Logistieke orderflow

Waar LMF begint

LMF ontvangt niet alle orders via één ingestiekanaal. orders/dash/hub-dashboard lezen bestaande vers_order en order_regel. De logistieke uitvoering selecteert vooral bestaande leverancier_pakbon met optionele vers_order-link. Het aanmaken van gewone winkelorders/pakbonnen is upstream XLS-gedrag, geen aangetroffen LMF-ordercreatie.

Daarnaast maakt new_supplier_delivery een LMF-pakbon met footer en opgegeven emballage. assignment zoekt een locatie via supplier+debtor, zoekt diens HUB (lokatie_leverancier.levering=2), en maakt alleen bij positieve berekende emballagewaarde een pakbon/footer plus HUB-registraties. Een bestaande pakbon levert bij assignment een melding 'bijgewerkt' op zonder daadwerkelijke update.

Selectie en route

• logistics_deliveries vereist positieve user.route. Locatie-routeleden en, alleen bij ontbreken van locatieleden, leverancier-routeleden leveren klanten voor de route. Klant en locatie moeten actief zijn; postcode- en naamfilters worden toegepast, inclusief een expliciete postcodeuitsluiting. De route-eigenaar moet via leverancier_marktplaats toegang hebben tot klant.marktplaats, en de ingelogde gebruiker via actieve lmf_user_project. Ordermarktplaats moet null of gelijk aan klantmarktplaats zijn.
• Sortering: bruikbaar niet-negatief route_lokatie.nummer, minimum per locatie, daarna ID/datum/naam. Zonder route: lege deliveries.
• stops heeft andere, oudere SQL: pakbon.HUB + locatie + route_lokatie voor user.route en datum. Transporteurfilter is uitgecommentarieerd; project-/actieveklantfilters van logistics_deliveries ontbreken.
• stops maakt een pickup per HUB en delivery per locatie in hashes. Meerdere pakbonnen/dagen voor dezelfde partij overschrijven elkaar; keys %hash bewaart de SQL-volgorde niet. Het is daarom geen betrouwbare één-op-één afspiegeling van alle route-events.
• route_plan verwerkt alleen customer-stops met positieve locatie/sequence en wijzigt de unieke route_lokatie-rij die globaal bij de locatie gevonden wordt. route_id wordt gevalideerd/teruggegeven, maar niet gebruikt in de lookup; route_date niet gebruikt. Niet-customer-stops worden genegeerd. Dit is geen optimalisatie en geen gedateerd ritplan.

Uitvoering en afronding

accept_new_delivery: bij pakbon.guid en status_levering=0 → geaccepteerd=now(), status=1, transporteur=user.leverancier_id.

stop splitst de string-ID en roept pickup_stop/delivery_stop. Beide schrijven hoeveelheden per artikel/kvd, vandaag, partij en stop_id naar leverancier_emballage_registratie_stop. De opgegeven ritdatum bepaalt deze schrijfdatum niet. Dit verandert geen pakbonstatus of lmf_stop-status.

confirm_delivery: vindt pakbon via guid, voorkomt herhaalde bevestiging voor dezelfde pakbon+actor in applicatiecode, schrijft leverancier_pakbon_levering en eventueel geleverd_volgens_leverancier. Variabele status 1/3/5 wordt berekend maar de UPDATE is uitgecommentarieerd. Foto/handtekening worden na databasecommit naar bestanden geschreven. Er is hier dus geen aangetoonde volledige overgang van 'new' tot 'Delivered'.

keana_webhook is een apart trackingspoor: externalId → vers_order.id, statusnaam → order_status.id, update hub_status/transport_status en INSERT pakbon_levering met ETA/ATA/tracking. Het werkt niet status_levering bij.

Wat een getoonde status betekent

LMF kent labels 0 new, 1 Accepted, 2 On Route to Hub, 3 On Hub, 4 On Route to Customer, 5 Delivered. Labels zijn geen bewijs dat alle transities geïmplementeerd zijn. supplier_deliveries toont bij bestaande emballageregels lowercase delivered; customer_deliveries zet in de response status=5/editable=false bij verpakkingsgegevens. Geen corresponderende database-update op dat moment.

Stop-ready bij klant zoekt bovendien _pickup terwijl de klantstop als _delivery geregistreerd wordt; next_stop zoekt IDs zonder pakbondeel. Zie onzekerheden.

Orderflowdiagram. De doorstroom in het diagram staat voor aanroepen/data; een pijl betekent geen gegarandeerde fysieke overdracht.