on 01-15-2016 8:16 PM
Hi SD experts!
I have researched in SCN search engine about this topic, and honestly have not found a similar case. I have read the SAP Wiki on pricing component (SD-BF-PR), but have not found a particularity pointing out this issue. http://wiki.scn.sap.com/wiki/display/SD/FAQ+for+SD+Pricing+SD-BF-PRI
From the previous wiki, I got to the SAP note “615370 - Condition update: Functions and restrictions” where I could find information regarding standard behavior of reason for rejection’s relation with pricing updates, but no link with the issue I am to present below.
Per the prior, I kindly request experts here if anyone has come across this issue, and found a standard solution to it (not a workaround).
BACKGROUND regarding business functional process in ECC for our company
In our SAP ECC 6.0 (SAP_APPL version 604 SP11), implementation we have customized for our exportation sales processes manual header conditions to charge our customers for additional expenses during the export process, this includes International Freight, Insurance, Expenses at Origin and Expenses at Destination.
Process-wise, user will enter at header level in the sales document the expenses, and systems prorates (as per standard) in the items according to each item's Gross Weight. Afterwards, once order is complete user proceed to bill a pro-form invoice that will be sent to customer for approval (billing type ZF5, copy of standard billing F5).
Customer replies approving, and sometimes rejecting some of the items. User adjusts the sales order adding reasons for rejection in the items (as you know, in standard SAP when there are already subsequent documents, items cannot be deleted; only rejected).
CASE
Recently a power-user has reported that system is prorating the additional expenses into items that had been previously marked "rejected" with any given “reason for rejection" (VBAP-ABGRU). Functionally speaking, the user is correct to mark the item rejected when they will no longer be sold in order to stop it from pulling requirements in MRP, and avoid incorrect delivery and billing.
Although the item is no longer needed, the freight has already been negotiated so it will be charged at the same amount; however, the particular item that was rejected will not be billed anymore thus also losing the particular amount of International Freight that had been prorated from the header into all the items.
CASE REPRODUCTION
Create an exports sales order, added customer, items and delivery dates. Automatic pricing executed.
Navigate to header > Conditions
Proceed to fill-in the International Freight amount, in header manual condition ZFIN.
Verify the rejected item (item 10), and system did prorate the portion of ZFIN corresponding to such item, which is not desired outcome for a rejected item.
Has anyone customized in such a way that standard would ignore rejected items during pro-rating function?
WORKAROUND
We have given the following workaround to business, while we research for a better solution. Ideally, in order to keep metrics on items that have not been sold, business would prefer to have the data clean, untouched, which is something the workarounds do not deliver.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks Arun! this was the solution, the item is no longer receiving prorate of the manual header condition!
I'm herein adding a snapshot of the issue resolution for future reference of other fellow SCNers . As you can see, Condition Value is now "0" thanks to the statistical value configuration via Custmizing Acvitity SIMG_CFMENUOLSDOVAG
When the order item is not delivered and is not expected to be delivered - can't you simply use a rejection reason with statistical values <> ' ' instead of deleting the item?
The users may need different reasons for reporting purposes - rejected by the customer and not delivered by the supplier.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
108 | |
12 | |
11 | |
6 | |
5 | |
4 | |
3 | |
3 | |
3 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.