Getting Started with ERP

ERP Suite Overview

The ERP layer adds what 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 an enforced lifecycle, projects that bill, and the arithmetic underneath all of it.

Where to find it

Architect Panel → ERP - Setup:

• ERP Bindings — point each engine at your datastores
• Legal Entities — the companies your data is filed under

It works against your datastores

The engines do not ship their own customer table, product table or invoice table. They work against the datastores you designed, with your column names, through a mapping called a binding.

The stock engine does not need a table called Products; it needs telling which of your datastores plays the item role. You keep the data model you built for your business and gain the behaviour — which is why adopting a module rarely means migrating anything.

Five sections, roughly seventy screens

• ERP - Setup — Legal Entities, ERP Bindings, Entity Permissions, Document Types, Document Conversion Map, Documents, Calculated Fields, ERP Custom Fields, PunchOut Suppliers.
• ERP - Finance — Ledger, Chart of Accounts, Journals, Accounting Periods, Tax Codes, Posting Rules, Exchange Rates, Intercompany Rules, Allocations, and the accounting and bank feed screens.
• ERP - Operations — Stock with its movements, balances, lots, genealogy, locations, policies and cost layers; Structures and standard costs; Demand and Supply; Assets, meters, depreciation, maintenance, inspections and non-conformances.
• ERP - Projects & Time — Projects & Time, Work Breakdown, Project Budgets, Billing Plans, Rate Cards, Time Entries, Timesheets, Expenses, Absence, Resource Capacity.
• ERP - Trading & Analytics — Pricing, Price Lists, Price Rules, Commission Schemes, EDI and its partners, transports, maps, messages and control numbers, AS2 Certificates, Analytics with Measures, Dimensions, Reports and Report Schedules.

Consoles and lists

Two kinds of screen appear, and knowing which you are on saves confusion.

• Consoles — purpose-built screens: Ledger, Stock, Structures, Projects & Time, Pricing, EDI, Analytics, Asset Register, Documents, Feed Queue, PunchOut Suppliers. This is where you do the work.
• Lists — the underlying datastores in the generic editor. This is where you configure, correct and inspect. A console shows the position; the list behind it shows every row.

Adopt only what you need

The modules are separate. A professional services firm might use Projects & Time, Documents and Finance and never open Operations. A distributor might use Operations, Pricing, Documents and EDI and have no projects at all. An unused section costs nothing — and Platform Modules can hide it entirely.

Worked example — deciding what to turn on

A manufacturer adopting ERP starts with Setup (entities and bindings), then Operations for stock and structures, then Finance once stock movements need to post. Projects, EDI and Pricing come later as they are needed. Each step is usable on its own, and nothing forces the next.

Recommendations

• Do Legal Entities and ERP Bindings first. Every other module assumes both.
• Adopt one module at a time and run it properly before starting the next.
• Hide the sections you will not use with Platform Modules, so the panel stays navigable.
• Read the background tasks article early — several modules do nothing visible until a task is enabled.

Legal Entities

An entity is a legal company operating inside your application. One company in one country means one entity you can largely forget about. A group with subsidiaries is what entities exist for.

Where to find it

Architect Panel → ERP - Setup:

• Legal Entities — one row per legal company
• Entity Permissions — which security groups may see and write which entity

Entity is not tenant

• A tenant is a customer of the platform. Tenants are sealed from one another and data never crosses.
• An entity is a legal company one customer operates. Entities are designed to be crossed, deliberately.

Both central group-accounting operations require crossing. An intercompany journal writes both sides in one transaction; a consolidation reads every subsidiary at once. Tenant isolation forbids both by construction, and should. Entity exists so those are possible without weakening it.

Setting one up

Add a row per company with its name, its functional currency (the one it keeps its books in) and its reporting currency (the one the group consolidates into). For a single-company system the two are usually the same.

Granting access

Use Entity Permissions. Access is an ordinary security group grant rather than a parallel permission system, so entity restrictions appear in the security screens your administrators already review instead of hiding in a module-specific corner.

A user permitted one entity sees only that entity everywhere. A finance user needing the group view is granted several.

What is filed by entity

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

Worked example — a group of three

A holding company with two trading subsidiaries sets up three entities. Each subsidiary keeps books in sterling; the group reports in sterling too, so functional and reporting match. Operational staff are granted their own subsidiary only. The finance team is granted all three, which is what makes consolidation and intercompany possible for them and impossible for everybody else.

Plan this before you post

Adding an entity later is easy. Splitting one into two after a year of postings is not — every historical record has to be attributed, and some genuinely will be ambiguous.

Recommendations

• Create the second entity now, dormant, if there is any prospect of one.
• Set both currencies at creation. Changing a functional currency after postings exist has no clean fix.
• Grant entity access through groups, never per user.
• Name entities as they appear on their statutory accounts, not by trading name.

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.

ERP Background Tasks

Several ERP modules depend on work happening on a schedule rather than when somebody presses save. All of the tasks below ship disabled, in keeping with the platform rule that nothing starts running because an update was applied.

Where to find it

Architect Panel → Automation:

• Tasks — enable, schedule and run each one
• Task Log — what ran, when, and what it did

The six tasks

• Calculated Field Recalculation (hourly) — the consistency sweep for calculated fields and rollups. Catches totals left stale by imports, data extraction or direct database changes.
• Accounting and Bank Feed Sync (hourly) — pulls transactions from connected accounting packages and bank feeds into the feed inbox.
• Accounting Outbound Mirror (hourly) — pushes postings out to an external package where you mirror rather than replace it.
• Asset Depreciation (daily) — posts the depreciation charge per period. Run daily so a period end is never missed; the engine refuses to run a period twice.
• Scheduled Report Distribution (hourly) — runs saved analytics reports on their schedules and delivers them.
• Letter Dispatch (every few minutes) — sends queued letters to the print and post provider. A queue rather than a batch.

Enabling one

Open Tasks, find it, set the frequency and tick Enabled. Run it once by hand first and read the Task Log entry before leaving it on a schedule.

Reading the log

Two patterns are worth watching for.

• A recalculation sweep that regularly corrects things means a table rule is missing somewhere. Add the rule rather than running the sweep more often — the sweep is a safety net, not the mechanism.
• A feed sync that regularly finds nothing may mean the connection has expired rather than that there is nothing to fetch.

Only enable what you use

No feeds means no sync or mirror. No assets means no depreciation. Enabling a task for a module you do not use wastes a run and clutters the log, which makes the entries that matter harder to see.

Worked example

A firm using documents, the ledger and projects enables three tasks: recalculation hourly, report distribution hourly, and letter dispatch every five minutes. Depreciation and both feed tasks stay off because they have no assets and no external accounting package. The task log stays short enough that an unusual entry is noticed.

Recommendations

• Run each task manually once and read the log before scheduling it.
• Enable only what your configuration needs.
• Check the log weekly for the first month after enabling anything.
• Trigger recalculation by hand after a large import rather than waiting for the schedule.