GM-X ERP for Blockchain - The INVOICE subsystem

By Tony Marston

6th September 2007
Amended 22nd September 2022

Introduction

1. Invoices, Invoice Items and Item Features

2. Invoice Roles

3. Invoice Status

4. Invoice Terms

5. Invoice Adjustments

6. Initial Values

7. Invoice Extra Values

8. Invoice Item Extra Values

Amendment History

Introduction

Ensuring that payment occurs is critical for organisations. One items have been ordered, shipped, or delivered in some fashion, it is important for the enterprise to make sure that is requests payments, and this is often done through invoices. It is vitally important to send out correct invoices that correspond to the appropriate orders, shipments or work efforts. The enterprise needs to set up systems that facilitate getting paid, and this could involve setting up appropriate billing accounts; matching invoices to orders, billing for shipments, invoicing for work efforts; sending out invoices; tracking payments against invoices; recording deposits, and issuing statements.

If a charge on an invoice needs to be reversed, or the whole invoice needs to be cancelled, it is possible to create a Credit Note which the customer can offset against the next purchase.

It should be noted here that this invoicing system does nothing more than allow the organisation to create sales invoices, credit notes and debit notes, and send them to customers. Tracking payments and issuing statements is done in the GM-X Accounts Receivable subsystem. The creation of purchase invoices and making payments is done in the GM-X Accounts Payable subsystem.

An invoice is a commercial document issued by a seller to a buyer, relating to a sale transaction and indicating the products, quantities, and agreed prices for products or services the seller has provided to the buyer. While it is possible to create an invoice manually, it is usual practice to create an invoice from an order. It is possible to create several invoices for the same order if different components of the order are delivered on different dates and each delivery has its own invoice. Note that an invoice can only cover the components of a single order - it is not permissable to combine the components of several orders into a single invoice.

A credit note is used to cancel an invoice, either in whole or in part, when the seller agrees that the buyer need not pay those parts, due to a fault with or a non-delivery of those parts. While it is possible to create credit notes manually, it is usual practice to create a credit note from an invoice, then to remove any components not affected by the credit note. It is possible to create several credit notes for the same invoice if different components of the invoice are disputed at different times. Note that a credit note can only cover the components of a single invoice - it is not permissable to combine the components of several invoices into a single credit note.

A debit note is used to cancel a credit note, either in whole or in part, when the seller agrees that the buyer must now pay those parts. While it is possible to create debit notes manually, it is usual practice to create a debit note from an credit note, then to remove any components not affected by the debit note. It is possible to create several debit notes for the same credit note if different components of the credit note are disputed at different times. Note that a debit note can only cover the components of a single credit note - it is not permissable to combine the components of several credit notes into a single debit note.

Invoices, Invoice Items and Item Features

Invoices are usually created directly from sales orders. A function is available to do this automatically so that the order details do not have to be transposed manually. It is possible to amend the resulting invoice, such as to add in any delivery charges, and it is also possible to create an invoice from scratch without referencing a sales order.

Figure 1 - Invoices, Invoice Items and Item Features

INVOICE_HEADER table

This holds information about the invoice/credit note/debit note as a whole. The link to a related sales order is optional.

An invoice can either be created manually or generated from an existing sales order which will copy across all the items and adjustment details exactly. The rules for amending invoice details, and for creating invoices from scratch, are exactly the same as for creating and amending sales orders.

A Credit/Debit Note can either be created manually or generated from an existing invoice. The tax date of the Credit/Debit Note should be the same as the date of the Invoice to which it applies so that any values which are time sensitive can be taken from the correct time period. For example, if the tax rate changes after the invoice is created but before the credit note is produced it will be necessary to specify the invoice date on the credit note so that the rate of tax which is applied to the credit note is the same rate of tax which was applied to the invoice.

INVOICE_ITEM table

This holds information on individual items with an invoice. Each item specifies a product and a quantity, and may have related records on INVOICE_ITEM_FEATURE and INVOICE_ITEM_ADJUSTMENT.

INVOICE_ITEM_FEATURE table

A product may have any number of features, optional or otherwise, and some features may adjust the product price by applying either a surcharge or a discount.

INVOICE_ITEM_FEATURE_CUSTOMISATION table

This table holds all the customised values for a feature which has been selected for an invoice item. Some features within a feature category may be able to be customised, such as engraving options for jewellery will need the text which is to be engraved.

EMAIL_TEXT table

When an invoice or credit note is emailed to a customer it will be constructed as a PDF document and sent as an attachment. The email will, however, require some text as the subject line and message body, and this table allows that text to be customised for different installations.

Invoice Roles

As well as the bill_to and bill_from details which are held on the INVOICE_HEADER, there may be a need to identify other parties who may be involved with an invoice.

Figure 2 - Invoice Roles

INVOICE_ROLE_TYPE table

This identifies the types of role with which parties can be related to an invoice.

Here are some examples:

• Approver
• Entered by
• Receiver
• Sender

INVOICE_ROLE table

This identifies the roles that various parties have with an invoice.

Invoice Status

An invoice will be in different states at different points in time, and instead of just recording the current state it may be more useful to maintain a history of each change in state.

Figure 3 - Invoice Status

INVOICE_STATUS_TYPE table

This identifies all the possible states that an invoice may go through.

Here are the values used by the system which cannot be altered:

INVOICE_STATUS_HIST table

This keeps a history of all changes in status for an invoice. The entry with the highest sequence number is the latest.

Invoice Terms

The parties involved in an invoice may agree on many arrangements or terms, such as payment terms. Each order may have one or more terms which are categorised by TERM_TYPE.

Figure 4 - Invoice Terms

INVOICE_TERMS table

This identifies the terms which have been added to an invoice. Any entries which have been added to the PARTY_TERMS table for this party_id_bill_to (for sales invoices) or party_id_bill_from (for vendor invoices) will automatically be added to this table.

INVOICE_ITEM_TERMS table

This identifies the terms which have been added to an invoice item.

Invoice Adjustments

As well as the price of individual products an invoice may contain a variety of discounts or surcharges which affect its total value. Some of these adjustments may apply to individual items, such as quantity breaks, while others apply to the whole invoice, such as sales tax.

Figure 5 - Invoice Adjustments

INVOICE_ADJUSTMENT table

This identifies those adjustments (surcharges or discounts) which apply to an invoice as a whole.

When any part of an invoice is amended the contents of this table is scanned to determine if any adjustments need to be made. Any effect that an individual adjustment record has is indicated in that entry's details, and the sum of all adjustments will be shown in the INVOICE_HEADER details.

Here are some examples:

INVOICE_ITEM_ADJUSTMENT table

This identifies those adjustments (surcharges or discounts) which apply to an invoice item.

When any part of an invoice item is amended the contents of this table is scanned to determine if any adjustments need to be made. The sum of all adjustments will be shown in the INVOICE_ITEM details.

Here are some examples:

It should be noted that it is possible to have more than one item for the same product in the same invoice, perhaps with different features, so any quantity discounts have to operate on the total quantity for that product across all items within the invoice, and not just the quantity on the current item.

Initial Values

There may be cases where a transaction requires user input and a particular value or values remains constant for all instances of that transaction. In order to avoid having to manually input the same value(s) each time the transaction is run it is possible to define each of those values in the database and have those values automatically included in the user input. For maximum flexibility the following tables in the MENU database are used:

Here are some typical cases:

Invoice Extra Values

This database may be used by other systems, such as a web front end, which may have a requirement for extra fields to be held for each invoice. There is a NAMES table which holds the names of any such extra fields, with their validation types, and a VALUES table which holds a corresponding value for each invoice.

Although these values can be held in the database they cannot be considered when processing any business rules as their names and meanings are not part of the standard software. They can, however, be dealt with in any custom plugins.

Figure 6 - Invoice Extra Values

INVOICE_EXTRA_NAMES table

This identifies the names of extra fields which can be held for each invoice.

INVOICE_EXTRA_VALUES table

This holds the values for any extra fields for each invoice.

Invoice Item Extra Values

This database may be used by other systems, such as a web front end, which may have a requirement for extra fields to be held for each invoice item. There is a NAMES table which holds the names of any such extra fields, with their validation types, and a VALUES table which holds a corresponding value for each invoice item.

Although these values can be held in the database they cannot be considered when processing any business rules as their names and meanings are not part of the standard software. They can, however, be dealt with in any custom plugins.

Figure 7 - Invoice Item Extra Values

INVOICE_ITEM_EXTRA_NAMES table

This identifies the names of extra fields which can be held for each invoice item.

INVOICE_ITEM_EXTRA_VALUES table

This holds the values for any extra fields for each invoice item.

Date created: 6th September 2007

Amendment history:

Copyright © 1999-2022 by Geoprise Technologies Licensing, All Rights Reserved.