Emballageflow

Drie bronnen, geen uniform transactiegrootboek

1. leverancier_pakbon_emballage: actuele hoeveelheden bij een pakbon/artikel/kvd; geleverd, retour, geleverd_volgens_leverancier, retour_volgens_leverancier, ontvangen, verstuurd.
2. leverancier_emballage_registratie: HUB-waarneming per partij/datum/artikel/kvd, inkomend/uitgaand, bevestigd, lmf_user, optionele leverancier_pakbon/levering.
3. leverancier_emballage_registratie_stop: chauffeurwaarneming per stop/tijd/artikel/kvd, opgehaald/afgeleverd, lmf_user en optionele pakbonlink.

Het is een combinatie van wijzigbare hoeveelheidsrecords en toegevoegde registraties. Het is geen zuiver append-only transactiemodel en geen opgeslagen begin-/eindsaldomodel.

Exacte schrijfpaden

| Functie | Invoer → write | Richting en beperkingen | |---|---|---| | new_supplier_delivery | location GUID, delivery_date, packages[id,number,package_type] → pakbon, footer, emballage.geleverd_volgens_leverancier | leverancier meldt uitgifte; UPDATE-key mist kvd; waarde = aantal × actuele artikelprijs | | update_supplier_delivery | delivery_id GUID, packages → emballage.geleverd en footer | andere kolom dan creatie; UPDATE mist kvd, insert vult kvd niet; niet-verstuurde regels worden niet verwijderd | | confirm_delivery | delivery_id GUID, outbound_packages → geleverd_volgens_leverancier + pakbon_levering | geldt in de gedeelde functie ook voor klant/logistiek; returned_packages wordt niet gelezen; geen volledige retourflow | | assignment | debtor/date/order_number/packages[code,quantity] → HUB-registratie inkomend en pakbon/footer | quantity=0 wordt 1; onbekende codes genegeerd; alleen bij som prijs×quantity >0; kvd niet meegegeven | | hub_incoming_deliveries | supplier_id/delivery_date/packages → reg.inkomend; returned_packages → reg.uitgaand | HUB ontvangt van leverancier en retourneert naar leverancier; UPDATE of INSERT; bevestigd=1 | | hub_outgoing_deliveries | location_id/delivery_date/packages → reg.uitgaand; returned_packages → reg.inkomend | HUB geeft naar klant uit en ontvangt retour; uitgaande packages altijd INSERT, retour UPDATE/INSERT | | delivery_stop | stop_id, packages → afgeleverd; returned_packages → opgehaald | klantlocatie, datum=now()/vandaag, user.id; UPDATE/INSERT per dag/locatie/artikel/kvd/stop_id | | pickup_stop | dezelfde velden | partij=hub als ID overeenkomt met pakbon.hub, anders leverancier; packages blijft afgeleverd, returned_packages opgehaald; naam pickup verandert deze mapping niet | | return_packaging | delivery_id (=levering) | alleen SELECT, ondanks tekst 'Retour emballage geregistreerd' |

De HUB-UPDATE-sleutel is artikel+hub+datum+leverancier/lokatie; zonder kvd en zonder bronpakbon. Hetzelfde artikel met verschillende temperatuurtypen of meerdere pakbonnen kan daardoor meer dan één rij wijzigen. De stopfuncties zetten niet-positieve ingevoerde waarden op 0 en bewaren geen revisiegeschiedenis. HUB-writes bevatten geen overeenkomstige numerieke validatie.

Bronreferenties

_emballage_source_reference probeert: numerieke leverancier_pakbon → delivery_id als pakbon.guid → levering → unieke pakbon voor HUB+partij+datum. _emballage_source_in_scope vergelijkt aanwezige scopewaarden. Als niet eenduidig/gevonden/in scope: lege bronreferentie, registratie gaat wel door. Expliciete levering gebruikt selectrow, geen controle dat precies één pakbon overeenkomt. Updates vullen bestaande bronlinks alleen via COALESCE aan; ze vervangen ze niet.

De migratie 20260810_lmf_emballage_source_refs.sql voegt nullable references toe, zonder backfill. Live catalogus bevestigt deze velden/FK's. Oudere niet-gelinkte registraties blijven zonder harde bron.

Partij, datum, rit en actor

• HUB-record: hub + leverancier óf lokatie bepaalt de tegenpartij; geen expliciet universeel from_party/to_party-paar.
• Stoprecord: locatie/HUB/leverancier is de bezochte partij. Vervoerder wordt in de controle afgeleid via lmf_user.leverancier_id, dus van de huidige actorconfiguratie.
• Order wordt via pakbon.vers_order bereikt. De actieve stops hebben geen FK naar lmf_stop of lmf_route; routecontext wordt bij lezen samengesteld.
• HUB-datum komt uit delivery_date, zonder apart created_at/updated_at. Stop-insert gebruikt now(); update laat actor/timestamp oorspronkelijk. Pakbonemballage heeft geen actor of tijdkolom.
• KVD: 1 Koel, 2 Vries, 3 Droog. Artikel-ID bepaalt krat/bak/catalogus, niet KVD.

Retour en correctie in de React-app

EmballageDrawer maakt {id, number, package_type}. HubDeliveries stuurt heen en retour naar beide HUB-endpoints. LogisticsStopDetail stuurt beide arrays naar stop. SupplierDeliveryDetail stuurt outbound_packages én returned_packages, maar de bevestigingsfunctie verwerkt alleen outbound_packages. CustomerDeliveryDetails stuurt packages/returned_packages; confirm_delivery leest outbound_packages, dus ook de heen-array sluit niet aan. LogisticDeliveryDetail bevestigt zonder emballagearrays.

Een retourknop is hierdoor geen bewijs van duurzame retourboekhouding. Correcties zijn bestaande aantallen overschrijven of aanvullende INSERTs; geen gevonden expliciete correctieboeking met reden, tegentransactie of verwijzing naar de oorspronkelijke boeking.

Controle

EmballageControl leest alle drie bronnen, koppelt op harde pakbon/leveringsreferenties en vergelijkt zes paren van waarnemingen. De volledige rekenregels staan in packaging-accounting; auditgevolgen in audit-trail.

Emballagediagram.