<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Data Model on Learn Oracle OTM</title><link>https://www.oracle-otm.com/posts/data-model/</link><description>Recent content in Data Model on Learn Oracle OTM</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 06 May 2016 20:15:00 +0000</lastBuildDate><atom:link href="https://www.oracle-otm.com/posts/data-model/index.xml" rel="self" type="application/rss+xml"/><item><title>Domains, Standard Schema and Data Dictionary</title><link>https://www.oracle-otm.com/posts/otm-domains-standard-schema-and-data-dictionary/</link><pubDate>Mon, 02 May 2016 16:34:00 +0000</pubDate><guid>https://www.oracle-otm.com/posts/otm-domains-standard-schema-and-data-dictionary/</guid><description>&lt;p&gt;OTM organises all of its data using a &lt;strong&gt;domain&lt;/strong&gt; model. Understanding domains, the database schema, and how business objects are identified is foundational for anyone working with OTM data — whether you are building integrations, writing reports, or troubleshooting transactions.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Domains:&lt;/strong&gt;&lt;/p&gt;
&lt;div class="field-box"&gt;&lt;strong&gt;What is a domain?&lt;/strong&gt; A domain is a logical grouping of OTM data for a business unit. A corporation with multiple shipping divisions — say, Merchandise and Food &amp; Beverage — would typically have one domain per division. Users and roles are tied to a domain, so a user in one domain cannot see or modify data in another.&lt;/div&gt;
&lt;div class="field-box"&gt;&lt;strong&gt;Domain hierarchy:&lt;/strong&gt; Domains can be nested — a parent domain at the corporate level with child domains under each business unit. Configuration defined at the parent level (e.g. Item Numbers, Agents, Rate Offerings) is shared across all child domains, while each child domain can also maintain its own configuration.&lt;/div&gt;
&lt;div class="field-box"&gt;&lt;strong&gt;DOMAIN_NAME column:&lt;/strong&gt; Every table in OTM includes a &lt;code&gt;DOMAIN_NAME&lt;/code&gt; column that ties each row to its domain. This is how OTM isolates data between business units within a single database instance.&lt;/div&gt;
&lt;p&gt;&lt;strong&gt;GID and XID — How OTM Identifies Business Objects:&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>Order Management Data Structure</title><link>https://www.oracle-otm.com/posts/otm-order-management-data-structure/</link><pubDate>Tue, 03 May 2016 17:42:00 +0000</pubDate><guid>https://www.oracle-otm.com/posts/otm-order-management-data-structure/</guid><description>&lt;p&gt;OTM models order management across three levels: the &lt;strong&gt;Purchase Order&lt;/strong&gt; (what was ordered), the &lt;strong&gt;Order Release&lt;/strong&gt; (a confirmed booking for movement), and &lt;strong&gt;Order Movements&lt;/strong&gt; (the planned legs of that movement). Understanding this hierarchy and the underlying tables is essential for integration work and troubleshooting.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Purchase Order (Order Base):&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;A Purchase Order represents the commercial transaction — what items are being moved, from where, to where, and under what terms. POs are typically created in an ERP system (e.g. Oracle E-Business Suite) and sent to OTM via inbound integration. Note that POs often lack exact weight and volume details, which are required for shipment planning — those are defined on the Order Release.&lt;/p&gt;</description></item><item><title>Shipment Management Data Structure</title><link>https://www.oracle-otm.com/posts/otm-shipment-management-data-structure/</link><pubDate>Tue, 03 May 2016 20:01:00 +0000</pubDate><guid>https://www.oracle-otm.com/posts/otm-shipment-management-data-structure/</guid><description>&lt;p&gt;A shipment in OTM consists of one or more &lt;strong&gt;Equipment&lt;/strong&gt; records (containers or trailers), &lt;strong&gt;Shipment Ship Units&lt;/strong&gt; loaded into each equipment, and &lt;strong&gt;Shipment Ship Unit Lines&lt;/strong&gt; that link back to the original Order Release lines. Understanding this structure is essential for troubleshooting planning results, writing integration queries, and working with carrier tracking events.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Shipment Structure:&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;When OTM plans an Order Release to a shipment, it creates Shipment Ship Units and assigns them to equipment. If a Bulk Plan splits an order across two containers — say 60 units in one and 40 in another — that split is recorded at the Shipment Ship Unit Line level. This line is the critical link between the shipment and the originating order: it ties back to a specific item, Order Release Line, Order Release, and Order Base.&lt;/p&gt;</description></item><item><title>Contract &amp; Rate Management Data Structure</title><link>https://www.oracle-otm.com/posts/otm-contract-rate-management-data-structure/</link><pubDate>Fri, 06 May 2016 17:29:00 +0000</pubDate><guid>https://www.oracle-otm.com/posts/otm-contract-rate-management-data-structure/</guid><description>&lt;p&gt;OTM models carrier contracting across five layers: &lt;strong&gt;Service Provider&lt;/strong&gt; (who moves the freight), &lt;strong&gt;Rate Service&lt;/strong&gt; (transit time commitments), &lt;strong&gt;Rate Distance&lt;/strong&gt; (how mileage is calculated), &lt;strong&gt;Rate Offering&lt;/strong&gt; (the contract), and &lt;strong&gt;Rate Records&lt;/strong&gt; (the actual cost lanes). Understanding this structure is essential for rate setup, planning troubleshooting, and freight cost analysis.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Service Provider:&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;A Service Provider (carrier) is the party that physically moves freight. They own or manage trucks, containers, trailers, and drivers. They receive tender requests from OTM specifying origin, destination, weight, volume, and shipment dates — and issue invoices once delivery is complete.&lt;/p&gt;</description></item><item><title>Business Process Automation Data Structure</title><link>https://www.oracle-otm.com/posts/business-process-automation-data-structure/</link><pubDate>Fri, 06 May 2016 20:15:00 +0000</pubDate><guid>https://www.oracle-otm.com/posts/business-process-automation-data-structure/</guid><description>&lt;p&gt;The Business Process Automation (BPA) module handles the technical configuration layer of OTM — workflows, notifications, outbound integrations, reports, and transmission logging. The tables below are useful when troubleshooting agent behaviour, auditing integration traffic, or diagnosing report failures.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Contacts:&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;A Contact in OTM defines a communication endpoint — an email address, fax number, or integration URL — that OTM can reach when sending notifications or outbound data. Contacts can be associated with:&lt;/p&gt;</description></item></channel></rss>