GR based IV check box suppressed - Extended Classic Scenario

Hello Folks,
How are you doing today ?
We are working in SRM 5.0 Extended Classic scenario.
When created the Local PO in SRM with GR Based IV Check box active, the
follow-on back-end Purchase order is generated without this flag. In
other terms, system is creating the follow-on ECC PO without GR Based
IV check box active. As a result, we are unable to run the ERS cycle.
Back-end system in above scenario is ECC 6.0. And vendor settings are
maintained with GR based IV flag on in both ECC and SRM.
Kindly advice.
Thank you for your assistance !

Hi Ravi and Yann,
Thank you for your inputs. OSS note-956083 can not be applied in my case due to the hight system version (patch level 550).
I have already raised this issue to SAP, but in the lack of proper infrastrucure SAP can not access the system. (BASIS guys are still struggling with it)
Well...let me give you recap-
We have not activated nor implemented any BAdi so far (Vanila SRM 5.0 EC scenario) PO creation for goods is working fine and as desired. But when it come across with PO with limit item or services, system throws an error as -
"PO 5100000263: Service-based invoice verif. requires GR "NO" or G R-based invoice verif."
Would deeply appreciate if you guys can share insight on this issue.
Thank you for your assistance!

Similar Messages

SRM: Extended Classic scenario: Request your help.

Hi Guru's,
We are implementing the EXTENDED CLASSIC SCENARIO in our project. kindly request your help.
in our project the SRM box is : G3OSBSR102.
R/3 backend Box is : RCHSBR3142.
Now when i create a shopping cart it should create the Purchase order In SRM( G3OSBSR102) and also copy the created purcahse order in teh backend system : RCHSBR3142.
The issue here is which Logical system should be populated in the field at item level when creating the shopping cart :BE_LOG_SYSTEM.
1) In this field: BE_LOG_SYSTEM.
If i populate the SRM local: G3OSBSR102., then it will consider the Business object type as : BUS2201and creates the local Po but while transfering this local created document(PO) to R/3 system is loosing the Logical system at the item level of the PO.
If i populate this field at the item level via DEBUGG mode then system is sucessfull in transferring the document to R/3.
2) In this field: BE_LOG_SYSTEM.
If i populate the SRM local: RCHSBR3142, then it will consider the Business object type as : BUS2012 and creates the purchase order in R/3 system and will not create teh local purchase order.
Kindly request your help for any further settings if i did miss.Appreciate your help in this regards.
Many Thanks,
Prasad NN.

Dear Prasad,
To work on Extended Classic Scenario, you just have to maintain the following configuration in SPRO:
>SAP Supplier Relationship Management
>SRM Server
>Cross-Application Basic Settings
>Activate Extended Classic Scenario
Check the flag "Extended Classic Scenario Active".
You dont have to manipulate "BE_LOG_SYSTEM" field to choose your scenario.
Regards
Thiago Salvador

Need to change the LOV field based on checked box selection in OAF page

Dear ALL,
I have a requirement as below:
I have a custom OAF page having a lov field which is mandatory, a check box and a two text fields.
So based on LOV value selection i am defaulting two text field value automatically.
So my requirement is when user selects the check box automatically the LOV field should be non mandatory and user can insert in values to the lov field and text field and submit it.
SO basically based on check box field selection i need to make the lov field in such a way it should accept all the values what user enters instead of check the query added in VO behind the LOV.
Please suggest me some pointers to achieve this requirement.
Thanks
Deb

hi,
in PFR use:
if ("checkevent".equals(pageContext.getParameter(EVENT_PARAM)))
                 HashMap hashMap = new HashMap();
                 String checkboxval=pageContext.getParameter("item2");
              hashMap.put("checkboxval",checkboxval);
                pageContext.setForwardURLToCurrentPage(hashMap ,
                true, // retain the AM
                OAWebBeanConstants.ADD_BREAD_CRUMB_NO,
                OAWebBeanConstants.IGNORE_MESSAGES);
and in PR use:
if((pageContext.getParameter("checkboxval'))!=null)
OAMessageLovInputBean lovInputBean=(OAMessageLovInputBean)webBean.findIndexedChildRecursive("item3");
      lovInputBean.setRequired("false");
try it
Regards
Mahesh

GR Based IV check box

Hi. I need help in controlling the GR Based IV check box in creating the PO.
We normally set this in the vendor master. But then, How can I set the GR BASED IV checkbox base on the PO document type that will be used?
Let say I want all sap standard types of PO to be GR Based and some Z type PO to be not a GR based IV PO. Is this possible?
Is there a User-Exit for this?

HI,
Since you want to set the GR based IV to set for all Standard Purchase order- at doc type level.
So the first thing is the vendor master setting which you are already doing.
Second you can also do it by the info record .by creating info record for all vendor and material /Material Group ..we can control the GR IV indicator
Third thing is Controlling it by the screen layout.
SPRO-Material Mangement-Purchasing- Purchase order-Define doc types
here in the definition of Doc type ,attach a screen layout.
SPRO-Material Mangement-Purchasing- Purchase order- Define screen Layout at doc type level.
in this Screen layout in the tab --GRIR control. make the GR based invoice as mandatory,so that it cant be skipped while created or change of PO and user will check it even if it is missed out.
hope so it helps
Regards
Anjanna

Default settings for gr based ir check box for asset PO

dear experts,
in vendor master record in purchasing data tab i have checked gr based iv check box, and hence whenever i am creating a Po with X vendor for material system is automatically checking the check box in po for gr based iv but with the same vendor X if i am creating a PO for Asset itis not checking the gr based iv check box by default.
can you pls tell me where the default setting for gr based iv lies for the asset procurement.
thanks
ujwal

HI Ujjwala,
The setting in spro in Acct assigment, u are talking about is GR Receipt or Invoice Receipts.
These are not GR Based Invoice Verification.
GR based Invoice Verification comes from either ur inforecords or vender master.
if u check or uncheck these in spro in acct assigment, then it will comes ur Deliver Tab not ur invoice Verification Tab.
one thing more, if u make it mutiple Acct assigment, then it will be Non Valuated G/R Based IV.
Hope Clear U !
REgards,
Pardeep Malik

Extended classic scenario triggered on company code

Good morning,
I have a system with SRM 5.0. I would like to have both classic and extended classic scenario, I know that it is possible to activate extended classic only for a product category with BADI BBP_EXTLOCALPO_BADI , but my question is: Is it possible to activate it for a company code? If yes, is it with the same BADI ?
Thanks in advance
Charlotte

Hi
Before talking about de-activating ECS or not in this BADI, this scenario must first be activated.
This is done via the customizing point "Activate ECS": just flag the check-box, and all you classic items (i.e. those for which a backend has been determined) become extended classic.
Here is the SRM - IMG path:
SRM Server --> Cross-Application Basic Settings --> Activate Extended Classic Scenario.
You can then fine-tune the scenario by using the BADI BBP_EXTLOCALPO_BADI.
Note- The BADI BBP_EXTLOCAL_PO_BADI can be used to activate the classic scenario based on the proguct categories .
You can choose to have the 3 scenarios working on the same SRM system depending on product category (standard) or any other business rule through the BADI BBP_EXTLOCALPO_BADI. The BADI is mandatory if you want the Classic and the Extended Classic to work together
Exactly, this BADI allow you to implement your own business rule for backend determination in a multiple Backends environment (Standard customizing is only based on Product categories)
As soon as you use BADI BBP_EXTLOCALPO_BADI , you don't have to use the ECS scenario activation customizing point (the rule is overwritten with the BADI result). The BADI BBP_DETERMINE_LOGSYS will only help in your case, if you have several Backend where to create PO documents.
PS: be aware that in ECS scenario you will no longer be able to create PR or reservations in R/3.
Other related links ->
Classic Scenanio and Extended Classic Scenario
Extended Classic vs Standalone
Re: Calssic or Extended Classic Scenario - BBP_EXTLOCALPO_BADI
Classic / Extended Classic Scenario for Shopping Cart
Re: Classic Scenanio and Extended Classic Scenario
Re: Switching from Classic to Extended Classic
Re: Calssic or Extended Classic Scenario - BBP_EXTLOCALPO_BADI
Change from ECS to Classic Scenario
Re: Changing the Global Control of Extended Classic Scenario
Re: Technical Scenario Switch: From Standalone To Extended Classic
Do let me know.
Regards
- Atul

Extended Classic Scenario PPOMA_Purchasing Org and Group

Hi gurus,
We are working with SRM 5.5 and we are having problems with the assignments for the Purchasing organization and Purchasing groups in the PPOMA.
In the documentation it says we should have one box for the R3 Purchasing Organization (flagged and referred to the backend POrg) and one for the Local Purchasing Organization (flagged but NOT referred to the backend POrg). The same for the Purchasing Groups, the one under R3 POrg will be flagged and referred to the PGroup in R3 and the one under the Local POrg will have the flag but it will not be referred to the backend PGroup.
Afterwards, in the attributes for the Local POrg and Local PGroup, with the attributes PURCH_ORGX and PURCH_GRPX the local and the R3 POrg and PGroup will be assigned each other.
The purchasers will be located in the Local PGroup. The R3 POrg and PGroup will never have users assigned.
The problem is that all the workflow is only working if the "Local" POrg and Group have the backend purchasing organization and purch group assigned in the Function Tab. This means that the 2 boxes for R3 are no longer necessary. In the documentation it says that this version of SRM needs both boxes for the POrgs and the 2 boxes for the PGroups. We have flagged the Extended Classic Scenario.
Any help on this? It's because of the version?
Many thanks and regards,
I will give Points!

Hi Ana
PURCH_GRP     Purchasing group     Number of an organizational unit that is indicated as local purchasing group in the organizational plan.
This attribute is simulated. You define an organizational unit as company on the Function tab.
PURCH_GRPX     R/3 purchasing group     Number of an organizational unit that is indicated as the R/3 purchasing group in the organizational plan. The value contains the ID and the associated backend system of a backend purchasing group.
This attribute is simulated. You define the ID and the associated system on the Function tab.
PURCH_ORG      Purchasing organization     Number of an organizational unit that is indicated as local purchasing organization in the organizational plan.
This attribute is simulated. You define an organizational unit as purchasing organization on the Function tab.
PURCH_ORGX     R/3 purchasing organization     Number of an organizational unit that is indicated as the R/3 purchasing organization in the organizational plan.
This attribute is simulated. You define the ID and the associated system on the Function tab.
can you elaborate more?
in ECS also we can map the backend purchase organisation/ purchase group for purchasing activity.
there might be a resposibilty tab for the backend purchase group might be mapped the responsible purchaser list (dept).plz check it up
regards
Muthu
regards
Muthu

Difference between Classic Scenario and Extended Classic Scenario

Hi Expers,
I need your help again........:-)
I just want to know what is the differne between classic and Extended Classic Scenario.
Points will be rewarded
Thank you
sam

Hi Sam,
(explaination frm a previous thread)
Difference between scenarios
WIth classic scenario, the SC following document is to be created in your R/3 backend(s). Thus you can get an PO, a PR or a stock reservation in R/3.
With extended classic the following document is to be found in SRM itself. Thus from a SC item you can get a complete PO, an incomplete PO or depending on your customizing a Sourcing cockpit (now called Sourcing Application) requirement. Additional FM are called when you tick the box "Enable Extended classic" in the IMG activity, enabling you to get a local PD.
If you need to get a stock reservation in R/3 with extended classic, you will have to switch back to classic scenario for the particular category or product with a dedicated BADI ("Control extended classic ").
Be aware that with extended classic, the PO created in R/3 is not exactly a replication. That is a "copy" with that crucial difference that the SRM PO will use a different Purchase Organization that of R/3. It enables you to centralize your purchasing. In SRM you can create a "local" Purch. Org for EMEA zone for instance while in R/3 that is rare you can purchasing above a country (because in the backend you have to produce legal documents related to one company). Those "local" (=SRM) Purch. Org. are required to enable extended classic and it makes simpler Contract management for instance (in classic scenario contracts may need to be replicated to your R/3 back end and adjusted for each back end and each Purch Org in R/3, and even for each plants).
In a nutshell with extended classic you have a PO in SRM, and this PO is assigned to a different Purch Org that of R/3. Purch Org in R/3 are determined on the basis of the "LOcation" (R/3 plant you have replicated from your backent into SRM).
Extended classic is required for service purchasing when you want your requesters to be able to adjust the PO price while they can not access R3. In extended classic, PO is issued from SRM and not from R3.
Please check this too:
http://help.sap.com/saphelp_srm40/helpdata/en/e9/d0fc3729b5db48e10000009b38f842/content.htm
BR,
Disha.

Extended Classic Scenario not creating backend PO

Hi All
We are just starting with SRM (Using SRM 5.0 SRM Server 5.5) and trying to decide to use Classic or Extended Classic.
I can get the Classic working were an approved SC creates a backend PO without any problem. However when I switch on Extended Classic the backend PO is not created from an apporved SC.
In RZ20 my error is Shopping cart 1000000080 (PReq. ): BBP_BD 002 Buffer table not up to date and Table BBP_DOCUMENT_TAB is empty
In config I activated the extended classic scenario as well as activating the backend purchasing groups as responsible. Under sourcing I also defined for the relevant product categories as "1 - Sourcing Never Carried out"
Am I missing something obvious??
Many thanks for any help.
Daniel

Hi Daniel,
In reference to the info. you have provided, it looks like you have not switched to Extended Classic Scenario properly.
Once you say you are on ECS, the P.O should get created in SRM and the copy of it should get replicated to R/3.
As you said you have flagged both the check boxes in SPRO for ECS activation, try activating sourcing also.
SPRO > IMG > SRM > SRM Server > Sourcing > Choose one Product category for which you want to create shopping cart and set the setting as " Sourcing Always carried out".
Check whether the approved shopping cart is coming to Sourcing cockpit or not.And from there try to create a P.O by assigning vendor.
Also ensure that no BADI is activated which converts ECS to Classic scenario for the Product category you have choosen.
If this cycle woks then definitely what you require will also work.Clarifications are welcome.
Award points for helpful answers.
Rgds,
Teja

How differentiate POs classic scenario and POs extended classic scenario?

Hi Gurus,
Is possible determine that some POs are generated in SRM system and send to R3 (Extended classic scenario) and other POs only to send from SRM to R3 system (classic scenario) in the same system?
How we can differentiate which POs should be sent to R3 (classic scenario) and which not? Is possible use type of document for example? Could you explain me if exists standard process?
The objective is determining the following: Is necessary differentiating POs created in SRM of importation and should be sent to R3 system (classic scenario), and in case of local POs (not importation) is necessary extended classic scenario.
I have understood that there is a scenario that includes the Classic and Extended Classic, I think is called Decoupled scenario.
Thanks for your help!!

Hello,
Yes this is possible.
You can do it automatically based on the product category. You must define the back-end system you wish to use for each product category by making the relevant settings in Customizing for SAP SRM under SRM Server --> Technical Basic Settings --> Define Backend System for Product Category
Check the online documentation here: http://help.sap.com/saphelp_srm701/helpdata/en/f3/6f505050404ce99151722a79a2c089/frameset.htm
You can also use Business Add-In BBP_EXTLOCALPO_BADI to overwrite settings made in Activate Extended Classic Scenario and implement more rues for the scenario determination, e.g. based on the purchasing organization for manually created PO's.
First you set you system to Activate Extended Classic Scenario : SPRO --> SAP Supplier Relationship Management --> SRM Server --> Cross-Application Basic Settings --> Activate Extended Classic Scenario.
Then you set exceptions in the BAdI.
Regards
Franck

SAP eSourcing with SRM Extended Classic Scenario

Hi Team,
We are using ECC 6.0 with eSourcing. Currently we use SRM 5.0 with Classic Scenario.
Now we are planning an upgrade from SRM 5.5 to SRM 7.0 and want to do the Extended Classic Scenario. This will help us to do additional functionalities of SRM.
eSourcing can be used for Strategic RFx and CLM functionalities.
SRM can be used for SC, Operational Sourcing and PO. We can also use the SRM-SUS Scenario for PO confirmation and Invoices.
Have any one used eSourcing with SRM Extended Classic? In that case, please provide some light into how to use all these application to better streamline the overall Source to Procure strategy.
Also, do you think Classic is the way to go or Extended Classic is better? Any documents or pictures are greatly appreciated.
Thanks
Jogy

Hi
SAP provide standard integration b/w ECC and Esourcing/ CLM (PR (both inbound and outbound). However in case you decide to go with extended classic scenario,you might need e Sourcing/ CLM integration with SRM (since PO would be created in SRM) which is not provided out of the box by SAP. However custom interface (based on flat file transfer) can be built b/w SAP SRM and e Sourcing.
MM-SUS scenario is not much different from EBP-SUS scenario in terms of functionality.
Regards
Mudit Saini

No GR on Confirmation Approval in Extended Classic Scenario

Hi all gurus out there,
We are trying to implement confirmation approval workflow in our SRM system. Our SRM version is SRM 3.0 or EBP 4.0 and we are operating in extended classic scenario.
We implement the approval workflow WS10400002 (1-step approval) and WS10400010 (no approval). WS10400002 is used in situation when an administrator does the confirmation and will go to the requestor for approval. Here, when the requestor approves the confirmation, the status is updated correctly to 'Approved' but no goods receipt is triggered by the system. We looked at the workflow and found that there is no task/activity to do the post goods receipt in the backend system.
Can someone please confirm whether these are the correct workflows that I should be using and that it is not a bug? I just want to make sure it is not as a result of a standard limitation before going back to SAP.
Cheers!
Siow Fong

Hi Guys,
I checked with SAP on this and found out that the standard codes would have created the goods receipt. This creation is no longer coded in the workflow itself (like the old workflow used to be). The reason why it was not working for us was a piece of code being added that prevented the creation of the goods receipt.
Regards
Siow Fong

Problem in Extended Classic Scenario related to PO

hi,
we are using Extended classic scenario in our client. User has created a SC .when we are going to create a PO system is showing an error Purchase Group B01 does not exist.
This Purchase group is not created in R3 or neither replicated to SRM.and it is not assigned in the Org structure.
Kindly Let me know from where the purchase Group might be Picked apart from the org Structure.
regards
subhash

Hi
Can you check your SC how this Purchase group picked form your basic data ?
since this purchase group is existing in srm thats why it picked while create sc right?
regards
Muthu

Extended Classic Scenario, BADI for PO creation in R/3

Hi,
We are using the extended classic scenario. When the PO gets replicated from SRM to R/3, right now the field CATALOGID is not being transmitted to the backend R/3 system.
1) What BADI should I implement (and the method) to transmit the CATALOGID to R/3?
2) After implementing the BADI, do I also have to change the BAPI?
3) Is the BAPI used to transfer data from SRM to R/3, BAPI_PO_CREATE?
Thanks and Regards,
Peter

Hi Peter,
1-You can use BBP_ECS_PO_OUT_BADI for ECS scenario.
Since the R3 PO does not have field for catalog id, the EKKO- BEDNR (Tracking Number) field can been used for example to store this information. In this BADI all the items are identified and their tracking number field is populated with a catalogue id value.
2-If you use the tracking number field, no use of R/3 BADI is required.
3-BAPI_PO_CREATE1
Please check my answers in this post :
catalogid field not going in R3 backend
Kind regards
Yann
Message was edited by: Yann Bouillut
Message was edited by: Yann Bouillut

ASN for extended classic scenario

Hello all,
we have SRM with extended classic scenario (EBP-MM),
is it possible to use ASN (shipping notification) functionality in our system ?
Kind regards,
Arthur

Hi
ASN can be created by the vendor in SUS system for that XI mapping is required. ASn can be created in SUS by any vendor users. I guess it's not possible with ECS.
Please check the SAP Consulting Note 1026638 GR Output Integration with MM-SUS Scenario for R/3 <= 47
You need to have functional background for this:
To create an ASN against PO or SA release:
1. you need to compulsarily put how much qty you are sending against the reqd. qty(shown by PO / SA )
2. dispatch vehicle no. (optional)
3. road challan no. (optional)
4. one more optional entry ( sorry I forgot)
Useful related pointers ->
Re: how does the GR get into SUS---MM-SUS Sceanario
ASN in Extended Classic Scenario with SUS
SUS ASN & Invoice
The specified item was not found.
Do let me know.
Regards
- Atul

GR based IV check box suppressed - Extended Classic Scenario

Similar Messages

Maybe you are looking for