Openbravo Forge End of Life Notice

Dear Openbravo Forge User,

Because of continued very low usage we decided to stop the following services on 31st of August 2017:

In case of question: webmaster "at"
View source | Discuss this page | Page history | Printable version    | Latest revision

Intercompanyinvoicing/Functional Specifications

m (Transactions)
Line 64: Line 64:

Revision as of 14:20, 6 July 2009


Inter-company Invoicing - Functional Specifications



The purpose of this document is to describe the functional specifications for an extension module, to be develop in top of Openbravo ERP 2.50, to support inter-company invoicing.


The module will provide the following functionality:

Design Considerations

While the initial scope of the module is limited to inter-company invoices created from sales invoices, the design of the solution should allow to enhance it in future versions to support additional flows and inter-company documents:



Functional Requirements

User roles & profiles

This specification applies to two roles:

Business process definition

The supported inter-company invoicing process is described in the picture below.


The AR Staff creates sales invoices and complete them as usual. During the completion process the system evaluate the invoice and, if it is of type inter-company, it creates the corresponding purchase invoice.

The AP Staff of the corresponding organization can review the automatically created purchase invoice and, if their privileges allow them to do so, can drill to the sales invoice.

User stories

Micro-toys Co. is an enterprise made of several subsidiaries. Each subsidiary is modeled in Openbravo as a legal entity. Micro-toys Holding is the parent company while Micro-toys Spain and Micro-toys France are two subsidiaries.

On June 28th, Maria – a member of the AR Staff of Micro-toys Holding – creates sales invoice having Micro-toys Spain as business partner.

When the invoice is complete, the system creates a corresponding purchase invoice in organization Micro-toys Spain, having Micro-toys Holding as business partner.

The purchase invoice has a link at header level to the sales invoice and when Javier – a member of the AP Staff of Micro-toys Spain – queries it, he can use this link to drill into the original AR invoice.

Functional requirements based on business processes

Num Requirement Importance
1.1 Users should be able to identify specific document types as being Inter-company documents. For those, they should be able to identify the type of the matching document in the target organization. Must have
Num Requirement Importance
1.1 The following additional columns are created in the C_INVOICE table:
  • ORIGINAL_INVOICE_ID VARCHAR(32) - this columns is populated only for inter-company purchase invoices and stores a foreign key to the original sales invoice that originated it.

Please notice that the above names are indicative only. The actual column names need to respect the modularity naming convention for columns added to a core table and need to embed the module prefix.

Must have
1.2 The IS_INTERCOMPANY flag should be derived from the business partner selection. In the Sales Invoice screen, when the business partner is selected, the IS_INTERCOMPANY flag should be derived depending on whether the business partner is tied to an organization. Must have
1.3 Whenever a sales invoice is completed, as part of the completion process, the system should validate whether the invoice is an inter-company invoice and if so, create the corresponding purchase invoice.

The logic of the process is as follows:

  • If IS_INTERCOMPANY equals 'Y':
    • Create the corresponding purchase invoice with the following characteristics:
        • Document type: AP Invoice
        • Document No: next value in the document sequence
        • Business Partner: the organization of the sales invoice
        • Partner Address, User/Contact, Price List, Form of Payment, Payment Terms: derived from the business partner.
        • All other attributes of both header and lines created as mirror of the original document
        • IS_INTERCOMPANY to 'Y'
        • ORIGINAL_INVOICE_ID is set to the ID of originating invoice
Must have
1.4 The above logic can complete in error in case one of the following conditions are met:
  • The selling organization is not associated to a business partner.
  • The period is closed in the purchasing organization.
  • Some reference data is invalid in the purchasing organization.

Under these circumstances, the purchasing inter-company invoice cannot be created. In this case, users should not be able to complete the original sales invoice and should be presented with an appropriate error message.

Must have
1.5 The Sales Invoice window should be modified so that the is IS_INTERCOMPANY flag is added to the Header tab as a checkbox with the label "Inter-company".<P>

This field is added as the last row before Status. See screen mock ups.

Should have
1.6 The Purchase Invoice window should be modified so that the is IS_INTERCOMPANY flag is added to the Header tab as a checkbox with the label "Inter-company".<P>

Also, the ORIGINATING_INVOICE_ID is added as to the Header tab as a read-only field with the label "Originating Invoice" These fields are added as the last row before Status. See screen mock ups.

Should have

Technical Requirements

Num Requirement Importance
1.1 The process of creating inter-company invoices should be developed in Java leveraging DAL if possible. Should have
1.2 The invoice completion process should support modular extensions like the one required to suppor inter-company invoices Must have

Screen Mock ups

Sales Invoice Window

The Sales Invoice window is modified to add the Inter-company check box as below.


Purchase Invoice Window

The Purchase Invoice window is modified to add the Inter-company check box and Originating Invoice field as below.


Open Discussion Items

Closed Discussion Items

We had originally opted for a separate background process that can be scheduled to run at regular intervals (every day, every hour, every minute) but we have reversed this decision and opted to go for an on line extension of the Invoice Complete process.

Searching for inter-company invoices should be an implementation configuration since not many people would consider this a main selection criteria.

Yes, it is enough.

The funcitonality should work for any type of organizations, as long as they are mapped to a business partner.

No longer a discussion item since the current functional design does not require background processes.