Accredo Saturn is scriptable.
MaxBasic is its built-in scripting language. A script attaches to an event in Saturn's own save-and-post cycle, or runs standalone on a schedule, so a business rule is enforced inside the transaction rather than in a spreadsheet beside it. Choosing the right event is most of the craft.
Personal reply from Andrew within one business day.
What is MaxBasic, exactly?
MaxBasic is Accredo Saturn's built-in scripting language — a Basic-derived language that runs inside the product itself, with access to its data, its forms and its own posting routines, rather than talking to it from outside over a wire.
That distinction is not pedantry; it is the entire reason scripting is a separate discipline from integration. An external system, however well built, is a visitor. It authenticates, it asks for things, and it is subject to whatever the product chooses to expose. A script is not a visitor. It runs as part of the transaction, at a moment the product itself chose to hand over control, and it can therefore do things no outside caller can — including refusing to let a save happen.
The practical consequence is about coverage, not capability. A rule enforced in a script applies to every route into the data: the integration, the scheduled import, and the person typing directly into Saturn at four o'clock on a Friday. A rule enforced in the calling application applies only to records that arrive through that application. If the requirement is genuinely "this must always be true", there is only one place it can live, and that fact settles a surprising number of design arguments before they start.
Scripts are files, and files get deployed. An Accredo script is a .pfs file placed on the Saturn install and registered against something — an event in the save or post cycle, a form, or a scheduled run. That is a change to the client's environment rather than to a system you host, and it is the part people consistently underestimate when they scope scripting work. It needs the same discipline as any other code that runs in production: source control, a record of what is installed and why, a way to test it without touching the live company file, and a way to take it back out.
There are two operational shapes, and only one language. An event script is triggered by Saturn doing something, runs synchronously, and usually has a person waiting on the other side of it. A batch script is triggered by a scheduler or an operator, runs standalone, and works through records in bulk. They are written in the same language against the same data, and they fail in almost opposite ways — which is why the choice between them matters more than it looks and gets its own section below.
None of this is exotic. It is the same set of trade-offs any mature business system presents once it lets you put code inside it. What makes Accredo work specialised is not the language, which is learnable in a week; it is knowing what Saturn does to a record between the moment a user presses save and the moment the ledger agrees, and putting your code at the right point in that sequence.
Which event should a script attach to?
Four hooks cover most of the work: BeforeSave, AfterSave, AfterPost and OnPrint. They fire at different moments, they can do different things, and putting logic in the wrong one is the most common way a working script turns into a support problem six months later.
// Saving is not posting. Most misplaced logic is logic that confused the two.
BeforeSave is the only place you can say no. It runs while the record is still a proposal, before anything is committed, and it is the one hook that can reject outright. That makes it the natural home of validation — this combination is not permitted, this field is required once that one is set, this discount needs an approval that has not happened. What does not belong in it is anything slow, and anything with a side effect outside Saturn. It sits between a person and the button they just pressed, and it may run more than once for a single successful save. A BeforeSave that sends an email is a BeforeSave that will eventually send an email about a save that never happened.
AfterSave is for the consequent work. It fires once the record exists, which makes it the right place for anything that has to exist alongside it: a companion record, a stamp written back to something related, a queue entry for another process to collect. The trap is treating it as a second chance to validate. By the time AfterSave runs the answer is already yes, so rejecting there means unwinding a commitment rather than declining a request — a different and considerably worse piece of code to write, and a much worse one to debug at month-end.
AfterPost is where the money is real. Saving and posting are not the same event, and conflating them is the single most expensive misunderstanding in this whole area. A saved record is data. A posted one has moved stock, a balance, or the general ledger, and only then is the transaction a financial fact. Anything that depends on that fact — telling another system an invoice now exists, releasing a downstream step that was waiting on it, updating an external status that customers can see — belongs in AfterPost. Put it in AfterSave and you get the classic support call: an outside system confidently reporting a transaction that Accredo does not yet consider posted.
OnPrint is about the document, not the data. It fires when a document is produced, and its job is presentation logic — what appears on this layout, for this customer, in this circumstance. Conditional blocks, an extra line pulled from somewhere else, a different message against a back-ordered item. The rule that keeps OnPrint clean is that printing is a read: producing a document should not change the data the document describes. A script that writes during a print is a script whose behaviour depends on how many times somebody previewed, and that is a bug you find by accident, months later, in a reconciliation.
Beyond the four, there is the scheduled batch script — no event at all, just code that runs when the scheduler says so. That is the right answer for volume work, for overnight reconciliation, and for anything too slow to run in front of a user. The Accredo Saturn capability page names the toolbox this sits in; the rest of this page is about deciding between them.
Event script, batch script, or not in Saturn at all?
Once the rule itself is understood there is a second question, and it is the one most often skipped: where should it live? The differences between the three answers are operational rather than technical. They fail differently, they are maintained by different people, and they age at very different rates.
| Event script | Batch script | The calling system | |
|---|---|---|---|
| What it is | Code registered against a point in Saturn's own save, post or print cycle. It runs as part of the transaction. | A standalone script run on a schedule or on demand, working through records in bulk rather than one at a time. | Logic held in the application or integration that talks to Saturn, rather than inside Saturn. |
| When it runs | The instant the thing happens, synchronously, usually with a person waiting. | Whenever the schedule says — overnight, hourly, or when somebody asks for it. | Whenever that system decides, entirely outside Saturn's knowledge or control. |
| Best for | Rules that must hold for every record without exception, including ones typed straight into Saturn by a person. | Volume work, reconciliation, overnight extracts, and anything too slow to sit in front of a user. | Logic that is genuinely about the other system — its workflow, its screens, its own rules. |
| How it fails | Loudly and immediately, which is mostly a virtue. The exception is a slow one, which presents as "Accredo has gone slow" rather than as an error anybody can read. | Quietly, and hours later. A batch script whose output nobody reads is a process that can stop without telling anyone it has stopped. | Invisibly to Saturn. If the rule exists only out there, anyone working directly in Saturn walks straight past it without knowing there was a rule. |
| What it costs to own | It is part of the install. It has to survive upgrades and be documented well enough that whoever supports Saturn next can see why it exists. | The same deployment story, plus a schedule and a log somebody actually reads. Cheaper to change, because nothing is waiting on it. | Nothing on the Saturn side — which is exactly the appeal, and exactly why rules end up out there that should never have left. |
// Must be true of every record? In Saturn. Slow or high-volume? On a schedule. Genuinely the other system's rule? Out there.
The short version of the table is a single test: ask who can get around it. If a rule can be bypassed by somebody doing their job normally in Saturn, and that bypass would be a problem, then the rule is in the wrong place and no amount of care in the calling system will fix it. Everything else — performance, tidiness, whose team maintains what — is a real consideration but a secondary one.
The third column is where this page and its sibling meet. Once logic sits outside Saturn it has to reach in, and how it reaches in is a decision in its own right: the Accredo API and OData integration page sets out the three mechanisms the web service offers, and the third of them is calling a server-side script from outside — which is the two halves of this table meeting in the middle. An external system triggers the work; the work still happens inside the product, with everything the product enforces on its own users. That combination is usually the right answer for a transaction, and the field service management case study is the same decision taken on a live build, with the reasoning written up rather than asserted.
When is scripting the wrong answer?
Reasonably often, and saying so early is cheaper for everybody than discovering it after an invoice. Four cases come up repeatedly, and the first is the most common by a distance.
When the product already does it. Saturn has a great deal of configuration in it, and a meaningful share of scripting requests turn out to be for behaviour that is already available and that nobody knew was there. A script that reimplements a setting is a script somebody has to maintain forever, through every upgrade, in place of a feature that was free. The first question on any scripting request should be whether this is a build or a conversation, and it is worth the hour it takes to find out.
When it should be a field or a form rather than code. If the requirement is that a piece of information gets captured, stays with the record and turns up in a report, that is a custom field and a layout change. Wrapping it in a script adds a moving part and a maintenance obligation to something that would otherwise just be structure. Code should be where the judgement is, not where the storage is.
When the process itself is the problem. Automating a step that should not exist makes the wrong thing happen faster and adds a system to look after. Sometimes the right recommendation after looking at a request is that two teams need to agree on a definition, or that a step needs deleting rather than scripting. That advice is free, and it gets given more often than a sales pitch would suggest.
When nobody is going to own it. A script becomes a permanent part of the client's install. Undocumented, unversioned and understood only by whoever wrote it, it stops being an asset and becomes a liability that surfaces at the next upgrade or the next staff change — and the person it surfaces on is rarely the person who commissioned it. If the documentation and the handover are not in the scope, the work is not finished, and scoping it that way is not padding.
What does an Accredo scripting project involve?
Almost never as much code as people expect, and almost always more conversation. Writing the script is usually the shortest part; pinning down what the rule actually is takes longer and is where the value sits.
The rule as stated is very rarely the rule as practised. "We never ship without a purchase order" reliably turns out to have four exceptions that everyone knows about and nobody has written down, and a script that enforces the stated version will stop the business by Wednesday. So the first piece of work is establishing the real rule including its exceptions, who is allowed to invoke them, and what should happen when someone tries — reject, warn, or record and continue. Those three are entirely different pieces of code, and choosing between them is a business decision rather than a technical one.
After that the sequence is deliberately unremarkable. Decide where the logic belongs, using the table above. Write it against a copy of the company file, never against the live one, because a validation rule with a bug in it does not fail politely — it stops people invoicing. Prove it against the awkward cases as well as the obvious one, since the awkward cases are the reason the rule exists. Then deploy it with the removal path already known and tested, and document what is installed, what it does, what it deliberately does not do, and why it was put where it was put.
What you end up with is a documented, supportable build rather than a file on a server. The source is yours, the reasoning is written down, and what is installed on the Saturn server is recorded well enough that somebody else could pick it up. None of it requires changing your licensing or your upgrade path, and coordinating directly with whoever maintains your Saturn install is normal and expected rather than awkward. If you want the wider picture, the Accredo Saturn capability page covers the forms, custom tables, pricing rules and reporting this sits alongside, and the integration topography section is the short version of the routing decision this page has just spent a table on.
Got a rule your team enforces by remembering it? Describe it — the audit is free, and sometimes the answer is that Saturn already does this.
Book a free process auditQuestions about Accredo scripting.
What is MaxBasic in Accredo?
MaxBasic is Accredo Saturn's built-in scripting language. It runs inside the product rather than talking to it from outside, so a script has access to Saturn's own data, its forms and its own posting routines. The practical consequence is coverage: a rule enforced in a script governs everybody, including the person typing directly into Saturn, which is something no external integration can achieve.
What is a .pfs file in Accredo?
It is the file an Accredo script lives in. The script is deployed onto the Saturn install and registered against something — an event in the save or post cycle, a form, or a scheduled batch run — and from that point it is part of the client's environment. That is why it needs the same treatment as any other production code: source control, a record of what is installed and why, testing against a copy rather than the live company file, and a clean way to take it back out.
What can an Accredo event script actually do?
Four things, at four different moments. BeforeSave can validate and reject, because the record is still a proposal at that point. AfterSave can create the consequent work once the record exists. AfterPost can act on the fact that the ledger has genuinely moved, which is not the same event as a save. OnPrint can decide what a document shows. Most of the skill is choosing between them rather than writing any one of them.
Will custom scripts survive an Accredo upgrade?
A script written against the product's supported surface should. A script leaning on behaviour the product never promised is the one that breaks, and it usually breaks quietly. Either way the answer is not to hope: scripts are version-controlled and documented so an upgrade becomes a test you run rather than a discovery you make, and upgrades are coordinated with whoever maintains your Saturn install rather than sprung on them.
Do we need a script, or can the API do it?
It depends on whether the rule has to hold for records created inside Saturn as well as records arriving from outside. If it does, it belongs in a script, because an integration cannot police what it never sees. If the logic is genuinely the other system's own, it belongs there and the API is how it reaches in. And where a transaction has to post the way Saturn posts to itself, a script is the route regardless of what triggered it — which is often an external system calling one.