Panopea Consulting - iMIS Blog

Accrual Dues + List Bills + Payments = Ugly

I have a client who needs to combine accrual dues billing with list bills. That is, a single invoice created for the dues of many individual members linked to the paying entity using the Bill To ID field on the Financial tab.

What I've found is that the billing process itself works pretty nicely but the payment application processes have some truly ugly bugs.

If you meet all three of the items listed below, you can just skip reading this post because you won't have a problem (at least as far as I know) with accrual dues + list bills:

1. The number of members per list bill is low. Unfortunately, I can't tell you how low it needs to be, but if you get into the hundreds, you may be in trouble.
2. You always receive a single check that pays the invoice in full.
3. You never make a payment application error such as applying a payment to the wrong invoice.

Yeah, not a very likely set of conditions and my client doesn't fit any of them.

Here are the specific issues that I've seen so far:

Problem #1 - Can't apply a payment to large list bill
Using either Service Central or the Cash Receipts module, you may find that large list bills cannot be paid successfully. iMIS will hang and the transaction will fail to complete. My client ran into this for when trying to apply payments for about 2,000 members and also for several hundred.

The "fix" to this is that you can get a modified license key to use "Advanced Pay". You will be adding ADVPAY to your license code string and you will add a new stored proc to your db called sp_asi_ARPayment. I say "fix" in quotes because the use of ADVPAY causes other issues -- keep reading.

Be aware that this solution requires that you enter the payments for these large list bills using the AR module's Cash Receipts window and you must enter the invoice number into the Cash Receipts window. You cannot just enter the ID and apply the payment to the correct invoice line. You cannot use Service Central's payment window.

Problem #2 - Can't delete an existing payment
With or without ADVPAY in place, and whether using Service Central or AR/Cash's Cash Receipts window, a payment for an accrual dues list bill that has been previously entered cannot be deleted. Attempting to do so will hang iMIS. I've not found a fix to this problem. (SMR 196675)

Problem #3 - Can't correctly apply a second payment to an invoice
Haven't identified the reproducible set of circumstances to make this happen, but sometimes if applying a second payment to a invoice that wasn't fully paid by the first payment, the application of the second payment sets the Paid Thru date of all of the members to NULL. Nice, huh? This is due to a problem in the sp_asi_ARPayment proc but I've not figured out where the issue lies (yet). (SMR 183036)

Problem #4 - Can't enter a correct reversing payment if using ADVPAY
Since you can't delete a payment, then the only way to correct a payment entry error is to enter a reversing payment, right? If only life were so easy. If you're not using ADVPAY, entering a reversing payment does work. But if you are using ADVPAY, the sp_asi_ARPayment proc is written so that the reversing payment is 100% applied to Line #1 of the invoice. Fortunately, since the problem is in the proc, you can adjust the proc. I've done so (and I am really hoping I've done so correctly!) so I think I actually can claim a successful workaround for this issue! (SMR 195223)

By the way, this client is using version 10.6.30.17 but so far none of these issues have been identified by ASI Tech Support as having been resolved in later versions.

"Hidden" Feature of Service Central

How many of you using, supporting or selling Service Central are aware of its List Paying functionality?

I have run into this at more than one client who is already using the Service Central module in iMIS and could use List Paying but don't know they already have it. So I don't think enough of the iMIS world are aware of this very cool feature. I just ran into this again yesterday at a new client of mine.

List Paying is absolutely wonderful if you receive a single dues payment from an entity that is paying for many individual memberships. Without List Paying, you must go to each individual's record, apply the dues payment, move on to the next. Repeat until you are ready to scream. And god forbid, you should miss one person's payment and then have to go back to figure out who you missed. It can take a long time to apply the payments.

Much of that pain is alleviated by Service Central's List Paying functionality. All you have to do to make it work is to populate the Bill To ID field on the Financial window of every individual member with the ID of the entity that sends you the big check.  If you're doing a mass update to set this up, you need to populate Name.BT_ID and Name_Fin.BT_ID.

When you receive that big check, go to Service Central > Enter/Edit Payments and enter the ID of the entity. Not only will you see the amount owed by the entity, you will also see all of the dues payments for all of the individuals that you need to apply payments for. Right there in a single window! Apply the payments here, click Save. Every individual's record will be properly updated to show the dues payment including updating Name.PAID_THRU, updating the Subscriptions records and creating the Activity records.

p.s., It's even documented in the manual!

At Long Last - 10.6.29.06 patch available

ASI has released the 10.6.29.06 patch for the client and re-enabled the links for the other 10.6 patches on their website.

Colors in the 10.6 Framework

Some time ago I posted an entry with my complaints about the 10.6 color scheme. I still don't like it and so far the clients I've shown don't either, but an important thing to remember about the framework is that it can be modified.

Making the modifications just got a lot easier thanks to Henry Huey of ASI. He's posted a tool for doing it on the imiscommunity website. If you have access to that site, you'll find it here:
http://www.imiscommunity.com/imis_framework_colors_utility

Haven't had a chance to take a look at it yet, Henry, but a big thanks for posting it. 

p.s. There's about a gabillion GREAT reasons to like 10.6 so don't let my snark about the color scheme seem like I'm making an overall comment about 10.6. I'll do that in subsequent postings.

UPDATE: I tried it on my test 10.6 environment and it worked great.

Big Ugly Bug in 10.6

Just in case you're not aware, there's a big ugly bug in version 10.6. If you post a batch with dues payments, it will corrupt your existing Dues activity records.

This will be corrected in a patch to be released very soon. ASI will also be redistributing the client software CD for 10.6 so that this correction is included.

So, kids, don't upgrade just yet.

If you have already gone there, contact ASI for a correction script. Cornell Hooton also posted one on the NiUG listserv yesterday.

10.6.29.03 CS Patch Available

ASI has released the .03 patch for 10.6 as of yesterday.

This fixes a critical bug where iMIS would hang when you attempted to edit the registrant class of an existing registration plus a few others.

10.6 Bug? Dues Importer fails on large import

In a test upgrade of a client's database from 4.40 to 10.6, there seems to be an issue with the Dues Importer failing on large imports (31,000+ payments). The process is failing around the 16,376 to 16,383 trans count.

Looking at a SQL trace, I can see that the update to the Batch record is malformed. It says "...LAST_UPDATED =  WHERE ...".

In this case it should have said "...LAST_UPDATED =''MANAGER''  WHERE ...".

Pretty dang [more colorful adjective deleted to preserve G rating] annoying to have the thing fail for something that matters so little!

Submitted as SMR #126552. Will update when I get ASI's response.

UPDATE #2: As of 5/10/06, ASI rates this issue as Urgent. They already have a fix for this -- I tested a new build of the imisar.lbr and my test file of 31K+ payments did not fail. And it seems to be importing faster! Tech Support says .05 will be released within two weeks and I assume it will be sooner. Yahoo!

UPDATE: As of 5/5/06, ASI confirms that it is an issue and Dev has already provided Tech Support with a new build to test. I don't know when it will be available. I hope it makes it into the soon-to-be-released .04 patch.

Change in Security Levels & Batches

From the Feb. 2006 ASI TechLet:

Batch Security Levels in v10.5

A change was made in iMIS 10.5 to the security level needed to view Posted/Closed Batches. As of 10.5, you need a security level of 8 to view Posted/Closed Bathes. Prior to this release, a security level of 4 allowed users to view Posted/Closed batches. In addition, the security level to mark a batch ?Post Ready? decreased from security level 4 to 3.

Corrupted Library File

A client was experiencing the following symptoms in version 10.4 using Sybase: The user would attempt to open a new batch by clicking the New button and nothing would happen. If the user would try to click on an existing open Batch then the following error message would occur: 

(Click on the image to get a better view of it.)

The solution to this problem was to replace the IMISAR.lbr file on this user's computer.

What's funny about the corrupted .lbr file problem is that you never can really tell how it might behave. The same file might get corrupted and display completely different strange behavior. So here's my checklist of conditions that should make you suspect that a corrupted file is the cause of the problem you are seeing:

• The problem is limited to a single workstation.
• The problem is not iMIS user-specific. That is, no matter what log in you use on that same computer--including MANAGER!SA or (MANAGER!DBA), the problem occurs.
• The problem is limited to a single module. In this case, I didn't know at first if there was some sort of issue with the ODBC configuration on this computer but since the user can insert into Name or for an Event registration, then it's not likely to be the ODBC configuration.
• It's kind of funky -- strange behavior you've not seen or heard of before. It's no known bug. And the user's computer has been working fine in the past.

And in case you are wondering how a file gets corrupted in the first place, it will happen sometimes if your computer crashes. A power failure or any other reason you reboot while you were in iMIS are typical scenarios.

This problem doesn't come up all that often, at least amongst my clients. I think I run into it maybe once or twice a year. Just get a new, fresh copy of the .lbr and if it resolves the problem, then you know corruption was the issue. If you can't easily find a new, unused version of the file, you can also grab one off a computer that is not experiencing the problem. But I prefer to grab a brand new copy if at all possible.