Folks Inventory ERP

Folks Inventory ERP is the side of the Folks ERP suite that owns physical goods, money flowing into and out of the warehouse, and points of sale. It runs on a single SQL-Server-backed engine and is split into seven modules — five operational and two financial — that share a common authentication and approval framework.

Modules in this manual

The data flow at a glance

Every user in the system has a Login, an Employee Registration profile and one or more User Roles. Roles drive what menus and actions you see — they are not just labels.

2.1 Logging in

1. Open the FE URL in your browser. The Login page accepts Username and Password.
2. On success, you receive a JWT and are redirected to the role's DefaultPath (set on the Login row).
3. If your Login.Status is Inactive or Blocked, the system rejects you with an admin-only resolution.

2.2 Roles you'll meet

2.3 The page anatomy

2.4 Common conventions

• Codes are auto-generated. Leave the code field empty when adding — the SP fills it in.
• IsActive flag. Most master rows have this — soft-delete preferred over physical delete.
• UserID stamping. CreatedBy, CreatedDate, ModifiedBy, ModifiedDate are filled from the JWT — not from the form.
• File attachments. Use the ImagePath / FileRepository hooks; never store binary in the main entity table.

The User Management module is shared with the BackOffice ERP and is treated as locked code — both apps consume the same Login, Employee, Role and Workflow tables. This chapter is a reference, not an instruction set.

3.1 Login & RBAC chain

3.2 Tables you may need to know

The Asset module manages every physical item the organisation owns or hires. It supports four asset families — Assets, Devices, Equipment, Utilities — plus a parallel Hired hierarchy for rented items. Each family has its own master, movement and geo-tracking entities, but they share a common audit, costing and disposal model.

4.1 The four families

4.2 Sub-modules & what they own

4.3 The asset's life

The Asset Master is a three-level tree. AssetType is the broadest category (e.g. IT Hardware), AssetCategory a refinement under a Type (e.g. Laptops), and AssetItem the specific master record (e.g. HP EliteBook 840). Each Item carries one or more Unit Details — the units it can be tracked in.

5.1 The hierarchy

5.2 Adding a new Asset Type

1. Open Asset → Asset Type.
2. Click Add. Enter Type Name and Description. Leave Code blank — the SP CF_MasGen_FolksERP_Asset_AssetType_Insert generates it.
3. Save. The grid refreshes.

5.3 Adding a Category under a Type

1. Open Asset → Asset Category. Pick the parent Asset Type.
2. Add the category. The dropdown is filtered by AssetCategory_SelectByAssetTypeID.

5.4 Asset Item — the actual master

5.5 Unit Details

Some items are tracked in more than one unit (a paint drum is bought by litre but issued by can). Add each measurement unit on Asset Item Unit Details and mark a conversion factor back to the default unit.

While the General Asset path is the most common, four parallel paths exist for things that need different metadata. They share movement and geo concepts but have their own Master entity.

6.1 Devices

Devices are typically electronic / IT items with a serial number, a geographical movement history, and a contacts list (vendor, AMC supplier). Use this when you need to know which laptop was last seen at which site, on which date.

• DeviceMaster — serial, model, ownership, current site.
• DeviceType — laptop, printer, scanner, projector…
• DeviceMovement — every check-in / check-out event.
• DeviceMovementGeoLocation — lat/long captured at each movement.
• DeviceMasterContacts — supplier and AMC contacts attached.

6.2 Equipment

Equipment covers the heavy / specialised gear that a project site uses (drills, scaffolding, generators owned by the company). Mirror structure to Devices but distinct types and movement rules.

6.3 Utilities

Utilities are site-tied service-oriented assets — gensets, AC packs, water pumps. The pages mirror Devices/Equipment but emphasise SiteID over person assigned.

6.4 Hired (Rental) Assets

For things you don't own, the Hired hierarchy lives parallel: HiredCategory → HiredItem → HiredItemUnitDetails. Hired items are tied to a HiredRentedLeaseAgency (the party renting to you) and accumulate HiredRentCosting by usage period.

Every time an asset physically changes hands or location, you log a movement. The same family's Master + Movement + MovementGeo tables form a triplet. GeneralAssetMovement is the catch-all when the family is just Asset.

7.1 The movement event model

7.2 The flow

7.3 Reading the history

Use GeneralAssetMovement_Select with the AssetItemID to fetch the full chronological list. Each row references the geo log via the matching MovementID — join in to plot on a map.

Maintenance has two halves: a schedule + log half (when did we service it, by whom), and a cost half (labour, fuel, service, spares). The cost half feeds depreciation and the Asset Reports.

8.1 The maintenance schedule

1. Open Asset → Asset Maintenance. Pick the AssetItem.
2. Enter Scheduled Date, Type (Preventive / Corrective / Calibration), Owner.
3. On completion, set the Completed Date and a Remark — this closes the maintenance row.

8.2 Cost capture

8.3 Why the SP path matters

Each cost insert calls a dedicated SP that also recomputes the matching AssetValueMonitor row. Bypassing the SP (e.g. raw insert) leaves valuation stale and Reports show wrong book values.

Three closely-related sub-modules that together close the asset's life. Auditing surfaces the candidates, Value Monitor tells you what they're worth, and Disposal records the exit.

9.1 Auditing

1. Open Asset → Asset Auditing. Pick the period & auditor.
2. For each AssetItem, the SP AssetAuditing_Select shows expected location, last movement, accumulated cost, and book value.
3. Auditor sets the AuditStatus: OK, Flag for Review, Recommend Disposal.

9.2 Audit statuses (table)

9.3 Value Monitor

AssetValueMonitor stores a per-period book value per asset/unit. Two SPs maintain it: AssetValueMonitor_Insert for the original cost and AssetValueMonitor_UpdateDiminiPercentage applied each period to reduce book value. Operational events (maintenance, fuel) trigger the same recompute path.

9.4 Disposal

1. From Asset Auditing, choose Recommend Disposal.
2. Open Asset → Asset Dispose. The candidate appears.
3. Pick a Dispose Type (Sold / Scrapped / Donated / Lost). Enter buyer/agency, sale value, date.
4. Save — the SP marks the asset Disposed, freezes the value monitor row, and (if Sold) creates a journal candidate for Accounts Gateway.

Seven canned reports cover the main views auditors and finance ask for. All run from the Asset → Reports menu and accept the same standard filter set: From Date / To Date / Asset Type / Category / Status.

The Purchase module owns the Procure-to-Pay chain. Eleven sub-modules, ~42 tables, ~150 SPs and 22 Razor pages walk a request from a buyer's plan to a vendor's paid bill.

11.1 The eleven sub-modules

11.2 The end-to-end flow

Before any POR can move, you need vendors. The Vendors table holds suppliers; the InviteVendor page sends the RFQ; SubmitQuot records the response.

12.1 Adding a vendor

1. Open Purchase → Purchase Dictionary → Vendor Entry.
2. Enter the basics — Name, Trade Licence, VAT/TRN, Country, City, Currency, Payment Terms.
3. Add Contacts (multiple) — name, role, phone, email. Mark one as Primary.
4. Save. The vendor is now selectable in POR and PO screens.

12.2 Inviting vendors to quote

• Open the POR for which you need quotes.
• Click Invite Vendor. Pick 3–5 from the multi-select.
• Each chosen vendor receives an email with a link to SubmitQuot.

12.3 Submitting a quote

Vendors land on Submit Quot and key in their unit prices, delivery dates and validity. Each line maps to a POR detail line — the comparison page reads from QuoteForPurchaseOrderRequestDetails.

12.4 Comparison

The four documents on the procurement spine. Each carries the previous one's reference and adds detail.

13.1 Purchase Plan

A periodic ask of what the organisation expects to buy — stocked items, project items, services. The Plan does not commit money; it sets a budget envelope.

13.2 Purchase Order Request

The POR is what departments raise — line items, qty, target delivery, project site, distribution.

13.3 PO statuses

13.4 Purchase Work Order

Some POs spawn an internal Work Order — typically when execution involves multiple in-house steps before goods are delivered to the requester. PurchaseWorkOrder + PurchaseWorkOrderDetails.

When goods arrive, three things happen. Delivery records the receipt. Logistics records the truck, route and driver. The matching StoreEntry in the Store module increments stock.

14.1 The receipt screen

• Open Purchase → Delivery. Pick the open PO.
• Scan or key the Received Qty per line. Mismatch with PO is highlighted in red.
• Attach the LPO / Delivery Note PDF.
• A StoreEntry is auto-created for each line — stock increments visible on the Store dashboard.

14.2 Logistics

14.3 The link to Store

Once goods land, the supplier bills you. The system matches their invoice against the PO and Delivery, runs a periodic statement reconciliation, and supports two voucher types for cost allocation.

15.1 Three-way match

15.2 Statements

Each vendor has a running PurchaseStatement — an opening balance + period transactions + closing balance. Reconciliation compares this with the supplier's own statement.

15.3 Returns

PurchaseReturn records goods sent back (damaged / wrong / over-supplied). It reverses the matching StoreEntry via a negative StoreExit.

15.4 Vouchers

• Expense Voucher — costs incurred against a PO (freight, customs, demurrage).
• Income Remittance Voucher — refunds, settlements received.
• Voucher Case — group multiple vouchers under one heading for posting.

The Sales / POS module is the counter-side of Inventory ERP. Seven sub-modules, six top-level controllers and ~12–15 Razor pages drive a cashier from session-open to Z-Report.

16.1 The seven sub-modules

16.2 The seven POS tables

16.3 Top-level controllers

• PosTerminalController — terminal CRUD.
• PosSessionController — Open, Close, Active (by cashier).
• PosSaleController — NextNumber, Save, GetById, Search, Void.
• PosPaymentMethodController — payment method CRUD.
• PosLookupController — items, customers, payment methods, cashiers for dropdowns.
• PosReportController — SalesSummary, DayClose.

The day on a POS goes Session-Open → ring sales → Tender → Print → repeat → Session-Close. This chapter walks each step.

17.1 Open the session

1. Cashier logs in. POS → Open Session.
2. Pick the Terminal. The default opening balance is the previous close — adjust if a manager has dropped cash.
3. SP PosSession_Open creates the POS_Session row with status Open.

17.2 Ringing a sale

17.3 Tendering

• Cash — enter tendered amount, system calculates change.
• Card — enter auth code & last-4.
• Multi-tender — keep adding payment lines until PaidAmount ≥ TotalAmount; the difference is change.
• Void — only before tender complete.

17.4 Sale completion

On Save, the SPs run in this order: POS_Sale_Insert → POS_SaleLine_Insert (per line) → POS_Payment_Insert (per tender) → StoreExit_Insert (per stock-impact line) → StockAtStore_Update.

End-of-day is a discipline. The Cashier closes the session, the Manager reviews variance, and the Reports section gives finance a clean roll-up.

18.1 Closing a session

1. POS → Close Session.
2. Enter the Closing Balance (physical count of cash drawer).
3. SP PosSession_Close computes:

   ExpectedBalance = OpeningBalance + SalesTotal − PayoutsTotal
   VarianceAmount  = ClosingBalance − ExpectedBalance

4. If variance is non-zero, a flag is set and the Manager must sign off.

18.2 Z-Report

The Z-Report is the per-session daily summary. Header (terminal, cashier, dates), totals (gross sales, discounts, tax, net), payment-method breakdown, line-count, void count, refund count, and variance.

18.3 Manager reports

The Store module is the warehouse-floor truth. It owns ~25 tables and 100+ SPs that govern what is on the shelf, where it is, who put it there, and what state it's in.

19.1 The eleven sub-modules

• Store Master Data — store registry, location, employee assignment.
• Inventory Masters — Item Category / Type / Brand / Grade / Units.
• Stock Inward (GRN-like) — StoreEntry against PO/Delivery.
• Bin / Location — physical bin assignment, geo coords.
• Stock Balance — opening / closing qty, thresholds, refill triggers.
• Issue (Exit) — to project, site, or sale.
• Inter-store Transfer — consigner → consignee.
• Stock Count / Audit — physical vs. system; variance review.
• Damaged / Dead Stock — log + approval + disposal.
• Store Expenses & Petty Cash — operational ledger.
• Delivery Logistics — receipt note, transport.

19.2 Stock Balance — the source of truth

StockAtStore holds the per-(Store × Item) snapshot. Every Entry / Exit / Audit changes its ClossingBalanceQuantity via SPs — never directly.

Three kinds of stock movement. Each writes a row in either StoreEntry or StoreExit and updates StockAtStore via the matching SP.

20.1 Inward

• From a Delivery (Chapter 14), the system auto-creates a StoreEntry. Or open Store → Inward for an ad-hoc receipt.
• Enter Qty, Unit, Received By, Movement Type, Remarks.
• Stock balance increments on the dashboard — QtyAfter = QtyBefore + received.

20.2 Issue (Exit)

For consumption — to a project site, a department, a sale (POS already does this for you). Store → Issue.

20.3 Inter-store transfer

One physical movement = two virtual events. The consigner store posts a StoreExit; the consignee store posts a corresponding StoreEntry, linked back via VirtualEntryID.

Periodic counts catch what entries and exits miss — pilferage, breakage, mis-shelving. The Store has a formal Audit cycle.

21.1 Run an audit

1. Open Store → Stock Audit. Generate a batch via StoreAuditingBatchCODEGenerator.
2. Walk the floor with a print-out (or scanner). Count physical qty per item.
3. Enter Audited Unit Count. The SP computes variance against StockAtStore.ClossingBalanceQuantity.

21.2 Variance disposition

21.3 Damaged Stock

StoreDamagedItem rows are pending until a manager approves. On approval, a StoreExit is posted with reason Damaged; on rejection, the variance is reversed.

21.4 Dead Stock

DeadStock is for items still on the shelf but unlikely to move (obsolete, expired). Approval routes can write them off or move them to a clearance bin.

At the end of every accounting period, you freeze stock. The current closing balance becomes the next period's opening, and a snapshot is stored on StoreClossingBalanace + StoreClossingBalanceDetails.

22.1 Pre-close checks

• All Deliveries linked to closed POs are received or formally returned.
• All POS sessions are closed (no Open rows in POS_Session).
• All audit variances are dispositioned (no Flagged rows).
• Damaged / Dead Stock items are approved or rejected.

22.2 Run the close

1. Open Store → Closing Balance. Pick Period End Date.
2. The SP StoreClossingBalanace_Insert snapshots every StockAtStore row into the header + details.
3. The next period's opening balances are seeded automatically.

22.3 What is frozen

The Accounts module is the General Ledger. It is shared with the BackOffice ERP and contains a clean double-entry core wrapped in audit and reporting helpers.

24.1 Chart of Accounts

Two-level structure: LedgerGroups (Asset / Liability / Equity / Income / Expense) parent each Ledger. Groups can themselves nest via ParentGroupID.

24.2 Domain Account Master

Accounts_DomainAccountMaster is a per-domain (per-app) override of the chart, so Inventory and BackOffice can share the same physical ledgers but expose different subsets in their menus.

24.3 Sub-ledgers

Each Customer or Supplier appears as a SubLedger under the Receivables / Payables control account. This lets aged-receivable / payable reports drill from a control balance into the underlying parties.

Posting to the GL is two-step: a Transaction header + many TransactionDetails. The detail rows must balance — Σ Debit = Σ Credit.

25.1 Voucher types

25.2 Posting a journal

1. Open Accounts → Journal. Click New.
2. Header: Date, VoucherType, ReferenceNo, Narration, PaymentMode.
3. Add detail rows — each Ledger × Debit / Credit. The footer shows the running totals; Save is disabled until they match.
4. SP Accounts_Transaction_Insert writes the header; Accounts_TransactionDetails_Insert writes each line, then validates balance.

25.3 Petty Cash

The PettyCashLedger is a fast-path for small disbursements. Each row is a single line spend (purpose, amount, paid-by). Periodic settlement posts a summary JV to the main ledger.

26.1 Canned reports

26.2 MGS Export

MGS = MasGen Suite — the export pipeline that pushes posted transactions to an external GL or BI tool. Four tables drive it:

• MgsExportHeads — export categories.
• MgsExportMapper — maps a posted transaction to an export head, with credit/debit amount and edit flag.
• MgsExportReleaseMaster — a release batch (header).
• MgsExportReleaseLog — append-only log of what was sent.

The Accounts Gateway is the bridge that pushes Customer- and Supplier-side transactions from operational modules (Sales, Purchase, Payments, Reservation) into the Accounts ledger. It avoids cross-module coupling and gives finance a single inbox of postings to review.

27.1 The three SPs

27.2 The Gateway page

27.3 The post action

1. Accountant clicks Post. The Gateway candidate is wrapped in an Accounts_Transaction with the appropriate VoucherType (RV for customer, PV for supplier).
2. Detail rows are produced: e.g. customer payment → Cash Dr 259.88 / Sales Cr 247.50 / Tax Cr 11.88.
3. The Gateway row is marked Posted with the new TransactionID.
4. Released to Accounts_ReleaseLog for audit.

Every long-lived row carries a status. This chapter is a quick-look table.

28.1 Notifications you'll see in the Inbox

• POR submitted by buyer (to approver).
• PO ready for approval / partial delivery alert.
• Stock below threshold (reorder suggestion).
• Audit variance flagged for manager review.
• Accounts Gateway has un-posted candidates.

29.1 Top issues