User exit on VL04
Hello, I hope somebody can help me, I was looking for a user-exit in transaction VL04, but at this time i didn't find it, any of you knows if exist ?
hello
i hope i help you
Additional key words
User exit, MV50AFZ1, VL01, VL02, VL01N, VL01NO, VL02N, VL04, VL10, SAPMV50A, outbound delivery, inbound delivery, customer enhancement
Cause and preconditions
This is due to an inadequate documentation.
Solution
Up to now in delivery processing you have been provided with user exits in the form of Includes, which are not changed anymore by SAP through upgrades or Support Package 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 data.
This note provides an overview of the call and the function of the individual user exits.Bear in mind that only general recommendations for the correct implementation of the user exits can be given here and that SAP cannot assume any responsibility 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 exits before implementing them in your production system.Also check whether your own developments 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 due list (table VKDFS), the transportation planning index (table VTRDI) and the delivery due index (table VEPVG).Even if the data of the delivery which is written to the database is apparently correct, inconsistent internal tables can result in errors in the update of the said worklists.
Only use local structures for the selection result for database accesses in the user exits.The use of the global structures defined in the delivery-processing with 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 internal tables:The internal table whose name starts with an X contains the current data, including the last changes made by the user.Generally the table with Y as the first letter of the name contains the database status before the change.It is only significant in the change mode of the delivery.
In general, the change indicator (UPDKZ) of the X or Y table states whether the record is to be inserted (UPDKZ = 'I'), updated ('U') or deleted ('D') in the database.
The following list is an overview of the most important internal tables and structures of the delivery:
LIKP and XLIKP are the header lines of the current delivery.In dialog processing, only structure LIKP contains the current status up to the start of saving.The corresponding internal table XLIKP is only reliably filled during collective processing;
When saving, indicator XLIKP-UPDKZ states for each individual table entry whether the respective header is to be inserted (UPKDZ = 'I'), changed ('U') or deleted ('D'). The change indicator is SPACE if no changes were made. Indicator XLIKP_UPDKZ is filled with 'U' when the header is changed.
Structure YLIKP contains the database status of the delivery header in change mode. As of Release 4.6, table YLIKP is also filled in this case.
The internal table XLIPS contains the current status of the delivery items.The change indicator (XLIPS-UPDKZ) states whether the item is to be inserted, changed or deleted (see above).
Items that were deleted or changed in change mode also appear in table YLIPS, which represents the database status of the respective items.
The item status of the individual delivery items is stored in the internal table XVBUP.The table also contains a change indicator in accordance with the above-mentioned logic, however, entries to be deleted are always removed directly from the table. Hence, the change indicator 'D' does not occur in XVBUP.
The original status of the item status data is stored in change mode in table YVBUP.You can recognize items to be deleted by the change indicator YVBUP-UPDKZ = 'D'.
Similar to the item statuses, tables XVBUK and YVBUK contain the header status information.The change indicator is used in accordance with the same logic as for XVBUP and YVBUP so that the change indicator 'D' does not occur in table XVBUK either.Bear in mind that the header and item status tables can also contain the status information of the supplied preceding documents!
The document flow for the delivery is stored in tables XVBFA and YVBFA;generally the document flow table also contains data from the preceding documents.
The partners are stored in tables XVBPA and YVBPA.The change indicator is managed like the status tables (no change indicator 'D' in XVBPA).
Determination of the processing status of the delivery
Often it is necessary to distinguish between the different processing statuses of the delivery because the exit is processed both during the creation of deliveries and during changes.You can use the following indicators to determine the processing status of the delivery:
Create, change or display?
Field T180-TRTYP has the value 'H' in the change mode, value 'V' when changing and the characteristic 'A' in the display mode.
Dialog or collective processing?
Indicator V50AGL-SAMMELGANG (as of Release 4.0) or KZ_SAMMELGANG (up to Release 3.1I) has the characteristic 'X' in collective processing;
remark:at times this indicator can also be set in dialog processing, for example when creating batch split items.In this case, it has the task of suppressing the output of error messages in the dialog.
Pick order verification or change of delivery in the dialog?
Indicator KOMMIRUECKMELDUNG is set if a delivery is changed by a pick order verification from Warehouse Management or through the importation of an IDoc.
Goods movement posting active?
If the goods issue posting or goods receipt posting is active, indicator V50AGL-WARENAUSGANG is set.In the case of a cancellation, indicator V50AGL-WARENAUSG_STORNO can be queried. However, both indicators are only available as of Release 4.0.
In Release 3.1, the active goods issue posting can be recognized by the function code: In this case field FCODE has the value 'WABU'.
Is the delivery deleted completely?
If a delivery document is deleted completely, field YLIKP_UPDKZ is set to 'D', T180-TRTYP has the characteristic 'V' in this case.
Is the subsequent delivery split active?(only relevant in Release 4.6)
Indicator V50AGL-MULT is set if deliveries are saved that were subsequently split.In this case indicator T180-TRTYP has the value 'V'. The internal tables of delivery processing can contain several deliveries (as in collective processing).
Synchronous or asynchronous update?
Indicator V50AGL-SYNCHRON (Release 3.1I:KZ_SYNCHRON) is set when the delivery is to be updated synchronously.If the indicator is not set, the delivery is updated asynchronously.The update function modules must then be called with the addition IN UPDATE TASK.
Bear in mind that the query for the transaction code (SY-TCODE) in dialog processing no longer works reliably in Release 4.6 since it is possible to change between display mode and change mode within delivery processing.Field SY-TCODE is also no longer filled with the expected value if
deliveries are generated in parallel processing within Transaction VL10,
collective processing is executed for generating deliveries as a background job.
More information on this problem can be found in Note 209846.
FORM routine USEREXIT_REFRESH_DOCUMENT (Include MV50AFZ1)
Purpose
FORM routine USEREXIT_REFRESH_DOCUMENT is used for the initialization of your own data areas before the processing of a new delivery document.
Call
The routine is called from within the standard routine BELEG_DATEN_INIT (SAPMV50A).
Basically the data initialization is called on the following occasions:
After deliveries have been saved in the dialog (not in the new delivery dialog, except for transaction VL01NO).
In the dialog before the return to the initial screen with the functions 'Back' or 'Cancel' (not in the new delivery dialog).
In the new delivery dialog when changing between 'Display' and 'Change' and when reading a new document using function 'Other outbound delivery' or 'Other inbound delivery'.
As of Release 4.6: In collective processing for the creation of deliveries before the processing of a new packet for supplied preceding documents.
Before Release 4.6: In collective processing for the creation of deliveries after the processing of a packet for supplied preceding documents.
When starting the transaction in the old delivery transactions (VL01, VL02, VL03). In the new delivery dialog. the initialization is not called for reasons of performance.
Data access
During the document initialization, the access to delivery data results in undefined results.
Output of messages
The output of error messages during the document initialization is not useful.
FORM routine USEREXIT_DELETE_DOCUMENT (Include MV50AFZ1)
Purpose
When a delivery is deleted, you can delete your own dependent data using this FORM routine.
Call
The FORM routine is called from FORM routine BELEG_LOESCHEN (SAPMV50A) when the document can be deleted completely.Immediately after FORM routine USEREXIT_DELETE_DOCUMENT is called, the document backup is called for which the logically deleted delivery is removed from the database.
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.
The internal table XLIPS contains the current status of the items to be deleted, including the last changes made by the user before the deletion.All items have the change indicator 'D'.
The internal table YLIPS contains the database status of all delivery items in this special case.
The internal table for the item status XVBUP does not contain any items of the current delivery anymore, the database status of the item status can only be determined from the internal table YVBUP.
In the internal table for the header status of the delivery XVBUK there is also no entry anymore for the current delivery.The current status information (database status) can be taken from table YVBUK.
The internal table with the partner data XVBPA is also empty.The database status of the partner data is in the internal table YVBPA.
The internal tables of delivery processing must not be manipulated in this exit under any circumstances so as to avoid data inconsistencies.
Output of messages
The output of error messages and user dialogs is only possible with restrictions in FORM routine USEREXIT_DELETE_DOCUMENT.No messages of type E or W can be output.This results in runtime error DYNPRO_MSG_IN_HELP as of Release 4.0.
Other notes
The deletion of the delivery can no longer be prevented at this point by returning to the dialog, since all the delivery data has already been deleted logically.If the deletion of the delivery has to be prevented by the user for certain reasons, an error message of the type A should be output.
FORM routine USEREXIT_READ_DOCUMENT (Include MV50AFZ1)
Purpose
The exit is intended to make your own data available for processing in the delivery.
Call
The routine is processed exactly once after the delivery document data is read in the change or display mode of the delivery. Exception:The routine is not executed when reading deliveries during the subsequent delivery split and when enhancing deliveries.
Data access
Within the exit you have full access to all the data of the delivery that has just been imported.In principle it is possible for you in this exit to already change the imported delivery data.For this, consult the recommendations on changing delivery data in the description of user exit USEREXIT_SAVE_DOCUEMENT_PREPARE.
Output of messages
There are no restrictions placed on the output of error messages and user dialogs in this exit.However, consider that the exit is also processed in the background:
User interaction is not useful for the pick order verification from Warehouse Management or when importing IDocs.You can recognize this processing case by the fact that the indicator KOMMIRUECKMELDUNG is set.
For the goods issue posting via the delivery monitor (Transaction VL06G) or Transactions VL19, VL21 and VL23, the delivery dialog may be called in batch input mode.In these cases, the output of a dialog box can result in a termination of the processing because no batch input data is available for the dialog box.The batch input case can be recognized by the fact that the indicator SY-BINPT is set.If the difference regarding the batch input mode needs to be made more precise, the output of function module BDC_RUNNING can be used (read Note 416150 for this).
FORM routine USEREXIT_MOVE_FIELD_TO_LIKP (Include MV50AFZ1)
Purpose
The exit is intended to supply your own additional fields of the header table LIKP with data.
Call
The FORM routine is processed exactly once during the creation of a new delivery.FORM routine USEREXIT_MOVE_FIELD_TO_LIKP is always called at the end of routines LIKP_FUELLEN (SAPFV50K;creation of deliveries with predecessor reference) and LIKP_FUELLEN_OR (SAPFV50K; creation of deliveries without predecessor reference).In the case of deliveries with predecessor reference, the copy routine for transferring the predecessor data is called once before and once after this exit.
Data access
Within the FORM routine you cannot yet access other data of the delivery since this data is not yet available at that time.However, when creating deliveries with order reference, you can access the data of the supplied order via the internal tables CVBAK (order header), CVBAP (order item), CVBPA (order partner) and CVBEP (delivery schedules).When importing data from these tables, make sure that the current header lines of the tables are not changed!Use local structures instead.
If standard fields of structure LIKP are changed, determinations and checks that have already been performed on these fields might have to be carried out once again to avoid data inconsistencies.Therefore analyze the dependencies before you change standard fields in table LIKP in this exit.
Data from preceding documents should be transferred with preference via the copy control.
You are advised against using the exit for manipulating other delivery data, for instance for creating your own partners, since this can have negative effects on the data consistency and the correct functioning of the collective availability check.
Output of messages
The exit must not be used for the direct output of error messages.However, messages of type I and E can be included in the delivery creation log via FORM routine MESSAGE_HANDLING (main program SAPMV50A).(If this routine is processed in the change mode, messages are not output directly but collected in the log). Messages of type W are not written to the log.
Other notes
Bear in mind that changing data in structure LIKP affects the delivery split during the creation of deliveries.
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.
Call
The routine is processed exactly once per item during the creation of delivery items.FORM routine USEREXIT_MOVE_FIELD_TO_LIPS is always called at the end of routines LIPS_FUELLEN (creation of items with predecessor reference) and LIPS_FUELLEN_OR (creation of items without predecessor reference and creation of additional items in the delivery such as batch split items or packaging items).When you create items with predecessor reference, the routines of the copy control are called before and after this user exit.
Data access
Within the exit you have access to the corresponding delivery header data (structure LIKP) and partner data of the delivery (XVBPA).No status information is available yet for the new items.If, prior to the current item, other items were already supplied in the same delivery, you can access the header status of the delivery via table XVBUK.The status of the items which were generated in the same transaction or which already existed in the delivery can be read from table XVBUP.
When you change standard fields of the item, note that checks and determinations with reference to these fields may have already been carried out and unchecked changes to these fields may result in data inconsistencies.Therefore, analyze any possible dependencies before making any changes to standard fields.
Note that the item number for the new item is already only assigned for items without predecessor reference during the call of the exit.
It is not useful to change other data of the delivery in this exit.Here you should only access other data of the delivery in read mode.Make sure that the current header lines of the internal tables are not changed.Define local structures to read data from you own internal delivery tables.
Note that when you create a batch split items, the fields for the delivery quantity (LIPS-LFIMG, LIPS-LGMNG) are not yet filled during the run of the FORM routine because batch split items are generated with the quantity 0 and are only allocated a quantity in a second step.
Output of messages
The direct output of messages is not allowed in this exit because this can result in document inconsistencies.Instead, use FORM routine MESSAGE_HANDLING (main program SAPMV50A), which, in the change mode, transfers messages of type E or I to the delivery processing log.
FORM routine USEREXIT_BATCH_DETERMINATION (Include MV50AFZZ)
Purpose
You can use the routine to determine the batch, that is to be assigned to the delivery item, in accordance with your own criteria.
Call
The user exit is called during the creation of the item within routine LIPS_BEARBEITEN (program SAPFV50P).
Data access
Within the routine, the access is possible to the already determined order item data (LIPS).In addition, you can access the corresponding header data of the delivery (XLIKP, XVBPA).
In the routine only the batch of the delivery should be changed (field LIPS-CHARG).The current header lines of the internal tables must not be changed.Use local structures for the reading of data from internal tables instead.
Output of messages
The exit must not be used for the direct output of error messages.However, messages of type I and E can be included in the delivery creation log via FORM routine MESSAGE_HANDLING (main program SAPMV50A).(If this routine is processed in change mode, messages are not output directly but collected in the log). Messages of type W are not written to the log.
FORM routine USEREXIT_SAVE_DOCUMENT_PREPARE (Include MV50AFZ1)
Purpose
This routine is the most powerful exit in delivery processing and can be used for the final change of all delivery data.At the time of the call, the delivery is complete and consistent, only the document number has not yet been determined in the change case.Therefore, changes to the delivery at this time must be made with particular care because no subsequent checks can prevent possible data inconsistencies.
Call
This exit is called from routine BELEG_SICHERN (SAPMV50A) before deliveries are saved in the dialog and during the creation of deliveries in collective processing.
Data access
Since the delivery is about to be saved, all relevant delivery data can be accessed.The current document status is to be found in the X tables and the previous database status is to be found in the corresponding Y tables.Take into account the following during the data access:
When you create deliveries in collective processing or when you execute the subsequent delivery split (as of Release 4.6) several deliveries may exist in the internal tables.Therefore, it is generally not sufficient for processing only to consider the header lines LIKP or XLIKP.
The header lines of the internal tables may be changed in this exit.Hence standard routines, which require a previous correct positioning of the work areas, can also be called for processing.
If you want to change item data consistently, you should consider the source code example EXAMPLE 1 from the correction instruction.With this, the internal tables of the delivery including the change indicators are updated correctly.
If you want to delete delivery items consistently, call FORM routine XLIPS_LOESCHEN (program SAPFV50P) in a similar way to the source code example EXAMPLE 2 in the correction instruction.
Remark:The source code examples described in the correction instruction are only supposed to illustrate the correct call of the standard FORM routines and they do not have any business significance.If implemented in a productive system, check the exact conditions under which the source code can be processed usefully (for example, deleting items in the case of an active goods issue posting is not useful).Use the above-mentioned indicators, which characterize the processing status of the delivery, to formulate the conditions under which the source code is to be executed.
The requirements update is already completed when the routine is called. If changes relevant for requirements are made, routine BELEG_SICHERN_VORBEREITEN (program SAPMV50A) must be called again.
The header status of the documents involved has also already been determined.For status update purposes, you might need to execute routine XVBUK_PFLEGEN (program SAPFV50K).
Output of messages
With the output of messages or user dialogs you must make sure that this exit can be processed both in the dialog and in the background.In particular during the goods issue posting, no messages or user dialogs must be output under any circumstances because this can result in incorrect material documents.
FORM routine USEREXIT_SAVE_DOCUMENT (Include MV50AFZ1)
Purpose
The routine is used to save your own data when saving deliveries.Delivery data cannot be changed here anymore since it has already been transferred to the update.
Call
It is called when the document is saved (routine BELEG_SICHERN, program SAPMV50A) immediately before the COMMIT WORK statement.
Data access
As in routine USEREXIT_SAVE_DOCUMENT_PREPARE, you can access all the global data of the delivery.When you create the delivery, the document number of the delivery is now also known.
If your own data is to be updated, this should be done via function modules which can be updated.Depending on the way indicator V50AGL-SYNCHRON (Release 3.1I:KZ_SYNCHRON) has been set, carry out the update in synchronous or asynchronous mode:
V50AGL-SYNCHRON = 'X': Synchronous update
V50AGL-SYNCHRON = ' ':Asynchronous update, necessary to call update function module with the addition IN UPDATE TASK.
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 WORK is sent implicitly here.In serious cases processing can be canceled with a message of type 'A'.
Transaction SE80 with program SAPMV50A.
Look at subroutines beginning with USEREXIT_
Regards,
Thomas.
It works, thanks to you.
HOW I CAN ADD LINE TO THE DELIVERY (VL01N) ?
IN TRANSCTION VL01N I TRY TO ADD LINE BY ABAP CODE
MV50AFZ1 -> FORM USEREXIT_SAVE_DOCUMENT_PREPARE.
I APPEND LINE TO XLIPS
xlips-POSNR = L_POSNR.
xlips-MATNR = g_MATNR.
xlips-MATWA = g_MATNR.
xlips-LFIMG = FNL_TOTAL.
xlips-UPDKZ = 'I'.
append xlips.
ITS WORK GREAT LIPS(TBL) GET THE NEW LINE
BUT WHEN I TRY TO SEE IT AGAIN IN VL02N THE NEW LINE APPEAR BUT
THE DATA IS COPY OF THE LAST LINE
HOW CAN I ADD THIS NEW LINE ?
_________________
don't dream it ' , do it .