Developers
The canonical data model
The shared objects every ERP connects through, which is why changing ERP is one adapter.
The objects
| Object | What it is | AP | AR |
|---|---|---|---|
| Party | Who the document is from or for | Vendor | Customer |
| Order | The commitment, with its lines and what remains to bill | Purchase order | Sales order |
| Movement | The goods actually moving, with its lines | Item receipt | Item fulfilment |
| Document | The incoming paper | Vendor invoice | Bill of lading |
| Result | What is written back, with its lines | Vendor bill | Customer invoice |
| Coding | The account and dimensions on each result line | Expense GL · class · department | Revenue GL · class · tax, from the order line |
| Charges | Tax, freight and other non-goods lines | Placed by rule | Placed by rule |
What an adapter implements
- Fetch the order, with its lines and remaining quantities.
- Fetch what moved against it, with its lines and what has already been consumed.
- Translate the incoming document in, and the result out.
- Name the dimensions this ERP carries.
- Translate the ERP’s status codes — exactly once, here. No engine code ever sees them.
The NetSuite adapter is the contract. Stockly, Analytos’s own ERP, implements the posting path. The QuickBooks adapter is a stub. A CDM Objects page in the product shows exactly which ERP field each object maps to for the connected system.
Why it matters
The matching kernel is only ever given role names — commitment, fulfilment, output. It never learns whether it is buying or selling, which is why the same tested code decides both directions, and why adding the second product is a configuration change rather than a second implementation.
The API
Every screen in the product is driven by the same REST API: upload, status, inbox, rules, matching policies and posting are all callable. The live documentation is served by the running service.
Want to see it rather than read about it?
A walkthrough takes an hour and starts with your own documents.