You can use this method to confirm time events> for phases of theprocess orders.
You can also transfer goods movements that should be posted togetherwith a confirmation.
If no goods movements are specified for a confirmation, then they aredetermined according to the standard logic for backflushes and automaticgoods receipt for the confirmation.
INCLUDE BAPI_PRODORDCONF_HINT_COMMIT OBJECT DOKU ID TX
INCLUDE BAPI_PROCORDCONF_CD_BERECHT OBJECT DOKU ID TX
INCLUDE BAPI_PROCORDCONF_CD_RETURN OBJECT DOKU ID TX
The PostWrongEntries> parameter controls which confirmations aretransferred to the error pool.
Error pool entries can be corrected and re-posted via thepost-processing of confirmations>.
- 0: No confirmations
- 1: Only incorrect confirmations
- 2: Incorrect confirmations and confirmations that cannot be processedbecause of a lock situation
0: No confirmations
The Testrun> parameter controls whether the confirmation data foris designated for posting or is only checked in the test mode.
- X: The confirmation data is checked in the test mode.
No objects are locked for access.
- Blank: The confirmation data is intended for posting after it has beensuccessfully checked.
Lock entries are set for the affected objects.
Blank: Test mode.
The DetailReturn> table provides one of the following pieces ofinformation for each confirmation:
- Successful posting
- Exception situation (due to incorrect data or current lock situations)
For each confirmation transferred to the Timeevents> table, anentry is made in the DetailReturn> table.
For a successful posting of a confirmation, the key of the confirmationis made available in the CONF_NO> and CONF_CNT> fields.
Otherwise, all the details for the exception situation are madeavailable in the respective fields and the report text is transferredto the MESSAGE>. In the event of a lock situation, theFLG_LOCKED> indicator is also set.
The Goodsmovements> table contains goods movements that should beposted independently of the confirmations.
The following automatic goods movements can be posted together withconfirmations:
- Backflushes of components
- Automatic goods receipts postings for the assembly
To complete or correct the goods movements, the data can be transferredin the Goodsmovements> table.
The assignment of the goods movements to the respective confirmation ismade using the LinkConfGoodsmov> table.
If at least one goods movement is assigned to a confirmation, then noautomatic goods movements are determined on saving.
When you use the confirmation to post goods movements, you cannot usethe entire MM functionality. This applies to the confirmation dialogtransactions and also to the confirmation BAPIs.
The NO_TRANSFER_REQ >= X indicator in theGoodsmovements> table is set to prevent a transport requirementfrom being created when the goods movement is executed. For the transferof goods movements to confirmation BAPIs, the inventory managementstructure BAPI2017_GM_ITEM_CREATE> is used. However, this containssome fields that do not play a part in or are not supported forconfirmations. Therefore, the indicator has no effect.
The table LinkConfGoodsmov> assigns each goods movement item to aconfirmation.
The assignment is carried out via the indexes IndexConfirm> andIndexGoodsmov>:
- IndexConfirm> refers to the entry in the AtHdrLevels> table.
- IndexGoodsmov> refers to the entry in theGoodsmovements> table.
Items that are not assigned to a confirmation are not taken intoaccount when you save.
If you want to prevent goods movements being automatically determinedfor a confirmation, because none have occurred, make an entry in thetable LinkConfGoodsmov> without making an entry in theGoodsmovements> table.
In this case, the index in the IndexConfirm> field must refer tothe confirmation concerned, and the IndexGoodsmov> field must havethe initial value 0>.
The Timeevents> table transfers the confirmations to be enteredas time events.
The confirmed object phase can be identified in one of the followingways:
- By the confirmation number in the CONF_NO> field
- By a combination of the following details:
Order in the ORDERID> field
Phase in the PHASE> field
Possible secondary resources in the SEC_RESOURCE> field
Each entry in the Timeevents> table represents a separate timeevent, which is checked and processed in the transferred sequence.
Each time event must be described by specified a valid record type inthe RECORDTYPE> field. The following record types are permitted:
- B10: Start of processing
- B20: Partial finish of processing
- B30: Interruption of processing
- B40: End of processing
- V20: Partial finish of variable activity
- V40: End of variable activity
You must specify the date and time in the LOGDATE> and LOGTIME> fields for each time event.