Welcome to uzERP

• 1: Features
• 2: Quick Start
• 3: Installation
• 4: System Configuration
• 4.1: Initial Setup
• 4.2: Financial Ledgers
• 4.3: Manufacturing
• 4.4: Logistics
• 4.5: Contacts
• 4.6: CRM Setup
• 4.7: Documents
• 4.8: Users
• 4.9: 2FA with Twilio Verify
• 4.10: Model Customisation
• 5: Modules
• 5.1: Accounts
• 5.1.1: Cash Book
• 5.1.2: General Ledger
• 5.1.3: Payment Terms
• 5.1.4: Purchase Ledger
• 5.1.5: Purchase Ledger Batch Payment
• 5.1.6: Sales Ledger
• 5.1.7: VAT Module
• 5.2: Report Writer
• 5.3: Contacts
• 5.3.1: Accounts
• 5.3.2: Leads
• 5.3.3: People
• 5.4: Logistics
• 5.4.1: Delivery and Despatch Schedule
• 5.4.2: Despatch
• 5.4.3: Goods Received
• 5.4.4: Orders for Despatch
• 5.4.5: Purchase Invoice Register
• 5.4.6: Purchasing Order Processing
• 5.4.7: Sales Invoice Resgister
• 5.4.8: Sales Order Processing
• 5.5: Manufacturing
• 5.5.1: Warehousing and Stores
• 5.5.2: Stock
• 5.5.3: How to create a stock map
• 5.5.4: Works Orders
• 5.5.5: Backflushing
• 5.5.6: Production Recording
• 5.6: Quality
• 6: Frequently Asked Questions and How-to
• 6.1: Cash Book
• 6.2: Contacts
• 6.3: Copy Live Data to a Test System
• 6.4: Dashboard/Homepage
• 6.5: Data Export
• 6.6: Frequently Asked Questions
• 6.7: Goods Received
• 6.8: Power User/Developer
• 6.9: Purchase Ledger
• 6.10: Purchase Order Processing
• 6.11: Sales Ledger
• 6.12: Sales Order Processing
• 6.13: Stock
• 7: Glossary
• 8: Requirements

1 - Features

uzERP is an Open Source modular business system designed for Small and Medium sized Enterprises (SME) or owner managed businesses. The system has modules that touch every business function:

• Lead and Opportunity tracking
• Customer Relationship management (CRM) including Activities and Campaigns
• “Order to cash” processing for both the sales and purchase processes including trade counter operations
• Asset and Project management
• Accounting - Sales, Purchase and General Ledger plus Cash Book
• Manufacturing management including requirements planning and shop floor data collection
• Stock Management with multi location Warehousing
• HR - personnel details, holiday & training records
• Quality and customer service monitoring
• Engineering and Maintenance task tracking

The Open Source nature of uzERP means that a business can implement any modules that are applicable to their environment. uzERP comes with no licensing cost, organisations can implement uzERP in a phased way without the big bang approach needed to get a quick payback from traditional upfront licence fees.

The above is just a small subset of what uzERP can do. Why not check out the Demo online to get a flavour of what uzERP can do for your business.

Interface Design

uzERP is web based so is accessible from any PC or Mac using a web browser - no client software is required.

Progressive disclosure provides a rich user experience with drop down menus, context sensitive defaults and lists. uzERP’s clutter free workspace presents users with a familiar environment that can be navigated intuitively:

• List based displays provide a familiar ‘spreadsheet like’ interface to data
• All lists are searchable and printable meaning users can get the information they need quickly and easily
• In-list Links allow for progressive disclosure so users get the information they need quickly and intuitively
• A configurable and context sensitive sidebar provides access to more information or extra operations
• [[uzLETs|User-Manual/uzLETS]] provide desktop shortlists, graphs and quick links that put information right in front of users

2 - Quick Start

One-Click install

The quickest way to get up and running with a full uzERP install is to use the Digital Ocean Marketplace app.

If you already have a Digital Ocean account uzERP can be deployed with one-click onto the lowest tier for $5 per month.

See the uzERP application page on Digital Ocean for more information.

Once the droplet is deployed you can log into the starter instance with the username/password ‘admin’.

Next steps

You probably should secure uzERP so you connect using encrypted HTTPS traffic, the simplest way is to use a DigitalOcean load balancer and install a LetsEncrypt certificate.

From there go to the Initial Setup page to get started testing uzERP.

3 - Installation

The target OS for a uzERP is Ubuntu 18.04 - these instructions can be modified for other distributions (see requirements) but your mileage may vary.

Operating System

Create a basic 18.04 LTS server install from the Ubuntu ISO which can be downloaded here https://releases.ubuntu.com/18.04/ubuntu-18.04.5-live-server-amd64.iso or use a service such as Digital Ocean to host your uzERP instance https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

You should make sure the install includes the SSH option to access the server from the command line. Update the installation and install the GB locale…. (en_US is the only locale installed by default)

sudo apt update && sudo apt upgrade -y && sudo apt autoremove
sudo locale-gen en_GB.UTF-8
sudo update-locale LANG=en_GB.UTF-8

Its a good idea to switch on the firewall and then allow OpenSSH access.

sudo ufw allow OpenSSH
sudo ufw enable

Apache, PHP and PostgreSQL

sudo apt install apache2
sudo ufw allow in "Apache Full"

The latter allows for https connections at a later date.

Not strictly required, because uzERP will use the local disk if memcached is not installed, but highly recommended

sudo apt install memcached

We need to enable the Apache expires module

sudo a2enmod expires

Now install PHP (plus extras) and postgreSQL

sudo apt install php libapache2-mod-php php-pgsql php-mbstring php-bcmath php-xml php-curl
sudo apt install postgresql postgresql-contrib

Printing support

We need Apache FOP, qPDF and Ghostscript so we can do some dead tree processing

sudo apt install fop qpdf ghostscript

Network printer discovery in uzERP requires a CUPS server - a remote VM won’t find itself on a network with any printers so this can be ignored for the moment.

If barcode4j IS required you need to get it from sourceforge and copy the barcode4j-x.x.x folder to /usr/share, then update the FOP script - see https://github.com/uzerpllp/uzerp-containers/blob/master/uzerp-app-dev/files/fop for more information.

Set up postgreSQL database

Create uzERP roles and an empty database

Note - adjust the db locale in the db creation commands below if necessary, depending on collation requirements

sudo -u postgres createuser -P -s -e sysadmin
sudo -u postgres createuser -P -e readonly
sudo -u postgres createuser -P -e ooo-data
sudo -u postgres createuser -P -e  www-data
sudo -u postgres createdb --locale=en_GB.UTF-8 --template=template0 uzerp

If you want a testing instance to play with you can add another database at this point…..

sudo -u postgres createdb --locale=en_GB.UTF-8 --template=template0 uzerp-test 

Create directory, download and unzip latest uzERP release

uzERP releases are here https://github.com/uzerpllp/uzerp/releases - change the commands below to install the release you want

sudo mkdir /var/www/uzerp
cd /var/www/uzerp
sudo wget https://github.com/uzerpllp/uzerp/releases/download/1.26.6/release-uzerp-1.26.6.tar.gz
sudo tar -xvf release-uzerp-1.26.6.tar.gz

The tar file can be removed or left for later to set up a test instance on the same server at a different location.

Starter database and config

Create the starter database from the sql file included with the release - options are:

• base - minimalist start point and requires a fair amount of work to get going and probably not recommended without assistance
• starter - gets you a basic working environment to build upon
• demo - loads all of the demo data which may be useful for initial evaluation or testing

To populate a starter database:

sudo -u postgres pg_restore --dbname=uzerp /var/www/uzerp/1.26.6/schema/database/postgresql/uzerp-starter-dist.sql

Login to psql from the postgres user to check creation of the database

sudo su postgres
postgres$ psql -h localhost -U sysadmin uzerp

As a test list tables and describe the gl_accounts table

uzerp=# \d 
uzerp=# \d gl_accounts
uzerp=# \q

uzERP config.php

Copy the the config file and update with db credentials

cd /var/www/uzerp/1.26.6/conf/
sudo cp config-example.php config.php
sudo pico config.php

Edit the config.php file and change the $conf[‘DB_NAME’] and $conf[‘DB_PASSWORD’] entries to match the database credentials for the www-data user you set you earlier.

Web server

Permissions

Make sure permissions are correct - the www-data user needs read access to files inside the document root (/var/www/uzerp/1.26.6 in this case) and write access to the following directories:

• data/cache
• data/tmp
• data/users
• data/templates_c

It may be necessary to create the cache directory manually if it does not already exist.

sudo chgrp -hR www-data /var/www/uzerp/
sudo chown -hR www-data templates_c/
sudo chown -hR www-data tmp
sudo chown -hR www-data users/

PHP and FOP settings

There are some PHP and FOP settings that need to be changed in a production environment. To allow posting of large forms and increase PHP’s memory limit for some processes edit php.ini so that the variables match the settings below:

max_input_vars = 5000

memory_limit = 512

Also in php.ini, for security reasons, we need to prevent the session cookie being read by javascript by setting the following:

session.cookie_httponly = true

If running under TLS we can ensure that the session cookie is only available in TLS requests as follows:

session.cookie_secure = true

We have also found that the Java Heap size needs to be larger for some FOP outputs. To do that, edit the file /etc/fop.conf.d/headless.conf so that it contains the following:

HEADLESS="-Xmx1024m -Djava.awt.headless=true"

Apache vhost set up

https://www.digitalocean.com/community/tutorials/how-to-set-up-apache-virtual-hosts-on-ubuntu-18-04

sudo pico /etc/apache2/sites-available/25-uzerp.conf 

An example Apache virtual hosts file is shown here which can be cut and pasted in - pay particular attention to the DocumentRoot and Directory entries. Everything else can be left as is.

<VirtualHost *:80>
  ServerName {{ the server name goes here - example = uzerp.local }}
  ServerSignature off
  TraceEnable off
  DocumentRoot "/var/www/uzerp/1.26.6"
  <Directory "/var/www/uzerp/1.26.6">
    Options -Indexes +FollowSymLinks -MultiViews
    AllowOverride None
    Require all granted
    AddOutputFilterByType DEFLATE text/plain
    AddOutputFilterByType DEFLATE text/html
    AddOutputFilterByType DEFLATE text/xml
    AddOutputFilterByType DEFLATE text/css
    AddOutputFilterByType DEFLATE application/xml
    AddOutputFilterByType DEFLATE application/xhtml+xml
    AddOutputFilterByType DEFLATE application/javascript
    AddOutputFilterByType DEFLATE application/x-javascript
    AddOutputFilterByType DEFLATE application/json
    # Set Cache-Control headers based on access
    ExpiresActive On
    ExpiresByType application/javascript "access plus 48 hours"
    ExpiresByType application/x-javascript "access plus 48 hours"
    ExpiresByType text/css "access plus 48 hours"
    ExpiresByType image/gif "access plus 48 hours"
    ExpiresByType image/png "access plus 48 hours"
    ExpiresByType image/jpeg "access plus 48 hours"
  </Directory>
  ## RedirectMatch rules
  RedirectMatch 404 ^/conf/.*$
  RedirectMatch 404 ^/utils/.*$
  RedirectMatch 404 ^/plugins/.*$
  RedirectMatch 404 ^/schema/.*$
  RedirectMatch 404 ^/vendor/.*$
  RedirectMatch 404 ^/composer.*$
  RedirectMatch 404 ^/phinx.*$
  RedirectMatch 404 ^/user/(?!theme.*.css)
  ## Logging
  ErrorLog "/var/log/apache2/uzerp_error.log"
  CustomLog "/var/log/apache2/uzerp_access.log" combined
</VirtualHost> 

Disable the default site, enable the uzERP vhost and restart Apache.

sudo a2dissite 000-default.conf
sudo a2ensite 25-uzerp.conf 
sudo systemctl restart apache2

At this point your server should respond on port 80 (by default) with a uzERP login - the credentials are admin/admin which should be changed as soon as possible after setup.

If you want a test instance then another vhost file will be required pointing to the relevant DocumentRoot.

Beyond the basics

HTTPS with Let’s Encrypt

It is highly recommended that a production deployment should be secured with Let’s Encrypt to provide a TLS/SSL certificate and enable encrypted HTTPS traffic.

More information on setting this up on an Ubuntu 18.04 server can be found here https://www.digitalocean.com/community/tutorials/how-to-secure-apache-with-let-s-encrypt-on-ubuntu-18-04

4 - System Configuration

4.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.

4.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

4.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.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.

4.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

4.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

4.7 - Documents

This is where you can define custom document output

4.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.

4.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.

4.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'

5 - Modules

uzERP Modules

Standard Modules

Other Modules

uzERP contains other modules which were specifically developed to meet the needs of the project’s original sponsor Severn Delta Limited. While these may prove useful, and are delivered with the other modules, they are not documented.

• [Quality|Quality)
• [Customer Service|Customer Service)
• [HR|HR)
• [Ticketing|Ticketing)
• [Calendar|Calendar) (Deprecated)
• [Engineering|Engineering)
• [User Space Tables) (Deprectated)
• [EDI)

5.1 - Accounts

Within the Finance function there are many separate modules. Although Accounts appears in the top menu and behaves like a normal module it is in fact a ‘group container’ for all of the Finance related modules.

5.1.1 - Cash Book

The Cash Book module provides a record of the cash received and paid out within each bank account. It is fully multi-currency and closely linked to the other accounting ledgers.

Generally, most of the transactions for the Cash Book will be input automatically from the Sales and Purchase ledger modules in the form of receipts and payments. However, there are always entries that need to be posted directly, for instance:

• Tax transfers to the regulatory authorities

• Wages and Salaries payments

• Direct payments for settlement of expense claims or credit card purchases

The above payments types, and more, can be entered directly into the Cash Book and allocated to General Ledger income, expense, asset or liability accounts. In addition, the VAT on these transactions can be accounted for where applicable.

Although normally used for Bank accounts separate accounts can be set up for petty cash, merchant services (such as Worldpay, Paypal, Visa or Mastercard) and business debit cards.

Features of this module include

• Unlimited Bank accounts each allocated a unique General Ledger account code and cost centre combination

• Entry of payments or receipts in any defined currency

• Payments can be linked to contacts including those not defined in Purchase or Sales Ledgers

• Account for VAT directly on payments or receipts

• Transfers of funds between bank accounts in the currency of the paying OR receiving account

• Easy check box style reconciliation to statement

Entering a payment

Bank reconciliation

Periodic Payments/Receipts

Periodic payments are used for direct debits or standing orders (payment OR receipt). They can be set up for Purchase Ledger payments or Sales Ledger receipts as well as direct Cashbook payments. Information on how to set them up is here

Once set up Period Payments will appear in the overdue periodic payments uzLET within cashbook to remind you to post them.

5.1.2 - General Ledger

For detail on how to set up the general ledger refer to the Ledger Set Up section

5.1.3 - 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 table. Examples

5.1.4 - Purchase Ledger

The Purchase Ledger is used to record details of financial transactions between your company and your suppliers. With it you can record supplier invoices and control their payment.

A typical workflow for Purchase Ledger is as follows:

• Add a supplier record for contacts already in the system
• Create invoices from Goods Received Notes or enter invoices and credit notes directly using the Purchase Invoicing module and post to the ledger;
• Post credit and debit journals to the Purchase Ledger for contras and the like;
• List un-posted invoices periodically to clear any queries;
• Select invoices which are authorised and due for payment into payment batches with optional filters including paying bank account, payment method, supplier classifications - uzERP can process a number of payment batches in parallel, e.g. for different payment methods;
• Produce a list of items selected for payment;
• Review the selection on screen and optionally remove some transactions from the paymePurchase Ledger nt run;
• Pay the transactions selected and produce payment documents (cheques, remittance advices etc) where required or generate payment files for BACS;
• Make ad hoc or manual payments (e.g. a hand written cheque) by supplier and match with invoices settled;
• Pay an amount to a supplier which is not yet allocated to an invoice;
• Allocate cash and credits to invoices and other debit transactions.

In common with all modules Purchase Ledger uses progressive disclosure to display information about suppliers and transactions. There are also several dashboard uzLETS to provide quick access to useful information.

Suppliers

Supplier records need to be added based on already existing Accounts from the Contacts module

• Supplier * - the suppliers’s name is selected from the accounts which have not already been allocated as a purchase ledger supplier;
• Payee Name * -
• Remittance Advice - a boolean (Yes/No) to determine if a remittance is produced for this supplier;
• Currency * - the currency of the account;
• Bank Account - the bank account the supplier is normally paid from;
• Credit Limit * - a credit limit which can be used for supplier planning purposes;
• Payment Term * - the payment terms agreed with this supplier which will be used to calculate due dates on invoices;
• Payment Type * - how this supplier is normally paid;
• Tax Status * - determines if tax (VAT) is charged and if the supplier is included in EU Intrastat reports;
• Receive Into - where goods are normally received from this supplier;
• Order Method -
• Email Order -
• Email Remittance -
• Sort Code/Account Number/Bank Name Address/IBAN Number/BIC Code - banking information. Items marked * are mandatory.

Journals

Payments and Allocation

Manual payments are handled

[[Batch payments]] on the other hand have a defined procedure.

Ledger Transaction Status Codes Reference

Some reports may show raw status codes against each transaction. Each code has the following meaning:

• N = New
• O = Open
• Q = Query
• R = Part Paid
• P = Paid

5.1.5 - Purchase Ledger Batch Payment

Make sure that the default printer is set to the cheque printer before you start this procedure.

To select batch payments go to the purchase ledger suppliers list and use the Select For Payment action on the sidedbar.

to select items by payment type and customer - tick boxes required and check total before saving.

Then use the Selected Payments action which will show the selected payments (no of items etc) clicking the currency link will take you to a list which can be printed and checked - at this point you can still back out.

Enter all details for the payment run, i.e. the bank account, batch reference etc. At this point if you click PAY the purchase ledger is updated and the invoices are allocated per the payment run. If you click PAY you cannot back out.

After the PL is updated go to this screen http://egs.severndelta.co.uk/?module=purchase_ledger&controller=plsuppliers&action=batch_payment_history and there will be batch that says ‘process’. Clicking process prints the cheques to the default printer that you have set - MAKE SURE THEY ARE LINED UP AND THE DEFAULT PRINTER IS SET TO THE CHEQUE PRINTER BEFORE YOU PROCESS. The cheques will now print.

Once they are printed, on the next screen, enter the cheque numbers (start and finish) and the PL and cashbook will be updated to reflect the cheque numbers.

You will then be taken to the print remittance screen where you can print or send the remittance advices.

Once the cheque run is complete, if you go here http://egs.severndelta.co.uk/?module=purchase_ledger&controller=plsuppliers&action=batch_payment_history you can click the date to get a list of the cheques raised as in the example here http://egs.severndelta.co.uk/?module=purchase_ledger&controller=plsuppliers&action=batch_payment_history_detail&id=4. The details link gives you the details.

BACS processing

Available integration to HSBC BACS standard 18 file format.

By setting up an email address tagged ‘REMITTANCE’ under the system company this will act as the return address for the remittance.

5.1.6 - Sales Ledger

The uzERP Sales Ledger allows you to create and maintain information about your customers. Invoices are entered in the [Sales Invoice Register](Sales Invoice Register) system when you sell goods and services and cash receipts and other credit transactions can be allocated against the invoices.

The Sales Ledger is an open item system which means that the invoices remain outstanding until they are removed by having credit items (cash, Credit Notes) allocated to them. Postings are made to the General Ledger and the Tax system automatically.

Tips and tricks for Sales Ledger are here.

Customers

The customer is the basic unit within the Sales Ledger to which all other pieces of data are related. All transactions are entered against a customer.

Basic Information:

• Name * - the customer’s name is selected from the accounts which have not already been allocated as a sales ledger customer;

• Statement - a boolean (Yes/No) to determine if a statement is produced for this customer;

• Currency - the currency of the account;

• Bank Account - the bank account the customer normally pays into;

• Credit Limit * - a credit limit which can be used for credit control purposes;

• Payment Term * - the payment terms agreed with this customer which will be used to calculate due dates on invoices;

• Payment Type * - how this customer will normally pay;

• So Price Type - the price type, if allocated, dictates the price used during Sales Order Processing;

• Tax Status * - determines if tax (VAT) should be charged to this customer and if the customer is included in EU Intrastat reports

• Despatch From - which warehouse this customer’s goods are normally sent from

• Sl Analysis -

• Invoice Method -

• Email Invoice -

• Email Statement -

• EDI information -

Items marked * are mandatory.

Journals

Receipts and Allocation

Customer Discounts

The customer discount matrix allows individual discount percentages to be allocated by product group. These discounts are then applied during Sales Order Processing.

Credit Control

5.1.7 - VAT Module

VAT Returns

Menu: Accounts > Tax > VAT & Intrastat

This will display a list of VAT returns and their status. To view a VAT return and have more options, click the year on the far-left that corresponds to a particular return.

VAT Return View

This view shows the VAT values, submission receipt details and provides actions and reports for a return.

Actions

• Update VAT Position, Recalculates the values of the VAT return using the current state of accounting records.
• Close VAT Period, Recalculates the values of the VAT return and marks the VAT period as closed. No further changes can be made.
• Submit VAT Return, Submit the VAT return to HMRC using Making Tax Digital.
• Print VAT Return, Print, view or email a paper copy of the VAT return.
• View Transactions, View transactions relating to VAT Inputs, Outputs, EU Sales and EU Purchases. These reports can also be printed and output to email or CSV file.

Making Tax Digital

VAT-registered businesses with a taxable turnover above the VAT threshold are required to use the Making Tax Digital (MTD) service to keep records digitally and use software to submit their VAT returns from 1 April 2019. The VAT module enables you to submit VAT returns directly from uzERP to HMRC.

uzERP is an HMRC recognised solution for Making Tax Digital for VAT. We configure the systems of customers who have support agreements to use Making Tax Digital for VAT to submit VAT returns.

Configuring MTD

The configuration file for MTD is conf/oauth.yml. Other Oauth2 integrations may also be configured in the same file.

Example:

---
mtd-vat:
    clientid: 'ms1iIWBBPqEUYYWy90fCzlR3sgsa'
    clientsecret: '9253d6ef-15ca-42d7-a7f7-07a8a0a682c2'
    clientuuid: '606be9ed-4125-501b-93f1-86439f45bfda'
    baseurl: 'https://test-api.service.hmrc.gov.uk'
    redirecturl: 'http://localhost:8080/?module=vat&controller=vat&action=index'

The clientid, clientsecret are provided to developers by HMRC. Supported uzERP customers are provided these values, along with the clientuuid by uzERP LLP, see https://www.uzerp.com/mtd-terms.

clientuuid is an RFC4122 version5 uuid, using a SHA1 hash and the X500 namespace, that encodes the user company name. For example, on a Linux operating system the following command would generate a unique client uuid:

$ uuidgen --sha1 --namespace @x500 --name "O=Global Widgets Ltd."

606be9ed-4125-501b-93f1-86439f45bfda

Authorising uzERP to Access VAT Records

Once your uzERP system is configured for MTD you need to authorise it to read your company’s VAT records and post returns.

In the menu, go to: Accounts > Tax > VAT & Intrastat

Your browser will redirect to a page on the HMRC website where you will need to log-in with your credentials and authorise uzERP for MTD. Following authorisation, you will be returned to the list of VAT returns in uzERP.

Fraud Protection Headers

By law uzERP must send additional information called Fraud Prevention Headers when submitting VAT returns to HMRC. The headers may contain personal information and the HMRC have published a Data Protection Impact Assessment.

Fraud Prevention Headers sent by uzERP:

5.2 - Report Writer

The uzERP report writer uses views or tables created in the Reports schema of the database in use. These tables or views can then be used to build end user reports without any particular knowledge of the underlying databse structure or SQL.

Views

By default, views in the public schema are not surfaced in the uzERP Report Writer. If you want to use a standard view in the reporting module then set up a new view under the reports schema - the example below takes the standard GL transactions view and makes it available for reporting

	CREATE OR REPLACE VIEW reports.my_gl_transactions AS 
	SELECT id, docref, usercompanyid, glaccount_id, glcentre_id, glperiods_id, 
	       trandate, source, "comment", reference, twincurrency_id, twinrate, 
	       "type", twinvalue, "value", account, cost_centre, glperiod, twincurrency, 
	       year_period
	  FROM gltransactionsoverview;

You can of course omit columns or add WHERE clauses to pare the data down.

Using this technique you can create custom views from any data in the system - as long as the view is in the reports schema then it will be available for reporting. It also means that one underlying view or table can be used to drive many end user reports.

Building a basic report

To add a basic report go to Reporting -> Reports -> Add Report.

There are three panes:

1. Report Options - this allows for the selection of the base view/table and report name. It shows a list of columns available based on the view/table selected from the drop down.

2. Report Builder - columns are dragged here to build up the report. The order of the columns here determine the order of the output within the report.

3. Properties - when a selected column is double clicked the properties for that column are shown and can be changed

5.3 - Contacts

Contacts

The Contacts module is where information about your business partners is stored

• [[Accounts]] - used to keep track of Customers and Suppliers details
• [[People]] - employees of your Business Partners
• [[Leads]] - sales prospects

Contacts have an owner and be assigned to another system user for management. The screenshot shows the basic details held against any Account contact.

Optional and customisable CRM details covering Status, Source, Classification, Rating, Industry and Type can be allocated. In addition the following information is stored against any contact in the system. It is either entered directly or ‘related’ information from other parts of the system.

Opportunities/Activities

These related items link back to the Opportunities and Activities entered against the Account/Person/Lead via the [[CRM]] module.

Projects

The Projects module allows projects to be assigned to contacts at the company and/or person level - this is usually the main client contact.

Notes

Notes can be attached to all contacts and analysed by note ’type’ If one of the Sales Order/Invoice Purchase Order/Invoice note types are used the note will ‘pop up’ when entering an order/invoice against the Company or Person.

Attachments

Files such as drawings, contracts etc can be uploaded to the uzERP file server and attached to a contact here.

Addresses/Phone/Fax/Email

Each contact can have multiple mail and email addresses and phone/fax numbers. Those addresses marked shipping, billing and payment can be used as options in the despatch, sales ledger and purchase ledger systems respectively

Meetings/Calls

Details of meetings and calls can be added here. Meetings will ling back to the calendar module if required.

5.3.1 - Accounts

The Accounts section under [[Contacts]] stores information on business partners that you already deal with.

In order to tag an account for use in the [[Sales Ledger]] or Purchase Ledger the category must be set to Customer or Supplier. An account can be either or both meaning that a single source of contact information is kept for all trading partners.

5.3.2 - Leads

The Leads section of the [[Contacts|User Manual/Modules/Contacts]] module stores information about sales prospects for use in the [[CRM]] process.

When a lead turns from being a prospective customer into a live account it can be converted using the convert to account option - it will then be available in the [[Accounts]] section of the [[Contacts]] module and can be allocated as a customer in the [[Sales Ledger]].

5.3.3 - People

People may be entered independently or associated with [[Accounts]] or [[Leads]]

5.4 - Logistics

Logistics

The Logistics group in the main menu contains all of uzERP’s logistics related activities: Sales, Purchasing, Despatch, etc.

5.4.1 - Delivery and Despatch Schedule

A Calendar view of all of the activity in the warehouse.

5.4.2 - Despatch

Manages the despatching function and warehouse operations.

Orders for Despatch

Warehouse Operations

5.4.3 - Goods Received

See: Setting the location for goods received

5.4.4 - Orders for Despatch

A view of all the Sales orders that are ready to go.

5.4.5 - Purchase Invoice Register

Purchase Ledger Invoices are entered from within the Logisitics area. Going to Logisitics > Purchase Invoicing > Purchase Invoices shows a list of Supplier invoices and their current status along with processing actions in the sidebar.

Creating Invoices

Action: New Invoice

The New Invoice action creates a new invoice against a supplier. A GRN number can optionally be entered against each line, but products and quantities cannot be entered or selected. This method of creating invoices can be used when you don’t need a purchase order or GRN, but need to register an invoice for payment.

Do not use the New Invoice action for invoices against blanket/call-off or orders for stock items. When this type of invoice is matched, the purchase order line will be considered complete and marked as invoiced, no more deliveries will be able to be received against it. Always use Create Invoice from GRN for blanket/call-off or orders for stock items.

Action: Create Invoice from GRN

[[Received|Modules/Logistics/Purchasing/Receiving]] purchase order lines will have a GRN (Goods Received Note), which can be used to create a supplier invoice. The Create Invoice from GRN action shows a list of GRN lines that can be selected to create an invoice that mirrors an invoice received from a supplier.

Matching Goods Received to Invoices

When an invoice is received against an order it can be matched against a Goods Received Note (GRN) by going to Purchase Orders > Create Invoice From GRN.

If an invoice is entered then subsequently needs to be matched go to Logistics > Purchase Orders > Purchase Orders > Match GRN to Invoice - you can post match an old line to an old invoice, assuming the invoice shows up in the drop down.

5.4.6 - Purchasing Order Processing

Purchase Order Processing allows for the management of supplier purchase orders for both goods and services.

Please see the Purchase Order Processing How To for some answers to common questions.

Suppliers

Before any orders can be processed suppliers must be set up on the system. This is achieved by first entering an account via Contacts > Accounts. The Account must be flagged as a supplier in the category section.

Once the contact details are added the supplier must be initialised in the Purchase Ledger under Accounts > Purchase Ledger > View Suppliers > Add Supplier. Here details relating to payment, VAT status, etc can be updated.

Products

Menu:

• Logistics > Purchase Orders > Products
• Logistics > Purchase Orders > Product Lines

The Product and Product Lines options are used to define the product catalogue for purchasing. In a manufacturing or wholesale environment, most product lines will be linked back to a stock item as well as to a defined supplier.

Using products is optional, order lines can still be entered on-the-fly by just entering a price and description. This enables one-off items to be purchased without the overhead of defining a product. For regularly purchased items the use of products is highly recommended. For stock controlled items the use of products is mandatory

Each product holds the following information:

• Product Group - use this drop down to pre-select the product group of the item where the item is stocked
• Stock Item - if the item is stocked, relate this price to a stock item
• Description - a description for the item - this is defaulted to the item description where the product is a stock line
• UoM - the unit of measure
• Tax Rate - whether the item is taxable and the rate of tax to charge
• GL Account - the GL account where the purchase is to be credited
• Cost Centre - the cost centre where the purchase is to be credited
• Start Date - the effective date of the price for this product
• End Date - this can be used to ‘close off’ products so that they are no longer valid and cannot be used

Product Lines

Once a product is added individual price combinations can be added for suppliers and dates. Each product can have multiple lines to denote different suppliers for the same item. In addition the system can be used for time based pricing where a supplier increases (or decreases) prices over time.

Each product line holds the following information:

• Supplier - the supplier for this price, leave blank to have this price available from ALL suppliers
• Supplier Product Code - if required, enter the supplier’s code here for those situations where the supplier’s code needs to be quoted on documentation
• Description - a description for the item, defaulted to the item description where the product is a stock line
• Currency - the currency for the price (based on the customer’s currency)
• Price - calculated based on gross price and discount matrix for the customer/type/discount combination
• GL Account - the GL account where the purchase is to be credited
• Cost Centre - the cost centre where the purchase is to be credited
• Start Date - the effective date of the price for this product
• End Date - this can be used to ‘close off’ product lines so that they are no longer valid and cannot be used
• EAN - can be used to implement bar coding

When viewing Products or Product Lines, the default search selects records that are current at today’s date. Anything that has an end date in the past or start date in the future will not be listed.You can clear the Current At date search to show all past, present and future products/lines or set Current At to an appropriate date.

Order Processing

Orders are entered by selecting the Purchase Orders > New Order menu option or by using the New Purchase Order link from the sidebar of the purchase orders list view.

If the total value of the order exceeds the user’s authorisation limit, it will become a requisition and require authorisation before it can be sent to the supplier

The basic purchase order processing steps are:

1. Enter the purchase order
2. Send the order to the supplier by using the sidebar Print Order action. The order can be printed or sent via email, etc.
3. Optionally indicate that the order has been acknowledged by using the Order Acknowledgement Received action.
4. [[Receive deliveries|Modules/Logistics/Purchasing/Receiving]].
5. [[Create and match supplier invoices|Modules/Logistics/Purchasing/Invoicing]]

Order Status

Each order/order line can have one of the following statuses:

• New - order has been entered but not sent to the supplier
• Awaiting Delivery - ordered but no deliveries received
• Part Received - partial delivery received
• Cancelled - order/line cancelled
• Received - total order quantity received
• Invoiced - order/line matched to an invoice

5.4.7 - Sales Invoice Resgister

The Sales Invoice Register is analagous to a sales “day book” and records every invoice or credit note entered. Invoices can be entered directly into the Sales Invoicing system or can be generated from the uzERP [Sales Order Processing](Sales Order Processing) system.

5.4.8 - Sales Order Processing

Please see the [[Sales Order Processing How To|How-To/Sales-Orders]] for some answers to common questions.

[[TOC]]

Product Lines

Sales Order Product Lines represent the organisation’s catalogue.

You can input products for sale based on price lists which may be general across the company or relate to customer groups. In addition individual product prices may be input for specific customers. The columns in the SO product lines table are:

• Product Group - use this drop down to pre-select the product group of the item where the item is stocked
• Customer - the customer for this price, leave blank to have this price available to all customers
• Stock Item - if the item is stocked, relate this price to a stock item
• Customer Product Code - if required, enter the customers code here for those situations where the customer’s code needs to be quoted on documentation
• Description * - a description for the item - this is defaulted to the item description where the product is a stock line
• So Price Type - if this product line relates to a price list, for example trade or retail
• Gross Price - the gross price
• Product Group Discount - where extra discounts are available by group the code can be added here
• Net Price - calculated based on gross price and discount matrix for the customer/type/discount combination
• Currency * - the currency for the price (based on the customer’s currency)
• UoM * - the unit of measure
• Tax Rate * - whether the item is taxable and the rate of tax to charge
• GL Account * - the GL account where the sale is to be credited
• Cost Centre * - the cost centre where the sale is to be credited
• Start Date * - the effective date of the price for this product
• End Date - this can be used to ‘close off’ product lines so that they are no longer valid and cannot be used

Items marked * are mandatory.

When viewing Products or Product Lines, the default search selects records that are current at today’s date. Anything that has an end date in the past or start date in the future will not be listed.You can clear the Current At date search to show all past, present and future products/lines or set Current At to an appropriate date.

During order entry the system will look at this table to determine the items available for sale for the customer in question and build an appropriate drop down list allowed for that customer based on products that are:

1. in the appropriate ‘price type’ for the customer (the ‘price type’ for the customer is set against the Sales Ledger record).
2. specific to the customer, that is where the product line is allocated to a customer
3. available in general to all customers

Entering products and prices here therefore greatly speeds up order entry. It is also worth noting the following when entering orders where the SO product line is used:

1. When linking an item to a Sales Order Product Line, the item code and description from the Stock Item is copied to the Sales Order Product Line description which can then be amended to add additional information to the Sales Order Product Line (for instance customer part numbers/description)
2. There are two description fields on the Sales Order Line; item description and description
3. The description is always displayed on the Sales Order Line; in some places, the item description is also displayed
4. The Sales Order Line description comes from the Sales Order Product Line description; the Sales Order Line description can then be changed to provide additional information at order entry time
5. The Sales Order Line description is copied to the Sales Invoice Line
6. The Sales Order Line item description comes from the Stock Item description to match with the linked stock item; the Sales Order Line item description cannot be changed
7. The Sales Pick List shows the Stock Item code and the description from the Sales Order Line; this will highlight any differences between the linked stock item and the description
8. When editing a Sales Order Line, the description is not automatically changed because this could lose any additional information that was originally entered for that order line
9. If the Stock Item description is subsequently amended, neither the Product Line description nor the Sales Order Line item description is automatically updated

Order Processing

Orders are entered by selection the add Sales Orders -> New Order menu option or using the New Sales Order link from the sidebar of the sales orders list view.

Order Status

Each order/order line can have one of the following status. These are pretty straight forward and are listed below.

• New - the order has been entered
• Open -
• Cancelled
• Despatched
• Part Despatched
• Invoiced

Sidebar Actions

Print Acknowledgement

Prints an acnowledgement for the order and sets its status to Open

Print Pro Forma Invoice

Allows for the printing of a proforma invoice.

Print Pick List

Confirm Pick List

Confirm items as picked on a line by line basis.

Edit Sales Order

This option only appears if editing is allowed, based on the status of the order.

Revise Line Despatch Date

Each line can have a different despatch date - this option allows for revisions for new/open lines.

Cancel Lines

Cancel lines on an order.

Related Items

Show Packing Slips

This option is used to create a packing slip that can be enclosed when goods are despatched.

Price Types

Price types allow SO product lines to be grouped into price lists. Customers can be allocated a Price Type which means that at Order Entry the system will look for prices from the SO Product Lines table which are allocated to this price type. Examples would be:

• EU - European Distributors
• Medical - Medical Distributors
• Trade - Trade & Industrial Customers

In addition Customer Discounts can be used to apply a discount to a price type based on an item’s product group for a particular customer.

Item Availability

When processing customer orders it is useful to have an overview of the availability of stock within the system. Two screens are available:

• Logistics -> Sales Orders -> Sales Orders -> Item Availability
• Logistics -> Sales Orders -> Product Lines -> View Supply/Demand

This shows demand for [[Stock Items|Modules/Manufacturing/Stock]], i.e. sales orders vs stock and supply ([[Works Orders|Modules/Manufacturing/Works-Orders]] or [[Purchase Orders|Modules/Logistics/Purchasing/Purchase-Order-Processing]]).

The columns are:

1. Required = quantities from sales order lines
2. Available = available quantities in saleable locations
3. In Stock = quantities in stock but NOT in saleable locations
4. Actual shortfall = (Available + In Stock) - Required
5. On Order = Quantities from Purchase order or Works order lines
6. Expected Shortfall = Actual Shortfall - On Order

Note that this ONLY deals with stock items, if the item is not stock on then it won’t appear. Item Availability only shows items for which you have an order whereas the View Supply/Demand shows the full list and can be selected by Product Group).

5.5 - Manufacturing

The Manufacturing module is used where you wish to store or make items for sale or distribution.

5.5.1 - Warehousing and Stores

The warehouse management system is where the set up of Stores (warehouses), locations and bins takes place. The system uses a series of one to many relationships to represent a hierarchical structure - thus 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.

What You Can Do With uzERP Warehouse Management

• Maintain Location Balances - displays and reports show all balances held in real locations (as opposed to no-balance locations) and can aggregate them.
• Evaluate Stock Balances - balances may be evaluated using item costing data. This allows you to answer questions like, “What is the value of finished goods stock?” or, “How much do we have tied up in inspection?”.
• Maintain Stock Transaction History - every stock transaction is recorded, with its date and time, together with the cost prevailing at the time. This table can be used for a wide variety of historical and audit tasks, as well as extracting inventory movement data for transfer to the accounting system if required.
• Evaluate Stock Transactions - the transaction history table can be evaluated, using the current cost or the cost when the transaction was made. This allows you to answer questions like, “What is the value of WIP issues to date this month?” or, “What is the cost of sales deliveries this week?” These stock transactions and the related cost data can be used to maintain the financial state of your stock.
• Restrict Stock Available For Sale - balance locations may be marked as “Goods-for-sale” locations. uzERP’s Sales Order processing routines will only sell stocks in these accounts.
• Provide An On-Line Bin Card - The transaction history display for each item in the system uses a format similar to a bin card, including historical balances and running totals. This can make uzERP appear reasonably familiar to stores personnel used to manual systems.

5.5.2 - Stock

Please see the Stock How To for some answers to common questions.

In some senses the Stock system is the heart of the commercial system if you are a manufacturer or wholesaler as every aspect of the business will be related back to a stock item is some way. The stock system will hold:

• Stock Item details
  • Units of measure
  • Structures and Operations for manufactured, sub-contracted and kit items
• Stock Item balances across warehouses/locations/bins
• Stock Transactions
• Links to:
  • Work Orders, via the stock item itself
  • Sales orders, via sales products/productlines
  • Purchase orders, via purchase products/productlines

We suggest that a stock map be 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.

Stock Accuracy

Stock accuracy is of prime importance in running any business that buys, sells or makes products. If your stock records are wrong, then anyone using those stock records for information to support decisions will:

• Make wrong decisions (if the records aren’t known to be wrong)
• Not trust the records and use judgement, not fact

The results of inaccurate stock records are felt in a number of ways:

• Excess stock that needs funding (more than you realise!);
• Shortages that lose business;
• Increased overheads as everybody keeps their own stock records;
• Confusion when stock records disagree (more costs).

No business will maintain a competitive edge with inaccurate stock records. Your target stock accuracy should be 100% in all areas. You should be getting near to this, in the high 90’s, to be confident.

Stock Items

Stock Items are the core of the stock module. The basic information for a stock item is as follows:

• Item Code * - a unique identifier for the stock item
• Alpha Code - a free format code used for analysis
• Uom * - the unit of measure for the item as defined in the UOMs table
• Prod Group * - a product group used for analysis
• Cost Decimals * - the number decimal places to hold costs
• Qty Decimals - if you require whole items set this to 0
• Min Qty/Max Qty - used for replenishment reports
• Tax Rate * - when purchased or sold the tax rate normally used for this item
• Description - a description
• Type Code * - the type code drives certain actions i te manufacturing and stock system such as backflushing and can be used for analysis
• Comp Class * - component class is one of Bought in, Manufactured or Sub-Contracted
• Abc Class * - inventory management classification
• Materials Cost * - if Comp Class is Bought-in this can be entered here
• Batch Size/Lead Time/Ref1/Text1 - optional analysis fields
• Obsolete Date - if this item is marked as obsolete

Items marked * are mandatory.

Cloning Stock Items

Items can be cloned(copied) using the Clone Item action, available on the sidebar when viewing and item. Optionally, other records attached to the item can be copied at the same time.

• Structure
• Operations
• Outside Operations
• Unit of Measure Conversions
• Sales Order Product and Prices (since 1.9)

When cloning the Sales Order Product and prices there a a few things to note:

• only prices that are not specific to a customer are copied
• descriptions on the sales product and prices will match the item being cloned
• the specified start date will be applied to the sales product and price

Stock Transactions

Each movement will generate two transactions (based on double entry) – a “from” and a “to” in line with the warehousing system. Backflusing in the manufacturing system will move stock and generate transactions.

Product Structures

A product structure (BOM) is a list of the components that build a finished item. If each of the components in a structure has a price then the system will automatically build up the cost of those components to make 1 of the finished items. You can build in waste and also cost the labour and machine time to give you a full cost. The system will also maintain it so that every time the price of a part changes (say the cost of rims increases) it will automatically update the cost of all the finished items where the part is used so you always have the latest cost on file for all of the items.

5.5.3 - How to create a stock map

When setting up the warehouse management system it is particularly important to create a stock map showing Warehouses and Locations, the Actions that generate the stock movements and how these are to be handled and the movement types between the locations associated with each action.

The terminology used in uzERP is as follows:

uzERP’s stock movement system is a ‘double-entry’ system - each and every stock movements is represented by a pair of transactions - there must be a “From” and a “To” component. This means that there has to be some way to represent locations that are ‘outside’ of the physical stock system. This is what ’no-balance’ locations are for.

The boxes in the diagram represent Stock Locations that are designated as ‘balance locations’ i.e. they hold real stock. These may be physical locations for example ‘Raw Material stores’, or logical locations, say ‘Goods awaiting inspection’. For these, a stock balance is meaningful and is held by the system in the balances table. The ‘clouds’ are no-balance locations, which don’t have balances held, but represent logical locations where stock is moved to or from.

The individual warehouse Transfer Rules are represented by arrows between the locations and the Actions these rules are associated with are shown by the labels. You will notice that some Actions are associated with only one Transfer Rule, while others connected to several. For example, goods are received from a no-balance location called Purchase Orders into a balance location for Raw Materials.

Once the stock map is completed you can then go through the process of adding the locations and actions to the system via the Setup -> Manufacturing Setup -> Stock Actions routines.

5.5.4 - Works Orders

Works orders are used to drive the manufacturing process and are crucial to the demand planning and shop floor data capture parts of the system. Works order information can be accessed from the Manufacturing -> Works Orders menu option. The Manufacturing module home page has the following uzLETs for managing works orders

• Print Works Orders
• Book Production and Issues/Returns
• Backflush Errors

The stages of a Works Order

Orders go through several stages denoted by the status indicator:

• New - The order has been entered onto the system but is not yet finalised. At this stage no bookings can be made to the order but it shows up in all of the demand and requirement reports.
• Released - The order is available for document printing and will appear in the open order uzLETs.. Materials can be reserved against orders with a released status and but work has not yet started as no production has been booked.
• Open - Production has been booked to the order or materials issued or reserved. The order is ‘in progress’.
• Complete - The order is completed.

Adding a Works Order

The menu option Manufacturing -> Works Orders -> Add Works Order takes you straight to the form and following information is required to add a works order:

• Stock Item - all manufactured items are shown in the drop down.
• UoM - the unit of measure for this works order. This will default to the usual unit for the item although alternative UoMs may be used where ther is a conversion factor in place.
• Data Sheet - If a data sheet is to be issued with the works order.
• Order Qty - how many units are required.
• Required By - when the works order is due to be completed.
• Project - if the works order is related to a project it may be selected here.
• Text1, Text2, Text3 - free format text.
• Order No, Order Line - a sales order or customer order and the line to which this order relates.
• Documentation - any documentation required.

A works order is added with a status ‘New’.

Managing a Works Order

There are various actions for managing Works Orders that have been entered. When the works order is selected from the collection the following sidebar actions are available

• Edit
• Review Material
• Review Resources
• Force Complete
• Issues
• Returns
• Book Production
• Reset Status

In addition there is a ‘show related’ option to view all transactions against the order.

Booking Production

Production against a works order is booked by using the Book Production uzLET.

Shop Floor Loading

5.5.5 - Backflushing

Backflush refers to a special type of stock transaction. When backflushing is in use, uzERP can be made to assume that raw materials or components have been used because a particular action in the stock system has taken place. This assumption is based on the product structure for the item being produced.

The reasons for wanting to use backflushing vary. In process-flow or JIT production environments it is often the most cost-effective way to provide records of raw material or component consumption. This way material costs can be attributed to products made on a particular works order. Installations like this usually have excellent procedures and quality control and can rely upon actual events following plans.

Within uzERP backflushing can also be used as a way of tracking consumption or free-issued materials at sub-contractors by moving the assumed consumption on receipt of the goods.

Beware of backflushing simply to save stores time, or if there are not enough stores personnel to perform all the necessary transactions. A system like uzERP will only perform if events in the system actually line up with events on the ground and backflushing will magnify this issue - when the system is asked to make assumptions like this it is doubly important that data is accurate and the assumptions are valid.

Batched, serialised or bin controlled components cannot be backflushed because uzERP cannot tell which batch was issued, or which bin stock was taken from.

Set Up for Backflushing

In order for backflushing to work there must be a backflush action set up that details the movement required for the raw materials or components on completion of the stock item being produced - whether or not backflushing is used is determined by the type code of the item being produced or received.

This means that a type code must be set up where there are different actions, perhaps where there are both manufactured and sub-contracted parts.

Backflush Errors

In the event of an error, when uzERP can’t find enough stock to make a backflush issue, an ‘unresolved’ movement is created. There is a uzLET on the default manufacturing sceen which shows that there is a problem, which is shown below:

{{:backflusherrors.png|750}}

Clicking on the link will take you to the transaction where the problem can be resolved.

{{:backflushresolve.png|}}

A regular audit of backflushes should be carried out by using the stock transaction view and searcing for unresolved stock transactions.

5.5.6 - Production Recording

This part of the manufacturing module allows you to collect performance data related to shop floor operations. You are able to set up

• Shifts

• Downtime Codes

• Waste Types

5.6 - Quality

The quality module allows users to input and track complaints by retailer, status, complaint type, product etc.

Adding / Editing a Complaint

The only required field for a complaint is the date of which it is raised, which can be any time in the past, present or future. However entering an as concise complaint will increase it’s value to you as data.

Fields

Complaint Behaviour

When entering a complaint, certain fields values can affect the behaviour of other fields, and thus, general functionality. You should be aware of the following:

Entering a completed date will remove the assigned to person

The assigned to field is great for being able to track a complaint as it circulates your organisation, however when a complaint has been closed a completed date should be entered. When a complaint is completed it is no longer one person’s responsibility, therefore any value within the assigned to field is removed.

6 - Frequently Asked Questions and How-to

General

• Common Questions
• Dashboards and User Preferences
• Data Export

Sales and CRM

• Contacts - Accounts, People, Leads
• CRM - Activities & Campaigns
• Home Page/Dashboard/General
• Sales Order Processing
• Despatch

Purchasing

• Purchasing Order Processing
• Goods Received

Stock and Manufacturing

• Manufacturing & Works Orders
• Stock
• Warehousing

Accounting

• Asset Register
• Cash Book
• [Costing]
• [General Ledger]
• Purchase Ledger
• Sales Ledger

Technical

• Power User How To - interesting bits ’n’ bobs - including some SQL tricks.
• Copy-Live-Data-to-a-Test-System

6.1 - Cash Book

How do I…?

Carry out a cheque or BACS run?

See [[Batch Payments|Modules/Accounts/Batch-Payments]]

Set up Periodic or Recurring payments

Go to Setup -> Ledger Setup -> Periodic Payments - from here you can set up payments AND receipts. There is an uzLET within the cashbook module to show overdue periodic payments.

6.2 - Contacts

How do I….?

Convert a Lead into an Account?

Use the sidebar option ‘Convert To Account’ when viewing the Lead - this will require the entry of an account number. Once converted the Sales or Purchase Ledger details can be set up by going to the appropriate main menu option:

• Accounts -> Purchase Ledger -> View Suppliers -> Add Supplier
• Accounts -> Sales Ledger -> Customers -> Add Customers

Find People related to a particular customer?

Use the main menu option: Accounts -> People

Use the search option by company and and click the Search button. This list can be printed, emailed or exported by clicking on the Output button.

6.3 - Copy Live Data to a Test System

When we install uzERP for customers we install a live instance and a test instance. The test instance is for testing, training, etc. and it is often useful for it to run on a recent copy of the live system.

To make a copy of the live system database and load it to the test system, use the following procedure.

Change the placeholders [dump-file-name.sql] and [test-db-name] in the commands, below, to suit your own uzERP configuration.

1. Dump a copy of the live database:

sudo -u postgres pg_dump -Fc uzerp-live > [dump-file-name.sql]

2. Delete the existing test database:

sudo -u postgres dropdb [test-db-name]

3. Create an empty test database:

sudo -u postgres createdb --locale=en_GB.UTF-8 [test-db-name]

4. Load the dumped data into the test database:

sudo -u postgres pg_restore --dbname=uzerp-test [dump-file-name.sql]

5. Vacuum the database:

sudo -u postgres /usr/bin/vacuumdb -z [test-db-name]

6.4 - Dashboard/Homepage

Create your own dashboard by pulling uzLETS from every module you have access to.

Also manage Preferences, Holiday Requests, Expenses and saved data.

How Do I…?

Change the number of lines displayed in a uzERP’s lists?

Home -> My Preferences and change ‘Items to display per page’.

Change my default printer?

Home -> My Preferences and pick a printer from the list under ‘Default Printer’.

Use my ‘Local’ Printer?

Home -> My Preferences and choose Enable browser PDF printing.

Create a dashboard?

You can set up a dashboard on any module page by adding ‘uzLETS’. These are small blocks that contain useful summary information. On the Home Page all uzLETS from all modules that you have access to are available. This allows you to create a cross-module dashboard of high level information or items requiring action. On each module page you can also add the uzLETS for that module to create module dashboards.

6.5 - Data Export

How Do I…?

Export data to spreadsheet?

The steps are quite simple:

1. On any view or report click the output button
2. Select ‘CSV’ as the File Type and View as the Action
3. Set the options as approriate
4. Click Output Document

Depending on your setup the browser will either download the file or open it in the appropriate client application.

6.6 - Frequently Asked Questions

The FAQ information here answers some common questions about uzERP. There are also some operational [[How To|How To/Index]] questions and answers describing activities by module.

Basics

What hardware and software do I need?

Hardware depends on the number of users but is relatively modest.

A server should be dedicated to uzERP and running a Linux server variant - we recommend Ubuntu Server Edition. See more detail on software [[requirements]].

Which browser can I use?

uzERP will work in any modern, web-standards compliant browser. The system has been extensively tested using Firefox and Google Chrome. If you need to use Internet Explorer, then version 11 onwards is required.

How many users does uzERP support?

uzERP is built using solid Open Source tools and will scale to any number of users, depending on your hardware. Since there are no per-user licencing restrictions you can add users as you need them at no extra cost.

Contacts

Can I store contact records for prospects as well as live accounts?

uzERP has a full contact management module which supports Leads, Accounts and Person records. Each contact can have multiple addresses, phone numbers and email addresses.

CRM

What is CRM?

There are many definitions - one we particularly like is:

CRM, or Customer Relationship Management, is a company-wide business strategy designed to reduce costs and increase profitability by solidifying customer loyalty. True CRM brings together information from all data sources within an organisation (and where appropriate, from outside the organisation) to give one, holistic > view of each customer in real time. This allows customer facing employees in such areas as sales, customer support, and marketing to make quick yet informed decisions on everything from cross-selling and up-selling opportunities to target marketing strategies to competitive positioning tactics.

How does uzERP support CRM?

uzERP allows the entry of contact details for actual and prospective clients. The CRM module specifically allows the tracking of opportunities, campaigns and activities. Because of the progressive disclosure embedded in the user interface, information is quickly available to those who need it.

Projects

I have a fabrication business - can uzERP handle the large scale jobs we do?

uzERP’s project management module is quite extensive and can be used for large scale manufacturing or on-site construction projects.

Manufacturing

Can I use the system to manage stock (inventory)?

uzERP has an extremely flexible stock (inventory) management system. There are facilities to sort products by group and type as well as process route, free format text columns for analysis and full search capabilities. Stock can be stored at multiple locations within multiple stores (warehouses). Locations can also be ‘bin controlled’ to give further granularity.

Does the system handle complex manufacturing?

uzERP will handle make to stock, make to order and large batch processing. Multi-level product structures and complex routes are available, including sub-contract operations. There are facilities to enter departments and work centres, make product substitutions and carry out late configuration and shop floor data collection. Shop floor paperwork is catered for, and backflushing of materials used in production can be accomplished for high volume manufacturing.

What about simple manufacturing?

uzERP can do that as well. You don’t have to deploy all of the functionality - and since all available modules are delivered with the software, you can pick and choose which options work best for your business.

We use OEE as a performance metric - can I record actual operational performance?

There is a comprehensive shop floor data collection system within the Manufacturing module. there are user defined shift patterns work centres and performance codes so your reporting can be very ‘granular’. The Reporting module allows for complex custom reports to be built and there is always the option to output summary data to spreadsheet for further analysis.

Logistics

How can uzERP help me manage Logistics?

uzERP can handle multi-warehouse/location scenarios or very simple use-cases. Some businesses are necessarily complicated but uzERP can help by improving visibility of stock, streamlining procedures and providing a clean and familiar browser based user-interface for your staff. Searching is embedded, so finding the right information, such as ,‘Where is my stock?’ or ‘Which orders are due today?’, is very easy indeed.

Can uzERP help me plan?

uzERP has comprehensive [[supply and demand management|supplydemand]] capabilities, including summary reports showing on order, available stock and fulfilment.

Accounts

uzERP covers Sales Ledger and Purchase Ledger (AR and AP) plus General Ledger and Cash Book which are all linked to the back end systems for invoicing and goods received meaning you can drill back from accounting transactions or forward from commercial systems.

What about Sales Tax?

There are multiple VAT rates which can be allocated to items sold. Each trading partner is allocated to a VAT status to determine whether the VAT is actually charged, and there are options to produce UK intrastat information. The adaptability means that other tax regimes should be catered for fairly easily.

We deal in multiple currencies - can uzERP cover this?

Yes, uzERP is multi-currency.

6.7 - Goods Received

How do I…?

Cancel a Goods Received Note (GRN)?

When looking at an individual GRN there is a side bar option ‘Cancel GRN’.

6.8 - Power User/Developer

This section is for those of you who want to get more from uzERP by writing custom SQL for reports etc or playing with uzLETS.

How do I…?

Find the GL period of a transaction given its date?

So you have a transaction, say an invoice or stock movement, with a date and you’d like to sort it by GL period to line up with the accounting periods rather than its calendar month. Here’s how for sales invoices:

SELECT invoice_number, invoice_date, year, period
FROM gl_periods p, si_header i
WHERE p.enddate = ( SELECT min(enddate)
	            FROM gl_periods z
	            WHERE z.period `<>` 0 z.enddate >= i.invoice_date
	            AND p.usercompanyid = z.usercompanyid)
ORDER BY invoice_number

Set up a view for use in Reporting?

By default, views in the public schema are not surfaced in the uzERP Report Writer. If you want to use a standard view for reporting then set up a new view under the reports schema - the example below takes the standard GL transactions view and makes it available for reporting

CREATE OR REPLACE VIEW reports.my_gl_transactions AS 
SELECT id, docref, usercompanyid, glaccount_id, glcentre_id, glperiods_id, 
       trandate, source, "comment", reference, twincurrency_id, twinrate, 
       "type", twinvalue, "value", account, cost_centre, glperiod, twincurrency, 
       year_period
FROM gltransactionsoverview;

You can of course omit columns or add WHERE clauses to pare the data down.

Use this technique to create custom views from any data in the system - as long as the view is in the reports schema then it will be available for reporting.

PostgreSQL date sorting?

This looks a bit complicated, but the date_part - date_part(‘year’, invoice_date)||to_char(date_part(‘month’, invoice_date),‘FM09’) - could be encapsulated in a pgsql function.

SELECT date_part('year', invoice_date)||to_char(date_part('month', invoice_date),'FM09') as inv_year_month,
	 CASE WHEN date_part('year', current_date)||to_char(date_part('month', current_date),'FM09')=date_part('year', 
		invoice_date)||to_char(date_part('month', invoice_date),'FM09')
	        THEN 'current = '||net_value
	      WHEN date_part('year', current_date - interval '1 
		month')||to_char(date_part('month', current_date - interval '1 
		month'),'FM09')=date_part('year', 
		invoice_date)||to_char(date_part('month', invoice_date),'FM09')
	        THEN '1 Month = '||net_value
	      WHEN date_part('year', current_date - interval '2 
		month')||to_char(date_part('month', current_date - interval '2 
		month'),'FM09')=date_part('year', 
		invoice_date)||to_char(date_part('month', invoice_date),'FM09')
	        THEN '2 Month = '||net_value
	   END
FROM si_header;

Checking the date function, it does handle the differing day lengths in months, as follows:-

SELECT date_part('year', timestamp 
	'2011-01-04')||to_char(date_part('month', timestamp '2011-01-04'),'FM09')
	      , date_part('year', timestamp '2011-03-31'- interval '1 
	month')||to_char(date_part('month', timestamp '2011-03-31'- interval '1 
	month'),'FM09')
	      , date_part('year', timestamp '2011-04-01'- interval '1 
	month')||to_char(date_part('month', timestamp '2011-04-01'- interval '1 
	month'),'FM09');

In the above, taking one month off 31/03/2011 gives 201102; taking one month off 01/04/2011 gives 201103; i.e. it works on months not days.

SELECT date_part('year', current_date)||to_char(date_part('month', 
	current_date),'FM09')
	      , date_part('year', current_date - interval '1 
	month')||to_char(date_part('month', current_date - interval '1 
	month'),'FM09')
	      , date_part('year', current_date - interval '2 
	month')||to_char(date_part('month', current_date - interval '2 
	month'),'FM09')
	      , date_part('year', current_date - interval '3 
	month')||to_char(date_part('month', current_date - interval '3 
	month'),'FM09')
	      , date_part('year', current_date - interval '4 
	month')||to_char(date_part('month', current_date - interval '4 
	month'),'FM09')
	      , date_part('year', current_date - interval '5 
	month')||to_char(date_part('month', current_date - interval '5 
	month'),'FM09')
	      , date_part('year', current_date - interval '6 
	month')||to_char(date_part('month', current_date - interval '6 
	month'),'FM09')
	      , date_part('year', current_date - interval '7 
	month')||to_char(date_part('month', current_date - interval '7 
	month'),'FM09')
	      , date_part('year', current_date - interval '8 
	month')||to_char(date_part('month', current_date - interval '8 
	month'),'FM09')
	      , date_part('year', current_date - interval '9 
	month')||to_char(date_part('month', current_date - interval '9 
	month'),'FM09')
	      , date_part('year', current_date - interval '10 
	month')||to_char(date_part('month', current_date - interval '10 
	month'),'FM09')
	      , date_part('year', current_date - interval '11 
	month')||to_char(date_part('month', current_date - interval '11 
	month'),'FM09');

Put transactions into time buckets ?

This applies in something like an aged debt report (shown below) and uses some of the techniques highlighted above:

SELECT 
sltransactionsoverview.customer, 
sltransactionsoverview.transaction_date, 
sltransactionsoverview.id, sltransactionsoverview.transaction_type, sltransactionsoverview.our_reference, sltransactionsoverview.ext_reference, 
sltransactionsoverview.gross_value, 
sltransactionsoverview.currency, 
sltransactionsoverview.rate, sltransactionsoverview.description, sltransactionsoverview.payment_terms,
      CASE
            WHEN to_char(sltransactionsoverview.transaction_date::timestamp with time zone, 'YYYYMM'::text) = to_char('now'::text::date::timestamp with time zone, 'YYYYMM'::text) 
	            THEN sltransactionsoverview.gross_value
            ELSE 0::numeric
      END AS current_gross, 
      CASE
            WHEN to_char(sltransactionsoverview.transaction_date::timestamp with time zone, 'YYYYMM'::text) = to_char('now'::text::date - '1 mon'::interval, 'YYYYMM'::text) 
	            THEN sltransactionsoverview.gross_value
            ELSE 0::numeric
	END AS m1_gross, 
	CASE
	      WHEN to_char(sltransactionsoverview.transaction_date::timestamp with time zone, 'YYYYMM'::text) = to_char('now'::text::date - '2 mons'::interval, 'YYYYMM'::text) 
	            THEN sltransactionsoverview.gross_value
	      ELSE 0::numeric
	END AS m2_gross, 
	CASE
	      WHEN to_char(sltransactionsoverview.transaction_date::timestamp with time zone, 'YYYYMM'::text) = to_char('now'::text::date - '3 mons'::interval, 'YYYYMM'::text) 
		      THEN sltransactionsoverview.gross_value
	      ELSE 0::numeric
      END AS m3_gross, 
	CASE
	      WHEN to_char(sltransactionsoverview.transaction_date::timestamp with time zone, 'YYYYMM'::text) = to_char('now'::text::date - '4 mons'::interval, 'YYYYMM'::text) 
	            THEN sltransactionsoverview.gross_value
	            ELSE 0::numeric
	END AS m4_gross, 
	CASE
	      WHEN to_char(sltransactionsoverview.transaction_date::timestamp with time zone, 'YYYYMM'::text) <= to_char('now'::text::date - '5 mons'::interval, 'YYYYMM'::text) 
	           THEN sltransactionsoverview.gross_value
	      ELSE 0::numeric
	END AS m5_gross
FROM sltransactionsoverview
LEFT JOIN slmaster_overview ON sltransactionsoverview.slmaster_id = slmaster_overview.id
LEFT JOIN companyoverview ON slmaster_overview.company_id = companyoverview.id
LEFT JOIN countries ON companyoverview.countrycode = countries.code
WHERE sltransactionsoverview.status::text `<>` 'P'::text
ORDER BY sltransactionsoverview.customer, sltransactionsoverview.transaction_date, sltransactionsoverview.id;

6.9 - Purchase Ledger

How do I…?

Carry out a cheque or BACS run?

See Purchase Ledger Batch Payment

6.10 - Purchase Order Processing

How do I…?

Set up stock items for buying?

There is a product lines table that is accessed via Logistics > Purchase Orders > Product Lines. A product line can be linked to a stock item and can also be specific to a supplier if required.

Set up non-stock or services for buying?

As above, go to Logistics > Sales Orders > Product Lines. The line to be purchased is added here with its price, supplier etc - there is no need to reference it back to a stock item if it is for a service

Receive more than was ordered?

uzERP will allow you to receive more items than were actually ordered and

• update stock with the correct quantity
• allow the actual invoice cost to be entered

Close an order line with an outstanding quantity?

Where an order line shows an outstanding quantity that will not be received, it can be marked as completed.

1. Edit the order line
2. Select ‘Complete Line’
3. Save the line

Only the original creator of the order can edit part received lines and mark them complete.

Call-Off Orders

Although there is no specific functionality relating to call-off orders in PO processing each order line within an order can have a different delivery date. In this case the delivery date of the whole order is set to the latest date for a line. As goods are received they are booked to the relevant line and the order status is set to part-received until all lines are completed. There is a caveat… once the order is authorised, printed and sent to the supplier in order to make changes re-authorisation is required. This makes it unsuitable where the order quantities are not fixed i.e. the requirements need amending after the order is raised.

Add a new PO delivery address

• The system company needs to be edited and an address added. There is a sidebar action which allows alternate addresses to be added. In order to use this as a delivery address the new entry must be designated as a shipping address.
• Step two is to add a new store for the shipping address within manufacturing setup and add a receiving location to this store.
• Lastly a Receive action should be added.

6.11 - Sales Ledger

How do I…?

Show the outstanding invoices for a customer?

Go to the sales ledger record and click the side bar action ‘Outstanding’ under Related Items.

Find out when a customer has paid and which invoices payment covered?

Under the customer’s account in sales ledger and look at the ‘All Invoices’ side bar link - if its paid you can click on ‘paid’ to see the cross reference transactions and therefore the payment. If the payment is unallocated use the ‘Outstanding’ link to find the payment.

Put a customer on stop?

Go to the customer under Sales ledger and look for the side bar action ‘Stop Account’

Refund a customer in credit?

1. Enter refund into cashbook as a cashbook payment (VAT = none) - GL code as appropriate
2. Enter SL journal for same amount to same GL code
3. Allocate SL journal to SL credit(s)

6.12 - Sales Order Processing

How do I…?

Make products available to sell?

There is a product lines table that is accessed via Logistics -> Sales Orders -> Product Lines. A product line can be linked to a stock or a service item and can also be specific to a customer if required. Products can be included in price lists.

Enter sales prices for items?

Go to Logistics -> Sales Orders -> Product Lines. The line to be sold is added here with its price and reference it back to the Stock Item from the drop down.

Set up a price list description?

Menu option Logistics -> Sales Orders -> Price Types

Allocate a customer to a price list?

In the sales ledger the customer can be allocated to a price type (list).

Set up a specific price/discount for a customer?

There are two ways:

1. Go to Accounts->Sales edger->Customer Discounts - you can then add a discount by product group that is taken off the price list price. So if, say, customer A gets 10% off Product Group X add it here. All prices for that product group should be discounted by this figure.
2. If its more granular (at the specific item level and not product groups) you would have to add a new product line for that item. But as well as linking it to the stock item when you add it link it to a customer as well and don’t link it to a price type (price list) - then the price that is displayed will be the specific one for the customer not the one from the price list

6.13 - Stock

How do I…?

Add an Item for sale

To add stocks you go to the menu option Manufacturing->Stock Items->Add a stock item OR Manufacturing->Stock Items and then ‘add’ from the sidebar. This adds the ‘internal’ stock information for stores and manufacturing purposes. To get them into sales orders then you need to add external information (i.e. price) which then looks at SO Product lines. Go here Logistics->Sales Orders->Products

Note that an SO product doesn’t necessarily have to be on stock.

Find out how much of an item I have sold?

When viewing the details for an item click the sidebar action ‘Show Sales Invoices’.

Find out what stock is at a particular location

Use menu option Manufacturing -> Stores, click the store you are interested in and then the location - then use the sidebar action ‘Show Stock Balances’.

7 - Glossary

Some terms that may help when thinking about concepts in uzERP.

A

Acknowledgement

A commitment from a supplier to advise a customer that a Purchase Order has been received. It usually details the items and/or services ordered and it normally implies acceptance of the order.

Actual cost

Cost actually paid for an item. This is very difficult to establish and record in a computer system, even for purchased items, since you don’t usually have the invoice at the time of receipt. Most companies use some sort of approximation. See “Average cost”.

Assemble to order

An arrangement where common sub-assemblies may be made and stored against a sales forecast and final assembly is performed only when a customer order is received.

Assembly

An item which is assembled from several others to make up a composite article. Assemblies are often categorised into sub-assembly and final assembly. See also “Component”, “End product”.

Authorise (an invoice)

An authorised invoice is one that has been registered, matched with a GRN and passed for posting to the Purchase Invoicing system.

Available-to-promise (ATP)

Existing stocks available for sale plus quantities and their due dates that are expected from manufacturing or purchasing operations and which are not already promised to customers.

Average cost

A cost per item stock unit maintained by uzERP for each store. It’s a moving average, based upon the contents of the item in the store and their values on arrival. See “Moving average”.

B

Back orders

Customer orders which should have been despatched, but which are still outstanding, pending receipt of the goods in question.

Backflush (components)

A process whereby uzERP automatically issues component items when products are made and allocates their costs as planned to the works order in question. Components are backflushed based on the current product structure used in the works order.

Backflush event

An event that triggers backflushing. Such events depend upon the way uzERP is configured at your installation. Possible events are Works Order completion, Sub-Contract Order receipt. See “Backflush (components)”.

Balance Location

A Stock Location which holds stock balances. Opposite to a “No-balance account”.

Bar-code

A series of alternating black bars and spaces that represent ASCII characters in a machine-readable form. All grocery and many other products have bar-codes printed on the packaging. uzERP can be interfaced to a variety of bar-code reading equipment.

Base Currency

Currency in which all financial transactions are recorded within uzERP. See Also ‘Twin Currency’.

Batch (Accounting)

A collection of transactions identified as an auditable set for input to a ledger.

Batch (Stock / Inventory)

A quantity of work to be launched or already work-in-progress. Also called a “Lot”.

Bill of Material (Structure or BoM)

A list of all the components (intermediates, sub-assemblies, raw materials, etc.) showing the quantity of each needed to make an end product. A single level Bill of Material is a list of all immediate components. The uzERP system, in theory, allows an infinite number of levels.

Bin location

A physical location within a store in which stocks are held. Bin locations may be racks or boxes or simply areas marked out on the floor. uzERP allows many items to be stored in a bin and many bins to be used for storing the same item, but for stock accuracy reasons it’s often helpful to keep one item per bin location.

Bin Card

A manual record of stock quantities available, together with historical details of stock movements, which is maintained for a single item of stock in a store or bin. uzERP has a stock display similar to a bin card for each item to provide a familiar function for operators used to manual systems.

Blanket Order

See: Call-off Order

Bottleneck

A restriction in the flow of work through the manufacturing facility caused by some lack of capacity at a crucial point or operation.

Branch

The uzERP contact system can store branches against a main contact record.

Buffer stocks

See “Safety stock”.

Build-through item

An item defined within the Bill of Materials as having components but which, in fact, never exists as an independent item. It is often used as a convenient grouping for a list of items common to several assemblies. A build-through item is a special kind of Phantom. uzERP does not yet included build through functions - this is planned for a future release.

Bulk issue item

Items which are not ordered via the MRP process, in line with calculated requirements. They are issued from stores for general use and not against specific production (or other) orders. n general, these items are low in value.

C

Calculated lead time

Lead time(s) for an item, calculated from its route(s), using planned batch size, set-up times, process times and pre-operation delay times. Compare it with the “Planned” and “Actual” lead times.

Call-off Order

A Call‐off Order is purchase order created to cover multiple deliveries from a single supplier, for example:

• For a long term supply from the same supplier
• An unknown delivery schedule
• Where precise quantities are not known until after delivery
• Where special pricing has been negotiated on an annual volume

See also: Call-off or Blanket Orders

Capacity

The total capability of a manufacturing facility under specified operating conditions. This is normally expressed in terms of hours per period for a work centre or resource type.

Capacity Requirements Planning (CRP)

The process of establishing the quantity of each chosen resource typerequired to support a given load.

Column

A relational database term. See “Relational database”.

Component

Term used in uzERP for any item in the Item table, be it piece part,raw material, intermediate item or sub-assembly which may be used to make another item. See also “Bill of Material”.

Composite Lead Time (CLT)

The length (in days) of the critical path for the manufacture of anitem from scratch, including procurement of raw materials. It also includes the “Inter-Level lead time addition” for every level, including Build-throughs, in the Product Structure. See “Manufacturing Composite Lead Time (MLT)”.

Consignment stock

Stock held on a customer site or in a third party’s premises but still owned by the manufacturer.

Consumable item

An item of stock not incorporated directly into a finished product but which are used as part of the manufacturing process (e.g. cleaning materials, lubricants etc.). If held within the uzERP system these items may be controlled on a re-order level basis and treated as overhead costs.

Contact

Term for an individual a customer, supplier or other associate of the company - this may be an account, lead or person.

Cost roll over

Process of updating the standard cost held by uzERP for every item in the system based on the latest cost.

Cost roll up

Process of updating the latest cost held by uzERP for every item in the system based on components and resource usage. Latest cost is updated for each item as things change so this is performed infrequently.

Credit check

Compare a customer’s outstanding debts against limits agreed forthat customer. Such limits may refer to the total value of the debts and/or the timely settlement of such debts.

Credit limit

A value which is agreed to be the maximum acceptable total of a customer’s outstanding debt.

Credit Note

A formal document that reverses a sales invoice. Goods can be returned to a designated Stock Location and a credit is raised on the Sales Ledger for the customer.

Customer part number

A code by which a particular customer identifies an item in uzERP. Different customers may use different customer part numbers for the same uzERP item and this is set up through the Sales Order Product Lines system.

Cycle counting

A method of checking the perpetual inventory record against actual balances. It involves planning a schedule for the store which ensures that all balances are checked at least once during a pre-determined “Count period”, more important items being counted more frequently than those that are inexpensive or don’t move very often.

D

Database

A repository for all the data associated with a system. uzERP has a single, integrated, relational database for all its systems. See “Relational database”.

Debit Note

The equivalent of an order which has no implications in the stock record. The stock may have been taken or there may be no stock involved or it may be to correct a previous error. Debit Notes are available or invoicing immediately. Opposite “Credit Note”.

Degenerate Structure

See “Structure loop”.

Delivery address (delivery point)

The geographic address to which deliveries will be made for a sales order. It need not be the same as the order address, the statement address or the invoice address.

Delivery lead time

The (Purchase) delivery lead time is the normal number of “Calendar days” that it takes to get a specific item from a stated supplier. See “Planned lead time”.

Demand

A demand is a set of requirements for an item from a source. There may be many demands for an item; they may be either independent or dependent. See “Requirement”.

Dependent demand

A schedule of dependent requirements.

Dependent requirement

A requirement for products, components and purchased material calculated by MRP and dependent upon other orders, for parent items, already in the system.

Despatch note

An advice note that details all items contained in a single delivery. It identifies the customer that will receive the goods and usually relates to an individual order.

Direct delivery

A term used when a supplier arranges for a third party to deliver goods directly to one of his (the supplier’s) customers without the goods appearing on the supplier’s premises. A normal stocked item may be delivered direct. See also “Non-stocked item”.

Direct item

The term given to items of inventory which are sold or used directly in mmanufacture, as opposed to consumables (indirect items).

Discount

An allowance or deduction granted by a supplier to customers in order to persuade them to buy more or to pay promptly, etc.

Documents

In uzERP terminology documents are

• Sales

  • Sales Order Acknowledgements
  • Pick Lists
  • Despatch Notes
  • Invoices
  • Credit Notes
  • Statements

• Purchases

  • Purchase Orders
  • Remittances

• Operations

  • Works Order paperwork

Drawing number/issue number

The reference number of the drawing or other specification of an item. Within uzERP this reference may be input into one of several fields on the item record.

Due date

The date at which an order or requirement becomes due.

Due quantity

The quantity expected to be received from an operation. It may be influenced by “Operation scrap”, either negative or positive. See also “Expected quantity”.

E

Economic Batch/Order Quantity (EBQ/EOQ)

A mathematically calculated order quantity which seeks to achieve an economic balance between stock holding costs and ordering / set-up costs. Larger order quantities require fewer orders / set-ups whilst smaller orders result in lower inventory levels. This can be seen graphically by plotting cost against batch size. There are a many models for calculating EBQ/EOQ.

Effective date

The date on which a set of components is introduced or terminated in a Product Structure.

End product

An item in the Item Master which is at the top of the Product Structure, which is made from components.

Engineering Change Note (ECN)

A document which authorises a change in the form, fit or function (and sometimes cost) of an item. It may change the drawing, the Product Structure, the recipe or the route.

Environment

The overall description of the company requirements under which the uzERP systems will operate. This includes the definition of facilities, stores, stock accounts and overall system controls.

Expected delivery

Anticipated arrival of goods at Goods Inwards, from a supplier. An expected delivery doesn’t become an expected receipt until it has passed inspection and been transferred out of Goods Inwards.

Expected quantity

The level of output expected from a delivery when it’s received into stores for use. You might anticipate some loss in Goods Inwards inspection and uzERP can plan for this. It’s also the output expected from a works order or operation. You might expect some loss or gain during the manufacturing process, so the expected quantity may not be the same as the order quantity. Sometimes called, “Yield”.

Expected stock balance

A predicted stock balance, calculated from current stock levels and expected receipts and issue data. It’s calculated by the Supply /Demand Review in uzERP.

Expedite

To speed up the progress of individual purchases, deliveries or works orders (often to the detriment of other planned work!).

Explosion

A process which starts at end-product level and works downwards. MRP works this way, so does an indented Bill of Materials print.

Extended pricing

A system in which a 3-dimensional table is used to ascertain a price for an item in a category of products for each customer. Given the item number, product group and customer, uzERP will provide from this table an absolute price.

F

Finished goods stock

Stock of end-product items which are held for the purposes of supply to an external consumer (i.e. customer).

Finite capacity planning

A procedure that establishes the sequence of work, as displayed in a work-to list, using capacity, amongst other things, as a constraint. Because uzERP has an open source RDMS it can be interfaced with 3rd party finite capacity schedulers.

Free issue (to a sub-contractor)

Materials or components that are sent to another organisation for specialist work to be performed. They’re usually returned under a different item number.

Free stock

The amount of stock of an item that is available for use. The actual definition of the term, “Free for use,” depends upon rules at your installation. See also, “Goods for sale” and “MRP-free stock”.

G

Goods for sale

Items that are available for sale by uzERP Sales Order Processing functions. Such stocks are contained in Stock Locations marked as saleable.

Goods Inwards procedures

The standard operating procedures used by the company for recording delivery, inspection and receipt of goods from suppliers. They may be recorded as routes or as stock actions in uzERP (from the the stock map).

Goods Received Note (GRN)

A document raised by the Goods Inwards department containing details of the quantity of items which have been received from an outside supplier - when goods are booked in against an order uzERP automatically raises a goods recievd note.

GRNI (Goods received not invoiced)

That proportion of the value of goods implied by a GRN that has not been matched with an invoice line or lines.

I

Indented Bill of Materials (BoM)

A report showing an parent item together with all its components right down to the raw material level; so-called because of the appearance of the display in which each subsequent structure level is indented.

Independent requirement

A requirement to supply goods that is input directly by the user or from another system, such as Sales, Warehouse Replenishment or Repair Forecasting. Such requirements are not dependent upon any other requirement known to the MRP process.

Indirect item

Item used by your company in the pursuit of its business but which isn’t sold or used directly the manufacturing process (i.e.: which doesn’t appear in the Product Structure). See “Consumable Stock”.

Infinite Capacity Planning

A method of showing the loading of individual work centres based upon orders and due dates and without taking into consideration the amount of capacity actually available at the work centre. It works because capacity constraints have been taken into account. uzERP is an infinite capacity planning system, it may be linked to finite capacity planning software.

Inspection

An independent operation performed either as part of the goods receiving process or as part of the manufacturing process during which the items are checked for conformance to specification.

Inventory

This is the general term given to all types of stock that occur and are recorded in uzERP.

Invoice

A formal document requesting payment for goods or services supplied to a customer. Details of each invoice are held in Sales Invoicing system and in the Sales Ledger against each customer.

Invoice address

The geographic address to which invoices will be sent. It need not be the same as the delivery address, the order address or the statement address.

Invoiced price

The price quoted and used for extending invoice amounts. When a purchase invoice price differs from the agreed price, the Purchase Price Variance results.

Invoice register

uzERP maintains a list of both Sales an Purchase invoices.

Item (Stock)

Any item which is stocked, made, bought or otherwise handled by the system, e.g. tools, raw materials, end products, intermediates, etc. Items are held in a table containing descriptive and control information about all items handled by the uzERP system.

Item number

A code which is used to identify an item uniquely to uzERP.

Item specific unit of measure

Unit of measure specific to an individual item which overrides or adds to the standard conversion table. It can be used to convert area to weight, for example, using a conversion factor based on grammes per metre squared.

J

Job

A batch of production work issued under the authority of a works order for processing on the shop floor.

Jobshop

A factory or factory area which makes batches of products to customers’ orders, on a non-repetitive basis. Handled in uzERP as a Make-to-order environment.

Just in time (JIT)

A production control system that works by requesting components from the previous stage (or outside supplier) when they’re needed, not before. Work is authorised only when a batch of components is (or will be) needed at the next stage of manufacture. Batches are as small as possible and are “Pulled” through the system using tokens of some kind. JIT is a wide philosophy, not just a production control method. It relies on increased Production Engineering effort to reduce set-up times for example, and changed attitudes to Quality Control. uzERP has a number of features that help JIT implementation.

K

Kit issue

A single transaction resulting in stock issue transactions for all the outstanding components required for an individual works order. This is yet to be implemented in uzERP.

Kit list

A list of all components together with quantities required for a specific works order.

L

Lead time

The time taken to convert a set of components into another product (item), from the time that the components are picked from the stores until the time the product is received. See “Planned lead time”, “Actual lead time” and “Calculated lead time”.

Live item

A live item is usually one that has, or will have, requirements. It may also be one that is still in use at a customer site, even though no future requirements are expected.

Lineside stock

Stock which is kept adjacent to the process where it will be required and which tends to pass into the process without an explicit transaction. See also “Bulk issue”. In uzERP lineside is a term used for stocked items that are often associated with “Backflushing”.

Load

The amount of work lined up for a facility, work centre or resource, usually expressed in hours. The demands placed upon work centres or resources by released, firm and recommended orders.

M

Made-in item

An product or intermediate item that is sourced primarily in manufacturing.

Make-to-order

A type of manufacturing operation in which completed end products are only produced when a specific customer order is received. Also called “Lot for lot” or “1:1” or “One to one”. Also a type of ordering in MRP in which an order is recommended for every requirement and no batching takes place.

Make-for-stock

A type of manufacturing operation in which completed end products are produced against a sales forecast and passed to a “Goods for sale” Store/Location.

Manual allocation

A system by which stock may be reserved for individual customer orders. It is normally used to make specific allocations.

Manual pricing

Selected items may have no selling price recorded in the system. The system will prompt for a price to be entered at the time the order is accepted.

Manufacturing Composite Lead Time (MLT)

The length, in days, of the critical path to make an item, assuming that all buffered items are available immediately (and, therefore, excluded from the critical path). It also includes the “Inter-level lead time” for every relevant level in the Product Structure.

Master Production Schedule (MPS)

The company’s overall procurement plan, expressed as time phased requirements for end-products (or planning groups) and spares, which is to be placed on Manufacturing.

Master Production Schedule (MPS) item

An item (in the Item Master) which is used for Master Production Schedule planning.

Material Requirements Planning (MRP)

A system of calculating recommended orders and changes to firm orders for manufactured and purchased items. It uses bills of material, inventory, existing orders and master schedule information.

Max/min or min/max

A method of stock control which relies upon setting a minimum and maximum stock level figure for each item. When a stock issue causes the stock quantity to fall below the minimum level some more of the item are ordered to bring the stock figure to the maximum.

Moving average

Arithmetic mean of a set of the most recent values. See Weighted average cost.

N

No-balance Location

Stock Location representing a location which is unreal or outside the stock system, e.g.: Sold Goods, Stock Adjustments, etc.

Non-stock item

An item which is not normally stocked but may have to be bought or sold using uzERP functions. Such items need no record in the Stock Items table but could be set up in Purchase Order Product Lines to make ordering easier. Items that are not normally sold but for which an order has been accepted can be processed as non-stocked items. Items which are never stocked but are frequently sold should be registered in the Sales Order Product Lines table.

Normalisation

A relational database term, part of the process of database design. It’s a data analysis process in which you decide what tables to have and which data goes into them.

O

Operation

The smallest discrete unit of work, carried out during the manufacturing process, that is taken into account for planning and control purposes.

Operation sequence

The sequence in which operations are planned to be performed. In some industries it’s simply calculated from the order due date and the duration of each operation. If you have a mix of work and many orders open at the same time, deciding which is the best operation to pick out of the queue next can be a very complex business.

Order

An instruction to procure or deliver. See “Sales order”, “Purchase order”, “Recommended order”, “Released order” and “Works order”.

Order address

The geographic address from which an order was accepted and to which acknowledgement will be sent. It need not be the same as the delivery address, the statement address or the invoice address.

P

Parameter

A piece of control data that is held in the database or passed to a program and which affects or controls what that program will do. There is a Set Up module in uzERP that controls these items.

Parent item

The top level item in a single level Bill of Material

Period end

The end of a business period, implying the end of a set of transactions. They’re usually financial transactions but may be inventory or other, similar transactions.

Perpetual inventory

A method of stock-take and stock checking which relies upon a continuous, audited method of counting stock levels of different items throughout the year rather than at a single stocktaking point. The frequency of counting is often related to an item’s ABC analysis code.

Phantom

An item that is included for planning or other purposes and does not form part of the engineering design. Phantoms are not real items and are not usually stocked, although they may be in uzERP. Phantoms can be used for Planning Bills, using up obsolete stocks, ordering free-issue materials and so on. See “Build through”.

Pick

The act of withdrawing stock from stores prior to despatch to a customer, inter-stores transfer, issue to work-in-progress, etc..

Picking List

A list produced by uzERP to tell Sales Stores operators what to pick in order to satisfy customer delivery requirements for a specified period. See also “Kitting list”.

Planned lead time

The length of time, in working days, taken to convert a set of components into a parent item. It’s measured, for in-house manufacture, from the day work starts to the day that the finished item is expected to arrive into stores. For purchased items it’s measured (again in working days) from the day when the order must be placed to the day when it’s received, inspected, into stores. See “Delivery lead time”.

Price change effectivity

A means of registering imminent price changes against a list of prices for an item. The price change may be a value or a percentage and can be applied automatically to some or all prices for an item when the effectivity date is reached. The time of day for the price change is controlled by when the price change program is run.

Price types

Flexible method by which uzERP allows prices to be managed. Price lists may be established by item, sales office or customer, customer type by setting the price type in the customer record. May contain details of discounts and surcharges which may apply. Price list changes may vary over time (see “Price change effectivity”).

Price unit

The units in which an item is priced for sale. uzERP will convert from one unit to another when necessary, provided a conversion factor has been provided for the item

Process time

The time during which resources are being used to convert component(s) to a single unit of an end-product. Often called, “Process time each” because it’s measured per piece or per unit, not per batch. See “Set-up time”.

Promotional pricing

The application of special prices to selected goods for a finite period of time. See “Coded pricing”, “Extended pricing”, “Manual pricing” and “Simple pricing”.

Purchase order

A written instruction to a designated supplier to provide a service or product, normally specifying quantity and delivery date. In uzERP they may have many lines, each for a different item, including non-stock items. Lines may be for “Blanket order”, “Scheduled order” or a single delivery.

Purchase requisition

Requisition for a purchased item. A purchase order is seen by the system as a ‘requisition’ until it is authorised.

Q

Queue Time

See “Pre-op wait time”.

R

Raw material

Components that are converted during the manufacturing process into things that can be used or sold. Raw materials are normally purchased items (the bottom of a structure in uzERP). Examples are cement, perfume, fabric, steel and so on.

Received line

In the uzERP purchase order system a “Received line” is entered on an invoice for every part of matched Goods Received Note (GRN) line.

Relational database (RDB)

A method of storing data that makes it easily accessible to everyone. All data is stored in tables in a relational database. As you would expect, tables have rows and columns. A table contains data that describes a single class of things that are of interest (e.g. Cusomers). Each row contains data about one of the things (Customer ‘Jim Smith’). Each column contains a piece of data that describes the thing (that is an attribute) - this might be the telephone number. Also see “Normalisation”.

Relational database management system (RDBMS)

Computer program which provides access and update capability for the Relational Database - uzERP uses the postgreSQL RDBMS.

Released order

A works order with authority for work to proceed.

Resource

Something that is used or consumed when an operation is performed at a work centre. See “Resource type”.

Resource type

A set of resources which have similar characteristics and which are grouped together for capacity planning and shop control purposes. They could be machines or tools or a group of workers with the same skills, for example.

Roles

uzERP’s user security model is ‘role based’ such that each user has a role which determines the actionsthey can carry out and menu options they can see.

Rough-cut Capacity Planning (RCCP)

A method of checking whether you have enough capacity to make what’s in the Master Production Schedule.

Row

A relational database term. See “Relational database”.

S

Sales order

An obligation to deliver items or services to a customer, usually at a specific time and for a specific price.

Sales order status

An indication of the stage that a sales order has reached. Examples are, “Quotation supplied”, “Despatched”, “Invoiced”, “Closed”, etc..

Sales Order Product Line

A product sold to the Company’s external customers. uzERP’s Sales Order Processing system looks at the product line table when setting up orders - the product lines may be stock items or non stock.

Scrap

Items that are lost during manufacture or as a result of failing some inspection on receipt or in the stores.

Scrap percentage (scrap%)

A planning figure that causes MRP, costing and other systems to increase (or decrease if it’s negative) the size of each order it recommends. This ensures that enough items actually get made to satisfy the requirement, taking into account the fact that some might be lost.

Service Line/Service Invoice

In the uzERP Purchase Invoicing a “Service invoice/line” is used to record invoices and invoice lines which will not have an associated Goods Received Note, e. g. carriage, Professional Services, etc.

Set-up time

The time required to change a machine from manufacturing one item to another. Set up times considerably affect the ability to manufacture in small lots (as in Just-in-Time production) and should be reduced to their minimum levels through Production Engineering effort.

Shift pattern

During production recording uzERP will request a shift designation to record time and waste.

Shop floor paperwork

A pack of documents that (usually) accompanies work as it travels around the factory. It’s often used to collect data about which actual work centre and resources were used for each operation as well as the times and numbers used. Quality data may be collected too. A whole set of shop paperwork may include a route sheet, operation booking slips, scrap booking slips and component requisitions.

Standard cost

The Frozen or Standard cost is the planned cost of an item including the cost of all components, resources and overheads used in its manufacture.

Structured Query Language (SQL)

A standard query language associated for extracting information from a Relational Database. All uzERP data is available to you, for query and for update, using SQL.

Stock transaction

A movement of some stock. All stock transactions should be entered into uzERP, where they will be timed and dated and costed. See “Planned stock transaction”, “Unplanned stock transaction” and “Authorised stock transaction”.

Stock unit of measure (UoM)

The units in which the stock of an item is counted in the stores. It’s a field in the Stock Item table that is entered when the item is added. uzERP converts from stock units to usage units, delivery units, price units, selling units, etc. based on item specific or system wide conversion factors.

Stocked item

An item which is, has been or will be, held in the uzERP stock record.

Stock Location

uzERP uses Locations to provide a flexible method of recording physical and logical categories of stock that is held in a Store.

Stock Location map

A diagram that shows the Stock Locations used in a particular company and the stock movements that have been authorised between them.

Store

A place where stocks are held. It could be a physical place, like a warehouse, or it could be a logical sub-division of stocks. You could, for example, keep all indirect items in a different store from direct items, even though they’re physically in the same warehouse.

Structure loop

A situation where an item is deemed to be made from itself at some level in the Product Structure.

Sub-assembly

A term used in discrete manufacturing industries to describe an intermediate level in the Product Structure.

Sub-contract

Work, done to your own deign and, perhaps, normally done in your own factory, sent to another factory to relieve pressure on in-house capacity. Work can be sub-contracted to an outside supplier or to another factory in your own group.

Supplier

A company from whom you purchase goods or services. Also called a “Vendor”.

Supplier catalogue

A list of items that you buy, or have bought, from a particular supplier. It contains UoM and pricing data. The Purchase Order Product Lines allows you to input various codes and prices for items purchased - these are then linked to items in the stock items table where the item is stocked.

Supplier part number

A code by which a particular supplier identifies an item in uzERP. Different suppliers may use different supplier part numbers for the same uzERP item - this is handle by Purchase Order Product Lines.

Supply / demand review

A process in which a requirement schedule is compared with a schedule of expected deliveries to give a profile of expected stock levels stretching into the future. The supply demand review is available for both sales and purchase items in the Logistics system.

T

Table

A relational database term. See “Relational database”.

Transaction history

Table of transactions (usually stock movements or financial transactions) kept for historical or audit reasons.

Transaction reference

A unique, numeric auto-generated reference that identifies each transaction in the system.

U

Unit of measure (UoM)

Code that indicates the units in which a quantity is measured. Examples are LITRE, EACH, METRE, TENS, BOX. uzERP will perform a variety of UoM conversions for you, based upon a UoM conversion table.

Unplanned stock transaction

A stock transaction which has not been expected by any planned event. If such transactions occur on an item used in manufacturing, or allocated to customer orders, then this represents a change plan. Such a change inside the normal planning horizon for the item is a “Front end change”. Examples of unplanned stock transactions are stock losses and gains, scrap greater than planned, component issue too early and out of planned sequence, etc..

V

Vendor

See “Supplier”.

W

Warehouse

The physical store where stock is kept. You can control many warehouses with uzERP - the terminology used in uzERP is store.

Weighted average cost

Cost per unit calculated by adding the actual cost of items received into the store to the cost of those already in stock.

Work centre

A place where work takes place in the factory. A WIP operation takes place at a work centre and resources and components are used or consumed there. A route is a planned journey through the factory with each operation or stage taking place at a work centre. Work centres may have costs and overhead formulae associated with them in uzERP.

Work-in-progress (WIP, wip, w-i-p)

Work that is at some stage of completion in your plant, including components, part finished (PF) and completed items. The term “Work-in-progress” is sometimes applied to the work itself, sometimes to the stock involved and sometimes to the value of those stocks.

Work-to list

A list of operations at a work centre which are, or will soon be ready to start.

Works order

Authority for components to be consumed and for work to be done.

8 - Requirements

Required OS Packages

These package names are from Ubuntu, other distributions may use different names.

• apache2 (Using either mod_php or proxying to php-fpm or other fcgi. Alternatively Nginx/php-fpm)
• postgres (version 10.x)
• memcached (Not strictly required, because uzERP will use the local disk if memcached is not installed, but highly recommended)
• fop
• php (version 7.x)
• php-memcached
• php-pgsql
• php-bcmath
• php-xml
• qpdf

Optional OS Packages

• cups (cups print server, required for direct printing to printers)
• postfix/Exim email MTA for sending documents from uzERP, e.g. Invoices, Purchase Orders)
• ghostscript (PDF thumbnails use the ‘convert’ utility)
• php-curl (used by sentry logging)

Development Requirements

The following are only required to build a uzERP release package. Official, pre-built release packages are available from github.

• npm (Node package manager to install gulp)
• gulp (gulp task runner for building css and javascript)
• composer (for installing PHP dependencies)