Barcode op basis van alleen Subchargenummer

[Wouter Rijnbende]

Barcode op basis van alleen SubchargenummerBinnen Profit hebben we talloze (Scan- en TouchScreen) schermen waarop we "iets" kunnen scannen. Een "Produktieorder", een "Lokatie", maar, we focussen ons nu puur en alleen op een "Voorraaditem".


Wat is een Barcode?
Een Barcode is op zich niet veel meer dan een stukje tekst, welke op een grafische manier in streepjes wordt weergegeven en welke zodoende door een scanner kan worden gelezen. Als een Gebruiker met zijn scanner een Barcode scant, zorgt dit scannen er feitelijk voor dat de data die in de Barcode staat ingetypt wordt alsof iemand dit met zijn toetsenbord had gedaan. Vandaar ook dat ónder een Barcode (ook wel streepjes code genoemd) veelal ook een data (meestal cijfer) reeks staat met de gegevens die inhoudelijk in de Barcode staan; mocht de Barcode niet gescand kunnen worden, dan kan de Gebruiker de gegevens ook handmatig intypen.


Wat moet er in een Barcode staan?
Voor het Scantrajekt in Profit hebben we gesteld dat het Chargenummer voldoende zou moeten zijn. Méér hoeft er in principe niet in de Barcode te staan. Hieruit volgt dat dit Chargenummer "uniek" moet zijn om zowel Artikelnummer én Verschijningsvorm én Kenmerkkombinaties én Chargenummer te kunnen identificeren. In de huidige versie is dat niet altijd het geval! Dit zal worden aangepast.


Subcharges per Palletnummer
De Scanterminalschermen zijn in eerste instantie ontwikkeld voor Goederen Ontvangst. Aldaar werden 20 pallets met ieder 40 dozen van 5 Kg paprika's ingekocht, waarbij we iedere pallet uniek wilde kunnen scannen. De Inkooporderregel werd versleuteld tot een Chargenummer van 9 posities, en voor iedere binnengeboekte pallet werd er een nieuw Subchargenummer (2 posities) gegenereerd. Op die manier konden we vooraf Etiketten printen met Barcodes erop, waarmee we én konden zien welke goederen we nog moesten ontvangen (immers daarvoor hadden we de etiketten al klaarliggen) én zodra de pallets geleverd werden, konden we een sticker op een pallet plakken, en daarna de pallet scannen en binnen boeken.

In het Magazijn treffen we fysiek 20 pallets aan met 20 Subchargenummers die alle 20 verwijzen naar de Inkooporderregel waarop het produkt is ingekocht. In Profit treffen we 20 Voorraaditems aan, die uniek worden gemaakt door hun Subchargenummer. Scannen we zo'n barcode, dan hebben we daarmee de hele pallet geïdentificeerd en kunnen we deze bijv. overboeken naar een andere Lokatie.

Binnen het ontwerp 'Subcharges per Palletnummer' kunnen we ook 10 van de 40 dozen 'Splitsen' naar een andere pallet. Dat levert dan een nieuw Subchargenummer op, immers, we kreëren een nieuwe pallet.

Het meerdere malen kunnen binnen boeken van voorraad van eenzelfde Subchargenummer is hier niet mogelijk!
Heel misschien werkt het gewoon als vanzelf toch... in ieder geval geldt dat alle klanten die wij kennen en scannen aan de Inkoopzijde, rubriek 'Subchargenummer per Pallet' aan hebben staan (desnoods door ons ingegeven als vereiste). Merk overigens op dat die methode ons ook gewoon toestaat om 20 pallets van 40 dozen a 5 Kg gewoon als één partij van 800 Verschijningen te kunnen ontvangen.


EAN 128 Code
Zoals gezegd wordt het Subchargenummer aan de Inkoopzijde samengesteld uit het Inkoopordernummer, de Inkooporderregel en een Subcharge-volgnummer. Nog vóórdat een partij wordt ontvangen wéten we dus al welk Chargenummer er op die pallet zal komen te staan, immers, ze wordt afgedwongen door de Inkooporderregel. Op ons etiket staat dat we op Inkooporder 20190906023 regel 16 20 pallets x 40 dozen x 5 Kg paprika's hebben ingekocht.

Op het etiket zullen we afdrukken:
- een Barcode die het Subchargenummer impliceert
- de Human Readable versie van dit Subchargenummer
- De Inkooporder en Inkooporderregel
- Dat het om Paprika's gaat, verpakt in een doos van 5 Kg
en wellicht nog wat meer gegevens...

Hierboven is ook uitgelegd dat we het etiket al op voorraad uitprinten, om direkt na goederen ontvangst op de pallets te kunnen plakken, en dat etiket te kunnen gebruiken om de voorraad mee binnen te scannen. Maar nu... nu verwijdert de inkoper de Inkooporderregel met paprika's, en voegt opnieuw een regel toe, eveneens regel 16, waarop nu komkommers worden ingekocht. Hij print netjes weer nieuwe stickers uit en deze gaan naar afdeling Goederen Ontvangst toe. Althans... dat is de bedoeling... maar... stel... de stickers komen niet uit de printer... iemand vergeet de oude stickers weg te gooien... whatever... Bij binnenkomst van de komkommers plakken we de oude sticker (waar nog paprika's op staan) op de pallet, en we kunnen de handel gewoon binnenboeken, immers, de Barcode waarmee we dat doen verwijst naar de Inkooporderregel en dat is nog steeds regel 16 op order 20190906023. Ondertussen hebben we op voorraad een pallet komkommers liggen, terwijl er een etiket 'paprika's' op ligt. Fout!

Natuurlijk kunnen we zeggen 'joh, iemand weet best wel het verschil tussen een paprika en een komkommer' en natuurlijk, dat weet iedereen. Maar... stel dat we het over tomaten hebben, dan heeft de betreffende klant wel meer dan 10 A4 tjes met verschillende soorten tomaten. Ingedeeld naar land van herkomst, klasse, maat en dan nog de verschillende soorten en kwaliteiten. De man die de goederen binnen boekt ziet zelf niet het verschil tussen een spaanse tomaat of een franse tomaat, toch moet dit juist geregistreerd worden.

Dit probleem is opgelost door ook de EAN-13 code van een Artikel-/Verschijning te betrekken in de Barcode op het etiket. De Barcode is een EAN-128 code geworden bestaande uit twee Identifiers:

(01) de EAN-13 code van de Artikel-/Verschijning
(10) het Chargenummer

Door ook de EAN-13 code te verwerken in de Barcode was een double-check mogelijk op basis waarvan Profit zegt 'joh, jouw EAN-13 code impliceert paprika's, maar jouw Chargenummer impliceert een Inkooporderregel waar komkommers op staat, dat klopt niet!'. Feitelijk vertelde Profit de Gebruiker op deze manier dat hij een verkeerd Etiket aan het plakken was.

Naast een Layoutvariable die het Chargenummer als Barcode afdrukte kwam er nog een tweede Layoutvariabele bij, nl. een die zowel EAN-13 alsmede het Chargenummer bevatte.


Subcharges in Produktieorders
De Subcharges aan de Inkoopzijde zijn weer de basis geweest voor de Subcharges per Pallet aan de Produktiezijde. Tot dáár klanten waren die hun voorraad liever bleven opboeken met het bestaande Chargenummer in plaats van dit met een Subchargenummer te gaan doen. Er is een tweede parameter geïntroduceerd waarmee we voor het scannen in Produktie separaat konden aangeven of dit 'Per Palletnummer' moest gebeuren of niet. I.g.v. "Nee" werd de Output v/d Produktieorder gewoon opgeboekt op basis van het oude Chargenummer van de Produktieorder, zonder hierbij gebruik te maken van Subcharges.

Zo gold dat als we 4500 L op een Produktieorder produceerden, en dit afvulden als 200 blikken van 20 Liter en 100 blikken van 5 liter, beide items op voorraad kwamen te liggen met hetzelfde Chargenummer. Doordat de Barcode ook de EAN-13 code van de Artikel-/Verschijning bevatte, kon op basis van deze EAN-13 code worden bepaald of we het 5- danwel het 20- liter blik scanden, en leidde de kombinatie van Artikel + Verschijning + Charge tot het Voorraaditem.


Alléén voor communicatie naar de klant
Op deze manier is er langzaam maar zeker in gesloopt dat de Barcode zowel de (01) Identifier (EAN-13 code) alsmede de (10) Identifier (Chargenummer) moest bevatten, en dát was nou nèt niet de bedoeling. Voor Profit zelf zou moeten gelden dat het Chargenummer altijd uniek is. De EAN-13 code dient alleen te worden gebruikt in communicatie naar een klant toe, maar mag door Profit zélf niet worden gebruikt om een Voorraaditem te lokaliseren. Dus ja, als uw klant iets wil kunnen scannen op basis van uw EAN-13 code, dan mag uw Barcode deze waarde best bevatten, maar, het moét voor uw klant nodig zijn. Als het voor Profit nodig is, doen we het verkeerd...

Wat maakt het uit?
Een EAN-13 code (ook wel GTIN-13 genoemd) wordt samengesteld uit een Landkode (2 posities), een Aansluitnummer (5 posities) een Volgnummer (5 posities) en een Kontrolecijfer (1 positie). Feitelijk hebben we binnen één Aansluitnummer dus de mogelijkheid om 99.999 codes te bedenken. En ach, binnen Profit bestaat er een tool waarmee we die nummers zelf kunnen genereren voor alle kombinaties van Artikel-/Verschijningen die we hebben, m.a.w., die run genereert in notime 30.000 unieke codes voor onze Artikel-/Verschijningen, we toevoegen een Produktieorder toe, genereren Etiketten, daar komen vanzelf die EAN-128 codes op met de EAN-13 code én het Chargenummer, en we kunnen doen wat we willen... Wat is het probleem?

Het probleem is dat we op dit moment de EAN/GTIN code wél nodig hebben om een Voorraaditem te kunnen vinden. En met dat dat zo is, zullen we er dus ook altijd voor moeten zorgen dat die code er is! Een Artikel-/Verschijningsvorm kan op zich weer verder uniek worden gemaakt met 3 Kenmerken. Kenmerken, die ieder weer talloze kombinaties kunnen bevatten, en waaruit het totaal aantal kombinaties feitelijk ongelimiteerd wordt. Zo kan een bepaalde klant afdwingen dat hij een afwijkende Emballageset wil hebben. In Profit zullen we (dus) moeten weten dat als dié klant een 20 liter blik besteld, er andere Emballage aan de orde is. Logistiek realiseren we dit door hiervoor een Kenmerk in te zetten. Als we 5000 klanten hebben, kunnen we zo al onze produkten wel uniek gaan maken naar de specifieke wensen van onze klant. Voor een ieder van die klanten geldt 'we willen alleen een ander deksel op het blik'. Bedenk dat we nog een tweede kenmerk kunnen opnemen waarmee we Etiketten/Labels gaan verwerken, immers, leveren we het blik aan Amerika, dan moeten er andere Etiketten op het blik als wanneer het blik aan China wordt geleverd. Het aantal kombinaties wordt op zo'n manier al snel ongelimiteerd... En... voor iedere kombinatie moéten we nu een EAN-13 code opnemen, anders kunnen we het blik niet meer scannen... Binnen de korste keren raken we door de 99.999 volgnummers van ons Aansluitnummer heen, en zullen we een nieuwe moeten aanvragen. En waarom? Zolang de klant niets met onze EAN code doet, moet het niet nodig zijn... mits het Chargenummer maar uniek is, zoals oorspronkelijk bedoeld.


Dus? Vanaf heden kijkt Profit niet meer naar de EAN-13 code in de Barcode?
Eigenlijk zou het wel zo moeten zijn, maar... wij realiseren ons dat dát niet mogelijk is. Bedenk immers maar dat veel klanten de output van hun Produktieorders niet "per Palletnummer" opboeken, maar gewoon als volgt:

Scannen doen deze klanten ook... maar als wij niet meer naar de EAN-13 code zouden kijken, is een 5 liter blik nooit van een 20 liter blik te onderscheiden, immers, in het verleden zijn hier geen Subchargenummers aan toegekend. Zou Profit niet meer kijken naar de EAN-13 code, dan zou bij zo'n klant de bestaande voorraad niet meer kunnen worden gescand; dat mag natuurlijk niet.


Hoe werkt het dan wel?
Bij Touchscreen-/Scanterminal Parameters zetten we de parameter "P.O. behandeling per Palletnummer J/N" op "Ja".

Als deze parameter aan staat, zal het Chargenummer welke normaal gesproken aan een Produktieorder wordt toegekend veranderen in een zgn. Hoofdcharge, en zal iedere opboeking op die Produktieorder resulteren in een Subchargenummer. Een Subchargenummer wordt opgebouwd uit de Hoofdcharge aangevuld met 2 posities voor een volgnummer, beginnend bij '01'. Het doel van 'opboeken per pallet' is dat we iedere Pallet met nieuw Subchargenummer gaan opboeken, en daarmee krijgt iedere Pallet een ander Subchargenummer. Ieder Subchargenummer dient uniek te zijn v.w.b. de volgende gegevens:
* Artikelnummer
* Verschijningsvorm
* Kenmerken
* Debiteur
* Verkooporder-/regel

Hieruit volgt dat het niet is toegestaan om appels en peren of om blikken van 5- en blikken van 20 liter op dezelfde pallet te leggen.

Alle Voorraaditems van hetzelfde Subchargenummer zijn dus v.w.b. bovenstaande gegevens altijd uniek. Technisch gezien kunnen we dit formeel kombineren met 'Splitsen', waarmee we in staat zijn om van een pallet met 22 blikken van 20 liter er 10 af te splitsen naar een nieuw Subchargenummer. Voor deze 10 blikken zouden we dan weer een nieuwe Subcharge krijgen, die voor de pallet met 10 blikken wederom uniek is. Het Subchargenummer identificeert dan altijd maar één Voorraaditem. Maar... let op: in ons voorbeeld mogen we geen gebruik maken van dit splitsen! Dit, omdat het niet enkel meer om een pallet etiket gaat met een Barcode erop, maar ook de blikken op die pallet krijgen (via een extern etiketteringsprogramma) deze Chargenummers op het blik geprint. Als we een pallet dus formeel zouden splitsen naar een ander Subchargenummer, dan genereert Profit weliswaar een nieuw Subchargenummer, maar de blikken op de pallet bevatten nog steeds het oude Subchargenummer welke tijdens produktie is toegekend. Middels een parameter "Overrulen aantal Verschijningen bij Scanterminal Verplaatsen J/N" hebben we het (voor klanten die niet met Subcharges werken) mogelijk gemaakt om bij het Scanterminal Verplaatsen Voorraaditem het aantal Verschijningen te kunnen overrulen.

Hiermee zijn we in staat om 10 blikken van een pallet met 22 blikken te verplaatsen naar een andere Lokatie, zonder dat we daarbij het (Sub-)Chargenummer veranderen. Deze parameter zal nu ook worden gebruikt om de 'Splits' Scanterminalschermen te blokkeren, immers, we werken òf met volledig unieke Palletnummers (in welk geval we zullen moeten splitsen) òf we kennen hooguit een Subchargenummer toe tijdens het produceren maar geldt dat na het produceren deze Subcharges niet meer zullen wijzigen (immers, ze staan op het blik zelf geprint).
Edit: Bovenstaande parameter is in oktober 2019 komen te vervallen. Of we een aantal Verschijningen mogen opgeven wordt nu bepaald op basis van of er al dan niet een Subcharge werd gescand (scannen we een partij die niet met Subcharges werkt, dan mogen we het aantal altijd overrulen) en daarnaast o.b.v. een nieuwe setting op Artikelniveau waarmee kan worden aangegeven of er i.g.v. Subcharges gesplist MOET worden, danwel Splitsen NIET is toegestaan. Zie ook topic http://ha1.heartprofit.nl/profit/index.php?topic=29555.0

Door deze methode is het Chargenummer (feitelijk het Subchargenummer) uniek geworden voor gegevens die anders in de EAN-13 code zaten. Omdat die gegevens nu m.b.v. het Chargenummer kunnen worden bepaald, kan de Barcode die Profit nodig heeft om een Voorraaditem te scannen zich beperken tot puur en alleen dit Chargenummer. Merk echter op dat deze Subchargenummers pas zullen gaan ontstaan vanaf het moment dat Produktieorder op de nieuwe manier worden opgeboekt. Op voorraad staan nog tal van blikken waarvan de Barcode een EAN-128 Barcode betreft mét (01) Identifier (de EAN-13 code) en met (10) Identifier (het Chargenummer). Die oude voorraad kan niet worden gescand op basis van het Chargenummer alleen, immers, daarin zit nog geen uniek Subchargenummer verwerkt. Feitelijk ontstaat dan de volgende situatie: als de Barcode géén EAN-13 code bevat maar enkel een "uniek" Chargenummer, dan zal Profit het Voorraaditem kunnen lokaliseren. Als de Barcode wél een EAN-13 code bevat, dan mág Profit deze gebruiken om het Voorraaditem te kunnen lokaliseren (immers, anders zouden we onze oude voorraad niet meer kunnen scannen). Vanzelfsprekend kunnen wij niet tegenhouden dat u in de Variabele Layout waarmee u uw etiketten afdrukt, gewoon een EAN128 code blijft opnemen mét daarin de EAN-13 code van de kombinatie Artikel-/Verschijningsvorm-/Kenmerk. Het is echter slimmer om over te stappen naar de methode waarbij de Barcode alleen een Chargenummer bevat, immers, een EAN-13 code opnemen op het etiket impliceert juist dat u voor alle mogelijke kombinaties een nieuwe EAN code opneemt, en dat worden er (onnodig) veel.  "Informatief" mogen we voor onze klant nog best een EAN-13 code opnemen, maar voor Profit is dat nu niet meer nodig; Profit heeft aan het Chargenummer voldoende.


Hoe komen we aan ons Etiket met de Barcode erop?
Hoewel "Inkoop" natuurlijk niets met "Produktie" te maken heeft, kijken we toch eerst even hoe "Etiketten" aan de Inkoopzijde werken. Aldaar hebben we momenteel twee manieren op voorraad van Barcodes te voorzien:

a. we genereren (en printen) vooraf de Etiketten met een scanbare Barcode. Deze stapel Etiketten komen op de 'Goederen Ontvangst' lokatie in een bak te liggen. Zodra de betreffende Leverancier zijn spullen komt leveren, pakken bij het juiste pallet-etiket, plakken deze op de pallet, en daarna kunnen met een scanner de Barcode scannen en zodoende de produkten in Profit administratief op voorraad leggen.

b. een Touchscreenscherm toont ons welke Leveranciers welke produkten (wanneer) moeten leveren. Met dit soort selekties navigeren we naar de Inkooporderregel die we willen binnenboeken. We boeken nu de Inkooporderregel binnen en vanuit het TouchScreen worden er direkt pallet-etiketten geprint die we op onze pallets kunnen plakken.

Aan de Produktiezijde beschikken we niet over een soortgelijk TouchScreenscherm, dus, methode b. valt daar al af. Overigens hebben we daar alleen zo'n scherm niet, omdat we deze nog voor niemand hebben hoeven (mogen) maken. Zouden we wel zo'n scherm ontwikkelen, dan kunnen we daar vanzelfsprekend ook de output mee opboeken en dat scherm Etiketten laten printen. Voor nu zijn richten we ons dus even op het opboeken m.b.v. een scanner...

Met als uitgangspunt dat we "per pallet" gaan opboeken, is het om te beginnen handig dat we er voor zorgen dat Profit weet hoeveel Verschijningsvormen er op een pallet staan. Dit kunnen we bij de Artikel-/Verschijningsvorm aangeven op het 2e Tabblad m.b.v. de rubrieken 'Aantal Verschijningsvormen per Palletlaag' en 'Aantal Palletlagen per Pallet'. Zo is onderstaand aangegeven dat we v.w.b. ons produkt, in de Verschijningsvorm "20.0LMR" (20 liter blik) 2 palletlagen hebben van ieder 11 blikken, ofwel 22 blikken van 20 liter per pallet. Dit betreft overigens iets wat 1 keer moet zijn ingericht.

Vanuit Raadplegen Output Produktieorder (5-2-1-1-Shift+F5) kunnen we met toetskombinatie Shift+F4 'Etiketten Genereren', die we daarna kunnen printen. Het genereren van deze Etiketten zullen we zo lang mogelijk uitstellen tot het moment dat we zeker zijn dat de Output van de Produktieorder niet meer wijzigt, immers, als we een P.O. 3 maanden van te voren toevoegen en dán al Etiketten genereren, terwijl het Afvuladvies van die Produktieorder nog gaat wijzigen, dan hebben we die etiketten voor niets geprint.
Als voorbeeld nemen we onderstaande Produktieorder:

Als we middels Shift+F4 Etiketten gaan genereren, dan zal Profit per Outputitem van de Produktieorder, per Pallet een Subchargenummer genereren. Profit weet in dit voorbeeld dat we van de 1e regel 44 blikken nodig hebben, dat er 22 blikken op 1 pallet passen, en dus zullen we 2 pallets nodig hebben = twee Subcharges. Deze Subcharges kunnen 'onder water' worden gegenereerd, maar het is ook mogelijk om via een parameter in te stellen dat hier tijdens het genereren van de etiketten om moet worden gevraagd. In dat geval verschijnt onderstaand scherm waarmee de door Profit berekende gegevens kunnen worden overschreven; dit kan handig zijn 'ter kontrole' maar is bijvoorbeeld ook goed bruikbaar indien op Artikel-/Verschijningsvormniveau nog niet overal is aangegeven hoe een pallet gestapeld moet worden, immers, dan biedt dit scherm alsnog de mogelijkheid om zelf te bepalen hoeveel Subcharges u wilt hebben (lees: hoeveel pallets er opgeboekt moeten worden).

Na het genereren van de Etiketten komen we in 'Raadplegen Etiketten' terecht van waaruit we de Etiketten kunnen printen. Dat dit via een Raadpleegfunktie verloopt heeft overigens te maken met het feit dat ook hier weer een hele subadministratie achter zit waarbij we 'Opdrachten tot printen van Etiketten' kunnen opsparen, om ze vervolgens 'getagd' kunnen printen, of zélfs 'getagd en gesorteerd op sorteerkode'. Denk hierbij aan het feit dat we grote-, middelgrote- en kleine etiketten hebben, en dat we gele-, groene-, rode- en blauwe etiketten kunnen hebben, en ieder produkt om zijn eigen formaat en kleur vraagt. 'Getagd en gesorteerd' helpt nu om alle 'nog te printen etiketten' te printen per formaat en kleur opdat u zo min mogelijk een andere rol (blanco) etiketten hoeft te verwisselen. Maar, dat is weer een heel ander hoofdstuk...

Als we weer terugkomen in Raadplegen Produktieorder-output, dan zien we nu dat de laatste kolom (ES  = Eerste Subchargenummer) gevuld is, en ons per Outputitem het 1e Subchargenummer toont welke is toegekend aan deze Outputregel. In de 3e kolom zien we 'het Chargenummer' welke is toegekend aan deze Produktieorder. Dit nummer, aangevuld met het Subchargenummer, leidt vervolgens tot een unieke kombinatie die zowel Artikel, alsmede Verschijningsvorm én Kenmerken (en zelfs Debiteur en eventueel Verkooporderregel) impliceert.

Via een Variabel Layout mechanisme kunnen we zelf bepalen welke informatie we allemaal op ons Etiket willen krijgen. Zo'n etiket dient minimaal een Barcode te bevatten met daarop het (unieke) Subcharge (= Pallet) nummer. Onderstaand een voorbeeld van zo'n etiket:

Als we nog even een stukje terugscrollen, dan zien we dat we bij het Genereren van de Subcharges niet alleen konden aangeven hoeveel Subcharges we willen hebben, maar óók hoeveel etiketten we per Subcharge willen hebben:

Dit aantal etiketten kunnen we beïnvloeden met settings die we bij een Verschijningsvorm kunnen opgeven:

Op die manier kunnen we er voor zorgen dat we bijv. voor ieder blik op de pallet een Etiket wensen te hebben, plus dan nog 1 extra om op de pallet te plakken. Misschien willen we wel 4 extra etiketten hebben, dan kunnen we aan iedere zijde van de pallet een etiket plakken. En misschien willen we altijd wel één extra Etiket hebben omdat we er nog wel eens een verprutsen tijdens het op de pallet plakken.

In de situatie van deze specifieke implementatie geldt dat externe labelsoftware de Subcharges uit Profit leest, en ieder blik voorziet van een Barcode met daarop het door Profit toegekende Subchargenummer. Gaan we over op een tweede pallet, dan weet het externe systeem dat er op de eerst volgende 22 blikken een andere Subcharge moet worden geprint. Aangezien het beprinten van de blikken buiten Profit om wordt gerealiseerd, hoeft Profit geen etiketten voor de blikken te printen. Bij de Verschijningsvorm laten we het aantal etiketten dus gewoon op 0 staan. We krijgen dan alsnog tóch altijd een Etiket, en die kunnen we uitprinten om vervolgens op de Pallet zelf te plakken! Dat deel werkt daarmee precies hetzelfde als aan de Inkoopzijde, alwaar we ook vooraf per Pallet een Etiket printen die we t.t.v. Goederen Ontvangst op de Pallet plakken.

Vanzelfsprekend zijn er ook nog andere mogelijkheden om ergens een Barcode op af te drukken die we kunnen gebruiken om te scannen. Zo is iedere Produktieorderlayout maatwerk, en zou u er voor kunnen kiezen om tijdens het Printen van de Produktieorder per Pallet een extra blad af te drukken met informatie omtrent die pallet. Onderstaand ziet u een voorbeeld van een Produktieorder waarop 11 blokken worden afgedrukt met ieder een eigen Subchargenummer (= Palletnummer) en een Barcode die representatief is voor dat Subchargenummer. Pallets met gelijke gegevens (Artikel-/Verschijning-/Kenmerken) scheiden de overige pallets middels een dikkere streep, op die manier zien we welke pallets 'bij elkaar horen'. Ook zijn de pallets met gelijke gegevens genummerd in de vorm van '1 van 3', '2 van 3' en '3 van 3'. Subcharge 390900202 is de 2e pallet van in totaal 3 pallets van Verschijningsvorm "20.0LMR" en Kenmerk "(E)B12345".
Ieder blok toont ook hoeveel Artikel-/Verschijningen er op die pallet moeten komen te liggen, opgebouwd uit bijv. 2 Palletlagen van ieder 11 Verschijningen.
Tevens worden de Emballageset-onderdelen vermeld, opdat we kunnen zien dat het ene blik een standaard deksel behoeft, terwijl de ander een rood of een geel deksel nodig heeft.

Nb: In de specifieke situatie bij deze klant print Profit geen Etiketten voor de blikken, dat gebeurt m.b.v. een extern pakket (Nicelabel). Door een van de Barcodes van deze Produktieorder te scannen weet het externe pakket met welke pallet we bezig zijn, en kan zij de etiketten printen die op de blikken terecht moeten komen.


Opboeken P.O. Output via de scanner
Vanuit Scanterminalmenu, Produktie kunnen we nu in het scherm 'Opboeken Output' een pallet opboeken door de Barcode te scannen van de betreffende pallet. Deze Barcode bevat niets meer dan het Subchargenummer die aan de betreffende pallet is toegekend. Ze hoeft géén EAN-13 code meer te bevatten (en dus hoeven we er ook niet voor te zorgen dat die er is). Profit wéét dat er 2 lagen van 11 blikken = 22 blikken op één pallet liggen en stelt derhalve default voor dat er 22 blikken worden opgeboekt met dit Subchargenummer. Ook zien we dat de waarde van het Kenmerk 'Emballageset-Id' wordt getoond:

Op eenzelfde manier boeken we ook de andere 10 pallets op, door de Barcode van de pallet te scannen, en aan te geven hoeveel Artikel-/Verschijningen er op die pallet liggen. Als we dat gedaan hebben. liggen er 11 pallets op voorraad, ieder met hun eigen (unieke) Subchargenummer. Iedere pallet is uniek voor zijn kombinatie Artikel-/Verschijningsvorm-/Kenmerken.

Nógmaals opboeken
In een vorige versie van 'Opboeken Output' via de scanner, was het i.g.v. 'per pallet' opboeken niet mogelijk om nógmaals Output op te boeken van een Subchargenummer waarop al iets wás opgeboekt. In de nieuwe versie is dat wél mogelijk, doch na éérst er voor te zijn gewaarschuwd dát er al output is opgeboekt. Deze methode staat ons toe om bijv. eerst 10 blikken, en daarna 12 blikken op onze pallet op te boeken, of desnoods 'blik voor blik'.

 
Layoutvariabelen
Last but not least... Als we willen gaan scannen op basis van enkel het Chargenummer, dan zullen we in de Variabele Layout waarmee we ons etiket maken, een Layoutvariabele moeten opnemen die enkel dit Chargenummer bevat. Hieronder ziet u welke Layoutvariabele hiervoor gebruikt kan worden:

Human Readable	: %BO-EAN128SPC03%
Morovia Barcode	: %AV-EAN128SPC03% (in een van de %PQT% Morovia Lettertypen)
Zebra Barcode	: %AV-EAN128CH%

Nb: Hoewel de Barcode met enkel het Chargenummer niets te maken heeft met EAN128, heten de Layoutvariabelen wel zo; zo'n staan alle Barcode variabelen toch enigzins bij elkaar als we Layoutvariabelen gaan Raadplegen.