Automating FCR and Hen-Day Production Reports on Layer Farms

Layer farms with a scale of 10,000–50,000 birds still often rely on manual spreadsheets to calculate FCR and hen-day production. Supervisors record the number of eggs every morning, then admins calculate at the end of the week. As a result: reports are 1–2 days late, human error is 3–5%, and FCR is only known after feed has already been wasted. Yet these two metrics—FCR (Feed Conversion Ratio) and hen-day production (HDP)—are the main indicators of layer farm profitability. FCR determines feed efficiency (the largest cost, ±70% OPEX), while HDP measures the daily productivity of the hens. This article discusses how to build automation for FCR and HDP reports from daily flock data using PostgreSQL 16, Python 3.12 (pandas 2.2), and a cron scheduler—a stack that is easy for an internal IT team to maintain without vendor lock-in.

Understanding the Metrics: FCR, Hen-Day, and Hen-Housed Production

Before writing code, ensure that metric definitions are agreed upon between the operations and IT teams. Hen-day production (HDP) = (number of eggs today ÷ live bird population today) × 100%. Example: 8,400 eggs from 9,000 birds = 93.3%. Hen-housed production uses the initial population as the divisor, so it reflects the impact of mortality and culling. Layer FCR is calculated as kg feed ÷ kg egg mass (or ÷ number of eggs for certain farm conventions). Commercial layer standard: FCR 2.0–2.2 kg feed/kg eggs, HDP ≥ 85% at peak production (age 26–32 weeks).

The minimum daily data that must be collected per flock: record_date, flock_id, eggs_count, eggs_weight_kg (or sampling), feed_consumed_kg, live_birds, mortality, and temperature_c. Without egg weight, FCR cannot be calculated—so invest in a digital scale per house (cost ±IDR 1.5 million/unit) or perform sampling of 30 eggs/day for extrapolation.

The relational schema I used in my last Layer ERP project: table flocks (id, house_id, doc_date, initial_count), daily_records (flock_id, record_date, eggs_count, eggs_weight_kg, live_birds, mortality, feed_consumed_kg), and egg_collections (details per sorting grade A/B/C). A composite index on (flock_id, record_date) is mandatory—a 30-day × 50-house query loses ~40% performance without an index.

The key to automation is a single source of truth: all calculations in one Python function, used by the dashboard, alerts, and PDF/Excel export. Do not let Excel hold the company formulas—that is a weak point for configuration and audit trail.

Implementation: Python Script + PostgreSQL for Daily Reports

The stack I recommend: Python 3.12, pandas 2.2+, SQLAlchemy 2.0 (psycopg 3 driver), and cron or n8n for scheduling. For a 5,000-row × 30-day report, execution finishes in < 2 seconds. The following is the core calculation script that can be run directly:

import pandas as pd
from sqlalchemy import create_engine

engine = create_engine('postgresql+psycopg://user:pass@localhost:5432/poultry')
df = pd.read_sql("""
  SELECT flock_id, record_date, eggs_count, eggs_weight_kg,
         feed_consumed_kg, live_birds
  FROM daily_records
  WHERE record_date >= CURRENT_DATE - INTERVAL '30 days'
  ORDER BY flock_id, record_date
""", engine)

df['hdp_pct'] = (df.eggs_count / df.live_birds * 100).round(2)
df['fcr'] = (df.feed_consumed_kg / df.eggs_weight_kg).round(3)
df['hdp_7d'] = df.groupby('flock_id')['hdp_pct'].transform(lambda s: s.rolling(7).mean().round(2))
df['fcr_mtd'] = df.groupby('flock_id')['fcr'].transform(lambda s: s.expanding().mean().round(3))
print(df.tail(10))

Brief explanation: the hdp_7d column is a 7-day moving average to dampen daily noise (for example, broken eggs or a power outage), while fcr_mtd is month-to-date FCR used to compare performance between houses. After calculation, the results are written back to the report_daily table with an upsert (ON CONFLICT (flock_id, record_date) DO UPDATE) so that it is idempotent—the scheduler can run multiple times without duplication.

Run the script via a cron job at 05:30 WIB after daily input is complete: 30 5 * * * /usr/bin/python3 /opt/poultry/report_daily.py >> /var/log/fcr.log 2>&1. For teams that are not comfortable with crontab, n8n (version 1.x, self-hosted) provides Cron + PostgreSQL + HTTP Request nodes to the WhatsApp Business API. What matters: idempotent, logged, and alert-on-failure (send a message to Slack/Telegram if exit code ≠ 0).

Dashboard and Automatic Alerts Based on Thresholds

A report that is not read might as well not exist. I always set up two layers of distribution: (1) a web dashboard (Metabase 0.49 or Grafana 10 if real-time is needed) that queries the report_daily table directly, and (2) a daily push to the management WhatsApp/Telegram group at 06:00 WIB containing a summary: yesterday's HDP, MTD FCR, houses with the lowest performance, and a list of houses violating the thresholds.

Example anomaly detection query: houses whose HDP has dropped > 3% compared with 7 days ago, or whose FCR has risen > 5% from the previous month's baseline. This early detection has been proven to cut investigation time from 2 days to 2 hours in cases of declining feed quality or mild outbreaks (IB, ND) at my clients.

For PDF export to management, use Jinja2 + WeasyPrint; the report format is one page per house with a weekly HDP sparkline. Store the PDF in S3/MinIO for audit trail—do not rely only on WhatsApp screenshots.

Best Practices

1. Validate input at the entry point—reject eggs_count > live_birds × 1.1 or feed_consumed_kg per bird > 130 g/day; buffer before entering the database.
2. Provide a 1-day grace period before data is considered final (record_date + 1), so input corrections do not produce duplicate reports.
3. Use an explicit timezone (Asia/Jakarta) in PostgreSQL (TIMESTAMPTZ) and Python (zoneinfo.ZoneInfo); avoid naive datetime.now() that causes reports to shift when the server moves region.
4. Store daily report snapshots in a separate table from raw data—a 6-month backward audit must be accurate even if raw data is corrected.
5. Automate regression tests with pytest against 3 scenarios: normal data, missing 1 day, and outlier (e.g. eggs 0 due to power outage); deploy the script only if the tests pass.

FAQ

Should FCR be calculated daily or weekly?

Ideally daily for early detection, but read as a 7-day moving average. Daily FCR is very noisy due to fluctuations in egg weight and feed leftovers; MTD figures are reported to management, while HDP is monitored daily.

What if egg weight is not weighed every day?

Take a sample of 30 eggs/day per house (mix grades A/B/C) and extrapolate with eggs_count. Sampling error ±1.5%—still below management FCR tolerance. Weekly scale calibration is mandatory.

Can it run without its own server?

Yes. A combination of Supabase (managed PostgreSQL) + Google Cloud Scheduler + Cloud Functions saves OPEX of ±IDR 500 thousand/month for a scale of 20 houses. However, for personal data and unstable house connections, on-premise at the head office is more reliable.

How to integrate with an existing Poultry ERP?

Expose the report_daily table via REST API (FastAPI 0.110+). ERP reads the endpoint /api/v1/reports/daily?flock_id=&date_from=, no need to query the database directly—avoiding schema coupling.

FCR and hen-day production automation is not about advanced technology—it is about data discipline and consistent calculation units. With the right PostgreSQL, Python, and scheduler, reports that used to take 2 days can be available 30 minutes after the last input, accurate, and auditable. If you are building a Poultry ERP, SIM Peternakan, or want to integrate the farm data layer into a management dashboard, I am ready to help with architecture audit and end-to-end implementation—from schema design to automatic alerts on WhatsApp.

Related solutions by PT Pilar Inovasi Informatika (Pilar Inovasi IT products): Agriculture ERP. Need a free consultation?