Receipt Entry

Sequential list of generated dispatch notes. Showing today's challans by default — adjust the dates or click "Show All" to widen the range.

Dispatch Register

Every milk dispatch challan — party dispatches and stock transfers — newest first. Use the printer button to print or download any challan. (Plant Heads see challans from all plants.)

Milk Dispatch

Create dispatch challans and import consolidated orders for raw/processed milk. Billing is handled in the shared Accounting & Billing module.

Milk Challans

Product Dispatch

Create product dispatch challans for finished milk products (paneer, ghee, etc.) using the product master & SKUs.

Recent Product Challans

Create Dispatch Challan

Shift Close — Milk Stock Book

Enter tank-wise physical readings at handover and close the shift. A closed shift is locked — corrections need an admin adjustment.

Diversions & Returns

Location: —

Acknowledge milk diverted to production with your own final figures — once acknowledged, YOUR figures (not the dairy accountant's entry) are what count.

Production Returns

Skim and cream returning to stock re-enter the shift's balance; butter is balancing-only and does not re-enter stock.

Milk Stock Report

Shift-wise mass-balance for one location: opening, collection, diversions, dispatches, closing, and loss/gain.

New Product Dispatch Challan

Product Challans

Generated product dispatch notes, most recent first.

Pre-fill Orders from Consolidated Sheet

Choose a standard consolidated Excel file (`.xlsx`, `.xls` or `.csv`). The app will dynamically match columns, filter out non-milk items, extract quantities for BM, CM, and Skim Milk, and queue them for instant challan generation.

Pending Drafts Queue

Batch imported orders from Excel sheet are queued here as drafts. Use Edit & Finalize to fill quality metrics individually, or tick parties and Finalize Selected to assign serial numbers in one click.

Import Product Orders from Excel

Upload a product order sheet (`.xlsx`, `.xls` or `.csv`). The app matches each row against the party master and product master, then queues the recognised rows as product challan drafts — grouped one draft per party. Review and finalize each draft to assign its challan number.

Audit Activity Logs

Securely tracks all operational activities user-wise, including logins, modifications, challan generations, and settings updates.

Login History Report

Successful and failed sign-in attempts captured per user, with the originating IP address and device. Use this to spot logins from unexpected locations.

Currently Logged In Users

Live sessions active right now — one row per signed-in device, with login time, originating IP and browser. Sessions clear on logout or server restart.

Test as user

Open a milk or order portal account exactly as that user sees it. The user's phone is never touched — no OTP is requested and no SMS is sent. You confirm with your own PIN on the portal, and every write you make while testing is recorded against your name.

Live test sessions

Audit trail — append-only; these records cannot be edited or deleted from the app

Your impersonation PIN

This PIN is yours alone — it activates a test session and is accepted nowhere else in the system. It will never log anyone in on a public login page. You cannot see or set another admin's PIN.

Attendance

Checkpoint attendance for security staff. Each check is two live photographs taken in-app plus a GPS reading; the server computed the distance and judged it against this plant's geofence. Refused attempts are recorded too and shown on the cell they were aimed at.

Map Replay

Replays a guard's (or a plant's) attendance checks in the order they happened. Rejected attempts plot too — they are often the ones worth looking at. Click any marker for that check's full detail.

Leave requests

An approved day is excluded from that guard's compliance denominator — it counts as neither present nor missed. Decisions are recorded permanently against the request.

Compliance report

One row per attendance day. For a duty that crosses midnight the whole night reports under the date it started. Click a row to see every checkpoint of that day and what happened to it.

Problem Reports

Bug reports, error reports and feature requests sent from the staff desk, the milk field portal and the customer order portal. Voice notes play inline; the diagnostic bundle downloads as JSON and can be handed straight to a Claude Code session.

Receiving OCR Audit

Every challan received via the photo-first OCR-assisted entry flow: what the camera read off the slip vs. what the operator actually typed, for each audited field. The entered value is shown; a flagged field also shows the OCR reading in red next to it.

Manual Entries Report

Milk-collection entries in two categories: Hand-keyed — no photo/OCR evidence trail at all, either a whole shift keyed in with no photo, or extra rows hand-added into an otherwise photographed shift (tracked reliably from 5 Jul 2026 on; earlier entries are excluded and shown as a count, not guessed) — and DPU manual (*) — a row on the photographed shift-summary the printer itself marked with an asterisk, meaning the PMC operator rejected the milk-analyzer's automatic reading and keyed FAT/SNF in by hand at the machine (tracked since digitization launched, 29 Jun 2026). Occasional DPU-manual use is legitimate (analyzer faults); the point of this report is to surface PATTERNS of overuse, not single rows.

OCR Audit Report

Every Nth saved shift summary is silently re-read in the background with a second model (Gemini Flash); a disagreement escalates all photos to Gemini Pro as arbiter and alerts admins on Telegram. Detection only — saved collection data is never changed. Use the match rate below to decide whether to sample more (lower N) or less (raise N) often. The report starts from the day this feature shipped — there is no backfill.

OTP Audit Report

Every OTP request and verify attempt, across the Order and Milk portals — measurement only, this never changes OTP or login behavior. Use it to see SMS cost drivers (per-user counts, repeat requests) and whether MSG91 accepted or rejected each send.

Current Rates

Active rates per party. Rows (parties) and columns (milk type / product) are ordered by sale value over the 30 days ending on the chosen date — biggest first. Pick a past date to see the rates that were active then.

Milk Rates

Product Rates

Tanker Capacity Alerts

Milk-tanker dispatches where one or more compartments were filled beyond ±80 kg of the optimum capacity recorded for that tanker at the time of dispatch. Each row is one off-optimum compartment.

Milk Sales Report

Party-wise milk billed for the selected period — quantity, quality-weighted FAT/SNF, blended rate, and total amount. Based on billed challans (final invoice, else Proforma) within the date range; challans not yet billed aren't included.

Busy Rates

What we actually charged each party for each milk product, read out of the Busy invoice lines. Each cell is the rate on the most recent date that party bought that item; the column header carries the min / median / max across every party, so a cell reads against its own column.

Product Sales

Everything sold, item by item, from the Busy voucher store. Saksham does not record these sales yet, so Busy is the only source. Sale returns net off.

Type quantities directly into the grid to add or edit an order — changes save when you leave the box. Milk columns: BM Buffalo · CM Cow · SM Skimmed · MM Mixed.

Recurring delivery plans for parties. Active subscriptions auto-create the daily order into the Customer Orders queue (also runs on a timer). Customers can manage these from their portal.

MCC Collection — Dock Sample Report

Upload one or more chilling-center dock-wise sample reports — they may be from different MCCs, dates and shifts. The MCC, date and shift are read from each report. Review the queue and remove any you don't want, then import them all together (up to 62 files at once).

Recorded MCC Collections

What each chilling center received, summarised per shift. Pick All plants (combined) to see every center together, or click a shift for the PMC-wise detail.

PMC Collection — Collection Summary

Upload the PMC collection summary export (may contain many dates / both shifts). The system auto-creates or updates each PMC found and tags it to the detected MCC — you'll see how many PMCs will be added vs updated before saving.

Recorded PMC Collections

What each primary center reported, summarised per shift. Pick All plants (combined) to see every center together, or click a shift for the PMC-wise detail.

Sour Milk — New Dock Entry

Milk found sour or adulterated at the dock is recorded here — the legacy dock software does not capture it. It stays out of the main collection figures. The PMC operator sees the quantity and milk type (and, if returned, that it was returned) — never the grade or end use.

Import Past Data (Excel)

Columns expected: Date, PMC Code, PMC Name, Quantity (L), Milk, Grade, Use. Milk accepts Cow/Buffalo (or C/B, case-insensitive) and is required on every row — anything else is a per-row error, never guessed. PMCs are matched by code first, then by exact name. Download the sample to see the expected format.

Recorded Sour Milk

MPI Staff

MPIs (Milk Procurement In-charges) are organisation field staff. An MPI logs into the milk portal with their mobile number (default password: last 4 digits) and can work as any PMC currently allotted to them — upload, farmers, dock, reports, account. Attendance, leave and salary come in a later HR release.

Allot PMCs

Pick an MPI, then tick the PMCs that should be with them. Ticking a PMC that is with another MPI reassigns it; unticking one of this MPI's PMCs leaves it unallotted. Records are date-ranged as before — nothing is rewritten for untouched PMCs, so the full history stays for incentive calculations.

Allot Rate Cards

Pick an MPI or Sr MPI, then tick the purchase rate cards they may apply from the MPI portal (only on PMCs in their scope). Unticking revokes a card from today — rates they already applied stay untouched. A card allotted to a Sr MPI does not pass down to the MPIs under them; allot it to each MPI separately. Records are date-ranged, so past holdings stay answerable.

Allotment History

Reporting Changes

Every change to who an MPI reports to, newest first — kept permanently because incentive calculations depend on this history.

Farmers

Correct a farmer's phone number, delete a wrongly-created farmer (only once they have zero collection/payment records), or shift a farmer's purchase records to the correct farmer — e.g. when a shift-summary OCR misread a farmer code. Every change here is permanently logged: who, when, and what changed.

The farmer logs in to their own portal with this mobile number + an SMS OTP — there is no password or PIN to manage.

No edit limit here (office/admin) — the PMC operator/MPI portal caps their own edits at 3 and does not reset when you edit here.

Deleting a farmer does not reserve their code — if this PMC ever assigns code to a genuinely new/different farmer, future digitized shifts will attach to this same record (invisible in farmer lists once deleted). If that happens: Reactivate + rename this record if the new collections really are a new farmer who should keep this identity, or use Shift Purchases with this farmer as the source if they actually belong to some other existing farmer. A watchdog alert flags this automatically.

OCR digitization safeguards

New farmer codes OCR encountered during digitization (approved as a new farmer, or corrected as a misread of an existing code — a retaken photo never reaches this list), and every case where a re-read name disagreed with the name already on file (the stored name is never overwritten by OCR).

Collection vs Receipt Differences

Compares each PMC's reported collection against what the MCC received — one row per PMC per shift, sorted by PMC code, split into cow, buffalo and combined. Toggle between this page's own calculation and the one the MPI/operator reads on the milk portal; the rows are the same either way. Use Show calculation on a row to trace every figure back to the PMC sheet and the dock report.

Milk Chilling Centers (MCC)

PMC Centers

PMCs are created automatically from uploads. Reassign a PMC to a different MCC or disable it here.

Data Issues — implausible shift dates

Digitized shifts dated more than 60 days in the past, or dated in the future — usually an OCR misread of the printed date, not a real transaction. Review each row against its farmer-row count before deleting; this is a genuine, irreversible hard-delete. Admin/DB-admin only.

Digitize a shift summary

Upload the photos of a PMC shift-summary printout, one at a time. Photograph the top first — the center, date and shift are read from it — then add each following section one photo at a time, ending with a clear photo of the totals block at the bottom. Check the readings, review the rows, then save. Not tied to any one PMC, so you can digitize any center's sheet here.

Confirm & Save

Shifts a PMC operator couldn't import (out-of-range FAT/SNF, hand-added rows, totals mismatch) and escalated. Open one to see the photos and the grid as the operator left it — you can correct any cell, then approve (imports it) or reject with a note the operator sees.

Upload a rate card

Upload a fat×SNF rate file (.xlsx). Pick the milk type and give it a short name you'll recognise later (e.g. 324 for cow, 860 for buffalo). Cow milk is fat 2.2–5.3; buffalo is 5.4–15.

Apply a rate to PMCs

Choose a saved rate card, the date it becomes applicable (leave the end date blank for open-ended), and the PMCs it applies to. Cow and buffalo are applied separately, so each can change on its own date.

Saved rate cards

PMC dock factors

Additive cow/buffalo FAT/SNF corrections applied to the dock reading before the MPI-visible comparison, per PMC — persists until changed. Steps of 0.05, range −1.0 to +1.0. Composes with the per-shift factor set from the Dock Approvals screen. Unrelated to the Milk Stock Book's shift-closing-sheet Cow/Buff Fat/SNF Adj.

Needs approval — the default — is every shift with at least one PMC still undecided, whether none have been approved yet or only some have. It is the same test the daily digest counts with, so this list and that number never disagree. One item per plant+shift dock upload, but each PMC is approved individually. A PMC becomes approvable once its shift summary is digitized — until then there is nothing to compare against and it stays in "awaiting digitization". Approving a PMC releases that PMC's comparison to its MPI and freezes its factors; the rest of the shift is unaffected.

PMC Ledger — Milk Payable

What the MCC owes each PMC. Milk received (field-collected farmer total) plus the PMC's commission builds up the payable; payments to the PMC draw it down. Milk values come straight from the digitized shift summaries.

Record Payment to PMC

Pays the PMC selected above. The payment reduces the PMC's running payable.

All PMC Payables

Every PMC's balance from the same engine as the Trial Balance's PMC Payables (Control) line — the total here always ties to that control account.

Select a PMC to view its milk-payable ledger.

Dock Verification & Shortfall Penalties

Field-supplied (portal) vs received at the MCC dock, per shift. Where the dock is short, a penalty is suggested from the rule — review and approve (or adjust) to deduct it from the PMC.

Payment Register — Test & Debug

Run the real Payment Register pipeline against any PMC and cycle without touching what operators and MPIs see. A test run is computed by the same code an operator hits — same OCR, same photo stitching, same header and completeness gates, same reconciliation — but no register and no reconciliation run are written, so nothing appears on the Payment Register screen, the operator portal, or the office notification bell.

Every run below — real operator uploads and admin tests alike — can be downloaded as a self-contained debug bundle.

Test upload TEST ONLY — never visible to operators

Test result

Run history

Every commit attempt since v2.150.0 — successes and failures, operator uploads and admin tests. A blocked attempt used to leave no trace at all; each row now carries its outcome and reason codes.

Payment Register Reconciliation

The DPU's own end-of-cycle PAYMENT REGISTER receipt (uploaded by the PMC operator), reconciled against Saksham's digitized shift data for the same PMC and cycle — to catch a payment posted to the wrong farmer when OCR misread a code. Read-only; corrections stay manual accountant work.

Uploaded Registers

Record Payment / Credit Note

Party Ledger

Busy comparison

Busy is the book of record until 31 March 2027; both systems run in parallel until then. This is where a ledger is decided one counterparty at a time — Busy's figure, Saksham's, and the difference. Most of Busy has no Saksham counterpart yet, and that is expected, not an error rate: Saksham does not hold most of what Busy does. Nothing here posts, and setting a cutover date moves no money — it changes only which book this screen expects to be right.

Combined ledger

One ledger — a party, a PMC or a plain GL account — with Busy on one side and Saksham on the other. Set a cutover date and the two splice into a single running statement: Busy's entries up to the day before it, Saksham's from it onward. Nothing here posts. Setting a cutover moves no money — it changes only which book this screen treats as authoritative.

Bank Import

Upload the bank's own statement and match every transaction to a ledger. Rows you don't match stay in Suspense (so the bank ledger still ties to the bank's closing balance) and wait in the queue. Each choice is remembered, so the next statement fills itself in.

Outstanding & Aging

Net amount owed by each party, bucketed by age (oldest first). Open a party's ledger to see the line-by-line breakdown.

Payment Terms & Due

Every account that owes money, read through that party’s own payment terms. Set terms on a party in Master Data → Party Master; an account with no terms, or with no Saksham party at all, is still listed here with its balance and its age — it just gets no due date.

Container Stock by Party

Returnable containers held by a party. Milk-can movements come automatically from finalized challans (cans dispatched) and receipts (empty cans returned). Outstanding = opening balance + dispatched − returned.

Outstanding Overview

Bank & General Ledger

Bank, cash and other ledger accounts, their running statements, and a trial balance. Receipts you record post here automatically (Dr Bank / Cr Party); sales post Dr Party / Cr Sales. Parties' own ledgers stay under Receipts & Ledgers.

User Rights & Access

See who has which rights and grant or revoke them per user: editing locks, audit-log visibility, draft deletion, back-date limits, and which parts of the system each account can reach (Milk Dispatch, Product Dispatch, Accounting & Billing, Receipt Entry, Reports). Admin and Database Admin only.