Re: Rounding at Sales Invoice Amount -- BPCS-L

This is probably version specific.  What version you at?
We at 405 CD on AS/400 mixed mode on OS/400 V5R1.

This sort of thing also varies by what programming language you using, alsolook at query/400.

There is also an issue of what the people in charge of company accountingwant done, and whether your version offers you the flexibility to go one ofseveral ways. I do not have enough education in accounting to know what isa valid rule, and if this varies by government jurisdiction.

We had to modify because of systemic bug that SSA would not fix when wewere on them for tech support ... we now on another place.

The systemic problem is that in IBM RPG when you are doing math withmaximum size fields like x,xxx,xxx,xxx.xxxxx there is a concept that peoplein Microsoft and Internet world call a buffer overflow, but in the IBMworld it is that when values in the math fall outside of thex,xxx,xxx,xxx.xxxxx space alotted without the programmer supplying workfields to handle that overflow, then you can get mathematically wrongresults, and this is most likely to happen not when you have populationnear the ends of the fields like in the first or last digits, but when youworking with what IBM calls extreme values like zero and one.


99% of the time it looks just like a rounding error.

If your cost buckets don't add up and they off by like 0.00001 or 0.00002and some costs go negative, this problem probably caused by this bug.We once got an entry to our General Ledger for 9,999,999,999.99998 whichwas caused by this bug.Because it is from a bug, you can't reverse the transaction and expect theerror to go away.


This is clearly spelled out in the IBM RPG programmer manual.

When I reported this to SSA, I gave them chapter and verse from the manual,and where in several programs (e.g. costing, invoicing) they doing thiswrong, but I don't think SSA tech support understood what I was trying totell them.


We do our invoicing to 3 decimal places after the $

this is because we used to be selling reels of wire which verycompetitively priced, and needed the extra decimal places in the quoting.

So basically our invoices are telling our customers that they owe to somefraction that does not exist in real currency.

I had a former boss who disagreed with me what half adjust meant anddemanded that we modify all the programs to agree with hisinterpretation. I wanted to let it just do whatever IBM and SSA hadprogrammed, and not sweat that microscopic detail in billions of sourcecode lines, but he wanted it fixed.

I said that when I went to school and we covered this, it was 50 years ago,so my memory could be failing, but what I remember was:* When what you are rounding is material consumed, you always round up anyfractions ... it is like the story of the army busses and trucks ... howmany vehicles to carry all the troops, without the extras sitting insomeone's lap, on the floor between seats, standing up or whatever ... youround up to an extra vehicle

* When the value is bigger than point 5 you round up
* When the value is smaller than point 5 you round down
* When the value is exactly point 5 you take it to the nearest even number

Well my former boss disagreed about the exactly point 5 scenario ... hesaid it always went up

Afterwards I asked my sister about this ... she teaches high school math,and at the time she was also doing some college classes ... basically shetold me that we were both wrong


it is not true that there is ONE RULE
there are in fact several valid rules available

We had a similar situation on the ERP we were on before BPCS

I was in the habit of studying the documentation on patches before tryingto implement them.

I found one in which I knew enough accounting to know this cannot be right.

Some customer that knew nothing about accounting had complained that theERP would not let them post to General Ledger when the debits and creditsdid not match, so the vendor fixed that, and one of the latest collectionsof patches would let 100% of the ERP customers post stuff to General Ledgernot in balance.

Hi All,
 Would you like to share your experience about rounding at Sales Invoice ?
Is it true that BPCS round amount net price and tax at invoice line level,
not at total invoice level ..or maybe I don't setup parameter incorrectly?

Example:

*(Setting)*
Round Type: Half adjustment
Round to position type : 1
Tax Rate: 10%

I have 1 invoice with 3 inv line. All of these inv lines have same setting
above.

*(SIL.ILNET )*
SUM(97.5 + 97.6 + 97.8) for invoice #1 = 292.8
After rounding, it should be 239

*(SIL.ILTA01)*
SUM(9.75+9.76+9.77) for invoice no. #1 = 29.29
After rounding, it should be 29

But.. what I found at SIH.SITOT and SIH.SITAX ?
SITOT = 324 and SITAX = 30

I assumed that 324 was origined from 294 + 30 (sitax).
294 = half adj(97.5) + half adj(97.6) + half adj(97.7)
30 = half adj(9.75 ) + half adj(9.76) + half adj(9.77)
 Thanks in advance..


-
Al Macintyre  http://www.ryze.com/go/Al9Mac
BPCS/400 Computer Janitor ... see
http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html