ZyncGold ERP — Process Flows

Phase A · Tenant Setup

Super-admin onboarding → create company setup

A platform operator signs in and stands up a brand-new tenant. Creating the company provisions everything it needs to operate — in a single all-or-nothing transaction.

Flow

1. 1
   Super AdminSigns in to the platform.Session issued. A platform operator bypasses all permission and feature checks, so they can act across any company.
2. 2
   Super AdminCreates the company — name, registration number, fiscal year start/end, contacts.System validates company name and registration number are globally unique and the fiscal year end differs from the start.
3. 3
   SystemProvisions the tenant atomically.In one transaction, in order: company record → HQ branch ("{name} - HQ") → default config → Admin permission group → admin user + employee account → chart of accounts → fiscal periods (one per calendar month). A partial failure retries rather than leaving half-built data.
4. 4
   SystemEnables all standard modules and feature keys for the new company by default.Default role groups (Admin, Salesman, Marketing, Customer, Supplier) are seeded with full administrator access.
5. 5
   AdminSigns in to the new company; context is scoped to the company and HQ branch.Switching into an archived company is blocked for non-operators.

Provisioned in one transaction

Rules & gotchas

• Company name and registration number must be globally unique; fiscal end ≠ start.
• Provisioning is all-or-nothing — the company is never left partially built.
• Permanent company deletion requires the exact company name as confirmation and is operator-only.
• Known issue (auth): a hardcoded bypass one-time code is accepted during phone sign-in/sign-up — must be removed before production.

End state

A fully provisioned tenant — HQ branch, config, admin login, chart of accounts, fiscal periods and default role groups — ready for operational setup.

Phase B · Operational Setup

Workforce — employees & permission groups staff

The Admin staffs the company: defines who can do what, then creates employees — each with a staff login provisioned in the same step.

Flow

1. 1
   AdminCreates any additional branches and departments under the company.Departments scope automatically to the creating user's branch.
2. 2
   AdminDefines or adjusts permission groups and grants per-action permissions.Group names are unique per company; permission changes take effect immediately. Groups can carry business attributes such as labour and diamond discounts.
3. 3
   AdminCreates an employee — profile, permission group, leave/attendance/claim groups, basic salary, employment type.A staff login account is provisioned in the same transaction; if either the employee or the account fails, the whole creation rolls back.
4. 4
   AdminAlternatively, invites an existing user to join the company as an employee.System prevents a duplicate employee record for that user in the company.
5. 5
   AdminOptionally sets per-employee labour / diamond discount overrides.Effective discount = the employee override when set, otherwise the group default.

Rules & gotchas

• Employee and login account are created together (atomic).
• SuperAdmin bypasses every permission check; staff are resolved to their group via their employee record.
• Default groups (Admin, Salesman, Marketing, Customer, Supplier) already exist from company creation.

End state

Staff can sign in, scoped to their branch, with permissions resolved from their group plus any overrides.

Phase B · Operational Setup

Catalog — gold items & the daily rate catalog

Pricing staff publish the day's gold rate, then build the item catalogue. Item prices are computed live from weight, purity and the current rate.

Flow

1. 1
   Pricing staffPublishes the day's buy and sell gold rate for each purity (18k / 22k / 24k).Recorded append-only (history preserved) and broadcast live to every connected admin and customer client.
2. 2
   AdminCreates item categories (hierarchical) and item types with margin rules.
3. 3
   AdminCreates an item — classification plus gold attributes: net weight, purity, making-charge type & value, stone/diamond pricing, optional image.Search keywords auto-generated; the item can be toggled Online / Offline. Each item also has a sold-by mode — Item (a unique, individually-SKU'd piece), Quantity (counted), or Weight (by the gram); jewellery uses Item.
4. 4
   SystemComputes the price live from the current rate (see build-up below).
5. 5
   AdminOptionally bulk-imports items from a spreadsheet via preview-then-confirm.Missing item types or categories are auto-created during import.

Price build-up

Rules & gotchas

• Rates are append-only — a new rate is a new record; the latest rate drives all gold pricing.
• The purity factor is derived from the item's purity type.
• Items are catalogue templates; physical stock pieces are created later, at purchase — not here.
• An Item-sold piece of jewellery becomes its own individually-SKU'd stock record and is later sold as that exact piece, not as a quantity from a pool.

End state

A priced catalogue and a live gold rate, ready for stock to be purchased against each item.

Phase C · Procurement & Distribution

Purchase from supplier purchase

HQ buys stock from a supplier. Each invoice line is a physical piece; posting the invoice brings the goods into inventory, raises the supplier bill, and the payment settles it.

Flow

1. 1
   BuyerCreates the supplier (linked to a payable/creditor account) if new.
2. 2
   BuyerCreates a purchase invoice — adds line items, each a physical piece (SKU, weights, rate, certificate).Each stock piece is created in Saved status; totals recompute from line items on every change.
3. 3
   BuyerRaises / submits the invoice; an optional multi-stage approval workflow routes it to approvers.On final approval the document is marked complete.
4. 4
   BuyerPosts the purchase invoice (individually or in bulk).Posting is the gate that makes stock sellable.
   Saved→Available
5. 5
   SystemPosts the ledger entries — the goods enter inventory and the supplier bill (payable) is raised.
6. 6
   FinanceRecords payment against the invoice(s).Amount is distributed sequentially across linked invoices; any excess is credited to the supplier as an outstanding balance.

Stock & ledger effects

Stock: Saved→Available on posting. Stock records become immutable once they leave Saved.

Posting always raises the supplier bill on the creditor account; settling it (cash or transfer) is the separate payment step above. Accounts map to the company config (Inventory / Creditors / Cash / Tax).

Rules & gotchas

• Posting a purchase invoice is the gate that makes its stock Available for sale.
• Stock records are immutable once they leave Saved status.
• Payment distributes across invoices in order; overpayment is held as a supplier credit.
• Known issue (workflow): a stage set to "any approver" currently waits for all approvers — "any" behaves like "all".

End state

Stock is Available at HQ, the supplier bill is recorded, and it is partly or fully paid.

Phase C · Procurement & Distribution

HQ → branch stock transfer transfer

Stock is bought centrally at HQ, then distributed to the branches that will sell it. A transfer is a pure logistics movement — no money changes hands.

Flow

1. 1
   HQCreates a stock transfer — selects Available pieces, chooses the destination branch, dispatches.Pieces move to in-transit and a transit log entry records the movement.
   Available→InTransit
2. 2
   In transitPieces belong to the company but are sellable at neither branch.
3. 3
   BranchConfirms receipt.Pieces become Available and their current branch is set to the destination; the receiver and timestamp are recorded.
   InTransit→Available @ destination

Stock & ledger effects

Stock: Available→InTransit→Available   Ledger: none — a transfer is a stock/location movement only; inventory value stays within the company, so no GL entry is posted.

Rules & gotchas

• Pieces are not sellable while InTransit.
• The destination must confirm receipt before stock is Available there.
• No financial posting occurs — this is logistics, not a transaction.

End state

Stock is Available at the branch, ready to sell.

Phase D · Sales

Normal retail sale sale

A branch sells a piece to a customer. The cart becomes a sales invoice; posting marks the piece sold, bills the customer and takes payment.

Flow

1. 1
   SalesmanIdentifies or creates the customer (linked to a receivable account).
2. 2
   SalesmanBuilds the cart — selects the specific Available piece(s).Jewellery is sold by Item: the exact individually-SKU'd piece is added (quantity is one). For Quantity/Weight items the amount is validated against available stock so you can't over-sell.
3. 3
   SystemMaintains a running subtotal, tax and total as the cart changes.Gotcha: cart tax is currently a hardcoded 10%, not wired to the company tax config.
4. 4
   SalesmanChecks out.The cart converts into a sales invoice and is emptied; the invoice reference and total are returned.
5. 5
   SalesmanPosts the sale and takes payment (cash or credit).The piece is marked Sold with a sales-side pricing snapshot.
   Available→Sold

Stock & ledger effects

Stock: Available→Sold

Gold pass-through: the engine posts the goods value straight against Inventory — there is no Sales Revenue or Cost-of-Sales account. Margin is realised through inventory valuation and the making charge, not a revenue/COGS pair. Cash is never posted at invoice time: the bill always lands on the customer's account, and a separate payment settles it.

Rules & gotchas

• A cart cannot be checked out while empty. Jewellery is sold by Item — the exact piece bought is what's billed and marked Sold (not a count from a pool); Quantity/Weight amounts are validated against available stock.
• Known issue (cart): tax is a hardcoded 10% of subtotal, so the cart total may not reflect the correct rate.
• Posting marks the stock Sold and snapshots the sale price.

End state

The piece is Sold, the sale is billed to the customer's account (goods passed through Inventory), and payment is received or a receivable stands.

Phase D · Sales

Trading sale — old-gold buyback trade

The customer buys a new piece and part-pays with old gold. The old gold is valued at today's buy rate and offset against the sale; the customer pays only the balance.

Flow

1. 1
   SalesmanBuilds the sale for the new item(s) at today's sell rate — as in a normal sale.
2. 2
   SalesmanWeighs and assesses the customer's old gold — gross weight, net weight, purity.The day's buy rate for that purity is applied (not the sell rate).
3. 3
   SystemValues the old gold.Trade-in value = buy rate × net weight, captured with gross / net / pure weight and the rate applied.
4. 4
   SystemComputes the net payable.Net payable = sale total − trade-in value. The trade-in leg credits the customer's receivable, reducing what they owe.
5. 5
   CustomerPays the balance (net payable) by cash or transfer.
6. 6
   SystemRecords the old gold as an auto-generated purchase invoice with the customer as the "supplier" (linked via tradeInId).The old gold enters branch stock as purchased scrap/pieces and is tracked like any other inventory.

Stock & ledger effects

Stock: new piece Available→Sold · old gold enters as Available scrap @ branch

The customer account nets to zero: the sale bills them the full price, the old-gold trade-in — booked as an auto-generated purchase with the customer as supplier — credits it back, and the cash balance clears the rest. Goods flow through Inventory both ways, with no Sales Revenue or COGS; the trade-in leg uses the configured return-value account.

Rules & gotchas

• Old gold is valued at the buy rate (not sell), per purity.
• The trade-in is recorded as a purchase invoice (customer as supplier) so the old gold stays tracked in inventory.
• Trade-in items become locked once attached to the sales invoice.
• If the trade-in value is ≥ the sale total, the remainder is owed back to the customer as a credit / payout.

End state

The new piece is Sold, the old gold sits in branch stock, and the customer paid only the balance.

Phase E · Reconciliation

End-of-day old-gold return to HQ eod documents a gap

At close, each branch sends the day's traded-in old gold back to headquarters for consolidation, refining and resale.

Flow

1. 1
   BranchAt close, gathers the day's traded-in old gold (the scrap pieces created by the trading-sale flow).
2. 2
   BranchCreates a stock transfer of those pieces from the branch to HQ.Logistics only — no GL posting.
   Available→InTransit
3. 3
   HQConfirms receipt.Old gold is consolidated centrally.
   InTransit→Available @ HQ

Stock & ledger effects

Stock: Available @ branch→InTransit→Available @ HQ   Ledger: none (transfer).

Rules & gotchas

• Uses the generic branch-transfer mechanism — no EOD-specific logic exists.
• No system-enforced cash/cut-off reconciliation at end of day.

End state

The day's old gold is consolidated at HQ and the branch scrap pool is cleared.

Phase F · Treasury & Metal Settlement

Refine old gold → credit the metal account metal-refine target design

Accumulated old gold is melted and assayed at HQ; the actual recovered pure gold is credited to a fine-gram metal account the business can later spend.

Flow

1. 1
   SalesmanAt each trading sale, assesses the old gold per piece at its karat and records nominal fine grams = net weight × fineness factor into the branch scrap balance.Nominal is an estimate from the assessed purity; true fineness is confirmed only at assay.
2. 2
   BranchAt day close, transfers the scrap to HQ via the end-of-day return.
3. 3
   HQ treasuryAccumulates scrap into a melt lot and sends it to the refiner (melt & assay).
4. 4
   RefinerAssay returns the actual recovered fine grams (e.g. 89.8 of 91.6 nominal).
5. 5
   SystemCredits the HQ Gold Metal account with the actual recovered fine grams, clears the nominal scrap balance, and books the difference as refining loss (plus any cash refining fee).

Metal balance flow

Unit: the account holds fine (pure) grams — rate-independent, with mixed purities normalized in.

Stock & ledger effects — inventory → metal GL account

Stock: melting consumes the physical old-gold scrap — Available scrap @ HQ→Melted — so the scrap inventory falls to zero and its gold content now lives only in the grams-denominated metal account.

The debit lands on a GOLD-currency account (whose balance is grams) while the inventory credit is cash-valued — the two legs reconcile through the multi-currency exchange / balancing entry (the same primitive used in pay-in-weight). Net effect: scrap inventory → 0 and metal account + 89.8 fine g. Your worked case (≈500 g in → credit the metal GL account ≈500 g, inventory zero) is the zero-loss version of this — in practice the credited grams are the recovered figure and the small gap is refining loss.

Rules & gotchas

• The metal account is denominated in fine (pure) grams; every purity normalizes in via its fineness factor (22k 0.916, 18k 0.750, 24k 0.999).
• Nominal (assessed at the counter) is an estimate; the actual recovered grams from assay are authoritative; the gap is refining loss.
• The balance is physical and rate-independent — the buy-back margin lives in the cash rate, never in the grams.
• Melting is a stock-out: the old-gold scrap pieces leave inventory (status Melted) and the scrap pool zeroes — after the convert, the gold exists only as the metal-account balance, not as inventory.

What's built vs to build

End state

A spendable, fungible fine-gram balance at HQ, reconciled to real recovered gold.

Phase F · Treasury & Metal Settlement

Pay a supplier in gold weight metal-pay target design

When buying new stock, HQ settles the gold content from its fine-gram metal account and pays only the shortfall and labour in cash — passing customer old gold straight through into new inventory.

Flow

1. 1
   BuyerCreates the purchase invoice for the new stock; the supplier price splits into a gold-content leg (fine grams) plus a labour/premium leg (cash).Cash-only suppliers skip this flow and settle as a normal purchase.
2. 2
   SystemResolves the gold leg in fine grams (from the split invoice, or derived from the day's rate).
3. 3
   SystemApplies the prefer-metal-else-cash rule.If the metal balance covers the gold leg → settle it all in weight; otherwise settle the available grams in weight and fix the shortfall to cash at the rate.
4. 4
   SystemSettles the metal leg: debits the HQ Gold Metal account and credits the supplier's gold payable, weight-for-weight.The metal balance drops by the grams paid — the inventory decrement that prevents double-spending. Physical 999-bar hand-over weighs out fine ÷ 0.999.
5. 5
   FinancePays the labour/premium and any gold shortfall in cash.
6. 6
   SystemPosts the new stock to inventory (Available) and closes the supplier payable.

Worked example — buy 10 g, hold 7 g old gold

Buckets move in opposite directions:

Sanity check: net gold held = +10 − 7 = +3 g; cash out = 3 g × rate. You increased gold holdings by 3 g and paid cash for exactly those 3 g — the rest passed through as metal. Labour/premium, if any, is paid in cash on top.

Rules & gotchas

• Prefer metal whenever the pool covers the gold leg; otherwise metal + cash shortfall.
• The metal debit is the safeguard against double-spending the same grams.
• The shortfall is fixed to cash at the prevailing rate; physical 999-bar delivery converts fine grams via ÷0.999.
• Cash-only suppliers settle entirely in cash through the normal purchase flow.

What's built vs to build

End state

New stock is Available; the metal pool is reduced by the grams paid; the supplier is fully settled in a mix of weight and cash.