Boekhoudkundige emballagepositie
Conclusie binnen LMF
NOT FOUND: een LMF-endpoint of React-scherm voor een reproduceerbare beginstand + uitgifte − retour ± correcties = eindstand per partijenpaar. De code heeft actuele aantallen per bron en een diagnostische vergelijking. Een getoond aantal pakketten, netto pakbonbedrag of aantal afwijkingsketens is geen emballagesaldo.
CONFIRMED: er bestaan berekeningen, hieronder exact gescheiden. Er zijn geen niet-interne triggers op de onderzochte LMF-emballagetabellen in de live catalogus die hier verborgen saldoboekingen toevoegen. Andere applicaties kunnen dezelfde tabellen wel aanpassen.
Bestaande berekeningen
| Functie/query | Groepering | Berekening |
|---|---|---|
| _preload_guid_packages (LMF:4077) → packages | pakbon.guid + artikel + kvd | SUM(geleverd), SUM(retour), SUM(geleverd_volgens_leverancier), SUM(retour_volgens_leverancier); leverancier_id>0 kiest leverancierswaarden, klant kan fallback krijgen |
| _preload_delivery_packages (LMF:4141) → logistic_packages | pakbon.levering + artikel + kvd | SUM(geleverd) en SUM(retour), null→0; geen aftrekking |
| _preload_registration_details_by_entity_date (LMF:3884) | één HUB + leverancier of locatie + datum + artikel + kvd | SUM(COALESCE(inkomend,0)), SUM(COALESCE(uitgaand,0)), MAX(bevestigd) |
| _preload_dash_registration_details_by_entity_date (LMF:3993) | hetzelfde met HUB als expliciet groeps-/cachesleuteldeel | dezelfde sums; filter op gewenste HUB/partij/datumcombinaties |
| _registration_totals (LMF:3731) | ontvangen detailrijen | afzonderlijk optellen inkomend/uitgaand/aankomstvolume/vertrekvolume |
| hub_orders/dash_orders | per orderresponse, met partij/datumtotalen | toont die totalen op iedere orderrij; één partij/dag kan meerdere orderrijen hebben, dus responsekolommen niet blind over orders sommeren |
| new_supplier_delivery/update_supplier_delivery/assignment | één pakbon | som ingevoerde aantal × huidige leverancier_emballage_artikel.prijs → footer.totaal_emballage_bedrag; geen periode- of partijenbalans |
Volume per artikel in de HUB-queries is letterlijk:
unit_volume = COALESCE(
NULLIF(lengte,0) * NULLIF(breedte,0) * NULLIF(hoogte,0) / 1000000,
volume,
0)
incoming_volume = SUM(COALESCE(inkomend,0) * unit_volume)
outgoing_volume = SUM(COALESCE(uitgaand,0) * unit_volume)
Code bewijst de deler, niet de fysieke meeteenheid van de opgeslagen maten. Orderresponse rondt volumes af op drie decimalen; order_amount wordt afgerond naar centen. Dit zijn logistieke totalen, geen eigendomssaldi.
EmballageControl: exacte vergelijkingslogica
Runtimebeperking (CONFIRMED, U20): _filters accepteert params alleen als ref(base) eq HASH. De handler geeft een blessed XLS::Base-object; daardoor worden geldige datumparameters genegeerd en volgt date_range_required. Onderstaande rekenlogica bestaat en is fixture-getest, maar deze ingang blokkeert het normale HTTP-pad.
Bronselecties: _packing_rows:138, _hub_rows:160, _stop_rows:181. HUB-scope verplicht eigen user.leverancier_id; begin/einddatum verplicht; datumverschil maximaal 31 dagen (inclusieve selectie kan dus 32 kalenderdatums bevatten). Default 100 / max 250 items; >2000 opgehaalde bronrijen geeft fout. De limietcontrole gebeurt na ophalen, niet als SQL-LIMIT. Filteren/pagineren daarna in geheugen.
Groepering (_hard_group_key:255, _linked_group_key:266):
pakbon:<leverancier_pakbon>:<artikel>:<kvd>
anders levering:<levering_id>:<artikel>:<kvd>
anders <bron>:<rij-id of hash>:<artikel>:<kvd>
Een leveringsreferentie wordt aan een pakbonketen gekoppeld als precies één packing-keten overeenkomt. Meer dan één kandidaat → ambiguous. Geen fallback op alleen partij/datum/aantal. chain_id is emballage_chain: + SHA1(groeperingssleutel), geen permanente database-ID.
_registered_quantity:503: null, ongeldig en 0 leveren undef; negatieve numerieke waarden worden wel geaccepteerd. _set_slot:356 telt dubbele slots niet op: zet ambiguous, bewaart bronregels en gebruikt geen ondubbelzinnige vergelijking voor die slot.
_finalize_chain:392 vergelijkt:
| Links | Rechts | Verschil indien beide aanwezig | |---|---|---| | supplier_delivered | hub_supplier_in | links − rechts | | hub_customer_out | logistics_customer_delivered | links − rechts | | logistics_customer_delivered | customer_delivered | links − rechts | | customer_returned | logistics_customer_picked | links − rechts | | logistics_customer_picked | hub_customer_in | links − rechts | | hub_supplier_out | supplier_return_received | links − rechts |
Ontbreken beide kanten, dan wordt het paar overgeslagen. Eén ontbreekt → missing. Gelijke waarden → aligned; ongelijk → difference. Ketenstatus prioriteit: ambiguous, daarna difference, daarna missing (ook als geen complete vergelijking), anders aligned. Een aligned keten bewijst dus niet dat alle zes schakels aanwezig zijn. Logistieke HUB-/leverancierstops zijn bronregels, geen vergelijkingsslots. Velden ontvangen/verstuurd worden gelezen maar niet in slots gebruikt.
_summary:451 telt ketens per control_status, geen emballageaantallen of geld. Detail geeft bronnen en vergelijkingen; de functie schrijft niets terug.
Gevraagde boekhoudkundige dimensies
| Dimensie | Aangetroffen in LMF | |---|---| | Beginstand | NOT FOUND; geen openingsboeking/selectie vóór periode | | Mutaties | wijzigbare bronhoeveelheden; niet iedere wijziging als nieuwe beweging | | Uitgifte/retour | afzonderlijke kolommen en perspectieven, zonder één universele tekenconventie | | Correcties | UPDATE/extra INSERT; geen afzonderlijke correctiereeks | | Eindstand | NOT FOUND als expliciete LMF-berekening | | Leverancier/HUB/klantlocatie/artikel/kvd | aanwezig in bronselecties en controleketens | | Vervoerder | actor→leverancier afgeleid voor stopbron; geen vervoerderssaldo | | Klantaccount | via locatie→klant; controle groepeert direct op locatie, niet klantaccount | | Waardehistorie | artikelprijs is actuele stamdata; geen prijs-snapshot in pakbonemballagerij |
Een eigen rekenregel voor begin-/eindstand toevoegen zou nieuwe businesslogica zijn en is daarom niet gedaan. Dezelfde fysieke beweging kan op drie plekken bevestigd zijn: die bronnen optellen zou dubbeltellen.
Aangrenzende systemen: wel gevonden, niet LMF
XLS::Logistiek::emballage_saldo (bron) leest andere tabellen emballage en emballage_lokatie, groepeert per locatie/code/heen_terug en berekent som(aantal waar heen_terug='h') minus som(aantal met andere richting). Geen datumfilter/openingsstand in deze functie. emballage_invoer schrijft dit oudere model. Geen call of synchronisatie vanuit LMF aangetroffen; dus niet presenteren als de saldo-implementatie van de React-app.
XLS::ShopAPP::Service::PackingSlips werkt dezelfde pakbonemballage bij (rond 533) en berekent op pakbonniveau SUM((geleverd-retour)*actuele prijs) (rond 682, 877). XLS::Administratie en leverancier-pakbonschermen doen soortgelijke writes/waardeberekeningen. Dit verklaart waarom LMF kolommen kan lezen die zijn eigen confirm-pad niet vult. Het bewijst geen gekoppeld, doorlopend partijen-grootboek.