Ansicht
Dokumentation

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

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

General Material Data   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Der Funktionsbaustein wird von folgend Stellen aus aufgerufen:

  • aus der ALE-Wareneingangserfassung ohne Bestellbezug,
  • aus der Nachschubdisposition,
  • aus der Verarbeitung der Filialauftragspositionen per ALE-Eingang,
  • aus der Frischedispo
  • aus der 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 Schnittstellprofile wird pro Kunde bzw. Kunde/Warengruppe ermittelt.

Der Defaulttyp 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 muß 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

  • STEP = ' ' - "einstufig"
  • STEP = '1' - "zweistufig; 1. Schritt"
  • STEP = '2' - "zweistufig; 2. Schritt" wird derzeit nicht unterstuetzt !

arbeiten.

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

en 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 im R/3 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 zB: 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 Belge 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.
  • 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 Rackjobberartikel
  • - 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

Bestellpositionsänderung

------------------------

  • Mittels Filialauftrag können bestehende Bestellpositionen storniert oder geändert werden. Momentan können nur Lieferdatum und Menge geändert werden.
  • Voraussetzungen sind die Übergabe von Bestellbelegnummer und Belegtyp 3 (= Bestellung) und die Artikelnummer (EAN, Lieferantenartikelnummer). Wird keine zu ändernde Position angegeben, so werden alle Positionen im Bestellbeleg mit der angegebenen Artikelnummer geändert.
  • Nicht zu ändernde Felder in der Bestellung dürfen im Filialauftrag auch nicht gesetzt werden.
  • Der Typ der Änderung (AENDERN / STORNO) wird im Feld wvfb-ematn (ggfs. mit der Positionsnummer) abgelegt. Mischfälle von AENDERN und STORNO in einem Filialauftrag sind nicht zulässig!

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.0C 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
CREATE_ONLY_COMPLETE_DOC
DOCUMENTS_CREATED
E_BELEG_NR
E_BELEG_POS_NR
FAULTS_FOUND
HEAD_CONDITIONS
HEAD_PARTNERS
ITEM_CONDITIONS
ITEM_DOCU_LOG_ON
ITEM_PARTNERS
I_ALL_POSTED_ITEMS
I_PR_REQUESTOR
I_SUBMI_NUMBER
LTS_SPLIT
NO_ROUNDING
NO_WF
ORDER_POSITIONS
SHOW_STATUS_MESSAGE
SORT_STEP_2
STEP
STORNO_BELEG
TEKPO_DATA_FOR_PO

Ausnahmen

APPL_ERRORS_EXIST
ERROR_IN_APPLICATION
NO_DOCUMENT_WRITTEN
NO_EXTERNAL_VENDOR_GIVEN
NO_ORDER_POSITIONS
NO_UNIQUE_SOURCE_OF_SUPPLY

Funktionsgruppe

WVFB

ROGBILLS - Synchronize billing plans   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 19143 Date: 20240523 Time: 073113     sap01-206 ( 154 ms )