Anna Darpan state-PDS integrations — what weighbridge teams need to know
A walk-through of the Anna Darpan public-distribution-system portal integration — the workflow, data fields, credentialing, and four pitfalls from live state-civil-supplies deployments.
For state civil-supplies officers, IT contractors, and weighbridge vendors
If you operate a weighbridge that handles state public-distribution-system grain — wheat or rice moving from procurement centres to fair-price shops via state godowns — there is a good chance you have to push every weighment into Anna Darpan. The portal is the digital backbone of the PDS rationing system in most states that have adopted it. Integration is mandatory in some states, voluntary in others, and operationally essential everywhere. This piece walks through what the integration actually involves and what trips up new yards.
What Anna Darpan is
A central + state public-distribution-system management portal. It tracks grain procurement, stocking, transfer between godowns, and final distribution to fair-price shops. Most state civil-supplies departments use it; the central FCI uses related but distinct systems (FCI Hafed for procurement workflows).
For a weighbridge specifically, Anna Darpan integration means: every consignment of grain weighed at the yard — whether a truck arriving at a godown, leaving a godown, or transiting between sites — is logged into Anna Darpan with truck registration, weight, source, destination, and consignment metadata. The portal calculates stock movements automatically.
Which states + agencies use it
Adoption is uneven across India. The portal is operated under state civil-supplies departments, so each state's deployment is somewhat distinct. Key states + agencies actively using Anna Darpan as of 2026:
- Madhya Pradesh civil supplies — primary use case
- Chhattisgarh — extensive PDS integration
- Rajasthan — some PDS workflows
- Odisha — partial deployment
- Multiple state cooperative federations using the central Anna Darpan codebase under their own branding
If your yard handles PDS grain in any of these states, integration is either mandatory or strongly expected. Other states may use related but separately-branded portals — the architecture below applies broadly even where the portal name differs.
The end-to-end consignment workflow
At a PDS weighbridge with Anna Darpan integration enabled, here is what happens during a single consignment movement.
- Truck arrives with a despatch advice. The despatch advice was generated by the originating godown's Anna Darpan account and references a consignment ID — a number that uniquely identifies the grain quantity, the consignee, and the route.
- Operator scans / enters the consignment ID. The software queries Anna Darpan for the expected weight and consignment metadata.
- Gross + tare weighment. Truck is weighed gross at arrival; tared. Net is calculated. If the actual net is more than the tolerance band (typically ±0.5%) from the expected, the operator is prompted to confirm before pushing.
- Push to Anna Darpan. The weighed consignment is pushed to the portal with the truck's actual receipt-end weight, the timestamp, the receiving godown, and the operator ID.
- Portal acknowledges. A receipt reference is returned, printed on the slip + recorded against the original despatch ID.
- Stock movement updates. The portal automatically debits the source godown's stock and credits the receiving godown's stock by the actual received weight.
- End-of-day reconciliation. A summary push at shift end confirms every consignment was acknowledged. Discrepancies flagged for the godown manager.
What a yard needs before integration
- Anna Darpan portal credentials. Issued by the state civil-supplies department to the godown / yard. API access is a separate permission tier that requires explicit IT-desk approval.
- Consignment-ID input device. Most yards use a barcode scanner. The despatch advice carries a barcode of the consignment ID; the yard scans it at arrival. Manual entry is a fallback.
- Internet at the yard. Anna Darpan is online-first. Offline-queue capability is essential — when the WAN drops the consignments must queue and post when connectivity returns.
- Indicator + Windows PC. Same as any modern weighbridge — EagleOS runs on Windows 7/8/10/11; indicator is RS-232 or USB-Serial.
- Operator training on PDS workflow. Operators must understand how to handle a despatch-advice mismatch, a missing consignment ID, or a damaged barcode. EagleOS shows the right prompts; the operator must know what to do.
The data that flows portal-side
For a single consignment movement, ~20 fields go to Anna Darpan. The schema is broadly stable but state-specific extensions are common.
| Field group | Fields |
|---|---|
| Yard / godown identifiers | godown_id, district_code, operator_id, shift_id |
| Consignment context | despatch_advice_id, consignment_id, source_godown_id, destination_godown_id, grain_code, expected_weight_kg |
| Truck identity | vehicle_no, driver_phone (optional), transporter_id |
| Weighment | gross_weight_kg, tare_weight_kg, net_weight_kg, gross_timestamp, weighing_mode |
| Acknowledgement | slip_number (yard-local), portal_reference_id (returned), receipt_timestamp |
| Audit | device_signature, software_version, sync_attempt_count |
How Anna Darpan differs from FCI Hafed
Both are central-government-related grain portals, but the workflows are distinct enough that integration patterns differ:
| Dimension | FCI Hafed | Anna Darpan |
|---|---|---|
| Primary scope | Procurement from farmers | Stock-movement after procurement |
| Initiating event | Truck arriving with farmer grain | Truck arriving with godown despatch advice |
| Master data | Party / farmer master | Consignment / despatch-advice master |
| Tolerance | Tight (per-truck min / max enforced) | Wider (±0.5% typical) |
| Operator decision points | Few — system drives | More — mismatch handling is common |
| API change frequency | Per season (twice annual typical) | State-dependent; less predictable |
A yard that handles both — say, an FCI procurement yard that also serves as a PDS transit godown — needs both integrations live simultaneously. EagleOS handles both from the same install; the operator switches modes from the menu.
Timeline from credential request to live sync
| Phase | Duration | Bottleneck |
|---|---|---|
| State civil-supplies credential request | 3-4 weeks | State IT desk processing |
| Hardware delivery | 1-2 weeks | Vendor logistics |
| Software install + Anna Darpan config | 1 day | Credentials in hand |
| Sandbox / UAT cycle | 4-8 hours | State sandbox availability |
| Operator training | 1 day | — |
| Go-live + first-week handholding | 1 week onsite | — |
Total realistic: 4-6 weeks from PO to live sync, with the state IT-desk credential request the dominant variable.
Four pitfalls from live deployments
- Despatch-advice barcode damage. Truck drivers fold + crumple the paper advice. Barcode scanners fail to read. Yard falls back to manual entry, error rates rise. Fix: every advice should be issued with two barcodes (one on each half of the paper); EagleOS supports either scan.
- Receiving godown stock-credit lag. The portal sometimes lags in updating receiving stock — usually within minutes but occasionally hours. Operator panics and re-pushes. Fix: EagleOS shows the portal-side stock balance after each consignment so the operator can verify before re-pushing.
- Tolerance-band false alarms. ±0.5% is tight for grain consignments. Honest transit losses (spillage, sampling) sometimes cross the band. Fix: the operator should be able to confirm a small overage with a one-line note; EagleOS captures this in the slip + audit log.
- State-specific schema drift. When a state extends Anna Darpan with additional fields (e.g. a special PMGKAY tag or a season identifier), older software versions fail validation. Fix: track schema versions per state; ship updates as they are notified.
Handling multi-state PDS operations
State civil-supplies federations sometimes operate yards across state borders. Anna Darpan deployments are state-scoped — Madhya Pradesh's deployment doesn't talk to Chhattisgarh's directly even if both use the same Anna Darpan codebase.
For a multi-state operator, this means each yard talks to its own state's Anna Darpan instance. EagleOS supports this by holding multiple state-credentials in the same install and routing each consignment to the right instance based on the destination godown's state code.
If your operation spans 2+ states, ask any vendor you are evaluating about multi-state credential handling specifically — it is a common gap.
Read the Anna Darpan integration page for the deployment-specific details or talk to the team about your state's adoption.
Last updated: June 2026 · Eagle Weigh editorial team
Ready to talk specifics?
This article walks through the principles. The next step is mapping them to your yard.