One sale, two documents: set up the pairing between your companies — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for you if you keep the books for two or more companies in the same group and one sells to another. In about eight minutes you will set things up so that a sale finalised in one company raises the matching purchase in the other, at once or on a confirmation, and you will check the first pair.

Step 1 — Decide what the pairing will and will not do

After this step you will know exactly what you are switching on. When GadgetSphere Distribution sells a pallet of accessories to GadgetSphere Sdn Bhd, the same event has to exist twice: a sale in the seller’s books and a purchase in the buyer’s, facing opposite ways and agreeing. BigLedger can raise the second document from the first when the first is finalised. But only when the sale carries a pairing, chosen on the invoice itself. Two of your companies trading with each other is not enough, and the job that does the pairing also has to be switched on for your tenant, which no screen shows. An invoice saved without a pairing is an ordinary sale, and nothing happens in the other company, with no message. So the set-up comes in order: the buyer as a customer with the right account, the branch that receives, the rule, and the choice on each sale.

Reference: Sales Invoice No Stock Out (Internal) — The intercompany flow

Step 2 — Bill the buying company through its own record

After this step the seller can bill the buyer in a way the pairing understands. Every company has an entity record of its own, usually created with the company and carrying its name. The customer on GadgetSphere Distribution’s invoice must be that record, GadgetSphere Sdn Bhd’s own, because the pairing works out the buying company from the company that owns the customer record. A separate customer somebody once typed for the same business will not do: the pairing fails with COMPANY_ENTITY_NOT_EXIST. So open GadgetSphere Sdn Bhd’s own record in the Entity applet and give it the customer role, which is what lets a sales invoice pick it. Do the same the other way round for every pair of companies that trade, so each company’s own record is ready before the first sale.

Reference: Entity Maintenance — Create — Main tab

Step 3 — Give each company the account it posts to

After this step each side lands in the right control account. A company’s own record starts with no receivable or payable type, the AR/AP type, so a document posted to it ends final with no journal. Give it the plain trade type, receivable or payable, as for any customer or supplier, so the sister company sits in your ordinary Debtor and Creditor Reports, where you agree the companies at month end. But one type cannot serve both ways: GadgetSphere Sdn Bhd is a customer in one company’s books and may be a supplier in another’s. The answer is a Company Linking row: one for the posting company, with a type on it, wins over the record’s own. So on GadgetSphere Sdn Bhd’s record, add a row for GadgetSphere Distribution set to trade receivable, and on GadgetSphere Distribution’s record a row for GadgetSphere Sdn Bhd set to trade payable. Without it, a payable-typed record puts the sale in the seller’s creditors.

Reference: Entity Maintenance — Edit — other tabs

Step 4 — Name the branch that receives

After this step the pairing knows which of the buyer’s branches gets the document. It looks for a branch, not just a company, and you set that up in two places. First, on GadgetSphere Sdn Bhd’s own record, open the Intercompany Branch tab and add a row for the branch that will receive, say GS-KV-01; the company fills in from the branch. Second, open GS-KV-01 in the Organisation applet and set its Default Entity Branch to that row. The pairing takes the branch whose Default Entity Branch is the one chosen on the invoice, and with none it fails with ENTITY_BRANCH_NOT_SET_AS_DEFAULT_FOR_ANY_BRANCH. One caution about stock: the document does not read the branch’s Main Location. With several locations linked, it takes one of them in the system’s own order, so a receiving branch with a single location is safest.

Reference: Organization — What it pairs with in practice

Step 5 — Write the rule on the selling branch

After this step the seller’s branch has a rule an invoice can choose. Open GadgetSphere Distribution’s selling branch in the Organisation applet, then its Intercompany Configuration tab. Add a row with a config code and name you will recognise on an invoice, one document pair, here Sales Invoice to Purchase Invoice, and a mode. AUTO creates the purchase invoice as soon as the sale is finalised. MANUAL leaves a row for someone to confirm. Either way, the new purchase invoice is a draft, unless you also tick Auto Final Target Doc, which finalises it at once. One row per selling branch per pair is enough, because the receiving branch is chosen on each sale. You can write rows at company level and copy them to every branch, but a branch’s own rows are what its invoices offer.

Reference: Organization — Company Intercompany Configuration and Engagement Access

Step 6 — Choose the pairing on each sale

After this step each intercompany sale carries its instruction. On the sales invoice, pick GadgetSphere Sdn Bhd’s own record as the customer. Then open the Account tab and its Intercompany sub-tab. It shows the branch and the customer, and the two selectors below them appear only when that customer has at least one intercompany branch. Choose the Intercompany Branch, GS-KV-01’s row, then the configuration, listed by its code and mode. Only rules written on this invoice’s own branch for sales invoices are offered. Now finalise as usual. The choice is saved on the invoice and is the only thing the pairing reads, so if you skip the sub-tab you have made an ordinary sale. Add the sub-tab to your checklist for every invoice to a group company.

Reference: Sales Invoice No Stock Out (Internal) — Account Tab

Step 7 — Check the first pair

After this step you will know the set-up works. Finalise the first invoice from GadgetSphere Distribution to GadgetSphere Sdn Bhd, say RM 20,000 of wireless audio. Then open the Purchase Invoice applet for GadgetSphere Sdn Bhd. With an AUTO rule, a new invoice should be there once the follow-on job has run, at GS-KV-01, with GadgetSphere Distribution’s own record as the supplier and a description that begins Auto Created From and ends with the seller’s invoice number. The Intercompany menu, which needs a permission to show, lists the pair under Processed. With a MANUAL rule, what you should find is a row under Unprocessed, and the invoice appears when you confirm it. If there is neither, either the sub-tab was skipped or the pairing job is not switched on for your tenant, which support can confirm. A pairing that failed also lands under Unprocessed, looking like a waiting row, which the next presentation explains.

Reference: Purchase Invoice (Internal) — Screens and menus

How the steps fit together

    flowchart TD
  s1["Step 1 — Decide what the pairing will and will not do"]
  s2["Step 2 — Bill the buying company through its own record"]
  s3["Step 3 — Give each company the account it posts to"]
  s4["Step 4 — Name the branch that receives"]
  s5["Step 5 — Write the rule on the selling branch"]
  s6["Step 6 — Choose the pairing on each sale"]
  s7["Step 7 — Check the first pair"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7
  

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

Next: The other company’s copy: what it carries, when it posts, and keeping both books in step · Back to the series · Play this as a presentation