Note 488725 - FAQ: Temporary quantity assignments in Global ATP
Summary
This note contains frequently asked questions on the subject of
'Temporary/persistent quantity assignments in Global ATP'.
CAUTION: This note is updated regularly.
- 1. What are temporary quantity assignments and why are they necessary?
Temporary quantity assignments reserve (or lock) quantities allotted during an ATP check in APO against opposing parallel ATP checks. The quantities remain locked until the order which triggered the ATP check is either saved or exited without saving. In either case, the related temporary quantity assignments are deleted. In the first case, they are no longer required because the order was cancelled, while in the second case, the updated order reserves the quantities itself in APO. A separate quantity assignment is then no longer necessary. This means that temporary quantity assignments exist only for the short duration of a transaction. An exception to this rule is the case of persistent quantity assignments (see FAQ point 2), which are still present after the end of an transaction. Quantity assignments are stored in the liveCache and once they are created, they are immediately displayed for all parallel transactions. You can identify temporary quantity assignments in the monitor (transaction /SAPAPO/AC 06) by the persistency indicator N (= non-persistent). All ATP basic methods (product availability check, product allocation, check against planning) create their own temporary quantity assignment.
- 2. What are persistent quantity assignments?
Unlike temporary quantity assignments, persistent quantity assignments continue to exist after a transaction is ended, that is, they reserve quantities over a longer, unspecified period until they are deleted by another transaction. The persistence indicator for persistent quantity assignments changes depending on the transaction phase they are in: In the transaction that creates them, they have the indicator V
(= prepersistent), and when the transaction is exited with 'Save', they are assigned the indicator P (= persistent), otherwise they are deleted. If another transaction has read or downloaded the persistent quantity assignments, they acquire the indicator O (= postpersistent). If this downloading transaction is then saved (updated), the postpersistent quantity assignments are deleted.
Persistent quantity assignments are used in the following scenarios:
- Backorder processing (batch with postprocessing and interactive operation)
- ALE third-party order processing ( 'old third-party')
- CRM scenario ('old' CRM scenario where the requirements are contained in R/3, not in CRM)
- Multi-level ATP check (as of APO 3.1)
The following section recaps the transition between the various persistence indicators, using the example of backorder processing:
During backorder processing, prepersistent quantity assignments are written as a result of the checks. When the backorder processing is then saved, the quantity assignments become persistent (the 'Backorder processing' transaction is thus completed). If this backorder processing is to be updated, the results are sent to R/3, updated there and then sent to APO using the core interface (CIF). In APO, the related quantity assignments are now imported by means of the update transaction and switched to postpersistent. Once the update is complete, the postpersistent quantity assignments are deleted. The postpersistent status is required to allow postpersistent quantity assignments to be switched back to persistent in the event of an error (that is, if the APO update encounters an error and is not committed). If the assignments are already deleted, they can no longer be restored.
- 3. What are quantity assignments of the type 'Advanced Planning and Scheduling'?
These quantity assignments, also known as APS delta records, differ fundamentally from the temporary and persistent quantity assignments described above. The main difference is that APS delta records are not quantity assignments, but time series entries for temporary planned orders. They are used in the CTP (Capable-To-Promise) scenario. In this scenario, temporary planned orders may sometimes be created during the ATP check and updated in the order network in the liveCache. However, the planned orders are not yet contained in the ATP time series in the liveCache since they could then be read by parallel ATP checks and used for confirmation. Therefore, instead of temporary planned orders being entered in the ATP time series, APS delta records are created for the planned orders. Once the CTP check result is saved and the temporary planned order becomes a 'real' planned order, the APS delta records are entered (incorporated) in the ATP time series. Otherwise, the APS delta records are simply deleted. Three APS delta records are created for each temporary planned order:
One for 1.1.1970 with quantity -X
One for 1.1.1970 with quantity -X
One for the correct date of the planned order with quantity X
The reason for the peculiar records for 1.1.1970 is explained by the method of operation of the scheduler in the liveCache order network. The receipts are always first created on 1.1.1970 (which is time 0 in the UNIX environment) and are then moved to the correct time.
Report /SAPAPO/OM_DELTA_COMPRESS compresses the delta records (for example, it deletes unnecessary delta records for 1.1.1970) and should always be executed if there are many delta records and you want a clear overview.
You can display APS delta records with the display function for temporary quantity assignments. For this purpose, select the relevant category 'Advanced Planning and Scheduling' and leave the User field blank. APS delta records are always written with the system user 'THE_NET'.
APS delta records should not be deleted manually since this can cause inconsistencies in the ATP time series. In any case, remaining delta records are not problematic because they do not reserve quantities. However, you must be careful when manually deleting temporary planned orders. You should only do so using the standard product heuristics in the product view, since in this case the related APS delta records are incorporated in the ATP time series. If you do not use the standard product heuristics, negative ATP time series entries can result, because the corresponding quantity is subtracted from the ATP time series as a result of deleting the planned order (even though the quantities were not contained in the ATP time series because there are only APS delta records). If these inconsistencies have occurred, you can incorporate the APS delta records subsequently using report /SAPAPO/ATP_SERVICE. To do this, simply select the product and location in the report and then select the option for incorporating delta records. The corresponding APS delta records then disappear and the ATP time series are consistent again.
After you implement Note 970113 (SCM 4.1 and higher), CTP and GATP are integrated to such an extent that APS delta records are no longer necessary.
- 4. Why is
- 5. This happens if the order number is (still) unknown when the quantity assignment is created. In fact, since this is the usual scenario for temporary quantity assignments, it is NOT an error.
For example: A sales order is created in R/3 and checked in APO. The check generates non-persistent quantity assignments with an unknown order number because this order does not yet exist in APO. The order only exists in APO after the order is saved in R/3, posted and then transferred to the APO via CIF. However, the temporary quantity assignments are already gone (they are deleted immediately after the APO posting). This means that these non-persistent quantity assignments can never have an order number.
The order number field is for information purposes only and is not a key field for the quantity assignments. As a result, even though in theory it would be possible, the order number is not added subsequently when the persistent delta records are posted either.
- 6. Sometimes quantity assignments with product or location 'PeggingID not found' appear in the display of the temporary quantity assignments (transaction /SAPAPO/AC06). Why is this? Can these quantity assignments be deleted?
Every product location combination (or pegging area) is encrypted by a GUID. This pegging area is usually in the liveCache and on the APO database. The quantity assignments display determines the temporary quantity assignments from the liveCache and then tries to convert the GUID of the pegging area into readable product and location names. The conversion is performed by reading the pegging area data on the database. If this entry is not found on the database, 'PeggingID not found' is displayed as product and location. One reason for this may be inconsistencies between the liveCache and database - the pegging area may be in the liveCache, but not in the database. You can use transaction /SAPAPO/OM17 to eliminate these inconsistencies. Pegging areas are frequently missing in the case of make-to-order production because these are created dynamically and deleted.
The quantity assignments with unknown pegging area should first be regarded as normal quantity assignments (they can be deleted if old and no longer required).
- 7. Why are no quantity assignments displayed in the display of the temporary quantity assignments (transaction /SAPAPO/AC06), even though * was entered as a user?
No wildcards can be used in the user selection. To display temporary quantity assignments for all users, leave the user field blank.
- 8. Why are quantity assignments left even though they should have already been deleted? What is the cause and how can the quantity assignments be deleted?
Sometimes, quantity assignments are not be deleted. There are many reasons for this, depending on the particular scenario used. There is therefore no generally applicable procedure for determining why quantity assignments remain. The following section gives some tips on eliminating problems with remaining quantity assignments (depending on the given scenario).
- General information
In most cases, quantity assignments are deleted using the CIF interface, depending on activities in R/3 (such as saving/terminating an order, posting backorder processing). The related queue entries (transaction SMQ1 in R/3 or SMQ2 in APO if you switched to inbound queues) start with CFTG, followed by a GUID. These queues contain the /SAPAPO/CIF_GEN_TID_INBOUND module, which is responsible for deleting quantity assignments. Therefore, if quantity assignments remain, you should first check whether there are corresponding queue entries. If so, these must be restarted. You should never delete the queues, because then the system does not delete the related quantity assignments and you must therefore eliminate them manually. If no queue entries are present, you can use transaction SM58 (Selection with initial user) to check in APO if there are entries of the module /SAPAPO/DM_DELTA_CLEAR_TRGUID. This module is responsible for deleting the quantity assignments in APO. Any entries found must be processed. Since locking problems are often the reason why these entries are left, you should check transaction SM58 regularly and process it if necessary. This transaction can be scheduled as a batch job by scheduling report RSARFCEX as a job. In this case too, the entries must never be deleted, since otherwise the related quantity assignments are no longer deleted.
- Backorder processing
Prepersistent quantity assignments are written during backorder processing and these become persistent after saving. These remain until backorder processing is posted or deleted. They are posted on an order-by-order basis, that is, while the orders involved are posted in APO, the related persistent quantity assignments change to postpersistent and then the postpersistent quantity assignments are deleted via the CIF queue. If persistent quantity assignments of a posted backorder processing remain, you should check whether backorder processing was actually fully updated afterwards in APO (status 'X' = update ended). It is possible that not all quantity assignments are deleted immediately when data is updated afterwards in APO, but only when the last order is transferred (when backorder processing has the status 'Update ended' ). An overall deletion call then takes place for all remaining quantity assignments of this backorder processing.
In this regard, it should be mentioned that a quantity assignment cannot always be assigned precisely to an order item with the POSGUID in backorder processing. The reason for this is that quantity assignments during the backorder processing checks are only written if the cumulative confirmed quantities exceed the quantities already confirmed before the backorder processing. In calculating whether this limit (high-water mark) of already confirmed quantities is exceeded, the assignment to the order item list is lost - this means that a quantity assignment may sometimes be written for an order item, even though a quantity was no longer assigned to it by backorder processing. This does not affect the system, as only the sum of the locked quantities is important. However, the system response can cause some confusion, particularly if quantity assignments were not deleted completely after backorder processing.
- ALE third-party order processing / CRM scenario
In these scenarios, prepersistent quantity assignments are written during the online ATP check, and are then converted to persistent quantity assignments when the order is saved. These remain until the order is transferred to the connected second OLTP System and updated there. If persistent quantity assignments now remain, you should check whether the transferred order has a confirmed quantity. If not, the previous confirmation from the first R/3 or CRM system could not be assigned to the transferred order. This is often due to the first and second system having different settings for transport and shipping scheduling. If this is not the case, you should check the queues (as described under general information), in both the first and the second system.
If you cannot determine and eliminate the cause of the remaining quantity assignments, you can delete them manually. You can do this using the monitor for temporary quantity assignments (transaction /SAPAPO/AC 06). You can select quantity assignments on the display screen and delete them by choosing Delete (the garbage can with text 'TrGuid'). This deletes all quantity assignments that were written by the system in the same transaction (that is, all assignments with the same transaction GUID). For this reason, all you have to do to delete all quantity assignments for a backorder processing run is select a single quantity assignment since all quantity assignments for this backorder processing have the same transaction guid.
In addition to this manual deletion procedure, you can also use the deletion report /SAPAPO/OM_DELTA_REMOVE_OLDER. This report deletes all selected quantity assignments, depending on how old the quantity assignments are and on the user who created the quantity assignments. Of course, you can also use transaction SM36 or SM37 to schedule the report as a batch job and then regularly delete old quantity assignments. However, in this case, you must be careful not to delete quantity assignments that are still required. These vary according to customer and the scenario used. Non-persistent quantity assignments that are older than a day can usually be deleted since these are only supposed to exist for a very short time. In the case of persistent quantity assignments, it depends on how long the overall process takes (for example, the maximum time needed to update a backorder processing run). If a customer frequently has backorder processing that is only updated after 3 days, no persistent quantity assignments younger than 3 days should be deleted.
- 9. Why are quantity assignments not deleted automatically during a rollback? I want to understand the technical background and potential problems that may occur when I delete quantity assignments.
Naming the function modules that are not released is simply a debugging tool. It does not mean that SAP allows you to use these modules in your own applications. As of SCM 4.1, SAP offers released function modules with the same functions in the same function group but that are not used by SAP-specific programs.
The temporary quantity assignments are written to the liveCache using a second database connection and are committed immediately. This ensures that they are immediately visible for parallel transactions but this also means that they are not automatically deleted during a rollback. The "task handler" is available for an almost automatic deletion of quantity assignments. The task handler is triggered as soon as the RFC connection between the calling system and the SCM is (unexpectedly) ended. It deletes all quantity assignments written in the transaction, but it cannot recuperate the non-persistent quantity assignments that were implicitly deleted in the transaction. Terminations that do not break off the RFC connection (for example a dump in the SAP GUI) cannot be caught by the SCM system.
Once a transaction is terminated successfully, the task handler must be deregistered. This is done by calling either "BAPI_APOATP_INITIALIZE" or "BAPI_APO_TASKHANDLE_DEREGISTER". Any terminations in the calling transaction after this event cannot be caught by the SCM system.
The calling transaction is also responsible for removing the relevant quantity assignments again. If the transaction terminated successfully, this can be done either by calling "/SAPAPO/CIF_GEN_TID_INBOUND" using CIF or "BAPI_APOATP_REMOVE_TMP_OBJECTS" directly using RFC. If there is a late rollback (for example because of an update termination) the deletion can only take place using "BAPI_APOATP_REMOVE_TMP_OBJECTS".
Up to SCM 4. 1, the attempt to delete quantity assignments may fail if the anchor object of the quantity assignment in the liveCache is currently locked by another transaction. A failed deletion attempt by the task handler cannot be repeated. A failed deletion attempt using CIF ensures that a tRFC hangs with the status "errors" and this can be restarted manually using transaction SM58 or automatically by report ???. A failed deletion attempt using "BAPI_APOATP_REMOVE_TMP_OBJECTS" returns an error message to the calling application.
- 10. What technical changes have been made to quantity assignments between releases and why?
Up to and including SCM 4. 0, temporary quantity assignments were also protected by an enqueue lock on the anchor object. Since, for technical reasons, the task handler cannot consider an enqueue lock, and since it can be very difficult to get simultaneous locks for all anchors in documents with many items, as of SCM 4.1 (Note 780510), we have removed the enqueue lock for temporary quantity assignments in the product availability check.
Instead, we introduced a repeat mechanism which allows for a repeated partial deletion. This repeat mechanism has only been used efficiently in the CIF call since Note 960279 (SCM 4.1) or 813546 (lower releases).
In SCM 5.0 the administration objects in the liveCache are completely parallel, with the result that a technical lock in the liveCache is no longer possible.
- 11. What are active, passive and aggregated quantity assignments?
As part of the multi-level ATP check for APO 3.1, a new status for quantity assignments was introduced, which is referred to as the type of a quantity assignment. There are four different types in total: active, preactive, passive and prepassive quantity assignments.
- Active quantity assignments are those assignments used up to and including APO 3.0, in other words, quantity assignments known to date.
- Passive quantity assignments are required for reservations at component level (dependent requirements) in the multi-level ATP check. All passive quantity assignments are aggregated and available as aggregated quantity assignments in the liveCache. These aggregated quantity assignments are read by parallel checks and they reserve the necessary requirements and confirmations at component level. The passive quantity assignments themselves no longer reserve any quantities, but exist for information purposes only, since their aggregates lock. Hence the name 'passive'. They are deleted if the ATP tree structures generated by the multi-level ATP check is converted to PPDS planning objects.
- Prepassive quantity assignments are written online for the components during the multi-level ATP check. When the order is saved, they are converted into passive quantity assignments and aggregated. Prepassive quantity assignment have an 'active' function, in that they do reserve quantities, unlike the passive quantity assignments described above.
- Preactive quantity assignment are written online during the multi-level ATP check and converted into active quantity assignments when the order is saved. While they have a 'passive' nature because they do not reserve any quantities themselves, they are not aggregated. Preactive quantity assignments are required to release any excess quantity locked by the order at the final material level, so they are always preceeded with a minus sign.
For example: A sales order for 100 pieces of a final material is created and checked at several levels. At the final material level, 40 pieces are confirmed directly by stock, while the remaining 60 can be produced. The customer requirement now receives the entire confirmation of 100 for the final material and is thus updated as such when saved. However, this means that the sales order reserves 100 pieces of the final material itself, which is incorrect because only 40 were confirmed at the final material level and only these may be reserved. For this reason, a preactive quantity assignment for -60 is written for the final material. As a result, only the total of 40 pieces is locked for parallel checks.
- 12. Why are the quantity assignments inconsistent and incorrect after a liveCache crash followed by a liveCache recovery? How can the inconsistencies be eliminated?
This can only occur with APO 3.0 and a liveCache version lower than 7.4. Note 435827 provides a detailed description of the causes and the procedure for cleaning up the inconsistencies.
As of liveCache Version 7.4, the liveCache handles data backup and recovery, so errors of this type should no longer occur.
-
Header Data
| Release Status: | Released for Customer | |||||||||||||||||||||||||||||||||||||||||
| Released on: | 02.10.2006 18:15:26 | |||||||||||||||||||||||||||||||||||||||||
| Priority: | Recommendations/additional info | |||||||||||||||||||||||||||||||||||||||||
| Category: | FAQ | |||||||||||||||||||||||||||||||||||||||||
| Primary Component: | SCM-APO-ATP Global Available-to-Promise Affected Releases
Related Notes |
No comments:
Post a Comment