How to Manage Multiple Farms with a Centralized ERP: Architecture, Inventory Synchronization, and KPIs

Managing three layer farms with a total of 45,000 birds should not be much more complicated than managing one. In reality, many operations managers lose control as the number of farms increases. At one location, egg production is recorded in a spreadsheet; at another, daily reports are sent via WhatsApp and then recapped by admin staff two days later. As a result, Hen Day Production (HDP) between houses can never be compared apples to apples, feed stock in the central warehouse is not synchronized with actual usage, and a stocktake variance of 3-5 percent is considered normal even though it is worth tens of millions of rupiah per month. This pattern of problems is identical to what we encounter when building multi-branch SIMRS or SIM Klinik with several service units: it is not a lack of applications, but fragmented data. The solution is one centralized ERP with strict rules of the game. This article dissects it from the perspective of architecture, stock synchronization, through to KPIs.

Architecture Foundation: One Master Database, Many Farm Identities

The first decision that determines everything is whether you use one shared database or one database per farm. For a scale of 3 to 30 farms, one PostgreSQL 16 database with a farm_id column in every transactional table is far more efficient. A separate database per farm only makes sense if there are different legal entities with separate tax reporting obligations, or locations in another jurisdiction. In the shared database model, enable Row Level Security (RLS) so that application queries cannot leak to other farms even if a developer forgets to add the WHERE farm_id = ... clause. Cross-farm data leakage is the most expensive incident to fix after the system has been running for a year.

Second, define the master data hierarchy rigidly: company, farm, house, then flock or batch. Each level has a unique code used consistently across all modules. Feed, drug, and chicken strain masters must use internal codes, not free-form manually typed names. We often find the central warehouse records BR-1P while the farm records Brans Pur 1, and stock never matches. Use versioning on item masters so that price or composition changes do not corrupt historical reports.

Third, prepare an offline-first API layer. Node.js 20 LTS with Fastify 4 or Laravel 11 are both adequate. For farms in weak-signal areas, for example the highlands around Magelang, the house application stores transactions in local SQLite and then sends a synchronization queue when the network is available. Each entry carries a client_uuid as an idempotency key so that resending never creates duplicate data.

Feed and Drug Synchronization: The Key to Reconciliation Without Variance

The biggest source of variance in multi-farm operations is not theft, but stock transfers between locations recorded twice separately. The rule is simple: inter-farm transfers must be one document with two automatic journals, namely a deduction at the origin farm and an addition at the destination farm, with the same document number. Never let staff record an issue at one farm and a receipt at another farm as two independent activities.

Technically, use an idempotent upsert with a unique constraint on the combination of farm, flock, and date. This makes the synchronization process safe to run repeatedly, including when a house device resends the same data. Run a nightly reconciliation job that compares book stock with stocktake results and produces a variance report. A reasonable tolerance threshold is 1 percent for bulk feed and 2 percent for drugs and vitamins; variances above that automatically trigger an investigation work order, rather than merely being recorded as a footnote in the monthly report.

Example implementation in PostgreSQL 16 to accommodate daily logs from many farms at once:

INSERT INTO daily_logs (farm_id, flock_id, log_date, feed_kg, egg_kg, mortality)
VALUES (:farm_id, :flock_id, :log_date, :feed_kg, :egg_kg, :mortality)
ON CONFLICT (farm_id, flock_id, log_date)
DO UPDATE SET feed_kg  = EXCLUDED.feed_kg,
              egg_kg   = EXCLUDED.egg_kg,
              mortality = daily_logs.mortality + EXCLUDED.mortality;

Note that the mortality figure is summed, not overwritten, because death events are cumulative per report submission. The most common mistake is overwriting this value so that the daily mortality total is lost when two shifts report.

Cross-Farm KPI Dashboard and Access Governance

Without a single definition, each farm will have its own version of the HDP and Feed Conversion Ratio (FCR) formulas, and evaluation meetings turn into debates over definitions. Define all KPIs in one place, ideally as views or materialized views in the database, not in each farm head's Excel file. The minimum KPIs to monitor daily: HDP, feed consumption per 1,000 birds, daily and cumulative mortality, FCR, cost per kg of eggs, and Income Over Feed Cost (IOFC).

For presentation, a materialized view refreshed every 15 minutes is sufficient for operational needs and far cheaper than querying transactional tables directly. Metabase 0.50 or Grafana 11 can read those views and display farm rankings transparently. This transparency has a disciplinary effect: once farm heads know their numbers are compared directly with other farms, data input quality improves within weeks.

Access governance must follow the organizational hierarchy. A farm head sees only their own farm, an area manager sees three to five farms in their region, and HQ sees the entire portfolio. Implement role-based access control at the application layer and RLS at the database layer, then enable an audit log for every change to master data, feed prices, and stock correction journals. Without an audit log, variance investigations will stop at the statement that no one knows who changed it.

Best Practices

1. Apply a single transfer document for stock movements between farms, not two separate entries.
2. Require an idempotency key on every synchronization endpoint and a unique constraint on the combination of farm, flock, and date.
3. Define HDP, FCR, and IOFC formulas in the database as views, not in each farm's spreadsheet.
4. Run automatic stock reconciliation every night with tolerance thresholds of 1 percent for feed and 2 percent for medicine.
5. Enable RLS and audit logs from day one, not after the first incident occurs.

FAQ

Is one database for all farms safe in terms of performance?

It is safe for scale up to dozens of farms. With composite indexes on farm_id and log_date and materialized views for reporting, PostgreSQL 16 is still comfortable under 100 million daily log rows. Separate databases only if volume or regulation demands it.

How do you handle farms that frequently lose internet connection?

Use an offline-first architecture: the barn application writes to local SQLite, stores a synchronization queue, and resends automatically when the connection returns. The idempotency key ensures data is not duplicated.

How long is a realistic multi-farm ERP implementation?

For 3-10 farms with one commodity type, the basic phase such as master data, daily recording, stock, and dashboard usually finishes in 8-12 weeks. Accounting modules and payroll integration follow in the next phase.

Can a centralized ERP be integrated with existing systems?

Yes. Provide a JSON API with token authentication and OpenAPI 3.1 documentation. Integration with accounting systems, egg retail POS, or payroll applications is generally done through that API, not direct database synchronization.

Managing multi-farm with a centralized ERP is not a software installation project, but a project of standardizing processes and data. Start with rigid master data, a single stock transfer document, and a single KPI definition, then build automation on top. If you are evaluating ERP architecture for several farms, clinics, or service units, our IT consulting team provides application development for SIMRS, SIM Klinik, ERP, POS, and websites for the Yogyakarta, DIY, and Magelang areas. Discuss your needs and get a realistic implementation roadmap.

This article is part of the knowledge base of Nugroho Setiawan, an IT consultant in Jogja (Yogyakarta). Related solutions: PilarPOS Agriculture ERP Clinic Management System. Need a free consultation?