XLS::LMF — overdraagbare feitelijke analyse

Peildatum 2026-10-03, stuart, backendbron /usr/lib/perl5 commit 17c1a9152f82a0d018b968e1cb44fd7ea9c5e836. Analyse voor latere functionele/visuele documentatie; geen nieuwe architectuur of website gebouwd. Volledig rapport: docs/lmf-analysis/. Dit bestand kan zelfstandig aan ChatGPT worden gegeven.

Bewijsstatus: CONFIRMED = direct in code/catalogus; LIKELY = afleiding; UNCLEAR = onvoldoende bewijs; NOT FOUND = binnen onderzochte scope niet aangetroffen. CONFIRMED betekent niet automatisch interactief getest of correct werkend.

Wat LMF werkelijk is

XLS::LMF is een Perl JSON-service achter XLSLMFHandler/mod_perl op /api. De handler bouwt XLS::Base/DBH/params, valideert actieve lmf_user met Bearer-UUID en dispatcht request + rol. Data bestaat uit gewone hashrefs, PostgreSQL-rijen en wisselende JSON-enveloppen. Sommige leesoverzichten vullen GUID's in en committen. Er is geen uniforme ORM of volledige logistieke statusmachine.

React-runtime: Apache /var/bestelsysteem/lmf-app → /mnt/storage/lmf_app/build, bundel main.7e850739.js. Dezelfde bundel in lmf_buildv0027.zip is byte-identiek; oorspronkelijke componenten zijn uit diens sourcemap herleid. React/Redux/thunk/Router/Axios/MUI, Chart.js, camera/handtekening en @react-google-maps/api. Redux login/current_information (periode/navigator) blijft in localStorage. Axios: https://window.BASE_URL/api, JSON + Bearer.

Backendbron, geteste werkboom en geserveerde React-build zijn vastgesteld. De geladen Perl-versie van reeds draaiende Apache-workers en browsercaches zijn niet vastgesteld. Negen fixture/static testbestanden slaagden, 76 top-level tests/subtests, geen databasischrijftests. Catalogus van 36 tabellen read-only via XLS::Base gecontroleerd; geen bedrijfsrijen gelezen.

Vier perspectieven en acties

| Perspectief | React-componenten | Aantoonbare backendacties | |---|---|---| | Leverancier | SupplierDeliveries, SupplierDeliveryDetail, NewSupplierDelivery, SupplierOrders, SupplierProducts, SupplierDashboard | eigen orders/producten; pakbonnen; nieuwe levering; bevestiging; API voor aanpassen/connector | | HUB | HubIncoming, HubOutgoing, gedeeld HubDeliveries, HubDashboard | leverancierzijde ontvangen/retour; klantzijde uitgeven/retour; overzichten; aanvullende kaart/route/controle-API's | | Logistiek | LogisticsDeliveries, LogisticsStops, LogisticsStopDetail, LogisticDeliveryDetail, NewLogisticsDeliveries, LogisticsDashboard | user.route-overzichten; afgeleide stops; aantallen per stop; vrije pakbon accepteren; bevestiging; volgorde-API | | Klant | CustomerDeliveries, CustomerDeliveryDetails, CustomerSettings, LocationSelector, CustomerDashboard | actieve locaties, leveringen/ETA/emballage, ontvangstformulier, locatiebijzonderheden |

Serverdispatch-prioriteit: hub → klant → leverancier → logistiek. Profiel/role-prioriteit: klant → leverancier → hub → logistiek. Meerdere true-flags kunnen verschil geven. Supplier/HUB/carrier zijn verschillende rollen van leverancier, niet aparte partijtabeltypen. Klantaccount=klant, afleverlocatie=lokatie.

Belangrijkste API-mapping

Alle frontendacties hieronder gebruiken POST onder /api; login/identify hebben hun eigen authenticatiegedrag.

| Component/actie | Endpoint → functie | Kerngegevens | |---|---|---| | Login | login → handler.authen → role/klant/hub/leverancier/logistiek | lmf_user, accounts/locaties/catalogus/config | | SupplierOrders/Products | orders → order_regels; products | vers_order/order_regel/product | | SupplierDeliveries/Detail | supplier_deliveries; supplier_delivery → supplier_deliveries | eigen pakbonnen via guid | | NewSupplierDelivery | new_supplier_delivery | pakbon/footer/geleverd_volgens_leverancier | | SupplierDeliveryDetail | confirm_supplier_delivery → confirm_delivery | actorbevestiging + outbound hoeveelheden | | HubIncoming/Outgoing | hub_incoming / hub_outgoing | pakbonnen + HUBregistraties/catalogus | | HubDeliveries | hub_incoming_deliveries / hub_outgoing_deliveries | inkomend/uitgaand, bevestigd, actor/bronlinks | | LogisticsDeliveries | logistics_deliveries | routeleden, pakbonnen, projectmarktplaats | | LogisticsStops/StopDetail | stops; stop → pickup_stop/delivery_stop | afgeleide stop-ID, opgehaald/afgeleverd | | LogisticDeliveryDetail | accept_new_delivery; confirm_logistics_delivery | pakbonstatus0→1; aparte actorbevestiging | | CustomerDeliveries/Details | customer_deliveries; confirm_customer_delivery | klantlocatie/pakbon; contractverschillen aanwezig | | CustomerSettings | location_comment | lokatie.bijzonderheden | | Vier dashboards | dashboard → rolgebonden *_dashboard | ordercounts en top10 productgroepen |

Geen Reactcall in geverifieerde build: dash_orders/customers/route_customers/suppliers, route_plan, emballage_hub_control, return_packaging, postcode, check_token, hub_routes/vehicles/orders/customers/suppliers/productdetails, update_supplier_delivery. Er kunnen andere clients zijn; niet bewezen.

Gedeeld: GroupedDeliveries/GroupbyOptions/DateRangePicker; EmballageDrawer maakt {id,number,package_type}; GoogleMapCustom; Signature/Camera-components. Leveringen als accordions, orders/producten als tabellen, dashboards als charts. Emballagecontrole/saldo heeft geen gevonden Reactscherm.

Domein en tabellen

• Identiteit/scope: lmf_user, lmf_user_project, lmf_project, klant, lokatie, leverancier, lokatie_leverancier, marktplaats, leverancier_marktplaats.
• Orders: vers_order, order_regel, product, productgroep, order_status.
• Uitvoering: leverancier_pakbon, leverancier_pakbon_regel, leverancier_pakbon_footer, leverancier_pakbon_levering.
• Vaste routes: route, route_lokatie, user.route; voertuigcapaciteit en kosten uit voertuig.
• Apart importerplan: lmf_route(project,route_id,route_date,transporteur_id,status,timestamps), lmf_stop(type,volgnummer,partij), lmf_stop_leverancier_pakbon. Niet gebruikt door huidige route_plan/stops-dispatch.
• Emballage: leverancier_emballage_artikel, leverancier_pakbon_emballage, leverancier_emballage_registratie, leverancier_emballage_registratie_stop.
• Config/log/branding: navigator, klant_koppeling, leverancier_koppeling, leverancier_apikey, lmf_log, lmf_bezoeker, lmf_pagina, domain.

Alle onderzochte tabellen hebben PK id behalve lmf_stop_leverancier_pakbon met samengestelde PK. Concrete FK's/kolomtypen/read/write-lijsten staan in database.md en evidence/database-schema.json. CTE's scoped_customers/scoped_pakbon zijn geen echte tabellen.

Identifiers: supplier delivery_id = pakbon.guid; logistiek/klant delivery_id vaak pakbon.levering. confirm_delivery zoekt guid. packages({leverancier_pakbon=>...}) verwacht guid; logistic_packages verwacht levering. Klantlijst location_id = lokatie.guid; HUB-location_id en dash customer_id = lokatie.id. Actieve stop_id is partij_pakbon_pickup|delivery, geen lmf_stop.id.

Werkelijke orderflow

Bestaande orders/pakbonnen of LMF-manuele/connectorpakbon → selectie op periode/rol/route/scope → deliveries of afgeleide stops → acceptatie of hoeveelheidsregistratie/bevestiging. Gewone ordercreatie is upstream, geen LMF-ingestietransactie.

logistics_deliveries leest user.route, actieve klant/locatie, route-eigenaarmarktplaats en actieve user-projecttoegang; sorteert op route_lokatie.nummer. stops heeft oudere, ruimere filters en dedupliceert via hashes op partij, waardoor meerdere pakbonnen/dagen en SQL-volgorde verloren kunnen gaan.

accept_new_delivery zet status0→1, geaccepteerd en transporteur. confirm_delivery schrijft bevestiging en outbound-emballage; de statusupdate is uitgecommentarieerd. Statuslabels 0..5 bestaan, maar alle overgangen zijn niet geïmplementeerd. Sommige responses tonen Delivered puur omdat emballageregels bestaan.

route_plan is POST-only en verwerkt alleen customer-stops: positieve route-ID/locatie/sequence, unieke locatie; globale lookup route_lokatie op lokatie, dan nummer-update. route_id wordt niet gebruikt als SQL-filter; route_date niet toegepast; geen project-/eigenaarscontrole. De uitgebreidere RoutePlanImporter met locks, projectchecks en idempotente plan/stopsync is wel aanwezig/getest maar niet aangesloten.

Emballageflow en boekhouding

KVD/package_type: 1 Koel, 2 Vries, 3 Droog; artikel-ID bepaalt verpakkingssoort.

| Bron | Wat wordt bewaard | |---|---| | leverancier_pakbon_emballage | actuele geleverd/retour en leveranciergemelde waarden, kvd, ontvangen/verstuurd; geen actor/tijd | | leverancier_emballage_registratie | HUB + supplier of locatie, datum, inkomend/uitgaand, bevestigd, lmf_user, nullable pakbon/levering | | leverancier_emballage_registratie_stop | actor/tijd, bezochte partij, opgehaald/afgeleverd, kvd, string stop_id, nullable pakbon |

HUB-leverancierzijde packages→inkomend, returned→uitgaand. HUB-klantzijde packages→uitgaand (altijd INSERT), returned→inkomend (UPDATE/INSERT). HUB-updatekey mist kvd/pakbon. Chauffeur packages→afgeleverd, returned→opgehaald; vandaag/now(), update per partij/artikel/kvd/stop/dag. Wijzigingen overschrijven oude aantallen zonder actor/tijdrevisie.

new_supplier_delivery schrijft geleverd_volgens_leverancier; update_supplier_delivery schrijft geleverd. confirm_delivery verwerkt alleen outbound_packages als geleverd_volgens_leverancier en negeert retouren. return_packaging doet geen write, alleen SELECT met misleidende succesmelding.

Bronlinkhelper: expliciete pakbon, guid, levering of unieke HUB/partij/dag. Ontbrekende/ambigue bron blokkeert registratie niet; oude records niet backfilled. Meerdere pakbonnen bij levering zijn niet steeds eenduidig. Geen uniform from/to-partijenrecord.

Geen boekhoudkundig begin-/eindsaldomodel in LMF gevonden. Er zijn afzonderlijke SUM(geleverd)/SUM(retour), SUM(inkomend)/SUM(uitgaand), aantallen/volumes en pakbonwaarde aantal×actuele artikelprijs. Dit zijn geen doorlopende partijensaldi. Dezelfde beweging kan in meerdere bronnen bevestigd zijn; bronnen optellen telt dubbel.

_preload_guid_packages groepeert guid/artikel/kvd en kiest perspectiefvelden; _preload_delivery_packages levering/artikel/kvd. _preload_registration_details_by_entity_date en dash-variant groeperen HUB/partij/datum/artikel/kvd. _registration_totals telt de vier hoeveelheid/volumekolommen afzonderlijk op. Volume=COALESCE(lengte×breedte×hoogte/1000000 met NULLIF(0), volume, 0). Maat-eenheid niet bewezen. hub_orders/dash_orders herhalen partij/dagtotalen op orderrijen; niet blind sommeren.

EmballageControl is een read-only vergelijking, geen saldo. Ketenkey pakbon/artikel/kvd, anders levering/artikel/kvd, anders bronrij. Alleen unieke harde referenties linken. Nul→niet geregistreerd; dubbele slots→ambiguous, niet optellen. Zes verschillen links−rechts:

1. supplier_delivered − hub_supplier_in;
2. hub_customer_out − logistics_customer_delivered;
3. logistics_customer_delivered − customer_delivered;
4. customer_returned − logistics_customer_picked;
5. logistics_customer_picked − hub_customer_in;
6. hub_supplier_out − supplier_return_received.

Beide ontbreken: paar overgeslagen; één ontbreekt: missing; ongelijk: difference; gelijk: aligned. Ketenprioriteit ambiguous > difference > missing > aligned. Summary telt ketens, geen aantallen/geld. Eigen HUB-scope, maximaal31 dagen verschil, >2000 bronrijen fout, paginalimiet250. Runtimeafwijking: filters accepteert base.params alleen bij ref(base) eq HASH; echte XLS::Base is blessed en verliest zo params. Met een synthetisch blessed object reproduceert daterange_required. Fixturetests gebruiken gewone hashes.

Buiten LMF bestaat XLS::Logistiek::emballage_saldo op andere tabellen emballage/emballage_lokatie: per locatie/code som h-aantallen minus andere richtingen, geen datumfilter. Geen call/synchronisatie vanuit LMF gevonden. ShopAPP/Administratie schrijft dezelfde pakbonemballage en berekent netto pakbonwaarde (geleverd-retour)*prijs; dat is geen bewijs van een LMF-grootboek.

Maps en integraties

GoogleMapCustom vraagt via Google DirectionsService een DRIVING-route tussen from/to en rendert die met DirectionsRenderer. Geen meerstops/waypoints/optimizer in appcode. Zonder from staat een custom midden-icoon; Marker gebruikt lat/lng niet voor Google-markerposition. useEffect hangt alleen van isLoaded af, geen lokale route-errorcatch. Google/Waze-links navigeren naar bestemming; geen plannerresultaat terug. Hub-Waze gebruikt een latitudet-typo.

Keana: publieke callback keana → authenticate POST /logistics/api/auth/token → Bearer GET /logistics/api/delivery/id/tracking/tracking_id. history.externalId→vers_order; statusnaam→order_status; update hub_status/transport_status; insert pakbon_levering met ETA/ATA/tracking en vaste actor39. Geen inkomende handtekeningcheck/eventdedup in dit pad; commits per stap. Credentials/tokenwaarden niet opgenomen. Client heeft submit_delivery/get_trip, maar geen aanroep vanuit LMF aangetroffen.

XLS::Postcode→PostcodeNL-adreslookup; Base.ip_info voor branding. Connector assignment/download_orders/log, uploadstubs. NewSupplierDelivery kan base64+prompt naar externe packaging_prompt_base64-API sturen, buiten LMF. Backend zelf optimaliseert geen route; leverancier van eventuele externe route_plan-client UNCLEAR.

Belangrijkste afwijkingen en auditgrenzen

• CustomerDeliveries stuurt geen location_id ondanks vereiste backendfilter.
• CustomerDeliveryDetails stuurt packages, confirm leest outbound_packages; alle confirm-retouren worden genegeerd.
• Levering/guid-verschil kan bevestiging breken.
• registerStopEmballage mist een data-niveau in de respons; databasewrite kan wel slagen.
• stops ready zoekt voor klant _pickup i.p.v. _delivery; next_stop mist pakbondeel.
• Geen uniforme objectautorisatie; onder meer route_plan, location_comment, stop en sommige confirm/updatepaden hebben beperkte scope.
• Veranderbare aantallen/prijzen/actorrelaties, geen before/after of openingsstand. Geen niet-interne triggers op de onderzochte emballagebronnen die verborgen saldi bijhouden.
• Foto/handtekening na DBcommit; bestandsfout kan alsnog succesmelding geven.
• Runtimegebruik, datavolledigheid/duplicaten, externe audits, browsercache en bedoelde business-saldodefinitie zijn UNCLEAR. Er zijn geen productiebedrijfsrecords gelezen of mutaties uitgevoerd om dit te verifiëren.

Richtlijn voor latere interactieve uitleg

Gebruik bestaande namen/IDs en onderscheid zichtbare frontendacties, beschikbare backend-API's, niet-aangesloten modulepaden en ontbrekende functies. Toon wie → component → request → functie → query/registratie → resultaat, inclusief contractafwijkingen. Maak van statuslabels, ontvangstmeldingen of controles geen veronderstelde boekingen, fysieke overdrachten of werkende saldoflow. Nieuwe businessregels vragen apart besluit; dit rapport vult ze niet in.

Belangrijkste diagrammen

flowchart LR
  React["React app"] --> Handler["XLSLMFHandler"]
  Handler --> Base["XLS::Base"]
  Handler --> LMF["XLS::LMF"]
  Base --> Conn["XLS::Base::Connection"]
  Conn --> DB["DBI / PostgreSQL"]
  LMF --> DB
  LMF --> Datum["XLS::Datum"]
  LMF --> GUID["Data::GUID"]
  LMF --> XML["XML::TreePP"]
  LMF --> Control["EmballageControl: controle"]
  Control --> DB
  LMF -. "geladen; factory niet aangeroepen" .-> Importer["RoutePlanImporter"]
  Importer --> DB
  LMF --> Postcode["XLS::Postcode"]
  Postcode --> NL["Net::PostcodeNL::WebshopAPI"]
  LMF --> Keana["Keana::API"]
  Keana --> HTTP["LWP / HTTP::Request / JSON"]
  React --> Maps["Google Maps JS"]

flowchart TD
  Existing["Bestaande vers_order + order_regel"] --> Slip["Bestaande leverancier_pakbon"]
  Manual["new_supplier_delivery of connector assignment"] --> Slip
  Slip --> Select["Selectie periode, rol, route of marktplaats"]
  Fixed["route + route_lokatie + user.route"] --> Select
  Select --> Deliveries["logistics_deliveries: lijst"]
  Select --> Stops["stops: afgeleide HUB- en klantstops"]
  Slip --> Accept["accept_new_delivery: status 0 naar 1"]
  Stops --> Registration["stop: opgehaald/afgeleverd registreren"]
  Deliveries --> Confirm["confirm_delivery: actorbevestiging"]
  Confirm --> Evidence["pakbon_levering + supplierhoeveelheid"]
  Confirm --> NoTransition["Geen actieve status_levering-update"]
  Keana["Keana callback + history"] --> Status["vers_order hub_status/transport_status"]
  Keana --> Tracking["pakbon_levering: ETA, ATA, tracking"]
  PlanInput["Aangeleverde customer.sequence"] --> Update["route_plan: route_lokatie.nummer"]
  Update --> Fixed

flowchart TD
  Supplier["Leverancier: opgegeven aantallen"] --> Slip["pakbon_emballage: volgens leverancier"]
  HubIn["HUB leverancierzijde: heen en retour"] --> HubReg["emballage_registratie: inkomend/uitgaand"]
  HubOut["HUB klantzijde: heen en retour"] --> HubReg
  Driver["Chauffeur: stop packages/returned_packages"] --> StopReg["emballage_registratie_stop: afgeleverd/opgehaald"]
  Other["Andere XLS-pakbonschermen"] --> Customer["pakbon_emballage: geleverd/retour"]
  Slip --> Ctrl["EmballageControl: harde bronlinks"]
  Customer --> Ctrl
  HubReg --> Ctrl
  StopReg --> Ctrl
  Ctrl --> Compare["Zes paren waarnemingen vergelijken"]
  Compare --> Result["aligned / difference / missing / ambiguous"]
  Result --> Limit["Geen beginstand of eindbalans"]
  ReturnEndpoint["return_packaging endpoint"] --> ReadOnly["Alleen SELECT; geen retourwrite"]

flowchart LR
  Supplier["Leverancier"] --> SO["Orders/producten/dashboards lezen"]
  Supplier --> SD["Levering aanmaken en bevestigen"]
  Hub["HUB"] --> HI["Ontvangst leverancier en retour"]
  Hub --> HO["Uitgifte klant en retour"]
  Hub --> HC["API: emballagecontrole"]
  Logistic["Logistiek"] --> LL["Leveringen/ritten bekijken"]
  Logistic --> LS["Stopaantallen en acceptatie"]
  Logistic --> LP["API: aangeleverde volgorde opslaan"]
  Customer["Klant"] --> CD["Locatie/leveringen/ETA bekijken"]
  Customer --> CC["Ontvangstbevestiging; contractafwijkingen"]
  SO --> Orders["vers_order + regels"]
  SD --> Slip["pakbon + emballage + bevestiging"]
  HI --> HubReg["HUB-registratie"]
  HO --> HubReg
  HC --> Sources["Drie bronsoorten vergelijken"]
  LL --> Routes["route_lokatie + pakbon"]
  LS --> StopReg["stopregistratie / pakbonacceptatie"]
  LP --> Routes
  CD --> Slip
  CC --> Slip