Village Dairy Co-op Milk Collection & Quality-Based Payment App (Java, Room, MVVM)

MilkBook is an offline-first Android app, written in Java with Room and MVVM, that runs the daily accounts of a village dairy co-operative society. In the Anand-pattern structure that Tamil Nadu's Aavin federation builds on, a primary village society collects milk from member farmers twice a day, tests fat and SNF with a milk analyser, and pays each pour by a published rate card. The clerk notes each pour in a register, reads a printed rate chart and multiplies by hand — hundreds of entries a day, tallied at night, with disputes every fortnight.

MilkBook records each collection (member, shift, weight, fat %, SNF %) in a few taps, computes the payment with the two-axis formula used across Indian dairy co-operatives — paying separately for the kilograms of fat and SNF the pour contains — and flags suspicious readings (SNF far below the society's normal band, usually added water) for a supervisor re-test. Rate cards are versioned with effective dates, so a federation revision applies only from its date and past pours keep the rate actually in force. Members get a passbook of pours, quality and payments; the clerk gets shift totals, fortnightly vouchers and CSV export for the union office.

The project is scoped as a six-week, two-member mini project for the University of Madras BCA 320S61 Mini Project (Professional Competency Skill) in Semester 6, built with the profile's Java stack — Java 17, the Android SDK, Room and WorkManager — with MPAndroidChart as a labelled industry-standard extra.

A primary dairy co-operative society pays its member farmers twice a day, per pour, on measured fat and SNF — yet the entire calculation runs on a paper register and a printed rate chart. Hundreds of manual lookups and multiplications a day produce arithmetic errors and fortnightly payment disputes; a rate revision invalidates the printed chart mid-fortnight, so pours near the changeover are priced inconsistently; and suspicious quality readings are discovered only at the chilling centre, after the milk has been pooled. Members have no way to check their own history, and the secretary cannot answer "what did I get paid for the first shift of the 4th?" without flipping through pages.

The problem is to build an offline-first Android application that records every pour with its quality reading, computes the two-axis payment from the rate card actually in force on that date, flags implausible readings for re-test before the milk leaves the village, and gives members, clerk and secretary each an accurate, searchable view of the same numbers — without storing any government identity numbers.

Abstract

Village dairy co-operatives pay members per pour, on measured quality, twice a day — one of the most arithmetic-heavy small ledgers in rural India. When the calculation lives in registers and printed charts, errors are common, rate revisions confuse old entries, and suspect readings surface only when the chilling centre rejects a lorry. This project delivers MilkBook, an offline-first Android app in Java that records each collection, computes two-axis payments from effective-dated rate cards, flags anomalous readings for re-test, and produces member passbooks, shift totals and CSV reports. It is built with Room on SQLite, MVVM (ViewModel + LiveData), Material Components and WorkManager.

Introduction

We studied the morning shift of a fictional society — Sri Varadha Milk Producers' Society near Kanchipuram (name invented for the report) — with about 180 members pouring milk across two shifts. A milk analyser prints fat and SNF, but the clerk still writes weight, fat, SNF and amount in a bound register and prices it from a printed chart. On rate-revision days the old chart is withdrawn and a new one pinned up, producing mixed-rate totals; members dispute fortnightly payments; reconstructing any past day means flipping pages.

Existing system and its limitations

• Paper register per shift — transcription slips, no backup, no search.
• Printed rate chart — one wrong lookup silently over- or under-pays a member.
• Manual arithmetic for hundreds of pours, tallied late at night.
• Rate revisions applied by replacing the chart, so pours near the changeover are disputed.
• Quality anomalies surface only at the chilling centre, after the milk has left.
• Fortnightly statements are handwritten; members cannot check their history.

Proposed system

• Member enrolment (code, name, phone, default cattle type — no Aadhaar or government ID numbers).
• Collection entry in one screen: member, shift, weight, fat %, SNF %, validated against plausible bands.
• A two-axis payment engine: kg fat = weight × fat % ÷ 100 and kg SNF = weight × SNF % ÷ 100, each priced by the rate card in force on that date for that cattle type, plus quality bonuses.
• Versioned rate cards with effective dates; every collection references the card that priced it.
• A quality-flag workflow: readings outside the SNF band are flagged, re-tested, and cleared or deducted, with history kept per member.
• Member passbook, shift summaries, fortnightly vouchers, CSV export/import and daily charts, plus a WorkManager reminder at the evening shift.

Feasibility study

• Technical: Java (220C4A) is the programming core of the Madras CBCS BCA syllabus; Room, MVVM and WorkManager are the standard offline stack. The engine is a few arithmetic lines plus an indexed lookup.
• Economic: runs on the clerk's existing Android phone; no server, data plan or licence cost.
• Operational: the entry screen mirrors the register the clerk already fills, so training takes minutes.
• Schedule: six weeks — one study, one design, two build increments, one testing, one report and demo.

In scope

• One primary society with 100–250 members, two daily shifts, cow and buffalo milk lines.
• Roles: Clerk (entry), Secretary/Supervisor (rate cards, flags, reports), Member (read-only passbook on the same device).
• Member records with a society-issued code — no Aadhaar or government ID numbers.
• Collection entry with analyser readings, automatic amount computation, and correction with an audit note.
• Rate cards per cattle type with effective dates, fat rate (₹/kg fat) and SNF rate (₹/kg SNF), and optional quality-bonus rules.
• Quality flags with re-test resolution; fortnightly vouchers; CSV export/import; charts of daily quantity and average fat.

Out of scope (v1)

• Direct money transfer to bank accounts (vouchers are printed/CSV; a UPI payout link is future scope).
• Bluetooth/serial integration with specific milk-analyser hardware (CSV import covers it generically).
• Union- or district-level cloud dashboards and multi-society sync.
• Cattle feed inventory, loan ledgers and veterinary records kept by some societies.

The project follows an incremental SDLC model: a thin end-to-end slice (member + collection + payment) is finished first, then features are added in increments, each ending in a testable build reviewed by the guide. This fits a six-week mini project because the risky part — the payment engine and rate-card lookup — is built and verified early.

Team split: Member 1 owns members, rate cards and the passbook/reporting modules; Member 2 owns the payment engine, quality-flag workflow and tests. Both write their own chapters and answer the viva for their modules.

Testing approach: JUnit unit tests pin the two-axis formula and the effective-date selection against worked examples; Room DAO tests run on an in-memory database; Espresso covers one end-to-end entry flow. Black-box test cases for each screen are recorded in a table (ID, input, expected, actual, status).

MilkBook is a classic three-layer Android app:

1. UI layer — Activities and Fragments with Material Components; every screen observes state from its ViewModel; no business logic here.
2. ViewModel + LiveData layer — survives rotation, exposes members, collections and totals as LiveData, and calls the repository only.
3. Data layer — a repository over Room (SQLite): entities, DAOs with indexed queries, and database transactions for multi-table writes such as a collection with its payment line. WorkManager runs shift reminders; a small CSV exporter reads the same DAOs.

The payment engine is a pure Java class (no Android imports) so it is trivially unit-testable: given weight, fat, SNF and the effective rate card, it returns the amount; given a date and cattle type, a DAO query selects the card with the greatest effectiveFrom not after that date.

flowchart LR
  C[Clerk / Supervisor / Member] --> UI[Material screens]
  UI --> VM[ViewModel + LiveData]
  VM --> REPO[Repository]
  REPO --> ENG[Payment engine: two-axis amount]
  REPO --> DAO[Room DAOs]
  DAO --> DB[(SQLite)]
  REPO --> CSV[CSV exporter / importer]
  WM[WorkManager] -->|shift reminder| UI

ER diagram

erDiagram
  MEMBER ||--o{ COLLECTION : pours
  RATE_CARD ||--o{ COLLECTION : "prices"
  COLLECTION ||--o{ QUALITY_FLAG : "may raise"
  MEMBER ||--o{ PAYMENT : "is paid by"
  MEMBER ||--o{ RATE_CARD : "cattle type"

  MEMBER {
    int id PK
    string code UK
    string name
    string phone
    string defaultCattleType
  }
  RATE_CARD {
    int id PK
    string cattleType
    date effectiveFrom
    real fatRatePerKg
    real snfRatePerKg
    real bonusPerLitre
  }
  COLLECTION {
    int id PK
    int memberId FK
    date shiftDate
    string shift
    real weightKg
    real fatPct
    real snfPct
    int rateCardId FK
    real amount
  }
  QUALITY_FLAG {
    int id PK
    int collectionId FK
    string reason
    string status
    real retestFat
    real retestSnf
  }
  PAYMENT {
    int id PK
    int memberId FK
    date periodStart
    date periodEnd
    real grossAmount
    real netAmount
    date paidOn
  }

• UPI payout integration so fortnightly vouchers can be paid and reconciled electronically.
• Bluetooth integration with common milk-analysers and dot-matrix printers to remove even CSV as a middle step.
• Union-level cloud sync with per-society dashboards for the bulk milk cooler and lorry planning.
• Bilingual UI (Tamil/English) and voice prompts for low-literacy entry contexts.
• Route and can management for pour collection centres, and an animal-health advisory module for members.