User exits in delivery processing Help

SAP Note Number Note Language DEENJA Display Versions 56781012

1314
Print SSCR 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
ecord is to be inserted (UPDKZ = 'I'), updated ('U') or deleted ('D') in the dat
abase.
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. In dialogprocessing
, only structure LIKP contains the current status up to the start of saving. The
corresponding internal table XLIKP is only reliably filled during collective pr
ocessing;
When saving, indicator XLIKP-UPDKZ states for each individual table entrywhether
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_U
PDKZ is filled with 'U' when the header is changed.
Structure YLIKPcontainsthe 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 statusof the deliveryitems. The ch
ange indicator (XLIPS-UPDKZ) states whether the item is to be inserted, changed
or deleted (see above).
Items thatwere deletedor changed in change mode also appear in table YLIPS, whic
h represents the database status of the respective items.
The item status of the individual delivery items is stored in internaltable XVBU
P. The table also contains a change indicator in accordance with the above-menti
oned logic, however, entries to be deleted are always removed directly from the
table. Hence, change indicator 'D' does not occur in XVBUP.
The original status of the item status data is stored in change mode in table YV
BUP. You can recognize items to be deleted by change indicator YVBUP-UPDKZ = 'D'
.
Similar to the item statuses, tables XVBUK and YVBUK contain the header status i
nformation. 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.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; Generall
y the document flow table also contains data from the preceding documents.
The partners are stored in tables XVBPA and YVBPA. The change indicator is manag
ed 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 processingstatuses of
the delivery because the exit is processed both during the creation of deliveri
es and during changes. You can use the following indicators to determine the pro
cessing status of the delivery:
Create, changeor display?
FieldT180-TRTYP has value 'H' in change mode, value 'V' when changing and charac
teristic 'A' in display mode.
Dialog or collective processing?
Indicator V50AGL-SAMMELGANG (as of Release 4.0) or KZ_SAMMELGANG (up to Release3
.1I) has 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 should suppress the output of
error messages in the dialog.
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.
Goods movement posting active?
If the goods issue posting or goods receipt posting is active,indicator V50AGL-W
ARENAUSGANG is set. In the case of a cancellation, indicator V50AGL-WARENAUSG_ST
ORNO 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 value 'WABU'.
Is the delivery deleted completely?
Ifadelivery document is deleted completely, field YLIKP_UPDKZ is set to 'D', T18
0-TRTYP has characteristic 'V' in this case.
Is the subsequent deliverysplit active? (only relevant in Release 4.6)
Indicator V50AGL-MULT is set if deliveries are saved that weresubsequently split
. In this case indicator T180-TRTYP has value 'V'. The internal tables of delive
ry processing can contain several deliveries (as in collective processing).
Synchronous or asynchronous update?
Indicator V50AGL-SYNCHRON (Release 3.1I: KZ_SYNCHRON) is set when thedelivery is
to be updated synchronously. If the indicator is not set, the delivery is updat
ed asynchronously. The update function modules must then be called with the addi
tion IN UPDATE TASK.
Bear in mind that the query for the transaction code (SY-TCODE) indialog process
ing no longer works reliably in Release 4.6 since it is possible to change betwe
en display mode and change mode within delivery processing. Field SY-TCODE is al
so 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.
You can find more information on this topic in Note 209846.

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.

Call
The routine is called from within the standard routine BELEG_DATEN_INIT (SAPMV50
A).
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).
Inthe dialog before the return to the initial screen with functions 'Back' or 'C
ancel' (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 inbou
nd delivery'.
As of Release 4.6: Incollectiveprocessing for the creation of deliveries before
the processing of a new packet for supplied preceding documents.
Prior to Release 4.6:In collectiveprocessing for the creation of deliveries afte
r the processing of a packet for supplied preceding documents.
When starting the transaction in theolddeliverytransactions (VL01, VL02, VL03).
In the new delivery dialog the initialization is not called for performance reas
ons.
Data access
During the document initialization, the access to delivery data results in undef
ined results.

Output of messages
The output of error messages during the document initialization does not make se
nse.

FORM routine USEREXIT_DELETE_DOCUMENT (Include MV50AFZ1)

Purpose
When a delivery is deleted, 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. Immediately after FORM routine USEREXIT_DELET
E_DOCUMENT is called, the document backup is called for which the logically dele
ted 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
change indicator 'D'.
The internal table YLIPS contains the database status of all delivery items in t
his special case.
The internal table for item status XVBUP no longercontains anyitems of the curre
nt delivery, the database status of the item status can only be determined from
internal table YVBUP.
In the internal table for the header status of delivery XVBUK thereis alsono ent
ry anymore for the current delivery. The current status information (database st
atus) can be taken from table YVBUK.
Theinternal table with partner data XVBPA is also empty. The database status of
the partner data is in internal table YVBPA.
The internaltables ofdelivery processing must not be manipulated in this exit un
der any circumstances so as to avoid data inconsistencies.
Output of messages
The output of error messages and user dialogs is only possiblewith restrictions
in FORM routine USEREXIT_DELETE_DOCUMENT. No messages of type E or W can be outp
ut. 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 byreturnin
g 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 rea
sons, an error message of 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 deliv
ery.

Call
The routine is processed exactly once after the delivery document datais read in
the change or display mode of the delivery. Exception: The routine is not execu
ted when reading deliveries during the subsequent delivery split and when enhanc
ing deliveries.

Data access
Within the exit you have full access to all the data of the delivery thathas jus
t been imported. In principle it is possible for you in this exit to already cha
nge the imported delivery data. For this, consult the recommendations on changin
g delivery data in the description of user exit USEREXIT_SAVE_DOCUEMENT_PREPARE.

Output of messages
There are no restrictions placedonthe output of error messages and user dialogs
in this exit. However, 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. You can recognize this processing case by the f
act that indicator KOMMIRUECKMELDUNG is set.
For the goods issue posting via the delivery monitor (TransactionVL06G) or Trans
actions VL19, VL21, and VL23, the delivery dialog may be called in batch input m
ode. In these cases, 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. The b
atch input case can be recognized by the fact that indicator SY-BINPT is set. If
the difference regarding the batch input mode needs to be made more precise, th
e 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 header table LIKP w
ith 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 calledat the end of routine
s 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 tr
ansferring 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 deliverysince th
is data is not yet available at that time. However, when creating deliveries wit
h order reference, you can access the data of the supplied order via internal ta
bles CVBAK (order header), CVBAP (order item), CVBPA (order partner) and CVBEP (
delivery schedules). When importing data from these tables, make sure that the c
urrent header lines of the tables are not changed! Use local structures instead.
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. 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 deliverydata, 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, messa
ges of type I and E can be included in the delivery creation log via FORM routin
e MESSAGE_HANDLING (main program SAPMV50A). (If this routine is processed in cha
nge mode, messages are not output directly but collected in the log). Messages o
f type W are not written to the log.

Other notes
Bear in mind that changing data in structure LIKP affects the delivery split dur
ing 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 deliveryit
ems. 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). When you
create items with predecessor reference, 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). No status information is ava
ilable yet for the new items. If, prior to the current item, other items were al
ready supplied in the same delivery, you can access the header status of the del
ivery 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 XVBU
P.
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 c
hanges to these fields may result in data inconsistencies. Therefore, analyze an
y possible dependencies before making any changes to standard fields.
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.
It does not make sense to change other data of the delivery in thisexit. Here yo
u 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 struc
tures to read data from you own internal delivery tables.
Note that when you create a batch split items, the fields for the deliveryquanti
ty (LIPS-LFIMG, 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.

Output of messages
The direct output of messages is not allowed in this exit because thiscan result
in document inconsistencies. Instead, use FORM routine MESSAGE_HANDLING (main p
rogram SAPMV50A), which, in change mode, transfers messages of type E or I to th
e delivery processing log.
If you do not want the itemtobecreatedbecause an error occurred, you should also
set the XLIPS_LOESCHEN_MENGE_0 indicator in the routine to the value 'X'.

FORM routine USEREXIT_BATCH_DETERMINATION (Include MV50AFZZ)

Purpose
Youcanuse the routine to determine the batch, that is to be assigned to the deli
very item, in accordance with your own criteria.

Call
The user exit is called during the creation of the item within routine LIPS_BEAR
BEITEN (program SAPFV50P).

Data access
Within the routine, the access is possible to thealreadydetermined order item da
ta (LIPS). In addition, you can access the corresponding header data of the deli
very (XLIKP, XVBPA).
In the routine only the batch of the delivery should be changed (fieldLIPS-CHARG
). The current header lines of the internal tables must not be changed. Use loca
l 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, messa
ges of type I and E can be included in the delivery creation log via FORM routin
e MESSAGE_HANDLING (main program SAPMV50A). (If this routine is processed in cha
nge mode, messages are not output directly but collected in the log). Messages o
f type W are not written to the log.

FORM routine USEREXIT_SAVE_DOC_BEFORE_PREP (Include MV50AFZ1)

This routine is only available after the implementation of Note 751000.

Purpose
This routine can be used for the final change of all delivery data. Atthe time o
f the call, 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. Therefore, changes to the delivery at this
time must be made with particular care because no subsequentchecks can prevent p
ossible data inconsistencies.
Since requirements processinghasnot yet occurred, this user exit is, in particul
ar, suitable for changes relevant for requirements when the delivery is saved.

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. 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).

Data access
The data access corresponds to that of FORM routine USEREXIT_SAVE_DOCUMENT_PREPA
RE (Include MV50AFZ1).

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. At the time of the call, the delivery is
complete and consistent, only the document number has not yet been determined i
n the creation case. Therefore, changes to the delivery at this time must be mad
e with particular care because no subsequent checks can prevent possible data in
consistencies.

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
.

Data access
Since the delivery is about to be saved, all relevant delivery data can be acces
sed. 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. 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.6) several deliveriesmay exist in the inter
nal tables. Therefore, it is generally not sufficient for processing only to con
sider the header lines LIKP or XLIKP.
The header lines of the internal tables may be changed in thisexit. Hencestandar
d 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 thesource code
example EXAMPLE 1 from the correction instruction. With this, the internal tabl
es of the delivery including the change indicators are updated correctly.
If you want to delete delivery items consistently,call FORMroutine XLIPS_LOESCHE
N (program SAPFV50P) in the same way as source code example EXAMPLE 3 in the cor
rection instructions.
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. If implemented in a p
roductive 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 i
ssue posting is not useful). Use the above-mentioned indicators, which character
ize the processing status of the delivery, to formulate the conditions under whi
ch the source code is to be executed.
The requirements update is already completed when the routine is called. If you
carry outchangesrelevant for requirements, FORM routine USEREXIT_SAVE_DOC_BEFORE
_PREP (Include MV50AFZ1) from Note 751000 should be used.
Note that the requirements can be updated incorrectly if you delete the entire d
ocument in this user exit. Use a user-defined check in the incompletioncontrol i
f you want to delete the entire document (see Note 158807). If it is not possibl
e to use the incompletion control, you should use user exit USEREXIT_SAVE_DOC_BE
FORE_PREP for the deletion.
The header status of the documents involvedhasalso alreadybeen determined. For s
tatus update purposes, you might need to execute routine XVBUK_PFLEGEN (program
SAPFV50K).
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. In particular during the
goods issue posting, no messages or user dialogs must be output under any circu
mstances because this can result in incorrect material documents.

FORM routine USEREXIT_SAVE_DOCUMENT (Include MV50AFZ1)

Purpose
The routine is used to save yourowndatawhen saving deliveries. Delivery data can
not be changed here anymore since it has already been transferred to the update.

Call
Itis 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, youcanaccess all the global data o
f the delivery. When you create the delivery, the document number of the deliver
y is now also known.
If your own data is to be updated, this should be done via functionmodules which
can be updated. Depending on the way indicator V50AGL-SYNCHRON (Release 3.1I: K
Z_SYNCHRON) has been set, carry out the update in synchronous or asynchronous mo
de:
V50AGL-SYNCHRON = 'X': Synchronous update
V50AGL-SYNCHRON= ' ': Asynchronous update, necessary to call update function mod
ule 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 W
ORK is sent implicitly here. In serious cases processing can be canceled with a
message of type 'A'.