Summary
Symptom
Planning runs of one or several SAP SCM / APO applications (e.g. PP/DS MRP, PP/DS-Heuristc, PP/DS-Optimizer, CTM, SNP-Heuristic, SNP-Optimizer, SNP Deployment, SNP TLB) are scheduled in parallel to data transfer from SAP ERP (R/3) to SAP SCM / APO via the Core Interface (CIF).
Planning runs or CIF-updates report (locking) errors or planning results or CIF-updates are inconsistent or incomplete.
These errors can be caused by lock collisions because CIF and a planning run might change the same data (in most cases the same order) concurrently.
Other terms
CTM planning run, SNP heuristic, MRP planning run, Optimizer run, lock errors, stop queues, PP/DS planning run, ATP check
Reason and Prerequisites
Same data (mainly orders) is changed concurrently by CIF and a SCM / APO planning run.
From a technical perspective, in APO in most cases a lock collision will occur in liveCache. Each transaction has to acquire a liveCache lock for each object which has to be changed or deleted by that transaction. The liveCache locks are somehow similar to conventional database locks. Most planning runs and CIF-updates are running in a so-called "transactional simulation". Changes are done temporarily within such a transactional simulation in liveCache. Within a transactional simulation lock collisions can not occur, i.e. several parallel transactions can change an object simultaneously. After all relevant changes are done the application program triggers a so-called "merge" of the transactional simulation. This step merges all temporary changes performed within the transactional simulation into the real (operative) data. To do so, the merge has to acquire a liveCache lock for each object which has to be changed or deleted within that merge. The merge acquires all liveCache locks right at the beginning of the merge. If one or several objects are locked by parallel transactions (usually by parallel merges) the merge will wait up to 20 seconds for these locks. If all needed locks are released within that time the merge starts to update, delete or create liveCache objects as they have been updated, deleted or created during the transactional simulation. If the merge can not acquire all needed locks it terminates and returns an error to the calling application (CIF or a planning run or any other APO transaction.)
Instead of merging a transactional simulation alternatively it could also be deleted. In that case all changes during the transactional simulation are discarded.
If a merge runs into a lock collision then the merge could be restarted (several times) as part of a retry-logic, as implemented in CIF, for instance. If after several retries the merge still can not acquire all locks the entry will remain in the CIF queue showing an error.
Planning runs usually do not have such a retry-logic. If the merge of a planning run can not acquire all needed locks the planning run might terminate completely or it might skip one object (like a product-location-combination) and it will report an error.
Solution
There are different solutions depending on what kind of scenarios / applications are run in SCM / APO. Whether which scenario is used intensive testing is recommended to guarantee expected behaviour. As there are too many scenarios, combinations of scenarios, use cases and configurations it is impossible to describe a detailed solution for any process in SCM / APO. Therefore, this note provides for each APO application just the most important aspects concerning a parallel processing of CIF updates and planning heuristics:
A change of master data might lead to lock collisions with CIF updates as some changes to master data will cause changes to transactional data. Examples are the change of a resource calendar or the change of a resource type. Changing a PPM will not interfere with CIF updates if this change will not result in an immediate re-explosion of the corresponding production orders. Nevertheless, it is not recommended to change a PPM in parallel to a planning run because this might lead to unreasonable or even inconsistent planning results. This becomes obvious by considering a case where a MRP run reads several times a PPM which is changed or even deleted in between.
This example shows why in general, it is not recommended to change master data (neither in APO nor via CIF) in parallel to any planning run. Only the creation of new master data in parallel to planning runs should, in general, not cause any issues.
It is recommended to stop CIF while executing a copy of planning versions (Reports /SAPAPO/VERSION_COPY_PAR und /SAPAPO/VERSION_COPY_TRANS). The following BADIs are offered to control the CIF process while copying
Further information can be found in note 519014.
As no data of DP is send from SAP ERP (R/3) to SCM / APO no locking issues will occur when DP planning runs are scheduled concurrently to CIF transfers.
However when the DP forecast is released to Supply Network Planning and in parallel the forecast is updated or a sales order transfer via CIF triggers forecast consumption then locking issues can occur during the forecast release.
As a result the forecast release adds a corresponding error message into the application log. Then the location product where the locking occurred is skipped and afterwards the forecast release continues with the next location product.
Please note that there is no functionality available to automatically restart the forecast release only for those location products where locking (or other) issues occurred. To resolve the incomplete forecast release either a manual selection of the failed location products is necessary or a restart with the complete selection of location products.
An ATP-check itself will not lead to any locking problems even if a planning run is carried out in parallel. However, SAP does NOT recommend using CTP or MATP with "recreation of receipt elements" during that check. Saving the document which carried out an ATP-check could potentially lead to a problem, if a multi-level ATP-check (incl. RBA-STO, consolidation & subcontracting) was carried out and the ATP-tree is converted immediately or "recreation of receipt elements" was active. Additionally, SAP does not recommend executing the following batch processes in parallel to a planning run:
Explanation: The scenarios mentioned above could result in the creation, change or deletion of their corresponding receipt elements (planned orders / purchase requisitions / stock transfer requisitions) including their fixed pegging relations. A planning run might touch the very same orders and depending on the duration of the process, lock-collisions might occur.
Remark: Changing or deleting existing documents is generally more critical than creating new ones. Locking errors often occur randomly, so it could easily happen that all ATP-processes are executed smoothly, although an order change was triggered by a parallel planning process. Please be aware of the fact, that in case of parallel order manipulation neither the results of the planning run nor the result of the parallel ATP processes might be sensible anymore from a business point of view.
Example:
PP/DS is re-planning existing production and planned orders taking into account their current constraints. This will lead to a change of planned input and output dates and quantities. The newly calculated dates and quantities however will not be visible to parallel processes like BOP until the planning has finished and is merging the result to the active version. So the parallel BOP would have calculated its confirmations based on old, outdated data. Its result is meaningless, although NO lock collision occurred!
Solution approach:
Avoiding these incoherent results especially between BOP and planning runs should be possible with a reasonable effort by just selecting the worklists in both applications in a sensible, non-overlapping way; or even simpler by running the BOP after the planning functions have finished their tasks. Additionally the ATP-check (online or BOP) is uncritical when only taking into account receipt elements which are not supposed to be touched by planning applications in SCM anymore. So a straight forward ATP-check taking into account stock, advanced shipping notifications, purchase orders, released production orders and released process orders only, should neither lead to locking collisions nor to incoherent results.
Purchase requisitions and planned orders should not be "updated" via CIF during planning runs of PP/DS.
Changes to Planned/Production orders during parallel planning runs in PP/DS -
In general, we do not recommend online changes in R/3 when doing parallel planning run in APO. Please read note 575624 for more details.
Additionally online changes from R/3 for in-house production orders can cause the below effects on existing orders:
So if a planning is happening at the same time, the outcome of the planning run can be invalidated due to the above changes. The liveCache locking concept is the same as explained in the top section of this note. CIF has retry mechanism if it fails to get a lock. Even if this fails, the queue ends up with error.
If an R/3 confirmation happens at the same time as the APO planning run, the R/3 confirmation will always over-ride the changes done by the planning run. If the APO planning run tries to do the change on the same object that was confirmed, then an error will be raised to the user.
If simulation versions are merged in PP/DS the system might not transfer all the order changes that you made in APO. This is due to parallel changes in R/3 or in the ECC system.
If you want as many of your changes in APO as possible to be transferred then refer to note 1235278 for further details.
CIF updates of orders
Depending on the settings for 'Delete Mode' in the CTM profile, no orders or only orders which are not fixed will be deleted.
CTM treats orders that are transferred via CIF as fixed, so it will not lead to any locking problems with respect to CIF updates of orders.
CIF updates of master data
There are no known locking issues for master data changes in parallel to a CTM run. Nevertheless, theoretically order creation may fail due to locked product-location combinations or resource calendars, but the possibility for that to happen is very low.
Depending on the customizing, CTM logs errors or stops execution, there is no retry logic implemented in CTM.
CTM reads in all necessary master and transactional data at the beginning of the plannung run.
If either data is changed parallel to a CTM run, the result might not be consistent to the new situation and, if CTM is to create fixed pegging relationships, log entries for pegging errors may occur. If, for example, the quantity of a customer order is reduced during a CTM run, only the remaining quantity of a planned order is fixed pegged to the customer order.
In order to avoid locking issues and subsequent application failures during the SNP heuristic planning run the CIF should not update orders which are created, changed or deleted by the SNP planning run. These are orders such as SNP planned order, purchase requisition, stock transfer purchase requisition, SNP scheduling agreements or subcontracting orders.
SNP planning stores the planning result in packages of several orders. The package size and structure is depending on the used SNP planning application, e.g. SNP heuristics creates order packages per location product and order type. In case a locking situation occurs, SNP planning uses a retry mechanism to resolve the locking. When the limited number of retry attempts fails, then the complete order package which includes the lock is discarded and a corresponding error message is recorded in the application log. SNP planning will then continue with the next order package. The prerequisite for storing the planning result in order packages with retry attempts is to use the transactional simulation for planning runs, which is the default setting.
The prerequisite for the retry mechanism is that SNP planning is executed in batch mode.
There are no known locking issues for master data changes in parallel to an SNP planning run. Nevertheless changing master data in parallel to SNP planning can lead to useless planning result with regards to the changed master data and is therefore not recommended. Especially the SNP optimizer reads all necessary master data at the beginning of the planning run and therefore the planning result can be completely outdated when master data is changed during the planning run.
Furthermore when new master data is created which is subsequently considered by a parallel SNP planning run then errors can occur in case time series key figures are used for the new master data in the corresponding SNP Planning Area. The errors will occur when the time series key figures are read by the planning run but not yet created for the new master data.
Also when transactional data is changed in parallel to a planning run, the planning result can be inconsistent or useless after the change when the planning considered the transactional data before the change by CIF happened. Especially when the SNP Optimizer is used then the impact to the planning result can be significant, since the complete supply and demand data is retrieved at the beginning of the planning run.
To avoid inconsistencies in planning results due to outdated data it is recommended not to change the same data by parallel jobs. This can be achieved e.g. by using corresponding selections for the SNP planning runs.
Transactional data for which potentially collisions with CIF may occur are: purchase orders, purchase order requisitions, delivery schedules, planned orders, and scrap orders.
SPP applications like forecasting, inventory planning, DRP and deployment access transactional data via the so called transactional data layer (TDL). When CIF is transferring transactional data and SPP applications try to access this data via TDL, then an exception is raised by TDL. The SPP applications catch this exception and write an error message to the application log. The location(product)s for which such an exception occur are handled as not planned. This means triggers for the location(product)s aren't deleted and SPP will try to plan the location(product)s in the next planning run again.
SPP applications access master data via PSM data managers. The PSM data managers call MDL. The underlying master data access modules return an error message in case of a collision. MDL propagates these error messages to PSM. When PSM receives an error message while writing master data, it stops the current processed package and rolls all data back. A package is a subset of a PSM selection, which is processed at once. This means triggers for all location(product)s of the package aren't deleted and SPP will try to plan the location(product)s in the next planning run again.
Collisions can occur for product and location product master data which is written by SPP applications like Forecasting, Inventory Planning, Deployment, Surplus and Obsolescence and the Planning Mode Determination.
If the transfer of changes in ERP (R/3) via the CIF interface and APO is not locked consistent planning results can only be guaranteed in regards to the initial data at planning start.
If the transfer of changes in ERP (R/3) via the CIF interface and APO is not locked warning messages in the log of the planning run can occur (e.g. master data changes via CIF during planning runs, orders cannot be considered anymore).
In order to avoid inconsistent planning results it is possible to create different CIF integration models with different data objects (e.g. separate models for master and transactional data objects, separate models for different transactional data objects). However you should consider that the re-activation of the integration model automatically trigger a new initial data transfer.
You can block the transfer of specific transaction data. You should be aware that the queue names are automatically generated by CIF so there is no way to manually or via BAdI change the queue names in order to be able to assign queue names which can be used to differentiate the data objects by their content, eg. Purchase Orders of US would have CFPOUS* and Purchase Orders of Germany have CFPODE*. You can only block the transfer of specific data globally.
Here are some examples:
You can halt all CIF queues that are sent to APO by locking the generic queue
Then neither master nor transactional data is transferred to the APO System. It is also possible to lock the transfer of data changes for only certain master data.
Example: blocking the transfer of material master data changes:
You will find further documentation on the programs RSTRFCI1 and RSTRFCI3 in note 717244.
For all other SCM / APO applications which are not mentioned in this note, please contact SAP.
Planning runs of one or several SAP SCM / APO applications (e.g. PP/DS MRP, PP/DS-Heuristc, PP/DS-Optimizer, CTM, SNP-Heuristic, SNP-Optimizer, SNP Deployment, SNP TLB) are scheduled in parallel to data transfer from SAP ERP (R/3) to SAP SCM / APO via the Core Interface (CIF).
Planning runs or CIF-updates report (locking) errors or planning results or CIF-updates are inconsistent or incomplete.
These errors can be caused by lock collisions because CIF and a planning run might change the same data (in most cases the same order) concurrently.
Other terms
CTM planning run, SNP heuristic, MRP planning run, Optimizer run, lock errors, stop queues, PP/DS planning run, ATP check
Reason and Prerequisites
Same data (mainly orders) is changed concurrently by CIF and a SCM / APO planning run.
From a technical perspective, in APO in most cases a lock collision will occur in liveCache. Each transaction has to acquire a liveCache lock for each object which has to be changed or deleted by that transaction. The liveCache locks are somehow similar to conventional database locks. Most planning runs and CIF-updates are running in a so-called "transactional simulation". Changes are done temporarily within such a transactional simulation in liveCache. Within a transactional simulation lock collisions can not occur, i.e. several parallel transactions can change an object simultaneously. After all relevant changes are done the application program triggers a so-called "merge" of the transactional simulation. This step merges all temporary changes performed within the transactional simulation into the real (operative) data. To do so, the merge has to acquire a liveCache lock for each object which has to be changed or deleted within that merge. The merge acquires all liveCache locks right at the beginning of the merge. If one or several objects are locked by parallel transactions (usually by parallel merges) the merge will wait up to 20 seconds for these locks. If all needed locks are released within that time the merge starts to update, delete or create liveCache objects as they have been updated, deleted or created during the transactional simulation. If the merge can not acquire all needed locks it terminates and returns an error to the calling application (CIF or a planning run or any other APO transaction.)
Instead of merging a transactional simulation alternatively it could also be deleted. In that case all changes during the transactional simulation are discarded.
If a merge runs into a lock collision then the merge could be restarted (several times) as part of a retry-logic, as implemented in CIF, for instance. If after several retries the merge still can not acquire all locks the entry will remain in the CIF queue showing an error.
Planning runs usually do not have such a retry-logic. If the merge of a planning run can not acquire all needed locks the planning run might terminate completely or it might skip one object (like a product-location-combination) and it will report an error.
Solution
There are different solutions depending on what kind of scenarios / applications are run in SCM / APO. Whether which scenario is used intensive testing is recommended to guarantee expected behaviour. As there are too many scenarios, combinations of scenarios, use cases and configurations it is impossible to describe a detailed solution for any process in SCM / APO. Therefore, this note provides for each APO application just the most important aspects concerning a parallel processing of CIF updates and planning heuristics:
- Prerequisites for some functions of individual APO applications where no locking issue can occur.
- Behavior of individual APO applications in case a locking issue occurs.
- Recommendations for individual APO applications to avoid locking issues in some specific areas.
- 1. Master Data
A change of master data might lead to lock collisions with CIF updates as some changes to master data will cause changes to transactional data. Examples are the change of a resource calendar or the change of a resource type. Changing a PPM will not interfere with CIF updates if this change will not result in an immediate re-explosion of the corresponding production orders. Nevertheless, it is not recommended to change a PPM in parallel to a planning run because this might lead to unreasonable or even inconsistent planning results. This becomes obvious by considering a case where a MRP run reads several times a PPM which is changed or even deleted in between.
This example shows why in general, it is not recommended to change master data (neither in APO nor via CIF) in parallel to any planning run. Only the creation of new master data in parallel to planning runs should, in general, not cause any issues.
It is recommended to stop CIF while executing a copy of planning versions (Reports /SAPAPO/VERSION_COPY_PAR und /SAPAPO/VERSION_COPY_TRANS). The following BADIs are offered to control the CIF process while copying
- /SAPAPO/MVM_COPY1
- /SAPAPO/MVM_COPY2
- /SAPAPO/MVM_COPY5
- /SAPAPO/MVM_COPY6
Further information can be found in note 519014.
- 2. Demand Planning (DP)
As no data of DP is send from SAP ERP (R/3) to SCM / APO no locking issues will occur when DP planning runs are scheduled concurrently to CIF transfers.
However when the DP forecast is released to Supply Network Planning and in parallel the forecast is updated or a sales order transfer via CIF triggers forecast consumption then locking issues can occur during the forecast release.
As a result the forecast release adds a corresponding error message into the application log. Then the location product where the locking occurred is skipped and afterwards the forecast release continues with the next location product.
Please note that there is no functionality available to automatically restart the forecast release only for those location products where locking (or other) issues occurred. To resolve the incomplete forecast release either a manual selection of the failed location products is necessary or a restart with the complete selection of location products.
- 3. Global ATP
- ATP checks can be executed in parallel to planning runs.
- It is not recommended to use the following ATP-related functions in parallel to all planning runs which create, change or deletes order documents:
- Backorder processing (BOP) in update mode
- Capable-to-Promise (CTP) in an ATP-check
- Multi-level-ATP (MATP) check with recreation of receipt elements
- Converting ATP-Trees: Neither using the conversion-batch-report nor starting immediate online conversion, during sales order update.
(ATP-Trees are used when checking availability with the following advanced methods: Multi-Level-ATP, Rules-Based-ATP triggered stock transfer [RBA-STO], Consolidation and Subcontracting)
An ATP-check itself will not lead to any locking problems even if a planning run is carried out in parallel. However, SAP does NOT recommend using CTP or MATP with "recreation of receipt elements" during that check. Saving the document which carried out an ATP-check could potentially lead to a problem, if a multi-level ATP-check (incl. RBA-STO, consolidation & subcontracting) was carried out and the ATP-tree is converted immediately or "recreation of receipt elements" was active. Additionally, SAP does not recommend executing the following batch processes in parallel to a planning run:
- Back-Order-Processing (BOP) in update-mode. This seems to be a very hard constraint, but it is especially true for the critical processes described above. For all the other ATP-processes locking collisions should not occur, nevertheless SAP does not recommended BOP in parallel to a planning run in order to avoid incoherent results between ATP and planning processes as described in the remark below. (BOP in simulation mode is supposed to be uncritical) The process "event driven quantity assignment" (EDQA) is triggering a small BOP in update mode, too. It is therefore another theoretical candidate for a critical process. However, it is extremely unlikely that it really causes troubles.
- ATP-tree conversion batch-job.
Explanation: The scenarios mentioned above could result in the creation, change or deletion of their corresponding receipt elements (planned orders / purchase requisitions / stock transfer requisitions) including their fixed pegging relations. A planning run might touch the very same orders and depending on the duration of the process, lock-collisions might occur.
Remark: Changing or deleting existing documents is generally more critical than creating new ones. Locking errors often occur randomly, so it could easily happen that all ATP-processes are executed smoothly, although an order change was triggered by a parallel planning process. Please be aware of the fact, that in case of parallel order manipulation neither the results of the planning run nor the result of the parallel ATP processes might be sensible anymore from a business point of view.
Example:
PP/DS is re-planning existing production and planned orders taking into account their current constraints. This will lead to a change of planned input and output dates and quantities. The newly calculated dates and quantities however will not be visible to parallel processes like BOP until the planning has finished and is merging the result to the active version. So the parallel BOP would have calculated its confirmations based on old, outdated data. Its result is meaningless, although NO lock collision occurred!
Solution approach:
Avoiding these incoherent results especially between BOP and planning runs should be possible with a reasonable effort by just selecting the worklists in both applications in a sensible, non-overlapping way; or even simpler by running the BOP after the planning functions have finished their tasks. Additionally the ATP-check (online or BOP) is uncritical when only taking into account receipt elements which are not supposed to be touched by planning applications in SCM anymore. So a straight forward ATP-check taking into account stock, advanced shipping notifications, purchase orders, released production orders and released process orders only, should neither lead to locking collisions nor to incoherent results.
- 4. Planning runs of PP/DS
Purchase requisitions and planned orders should not be "updated" via CIF during planning runs of PP/DS.
Changes to Planned/Production orders during parallel planning runs in PP/DS -
In general, we do not recommend online changes in R/3 when doing parallel planning run in APO. Please read note 575624 for more details.
Additionally online changes from R/3 for in-house production orders can cause the below effects on existing orders:
- De-allocate the orders in APO.
- Cause loss of scheduling information (i.e. dates/times can change).
- It can also firm the orders.
So if a planning is happening at the same time, the outcome of the planning run can be invalidated due to the above changes. The liveCache locking concept is the same as explained in the top section of this note. CIF has retry mechanism if it fails to get a lock. Even if this fails, the queue ends up with error.
If an R/3 confirmation happens at the same time as the APO planning run, the R/3 confirmation will always over-ride the changes done by the planning run. If the APO planning run tries to do the change on the same object that was confirmed, then an error will be raised to the user.
If simulation versions are merged in PP/DS the system might not transfer all the order changes that you made in APO. This is due to parallel changes in R/3 or in the ECC system.
If you want as many of your changes in APO as possible to be transferred then refer to note 1235278 for further details.
- 5. Capable-To-Match (CTM)
CIF updates of orders
Depending on the settings for 'Delete Mode' in the CTM profile, no orders or only orders which are not fixed will be deleted.
CTM treats orders that are transferred via CIF as fixed, so it will not lead to any locking problems with respect to CIF updates of orders.
CIF updates of master data
There are no known locking issues for master data changes in parallel to a CTM run. Nevertheless, theoretically order creation may fail due to locked product-location combinations or resource calendars, but the possibility for that to happen is very low.
Depending on the customizing, CTM logs errors or stops execution, there is no retry logic implemented in CTM.
CTM reads in all necessary master and transactional data at the beginning of the plannung run.
If either data is changed parallel to a CTM run, the result might not be consistent to the new situation and, if CTM is to create fixed pegging relationships, log entries for pegging errors may occur. If, for example, the quantity of a customer order is reduced during a CTM run, only the remaining quantity of a planned order is fixed pegged to the customer order.
- 6. SNP heuristics / SNP optimizer
In order to avoid locking issues and subsequent application failures during the SNP heuristic planning run the CIF should not update orders which are created, changed or deleted by the SNP planning run. These are orders such as SNP planned order, purchase requisition, stock transfer purchase requisition, SNP scheduling agreements or subcontracting orders.
SNP planning stores the planning result in packages of several orders. The package size and structure is depending on the used SNP planning application, e.g. SNP heuristics creates order packages per location product and order type. In case a locking situation occurs, SNP planning uses a retry mechanism to resolve the locking. When the limited number of retry attempts fails, then the complete order package which includes the lock is discarded and a corresponding error message is recorded in the application log. SNP planning will then continue with the next order package. The prerequisite for storing the planning result in order packages with retry attempts is to use the transactional simulation for planning runs, which is the default setting.
The prerequisite for the retry mechanism is that SNP planning is executed in batch mode.
There are no known locking issues for master data changes in parallel to an SNP planning run. Nevertheless changing master data in parallel to SNP planning can lead to useless planning result with regards to the changed master data and is therefore not recommended. Especially the SNP optimizer reads all necessary master data at the beginning of the planning run and therefore the planning result can be completely outdated when master data is changed during the planning run.
Furthermore when new master data is created which is subsequently considered by a parallel SNP planning run then errors can occur in case time series key figures are used for the new master data in the corresponding SNP Planning Area. The errors will occur when the time series key figures are read by the planning run but not yet created for the new master data.
Also when transactional data is changed in parallel to a planning run, the planning result can be inconsistent or useless after the change when the planning considered the transactional data before the change by CIF happened. Especially when the SNP Optimizer is used then the impact to the planning result can be significant, since the complete supply and demand data is retrieved at the beginning of the planning run.
To avoid inconsistencies in planning results due to outdated data it is recommended not to change the same data by parallel jobs. This can be achieved e.g. by using corresponding selections for the SNP planning runs.
- 7. Service Parts Planning (SPP)
Transactional data for which potentially collisions with CIF may occur are: purchase orders, purchase order requisitions, delivery schedules, planned orders, and scrap orders.
SPP applications like forecasting, inventory planning, DRP and deployment access transactional data via the so called transactional data layer (TDL). When CIF is transferring transactional data and SPP applications try to access this data via TDL, then an exception is raised by TDL. The SPP applications catch this exception and write an error message to the application log. The location(product)s for which such an exception occur are handled as not planned. This means triggers for the location(product)s aren't deleted and SPP will try to plan the location(product)s in the next planning run again.
SPP applications access master data via PSM data managers. The PSM data managers call MDL. The underlying master data access modules return an error message in case of a collision. MDL propagates these error messages to PSM. When PSM receives an error message while writing master data, it stops the current processed package and rolls all data back. A package is a subset of a PSM selection, which is processed at once. This means triggers for all location(product)s of the package aren't deleted and SPP will try to plan the location(product)s in the next planning run again.
Collisions can occur for product and location product master data which is written by SPP applications like Forecasting, Inventory Planning, Deployment, Surplus and Obsolescence and the Planning Mode Determination.
- 8. CIF
If the transfer of changes in ERP (R/3) via the CIF interface and APO is not locked consistent planning results can only be guaranteed in regards to the initial data at planning start.
If the transfer of changes in ERP (R/3) via the CIF interface and APO is not locked warning messages in the log of the planning run can occur (e.g. master data changes via CIF during planning runs, orders cannot be considered anymore).
In order to avoid inconsistent planning results it is possible to create different CIF integration models with different data objects (e.g. separate models for master and transactional data objects, separate models for different transactional data objects). However you should consider that the re-activation of the integration model automatically trigger a new initial data transfer.
You can block the transfer of specific transaction data. You should be aware that the queue names are automatically generated by CIF so there is no way to manually or via BAdI change the queue names in order to be able to assign queue names which can be used to differentiate the data objects by their content, eg. Purchase Orders of US would have CFPOUS* and Purchase Orders of Germany have CFPODE*. You can only block the transfer of specific data globally.
Here are some examples:
- CFSTK* Stocks
- CFSLS* Sales orders and deliveries
- CFPO* Purchase requisitions and purchase orders
- CFPLO* Planned and production orders
You can halt all CIF queues that are sent to APO by locking the generic queue
- CF*
Then neither master nor transactional data is transferred to the APO System. It is also possible to lock the transfer of data changes for only certain master data.
Example: blocking the transfer of material master data changes:
- CFMAT*
You will find further documentation on the programs RSTRFCI1 and RSTRFCI3 in note 717244.
- 9. Other SCM / APO Applications
For all other SCM / APO applications which are not mentioned in this note, please contact SAP.
Header Data
| Release Status: | Released for Customer |
| Released on: | 22.09.2008 18:13:24 |
| Master Language: | English |
| Priority: | Recommendations/additional info |
| Category: | Consulting |
| Primary Component: | SCM-APO-INT Interfaces |
Affected Releases
|
Related Notes
