BAPI_EXCHANGERATE_CREATE : exch_rate rounds off

Hi All,
I have written a program to upload exchange rates from flat file and store them in OBO8.
I have used FM
BAPI_EXCHANGERATE_CREATE
for uploading the rates.
My issue is when i try to upload 188.39 (HUF/USD) it gets rounded up i.e. 1/188.39000 = 0.00530813 gets as 0.53100 as system multilpies it by 100 for HUF.
The reason behind this is field exch_rate in structure bapi1093_0 is of length 9 and decimal 5.
I tried to copy the FM ,structure and change the length but it has lots of standard includes and FM so i get many errors.
Is there any other way round to achieve this?
Thanks,
M Mishra
Edited by: Mishra.Manas on Mar 18, 2010 6:44 AM

Hi Manas,
before calling that bapi u can call this bapi BAPI_CURRENCY_CONV_TO_EXTERNAL for your required conversion.
regards Nitin.

Similar Messages

Issue in MODVAT Clearing Account and Rounding off of Excise.

I have one issue in MODVAT Clearing Account and Rounding off of Excise.
Example:
Material cost    100Rs.
Excise value
1. BED             10.5 Rs
2. ECes             2.1 Rs
3. HEces          1.3.Rs
At the time of GR
Material Ac Dr          100
     To GR/IR                        100
At the time of Excise Capture
We done the rounding of Excise value
RG23 A BED         11
RG23 A Eces          2
RG23 A HEces        1
   To MODVAT            14
At the time of IR . System create IR with reference of PO
GR/IR DR      100
MODVAT         13.9
    To Vendor         113.9
So here you can see that there is a difference of 0.1 in MODVAT account and hence we are crediting Vendor with the lesser amount here with 0.1 RS.
So we cannot reconcile the MODVAT Account
Less Payment to vendor by 0.1 Rs
So is there any solutions on that.
regards
Shayam
Edited by: Shayam_210 on Jan 3, 2011 7:08 AM
Edited by: Shayam_210 on Jan 3, 2011 7:09 AM

Hi,
Check the rounding setting in below:-
SPRO > Logistics - General > Tax on Goods Movements > India > Basic Settings > Maintain Company Code Settings
SPRO > General Settings > Currencies > Define rounding rules for currencies
Regards,
Gaurav

MIRO- excise and VAT duties Rounding off

Hi all,
A PO will have 20 items. Those 10 items will have excise duties and VAT amount. At the time of PO these excise duties and the VAT amount should not get rounded off. But while the user is doing MIRO, the value of these excise duties and the VAT amount should come to the screen as rounded off. Is it possible? If yes please suggest me.
I am Using TAXINN procedure

Hi girish,
We can Bring condition Round Down and Up but we can't do as you said.See some User Exists are available .
BR
Raj

Round off error?

Hi,
I'm playing a little bit with the trial version of Numbers, just to see if my good old Ti is still capable to run it properly before buying a full license of iWorks.
By the way, it seems like there's some kind of round-off error. Try to build a series as follows: enter -10 in to a cell, then let Numbers build the series using the usual formula "previous cell value - 0.1". Apply a format so that only two decimal values are visible. Drag the formula and build twenty values (just to have some values). Now use the previous series and calculate its squared values. Then select some cells in the squared values column, starting from the first one: as soon as you include the squared value of -9.3 in the selection you will see that the data inspector will show a min value equal to 86.4900000000001 , which should be the squared value of +/- 9.3.
Now, try to subtract 86.49 to that cell and you will see that the result is not exactly zero: you can try to calculate the inverse of it and, instead of an error, you get a very big (actually, not that big!) number.
You can easily reproduce this weird behavior if you open Calculator and calculate the squared value of 9.3: until you set the precision up to 14, you get the correct value, you select precision >= 15, you get the round off value.
So, it seems it is not a Numbers only related problem.
Just for the record, I've just calculated the same value into Octave, and the result is correct (and different):
86.4900000000000 (Octave)
86.4900000000001 (Numbers)
Yet not so serious, this kind of "numerical noise" might lead to annoying issues...

HI SIR,
WE CREATED ONE PO .IN THAT PO ITEM NO2 SHOWING NET VALUE AS 11.63 FOR MATERIAL CS PLATE WHER AS ITEM NO 5 SHOWING NET VALUE AS 11.62 FOR SAME MATERIAL AND SAME PRICING CONDITIONS.
Hi ,
Please check in item conditions whether have you entered discount conditions in line itenm 5.
Regards,
Vijay

Rounding off to a variable value to 4 decimal values in sap script ouput

Hi All,
I have a value getting displayed in sap script output as 235.6789 i want to Round off this variable value to 4 decimal values!
What is the formatting option need to be used & how!
Thanks in advance.
Thanks,
Deep.

Hi,
1.In layout just call that variable, where you need like:
&variable(.4)&.
Just see these:
&symbol(Z)& Omit Leading Zeros
&symbol(S)& Omit Leading Sign
&symbol(<)& Display Leading Sign to the Left
&symbol(>)& Display Leading Sign to the Right
&symbol(C)& Compress Spaces
&symbol(.N)& Display upto N decimal places
&symbol(T)& Omit thousands separator
&symbol(R)& Right justified
&symbol(I)& Suppress output of the initial value
Regards,
If helpful reward with points(Don't forget).

Rounding off value problem in sales order

Hi All,
This is related to a rounding off value problem in sales order.
The problem is described by an example which is as follows -
Selling Price of Material A = Rs. 176.76
Excise charged = Rs. 21.80
Total Price = Rs.176.76 + Rs.21.80 = Rs. 198.56
On this total Trade Discount (ZDTD) having access sequence,is calculated at the rate of 4% = Rs. 7.94
But the condition base value after the discount is showing Rs.198.60 instead of Rs.198.56
I want the system to reflect the value as Rs.198.56 intact and it should not round up to the nearest value i.e. Rs. 198.60
Why is this happening? Is it possible to reflect the exact value? If yes what is needed to be done?
The commercial round off is activated for the DIFF Condition Type.
Looking forward to some valuable suggestions.
Thanks & Regards
Priyanka Mitra

Hi Ramesh,
Thanks for your suggestion but the problem has been solved by me.
Regards
Priyanka Mitra

How to round off quantity in inventory

Hi,
How to avoid decimal places for PC(Piece) in the goods movement transactions.. I have given 0 decimal places in CUNI transaction. It is working properly for Production Order during Conrimation but it is not working in Inventory transactions like MIGO, MB1C,MB1A....
for example When I enter Unint of entry In Alternate Unit say '10 KG' System Automatically Caliculates quantity in base unit in decimal places say 115.012 PC based on the conversion factor defined in material master.
My requiremet is the base unit quantity PC rounded off to nearest value in as 115 (PC).
The same thing is working fine for production order.
please suggest me how to do.
Thanks,
Shekar

this all depends on your conversion rate enterd in material master.
if 115.012 PC equals 10 KG.
what do you actually want the system to do,
it would now that you would get 115.012
you want it to be 115,
this would then mean that you have to modify the entered quantity from 10 to 9something
Is it that what oyu want?
you certainly cannot have 115 PC and 10 KG if you dont change the conversion rate in your material master

Need rounding off value for partial Goods receipt

Hi,
My requirement is that the PO value,PO tax value ,GR value and Invoice value(IR) should get rounded off.
When I am using the PO value which is rounded off in PO, but at the time of posting partial goods receipt the value for the GR/IR clearing or the stock value is not getting rounded off for these G/ls.
What should I do for this to get the rounded off values in GR.
Regards,
Goraksh

Hi Goraksh,
The problem is that the pricing (incl. the rule 17) is not normally called at the time of GR. As Jürgen wrote, the system just uses the "net value" field of the PO.
I have however a "wild" idea. If the price in the PO comes from the info record or from a contract (and not changed manually there), then you can set the "pricing date category" = 5 there, meaning "GR date". This causes the pricing to be called again at the time of GR and your formula 17 will fire.
The side effect of course is that the price that you had in the PO, printed and sent to the vendor will not be binding: if you change the PIR price before the GR, the GR will be posted to the new PIR price, despite the fact that the PO printout showed something else. So the question is if the price printed on the PO is indeed binding in your business case - in many business cases it is the current vendor price that matters for the billing by the vendor, not the one that you prined on the PO. For such business cases you should have had pricing date category 5 anyway...
BR
Raf

Unit of measure - rounding off during creation of planned order

Dear All,
We have defined one material OIL in MM41 and its UoM is EA also we have put alternative UoM is L(liter).
now we create BOM of semifinished material we use this oil as a component and enter its value in decimal points.
e.g 0.375 EA
During planned order creation or REM backflush system convert this quantity to 1 EA ,WE dont want this automatic conversion .
We have uploaded all master data in production and now it is very difficult to change all BOM
So what is the solution of this that system can not convert qty (rounding off).EA
Kindly reply
Sunil

Hi Sunil,
IN CUNI Transaction Field Decimal Places is for displaying the decimals,there is a decimal place Rounding off field below,there try to maintain 3 decimals and check whether it is working.
One more thing is Unit EA will be used always as non decimal unit,But i dont know in your buisness how for unit EA there is a decimal qty
Edited by: Girish Adaviswamy on Mar 2, 2010 10:59 AM

PR to PO quantity rounding off

Hi Team
I am facing a peculiar error when i am trying to create the PO with respect to PR
I have created the PR for 1.130(one point one three zero) TO(tonnes). Now when i am creating the PO wrt to this PR then the PO quantity is coming as 2.000(1.130 is rounded off to 2.000)
now the system is populating ERROR as - Materials of requisition 10000012 item 00010 alr. ordered in full
Message no. 06076
If i change the PO quantity manually to 1.130 then the error will vanish off.
Please let me know how to get the same quantity(without rounding off) from PR to PO during PO creation wrt PR
Thanking you in advance
Regards
Shuban

Hi,
This just because of rounding value maintained for the material in the MRP1 view either 1000 or 2000 which results in creating PO of 2000 even though the PR has created requirement of 1.130 assume if your requirement is under 1000 then still when your creating PO it would create for 1000 because of rounding value of 1000 maintained.
If you donu2019t want this rounding value then remove it from Material Master, MRP-1view. Then the system will consider the order quantity from the purchase requisition during MRP run and same will flow in the purchase order. Hope this helps you.

Paisa Round Off - GL Account for Warehouse wise

Dear All,
Please guide me how to configure the Paisa Round Off - GL Account determination for Warehouse wise
( for Different Warehouse ).
Thanks in Advance.
- Rajesh

Check these link which explains Rounding in B1
[https://websmp201.sap-ag.de/~sapidb/011000358700000243182007E/CW12_Learn_about_Rounding.wrf]
[https://websmp201.sap-ag.de/~sapidb/011000358700000243172007E/CW12_Learn_about_Rounding.pdf]

Using round off function in where clause

Hi All,
I'm trying to use round off function in where clause, I seek help in completing this script.
WITH CR_Details AS
(Select
request_id,
parent_request_id,
fcpt.user_concurrent_program_name Request_Name, phase_code, status_code,
round((fcr.actual_completion_date - fcr.actual_start_date),3) * 24 * 60 as Run_Time,
round(avg(round(to_number(actual_start_date - fcr.requested_start_date),3) * 1440),2) wait_time,
fu.User_Name Requestor,
fcr.argument_text parameters,
to_char (fcr.requested_start_date, 'MM/DD HH24:mi:SS') requested_start,
to_char(actual_start_date, 'MM/DD/YY HH24:mi:SS') ACT_START,
to_char(actual_completion_date, 'MM/DD/YY HH24:mi:SS') ACT_COMP,
fcr.completion_text
From
apps.fnd_concurrent_requests fcr,
apps.fnd_concurrent_programs fcp,
apps.fnd_concurrent_programs_tl fcpt,
apps.fnd_user fu
Where 1=1
and fcr.concurrent_program_id = fcp.concurrent_program_id
and fcp.concurrent_program_id = fcpt.concurrent_program_id
and fcr.program_application_id = fcp.application_id
and fcp.application_id = fcpt.application_id
and fcr.requested_by = fu.user_id
and fcpt.language = 'US'
and fcr.actual_start_date like sysdate )
     select crd.*
     from CR_Details crd
     where Run_time <> '0'
     AND wait_time <> '0'
GROUP BY
crd.request_id,
crd.parent_request_id,
crd.fcpt.user_concurrent_program_name,
crd.requested_start_date,
crd.User_Name,
crd.argument_text,
crd.actual_completion_date,
crd.actual_start_date,
crd.phase_code,
crd.status_code,
crd.resubmit_interval,
crd.completion_text,
crd.resubmit_interval,
crd.resubmit_interval_unit_code,
crd.description
Not sure about the GROUPBY function referencing the "crd." .

Hi,
The best thing for you to do is start over. Start as small as possible, then take baby steps.
Pick one of the tables; fcr perhaps, and write a query that just uses that table, like this:
SELECT    *
FROM       apps.fnd_concurrent_requests     fcr
WHERE       fcr.actual_start_date          >= TRUNC (SYSDATE)
AND       fcr.actual_start_dt          < TRUNC (SYSDATE) + 1
;(I think this is what you meant to do when you said "... LIKE SYSDATE".)
Make sure this little query gets credible results. When that tiny query is working perfectly, add another line or two. You can cut and paste code from what you posted, if that helps you.
If you get stuck, post the last version of your code that worked perfectly, and the latest version (only a line or two bigger) that has the problem. Describe what the problem is. If you get an error, post the complete error message. In any event, post CREATE TABLE and INSERT statements for all the tables and columns needed to run the query, and the results you want to get from that query.
When you post any code, format it, so that how the code looks on the screen gives some clues about how it is working.
When you post any formatted text on this site, type these 6 characters:
\(small letters only, inside curly brackets) before and after each section of formatted text, to preserve spacing.
If you going to use the AVG function in the sub-query, then you probably need to do a GROUP BY in the sub-query.
If you're not using any aggregate functions (like AVG) in the main query, then you probably don't want to do a GROUP BY in the main query.
I know this is a lot of work. I'm sorry. If there was an easier way, I wouldn't ask you to do all this.

Problem in VAT Round off during MIRO

Hi Friends,
I having problem in VAT round off during MIRO. We have created PO with excise +VAT. VAT amount has been rounded off. After GRN, we are trying to post the Invoice in MIRO, the VAT amount shows with Decimal.
We are using TAXINN, in the tax pricing proceedure i have mede 17 for call type for VAT condition type. in OB90 we have mede the rounding rule as 100 for currency INR.
When i create the FI direct invoice using the same Tax code it works fine, but having problem in MIRO. I want the decimal should be rounded to the nearest value.
Can any one help me is there any standard set up where we can arrive this?? OR is it required any user exit??
Regards,
Deva

Check whether you can use the user exit function module KR_USER_EXIT_ROUNDOFF
Regards,
SDNer

Rounding off differences for Vendor and Customer payment

Dear All,
Rounding off differences for vendor payment in T Code F-53 is giving the following error when I want to post.
Item category 06000 not allowed in accounting transaction 1000/0001
Message no. GLT2001
Diagnosis
The online document splitting is active in your system. Here, each document is assigned to a accounting transaction variant and each document row to an item category.
You determine for each business transaction variant which item categories can or must be posted here.
The following error occurred for the document you entered:
Item category 06000 in accounting transaction 1000, variant 0001 is not allowed.
System Response
The document cannot be posted.
Procedure
Check the document entered, the derivation of the business transaction variant, the derivation of the item category, and the assignment of the item categories to the business transaction variant.
Please advice
Regards
BIJUDAS

Thx for the quick answer Andreas. n further discussions we found that the actual requirement is to only have the payment history data for both the vendor and the customer only as a referece. I mean they dont want to have the actual accounts posted for historical data, since we have to anyway have a conversion for the GL accounts related data afterwards.
I hope i cleared what we want here. Do we have any way we can update the data in this case. Is there anyway we can have data stored in LIS possibly for such cases..
Any ideas

IN Po quantity is getting round off - when we create PO through BAPI?

Hi all,
In PO quantity is getting round off instead of 5711.210 it is taking 5711 only. Here we are creating the PO's through BAPI automatically.
and in excel sheet we have maintained 5711.210, Kindly let me know what may be the possible causes for this..
regards,
archana

fyi
change decimal places in PO quantity

BAPI_EXCHANGERATE_CREATE : exch_rate rounds off

Similar Messages

Maybe you are looking for