Direct procurement always as extended classic -- why ?

Hi ,
As per SAP's specification , ' SRM Server is the leading server for direct procurement. This means the system behaves according to extended classic scenario' .
Is there any specific reason on why the scenario would always be extended classic for direct procurement ?
And does this also imply that in a classic scenario, if a SC is created for a direct material which refers to backend material , the PO created would be in accord with the extended classic scenario ?
Reasons/Answers --- Anyone ?
thanks-
Harmeet.

Hi Harmeet
Yes, even in classic scenario, if a SC is created for a direct material which refers to backend material , the PO created will be in accordance with the extended classic scenario by default i.e. a local SRM PO would be created which will be replicated to ECC. However you can alter this behaviour and force the system to create a PO in ECC (like classic scenario) by implementing BADIs.
Regards,
Nikhil

Similar Messages

Why extended Classic is implemented

Hi Everybody,
I was working in SAP SRM for past 3 years and only Support Experience. Yesterday attended an interview and he asked me why your client has implemented Extended Classic why not Classic Scenario?
I know it depends to client-to-client.
Can any one let me know the list of points need to be discussed to support this question. My answer was not impressive.
Sree

Hi Sree,
You are right here it depends on the client whether to configure the system for extended classic and classic scenario.
The extended classic scenario suits customer who wants to
their purchasing department to save time and money by using the streamlined purchasing functionality of SAP SRM
use the full sourcing capabilities offered by SAP SRM, yet who also want to be able to confirm and invoice direct materials
the flexibility of being able to pre-enter confirmations and invoices
Where the classic scenario suits the customer who wants:
wide user group, for example employees not necessarily working in the purchasing department, to be able to enter their requirements quickly and easily. SAP SRM’s functionality and ease of navigation allow this, as it requires only minimal training
their purchasing department to operate solely with the functionality offered by the backend system(s)
For whom a transfer of purchasing activities to SAP SRM is not viable in SAP SRM
You can use both the classic and extended classic capabilities by configuring the product categories
Please let me know if the above answer is helpful.
Best Regards,
Ankit Jain

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.

Direct Procurement in Classic Scenario

Hi Experts,
We are on SRM 7 Ehp1, ECC 6 Ehp4.
Classic Scenario.
1. I have read in the forums , that in Classic Scenario, direct procurement is possible but the system behaves like Extended Classic and creates a Local PO. Just want to confirm this and if yes , does this happen as a standard or do we need to implement any BADI or anything to achieve this.
2. Also , in Classic Scenario, PDP scenario , can we transfer stock items(Direct Materials) PR's into SRM system or are there any limitations.
Thanks
Aditya

Hi Aditya,
You are right. Classic system behaves as extended classic for Direct procurement scenario. Your PO will be created in SRM itself and a copy of this will be sent to ECC. This happens as a standard and no BADIs need to be implemented for this.
Also in your classic system, you can transfer stock PRs into SRM. These will be available as shopping carts in the sourcing cockpit.
Regards,
Nikhil

Service Procurement in Extended Classic Scenario

Hi,
We are planning to use SRM 7 EHP 1 with backend ECC 6 EHP 4. We are leaning toward the extended classic scenario. However we are a bit confused reading some documentation that saying Service Procurement classic can only be used in classic scenario.
What does this mean? To put this in more simple, can we have this scenario in extended classic deployment:
PDP:
1. We create PR with 2 items, each item have 3 sub-line services,
2. We push this PR to SRM
3. We create PO in SRM and it is copied to ECC.
4. PO will have 2 items, with each item have 3 sub-line services.
Self Service Procurement:
1. We create SC with 2 items, each items have 3 sub-line services,
2. We create PO in SRM and it is copied to ECC
3. PO will have 2 items, with each item have 3 sub-line services.
Really appreciate if someone can clarify this point.
Best regards,
Josh

Dear Josh,
For your scenarios below:
Self Service Procurement:
1. We create SC with 2 items, each items have 3 sub-line services,
2. We create PO in SRM and it is copied to ECC
3. PO will have 2 items, with each item have 3 sub-line services.
The shopping cart and PO in local SRM system does not support service hierarchy (Service subline) in the system.
PDP:
1. We create PR with 2 items, each item have 3 sub-line services,
2. We push this PR to SRM
3. We create PO in SRM and it is copied to ECC.
4. PO will have 2 items, with each item have 3 sub-line services.
Here also, the system will not create po in the local srm system. The local PO cannot support service hierarchy. The system by default create the purchase order in the backend system directly.
Thanks and regards,
Ranjan

Direct procurement in Classic

Experts,
Need your help once again.
I have implemented direct procurement in Classic scenario (SRM 7/ECC 6.0) and after reading on this forum, I realised that Direct procurement in classic, functions as extended classic because a local PO is created in SRM and this is replicated to ECC. So far this is working for me.
Now I want to make changes to this PO. It is not allowing me to edit PO in ECC which is right because PO was created in SRM and copied to ECC. But strangely, I am unable to edit PO in SRM also?
Is this correct behaviour?
Please suggest.
Best Regards,
John

Hi John,
For direct procurement, it will have nothing to do with CS or ECS.
SRM will create the local PO for direct material and transfer the PO into ERP. And you could not change the PO in ERP.
Regards,
Guoyu

Manage direct procurement in classic scenario

Hi Experts,
We are on SRM 701
Classic Scenario
can anyone let me know how we can manage direct procurement in classic scenario?
i want to kept goods in storage location and i cant do that because of account assignment tap in SC and as i know account assignment is mandatory to create a Sc
Regards
Elham

Hello Elham,
As suggested Account Assignment should always be used and one cannot skip it for creating the Shopping Cart. If you are having Classic Scenario then your PO would be in backend system directly which you can manage through dummy account assignment as guided you in your previous post. Just get in touch with your Finance Team and ask them to make a Dummy Profit Center/Cost Center which you can use while creating SC for your local Storage
Thanks
Gaurav Gautam

Service procurement using Extended classic scenario

Hi All,
Can Extended classic scenarion supports service procurement.
I mean SC with services and PO with services in SRM without hierarchies
If not any work arounds
Abdul Raheem

Hi Abdul ,
Service procurement using Extended classic scenario is not possible
PO wont able to create in SRM .
Thanks & Regards
Pradeep Kumar Dondeti

Why Extended Classic Scenario

Hello
I understand the difference between Extended Classic and Classic Scenario with the follow on document creation. But, I need to understand the business benifits of implementing Extended Classic Scenario as opposed to Classic Scenario in SRM. In what business scenario do one suggest Extended Classic.
Appreciate every answer
Thanks
Vijay

Hi Vijay,
The most important thing to consider when choosing the implementation scenario is to consider which system will support the different steps of the procurement process.
In case of the classic scenario, after creation of the request (shopping cart) in SRM, the remaining process steps will be handled / supported in the back-end system (ECC). Goods receipt can be executed in both systems. This would be a good choice if the organization has already an operational back-end system and the users from the purchasing department are already familiar (and happy) with all the MM functionality. SRM will only function as a support tool for administrating the purchasing needs of the end-users in the organization.
In case of the extended-classic implementation scenario the complete purchasing process will be supported in the SRM system (most organizations prefer to use the back-end system for invoice verification). Thus requesters, purchasers, goods recipients etc. all will use the SRM system to support their respective activities. This would be the preferred scenario in case both MM (ECC) and SRM are new to the organisation and will be implemented together.
SRM offers the different users a nicer user interface as opposed to the R/3 screens. Also the (strategic) sourcing capabilities of SRM can only be used when implementing the extended classic scenario. Same for the Suplier Enablement business scenariou2019s. Most are only supported when extended classic is active.
So depending on the intentions of the organization a choice can be made. SRM only as a tool for administrating the decentralized request from the end users in the organization: Classic scenario will suffice. SRM as a tool to support the complete purchasing process, from sourcing till evaluation - Extended classic will be the correct choice.
Regards,
Skander

Procurement Card in SRM 7.0 Extended Classic with PPS

Could sometime tell me if we can implement Procurement Card functionality when you have SAP SRM 7.0 Extended Classic with PPS enabled. Appreciate any help in this regard. Thanks, Alisetty

Gurus:
Anyone have any idea about using Procurement Card when you have SRM7.0 Extended Classic with PPS.
I didn't find any lead on this and appreciate your inputs.
Regards,
Vijay Alisetty

Difference between service procurement classic and extended classic?

I could you find any document for extended classic.
Could anybody help explain what is different between the 2 classics?
Thanks!

In the Extended Classic scenario, the entire procurement process takes place locally in EBP (SRM) and a copy of the data is replicated to the back-end system. In essence, this scenario is an extension of the Classic Scenario.
The purchase order in the back-end SAP system (ERP , R/3 System) is a read-only copy that enables goods receipt, service entry, and invoice verification in the back-end system. The back-end purchase order cannot be changed. If you wish to make any changes to the purchase order, you must do so in EBP i.e. SRM system. Once you save these changes, they are transferred to the back-end purchase order.
While in Classic Scenario , The PO is created in the backend ERP system once the SC is approved.
In brief , you can say while in extended classic scenario , the backend ERP system is a read only system and we do everything is EBP (SRM) system only. and in Classic Scenario , ERP system was used to generate the purchase orders.
Hope it clarifies and gives you a little visiblity on what is the difference between both.

Configuration of Service procurement for Extend Classic

Hi SRM Gurus,
Can anyone send me the configuration documents for configuration of service procurement for extend classic scenario.
I have referred to SRM Enterprise Buyer 5.0 Configuration (SRM 210) and SAP Library. But both of these doesn't talk about the configuration steps involved in that.
Any documents, leads and help would be highly appreciated. My email id is [email protected]
Thanks
Ramgopal Verma

Hi,
In plant Y, you have to maintain Spl.procurement key in material master. In MRP 2 view assign External procurement & spl.procurement kery 40.
In the plant X, create material master as inhouse production in MRP 2 view.
Have to maintain BOM & Routing in plant X.
Configure in SPRO> MRP> Planning> Define spl.procurement key.
In this assign Issue plant as X.
Run MRP for plant Y. System create Stock transport req in plant Y.
Convert this req into stock transport order.
In plant X, dependent req will create.
Use MB1B mvt type 301for single level stock transport.
For multi level stock transport use MB1B 303 - issue & 305 -receive mvt.
Regards,
Dharma

Anybody ever created multple PO doc type/number ranges in extended classic?

I have searched this forum, and found plenty of useful threads which would help me determine different document types/number ranges for back-end purchase orders in a classic scenario. (And I have done something similar many years ago on a classic EBP 3.0 implementation)
However, I have a customer who has an SRM 5 extended classic implementation, and who (Based on certain simple criteria) requires a different PO number range to identify certain types of indirect orders. (They also have direct materials procured using doc type ECDP, but that's not relevant to this requirement)
This would obviously have to apply to the local PO in SRM, as well as the backend ECC PO.
It would also need to be derived for orders created automatically via approved shopping carts, as well as those orders that are created via sourcing.
I've copied ECPO via define transaction types IMG step, as well as assigned a new number range.
Just to test, I've also added the second doc type in the BSA attribute for a particular test user - just initially see if it was possible to manually choose when creating a PO in sourcing. However, I could only get ECDP and ECPO.
I have looked at various BADIs to see if I can determine doc type or number range somewhere in the PO creation, but as far as I can see, they either:
- Seem to apply only to the object type (PO, requisition, reservation etc) rather than the transaction type within that object.
- Or look like they are too late in the process to influence the doc type and number range (BBP_DOC_CHANGE_BADI?) ... which doesn't seem to have those doc type or PO number fields available anyway
- Or I doesn't seem to be trigerred at all when turning requirement into Po and ordering via sourcing. (tried break-point & endless loop in implemnetation of BBP_CREATE_BE_PO_NEW, but nothing happened. In any case the PO number was alreadya ssigned)
If anybody has ever managed this before, or can tell me that I am definitely barking up the wrong tree, it would be gratefully appreciated. The document type is actually lesss important than the different number range... and was really just an attempt to trigger a different number. I'm starting to think that this sort of thing may only be possible in a classic implemntation.
What I need ideally, would have been some kind of 'local PO' equivelent of the BADI that enables you to determine transaction type for a bid.
Regards,
Vince
Edited by: Vincent White on Dec 6, 2010 5:13 PM

Hi. Not sure on this, but I can tell you that with extended classic it is BADI BBP_ECS_PO_OUT_BADI that is called for the backend PO instead of the CREATEPO_BACK BADI.
You can have a look in BBP_ECS_PO_OUT_BADI and see if that helps?
Don't think it will influence the PO in SRM at all though.
Have you tried the number range / grouping BADIs? They definitly work for changing the number range for classic POs.
Regards,
Dave.

Questions about Extended classic scenario

Hi gurus,
I'm working in SRM 5.0, ECS, backend ECC 6.0 (only one backend).
Everytime a SC is being approved a SRM PO has be created. Then a copy of this PO has to be created in ECC with document Type ATT and the same number of the SRM PO.
I have two questions
First of all I need to know the settings to make in 'Define objects in backend system' (for every purchasing Group and every Category ID, I need to create always PO in backend).
P.Gr Category ID Source System Internal proc. External proc.
* TRDCLNT011 Always external procurement PO if item data complete, otherwise P.Req.
Is this correct?
Secondly I need to understand the logic for number range definition
SRM Activities
1 - Define number range for Shopping Cart
I Need to create a SC number range
01 1000000000 - 1999999999
and then associate this range (01) to SHC transaction type ('Int.n' field)
2 - Define a number range for local PO
LO 7000000000 - 7999999999
and then associate this range (LO) to ECPO transaction type ('Int.n' field)
3- Create a new transaction type 'ATT' (backend PO)
4 - Define a number range for backend PO
PO 7000000000 - 7999999999
and then associate this range (PO) to ATT transaction type ('Int.n' field)
ECC Activities
1 - Define a number range for document type ATT
XX 7000000000 - 7999999999
and then associate this range (XX) to ATT Document type 'External
Is this correct?
I'd really appreciate your help
Points will be rewarded
Thaks in advance
Best regards
Gg

Hi. It all sounds about right.
I don't think the define backend docs does a great deal in ECS, you always get a PO with extended classic. If you ever want anything but a PO, a reservation for example, you have to not use extended classic for those items.
The number ranges look OK, although I think you only need 1 number range for the backend/local POs, it should all go in line on its own. It's been a while since I got an ECS system going so it is hard to remember.
The thing to do is try it in a test system and see what happens.
If anything goes wrong let us know on SDN what error messages you get and we should be able to help.
Regards,
Dave.

Classic and Extended classic scenario

Hi All,
Can we have classic scenario for Service procurement (MM-SRV) and Extended classic for direct material procurement in the same SRM system.
This is because Extended classic doesnot support service procurment where as Classic scenario supports
Does any body implemented like this. If so pls let me know Pros and cons
Abdul Raheem

Hi Laurent,
Thanks for reply.
Do we have any limitations if we go by this model like Service procurement by Classic and Direct procurement by Extended Classic.
If any thing breif on PRos and Cons of going by this model.
Abdul raheem

Direct procurement always as extended classic -- why ?

Similar Messages

Maybe you are looking for