Ansicht
Dokumentation

CRM_ATP_EXTERN_DOKU - Explanation for Setting up Availability Check with External Systems

If you are using an external (non-SAP) ATP system for production planning or purchasing, you can use this external ATP system to carry out

• Availability Check

The required quantity is persistently linked to the business transaction item.

• Availability Information

Temporary schedule lines are generated on the CRM Server that exist only during the current logical unit of work (LUW), and no persistent reservations are generated.

• Backorder processing

Confirmations generated by the external system are transferred back to the CRM Server

When the CRM Server carries out availability check or obtains availability information, it performs a synchronous call to the ATP system. Backorder processing performs asynchronous calls because the ATP system calls the CRM Server and passes a set of confirmations to it.

You connect an external ATP system by implementing the following Business Add-ins (BAdls):

• CRM ATP_EXTERN_BADI for carrying out availability check or availability information using an external system

• CRM ATP_EX_POST_BADI for posting the results in an external system

You are responsible for the following:

• Ensuring consistency between the related systems, because the CRM Server has no means to do it

• Solving problems such as locks or serialization to avoid overtaking of processes in the connected systems

• Mapping between the CRM Server and the external system

The BAdI-framework has a specific architecture in which a mapping layer is provided. In this layer you implement the logic which maps external ATP data to CRM data and vice versa.

• Providing a data exchange infrastructure to call the external system

Remote Function Calls (RFCs) work only in SAP R/3 based systems. Which data exchange infrastructure has to be used depends on your requirements.

Set up System Landscape

1. Specify the ATP System

The CRM ATP logic needs to know which ATP process or system is active (on client level). You define this under Define Middleware Parameters for Availability Check/lnformation.

The CRM Server checks which Middleware parameters are defined (that is, which system and process are active) in the following sequence:

1. SAP APO
2. SAP R/3 ATP check
3. SAP R/3 ATP information
4. External ATP check
5. External ATP information
6. Nothing: no ATP check or information is carried out

2. Define ATP Profile

Business transaction items are put into two data repositories according to whether they are

• Relevant for ATP check (for example, the quantity has changed)

• To be deleted from an ATP system (for example, the item category has changed, and the item is no longer relevant for ATP check)

The central function module (CRM_CONFIRM_ADD_ITEM_EC) is called whenever the event handler triggers an event that is related to ATP check such as change of quantity or change of item category. This function module collects the items in the two data repositories.

Therefore you need to maintain an ATP profile for the relevant products under Define ATP Profile.

This profile is analog to the ATP profile used for availability check with SAP APO and is used as an identifier that for this item an ATP check is to be performed. The key of the ATP profile must be numeric.

3. Change the ATP Relevance for an Item

CRM_CONFIRM_ADD_ITEM_EC is registered to many events that potentially influence the ATP relevance and the necessity to conduct a (new) ATP check. The relevance is determined in CRM_CONFIRM_ATP_RELEVANCE_CHCK.

If you have different criteria for ATP relevance (for example, based on the content of special fields that you use) you can use a BAdI method. For the implementation CRM_CONFIRM_ATP_RELEVANCE_CHCK may serve as a kind of template.

4. Specify the ATP System

The CRM Server needs to know what kind of ATP system is used: SAP APO, SAP R/3, or external. For this purpose, whenever an item is ATP relevant, the function module CRM_AV_CHECK_DEFINED derives the conf_mode internally from the active ATP system.

Related to the conf_mode is the source flag in the confirmation schedule line (schedlin). Whenever a confirmed schedule line is created, the source flag is set depending mainly on the conf_mode. There are several potential sources for confirmed requirements, which are listed below. Similarly, the confirmation of an external ATP system has to be marked in the schedule line. With EXT_ATP the system performs similarly to the ATP check using SAP APO, and with EXT_ATP_WO_RESERV the system performs similarly to the ATP information using SAP R/3 (R3_ATP_WO_RESERV).

The following constants are used in the confirmation schedule lines:

CRM_DIRECT include CRM_SCHEDLIN_CON

CONSTANTS:

  BEGIN OF gc_schedlin_source,

  END OF gc_schedlin_source.

Preparation for ATP Check

The ATP check is conducted at the end of business transaction processing if at least one event with the name CONFIRMED was triggered by CRM_CONFIRM_ADD_ITEM_EC. The main module is CRM_CONFIRM_DO_CONFIRM_EC.

First, the data repository with the items relevant for ATP is checked to see whether the data in the items is complete and consistent, and whether the final state and statuses still indicate ATP relevance for these items.

Secondly, the items that have to be deleted in the ATP system are processed.

Then the items that are relevant for ATP check are processed. The requirements are prepared for the ATP check and the function module CRM_ATP_DISPATCH is calIed. This function module delivers the results from ATP systems such as, for example the SAP APO System. The results are mapped to the CRM format and linked to the business transaction.

1. Final Check for Completeness and Consistency

First, the function module CRM_CONFIRM_ITEM_FINAL_CHECKS carries out a final check for every item that is in the data repository "relevant for ATP", to see whether the data is complete and consistent, and to check the final state and status of an item. For example, it does not make sense to conduct an ATP check if the unit of measurement in which the product is sold is invalid.

If you use different criteria for completeness and consistency of an item, you implement the BAdI method ITEM_FINAL_CHECK. The system processes this BAdI method only if an external ATP system is active. The BAdI method returns with the information that the item has to be skipped for ATP check.

Note: The message handling is your responsibility. You can take the checks used for SAP APO as a template. To delete your messages from the application log, the BAdI method ATP_ERROR_MSG_DELETE is provided in the form routine APO_RELATED_MSG_DELETE In function group CRM_CONFIRM.

2. Delete Items

If items are no longer relevant for ATP check, they need to be deleted from the ATP system. This is done with the function module CRM_CONFIRM_APO_REQ_DELETE . If an external system is active, this function module calls the BAdI method REQUIREMENT_DELETE instead of calling the SAP APO System.

In this BAdI method you specify your criteria for deleting items and requirements from the external ATP system. You need a mapping layer in which you convert the CRM format into the format of the external ATP system. A remapping into the CRM format is not necessary, because data is not returned to the CRM Server.

3. Prepare Items to be Checked for Availability

The next step is to handle the items that are relevant for ATP check. If an external ATP system is connected, the form PREPARE_AV_CHECK_APO_NEW is bypasssed, and a form PREPARE_AV_CHECK_EXTERN is processed. The form routine contains the BAdI method PREPARE_AV_CHECK_EXTERN in which you implement your logic to fill the tables for the business transaction header, item, and schedule lines from the data repository "relevant for ATP", and other data. There is an example implementation for this BAdI method that is on the lowest common level. You can complete it according to your requirements or do another implementation of the BAdI method.

Now the data is ready to be transferred to the dispatcher.

Execution of ATP Check

Set up the Dispafcher

The dispatcher (CRM_ATP_DISPATCH) is responsible for selecting the required ATP system and providing it with the necessary data. It consists of repositories and related services. It offers as many repositories as there are conf_modes available. In a pre-step, the transferred items are distributed into the repository that is related to the conf_mode of the item to be processed. After the distribution, the related services are invoked. The results or return values from the services are converted into the format of scheduled items.

Only one repository is filled at a time. Mixed ATP processes (for example, ATP check using external systems and SAP APO) are not supported.

To support ATP check, ATP information, or backorder processing using external ATP systems, there are three additional respositories. In addition to the existing services, three additional services are implemented in the standard system. The following function modules are called up by CRM_ATP_DISPATCH:

• CRM_AV_CHECK_EXT_DO_CHECK

• CRM_AV_SIMU_EXT_DO_CHECK

• CRM_AV_CHECK_EXT_BOP_GET

In these function modules the following BAdI methods are provided (they have the same interface as the function modules):

• AV_CHECK_EXT_DO_CHECK

• AV_SIMU_EXT_DO_CHECK

• AV_CHECK_EXT_BOP

Typical Architecture for ATP Check l Information

The following steps show a typical architecture of the services in the standard system (for example, CRM_AV_CHECK_APO_DO_CHECK for ATP check using SAP APO):

1. Preparation: Map data into required format, for example SAP R/3
2. Preparation: Map into SAP APO interface format
3. Carry out Remote Function Call to the SAP APO System
4. Postprocessing: Map the results from SAP APO into SAP CRM format

Due to the requirements of SAP's ATP system, SAP CRM data must be mapped into SAP R/3 data, because this ATP system can communicate only in SAP R/3 data formats.The ATP system is called via Remote Function Call and the data is transferred in structures defined in the ATP system. The ATP system returns results in its structures and formats, and the required parts of the results must be mapped into SAP CRM formats.

To connect your external ATP system, you need to carry out similar steps. If your ATP system is unable to communicate in SAP CRM format, you need to implement mapping logic. You need to map the data into the structures provided by your ATP system.

Example Architecture for ATP Check l Information Using External ATP System

The following steps show an example architecture:

• Preparation: Map data into EXT_S format

• Preparation: Map into EXT_S interface

• Carry out (Remote Function) Call to the EXT_S system

• Postprocessing: Map the EXT_S results into SAP CRM

The function modules for the external ATP systems are empty with the exception of the BAdI method AV_CHECK_EXT_DO_CHECK where you implement your logic.

Theoretically you can implement, for example, a distribution logic to different ATP systems on item level. However, when the results from the ATP check are returned to the CRM Server, they must look as if they originated from one system. In this case the CRM Middleware parameter stands for a virtual system.

Backorder Processing (BOP)

The external system calls the CRM Server and transfers new confirmations. The function module CRM_EXTERNAL_INBOUND is provided as an optional entry point. For the implementation, CIF_SL_DOC_INBOUND_30A may serve as a template. No BAdI framework is provided, since the implementation depends mainly on the external system. Your implementation must support the correct conf_mode to invoke the correct ATP service in CRM_ATP_DISPATCH.

Business Transaction Processing: Save or Cancel the Business Transaction

When you save a business transaction, the ATP system needs to know if an ATP check (that is, with reservation of the product) is carried out. There are two ways to inform an ATP system:

Case 1: Saving a Business Transaction

Directly from the Online Logical Unit of Work (LUW)

In the case of a simple posting logic, you need to consider the situation that the CRM Server may have an abnormal end, either in the online LUW after informing the external ATP system or in the update LUW. When saving a business transaction, there may be unnecessary reservations. Consequently, product quantities are blocked unnecessarily. There is only one way to correct inconsistencies if the CRM Server has an abnormal end after processing the BAdI method AV_CHECK_EXT_SAVE. We recommend that you implement a check and update program that is run from time to time.

Posting with COMMIT-Logic

In this case, the data to be posted is sent to the external ATP system. At the end of the update LUW, a COMMIT is sent. Whether this method is feasible depends on the external ATP system and the business process you use.

You need to implement the BAdI method AV_CHECK_EXT_SAVE In CRM_ATP_ORDER_UPDATE if you intend to implement a posting logic with a COMMIT as is done for posting in SAP APO. In this case, you need to implement the BAdI method AV_CHECK_EXT_COMMIT as well. It is provided in CRM_AV_CHECK_DELTA. This, however, only makes sense if the external ATP system can handle a COMMIT. The external ATP system needs a logic that performs a rollback if the COMMIT is not received.

Case 2: Cancelling a Business Transaction with F3 or F4

On the CRM Server, only the online LUW is relevant. The external ATP system needs to know if a user quits a transaction without saving the business transaction. For this purpose the BAdI method AV_CHECK_EXT_CANCEL is provided; it is processed if an external ATP system is active. The interface consists of tables for headers for which the changes have to be undone. You can obtain the original state from the database (CRM