Configure a customer, configure taxes, price lists, basic sales to payment process, reporting.
These tutorials and many new topics will be available soon in a new book Working with webERP (on-line here and printed book available for purchase).
New sections will include:
Manufacturing Automation. Forecasts and production schedule. Material requirements planning (MRP). Purchasing based on demand. Work orders. Kittting.
Projects. Create projects, forecast labour, enter time and materials, report on cost and schedule.
Human Resources. Create employees, timesheets, timesheet reports, security roles.
Financial Reporting.
Reporting.
Customizing.
If you find this information useful, please say hello using the contact form and introduce yourself in a post to the webERP project forum. The community would love to meet you!
It is important each user has their own login with a password only they know. Also, each user must be assigned a suitable Security Role which allows only those operations within their scope of work to be performed. This is especially important if you will be using webERP in a regulated or controlled environment.
Default (out-of-the-box) security permissions generally satisfy a common demonitor of the webERP community, but eventually may be found lacking. Should that happen, it may be more efficient to develop bespoke security roles and security token assignments based on the structure, staff and relationships of the company, than to re-define the default implemention.
The webERP security model is comprised of four components:
Security Role
Security Roles are user roles with assigned security tokens (each user role has it’s own security role, and more than one security role can have the same security tokens. The webERP system administrator can edit the default security roles and create additional roles if needed for more selective control.
Each user (login ID) is assigned a Security Role.
To edit the Security Role assigned to a user, click [Main Menu > Setup > General > Users Maintenance] and edit the desired user (as a security role Administrator user).
Don’t think of the access a specific user requires to do their job, think of the role or job they perform, and assign it group (a “security role”) and make them a member of it, and then provide the group (the security role) with the necessary access.
Security Token
Security Tokens are used by webERP to control access to a page.
A Security Role is assigned one or more Security Tokens.
To view or edit the Security Tokens assigned to a Security Role, click [Main Menu > Setup > General > Access Permissions Maintenance] and edit the desired role.
Page Security Level
Each webERP script is assigned a Page Security Level, which is a Security Token a user must have to be given access to run the script.
To edit the Page Security Level, click [Main Menu > Setup > General > Page Security Settings] and edit the desired page.
In-Page Security
Pages (scripts) control the data, buttons and links presented according to any or all of the Security Tokens assigned to the Security Role of the user.
Users and assigned Security Roles
Default (out-of-the-box) Security Roles
Accountant
AP Clerk
AR Clerk
Inquiries/Order Entry
Manufact/Stock Admin
Purchasing Officer
Customer (login only)
Supplier (login only)
System Administrator
SCC Employees and Security Role
The following organisation chart shows SCC employees with their assigned security role.
E.g. Miquel DeLazes > Security Role: Manufac/Stock Admin [Main Menu > Setup > General > Users Maintenance]
Security Roles and Security Tokens
Miquel Delazes, by being assigned the role “Manufact/Stock Admin”, is given security tokens 0 (Main Index Page), 1 (Order Entry/Inquiries customer access only), 2 (Basic Reports and inquiries with selection options) and 11 (Inventory Management and Pricing)
To create or edit a user Security Role: [Main Menu > Setup > General > Access Permissions Maintenance]
Examining the security role “Manufact/Stock Admin” shows which Security Tokens are assigned to Miquel Delazes through his Security Role “Manufact/Stock Admin”.
In his role as “Manufact/Stock Admin”, Miquel will need to search, create and edit Items, which is accomplished using the “SelectProduct.php” script.
E.g. [Main Menu > Inventory > Maintenance > Select an Item] and click [Seach Now].
Access to the SelectProduct.php script is controlled by the Page Security Level.
Page Security Levels
To view or edit the page security levels (aka script security levels), click [Main Menu > Setup > General > Page Security Settings].
It can be see that the SelectProduct.php script (aka page) has been assigned “Basic Reports and Inquirires with selection options”, which is assigned to the “Manufact/Stock Admin” security role assigned to Miquel as we saw previously.
In-Page Security
A page itself can restrict access and fine-tune security role, security token assignment and security level script assignment.
For example, examine the SelectProduct.php script. User Miquel will not be shown pricing, supplier purchasing or cost information because his “Manufact/Stock Admin” security role does not have Security Token 12 (Prices Security), Security Token 9 (Supplier centre – Supplier access only) or Security Token 18 (Cost authority).
Unless you are only selling services, you will need to purchase product to sell, or raw materials to manufacture into product to sell.
An Enterprise Resource Planning (ERP) system offers significant advantages for sales operations by centralizing customer data, product information, and pricing into a single, unified platform. This integration streamlines the entire sales process, from order entry to fulfillment, by eliminating manual data re-entry and reducing errors. Furthermore, ERP systems provide real-time visibility into inventory levels and order status, enabling sales teams to provide accurate information to customers and manage expectations effectively. The robust reporting and analytics capabilities within an ERP allow for deeper insights into sales performance, customer trends, and forecasting, empowering data-driven decision-making. Ultimately, leveraging an ERP for sales enhances efficiency, improves customer satisfaction, and drives revenue growth through optimized workflows and informed strategies.
Features of using webERP for selling include:
Efficiency. Items, Customers, Sales Orders, Shipping Orders, etc. are managed within one controlled system. Fix a problem once and it’s fixed everywhere.
Visibility. Because all data and transactions reside and are performed in a single system, it is also available to all users (subject to security roles and privileges).
Scalable. Readily scales with users, items, and customers, and can adapt to changing business processes.
This chapter introduces the sales cycle, starting with creating a product with initial stock, and creating a customer. Then a draft sales order or quote is created for the product, the order is confirmed, and then picked and shipped. The customer is invoiced, and finally payment is received. Concepts such as Units of Measure (UOM), Cost Price, Categories and Taxes, and Fiscal Periods are introduced along the way.
The Aircraft Wireless product will be used as an example. Documentation will be stored in the webERP Knowledge Base (integration with WackoWiki CMS).
Goals
Receive purchase orders from a customer.
Ship goods to a customer from inventory.
Receive payment from a customer.
Sales Terms
A Customer is a party who purchases goods or services from a Supplier.
A Purchase Order is a request from a purchaser, for a specific item and according to specific terms. The purchase order is generally considered legally binding when the supplier reports the order was accepted.
O2C – Order to Cash – the customer sales and payment process.
Order-to-Cash (O2C) Process
The sales cycle is a sequential process that starts with identifying a prospect or lead, possibly by clicking on an online ad, answering a cold-call, or just walking into your store, progresses to a paying customer, and then repeats.
Identify lead
Quote sale of product or service
Convert the lead to a sale
Ship goods or perform service
Invoice customer
Receive payment
Repeat
Not all companies and circumstances require all steps, or may change the order of some steps depending on the product and customer.
The high-level sales and payment process cycle is commonly called Order to Cash, or O2C.
webERP Sales and Accounts Receivable
There are five primary tasks associated with sales orders and accounts receivable in webERP.
Counter Sales
Create order, invoice and receipt records in one process (order location is “Cash Sales Customer”).
Order Process
Enter order > Print order and dispatch note > Confirm quantities dispatched and invoiced > Print invoices and send to customers.
Produce and Send statements
Perform during month-end tasks.
Enter Customer Receipts
Enter multiple cheques in a one batch or single batch for each transaction listed on a bank statement.
Allocate Receipts and Credits
Allocations create exchange differences between invoice rate and payment rate (can be un-done and re-done at any time).
Step 1. Create a sales order in response to a customer purchase order.
Step 2. Advance Sales Order to Quototion status (the cost is determined).
Step 3. Advance Sales Order to Confirmed status (a contract now exists and the order can be processed).
Step 4. Process order.
Step 5. Create a Shipping Order to trigger shipping the ordered goods.
Step 6. Assign and pick shipment.
Step 7. Complete the shipment, which is a trigger for the invoicing procedure.
TODO replace flowchart with swim-lane drawing.
Security
We will login as user “mnestor” (Mary Nestor), who is assigned the Administrator security role and has permission for almost all operations (except for some finance related operations which will require a user with the Accountant security role).
In actual use however it is important each user has their own login with a password only they know. This allows correctly identifying the person performing an operation and provides tracibility. This is especially important if you will be using webERP in a regulated or controlled environment.
Default (out-of-the-box) security permissions generally satisfy a common demonitor of the webERP community, but eventually may be found lacking. Should that happen, it may be more efficient to develop bespoke security roles and security token assignments based on the structure, staff and relationships of the company, than to re-define the default implemention.
Setup
Before customers can be created the following information is required:
Currencies – the currency of the customers’ account.
Sales Types – the sales type is combined with the currency of the customer to determine the price list applicable to the customer. Item prices are held against sales types and currencies, and each customer must reference a sales type. The sales type typically reflects if a sale is a trade sale, retail, wholesale, indent, cash sale, special sale, etc., and as many many sales types as necessary can be created. A Sales Type is required to set an Item Price and scripts may assume at least one Sales Type exists.
Credit Status – indicate the credit-worthiness of a customer. Each customer must reference a credit status type and some credit status records can be configured to prohibit invoicing.
Payment Terms – terms governing payment associated with a customer. As many terms records as necessary can be defined. The customer must reference a parcular payment terms.
Tax Groups – the groupings of tax authorities the supplier must collect tax for on customer sales. Each customer branch must refer to a tax group. Sales to these branches will automatically calculate the tax based on where the sale is from and the tax category of the item being invoiced.
After cresting a customer a branch must be created. Accounts receivable requires customer branch information, such as delivery address. The following information must be entered before a customer branch can be created :
Sales Areas – for reporting and analyzing sales by area. GL integration can be configured to query the area of a customer to determine the GL account for posting sales to. Each customer branch must referance a sales area (define a “Default” area if more specific sales areas are not needed).
Location – somewhere stock can be held, e.g. a warehouse. Each customer branch needs to refer to the stock location for it to draw stock from. If there are multiple locations, the one that is most freight efficient to draw stock from is preferable.
A sales person must be designated for each company branch who is responsible for managing the sales relationship and takes credit for sales to the branch. If sales people are not necessary for your business, define a single salesperson naned “Default” or similar.
[Main Menu > Setup > General Setup > Currency Maintenance]
Sales Types
[Main Menu > Setup > Receivable/Payables Setup > Sales Types]
Credit Status Codes
[Main Menu > Setup > Receivables/Payables Setup > Credit Status]
Payment Terms
Payment terms were configured in the Purchasing with webERP tutorial and are shown again here for convenience.
[Main Menu > Setup > Receivables/Payables Setup > Payment Terms]
Tax Groups
Tax groups were configured in the Purchasing with webERP tutorial and are shown again here for convenience.
[Main Menu > Setup > General Setup > Tax Group Maintenance]
[Main Menu > Setup > General Setup > Tax Authorities and Rates Maintenance]
[Main Menu > Setup > General Setup > Tax Authorities and Rates Maintenance > {CRA} > Edit Rates]
[Main Menu > Setup > General Setup > Dispatch Tax Province]
Taxes are more complicated however when selling, and can depend upon not only on the location of the seller but also that of the buyer, and where custody of goods changes.
The first customer for the Aircraft Wireless is B&E Submarines, a Canadian company operating in the province of British Columbia. B&E will be paying in advance for development costs and the first 10 Aircraft Wireless units.
B&E is located in a different province in Canada than the SCC. the SCC will need to collect 5% of a sale to B&E for GST, seperately collect 7% of a sale to B&E for BC PST and remit both to the CRA (the SCC has not registered for BC PST but will do so if the Aircraft Wireless product is a succes, afterwhich will submit BC PST directly to BC)
A new tax group “CRA BC HST PST” will be created and B&E will be switched to the new group.
TODO add screenshots and descriptions.
Sales Areas
At lease one sales area must be defined. Create a 000 (Default) sales area.
[Main Menu > Setup > Receivables/Payables Setup > Sales Areas]
Inventory locations were configured in the Purchase with webERP tutorial but are presented again here for convenience.
[Main Menu > General Ledger > Maintenance > Bank Accounts]
In addition to entering the bank account information, the user must also have authorization to use the bank accounts.
Bank account authorization can be accessed either by user or bank account.
[Main Menu > General Ledger > Maintenance > User Authorized Bank Accounts]
Set Price
Items to be sold will require pricing. This may have been done when the item was created (see tutorial Manage Parts, Suppliers and BOMs with webERP), if not a price must be set (entered) now.
webERP includes price lists but they will not be covered in this tutorial.
[Main Menu > Inventory > Maintenance > Select an Item > {select item} > Maintain Pricing]
Create Customer
TODO describe creating customer.
Sell Item
Before an item cas be sold there must be stock on hand of it.
Issue Order
TODO describe issuing order.
Ship Order
TODO describe shipping order aka transfer custody for an item to the customer.
Receive Payment
TODO receive payment from customer.
Reports
A variety of reports are available for managing and understanding customers orders and paymentds, indicating item demand, open orders, and customers behind in payment.
Reports that you may find useful include:
Unit Sales for a Period
(submitted to webERP project by efeoli (Enrique) to illustrate test results 2024-11-11)
Change Happens
It happens that an order may need to be revised.
Cancel order in whole or in part for items the customer no longer requires.
Modify orders to mitigate reduce cost, modify delivery date, add forgotten items, substitute an item for some reason, or a multitude of other possible changes.
Summary
This completes the overview of selling with webERP. In this chapter we started by creating a product and creating initial stock we had on hand. We then created our first customer, issued a quotation to them for the product, and continued the workflow by converting the quotation to a sales order, shipping product the customer, invoicing the customer and finally accepting payment.
In the next chapter, we will take a break from operational use and dive into Accounting and Finance, and see how the buying, manufacturing and selling we’ve been doing is reflected in financial reports.
webERP is mature web-based open-source ERP (Enterprise Resource Planning) software that supports best practises and multi-user business administration, purchasing, sales, manufacturing and standard double-entry accounting.
The webERP Knowledge Base stores notes and documents/files related to Items, Suppliers and Customers. webERP will be configured to use WackoWiki for its underlying CMS.
Goal
Configure webERP to use for the Swift Construction Company (the SCC),
The SCC is a manufacturing company located in Calgary, Alberta, Canada, operates in Canadian funds and interacts with Canadian and international suppliers and customers.
Procedure
Log into a webERP site using the admin user credentials provided by your systems administrator (the credentials entered into the new site web auto-installer) and create a new user with administrator privileges (e.g. “mnestor” (Mary Nestor).
email: e.g. mnestor@swiftconstruction.com
system administrator privileges
The original admin user cannot be deleted because it is the start of the tracability chain.
In actual use however it is important each user has their own login with a password only they know. This allows correctly identifying the person performing an operation and provides tracibility. This is especially important if you will be using webERP in a regulated or controlled environment.
Default (out-of-the-box) security permissions generally satisfy a common demonitor of the webERP community, but eventually may be found lacking. Should that happen, it may be more efficient to develop bespoke security roles and security token assignments based on the structure, staff and relationships of the company, than to re-define the default implemention.
Some data may exist in a new database and can generally be deleted if desired to avoid user distraction and confusion.
Location
I will create a new location “Shopton” for the SCC headquarters.
Note: Delivery Address 1 must be given a value (e.g. attempting to create a purchase order without line 1 will cause a “missing delivery address” error).
After creating the new location, change the location of the administration user to the new location (and of any other users).
Currencies
I will create a new CAD currency as some items will need to be purchased in Canadian dollars. webERP will obtain currency exchange rates from either Google or the European Central Bank (Main > Setup > General > System Preferences).
“CAD” is called the “Functional Currency” because it is the currency the Swift Construction Company operates in.
[Main Menu > Setup > General Setup > Currency Maintenance]
Company Preferences
Operating practices for a specific company are configured in the Company Preferences screen (webERP supports multiple companies and the desired company is selected at login).
[MainMenu > Setup > General > Company Preferences]
System Parameters
General system-wide behavior is configured in the System Preferences screen. I will quickly review some interesting parameters and give more detail on a a few.
Db Maintenance: Daily
The “OPTIMIZE DATABASE” query runs daily when the first admin user logs in. Setting this to ‘Allow ‘SysAdmin Access Only” prevents normal users from logging in which can be useful when performing maintenance but users already logged in are not affected (will need to work with your server system administrator if for some reason you require that no users can be logged in except yourself).
Date format: Y-m-d.
Unless you are forced, use ISO 8601 dates for clarity over familiarity (e.g. 2017-03-08 instead of March 8, 2017 – or is that August 3rd?.
Frequently Ordered Items: 0.
I don’t know how this variable is used and will have to experiment later.
Sales Order Allows Same Item Multiple Times: Yes
In general, I don’t want to block any operations and will assume users know what they are doing (and have a backup).
Languages to Maintain Translations for Item Descriptions: None
Don’t complicate things initially.
Picking note must be produced before an order can be delivered: No
Again, don’t complicate the process to start with.
Auto Update Exchange Rates Daily: Automatic
Rates sourced from the EU.
Create Debtor Codes Automatically: No
I will use my own mnemonic codes (if set to Yes, a sequential integer will be assigned).
Create Supplier Codes Automatically: No
I will use my own mnemonic codes.
Country of operation: Canada
Used when calculating shipping costs.
Purchase Order Allows Same Item Multiple Times: Yes
I will revisit this later, but at least initially I don’t want anything to block operation.
Automatically authorise purchase orders if user has authority: Yes.
Will disable when someone else is creating new purchase orders.
Financial year ends on: December
Most common.
Maximum Size in KB of uploaded images: 300
Default value, may require new photos and screenshots to be reduced before uploading.
Directory to store images: part_pics
Same name used in weberpdemo company.
Directory to store reports: reports
Same name used in weberpdemo company.
Wiki application: WackoWiki
Items, Suppliers and Customer pages have a link to the “Wiki Product Knowledge Base” where supporting notes can be entered, including links to related information and document files (e.g. PDF, DWG, etc.). WackoWiki must be seperately installed and configured and Wiki Path provided by your system administrator.
Inventory Costing Method: Standard
webERP also supports weighted average but Standard Costing is more obvious for starting with.
Auto issue components: Yes
Automatically decrement items from stock according to the BOM for an Item when it is manufactured to reduce admin effort.
Prohibit Negative Stock: No
Keep operations non-blocking but this may be safe to assume and will enable later. I don’t know how this is implemented or if it has an effect on system performance.
Log Severity Level: All
In general, it is good to see all log entries initially for familarity and reduce later as you more familiar with system. You will need system user access to the server to vew the log files(“Path to log files” is provided by your system administrator).
Controlled Items Defined At Work Order Entry:
Yes. When set to yes, controlled items (items with individual or batch/lot identification) are defined when a work oeswe at the time of the work order creation (otherwise controlled items ) are entered at the time the finished items are received against the work order
Auto Create Work Orders: Yes
This causes work orders to be automatically created for the default factory location if a sales order is entered and cannot be satisfied by the current inventory quantity.
Default Factory Location: Shopton
The location for automatically created work orders.
Manager email addresses: provided by your IT services provider
You may want to use a common email address for manager email messages at least while becomming familiar with webERP.
Using Smtp Mail: credentials provided by your email service provider
[Main Menu > Setup > General > System Parameters]
Summary
This completes basic webERP configuration. More complex configuration will be explained in context. E.g. bank accounts will be presented in the contect of Purchasing or Selling.
