SAP SRM Extended Classic Deployment Scenario

[Former Member]

SAP Supplier Relationship Management (SAP SRM):

SRM in SAP stands for Supplier Relationship Management. It is one of the parts of SAP Business Suite Software. It is based on the SAP NetWeaver platform hence it also known as SAP NetWeaver SRM. It is for strengthening the procurement processes of an organization by automating, accelerating of procure-to-pay processes for goods and services. It introduced many facilities for better co-ordination between the suppliers and business activities. SAP SRM will examine and forecast purchasing behavior, it also shorten the procurement cycles, and work with your partners in real time. So it helps for building long-term relationships with the suppliers. The efficient processes in SAP SRM enable you to cut down your procurement expenses and to work more intensively with more suppliers than ever before.

SAP SRM mainly deals with

• Self-Service Procurement
• Plan-Driven Procurement
• Service Procurement
• Strategic Sourcing
• Operational Contract Management
• Supplier Qualification
• Supplier collaboration
• Catalog Content Management
• Analytics

Three types of multilevel hierarchy structures are used in SAP SRM master data

• Product category hierarchies
• Supplier hierarchies
• Central contract hierarchies

SAP SRM Lifecycle:

The following lifecycle is followed in SRM. This starts with creation of Shopping Cart. Once a shopping cart is created, a corresponding Shopping Cart number is generated. This will be sent for approval. Once the shopping cart is approved, a purchase requisition number will be generated and this will lead to generation of various process purchasing documents. This will also give rise to a Purchase Order along with a unique number. Once the PO is created, the goods are supplied at the ship-to address and goods recieipt will be given. Goods receipt will be verified and an invoice will be created. Once the invoice is created, the buyer will process the payment. Below diagram  (Figure 1) depicts the entire SAP SRM lifecycle structure.

Figure 1: SAP SRM Technical Life cycle

However, based on the system availability and generation of various documents, SRM have four different types of deployment scenarios.

SAP SRM Deployment Scenarios:

SAP SRM enables organizations to efficiently source and procure all categories of products, that is, direct materials, indirect materials, and services, and can be integrated with any backend planning, inventory, and accounting systems. SAP SRM provides four deployment scenarios, including the classic, extended classic, standalone, and decoupled scenario, and companies can decide on the level of integration with backend planning and accounting systems by implementing the appropriate deployment scenario.

It provides an integrated enterprise procurement platform that enables integration of procurement with design, planning, inventory, and financial applications. SAP SRM is seamlessly integrated with the SAP ERP application and can be integrated with other non- SAP backend ERP applications as well. Depending on the system that you want to be the main purchasing application, there are four scenarios of integration with backend ERP applications.

Local Scenario or Standalone Scenario:

In a standalone scenario, all procurement processes are executed in SAP SRM, and shopping carts and other procurement documents are processed in SAP SRM. Only final invoice data is sent to the backend accounting system. Account assignments are checked locally with accounting data defined in SAP SRM.

Applicability:

This is applicable for the following customer types:

• Customers who do not have an operational and/or productive backend system for materials management and have only financial accounting systems.
• Customers who want to move all procurement activity for selected categories to the SAP SRM system. This enables companies to reduce the load on the backend procurement (MM) system by transferring buyers who deal in these selected categories.
• Customers who do not have their own product data, those who want to maintain only minimal product data, and those who want to rely on supplier catalogs.
• Customers who want to use procurement card functionalities.
• Customers who want to use all of the functionalities in the service procurement scenario.
• Customers who want to involve suppliers in procurement transactions using Supplier Self- Service (SUS) integration with SAP SRM.

Process Flow:

Below diagram (Figure 2) depicts the process flow for Standalone scenario where Enterprise Buyer is the SRM system (or Portal) and the backend can be any system either SAP or non-SAP. Except the invoice posting, all other documents are created in SRM system.

Figure 2: Process Flow for Local or Standalone Scenario

Process Flow is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration settings. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• If the shopping cart is approved, the system creates a purchase order in the SAP SRM system. If the data is incomplete, the shopping cart is moved to a purchaser’s work list in sourcing (commonly referred to as the sourcing cockpit) from where the purchaser creates the purchase order.
• The goods receipt for materials or service entry sheet for services is created in the SAP SRM system as confirmation.
• An invoice is created in the SAP SRM system, which creates an accounting document in the backend system.

Go for Standalone scenario, if. . .

• Product categories are created in SAP SRM directly, that is, local product categories.
• The SAP SRM system is defined as the local system in the configuration setting Define Backend Systems.
• An accounting system is defined as the backend system in the configuration setting Define Backend Systems.
• The target system for the product category should be the SAP SRM system in the configuration setting Define Backend System for Product Category. You can also use the standalone scenario using backend product categories with this setting. Optionally, BAdI BBP_DETERMINE_LOGSYS is implemented to determine the target system as the SAP SRM system.

Classic Scenario:

In a classic scenario, the SAP SRM system is used mainly to capture procurement requisitions from employees in the form of shopping carts. All other procurement activities take place in the backend materials management system.

Applicability:

This is applicable for the following customer types:

• Customers who have a strong backend procurement system and where buyers do not want to use multiple systems for their operations.
• Customers who want to involve suppliers in procurement transactions using SUS integration with Materials Management (MM).
• Customers have a large user base in the SAP ERP system.
• Customers have their professional purchasers using SAP MM Purchasing application and want to continue using it.
• Customers have established supplier document collaboration mechanisms in SAP ERP (e.g. EDI) and want to continue using them.

Process Flow:

Process Flow is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements. The employee can also view the stock status for the material.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration settings. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• If the shopping cart is approved, the system creates a follow-on document in the backend system. The settings in the configuration setting 'Define objects in backend system' determine the type of follow- on document. The following settings are possible for each product category:
• If stock for the material is available on the requested date in the backend system, you can specify that a reservation (material issue requisition) is created.
• § Settings can be configured in such a way that the system always creates a reservation if the material belongs to a material type that is subjected to inventory management in the backend system.
• Settings can also be configured in such a way that the system never creates a reservation and always creates either a purchase requisition or purchase order.
• § Settings can be configured to always create purchase requisitions in the backend system.
• § The system can be configured to create a purchase order, if the shopping cart data is complete. If the data is not complete, the system creates a purchase requisition.
• Optionally, you can use customer- specific rules to determine the backend object by implementing BAdI BBP_TARGET_OBJTYPE.
• If the system creates a purchase requisition in the backend system, purchasers need to process the requisition and create a purchase order in the backend system.
• The purchase order is available only in the backend system. However, requisitioners can check the status of the shopping cart and view the essential purchase order information in the SAP SRM system, also.
• The goods receipt for materials or service entry sheet for services is created directly in the backend system. Alternatively, users can also create the confirmations in the SAP SRM system and the system automatically creates a goods receipt in the backend system.
• The invoice can be entered directly in the backend system. Alternatively, users can create an invoice in the SAP SRM system, which creates an invoice document in the backend system.

Figure 3: Process Flow for Classic Scenario

Go for Classic Scenario, if . . .

• At least one backend materials management system and accounting system is connected to the SAP SRM system and defined in the configuration setting Define Backend Systems.
• Product categories from the backend procurement system are replicated and used in the SAP SRM system.
• The target system for each product category is the backend system in the configuration setting Define Backend Systems for Product Category. Optionally, BAdI BBP_DETERMINE_LOGSYS is implemented to determine the backend system based on shopping cart data.
• The extended classic scenario should not be activated in the configuration setting Activate Extended Classic Scenario. If the extended classic scenario is activated, then BAdI BBP_EXTLOCALPO_BADI should be implemented to enable the classic scenario based on customer- defined rules.

Extended Classic Scenario:

In an extended classic scenario, the procurement process takes place in the SAP SRM system. The purchase order is created in the SAP SRM system and a read-only copy of the purchase order is replicated to the backend system. Goods receipts and invoices can be entered either in the backend system or in the SAP SRM system.

Applicability:

This is applicable for the following customer types:

• Purchase order response from the vendor can be captured in SAP SRM. Differences between purchase order and purchase order response, if any, can be approved by the purchaser in an interactive user interface.
• The full sourcing capabilities of SAP SRM are available in the extended classic scenario.
• Direct material procurement is enabled in the extended classic scenario only.
• Sophisticated workflow functionality is available in SAP SRM.
• Entry of confirmation is easier in SAP SRM compared to backend ERP. In SAP ERP, goods receipt for materials and service entry for services are done in two different transactions whereas in SAP SRM both goods receipts and service confirmations are done in the same transaction. In addition, SAP SRM also provides approval workflow for confirmations.
• Procurement card functionality is available in the extended classic and standalone scenarios only.
• Want their professional purchasers to work primarily in SAP SRM.
• Want to utilize complete sourcing capabilities of SAP SRM.
• Want to use out-of-the-box new communication methods with their suppliers (e.g. XML).
• Do not have the need to create SAP MM Purchase Requisition or Stock Reservation from the SAP SRM Shopping Cart.

Process Flow:

Process Flow is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements. The employee can also view the stock status, if the material used is a stock material.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration settings. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• If the shopping cart is approved, the system creates a purchase order in the SAP SRM system. If the data is incomplete, the shopping cart is moved to the sourcing cockpit for further action from the purchaser.
• In the extended classic scenario, purchase orders can be created in the following ways:
• From a shopping cart
• From an external requirement created in the backend system and transferred to SAP SRM
• Directly in SAP SRM from the Transaction “Create purchase order”
• From the winning bid in a bidding or reverse auction process
• The purchase order is created in the SAP SRM system. A copy of the purchase order is replicated to the backend system. The purchase order in SAP SRM is the leading purchase order, and any changes to the purchase order can only be made in SAP SRM. The data replicated to the backend system can be influenced by implementing BAdI BBP_ECS_PO_OUT_BADI. For example, a purchasing organization in SAP SRM can be mapped to a purchasing organization in SAP ERP using this BAdI.
• The purchase order response from the supplier can be entered directly in SAP SRM or updated automatically via XML communication. The supplier may indicate a different delivery date or a different price in the response. The differences can be approved or rejected by the purchaser in an interactive user interface. A workflow can also be activated for purchase order response approvals.
• The goods receipt for materials or service entry sheet for services is created directly in the backend system. Alternatively, users can also create the confirmations in the SAP SRM system and the system automatically creates a goods receipt in the backend system.
• Invoices can be entered directly in the backend system. Alternatively, users can create invoices in the SAP SRM system, which in turn creates an invoice document in the backend system.

Figure 4: Process Flow for Extended Classic Scenario

Go for Extended Classic Scenario, if . . .

• At least one backend materials management system and accounting system is connected to the SAP SRM system and defined in the configuration setting Define Backend Systems.
• Product categories from the backend procurement system are replicated and used in the SAP SRM system.
• The target system for each product category is the backend system in the configuration setting Define Backend Systems for Product Category. Optionally, BAdI BBP_DETERMINE_LOGSYS is implemented to determine the backend system.
• The extended classic scenario is activated in the configuration setting Activate Extended Classic Scenario. Alternatively, BAdI BBP_EXTLOCALPO_BADI is implemented to control the extended classic scenario based on customer defined rules.
• If the backend system is an SAP R/3 version lower than 4.6B, you must define local purchasing organizations and purchasing groups.
• If the backend system is an SAP R/3 version 4.6B or higher, you need to map the purchasing group used in the purchase order to the backend purchase group in one of the following ways:
• Use a backend purchasing organization and purchasing group in the shopping cart and purchase order.
• Use BAdI BBP_PGRP_FIND to determine a backend purchasing group in the shopping cart.
• If a local (created in SAP SRM without reference to a backend system) purchasing group and purchasing organization are used, then a valid backend purchasing group is assigned to the RFC user that created the backend purchase order. This assignment is made in the backend system using user parameter EKG in Transaction code SU01.
• Implement the user exit of the BAPIs BAPI_PO_CREATE1 (EXIT_SAPL2012_001 and EXIT_SAPL2012_003), and BAPI_PO_CHANGE (EXIT_SAPL2012_002 and EXIT_SAPL2012_004) to determine the purchasing group with a customer- specific logic.

Decoupled Scenario:

SAP SRM officially does not have a scenario called decoupled. However, this scenario name is loosely used to indicate the ability to use the other three scenarios in parallel. SAP recognizes that the procurement strategy for each category of purchases can be different and any procurement solution should offer flexibility during implementation to cater to all requirements. Hence, SAP SRM provides the flexibility to implement all three scenarios in parallel, based on customers’ requirements.

Applicability:

Companies that wish to fully leverage the flexibility offered by SAP SRM use the decoupled scenario. For example, a company might want to use the standalone scenario for certain indirect materials and routine services, the classic scenario for stock materials so that inventory and planning capabilities of backend materials management system can be utilized, and the extended classic scenario for purchases where flexibility and greater collaboration with suppliers is required in purchase order responses.

Process Flow:

The process is as follows:

• An employee searches the catalogs and creates an online shopping cart for his requirements. The employee can also view the stock status for the material.
• The system triggers an approval workflow based on the workflow start conditions defined in the configuration setting. The workflow is routed to the mailbox of the approving manager, who approves or rejects the shopping cart.
• Alternatively, an external requirement from the backend system is received in the SAP SRM system.
• The system verifies whether the product category used is a local SAP SRM product category. If the product category is a backend product category, the system verifies whether the target system defined in the configuration setting Define backend system for product category is a local SAP SRM system. Processing of such shopping cart items is handled in SAP SRM as a standalone scenario. On approval of such a shopping cart, the system creates a purchase order in the SAP SRM system. If the data is incomplete, the shopping cart is moved to the sourcing cockpit from where the purchaser creates the purchase order. Goods receipts or service confirmations and invoices are created in SAP SRM. Accounting documents from invoice postings are updated in the backend accounting system.
• If the shopping cart does not belong to a standalone scenario, the system verifies whether the extended classic scenario is activated in the configuration setting Activate extended classic scenario. If the setting is activated, the system processes the shopping cart as described in the extended classic scenario.
• If the extended classic scenario is not activated, the system checks whether the BAdI to control the extended classic scenario (BBP_EXTLOCALPO_BADI) is implemented. If the BAdI is implemented, then the system verifies the shopping cart data with the conditions specified in the BAdI. If the conditions in the BAdI are met, then the system processes the shopping cart as described in the extended classic scenario.
• If the extended classic scenario does not apply to the shopping cart, then the system processes the shopping cart as per the classic scenario process.

Figure 5: Process Flow for Decoupled Scenario

Illustration for Extended Classic Scenario:

Below illustration takes you through the creation of various documents in an Extended Classic Scenario.

This scenario starts with creation of shopping cart from portal. Below snapshot depicts the creation of shopping cart. We can also see that we can create other documents like Purchase Order, Confirmation and Invoice also from portal.

Click on Shopping Cart. Enter the required details in the shopping cart. Below snapshot depicts the 'Create Shopping Cart' window entered with required details. Shopping Cart number is also proposed in the window.

Click on 'Order' to create a shopping cart. This will trigger a workflow for approval. Below diagram shows the status as 'Awaiting Approval' which tells that the workflow is triggered and shopping cart is created successfully. The header is also changed from 'Create Shopping Cart' to 'Display Document'.

Once the shopping cart is approved, we can see the status updated as given in the below snippet. Here, the approval process is automatic and done by the system.

As supplier is assigned to Shopping Cart, Purchase Order will be automatically created because of auto sourcing. Below snippet depicts the link.

  

Refer to below snippet gives a look at the Purchase Order that is created in Portal (in ordered status) with the same supplier.

Once Purchase Order is created, we can see the details of the PO in the backend system also.

Now, confirmation needs to be created in the portal. Below snippets flow you through creation of confirmation.

Step 1: Enter the PO Number and click on 'Search'.

Step 2: Select the PO in the list and click on 'Start'.

Initially, confirm quantity will be 0 and outstanding quantity will be the total quantity available. Enter the Confirm Quantity and click on Confirm button.

Step 3: Once the invoice is confirmed, Confirmation will be posted and status changes to 'Awaiting Approval' Status.

Step 4: Once approved, the Confirmation will be displayed as below. The quantity in Outstanding will be subtracted with the Confirm Quantity.

Step 5: Data is replicated in the backend system as shown below:

Goods Receipt is captured in ECC (backend system) as shown below.

Invoice can be created from Purchase Order using the transaction MIRO.

A simulation screen appears in process on which we need to click the 'Post' button.

Once clicked on Post, an invoice with a document number will be created.

Invoice can be verified in MIRO as shown below.

This completes life cycle for Extended Classic Scenario in SRM.

Take-away:

• Various Deployment Scenarios
• Illustration of Extended Classic Scenario