Zootehnie — ghid de configurare pe SGApps ERP

Poziție onestă: SGApps ERP nu este un IAS zootehnic dedicat (nu are module preconstruite pentru genealogie bovină, jurnal de furajare zilnic tipizat sau formulare S.M.A.R.T. pentru ANSA). Ce oferim este un set de primitive extensibile (folder-produs, folder-grup, invoice cu ciclu de viață, stock-logger inalterabil, BOM, references.json liber) care se pot configura la cerere pentru a acoperi majoritatea fluxurilor operaționale ale unei ferme de bovine, suine, ovine sau păsări. Rapoartele obligatorii către ANSA sau alte autorități rămân un GAP tratat individual pe proiect.

1. Modelul recomandat de entități

Concept business	Entitate ERP	Câmpuri folosite
Animal individual (bovină, scroafă reproducătoare, oaie matcă)	`folder-produs` de tip `product`	`name` (poreclă/număr), `SKU`, `MPN` numeric permanent sau `F:<prefix>:<uid>` temporar (pentru animale fără crotal), `photo_00..photo_N` (foto identificare), `params.*` (data nașterii, rasa, sex, mama, tata) — toate în `references.json`
Turmă / grup animale (lot vaci lactație, lot îngrășare porci)	`folder-grup`	`params.quantity_available` — efectivul curent al grupului
Fermă / adăpost / stână	`POS` (punct operațional distinct)	Fiecare POS are `IDNO` propriu, casa de marcat proprie, stoc propriu, config propriu
Câmp per POS (per fermă) pe același animal	`params_pos[<pos>]`	Aceeași fișă de animal poate avea date diferite când e transferată între ferme (ex.: stare curentă, jurnal local)
Crotal, cod SNIIA, cod pașaport	`references.json` — chei libere	Ex.: `references.animal:crotal`, `references.animal:sniia`, `references.animal:pasaport-nr`
Tratament veterinar programat, ciclu de reproducere, campanie de vaccinare	`invoice lifecycle` (wip → validated → applied → done)	Fiecare procedură = un invoice cu stagii; log-ul rămâne inalterabil
Mulsul zilnic (kg lapte) / recolta de ouă	`stock-logger` cu unitate `l` sau `buc` pe un produs de tip "lapte-fermă-X"	Fiecare intrare = un log cu timestamp, cantitate, autor
Furaj consumat pe zi / pe lot	`bomCycleGenerate` — ciclu BOM cu intrări multiple (concentrat + fibros + apă) → ieșire virtuală "furaj-consumat-lot-X"	Vezi `applications/horeca/api.js` linia 319
Rețetă de furajare	`product:recipe` pe produsul finit (kg lapte sau kg spor greutate)	Rețeta e versionată prin flow standard invoice
Multimedia veterinar (fișă tratament, poze răni, ecografii)	`photo_00..photo_N` pe folderul animal + fișiere atașate	Fiecare animal poate acumula istoric vizual

Ce nu e un fit natural: genealogie multi-generațională (arbore descendență cu bunici, străbunici, colateralii) — sistemul nu are model dedicat de "pedigree tree" cu vizualizare grafică. Legăturile părinte-copil pot fi stocate ca references.animal:mama-mpn / animal:tata-mpn, dar navigarea vizuală în arbore este un GAP (customizare la cerere).

2. Ce se acoperă 1:1 cu primitivele existente

Toate elementele de mai jos sunt implementate în cod și pot fi folosite fără dev nou:

Fișa individuală de animal — folder-produs cu foto multiple (photo_00..photo_N — vezi applications/erp/storage-groups/component/group.js), MPN unic (temp F: până la primirea crotalului oficial, apoi upgrade la MPN numeric permanent — vezi applications/storage-groups-folder-invoices/api.js linia 460 create + linia 507 update temp MPN).
Grup / turmă cu efectiv curent — folder-grup cu params.quantity_available; sistemul recalculează la fiecare mișcare (achiziție, vânzare, transfer, moarte animal).
Transfer animal între ferme — invoice de tip transfer inter-POS, cu istoric inalterabil în stock-logger (vezi assets/scripts/modules/applications/erp/stock-logger/); log-ul înregistrează timestamp, cantitate (± 1 animal), autor, sursa (folderul invoice care a produs mișcarea).
Mulsul zilnic per fermă / per lot — introducere manuală (cantitate kg/l pe zi) sau via AndroidBridge (tabletă în muls) cu decrementare stoc virtual "lapte-crud" și incrementare stoc real când se recepționează la cisternă/frigider (fiecare eveniment log-at în stock-logger).
Vaccinare / tratament programat — invoice cu stagii wip (programat) → validated (executat) → applied (stoc medicament decrementat) → done (arhivă); execuția pe tabletă cu foto (photo_* atașat la invoice-ul-tratament).
Consum furaj zilnic — bomCycleGenerate cu rețetă multi-ingredient (kg concentrat + kg tărâțe + kg fân + l apă) pe grup animal — fiecare ciclu decrementează exact ingredientele din stoc, cu autor + timestamp.
Alertă stoc furaj sub minim — configurare pe produsul-ingredient a pragului params_pos[<fermă>].stock_min; notificarea ajunge în Notifications Watcher (vezi applications/erp/notifications-watcher.js) — dashboard + audio cue + browser push. Nu e trimisă automat pe email/Telegram/SMS (integrarea multi-canal e ⚙️ ofertă individuală).
Cost intern al kg carne / kg lapte — sistemul calculează cost productiv = suma cost ingrediente rețetă × cicluri BOM rulate, la costurile curente ale ingredientelor (vezi sg.helpers.priceCalculate + rețete BOM din applications/horeca/api.js).
Registru pierderi (mortalitate) — invoice de tip "pierdere" cu motiv obligatoriu din nomenclator (fixat la cerere: mortalitate_natural, mortalitate_boală, sacrificat_forţat, pierdere_furt) + notă liberă; log rămâne inalterabil.
Audit fiscal-ready — orice mișcare (achiziție animal viu, vânzare la abator, vânzare direct consumator, transfer inter-fermă) generează bon fiscal via casă de marcat certificată SFS (vezi docs-functionality/module-comune/fiscal-printers.md) + e-Factura B2B când e cerută (applications/e-factura/api.js).
Multi-fermă cu date izolate — mecanismul params_pos[<pos>] face ca aceeași fișă de animal transferată să aibă starea locală per fermă; stocuri, prețuri, evidențe se calculează per POS.
Configurare per fermă versionată — SharedRefs (vezi applications/shared-refs/) permite stocarea de setări (praguri furaj, orare hrănire, delta greutate zilnic acceptabil) cu istoric complet audit-log per POS / per user / global.

3. Ce necesită dev/proiect (project scope, nu produs)

GAP-urile de mai jos nu sunt acoperite implicit; ele apar în cotația scrisă când clientul le confirmă în etapa de descoperire:

Fișe genealogice multi-generaționale cu vizualizare arbore — model de date există (references între animale), dar UI-ul de "pedigree tree" cu 3-4 generații trebuie construit. Estimare orientativă: 3-5 săptămâni dev + design.
Jurnal de furajare zilnic tipizat pe grup, cu comparare "planificat vs. realizat" — mecanismul BOM există; un UI dedicat de tip calendar-cu-cifre-per-zi + comparare cu plan (peste ce oferă tabelele standard din storage-groups) trebuie configurat separat. Estimare: 2-3 săptămâni.
Modul de reproducere (evidența monta, gestație, fătare planificată/reală cu alerte pe dată prevăzută) — model: fiecare ciclu de reproducere = invoice cu stagii; UI dedicat gestație + alertă e customizare. Estimare: 3-4 săptămâni.
Curbe de lactație / curbe de creștere pe individ — datele sunt în stock-logger (kg lapte zilnic / kg greutate corp la cântăriri periodice); graficele de curbă nu există implicit în dashboard. Estimare: 2 săptămâni.
Integrare directă cu cântare electronice / cititor crotal RFID / boxe muls automat — bridge-ul AndroidBridge are USB + Bluetooth + on-device HTTP server (vezi applications/android-bridge/), dar driver-ele specifice per model (cântar, cititor RFID, robot muls) trebuie configurate per hardware, la cerere.
Import date istorice din alt IAS zootehnic (Registrul Naţional Zootehnic, aplicații 1C zootehnie, foi Excel gestor ferm) — nu există import automat. Migrare = serviciu individual după evaluarea fișierelor sursă (vezi convenția generală Migrare date).

4. Ce e complet neacoperit sau se face manual

Onest — aceste zone rămân manuale / hibride cu formularistica autorității; nu le acoperim implicit:

Formularele S.M.A.R.T. / raportări obligatorii ANSA (mișcări animale, mortalitate, tratamente veterinare, buletin sănătate) — nu există template preconfigurat de export. Datele pot fi extrase din stock-logger + invoice-uri, dar completarea formularului rămâne responsabilitatea operatorului sau customizare separată.
Integrare cu sistemele oficiale SNIIA / RGCE / registru genealogic național — nedocumentat; nu am integrat API-uri publice ale autorității zootehnice; verifică în etapa de descoperire dacă autoritatea expune API-uri pentru integrare programatică.
Certificat sanitar-veterinar de transport animale (Model 2) — completarea rămâne pe hârtie / portal autoritate; sistemul poate ține evidența numărului de certificat ca references.transport:cert-nr, dar generarea PDF-ului tipizat nu e implementată.
Registrul de exploatație zootehnică (RE) oficial — nu generăm PDF conform format autoritate; extractul de date brute e disponibil în storage-groups.
Rații de furajare balansate nutriţional (calcul NDF/ADF/energie metabolizabilă/proteină brută) — sistemul rulează rețete BOM statice; calculul nutrițional dinamic (target vs. real, ajustare per stadiu lactație / stadiu îngrășare) nu e feature product.
Analize laborator (lapte crud, sânge, materii fecale) — se pot stoca ca atașamente pe folder-animal (photo/fișier PDF) sau references custom, dar interpretarea + alertele nu sunt automate.
Trasabilitate carne "from farm to fork" cu QR-cod pe pachet ce descarcă istoricul complet al animalului — model de date există, dar generatorul QR + pagina publică de trasabilitate = customizare separată.

5. Scenariu real end-to-end

Context:* fermă de 40 vaci lactație, tabletă în muls, PC birou administrator, casă de marcat certificată SFS.

06:00 — Muglașul intră cu tableta pe HoReCa Dashboard* (webapp-ul funcționează ca operational hub, chiar dacă contextul e zootehnie — tabele/liste sunt aceleași). POS-ul curent e "Fermă 1 - Muls".

06:05* — Începe mulsul. Pentru fiecare vacă (identificată prin crotal numeric = MPN permanent), introduce cantitatea în litri pe fișa individuală. Sistemul emite câte un log stock-logger per intrare, incrementând stocul "lapte-crud-Fermă-1" (unitate l, folder-produs cu SKU=LAPTE-CRUD-F1).

07:30 — Muls terminat. Sistemul calculează automat: total 380 l — vezi listing în Storage Groups* cu filtrul Only Products + căutare "lapte" (applications/erp/storage-groups/component.js).

08:00* — Cisterna vine să ridice laptele. Se scrie un invoice de tip transfer POS-Fermă-1 → POS-Depozit-central, cantitate 380 l. Log-ul din stock-logger rămâne inalterabil; dacă apare o corectie ulterior (măsurătoare cisternă diferă cu 2 l), se emite un al doilea invoice de tip corecție cu motiv obligatoriu (nu se editează log-ul vechi).

14:00* — Veterinarul programează 3 vaccinări pe lotul de vițele. În webapp deschide invoice de tip "tratament-veterinar" cu stagiu wip (programat) → 3 rânduri (vițele × 1 doză vaccin X). Odată efectuat, avansează stagiul la applied — stocul de vaccin decrementează 3 doze din depozit, cu autor Veterinar Ion, timestamp la secundă, plus poză cu flaconul (photo_00).

18:00 — Zootehnistul consultă Reports* din HoReCa Dashboard → agregări pe subtypes (intrări-lapte pe azi, consum furaj pe azi, mortalitate) + Top losses (dacă a fost cazul).

Rezultatul:* 40 intrări individuale în stock-logger, 1 transfer către depozit central, 1 invoice tratament veterinar. Toate cu autor, timestamp, sursă, complet auditabile. Bonul fiscal pentru vânzarea laptelui către procesator se emite ulterior via POS-Fiscal când se generează factura pe firmă (applications/e-factura/api.js).

6. Ce nu promitem

Nu suntem un IAS zootehnic dedicat — nu concurăm cu produse specializate pe segmentul zootehnie care oferă module native pentru genealogie, curbe lactație, planuri reproducere.
Nu automatizăm raportările ANSA / RGCE / SNIIA — datele sunt disponibile pentru extragere, dar formularistica oficială se completează manual sau prin customizare separată.
Nu integrăm out-of-the-box cu robot-uri de muls, dozatoare furaj automatizate sau cântare tip alee — driver-ele hardware sunt studii de caz per model, nu feature product implicit.
Nu calculăm rații balansate nutriţional — rulăm rețete BOM statice; nutriționistul rămâne responsabil de compoziție.
Nu emitem certificate sanitar-veterinare tipizate — completarea oficială (Model 2 transport, aviz sanitar) rămâne în afara sistemului.

7. Scoring (0-100% per dimensiune)

Dimensiune	Pondere	Scor	Notă onestă
Model de date	25%	65%	Primitivele acoperă animal-individual, turmă, transfer, tratament. Genealogia multi-generațională necesită UI custom.
Fluxuri operaționale zilnice	25%	55%	Muls, hrănire, tratament, transfer — toate se pot rula cu primitivele existente. UI-ul tabletă e generic, nu adaptat gesturi specifice fermier (input rapid crotal, scan RFID, apăsare-pentru-vaccinat).
Rapoarte management	15%	45%	Storage-groups + shift close dau agregări generice. Curbe lactație / curbe creștere / KPI zootehnie specifici nu sunt built-in.
Rapoarte oficiale autoritate	15%	10%	Formulare ANSA / SNIIA / registru genealogic nu au template. Datele brute sunt exportabile prin API (JSON), dar formatarea oficială e nedocumentată.
Integrări specifice vertical	10%	20%	Bridge-ul Android oferă USB/BT/HTTP pentru orice hardware, dar driver-ele specifice (RFID crotal, cântar alee, robot muls) sunt configurări per proiect.
Documentație existentă	10%	5%	Această pagină e primul ghid zootehnie; nu există încă capturi vizuale sau scenarii pas-cu-pas dedicate.

Total ponderat: ~40%*

Interpretare: SGApps ERP poate rula operațional o fermă mică sau medie cu customizare la onboarding pentru fluxul specific (rețete de furajare, nomenclator motive pierdere, structură ferme/adăposturi). Zonele de conformitate cu autoritatea zootehnică rămân majoritar manuale* — verifică-le în etapa de descoperire, înainte de contractare.

Următorul pas

Landing verticale
Programează un apel pentru evaluare fit vertical zootehnie