F&A Pricing Rounding
I have an issue related with the F&A pricing. I need to have gross price value to be rounded up to 4 decimal only , for which I have selected the correct rounding rule but still in the PO , value is coming as 6 decimal places. Can any body tell me what could be the reason and what need to be done?
Dipak Kadam
Hello Dipak,
Please ensure that you are seleceting the correct rounding rules for the field "term rounding rule" and "Currency rounding rule". Also ensure that you have selected the rate based Indicator tick mark in the formula. One more thing to ensure that you select the correct currency symbol for which no of decimal palces are allowed as expected by you.
Hope this will work. Let me know if you need any more info.
thanks,
Ritesh
Edited by: attarde2009 on Mar 28, 2010 3:26 PM
Similar Messages
-
Sales Order Discount Pricing Rounding Error
When we use discount RA01 in our Sales Pricing / Orders it results in rounding issue that shows on Customer Invoice.
eg: Sales Order Conditions Tab
Product XXXX x 2 EACH
CnTy Amount (per ea)
PR00 $141.55 EA
RA01 10%
$14.16
Net Val $127.40EA
Total Condition Value (x Order qty)
PR00 $283.10
RA01 $28.31
Net Val $254.79
So what the Customer sees is the unit price of $127.40 and totol line cost of $254.79.
But $127.40 x 2 is obviously $254.80
It looks as though the discount is being calculated as 14.155, then the Net Value rounding from $127.395 to $127.40
Where as the TOTAL Net Value for the line is showing the $127.395 x 2 = $254.79.
How do we get this scenario to result in the Net Value Amount, and Net Value Condition Value multiplying correctly by Qty on the Order??
Thanks
Hayley McDougalHi Thenmozhi
Sorry for confusion, I am responding to your question above using a new Public logon, as the logon i used to raise this question has been locked, and SAP advise may take a few days to rectify. But I am hoping I can sort this issue ASAP.
The Requirements indicator for PR00 and RA01 is 2
The Calculation Type is PR00 = C (qty) and RA01 = A (%)
The Net Price, PR00 and RA01 are all set to Rounding = Commercial.
Thanks -
Pricing Rounding Issue.
Hi Team,
I want to round my Amount and condition value to Integer level(Remove decimal and following two values)
E.g. my PR00 has value 110 for quantity 11 so my condition value will be 110*11 =1210. If i want to apply 1.9% discount on this using condition type ZXXX it would calculate it as 22.99. I want this value to be rounded off to 23 or 22 hence removing the last two digits on the right of decimal.
Also since SAP calculates % on the condition value as in above case it calculates 1.9 % on 1210, I have a requirement where 1.9% should be calculated on amount per unit in this case on 110 and then multiply it with the qty.
I hope I am clear with my explanation, and in case you need further infi, pls let me know.
Regards,
AnupamHi,
Check these notes,
Note 80183 - Rounding
Note 315792 - Group conditions of the same amount on item
Note 166952 - Rounding when distributing header conditions
I hope this helps you,
Regards,
Eduardo -
Pricing Conditions Rounding Issue
Currently, our system has two pricing condition types. ZP,ZD. The ZP conditions represent a base price and the ZD represent a differential(- discount or + surcharge). Both are based on the same hierarchy. ZP00,ZP01,ZP02.ZP03,ZP04. A ZP01 overrides a ZP00 and ZP03 overrides ZP00, ZP01,ZP02 and so on and so forth. All transactions are settled in USD. However, most of the time the ZP, ZDs are based on prices that extend out more than two decimal places. I am experiencing and issue because SAP calculates the ZP and ZD separately and is rounding each. For example the ZP or base price in this case is $2.245. This times quantity of 3,999Gal = $8,977.755. SAP rounds this to $8,977.76. SAP then calcs. the differential ZD $.0235X3,999Gal = $93.9765. SAP rounds to $93.98. This is a total price of $8,977.76+$93.98 =$9,071.74. However the unit price is ZP $2.245 + ZD $0.0235 = $2.2685. If you take this price multiplied by the quantity $2.2685 X 3,999Gal = $9,071.7315. So the actual total price is off by 1ct because SAP treats the ZP and ZD as two separate calculations. I have seen various ideas on how to fix, from creating another pricing condition, to user exits. I was wondering if there was a preferred method? Or if there is a simpler solution?
Good Evening,
1. Please review OSS NOTE 80183 regarding Rounding.
Values calculated in pricing are always rounded to the amount of
decimal places which the used document currency owns. As subsequent
processing steps setup on this rounded value rounding differences can
occur in the calculation of the price per unit or in subtotal line.
To bypass such effects note 80183 describes possible solutions to
reduce / bypass this effect.
A few problems in rounding after applying note 80183, variant 2 have
been recorded where it was recommended to use the formulas 919 and
920 on all discounts and surcharges that appear before NETP and the
problem was solved.
2. In transaction V/06 there is a field under header 'Control data1'
which can effect how the system rounds off condition values during
pricing:
->> Rounding rule
The rule that determines how the system rounds off condition
values during pricing. The last digit will be rounded.
Example
o In the standard rounding rule '_', values are rounded off according
to business standards:
10.454 -> 10.45 DEM
10.455 -> 10.46 DEM
o In rounding rule 'A', values are always rounded up:
10.459 -> 10.46 DEM
10.451 -> 10.46 DEM
o In rounding rule 'B', values are always rounded down:
1045.9 -> 1045 LIT
1045.1 -> 1045 LIT
In this example, the currency of the condition rate is Italian Lira.
The Italian Lira does not have any places after the point.
3. Also check if the condition type is set as item condition as well
as group condition in transaction V/06. What this means is that
the system will calculate the value of the condition on header level
and compares it with the sum of item values in the document.
Any rounding difference (KONV-KDIFF) detected, will be populated
in the line item with greatest value or in first line item if all are
of equal value.
In other cases where there is no adjustment because there is no
rounding difference when comparing the header value and the sum of
item values.
->> Solution to this scenario -
If you remove the 'group condition' setting, the system will then
calculate amount for the items directly and you will not get the
rounding. You must decide which setting is more suited for your
business. This is not a bug, but works as per designed.
EXAMPLE: MWST - tax condition (a group condition)
Item 10 16% of 100.90 = 16.14
Item 20 16% of 100.90 = 16.14
Total = 32.28
I hope this helps you!
Kind Regards,
Martina McElwain
SD Forum Moderator -
Rounding condtion type decimals
HI ALL,
I have a requirement where for eg: Condition type PR00 is with 50.45 it should round off to 50.00
or if it is 50.95 also inthat case also it should round off to 50.00
i tried doing rounding rule in conditon type, it is only rounding the decimals
i dont want any decimals
Please let me knw if any one has the answer
SyedHello,
In transaction V/06 there is a field under header 'Control data1' which can effect how the system rounds off condition values during pricing:
->> Rounding rule
The rule that determines how the system rounds off condition
values during pricing. The last digit will be rounded.
Example
o In the standard rounding rule '_', values are rounded off according
to business standards:
10.454 -> 10.45 DEM
10.455 -> 10.46 DEM
o In rounding rule 'A', values are always rounded up:
10.459 -> 10.46 DEM
10.451 -> 10.46 DEM
o In rounding rule 'B', values are always rounded down:
1045.9 -> 1045 LIT
1045.1 -> 1045 LIT
Please try using the rounding rule 'B' for your scenario.
I hope you find this information very helpful and hopefully it will solve your problem.
Regards,
Martina McElwain
SD - Forum Moderator -
Problem of DIFF (Rounding Off) Condition Type in Sales Pricing Procedure
Hi All,
This problem is related to Sales Order. The system is not picking up a condition type in the pricing procedure.
For example when I am raising a sales Order where the Trade Price is being calculated with the help of a Alternative Calculation Type , Subtotal 1 , X in the the Print column and Posting Key ERL are assigned to it.Here in the end the condition type DIFF is not getting populated in the pricing though it is maintained in the pricing procedure. When I am checking in the pricing analysis the error message and its detailed description which is shown as follows -
DIFF 011 Condition ignored (requirement 013 not fulfilled)
The requirement 1. was assigned to this condition in the pricing procedure. This requirement was not met in the preliminary condition step, and so the condition was excluded from further processing.
You can use Additional information to display the requirements used.
Now considering the above scenario please suggest to attain my requirement.
Thanks & Regards
PriyankaDear Priyanka,
The "reqt" field in the pricing procedure basically tells d system that the routine mentioned in this field is a sort of prerequisite without fullfilling of which the associated condition type will not get xecuted.
In ur case u have selected "1" which is for condition types A001, B001 etc used in "material listing / xclusion" function.
For condition type DIFF, the correct value is "13" i.e "Rounding as per T001R".
So just replace "1" with "13", things will b fine.
Please close the thread if answered.
regards
Param -
Regarding rounding off value in pricing procedure
hi fi professionals,
i have an issue regarding pricing procedure, pls help me out, its urgent
i have a condition type, zrou(rounding off value)
the fanda is- when i am creating po- my net value is suppose- 19.90.
so my client requirement is- 0.10
so i have given 0.10, then total value is- 20.00
but this value is not pickin up in migo- accounting document
it is picking 19.90 only.
so what is the configuraion needed in omsy for picking up the total value in accounting doc.
regards,
susantaHi..
You would need to maintain a account key in the pricing procudure which would calculate the balance to make the total a rounded value.
In FI perspective, you need to assign a GL account for that..
Cheers
Raghu -
Condition rounding error in pricing of sales order
Hi all,
I have a problem on rounding of condition type MWST in a sales order.
I have the PR00 condition evaluated with 6,50 euro for 1 piece; on this price should be applied condition type MWST with a percentage of 10%.
The result should be 0,65 euro but the system shows (and calculates) 0,64 euro for MWST.
How can I solve this rounding problem?
Thanks in advance for your helpful answers.
AlessandraHi,
Check if you are using VOFM subroutines in your pricing procedure (V/08) or in the condition type (V/06) for rounding rules.
Check too this notes and related notes in them (surely, they will help you)
Note 80183 - Rounding
Note 315792 - Group conditions of the same amount on item
Note 166952 - Rounding when distributing header conditions
Note 517829 - Source code f new dstrbtn rule 'roundng diffrnce comparison'
I hope this helps you
Regards,
Eduardo -
Hi All,
We have one issue for Russia in Pricing
We have one condition type for Base price and the value is 515.30 $ and
Surcharge is 15% o the Base price which willl be 515.30*15/100 which equals to 77.295
The total is Baseprice + Surchage which was calculated as 515.30+77.295 = 592.595 ( but rounded as 592.60) which is showing a difference
If customer orders for 10 parts, then there will be 2 $ variace between the amount calclated and showed in SAP
Can you please let me know why this is displayed with rounding , is this standard behavious and if so, where was it controled.
thanks
santoshI dont think this will be treated as an issue by the client. It is general that in exports, there will always be some difference in decimals. Considering all these things only, client would have arrived at their selling price. If I am correct, this would be addressed by having a separate G/L account for Gain or Loss in foreign exchange.
Check one such thread where a similar topic was discussed some time back.
[Re: Exports|Re: Exports]
May be you can check with your FI counter part also on this.
thanks
G. Lakshmipathi -
Rounding In Cash Sales Pricing
hi,
I have the following problem:
We have a pricing procedure used for normal sales which should have no rounding on it, but the same pricing procedure is used for cash sales which must be rounded down to the nearest 5c.
Any idea how to get this to work only for cash sales order type, without affecting other order types.Since in your case, the same pricing procedure is used for all the sale order types, you can try with any of the following sale order user exits
User exits in the program MV45AFZZ - USEREXIT_READ_DOCUMENT or
User-Exits in program MV45AFZB - USEREXIT_CHECK_VBAP
where you can have a logic on sale order type such that the rounding down should work only for the cash sale order type. Tell this logic to your ABAPer and ask him / her to try with any of the above user exits.
thanks
G. Lakshmipathi -
Price Rounding Issue - AFS Pricing
Hello Friends,
We are facing an issue in sales order pricing & its subsequent effect in invoice. We use AFS pricing, where different grid sizes have its basic price.
We have a basic price condition which come thru a master record, and this can be overridden by a manual price condition.
When such manual condition is entered, it applies to all the quantity of the line item irrespective of the number of grid sizes.
So suppose I had 6 grid sizes in the line item (which also results into 6 schedule lines) list price will be shown across all the grid sizes, see DOC1
But when I enter a manual price EUR 7, it applies to the total quantity that is 6. So the net value in this case will be EUR 7, See DOC2
By calculation, 7/6 = 1.166666666666667
So when now I create the invoice, the value gets rounded for all the grid sizes & it becomes 1.17
Here when system calculate the net value it will sum up 1.17, six times & the resultant net value is EUR 7.02, see DOC3
As a result most of the time there is difference between the order value & the invoice value.
Please suggest what action should be taken.
Regards,
Dhananjay BorateDear Dhananjay Borate,
You can avoid this issue working this the following options:
Every Condition Type, in the "Control Data Box 1" have the option to apply a "Rouding Rule" with three different options:
Empty.
In the standard rounding rule '_', values are rounded off according to business standards:
10.454 -> 10.45 DEM
10.455 -> 10.46 DEM
"A"
In rounding rule 'A', values are always rounded up:
10.459 -> 10.46 DEM
10.451 -> 10.46 DEM
"B"
In rounding rule 'B', values are always rounded down:
1045.9 -> 1045 LIT
1045.1 -> 1045 LIT
Also you can use, in the "Gruop Condition ", the Rounding difference comparison.
Indicator that controls whether rounding difference is settled for group conditions with a group key routine. If the indicator is set, the system compares the condition value at header level with the total of the condition values at item level. The difference is then added to the largest item.
Use the Conditons Types:
PDIF - Diff.value (own)
DIFF - Rounding Offwith the Conditions that apply to your needs. The standard gives this ones as examples: [Requirement: Routine 13 - Rounding as perT001R], [Condition Formula 16] and [Basis Type 4]
Regards,
Johnattan. -
HI,
system is showing different condition values(condition type PNTP) in sales order and Invoice..
Eg. material cost in Material master is 16.59 $ per 1000 PCS
here our ordering quantity is 10,000 pcs
in sales order it is taking amount as 16.59 per 1000 pcs and for 10,000 condition value is 165.90 $
but in invoice it is taking amount as 0.02 per 1 pc ( rounding the 16.59 to 1 pc i.e 16.59/1000 = 0.01659 = 0.02) and hence for 10,000 qunatity it is showing condition value as 0.02*10,000 = 200 $
here i am getting around 30$ different.. can you please help me in solving this issue...
are there any SAP notes available for this?
thanks,
sudhirHi,
Go to VK11 and save the condition record as 0.01659 for your condition type.
Or save the condition record as 16.59 per 1000.
Then go to V/08 and select your pricing procedure.
Over there remove the rounding of the condition type.
Also go to V/06 select your condition type and go to detail.
Over there just remove the rounding rule.
Now try to create the sales order and check the pricing.
One question do you want rounding should be done in the last of the pricing?
Regards
Raj.
Edited by: Raj Aryan Malhotra on Jul 16, 2009 1:25 PM -
Hi All,
I have a requirement from finance. In the net amount the Decimel places should be rounded off so that the decimel is always Zero.
eg. if the Net Amount is 50.14 = 50.00
eg. if the Net Amount is 50.19 = 50.00
eg. if the Net Amount is 50.65 = 51.00
Do we have a standard routine for this. If no can you please help how the routine will look like for the above scenario.
Regards,
RajneeshThank you.
I maintained the entry in T001R.
However in Maintain Pricing Procedure i do not see the Routine 13 as seen in vofm.
In Cal Type i see routine 13 named as 'Minimum ValueSurchrg' and Routine 17 as 'Rounding as perT001R' with a different functionality as below
Round the amount according to T001R
form frm_kondi_wert_017.
check: rekursiv ne 'A'.
check: t001r-reinh ne 0.
xkwert = xkwert * ( 1000 / t001r-reinh ) / 1000 * t001r-reinh.
endform.
Any clue friends -
Rounding Issue with Pricing Conditions
Currently we have in place a pricing hierchery that consists of two pricing conditions. ZP for base price and ZD for a +-differential. Both conditions begin with 00. ZP00. ZP01, ZP03, ZP04. If a ZP01 exists it overrides a ZP00. If a ZP03 exists it overrides ZP00,ZP01, etc. So basically the higher the number means it overrides anything underneath it. The ZD conditions are setup exactly the same way. I am currently running into a round issue. We settle all transactions in USD however the manual and differentials are often based on prices that go out more than 2 decimal places. SAP is treating the calculation for the ZP and ZD as two separate calculations. It rounds each of them and then combines for a total price. So if the base price ZP02 is $2.245 multiplied by quantity 3,999 = $8,977.755 which it rounds to $8,977.76 and the differential ZD02 is $.0235 this = $93.9765 which it rounds to $93.98 for a total price of $9,071.74. However if you add the ZD02 + the ZD02 you get a total unit price of $2.2685. This multiplied times the quantity 3,999 = $9,071.731 which is correct. But because SAP does each calc separately the price comes out to $9,071.74 or off 1CT. I have seen various solutions on how to fix this from user exits to creating additional conditions that takes both ZP and ZD conditions and calculates them as one but I was hoping someone had come up with something better? Or if there was a preferred method?
Currently we have in place a pricing hierchery that consists of two pricing conditions. ZP for base price and ZD for a +-differential. Both conditions begin with 00. ZP00. ZP01, ZP03, ZP04. If a ZP01 exists it overrides a ZP00. If a ZP03 exists it overrides ZP00,ZP01, etc. So basically the higher the number means it overrides anything underneath it. The ZD conditions are setup exactly the same way. I am currently running into a round issue. We settle all transactions in USD however the manual and differentials are often based on prices that go out more than 2 decimal places. SAP is treating the calculation for the ZP and ZD as two separate calculations. It rounds each of them and then combines for a total price. So if the base price ZP02 is $2.245 multiplied by quantity 3,999 = $8,977.755 which it rounds to $8,977.76 and the differential ZD02 is $.0235 this = $93.9765 which it rounds to $93.98 for a total price of $9,071.74. However if you add the ZD02 + the ZD02 you get a total unit price of $2.2685. This multiplied times the quantity 3,999 = $9,071.731 which is correct. But because SAP does each calc separately the price comes out to $9,071.74 or off 1CT. I have seen various solutions on how to fix this from user exits to creating additional conditions that takes both ZP and ZD conditions and calculates them as one but I was hoping someone had come up with something better? Or if there was a preferred method?
-
SD -Pricing issue with rounding
Hi All,
We have a price condition in sales order, in which the base codition is USD4 and conditon base value is in USD. System is not giving proper values after rounding. Please see the below example.
Base proce = 2.845 USD4 per PC
Qty = 1
Condition base value = 2.845 * 1 = 2.85 USD
Base proce = 2.345 USD4 per PC
Qty = 1
Condition base value = 2.345 * 1 = 2.34 USD
Base proce = 2.245 USD4 per PC
Qty = 1
Condition base value = 2.845 * 1 = 2.25 USD
If you observe in second case it is not rounded properly. I couldn't understand why it is calculating like this. The value is returning from standard converting currency function module.
Please advice me.
Thanks,
Kiran.Check in IMG > Logistics General whether for your Company Code, check box for rounding duty is ticked. If so and still you have issue, have a look at the following notes:-
Note 117891 - Rounding off not happening
Note 1005838 - Rounding of duties when get excise invoice is used in J1IIN
G. Lakshmipathi
Maybe you are looking for
-
ITunes will not recognize my iPod, but windoes DOES.
When i plug my 30gig iPod into my pc via usb, windows recognizes it, and it even prompts iTunes to pop up. After this however, nothing happens. I cannot get iTunes to recognize my iPod, therefore cannot update it. I have tried all of the steps on the
-
Cisco prime 4.2 monitor SFP conn & isdn active call session
Hello all, my customer already bought cisco prime 4.2 , they asked me if this cisco prime is able to monitor the SFP (fiber connector) status active/not active and monitor the voice call active session for 24 hours ? anyone can help me to configure i
-
Sub-contracting with excise duty..?
Hi all can anybody explain me the sub-contracting process with excise duty , here we are going create excise invoice(J1IS instead of sub-contract challan) and what abt material document for sending out materials whether v an use excise invoice as mat
-
Menus pop up when typing the same word in Koteri
When I type Japanese words again and again, a menu pops up with the kanji that I've used previously. How do I select this word from the menu so I don't have to keep typing? I've clicked on the word, and it doesn't do any good.
-
SAML1.1 Assertion (Sender Vouches) policy
Hi, I am trying to write SAML1.1 Assertion (Sender Vouches) policy that will not be used over HTTPS and will not use the message signing and encryption (I do not want to use the standard policies Wssp1.2-2007-Saml1.1-SenderVouches-Https.xml and Wssp1