controlecijfer achter de EAN code bij subset B: hoe te berekenen?

[Johan]

Ik maak een etiket (vanuit Bartender) om vervolgens te kopieren naar de etiketlayout, met een GS1 128 barcode. Het doel is, om het etiket op een zebra Printer af te gaan drukken, dus ZPL opmaak.
Daarbij komt de code
^BY2^BCN,96,N,N^FD>;>8010400867950719215131002108468>67
In beeld, dat is dus tag 1, 15 en 10. De inhoud van tag 10  is 84687
als ik dan in profit deze code kopieer, dan maak ik er
^BY2^BCN,96,N,N^FD>;>8010400867950719215%PO-THT9%10%et-charge%>67

Echter, die code >67 veranderd afhankelijk van de inhoud van de tags. Met andere woorden: Dat is een berekend veld. Hoe doe je dit in Profit?

Als ik nou subset C gebruik
^BY2^BCN,96,N,N^FD>:>8010400867950719215131002108468
Op deze manier (de “;” vervangen door “:”  ) dan wordt tag 10 afgekapt, de 7 van het chargenummer wordt niet meer meegenomen.

Kortom: Hoe zou ik het weergeven van het volledige chargenummer in de streepjescode voor elkaar kunnen krijgen bij Codeset B? Iemand hier ervaring mee?

 

[Wouter Rijnbende]

Als ik naar je voorbeeld kijk, kan ik me niet aan de indruk onttrekken dat je zélf een poging doet om middels meerdere layoutvariabelen zelf een correcte barcode samen te stellen die je ergens wilt afdrukken.

Dus, in een EAN-128 barcode kun je tags herkennen waaronder de EAN code van het produkt (01),  Chargenummer (10),  Inhoud (240/310x), THT (15).

Afhankelijk van het type barcode zal er een checksum bepaald moeten worden;
maar, daar ben je er nog niet mee, ook al is de code goed, moet e.e.a. ook nog van bepaalde interne codes worden voorzien om e.e.a. überhaupt te kunnen scannen.

Hoe dan ook, daar ga je zélf nooit uit komen door dit uit verschillende componenten op te bouwen.

Wij moeten hier een speciale layoutvariabele voor maken, die e.e.a. doet zoals jij dat nodig hebt.
Er zijn al diverse van dit soort layoutvariabelen, en mogelijk zit daar al degene tussen die jij nodig hebt.
De variabelen zijn er altijd per twee tegelijk: één voor de scanable barcode, en één voor de humanreadable barcode

Voor Zebra hebben we i.i.g. %AV-EAN128_01_10% versus %BO-EAN128_01_10%

Voor Morovia fonts (die je op normaal A4 papier kunt gebruiken in een HP compatible laserprinter) hebben we ook een aantal varianten.

Als jij ook de THT erin wilt hebben (15) zul je op zoek moeten naar een code waarbij 01, 10 en 15 in de omschrijving vermeld staan.
Is die er niet, dan zullen we deze voor je moeten maken (deze variabelen zijn wel wat complexer dan de normale, die aanpassing zal niet voor de gebruikelijke 0,5 uur uitkunnen; reken maar op 2 uur).

Nb: Merk overigens op dat opname van een code (15) nog tot praktische problemen kan leiden.
Normaal gesproken kun je nl. je etiketten al genereren en printen zodra je de Produktieorder hebt toegevoegd;
de THT datum wordt echter pas bepaald zodra je je goederen hebt opgeboekt ! en dus zou je je etiketten niet eerder kunnen printen dan op het moment dat je gaat afvullen ! (tsja... of je moet de THT printen op basis van de geplande gereedmelddatum, en er procedureel voor moeten zorgen dat je ook vooral niet eerder/later gaat produceren; maar dat is ook niet echt werkbaar lijkt me).

[Johan]

Ik zoek duidelijk 1, die achtereenvolgens tag 1, 15, 10 afdrukt.
tag 15, de tht, vul ik nu met %PO-THT9:6% en is,  zoals je onderstaand aangeeft duidelijk een heel lastige.

Kan de waarde die %PO-THT9:6% ophoest, ook keihard worden gebruikt als dé tht datum bij het opboeken? Dit ongeacht de datum waarop er (deels) wordt opgeboekt?

We werken namelijk met eindproducten die doorgaans een jaar tht hebben. Als ik een PO toevoeg met een geplande gereedmelddatum (en inherent daar aan een geplande tht), en dat wordt eens een dagje of wat mij betreft een week eerder of later... daar gaan we niet moeilijk over doen.
Het komt vast voor dat een po op 2 verschillende dagen wordt opgeboekt, maar het komt eigenlijk niet voor dat een dergelijke PO langer dan een week er over doet om alle onderdelen op te boeken.

vraagje 2: Die GS1 artikelcode (tag 1), waar leg je die eigenlijk formeel gezien vast? Als jullie namelijk een variabele moeten bouwen, dan moet je die informatie ook ergens vandaan halen. Het is niet "mijn" gs1 artikelcode die er op staat, maar de code die we op verzoek van een klant gebruiken. (Laco is nl. nog steeds niet aangesloten bij GS1)

[Wouter Rijnbende]

Kan de waarde die %PO-THT9:6% ophoest, ook keihard worden gebruikt als dé tht datum bij het opboeken?[/b] Dit ongeacht de datum waarop er (deels) wordt opgeboekt?

Natuurlijk kunnen we best iets verzinnen als "Bedrijfsparameter THT datum bepalen o.b.v. geplande Gereedmelddatum J/N" (4 uur), en alle P.O. opboekfunkties zodanig aanpassen dat deze instelling gerespekteerd wordt (3 uur), maar, m.i. gaat dat nog steeds niet opleveren wat je wilt. Immers, wat nu als je met de P.O. planning de order naar voren of naar achteren schuift ? Dan wijzigt ook de geplande gereedmelddatum.

Wat überhaupt te denken van Omvorm Opdrachten, waarbij je twee partijen met elkaar gaat mengen, en "output" als vanzelf de kleinste THT datum van alle ingestoken charges toegekend krijgt ? In zo'n geval wordt de THT datum niet eens gebaseerd op de geplande gereedmelddatum, maar is afhankelijk van de ingestoken batches, en daarmee per definitie pas achteraf bekend.

't Kan toch ook niet zo zijn dat we maar moeten gaan zeggen "als er al een keer een etiket gegenereerd is (waarop een THT datum is afgedrukt), dan moet je maar de THT datum hanteren die op dat etiket is afgedrukt"?

[Wouter Rijnbende]

Die GS1 artikelcode (tag 1), waar leg je die eigenlijk formeel gezien vast?

Via Raadplegen-/Toevoegen-/Wijzigen Kenmerkdomeinen; Hmenu-1-1-1-8-5-1.

Die kodes kunnen gegenereerd worden, maar, dan oplopend, en op basis van "jouw" gegevens.
Je kunt ze ook handmatig toevoegen, en dan mag je invullen wat je wilt.
Het is niet mogelijk om afhankelijk van je klant er een andere kode op te zetten.

Merk op dat er in theorie een extra niveau te bedenken valt, nl. dat de codes door jouw leverancier worden bepaald.
Als je naar 1-1-1-8-5-1 gaat, zie je ook dat er eerst om een Relatie wordt gevraagd;
het enige wat wij daar nu in ondersteunen is dat als je deze Relatie leeg laat, maar, in theorie zou je daar 'een leverancier' bij kunnen betrekken.
Als je die hoek in wilt, vereist dat wel maatwerk om dat helemaal consistent uit te werken.

Voor ogen ligt een situatie i.c.m. handelsartikelen; Jij koopt een produkt in bij jouw leverancier; hij zet er een barcode op, en jij wilt kunnen scannen op basis van de barcode die er al op staat. Maar ja... in theorie kan een Artikel meerdere Leveranciers hebben, en derhalve meerdere barcodes die tot hetzelfde produkt leiden. En, het feit dat 1 Leverancier zijn barcode erop zet, houdt nog niet in dat de andere leveranciers dat ook doen; hoe ga je die scannen?

Ook worden dezelfde EAN codes gebruikt om bestellingen (EDI) mee te verwerken; heb jij EAN codes afhankelijk van je leverancier, dan zou je bestelling ook impliceren dat ze geacht Leverancier moet zijn, en loop je in die hoek spaak. Je kunt wel zeggen "voor de order gebruik ik alleen de Artikel-/Vrs waar de code naar wijst", maar als het produkt door de andere Leverancier geleverd wordt, krijgt je klant een produkt gelabeld met een EAN code die niet overeenkomt met de code waaronder ze zelf bestelde.

Resumer: alles registereren we (vooralsnog) onder één code die je óf mag genereren op basis van je eigen aansluitnummer, of je mag zelf een waarde invullen.

[Johan]

Dat van die EAN artikelcode gaat wel werken, dat is geen probleem.

Dan moet ik nog even een excuus maken over de subsets.
Ik heb de code gegenereert door in Bartender een GS1 128 code te maken, met aldaar de instellingen op "codeset automatisch bepalen"
Ik heb de gegevens ingevoerd
GS1-artikelcode
tag 15 tht  131015
tag 10 charge 84510

daar maakt bartender dit van:

^BCN,50,Y,N^FD>;>8010400867905687415131015108451>60^FS
en dit lust de scanner van onze klant graag.
Als ik de ZPL programmering er op na lees, dan zou dit een Codesubset C, function 1 code moeten zijn, en niet subset B zoals eerder geschreven. Mijn excuses.

Het merkwaardige aan de door bartender gegenereerde code
^BCN,50,Y,N
en niet
^BCN,50,Y,N,N,N
Die overige parameters zullen wel default gevuld worden.

Rest dus even de vraag:
Kun je een variabele maken voor de zebraprinter, die tag 1, 15 en 10 bevat, die dus:
>;>8010400867905687415131015108451>60
dit soort resultaten op hoest.

even opdelen:
>;>8
01 0 4008679 05687 4  (tag 01 met GS1 bedrijf + artikelcode)
15 131015 (Tag 15 tht: Ik weet en begrijp naar aanleiding van eerdere tekst, dat dit niet zo hoort en formeel niet correct is, maar de waarde zoals PO-tht9 die geeft is wat mij betreft voor nu wel de meest praktische. formaat YYMMDD)

10 8451>60 tag 10 chargenummer. IN dit voorbeeld is het chargenummer 84510, en voor die laatste 0 wordt tot nu toe altijd  ">6" teken gezet. Ik begrijp die >6 nog even niet. Ik heb ook nog even niet getest wat er gaat gebeuren als je ipv 84510 (5 tekens) een 684510  (6 tekens) zou krijgen. Is iemand bekend wat die ">6" doet / hoe die bepaald wordt?

[Wouter Rijnbende]

Ik zal een code maken voor 01, 10 en 15.

Die >6 zit er mogelijk niet in, want ik heb geen idee wat je ermee bedoelt.

[Wouter Rijnbende]

>; aktiveert Subset C; dit deel zou je in theorie net zo goed in je layout zelf kunnen opnemen, daarmee is de inhoud van de variabeler ook bij B inzetbaar.

>8 is een code voor de start van een nieuwe Application Identifier; deze behoort dus én voor tag 01 én voor tag 10 én voor tag 15 te zitten.

>6 is een invocation code; schijnt iets terug te zetten naar subset B.

De Layoutvariabele is gemaakt, maar print nog niet precies wat ik wil.

Richard kijkt er even verder naar, want van de Zebra codes zelf heb ik weinig sjoegge.

[Wouter Rijnbende]

Ik zal je de details besparen, maar het heeft wat voeten in aarde gehad.

Layoutvariabele is erbij gemaakt conform jouw specifikaties. Zie Releasenote http://ha1.heartprofit.nl/profit/index.php?topic=24711.0

E.e.a. staat inmiddels op je systeem.

Let op: De >; moet je in je layoutregel opnemen, dus >;%AV-BRCSPC09Z%

[Johan]

^BY2^FO37,518^BCN,50,N,N^FD>;%AV-BRCSPC09Z%^FS
dit heb ik naar de printer toe gestuurd, voor een opdracht met een finishdatum van 17-10-2012, en charge 85021 (laco productiebestanden, etiketlayout 21392) artikel 25005 vrsvrm HE03 Tht 365 dagen, dagen tot signalering: 243

als ik de printfile af vang, dan komt dit in beeld
^BY2^FO37,518^BCN,50,N,N^FD>;>80104008679376378>815130420>8108502>61^FS
 
Die code ziet er volgens mij qua opbouw fantastisch uit. Ik moet 'm nog laten testen door mijn klant, echter die tht tag 15 is zo vreemd. Daar lijkt 20 april 2013 uit te komen, terwijl ik daar toch 131017 (17-oktober-2013)  verwachtte. de PO-tht9 variabele, geeft dat namelijk als resultaat.

[Wouter Rijnbende]

Schijnbaar kijkt hij niet naar de Houdbaarheid van de Verschijningsvorm, maar naar die van het Artikel.

Bij het Artikel heb je 185 dagen staan,
bij HE03 heb je 365 dagen staan.

Zal ik aanpassen.

[Wouter Rijnbende]

Aangepast, en staat op je systeem.

[Johan]

Dankjewel! Ziet er top uit, ik heb het voorbeeld nu onderweg naar de klant.

[Johan]

en ja: vanochtend ook groen licht van de klant. Bedankt!

[Wouter Rijnbende]

Yahoo