Intercompany Trading

When two companies of the same group both run on CifraHQ, one usually buys from the other. Without Intercompany Trading, the buyer keys a purchase order and the seller keys the same lines again as a sales order. With it, the seller's sales order is created for you the moment the buyer releases its purchase order, and it follows the buyer's changes until the seller releases it.

Each company keeps its own books. The seller prices the order with its own price lists, taxes and Bonus Rules. Nothing from the buyer's prices crosses over.

How it works

The buyer releases a purchase order whose vendor is linked to the seller company.
CifraHQ creates a Draft sales order in the seller company for the customer that represents the buyer. The lines, quantities, pack sizes, ship-to address and the buyer's PO number are copied. Prices come from the seller's rules.
Both sides can see the link: the purchase order shows a Synced badge with the seller's order number, and the sales order shows an Intercompany badge with the buyer's PO number.
Until the seller releases its sales order, changes on the buyer's PO flow through. Once the seller releases, the order is theirs and the buyer can no longer change it from its side.

**Sales staff on the seller side are notified** when an intercompany order arrives. Administrators on the buyer side are notified when a mirror fails or conflicts. Both notifications can be switched off in **Settings**.

Before you start

You need	Why
The tenant alias of each company	The alias is the first part of the company's CifraHQ address. For `https://acme.CifraHQ.cloud` the alias is `acme`. Each side is linked to the other by alias.
The same SKUs in both companies	Lines are matched by SKU. A SKU that exists in the buyer but not in the seller stops the mirror with a message naming the SKU.
A matching warehouse code	The seller's order uses the seller warehouse whose code equals the buyer's PO warehouse code, for example `101` on both sides. If there is no match, the seller's default intercompany warehouse is used.
An active Administrator with an API key in the seller	The mirror creates the seller's order as this service user, so the change history shows who created it. Most tenants already have one.
Administrator rights in both companies	Only administrators can set the fields below.

Step 1: set up the seller

Do this in the company that will receive the Sales Orders.

Go to Customers and open (or create) the customer record that represents the buyer company.
In the customer details, fill in Intercompany source tenant with the buyer's alias, for example acme. Save. Only one customer can represent a given tenant; CifraHQ refuses a second one.
Go to Settings and turn on Accept intercompany orders.
Optionally set Intercompany default warehouse code. It is used only when the buyer's PO warehouse code has no match in this company.

Step 2: set up the buyer

Do this in the company that will issue the Purchase Orders.

Go to Vendors and open (or create) the vendor record that represents the seller company.
In the vendor details, fill in Intercompany partner tenant with the seller's alias. Save.

CifraHQ checks the alias against the list of tenants when you save. A typo is rejected with the message No CifraHQ tenant with alias [...] exists.

Step 3: run a safe test

In the buyer, create a purchase order for the linked vendor with one line for a SKU that exists in both companies. Release it.
Refresh the purchase order after a few seconds. The header shows Mirroring to partner tenant while the job runs, then Synced with the seller's order number.
In the seller, go to Sales > Sales Orders. The new order is at the top as a Draft, carrying the Intercompany badge and the buyer's PO number in Customer PO.
Delete the test PO in the buyer while the seller's order is still a Draft. The seller's order is not deleted; it is put on hold with the reason Buyer PO deleted, so the seller decides what to do with it.

Day to day

When the buyer...	The seller's order...
Releases a PO	Is created as a Draft with the buyer's lines, ship-to and PO number.
Moves the PO back to Draft	Goes on hold. It can still be edited but cannot be released until the buyer releases again. The hold reason is shown on the order.
Changes lines and releases again	Is updated line by line: added lines appear, removed lines disappear, changed quantities follow. Lines the seller added by hand are kept. Bonus lines from the seller's own rules are recalculated.
Changes the ship-to and releases again	Gets the new ship-to address.
Deletes the PO while the seller's order is a Draft	Is put on hold with the reason Buyer PO deleted. It is never deleted for the seller.
Tries to delete the PO after the seller released	Is untouched. The delete is blocked in the buyer with Cannot delete PO [...]: partner [...] already released sales order [...]. Ask them to cancel it first.
Receives the goods	Nothing changes on the seller side in this version.

Once the seller releases its sales order, a further release of the buyer's PO no longer updates it. The purchase order shows Conflict and both sides are notified so they can agree the change by phone or email.

Statuses on the purchase order

Badge	Meaning
Mirroring to partner tenant	The job is queued or running. Normal for a few seconds after release.
Synced	The seller's order exists and matches the last release. The seller's order number is shown next to the badge.
Mirror to partner tenant failed	Something stopped the mirror. The full message is shown on the purchase order. Fix the cause and release the PO again.
Conflict	The seller already released its order and a later change on the PO was not applied.

A sweep runs every 30 minutes and retries any purchase order that is still pending or failed for a temporary reason, so a short outage on the seller side heals itself.

Troubleshooting

Message on the purchase order	Fix
Partner [...] has not enabled intercompany orders (Setup > Intercompany).	In the seller, turn on Accept intercompany orders in Settings, then release the PO again.
No customer in [...] declares this tenant (...) as its intercompany source.	In the seller, set Intercompany source tenant on the customer that represents the buyer.
More than one customer in [...] declares ... as its intercompany source.	In the seller, clear the field on all but one customer.
Partner [...] does not carry these SKUs: ...	Create the listed SKUs in the seller, or change the PO lines, then release again.
Partner [...] has no warehouse with code [...] and no intercompany default warehouse configured.	Create a seller warehouse with the same code, or set Intercompany default warehouse code in the seller's Settings.
Partner [...] has no active administrator API user to act as.	In the seller, make sure an Administrator user is active and has an API key.
Partner tenant [...] does not exist.	The alias on the vendor is wrong. Correct it and release again.
Sales order cannot be released: it is on intercompany hold	The buyer moved its PO back to Draft or deleted it. Ask the buyer to release again, or clear the hold by handling the order manually.

Rules and limits

The link is opt-in on both sides. A vendor alias without a matching customer alias and the seller setting does nothing except record a failure.
Prices, currency, Payment Terms and the Info1 to Info10 fields are never copied. The seller's own rules apply.
The seller's order is never deleted by the buyer. It is held, and the seller decides.
The buyer's PO cannot be deleted once the seller has released the matching sales order.
Receipts, deliveries and Invoices are not linked in this version. The seller ships and Invoices as usual; the buyer receives and books the vendor bill as usual.

**Shared warehouse.** When both companies use the same LogisticaHQ warehouse server, the buyer's PO becomes an inbound order for the buyer's warehouse client and the seller's order becomes a pick ticket for the seller's client. Goods are picked from the seller's stock and received into the buyer's stock as two separate documents.

Was this page helpful?

Previous Vendor Pre-Payments Next Sales Transactions