Neu DPG Pfand-Marken aufkleben

[garifulin]

Guten Tag mit einander,

es tut mir ganz ehrlich leid dass ich das überhaupt fragen muss.
Im Einsatz ist bei uns die JTL Wawi 1.8.11.2
Lager arbeitet mit JTL Packtisch+
Plan&Produce wird nicht eingesetzt.
Nun bekommen wir Ware aus dem Ausland und diese soll auf den Deutschen Markt vertrieben werden. Dafür haben wir auch schon reichlich Etiketten bekommen mit allen für den deutschen Markt nötigen Informationen UND neuer GTIN.
Somit habe ich für Artikel xxx einen Zustand erstellt "zum bekleben" xxx-zBk
xxx-zBk hat als GTIN die Original GTIN so wie wir es vom Lieferanten erhalten haben.
xxx ist für den deutschen Markt verkaufsfertig.

Wareneingang würde ja über xxx-zBk gehen und Sobald 1.000 davon beklebt wurden muss ein Mitarbeiter den Zustand für diese 1.000 von xxx-zBk zum Standard xxx ändern somit hätten wir 1000 Stück des Artikels xxx für den deutschen Markt bereit.
Bis hier her soweit auch umsetzbar und verständlich, glaube ich zumindest.

Nun zu den Etiketten diese haben wir ja auch kaufen müssen und davon haben wir nicht unendlich viele. Wie bringe ich das System nun dazu, dass wenn man diese 1.000 xxx-zBk Zustandsänderung erfahren zu 1.000 xxx im gleichen Zuge 1.000 entsprechende Etiketten mit ausgebucht werden?
Sagen wir mal die Artikelnummer für die Etiketten dieses Artikel wird entsprechend etk-xxx sein.

Wie gehe ich hier am besten vor?
Geht es über eine Workflow?
Wird es ein CustomWorkflow werden müssen?
Gibt es überhaupt einen Trigger für Zustandsänderung.

Mein Hirn ist für heute schon mal Verbrannt 🙃

Grüße gari.

 

[Dustin]

Mal ganz dumme Idee warum arbeitest du nicht mit Stücklisten heißt du führst die Etiketten als separates Produkt und dann beim verpacken wird der Stammartikel und das Etikett angezeigt....

 

[frankell]

Hallo @garifulin,

grundsätzlich hat @Dustin nicht unrecht. Aber: Stücklisten kommen wieder mit ihren eigenen kleinen und großen Problemchen im Gepäck, an diversen Stellen. Das ist für diesen Fall daher eher nicht zu empfehlen.

Wenn die Ware des Artikels xxx immer aus dem Ausland, also zunächst als xxx-zBk kommt, dann würde ich eher ne SQL-Query schreiben, die die Wareneingänge des Artikels xxx zählt. Damit weißt Du ja gleichzeitig, wie viele Etiketten Du verbraten hast.

 

[Dustin]

Hi @frankell ,

welche Probleme meinst du bei den Stücklisten?

Aber SQL Query beim Wareneingang? Dann hat er das Problem das die schon ausgebucht sind bevor der Mitarbeiter die beklebt hat.... das wäre so auch nicht richtig denke ich.

LG

 

[frankell]

Sorry, ich meinte gar nicht Wareneingang, sondern vielmehr die Umbuchung vom zBk-Zustand in den Normalzustand.

Stücklisten sind bspw. in den Formular-Vorlagen immer so ne Wissenschaft für sich, vor allem, wenn man in den Dokumenten nur Stücklistenväter oder -komponenten angezeigt bekommen möchte. Ich schätze mal, dass Du nicht in den Dokumenten stehen haben möchtest, dass der gekaufte Artikel aus dem gekauften Artikel und einem Etikett besteht. Auch wenn das Gewicht ausgegeben wird und der Stücklistenvater das Summengewicht aller Komponenten hat, aber sowohl Vater als auch die Komponenten aufgelistet werden (-> doppeltes Gewicht). Und schließlich werden im Shop standardmäßig auch die Komponenten angezeigt.

Man kann alldem irgendwie begegnen, aber es kann mühselig sein. Und das nur für das Tracken der Etiketten.

 

[garifulin]

@frankell ja so etwas in der art habe ich mir gedacht, beim Umbuchen Erweiterte Eigenschaft zählen und diesen Wert dann bei etk-xxx minusbuchen. Aber ich finde nichts wo ich das eintragen kann. Deswegen die Idee mit CustomWF

 

[garifulin]

wow ich habe hier was gefunden als Idee
https://forum.jtl-software.de/threa...w-automatisieren-jtl-automation-video.152728/
hier nicht auf Wareneingang gehen sondern auf umbuchungen und 1x am Tag die etk-xxx entsprechend der Menge ausbuchen
jetzt müsste ich den passenden SQL dafür zusammenschustern/finden.

 

[frankell]

Die Umbuchungen landen auch in den Warenlagereingangs- bzw. -ausgangstabllen, also tWarenLagerEingang und tWarenLagerAusgang.

Ein Zustandsartikel kann als eigenständiger Artikel mit eigenem Lagerbestand geführt werden, wenn das Häkchen dafür bei den Einstellungen dieses Artikelzustands gesetzt ist. Der Zustandsartikel erhält dann eine eigene kArtikel, nach der Du wiederum in tWarenLagerAusgang filtern kannst und dann die Summe von fAnzahl ziehst. Das bringt Dir über die Zeit aber nur etwas, wenn Du davon auch die Gesamtmenge der Eingänge der Etiketten abziehst. Aber wenn Du deren Wareneingänge immer schön in der Wawi pflegst, dann solltest Du zu jedem Zeitpunkt sagen können, wie viele Etiketten noch da sein sollten.

Ob sie es dann tatsächlich sind, ist ja immer ne andere Frage.

 

[garifulin]

Zustand ändern scheint kBuchungsart 150 zu sein in der tWarenLagerEingang und tWarenLagerAusgang das bedeutet dass wenn ich 1x am Tag den WF um 23:00 laufen lasse mit

SELECT SUM([tWarenLagerAusgang].fAnzahl)
  FROM [eazybusiness].[dbo].[tWarenLagerAusgang]
  JOIN tArtikel ON tArtikel.kArtikel=[tWarenLagerAusgang].kArtikel
where  kBuchungsart=150
AND tArtikel.cArtNr LIKE '%-zBk'
AND DAY([tWarenLagerAusgang].dErstellt) = DAY(GETDATE())
AND MONTH([tWarenLagerAusgang].dErstellt) = MONTH(GETDATE())
AND YEAR([tWarenLagerAusgang].dErstellt) = YEAR(GETDATE())

dann habe ich die Gesamtanzahl der verbrauchten Etiketten.


Oder noch Besser pro Artikel

{% capture query -%}
DECLARE @kArtikel AS INT = {{ Vorgang.Allgemein.Stammdaten.InterneArtikelnummer }};

SELECT SUM(a.fAnzahl)
  FROM tWarenLagerAusgang a
  JOIN tArtikel an ON an.kArtikel=a.kArtikel
where  kBuchungsart=150
AND a.kArtikel=@kArtikel
AND an.cArtNr LIKE '%-zBk'
AND DAY(a.dErstellt) = DAY(GETDATE())
AND MONTH(a.dErstellt) = MONTH(GETDATE())
AND YEAR(a.dErstellt) = YEAR(GETDATE())
{% endcapture -%}

{{ query | DirectQueryScalar }}

dann müsste ich nur noch im WF sagen diese Anzahl beim Artikel etk-xxx Minus buchen.

so kommen wir der Sache glaube ich näher.

 

[frankell]

Es gibt aber keine solche Workflowaktion. Du könntest allerdings ein Eigenes Feld beim entsprechenden Artikel mit dem tatsächlichen Lagerbestand befüllen.

Oder aber Du lässt einfach gar keinen Workflow laufen, sondern baust Dir einfach den Code als Eigene Übersicht. Dann müsstest Du nur die Datumsfilter rausnehmen, damit Du alle (historischen) Ausgänge allen (historischen) Eingängen gegenüberstellen kannst. So wird dieser Code immer nur ausgeführt, wenn man tatsächlich mal die Zahl wissen möchte und nicht jeden Tag (auch wenn nichts passiert ist) und zusätzlich in Abhängigkeit vom Worker. Du hast damit zwar einen "falschen" Lagerbestand direkt beim Artikel, aber in der Eigenen Übersicht ist immer der (theoretisch) korrekte einsehbar. Und manuelle Korrekturbuchungen sind natürlich auch immer möglich.

 

[garifulin]

@frankell danke dir für deine Unterstützung. Also muss der Mitarbeiter der die Zustandsänderung bucht zusätzlich noch die Etiketten mit ausbuchen. Schade.

 

[frankell]

Das ist so, ja. Die Lösung dafür wäre nur die Stückliste, die aber wiederum nicht die Lösung ist.