SAP Training Week 1

BBP_GET_STATUS_2: This report updates requirement coverage requests.
CLEAN_REQREQ_UP: This report is used to update document asynchronously in the back-end system.
RSPPFPROCESS: This report is used to transfer purchase orders to vendors.
BBPERS: This report is used for local purchase order with evaluated receipt settlement (ERS) for which confirmations exists.

In the Classic scenario, all material management takes place in the back-end ERP system. SAP ERP is the leading system & we can have the option of changing purchase order within SAP ERP system after they have been generated from an SAP SRM shopping cart.

The Open Catalogue interface (OCI) describes the data exchange between the SRM Server and the external catalog applications. It enables the transmission of selected goods and services from a catalog to the SRM Server

* Independent SAP component that communicates with an ERP system.
* Familiar technical SAP infrastructure remains.
* Additional SRM specific features and configuration options
* Product- and Vendor Catalog interface (OC! / DPI)

You can use this business process for your inbound processing and receipt confirmation. Whenever a company requires a product to be procured from an external source of supply, whether for use in production (raw material) or for direct consumption (C-materials), the product will be delivered according to the official procurement document (a PO) agreed between two business partners.
The arrival of the goods could be announced by an advanced shipping notification (ASN) from the supplier, this states that the goods are to be delivered in a certain quantity at a defined date and time at a defined company location.
For the delivered product, an inbound delivery is selected and processed for putaway.
Once the goods are taken into stock, a goods receipt must be posted.
The actual physical receipt of material at the warehouse or the receiving locations can be controlled in different levels of detail. For example, you can control the process only at a document level using purchase orders and stock transports orders for inbound deliveries and shipments, or you can go up to the pallet and material level.
The receiving process is supported in different ways depending on your needs. Optionally, you can use inbound deliveries, advanced material flow, and process control functions. These options include yard management, and warehouse management with task and resource management with task and resource management controlling the process down to pallet and package level using advanced strategies.
Inbound processing reflects the receipt of materials that are delivered to a receiving location. This receipt can be processed based on purchase order, stock transport order, or even a returns order. It includes the notification of goods to be received, the putaway, goods receipt posting, and the proof-of-delivery (POD) message to the supplier. By viewing the goods receipt from two perspectives, it is possible to follow the purchase order process and the physical material movements separately.
(Cf page 10)

SAP Supplier Relationship Management (SAP SRM) provides a two-step activation process for the implementation of new functions and the enhancement of existing functions.
This approach uses business function and Customizing switches. You use business functions to display Customizing activities and Customizing switches. Once the Customizing switches are visible, you use them to activate new fields or execute new code.
Activation of Business Functions
When you activate business functions you activate switch Framework switches (SFW switches). SFW switches directly control whether new customizing activities and customizing switches are visible.
You can activate SAP SRM business functions in Customizing for SAP Supplier Relationship Management under SRM Server ->Activate Business Functions.
Deactivation of Business Functions
In SAP SRM, you can deactivate a business function in the following applies:
• The business function only activates Customizing switches and does not directly activate any code or fields.
• The Customizing switches corresponding to the business functions can be deactivated.
To deactivate a business function, perform the following steps need to be performed.
1. Check whether there are limitations at Customizing switch level. You can find this information in the business function description and in the documentation of the Customizing switch in Customizing for SAP Supplier Relationship Management. If there are no limitations, deactivate the Customizing switch or switches in Customizing for SAP Supplier Relationship Management.
2. Run transaction switch Framework Customizing (SFW5), select the business function, and deselect the revertible checkbox. To do this you need special authorizations.
3. Save and activate your changes.

The following multilevel hierarchies come as part of standard delivery:
• Product category hierarchies
• Supplier hierarchies
• Central contract hierarchies
Product category hierarchies provide the following:
• Extended search of product categories
• Import of product category hierarchies into the SAP SRM system, for example:
• Back-end material categories from SAP ERP
• Standard product category hierarchies (such as UNSPC, eClass)
• Customer-defined product categories
Supplier hierarchies provide the structure and model of supplier relationships
Central Contract Hierarchies Group together contracts, making them easier to find and process.

There are various BAdls available for process - controlled workflow and the BAdl are used to control the process flow according the requirement of the organization.
/SAPSRM/BD_WF_ADHOC_AGENT_F4: This BAdl enables to filter the available users to be inserted.
/SAPSRM/BD_WF_REVIEWER_RULE: This BAdl is used to assign SRM purchasing documents to agent groups for review
/SAPSRM/BD_WF_RESP_RESOLVER: This BAdl is used to assign SAP SRM purchasing documents to agent groups for approval.
/SAPSRM/BD_WF_REVIEWER_F4: This BAdl is used for adjusting search help for reviewers.

There are four ways to add an item to a shopping cart:
Catalogue: The catalogue supplies product ID, product text, product category, price, vendor, and other data.
Product: The product represents either a material or a service master. It can be searched via short description, product ID, product type, or product category.
Describe what you need: The user describes via text entry what he or she needs; the user fills in a description, unit of measurement, quantity and product category.
Old shopping carts and templates: Refer to existing documents.

The above requirement will be fulfilled with the extended classic scenario. In this scenario the complete procurement process takes place locally in SRM Server and is transferred to the ERP system as soon as the document is complete and approved.
If the data in the shopping cart is insufficient to generate a complete purchase order, the data is supplemented manually within SRM server before being transferred to the back-end system. The purchase order in SRM Server therefore is the leading purchase order. Good receipts (confirmations) and invoices can be entered in SRM Server or the back end ERP system.

The SAP SRM workflow enables to perform approvals of documents electronically. Depending on the document data and configuration settings, the system determines the necessary approval and completion steps, as well as the requested approvers.

All SRM documents need to have status approved to create any follow-on document. In other words, workflow configuration in SRM server is a mandatory task even if we do not want to have approvals performed by real business users.
In a typical procurement process the users creates a shopping cart, which is notified to the manager automatically based on the configuration setting done, who has the option to reject it or approves it & once it is approved purchasing document is created.

In classic scenario all the material management takes place in the back-end ERP System. Good receipts can either be entered in the ERP system or in SRM Server, and goods receipts are automatically created in back-end ERP system by passing an IDoc. However if local scenario was implemented purchase order and confirmation are entered and stored in SRM server and there is no information passed to the ERP system.
We can physically delete confirmations if the document status is saved or awaiting approval. If the goods receipt is already posted in the ERP system, the confirmation needs to be cancelled & provided an invoice posting for the same has not been done yet.
Service entry sheets are transferred via RFC to the ERP system.

Pricing consists of the following elements:
• Condition Type
A condition type serves to differentiate between prices in the system. You can define a separate condition type for each type of price, surcharge or discount that may arise in your business transactions. The condition type defines, for example, a discount as a fixed amount or as a percentage.
For example, you can apply release-based rebates that depend on former spend or volume, based on historical spend and not on a single purchase order. Therefore, you can assign a condition where the discounts are based on aggregated release value of the referenced contract or contract hierarchy (if the contract is part of a hierarchy) has been introduced.
You can also define group conditions with which scales are used in several items of a purchase order.

• Calculation Schema
The calculation schema describes a sequence of condition types that are used to determine prices. In SAP SRM, the calculation schema 0100 is defined as default. You can modify this and add your own condition types.
• Access Sequence
An access sequence is a search strategy with which the system looks for valid data for a specific condition type. You can define an access sequence for each condition type. In SAP SRM, the access sequences are predefined.
• Condition Table
A condition table contains price information on a master data type, for example, on a product master. If you define a product price or a special discount, for example, you create condition records in the relevant condition table.

Data can be exchanged in XML format between SRM Server and any Vendor system. Data can be exchanged either directly using SAP XML or any XML dialect. The figure illustrates the data exchange between the SRM Server system and external systems, including SAP supplier self-services.

Event schemas are used to control the effects of the events that belong to the business objects. They can be used to define the deadline for triggering a reaction to the event. Event categories are used to define the nature of this reaction.
The system determines the recipient for event category Alert using alert category; it sends one of the following:
An alert, using alert category.
A message, using SAP Smart Form.
A work item, using workflow.
Note that an event always occurs at a predefined time. However, you can trigger an alert or message before or after this time by specifying a negative or positive value. If you enter no deadline, the system assumes that the value is zero and the alert is triggered at the moment of the event.

All master data is available locally in the SAP supplier Relationship Management (SRM) system. This data includes, for example, product master records, business partner master records, and product categories. You copy the master data from the back end system to SAP SRM.
In SAP SRM, both materials and services are stored as products. However, you can distinguish materials from services by the product type.
Products categories correspond to material groups in the SAP back-end system.
If the SAP SRM system communicates with and SAP back-end system, the length of the product ID is restricted to a maximum of 18 characters. This should be the case even if the products are created locally, and not replicated from the back-end system. If you assign a product ID with more than 18 characters, a different number (with a maximum of 18 characters), has to be assigned in the back-end system.

In order to use direct material procurement scenario in SRM system, we have to refer to products that exist in the back-end system. Therefore, we need to replicate units, product categories, material types, and the interesting products from the ERP back-end.
In the next step, we have to ensure that our plant appears as a business partner in SRM Server.
To ensure that the documents can be transmitted to the backend we have to maintain corresponding transaction types, document types, and number ranges for purchase orders in SRM server and in the ERP back-end system. If any on the above document types, transaction types or number ranges in missing in ERP back-end system the purchase order will not be replicated in back-end ERP system.

SRM Server
set up transaction type and number ranges
replicate the locations from back ends, with one of the location reports (for example, BBP_IOCATIONS_GET_FROM_SYSTEM)
set up attribute DP_PROC_TY as transaction type for direct material PO's
replicate products from back-ends

ERP System
set up document type and number range for direct material purchase orders corresponded to the SRM Server

This process describes the automatic assignment of a purchasing group or purchasing organization to the following documents:
• External requirements
• Purchase orders
• Contracts
• RFx
Use this process to distribute the workload of documents among the purchasers in your company. Assigned documents automatically appear for processing in the worklists of the purchasers that belong to the purchasing group or organization. The documents are automatically assigned to the purchasing group according to given criteria. This speeds up the entire procurement process, since documents do not have to be assigned manually in order for the purchasers responsible to process them.
It is also possible to reassign documents that have already been assigned to a purchasing group or organization — if the purchaser responsible for the group or organization is absent, for example.
You need to have implemented and activated the Business Add-In (BAdI) BBP_PGRP_ASSIGN_BADI. Here the rules covering the assignment of purchasing groups to documents are defined. This BAdI contains a method for each type of document to be assigned:
• BBP_SC_PGRP_ASSIGN for external requirements
• BBP_PO_PGRP_ASSIGN for purchase orders
• BBP_CT_PGRP_ASSIGN for contracts
• BBP_BI_PGRP_ASSIGN for RFx
If you do not define any rules, the system distributes the documents to a standard purchasing group or organization, as defined in your organizational plan.
The workload distribution process is outlined below in the diagram. Documents cannot be assigned to purchasing groups that are themselves assigned to different purchasing organizations. Besides, purchasing groups and organizations must reference the same logical system in the back-end.
1. A purchasing requisition is sent to SAP SRM, where it is converted into
an external requirement.
2. Upon creation of the external requirements, method
BBP_SC_PGRP_ASSIGN of the BAdI BBP_PGRP_ASSIGN_BADI
applies the distribution rules.
3. If the requirement conforms to the rules, it is automatically assigned to
the correct purchasing group (in this example, purchasing group 01).
4. If no assignment rules are maintained in the BAdI, the standard
purchasing group (as defined in the organizational plan — in this
example, 99) is assigned. The standard purchasing group is also
assigned to the shopping carts that are created in SAP Supplier
Relationship Management. In this case, you can proceed as follows:
o Assign a purchasing document manually o Define the assignment rules and have the system automatically reassign a purchasing group.
If you do not redistribute the workload, the requirement retains the standard purchasing group.
Note: One purchase requisition can have multiple lines, each of which is assigned to a different purchasing group

The number range for the supplier list has been defined.
This needs to be done under; Customizing for SAP Supplier Relationship Management under 9> SRM Server -^Cross-Application Basic Settings -* Number Ranges -^SRM Server Number Ranges -^Define Number Ranges for Supplier List. 4*
Carry out the following settings in Customizing:
• For the Shop application, you can specify that only the supplier list is to
be used, or that the entries from the supplier list are displayed in an
additional column in the original source of supply list.
• You can use a Business Add-In (BAdI) to define detailed criteria to
display the supplier list.
• Supplier lists can be created for products or for product categories (and
NOT for Product set-types). Product supplier lists take precedence
over product category supplier lists
Possible sources of supply in the supplier list are:
• Suppliers
• Back-end contracts
You can do the following:
o Assign suppliers that belong to the purchasing organization selected on header level.
o Deactivate individual suppliers or back-end contracts within a supplier list. These are then no longer shown in the applications.
o Search for contracts directly in the back-end system using the input help, and subsequently transfer them.

We must perform the customizing steps to determine different back-end systems for different product categories, starts with assigning the RFC destinations, ALE customizing, PI settings, defining back-end systems and SRM system in IMG, assigning product categories to back-end system as target & finally implementing a BAdl.