There are too many, too few or simply incorrect sales document (quotation, sales order, scheduling agreement) or delivery requirements. You can detect or check this using Transaction MD04 (Stock/Requirements List). These inconsistencies may trigger follow-on errors in planning, procurement (production, purchase order) or document processing (availability check).
Sales document, sales requirements, outbound delivery, delivery, delivery requirement, reconstruction, reorganization, VBBE: Sales Requirements Individual Records; VBBS: Sales Requirement Totals Record, summation SUMBD, individual requirement, total requirement, daily requirement, weekly requirement, customer requirement, sales order requirement, ATP availability, batch input, collective processing, /SAPAPO/CIF_DELTAREPORT3: CIF - Comparision/Reconciliation of Transaction Data, VBUK: RFGSK, LFGSK, WBSTK, ABSTK; VBUP: RFGSA, LFGSA, WBSTA, ABSTA
The problem may be caused by a program error or an operating error.
Cause of Error
Try to discover the cause of the error and then try to correct it to avoid new requirements errors. If you cannot correct the error yourself, create a customer message and describe how the error can be reproduced (for further information see Note 547277, point 1).
If errors occur repeatedly in the requirements update that you (still) cannot reproduce, save the log of correction report SDRQCR21 (see below) so that this data may be used when troubleshooting.
- Correct the requirement errors using the SDRQCR21 report in accordance with "Instructions for Using SDRQCR21". To improve system performance, make sure that you have implemented Note 820823 (as of Release 4.5B).
- If the ATP server is active in your system, update the data in the ATP buffer (see Note 163819).
- If your R/3 system transfers sales and delivery requirements to an APO system (using an active integration model for the "Sales order" object), adjust the data in APO using Transaction /SAPAPO/CCR (Report /SAPAPO/CIF_DELTAREPORT3). If this does not work, see Note 444641.
- Material and Plant
If you enter selection criteria for "Material" or "Plant," the report processes the requirements according to this selection only. If you do not enter a selection criterion, the report processes all sales and delivery requirements.
By severely restricting the selection criterion "Material," you may be able to reduce the runtime of the report. In general, selecting the "Plant" criterion only does not shorten the runtime period. For more information, see the section entitled "Performance of SDRQCR21".
- Data transfer
Select the "Data transfer" parameter so that the report updates the requirements on the database.
If you execute the report without selecting the data transfer parameter, the report simulates the update only (that is, it checks the requirements and issues a log, but it does not make any changes). In this way you can also use SDRQCR21 as a pure check report for sales and delivery requirements.
- Compare
Always select the "Compare" parameter to improve the performance (runtime) and to restrict the scope of the log.
The report then corrects, deletes and creates only the requirements affected by the correction. If you do not select the parameter, the report completely reconstructs the database (for the materials/plants selected).
- Planning entry
If you select the "Planning entry" parameter, the report creates planning file entries (entries for the planning run) for the materials/plants affected (and relevant according to the MRP type).
- Processing for material
If you select the "Processing for material" parameter, the report saves the requirements (database commit) one after the other for each material/plant, instead of saving all the requirements in one step. Correspondingly, the log issued by the report is also sorted according to material and plant.
- No parallel processing with a data transfer!
Only execute the SDRQCR21 report with a data transfer once you have made sure that no-one will process sales documents or deliveries (for the materials/plants according to the selection) whilst the report is running, either in the foreground (dialog) or in the background (rescheduling, collective run for creating deliveries, EDI-IDoc and so on)!
Reason: The report does not read or set blocks. It therefore produces correct results only if no other program updates sales or delivery requirements, or checks availability while the report is running. If you execute the report with a data transfer during production operation, the system may even generate new requirement errors!
Additional Information: If you run the SDRQCR21 report twice at the same time, enter the relevant selection criteria Material/Plant for the same reason, so that they do not overlap during simultaneous processing.
- Recommendation
To execute the SDRQCR21 correction report easily, securely and completely, do not enter any selection criteria for "Material" or "Plant," select all four checkboxes and make sure that the report is not running during production operation. If runtime problems or other problems occur, see the following explanations in the sections entitled "Performance of SDRQCR21" and "Solving SDRQCR21 Problems."
- Comments
- Even if you execute the report without a data transfer, you should still select the "Compare" parameter.
However, it is irrelevant whether you select the "Planning entry" parameter in this case, since the report without a data transfer does not create any planning file entries.
- The "Compare," "Planning entry" and "Processing for material" parameters are available as of R/3 Release 3.1I only.
The report may require a long runtime. Since you can only execute it at specific times (you cannot use parallel processing, that is, you cannot execute the report with a data transfer during normal production operation), bottlenecks may occur.
In this case, attempt the following solutions:
- Execute the report with a data transfer only for materials with requirement errors. To do this, proceed as follows:
- Step 1: Execute the report without a data transfer (!) and without the selection criteria 'Material/Plant', but with 'Compare' and with 'Processing for material'. You can also do this during production operation.
- Step 2: Outside production operation (!), execute the report with a data transfer only for those materials (or material/plant combinations) for which step 1 logged requirement errors.
- Step 3, only if you use total requirements (Table VBBS, daily/weekly requirement) and not individual requirements (Table VBBE):
Outside of production operation (!), repeat step 1 without 'Processing for material' for test purposes. The report should no longer log any errors.
- Comment 1: If step 1 logged several materials with requirement errors, repeat it (several times if necessary) with selection(s) according to these materials. By repeating the step in this way, the system may log fewer materials with requirement errors. (During production operation, the report usually logs more requirement errors than actually exist. If data was transferred, the report would then create new errors.) Carry out step 2 only for those materials for which the report has logged permanent requirement errors.
- Comment 2: If the time outside production operation is insufficient for step 2, divide the step into several substeps. That is, divide the material list determined in step 1 into sections that do not overlap and execute the report for each corresponding subsection. You can execute these substeps in succession, if necessary over several days, or partially at the same time depending on your system capabilities.
- Comment 3: If, contrary to expectations, step 3 logs materials with requirement errors, (repeatedly) treat this step as step 1 of a new correction process. Outside production operation, reduce the list of materials with requirement errors as described in comment 1, and so on.
- Do not select the 'Planning entry' parameter.
The report then does not create any new planning file entries (see above). However, you must be aware of the risks involved in doing this!
- Archive sales documents and deliveries.
We recommend that you archive sales documents and deliveries. Document archiving reduces the database for the SDRQCR21 report and for other programs, and therefore significantly improves performance.
- Optimize database performance.
The tables that the report uses to approximately preselect the relevant document items are the most important:
- VBUK and VBUP (without a selection according to Material/Plant)
- VAPMA, VLPMA and VBUP (with a selection according to Material/Plant)
The report still reads entries from tables VBAK, VBAP, VBEP, LIKP, LIPS, as well as VBPA, VBUP and VBFA (if necessary).
Finally, it reads and updates tables VBBE (requirement individual records) or VBBS (totals records for each day/week).
Solving SDRQCR21 Problems
- Document status
The report returns correct results only if the statuses of the documents affected are correct (with regard to reference, delivery, goods movement, reason for rejection). This prerequisite is usually met. Only if you have good reason to suspect that the statuses are inconsistent or that the report has returned incorrect results because of inconsistencies, see Note 207875 and/or 506510, to check and, if necessary, correct the statuses of sales documents and/or deliveries.
- Item Material Index
If you enter the 'Material' or 'Plant' selection criteria, the report returns correct results only if the document items affected are contained correctly in the relevant material index (VAPMA, VLPMA). This prerequisite is usually met. Only if you have good reason to suspect that the index is inconsistent, that the report has returned incorrect results because of inconsistencies, or that the report terminated with SAPSQL_ARRAY_INSERT_DUPREC because of inconsistencies, check the TVIND Customizing table and see Note 128947 and/or 33267 for information about correctly reconstructing the material index.
No comments:
Post a Comment