Self Service Procurement Highlights
Features of Self Service Procurement
Tax Engine (TTE)
Availability check is executed in all the plants defined in user attributes.
Procurement cards Features
Statuses of a SC
Follow on Docs for a SC
With SRM 7.0 , only SRM-MDM catalog can be used.
SRM Specific Inbox à UWL (NW Portal)
Status of invoice or credit memos
App Controlled Workflows in SAP SRM 7.0
Rest all the workflows have been migrated to process controlled workflow.
Process Controlled Workflow
Process Controlled Workflow features
Process Type – Approval with Completion allows purchaser and approver to communicate.
Decision set and decision type for ad-hoc agents are identical to ones in the current process levels.
Reviewers can be added and they can – display the doc/attachment, add notes and reviews.
System can insert reviewers on its own.
Process schema uses the BRF for evaluation
A process schema encapsulates the draft of approval process for a business object. There
can be various process schemas for a single business object.
BRF event refers to a BRF expression which determines a valid process schema. BRF
expressions can be nested.
Decision types in process controlled workflow
BC Sets – pre delivered. Uploading a BC set creates events, expressions, process schema and
levels for basic approval process. TXN SCPR20.
SAP SRM and ERP on the same client
If SRM / ERP on same client – only few business scenarios are supported
Constraints with one client
SAP SRM Business Scenarios
Spend Analysis – uses SAP NW BI. Harmonization of data can be done using SAP NW BI,
integrating SAP BI with SAP MDM or local master data alignment (for limited data volume)
Supplier Evaluation.—this can be integrated with confirmations, invoice and supplier list
to evaluate vendor on day to day operational procurement information. Evaluation and
monitoring of supplier performance runs in SAP NW BI.
Operational Contract Management
Strategic Sourcing with RFx. – can be without integration of sourcing cockpit.
Strategic Sourcing with live auction – with or without sourcing cockpit.
Vendors can be created in the following manners
Defining a Backend System based on product category
In SAP SRM,Based on product category follow-on documents creation is determined i.e.
locally or in a backend system. This kind of scenario is referred to as decoupled scenario.
Configuration Please follow the path mentioned below :
SPRO →Supplier Relationship Management → SRM Server → Technical Basic Settings → Define
Backend Systems → Define Backend System for Product Category.
We can use BADI BBP_DETERMINE_LOGSYS to define backend system based on our business logic.
During determination of backend, back end system value is placed in ITEM_DATA-
LOGICAL_SYSTEM field of BADI BBP_DETERMINE_LOGSYS.
Use method DETERMINE_LOGSYS to determine backend system for SC. We can modify the value of ITEM_DATA-LOGICAL_SYSTEM based upon the value in ITEM_DATA OR ACCT_DATA.
Sample code for BADI BBP_DETERMINE_LOGSYS:
Create an implementation for BADI BBP_DETERMINE_LOGSYS.
method IF_EX_BBP_DETERMINE_LOGSYS~DETERMINE_LOGSYS.
data :lt_item TYPE LINE OF bbpt_detlogsys_item.
Loop at item_data into lt_item.
If lt_item-product_type = ‘A1’. “product type
If sy-sybrc = 0.
Lt_item-be_co-code = ‘1111’. “‘company code
Lt_item-logical_system = ‘A1CLNT100’. “logical system
Modify it_item from lt_item.
Endif.
Endif.
How to Hide a Tab of Shopping Cart Screen in SAP SRM 7.0
Follow below steps to hide tab in Shopping cart screen:
Click on the tab which you want to hide in Shopping cart Screen.
Find the Webdynpro component and view by right clicking on the SC screen.You can find the
information in "More field Help".
For tabstrip enhancement the webdynpro component which can be used is
/SAPSRM/WDC_UI_SC_DOFC_D1.
Goto SE80 and display /SAPSRM/WDC_UI_SC_DOFC_D1 Webdynpro component found in above step.
Create an enhancement implementation for Webdynpro Component.
Goto Layout tab of enhancement and choose the tabstrip which you want to remove.
Right click on that particular tab and choose "Remove element form Tab ".
Activate the enhacement implementation .Now tab will not appear in SC screen.
You can revert the changes made in the enhancement to original screen.
Product Categories in SRM
After all the relevant settings have been done on ALE and IMG for backend systems,
BADI BBP_DETRMINE_LOGSYS can be used to determine the backed system for a product category.
This is particulary useful in decoupled scenarios.
Classic Scenario --- PR is created instead of a PO or Reservation in backend
Problem Statement
You create a SC in your SRM system and you expect a purchase order or a reservation to be
created in the back end. However, a purchase requisition is created instead. And you keep
guessing why !
The system determines the object type of the follow-on document after you
save the shopping cart. When determining the object type, the system checks
SRM Customizing ('SPRO' -> 'Supplier Relationship Management' -> 'SRM
Server' -> 'Cross Application Basic Settings' -> 'Define Objects (purchase
requisitions, reservations, purchase orders) in Backend System'), but the
actual decision is made in the backend system. In the backend system, the
system reads the SRM Customizing and the document data of the shopping
cart:
o The system first checks whether Customizing was created for the
current purchasing group or product category (Example for
purchasing group 'EKG1' and product category 'KATEGORIE1'):
Purchasing group Product category Sequence
EKG1 KATEGORIE1 1
* KATEGORIE1 2
EKG1 * 3
EKG1 KAT* 4
* * not allowed
* KAT* not allowed
EK* KATEGORIE1 not allowed
The system always uses the first entry: If a valid entry is found, the system does not check the next level (1..4).
For Customizing entries that are not allowed, the system automatically converts the object type of the follow-on document to purchase requisition.
The application data of the shopping cart is validated (SOS,material, ...) in the next step.
If the purchase order that was chosen in SRM Customizing cannot be created in the backend system, the object type of the follow-on document is automatically set to purchase requisition.
BAdI:
The follow-on document type that is determined can be overridden by the BAdI BBP_TARGET_OBJTYP. After calling this BAdI, the system no longer checks the document type against the backend system. If the overridden document type (reservation or purchase order) cannot be created in the backend system, however, the system also does not create a purchase requistion as an alternative. Instead, the system creates an entry in the alert monitor under 'Backend Application Errors'.
Troubleshooting:
If the system creates a different follow-on object than expected, check
whether Notes 140846 and 787045 are implemented in your backend system.
For the necessary Customizing settings, see Consulting Notes 157887 and
336658. Check also in Customizing: SPRO -> 'Supplier Relationship
Management' -> 'SRM Server' -> 'Technical Basic Settings' -> 'Define
Backend Systems' -> 'System Type' whether the release of the backend system
is the latest release.
How to analyze Shopping Cart Transfer Process
The Shopping Cart (SC) transfer is the process during the follow-on document is created to
the shopping cart, which has been ordered by the requester. It is started by the workflow
event ‘SetReleased’ and ends with the triggering of the follow-on document creation
eventually by updating the alert entries. Since the workflow is executed in the background,
it takes also the transfer into the background, therefore it is not possible to debug the process in dialog mode after ordering the SC, the code won't stop at the preset breakpoints.
This blog gives a short overview about the most analyzed points of the transfer.
How can be the transfer started?
The SC transfer is triggered by the function module BBP_PD_SC_TRANSFER. This needs only the
GUID of a transferable shopping cart as an input. Transferable shopping cart means, that it has no errors and has at least one item without the status I1111 (item in transfer process) I1113 (follow-on document created).
Steps to start the transfer:
Please note, that by this kind of manual transfer the workflow steps are not executed, and
the workflow will stay in the status Waiting even after the follow-on document is created.
Don't use it therefore in production system.
How to analyze the creation of follow on documents in backend system
Following are the steps for analyzing for the typical problem related to creation of
documents in backend system.
The B31I_INTERPRETE_DATA is responsible for defining the type of the follow-on document
(Purchase Order, Purchase Requisition or Reservation) in classic scenario.
The B31I_INTERPRETE_DATA calls the plugin function BBP_INTERPRETE_DATA of the backend system via RFC. The decision about the type of the follow-on document is made in the backend system, depending on the SRM customizing (proc_cust_backend) and the item data
lt_procurement_item). The result is returned in the field lt_procurement_item[]-OBJ_TO_GEN,
whereby 1=reservation, 2=purchase requisition, 3=purchase order.
Debugging:
‘ CALL FUNCTION 'BBP_INTERPRETE_DATA'
DESTINATION destination
You are now in the backend system. Set a watchpoint to the fields 'purchasing',
'no_reservation', 'procurement_item-obj_to_gen', 'reservation'
When you stop at these watch-points, you will see why the object type is taken (e.g. one of the typical reasons is, when the Source is Supply is not correct).
The type of the follow-on document will be sent to the SRM system in the
fieldlt_procurement_item[]-OBJ_TO_GEN with the value 1, 2 or 3.
At the end of your analysis don't forget to change back the RFC user to system user in the
backend system.
BBP_PD 427 - Enter no more than one partner of type Vendor
When creating a shopping cart, you select the preferred vendor. Error message BBP_PD 427 is
raised - Enter no more than one partner of type Vendor.
This error occurs when you convert preferred supplier (partner function 39) to fixed
supplier (partner function 19) using BBP_DOC_CHANGE_BADI.
BBP_DOC_CHANGE_BADI is triggered twice after an update, which is as per SAP’s design.
After the first call, if the change occurred from partner function 39 to 19, then the same
is updated to PD layer.
Therefore in order to ensure that you don't add this again (i.e. two partner function 19),
you have to do BBP_PD_SC_GETDETAIL call to get the updated PD partner information.
Then do a check in this partner table and see if fixed vendor(partner function 19) already
exists. If so, do not add it again
Currency integration between SRM and ECC
This topic will give you a brief overview about how does the currency integration works
between SRM and ECC systems. The intent is to explain the integer and decimal system in SAP system, as well as the behavior in the database and in the User Interface (UI).
The next paragraphs will show the behavior of the currency decimals in SAP system and the
integration between SRM and ECC. A table will be present to demonstrate what is the impact of the value in column “Decimals” (table TCURX).Identifying the versions of your applications
Currency fields.
The value of data stored in currency fields depends on the decimal places defined for thecurrency. SAP Standard takes as 2. Therefore the value will be the same if the currency is defined for two decimal places (relevant to transaction OY04).
The transaction OY04 allows currency maintenance and its decimals. However, the value in
the “Decimals” column doesn’t mean the quantity of decimals. If you place a value of 0 (zero) in this column, so this currency will show values divided by 100.
Find below the list of values for “Decimals” column, as well as its behavior:
Decimal Places Value of price in stored in table
0 /100 (Divide 100)
1 /10 (Divide 10)
2 No Conversion(Standard)
3 * 10 (Multiply 10)
It is recommended to have the same decimal place configuration for both SRM and ECC
Backend.
The reason why the values in the database (transaction.BBP_PD-> BBP_PDIGP or in
BBP_PROCDOC_GETDETAIL) are different at decimal positions from UI fields is because as per the standard design the internal price structures and database structures has only 2 decimals places.So they can’t hold more than 2 decimals. Due to this reason, it is not possible to store 3 decimal positions in the database same like in UI. This is the standard system design and this can’t be changed.
The need for using Service Procurement scenario
Services procurement can be challenging due to the complexities involved in defining the
quantity, duration, and price of services to be consumed. SAP SRM Services Procurement
helps you manage procurement resources and monitor costs for a wide range of services
commonly used across major industries such as time-based and deliverable-based services.
This includes service demand that originates in your back-end SAP ERP application. With
sourcing, contract management and supplier enablement, the application enables you to
improve services procurement activities on an end-to-end level and establish cost-saving
measures.
SAP SRM helps facilitate and coordinate services-supplier collaboration: define and price
services and bid for the best supplier based on cost, availability, and other terms. The
result is an increase in the speed and visibility of the services procurement process. With
the application, you can drive business value across the company and streamline the
procurement of services with enhanced RFx functionality
An organization that does not have a clear strategy for an end-to-end procurement process
for services only applies an ineffective procurement process which ultimately results in
high costs for the company. The procurement group often has only decentralized control over
services procurement. Numerous lines of business are involved in purchasing decisions, such
as Human Resources, Finance and Maintenance. This decentralized control makes it difficult
for procurement to gain full visibility into total expenditures and the suppliers engaged.
This is coupled with the challenge of employees using unauthorized suppliers, rather than
utilizing procurement-approved suppliers for their services needs.
Manual, non-integrated processes result in long procurement cycle times, and also increase
the margin of error. For example, service delivery information might not be linked to the
negotiated terms, making oversight very difficult. The lack of supplier collaboration
results in poorly-defined requirements, and a disconnect during the purchase order, service
confirmation, and invoicing processes.
Services Procurement with SAP SRM supports a company in managing resources and monitoring costs over servicessupports complex categories such as maintenance, construction, IT, and temporary labor centralizes management of services spend enforces compliance by engaging approved suppliers at the negotiated rates enables supplier collaboration on service definitions, bid responses, purchase order delivery, service confirmations, and invoice distribution
Plan Driven Procurement -- refresher
Direct procurement refers to procurement of direct materials for inventory
Demand from production is transferred to SRM using open XML.
Process in Plan Driven Procurement
Sourcing Integration with Direct Procurement
Customizing can be set up so that the requirements are transferred into sourcing directly.
External Classis – requirements from backend come to SRM assign source of supply
PO created directly in back end.
For external classic requirement , SRM does not automatically assigns a source of supply.
This is a manual process.
In extended classic , sourcing with backend contracts and purchasing info records is not supported.
Manual Direct Procurement With contract / Without contract / local contract can be used.
If account assignment is Cost Center, the item would be treated as a consumable item.
When the checkbox ‘ Order as Direct Material’ is selected, account assignment tab disappears and the account determination is done in backend automatically.
Direct Procurement in SRM always follows extended classic scenario.
Service Procurement with external staffing - certification refresher
Service Procurement External Staffing –
Create request for external staff – Purchasers , Requestors and Purchasing Assistants can create a request for information.
While requesting for external services request can ONLY be created if there source of supply for related service master .This essentially means that even if a new vendor is selected for providing external services even then the vendor has to be set up as a source of supply using contracts ,vendor list etc.
Hierarchal display of service items is possible only in EC or standalone scenario.
Pricing is dependent on sourcing.
Priority while determining pricing
Price cannot be determined if
available to purchasers and purchasing assistants.
Procurement of external services can be done in classic, standalone and EC scenarios.
After a vendor has responded to an RFI , a PO can directly be created from this by using
the ‘submit request’ button in check status of application. This activity can be performed
by employees, purchasers and purchasing assistant.
A quick entry screen is available for professional users to enter service requisition
quickly. There are certain service specific entry fields which can be used to enter limits,
expenses and other specific details. A service provider is a specific employee of a vendor which can be a SUS user or can be a contact person for a vendor.
Services can be selected from internal or external catalogs. Source of supply can be contracts as well.
Service Procurement Classic with Hierarchies - certification refresher
Service Procurement Classic with Hierarchies -- SRM 7.0
Transfer PR in ECC with hierarchies to SRM sourcing cockpit. System can be configured to
send requirements directly to RFx. If sent to RFx directly it would not be shown in carry
out sourcing.
In a hierarchy, the levels are
E-SOA is used for transfer of hierarchies,before srm 7 / ecc 6 ehp 4 , only materials could be passed to srm.
Transfer of hierarchies possible only in classic scenario.
Types of limits which are transferred:
Line type indicators can be transferred from ECC to SRM. When a PR is saved in ECC It can be transferred to SRM automatically.
BADI ME_REQ_SOURCING_CUST is used in ECC to decide the auto/manual transfer/no transfer. This BADI is required to transfer materials/services and this replaces config in ECC and use of
report BBP_EXTREQ_TRANSFER.
CPPR – Collective processing of purchase requisitions – can be used for transfer of PR. This is available in role operational buyer.
Hierarchies are supported in srm 7 , ecc6 ehp4 by
Direct Material Procurement Process in SRM
How is a material classified as a direct material?
A direct material is used directly in production process and it is mostly held on stock. A
direct material has an impact over the value of the finished good or product.
How to configure SRM system for direct procurement ?
Settings on SRM Server
Settings on ERP
Set up document type and number range for direct material purchase order corresponding to
SRM Server.
Also , please remember, in direct material procurement the system always behaves in
extended classic scenario i.e. SRM server is the leading system for direct procurement.
Whats new with SAP SRM 7.01
A lot of new features have been introduced with the Ehp1 for SRM 7.0. Shopping savvy
are going to love the new interface, the new NWBC client.
Read on to get an overview on whats new with SAP SRM 7.01
Bidding Procedures -- In General
Single-Stage: One-Envelope Bidding Procedure
In the Single-Stage: One-Envelope bidding procedure, Bidders submit Bids in one envelope
containing both the Price Proposal and the Technical Proposal.
The envelopes are opened in public at the date and time advised in the Bidding Document.
The Bids are evaluated, and following approval by the purchasing organization, the Contract
is awarded to the Bidder whose Bid has been determined to be the lowest evaluated
substantially responsive Bid.
Single-Stage: Two-Envelope Bidding Procedure
In the Single-Stage: Two-Envelope bidding procedure, Bidders submit two sealed envelopes
simultaneously, one containing the Technical Proposal and the other the Price Proposal,
enclosed together in an outer single envelope.
Initially, only the Technical Proposals are opened at the date and time advised in the Bidding Document. The Price Proposals remain sealed and are held in custody by the
Purchaser. The Technical Proposals are evaluated by the Purchaser. No amendments or changes
to the Technical Proposals are permitted.
The objective of the exercise is to allow the Purchaser to evaluate the Technical Proposals
without reference to price. Bids of Bidders who do not conform to the specified requirements may be rejected as deficient Bids, with purchasing organization’s approval.
Following approval of the technical evaluation and at a date and time advised by the
Purchaser, the Price Proposals are opened in public. The Price Proposals are evaluated, and
following approval of the price evaluation, the Contract is awarded to the Bidder whose
Bid has been determined to be the lowest evaluated substantially responsive Bid.
Two-Stage: Two-Envelope Bidding Procedure
In the Two-Stage: Two-Envelope bidding procedure, at the first stage, Bidders submit two
sealed envelopes simultaneously, one containing the Technical Proposal and the other the
Price Proposal, enclosed together in an outer single envelope.
Only the Technical Proposals are opened at the date and time advised in the Bidding
Document, and the Price Proposals remain sealed and are held in custody by the Purchaser.
The Technical Proposals are evaluated and if the Purchaser requires amendments or changes
to the Technical Proposals, such amendments and changes are discussed with the Bidders. The
Bidders are allowed to revise or adjust their Technical Proposals to meet the requirements of the Purchaser.
The objective of the exercise is to ensure that all Technical Proposals conform to the same
acceptable technical standard and meet the technical solution required by the Purchaser.
Bids of Bidders who are unable or unwilling to bring their Technical Proposals to conform
to the acceptable technical standard will be rejected as deficient Bids Following approval of the evaluation of Technical Proposals, Bidders are invited, at the second stage, to submit Modified Bid Proposals consisting of Revised Technical Proposals and Supplementary Price Proposals based on the technical standard agreed.
The original Price Proposals and the Modified Bid Proposals are opened at a date and time advised by the Purchaser. In setting the date the Purchaser will allow sufficient time for the Bidders to incorporate the changes in the Revised Technical Proposals that are needed to meet the agreed technical standard and to prepare the Supplementary Price Proposals that reflect these changes.
The Price Proposals, Supplementary Price Proposals, and Revised Technical Proposals are evaluated, and following approval, the Contract is awarded to the Bidder whose Bid is determined to be the lowest evaluated substantially responsive Bid.
Two-Stage Bidding Procedure
In the Two-Stage bidding procedure, Bidders first submit their Technical Proposals, in
accordance with the specifications, but without prices.The Technical Proposals are opened at the date and time advised in the Bidding Document.
The Technical Proposals are evaluated and discussed with the Bidders.Any deficiencies, extraneous provisions and unsatisfactory technical features are pointed out to the Bidders whose comments are carefully evaluated. The Bidders are allowed to revise or adjust their Technical Proposals to meet the requirements of the Purchaser.
The objective of the exercise is to ensure that all Technical Proposals conform to the same
acceptable technical standard and meet the technical solution required by the Purchaser.
Bids of Bidders who are unable or unwilling to bring their bids to conform to the
acceptable technical standard may be rejected as deficient bids.
After the evaluation of Technical Proposals has been approved by purchaser, the second
stage is to invite Bidders to submit Price Proposals and Revised Technical Proposals in
compliance with the acceptable technical standard. The Revised Technical Proposals and
Price Proposals are opened in public at a date and time advised by the Purchaser.
In setting the date the Purchaser should allow sufficient time for Bidders to incorporate
the changes involved in the Technical Proposals and prepare Price Proposals.
The Price Proposals and Revised Technical Proposals are evaluated, and following approval,
the Contract is awarded to the Bidder whose Bid has been determined to be the lowest
evaluated substantially responsive Bid.
Permissions or Roles in SAP SRM Bidding Process
As a follow on to my last post which was about the bidding process, here is some useful
information on the 'roles' or 'permissions' in the sap SRM bidding process.
Following are the permissions available in SRM bidding process
The Bid Floor Admin is the person responsible for initiating the opening process,
for Technical and Price rounds. By default, this is the purchaser. The bid floor
administrator can extend the duration of the simultaneous logon process. The Technical Opener is responsible for the simultaneously login and for the technical opening once the technical round is initiated. This user must approve the opening of technical RFx responses.
Technical Evaluators are responsible for evaluating the technical responses submitted by the vendor
The Price Opener is responsible to simultaneously login and performs the Price opening once the price round is initiated by the bid floor admin. This user must approve
the opening of price RFx responses
The purchaser can assign roles and permissions before and after publishing the RFx.
Please note that the permissions are valid only for the selected RFx .
CCM to MDM migration
With introduction of SAP SRM 7.0, CCM moves to sunset phase. So if you plan to upgrade from
an earlier version of SRM to SRM 7.0, you might consider upgrading from CCM to MDM. Here
are answers to few FAQ's on this subject.
Is CCM supported with SRM 7.0?
SAP CCM 2.0 is supported as a separate application as per the maintenance agreement currently in place until December of 2013. However, considering the longer term goal it is
advisable to move to MDM
What are the limitations of CCM?
1. SAP has stopped developing any new functionality in CCM (a sunset phase)
2. Primitive end user interface for both sides: maintenance and shopping
3. Primitive content validation functionality
4. Serious performance issues with big catalogs
When is the Support for CCM expiring?
CCM is supported till the end of 2013. So be prepared with your upgrade plans :-)
Is there any tool to migrate from CCM to SRM MDM Catalog?
No
Is there any migration guide to migrate from CCM to SRM MDM Catalogs?
Technically, moving to CCM to MDM is not upgradation.It can be considered as new
installation and migration of contents from CCM to MDM.
1. Install SRM-MDM Catalog
2. Adjust Repository if there are custom fields
3. Import contents from the existing catalogs
4. Define views in MDM
Is there any OSS Note to migrate data from CCM to SRM MDM Catalog?
Check the OSS note no – 1376770
How to analyze and fix errors in transfer of invoice to backend.
What happens when an invoice is not transferred to the backend correctly ?
How do you analyze and figure out the error in invoice transfer?
How to fix the error in transfer of an invoice?
What idoc type / message type / background jobs are involved in invoice processing ?
Read on for answers ......
An IDoc BBPIV is sent if an invoice is released in the EBP system. In the invoice the statuses I1022 "Release granted" and I1017 "In transfer" are set. In addition, for the background job (see below) an entry is written to table BBP_DOCUMENT_TAB.
Unless I1017 is not set again to inactive, all previous operations are not allowed (in
particular all changes to the invoice), that is, they are stopped by the program. The
sending of the IDOC is checked by the background job CLEAN_REQREQ_UP. The report reads the
BBP_DOCUMENT_TAB and makes a RFC (remote function call) per META_GOODSMVT_UPDATECHECK to check the posting of inbound IDocs. If the IDoc is posted successfully (status 53), the BBP invoice receives status I1018 "Transferred to backend".In addition, the entry is deleted in BBP_DOCUMENT_TAB.
If the IDoc is posted incorrectly (status 51, no follow-on document), the status of the
invoice is set to I1019 "Transfer failed".The entry in BBP_DOCUMENT_TAB remains as is, that
is, the status of the IDOCs in the backend system is still checked by the background job.
The sending of the IDOC is checked by the background job CLEAN_REQREQ_UP. If the IDoc has
not (yet) arrived in the backend system, the entry also remains as is.
Status I1018 allows to reverse the invoice in the future. In case of status I1019, a
deletion is (again) possible.
The following must be considered when processing an incorrect IDoc in the backend system:
a) Further process the same IDoc (using BD87), instead of copying and correct the IDoc with
Transaction WE19 since in the latter case, the background job cannot find the (copied) IDoc
and the invoice posted from that. In this case the BBP invoice would remain endlessly in
status "incorrect", the entry in BBP_DOCUMENT_TAB would never be deleted and the background
job would always make the RFC at every run.In addition the BBP invoice would never receive
the status "paid" (see below).
b) If the IDoc cannot be corrected or the error in the backend system cannot be solved, the IDoc remains in status "incorrect".In this case the BBP invoice should be deleted and the entry in BBP_DOCUMENT_TAB should be deleted manually or with a self-written report.
Additional information: As of EBP Release 4.0 or after the implementation of Note 601470 or
the import of the relevant Support Package, the entry in BBP_DOCUMENT_TAB is deleted by the
program (during the deletion of the invoice). Then the manual deletion is no longer required.
Status I1020 "paid" is set in the invoice by using the second background job
BBP_IV_UPDATE_PAYMENT_STATUS to check the payment status of the follow-on invoice in the FI backend system for all invoices from the selection area.This only occurs for BBP invoices
with status I1018 "Transfer to backend".
To read the FI documents, META_FI_DOCUMENT_READ_40B is used.
Migrate Vendor Structure from SRM 4.0 to SRM7.0
Below is a brief on the various steps to be followed while migrating vendor org. structure
from SRM 4.0 to SRM and some most common errors and its resolutions.
Once Upgrade is done we need to execute the following report
BBP_XPRA_ORGEH_TO_VENDOR_GROUP to get the vendor node to be created under PPOMV_BBP (Vendor Org Structure)
Detailed Procedure --
Execute the report from SE38 ” BBP_XPRA_ORGEH_TO_VENDOR_GROUP”
In the selection criteria for this report , click on the checkbox “Only Run Checks” and check whether it is gives any error or not. If there are no errors, then
uncheck the "Only Run Checks" option and execute the report.
Once executed a screen comes up saying that the node has been created .
Once this is executed then if you look in Vendor Org Structure in PPOMV_BBP you
will find the Node created successfully
Most common errors and their resolutions:
When you try to migrate the Vendor structure then you will encounter errors if
the structure is not proper as per SAP's recommendations.
If you encounter an error , "partner for root node does not have organizational
unit role", then Report BBP_ASSIGN_ROLE_TO_ORGUNIT_BP can be used to assign Org Unit role to the Org unit.
·
If the supplier has not been assigned the supplier role then an error "partner for supplier node has no supplier(bidder) role", then use report BBP_ASSIGN_ROLE_TO_ORGUNIT_BP to assign the supplier role. An option 'Assign Supplier Role' is available on the selection screen of report BBP_ASSIGN_ROLE_TO_ORGUNIT_BP. If this option is not available, then check note 1613293.
If you get an error saying that there is no BP number assigned then we need to execute report “BBP_ASSIGN_BP_TO_ORGUNIT” in order to assign BP number to that particular Org unit. Once this is done then we need to execute the report “BBP_XPRA_ORGEH_TO_VENDOR_GROUP” to get the Org Structure in PPOSV_BBP(Display Supplier Groups)
Whats new with SRM 7.02 in Operational Sourcing area.
Below is a brief on some of the new salient features introduced in the operational sourcing
area with SRM 7.02 i.e. SRM 7.0 Ehp2.
Quick Quote (RFx) can now be created from Shopping Cart -- this is possible at SC line item level. Benefit of quick quote is that stakeholders will know the approximate value of a shopping cart before approving.
Shopping Cart Modifications from Sourcing -- Requirements can be modified in sourcing application(e-sourcing) and changes from sourcing can trigger the relevant workflow process in SRM.
Direct Materials Procurement in Classic Deployment -- Earlier any direct material
procurement in SRM was in extended classic scenario.
Sourcing Graphical Search is now available to provide better visibility into requirements.
The account assignment category “unknown” is supported in external requirements transferred to SRM and local Shopping carts created in SRM. A purchase order created or replicated to ERP with the “Unknown” account assignment category would be transferred to ERP in the held mode.
Create an RFx from a shopping cart with the status 'Awaiting Approval' or 'Saved for quick quotes'
Purchaser can then create an RFx directly from the Item Overview tab of the shopping cart.
Purchasers can update the value of a shopping cart based on the RFx responses before the shopping cart is approved
How to add custom fields to Shopping Cart Item Data Screen
This sounds like one of the most common requirement by any customer -- Addition
of custom fields to Shopping Cart data. With SRM 7.0 , using meta data framework ,achieving this has became really easy. Here is a brief idea on how this can be done
Transaction Code SPRO--> IMG Path -->SAP Implementation Guide --> SAP Supplier Relationship Management --> SRM Server --> Cross Application Basic Settings--> Extensions and Field Control (Personalization) --> Configure Customer Fields --> Define Customer
Fields on Item Level --> In this append the custom fields in the both the structures .
The two structures are:
1. INCL structure with CSF
2. INCL structure with CSF_SC
Append for custom fields to shopping cart item ( to add on item basic data)
Append for custom cross document item data base field ( to save to the data base)
And you need to set the metadata for the custom field based on you requirement. For SC it
is /SAPSRM/V_MDF_IC.
Doing these steps would ensure that you have all the custom fields available for the SC in the database , and available for user on the SC screen. However, if the positions/layout/cosmetic changes are also required, then a webdynpro consultant needs to be pulled in. Its not a tough exercise to these layout changes. Simple changes can be achieved fairly easily an quickly. However, if you are looking at more customer specific action handling on these fields, be prepared to give the abap/webdynpro guy a decent slice in the project plan.
In's and Out's of Quota Arrangement in SAP SRM.
Quota Arrangement in SRM can be extremely useful for companies with huge volumes
of purchasing and multiple contracts with different vendors. It ensures that each vendor gets a fair amount of business from your company, and at the same time ensures that your company is able to maintain healthy relationships with multiple vendor. Thus a win-win situation.
You can use this function in both a manual sourcing process and an automated sourcing process to generate purchase orders. Quota arrangements allow you to define target percentages and distribute them between two or more purchasing contracts. A quota arrangement ensures that a contract is guaranteed both a minimum sales volume and a defined percentage of the total purchasing volume of a product category or product.
When defining a quota arrangement, two things are defined --
1. Guaranteed Minimum
2. Target Value
There are two phases in the validity period of a quota arrangement . These can be
best described as Fulfillment of guaranteed minimums: The quota arrangement first ensures that all guaranteed minimums of contracts participating in that quota arrangement are fulfilled. The sequence
in which the guaranteed minimums are fulfilled is determined by the target percentages defined in the quota arrangement.
Assignment of contracts based on target percentages: Once all of the guaranteed minimums of
contracts participating in a quota arrangement have been fulfilled, the system continues to automatically assign contracts based on the target percentages defined in that quota arrangement. The winning contract is then determined by the relative difference between the actual release value and the target value of the quota arrangement.
You can only create a quota arrangement if a product category or a product is saved in the system, and a contract is available so that you can assign target percentages for the quota arrangement. A quota arrangement uses standard rules to determine the winning contract in the sourcing process. However, the system can redetermine a winning contract with your own logic if you implement a Business Add-In (BAdI) from Customizing. To access this BAdI in Customizing for SAP Supplier Relationship Management, choose SRM Server Business Add-Ins (BAdIs) Sourcing Redetermination of the Contract to be Used (Quota Arrangement) .
A quota arrangement has the highest priority in the sourcing process.
In SRM no configuration is required for Quota arrangement. In SRM NW portal under strategic purchasing tab you will have Quota Arrangements option where you can activate the quota arrangement for a product category / product. You need to enter contract numbers,target percentage and Quota base quantity while creating quota arrangement.
Quota arrangement will not have any effect in sources of supply while creating a shopping cart. If you define contracts in quota arrangement and both are relevant for shopping cart, system will not choose one of them to be displayed. Both contracts will be suggested as source of supply. Quota arrangement has only effect in sourcing cockpit, notduring cart creation
· MM -SUS vs SRM-SUS
· SUS -- Supplier Self Service -- can be integrated with your ECC system or the SRM system. Based on the integration and business scenario, the SUS scenario can be identifiedas a MM-SUS scenario or a SRM-SUS scenario. It is important to understand the difference between these two . Here is a brief on the difference between SRM-SUS and MM-SUS
In MM-SUS, the PO will be created in ECC and sent to SUS. The supplier in SUS will send a PO response as confirmation. Supplier then sends an ASN(Advance Shipping Notification) on the basis of which an inbound delivery will be created in ECC . Using thisinbound delivery a GR(Goods Receipt) can be posted in ECC. Lastly supplier sends an invoice which is accepted or rejects in ECC system. MM SUS works in classic implementation with SRM.
In SRM-SUS, the PO will be created in SRM and sent to SUS. The supplier in SUS will send a
PO response confirmation. Standard SRM-SUS does not support ASN or invoice. This works in
extended classic implementation with SRM.
Please note -- You cannot send ASN or Invoice with SRM-SUS.
Analyzing the SRM SUS scenario, one might think that wouldn't it have been greatif we had the option of ASN / Invoice in the SRM-SUS scenario. This would have certainly strengthened the SRM standalone scenario. Anyways, this is not an option provided as a standard SAP solution. You may want to utilize the SAP Consulting services for a solution to this issue.
Park and Hold Purchasing Documents - SRM Classic Scenario
One of the most common business requirements in purchasing departments is that the users
need an option to save an incomplete purchasing document. SAP provides a function to achieve this requirement in the classic scenario. This function is known as ‘Park and Hold’. You can use this function to complete the data later, or ask another user to check the data.
There are two methods of saving data temporarily:
If your purchasing document contains incomplete or incorrect data, you can hold the document and complete processing later.
If your purchasing document is complete but you want to trigger a workflow to have the budgeting data checked, you can park the document.Thus, using this function purchase orders can be created with the status ‘park’ or ‘hold’in SAP ERP. You must activate the business function SRM_SERVICE_PROC_1 to use this function.
Following is some detailed info on the details of ‘hold’ and ‘park’ status –
Hold
· Completeness status: H
· If you have entered incomplete header data and at least one item for a purchase order, but want to complete the purchasing document at a later time, you can hold the document
· System writes all errors that occur to a message log
· The held document gets a document number and is displayed in the document overview, but no data or statistics in logistics, controlling (CO), or funds management are updated
· Held purchase orders are MRP relevant
· When you process held documents again, you can either hold them again, park them,or post them.
Park
· Completeness status: P
· If you want to have the budget data of a purchase order checked, you can park the document.
· You can only park a purchasing document if the closing check finds no errors other than incorrect budget data.
Parked documents are displayed with their document number in the document overview, and errors are written to a message log
When you process parked documents again, you can park them again but cannot hold them
Difference between ‘Held’ and ‘Parked’ documents
Unlike held documents, parked documents lead to updates in material management data and are used for evaluations in the system.
· Parked purchase orders are MRP relevant.
· How to troubleshoot workflow in SRM
· My SC is struck in workflow approval and I don't know how to check it.
My PO goes to the wrong approver and I don’t know where to see.
Workflow problem..errrr.. I don’t know how to check it.If this sounds familiar to you, read on to know a little bit about how to troubleshoot
workflow problems in SRM --
Workflow processes in SRM are grouped by the procurement document i.e. PO/SC etc.
BBP_PD transaction can be used to get a basic overview of the workflow steps involved
for a particular purchasing document. In BBP_PD, workflow items are provided under the
header -- “Workflow Item:”. Here you will get brief information related to the workflow.
You can find the workflow agents(approvers), users, state , created at , finished at and
some other relevant information.
If you want to see the details related to the workflow of any purchasing document, use
transaction SWI6.
In SWI6, use the object type (business object type) and object ID (purchasing document
number) to see the workflow details related to that document. Use Object Type Category as
BOR Object Type.
Once inside SWI6 you can see overview of all workflow steps for this document. In the
current data section , all the workflow steps can be seen , and these steps have hyperlinks. So if you click on any of them, it leads you to further information related to that step.
Inside SWI6, you can select the workflow and click on the ‘display workflow log’ at the
top in the menu bar.
After clicking the ‘display workflow log’ button, the new screen will have an even more
detailed information on the steps involved in that workflow. Here you can find some more
details related to workflow, you can see workflow agents and workflow objects for the
purchasing document.
In front of every step of the workflow, there are two buttons which can be used to see
the details and the graphical representation of the workflow steps. A third button is
available for steps which involve an agent.
If you want to see more details related to any workflow step, select any step and click
on the button “List with technical details’ at the top. Keyboard shortcut – Shft+F9.
Inside the technical details you can see the details of the workflow step, step history , deadlines, task description , container , message .
If you want to check the data that was passed to the workflow step, navigate to the container tab. Here you will find the container containing all the data involved in processing of this workflow step.
Hope this helps …. Play around inside SWI6 to understand more ..
These steps apply to troubleshooting of both application controlled and process
controlled workflows.
· Item based approval in application controlled workflow
· Item based approval often makes more sense to business as it provides them with
an option to select approver at line item level , based on criteria of individual items.
Incase this approach is used a separate approval of each item is required before it can be
converted to a PO. Also, in case of line item approval process being in place, items which
do not require any approval will have to wait till the approval process for other items in
the same SC has been completed.
Item level approvers can be determined using BADI BBP_WFL_APPROV_BADI. This BADI
is called every time when requester changes SC or approver takes action on it.
Following are the steps to write the logic in BADI for determining line item
approvers --
1) As per your logic, for each item first determine the approvers at each level & assign them approval index. Arrange them in ascending order of their approval index at item level.
2) It is possible that you have multiple approvers for multiple items in the same SC. For sending SC for approval, you will have to generate APPROVAL_OBJECT_GUID for each approver.
For this you have to find out criteria for generating APPROVAL GUID.
For example: If a SC has 3 items. Out of these items if for any 2 items product category is
similar then approvers will be similar for these 2 line items. Similarly for different
Product Category, different approvers are determined. So you can consider 'Product
Category' & 'Approval index' as a criteria to club approvers at each level.
3) Use function module ''BBP_WFL_DIN_APP_OBJ_GET' to generate approval GUID based on
criteria & to update BADI parameter 'ITEM_APPROVAL_OBJ'.
4) Update BADI parameters 'APPROVAL_TABLE' and 'ITEM_APPROVAL_TABLE'.
5) Once SC is approved by all, set 'NO_FURTHER_APPROVAL_NEEDED' flag.
Offline Bidding in SAP SRM
You can use an offline bidding form to allow your suppliers to respond to an RFx without
having to log on to the SAP SRM application. When a purchaser publishes an RFx, an SAP
Interactive Form by Adobe is sent as an e-mail attachment to all suppliers who are authorized for offline bidding. Bidders can be added in the RFx itself using the bidders tab. If the purchaser has used some question functionality in the Rfx, then these questions would automatically be added to the adobe form. This is a very useful feature in the offline bidding process.
The interactive adobe document which is sent as an attachment for offline bidding supports
· Data entry for fields such as quantity, price, and price unit
· Possibility to ask and respond to questions
If the suppliers bid offline, they complete and submit the form using e-mail. The steps involved in offline bidding from supplier’s end is
· Supplier receives the adobe interactive form as an attachment in the email for participation in Rfx.
· Supplier downloads the forms
· Supplier fills up the information in the form. – this process is offline.
· Supplier emails the form to the purchaser.
The purchaser's SAP SRM system
· Receives the e-mail,
· Reads the attachment
· Creates the RFx response from information in the adobe form sent by supplier.
The offline bidding form can be termed as a simplified alternative to the Rfx response.However it cannot be a general replacement for the online creation of RFx responses. If the RFx and the supplier are enabled for offline bidding, suppliers can choose to submit an RFx response online or use the offline bidding form.
The reason why offline bidding cannot be used as a general replacement to the online Rfx
response are listed below
· Buttons to indicate suppliers intent are not available in offline bidding.
· Export to Excel or Import from Excel is not available.
· The option of adding a new line item or subline is not available
· Supplier cannot access a Catalog
· Collaborative bidding via C-folders is not possible via offline bidding
· Option to validate entries for errors (Check button) is not available
· Attachments cannot be added to Rfx response.
· Entering complex prices (Price Conditions) is not possible
· Multiple invited contact person cannot work on the same RFx response
· Response modifications (add alternatives, substitutes, or supplements) is not available.
"No Logical system for FI is maintained" – How to fix this error
This error occurs when the accounting system has not been properly setup in the SRM system.
Make sure that the following entries/configs are maintained in SRM system :
· Attributes ACS and BUK in the organization model (PPOMA_BBP)
· Define G/L Account for Product Category and Account Assignment Category
· Define backend system for product category
· Entries in table BBP_BACKEND_DEST
· If you have performed a client copy of your systems, then the table
BBP_DET_LOGSYS may still contain the old product category GUID from the other system. Make
sure this has updated information.
You can follow the following path in SPRO to maintain tax codes in SRM --
SPRO->SRM ->SRM SERVER->Cross Application Basic setting->Tax calculation->Enter Tax code.
· In SPRO you may define the tax codes that are available for use in SAP SRM.
· You can define a tax code to be used as the default tax code. SRM system will propose this as the default tax code; however this can be overwritten in the SRM document.
· Different tax categories such as Sales Tax, Consumer Tax etc can be defined if you specify an external tax system.
· Tax code is picked from Material Master and vendor master data if you have picked
tax calculation in backend data.
· Use IMG path "Tax Calculation > Enter Tax Code" to enter tax codes. Also if EBP
tax codes are not exactly same as in backend system you need also to enter in "Tax Codes >
Assign Enterprise Buyer Tax Code to FI System" which code in EBP corresponds with code in
R/3.
The main tables for tax in SRM are as follows
· BBP_TAX --Tax Codes for Enterprise Buyer
· BBP_TAXT Enterprise Buyer -- Tax Code Description
· BBP_MAP_TAX_CODE -- (Assign Enterprise Buyer Tax Code to FI System)
· BBP_DET_TAX_CODE -- (Tax Code Determination)
Steps for setting tax determination in SAP SRM
1) Determine System for Tax Calculation: You need select Tax Calculation Occurs in Backend
2) Enter Tax Code: You need copy the tax codes from R/3 backend system (with the same name)
and choose tax category and the default tax code
3) Determine tax code for country/product category: This transaction is optional when you use R/3 tax calculation
4) Assign Enterprise Buyer Tax Code to FI System: You need map the EBP Tax Code with FI Tax
Code and put the FI System (the RFC connection with the backend, it is very important)
How to find current process level in workflow
Use the below code to get the current process level in process controlled workflow. This can be extremely helpful in cases when you want a functionality which depends on the process level of workflow.
Please note that SAP does not suggest usage of this class/method. However, they do not
provide with any alternative as well . :)
data:ls_process_level type /sapsrm/s_wf_process_level,
lo_curr_proc_level type ref to /sapsrm/cl_wf_process_level.
call method /sapsrm/cl_wf_apv_facade=>get_current_process_level
exporting iv_document_guid = iv_doc_guid
importing es_process_level = ls_process_level.
How to determine the last step in an N level approval process
If you want to determine if the current workflow process level is the last in an N-step
approval, then class /SAPSRM/CL_WF_PROCESS_LEVEL, method IS_LAST_LEVEL might not work. SAP
also does not provide any support over this.
However, we have an alternative solution here --
· Get the SC instance from the PDO buffer --
( /SAPSRM/CL_PDO_FACTORY_SC_ADV=>GET_BUFFERED_INSTANCE )
· If the instance is bound, get the source document instance
( /SAPSRM/CL_WF_PDO_IMPL_FACTORY=>GET_INSTANCE )
· Then, get the process info if the SC is instantiated
( /SAPSRM/IF_PDO_DO_APV_EXT~GET_PROCESS_INFO )
· With the exporting parameter ES_PROCESS_INFO, check if PROC_DETAIL_LIST has a
Forecast time indicator. If not, you current process level is the last one.
Long text formatting problem in SRM 7.
If you upgrade from SRM 7 from a lower version , you might face a problem in the formatting of long texts in custom smartforms .
If the long text in the document was originally entered as --
"this is header text.
1. line 1 of text.
2. line 2 of text "
When printed on smartform, it comes up as --
"this is header text.#1. line 1 of text.#2. line 2 of text "
Follow the steps below to fix this --
· Fetch the text for the document.
· Convert longtexts from c(132) to String and replace linefeeds (##) using code
below.
CALL FUNCTION 'BBP_OUTPUT_LONGTEXT_MAP_SMART'
EXPORTING
it_longtext = longtext table
IMPORTING
et_longtext = longtext table import.
· Define a logic for splitting the text lines as per your requirements.for ex,
header text, item vendor text etc. For each different logical split concatenate all text into one single string.
For ex --
LOOP AT gt_ltxt INTO ls_lngtxt WHERE tdid EQ 'HTXT'.
CONCATENATE lv_lngtxt ls_lngtxt-tdline INTO lv_string.
ENDLOOP.
· The string (lv_string) can now be formatted into separate lines, as originally formatted by the user . Use code below for this.
REPLACE ALL OCCURRENCES OF cl_abap_char_utilities=>horizontal_tab IN lv_string WITH '
\t' .
REPLACE ALL OCCURRENCES OF '\t' IN lv_string WITH '' .
SPLIT lv_lngtxt AT cl_abap_char_utilities=>newline INTO TABLE lt_tab.
· The table lt_tab will now have text as per the original formatting of the user.
· Loop at the table lt_tab, and print the text.
Automatic Approval does not work in SRM 7.0 - Process Controlled Workflow
In SAP SRM 7.0, if you are using the process controlled workflow you may create any process
schema as per your business requirement.
But if you use automatic approval in process controlled workflow, the event linkage flag for the object /SAPSRM/CL_WF_PDO becomes automatically unchecked because of the process
schema. Hence the automatic approval does not work.
To fix this problem, follow the steps below --
Start transaction SWE2
Activate the event linkage for the following row
Object category: ABAP Class
Object Type : /SAPSRM/CL_WF_PDO
Event :READY_FOR_RELEASE
Receiver Type: SRM_PROCESS_START
Offline Approval using BlackBerry - SAP SRM 7
There are two options available in which offline approval process can be handled by a blackberry device.
Option 1 -- No additional installation is required on your blackberry.
- The SRM system sends the approval e-mails to BlackBerry users.
- Approvals or rejections are text-based, and can be made by entering 'Yes' or 'No' on your
BlackBerry .
Option 2 -- requires installation of a Java application on your blackberry client
- The SRM server sends the approval e-mails to BlackBerry users.
- Approval or rejection is made via the Java application on the BlackBerry interface.
- Because of the JAVA app, you can easily distinguish between normal e-mails and approval e-mails
Following are the prerequisites before setting up the offline approval process.
- It is important that necessary setting have been maintained in
/SAPSRM/OFFLINEAPPROVALSEND
- In the Customizing activity Change Organizational Plan (transaction PPOMA_BBP), you have
set the attribute FORWARD_WI to 'X' for all users that are to use the offline approval function.
- E-mail address of the system user WF-BATCH is maintained
- E-mail addresses of all users has been maintained that are to use the offline approval function
Important Setting for Extended Classic Scenario - SAP SRM
-- At least one backend MM system and accounting system should be connected to the SAP SRM
system .
-- The settings for the MM and Accounting systems should have been defined in the configuration setting"Define Backend Systems." in SPRO
-- Product categories from the backend system should have been replicated in the SRM
system.
-- The target system for each product category is the backend system in the configuration setting "Define Backend Systems for Product Category" in SPRO.
-- An alternate to point above is implementation of BADI BBP_DETERMINE_LOGSYS to find the
correct backend system.
-- The extended classic scenario is activated in the configuration setting "Activate Extended Classic Scenario"in SPRO.
-- An alternate to above point is implementation of BADI BBP_EXTLOCALPO_BADI to control the
extended classic scenario based on business specific 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 4.6B or higher, you need to map the purchasing group in
SRM to the backend purchase group
-- Use BAdI BBP_PGRP_FIND to determine a backend purchasing group in the shopping cart.
---- If a local pur. group and pur. Org. are used, then a valid backend pur. 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.
Plan Driven Procurement in SAP SRM - Configurations for PDP
Plan Driven Procurement Scenarios :
Plan Driven Procurement with Plant Maintenance
-- This scenario processes requirements that have been generated in systems other than SAP
SRM.
-- This works in Extended Classic Scenario.
Plan Driven Procurement with Supplier Integration
-- This scenario is used to process procurement of Direct Materials from ERP system where
Supplier can collaborate with the purchasing company using SUS. In this case MM-SUS is
implemented
-- Requisitions from procurement system are not pushed to SRM system in this case.
-- Procurement process takes place within procurement system(MM) only.
Configurations
Configuration Required in SRM system --
-- Create a Shopping cart Transaction Type for SCs created by Plan Driven Procurement (if a
separate transaction type is required)
-- Complete the configurations required to activate Extended Classic Scenario in SRM
system. BADI can also be used .
--Create an Entry Channel in the Org Structure for Plan Driven Procurement.This Entry
channel is created in the Organization Structure anywhere under the root org unit.
-- When a requisition is passed to SRM system , a SC is created for this requisition using
an RFC user. This RFC user should have the necessary attributes and roles to create a SC in
SRM system. Appropriate setting should be done on org. structure and SU01.
-- Define Purchasing Group for the product responsibility and organizational responsibility for document processing in SRM
Configurations in ERP System --
-- Create an RFC Connection to the SRM system.
-- Create a profile for the SRM System in table V_T160PR. If multiple SRM systems are
connected, then a separate profile is created for each system.
-- For the Purchase Requisitions to get transferred to SRM System, assign the combination
of Material Group and Purchasing Group to this profile in the table V_T160EX.
-- Use BADI BBP_BADI_EXTREQ_OUT to control transfer of requisitions.
Whats new with SAP SPM 3.0 ( Spend Performance Management 3.0)
In SPM 3.0, SAP has introduced a home screen concept with quick and easy access to all the
features.
A. Create New Content
-- Improved 1 click access to new reports, dashboards, briefing books and alerts
B. Advanced Analysis
-- New features of SPM 3.0 are What if Analysis, Waterfall Analysis, Savings Analysis,
Business Synergy.
-- Advance analysis features from SPM 2.1 are now in a more prominent position. Spend
Advisor, Supplier Risk Analysis
C. Recent documents
-- Displays quick links via report icons to last 3 reports used.
-- Browse all – quick access to the Content folders
D. Favorites
-- End User configurable ; direct links to users favourite reports, dashboards and breifing
books
E. To Do List
-- Displays Alert Notifications
F. Quick Links
-- Configurable links to external sites or intranet content
What if Analysis
What if Analysis is a new feature in SPM 3.0. It is a framework that empowers the end user
to model different scenarios for a sourcing activity.
There are 2 parts to what if analysis
I. Model – a template that is used to build scenarios
II. Scenario – different scenarios can be created from the same model to show different
outcomes.
What if reports uses
1. Global variables -apply to whole report
2. Local variables - apply to the individual lines
3. Formulas – can use report data and global and local variables for calculations
SAP Sourcing Supplier Management - Brief Intro
SAP Sourcing Supplier Management enables the following capabilities:
Centralized supplier database: Create a central repository of all your Supplier records with all the associated documentation including scorecards, financial statements,risk assessments, and insurance certificates can help support periodic supplier reviews to audit compliance.
· Integrated Supplier Portal: Each Supplier has a personalized portal that allows him to view all relevant information to manage their relationship with you. Suppliers respond to bid requests and auctions, view scorecard performance, maintain their own contact and category records, and view active contracts. This holistic and easy-to-use interface greatly reduces the time it takes for Suppliers to become proficient working over the Internet and decreases their cost of doing business with you.
· Supplier Scorecard Sharing: The ability to easily track and analyze supplier performance can reduce risk and costs. SAP Sourcing’s flexibility allows you to establish metrics and evaluation criteria based on category and region. For reporting purposes, you can generate a scorecard over periods of time, such as each quarter, to monitor a supplier’s progress over the course of a year. Automatic assignment of traffic light indicators quickly highlights areas requiring attention from Supplier managers. The ability to share Supplier scorecards through the Supplier portal enables full collaboration and sharing of information to ensure optimal performance.
· Supplier Self-Registration: Suppliers can self-register in SAP Sourcing, or you can invite them to become users. The registration form can be configured to collect the most relevant information to accelerate the supplier qualification process. When new Suppliers are accepted, their registration form responses are used to generate the initial Supplier record.
· Supplier Profile Maintenance: As the supplier information changes, Suppliers can
update their product and contact information through the Supplier portal, saving the Sourcing organization from the administrative burden of researching and updating supplier
information.
· Supplier Relationship Activities: A successful Supplier relationship is built and sustained over time through a series of ongoing, recurring activities. These include routine tasks such as safety, insurance, and diversity certifications, as well as strategic joint meetings and planning activities. SAP Sourcing delivers an automated tracking and alert system that enables you to manage Supplier-specific activities with less effort. The system automatically sends alerts to Suppliers when tasks are due. In response Suppliers can modify profile and contact information and send updated certificates online through the SAP Sourcing Supplier Portal and the new, reviewed information is updated directly to the Supplier record.
· Supplier Diversity Promotion: SAP Sourcing offers a unified system to help increase the number of qualified diverse suppliers, achieve desired participation and award rates, and track compliance without additional resources. For example, diversity qualifications seamlessly flow from the self-registration form, to the Supplier record, to RFx responses for “extra credit” on scoring. Buyers inviting suppliers to events now have easy access to a single, searchable supplier database that includes category, location, and diversity information, lowering the threshold for compliance.
· Need of storage locations in SAP SRM
· In Storage Location Section of Extended Attributes we can maintain Storage
Locations which are synonymous with Storage locations in R/3. The values maintained here
will be available for the user to select as storage location while creating shopping carts.
· Storage locations are required in SRM in case of direct procurement scenario.
· If you order the material as direct procurement while creating the shopping cart, (direct procurement tab) the cost assignment filed will not be displayed and the valuation happens based on the Valuation class (material master). The material gets received and stored in the storage location. So mentioning a storage location is mandatory in this case which is not the case if you order it as indirect material.
· How to : cross company purchasing - purchasing group from one company buys for
another company
· In this article I am referring to a scenario where you want buyer of purchasing
group of one company to do the purchasing for another purchasing group belonging to another
company.
Consider the org set up as --
-- 2 separate companies A and B exist under the root node
-- Company A has Purchasing Org A .
-- Purchasing Org A has Purchasing Group A
-- Purchasing Group A has Buyer A responsible for product category X
-- Company B has Purchasing Org B .
Buyer A should do the purchasing for product category X for purchasing Org B.
This can be done using the responsibility tab of Purchasing Group A.
Assign the Org ID corresponding to Purchasing Org B under the responsibility tab of purchasing group A.
Now Buyer A would be able to do purchasing for purchasing org A and B which belong to
different companies.
SRM Content for PI 7.11
If your landscape has ECC 6, SRM and PI 7.11 system , following components are required for
ERP -- XI -- SRM system integration.
· XI CONTENT SRM
· XI CONTENT SRM_EXT_FUNC
· XI CONTENT SRM_EXT_FUNC IC
· XI CONTENT SRM SERVER IC
· XI CONTENT SRM SERVER
Above scenarios are must if you want to implement --
· Contract Management scenario
· Centralized Sourcing
· Plan Driven Procurement with Supplier Integration
If you are planning to use SRM-MDM catalog then 'XI CONTENT SRM-MDM CATALOG' is also
required.
PO replication from ERP - SUS (MM - SUS)
Follow the steps below in ERP for PO replication to SUS --
Maintain Event Type Linkages for Purchase Order Output in PurchaseOrderERPRequest_Out_V1
SOA Service (Supplier Self-Services Scenario)
1. Run transaction Display/Maint. Event Type Linkages (SWETYPV).
2.Choose New Entries.
3.In the Object Types field, enter CL_SE_PUR_WF_OUT.
4.In the Event field, enter CREATED.
5.In the Receiver Type field, enter WS53800008.
6.In the Receiver Function Module field, enter SWW_W1_CREATE_VIA_EVENT_IBF.
7.Select the Linkage Activated checkbox.
8.Save your entries.
9.Choose New Entries.
10.In the Object Types field, enter CL_SE_PUR_WF_OUT.
11.In the Event field, enter CHANGED.
12.In the Receiver Type field, enter WS53800008.
13.In the Receiver Function Module field, enter SWW_W1_CREATE_VIA_EVENT_IBF.
14.In the Check Function Module Field, enter OPS_SE_PUR_CHANGED_EVENT CHECK.
15.Select the Linkage Activated checkbox.
16.Save your entries.
You can use the BAdI PUR_SE_PO_INTERFACE_OUT_SELECT to control which outbound services are to be sent in relation to the purchase order.
SRM Error - Supplier X not intended for pur. org. Y
This error can be encountered in the a scenario where SRM central contract is not used for
local sourcing and the supplier is has not been assigned to Purchasing Org. of the user.
There are 2 ways to fix this error --
1. The most obvious thing is to assign the purchaser to the pur. org. of the user.
2. However, if there is a business requirement as per which the supplier should not be
assigned to the purchasing organisation, then follow the manual steps below to make this
error message customizable.
1.Go to the transaction SM30
2.Go to the View BBPV_PDMSG
3.Click on new entries to add a new entry in to the view
4.Add BBP_PD for the Applic Area column
5.Add 018 for the Msg field Column
6.Add BUS2000113 for the Object Type Column
7.Add EWI for the Allowed column
8.Add 'E' for the Standard Column
-- Save changes made by the activity mentioned above.
1.Go to Transaction SM30
2.Go to the View BBPV_PDMSG_CUS
3.Provide the Object type as BUS2000113
4.Add BBP_PD as the Message Cl (Message Class)
5.Add no as 018
6.Add Type as 'W'
7.Add E as standard
Save the Changes to the View.
Refer SAP Note 1531626 for more details.
Company Code & Plant mapping not updated in SRM
If you make any change to the company code & plant mapping in the ERP system and replicate these changes to SRM by running a program BBP_GET_location_selected or BBP_GET_location_all
, the mapping in SRM is not updated.
One way to fix this problem is --
You can change the company code assignment for the plant from the web portal if you have administrative role.
Follow the path:
Administration > Location tab > Here select the Plant(i.e. Location) to Edit mode >
Then select your logical system > Under location mapping, change the company code and save it.
Now you can see the updated result under the extended attribute section in PPOMA_BBP.
Alternatively, you can see the results in table BBP_LOCMAP in SRM system.
How to restrict the type of documents that can be created from Sourcing Cockpit
In SRM , the purchaser has by default an option to create a Rfx / Contract or a PO from the sourcing cokcpit (Assign Source of Supply). This option is available from the dropdown on the button in the tool bar which provides a list of follow-on documents that can be created. Many business require these option to be restricted i.e. for ex. a purchaser should be presented with an option to create a PO only, which means the purchaser should not be presented with the option to create Rfx or contract .
This requirement, which looks like a webdynpro enhancement , actually requires a 2 step procedure.
1. Go to SM30 and enter /sapsrm/v_soco
2. Uncheck the document types that are not necessary
3. Save
Documents in Strategic Sourcing - RFI / RFP/ RFQ / Auctions
In this blog I have tried to provide some basic understanding on the commonly used documents in strategic sourcing process. These documents are RFI , RFP , RFQ and Auctions.
Read on to learn a bit about these --
An RFx is a sourcing document that enables you to request information, quotes, and prices
regarding goods and services from multiple suppliers.
RFP - Use this document type to solicit bids on goods and services. It can include complex
questions and criteria and can facilitate your decision-making on sourcing choices.
RFI - Use this document type to elicit information from vendors about their organizations,
goods, and services.
RFQ - Use this document type to solicit price quotes on specific goods and services when
pricing and costs are the primary concern.
Auctions - An auction is a strategic sourcing event that is used to negotiate the best value in a short period of time. In an auction, suppliers bid to provide products and services. An auction can occur on its own or in conjunction with an RFx. Unlike an RFx,which can go on for weeks, auctions typically last for a few hours to a few days. Although auctions can be either reverse or forward, you typically use reverse auctions for your sourcing events. In a reverse auction, the price drops as the auction proceeds, whereas in a forward auction, the price increases as the auction proceeds.
How to replicate HR Org Structure from ECC - SRM
Option 1:
· You can schedule the report RHALEINI in SRM by maintaining variants as per the requirement. The variants should be created for object type 1000 and 1001 and for different
relationship types. You can schedule this report as required. The suggested way is to schedule this report once daily , after the close of business hours, as it tries to send the whole org structure by creating IDOCs.
Before scheduling this report, you need to do the config for the following things in SRM.
· Maintain and distribute the distribution model -- In transaction BD64, maintain and distribute model view for the message type HRMD_ABA (org structure related changes).
· Maintenance of Idoc and message type -- In WE20, create a partner for ECC/ERP
system under "Partner Type LS". Maintain message type "HRMD_ABA" under outbound parameters.
Go to details and check the radio button "Transfer IDOC immediately" under "Output Mode".
This will help to transfer the IDOCs immediately from SRM to ECC/ERP as soon as they are created in SRM.
Option 2:
Option 1 might create performance issue if the org structure is a complex one having manynodes. In order to overcome this issue, you can distribute the org structure via change pointers. This will replicate only the changes made to the org structure. You need to follow the below config steps in SRM.
· Activate Change pointers -- You can use transaction BD61 or navigate through SPRO
--> IMG --> Supplier Relationship Management --> SRM Server --> Technical Basic Settings
--> ALE Settings (Logical System) --> Distribution (ALE) --> Modelling and Implementing
Business Processes --> Master Data Distribution --> Replication of Modified Data --> Activate Change Pointers - Generally. Tick the option "Change Pointer Activated -generally".
· Activate Change pointers for HRMD_ABA -- Navigate through SPRO --> IMG -->
Supplier Relationship Management --> SRM Server --> Technical Basic Settings --> ALE
Settings (Logical System) --> Distribution (ALE) --> Modelling and Implementing Business
Processes --> Master Data Distribution --> Replication of Modified Data --> Activate Change
Pointers for Message Types. Activate for message type HRMD_ABA by ticking the check box.
· Maintain and distribute the distribution model --In BD64, create a distribution model for message type of HRMD_ABA and maintain filters for different info types (object type 1000, 1001 , relationship types like A003, A008 etc). Then distribute the model view to ECC.
· Maintenance of Idoc and message type -- In WE20, create a partner for ECC/ERP
system under "Partner Type LS". Maintain message type "HRMD_ABA" under outbound parameters.
Go to details and check the radio button "Transfer IDOC immediately" under "Output Mode".
This will help to transfer the IDOCs immediately from SRM to ECC/ERP as soon as they are
created in SRM.
· Schedule the report RBDMIODC in SRM to create the IDOCs from change pointers.
This report can be scheduled as required . Suggested practice is to schedule it once or twice daily.
· Schedule the report RBDAPP01 in ECC to post the incoming IDOCs from SRM.
Tables containing Attribute and HR relationships
Following are few tables that contain a lot of information related to attributes and HR
data and other relationships.
Basic table for attributes is T77OMATTR
Following are the tables that are updated with attributes.
HRP1222 (Infotype 1222: General attribute maintenance)
HRV1222B (View of Attributes)
HRV5502A (SRM Location)
HRP1000 (Objects details_link to Code)
HRP1001 (Relationships to other objects)
HRT1222 (Table Section Infotype 1222: General Attribute Maintenance)
HRV5500A (SRM: Selection Help for SRM Function)
HRV5500OT (SRM Function (OTJID))
HRV5501A (SRM: Selection Help for Product Responsibilities)
HRV5501OT (SRM Product Responsibility (OTJID))
HRV5502A (SRM Location)
HRV5502OT (SRM Location (OTJID))
BBP_ATTR_ACCESS (Attribute Access Mode)
BBP_ATTR_DFT (Default Values of Basic Attributes)
BBP_ATTR_VALUE_T (Text for SRM Attribute Values)
How to find data of a specific attribute in the SRM system
If you want to see specific attributes of a BP in SRM , follow the steps below --
· Look for the relation of the object in the table HRP1222. Here you can find the field TABNR and then select the table HRT1222 with key TABNR
· In the table HRT1222 you have a field named ATTRIB, here you can take the requested Attribute key eg. BUK, ADDR_BILLT. The values are stored in fields LOW and HIGH
(possible interval values, if no intervals, the LOW field is used).
Important Tables that store attributes and other HR information can be found here.
You may use the function modules BAPI_USER_GET_DETAIL , BBP_OM_FIND_SC,
RHGA_READ_TREE_UP_SET etc.
Features of Self Service Procurement
- Employees can create and manage own requisitions
- SC Wizard for employees
- SC Pro for purchasers and purchasing assistant
- Shop on behalf of for purchasers and purchasing assistant
- Service Request and Service Order can be created using professional SC.
- Cross catalog search to search in multiple catalogs
- Tax calculation can be done in SAP R/3, External tax system , in SRM , or SAP Transaction
Availability check is executed in all the plants defined in user attributes.
Procurement cards Features
- Can be used only in SC on if local PO in standalone
- Not available for local PO in Extended Classic.
- User has valid procurement card master record.
- Budget Check is performed w.r.t. WBS , Co Internal orders or Fund Management objects
- If fund management component is used than an availability check on components for account assignment can be done.
Statuses of a SC
- Saved
- Awaiting Approval
- In your inbox
- Rejected
- Contains Error
- My personal template
- Public Template
- My favorites ( single items)
- Open for confirmation – auto creation of full GR in background
- Open for Invoice – auto creation of full invoice in background
Follow on Docs for a SC
- PR
- PO
- Reservation
- GR / Service Entry Sheets
- Invoice
With SRM 7.0 , only SRM-MDM catalog can be used.
SRM Specific Inbox à UWL (NW Portal)
- Substitute Buyer has to be defined in user settings -> Name of substitute Goods Receipt/Service Entry / Time Entry are handled by one confirmation scenario single document Confirmation
- Backend confirmation is created for Backend PO (irrespective that they exist in SRM or
- not).
- Return Delivery for backend PO -- GR is created with movement type 122.
- Return Delivery for local PO – local return delivery is created.
- Deleted confirmations are known as cancelled or reversed transactions.
- In CNF Reference Document field has 40 characters, only 16 are transferred to backend.
- Tolerance Check in Invoices
- DA – Exceeded cumulated value (Value/percentage)
- DO – Exceed amount, quantity variance (Value/percentage)
- LA – Amount of limit PO (Value/percentage)
- LD – Limit purchase order, time limit exceeded (valu)
- PP – Value Variance for single value (Value/percentage)
Status of invoice or credit memos
- Post
- Save
- Check
- Refresh
- Change
- Recreate – current changes in PO or GR are taken into account
- Cancel – revers invoiced values and generates an offsetting document in DO
App Controlled Workflows in SAP SRM 7.0
- WS10400022 -- Contract Alert Workflow
- WS10000192 -- Approval Workflow for Internal Users
- WS10000209 -- Approval Workflow for new bidder/supplier
- WS10000093 / WS 100000100 -- Procurement Card Approval.
Rest all the workflows have been migrated to process controlled workflow.
Process Controlled Workflow
Process Controlled Workflow features
- Supports N step approval
- Supports different process levels – approval , completion , review etc
- Supports different decision levels – header / item / partial doc.
- Supports diff roles – manager, reviewer, specialist etc.
- Process is evaluated using process schema
- BRF can be used to control the process flow further. BRF is provided by SAP NW.
- SRM Specific inbox is UWL.
- Process controlled WF is available for PO, SC, CNF , PO Response, Quote, Invoice, Contract,RFx.
Process Type – Approval with Completion allows purchaser and approver to communicate.
Decision set and decision type for ad-hoc agents are identical to ones in the current process levels.
Reviewers can be added and they can – display the doc/attachment, add notes and reviews.
System can insert reviewers on its own.
Process schema uses the BRF for evaluation
A process schema encapsulates the draft of approval process for a business object. There
can be various process schemas for a single business object.
BRF event refers to a BRF expression which determines a valid process schema. BRF
expressions can be nested.
Decision types in process controlled workflow
- Decision on entire document (at header level)
- Item based Decision for entire document ( on item level – all items)
- Overall decision for partial document ( header)
- Item based decision for partial document.
- Only SC supports all 4 decision type. However Process Schema step ‘Completion ‘ – only 1 and 2 are supported. Because 3 and 4 are for partial. Contracts and PO’s support 1 and 2 . All other docs support 1 only.
BC Sets – pre delivered. Uploading a BC set creates events, expressions, process schema and
levels for basic approval process. TXN SCPR20.
SAP SRM and ERP on the same client
If SRM / ERP on same client – only few business scenarios are supported
- Self service procurement in classic.
- Service procurement for external staffing – whole scenario in SRM in standalone
- Supplier collaboration with SUS – SRM SUS and MM SUS connection.
Constraints with one client
- Multiple backend functions are not supported
- Upgrade or migration from a separate SRM system to SAP ERP 6.0 with SRM in one client on ERP is not supported.
- No migration path from SRM one client to standalone SRM.
- Extended classic is not supported.
SAP SRM Business Scenarios
- Self Service Procurement – Classis Scenario.
- Self Service Procurement – Extended Classic Scenario
- Plan Driven Procurement with Plant Maintenance – Demand is transferred to SRM using openXML
- Plan Driven procurement with supplier integration – procurement of direct materials.
- Service Procurement – Classic Scenario. à PR in MM à RFx in SRM.
- Service Procurement – External Staffing – this process starts when a request is sent to supplier Catalog Management
Spend Analysis – uses SAP NW BI. Harmonization of data can be done using SAP NW BI,
integrating SAP BI with SAP MDM or local master data alignment (for limited data volume)
Supplier Evaluation.—this can be integrated with confirmations, invoice and supplier list
to evaluate vendor on day to day operational procurement information. Evaluation and
monitoring of supplier performance runs in SAP NW BI.
Operational Contract Management
Strategic Sourcing with RFx. – can be without integration of sourcing cockpit.
Strategic Sourcing with live auction – with or without sourcing cockpit.
Vendors can be created in the following manners
- Manual
- From CSV
- From SAP ECC
Defining a Backend System based on product category
In SAP SRM,Based on product category follow-on documents creation is determined i.e.
locally or in a backend system. This kind of scenario is referred to as decoupled scenario.
Configuration Please follow the path mentioned below :
SPRO →Supplier Relationship Management → SRM Server → Technical Basic Settings → Define
Backend Systems → Define Backend System for Product Category.
We can use BADI BBP_DETERMINE_LOGSYS to define backend system based on our business logic.
During determination of backend, back end system value is placed in ITEM_DATA-
LOGICAL_SYSTEM field of BADI BBP_DETERMINE_LOGSYS.
Use method DETERMINE_LOGSYS to determine backend system for SC. We can modify the value of ITEM_DATA-LOGICAL_SYSTEM based upon the value in ITEM_DATA OR ACCT_DATA.
Sample code for BADI BBP_DETERMINE_LOGSYS:
Create an implementation for BADI BBP_DETERMINE_LOGSYS.
method IF_EX_BBP_DETERMINE_LOGSYS~DETERMINE_LOGSYS.
data :lt_item TYPE LINE OF bbpt_detlogsys_item.
Loop at item_data into lt_item.
If lt_item-product_type = ‘A1’. “product type
If sy-sybrc = 0.
Lt_item-be_co-code = ‘1111’. “‘company code
Lt_item-logical_system = ‘A1CLNT100’. “logical system
Modify it_item from lt_item.
Endif.
Endif.
How to Hide a Tab of Shopping Cart Screen in SAP SRM 7.0
Follow below steps to hide tab in Shopping cart screen:
Click on the tab which you want to hide in Shopping cart Screen.
Find the Webdynpro component and view by right clicking on the SC screen.You can find the
information in "More field Help".
For tabstrip enhancement the webdynpro component which can be used is
/SAPSRM/WDC_UI_SC_DOFC_D1.
Goto SE80 and display /SAPSRM/WDC_UI_SC_DOFC_D1 Webdynpro component found in above step.
Create an enhancement implementation for Webdynpro Component.
Goto Layout tab of enhancement and choose the tabstrip which you want to remove.
Right click on that particular tab and choose "Remove element form Tab ".
Activate the enhacement implementation .Now tab will not appear in SC screen.
You can revert the changes made in the enhancement to original screen.
Product Categories in SRM
- Product Categories are used to group products together.
- Back end product categories are replicated to SAP SRM using CRM middleware.
- If SRM is on one client scenario (for detail of one client scenario , read older post), then replication of product categories is not possible using CRM middleware. In such case, a different approach is used for replication.
- Product category hierarchies can also be uploaded from external files via XI and file adapter
After all the relevant settings have been done on ALE and IMG for backend systems,
BADI BBP_DETRMINE_LOGSYS can be used to determine the backed system for a product category.
This is particulary useful in decoupled scenarios.
Classic Scenario --- PR is created instead of a PO or Reservation in backend
Problem Statement
You create a SC in your SRM system and you expect a purchase order or a reservation to be
created in the back end. However, a purchase requisition is created instead. And you keep
guessing why !
The system determines the object type of the follow-on document after you
save the shopping cart. When determining the object type, the system checks
SRM Customizing ('SPRO' -> 'Supplier Relationship Management' -> 'SRM
Server' -> 'Cross Application Basic Settings' -> 'Define Objects (purchase
requisitions, reservations, purchase orders) in Backend System'), but the
actual decision is made in the backend system. In the backend system, the
system reads the SRM Customizing and the document data of the shopping
cart:
o The system first checks whether Customizing was created for the
current purchasing group or product category (Example for
purchasing group 'EKG1' and product category 'KATEGORIE1'):
Purchasing group Product category Sequence
EKG1 KATEGORIE1 1
* KATEGORIE1 2
EKG1 * 3
EKG1 KAT* 4
* * not allowed
* KAT* not allowed
EK* KATEGORIE1 not allowed
The system always uses the first entry: If a valid entry is found, the system does not check the next level (1..4).
For Customizing entries that are not allowed, the system automatically converts the object type of the follow-on document to purchase requisition.
The application data of the shopping cart is validated (SOS,material, ...) in the next step.
If the purchase order that was chosen in SRM Customizing cannot be created in the backend system, the object type of the follow-on document is automatically set to purchase requisition.
BAdI:
The follow-on document type that is determined can be overridden by the BAdI BBP_TARGET_OBJTYP. After calling this BAdI, the system no longer checks the document type against the backend system. If the overridden document type (reservation or purchase order) cannot be created in the backend system, however, the system also does not create a purchase requistion as an alternative. Instead, the system creates an entry in the alert monitor under 'Backend Application Errors'.
Troubleshooting:
If the system creates a different follow-on object than expected, check
whether Notes 140846 and 787045 are implemented in your backend system.
For the necessary Customizing settings, see Consulting Notes 157887 and
336658. Check also in Customizing: SPRO -> 'Supplier Relationship
Management' -> 'SRM Server' -> 'Technical Basic Settings' -> 'Define
Backend Systems' -> 'System Type' whether the release of the backend system
is the latest release.
How to analyze Shopping Cart Transfer Process
The Shopping Cart (SC) transfer is the process during the follow-on document is created to
the shopping cart, which has been ordered by the requester. It is started by the workflow
event ‘SetReleased’ and ends with the triggering of the follow-on document creation
eventually by updating the alert entries. Since the workflow is executed in the background,
it takes also the transfer into the background, therefore it is not possible to debug the process in dialog mode after ordering the SC, the code won't stop at the preset breakpoints.
This blog gives a short overview about the most analyzed points of the transfer.
How can be the transfer started?
The SC transfer is triggered by the function module BBP_PD_SC_TRANSFER. This needs only the
GUID of a transferable shopping cart as an input. Transferable shopping cart means, that it has no errors and has at least one item without the status I1111 (item in transfer process) I1113 (follow-on document created).
Steps to start the transfer:
- Create a new shopping cart (which is free of errors) and set it on status 'hold'.
- Copy the SC GUID from the transaction BBP_PD
- Execute the function BBP_PD_SC_TRANSFER with the SC GUID in debugger mode
Please note, that by this kind of manual transfer the workflow steps are not executed, and
the workflow will stay in the status Waiting even after the follow-on document is created.
Don't use it therefore in production system.
How to analyze the creation of follow on documents in backend system
Following are the steps for analyzing for the typical problem related to creation of
documents in backend system.
The B31I_INTERPRETE_DATA is responsible for defining the type of the follow-on document
(Purchase Order, Purchase Requisition or Reservation) in classic scenario.
The B31I_INTERPRETE_DATA calls the plugin function BBP_INTERPRETE_DATA of the backend system via RFC. The decision about the type of the follow-on document is made in the backend system, depending on the SRM customizing (proc_cust_backend) and the item data
lt_procurement_item). The result is returned in the field lt_procurement_item[]-OBJ_TO_GEN,
whereby 1=reservation, 2=purchase requisition, 3=purchase order.
Debugging:
- Set the RFC user to dialog
- In the transaction SM59 of the SRM system check the name of the RFC user which is used for the RFC calls
- logon into the backend system, and set this user to dialog
- Set a breakpoint in the function B31I_INTERPRETE_DATA (in the SRM system)
- Start the SC transfer – using FM BBP_PD_SC_TRANSFER
- When you reach the breakpoint, jump with F5 into the backend system
‘ CALL FUNCTION 'BBP_INTERPRETE_DATA'
DESTINATION destination
You are now in the backend system. Set a watchpoint to the fields 'purchasing',
'no_reservation', 'procurement_item-obj_to_gen', 'reservation'
When you stop at these watch-points, you will see why the object type is taken (e.g. one of the typical reasons is, when the Source is Supply is not correct).
The type of the follow-on document will be sent to the SRM system in the
fieldlt_procurement_item[]-OBJ_TO_GEN with the value 1, 2 or 3.
At the end of your analysis don't forget to change back the RFC user to system user in the
backend system.
BBP_PD 427 - Enter no more than one partner of type Vendor
When creating a shopping cart, you select the preferred vendor. Error message BBP_PD 427 is
raised - Enter no more than one partner of type Vendor.
This error occurs when you convert preferred supplier (partner function 39) to fixed
supplier (partner function 19) using BBP_DOC_CHANGE_BADI.
BBP_DOC_CHANGE_BADI is triggered twice after an update, which is as per SAP’s design.
After the first call, if the change occurred from partner function 39 to 19, then the same
is updated to PD layer.
Therefore in order to ensure that you don't add this again (i.e. two partner function 19),
you have to do BBP_PD_SC_GETDETAIL call to get the updated PD partner information.
Then do a check in this partner table and see if fixed vendor(partner function 19) already
exists. If so, do not add it again
Currency integration between SRM and ECC
This topic will give you a brief overview about how does the currency integration works
between SRM and ECC systems. The intent is to explain the integer and decimal system in SAP system, as well as the behavior in the database and in the User Interface (UI).
The next paragraphs will show the behavior of the currency decimals in SAP system and the
integration between SRM and ECC. A table will be present to demonstrate what is the impact of the value in column “Decimals” (table TCURX).Identifying the versions of your applications
Currency fields.
The value of data stored in currency fields depends on the decimal places defined for thecurrency. SAP Standard takes as 2. Therefore the value will be the same if the currency is defined for two decimal places (relevant to transaction OY04).
The transaction OY04 allows currency maintenance and its decimals. However, the value in
the “Decimals” column doesn’t mean the quantity of decimals. If you place a value of 0 (zero) in this column, so this currency will show values divided by 100.
Find below the list of values for “Decimals” column, as well as its behavior:
Decimal Places Value of price in stored in table
0 /100 (Divide 100)
1 /10 (Divide 10)
2 No Conversion(Standard)
3 * 10 (Multiply 10)
It is recommended to have the same decimal place configuration for both SRM and ECC
Backend.
The reason why the values in the database (transaction.BBP_PD-> BBP_PDIGP or in
BBP_PROCDOC_GETDETAIL) are different at decimal positions from UI fields is because as per the standard design the internal price structures and database structures has only 2 decimals places.So they can’t hold more than 2 decimals. Due to this reason, it is not possible to store 3 decimal positions in the database same like in UI. This is the standard system design and this can’t be changed.
The need for using Service Procurement scenario
Services procurement can be challenging due to the complexities involved in defining the
quantity, duration, and price of services to be consumed. SAP SRM Services Procurement
helps you manage procurement resources and monitor costs for a wide range of services
commonly used across major industries such as time-based and deliverable-based services.
This includes service demand that originates in your back-end SAP ERP application. With
sourcing, contract management and supplier enablement, the application enables you to
improve services procurement activities on an end-to-end level and establish cost-saving
measures.
SAP SRM helps facilitate and coordinate services-supplier collaboration: define and price
services and bid for the best supplier based on cost, availability, and other terms. The
result is an increase in the speed and visibility of the services procurement process. With
the application, you can drive business value across the company and streamline the
procurement of services with enhanced RFx functionality
An organization that does not have a clear strategy for an end-to-end procurement process
for services only applies an ineffective procurement process which ultimately results in
high costs for the company. The procurement group often has only decentralized control over
services procurement. Numerous lines of business are involved in purchasing decisions, such
as Human Resources, Finance and Maintenance. This decentralized control makes it difficult
for procurement to gain full visibility into total expenditures and the suppliers engaged.
This is coupled with the challenge of employees using unauthorized suppliers, rather than
utilizing procurement-approved suppliers for their services needs.
Manual, non-integrated processes result in long procurement cycle times, and also increase
the margin of error. For example, service delivery information might not be linked to the
negotiated terms, making oversight very difficult. The lack of supplier collaboration
results in poorly-defined requirements, and a disconnect during the purchase order, service
confirmation, and invoicing processes.
Services Procurement with SAP SRM supports a company in managing resources and monitoring costs over servicessupports complex categories such as maintenance, construction, IT, and temporary labor centralizes management of services spend enforces compliance by engaging approved suppliers at the negotiated rates enables supplier collaboration on service definitions, bid responses, purchase order delivery, service confirmations, and invoice distribution
Plan Driven Procurement -- refresher
Direct procurement refers to procurement of direct materials for inventory
Demand from production is transferred to SRM using open XML.
Process in Plan Driven Procurement
- Planning – generally done in backend MRP or APS systems.
- Ordering – Auto PO generations – if only single source of supply exists.
- Source of Supply – if multiple source of supply then purchaser can select one.
- Third party processing – vendors can have an insight into org’s inventory.
- Confirmations and invoicing
Sourcing Integration with Direct Procurement
Customizing can be set up so that the requirements are transferred into sourcing directly.
External Classis – requirements from backend come to SRM assign source of supply
PO created directly in back end.
For external classic requirement , SRM does not automatically assigns a source of supply.
This is a manual process.
In extended classic , sourcing with backend contracts and purchasing info records is not supported.
Manual Direct Procurement With contract / Without contract / local contract can be used.
If account assignment is Cost Center, the item would be treated as a consumable item.
When the checkbox ‘ Order as Direct Material’ is selected, account assignment tab disappears and the account determination is done in backend automatically.
Direct Procurement in SRM always follows extended classic scenario.
Service Procurement with external staffing - certification refresher
Service Procurement External Staffing –
Create request for external staff – Purchasers , Requestors and Purchasing Assistants can create a request for information.
While requesting for external services request can ONLY be created if there source of supply for related service master .This essentially means that even if a new vendor is selected for providing external services even then the vendor has to be set up as a source of supply using contracts ,vendor list etc.
Hierarchal display of service items is possible only in EC or standalone scenario.
Pricing is dependent on sourcing.
Priority while determining pricing
- Manual
- Contract
- Product linkage
- Product master
Price cannot be determined if
- Free text items are used
- Vendor is determined based on vendor list
- Vendor determined on product category contract
- In such case vendor enters the price in the bid and upon acceptance of bid this priceis transferred to the PO.
available to purchasers and purchasing assistants.
Procurement of external services can be done in classic, standalone and EC scenarios.
After a vendor has responded to an RFI , a PO can directly be created from this by using
the ‘submit request’ button in check status of application. This activity can be performed
by employees, purchasers and purchasing assistant.
A quick entry screen is available for professional users to enter service requisition
quickly. There are certain service specific entry fields which can be used to enter limits,
expenses and other specific details. A service provider is a specific employee of a vendor which can be a SUS user or can be a contact person for a vendor.
Services can be selected from internal or external catalogs. Source of supply can be contracts as well.
Service Procurement Classic with Hierarchies - certification refresher
Service Procurement Classic with Hierarchies -- SRM 7.0
Transfer PR in ECC with hierarchies to SRM sourcing cockpit. System can be configured to
send requirements directly to RFx. If sent to RFx directly it would not be shown in carry
out sourcing.
In a hierarchy, the levels are
- Service item – top most level. Item category D.
- Service outline – defines the outline function
- Service line – qualitative and quantitative description of services.
E-SOA is used for transfer of hierarchies,before srm 7 / ecc 6 ehp 4 , only materials could be passed to srm.
Transfer of hierarchies possible only in classic scenario.
Types of limits which are transferred:
- Overall limit – total of unplanned items in a document.
- Expected value – included in net price of an item.
- No limit – service line level.
Line type indicators can be transferred from ECC to SRM. When a PR is saved in ECC It can be transferred to SRM automatically.
BADI ME_REQ_SOURCING_CUST is used in ECC to decide the auto/manual transfer/no transfer. This BADI is required to transfer materials/services and this replaces config in ECC and use of
report BBP_EXTREQ_TRANSFER.
CPPR – Collective processing of purchase requisitions – can be used for transfer of PR. This is available in role operational buyer.
Hierarchies are supported in srm 7 , ecc6 ehp4 by
- External requirements
- PO in SUS / PO response
- RFx / Rfx response
Confirmation in SUS
- A service item with all service outlines and service lines is considered as one item.
- For external requirements, sourcing is carried out at service item level.
- If external requirement contain hierarchies, it cannot be edited.
- Replace with catalog items is not possible for service structures.
- Local contracts in SRM cannot be used as source of supply. Only backend contracts and supplier list as source of supply.
- If an external requirement contains hierarchal services, then only a classic PO or backend contract would be created.
- MM-SUS solution supports the hierarchal services.
Direct Material Procurement Process in SRM
How is a material classified as a direct material?
A direct material is used directly in production process and it is mostly held on stock. A
direct material has an impact over the value of the finished good or product.
How to configure SRM system for direct procurement ?
Settings on SRM Server
- Set up transaction type and number ranges in IMG
- Replicate the locations(plants) from the backend systems. This can be done using report
- BBP_LOCATIONS_GET_FROM_SYSTEM set up attributes DP_PROC_TY as transaction type for all direct material procurement
- Replicate the products(materials) from the backend material.
Settings on ERP
Set up document type and number range for direct material purchase order corresponding to
SRM Server.
Also , please remember, in direct material procurement the system always behaves in
extended classic scenario i.e. SRM server is the leading system for direct procurement.
Whats new with SAP SRM 7.01
A lot of new features have been introduced with the Ehp1 for SRM 7.0. Shopping savvy
are going to love the new interface, the new NWBC client.
Read on to get an overview on whats new with SAP SRM 7.01
- Service Procurement InnovationsStrengthen service procurement processes between SAP SRM and SAP ERP by Central Contract for services including service hierarchies
- start rfx process for services with hierarchy structure from scratch
- Call off to a central contrat from ERP invoice
- New functionality to upload SRM Contracts with service hierarchies to the catalog.
- Central Contract Management - High transparency of contract lifecycle through embedded analytics
- Central contracts for complex services including hierarchies
- Strategic Sourcing-- Oddline bidding with adobe interactive forms
- RFx response 'in front of firewall'
- Response modification allowed at item level
- Response comparison weight sumulation two envelope bidding
- Self Service Procurement --more efficient and user oriented shopping process
- Easy requisitioning via new SC concept
- Catalog UI enhancements
- Possibility to maintain personal delivery address as an employee
- Supplier Management -- Better support for registration, qualification and creation of
- suppliers
- Simplified Implementation and Operation
- Portal independent Navigation Frame -- The SRM poirtal independent Navigation frameallows to run a SRM installation without a portal.
- Possibility to execute the enterprise services without installation of PI
- SRM Analytics - independent from BI
- SAP Procurement for Public Sector -- Performance enhancements to a very large complex procurement item handling
- Reduced number of screens and clicks for activities including approvals and changing documents.
Bidding Procedures -- In General
Single-Stage: One-Envelope Bidding Procedure
In the Single-Stage: One-Envelope bidding procedure, Bidders submit Bids in one envelope
containing both the Price Proposal and the Technical Proposal.
The envelopes are opened in public at the date and time advised in the Bidding Document.
The Bids are evaluated, and following approval by the purchasing organization, the Contract
is awarded to the Bidder whose Bid has been determined to be the lowest evaluated
substantially responsive Bid.
Single-Stage: Two-Envelope Bidding Procedure
In the Single-Stage: Two-Envelope bidding procedure, Bidders submit two sealed envelopes
simultaneously, one containing the Technical Proposal and the other the Price Proposal,
enclosed together in an outer single envelope.
Initially, only the Technical Proposals are opened at the date and time advised in the Bidding Document. The Price Proposals remain sealed and are held in custody by the
Purchaser. The Technical Proposals are evaluated by the Purchaser. No amendments or changes
to the Technical Proposals are permitted.
The objective of the exercise is to allow the Purchaser to evaluate the Technical Proposals
without reference to price. Bids of Bidders who do not conform to the specified requirements may be rejected as deficient Bids, with purchasing organization’s approval.
Following approval of the technical evaluation and at a date and time advised by the
Purchaser, the Price Proposals are opened in public. The Price Proposals are evaluated, and
following approval of the price evaluation, the Contract is awarded to the Bidder whose
Bid has been determined to be the lowest evaluated substantially responsive Bid.
Two-Stage: Two-Envelope Bidding Procedure
In the Two-Stage: Two-Envelope bidding procedure, at the first stage, Bidders submit two
sealed envelopes simultaneously, one containing the Technical Proposal and the other the
Price Proposal, enclosed together in an outer single envelope.
Only the Technical Proposals are opened at the date and time advised in the Bidding
Document, and the Price Proposals remain sealed and are held in custody by the Purchaser.
The Technical Proposals are evaluated and if the Purchaser requires amendments or changes
to the Technical Proposals, such amendments and changes are discussed with the Bidders. The
Bidders are allowed to revise or adjust their Technical Proposals to meet the requirements of the Purchaser.
The objective of the exercise is to ensure that all Technical Proposals conform to the same
acceptable technical standard and meet the technical solution required by the Purchaser.
Bids of Bidders who are unable or unwilling to bring their Technical Proposals to conform
to the acceptable technical standard will be rejected as deficient Bids Following approval of the evaluation of Technical Proposals, Bidders are invited, at the second stage, to submit Modified Bid Proposals consisting of Revised Technical Proposals and Supplementary Price Proposals based on the technical standard agreed.
The original Price Proposals and the Modified Bid Proposals are opened at a date and time advised by the Purchaser. In setting the date the Purchaser will allow sufficient time for the Bidders to incorporate the changes in the Revised Technical Proposals that are needed to meet the agreed technical standard and to prepare the Supplementary Price Proposals that reflect these changes.
The Price Proposals, Supplementary Price Proposals, and Revised Technical Proposals are evaluated, and following approval, the Contract is awarded to the Bidder whose Bid is determined to be the lowest evaluated substantially responsive Bid.
Two-Stage Bidding Procedure
In the Two-Stage bidding procedure, Bidders first submit their Technical Proposals, in
accordance with the specifications, but without prices.The Technical Proposals are opened at the date and time advised in the Bidding Document.
The Technical Proposals are evaluated and discussed with the Bidders.Any deficiencies, extraneous provisions and unsatisfactory technical features are pointed out to the Bidders whose comments are carefully evaluated. The Bidders are allowed to revise or adjust their Technical Proposals to meet the requirements of the Purchaser.
The objective of the exercise is to ensure that all Technical Proposals conform to the same
acceptable technical standard and meet the technical solution required by the Purchaser.
Bids of Bidders who are unable or unwilling to bring their bids to conform to the
acceptable technical standard may be rejected as deficient bids.
After the evaluation of Technical Proposals has been approved by purchaser, the second
stage is to invite Bidders to submit Price Proposals and Revised Technical Proposals in
compliance with the acceptable technical standard. The Revised Technical Proposals and
Price Proposals are opened in public at a date and time advised by the Purchaser.
In setting the date the Purchaser should allow sufficient time for Bidders to incorporate
the changes involved in the Technical Proposals and prepare Price Proposals.
The Price Proposals and Revised Technical Proposals are evaluated, and following approval,
the Contract is awarded to the Bidder whose Bid has been determined to be the lowest
evaluated substantially responsive Bid.
Permissions or Roles in SAP SRM Bidding Process
As a follow on to my last post which was about the bidding process, here is some useful
information on the 'roles' or 'permissions' in the sap SRM bidding process.
Following are the permissions available in SRM bidding process
The Bid Floor Admin is the person responsible for initiating the opening process,
for Technical and Price rounds. By default, this is the purchaser. The bid floor
administrator can extend the duration of the simultaneous logon process. The Technical Opener is responsible for the simultaneously login and for the technical opening once the technical round is initiated. This user must approve the opening of technical RFx responses.
Technical Evaluators are responsible for evaluating the technical responses submitted by the vendor
The Price Opener is responsible to simultaneously login and performs the Price opening once the price round is initiated by the bid floor admin. This user must approve
the opening of price RFx responses
The purchaser can assign roles and permissions before and after publishing the RFx.
Please note that the permissions are valid only for the selected RFx .
CCM to MDM migration
With introduction of SAP SRM 7.0, CCM moves to sunset phase. So if you plan to upgrade from
an earlier version of SRM to SRM 7.0, you might consider upgrading from CCM to MDM. Here
are answers to few FAQ's on this subject.
Is CCM supported with SRM 7.0?
SAP CCM 2.0 is supported as a separate application as per the maintenance agreement currently in place until December of 2013. However, considering the longer term goal it is
advisable to move to MDM
What are the limitations of CCM?
1. SAP has stopped developing any new functionality in CCM (a sunset phase)
2. Primitive end user interface for both sides: maintenance and shopping
3. Primitive content validation functionality
4. Serious performance issues with big catalogs
When is the Support for CCM expiring?
CCM is supported till the end of 2013. So be prepared with your upgrade plans :-)
Is there any tool to migrate from CCM to SRM MDM Catalog?
No
Is there any migration guide to migrate from CCM to SRM MDM Catalogs?
Technically, moving to CCM to MDM is not upgradation.It can be considered as new
installation and migration of contents from CCM to MDM.
1. Install SRM-MDM Catalog
2. Adjust Repository if there are custom fields
3. Import contents from the existing catalogs
4. Define views in MDM
Is there any OSS Note to migrate data from CCM to SRM MDM Catalog?
Check the OSS note no – 1376770
How to analyze and fix errors in transfer of invoice to backend.
What happens when an invoice is not transferred to the backend correctly ?
How do you analyze and figure out the error in invoice transfer?
How to fix the error in transfer of an invoice?
What idoc type / message type / background jobs are involved in invoice processing ?
Read on for answers ......
An IDoc BBPIV is sent if an invoice is released in the EBP system. In the invoice the statuses I1022 "Release granted" and I1017 "In transfer" are set. In addition, for the background job (see below) an entry is written to table BBP_DOCUMENT_TAB.
Unless I1017 is not set again to inactive, all previous operations are not allowed (in
particular all changes to the invoice), that is, they are stopped by the program. The
sending of the IDOC is checked by the background job CLEAN_REQREQ_UP. The report reads the
BBP_DOCUMENT_TAB and makes a RFC (remote function call) per META_GOODSMVT_UPDATECHECK to check the posting of inbound IDocs. If the IDoc is posted successfully (status 53), the BBP invoice receives status I1018 "Transferred to backend".In addition, the entry is deleted in BBP_DOCUMENT_TAB.
If the IDoc is posted incorrectly (status 51, no follow-on document), the status of the
invoice is set to I1019 "Transfer failed".The entry in BBP_DOCUMENT_TAB remains as is, that
is, the status of the IDOCs in the backend system is still checked by the background job.
The sending of the IDOC is checked by the background job CLEAN_REQREQ_UP. If the IDoc has
not (yet) arrived in the backend system, the entry also remains as is.
Status I1018 allows to reverse the invoice in the future. In case of status I1019, a
deletion is (again) possible.
The following must be considered when processing an incorrect IDoc in the backend system:
a) Further process the same IDoc (using BD87), instead of copying and correct the IDoc with
Transaction WE19 since in the latter case, the background job cannot find the (copied) IDoc
and the invoice posted from that. In this case the BBP invoice would remain endlessly in
status "incorrect", the entry in BBP_DOCUMENT_TAB would never be deleted and the background
job would always make the RFC at every run.In addition the BBP invoice would never receive
the status "paid" (see below).
b) If the IDoc cannot be corrected or the error in the backend system cannot be solved, the IDoc remains in status "incorrect".In this case the BBP invoice should be deleted and the entry in BBP_DOCUMENT_TAB should be deleted manually or with a self-written report.
Additional information: As of EBP Release 4.0 or after the implementation of Note 601470 or
the import of the relevant Support Package, the entry in BBP_DOCUMENT_TAB is deleted by the
program (during the deletion of the invoice). Then the manual deletion is no longer required.
Status I1020 "paid" is set in the invoice by using the second background job
BBP_IV_UPDATE_PAYMENT_STATUS to check the payment status of the follow-on invoice in the FI backend system for all invoices from the selection area.This only occurs for BBP invoices
with status I1018 "Transfer to backend".
To read the FI documents, META_FI_DOCUMENT_READ_40B is used.
Migrate Vendor Structure from SRM 4.0 to SRM7.0
Below is a brief on the various steps to be followed while migrating vendor org. structure
from SRM 4.0 to SRM and some most common errors and its resolutions.
Once Upgrade is done we need to execute the following report
BBP_XPRA_ORGEH_TO_VENDOR_GROUP to get the vendor node to be created under PPOMV_BBP (Vendor Org Structure)
Detailed Procedure --
Execute the report from SE38 ” BBP_XPRA_ORGEH_TO_VENDOR_GROUP”
In the selection criteria for this report , click on the checkbox “Only Run Checks” and check whether it is gives any error or not. If there are no errors, then
uncheck the "Only Run Checks" option and execute the report.
Once executed a screen comes up saying that the node has been created .
Once this is executed then if you look in Vendor Org Structure in PPOMV_BBP you
will find the Node created successfully
Most common errors and their resolutions:
When you try to migrate the Vendor structure then you will encounter errors if
the structure is not proper as per SAP's recommendations.
If you encounter an error , "partner for root node does not have organizational
unit role", then Report BBP_ASSIGN_ROLE_TO_ORGUNIT_BP can be used to assign Org Unit role to the Org unit.
·
If the supplier has not been assigned the supplier role then an error "partner for supplier node has no supplier(bidder) role", then use report BBP_ASSIGN_ROLE_TO_ORGUNIT_BP to assign the supplier role. An option 'Assign Supplier Role' is available on the selection screen of report BBP_ASSIGN_ROLE_TO_ORGUNIT_BP. If this option is not available, then check note 1613293.
If you get an error saying that there is no BP number assigned then we need to execute report “BBP_ASSIGN_BP_TO_ORGUNIT” in order to assign BP number to that particular Org unit. Once this is done then we need to execute the report “BBP_XPRA_ORGEH_TO_VENDOR_GROUP” to get the Org Structure in PPOSV_BBP(Display Supplier Groups)
Whats new with SRM 7.02 in Operational Sourcing area.
Below is a brief on some of the new salient features introduced in the operational sourcing
area with SRM 7.02 i.e. SRM 7.0 Ehp2.
Quick Quote (RFx) can now be created from Shopping Cart -- this is possible at SC line item level. Benefit of quick quote is that stakeholders will know the approximate value of a shopping cart before approving.
Shopping Cart Modifications from Sourcing -- Requirements can be modified in sourcing application(e-sourcing) and changes from sourcing can trigger the relevant workflow process in SRM.
Direct Materials Procurement in Classic Deployment -- Earlier any direct material
procurement in SRM was in extended classic scenario.
Sourcing Graphical Search is now available to provide better visibility into requirements.
The account assignment category “unknown” is supported in external requirements transferred to SRM and local Shopping carts created in SRM. A purchase order created or replicated to ERP with the “Unknown” account assignment category would be transferred to ERP in the held mode.
Create an RFx from a shopping cart with the status 'Awaiting Approval' or 'Saved for quick quotes'
Purchaser can then create an RFx directly from the Item Overview tab of the shopping cart.
Purchasers can update the value of a shopping cart based on the RFx responses before the shopping cart is approved
How to add custom fields to Shopping Cart Item Data Screen
This sounds like one of the most common requirement by any customer -- Addition
of custom fields to Shopping Cart data. With SRM 7.0 , using meta data framework ,achieving this has became really easy. Here is a brief idea on how this can be done
Transaction Code SPRO--> IMG Path -->SAP Implementation Guide --> SAP Supplier Relationship Management --> SRM Server --> Cross Application Basic Settings--> Extensions and Field Control (Personalization) --> Configure Customer Fields --> Define Customer
Fields on Item Level --> In this append the custom fields in the both the structures .
The two structures are:
1. INCL structure with CSF
2. INCL structure with CSF_SC
Append for custom fields to shopping cart item ( to add on item basic data)
Append for custom cross document item data base field ( to save to the data base)
And you need to set the metadata for the custom field based on you requirement. For SC it
is /SAPSRM/V_MDF_IC.
Doing these steps would ensure that you have all the custom fields available for the SC in the database , and available for user on the SC screen. However, if the positions/layout/cosmetic changes are also required, then a webdynpro consultant needs to be pulled in. Its not a tough exercise to these layout changes. Simple changes can be achieved fairly easily an quickly. However, if you are looking at more customer specific action handling on these fields, be prepared to give the abap/webdynpro guy a decent slice in the project plan.
In's and Out's of Quota Arrangement in SAP SRM.
Quota Arrangement in SRM can be extremely useful for companies with huge volumes
of purchasing and multiple contracts with different vendors. It ensures that each vendor gets a fair amount of business from your company, and at the same time ensures that your company is able to maintain healthy relationships with multiple vendor. Thus a win-win situation.
You can use this function in both a manual sourcing process and an automated sourcing process to generate purchase orders. Quota arrangements allow you to define target percentages and distribute them between two or more purchasing contracts. A quota arrangement ensures that a contract is guaranteed both a minimum sales volume and a defined percentage of the total purchasing volume of a product category or product.
When defining a quota arrangement, two things are defined --
1. Guaranteed Minimum
2. Target Value
There are two phases in the validity period of a quota arrangement . These can be
best described as Fulfillment of guaranteed minimums: The quota arrangement first ensures that all guaranteed minimums of contracts participating in that quota arrangement are fulfilled. The sequence
in which the guaranteed minimums are fulfilled is determined by the target percentages defined in the quota arrangement.
Assignment of contracts based on target percentages: Once all of the guaranteed minimums of
contracts participating in a quota arrangement have been fulfilled, the system continues to automatically assign contracts based on the target percentages defined in that quota arrangement. The winning contract is then determined by the relative difference between the actual release value and the target value of the quota arrangement.
You can only create a quota arrangement if a product category or a product is saved in the system, and a contract is available so that you can assign target percentages for the quota arrangement. A quota arrangement uses standard rules to determine the winning contract in the sourcing process. However, the system can redetermine a winning contract with your own logic if you implement a Business Add-In (BAdI) from Customizing. To access this BAdI in Customizing for SAP Supplier Relationship Management, choose SRM Server Business Add-Ins (BAdIs) Sourcing Redetermination of the Contract to be Used (Quota Arrangement) .
A quota arrangement has the highest priority in the sourcing process.
In SRM no configuration is required for Quota arrangement. In SRM NW portal under strategic purchasing tab you will have Quota Arrangements option where you can activate the quota arrangement for a product category / product. You need to enter contract numbers,target percentage and Quota base quantity while creating quota arrangement.
Quota arrangement will not have any effect in sources of supply while creating a shopping cart. If you define contracts in quota arrangement and both are relevant for shopping cart, system will not choose one of them to be displayed. Both contracts will be suggested as source of supply. Quota arrangement has only effect in sourcing cockpit, notduring cart creation
· MM -SUS vs SRM-SUS
· SUS -- Supplier Self Service -- can be integrated with your ECC system or the SRM system. Based on the integration and business scenario, the SUS scenario can be identifiedas a MM-SUS scenario or a SRM-SUS scenario. It is important to understand the difference between these two . Here is a brief on the difference between SRM-SUS and MM-SUS
In MM-SUS, the PO will be created in ECC and sent to SUS. The supplier in SUS will send a PO response as confirmation. Supplier then sends an ASN(Advance Shipping Notification) on the basis of which an inbound delivery will be created in ECC . Using thisinbound delivery a GR(Goods Receipt) can be posted in ECC. Lastly supplier sends an invoice which is accepted or rejects in ECC system. MM SUS works in classic implementation with SRM.
In SRM-SUS, the PO will be created in SRM and sent to SUS. The supplier in SUS will send a
PO response confirmation. Standard SRM-SUS does not support ASN or invoice. This works in
extended classic implementation with SRM.
Please note -- You cannot send ASN or Invoice with SRM-SUS.
Analyzing the SRM SUS scenario, one might think that wouldn't it have been greatif we had the option of ASN / Invoice in the SRM-SUS scenario. This would have certainly strengthened the SRM standalone scenario. Anyways, this is not an option provided as a standard SAP solution. You may want to utilize the SAP Consulting services for a solution to this issue.
Park and Hold Purchasing Documents - SRM Classic Scenario
One of the most common business requirements in purchasing departments is that the users
need an option to save an incomplete purchasing document. SAP provides a function to achieve this requirement in the classic scenario. This function is known as ‘Park and Hold’. You can use this function to complete the data later, or ask another user to check the data.
There are two methods of saving data temporarily:
If your purchasing document contains incomplete or incorrect data, you can hold the document and complete processing later.
If your purchasing document is complete but you want to trigger a workflow to have the budgeting data checked, you can park the document.Thus, using this function purchase orders can be created with the status ‘park’ or ‘hold’in SAP ERP. You must activate the business function SRM_SERVICE_PROC_1 to use this function.
Following is some detailed info on the details of ‘hold’ and ‘park’ status –
Hold
· Completeness status: H
· If you have entered incomplete header data and at least one item for a purchase order, but want to complete the purchasing document at a later time, you can hold the document
· System writes all errors that occur to a message log
· The held document gets a document number and is displayed in the document overview, but no data or statistics in logistics, controlling (CO), or funds management are updated
· Held purchase orders are MRP relevant
· When you process held documents again, you can either hold them again, park them,or post them.
Park
· Completeness status: P
· If you want to have the budget data of a purchase order checked, you can park the document.
· You can only park a purchasing document if the closing check finds no errors other than incorrect budget data.
Parked documents are displayed with their document number in the document overview, and errors are written to a message log
When you process parked documents again, you can park them again but cannot hold them
Difference between ‘Held’ and ‘Parked’ documents
Unlike held documents, parked documents lead to updates in material management data and are used for evaluations in the system.
· Parked purchase orders are MRP relevant.
· How to troubleshoot workflow in SRM
· My SC is struck in workflow approval and I don't know how to check it.
My PO goes to the wrong approver and I don’t know where to see.
Workflow problem..errrr.. I don’t know how to check it.If this sounds familiar to you, read on to know a little bit about how to troubleshoot
workflow problems in SRM --
Workflow processes in SRM are grouped by the procurement document i.e. PO/SC etc.
BBP_PD transaction can be used to get a basic overview of the workflow steps involved
for a particular purchasing document. In BBP_PD, workflow items are provided under the
header -- “Workflow Item:”. Here you will get brief information related to the workflow.
You can find the workflow agents(approvers), users, state , created at , finished at and
some other relevant information.
If you want to see the details related to the workflow of any purchasing document, use
transaction SWI6.
In SWI6, use the object type (business object type) and object ID (purchasing document
number) to see the workflow details related to that document. Use Object Type Category as
BOR Object Type.
Once inside SWI6 you can see overview of all workflow steps for this document. In the
current data section , all the workflow steps can be seen , and these steps have hyperlinks. So if you click on any of them, it leads you to further information related to that step.
Inside SWI6, you can select the workflow and click on the ‘display workflow log’ at the
top in the menu bar.
After clicking the ‘display workflow log’ button, the new screen will have an even more
detailed information on the steps involved in that workflow. Here you can find some more
details related to workflow, you can see workflow agents and workflow objects for the
purchasing document.
In front of every step of the workflow, there are two buttons which can be used to see
the details and the graphical representation of the workflow steps. A third button is
available for steps which involve an agent.
If you want to see more details related to any workflow step, select any step and click
on the button “List with technical details’ at the top. Keyboard shortcut – Shft+F9.
Inside the technical details you can see the details of the workflow step, step history , deadlines, task description , container , message .
If you want to check the data that was passed to the workflow step, navigate to the container tab. Here you will find the container containing all the data involved in processing of this workflow step.
Hope this helps …. Play around inside SWI6 to understand more ..
These steps apply to troubleshooting of both application controlled and process
controlled workflows.
· Item based approval in application controlled workflow
· Item based approval often makes more sense to business as it provides them with
an option to select approver at line item level , based on criteria of individual items.
Incase this approach is used a separate approval of each item is required before it can be
converted to a PO. Also, in case of line item approval process being in place, items which
do not require any approval will have to wait till the approval process for other items in
the same SC has been completed.
Item level approvers can be determined using BADI BBP_WFL_APPROV_BADI. This BADI
is called every time when requester changes SC or approver takes action on it.
Following are the steps to write the logic in BADI for determining line item
approvers --
1) As per your logic, for each item first determine the approvers at each level & assign them approval index. Arrange them in ascending order of their approval index at item level.
2) It is possible that you have multiple approvers for multiple items in the same SC. For sending SC for approval, you will have to generate APPROVAL_OBJECT_GUID for each approver.
For this you have to find out criteria for generating APPROVAL GUID.
For example: If a SC has 3 items. Out of these items if for any 2 items product category is
similar then approvers will be similar for these 2 line items. Similarly for different
Product Category, different approvers are determined. So you can consider 'Product
Category' & 'Approval index' as a criteria to club approvers at each level.
3) Use function module ''BBP_WFL_DIN_APP_OBJ_GET' to generate approval GUID based on
criteria & to update BADI parameter 'ITEM_APPROVAL_OBJ'.
4) Update BADI parameters 'APPROVAL_TABLE' and 'ITEM_APPROVAL_TABLE'.
5) Once SC is approved by all, set 'NO_FURTHER_APPROVAL_NEEDED' flag.
Offline Bidding in SAP SRM
You can use an offline bidding form to allow your suppliers to respond to an RFx without
having to log on to the SAP SRM application. When a purchaser publishes an RFx, an SAP
Interactive Form by Adobe is sent as an e-mail attachment to all suppliers who are authorized for offline bidding. Bidders can be added in the RFx itself using the bidders tab. If the purchaser has used some question functionality in the Rfx, then these questions would automatically be added to the adobe form. This is a very useful feature in the offline bidding process.
The interactive adobe document which is sent as an attachment for offline bidding supports
· Data entry for fields such as quantity, price, and price unit
· Possibility to ask and respond to questions
If the suppliers bid offline, they complete and submit the form using e-mail. The steps involved in offline bidding from supplier’s end is
· Supplier receives the adobe interactive form as an attachment in the email for participation in Rfx.
· Supplier downloads the forms
· Supplier fills up the information in the form. – this process is offline.
· Supplier emails the form to the purchaser.
The purchaser's SAP SRM system
· Receives the e-mail,
· Reads the attachment
· Creates the RFx response from information in the adobe form sent by supplier.
The offline bidding form can be termed as a simplified alternative to the Rfx response.However it cannot be a general replacement for the online creation of RFx responses. If the RFx and the supplier are enabled for offline bidding, suppliers can choose to submit an RFx response online or use the offline bidding form.
The reason why offline bidding cannot be used as a general replacement to the online Rfx
response are listed below
· Buttons to indicate suppliers intent are not available in offline bidding.
· Export to Excel or Import from Excel is not available.
· The option of adding a new line item or subline is not available
· Supplier cannot access a Catalog
· Collaborative bidding via C-folders is not possible via offline bidding
· Option to validate entries for errors (Check button) is not available
· Attachments cannot be added to Rfx response.
· Entering complex prices (Price Conditions) is not possible
· Multiple invited contact person cannot work on the same RFx response
· Response modifications (add alternatives, substitutes, or supplements) is not available.
"No Logical system for FI is maintained" – How to fix this error
This error occurs when the accounting system has not been properly setup in the SRM system.
Make sure that the following entries/configs are maintained in SRM system :
· Attributes ACS and BUK in the organization model (PPOMA_BBP)
· Define G/L Account for Product Category and Account Assignment Category
· Define backend system for product category
· Entries in table BBP_BACKEND_DEST
· If you have performed a client copy of your systems, then the table
BBP_DET_LOGSYS may still contain the old product category GUID from the other system. Make
sure this has updated information.
You can follow the following path in SPRO to maintain tax codes in SRM --
SPRO->SRM ->SRM SERVER->Cross Application Basic setting->Tax calculation->Enter Tax code.
· In SPRO you may define the tax codes that are available for use in SAP SRM.
· You can define a tax code to be used as the default tax code. SRM system will propose this as the default tax code; however this can be overwritten in the SRM document.
· Different tax categories such as Sales Tax, Consumer Tax etc can be defined if you specify an external tax system.
· Tax code is picked from Material Master and vendor master data if you have picked
tax calculation in backend data.
· Use IMG path "Tax Calculation > Enter Tax Code" to enter tax codes. Also if EBP
tax codes are not exactly same as in backend system you need also to enter in "Tax Codes >
Assign Enterprise Buyer Tax Code to FI System" which code in EBP corresponds with code in
R/3.
The main tables for tax in SRM are as follows
· BBP_TAX --Tax Codes for Enterprise Buyer
· BBP_TAXT Enterprise Buyer -- Tax Code Description
· BBP_MAP_TAX_CODE -- (Assign Enterprise Buyer Tax Code to FI System)
· BBP_DET_TAX_CODE -- (Tax Code Determination)
Steps for setting tax determination in SAP SRM
1) Determine System for Tax Calculation: You need select Tax Calculation Occurs in Backend
2) Enter Tax Code: You need copy the tax codes from R/3 backend system (with the same name)
and choose tax category and the default tax code
3) Determine tax code for country/product category: This transaction is optional when you use R/3 tax calculation
4) Assign Enterprise Buyer Tax Code to FI System: You need map the EBP Tax Code with FI Tax
Code and put the FI System (the RFC connection with the backend, it is very important)
How to find current process level in workflow
Use the below code to get the current process level in process controlled workflow. This can be extremely helpful in cases when you want a functionality which depends on the process level of workflow.
Please note that SAP does not suggest usage of this class/method. However, they do not
provide with any alternative as well . :)
data:ls_process_level type /sapsrm/s_wf_process_level,
lo_curr_proc_level type ref to /sapsrm/cl_wf_process_level.
call method /sapsrm/cl_wf_apv_facade=>get_current_process_level
exporting iv_document_guid = iv_doc_guid
importing es_process_level = ls_process_level.
How to determine the last step in an N level approval process
If you want to determine if the current workflow process level is the last in an N-step
approval, then class /SAPSRM/CL_WF_PROCESS_LEVEL, method IS_LAST_LEVEL might not work. SAP
also does not provide any support over this.
However, we have an alternative solution here --
· Get the SC instance from the PDO buffer --
( /SAPSRM/CL_PDO_FACTORY_SC_ADV=>GET_BUFFERED_INSTANCE )
· If the instance is bound, get the source document instance
( /SAPSRM/CL_WF_PDO_IMPL_FACTORY=>GET_INSTANCE )
· Then, get the process info if the SC is instantiated
( /SAPSRM/IF_PDO_DO_APV_EXT~GET_PROCESS_INFO )
· With the exporting parameter ES_PROCESS_INFO, check if PROC_DETAIL_LIST has a
Forecast time indicator. If not, you current process level is the last one.
Long text formatting problem in SRM 7.
If you upgrade from SRM 7 from a lower version , you might face a problem in the formatting of long texts in custom smartforms .
If the long text in the document was originally entered as --
"this is header text.
1. line 1 of text.
2. line 2 of text "
When printed on smartform, it comes up as --
"this is header text.#1. line 1 of text.#2. line 2 of text "
Follow the steps below to fix this --
· Fetch the text for the document.
· Convert longtexts from c(132) to String and replace linefeeds (##) using code
below.
CALL FUNCTION 'BBP_OUTPUT_LONGTEXT_MAP_SMART'
EXPORTING
it_longtext = longtext table
IMPORTING
et_longtext = longtext table import.
· Define a logic for splitting the text lines as per your requirements.for ex,
header text, item vendor text etc. For each different logical split concatenate all text into one single string.
For ex --
LOOP AT gt_ltxt INTO ls_lngtxt WHERE tdid EQ 'HTXT'.
CONCATENATE lv_lngtxt ls_lngtxt-tdline INTO lv_string.
ENDLOOP.
· The string (lv_string) can now be formatted into separate lines, as originally formatted by the user . Use code below for this.
REPLACE ALL OCCURRENCES OF cl_abap_char_utilities=>horizontal_tab IN lv_string WITH '
\t' .
REPLACE ALL OCCURRENCES OF '\t' IN lv_string WITH '' .
SPLIT lv_lngtxt AT cl_abap_char_utilities=>newline INTO TABLE lt_tab.
· The table lt_tab will now have text as per the original formatting of the user.
· Loop at the table lt_tab, and print the text.
Automatic Approval does not work in SRM 7.0 - Process Controlled Workflow
In SAP SRM 7.0, if you are using the process controlled workflow you may create any process
schema as per your business requirement.
But if you use automatic approval in process controlled workflow, the event linkage flag for the object /SAPSRM/CL_WF_PDO becomes automatically unchecked because of the process
schema. Hence the automatic approval does not work.
To fix this problem, follow the steps below --
Start transaction SWE2
Activate the event linkage for the following row
Object category: ABAP Class
Object Type : /SAPSRM/CL_WF_PDO
Event :READY_FOR_RELEASE
Receiver Type: SRM_PROCESS_START
Offline Approval using BlackBerry - SAP SRM 7
There are two options available in which offline approval process can be handled by a blackberry device.
Option 1 -- No additional installation is required on your blackberry.
- The SRM system sends the approval e-mails to BlackBerry users.
- Approvals or rejections are text-based, and can be made by entering 'Yes' or 'No' on your
BlackBerry .
Option 2 -- requires installation of a Java application on your blackberry client
- The SRM server sends the approval e-mails to BlackBerry users.
- Approval or rejection is made via the Java application on the BlackBerry interface.
- Because of the JAVA app, you can easily distinguish between normal e-mails and approval e-mails
Following are the prerequisites before setting up the offline approval process.
- It is important that necessary setting have been maintained in
/SAPSRM/OFFLINEAPPROVALSEND
- In the Customizing activity Change Organizational Plan (transaction PPOMA_BBP), you have
set the attribute FORWARD_WI to 'X' for all users that are to use the offline approval function.
- E-mail address of the system user WF-BATCH is maintained
- E-mail addresses of all users has been maintained that are to use the offline approval function
Important Setting for Extended Classic Scenario - SAP SRM
-- At least one backend MM system and accounting system should be connected to the SAP SRM
system .
-- The settings for the MM and Accounting systems should have been defined in the configuration setting"Define Backend Systems." in SPRO
-- Product categories from the backend system should have been replicated in the SRM
system.
-- The target system for each product category is the backend system in the configuration setting "Define Backend Systems for Product Category" in SPRO.
-- An alternate to point above is implementation of BADI BBP_DETERMINE_LOGSYS to find the
correct backend system.
-- The extended classic scenario is activated in the configuration setting "Activate Extended Classic Scenario"in SPRO.
-- An alternate to above point is implementation of BADI BBP_EXTLOCALPO_BADI to control the
extended classic scenario based on business specific 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 4.6B or higher, you need to map the purchasing group in
SRM to the backend purchase group
-- Use BAdI BBP_PGRP_FIND to determine a backend purchasing group in the shopping cart.
---- If a local pur. group and pur. Org. are used, then a valid backend pur. 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.
Plan Driven Procurement in SAP SRM - Configurations for PDP
Plan Driven Procurement Scenarios :
Plan Driven Procurement with Plant Maintenance
-- This scenario processes requirements that have been generated in systems other than SAP
SRM.
-- This works in Extended Classic Scenario.
Plan Driven Procurement with Supplier Integration
-- This scenario is used to process procurement of Direct Materials from ERP system where
Supplier can collaborate with the purchasing company using SUS. In this case MM-SUS is
implemented
-- Requisitions from procurement system are not pushed to SRM system in this case.
-- Procurement process takes place within procurement system(MM) only.
Configurations
Configuration Required in SRM system --
-- Create a Shopping cart Transaction Type for SCs created by Plan Driven Procurement (if a
separate transaction type is required)
-- Complete the configurations required to activate Extended Classic Scenario in SRM
system. BADI can also be used .
--Create an Entry Channel in the Org Structure for Plan Driven Procurement.This Entry
channel is created in the Organization Structure anywhere under the root org unit.
-- When a requisition is passed to SRM system , a SC is created for this requisition using
an RFC user. This RFC user should have the necessary attributes and roles to create a SC in
SRM system. Appropriate setting should be done on org. structure and SU01.
-- Define Purchasing Group for the product responsibility and organizational responsibility for document processing in SRM
Configurations in ERP System --
-- Create an RFC Connection to the SRM system.
-- Create a profile for the SRM System in table V_T160PR. If multiple SRM systems are
connected, then a separate profile is created for each system.
-- For the Purchase Requisitions to get transferred to SRM System, assign the combination
of Material Group and Purchasing Group to this profile in the table V_T160EX.
-- Use BADI BBP_BADI_EXTREQ_OUT to control transfer of requisitions.
Whats new with SAP SPM 3.0 ( Spend Performance Management 3.0)
In SPM 3.0, SAP has introduced a home screen concept with quick and easy access to all the
features.
A. Create New Content
-- Improved 1 click access to new reports, dashboards, briefing books and alerts
B. Advanced Analysis
-- New features of SPM 3.0 are What if Analysis, Waterfall Analysis, Savings Analysis,
Business Synergy.
-- Advance analysis features from SPM 2.1 are now in a more prominent position. Spend
Advisor, Supplier Risk Analysis
C. Recent documents
-- Displays quick links via report icons to last 3 reports used.
-- Browse all – quick access to the Content folders
D. Favorites
-- End User configurable ; direct links to users favourite reports, dashboards and breifing
books
E. To Do List
-- Displays Alert Notifications
F. Quick Links
-- Configurable links to external sites or intranet content
What if Analysis
What if Analysis is a new feature in SPM 3.0. It is a framework that empowers the end user
to model different scenarios for a sourcing activity.
There are 2 parts to what if analysis
I. Model – a template that is used to build scenarios
II. Scenario – different scenarios can be created from the same model to show different
outcomes.
What if reports uses
1. Global variables -apply to whole report
2. Local variables - apply to the individual lines
3. Formulas – can use report data and global and local variables for calculations
SAP Sourcing Supplier Management - Brief Intro
SAP Sourcing Supplier Management enables the following capabilities:
Centralized supplier database: Create a central repository of all your Supplier records with all the associated documentation including scorecards, financial statements,risk assessments, and insurance certificates can help support periodic supplier reviews to audit compliance.
· Integrated Supplier Portal: Each Supplier has a personalized portal that allows him to view all relevant information to manage their relationship with you. Suppliers respond to bid requests and auctions, view scorecard performance, maintain their own contact and category records, and view active contracts. This holistic and easy-to-use interface greatly reduces the time it takes for Suppliers to become proficient working over the Internet and decreases their cost of doing business with you.
· Supplier Scorecard Sharing: The ability to easily track and analyze supplier performance can reduce risk and costs. SAP Sourcing’s flexibility allows you to establish metrics and evaluation criteria based on category and region. For reporting purposes, you can generate a scorecard over periods of time, such as each quarter, to monitor a supplier’s progress over the course of a year. Automatic assignment of traffic light indicators quickly highlights areas requiring attention from Supplier managers. The ability to share Supplier scorecards through the Supplier portal enables full collaboration and sharing of information to ensure optimal performance.
· Supplier Self-Registration: Suppliers can self-register in SAP Sourcing, or you can invite them to become users. The registration form can be configured to collect the most relevant information to accelerate the supplier qualification process. When new Suppliers are accepted, their registration form responses are used to generate the initial Supplier record.
· Supplier Profile Maintenance: As the supplier information changes, Suppliers can
update their product and contact information through the Supplier portal, saving the Sourcing organization from the administrative burden of researching and updating supplier
information.
· Supplier Relationship Activities: A successful Supplier relationship is built and sustained over time through a series of ongoing, recurring activities. These include routine tasks such as safety, insurance, and diversity certifications, as well as strategic joint meetings and planning activities. SAP Sourcing delivers an automated tracking and alert system that enables you to manage Supplier-specific activities with less effort. The system automatically sends alerts to Suppliers when tasks are due. In response Suppliers can modify profile and contact information and send updated certificates online through the SAP Sourcing Supplier Portal and the new, reviewed information is updated directly to the Supplier record.
· Supplier Diversity Promotion: SAP Sourcing offers a unified system to help increase the number of qualified diverse suppliers, achieve desired participation and award rates, and track compliance without additional resources. For example, diversity qualifications seamlessly flow from the self-registration form, to the Supplier record, to RFx responses for “extra credit” on scoring. Buyers inviting suppliers to events now have easy access to a single, searchable supplier database that includes category, location, and diversity information, lowering the threshold for compliance.
· Need of storage locations in SAP SRM
· In Storage Location Section of Extended Attributes we can maintain Storage
Locations which are synonymous with Storage locations in R/3. The values maintained here
will be available for the user to select as storage location while creating shopping carts.
· Storage locations are required in SRM in case of direct procurement scenario.
· If you order the material as direct procurement while creating the shopping cart, (direct procurement tab) the cost assignment filed will not be displayed and the valuation happens based on the Valuation class (material master). The material gets received and stored in the storage location. So mentioning a storage location is mandatory in this case which is not the case if you order it as indirect material.
· How to : cross company purchasing - purchasing group from one company buys for
another company
· In this article I am referring to a scenario where you want buyer of purchasing
group of one company to do the purchasing for another purchasing group belonging to another
company.
Consider the org set up as --
-- 2 separate companies A and B exist under the root node
-- Company A has Purchasing Org A .
-- Purchasing Org A has Purchasing Group A
-- Purchasing Group A has Buyer A responsible for product category X
-- Company B has Purchasing Org B .
Buyer A should do the purchasing for product category X for purchasing Org B.
This can be done using the responsibility tab of Purchasing Group A.
Assign the Org ID corresponding to Purchasing Org B under the responsibility tab of purchasing group A.
Now Buyer A would be able to do purchasing for purchasing org A and B which belong to
different companies.
SRM Content for PI 7.11
If your landscape has ECC 6, SRM and PI 7.11 system , following components are required for
ERP -- XI -- SRM system integration.
· XI CONTENT SRM
· XI CONTENT SRM_EXT_FUNC
· XI CONTENT SRM_EXT_FUNC IC
· XI CONTENT SRM SERVER IC
· XI CONTENT SRM SERVER
Above scenarios are must if you want to implement --
· Contract Management scenario
· Centralized Sourcing
· Plan Driven Procurement with Supplier Integration
If you are planning to use SRM-MDM catalog then 'XI CONTENT SRM-MDM CATALOG' is also
required.
PO replication from ERP - SUS (MM - SUS)
Follow the steps below in ERP for PO replication to SUS --
Maintain Event Type Linkages for Purchase Order Output in PurchaseOrderERPRequest_Out_V1
SOA Service (Supplier Self-Services Scenario)
1. Run transaction Display/Maint. Event Type Linkages (SWETYPV).
2.Choose New Entries.
3.In the Object Types field, enter CL_SE_PUR_WF_OUT.
4.In the Event field, enter CREATED.
5.In the Receiver Type field, enter WS53800008.
6.In the Receiver Function Module field, enter SWW_W1_CREATE_VIA_EVENT_IBF.
7.Select the Linkage Activated checkbox.
8.Save your entries.
9.Choose New Entries.
10.In the Object Types field, enter CL_SE_PUR_WF_OUT.
11.In the Event field, enter CHANGED.
12.In the Receiver Type field, enter WS53800008.
13.In the Receiver Function Module field, enter SWW_W1_CREATE_VIA_EVENT_IBF.
14.In the Check Function Module Field, enter OPS_SE_PUR_CHANGED_EVENT CHECK.
15.Select the Linkage Activated checkbox.
16.Save your entries.
You can use the BAdI PUR_SE_PO_INTERFACE_OUT_SELECT to control which outbound services are to be sent in relation to the purchase order.
SRM Error - Supplier X not intended for pur. org. Y
This error can be encountered in the a scenario where SRM central contract is not used for
local sourcing and the supplier is has not been assigned to Purchasing Org. of the user.
There are 2 ways to fix this error --
1. The most obvious thing is to assign the purchaser to the pur. org. of the user.
2. However, if there is a business requirement as per which the supplier should not be
assigned to the purchasing organisation, then follow the manual steps below to make this
error message customizable.
1.Go to the transaction SM30
2.Go to the View BBPV_PDMSG
3.Click on new entries to add a new entry in to the view
4.Add BBP_PD for the Applic Area column
5.Add 018 for the Msg field Column
6.Add BUS2000113 for the Object Type Column
7.Add EWI for the Allowed column
8.Add 'E' for the Standard Column
-- Save changes made by the activity mentioned above.
1.Go to Transaction SM30
2.Go to the View BBPV_PDMSG_CUS
3.Provide the Object type as BUS2000113
4.Add BBP_PD as the Message Cl (Message Class)
5.Add no as 018
6.Add Type as 'W'
7.Add E as standard
Save the Changes to the View.
Refer SAP Note 1531626 for more details.
Company Code & Plant mapping not updated in SRM
If you make any change to the company code & plant mapping in the ERP system and replicate these changes to SRM by running a program BBP_GET_location_selected or BBP_GET_location_all
, the mapping in SRM is not updated.
One way to fix this problem is --
You can change the company code assignment for the plant from the web portal if you have administrative role.
Follow the path:
Administration > Location tab > Here select the Plant(i.e. Location) to Edit mode >
Then select your logical system > Under location mapping, change the company code and save it.
Now you can see the updated result under the extended attribute section in PPOMA_BBP.
Alternatively, you can see the results in table BBP_LOCMAP in SRM system.
How to restrict the type of documents that can be created from Sourcing Cockpit
In SRM , the purchaser has by default an option to create a Rfx / Contract or a PO from the sourcing cokcpit (Assign Source of Supply). This option is available from the dropdown on the button in the tool bar which provides a list of follow-on documents that can be created. Many business require these option to be restricted i.e. for ex. a purchaser should be presented with an option to create a PO only, which means the purchaser should not be presented with the option to create Rfx or contract .
This requirement, which looks like a webdynpro enhancement , actually requires a 2 step procedure.
1. Go to SM30 and enter /sapsrm/v_soco
2. Uncheck the document types that are not necessary
3. Save
Documents in Strategic Sourcing - RFI / RFP/ RFQ / Auctions
In this blog I have tried to provide some basic understanding on the commonly used documents in strategic sourcing process. These documents are RFI , RFP , RFQ and Auctions.
Read on to learn a bit about these --
An RFx is a sourcing document that enables you to request information, quotes, and prices
regarding goods and services from multiple suppliers.
RFP - Use this document type to solicit bids on goods and services. It can include complex
questions and criteria and can facilitate your decision-making on sourcing choices.
RFI - Use this document type to elicit information from vendors about their organizations,
goods, and services.
RFQ - Use this document type to solicit price quotes on specific goods and services when
pricing and costs are the primary concern.
Auctions - An auction is a strategic sourcing event that is used to negotiate the best value in a short period of time. In an auction, suppliers bid to provide products and services. An auction can occur on its own or in conjunction with an RFx. Unlike an RFx,which can go on for weeks, auctions typically last for a few hours to a few days. Although auctions can be either reverse or forward, you typically use reverse auctions for your sourcing events. In a reverse auction, the price drops as the auction proceeds, whereas in a forward auction, the price increases as the auction proceeds.
How to replicate HR Org Structure from ECC - SRM
Option 1:
· You can schedule the report RHALEINI in SRM by maintaining variants as per the requirement. The variants should be created for object type 1000 and 1001 and for different
relationship types. You can schedule this report as required. The suggested way is to schedule this report once daily , after the close of business hours, as it tries to send the whole org structure by creating IDOCs.
Before scheduling this report, you need to do the config for the following things in SRM.
· Maintain and distribute the distribution model -- In transaction BD64, maintain and distribute model view for the message type HRMD_ABA (org structure related changes).
· Maintenance of Idoc and message type -- In WE20, create a partner for ECC/ERP
system under "Partner Type LS". Maintain message type "HRMD_ABA" under outbound parameters.
Go to details and check the radio button "Transfer IDOC immediately" under "Output Mode".
This will help to transfer the IDOCs immediately from SRM to ECC/ERP as soon as they are created in SRM.
Option 2:
Option 1 might create performance issue if the org structure is a complex one having manynodes. In order to overcome this issue, you can distribute the org structure via change pointers. This will replicate only the changes made to the org structure. You need to follow the below config steps in SRM.
· Activate Change pointers -- You can use transaction BD61 or navigate through SPRO
--> IMG --> Supplier Relationship Management --> SRM Server --> Technical Basic Settings
--> ALE Settings (Logical System) --> Distribution (ALE) --> Modelling and Implementing
Business Processes --> Master Data Distribution --> Replication of Modified Data --> Activate Change Pointers - Generally. Tick the option "Change Pointer Activated -generally".
· Activate Change pointers for HRMD_ABA -- Navigate through SPRO --> IMG -->
Supplier Relationship Management --> SRM Server --> Technical Basic Settings --> ALE
Settings (Logical System) --> Distribution (ALE) --> Modelling and Implementing Business
Processes --> Master Data Distribution --> Replication of Modified Data --> Activate Change
Pointers for Message Types. Activate for message type HRMD_ABA by ticking the check box.
· Maintain and distribute the distribution model --In BD64, create a distribution model for message type of HRMD_ABA and maintain filters for different info types (object type 1000, 1001 , relationship types like A003, A008 etc). Then distribute the model view to ECC.
· Maintenance of Idoc and message type -- In WE20, create a partner for ECC/ERP
system under "Partner Type LS". Maintain message type "HRMD_ABA" under outbound parameters.
Go to details and check the radio button "Transfer IDOC immediately" under "Output Mode".
This will help to transfer the IDOCs immediately from SRM to ECC/ERP as soon as they are
created in SRM.
· Schedule the report RBDMIODC in SRM to create the IDOCs from change pointers.
This report can be scheduled as required . Suggested practice is to schedule it once or twice daily.
· Schedule the report RBDAPP01 in ECC to post the incoming IDOCs from SRM.
Tables containing Attribute and HR relationships
Following are few tables that contain a lot of information related to attributes and HR
data and other relationships.
Basic table for attributes is T77OMATTR
Following are the tables that are updated with attributes.
HRP1222 (Infotype 1222: General attribute maintenance)
HRV1222B (View of Attributes)
HRV5502A (SRM Location)
HRP1000 (Objects details_link to Code)
HRP1001 (Relationships to other objects)
HRT1222 (Table Section Infotype 1222: General Attribute Maintenance)
HRV5500A (SRM: Selection Help for SRM Function)
HRV5500OT (SRM Function (OTJID))
HRV5501A (SRM: Selection Help for Product Responsibilities)
HRV5501OT (SRM Product Responsibility (OTJID))
HRV5502A (SRM Location)
HRV5502OT (SRM Location (OTJID))
BBP_ATTR_ACCESS (Attribute Access Mode)
BBP_ATTR_DFT (Default Values of Basic Attributes)
BBP_ATTR_VALUE_T (Text for SRM Attribute Values)
How to find data of a specific attribute in the SRM system
If you want to see specific attributes of a BP in SRM , follow the steps below --
· Look for the relation of the object in the table HRP1222. Here you can find the field TABNR and then select the table HRT1222 with key TABNR
· In the table HRT1222 you have a field named ATTRIB, here you can take the requested Attribute key eg. BUK, ADDR_BILLT. The values are stored in fields LOW and HIGH
(possible interval values, if no intervals, the LOW field is used).
Important Tables that store attributes and other HR information can be found here.
You may use the function modules BAPI_USER_GET_DETAIL , BBP_OM_FIND_SC,
RHGA_READ_TREE_UP_SET etc.
This blog is gives great information on SAP PI XI online training in hyderabad,uk,usa,canada.
ReplyDeleteOnline SAP PI XI Training in USA
SAP PI XI Online Training uk
nice blog, I like your good post, thanks for sharing great information.
ReplyDeleteSAP SRM Training institute in Noida
Great Post!!! I have read your blog and it's very informative & really impressed .
ReplyDeleteThanks for sharing it. Keep continue your post.
SAP FIORI TRAINING ONLINE
SAP FICO TRAINING ONLINE
This comment has been removed by the author.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteThank you for giving this best information. It’s a very nice topic
ReplyDeleteSap Online Access
Cool Post.
ReplyDeleteSAP Training in Chennai
SAP ABAP Training in Chennai
SAP FICO Training in Chennai
SAP MM Training in Chennai
SAP SD Training in Chennai
This comment has been removed by the author.
ReplyDeleteSAP SRM Training in GURGAON
ReplyDeleteSAP SRM Training Institute in Delhi
ReplyDelete