Control extended classic mode BADI

Hi,
I am trying to setup the system to work in the extended classic scenario.
I have activated the extended classic switch and i am using the BADI control extended classic badi.
For product categories that i want to use in extended classic mode, the logic inside the BADI returns a "X"
For Eg: I have a product cat "Boards" for whcih the BADI returns "X"
When i add this pruduct category to my shopping cart, there is a dump in ITS.
However, I remove the product cat "Board" from the BADI, I am able to add this product cat to the shopping cart without a dump.
Please let me know why this is happening.
Dump:
Runtime Errors           UNCAUGHT_EXCEPTION
Except.                  CX_BBP_PD_ABORT
Date and Time            04/21/2010   06:07:37
Short dump has not been completely stored (too big)
What happened?
The exception 'CX_BBP_PD_ABORT' was raised, but it was not caught anywhere
       along
the call hierarchy.
Since exceptions represent error situations and this error was not
      adequately responded to, the running ABAP program 'SAPLBBP_PDH' has to be
      terminated.
Please help
Thnaks,
Vignesh

Hi Laurent,
I am getting the foloowing error. Can you identify what is going on ?
Information on where terminated
    Termination occurred in the ABAP program "SAPLBBP_PDH" - in "BBP_PD_ABORT".
    The main program was "SAPLBBP_SC_UI_ITS ".
    In the source code you have the termination point in line 73
    of the (Include) program "LBBP_PDHU08".
Source Code Extract
Line SourceCde
   43
   44   READ TABLE lt_callstack INTO ls_callstack2 INDEX 4.
   45   CONCATENATE   '/' ls_callstack2-eventtype
   46                 ls_callstack2-eventname ls_callstack2-progname
   47                 INTO lv_msgarg3 SEPARATED BY space.
   48
   49   CALL FUNCTION 'BBP_ALERT_INTERNAL_OT'
   50     EXPORTING
   51       msgid   = gc_msgid_bbp_pd
   52       msgno   = 047
   53       msgarg1 = lv_msgarg1
   54       msgarg2 = lv_msgarg2
   55       msgarg3 = lv_msgarg3.
   56
   57   MESSAGE ID gc_msgid_bbp_pd TYPE c_msgty_i NUMBER iv_msg_no
   58           WITH ls_callstack1-eventtype
   59                ls_callstack1-eventname
   60                ls_callstack1-progname.
   61
   62   rollback work.
   63
   64 * get the messages from the application log
   65   TRY.
   66       CALL FUNCTION 'BBP_PD_LOG_GET_MESSAGES'
   67         TABLES
   68           e_messages = lt_messages.
   69     CATCH cx_bbp_pd_abort.
   70       REFRESH lt_messages.
   71   ENDTRY.
   72
>>>>>   RAISE EXCEPTION TYPE cx_bbp_pd_abort EXPORTING
   74       worked_on_document = lv_guid
   75       t100_msgid = gc_msgid_bbp_pd
   76       t100_msgno = iv_msg_no
   77       t_appl_log_messages = lt_messages.
   78
   79 ENDFUNCTION.
Pls help

Similar Messages

User attributes in extended classic mode

Hi,
If i want to use the system in extended classic mode, what should i maintain in the attribute of BSA in the organization structre?
Should i maintain 1 entry for document type ECPO for SRM system and an another entry entry EC for the backend system.
Thanks,
Vignesh

for example if you create a direct material PO's you have to maintain this attaribute DP_PROC_TY
To ensure that the documents can be transmitted to the back end, you have to maintain
corresponding transaction types, document types, and number ranges in Enterprise
Buyer and respectively in the back end system.
Whatever PO transaction type you may use and it must be equivalent to ECC document type.
and number range must be same srm and ECC since SRM only determines the number range for this.

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

Activate extended-classic by badi -- PO not created in ECC

Hi,
in certain circumstances I activate the extended-classic escenario in SOCO using Badi BBP_DETERMINE_LOGSYS~DETERMINE_LOGSYS:
'logical_system = 'ECCSYSTEM'.
I do this because i need to launch the PO workflow in SRM for the PO created in the SOCO. The problem is the PO is created with the 'saved' status, not in 'order' status, and also when it approves such requests are not replicated to ECC.
If i change the scenario with the BBP_EXTLOCALPO_BADI~DETERMINE_EXTPO Badi I have no problem, the PO is created with 'order' status and when i approved the PO is replicated inmediately in ECC.
Any idea about this problem?
The scenario is classic in srm 7 with ehp8.
Thanks.

Hi,
I would believe the configuration is not properly done in your system.
The BADI BBP_EXTLOCALPO_BADI~DETERMINE_EXTPO is the only BADI you can used to adjust if ECS PO will be created.
By using the BADI BBP_DETERMINE_LOGSYS, it has instead lead to a SRM local PO is requested for and this PO will never replicated to the ERP. If you are not requiring it, please leave this BADI completely.
ECS PO will always be ordered when the PO information is complete. It will be HELD status when the information is incomplete. If you encountered HELD status, it means a purchaser has to complete those missing information first before the ECS PO can be saved. Do you have some customer fields that are mandatory but not populated in the SOCO creation and this lead to HELD status?
Regards.
YS

Controlling extended classic

We are using the Extended classic scenario in SRM 5.
A requirement has now surfaced where all catalogue items should be processed within SRM PO wise so when the cart is approved it reacts just like extended classic where a copy of the PO goes to R/3.
Free text items once approved should invoke the classic scenarion via Badi BBP_EXTLOCALPO_BADI.
Our problem is that it cannot destinguish between catalogue and free text items and as we are not using R/3 products and types we can only use the product category section of the method, but as catalogue items could have the same category this causes a problem as we do not want to add categories specific for catalogue shopping and the decoupled scenario does not suit the model
Can anyone help with a suggestion we have also looked at using the the badi BBP_DETERMINE_LOGSYS
Tom

Hi. I take it the idea of duplicate categories did not go down too well? Another option, how about getting really creative with the BADIs?
1 - Create a custom table to store 3 fields - cart number, line number, real product category
2 - Create 2 product categories, 1 called "Catalog" 1 called "Free Text"
3 - Use the BBP_DOC_CHANGE_BADI method BBP_SC_CHANGE to check if the current t-code = BBPSC07/8/9 (whatever you use as the approval inbox) and SY-UCOMM = "approve" (or complete approval step, whatever SRM version you are on) and this is the last step of the workflow then change product category to either "free text" or "catalog" and also write the original values to the custom table
4 - Get the BBP_EXTLOCALPO_BADI working off the 2 product categories
5 - Use the BBP_CREATE_PO_BACK BADI to change the product category from the dummy one to the real one by reading the custom table for backend POs
6 - Use the BBP_DOC_CHANGE_BADI method BBP_PO_CHANGE to change the product category from the dummy to the real for the local POs
The only down side to this is that the cart will end up with the dummy product category. You could try the BBP_DOC_CHANGE_BADI again to see if it is called after the backend docs are transferred, then you can swicth from the dummy to the real again.
Regards,
Dave.

Classic / Extended Classic Scenario for Shopping Cart

Dear Friends,
We are working on two different business scenarios with same Product type, Product and Product Category where we would like to control Extended Classic Scenario.
1. Self Service procurement to be executed in Classic Scenario as the follow-on document (Purchase Requisition) should be created in backed ECC system.
2. Plan Driven Procurement cycle where External requirement is transferred from backend ECC to SRM keeping Extended Classic scenario active so that system creates Shopping cart in SRM.
So which condition should I use to control the Classic / Extended Classic Scenario in BADI BBP_EXTLOCALPO_BADI method DETERMINE_EXTPO.
Regards,
Sandeep Parab

Thanks Pierre,
My Sourcing requirement is working as desired with following code in BADI BBP_SRC_DETERMINE (method DETERMINE_SOURCING).
method IF_EX_BBP_SRC_DETERMINE~DETERMINE_SOURCING.
DATA: w_header TYPE BBP_PDS_SC_HEADER_D.
CALL FUNCTION 'BBP_PD_SC_GETDETAIL'
EXPORTING
    I_GUID = HEADER_BBP_GUID
IMPORTING
    E_HEADER = w_header .
IF sy-subrc = 0.
IF w_header-subtype = 'ER'.
    SOURCING = 'X'.
ELSE.
    SOURCING = ' '.
ENDIF.
ENDIF.
endmethod.
However Im not able to control the Classic and Extended Classic Scenario even after introducing field EXT_DEMID in structure BBPS_EXTPO_BADI in badi BBP_EXTLOCALPO_BADI and method DETERMINE_EXTPO.
method IF_EX_BBP_EXTLOCALPO_BADI~DETERMINE_EXTPO.
IF ITEM_DATA-EXT_DEMID = ' '.
BBP_EXTPO_GL = ' '.   for classic
ELSE.
BBP_EXTPO_GL = 'X'.   for extended classic
ENDIF.
endmethod.
No idea y this is not working to my knowledge it should work
What do you think ? this this code and badi actiation im not able to perform SSP in classic mode and sourcing with extended classic mode.
Regards,
Sandeep Parab.

Extended Classic Scenerio and Vendor Text

This subject has been brought up before, I've reviewed all those messages. The standard SRM product does not replicate vendor text to the backend system in the extended classic mode.
Having said that, I've been trying to make this work and hope someone here can give me some insight on what I am doing wrong.
In my setup, SRM is using function module B46B_DPO_TRANSFER to send the purchase order to R/3. This fm has a table called i_longtext that contains the header text.
B46B_DPO_TRANSFER calls FUNCTION 'BBP_PO_INBOUND' DESTINATION lv_destination" to create the PO on R/3. This call is missing the POTEXTHEADER table definition. So, I've modified the call to include this table and also filled the table with the following values:
po_item = 00000
text_id = F01 "this value was obtained from the text type for purchase order header configuration settings in R/3"
text_form = *
text_line = "the message that was typed in the header text"
I can't seem to get the header text to appear on the purchase order in the backend, has anyone been successful in making this work?
Kind regards,
Shawn O'Connor

Hi
Incase BBP_LONGTEXT_BADI does not helps, then you can use the BADI, which i mentioned in my earlier post.
In the BADI - BBP_CATALOG_TRANSFER, there is a table structure, which holds the long text data.
Refer table ET_SC_LONGTEXT inside ENRICH_ITEM_DATA method of this BADI.
Here is the documenatation of this BBP_CATALOG_TRANSFER BADI.
Short Text
Transfer Shopping Cart from Catalog
You can use the Business Add-In BBP_CATALOG_TRANSFER to change or add to the data that the catalog returns to SAP Enterprise Buyer via the catalog interface.
Note that your changes also affect the following applications in SAP Enterprise Buyer:
Confirm Goods Receipt/Service Entry
Plan Products for Maintenance Order
The call of this BAdI occurs in function module 'BBP_WS_IMPORT_SC_DATA'. This module is called by the relevant application to import catalog items previously sent by the browser of the user to the application Web server from there. After the catalog has transferred the data to SAP Enterprise Buyer the system carries out the following actions.
Conversion of ISO code of unit of measure and currency to SAP format
Conversion of price field to SAP format
In the case of transfer of a material or service number:
The system reads the product master with this number. If the number exists, the system transfers from the product master record the description and the purchase order unit of measure.
In the case of a partner number:
The system reads the business partner master with this number. If the number does not exist, the number in the shopping cart item is reset.
Note
In previous Releases, only the tables with the prefix "ENRICHED" were available. These were then returned to the calling application and transferred to the relevant document structure from there. From this Release on, the data is transferred from the current document structure to the application. The relevant tables are included as additional parameters (parameters with the prefix "ET_SC_").
New implementations should use these tables only and set the parameter "ev_sc_structures_used". In order that previous implementations need not be changed, a mapping occurs after the BADI. The parameter controls the mapping direction:
Set: New structure overwrites old structure
Not set: Old structure overwrites new structure
In the method ENRICH_ITEM_DATA, the following parameters are available:
catalog_content
This parameter contains the original data that the catalog transferred to the catalog interface. The structure corresponds exactly to the catalog interface. The data in this parameter is only for information purposes, you make any changes in the parameters et_sc_item_data , et_sc_accounting, et_sc_partner, et_sc_orgdata, et_sc_longtext, and et_sc_messages.
Note
The catalog interface also contains customer fields that you can use for your own purposes. You can pass these on in fields that the application can use further.
enriched_item_data
This parameter contains the data for a shopping cart item in Enterprise Buyer.
Note
This table should not be used in new implementations (see above Note).
enriched_acct_data
This parameter contains all account assignment fields. This parameter is empty at this time in the standard system.
Note
This table should not be used in new implementations (see above Note).
enriched_item_longtext
This parameter contains the long texts for the items.
Note
This table should not be used in new implementations (see above Note).
catalog_content_errors
This parameter contains the error messages that occurred when the catalog items were being enriched.
Note
This table should not be used in new implementations (see above Note).
ev_sc_structures_used
This parameter has to be set if the following tables are used in the implementation (recommended procedure, see Note above) et_sc_item_data This parameter contains the data of a shopping cart item in Enterprise Buyer.
et_sc_accounting
This parameter contains all account assignment fields. In the standard system, this parameter is empty at this time.
et_sc_partner
This parameter contains the links to the requester and the supplier, if used.
et_sc_orgdata
This parameter contains the links to the org. data for the partners from
et_sc_partner.
et_sc_longtext
This parameter contains the long texts for the items.
et_sc_messages
This parameter contains the error messages that occurred during enrichment of catalog items. If this table contains a message of type 'E', the item causing this error is not transferred to et_sc_item_data. If the item is added in the BADI again (from the data from catalog_content), the relevant error message should be deleted, since the current SRM Server application generally searches this table for error messages of type 'E' in order to output an error message to the user.
Hope this will help.
Please reward suitable points.
Regards
- Atul

Freight is not updated in R/3 in the Extended Classic scenario

Friends,
Freight is not updated in R/3 in the Extended Classic scenario.
Once a PO is ordered, if a freight condition in SRM is applied, it does not get updated in R/3.
We have created a condition for Freight (Value and Percentage)in Create
Payment Conditions using the following menu path:
spro
--> Supplier Relationship Management
--> SRM Server
--> Cross-Application Basic Settings
--> Pricing
--> Process Payment Conditions
When creating a Purchase Order in SRM in the "Item Data" tab, there is
a"Pricing" option. Choose "Pricing" and select "Add Further Conditions"
from the drop down menu. Here Freight is available. Add Freight and
the PO record in SRM is updated with the Freight Condition. However,
upon ordering, the Freight condition does not transfer to the PO
recordin R/3.
We've heard this can be achieved by enhancement: only ie by implementing
set of BADIs.. But does anyone know WHICH BADIs we need? Or how we could find out? Thanks.

Hi
 You can either of these BADIs to handlwe the scenario.
BBP_CREATE_BE_PO_NEW Exit while creating a purchase order in the backend system
BBP_CREATE_PO_BACK OLD Exit while creating a PO in the backend system
BBP_ECS_PO_OUT_BADI ECS: PO Transfer to Logistics Backend
BBP_EXTLOCALPO_BADI Control Extended Classic Scenario
Hope this will help.
Please reward suitable points.
Regards
- Atul

Extended Classic Purchase Order created from RFx Response having complex pricing conditions enabled

Hello Colleagues,
I am currently analysing the correct usage of the complex pricing conditions in the sourcing process and wanted to understand the usage of the complex pricing condtions ( 01CT , dis % , header disc% , location dependent conditions , etc. with or without scales , ) while creating a extended classic purchase order directly as follow on document from rfx response.
How relevant is the price conditions 01CT. Consider a case if the price condition from rfx response to po is changed to price manual 01PB but the price is correctly copied when the po is initially created from rfx response.
Is this is the correct system behaviour ?
Kindly help to clarify the above points.
Thanks & Best Regards,
Rahul

Hi
 You can either of these BADIs to handlwe the scenario.
BBP_CREATE_BE_PO_NEW Exit while creating a purchase order in the backend system
BBP_CREATE_PO_BACK OLD Exit while creating a PO in the backend system
BBP_ECS_PO_OUT_BADI ECS: PO Transfer to Logistics Backend
BBP_EXTLOCALPO_BADI Control Extended Classic Scenario
Hope this will help.
Please reward suitable points.
Regards
- Atul

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

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

Customization step for classic to extended classic

Hi,
Currently I have implemented classic scenario in SRM 7.0 with ECC in back-end. Now I am planing to implement extended classic scenario. In the same time we are planning to continue the classic scenario for some product category. In breif: Purchase order will be either in SRM or ECC base on product category. Please guide me let me the necessary customization setting for implementing the abover scenario.
Thanks
Regards,
Jennifer

HI,
Please activate extended classic in SRM
SPRO: Cross-Application Basic Settings->Activate Extended Classic Scenario
SPRO: Business Add-Ins->Control Extended Classic Scenario (here you can control if you need PO in SRM or ERP)
Number range, tranaction types to be configured according for SRM and ERP
Regards
Sam

Control extended classic mode BADI

Similar Messages

Maybe you are looking for