Skip to main content

Common Entities

📄️Article

An Article represents a tradeable product or commodity in the system — for example an agricultural raw material, a processed food product, or a physical good. It is the core item master data entity that serves as the reference point across the entire platform: articles appear on contracts, contract positions, recipe positions, transaction positions, price lists, and enquiry properties. Nearly every operational workflow — from agreeing a trade to weighing goods at intake to generating an invoice — references an article.

📄️CallingClause

A CallingClause is a salutation or greeting form stored on address records, used to address correspondence, emails, and printed documents to a contact in a contextually appropriate and personalized way. Examples include "Dear Mr.", "Dear Ms.", "Dear Dr.", or "To Whom It May Concern". The CallingClause also carries a gender flag, which allows the system to apply grammatically correct gendered forms in languages where salutations are gender-dependent — particularly relevant for German-language documents where "Sehr geehrter Herr" and "Sehr geehrte Frau" are distinct forms.

📄️CoPosType (Contract Position Type)

A CoPosType is a classification entity that categorizes individual contract positions (CoPos) by their functional role within a contract. Common examples include a "Main Position" (the primary agreed delivery of goods), a "Premium Position" (a quality-based surcharge), a "Deduction Position" (a quantity or price reduction for moisture, impurities, or other quality shortfalls), or a "Service Position" (a fee for storage, handling, or analysis). Different position types may be treated differently by the invoicing logic — some are included in the net contract value, others are added as surcharges, and deduction positions reduce the payable amount.

📄️Contract

A Contract is the central trade document formalizing an agreement between two parties for the purchase or sale of specific goods. It defines the commercial terms — which articles in what quantities at what prices — as well as the logistical terms: where goods are to be delivered, under which transport responsibility, which delivery conditions (Incoterms) apply, and what the target completion date is. Tax and invoicing configuration (tax group, tax method, invoicing behavior) is also captured at the contract level, ensuring that every position and resulting invoice is generated with the correct fiscal treatment.

📄️ContractVersion

A ContractVersion is a versioning sub-classification that sits beneath a ContractType, allowing a single contract type to have multiple named variants or form editions. In practice this is used when the same kind of contract covers several slightly different variants depending on trade relationship or regulatory context — for example a standard grain purchase contract vs. a special organic grain purchase contract, or different clause editions for domestic vs. export trades.

📄️Currency

A Currency is a master data entry representing a monetary currency used across the system — in contracts, payments, price lists, and partner master data. Each currency stores an exchange rate relative to the system's base currency (Euro), which the platform uses to convert values when multi-currency transactions need to be compared or consolidated in reporting. One currency can be flagged as the system default, pre-selecting it in new records and as the fallback when no explicit currency is specified.

📄️EnqPropUnit (Enquiry Property Unit)

An EnqPropUnit defines a unit of measurement used for properties within questionnaires and enquiry forms — for example kilograms (kg), tonnes (t), hectoliters (hl), or percentage (%). Each unit stores a conversion factor relative to a base storage unit, enabling the system to convert quantities entered in user-friendly field units into the canonical storage unit used internally for calculations and comparisons. A decimal precision limit controls how many decimal places are shown and accepted in input fields that use this unit.

📄️PGVariant (Product Group Variant)

A PGVariant is a specific variety or sub-type within a product group — used to differentiate articles at a finer granularity than the product group level alone allows. In an agricultural context, a PGVariant typically represents a crop variety (e.g. "Pannonikus" within the wheat product group) or a quality/grade designation (e.g. "Premium" within an oilseed group). This allows the system to track and report on variety-specific volumes, prices, and quality data without creating separate top-level product groups for each variety.

📄️PartnerPartnerType

A PartnerPartnerType is a junction record that assigns one or more role types to a partner. Partner types define the roles a partner can play within the system — common examples are "Supplier", "Customer", "Carrier", "Producer", or "Commission Agent". A single partner can hold multiple types simultaneously, reflecting the reality that the same business entity often acts in different capacities: a farm might be both a producer delivering grain and a customer buying certified seeds.

📄️RefBaseAmount

A RefBaseAmount (Reference Base Amount) defines a canonical quantity unit used as the baseline for price and volume calculations within a product group. In commodity trading, prices are often quoted per tonne, per hectoliter, or per standardized quality unit — but actual physical quantities measured at the weighbridge may be in kilograms, liters, or other raw units. The RefBaseAmount provides the conversion anchor that allows the system to express all quantities in a consistent reference unit for pricing, invoicing, and reporting purposes.

📄️StorePeriod

A StorePeriod defines a named time window used to categorize warehouse inventory and contracts by when goods were stored or produced. In agricultural and commodity trading contexts, a storage period typically corresponds to a harvest season, a marketing year, or a fiscal quarter — for example "Harvest 2024" or "Q1 2025". This temporal categorization is fundamental for inventory management: goods from different periods can carry different prices, quality grades, certifications, or traceability requirements, even if they are physically the same commodity sitting in the same warehouse.

📄️Tax

A Tax entry defines a specific tax rate used in the system — for example 20% standard VAT, 10% reduced VAT, or 0% for tax-exempt goods. Each Tax belongs to a tax group (TaxGrp) which collects all applicable rates for a given fiscal regime, and the combination of group and rate determines exactly which percentage is applied to a given transaction. Tax entries are referenced on contract positions, shopping cart positions, and invoices to calculate the correct tax amount for each line item.

📄️TaxMethod

A TaxMethod defines the calculation method used to determine how tax is handled for a contract or invoice — specifically whether prices are expressed inclusive or exclusive of tax, and whether any special fiscal treatment applies. Common tax methods include "net invoicing" (prices shown without tax, tax added on top at invoice time), "gross invoicing" (tax already included in the displayed price, broken out on the invoice), and "reverse charge" (where the tax liability is transferred from the seller to the buyer, typically in B2B cross-border transactions within the EU).

📄️Trans (Transaction)

A Trans is the header record for a stock movement event — a goods receipt at intake, a goods issue on dispatch, or any other warehouse operation that changes the inventory position. It acts as the organizational umbrella under which all individual weighed or counted items (TransPos) are grouped. A single transaction might represent a full truck delivery containing twenty different positions with different articles, qualities, and weights — all belonging to the same physical arrival event at the facility.

📄️TransPos (Transaction Position)

A TransPos is a single weighed or measured item within a stock transaction — the line-level record of one particular batch or delivery unit within a goods movement event. Where the Trans header captures the who, when, and why of a movement, each TransPos captures the physical detail: which article, in what net quantity, of which quality and variety, carrying which lot identifiers. Multiple TransPos records can exist under a single Trans, representing the individual weighings or sub-lots that together make up the complete delivery or dispatch.