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.

Similar Messages

  • Difference between service entry sheet and goods receipt?

    Hi all,
    What is difference between service entry sheet and goods receipt?
    Thanks!

    Hi,
    **Service Entry Sheet:: It** is only for Indirect  material (or ) services
    In the service p.o you have to Give the G/L account in the P.O
    It is one form of Goods Receipts for all the service related P.O what you are raising.
    For Example:
    1 Service charges for cleaning A/c- Rs 100/Hr.
    P.O can be raised for 200 hr. when the service is completed say for 2 hrs. You can raise service entry sheet for 2 hrs and the vendor gets payment  of Rs 200.
    Goods Receipts: For Direct material procurement only .
    G/L account is determined based on OBYC setting.
    Regards
    G.Ganesh Kumar

  • What is difference between  Service map iview and Workset Map iview

    Hi Experts,
                        Can anyone tell me the difference between  service map iView and Workset Map iView.
    When I am creating these iViews, its seams both are same. I canu2019t find difference still, can anyone help me out of this
    Thanks in Advance
    Janardhan

    Hi,
    Service Map Iview:The Service Map iView is an ERP-specific variant of the portal Workset Map iView. It serves as a central point of entry and guided access to the services of SAP service modules such as the Manager Self Service (MSS) module, or the Employee Self Service (ESS) module.
    Workset Map iview:A Workset Map is the equivalent of a site map, providing users with explicit information on the functionality that is available in a given workset. It is based on an iView, and serves as a central point of entry and guided access to the contents of a workset.
    if you want to more info pls go thr the below thread
    Workset Map iView
    i hope it will help you
    Thanks,
    Sreeni.

  • 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

  • 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

  • Difference between Service pack 13 and Service pack 22 in PI 7.0

    Hi,
    Kindly spcify the difference between Service pack 13 and Service pack 22 in PI 7.0
    Thanks

    Dear Nair,
    It is always recommended to apply the latest Support Packages on the PI system. The reason being that a lot of fixes are included in the latest SPs. Also, the perfomance of hte system will be improved with the latest SPs.
    Best Regards
    Nishwanth

  • 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

  • Classic and Extended Classic implementation

    Hi all,
    Can Self service procurement scenario be implemented in classic as well as extended mode?What are the differences in configuration in SPRO?

    Hi,
    There is no much differences in terms of configuration in SRM system.
    for extended classic scenarion  SPRO-> SRM server-> cross applications basic setting -> activate extended classic scenario
    This setting determines EBP system generates local purchase orders.
    If you are implementing Ext classic scenario no need to define the step  cross applicatoins -> Define objects in backend system
    Using badi  BBP_EXTLOCALPO_BADI you can override the setting in extended classic scenario, example: for certain product category using BADI we can create PO in back end system also ( classic scenario ).
    Thanks & Regards,
    Prasad.s

  • Difference between Service data objects and process data object

    Hi
    Can anybody tell me what is the difference between SDO (Service Data Objects) & PDO (Process Data Objects).I am using 2 port PCI-CAN series 2 card.
    If anybody knows the answer then please reply.
    Thanking You

    Hi,
    See the online help file from our NI CANopen Library for LabVIEW for some basic informations about SDOs and PDOs.
    More information should be available from the web.
    DirkW
    Attachments:
    lvcanopenvhelp.zip ‏154 KB

  • 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

  • Difference between service order quotation and service contract quotation

    Hi,
    Can any one differentiate service order quotation and service contract quotation??
    appreciated with points
    Regards,
    Nagi Reddy

    Service Order:
    A service order is a short-term agreement between service provider and service recipient, in which one-time services are ordered by the service recipient and resource-related billing performed upon completion. Such an order could be, for example, to maintain or repair some equipment, making it necessary to send a technician along with spare parts. These services are usually billed.
    Service Contracts:
    Service contracts are outline agreements with business partners which define services offered for a particular period. You support service contracts by processing contract-based and planned services.
    Service contracts represent long-term service agreements with customers in relation to the content and scope of services guaranteed within specific tolerance limits for certain parameters, for example, within a predefined timeframe.
    I hope this helps

  • Difference between My Procurement Substitutes and Manage Substitute rules

    Hello,
    I have question regarding SRM 7.0 Substitution for Shopping cart approval workflow. We have defined Process Controlled Workflow (BRF) for Shopping carts.
    There are two ways substitution which i am seeing.
    1) Go under Personalization -->  User Account --> "My Procurement Substitutes" and then add Person as substitute.
    2) Under Work item There is tab called "Manage Substitution Rules"
    Could you please advise what would be suitable option to place Substitution once some approver is going on vacation...
    Thank you
    Ritesh

    Hello,
    Procurement substitutes are linked to team purchasing functionality. Check the following link:
    http://wiki.sdn.sap.com/wiki/display/SRM/Team+purchasing
    Substitution rules are related to approvers substitution. Check following link:
    http://help.sap.com/saphelp_nw70/helpdata/en/0b/1fc20097b74c41b38621ec2a9454bb/frameset.htm                                          
    Regards,
    Ricardo

  • 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.

  • 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 service pack and Patch in XI

    What is the difference between Service Pack(SP) AND Patch ??
    e.g SP12, Patch8.
    Is it like that when there is a major change they will issue SP and
    for a small change they will issue patch ?? or after number of patches
    they will issue SP combining all the patches ??
    Service Pack level can be seen from SAP gui system..>status.
    But Patch level where can we see ?? what is the Tcode for that ?? or just we got
    to go through below links ??
    http://<host>:<j2ee_http_port>/sap/monitoring/ComponentInfo
    also
    http://<host>:<j2ee_http_port>/sap/monitoring/SystemInfo for core system info (J2EE or JVM patch level, etc.)
    thanks
    kumar

    Hello,
    A service pack (in short SP) is a collection of updates, fixes and/or enhancements to a software program delivered in the form of a single installable package. Service packs are usually numbered, and thus shortly referred to as SP1, SP2, etc. It is notable that they may bring, besides bug fixes, entirely new features
    A patch (sometimes called a "fix") is a quick-repair job for a piece of programming. During a software product's beta test distribution or try-out period and later after the product is formally released, problems (called bug) will almost invariably be found. A patch is the immediate solution that is provided to users; it can sometimes be downloaded from the software maker's Web site. The patch is not necessarily the best solution for the problem and the product developers often find a better solution to provide when they package the product for its next release.

Maybe you are looking for