GS1 Belgilux

Nadat we in het vorige nummer van dit Bulletin enkele succesvolle implementaties van ‘3-way match' hebben voorgesteld, kunnen we ditmaal moeilijk anders dan ons te verdiepen in het recept. Wat is die sleutel tot succes? Vooral het streven naar eenvoud en goede afspraken, ook intern, zo blijkt.

‘3-way match'

‘3-way match' is een modieuze, relatief nieuwe term waarmee wordt aangegeven dat een bedrijf de drie belangrijkste eCom-berichten gebruikt en ze op elkaar afstemt, zodat die ‘centrale berichtenflow' wordt geoptimaliseerd. Gewoonlijk gaat het over de bestelbon, de verzendnota en de factuur, in klassieke EDI-termen de ORDERS-, DESADV- en INVOIC-berichten. Om die perfect op elkaar af te stemmen, volstaat het een beperkt aantal parameters van bericht tot bericht door te geven. Dat is op zich niet zo moeilijk, maar het veronderstelt toch een minimale vertrouwdheid met de GS1 Identificatiestandaarden. Het is immers niet mogelijk om zonder voorafgaandelijke datasynchronisatie de commerciële en de logistieke processen te koppelen --- en dáár zit precies de kneep. Een eenvoudig voorbeeld maakt dit meteen duidelijk.

Eenvoudig voorbeeld

Klant K bestelt bij Fabrikant F een MacGuffin (MG).

Er zijn MGs voorradig, en dus levert F een MG aan K, op de gewenste plek en het gevraagde tijdstip. Vervolgens bezorgt F aan K de factuur voor de geleverde MG.

Iedereen tevreden, en dus einde verhaal.

Toch is dit voorbeeld ten dele fictief, want in de praktijk is níét iedereen tevreden. Hoe komt dat? Waarom functioneert dit schema op papier, maar niet altijd in de praktijk? Het antwoord is verrassend eenvoudig: omdat in het voorbeeld K's besteleenheid --- niet te verwarren met de bestelde hoeveelheid (die een veelvoud is van de besteleenheid) --- gelijk is aan F's levereenheid (of verzendeenheid), en nadien blijkt die besteleenheid ook nog gelijk te zijn aan F's facturatie-eenheid. Dat betekent dat het mogelijk is dezelfde entiteit doorheen deze drie berichten te volgen. Doordat beide partners er op voorhand voor hebben gezorgd dat dat het geval is, maken zij het zichzelf nadien gemakkelijk.

Laat ons dit eenvoudige basisprincipe illustreren met een concreet voorbeeld.

Stel, klant K bestelt 1800 flessen XYZ (met als identificatienummer <GTIN-1>) bij fabrikant F. Dat zou er, vereenvoudigd voorgesteld, als volgt kunnen uitzien in een bestelling (EANCOM® ORDERS-bericht):

In de hoofding wordt het bericht geïdentificeerd (samen met nog enkele andere elementen die hier van minder belang zijn); in de detailsectie wordt onder meer aangegeven wat men bestelt (LIN-segment) en in welke hoeveelheid (QTY-segment).

Fabrikant F maakt de bestelling vervolgens klaar voor verzending. Zodra de truck het magazijn heeft verlaten, kan dit worden meegedeeld aan klant K in een verzendbericht (EANCOM® DESADV-bericht):

In de hoofding wordt het bericht geïdentificeerd en wordt verwezen naar de corresponderende bestelling; in de detailsectie wordt onder meer aangegeven wat er is verzonden.

Tenslotte zal fabrikant F een factuurbericht zenden naar klant K (EANCOM® INVOIC-bericht):

In die factuur wordt opnieuw verwezen naar het corresponderende order, en er wordt gedetailleerd wat er precies is verkocht.

Het geheim

Waarom gaat dit blijkbaar zo vlot? Omdat zowel bij fabrikant F als bij klant K de interne systemen elkaar ‘kennen'. Nadat de bestelbon (het ORDERS-bericht) is ontvangen, weet de afdeling logistiek van fabrikant F wat er onder <GTIN-1> moet worden begrepen, en hetzelfde geldt nadien voor de boekhoudafdeling. Bij fabrikant F geldt immers:

besteleenheid = verzendeenheid = facturatie-eenheid

In dit theoretische voorbeeld lijkt de fabrikant alle macht te hebben, in die zin dat hij zelf vastlegt welke zijn bestel-, verzend- en facturatie-eenheid is voor een artikel. In de praktijk zal het bepalen van die drie grootheden echter het resultaat zijn van een complex samenspel van factoren. Niet enkel intern is het soms moeilijk om een uniforme visie te verkrijgen, maar ook met de partner (klant) moeten afspraken worden gemaakt. Want ook de klant zal hoogstwaarschijnlijk een voorkeur hebben voor één welbepaalde verschijningsvorm waarin de goederen bij hem worden geleverd, en misschien is dit niet degene die de fabrikant standaard hanteert.

Eenvoudig voorbeeld revisited

Een nadere blik op het voorbeeld van hierboven zal dat verduidelijken.

In dat voorbeeld had klant K 1800 flessen XYZ besteld. Maar, zoals de bestelling er nu uitziet, zal hij 1800 losse flessen ontvangen. Hij heeft immers 1800 stuks -- eenheden dus -- van <GTIN-1> besteld, en bovendien geen biezondere verpakkingsinstructies gegeven. Hij moet dus niet verbaasd zijn als de fabrikant hem daadwerkelijk 1800 losse flessen levert!

Zo ver zal het in de praktijk natuurlijk nooit komen. Maar het helpt wél als de klant alle mogelijke ambiguïteit op voorhand wegneemt door heel precies te bestellen wat hij wenst te ontvangen, en niet iets dat erop lijkt, of dat de fabrikant misschien wel zal kunnen interpreteren aan de hand van bestellingen van vroeger.

Logistiek

Anderzijds zal de fabrikant sowieso geen losse flessen (<GTIN-1>) als besteleenheid aanbieden. Die flessen verpakt hij bijvoorbeeld in kratten van 10 (<GTIN-2>) en van 20 flessen (<GTIN-3>), en misschien biedt hij zelfs standaard pallets aan met 20 kratten van 20 flessen (<GTIN-4>). In dat geval zijn zowel <GTIN-2>, <GTIN-3> als <GTIN-4> mogelijke bestelhoeveelheden. De moeilijkheid is de verschillende accenten met elkaar te verzoenen. De logistiekers van de fabrikant zijn nl. niet geïnteresseerd in losse flessen of zelfs in kratten, maar uitsluitend in logistieke eenheden, d.w.z. de eenheden die in het magazijn worden gehanteerd. De vraag is dus of de fabrikant zijn klant de mogelijkheid zal bieden, c.q. hem stimuleren, om pallets te bestellen, dan wel of de commerciële dienst van de fabrikant de klant integendeel zo weinig mogelijk wil vervelen met dit soort akkefietjes en hem zo veel mogelijk de vrijheid wil laten. Gewoonweg omdat men ervan uitgaat dat de logistieke dienst de bestelling van de klant wel zal kunnen interpreteren en verwerken tot wat hij nodig heeft.

Mutatis mutandis geldt eenzelfde redenering uiteraard evenzeer voor de boekhouding van de fabrikant.

De slotsom van deze discussies zal zijn dat de fabrikant zijn klant verschillende verschijningsvormen van XYZ aanbiedt. Bv. niet enkel het standaard pallet, maar ook de kratten van 10. Die ‘aanbieding' wordt geëxpliciteerd bij de datasynchronisatie, dus nog vóór er effectief EDI-uitwisselingen gebeuren (ofwel bij een latere update van de informatie over product XYZ). In het IMD-segment dat bij elke GTIN hoort, zal de fabri-kant deze ‘eigenschap' van het artikel aangeven: is het een besteleenheid, verzendeenheid, facturatie-eenheid, ja zelfs ‘géén besteleenheid' (ingeval de fabrikant daarover niet de minste twijfel wil laten bestaan). Aldus weet de klant welke verschijningsvormen hij kan bestellen, welke hij in zijn magazijn kan verwachten, en welke er gefactureerd zullen worden.

Als het handige regeltje van hierboven niet van toepassing is, zullen er conversies moeten gebeuren zodat het wél bruikbaar is.

Herwerkt voorbeeld

Hernemen we het eerdere voorbeeld, waarbij klant K zijn 1800 flessen XYZ ditmaal bestelt als 90 kratten van 20 flessen elk.

De corresponderende bestelling zou er, vereenvoudigd voorgesteld, als volgt kunnen uitzien (we beperken ons tot de detail section):

Merk op dat de klant rechtstreeks 90 kratten van 20 bestelt, maar het zou ook kunnen dat het interne bestelsysteem toestaat dat hij 1800 flessen XYZ (<GTIN-1>) ingeeft, waarna het, rekening houdend met de besteleenheden, voorstellen doet, bv. 90 kratten van 20 (= <GTIN-3>), of 180 kratten van 10 (= <GTIN-2>), of een combina-tie van kratten en standaard pallets (= <GTIN-4>). Dit alles afhankelijk van de vroeger met de klant gemaakte afspraken.

Dat levert in het verzendbericht gelijkaardig:

Dit is mogelijk op voorwaarde dat het magazijn kratten van 20 kan aanleveren (ongeacht de verdere conditionering, in dit geval bv. tot 3 niet-gestandaardiseerde pallets met de maximaal toegestane hoeveelheid van 30 kratten, die de producent echter niet als standaard aanbiedt in zijn assortiment en die dus geen GTIN hebben).

En tenslotte gelijkaardig in de factuur:

Merken we tenslotte nog op dat dit voorbeeld is uitgewerkt vanuit het oogpunt van de fabrikant, maar het spreekt voor zich dat het net zo goed vanuit het perspectief van de klant kan worden bekeken.