❑Welcome to the Summary Page with the New Features in the MKMS Version 5.1.35.8249 to 5.1.35.8251 Release.
•Several "bug fixes" have been completed during this series of updates.
•The major changes and enhancements are included in the Features List below.
❑Understanding the Features List:
•All of the Program Module(s) that are Affected are listed.
•The Chapter Links are provided for finding the instructions, illustrations, and details on the operation and usage of the new feature(s).
•A brief Description of the Enhancement is shown, sometimes with additional Chapter Links.
Program Module(s) Affected |
Chapter Links |
Description of the Enhancement |
|
|
|
There is a new Invoicing Groups Form (located in General Maintenance) which has been added for those Companies who have a large number of Accounts (Subscribers), many of whom are Invoiced for on-going monitoring and recurring maintenance services, and often these services are provided at multiple locations for varying sets of those recurring services. ▪Under these circumstances, the associated Recurring Revenue Invoices can become extremely long, complicated to read, and difficult to comprehend.
The "Summarize Recurring Items" option on the Print Invoices Form allows the Detail Line Items on those Recurring Revenue Invoices to be condensed into groups - sets of related Recurring Revenue Items summarized together - and printed with a simple Description and Total for each set (Invoicing Group) of items. ▪The Description for each recurring revenue Invoicing Group is defined using this new Invoicing Groups Form ▪When a Recurring Revenue Item may need to be grouped with similar items when the Summarize Recurring Items option is chosen on the Print Invoices dialog, use the Drop-Down Selection List provided on the Recurring Revenue Form to Choose the appropriate Invoicing Groups Description from that list.
Any number of Invoicing Group Descriptions may be defined, and any one of these may be added to any Recurring Revenue record when that Recurring Revenue item is to be available for grouping. a)This Invoicing Group's Description will determine in which Invoicing Group that Recurring Revenue Item will be included when the "Summarize Recurring Items" option is Checked in the Print Invoices dialog. b)The Description of the assigned Invoicing Group will be the Description printed on the Invoice - along with the Total charges for the set (group) of summarized Recurring Revenue Items. c)By using this feature, the length of those Recurring Revenue Invoices will become much more manageable (and comprehend-able) for the recipient.
❖ See the Summarize Recurring Items discussion in the Print Invoices chapter for more information. |
||
Other System Maintained fields section on the Recurring Revenue Form:now has fields which are populated by the system as that data becomes available.
a)Last Period Billed - The Month and Year in which Auto Billing was executed for this Recurring Revenue item. b)Last Date Billed - The Billing Date assigned to that Recurring Revenue item's Invoice. c)Next Billing Period - The Month and Year in which Auto Billing should be executed for this Recurring Revenue item.
Invoice Group - The Invoicing Groups Form is used to define the Description of Summarized Invoices when a Recurring Revenue Item should be grouped with other similar items to simplify and clarify the resulting Recurring Billing Invoices. ▪This Special Function Invoice Group field is manually populated when appropriate.
❖See the Summarize Recurring Items discussion in the Print Invoices chapter for more information. |
||
|
|
Tokenized Credit Card Information: ▪When InnoEPay is properly installed and operating as your Company's Payment Gateway, that system will "tokenize" the Account Number and Expiration Date of those Credit Cards identified in the Auto Draft Setup section of the Edit View of the Subscriber Form a)Thereafter, when the Credit Card Account Number and/or Expiration Date changes, the system will set Credit Card Status field in the epPayBatchDet table back to PENDING and Card Token data back to NULL, b)This will cause the InnoEPay service to "tokenize" the Credit Card again using the new (revised) Credit Card Account Number and/or Expiration Date information. |
|
When a Bank Draft is being defined in the Auto Draft Setup section of the Subscriber Form's Edit View, there is a new "Account Holder" field available. ▪By default, the Subscriber's Name entered in the General Subscriber Information section is inserted as the Account Holder, but this should be modified as required.
Thereafter, when changing certain Auto Draft fields a)Draft Type (CardType), b)Account Holder (BankAccountHolder), c)Routing Number (RoutingNumber), d)Account Number (BankAccountNumber), e)Account Number (CardNumber), f)Credit Card Type (CardKind), g)Account Holder's Name (CardHolderName), h)Expiration Date (CardExpiryDate), i)Account Holder's Address (CardHolderAddress), j)Zip/Postal Code (CardHolderZip)
▪The system will display a Confirmation box with three options will be displayed: 1)Yes - Click the "Yes" option to use the new information and to update any pending transactions. 2)No - Click the "No" option to save the changes and the existing payment transactions will be processed with the old (previous) information. 3)Cancel - Click the "Cancel" option to abort the changes.
When the "Yes" option is selected, the new Pay Batch Pending Transactions dialog - data grid - will be displayed. ▪This Pay Batch Pending Transactions dialog will allow the User to modify PENDING payment transactions. ▪If you do not want to modify a PENDING payment transaction, you may (as needed) Delete a selected payment transaction from the data grid and then enter a new E-Payment which would use any revised information. |
||
There is a new Summarize Recurring Items? option on the Print Invoices dialog. ▪This "Summarize Recurring Items" option allows the Detail Line Items on those Recurring Revenue Invoices to be condensed into groups - sets of related Recurring Revenue Items summarized together - and printed with a simple Description and Total for each set (group) of items. ▪The Invoicing Groups (General Maintenance) Form will be used by those Companies who have a large number of Accounts (Subscribers), many of whom are Invoiced for on-going monitoring and recurring maintenance services, and often these services are provided at multiple locations for multiple, for varying sets of those recurring services. oUnder these circumstances, the associated Recurring Revenue Invoices can become extremely long and complicated to read (and difficult to comprehend). ▪The Description for each recurring revenue Invoicing Group is defined using the Invoicing Groups Form (located in General Maintenance).
Check this Summarize Recurring Items? box on the Print Invoices dialog to have those Recurring Revenue Items - which were assigned an Invoicing Group Description - summarized into one Detail Line Item on the Subscriber's Invoice. ▪The Description printed on the Invoice (along with the Total charges of those summarized Recurring Revenue Items) will be the Description of the Invoicing Group assigned to each member of that group of summarized Recurring Revenue Items (i.e., by assigning the appropriate Invoicing Group to those Recurring Revenue item's record, those Recurring Revenue Items will be summarized on that Invoice when the "Summarize Recurring Items" option is selected.
➢Note: When there are Recurring Revenue Items not assigned to an Invoicing Group and/or other non-recurring item(s) on the same Invoice, those Detail Line Items will appear individually as usual. |
||
If a Recurring Revenue record has been assigned an End Date and the DeferRecurrringRevenue option in Company Settings is set to True ("T"), the End Date can no longer be modified. ▪When that Recurring Revenue record was ended, it inserted the remaining Amount that was in Deferred into the Transaction File thus reducing Deferred Amount and increasing Sales Amount. ▪Therefore, changing the End Date would double-dip the Deferred Amount.
Now, the User must create a new Recurring Revenue record, and set the End Datedate to the Date to which is should have been set. |
||
There is a new Proposal Lost Reason Form (located in General Maintenance) which is used to identify the various Reasons for why a Proposal would be/has been rejected by a Prospect or Subscriber. a)One of these Proposal Lost Reasons must be assigned to any Proposal which was ultimately rejected. b)Thereafter: 1)The associated Proposal Loss Report will provide a list of those Proposals which were determined to have been lost (i.e., ultimately rejected by a Prospect or Subscriber) and includes - among other information - the Date of, and Reason for each rejection. 2)The associated Proposals (Grid) report will also report the Reason why a Proposal was rejected. 3)The Proposal Lost Report c)These reports may be grouped, sorted, and/or filter by one or more Reasons. |
||
There is a new Proposal Status Form (located in General Maintenance) which is used to create Descriptions representing the current Status (as it relates to a Proposal's Sales Cycle) of any Proposal created for a Prospect or Subscriber. a)One of these Proposal Status Descriptions must be assigned to each Proposal. (initially the system provided Default Proposal Status will be assigned automatically). b)Thereafter: 1)The associated Pipeline Analysis Report will provide a list (among many other things) of the Status of each listed Proposal 2)The associated Proposals (Grid) report will also report the Status of each listed Proposal. 3)The new Proposal Lost Report (see below) which includes the Status that existed immediately prior to when the Proposal was rejected. 4)The Status and Rating Modification report (see Status/Rating Modification Report below) which displays a list (of selected) Proposals which have had a Proposal Status and/or Confidence % Rate change occur (See the "Understanding and Using the Confidence % field" discussion in the Proposals chapter for more information) within a specified Range of Days. c)These reports may be grouped, sorted, and/or filter by one or more the assigned Proposal Status. |
||
There is a new Proposal Lost Report which displays a fully functional data grid (list) of those Proposals that were determined to have been lost (i.e., ultimately rejected by a Prospect or Subscriber) which includes - among other information - the Date of, and Reason for each rejection, and the Status that existed immediately prior to when the Proposal was rejected. ▪This Proposal Lost Report data may be viewed, sorted, filtered, reconfigured, printed, emailed, and/or exported, as may be required. ▪See the "Understanding and Using the Confidence % field" discussion in the Proposals chapter for more information. |
||
There are 5 new fields which have been added to the Proposal Header on the Proposals Form ▪These fields allow your Company to more effectively track current Status (within the Sales Cycle), its Confidence Percentage Rating, and why a Proposal was Lost, the Lost Date, the Lost Reason. 1.Status – a Drop-Down Selection List field - the current Proposal Status must be identified. 2.Confidence % - a numeric field - requires 0 - 100 (%) entered as appropriate â. 3.Proposal Lost - a Check box field - Defaults to False (not checked). 4.Date - a Drop-Down Calendar/Date field - If "Proposal Lost" box is Checked, the Date Lost (and Reason - see #5. below) will be required with the Date field defaulted to Today. 5.Reason – a Drop-Down Selection List field - If "Proposal Lost" box is Checked, the Proposal Lost Reason will become a required field. â See the "Understanding and Using the Confidence % field" discussion in the Proposals chapter for more information.
The following reports use some or many of these new entries: |
||
There is a new Proposal Expiration Aging Report - presented as a data grid - which displays an "Aging Grid" showing how many days have passed since the Expiration Date that was assigned to each listed Proposal. ▪This information lets the Sale Team and/or Sales Manager see how "stale" these Proposals have become. |
||
There is a new Status/Rating Modification Report - presented as a data grid - which displays a list (of selected) Proposals which have had no Proposal Status, and/or Confidence % Rate, and/or Active State changes made to those Proposals within a specified Range of Days. ▪This information will help the Sale Team and/or Sales Manager see how "actively and/or inactively" these Proposals are being managed. |
||
|
|
|
The Pipeline Analysis Report has been enhanced with additional columns (fields) with the information from each Proposal's Status, Confidence $, Confidence %, Gross, and Inside Sale entries. ▪See the "Understanding and Using the Confidence % field" discussion in the Proposals chapter for more information. |
||
The Proposals (Grid) - which is a fully functional data grid that lists all existing Proposals (for Subscribers and Prospects) within a User specified Date Range with those Dates based on a User Selected Type of Date (i.e., Creation or Expiration Date) - now has 5 new columns (fields) which should allow your Company to also track why a Proposal was Lost, the Lost Date, the Lost Reason, the Confidence Rating, and current Status (within the Sales Cycle) of each Proposal. 1."Status" – a Drop-Down Selection List field - the appropriate Proposal Status must be selected.. 2.Confidence % - a numeric field - requires 0 - 100 (%) entered as appropriate â. 3.Proposal Lost - a Check box field - Defaults to False (not checked). 4.Date - a Drop-Down Calendar/Date field - If "Proposal Lost" box is Checked, the Date Lost will be required and will be defaulted to Today. 5.Reason – a Drop-Down Selection List field - If "Proposal Lost" box is Checked, the Proposal Lost Reason will be required. â See the "Understanding and Using the Confidence % field" discussion in the Proposals chapter for more information. |
||
|
|
|
Previously, in the Item List sub-tab of the Inventory Tab in the Inventory Tracking/Job Costing system, when the Use Inventory function was accessed, the system took a long time to insert that Inventory Usage record because the Use Inventory function ALWAYS attempted to update the Kits table, even though it was rarely necessary. ▪Now the system determines - as an Inventory Item is identified as Used in the Job Invoice Multi Usage dialog, whether or not that Inventory Item was assigned to a Kit, then only calls the Kit Recalculation procedure when it's actually needed. |
||
|
|
