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

Description:
In v.18 we are seeing two odd problems that seem to be related.

1. When recalled items are billed to Lost by p_cir_51 (or any other method), cash transaction type 54 is being charged although we do not have 0054 defined in tab18.eng. The display text that shows for the 54 transaction ("Lost item - maximum overdue fine") is what we have defined for 0042 transaction, but the 42 charge is not being charged. Also, our 0042 transaction is set to bill $10, but these 0054 charges show up as $100; we have no $100 amounts defined in columns 7 or 8 of tab34 anywhere. Related cash transactions 0041 and 0040 are being charged correctly.

2. Some dates and times that display on the Cash node, Loan tab are crazy (e.g. 20/07/1442). The display also includes weird Return dates (e.g. 23/00/0726), even though if an item is Lost it has not yet been returned! The z36 (loan) record looks fine.

Resolution:
The 0054 transaction MUST be defined in your tab18.<lng> or you can experience this problem!

The first problem--the presence of odd 0054 charges along with the 0040 and 0041 charges--is due to a bug or a configuration problem, depending on how you look at it. If the 0054 transaction is not defined in tab18.<lng>, the programs that handle overdues mistakenly add a 0054 transaction anyway, based on the values you have defined for the 0042 transaction, with a twist: if you have OVERDUE-RECALL-RATIO your tab100 set to "Y", the program multiplies the current amount in Z31 (the normal 0042 charge) times itself to calculate the actual charge. So, since you have the 0042 charge set to 10, the 0054 charge is created as 100. While this problem is due to a program bug, there is an easy workaround. You can define the 0054 transaction in your tab18 and just set the values to "N" and zero and such. That way, this bug will not be operative for you and the errant charges should not appear.

The second problem--the display of very odd dates and values in the cash-->loan tab for these "54" transactions--is due to the fact that the Z36-KEY value is created as if the transactions were 0042 charges. The Z36-KEY field can be interpreted in two different ways, depending on the transaction type. The 0054 transactions are added as if they are 0042 transactions, but they are displayed as non-004X transactions, so the display is completely messed up. Again, the workaround of defining the 0054 transaction in tab18 will keep these transactions from being created and will thus avoid the problem in the display.

If you find that any of these 0054 transactions were created in your system, you can change them to 0042 transactions and change the amounts to correct them.

• Article last edited: 10/8/2013