Description

Hello,

I have a situation that is somewhat out of the normal, but is something that happens in iMIS in other circumstances. Let me lay out the scenario. We have a dues billing situation where an association has two different dues products. One amount is collected for the association’s dues, and another amount is collected to pay a parent organization’s dues.

The products (called MDUES for the association’s dues, and ADUES for the parents dues), are billed on separate cycles. Since the ADUES are billed in August, and the MDUES are an Anniversary dues product, there is the opportunity for the member to make two individual dues payments during the year.

Currently, both the dues products are both setup as DUES product types, and are included in the Customer Type setup, MDUES being listed first and ADUES being listed second. This would indicate to me that the MDUES is considered the “Primary” dues product for an individual.

Here is the problem. We have a dues balance amount for MDUES. A person goes to the web to pay the outstanding balance. We post the batch, it moves the Name.paid_thru and the Subscriptions record’s paid_thrus on MDUES, just as you would expect. An ADUES record is then placed in the person subs records. In the same calendar year another web payment is made for the ADUES product. The posting of that batch also moves the Name.PAID_THRU as well as advances MDUES another year, even though no balance or payment was taken for that MDUES product during the second transaction. Since ADUES is being collected for the parent organization, and is not the Primary dues item, we don’t want the paid thru moving around on anything but that particular ADUES subscription record.

In an attempt to get around this problem, I set up an alternate ADUES type of product under the product_type of MISC. My thinking here is that since the new product is not a dues product type, the paid thru will not move upon paying off the balance. To my surprise, paying of a balance on the MISC dues item and posting the batch again moved the PAID_THRU dates on Name.PAID_THRU and advanced the MDUES dates.

I have not tried deleting the subscription item from the collection on the fly, adding it back in, and rebilling the item as NonDuesSubscription item.. That might or might not work, but it would seem that I shouldn’t even have to go through this additional step. I also have not tried any other product types other than MISC, but that being the most generic, I thought that would work in almost every circumstance for what I am trying to do here.

The association is fairly open to change if there is another technique or setup combination that would allow them to accomplish the end goal, i.e. other product types for the dues products, or adjustments to customer types or product setups.

We are using a proven set of IBO code that is deployed widely and working fine in every other circumstance. I can provide off line if you would like, screen shots as well.

In a related question, is the IBO ever going to expose the Dues Billing Cycles that are setup in iMIS? It would be nice to make a determination of what a particular member's group of “normal” products that would be billed (similar to using the Create Invoice feature in iMIS and selecting a billing cycle to create the subscription items) in a joining scenario.

Thanks

Bill