Loading

ERP Custom Fields

ERP custom fields add your own fields to ERP records (a customer's account number in your old system, a purchase order's project code, a delivery's carrier) without changing the datastore's structure. The values are kept beside the record and appear on its record screen in a Custom fields pane.

Where to find it

Architect Panel → ERP - Setup:

  • ERP Custom Fields — the definitions: which datastore a field is added to, its name, label, type and rules
  • ERP Setup — its checklist lists any custom field definition that is not valid

When to use it

Use a custom field when you need to record something the shipped ERP datastores do not hold and you would rather not change those datastores, which platform updates maintain. For a field that every installation would want, or one you need to report on heavily, adding a real column to your own datastore is usually better.

Defining a custom field

  1. Open ERP Custom Fields and add a row.
  2. Choose the datastore the field belongs to (Table Name), for example the purchase orders or customers datastore. It must be a registered datastore that exists.
  3. Give it an internal name: letters, digits and underscores, starting with a letter or underscore, at most 64 characters, such as carrier_ref. It must not be the name of a real column on that datastore, or of another custom field on it.
  4. Give it the label people will see, and help text that says what to enter.
  5. Choose the type from the picker (text, number, date, a link to another datastore, and so on), and its settings if the type has any, such as the choices of a pick-list.
  6. Set whether it is required, a default value, any validation rule, its position on the form, and whether it is encrypted.
  7. Make sure it is enabled, and save.

Encryption applies to text-like fields (text, long text, phone, address): the value is stored encrypted at rest and searching it still works, more slowly. On a date, number or link field the setting is ignored, because those values are compared and joined.

Using it

Open a record of that datastore on its record screen. The Custom fields pane lists the fields defined for it, with their current values. Edit and save; required fields are checked before anything is written, and only fields defined for that datastore are stored.

Who can see and change the values follows the record: you need read access to the datastore to see them and edit access to change them, the record must be visible to you, and record access rules apply. For ERP documents the ERP role grid applies too, so a buyer can read the custom fields on their own purchase order.

The rules are enforced everywhere

A definition saved through the ERP Custom Fields list, a record screen, the API or an import is checked the same way. The refusals you may see:

  • "Choose the datastore the custom field belongs to - it must be a registered datastore that exists."
  • "A custom field needs a valid name: letters, digits and underscores, starting with a letter or underscore, at most 64 characters."
  • "'...' is already a real column on ... - a custom field cannot shadow it. Choose another name."
  • "There is already a custom field called '...' on ..."

A definition stored before these checks existed that breaks them is ignored at run time and listed on the ERP Setup checklist, so you can correct it.

What goes wrong

  • The pane does not appear: no enabled field is defined for that datastore, or you lack read access to it.
  • A value will not save: a required custom field is empty, or you have read but not edit access.
  • Turning a field off: disable it rather than deleting it; existing values and history stay intact.

Worked example

A distributor wants every delivery note to record the carrier's consignment number. The architect adds an ERP custom field on the delivery notes datastore with the internal name consignment_no, the label "Consignment number", type text, not required. Warehouse staff open a delivery note's record screen, fill in the Custom fields pane, and the number is there for anyone answering a customer's "where is my order" call.

Recommendations

  • Name fields as identifiers you will recognise in a year; they cannot clash with real columns.
  • Write help text; it is what tells people what to enter.
  • Encrypt sensitive text, not dates or numbers.
  • Disable rather than delete fields you no longer need.