Korrekte Lagerbestände selber bestimmen (SQL-Skript), da Programm sie falsch ausgibt

[woru56]

Version 0.9.9.701


Im JTL-Wawi wird zurzeit wie folgend beschrieben der Lagerbestand
beeinflusst:


· Erstellung eines Angebotes

• keine Änderung des „Lagerbestandes“, „Reserviert“ und „Verfügbar“

--> ist OK!

· Erstellung eines Auftrages

• „Verfügbar“ wird um bestellte Positionen vermindert
• „reserviert“ wird um bestellte Positionen erhöht
• „Lagerbestand“ (berechnet, Summe aus beiden) bleibt konstant

--> nachvollziehbar

· Änderung eines Auftrages

• „Verfügbar“ wird um geänderte oder neue Positionen angepasst
• „Reserviert“ bleibt unverändert (falsch!)
• „Lagerbestand“ (berechnet, Summe aus beiden) ändert sich (falsch!)

--> eindeutig falsch!

· Lieferdatum setzen (Lieferschein auch ohne Datum möglich (falsch!)

• keine Änderung des „verfügbaren“, „reservierten“ und des „Lagerbestandes“

--> falsch, da ausgelieferte Ware nicht mehr im Lager sein kann!

· Rechnung schreiben à

• „Verfügbar“ ändert sich nicht
• „Reserviert“ falsch reserviert wird auch nur falsch vermindert (Fehler heben sich auf!)
• „Lagerbestand“ (berechnet, Summe aus beiden) ??

--> nach Rechnungslegung für alle Varianten alles wieder korrekt

Es ist verwirrend, aber nachvollziehbar. Der „Reservierungsfehler“ beruht auf einer
neu eingeführten Tabelle (ab Version 0.9.9.6xx) „tReserviert“, in die mit
Auftragserstellung die bestellten Positionen eingetragen werden.

Aus dieser Tabelle werden die angezeigten Werte für „Reseviert“ berechnet.
Wenn ein Auftrag noch einmal angefasst wird (Menge wird verändert oder
Position wird hinzugefügt oder gelöscht), wird die Tabelle „tReseviert“ nicht
mit verändert. Daraus resultieren dann diese „Reservierungsfehler“.

Hier auf eine Nachbesserung zu hoffen, ist wahrscheinlich vergebens. Zum Glück
werden die betreffenden Positionen mit Rechnungsstellung aus der Tabelle
„tReserviert“ gelöscht und beeinflussen dann den „Lagerbestand“ nicht mehr.

Im Forum wurde bereits diskutiert, ob der „Lagerbestand“ bereits mit Lieferung
(Lieferdatum setzen) korrigiert werden soll. Hierzu gibt es nur eine vernünftige
Antwort: JA! Wenn ich in das Lager gehe, muss ich genau die Anzahl der Artikel
dort vorfinden, die mein Wawi als Lagerbestand ausweist. Wie soll sonst eine
Kontrolle ( Inventur) durchführbar sein.

Um diese Zahlen zu erhalten und um den beschriebenen Programmfehler
aufzuzeigen habe ich ein Skript geschrieben, dass ich allen JTL-Wawi-Nutzern
gerne zur Verfügung stellen möchte (als Anhang). Es wertet nur Daten aus,
kann also nichts an den Datenbänken verändern!

Es ist natürlich nur für solche Anwender, die mit einem SQL-Skript auch etwas
anfangen können (z.B. wissen, wie man es zum Laufen bekommt).

Wichtig:
Es ist für Artikel geschrieben, die entweder keine oder nur genau eine Variation
haben. Die Anzahl der Variationswerte ist beliebig.
Falls mit Artikeln gearbeitet wird, denen mehrere Variationen zugeordnet
wurden, ist das Skript leicht anzupassen (siehe Kommentar im Skript).

 

[woru56]

AW: Falsch berechnete Lagerbestände

Version 0.9.9.701
Der „Reservierungsfehler“ beruht auf einer
neu eingeführten Tabelle (ab Version 0.9.9.6xx) „tReserviert“, in die mit
Auftragserstellung die bestellten Positionen eingetragen werden.

Aus dieser Tabelle werden die angezeigten Werte für „Reseviert“ berechnet.
Wenn ein Auftrag noch einmal angefasst wird (Menge wird verändert oder
Position wird hinzugefügt oder gelöscht), wird die Tabelle „tReseviert“ nicht
mit verändert. Daraus resultieren dann diese „Reservierungsfehler“.

Ich möchte mich mit diesem Punkt nochmals an die Programmierer (Janusch??) wenden.
Mir ist schon klar, dass mittlerweile das "Kern- Wawi" zur Nebensache geworden ist.
Trotzdem sollten noch klar beschriebene Fehler beseitigt werden können.
Die Ursachen für bestimmte Fehler zu finden, macht auch Mühe (die so den Entwicklern abgenommen wird).

 

[woru56]

AW: Korrekte Lagerbestände mit SQL-Skript bestimmen

Version 0.9.9.701
Um diese Zahlen zu erhalten ... habe ich ein Skript geschrieben, dass ich allen JTL-Wawi-Nutzern
gerne zur Verfügung stellen möchte (als Anhang). Es wertet nur Daten aus,
kann also nichts an den Datenbänken verändern!

Gibt es hier wirklich niemand, der hinter die Kulissen schauen möchte?

Es ist schon erstaunlich, das solche Dinge offensichtlich auf kein Interesse stoßen.

 

[pikantum]

AW: Korrekte Lagerbestände selber bestimmen (SQL-Skript), da Programm sie falsch ausg

Da will ich mal deinen Monolog unterbrechen:

Ich vermute mal, das der Gesamtfokus vom JTL-Team auf die bevorstehende Auslieferung vom Shop 3 gerichtet ist. Da werden evt. manche Sachen warten müssen.

Aber interessiert mitlesen ist schon....

 

[Janusch]

AW: Korrekte Lagerbestände selber bestimmen (SQL-Skript), da Programm sie falsch ausg

Hallo,

ja, momentan geht es etwas drauf und drüber...

Dennoch:

· Änderung eines Auftrages

„Verfügbar“ wird um geänderte oder neue Positionen angepasst
„Reserviert“ bleibt unverändert (falsch!)
„Lagerbestand“ (berechnet, Summe aus beiden) ändert sich (falsch!)
--> eindeutig falsch!

Aus dieser Tabelle werden die angezeigten Werte für „Reseviert“ berechnet.
Wenn ein Auftrag noch einmal angefasst wird (Menge wird verändert oder
Position wird hinzugefügt oder gelöscht), wird die Tabelle „tReseviert“ nicht
mit verändert. Daraus resultieren dann diese „Reservierungsfehler“.

Die Reservierung wird definitiv angepaßt.

Evtl. bitte um kurze Vorführung wie es zu dieser Annahme kommt (am besten per TV), vielleicht spielen andere Faktoren noch eine Rolle.

Aktuell wird "reserviert" erst dann gebucht wenn eine Rechnung erstellt wird.
Dies wird sich ändern sobald Teillieferungen einegführt werden.

 

[woru56]

AW: Korrekte Lagerbestände selber bestimmen (SQL-Skript), da Programm sie falsch ausg

Hallo Janusch,

Evtl. bitte um kurze Vorführung wie es zu dieser Annahme kommt (am besten per TV), vielleicht spielen andere Faktoren noch eine Rolle.

eigentlich dachte ich den Fehler deutlich genug beschrieben zu haben.
Außerdem habe ich noch ein Skript beigefügt. Aber bitte hier noch einmal alles Schritt für Schritt
(jetzt mit Version 0.9.9.705):

Ausgangssituation:

Schuh mit 2 Größen, je 50 Paar am Lager:
siehe Bild "Lager-Ausgangsposition.jpg"
(leider kann ich kein pdf hochladen, deshalb jpg)

Auftrag erstellt für 10x Testartikel 2; Größe 37:

siehe Bild "Lager-nach Auftragserstellung.jpg"

Soweit so korrekt!

Auftrag wird um eine Position nachträglich ergänzt (5xTestartikel 2, Größe 38:

siehe Bild "Lager-nach Auftragsänderung.jpg"

Aber plötzlich Schwund im Lager (Reserviert wird nicht erhöht!)

Falsch!

Die Ursache ist, wie schon beschrieben, in der Handhabung der Tabelle
tReserviert zu sehen. Deren Inhalt wird nur zur Auftragserstellung (Hinzufügen von Datensätzen)
und bei Rechnungslegung (Löschen von Datensätzen) verändert.
Bei Auftragsänderung oder Ergänzung wird sie nicht mit korrigiert.
Dass der Programmierer sich nicht viele Gedanken gemacht hat, ist
schon daran zu sehen, dass vom üblichen Namensschema abgewichen worden ist.
Statt den Feldbezeichner "tBestelleigenschaft_kBestellPos" zu verwenden, wird einfach nur "kKey" vergeben,
abweichend davon, wie es sonst in den anderen Tabellen gemacht wurde.

 

[Janusch]

AW: Korrekte Lagerbestände selber bestimmen (SQL-Skript), da Programm sie falsch ausg

Hallo,

eigentlich dachte ich den Fehler deutlich genug beschrieben zu haben.

Genau das ist das Problem, es hat die Info gefehlt das es sich um "Lager in Variation" handelt.
Normale Artikel werden korrekt geändert.

Ich prüfe dies.

 

[woru56]

AW: Korrekte Lagerbestände selber bestimmen (SQL-Skript), da Programm sie falsch ausg

Ich prüfe dies.

Ok, der Fehler ist mit der aktuellen Version 0.9.9.706 ausgemerzt.

Bleibt das Problem, dass bei Artikeln mit Variationen zwar der Gesamtbestand
im Lager jetzt korrekt angezeigt wird, jedoch nicht für die einzelnen Variationen.

Beispiel Inventurliste (siehe angehängtes jpg).

Zusätzlich besteht auch weiterhin das Problem, dass Artikel als reserviert
vorgehalten (und damit dem Lagerbestand zugeschlagen werden),
wenn diese bereits ausgeliefert worden sind.

Die Zusammenhänge sind einfach vielschichtiger, als dass sie mit einer einfachen Zusatztabelle tReserviert abgefangen werden können.

Wahrscheinlich sollte man als Anwender das Konzept Artikel mit eigenständigen Variationen aufgeben. Der Schwenk zum Konzept "Variationskombinationen"
wird wohl schon deshalb notwendig werden, da es eigentlich sinnvoller ist und von den Entwicklern auch weiter voran getrieben wird. Schade nur um die ganze Arbeit bisher.

Für mich bedeutet das Abschiednehmen vom JTL-Wawi!