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. The ERP Setup console now checks every binding for you and says exactly what is missing.

Where to find it

Architect Panel → ERP - Setup:

  • ERP Setup — the Bindings tab: every binding, whether it is valid and what to fix
  • ERP Bindings — the bindings themselves; the Field Mappings action on a binding opens its slot mappings

Admin Panel → ERP - Setup:

  • ERP Setup — the same Bindings tab, read-only for an ERP administrator who is not an architect

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. A slot can hold a fixed value instead of a column, for example one warehouse for every row.

Checking binding health

  1. Open ERP Setup and choose the Bindings tab. The summary card Bindings valid at the top of the console shows how many pass.
  2. Read the Status column: Valid, Problems, Disabled or Disabled, has problems.
  3. For each binding with problems, read What to fix. Typical hints are a required slot with no mapping, a datastore that does not exist or is not registered, or an engine that is not in the engines list.
  4. Open Slots under the hints to see every slot the engine declares, whether it is Required or Optional, and what it means.
  5. As an architect, press Field mappings on the row to fix the mapping, or Open ERP Bindings to change which datastore the binding points at.
  6. Return to the Checklist tab: the row Bindings resolve turns green when every enabled binding validates.

The columns on the Bindings tab

  • Binding: its name, with its key and role underneath.
  • Engine: the ERP engine that reads it.
  • Datastore: the table it points at, or Missing.
  • Required slots: how many of the required slots are mapped, for example 4 of 5.

Names, not internal IDs

A binding refers to your datastore and column by name. Renaming a datastore or a column therefore breaks any binding that refers to it, and the Bindings tab shows it straight away as Problems. Internal record IDs are not used because they differ between installations; a binding silently pointing at a different table would, for a ledger, post into the wrong books.

What goes wrong

  • An engine that seems to do nothing: almost always an empty required slot. Check the Bindings tab before anything else.
  • "No bindings are defined": bindings are created with the document types that use them. Set up the document types first.
  • Bindings are maintained by an architect: a non-architect ERP administrator sees health but cannot change mappings.

Worked example

A distributor renames the column Qty on its Order Lines datastore to Quantity. The next morning the ERP administrator sees Problems against the sales order line binding, with the hint to add a field mapping for the quantity slot. The architect presses Field mappings, points the slot at Quantity, saves, and the binding returns to Valid without any document being re-keyed.

Recommendations

  • Open the Bindings tab after any rename of an ERP datastore or column.
  • Fix every problem before enabling a binding. A disabled binding with problems is harmless; an enabled one fails at the first posting.
  • Write down which datastore plays which role: it is not obvious six months later.
  • Test one record end to end after changing a mapping.