Extended classic scenario and printout in ERP

Hi,
we want to use extended classic scenario but the printout of the PO should happen in the backend system. PO is already created in the ERP system but I can't change it (as designed). How is it possible to create the printout from the backend?
Thanks
Hubert

Hi Hubert
This consulting note is for triggering Output of PO from ECC instead of SRM. Printing can happen from ECC if you can switch off PO Output form SRM and start triggering the same from ECC as per consulting note.
Try working with this FM In SRM BBP_OUTPUT_PO_PRINT_REMOTE for printing the PO, if PO Output is still required to be triggered from SRM.
Regards
Virender Singh

Similar Messages

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

Extended Classic Scenario - Free Items?

Does SAP support PO's in Extended Classic Scenario with a zero price (free items)?
My client is switching from classic to extended classic scenario and they require to be able to creaet PO's that have a zero price like they have in the classic scenario.
We are currently getting an error that we need a price with the IR flag, but I would expect the system to automatically unflag the IR flag for a free item?

Hi Jay,
Thanks for your response. There are two problems with your soluiton. First the shopping cart doesn't have the IR flag on it and can't be changed by the user and we have PO's created directly from SC's and go out to the vendor.
Second, In extended classic scenario it apprears that the system doesn't allow you to change the ir flag on the PO and make the cooresponding change in the ERP PO.

Extended classic scenario in SRM 7.1

Hi colleagues,
we want top use SRM 7.1 with extended classic scenario and we want to create POs in SRM and reflect them in ERP backend. The question is it possible somehow to change those POs aftewards (e.q. add confirmations, transportation costs, etc...) in ERP? Or is there any way to trasnfer POs in hold status from SRM to ERP and then change them in ERP?
Thanks and regards, Anton

Hi Anton,
PO is created a in SRM as local and a copy( copy does not contain the entire PO info, only the useful for the backend) is being sent to R3.
DO NOT try to search a workaround for modification in the backend..sooner or later you will be incurring in incosisnten data and misalignmentes.
SRM is the PO golden source.
Thanks and Regards,
Abraham

SRM 7 : Vendor record replication in backend with Extended Classic Scenario

Hello,
We are implementing SRM 7 with Extended Classic Scenario and Supplier Self-registration.
Can you explain what is to be configured to get the new vendors replicated to the backend?
Thanks in advance.

Hi,
It is possible to transfer suppliers to ERP system, if you use 'Supplier registration with ERP' scenario. After registration and acceptance, newly registered suppliers would appear on supplier monitor from where you can transfer them to backend system.
Check the below link for more details:
http://help.sap.com/saphelp_srm50/helpdata/en/cf/35074152aff323e10000000a155106/frameset.htm
Regards,
Sanjeev

Extended classic scenario to Classic scenarioc in SRM.??

someone pls tell me how to change from Extended classic scenario to Classic scenarion while creating in shopping cart...?
I am using BADI "BBP_EXTLOCALPO_BADI" change to classic scenarion from extending classic..but i got confused about source code..So i request any one can help me for suitable source code..

Hi
Do you mean to say that you have set up Extended Classic Scenario but you want to change it to Classic Scenario?... If this is the case, remove the activation in COnfiguration for Extended classic scenario and deactivate BADIs you ve implemented for Extended Classic
OR
Do you want to change it to Classic only for the Document user is creating.--> Read the indicator or data from SC and decide whether the document has to be in Classic or Extended classic SCenario.... The BADI will either have Extended classic = X or NOT.... so there is no parameter for classic Scen... Depending on your requirements, implement the ext. classic badi to SET it or NOT set it...
Regards
Virender SIngh

Extended Classic Scenario - how does the integration work ?

Hi,
Apologies for asking a basic question, but we are looking at requirements for integrating SRM with R/3 using the extended classic scenario and I need to understand how the integration actually works ? How is the data transferred between the 2 systems ? Does it use BADI's, idocs etc ?
Many thanks,
fiona

Hi Olaf,
I just wanted to give some precision on what you said (in the thread How to "see" PO in EBP ? also)
The Extended classic scenario only refers to the local PO creation replicated in R/3.
In this scenario, in the R/3 PO only the data not managed/sent from the SRM are available for modification (which depends on the SRM version you use)
The "PR transfer from R/3" is called "Plan driven procurement", and in this scenario only RFC is used, the qRFC are only used for BDocs of the CRM Middleware.
Regards.
Vadim

Extended Classic Scenario - PO Update issue

Hello experts.
We are working with SRM 5 in the extended classic scenario and we have a serious problem in a productive environment for the following case.
(01) We create a purchase requisition (PR) in R/3 with several items;
(02) We send PR to the SRM generating a shopping cart;
(03) The buyer creates a PO for all items from the shopping cart;
(04) The PO is transmitted to R/3;
(05) For some cases buyer changes the PO wich is sent back (updated) to R/3;
So far so good. The problem happens when some item in the request already has GR or Invoice. In those cases when the PO is updated on SRM, its transmission to R/3 does not occur, generating an error log that can be seen in transaction RZ20 of SRM.
I understand that if any GR or Invoice exists for the item it can no longer be modified, but is it expected that no other item can also be modified from SRM? What is the expected behavior for this case?
Moreover, even if the GR and Invoice have been canceled, we are still unable to update the PO in R/3 from SRM. Is this a expected behavior? It was our understanding that the PO should be updated if all incoming documents (GR, Invoice, SES ..) were completely canceled.
We appreciate any help on this matter.
Thanks and Regards,
Evandro Miasato

Hi, Masa,
Thank you for your advice,
I set the method U:Print Using Berkeley Protocol, after that
in trx. SP01 I have the Error Status on Composite Document -
Status Incorrect (Reason Unknown).
Best regards,
Guzal.

Tolerances in SRM extended classic scenario

Hi all,
I have a question regarding tolerances in extended classic scenario and I hope that somebody could help me.
We use extended classic scenario. The tolerance group is attached to TOG attribute in PPOMA_BBP, tolerance key is DQ.
We also tried to use tolerance key CF, but it seems as if CF is not applicable for GR?
However, whenever we try to confirm more than PO quantity, we get an error message. PO Ordered quantity exceeded by 1 EA
It seems so that SRM has a double tolerance check
one in SRM against defined tolerance (via attribute TOG)
one in R/3 against the PO tolerance
Now my question: Is this the expected behaviour or a bug? We do not want to maintain two tolerances. And furthermore most of the time we have POs without a material master. Are there any possibilities to skip the PO tolerance check?
Thanks for your help,
Martina
Edited by: Martina A. on Jan 15, 2008 1:13 PM

Hi
Depending on the SRM version you are using, Please go through the links, which will definitely help ->
Condition Type SRM - ECC
Tolerance in SRM and ECC (BE R/3)
Tolerance
Re: SC Budget check without SAP Fund Mgmt
TOG parameter and tolerance checks better understanding
Setting EKPO-UNTTO with BAPI_PO_Create
Re: SRM: many confirmation for PO
Please maintain the "TOG" attribute in PPOMABBP transaction in SRM.._
Do let me know.
Regards
- Atul

Classic and extended classic scenario with one EBP

Hello Guys
If I have a one EBP and multiple ERP back ends. For one backend, I need to have classic and other to have extended classic scenario. How this can be fulfilled. Is it possible, if so please provide the configuration setup.
Thanks in advance.

Hello,
In BADI BBP_EXTLOCALPO_BADI method DETERMINE_EXTPO.
you can try this.
Structure Declaration
DATA: ls_item_data TYPE bbps_extpo_badi.
Moving item data to a structure
MOVE-CORRESPONDING item_data TO ls_item_data.
SELECT SINGLE LOGSYS FROM comm_product
                                 INTO lv_logsys
                                 WHERE PRODUCT_GUID = ls_item_data-PRODUCT .
If lv_logsys = 'XXXCLNT010' "backend system
      Cancelling the enhanced classical scenario
        bbp_extpo_gl-bbpexpo = space.
ELSE IF lv_logsys = 'YYYCLNT010' "backend system
      Cancelling the enhanced classical scenario
        bbp_extpo_gl-bbpexpo = ' X'.
ENDIF.
Regards,
Neelima

Classic Scenanio and Extended Classic Scenario

Hi all,
I would implement on the same system 2 different scenario:
1. Classic Scenario for self service procurement
2. Extended Classic Scenario for the following business scenario:
a. PR from ECC is transfered into Sourcing Cockpit with Plan Driven Scenario
b. buyer convert the SC created in Sourcing Cockpit into a GOA or a PO that are transfered to ECC.
Can coexist this different scenario?
Can I address this different scenario only with organizational differences?
Thanks
Bye
Marco

Hi Marco,
I see 2 quick ways to realise your requirement.
The first is to create an attribute in t77omattr for a position and maintain that attribute in the organisational model. This attribute could just be filled with an X for example.
Then you have to implement BADI BBP_EXTLOCALPO_BADI and retrieve the attribute you created with FM BBP_READ_ATTRIBUTES (use sy-uname to retrieve the attribute for the current user).
The 2nd is to create a Z-table with the user-ids that you want to use the local (or ECS) scenario. Then again in BADI BBP_EXTLOCALPO_BADI you have to write the logic to retrieve and compare this.
Keep in mind that these are user-based distinctions and not based on scenario.

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.

BADI for Classic and Extended Classic Scenario

Hi,
   Please   provide list of Reports and BADI's for
       Classic and Extended Classic Scenario.
Thanks,
Srini

Hi,
In SRM there will be a number of BADI's are Available, We can utilize them according to the requirements
As per the request few important BAID are provided below..
Workflows
1). BBP_CHNG_AGNT_ALLOW:          Allow / Allow Change/Add Approver
This BADI is implemented not to allow users to change the approvers in the workflow.
2). BBP_WFL_SECUR_BADI:          Overwrites the authorization level of the approver
This BADI controls the restart of the workflow
Purchasing Related
1). BBP_PGRP_FIND:               Shopping Cart: Determine Responsible Purchasing Group(s)
This determines the responsible purchasing group for the shopping carts.
Shopping Cart Related
1). BBP_SC_MODIFY_UI:          BADI to Change Shopping Cart Layout
2). BBP_GROUP_LOC_PO:          Exit Grouping of Items for Local Purchase Orders
This splits local PO if more than one contract in a PO.
3). BBP_TARGET_OBJECTS:          Exit while determining target objects in backend
4). BBP_WF_LIST:               Change Worklists and Search Results Lists
This is used to restrict the search results for the user.
5). BBP_CTR_BE_CREATE:          Exit when Creating a Contract in the Backend System
6). BBP_CREATE_PO_BACK:          Exit while creating a purchase order in the backend system
This BADI is used to add the shopping carts attachments to the PO and also to make adjustments in payment terms, currency etcu2026
7). BBP_DOC_CHECK_BADI:     General BAdI in Cross-Check for Message Returns
8). BBP_DOC_CHANGE_BADI:     BAdI for Changing EBP Purchasing Documents
9). BBP_ECS_PO_OUT_BADI:     ECS: PO Transfer to Logistics Backend
Thanks
prasad .s

'BAPI_POEC_CREATE' function doesn't work with extended classic scenario

Hi everybody.
Antecedents:
We are working in an extended classic scenario.
When we create a Purchase Order via ITS in SRM, the system works ok, the PO is replicated in the ERP system.
But when we execute BAPI_POEC_CREATE function module in order to create a PO in SRM, no message are available in the application monitor, but the PO is not replicated in the ERP system.
Both exampled were created with exactly same data (partners, items, categories, accounts, )
Moreover when we modify the second PO created via ITS, the systems doesnt show any error message, we can order our PO again without error, but the PO isnt replicate in the ERP system.
1. We executed BAPI_POEC_GETDETAIL function module, and there is only a difference between POs, E_PO_STATUS table.
PO created by transaction has 8 entries:
       I1009 X
       I1015 X
       I1021
       I1038
       I1039 X
       I1043
       I1080 X
       I1180
And PO created by BAPI has 5 entries:
       I1015 X
       I1021
       I1038
       I1043
       I1180
2. We run BBP_PD transaction, and there is only a difference.
PO created by transaction mode shows:
- Message: W BBP_PD 830 Default values have been taken from Vendor PRUEBA10/purchasing organization Área Global Compras (org. compras)
And PO created by BAPI
- Message: No Messages
Could anyone help me with the problem?
Thanks in advance.
Raúl.

Hi Raúl,
this is exact, BAPI_POEC_CREATE is designed to create local PO.
If you want to replicate it to R/3, then you have to change it to an ECS PO.
In BADI BBP_DOC_CHANGE_BADI, called at the real beginning of BBP_PD_PO_CREATE, you will have to change some data to enable the ECS scenario:
- change header subtype to EP
- change header log system to SRM (keep FI LS as is)
- determine a backend purch group & org
- complete BE fields (be_object_id, be_object_type, don't change be_log_system because it will be determined during the transfer, be_pur_org and be_pur_group will also be determined during the transfer)
- ... and maybe other R/3 relevant fields
Compare both PO one by one, and adapt the gaps.
Rgds
Christophe
PS: please reward points for helpfull answers

Extended classic scenario and printout in ERP

Similar Messages

Maybe you are looking for