GM-X ERP for Blockchain - Frequently Asked Questions (FAQ)

Logging On to the system: How do I access the system?; How do I logon as a representative of an internal organisation?; How do I logon as a representative of an external organisation? (Supplier Portal)
Miscellaneous: How can I prevent key words from being deleted from the database?; How can I prevent clients from accessing unlicensed subsystems?
Currency Codes and Exchange rates: Where are currency codes defined?; Where are exchange rates defined??; How do I define my home/operating/functional currency?; How do I deal with other currencies in certain documents?
Sales Order Processing: How do I deal with Sales Tax (called Value Added Tax in the UK)?; How do I deal with Sales Tax in countries other than my own?; How do I deal with UK Alcohol Tax?; How do I not charge Alcohol Tax for a customer in the UK who is bonded?; How do I deal with Foreign Currencies on Sales Orders?; How do I prevent certain products from being added to sales orders?; How do I set up Contract/Agreement Pricing for particular customers?; How are adjustments such as Sales Tax automatically attached to an order?; When is an invoice sent to the customer in the sales order process?; How can I signify which changes in order status are valid?; How can I send emails to the customer automatically when the order status changes?; How do I define Payment Terms?; How do I define an Early Settlement Discount?; How do I define Withholding Tax?
Inventory: How do I book existing stock into inventory?; How do I consume inventory in a production run?; How do I book the output from a production run into inventory?; How can I put certain stock into quarantine when receiving into inventory?; How do I convert raw materials into a finished product?; How is the ownership of inventory handled?
Shipments: What are the steps in the processing of outbound shipments?; What are the steps in the processing of inbound shipments?; How are Purchase Returns handled?; How are Customer Returns handled?
Parties (Organisations, People and Addresses): How are postal addresses held in the system?; What happens when an address in entered?; Why do searches on geographic areas miss out some inner areas?; What are "Functional Units" and how do I create them?
Products: How can I change a product price on a particular date?
Purchase Order Processing: How can I create a Purchase Order from a supplier's Quotation?; When is a PO sent to the supplier in the purchase order process?

1. How do I deal with Sales Tax (called Value Added Tax in the UK)?

In the UK there is not a single rate of VAT (sales tax) which covers all items, instead there are different rates which cover different categories of items:

Standard Rate - currently 20%
Reduced Rate - currently 5%
Zero Rate
Exempt

Although these categories are defined on the PRICE_COMPONENT table by default, you can disable any that you don't use by setting their end_date in the past thereby making the entry historic instead of current.

The following VAT entries are defined on the PRODUCT_CATEGORY table by default. You can add others if you wish.

Id	Description
VAT-S	Standard Rate VAT
VAT-R	Reduced Rate VAT
VAT-0	Zero Rate VAT
VAT-E	VAT Exempt

If you use more than one tax rate then you must add entries to the PROD_CAT_CLASS table in order to link each PRODUCT with the relevant PRODUCT_CATEGORYs. Note that it is not necessary to link Standard Rate products with the Standard Rate category as every product is assumed to be Standard Rate unless it is linked to one of the non-standard rates.

You must then ensure that the PRICE_COMPONENT table contains entries for each tax rate that you intend to use. Note that each of these records has its own start and end date, so it is possible to define different percentages for different date ranges. If a particular tax rate is not applicable for your installation then you can set the end date to a date which has already passed. This will cause the search for a record which is current (valid for today's date) to return nothing.

Sales Tax for Standard Rate:

field	value
order_adjustment_type_id	Set to "Sales Tax".
price_type	Set to "Surcharge".
price_frequency	Set to "One Time Charge".
prod_cat_id	Set to "VAT-S".
percent	Set to 17.5 (or whatever is applicable).
area_id	Optional. If you need to deal with sales tax for more than one country then you must specify the country here.
start_date	The date on which this rate comes into effect.
end_date	Optional. The date on which this rate ends. Blank signifies an unspecified date in the future. A date in the past will signify that this entry has expired (has become historic instead of current).

Sales Tax for Reduced Rate:

field	value
order_adjustment_type_id	Set to "Sales Tax".
price_type	Set to "Surcharge".
price_frequency	Set to "One Time Charge".
prod_cat_id	Set to "VAT-R".
percent	Set to 5.0 (or whatever is applicable).
area_id	Optional. If you need to deal with sales tax for more than one country then you must specify the country here.
start_date	The date on which this rate comes into effect.
end_date	Optional. The date on which this rate ends. Blank signifies an unspecified date in the future. A date in the past will signify that this entry has expired (has become historic instead of current).

Sales Tax for Zero Rated/Exempt:

field	value
order_adjustment_type_id	Set to "Sales Tax".
price_type	Set to "Surcharge".
price_frequency	Set to "One Time Charge".
prod_cat_id	Set to "VAT-0" or "VAT_E".
percent	Set to 0.
area_id	Optional. If you need to deal with sales tax for more than one country then you must specify the country here.
start_date	The date on which this rate comes into effect.
end_date	Optional. The date on which this rate ends. Blank signifies an unspecified date in the future. A date in the past will signify that this entry has expired (has become historic instead of current).

Each time an order item is added, amended or deleted, the total from all items is recalculated, and any order adjustments are applied to this total. Note that sales tax is applied after any discounts and surcharges. A separate subtotal is obtained for products within each category, and the rate for that category is applied to that subtotal. Every product is automatically deemed to be standard rate unless it has been associated with a non-standard rate category.

Note that if any of these adjustments is linked to a particular area_id they will only apply to customers whose primary address is within that area.

2. How do I deal with UK Alcohol Tax?

Organisations such as distilleries and breweries which manufacture alcoholic liquors must levy a special alcohol tax on all their sales in addition to any VAT. Unlike VAT which is a simple percentage which can be applied to the order total, alcohol tax is determined by the volume and strength (known as ABV or % Alcohol By Volume) within each product. As different products can vary in both volumes and strength it therefore becomes necessary for the organisation to perform its own calculation for each product and to define the result as surcharge on an Item Adjustment.

The first step is to define an entry on the ITEM_ADJUSTMENT_TYPE table as follows:

Id	Type	Description
ALCOHOL	Surcharge	Alcohol Tax

The second step is to add entries to the PRICE_COMPONENT table to define the actual tax amount, one for each product. Note that each of these records has its own start and end date, so it is possible to define different values for different date ranges.

field	value
item_adjustment_type_id	Select "Alcohol Tax".
price_type	Set to "Surcharge".
price_frequency	Set to "One Time Charge".
product_id	Required. The product identity.
quantity_break_id	Must be empty.
value	Enter the value which has been calculated using this product's volume and ABV.
area_id	Select "United Kingdom" to limit this entry to customers within the UK only.
start_date	The date on which this surcharge comes into effect.

Each time an order item is added any adjustments for that product will be identified and added to that order. Any adjustment value will be added to the base price for that item.

Note that as each of these adjustments is linked to a particular area_id, they will only apply to customers whose primary address is within that area.

3. How do I not charge Alcohol Tax for a customer in the UK who is bonded?

After an alcoholic liquor has been distilled it is stored in a bonded warehouse before it is sold. As soon as it is removed from that bonded warehouse the government's alcohol tax becomes payable UNLESS it is moved to another bonded warehouse. This includes being sold to a customer who will store the product in his own bonded warehouse, possibly because that product will be blended into his own product. It then becomes the responsibility of that customer, not this organisation, to pay the alcohol tax to the government, and to add the alcohol tax to his customers' invoices.

It is therefore necessary to identify such customers so that, even though they reside in the UK, they are not eligible for UK alcohol tax.

The first step is to create an entry on the PARTY_CLASS table as follows:

Id	Description	Party Type
TAX	Taxation Options	Organisation

The second step is to create a related entry on the PARTY_SUBCLASS table as follows:

Class	Subclass	Description
TAX	BONDED	Bonded (exempt from alcohol tax)

The third step is to create a entry on the PARTY_PRICE_EXCLUSION table for each alcohol tax entry as follows:

Field	Value
price_component_id	The identity of a price component which identifies a product's alcohol tax.
party_subclass_id	BONDED (from the PARTY_SUBCLASS table above)
start_date	The date on which this entry comes into effect.

The final step is to identify those customers (parties) to whom this exclusion applies. This is done by locating the customer's PARTY record, then adding an entry to the PARTY_SUBCLASS_LINK table as follows.

Field	Value
party_id	The identity of an entry on the PARTY table.
party_subclass_id	BONDED (from the PARTY_SUBCLASS table above)
start_date	The date on which this entry comes into effect.

This means that even though a UK customer may be eligible for the UK alcohol tax, it is not applied in those cases where the customer shares a PARTY_SUBCLASS entry with one that is defined on that adjustment's exclusion list.

4. How do I deal with Foreign Currencies on Sales Orders?

Please read the following for background information regarding the handling of currencies:

Where are currency codes defined?
Where are exchange rates defined??
How do I define my home/operating/functional currency?
How do I deal with other currencies in certain documents?

For Sales Orders the two parties are identified as follows:

party_id_internal - this is the issuing party.
party_id - this is the receiving party (the customer).

All order values are input in transaction currency which may or may not be the same as the organisation's home/operating currency. If they are different then the current exchange rate between those two currencies will be captured, and this rate will be used to convert all transaction/foreign currency amounts into home/functional currency. All the order processing enquiry screens will have a "Switch Currencies" button which, when pressed, will toggle the display to show the amounts in one currency or the other. With all communications with the customer, such as with emails or PDF copies, the values will always be shown in the transaction/foreign currency.

All order payments will also be entered in transaction currency, and the enquiry screens will also have a "Switch Currencies" button.

5. How do I prevent certain products from being added to sales orders?

It may be the case that there are certain items in the organisation's product catalog which are not for sale to customers, such as unfinished goods. The easiest way to ensure that such products are not added to sales orders is to remove them from the list of products which a sales person sees during the order entry process. If a product cannot be seen, it cannot be selected.

In the GM-X application there are several tasks which provide lists of products, and there is one which is specifically used for sales order entry, so it is simple to modify this task to exclude certain products. The only difficulty is deciding which products? The answer lies in the use of flexible product categories.

The first step is to create an entry on the PRODUCT_CATEGORY table as follows:

Id	Description
NOTFORSALE	Not for sale

The second step is to add entries to the PROD_CAT_CLASS table which links selected PRODUCTs to this new category. NOTE - this is done automatically whenever a new product is created to give the user time to add all the associated data, such as features and price components. Once the data is complete the product will not appear in any 'for sale' lists until this entry has been removed.

During the sales order entry process the user must access a POPUP form to choose from the list of available products, and this particular form has been programmed to exclude any product which has a current "NOTFORSALE" entry on the PROD_CAT_CLASS table.

Note that it is possible to have multiple 'Not For Sale' categories by using codes which begin with 'NOTFORSALE', as in the following:

Id	Description
NOTFORSALE1	Not for sale (category 1)
NOTFORSALE2	Not for sale (category 2)

6. How do I set up Contract/Agreement Pricing for particular customers?

It is quite common for large, important customers to negotiate a special price for a product instead of the "normal" price which is charged to everyone else. This is known as Contract Pricing or Agreement Pricing.

All that is necessary is to create an entry on the PRICE_COMPONENT table for each combination of product and customer, as follows:

field	value
price_type	Set to "Base Price".
price_frequency	Set to "One Time Charge".
product_id	The product identity
value	The agreed price for this customer, in home currency.
customer_id	The customer (party) identity.
start_date	The date on which this price comes into effect.

7. How do I book existing stock into inventory?

When an organisation with existing inventory starts to use this system there may be existing stock which needs to be recorded. The steps to achieve this are as follows:

Create the FACILITIES (warehouses, depots, etc) where stock may be held.
Define the CONTAINERS that exist within each of those facilities.
You may create the INVENTORY ITEM beforehand, or create it during the receiving process. Note that if a product will have stock in several locations it will have a separate entry for each location.
In the Shipments subsystem you must create an inbound shipment, which can be one of the following:
- A Supplier Shipment - for which you must choose the Supplier and the Receiving Party using the popup buttons.
- A Transfer In - for which you must choose the Sending Party and the Receiving Party using the popup buttons.
After creating the SHIPMENT record the system will automatically create a PACKAGE record so that you can then create a PACKAGE_IN_CONTENT record for each product identifying the quantity that you wish to add to inventory.
On the screen which lists the package contents is a navigation button called 'Inventory Receipts' which will allow you to book each item into inventory. Initially this screen will be empty, but you can press the 'New' button to create a new INVENTORY_RECEIPT record.
The 'Add Item Receipt' screen will show the product_id and ask you to choose an inventory_item_id using a popup button. You may either:
- Choose one of the listed items.
- Press the 'New' button to create a new inventory item. You must supply a facility_id and a container_id.
When you press the 'Submit' button on the 'Add Item Receipt' screen this will:
- Create an ITEM_RECEIPT record which will cause the qty_on_hand for that inventory item to be incremented.
- On the 'List Inbound Package Content' screen it will show against each item the amount that has been booked into inventory.

8. How do I consume inventory in a production run?

This is where raw materials are taken from inventory and turned into finished goods by some production process.

Use an Outbound Transfer to move stock from inventory to the production facility. Each ITEM ISSUANCE will then decrease the on-hand quantity of an INVENTORY_ITEM.
There is no need for an equivalent Inbound Transfer to the production facility as the raw materials will be consumed and not stored.

NOTE: A more sophisticated process is described in How do I convert raw materials into a finished product?.

9. How do I book the output from a production run into inventory?

This is where raw materials are converted into finished goods by some production process, and the finished goods are then booked into inventory.

Use an Inbound Transfer to move stock from the production facility into inventory. Each ITEM RECEIPT will then increase the on-hand quantity of an INVENTORY_ITEM.
There is no need for an equivalent Outbound Transfer from the production facility as it does not hold any inventory.

10. What are the steps in the processing of outbound shipments?

There are several stages in the preparation of outgoing shipments which involve running different tasks in several subsystems.

Customer Shipments and Outbound Transfers

Create the sales/transfer order and add order items. Initial status is automatically set to "Pending".
If required send a copy of the completed sales order to the customer and wait for confirmation. Status changed to "Pro Forma Sent".
Receive customer's confirmation. Status changed to "Confirmation Received".
Send the order to be approved by a manager or supervisor. Status changed to "Awaiting Approval".
When the order is approved all the items are added to a pick list. Status changed to "Approved for Picking".
The PICKLIST HEADER screen shows order id's, and it contains the following navigation buttons:
- ORDER - to view the order details.
- PICKLIST DETAIL - to view the order items which are in this picklist.
- SHIPMENTS - to view the details of any shipments associated with the order.
The PICKLIST DETAIL screen shows items for a selected order, and for each item it shows the quantity ordered, the quantity picked (issued from inventory), and the quantity packed (inserted into a package for shipment). This will contain the following navigation buttons:
- ITEM ISSUANCES - to show all the item issuances for a selected picklist item.
The ITEM ISSUANCE screen shows all the item issuances for a selected picklist item. A serialised item can only have a single issuance, but a non-serialised item may have several quantities issued from different locations (containers within facilities). Each issuance detail will show the location (facility and container) from where the stock was issued (taken), and the quantities which have been packed into any outbound packages (if any). The following navigation buttons will be shown:
- NEW - create a new item issuance. This requires the selection of an inventory item with enough on-hand quantity.
- ITEM FEATURES - to show the features associated with the selected order item or issuance item.
- ADD TO SHIPMENT - add this item to PACKAGE_OUT_CONTENT record. If necessary a new SHIPMENT and PACKAGE record will be created.
- PACKAGE CONTENTS - if the item has been packed this will show all the items with that package.
A new ITEM_ISSUANCE involves removing a quantity of stock from a particular location (FACILITY and CONTAINER). The user must select the location and, for non-serialised items, the quantity. Several issuances may be created if there is not sufficient on-hand quantity in a single location. An issuance may be delayed as it has to wait for stock to be replenished. Note the following:
- After an item has been issued from stock its on-hand quantity will be reduced.
- If inventory has previously been reserved then the facility, location and quantity will be filled in automatically, and all the user has to do is press the SUBMIT button to complete the issuance and delete the RESERVED_ITEM record.
- If the quantity available goes below the reorder level as defined on the REORDER_GUIDELINE record this will cause a replenishment request will be issued.
Once items have been picked from inventory they can be packaged ready for shipment. This can be done in several ways:
- For customer shipments and outbound transfers the "Add to Shipment" button will create a SHIPMENT and SHIPMENT_PACKAGE record, then a separate PACKAGE_OUT_CONTENT record for each item.
- You can create a SHIPMENT record manually which will also create the first SHIPMENT_PACKAGE record.
- You can then select a package and create a separate PACKAGE_OUT_CONTENT for each ITEM_ISSUANCE one at a time.
- Instead of adding item issuances one at a time you can use the "Maintain Packages" button to maintain all the packages and their contents on a single screen. This will allow new packages to be be created and items to be moved from one package to another.
Once all the packages in a shipment are complete the status of the shipment must be changed to "Awaiting Dispatch".
In order to send shipments to their destinations it is first necessary to create a dispatch event, then to identify which shipments are going to be included in that event. All the packages within the same shipment must be dispatched together within the same dispatch event. If packages cannot be dispatched together they must be assigned to different shipments so that they can be assigned to different dispatch events.
When the dispatch events starts (when the shipments actually leave the premises) the shipment event must be updated to "Dispatched", and this will change the status of all related shipments to "In Transit/En Route".
As each package is delivered it is possible to record the date and time, and this will update the status to "Delivered". If the delivery is not accepted it is possible to specify the reason for its rejection.

11. What are the steps in the processing of inbound shipments?

Supplier Shipments, Customer Returns and Inbound Transfers

As the shipment arrives create a SHIPMENT record to identify who sent it. If it is connected with an internally-generated order it is possible to show the order's identity. Note the following:
- For a Customer Return it maybe necessary to show the RMA number.
- For a Supplier Shipment the supplier may have completed an Advance Shipping Notice (ASN). If the ASN number is specified when creating the Supplier Shipment then all the details from the ASN will be copied across automatically, thus removing the need to enter them manually.
Create a separate record for each PACKAGE within the shipment. It is possible to record the supplier's external package number as well as the internal number.
As each package is opened a separate CONTENTS record should be created for each product that it contains. Serialised items will require a separate entry to identify each serial number.
If any items from a supplier are rejected at this stage the quantity being rejected should be noted, as well as the reason for their rejection. Rejected items can subsequently be processed as a Purchase Return so that they can be sent back to the supplier.
The quantity accepted then be booked into inventory by pressing the "Inventory Receipts" button followed by the "New" button. This will create an ITEM_RECEIPT, which involves choosing an existing INVENTORY ITEM or by creating a new one. This operation will increase the available quantity for that item. It is possible to split the quantity across more than one inventory item if the item is unserialised. If the item is serialised then a separate inventory item is required for each serial number as the inventory item cannot accept a quantity which is greater than 1.

12. How are postal addresses held in the system?

Each postal address within the PARTY system contains the following information:

a unique address_id
address line 1
address line 2
address line 3
town/city
county/state/region
postcode
country

These addresses are held separately from individual party details as it is possible for an address to be shared by multiple parties, and instead of duplicating the details each party contains a pointer to a particular address_id.

The full details of each address are not held on a single database table. Instead they are distributed as follows:

Address lines 1, 2 and 3 are held on the POSTAL_ADDRESS table.
The town/city, county/state/region, postcode and country portions are held as individual entries on the GEOGRAPHIC_AREA table.
The POSTAL_ADDRESS_AREA table identifies which geographic areas are associated with each address.

Other tables are used as follows:

The GEOGRAPHIC_AREA_HIERARCHY table identifies where one area lies within another. This produces a hierarchy such as:
- A postcode exists within a town/city.
- A town/city exists within a county/state/region.
- A county/state/region exists within a country.
The GEOGRAPHIC_AREA_TYPE table allows each geographic area to be classified by type, thus allowing a UK county to be differentiated from a USA state or a Swiss canton. If UK town and USA town are separate types, then Bangor, Wales will have a separate entry from Bangor, Maine instead of trying to share the same entry for Bangor.
The POSTAL_ADDRESS_STRUCTURE table defines the address structure for each country. It identifies which particular AREA_TYPE is used for each of the address components, and whether each of those components is optional or required. In the UK, for example, postcodes are required whereas Eire does not use them.
The CONTACT_MECHANISM table holds the full address string for each postal address, as well as the details of all other contact mechanisms which are not addresses.
The PARTY_CONTACT_MECHANISM table identifies which contact mechanisms are linked to which parties.

It is possible to create geographic areas which are not used in postal addresses, such as sales areas or delivery areas, which act as containers for other areas. These areas, and the areas which are contained within them, must be created manually as they cannot be handled with the input of postal addresses.

It is also possible for a geographic area to be contained within more than one senior area. For example, an English county belongs within the country "England", but is also belongs within the country "United Kingdom". Thus it is possible to search for addresses in the UK, which includes England, Scotland, Wales and Northern Ireland, or to search for addresses in England only.

There are some towns in the UK which can belong in several areas at the same time. For example, "Sutton" is a town in the county of "Surrey", but it also belongs in the pseudo-county called "Greater London". Provided that the AREA_HIERARCHY table contains the correct links then any address which includes the town "Sutton" will be included on any search for either "Surrey" or "Greater London".

13. What happens when an address in entered?

When a postal address is entered it is not a simple matter of writing all the details to a single database record.

The country (a mandatory part of all addresses) is used to retrieve an entry from the ADDRESS_STRUCTURE table. This identifies which AREA_TYPE is valid to be used for each component of the address, and whether that component is optional or mandatory.
A lookup is made on each area name (from user input) and area type (from the address structure) to see if an entry already exists on the GEOGRAPHIC_AREA table to provide a value for area_id. If an entry does not exist then one will be created automatically. This is where a lookup on "Bangor" of type "UK town" will not pick "Bangor" of type "USA town".
After an area_id has been provided a check is made on the GEOGRAPHICAL_AREA_HIERARCHY table to ensure that an entry exists for each junior-to-senior area as identified within that address. Any missing entries are created automatically.
A full address string is constructed from the user input and a lookup is performed to see if that exact address already exists. If it does then this will provide a value for address_id and contact_mechanism_id.
If a match for that full address string is not found the following records are created:
- An entry on the POSTAL_ADDRESS table to hold the values for address1, address2 and address3.
- An entry on the POSTAL_ADDRESS_AREA table for each GEOGRAPHIC_AREA that has been linked with that address.
- An entry on the CONTACT_MECHANISM table which allows that address to be linked to any number of parties.

14. Why do searches on geographic areas miss out some inner areas?

When an address is entered it contains a number of geographical areas, so that address is certain to be included in a search that specifies any of those areas. However, a valid postal address may not contain every possible area with which it should be associated, so it may not appear in a search which specifies one of those "missing" areas. This situation arise for several reasons:

In the UK the "county" part of the address is optional, so it is possible that a search on a county may not include all the relevant towns.
In the UK certain historical counties have been merged or renamed over the years, so it is possible for addresses in the same town to specify different "counties" and still be valid.
The UK post office may accept a region which is not actually a "county" but which is a nearby large city. For example, a small town outside the city of Bristol may include "Bristol" as its region name, but that town may exist in any of the counties of Avon, Somerset or Gloucestershire. A search on any of those counties may therefore not include that town in its results.

This situation can easily be rectified, not by changing the address, but ensuring that the AREA_HIERARCHY table contains an entry which links each "town" to all of its possible "regions". It is possible to link a "town" to as many "regions" as you like so that a particular town, and thereby all the addresses within that town, can be included in a search which specifies any one of those regions.

When a search is initiated on a particular geographic area the contents of the POSTAL_ADDRESS_AREA table is examined in order to identify all addresses which lie within that area. However, as has been explained earlier, it is possible that an address which exists in that area does not have an entry on the POSTAL_ADDRESS_AREA therefore would not be included in the search results. This problem is solved by including in the search criteria all those areas which have been identified on the GEOGRAPHIC_AREA_HIERARCHY table as being immediately junior to the primary search area.

15. How are Purchase Returns handled?

When an inbound Supplier Shipment is received the goods are usually inspected before being placed into inventory. If there are any problems then the affected goods should be returned to the supplier using an outbound Purchase Return using the following steps:

Update the package content record for the product to identity the quantity rejected and the rejection reason.
On the List Package Content screen select the product and press the "Return to Supplier" button. This will add the rejected quantity to a pending outbound Purchase Return shipment to that supplier. It one does not exist it will automatically be created with one package and one package content. Subsequent purchase returns to the same supplier will be added to the same package.
Once the return shipment is complete status of the shipment must be changed to "Awaiting Dispatch". Further processing is the same as for other outbound shipments.

16. How are Customer Returns handled?

After a customer receives his goods he may want to return them for some reason. This will require a type of inbound shipment known as a Customer Return.

It may be a requirement for the customer to complete a RMA before any goods can be returned.
When the goods are actually received they should be booked in as a Customer Return and processed as per any other inbound shipment.

17. How do I deal with non-UK sales tax?

This is similar to FAQ#1, but each PRICE_COMPONENT entry must have its area_id set to the country in question.

18. How can I change a product price on a particular date?

All entries in the PRICE_COMPONENT table have a start_date and an end_date which identifies the date range for which the price applies. An entry without an end date will effectively run on forever. Records with start and end dates effectively have three ranges:

HISTORIC - where end_date is in the past.
CURRENT - where today >= start_date and <= end_date.
FUTURE - where start_date is in the future.

This means that only one record will be valid on any one date.

If you want a new price to become effective on a particular date then you must create a new record with the new value and its start date. It is imperative that you do not simply change the value on the exiting record as you will lose all reference to the old value.

The procedure for creating a new record with a new start date is quite simple:

In the price component LIST screen select the current entry and press the READ button.
Press the COPY button in the bottom right of the screen. This will save the current details in the computer's memory.
Exit back to the LIST screen and press the NEW button which will show a screen with blank values.
Press the PASTE button in the bottom right of the screen to fill the screen with the details which were saved with the previous COPY operation.
Enter the new value and the new start date, then press the SUBMIT button. Note that the new start date must be later than the start date of the current record. It can be any date in the future.

As well as creating a new record with a new start date the system will automatically set the end date on the current record to the day before.

19. How are adjustments such as Sales Tax automatically attached to an order?

On the ORDER_ADJUSTMENT_TYPE table is a field called is_manual which can either be set to 'YES' for manual or 'NO' for automatic. When a sales order is created all those adjustment types which are marked as 'automatic' will then be examined to see if there are any current entries on the PRICE_COMPONENT table for the customer or customer's country. Note that for the UK there may be up to four categories of sales tax as identified in FAQ#1. These entries will be automatically added to the ORDER_ADJUSTMENT table and will supply either a value or a percentage. Until items are added to the order the value for applicable_amount will be zero.

As each item is added to an order the system will determine which tax category (Standard rate, Reduced rate, Zero rated or Exempt) applies to the product. If none is found the system will assume that the Standard rate applies by default. It is only necessary to link a product with a tax category when it belongs to something other than the Standard rate. The system will then accumulate the goods amount for all order items within each tax category and use this as the applicable_amount to which the percentage will be applied in order to determine the total tax due for that rate.

If your organisation does not have any products which fall within a particular tax category the simplest way to prevent them from being added to each order is to locate the entry on the PRICE_COMPONENT table and set the end_date to a date in the past. This will then mark the entry as 'expired', and the system will ignore it.

20. What are "Functional Units" and how do I create them?

The PARTY table contains an entry for every organisation and person who is required to be known to this application. One of these organisations is known as the "client" organisation, and is the one for whom the application is being run. This organisation is also known as the "Functional Unit" and can be identified by adding the "Functional Unit" ROLE to the organisation's PARTY data. This data then provides the following:

The identity of the internal party in various transactions, such as sales orders and invoices.
The home currency for all such transactions.
The default CALENDAR for relevant transactions (which may be overridden for individual users).

It is possible for a GM-X installation to handle the business for a group of organisations which do business under their own name, possibly in different countries with different currencies and calendars. In this case the following needs to happen:

Each of those organisations should have "Functional Unit" added as a ROLE.
Each user should have their own entry on the PARTY table. The party_id should then be recorded on the user's record in the MNU_USER table.
An entry should be added to the PARTY_RELATIONSHIP table which identifies that person as an employee of one of these functional units.

When passing through the LOGON screen this information can then be made available to the application. If the user has not related to a Functional Unit then the following will happen:

The system will look for any party which has a role of Functional Unit.
If not found then the default party_id of 1 will be used.

NOTE: Entries on the PRICE_COMPONENT table which do not have a value for party_id_functional will be treated as Global prices and will be available to all organisations within the group, but if any prices exist for a Functional Unit then it is assumed that all prices will be defined for that Functional Unit, and the system will not fall back to the Global price.

If a GM-X instillation is handling multiple functional units which move inventory between themselves then please read FAQ35 which explains how the ownership of inventory items can be determined and how it can be changed.

If you have a Supplier Portal which allows an external party to access your system then you should do the following:

Add the supplier to the PARTY table as an organisation.
Add an entry to the PARTY ROLE table which identifies this organisation as a supplier.
Add the supplier's representative to the PARTY table as a person.
Add an entry to the PARTY_RELATIONSHIP table which links this person with his employer.

When the supplier's representative logs on his employer's organisation will automatically become his Functional Unit without the need to have that fact identified on the PARTY ROLE table.

21. Where are currency codes defined?

They are defined on the UNIT_OF_MEASURE table with a uom_cat_id which identifies them as currency codes. On the GM-X->Product->Setup->UOM menu is an option called "Currencies" which will active the "List Currencies" screen in order to list all the currency codes that are defined in your copy of the database. Here are some examples:

Category	Description	Abbreviation	Scale
CURR	UK Pounds	GBP	2
	US Dollars	USD	2
	Canadian Dollars	CAD	2
	Euros	EUR	2
	Australian Dollars	AUD	2
	Japanese Yen	JPY	0

The scale column identifies how many decimal places should be used when displaying amounts in that currency. In the above example this shows that Japanese Yen should always be shown as whole numbers such as 1000 instead of 1000.00.

22. Where are exchange rates defined?

They are defined on the UOM_CONVERSION table which identifies two currencies and the conversion_factor (exchange rate) which will allow values to be converted from one currency to another. When in the "List Currencies" screen (see FAQ#21) there is a navigation button called "Exchange Rates" which will show all the current rates from the selected currency to other currencies as well as the date on which each rate was set.

Once a rate has been set it will remain active until it is replaced with a different value with a later start_date. This will also cause the end_date of the current record to be updated to be set one day earlier, thus making that record "historic" instead of "current". Instead of having a single record with nothing but the current exchange rate, by having multiple records with different date ranges it is possible to keep a history of what rate was applicable on a particular date. Here are some examples:

FROM currency	TO currency	Conversion Factor
UK Pounds	US Dollars	2.04631
	Canadian Dollars	2.1521
	Euros	1.49183
	Australian Dollars	2.33514
	Japanese Yen	243.816

Note that if you wish to switch the FROM and the TO currencies then this will require a separate entry in the database. It is not general practice simply to take the rate for converting in one way and invert it for converting the other way.

23. How do I define my home/operating/functional currency?

Each GM-X installation should have at least one Functional Unit (see FAQ#20) defined on the ORGANISATION table. The currency code for this party then becomes the operating currency (also known as the home or functional currency) for all the financial transactions (sales orders, invoices, etc.)

For parties which are not Functional Units, such as customers or suppliers, the currency_code on their PARTY records identifies the currency in which they prefer to operate.

24. How do I deal with other currencies in certain documents?

While some organisations only ever operate in a single country and currency, some organisations conduct business with parties who operate in different countries and in different currencies. In this case it is necessary for each of the two parties to be able to view each transaction in their preferred currency as well as the other currency. The currency of the internal organisation is known as "home/functional" currency, while the currency of the other party is known as "foreign/transaction" currency.

Objects such as Orders, Invoices, Quotations and Expenses are documents which itemise financial dealings between two parties. These two parties are:

party_id_issuer - the party issuing the document, which is usually the Functional Unit.
party_id_receiver - the party receiving the document. In the case of a Sales Order/Invoice this is the Customer. In the case of a Purchase Order/Invoice this is the Supplier.

Note also that as well as documents being created on behalf of the Functional Unit which are then sent to external parties, it is also possible for documents to be created by external parties and received by the Functional Unit. It is possible for the external party to create the document directly in the organisation's system using a Supplier Portal, or to create the document in their system which is then sent to the receiving party over a blockchain.

In order to deal with this multi-currency requirement the GM-X database contains additional fields as well as the standard fields which hold values in the organisation's home currency. These fields are:

Field	Type	Description
currency_code	string	Links to an entry on the CURRENCY_CODE table. This identifies the transaction currency. This defaults to the operating/home currency of the receiving party, but may be changed by the user.
exchange_rate	numeric	Optional. The exchange rate which allows values to be converted from functional currency to transaction currency. This is only required if the two currencies are different.
	There may be one or more fields on a database table which hold financial amounts. Each of these has a version called <value> which holds the amount in home/functional currency, and another version called <value>_tx which holds the equivalent amount in foreign/transaction currency.
<value>	numeric	This holds a value which is expressed in home currency.
<value>_tx	numeric	This is the same as <value>, but expressed in transaction currency.

Note that the screens will only show one of these values at a time. A navigation button called "Switch Currency" will allow the display to be toggled between the two currencies. All input and update screens will only ever operate in transaction currency, in which case the input amount will be stored in <value>_tx, then multiplied by the inverse of exchange_rate before being stored in <value>.

25. How can I create a Purchase Order from a supplier's Quotation?

Having received a Quotation from a supplier and accepted it, either for all items or just a subset, there are two ways in which a Purchase Order (PO) can be sent to the supplier for those selected items:

On the Create PO Header screen near the top is a popup button with the label Create from Quotation. Press this button to see a list of Quotations which have been received from suppliers and which have an "Accepted" status. If you select one then the supplier's details will be automatically filled in from your selection. When you press the SUBMIT button a new PO will be created, then all the associated Quote Items with a status of "Accepted" will be copied across to the Order Item table. You may then amend, add or delete any of these items.
If you do not wish to copy the entire set of Quote Items into the PO then do not use the Choose Quotation popup. Instead when you are in the Add Order Item screen you can use the Choose Quote Item popup which will show you a list of all Quote Items with a status of "Accepted" from the chosen supplier. These may be items from a mixture of different Quotations.

26. How can I put certain stock into quarantine when receiving into inventory?

This only applies for products which are tracked by lot or serial number. It requires the following steps:

Create an entry on the INVENTORY_ITEM_STATUS table to indicate 'in quarantine' status.
Update the Inventory Controls record to specify this status. Without this the status cannot be set automatically.
When an ITEM_RECEIPT is created for a qualifying product then its status will automatically be set to 'in quarantine'.

Note that quarantined stock may be reserved, but cannot be issued.

27. When is an invoice sent to the customer in the sales order process?

An invoice can be generated from the sales order when either of the following tasks is executed:

When the sales order is approved by one of the following tasks:
- to Picklist, task = inv_picklist_dtl(upd5), will add add items to the PICKLIST_DTL table
- to Supplier, task = ord_purchase_order_build(add4), will add all items to the PURCHASE_ORDER_BUILD table.
- Approve Items, task = ord_order_item_s(multi2), will offer the choice, item by item, of picking from inventory (if available) or sending to a supplier.
When the shipment status is set to 'Awaiting Despatch', task = shp_shipment(upd1)sh2.

To signify which of these is required the string "create_invoice=TRUE" should be inserted into the SETTINGS field of the relevant task on the MENU database. This will cause the task acc_invoice_header(add4) (for orders) or acc_invoice_header(add1)so (for shipments) to be run automatically in the background. This will copy the details from the sales order into the Invoice database after which it will automatically run task acc_invoice_header(upd1)email.

Task acc_invoice_header(add4) will create an invoice from the sales order details, then set the order status to 'Invoice Created'.

Task acc_invoice_header(add1)so is the same as acc_invoice_header(add4), but with a confirmation screen.

Task acc_invoice_header(upd1)email will display a confirmation screen before sending the email to the customer. This will require that the customer has a suitable email address set up on the PARTY_CONTACT_MECHANISM table with a purpose of 'EMAIL_INV' (Invoice Email). If one is not found it will use the primary (or only) email address.

28. When is a PO sent to the supplier in the purchase order process?

A Purchase Order (PO) is sent to the supplier when the PO is approved. This is done on the "List Purchase Orders (To Be Approved)" screen by selecting a PO and pressing the "Approve - to Supplier" navigation button. This will create a PDF document and email to the supplier.

This requires a suitable email address entry being set up for the supplier on the PARTY_CONTACT_MECHANISM table with a purpose of 'ADDR-PO' (Purchase Order) which requires a linked entry on the CONTACT_MECH_PURPOSE_TYPE table. If one does not exist with that particular purpose it will look for a single entry of the 'EMAIL' type.

29. How can I signify which changes in order status are valid?

All possible status values for orders, whether for sales, purchases or transfers, are held on the ORDER_STATUS_TYPE table. Some of these may not be used in particular installations, so can be ignored, or even deleted.

Every order starts its life with a status of 'Pending' (PEND), and every subsequent change moves it from its current value to a new value. In order to signify that a particular change an entry needs to be added to the ORDER_STATUS_RULES table in order to signify which combinations of current/from and new/to values are allowed. Any change using a combination which is not identified on this table will therefore be rejected.

30. How can I send emails to the customer automatically when the order status changes?

All possible status values for orders, whether for sales, purchases or transfers, are held on the ORDER_STATUS_TYPE table. In order to send out an email whenever an order's status is changed to one of these values then you need to specify a value for template_id and is_email_auto.

The template_id will point to a record on the EMAIL_TEMPLATE table. The email_template field will specify the message that is to be sent out. This should contain the text of the message either in plain text or HTML format. It may also contain certain keywords enclosed in a pair of '#' characters which will identify values that will be obtained from the database at runtime, thus allowing the message to be personalised.

Note hat settings on the EMAIL_TEMPLATE table will allow the message to be sent again a specified number of times after a specified delay. The same message template can be used again, or it can be switched to a different message.

31. How do I access the system?

Nobody can log onto the system unless they first pass through the LOGON screen. This requires two values:

An entry on the MNU_USER table in the MENU database. The LOGON screen may ask for either a user_id or an email_address depending on how the system administrator has configured the system.
A valid password. This password may be held on the MNU_USER table, or it may be taken from an external source, such as a RADIUS or LDAP server, depending on how the system administrator has configured the system.

After logging on the user will be taken to the starting menu which is defined on the MNU_ROLE table. From this point on the user will only be allowed to access those parts of the system which have been granted to those MNU_ROLES to which the user has been associated.

If passwords are taken from the MNU_USER table the system administrator may have set up rules which require the password to be changed. If a change is triggered then this must be performed before the starting menu can be displayed.

32. How do I logon as a representative of an internal organisation?

Please see How do I access the system? for the basic rules.

If the application is only dealing with a single Functional Unit then party_id=1 will be used as the default value. Note that this is initially created with the name 'Client Organisation', so all its details will be to be changed to appropriate values.

If a value other than the default is required then that party should have an entry on the PARTY_ROLE_LINK table which links it to the 'Functional Unit' role.

If there is only one Functional Unit then no further action is required.

If there is more than one Functional Unit then the following steps will be required:

Each relevant Organisation should have an entry on the PARTY_ROLE_LINK table which links it to the 'Functional Unit' role.
The user should have an entry on the PERSON table, and this party_id should be inserted into the party_id field on the MNU_USER record so that the two entries can be linked.

These two parties should then have an entry on the PARTY_RELATIONSHIP table with the following values:

Field	Value
rel_type_id	'Employment'
rel_status_id	'Active'
rel_priority_id	(Not relevant)
rel_weighting_factor	(Not relevant)
start_date	The starting date for this entry.
end_date	The ending date for this entry.
party_id_1	The identity of the Organisation in this relationship
role_type_id_1	'Organisation Role'
role_subtype_id_1	'Employer'
party_id_2	The identity of the Person in this relationship
role_type_id_2	'Person Role'
role_subtype_id_2	'Employee'

Note that the order in which the details of the two parties is entered is not significant. The employee details could be entered as party#1 with the employer details as party#2.

During the logon process the following lookups will be performed:

Look for an entry on the PARTY_RELATIONSHIP table which links this user to a Functional Unit.
Look for the first organisation which has been identified as a Functional Unit.
If all else fails then use the default value party_id=1.

33. How do I logon as a representative of an external organisation? (Supplier Portal)

Please see How do I access the system? for the basic rules.

The user should only be linked to the 'Supplier' role as this will restrict access to only those functions which are allowed for a member of an external organisation.

The user should have an entry on the PERSON table, and this party_id should be inserted into the party_id field on the MNU_USER record so that the two entries can be linked.

The person's employer needs to have an entry on the ORGANISATION table and an entry on the PARTY_ROLE_LINK table which links it to the Supplier role.

The two parties - employer and employee - should have an entry on the PARTY_RELATIONSHIP table using the same values as shown in FAQ32.

34. How do I convert raw materials into a finished product?

This procedure, which is known as a "conversion", requires the following to be set up on the database:

The output product (there can be only one) must exist on the PRODUCT table with the subtype of 'G' (Good).
The input product(s) (there can be more than one) must exist on the PRODUCT table with the subtype of 'G' (Good).
The service/process which does the conversion must exist on the PRODUCT table with the subtype of 'S' (Service).
The output product must have a Bill Of Materials (BOM) established on the PRODUCT_COMPONENT table where it is defined as product_id_snr and the input product(s) and the service are defined as product_id_jnr. This provides a value for scrap.
The output product must have an entry on the PRODUCT_BOM_TYPE table. This provides a value for yield.

The task which performs this process has the following steps:

Identify the target (output) product which will be the result of this process.
Identify the purchase order line which contains the service item.
Identify the quantity of the target product which is to be produced.
Identify each input product and the quantity to be consumed.

When the SUBMIT button is pressed this task will create the necessary entries on the ITEM_RECEIPT table for the target/output product and ITEM_ISSUANCE table for each consumed/input product.

35. How is the ownership of inventory handled?

In the situation where a GM-X installation is handling multiple Functional Units which buy and sell inventory among themselves it is vitally important that the owner of that inventory can be easily identified and only be altered in the right circumstances.

For receiving into inventory the guiding principles which are followed in GM-X are s follows:

The party_id of a CONTAINER indicates the owner of the stock in the container - not the owner of the CONTAINER itself. For a CONTAINER to have an owner (or owners), it must be linked to an ASSET in the FINANCE-FA (Fixed Assets) subsystem by way of the is_container_id field of the ASSET table.
All the CONTAINERs belonging to a hierarchy must have the same party_id.
At receiving time, an INVENTORY_ITEM always receives the party_id of the CONTAINER into which it is placed.
The system determines which containers are eligible to receive the INVENTORY_ITEM (i.e. have the right party_id) based upon the business document related to the goods receipt. Business documents include Purchase Orders (POs), Transfer Orders, Sales Orders, Item Movements and Container Movements.
- Sales Orders result in stock being issued to the customer by way of a Customer Shipment. This may be followed by a Customer Return which may or may not have a Returned Material Authorisation (RMA).
- Purchase Orders result in stock being received from the supplier by way of a Supplier Shipment which may or may not have an Advance Shipment Notification (ASN). Faulty goods may be rejected and immediately returned to the supplier by means of a Supplier Return without having to be booked in and out of inventory.
- Transfer Orders result in stock being moved from one location to another for the same party. There is one outbound shipment with an issuance from the 1st location which is usually followed by an inbound shipment with a receipt at the 2nd location.
For Supplier Shipments a CONTAINER is eligible to receive an INVENTORY_ITEM when its party_id is the same as party_id_internal of the ORDER_HEADER for the related Purchase Order (i.e. the party which receives ownership of the stock).
For Customer Returns a CONTAINER is eligible to receive an INVENTORY_ITEM when its party_id is the same as party_id_internal of the ORDER_HEADER for the related Sales Order (i.e. the party to which the stock is returned).
For Transfer Shipments, a CONTAINER is eligible to receive an INVENTORY_ITEM when its party_id is the same as party_id_internal of the ORDER_HEADER (i.e. the party which receives ownership of the stock). Further, the party_id and party_id_internal of the ORDER_HEADER must be the same. In other words, the movement of stock via transfer order will never involve an ownership change (i.e. the organisation performing the transfer is the same as the organisation on whom the transfer order is raised). While the sending and receiving parties must be the same, the target address must be different from the source address.
For Item Movements, the CONTAINER which is eligible to receive an INVENTORY_ITEM is the container_id_to of the INVENTORY_ITEM_MOVEMENT. An ownership transfer will occur whenever the receiving CONTAINER's party_id is different from that of the container_id_from of the INVENTORY_ITEM_MOVEMENT.
- Note: CONTAINERs denoted by container_id_from and container_id_to of an INVENTORY_ITEM_MOVEMENT must always be at the bottom of any hierarchy. Per Rule #2, above, if the CONTAINER denoted by container_id_to of the INVENTORY_ITEM_MOVEMENT belongs to a hierarchy then all the CONTAINERs above it in the hierarchy will have the same party_id.
For Container Movements there is never any change in ownership.

If the CONTAINER being moved does not have a value for container_id_snr it can only be moved to another facility.
If the CONTAINER being moved does have a value for container_id_snr it can only be moved to another senior container of the same container_type_id and with the same party_id. This senior container may exist in either the same or a different facility.

Note that the Shipment Subsystem is used to transfer stock from one party/location to another as denoted by the party_id_sender and party_id_receiver on the SHIPMENT record. For outbound shipments the products are issued from the stock owned by the party_id_sender. For inbound shipments the products are received into stock owned by the party_id_receiver. For Transfer Orders the two parties are the same, but the sending address must be different from the receiving address.

For issuing from inventory the guiding principles which are followed in GM-X are as follows:

The system determines which INVENTORY_ITEMs are eligible for outbound shipping based upon the business document related to the goods issue. Business documents include Sales Orders, Transfer Orders, Item Movements and Container Movements.
For sales orders, an INVENTORY_ITEM is eligible for shipment when its party_id is the same as party_id_internal of the ORDER_HEADER (i.e. only the party which owns the stock can sell it; any other scenario constitutes theft).
For transfer orders, an INVENTORY_ITEM is eligible for shipment when its party_id is the same as party_id of the ORDER_HEADER (i.e. the party performing the transfer). Further, the party_id and party_id_internal of the ORDER_HEADER must be the same. In other words, the movement of stock via transfer order will never involve an ownership change (i.e. the organisation performing the transfer is the same as the organisation on whom the transfer order is raised).
For Item Movements, any INVENTORY_ITEM is eligible for movement. An ownership transfer will occur whenever the receiving CONTAINER's party_id is different from that of the container_id_from of the INVENTORY_ITEM_MOVEMENT.
For Container Movements, the party_id of the CONTAINER denoted by container_id_snr_from of the CONTAINER_MOVEMENT must be the same as the party_id denoted by the container_id_snr_to of the CONTAINER_MOVEMENT. In other words, CONTAINER_MOVEMENTs never involve an ownership change. After a container is moved its contents belong to the same PARTY as before.

36. How can I prevent key words from being deleted from the database?

In many places within the application there are dropdown lists or radio buttons where, instead of free-format text, the user can only choose a value from a list of options which is provided by the application. These values can be obtained from one of two places:

From a language_array.inc file in one of the text directories where there is a separate subdirectory for each supported language. This is where the list of options is fixed and cannot be amended by the user.
From a database table, which means that there are screens available to add or remove entries from that table.

Options provided in a language_array.inc file cannot be amended by the user, but those in a database table can. While some of these database values are completely under the control of the user and can be added or deleted when required, there may be some values which have special significance to the application and which should never be deleted. For example, on the ROLE_SUBTYPE table there are values such as "Customer", "Supplier" and "Functional Unit" which are required by several parts of the application. In order to prevent such values from being deleted a mechanism has been devised to interrupt the deletion process with an error message which says "This entry is reserved for use by the application and cannot be deleted".

In order to activate this mechanism all that is required is to create a file of restricted words and place it within the relevant subsystem directory. This file can exist with any one of the following names:

include.restricted_keywords.<project_code>.inc
project/<project_code>/include.restricted_keywords.inc
include.restricted_keywords.inc

This mechanism will search for the file in the above order and stop when the search is successul. Note that the first two versions allow different values to be supplied for different project codes while the last defines a single set of values which will apply to all project codes.

Here is the contents of an existing file as an example:

<?php

$array = array();

// this file identifies records on certain tables which should NOT be deleted.
// each entry in this array should identify the table and the primary key values.

// $array['<tablename>'][] = array('<column_id>' => 'value');

$array['party_identity_type'][]   = array('identity_type_id' => 'ALTERNATIVE');

$array['relationship_priority'][] = array('rel_priority_id'  => 'MED');

$array['relationship_status'][]   = array('rel_status_id'    => 'ACT');

$array['relationship_type'][]     = array('rel_type_id'      => 'CUSTOMER');
$array['relationship_type'][]     = array('rel_type_id'      => 'SUPPLIER');

$array['role_subtype'][]          = array('role_type_id'     => 'ORG',
                                          'role_subtype_id'  => 'FUNC');
$array['role_subtype'][]          = array('role_type_id'     => 'CUST',
                                          'role_subtype_id'  => 'CUSTOMER');
$array['role_subtype'][]          = array('role_type_id'     => 'SUPP',
                                          'role_subtype_id'  => 'SUPPLIER');

return $array;

?>

Note that this file should produce a variable called $array which is a multi-dimensional/multi-level array. The key at the first level identifies the table name within that subsystem, the key at the second level identifies the column name on that table, and the value identifies the value which should not be deleted.

37. How can I prevent clients from accessing unlicensed subsystems?

There may be circumstances where an installation being used by a client contains the files for some subsystems which have not actually been licensed by that client. Instead of removing the details of the unlicensed subsystems from the MENU database the alternative is to use a new configuration file whso name is in the format licensed.subsystems.<project>.inc where <project> is a unique identifier which is given to each cient organisation. An example of its contents is given below:

<?php

// this identifies the licensed subsystems
$licensed[] = 'menu';
$licensed[] = 'audit';
$licensed[] = 'workflow';

$licensed[] = 'order';
$licensed[] = 'party';
$licensed[] = 'product';

?>

This file is optional, which means that if it does not exist when the user logs on then nothing will happen. If it does exist then whenever a script is run and a table object is created the contents of the $parent_relations and $child_relations arrays will be scanned for entries which belong to subsystems which are not in that list and remove them. This will prevent any framework code from trying to access any unlicensed subsystems.

39. How do I define Payment Terms?

Payment terms are usually expressed as "Net X days" where X can be 30, 60 or 90 (or whatever the organisation chooses). This number of days is added to the invoice date in order to identify the date on which payment is due. If payment is not made by the date the organisation may charge interest on the amount due.

To apply payment terms automatically to each order/invoice please follow these steps:

All terms must have an entry on the TERM_TYPE table. This may contain a mixture of different terms, so those which are payment terms should have a term_type_id which begins with "NET-". As well as a textual description the number of days should be defined in the default_value column.
On the Order Control record it is possible to define a separte default payment terms for both sales and purchase orders.
It is also possible to add an entry to the PARTY_TERMS table in order to specify particular payment terms for an individual PARTY.

Whenever an order is created the following procedure will be performed:

A lookup will be performed on the ORDER_TERMS table for an entry with a term_type_id beginning with "NET-". If one is found the procedure will stop.
A lookup will be performed on the PARTY_TERMS table for an entry with a term_type_id beginning with "NET-". If one is found the details will be added to the ORDER_TERMS table and the procedure will stop.
A lookup will be performed on the PARTY_TERMS for an entry with the default_payment_terms as identified on the Order Control record. If this is not empty the details will be added to the ORDER_TERMS table and the procedure will stop.

For invoices the procedure will use the INVOICE_TERMS table.

Note that records on the ORDER_TERMS and INVOICE_TERMS tables can be added or deleted manually at any time.

For invoices this record will be used to calculate the due_date on the INVOICE_HEADER record. This value can be changed manually, but if emptied it will be recalculated using the INVOICE_TERMS record.

39. How do I define an Early Settlement Discount?

In order to encourage customers to pay their invoices early they may offer what is known as a Early Settlement Discount which allows the customer to deduct that discounted amount from the invoice amount provided that they settle within the specfied time limit. This then requires the following records on the database:

An entry on the ORDER_ADJUSTMENT_TYPE table to define the adjustment type. Example:
- order_adjustment_type_id = 'ESD-X-X'
- order_adjustment_type_desc = 'Early Settlement Discount, X%
- discount_or_surcharge = 'Discount'
- is_manual = 'Yes' (or 'No' if they should be added automatically)
An entry on the TERM_TYPE table to define all the different terms which may be available. Example:
- term_type_id = 'ESD-2-10'
- term_type_desc = 'Early Settlement Discount, 2%, 10 days'
- term_type_text = 'A discount of 2% to be applied if the invoice is settled within 10 days'
- is_value_required = 'Y'
- default_value = '10'
An entry on the PARTY_TERMS table to define which terms are available to which customer, and for discounts the time limit in days. Example:
- party_id = the party_id for the customer.
- term_type_id = the term_type_id from the TERM_TYPE table.
- value = the time limit in days.
An entry on the PRICE_COMPONENT table to define the discount as a percentage. Example:
- price_component_desc = 'Early Settlement Discount, 2%'
- order_adjustment_type_id = 'ESD-2-10'
- percent = '2.00'
- price_type = 'Early Payment Discount'
- frequency = 'One Time Charge'

Note that the values for term_type_id and order_adjustment_type_id must be the same so that they can be linked. It is suggested, though not required, that meaningful identities such as 'ESD-2-10' be used instead of random strings of letters and numbers.

Whenever a new order is created any entries on the PARTY_TERMS table for that customer will be copied to the ORDER_TERMS table. A lookup will then be performed on the PRICE_COMPONENT table for a matching entry, and if one is found it will be added to the ORDER_ADJUSTMENT table.

Note that the same processing will be performed whenever an invoice is created in order to add records to the INVOICE_TERMS and INVOICE_ADJUSTMENT tables.

While the value of the discount amount will be calculated it will NOT be deducted from the net order/invoice amount. It will only be applied when the invoice is settled with the specified time period.

Note that this design supports only the "gross method" accounting treatment for financial discounts, also known as "cash discounts" or "early payment discounts". Under the gross method, invoices, credit notes and debit notes which are open and outstanding are carried on the books at full face value until paid or settled, and financial discounts are recognised as business income only when customers take the financial discounts offered. Market research indicates that nearly all businesses use gross method instead of the "net method", under which open invoices, credit notes and debit notes are carried on the books at net value after the financial discount offered.

40. How do I define Withholding Tax?

Unlike a standard sales tax which is added to the invoice total and then paid by the payor to the payee, this amount is deducted from the invoice total by the payor and never received by the payee. The payee should then regard this amount as an expense.

This then requires the following records on the database:

An entry on the ORDER_ADJUSTMENT_TYPE table to define the adjustment type. Example:
- order_adjustment_type_id = 'WITHHOLDING-TAX'
- order_adjustment_type_desc = 'WithholdingTax'
- discount_or_surcharge = 'Discount'
- is_manual = 'Y' (these should not be added automatically)
An entry on the PRICE_COMPONENT table to define the discount as a percentage. Example:
- price_component_desc = 'WithholdingTax, 2%'
- order_adjustment_type_id = 'WITHHOLDING-TAX'
- percent = '2.00'
- price_type = 'Withholding Tax'
- frequency = 'One Time Charge'