Problema with rounding

Hello!

I'm having a issue with the rounding of the JDE.
The JDE make a rounding in all the values of the fiscal notes, but some values end up getting some diference than that which the cliente sends to us. The diference is of cents, but it's a problem with the cliente and sometimes with the government.

Someone here know how to fix this?

Thanks.

Daniel,

Is this the same issue that you posted on 20th August?

You need to provide some detail - JDE Apps and TR versions; The application and/or UBE involved and the form/section and the event and the variable(s) etc. Please provide as much information as you can.

Also provide details about what you have done to find a solution and why this has not worked.

Hi Peter!

The JDE is 811, the TR 8.43.
The problem is in the invoice generation, but I think this can be up the requests.

The batch that we think that this problem exists is a customization of R76558B.

Do you have any solution for this problem? I was looking for the Tax Calculator function, but it's not there...

Daniel,

I still do not know what the problem is. Basically the detail that has been provided is:

[ QUOTE ]
some value or values, related in some way to invoices, possibly involving a customization of R76558B (and thus sales orders so the invoices are probably accounts receivable invoices), has incorrect rounding.

[/ QUOTE ]

Can you attach a screen print or PDF that shows the problem? How was the problem discovered in the first place?

I want to know which data items have the wrong rounding and what the wrong values are and what they should be.

Are the wrong values stored in a table? If so which table and which column?

Have you created a debug log of the process where the problem is occurring?

Peter,

The problem is the values of the invoice... All the values!
Basically, JDE make a rounding to the next lowest value, ex: 139,6996 becomes 139,69 but the client wants that the value becomes 139,70... Do you catch it?

This is not wrong, but the client wants that this value round for the next highest value...

I don't have any log or PDF now, sorry for this.

This problem is in all invoices issues by JDE... I am thinking that this can't be solved too easy... The problem is with the AEXP field that have only 2 decimals, I think, but we can't change it...

For example, the client wants that the round of JDE becomes equal to the round of excel: to the highest, not to the lowest.

Man, this is really hard to explain, further in english! lol

Daniel,

I appreciate that English is not an easy language for you and I thank you for the effort you have made.

I suspect that the problem is in the Sales Order module and not the Accounts Receivable module, as the item AEXP you mention is not a column in any of the Accounts Receivable tables, but is a column in the Sales Order tables.

I am not familiar with Sales Orders. But I suspect that you are correct in that this problem will not be easily solved.

Maybe another JDEList member familiar with Sales Orders may be able to provide further assistance.

Peter,

Yes, the problem really is in the Sales Order.

Thanks for your attention.

Now let's see if someone that know a little more of Sales Order can help me...

Thanks!

Hi Daniel - AEXP is the extended amount of the sales order detail line. In order to understand what might be happening we need to know a bit about how that is set up.

To start, how about getting us a the item, quantity, unit price, unit of measure as entered, and pricing unit of measure. If pricing UOM and UOM as entered are not the same then we need to see the unit of measure conversion table for that item. It will also be helpful to understand how your pricing is set up.

Basically - if your pricing UOM is not the same as your sales order UOM then the system does the math to adjust the quantities to the pricing UOM context. Sometimes this can lead to rounding errors in the calculations. These are not really errors but drift in the results caused by the number of decimal places.

I don't really know what is causing your particular problem, but if you can start to show us the way your items and pricing are set up then we might be able to get to the bottom of your issue.

Hi kylepyro!

The item in our system is 83007 (ITM), in one line of the invoice the quantity is 4, and in another is 1 (5 in total), the unity price is 27,99338... The sum maded by JDE results in 139,96 (139,9669), but the cliente wants that this value becomes 139,97...

Ola Daniel

ok - that is a start. I'm guessing that you have your invoice summarizing the two sales order detail lines together. Is that correct? If so, I might not be familiar with the area where your problem exists, but lets take a stab at it.

If I do the math on your figures 139.96 / 5 gives me a unit price of 27,992. 139.97 / 5 gives me a unit price of 27.994. If I take your unit price of 27.99338 and multiply by 5 I get 139.9669, which should round to 139.97.

However - if I calculate the lines on their own I get a different answer.

27.99338 X 4 = 111.97352 which will round to 111.97 in the extended amount field of the sales order detail line.

27.99338 X 1 = 27.99338 which will round to 27.99.

27.99 + 111.97 = 139.96 which is what you are seeing on your invoice.

My question is, do the two lines in the sales order contain those extended amounts. If so, then whatever business/system process is causing you to split that one item on the order is driving this problem. I'm guessing sales order and invoicing process are working as they ought to. You're simply getting caught by the number of times a rounding event occurs.

A second theory is that pricing unit of measure is causing the problem, but dig into this theory first before we go there. This idea fits the facts that you've given. A simple test will be to enter a sales order for 1 line of this item with 5 units and see what you get for a result on your invoice.

Deixe-nos saber - let us know
(faking it with google translate)

Hi Daniel

The problem is about making the tax calculation by line or by order total.

this is a setting that can be adjusted in P0022 fiscal rules

there you can adjust a setting for accounts receivable to calculate taxes at order level.

I also tested with this setting, and I can advance you, that at least on XE the R42565 and R42800 handle this right, but the R42810 will ignore this setting and make the report calculating at line level, so you can get differences, we solved this by creating our own custom version of the Sales diary

kylepyro,

I will make some tests in py and I'll post the results here. Let's see if this works! If don't I'll bring here what happened

Tks

Hi clmates!

You can tell me how do setting this? I'm working with JDE 811, no XE, but the application looks ok.

This setting will solve the problem with de AEXP too?

Actually, the problem is em AEXP, BIPI, BICM... All values of invoice, literally.

kylepyro,

My test have done exactly as you said, the total value in the order was 139,97.

Then, the problem isn't in the invoice generation, but in the sales order?

I already glanced over the code of the application, but can't locate something about this.

Do you know something?

I'll keep on seeking!

Hi Daniel.

I'm not sure, the best is that you use your CRP environment to change this setting in P0022 and test it

the control you have to change is the one with alias TAXL

clmates,

I have tested this on our PY, but it don't work.

Do you have an example of how you setting this?

Attached the print of the application.

Tks

Hi

Activate the Sales Order Taxes at Order Level checkbox

Then logout and login to the application, and test.

I don't know if this constant is cached at server level, so maybe you have to restart server, or flush caches, In XE that was read by the workstation upon start, but I don't know in 9.1

Good luck

Daniel, did you happen to find the solution? I'm from Brazil so I'll probably understand what kind of problems we can have (NFe... SPED Reporting...etc). I had rounding problems in other customers, but I'm not sure if I really understood the problem.

Portuguese version:
Danial, você achou a solução para o problema? Também sou do Brasil então tenho uma noção dos problemas que você pode enfrentar.. (NFe, SPED, etc). Tive problemas com arredondamento em outro cliente, mas não sei se eu entendi direito qual é o problema no teu caso.

I'll try this... let's see...

Então Olavo (vamos falar com português mesmo)... Ainda estou trabalhando nisso!

O grande problema, é que não é somente arrumar os valores nos pedidos, já que um mesmo pedido pode gerar mais de uma nota.

Então, o correto seria arrumar isso direto na nota fiscal, só que ai os cálculos de impostos teriam que ser refeitos.

Ou seja, vai ser mil vezes mais complicado.

Mas, enfim, é bom ver um brasileiro aqui, cara! rs

Me adiciona no gmail ([email protected]), é sempre bom ter contatos profissionais, além de a gente poder se ajudar nesses casos.

Vou tentar desenvolver uma aplicação ou um relatório para tentar resolver esse problema, parece que é o único jeito...


=================== English (Google)

Then Olavo ... I'm still working on it!

The big problem is that not only arrange the values ​​in order, since the same application can generate more than one note.

So the correct would fix it right on the invoice, only ai tax calculations would have to be redone.

Ie will be a thousand times more complicated.

I will try to develop an application or a report to try to solve this problem, it seems that is the only way ...