View source | Discuss this page | Page history | Printable version    | Latest revision

Intercompanyinvoicing/Functional Specifications

(Open Discussion Items)
(Open Discussion Items)
 
(33 intermediate revisions not shown)
Line 29: Line 29:
====Business process definition====
====Business process definition====
-
The supported inter-company invoicing process is described in the picture below.
+
A sample inter-company invoicing process is described in the picture below.
[[Image:IntercompanyInvoicing.png]]
[[Image:IntercompanyInvoicing.png]]
-
The AR Staff creates sales invoices and complete them as usual. Meanwhile the system, through a background process, scans for newly completed invoices and, if they are related to a business partner associated to a legal entity, creates the corresponding purchase invoice.
+
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.
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.
 +
The above sample illustrate the process initiated from a sales invoice; other supported flows can be initiated from a purchase invoice, a sales order or a purchase order.
 +
 +
The complete list of supported flows is:
 +
* Inter-company sales invoice generates inter-company purchase invoice
 +
* Inter-company purchase invoice generates inter-company sales invoice
 +
* Inter-company sales order generates inter-company purchase order
 +
* Inter-company purchase order generates inter-company sales order
====User stories====
====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.
+
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, Italy and North America are subsidiaries; North America has two divisions, one for USA and one for Canada.
-
On June 28th, Maria – a member of the AR Staff of Micro-toys Holding – creates sales invoice having Micro-toys Spain as business partner.
+
[[Image:interco-example.png]]
-
When the invoice is complete, the system creates a corresponding purchase invoice in organization Micro-toys Spain, having Micro-toys Holding as business partner.
+
# 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.
-
 
+
# On June 29th, Javier creates a purchase order having Micro-toys Holding as business partner. When the order is complete, the system creates the corresponding sales order in Micro-toys Holding. That sales order generates a sales invoice but that sales invoice, although it has Micro-toys Spain as a business partner does not automatically generate a purchase invoice. The purchase invoice is generated from the purchase order instead.
-
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.
+
# On June 29th, Maria – a member of the AR Staff of Micro-toys Holding – creates sales invoice having Micro-toys Italy as business partner. According Micro-toys Co. policy, the corresponding purchase invoice in Italy needs to be created manually. Maria emails a copy of the document to Cecilia, a member of the AP Staff of Micro-toys Italy that enters the transaction manually.
 +
# On June 30th, Javier creates a sales invoice in Micro-toys Spain having Micro-toys North America as business partner. As by policy Micro-toys Co. does not allow subsidiaries to trade with each other, the system prevents this invoice from completing.
====Functional requirements based on business processes====
====Functional requirements based on business processes====
 +
 +
=====Configuration=====
{| border="1"
{| border="1"
Line 55: Line 65:
!Requirement
!Requirement
!Importance
!Importance
 +
!Status
|-
|-
|1.1
|1.1
 +
|
 +
Users should be able to identify specific document types as being inter-company documents. For those, they should be able to identify which source and target organizations allow inter-company trading and which ones, among them, trigger the creation of an automatic matching document in the target organization.
 +
 +
This can be achieved by adding an IS_INTERCOMPANY flag to the document type and a new child table that, for inter-company documents, allow users to specify the source and target organization pair and their corresponding matching inter-company document.
 +
 +
For instance:
 +
* when an inter-company sales invoice of type "Intercompany Sale" is created in organization A specifying organization B as business partner, the corresponding inter-company purchase invoice will have type "Intercompany Purchase B"
 +
* when an inter-company sales invoice of type "Intercompany Sale" is created in organization A specifying organization C as business partner, the corresponding inter-company purchase invoice will have type "Intercompany Purchase C"
 +
 +
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 both the definition of the main documents at * level and the specification of the source and target organization pairs at lower level and the definition of documents at lower level in the hierarchy.
 +
 +
For example, a valid configuration to meet the above user stories is:
 +
* "Intercompany Sale" and "Intercompany Purchase" defined at * organization
 +
* "Intercompany Sale" has the following child record:
 +
** Source:"Holding" - Target: "Spain" - Matching document: "Intercompany Purchase"; this configuration supports the first user story.
 +
** Source:"Holding" - Target: "France" - Matching document: null; this configuration supports the third user story.
 +
* "Intercompany Purchase" has the following child record:
 +
** Source:"Spain" - Target: "Holding" - Matching document: "Intercompany Sales"; this configuration supports the second user story.
 +
Please notice that the invoice from Spain to North America is not allowed as this is not an explicitly declared allowed pair.
 +
 +
An alternative valid configuration is:
 +
* "Intercompany Sale Holding" defined within the Holding organization
 +
* "Intercompany Purchase Spain" defined within the Spain organization
 +
* "Intercompany Sale Holding" has the following child record:
 +
** Source:"Holding" - Target: "Spain" - Matching document: "Intercompany Purchase Spain"; this configuration supports the first user story.
 +
** Source:"Holding" - Target: "France" - Matching document: null; this configuration supports the third user story.
 +
* "Intercompany Purchase Spain" has the following child record:
 +
** Source:"Spain" - Target: "Holding" - Matching document: "Intercompany Sales Holding"; this configuration supports the second user story.
 +
Please notice that the invoice from Spain to North America is not possible since there is not inter-company sales document declared within Spain.
 +
 +
 +
Please notice that the above column name is 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.
 +
|Must have
 +
|Planned
 +
 +
|-
 +
|1.2
 +
|
 +
There should be two seeded default inter-company documents, defined at * organization level:
 +
* Inter-company Purchase, for table C_INVOICE and having IsSOTrx set to N and IS_INTERCOMPANY set to N
 +
* Inter-company Sale, for table C_INVOICE and having IsSOTrx set to Y and IS_INTERCOMPANY set to Y. In addition, this document should identify Inter-company Purchase as the matching inter-company document.
 +
 +
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.
 +
|Should have
 +
|Out of scope
 +
 +
|}
 +
 +
=====Transactions - Invoices=====
 +
 +
 +
{| border="1"
 +
|-
 +
!Num
 +
!Requirement
 +
!Importance
 +
!In scope?
 +
 +
|-
 +
|2.1
|The following additional columns are created in the C_INVOICE table:
|The following additional columns are created in the C_INVOICE table:
-
* INTERCOMPANY_PROCESSED CHAR(1) NOT NULL DEFAULT 'N' – this column allows the inter-company invoice creation background process to identify invoices that need to be evaluated. Possible values are 'N' or 'Y'.
+
* ORIGINAL_INVOICE_ID    VARCHAR(32) - this columns is populated only for inter-company invoices and stores a foreign key to the original sales invoice that originated it.
-
* 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.
+
-
* IS_INTERCOMPANY        CHAR(1)    - flag that allows to identify inter-company invoices. This column is set the the inter-company invoice creation background process and contains NULL for records where INTERCOMPANY_PROCESSED is 'N' and either 'Y' or 'N' if INTERCOMPANY_PROCESSED is 'Y'.
+
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.
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
|Must have
 +
|Planned
|-
|-
-
|1.2
+
|2.2
-
|A new background process called “Create Inter-company Invoices” must be created. The purpose of this process is to scan the sales invoices in the current client and, if they are inter-company invoices, flag them as such and create the corresponding purchase invoice.<P>
+
|Whenever an 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.
-
The process accepts the following optional parameters:
+
 
-
* Organization: if specified, only invoices for this organization are considered.
+
If this validation fails an error should be raised.
-
* Date from: if specified, only invoices having invoice date later than or equal to the specified value are considered.
+
|Must have
-
* Date to: if specified, only invoices having invoiced date earlier than or equal to the specified value are considered.
+
|Planned
 +
 
 +
 
 +
|-
 +
|2.3
 +
|Whenever an 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 invoice when appropriate.<P>
The logic of the process is as follows:
The logic of the process is as follows:
-
* Select all sales invoices that match the criteria specified in the parameters and having INTERCOMPANY_PROCESSED equal to 'N'
+
* If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_INVOICE_ID is null AND business partner on the invoice is mappet to an organization AND the organization of the invoice and the organization of the business partner are a valid source and target AND there is a specific matching document type, THEN create the corresponding invoice in the target organization.
-
* For each of them, evaluate whether the business partner is a legal entity
+
* If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_INVOICE_ID is null AND business partner on the invoice is mappet to an organization AND the organization of the invoice and the organization of the business partner are NOT a valid source and target, THEN generate an error because inter-company is not allowed.
-
** If yes:
+
* In all other cases, proceed as usual.
-
*** Set IS_INTERCOMPANY to 'Y'
+
 
-
*** Create the corresponding purchase invoice with the following characteristics:
+
When creating the corresponding invoice, use the following characteristics:
-
**** Document type: AP Invoice
+
* Organization: the organization mapped to the business partner.
-
**** Document No: next value in the document sequence
+
* Document type: use the matching document type for the sales invoice in the organization mapped to the business partner.
-
**** Business Partner: the organization of the sales invoice
+
* Document No: next value in the document sequence
-
**** Partner Address, User/Contact, Price List, Form of Payment, Payment Terms: derived from the business partner.
+
* Business Partner: the organization of the sales invoice
-
**** All other attributes of both header and lines created as mirror of the original document
+
* Partner Address, User/Contact, Price List, Form of Payment, Payment Terms: derived from the business partner.
-
**** INTERCOMPANY_PROCESSED to 'Y'
+
* Header level warehouse: any warehouse associated to the organization
-
**** IS_INTERCOMPANY to 'Y'
+
* Line level warehouse: the default warehouse for the product; if that is not specified, any warehouse associated to the organization.
-
**** ORIGINAL_INVOICE_ID is set to the ID of originating invoice
+
* All other attributes of both header and lines created as mirror of the original document
-
** If no:
+
* ORIGINAL_INVOICE_ID is set to the ID of originating invoice
-
*** Set IS_INTERCOMPANY to 'N'
+
|Must have
-
* Set INTERCOMPANY_PROCESSED to 'Y'
+
|Planned
 +
 
 +
|-
 +
|2.4
 +
|In case the organization of the invoice and the organization of the business partner do not form a valid source and target combination for the original document type, the following error should be presented and the original document cannot be completed:
 +
* The business partner of this document has not been configured with a valid inter-company relationship with this organization using the current document type.
|Must have
|Must have
 +
|Planned
|-
|-
-
|1.3
+
|2.5
-
|The above process can complete in error in case one of the following conditions are met:
+
|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 selling organization is not associated to a business partner.
-
* The period is closed in the purchasing organization.
+
* The period is closed in the target organization.
* Some reference data is invalid in the purchasing organization.
* Some reference data is invalid in the purchasing organization.
-
Under these circumstances, the purchasing inter-company invoice cannot be created.
+
Under these circumstances, the inter-company invoice cannot be created.
-
The INTERCOMPANY_PROCESSED flag for the sales invoice must be left to N and an error message is output to the process log.<P>
+
In this case, users should not be able to complete the original sales invoice and should be presented with an appropriate error message.
-
The failure handling should be done on a transaction by transaction basis, meaning that if one sales invoice fails to create the corresponding purchasing invoice, others must succeed if they can.
+
|Must have
|Must have
 +
|Planned
|-
|-
-
|1.4
+
|2.6
-
|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>
+
|The Purchase Invoice window should be modified so that the ORIGINATING_DOCUMENT_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.
This field is added as the last row before Status. See screen mock ups.
|Should have
|Should have
 +
|Planned
|-
|-
-
|1.5
+
|2.7
-
|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>
+
|The Sales Invoice window should be modified so that the ORIGINATING_DOCUMENT_ID filed is added as to the Header tab as a read-only field with the label "Originating Invoice"
-
Also, the ORIGINATING_INVOICE_ID 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.
-
These fields are added as the last row before Status. See screen mock ups.
+
|Should have
|Should have
 +
|Planned
 +
 +
 +
|}
 +
 +
=====Transactions - Orders=====
 +
 +
{| border="1"
 +
|-
 +
!Num
 +
!Requirement
 +
!Importance
 +
!In scope?
 +
 +
|-
 +
|3.1
 +
|The following additional columns are created in the C_ORDER table:
 +
* ORIGINAL_ORDER_ID    VARCHAR(32) - this columns is populated only for inter-company orders 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
 +
|Planned
 +
 +
|-
 +
|3.2
 +
|Whenever an order 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.
 +
|Must have
 +
|Planned
 +
 +
 +
|-
 +
|3.3
 +
|Whenever an order is completed, as part of the completion process, the system should validate whether the order is an inter-company order and, if so, create the corresponding order when appropriate.<P>
 +
The logic of the process is as follows:
 +
* If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_ORDER_ID is null AND business partner on the order is mapped to an organization AND the organization of the order and the organization of the business partner are a valid source and target AND there is a specific matching document type, THEN create the corresponding order in the target organization.
 +
* If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_ORDER_ID is null AND business partner on the order is mapped to an organization AND the organization of the order and the organization of the business partner are NOT a valid source and target, THEN generate an error because inter-company is not allowed.
 +
* In all other cases, proceed as usual.
 +
 +
When creating the corresponding order, use the following characteristics:
 +
* Organization: the organization mapped to the business partner.
 +
* Document type: use the matching document type for the sales invoice in the organization mapped to the business partner.
 +
* 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.
 +
* Header level warehouse: any warehouse associated to the organization
 +
* Line level warehouse: the default warehouse for the product; if that is not specified, any warehouse associated to the organization.
 +
* All other attributes of both header and lines created as mirror of the original document
 +
* ORIGINAL_ORDER_ID is set to the ID of originating invoice
 +
|Must have
 +
|Planned
 +
 +
|-
 +
|3.4
 +
|In case the organization of the order and the organization of the business partner do not form a valid source and target combination for the original document type, the following error should be presented and the original document cannot be completed:
 +
* The business partner of this document has not been configured with a valid inter-company relationship with this organization using the current document type.
 +
|Must have
 +
|Planned
 +
 +
|-
 +
|3.5
 +
|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 target organization.
 +
* Some reference data is invalid in the purchasing organization.
 +
Under these circumstances, the inter-company order 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
 +
|Planned
 +
 +
|-
 +
|3.6
 +
|The Purchase Order window should be modified so that the ORIGINATING_DOCUMENT_ID filed is added as to the Header tab as a read-only field with the label "Originating Order"
 +
This field is added as the last row before Status. See screen mock ups.
 +
|Should have
 +
|Planned
 +
 +
|-
 +
|3.7
 +
|The Sales Order window should be modified so that the ORIGINATING_DOCUMENT_ID filed is added as to the Header tab as a read-only field with the label "Originating Order"
 +
This field is added as the last row before Status. See screen mock ups.
 +
|Should have
 +
|Planned
Line 125: Line 293:
!Requirement
!Requirement
!Importance
!Importance
 +
!Status
|-
|-
-
|1.1
+
|3.1
-
|The “Create Inter-company Invoices” process should be developed in Java leveraging DAL.
+
|The process of creating inter-company invoices should be developed in Java leveraging DAL if possible.
 +
|Nice to have
 +
|Out of scope
 +
 
 +
|-
 +
|3.2
 +
|The invoice completion process should support modular extensions like the one required to support inter-company invoices
|Should have
|Should have
 +
|Planned
|}
|}
Line 135: Line 311:
== Screen Mock ups ==
== Screen Mock ups ==
-
=== Sales Invoice Window ===
+
=== Document Type Window ===
-
The Sales Invoice window is modified to add the Inter-company check box as below.
+
The Document Type window is modified at header level to add the Inter-company check box as below.
-
[[Image:Intercompany-SalesInvoice.png]]
+
[[Image:DocumentType-Header.png]]
 +
 
 +
Also a new tab is added to specify the inter-company relations.
 +
 
 +
[[Image:DocumentType-MatchingInter-companyDocument.png]]
=== Purchase Invoice Window ===
=== Purchase Invoice Window ===
-
The Purchase Invoice window is modified to add the Inter-company check box and Originating Invoice field as below.
+
The Purchase Invoice window is modified to add the Originating Invoice field as below.
[[Image:Intercompany-PurchaseInvoice.png]]
[[Image:Intercompany-PurchaseInvoice.png]]
 +
 +
=== Sales Invoice Window ===
 +
 +
The Sales Invoice window is modified to add the Originating Invoice field as below.
 +
 +
[[Image:Intercompany-SalesInvoice.png]]
 +
 +
=== Purchase Order Window ===
 +
 +
The Purchase Order window is modified to add the Originating Order field as below.
 +
 +
[[Image:Intercompany-PurchaseOrder.png]]
 +
 +
=== Sales Invoice Window ===
 +
 +
The Sales Invoice window is modified to add the Originating Order field as below.
 +
 +
[[Image:Intercompany-SalesOrder.png]]
==Open Discussion Items==
==Open Discussion Items==
 +
 +
* In ''inter-company relations'' tab in ''document type'' window, in the ''target document type'' drop down list, only intercompany document types available for the target organization will be displayed.
 +
 +
* The only actions allowed for the documents are complete, unlock and close. None of the documents can be reactivated, neither the manual nor the generated.
 +
 +
* If the document is not generated, that is, if originating order/invoice field is black, the field will not be displayed.
 +
 +
* The currency of both pricelist of both business partners involved must be the same. Otherwise the following message will be displayed: ''The currency of the price list of the matching business partner must be the same as the one used in this document''.
 +
 +
==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?
* 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.
* 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?
* 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?
* Are the parameters of the background process needed? Do they present technical difficulties?
-
 
+
No longer a discussion item since the current functional design does not require background processes.
-
===Closed Discussion Items===
+
-
* Should the inter-company invoice be created by a background process or by the Invoice Complete process?<P>
+
-
We opted for a separate background process that can be scheduled to run at regular intervals (every day, every hour, every minute) as this appears to be the least invasive solution.
+

Latest revision as of 07:22, 4 August 2009

Contents

Inter-company Invoicing - Functional Specifications

Overview

Purpose

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.

Scope

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:

Constraints

None.

Functional Requirements

User roles & profiles

This specification applies to two roles:

Business process definition

A sample inter-company invoicing process is described in the picture below.

IntercompanyInvoicing.png

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.

The above sample illustrate the process initiated from a sales invoice; other supported flows can be initiated from a purchase invoice, a sales order or a purchase order.

The complete list of supported flows is:

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, Italy and North America are subsidiaries; North America has two divisions, one for USA and one for Canada.

Interco-example.png

  1. 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.
  2. On June 29th, Javier creates a purchase order having Micro-toys Holding as business partner. When the order is complete, the system creates the corresponding sales order in Micro-toys Holding. That sales order generates a sales invoice but that sales invoice, although it has Micro-toys Spain as a business partner does not automatically generate a purchase invoice. The purchase invoice is generated from the purchase order instead.
  3. On June 29th, Maria – a member of the AR Staff of Micro-toys Holding – creates sales invoice having Micro-toys Italy as business partner. According Micro-toys Co. policy, the corresponding purchase invoice in Italy needs to be created manually. Maria emails a copy of the document to Cecilia, a member of the AP Staff of Micro-toys Italy that enters the transaction manually.
  4. On June 30th, Javier creates a sales invoice in Micro-toys Spain having Micro-toys North America as business partner. As by policy Micro-toys Co. does not allow subsidiaries to trade with each other, the system prevents this invoice from completing.

Functional requirements based on business processes

Configuration
Num Requirement Importance Status
1.1

Users should be able to identify specific document types as being inter-company documents. For those, they should be able to identify which source and target organizations allow inter-company trading and which ones, among them, trigger the creation of an automatic matching document in the target organization.

This can be achieved by adding an IS_INTERCOMPANY flag to the document type and a new child table that, for inter-company documents, allow users to specify the source and target organization pair and their corresponding matching inter-company document.

For instance:

  • when an inter-company sales invoice of type "Intercompany Sale" is created in organization A specifying organization B as business partner, the corresponding inter-company purchase invoice will have type "Intercompany Purchase B"
  • when an inter-company sales invoice of type "Intercompany Sale" is created in organization A specifying organization C as business partner, the corresponding inter-company purchase invoice will have type "Intercompany Purchase C"

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 both the definition of the main documents at * level and the specification of the source and target organization pairs at lower level and the definition of documents at lower level in the hierarchy.

For example, a valid configuration to meet the above user stories is:

  • "Intercompany Sale" and "Intercompany Purchase" defined at * organization
  • "Intercompany Sale" has the following child record:
    • Source:"Holding" - Target: "Spain" - Matching document: "Intercompany Purchase"; this configuration supports the first user story.
    • Source:"Holding" - Target: "France" - Matching document: null; this configuration supports the third user story.
  • "Intercompany Purchase" has the following child record:
    • Source:"Spain" - Target: "Holding" - Matching document: "Intercompany Sales"; this configuration supports the second user story.

Please notice that the invoice from Spain to North America is not allowed as this is not an explicitly declared allowed pair.

An alternative valid configuration is:

  • "Intercompany Sale Holding" defined within the Holding organization
  • "Intercompany Purchase Spain" defined within the Spain organization
  • "Intercompany Sale Holding" has the following child record:
    • Source:"Holding" - Target: "Spain" - Matching document: "Intercompany Purchase Spain"; this configuration supports the first user story.
    • Source:"Holding" - Target: "France" - Matching document: null; this configuration supports the third user story.
  • "Intercompany Purchase Spain" has the following child record:
    • Source:"Spain" - Target: "Holding" - Matching document: "Intercompany Sales Holding"; this configuration supports the second user story.

Please notice that the invoice from Spain to North America is not possible since there is not inter-company sales document declared within Spain.


Please notice that the above column name is 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.

Must have Planned
1.2

There should be two seeded default inter-company documents, defined at * organization level:

  • Inter-company Purchase, for table C_INVOICE and having IsSOTrx set to N and IS_INTERCOMPANY set to N
  • Inter-company Sale, for table C_INVOICE and having IsSOTrx set to Y and IS_INTERCOMPANY set to Y. In addition, this document should identify Inter-company Purchase as the matching inter-company document.

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.

Should have Out of scope
Transactions - Invoices
Num Requirement Importance In scope?
2.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 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 Planned
2.2 Whenever an 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.

Must have Planned


2.3 Whenever an 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 invoice when appropriate.

The logic of the process is as follows:

  • If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_INVOICE_ID is null AND business partner on the invoice is mappet to an organization AND the organization of the invoice and the organization of the business partner are a valid source and target AND there is a specific matching document type, THEN create the corresponding invoice in the target organization.
  • If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_INVOICE_ID is null AND business partner on the invoice is mappet to an organization AND the organization of the invoice and the organization of the business partner are NOT a valid source and target, THEN generate an error because inter-company is not allowed.
  • In all other cases, proceed as usual.

When creating the corresponding invoice, use the following characteristics:

  • Organization: the organization mapped to the business partner.
  • Document type: use the matching document type for the sales invoice in the organization mapped to the business partner.
  • 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.
  • Header level warehouse: any warehouse associated to the organization
  • Line level warehouse: the default warehouse for the product; if that is not specified, any warehouse associated to the organization.
  • All other attributes of both header and lines created as mirror of the original document
  • ORIGINAL_INVOICE_ID is set to the ID of originating invoice
Must have Planned
2.4 In case the organization of the invoice and the organization of the business partner do not form a valid source and target combination for the original document type, the following error should be presented and the original document cannot be completed:
  • The business partner of this document has not been configured with a valid inter-company relationship with this organization using the current document type.
Must have Planned
2.5 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 target organization.
  • Some reference data is invalid in the purchasing organization.

Under these circumstances, the 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 Planned
2.6 The Purchase Invoice window should be modified so that the ORIGINATING_DOCUMENT_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.

Should have Planned
2.7 The Sales Invoice window should be modified so that the ORIGINATING_DOCUMENT_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.

Should have Planned


Transactions - Orders
Num Requirement Importance In scope?
3.1 The following additional columns are created in the C_ORDER table:
  • ORIGINAL_ORDER_ID VARCHAR(32) - this columns is populated only for inter-company orders 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 Planned
3.2 Whenever an order 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.

Must have Planned


3.3 Whenever an order is completed, as part of the completion process, the system should validate whether the order is an inter-company order and, if so, create the corresponding order when appropriate.<P>

The logic of the process is as follows:

  • If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_ORDER_ID is null AND business partner on the order is mapped to an organization AND the organization of the order and the organization of the business partner are a valid source and target AND there is a specific matching document type, THEN create the corresponding order in the target organization.
  • If the document type has IS_INTERCOMPANY set to 'Y' AND ORIGINAL_ORDER_ID is null AND business partner on the order is mapped to an organization AND the organization of the order and the organization of the business partner are NOT a valid source and target, THEN generate an error because inter-company is not allowed.
  • In all other cases, proceed as usual.

When creating the corresponding order, use the following characteristics:

  • Organization: the organization mapped to the business partner.
  • Document type: use the matching document type for the sales invoice in the organization mapped to the business partner.
  • 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.
  • Header level warehouse: any warehouse associated to the organization
  • Line level warehouse: the default warehouse for the product; if that is not specified, any warehouse associated to the organization.
  • All other attributes of both header and lines created as mirror of the original document
  • ORIGINAL_ORDER_ID is set to the ID of originating invoice
Must have Planned
3.4 In case the organization of the order and the organization of the business partner do not form a valid source and target combination for the original document type, the following error should be presented and the original document cannot be completed:
  • The business partner of this document has not been configured with a valid inter-company relationship with this organization using the current document type.
Must have Planned
3.5 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 target organization.
  • Some reference data is invalid in the purchasing organization.

Under these circumstances, the inter-company order 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 Planned
3.6 The Purchase Order window should be modified so that the ORIGINATING_DOCUMENT_ID filed is added as to the Header tab as a read-only field with the label "Originating Order"

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

Should have Planned
3.7 The Sales Order window should be modified so that the ORIGINATING_DOCUMENT_ID filed is added as to the Header tab as a read-only field with the label "Originating Order"

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

Should have Planned


Technical Requirements

Num Requirement Importance Status
3.1 The process of creating inter-company invoices should be developed in Java leveraging DAL if possible. Nice to have Out of scope
3.2 The invoice completion process should support modular extensions like the one required to support inter-company invoices Should have Planned

Screen Mock ups

Document Type Window

The Document Type window is modified at header level to add the Inter-company check box as below.

DocumentType-Header.png

Also a new tab is added to specify the inter-company relations.

DocumentType-MatchingInter-companyDocument.png

Purchase Invoice Window

The Purchase Invoice window is modified to add the Originating Invoice field as below.

Intercompany-PurchaseInvoice.png

Sales Invoice Window

The Sales Invoice window is modified to add the Originating Invoice field as below.

Intercompany-SalesInvoice.png

Purchase Order Window

The Purchase Order window is modified to add the Originating Order field as below.

Intercompany-PurchaseOrder.png

Sales Invoice Window

The Sales Invoice window is modified to add the Originating Order field as below.

Intercompany-SalesOrder.png

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.