Development - Structure

This page will be of interest primarily to developers wishing to get to grips with the system and how the various scripts function.

Sales Orders

Initiation of orders is done from the script :

SelectOrderItems.php

This script contains functionality to select the customer for the order as well as selecting the parts for the order.

The order processing logic revolves around a cart object called Items which is declared as a session variable. It contains an array of LineItem objects, each line item contains all the information about the order line items - I hope predictably! The Items session variable also contains the order header data about customer, currency, sales type etc. The entire order is thus cached in this session variable. Updates to the database for the cached sales order are only effected when the user explicitly commits modifications. This is actually done from the

DeliveryDetails.php script.

The SelectOrderItems.php script also allows modifications to pre-existing orders by repopulating the Items session object and the Items-LineItems array directly from the database. Checks are necessary to ensure that changes are sensible.

The script has two ways to select parts to add to an order:

1. By selecting the stock category or an extract of the code or description. The user must then hit the search button to initiate the search. The page displays the choice of parts meeting the criteria for selection.
2. By entering the part code and quantity directly. This allows quick entry of sales orders, where the user is familiar with the stock codes. The user must hit the quick entry button to initiate the processing of entries in the quick entry grid.

Pricing

The script looks up the pricing for the customer based on the customer currency and sales type. As many sales types as required can be set up each with its own price list. Where there is no pricing set up for the sales type and currency of the customer then no parts are available for adding to the order.

Kit set parts can be entered - these are defined at the stage of the inventory item setup - they are exploded into their components for modification directly in the order. They are a short cut to selecting each individual part where only one part changes. eg a computer with xyz motherboard, case, keyboard, mouse, 256Meg RAM etc. The kitset part could bring all these parts into the order, but then allow deletion of the 256Meg RAM and replacement with the code for 512Meg RAM or whatever modifications are required.

Assembly parts can also be entered that refer to underlying component parts but priced at the assembly level. An assembly part is not exploded into its components at the time of order entry like a kitset. It exists in orders and sales analysis records but not for stock quantity records maintained although movement records are created for the assembly parts as well as the components of the assembly.

Delivery and Freight Charges

Having selected the customer and the line items for the order, the delivery details need to be entered. Depending on the entries in logicworks.ini the freight charge is calculated. There is an option to NOT calculate a freight charge if the total order value is greater than a specific value. The freight calculation is based on the entries made for the various courier companies from the selected stock location to the city of the delivery address entered. If the city is not found in either line 2 or 3 of the delivery address then the script returns an error. Where several courier companies are found then the system selects the one with the least cost based on the total of the kgs on the order or the volume of the order. The freight calculation is a function held in a seperate file FreightCalc.php requiring parameters to be passed, the delivery address lines, the from location the volume and weight of the order. The function returns an array containing the BestShipper and the FreightCost. The FreightCalc file is included into the DeliveryDetails.php script. There is therefore a requirement to maintain the volume in cubic meters and weight in kgs for each part and also the scale of freight costs if this functionality is used.

If the data requirement to use this effectively is considered too great, it is possible to disable this freight calculation too in logicworks.ini.

Once the order delivery details are all entered in the DeliveryDetails.php script then the order can be committed to the database. It is entirely cached in the Items session variable to this point and only when the order is placed or changes committed is the session variable cleared and the database updated.

Finding Sales Orders

Orders can be found using the script:

SelectSalesOrders.php

This script allows a number of ways to find an outstanding sales order.

1. By customer - a customer selected from the SelectCustomer.php script can call this script to show only outstanding orders for the customer selected.
2. By part - selection of a part is built into the script. The purist would have the SelectProduct functionality seperated in a seperate script. However I feel that this way makes for a more intuative user experience.
3. An order number can be entered directly.

The SelectSalesOrders.php

script also provides links on the orders returned to allow the order to be modified or invoiced.

Modification of order line items is done in the same script as originally created ... SelectOrderItems.php but it is not possible to change a line quantity to a quantity less than is already invoiced, or to delete a line that has some quantity already invoiced.

Invoicing

An invoice can only be created by first selecting the items to invoice onto a sales order. The order can then be invoiced.

The link to invoice the order from the SelectOutstandingOrders.php script shows all the line items on the order that are yet to be invoiced. There is opportunity for the user to alter the quantity to invoice but not the price/discount. There is also opportunity to manually over-ride tax calculations and freight charges.

The ConfirmDispatch-Invoice.php script actually processes the invoice within a database transaction creating the DebtorTrans record, the SalesAnalysis record, the stock movement records updating the location stock records and the sales order delivery details.

To look at the details of a completed order the script:

SelectCompletedOrder.php

allows similar selection facilities as the outstanding sales orders searches. This page also shows the quantities on the order that have been delivered and invoiced.

Accounts Receivable / Debtors Accounts

A customer account consists of a master record ? the branch records set up against the master record and the transactions which require a branch record for invoices and credits but no branch record for receipts. The balance of the account is not held against the master record but is accumulated from the transactions that have an amount not yet allocated. Invoices (SysTypes TypeID=10) ie charges are recorded as positives in the DebtorTrans table and credits (SysTypes TypeID=11) and receipts (SysTypes TypeID=12) are recorded as negatives.

Accounts Receivable Receipts

Since cash comes in for a number of reasons , the most common of which is the payment of invoices , the receipt form allows for entry of GL items as well as customer receipts. The total of which may need to be collated for banking. The allocation of receipts is a separate process completely see below. The script for receipts creates a class to hold all the information about the receipt before it is all accecpted. Only then is the database updated with the necessary records to record the receipt and general ledger impact if the debtors link is active.

Accounts Receivable Allocations

The system is designed so that allocations can only be made by selecting either receipts or credit notes and the available invoices for allocating to are then found. Amounts can be entered against invoices until the whole receipt or credit is allocated. An update option allows the total left to allocate to be recalculated taking into account any amounts entered against invoices already.

NB. Since there is no use of java or client side scripting, there is no way to keep track dynamically of how much is left to allocate.

The allocations script can be called with:

1. no parameters where it will return all the receipts and credit notes that have a balance yet to be allocated to invoices.
2. A customer code - all credits and reciepts will show for that customer that are yet to be fully allocated.
3. A transaction type (11 or 12) and transaction number ? this will show the transaction and the amount previously allocated to it with the invoices it was allocated to together with any unallocated invoices. The existing allocations can be modified at will and new allocations made.

Sales Analysis

All invoices and credit notes create or update sales analysis records. Sales analysis records go down to the part level. There is some duplication of data by maintainig a seperate sales analysis table. The rationale for this is:

• improve the simplicity of required queries to produce sales analysis and hence speed of creation of reports.
• allow indexing of common fields for analysis in sales analysis to further improve performance of sales analysis queries.
• to remove the dependencies between data tables. If stock movements are purged this could create problems for sales analysis.

Sales analysis reports can be designed for up to four levels of sorting. The report writer is hopefully simple, but offers great flexibility. Report designs can be saved for running later. Reports can be run to output pdf files for printing directly or saving locally for emailing or archiving. Alternatively, reports can be run to create .csv (comma seperated values) files for analysis in most spreadsheet applications or import into user databases such as Borand?s Paradox or Micosoft Access.

Sales analysis reports are designed and stored as a header record containing the information about the sorting and criteria for selection and detail records defining the columns to show on the report.

Report column definitions allow the period range and type of information to show eg GP, cost, value, quantity. Periods are monthly and maintained invisibly to the user. The period is only ever used for general ledger reporting and for sales analysis. An enquiry page from the report columns definition page allows for easy reference to the period required.

Purchase Orders

Similar selection facilities exist for purchase orders as do for Sales orders using the script

POSelectOrders.php

this script shows all outstanding orders where there are deliveries yet to be received. A specific supplier or part can be selected to show only purchase orders meeting the criteria selected.

The script also shows links to:

1. Modify the order within certain bounds eg cannot reduce a purchase order line quantity below the quantity already received.
2. Print the purchase order. This link is disabled if the purchase order has already been printed. Orders can be re-printed but a warning shows that the order has already been printed so that there can be no accidental double printing and sending of an order to a supplier.
3. Receive items on the order.

Inventory

Stock movements are created - depending on the type of stock item - each time a product is invoiced or credited. If an item is credited and written off eg. goods damaged in transit then two stock movements are created:

1. To bring the stock item back into stock and record the credit to the customer.
2. To write the item off to the selected GL account.

Stock movements are also created when an item is received against a purchase order.

Each time a stock movement is entered the stock quantity at the location is updated.

The stock is therefore fully integrated with sales and purchasing. The only stock transactions that involve direct entry are:

1. Stock transfers between locations.
2. Stock quantity adjustments.

It is not possible to enter either of these two types of transaction against dummy, assembly or kitset parts since no stock movements or stock quantities exist for these types of parts.

Stock Inquiries

Selecting a product shows all the options available to operate on the part.

• Stock usage by location
• Stock status showing quantity on hand, quantity on order, quantity demanded and re-order quantity.
• Stock movements by location for defined date range.
• Outstanding sales orders

All inquires follow a similar format, that allow input of the stock code directly for users familiar with the codes. Alternatively, the enquiry script can be called from the SelectProduct.php script which has all the facilities to be able to select the part required.

Accounts Payable

Supplier invoices are entered using the script:

SuppInvoice.php

This script must be called with a SupplierID from the SelectSupplier.php page. Once a supplier is passed to the page a new SuppTrans object is created to hold (cache) all the information about the invoice. The SuppTrans class has three arrays one for the GL analysis, one to hold the shipment charges (e.g. freight, cartage and duty) and the third for the Goods Received to be invoiced GRNs ? these could also be items on a shipment.

If the GL link to creditors in the company preferences is set then the amount to invoice must be accumulated from stock items received being invoiced, the shipment charges and the general ledger postings entered. There is no opportunity to enter the total invoice amount manually.

General ledger analysis link only shows if the GL Creditors link is active. This script allows population of the GLCodes array. The page allows a GL code to be entered directly by a user familiar with the GLCodes or to select a code from a select box. Plenty of space for narrative is available too.

The link from the SupplierInvoice.php script to the SuppInvGRNItems.php allows the goods received from the supplier that have not already been invoiced to be selected for invoicing. The quantity received shows for each part together with the quantity already invoiced. The quantity being invoiced is defaulted to the amount received less any amount already invoiced. This can be changed as can the price charged. There are three parameters in logicworks.ini that affect the behaviour of this script. If the parameter to check for over deliveries is set then the remaining two parameters are used to check the proportion that the order is over invoiced by in terms of the quantity invoiced and the price charged respectively.

The total of all lines of goods received being invoiced are accumulated. If the GL link to creditors is active then the order lines and the GL lines are accumulated together to get the total currency amount of the invoice. If the link is not active the currency amount must be entered manually, but the amount must be more than the goods received being invoiced.

The due date of supplier invoices defaults to the date of the invoice entered after applying the terms defined for the supplier. There is an option to create a payment directly from the invoice creation. The payment record created will be for the total of the single invoice.

Supplier Payments

Records can be created for all due amounts either by using the payment run or using the manual payment entry.

The payment run creates payment records for all payments due to the specified date in the specified currency at the specified exchange rate, from the specified bank account. The allocation records necessary are also created by this process. The payment run calculates the differences on exchange for each invoice settled and updates the invoices for allocated amounts and produces general ledger transactions if the creditors link is active. The bank payment record is also created for bank reconciliation purposes.

Manual supplier payments can be entered by selecting the supplier then the manual payment link. The currency of the supplier is automatically defaulted. However, the rate must be entered and the amount together with any reference.

Manual payments screen called without the SupplierID also allows entry of general ledger analysed payments.