|
Functionality
You are carrying out a backflush for the make-to-order scenario. If thebackflush cannot be carried out successfully, the system displays anappropriate message via the exporting parameter RETURN. If thebackflush was carried out successfully, the exporting parameter RETURNis filled with initial values.
The backflush is ultimately carried out for a material. The costs arecollected at the product cost collector.
Meaning of the parameters:
BFLUSHFLAGS: Control of the type and the scope of a backflush
BFLUSHDATAGEN: Parameters for the backflush data independent of anyscenario
BFLUSHDATAMTS: Parameter specifically for the make-to-stock scenario
SERIALNR: List of serial numbers
RETURN: Return of an error code when the backflush could not be carriedout successfully.
No COMMIT WORK is carried out in this module.
Note that a COMMIT WORK is created directly after accessing this BAPI.This means that it is not possible to use several BAPIs which recorddata on the database in sequence and then to create only one COMMITWORK after the last BAPI. Should this happen, however, the second BAPIwill be terminated as such a chain of accesses is not supported by theprogram. Notes
You must enter a material and a plant or a planned order.
You must also enter a posting date and a document date.
If the repetitive manufacturing profile is set so that an onlinecorrection is mandatory when withdrawal errors occur and if awithdrawal error does occur when backflushing, the backflush cannot becarried out and an appropriate error code is displayed in the RETURNparameter.
If the repetitive manufacturing profile is set so that an onlinecorrection is optional when withdrawal errors occur and if a withdrawalerror does occur when backflushing, the system creates postprocessingrecords for the components which could not be withdrawn. Therefore,make sure that the creation of postprocessing records is allowed in therepetitive manufacturing profile. Otherwise the withdrawal errors arenot logged and there is no system-aided way of postposting thecomponents.
The backflush number given by the system is returned to the caller viathe CONFIRMATION parameter. Description
The backflush number is given by the system when carrying out abackflush. It specifically identifies a backflush within the SAP system. Description
The fields in this parameter provide information on the error whichoccurred when the backflush could not be carried out successfully. Thefield MESSAGE contains a detailed error description should the shorttext for the error not provide enough space to describe the error. Description
The individual parameters of this structure contain the data requiredfor the backflush which are independent of the selected scenario(process). The following parameters must be transferred:
POSTDATE,,,,Posting date
DOCDATE,,,,Document date
You must also fill in one of the fields - either PRODPLANT orPLANPLANT. Depending on whether you are backflushing a yield quantityor a scrap quantity, you have to fill in either the field BACKFLQUANTor SCRAPQUANT. If you are backflushing component scrap, excesscomponent consumption or a separate activity posting, the fieldBACKFLQUANT must be filled with the quantity to be used as thereference quantity for determining the components or activities.
The field PLANORDER must be filled if the backflush is to be carriedout for a specific planned order. Otherwise, you have to fill at leastthe field MATNR with the material number of the assembly to bebackflushed.
WARNING: If no production version is transferred (PRODVERSION) andseveral production versions exist for the material in the specifiedplant, the system cannot carry out the backflush successfully as nospecific production version can be selected. Description
The individual parameters of this structure contain the data requiredfor backflushing when backflushing in the make-to-stock scenario. Theseare the following parameter:
REPPOINT,,,,Reporting point (milestone operation number in the routing)
This parameter must be filled if you want to carry out a reportingpoint backflush or if you want to carry out a separate activityposting, a separate goods issue posting or a separate component scrapposting with reference to a reporting point. Description
The individual parameters of this structure control the type or thescope of the backflush to be posted within the backflush processesselected by the choice of BAPI.
- Parameter BCKFLTYPE
This parameter determines the type of backflush to be posted. The
following backflushing types are allowed when backflushing in amake-to-stock scenario:
01,,Final backflush
02,,Reporting point backflush
10,,Separate activity backflush
11,,Separate component consumption backflush
12,,Separate component scrap backflush
21,,Final Backflush (Document-Neutral Reversal)
22,,Reporting Point Backflush (Document-Neutral Reversal)
31,,Separate Component Consumption Backflush (Document-Neutral Reversal)
32,,Separate Component Scrap Backflush (Document-Neutral Reversal)
If the value 02 is transferred with the parameter (reporting pointbackflush), a reporting point must be transferred in structureBFLUSHDATAMTS with the parameter REPPOINT.
- Parameter RP_SCRAPTYPE
This parameter determines the type of a reporting point scrap backflush.It only has to be filled if the value 02 is transferred with parameterBCKFLTYPE and you are backflushing scrap. That is, if a value is enteredin field SCRAPQUANT of parameter BFLUSHDATAGEN. The possible variationsof the parameter RP_SCRAPTYPE are:
1,,Scrap at the entered reporting point
2,,Scrap up to the entered reporting point
3,,Excess component consumption at the reporting point (not fordocument-neutral reversals)
If a value is required for this parameter, but no value has beentransferred, the value 1 is set as the default value.
- Parameter ACTIVITIES_TYPE
This parameter defines the type of a separate activity backflush. Itonly has to be filled if the value 10 is transferred with the parameterBCKFLTYPE. The possible variations of the parameter are:
1,,Activities of all operations
2,,Only activities at the specified reporting point
3,,Only activities of operations after the last reporting point
If a value is required for this parameter, but no value has beentransferred, the value 1 is set as the default value. For variations 2and 3, you must enter a reporting point with parameterBFLUSHDATAMTS-REPPOINT.
- Parameter COMPONENTS_TYPE
This parameter defines the type of a separate goods issue posting or aseparate component scrap posting. It only has to be filled if the values11 or 12 are transferred with the parameter BCKFLTYPE. The possiblevariations of the parameter are:
1,,Components of all operations
2,,Only components for the entered reporting point
3,,Only components after the last reporting point
If a value is required for this parameter but no value has beentransferred, the value 1 is set as default value. For variations 2 and3, a reporting point has to be transferred with parameterBFLUSHDATAMTS-REPPOINT.Description
Goods movements that are to be posted depending on the confirmations.
Automatic goods movements can be posted with a confirmation. Thisinvolves the backflushing of components and automatic goodsreceipt postings for an assembly. If this data is to be supplementedor corrected, the goods movement data can be transferred in the
Goods Movements table.
If a confirmation is assigned to at least one goods movement, there isno determination of automatic goods movements for the confirmation uponsaving. That is to say, the goods movements passed on cannot be regardedas additional goods movements to the ones automatically posted. Instead,they represent replacement items for them so to speak.Default Note
Note that not all of the indicators of the Goods Movements table can beused. For example, the NO_TRANSFER_REQ = X indicator is set to preventthe generation of a transfer requirement when the goods movement iscarried out. However, this indicator has no effect - a transferrequirement is created nevertheless.
Cause: The inventory management structure BAPI2017_GM_ITEM_CREATE isused to pass on goods movements to confirmation BAPIs. However, thisstructure contains some fields that have no relevance to confirmationsin repetitive manufacturing or are not supported. Generally, thecomplete MM functionality cannot be supported in the posting of goodsmovements via confirmations. This applies both to the confirmationdialog transactions and the confirmation BAPIs. Description
If serial numbers have to be maintained for the finished product to bebackflushed, you can use this parameter to transfer the serial numbersto be used for posting the goods receipt of the finished product. Notethat, in certain circumstances, the number of serial numbers to betransferred must correspond exactly to the backflush quantity (thisdepends on the serial number settings in the SAP system). If in such acase, too few serial numbers are transferred, the system cannot carryout the backflush successfully.
|