Road to e-automate 8.0 - Office Equipment Management Software - Service Management Software - Copier Dealer Software - e-automate Dealer Software

Customer P&L Infrastructure

Most transactions that apply to customers are entered via AR Invoices and AR Payments and these transactions get tagged appropriately to the customer in the general ledger; however, other transaction such as AP Invoices and GL Module Journal Entries cannot be tagged with a customer.

Existing Functionality Problems
  1. GL Module Journal entries cannot be associated to customers
  2. AP Invoices cannot be associated to customers
  3. Non-GL Module Journal entries can be orrected and voided thus causing loss of customer association

8.0 Functionality
The ability to tag all GL module journal entries and AP entries with a customer (if applicable) in order to have the data to support a customer P&L report.
  1. The ability to add Customer to GL journal entries and AP Invoices
  2. Prevent voids and corrections of non-G/L module journal entries
  3. Modify de-normalized GL Transactions table to pull in GL and AP customer information. NOTE: This table currently shows in e-views and contains all GL entries with their associated customer (if applicable).

GL Distribution Code

Currently users have to manually enter the distributions on each AP Invoice.

Existing Functionality Problems
  1. Because it is manual, it is time consuming and it leaves room for data entry error

8.0 Functionality
Ability to allocate a GL code to a different GL code and/or allocate further by either $ amount of %and then by division, branch or dept.
  1. Added the ability to create/modify/delete GL Distribution Codes. Each code will support G/L Account, Department & Branch splits by percentage
  2. On AP Invoice Detail screen added the ability to select an GL distribution code. Upon selecting and clicking OK, a line item for each separate distribution will be calculated and added to the invoice.
  3. Allows for the distributions from the distribution code to be combined with the ability to distribute to multiple equipment so that each equipment can be distributed to multiple accounts and departments. The branch on the distribution code will be overridden by the branch on the equipment.

A/R Reps and Task Management

The AR Console currently has a filterable list of customers with balances and a company-wide task list

Existing Functionality Problems
  1. Customers do not have an AR Rep field.
  2. The AR Console is not easily filterable by AR Rep.
  3. The AR Task list does not support the flexible filter control and cannot be filtered by AR Rep

8.0 Functionality

The ability to associate customers to Accounts Receivable Reps and then filter by these AR Reps in the AR Console and in AR Reports.
  1. Added AR Rep to customer screen, AR Console customer list and AR Console task list
  2. Added quick filter control to AR Console task list
  3. Added 'Assigned to' employee to AR Tasks and support the filtering of 'AR Rep' and 'Assigned to'
  4. Added AR Rep to Customer Bulk Updates
  5. Added AR Rep as a filter on the customer list and any report that uses an advanced customer filter such as the AR Aging report
  6. Added functionality to support a follow up call.
  7. Added Current Balance, Past due Balance, Balance, and Unapplied Balance to the task list to easily identify overdue accounts
  8. Added Past due balance to the task edit screen to easily identify if the account is overdue
  9. Added a hyperlink and/or button to quickly navigate from a selected task to the selected task's customer in the account view.

On Hold Code Stamps

Existing Functionality
Only support one 'On Hold' stamp

Existing Functionality Problems
User can't see from the header screen the specific on hold code

8.0 functionality

The ability to see specific on hold code text on the header screen for sales orders, sales invoices, and service calls as the customer is entered.
  1. Added the option to add the on hold code description to the stamp text on the customer, sales order, sales invoices, service call edit and service call invoice screens. The stamp text will be restricted to the first 24 characters of the on hold code description. Any spaces between words will be converted to new lines. Any trailing spaces will be truncated.
  2. The text "On Hold" will automatically appear as the first two words of the stamp. If the user chooses to not add the description, the stamp text will only be "On Hold".
  3. Added the ability to specify the color of the stamp
  4. Upon upgrade all on hold codes will be upgraded to display the first 24 characters of the description and the color will be red with the exception of the system defined 'PA-Parts Available' on hold code which will be upgraded to be green.

View cashbook reconcile report from cashbook reconcile window

The cashbook reconcile process is currently difficult to use. In order to reconcile an account, print the report, and finish, the user must close the cashbook reconcile window, open the report, and then reopen the cashbook reconcile window. This is time consuming and requires training to properly use. It is also easy for users to forget a piece of the process. If the user forgets to print out the report before finishing the process, it is not possible to print the report at a later time.
  1. The ability to view or print the reconciliation report while working in the cashbook reconciliation window.
    1. Existing Functionality
      You must currently leave the cashbook reconciliation window, view or print the report, and then reopen the cashbook reconciliation window. This takes time, and it is easy to forget to print the reconciliation report.
  2. Once the reconciliation process is finished, there's not a way to print the report if they forgot to print it before finishing. A warning should be present that the report cannot be printed later.
    1. Existing Functionality
      There is no existing functionality. It's easy for a user to get into an undesirable situation.
  3. Users require training about how to properly use the "Finish later", "Finish", and "Close" buttons. These buttons should be renamed, and their functionality changed slightly, to be clearer to the user.
    1. Existing Functionality
      The existing functionality can be confusing.

8.0 functionality

These problems were fixed by adding a print button to the reconcile window and changing the "Finish Later" and "Finish Now" buttons to read "Save" and "Finalize." Several warnings will come up reminding the user to save and print the report because it will not be available later.
  1. Added print button to reconcile cashbook account window. Clicking the button will generate the report using RPF. The statement date will default to the ending date being used to filter the lists. The report will be generated for the selected account. If there are pending changes which have not been saved, the user will be shown a message prompting them to Save/Cancel.
  2. Added a Save/Cancel dialog which will appear each time the user changes accounts with pending changes.
  3. Added a confirmation when the user clicks Finalize. It should contain a warning to the user that they will not be able to print the report once they finalize.
  4. The finish and finish later buttons have been modified to become Save and Finalize. These buttons do not close the form like they currently do. The save button saves all pending changes, and will only be enabled if there are changes to be saved. The Finalize button acts the same as the Finish button currently, and reset the deposits and payments lists rather than close the form.
  5. Added a Yes/No/Cancel dialog when Close is clicked with pending changes. This will allow the user to save the changes, not save the changes, or not exit the form.

GL Void Confirmation of Date

When an invoice is voided in the system, the void date is the same as the original invoice date.

Existing Functionality
  1. There is not currently a way to alter the date of the void.

8.0 functionality

When a user voids an invoice the date of the void is the same as the date of the invoice. This date and period is displayed to the user in the void confirmation message. A user can change this date when desired.
  1. Added system options to allow the user to choose the void date, to modify the voiding date, and to default the void date, with options of original transaction date, and today's date. These options are placed on a new option menu for General Ledger. User are allowed to choose the void date between the original transaction date and today's date. User is allowed to manually enter a different date into the voiding date picker.
  2. The user can select a date for the void. This applied to the areas listed below. This date must be on, or after, the original transaction date.
    If the option of choosing or modifying the void date is turned off, the relevant controls will not appear.
    1. Sales invoices
    2. Service invoices
    3. Contract invoices
    4. Contract accruals
    5. AP invoices
    6. Misc charge invoices
    7. Misc charge credit memos
    8. Misc charge debit memos
    9. Customer payments
    10. Consolidated billings
    11. Cashbook transactions
    12. Fixed asset transactions
    13. GL journal entries
  3. The void date and GL period are displayed to the user along with the void confirmation.

Add Notes to AR Receipts

Notes are needed in the AR Receipts screen. The main functionality is already there for another form, all that is needed is to extend the existing AR Receipts screen and add the required DB tables to use the "notes infrastructure".

Existing Functionality Problems
  1. The ability does not exist to add/review notes for AR Receipts.

8.0 Functionality
  1. Added a notes icon to the bottom left hand corner of the AR Receipts screen which will show the standard system notes form when clicked.
  2. A notes button will also show up in the toolbar for lists which contain the receipts in keeping with standard system capabilities.

Print AP check stubs in the order of the vendor invoice numbers

AP check stubs currently print in the order of their e-automate voucher numbers. It would be much better to change the ordering to be by the vendor's invoice number.

Existing Functionality Problems
  1. It takes a lot of time for e-a customers and their vendors to find checks for a specific invoice.

8.0 Functionality
  1. Added the ability to print AP check stubs in vendor invoice number order.

Exclude Freight from Term Discount Calculations When Paying Vendors

Currently, e-automate is calculating the term discount on the freight amount on Purchase order Invoices and Vendor Invoices. The freight amounts should be excluded from the term discounts.

Existing Functionality
  1. Instead of using the discount on the setup of the vendor record, user uses the discount area for each line item on the invoice. Or, user enters freight as a separate invoice and adds "f" at the end of the invoice number. This will calculate the discounts automatically. On the freight invoice enter the same due date without any discounts.

Existing Functionality Problems
  1. Inefficient and counterintuitive steps required to keep term discounts from applying to the freight costs.

8.0 Functionality
  1. The ability to exclude freight when calculating term discounts for vendors has been added.

Apply CM to Multiple Invoices

Currently, a user has to create a zero dollar payment in order to apply a credit memo to multiple invoices. This process needs to be simpler. A screen could be created very much like the "Apply Payment" screen, which would automate the process and would create the zero dollar Payment behind the scenes. A new transaction type can be created for the "payment" to separate it from other payments. This way in lists it would show as a split application.

Existing Functionality
  1. Currently you have to do a $0 payment to pull in the credit to apply it to multiple invoices. This is inefficient and counterintuitive step required to apply a CM to multiple invoices.

8.0 Functionality
  1. The user needs to be able to quickly apply a single Credit Memo to multiple invoices. This will have the same basic functionality as the Apply Payment Screen. You will be able to choose a customer and a credit memo. You will then be able to add the invoices in which to apply the credit memo. Behind the scenes a zero dollar payment will be created to facilitate the application.

View invoice notes from AR Console

The user needs to be able to add/view notes of invoices from the AR Console. The notes functionality exists on the invoices but in order to access them the user has to open the invoices one at a time. In other consoles (IE Sales Invoice Console) the user has the ability of checking notes directly, so the same feature will be extended to the AR Console.

Existing Functionality
  1. Currently the notes accessibility exists in other lists, and would be good to have "instant access" to the notes instead of having to open items one by one.

Existing Functionality Problems
  1. Since the notes are not directly accessible from the console, users have been working around by entering tasks for the invoices. This needs users to mark the task as completed. Whether they close the task or not this is not the reason they were created.

8.0 Functionality
  1. Added ability to access the invoice notes directly from the AR Console from a right-click context menu.

Contract Catch-up Billing

  1. Existing Functionality Problems
    e-automate does not currently support catch up billing on one invoice rather e-automate will create one invoice for each past billing period

8.0 Functionality
Added the ability to allow for more than one billing cycle to be billed and presented on an invoice.
  1. Automatically bill all past periods to current billing cycle for both base and overage
    1. For base, if multiple periods are being billed then the base rate will be multiplied by the number of periods billed. Prorated base periods will also be accounted for.
    2. For overage, if multiple periods are being billed the covered copies allowance will be multiplied by the number of periods billed. Prorated overage periods will also be accounted for.
  2. Separately for base and overages, invoice indicates dates of past and current billing periods in one extended date range and in one total charge
  3. Allow or disallow catch up billing on the contract. Billing tab and then driven from the settings on the contract type.

Contract Invoice Preview

  1. Existing Functionality
    Users can preview a contract invoice in the contract billing queue
  2. Existing Functionality Problems
    Contract invoice security and multiple clicks are required to use the billing queue.

8.0 Functionality
The ability to preview the invoice once a contract is created.
  1. Adding a right-click option to the contract list titled 'Preview next invoice' once selected:
    1. Ask for a billing cutoff date
    2. Check for group billing
    3. Do all the billing validation
    4. Do all the standard billing calculations including sales tax calculations
    5. Show errors and warnings and allow user to resolve
    6. Show invoice format selection screen
    7. Show a preview of the invoice in the specific invoice formats specified on the contracts invoice format code
    8. Each invoice format will support a preview mode that will pull data from the billing queue
  2. This preview action will actually put the contract in the billing queue temporarily and it should be transparent to the user. If for some reason it gets left in there, a user can go to the contract billing queue clear screen to delete them. In addition, logic will be added to check and delete orphans anytime any user previews any contract or creates a contract billing queue list. Also, when the auto invoice contracts e-agent task is built it will check and delete orphans as well.

Contract Miscellaneous Items

  1. Existing Functionality Problems
    The system currently supports one miscellaneous charge per contract.

8.0 Functionality
Adding unlimited miscellaneous charges on a contract
  1. Add multiple miscellaneous charges to the contract header and contract equipment detail screens
  2. New Contract Misc. Charge codes will be supported for quicker entry of charges and better support for reporting. These charge codes will be required. Dealers upgrading to version 8.0 that already have misc. charges will be required to select a charge code upon editing the current misc. charges on contracts; however, these charge codes will only be required for existing charges if an edit is required. Current misc. charges will continue to bill correctly without charge codes. These codes will contain a description, GL Account, GL Department, and tax flag.
  3. Each charge will be associated with either the base or overage cycle if you choose a date range. If you don't choose a date range a charge can be associated with base and or overage cycles
  4. On the invoice charges will be automatically prorated if the start or end date fall within the billing dates (base or overage)
  5. Each charge will support a charge code, description, start date, end date, GL account, GL Dept, Branch, Division, notes, source notes (read only), tax flag, bill with, quantity, price, amount and tax code.
  6. Expired charges will be hidden by default on the contract but can be optionally displayed by checking a checkbox

Contract invoice Formats/Definitions

  1. Existing Functionality
    Currently the system supports one report definition file and one export format for all contracts
  2. Existing Functionality Problems
    The one file becomes cumbersome when customizing to support many different formats. Additional invoice formats can be set up but they are not associated to the contract so they cannot be automated. In addition, additional excel formats are not supported

8.0 Functionality
Enhance contract invoicing module to support multiple report definition files. Each contract has its own set of report definitions via an invoice report group which includes a primary invoice definition for all printing, viewing, emailing and well as multiple additional report definition files for emailing.
  1. Allows users to configure additional report definition files. Supports the ability to identify each report definition by a name and description.
  2. Allows users to bundle the report definition into Invoice Report Groups and assign them to contracts
  3. Modified contract group billing to group based on Invoice Report Group in addition to existing grouping requirements. Stored the report definitions on each historical transaction so future invoice report group changes don't affect the history.
  4. Modified the batch viewing logic to facilitate viewing each distinct primary report definition.
  5. Allows for an AR Contact and send method override on Contracts. If there is no AR Contact defined on the contract the AR Contact on the Bill To customer will be used.
  6. Extended contact email address field to support many more characters which will allow the email field to handle multiple email addresses using the semicolon address separator.
  7. Ensured emailing in the EA and eAgent systems refer to the supplemental report definitions. For example, upon emailing from the AR Console the system would first create a pdf for the primary report definition stored on the invoice and then create multiple excel/pdf files from the supplemental report definitions which are also stored on the invoice (i.e. one contract could be setup to send one pdf file and 3 excel files).
  8. Customers using e-info will be sent these supplemental report definitions if they request that a particular invoice be sent to them. They will get the primary pdf definition and all supplemental definitions.
  9. Added the ability to edit the report definitions on contract invoices

Contract Item Coverage Availability

Existing Functionality
A dealer finalizes a proposal to provide all compatible toner for a local client, with the exception of one copier in the Marketing department which requires OEM toner. As the client makes online toner orders and as they call in to make toner orders, only the appropriate toner cartridges should appear based on specific machines (i.e. Compatible toner should be the only toner available to order unless the one Marketing exception machine is identified) This is currently unavailable.

8.0 Functionality

Provided ability to filter the availability of parts and supplies on contracts based on settings associated with the bill code.
  1. The bill codes have been split into a parts coverage code and supplies coverage code which will allow easier management of parts and supplies coverage combinations and exceptions. The bill code has been used to identify the correct parts and supplies coverage codes for equipment on contract.
  2. For both parts and supplies coverage codes, the following functionality has been added:
    1. The ability to control what is allowed (Visible) in addition to what is covered (Zero cost).
    2. The ability to add item inclusion exceptions in addition to the currently supported item exclusion exceptions
    3. The ability to test the coverage codes
    4. The ability to filter the service codes and item exceptions by the allowed and covered settings.
  3. Added a View Item Coverage button on the contract equipment screen to allow users to see the items that are allowed and/or covered for that piece of equipment on the contract
  4. Added a bill code column to the equipment list on the contract screen
  5. Enhanced sales order entry, sales invoice order entry, and e-info order entry to take into account the new 'Allowed' setting in addition to the new item inclusions functionality defined on the parts and supplies coverage codes

Enhanced Contract Proration

  1. Existing Functionality Problems
    Contract users have to manually modify the contract to get it pro-rated correctly

8.0 Functionality
For new contracts or a contract re-write it is necessary to pro-rate some invoices. System now auto-calculates correct monthly rate and copies included in base for the prorated period.
  1. Added a prorate first and last billing checkbox to the contract screen. If checked then the entire contract will be prorated (i.e. Contract base rates, equipment base rates and covered copies) on the first or last billing.
  2. Now displays a prorated label next the base rates and covered copies stating that the first or last billing will be prorated and what the prorated value will be
  3. Changed the "Prorate last billing" checkbox to "Prorate last billing and issue credit" when expiring within a previously billed period.
  4. Enhanced the equipment proration screen by adding a meter list that supports the following:
    1. The entering of start meter readings
    2. The adding of meters to meter groups
    3. The setting or incrementing of the next covered copies for the next overage cycle
    4. The setting or incrementing of the prorated covered copies for the current overage cycle
  5. Enhanced the equipment proration screen by adding a meter list that supports the following:
    1. The entering of end meter readings
    2. The decrementing of the next covered copies for the next overage cycle
    3. The decrementing of the prorated covered copies for the current overage cycle
  6. A new screen pops up entitled Contract Renew/Revise which gives the user the following options
    1. Renew contract as of scheduled renewal date of X date
    2. Revise contract by expiring this contract early and create a new revised contract
    3. Current expiring contract
    4. Prorate last billing
    5. Prorate last billing and prorate (If revision date falls within the previously billed period)
    6. New revised contract
    7. Start date
    8. Maintain current billing cycle dates
    9. Prorate first billing
    10. Require ending meter readings on all equipment
  7. Changes have also been made to the billing audit report, contract invoice, e-views, GM reports, & analytics.

Add arrive button and status to dispatch console

There is currently a dispatch button and status available in the dispatch console, but no arrive button or status. This will add that.

Existing Functionality
  1. The dispatcher must open several forms to do this. This takes a lot of time which could be eliminated.

8.0 Functionality
  1. Added arrive button and right click to the dispatch console.
  2. Added arrive form which is displayed when arrive is selected.

Add usage to call back and call alert

Call back and call alert settings can be set for the system and overridden for models and equipment. Currently you can only set this up using a number of days. For high volume machines, or machines with greatly variable volumes, this method is not always accurate. This feature will add the option to set this up using meters as well.

Existing Functionality
  1. The current functionality uses a number of days rather than meters. The number of days can be adjusted down for high volume machines.

Existing Functionality Problems
  1. Using days does not account for high volume machines which have variable usage.

8.0 Functionality
  1. Added usage/meter to call back and call alert at the system level. Note: The usage/meter on call backs and call alerts will be based on the default meter.
  2. Added usage/meter to call back and call alert at the model level.
  3. Added usage/meter to call back and call alert at the equipment level.
  4. Call back report will take into account the usage in addition to number of days. Due to the fact that a meter reading is not always available to calculate this off of, the call back and call alert status will be determined in the following way:
    1. Use the current manner of calculating call back and call alert based on number of days to set the status.
    2. If the call is within the number of days, making it a call back, when the call is invoiced then check whether a meter reading is available. If there is no meter reading, leave the call back/alert set. If there is a meter reading, calculate based on the usage.
    3. When the call is invoiced and number of days is zero and usage is not, check whether there's a meter reading. If there is not a meter reading, it's not a call back or call alert. If there is, calculate based on the usage.
    4. Notes: Any calls which initially appear as callbacks due to number of days can be overridden to not be callbacks. These will not be modified to become callbacks again. Also, there is a way to override call back on calls which are callbacks due to usage.

Ability to do Equipment Change Orders

There is not currently a way to keep track of equipment which have been moved from one location to another. If there is any delay between when this move occurs and when the system is updated, information can get lost. In order to keep the system up to date more easily, there should be a way to track these moves. This is especially important in industries where equipment moves around on a regular basis, or when loaner equipment is placed with a customer.

A change order is a new e-automate entity which you use to track equipment location changes and information associated with the changes. You can use change orders to record information about equipment changing customer locations, equipment changing locations by moving from the customer back to the dealer, equipment changing locations by moving from the dealer to the customer, equipment changing locations due to loaner placement when equipment becomes inoperable.

Note that the functionality of this feature differs somewhat from custom functionality found in Remote Tech. This is due, in large part, to the time restrictions placed upon this feature. We feel that the feature outlined here provides beneficial functionality for nearly all e-automate users. Given the same time constraints, the current Remote Tech functionality cannot be integrated into e-automate in a way which provides nearly the benefit.

Existing Functionality Problems
  1. There is not currently a way to track this in e-automate.

8.0 Functionality
  1. Added the ability to create and edit change orders in e-automate.
  2. Added the ability to create and edit change order details in e-automate.
  3. Added the ability for 3rd party integrated mobile workforce solutions to create and edit change orders.

JIT Customer Order Inquirty

  1. Existing Functionality Problems
    Additional filtering (Equipment and Item) is required once the 'more info' list is opened

8.0 Functionality
Added the ability to quickly view from the sales order and sales invoice the history of a supply item on particular equipment.
  1. 'More info' list pre-populates based on item and equipment at the sales order/invoice detail and header screens

Roll-up Invoicing

  1. Existing Functionality
    Users can add line items in a particular order and manually rollup the pricing or create a custom report to rollup the pricing
  2. Existing Functionality Problems
    Users cannot rollup and/or hide line items without losing margin on the accessories or by using a custom report.

8.0 Functionality
This feature will allow parent-child relationships among line items on sales orders and sales invoices. The copier dealer industry has the need to be able to "roll up" line items into a parent item on sales orders/invoices for purposes of billing their customers and leasing companies. Currently, all items on the sales order/invoice appear on the printed sales order and sales invoice reports. This feature will allow line items to be hidden, and optionally have their prices aggregated into their parent line items.
  1. Adding line item roll up functionality on Sales Orders and Sales Invoices and support the following:
    1. Line items can be assigned to another single parent line item on the same entity, thus making it a child line item.
    2. Line items can be assigned multiple child line items on the same entity, thus making it a parent line item.
    3. A line item can be both a parent and a child.
    4. A line item cannot refer to itself, or make any circular references through parent child relationships.
    5. Items on a sales order in a parent-child relationship may be shipped separately, but must be fulfilled together at the same time
    6. A child line item's price can be set to have its price aggregate into its parent's price.
    7. Any line item can be set to be hidden when printed. It does not have to have a parent for this function; however, if it is hidden and has no parent, it cannot be a taxable item.
    8. A child item can have both of the above properties.
    9. Sales Orders and Sales Invoices will not print hidden items.
  2. Modifying e-info to display correctly when viewing the line items on a sales order or invoice

Pre-billing and Coupons

Existing Functionality Problems
  1. Currently there is no method of reversing pre-billed fulfillments.
  2. The pre-billing enable option is for all orders and needs to be restricted to only certain types of orders.
  3. Pre-billed invoices look the same as standard invoices thus coupon invoices would not be distinguishable.
  4. There is no easy way to reconcile the liability account.

8.0 Functionality
  1. Adding the ability to reverse fulfillments. With pre-billing, if you fulfill a completely pre-billed item there is no invoice generated with the fulfillment and no way to reverse the fulfillment. Added this ability like we did with purchase order receipts. Basically added a 'Reverse' feature to the sales order fulfillment screen
  2. Moved the Enable sales order pre-billing option to the sales order type so that dealers can restrict pre-billing to coupon sales orders

Notes Exist Field

  1. Existing Functionality Problems
    The user must currently open the notes for each entity to determine if they exist. It is very time consuming to open each entity to find the ones which contain notes.

8.0 Functionality
Notes are available many places throughout the product. They are used to hold various user data. Users may use notes to indicate a special state on an entity. With the new enhancements made, the ability to see the existence of a note without opening the note of each entity will allow users to quickly see where notes have been recorded.
  1. Added a "primary note exists" field to the following lists in the system. It will indicate (YES/blank) whether primary notes exist. This will be stored in the database on the entity.
  2. Added a "user notes count" field to the lists below.
    1. APVendors
    2. APVouchers
    3. ARCustomers
    4. ARInvoices
    5. CBAccounts
    6. CMContacts
    7. GLAccounts
    8. GLAssets
    9. GLBranches
    10. GLDepts
    11. ICItems
    12. ICJournals
    13. ICMakes
    14. ICModels
    15. ICRequests
    16. ICTransfers
    17. ICTransferOrders
    18. POOrders
    19. POQuotes
    20. POReceipts
    21. SCCalls (visible in dispatch console call list & service call list)
    22. SCContracts
    23. SCEquipments
    24. SCWorkOrders (visible in service call list)
    25. SHAgents
    26. SOFulfills
    27. SOOrders
    28. SOQuotes
    This will be a total count of the primary note, if it exists, plus all note details that exist. This will not count any note details which are PPN or EVENT note types. This field will be stored in the database on the entity, and will be kept in sync by the following triggers.
  3. Added AFTER triggers for INSERT, UPDATE, and DELETE which update the "primary note exists" and "user notes count" fields for an entity. This will filter out all PPN and EVENT note types.

Database Maintenance Tasks

  1. Customers need a way to automatically, as well as on demand, verify the integrity of their data.
    1. Existing Functionality
      This must currently be set up through SQL.
    2. Existing Functionality Problems
      Knowledge of SQL server best practices is required.
  2. Customers need a way to maintain acceptable performance of the system. They should be able to do this whenever they feel is necessary. The system should also do this automatically as often as DGI feels it is necessary (i.e. each time the system is upgraded to a newer version). The database should be checked to determine whether indexes need to be rebuilt, statistics rebuilt, or the stored procedure cache needs to be flushed.
    1. Existing Functionality
      There is not currently a way of doing this.
    2. Customers need documentation about how to properly maintain their SQL databases.

8.0 Functionality
  1. 1. Added the ability to run the "DBCC CheckDB" command from e-admin. The user has the ability to run this command with its options turned on or off for performance reasons.
  2. Added the ability to optionally run a consistency check before a backup is made. This consisted of adding a checkbox to the backup form each time a backup is prompted for in e-admin.
  3. Added the ability to optionally run a consistency check after a database is restored. This consisted of adding a checkbox to the restore form each time a database is restored in e-admin.
  4. E-admin currently contains the option to rebuild indexes in the database. This was changed to open an advanced maintenance window. This window allows the user to determine the tasks which should be performed to improve database performance (such as re-indexing, recreating statistics, flushing the stored procedure cache, etc). The options will default to checked if the system determines they are recommended. The user is able to choose all, some, or none of the recommendations to execute. These will execute in single user mode, and a backup is required before any changes occur.
  5. The above mentioned window will automatically display to the user each time a database is upgraded so they can choose what performance enhancements to apply.
  6. Added the ability to run the DBCC command, as well as the performance check, on a schedule from e-agent. This will output the results into a report which can be emailed to notify a user if performance could be improved or the database has become corrupt.
  7. Basic documentation was added to the training & documentation department which explains to the user the importance and use of each option, as to why they should or possibly should not be used.
  8. Added the ability to run the DBCC CheckDB command, as well as the performance check from e-agent. The performance check sends a report via email containing the results from the DBCC CheckDB command, as well as the recommendations from the performance check.

View Accessories Linked to Host Equipment

  1. Existing Functionality
    Accessories can be assembled to host equipment but accessories do not necessarily show they are assembled and not available unless the user transfers the accessories into a specific bin. In addition, the physical inventory report does not segregate assemble inventory under their respective host equipment
  2. Existing Functionality Problems
    It is difficult to tell what accessories are assembled and which ones are available

8.0 Functionality
  1. Added new 'Assembled' bin functionality. Modified Equip Builds, Transfers, Inv. Adjustments, Sales Orders, Sales Invoices, Sales Order Fulfillments to use this special bin when dealing with assembled inventory.
  2. Modify the Item Availability screen. Add the ability to:
    1. Add a branch filter that filters all data on the screen including the data on the tabs
    2. Add a root level warehouse type grouping to the inventory location view
    3. View accessories of serialized host equipment items
    4. View hosts of serialized items
    5. Add a right click option to show possible list of hosts for non-serialized items
  3. Modified the Physical Inventory Creation to add accessories as child line items to the host equipment. Items in the 'Assembled' bins will not show up on a count sheet separately unless they are orphaned accessories
  4. Modified the Inventory Location by Warehouse report to add accessories as child line items to the host equipment. Items in the 'Assembled' bins will not show up on a report separately unless they are orphaned accessories.
  5. Modified the quick entry transfer screen to include the warehouse on hand quantity and warehouse available quantity in the transfer from and transfer to sections.

e-Agent auto ILC task enhancement

Currently e-Agent will automatically run the ILC for you, taking all the default actions. However, there is no way to audit the actions taken.

Existing Functionality
  1. Currently the task operates and emails a notice but does not include details of actions taken in the notification.

Existing Functionality Problems
  1. Perhaps users need to review the actions to have confidence that the task is performing correctly.

8.0 Functionality
  1. e-Agent task has been modified so that it will email the details of the actions taken in the notification email.

Default "to" warehouse and bin on a transfer

When adding multiple items to a transfer in standard mode, default the "to" warehouse and "from" warehouse from the transfer header.

Existing Functionality Problems
  1. This must currently be done manually.

8.0 Functionality
  1. Added source and destination warehouses to the transfer header.
  2. Default has been set to the "to" warehouse from the transfer header.
  3. Default has been set to the "from" warehouse from the transfer header.

Show receipt date on serialized items in Inventory Availability view

The create date from the ICSerialNumbers table should be added to the inventory availability view. This needs to be in both the list and the tree view.

Existing Functionality Problems
  1. This information is currently available from other areas of the product but must be gathered from several places.

8.0 Functionality
  1. The receipt date of serialized items will now be displayed in the inventory availability view. This will be displayed in both the list and the tree view.

Notify if Quantity is available in another bin

When entering a sales transaction, if the requested quantity is not available in the specified bin, search for quantity in other bins in the warehouse and alert user if quantity is found.

Existing Functionality
  1. Currently, if you enter a quantity into the sales system, the system uses the Quantity in the ICItemWarehouses table. This is actually the quantity across all bins in that warehouse. However, if the requested quantity is available, the system does not allocate across multiple bins even if it would be necessary in order to pick up that quantity. Rather, the system will allocate all the requested quantity from the item's default bin. This is regardless of where in the warehouse the quantity actually exists. The system does not notify the user that the quantity is not actually in that bin.
    It appears the system assumes that if qty is available, it must be in the default bin. This is probably true for many people most of the time, but not for all the people all of the time. Despite the old adage, we can probably improve on this situation.
    Furthermore, the ILC won't touch the SO either. This appears to be a process loophole right now. Nobody (and no automation) is going to tell the user that there is quantity available but in a different bin. Presumably currently when the SO is picked it is up to the picker to figure out how to get the quantity. I can understand why this must be somewhat annoying for the picker and could result in errors or etc.

Existing Functionality Problems
  1. Sales transactions, particularly the sales orders, are left in a half-way state and require manual intervention in order to fulfill them.

8.0 Functionality
  1. When the requested quantity is not available in the specified bin, a screen will pop up alerting the user of this. This screen will pop up when the quantity specified can't be found in the specified location but can be found elsewhere in the warehouse. At the top will be a list of the bins in the warehouse. The bottom will have a bin distribution list with a proposed distribution. If the transaction required multiple bins in order to fulfill the quantity requested, the bin split will be proposed by selecting bins in pick order that contain the quantity needed. The user can modify the bin selection if they do not like the proposal, thus creating a custom bin proposal. Clicking "Yes" accepts the proposal and will close the window configuring the sales detail accordingly. Clicking "No" will reject the proposal and the system will continue to use the bin specified originally, even though it does not contain the required quantity. Clicking "Cancel" will terminate the pending addition of the sales line item.

Auto Estimate Meters in the Meter Entry Window

  1. When entering a meter reading for billing, you must manually calculate an appropriate estimate. This is time consuming, and error prone.
    1. Existing Functionality
      The estimated meter reading must be manually calculated.

    Existing Functionality Problems

      Manual calculation of meter estimates can take a lot of time, and is easy to do poorly, leading to errors.
  2. When a user goes to manually calculate a meter reading, they can't use the system calculator because it's not visible on the control.
    1. Existing Functionality
      The user must use the windows calculator, or something similar.

8.0 Functionality
The system now supports the option to automatically calculate an estimated meter reading based on existing meter readings or meter history.
  1. Added a system option to default the meter display to the calculated estimate
  2. Added the ability to calculate the meter estimate, based on either existing readings or meter history. This will occur when "Estimated" is selected as the meter source if the above mentioned option is enabled. The calculation will also occur when the user clicks the Estimate button. The meter display control will default to the calculated estimate, allowing the user to review and add the reading, or to change the reading. At least 2 readings are necessary in order to estimate the reading. If the readings do not span at least 3 months, or there aren't at least 3 readings, a message will be shown to the user to let them know that the estimate may be suspect due to insufficient data. The calculation details will be visible to the user via a panel which the user can view from the estimate button as well. The Estimate button will only be enabled if Estimated is selected as the meter source.
  3. Added the calculator to the meter display control.

Base Rates on Meter Groups

Put base rates on Meter Groups to make granularity of revenue distributions to the meter group level.

Existing Functionality
  1. Base rates exist at the contract level and on the equipment level.

Existing Functionality Problems
  1. Users cannot accurately report on profitability down to the meter group, nor control GL distributions at the meter group level. Base rate is not tied to covered copies.

Existing Functionality
  1. Only one field for covered copies is available.

Existing Functionality Problems
  1. Base rate must be changed prior to billing, and covered copies must be manually changed after billing to calculate overage for past cycle and still bill base for next cycle using a different overage.

8.0 Functionality
  1. Base rate can be specified on each Meter Group. Meter group base rate will be in addition to contract base rates or equipment base rate, not in place of. The total of the meter group base rates will show in a label on the base billing tab on the contract screen. Meter group rates will be specified by entering the covered copies and a base rate per copy, which will calculate the base rate for that meter group. Add rate schedule to meter group base rate.
  2. Added a label called "Billed covered copies" which will show the covered copies billed for the last cycle. Overage calculations should be based on this value. A button will be provided to bring up a form to change this value, in the case of conversions, or if they just want to manipulate the overage calculation for some reason. At each billing of base, the covered copies will be copied into billed covered copies. (Ref Case #2)
  3. Distributions has been moved from the contract types into their own code called "Base distribution codes". Overage types on the meter groups will be renamed "Overage distribution codes". Base Distribution Codes will be added. In lists and codes, prefix these with "Contract".
  4. Added distribution codes at the contract equipment level to override the contract type distribution code.
  5. Upgraded script creates and splits out Distributions Codes from current contract types. Provides functionality to merge Distribution Codes in e-automate.
  6. Unearned Revenue will be tracked for the meter group base rates. Meter groups will not be deleted when an unearned balance exists.
  7. Contact invoices will distribute the revenue for contract, equipment, and meter group base and overage rates according to the distribution codes specified. In addition, Contract Invoices will distribute meter group base amount to each equipment for equipment revenue allocation and equipment level taxing
  8. Audit report has been updated to show meter group base rates.
  9. Contract invoice has been updated to combine meter group rates with contract level base rates.
  10. Accruals process has been modified to use the new distribution codes, and account for meter group base rates.
  11. GL transaction details table has been updated to reflect changes.
  12. Contract profitability report has been updated to reflect changes.
  13. Contract Item Import Utility has been upgraded to support base rates at the meter group level.

Kitting for Purchasing and Sales

Provide support so that inventory kits may be defined which consist of a combination of separate inventory items. Kits can be included on purchase and sales orders as a single line item, however, the individual components will be tracked in inventory as separate items.

Existing Functionality

8.0 Functionality
  1. A kit, for purposes of this design is a single item which is made up of one or more separate components. The components themselves are individual items that can stand on their own. Assembly is the process of combining individual components into a kit, and disassembly is the process of breaking down a kit into individual components.
  2. Inventory
    1. Generally, kits are not managed in inventory by many point of sale customers. Kits are generally used only for purchasing and sales. There will not be a lot of changes to the Inventory Item Edit screen. The following minor changes will be introduced:
      1. Change the title of the Manufacturing tab to Assembly
      2. Change the current Manufacturing type field to Assembly type
      3. Currently the Manufacturing Type field contains the following options from the CoSystemCodes table: Assembled Kit; Parts Kit. These options will be enhanced to include the following:
        1. Assembled Kit
        2. Parts Kit
        3. Purchasing/Sales Kit
        This new type will be used to identify kits which are used only for either purchasing or sales. The existence of a Sales code and Inventory/Expense code will determine if the kit is available for sales and purchasing respectively.
      4. Move the Bill of Materials listing over to the left side of the dialog below the existing Manufacturing Type field.
      5. Add a new Assembly costs header over the existing costing fields and move them to the right side of the dialog
  3. Inventory Price Differences
    1. One of the issues related to purchasing and sales of kits when the components are tracked as individual inventory items is the cost/price difference of the individual components vs. kit. For the initial version of kitting support, the system will introduce a new system option for determining how the system handles this price/cost differential.
      1. Track price/cost difference on non-inventory kits
      By default this option will be set to true. When it is enabled the system will calculate the difference between the price/cost of the kit and the sum average cost of the components. This amount will be either credited or debited from the associated revenue or expense account for the non-inventory kit item as appropriate. When this system option is not enabled, we will dynamically allocate the price/cost of the item by taking each components weighted percentage of cost using the individual average cost of the components and applying the weighted percentage to the overall kit price/cost.
      In the future we would like to allow the users the ability to specify the percentage of the overall price/code for each individual component as well as potentially allow for specific adjustment accounts for the credit/debit rather than only using the existing expense and revenue accounts. However, this functionality will not be supported in this release.
  4. Purchasing
    1. The purchasing functionality will be updated to support the display of a kit part number, description and total kit price. These updates will need to be supported for both purchase orders and purchase bid requests. This design is based on the assumption that purchased kits are predefined by the vendor and not something that the user can create on an ad hoc basis.
      If a purchase order does not include any kitted items, there will be no changes to the existing form. However, when the purchase order does contain kitted items (i.e. Purchase Kits) we will display the kit line item but not any of the details. The individual details will be added to the purchase order object and saved in the database, but will not be visible on the purchase order. Additionally, the line number field will be changed to be a separate field stored in the database and will not use the internal DetailID field that is currently used. Existing purchase orders will need to be updated to support the new line number field.
      Additionally, the purchase order item screens will need to be updated to support the new kitting features. By default, purchase order items will continue to use the same screen. However, since the components of Purchasing Kits will be added to the purchase order object, as the user steps through the Purchase Order item screen they will see the individual components of the kit using this same screen. For component items, the screen will be read only and the user will not be able to modify any items on the dialog.
  5. Sales
    1. The sales functionality will be updated to support the display of a kit part number, description and kit details. This design is based on the assumption that sales kits are predefined and that in this version the user cannot create sales kits on an ad hoc basis.
      If a sales order does not include any kitted items, there will be no changes to the existing form. However, when the sales order does contain kitted items (i.e. Sales Kits) we will display the individual components of a kit using a legal style line numbering. For example, a Sale Kit might have a line number of 2 and the individual components of that kit will be added as line items with number of 2.1, 2.2, 2.3 etc. as shown below.
  6. Receiving
    1. The receiving functionality will be updated to support the display of kits and their detailed components for receiving purposes. This design is based on the assumption that for purchasing kits, all individual components are required to been seen and received.
      If a purchase order receipt does not include any kitted items, there will be no changes to the existing form. However, when the purchase order receipt does contain kitted items (i.e. Purchasing Kits) we will display the individual component items using a legal numbering style as described previously and shown below.
      The user will be able to select either the kit, or the individual components, for receiving. If the kit is selected, and the number received is input, this will prompt the user that the appropriate quantities of all components will be marked as received. If the user selects an individual component and changes the amount received, the system will validate this against the kit, warn the user, and update the number of kits received. The support screens for receiving will follow the same design constructs as outlined for purchasing and the purchase order item detail with the exception that component items will be editable for receiving purposes.
  7. Fulfillment
    1. The sales fulfillment functionality will also be updated to support sales of kits. This design is based on the assumption that sales kits are predefined and that in this version the user cannot create them on an ad hoc basis.
      The fulfillment screens should be able to support kitting as currently designed; there will be no changes to the existing forms. However, when the sales order does contain kitted items (i.e. Sales Kits) we will look at the possibility to update the fulfillment detail dialog for Sales Kits to include a line under availability showing the number of kits that could be assembled and sold. This will be calculated based on examining the available, unallocated components required to construct a kit. The implementation of this new availability line will be based on performance issues related to the calculation.

Service Call Bill in Increments

Provide support for service calls to have an incremental billing option where accrued time is allocated to minimal increments and then billed at the incremental rate.

Existing Functionality

8.0 Functionality
  1. E-automate now supports service calls to be billed in increments for both labor and the hourly portion of travel.
  2. All related charges under a given bill code for a service call are allowed to be aggregated prior to calculating the incremental billing.
  3. Support now exists to separate aggregation and incremental billing for standard labor, overtime labor, and travel related hourly charges.

Request Demo

Please fill out the form below so that we may have a sales representative contact you. If you would like to contact us, you may do so by sending us an email at or call 877-dgsolutions (877-347-6588)

* = Required Field




  • Digital Gateway, Inc.
    4626 North 300 West
    Suite 200
    Provo, UT 84604


  • Phone: 801-492-3576
  • Fax: 801-492-1704
  • Toll Free: 866-342-8392
  • Sales: 877-DG-SOLUTIONS (877-347-6588)
  • Customer Care: 866-DG-SUPPORT (866-347-8776)



  • Digital Gateway will be in the office except for the following holidays:
  • Memorial Day (Monday May 26th, 2014)
  • Independence Day (Friday July 4th, 2014)
  • Labor Day (Monday Sept 1st, 2014)
  • Thanksgiving (Thursday and Friday November 27th -28th, 2014)
  • Christmas (Wednesday and Thursday December 24th -25th, 2014)
  • New Year's Day (Thursday January 1st, 2015)