Folks Inventory ERP — User Manual

Folks Inventory ERP is the inventory-and-trade member of the Folks ERP suite. Where the back-office edition owns HR and the project edition owns delivery, this one owns physical goods, the money that flows in and out of the warehouse, and the points where you sell. It is a single .NET 9 Blazor Server application backed by one SQL Server database (MasGen_InventoryERP_DevV4), shipping eleven modules under a single warm "clay" theme.

What's new in v4.0

You never see this layer, but it explains why the app behaves the way it does. Folks Inventory ERP is deliberately SQL-first: there is no ORM and no business logic in LINQ. Every read and write goes through a named stored procedure, and every screen is plumbed through the same six tidy layers.

The app opens on a split-screen login — a warm pitch panel on the left, your credentials on the right. Sign in with your username and password; on success the system resolves your role, builds your menu from the privileges granted to that role, and drops you on the dashboard.

How role-based access works

RBAC is data-driven, not hard-coded. A role is granted privileges on menu pages; the sidebar is literally a query of "which pages may this user's role see". Add a page to a role and it appears; revoke it and the page — and its menu entry — disappear.

Almost every screen is one of three shapes. Learn the three and you can drive a page you have never opened before.

The eleven modules group into six pillars. This is the mental model the rest of the manual follows.

The dashboard is the first thing you see after login and the page you return to between tasks. It rolls up the whole platform into a grid of KPI cards and a few working lists, so you can spot a problem — a store running dry, a procurement waiting, a slow POS day — without opening a single module.

folks-inventory / home

Reading the KPI cards

A store is any place stock physically lives — a warehouse, a shop floor, a kitchen, a virtual holding bin. Everything downstream (entries, sales, transfers, balances) is scoped to a store, so this is the first master you set up.

Creating a store

folks-inventory / store

The Store Master lookups

An item is a thing you stock and move — a product, ingredient or consumable. Items are described once and then stocked into many stores. Classification (brand, category, grade) and a unit of measure make reporting and reordering meaningful.

Store Operations is where quantity actually changes. Every operation posts a movement against StockAtStore; the balance you see is never typed, it is the sum of movements. This is the single most important idea in the warehouse.

A Store Entry adds quantity to a store. It is what a delivery becomes when goods arrive, but you can also raise one directly for an opening balance or an internal find. Pick the store, the item, the quantity and unit, optionally a reference (PO, delivery note), and post.

• Choose the receiving store and the item.
• Enter quantity, unit and (optionally) the unit cost and a reference.
• Post — a positive movement is written and the balance increases immediately.
• The item's on-hand at that store goes up by the entered quantity on Stock Balance.

A Store Exit removes quantity for a reason other than a POS sale — issuing to a kitchen, consuming internally, writing off. It is the mirror of an entry: pick store, item, quantity, reason, post a negative movement.

Two pages handle the exceptions. Store Returns brings stock back (a customer return, a reversed issue) — a corrective movement. Damage Entry writes stock off as no longer sellable, recording the reason; damaged quantity leaves the sellable balance but stays visible for loss reporting.

Stock Balance is the truth screen — the live on-hand quantity per item per store, computed from every movement. It is read-only by design: you change the balance by posting an operation, never by editing the number.

folks-inventory / stockbalance

A stock audit reconciles the system balance against a physical count. You generate an audit batch (which stamps an STRAUD… code), enter the counted quantity for each item, and the system computes the variance. A shortfall is treated as a loss.

• Generate an audit batch for a store — it snapshots the current system quantities.
• Enter the physical count for each item.
• Variance = physical − system is shown per line.
• A negative variance auto-creates a Damage row linked to the audit id, so the loss is both recorded and written off in one step.

Three connective pages close out Store Operations:

A transfer moves stock from one store (the consigner) to another (the consignee) in a single governed action. It is a dual-write: an exit at the source and an entry at the destination, both stamped with the same transfer code so the two legs always reconcile.

Procurement in Folks Inventory ERP is not one form — it is a tracked pipeline. A plan is created from a requisition and then walks six stages, each on its own page, each stamping a live status. A buyer can always see exactly where any item sits.

Vendors are the suppliers a tender is floated to and a PO is awarded to. Capture the trading name, contact and email — only vendors with an email are eligible to quote, so the compare step has someone to ask.

The plan is the spine of procurement. Start it from a Store Item Requisition — picking the requisition auto-fills the item, requested quantity and unit, and links the plan back to the request. Set the planned quantity and save; the plan enters the pipeline as New Request. From the plan list, Generate Indents advances it.

folks-inventory / purchasedashboard

After indents are generated, Create Tender Request (/createtenderreq) bundles the indented lines and floats them to active vendors — the plan moves to Tender Created. Compare Quotes (/comparequot) then captures one quote per eligible vendor and ranks them, so the cheapest compliant offer is obvious.

Process PO (/processpo) awards the order to the lowest quoted vendor, creating a PurchaseOrder and moving the plan to Delivery Processing. Delivery (/delivery) then processes logistics, raises the delivery note and receives the goods — which posts a Store Entry and lands the plan on Delivered.

Purchase Monitor (/purchasemonitor) is the control tower — every plan with its current stage, so nothing stalls unseen. The Purchase Dashboard (/purchasedashboard) rolls procurement into KPIs: open plans, spend, vendor mix, delivery cycle time.

The point-of-sale module sells items straight out of a store's stock. A sale is rung inside an open session on a terminal, paid with a payment method, and recorded as a PosSale — which decrements stock and posts the takings. At end of shift, a day-close reconciles the drawer.

The sale screen is a fast till: search or scan items into the cart, adjust quantities, take payment. VAT is computed on the subtotal, and confirming the sale decrements each item from the session's store and writes the PosSale with its lines.

folks-inventory / possale

Assets are durable items — ovens, vehicles, laptops, fixtures — tracked for their value, location and condition rather than their sellable quantity. The module is sixteen pages: registers, classification lookups, the place hierarchy, and the lifecycle pages (maintenance, audit, disposal). It opens on an Asset Dashboard of KPIs and quick actions.

The core register is Asset Item (/assetitem) — each asset carries an auto code (AST0004), a name, a category, a value per item, an item count and a purchase date. Asset Category and Asset Type classify them for reporting.

Each register shows names, not raw ids — type, ownership and contact are chosen from dropdowns and displayed as labels, with a derived code (DEV0001, EQP0001).

Assets live somewhere. Projects (/projects), Project Sites (/projectsites) and Location Details (/locationdetails) form the place hierarchy that an asset, a store or a device can be assigned to.

The Accounts module is a proper double-entry ledger: a chart of accounts grouped into ledger groups, balanced journal vouchers, a cash book, cheques and bank charges, and a balance sheet. Stock and trade events have a money side, and this is where it is recorded.

The Account Master (/accountmaster) is the chart of accounts — each account has a derived code (ACC0001), a name, a ledger group, a type (Asset, Liability, Income, Expense, Equity) and an opening balance. Ledger Group and Sub Ledger organise it.

A transaction is a balanced voucher: total debits must equal total credits before it will save. The entry screen lets you add as many lines as needed, picking an account per line and a debit or credit amount, with a narration.

User Management is the security base of the whole suite — users, roles, the menu tree, and the privileges that map roles to pages. Everything else in this manual is visible only because UM grants it.

The employee register is the people directory the rest of the app draws on — store managers, auditors, cashiers, buyers are all employees here.

The audit log is the trail of who did what and when across the platform — a read-only report you filter by user, action and date. It is the page you open when you need to answer "who changed this?"

Procurement pipeline status

Stock state

Cheque status

For implementers: every screen maps to tables and procedures by a consistent naming convention.

Glossary

Movement

A single signed change to stock — every entry, exit, sale, transfer leg, return or damage.

StockAtStore

The live on-hand quantity per item per store, computed from movements.

Requisition

A store's request for an item and quantity — the start of procurement.

Plan

The procurement record that walks the six pipeline stages.

Indent

The internal authorisation to buy, generated from a plan.

Tender

A request for quotes floated to eligible vendors.

Consigner / Consignee

The sending / receiving store in a transfer.

Session

A cashier's POS shift on a terminal, opened with a float and reconciled at day-close.

Period close

A snapshot of every stock balance into the closing-balance detail.

RBAC

Role-based access control — pages shown per role via seeded privileges.

DevSP

A workflow stored procedure that performs a multi-step action in one transaction.