← BACK TO WORK
Flagship case study · sole engineer

VaatcoBMS

An audit-ready business system for pharmaceutical and aquaculture manufacturing—connecting stock, sales, payroll, returns, and accounting through explicit operational and financial rules.

SYSTEM SCOPE

.NET 8 · PostgreSQL · double-entry ledger · effective-dated territory · manufacturing and batch traceability

Open the live system

Inventory value

Tied to control accounts

Financial edits

Reversal-only after posting

Posting boundary

Balanced in one transaction

CORE ARCHITECTURAL LIFECYCLE

End-to-End Sales, Warehouse Dispatch & Billing Workflow

We developed a robust, end-to-end sales delivery workflow that seamlessly connects field booking, warehouse dispatch, and financial billing into a single tamper-proof lifecycle. Starting from field order booking with real-time stock hints and credit limit checks, it moves through warehouse carton packing, transport logistics assignment (Truck, Courier, Hand Delivery), and chalan dispatch—cleanly deducting physical inventory at the exact moment of shipment. Upon invoice approval, the system automatically books double-entry General Ledger journals, routes packaging expenses, and updates customer receivables through a single canonical calculation. It eliminates operational friction, prevents phantom inventory, and enforces strict role-based access control.

STAGE 01Field Sales

Field Booking

  • Real-time FG stock availability hints
  • Credit limit & outstanding due checks
  • Strict read-only role policy post-booking
0 physical stock deducted at booking
STAGE 02Warehouse

Carton Packing

  • Allocate PM shipping cartons per order
  • Visual stock readiness & staging indicators
  • Packing costs hidden from field users
0 GL impact until dispatch/billing
STAGE 03Dispatch

Chalan Dispatch

  • Automated FEFO batch allocation lock
  • Assign transport logistics: Truck, Courier, Hand Delivery
  • Cleanly deducts FG & PM stock at shipment
  • Authorized 4-party delivery chalan
Prevents phantom inventory drift
STAGE 04Finance / Admin

Invoice Approval

  • Double-entry GL booking (AR / Rev / COGS)
  • Routes PM carton costs to packaging expense accounts
  • Syncs CustomerDue via single canonical calc
Immutable ledger lock & mirror reversals
PILLAR 01 / SALES & COLLECTIONS

Eliminating conflicting dealer balances and resolving the bulk collection puzzle

Business pain point

A dealer pays one amount against several invoices. If each screen allocates that money differently, the business cannot reliably answer what is still owed—or who owns the account after a territory change.

How I engineered the solution

  • Deterministic FIFO payment replay absorbs OpeningDue first, honors pinned invoices, settles oldest-first, and carries excess as an advance.
  • One CustomerDueCalculator is reused across dashboards, ledgers, and PDF statements.
  • Effective-dated ZSM > RSM > ASM > TSM > TO geography governs access. Mid-period transfers change live access immediately while preserving period targets with the previous manager through month-end; managers may hold dual roles.
  • An audited cash commission engine uses configurable age windows, with statutory VAT withholding and a transactional double-claim lock.

Defensible business impact

A single explainable balance is available across views, bulk payments follow one repeatable allocation rule, and manager transfers preserve both immediate access boundaries and month-end performance ownership.

FAILURE-CLASS ENGINEERING

Two deep engineering debugging stories

When a system behaves unexpectedly, classify the failure before changing the data.

DEBUG STORY / 01PostgreSQL concurrency

The second save that silently failed

Consecutive Unit of Work saves raised false concurrency exceptions when a generated token was not synchronized back to the ORM.

  1. 01Inspected the save sequence and generated-token lifecycle.
  2. 02Added a BEFORE INSERT OR UPDATE trigger named trg_set_rowversion on token tables.
  3. 03Used store-generated ORM synchronization so the next save uses the database-issued token.
Verification invariant

A committed row version must match the version used by the following Unit of Work save.

DEBUG STORY / 02Failure-class thinking

The journal existed, the record did not

An accounting credit note appeared in the GL but was missing from its UI screen—a read-path classification problem, not a reason to post it again.

  1. 01Built a read-only classification script and mapped journal source modules.
  2. 02Moved tab filtering server-side and added a reconciliation banner.
  3. 03Wrote a guarded header-reconstruction script that never double-posts an existing journal.
Verification invariant

Repair the missing source record without duplicating a journal that already exists.

The system's business invariants are the center of the engineering story.

Discuss a systems challenge