Intercompany Processes

Registered by Eric Caudal - www.elico-corp.com

The scope of this document is to design a framework about inter-company processing for:
- Supply chain workflow (Sales and purchases) between companies in the same database
- Invoicing between companies linked with inter-company processes
- Stock picking between companies linked with intercompany processes

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

1.- Scope
1.1.- Scope
The scope of this document is to design a framework about inter-company processing for:
Supply chain workflow (Sales and purchases) between companies in the same database
Invoicing between companies linked with inter-company processes
Stock picking between companies linked with intercompany processes
1.2.- Selected Method (pull/push)
The setup should lead to a push of all objects or status between the companies

1.3.- Glossary:
SO: Sales Order
PO: Purchase Order
SM: Stock Move
SP: Stock Picking
DO: Delivery Order
IS: Incoming shipment
IC: Intercompany
IC Objects: Objects in OpenERP that are linked to another one by the Inter-company logic.

2.- showcases
Inter-company processes could be on side only (only one company pushes to another one) or crossed (2 companies could be Origin and Destination at the same time). In the later case, in principle it should not be on same object type (See “Avoiding loops in the inter-company process”).
2.1.- One side Inter-company organization (push is always coming from same side)
2.1.1.- Definition:
Company B is selling to Company A. Creating a SO in company B should automatically create a PO in Company A. In this case, Company B is called Origin and Company A is called Destination.
eg: Company B is a trading company in Hong-Kong selling equipment bought in Europe to Company A located in China.
2.1.2.- Process
1. In company B, a SO (To company A) is created in draft state.
2. In company A, a PO (From Company B) is created in draft state by IC process (PO is linked to SO Origin)
3. In company B, a SO (To company A) is saved (with whatever modification eg status)
4. In company A, a PO (From Company B) is changed (if “Locked”, delete and recreate ; if not “Locked” then ignore)
5. In Company B, the draft SO is manually confirmed
=> that creates (via standard procurement) a DO in Company B
6. In Company A, PO is automatically confirmed by IC process.
=> that creates (via standard procurement) an IS in Company A (IS is linked to DO by the IC process)
7. In Company B, the goods are shipped which processes the DO to Company A
=> if a backorder is created (usually in done state) the same backorder amount is created in Company A
8. In Company A, IS is automatically processed by the IC process (with quantities in DO from Company B)
=> a backorder is created based on Company B information.
9. In Company B, the Customer invoice is manually created
1. from SO
=> In company A, IC process creates a supplier invoice
(if SO in company B is linked to PO in company A, then the supplier invoice in company A should be linked to the PO in company A, and PO should be marked as invoiced)
2. from DO
=> In company A, IC process creates a supplier invoice
(if DO in company B is linked to IS in company A, then the supplier invoice in company A should be linked to the IS in company A, and IS should be marked as invoiced)
10. In Company B, the Customer invoice is saved
=> In company A, IC process change the linked supplier invoice (if “Locked” delete and recreate ; if not “Locked” then ignore)
11. In Company B, the customer invoice is validated
=> In company A, IC process validates the linked supplier invoice
2.2.- Crossed Inter-company Organization (push can come from both sides)
2.2.1.- Definition
Company A is buying from company B. Creating a PO in company A should automatically create a sales order in Company B. In this case, Company A is called Origin and Company B is called Destination.
eg: Company A is a trading company in Hong-Kong buying equipment from manufacturing Company B located in China.
2.2.2.- Process
1. In Company A, a PO (from Company B) is created in draft
2. In Company B, a SO (to Company A) is created in draft by IC process (SO is linked to PO)
3. In Company A, a PO (from Company B) is saved (with whatever modification eg status)
4. In Company B, a SO (to Company A) is changed ( if “Locked”, delete and recreate ; if not “Locked” then ignore)
5. In Company A, the draft PO is manually confirmed
=> that creates (via standard procurement) a IS in Company A
6. In Company B, SO is automatically confirmed by IC process.
=> that creates (via standard procurement) a DO in Company B (DO is linked to IS by the IC process)
7. In Company B, the goods are shipped which processes the DO to Company A
=> if a backorder is created (usually in done state) the same backorder amount is created in Company A
8. In Company A, IS is automatically processed by the IC process (with quantities in DO from Company B)
=> a backorder is created based on Company B information.
9. In Company A, the supplier invoice is manually created
1. From PO
=> In company B, IC process creates a customer invoice
(if PO in company A is linked to a SO in company B, then the customer invoice in company B should be linked to the SO, and SO should be marked as invoiced)
2. from DO
=> In company B, IC process creates a customer invoice
(if IS in company A is linked via IC to DO in company B, then the customer invoice in company B should be linked to the DO in company B, and DO should be marked as invoiced)
3. From scratch
=> In company B, IC process creates a customer invoice
10. In Company A, the supplier invoice is saved
=> In company B, IC process change the linked customer invoice (if “Locked” delete and recreate ; if not “Locked” then ignore)
11. In Company A, the supplier invoice is validated
=> In company B, IC process validates the linked customer invoice

2.2.- Crossed Inter-company Organization (Object created from one company is validated by the other)
2.2.1.- Definition
Company A is buying from company B. Creating a PO in company A should automatically create a sales order in Company B. Company B will validate the SO which will trigger a validation of PO in company A.
In this case, Company A is called Origin and Company B is called Destination.
eg: Company A is a trading company in Hong-Kong buying equipment from manufacturing Company B located in China.
2.2.2.- Process
1. In Company A, a PO (from Company B) is created in draft
2. In Company B, a SO (to Company A) is created in draft by IC process (SO is linked to PO)
3. In Company A, a PO (from Company B) is saved (with whatever modification eg status)
4. In Company B, a SO (to Company A) is changed ( if “Locked”, delete and recreate ; if not “Locked” then ignore)
5. In Company B, the draft SO is manually confirmed
=> that creates (via standard procurement) a DO in Company B
6. In Company A, PO is automatically confirmed by IC process.
=> that creates (via standard procurement) a IS in Company A (IS is linked to DO by the IC process)
7. In Company B, the goods are shipped which processes the DO to Company A
=> if a backorder is created (usually in done state) the same backorder amount is created in Company A
8. In Company A, IS is automatically processed by the IC process (with quantities in DO from Company B)
=> a backorder is created based on Company B information.
9. In Company A, the supplier invoice is manually created
1. From PO
=> In company B, IC process creates a customer invoice
(if PO in company A is linked to a SO in company B, then the customer invoice in company B should be linked to the SO, and SO should be marked as invoiced)
2. from DO
=> In company B, IC process creates a customer invoice
(if IS in company A is linked via IC to DO in company B, then the customer invoice in company B should be linked to the DO in company B, and DO should be marked as invoiced)
3. From scratch
=> In company B, IC process creates a customer invoice
10. In Company A, the supplier invoice is saved
=> In company B, IC process change the linked customer invoice (if “Locked” delete and recreate ; if not “Locked” then ignore)
11. In Company A, the supplier invoice is validated
=> In company B, IC process validates the linked customer invoice

2.3.- Control of the steps in show cases
Control should be checked at company level: eg to trigger one of the steps, the corresponding checkbox should be True in the Origin company setup
3.- Setup to be done at company level
IC can only be triggered when a partner linked to a company is used in SO/PO/SP. In this case the company where the document is generated is considered the Origin and the company linked to the partner is considered the Destination.
Set up to be done in the origin company (as we are in push method)
IC objects cannot be modified in the destination company.
3.1.- Sales Order Setup
Checkbox: Draft Sales Order creates draft PO
Checkbox: Confirm Sales Order Confirms PO
A list of status should link SO status of current company with PO status in Destination company
eg:
draft in SO => draft in PO
sent in SO => draft in PO
preorder => preorder (currently does not exist but could be introduced in Minimax)
etc.
3.2.- Purchase Order Setup
Checkbox: Draft PO creates draft Sales Order
Checkbox: Confirm PO Confirms Sales Order
A list of status should link PO status of current company with SO status in Destination company
eg:
draft => draft
sent => draft
preorder => preorder
etc.
3.3.- Invoicing setup
Checkbox: Draft Sales Invoice creates draft Supplier Invoice
Checkbox: Confirms Sales Invoice confirms Supplier Invoice
Checkbox: Draft Supplier Invoice creates draft Sales Invoice
Checkbox: Confirms Supplier Invoice Confirms Sales Invoice.
3.4.- Stock move setup
Checkbox: Draft Stock Picking creates draft Stock Picking
Checkbox: Process Stock Picking processes Stock Picking
4.- Setup in Objects
4.1.- Concepts
A link_id (in PO, SO, Invoice and stock picking) should be be created in the different objects which would indicate that this object is part of a inter-company process and to which object it is linked. Should be 2 fields (Origin + direction).
When a link is inserted in one destination object, the opposite link should be inserted in the origin object.
4.2.- Information in SO:
IC link: o2m to PO, read-only
IC direction: selection(from, to), indicates the direction from the above link (if from indicates that IC Link is the PO Origin for the given SO)
Lock for Multi-company Process: Checkbox (only IC Manager can edit it, default =False)
4.3.- Information in PO:
IC link: o2m to SO, read-only
IC direction: selection(from, to), indicates the direction from the above link (if from indicates that IC Link is the SO Origin for the given PO)
Lock for Multi-company Process: Checkbox (only IC Manager can edit it, default =False)
4.4.- Information in SP:
IC link: o2m to SP, read-only
IC direction: selection(from, to), indicates the direction from the above link (if from indicates that IC Link is the SP Origin for the given SP)
Lock for Multi-company Process: Checkbox (only IC Manager can edit it, default =False)
4.5.- Information in Invoice:
IC link: o2m to SP, read-only
IC direction: selection(from, to), indicates the direction from the above link (if from indicates that IC Link is the invoice Origin for the given invoice)
Lock for Multi-company Process: Checkbox (only IC Manager can edit it, default =False)
4.6.- Locations in Partners
Location setup in the partner linked should be a “transfer location” (not strictly necessary though)
5.- User rights, logging and maintenance
5.1.- Log
Create a log (create a group Intercompany in Message).
Any intercompany update/creation/deletion should generate a message.
Any message should contain the user, date/time, Origin Company, Destination Company, Origin object (type+id), Destination Object (type+id)
5.2.- ACL
Create a group IC manager (allow to see in both company and change the setup of the companies)
IC user (allow to operate with IC companies without ACL issues).
Other users: are not allowed to trigger Inter-company automatic creation
5.3.- Intercompany Menu.
In the following menu (1 to 6), the user should be able to see objects from both companies (to be decided how)
1. One menu Origin SO (linked to which Destination PO).
2. One menu Origin PO (linked to which Destination SO).
3. One menu Origin SP (linked to which Destination SP).
4. One menu Destination SP (linked to which Origin SP).
5. One menu Origin invoice (linked to which Destination invoice).
6. One menu Destination invoice (linked to which Origin invoice).
In all those menus there should be a button/wizard to unlink (=it empties the link in both objects).
7. One menu Exceptions (Unlinked)
An Unlinked is a IC object for which the corresponding object in the Destination company is not linked anymore (has been unlocked).
8. One menu Exceptions (Orphans)
An Orphan is a IC object for which the corresponding object in the Destination company is not existing anymore (has been unlocked and deleted).
9. One menu log (from messaging)
6.- Limitations:
6.1.- Loop control.
In order to avoid that an Origin bounce back in loop we need to implement a control. For this reason an inter-company process can never sent back to the sender (Destination company cannot be the same as the Origin of the IC)
6.2.- “Locked” Status
In the following object (SO/PO/SP/SI/CI) a check box “Lock for Multi-company Process”. It should be set to true whenever an object has been created directly from IC (eg PO from SO or SI from CI).
If “Lock for Multi-company Process” is True, it is not possible to edit the object.
A specific group “IC Manager” should be the only one been able to change this value (A warning should be issued that it is not possible to come back).
If “Lock for Multi-company Process” is False, it is not possible to edit the checkbox (it is only changed when a new object is created.
6.3.- Other limitations by design
Push flows/chained moves are not considered in the scope. Normal SP workflow should triggered them separately in both companies
Pull flows are not considered in the scope. Normal SP workflow should triggered them separately in both companies
Relation:
A PO can only be linked to one SO in Destination
A SP can only be linked to one SP in Destination
An invoice can only be linked to one invoice in Destination
There is no check for company setup consistency

TODO:
Check the needed domain for product validation between companies (avoid that a product exist in one but not in the other).

(?)

Work Items