System Configuration

• 1: Initial Setup
• 2: Financial Ledgers
• 3: Manufacturing
• 4: Logistics
• 5: Contacts
• 6: CRM Setup
• 7: Documents
• 8: Users
• 9: 2FA with Twilio Verify
• 10: Model Customisation

1 - Initial Setup

The Setup Menu

The system is configured using the Setup menu. When first installed the system has one user called ‘admin’ with the password ‘admin’. This should be changed as soon as possible after installation to something more appropriate.

System Company

The first thing to do is to go to Setup > System Admin > System Companies to set up the details for the base system company - there will already be a dummy company set up, but the details should be changed to match those of your organisation by clicking on the company name link in the companies list - then by clicking the company name link you can edit the details of the company. At this point you can add the following information to the system company:

Phone numbers, Addresses and email contacts

The system company can have multiple addresses, phone and email contacts. If you set up multiple addresses they can later be assigned to warehouses to provide distinct delivery address details in the warehouse management system. Email contacts can also be set with two in particular having special significance

• REMITTANCE - becomes the return email when bulk sending remittance advices from the batch payment routines
• STATEMENT - the default return address when issuing statements

People

Employees can be set up under the system company and can be linked to users, if required. People set up in this way can then be linked as employees if the HR system is used at a later date.

System Company Options

Returning to the View System Company screen, and by using the side bar option Edit [Company Name], you can edit the options for the System Company - one important option is to change the company logo which can be uploaded by clicking the button. It is also possible within this section to switch off certain modules completely, although you probably don’t want to do this at this stage.

Roles and Users

uzERP has a role based system where access to functions within the system is set up under a role. Users are then assigned a role which gives them access to the functionality required to do their job. Initially uzERP has one ‘Adminstrator’ role and one user - ‘Admin’.

Go to the Setup > Admin menu where there are two options:

Roles

Under this option click ‘New’ or ‘New Role’ in the sidebar. If editing a previously set up role click the role name in the list.

The role will need a name and, optionally, a description. You can choose to allow this user to manage uzLETs on their home or module pages by checking the option.

Down the right side of the screen is a list of permissions by module - which gives access to the main functions of the system and corresponds to the top level menu. By checking the appropriate option you can allow or disallow access to that particular module. The list is extensive and has a tree structure giving access to lower level functions under each module.

If you have already set up users you can use the multi-select box to allocate users to this role.

Users

Under this option click New or New User in the sidebar. If editing a previously set up user click the role name in the list. Each user MUST have a username - this is case sensitive. If you have set ‘people’ under the system company the user can be allocated to a person.

The user must then be given a password and role, and linked to a system company. If the user is not linked to a person then an email address can be added (although this is optional).

Setting up email

A return email address for the user is required. This can be one of the following:

1. the email address in the user’s details
2. the email address for the person linked to the user’s details
3. If the user is allowed to send statements and/or remittances, then either the above needs to be done, or a general STATEMENT or REMITTANCE email address needs to be set up under the system company.

Printing

If a CUPS Print Server is installed and configured, uzERP will discover CUPS advertised network printers and add them to the available printers list.

The majority of uzERP outputs can be sent directly to a PDF file that opens in the browser and can be sent to any printer accessible from the local client PC, etc. This is useful where direct printing is not possible.

2 - Financial Ledgers

Introduction

If you decide to use any of the Logistics or Accounting functionality then various options within Ledger setup need to be activated. As with any large system uzERP is flexible and a certain amount of pre-planning and testing will be necessary to get the system working how you would like. The order in which you do things in the set up phase is quite important and this document follows the order that you should use when setting up the ledgers part of the system.

The “Starter” database is a working system and has the options outlined already populated - you can then change these to suit.

General Ledger

GL Summary and Analysis Codes (Optional)

GL Summary and Analysis codes allow for the grouping of entries and balances within the General Ledger for reporting purposes. The structure of these codes is a one to many relationship between the three tables such that one GL Summary code relates to many GL Analysis codes…. and one GL Analysis code relates to many GL account codes. In this way the grouping can lend itself to any number of user defined reporting formats.

• GL Summary Codes - used to analyse accounting data at the highest level, these can be grouped together for the highest level analysis

• GL Analysis Codes - a lower level analysis of GL balances for reporting Check out the sample data at http://demo.uzerp.com to get some ideas.

GL Account Codes - The Chart of Accounts

GL Account codes represent the chart of accounts for the system. Codes are split between Balance Sheet and Proft & Loss account and certain balance sheet codes will be be designated control accounts. If a GL Account code is designated as a control account, manual General Ledger Journal postings to this code are not allowed as ALL of the postings will be coming from a subsidiary ledger (Purchase Ledger, Sales Ledger, Cash Book) or process such as VAT processing.

Balance sheet codes

• Retained profits
• Purchase ledger control
• Sales Ledger control
• VAT input tax control
• VAT output tax control
• VAT control
• VAT EU/Intrastat control
• At least code to represent a bank account

Profit and Loss

• A code for writing off currency differences

You are free to choose the nomenclature for the codes but they must exist and be unique and ALL, with the exception of retained profits and the currency differences code, should be set up as balance sheet control accounts.

All other GL Account codes are optional and should be set up in line with the chart of accounts you require. The GL Summary and Analysis codes help to analyse costs and balances in the ledger.

GL Cost Centres

Cost centres are used for further analysis of entries in the General ledger. For example a departmental analysis of costs and revenue could be produced by allocating entries against the relevant costs centres and GL account codes.

When entering a GL cost centre you need to specify the GL account codes that are valid for that GL cost centre. This will then limit the choices offered when making entries to the system so that only costs and revenue types expected are logged against the relevant GL cost centres. If using only one cost centre then make sure all codes are valid for that centre otherwise you will not be able to enter transactions correctly.

GL Periods

Each transaction within the General Ledger is allocated to a period based on the date of the transaction. The period set up is completely flexible in that the system can cope with any number of periods within the accounting year, for example 12 monthly periods, 13 four-weekly periods, or 4 quarterly periods.

When first setting up the system it is recommended that the periods that represent the first year are entered - from there on the system will always keep 12 future periods available. When setting up the periods you should also indicate which VAT period the transactions relate to - normally these will be quarterly periods.

Currencies

There must be at least one currency for the system to function properly - this is known as the base currency. In addition the system will allow you to set up any currency you trade in and enter a conversion rate with the base currency. The fields for currency entry are:

• Currency - short code for the currency that appears in dropdowns - e.g. USD
• Description - long description e.g. US Dollar
• Symbol - the currency symbol for invoices etc e.g. $
• Decdesc - the description of the decimal e.g. cent
• Rate - the rate with respect to the base currency (obviously 1 for the base currency)
• Writeoff Glmaster - where currency write offs are posted in the GL transactions table
• Revalue Glmaster - where currency revaluations are posted in the GL transactions table
• Glcentre - the gl centre code for write offs and revaluations
• Datectrl - if this currency is subject to date control (this feature not yet implemented and will be ignored)
• Method - how to convert between base and this currency, i.e. divide or multiply.

GL Parameters

The General Ledger parameter section specify how the system works, and provides defaults for background processing.

• Balance Sheet Cost Centre – the default GL cost centre used in posting control accounts
• Base Currency – company base currency
• Number of periods in year – determines which period close triggers a year end
• Number of weeks in year – used in asset register to calculate depreciation (not yet implemented)
• P&L Account Centre – default GL cost centre for P&L account transactions
• Purchase Ledger Control Account
• Retained Profits Account
• Sales Ledger Control Account
• Twin Currency – usually the Euro in the Eurozone. If twin currency not required set to the same as base currency
• VAT Control Account – used to prepare the VAT return and make VAT payments
• VAT Input – where VAT outputs should be posted
• VAT Output – where VAT inputs should be posted
• VAT EU acquisitions – if you want to report EU tax correctly this needs to be set up in the chart of accounts

Cash Book

Bank Accounts

For the system to function correctly there must be at least one bank account on the system. Each individual bank account must be allocated to a unique GL account code and this must already exist, and be set as a control account, before the bank account can be set up.

The bank accounts can be denominated in any currency that is used by the system, which obviously need to be in place before any other details can be entered.

The following information is required on entry

• Name - this is a mandatory field and is shown in all drop down boxes where a bank account entry is required
• Description - optional but concatenated in drop down boxes with name
• Bank Account Name
• Bank Name
• Bank Sort Code
• Bank Account Number
• Bank Address
• Bank Iban Number
• Bank Bic Code
• Currency - this is a mandatory field
• GL Account - this is a mandatory field
• Cost Centre - this is a mandatory field
• Statement Balance - this is a mandatory field
• Statement Page - this is a mandatory field

The balance field should be left at zero on entry.

Payment Types

At least one payment type is required - this is the transfer type for making transfers between accounts - in the default set up this will already be in the table. Other payment types can be entered as required.

There is the option enter a payment method against a payment type - this is used in the purchase ledger the determine the action to be taken when making a payment for a supplier who has this payment type set. At present there are two actions:

• Cheque Print
• BACS

If no method is set the type can still be used in purchase ledger but no automatic action will be taken.

In sales ledger the payment type has no effect beyond identifying the source of a receipt for reporting purposes.

Payment Terms

Payments terms are used in the sales and purchasing systems to determine when transactions are due for payment and whether discount should be applied.

• Description - for example 30 Days from Date of Invoice
• Basis - the basis of calculation of the due date either by reference to the Invoice date or Month end date
• Days - the number of days from the base day
• Months - the month end used in the base day
• Discount - a percentage which is used in Sales Ledger to calculate the settlement discount applicable to the transaction

Each Customer or Supplier is allocated a payment term from this list.

Examples:

Periodic Payments

Periodic payments can be used for standing orders, direct debits or items such as wages payments. The information required is as follows:

• Source *
• Company
• Person
• Bank Account *
• Currency *
• Payment Type *
• Tax Rate
• Frequency *
• Account
• Centre
• Description
• Ext Reference *
• Start Date *
• End Date
• Occurs
• Net Value
• Tax Value
• Gross Value
• Variable
• Write Variance

Tax

uzERP is designed around the requirements of the UK VAT system and tries to cater for this as much as possible through flexible tax periods, multiple product VAT rates and statuses for trading partners.

Tax Periods

In order to allow for flexible tax (VAT) reporting the system allows GL periods to be grouped into tax periods - these are set up in the GL Periods section where each GL period is allocated to a VAT period (usually a quarter). The transactions are then grouped together to allow for VAT reporting.

Tax Rate

In the UK, as in most EU jurisdictions, the tax rate is applied based on the category of product being bought or sold. Under this section you can enter the various VAT rates that apply to the products you sell. You can enter as many different rates as you wish for reporting purposes, each with a different rate if necessary. The details required for each rate are:

• Short code for the tax rate (Usually a single letter)
• Description
• Percentage the percentage of tax to apply (can be 0%)

Tax Statuses

In the UK the decision to apply tax is a combination of the tax on the product and the status of the trading partner (supplier or customer). The tax status determines whether tax is charged - this status is then used when setting up a trading partner in the purchase or sales ledger.

• Description - the description of the traders tax status
• Apply Tax - whether or not to apply any tax calculated from the product tax rate
• EU Tax - whether to include in the EU tax analysis for intrastat purposes

3 - Manufacturing

In common with many more expensive large scale systems, uzERP manufacturing management is very flexible and adapts well to different business models. A certain amount of pre-planning is strongly recommended to get the system working for your organisation.

Particular attention needs to be paid to the stock system. We suggest that a Stock Map is developed prior to implementation of the system. This will assist in defining the relationships between stores and locations and producing a view of how stock moves between them.

Warehouse Management

The warehouse management system is where the set up of Stores, Locations and Bins takes place. A Store can have many Locations, and a Location can have many (optional) Bins.

In addition the system uses a double-entry method to track stock - such that any movement affects two locations. For instance receipts of goods come from a purchase location into a stock location. For this reason some locations can be treated as No Balance locations.

Stores

A store usually represents a distinct warehouse or manufacturing site. There must be a least one store although you might decide to have a separate store for each site on which you do business, plus each facility within the site. Each store has a store code, description and address. The fist two are mandatory, with the address being selected from the range of addresses set up against the system company.

It is a good idea to relate the names of the facility and store, for example:

• BW - Bridgewater Warehouse
• FIN - Finished store
• NEW - New Works
• MAIN - Main warehouse

Locations

Locations sub-divide stores and are used for controlling and analysing stock, both numerically and financially. They show where the stock actually is, how it moves and where it sits around.

Bin Control

Bins sub-divide Locations. They may identify a rack and positions within the rack, or they may be just areas marked out on the floor. You don’t need to define bins in a location - especially if you have some other way to tell where things are.

It’s worth noting here that bin control is specified at the Location level. That is, you decide which Locations in each store are to be bin controlled. Every time a stock transaction addresses a bin-controlled location, the bin number will be requested by the system. If the location is not bin controlled, no bin is requested. This means that a store’s receiving or inspection areas needn’t be bin controlled while the raw material store could be.

Product Groups

Within the stock system Product Groups can be used for analysis. There must be at least one product group in the system as this is a mandatory field for each stock item. The database allows for a product group code AND description which can be used to group stock items for further analysis.

Type Codes

Type codes can also used to group stock for analysis purposes in conjunction with Product Groups.

However, the type code of an item is also used in conjunction with Actions to determine which actions are taken when specific procedures are called for a particular stock item when using manufacturing management or sub-contracting. In particular, actions control where stock is put on Works Order completion, whether parts used are backflushed and where to issue excess usage.

• Type code - a short code for the stock type
• Description - full description

The following fields affect the manufacturing processes:

• Completion Action - the action to be used when completing a works order this item type. This is used for manufactured items where you want to specify the action to move stock that has been made against a works order.
• Backflush action - if you wish to backflush the standard bill of materials for a manufactured item the action to be used to backflush parts is entered here.
• Issue action - the action to be used if manual issue of parts to a works order is required for this item type - used where backflushing is not in force AND to enable over/under usage bookings to works orders.

Unit of Measure

The UoMs section allows you to set up the units of measure applicable to your organization. These are used in the stock, ordering and invoicing systems. there must be at least one UoM for the system to function correctly. The system is delivered with default UoMs such as Kilogram, metre and gram.

Unit of Measure Conversions

uzERP allows you to define conversions between UoMs for use in the stock system. Once a UoM has been set up, you can specify default conversions between UoMs which will apply on a system wide basis. Obviously certain conversions are fixed e.g. a Kilo contains 1,000 grammes, but you can also specify here conversions that are unique to your company. For instance if you always supply your products in cases of 6 you could set up a UoM conversion such that CASE contains 6 PACKS.

Further flexibility is provided where different products have different UoM conversions since uzERP allows item-specific conversions to be entered during item setup. As long as the UoMs have been specified then the conversion can be set up.

Actions and Transfer Rules

Once the stock map is defined you need to set up the Stock Actions that describe how stock will move between locations. They are also referred to as Menu Actions because they can be made to appear on a appear on a menu.

Transfer Actions have four characteristics:

• Action name (short code, e.g. “Issue”)
• Description of what the action does (e.g. “Issue stock from warehouse to line-side”)
• Label for the movement (e.g. qty issued)
• Action Type

The Action Type determines the stock movements and additional processing for key operations as follows:

Setting the location for goods received

When goods are received against a purchase order they are automatically added to the stock balance at the location defined by the receive action for the order.

An action must be added with a type Receive - if you want to receive against an order the type must be Receive and there must be only one transfer rule for the action. Once added, select the action in question and in the side bar select Add Rule. The transfer rule for the action can then be added.

It is possible to have multiple receive actions so that stock can be received into different warehouse/location combinations. The option will appear in the Receive Into drop down on the order - you can default this by supplier so that goods received from that supplier will, by default, be received into a particular location using the supplier’s Receive Into option.

Making actions unavailable

An action can be made inactive by removing all of its transfer rules. For example, a company may have defined several receiving actions and now wants to ensure that one of those choices is not available when entering new purchase orders. Care should be taken that there are no open orders that need to use the action being changed.

Manufacturing Management

uzERP allows you to control many aspects of the manufacturing environment including specifying routes and operations for your products, managing shop floor paperwork, collecting data and reporting on manufacturing performance.

Departments and Workcentres

You can set up as many departments as your organisation requires and within each department you can set up multiple workcentres - these could represent groups of machines, a linked set of processes or a single machine station. Each workcentre can be allocated a recovery, or charge-out, rate to recover the cost into products.

Departments may have production recording enabled - this means that they are included in the production recording system and can have actual time recorded against them. This gives the flexibility to have a group of workcentres included on a route and therefore costed into a product, but not have actual time booked via the production recording system.

Resources

Most processes within a manufacturing environment consume resources. In uzERP a Resource is generally used for Operator grades who work on producing stock items. This allows the consumption of an Operator’s time to be costed into a product using the recovery rate for the resource.

4 - Logistics

Sales

TODO

Purchasing

Purchase Order Authorisation Limits

Purchasing authorisations are based on user name and a matrix of [[GL Account/Cost Centre|Setup/Ledger Setup]] combinations. A maximum value is then assigned to the authorisation limit. Each user can be allocated several limits across multiple centres giving a very fine grained level of control over the authorisation of expenditure.

When a purchase order is raised in uzERP it can be for either stocked or non-stocked items. It is possible to set up products that are purchased regularly via purchase order product lines although items to be bought can be entered directly onto the order.

Either way, a GL Account/Cost Centre combination is allocated to each line on the order. This authority limit determines who has authority to authorise the orders.

5 - Contacts

Contacts Setup

Menu: Setup > Contacts

There is a check box to set the preference for the auto creation of account numbers. Use this if you want system generated account numbers - if maintaining a link with legacy data it may be wise to enter historic, manual, account codes.

Contact Categories

Categories can be associated with a either Companies or People, or both. The following have some impact on how the system works

• Employee - if a person within the system company is marked as an employee then they will be available in the HR system
• Customer - an account marked as a customer will be available in the Sales Ledger (Accounts Receivable)
• Supplier - an account marked as a supplier will be available in the Purchase Ledger (Accounts Payable)

If you base your system on the starter database then Contact categories already has ‘Employee’, ‘Customer’ and ‘Supplier’ set up.

Other Information

Apart from the above there is little setup required in the contacts module beyond the optional classifications you require. The different sections you can use are:

• Company Classifications
• Company Industries
• Company Ratings
• Company Sources
• Company Statuses
• Company Types

6 - CRM Setup

Menu: Setup > CRM Setup

As with Contacts Setup, there is little to do in CRM setup beyond adding the optional classifications you require in the following areas:

• Opportunity Sources
• Opportunity Types
• Opportunity Statuses
• Activity Types
• Campaign Types
• Campaign Statuses

7 - Documents

This is where you can define custom document output

8 - Users

Post installation individual users must be added in using the Setup -> Admin -> Users -> New option.

In most organisations users represent a specific individual, therefore if you added employee ‘people’ records to the system company a user can be associated with an individual staff member. This is not obligatory as there may be some system ‘users’ that represent a group or department, for example ‘x_group’ or ‘cell_b’.

Each user gets a unique username and must be given a password. Their email can be entered here and if roles have been previously set up they can be allocated a role. Finally the system companies that they have access to must be highlighted.

9 - 2FA with Twilio Verify

Available Since release 1.31.0

What is Twilio Verify

Twilio Verify is a service that validates users after they have logged into uzERP with their username and password. Twilio Verify supports verification via SMS, voice, push message, etc. but uzERP only implements time-based one-time passwords (TOTP).

With TOTP, users enroll with Twilio and then use codes obtained from an app on their phone, computer or tablet. Some suitable apps are Authy and Google Authenticator.

Before configuring uzERP you will need to create an account and a Verify service with Twilio.

Configure uzERP for TOTP 2FA with Twilio

Set injector classes

• Set the LoginHandler class to HTMLFormLoginHandlerMFA.
• Add the MFAValidator class, if not present, and set it to TWValidator.

Add Twilio settings to the uzERP configuration file

Add the Twilio secrets to the config/.env file in uzERP:

# Example settings

TWILIO_ACCOUNT_SID="ACxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
TWILIO_AUTH_TOKEN="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
TWILIO_SERVICE_SID="VAxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"

Update PHP session management settings (optional)

Twilio will charge your account for each successful validation. uzERP session management can be configured with an appropriate user activity timeout and max age in seconds in the config/.env file.

The above settings should be chosen carefully to balance user convenience, security and cost based on your threat model.

# Example settings

# Let uzERP manage user session timeout and maximum age.
# If included and true, uzERP manages session age.

UZERP_MANAGE_USER_SESSIONS=true

# If UZERP_MANAGE_USER_SESSIONS is true, the following
# variables must be set.

USER_ACTIVITY_TIMEOUT_SECS=28800 #30 Mins = 1800
USER_SESSION_MAX_AGE_SECS=28800 #8 hours

User management with 2FA

The user database table includes some fields to support 2FA:

Verification can be disabled for the next user login from the Web UI and is automatically re-enabled once the user has been validated.

A user’s 2FA status can also be reset, which removes the mfa_sid and sets mfa_enrolled and mfa_enabled to false. The user is then required to re-enroll on their next login.

User enrollment

Once 2FA is enabled users will be required to enroll with the service using their chosen app.

When an un-enrolled user logs in with their usual username and password uzERP will obtain a new TOTP secret from Twilio and present a QR code and plaintext secret that the user can use to set-up their app. The app will then provide a code that the user must enter into uzERP for verification.

After successful verification the user will be logged in to uzERP. Once enrolled the user will need to enter a code from their app each time they login to uzERP.

10 - Model Customisation

Custom Sort in Lists

Since 1.9.2

The configuration for custom sort was moved from conf/custom-model-order.yml to conf/model-config.yml in release 1.9.2 and the configuration of custom model sorting was simplified.

The default sort for each data model is defined internally within the uzERP source code but views can be re-sorted by clicking on the headings. The default sort can be overridden by creating a model-config.yml file in the conf/ directory, when site users need a view to be sorted using an alternative column by default.

The custom sort orders defined in the YAML file are cached in the key <database-name>[model-config]. Each time the file is changed the cache key must be cleared for any changes to applied in uzERP (see Setup > Cache Management > Cache in the uzERP menu).

model-config.yml is a simple YAML file where the models and sort criteria can be defined under the key ModelOrder:

        ModelClassName:
            ModelOrder:
                field_name1: 'ASC|DESC'
                field_name2: 'ASC|DESC'
            ClickInfo:
                fields:
                    field_name1: 'Your Label'
                    field_name2: 'Another Label'
                methods:
                    model_method: 'Label'

Columns defined under ModelOrder are sorted in the order they are listed. The order direction (ascending = ASC, descending = DESC) for each column.

For example, suppose you wanted to sort Sales Order lists and CRM Activities using custom columns:

    SOrder:
        customer: 'DESC'
            order_number: 'DESC
    Activity:
            enddate: 'ASC'

Click Info

Since 1.9.2

Click info provides a way of showing additional information to the user in uzERP’s grids without having to click through to the underlying data view.

For example, users need to see the pickable stock balance from the Sales Order Product list. With the appropriate configuration users can click on an information icon next to the stock item link and the required information will be shown in a pop-up (see screenshot, below).

To make click info available for a linked model, define the fields and methods to call in the conf/model-config.yml file:

STItem:
    ClickInfo:
        fields:
            text1: 'MF Category'
            lead_time: 'Lead Time'
        methods:
            pickableBalance: 'Sales Stock'