Functionality You use this method to enter confirmation time tickets> foroperations in production orders. You can also transfer good movements, that are posted together with aconfirmation. If no goods movements have been entered for aconfirmation, they are determined using the standard logic forbackflushing and automatic goods receipt for confirmations. Creation of a WIP Batch> During the entry of a confirmation, you can additionally create a WIPbatch. This functionality is available as of Enhancement Package 4 forERP2005. To be able to use the functionality, you must activate theBusiness Function LOG_PP_WIP_BATCH. In addition, you must activate theWIP batch in Customizing under Logistics General -> Batch Management-> WIP Batches -> Activate WIP Batch aktivieren>. To create a WIP batch with a confirmation, you must specify a batchnumber in the WIP_BATCH field of the table TIMETICKETS. The WIP batchspecified must not yet exist - it is created when the confirmation isposted. If internal number assignment is to be used for the batches, you mustenter the * sign (asterisk) in the WIP_BATCH field instead of a batchnumber.Notes INCLUDE BAPI_PRODORDCONF_HINT_COMMIT OBJECT DOKU ID TX Authorization check> The authorization object C_AFRU_AWK> is checkedtogether with activity 01 (create), the order type and the work of theproduction order to be confirmed. Parameters>
- PostWrongEntries>
You use the PostWrongEntries> parameter to control whether in anexception (incorrect data/ locked objects) the confirmations areaccepted by the SAP system and placed in the pool of incorrectconfirmations. Exceptions for confirmations are logged in the DetailReturn>parameter table. The following characteristic values of the PostWrongEntries>parameter are possible: " ": Confirmations, in which no exception occurred, are posted. All theconfirmations are not processed, they are not placed in the pool forincorrect confirmations. "1": Confirmations, in which no exception occurred, are posted. Allconfirmations with incorrect data are placed in the pool for incorrectconfirmations. On the other hand, confirmations that are not posted duea lock situation are not processed, they are not placed in the pool. "2": Confirmations, in which no exception occurred, are posted. Allconfirmations with exceptions are placed in the pool.
- Testrun>
You use the Testrun> parameter to specify that the transfered dataare only checked to see if they are correct. Locking of objects suchorder and reservation as well as the updating of databases does not takeplace in this mode. You set the value "X" to activate the Testrun> mode.
- Return>
If confirmations could not be processed, due to a serious error, youreceive information about the error in the Return> parameter.
- Timetickets>
The confirmation data is transfered to the Timetickets> table.
- Goodsmovements>
If goods movements should be posted that differ from the standard logic,transfer these goods movements in the Goodsmovements> table.
- LinkConfGoodsmov>
The goods movements are linked to a confirmation via theLinkConfGoodsmov> table. There must be an entry in this table forevery entry in the Goodsmovements> table. The index in theLinkConfGoodsmov-Index_Confirm> field refers to the lines in thecorresponding confirmation in the Timetickets> table and the indexin the LinkConfGoodsmov-Index_Goodsmov> field refers thecorresponding good movement in the Goodsmovements> table. If you want to prevent a goods movement being posted during aconfirmation according to the standard logic, make an entry in theLinkConfGoodsmov> table as well as in the Timetickets>table. The index in the LinkConfGoodsmov-Index_Confirm> fieldrefers to the lines of the corresponding confirmation in theTimetickets> table. Enter the initial value 0 in theLinkConfGoodsmov-Index_Goodsmov> field. It is not necessary tomake an entry in the Goodsmovements> table, in this case. If no entry exists in the LinkConfGoodsmov> table for aconfirmation, goods movements are determined using the standard logicfor backflushing and automatic goods receipt for confirmations.
- CharacteristicsWIPBatch>
Table of characteristics of a WIP batch that is to be created In the CHAR_NAME> field, you have to specify the characteristicname, and in the CHAR_VALUE> field the associated characteristicvalue. The characteristic name passed on must be defined in the class of thematerial to be classified. The technical name of the characteristic mustbe specified, not the short description of the characteristic. If a characteristic name is not defined in the class of the material,the system ignores the table entry. No error message is issued. If a mandatory characteristic is not valuated, the WIP batch is createdneverthe less. In this case the classification of the WIP batch acquiresthe status incomplete>.
- LinkConfCharWIPBatch>
Über die Parametertabelle LinkConfCharWIPBatch> erfolgt dieZuordnung jeder einzelnen Merkmalsbewertung zu einer WIP-Charge.Merkmalsbewertungen, die keiner WIP-Charge zugeordnet sind, werden nichtberücksichtigt. Die Zuordnung erfolgt über die Indizes IndexConfirm> undIndexCharWIPBatch>. Dabei muß der Index IndexConfirm> aufden Eintrag in Parametertabelle Timetickets> verweisen, der IndexIndexCharWIPBatch> auf den Eintrag in ParametertabelleCharacteristicsWIPBatch>. Das heißt, daß sich in der Regel die Anzahl der Einträge in den TabellenLinkConfCharWIPBatch> und CharacteristicsWIPBatch>entsprechen. The assignment of each individual characteristic valuation to a WIPbatch is carried out via the parameter table LinkConfCharWIPBatch >. Characteristic valuations that are not assigned to a WIP batch arenot taken into account. The assignment is effected via the indexes IndexConfirm> andIndexCharWIPBatch>. The index IndexConfirm> must referencethe entry in the parameter table Timetickets> and the indexIndexCharWIPBatch> the entry in the parameter tableCharacteristicsWIPBatch>. This means that, as a rule, the number of entries in the tableLinkConfCharWIPBatch> corresponds to the number in the tableCharacteristicsWIPBatch>.
- DetailReturn>
The DetailReturn> table informs you for each confirmation to beentered, whether a confirmation could not be entered due to a lockconflict or which error occurred. If the confirmation could be enterd successfully, the key of theconfirmation is logged in the fields DetailReturn-Conf_No> andDetailReturn-Conf_Cnt>. In the case of a lock conflict, the DetailReturn-Flg_Locked >indicator is set. If the data is found to be incorrect, a corresponding error message iswritten in the relevant fileds of the DetailReturn> table.Description The Return parameter is only used for serious errors that prevent allconfirmations from being processed further. As a rule, this type oferror only occurs if the transferred confirmation data cannot beconverted into the internal structures, because conventions regardingdata definitions have not been adhered to. The Return> parameter's structure contains all the necessaryinformation about the error in detail. This is also prepared in themessage text MESSAGE>.Default If no serious error is found, the return parameter is returned withinitial values. Description Controls which confirmations are transferred to the error pool. Error pool entries can be corrected and posted usingReprocessing Confirmations>.Value range
- 0: Neither confirmations with errors nor confirmations that cannot be
processed due to a lock situation are transferred to the error pool.
- 1: Confirmations with errors are transferred to the error pool, whereas
confirmations that cannot be processed due to a lock situation are nottransferred to the error pool.
- 2: Both confirmations with errors and confirmations that cannot be
processed due to a lock situation are transferred to the error pool.Default The default value is "0". That is, no confirmations are transferred tothe error pool. Description Indicator that can be used to control whether confirmation data is tobe defined for posting, or whether confirmation data is merely to bechecked in test mode. In test mode, none of the objects are locked andthey can still be accessed if required. Value range
- "X": The transferred data is merely checked in test mode.
- " " (SPACE): If the check was successful, the confirmation data is
defined for posting. Lock entries are set for the affected objects.Default With the preassigned value " ", the confirmation data is defined forposting, provided no error can be found. Description The parameter table DetailReturn> provides information about thesuccessful entry of each individual confirmation in the Timetickets > table, or about any exceptions that occur due to incorrect data ora current lock situation. An entry is made in the DetailReturn> table for each confirmationthat is transferred to the Timetickets> table. For example, thethird entry in the DetailReturn> table provides information aboutthe posting of the third confirmation in the Timetickets> table. If the confirmation is successfully entered, the key assigned to theconfirmation is found in the CONF_NO> and CONF_CNT> fields.Otherwise, all details about the exception are found in the individualfields, but also transferred in the prepared message text MESSAGE >. If a lock situation occurs, the FLG_LOCKED> indicator isalso set.Description Goods movements that should only be posted as the result of aconfirmation. Automatic goods movements can be posted with a confirmation. One formof this is backflushing of components>, the other isautomatic goods receipt posting for an assembly>. If this data isadded to or corrected, the goods movements data can be transferred viathe Goodsmovements> table. The assignment of goods movements toconfirmations occurs via the other parameter table LinkConfGoodsmov >. If at least one goods movement is assigned to a confirmation, noautomatic goods movements are determined for the confirmation when itis saved. In other words, the goods movements that are transferredcannot be regarded as being supplementary to the goods movements thatare automatically posted. Rather, the goods movements that aretransferred represent replacement items for the goods movements thatare automatically posted.Default Note Note that not all of the indicators in the Goodsmovements> tablecan be used. For example, indicator NO_TRANSFER_REQ = X is set in orderto avoid creation of a transfer request during a goods movement.However, this indicator has no effect - a transfer request is creatednonetheless. Cause: Inventory management structure BAPI2017_GM_ITEM_CREATE is usedto transfer goods movements to confirmation BAPIs. However, thiscontains some fields that have no effect or are not supported duringthe confirmation of production orders. Generally, the complete range ofMM functions cannot be supported during posting of goods movements.This is valid for both confirmation dialog functions and confirmationBAPIs.Description Each individual goods movement item is assigned to a confirmation viathe parameter table LinkConfGoodsmov>. Items that are notassigned to a confirmation cannot be included in the process when theconfirmation is saved. Assignment occurs via the IndexConfirm> and IndexGoodsmov>indices. For this process the IndexConfirm> index has to refer tothe entry in the parameter table Timetickets> and theIndexGoodsmov> index has to refer to the entry in the parametertable Goodsmovements>. As a rule, therefore, the total number of entries in theLinkConfGoodsmov> table corresponds to the total number ofentries in the Goodsmovements> table. Exception: You want to prevent goods movements from being automaticallydetermined for a confirmation, because, as an exception, none havearisen. This can be achieved by an entry in the LinkConfGoodsmov>table, without an entry having to be made in the Goodsmovements>table. In this case, the index in the IndexConfirm> field has torefer to the confirmation in question, whereas the initial value 0 > has to be entered in the IndexGoodsmov> field.Description Table of confirmations to be entered, as time tickets. You can identify the confirmed operation> by entering theconfirmation number in the CONF_NO> field. Alternatively, you canidentify the operation by entering the order, sequence and operation,and if necessary the sub-operation, in the ORDERID>, SEQUENCE >, OPERATION> and SUB_OPER> fields. If an individual capacity is being confirmed, you can identify theindividual capacity with the help of the CAPA_CATEGORY> andSPLIT> fields, as well as entering the operation. Each entry in the Timetickets> table represents a separateconfirmation that is checked and processed in the sequence in which itis transferred.
|