Twenty-plus years living in Saturn as the daily source of truth — writing the MaxBasic, designing the forms, owning the reporting. XBA makes Accredo do the specific things your business does, without compromising the ledger it runs on.
Personal reply from Andrew within one business day.
Accredo Saturn is deeply extensible if you know where the hooks are. This is the toolbox — each capability delivered as a documented, supportable build, not a one-off script.
Business rules enforced where they belong — in the transaction itself. BeforeSave validation, AfterSave and AfterPost automation, OnPrint document logic, plus scheduled batch scripts for the work that runs overnight.
Custom entry screens, dashboards and maintenance forms built in Saturn's Form Designer — grids, combos, live lookups and code behind them. Invoices, packing slips and statements that print exactly what your process needs.
Standalone custom tables and extension fields on Accredo's own tables, indexed and registered properly — so the data your business actually runs on lives inside Saturn with everything else, not in a spreadsheet beside it.
SP scripts that resolve multi-tier customer agreements, contract pricing and volume breaks at quote and invoice time — automatically, consistently, and without the sales team maintaining a shadow spreadsheet.
Saturn's web service API opens the ledger to the systems around it — reads, standard record writes and raw queries over OData/REST. The route for connecting web apps, Microsoft 365, HubSpot, e-commerce and reporting tools.
From reports inside Saturn to live browser dashboards reading ERP data — branch performance, stock, pricing and margin in one view that refreshes itself, instead of a monthly spreadsheet ritual.
The most expensive gap in most Accredo sites isn't in the office — it's everywhere the work happens away from a Saturn terminal. Goods received in the warehouse, jobs completed in the field, returns arriving at the dock: all captured on paper or memory, then re-keyed later, with drift.
XBA builds web applications for exactly these edges — barcode-driven warehouse capture, field service job sheets, returns processing — that capture the record once, at the source, and post it to Saturn the way Saturn posts to itself. The field service management case study is one of them, written up in full — including which data travels the OData API and which has to be posted natively.
Getting data into Saturn safely is a design decision, not a default. Reads and standard records travel the supported OData API. Transactional writes that have to land cleanly use native MaxBasic, posting directly the way Saturn posts to itself. Both routes treat the ledger as the single source of truth.
// The wrong path is how integrations corrupt ledgers. Choosing correctly is the specialty.
Path A has more in it than one lane suggests. Saturn's web service is an OData v4 REST API with three distinct mechanisms behind it — entity endpoints, a read-only SQL passthrough and server-side script calls — and choosing between those is its own decision. The Accredo API and OData integration page sets all three out in a comparison table, along with the authentication and concurrency detail, and is honest about where the API stops.
Path B has its own decisions in it too. Native MaxBasic means a script running inside Saturn, and where that script attaches — to the save cycle, to the post, to a document, or to nothing at all but a schedule — changes what it can do and how it fails. The MaxBasic scripting page takes the four event hooks one at a time, and is equally honest about the cases where the right recommendation is not to script at all.
Running Accredo Saturn and drowning in a manual process? Tell me what's eating the week — the audit is free.
Book a free process auditYes, and more deeply than most sites running it realise. Accredo Saturn is extensible through its own built-in tooling: a scripting language that runs inside the product, a form designer for building custom screens, table tools for adding fields and standalone tables, pricing rules, document layouts, and a web service API for the systems around it. All of it is the product extending itself rather than a third-party layer bolted alongside, which is why a well-built customisation behaves like part of Saturn instead of like something attached to it.
Six areas cover almost all of it. Event scripting puts business rules inside the save and post cycle. Scripted forms build custom entry screens, maintenance grids and dashboards. Custom tables and extension fields let information your business actually runs on live inside Saturn rather than in a spreadsheet beside it. Special pricing rules resolve tiered agreements and volume breaks at quote and invoice time. The OData web service opens the ledger to external systems. Reporting runs from inside the product out to live dashboards. Most real projects use two or three of them together.
Work built against the product’s supported surface should carry through. Work that leans on behaviour the product never promised is what breaks, and it usually breaks quietly rather than loudly. The difference is a build decision, not luck. Customisations are version-controlled and documented so that an upgrade becomes a test you run rather than a discovery you make months later, and upgrades are coordinated with whoever maintains your Saturn install rather than sprung on them.
It depends on who has to touch it. A rule that must hold for every record, including ones typed straight into Saturn by a person, has to live inside Saturn — an external system cannot police what it never sees. A screen for people who already have Saturn open all day belongs inside it too. But where the people doing the work are in a warehouse, in a van or on a phone, a screen inside Saturn is the wrong artefact regardless of how well it is built, and the answer is a small application that posts into Saturn through a supported route.
By finding out what the rule or the job actually is before quoting anything, because the version described in a meeting and the version practised at the desk are rarely the same. That first conversation is a free process audit with a written outcome, and it fairly often ends with the recommendation that the product already does this, or that a process needs changing rather than a system. Where there is a build, it is scoped and quoted before it begins and delivered fixed-price, with documentation and handover in scope rather than sold afterwards.
