Product Availability Check (PAC)

view

Checking the availability of a product based on the ATP quantity. The ATP quantity is calculated based on storage stock, planned receipts and planned issues. Parameters for PAC are defined mainly in the check instruction, the ATP group and the check control. You can specify the following check parameters:

Cumulation (/SAPAPO/V_ATP01-ONVBA) How to deal with shortages (no cumulation = no shortage check) where to customize: ATP group (spro: APO > gATP > PAC > Maintain ATP Group)

o o o o

Check control various customizing: scope of check (what receipts to check) consider past receipts? (use receipts with due dates in the past for confirmation?) check horizon? (any amount can be procured after a certain amount of days?) check sublocation or batches? (how detailed a check should be) where to customize: ATP group (spro: APO > gATP > PAC > Maintain Check Control) business event + ATP group => check control

ATP check using the time series vs. pegging network To do this characteristic-based PAC, the production type in the check mode has to be set to "characteristic evaluation" whether to create internal deltas/TQAs (/SAPAPO/V_ATP00-ACENQ) whether to create temporary quantity assignments (TQAs) to keep track of requirements in a sales order in process/not yet saved

Product Allocation
With PAL you can allocate products for specific customers or regions depending on the period. If you use product allocations in situations in which a product is in short supply, you can avoid allocating the entire available quantity to the first customer, which either delays the confirmation of subsequent sales orders, or makes confirmation impossible. In Product Allocation delivery dates and quantities will be checked against the allocation quantities in certain periods. If delivery proposal will be accepted, the corresponding allocation quantities will be reduced with the delivery quantity.

Transactions

/n/SAPAPO/AC42 to get overview of Product Allocation Situation (needs: product, location, PAL group, PAL object) /n/SAPAPO/ATPCQ_CHECK to check the customizing (needs: PAL procedure) /n/SAPAPO/ATPQ_CHKCUST to check product allocation assignments for one sales order

Relevant notes (login required)

676128 Product allocations: Product allocation assignment check

Labels parameters

Edit

Add Labels

http://w iki.sdn.sa

117506865

SCM

Forecast Check
You execute a check against the forecast if you want to know if enough planned independent requirements are available for the incoming sales orders.

Online Help
http://help.sap.com/saphelp_scm50/helpdata/en/26/c2d63b18bc7e7fe10000000a114084/frameset.htm under "Basic Methods of the Availability Check" --> "Checking Against the Forecast"

Relevant notes (login required)

159937 Checklist for requirements consumption and reduction in APO 568506 Collective consulting note on consumption of forecasts 538046 Checklist for transferring planned independent requirement 47045 Tip check list f. indep.reqs.reduc./consmptn probs

Rules-Based ATP Check

The rule-based availability check is an iterative process, meaning that each step defines the subsequent check step based on the rules saved in the system. Possible steps:

Determining alternative locations (location determination), Determining alternative products (product substitution), Determining alternative production process models (PPM). Searching for substitutions will be stopped if an acceptable result of the check is available. Some possibilities with RBA:

Only one substitution is also possible. Production can be triggered in alternative locations. Stock transfer can be triggered in alternative locations.

Transactions

/SAPAPO/RBA04: Integrated Rule Maintenance /SAPCND/AO11: Create Rule Determination

Relevant notes (login required)

1085147 TAPA/TAN - when is a sub-item created?

502177 700386

Integration: Rules-based ATP in sales FAQ: Rules-based ATP

Capable-To-Promise (CTP)
You can configure if Production Planning and Detailed Scheduling is called automatically when a product is not completely available. If the former product availability check fails, GATP can trigger production directly. In this case corresponding method in PP/DS will be called which creates planned orders for all ressources in PPM and also checks the availability of the components. The result will be transferred to ATP which makes the neccesery changes in the sales order (after accept the delivery proposal). APO makes changing in ATP time series and PP/DS transfers the simulated planned order to R/3.

Relevant notes (login required)

426563 CTP: Settings, system behavior and performance (docu) 601813 FAQ: Characteristic evaluation in ATP check mode

Multilevel ATP Check (MATP)

MATP will be used in cases when a large part of the value-added activity arises at final assembly. Already at the time of order entry all components will be checked which are necessery for the production of the final product. During MATP an ATP-Tree Structure is getting created during saving of the sales order in the APO-Database and represents the BOM Structure, enhanced with Material/Location substitutions (RBA). Receipt elements are only generated later when the ATP tree structure is converted in PP/DS.

Transactions
/SAPAPO/RRP_ATP2PPDS: Conversion of ATP tree structures to receipt elements

Relevant notes (login required)

480292 Multilevel ATP (documentation) 520432 Consulting note: Determining dates in multi-level ATP 455421 Comparing multi-level ATP and CTP (documentation)

Batch BOP
In Batch Backorder Processing (or backorder processing in the background), items are selected according to specific key fields (using filters) and brought into a processing sequence for the availability check (by means of the sort). The previously confirmed quantities are rejected and an ATP check is carried out for all selected items in the defined sequence. A new date can thereby be determined. The results are always held in a buffer. Depending on the execution mode, the results can be updated afterwards, processed, or rejected later.

Interactive BOP (BOPI):

With interactive backorder processing you can manually redistribute confirmed quantities of one or more products specifically over a quantity of selected requirements. You can call the function directly or use it as a postprocessing function of batch backorder processing. The aim of interactive backorder processing is to manually assign a confirmed quantity to requirements schedule lines. Schedule line dates can be changed, deleted, or created.

Relevant notes (login required)

510912 485085 BOP: Tips & Tricks Backorder processing: New rule evaluation

1623412 First Aid in case of BOP update issues

EDQA (Event-Driven Quantity Assignment)

System should be able to react instantly on positive changes in the stock/requirements situation by distributing the free quantity to backordered sales items waiting to be confirmed. Depending on the events mentioned above, the system has to distribute the quantity according to particular rules: Range of order items that have to be confirmed Sort sequence of selected order items in the range

If all waiting sales orders are confirmed, the still available quantity may have to be deployed to other facilities via push deployment Supporting different Goods receipt status Uses Order Due Lists (ODL) where backorders are stored and filtering and sorting of the sales order items is possible EDQA Process is triggered by activities Change Purchase Order Document Change Sales and Distribution Document Change Stock Data

Selection criteria can be defined for the EDQA Process EDQA triggers via a workflow event an ODL based backorder (BOP) processing can do a Reassignment of Order Confirmations (ROC)

Transactions:
Define Processes for Event-Driven Quantity Assignment (TA /SAPAPO/EDQA_PD) Assign Events of Event-Driven Quantity Assignment (TA /SAPAPO/EDQA_ED)

Processes of Event-Driven Quantity Assignments (TA /SAPAPO/EDQA)

Further informations
http://help.sap.com/saphelp_scm70/helpdata/en/45/8e2c9855de40c0e10000000a1553f7/frameset.htm

Relevant notes (login required)

1130360 EDQA and ODL with sublocation

ODL (Order Due List)

An order due list is a list of the most important orders you have taken that have not been confirmed, or the least important ones that have been confirmed. The systems goal is to confirm the orders that havent been (that are on the ODL), or to potentially de-confirm the ones that have been, if higher priority orders come in for the same product.

Transactions:
Configure Order Due Lists (TA /SAPAPO/ODLC) Process Order Due Lists (TA /SAPAPO/ODL) Display Change Log (TA /SAPAPO/ODL_LOG) Initial ODL Creation / Reorganization (TA /SAPAPO/ODLR)

Further informations
http://help.sap.com/saphelp_scm70/helpdata/en/45/8e2c9855de40c0e10000000a1553f7/frameset.htm

Relevant notes (login required)

1130360 EDQA and ODL with sublocation 1105656 FAQ: Order due lists in SCM

Time and Scheduling Functions

In the Transportation- and Shipment Scheduling the following dates and durations (activities) are used: Dates:

ELDAT (Unloading Date) (only APO) LFDAT (Delivery Date) WADAT (Goods Issue Date) LDDAT (Loading Date) MBDAT (Material Availability Date) TDDAT (Transportation Planning Date)

Activities:

UNLD (Unloading) (only APO) source: conditions TRAN (Transit) source: 1. lane, 2. conditions, 3. dist. LOAD (Loading) source: conditions PICK (Picking) source: conditions LEAD (Planning) source: conditions Generally we have 3 phases during the scheduling: 1. shipping, 2. transportation, 3. receiving

The first is for the activities(and dates) what are carried out in the location-from. The second is for activity what is carried out during the transportation. The third is for the activities(and dates) what are carried out in the location-to. From SCM 4.0:

The shipping calendar of the location-from is used for the 1. phase The calendar of the transportation lane(or route) is used for the 2. phase. The receiving calendar of the location-to is used for the 3. phase.

Transactions

/n/SAPAPO/SCHED_TEST to simulate the scheduling in APO /n/SAPCND/AU13 to check the Scheduling Condition Types /n/SAPAPO/CALENDAR to check the calendar /n/SAPAPO/SCC_TL1 to check the transportation lane

Relevant notes (login required)

547961 FAQ: Shipment and transportation scheduling in R/3 547941 FAQ: Shipment and transportation scheduling in APO 443500 R/3 versus APO: Dates in sales orders and deliveries 526359 Time streams and APO shipment and transportation scheduling

Sales Integration
Sales Integration deals with:

the saving from R/3 to APO of: Quotations, sales orders, contracts, scheduling agreements, normal deliveries, stock transfer deliveries (=Replenishment deliveries), VMI Sales orders, VMI deliveries

the saving from APO to R/3 of: VMI sales orders, sales orders processed by /SAPAPO/BOP several reports: /sapapo/cif_deltareport3 (for sales docs only) = transaction /sapapo/ccr

/sapapo/sdrqcr21 /sapapo/sdorder_del SCM-APO-INT-SLS deals only with the applicative part of the transfer of sales documents. Technical communication problems of the CIF interface or problems with the status of queues (RETRY, SYSFAIL...) belong to the SCM-APO-INT component. The coding of the SCM-APO-INT-SLS component is located on both R/3 and APO side.

Transactions

/n/SAPAPO/SDORDER_DEL to delete obsolete data from LiveCache and APO Database. /n/SAPAPO/SDRQCR21 to check and fix sales documents requirements inconsistencies between R/3 and APO. /n/SAPAPO/CCR - external consistency check for requirement inconsistencies between R/3 and APO Livecache. /n/sapapo/om17 - internal consistency check between Livecache and APO Database.

Relevant notes (login required)

425825 Consistency checks, /sapapo/om17, /sapapo/cif_deltareport 894294 /sapapo/sdorder_del: Performance and advice

Temporary quantity assignments (TQA)

They are used to inform ATP checks executed in parallel transactions about given confirmations. They are necessary to span the time between the check and the final saving of the confirmation (thru saving the requesting order item). There are internal deltas, which are used to keep track of changes in own transactions and external deltas (or TQAs) which keep track of external transactions.

Frequent problem: Documents with number "<unknown>" in ATP are always temporary quantity assignments. If the order number was known at the time of running the ATP check, the TQA carries the order number, otherwise it carries <unknown>. The TQA carries order number <unknown> until either the item is converted or a new ATP check is executed. The system behaviour should be fine after the deletion of the hanging TQA's

Deletion of TQA-s: You can delete the old assignements with the report /SAPAPO/om_delta_remove_older (via SE38). Alternatively you can delete the TQA's manually. Use transaction /SAPAPO/AC06. You must be careful not to delete quantity assignments that are still required. These vary according to the scenario used.

The CTP temporary requirements are not integrated to either the transaction /SAPAPO/AC06 or to the report /SAPAPO/OM_DELTA_REMOVE_OLDER, like the normal TQA.

Relevant notes (login required)

488725 FAQ: Temporary quantity assignments in Global ATP

1287255 /SAPAPO/ATP 112 when you delete temporary qty assignments

BOP Performance
There are many BOP entries for items that have been ran by BOP either simulation or update. Delete as many as possible BOP runs existing in the system. This will eliminate the entries in tables: /SAPAPO/BOP This you can perform in transaction: /SAPAPO/BOP_DELETE: use it to delete BOP results older than 7 days; if necessary the date can be set even closer to the current date to delete BOP results in status 'U' this status has to be selected explicitely /SAPAPO/BOP_RESULT performance The 'Original Requirements/Confirmation Situation' variant displays the ATP situation BEFORE and AFTER the bop. This situation is stored on the data base table and will never change. The 'Current Requirements/Confirmation Situation' display version will select the AFTER values from another set of data base tables (the passive ATP trees) and compare it to what is currently in Live cache. SAP recommend to use the BOP_RESULT display variant 'original requirement/confirmation situation' for two reasons: 1.) It is much faster since it reads directly from the data base and does not recalculate the change in the confirmation situation item per item 2.) It is more comphrehensible since it always displays the same situation BEFORE and AFTER the BOP

Relevant notes (login required)

635411 Performance: BOP reading filter in APO 519766 Consulting note: Backorder processing results display

ATP log
The availability check process can be logged by activating the ATP application log for error analysis by technically oriented users, developers or consultants. It collects information about customizing settings, the technical and time aspects of the check as well as warnings and errors that occurred. The ATP log should only be switched on for a short time (considerable performance decrease of the system!) and only for specific users. Transactions:

Create ATP log for a user: /SAPAPO/ATPLOG Display the ATP log: /SAPAPO/ATPLOG_DSP Delete ATP Log: /SAPAPO/ATPLOG_DEL Application classes:

BAP: BAPI interface of the APO BOP: Treatment of arrears EAS: Explanation and simulation component EVR: Rule evaluation FCK: Basic method examination against vorplanung PAC: Basic method product liquidity check PAL: Basic method imposition of quotas PAT: Persistente ATP Baumstuktur PRD: Production SCH: Time limitation TQA: temporary quantity allocations TRC: ATP CONTROLLER

Correlation
The correlation is about gathering results from lower level objects to a higher level object in the ATP object structure stored in the memory. This can be done from component groups to the finished product level, and e.g. from substitutions to main item level. Propagation is the other way round, it takes the results of a higher level objects, and updates the related lower level objects' results to correspond to the higher level. Correlation Services: The Correlation Service provides correlation functionality for delivery groups and sales BOMs. Normally this is done during the availability check, but if the caller application needs only new correlation, it can call the Correlation Service. Example: In the Extended Warehouse Management the picking of a KIT fails. One product has less quantity in the warehouse than the needed, so less KIT can be transported. This case the EWM calls the Correlation Service to determine the reduced quantities for the other components.

Third-Party Order Processing

In this process, you do not supply the customer yourself. Instead, you assign another supplier or dealer to deliver the products requested by the customer. In third-party order processing, you can ensure that the requirement is confirmed as quickly as possible without accepting cancellations or backlogs. The following types of third-party order processing are available: Third-party order processing by source determination (TPOP) Third-party order processing by product allocation (TPOPD)

Transactions /SAPAPO/TPOP_POREL Conversion of Planned Purchase orders

/SAPAPO/TPOP_ASSIGN Create product location assignments for the vendors The TPOPD scenario is called as Dealer-to-dealer scenario, as it was developed for car dealers. It is also called as third party order processing with product allocations.

/sapapo/atpq_chkusg - Product allocation assignment check

program name: /SAPAPO/RMQUOT_USAGE_CHECK You can use the report to compare and to correct the product allocation assignment and the incoming orders quantity. The sum of the product allocation assignments of a period is generally equal to the incoming orders quantity in the time series. To make sure that the system has consistent status is of high importance and should therefore be checked on a regular (daily or weekly depending on the number of inconsistencies) basis. This report has to be started online and requires manual interaction to correct inconsistencies. The report is often scheduled in the background, to evaluate the spool lists only. If there are errors, it is started manually. It is strongly recommended to run the report online. It is possible to run this program in the background with an automated update of the checked items using the following workaround: Create a Batch Input for the program /SAPAPO/RMQUOT_USAGE_CHECK via SAP Menu: System -> Services -> Batch Input -> Record (see note 676128 for further details).

Relevant notes (login required)

676128 Product allocation assignment check

/SAPAPO/CCR Comparison-Reconciliation of transaction data

Check consistency between the APO system and one or more dedicated R/3 systems. Inconsistencies may occur if at least one of the systems crashes and cannot be fully recovered again.In the same way, inconsistently deleting CIF queues or unwanted user settings can cause inconsistencies.

Usage:

In background, test mode only. But possible to save the results so that they can be quickly reloaded in foreground and then the fixing of the inconsistencies can be manually done. Iteration functionality allows to quickly recheck that the reported inconsistencies are still inconsistent or repaired It only checks transaction data used in APO (production orders, planned orders, sales orders, stocks and so on). Sometimes, depending on system settings in APO, data changes made in APO are not being transferred synchronously to R/3 (for instance the VMI orders you transfer to R/3). As a result, "false" inconsistencies were being reported (change pointers are still in /sapapo/c5).

You can run the report in parallel by creating variants for the different object types. Make sure that the different objects selected do not overlap.

Relevant notes (login required)

425825 Consistency checks, /sapapo/om17, /sapapo/ccr

/SAPAPO/SDRQCR21- Correction report for delivery req. and sales req.

This report corrects incorrect sales order and delivery (requirements) in SAP R/3 / ECC and SAP APO/SCM.

checks precisely the SD order tables doesn't check inactive integration models. Therefore, it is not a perfect substitute for /SAPAPO/CIF_DELTAREPORT3 schedule the report /SAPAPO/SDRQCR21 on a weekly basis can't be run during operation hours, its long runtime might be a bottleneck should be used only you have reliable VBBE table The following improvements were integrated into /SAPAPO/SDRQCR21 with note 987299: 1. The possibility to check specific order numbers or order items. 2. Iteration The report first selects orders in SCM, then in R/3 and compares the selected orders. A new check is triggered in case of inconsistencies until the inconsistencies disappear or the maximum number of iterations is reached. 3. Table /SAPAPO/OBREF The report can find and correct a wrong document flow including document flow from Stock Transfer Orders to deliveries. 4. More accurate evaluation and correction of Product Allocation Assignments. 5. For performance reasons when selecting Product Allocation, it is possible to exclude fully delivered orders and/or only to check Sales Orders or Stock Transfer Orders. 6. Redesign of the requirement recompilation If you use the option to build requirements from the document flow, a very long runtime may occur and the requirements are re-created without document blocks. Therefore, inconsistencies may occur during the operation. With the new version of the report for which notes 998102 and 1023543 are prerequisites, a new logic for recompiling requirements is introduced. The following new switches are available which allow you to use the report during system operation. The first Flag 'Lock documents...' sets a document block if the requirements from table VBBE are rewritten in the R/3 system. This prevents the document from being changed at the same time. The second flag writes a planning file entry (net change per material/plant) in the R/3 system if the requirement situation has changed. The next MRP reads this and plans accordingly.

Relevant notes (login required)

444641 Correction of incorrect sales order requirements with APO 987299 Report /sapapo/sdrqcr21: Functional enhancements

/SAPAPO/SDORDER_DEL - ATP:Delete SD orders from database

This report can be used to delete old sales order data from the APO database tables and / or APO livecache.

should be executed regularly e.g. weekly

No system downtime is necessary to execute this report The only side effect can be that not all records which are obsolete are removed because they are processed by parallel transactions. But no inconsistencies should occur. system performance might be negatively impacted, however, this should not be a major concern. it is recommended to run this report using different variants due to performance reason Concerning Product Allocation deletion, please note the importance of the field date (until to) /SAPAPO/SDORDER_DEL only deletes data from tables in the SCM system. The R/3 system is not cleaned up. First tab : This first tab is used to delete obsolete data in the APO database. The purpose of this deletion is to prevent the tables from growing too big which would slow down the APO system. The report should be scheduled on a regular basis typically once a week for Selective deletion and once a month for Adjust ATP tables with /sapapo/posmapn and Delete obsolete records in the /sapapo/posmapn table . Second tab: The 2nd tab should not be used in combination with the 1st tab. The 2nd tab should be used in exceptional cases when you want to delete live data (still in Livecache) which you cannot delete by other means (such as the deltareport or the /sapapo/sdrqcr21 report). This deletes both the Livecache data and the database tables data. Third tab: This deletes all data from the database without any check !!!

Relevant notes (login required)

894294 /sapapo/sdorder_del: Performance and advice

1008133 Runtime for report /SAPAPO/SDORDER_DEL is too long