Loading

Connecting Engines to Your Datastores

A binding maps an ERP engine onto your data model. It is what lets the stock engine work with a datastore you called Parts and the time engine work with one you called Jobs.

Where to find it

Architect Panel → ERP - Setup:

  • ERP Bindings — which datastore plays which role, and which column fills which slot
  • ERP Custom Fields — extra fields the engines should carry alongside your own

Roles and slots

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

You state which datastore plays each role and which column fills each slot. The engine then asks for slots and never for columns, so it works whether your quantity column is Qty, Quantity or Number_Of_Units.

Constants as well as columns

A slot can hold a fixed value instead of a column. If every row is the same warehouse, fill the warehouse slot with that warehouse rather than adding a column you would populate identically on every record.

Names, not internal IDs

A binding refers to your table and column by name. One consequence: renaming a datastore or column breaks any binding that refers to it, so revisit this screen after a rename.

The alternative would be worse. Internal record IDs are reassigned when the platform updates, and a binding silently pointing at a different table afterwards means, for a ledger, posting into the wrong company's books. Every other modern part of the platform that links to a table by configuration behaves the same way.

Fill every slot an engine asks for

An incomplete binding produces an engine that appears to do nothing at all — the same symptom as a missing table rule. Complete it, save, and test one record end to end before configuring the next module.

Worked example

A distributor already has a Products datastore with columns Code, Description and UnitOfMeasure, and a Warehouses datastore. Binding the stock engine means: item role → Products, code slot → Code, description slot → Description, location role → Warehouses. Nothing was added to either datastore, and stock movements start working against the data model they already had.

Recommendations

  • Bind before you configure anything else. Most mysterious module problems are an empty slot.
  • Write down which datastore plays which role — it is not obvious six months later.
  • Revisit bindings after any rename.
  • Test one record end to end before moving on.