End-to-end traces

Bronnamen van React komen uit de byte-identieke build-sourcemap, zie frontend. Deze traces volgen code; ze zijn geen verklaring dat alle paden interactief getest zijn.

1. Logistiek overzicht — CONFIRMED

Logistieke gebruiker kiest periode
↓ LogisticsDeliveries → GroupedDeliveries (useState/useSelector)
↓ services/logistics.fetchLogisticDeliveries: POST /api/logistics_deliveries
↓ XLSLMFHandler: Bearer → actieve lmf_user
↓ XLS::LMF::handle_request → logistics_deliveries
↓ preload helpers, XLS::Datum, role/logistiek
↓ route_lokatie/route + pakbon/regels + lokatie/klant + lmf_user_project/lmf_project
↓ eventueel ontbrekende pakbon.levering invullen en commit
↓ {code:200, deliveries:[from,to,suppliers,packages,status,volgnummer],role:...}
↓ groepen/accordions; keuze opent LogisticDeliveryDetail

2. Routeweergave op kaart — CONFIRMED, tweepuntsroute

Gebruiker opent leveringsdetail
↓ SupplierDeliveryDetail / CustomerDeliveryDetails / LogisticDeliveryDetail
↓ lijstresponse of supplier_delivery-request levert from/to-coördinaten
↓ LMF supplier_deliveries / customer_deliveries / logistics_deliveries
↓ leverancier.latitude/longitude en lokatie.lat_lng, partnerhelpers
↓ GoogleMapCustom krijgt from/to
↓ browser DirectionsService.route(origin,destination,DRIVING) naar Google
↓ Google routes-resultaat → DirectionsRenderer
↓ kaart of aparte Google/Waze-navigatielink

Geen routeoptimalisatie of planwrite in deze trace. Routes over meerdere stops zijn niet door deze kaartcomponent bewezen. Het API-pad dash_route_customers → route_lokatie bestaat los hiervan, zonder frontendcall in deze build.

3. Stop/levering — write CONFIRMED, UI-response afwijkend

Chauffeur kiest Mijn Ritten / stop
↓ LogisticsStops → fetchLogisticStops POST /api/stops
↓ XLS::LMF::stops → route_lokatie + leverancier_pakbon + stopregistratie
↓ {data:{stops:[samengestelde stop_id,coords,ready,...]}}
↓ LogisticsStopDetail → registerStopEmballage POST /api/stop
↓ LMF.stop → delivery_stop of pickup_stop
↓ INSERT/UPDATE leverancier_emballage_registratie_stop; commit; opnieuw stops
↓ {code:200,data:{stops:{code:200,data:{stops:[...]}}}}
↓ frontend verwacht response.data.stops.data.stops; mismatch, zie uncertainties

4. Emballage registreren bij HUB — CONFIRMED

HUB kiest leverancier en datum
↓ HubIncoming → HubDeliveries → EmballageDrawer
↓ fetchIncomingHub POST /api/hub_incoming → LMF.hub_incoming
↓ pakbon, artikelcatalogus, HUB-registraties → inkomende/uitgaande aantallen
↓ invoer [{id,number,package_type}] + supplier_id + delivery_date
↓ registerIncomingGoodsHub POST /api/hub_incoming_deliveries
↓ LMF.hub_incoming_deliveries → _emballage_source_reference
↓ UPDATE/INSERT leverancier_emballage_registratie inkomend; bevestigd=1; commit
↓ code/message → frontend herlaadt HubIncoming

Bij onduidelijke bron wordt zonder pakbonlink geregistreerd; een succesmelding bewijst geen volledige bronketen.

5. Emballage retour — CONFIRMED via HUB/stop, niet via return_packaging

HUB registreert retour bij een klantlocatie
↓ HubOutgoing → HubDeliveries → retourdrawer
↓ returned_packages + location_id + delivery_date
↓ POST /api/hub_outgoing_deliveries
↓ LMF.hub_outgoing_deliveries → bronreferentiehelper
↓ UPDATE/INSERT HUB-reg.inkomend; actor bij INSERT; bevestigd=1; commit
↓ code/message → herladen locatie/datumoverzicht

Bij chauffeur is returned_packages → stop → opgehaald. Bij SupplierDeliveryDetail/CustomerDeliveryDetails worden retourarrays wel verstuurd maar door confirm_delivery niet verwerkt. Het gelijknamige API-endpoint return_packaging leest slechts pakbon/HUB en heeft geen frontendcall in deze build.

6. Emballagesaldo — NOT FOUND; dichtstbijzijnde werkelijke controletrace

Een saldo-React-component, saldo-request en saldo-eindstand zijn niet aangetroffen. Ze worden daarom niet als bestaande flow getekend.

HUB-API-client (Reactscherm niet gevonden) vraagt periode/filters
↓ /api/emballage_hub_control [eventueel chain_id]
↓ XLSLMFHandler → LMF.handle_request
↓ XLS::LMF::EmballageControl.handle_request / _filters
↓ _packing_rows + _hub_rows + _stop_rows (alleen SELECT)
↓ drie emballagebronnen, artikel, pakbon, lmf_user/leverancier
↓ _chains → _finalize_chain: zes vergelijkingen
↓ {data:{summary,items,pagination}} of {data:{detail:{sources,comparisons,...}}}
↓ API-response beschikbaar; React-weergave in actieve build NOT FOUND

Dit is een verschillencontrole, geen saldo. Het aparte oudere XLS::Logistiek.emballage_saldo gebruikt emballage_lokatie en geen React/LMF-pad.

7. Leverancierbevestiging — CONFIRMED met beperkte betekenis

Leverancier opent /supplier-delivery-detail/:id
↓ SupplierDeliveryDetail → fetchSupplierDelivery POST /api/supplier_delivery
↓ supplier_deliveries op eigen leverancier en pakbon.guid
↓ formulier met outbound_packages/returned_packages/comment/photo/signature
↓ confirmSupplierDelivery POST /api/confirm_supplier_delivery
↓ confirm_delivery: pakbon+actor al bevestigd? anders INSERT bevestiging
↓ UPDATE/INSERT geleverd_volgens_leverancier; commit; optioneel bestanden
↓ code/message; geen status-update en geen retourwrite

8. Aangeleverde volgorde — CONFIRMED API, frontendcaller UNCLEAR

Externe/onbekende client stuurt route_id, route_date, stops
↓ POST /api/route_plan als logistieke gebruiker
↓ LMF.route_plan → _route_plan_update_route_locations
↓ valideert customer.location_id/sequence; route_lokatie lookup op locatie alleen
↓ UPDATE route_lokatie.nummer, commit
↓ {data:{route_id,customer_stops,updated}}
↓ reactie voor client; geen gekoppeld Reactscherm aangetroffen