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

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.

A cash purchase settles the payable at posting rather than in a separate payment step. Accounts shown map to the company config (Inventory / Creditors / Cash / Tax paid).

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, recognises revenue and takes payment.

Flow

1. 1
   SalesmanIdentifies or creates the customer (linked to a receivable account).
2. 2
   SalesmanBuilds the cart — adds Available pieces.Requested quantity is validated against available stock; over-ordering is prevented.
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

Marking the piece Sold also moves its cost out of inventory to cost-of-sales.

Rules & gotchas

• A cart cannot be checked out while empty; quantities are validated against 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, revenue is recognised, and payment is received (or a receivable is raised).

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 receivable nets to zero: you take in old gold (an asset) plus the cash balance, and give out the new piece. The trade-in value posts through the configured return-value sales 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.