CommLinc User Guide
Table of Contents
- Table of Contents
- Contracts
- Contract List
- Contract Card
- Contract Schedules
- Futures Trading
- Load Instructions
- Loads
- API Integration
- Reports
Contracts
Contracts, along with Loads, form the basis of CommLinc from which all transactions are initiated. Contracts define the specifics of an agreement between a trading company and a counterparty. In broad terms, a commodity contract specifies what is referred to as the 5 P's and 2 Q's of commodity trading.
- P1: Product — Represented by an Item in CommLinc.
- P2: Price — The price per unit of measure as well as the pricing mechanism.
- P3: Place — The location where the product will be delivered.
- P4: Period — The period during which delivery is to be executed.
- P5: Payment Term — The terms on which payment will or must be made after delivery.
- Q1: Quantity — The quantity to be delivered during the execution of the contract.
- Q2: Quality — The quality of the commodity to be delivered.
Contract List
The Contract List page gives the user a bird's-eye view of the contracts in the system. Each contract can have one or more Contract Schedules related to it. The Load Allocation grid displays the loads allocated to each contract schedule. Filtering on the various fields on the contract table allows the user to limit the displayed contracts to only what is specifically required.
The Contracts List page's primary grid includes summary metrics per contract such as Estimated Quantity, Delivered Quantity, Hedged Quantity and Invoiced Quantity. These fields are calculated by summing the relevant quantities in the related Contract Schedule and Load Allocation tables.
Contract Schedules define the variant or grade, stock-keeping location, season, variant adjustment table, attribute value adjustment table, default futures delivery month, delivery period, and the quantity and adjusted quantity of the schedule. Unit Price is editable depending on whether the contract type has Allow Price Override set to true.
Basis, spread, estimate quantity, delivered quantity, hedged quantity and invoiced quantity are calculated from the related records as allocated through their respective allocation functions. Shipment method, transport method, transport budget and gross weight make up the metrics related to logistics. The final fields are the standard Business Central dimension codes.
Contract Card
The CommLinc Contract Card is the interface through which the P's and Q's with their related details are captured. Once created, a contract must be released before Loads can be allocated to it. From the header section of the card the user can request approval, print, attach a PDF copy to the contract record, or email a contract.
Document attachments (the standard BC paperclip) are supported on Contracts, Contract Schedules, Loads, and Futures Trades.
Creating a new contract: When a new contract is opened from the Contract List, the system first prompts the user to select Purchase Contract or Sale Contract before any fields are shown. The Transaction Type cannot be changed after this selection.
Schedule subpage prerequisites: The Contract Schedules subpage is only enabled for editing once all four of these header fields are populated: Counterparty No., Item, Transport Method, and Shipment Method. Until all four are set, the schedule grid is visible but locked.
The Contract Card has eight expandable functional areas for maintaining the contract, each of which is discussed below.
Contract Lifecycle
A contract progresses through the following statuses:
| Status | Description |
|---|---|
| Open | The contract is editable. Loads cannot be allocated until the contract is Released. |
| Pending Approval | A workflow approval request has been submitted. The contract is locked for editing. |
| Rejected | The workflow approval was rejected. The contract returns to Open for correction. |
| Approved | The contract has been released and is available for load allocation and invoicing. |
| Closed | All schedules have been fully delivered and invoiced. Set automatically by the system when every schedule reaches Closed status. |
| Cancelled | The contract has been cancelled. Only permitted if no schedules exist on the contract. |
Releasing a Contract
A contract is released either manually using the Release action, or through the approval workflow. Before a contract can be released, all of the following fields must be populated:
- Counterparty No.
- Item No.
- Transport Method
- Shipment Method
- Payment Terms Code
- Default Weight Liability Transfer
- Default Grade Liability Transfer
If any of these fields are blank the release action is blocked with an error message.
Approval Workflow
If the approval workflow is configured for contracts, the Request Approval action is used instead of Release. Two prerequisites must be met before a request can be submitted:
- An active workflow based on the Approve Contract Workflow — CommLinc template must exist and be enabled in Business Central.
- The contract must be in Open status.
If either condition is not met the action is blocked with an informative error.
Once submitted the contract moves to Pending Approval and is locked. Approval outcome transitions are automatic:
| Approver action | Resulting contract status |
|---|---|
| Approves (all approvers done) | Approved |
| Rejects | Rejected |
| User cancels request | Open |
The workflow also supports standard BC approver delegation — an approver may delegate the request to another user without rejecting it.
Reopening a Contract
An Approved contract can be manually reopened to Open status using the Reopen action. Reopening allows header fields to be edited while preserving all existing schedule allocations.
Deleting a Contract
A contract can only be deleted when all of the following conditions are met:
- Contract Status is Open.
- No load allocations exist against any schedule.
- No futures trade pricing records exist against any schedule.
- No spread allocations exist against any schedule.
Contract - Counterparty
Counterparty specifies with whom the contract is concluded. In the case of a Purchase Contract it will be a standard Business Central Vendor while for Sales Contract it is a Customer.
Counterparty No.: Specifies the number of the Counterparty to the contract. This will be Vendors or Customers in Purchase or Sales contracts respectively.
Name: Defaulted from the Name on the Vendor or Customer record for future reference purposes.
Contract - General
Specifies the primary options determining the functions and behaviour of the contract.
Contract Type: Specifies the Contract Type defined in CommLinc. One of the main functions of the Contract Type is to determines whether a contract is hedged, therefore allowing access to selecting futures trades to determine price. It also specifies if the calculated price is allowed to be overridden by the user.
Contract Date: Specifies the date contract is written.
Item: Specifies the Commodity represented by standard Business Central Items in CommLinc.
Transport Method: Specifies the Transport Method to be used in the execution of the contract. Two important contract aspects determined by Transport Method is the Loss Tolerance % and whether stock is physically transported of executed by certificate or stock transfer.
Shipment Method: Specifies the Standard Business Central Shipment Method which is typically used for Inco terms.
Back to Back: Defining a contract as a Back To Back contract indicates a direct link between one Purchase and one Sales contract executed directly between the two counterparties. Back to Back contracts are typically executed by means of direct shipments where product is collected from a vendor and delivered directly to a customer.
Back to Back Contract: Displays the contract number of the linked back-to-back contract. Read-only — set automatically when the back-to-back relationship is created.
Commission Trader: Specifies the trader related to the contract. Traders are maintained through standard Business Central Salespeople/Purchasers functionality.
Responsibility Center: Specifies the responsibility center under which the contract resides, maintained through standard Business Central Responsibility Center. When a Counterparty is selected, the Responsibility Center is automatically overwritten with the value from the Customer or Vendor master record. If you have manually set a different Responsibility Center, verify it after selecting the counterparty.
Assigned User: Specifies the user to which the contract can be assigned.
Contract Status: Specifies whether the contract is Open, Pending Approval, Approved, Closed, or Cancelled. A contract in Rejected status is still editable — it can be corrected and a new approval request submitted.
Basis Final: Indicates that all basis elements on this contract's schedules have been finalised. When ticked, advance invoicing becomes available for eligible schedules. The default value is driven by the Contract Type setting.
Contract Qty.: Indicates the sum of the quantities specified on the Contract Schedules.
Adjusted Qty.: Indicates the sum of adjustment quantities specified on the Contract Schedules, typically due to under or over allocation of a contract.
Packaging Type: Specifies the default packaging type for the commodity on this contract. An information field available for filtering and reporting.
Default Weight Liability Transfer: Specifies the point at which liability for the weight of product on a load transfers to or from a Vendor or Customer respectively. Options are Loaded, Offloaded or Certificate transfer.
Default Grade Liability Transfer: Specifies the point at which liability for the grade of product on a load is determined. Options are Loaded, Offloaded or Certificate transfer.
Over-Receipt Code: Specifies the contract tolerance in respect of under and over deliveries.
Advance Percentage: Information field specifying the agreed advance percentage negotiated on the contract.
Contract Closed: Indicates that a contract is closed. Used for sorting and filtering of contracts.
Shortcut Dimension 1: Specifies the code for Shortcut Dimension 1, which is one of two global dimension codes that you set up in the General Ledger Setup window. Setup as Trading Desk Code in above example.
Shortcut Dimension 2: Specifies the code for Shortcut Dimension 2, which is one of two global dimension codes that you set up in the General Ledger Setup window. Setup as Primary Contract Code in above example.
Internal Reference: Free text for internal referencing.
External Document No: Free text for capturing external reference.
Business Rules — General
Counterparty changes: Changing the Counterparty requires confirmation. The Counterparty cannot be changed if any schedule already has an Estimate Quantity (i.e. loads have been scheduled against the contract). For Sales contracts, the customer credit limit is evaluated when the Counterparty is first set.
Item changes: The Item cannot be changed if any of the following are non-zero on the contract: Purchase Invoice Qty, Sales Invoice Qty, Estimate Qty, Hedged Qty, or Delivered Qty. When the Item is successfully changed, all schedule Item fields are updated to match.
Responsibility Center: Only users whose User Setup grants access to the selected Responsibility Center may be assigned to the contract. Changing the Responsibility Center clears the Assigned User field.
Back to Back: When the Back to Back checkbox is ticked, the system prompts the user to either create a new contract of the opposite transaction type (Purchase ↔ Sale) or link to an existing open contract. A newly created back-to-back contract is pre-populated with the same Item, Contract Date, Transport Method, Shipment Method, Trader, Responsibility Center, and Dimensions as the source contract, and its schedules are copied from the source. The linked contract number is shown in the Back to Back Contract field (read-only on both sides). Unticking Back to Back prompts for confirmation and removes the link from both contracts simultaneously.
Currency: When a Currency Code is set, the Currency Factor is automatically retrieved from the BC exchange rate table for the current Work Date. If no exchange rate record exists, a notification is displayed. The user is prompted to confirm if the factor subsequently changes.
Contract - Counterparty Details
Counterparty details, in the case of a Purchase Contract it will be a standard Business Central Vendor while for Sales Contract it is a Customer.
Payment Terms are selected from the standard list of BC Payment Terms. When a Counterparty is first selected on the contract, the Payment Terms Code is automatically defaulted from the Customer (sales) or Vendor (purchase) master record. If the counterparty has no Payment Terms set on their master record, this field will arrive blank and must be completed manually before the contract can be released.
Contact No. specifies the contact number of the contact at the counterparty. Once a Contact No. is selected, the contact's Name, Phone No., Mobile Phone No., and E-Mail are displayed as read-only fields sourced from the Contact record.
Account Counterparty defines whether the current Counterparty (Customer/Vendor) is to be invoiced or if another party will be invoiced.
Account No. defines the Customer or Vendor to be invoiced on the contract. The field is only editable if another party is selected in the Account Counterparty dropdown above.
Important: For Sales contracts, if the Customer has a Bill-to Customer No. set on their master record, the Account No. is automatically defaulted to that bill-to customer rather than the contract counterparty. For Purchase contracts the equivalent is Pay-to Vendor No.. Verify this field if your counterparty has a bill-to/pay-to relationship configured — invoices will go to the Account No., not necessarily the counterparty.
Counterparty Reference: Specifies an external document number, for example that refers to the counterparty's numbering system.
Counterparty Address: The counterparty address fields are defaulted from the current address of the counterparty at the time the counterparty is selected. This represents the domicilium of the counterparty at time of contracting, not to be confused with the shipping address specified in the Shipping section. Address fields are editable as required.
Contract - Signature
Section for recording contract signature status and electronic signature references.
Contract Signed: Specifies whether the contract has been dually signed.
Contract Signed Date: The date the contract was signed.
Electronic Signature Status: Specifies the status of the electronic signature process for the contract.
Electronic Signature Request ID: Specifies the unique identifier for the electronic signature request associated with the contract.
Electronic Signature Remark: Specifies any remarks or comments related to the electronic signature process for the contract.
Trader Manager Contact: Specifies the contact person within the company who is authorized to authorize the trade.
Company Signatory: Specifies the name of the contact person within the company who is authorized to sign the contract.
Counterparty Signatory: Specifies the name of the contact person at the counterparty who is authorized to sign the contract.
Contract - Metrics
Contract Metrics provide a bird's-eye view of summed totals of transactions related to the contract. The four sections are Hedging, Logistics, Invoiced Quantity, and Advances.
To view the details behind any metric, drill down on the relevant quantity field.
Hedging
Hedged Qty. totals the quantity priced on all contract schedules through futures trade allocations. Negative values indicate un-pricing transactions where a buy trade has been allocated to a purchase contract.
Hedged Adjusted Qty. totals the hedge adjustment quantities, representing quantity adjustments applied to the hedged position after the initial allocation.
Logistics
Estimate Qty. is the total estimated delivery quantity across all load allocations on the contract.
Delivered Qty. is the total net quantity delivered, after mass adjustments, across all load allocations.
Contract Weight is the total weight across all contract schedules, calculated from schedule quantity and the item unit-of-measure conversion factor.
Invoiced Quantity
Purchase Invoice Qty. is the total quantity invoiced on purchase invoices linked to this contract.
Sales Invoice Qty. is the total quantity invoiced on sales invoices linked to this contract.
Advances
Advance Invoice Qty. and Advance Invoice Value sum the quantities and amounts on advance (prepayment) purchase invoices raised against this contract.
Advance Cr. Note Qty. and Advance Cr. Note Amount sum the quantities and amounts on advance credit notes, representing advance amounts reversed or reconciled against final invoicing.
Contract - Schedules
The Contract Schedule defines the variant or grade, stock-keeping location, season, variant adjustment table, attribute value adjustment table, default futures delivery month, delivery period, and the quantity and adjusted quantity of the schedule. Unit Price is editable depending on whether the contract type has Allow Price Override set to true.
Basis, spread, estimated quantity, delivered quantity, hedged quantity and invoiced quantity are calculated from the related records as allocated through their respective allocation functions. Shipment method, transport method, transport budget and gross weight make up the metrics related to logistics. The final fields are the standard Business Central dimension codes.
Schedule Defaults
When a new schedule is added, the following fields are defaulted from the contract header: Item, Transaction Type, Counterparty, Transport Method, Shipment Method, Currency Code, Currency Factor, and Dimensions. The Allocation Order defaults to the schedule number and can be adjusted to control the sequence in which schedules are filled during automatic load allocation. Basis elements are automatically pre-populated from the Contract Type definition (see Schedule - Basis).
Schedule Status
A schedule transitions automatically between Open and Closed status based on its quantities:
- A schedule is set to Closed when Quantity + Adjusted Qty = Delivered Qty and Delivered Qty = Invoiced Qty.
- When all schedules on a contract are Closed, the contract header status is automatically set to Closed.
- A schedule can be manually toggled between Open and Closed using the Close/Reopen Schedule action, provided the quantity conditions above are not actively preventing it.
Schedule Quantity Rules
The system enforces the following constraints when editing schedule quantities:
- Quantity cannot be reduced below the current Estimate Qty or Delivered Qty (hard error).
- Quantity cannot be reduced below the current Invoice Qty (hard error).
- If the quantity is reduced below the Hedged Qty, a warning is displayed but the change is not blocked.
Schedule Deletion
A schedule cannot be deleted if any load allocations exist against it. Deleting a schedule automatically removes all related pricing, basis, and spread records.
Allocation Order
When loads are automatically allocated to a contract using Apply to Contract, schedules are filled in Allocation Order sequence (defaulting to the schedule number, i.e. oldest first). To change the fill priority, edit the Allocation Order value on each schedule directly in the schedules subpage.
Pricing Status Control
If Pricing Status Mandatory is enabled in CommLinc Setup, a schedule must have a Pricing Status assigned before it can be allocated to or invoiced. Whether a given Pricing Status permits allocation or invoicing is controlled on the Pricing Status setup record. A schedule can only be invoiced when all three conditions are met:
- The schedule is Priced (or the Contract Type is not hedgeable).
- The assigned Pricing Status allows invoicing.
- The Delivered Qty exceeds the already Invoiced Qty.
The Unit Price field is directly editable only if Allow Price Override is enabled on the Contract Type. The price cannot be modified after any quantity on the schedule has been invoiced.
Schedule - Pricing
Contracts with a Contract Type set to hedgeable (Is Hedged) can be priced by allocating Futures Trades to a Contract Schedule.
To price a contract schedule, open the Contract Schedule Trade Allocation screen by drilling down on the price field of the contract schedule. If the contract is not hedgeable, the price field of the Contract Schedule is directly editable.
On drill-down, the user can select a futures trade captured through the Futures Trading functionality. When selecting Futures Trades the lookup screen is limited to futures contracts of the same commodity as the contract as well as the same Default Futures Contract as specified on the contract schedule. By clearing the filters on the lookup page, other trades are displayed for selection.
After selecting the Futures Trade, the user must either enter the number of contracts or the exact quantity of the futures trade to allocate to the contract schedule. If price override is allowed on the contract type, the user can change the price to be used in calculating the schedule price. Contract Schedules can be partially priced or priced using multiple Futures Trades, in which case the weighted average price is used as the schedule price. Once a Contract Schedule has been invoiced, the pricing elements can no longer be edited.
Two additional constraints apply when adjusting existing pricing allocations:
- The Hedged Quantity cannot be reduced below the Invoiced Quantity. If a user attempts to reduce an allocation quantity on a partially-invoiced schedule — for example to move quantity from one trade to another — the system will block the change if it would leave less hedged quantity than has already been invoiced.
- The Adjusted Allocation field updates the schedule's Hedged Adjusted Date to the trade date whenever it is changed. This affects date-based reporting; verify the date is correct after any hedge adjustment.
Basis is the premium or discount which will be applied to the schedule price at invoicing. Each Contract Type has a default set of Basis Elements.
Schedule - Basis
To add Basis elements to a Contract Schedule, drill down to the Basis Elements editing screen.
The default set of basis elements, as defined on the Contract Type, are pre-populated in the edit screen. Basis elements can be added or removed from the contract schedule as required.
Basis elements are locked as soon as any purchase or sales invoice quantity exists against the schedule — this includes partial invoicing. A user who attempts to add, remove, or modify a basis element on a partially-invoiced schedule will receive an error, even if the specific load being invoiced is not yet finalised. Plan basis adjustments before any invoicing begins.
Schedule - Spread
Contract Schedules can be spread from one delivery month to another prior to invoicing.
Spreads can be either specific to one contract and captured through the pricing mechanism, or through the generalised Futures Spread spread mechanism. Allocating a portion of a spread to a contract schedule will calculate the price differential between the From and To Futures trades and add the value to the Contract Schedule Spread amount. The Default Futures Contract on the schedule will also be changed to reflect the spread To Futures Contract.
Two additional behaviours to be aware of:
- Cross-commodity spreads — if the futures instrument on the selected spread does not match the contract's commodity, the system will ask for confirmation rather than blocking the entry. This prompt is expected when executing a legitimate cross-hedge; if the cross-commodity spread is unintentional, cancel and verify the correct spread is selected.
- Modifying an existing spread line — if a spread already allocated to a schedule is subsequently modified (e.g. the quantity is corrected), the schedule's Default Futures Contract is recalculated and overwritten again based on the updated spread. Verify the Default Futures Contract on the schedule after any spread correction.
Contract - Schedule Management
The Contract Schedules subpage and the Load Allocations subpage both carry actions that go beyond basic data entry. This section documents each one in detail.
Invoice Schedule
The Invoice Schedule action on the schedule row invoices all load allocations on the selected schedule that are ready for invoicing — those where the load is marked Final to Invoice and the schedule's Pricing Status allows invoicing. After generating the last invoice, the system prompts to open it.
The Invoice Allocation action on the Load Allocations subpage works on a single selected allocation rather than all allocations on the schedule. It additionally validates that the contract is in Approved status and that the schedule is fully priced before proceeding.
Credit Allocation
The Credit Allocation action is visible on the Load Allocations subpage only for allocations that have already been invoiced. It generates a Credit Memo for the selected allocation and prompts to open it. The Load No., Contract No., and Schedule No. references are automatically carried through to the credit memo lines.
Advance Invoicing
The Advance Schedule action is visible only on Purchase schedules. It is enabled when:
- Delivered Qty exceeds the net outstanding advance quantity (Advance Invoice Qty − Advance Cr. Note Qty) — meaning there is delivered quantity not yet advanced.
- The schedule has no Futures Trade pricing allocations — advances are exclusively for unpriced schedules. A schedule with any hedged quantity cannot be advanced.
- The Advance Percent on the contract header is greater than zero.
- The Basis Final checkbox on the contract is ticked.
The advance unit price per ton is calculated as:
(Unit Price + Variant Discount + Attribute Premium) × Advance %
Advance invoices are created as Purchase Invoices posted against the Prepayment G/L Account from the General Posting Setup. Only loads flagged as Final to Invoice Purchase are eligible. The quantity available to advance is: Delivered Qty − Invoiced Qty − Previously Advanced Qty. Advance amounts are reconciled and netted out during final settlement invoicing.
Splitting a Schedule
The Split Schedule action creates a new schedule from a portion of the current one. It is enabled only when the schedule has more quantity than has been invoiced — i.e. Quantity + Adjusted Qty > Invoiced Qty. A fully invoiced schedule cannot be split.
The split dialog presents three options:
- Quantity to Split — the quantity to move to the new schedule. Cannot exceed Quantity + Adjusted Qty − Invoiced Qty.
- Select Specific Loads — when enabled, a selection screen appears listing the loads currently allocated to the schedule. The user picks which loads move. If disabled, allocations move in delivery date order (oldest first) until the split quantity is filled.
- Do Not Split Load Allocations — when ticked, load allocations are left entirely on the original schedule and the new schedule is created with no allocations. Useful when the split is purely for pricing or delivery period management rather than physical load management.
On split the following occurs automatically:
- Basis elements are copied to the new schedule.
- Load allocations are moved in delivery date order up to the split quantity (or as selected), unless Do Not Split Load Allocations is ticked.
- Pricing records are split in sequence (oldest trade first) if the original schedule has no invoiced quantity, or proportionally across both schedules by quantity if invoiced quantity exists.
- Spread records are proportionally distributed based on respective hedged quantities.
- If advance invoices exist on moved allocations, a nil advance invoice is automatically generated and posted to transfer the advance balance to the new schedule.
Reallocating a Load Between Schedules
The Reallocate Allocation action on the Load Allocations subpage moves an individual load allocation from its current schedule to a different one. It is only available when the allocation has no invoiced quantity.
A lookup opens filtered to open schedules matching the current load's: Item, Transaction Type, Counterparty, and — for purchase allocations — the same Transport Method. The target contract must be in Approved status. The same schedule cannot be selected as both source and target.
If the target schedule has insufficient remaining capacity, the system will attempt to make space through load bumping (see below).
Load Bumping
Load bumping is the mechanism the system uses automatically when allocating a load to a schedule that does not have sufficient remaining quantity to accommodate it. It applies during both Apply to Contract and Reallocate Allocation.
How bumping works:
The system scans the allocations already on the target schedule and temporarily removes ("bumps") ones that meet all of the following criteria:
- The load is not marked Final to Invoice — a finalised load is never bumped.
- The allocation has no invoiced quantity.
- The allocation does not belong to the load currently being allocated.
Bumped allocations are removed in reverse load-number order (newest loads bumped first) until enough space is freed. Once the priority load is placed, the system re-allocates the bumped loads using the standard contract allocation logic — filling the original schedule first, then spilling to the next available open schedule on the contract if the original is now full.
What bumping means in practice:
Bumping ensures a higher-priority or more recently finalised load can be correctly positioned on a schedule even when earlier loads have partially consumed the available space. Because the bumped loads are re-allocated automatically, no allocations are permanently lost — but a bumped load may end up on a different schedule than it started on. If a bumped load cannot be placed on any schedule, a message is displayed with the quantity that could not be accommodated.
Loads marked Final to Invoice are never bumped. Once a load is flagged for invoicing, its allocation position on the schedule is permanent and cannot be displaced by another load.
Open/Close Schedule
The Close Schedule and Open Schedule actions toggle the schedule between Open and Closed status manually — the system's automatic status calculation (see Schedule Status) is the primary mechanism, but these actions provide a manual override when required.
Contract - Currency
Currency related to contract.
Currency defines the BC currency which will be used for invoicing. Standard BC Currency mechanism is leveraged for invoicing purposes.
Currency Factor indicates the currency factor to be passed to invoicing.
Contract - Shipping
The shipping section is used to detail logistical information related to where the product will be shipped from or to in the case of purchase and sales contracts respectively.
By default the shipping route is from the stock location to the shipping address.
Shipping Option allows for three different options: Default Counterparty Address, Alternate Shipping Address and Custom Shipping Address. Alternate lets the user select one of the contract counterparties pre-defined addresses while custom address allows for free editing of address details.
Shipping Contact specifies the name of the contact person at the shipping address.
Shipping Phone No. specifies the telephone number at the shipping address.
When Loads are created through the Load Scheduler the Load's delivery or pickup address is defaulted from the contracts Shipping details.
Contract - Foreign Trade
Foreign trade defines logistical information related to cross border trades for reporting purposes.
Exit Point specifies the intended entry or exit point of the country.
Received-from/Shipped-to Country specifies the foreign country where the product originates from or its final destination in the case of purchase and sales contracts respectively. This field is primarily for reporting purposes.
Contract - Mass Adjustment Attributes
Allows default Loaded and Offloaded adjustment tables to be defined for a contract. Default tables are copied to load grading records at the time of grading. Grading records of loads already graded prior to being allocated to a contract will not be retrospectively modified.
Attribute specifies the attribute to determine the adjustment.
Order specifies the order in which mass calculations will be executed. The Order value must be unique within the contract — two rows with the same Order value cannot be saved and will produce a duplicate-key error. Use non-overlapping numbers (e.g. 10, 20, 30) to leave room for future insertions.
Load Adjustment Table defines the table containing the adjustment specifications for loading.
Offload Adjustment Table defines the table containing the adjustment specifications for offloading.
Contract Schedules
The Contract Schedules list is a read-only cross-contract inquiry view of every contract schedule in the system. Unlike the Load Scheduler (which is scoped to a single contract) this list spans all contracts and is the most efficient way to filter and analyse schedule status across the entire portfolio at once.
The list can be filtered by any combination of: Transaction Type, Item, Location, Season, Delivery Date, Counterparty, Dimension codes, or Schedule Status. All fields are available for personalisation.
In addition to the standard schedule fields, the list includes several calculated status indicators:
Total Quantity = Schedule Quantity + Adjusted Qty.
Remaining to Deliver = Total Quantity − Delivered Qty. Indicates how much of the schedule still needs physical delivery.
Fully Delivered — true when all loads allocated to the schedule are marked Final to Invoice and the total delivered quantity meets or exceeds Total Quantity.
Hedged Contract — true when the Contract Type for this schedule is configured as Is Hedged.
Fully Priced — true when the schedule is either not hedgeable, or its Hedged Qty + Hedged Adjusted Qty is equal to or greater than the schedule quantity.
Remaining to Price = (Quantity + Adjusted Qty) − (Hedged Qty + Hedged Adjusted Qty). Only meaningful for hedged contracts; zero for non-hedged.
Remaining to Invoice = Delivered Qty − Invoice Qty (purchase schedules) or Delivered Qty + Invoice Qty (sales schedules, where Invoice Qty is stored negative).
This page is read-only. To edit a schedule, open the parent contract from the Contract No. field.
Futures Trading
Commodity futures trades are agreements to buy or sell a particular commodity at a future date. The price and the amount of the commodity are fixed at the time of the agreement. Traders use futures trades to fix the price of contracts to be executed in the future. As a futures trade creates the obligation to buy or sell a commodity at a future date, it is important for commodity traders to match their long and short positions to open sales contracts, open purchase contracts, or physical stock positions.
Understanding Positions and Allocation Signs
Before using the Futures Trading screens, it is important to understand how positions and allocation signs work across the system.
Long means the company has bought futures — it has an obligation to receive commodity. A Buy (B) trade creates a long position.
Short means the company has sold futures — it has an obligation to deliver commodity. A Sell (S) trade creates a short position.
When a futures trade is allocated to a contract schedule it is being used to set the price of that contract. The sign of the allocation quantity depends on the trade direction and the contract type:
| Trade | Contract | Effect | Sign on Allocated field |
|---|---|---|---|
| Sell (S) | Purchase | Pricing a purchase | Positive |
| Buy (B) | Purchase | Un-pricing a purchase | Negative |
| Buy (B) | Sale | Pricing a sale | Positive |
| Sell (S) | Sale | Un-pricing a sale | Negative |
Negative allocated quantities therefore indicate un-pricing transactions, which is why the existing guide notes that negative hedging amounts indicate un-pricing.
A futures trade is considered fully allocated when the sum of all allocations (to contracts, spreads, and bank finance, with appropriate signs) equals the trade quantity, leaving zero unallocated.
Futures Contract List
A futures contract defines the year and month of a Futures Instrument. A futures instrument represents a commodity trading instrument on a particular futures exchange.
Each futures contract is uniquely identified by the combination of Futures Instrument, Delivery Month, and Year — the system prevents duplicate contracts for the same instrument and period. When an Expiration Date is entered, the Delivery Month and Year are automatically derived from it.
The list summarises the book position of each contract across all its trades:
Long Position is the total quantity of Buy trades on this contract.
Short Position is the total quantity of Sell trades on this contract.
Allocated Purchases is the total quantity allocated to Purchase Contract schedules. A negative value indicates un-pricing — a long (Buy) trade applied to a purchase contract.
Allocated Sales is the total quantity allocated to Sales Contract schedules. A negative value indicates un-pricing — a short (Sell) trade applied to a sales contract.
Allocated Spread Purchase is the total long-side quantity consumed by book spreads referencing this contract.
Allocated Spread Sale is the total short-side quantity consumed by book spreads referencing this contract.
Allocated Bank Purchase is the total quantity allocated to the purchase side of bank finance records.
Allocated Bank Sale is the total quantity allocated to the sale side of bank finance records.
Net Allocation is the net of all purchase and sales allocations, indicating the remaining unallocated position on the contract.
Futures Trade List
Futures Trades List details the individual trades of Futures Contracts executed on a futures exchange.
The Futures Trade screen is used to enter trades executed on the futures market.
No. is the system-generated document sequence number.
Trade Date is the date and time the trade was executed.
Sell/Buy indicates a sell (S) or buy (B) transaction.
Dealer Code indicates the Futures Exchange Dealer who executed the deal. Selecting a Dealer Code automatically populates the Salesperson/Purchaser Code from the dealer record.
Futures Exchange is the exchange on which the trade was executed. This is auto-populated from the Futures Instrument when a Futures Contract is selected.
Futures Contract identifies the Futures Contract traded. Selecting a contract automatically populates the Item No. and Futures Exchange from the underlying Futures Instrument.
Exchange Reference is the unique reference number assigned by the Futures Exchange. The combination of Exchange Reference and Deal Sequence must be unique per exchange — this constraint prevents duplicate imports.
Deal Sequence is the sequence number allocated by the Futures Exchange.
Member is the exchange member code that executed the trade.
Number of Contracts is the number of contracts traded. Quantity is calculated automatically as: Number of Contracts × Contract Size (from the Futures Instrument setup).
Price is the traded price per unit for Futures and Spot trades, and the option premium per unit for Put and Call options.
Trade Type options are: Future (F), Put (P), Call (C), Spot (S). When importing via Excel only the first character is required.
Strike is the option strike price, applicable to Put and Call trade types only.
Cross Hedge Item No. is used when the futures instrument does not exactly match the physical commodity being hedged (cross-hedging).
Salesperson/Purchaser Code identifies the trader who executed the deal.
Allocated Purchase / Allocated Sales sum the quantities allocated to purchase and sales contract schedules respectively. Negative values indicate un-pricing transactions.
Allocated Spread Purchase / Allocated Spread Sales sum the quantities consumed by the long and short sides of book spreads.
Allocated Bank Purchase / Allocated Bank Sales sum quantities allocated to bank finance transactions.
Price Calculation on Contract Schedules
When a futures trade is allocated to a contract schedule, the schedule price is recalculated as the weighted average of all pricing allocations on that schedule:
Schedule Price = Σ (Allocation Price × Quantity) ÷ Σ Quantity
For Put and Call options the trade price is treated as an option premium rather than a direct price:
- A sold option (S): premium is positive, added to the Option Premium Basis Element.
- A bought option (B): premium is negative.
The Option Premium Basis Element is configured in CommLinc Setup and must be present in the contract schedule's basis elements. If it is not, the allocation is blocked with an error.
The total priced quantity across all pricing allocations on a schedule cannot exceed the schedule's Quantity + Adjusted Qty.
Futures Trades - Excel Import
To import Futures Trades via Excel, click the Share this page with other users or apps icon in the upper right corner of the Futures Trade List screen, then select Edit in Excel.
Tip — Personalising the Futures Trade screen so that columns are displayed in the same order as a spreadsheet containing the daily trades will make the import process easier. The Excel file is created with columns in the same order as the Futures Trade List screen. Before clicking Exit in Excel, filter on the date of the trades you wish to import. This will create a blank spreadsheet in which to capture or paste the day's transactions.
After capturing the day's trades in the spreadsheet, use the Publish functionality to update or add the trades to the system.
The Exchange Reference and Deal Sequence combination must be unique per exchange. If a duplicate is imported the system will reject it, preventing accidental double-entry of exchange confirmations.
Futures Spread List
Futures spreads record the rolling of a position from one delivery month to another. A book spread moves the trading book's exposure; an individual producer or customer spread can be allocated directly to a contract schedule through the schedule pricing mechanism.
One record is created per spread transaction. The spread quantity can be allocated across different contract schedules.
No. is a system-generated sequence number.
Spread Date is defaulted from the Trade Date of the Long trade when it is selected.
Description provides a free text space to briefly describe the spread.
Futures Trade Long identifies the long (Buy) trade involved in the spread. Selecting it automatically populates Futures Contract Long and the Spread Date.
Futures Contract Long references the futures contract on the long side.
Futures Trade Short identifies the short (Sell) trade involved in the spread. Selecting it automatically populates Futures Contract Short.
Futures Contract Short references the futures contract on the short side.
Number of Contracts is the number of contracts in the spread.
Quantity is calculated automatically as: Number of Contracts × Contract Size (from the Long contract's Futures Instrument).
Spread Value is calculated automatically as: Short Trade Price − Long Trade Price. This represents the cost or gain of rolling the position from the long month to the short month.
Spread Allocation Rules
The total quantity allocated from a spread to contract schedules (Qty Allocated) cannot exceed the spread Quantity. The system also validates that allocating a spread does not cause the underlying long or short futures trade to be over-allocated beyond its own trade quantity.
When a spread is allocated to a contract schedule, the schedule's Default Futures Contract is updated to the short-side contract (the month the position has been rolled to), and the spread value is added to the schedule's Spread amount.
Futures Trade Allocation
The Futures Trade Allocation list is a read-only global view of every futures trade pricing allocation record in the system — the individual lines that link futures trades to contract schedules. It is the primary tool for auditing how trade quantities are distributed across contracts.
Each row shows: Futures Trade No., Contract No., Schedule No., Transaction Type, Trade Date, Item, Futures Contract (delivery month), Quantity allocated, Adjusted Allocation, Allocation Price, Option Premium, and Strike Price.
The list can be filtered by any field — for example, filtering on a specific Futures Contract month shows all contracts priced against that month, making it easy to identify exposure and verify that allocations are correctly matched between purchase and sales positions.
This page is read-only. Allocations are created and managed from the Contract Schedule Pricing drill-down on the Contract Card.
Bank Finance
Bank Finance provides a mechanism to record stock under bank finance without creating formal sale and buyback contracts. Futures trades can be allocated to a Bank Finance record to represent the bank's hedged position.
No. is a system-generated sequence number. New records default to Active status.
Vendor identifies the Vendor No. of the bank or institution financing the stock.
Item identifies the item number of the commodity financed.
Finance Date is the date the finance transaction is concluded.
Quantity is the maximum quantity of commodity covered by this finance facility.
Value is the total value of the finance facility.
Active indicates whether the facility is currently open and available for futures trade allocation. Inactive records are excluded from allocation lookups.
Allocated Bank Purchase is the quantity of stock purchased by the bank, represented by Sell (S) futures trades allocated to the purchase side. A sell trade on the bank's behalf means the bank is effectively short the physical.
Allocated Bank Sale is the quantity of stock sold back by the bank, represented by Buy (B) futures trades allocated to the sales side.
Bank Finance Allocation Rules
The total quantity allocated from a futures trade to bank finance records across all sides (contracts, spreads, bank finance) cannot exceed the trade's own Quantity. The system validates this constraint whenever a bank finance allocation is created or modified.
Load Instructions
Load Instructions are a tool used for the management of stock due for out loading at 3rd party storage facilities. When product is to be collected at the storage facility the stock owner will inform the storage facility that it intends out loading the specified quantity. Loads can optionally be allocated to load instructions to track the balance available for collection.
Load Instruction List
The Load Instruction List is a list of all issued load instructions. The list page is divided into two sections, the bottom section displays the loads which have been allocated to the load instruction. One load can be split across more than one instruction.
The top grid contains information related to the load instructions.
No. is a system-generated sequence number. New instructions default to Open status on creation.
Instruction Date is the date on which the instruction was issued.
Location Code represents the storage location from which the commodity must be collected.
Location Name is the name of the location.
Item represents the item code of the commodity on instruction. Selecting the Item automatically defaults the Unit of Measure from the item's Base Unit of Measure.
Variant Code is the Item Variant or grade of the commodity on instruction.
Status is the current status of the instruction. Valid values are Open and Closed. Status is manually managed — it is not automatically set by the system.
Instruction Reference is a free text field for an external reference number or note.
Silo Certificate Numbers stores the silo certificate numbers associated with this instruction.
Quantity represents the quantity of commodity intended for out loading. The quantity cannot be reduced below the Loaded Qty already allocated to loads.
Loaded Qty is the sum of all load quantities allocated to the instruction.
Remaining Qty is a calculated field: Quantity − Loaded Qty, indicating the balance still available for out loading.
Load Instruction Business Rules
- A load instruction cannot be deleted if any load has been allocated to it (Loaded Qty > 0).
- The Quantity cannot be set below the current Loaded Qty — this would make the instruction over-allocated.
- Status is manually controlled; closing an instruction does not prevent further load allocations unless explicitly managed.
The bottom grid shows the loads allocated to the instruction:
Load No. is the load allocated to this instruction.
Loaded Date is the date the load was loaded at the storage location, sourced directly from the Load record.
Loaded Variant is the grade of the commodity as loaded, sourced from the Load record.
Location Code is the location associated with the load. It is possible that a load is collected at a different location to that specified on the instruction — this can occur when the storage operator directs collection to an alternative silo.
Customer, Item, Vehicle Registration and Shipment Reference all relate to details of the load.
Quantity Allocated is the portion of the load allocated to this instruction.
Loaded Weight and Net Loaded Weight relate to the gross and net weights of the load.
Loads
CommLinc Financial Architecture
Before diving into loads, it is worth understanding the financial transactions that CommLinc generates and what each one represents. CommLinc's core purpose is to serve as the control system that drives Business Central's financial and inventory engine — but it never duplicates a transaction, and it is designed so that completing the process in the correct sequence makes double-posting structurally impossible.
Inventory Transactions — via Purchase and Sales Orders
Stock movements in Business Central are managed through Purchase and Sales Orders. CommLinc generates and maintains these automatically, using the load's weights as they become available:
| Transaction | Purpose | When generated |
|---|---|---|
| Purchase Order | Records stock arriving at a location (Inbound/Direct) | When load has Estimate Weight, updated as loaded/offloaded weights are captured |
| Sales Order | Records stock leaving a location (Outbound/Direct) | Same lifecycle as Purchase Order |
| Inventory Adjustment | Reconciles in-transit gains or losses | When Final to Invoice is set; auto-reversed if weights change |
Once a Purchase or Sales Order is fully invoiced — nothing left to receive or ship, nothing left to invoice — CommLinc automatically deletes it. This is by design: a fully processed load leaves no open orders behind, and the stock movement is preserved permanently in the posted item ledger entries.
Financial Transactions — directly in Business Central
All financial settlement flows through standard BC purchase and sales invoice documents that CommLinc creates and links back to the originating load and contract:
| Transaction | Type | Purpose |
|---|---|---|
| Purchase Invoice | Purchase document | Pays the vendor (producer/supplier) for commodity delivered. Includes main item line at Net Price (Price + Basis + Spread), plus Item Charge lines for Variant Discounts and Attribute Premiums. |
| Sales Invoice | Sales document | Bills the customer for commodity delivered. Same structure as purchase invoice, applied to the sales side. |
| Advance Invoice | Purchase document (prepayment) | Pays a portion of the expected purchase settlement before final invoicing. Uses a G/L Account (not an item), posted as a prepayment. Reconciled and netted at final invoicing. |
| Transport Purchase Invoice | Purchase document | Pays the transporter for freight. Uses a Transport Item (not an Item Charge), based on the transporter's actual invoiced weight and rate. |
| Transport Loss Sales Invoice | Sales document | Recovers the cost of transport loss exceeding the tolerance from the transporter's linked customer account. |
Prevention of Double Processing
CommLinc enforces a strict sequence that makes it structurally impossible to invoice the same quantity twice:
- Purchase and Sales Invoices are created with quantity = Delivered Qty − already Invoiced Qty. If this is zero, no invoice is created.
- Transport Invoices check that Transport Invoice Qty is less than Transport Weight before creating a new invoice line. Once fully invoiced, the action is blocked.
- Allocations cannot be re-allocated once they carry invoiced quantity.
- Final to Invoice flags lock the relevant weights and variants as read-only the moment they are set, preventing the base quantities from changing after invoicing has started.
- Contract status is checked on every invoice creation — if a contract is not Approved, the invoice is blocked.
- Basis Final must be true on the contract before any purchase invoice is accepted, ensuring pricing is confirmed before financial settlement.
- Every posted invoice, credit memo, and order carries the Load No., Contract No., and Schedule No. as permanent references, making the full financial trail auditable from any direction.
Loads, along with Contracts form the basis of CommLinc from which all transactions are initiated. Loads are used to represent a physical movement of a transfer of stock. Loads can be either Inbound, Outbound, Direct, or Transport loads.
- Inbound — from a Vendor to a Stock Location. Increases stock at the location.
- Outbound — from a Stock Location to a Customer. Decreases stock at the location.
- Direct — from a Vendor directly to a Customer. A Location still serves as a logical stock point for regulatory reporting and in-transit loss accumulation.
- Transport — records transporter movements only. No Purchase or Sales Orders are generated and the load cannot be allocated to contracts.
Each load in CommLinc generates a Purchase Order and/or Sales Order depending on the load type. Purchase and Sales Orders are the mechanism by which Business Central manages Inventory. When generated through CommLinc they are automatically marked as Received or Shipped, which increases or decreases available inventory at the Load's location.
| Load Type | Purchase Order | Sales Order |
|---|---|---|
| Inbound | ✓ | — |
| Outbound | — | ✓ |
| Direct | ✓ | ✓ |
| Transport | — | — |
Once generated, Purchase and Sales Orders can be managed through standard Business Central purchase and sales order management functions.
Note on fully-invoiced orders: When a CommLinc-generated Purchase or Sales Order is fully invoiced, the system automatically deletes the open order after posting. There will be no open order remaining for a fully invoiced load — look for the posted invoice in Posted Purchase Invoices or Posted Sales Invoices instead.
Note on corrective credit memos and copy document: When the standard BC Correct action is used on a posted CommLinc Purchase or Sales Invoice, the resulting credit memo automatically carries the Load No., Contract No., and Contract Schedule No. through to the credit memo lines. These references are also preserved when using Copy Document to copy a CommLinc invoice to a new document, ensuring all corrective transactions remain traceable to the originating load and contract.
Loads are allocated to contracts for the management of contract liability and to determine the financial value to be invoiced. A load can be allocated to one or more contracts.
| Load Type | Allocated To |
|---|---|
| Inbound | Purchase Contracts |
| Outbound | Sales Contracts |
| Direct | Both Purchase and Sales Contracts |
Loads can be generated directly from Contract Schedules using the Load Scheduler or directly from the Load List or Load Card. When generated from the Load Scheduler they are automatically allocated to the applicable contract, or both contracts in the case of Back to Back contracts.
Load Lifecycle
A load progresses through the following statuses, which are updated automatically every time the load is saved:
| Status | Trigger |
|---|---|
| Estimate | Load created. No loaded or offloaded weight captured yet. |
| Loaded | Loaded Weight has been captured. |
| Offloaded | Offloaded Weight has been captured. |
| Invoiced | All load allocations on the load have been invoiced. |
| Cancelled | Load has been cancelled. No further edits are permitted. |
Deleting a Load
A load can only be deleted when its status is Estimate and it has no posted transactions (no received, shipped, invoiced, inventory adjustment, or advance invoice quantities). Deleting a load removes all load allocations and comments.
Changing the Item or Location
The Item and Location Code cannot be changed if any of the following exist: received quantity, shipped quantity, purchase or sales invoiced quantity, inventory adjustments, or advance invoices. They also cannot be changed if the load has any purchase or sales allocations — allocations must be removed first. When the Item is changed, all grading attribute values on the load are cleared, and the loaded and offloaded variants are reset to the item defaults.
Changing the Vendor or Customer
The Ship-from Vendor cannot be changed if the load has been received or purchase-invoiced, or if purchase allocations already exist. The Ship-to Customer cannot be changed if the load has been shipped or sales-invoiced, or if sales allocations already exist.
Changing the Transport Method
The Transport Method cannot be changed once the load has purchase allocations. For Inbound loads using a non-certificate transport method, Pay Handling Fee is automatically set to true when the transport method is validated.
Changing Variants
The Loaded Variant cannot be changed if the load has already been invoiced based on the loaded variant. The Offloaded Variant cannot be changed if invoiced on the offloaded variant. Changing either variant automatically recalculates variant discounts on all load allocations and re-posts any existing Purchase or Sales Orders to reflect the updated variant.
Load Scheduler
The purpose of the Load Scheduler is twofold: first, to provide a bird's-eye view of contract schedules for delivery, and second, to facilitate the generation of Loads directly from a contract schedule.
The Load Scheduler, by default, contains information about the Contract Schedule such as status, counterparty, delivery dates, commodity (item), location and summarised quantities. As with all lists in Business Central, the Load Scheduler can be customised to display the fields you require to manage contract schedules effectively.
To generate loads, select the applicable Contract Schedule. If the contract is in Approved status, the Create Load icon will be enabled.
The Load Options popup allows the user to define additional information prior to generating the loads.
Load Type is automatically populated based on the contract type of the schedule selected.
Schedule from is populated from the delivery from date on the contract schedule, but may be edited.
Estimate Weight is populated from the CommLinc Settings.
Multiple loads, when selected will enable the Scheduled Loads field to open. Here the user can indicate the number of loads required.
Scheduled Loads indicates the number of loads to generate, it is defaulted to the loads remaining on the schedule. The loads will be initialized with dates spread evenly across the scheduled period.
Schedule to to is defaulted from the delivery to date on the contract schedule, but can be edited.
Transporter if the transported is known it can be filled in here and will be pre-populated on the generated load.
Transport Rate is defaulted from the budgeted transport rate on the contract but can be edited as required.
Selecting the OK button will initiate the generation of the load or loads, after which the user will be prompted as to whether the last generated load should be opened. All generated loads will be available in the Load List.
Load List
The Load List displays all loads in the system in descending number sequence. The Load List is an essential tool for managing the status of loads. In addition to information related to the Type of load, Transport and Shipment Methods, Location, Commodity, Customer and/or Vendor, and Transporter, the screen also contains a host of statistical information required for the effective management of loads.
The screen can be customised by the user to display only information relevant to their particular function.
The initial columns on the screen describe the load while the latter part of the screen presents statistical information related to the Loads. The statistical information summarizes the load weights, allocation to purchase and sales contracts, quantities shipped and received, quantities invoiced, Positive and Negative Adjustments, and quantities allocated to load instruction.
Detailed information describing the load information can be found in the Load Card section. The statistical information is described below.
Estimate Weight indicates the weight estimated for the load. The estimate weight is used as the quantity on generated Purchase and Sales orders to preliminarily increase or decrease stock respectively. Once actual weights are received they can be captured and the Purchase and Sales orders are adjusted accordingly. In the case of Purchase Orders, the quantity received cannot be reduced if the system has already allocated the product to shipped Sales Orders. For this reason the user should be cautious about generating purchase orders based on Estimate Values.
Loaded Weight is the actual weight loaded onto the vehicle.
Offloaded Weight is the actual weight off loaded at the destination.
Transport Weight is defaulted to the loaded weight and is used to calculate the transporters remuneration.
Transport Loss is the difference between the loaded and offloaded weights less the allowance for transport loss as indicated by the Transport Method loss tolerance %.
Purchase Estimate is the sum of estimate quantities allocated to purchase contracts through load allocations.
Sales Estimate is the sum of estimate quantities allocated to sales contracts through load allocations.
Purchase Qty. is the net amount allocated to the purchase contracts through load allocations. The net amount is calculated by reducing the loaded weight by the weight adjustment. Weight adjustments are calculated from the grading attributes captured on the load.
Sales Qty. is the net amount allocated to the sales contracts through load allocations. The net amount is calculated by reducing the offloaded weight by the weight adjustment. Weight adjustments are calculated from the grading attributes captured on the load.
Purchase Invoice Qty. sums the quantity invoiced on the load, net of any credit notes.
Sales Invoice Qty. sums the quantity invoiced on the load, net of any credit notes.
Received Qty. sums the quantity received through the Purchase Order receipt process.
Shipped Qty. sums the quantity shipped through the Sales Order ship process.
Positive Inventory Adjustment Qty. is generated when the Net Qty Invoiced is more than was loaded out of stock, representing an in-transit gain.
Negative Inventory Adjustment Qty. is generated when the Net Qty Invoiced is less than was loaded out of stock, representing an in-transit loss.
Load Instruction Qty. sums the load quantities allocated to Load Instructions.
Load Planning Schedule
The Load Planning Schedule is an alternative list view of loads oriented around the Schedule Date rather than the load number. It is designed for transport planning — showing loads in date order with the day of the week displayed, making it easy to see what is scheduled for each day of the week.
Columns include: Load No., Item Description, Schedule Date, Day (of week), Load Type, Load Status, Transporter, Vehicle Registration, Freight Rate, Location, Ship-to Customer, Ship-from Vendor, Shipment Reference, and Estimated Weight.
Drilling down on any row opens the full Load Card. The page can be filtered and personalised like any BC list.
Related Loads
Related Loads is a grouping mechanism that allows multiple loads to be associated under a single relation record. This is useful when several loads form a logical group — for example, a set of loads all executing against the same shipment, voyage, or physical consignment.
A Related Load record contains: a system-generated No., a free-text Description, a Relation Date (defaulted to Work Date on creation), and a Closed flag. The bottom panel of the page shows all loads linked to the selected relation.
Loads are linked to a Related Load by setting the Related Load field on the Load General section. A Related Load record cannot be deleted while any load references it.
Load Allocations
The Load Allocations list is a read-only global inquiry view of every contract-schedule load allocation record across all loads. It is useful for querying how quantities have been allocated across contracts and loads without navigating into individual load cards. The list can be filtered by Contract No., Schedule No., Load No., Transaction Type, or Delivery Date.
Load Card Workflow
The Load Card is where logistics coordinators spend most of their time. Understanding the sequence of actions and what each step triggers in the system is essential for correct load management.
Stage 1 — Planning: Create the Load
When a new load is created, the system pre-populates Load Type and Estimated Weight from the defaults in CommLinc Setup. The Load Status is set to Estimate.
At this stage the coordinator enters:
- Load Type (Inbound/Outbound/Direct)
- Transport Method and Shipment Method
- Schedule Date
- Commodity (Item) and Location
- Transporter details (Vendor, contact, vehicle registration, freight rate)
- Ship-from Vendor (for Inbound/Direct) and/or Ship-to Customer (for Outbound/Direct)
- Shipment Reference, Loading Reference
Estimated Weight is the quantity the system uses for all allocation and inventory calculations until actual weights are available. It defaults from CommLinc Setup but can be changed. It is the only weight on the load at this stage.
Note on Load Type editability: The Load Type can only be changed while no transactions have been posted against the load (no received qty, shipped qty, invoices, or inventory adjustments). Once any transaction exists, the type is locked.
Note on Item editability: Once the load is allocated to any contract (purchase or sales), the Item field is locked and cannot be changed without first removing all allocations.
Stage 2 — Contract Allocation: Apply to Contract
Once the load has the minimum required fields, the coordinator allocates it to the appropriate contract using Apply to Contract or Apply to Contract Schedule on the Load Contract Allocations subpage.
Apply to Contract fills schedules automatically in Allocation Order (oldest first), subject to matching Item, Counterparty, Location, and Transport Method. The system fills one schedule to capacity before moving to the next.
Apply to Contract Schedule gives the coordinator direct control over which specific schedule receives the load.
The Available to Allocate quantity (shown in Load Details) is based on the Estimated Weight and any adjustment factor already applied. The Remaining to Allocate field shows how much has not yet been placed on a contract schedule — it is highlighted in red when non-zero, prompting action.
Load Bumping During Allocation
When a target schedule no longer has enough remaining capacity to accommodate the load's full available quantity, the system uses load bumping to make space. This is triggered automatically by both Apply to Contract and Reallocate Allocation.
Bumping temporarily removes ("bumps") existing allocations from the target schedule that are:
- Not marked Final to Invoice (finalised loads are never bumped)
- Not yet invoiced
- Not the same load being allocated
The bumped loads are removed in reverse load-number order — the most recently created loads are bumped first. This ordering has a specific purpose: it minimises the creation of split loads. By bumping newer loads (which are more likely to be recent, undelivered estimates) rather than older established allocations, the system preserves the delivery sequence and avoids fragmenting loads that may already have physical movements against them.
After the priority load is placed, the bumped loads are automatically re-allocated using the standard contract allocation logic. They fill the original schedule first; if it is now full, they spill to the next open schedule on the contract. If a bumped load cannot be fully re-accommodated, a message reports the quantity left unallocated.
Loads marked Final to Invoice are never bumped under any circumstances. Their position on the schedule is permanent.
Stage 3 — Loaded Weight: Received from Transport Documentation
When the vehicle is loaded at the source location, a load ticket or weigh-bridge slip is issued by the storage facility or loading point. This document is the source of the Loaded Weight — it is not derived from the Business Central Purchase or Sales Order. The coordinator enters the weight from this external document into the Load Card.
When Loaded Weight is saved, the following chain occurs automatically:
- Estimated Weight is updated to the Loaded Weight (if Offloaded Weight is still zero), giving contracts a more accurate working quantity.
- Load allocations are recalculated — the Estimate Qty on all purchase and sales allocations is updated to reflect the new Available to Allocate quantity derived from the loaded weight.
- Load instruction quantities are updated if any instructions are allocated.
- Load Status advances to Loaded.
- Inventory Posting Date is set to the Date Loaded.
- For Direct loads: all allocation Delivery Dates are set to the Date Loaded.
- Purchase and Sales Orders are re-posted if they already exist, with the updated quantity.
The Loaded Adjustment Factor (and its companion Loaded Adjustment Qty display field) represent the mass deduction factor calculated from grading. The two fields are linked: entering the factor computes the qty, entering the qty back-calculates the factor. Either can be entered directly.
Stage 4 — Offloaded Weight: Received from Destination Documentation
When the vehicle is offloaded at the destination, a second weigh-bridge slip or delivery receipt is issued. This is also an external document — not from BC. The coordinator enters the Offloaded Weight from it.
When Offloaded Weight is saved, the following chain occurs:
- Estimated Weight is updated to the Offloaded Weight, reflecting the most accurate final quantity.
- If Loaded Weight was zero, it is also set to the Offloaded Weight.
- Transport Loss is calculated: Loaded Weight − Offloaded Weight − (Transport Weight × Loss Tolerance %). If the result is positive, transport loss exists above the tolerance threshold.
- Load allocations are recalculated — both purchase and sales Estimate Qty and Delivered Qty are updated. The Delivered Qty on purchase allocations uses the loaded weight (adjusted), while sales allocations use the offloaded weight (adjusted), depending on the Weight Liability Transfer setting on the contract.
- Storage Paid From and Storage Paid To are defaulted to Date Offloaded if not already set.
- For Inbound non-certificate loads, Pay Handling Fee is set to true.
- Load Status advances to Offloaded.
- For Inbound and Outbound loads: all allocation Delivery Dates are set to the Date Offloaded.
- Purchase and Sales Orders are re-posted with the updated quantities.
- An Inventory Adjustment is posted if the net quantity invoiced differs from what was received or shipped — this reconciles in-transit gains or losses.
The Offloaded Adjustment Factor and Offloaded Adjustment Qty work identically to the loaded equivalents.
Stage 5 — Grading: Attribute Values
The Grading action opens the Load Attribute Editor where the coordinator enters the measured attribute values for the load (moisture, protein, screenings, etc.). After the grading screen is closed:
- Mass Adjustment Factors are recalculated from the attribute values against the relevant Attribute Mass Adjustment Tables, updating the Loaded and Offloaded Adjustment Factors on the load.
- Attribute Premiums on all load allocations are recalculated, updating the financial settlement values per allocation.
- Allocation quantities (Delivered Qty) are recalculated to reflect the updated mass adjustments.
Grading can be done at any stage — before or after weights are entered — but is most meaningful once actual weights exist.
Stage 6 — Finalising for Invoice
Once the coordinator is satisfied that weights, variants, and grading are correct, they tick Final to Invoice Purchase and/or Final to Invoice Sales. This is the signal that the load is ready for financial processing.
Before the flag is accepted, the system validates:
- Vendor (purchase) or Customer (sales) is set
- Location Code is set
- Required weights are present (Offloaded Weight for Inbound; Loaded Weight for Direct)
- Dimensions are populated if mandatory
- Variants are set if mandatory
Ticking Final to Invoice also:
- Locks the weight and variant fields — they become non-editable once this flag is set (for the relevant side)
- Locks the Location Code — cannot be changed after either Final to Invoice flag is ticked
- Posts a final Inventory Adjustment to reconcile the BC inventory to the actual net quantity
Stage 7 — Invoicing
The coordinator can invoice from the Load Card using Invoice Load, which processes all allocations on the load in one action. The system generates separate purchase and/or sales invoices per contract schedule allocation, based on the delivered quantities and contract schedule pricing (Price + Basis + Spread, adjusted for Variant Discounts and Attribute Premiums).
Alternatively, invoicing can be done allocation-by-allocation from the Load Contract Allocations subpage using Invoice Allocation, or schedule-by-schedule from the Contract Card.
The Metrics section of the Load Card provides a real-time summary of all these transactions, with quantities highlighted in red whenever a discrepancy exists between what CommLinc expects and what has been posted to BC inventory.
Stage 8 — Transport Invoicing
Transport invoicing is separate from commodity invoicing and is built around the principle of reconciling the transporter's actual invoice against what CommLinc expects to pay.
Transport Invoice Fields — Two Separate Purposes
The Transporter section of the Load Card carries two distinct categories of figures that serve different purposes:
CommLinc's calculated figures — used to generate the transport Purchase Invoice:
- Transport Weight — the weight CommLinc uses to determine what is payable. Defaults to Loaded Weight but can be overridden (e.g. when liability transfer occurs at offloading).
- Freight Rate — the agreed rate per unit of measure. This is the rate that CommLinc invoices at.
The transporter's claimed figures — recorded for reconciliation and remittance, but not used in the invoice calculation:
- Transporter Invoice No., Date, Due Date — the transporter's own invoice reference and payment terms.
- Transporter Invoice Weight — what the transporter claims was transported.
- Transporter Invoice Rate — the rate the transporter applied on their invoice.
The purpose of recording the transporter's claimed figures is to enable the coordinator to send a detailed remittance to the transporter explaining exactly how CommLinc calculated the payment — and why it may differ from what the transporter claimed.
Invoice Transport
The Invoice Transport action creates or updates a Purchase Invoice to the Transporter. It is enabled when:
- A Transporter is set on the load
- The load has a Transport Weight > 0
- Transport is payable (Outbound or Direct loads; or Inbound loads where Pay Inbound Transport is ticked)
- The transport has not already been fully invoiced (Transport Invoice Qty < Transport Weight)
- The Transporter Invoice No. is filled in — this is required so the system can match or create the correct invoice header
The system looks for an existing open Purchase Invoice to the Transporter with the same Vendor Invoice No. If one exists, the current load's line is added to it — this allows multiple loads covered by the same transporter invoice to accumulate on a single BC Purchase Invoice. If no matching open invoice exists, a new one is created.
The invoice line is built using CommLinc's own figures, not the transporter's claimed amounts:
- Quantity = Transport Weight (CommLinc's weight) minus any already-invoiced quantity
- Unit Price = Freight Rate (the agreed CommLinc rate)
- Item = the Transport Item defined on the commodity's Item record
The invoice header uses the transporter's dates for payment processing:
- Posting Date / Document Date = Transporter Invoice Date
- Due Date = Transporter Invoice Due Date
A comment line is added to the invoice recording the load number, vehicle registration, and loading date for remittance and audit purposes.
Invoice Transport Loss
Invoice Transport Loss creates a Sales Invoice for any transport loss that exceeds the tolerance threshold. It is enabled when Transport Loss > Transport Loss already invoiced. The invoice is raised to the Transporter Customer — the Customer record linked to the Transporter Vendor — allowing the transport loss recovery to flow through standard BC accounts receivable.
Load Card
The Load Card is a comprehensive management portal for loads. Besides capturing of loads the Load Card has the following features:
Generate Transport Order, used to generate the Purchase Order for the transporter in the instances where transport is due on the load.
Generate Purchase Order, used to generate a Purchase Order for inventory in the case of Direct and Inbound Loads.
Generate Sales Order, used to generate a Sales Order for inventory in the case of Direct and Outbound loads.
Invoice Load, used to generate Purchase and Sales Invoices from the Contract Schedule Load Allocations.
Grade Load, used to capture the grading attributes of the load. The grading attributes are used to calculate Load Mass Adjustments and Load Attribute Value Adjustments
Print and/or Email Load Confirmations.
Route information, displays the route between loading and offloading points using the mapping tool setup in Business Central, e.g. Google Maps.
Allocate loads to Contracts in the Load Allocation section.
Allocate loads to Load Instructions in the Load Instruction Allocation section.
Display load metrics in the Metrics section.
The Load Card consists of eight different sections namely:
- General,
- Commodity,
- Shipping,
- Transporter,
- Load Details,
- Load Contract Allocations,
- Load Instruction Allocations, and
- Metrics
each of which is discussed below.
Load General
No. is a system generated sequence number.
Load Type indicates what type of load it is, options are Inbound, Outbound and Direct.
Transport Method is a CommLinc feature, Transport Method used to describe the type of transport and its associated attributes. Attributes such as Load Rate (indicating a load price or a per unit price) , Loss Tolerance %, Certificate Transfer and the different Item Charges for transport based on Item Category for In and Outbound transport.
Load Status is automatically updated based on the loads state. Options include: Estimate, Loaded, Offloaded, Invoiced and Cancelled.
Scheduled Date is intended to indicate the date the load is scheduled to load.
Shipment Methods related to standard Business Central Inco Terms.
Shipment Reference is a free text intended as a cross reference to external systems.
Sales Person relates to the Business Central Salesperson/Purchaser code.
Dimension Code 1 in this instance defined as Trading Desk, but could be defined as per Business Central Dimension Code functionality.
Dimension Code 2 in this instance defined as Primary Contract Code, but could be defined as per Business Central Dimension Code functionality.
Purchase Order references the Purchase Order related to the load.
Sales Order references the Sales Order related to the load.
Transport Order references the Transport Order related to the load.
Transport Loss Invoice No. references the "Transport Loss Sales Invoice" generated for any eventual transport losses.
Load Commodity
In CommLinc Commodities are stored in the Item Table of the Inventory Module. The word Commodity, Item and Product are used interchangeably.
Item references the Item Code of the commodity to be transported on the load.
Item Description is a display field showing the selected Item Description.
Location Code references the stock keeping location of the commodity.
Location Description is a display field showing the name of the location selected.
Load Shipping
Shipping consists of two columns containing Ship From and Ship To Address details. For Inbound loads Ship From is enabled, for Outbound loads Ship To is enabled and for direct loads both are enabled. Values default from Customer and Vendor default addresses, but can be modified.
Ship From relates to the Vendor supplying the commodity. Selecting the Ship-from Vendor defaults the address from the vendor's primary address. If the vendor has pre-defined Order Addresses (alternate shipping points), a Shipping Code field is available to select one — choosing it replaces all Ship From address fields with the details from that order address.
Ship To relates to the Customer purchasing the commodity. Selecting the Ship-to Customer defaults the address from the customer's primary address. If the customer has pre-defined Ship-to Addresses, a Shipping Code field is available to select one — choosing it replaces all Ship To address fields accordingly.
Load Transporter
The Transport Section is hidden if the checkbox Certificate Transfer on the Transport Method table is checked.
Transporter relates to the Vendor code of the transporter transporting the load.
Transporter Name is a display field displaying the name of the selected Vendor.
Contact No. is the code relating to a Vendor Contact.
Contact is a display field displaying the name of the selected Vendor Contact.
Freight Rate is the agreed rate per Unit of Measure or the fixed rate per load. Load rate is applied if the checkbox Load Rate on the Transport Method table is checked.
Pay Inbound Transport checkbox is used to indicate that Inbound Transport should be paid on the load.
Transport Weight defaults from the weight loaded, but may be overridden if required.
Transport Loss is calculated as: Loaded Weight − Offloaded Weight − (Transport Weight × Loss Tolerance % from the Transport Method). The calculated value can be overridden. When Transport Loss is greater than zero the user is prompted to generate a Sales Invoice for the loss quantity, posted against the Customer record linked to the Transport Vendor — this is the mechanism by which in-transit losses are recovered from the transporter.
Transporter Invoice No., Transporter Invoice Date, Transporter Invoice Due Date, Transporter Invoice Weight, and Transporter Invoice Rate are the details of the transporter's invoice. Any change to these fields on an existing record deletes the previously generated unposted Purchase Invoice so that it can be regenerated with the updated values.
Transport Item No. specifies the Item used to create the transport Purchase Invoice line. Changing this field also deletes any existing unposted transport Purchase Invoice.
The Transporter section is hidden entirely when the Certificate Transfer checkbox is ticked on the Transport Method, as no physical transport is involved.
Load Details
The details section of the page is used to record weights and grades information related to the load.
Estimate Weight is defaulted from the Default Estimate Weight field on CommLinc Setup table. The Estimate Weight is used as the Purchase and Sales Order Quantity if there are no Loaded or Offloaded weights available.
Loaded Weight indicates the weight loaded.
Date Loaded is the date upon which the load was physically loaded.
Offloaded Weight indicates the weight offloaded.
Date offloaded is the date upon which the load was physically offloaded.
Load Adjustment Factor is calculated by totaling any mass adjustments derived from the combination of the loads grading attributes and the relevant Attribute Mass Adjustment Tables.
Offload Adjustment Factor is calculated by totaling any mass adjustments derived from the combination of the loads grading attributes and the relevant Attribute Mass Adjustment Tables.
Grading Attribute Values
When the Grade Load action is used, a grading screen allows attribute values to be captured for the load. Each attribute row stores a Loaded Value and an Offloaded Value separately. If Loaded Value is left at zero, the system uses the Offloaded Value as the fallback when calculating the load-side adjustment factor — a blank Loaded Value does not mean no adjustment, it means the offloaded reading is applied to both sides.
Each attribute row also carries its own Loaded Adjustment Table and Offloaded Adjustment Table codes. These default from the Item/Location mass adjustment table setup, or from the contract-level Mass Adjustment Attributes if the load is allocated to a contract. They can be inspected and overridden directly on the grading record if a specific load requires a different table than the default.
Loaded Variant the Commodity Grade of the load at time of loading, represented in Business Central as an Item Variant.
Offloaded Variant the Commodity Grade of the load at time of offloading, represented in Business Central as an Item Variant.
Final to Invoice Purchase and Final to Invoice Sale are control indicators for the user to indicate that the load is ready for purchase and sales invoicing respectively.
Storage Paid To is the date until which storage has been paid at the storage location. The lookup prompts whether this is Year Storage; if confirmed, the period is automatically set from Date Offloaded to the Season end date for the commodity.
Weight Cascade Rules
Weight fields flow into one another automatically:
- When Loaded Weight is entered and Offloaded Weight is zero: Estimated Weight is set equal to Loaded Weight.
- When Offloaded Weight is entered: Estimated Weight is updated to Offloaded Weight. If Loaded Weight is zero, it is also set to the Offloaded Weight.
- When Estimated Weight changes (and neither Loaded nor Offloaded Weight has been captured): Estimate quantities on all load allocations and load instructions are recalculated.
Any change to Loaded or Offloaded Weight triggers a recalculation of load allocation quantities, load instruction quantities, and inventory adjustments.
Date Rules
- Date Loaded cannot be edited after any allocation on the load has been invoiced.
- If Date Offloaded is earlier than Date Loaded when Date Loaded is set, Date Offloaded is cleared.
- For Direct loads: all load allocation Delivery Dates are set to the Date Loaded.
- For all other load types: load allocation Delivery Dates are set to the Date Offloaded.
- When Date Loaded or Date Offloaded is updated, open Purchase and Sales Orders are re-posted with the new date.
Final to Invoice — Validation Rules
Ticking Final to Invoice Purchase validates the following before allowing the change:
- If Dimension 1 Mandatory on Load is set in CommLinc Setup: Dimension 1 must be populated on the load and on every purchase allocation.
- If Dimension 2 Mandatory on Load is set: Dimension 2 must be populated on the load and on every purchase allocation.
- Ship-from Vendor must be set.
- Location Code must be set.
- For Inbound loads: Offloaded Weight must be > 0. For Direct loads: Loaded Weight must be > 0.
- If the Item has mandatory variants: both Loaded and Offloaded Variants must be valid.
- If no Purchase Order exists, one is automatically generated.
- If the Received Quantity on the Purchase Order differs from the Net Purchase Allocation Qty, the user is prompted to re-post the Purchase Order to correct it.
- An Inventory Adjustment is posted to reconcile stock.
Ticking Final to Invoice Sales validates:
- Dimension 1 and 2 (same rules as purchase, applied to sales allocations).
- Ship-to Customer must be set.
- Location Code must be set.
- Offloaded Weight must be > 0.
- If Item has mandatory variants: Loaded and Offloaded Variants must be valid.
- If no Sales Order exists, one is automatically generated.
- If Shipped Quantity differs from Net Sales Allocation Qty, the user is prompted to re-post the Sales Order.
- An Inventory Adjustment is posted to reconcile stock.
Load Contract Allocations
Through Load Contract Allocations, Loads are connected to Contracts, allowing for calculation of financial settlement values. Invoicing of loads in CommLinc is derived from the information in the allocations table. A load can be allocated to many contract schedules through allocations.
Inbound loads can be allocated to Purchase Contracts, outbound loads to Sales Contracts, and direct loads to both Purchase and Sales Contracts. By selecting Apply to Contract, CommLinc will allocate the load to the selected Contract's Schedules based on the principle of filling the oldest schedule first. By selecting Apply to Contract Schedule, the user has more control over which Contract Schedule to apply the load to. By default, only contract schedules that match the primary information on the load are displayed: Commodity, Customer/Vendor, Location and schedule Status. To select Contract Schedules outside this range, the user can clear the filters to display more schedules.
Transaction Type identifies the contract schedule as a Purchase or Sales Schedule.
Contract No. identifies the selected Contract.
Schedule No. identifies the selected Contract Schedule.
Contract Name is the name of the counterparty on the contract.
Item and Variant indicates on what Item and Variant the contract price is based.
Season identifies the season indicated on the contract schedule, season is used in conjunction with Variant Value Adjustment Tables and Attribute Value Adjustment Tables to calculate Variant Discounts and Attribute Premiums.
Estimate Qty indicates the initial estimation prior to loading.
Delivered Qty is the Net Quantity to delivered after any mass adjustments due to grading attribute values or farm delivery adjustments etc.
Net Price is price per unit of measure derived from the Contract Schedule.
Variant Discount is the difference in the value of the contracted grade and the delivered grade, calculated using season and Variant Value Adjustment Tables.
Attribute Premium is a premium paid based on the values captured in the grading factors and the Attribute Value Adjustment Tables to calculate Variant Discounts and Attribute Premiums.
Invoiced Qty is the sum of invoices linked to the load contract allocation. Once a load has been invoiced it can not be changed.
Allocation Validation Rules
The following conditions are enforced when allocating a load to a contract schedule:
- The Item on the load must match the Item on the contract.
- For Purchase allocations: the Ship-from Vendor on the load must match the contract Counterparty.
- For Sales allocations: the Ship-to Customer on the load must match the contract Counterparty.
- The contract schedule Pricing Status must permit allocation (see Pricing Status setup).
- For Purchase allocations: the Transport Method on the load must match the Transport Method on the contract schedule.
- The target contract must be in Approved status.
When Apply to Contract is used, the load is allocated to open schedules in Allocation Order sequence, filling each schedule to capacity before moving to the next. Schedules that are already fully delivered or whose Pricing Status blocks allocation are skipped. If a message is shown after allocation, it indicates a net quantity that could not be accommodated on any available schedule.
When Apply to Contract Schedule is used, the filters on the lookup default to schedules matching the load's Item, Counterparty, Location, and open status. Clearing the filters exposes all open schedules.
Delivered Quantity Calculation
The Delivered Qty on a load allocation represents the net commodity quantity after mass adjustments. The calculation depends on the Weight Liability Transfer setting on the contract:
- If Loaded: uses Loaded Weight × (1 − Load Adjustment Factor)
- If Offloaded: uses Offloaded Weight × (1 − Offload Adjustment Factor)
The Delivered Qty cannot be set below the Invoiced Qty on that allocation.
Load Instruction Allocations
Load Instructions are used to track stock placed on out loading as 3rd party storage facilities.
Load Instruction No. is the selected load instruction.
Instruction Date is the date the product was placed on Load Instruction.
Instruction Variant is the default grade associated with the instruction.
Quantity Allocated represents the quantity of this load that is allocated to the instruction.
Loaded Quantity sums the total quantity already loaded on the instruction.
Remaining quantity shows the balance available in the instructions.
Load Metrics
Load Metrics provide a bird's-eye view of the transactions related to the load.
The Load Metrics section is divided into three columns: Purchase, Sales and Stock.
Purchase column sums the allocation of the load to Purchase Contracts, including Estimate Qty, Delivered Qty and Invoiced Qty.
Sales column sums the allocation of the load to Sales Contracts, including Estimate Qty, Delivered Qty and Invoiced Qty.
Stock column sums the values on Purchase and Sales Orders affecting stock, including:
Received Qty, the quantity receipted on the related Purchase Orders.
Shipped Qty, the quantity shipped on the related Sales Order.
Positive Inventory Adjustment Qty, sums positive inventory adjustments related to the load (in transit gains).
Negative Inventory Adjustment Qty, sums negative inventory adjustments related to the load (in transit losses).
Load Instruction Qty, sums the quantity allocated to Load Instructions.
API Integration
Why API Integration Matters
CommLinc manages commodity trading through Business Central, but a trading operation rarely lives in one system. Weighbridges, grain portals, grading laboratories, pricing engines, e-signature platforms, and producer portals all generate data that ultimately needs to reach CommLinc — and CommLinc data needs to flow out to counterparty systems, reporting platforms, and mobile applications.
Without an API, that data crosses system boundaries through manual re-keying: an operator reads a weighbridge ticket, types the weight into CommLinc, and hopes they didn't misread the slip. With the API, the weighbridge application writes the loaded weight directly to the load record the moment the vehicle leaves the scale. The result is faster data, fewer transcription errors, and an unbroken audit trail from the physical event to the financial transaction.
The CommLinc API makes the following integration patterns practical without custom development on the Business Central side:
- Inbound data capture — external systems (weighbridges, grading labs, farm portals) create or update loads, load weights, grading attributes, and futures trades directly.
- Contract management — a web portal or mobile app can create, read, and update contracts and schedules on behalf of traders who are away from the desk.
- Reference data sync — items, variants, locations, seasons, and pricing structures maintained in CommLinc are available to downstream systems without a full BC integration.
- Reporting and analytics — a data warehouse or BI tool can pull load allocations, item ledger entries, and contract metrics on a schedule without screen-scraping or file exports.
- Document attachment — signed contract PDFs from an e-signature platform are pushed directly onto the contract record via the attachment fields.
How Business Central Custom APIs Work
CommLinc's API is implemented as a set of Business Central custom API pages, exposed through the standard OData v4 endpoint that Business Central provides for all custom API integrations. Authentication uses OAuth 2.0 with Microsoft Entra ID, the same identity platform that secures the Business Central web client.
For a full explanation of authentication, permissions, filtering syntax, and OData conventions, refer to the official Microsoft documentation:
Base URL
All CommLinc API endpoints share the following base URL structure:
https://api.businesscentral.dynamics.com/v2.0/{tenantId}/{environmentName}/api/linc/commLinc/v2.0/companies({companyId})/
| Segment | Description |
|---|---|
{tenantId} |
Your Microsoft Entra tenant ID |
{environmentName} |
The Business Central environment name (e.g. Production, Sandbox) |
{companyId} |
The GUID of the company within BC |
Example — retrieving all open contracts:
GET .../api/linc/commLinc/v2.0/companies({companyId})/contracts?$filter=contractStatus eq 'Open'
Available Endpoints
Core Transactional Endpoints
These endpoints represent the primary CommLinc documents. All use SystemId as the OData key.
| Entity Set | Entity | GET | POST | PATCH | DELETE | Notes |
|---|---|---|---|---|---|---|
contracts |
contract |
✓ | ✓ | ✓ | — | Can $expand=contractSchedules,contractAttributeMassAdjustments |
contractSchedules |
contractSchedule |
✓ | ✓ | ✓ | — | Can $expand=contractSchedulePrices,contractScheduleBases. Available standalone and nested under contracts |
contractSchedulePrices |
contractSchedulePrice |
✓ | ✓ | ✓ | — | Futures trade pricing allocations per schedule |
contractScheduleBases |
contractScheduleBasis |
✓ | ✓ | ✓ | ✓ | Basis element lines per schedule |
contractAttributeMassAdjustments |
contractAttributeMassAdjustment |
✓ | ✓ | ✓ | — | Contract-level mass adjustment table overrides |
loads |
load |
✓ | — | ✓ | — | Loads are created through CommLinc only; see bound action below |
loadAllocations |
loadAllocation |
✓ | — | — | — | Read-only; allocations are managed through CommLinc |
futuresTrades |
futuresTrade |
✓ | — | — | — | Read-only; trades are imported via CommLinc |
futuresContracts |
futuresContract |
✓ | ✓ | ✓ | ✓ | Futures delivery months |
Reference and Setup Endpoints
These endpoints expose CommLinc master data for synchronisation with external systems.
| Entity Set | Entity | GET | POST | PATCH | DELETE | Notes |
|---|---|---|---|---|---|---|
items |
item |
✓ | ✓ | ✓ | ✓ | Can $expand=itemVariants |
itemVariants |
itemVariant |
✓ | ✓ | ✓ | ✓ | Available standalone and nested under items |
attributes |
attribute |
✓ | ✓ | ✓ | ✓ | Item grading attributes |
itemLedgerEntries |
itemLedgerEntry |
✓ | — | — | — | Read-only stock movement history |
locations |
location |
✓ | ✓ | ✓ | ✓ | Stock locations |
traders |
trader |
✓ | ✓ | — | — | Salesperson/Purchaser records |
seasons |
season |
✓ | ✓ | ✓ | ✓ | Commodity seasons |
pricingStatuses |
pricingStatus |
✓ | ✓ | ✓ | ✓ | Schedule pricing status codes |
packagingTypes |
packagingType |
✓ | ✓ | ✓ | ✓ | Packaging type codes |
basisElements |
basisElement |
✓ | ✓ | ✓ | ✓ | Basis element definitions |
variantAdjustmentTables |
variantAdjustmentTable |
✓ | ✓ | ✓ | ✓ | Can $expand=variantAdjustmentMatrices |
variantAdjustmentMatrices |
variantAdjustmentMatrix |
✓ | ✓ | ✓ | ✓ | Grade discount/premium matrix rows |
attributeMassAdjustments |
attributeMassAdjustment |
✓ | ✓ | ✓ | ✓ | Attribute mass adjustment table definitions |
Bound Actions
Bound actions are OData operations that execute business logic and cannot be expressed as a simple data write.
| Entity | Action | Method | Description |
|---|---|---|---|
load |
Microsoft.NAV.CreateTransportInvoice |
POST | Validates the load's transport details (Transporter Invoice No. required, Transport Weight > 0) and creates or updates the transport Purchase Invoice in Business Central. |
Example call:
POST .../api/linc/commLinc/v2.0/companies({companyId})/loads({systemId})/Microsoft.NAV.CreateTransportInvoice
Body: {}
Document Attachments via API
The contracts endpoint supports uploading a document attachment via PATCH. Supply three fields alongside the update:
| Field | Description |
|---|---|
attachment |
Base64-encoded file content |
attachmentFileName |
File name including extension (e.g. Contract_001.pdf) |
attachmentFileExtension |
File extension only (e.g. pdf) |
The attachment is stored on the contract record and appears in the standard Business Central document attachments factbox. This is the integration point for e-signature platforms that need to deposit a signed contract PDF back into CommLinc after signing is complete.
Reports
Contract Summary
The Contract Summary is a Word-format report that provides a comprehensive view of a contract and its schedules. It can be printed or attached as a PDF directly from the Contract Card.
Report filters: Standard Business Central filters on the Contract table — filter by contract number, counterparty, item, transaction type, or any combination.
Contract header section shows: Contract No., Date, Transaction Type, Item, Counterparty (including address and contact), Currency, Payment Terms, Weight and Grade Liability Transfer, and summary quantities:
- Contract Qty = Quantity + Adjusted Qty across all schedules
- Delivered Qty = sum of delivered quantities from load allocations
- Remaining Qty = Contract Qty − Delivered Qty
- Hedged Qty = Hedged Qty + Hedged Adjusted Qty across all schedules
- Invoice Qty = total invoiced from value entries
Schedule detail section shows per schedule: Schedule No., Location, Delivery Date From/To, Qty, Hedged Qty, Unit Price, Basis, Spread, and:
- Net Price = Unit Price + Basis + Spread
- Remaining Qty = Schedule Qty − Delivered Qty
Pricing lines per schedule show each futures trade allocation: Trade Date, Futures Contract, Allocated Quantity, Adjusted Allocation, Net Quantity (Qty + Adjusted), Allocation Price, Option Premium, and Strike Price.
Load allocation lines per schedule show each load: Load No., Dates Loaded/Offloaded, Vehicle Registration, Shipment Reference, Grade, Gross Mass, Mass Adjustments, Net Mass (Delivered Qty), and Invoice reference numbers. Per-attribute grading factors and their mass adjustment contributions are also listed.
Contract Schedule Pricing Summary
The Contract Schedule Pricing Summary report details the pricing elements of contract schedules, including the base futures price, basis elements, spread values, and the resulting net price. It is useful for reviewing the pricing status of open contracts and for reconciling prices with counterparties.
Load Inventory Summary
The Load Inventory Summary is an Excel-format report that reconciles physical load weights against Business Central inventory postings.
Report filters: Load Date From, Load Date To (defaults to the last day of the current month).
Per load the report shows:
- Load type, status, item, dates, location, variants, loaded and offloaded weights, adjustment factors
- Received Qty — quantity posted to BC inventory via Purchase item ledger entries
- Shipped Qty — quantity removed from BC inventory via Sales item ledger entries
- Inventory Adjusted Qty — net of positive and negative inventory adjustments posted for the load
- Net Inventory Qty = Received + Shipped + Adjusted (signs as per BC conventions)
- In-Transit Qty — the difference between the quantity that should be in transit (allocatable purchase minus allocatable sales) and what has actually been received and shipped. A non-zero value indicates a discrepancy between physical movements and inventory records.
- Received/Shipped/Adjusted variant codes and locations are shown as comma-separated lists from the actual item ledger entries, allowing identification of which grades and locations were posted.
- Final to Invoice Purchase and Final to Invoice Sales flags.
Load Invoice Summary
The Load Invoice Summary is an Excel-format report that provides a detailed breakdown of invoicing per load and per contract schedule allocation.
Report filters: Load Type (optional — leave blank for all types), Load Date From, Load Date To (defaults to last day of current month).
The report has two levels:
Load row shows all load-level data: type, status, item, dates, weights, variants, adjustment factors, ship-from vendor, ship-to customer, transporter, freight rate, vehicle registrations, references, inventory quantities (received, shipped, net purchase/sales, invoiced, inventory adjustments), transport invoice details, advance invoice amounts, and dimensions.
Allocation row shows per contract allocation: Contract No., Schedule No., stock and basis location, item, variant, Schedule Price, Basis, Spread, Net Price (= Price + Basis + Spread), Pricing Date (date of the most recent futures trade allocation), Average Price (weighted average of futures trade prices), Delivered Qty, Invoiced Qty, purchase and sales invoice numbers with posting dates, Variant Discount, Attribute Premium, dimension codes, advance invoice and credit note quantities and amounts.
Each basis element defined in the system appears as a separate column on the allocation row, allowing full basis reconciliation per allocation.
Transport section on the load row includes: whether transport is payable, transport invoice quantities, transport invoice numbers with posting and due dates, transporter's invoice number, and transport loss invoice number.
Position Report
The Position Report summarises the company's open commodity position by netting purchase and sales contract quantities against delivered and invoiced quantities. It provides risk managers with an overview of open long and short positions and the extent to which those positions are covered by futures hedges.