Hi Zusammen,

habe da ne allgemeine Verständnisfrage:

Warum werden nicht immer TB's automatisch in TA's umgewandelt. Ich bekomme jeden Tag en Anruf aus der Produktion, weil die Ware nicht in unser LVS fährt. Wenn ich dann in der LB11 nachschaue, ist dort der TB nicht zu nem TA umgewandelt...... Die Gesamtanzahl dieser "nichtdurchgegangenTB's" bekomme ich in der LL01 angezeigt aber habe bis jetzt nur selten ein Grund dafür gefunden (Ab und zu ist der Endlagerplatz im Materialstamm nicht richtig gepflegt)

Danke schonmal im Vorraus

mfg
Pyriel

Hallo Pyriel,

soweit IM davon betroffen ist, ist das eine Customizing-Einstellung - und die greift pro Lagernummer + Bewegungsart.

Das Thema der sofortigen TA-Erstellung heisst  "direkte TA-Erstellung" - (anders als bei  "automatische TA-Erstellung",  die erwartet einen verarbeitenden Batch-Job.)

Die Transaktion dazu heisst OMKX - aber Achtung, hier wird über Referenz-Bewegungsarten zwischen den Bewegungsarten des IM und den Bewegungsarten des WM gearbeitet ! 

Die kompletten Einstellungen dazu findet man im Customizing des Lagers, vor allem bei den Bewegungsarten des IM und des WM.

---

Hallo nk,

was ich jetzt gerade nicht verstehe, warum wird das IM berührt???

ich bin der Meinung gewesen, dass im IM die Buchung normal gemacht wird und sobald das LVS-lager betroffen ist (ist nur 1 Lagerort von vielen normalen) greift das WM im Hintergrund (bezugnehmend auf die IM-Buchung). Es wird ein TB erzeugt, dieser umgewandelt in einen TA und dann läuft die Ware ins LVS rein (wir haben fürs LVS aber ein Fremdsystem (SAP-Master, Fremdsystem - Slave)

Deswegen habe ich nie an IM Einstellungen gedacht.... :-)

und warum gehen manche Buchung ohne Probleme durch (IM und WM) und manche (vom gleichen Kollegen) bleiben bei als TB liegen. Klar wenn es auf der Schnittstelle oder Matstamm net passt und deswegen auf einen Fehler läuft aber dies ist selten der Fall. ich geh meistens in die LB11 rein und klick auf "TA Hell" und das normale prozedere. Hier laufe ich seltenst auf einen Fehler (bis auf die oben genannten Ausnahmen) 

Hallo PYriel,

der TB ist doch die Schnittstelle zwischen IM und WM. Du machst eine IM-Buchung, deinem IM-Lagerort ist eine LVS-Lagernummer zugordnet - also muss eine WM-Buchung erstellt werden.

SAP macht also einen TB (als Ausfluss der IM-Buchung und der Anforderung: in der zum IM-Lagerort gehörenden LVS-Lagernummer sind von Ware 4711 insgesamt 123456 St zu bewegen, und zwar nach LTyp 914 (bei Ausgang z.B.) oder  von LTyp 901 (bei WE z.B.)  ) und gibt diesen an die Lagerfunktionen, um dort gemäß Strategien einenTA aufzubauen.

---

Das Quant war wahrscheinlich zum Zeitpunkt der automatischen TA-erstellung nicht verfügbar, sprich, ein anderer TA für das gleiche Quant war noch nicht quittiert.

Im Lagertyp kann zum Beispiel definiert werden ob Lagerplatz oder Quant bei Ein-/auslagerung gesperrt werden.

Hallo PYriel,

ich habe dazu bei uns den Report RLAUTA11 als Batch alle 5 Minuten eingeplant, dieser wandelt dann die Transportbedarfe in Transportaufträge um. Da die bei uns sofort quittiert werden, wird damit auch die Bewegung sofort durchgeführt.

mfg Andreas

Hallo,

der RLAUTA11  hilft nur bei AUTOMATISCHER TA-Erstellung.

DIREKTE TA's (und das sind die die ohne Batch-Job tatsächlich sofort asynchron erstellt werden) haben mit dem RLAUTA11 nichts zu tun !

Direkte TA müssen über die OMKX definiert werden.  Wenn man OMKX verwendet, sollte und kann man einen mail-Empfänger angeben, der eventuelle Fehlermeldungen aus der asynchronen Verarbeitung erhält und dadurch über SAP-Office  Zugriff auf den fraglichen TB hat und die genaue Fehlerbeschreibung sieht (ob kein Platz gefunden oder Gesperrt oder was auch immer).

Es hängt von der Anforderung beim Kunden ab, ob man über Batch-Job geht (also TBs ansammelt) oder ob man sofort TAs erzeugt haben will (also OMKX)

---

Guten Tag,

wir haben momentan auch ein ähnlich gelagertes Problem: TB's für die Produktionsversorgung existieren, diese werden dann über den RLAUTA10-Job, soweit möglich, in TA's umgewandelt. Bisher hat das ganz gut funktioniert, aber in letzter Zeit treten speziell bei Abrufteilen (grössere TB's, die mehreren TA's abgearbeitet werden) Probleme auf, weil diese aus einem bestimmten Lagertypen bedient werden sollen. Interessanterweise bekomme ich beim Versuch den TA hell anlegen zu lassen auch die Info, dass der Von-Lagerplatz nicht ermittelt werden kann. Der Lagertyp ist natürlich in der Suche enthalten, aber das System springt aus irgendeinem Grund drüber.. - aber halt nur manchmal.. Somit gehen wir davon aus, dass die Customizing-Einstellungen nicht grundsätzlich unvollständig sein können, aber wohl eine bestimmte Konstellation dafür verantwortlich sein könnte. Vielleicht hat ja jemand einen Tipp für uns wo wir noch suchen könnten?

Danke!

Gruß,

Eva

Hallo Eva,

leg den TA hell an, geh in der LT01 auf Umfeld - Protokoll Platzfindung   und schau dir mal genau an, warum kein Platz gefunden wird.

Das System geht die komplette Findungslogik durch und versucht, einen Platz mit ausreichender Menge und geforderter Bestandsqualifikation  und gem. Auslagertyp-Kz des MatStamms zu finden.

Diese Informationen und ihre Analyse genügen in der Regel, um das Problem zu klären. Es liegt evtl. an fehlerhafter Lagertyp- oder Lagerplatztyp-Findung.

---

Hallo Nk,

danke, danach habe ich gesucht. Allerdings bringt mich die Info dort auch nicht wirklich weiter: er scheint den Lagertypen sehr wohl zu durchlaufen, findet aber aus für mich unerfindlichen Gründen wohl nichts und geht zum nächsten weiter...

Hast du vielleicht sonst noch eine Idee wo ich ansetzen könnte?

Danke & Gruß,

Eva

Hallo Eva,

was steht denn in deiner letzten Zeile des Protokolls der Lagerplatzfindung ?  Und was steht in der letzten Zeile vor der Message und dem Message-Hinweis ?
(die von mir mit  x markierten Zeilen)

Also z.B.    x      Auslagerung Lagertyp 600 Auslagerstrategie FIFO (First in first out)
                            Systemmeldung   L3 008
                      x            VonLagerplatz konnte nicht ermittelt werden

Daraus kann man erkennen, was falsch gelaufen ist.  In diesem Beispiel: letzter durchsuchter Lagertyp war 600, es wurde dort kein Platz mit ausreichender menge und Bestandsqualifikation gefunden.

Wenn du der Meinung bist, daß Plätze mit Material vorhanden sind und das System verwendet die nicht, dann solltest du bedenken, daß z.B. ein Platz, dessen Material in einem nicht quittierten TA enthalten ist, ja nach System-Customizing (Sperrlogik) nicht zur Verfügung steht und übersprungen werden muss - selbst wenn die Materialmenge ausreicht deiner Meinung nach ! Sichtbar in LX02 oder LX03 etc., wenn man die Felder "verfügbarer Bestand", "einzulagernder Bestand" und "auszulagernder Bestand" einblendet. Nur wenn der "verfügbare" ausreicht, kann der Platz verwendet werden. Das Feld "Gesamtbestand" besagt nichts.

Es gibt div. Möglichkeiten, aber nach meiner Erfahrung stimmt die Aussage des Findungsprotokolls immer - man muss nur ergründen, warum man selbst was anderes erwartet als das System tut.

---

Hallo Nk,

zuerstmal vielen herzlichen Dank für die WM-Nachhilfe (das ist ja wirklich nicht meine Welt..) . Diese Info über den ein- bzw. auszulagernden Bestand sehe ich ja auch in der LS24, denke ich. Habe aber brav mal die LX03 mit den Feldern angesehen. Gesamtbestand = Verfüg. Bestand, dh. ein- und auszulagernder Bestand im ganzen Lagertypen ist 0. Im Protokoll steht sinngemäss genau das, was du als Bsp angeführt hast. Es werden vier Lagertypen, jeweils mit der Auslagerstrategie Fifo durchsucht und am Schluss steht die Meldung L3 008. Im dritten Lagertypen wäre der Bestand (aus meiner Sicht) vorhanden.

Je länger ich mich damit beschäftige, desto kurioser wird es. Ich finde kein Muster. Es geschieht bei den geprüften Materialien von Zeit zu Zeit, aber immer in diesem einen Lagertypen. Gestern haben wir sogar festgestellt, dass ein TA  doch automatisch vom Job angelegt worden ist  (2,5 Tage nach der Einlagerung des Materials in den freien Bestand!! das Material lag einsam auf seinem Lagerplatz und dieser hatte auch nur ein Quant) - ach ja, der Job läuft alle 10 Minuten...

Es wird sicher einen Grund geben wieso der Bestand nicht verwendet wird, aber langsam bin ich mir nicht mehr so sicher, ob ich den noch finden werde...

Danke für jeden weiteren Unterstützungsversuch!!

Gruß,

Eva

Hallo Eva,

ohne Detail-Analyse am System wird sich das evtl. nicht ergründen lassen.

Aber es deutet nach deiner Beschreibung darauf hin, daß dieses ominöse Quant gesperrt war zum jeweiligen Zeitpunkt - die Findungs-Strategien  müssen stimmen, sonst würde es nach 2,5 Tagen auch nicht gefunden.
Wenn die Findung nicht verändert wurde und der Lagertyp nicht gesperrt war und das Quant nicht gesperrt war und der Platz nicht gesperrt war und die Menge immer im verfügbaren Bestand war und die Bestandsqualifikation des Materials nicht verändert wurde (Q-Freigabe o.ä.), dann könnte eine bei euch benutzte Modifikation aktiv sein oder ein Bug im SAP.

Das lässt sich dann wohl nur noch am System lösen (debuggen etc.)

---

Hallo nk,

danke. Habe nun in meiner Verzweiflung gebeten den alten TB abzuschliessen und einen neuen anzulegen, um zu sehen, ob sich das Systemverhalten dann ändert.. und siehe da, der TA wird nun durch den Job problemlos erzeugt. Meine Verwirrung wird dadurch zwar noch grösser.. Ich werde das mal im Auge behalten und hoffe doch, dass ich irgendwann verstehe in welcher Situation das auftritt.. Das mit der Modifikation muss ich noch klären (WM mache ich nur vertretungsweise, wie man merkt...).

Vielleicht noch ein Detail von dem Material, wo der TA nach 2,5 Tagen doch entstanden ist. Ich habe mal die alten TA's durchforstet - das System scheint hier immer eine Denkpause - von unterschiedlicher Dauer -  zu benötigen, bevor der TA für den PVB erstellt wird.

Vielen Dank für den tollen Unterstützungsversuch!

Gruß,

Eva