cancel
Showing results for 
Search instead for 
Did you mean: 

Shopping cart contains error

Former Member
0 Kudos

Hi All

Created shopping cart in SRM 4.0 and got approved.

After approval cart status shows "Approved" but in the item details status shows "Contains errors".

No follow-on document created in R/3.

In Display changes section it says "Error in transmission" and "Item in process indicator: Status is Inactive" changed by field shows WF-BATCH.

Where could be the error. In workflow or during transmission?

Did anyone faced this problem?

Thanks in advance

Jagdish

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

HI Jagdish,

Like you I am getting an error while transeferring the shop cart, but no alerts.

Did you describe any message type for the PO in distribute model......

Regards Sachin

Former Member
0 Kudos

Hi Jagdish,

I also face similar problem and resolevd my maintaining Attribute BSA "Document Type in R/3 System" in Organization Plan . This has to be maintained as below :

R/3LOGICALSYSTEM\ECPO

Hi Sachin, PO from SRM to R/3 goes thru RFC And nothing to be defined in distribution model for PO. For details on communication refer link below

Pls. confirm result.

Sanjay

Former Member
0 Kudos

Hi

After running FM BBP_REQREQ_TRANSFER that error is not coming for new shopping carts.

But PO is not creating in backend instead shopping cart goes into purchasers worklist.

I observed no source is picked inspite of inforecord exist in R/3. It says no source exists.

When I select a preferred vendor it creates PR in sourcing I suppose.Because preferred vendor is to suggest buyer to consider. Thats why shopping cart goes into purchaser's worklist. Am I correct?

I dont understand why Inforecord is not picked as the source of supply automatically.

What could be the reason.

Thanks

Jagdish

Former Member
0 Kudos

Hi,

First, if your SC lines are going into the sourcing cockpit instead of creating backend document, it is due to the sourcing customizing you've made in SRM (Carry out sourcing for items without SOS).

Concerning your need. If you want your system to pick up the prefered vendor as assigned vendor, and thus create a PO or PR in R/3, then you have either to manage vendor lists in SRM, or to "manually" assign the prefered vendor as the assigned one in the SC change BADI.

About you inforecords in R/3, SRM standard does not look into R/3 for vendor assignement during the SC creation (but you can choose to develop something in the BADIs for that) .

Regards.

Vadim

Former Member
0 Kudos

Hi Vadim

Thanks for your response.

But SRM documentation says source will be picked automatically if there exists Info record or contract in backend system.

I did manage vendor list in SRM and I assigned preferred vendor from that vendor list. Still it is going to purchaser's work list.

You mean even for picking Inforecord as source during shopping cart creation, we need to develop logic in BADI ? But I understand that is standard functionality.

Regards

Jagdish

Former Member
0 Kudos

Hi,

Once again about the sourcing cockpit, watch your customizing if you don't want the items to get into it.

Concerning inforecords and backend contracts use in SRM, this is a new function that allows you to get these data as SOS <u>in the sourcing cockpit, not for SC</u>.

This has been done by SAP to allow the Sourcing cockpit in a classic scenario.

Once again, keep in mind that the SC and the requirement (in sourcing cockpit) are 2 different documents in SRM.

In the SC creation, you only can use local data as SOS, so for your need, yes, you'll have to implement a BADI.

Regards.

Vadim

PS: Please don't forget to reward points on helpful answers in your threads.

Former Member
0 Kudos

Hi Jagdish,

When you mean You managed vendor list in SRM, looks to me you would have activated the customizing "Define Sourcing via Vendor List Only". You are saying those appears as SOS while creating SC. If that is true, It will not allow any R/3 Info Record and Contract appearing as SOS. It works as designed for you.

If you want to look up of all SOS on Specific SCs, do not activate globally "Define Sourcing via Vendor List Only". Use the BADI BBP_AVL_DETERMINE.

Regarding SC going to Sourcing, Pls check that you do not have the customizing "Define Sourcing for Product Categories" or BADI BBP_SRC_DETERMINE activated. Without this, it can not go to Sourcing automatically.

One more thing you may want to check is the Completion by Purchaser workflow is triggering the SC to Sourcing.

Thanks,

Jay

Former Member
0 Kudos

Hi Vadim

Thanks for you valuable suggestion. Rewarded points for this thread.

Yes, SOS is possible only for local data and vendor catalog items.

Do Info records propose as SOS in sourcing cockpit. I didnot test it because we are facing problem in opening Carry out sourcing screen (getting Screen does not exist error)

In case of preferred vendor, I am selecting from vendor list (which is created in SRM) into SC in following scenarios.

1. Customized "Sourcing never carried out" for one category. Error "ME013 DocumentType ECPO not allowed with doc. ca"

2. Customized "Sourcing carried out for items without assigned SOS" for other prod category. SC shows "In purchaser's work list"

3. customized "Auto creation of bid invitation if no SOS". Bid invitation is creating succesfully.

I dont understand why error comes in point 1 above inspite of maintaining vendor list.

Even maintained ECPO in both SRM (trans typr) and R/3(doc type).

Thanks

Jagdish

Former Member
0 Kudos

Hi,

Jagdish, As I told you, I think the error you get comes from a customizing issue in SRM or R/3 on document type.

I think the complete error message is "ME013 DocumentType ECPO not allowed with doc. category", and it comes from the backend

Please check the following:

-Are you abble to create manually a PO of type ECPO in R/3 ?

-If so, check you assigned in R/3 an externel number range to doc TYpe ECPO, that corresponds to SRM ECPO internal number range

-Finally check what happens by debugging, please repost for that I'll give you step by step instructions.

Regards.

Vadim

Former Member
0 Kudos

Hi Vadim,

1. Yes, I am able to create PO manually in R/3 for ECPO.

2. Ext no. range is assigned to doc type ECPO in R/3 and same no. range is assigned in SRM ECPO as internal no. range.

3. I need to debug. Will let you know once I do that. Because our project is shut down for 1 week. Once I get back to work will check and post you the results.

In this context I observed following issues.

1. When tried to create PO from sourcing by assigning vendor, getting error "Problem in determining backend follow-on docs".

2.When I tried to assign backend info record to the vendor in the Vendor list, I could only see backend Contracts and Outline agreements but not Inforecords to propose source of supply. Because of this not able to assign source automatically while creating shopping cart. How to bring backend inforecords as source of supplies in Vendor list?

3.I read in one of the threads that for direct material (Material replicated from R/3 to SRM Product master) PO cannot be created directly from SC without sourcing.

As per my understanding only when "Direct Material/Procurement" tab is choosen in basic data of SC, then it will be a direct procurement scenario otherwise we can create PO directly from SC for R/3 materials. Please clarify.

Vadim, I may be troubling you with issues as I am a functional guy but technically not good and getting very little support from Basis as they also not known much in this area. So please bear with my issues.

"Wish you Merry Christmas and Happy New Year"

Thanks

Jagdish

Former Member
0 Kudos

Jagdish,

I am also having a similar problem...

This is my comple set up..

Settings For

a. Purchase Requisition

b. Purchase Order

In R/3

a.

<No range> PR 8000000000 - 8999999999 (Checked Ext range)

<Doc Type>: PR, No.rng.Ext:-PR, Field.Sel:- PR (EBP purchase requisition)

b.

<No range> 75 0007500000 - 0007999999 (Checked Ext range)

<Doc Type>: 75, No.rng.Ext:-75, Field.Sel:- PQ (EBP Purchase order)

In SRM

a.

<No range> : PR 8000000000 - 8999999999

b.

<No range> : 75 8000000000 - 8999999999

c.

<Define No range per backend system for follon doc.> No.Range PO :75, No.Range PReqs: PR

d.

<Define objects in backend system (Pr, PO, RS)>

External Procurement, Always Purchase Requisition.

e.

<in the org for Attribute BSA>

backendsystem\PR for purchase requisition, backendlogsys\75

Sourcing :

1. maintained no sourcing for a product id (1).

2. Always cary out sourcing for a product id (2).

Scenarios:

When doing the shopping cart for Product id (1).. it is creating a PR in the backend system..(Obvious from setting d. )

When doing the shoppinc cart for Product id (2).. it is pushing the requirement to Sourcing and from there when i fill in the vendor data and click Create PO then it throws up an error

"Shopping Cart 0010000804 (Purchase order 0007500007): ME013 Document type PR not allowed with doc. category F (Please check input)"

Can u guide me in what steps i am messing up and i dont know from where does the SRM transaction type come into picture..

Regards

Sunny

Former Member
0 Kudos

Hello Jagdish,

Concerning your issues:

1- Message "Problem in determining backend follow-on docs" when trying to create a PO from Sourcing Cockpit. Depending on your customizing, is this SC supposed to be in ECS or Classic scenario ?

In case of classic scenario, SRM will create a PO directly in R/3 (see point 3 for direct procurement), using BBP_PD_SC_TRANSFER_MULTI_BE_PO. In that function, SRM reads your customizing point "Define Objects in Backend System (Purch. Reqs, Reservations, Purch. Orders)" and overwrites entries with "Always External Proc" + "PO if item data is complete". It will then request the backend to see what kind of document is allowed, depending on item data (product ID ?, category, vendor....). This is done with META_INTERPRETE_DATA. If R/3 sends back another document type than PO, then SRM raises this error BBP_PD 283 "Error during determn of backend follow-on docs".

Check this customizing point (do you use * or Purch grou Org IDs...).

2- you can only assign backend contracts in SRM vendor list (search help is provided). No Info records.

have you activated the customizing point "Sourcing via Vl only" ? If not, and if you are in classic scenario, the system will search SOS directly in R/3, and there you will get contracts AND info records.

In ECS scenario, SOS are searched locally + vendor lists.

3- Direct procurement basis: it is quite similar to ECS process (SC --> local PO --> R/3 PO), with account assignement cleared (order to stock).

So if you choose direct procurement for a SC item with a product ID, send it to Sourcing Cockpit, you will create a local PO replicated to R/3.

If you don't choose direct procurement for this item, then you can create a PO directly in R/3 from sourcing, if you are in classic scenario.

Your understanding is good, but you where misleaded by this thread that was more about the need of product IDs to activate direct procurement.

Rgds

Christophe

Former Member
0 Kudos

Hello Sunny,

this message ME 013 is raised by R/3 because your system tried to create a PO (doc category F in R/3) with document type PR (sent by SRM).

This document type comes from attribute BSA that you have maintained with 2 entries "backendsystem\PR" for purchase requisition, "backendlogsys\75" for PO.

But there is no logic of attribute value determination depending on R/3 doc type.

You say that one is for PR and the other for PO.

But how can the system select the correct value automatically ????

Where do you have read such a mechanism ?

At the SC creation time, the system stores the backend doc type in table BBP_PDBEI-BE_DOC_TYPE (you can check the value in BBP_PD, bottom of SC item data).

This value is retrieved when trying to create a PO in R/3.

As you have 2 values, the system gets the default one and, bad luck, you get PR instead of 75.

In general, we define the same R/3 doc type for PR & PO in attribute BSA, so you need only one attribute value.

Otherwise, use a BADI to change this BE_DOC_TYPE_FIELD:

- BADI change SC if you know what kind of doc will be created

- BADI create BE PO to change the value

Hope this helps.

Rgds & happy new year

Christophe

Former Member
0 Kudos

hi Christopher,

Thankz for your reply.. it really helped me to crack the problem..

i went ahead and maintained the same doc types for PR and PO in the backend system and its working fine....

i had no problems creating a backend PO when pushing the shopping cart into the sourcing and doing the bidding..

but the problem arrises when i am trying to use the bidding engine to create a bid, accept it and then create a PO (skipping the SC and sourcing)....

Error : Purchase Order cannot be created without IPC pricing...

Where do i set this up ....

Out of the box, can we directly start from the bidding engine and create a backend PO.. because from bidding it is alwayz asking for transaction types and not for the backend doc types..

I will assign u points for the next thread ..

i was unable to do it for the last reply..

Regards

Sunny

Former Member
0 Kudos

Hi Sunny,

AS we said in previous posts, you can not create directly a backend PO from Bidding without starting from a SC.

So, starting from bidding, you can only create local or ECS PO (replicated to R/3). Except with custom code.

In that case, the PO pricing is done in SRM via IPC.

IPC could be avoided in previous releases by activating BADI to use old ABAP pricing in classic scenario only.

To you have de-activated IPC ?

Without IPC, you could not either create a SC, the system would dump in pricing function modules.

Rgds

Christophe

Former Member
0 Kudos

Hi Christophe

Thanks for your explanation

1. We are in classic scenario and getting Message "Problem in determining backend follow-on docs" when trying to create a PO from Sourcing Cockpit.

What I observed is, in BSA attribute I could see only one ECPO value. I have maintained ECPO as the doc for both PR and PO in R/3. I suspect that ECPO (PR) is selected in BSA attribute and that could be the reason why I am getting the error while creating PO. System expects ECPO (PO) but I could see only one ECPO in BSA attribute search help list while choosing.

Am I correct in my analysis. If so what should be done in selecting ECPO (PO) in BSA attribute. Where could I be wrong?

2.I have customized "Sourcing via Vendor List" in my classic scenario. In my vendor list I could see only R/3 contracts and Outline agreements as SOS. but no Info records from R/3. How could I select R/3 Inforecords as SOS in vendor list. If that is selected in VL then the same would get assigned automatically to the SC as SOS.

3. Now it is clear that SC will go to Sourcing when "Order as Direct material" is selected. Product ID should be there in SRM and R/3.

I have rewarded some points for this thread.

please help me in resolving my above 1 & 2 points.

Thanks

Jagdish

Former Member
0 Kudos

Hello Jagdish,

For point 1 & 2, I can not add more than in my previous reply:

1- this is related to "Define Objects in Backend System (Purch. Reqs, Reservations, Purch. Orders)" and not to BSA attribute (otherwise you would get the same message as Sunny when SRM tries to create a PO in R/3 with a wrong doc type). Try to debug the process (you can call Sourcing cockpit in SAP GUI) and set a break point in FM BBP_PD_SC_TRANSFER_MULTI_BE_PO or in instruction "message".

2- we can only maintain backend contracts and agreements in VL. No info record. I have no solution for you via VL. For some custom project, we have derivated the local source of supply search (standalone or ECS scenario) to search for backend contracts and IR.

If you are in classic scenario, what is the added value of using VL, because in VL you assign backend contracts that are already selectable in native SOS search ?

If you want the exact copy of backend SOS in your VL, then it is more effective to search directly R/3 SOS, isn't it ?

If you really want to maintain VL as a mirror of R/3 SOS, then you must create a VL for each product (!!!) and assign manually all vendor IDs having Inforecords for this product in R/3, without entering a contract ID. Those vendors should be the same as in R/3 InfoRecord, but you would not have any search help on backend docs like for contract IDs.

3- The action "order as Direct Material" is not linked at all to the sourcing process. It triggers a process where a local PO is created, and replicated to R/3. Depending on your sourcing customizing, items will be sent to sourcing, would it be direct procurement or not.

We must have product ID in both systems (I am still investigating the possibility to use a product ID from the catalog without replicating it in SRM).

Rgds

Christophe

Former Member
0 Kudos

Hi Christophe

Thanks for your help.

1.I am able to create PR but not PO. I have selected the preferred vendor in SC. Because vendor was not picked automatically.

I have maintained both PR and PO num ranges and doc types in R/3. I did not understand why PR is created instead of PO in backend.

2. I have removed Vendor list and disable vendor list in sourcing. Still am not able to pick Info record as SOS.

What could be reason?

Thanks

Jagdish

Former Member
0 Kudos

Hello Jagdish,

1- If you select a preferred vendor, then you will create a PR with this preferred vendor. To create a PO, you need to have a valid SOS (a fixed vendor and not a preferred). This can be done by:

- ordering an item from a catalog with assign vendor

- automatic SOS assignment(if only 1 SOS found)

- manual selection of proposed SOS (BE CTR, IR or SRM VL)

- SC WF completion by purchaser to assign the vendor

- BADI SC change to change the preferred vendor into a fixed one (just have to change its partner function)

2- To see backend IR in SC SOS tab, you need:

- to be in classic scenario

- an item with a product ID (replicated from R/3)

- have this SC item assigned to the same Purch Org than your R/3 IR purch Org

- have the R/3 IR vendor replicated into SRM

- have no or the same plant in R/3 IR than SC item plant

If all those are ok, take a look at R/3 BAPI_SOURCEDETERMIN_GETSOS, where you could have some user-exits changing the data.

Rgds

Christophe

Former Member
0 Kudos

Hi Christophe

Thank you very much for your helpful support.

1-

-Created SC with Product master (same material ID in R/3)and not from catalog.

-No SOS selected by the system.(but only one IR exists in R/3). So not selected any preferred vendor also.

-Completed the SC without vendor.

-PR created in R/3.

-In BBP_PD observed obj type as BUS2105.

-Tables BAPIEBAN and BAPIEBKN got updated.

-IR & vendor entries are picked in BAPIEBAN table correctly from R/3 though vendor is not selected in SC.

This means system is picking the right source.

2-

-I am in classic scenario

-Item with product ID is selected (replicated from R/3)

-SC item assigned to same P.Org as R/3

-R/3 IR vendor replicated in SRM

-Same R/3 plant assigned to SC item.

Still backend IR is not shown in SC SOS.

I observed that everytime system is trying to create PR. In BSA attribute the value assigned is ECPO/PR.

I could not see ECPO/PO in the attribute list to select in BSA.

This could be the reason for generating PR. Am I correct?

If so what should be done to make ECPO/PO visible in the attribute list of BSA.

Also checked BAPI BAPI_SOURCEDETERMIN_GETSOS. It is giving same vendor as in BAPIEBAN table.

Thanks

Jagdish

Former Member
0 Kudos

Jagdish,

1- Without SOS, you will always create PR in R/3.

With a valid SOS, you can create a PO, except if you force a PR in SPRO / Define Objects in Backend System (Purch. Reqs, Reservations, Purch. Orders) --> Ext. Proc = "Always a PR"

2- Debug your transaction when adding the SC item, the system will read SOS from R/3. Set a break point in META_SOURCEDETERMIN_GETSOS to see what's going on.

Rgds

Christophe

Former Member
0 Kudos

We are facing multiple issues related to this -

1) we are finding that automatic PO is not getting created if there is a SOS like Info record in the backend system. It always creates the PR eventhough we have checked in SPRO as PO to be created if item data complete. We tried to created the same doc types for both PR and PO in the backend but it isnt solving the issue, we still get PR created.

2) The second issue we are facing now is that suppose we create a contract then none of the SOS are displayed in SRM.

Not sure why this is happeneing. Any help is welcome

Thank You

Abhinandan

dennis_bruder
Employee
Employee
0 Kudos

Hi,

if you are familiar with the debugger the best way is to debug FM BBP_REQREQ_TRANSFER, but if not you could call transaction BBP_PD in your SRM system. Enter your SC no in the object id field and flag the fields check document and find alerts.

Maybe you can find here a hint what is wrong with your cart.

Regards

Dennis

Former Member
0 Kudos

Hi Dennis

Checked the shopping cart in BBP_PD.

In Status block it says "Item in transfer process" as Inactive and "Error in transmission" as active.

In BBP_PD under alert block, it shows

Shopping cart/Backend application errors.

In Argument1 Shopping cart no, Argument2 PR no is picked, Argument 3 “ME013 Document type ECPO not allowed with doc. Ca”

Can you help me out what could be the problem?

Thanks

Jagdish

Former Member
0 Kudos

Hi,

That means you didn't create and customized correctly the document type (called transaction type in SRM, deocument type in R/3)

The ECPO document type must be created in R/3 and assiociated to PO document category.

Regards.

Vadim

Former Member
0 Kudos

Hi Vadim

Thank for your reply

Actually I have created document type ECPO in both SRM and R/3. In SRM ECPO is defined in BUS2201(EBP Purchase order) transaction type.

Even created number ranges and assigned number ranges to ECPO in R/3 and SRM.

I dont understand why it is not transfering to backend.

Can you tell me if I have missed any customizing other than above or any background jobs are missing?

Thanks

Jagdish

Former Member
0 Kudos

Hi,

Your WF seems to work well, the error should come from the transmission. Try to launch FM BBP_REQREQ_TRANSFER in debug mode, you'll get the error.

nb: this FM is called at the end of the WF by the system.

Regards.

VAdim