Agricultură — ghid de configurare pe SGApps ERP

Poziție onestă: SGApps ERP nu este un sistem de management agricol specializat (nu are hărți GIS integrate, planificator campanii de tratament / fertilizare cu alerte agronomice, nu se integrează cu Sistemul Informațional Agricol de la MADRM sau cu portalul AIPA pentru cereri de subvenții). Ce oferim este un set de primitive extensibile — parcele ca folder-grup, culturi ca folder-produs, cicluri de lucru (semănat / întreținere / recoltat) ca invoice lifecycle, evidență cantități în stock-logger — care se pot configura la cerere pentru o fermă vegetală, o livadă sau un producător în sere. Raportările oficiale AIPA / ANSA / APIA rămân majoritar manuale sau customizare separată.

1. Modelul recomandat de entități

Concept business	Entitate ERP	Câmpuri folosite
Cultură vegetală (soi grâu, hibrid porumb, variație măr)	folder-produs de tip product	name, SKU, MPN numeric, photo_00..photo_N (foto plante, boli, faze fenologice), params.* (soi, hibrid, perioada de vegetație, densitate semănat) — în references.json
Parcelă / tarla / solă / sector livadă	folder-grup sau POS (după scală)	Pentru ferme mici — un folder-grup per parcelă în catalog; pentru ferme mari cu operațiuni distincte — fiecare parcelă majoră ca POS propriu cu stoc și evidență izolate
Cod cadastral / cod parcelă APIA / suprafață ha	references.json — chei libere	Ex.: references.parcela:cod-cadastru, references.parcela:cod-apia, references.parcela:suprafata-ha
Ciclu campanie (semănat, erbicidare, fertilizare, recoltare)	invoice lifecycle (wip → validated → applied → done)	Fiecare operațiune agricolă = un invoice; log-ul e inalterabil
Lot recoltă (tone recoltate azi din parcela X)	folder-produs de tip lot, cu MPN temporar F:<prefix>:<uid> (până la primirea codului oficial lot) → upgrade la MPN permanent la livrare/vânzare	Pattern extensiv folosit în applications/storage-groups-folder-invoices/api.js linia 460+
Cantitate recoltată (kg/tone) per parcelă per zi	stock-logger cu unitate kg sau t pe produsul "recoltă-parcela-X"	Fiecare zi de recoltă → log intrări; sisteme de balotare pot pusha via API
Consum inputuri (semințe, îngrășăminte, pesticide)	bomCycleGenerate pe cultură — rețetă multi-ingredient (kg semințe + l fertilizant + kg pesticide) → 1 ha lucrat	Vezi applications/horeca/api.js linia 319
Rețetă tehnologică pentru cultură	product:recipe pe produsul "cultură-1ha-realizat"	Rețeta versionată; permite comparare cost planificat vs. real
Fișă lucrare / bon lucrare mecanizată (om + tractor + implement + ore)	invoice custom cu 3 rânduri (om-ore, tractor-ore, implement-ore) sau BOM cycle	Se configurează la onboarding conform fluxului fermier
Multi-fermă / multi-parcelă cu date izolate	params_pos[<pos>]	Aceeași cultură/același input poate avea prețuri, stocuri, evidențe diferite per fermă
Documentație foto evoluție cultură / boli / dăunători	photo_00..photo_N pe folder cultură + fișiere atașate pe invoice-ul-lucrare	Fiecare cultură/parcelă acumulează istoric vizual

Ce nu e un fit natural: hărți GIS interactive (poligonuri parcelă pe hartă cu straturi meteo/sol/istoric randament) — sistemul nu are componentă geospatială nativă. Se pot stoca coordonate GPS ca text în references.parcela:gps-polygon, dar vizualizarea + operarea pe hartă = customizare separată sau integrare externă (ex.: Google Earth / QGIS export).

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

• Catalog culturi + parcele + inputuri — folder-produs pentru fiecare tip (sămânță, îngrășământ, pesticid, produs recoltat), folder-grup pentru organizare (culturi cereale, culturi legume, livadă meri). Câmpurile custom references.* acoperă orice metadata (soi, hibrid, cod APIA, perioada de fungicide, doza recomandată).
• Evidență lucrări mecanizate zilnice — invoice-uri de tip lucrare cu ore-om + ore-tractor + implemente; stock-logger (vezi applications/erp/stock-logger/) păstrează istoricul inalterabil per operator, per utilaj.
• Consum inputuri per parcelă — bomCycleGenerate (vezi applications/horeca/api.js linia 319) rulează rețeta "1 ha grâu = X kg sămânță + Y kg NPK + Z l erbicid" — fiecare rulare decrementează stocurile în timpul lucrării.
• Recoltă cu identificator lot temporar — pattern F:<prefix>:<uid> din applications/storage-groups-folder-invoices/api.js permite deschiderea unui folder "lot-recoltă" fără cod definitiv, cu adăugare progresivă de intrări (fiecare remorcă = un log), apoi upgrade la MPN oficial la depozit sau la livrare.
• Transfer recoltă către depozit / procesator / cumpărător — invoice inter-POS cu emitere bon fiscal (via casă de marcat certificată SFS — vezi docs-functionality/module-comune/fiscal-printers.md) + e-Factura B2B la nevoie (applications/e-factura/api.js).
• Alerte stoc input sub minim — configurare pe fiecare produs input cu stock_min per POS/fermă → Notifications Watcher (applications/erp/notifications-watcher.js) livrează alerte pe dashboard + browser push + audio cue. Trimitere automată SMS/email/Telegram nu e feature product implicit (⚙️ integrare custom).
• Cost intern per hectar / per tonă recoltată — sistem calculează suma inputuri × cicluri BOM rulate la costurile curente ale inputurilor (sg.helpers.priceCalculate).
• Registru pierderi (calamitate, boală, dăunători) — invoice de tip pierdere cu motiv obligatoriu din nomenclator (fixat la cerere: calamitate_grindina, calamitate_seceta, boala, daunatori, depreciere_stoc), notă liberă + eventual foto (photo_* pe invoice).
• Multi-parcelă / multi-fermă — mecanismul params_pos[<pos>] permite stocuri și prețuri distincte per fermă; același input poate avea cost achiziție diferit între ferme.
• Configurare tehnologică versionată — SharedRefs (applications/shared-refs/) permite stocarea rețetei tehnologice per cultură cu istoric audit-log; când se modifică doza recomandată, versiunile anterioare rămân accesibile pentru calcule pe perioade vechi.
• Audit fiscal-ready — orice vânzare recoltă (către angrosist, către procesator, către consumator direct) generează bon fiscal + optional e-Factura; jurnal SNC (611 pentru materiile prime consumate, 711 pentru cost producție, 216 pentru produse finite din culturi) — vezi SNC Moldova.

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

• Modul GIS / hartă interactivă parcele cu straturi meteo, cultură curentă, istoric randament — nu există componentă geospatială nativă. Estimare orientativă: 6-10 săptămâni (integrare tile provider + editor poligoane + layer istoric).
• Planificator campanie fitosanitar cu alerte agronomice (calendare tratamente în funcție de faza fenologică + prognoză meteo + praguri economici de dăunători) — model cu invoice-stagii + notificări există, dar logica agronomică specifică nu. Estimare: 4-6 săptămâni.
• Modul livadă / plantaţie perenă (pomi individuali cu fișă, cartare rânduri, evidență tăieri) — modelul folder-produs + params_pos acoperă parțial; UI dedicat pomi cu vizualizare rând-coloană = customizare. Estimare: 3-5 săptămâni.
• Curbe de randament / grafice sezoniere per parcelă / per cultură — datele sunt în stock-logger; graficele agregate (kg/ha pe ani, comparație an-la-an) nu sunt built-in dashboard. Estimare: 2-3 săptămâni.
• Integrare cu senzori sere / stații meteo / dispozitive irigare — bridge AndroidBridge (applications/android-bridge/) oferă infra HTTP/USB/BT; driver-ele specifice pe hardware sunt configurări per proiect.
• Import date istorice din alt sistem agricol (fișe câmp Excel, softuri contabile agricole existente, cadastru local) — nu există import automat. Migrare = serviciu individual după evaluarea fișierelor sursă.
• Sisteme de balotare / semănătoare / combine cu telemetrie ISOBUS — nu integrăm out-of-the-box protocoale ISO 11783; potențial de customizare per model.

4. Ce e complet neacoperit sau se face manual

• Cereri de subvenție AIPA / dosarul de plată directe — nedocumentat; nu am integrat portalurile AIPA pentru trimitere programatică cerere subvenție sau raportare implementare proiect. Datele brute (suprafață cultivată, tehnologie aplicată, chitanțe input-uri) sunt extractibile din sistem.
• Registrul de evidență a tratamentelor fitosanitare (obligatoriu conform legislației MD pentru fermele care aplică pesticide) — nu generăm formularul tipizat; datele operațiunilor sunt în invoice-uri, dar formatarea oficială e nedocumentată.
• Registrul plantaţiilor viticole / pomicole conform format autoritate — nu există template.
• Certificatul de origine / conformitate pentru produsele agroalimentare (ANSA) — completarea rămâne pe hârtie / portal ANSA; sistemul poate ține numărul certificatului ca reference.
• Analize sol / plante / apă — se pot stoca ca atașamente pe folder-parcelă (foto/PDF), dar interpretarea automată + recomandări fertilizare = nu.
• Prognoză meteo integrată — nu; utilizatorul consultă surse externe.
• Managementul apei irigare (planificare consum apă, chittanțe la asociația de irigare, respectarea cotei alocate) — nu există modul dedicat; evidența e posibilă ca stock-logger + invoice-uri, dar customizare specific irigare = separat.
• Trasabilitate GlobalGAP / Bio / certificare produs organic — se pot stoca certificatele ca atașament, dar auditurile trasabilitate rămân pe procesul auditorului certificator.

5. Scenariu real end-to-end

Context: fermă vegetală mică cu 3 parcele (grâu 20 ha, porumb 15 ha, floarea-soarelui 10 ha), 1 tractor, 2 muncitori sezonieri. POS: 1 birou administrativ + 1 tabletă pentru câmp.
Primăvara — semănat grâu:
06:00 — Administratorul deschide HoReCa Dashboard (webapp-ul e generic operațional; contextul agricol e configurat la onboarding) → tab Orders → creează invoice de tip "operațiune-câmp" cu parcela = "Parcela-Grâu-20ha" (folder-grup), rețetă tehnologică = "grâu-1ha-semănat" (BOM-recipe cu 220 kg sămânță + 100 kg NPK + 4 ore-tractor + 4 ore-om per hectar).
06:15 — Rulează bomCycleGenerate cu cycles=20 (20 ha) → sistemul decrementează stocurile input (4400 kg sămânță, 2000 kg NPK, log-uri stock-logger pe fiecare); logul de tractor rămâne ca invoice separat.
14:00 — Muncitorul finalizează cu tableta operațiunea → stagiul invoice trece de la wip la applied, log-uri consolidate; se pot atașa photo_* cu starea parcelei după lucrare.
Vara — recoltare porumb:
08:00 — Începe recoltarea Parcelei-Porumb-15ha. Se deschide un lot temporar cu MPN F:PORUMB-2026-08:aB3xY (folder-produs recolta, temp MPN până la codificare oficială). Fiecare remorcă cântărită la vin → intrare via invoice → log în stock-logger cu autor, cantitate, timestamp.
14:00 — Recoltare terminată; total 82 tone. Se convertește MPN temporar în MPN permanent (via updateReferences — vezi applications/storage-groups-folder-invoices/api.js linia 507) — devine SKU=PORUMB-2026-P15HA-LOT001. Se emite invoice transfer către depozit sau invoice vânzare directă către angrosist cu e-Factura B2B (applications/e-factura/api.js).
Sezon-close — Administratorul consultă Reports pentru agregări subtypes + Top losses. Calcularea marjă per parcelă (venit vânzare recoltă − cost inputuri − cost lucrări − pierderi) este vizibilă în rapoartele generice; UI dedicat "randament/hectar/an" cu grafice ar fi customizare.

6. Ce nu promitem

• Nu suntem un sistem agricol dedicat — nu concurăm cu produse cu hărți GIS, planificare fitosanitară agronomic, integrare senzori sere.
• Nu automatizăm cererile AIPA / raportările ANSA — datele sunt disponibile, formatele oficiale se completează manual sau prin customizare separată.
• Nu integrăm out-of-the-box cu combine, stații meteo, dispozitive irigare automatizate — driver-ele hardware sunt studii de caz per model.
• Nu oferim recomandări agronomice — utilizatorul rămâne responsabil de decizii tehnologice.
• Nu emitem certificate de origine / bio / GlobalGAP — completarea oficială e în afara sistemului.

7. Scoring (0-100% per dimensiune)

Dimensiune	Pondere	Scor	Notă onestă
Model de date	25%	60%	Primitivele acoperă parcelă, cultură, input, ciclu operaţional. Lipsă model GIS nativ (poligoane, straturi) — se poate adăuga ca text ref, nu ca UI.
Fluxuri operaționale zilnice	25%	50%	Semănat, tratament, recoltare — toate se pot rula cu BOM-cycle + invoice-uri. UI tabletă e generic, nu are gesturi câmp (input rapid poziție GPS, foto-pe-parcelă cu tag automat).
Rapoarte management	15%	40%	Storage-groups + shift close dau agregări. Randament/ha, comparaţie interanuală, hartă cost pe parcelă = nu implicit.
Rapoarte oficiale autoritate	15%	10%	Formulare AIPA / ANSA / registru fitosanitar nu au template. Datele brute exportabile prin API JSON.
Integrări specifice vertical	10%	15%	Bridge Android oferă infra, dar ISOBUS combine / stații meteo / senzori sere = configurări separate.
Documentație existentă	10%	5%	Prima pagină dedicată agricultură; fără capturi/scenarii vizuale încă.

Total ponderat: ~36%
Interpretare: SGApps ERP poate acoperi operațional o fermă vegetală mică / medie (evidență inputuri, ciclu tehnologic, cost/ha, cost/tonă, audit fiscal), dar componentele agricole avansate (GIS, agronomie, subvenții) rămân majoritar în afara scope-ului out-of-the-box. Verificare fit în etapa de descoperire înainte de contractare.

Următorul pas

• Landing verticale
• Programează un apel pentru evaluare fit vertical agricultură