Skip to end of metadata
Go to start of metadata

If the customizing of the third party process is correct it is needed to debug to get to the reason why the problem still occurs. In this case it might be helpful to know the affected source code as well as the interfaces to other components. There are 5 relevant cases:

Case 1: Creation and Change of Purchase Requisition
 -       Central forms (name of includes : FV45EFMA_<form name> ):
-       BESCHAFFUNG_ANLEGEN (creation of PReq item)
-       BESCHAFFUNG_AENDERN (change of PReq item)
-       BESCHAFFUNG_LOESCHEN (deletion of PReq item)
-       Often called from VBEP_BEARBEITEN_BESCHAFFUNG
include FV45EFMA_VBEP_BEARBEITEN_BESCH)
 Code logic for creation or change
-       FM SD_ORDER_SUBSEQUENT_ALLOWED
Check whether creation or change of PReq item is allowed
-       FM ME_READ_REQUISITION_EXT
-       Only in Change-case
-       Reads the current PReq item data from MM
-       This is the interface to MM (FM already belongs to MM. If anything goes wrong in there message belongs to MM-PUR-GF-TP).
-       Perform BESCHAFFUNG_FUELLEN
Fill communication structures EBAN and EBKN (uses PARM)
-       FM ME_REQUISITION_EXT
-       MM gets EBAN and EBKN from SD (only some fields) and maintains the structures.
-       Important import value DA_LFDAT. This is the delivery date scheduled from MM which will be used to derive VBEP-MBDAT
-       This is the interface to MM (FM already belongs to MM. If anything goes wrong in there message belongs to MM-PUR-GF-TP)
-       Perform ERGEBNIS_AN_VERFUEGBARKEIT
-       ATP gets this value for creating the confirmed schedule line.
-       Important structure MVERF_DB
-       If anything goes wrong here message belongs to SD-BF-AC.
 Code logic for creation or change (simplification) when saving the sales order:
-       Perform BESCHAFFUNG_SICHERN
(include FV45EFMA_BESCHAFFUNG_SICHERN)
-       FM ME_CREATE_REQUISITION_EXT
-       MM gets all information (in terms of EBAN and EBKN) and registers for update.
-       This is the interface to MM (FM already belongs to MM. If anything goes wrong in there forward the message belongs to MM-PUR-GF-TP)
 Case 2: Update of Sales Order from Purchase Order
 When the purchase order (PO) is created and every time it is changed the corresponding sales order item(s) is/are updated in terms of confirmed date and quantity.
-       Central function module (and interface to MM):
SD_PURCHASE_CHANGE_ORDER
-       This FM is called from MM form BUCHEN (include MM06EF0B_BUCHEN).
-       Dates and quantities are communicated via internal table XVBEPEK which is filled in (MM-)form SD_AEND_VORBEREITEN (include MM06EF0S_SD_AEND_VORBEREITEN).
-       This FM can update several sales orders. The loop over the sales orders is performed in the FM.
-       For every sales order FM SD_SALES_DOCUMENT_READ is called once and at the end of the process the data are changed by call of FM SD_SALES_DOCUMENT_SAVE.
-       For every sales order to be updated form EBAN_VBEP_UPDATE (include FV45EFMA_EBAN_VBEP_UPDATE) is called.
 -       Logic of form EBAN_VBEP_UPDATE:
-       Loops over entries of XVBEPEK which belong to one sales order.
-       Each line of XVBEPEK represents the update of one schedule line.
-       Form ERGEBNIS_UEBERNEHMEN (include FV45VF0E_ERGEBNIS_UEBERNEHMEN) is called to fill MVERF_DB. If something goes wrong in here message belongs to SD-BF-AC
-       Changes for all schedule lines of one sales order item are written to XVBAP, XVBEP etc. by call of form VBAP_BEARBEITEN_ENDE (include FV45PFAP_VBAP_BEARBEITEN_ENDE).
-       Don't miss to check userexit USEREXIT_CHANGE_SALES_ORDER (include FV45EFZ1).
-       If anything goes wrong in the MM area message belongs to
MM-PUR-PO or MM-PUR-GF-TP.
 Case 3: Status Update of SO from Invoice Receipt
 When the invoice receipt (IR, transaction MIRO) or invoice verification is created or changed the status of the corresponding sales order item(s) is/are adjusted.
-       Central function module (and interface to MM):
SD_PURCHASE_CHG_ORDER_STATUS
-       This FM is called from MM form FAKTURAINDEX (include LMRMPFF0).
-       Invoice verification quantities are communicated via internal table VBAPCOM1 which is filled in (MM-)form FAKTURAINDEX (include LMRMPFF0).
-       This FM can update several sales orders.
-       For every sales order FM SD_SALES_DOCUMENT_READ is called once and at the end of the process the data are changed by call of FM SD_SALES_DOCUMENT_SAVE.
-       Loops over VBAPCOM1 and calls form XVBUP_AKTUALISIEREN  (include FV45PFUP_XVBUP_AKTUALISIEREN) once for every sales order item.
 -       Logic of form XVBUP_AKTUALISIEREN:
-       Reads the cumulated quantity in table XVBAPF for the SO item.
-       Adds or subtracts current invoice receipt quantity to XVBAPF-REMNG according to Debit/Credit Indicator VBAPKOM1-SHKZG.
-       Updates table XVBAPF.
-       Calls form XVBUP_PFLEGEN_AKTUELL (include ERGEBNIS_UEBERNEHMEN (include FV45PFUP_XVBUP_PFLEGEN_AKTUEL1) which in turn calls FM RV_XVBUP_MAINTAIN to update the sales order status.
-       If anything goes wrong in the MM area message belongs to
MM-IV-LIV.
 Case 4: Status Update of SO from Goods Receipt:
 Only in Individual Purchase Order scenario:
When the goods receipt (GR, transaction MIGO) is created or changed the status of the corresponding sales order item(s) is/are NOT ADJUSTED (please keep this in mind!).
-       There is a modification Note 149421
„Individual purchase order: No SD update by goods receipt"
available, but if the customer reports problem with this scenario it is a consulting issue and no Prio-1.
-       There is a second modification Note 650247
„Delivery group date not brought fwd for 3rd-party/indiv PO"
which does not necessarily need Note 149421 as a prerequisite but very often comes together with it.
 Case 5: ALE process (PO automatic)
 There is an option to create or change the purchase order automatically when saving the sales order. This is realized via a workflow / event process and needs special expertise to debug.
-       If you are encountering such a customer message do not try to debug.
-       Tell the customer as a work-around to switch off the ‚PO automatic flag' in customizing:
-       VOV7 with respective item category and remove flag „Create PO automatic" (TVAP-ALEKZ)
-       Create purchase orders manually using ME21N or ME59N.
 

  • No labels