The following tutorial explains how to organise production, commerce and financial exchange across supply-chains.
It assumes you are familiar with the system or have completed the Modelling Bills of Materials tutorial. If you are using bitcoin, the procedure is the same as that for fiat currencies, except for the payment.
Note
For simplicity, the tutorial will give us only a single product to play with. To fully understand allocations and object mirroring you would need more than one product. The Power BI repository contains a T-SQL script that will create several additional products (albeit the same product in different colours) and a corresponding order book. This makes supply-chain operation more involved, but it generates a more realistic set of allocations against the supplier and customer. To install this dataset, download the network_data_extension.sql script and from SSMS run it against the tcTHEBUS database.
Switch immediately back to the three Network Interfaces. You should see transactions being written to The Business service as it deploys task contracts to the blockchain, with corresponding events emitted to the other two accounts. The Ganache accounts page will show a reduction in ETH and an increase in Tx count (around 120). Their transaction page records the contract deployments and calls.
Unless ordering takes place via a catalogue, most object codes differ between companies. The first task, therefore, is to mirror these codes and write them to the blockchain. Connect to the Plastic Provider and open Network Allocations. Unknown, new materials await mirroring so that they can be identified. These activities are called Allocation Codes. There are three options: Create a new activity; assign to an existing code; and map to a catalogue identity (when Mirrors? is checked). Assignment would be the norm, but here we need to create mirror activities. Once mirrored the allocation code is removed from this list.
Now that the consortium has been created and activities mirrored, order books can be exchanged over the network. However, it is not possible to mirror order books in many circumstances; instead, we employ the manufacturing systems solution of allocations. It is the set of all allocations that become mirrored by either party. To understand how that works practically, it is best to start with the Plastic Supplier.
Here are the defaults that load automatically when a new task is raised against an allocation. To avoid a shortfall, the quantity can be rounded up, but not down:
And here is the datasheet after the allocations have been satisfied:
On selecting Income, you will find there are no demand allocations that take the supply. Normally, the supplier would never send a sales order to the customer without first receiving instruction; but we are using the Tutorial Data to push supply. Therefore, the balance just keeps going up (5000 for M/00/70/00). Open the Network Allocations SvD for The Storage Box Company and the Schedule-On dates will be empty for the same reason. Mirror the assembly M/00/70/00 to a new activity SB-9653. Open Task Explorer and create 5 purchase orders for each of the months. Switch to the supplier, and filtering on the expense allocations will show they have been mirrored.
However, as customer, The Box Company is not interested in matching the supplier’s allocations, only ordering what it needs. The customer decides to double its order quantities (they can also change Action On as well to trigger a shift in delivery dates) . To do this, edit each sales order from their SvD listing. These order book changes are sent over the blockchain and the customer now presents the supplier with a new schedule where the projected balance is negative:
Everything is now in place: demand has cascaded down the supply chain, but nothing has in fact happened. We now need to roll up the production process - from the shipment of material, the manufacture of the goods, to the final delivery of the assembly. Then there is a second cascade down the supply-chain, in the form of money.
Before that, check out the transaction log on the network service:
The Tx hashes identify each transaction on the blockchain. Because we are using a local Ganache server, these are visible in its Transactions page, showing the From/To addresses you assigned during the installation:
In manufacturing, despatches are made on a delivery note raised by the Despatch Department and subsequently invoiced by Admin. The reason for this is that delivery notes were once signed with a pen by the customer’s Goods Inwards storeman, and the invoice was mailed to their Accounts Department. However, the Trade Control invoice doubles up as a despatch note; therefore, we need to raise invoices to despatch goods (or more generally, deliver a service).
For demonstration purposes, stop the Plastic Provider Network Interface Watch.
Connect to the Plastic Provider and from Network Allocations SvD (or Task Explorer), edit the first task for a plastic and deliver half the consignment by choosing Invoice. Add a miscellaneous charge for delivery (Sales - Carriage) and amend the Invoice Quantity of the task to half the total consignment. It will ask if you want to reconcile the task to the invoice: make sure you select No or there will be a quantity shortfall. Opening Network Invoices from the main menu, the invoice is awaiting deployment and transmission to the customer.
The SvD for the delivered plastic will still show that the allocations have not been satisfied. That is because the customer must mirror the sales invoice/despatch note with a corresponding purchase invoice/goods receipt note (GRN). When the delivery is accepted, the quantity is communicated over the network and the allocations updated accordingly.
Re-start the Plastic Provider Network Interface Watch and the sales invoice will be sent to THEBUS via the EVM. Connect to The Business and look at the SvD expenditure. It is now the inverted image of the supplier’s invoice. The invoice has been received but the customer’s allocations remain. Just as raising an invoice with a positive cash polarity constitutes a delivery, we need to mirror this to transact a receipt (GRN).
Open Network Invoices and you will be presented with the plastic supplier’s carriage charge. As with Activity Mirroring, you will need to mirror their income Charge Code to a corresponding Direct Expense.
Opening Definitions, you can amend and view all the Cash Code mirrors by using the + sign in the Cash Code page. All mirrors for any given business can also be edited in Organisation Maintenance. The mirror you created in the previous step will have been automatically sent over the network to the supplier, so that when you mirror their sales invoices the supplier does not need to repeat this process.
Now the invoice is both mapped to known allocations and cash codes, the supplier’s formal demand for payment can be processed. You must mirror their invoice so that it is signed off on the blockchain, the supplier is notified of your acceptance and the SvD allocations are adjusted. The Mirrors page should look something like this:
Check out the results - not just the allocations, but also the Invoice Register, Company Statement, Organisation Statements and so on.
Switch to The Business and open the first order. The materials are ready. Assuming everything else is in place too, with the tasks and operations complete, we can invoice/despatch the sales order. Select M/00/70/00 and invoice the full shipment to The Box Company (add carriage if you want).
If you Save/Refresh, although purchase orders must still be processed, the operations and works orders have been automatically completed.
As the goods have flowed up the supply chain, so we now go back down again, paying the invoices in exchange for their goods or service. If you are using a fiat currency, this process is controlled by the banks. Otherwise, you can pay directly from your Bitcoin Wallet.
From The Storage Box Company, look at the Company Statement. Open Payment Entry and pay the supplier (assuming an overdraft). You only need to select the organisation and post the defaults. The current balance of the Company Statement is reduced accordingly, and the invoices removed. A payment event is sent to the supplier notifying them that you have paid up, but their mirror invoice remains unpaid.
Switch to The Business. Check out the network allocations, invoice mirrors and events to see how they have been automatically updated over the network. Enter the customer’s payment to complete the process and a payment event will be sent out. The goods have been successfully delivered to the customer (quantity in, cash out), and in exchange, the money paid to the supplier (quantity out, cash in). Because both parties enter payments from their respective bank statements, the payment notification events automate confirmation that the money has been received.
Normally one of two things can go wrong in a trading exchange - faulty goods or bad service and mischarges. With Trade Control, you could just send an invoice with a negative quantity or charge, but it would go against convention. For faulty goods, the customer would send them back on a return note with an accompanying debit note. Should the supplier accept this, they would mirror it with a credit note. Internally, these states are modelled using polarity. Also, you can always raise invoices directly for miscellaneous charges with no supply/demand implications. For mischarges, you can also use zero quantities.
Delete/edit the invoice lines to debit 25Kg. Leave the defaulted carriage charge on the debit note to finance the return.
To obtain a quotation, you just raise a Pending Task against the supplier, who then mirror it with their cost. If you accept the cost, you amend the Unit/Total Charge and set the status to Open. It will then automatically transfer to the supply versus demand listings of both parties.
Although we have been manually tending to the allocations, this is at root a technique from the Material Requirements Planning algorithms developed in the manufacturing sector during the 1960s. Therefore, various techniques for automating this process could be applied to maintain positive SvD balances throughout the supply chain. Any change to the state would automatically flow down the demand side and then flow back up from the supply. Whilst the author has coded several finite and infinite scheduling algorithms, we are not going to automate at this time. But you can understand that the process you have covered in the tutorial is a practical implementation of supply-chain scheduling.
Furthermore, investigate the Network Interface transaction and event history generated by the three business nodes and trace to the Contract Calls and Deployments in the Ganache RPC Server. You can confirm how the information has been communicated over the EVM and immutably recorded in the contracts written to the blockchain. Therefore, switching to a public blockchain would mean any number of nodes can be connected and synchronised from anywhere in the world.
Trade Control Documentation by Trade Control Ltd is licenced under a Creative Commons Attribution-ShareAlike 4.0 International License
