Skip to main content
Version: Latest

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:

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).