Invoicing An Order

Selecting an Order To Invoice

All invoices require a sales order to be entered first.

From the main menu select the orders tab. Select Outstanding Sales Orders Maintenance. This page shows all the orders outstanding. If the order number is known it can be entered on this screen to select the order to invoice. Hit search orders and the order should show below, together with links to modify the order, print the packing slip and to invoice. Click the link to invoice the order.

Producing An Invoice From A Selected Order

Having selected an order to invoice the order line comes up for confirming the quantities of the order that were dispatched. If the quantity dispatched differs from the order the difference is recorded in the table OrderDeliveryDifferencesLog - and a report is available to show the orders that were not able to be delivered with the first dispatch. There is also opportunity to enter the freight charge and if necessary enter the tax charge - which will normally be calculated automatically based on the tax authority of the customer branch being invoiced. The date of the invoice is defaulted based on the time of day and the settings in config.php. If the hour (in 24 hour format) is after the setting of $DispatchCutOffTime in config.php, then the following day is deemed to be the invoice date, alternatively the invoice date will default to today. Where not all lines on the order are being invoiced there are two choices with how to deal with the balance.
 

• Put the balance on back order
• Cancel the line on the order

Finally there is also a field for entry of any text on the invoice. Hitting the process invoice button updates the order as instructed and produces all the entries including general ledger postings (if integration is enabled in the company preferences screen - see setup) to record the invoice. Until the process invoice button is hit, no entries have been saved to the database and it is safe to leave the page at any stage without having changed anything - the invoicing process can be cancelled at any time simply by following a link to another page. The processing that takes place once the Process Invoice button is hit includes:
 

• Creation of the stock movements for each line item on the order - or for the assemblies components - from the location entered at the time of the order, at the price as per the order.
• Creation of the DebtorTrans record that records the invoice against the customer's account.
• Creation of the general ledger jorunals to record the sale and debtor etc.
• Updating the order for amounts dispatched, and the invoice number.
• Creating/updating the sales analysis records of the items being sold.
• Updating the stock quantities for all lines of the invoice and the components of all assemblies included on the order.

If the order is not to be invoiced to the customer or branch specified in the order, or pricing is to be changed then the order must be changed. These elements cannot be altered at the time of invoice, they must be altered in the order before it is confirmed for invoicing. Once an invoice is created it cannot be deleted or modified. The order is also updated with the invoice number that it was dispatched on.

Credit Notes

Credit notes can be created in one of two ways:
 

• From a customer inquiry screen if the user has the necessary permissions ( $PageSecurity=3 - see Security Schema) a link shows to allow an entire invoice to be credited. Having clicked this link there is opportunity to de-select some items from being credited so that only the part of the invoice that needs to be credited can be, with only minimal keying. The same credit note creation page as used in manual creation of credit notes will appear but with all the items from the orignal invoice already entered into the credit note.
• Using the link on the main menu under the receivables tab, select the link to create a credit note.

Important Note:

It is important to use credit notes to correct incorrect invoices correctly. Crediting a small price against a part implies that the goods were returned and the customer only credited a fraction of their worth. This is not the correct way to credit an overcharge. By default credit notes return the stock to the location specified, so the stock records will be overstated by the goods returned to stock by the credit note. To correct a pricing error a credit note for the invoice line at the incorrect charge must be done and a new invoice at the correct charge must be made up. This ensures that sales analysis records are not corrupted for the quantities sold and that stock records are maintained correctly. A special pricing adjustment type of credit note is available that does not have any cost implications for the sales analysis and has no stock physical movement record associated with it.

The process for creating a credit note manually is:

• Select the customer to be credited, there are the usual selection options (a box to enter an extract of the customer's name and a box to enter an extract of the customer's code)
• Select the items to be credited and the prices to be used in crediting the customer - the same quick entry option is available as is used in order entry. - where the part code and quantity to be credited is entered directly. Pricing is automatically determined by reference to the customer's sales type, currency with regard to any special pricing for the customer (and branch) being credited. If the search for a part functions are used, then after each part is selected the quantity can be updated after the item is selected.
• Having selected all the items it is possible to edit the items to be credited by clicking the button of the code of the item on the summary, then editing the price and quantity.
• Amounts to be credited for freight can be entered directly (this would be entered directly from the original invoice if the credit an invoice option was used from the customer inquiry screen).
• The tax amount to credit is calculated automatically by default based on the tax authority of the branch being credited and the total of the line items and freight to be credited. It is also possible to select the manual option. Once having selected manual, the user should hit update to allow free entry of any amount in the tax field.
• By default it is assumed that the goods in the credit note are being returned to stock. The location to where the goods are being returned must be selected from the selection box.
• If the goods are not being returned to stock, they are to be written off perhaps as samples or showroom display, damaged goods or whatever, the credit note type option should be changed to goods written off. After changing the credit note type and hitting the update button, a new select box will allow a general ledger code to be selected (assuming the general ledger interface to accounts receivable is active - it will not show if there is no integration). The appropriate general ledger code should be selected from this box. The location to return the stock to select box will disappear since it is no longer relevant. A third option is to credit a pricing adjustment - this type does not create any stock movements and the sales analysis updates only affect the value no cost of sales updates take place.
• Any text describing the reasons for the credit note should be entered in the narrative box provided.
• After completing all the inputs required, hit the Process Credit Note button to create the credit note. The created credit note number will be reported confirming that it has been processed.

Entry Of Receipts

This system tracks the invoices and credits which are outstanding (a so called open item system) in contrast to systems which use a balance brought forward from the previous month to add and subtract current month transactions. Experience has shown balance forward systems whilst intuitive, often result in queries for more information with the inevitable question from customers "what was this balance made up of ?" . The statements produced by this system show a full reconciliation of the amounts outstanding against invoices and credits that are yet to be settled totalling the amount of the customer's account. In order to provide the necessary information to track outstanding amounts, invoice by invoice, the detail of the make up of payments must be entered.

Payments received from customers are therefore entered in a two-stage process:

• The amount of the payment received is entered in foreign currency together with the exchange rate at which this has been banked into local currency. Any details pertinent to the receipt such as the date, method of payment and any details (which can be recalled from inquiries later) are entered at this stage.
• The foreign currency received is allocated to the invoices (and debit journals) on the customer's account. Put another way, the invoices that the payment is meant to be settling are matched off against the payment.

If the details of the make up of a payment received are not available at the time of banking, the receipt can still be entered to stage 1. However, the allocation must be done before the statement is produced if the account is to make sense.

Note: Differences on exchange are only calculated once the receipt is matched against the invoices it is paying.

Receipts relating to general ledger transactions can also be entered in the same batch as customer receipts.

The process of entering receipts is initiated from the main menu under the receivables tab - another link is also available from the general ledger tab.

Firstly, the receipt header information is required, the bank account - one of the previously defined bank accounts (see setup), the date the batch of receipts are banked, the currency and exchange rate of the banking and the type of receipt together with any narrative. The currency can be selected from the defined currencies (see setup). The receipt types can also be selected - they are defined in config.php. Once this information is entered it must be accepted before the receipts in the batch can be entered.

Receipt - Customer

By default once the a customer has been selected the following information is displayed:
 

• The payment terms applicable, so amounts overdue can be easily noted from the allocation screen without having to go back and do an inquiry.
• The payment discount percentage applicable. The user can then use this rate if applicable to calculate the discount applicable, depending on how much of the payment relates to "on time" invoices.
• The currency that the currency is paying in.

Receipt - Date

The date that the receipt was received and banked. If a receipt is being entered retrospectively - or several days bankings are being done together, the default date (i.e. the current date) should be over written with the date the receipt was originally received. This date is used on the statement and the customer may not be able to tie up the receipt if an incorrect date is entered.

Customer account inquiries are shown in date order so the account will not show correctly if the date entered is not the date the money was received. The date is also used in the general ledger transaction created.

Receipts - Currency and Exchange Rate

Selection of the customer automatically tells the system which currency to expect the receipt in. The customer's account is maintained in the currency selected in the customer maintenance screen.

The correct rate at which the bank has converted the foreign currency to local currency must be input, the system shows the calculation of the local currency banked at the bottom of the screen. The receipt cannot (therefore) be entered until the amount in local currency is known. The exact rate to enter in this field will be the foreign currency figure divided by the local currency figure.

Eg banked 1212 local, in customer's currency this was 400.

Rate is 400/1212 = 0.330033

The local currency calculated by the system should confirm that the rate entered is correct. The general ledger integration - if enabled - will produce a bank deposit for the local currency amount shown at the bottom of the screen, and reduce (credit) the Debtors Control account by the same amount. The system defaults the exchange rate to that set up against the currency in the currencies table.

When the receipt is matched to invoices, any differences between the local currency amounts banked against the local currency invoiced are recorded against the invoices and written off the general ledger Debtors Control Account and written into the profit and loss account - (specified in the company record of the customer concerned) if the general ledger integration is enabled from the module options screen.

Receipts - Payment Method

The payment method is stored against the receipt and shows on the customer's statement. A banking report can also be run off based on the payment method to summarise the day's bankings, to automate the task of collating the different vouchers and summarising for the bank.

Receipts - Amount

The amount of the receipt in foreign currency is entered here. This cannot be 0. Although, negative receipts are allowed (to reverse incorrect receipts).

Note: Care should be taken when allocating negative receipts to ensure that only previous allocations are reversed, strange results could occur if allocations are made to invoices not previously allocated to positive receipts - although system integrity will be maintained.

Receipts - Discount

The amount of discount on a receipt can be entered at this point and allocated together with the receipt as one amount. This is useful, where a customer pays an amount net of discount - quite correctly according to his terms and conditions, and the amount naturally will not tie up to invoices on its own without the addition of the discount. The system calculates the gross amount of the payment including discount to set off the customer's account.

Receipts - Allocating to Invoices

Once all the details necessary have been entered for the receipt - the customer, the exchange rate and the amount in foreign currency, the receipt is ready to be allocated to the invoices which is to settle.

This concept can seem strange to businesses that have previously operated customer accounts where they are only interested in the current months' transactions and the balance brought forward from last month. The aim of this system is to remove the question from the customer's lips ... "What is that figure, balance brought forward made up of?". Under the "Balance Forward" system this question can be a tough one to answer, since there is no record of which invoices were paid by which payment. However, this system needs explicit instructions for each receipt on which transactions should be settled as a result.

From the menu under the Accounts Receivable tab - Click on the link to Allocate Receipts or Credits.

This page shows all outstanding receipts and credits that are yet to be allocated. Clicking on the links against these receipts and credits takes the user to the outstanding transactions on the customers account that are available for allocation. This screen shows all unallocated transactions but only invoices are available to allocate the receipt or credit note to.

Note that allocations of a receipt are not allowed to another receipt. If necessary, negative receipts can be used to reverse allocation against invoices and debit journals (although this is undesirable). Once entered, receipts cannot be deleted - (obviously this would be undesirable from the standpoint of proper internal controls).

If the whole of the receipt is not matched off against (allocated to) invoices and debit journals the system will prompt to ensure that this is what was intended. Unlike many systems, allocations can always be completed or amended later.

Differences on Exchange

The process of allocating receipts to invoices gives the system the information necessary to calculate the difference on exchange since the receipt converted at the rate specified in the receipt screen will equate to a different amount to the local currency equivalent of the invoices it is matched to, unless both the receipt and the invoices it is allocated to are converted at the same rate.

The difference calculated at the time of allocation can be seen on the receipt screen once the allocations are done and the screen closed and is itemised against the invoices to which it is allocated against. Unlike many systems the difference on exchange can be fully itemised transaction by transaction. Inquiries on the detail of receipts show the difference on exchange that the receipt is responsible for. Further the inquiry on where the receipt was allocated to will show the analysis of where the difference on exchange for the receipt under review came from.

Alterations to the allocations naturally alter the difference on exchange. The general ledger interface produces a journal for only the movement of the difference on exchange for a given receipt each time its allocations are altered.

Receipts Processing

Many customer receipts can be entered at a time and mixed together with receipts for nominal items i.e. receipts from vending machine or sales of fixed assets reimbursement for private use of company assets etc. Once all receipts have been entered the processing can take place. The system only stores the data entered in a server side cookie called a session until such time as the Process button is clicked.

The processing will give the batch of receipts a number and insert new receipt transactions against customer accounts and update the customer's record with the amount of and the date of the last payment. In addition if the general ledger interface is enabled, the journals to put the receipt into the bank account specified and to decrease the Debtors control account - specified in the company record are created. General Ledger journals are also created for the discount - if any, with the corresponding entry to the Debtors Control account. All the necessary account codes must be set up in the company preferences page under the setup tab and the bank account set up page.

Deposits Listing

After processing has completed a link to print the deposit listing for the batch of receipts just entered is shown. The batch number is also reported. The listing shows the information required by banks in processing a batch of cheques. This deposit listing can be reprinted at any time from a link under the accounts receivable tab - reports and inquiries.

Allocate Credits To A Customer's Account

This option allows any credit amount - be it a receipt or a credit notes to be allocated to debit amounts - invoices . Receipts or credits that have previously been allocated are available for alteration of their allocations if necessary. There are two ways to perform this function:

• From the menu select the accounts receivable tab and click the link to "Allocate Credits To Customer's Account".
• From the customer account inquiry - there is a link to allocate any customer receipt or credit where the user has appropriate privileges.

Using the first method, by default the screen opens with only the receipts, credit notes and credit journals which have an amount outstanding left to allocate. If there are many receipts which have amounts outstanding and are not fully allocated to invoices and debit journals then this is an indication that there are allocations which need to be done. For the customer's statements to make sense, the allocations must be done.

Double clicking the receipt to allocate will then open the form that allows the allocations to be made. This screen brings up all the invoices and journals that are outstanding on this customer's account. Invoices that have already been paid off will not show. However, existing allocations made from the selected receipt or credit will show. Clicking a receipt or credit note from the customer inquiry screen brings up this same page.

If a mistake was made with previous allocations these can be rectified by selecting the previous receipt which was wrongly allocated, all the invoices which the receipt was allocated to will show (together with other invoices which are yet to be allocated to). The amounts allocated against them can be amended at will.

Note: This is a complex area behind the scenes, to handle the changes that may result to the difference on exchange. The system calculates the alteration to the exchange difference which results from allocating the receipt to different invoices (or not being allocated at all) and creates the necessary journal in the general ledger - if the integration option is used - to ensure the debtors control account stays in balance with the list of balances.

Overview

The general ledger is the accounting hub that is central to the "sub" ledgers for creditors (Accounts Payable), debtors (Accounts Receivable) and stock (inventory). All entries in the sub ledgers are also represented by entries in the general ledger. It is the integration set-up that determines how entries in the sub-ledgers are reflected in the general ledger. Most activity in the general ledger will be automatically created from the activity in the sub-ledgers with receivables, payables and stock administration.

However, there are also facilities to:
 

• Enter general ledger receipts against a pre-defined bank accounts.
• Enter general ledger payments against pre-defined bank accounts.
• Enter general ledger journals between any general ledger accounts - except bank accounts. These can also be made to reverse automatically in the following period. Further journals can be posted to any period future or previously - the period is determined by reference to the date entered.
• Inquire on general ledger account activity and from any entry in this inquiry drill down to the journals created to produce the entry.
• Inquire on the general ledger trial balance for any period end in history or currently.

Account Groups

The account group is the parent object of a general ledger account for someone who understands OO programming. Child accounts created inherit the properties of the account group - ie the account will be a profit and loss account if it belongs to an account group that is a balance sheet account, the child accounts will display in the trial balance (TB) together in the sequence determined by the account groups sequence in the trial balance (TB).

Using a numbering system inhibits the ability to manipulate the format of the trial balance ie you have to be able to change the account code to change where an account appears ie

10100 motor expense Copenhagen

10110 motor expenses The Hague

10120 motor expense Amsterdam

would be great but then if we wish to restructure so that Copenhagen expenses are all shown together and The Hague is now all shown together etc we will have to change the numbering. In web-erp all that is required is to change the account group. In the first situation we could have an account group for motor expenses and all these account numbers would be set up as belonging to the account group. We can decide whereabouts the account group should appear in the trial balance by changing the sequence in trial balance field. All accounts in the account group will show together. If we decided to change the trial balance to show The Hague expenses together as a separate group of costs, we could create an account group for the The Hague selling costs - or whatever, and change the motor expenses the Hague account no 10110 to be a member of that account group.

Account groups require the sequence in the trial balance to be specified and also whether the accounts in that group will be profit and loss accounts or balance sheet accounts.

A balance sheet account is one where only the balance at the end of the period concerned is of interest. A profit and loss is one where we are interested in the movement over the period. eg. Motor expenses we are not concerned with the balance at the end of the month so much as how much was spent over the period of the profit and loss. However, for a bank account we wish to know what we have now as a balance not the movements in the account. As noted accounts created as a member of an account group will inherit the properties of the account group ie if the account group is a balance sheet group then the accounts will be interpreted as balance sheet accounts.

Bank Accounts

Certain general ledger accounts can be defined as bank accounts - as many bank accounts as needed can be defined. At the time of defining a general ledger account as bank account the currency of the bank account must also be specified. General ledger accounts defined as bank accounts can be reconciled to bank statements using the matching facilities - all receipts and payments show in the currency of the bank account for easy matching off statments. Entries made to bank accounts using receipts or payments, also create a total receipt or payment, which is retained for the purposes of matching off the bank statements. Using the bank payments page, general ledger payments can be analysed to any number of other general ledger accounts, but only one entry to the bank account is made. This page also allows payments to supplier accounts to be created. Similarly, using the receipt entry page, a series of receipts from customers which may all have been banked together can be deposited as one amount to a bank account. There is only one amount appearing on the statement as the total of all these receipts, this bank account transaction is created and available for matching deposits off the bank statements.

Bank accounts are defined from the setup tab from the link to Bank Accounts Maintenance. There is facility to enter the name of the account, the currency of the account, the bank account number and the address of the bank if required, as well as selecting the general ledger account to which it refers. There are links to edit existing bank account records and to delete them. However, once defined as referring to a particular general ledger code it is not possible to change the general ledger code of the bank account. This is because there would be entries made to this account. Similarly, if bank transactions have been created using this bank account it is not possible to delete it. The bank account transactions must be purged first (but currently no facility exists to purge bank transactions). It is not possible to change the currency of a bank account once there are transactions against it.

Once all receipts and payments are matched to bank statements, the bank reconciliation statement can be printed which should show how the current general ledger balance reconciles to the bank statement for this account. The reconciliation also has an option available for bank accounts set up in other than the functional currency of the business (local currency), to post differences in exchange. The balance of the account is maintained in local currency in the general ledger and for the purposes of the bank reconciliation this is converted to the bank account currency at the exchange rate in the currencies table (see Setup -> Currency Maintenance) - this rate can be changed manually to the rate of the day and the foreign currency balance on the account will change - to correct this balance an exchange difference needs to be recorded. Having worked through the matching of receipts and payments to the bank statements - the bank statment balance can be entered to compare against the system balance - a correcting entry is then made to the GL to post the difference on exchange. The posting to the general ledger is back dated to the end of the preceeding month - since it is assumed that the reconciliation may be a few days or a week behind the current date.

Bank Account Payments

From the general ledger tab, the first link under transactions is Bank Account Payments.

The following data is required:

• The bank account from which the payment has been (or is to be) made. A select box allows this to be selected from the list of defined bank accounts.
• The date on which it was paid. This is important since the accounting period in which the payment is entered is determined from the date. The system will default to today's date - this must be changed where bank payments are being entered retrospectively.
• The currency which is being paid. Payment to suppliers may be made in foreign currency being purchased in the currency of the bank account at the exchange rate entered - see below.
• The exchange rate - this is the exchange rate between the currency being paid and the currency of the bank account. If the currency being paid is the same as the currency of the bank account then this rate should be 1. If another currency is being purchased with the payment then the rate at which it is being purchased should be entered.
• The functional exchange rate - this the exchange rate between the currency of the bank account and the functional currency of the business as defined in the company preferences (ie the reporting currency of the business). Where the bank account is in the same currency as the functional (reporting) currency of the business then this value should be 1. The functional currency entry will only be required when the bank account currency is different to the the functional currency and will default to 1 automatically if they are the same.
• Narrative - applicable to the whole payment. Narrative applicable to individual general ledger entries can be entered separately.

Payments can take two forms - either it is a general ledger payment or it is a payment to a supplier. General ledger payments require an analysis of how the payment should be posted to the general ledger. General ledger accounts can be specified either as the account code directly (if the account code is known) or by selecting from the select box. Any narrative applicable to the general ledger amount can be entered too - and the amount to be posted to the selected/entered account. The total payment is taken as being the sum of all the entries made. If the total of all entries made is negative then this is entered as a negative payment - these are accepted to allow for correction of data entry errors. Payments are always entered in the curreny of the payment - the conversions are handled by the system for general ledger postings etc.

General Ledger Integration Setup

Bank Accounts are automatically integrated with the general ledger and cannot exist separately without the GL being used. Every transaction is recorded in two places (double entry) eg. A bank account payment reflects in the bank account and also in the expense account that is was paid for - eg. stationery, fuel, entertaining, advertising or whatever. One entry goes as a debit on the left and the other as a credit on the right - when you look at the trial balance the debits should tie up with the credits ie the trial balance - a list of the general ledger balances should have balancing debit total and credit totals.

With respect to the sales (AR) and purchase (AP) ledgers, general ledger postings can be turned off in the company preferences screen by setting each of the flags to No.

Integrated general ledger postings do provide a good way of building up the business's accounts from activity in these sub ledgers.

You can choose between two levels of integration:

1. Integrate GL at the debtors and sales level only

This creates general ledger journals for each sale as follows:

DR the debtors control account - defined in the company preferences screen
CR the sales account - defined with reference to the customer sales area, stock category of the item being sold and the sales type (price list) of the customer. This provides great flexibility as to how sales should be posted
CR the tax to the taxgl account defined in the tax authorities (ie the general ledger code of the tax authority of the customer branch). It is also possible to have just one general ledger account for all sales by defaulting ANY sales area, ANY stock category and ANY sales type with a single general ledger code - see later section on sales general ledger codes.
the reverse takes place for a credit note.
When cash is received:
CR the debtors control - defined in company preferences DR the bank account - defined in the bank account setup.
There are also general ledger entries for discounts and differences on exchange which have been ignored for the purposes of this introduction.
This level of integration ensures that the list of balances of all customer accounts (in local currency) always ties up with the general ledger debtors control account.

2. Integrate GL at the stock level as well

For every sale:

CR stock value at the standard cost of each item sold - the stock GL account being defined in the stock categories record.
DR Cost of Goods Sales (COGS - or COS) with the same cost. - the COGS GL accounts are defined with similar flexibility as descibed for the Sales GL accounts under the setup menu under AR/AP options

the reverse happens for credits.

This enables the stock value to be continuously updated in the general ledger and always be equal to the stock valuation at standard cost.

This level of integration also has ramifications for stock adjustments, stock deliveries and stock cost changes.

For stock adjustments the quantity adjusted is extended by the standard cost and it is written on (CR) or off (DR) to the stock adjustment GL account as specified in the stock category record for that item.

For receipts of stock - the stock coming in is extended by the standard cost and the entry is to:

DR stock at standard cost x number received - the stock account being defined in the stock category record for the item being received.
CR GRN suspense at standard cost x number received - this account is specified again in the company preferences screen.

The two levels of general ledger integration are:

• Sales journals that post a credit to a sales general ledger account, a debit to a discount account, a credit to a tax account, a credit to a freight recovery account and a debit to a debtor account. This level of integration also reverses the posting described here for sales credit notes. This level also triggers the general ledger journals for banking of cash against debtor accounts. Debiting a bank account and crediting the debtors account.
• Stock journals that post a debit to a cost of sales account and a credit to a stock account - and the reverse entries for sales credit notes.

The level of general ledger integration is determined by reference to the flags in the company preferences page.

Sales Journals

The general ledger accounts that are used in this level of integration are determined from several inputs.
 

• Sales Area of the customer being invoiced/credited
• Sales Type (or price list) of the customer being invoiced/credited.
• Stock Category of the item being invoiced/credited.

A table of sales general ledger accounts is maintained and can be modified from the setup tab. When an invoice is created from the ConfirmDispatch_Invoice.php script the system uses a function defined in GetSalesTransGLCode.inc to look up the general ledger codes that are appropriate. By default this function uses the following logic:
 

• If there is a record in the SalesGLPostings table that has a matching Area, SalesType and Stock Category then the function returns the sales account and the discount account applicable.
• If there is a match for the Area and SalesType using the default Stock Category (ANY) then the codes applicable to this record are returned.
• Then if there is a matching Sales type, stock category with default (AN) area this is used.
• Then if there is a matching stock category record using the default area (AN) and the default salestype (AN) this is used - finally
• If there is no record is found after trying the above combinations then the GL Code for the default area, sales type and default stock category is used - this is GL code 1. If GL Code 1 is not defined, then it will be created.

Since the logic of how the general ledger account is determined is defined in this function it is relatively simple to change this to what is most appropriate for the business.

The freight recovery and the debtors control account used are those defined in the company preferences page.

The tax account used is the account defined in the tax authorities definition used for the customer being invoiced.

Stock Journals

The general ledger accounts that are used for posting sales transactions are determined using the sales area, the sales type of the customer being invoiced/credited and the stock category of the item being invoiced/credited. A table of general ledger accounts is maintained and can be modified from the set up tab from the link "COGS GL Interface Postings". The same logic as above is applied and the function is defined in the same GetSalesTransGLCode.inc script to look up the appropriate GL codes. Again, since the logic of how the general ledger account is determined is defined in the function GetCOGSGLAccount, it is relatively simple to change this to suit the business.

The account to credit stock with for the cost of goods sold is determined by reference to the stock item being sold. The stock category of the item is retrieved and the general ledger codes applicable to the stock category are used.

The profit and loss accounts used for stock adjustments are also determined by reference to the stock category record.

The profit and loss account used for posting the variance between standard cost of a purchased item and its actual cost as invoiced is also determined from the stock category record.

EDI

EDI stands for electronic data interchange - the electronic transmission of transaction information between trading partners. There are numerous standards for the encoding of such transactions the most widely used being UN/EDIFACT and its derivative EANCOM implementation. In fact many industry groups use the standard formats in slightly different ways and some businesses within the industry use the industry standard slightly differently again. So ultimately, the standards are really only a framework for what the actual messages look like. In implementing EDI in webERP, some flexibility in the format of messages to be sent and received is available. EDI messages are created in flat files in the directory specified in config.php for EDI outgoing messages and a log of the EDI messages sent is retained also. The messages can be sent either as an email attachment to the customer supplied email address or via ftp to a customer supplied ftp server address - using the ftp username and password provided by the customer.

EDI Setup

To enable EDI transactions for a customer, first select the customer from the Select Customer link on any page, then click the link - Customer EDI Configuration. This page allows selection of the type of transactions that are to transmitted electronically currently only invoices/credit notes and orders are available. Each must be specifically enabled to activate them. Each customer must have their:
 

• EDI reference that they are identified by
• Transport mechanism and address to which the invoice/credit note messages are to be sent - either email as a file attachment or via ftp (file transfer protocol)

If the transport mechanism is to be ftp - this must be compiled into PHP with the flag -enable-ftp, most windows PHP installtions have this by default now. Additional fields for the ftp server username and password will also be required.

To activate EDI polling for invoices to send the script EDISendInvoices.php must be run as a scheduled job - using cron or some other scheduling system -see automating sales reports. It can also be run from the utilites menu Z_index.php with debugging output.

To activate EDI polling for orders to be entered as received the script ???? must be run as a scheduled job using cron or some other scheduling system.

Sending EDI Invoices

EDI messages are made up of segments which must appear in a certain order. Since customers will require EDI invoices in slightly different formats, the exact format can be defined in the table EDIMessageFormat. This table has a record for each customer invoice line and the sequence when it must appear in the message. The field line text in this table can include any of the predefined EDI invoice variables surrounded by "[" and "]" to denote them as a variable to be replaced with the appropriate value as follows:
 

EDI Invoice Detail Section
EDITransNo	The unique EDI transaction number
InvOrCrd	Whether the transaction is an invoice or a credit - the value of this variable is an EANCOM defined number, 388 for a tax invoice and 381 for a credit note
TransNo	The transaction number of invoice or credit
OrigOrDup	Whether the transaction is a duplicate or original sending the value of this variable is an EANCOM defined number 7 for a duplicate and 9 for an original
TranDate	The transaction date in the format CCYYMMDD
OrderNo	The original order number - only for invoices
CustBranchCode	The customer's internal code for the branch
CompanyEDIReference	The customer's EDI reference code
BranchName	The branch name
BranchStreet
BranchCity
BranchState
TaxAuthorityRef	The businesses Tax Authority reference number
DatePaymentDue	The due date for this transaction
TaxTotal	The total amount of tax on the transaction

EDI Invoice Detail Section - for the lines on the transaction
LineNumber
StockID	The webERP item code
CustStockID	The customer's internal code for the item
ItemDescription
QtyInvoiced	Quantity invoiced or credited
LineTotalExclTax	The total for the line excluding tax
UnitPrice	Unit price for the item
LineTaxAmount	The tax applicable to the line

EDI Invoice Summary Section
NoLines	The total number of lines on the invoice/credit
TotalAmountExclTax	Total amount of the transaction excluding tax
TotalAmountInclTax	Total amount of the transaction including tax
NoSegments	The total number of segments in the transaction this is required as a control check in the summary

There is therefore great flexibility in how the messages are defined. The variables for the summary and heading sections can be used in any section. The detail section variables can only be used in the detail section.

Most customers will require that the branch to which the invoiced goods are delivered to, be identified using the customer's coding system. It is therefore important to ensure that the customer's branch code is actually entered against the webERP branch record. The variable CustBranchCode is retrieved from the branch record and if it is not entered then the EDI transaction will fail.

Some customers may also require the item code to be their item code, not the webERP item code. The variable CustStockID is derived from the cross reference table EDIItemMapping which would need to contain a cross reference record for each item that they may buy.

The script that creates the EDI invoices (EDISendInvoices.php) should be run automatically in the background as a scheduled task. It first gets a list of all customers who should receive EDI invoices (or credit notes) - as determined in the settings of their DebtorsMaster record. Then the script goes through each customer returned in turn to get any invoices or credits that have not already been sent. A flat file is created for all the customers invoices and credits and sent to the customer using the transport, address and other parameters defined in the customer edi setup page - recorded against their DebtorsMaster record. There is a link to enable the script to be run manually - the browser will also show the output of the EDI message

Overview

Manufacturing - simply the combination of items to make other items can be implemented effective from webERP version 3.06.
It has been possible to build bills of material for manufactured items for some time but the functionality that allows the materials to be issued from stock and manufactured items received into stock was introduced with 3.06. This is the purpose of the work order.
Functionality to add labour items to work orders and post recovery amounts to a profit and loss account for issues of labour to a work order was added after 3.09 (Sept 2008).
Functionality to set up a master production schedule and explode bills of materials into the components required to manufacture this demand and calculate the required orders to be placed/rescheduled (MRP) was added by Mark Yeager in March 2009.

Bills of material now allow components to be defined as "auto-issue". Components set up to auto-issue, automatically create the issue transactions against the work order based on the bill of material quantities on the entry of receipts of a finished item against the work order. This decreases the administration of work orders for those components with relatively low value and limited possibility for any usage variance. It is not recommended that this feature be used on components where the final requirement for it could vary with for example yield differences between work orders. Work orders take the value of components and materials issued and divide this total cost between the output items to arrive at a cost per unit for all output items. The process for performing this calculation is called "closing" the work order.

Functionality to automatically create works orders for manufactured items at a default factory when a sales order is entered for which there is insufficient stock after all sales orders are delivered and outstanding works orders and purchase orders received. This functionality needs to be turned on as an option under configuration settings. The email address of the production manager who will receive an advice of the work order being created can also be defined in the configuration settings.

In dealing with serial or batch controlled items there are two ways that the system can operate. Either the serial numbers or batches must be created at the time the work order is created or they are entered at the time they are completed. If they are created at the time the work order is set up there is an option enter remarks about each lot or serial number about the manufacture or quality check data. To have serial numbers (or batches) defined at the work order entry stage this needs to be set in the configuration settings.

The sequence of events in manufacturing an item is as follows:

• Enter a Work Order - selecting all the output items required to be included in the work order costing. To ensure accurate costing it is recommended that work orders be created for single items wherever possible. The quantity required of the item and the date the items are required to be completed by must also be specified. If the output item is a controlled item - either serialised or lot/batch controlled - then there is also an option to enter the next serial number or batch reference which will be retrieved when entering the manufactured items received. If the configuration is set to create serial numbers (or batches) up at the time of the work order entry then there is an option to create serial numbers automatically based on the next serial number for the item defined in the stock master - all that is required is the number of serial numbers to create.
• Receive Items against the work order. When manufactured items are completed they can be 'received' against the work order. Auto-issue components are automatically issued. On the first receipt of manufactured items against a work order, the cost of the item is recalculated by rolling up the cost from the bill of material. A cost adjustment is performed if the cost changes. If serial numbers (or batches) have been defined at the time of the work order entry these will list for checking off the items being received as finished against the work order
• Issue components and raw materials to the work order
• Once all components and raw materials are issued to the work order and no more manufactured items can be received against the work order it can be closed. The closing process recalculates the cost of the items manufactured on the work order and if weighted average costing is used a cost update will be processed.

General Ledger Integration Issues

When the "Create GL entries for stock transactions (at standard cost)" option in the company preferences form is set to "Yes", then GL journals are created as a result of work order transactions. When a work order is created there is no GL impact. The ways the GL is impacted as a result of manufacturing processes are as follows:

• Receiving Manufactured Items - the stock of finished goods - as per the stock category record of the item being manufactured is debited with the recaclulated (rolled up) cost of the item - as at the time of the first receipt against the work order and credited against the work in progress account of the item (from its stock category record). Subsequent receipts of manufactured stock against the work order are debited to the stock account at the same cost as the first entry. Also, auto-issue components that get issued at the time of the receipt of the manufactured item also create GL entries to debit the work in progress account of the manufactured item's stock category WIP account. The credit goes against the stock account of the component's stock category. For manufactued and purchased items this will be a balance sheet account. However, if the item belongs to a labour type stock category then it is possible to select a profit and loss "recovery account" and for the credit for the value of labour "issued" to the work order to go to this profit and loss account.
• Issuing components to the work order - the same entries as for auto-issue components above. i.e. debit the manufactured output item's WIP account and credit the component item's stock account. Labour items can also be auto issue.
• Closing the work order - compares the quantity of components issued against the bill of material at the time of the first receipt of the manufactured items - the volume differences are evaluated at the standard cost (as at the time of the first receipt of manufactured item) to come up with the usage variance posted to the debit or credit of the manufactured item's stock category record's usage variance account. Then the cost of the items issued to the work order are compared against the cost as at the time the first receipt of the manufactured item was entered - differences here are taken to the price variances account in the manufactured item's stock category record. It is the closing of the work order that ensures that the costs received from the work order in the form of manufacturing output equals the cost of the inputs - the various components and materials issued to the work order

Event	Debit	Credit
Components issued to the work order	WIP a/ct from stock category of manufactured item	Stock account from the category of the component item
Labour issued to the work order (identical to any other component except that labour type categories have profit and loss accounts for their stock account)	WIP a/ct from stock category of manufactured item	Labour recovery account from category of the labour type item
A completed manufactured item is received against the work order	stock account from the category of the manufactured item	WIP from the category of the manufactured item
Work order closed and the difference between the WIP debits and credits from the above transactions is compared and the balance is either Standard costing - taken to material usage variance from the stock category of the manufactured item Weighted average costing - if some of the manufactured stock remains on hand the variance is taken to the stock account from the category of the manufactured item. The cost of the manufactured item is updated with the recalculated WAC	WIP / Usage variance	WIP / Usage variance OR stock

Work Order Entry

The Work Order is the medium for issuing components/raw materials to. A running total of the costs issued to the work order is maintained. Work orders can be created that have any number of output items. Output items are restricted to only "manufactured" items as defined in the item entry form. The work order tracks the quantity of the output items received against the work order and checks that no more than the work order quantity originally set up, with an allowance including the over-receive proportion as defined for purchase orders, is received.

Setting up a work order is performed from the Manufacuting tab -> transaction entry -> Work Order Entry. The work order number is automatically maintained and defaulted for new work orders as is the start date defaulted to the date the work order was created. Other data required includes:

• Factory location - this is the inventory location which is used to retrieve the bill of materials for the items being manufactured on the work order - it is possible to have different bills of material for the same item depending on the inventory location. This inventory location is also used as the default location where materials for the work order are issued from and the default location where manufactured items are received into. It is possible to modify this during the issuing and receive processes.
• Required By - this is the date when the manufacturing must be completed by

With the above information completed then the items to be manufactured on the work order need to be selected. Normally this should just be a single item but it is possible to have multiple outputs against a single work order which is useful for by-products or processes with several output products. There are search facilities in the work order entry screen - only items flagged as manufactured in the item definition screen (Stocks.php) will show for selection. For each item selected the quantity required defaults to the EOQ - (Economic Order Quantity) defined in the item definition (Stocks.php) screen. If no EOQ is defined for the item then the quantity defaults to 0 and must be entered manually. The quantity required can be over-ridden and changed at any stage. Things are a bit different if the configuration option to defined serial numbers and lots at the time of work order creation is set. The quantity on the work order is calculated based on the number of serial numbers created or the sum of the quantity required for each batches entered. It is not possible to create a duplicate of an existing batch or serial number for the same item. (It is possible to have the same serial number or batch for different items.)

The quantity received of the item is maintained automatically against the work order items. The balance of the work order yet to be manufactured and received shows as "on order" in the stock status inquiry. Similarly the quantity required of components as extended by the bill of material for work order items is shown as quantity demanded against component items stock status inquiries.

Closing Work Orders

The selection of work orders allows the costing to be viewed. The work order costing shows all the issues of materials and components against the work order as compared against the bill of material requirments - as they were when the first reciept of manufactured stock was received against the work order. The variances on the work order in terms of the usage of components and the expected cost of materials/components issued to the work order are displayed. Closing the work order takes these variances and if general ledger integration to inventory is enabled then journals are created to write back the work in progress balance. Of course if there are several manufactured output items on the work order then the variances are apportioned between the items based on the quantity of the item received multipled by the expected cost as a proportion of the total expected cost of all items received on the work order. The detail of how the postings created depends on whether weighted average costing is used or standard costing.

• Standard Costing: Under standard costing the entire variances are taken to the profit and loss account. The usage variance is taken to the general ledger account specified in the manufactured item's stock category record. The cost variance is taken to the item's purchase price variance account on the stock category record.
• Weighted Average Costing: If not all the stock manufactured on the work order remains on hand - perhaps some is sold - then the variance relating to the proportion that is left on hand is taken to the value of stock e.g. a negative variance increases the value of stock. A stock cost adjustment is also created (irrespective of whether the GL integration is enabled).

Closing the work order also deletes any existing serial number/lots that were defined at the time the work order was entered (where this conifguration option is enabled) but the serial number has not been entered as received/finished.

Material Requirements Planning (MRP)

It is one thing to plan for purchasing where the item being sold is the item to be purchased. Things get more complicated when the item being sold is manufactured - each of the components in the bill of material need to be available before the item being sold can be manufactured. Where the components in turn are also manufactured then the complexity compounds - this is the material requirements planning calculations are for.

The author of the MRP - Mark Yeager has also contributed a manual page for his scripts which is linked from the manual contents page. For the curious, here (in the developers own words) are the basic steps of the MRP calculations: First, create a levels table by examining the bom table and finding a level number for each part; for instance, a part with nothing under it in a bom structure is a level 0 part, a part with 7 levels of parts below it is level 7. Next, I create an mrpsupplies table and an mrprequirements table. Supplies are from the current quantity on hand, open purchase orders, and work orders. Requirements are from open sales orders, worequirements records for open work orders, parts below their reorder levels, and demands the users can enter in an mrpdemands table for sales forecasting. Then I read through the levels table, starting at the highest level, and net the supplies and requirements for every part. If there is not enough supply, an mrpplannedorder record is created, and, if that part has parts below it in the bom structure, a requirement record is created for those lower level parts based on the net requirement for the top level part times the quantity per assembly for the component, with a schedule date based on the lead time for the part.

The MRP system uses certain order modifiers to inflate the requirement quantity. The EOQ from stockmaster is used, together with the item shrinkage factor and pan size.

There are a few programs to use before running an MRP.

Prerequisites

Each item that requires a shrinkage factor or pan size to be set up must be defined in the stock item maintenance form all items need to have an EOQ (Economic Order Quantity - the most efficient or required order quantity) set up.

Pansize : This modifier is sometimes called the order multiple. It allows you to create planned orders in even multiples. This is especially useful if you are required by your suppliers to place orders in specific lot sizes. It is also a useful modifier is you have established your own production run sizes. This modifier causes MRP to inflate the required order quantity to an even increment of the pansize value. As with all modifiers you do need to be careful with this modifier as its use could lead to excess inventories

From the Setup Menu - MRPCalendar.php creates a calendar of valid dates for manufacturing. That way if the system schedules a planned work order for a part for a Friday and a component has a lead time of 5 days, the system will schedule the component for the preceding Friday rather than the preceding Sunday. To create the calendar, you enter a starting and ending date range and can opt to exclude Saturdays, Sundays, or any other day of the week. After the original creation, individual days can be set to be valid or invalid manufacturing days.

It is important to remember that this is "infinite capacity" MRP - i.e. orders will be created based on the demand requirements without any constraints on the ability/capacity to manufacture the order... currently the system is only implemented to calculate and report orders required and further analysis is required to figure out how to manufacture the required orders.

From the Setup Menu the demand types need to be defined - by default webERP sets up a single Forecast demand type - which should be adequete for many businesses without further additional demand types. However, the system has ability to add additional demand types (the script MRPDemandTypes.php maintains a table of user-defined types of demands; for instance, F for Forecast or S for sales or whatever the user wants to use.

There are two programs for users to enter the demands.

MRPDemands.php can be used to enter single demands at a time. There is also a List Selection button that will list all demands for a part, if a part is entered, or all demands for a demand type, if no part is entered; when the parts are displayed, there are buttons to Edit or Delete. The Delete Demand Type button deletes all of the particular demand that is selected.

MRPCreateDemands.php can be used to generate a Master Production Schedule. The user selects a demand type, stock category, inventory location, and then enters a date range for sales orders to include. The program will generate demands beginning from the Start Date For Distribution for the number of periods – either weeks or months – that the user selects. Parts can be excluded based on their total sales quantity or total sales dollar. A multiplier can be used to increase the quantity; an example from my company is that we wanted to forecast for a year and a half, so rather than look at the last year and a half sales, we looked at the most recent 6 months and multiplied that times 3. An example of the distribution is if in a certain sales period a part had a quantity of 15 and the Distribution Period was months and the Numbre of Periods was 6, the first three months of records would have a quantity of 3 each and the last 3 would have a quantity of two. Dates are calculated based on the manufacturing calendar.

MRP.php runs the MRP itself. It is a regenerative process that purges all of the old files and creates new ones. There is a selection to chose the location for inventory. Days Leeway can be entered, so purchase order and work order dates scheduled within the leeway of the calculated need date are considered valid; the system does not actually change the dates in the work orders or purchase orders, but there is a report of those orders that the MRP estimates should be changed. And there are check boxes to select if MRP Demands, eoq, pan size, and shrinkage factor should be used. The MRP runs pretty quickly. The system I am running it against is not as large as most long running systems, but, with about 3,000 parts, a few hundred open sales orders and purchase orders, a half a dozen demands for assemblies that go 7 levels deep and have close to a thousand parts, plus individual demands for a few hundred other parts, I run this on a 3 and a half year old iMac with 1 gig of memory and it takes less than a minute. I also tried it on my web host, which is in Chicago, while I’m in New Jersey about 30 miles west of New York, and it took less than 20 seconds.

The MRP doesn’t change or create webERP purchase orders or work orders. I think it might be dangerous to do that automatically, without some sort of human oversight. In the 2.0 version, I might have some sort of screen that will bring up what I call MRP Planned Orders and allow users to generate purchase orders or work orders from them. Right now, there are several reports to show the results of the MRP. MRPReschedules.php shows those work orders and purchase orders that the system calculates should have their dates changed; if there is no requirement for the orders, a CANCEL message is displayed. MRPPlannedWorkOrders.php and MRPPlannedPurchaseOrders.php show orders that the MRP calculates should be created. The reports can be created showing every individual order needed and the source of its requirement, or the orders can be consolidated into weekly or monthly orders. MRPReport.php shows the supply and demand for individual parts. On the demand side, it shows the type of order that created the demand, the top level part for that demand, and the order number – in the case of user entered MRP demands, the order number is system generated. The supply side shows orders that make up the supply and in the case of Planned orders created by the MRP, it shows the type of demand the supply was planned to cover and the order number for that demand. Finally, there is MRPShortages.php that shows those parts that have a demand that is greater than the supply. The dollar total might be a little misleading because if there is a sales order for an assembly without enough supply to cover it, that will show up on the report, but so will all of the components that are needed to build the assembly. I haven’t quite decided if I should exclude the components or not.

Functionality
 

• Customer orders can be entered and maintained and referenced back to the customer's order number.
• The cumulative quantity on order for a stock item shows as a demand in stock status inquiries.
• The cumulative quantity on order for assembly items shows the demand against its components in the stock status inquiries.
• The quantity of the order left to invoice is maintained and updated for invoices and credit notes raised against the order.
• The orders entered can be invoiced directly with little or no additional input.
• Multiple dispatches are possible from a single order. Order retains references to each dispatch.
• Differences from the order are logged when dispatches are not the same as the ordered quantities for reporting delivery in full on time.
• Pricing automatically returned based on the customer sales type, branch and currency.
• Quantity break discounts across a range of products are automatically calculated based on the discount matrix.
• Packing slips printable on laser or pre-printed stationery.
• User selectable inventory location to pick from.
• Free form entry of delivery addresses - defaulting to the customer branch physical address.
• Recurring sales orders that recurr until any chosen finish date at a defined frequency per annum
• Invoices for cash sales can be entered directly without first entering an order

Entry of Sales Orders

From the main menu, Orders tab, click the Order Entry link.

Selection of the Customer and Branch

Initially, the order entry page shows the options to allow selection of a customer and branch. The customer is the actual charge account to where the order should be billed and the branch contains all the information about delivery. The customer search facilities are similar to the select customer script, but the code actually looks up on the branch code of the customer, only branches are displayed with accompanying customer charge to information. Searching for a customer can be either by entering a letter or letters in the branch code or by entering some keywords (or section of) in the customer name. Searching in this way minimises the result set returned (possibly over a dial up connection) to ensure the response is as speedy as possible to the users browser. All branches matching the criteria entered and not flagged as disabled for transactions, are returned each one with a button on the customer code. Hitting the button for the desired customer/branch selects it as the customer and branch to deliver the order to. There is opportunity later to modify the delivery details if need be. The order now shows the quick entry screen headed up with the name of the customer and branch, together with the sales type of the customer.

Selection of Order Line Items

There are two ways to select the line items for the order.

• By default a "quick entry" screen shows allowing the direct entry of the inventory code and the quantity required for the order. The number of lines shown on this quick entry table is defined by a variable in config.php - $QuickEntryLines which is user modifiable. After the user has entered any number of lines into this table, hitting the Quick Entry button processes the items entered into the order. The prices are retrieved based on the sales type, the currency, customer branch and the charge to customer of the order. If there were insufficient lines to enter all part codes for the order, the same process can be repeated with the quick entry table shown below the order summary after the first quick entry has been processed.
• On the quick entry screen there is a button to search parts. This button enables the user to search for a part based on the stock category and/or any part of the item's description and/or any element of the item's code. Hitting the search button after making appropriate entries in the code or description fields shows the part codes and descriptions together with picture of the item - if one has been uploaded to the server for all parts. Part pictures must be in .jpg format with a file name identical to the part code but with the extension .jpg, and it must reside in the directory specified in config.php for part_pics. The item code is displayed as a button and the system automatically puts one of the item selected onto the order. Additional parts can be selected in the same way.

Having selected the parts for the order, it is possible to edit the quantities, price and discount applicable to each line of the order. To get the order values to re-calculate the "Recalulate" button must be clicked (this is the compromise of using server side scripting - PHP - to the exclusion of any client side - java - processing). Discounts will be calculated using the Discount Matrix functionality described under that section within the order based on the quantities that are entered.

If a line entered, displays against a red background this means that the system inventory is showing insufficient stock to cover the order line, from the inventory location as defaulted from the customer branch record - as the most appropriate inventory location to draw the stock for this branch's orders. The item code displayed is also a link to a new browser window showing the stock status inquiry for the item, this shows the stock available at all locations.

A line can be deleted at any time by clicking on the link at the end of the line to delete it.

The whole order can be cancelled at any time by clicking on the "Cancel Whole Order" button.

The customer can also be changed at any time.

Once all the line items have been selected the Delivery Details button must be clicked. Note that there have been no changes to the database at all. The data entered exists only as a server side cookie - a file on the web-server. Delivery details must be confirmed before the order can be placed.

Delivery Details

By default the delivery details are obtained from the physical address of the branch. However, any of the information in this screen can be over-ridden. This information prints on the dispatch/packing slip and on the invoice.

The inventory location where the stock for the order is to be drawn from is defaulted from the customer branch record. However, it is possible to select an alternative inventory location if the order is to be picked from elsewhere.

The customer's order reference should be entered here and the most appropriate freight company should be selected. The system keeps track of the last freight company used to deliver to the branch and uses this as the default, if it is over-ridden then this new value is stored against the branch.

It is possible to go back to the line item entry screen retaining all the data entered on the delivery details screen by clicking on the modify line items button. If the inventory location to draw from has been changed the colouring of the background of the line items will be updated to reflect the stock available at the new location to pick from.

If the automatic freight calculations are being used - see the parameters in config.php, the freight cost will be calculated based on the sum of the whole order cubic metres and weight. The best shipping company will also be returned. The user can choose to charge the freight calculated or just use the cheapest freight company. The freight charge calculated can be over-ridden if required.

Once all details are entered correctly the Place Order button should be clicked. It is important to note that abandoning the order before this button is clicked there have been no updates to the database and nothing is saved. Clicking into some other screen loses the order as entered. Whilst it is perfectly acceptable to have several browser screens open looking at different inquiries at the same time. It is not possible to have two windows entering two separate sales orders at the same time, entries in the one window will over-write the other.

Entry of Cash Sales Directly - Counter Sales

In version 3.12 of webERP a new feature was introduced which allowed for cash sales to be entered directly without first entering an order and then confirming a dispatch to invoice. This feature is known as "counter sales". From the main menu->Sales tab select Enter Counter Sales. Entry is similar to entering an order, by default the quick entry screen allows entry of item codes and quantities but it is also possible to select items by the search functions in much the same way as an order. The tax is calculated and the total amount to pay is shown. This page also expects the payment to be made and entered. The payment entered is automatically allocated to the sale.

Behind the scenes this script produces all the database entries for an order and an invoice with sales analysis, stock movements etc etc all correctly created. The customer (and customer branch) used for the entries is derived from the user's default inventory location.

Setting Up Counter Sales

webERP looks at the user's default location and then looks up against the location record to find the cash sales debtor account (and branch) to use for counter sales entered. Each location for which counter sales are required must first be set up with the cash sales customer and branch which is to be used for counter sales entered. Note that the default location of the customer branch is ignored - the user's default location (see Setup->General->User Maintenance - the script webERP/WWW_Users.php) is used as the location and stock movements are all created from this location against the customer specified in the location record (Setup - > Inventory Setup -> Location Maintenance - the script webERP/Locations.php). To specify the customer and branch to use for counter sales for an inventory location (or warehouse), the customer code and branch code must be entered in the format customercode-branchcode in the field provided for this purpose. i.e. the customer code then a hyphen then the branch code.

Modfiying An Order

Only Outstanding sales orders can be modified. Only these orders have any balance of a quantity remaining to be delivered and/or invoiced. Order lines that have been invoiced completely will not be available for modification. New items cannot be added to the order. Pricing cannot be altered if any amount of the line has already been delivered/invoiced. Quantities of an order line cannot be reduced below the quantity of the line already invoiced.

Note that changing the delivery address of an outstanding order that has already had some of the order delivered and invoiced will affect re-prints of the initial invoice - it will show as being delivered to the order delivery address that has been modified. Hard copy of original invoices are required.

Selecting an Outstanding Sales Order

There are several ways:
 

• If the item ordered is known, sales orders can be selected that have the item on by first selecting the item in the Select Item page, once the item is selected a link to show outstanding sales orders is displayed.
• If the customer is known, then first select this customer then use the link on the customer selection menu to show only the outstanding orders for the customer selected.
• All outstanding orders can be displayed by entering the Outstanding Sales Orders screen without a customer or item directly from the main menu under the orders tab. The outstanding Sales Orders screen also has facilities for looking up a part directly as well.

The Outstanding sales orders are shown by inventory location, the inventory location desired can be selected on this screen, by default the location defined as the default for the user is shown. The orders matching the criteria are only shown when the user clicks on the search orders button.

The orders displayed each show links to modify the line items, invoice the order or print the dispatch note. If the order has already been printed this link will show that it has already been printed to avoid printing several dispatch notes and risk doubling up deliveries.

Quotations

A quotation can be entered for any customer/branch in much the same way as entry of an order. The pricing can be changed and discounts entered for the quotation in the same way as an order. An order is flagged as a quotation from the Delivery Details screen. On entry of a quotation a link to produce a pdf quotation for sending to the customer is available. If the quotation option is selected then the stock is not reserved in the stock status inquiries. Quotations can shown on the outstanding sales orders screen by selecting the option to show quotations. When this option is set only quotations show, there is a link so that they can be modified and if necessary changed to a sales order, there is also a link to re-print the pdf quotation.

Having changed a quotation to a sales order, from then on the process is the same as for any other sales order, a packing slip can be printed and the order confirmed for invoicing.

Recurring Sales Orders

Orders entered can be defined so as to recurr at a desired frequency entered as:

• weekly
• fortnightly - (2 weekly)
• monthly
• bi-monthly
• quarterly
• six monthly
• annually

If the order entered contains only 'dummy' service items - ie those items that do not refer to physical stock that requires advice to warehouse people to effect the delivery - then the order can be flagged to invoice automatically.

The process of defining a recurring order is done from the normal order entry screens - entering the line items and then the delivery details. However, instead of clicking the "Place Order" button, the user should click the "Create Recurring Order" button. This then allows entry of:

• The frequency that the order should recurr
• The starting date from when the order should start to recurr
• The ending date after which the order should not recurr anymore
• If all the line items on the order are dummy items then an option to auto-invoice is also shown

It is possible to review the recurring order templates currently defined from the SelectRecurringSalesOrder.php script which allows the entry of the dispatch location and then lists all those recurring order templates that are defined to be dispatched from this location.

From this selection screen it is also possible to select the template for modification. Line items on the order cannot be modified here, only the frequency, start and stop dates. If line items need to be modified then the template can be deleted and a new template created.

The sales orders are created from the recurring sales order templates by the script RecurringSalesOrderProcess.php. This script loops through all the recurring order templates and creates the orders as necessary based on the current date and the last time an order was created for the template and the frequency it is to recurr. The date of the last recurrence is updated in the template as the date of the last recurrence + the number of days between recurrences. An email is also produced for the email contact stored in the location record from where the delivery is to be effected from. The email advises that an order was created, the order number and if it was auto-invoiced. Ideally this script should be run from a scheduler/cron daily. It can be run as many times as you like and only create the orders required - without duplicating incorrectly.

Discount Matrix

webERP has a system called a discount matrix which allows any group of products to be defined and discounts applicable to all items of the group to be set up just once for the whole group of items. Different discounts can be applied to the "discount group" for each sales type (price list). When an item is entered into a sales order the system retrieves the correct price based on the customer's sales type (price list) and then retrieves the appropriate discount based on the quantity of the item and the other items already entered on the order. The discounts retrieved can be over-ridden.

To define the grouping of products:

Select an item that you wish to have a discount structure applied to it - using the "Select Item" link. Under the "Item Maintenance" section click on "Maintain Discount Category".

If there are no currently available discount categories then enter a discount category code - otherwise select the discount category that you wish to allocate the item to.
 

You can now search for additional items and add as many items to the discount group as you wish from this screen.

Having created the discount group you can now administer the discount rates applicable to this group of items.

From the main menu go to -> Setup -> Receivables/Payables section -> Discount Matrix

This form allows you to select any of the discount groups defined above and any sales type (price list)and then enter any quantity break and discount applicable given the quantity break - if the discount is applicable for all sales then enter a quantity break of 1

1 Assets

10 cash & Banks

1001 Petty cash

1002 Cash on hand (in Cash Registers)

1010 Bank accounts

1011 Regular saving accounts

1021 Post dated checks

11 Accounts receivable

1101 Receivable from Ordinary customers

1102 Receivable from Foreign customers

1103 Receivable from dealers

1104 Receivable form other client types

1105 Advances to employees

1111 Accrued accounts receivable

1121 Other accounts receivable

1131 Prepaid expenses

1141 Allowances for doubtful accounts (bad debts)

12 Inventory

1201 Stock item's inventory

120101 Finished goods Inventory - Family xxx

120102 Finished goods Inventory - Family yyy

120103 Finished goods Inventory - Family zzz

1202 Raw material inventory

120201 Raw Material items - Family aaa

120202 Raw Material items - Family bbb

1203 Semi finished items

120301 Semi finished goods - Family 111

120302 Semi finished goods - Family 222

1204 Work in progress

120401 Cost element 111

120402 Cost element 222

120403 Electrical works

120404 Sanitary works

120405 Printing

120406 Color separation

120407 Photography

1205 Supplies inventory

 

8 Gain / Losses on sale of assets

81 Loss on sale of assets

8101 Loss of sale on retirement bonds

8102 Loss on sale of investment

8103 Loss on disposal of machinery

8104 Loss on disposal of equipment

8105 Loss on exchange of equipment

8106 Loss on exchange of machinery

8107 Loss on, ----

-------------

82 Foreign exchange loss

8201 Foreign exchange loss

Each account in the chart of accounts is typically assigned a name and a unique number by which it can be identified. (Software for some small businesses may not require account numbers.) Account numbers are often five or more digits in length with each digit representing a division of the company, the department, the type of account, etc.

As you will see, the first digit might signify if the account is an asset, liability, etc. For example, if the first digit is a "1" it is an asset. If the first digit is a "5" it is an operating expense.

A gap between account numbers allows for adding accounts in the future. The following is a partial listing of a sample chart of accounts.

Current Assets (account numbers 10000 - 16999)

10100 Cash - Regular Checking
10200 Cash - Payroll Checking
10600 Petty Cash Fund
12100 Accounts Receivable
12500 Allowance for Doubtful Accounts
13100 Inventory
14100 Supplies
15300 Prepaid Insurance
 

Property, Plant, and Equipment (account numbers 17000 - 18999)

17000 Land
17100 Buildings
17300 Equipment
17800 Vehicles
18100 Accumulated Depreciation - Buildings
18300 Accumulated Depreciation - Equipment
18800 Accumulated Depreciation - Vehicles
 

Current Liabilities (account numbers 20000 - 24999)

20100 Notes Payable - Credit Line #1
20200 Notes Payable - Credit Line #2
21000 Accounts Payable
22100 Wages Payable
23100 Interest Payable
24500 Unearned Revenues
 

Long-term Liabilities (account numbers 25000 - 26999)

25100 Mortgage Loan Payable
25600 Bonds Payable
25650 Discount on Bonds Payable
 

Stockholders' Equity (account numbers 27000 - 29999)

27100 Common Stock, No Par
27500 Retained Earnings
29500 Treasury Stock
 

Operating Revenues (account numbers 30000 - 39999)

31010 Sales - Division #1, Product Line 010
31022 Sales - Division #1, Product Line 022
32015 Sales - Division #2, Product Line 015
33110 Sales - Division #3, Product Line 110
 

Cost of Goods Sold (account numbers 40000 - 49999)

41010 COGS - Division #1, Product Line 010
41022 COGS - Division #1, Product Line 022
42015 COGS - Division #2, Product Line 015
43110 COGS - Division #3, Product Line 110
 

Marketing Expenses (account numbers 50000 - 50999)

50100 Marketing Dept. Salaries
50150 Marketing Dept. Payroll Taxes
50200 Marketing Dept. Supplies
50600 Marketing Dept. Telephone
 

Payroll Dept. Expenses (account numbers 59000 - 59999)

59100 Payroll Dept. Salaries
59150 Payroll Dept. Payroll Taxes
59200 Payroll Dept. Supplies
59600 Payroll Dept. Telephone
 

Other (account numbers 90000 - 99999)

91800 Gain on Sale of Assets
96100 Loss on Sale of Assets

This is a partial listing of another sample chart of accounts. Note that each account is assigned a three-digit number followed by the account name. The first digit of the number signifies if it is an asset, liability, etc. For example, if the first digit is a "1" it is an asset, if the first digit is a "3" it is a revenue account, etc. The company decided to include a column to indicate whether a debit or credit will increase the amount in the account. This sample chart of accounts also includes a column containing a description of each account in order to assist in the selection of the most appropriate account.

Asset Accounts

Liability Accounts

Owner's Equity Accounts

Operating Revenue Accounts

Operating Expense Accounts

Non-Operating Revenues and Expenses, Gains, and Losses

Accounting software frequently includes sample charts of accounts for various types of businesses. It is expected that a company will expand and/or modify these sample charts of accounts so that the specific needs of the company are met. Once a business is up and running and transactions are routinely being recorded, the company may add more accounts or delete accounts that are never used.

At Least Two Accounts for Every Transaction

The chart of accounts lists the accounts that are available for recording transactions. In keeping with the double-entry system of accounting, a minimum of two accounts is needed for every transaction—at least one account is debited and at least one account is credited.

When a transaction is entered into a company's accounting software, it is common for the software to prompt for only one account name—this is because the software is programmed to automatically assign one of the accounts. For example, when using accounting software to write a check, the software automatically reduces the asset account Cash and prompts you to designate the other account(s) such as Rent Expense, Advertising Expense, etc.

Some general rules about debiting and crediting the accounts are:

• Expense accounts are debited and have debit balances
• Revenue accounts are credited and have credit balances
   
• Asset accounts normally have debit balances
• To increase an asset account, debit the account
• To decrease an asset account, credit the account
   
• Liability accounts normally have credit balances
• To increase a liability account, credit the account
• To decrease a liability account, debit the account

Service/Consultancies do not hold stock of anything. Whilst webERP is rich in features that assist businesses that have to deal with stock (inventory), it is also suitable for service businesses.

When an items is defined (Inventory tab -> Add A New Item) , the field

"Assembly, Kit, Manufactured or Service/Labor: "

must be defined as Service/Labour. This tells webERP that we are not keeping stock at all for this item. Stock inquiries will show N/A.
You might make an item say for "Computer consultancy" and another for "webERP support" the units might be in hours or other unit you charge for consultancy in.

Pricing for a unit of the service/consultancy item is much the same as any other item - you can price in different currencies and have prices for different customers etc. See the manual on pricing.

Often when you invoice service items you need to provide a description of what the order was for and this can often be several lines - you will not wish to go through changing the item description every time - it is too short anyway and will not show correctly on old invoices that had a different description. The answer is to use the feature that allows free-form narrative against each line item ordered/invoiced. This feature is accessed from Setup -> Configuration Settings

 

webERP is an open-source entirely web-based ERP solution that allows anyone to contribute their ERP knowledge to the development of webERP. WebERP is a accounting and ERP solution that can be accessible through a browser and pdf readers. You can run webERP "inhouse" on your own server, on an internet server, or it can be run as a cloud application.

webERP Order Entry: webERP Order Entry allows users to enter quotations that can then be changes to an order upon customer acceptance, allows for multiple dispatches from a single order, orders entered can be invoiced directly with little additional input, pricing can be set to take effect  from specific dates and can provide companies with daily sales reports and ad-hoc sales reports.

webERP Taxes: provides companies with taxation options for many countries, allows companies to use tax categories so tax rates are dependent on type of product, allows for tax rates to also be dependent on location of the warehouse the order is shipped from and allows multiple taxs payable to different tax authorities.

webERP Accounts Receivable: webERP provides many account receivable features including inquires on payments received to show how the payment was allocated to invoices and difference exchange attributed to each invoice and can be fully integrated with stock records and general ledger to provide users a full trail of journals for each transaction.

webERP Inventory: offers companies a large array of inventory features including the inclusion of unlimited number of warehouses, provides a history of stock movements allowing companies full traceability, allows for standard costs to be manually maintained or automatically generate average costs and provides companies with the inventory usage per month.

webERP Purchasing: helps companies by allowing purchase orders to be in any currency, goods received can be entered up to the purchase order quantity plus user defined percentage for over deliveries, allows for purchase orders to be emailed to defined suppliers and purchase order approval processes can be defined and followed.

webERP Accounts Payable: allows a company’s suppliers to be defined in any currency, allows for invoices to be entered against the good received with user definable allowances, provides an aged listing of balances that shows either a summary of balances or a more detailed invoice by invoice account balance and includes a fully integrated general ledger to help companies control account balances.

webERP Bank: allows bank accounts can be in any currency and it allows for payments/receipts to be paid in any currency as well, helps companies keep track of transfers between accounts by either entry of payment to another bank account or by the receipt of the transfer and calculates and posts general ledger unrealized exchange differences in foreign currency bank account balances.

webERP General Ledger: provides companies with many general ledger features including balance sheet and profit and loss statements, posts journals into any periods, provides reverse journals, allows for accounts to be grouped using relational methods and account groups can be organized in a hierarchical structure.

webERP Manufacturing: provides companies with multiple level bills of materials designed to help sopt errors, provides automatic cost roll up on changes of BOM or component costs, provides companies with work order costing that automatically provides the weighted average costs and provides a full MRP solution containing production schedule and forecasting.

webERP Contract Costing: webERP contract costing provides job costing to be created for select customers using a variety of requirements that can later be converted into quotes and provides full reports on contract costs and quoted cost differences.

webERP Fixed Assets: asset can be added through purchase orders or supplier invoices, allows for disposal of fixed assets through sales order entry and provides companies with integrated GL entries based on asset category.