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:
- Ability to create a matching purchase invoice for any sales invoice created for a business partner associated to an organization having a type marked as legal entity.
- Ability to drill from the purchase invoice to the sales invoice
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:
- Inter-company invoices initiated from purchase invoices.
- Inter-company orders initiated either from purchase orders or sales orders.
User roles & profiles
This specification applies to two roles:
- AR Staff: back office staff members that belong to the Finance function of the enterprise and that specialize in managing the receivables documents.
- AP Staff: back office staff members that belong to the Finance function of the enterprise and that specialize in managing the payables documents.
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.
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
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.
This can be achieved by adding an IS_INTERCOMPANY flag to the document type a new child table that, for inter-company documents, allow users to specify the matching inter-company document. For instance:
While in most case document types will be defined at * level, the application allows user to define them at lower organizations level. This designs allows for that.
Please notice that the above column 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.
See screen mock ups.
There should be two seeded default inter-company documents, defined at * organization level:
Please notice that these documents might need to be delivered by a separate module in order to be instantiated during the initial client setup if the user wants it.
Please also notice that the rationale for having IS_INTERCOMPANY set to N for Inter-company Purchase is that the current scope of this document only covers the flow that is initiated from the sales invoices.
|2.1||The following additional columns are created in the C_INVOICE table:
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.
|2.2||Whenever a sales invoice is saved the system should validate that if a document type having IS_INTERCOMPANY set to Y has been selected, the business partner is mapped to an organization.
If this validation fails an error should be raised.
|2.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:
|2.4||The above logic can complete in error in case one of the following conditions are met:
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.
|2.6||The Purchase Invoice window should be modified so that the ORIGINATING_INVOICE_ID filed is added as to the Header tab as a read-only field with the label "Originating Invoice"
This field is added as the last row before Status. See screen mock ups.
|3.1||The process of creating inter-company invoices should be developed in Java leveraging DAL if possible.||Nice to have|
|3.2||The invoice completion process should support modular extensions like the one required to support inter-company invoices||Should have|
Screen Mock ups
Document Type Window
The Document Type window is modified at header level to add the Inter-company check box as below.
Also a new tab is added to specify the matching inter-company documents.
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
- Should the inter-company invoice be created by a background process or by the Invoice Complete process?
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.
- Should we provide a way to search for inter-company invoices? Or should that be left as a configuration to be executed by the implementor?
Searching for inter-company invoices should be an implementation configuration since not many people would consider this a main selection criteria.
- Is the linking of inter-company invoices at header level enough? Should it be at invoice lines level? We assume that header level is appropriate since the two invoices must fully match and there cannot be discrepancies at line level.
Yes, it is enough.
- Should we restrict the functionality only for invoices across organizations of type legal entity or should it be open to any type of organization?
The funcitonality should work for any type of organizations, as long as they are mapped to a business partner.
- Are the parameters of the background process needed? Do they present technical difficulties?