Getting Started with ERP

ERP Suite Overview

The ERP layer adds the machinery a business system needs once it stops being a database with forms on it: a ledger that is the system of record, stock that cannot drift, documents with a lifecycle, projects that bill, and the arithmetic underneath all of it.

It works against your datastores, not instead of them

This is the single most important thing to understand, and it is unusual. The ERP engines do not ship their own customer table, their own product table or their own invoice table. They work against the datastores you designed, with your column names, through a mapping called a binding.

So the stock engine does not need a table called Products. It needs to be told which of your datastores plays the item role, and which column on it holds the code. You keep the data model you built for your business; the engines supply the behaviour.

What is included

• Calculated fields and rollups — server-side arithmetic for line totals and header totals.
• Transactional documents — document types with an enforced lifecycle, and conversion from quote to order to despatch to invoice.
• General ledger — double-entry journals, multi-currency, period close.
• Accounting and bank feeds — inbound data from Xero, QuickBooks, Sage and bank connections.
• Stock — an append-only movement ledger with reservations and FIFO valuation.
• Structures — bills of materials, recipes, kits, routings and requirements planning.
• Pricing — price lists with quantity breaks, discount rules and commissions.
• Time, expenses and projects — capture, rate cards, budgets and billing plans.
• Assets — a register with meters, preventive maintenance and posted depreciation.
• EDI — trading partners, message mapping and transports including AS2 and OFTP2.
• Analytics — a measure and dimension model over any registered datastore.

Adopt only what you need

The modules are separate. A professional services business might use time, projects, documents and the ledger and never touch stock or EDI. A distributor might use stock, pricing, documents and EDI and have no projects at all. Nothing obliges you to enable a module you have no use for, and an unused module costs you nothing.

Where to start

Two concepts come before everything else: entities and bindings. Entities are the legal companies your data is filed under. Bindings are how the engines find your tables. Read those two articles next — every other module assumes them.

Legal Entities

An entity is a legal company operating inside your application. If the business you are modelling is one company in one country, you will have exactly one entity and can largely forget about it. If it is a group with subsidiaries, entities are what let one application run all of them.

Entity is not the same as tenant

The platform already has multitenancy, and it is tempting to assume a second company is a second tenant. It is not, and the distinction is deliberate.

• A tenant is a customer of the platform. Tenants are sealed from one another — data never crosses, and that isolation is enforced at the lowest level.
• An entity is a legal company that one customer operates. Entities are designed to be crossed, carefully and on purpose.

The reason is that the two central group-accounting operations require crossing. An intercompany journal has to write both sides — one company owes, the other is owed — in a single transaction. A consolidation has to read every subsidiary at once. Tenant isolation forbids both by construction, and rightly so. Entity exists precisely so those operations are possible without weakening the isolation that protects one customer from another.

Setting one up

Create a row per legal company, with its name, its own currency and its reporting currency. The functional currency is the one that company keeps its books in; the reporting currency is the one the group consolidates into. For a single-company system they will usually be the same.

Granting access

Entity access is granted as an ordinary security group permission rather than through a separate system of its own. That is deliberate — it means entity restrictions appear in the security screens your administrators already use, alongside every other grant, instead of hiding in a module-specific corner where they will be forgotten during an access review.

A user who is permitted only one entity sees only that entity's records, everywhere in the application. A finance user who needs the group view is granted several.

What is filed by entity

Ledger journals, stock, assets, price lists, documents and projects all carry an entity. That is what makes a trial balance, a stock valuation or a sales report answerable for one company rather than for everything at once.

Plan this before you post anything

Adding an entity later is easy. Splitting one entity into two after a year of postings is not — every historical record has to be attributed, and some of them genuinely will be ambiguous. If there is any prospect of a second legal company, set both up at the start even if one is dormant.

Connecting Engines to Your Datastores

A binding is the mapping between an ERP engine and your data model. It is what allows the stock engine to work with a datastore you called Parts, and the time engine to work with one you called Jobs, without either engine knowing those names in advance.

Roles and slots

Each engine declares what it needs in abstract terms.

• A role is a table the engine needs — the item role, the header role, the line role, the project role.
• A slot is a column within that role — the code slot, the quantity slot, the date slot.

You fill in which of your datastores plays each role, and which of your columns fills each slot. From then on the engine asks for slots and never for columns, so it works identically whether your quantity column is called Qty, Quantity or Number_Of_Units.

Where to configure it

Bindings have their own screen in the Architect Panel, laid out as a matrix of roles and slots per engine. This is one of the few places the platform provides a bespoke screen rather than a plain datastore list, because a grid is genuinely the right shape for the job — you are filling in a table of correspondences, and seeing them all at once is what makes a gap obvious.

Constants as well as columns

A slot can be filled with a fixed value instead of a column. If every row in your system is the same warehouse, the warehouse slot can simply be that warehouse rather than a column you would have to add and populate identically on every record.

Bindings use names, not internal IDs

A binding refers to your table and column by name. This has one consequence worth knowing about: renaming a physical datastore or column breaks any binding that refers to it. If you rename something, revisit the bindings screen.

The alternative — referring to internal record IDs — would be worse. Those IDs are reassigned when the platform updates, and a binding that silently pointed at a different table after an update would, for a ledger, mean posting into the wrong company's books. Every other modern part of the platform that links to a table by configuration does the same thing for the same reason.

Validate before you rely on it

An incomplete binding produces an engine that appears to do nothing, in the same way a missing table rule does. Fill in every slot an engine asks for, save, and test one record end to end before configuring the next module.

Order of work

Bind before you configure. Almost every article in the rest of this section assumes the relevant binding is already in place, and most module problems that look mysterious turn out to be a slot left empty.