XLS::LMF en de externe DASH-koppeling

Peildatum: 3 oktober 2026. Analyse op stuart, bron /usr/lib/perl5.

De gebruiker heeft bevestigd dat DASH extern staat en op aanvraag (OnDemand) de API gebruikt. Er is momenteel geen realtimeverbinding. De externe DASH-broncode, gebruikte API-host, specifieke verzoeken, caching en verwerking van antwoorden zijn niet ingezien. De onderstaande endpointbeschrijving is vastgesteld aan de LMF-kant; beschikbaarheid van een endpoint bewijst niet dat DASH dat endpoint daadwerkelijk aanroept.

Positie van XLS::LMF

XLSLMFHandler verzorgt requestbody, authenticatie en JSON; XLS::LMF dispatcht en verwerkt logistieke bedrijfsgegevens rechtstreeks via de geïnjecteerde XLS::Base-DBH. De module omvat leveranciersleveringen, inkomende/uitgaande HUB-registraties, klantleveringen, logistieke routes/stops, bevestigingen, emballage en connectorfuncties. De vier rolvlaggen bepalen de gewone endpointtoegang. EmballageControl is een aparte gedelegeerde module. RoutePlanImporter wordt geladen maar is niet aangesloten op het actieve route_plan-pad.

De belangrijkste gegevenslagen zijn vers_order, leverancier_pakbon met regels en emballage, leverancier_emballage_registratie, klant/lokatie, leverancier en route/route_lokatie. Dat zijn deels verschillende registraties en selecties; een telling in het ene overzicht hoeft niet dezelfde populatie als een ander overzicht te hebben. De reguliere rolroute dashboard voor grafieken is afzonderlijk van de vier dash_*-routes.

Bronnen: XLS/LMF.pm:41, :224, :1285, :1974, :2331, :2508, :3013, :4362; XLSLMFHandler.pm:36. De algemene architectuuranalyse en backendcatalogus beschrijven de overige functies.

Verzoekpad en toegang

sequenceDiagram
    participant D as Extern DASH
    participant H as XLSLMFHandler
    participant L as XLS::LMF
    participant B as XLS-database
    D->>H: OnDemand API-verzoek
    H->>B: Actieve lmf_user bij token
    H->>L: request, methode, gebruiker, parameters
    L->>B: Marktplaatstoegang en gegevensselectie
    B-->>L: Resultaat van de queries
    L-->>H: code en data
    H-->>D: JSON-antwoord

Voor dash_orders, dash_customers, dash_route_customers en dash_suppliers geldt:

POST /api/<endpoint>, normaal met Authorization: Bearer <uuid> en JSON start_date/end_date.
Het token moet bij een actieve lmf_user horen. De DASH-dispatch loopt vóór de gewone rolbranches en is beschikbaar voor alle vier LMF-perspectieven.
HUB, leverancier en logistiek krijgen de vereniging van marktplaatsen uit leverancier_marktplaats voor hun server-side leverancier_id.
Een klant krijgt de marktplaats uit klant.marktplaats bij zijn server-side klant_id.
Zonder afleidbare marktplaats: applicatiecode 403. Aangeleverde scopevelden zoals marketplace_id, klant_id of hub_id worden geweigerd; de client kiest de toegang niet zelf.
Geen beperking tot alleen eigen orders/locaties binnen die marktplaats. Geen aanvullende controle op lmf_user.dashboard, lmf_user_project, de toegewezen gebruikersroute of compleet_assortiment in dit DASH-pad.

Gevolg: een klant- of leveranciersaccount kan via deze endpoints gegevens van andere partijen binnen zijn marktplaats ontvangen. De scope wordt server-side bepaald, maar is breed. Of dat voor iedere rol bedoeld is, vraagt een expliciete autorisatieafspraak.

Bronnen: XLSLMFHandler.pm:173; XLS/LMF.pm:411-512. Tests leggen de bereikbaarheid voor alle rollen en deze marktplaatsselectie vast.

Vier beschikbare DASH-reads

| Endpoint | Bron/selectie | Antwoord | Betekenis | |---|---|---|---| | dash_customers | vers_order → lokatie → klant; filter op vers_order.afleverdatum | data.customers[]: id, name, latitude, longitude | Klantlocaties met orders in de periode; id is lokatie.id, niet klant.id | | dash_route_customers | Dezelfde orderselectie, aangevuld met route_lokatie/route; routeleverancier moet eigenaar van de marktplaats zijn | data.routes[]: id, name, customers | Bestaande routes en klantvolgorde; geen berekende optimale route | | dash_suppliers | Leverancier of HUB van geselecteerde vers_order | data.suppliers[]: id, name, latitude, longitude, can_act_as_hub, can_act_as_carrier | Partijen die in de orderselectie voorkomen; geen volledige leveranciers- of vervoerderscatalogus | | dash_orders | leverancier_pakbon → vers_order, leverancier, HUB en locatie; filter op pakbon lever_datum | data.orders[]: order, datum, bedrag, partijen, coördinaten, aantallen en volumes | Ordergegevens waarvoor een passende pakbon en gekoppelde HUB bestaan |

Bronnen: XLS/LMF.pm:867, :901, :1018, :1058.

Alle vier sluiten orders uit waarvan een ingevulde vers_order.marktplaats afwijkt van de marktplaats van de klant; NULL is wel toegestaan. Er is hier geen algemeen actief-filter op klant, locatie of leverancier en geen orderstatusfilter. Daardoor kan de populatie afwijken van logistics_deliveries, dat onder meer route-, project-, actief- en adresvoorwaarden toepast (LMF.pm:3013).

Bij meerdere geldige routes voor een locatie kiest dash_route_customers één route: geldig laagste niet-negatieve volgnummer, daarna routenaam en route-ID. De server logt de ambiguïteit. Locaties zonder geldige route vallen uit de routesresponse, terwijl ze wel in dash_customers kunnen staan. Binnen een route wordt op volgnummer en klantnaam gesorteerd; het volgnummer zelf wordt niet gepubliceerd.

Betekenis van bedragen, aantallen en actualiteit

order_amount is vers_order.bedrag × 100, afgerond naar een geheel aantal centen. Het is geen eurobedrag en geen berekend bedrag per pakbon.
customer_id is een numerieke locatie-ID. Dit wijkt af van GUID's die sommige gewone LMF-app-endpoints gebruiken.
*_incoming_packages, *_outgoing_packages en volumes komen uit leverancier_emballage_registratie, via artikelgegevens. De sleutels zijn HUB + leverancier + dag en HUB + locatie + dag; niet order-ID of pakbon-ID.
Die totalen worden op iedere passende orderrij herhaald. Voorbeeld: drie orders bij dezelfde HUB/locatie/dag en een dagregistratie van 10 kratten kunnen ieder 10 tonen. Optellen geeft dan ten onrechte 30.
Leverancierdagtotalen zijn niet verder toegerekend aan de geselecteerde klantorders of marktplaats. Ze kunnen meer omvatten dan de orderselectie van DASH. De registratiequery filtert op HUB/partij/datum, niet opnieuw op marktplaats.
De aggregator telt ook onbevestigde registraties mee. Volume gebruikt eerst lengte × breedte × hoogte / 1.000.000, anders artikelvolume, anders nul; de maateenheid is hiermee niet zelfstandig bewezen.
De vier reads bevatten geen writes in hun onderzochte querypad. Preloadcaches leven alleen binnen het verzoek. Dit bewijst niet dat de externe DASH-client zijn eigen cache direct ververst.
Afzonderlijke OnDemand-verzoeken delen geen snapshot-ID. Tussen twee verzoeken kunnen registraties wijzigen; de endpoints leveren ook verschillende populaties/datumselecties.

Bronnen: XLS/LMF.pm:1058-1168, :3644, :3731, :3979-4074.

Mogelijke terugschrijfroute: route_plan

Beschikbaar in LMF; feitelijk gebruik vanuit DASH niet bevestigd. POST /api/route_plan zit in de logistieke rolbranch. Het verwerkt alleen stops met type=customer, positieve location_id en positieve sequence; dubbele locatie-ID's worden afgewezen.

De implementatie zoekt route_lokatie uitsluitend op lokatie, verwacht precies één rij en wijzigt daarvan nummer. Het meegegeven route_id is verplichte responsecontext, geen routefilter; de regressietest accepteert expliciet een externe route-ID. route_date wordt toegestaan maar niet gebruikt. HUB-/supplierstops worden overgeslagen. Er wordt geen gedateerd lmf_route/lmf_stop-plan opgeslagen.

Belangrijk: de accountcontrole vereist een logistieke gebruiker en leverancier-ID, maar controleert geen eigendom/project/marktplaats van de aangeleverde locaties. Dit pad hergebruikt de DASH-readscope niet. Een eventuele uitbreiding moet een onafhankelijke eigendomscontrole toevoegen; een externe planner-ID mag niet zonder afspraak als interne route.id worden behandeld. Bij meerdere bestaande routerijen voor een locatie volgt 409; bij geen rij 422.

Een opgeslagen volgnummer beïnvloedt de vaste routegegevens en kan daardoor latere selecties beïnvloeden, niet alleen een planning op route_date. Dit is een wezenlijk ander contract dan de aanwezige, niet-aangesloten RoutePlanImporter.

Bronnen: XLS/LMF.pm:179, :224-409; t/lmf_route_plan_route_lokatie_update.t:249.

Foutafhandeling, contract en aanbevolen vervolg

Autorisatie vastleggen: beslis welke rollen marktbrede DASH-data mogen lezen en of routewrites dezelfde marktplaats-/projectgrens moeten volgen. Pas dit niet stilzwijgend aan: huidige tests bevestigen de brede readscope en externe route-ID.
Aggregatie expliciet maken: beschrijf aantallen als partij/dagtotalen of lever ze als afzonderlijke, uniek gesleutelde verzameling. Bevestig met de externe DASH-beheerder of er nu per order gesommeerd wordt.
Bestaand protocol vastleggen: de handler vertaalt code in het JSON-antwoord niet algemeen naar de HTTP-status. DASH moet ook de JSON-code beoordelen. Ongeldige JSON is een uitzondering met een echte HTTP 400. Tokenfouten komen als applicatiecode 500 (Login fout!). Een migratie naar correcte HTTP-statussen moet met DASH worden afgestemd.
Datums en omvang valideren: de vier DASH-reads binden start/eind rechtstreeks aan SQL. Geen expliciete ISO-datumvalidatie, start ≤ eind, maximumperiode of paginering gevonden in dit pad. Queries en volledige resultaten worden in geheugen verwerkt. De batching vermindert queries, maar begrenst geen exportomvang.
Documentatie bijwerken vóór uitbreiding: /var/bestelsysteem/MD/openapi/XLS_LMF.openapi.yaml bevat geen dash_*-routes en beschrijft bij route_plan nog project-/stopsetcontroles die de actieve updater niet uitvoert. Het document benoemt zichzelf als niet-canoniek. Deze analyse wijzigt het API-gedrag of dat bestand niet.

Bronnen: XLSLMFHandler.pm:63-73, :154-170; OpenAPI :565; genoemde DASH-functies.

Verificatie en grenzen

Broncommit: 17c1a9152f82a0d018b968e1cb44fd7ea9c5e836.

Geteste bronbestanden (SHA-256):

XLS/LMF.pm: 14940e620ae765abbcc8f2383a7182ca506c44b7dbbf354051f9435685d5b2f6.
XLSLMFHandler.pm: 7940c4b127b21277dc1c8a8df636a162105dbf20d495dbdf87c7caabdf089b40.

Uitgevoerd:

prove -I. t/lmf_dash_read_endpoints.t t/lmf_route_plan_route_lokatie_update.t t/lmf_handler_request_body.t t/lmf_route_batching.t

PASS: 4 bestanden, 43 top-level tests/subtests. Tests gebruiken fixtures/mocks, geen productiegegevens. Zij controleren onder meer rol-/marktplaatstoegang, scopeparameterafwijzing, routekeuze, antwoordvorm, HUB-isolatie, batching, read-only DASH-paden, requestbody en de beperkte route_lokatie-update. Geslaagde tests bewijzen bestaand gedrag, niet dat alle autorisatie- of bedrijfskeuzes gewenst zijn.

De bron en geteste versie zijn hierboven vastgelegd. De in bestaande Apache-workers geladen versie is niet afzonderlijk vastgesteld; geen herstart uitgevoerd. Geen productie-API-aanroepen, databasewijzigingen of externe DASH-tests uitgevoerd. Alleen lokale analysedocumentatie aangevuld.

Bootstrap gelezen: INDEX.md, SYSTEM_BOUNDARIES.md, SYSTEM_TOPOLOGY.md, TRUTH_PRECEDENCE.md, relevante bestaande LMF-analyse/OpenAPI en batchingstatus. Deze analyse beschrijft broncodegedrag en is geen nieuw canoniek contract.

dash-integration.md