View source | View content page | Page history | Printable version   

Projects:Booking ControlFunctional Specification


Overview & Justification


The purpose of this document is to describe the Functional Specifications for an extension module to be developed in OB ERP version 2.50 called Booking Control.

This function is required by HIS and is item 5.5 on the WBS:


According to the HIS Project Development Backlog and Feature Requests published at, the feature HIS-20 ( is added to the functional scope of this module. Modifications due to this feature will be marked with a leading [HIS-20] string.


“Booking Control” supports an audit trail linking external documents to internal serial numbers.

This function is required in Germany, but is also generically useful in other countries.

New (dated on December 2010)

A dependence of the booking control sequence from the fiscal calendar (Year) is needed.

For every year in the fiscal calendar the sequence must start again.
As a result there could be more than one sequence in parallel for the same document type (one for the old year, one for the new year), because having different document types for different years is not an option.


2 invoices are booked in January 2009.

First invoice: Booking date is 02. January 2009 (=> booking period is Jan 2009). Booking control number is HIS-2009-1

Second invoice: Booking date is 30. December 2008 (=> booking period is Dec 2008). Booking control number is HIS-2008-120435

=> Booking control number must be setup with a prefix of "HIS-" + year + "-", depends on the fiscal year and starts new for every new fiscal year.

Finally, It is also required "Booking Control" functionality to be compatible with the new Advanced Payables & Receivables management functionality.


The booking control function provides the basis for proof of booking of a document.

A reference between the invoice document (on paper) and the invoice record (in the database) is generated then posting the invoice. => The reference number is part of the GL entry of the posted invoice.

In practice a serial is generated. The reference number is used to archive the invoice (on paper) and to find the related dataset in the ERP.

This reference number (or document number) is to be written on the invoice document (on paper). For this purpose the invoice gets a stamped.

This stamp contains fields for the account, the cost center etc. These fields are filled before booking by the accountant and the person responsible for data entry will use this information then booking. One additional field is the reference number, which is filled after posting the invoice. So the reference number must be shown on the screen as a result of a successful posting transaction.

New definitions and acronyms:

“Belegfunktion” - Booking Control

“Kontierungsstempel” – accounting postmark. Shall be refered to as Booking Control Stamp.

Design & Technical considerations

Design considerations:

Feature set must be developed and implemented as a separate or extended module.

While the initial scope of the feature is limited to the process described in this document, the design of the solution should allow to enhance it in future versions to support additional features like:

  1. Ability for the accountant to specify an account to use to post a document before the document is posted. In Openbravo the accounts are derived from the system configuration and the user does not have the ability to specify them on a transaction by transaction basis. The system derived posting rules should be followed. So when posting an purchase invoice an expense account should be prompted by the system. If the accountant has requested an unsupported transaction then the process should stop. Assuming the expense account is correct, the accountant may also choose to allocate / split the expense between two cost centres and the operator must be able to adjust the transaction line to split the cost according the the split shown on the booking control stamp. This cost allocation functionality will be subject to a separate requirements document and is not in scope for this current development..

Technical constraints:

See technical design document

Technical Requirements:

The internal control system of the accounting software must provide a validation function to show that the reference numbers of a financial period are gap-less for every accounting area.

It is possible that a gap will arise in the transaction numbering sequence because of a technical failure during posting or because a transaction has been deleted for some reason. These gaps must be reconcilable to a system log that shows the consumption of the original (unused) transaction number and recording either the technical failure or the deletion. In the situation where a transaction has been intentionally deleted then ideally the system should give a warning and require the user to select a reason code. However this functionality is part of the "Logging" requirements and will be managed by a separate requirements document.

Users & business process description

User goals:

The objective of Booking Control is to enable external documents to be stamped with certain information that allows the document to be matched to the transaction in the system.

The document booking control function must contain:

1. Sufficient explanation of the process,

2. Amount to be booked,

3. The timing of the process (posting period),

4. Confirmation of the transaction (Authorization) by the bookkeeper.

5. Unique reference number

User Roles and Personas:

Accountant:Stamps an external document (for example a Purchase Invoice) and indicates how that document should be booked.

Purchase Administrator: Entering Purchase Invoices into Openbravo using the information on the Booking Control stamp.

Auditor: Wishing to trace the transaction in Openbravo using the Booking Control Stamp on the Purchase Invoice

Business process diagram:

To be added.

Business scenario/s:

In brief, the process is as follows (using a purchase invoice as an example, same would apply to any other document which can be posted in the system).

a) Purchase invoice is received and stamped with the booking control stamp by the Purchasing Administrator.

b) The invoice is reviewed by the accountant who indicates the expense account that should be used and the split across cost centres.

c) The Purchasing Administrator enters the invoice. If the expense account proposed by the system is different from that proposed by the accountant then this must be resolved (manual action) before the document is posted.

d) The Purchasing Administrator allocates the expense across the required cost centers (currently out of scope. See 2.1 Design Considerations above).

e) The Purchasing Administrator posts the transaction and the system returns the reference number according to the sequences described in the requirements document).

f) The Purchasing Administrator writes (manual action) the reference number into the correct box on the booking control stamp on the original document

Functional requirements

Booking Control Process

Booking Control must include a "Booking Control Process" which must be linked to the corresponding Accounting Schema at the application path:
"Financial Management || Accounting || Setup || Accounting Schema || Accounting Schema >> Process "
Once the above it's done each booking of a document within that accounting schema will get a booking control document and therefore a booking control number which will be saved in the corresponding Booking Control tab, as described below in the section "Booking Control Tabs".

Booking Control Document

Booking Control must included a new Booking Control Document Type at the application path:
"Financial Management || Accounting || Setup || Document Type || Document Definition"

Booking Control document type must be linked to a Document Sequence named "Booking control sequence".

Booking Control Numbering & Sequence

Booking numbers must be generated by the system:

  1. every reference number (per year and per accounting area) is unique
  2. reference numbers starts new every financial year
  3. every accounting area can have its own reference numbers

Reference numbers starts new every financial year

There must be a "Periodicity" section in the below listed application path:
“Financial Management || Accounting || Setup || Document Sequence “ |- Sequence tab.

There will be a new (Yes/No) flag field named "Reset per Year". This field will have “No” as by default value, which means that the system will behave as nowadays.

In case the end-user set “Reset per Year” field as “Yes”, the “Advanced Booking Control Number per Fiscal Year” feature will work as described below for the “Booking Control Number Sequence”.

A new display logic will: (1) hide the existing field "Next Assigned Number"
(2) show a new field named "First assigned number for the Year"; which will be set up as "1" by default, but could be later on changed by the end-user.
(3) populate a new sub-tab named “Year Sequence” containing 2 columns as described below:

First column named = “Year”
Second column named = “Next Assigned Number”.

System will behave as described below and taking into account below setup:

(a) for the existing fields:

[YYYY] will be replaced with the "4-digits" year of the accounting date of the booking control document.

(b) for the “new” fields:

Documents having an accounting date of 2010 will have below booking control number:


Besides, the system will “automatically” update the new sub-tab “Sequences per Year” (in a trasparent way for the user). In our example:

Column "Year" = 2010
Column "Next assigned number" = 10003
Because the firts number for the year was "1000", 3 documents have been booked and the numbering increased by 1.

As an exception, in the case an end-user wants the booking control number to take as "First Assigned number for the Year" a diferent one that the one setup by default in the window "Financial Management || Accounting || Setup || Document Sequence “ |- Sequence tab - "First assigned number for the Year" field for a given year, he/she will have to manually create:

Every accounting area can have its own reference numbers

The range of reference numbers should be configurable for every accounting area. E.g.

000000 – 699999 University
700000 – 799999 BgA 1
800000 – 899999 BgA 2
900000 – 999999 all other

Or, also possible:

100000 – 999999 University
100000 – 999999 BgA 1
100000 – 999999 BgA 2
100000 – 999999 all other

University, BgA 1, BgA2, etc. are different accounting area.

Also the number of digits of the reference number should be configurable.

This configuration must be done following these steps:

for the organization you want to use a different sequence

Booking Control Tabs

There are many document types subject to booking/posting which must be impacted by the "Booking Control" functionality.
Above means that a new tab named "Booking Control" must be added to below documents/windows:

In the case of "Advanced Payables & Receivables" below documents/windows must also contain a Booking Control tab:

Once a purchase invoice is complete and post, the system will fill-in the corresponding information in the Booking Control Tab of the Purchase Invoice.
Information such as:

Same applies to rest of documents (Sales Invoice, GL Journals, etc).

Persona based scenarios

There must be a search function that then allows the detail of the accounting transaction to be returned to an Auditor .

When the auditor searches the invoice document (on paper) for an invoice document (on screen) or vice versa, he needs 3 keys:

=> a search function for reference numbers is needed at the application path:

"Financial Management || Accounting || Transactions || Booking Control || Header"

[HIS-20] Unique sequence per accounting unit

Booking control sequence number must be unique per accounting unit. An accounting unit is an aggregation of organizations, so that the booking control sequence number defined per org schema of an organization must be inherited from the relevant accounting unit.

The user must setup accounting units which will be all created at * level. When creating an accounting unit, the user must assign a code, a description and select the relevant booking control sequence. When configuring the org schema for an organization, the user must select an accounting unit and the application automatically retrieves the related booking control sequence.

Assumptions & Dependencies:


To be added.


To be added.

User interface

[HIS-20] New User Interface: Accounting Units


This window is accessed by navigating to General Setup || Enterprise || Accounting Units.

Name Type Length Default Constraint Mandatory
Code String Yes
Description String Yes
Booking Control Sequence Table List of Ad Sequence for Documents Yes

Accounting Units window does not display the Organization combo-box. When creating a new accounting unit, the application, behind the scenes, assigns the organization * to the new record.

[HIS-20] User interface changes: Org Schema tab in Organization window


The new field "Accounting Unit" is added to the Org Schema tab just above the "Booking control sequence" field. Specifications of this new field are in the following table.

Name Type Length Default Constraint Mandatory
Accounting Unit TableDir List of active Accounting Units Yes

Booking Control Sequence field is affected. It must be changed into a read-only field. An event is managed when the user selects the accounting unit. As soon as an accounting unit is selected, the application sets the booking control sequence according to the booking control sequence defined in the accounting unit being selected.


License code description

Openbravo Public License

Functionality enabled by the license code

Booking Control Function

Discussion items

Open discussion items:

Open items....

Closed discussion items:

To be added



Retrieved from ""

This page has been accessed 1,479 times. This page was last modified on 19 January 2018, at 10:11. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.