Neu Ware direkt in ein Standardlager einbuchen per SQL StoreProcedure dbo.spWarenlagerEingangSchreiben

[John]

Hi,

ich möchte Ware in ein Standardlager (nicht WMS) direkt per dbo.spWarenlagerEingangSchreiben.
Ameise und REST sind aus Kosten- und Performancegründen keine Option.

Leider finde ich dazu gar nichts. Vielleicht hat ja jemand von Euch mit der Funktion schonmal gearbeitet.

Die spWarenlagerEingangSchreiben

DECLARE @RC int
DECLARE @xWarenlagerEingaenge xml
DECLARE @kArtikel int
DECLARE @kWarenLagerPlatz int
DECLARE @kLieferantenBestellungPos int
DECLARE @kBenutzer int
DECLARE @fAnzahl decimal(28,14)
DECLARE @fEkEinzel decimal(28,14)
DECLARE @cLieferscheinNr varchar(255)
DECLARE @cChargenNr varchar(255)
DECLARE @dMHD datetime
DECLARE @dGeliefertAm datetime
DECLARE @cKommentar varchar(255)
DECLARE @kGutschriftPos int
DECLARE @kLHM int
DECLARE @kSessionId int
DECLARE @kBuchungsart int
DECLARE @kBestellPosUmlagerung int
DECLARE @kRMRetourePos int
DECLARE @nHistorieNichtSchreiben int
DECLARE @kWarenlagerEingang int

EXECUTE @RC = [dbo].[spWarenlagerEingangSchreiben]
   @xWarenlagerEingaenge
  ,@kArtikel
  ,@kWarenLagerPlatz
  ,@kLieferantenBestellungPos
  ,@kBenutzer
  ,@fAnzahl
  ,@fEkEinzel
  ,@cLieferscheinNr
  ,@cChargenNr
  ,@dMHD
  ,@dGeliefertAm
  ,@cKommentar
  ,@kGutschriftPos
  ,@kLHM
  ,@kSessionId
  ,@kBuchungsart
  ,@kBestellPosUmlagerung
  ,@kRMRetourePos
  ,@nHistorieNichtSchreiben
  ,@kWarenlagerEingang OUTPUT
GO

1. kSessionId
Eine Korrekturbuchung in der Wawi holt sich zunächste via spGetAndUpdatePK [@cName = 'tWarenLagerEingangSessionID'] eine SessionID und übergibt sie als kSessionId.
Ein Import per Ameise setzt kSessionId = 0
Welchen Effekt hat das?
Wie lange kann ich eine SessionID nutzen? Für alle Eingänge meiner Imporsitzung?

2. dGeliefertAm
Die Ameise setzt dGeliefertAm = NULL während eine Korrekturbuchung das Datum setzt.
Effekt?

3. kWarenLagerPlatz
Die Ameise und Wawi ermitteln kWarenLagerPlatz (hier mit kLager = 2) unterschiedlich.
Wawi:

SELECT * FROM
tWarenLagerPlatz
WHERE kWarenlager = 2
AND ((kWarenLagerPlatzTyp IS NULL) OR (kWarenLagerPlatzTyp <> 10))

Ameise:

SELECT tWarenLagerPlatz.kWarenLagerPlatz, tWarenLager.cName
FROM tWarenLager
JOIN tWarenLagerPlatz ON tWarenLagerPlatz.kWarenLager = tWarenLager.kWarenLager
WHERE tWarenLager.nFulfillment < 2 AND tWarenLager.nAktiv = 1 AND tWarenLager.nLagerplatzVerwaltung = 0 AND ISNULL(tWarenLager.kUser, 0) = 0
AND tWarenLagerPlatz.kwarenlagerplatztyp != 10 AND tWarenLagerPlatz.kWarenLager=2

Wieso läuft das unterschiedlich?

Der Rest der Procedur ist klaro...

John

 

[Enrico W.]

Welche Performancegründe sprechen gegen die Ameise?
Mit dem Import Preise und Bestände ist das m.E. schnell erledigt?

 

[FOC Solutions]

Welche Performancegründe sprechen gegen die Ameise?

Das ist nicht dein Ernst, die Ameise ist quälend langsam. Wir haben Kunden die müssen täglich über 100000 Artikel aktualisieren, das ist mit der Ameise ausgeschlossen. Das schafft sie in 24h nicht.

 

[Enrico W.]

Doch, die Frage ist durchaus ernst gemeint, denn dass das so langsam sein soll kann ich mit meinen Datenbeständen nicht reproduzieren.
Hättest du eine Beispieldatenbank, mit der ich das mal prüfen könnte?

 

[FOC Solutions]

Doch, die Frage ist durchaus ernst gemeint, denn dass das so langsam sein soll kann ich mit meinen Datenbeständen nicht reproduzieren.
Hättest du eine Beispieldatenbank, mit der ich das mal prüfen könnte?

Das Thema liegt beim Kollegen, nur der ist jetzt im Urlaub. Wir gucken danach, ob wir Euch die Kunden-DB zur Verfügung stellen dürfen.

 

[Enrico W.]

Danke. Sehr gern bis zur Unkenntlichkeit obfuskiert.

 

[JohnFrea]

@Enrico W. die hast Du vielleicht eine Antwort auf meine Eingangsfragen?

 

[Enrico W.]

Nein, hab ich nicht - und wenn ich sie hätte: Wir unterstützen keine DB-Eingriffe.
Das hat auch durchaus Gründe - denn mit dem Eintrag in der Datenbank ist es nicht getan. Es müssen in der Folge Aktionen ausgelöst werden - wie z.B. müssen Abgleiche getriggert werden, Workflows etc.

Um das mal in Relationen zu setzen habe ich jetzt auf die Schnelle eine CSV mit 100k Artikeln erstellt. Diese wurde gerade importiert. Mit der Ameise.
100.000 Datensätze in 54 Minuten, 47 Sekunden.
Als nächstes importiere ich zu diesen 100k Artikeln Bestände. Mal schauen, wie lange das dauert.

Der Import der Bestände hat für 100k Artikel auch gut eine Stunde gedauert.

 

[John]

Die Lager, in die ich schreiben möchte, dienen nur der Ansicht.
Es werden dort Lagerbestände eines anderen Standorts mit einer eigenen, anderen Warenwirtschaft angezeigt.
Sie sind für Auslieferung gesperrt und Workflows darauf nicht gewünscht.

Insofern finde ich Beschreiben legitim.

Hat jemand noch eine Idee, was es mit der SessionID und der Unerschiedlichen Auswertung von kWarenLagerPlatz auf sich hat?
Rober vielleicht @T4DT.GmbH

 

[mvh]

Moin. SessionId wird von WMS und WaWi benutzt, ist eine quasi Richtlinie von Microsoft, und es wird an zig Stellen verwendet. Die Ameise braucht keine Session und prüft es auch nicht. Wir erstellen eine SessionId und verwerfen diese nach dem Vorgang. Genauso dGeliefertAm - ist für den Vorgang in der Ameise irrelevant. Beim kWarenlagerPlatz bezieht die WaWi das Vorwissen und ändert die Abfrage je nach Lager, die Ameise versucht mit einer Abfrage alles zu regeln. In der Regel ist die Ameise "dumm" und "faul" - alles was nicht unbedingt gemacht werden muss - wird auf Null gestellt oder nicht berechnet, und ohne bekannte Lager/Artikel Zustände muss die Abfrage geändert werden.