Understanding Major vs Minor Updates

It is important for customers to understand the difference between a major and minor update. Each of these types of updates requires a time commitment from the update team and it is essential for ERP Managers and teams to understand what is involved in a minor vs a major update. The following is a brief description of the differences:

Minor update - An update to a new version of the software. In DEACOM, minor releases receive a new minor build number in the last three digits of the build (e.g. 14.04.051 to 14.04.053). Testing a new minor build in a test environment can take up to several weeks for customers, based on how many bug fixes are included in the release and how many minor version numbers are between the original and updated versions. Deacom provides a user acceptance test script, deacom user acceptance test script.pdf, located in the DEACOM Production folder. Check it out!
Major update - An update to a new version of the software that includes significant system enhancements. In DEACOM, major releases receive a new major build number (e.g. 14.03.076 to 14.04.027). Testing a new major build in a test environment can take several weeks to several months for customers, based on the scope of the company's processes and which of those are impacted by the given updates. The file deacom user acceptance test script.pdf, is a standard DEACOM user test script and is found in the DEACOM Production folder.

Note: Regardless of whether a customer is performing a minor or a major update, it is essential to validate a company’s mission critical business processes with its own data prior to updating to mitigate the risk that is associated with updating.

The build number scheme in DEACOM is summarized as follows.

Major

Minor

Deacom builds update scripts into the DEACOM installer to populate any new fields or tables in a release. These programs ensure that customers do not need to manually create, or contract a consultant to create, externals to complete an update.

Trunk and branch build structure

Deacom utilizes a trunk and branch build structure, as outlined in the figure below:

Major Updates

When an organization decides to perform a major DEACOM update, it is critical that the new build is thoroughly tested against that company’s business processes. A rigorous testing process helps mitigate the risk involved with installing a new version of the ERP software.

It is recommended to complete user testing through a pilot testing program that consists of two distinct phases:

ERP Manager or ERP team reviews business processes and system functionality at a high-level - In this phase, a company’s ERP leaders review the new build to make sure the processes contained within the build will work for their organization. A checklist of what should be reviewed by the ERP team during a major update is provided below.
End users complete pilot testing of new version in parallel with the old version and provide the ERP team with feedback on their respective areas - These pilots should occur as necessary throughout the course of this phase. The goal is to have end users provide system feedback to the ERP team. In turn, the ERP team provides feedback to Deacom in case a new build is necessary to address issues that occurred during the testing. Having the end users complete the pilot testing helps promote buy-in for the update at all levels of the organization. A checklist of what should be reviewed by end users during a major update is provided below.

ERP team checklist

Refresh the data in the test system.
Ensure .ini file is pointing to the expected System database; and in that System database, dxcomp4 is pointing to expected Company and Documents databases.
Verify server information for new version of the software.
Verify workstation environments are compatible with new DEACOM version.
Review the release notes and system change log.
Review new system security options in detail to understand how this will impact User and User Group security settings (all new security options in a major release are set to "No" by default).
Test all BI reports.
Test all grid layout reports (e.g. reports run through Sales > Order Reporting).
Test all printed reports (e.g. batch tickets and invoices).
Test all printed part forms (e.g. lot labels and job labels).
Test all triggers setup in system and confirm they are firing.
Test all EDI transactions that are setup in the system.
Test the WMS setup.
Validate GL transaction postings and inventory postings for mission critical business processes.

End user checklist

Review previews and graphs on the home screen.
Test adding master data records (e.g. item masters and formulations).
Test all daily transactions (e.g. issuing materials to Jobs and inputting production).
Test all monthly transactions (e.g. accounting month end close).
Validate work flow processes.
Run all grid layout reports that are used on a daily basis (e.g. QC Summary report in Job Reporting).
Ensure that every Report and Part Form can print to the actual printer it will go to in the update DEACOM version.
Compare printed Reports and Part Forms from update version to those used in production.

Minor updates

When an organization decides to perform a minor DEACOM update, it is critical that the new build is tested against mission critical business processes. It is recommended to complete user testing in three steps, to cover all bases:

Test the basic, mission critical business processes within the system. A high-level overview of some mission critical business processes is outlined below.
Test any Tracker tickets that were addressed for the company.
Review the DEACOM change log, located in Help > View DEACOM Program Change Log, and test all mission critical business processes that may be impacted by the changes noted.

Mission critical business processes

Critical processes will be specific to the company performing the update and must be tested before performing an update. The below table is a high-level overview of some mission critical business processes that companies may wish to test prior to updating.

Category	Business Process to Test
Sales	Create a new Sales Order and validate the pricing rules and user calculations.
Sales	Ship a Sales Order. If applicable, ship a Sales Order through the Sales Calendar.
Sales	Invoice a Sales Order and validate the invoice report layout.
Sales	Receive the Sales Order payment for the transaction and validate all the GL and inventory postings for the transactions.
Sales	Create an inter-company transfer and validate the receipt of the inter-company transfer.
Purchasing	Create a new Purchase Order and validate the pricing rules.
Purchasing	Receive a Purchase Order and, if a QC test exists, validate that the inventory went into QC testing status.
Purchasing	Complete purchasing QC for a lot and validate that the inventory moves to regular inventory status.
Purchasing	Enter a vendor invoice.
Purchasing	Complete a check run and validate that the check prints correctly, process a manual check and validate that the check prints correctly. Validate all the GL postings and inventory transactions.
Inventory	Create a new formula revision.
Inventory	Adjust inventory on hand for a lot and validate the adjustment was processed correctly through a "Lots" report.
Inventory	Move inventory between locations and validate that the move was processed correctly through a "Lots" report.
Inventory	Complete the Pre-Staging and Final Staging transactions.
Production	Create a new Job and validate the custom BOM for the Job is correct. Print the batch ticket.
Production	Schedule Jobs through the Job Calendar.
Production	Issue materials to a Job and validate the inventory and GL postings associated with the transactions.
Production	Complete during production QC tests for the Job.
Production	Input production or close/relieve materials for the Job. If a post production QC group is assigned to the formulation, validate that the Lots are now in QC testing inventory status.
Production	Complete post production QC tests for the Job and verify that the inventory is now in regular inventory status.
Production	Print a COA, SDS, or other regulatory document for the completed inventory.
Accounting	Complete a journal entry.
EDI	Complete an EDI transaction and validate that the transaction is completed correctly.
WMS	Validate that the WMS successfully connects to the automation console.