W99200201 Muli Version M to N upgrade Procedures – January 2010
1 Scope
To confirm the processes involved in upgrading Muli Users on the old Version MP software to Version N.
2 Associated Objects
- Muli enhancements Version N
- Company setup.ods
- MAN 2
- W99200202 Existing Muli User introduction to Version N
3 New Hardware Platform - Operating System
Most Muli Users will require to upgrade their hardware. With Version N, Muli is utilising “Virtual Computer” technology to increase security and reliability. Both old and new systems need to work in parallel during the testing period. For details, see W9920003 [Set up Ubuntu Linux].
4 Issues to be completed in the old system prior to the conversion of data
We see Users having more than one conversion attempt so major conversion decisions are included in the old database to enable adjustment and reprocessing. Where appropriate, User changes from the standard will be carried forward through consecutive conversions.
- Company Structure (redefinition for consolidations of DB's)
- Allocations (review to new standard)
- New combined Supplier, Customer & Marketing Master Records
- Prior to starting the process, Muli will upgrade your existing applications to enable access and view of proposed new codes within your existing reporting system (upgrade step1)
Supplier Usage Validation (20.2)
3.1 Supplier Maintenance (03010)
3.2 Supplier Report (03020)
6.16 Customer Master Maintenance (06180)
6.17 Customer Report (06190)
2.1 Project Master (allowing new project No. to be allocated)
20.2 Project Listing
20.10.1 Set up new consolidations
9.11.1 Payroll Employee Codes
9.13.3 Payroll Allowance Codes
(Superannuation maintenance in Version N)
5 New Supplier Codes
The new organisation codes are now 6-long and combine the Customers, Marketing, Suppliers & Subcontractors.
Please see Man5518-User codes principles
- Run 20.10.2 to verify usage of old Suppliers
With Version N, Code 239 provides the basis for verifying Users
.1 Active (all category 1 - Suppliers must have a new 6-digit code inserted)
.2 Last transaction 2-5 years
.3 Last transaction 5-10 years
.4 Last transaction 10+ years *
.5 Order raised (more than 12 months ago)
.6 Marked by User as inactive *
.7 Mark deleted with transactions *By default on conversion
.8 Mark deleted no transactions (not transferred unless new code provided) - On running the verification, all Suppliers are initially set as an 8, then if transactions are found, then a lesser number is allocated. We propose Suppliers who stay as status 8 will not be moved across to Version N unless a new Supplier code has been inserted.
- Suppliers in 3,4,5 will be assumed to be old and converted with old code preceded with a [ (left square bracket). These suppliers will not appear in normal enquiries.
- On reviewing the report 3.2, if you wish to keep the Supplier, then change 6-digit Supplier code to a correct new form code.
- After the above analyses, we are providing an export of suppliers & customers to a spreadsheet to allow users a way to review/rationalise their company-wide codes by applying a “sort by ABN” which will group all the same legal identities regardless of initial codes entered, thus creating a good starting point.
- Remember: In the spreadsheet, do not delete any lines
- Set the codes colours For suppliers & Customers
- In this format, the Customers and Suppliers are separate line items and if the same organisation, must be given the same new code.
- Set Codes column to a fixed pitch font
- Sort by ABN first and resolve all companies with the same ABN
- Sort by old code and then work logically through changing remaining codes
- Sort by new code, check for duplication to ensure they are real duplications that are to be considered. We combine all suppliers with the same code (very good where suppliers have had a name change)*** The new codes process on the spreadsheet will need to be processed by a senior accounts person (not an owner or junior), as you need to be accurate as Muli does not have verification checking in the process.
Companies with the same ABN only may be given the same new code. (You may use 11111111111 as a substitute number to consolidate old (PRE ABN companies).
DO NOT DELETE any entries from the spreadsheet.
pass the spreadsheet back to Muli who will then insert the new code into your existing database.
- Use 3.1 (Supplier Maintenance) to change individual codes.
-
Run 6.17 (Customer Master Maintenance) to manually insert new Customer Codes.
Remember Customer & Suppliers will be combined into a common Organisations file.
Rules as per Suppliers.
- Remember: In the spreadsheet, do not delete any lines
6 RPC's, Login, Payroll, ToDo
Muli is using using a 6-digit code also (lower case) with a separate 6-digit camel case representation for the new system.
Take the first 4-characters of the family name followed by the first 2-characters of the given name ir if only initials, use them.
ie: SkeoRo = Skeoch Ron
Like all rules they need to be broken to ensure we achieve unique keys for all RPC, but where required, please just change the last 1 or 2 characters
The new 6-character code will be used for both login, payroll and default email address.
All payroll people will have a RPC, however some may not be allowed to log in. To distinguish Organisation and RPC codes, RPC codes are displayed in CamelCase.
7 Region Code
Version N relies heavily on the region code for providing appropriate enquiries. We have developed a routine to set ORGS Region Code based on the postcode. This should provide a 95% accurate first pass.
8 Confirm and set up proposed Database Company Consolidations
Use 20.10.1 to set up new consolidations. The new database structure allows for up to 35 companies (1-9,A-Z) with each company having up to 26 profit centres with profit centre Z reserved for overheads. In some cases there will be split conversion as only overheads must go to profit center Z. With project numbering forced as ?ZYY000 - ? = company, YY the financial year end.
9 Confirm Project Number
If you want to use the default consolidations or change project numbers, then you may enter specific new project numbers to field 52 on the Project Master of individual projects.
All Overhead projects must use Profit Centre Z.
10 Payroll
The payroll system has been rewritten and as such there is a need to setup all employees in the new system.
-
Payroll Employee Codes
The key employee master data is coming over to the RPC record however the employee controls have been expanded and will need to be updated. It is the employee master detail (not RPC data that is being migrated)
A PAYG Payment Summary (Group Certificate) will be issued on the old system for all pays up to the changeover date and at the end of the year a second group certificate will be issued for the balance of year. Prior to each conversion you need to establish a new company structure spreadsheet.
New Database | Company | Profit Centre | Old Profit Centre | Company Name | Profit Centre NameThe 6 Character Employee code is used as the login RPC code
- Enable change of employee code for new system 09101
- Separate terminated flag as RPC/Employees are allowed to be re-employed using the same code Therefore RPC's may come and go from F3 enquires.
- (Can/ do we allow consolidation of old payroll codes?? - Common new code)
- restart payrun number greater than existing. -
Payroll sequence Codes
To enable the expanding needs for payroll management the range and controls of payroll codes has been increased from a maximum of 9000 to 26000 requiring ALL employees to have a new allowance code structure.
-
Payroll Superannuation Set-up
[Where you wish to use the new Direct Deposit Superannuation Payments for seldom used recipients, these will need to be set up in Version N]
-
Leave setup
Leave management has been rewritten to allow management of up to 6 Leave types.
All leave has to be setup with new opening balances.
-
Labour Orders
Existing project labour orders will continue to be used, however new accounting interface labour orders will be raised to enable easier verification at the end of year.
-
Payroll change over (Group certificates)
All employees will be issued 2 group certificates for the year
- one from existing system
- one from Version N MuliPrior to completing the old system group certificates, you will be upgraded to enable maintenance of company defined or extracted values for:
- FB provided
- Salary sacrifice - Maternity leave Payroll Validation
It is important to achieve a staged verification of Payroll that involves converting all RPC's, then setting up all payroll data. Then take a copy to reduce subsequence re-keying before processing a couple of dummy payrun to verify all new payroll processes.
11 Data Conversion by Muli
In Version MP, data is stored in ISAM files. In Version N we use PostgreSQL. There is a major change in data management and processing.
After conversion users may log in on new system and test same.
Data conversion is a major exercise undertaken by Muli where all transactions are read in the old system, substitutions established in the control files and then the new record are written.
Where there are multiple database all local order numbers, folio numbers etc. have to be adjusted by given values so that all transactions on the new system have unique numbers.
Once the basic conversion is completed users will be able to start testing and validate that the new system is working correctly.
The majority of conversion controls are inserted into the old system to enable reprocessing of the latest data, prior to the user going have on the new system.
Remember once real data is processed in the new Version N, there is no going back!
