User exits in delivery processing SAP Note Number 1314 Print SSCRHelp DEENJA Display Versions 56781012 Note Language Download Text Header Data Release Correction Instructions Support Packages >> Symptom You are not sure which user exitsexistin delivery processing and how the deliver y data in the existing exits can be changed so that it conforms with the standar d. Other terms Userexit,MV50AFZ1, VL01, VL02, VL01N, VL01NO, VL02N, VL04, VL10, SAPMV50A, outbo und delivery, inbound delivery, customer enhancement Reason and Prerequisites This is due to an inadequate documentation. Solution Up to now in delivery processing you have been provided with user exits in the f orm of Includes, which are no longer changed by SAP throughupgrades or Support P ackage imports. The Includes contain empty FORM routines, which are called from within different points in delivery processing. You can fill the FORM routines with your own source code to process additional own data or to change delivery d ata. This note provides an overview of the call and the function of the individualuse r exits. Bear in mind that only general recommendations for the correct implemen tation of the user exits can be given here and that SAP cannot assume any respon sibility for the effects of the implementation. If you need support, contact an experienced consultant or contact the SAP Remote Consulting Service. Carry out thorough tests of any of your own developments in user exitsbefore imp lementing them in your production system. Also check whether your own developmen ts have incorrect effects on less obvious functions in the delivery such as the update of the statistics and change documents or the structure of the billing du e list (table VKDFS), the shipment planning index (table VTRDI) and the delivery due index (table VEPVG). Even if the data of the delivery which is written to t he database seems to be correct, inconsistent internal tables can result in erro rs in the update of the mentioned worklists. Only use local structures for the selection result for database accessesin the u ser exits. The use of the global structures defined in the delivery processing w ith TABLES can result in errors that are far-reaching and that are difficult to understand. General information on the internal tables of delivery processing The most important data of the delivery is managed in coupled internaltables: Th e internal table whose name starts with an X contains the current data, includin g the last changes made by the user. Generally the table with Y as the first let ter of the name contains the database status before the change. It is only signi ficant in the change mode of the delivery. In general, the change indicator (UPDKZ)of the X or Y table states whether the r Similar to the item statuses. In this case. Generall y the document flow table also contains data from the preceding documents. The item status of the individual delivery items is stored in internaltable XVBU P. The partners are stored in tables XVBPA and YVBPA.ecord is to be inserted (UPDKZ = 'I'). The following list is an overview on the most important internal tables and stru ctures of the delivery: LIKP and XLIKP are the header lines of the current delivery. The ch ange indicator (XLIPS-UPDKZ) states whether the item is to be inserted. changeor display? FieldT180-TRTYP has value 'H' in change mode.indicator V50AGL-W ARENAUSGANG is set. indicator V50AGL-WARENAUSG_ST .for example when creating batch split items. The internal table XLIPS contains the current statusof the deliveryitems. The corresponding internal table XLIKP is only reliably filled during collective pr ocessing. Pick order verificationor change of delivery in the dialog?</> Indicator KOMMIRUECKMELDUNGisset if a delivery is changed by a pick order verifi cation from Warehouse Management or through the import of an IDoc. In the case of a cancellation. tables XVBUK and YVBUK contain the header status i nformation. Dialog or collective processing? Indicator V50AGL-SAMMELGANG (as of Release 4. The table also contains a change indicator in accordance with the above-menti oned logic. Hence. updated ('U') or deleted ('D') in the dat abase. only structure LIKP contains the current status up to the start of saving. changed or deleted (see above).1I) has characteristic 'X' in collective processing. it should suppress the output of error messages in the dialog. changed ('U') or deleted ('D'). whic h represents the database status of the respective items. You can use the following indicators to determine the pro cessing status of the delivery: Create. table YLIKP is also filled in this case. value 'V' when changing and charac teristic 'A' in display mode. As of Release 4.6. Items thatwere deletedor changed in change mode also appear in table YLIPS. Remark: At times this indicator can also be set in dialog processing. The change indicator is manag ed like the status tables (no change indicator 'D' in XVBPA). Goods movement posting active? If the goods issue posting or goods receipt posting is active. Indicator XLIKP_U PDKZ is filled with 'U' when the header is changed.0) or KZ_SAMMELGANG (up to Release3 . The change indicator is SPACE if no changes were made. change indicator 'D' does not occur in XVBUP. however. When saving. You can recognize items to be deleted by change indicator YVBUP-UPDKZ = 'D' .Bear inmind that the header and item status tables can also contain the stat us information of the supplied preceding documents! The document flow for the delivery is stored in tables XVBFA and YVBFA. indicator XLIKP-UPDKZ states for each individual table entrywhether the respective header is to be inserted (UPKDZ = 'I'). entries to be deleted are always removed directly from the table. The change indicator is used in accordance with the same logic as fo r XVBUP and YVBUP so that change indicator 'D' does not occur in table XVBUK eit her. Determination of the processing status of the delivery Often it is necessary to distinguish between the different processingstatuses of the delivery because the exit is processed both during the creation of deliveri es and during changes. Structure YLIKPcontainsthe database status of the delivery header in change mode . The original status of the item status data is stored in change mode in table YV BUP. In dialogprocessing . In Release 3. In the new delivery dialog when changing between 'Display' and 'Change' and when reading a new document using function 'Other outbound delivery' or 'Other inbou nd delivery'. except for Transaction VL01NO). collective processing is executed for generating deliveries as a background job. Call The routine is called from within the standard routine BELEG_DATEN_INIT (SAPMV50 A). the active goods issue posting can be recognized by the function code: In this case field FCODE has value 'WABU'. Synchronous or asynchronous update? Indicator V50AGL-SYNCHRON (Release 3. VL03). As of Release 4. Is the delivery deleted completely? Ifadelivery document is deleted completely. field YLIKP_UPDKZ is set to 'D'. both indicators are only available as of Release 4 . Basically the data initialization is called on the following occasions: After deliveries have been saved in the dialog (not in the new delivery dialog. You can find more information on this topic in Note 209846.6:In collectiveprocessing for the creation of deliveries afte r the processing of a packet for supplied preceding documents. FORM routine USEREXIT_REFRESH_DOCUMENT (Include MV50AFZ1) Purpose FORM routineUSEREXIT_REFRESH_DOCUMENTis used for the initialization of your own data areas before the processing of a new delivery document. If the indicator is not set.ORNO can be queried. In this case indicator T180-TRTYP has value 'V'.6: Incollectiveprocessing for the creation of deliveries before the processing of a new packet for supplied preceding documents. the access to delivery data results in undef . Is the subsequent deliverysplit active? (only relevant in Release 4. VL02. Prior to Release 4. The internal tables of delive ry processing can contain several deliveries (as in collective processing). When starting the transaction in theolddeliverytransactions (VL01. Inthe dialog before the return to the initial screen with functions 'Back' or 'C ancel' (not in the new delivery dialog). However.0. T18 0-TRTYP has characteristic 'V' in this case. Field SY-TCODE is al so no longer filled with the expected value if deliveries are generated in parallel processing within Transaction VL10. Bear in mind that the query for the transaction code (SY-TCODE) indialog process ing no longer works reliably in Release 4. Data access During the document initialization.6) Indicator V50AGL-MULT is set if deliveries are saved that weresubsequently split .1I: KZ_SYNCHRON) is set when thedelivery is to be updated synchronously.6 since it is possible to change betwe en display mode and change mode within delivery processing. In the new delivery dialog the initialization is not called for performance reas ons. The update function modules must then be called with the addi tion IN UPDATE TASK.1. the delivery is updat ed asynchronously. since all the delivery data has already been deleted logically. Output of messages The output of error messages during the document initialization does not make se nse. . Data access You can access the delivery data that has already been deleted logically within the FORM routine: Structure LIKP contains the delivery header to be deleted. In the internal table for the header status of delivery XVBUK thereis alsono ent ry anymore for the current delivery. The internal table for item status XVBUP no longercontains anyitems of the curre nt delivery. Theinternal table with partner data XVBPA is also empty. Immediately after FORM routine USEREXIT_DELET E_DOCUMENT is called. This results in runtime error DYNPRO_MSG_IN_HELP as of Release 4. the document backup is called for which the logically dele ted delivery is removed from the database. The database status of the partner data is in internal table YVBPA. The internal table YLIPS contains the database status of all delivery items in t his special case. including the last changes made by the user before the deletion. FORM routine USEREXIT_DELETE_DOCUMENT (Include MV50AFZ1) Purpose When a delivery is deleted. the database status of the item status can only be determined from internal table YVBUP.ined results. The internaltables ofdelivery processing must not be manipulated in this exit un der any circumstances so as to avoid data inconsistencies. you can delete your own dependent data using this FO RM routine. Call The FORM routine is called from FORM routine BELEG_LOESCHEN (SAPMV50A)when the d ocument can be deleted completely. No messages of type E or W can be outp ut. The current status information (database st atus) can be taken from table YVBUK.0. an error message of type A should be output. If the deletion of the delivery has to be prevented by the user for certain rea sons. All items have change indicator 'D'. Output of messages The output of error messages and user dialogs is only possiblewith restrictions in FORM routine USEREXIT_DELETE_DOCUMENT. Other notes The deletion of the delivery can no longer be prevented at this point byreturnin g to the dialog. The internal table XLIPS contains the current status of the items to be deleted. FORM routine USEREXIT_MOVE_FIELD_TO_LIKP is always calledat the end of routine s LIKP_FUELLEN (SAPFV50K. Output of messages There are no restrictions placedonthe output of error messages and user dialogs in this exit. In these cases. If the difference regarding the batch input mode needs to be made more precise. creation of deliveries with predecessor reference) and LIKP_FUELLEN_OR (SAPFV50K. Exception: The routine is not execu ted when reading deliveries during the subsequent delivery split and when enhanc ing deliveries. the copy routine for tr ansferring the predecessor data is called once before and once after this exit. VL21. FORM routine USEREXIT_MOVE_FIELD_TO_LIKP (Include MV50AFZ1) Purpose The exit is intended to supply your own additional fields of header table LIKP w ith data. the output of a dialog box can result in a termination of t he processing because no batch input data is available for the dialog box. consider that the exit is also processed in the backgroun d: User interaction is not useful for the pick order verification fromWarehouse Man agement or when importing IDocs. creation of deliveries without predecessor reference ). consult the recommendations on changin g delivery data in the description of user exit USEREXIT_SAVE_DOCUEMENT_PREPARE. th e output of function module BDC_RUNNING can be used (read Note 416150 for this). . However. the delivery dialog may be called in batch input m ode.FORM routine USEREXIT_READ_DOCUMENT (Include MV50AFZ1) Purpose The exit is intended to make your own data available for processing in the deliv ery. You can recognize this processing case by the f act that indicator KOMMIRUECKMELDUNG is set. For this. The b atch input case can be recognized by the fact that indicator SY-BINPT is set. Call The routine is processed exactly once after the delivery document datais read in the change or display mode of the delivery. Call The FORM routine is processed exactly once during the creation of a new delivery . In the case of deliveries with predecessor reference. Data access Within the exit you have full access to all the data of the delivery thathas jus t been imported. For the goods issue posting via the delivery monitor (TransactionVL06G) or Trans actions VL19. In principle it is possible for you in this exit to already cha nge the imported delivery data. and VL23. When you create items with predecessor reference. you can access the header status of the del . Call The routine is processed exactly once per item during the creation of deliveryit ems. When importing data from these tables. messa ges of type I and E can be included in the delivery creation log via FORM routin e MESSAGE_HANDLING (main program SAPMV50A). CVBAP (order item). Other notes Bear in mind that changing data in structure LIKP affects the delivery split dur ing the creation of deliveries. make sure that the c urrent header lines of the tables are not changed! Use local structures instead. other items were al ready supplied in the same delivery.Data access Within the FORM routine you cannot yet access other data of the deliverysince th is data is not yet available at that time. No status information is ava ilable yet for the new items. since this can have negative effects on the data consistency and the correct functioning of the collective availability check. prior to the current item. you can access the data of the supplied order via internal ta bles CVBAK (order header). If. You are advised against using the exit for manipulating other deliverydata. CVBPA (order partner) and CVBEP ( delivery schedules). for instance for creating your own partners. If standard fields of structure LIKP are changed. determinationsand checks that have already been performed on these fields might have to be carried out once ag ain to avoid data inconsistencies. (If this routine is processed in cha nge mode. However. FORM routine USEREXIT_MOVE_FIELD_TO_LIPS is always called at the end of rou tines LIPS_FUELLEN (creation of items with predecessor reference) and LIPS_FUELL EN_OR (creation of items without predecessor reference and creation of additiona l items in the delivery such as batch split items or packaging items).However. the routines of the copy control are ca lled before and after this user exit. Data access Within the exit you have access to the corresponding delivery header data(struct ure LIKP) and partner data of the delivery (XVBPA). Output of messages The exit must not be used for the direct output of error messages. Therefore analyze the dependencies before you change standard fields in table LIKP in this exit. messages are not output directly but collected in the log). Messages o f type W are not written to the log. FORM routine USEREXIT_MOVE_FIELD_TO_LIPS (Include MV50AFZ1) Purpose The routine is intended to supply your own additional fields of table LIPS with data. when creating deliveries wit h order reference. Data from preceding documents should be transferred with preference via the copy control. Call The user exit is called during the creation of the item within routine LIPS_BEAR BEITEN (program SAPFV50P). Output of messages . Make sure that the current header lines of the internal tables are not changed. LIPS-LGMNG) are not yet filled during the run of the FORM routin e because batch split items are generated with quantity 0 and are only allocated a quantity in a second step. which. When you change standard fields of the item. In addition. the access is possible to thealreadydetermined order item da ta (LIPS). in change mode. XVBPA). In the routine only the batch of the delivery should be changed (fieldLIPS-CHARG ). transfers messages of type E or I to th e delivery processing log. It does not make sense to change other data of the delivery in thisexit. Note that when you create a batch split items. you should also set the XLIPS_LOESCHEN_MENGE_0 indicator in the routine to the value 'X'. Note that the item number for the new item is already only assigned for items wi thout predecessor reference during the call of the exit. Here yo u should only access other data of the delivery in read mode. Instead. you can access the corresponding header data of the deli very (XLIKP. Data access Within the routine. in accordance with your own criteria. note that checks and determinations with reference to these fields may have already been carried out and unchecked c hanges to these fields may result in data inconsistencies. If you do not want the itemtobecreatedbecause an error occurred.ivery via table XVBUK. The current header lines of the internal tables must not be changed. analyze an y possible dependencies before making any changes to standard fields. Therefore. Use loca l structures for the reading of data from internal tables instead. use FORM routine MESSAGE_HANDLING (main p rogram SAPMV50A). that is to be assigned to the deli very item. Output of messages The direct output of messages is not allowed in this exit because thiscan result in document inconsistencies. The status of the items which were generated in the same transaction or which already existed in the delivery can be read from table XVBU P. the fields for the deliveryquanti ty (LIPS-LFIMG. Define local struc tures to read data from you own internal delivery tables. FORM routine USEREXIT_BATCH_DETERMINATION (Include MV50AFZZ) Purpose Youcanuse the routine to determine the batch. only the document number has not yet been determined i n the creation case. the delivery is complete and consistent. Data access The data access corresponds to that of FORM routine USEREXIT_SAVE_DOCUMENT_PREPA RE (Include MV50AFZ1). the delivery is complete and consistent. only the document number ha s not yet been determined in the creation case and the final processing of the r equirements has not yet taken place. messa ges of type I and E can be included in the delivery creation log via FORM routin e MESSAGE_HANDLING (main program SAPMV50A). Call This exit is called from routineBELEG_SICHERN(SAPMV50A) before deliveries are sa ved in the dialog and during the creation of deliveries in collective processing . FORM routine USEREXIT_SAVE_DOC_BEFORE_PREP (Include MV50AFZ1) This routine is only available after the implementation of Note 751000. At the time of the call.The exit must not be used for the direct output of error messages. this user exit is. Since requirements processinghasnot yet occurred. changes to the delivery at this time must be made with particular care because no subsequentchecks can prevent p ossible data inconsistencies. Atthe time o f the call. Purpose This routine can be used for the final change of all delivery data. in particul ar. Data access . suitable for changes relevant for requirements when the delivery is saved. Therefore. FORM routine USEREXIT_SAVE_DOCUMENT_PREPARE (Include MV50AFZ1) Purpose This routine is the most powerful exit in delivery processing andcan be used for the final change of all delivery data. Therefore. Call This exit is called from routine BELEG_SICHERN (SAPMV50A) before deliveriesare s aved in the dialog and during the creation of deliveries in collective processin g. Messages o f type W are not written to the log.However. (If this routine is processed in cha nge mode. The call is executed before the final determination of the requirements and b efore the call of user exit USEREXIT_SAVE_DOCUMENT_PREPARE (Include MV50AFZ1). messages are not output directly but collected in the log). changes to the delivery at this time must be mad e with particular care because no subsequent checks can prevent possible data in consistencies. Since the delivery is about to be saved. Delivery data can not be changed here anymore since it has already been transferred to the update. check the exact conditions under which the source code can be processed usefully (for example. . If you want to change item data consistently. you might need to execute routine XVBUK_PFLEGEN (program SAPFV50K). FORM routine USEREXIT_SAVE_DOC_BEFORE _PREP (Include MV50AFZ1) from Note 751000 should be used. program SAPMV50A) immediately before the COMMIT WORK statement. If you carry outchangesrelevant for requirements. FORM routine USEREXIT_SAVE_DOCUMENT (Include MV50AFZ1) Purpose The routine is used to save yourowndatawhen saving deliveries. With this. Hencestandar d routines. you should consider thesource code example EXAMPLE 1 from the correction instruction. Remark: The source code examples described in the correction instructionare only supposed to illustrate the correct call of the standard FOR M routines and they do not have any business significance. Output of messages With the output of messages or userdialogs you must make sure that this exit can be processed both in the dialog and in the background.call FORMroutine XLIPS_LOESCHE N (program SAPFV50P) in the same way as source code example EXAMPLE 3 in the cor rection instructions. If implemented in a p roductive system. The current document status is to be found in the X tables andtheprevious d atabase status is to be found in the corresponding Y tables. The header lines of the internal tables may be changed in thisexit. In particular during the goods issue posting. Note that the requirements can be updated incorrectly if you delete the entire d ocument in this user exit. The requirements update is already completed when the routine is called. Call Itis called when the document is saved (routine BELEG_SICHERN.6) several deliveriesmay exist in the inter nal tables. which require a previous correct positioning of the work areas. Use a user-defined check in the incompletioncontrol i f you want to delete the entire document (see Note 158807). which character ize the processing status of the delivery. deleting items in the case of an active goods i ssue posting is not useful). The header status of the documents involvedhasalso alreadybeen determined. If you want to delete delivery items consistently. Therefore. to formulate the conditions under whi ch the source code is to be executed. the internal tabl es of the delivery including the change indicators are updated correctly. you should use user exit USEREXIT_SAVE_DOC_BE FORE_PREP for the deletion. Take into account t he following during the data access: Whenyou createdeliveries in collective processing or when you execute the subseq uent delivery split (as of Release 4. it is generally not sufficient for processing only to con sider the header lines LIKP or XLIKP. For s tatus update purposes. If it is not possibl e to use the incompletion control. all relevant delivery data can be acces sed. Use the above-mentioned indicators. no messages or user dialogs must be output under any circu mstances because this can result in incorrect material documents. can also be called for processing. Data access As in routine USEREXIT_SAVE_DOCUMENT_PREPARE. necessary to call update function mod ule with the addition IN UPDATE TASK. the document number of the deliver y is now also known. this should be done via functionmodules which can be updated. youcanaccess all the global data o f the delivery.1I: K Z_SYNCHRON) has been set. . Depending on the way indicator V50AGL-SYNCHRON (Release 3. If your own data is to be updated. carry out the update in synchronous or asynchronous mo de: V50AGL-SYNCHRON = 'X': Synchronous update V50AGL-SYNCHRON= ' ': Asynchronous update. Never use your own COMMIT WORK or ROLLBACK WORK statements! Output of messages The output of messages or user dialogs is generally not allowed since a COMMIT W ORK is sent implicitly here. When you create the delivery. In serious cases processing can be canceled with a message of type 'A'.