In Bearbeitung Barcodeschema-Fehler

[Nachto]

Guten Tag,

wir haben heute auf 1.0.5.15 geupdated und dort ist der neue Barcodeschema-Editor eingebunden und wir stehen direkt vor dem ersten Fehler.

Wir haben selber Zeitungen mit fast ausschließlich 7% was als T-Prefix die 9 ist, sonst sind keine hinterlegt zusätzlich zu der 41. Normal wäre für mich nun wenn z.B. ein Artikel mit der EAN 41 und T-Prefix 0 gescannt wird, dass er nun wenn kein Schema passt mit dem T-Prefix er es in den normalen Artikeln sucht.
Leider bucht er das nun als Presseartikel statt als normalen Artikel.

Abhilfe würde es schaffen, wenn man prüft ob alle Prefixe belegt bzw definiert sind, falls nicht als normalen Artikel behandeln.

Leider sind aktuell keine Artikel mit 41x scanbar ausser Zeitschriften, da diese dann als Zeitschrift erkannt werden mit z.B. 7,xx€ statt 0,65€.

Freundliche Grüße
Nachto

 

[Philipp K.]

Hallo @Nachto

da ist mir leider ein Fehler bei der Veröffentlichung passiert, diese Version hätte nicht an euch rausgehen dürfen.

Daher erstmal eine dicke Entschuldigung für alle Umstände!

Wir haben eben intern besprochen, dass wir Anfang nächster Woche ein Update mit der alten, fest hinterlegten Funktion herausgeben. Um Datencrashes bei euch zu verhindern, müssen wir dazu aber erst eine neue Version bauen und ein paar Details anpassen, was ein bisschen Zeit in Anspruch nimmt. Ich hoffe, ihr könnt über das Wochenende auf die Funktion verzichten und drückt ein Auge zu.

Nachdem wir den Fehler behoben haben komme ich nochmal auf Deinen Einwand zurück! Schonmal danke vorab

Besten Dank & viele Grüße

Philipp

 

[Nachto]

Hallo @Philipp K.

ich selber hatte mich schon gewundert, weil die Barcode-Schemas voraussichtlich erst für die 1.0.5.0 angekündigt waren und wir gerade bei der 1.0.4.16 (oben hab ich fälschlicherweise 1.0.5.15 geschrieben) sind.
Der Fehler betrifft bei uns zum Glück aktuell nur eine Marke (Durstlöscher von Wesergold, diese haben alle eine EAN beginnend mit 410), sodass die Mitarbeiter informiert wurden, dass sie diese Artikel eben manuell einbuchen müssen.
Also alles in Ordnung, wegen uns braucht ihr euch da keinen Stress machen - unsere Mitarbeiter sind es gewohnt zu "improvisieren"

Falls noch Bedarf an Pilotkunden besteht bei diversen Funktionen im Zusammenhang mit JTL-POS / ERP-Connected, würden wir uns anbieten. Einmal würde eine produktive Umgebung (Chromebox) bereit stehen und eine Testumgebung (Chromebook).

Liebe Grüße
Nachto

 

[Klaus_K]

Hi Nachto,

als ich vor ner Weile den Prototyp im Issue-Tracker gesehen hatte, habe ich mich schon gefragt ob es nicht vielleicht sinnvoller ist bei den Presseerzeugnissen zwei Datensätze zu erzeugen. Auf dem Beleg wird ja auch die Benennung des Schemas "Zeitschrift" auf den Bon übernommen.

Wenn du also ein Schema "Presseerzeugnis 7%" mit Präfix 419 und eins "Presseerzeugnis 19%" mit Präfix 414 (glaub das müsste der für 7% sein) anlegst, wird auf deinem Bon auch im Text direkt die MwSt. angezeigt. Außerdem würdest du das Problem mit dem "410" umgehen. Der Steuer-Schlüsselwert wäre dann im Schema ja nicht mehr erforderlich.



Ich weiß, dass die Funktion noch nicht released werden sollte und auch zurückgebaut wurde - das fixen des Problems ist mit Sicherheit auch für andere Schemata sinnvoll, aber für Presse gäbe es eine schnelle und aus meiner Sicht auch sinnvolle Lösung.

Wie @Philipp K. bereits in einem anderen Post geschrieben hatte, sind die Möglichkeiten echt umfangreich und es gibt für manche Themen auch mehrere Lösungen.

Kannst es ja mal auf deinem Test-System ausprobieren

Viele Grüße und noch einen schönen Sonntag,
Klaus

 

[Nachto]

Hallo Klaus_K,

das wäre natürlich eine Möglichkeit gewesen, da ich selber kein Pilotkunde bin für die Funktion kann ich dies nun leider nicht testen - ein Update kam ja sehr schnell, sodass der Fehler einen Tag später behoben war.

Das mit den Presseprodukten scheint ähnlich gelöst zu sein wie du beschriebst, nur dass ein Schema hinterlegt ist wo man alle Steuersätzen einen (T-)Prefix zuordnen kann, man kann also sagen das erst einmal alle Artikel mit 41 Presseprodukte sind. Anschließend sagen, dass 419 7% und 414 19% sind. Problematisch wurde es erst wenn der T-Prefix nicht eingestellt war - da hätte er theoretisch ja sagen müssen, dass der Barcode nicht "konfiguriert" ist - oder halt eben wie ich oben schrieb gucken ob ein Artikel mit entsprechender EAN existiert.
Es wäre aber denke ich deutlich besser wenn prioritär erst einmal schaut existiert ein Artikel zu dieser EAN, wenn ja soll dieser eingebucht werden. Falls nein gucken ob ein Barcodeschema existiert. So würde man das ganze aus meiner Sicht sinnvoll lösen

Freundliche Grüße
Nachto

 

[Nachto]

Hallo,

das Problem scheint in der Pilotversion 1.0.5.0 noch vorhanden zu sein - vorübergehend haben wir die von @Klaus_K beschriebene Übergangslösung verwendet - hoffen allerdings, dass hier eine Lösung kommt, welche auf den eigentlich gedachten Weg funktioniert

Freundliche Grüße
Nachto

 

[Klaus_K]

Hallo,

das Problem scheint in der Pilotversion 1.0.5.0 noch vorhanden zu sein - vorübergehend haben wir die von @Klaus_K beschriebene Übergangslösung verwendet - hoffen allerdings, dass hier eine Lösung kommt, welche auf den eigentlich gedachten Weg funktioniert

Freundliche Grüße
Nachto

Hallo Nachto,

schade dass es noch nicht funktioniert wie es soll - aber schön dass mein Vorschlag zumindest zur Überbrückung funktioniert

Mir sind auch noch ein paar Sachen aufgefallen, die ich in folgendem Thread aufgeführt habe:
https://forum.jtl-software.de/threa...barcodes-pilotversion-jtl-pos-1-0-5-0.165294/
(u. a. das Thema "Rabatte ausschließen" könnte für dich relevant sein, falls ihr auch mit Rabatten arbeitet - die sind ja bei preisgebundenen Presseerzeugnissen nicht erlaubt)


Viele Grüße,
Klaus