Import von EAN über die Ameise

[deepblue]

Hallo,

habe ein kleines Problem beim Import von EAN über die Ameise. Verwende die aktuelle Version von JTL-Wawi.
Sobald ich die EAN-Nummern importiere werden vorne die zwei Nullen weggelassen. Somit ist meine 13-Stellige EAN nur 11-stellig! =(

Habe jetzt auch schon probiert die EAN in das Feld EAN einzugeben. Das funktioniert auch.
Aber leider schwächelt die Ameise bei meiner Import Datei.

Wenn ich mir mit Notepad++ die CSV-Datei anschaue sind die 00 vor der EAN richtig.

 

[KathiLe]

AW: Import von EAN über die Ameise

Setze die zwei Nullen als Prefix beim Import. Das ist die einfachste Lösung. Ggfs. musst du halt zwei Importe machen (einmmal für die Nuller und dann für die anderen EAN)

 

[Thomas_S]

AW: Import von EAN über die Ameise

Kann ich nicht nachvollziehen, bei mir klappt der Import mit führenden Nullen reibungslos

Setze die zwei Nullen als Prefix beim Import. Das ist die einfachste Lösung. Ggfs. musst du halt zwei Importe machen (einmmal für die Nuller und dann für die anderen EAN)

Eine wirkliche Lösung ist das aber auch nicht. Im Fall der Fälle macht man dann 5 Importe und sortiert alle Artikel vor ... aber wie gesagt, bei mir klappt das (Ameise 0.972)

 

[deepblue]

AW: Import von EAN über die Ameise

Guten Morgen,

habe es nun diverse male ausprobiert. LibreOffice Calc verschluckt immer die vorangestellten "00"
bei der EAN (Beim Export der CSV-Datei)

Die JTL-Wawi Exportiert richtig und packt alles in "

 

[casim]

AW: Import von EAN über die Ameise

Klärt mich mal bitte auf, was "00" am Anfang einer EAN denn für ein Länderkennzeichen sein soll (wobei dieses eigentlich sogar 3stellig wäre)

 

[Guenter H.]

AW: Import von EAN über die Ameise

Guten Morgen,

habe es nun diverse male ausprobiert. LibreOffice Calc verschluckt immer die vorangestellten "00"
bei der EAN (Beim Export der CSV-Datei)

beim Export passiert noch nichts. "Verschluckt" wird die führende Null erst durch LibreOffice Calc, weil du den Spaltentyp beim Öffnen nicht als "Text" definierst, sondern auf "Standard" belässt... 🙂

Grüße

Günter

 

[Thomas_S]

AW: Import von EAN über die Ameise

Hier ein Beispiel für eine EAN mit vielen Nullen. Einfach mal danach suchen 🙂

0000000306669

Tipp: EAN Search

 

[deepblue]

AW: Import von EAN über die Ameise

Hallo Günter (steelcouch),

bei mir hat dein Tip funktioniert. Bei dem Import Voransicht waren die Nullen immer schön drin (genauso bei Notepadd++), erst nach dem ich die CSV in LibreOffice eingeladen hatte, waren die 00 verschwunden. Beim erneuten speicher als CSV-Datei dann komplett draußen.

Hatte vergessen die Spalte EAN auf TEXT zu setzen!

 

[hrx]

AW: Import von EAN über die Ameise

Hallo zusammen,

das Thema würde mich insofern interessieren als dass ich gerne wissen würde ob hier nicht auch jemand das Problem gelöst hat, in CSV Dateien die EANs mit führenden Nullen um ebenjene Null zu "kastrieren" damit im Anschluss eine korrekte Artikelzuordnung möglich wird. Ich habe hier verschiedene Lieferanten die teillweise die Unart verfolgen, UPC Codes um eine führende Null zu ergänzen um daraus vermeintlich echte EANs zu generieren.

Danke für jegliche Hilfe 🙂

 

[Guenter H.]

AW: Import von EAN über die Ameise

Hi,

verschiedene Lieferanten die teillweise die Unart verfolgen, UPC Codes um eine führende Null zu ergänzen um daraus vermeintlich echte EANs zu generieren.

das ist keine Unart sondern vielmehr die einzig richtige Vorgehensweise, um einen UPC in eine gültige EAN umzuwandeln.

Zurück zu deiner eigentlichen Frage: die Ameise kann die führende Null nicht entfernen.

Grüße

Günter

 

[reneromann]

AW: Import von EAN über die Ameise

Hi,



das ist keine Unart sondern vielmehr die einzig richtige Vorgehensweise, um einen UPC in eine gültige EAN umzuwandeln.

Zurück zu deiner eigentlichen Frage: die Ameise kann die führende Null nicht entfernen.

Grüße

Günter

Es ist zwar keine "Unart", sondern sogar korrekt - also wenn man vor den UPC eine "0" stellt, um einen EAN-13 zu erzeugen - aber es kann zu Problemen kommen.

Beispiel: Auf dem Artikel ist ein UPC-Barcode abgedruckt (12-stellig), jedoch verwendet der Lieferant die "verlängerte" EAN-13 in allen CSVs. Wenn ich jetzt die "verlängerte" EAN-13 als Barcode in der Wawi hinterlege und den UPC scanne, findet die Wawi kein Produkt (oder nur dann, wenn die Wawi sucht). Gerade bei LS-POS gibt's dann das schöne Suchfenster, weil es keine exakte Übereinstimmung zwischen Datenbankfeld [EAN-13] und gescanntem Inhalt [UPC-12] gibt. Und um die Sache jetzt noch weiter auszuführen: Druckte man jetzt ein Artikeletikett, so wird statt des UPC natürlich der EAN-13 gedruckt - damit haben die Produkte dann auf einmal zwei verschiedene Barcodes und die "Sch...e ist richtig am Dampfen".

Ergo: Entweder konsequent NUR EAN-13 einsetzen - und dann sollte der Hersteller/Lieferant auch konsequent EAN-13 labeln(!), oder konsequent UPC einsetzen (und dann auch NUR UPC für die betroffenen Artikel). Ich hab mittlerweile die Vorlage vom Artikeletikett schon soweit geändert, dass es mir in Abhängigkeit vom im Artikel hinterlegten Barcode entweder einen UPC oder einen EAN-13 oder einen EAN-128 generiert, weil wir genau auf diese Problematik auch gestoßen sind und uns immer gewundert haben, warum die Barcodes vom Hersteller solche Probleme bereiten. Teilweise wurde an der Kasse dann auf "Divers" statt auf den richtigen Artikel gebucht - was zu schönen Fehlbeständen führt.

 

[poi]

AW: Import von EAN über die Ameise

habe es nun diverse male ausprobiert. LibreOffice Calc verschluckt immer die vorangestellten "00"
bei der EAN (Beim Export der CSV-Datei)

ACHTUNG!!
Wenn du solche Daten mit vorangehenden Nullen mit LibreOffice öffnen willst muss du beim Import dieser Spalte das TEXT Format einstellen!!! Voreingestellt ist dort immer Standard, das KILLT NULLEN. Ich habe das leidvoll herausfinden müssen und arbeite immernoch an der Schadensbegrenzung weil beim Import in die JTL Datenbank einiges schief gelaufen ist.

Nur so am Rande bemerkt... Gruß!

 

[deepblue]

AW: Import von EAN über die Ameise

Hallo,

das Importieren in Libre Calc funktioniert bei uns nun sehr gut. Ich möchte gerne konsequent nur EAN-13 einsetzen.

Heute man die neue Liste vom Großhändler und mir kam das Grauen.

Nun meine Frage kann man in Calc bei der Spalte EAN sagen nur 13 Ziffern, wenn nicht vorne mit "0" auffüllen?

Der Link: http://www.ean-search.org/ ist für uns sehr hilfreich. Vielen Dank! =)

 

[deepblue]

AW: Import von EAN über die Ameise

Hat jemand eine Idee, ob man die "00" oder "0" in Calc vorne anstellen kann? Damit die EAN bzw. GTIN Nummer 13-stellig ist?

 

[deepblue]

AW: Import von EAN über die Ameise

@poi

Vielen Dank für deinen Beitrag. Habe immer darauf geachtet, beim Import meiner CSV-Datei die Spalten auf TEXT Format einstellen.
Nur werden von Haus aus die GTIN-Nummer schon 11 oder 12-stellig geliefert.

Gibt es in CALC nicht eine Lösung damit alle GTIN Nummern 13-stellig sind?

 

[DITH-Shop]

AW: Import von EAN über die Ameise



Es ist zwar keine "Unart", sondern sogar korrekt - also wenn man vor den UPC eine "0" stellt, um einen EAN-13 zu erzeugen - aber es kann zu Problemen kommen.

Beispiel: Auf dem Artikel ist ein UPC-Barcode abgedruckt (12-stellig), jedoch verwendet der Lieferant die "verlängerte" EAN-13 in allen CSVs. Wenn ich jetzt die "verlängerte" EAN-13 als Barcode in der Wawi hinterlege und den UPC scanne, findet die Wawi kein Produkt (oder nur dann, wenn die Wawi sucht). Gerade bei LS-POS gibt's dann das schöne Suchfenster, weil es keine exakte Übereinstimmung zwischen Datenbankfeld [EAN-13] und gescanntem Inhalt [UPC-12] gibt. Und um die Sache jetzt noch weiter auszuführen: Druckte man jetzt ein Artikeletikett, so wird statt des UPC natürlich der EAN-13 gedruckt - damit haben die Produkte dann auf einmal zwei verschiedene Barcodes und die "Sch...e ist richtig am Dampfen".

Ergo: Entweder konsequent NUR EAN-13 einsetzen - und dann sollte der Hersteller/Lieferant auch konsequent EAN-13 labeln(!), oder konsequent UPC einsetzen (und dann auch NUR UPC für die betroffenen Artikel). Ich hab mittlerweile die Vorlage vom Artikeletikett schon soweit geändert, dass es mir in Abhängigkeit vom im Artikel hinterlegten Barcode entweder einen UPC oder einen EAN-13 oder einen EAN-128 generiert, weil wir genau auf diese Problematik auch gestoßen sind und uns immer gewundert haben, warum die Barcodes vom Hersteller solche Probleme bereiten. Teilweise wurde an der Kasse dann auf "Divers" statt auf den richtigen Artikel gebucht - was zu schönen Fehlbeständen führt.

Auch wenn das Thema uralt ist, ist es bei mir mal wieder aktuell.

Ich habe wieder einen Lieferanten der korrekte (also ggf 12stellige) UPC im Feld EAN angibt. Da meine Wawi mit den "verunstalteten" (also ggf um eine führende 0 erweiterte EAN) arbeitet, werden auch bei mir mal wieder nicht alle Artikel gefunden/zugeordnet/importiert/aktualisiert)

Gibt es eine Möglichkeit in der AMEISE 1.1.4.10 einen Platzhalter zu verwenden damit bei einer 12stelligen EAN/UPC auch die 13stellige EAN als korrektes match angesehen und der Artikel aktualisiert wird??
Mit einem "%" als Prefix habe ich es schon versucht, DAS funtz schon mal nicht.

Info:
Da die Artikel-CSV des Lieferanten knapp 700.000 (Ja, korrekt, 5 Nullen) umfasst, ist es aus Zeitgründen NICHT möglich das mehrfach durchlaufen zu lassen.
Zumal die AMEISE auch so schon Probleme zu haben scheint wenn der Import mehrere Stunden dauert ( bei mir sind es bspw. 5 Stunden für die 700.000 Einträge, da dann auch noch Workflows abgearbeitet werden müssen die das nicht wirklich beschleunigen)

Häufig habe ich nach 2 - 2 1/2 Stunden einen Timeout - bspw. wenn dann das automatische Backup läuft, oder "Pflege-SQL" , oder weitere Importe von anderen Lieferanten.