Automatic local PO creation has errors - SRM 5.0

Question

Hi there,
We are busy upgrading to SRM 5.0 and are having some issues....
I can create a shopping cart from the catalog and it creates a local PO but the PO is always in HELD status. When I look at the PO in BBP_PD I get the following errors:
E BBP_TAX             006 Data inconsistency during tax calculation                 
E BBP_TAX             006 Data inconsistency during tax calculation                 
E BBP_PD              358 Select a location to which a plant has been assigned      
E BBP_PD              865 Delete price or set 'Invoice Expected'                    
E BBP_PD              358 Select a location to which a plant has been assigned      
E BBP_PD              865 Delete price or set 'Invoice Expected'             
I have debugged function module BBP_PD_PO_CHECK and can see that the "invoice expected flag" is NOT set in the PO - this causes the "Delete price or set 'Invoice Expected'" error.     
The "Select a location to which a plant has been assigned" error is because there is no location on the document...in subroutine "GET_PLANT_FROM_LOCATION" in program "SAPLBBP_PDIGP"......not sure why that would be blank though....
The "Data inconsistency during tax calculation" is because in my debugging it was wanting a SUBTYPE of "ST" but it gets "EP". What concerns me about this one is that it actually should be "EP"...
I have been trying to debug the SC to PO mapping to see what could have gone wrong....I think it would be in BBP_PD_SC_MAP_TO_PO_LOC?
NOTE: I have had to TURN OFF the Pricing BADI (BBP_PRICEDATA_READ) implementation (BBP_PRODUCT_PRICE) to get this far. If it is active I get the following error in SM58.
"Purchase orders cannot be created without IPC pricing"
Has anyone had these issues before?
Any help will be greatly appreciated
Lynton

Answer 1

1. Did you activate extended classic in SPRO (or rather - is it still activated )
2. Did you retrieve the locations from the backend (as mentioned before by several others) check
3. The badi you mention should be deactivated, as pricing is done using the built-in IPC (SRM 4.0 had a not built-in one - maybe still pointing at the SRM 4.0 one?)
4. Check if the IPC is running correctly (go to SE38 and play around with IPCTEST* or TESTIPC* - too long ago to remember the correct report or was it something with pricing. The one thing I know is that TEST was definately in it!)
5. Vendor master data is correct?
6. Did you define that tax calculation is done in the backend (SPRO)? check
Regards,
Robin
Edited by: Robin Janke on Jun 20, 2009 8:49 PM