• Article Type: General
• Product: Aleph
• Product Version: 20

Description:
When loading an EDI invoice with a Service Charge at the beginning of the file, the service charge is spread evenly across all line items on a percentage basis, i.e. if the line item accounts for 10% of the total invoice it will get 10% of the service charge added.

However, the system is not calculating this amount correctly.

I loaded an EDI invoice with three line items, three different prices, all prices in whole dollars, and with a service charge of exactly 1% of the total, so that there would be no fractions of a penny to calculate. The first two line items had a service charge applied that was one cent less than it should have been, and the last line item was two cents more than it should have been.

In our v.20 Test server, in the ham50 ADM, see Vendor WOLX and Invoice # 65629.

This seems to be a variation of the same problem as the incorrect division of encumbrances when there is more than one budget per order, and the incorrect calculation of remaining encumbrance after an invoice.

Resolution:
[From Ex Libris:]

I see your example, and the results of the pro-rated charges. You're correct that rounding can sometimes cause a discrepancy of a penny or two, although the toal amount payable should always be correct. In this example, the rounding error is introduced because the individual line item amounts (207, 29, and 304) don't divide 'nicely' into the total (540). Some degree of rounding is necessary. I think if you change the 3 line item amounts to 216, 27, 297, for example, the pro-rated amounts would be more precise.

In any case, I'm wondering what the impact of this is on actual operations to determine if it's worth sending to development. My initial thought is that it probably isn't worth a developer's time to analyze and work on.


[More from site:]

Yes, if you change the first one to be exactly 40% of the total then it works. Unfortunately I'm one of those people who thinks it really does matter whether an accounting system gets the numbers right all the time. Since I have now shown three separate places in Aleph where this type of error occurs (Invoice service charge distribution, calculating the remaining encumbrance after an invoice is applied to an order, and in the division of encumbrances when there are multiple budgets for one order) I'm guessing it's all coming from one math subroutine that is called by all three of these operations. Isn't it probably an easy thing to find and look at that one subroutine?

I found a fourth instance where this is a problem: When loading an invoice line item for $30.80 split 50/50 between two budgets, the budgets were charged $15.40 and $15.41 respectively.


[More from Ex Libris:]

In our telephone call, we agreed that what you have reported is clearly a bug, or more likely a set of four or more bugs in the Aleph software. However, the overall result will generally be small enough that even a conscientious auditor would be able to let it pass, since the final totals always seem to add up properly. Because of that and the fact that we have no other reports of these problems, it seems unlikely that we would ever be able to fit the necessary fixes for these problems into our Development roadmap. If there's such a small chance that we'll ever fix them, it makes sense for us to close the incident at this point, rather than passing it on the Development to sit on the shelf.

The details of the problems are well-documented in this incident so that if the problem is ever reported again, we will be able to refer to this incident and possibly someday build a stronger case for fixing them. For now, though, I'll set the incident to Closing.

• Article last edited: 10/8/2013