Neu Lagerbestand von Stücklisten und das Zusammenspiel zwischen Überverkäufen erlauben in Komponenten

[Michael Spaltmann]

Hi,

noch kann ich euch da leider nichts zu sagen. Die Gemüter sind auch intern gespalten und aktuell arbeiten wir an anderen Themen. Sobald ich ein Update habe melde ich mich dazu.

Viele Grüße Michael

 

[John]

Stand ist: Im Westen nichts neues.

Einem Kunden von mir wurde das ganze jetzt zu doof und er hat sich von mir eine Lösung bauen lassen, die Überverkäufe/Lieferbarkeit aller Komponenten auswertet und das dann als Ergebnis automatisch über die Ameise bei Bedarf an den Stücklistenvater hoch vererbt.

 

[M_P]

Stand ist: Im Westen nichts neues.

Einem Kunden von mir wurde das ganze jetzt zu doof und er hat sich von mir eine Lösung bauen lassen, die Überverkäufe/Lieferbarkeit aller Komponenten auswertet und das dann als Ergebnis automatisch über die Ameise bei Bedarf an den Stücklistenvater hoch vererbt.

gut für dich, Arbeit = Umsatz 😉

Für uns als JTL-Kunden ist das Verhalten halt supoptimal und aus unserer Sicht ist die "richtige" Stücklistenlieferzeit- und -bestandsbrechnung eigentlich absolut obligatorisch (wenn man Stücklisten in seinem ERP anbietet).

Diese banalen Stücklisten Basics lernt man imho bereits in der weiterführenden Schule in BWL...

 

[John]

Naja, kannst Du ja selbst entscheiden:

Weiter leiden, warten bis sich die "Gemüter" bei JTL auskäsen oder lösen lassen.

 

[M_P]

Naja, kannst Du ja selbst entscheiden:

Weiter leiden, warten bis sich die "Gemüter" bei JTL auskäsen oder lösen lassen.

Die ÜV sind ja das kleinste Übel (was durch die Einstellbarkeit im "StücklistenVater" dazugekommen ist), das große Problem sind die falschen Bestände und Lieferzeiten und das wirst du ja auch nicht so einfach fixen können...

 

[John]

Bei meinem Kunden waren Überverkäufe und "Erscheint am" wichtig. Das werte ich aus und ändere den Vater entsprechend.

Beschreib doch mal genau, was Dir dazu noch fehlt...

 

[M_P]

Bei meinem Kunden waren Überverkäufe und "Erscheint am" wichtig. Das werte ich aus und ändere den Vater entsprechend.

Beschreib doch mal genau, was Dir dazu noch fehlt...

Dass für einen Stücklistenartikel der richtige Bestand (der den man über den vorhandenen Lagerbestand auch zusammenstellen kann) ermittelt wird.

Denn das ist aktuell nicht der Fall, sofern Stücklistenbestandteile Überverkäufe aktiviert haben, die wirken sich nämlich fälschlicherweise NICHT auf den Bestand aus, wodruch im SHop falsche Bestandsanzeigen (z.B. "Auf Lager") provoziert werden

 

[Desecrator]

ich verstehe nicht, warum man hier überhaupt diskutieren muss, wie sich das verhalten soll im Shop.
Es ist so einfach:

Artikel ÜV erlaubt und lagernd? JA ODER NEIN? wenn der Artikel nicht lagernd ist und ÜV nicht erlaubt ist, dann ist er eben nicht bestellbar.
wie kommt JTL auf die geradezu absolut absurde Idee, diesen Artikel dann trotzdem bestellbar werden zu lassen, nur weil er Teil einer Stückliste ist? 🙄👊🏽

um rechtlichen Problemen aus dem Weg zu gehen kurz gefragt: hat jemand einen WF, gerne auch custom, der hier Kontrolle betreibt und DERWEIL bei diesen Artikel ÜV ausschaltet?

 

[M_P]

wie kommt JTL auf die geradezu absolut absurde Idee, diesen Artikel dann trotzdem bestellbar werden zu lassen, nur weil er Teil einer Stückliste ist? 🙄👊🏽

Das ist ja gar nicht der Fall und darum geh es hier auch nicht.

-> es geht im die Stücklisten und nicht um deren Bestandteile

 

[Desecrator]

äh doch, natürlich ist das das Thema. siehe Post2.
es werden ÜV und/oder Lagerbestände falsch berechnet. und somit lassen sich Stücklisten bestellen, obwohl Bestandteile davon gar nicht bestellbar sind.

 

[M_P]

es werden ÜV und/oder Lagerbestände falsch berechnet. und somit lassen sich Stücklisten bestellen, obwohl Bestandteile davon gar nicht bestellbar sind.

Halbrichtig, es geht genau um das, was du gerade sagst, aber nicht in deinem vorherigen Post...

Sorry dass ich erst angenommen habe, das du auch meinst was du sagst (siehe meine Zitat zuvor).

 

[Desecrator]

naja, ich hab mir jetzt einen windows-dienst gebaut der alle 10 minuten läuft... per sql wird geprüft: ÜV-Status der Komponenten. alle ÜV = Ja? dann auch stückliste ÜV = Ja.
andernfalls ÜV = nein

lagerbestand irrelevant erst mal. keine rechtlichen Probleme derweil.

 

[John]

@Desecrator wieso braucht es dafür einen Dienst?
Ist das nicht eine Artikeleigenschaft, die einmal festgelegt wird und dann war es das?

 

[Lucas357]

also ich finde es sehr gut wie es bisher ist. Also das eine Stückliste den Bestand der Komponenten verringert wenn der Lagerbesteand bei der Komponente aktiviert ist. Und gleichzeitig das Überverkäufe bei der Stückliste möglich sind. Enorm praktisch für uns. Hoffe das bleibt so möglich.

 

[mvh]

@Desecrator wieso braucht es dafür einen Dienst?
Ist das nicht eine Artikeleigenschaft, die einmal festgelegt wird und dann war es das?

Er meint es so: es wird alle 10 Minuten geprüft, ob alle Stücklistenteile ÜV-Status haben, dann wird der ÜV-Status für die Stückliste selbst gesetzt, und umgekehrt
Und ja - es geht auch ohne den Dienst, auf der Datenbankebene über den Trigger tgr_tartikel_INSUP on tArtikel:
z.B.

Spoiler: Beispiel

IF UPDATE(cLagerKleinerNull)
    BEGIN
        DECLARE @StuecklistenMitLager TABLE (kVaterArtikel_Stueckliste INT, kStueckliste_Stueckliste INT);
        IF (EXISTS(SELECT 1 FROM INSERTED LEFT JOIN DELETED ON DELETED.kArtikel = INSERTED.kArtikel WHERE INSERTED.cLagerKleinerNull = 'N' AND DELETED.cLagerKleinerNull = 'Y'))
        BEGIN
            SET CONTEXT_INFO 0x696969;  -- Diesen Trigger nicht mehr aufrufen aus folgendem Code
           
            INSERT INTO @StuecklistenMitLager(kVaterArtikel_Stueckliste, kStueckliste_Stueckliste)
            SELECT DISTINCT tStueckliste.kVaterArtikel, tStueckliste.kStueckliste
            FROM #ModifiedItems
            JOIN dbo.tStueckliste ON tStueckliste.kArtikel = #ModifiedItems.kArtikel

            UPDATE dbo.tArtikel
            SET tArtikel.cLagerKleinerNull = 'N'
            WHERE tArtikel.cLagerKleinerNull='Y' and tArtikel.cAktiv='Y'
            AND tArtikel.kStueckliste IN
            (SELECT kStueckliste_Stueckliste FROM @StuecklistenMitLager)

            SET CONTEXT_INFO @OldContextInfo;
        END
        IF (EXISTS(SELECT 1 FROM INSERTED LEFT JOIN DELETED ON DELETED.kArtikel = INSERTED.kArtikel WHERE INSERTED.cLagerKleinerNull = 'Y' AND DELETED.cLagerKleinerNull = 'N'))
        BEGIN
            SET CONTEXT_INFO 0x696969;  -- Diesen Trigger nicht mehr aufrufen aus folgendem Code
           
            INSERT INTO @StuecklistenMitLager(kVaterArtikel_Stueckliste, kStueckliste_Stueckliste)
            SELECT ts2.kVaterArtikel, ts2.kStueckliste
            FROM dbo.tStueckliste ts2
            JOIN(
                SELECT DISTINCT tStueckliste.kVaterArtikel, tStueckliste.kStueckliste
                FROM #ModifiedItems
                JOIN dbo.tStueckliste ON (tStueckliste.kArtikel = #ModifiedItems.kArtikel)
            ) ts1 ON ts1.kStueckliste=ts2.kStueckliste
            OUTER APPLY (SELECT CASE WHEN cLagerKleinerNull='Y' THEN 1 ELSE 0 END AS nLagNull FROM eazybusiness.dbo.tArtikel ta WITH (NOLOCK) WHERE ta.kArtikel=ts2.kArtikel) mx
            GROUP BY ts2.kStueckliste, ts2.kVaterArtikel
            HAVING COUNT(*) = SUM(mx.nLagNull)

            UPDATE dbo.tArtikel
            SET tArtikel.cLagerKleinerNull = 'Y'
            WHERE tArtikel.cLagerKleinerNull='N' and tArtikel.cAktiv='Y'
            AND tArtikel.kStueckliste IN
            (SELECT kStueckliste_Stueckliste FROM @StuecklistenMitLager)

            SET CONTEXT_INFO @OldContextInfo;
        END
    END

 

[Desecrator]

das würde auch gehen, richtig. wäre ein Eingriff in JTL, da bin ich immer bissl ängstlich was updates etc angeht. wäre aber genau das gewünschte Verfahren und natürlich auch von Vorteil, weil es immer unmittelbar ausgeführt wird.
wir haben uns daher für einen sql-code per Aufgabenplaner entschieden, welcher einfach alle 10 Minuten eine Prüfung anstellt.

 

[frankell]

das würde auch gehen, richtig. wäre ein Eingriff in JTL, da bin ich immer bissl ängstlich was updates etc angeht.

Rein aus Interesse: Wie setzt Du denn die Werte? Doch auch über SQL, was ja auch ein DB-Eingriff ist.

Oder meinst Du die Änderung eines JTL-eigenen Triggers? Das würde ich aus dem von Dir benannten Grund auch nicht machen. Dann lieber nen eigenen setzen.

Zumal der INSUP auf tArtikel auch "nur" die globalen Überverkäufe setzt und nicht die des gewünschten Kanals, wobei man letzteres auch einfach überall setzen kann, weil es eh nur zusammen mit den globalen Überverkäufen funktional ist. Klugscheißer-Nachricht Ende. 😀

 

[mesh]

Wir haben - wie hier beschrieben - einen Custom WF erstellen lassen, der Überverkäufe eine Stücklisten-Hauptartikels auf Kinder vererbt.

Überverkäufe Stücklisten

Leider ist der Custom WF durch das Zwangsupdate auf 1.11.10 (DHL Versenden 4.0) in meinem Advanced-Paket jetzt nicht mehr funktionsfähig.
Gibt es eine andere Lösung für meine Anforderung ?

 

[mvh]

Wir haben - wie hier beschrieben - einen Custom WF erstellen lassen, der Überverkäufe eine Stücklisten-Hauptartikels auf Kinder vererbt.

Überverkäufe Stücklisten

Leider ist der Custom WF durch das Zwangsupdate auf 1.11.10 (DHL Versenden 4.0) in meinem Advanced-Paket jetzt nicht mehr funktionsfähig.
Gibt es eine andere Lösung für meine Anforderung ?

PowerShell-Skript mit Timer oder Datenbank-Trigger.

 

[frankell]

Da der CustomWorkflow für die DB letztlich nicht anderes als eine SP ist, würde ich deren Code einfach als neue SP anlegen und die Aktion des Workflows (Ausführen des CustomWorkflows) zu "Ausführen" ändern. Und dann halt ein Skript, das ein Skript startet, das die SP auf der DB ausführt. Das ist am Ende am wenigsten Aufwand, man bleibt mit einem Bein (auslösendes Ereignis) in der Wawi, der Code im Skript ist maximal minimal, kein Gefummel mit eigenem Trigger, und die Ausführung ist identisch zu vorher.