You can use this method to make the data of a confirmation for a processorder available in the ConfDetail>.
The confirmation can be created as one of the following objects:
- Time ticket
- Time event
- Activity confirmation
- Order confirmation
The following goods movements, that are posted together with theconfirmation, are also made available:
- Successfully posted goods movements in the Goodsmovements> table
- Incorrect goods movements in the Failedmoves> table
These goods movements are still available for post-processing viatransaction COGI>.
INCLUDE BAPI_PROCORDCONF_CD_BERECHT OBJECT DOKU ID TX
The parameter ConfDetail> transfers detailed data on theconfirmation.
The confirmation is uniquely identified by its key, which consists ofConfirmation> and ConfirmationCounter>.
The Return> parameter displays whether the required data of aconfirmation can be made available successfully.
If the confirmation fails, then the return parameter transfers thecorresponding detailed information and report texts.
The following exception situations can prevent a successfulconfirmation:
- The required confirmation does not exist
- The confirmation belongs to another order category
- There is no authorization for displaying the confirmation
If the confirmation data was made available successfully, then thereturn parameter is returned with initial values.
The Confirmation> parameter transfers the confirmation number.
The number is assigned internally for each phase of an order when thephase is created. It uniquely identifies the phase.
If a confirmation is created not for the phase but for the order, thenthe number is assigned and stored in the order header when the firstconfirmation is created.
Together with the Confirmationcounter> confirmation counter, theconfirmation number forms the key of every confirmation record in theAFRU> table.
The Confirmationcounter> parameter transfers the confirmationcounter.
The internally assigned counter distinguishes between multipleconfirmations for the same phase or for the same order. The lastconfirmation counter assigned is retained in the phase or in the order.
Together with the Confirmation> confirmation number, theconfirmation counter forms the key of every confirmation record in theAFRU> table.
The FailedGmoves> table contains all the goods movements for theselected confirmation, that could not be posted for the current pointin time.
The following goods movements cannot be posted:
- Incorrect goods movements
- Pre-selected goods movements
If the posting of goods movements fails because of an exceptionsituation, then the goods movements can be posted using post-processing.
The timing of the posting of goods movements can be decoupled from thesaving of the confirmation. In this case future change records forbackground jobs are written.
The Goodsmovements> table contains all the goods movements forthe selected confirmation that were successfully posted to date.
The following automatic goods movements can be posted for aconfirmation:
- Automatic goods receipt
If the posting of goods movements fails due to a lock situation, thenthe goods movements can be posted using the post-processing.
The timing of the posting of the goods movements can be decoupled fromthe saving of the confirmations. In this case, future change recordsfor background jobs are written.