Enterprise Resource Planning (ERP)

Enterprise Resource Planning (ERP). ERP is the system of record for money, quantity, and commitment of one legal entity: GL, AP/AR, inventory, purchasing, sales orders, MRP, manufacturing orders, and costing. Horizon is hours to months — not milliseconds, not engineering definition, not group close.

In industry this is SAP / NetSuite / Dynamics-class ERP capability for one legal entity. In N23D it is not a seat next to someone else’s stack. It is a peer module on one native Rust binary — N23D — 100% Rust we write.

Pallet-rack warehouse — inventory on one LegalEntityId

Same product. One company’s books. The item is the identity CAD and PLM already named. The books do not invent a second SKU. Invoice, WO, inventory, quote, and pay sit on a LegalEntityId. BUS consolidates the group. Cross-entity stock is an intercompany sale, not a warehouse transfer. HoldCo is not a plant code. Assets have financial views here; operational life lives in TIX on AssetId.

What ERP actually does

  • Financials of one company: general ledger, accounts payable, accounts receivable, fixed assets, multi-currency, period close. Double-entry ledger we own. Money is a decimal type. No floating-point dollars. Posted journals are append-only. Corrections are reversing entries. Period lock refuses late journals.
  • Inventory: multi-site, multi-bin, lot and serial, valuation as standard, FIFO, or moving average. Warehouse-lite: receive, putaway, pick, ship. Same-entity warehouse move is a transfer. Cross-entity stock movement is an intercompany sale, or explicit consignment. No third kind.
  • Purchasing: requisition, purchase order, receipt, three-way match. Vendor id is shared with the PLM approved-manufacturer list and the quality supplier record.
  • Sales: the order is born from a CRM quote accept, then delivery, then invoice. A CRM-accepted quote becomes a sales order with the same lines. CRM does not own accounts receivable.
  • MRP II: master production schedule, material requirements planning, capacity (rough now, finite later). BOM explode from a released PLM manufacturing-BOM snapshot. Pegging. Action messages: expedite, cancel, make.
  • Manufacturing orders: work order from the released manufacturing BOM and routing, kit, backflush, variance. Release to MES with revision and lot rules. Receive completions and scrap. Variance to standard. Charge codes on work orders and projects belong to the entity.
  • Costing: standard and actual, landed cost. Standard roll-up from manufacturing BOM, routing, and Materials identity. Actual from MES labor and machine plus purchase orders. Materials is not a cost card.
  • Item identity is PLM’s and global. Item commercial data is per entity: planning policy (make, buy, both), lead time, lot size, safety stock, scrap, cost method, standard cost, sites. ERP may not create an engineering item. It may create a non-engineered SKU (office supplies) in a separate type, still per entity. A part designed once can be bought by the GmbH and made by the Nevada LLC. That is two commercial rows, one item id.
  • Lot and serial identity is shared with MES and Materials pedigree. Quantity lives here. Genealogy lives in MES. ATP and pick refuse a lot on quality hold. An open critical nonconformance blocks ship.
  • Labor collection from MES. Payroll cash and liability journals from BUS pay results.
  • Tax and compliance exports. 100% Rust we write. No SAP, NetSuite, or Dynamics as the runtime. The double-entry ledger is ours.
Forklift loading a container — shipping docks and receiving

How N23D puts this in one place

Most stacks fail the day after save, when the model, the ticket, or the invoice becomes someone else’s import. N23D removes that day. This module reads the same record as the others.

  • one native Rust binary: N23D. 100% Rust we write. No vendor kernel, ledger, PLC runtime, HRIS, or ITSM as the source of truth. File readers and protocol bridges are interchange.
  • One identity plane: Item, VariantId, Person, and AssetId are global. Invoice, work order, inventory, quote, pay result, and NCR sit on a LegalEntityId.
  • One digital thread: modules read the same record. There is no daily STEP shuffle as the workflow. Check-in is PLM save. CAM does not fork the body.
  • Command::Core is the identity and policy plane. CCB is the full-spectrum change spine (not a second vault). TIX holds operational life of assets; ERP sees only the financial view.
  • Materials only from MAT. CAD selects VariantId. Missing density means mass is unknown — we do not invent a number so a BOM or plot closes.
  • ERP is one company’s books. BUS holds HR, org, legal entities, and group consolidation. HoldCo is not a plant. No fake Form 1120. No fake Lohnsteuer.
  • CRM quote accept writes the sales order. MES completes the WO. QMS NCR can block ship — same identity.
  • ERP may not create an engineering item. Non-engineered SKUs are a separate type, still per entity.
  • Fixed-asset depreciation and cost center are ERP. Locating, maintaining, and ticketing the asset is TIX.
Barcode scan on a package — lots and WOs on the books

What we will not fake

This is the product promise, not a claim that every solver and every pack already ships in the binary today. Industry-class names below are capability equals. They are not products we ship.

  • We do not ship SAP, NetSuite, or Dynamics as the runtime. The double-entry ledger is ours.
  • ERP does not consolidate the group and does not file Form 1120 from a plant ledger.
  • ERP is not PLM, MES, softPLC, or Salesforce. No floating-point dollars.

If the books still cannot name the body, or HoldCo is a plant code, we failed. Design, make, and bill the same identity.

Natively connected, not glued together

N23D runs one data model across design, make, operate, and the business. Nothing is exported as the daily path. Nothing is re-keyed. Nothing is lost in translation between vendors.

  • One data model. A part, an order, a nonconformance, a ticket, and a change point at the same objects. No mapping tables, no nightly sync, no drift.
  • No export/import loss. Geometry, tolerances, revisions, asset state, and history stay intact because they never leave the system as the daily path.
  • Auditability by default. Every change is versioned and attributable, so traceability is a query, not a project.
  • Speed. 100% Rust: native performance, small footprint, no runtime surprises.
  • Sovereignty. Your data, your infrastructure, your rules. No lock-in.