ITSA Workflow
This commit is contained in:
AzureAD\SylvainDUVERNAY
@@ -20,10 +20,10 @@ this repository contains the full copyright notices and license terms. -->
|
||||
<field name="act_window" ref="act_tradon_processes"/>
|
||||
</record>
|
||||
<record model="ir.action.act_window" id="act_itsa_operations_workflow">
|
||||
<field name="name">ITSA Operations Workflow</field>
|
||||
<field name="name">Interacid Practice Book</field>
|
||||
<field name="res_model">purchase_trade.process.documentation</field>
|
||||
<field name="context" eval="{
|
||||
'process_documentation_html': 'ITSA/Operations_Workflow.html',
|
||||
'process_documentation_html': 'ITSA/Interacid_Tradon_Practice_Book.html',
|
||||
}" pyson="1"/>
|
||||
</record>
|
||||
<record model="ir.action.act_window.view"
|
||||
@@ -47,7 +47,7 @@ this repository contains the full copyright notices and license terms. -->
|
||||
id="menu_tradon_processes"/>
|
||||
|
||||
<menuitem
|
||||
name="ITSA Operations Workflow"
|
||||
name="Interacid Practice Book"
|
||||
parent="menu_help_processes"
|
||||
action="act_itsa_operations_workflow"
|
||||
sequence="20"
|
||||
|
||||
@@ -0,0 +1,212 @@
|
||||
# Practice Book Generation Guideline
|
||||
|
||||
A reusable specification for producing **ERP "Practice Book" user manuals** for commodity
|
||||
trading clients, derived from two reference documents:
|
||||
|
||||
- *Trading, Middle Office and Derivatives Practice Book* (front-office)
|
||||
- *Shipping Practice Book v2* (operations / back-office)
|
||||
|
||||
Use this guideline as the blueprint when generating an equivalent document for **another
|
||||
customer, another commodity set, or a different workflow** (and, where relevant, a
|
||||
different ERP such as Tryton instead of iRely).
|
||||
|
||||
---
|
||||
|
||||
## 1. Purpose of these documents
|
||||
|
||||
A Practice Book is a **"to-be" operational manual**. It is *not* generic vendor software
|
||||
documentation. Its job is to tell a specific client's staff **how their business is to be
|
||||
run inside the configured ERP**, step by step, screen by screen.
|
||||
|
||||
Each book has a clear scope along the trade lifecycle:
|
||||
|
||||
| Book | Scope | Primary audience |
|
||||
|------|-------|-----------------|
|
||||
| **Trade / Middle Office / Derivatives** | Front office: contract capture, pricing, FX fixation, cost budgeting, hedging, broker reconciliation, market exposure, allocation, sales | Traders, Trader Assistants, Market Risk / Derivatives Desk, Finance |
|
||||
| **Shipping / Logistics** | Back office: logistics flows, shipping instructions, load shipment, inventory receipt, vouchers, invoicing, exception handling | Operations, Logistics, Trader Assistants, Finance |
|
||||
|
||||
**Defining characteristics to reproduce:**
|
||||
- Written in the client's own vocabulary and entity names (companies, commodities, ports, banks).
|
||||
- Describes the agreed *target process*, including explicit decisions made during implementation ("we have decided to…", "for simplicity we keep…").
|
||||
- Heavily screenshot-driven: every action is illustrated with an annotated capture of the real configured system.
|
||||
- Honest about gaps: carries open questions, "to be confirmed", and vendor action tags inline.
|
||||
- Organised lifecycle-first (follow the goods/contract from creation to settlement), not feature-first.
|
||||
|
||||
---
|
||||
|
||||
## 2. Document structure (section template)
|
||||
|
||||
Reproduce this skeleton. Sections marked **[shared]** are written once and reused
|
||||
verbatim across every book for the same client.
|
||||
|
||||
```
|
||||
Title page — Client / workflow name
|
||||
Contents — Auto-generated TOC with page numbers
|
||||
|
||||
1. Fundamentals & glossary [shared]
|
||||
- Company / Location and Line of Business
|
||||
- Contract pricing types (e.g. Priced vs Basis)
|
||||
- Contract sequences (multi-line contracts) + any limits agreed
|
||||
- Contracts budget & costs (route / cost-matrix concept)
|
||||
- Contract items (product catalogue philosophy)
|
||||
- Price fixations & hedging (one-liner overview)
|
||||
- Hedging & broker reconciliations (overview)
|
||||
- Allocations & reservations (overview)
|
||||
- Logistics flows (Inbound / Outbound / Drop Ship / Transfer)
|
||||
- Key process names (Shipping Instruction, Load Shipment, Inventory Receipt …)
|
||||
- System-specific term mapping (e.g. "Voucher vs Invoice")
|
||||
|
||||
2. Main subject chapters (lifecycle-ordered)
|
||||
- Each major process = a chapter
|
||||
- Each chapter = intro paragraph + numbered/illustrated steps
|
||||
- Field-reference tables for every data-entry screen
|
||||
|
||||
3. Worked scenarios
|
||||
- One "base scenario" (happy path), fully illustrated end to end
|
||||
- Labelled variants of the base scenario
|
||||
e.g. "Variant-2 (Location: X, Commodity: Y)"
|
||||
- Miscellaneous / exception flows (rejections, claims, transhipment …)
|
||||
- Optionally: "Scenarios that will not happen / for later phases"
|
||||
|
||||
4. Appendix
|
||||
- Overview diagram(s) of end-to-end flow
|
||||
- Cross-reference table (e.g. helpdesk / ticket references)
|
||||
- Footnotes collected from the body
|
||||
```
|
||||
|
||||
> The two reference books deliberately **share section 1 verbatim**. Keep this discipline:
|
||||
> write the fundamentals once per client and paste identically into each book so staff get
|
||||
> the same grounding regardless of which manual they open.
|
||||
|
||||
---
|
||||
|
||||
## 3. Content building blocks (the repeatable units)
|
||||
|
||||
### 3.1 Field-reference table
|
||||
Used for every data-entry screen. The leading number ties each row to a numbered red
|
||||
callout on the adjacent screenshot.
|
||||
|
||||
```
|
||||
| # | Attribute | Description |
|
||||
| - | --------- | ----------- |
|
||||
| 1 | <Field> | What it is, how it is used, who fills it, defaulting rules, worked example |
|
||||
```
|
||||
|
||||
Rules:
|
||||
- Descriptions are **operational**, not just definitional — say *who* enters it, *when*, *why*, and any calculation. Long cells with embedded examples are normal and expected.
|
||||
- Use a `???` / `@vendor: to complete` placeholder for fields not yet finalised rather than omitting the row.
|
||||
- Keep field labels in **bold** when referenced in prose.
|
||||
|
||||
### 3.2 Step sequence
|
||||
Process actions as a bulleted list, in execution order, each meaningful step followed by a
|
||||
screenshot:
|
||||
|
||||
```
|
||||
- Trader clicks **Insert** … [screenshot]
|
||||
- A new window opens; enter the line details [field-reference table]
|
||||
- Click **Save** — system allocates the number (e.g. PC- / SC- prefix)
|
||||
```
|
||||
|
||||
### 3.3 Annotated screenshot
|
||||
The dominant visual. Conventions to reproduce:
|
||||
- Real captures of the *configured* system populated with the client's data.
|
||||
- **Numbered red circular callouts** placed on the fields, matching `#` in the field table.
|
||||
- Placed immediately after the prose/table that describes them, never front-loaded.
|
||||
- For exception flows, before/after captures.
|
||||
|
||||
### 3.4 Notes, examples, open items
|
||||
- **Note / Important Note:** bolded inline callouts for rules, warnings, responsibilities.
|
||||
- *Italic worked examples* with concrete numbers (e.g. freight 4500 USD ÷ 19.2 MT = 234.38 USD/MT).
|
||||
- `[@vendor: …]` inline tags for open questions, bugs, or future enhancements — kept visible in the draft.
|
||||
- Footnotes (`[^n]`) for edge cases that would interrupt the main flow.
|
||||
|
||||
### 3.5 Worked-calculation block
|
||||
For any computed value (freight, finance, insurance, FX), show the **formula then a fully
|
||||
numeric example**:
|
||||
|
||||
```
|
||||
Finance cost = Principal × Rate × Days / 365
|
||||
= 87 848.77 × 2.0% × 60 / 365 = 288.82 USD
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Formatting & style conventions
|
||||
|
||||
| Element | Convention |
|
||||
|---------|-----------|
|
||||
| Field / column names | **Bold** |
|
||||
| Buttons / actions | **Bold** (e.g. click **Save**, **Insert**, **Allocate**) |
|
||||
| Worked examples | *Italic*, with real numbers |
|
||||
| System term being defined | **Bold** on first use |
|
||||
| Open questions / vendor actions | `[@vendor: …]` inline, left in the text |
|
||||
| Edge cases | Footnotes |
|
||||
| Process / status names | Capitalised exactly as in the system (In-Transit, Spot, In-Store) |
|
||||
| Headings | H1 = chapter, H2 = process, H3/H4 = sub-process or scenario variant |
|
||||
| Voice | Future/target tense ("we will create…", "the Trader will enter…") |
|
||||
|
||||
Keep the **client's real master data** in every example: company/location names,
|
||||
commodities, ports, incoterms, banks, grades, packaging (e.g. 69 kg bags). This grounding
|
||||
is what makes the book usable and is the single most important thing to localise.
|
||||
|
||||
---
|
||||
|
||||
## 5. How to adapt for a new customer / commodity / workflow
|
||||
|
||||
> **INSTRUCTION — ask before generating.** Before producing a new Practice Book, do **not**
|
||||
> assume answers from the reference documents. First **ask the customer the questions
|
||||
> below and wait for their answers.** Only once the answers are provided should the output
|
||||
> document be generated. Pose the questions grouped as listed; where a question has a small
|
||||
> fixed set of choices, offer them as selectable options, otherwise ask for free text.
|
||||
|
||||
**Questions to ask the customer:**
|
||||
|
||||
1. **Glossary entities.** What are the company/location name(s), the commodity set being
|
||||
traded (e.g. coffee, cocoa, cotton, sugar, grains, iron ore, steel, copper, aluminium,
|
||||
zinc/lead), and the line-of-business dimension? Are there any agreed structural limits
|
||||
(e.g. maximum number of contract sequences/lines)?
|
||||
|
||||
2. **Pricing types.** Which pricing types does the client use — *Priced*, *Basis
|
||||
(differential)*, *formula-priced*, or a combination? Which underlying markets and terms
|
||||
apply (e.g. ICE, LME, SHFE, GAFTA/FOSFA references)?
|
||||
|
||||
3. **Cost matrix & route logic.** What are the real incoterms, typical loading and
|
||||
destination places, and the cost types to budget (e.g. freight, insurance, finance,
|
||||
fumigation, inland, demurrage)? Which costs are auto-calculated vs. manually entered?
|
||||
|
||||
4. **Logistics flows in scope.** Which flows apply — Inbound (origin → warehouse),
|
||||
Outbound (warehouse → buyer), Drop Ship (direct), Transfer (location to location)? Are
|
||||
the goods bagged or bulk (affecting packaging, weights, draft survey, moisture/outturn),
|
||||
and is tolerance/franchise handling required for the commodity family?
|
||||
|
||||
5. **Hedging & FX scope.** What should the book cover — *physical only (no hedging/FX)*,
|
||||
*futures hedging only*, *futures + FX hedging*, or *FX only*? Front-office and physical
|
||||
mechanics must be kept in clearly separate chapters.
|
||||
|
||||
6. **Worked scenarios.** Which dimensions matter for this client's scenario variants
|
||||
(e.g. location, commodity, contract type, packaging, exception type)? Which exception
|
||||
flows must be covered (rejections, claims, transhipment …) and which are out of
|
||||
scope / later phase?
|
||||
|
||||
7. **Screenshots.** Will annotated screenshots be supplied from the client's configured
|
||||
environment, or should the document leave numbered placeholders for them? (Never reuse
|
||||
another client's captures.)
|
||||
|
||||
8. **Target ERP.** Which ERP is the target — Tryton, iRely, or another system? If it
|
||||
differs from the reference (iRely), provide the equivalent term/model mapping (e.g.
|
||||
Tryton models, wizards, states) so iRely-specific terms (Voucher, Sequence, Blotter)
|
||||
can be replaced. The pedagogical structure — fundamentals, field tables, illustrated
|
||||
steps, worked scenarios — is ERP-agnostic and must be preserved regardless.
|
||||
|
||||
---
|
||||
|
||||
## 6. Quality bar (acceptance criteria)
|
||||
|
||||
A generated Practice Book is "done" when:
|
||||
- A new staff member could execute each process end-to-end using only the book.
|
||||
- Every data-entry screen has a matching numbered field table + annotated screenshot.
|
||||
- Every computed figure shows its formula and a numeric worked example.
|
||||
- All examples use the client's real master data.
|
||||
- Open items are visibly tagged, not silently dropped.
|
||||
- The fundamentals chapter is identical across the client's set of books.
|
||||
- Scope boundaries (what is in / out / later phase) are stated explicitly.
|
||||
@@ -0,0 +1,236 @@
|
||||
# Screen reference - Fees, pricing and MTM
|
||||
|
||||
Parent process: Trade & Commodity Management
|
||||
|
||||
Source screens and models reviewed:
|
||||
|
||||
- `modules/purchase_trade/view/fee_form.xml`
|
||||
- `modules/purchase_trade/view/component_form.xml`
|
||||
- `modules/purchase_trade/view/component_form2.xml`
|
||||
- `modules/purchase_trade/view/pricing_form.xml`
|
||||
- `modules/purchase_trade/view/trigger_form.xml`
|
||||
- `modules/purchase_trade/view/period_form.xml`
|
||||
- `modules/purchase_trade/view/mtm_strategy_form.xml`
|
||||
- `modules/purchase_trade/view/mtm_scenario_form.xml`
|
||||
- `modules/purchase_trade/view/price_matrix_form.xml`
|
||||
- `modules/purchase_trade/fee.py`
|
||||
- `modules/purchase_trade/pricing.py`
|
||||
|
||||
Database note: table names below follow the Tryton convention of replacing dots with underscores.
|
||||
|
||||
## Fees on contract lines or shipments
|
||||
|
||||
Model: `fee.fee`
|
||||
Table: `fee_fee`
|
||||
Main view: `fee_form`
|
||||
|
||||
The compact `fee_form` currently displays `type`, `product`, lot links and lot count. The model also contains the full calculation fields used by tree views and automatic amount computation.
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `line` | No | Purchase line that owns the fee. |
|
||||
| `sale_line` | No | Sale line that owns the fee. This field is added by the sale extension of `fee.fee`. |
|
||||
| `shipment_in` | No | Inbound shipment that owns the fee. |
|
||||
| `shipment_out` | No | Outbound shipment that owns the fee. |
|
||||
| `shipment_internal` | No | Internal shipment that owns the fee. |
|
||||
| `supplier` | Yes | Fee supplier/vendor. |
|
||||
| `type` | Yes | Fee state: budgeted, ordered or actual. |
|
||||
| `p_r` | Yes | Pay/receive indicator: `PAY` or `REC`. |
|
||||
| `product` | Yes | Service product being charged. Domain restricts to service products. |
|
||||
| `currency` | No | Fee currency. |
|
||||
| `price` | No | Unit price, percentage, rate or lump-sum value depending on `mode`. |
|
||||
| `mode` | Yes | Calculation mode: lump sum, per quantity, percent of price/rate/cost, or per packing. |
|
||||
| `auto_calculation` | No | Automatically calculates packing quantity when mode is `ppack`. |
|
||||
| `inherit_qt` | No | Indicates quantity is inherited, enabled mainly for packing mode. |
|
||||
| `quantity` | No | Quantity used for calculation; read-only outside packing/manual contexts. |
|
||||
| `unit` | No | Unit for quantity or packing calculation. |
|
||||
| `packing_category` | Computed | Packing UoM category used to restrict `unit`. |
|
||||
| `inherit_shipment` | No | Links the fee to shipment quantities when applicable. |
|
||||
| `purchase` | No | Purchase header link for fee aggregation. |
|
||||
| `qt_state` | No | Quantity state used for calculation, defaulting to `BL` when available. |
|
||||
| `amount` | Computed | Calculated fee amount. |
|
||||
| `fee_lots` | Computed | Eligible lots for the fee. |
|
||||
| `lots` | No | Lots explicitly linked through `fee.lots`. |
|
||||
| `lots_cp` | No | Count of linked lots. |
|
||||
| `state` | Read-only | Invoice status: not invoiced or invoiced. |
|
||||
| `fee_landed_cost` | Computed | Indicates whether the fee is posted to inventory/landed cost. |
|
||||
| `inv` | Computed | Invoice linked to the fee. |
|
||||
| `weight_type` | No | Net or gross weight basis for calculation. |
|
||||
| `fee_date` | No | Fee date; defaults to current date. |
|
||||
|
||||
### Fee lots
|
||||
|
||||
Model: `fee.lots`
|
||||
Table: `fee_lots`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `fee` | Yes | Fee being allocated. |
|
||||
| `lot` | Yes | Lot receiving the fee allocation. |
|
||||
|
||||
## Pricing component
|
||||
|
||||
Model: `pricing.component`
|
||||
Table: `pricing_component`
|
||||
Views: `component_form`, `component_form2`
|
||||
|
||||
Components define how a contract line or MTM strategy gets market prices.
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `strategy` | No | MTM strategy that owns the component when used in MTM setup. |
|
||||
| `price_source_type` | Yes | Price source: curve or matrix. |
|
||||
| `fix_type` | No | Fixation type, such as official quotation or settlement. |
|
||||
| `ratio` | No | Percentage weight applied to the component. |
|
||||
| `price_index` | No | Price curve (`price.price`) used when source type is curve. |
|
||||
| `price_matrix` | No | Price matrix used when source type is matrix. |
|
||||
| `currency` | Computed | Currency derived from the selected curve. |
|
||||
| `auto` | No | Marks component as automatically generated or updated. |
|
||||
| `fallback` | No | Allows fallback pricing logic. |
|
||||
| `calendar` | No | Price calendar used for valid quotation dates. |
|
||||
| `nbdays` | Computed | Number of quotation/application days from period rules. |
|
||||
| `pricing_date` | No | Maximum pricing date. |
|
||||
| `triggers` | No | Period rules defining the quotation window and application window. |
|
||||
|
||||
## Pricing fixing records
|
||||
|
||||
Model: `pricing.pricing`
|
||||
Table: `pricing_pricing`
|
||||
View: `pricing_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `pricing_date` | No | Date of the market price/fixing. |
|
||||
| `price_component` | No | Component being fixed. |
|
||||
| `quantity` | No | Quantity fixed on this date. Default `0`. |
|
||||
| `settl_price` | No | Settlement/fixing price for the date. Default `0`. |
|
||||
| `fixed_qt` | Read-only | Cumulative fixed quantity at this row. |
|
||||
| `fixed_qt_price` | Read-only | Weighted average price of fixed quantity. |
|
||||
| `unfixed_qt` | Read-only | Remaining unfixed quantity. |
|
||||
| `unfixed_qt_price` | Read-only | Price assigned to unfixed quantity. |
|
||||
| `eod_price` | Read-only | End-of-day price. |
|
||||
| `last` | No | Use last available quotation when applicable. |
|
||||
|
||||
## Pricing period rules
|
||||
|
||||
Model: `pricing.trigger`
|
||||
Table: `pricing_trigger`
|
||||
View: `trigger_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `component` | No | Parent pricing component. |
|
||||
| `pricing_period` | No | Named period rule for quotation dates. |
|
||||
| `from_p` | No | Manual pricing window start, read-only when `pricing_period` is selected. |
|
||||
| `to_p` | No | Manual pricing window end, read-only when `pricing_period` is selected. |
|
||||
| `average` | No | Average quotations in the pricing window. |
|
||||
| `last` | No | Use last available price. |
|
||||
| `application_period` | No | Named period rule for applying the price. Defaults from `pricing_period` when empty. |
|
||||
| `from_a` | No | Manual application window start. |
|
||||
| `to_a` | No | Manual application window end. |
|
||||
|
||||
Model: `pricing.period`
|
||||
Table: `pricing_period`
|
||||
View: `period_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `name` | No | Period rule name. |
|
||||
| `trigger` | No | Business trigger used to anchor the date calculation. |
|
||||
| `include` | No | Includes the trigger date in generated date lists. |
|
||||
| `every` | No | Weekday selection for generated quotation dates. |
|
||||
| `nb_quotation` | No | Number of quotations. |
|
||||
| `startday` | No | Start-day offset type. |
|
||||
| `nbds` | No | Number of start-day offsets. Default `0`. |
|
||||
| `nbms` | No | Starting month offset. Default `0`. |
|
||||
| `endday` | No | End-day offset type. |
|
||||
| `nbde` | No | Number of end-day offsets. Default `0`. |
|
||||
| `nbme` | No | Ending month offset. Default `0`. |
|
||||
|
||||
## MTM scenario and strategy
|
||||
|
||||
Model: `mtm.scenario`
|
||||
Table: `mtm_scenario`
|
||||
View: `mtm_scenario_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `name` | Yes | Scenario name. |
|
||||
| `valuation_date` | Yes | Date used to value market prices. |
|
||||
| `use_last_price` | No | Allows valuation to use the last available curve price. |
|
||||
| `calendar` | No | Calendar used to determine valid quotation dates. |
|
||||
|
||||
Model: `mtm.strategy`
|
||||
Table: `mtm_strategy`
|
||||
View: `mtm_strategy_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `name` | Yes | Strategy name. |
|
||||
| `scenario` | Yes | Scenario used for valuation. |
|
||||
| `currency` | No | Valuation currency. |
|
||||
| `active` | No | Strategy is active; default `True`. |
|
||||
| `components` | No | Pricing components used to calculate MTM. |
|
||||
|
||||
Model: `mtm.component`
|
||||
Table: `mtm_component`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `strategy` | Yes | Parent MTM strategy. |
|
||||
| `name` | Yes | Component label. |
|
||||
| `component_type` | Yes | Commodity, freight, quality, FX, storage or other. |
|
||||
| `fix_type` | No | Fixation type. |
|
||||
| `price_source_type` | Yes | Curve, matrix or manual source. |
|
||||
| `price_index` | No | Price curve used for curve source. |
|
||||
| `price_matrix` | No | Matrix used for matrix source. |
|
||||
| `ratio` | No | Percentage applied to the source price. |
|
||||
| `manual_price` | No | Manual price when source type is manual. |
|
||||
| `currency` | No | Component currency derived from curve or matrix where possible. |
|
||||
|
||||
## Price matrix
|
||||
|
||||
Model: `price.matrix`
|
||||
Table: `price_matrix`
|
||||
View: `price_matrix_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `name` | Yes | Matrix name. |
|
||||
| `matrix_type` | Yes | Freight, location spread, quality, storage or other. |
|
||||
| `unit` | No | Unit for matrix values. |
|
||||
| `currency` | No | Matrix currency. |
|
||||
| `calendar` | No | Calendar for matrix validity. |
|
||||
| `valid_from` | No | Validity start date. |
|
||||
| `valid_to` | No | Validity end date. |
|
||||
| `lines` | No | Matrix rows. |
|
||||
|
||||
Model: `price.matrix.line`
|
||||
Table: `price_matrix_line`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `matrix` | Yes | Parent matrix. |
|
||||
| `origin` | No | Origin location used for lookup. |
|
||||
| `destination` | No | Destination location used for lookup. |
|
||||
| `product` | No | Product criterion. |
|
||||
| `quality` | No | Product category/quality criterion. |
|
||||
| `price_value` | No | Matrix price value. |
|
||||
|
||||
## Related tables
|
||||
|
||||
| Model | PostgreSQL table | Purpose |
|
||||
| --- | --- | --- |
|
||||
| `fee.fee` | `fee_fee` | Fees on purchase lines, sale lines or shipments. |
|
||||
| `fee.lots` | `fee_lots` | Fee-to-lot allocation. |
|
||||
| `pricing.component` | `pricing_component` | Price curve/matrix components. |
|
||||
| `pricing.pricing` | `pricing_pricing` | Pricing/fixing records. |
|
||||
| `pricing.trigger` | `pricing_trigger` | Pricing and application period windows. |
|
||||
| `pricing.period` | `pricing_period` | Reusable period rules. |
|
||||
| `mtm.scenario` | `mtm_scenario` | MTM valuation scenario. |
|
||||
| `mtm.strategy` | `mtm_strategy` | MTM strategy. |
|
||||
| `mtm.component` | `mtm_component` | MTM component definition. |
|
||||
| `mtm.snapshot` | `mtm_snapshot` | Stored MTM valuation snapshots. |
|
||||
| `price.matrix` | `price_matrix` | Matrix header. |
|
||||
| `price.matrix.line` | `price_matrix_line` | Matrix lookup lines. |
|
||||
|
||||
@@ -0,0 +1,208 @@
|
||||
# Screen reference - Shipments, physical lots and matching
|
||||
|
||||
Parent process: Trade & Commodity Management
|
||||
|
||||
Source screens and models reviewed:
|
||||
|
||||
- `modules/purchase_trade/view/shipment_in_form.xml`
|
||||
- `modules/purchase_trade/view/shipment_out_form.xml`
|
||||
- `modules/purchase_trade/view/shipment_internal_form.xml`
|
||||
- `modules/purchase_trade/view/lot_add_start_form.xml`
|
||||
- `modules/purchase_trade/view/lot_matching_start_form.xml`
|
||||
- `modules/purchase_trade/stock.py`
|
||||
- `modules/purchase_trade/lot.py`
|
||||
|
||||
Database note: models with `PoolMeta` extend existing Tryton tables. The most important tables are `stock_shipment_in`, `stock_shipment_out`, `stock_shipment_internal`, `stock_shipment_container`, `lot_lot` and `lot_qt`. Wizard-only screens such as matching and adding physical lots use transient `ModelView` records and do not create stable business tables by themselves.
|
||||
|
||||
## Inbound shipment
|
||||
|
||||
Model: `stock.shipment.in`
|
||||
Table: `stock_shipment_in`
|
||||
Main view extension: `shipment_in_form`
|
||||
|
||||
### Header and logistics fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `carrier_` | No | Carrier party used for transport execution. |
|
||||
| `from_location` | No | Loading/origin location. |
|
||||
| `to_location` | No | Destination location; replaces the base warehouse display. |
|
||||
| `transport_type` | No | Transport mode: vessel, truck or other. |
|
||||
| `vessel` | No | Vessel master reference. |
|
||||
| `vessel_type` | Computed | Vessel type derived from selected vessel. |
|
||||
| `cargo_mode` | Yes | Shipment mode: bulk or container. |
|
||||
| `del_from` | No | Delivery period start date. |
|
||||
| `del_to` | No | Delivery period end date. |
|
||||
| `bl_number` | No | Bill of lading number. |
|
||||
| `bl_date` | No | Bill of lading date. |
|
||||
| `travel_nb` | No | Voyage/travel number. |
|
||||
| `eta` | No | Estimated loading/POL date shown by the form. |
|
||||
| `etd` | No | Estimated departure/discharge date, depending on context. |
|
||||
| `etad` | No | Estimated arrival at destination. |
|
||||
| `receive_date` | No | Actual reception date. |
|
||||
| `receive_nb` | No | Reception reference number. |
|
||||
| `info` | Computed | HTML vessel information. |
|
||||
| `carte` | Computed | HTML map/IMO output for the vessel. |
|
||||
|
||||
### Tabs
|
||||
|
||||
| Tab | Field/model | Usage |
|
||||
| --- | --- | --- |
|
||||
| `Lots` | `lotqt` / `lot.qt` | Executed quantities/lots loaded or received on the shipment. |
|
||||
| `Fees` | `fees` / `fee.fee` | Shipment-level freight, control or logistics charges. |
|
||||
| `Estimated dates` | `pricing.estimated` | Estimated dates available to pricing rules. |
|
||||
| `Shipping Infos` | `booking`, `ref`, `booking_date`, `agent`, `note` | Booking reference and free-text shipping notes. |
|
||||
| `Container` | `stock.shipment.container` | Container equipment and seal information. |
|
||||
| `Demurrage` | `sof.statement` | Statement of facts and demurrage calculation. |
|
||||
| `Weight Report` | `shipment.wr`, controller fields | Controller instructions and linked weight reports. |
|
||||
|
||||
## Outbound shipment
|
||||
|
||||
Model: `stock.shipment.out`
|
||||
Table: `stock_shipment_out`
|
||||
Main view extension: `shipment_out_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `from_location` | No | Origin/loading location. |
|
||||
| `to_location` | No | Customer or discharge location. |
|
||||
| `transport_type` | No | Transport mode; default `vessel`. |
|
||||
| `vessel` | No | Vessel reference. |
|
||||
| `fees` | No | Sale shipment fees. |
|
||||
| `lotqt` | No | Lot quantity records linked to the shipment. |
|
||||
| `quantity` | Computed | Sum of incoming move quantities. |
|
||||
| `unit` | Computed | Unit from the first incoming move. |
|
||||
| `etl`, `eta`, `etd`, `unloaded` | No | Estimated and actual logistics milestones. |
|
||||
| `booking` | No | Booking reference. |
|
||||
| `ref` | No | Internal shipment reference. |
|
||||
| `note` | No | Free-text logistics notes. |
|
||||
|
||||
## Internal shipment
|
||||
|
||||
Model: `stock.shipment.internal`
|
||||
Table: `stock_shipment_internal`
|
||||
Main view extension: `shipment_internal_form`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `fees` | No | Fees attached to the internal movement. |
|
||||
|
||||
The rest of the internal shipment form is inherited from the base stock module.
|
||||
|
||||
## Shipment containers
|
||||
|
||||
Model: `stock.shipment.container`
|
||||
Table: `stock_shipment_container`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `shipment` | Yes | Parent inbound shipment. |
|
||||
| `container_type` | Yes | Container type/equipment. |
|
||||
| `container_no` | No | Container number. |
|
||||
| `quantity` | Yes | Number of containers of this type. |
|
||||
| `seal_no` | No | Seal number. |
|
||||
| `is_reefer` | No | Marks refrigerated equipment. |
|
||||
|
||||
## Add physical lots
|
||||
|
||||
Wizard: `lot.add`
|
||||
Start model: `lot.add.lot`
|
||||
Line model: `lot.add.line`
|
||||
Action: `Add physical lots` from `lot.report`
|
||||
|
||||
This screen creates physical lot lines from available quantity on an inbound, outbound or internal shipment selection.
|
||||
|
||||
### Header fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `quantity` | Read-only | Available quantity to split into physical lots. |
|
||||
| `unit` | Read-only | Unit for the available quantity. |
|
||||
| `shipment_in` | No | Inbound shipment being split; visible only when present. |
|
||||
| `shipment_internal` | No | Internal shipment being split; visible only when present. |
|
||||
| `shipment_out` | No | Outbound shipment being split; visible only when present. |
|
||||
| `lots` | No | Editable split lines. |
|
||||
|
||||
### Lot line fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `lot_qt` | No | Quantity for the split line. |
|
||||
| `lot_unit` | Yes | Unit for the split quantity. |
|
||||
| `lot_quantity` | No | Net weight of the physical lot. |
|
||||
| `lot_gross_quantity` | No | Gross weight of the physical lot. |
|
||||
| `lot_unit_line` | Yes | Commercial line unit used for contract valuation. |
|
||||
| `lot_premium` | No | Premium or discount carried by the physical lot. |
|
||||
| `lot_chunk_key` | No | Chunk key used to group or trace imported/split lots. |
|
||||
|
||||
## Matching purchase and sale lots
|
||||
|
||||
Wizard: `lot.matching`
|
||||
Start model: `lot.matching.start`
|
||||
Line model: `lot.matching.lot`
|
||||
Action: `Apply matching` from `lot.report`
|
||||
|
||||
The matching wizard compares available purchase-side and sale-side quantities and lets the user enter the quantity to match.
|
||||
|
||||
### Matching header fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `purchase` | No | Restricts purchase-side lots to one purchase contract. |
|
||||
| `sale` | No | Restricts sale-side lots to one sale contract. |
|
||||
| `qt_type` | No | Quantity type filter: open, physical or all. Default `all`. |
|
||||
| `lot_p` | No | Purchase lot candidates populated from `lot.qt` query output. |
|
||||
| `tot_p` | Computed | Sum of purchase quantities entered in `lot_matched_qt`. |
|
||||
| `lot_s` | No | Sale lot candidates populated from `lot.qt` query output. |
|
||||
| `tot_s` | Computed | Sum of sale quantities entered in `lot_matched_qt`. |
|
||||
|
||||
### Filter fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `product_p` | No | Purchase product filter. |
|
||||
| `location_p` | No | Purchase destination filter. |
|
||||
| `cp_p` | No | Supplier filter. |
|
||||
| `inc_p` | No | Purchase Incoterm filter. |
|
||||
| `product_s` | No | Sale product filter. |
|
||||
| `location_s` | No | Sale loading/location filter. |
|
||||
| `cp_s` | No | Client filter. |
|
||||
| `inc_s` | No | Sale Incoterm filter. |
|
||||
|
||||
### Matching line fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `lot_id` | No | Physical or virtual lot selected for matching. |
|
||||
| `lot_r_id` | No | Source `lot.qt` quantity record. |
|
||||
| `lot_purchase` | No | Purchase contract linked to the candidate. |
|
||||
| `lot_sale` | No | Sale contract linked to the candidate. |
|
||||
| `lot_name` | Read-only | Display lot name. |
|
||||
| `lot_type` | No | Quantity type: open, physical or loss. |
|
||||
| `lot_shipment_in` | No | Inbound shipment context. |
|
||||
| `lot_shipment_internal` | No | Internal shipment context. |
|
||||
| `lot_shipment_out` | No | Outbound shipment context. |
|
||||
| `lot_product` | Read-only | Product carried by the lot. |
|
||||
| `lot_quantity` | Read-only | Available quantity. Sale rows are shown as positive matching candidates after sign handling. |
|
||||
| `lot_unit` | Read-only | Unit of the displayed quantity. |
|
||||
| `lot_matched_qt` | No | Quantity the user wants to match. |
|
||||
| `lot_cp` | No | Supplier or client counterparty. |
|
||||
| `lot_shipment_origin` | Computed | Reference to inbound, outbound or internal shipment. |
|
||||
|
||||
## Related tables
|
||||
|
||||
| Model | PostgreSQL table | Purpose |
|
||||
| --- | --- | --- |
|
||||
| `stock.shipment.in` | `stock_shipment_in` | Inbound shipment header. |
|
||||
| `stock.shipment.out` | `stock_shipment_out` | Outbound shipment header. |
|
||||
| `stock.shipment.internal` | `stock_shipment_internal` | Internal transfer header. |
|
||||
| `stock.shipment.container` | `stock_shipment_container` | Shipment container details. |
|
||||
| `shipment.wr` | `shipment_wr` | Link between shipment and weight report. |
|
||||
| `sof.statement` | `sof_statement` | Statement of facts/demurrage record. |
|
||||
| `lot.lot` | `lot_lot` | Lot master and purchase_trade extensions. |
|
||||
| `lot.qt` | `lot_qt` | Lot quantity state records used for available/open/matched quantities. |
|
||||
| `lot.add.lot` | transient | Add-lot wizard header; no persistent business table. |
|
||||
| `lot.add.line` | transient | Add-lot wizard split line; no persistent business table. |
|
||||
| `lot.matching.start` | transient | Matching wizard header; no persistent business table. |
|
||||
| `lot.matching.lot` | transient | Matching wizard candidate line; no persistent business table. |
|
||||
|
||||
@@ -0,0 +1,131 @@
|
||||
# Screen reference - Party and price curve master data
|
||||
|
||||
Parent process: Trade & Commodity Management
|
||||
|
||||
Source screens and models reviewed:
|
||||
|
||||
- `modules/purchase_trade/view/party_form.xml`
|
||||
- `modules/purchase_trade/view/party_exec_sla_form.xml`
|
||||
- `modules/purchase_trade/view/party_exec_place_tree.xml`
|
||||
- `modules/purchase_trade/party.py`
|
||||
- `modules/price/view/price_form.xml`
|
||||
- `modules/price/price.py`
|
||||
- `modules/price/price_value.py`
|
||||
|
||||
Database note: `party.party` and `price.price` are shared master data models. The party fields listed here are the `purchase_trade` extensions on top of the base party screen. Price curves live in the `price` module but are consumed by `purchase_trade` pricing, derivatives and MTM.
|
||||
|
||||
## Party contract and execution data
|
||||
|
||||
Model: `party.party`
|
||||
Table: `party_party`
|
||||
Main view extension: `party_form`
|
||||
|
||||
### Contract tab
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `tol_min` | No | Default negative tolerance percentage for contracts involving the party. |
|
||||
| `tol_max` | No | Default positive tolerance percentage for contracts involving the party. |
|
||||
| `wb` | No | Default weight basis for contracts involving the party. |
|
||||
| `association` | No | Default trade association/rule set for the party. |
|
||||
| `origin` | No | Default product or geographic origin. |
|
||||
| `initial` | No | Party initials used for internal references or reporting. |
|
||||
|
||||
### Execution tab
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `sla` | No | Service-level agreement records for locations/costs. |
|
||||
| `execution` | No | Execution target records by area. |
|
||||
|
||||
## Party execution target
|
||||
|
||||
Model: `party.execution`
|
||||
Table: `party_execution`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `party` | No | Parent party. |
|
||||
| `area` | No | Country/region area. |
|
||||
| `percent` | No | Target percentage for execution allocation. |
|
||||
| `achieved_percent` | Computed | Achieved percentage. Current implementation returns a placeholder value. |
|
||||
|
||||
## Party execution SLA
|
||||
|
||||
Model: `party.execution.sla`
|
||||
Table: `party_execution_sla`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `party` | No | Parent party. |
|
||||
| `reference` | No | SLA reference. |
|
||||
| `product` | No | Product covered by the SLA. |
|
||||
| `date_from` | No | SLA validity start date. |
|
||||
| `date_to` | No | SLA validity end date. |
|
||||
| `places` | No | Location-specific SLA costs. |
|
||||
|
||||
Model: `party.execution.place`
|
||||
Table: `party_execution_place`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `pes` | No | Parent SLA record. |
|
||||
| `location` | No | Location where the SLA cost applies. |
|
||||
| `cost` | No | Cost value for the location. |
|
||||
| `mode` | Yes | Cost calculation mode: lump sum, per quantity, percentage or per packing. |
|
||||
| `currency` | No | Currency for the SLA cost. |
|
||||
| `unit` | No | Unit for packing mode. |
|
||||
|
||||
## Price curve
|
||||
|
||||
Model: `price.price`
|
||||
Table: `price_price`
|
||||
Main view: `price_form`
|
||||
|
||||
Price curves are selected in `pricing.component.price_index`, `mtm.component.price_index` and derivative records. The curve provides quotation values, units, currency conversion and contract-size calculations.
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `price` | No | Composite parent curve when the curve is built from other curves. |
|
||||
| `price_index` | Yes | Curve/index code, used as the record name. |
|
||||
| `price_desc` | Yes | Human-readable curve description. |
|
||||
| `price_period` | No | Product month/period attached to the curve. |
|
||||
| `price_curve_type` | No | Spot, future or composite curve type. |
|
||||
| `price_type` | No | Fixation type. |
|
||||
| `price_unit` | No | Unit in which quotations are expressed. |
|
||||
| `price_currency` | No | Currency in which quotations are expressed. |
|
||||
| `price_area` | No | Market area. |
|
||||
| `price_calendar` | No | Quotation calendar. |
|
||||
| `price_values` | No | Historical or future quotation values. |
|
||||
| `price_composite` | No | Components of a composite curve. |
|
||||
| `price_product` | No | Products linked to the curve. |
|
||||
| `price_ct_size` | No | Contract size for derivative and amount calculations. |
|
||||
|
||||
## Price values
|
||||
|
||||
Model: `price.price_value`
|
||||
Table: `price_price_value`
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `price` | Yes | Parent price curve. |
|
||||
| `price_index` | Computed | Display of the parent curve index. |
|
||||
| `price_date` | No | Quotation date. The model validates uniqueness by curve/date when both are present. |
|
||||
| `price_value` | No | Settlement or reference quotation value. |
|
||||
| `open_price` | No | Open price for the date. |
|
||||
| `low_price` | No | Low price for the date. |
|
||||
| `high_price` | No | High price for the date. |
|
||||
|
||||
## Related tables
|
||||
|
||||
| Model | PostgreSQL table | Purpose |
|
||||
| --- | --- | --- |
|
||||
| `party.party` | `party_party` | Shared party master data plus purchase_trade contract defaults. |
|
||||
| `party.execution` | `party_execution` | Execution target by area. |
|
||||
| `party.execution.sla` | `party_execution_sla` | Party SLA header. |
|
||||
| `party.execution.place` | `party_execution_place` | SLA location/cost details. |
|
||||
| `price.price` | `price_price` | Price curve/index master. |
|
||||
| `price.price_value` | `price_price_value` | Curve quotation values. |
|
||||
| `price.calendar` | `price_calendar` | Quotation calendar used by curves and pricing rules. |
|
||||
| `price.fixtype` | `price_fixtype` | Fixation type reference. |
|
||||
|
||||
@@ -0,0 +1,199 @@
|
||||
# Screen reference - Purchase and sale contracts
|
||||
|
||||
Parent process: Trade & Commodity Management
|
||||
|
||||
Source screens and models reviewed:
|
||||
|
||||
- `modules/purchase_trade/view/purchase_form.xml`
|
||||
- `modules/purchase_trade/view/purchase_line_form.xml`
|
||||
- `modules/purchase_trade/view/sale_form.xml`
|
||||
- `modules/purchase_trade/view/sale_line_form.xml`
|
||||
- `modules/purchase_trade/purchase.py`
|
||||
- `modules/purchase_trade/sale.py`
|
||||
|
||||
Database note: Tryton model names normally map to PostgreSQL table names by replacing dots with underscores. Contract headers write to `purchase_purchase` and `sale_sale`; contract lines write to `purchase_line` and `sale_line`. These models extend base Tryton purchase/sale screens, so this document focuses on the fields added or materially used by `purchase_trade`.
|
||||
|
||||
## Purchase contract
|
||||
|
||||
Model: `purchase.purchase`
|
||||
Table: `purchase_purchase`
|
||||
Main view extension: `purchase_form`
|
||||
|
||||
### Header fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `lc_date` | No | Letter of credit date used for contract documentation and trade finance follow-up. |
|
||||
| `wb` | Yes | Weight basis applied to the contract; defaulted from the first `purchase.weight.basis` record. |
|
||||
| `certif` | Yes | Certification attached to the contract; hidden for company `MELYA` by `company_visible`. |
|
||||
| `broker` | No | Broker party for the contract. Domain restricts to broker-related categories. |
|
||||
| `operator` | No | Operational owner responsible for execution follow-up. |
|
||||
| `trader` | No | Trader responsible for the commercial position. |
|
||||
| `our_reference` | No | Internal reference displayed on the contract. |
|
||||
| `association` | Yes | Trade association or rule set linked to the contract; hidden for company `MELYA`. |
|
||||
| `crop` | No | Crop/campaign information for commodity contracts. |
|
||||
| `tol_min` | Yes | Negative quantity tolerance percentage; default `0`. |
|
||||
| `tol_max` | Yes | Positive quantity tolerance percentage; default `0`. |
|
||||
| `from_location` | Yes | Origin/loading location. Supplier locations are allowed; customer locations are excluded. |
|
||||
| `to_location` | Yes | Destination/discharge location. Customer locations are allowed; supplier locations are excluded. |
|
||||
| `incoterm` | Inherited | Delivery term from the base purchase model, shown in the trade header. |
|
||||
| `incoterm_location` | Inherited | Named place for the Incoterm. |
|
||||
| `product_origin` | No | Free-text origin statement for reports or documentation. |
|
||||
| `bank_account` | No | Bank account selected from the supplier bank accounts, defaulted by currency when possible. |
|
||||
| `doc_template` | No | Document template used to populate required contract documents. |
|
||||
| `required_documents` | No | Required document types for the contract. |
|
||||
| `analytic_dimensions` | No | Analytic allocation dimensions attached to the contract. |
|
||||
|
||||
### Header tabs
|
||||
|
||||
| Tab | Field/model | Usage |
|
||||
| --- | --- | --- |
|
||||
| `Derivative` | `derivatives` / `derivative.derivative` | Paper hedge or derivative records linked to the purchase. |
|
||||
| `Pnl` | `pnl_`, `pnl` | Contract valuation lines or grouped dynamic P&L. |
|
||||
| `Forex` | `forex.cover.physical.contract` | FX covers linked to the physical purchase. |
|
||||
| `Execution plan` | `plan` | Execution workflow plan reference. |
|
||||
| `Estimated dates` | `pricing.estimated` | Estimated dates used by pricing period rules. |
|
||||
| `Required documents` | `contract.document.type` | Document checklist generated manually or from a template. |
|
||||
| `Dimensions` | `analytic.dimension.assignment` | Analytic dimensions for reporting and control. |
|
||||
|
||||
## Purchase contract line
|
||||
|
||||
Model: `purchase.line`
|
||||
Table: `purchase_line`
|
||||
Main view extension: `purchase_line_form`
|
||||
|
||||
### Line fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `quantity_theorical` | No | Contractual quantity reference, distinct from executed physical lot quantities. |
|
||||
| `finished` | No | Operational flag marking the line as finished. Default `False`. |
|
||||
| `enable_linked_currency` | No | Enables alternate linked currency pricing fields. Default `False`. |
|
||||
| `linked_price` | No | Linked-currency price, visible only when linked currencies are enabled. |
|
||||
| `linked_currency` | No | Linked currency used with `linked_price`. |
|
||||
| `linked_unit` | No | Unit used with `linked_price`. |
|
||||
| `price_type` | No | Pricing mode: `cash`, `priced`, `basis`, or `efp`. Default `priced`. |
|
||||
| `progress` | Computed | Fixation progress, shown for basis-priced lines. |
|
||||
| `premium` | No | Premium or discount applied to the line price. |
|
||||
| `inherit_tol` | No | If checked, line tolerances inherit contract tolerances. Default `True`. |
|
||||
| `tol_min` | No | Line-level negative tolerance percentage when not inherited. |
|
||||
| `tol_min_v` | Computed | Computed minimum quantity after tolerance. |
|
||||
| `tol_max` | No | Line-level positive tolerance percentage when not inherited. |
|
||||
| `tol_max_v` | Computed | Computed maximum quantity after tolerance. |
|
||||
| `tol_min_qt` | No | Absolute negative tolerance quantity. |
|
||||
| `tol_max_qt` | No | Absolute positive tolerance quantity. |
|
||||
| `inherit_cer` | No | If checked, line certification inherits contract certification. Default `True`. |
|
||||
| `certif` | No | Line-level certification when not inherited. |
|
||||
| `del_period` | No | Delivery period reference used by pricing period rules. |
|
||||
| `from_del` | No | Delivery period start date. |
|
||||
| `to_del` | No | Delivery period end date. |
|
||||
| `period_at` | No | Business event used to interpret the delivery period, such as loading, discharge, title transfer or arrival. |
|
||||
| `concentration` | No | Concentration value for concentrate contracts. |
|
||||
| `term` | No | Incoming document representing the contract term source. |
|
||||
| `update_pricing` | No | Requests pricing update from assay/term information. |
|
||||
| `assay_state` | No | Assay/pricing status: provisional, final or umpire. |
|
||||
|
||||
### Line tabs
|
||||
|
||||
| Tab | Field/model | Usage |
|
||||
| --- | --- | --- |
|
||||
| `Concentrate / Assays` | `assay.assay`, `assay.line` | Stores assay references and detailed elemental analysis. |
|
||||
| `Concentrate / Term` | `concentrate.term` | Payable or penalty terms used to price concentrate material. |
|
||||
| `Lots` | `lot.lot` | Physical and virtual lots attached to the purchase line. |
|
||||
| `Fees` | `fee.fee` | Service or logistics fees attached to the purchase line. |
|
||||
| `Mtm` | `purchase.strategy` | MTM strategies selected for the line. |
|
||||
| `Derivatives` | `derivative.derivative` | Hedge records at line level. |
|
||||
| `Pricing / Components` | `pricing.component` | Price curve or matrix components used by the line. |
|
||||
| `Pricing / Pricing dates` | `pricing.pricing` | Daily or fixing price records. |
|
||||
| `Pricing / Summary` | `purchase.pricing.summary` | Computed fixed/unfixed summary. |
|
||||
| `Estimated dates` | `pricing.estimated` | Estimated business dates used by period rules. |
|
||||
| `Optionals Scenarios` | `optional.scenario` | Optional pricing/execution scenarios. |
|
||||
|
||||
## Sale contract
|
||||
|
||||
Model: `sale.sale`
|
||||
Table: `sale_sale`
|
||||
Main view extension: `sale_form`
|
||||
|
||||
The sale contract mirrors most purchase-trade header controls. `from_location` and `to_location` are also required; in the sale form the base `warehouse` field is replaced by `to_location`.
|
||||
|
||||
### Header fields
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `lc_date` | No | Letter of credit date for customer contract follow-up. |
|
||||
| `wb` | Yes | Weight basis; defaulted from `purchase.weight.basis`. |
|
||||
| `certif` | Yes | Certification, hidden for company `MELYA`. |
|
||||
| `agent` | No | Sale-side commercial/logistics agent shown on the header. |
|
||||
| `operator` | No | Execution owner. |
|
||||
| `trader` | No | Trader responsible for the sale. |
|
||||
| `our_reference` | No | Internal reference. |
|
||||
| `association` | Yes | Trade association or rule set, hidden for company `MELYA`. |
|
||||
| `crop` | No | Crop/campaign information. |
|
||||
| `tol_min` | Yes | Negative quantity tolerance percentage. Default `0`. |
|
||||
| `tol_max` | Yes | Positive quantity tolerance percentage. Default `0`. |
|
||||
| `from_location` | Yes | Sale loading/origin location. |
|
||||
| `to_location` | Yes | Sale destination/discharge location; replaces base warehouse display. |
|
||||
| `incoterm` | Inherited | Sale Incoterm. |
|
||||
| `incoterm_location` | Inherited | Named Incoterm place. |
|
||||
| `product_origin` | No | Product origin statement. |
|
||||
| `bank_account` | No | Bank account selected from customer/party bank accounts, defaulted by currency when possible. |
|
||||
| `doc_template` | No | Template used to populate required contract documents. |
|
||||
| `required_documents` | No | Customer contract document checklist. |
|
||||
| `analytic_dimensions` | No | Analytic reporting dimensions. |
|
||||
|
||||
### Header tabs
|
||||
|
||||
| Tab | Field/model | Usage |
|
||||
| --- | --- | --- |
|
||||
| `Derivative` | `derivative.derivative` | Sale-linked hedge or derivative records. |
|
||||
| `Pnl` | `valuation.valuation.line`, `valuation.valuation.dyn` | Sale P&L and valuation output. |
|
||||
| `Forex` | `forex.cover.physical.sale` | FX covers for the sale contract. |
|
||||
| `Required documents` | `contract.document.type` | Required documents for sale execution. |
|
||||
| `Dimensions` | `analytic.dimension.assignment` | Analytic allocation dimensions. |
|
||||
|
||||
## Sale contract line
|
||||
|
||||
Model: `sale.line`
|
||||
Table: `sale_line`
|
||||
Main view extension: `sale_line_form`
|
||||
|
||||
The sale line uses the same pricing, tolerance, linked currency, lot, fee, MTM and derivative patterns as the purchase line. It adds a `Price composition` tab for reporting sale price build-up.
|
||||
|
||||
| Field | Required | Usage |
|
||||
| --- | --- | --- |
|
||||
| `quantity_theorical` | No | Theoretical quantity for the sale line. |
|
||||
| `finished` | No | Operational completion flag. |
|
||||
| `enable_linked_currency` | No | Enables linked-currency fields. |
|
||||
| `linked_price` | No | Alternate price when linked currency is enabled. |
|
||||
| `linked_currency` | No | Linked currency. |
|
||||
| `linked_unit` | No | Linked price unit. |
|
||||
| `price_type` | No | Pricing mode: `cash`, `priced`, `basis`, or `efp`. Default `priced`. |
|
||||
| `progress` | Computed | Fixing progress for basis-priced lines. |
|
||||
| `premium` | No | Premium or discount. |
|
||||
| `inherit_tol` | No | Inherits header tolerances when checked. Default `True`. |
|
||||
| `tol_min`, `tol_max` | No | Line-level tolerance percentages when not inherited. |
|
||||
| `tol_min_v`, `tol_max_v` | Computed | Computed min/max quantities after tolerance. |
|
||||
| `tol_min_qt`, `tol_max_qt` | No | Absolute tolerance quantities. |
|
||||
| `inherit_cer` | No | Inherits header certification when checked. Default `True`. |
|
||||
| `certif` | No | Line-level certification. |
|
||||
| `pricing_rule` | No | Free-text pricing rule shown on reports. |
|
||||
|
||||
## Related tables
|
||||
|
||||
| Model | PostgreSQL table | Purpose |
|
||||
| --- | --- | --- |
|
||||
| `purchase.purchase` | `purchase_purchase` | Purchase contract header. |
|
||||
| `purchase.line` | `purchase_line` | Purchase contract lines. |
|
||||
| `sale.sale` | `sale_sale` | Sale contract header. |
|
||||
| `sale.line` | `sale_line` | Sale contract lines. |
|
||||
| `contract.document.type` | `contract_document_type` | Relation object for required contract documents. |
|
||||
| `doc.template` | `doc_template` | Contract document templates. |
|
||||
| `pricing.estimated` | `pricing_estimated` | Estimated dates used by pricing and logistics rules. |
|
||||
| `pricing.component` | `pricing_component` | Pricing components attached to contract lines or MTM strategies. |
|
||||
| `pricing.pricing` | `pricing_pricing` | Price fixing records. |
|
||||
| `fee.fee` | `fee_fee` | Contract, shipment or line fees. |
|
||||
| `lot.lot` | `lot_lot` | Physical/virtual lots linked to contract lines. |
|
||||
| `purchase.strategy` | `purchase_strategy` | Purchase MTM strategy link model. |
|
||||
| `sale.strategy` | `sale_strategy` | Sale MTM strategy link model. |
|
||||
|
||||
@@ -0,0 +1,880 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="UTF-8">
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||||
<title>Interacid Trading S.A - Tradon Practice Book</title>
|
||||
<style>
|
||||
@import url('https://fonts.googleapis.com/css2?family=IBM+Plex+Sans:wght@300;400;500;600&family=IBM+Plex+Mono:wght@400;500&display=swap');
|
||||
|
||||
*, *::before, *::after { box-sizing: border-box; margin: 0; padding: 0; }
|
||||
|
||||
:root {
|
||||
--bg: #f4f5f7;
|
||||
--surface: #ffffff;
|
||||
--surface-soft: #f8f9fb;
|
||||
--border: #dde1e7;
|
||||
--text-primary: #1a1d23;
|
||||
--text-secondary: #5a6072;
|
||||
--accent: #1a4fa0;
|
||||
--accent-lt: #e8eef8;
|
||||
--amber: #b45309;
|
||||
--amber-lt: #fef3cd;
|
||||
--teal: #0f6e56;
|
||||
--teal-lt: #e1f5ee;
|
||||
--red: #b91c1c;
|
||||
--red-lt: #fee2e2;
|
||||
--purple: #534ab7;
|
||||
--purple-lt: #eeedfe;
|
||||
--gray-lt: #f1f2f4;
|
||||
--radius: 6px;
|
||||
--font: 'IBM Plex Sans', sans-serif;
|
||||
--mono: 'IBM Plex Mono', monospace;
|
||||
}
|
||||
|
||||
body {
|
||||
font-family: var(--font);
|
||||
font-size: 13px;
|
||||
line-height: 1.6;
|
||||
color: var(--text-primary);
|
||||
background: var(--bg);
|
||||
padding: 24px 28px 40px;
|
||||
}
|
||||
|
||||
header {
|
||||
border-left: 4px solid var(--accent);
|
||||
padding-left: 16px;
|
||||
margin-bottom: 28px;
|
||||
}
|
||||
header .label {
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
letter-spacing: .12em;
|
||||
text-transform: uppercase;
|
||||
color: var(--accent);
|
||||
margin-bottom: 4px;
|
||||
}
|
||||
header h1 {
|
||||
font-size: 21px;
|
||||
font-weight: 600;
|
||||
line-height: 1.25;
|
||||
}
|
||||
header .meta {
|
||||
display: flex;
|
||||
gap: 20px;
|
||||
flex-wrap: wrap;
|
||||
margin-top: 7px;
|
||||
font-size: 11px;
|
||||
color: var(--text-secondary);
|
||||
}
|
||||
header .meta span::before {
|
||||
content: '.';
|
||||
margin-right: 7px;
|
||||
color: var(--border);
|
||||
}
|
||||
header .meta span:first-child::before { content: ''; margin: 0; }
|
||||
|
||||
main { max-width: 1280px; }
|
||||
section { margin-bottom: 30px; }
|
||||
|
||||
.section-title {
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
letter-spacing: .1em;
|
||||
text-transform: uppercase;
|
||||
color: var(--text-secondary);
|
||||
margin-bottom: 12px;
|
||||
padding-bottom: 6px;
|
||||
border-bottom: 1px solid var(--border);
|
||||
}
|
||||
h2 {
|
||||
font-size: 16px;
|
||||
font-weight: 600;
|
||||
margin: 22px 0 10px;
|
||||
}
|
||||
h3 {
|
||||
font-size: 13px;
|
||||
font-weight: 600;
|
||||
margin: 18px 0 8px;
|
||||
}
|
||||
p + p { margin-top: 8px; }
|
||||
strong { font-weight: 600; }
|
||||
code {
|
||||
font-family: var(--mono);
|
||||
font-size: 11px;
|
||||
color: var(--accent);
|
||||
background: var(--accent-lt);
|
||||
border-radius: 3px;
|
||||
padding: 1px 4px;
|
||||
}
|
||||
|
||||
.summary-card,
|
||||
.chapter-card,
|
||||
.note,
|
||||
.toc,
|
||||
.scenario-card {
|
||||
background: var(--surface);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
}
|
||||
.summary-card,
|
||||
.chapter-card,
|
||||
.toc,
|
||||
.scenario-card { padding: 18px 20px; }
|
||||
.summary-card { margin-bottom: 20px; line-height: 1.75; }
|
||||
|
||||
.facts {
|
||||
display: flex;
|
||||
flex-wrap: wrap;
|
||||
gap: 10px;
|
||||
margin-bottom: 28px;
|
||||
}
|
||||
.fact {
|
||||
background: var(--surface);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
padding: 10px 14px;
|
||||
flex: 1 1 155px;
|
||||
}
|
||||
.fact-label {
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
letter-spacing: .08em;
|
||||
text-transform: uppercase;
|
||||
color: var(--text-secondary);
|
||||
margin-bottom: 3px;
|
||||
}
|
||||
.fact-value {
|
||||
font-size: 13px;
|
||||
font-weight: 500;
|
||||
font-family: var(--mono);
|
||||
}
|
||||
|
||||
.toc ul {
|
||||
columns: 2;
|
||||
column-gap: 32px;
|
||||
list-style: none;
|
||||
}
|
||||
.toc li {
|
||||
break-inside: avoid;
|
||||
margin-bottom: 7px;
|
||||
}
|
||||
.toc a {
|
||||
color: var(--accent);
|
||||
text-decoration: none;
|
||||
}
|
||||
.toc a:hover { text-decoration: underline; }
|
||||
|
||||
.phase-header {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 10px;
|
||||
margin: 24px 0 10px;
|
||||
}
|
||||
.phase-badge {
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
letter-spacing: .08em;
|
||||
text-transform: uppercase;
|
||||
background: var(--accent);
|
||||
color: #fff;
|
||||
border-radius: 3px;
|
||||
padding: 2px 8px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.phase-title {
|
||||
font-size: 12px;
|
||||
font-weight: 600;
|
||||
letter-spacing: .02em;
|
||||
}
|
||||
.phase-line {
|
||||
flex: 1;
|
||||
height: 1px;
|
||||
background: var(--border);
|
||||
}
|
||||
|
||||
.table-wrap {
|
||||
overflow-x: auto;
|
||||
border-radius: var(--radius);
|
||||
border: 1px solid var(--border);
|
||||
background: var(--surface);
|
||||
margin: 10px 0 16px;
|
||||
}
|
||||
table {
|
||||
width: 100%;
|
||||
border-collapse: collapse;
|
||||
font-size: 12px;
|
||||
}
|
||||
thead th {
|
||||
background: var(--surface-soft);
|
||||
color: var(--text-secondary);
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
letter-spacing: .08em;
|
||||
text-transform: uppercase;
|
||||
padding: 9px 12px;
|
||||
text-align: left;
|
||||
border-bottom: 1px solid var(--border);
|
||||
white-space: nowrap;
|
||||
}
|
||||
tbody tr { border-bottom: 1px solid var(--border); }
|
||||
tbody tr:last-child { border-bottom: none; }
|
||||
tbody td {
|
||||
padding: 9px 12px;
|
||||
vertical-align: top;
|
||||
}
|
||||
.num {
|
||||
width: 26px;
|
||||
height: 26px;
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
border-radius: 50%;
|
||||
background: var(--red);
|
||||
color: #fff;
|
||||
font-family: var(--mono);
|
||||
font-size: 11px;
|
||||
font-weight: 600;
|
||||
}
|
||||
.req {
|
||||
font-size: 10.5px;
|
||||
font-weight: 600;
|
||||
padding: 2px 7px;
|
||||
border-radius: 3px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.req-yes { background: var(--red-lt); color: var(--red); }
|
||||
.req-no { background: var(--gray-lt); color: var(--text-secondary); }
|
||||
.req-auto { background: var(--accent-lt); color: var(--accent); }
|
||||
.req-inh { background: var(--purple-lt); color: var(--purple); }
|
||||
|
||||
.note {
|
||||
padding: 12px 14px;
|
||||
margin: 12px 0;
|
||||
border-left: 4px solid var(--accent);
|
||||
}
|
||||
.note strong { color: var(--accent); }
|
||||
.important {
|
||||
border-left-color: var(--amber);
|
||||
background: #fffdf6;
|
||||
}
|
||||
.important strong { color: var(--amber); }
|
||||
.open-item {
|
||||
border-left-color: var(--red);
|
||||
background: #fffafa;
|
||||
}
|
||||
.open-item strong { color: var(--red); }
|
||||
|
||||
.steps {
|
||||
margin-left: 18px;
|
||||
}
|
||||
.steps li {
|
||||
margin-bottom: 8px;
|
||||
}
|
||||
|
||||
.screenshot-placeholder {
|
||||
margin: 12px 0 18px;
|
||||
border: 1px dashed #b8c2d0;
|
||||
border-radius: var(--radius);
|
||||
background: #fbfcfe;
|
||||
padding: 14px 16px;
|
||||
color: var(--text-secondary);
|
||||
font-size: 11.5px;
|
||||
}
|
||||
.screenshot-placeholder .shot-title {
|
||||
font-weight: 600;
|
||||
color: var(--text-primary);
|
||||
margin-bottom: 4px;
|
||||
}
|
||||
|
||||
.actor {
|
||||
font-size: 10.5px;
|
||||
font-weight: 500;
|
||||
padding: 2px 7px;
|
||||
border-radius: 3px;
|
||||
display: inline-block;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.actor-trade { background: var(--accent-lt); color: var(--accent); }
|
||||
.actor-ops { background: var(--teal-lt); color: var(--teal); }
|
||||
.actor-fin { background: var(--amber-lt); color: var(--amber); }
|
||||
.actor-back { background: var(--purple-lt); color: var(--purple); }
|
||||
.actor-multi { background: var(--gray-lt); color: var(--text-secondary); }
|
||||
|
||||
.tag {
|
||||
font-size: 10px;
|
||||
font-weight: 600;
|
||||
padding: 2px 6px;
|
||||
border-radius: 3px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.tag-trade { background: var(--accent-lt); color: var(--accent); }
|
||||
.tag-ops { background: var(--teal-lt); color: var(--teal); }
|
||||
.tag-fin { background: var(--amber-lt); color: var(--amber); }
|
||||
.tag-open { background: var(--red-lt); color: var(--red); }
|
||||
|
||||
.model-link {
|
||||
color: var(--accent);
|
||||
text-decoration: none;
|
||||
font-family: var(--mono);
|
||||
font-size: 11px;
|
||||
}
|
||||
.model-link:hover { text-decoration: underline; }
|
||||
.calc {
|
||||
font-family: var(--mono);
|
||||
font-size: 11.5px;
|
||||
background: var(--surface-soft);
|
||||
border: 1px solid var(--border);
|
||||
border-radius: var(--radius);
|
||||
padding: 10px 12px;
|
||||
margin: 10px 0;
|
||||
}
|
||||
footer {
|
||||
margin-top: 28px;
|
||||
padding-top: 12px;
|
||||
border-top: 1px solid var(--border);
|
||||
font-size: 10.5px;
|
||||
color: var(--text-secondary);
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
flex-wrap: wrap;
|
||||
gap: 6px;
|
||||
}
|
||||
|
||||
@media (max-width: 760px) {
|
||||
body { padding: 18px 14px 32px; }
|
||||
.toc ul { columns: 1; }
|
||||
header h1 { font-size: 18px; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<main>
|
||||
<header>
|
||||
<div class="label">Practice Book - Tradon / Tryton</div>
|
||||
<h1>Interacid Trading S.A<br>Sulfuric Acid Drop Ship Trading Operations</h1>
|
||||
<div class="meta">
|
||||
<span>Avenue des Baumettes 5, 1020 Renens, Switzerland</span>
|
||||
<span>Commodity: Sulfuric acid</span>
|
||||
<span>Currency: USD</span>
|
||||
<span>Scope: Physical trading only</span>
|
||||
</div>
|
||||
</header>
|
||||
|
||||
<p class="section-title">Document Status</p>
|
||||
<div class="summary-card">
|
||||
<p>This Practice Book describes how Interacid Trading S.A will run sulfuric acid drop-ship transactions in Tradon. It is written as a target operating manual: the Trader, Back-office, Operations and Finance teams should be able to follow the lifecycle from master data and contract entry through budgeted costs, shipment execution, lot creation, matching, pricing and settlement.</p>
|
||||
<p>The scope deliberately excludes futures hedging and FX hedging. Interacid's activity is treated as USD-denominated physical trading. Pricing covers mostly <strong>Priced</strong> contracts and selected <strong>Basis</strong> contracts, with Argus as the principal market reference. The public Interacid service positioning emphasizes global sulfuric acid trading, shipping/logistics capability, terminal services, safety and reliability; those themes are reflected in the operating controls in this book.</p>
|
||||
</div>
|
||||
|
||||
<div class="facts">
|
||||
<div class="fact"><div class="fact-label">Company</div><div class="fact-value">Interacid Trading S.A</div></div>
|
||||
<div class="fact"><div class="fact-label">ERP</div><div class="fact-value">Tryton / Tradon</div></div>
|
||||
<div class="fact"><div class="fact-label">Commodity</div><div class="fact-value">Sulfuric acid</div></div>
|
||||
<div class="fact"><div class="fact-label">Flow</div><div class="fact-value">Drop Ship</div></div>
|
||||
<div class="fact"><div class="fact-label">Default Tolerance</div><div class="fact-value">5%</div></div>
|
||||
<div class="fact"><div class="fact-label">Market</div><div class="fact-value">Argus</div></div>
|
||||
<div class="fact"><div class="fact-label">Currency</div><div class="fact-value">USD</div></div>
|
||||
</div>
|
||||
|
||||
<section id="contents">
|
||||
<p class="section-title">Contents</p>
|
||||
<div class="toc">
|
||||
<ul>
|
||||
<li><a href="#fundamentals">1. Fundamentals and glossary</a></li>
|
||||
<li><a href="#master-data">2. Master data setup</a></li>
|
||||
<li><a href="#purchase-contract">3. Purchase contract entry</a></li>
|
||||
<li><a href="#sale-contract">4. Sale contract entry</a></li>
|
||||
<li><a href="#costs">5. Costs: budgeted, ordered and lot-specific</a></li>
|
||||
<li><a href="#shipment">6. Drop-ship shipment execution</a></li>
|
||||
<li><a href="#lots">7. Physical lots and matching</a></li>
|
||||
<li><a href="#pricing">8. Pricing and concentration adjustment</a></li>
|
||||
<li><a href="#scenario-one">9. Scenario 1 - One purchase matched to one sale</a></li>
|
||||
<li><a href="#scenario-three-sales">10. Scenario 2 - One purchase matched to three sales</a></li>
|
||||
<li><a href="#appendix">11. Appendix - models and tables</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="fundamentals">
|
||||
<p class="section-title">1. Fundamentals and Glossary</p>
|
||||
<div class="chapter-card">
|
||||
<h2>Operating principles</h2>
|
||||
<p>Interacid will use Tradon to control physical sulfuric acid trading from contract capture to final settlement. The core business pattern is <strong>Drop Ship</strong>: the purchase and sale are commercially matched, and the product moves directly from supplier/loading point to customer/destination without an Interacid warehouse storage step.</p>
|
||||
<p>Each physical flow will be represented by a purchase contract, a sale contract, one or more shipment records, and physical lots that carry executed quantity, cost allocation, invoice status and matching status. The default contract tolerance is <strong>5%</strong> unless a customer, supplier or specific contract requires another tolerance.</p>
|
||||
<div class="note important">
|
||||
<strong>Important Note:</strong> Hedging, derivatives and FX cover tabs may exist in the configured application, but they are out of scope for Interacid's operational book. The teams will keep pricing and physical mechanics separate from hedging chapters because no hedging/FX process is expected for this scope.
|
||||
</div>
|
||||
|
||||
<h3>Key term mapping</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>Business term</th><th>Tradon term / model</th><th>Use in this book</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td>Purchase contract</td><td><a class="model-link" href="#purchase.purchase" data-tryton-model="purchase.purchase">purchase.purchase</a></td><td>Supplier-side commercial contract.</td></tr>
|
||||
<tr><td>Sale contract</td><td><a class="model-link" href="#sale.sale" data-tryton-model="sale.sale">sale.sale</a></td><td>Customer-side commercial contract.</td></tr>
|
||||
<tr><td>Physical lot</td><td><a class="model-link" href="#lot.lot" data-tryton-model="lot.lot">lot.lot</a></td><td>Executed quantity used for matching, costing and invoicing.</td></tr>
|
||||
<tr><td>Lot quantity state</td><td><a class="model-link" href="#lot.qt" data-tryton-model="lot.qt">lot.qt</a></td><td>Open, physical, matched or shipped quantity status used by matching screens.</td></tr>
|
||||
<tr><td>Shipment</td><td><a class="model-link" href="#stock.shipment.in" data-tryton-model="stock.shipment.in">stock.shipment.in</a></td><td>Operational record for shipment milestones, BL data, costs and lots.</td></tr>
|
||||
<tr><td>Budgeted/ordered/actual cost</td><td><a class="model-link" href="#fee.fee" data-tryton-model="fee.fee">fee.fee</a></td><td>Cost entered first at contract level, then ordered at shipment level, then allocated to physical lots.</td></tr>
|
||||
<tr><td>Price curve</td><td><a class="model-link" href="#price.price" data-tryton-model="price.price">price.price</a></td><td>Argus index or other market reference used by Basis/formula pricing.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="master-data">
|
||||
<p class="section-title">2. Master Data Setup</p>
|
||||
<div class="chapter-card">
|
||||
<h2>Party defaults and price curves</h2>
|
||||
<p>Before entering the trade, Back-office will make sure the supplier, customer, service providers and Argus curves exist. Party defaults reduce repeated entry on contracts and enforce Interacid's default tolerance discipline.</p>
|
||||
|
||||
<h3>Party screen - Contract and Execution tabs</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Tol - in %</strong></td><td><span class="req req-no">No</span></td><td>Default negative tolerance for contracts with the party. For Interacid sulfuric acid trading, enter <strong>5</strong> when the commercial relationship accepts +/-5% tolerance.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Tol + in %</strong></td><td><span class="req req-no">No</span></td><td>Default positive tolerance. It should normally mirror the negative tolerance unless a supplier/customer agreement says otherwise.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Weight basis</strong></td><td><span class="req req-no">No</span></td><td>Default commercial weight basis for the party, used when creating purchase or sale contracts.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Association</strong></td><td><span class="req req-no">No</span></td><td>Default trade rule or association reference. Use only when the commercial terms require it.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Origin</strong></td><td><span class="req req-no">No</span></td><td>Default product/geographic origin for documentation. For sulfuric acid, this should reflect the supplier or plant origin where relevant.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>SLA places</strong></td><td><span class="req req-no">No</span></td><td>Optional execution service cost matrix by location. Use for service providers where standard control, terminal or logistics costs are known by place.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Party Contract tab</div>
|
||||
Expected capture: open a supplier or customer party in Tradon, display the <strong>Contract</strong> tab with numbered red callouts on tolerance, weight basis, association, origin and initials. A second capture should show the <strong>Execution</strong> tab if SLA costs are configured.
|
||||
</div>
|
||||
|
||||
<h3>Price curve screen - Argus reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead>
|
||||
<tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Price index</strong></td><td><span class="req req-yes">Yes</span></td><td>Short index code used in pricing components. Example: <strong>ARGUS_SA_USD_MT</strong> or the final Interacid-approved Argus index naming convention.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Description</strong></td><td><span class="req req-yes">Yes</span></td><td>Human-readable description of the Argus sulfuric acid reference.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Index type</strong></td><td><span class="req req-no">No</span></td><td>Set to Spot or Future depending on the Argus source used. For regular physical sulfuric acid pricing, Spot will usually be sufficient unless monthly/future periods are configured.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Unit</strong></td><td><span class="req req-no">No</span></td><td>Commercial unit for the quotation, normally metric ton.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Currency</strong></td><td><span class="req req-no">No</span></td><td>Enter USD. All Interacid activity in this scope is USD-denominated.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Calendar</strong></td><td><span class="req req-no">No</span></td><td>Quotation calendar controlling valid price dates.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>Prices Values</strong></td><td><span class="req req-no">No</span></td><td>Daily or period values imported or keyed for Argus. Basis contracts and formula-priced lines will read these values.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Price curve and price values</div>
|
||||
Expected capture: show the Argus sulfuric acid curve header and the <strong>Prices Values</strong> tab with at least three dated quotation rows. Number the index, description, unit, currency, calendar and price values table.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="purchase-contract">
|
||||
<p class="section-title">3. Purchase Contract Entry</p>
|
||||
<div class="chapter-card">
|
||||
<p>The Trader or Back-office will create the purchase contract first. For drop ship, the purchase location and sale destination must be entered carefully because they drive matching, shipment, cost allocation and reporting.</p>
|
||||
<ol class="steps">
|
||||
<li>Open the purchase contract screen and click <strong>New</strong>.</li>
|
||||
<li>Enter the supplier, purchase date, currency USD, payment term and commercial reference.</li>
|
||||
<li>Enter the Interacid trade fields listed below.</li>
|
||||
<li>Add one purchase line for sulfuric acid, including quantity, tolerance, price type and concentration if concentration adjustment applies.</li>
|
||||
<li>Enter the budgeted costs on the purchase line or contract cost tab before shipment execution.</li>
|
||||
<li>Click <strong>Save</strong>, then follow the normal approval/confirmation process.</li>
|
||||
</ol>
|
||||
|
||||
<h3>Purchase contract header field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Weight basis</strong></td><td><span class="req req-yes">Yes</span></td><td>Commercial weight basis used for the sulfuric acid quantity. Back-office confirms the value from the supplier contract.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Certification</strong></td><td><span class="req req-yes">Yes</span></td><td>Certification attached to the physical contract if required for product documentation. Use the default if no special certificate is agreed.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Operator</strong></td><td><span class="req req-no">No</span></td><td>Operations owner who will follow the shipment and physical lot execution.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Trader</strong></td><td><span class="req req-no">No</span></td><td>Commercial owner of the purchase. This is used for internal follow-up and P&L ownership.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Our Reference</strong></td><td><span class="req req-no">No</span></td><td>Interacid internal reference. Example: <strong>ITSA-SA-P-0001</strong>.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Tol - in % / Tol + in %</strong></td><td><span class="req req-yes">Yes</span></td><td>Enter <strong>5</strong> and <strong>5</strong> by default unless the supplier contract specifies another tolerance.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>From location</strong></td><td><span class="req req-yes">Yes</span></td><td>Supplier loading location or origin terminal.</td></tr>
|
||||
<tr><td><span class="num">8</span></td><td><strong>To location</strong></td><td><span class="req req-yes">Yes</span></td><td>Customer destination or discharge point. For drop ship, this should align with the sale contract destination.</td></tr>
|
||||
<tr><td><span class="num">9</span></td><td><strong>Incoterm / Incoterm Location</strong></td><td><span class="req req-inh">Inherited</span></td><td>Commercial delivery rule and named place, copied from the supplier agreement.</td></tr>
|
||||
<tr><td><span class="num">10</span></td><td><strong>Origin</strong></td><td><span class="req req-no">No</span></td><td>Origin statement used for contract documentation and product traceability.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Purchase contract header</div>
|
||||
Expected capture: purchase contract form populated with an Interacid sulfuric acid supplier, USD currency, 5% tolerance, loading and destination locations, Incoterm and Interacid reference. Add numbered red callouts matching the table above.
|
||||
</div>
|
||||
|
||||
<h3>Purchase line field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Product</strong></td><td><span class="req req-inh">Base</span></td><td>Select the sulfuric acid product configured in Tradon.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Quantity / Unit</strong></td><td><span class="req req-inh">Base</span></td><td>Enter the contractual quantity in metric tons. Physical lots will later carry the executed quantity.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Price type</strong></td><td><span class="req req-no">No</span></td><td>Select <strong>Priced</strong> for fixed USD price. Select <strong>Basis</strong> when the line references Argus plus/minus a differential.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Premium/Discount</strong></td><td><span class="req req-no">No</span></td><td>Used for basis or differential pricing. Example: Argus + 2.50 USD/MT.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Concentration</strong></td><td><span class="req req-no">No</span></td><td>Enter contractual concentration when price must be adjusted by sulfuric acid concentration.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Inherit tolerance</strong></td><td><span class="req req-no">No</span></td><td>Leave checked for the default 5% contract tolerance. Untick only when the line has its own tolerance.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>Fees</strong></td><td><span class="req req-no">No</span></td><td>Enter budgeted costs at contract level before shipment. These will later be ordered at shipment level and allocated to lots.</td></tr>
|
||||
<tr><td><span class="num">8</span></td><td><strong>Pricing / Components</strong></td><td><span class="req req-no">No</span></td><td>For Basis contracts, add the Argus curve component and period rules. For Priced contracts, this tab may be minimal.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Purchase line tabs</div>
|
||||
Expected capture: purchase line showing sulfuric acid, quantity, price type, 5% inherited tolerance, concentration field, Fees tab and Pricing Components tab. Number the fields used in the table.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="sale-contract">
|
||||
<p class="section-title">4. Sale Contract Entry</p>
|
||||
<div class="chapter-card">
|
||||
<p>The sale contract represents the customer side of the drop-ship transaction. In the regular scenario it will match one purchase. In the split scenario, three sale contracts will be matched against the same purchase physical quantity.</p>
|
||||
<ol class="steps">
|
||||
<li>Create the sale contract from the sale menu or from the commercial workflow agreed with Trading.</li>
|
||||
<li>Enter the customer, USD currency, payment term and Incoterm.</li>
|
||||
<li>Use the same destination logic as the purchase contract so the drop-ship route is consistent.</li>
|
||||
<li>Add the sale line with sulfuric acid quantity, price type and concentration assumptions.</li>
|
||||
<li>Save and confirm the sale contract before lot matching.</li>
|
||||
</ol>
|
||||
|
||||
<h3>Sale contract header field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Weight basis</strong></td><td><span class="req req-yes">Yes</span></td><td>Weight basis agreed with customer.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Agent / Operator / Trader</strong></td><td><span class="req req-no">No</span></td><td>Commercial and execution owners. Fill when ownership must be visible in reporting.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Our Reference</strong></td><td><span class="req req-no">No</span></td><td>Interacid sale reference. Example: <strong>ITSA-SA-S-0001</strong>.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Tol - in % / Tol + in %</strong></td><td><span class="req req-yes">Yes</span></td><td>Enter <strong>5</strong> and <strong>5</strong> unless the customer contract says otherwise.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>From location</strong></td><td><span class="req req-yes">Yes</span></td><td>Drop-ship loading/origin location, aligned with the purchase when possible.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>To location</strong></td><td><span class="req req-yes">Yes</span></td><td>Customer discharge/destination location. This replaces the base warehouse display in the sale form.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>Incoterm / Incoterm Location</strong></td><td><span class="req req-inh">Inherited</span></td><td>Customer delivery term and named place.</td></tr>
|
||||
<tr><td><span class="num">8</span></td><td><strong>Required documents</strong></td><td><span class="req req-no">No</span></td><td>Document checklist for customer execution when a template is used.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Sale contract header</div>
|
||||
Expected capture: sale contract form populated with an Interacid customer, USD currency, 5% tolerance, from/to locations and customer Incoterm. Number the fields above.
|
||||
</div>
|
||||
|
||||
<h3>Sale line field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Quantity / Unit</strong></td><td><span class="req req-inh">Base</span></td><td>Customer contractual quantity. In the three-sales scenario, enter each sale quantity separately.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Price type</strong></td><td><span class="req req-no">No</span></td><td>Usually <strong>Priced</strong>; use <strong>Basis</strong> where the customer price references Argus plus/minus a differential.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Premium/Discount</strong></td><td><span class="req req-no">No</span></td><td>Basis adjustment or commercial differential.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Concentration</strong></td><td><span class="req req-no">No</span></td><td>Customer-side concentration assumption where price adjustment applies.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Lots</strong></td><td><span class="req req-auto">After matching</span></td><td>Displays lots allocated/matched to the sale after the matching wizard is completed.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Fees</strong></td><td><span class="req req-no">No</span></td><td>Use when sale-side costs or recoveries must be attached to the sale line.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>Pricing rule</strong></td><td><span class="req req-no">No</span></td><td>Free-text explanation shown on reports for Basis or formula-priced customer lines.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="costs">
|
||||
<p class="section-title">5. Costs: Budgeted, Ordered and Lot-Specific</p>
|
||||
<div class="chapter-card">
|
||||
<p>Interacid will control costs in three steps. First, Trading or Back-office enters <strong>budgeted costs</strong> at contract level. Second, Operations creates or updates <strong>ordered costs</strong> at shipment level when the service is committed. Third, final or specific costs are allocated to the <strong>physical lots</strong> contained in the shipment.</p>
|
||||
|
||||
<div class="calc">
|
||||
Example cost allocation:<br>
|
||||
Freight budget = 80.00 USD/MT x 10,000 MT = 800,000.00 USD<br>
|
||||
Ordered freight = 82.50 USD/MT x 10,000 MT = 825,000.00 USD<br>
|
||||
Difference to monitor = 25,000.00 USD unfavorable
|
||||
</div>
|
||||
|
||||
<h3>Fee screen field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Type</strong></td><td><span class="req req-yes">Yes</span></td><td>Select <strong>Budgeted</strong> at contract level, <strong>Ordered</strong> at shipment level and <strong>Actual</strong> when final invoice information is known.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>P/R</strong></td><td><span class="req req-yes">Yes</span></td><td>Pay/receive indicator. Freight, inspection and service costs are normally <strong>PAY</strong>.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Product</strong></td><td><span class="req req-yes">Yes</span></td><td>Service product, such as Maritime freight, inspection, terminal service, demurrage or other configured cost type.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Supplier</strong></td><td><span class="req req-yes">Yes</span></td><td>Service provider or vendor responsible for the cost.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Mode</strong></td><td><span class="req req-yes">Yes</span></td><td>Calculation mode: lump sum, per quantity, percentage of price/rate/cost, or per packing.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Price</strong></td><td><span class="req req-no">No</span></td><td>Rate or amount according to mode. For freight per metric ton, enter the USD/MT rate.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>Quantity / Unit</strong></td><td><span class="req req-no">No</span></td><td>Quantity used to calculate the amount. It can be inherited from lots or shipment depending on setup.</td></tr>
|
||||
<tr><td><span class="num">8</span></td><td><strong>Lots</strong></td><td><span class="req req-no">No</span></td><td>Specific physical lots receiving the cost. Use this when a cost applies only to part of the shipment.</td></tr>
|
||||
<tr><td><span class="num">9</span></td><td><strong>Amount</strong></td><td><span class="req req-auto">Computed</span></td><td>Calculated amount used for accrual, invoice checking and P&L.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Fee entry and lot allocation</div>
|
||||
Expected capture: show a budgeted contract fee, then an ordered shipment fee, then the fee lots selection with one or several physical lots selected. Number Type, Product, Supplier, Mode, Price, Quantity, Unit, Lots and Amount.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="shipment">
|
||||
<p class="section-title">6. Drop-Ship Shipment Execution</p>
|
||||
<div class="chapter-card">
|
||||
<p>For Interacid's drop-ship process, the shipment record is the operational bridge between the purchase, the sale and the physical lots. Operations will maintain carrier, vessel, BL, ETA, booking, receipt and control information.</p>
|
||||
<ol class="steps">
|
||||
<li>From Lots Management, select open purchase/sale quantities to ship.</li>
|
||||
<li>Create or open the shipment record.</li>
|
||||
<li>Enter carrier, transport type, vessel, cargo mode, BL details and logistics dates.</li>
|
||||
<li>Convert budgeted costs into ordered shipment costs where service commitments are known.</li>
|
||||
<li>Create physical lots for the shipment once quantities are known.</li>
|
||||
</ol>
|
||||
|
||||
<h3>Inbound/drop-ship shipment field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Carrier</strong></td><td><span class="req req-no">No</span></td><td>Carrier party or logistics provider responsible for movement.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>From location</strong></td><td><span class="req req-no">No</span></td><td>Loading point/origin terminal.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>To location</strong></td><td><span class="req req-no">No</span></td><td>Customer destination/discharge point.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Transport type</strong></td><td><span class="req req-no">No</span></td><td>Select vessel, truck or other. Sulfuric acid seaborne movements will generally use vessel.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Vessel</strong></td><td><span class="req req-no">No</span></td><td>Vessel master record when applicable.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Cargo Mode</strong></td><td><span class="req req-yes">Yes</span></td><td>Select bulk or container. Sulfuric acid is expected to be bulk unless a specific containerized flow is confirmed.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>BL number / BL date</strong></td><td><span class="req req-no">No</span></td><td>Bill of lading reference and date. These drive pricing and invoicing milestones where contract terms depend on BL.</td></tr>
|
||||
<tr><td><span class="num">8</span></td><td><strong>ETA / ETD / Arrival</strong></td><td><span class="req req-no">No</span></td><td>Operational milestone dates used by Operations to track shipment status and by Back-office for expected invoicing.</td></tr>
|
||||
<tr><td><span class="num">9</span></td><td><strong>Fees</strong></td><td><span class="req req-no">No</span></td><td>Ordered freight and logistics costs attached to the shipment.</td></tr>
|
||||
<tr><td><span class="num">10</span></td><td><strong>Lots</strong></td><td><span class="req req-auto">After lot creation</span></td><td>Shipment lot quantities created from the open contract quantities.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Drop-ship shipment</div>
|
||||
Expected capture: shipment form with carrier, from/to locations, vessel, cargo mode, BL date/number, ETA/ETD and the Fees and Lots tabs. Number the fields above.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="lots">
|
||||
<p class="section-title">7. Physical Lots and Matching</p>
|
||||
<div class="chapter-card">
|
||||
<h2>Create physical lots</h2>
|
||||
<p>Physical lots are created when shipment quantities are known. They are the operational unit used to allocate ordered costs, match purchase to sale and support invoicing.</p>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Quantity available</strong></td><td><span class="req req-auto">Read-only</span></td><td>Open quantity available to split into physical lots.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Shipment In / Internal / Out</strong></td><td><span class="req req-no">No</span></td><td>Shipment source selected by the workflow. For drop ship, use the relevant shipment carrying the direct movement.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Lot quantity</strong></td><td><span class="req req-no">No</span></td><td>Quantity to create for each physical lot. In the three-sales scenario, create lot quantities aligned with the sale splits.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Net weight / Gross weight</strong></td><td><span class="req req-no">No</span></td><td>Executed lot weights. Use net weight for commercial valuation unless the contract specifies otherwise.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Unit</strong></td><td><span class="req req-yes">Yes</span></td><td>Commercial unit, normally metric ton.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Premium</strong></td><td><span class="req req-no">No</span></td><td>Lot-specific premium or discount if commercial terms differ by lot.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Add physical lots</div>
|
||||
Expected capture: Add physical lots wizard with the available quantity and one or more lot rows. For the split scenario, show three rows matching the three sale contracts.
|
||||
</div>
|
||||
|
||||
<h2>Match purchase and sale lots</h2>
|
||||
<p>The matching wizard links purchase-side quantities to sale-side quantities. The total quantity entered on the purchase side should equal the total quantity entered on the sale side before the user applies matching.</p>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Purchase</strong></td><td><span class="req req-no">No</span></td><td>Filter purchase candidates to the contract being matched.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Sale</strong></td><td><span class="req req-no">No</span></td><td>Filter sale candidates to one sale contract, or leave filters broader when matching one purchase to several sales.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Qt type</strong></td><td><span class="req req-no">No</span></td><td>Use Open for open contract quantities, Physic for physical lots or All for broad review.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Purchase lot table</strong></td><td><span class="req req-auto">Computed</span></td><td>Shows available purchase lots and quantities.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Qt to match</strong></td><td><span class="req req-no">No</span></td><td>Quantity entered by Operations or Back-office for each purchase and sale candidate.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Sale lot table</strong></td><td><span class="req req-auto">Computed</span></td><td>Shows sale-side candidates. In the split scenario, enter quantities against three sale rows.</td></tr>
|
||||
<tr><td><span class="num">7</span></td><td><strong>Total purchase / Total sale</strong></td><td><span class="req req-auto">Computed</span></td><td>Control totals. Apply matching only when totals agree within accepted tolerance.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Matching wizard</div>
|
||||
Expected capture: Matching wizard with purchase and sale filters, purchase lot rows, sale lot rows and total quantities. For the second scenario, show one purchase quantity split across three sale rows.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="pricing">
|
||||
<p class="section-title">8. Pricing and Concentration Adjustment</p>
|
||||
<div class="chapter-card">
|
||||
<p>Most Interacid sulfuric acid contracts will be <strong>Priced</strong>, but Basis pricing is also in scope. Basis lines use a pricing component linked to an Argus price curve and a premium/discount. Where agreed, the final price can be adjusted according to concentration.</p>
|
||||
<div class="calc">
|
||||
Basis price example:<br>
|
||||
Final price = Argus reference + premium/discount<br>
|
||||
Final price = 95.00 USD/MT + 2.50 USD/MT = 97.50 USD/MT
|
||||
</div>
|
||||
<div class="calc">
|
||||
Concentration adjustment example:<br>
|
||||
Adjusted price = Contract price x Actual concentration / Contract concentration<br>
|
||||
Adjusted price = 100.00 x 98.5 / 98.0 = 100.51 USD/MT<br>
|
||||
[@vendor: confirm final Interacid concentration adjustment formula and rounding rule]
|
||||
</div>
|
||||
|
||||
<h3>Pricing component field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Price Source</strong></td><td><span class="req req-yes">Yes</span></td><td>Select Curve when pricing from Argus. Select Matrix only if a configured route/quality matrix is used.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Fixation type</strong></td><td><span class="req req-no">No</span></td><td>Reference fixation type for the curve, for example official quotation or settlement.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Ratio</strong></td><td><span class="req req-no">No</span></td><td>Component weighting percentage. Use 100% for a single Argus reference unless the contract specifies a blend.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Curve</strong></td><td><span class="req req-no">No</span></td><td>Select the approved Argus sulfuric acid price curve.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Calendar</strong></td><td><span class="req req-no">No</span></td><td>Quotation calendar used to decide valid pricing dates.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Period rules</strong></td><td><span class="req req-no">No</span></td><td>Rules that define pricing and application windows, such as dates before BL or a monthly quotation window.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
<h3>Pricing record field reference</h3>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>#</th><th>Attribute</th><th>Required</th><th>Operational description</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td><span class="num">1</span></td><td><strong>Date</strong></td><td><span class="req req-no">No</span></td><td>Quotation or fixing date.</td></tr>
|
||||
<tr><td><span class="num">2</span></td><td><strong>Component</strong></td><td><span class="req req-no">No</span></td><td>Price component being fixed.</td></tr>
|
||||
<tr><td><span class="num">3</span></td><td><strong>Qt</strong></td><td><span class="req req-no">No</span></td><td>Quantity fixed on the date.</td></tr>
|
||||
<tr><td><span class="num">4</span></td><td><strong>Settl. price</strong></td><td><span class="req req-no">No</span></td><td>Argus or final settlement price for the date.</td></tr>
|
||||
<tr><td><span class="num">5</span></td><td><strong>Fixed qt price</strong></td><td><span class="req req-auto">Computed</span></td><td>Weighted average price for fixed quantities.</td></tr>
|
||||
<tr><td><span class="num">6</span></td><td><strong>Unfixed qt</strong></td><td><span class="req req-auto">Computed</span></td><td>Remaining quantity still to be priced.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Pricing component and fixing records</div>
|
||||
Expected capture: contract line Pricing tab with an Argus component, period rule and pricing dates. Number the curve, ratio, calendar, date, quantity and settlement price fields.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="scenario-one">
|
||||
<p class="section-title">9. Worked Scenario 1 - One Purchase Matched with One Sale</p>
|
||||
<div class="scenario-card">
|
||||
<div class="phase-header">
|
||||
<span class="phase-badge">Scenario 1</span>
|
||||
<span class="phase-title">Regular Drop Ship</span>
|
||||
<div class="phase-line"></div>
|
||||
</div>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th style="width:230px">Step</th><th style="width:150px">Actor</th><th>Expected result</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td>Create purchase contract</td><td><span class="actor actor-trade">Trader / Back-office</span></td><td>One USD purchase contract for sulfuric acid, 5% tolerance, supplier route and budgeted costs.</td></tr>
|
||||
<tr><td>Create sale contract</td><td><span class="actor actor-trade">Trader / Back-office</span></td><td>One USD sale contract with matching product, route, quantity and price type.</td></tr>
|
||||
<tr><td>Create drop-ship shipment</td><td><span class="actor actor-ops">Operations</span></td><td>Shipment contains carrier/vessel or logistics reference, BL data, ETA and ordered costs.</td></tr>
|
||||
<tr><td>Create physical lot</td><td><span class="actor actor-ops">Operations</span></td><td>One physical lot carries the executed shipment quantity.</td></tr>
|
||||
<tr><td>Apply matching</td><td><span class="actor actor-back">Back-office</span></td><td>Purchase lot quantity equals sale lot quantity and both are linked.</td></tr>
|
||||
<tr><td>Allocate costs to lot</td><td><span class="actor actor-back">Back-office / Finance</span></td><td>Ordered freight and services are allocated to the physical lot for P&L and invoice control.</td></tr>
|
||||
<tr><td>Finalize pricing and invoicing</td><td><span class="actor actor-fin">Finance</span></td><td>Priced line invoices directly; Basis line uses Argus pricing records and concentration adjustment if applicable.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Scenario 1 flow evidence</div>
|
||||
Expected captures: purchase contract, sale contract, shipment, add physical lot wizard, matching wizard with one purchase row and one sale row, and fee allocation on the physical lot.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="scenario-three-sales">
|
||||
<p class="section-title">10. Worked Scenario 2 - One Purchase Matched with Three Sales</p>
|
||||
<div class="scenario-card">
|
||||
<div class="phase-header">
|
||||
<span class="phase-badge">Scenario 2</span>
|
||||
<span class="phase-title">Purchase Split Across Three Sales</span>
|
||||
<div class="phase-line"></div>
|
||||
</div>
|
||||
<p>In this variant, one purchase shipment is commercially allocated to three customer sale contracts. Operations creates physical lots or lot quantities that match the commercial split, then Back-office matches the purchase quantity against the three sale quantities.</p>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th style="width:230px">Step</th><th style="width:150px">Actor</th><th>Expected result</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td>Create one purchase contract</td><td><span class="actor actor-trade">Trader / Back-office</span></td><td>Purchase quantity covers the combined expected sale quantities plus tolerance.</td></tr>
|
||||
<tr><td>Create three sale contracts</td><td><span class="actor actor-trade">Trader / Back-office</span></td><td>Each sale contract has its own customer, price, delivery terms and quantity.</td></tr>
|
||||
<tr><td>Create shipment</td><td><span class="actor actor-ops">Operations</span></td><td>Shipment represents the full purchase movement.</td></tr>
|
||||
<tr><td>Split physical lots</td><td><span class="actor actor-ops">Operations</span></td><td>Physical lot rows are created to mirror the three sale quantities, or one lot is matched in three quantities depending on operational choice.</td></tr>
|
||||
<tr><td>Apply matching</td><td><span class="actor actor-back">Back-office</span></td><td>The purchase total equals the combined total of the three sale rows.</td></tr>
|
||||
<tr><td>Allocate costs</td><td><span class="actor actor-back">Back-office / Finance</span></td><td>Shipment costs are allocated to the specific physical lots so each sale carries its correct cost share.</td></tr>
|
||||
<tr><td>Invoice each sale</td><td><span class="actor actor-fin">Finance</span></td><td>Each customer invoice reflects its matched lot quantity, price type and any concentration adjustment.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="calc">
|
||||
Example split:<br>
|
||||
Purchase lot = 30,000 MT<br>
|
||||
Sale A = 10,000 MT, Sale B = 8,000 MT, Sale C = 12,000 MT<br>
|
||||
Matching control = 10,000 + 8,000 + 12,000 = 30,000 MT
|
||||
</div>
|
||||
<div class="screenshot-placeholder">
|
||||
<div class="shot-title">Screenshot placeholder - Scenario 2 matching</div>
|
||||
Expected capture: matching wizard showing one purchase contract/lot and three sale rows. The <strong>Total purchase</strong> and <strong>Total sale</strong> fields must agree before applying matching.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<section id="appendix">
|
||||
<p class="section-title">11. Appendix - Models and Tables</p>
|
||||
<div class="chapter-card">
|
||||
<h2>Primary models used by this book</h2>
|
||||
<div class="table-wrap">
|
||||
<table>
|
||||
<thead><tr><th>Screen / function</th><th>Tryton model</th><th>PostgreSQL table</th><th>Role</th></tr></thead>
|
||||
<tbody>
|
||||
<tr><td>Purchase contract</td><td><code>purchase.purchase</code></td><td><code>purchase_purchase</code></td><td>Supplier-side contract header.</td></tr>
|
||||
<tr><td>Purchase line</td><td><code>purchase.line</code></td><td><code>purchase_line</code></td><td>Supplier product, quantity, price and cost line.</td></tr>
|
||||
<tr><td>Sale contract</td><td><code>sale.sale</code></td><td><code>sale_sale</code></td><td>Customer-side contract header.</td></tr>
|
||||
<tr><td>Sale line</td><td><code>sale.line</code></td><td><code>sale_line</code></td><td>Customer product, quantity, price and cost line.</td></tr>
|
||||
<tr><td>Shipment</td><td><code>stock.shipment.in</code></td><td><code>stock_shipment_in</code></td><td>Drop-ship execution, BL, dates, fees and lots.</td></tr>
|
||||
<tr><td>Physical lot</td><td><code>lot.lot</code></td><td><code>lot_lot</code></td><td>Executed physical quantity used for matching and costing.</td></tr>
|
||||
<tr><td>Lot quantity</td><td><code>lot.qt</code></td><td><code>lot_qt</code></td><td>Available, physical, matched and shipment quantity state.</td></tr>
|
||||
<tr><td>Matching wizard</td><td><code>lot.matching.start</code></td><td>Transient</td><td>Matches purchase quantities to sale quantities.</td></tr>
|
||||
<tr><td>Add physical lots wizard</td><td><code>lot.add.lot</code></td><td>Transient</td><td>Splits available shipment quantity into physical lots.</td></tr>
|
||||
<tr><td>Fees</td><td><code>fee.fee</code></td><td><code>fee_fee</code></td><td>Budgeted, ordered and actual costs.</td></tr>
|
||||
<tr><td>Fee allocation</td><td><code>fee.lots</code></td><td><code>fee_lots</code></td><td>Fee-to-lot allocation.</td></tr>
|
||||
<tr><td>Pricing component</td><td><code>pricing.component</code></td><td><code>pricing_component</code></td><td>Argus curve or matrix component for Basis pricing.</td></tr>
|
||||
<tr><td>Pricing fixing</td><td><code>pricing.pricing</code></td><td><code>pricing_pricing</code></td><td>Pricing/fixing values by date and quantity.</td></tr>
|
||||
<tr><td>Price curve</td><td><code>price.price</code></td><td><code>price_price</code></td><td>Argus market index master data.</td></tr>
|
||||
<tr><td>Price value</td><td><code>price.price_value</code></td><td><code>price_price_value</code></td><td>Curve quotation values.</td></tr>
|
||||
<tr><td>Party</td><td><code>party.party</code></td><td><code>party_party</code></td><td>Customer, supplier and service provider master data.</td></tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="note open-item">
|
||||
<strong>Open item:</strong> Screenshots must be replaced with annotated captures from Interacid's configured Tradon environment. Never reuse another client's captures.
|
||||
</div>
|
||||
</div>
|
||||
</section>
|
||||
|
||||
<footer>
|
||||
<span>Sources: Tradon screen reference Markdown files and Interacid public service page.</span>
|
||||
<span>Generated for Interacid Trading S.A - Practice Book draft.</span>
|
||||
</footer>
|
||||
</main>
|
||||
|
||||
<script>
|
||||
document.addEventListener('click', function(event) {
|
||||
var link = event.target.closest('a[data-tryton-model]');
|
||||
if (!link) {
|
||||
return;
|
||||
}
|
||||
event.preventDefault();
|
||||
|
||||
var topWindow = window.top || window;
|
||||
var hash = topWindow.location.hash || '#tradon';
|
||||
var database = hash.replace(/^#/, '').split('/')[0] || 'tradon';
|
||||
topWindow.location.hash = database + '/model/' + link.dataset.trytonModel;
|
||||
});
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -149,6 +149,17 @@ End-to-end commodity trading operations.
|
||||
- [Settlements & final P&L](07_trade_commodity_management/16_settlements_and_final_p_and_l.md)
|
||||
- [Regulatory reporting (position limits, trade reporting)](07_trade_commodity_management/17_regulatory_reporting_position_limits_trade_reporting.md)
|
||||
|
||||
Screen and table references:
|
||||
|
||||
- [Purchase and sale contract screens](07_trade_commodity_management/screen_reference_purchase_sale_contracts.md)
|
||||
- [Shipment, physical lot and matching screens](07_trade_commodity_management/screen_reference_logistics_lots_matching.md)
|
||||
- [Fee, pricing and MTM screens](07_trade_commodity_management/screen_reference_fees_pricing_mtm.md)
|
||||
- [Party and price curve master data screens](07_trade_commodity_management/screen_reference_party_price_curve.md)
|
||||
|
||||
Generated HTML practice books:
|
||||
|
||||
- [Interacid Tradon Practice Book](ITSA/Interacid_Tradon_Practice_Book.html)
|
||||
|
||||
## Hire to Retire (H2R) / Human Capital Management
|
||||
|
||||
From talent acquisition through employee lifecycle to separation.
|
||||
|
||||
Reference in New Issue
Block a user