Definitions

We must make a clear difference between Contract, Trading File and Blanket Order.

Contract

A Contract is a formal document that represents a signed/approved agreement between two parties (Vendor/Customer). In Dynamics 365 Business Central following documents can be seen as contracts: Sales order, Purchase order, Sales blanket order, Purchase blanket order.

Blanket Order

A Blanket Order is a Contract from a formal perspective. Blanket Order, represents a framework for a long-term agreement between two parties: a company and their Customer/Vendor.

A blanket order is mainly used when a Customer has committed to purchase large quantities of an item that will be delivered in several smaller shipments over a certain period of time. Often blanket orders cover only one item with predetermined delivery dates.

The main reason for using a blanket order rather than a sales order is that quantities entered on a blanket order do not affect item availability and thus can be used as a worksheet for monitoring, forecasting, and planning purposes.

Unlike the Trading File, a blanket order only reflects sales or purchase agreements, not a consolidated view of Sales and Purchases.

Trading File

When we talk about Trading File in the following document, we talk about an entity that groups sales and purchase documents that are related to a specific deal. This is actually not a Contract as it is not signed/approved by third parties. From a generic perspective a Trading File can be seen as an analytical container that will be used to consolidate all figures related to the same deal.

A Trading File can therefore consolidate one or several Contracts (sales documents - these includes Sales Blanket Order but also Sales Order, Sales Invoice, Sales Return Order, and Sales Credit Memo) and one or several purchase documents (These include Purchase Blanket Order, Purchase Order, Purchase Invoice, Purchase Return Order, Purchase Credit Memo).

The information (in particular analytical dimensions) set in Trading File will be inherited in the related documents, providing an ability to consolidate data using the contract card/list or using financial reports (as Account Schedules) or possibly PowerBi reports.

Trading Files will be created when planning a deal. In these cases, the Trading File manager fill the Trading File with any relevant information (Description, Start Date, End Date, main Customer, etc.) for operational handling and follow-up and also define applicable Dimensions/ Dimension values for that Trading File.

It is possible to include envisioned (budgeted) revenue, cost and margin for later check and analysis.

It will also be possible to create a Sales/Purchase document and manually assign a Trading File to it. Dimension/Dimension Values will be inherited from the Trading File.

Creating a Sales/Purchase document related to a Trading File will update the ongoing revenue/cost and margin for the Trading File, making it possible to have a check on the Budget vs Work in Progress (WIP). Once documents are posted, the actual numbers will be reflected in the Trading File to have a view of Budget vs WIP vs Actuals.

A Trading File can be driven by Sales or driven by Purchase. When driven by Purchase, it means that the triggering event is the creation of a Purchase document and therefore Trading File will be related to a Vendor.

When driven by Sales, it means that the triggering event is the creation of a Sales document and therefore Trading File will be related to a Customer.

Trading Files may have associated Customer/Vendor No. These ones would be used for informational purposes and to create new related documents. However, a Trading File can contain Sales/Purchase orders from different Customers/Vendors. An example for that would be a trading commodity company that would buy 250 tons of grains on the commodity exchange and sell it to ten different Customers.

A Trading File can contain several item lines. For each of these lines a budget will be defined.

Previous
Next