iMIS Desktop to Staff site: Functionality differences

There are several changes to the campaign and appeal structure from iMIS Desktop to iMIS EMS, with the main changes being the following:

• Campaigns are now a required component. Campaigns were not previously required, which allowed appeals to be created free from a campaign. In iMIS EMS, an appeal (now referred to as source code) must be tied to a parent campaign. The benefit to this requirement is that all users have access to the Marketing > Campaigns navigation of the iMIS Staff site, which was previously a licensed feature.
• Source codes cannot be used in multiple campaigns. While you can create many different campaigns with various source codes, each campaign must have a unique set of source codes, meaning there is no way to share a source code among multiple campaigns. The benefit to this change is the response tracking feature in iMIS EMS, which allows users to easily track source codes that are embedded in communication templates.

See Migrating campaigns and appeals from Desktop to EMS for full details.

The iMIS Desktop offered many GL export file types. The iMIS Staff site only offers IIF and CSV as GL export file types. See Exporting general ledger transactions for more information.

Note: The GL Processor by CSImay be a good alternative for some associations. See the GL Processor by CSI documentation for more information.

As the self-service functionality of the public website evolved, it was clear that self-service users were not creating batches or assigning cash accounts to the batches. As a result, no batch cash account or batch cash entity has ever been assigned to any online created batch.

Since almost all types of transactions can be processed by either public or staff users, the decision to standardize the processing on one model was necessary. For that reason, in iMIS EMS, the batch cash account is never populated in any online created batch, and the batch cash financial entity is eliminated from the hierarchy for determining the financial entity ownership of transactions.

The iMIS Desktop allowed a transaction to be deleted if the associated batch was not yet posted and the transaction had not been exported to the GL. Users cannot delete transactions in the Staff site.

The Desktop provides the ability for staff users and members to change the member type both during renewal and outside of the renewal process. The process to change from one member type to another in the Staff site varies depending on the scenario.

As the self-service functionality of the public website evolved, it was clear that self-service users were not creating batches or assigning cash accounts to the batches. As a result, no batch cash account or batch cash entity has ever been assigned to any online created batch.

Since almost all types of transactions can be processed by either public or staff users, the decision to standardize the processing on one model was necessary. For that reason, in iMIS EMS, the batch cash account is never populated in any online created batch, and the batch cash financial entity is eliminated from the hierarchy for determining the financial entity ownership of transactions.

iMIS Desktop: Understanding the batch cash account's financial entity

In iMIS Desktop, the batch Cash Account’s financial entity was used in two ways regarding accounting and financial entity assignment:

1. Payment Processing – When a check or cash payment is processed, the GL account and financial entity (directly or indirectly) associated with the batch's Cash Account was assigned to the payment transaction. If a credit card or debit card payment is entered, the GL account and financial entity (directly or indirectly) associated with the credit or debit card cash account was assigned to the payment transaction (as opposed to the batch Cash Account and financial entity).
2. Income and Accounts Receivable Processing – The batch Cash Account’s financial entity also factored into the hierarchy to determine the financial entity ownership of the income or accounts receivable entries. The hierarchy involved in assigning a financial entity to income transactions and any invoices that are generated from those financial entities is:
   1. Financial entity directly assigned to the product and/or the overall event
   2. Batch cash financial entity
   3. Module level default financial entity
   4. Overall system default entity

iMIS EMS: Comparing how financial entities are assigned

In iMIS EMS, the cash GL account and financial entity assignment is processed according to this approach:

1. Payment Processing – In every case, the payment’s GL account and financial entity is derived from the payment method that is selected for the transaction. While there was only one check or cash “cash account” (or payment method) per each Desktop batch, in iMIS EMS, a choice can be made from any number of check/cash payment methods that are maintained in a staff payment method set.

In short, the same functionality that applied to deriving the GL account and financial entity for a credit or debit card payment in Desktop now also applies to check or cash payments. For all forms of payment, the GL account and financial entity (directly or indirectly) associated with the payment method is assigned to each payment transaction.

2. Income and Accounts Receivable Processing – The batch cash account’s financial entity, since it is never assigned, is eliminated from the hierarchy to determine the financial entity ownership of the income or accounts receivable entries. The hierarchy involved in assigning a financial entity to income transactions and the invoices that are generated from those financial entities is:
   1. Financial entity directly assigned to the product and/or the overall event
   2. Module level default financial entity
   3. Overall system default entity

In the iMIS Desktop, standard prorating would prorate miscellaneous fees; however, in the iMIS Staff site, miscellaneous fees are no longer prorated.

In the iMIS Desktop, staff users could specify the amounts to apply to individual subscription lines for renewals. In the Staff site, you do not have the ability to edit, pay, or partially pay subscription lines from a contact's account page. Instead, you should adjust or reverse the invoice.

In the iMIS Desktop on the billing window, you were able to define a Bill to ID (now called the Bill to ID for renewals) per line item (subscription). In the Staff site, you are not able to define a Bill to ID for renewals per line item, and instead, a single Bill to ID for renewals is used when billing is generated.

There are differences in fundraising terminology and configuration between the Desktop and Staff site.

Appeals: Source codes

Appeals are now referred to as Source codes and must be configured within a parent campaign. The SOURCE_CODE general lookup table is deprecated, and all source codes must be configured through a parent campaign.

distributions: Gift items

Distributions are now referred to as Gift items.

Gift items cannot have campaigns or source codes associated with them; however, when entering a gift, staff users can choose a source code to associate with the donation (Fundraising > Enter gifts), and the campaign that is assigned acts as the source code's parent campaign. A campaign cannot be set directly for the gift.

Source codes can also be associated with gifts through links sent through an iMIS communication template.

Funds: Financial entities

Funds are now referred to as Financial entities and cannot have an appeal or campaign associated with them, like you could in the Desktop. Source codes (previously appeals) can only be assigned at the gift level.

iMIS Desktop offered two order entry options:

• Simple Order Entry
• Full Order Entry

With iMIS EMS, there is no Simple Order Entry, and all users have Full Order Entry, which may cause order transactions to appear differently than they did in iMIS Desktop. With Full Order Entry, the presumption is that you are taking the order through the different stages of the order process, such as converting it from a quote to an actual order, printing shipping papers for shipping, and then ultimately generating an invoice for the order.

Since the order goes through these stages, at the time the order is placed and paid, the payment is applied to a prepaid invoice, because the order is not initially invoiced. Once the order is invoiced, iMIS transfers the credit for this prepayment against the order invoice (this invoice is created at the time orders are invoiced).

The transactions created when paying for the order at the same time it is placed works the same way as Full Order Entry transactions, so even though the settings for orders say to go ahead and move them to invoice stage at the time of the order is placed, iMIS still creates these three transaction lines.

The iMIS Desktop offered the Create New Batch for Invoicing configuration option that, when enabled, would create a new batch each time order invoices were generated.

In iMIS EMS, there is no such configuration option, because this is the default behavior. When order invoices are generated, a separate batch is always created, and the Invoice date is used as the Batch date, and the Created By field always displays AUTOBATCHINVOICE.

See Processing orders for more information.

Event registration classes enabled staff to manage the categories for customers that were planned to register for an event. Event registration classes were assigned to an event with a specific price. Anyone who had the same registration class assigned to them would receive the event pricing when they registered.

The same concept still applies in the Staff site but through pricing groups. Pricing groups are created using IQA queries and adding the query to an event registration option.

Prices assigned to registration classes in Desktop are honored in iMIS EMS, but registration classes cannot be viewed, edited, or used for reporting.

The iMIS Desktop offered aTransfer/Substitute button that allowed staff users to transfer an event registration to another contact.

You can still transfer an event registration from one contact to another; however, the original registration must first be cancelled. After the registration is cancelled, the open credit from that registration can be applied to the new registrant's registration.

In the Desktop, defining more than one primary dues product in a customer type was referred to as "wildcard products." In iMIS EMS, the term "wildcard" is no longer used. Instead, "multi-year billing" or "formula" are now used to referred to customer types with more than one primary dues product.

From Settings > Contacts > Customer types, open a customer type to review. You will see under the Primary fee drop-down, there us a checkbox labeled Use formula. This is where the old "wildcard" products are now defined.

When Always Create was enabled for a user defined table (UD Table), iMIS Desktop would automatically add a row to the table for newly added contacts.

iMIS EMS does not offer the Always Create functionality; instead, when joining two tables, business objects, or panel sources, be sure to use the Left Join or Right Join options.

Unless specific General Ledger (GL) Accounts are needed for each credit card provider, it's not necessary to create separate payment methods (like Visa, Mastercard, etc.). Instead, you can create just one credit card payment method to cover all credit card transactions.

iMIS EMS uses the NVarChar data type for contact name columns, product and event titles, descriptions, and event notes to support special characters, such as Māori macrons. Upon upgrading, custom business objects from iMIS 2017 referencing these columns convert from VarChar to NVarChar, ensuring special character compatibility.