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.

Similar Messages

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.

Difference between new network and extended network

Difference between extended network and new network settings

An "extended" network acts as one large wireless network. Wireless devices can roam anywhere a signal is present and stay on the network without having to make any changes.
A "new" network will require that a wireless device manually "switch" to that network and enter the password for the network to connect whenever you want to use that network. In other words, a "new" network will use a different wireless network name and password, which will require that you manually log on to that network.
The exception would be if you created a "new" wireless network and used the same wireless network name, same wireless security settings and same password as the "main" network and connected the AirPort back to the main router using an Ethernet cable. In that case, you would have an "Ethernet extended wireless" network.

Reverting to classic scenario in SRM7.1, from PPS and extended classic

Hello Experts,
Recently we have moved from SRM7 to SRM 7.01, in which we can have PPS without Extended classic scenario.
As business wants classic scenario, How can we make the system as classic , in which PPS and extended classic is activated.
any badi is available for this? Please help.
Regards,
Raju

Raju,
Basically you have few points to keep in mind. (yes you need to activate the SPRO config for extended classic, apart from this).
1. switch between extended classic and classic is actually defined by the backend logical system of the document. if thats SRM itself then it follows the path of extended classic or if it is ECC then it follows classic.
because its basically creating a follow on document and that explains the scenario.
2. it also depends on what object are you expecting to be created. from a SC many documents can be created.
a. PO in SRM
b. PO in ECC
c. PR in ECC
d. Reservation in ECC
- so, if you can define at any point that where is your document to be created and what is to be created you can control the flow.
Now to do this. if you have few options.
Option1:
1. set the object types(2) for product categories (config, backend document type).
2. implement BBP_EXTLOCALPO_BADI to switch off extended classic
Options 2:
1. in doc change badi, change the backend destination to ECC
2. in Badi BBP_TARGET_OBJTYPE pass the object type you want your follow on document to be.
hope this explains

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

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

Classic Scenario to Extended Classic Scenario

Hi friends,
   We have a requirement to migrate an existing SRM 5.0 solution from Classic to Extended Classic scenario.
   Is there any best practices document available from SAP in this regard? Also what are the things that need to be taken care of in particular? It would be great if some one can share his/her practical experience.
   Thanks in advance!
Best regards,
Pradip

Hello
If it is Plan driven procurement involved, better to go for 'Classic' scenario. Extended classic scenario is best suited for self service procurement of indirect material.(of course both scenario are best for indirect material!)
Now Switching over to Classic ti Extended classic:
1) Technical settings-->Define product categories for backend
    Here source sys is ERP backend and the Target sys is SRM client
2) Nu. ranges for Local P.Os
3) In Cross application basic settings, Activate extended Classing Scenario and Backend pur.grp responsible
4) In Define Objects in Backend system(Pur.req, Resrv, P.O)
    Ensure no entries are there. Since this step is not required for Extended classic
5) BAdi need to be activated.
Before all these, ensure there is no pending documents/transactions exists. All need to be closed. No open purchase documents!
The best guide for ref. is by Shah Khan.
Regards

Differences between the 2007 and 2009 160GB Ipod Classic?

What are the differences between the 2007 and 2009 160GB Ipod Classic?

The 2009 model is slimmer. Click here for more information.
(50305)

Difference between Snapshot scenario and non cumulative scenario

Hi,
Can any one please tell me the difference between snapshot scenario and non cumulative scenario in
inventory management.
Also please give example. I read the pdf " how to handle inventroy management scenarios", but can any one please give some easy to understand examples.
full points guaranteed-

hi,
In Non-cummulative method your stock movements are stored in the cube (inflow and outflow of NC KF) and the Total stock is calculated during query execution. Hence if there are lot of movements in the stock for the period you want to report on, query will take long time to execute.
In case of Snap shot scenario Stock movements are not loaded to cube. you use ODS to load the status of the stock and then from ODS you can load to Cube once in a month. So only summarized data will be availabe in Cube. Reporting will be fast.
Check the below threads
Inventory Management - SnapShot model
snapshot scenario?
SNAP SHOT Scenario in IM

Difference in PO creation in Classic v/s Extended Classic

Hi all,
Can anyone tell me in details what is the difference in PO creation in Classic v/s extended classic scenario technically e.g. BAPI,FM etc?
What are the main settings which determine whether PO needs to be created in SRM(local PO) or backend ECC system?

Are you talking about IMG > SAP SRM > SRM Server > Sourcing > Define Sourcing for Product Categories?
performance assistance help text below?****
1.     Sourcing is never carried out
This is the default setting at delivery.
SAP Enterprise Buyer does not transfer any items to the purchaser's sourcing application.
2.     Sourcing is always carried out
SAP Enterprise Buyer transfers each item to the purchaser's sourcing application.
3.     Sourcing is carried out for items without a source of supply
SAP Enterprise Buyer transfers all requirements that have multiple sources of supply, of which none are assigned, to the purchaser's sourcing application. Once you have selected a source of supply in the shopping cart, the item does not go to the sourcing application and a PO is created.
4.     Sourcing via automatic bid invitation for items without a source of supply
SAP Enterprise Buyer creates a bid invitation for all requirements that do not have a source of supply.
5.     Automatic requirement grouping; sourcing for items without assigned source of supply
If a source of supply is assigned to a requirement, the report Automatic Grouping of Requirements for POs and Bid Invitations automatically attempts to create a PO from several requirements. If it is unable to do this, the requirement is displayed so that you can assign it manually in the sourcing application. Once you have assigned a source of supply, you can submit the requirement to the report.
6.     Automatic requirement grouping; sourcing is never carried out
If a source of supply is assigned to a requirement, the report Automatic Grouping of Requirements for POs and Bid Invitations automatically attempts to create a PO from several requirements. If it unable to do this, the system creates an incomplete PO for the requirement.
7.     Automatic grouping and creation of a bid invitation in the case of items without assigned source of supply
If a source of supply is not assigned, the report Automatic Grouping of Requirements for POs and Bid Invitations automatically attempts to create a bid invitation from several requirement items. If is unable to do so, this is recorded in the error log of the report.

Can we use both Stand alone and Extended classic in one SRM system

Hi All,
Our client is now using Stand alone SRM system with back-end R/3 FI-CO system. Now they want to go Extended classic scenario for few product categories.
         Would it be possible to use both in one SRM system? If possible could you please provide what are the sequential steps to do this?
             Thanks in advance.
Regards,
Ram

Hi Ramesh,
How did you end up solving your problem, as i have the same scenario. Did you use this BADI (
SRM Server->Business Add-Ins->Control Extended Classic Scenario->Activate Extended Classic Scenario)? Based on my reading, it seems this BADI is relevant to switch between extended classic and classic scenarios.
From what i understand, we can control the standalone scenario via the define backend system configuration (SAP SRM -> SRM Server -> Technical Basic Settings -> Define Backend System for Product Category). In my scenario, I have one set of product categories, so i will likely need to implement this BADI (BBP_DETERMINE_LOGSYS, method:   DETERMINE_LOGSYS - SAP SRM -> SRM Server -> Business Add-Ins ->Shopping Carts and Requirement Items -> Determine Backend System / Company Code) in order to determine the correct backend system based on company/plant for example.
Did you then leave the extended classic scenario activated (IMG --> Supplier Relationship Management -> SRM Server-> Cross-Application Basic Settings->
Activate Extended Classic Scenario)?
Or how did you achieve both standalone and extended classic using one SRM server?
cheers,
AD

SRM standalone and extended classic

Hi Experts,
Configuration: ECC 6.0 (with Ehp4 installed - (not activated)
SRM 7.0
Just want to seek confirmation of my understanding re: SRM implementation scenarios. Is it possible to have a extended classic and standalone setup using the same SRM server with same client? Both will have the same product categories. These will be for two separate entities/companies.
Thanks in advance.
Regards.

Hi Mike,
How did you end up solving your problem, as i have the same scenario. Did you use this BADI (
SRM Server->Business Add-Ins->Control Extended Classic Scenario->Activate Extended Classic Scenario)? Based on my reading, it seems this BADI is relevant to switch between extended classic and classic scenarios.
From what i understand, we can control the standalone scenario via the define backend system configuration (SAP SRM -> SRM Server -> Technical Basic Settings -> Define Backend System for Product Category). In your scenario, you have one set of product categories, just like mine, so i assume you had to implement this BADI (BBP_DETERMINE_LOGSYS, method: DETERMINE_LOGSYS - SAP SRM -> SRM Server -> Business Add-Ins ->Shopping Carts and Requirement Items -> Determine Backend System / Company Code) in order to determine the correct backend system based on company/plant for example.
Did you then leave the extended classic scenario activated *
MG --> Supplier Relationship Management -> SRM Server-> Cross-Application Basic Settings->
Activate Extended Classic Scenario)?
Or how did you achieve both standalone and extended classic using one SRM server?
cheers,
AD

Classic and extended Classic.....

Hi Guru's
Can we have classic and extended classic together..If yes what settings need to be done and how based on what system will diffrentiate the follow on documents creation.
Thanks in Adv.
IS

Yes, this can be achieved. By default you have to activate Extended Classic Scenario in the system. But using the BADI BBP_EXTLOCALPO_BADI, you can switch to Classic Scenario based on your requirement.
For more details please check documentation here in your SRM system
SAP Implementation Guide ->
Supplier Relationship Management ->
SRM Server ->
   Business Add-Ins (BAdIs) ->
    Control Extended Classic Scenario ->
     Activate Extended Classic Scenario
Regards
Kathirvel

Classic wht and extended wht

hi,
may i know what is the difference between classic wht and extended wht? can advise what is the major difference between these two?
thanks

Hi,
Classic WHT- In some countries, the law provides that invoice recipients must withhold a certain portion of the payment amount and pay this to the tax authorities as withholding tax on behalf of the vendor. This requirement exists in the United Kingdom, for example. In other countries, withholding tax need only be reported to the tax authorities for certain vendors, such as self-employed people. Withholding tax is not posted in these countries. This is the case in France, for example.
Withholding tax amounts are reported to the tax authorities at regular intervals and a statement is also sent to the vendor periodically. These reporting periods vary from country to country.
The way in which withholding tax is calculated depends on the type of service. Transactions may:
Have a variable base for tax/SI contributions
Have different tax rates
Not relevant for withholding tax
EWHT-With extended withholding tax, you can process withholding tax from both the vendor and customer view.
In Accounts Payable, the vendor is the person subject to tax, and the company code is obligated to deduct withholding tax and pay this over to the tax authorities on the vendoru2019s behalf. In Accounts Receivable, the company code itself is subject to tax, and the customers that do business with this company code deduct withholding tax and pay this over to the tax authorities on the company codeu2019s behalf. In both cases, the business partner of the person/entity subject to tax deducts the tax and pays it over to the tax authorities.
Withholding tax is calculated and posted to the appropriate withholding tax accounts at different stages, depending on the legal requirements in each country. As a rule, withholding tax is posted at the same time that the payment is posted, in other words the outgoing payment (Accounts Payable) or incoming payment (Accounts Receivable), is reduced by the withholding tax amount.
In certain countries, such as Brazil, the Philippines, and Spain, withholding tax can or must be posted when the invoice is posted. This means that the amount receivable or payable is reduced by the withholding tax amount.
Extended withholding tax supports both concepts.
The key concept in extended withholding tax is the distinction between withholding tax type and withholding tax code. While withholding tax types represent basic calculation rules, specific features of these rules - in particular the percentage rate - are represented by the withholding tax code. You can define any number of withholding tax codes for a given withholding tax type.
If a particular transaction requires more than one kind of withholding tax, this is covered in the SAP System by defining more than one withholding tax type. When entering a line item, you can enter withholding tax data for each of these withholding tax types.
For more information about the functions of extended withholding tax (in comparison to classic withholding tax), see Withholding Tax
The following special features also exist:
In some countries, such as Argentina and Italy, other kinds of posting are required for certain business transactions. Instead of the payment amount being reduced by the withholding tax amount, the withholding tax is posted as an offsetting entry to an expense account You make the relevant settings in the withholding tax code.
Where cleared items are reset, the clearing document is automatically reversed if it contains withholding tax data. For withholding tax types with accumulation, the accumulation base amount is adjusted if the payment document is reversed.
Hope this helps.
Rgds
Manish

What is classical starschema and extended starschema.

Hi All,
What is classical starschema and extended starschema.Diff betwn both .
Thanks in advance.

Hi,
As per my knowledge there is no classical star schema.... It is jus the star schema and extended star schema...
Star Schema :
Star schema is nothing but Fact table in the center and surrounded by the master data tables...... In star schema we have some draw backs thats why we move accross to extended star schema.....
1. There is no usability of master data becoz it is inside the cube.
2. We can analyse only from 13 angles
3. Performance issue becoz data will be in alpha numerics....
We have come accross with these in Extended star schema
Extended star schema :
Fact table in the center surrounded by the Dimension tables.. And we have out the Master data tables from the cube to outside and these tables linked to the dimensions with the foreign key and primary key relationship... Between these Dimension and master data tables we have SID tables in which the data will be stored in numeric format..........
And final one is we can analyze the data in 13 * 248 angles.....
Khaja

Difference between Classic Scenario and Extended Classic Scenario

Similar Messages

Maybe you are looking for