Ansicht
Dokumentation

STEN_VWWS_STORDER_JRFC - Dispatcher zum Verarbeiten der übergebenen Auftragspositionen (ORDER_P...)

STEN_VWWS_STORDER_JRFC - Dispatcher zum Verarbeiten der übergebenen Auftragspositionen (ORDER_P...)

rdisp/max_wprun_time - Maximum work process run time   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Der Funktionsbaustein wird aus folgenden Anwendungen aufgerufen:

  • ALE-Wareneingangserfassung ohne Bestellbezug
  • Nachschubdisposition
  • Verarbeitung der Filialauftragspositionen per ALE-Eingang
  • Frischedisposition
  • Bestelloptimierung (Investment-Buying und Bestellbündelung)

Er erhält eine Tabelle mit Auftragspositionen als Import und die Information, woher der FB aufgerufen wurde (Vermeidung von doppelten Prüfungen).

Die fehlerhaften Positionen werden zurückgemeldet. Es sollte angegeben werden, welcher Belegtyp pro Position erzeugt werden soll. Fehlt diese Angabe, wird im internen Schnittstellenprofil (TWPIS) ein Defaultbelegtyp ermittelt. Das Schnittstellenprofil wird pro Kunde bzw. Kunde/Warengruppe ermittelt.

Der Default-Typ ergibt sich getrennt nach Nachschub (alle Prozesse, die nicht Filialauftrag sind) und Filialauftrag und abhäng von interner bzw. externer Beschaffung.

Wenn intern/extern nicht entschieden werden kann, so wird der Default/Default genommen. Ist dieser ebenso leer, oder

kann kein Profil gefunden werden, wird eines Bestellung gezogen. Der Absender der Auftragspositionen muß enthalten sein (= ALE-Absender).

Pro Position müssen mindestens der Materialidentifikator (z.B. die EAN) und die Menge definiert sein. Dies wird geprüft. Bei Fehler wird ein Workflow für die fehlerhafte Position erzeugt.

Der Baustein kann je nach Angabe im Import-Parameter STEP folgendermaßen arbeiten:

  • STEP = ' ' - "einstufig"
  • STEP = '1' - "zweistufig; 1. Schritt"
  • STEP = '2' - "zweistufig; 2. Schritt" wird derzeit nicht unterstuetzt !
  • Einstufig heißt:
Alle Positionen werden geprüft, angereichert und sortiert, dann direkt zu den gewünschten Belegen verarbeitet!

  • Zweistufig heißt:
Alle Positionen werden in zwei Stufen verarbeitet.


- 1. Schritt: Alle Positionen werden geprüft, angereichert,
sortiert und auf der DB zwischengespeichert
- 2. Schritt: Alle Positionen werden ohne Anreicherung eventuell
noch sortiert, dann direkt zu den gewünschten Belegen
verarbeitet.

Achtung
Zwischen Schritt 1 und 2 können belegübergreifende Optimierungen stattfinden. Das Optimierungsprogramm liest die Belegpositionen aus dem Zwischenpuffer. und übergibt sie an den Dispatcher zur Verbuchung.

Alle korrekten Positionen werden mit den entsprechenden Funktions- bausteinen aus dem Modul MM-Einkauf bzw. SD-Versand bzw. SD-Verkauf zu den gewünschten Belegen verarbeitet.

Als Belege sind folgende Belegtypen erlaubt:

  • ' ' MM-Bestellungen
  • 1 MM-BANF
  • 2, 3 MM-Bestellungen (default)
  • 4 SD-Lieferung ( Lieferung direkt oder Lieferung ohne Kundenauftrag)
  • 7 SD-Kundenauftrag
  • 8 Bestellkopie = 3 ohne Anstoß NAST
  • A GUESTORDER (Bestellung - intern, wenn Ware nicht verfügbar - extern)
  • B GROSSMENGE (Bestellung - intern, wenn Menge geliefert werden darf
  • => MVKE-LFMAX - sonst suche andere Bezugsquelle intern
  • oder extern)
  • unterstützt.

Es können teilweise Konditonen übergeben werden (siehe unten)

  • HEAD_CONDITIONS
  • ITEM_CONDITIONS

Beispiel

Materialnr: x

Menge: 5

Belegtyp 3 => Bestellung mit einer Position zu Lieferant y der mittels Bezugsquellenfindung gefunden wird.

Beachte if Lieferant/Lieferwerk leer und Belegtyp Bestellung und BSART "UB" oder Belegtyp = Lieferung ==> Reine VZ-Findung ! Es können Konditonen teilweise mitgeliefert werden

Hinweise

  • Codes wie zB. Währung Angabe nach ISO-Norm ist Pflicht!
  • Es können nur Aufträge für aktuellen Mandanten (Kontrollsatz IDOC) entgegengenommen werden!
  • Datum wird immer in Format yyyymmtt erwartet !
  • Externe Bestellnummer im Sinne einer externen Nummernvergabe in SAP wird nicht unterstützt, Mitgabe einer externen Bestellnummer als Referenz (z.B. auch für eine Bestellbestätigung) ist erlaubt. Fehlt die Belegnummer, wird die mit führendem 'I' markierte und komprimierte Nr des IDOC's eingetragen, um z.B. Fehlerworkflows zu erzeugen.
  • Texte, z.B. Bestelltexte können nicht übermittelt werden!
  • Unbelegte Felder sind immer mit Blank gefüllt.
  • Falls in den Auftragspositionen kein Lieferant/Lieferwerk mitgeliefert wird, erfolgt eine Bezugsquellenfindung; werden mehrere Ergebnisse gefunden, wird der erste gefundene Eintrag (TOP-DOWN) gewählt. Wird ein Lieferant mitgeliefert, so wird dieser ungeprüft verarbeitet. Tritt ein Fehler auf, so wird ein Workflow für diese Position ausgelöst.
  • Werden Auftragspositionen ohne Bezugsquelle übermittelt, und sind durch Anreicherung der Positionen mit verschiedenen Bezugsquellen mehrere Bestellungsbelege zu erzeugen, so werden die Positionen entsprechend sortiert und zu Belegen verarbeitet.
  • Eine Lieferantenartikelnummer als Positionsidentifikator ist nur dann sinnvoll, wenn der Lieferant mitgeliefert wurde.
  • Die Mengeneinheit muß entweder mitgeliefert werden oder muß eindeutig ermittelt werden können.
  • Wird die Mengeneinheit übermittelt, wird sie übernommen. Auf Basis von Menge und Mengeneinheit wird eine Mengenoptimierung pro Position je nach Rundungsprofil durchgeführt. Dabei wird die Menge eventuell gerundet oder an ein Min/Maxintervall agepaßt und eventuell umgerechnet in eine logistische Mengeneinheit.
  • Es muß mindestens pro Position die Menge und ein Artikelidentifikator z.B. EAN oder Artikelnummer im IDOC enthalten sein.
  • Einteilungen (Bestellung) sind als verschiedene Positionen zu senden.
  • Es werden nur default-Kontierungstypen gezogen (else Ktyp + k_daten wie z.B. Kostenstelle etc. ...
  • Werden Werte wie z.B. Lieferant oder Mengeneinheit übermittelt, so werden diese im Dispatcher aus Performancegründen nicht mehr überprüft.
  • Im Fehlerfall wird für diese Position ein Fehlerworkitem per Workflow erstellt. Folgende Methoden werden unterschieden:
  • Wenn eine Bestellung erzeugt werden sollte, so wird die Methode Bestellung erzeugen per Batch Input-Mappe gewählt. Die übermittelten Daten werden dem Sachbearbeiter bei Abarbeitung des Items vorgeblendet.
  • Analog wird ein BANF-BatchInput(ME51) erzeugt, wenn Fehler bei der BANF-Erzeugung auftraten.
  • Analog wird ein Lieferungs-Batchinput(VL01) erzeugt. wird im Workflow ein Fehlerreport für die fehlerhaften Positionen dem Sachbearbeiter angezeigt.
  • Die Fehlerbearbeitungsstelle ist über Standardrolle definiert.
  • Entweder überdie Customizingtablle TWPDO bzw. über user exit können PD-Objecte als Bearbeiter der Workitems ermittelt werden.
  • Die 5 Workflow-Methoden beziehen sich auf die Standard-Aufgabennummern:
- 'TS00900071' Fehler-/Warnungsliste
wird derzeit aus Performanceaspekten nur noch im Belegfluß (WPLST)
angezeigt, also nicht genutzt !
- 'TS00900073' Bestellung anlegen Batch Input
- 'TS00900075' Banf anlegen Batch Input
- 'TS00900079' Lieferung anlegen Batch Input
- 'TS00900060' Kundenauftrag anlegen Batch Input

Sonderfunktionen

Filialauftrag stornieren

Zur mit gelieferten Belegnummer wird der entsprechende Auftrag gelöscht. Hierzu ist Actioncode = '001' im IDOC und Belegnummer und Belegtyp muß gefüllt sein, damit der Beleg im System gefunden werden kann. Dies ist nur für Bestellungen (keine Einzelpositionen) möglich.

Als Belegnummer kann entweder BELNR oder EBELN aus dem Bestellkopf im Feld Orders_position-Belnr der Schnittstette übergeben werden.

Bestellkopie

Analog Bestellung aber die Bestellung löst keine Nachrichtenfindung aus => Ist nur eine Bestellkopie, um in der Statistik Streckenbestellungen der Filialen frühzeitig zu erkennen.

Konditionsübergabe

Es können bei den Belegtypen: BANF, Bestellung und Kundenauftrag sowie deren Sonderfällen Konditionen ab Release 4.0A (Kundenauftrag) bzw. 4.0B übermittelt werden

Hierzu dienen die beiden Übergabetabellen:

  • HEAD_CONDITIONS
  • ITEM_CONDITIONS

jeweils Auftragspositions- bzw. -Kopfbezogen Konditionen enthalten:

  • Kundenauftrag:
4 Konditonen pro Kopf und 4 pro Position sind erlaubt
  • Banf:
Es kann nur ein Preis pro Position (-kobtr) und Preiseinheit/Basismengeneinheit (-uprbs) übergeben werden. Währung wird aus Werk gezogen.
  • Bestellung:
Es kann nur ein Netto-EK-Preis pro Position übergeben werden. Hierzu sind in Item_conditions auftragposition + Nr = 1 sowie (BSP)
- Nettopreis betrag = ITEM_CONDITIONS-kond-kobtr 1,53 (DEM)
- Preiseinheit = ITEM_CONDITIONS-kond-uprbs (optional) 3
- Maßeinheit = ITEM_CONDITIONS-kond-meaun (optional) zu füllen.ST

Lieferungsdatenermittlung

Anhand des Materialidentifikators wird die Materialnr ermittelt. Mengeneinheit wird falls nicht übermittelt anhand internem Schnittstellenprofil aus MARC- bzw. Mara ermittelt. Menge und Mengeneinheit werden logistisch optimiert.

Die Empfangsstelle wird mittels der Abteilung aus Materialklasse + Werk ermittelt.

Die Bezugsquelle wird mit der Bezugsquellenfindung ermittelt.

Mit der Versandstellenfindung wird die Versandstelle, Route, etc. ermittelt, dazu werden SD-Keydaten aus dem Lieferwerk ermittelt.

Der Lagerort wird in der Lieferungserzeugung ermittelt.

Lieferdatum, falls nicht übermittelt wird aus Planlieferzeit ermittelt.

Zusätzlich zur Unterstützung eines eindeutigen Fehlerprotokolles wird eines Sammelgangnummer ermittelt.

Bestellung/BANF

Analog Lieferungsdatenermittlung (s.o.) außer Empfangsstellen- und Versandstellenfindung. Zusätzlich werden Belegart, EKORG und EKGRP, Positionstyp und Lagerort ermittelt.
Realisiert in Release 3.0:
- Lieferung inklusiv Batchinput im Fehlerfall
- Positionen zusammenfassen
- Runden
- Bestellweiterleitung Regel A:( check Verfügbarkeitsprüfung )
- Bestellweiterleitung Regel B:( check MVKE-LFMAX )
- Verbesserungen an den WF + an der Simulation ( Ergebnisse usability
) - WF Rollenfindung
- Abschalten Rahmenvertragsuche in BZQF (Performance)
- Findung Rack-Jobber-Artikel
- Leergutauflösung bei Lieferung
- Kundenauftrag ( einfache Form + Übermittlung von 4 Kopf- und 4 Positionskoditionen)
- detailierte Belgtypen Steuerung zentralseitig
- Bestellung löschen (ORDCHG ... )
- Ad Hoc Lösung Bestellbstätigung sofort (nur Änderungen oder alles)
- mittels ORDRSP
mittels WGSREQ
- Prüfung auf Doppelbestellung
- Belegfluss
- Bestellbestätigung (ORDRSP + WGSREQ)
- Bestellkopie
- user exit auf eingescannte Daten
z.b.
- mitgelieferte Bezugsquelle nochmal ändern
- fehlerhafte Fremdsystemdaten prüfen und umschiessen
- Belegtyp umschiessen

Weiterführende Informationen

  • Online Doku
  • Geschäftsprozeßmodelle:
  • Filialauftrag

  • Filialauftragsbearbeitung

  • Bezugsquellenfindung

  • Bestelloptimierung
  • Konzepte Release 1.1 und 1.2

Schnittstellendoku IDOC Transaktion we64

Schnittstellendoku: Welche IDOC-Inhalte können/müssen gefüllt sein, um

Zielbelegtyp x zu erzeugen siehe Customizing

"Steuerung Filialauftrag" ->Zusatzhinweise in Doku

With 4.5A it is possible to define a goods receiver "WE" partner as the customer for sales order.

Also it is possible to send a vendor subrange on header level to the PO!(partner "LTS" on header level)





Parameter

CALL_FROM
E_BELEG_NR
E_BELEG_POS_NR
FAULTS_FOUND
FAULTS_FOUND_TEXT
ITEM_DOCU_LOG_ON
I_PR_REQUESTOR
NO_WF
ORDER_POSITIONS
SORT_STEP_2
STEP
STORNO_BELEG

Ausnahmen

APPL_ERRORS_EXIST
ERROR_IN_APPLICATION
NO_DOCUMENT_WRITTEN
NO_EXTERNAL_VENDOR_GIVEN
NO_ORDER_POSITIONS
NO_UNIQUE_SOURCE_OF_SUPPLY

Funktionsgruppe

WOSX

General Material Data   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 15287 Date: 20240523 Time: 103609     sap01-206 ( 160 ms )