Operational Boundaries
This is the single most important page in this guide. Every starter-template family documented here was built to the same explicit business boundary, restated in full below because it governs what is (and is never) safe to add to any future phase in this area.
What Shumoul starter setup provides
For each BusinessActivity, a practical starter structure:
BusinessType,ProductDepartment,ProductCategory,Products,UnitOfMeasure,ProductUnits(prerequisites, categories, items/units)- A starter chart of accounts, GL account mappings, an inventory account category, and cost centers (accounting chart templates, inventory account category templates, cost center templates)
The purpose is to help a tenant start with a reasonable structure immediately after the onboarding survey — never to hand them a fully operational, ready-to-sell business.
What Shumoul starter setup does NOT provide
No operational inventory:
- No stock quantities
- No opening inventory balances
- No inventory transactions
- No accounting postings
- No suppliers
- No real or generated barcodes
- No market/real prices
- No price lists
- No warehouse balances
Prices and barcodes: where the real Product/ProductUnit model requires a Price or Barcode field
to exist, the safest current default is used — which in practice means leaving it blank/unset
(every seeded item template leaves Price, Barcode, and InternationalBarcode empty). No template
in this initiative has ever invented a market price or a plausible-looking barcode. The tenant is
responsible for entering real prices and real barcodes — nothing generated by starter setup should
ever be treated as final operational data.
Where inventory actually comes from
Inventory — real stock quantities, real opening balances, real transaction history — must come later from the tenant's own official documents, never from any template in this guide:
- Opening stock documents
- Purchase invoices
- Stock receiving documents
- Stock adjustment/count documents
This is enforced structurally, not just by convention: the
Product Catalog Items apply service deliberately never calls
CreateInventoryItemAsync (the real ERP's own stock-item-creation hook), and no accounting-posting code
path exists anywhere in this initiative. The
Inventory Account Category classification
makes this concrete at the field level: only 3 of 13 GL account fields are consumed by any posting code
today (all three in purchasing), and no sales/COGS/stock-movement posting logic exists in the codebase
at all yet.
Why this boundary is enforced this strictly
Getting a tenant's structure wrong (a category named slightly differently than they'd like) is a minor, easily-corrected annoyance. Getting a tenant's financial data wrong — an invented opening balance, a fabricated price, a placeholder barcode that later collides with a real one, a phantom GL posting — is a data-integrity and (for a live accounting system) potentially a compliance problem, and is far harder to correct after the fact. Every phase in this initiative was reviewed against this boundary before being accepted; a future phase proposing to add any of the "does NOT provide" items above should be treated as a business-decision escalation, not a routine extension.
Cross-reference: this boundary in each source phase
Every one of the following phase docs independently states some version of "starter templates only, not certified accounting/legal/tax advice, no stock/inventory/accounting impact": Accounting Chart Templates, Inventory Account Category Templates, Cost Center Templates, Product Catalog Categories, Product Catalog Items and Units, and Product Catalog — Starter Kit Integration (which restates the boundary as an explicit, verbatim business directive given before that phase began).
