| Agreement | ff0d9deb-c473-ea11-ada5-40b034e2c22b | true | true | ||||||
| Agreement | 64363a81-b4fc-e911-80eb-9cd21e38f3a4 | Agreement | true | Data about agreements (actual or potential) regarding the way business is to be conducted. Examples can include: * Contracts with Customers regarding charge rates and other terms and conditions for the shipping of cargo * Rate agreements with Suppliers for intermodal transport * Proposed contracts and templates for contracts * Standard terms and conditions and charge rates defined by the Enterprise, such as Base Rate Tariffs of Tiered Contracts * Agreements regarding Network Capacity. Eg Slot Charter Agreements, Vessel Sharing Agreements Exclusion: Customer Requirements (confirmed or otherwise) such as Bookings or standing requirements regarding the nature and mode of communication. | true | true | true | Transactional | João Santos |
| Asset Agreement | 8b3a0566-2d49-ed11-a428-a0510b9e9705 | Agreement | true | Data about equipment lease agreements, typically and mostly used for setting up the contracts that Maersk does with container leasing companies. | true | true | true | Transactional | João Santos |
| Rate | 8fe99371-0be4-ed11-b82d-44e517a1f1d9 | Agreement | true | The domain represents a comprehensive rate management system, encompassing various aspects of pricing and agreements with customers and suppliers. The central entity is the Rate, which represents a set of estimated prices for goods and services. Rates can be classified as Sales Rates, issued by the organization, or Purchase Rates, received from suppliers. Rate Lines are individual line items within a Rate, capturing details such as price, unit of measurement, charge type, and validity periods. Rate Lines can be composite, aggregating multiple lines into a single line item. Rates are closely linked to Agreements (contracts) with customers and suppliers, specifying pricing, terms, and conditions. Agreements can include specific Agreement Lines or Clauses. Charges represent monetary amounts and financial details associated with items or services, inherited by Rate Lines. Charges can have various attributes like rate basis, quantities, currency, freight terms, and charge types. The system also incorporates Constraints, which represent limitations or restrictions that may apply to the business, such as commodity restrictions, weight limits, or fuel type mandates. Constraints can be specified through Constraint Items. Selected Products represent transactional instances of master data Products, potentially with configuration choices (Selected Product Configurations). The rate management system integrates with reference data entities like Currencies and enumerations for classifying rates (Rate Commercial Type, Rate Price Type, Rate Status, and Rate Type). Overall, the diagram outlines a comprehensive framework for managing pricing, agreements, charges, and constraints, enabling effective rate management across various business scenarios. | true | true | true | Transactional | João Santos |
| Insurance Agreement | 99ef67d8-e0be-ed11-a1ac-ffabf0d7d350 | Agreement | true | An insurance agreement, or policy, is a document that outlines the terms and conditions of an insurance contract between an insurer (the insurance company) and an insured (the policyholder). The policy sets out what risks are covered by the insurance, how much the policyholder will pay for the insurance coverage, and what benefits the policyholder will receive in the event of a covered loss or claim. | true | true | true | Transactional | João Santos |
| Standard Clause | cb7c838a-4790-ed11-b81b-44e517a1f1d9 | Agreement | true | A standardized version of an Agreement Clause, typically stored in a library, to be re-used when making Agreements. | true | true | true | Master | João Santos |
| Demurrage and Detention Agreement | d0f6e8de-d7f0-ee11-b886-44e517a1f1d9 | Agreement | true | Defines the specific Detention and Demurrage contract with a specific Party relative to prices, terms and conditions. Example: The terms between a Third Party and an Enterprise as it relates to the pricing of products and services. | true | true | true | Transactional | João Santos |
| Negotiation | da302030-fe13-ee11-b833-44e517a1f1d9 | Agreement | true | This domain represents the relationships and key elements involved in various business processes related to commercial negotiations. The central entity is the "Negotiation," which orchestrates interactions between internal or external parties aimed at establishing one or more agreements. The "Negotiation" can be associated with one or more "Opportunities," which represent potential sales or pending deals. Each negotiation involves multiple "Negotiation Rounds," each producing draft agreements for approval. The rounds are connected through a sequence, and each round has a deadline for completion. Within a negotiation round, there are "Negotiation Instruments" representing the components to be negotiated, such as products, terms and conditions, prices, and allocations. Each instrument has a specific type and status, reflecting its current stage in the negotiation process. The negotiation can also be constrained by certain "Constraints," which may represent restrictions or requirements related to various aspects of the business, such as weight restrictions, fuel types, or commodity restrictions. "Agreements" can be established as a result of the negotiation process, specifying legally enforceable terms and conditions between the parties involved. These agreements can contain details like pricing, products, quantities, and clauses. Additionally, the diagram includes entities for managing references, associations with parties involved in the transactions, and enumerations for tracking the status of negotiations and negotiation rounds. Overall, this diagram provides a comprehensive view of the key data entities and relationships involved in the negotiation and agreement processes within the organization. | true | true | true | Transactional | João Santos |
| Asset | ebd72df6-c473-ea11-ada5-40b034e2c22b | true | true | ||||||
| Crane | 0a560381-b4fc-e911-80eb-9cd21e38f3a4 | Asset | true | A crane is a type of machine used for lifting, generally equipped with a hoist (device) or winder wire ropes or chains and sheaves, that can be used both to lift and lower materials and to move them horizontally. | true | false | true | Master | Steven Bosman |
| Asset | 4c560381-b4fc-e911-80eb-9cd21e38f3a4 | Asset | true | Something - either tangible (e.g. a Vessel, a Container, or a Crane) or intangible (e.g. Software) - with a value to the Enterprise and which is owned or controlled by the Enterprise. | true | true | true | Master | Steven Bosman |
| Sensor Observation | 4e520381-b4fc-e911-80eb-9cd21e38f3a4 | Asset | true | Measurement of the condition, circumstance and performance of an asset (equipment, vessel, truck etc.). Readings can be captured through sensors built into or mounted on an asset or through other ways of manual or semi manual capture. | true | true | true | Transactional | Steven Bosman |
| Facility | 4f550381-b4fc-e911-80eb-9cd21e38f3a4 | Asset | true | Contains data about * Operational facilities such as terminals, berths, warehouses, container yards, offices, rail ramps and other transfer facilities. * Commercial Facilities - which are limited to Maersk or Maersk Affiliated Facilities,such as Sales or Administration Offices It includes the low-level services which are offered at those facilities as well as the facility availablitiy/opening times. Includes the concept of "Port Characteristics", for example what cranes and other facilities are available at a given Terminal. Any given Facility may (and usually will) identify one specific Site - however, if there is a hierarchy (for example, a Terminal with multiple subsidiary facilities contained within its boundary) then only the top-level instance (typically a Marine Container Terminal) must be related to a specified Site. | true | true | true | Master | Steven Bosman |
| Asset Profile | 639f3e63-42c0-11f0-14c8-96109e803296 | Asset | true | true | true | true | Master | Steven Bosman | |
| Terminal | 7e0ad00e-ef98-11ef-3a77-922eb47883a8 | Asset | true | true | true | true | Master | Steven Bosman | |
| Asset Handling | 71b5ec7c-b4cb-ea11-adbc-40b034e2c22b | true | true | ||||||
| Transport Asset Requirement | 2024d2d2-7af2-ea11-a3b7-a0510b9e9705 | Asset Handling | true | Defines what are the required transport assets (i.e. vehicles and/or equipment, such as containers) for a given Service Plan, Service Plan Leg, Transport Order, or Carrier Booking. The requirements can include the size and the type of vehicle/ equipment, as well as quantity of assets, and requirements for range of temperature on temperature controlled assets. | true | true | true | Transactional | João Santos |
| Environment Control | 453c8de9-233e-ec11-a3dd-a0510b9e9705 | Asset Handling | true | A set of features and information relating to control of environment settings, such as temperature, ventilation, humidity or atmosphere. Typically used for the proper conservation of goods and commodities which are otherwise perishable or degradable, if not maintained under the specified environment conditions. They can be applicable to either transport assets (containers, ULD's, trucks, aircrafts, etc.) or storage assets (warehouses, etc.). | true | true | true | Reference | João Santos |
| Container Interior Fitting | 58fd5e28-908b-eb11-ade5-40b034e2c22b | Asset Handling | true | Describes how a container can be internaly fitted for e.g. garment on hangers (GOH), lining for tobacco transportation or angled ramps for transpotation of cars inside containers. | true | true | true | Transactional | João Santos |
| Slot Displacement | d9fb8cde-9b4b-ec11-a3e3-a0510b9e9705 | Asset Handling | true | Any requirements regarding slot displacement, i.e. when cargoes and/or equipments exceed the space within an equipment and/or vehicle. | true | true | true | Transactional | João Santos |
| Stowage | dd5a8275-57f9-ed11-b82e-44e517a1f1d9 | Asset Handling | true | Represents the act of stowing objects within/ inside another bigger and containing object. In the context of transport and logistics, this is typically stowing cargo within a container, equipment or vehicle, or stowing containers and equipments within a vehicle. Stowage can have multiple different requirements, according to the specific needs of a shipment, which are specified via this class. Stowage can be both planned or actual. | true | true | true | Transactional | João Santos |
| Fumigation | e1b2bfed-cf51-ec11-a3e3-a0510b9e9705 | Asset Handling | true | Fumigation is a method of pest control, or the removal of harmful micro-organisms, by completely filling an area with gaseous pesticides, or fumigants, to suffocate or poison the pests within. It is used to control pests in buildings, soil, produce, and most importantly during processing of goods to be imported or exported, to prevent transfer of exotic organisms. This method also affects the structure itself, affecting pests that inhabit the physical structure, such as woodborers and drywood termites. Fumigation can be applied to Cargo Packages, Vehicles, Containers and other Equipments, Warehouses, etc. | true | true | true | Transactional | João Santos |
| Business Common | 8038373b-e43b-ec11-a3dd-a0510b9e9705 | true | true | ||||||
| Case Management | 0a4e0381-b4fc-e911-80eb-9cd21e38f3a4 | Business Common | true | Handling issues / interactions with customers. An Issue can be defined as: * Claim - Is dealing with container loss or damaged goods - covered by insurance * Commercial Consideration - like a claim but not covered by insurance Not our direct responsibility to cover, but sometimes to keep the customer happy we will. (example: A container was being delivered to a facility to load, it was delayed, so the facility had to pay overtime for all their workers in order to get the container loaded in time. * Dispute - is used for dealing with invoice issues * Correction - Used for documentation errors * Unhappy with Service | true | false | true | Transactional | Steven Bosman |
| Business Exception Handling | 0cb60c3a-5c29-eb11-adcf-40b034e2c22b | Business Common | true | The business exception handling data model is constructed to represent, basically, any kind of business exceptions that can occur during business processes to "main" business objects. An example are business exception that can occur upon receiving cargo in a warehouse for a shipper booking. The cargo packages may be damaged and an exception has to be logged against the shipper booking informing about this damage that has been observed. A business exception is logged in the Exception Log which is having a category (e.g. "Reasonfor Late Receival), exception (e.g. "Quality Inspection Failed") and optionally a reason and a status as well. | true | true | true | Transactional | Steven Bosman |
| Constraint | 593a3a81-b4fc-e911-80eb-9cd21e38f3a4 | Business Common | true | Generic constraint subject area for holding all kinds of constraint that can apply to the business. This could be commodity restrictions in countries, vessel flag restrictions for terminals, weight restrictions at facilities etc. The model is dynamic so that it works for a broad range of use cases Further specifc examples include : Sanctions : Financial or commercial limitations applied against countries, organizations or individuals and certain goods and services. Both U.S. and European sanctions apply to Maersk. Export controls : Limitations on the export of specific items to certain countries (typically military items, items that can be used both for military and civil purposes and certain technologies) | true | true | true | Master | Steven Bosman |
| Survey | 75201b81-b3ac-11ef-61a3-865a2ac79532 | Business Common | true | Subject Area which models a survey. This is most commonly used to perform standardised examinations of vessels to determine safety and seaworthiness. However, the generic nature of this data model means that it could also be used for other types of survey, such as employee engagement surveys. | true | true | true | Transactional | Steven Bosman |
| Activity Plan Template | 83353a81-b4fc-e911-80eb-9cd21e38f3a4 | Business Common | true | A template for an Activity Plan. Can provide detail regarding how the requirements of an Operating Procedure are to be implemented. A standard reason that can be applied when e.g. raising an issue during one of the Maersk process activity (these could e.g. be delay reasons, Activity, handover reason etc.). Example of a reason could be 'Late Advice on discrepancies or 'On carrier details', 'Late Receipt of Terminal Data', 'Late for train', 'Cannot find route', 'Rail Issue' etc. These reasons are for example used by customers, truckers or internal staff to select from when logging actual issues. In other words reasons for things happening during the processes that Maersk conducts. The actual issues logged with a reason are kept in transactional solutions and not kept within the master data. The reasons are also used for other purposes, e.g. that an internal user selects a reason if he has to do 'Consult Customer' or 'Handover to country office' activity during executing activities of the process 'Process Shipment'. | true | true | true | Master | João Santos |
| Comment | 9c1b0a01-8e2b-ee11-b831-c403a888648f | Business Common | true | Any specific comments relevant to any party, that one may wish to indicate. The comments may originate from Maersk, or from a 3rd party (typically but not exclusively the customer). It's possible to have comments within comments. | true | false | false | Transactional | João Santos |
| Quality Control | a84291ae-6426-ec11-8359-062c85e3ec45 | Business Common | true | The Quality Control domain model defines a structured process for ensuring product or service quality. A Quality Control Profile specifies requirements such as whether audits, inspections, or best-before checks are needed, along with sampling rates. Each quality control activity is linked to a specific Quality Control Type, which describes the nature of the control, such as an inspection or an audit. The Quality Control entity tracks the execution of these activities, recording key timestamps for when the process starts, passes, fails, or is canceled, as well as any associated remarks. The status of a quality control activity is captured using the Quality Control Status enumeration, which includes states such as Awaiting, Started, Passed, Failed, and Cancelled. Lastly, the Party entity identifies those who perform or request the quality control, ensuring clarity and accountability throughout the process. The relationships between these components create a cohesive framework for managing quality control activities. | true | true | true | Transactional | Steven Bosman |
| Activity Plan | bb353a81-b4fc-e911-80eb-9cd21e38f3a4 | Business Common | true | Data about the execution of Work Processes. This model presents the data entities in the Activity Plan subject area, and their relationships with other entities. | true | true | true | Transactional | João Santos |
| Instruction | cc61b171-e855-ed11-b812-44e517a1f1d9 | Business Common | true | Any specific instructions relevant to any party, that one may wish to indicate. The instructions may originate from Maersk, or from a 3rd party (typically but not exclusively the customer). These typically refer to how cargo should be handled or transported, or notes and instructions for transport providers, truck drivers, etc. Examples: * Cargo Handling Instructions * Dangerous Cargo Handling Instructions * Inland and Haulage Instructions * Distribution Centre Handling Instructions * Instructions for Truck Drivers * Advanced Manifest Filing Instructions * etc. It' s possible to have instructions within instructions. | true | true | false | Transactional | João Santos |
| Approval | d59d66bf-ec84-ec11-a3e9-a0510b9e9705 | Business Common | true | Information about the approval conditions and related statuses, that is associated with another data or business element. This can be, for instance, an approval status for a shipment, or part of a shipment (for some aspect of its progress), a booking, a cargo, a move, etc. | true | true | true | Transactional | João Santos |
| Deadline | e6353a81-b4fc-e911-80eb-9cd21e38f3a4 | Business Common | true | Non-dated standard deadline, cut-off, or service level agreement that must be met for any service or product. | true | true | true | Master | Steven Bosman |
| Capacity Management | fbdc7dc0-c573-ea11-ada5-40b034e2c22b | true | true | ||||||
| Uptake Plan | 08500381-b4fc-e911-80eb-9cd21e38f3a4 | Capacity Management | true | Information about the management of Bookings, including * Policy regarding which categories of Booking should be accepted * Status information regarding execution of the policy | true | false | true | Transactional | João Santos |
| Shipment Consumption | 254728b1-07e0-eb11-a3d4-a0510b9e9705 | Capacity Management | true | A record of the equipment units (typically containers) that have been used (i.e. "consumed") for a given Shipment. Typically this record of "consumed equipment units" is done against an existing commitment agreement, whereby the customer has agreed upfront that he will use a given number of equipment units. The Shipment Consumption will be the record of the actual consumer units versus the ones committed to. The Shipment Consumption will also hold details on yield acceptance, i.e. if the yield obtained with the related Shipment is within acceptable values by Maersk. Yield validation is directly linked to the business area of Uptake Management. | true | false | true | Transactional | João Santos |
| Empty Repositioning Order | 6ba8d9e7-d173-ea11-ada5-40b034e2c22b | Capacity Management | true | A requirement for operational activity to move Empty Equipment from one pool to another pool. Also know as an Order To Transfer (OTT). | true | true | true | Transactional | João Santos |
| Transport Allocation | ae3b87cd-272e-ef11-a1c5-f3ef5fbf2395 | Capacity Management | true | The transport allocation domain deals with how quantities of containers, commodities or other measures, should be allocated between carriers of cargo. Transport allocations can be created for specific customers, if the customer for example specfies that a certain percentage of their cargo shipped with Maersk SCM should go with MSC and andother percentage go with CMA. | true | true | true | Master | João Santos |
| Capacity | d07baefb-11a5-ec11-8382-060656193b39 | Capacity Management | true | true | true | true | Master | João Santos | |
| Cargo | d19b88cf-c573-ea11-ada5-40b034e2c22b | true | true | ||||||
| Dangerous Cargo | 198e4329-a753-ea11-ad9d-40b034e2c22b | Cargo | true | Specifies all the Dangerous Cargo Information (legally mandotiry or not) that must go together with either a Customer Product or a Transport Leg. This subject area represents the "transactional data side" of the dangerous goods information. The "master data side" of the dangerous goods information can be found on "Hazardous Classification" subject area. Relationships between classes of these 2 subject areas will specify how data will relate to each other. | true | true | true | Transactional | João Santos |
| Cargo Type | 2b393a81-b4fc-e911-80eb-9cd21e38f3a4 | Cargo | true | Classification of the long-standing dataset used by Maersk for classifying cargo into specific high level types. | true | true | true | Reference | João Santos |
| Commodity Classification | 6e393a81-b4fc-e911-80eb-9cd21e38f3a4 | Cargo | true | A set of permitted classifications of goods e.g. toys, electronics or welding machinery, at a group or atomic level, by which cargo can be categorised. Commodity Classification - apart from the MHS commodity coding system specifically created in-house by Maersk, this is a set of externally-derived standard systems (Commodity Coding Systems) for grouping cargo into much finer-grained categories, along with a formal hierarchical structure. Dual-Use commodities, those which are monitored for their potential re-use by unfriendly regimes or groups. Prominent examples of Commodity Coding Systems which supply the datasets used for classifying commodities are: Maersk's own derived system (MHS) - HS (Harmonized Commodity Description and Coding System) maintained by the World Customs Organisation (WCO) - TARIC (the Integrated Tariff of the European Communities) - UNSPSC (United Nations Standard Products and Service Codes) to classify both products and services for use in eCommerce - HTSUS (The Harmonized Tariff Schedule of the United States) - UK Trade Tariff - DOT Numbers (North America extended UNIDs) Cargo on a shipment is usually described using the six digit HS 'atomic' level code (or four digit 'group' code). For commodity reporting the two digit 'group' code is used. To give it its full name, the 'Harmonized Commodity Description and Coding System (HS)' of tariff nomenclature is an internationally standardized system of names and numbers for classifying traded products developed and maintained by the World Customs Organization (WCO). Cross-linking (sometimes called "mapping") between classifications is made possible by the correlation class - through this two classifications which are effectively the same, but in two different Coding Systems, can be recorded, so that for example MHS code 123 could be mapped as the equivalent of HS code 65.43.21. Linkages for other purposes than simple "equivalence" can be captured in this data structure, for example the fact that one code "replaces" another, or "links to a potential Dual Purpose" (as per RQ-6116), or (in the case of Dangerous Goods) linking a pair of goods which can (or, more likely, cannot) be transported together. | true | true | true | Master | João Santos |
| Commodity | 768acc65-fa16-ea11-ad8b-40b034e2c22b | Cargo | true | Details about the product that has been ordered by a Maersk customer to be produced or purchased. The product is detailed in terms of styles, SKU and dimensions etc. and may be accompanied by UPC information as well. | true | true | true | Master | João Santos |
| Cargo Package | 89aa08c7-823e-ea11-b544-b46bfcaea91a | Cargo | true | Data relating to have cargo should be packaged by the seller or producer. With these structures It is possible to specify how products in orders must be packaged from outer packaging like pallets, over outer cartons to inner cartons. Package types can be specified for each level in the packaging specification in conformance with both UN and IMDG packaging types. Any "prepack" information submitted with the order or supplied at packing time can likewise be handled so that UPC numbers and the quantities of packages with the UPC number can be supported. | true | true | true | Transactional | João Santos |
| Hazardous Classification | b3646b49-e569-ea11-a3a9-a0510b9e9705 | Cargo | true | Specifies all required classifications, and related information, that are used when a commodity is considered dangerous/ hazardous. This subject area represents the Master Data side of dangerous goods details, by specifying all data and classifications that relate to a specific commodity and/or transport. This subject area that represents the "transactional data side" of the dangerous goods information will be subject area "Dangerous Cargo". Relationships between classes of these 2 subject areas will specify how data will relate to each other. | true | true | true | Master | João Santos |
| Commodity Classification Association | ccc4b6b5-93ae-ee11-a1bf-d7e14702d112 | Cargo | true | Represents transactional data and is used to support both master and transactional data associations to locations. A data object can specify a number of commodities related to a transaction in the logistics process. It can also be used because of: * Missing Master Data: This class has its own "Commodity Code" and "Commodity Name" attributes to allow the possibility of recording them directly as transactional data, for the cases where the required Commodity Classification master data doesn't exist yet. * Country Specific Data: There can be more than 1 commodity classification, to cover for cases where different countries of the transport journey require different codes. * Customer Specific Data: Recording customer values, that might be different from the actual and/or final commodity value, is also possible via "Commodity Code" and "Commodity Name" attributes. Note: A commodity code can be related to the commodity code master data set or exist here with code and description if it cannot be related to the master data set. The same goes for country codes and the manufacturer of the cargo. | true | false | false | Transactional | João Santos |
| Corporate | 939e7313-8eeb-ee11-8179-c403a888648f | true | true | ||||||
| Regulation | 10f5e673-bfd7-11f0-64d1-e682385842d0 | Corporate | true | ||||||
| Procurement | 432f21d6-08ed-ee11-8179-c403a888648f | Corporate | true | The procurement process at our organization involves categorizing goods and services into procurement categories, which streamlines the process and enables better management and control. Procurement projects are specific initiatives undertaken to acquire these goods and services from external sources. They involve identifying needs, defining specifications, evaluating finances, sourcing potential suppliers, conducting competitive bidding or negotiations, selecting vendors, managing contracts, and overseeing delivery. Procurement categories can be associated with products, product groups, transport activities, defined areas (such as countries or regions), and brands. Products are standardized services that customers can purchase as a whole, and they are organized into product groups for commercial or organizational purposes. Transport activities refer to whether the transport is import, export, domestic, cabotage, or cross-trade from the perspective of our organization. Procurement projects can be further classified as investment projects, which involve initiatives aimed at generating returns on invested capital, such as acquiring assets or launching new business ventures. Defined areas are geographically delimited areas with positional, commercial, jurisdictional, administrative, or economic significance, such as continents, countries, cities, or sites. These areas can be associated with procurement categories and play a role in procurement activities. Brands represent the names, terms, designs, or symbols under which our organization's products and services are sold. The domain provides an overview of the relationships between these various elements, illustrating the interconnected nature of the procurement process and the various factors that influence it. | true | true | true | Transactional | João Santos |
| Investment Project | 7a910f1b-8eeb-ee11-8179-c403a888648f | Corporate | true | This domain illustrates a data model for investment projects, procurement activities, and related entities within the organization. It depicts the relationships between various components involved in managing and tracking investment projects, their associated costs, vendor information, and other relevant details. The central entity in this model is the Investment Project, which encompasses initiatives and ventures undertaken to generate returns on invested capital. These projects can involve investing in assets, infrastructure, technology systems, or new business ventures. Each Investment Project is associated with a Project Type that categorizes the project based on its nature, scope, and requirements. Projects are further characterized by their Status, which reflects their current stage, such as "New", "Analysis", "Started", "Confirmed", or "Finalized". Projects can also have a Parent Project, allowing for a hierarchical structure and relationships between projects. The model incorporates Cost Performance Indices, which represent the percentage amounts associated with specific time periods, enabling the tracking and analysis of project costs over time. Additionally, Project Period Spend entities capture detailed information about project expenditures, including Annualised Total Effort, Current Total Efforts, Next Carry Over, Previous Carry Over, and various cost impact and savings metrics. The diagram also includes Project Vendors, representing the relationships between vendors and projects. Vendors can be identified as incumbents, and their market conditions can be specified. Projects are associated with Procurement Methods, such as auctions, RFX (Request for Proposal/Quotation), or direct procurement. Furthermore, the model encompasses Agreements, which specify legally enforceable rights and obligations between parties regarding the transfer of goods, services, money, or other terms and conditions. These agreements can be linked to projects and vendors. Overall, this data model facilitates the management and tracking of investment projects, their associated costs, vendor relationships, procurement processes, and agreements within the organization. | true | true | true | Transactional | João Santos |
| Customs | 39e01fa7-ed37-ec11-a3dd-a0510b9e9705 | true | true | ||||||
| Transit Document | 21da33f1-a990-ec11-a3ee-a0510b9e9705 | Customs | true | A document that is issued for and must officially accompany cargo that hasn't been customs cleared yet, but that was allowed to enter the country, in a so-called "bonded transport" or "bonded transit" from the border in to an inland location, typically a "bonded warehouse", where cargo will then be subsequently customs cleared. It should be noted that Transit Documents can also be issued for regions of countries where a customs union exists, such as the European Union. | true | false | false | Transactional | Steven Bosman |
| Customs Declaration | 2d61889c-bd3c-ec11-a3dd-a0510b9e9705 | Customs | true | Customs Clearance, on behalf of 1 particular customer, for 1 particular shipment, to 1 particular Customs Authority, for the purpose of clearing the cargo, and authorize either its entry, exit or move within a specific customs zone (typically a country or region). It should not be confused with Manifest, as this customs submission refers to the individual cargo of 1 specific customer, submitted by said customer or on its behalf, and not to a entire vessel, aircraft, etc. submitted by the related carrier. | true | true | true | Transactional | Steven Bosman |
| Manifest | 5f6dedbc-ed37-ec11-a3dd-a0510b9e9705 | Customs | true | A Manifest is a consolidated list of all cargo on board a vehicle (vessel, aircraft, etc.), plus vehicle attributes, and route details. It can list either cargo or passengers, including crew members. Typically, a cargo manifest lists all Transport Documents and the associated total number of goods shown on each Transport Document. Totals for the whole Manifest can then be derived and presented as well. Customs authorities at the respective ports, airports, etc. will need to review and confirm the cargo manifest against the actual cargo being loaded/unloaded at these locations. Without this confirmation, cargo cannot be loaded/unloaded. | true | true | true | Transactional | Steven Bosman |
| Customs Service Order | 69e43984-56f1-ec11-a404-a0510b9e9705 | Customs | true | A type of Service Order that relates to Customs Clearance services only. It relates to 1 particular shipment of 1 particular customer, although same shipment of same customer may have more than 1 Customs Service Order (for origin, destination, in transit, etc.). The Customs Service Order aggregates Commercial Invoices of related shipment for the purpose of customs clearance requests and submissions. It also aggregates any related submitted Customs Entries. | true | true | true | Transactional | Steven Bosman |
| Customs Filing Profile | 7de96f7f-3d64-eb11-addc-40b034e2c22b | Customs | true | A profile describing for a specific customer how customs filing is done, depending on export- and import country as well as a specific export- and and and import location, if necessary. With this profile it is possible to specify any number of compbinations for import/export filing scenarios and handle these based on what the transportation dictates in terms of locations. The profile can also specify a transport mode such that filing can be set up for ocean, air, rail, truck etc. | true | true | true | Reference | Steven Bosman |
| Commercial Invoice | e942aeb2-fa16-ea11-ad8b-40b034e2c22b | Customs | true | This document produced by the shipper/seller of goods which contains an accurate description of the merchandise, goods country of origin, and all items are itemized with actual selling price and currency. Details on the Packing List, Commercial Invoice and Carrier BL needs to match as they are submitted to Customs Officials for export and import customs clearance. | true | true | true | Transactional | Steven Bosman |
| Delivery Network | 967f3511-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Rail Schedule | 20d42f61-4288-ea11-adaa-40b034e2c22b | Delivery Network | true | Data about rail schedules (aka. timetables) and how these relate to rail carriers and geographic locations. Inspiration drawn from: https://www.raildeliverygroup.com/files/Publications/services/rsp/RSPS5046_timetable_information_data_feed_interface_specification.pdf | true | true | true | Transactional | João Santos |
| Vessel Schedule | 2e510381-b4fc-e911-80eb-9cd21e38f3a4 | Delivery Network | true | A commitment for a specific Vessel to call at specific Sites/Terminals on specific dates, along with progress information including actual call date and time. A Vessel Schedule is for a specific Vessel, containing one or more voyages serving a Rotation, and the Vessel Port Calls belonging to those Vessel Schedules. Exclusion: Vessel Schedules are not created for Barge and Rail Rotations. Note: Vessel schedule structure deviates slightly from the Flight Schedule structure because a vessel mostly does rotations between multiple ports and not "just" port to port like an aircraft. Therefore the structure of a vessel schedule is better suited to be port call-centric than vessel leg-centric. | true | true | true | Transactional | João Santos |
| Vessel Schedule Planning | 53510381-b4fc-e911-80eb-9cd21e38f3a4 | Delivery Network | true | Main concept in vessel schedule planning is the rotation, which defines the framework for how vessels are to be operated, to provide one or more services, in terms of: - Transport Mode - Marine container terminals (MCT) that can be called on - Sequence of MCTs - Time intervals between the MCTs - MCT-to-MCT connections Rotations are sometimes known as 'Proformas'. A rotation can, and typically does, have candidate vessels assigned to it. Multi-Rotation services do not occur. Occasionally 'temporary' rotations are used to transfer a vessel from one service to another. Of the many rotations operated by Maersk (excluding "feeder" rotations), fewer than ten fall into the special categories called "Butterfly" or "Pendulum". With these rotations, different sections of the rotation may be operated by different services. A Pendulum is a fixed rotation supporting a single service and in which cargo carrying capacity is managed by different String Business Units (the "Boomerang" rotation is a specific example of a Pendulum variant). Butterflies are more complex, coming in several variants (including feeder rotations) but most involve a rotation supporting two services, and optionally with cargo carrying capacity on different sections of the rotation being managed by different String Business Units (typically no more than two). There is a common join-point for both 'wings' of a Butterfly. The same applies to a Pendulum. 'Alternating' port calls can be handled by a Butterfly with its 'wings' folded. These occur when rotations cover a number of ports which are too small to justify weekly calls, but can justify fortnightly calls. In this case two continuously alternating, overlapping "circuits" are created within that rotation, in which the small ports are omitted on one "circuit" but included within the other. Some parts of Maersk choose to refer to this arrangement as a "Butterfly", even though technically it's only one service operating over one rotation - it's the rotation which covers the same "ground" twice in the form of two similar (but not identical) alternating "traversals" or "circuits". Also closely connected to rotations are "Double Call Ports". In a complex rotation (taking as example a rotation which on its headhaul visits several ports along the coast of China, goes through the Suez Canal, and then visits several ports in western Europe, then back to China): Either a given vessel completely "retraces its steps" on the backhaul (ie every headhaul port-visit is matched, in reverse order, by a backhaul port-visit) or the backhaul voyage is NOT a mirror-image of the headhaul voyage, it consists of only the main "intercontinental" leg (i.e. the coastal hops in China and in Europe are omitted in the backhaul voyage). So, from the perspective of one of those coastal "intermediate" ports, a double port call occurs when the first type (above) of rotation takes place (where the vessel retraces its steps on the backhaul). This means that a given vessel on such a rotation will unload its relevant cargo on the "import" legs, then a few days later on its return that vessel will make a second port-call to load cargo on the "export" legs. | true | true | true | Transactional | João Santos |
| Routing | 7022d7a3-8190-ed11-a1a6-a5e58e79069f | Delivery Network | true | The Routing subject area comprises data about the various routes that are offered to Maersk customers as options to select from when making a booking for transporting cargo. | true | true | true | Master | João Santos |
| Trade Lane | 7f510381-b4fc-e911-80eb-9cd21e38f3a4 | Delivery Network | true | A Route are groupings of the detailed Transport Product defining a Trade Scope offered by an Operator. A Route defines where the Cargo goes. System Note: The Route application provides a system for the storing and maintenance of Route Codes and the combinations (journeys) that make up each route for the carriers i.e. Maersk Line or Sealand. | true | true | true | Master | João Santos |
| Service | 908b0d75-e938-ef11-a1c5-f3ef5fbf2395 | Delivery Network | true | Vessel sharing supports the concepts of setting up vessel sharing agreement partnerships. These partnership master data is used for example in the Service where it is necessary to know who, from which partnership, participates in the service. | true | true | true | Master | João Santos |
| Network | a0317d48-056b-ed11-a1a4-dac57d1c6c19 | Delivery Network | true | Master data about point to point, area to area, pricing and priorities used for constructing a detailed proposition for transportation of cargo to a customer. | true | true | true | Master | João Santos |
| Transport | a3da5405-c91b-ef11-a1c4-a610861322cc | Delivery Network | true | A leg connection is a concept used for all transport related legs, e.g. Transport Leg, Service Plan Leg and so forth, and makes it possible to list the previous leg and all subseqeunt legs. Basically it allows the leg to lay out a graph representation of what came before and what happens next in term of legs. | true | false | false | Transactional | João Santos |
| Carriage | db156f92-7f3e-ed11-a421-a0510b9e9705 | Delivery Network | true | Carriage holds relevant details on the actual transport, i.e. schedules, vessel or other vehicle, voyage number, flight number, locations, etc., depending on the mode used (ocean, air, rail, road or inland water). | true | true | true | Transactional | João Santos |
| Flight Schedule | fa7ece4e-906d-ea11-bd82-34f39a7a061f | Delivery Network | true | Data about flight schedules and how these relate to air carriers and geographic locations. Note: Flight schedule structure deviates slightly from the Vessel Schedule structure because a flight rarely does a rotation between multiple airports. Therefore the structure of a flight schedule is better suited to be flight leg-centric than port call-centric. | true | true | true | Transactional | João Santos |
| Document | bbf7f871-7e74-ea11-ada5-40b034e2c22b | true | true | ||||||
| Document | 16370e07-ed11-ea11-80ed-9cd21e38f3a4 | Document | true | A general representation of a document including relevant relationships that are comment to document subtypes, e.g. data files of scans or renders, owning office and soft coded values Hard copies: A scanned copy of a signed hard copy business contract can be kept via the Document construct where the document can be rendered as a file. | true | true | true | Transactional | João Santos |
| Letter of Credit | 3fa229da-786d-ea11-ada2-40b034e2c22b | Document | true | The Letter of Credit is a document issued by a bank, per instructions from a buyer (i.e. the Consignee) of goods, authorizing the seller (i.e. the Shipper) to draw a specified sum of money under specified terms usually the receipt by the bank of certain documents within a given time. ATTENTION: not to be confused with the Financial Letter of Credit. For the Finantial one, which is used a payment method, please check subject area "Payment Terms" in "Finance" domain. | true | true | true | Transactional | João Santos |
| Equipment | efb32e61-7f74-ea11-ada5-40b034e2c22b | true | true | ||||||
| Equipment | 03550381-b4fc-e911-80eb-9cd21e38f3a4 | Equipment | true | A specific piece of equipment that is used in the transportation process. The Equipment will in most cases have a unique number like an ISO container number or a ULD IATA code. Examples include: * ISO shipping containers for ocean and intermodal freight * Unit Load Device for air cargo * Ancillary equipment such as Gensets and chassis Note: The identification number, serial number and the like have been moved to subclasses because they differ greatly between e.g. ISO and ULD containers. | true | true | true | Master | Steven Bosman |
| Equipment Profile | 11530381-b4fc-e911-80eb-9cd21e38f3a4 | Equipment | true | Data and structures about equipment like dry containers, reefers, chassis etc. These characteristics describes the equipment in terms of size, capabilities (air flow, temperature etc.). Includes data such as: * Size/Type * ISO Code * Tare weight * Maximum allowed weight | true | true | true | Reference | Steven Bosman |
| Equipment Size Type | 3fb9da3d-62f6-eb11-833a-067341d655fb | Equipment | true | Maersk internal size and type codes for equipment, and the related ISO information. | true | true | true | Master | Steven Bosman |
| Event | 19ce3fe5-8236-ea11-ad93-40b034e2c22b | true | true | ||||||
| Event | 21435ef5-9e74-ea11-ada5-40b034e2c22b | Event | true | An event for something that is planned or estimated to occur or something that has already occured in the transport/suppl chain process. An event can be associated to 'Production' or 'Vessel' or 'Equipment' or 'Scan' The Event is associated with a Event Trigger which explains what kind of event the date is for. Example "Receival at Origin", "Arrival at Destination" or "Stuffed". The Event is also associated with an Event Timing which designates whether the event is planned, actual, estimated or something else. Descriptive examples: - Actual container loaded on board a vessel at a specific time - Vessel into Fleet on a specific time - An equipment inspection is planned to happen or actually occurred Note: The transport related events that are planned, predicted, actual etc. should not be confused with the technical concept of an 'event' in event driven architecture. The technical event in event driven architecture is something that must have happened; a planned transport related event has not occurred, however the planning has occured so it does not conflict with event driven architecture principle but care must be taken when communicating about these different concepts not to confuse audience. | true | true | true | Transactional | Steven Bosman |
| Shipment Journey | 23fcaf7d-62ae-ed11-a1a9-88da74af6119 | Event | true | This domain depicts the process of tracking a shipment's journey from origin to destination, including various stages, modes of transport, and associated parties and locations. At the core is the Shipment Journey entity, which represents the overall tracking or visibility of a unit of cargo being transported. The Shipment Journey is broken down into individual Shipment Journey Legs, each representing a distinct step or mode of transportation, such as trucking or air carriage. Each Shipment Journey Leg has associated events that capture important milestones or occurrences, such as estimated arrival times, actual loading or unloading times, and other significant dates. These events are categorized by their triggers (e.g., "Receival at Origin," "Departure from Origin") and timings (e.g., planned, actual, estimated). The Shipment Journey and its legs are linked to various entities that provide additional context and details. Party Associations capture information about the parties involved in the shipment, such as the consignee, shipper, carrier, or vendor. Location Associations represent the relevant locations involved, like the port of loading, port of discharge, or final destination. References, such as tracking numbers, order numbers, or identifiers, are associated with the Shipment Journey Legs to facilitate searching and tracking. The Transport Mode specifies the mode of transport (e.g., maritime, rail, road, air) employed for each leg. The diagram also includes relationships between Shipment Journey Legs, allowing for the representation of complex multi-modal shipments or split/combined legs. The Unit of Tracking, which could be a container, package, or equipment, is associated with the overall Shipment Journey, enabling the tracking of specific units throughout the journey. Additionally, the diagram incorporates the concept of Cargo Service Type, which defines the modality or scope of service being provided, such as Full Container Load (FCL), Less than Container Load (LCL), or Conventional Cargo (CC). Overall, this diagram provides a comprehensive view of the entities and relationships involved in tracking and managing the journey of cargo shipments, facilitating visibility, coordination, and efficient logistics operations. | true | true | true | Transactional | Steven Bosman |
| Container Itinerary | 8857534a-469e-eb11-ade6-40b034e2c22b | Event | true | Data structures for container event and container itinerary. The container event is a specialisation of the equipment event. Container itinerary is a collection of planned and/or actual container events. | true | true | true | Transactional | Steven Bosman |
| Vehicle Event | 99c41cb1-636a-ea11-ada1-40b034e2c22b | Event | true | Captures information of Events involving a Vessel. When a Vessel is allocated and available various event takes place during the voyages. Examples: * Port Call * Fueling * Entry into fleet * Removal from fleet * Rebuild start * Rebuild end * Dry dock period start * Dry dock period end | true | true | true | Transactional | Steven Bosman |
| Equipment Event | bc4d0381-b4fc-e911-80eb-9cd21e38f3a4 | Event | true | An event involving an item of Equipment being physically moved or having another action done like sealing or inspection. | true | true | true | Transactional | Steven Bosman |
| Container Event | cf8bbca8-b919-ec11-8351-062656adbf85 | Event | true | Specific information captured against events for containers, for example the container yard stowage slot that a container is stored at or picked from or the event that captures that seals were attached to the container. | true | true | true | Transactional | Steven Bosman |
| Finance | c744d627-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Job Costing | 493a9b02-eef6-ec11-a406-a0510b9e9705 | Finance | true | A Financial Job is an instance of a "Job" withing the accounting process known as "Job Costing". The word "Financial" before "Job" is used here for the purpose of disambiguation with the HR definition of Job. Job costing is accounting which tracks the costs and revenues by "job" and enables standardized reporting of profitability by such job (like an overall profit & loss statement for the firm, but is specific to each job number). So, typically to support job costing, one must allow job numbers to be assigned to individual items of expenses and revenues. A job can be defined to be a specific project done for one customer, or a single unit of product manufactured, or a batch of units of the same type that are produced together, which means one can have a job per any sensible business item/ concept: container, truck, aircraft, equipment, bill of lading, transport document, shipment, cargo, etc. Costs and revenues are recorded in ledger accounts throughout the life of the job and are then summarized in the final trial balance. When all costs and revenues are realized, the job is "closed" and its final P&L statement issued. | true | true | true | Transactional | João Santos |
| Chart of Accounts | 4e3d3a81-b4fc-e911-80eb-9cd21e38f3a4 | Finance | true | Data about General Ledger Accounts that support the Enterprise's Financial Accounting processes. Includes: * General Ledger Accounts (including Sub-Ledger Accounts) * The 'global' Operational Chart Of Accounts * Subsets of the Operational Chart Of Accounts that are used by individual Business Units * Country specific subsets of the Operational Chart Of Accounts (typically used to meet specific legal or statutory requirements that apply in a Country) * Group Accounts that support the production of consolidated financial statements for a group of companies | true | true | true | Master | João Santos |
| Invoice | 4e631e1d-ba7e-ea11-ada7-40b034e2c22b | Finance | true | Billing document is either an invoice or a credit memo. | true | true | true | Transactional | João Santos |
| Payment Terms | 99d4b51a-c54b-ea11-ad9b-40b034e2c22b | Finance | true | Reference data used for indicating payment terms agreed between parties for e.g. shipments, credit terms agreed for when payments must be made, payment for how the payments are/must be conducted. | true | true | true | Reference | João Santos |
| Financial Order | d6be3487-e94d-ec11-ab99-5c879c3c5a54 | Finance | true | The Financial Order is an abstract concept, that refers to both Purchase Order (PO) and Sales Order (SO), generalizing them. In other words, PO and SO are subtypes of Financial Order. This is done for ease of modelling, as the attributes and relationships of both PO and SO are largely (if not all) the same. | true | true | true | Transactional | João Santos |
| Accounting Transaction | dc3c3a81-b4fc-e911-80eb-9cd21e38f3a4 | Finance | true | This model presents the data entities in the Accounting Transaction subject area, and their relationships with other entities. | true | true | true | Transactional | João Santos |
| Tax | e91fe7f2-cc22-ed11-a415-a0510b9e9705 | Finance | true | A tax is a compulsory financial charge or some other type of levy imposed on a taxpayer (an individual or legal entity) by a governmental organization in order to fund government spending and various public expenditures. A failure to pay, along with evasion of or resistance to taxation, is punishable by law. | true | true | true | Master | João Santos |
| Charge | ffbdee93-58cd-ea11-adbd-40b034e2c22b | Finance | true | This domain illustrates the core concepts and relationships related to charges and rates within our organization. It covers various aspects such as charge types, rate bases, units of measurement, and their associations with products, groups, and constraints. At the heart of this diagram lies the Charge entity, which represents a line item with a monetary amount and related financial details. Charges can be associated with various documents, such as invoices, purchase orders, rates, or transport documents. They are classified into different types, such as base charges, surcharges, or add-ons, and may be negotiable or non-negotiable. Charge Types are linked to charge groups, which align with the services provided. They can also be constrained by various factors, such as geography, cargo type, route, or customer-specific requirements. Each Charge Type corresponds to a Material code within the financial chart of accounts. Charges can be associated with Rate Bases, which define the basis for calculating the charge amount. Rate Bases can be based on units, containers, percentages of other charges, or time periods, and are linked to specific Rate Basis Types and Units of Measurement. The diagram also depicts relationships between charges and other entities, such as exchange rates for currency conversion, freight terms for determining who pays the charges, and payment conditions for specifying payment modes, terms, and credit terms. Additionally, the diagram highlights the connections between charges and various transactional documents, such as invoice lines, financial order lines, rate lines, and financial job lines. These documents capture the details of charges in the context of specific transactions or operations. Overall, this diagram provides a comprehensive overview of the key entities and relationships involved in managing charges and rates within our organization, enabling a better understanding of the underlying processes and data structures. | true | true | true | Transactional | João Santos |
| Generics | 89d439ec-7c6e-ee11-a1be-d7e14702d112 | true | true | ||||||
| Validation | 4e492a31-4ab3-ee11-a1c0-97e99c96f3d2 | Generics | true | The domain enables other data objects to relate validation information, in case it is needed to know if there are issues with the data. This could for example be used when a consumer posts data to a Maersk API and data could not be succesfully validated, then the validation data structure can be used to hold this validation information and communicated back to the consumer. | true | false | false | Transactional | Steven Bosman |
| Alternate Term Dictionary | 9d81428d-61f8-ee11-a1c1-a83983aea769 | Generics | true | The alternate term dictionary concept ensures that it is possible to have terms, which do not exist as attributes or relationship role names in the model, to be defined in a dataset. | true | false | false | Master | Steven Bosman |
| Event Notification | ada6f64a-276e-ee11-a1be-d7e14702d112 | Generics | true | The event notification is used to encapsulate business data when such is communicated via events. It contains meta data about the event, causation identifiers, batch information etc. | true | false | false | Transactional | Steven Bosman |
| Generics | d6ca71d5-0c6e-ee11-a1be-d7e14702d112 | Generics | true | Super classes with generic attributes and relationships needed by many other classes. | true | false | false | Transactional | Steven Bosman |
| Feature Toggling | ea3e0b47-fe2a-eb11-add0-40b034e2c22b | Generics | true | Subject area for handling systems feature toggling based on which business entities should have access to what features and functions. | true | true | true | Reference | Steven Bosman |
| Geography | 98177f38-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Geography | d2393a81-b4fc-e911-80eb-9cd21e38f3a4 | Geography | true | Data about geographically related concepts within which Maersk operates. The concepts include locational, business, jurisdictional, administrative, economic or military areas (which all have some element of geography in their definitions). The Geographic Defined Area consists of objects of the following types: * Continent * Country * Sub Division (region, state, etc) * City * Postal code It also includes 'Business Defined Areas' where the business can group certain geographical areas into a Maersk defined area. for example a Financial cluster or Reefer Operations cluster. | true | true | true | Master | Steven Bosman |
| Location Association | e13708a3-67ac-ee11-a1bf-d7e14702d112 | Geography | true | Represents transactional data and is used to support both master and transactional data associations to locations. A data object can specify a number of locations related to a transaction in the logistics process. For example, a Service Plan or Transport Plan will record the locations used in the transport legs or services The "Location Function" will specify what purpose the relationship with the location serves. Many times this will be a specific site but can also be a country if the function is for example "Origin". Examples could include Free on Board Point, Hub Port, Port of Loading/Discharge, Final Destination, Place of Origin/Receipt/Delivery/Transshipment etc. This domain represents transactional data (not Master Data). | true | false | false | Transactional | Steven Bosman |
| Time Zone | ec383a81-b4fc-e911-80eb-9cd21e38f3a4 | Geography | true | Data about uniform times that apply in regions of the Earth (Time zones). Includes offsets (e.g. +2 hrs) from Coordinated Universal Time (UTC). | true | true | true | Reference | Steven Bosman |
| Human Resources | a2c9f479-f9d4-eb11-ab86-5c879c3c5a54 | true | true | ||||||
| Job Position | 127959a3-f9d4-eb11-ab86-5c879c3c5a54 | Human Resources | true | Job Postion covers the Job Profiles, the Workforce Plan and the Job Requisition details. A Job Position can be filled via an Employee or a Contigent Worker. Job positions are filled for brands, and commercial facilities and are part of supervisory or company organisation. | true | true | true | Master | João Santos |
| Benefit and Compensation | 343c7398-f9d4-eb11-ab86-5c879c3c5a54 | Human Resources | true | Covers the Compensations plans, including Salary plans, Allowance Plans and Bonus Plans available to the Enterprise Covers the Benefits that are available - for example Medical Aid that are available to the Enterprise. | true | true | true | Master | João Santos |
| Talent and Performance | 59aec48c-f9d4-eb11-ab86-5c879c3c5a54 | Human Resources | true | Talent and Performance includes: Performance reviews Succession Planning Talent Pools | true | true | true | Transactional | João Santos |
| Attendance | c7e21582-f9d4-eb11-ab86-5c879c3c5a54 | Human Resources | true | The Attendance domain currently records the Absence details for both Employees and Contingent Workers. It maintains the Absence Balances and the indiviudal instances where absence from work occured. | true | true | true | Transactional | João Santos |
| Employee | d5ebdcf3-5b88-ea11-adaa-40b034e2c22b | Human Resources | true | Data about Individuals that that Maersk needs to track information about. | true | true | true | Master | João Santos |
| Maintenance and Repair | 0be87cf6-5ccf-eb11-ab84-5c879c3c5a54 | true | true | ||||||
| Maintenance Cost Recovery | 694b75e8-6af4-eb11-ab89-5c879c3c5a54 | Maintenance and Repair | true | Maintenance Cost Recovery cases are created when additional costs are incurred against containers (by example repairs or cleaning). The cases are then reviewed to identify if a third party (Customer or Service Provider) is liable for the additional incurred costs, and if so costs are sent to Finance to invoice the relevant party. | true | true | true | Transactional | Steven Bosman |
| Maintenance Type | f2169f0e-5dcf-eb11-ab84-5c879c3c5a54 | Maintenance and Repair | true | A Maintenance and Repair Item represents the fixed structures used to manage repairs within an order. | true | true | true | Master | Steven Bosman |
| Maintenance Order | f4169f0e-5dcf-eb11-ab84-5c879c3c5a54 | Maintenance and Repair | true | A Maintenance and Repair Order represents an instruction for to a Maintenance and Repair Shop to complete repairs to an Asset. Currently this model supports Maintenance and repairs to Equipment. | true | true | true | Transactional | Steven Bosman |
| Marketing and Sales | ec0abb41-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Sales Target | 5497a448-2ba6-ed11-8c06-5c879c3c5a54 | Marketing and Sales | true | This area currently covers 'Sales' Targets which are set at different times in the year. | true | false | true | Transactional | João Santos |
| Marketing | 8666e35b-cf2f-ef11-8184-c403a888648b | Marketing and Sales | true | Procurement plays a crucial role in our organization, ensuring efficient and strategic sourcing of goods and services. The domain illustrates two key elements: Procurement Methods and Market Conditions. The Procurement Method represents the approach employed for a particular procurement project, determining whether it will be an Auction, Request for Proposal (RFX), direct procurement, or other methods. Each method has a unique code and name for identification and reference. Market Conditions reflect the state of the supplier market, which can significantly influence procurement strategies. These conditions range from Monopoly, where a single vendor dominates the market, to Buyer's Market, where multiple vendors compete, giving the buyer more leverage. Accurately assessing the Market Condition is crucial for effective negotiation and decision-making. Both Procurement Methods and Market Conditions have corresponding codes and names for easy identification and reference within the organization's systems and processes. The interplay between these elements guides our procurement professionals in selecting the most appropriate method based on the prevailing market conditions, ultimately leading to optimal sourcing outcomes and cost-effective acquisitions. | true | false | false | Reference | João Santos |
| Sales Opportunity | 8c4e0381-b4fc-e911-80eb-9cd21e38f3a4 | Marketing and Sales | true | This area currently covers 'Sales' opportunities, but may in the future cover 'other' opportunities, which would be determined by the 'Opportunity Opportunity may be a sale or pending deal. Opportunites are classfied in to four categories, Acquisition, Renewal, Additional Business and One-off. Acquisition is new customer or new trade route/direction for an existing customer. Renewal is a straight forward "buy it again", same condition and product Additional Business is when selling a new product, new lanes or product family, then it's additional business. One-off : Non reoccurring business | true | true | true | Transactional | João Santos |
| Ocean Operations | 1ae3e9a0-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Shipment | 3e4f0381-b4fc-e911-80eb-9cd21e38f3a4 | Ocean Operations | true | Data about an order for cargo transport, or about a 'prebooking' for cargo transport. Note: Continuity of a Single Shipment Throughout and Compatibility Support Split Shipments During Transition This data model (along with the associated Shipment Route, Shipment Equipment and Cargo data models) supports the continuity of a single Shipment from initial creation at Booking time through to completion of all Shipment related processes (e.g. delivery of Cargo). It does not require and does not support, Split Shipment scenarios (e.g. the creation of Import Shipments or Operational Shipments, or the creation of additional Shipments to support production of multiple Transport Documents for a single Booking) that are used at the time of writing (October 2011) by some IT systems. Split Shipments add complexity, and no business requirement is currently (October 2011) known for them. | true | true | true | Transactional | João Santos |
| Operations | b4ead163-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Carrier Booking | 231847db-7836-ea11-ad93-40b034e2c22b | Operations | true | A booking for transport carriage with a transportation provider (internal or external provider). The Carrier Booking is sent to the carrier as a request. The carrier provides a response the carrier booking which is kept with the carrier booking request. | true | true | true | Transactional | João Santos |
| Service Plan | 23f87313-4f85-ea11-a3ad-a0510b9e9705 | Operations | true | The Service Plan (SPL) defines the scope of the service that Maersk is providing for a specific end-to-end shipment journey of a specific customer, such as: - where/when Maersk Ocean & Logistics service starts/ends; - where/when are specific services to occur; - what products and product add-ons are included; - what service features are included (Transport mode - Ocean, Air, Rail, Trucking; Cargo consolidation/ deconsolidation; Customs clearance etc.). 1 Service Plan will be for 1 Customer only. 1 Service Plan can only be for 1 specific end-to-end shipment journey. The SPL will typically be created/ generated either: - 1 Shipper Booking (once it's received), in the case of Logistics products like SCM, 4PL, CCL, etc.; - A document/ request equivalent to a Shipper Booking (to be defined/ modelled in the future), in the case of other products, like Rail, Trucking, stand-alone CHB or stand-alone WND; - rules on a Customer Rules Profile (either alone or in combination with 1 of above elements); - manually, by Maersk customer service. 1 Service Plan can only relate to 1 Shipper Booking. This is because we are saying the Shipper Booking is the moment when customer informs us what is exactly the scope of services he will be contracting with Maersk O&L for a given E2E shipment journey. - 1 Shipper Booking (once its received), in the case of Logistics products like SCM, 4PL, CCL, etc.; - A document/ request equivalent to a Shipper Booking (to be defined/ modelled in the future), in the case of other products, like Rail, Trucking, stand-alone CHB or stand-alone WND; - rules on a Customer Rules Profile (either alone or in combination with 1 of above elements); - manually, by Maersk customer service. 1 Service Plan can only relate to 1 Shipper Booking. This is because the Shipper Booking is when customer confirms what is the scope of services he will be contracting with Maersk O&L for a given E2E shipment journey. | true | true | true | Transactional | João Santos |
| Cargo Stuffing | 35370e07-ed11-ea11-80ed-9cd21e38f3a4 | Operations | true | Also referred to as the Container Stuffing or Equipment Stuffing, however to future proof the subject area and align more with Maersk Information Model it has been decided to call this Cargo Stuffing. We didn't want to limit the stuffing concept to only deal with containers or even equipment as stuffings can also take place on vehicles, i.e. airplanes or trucks. | true | true | true | Transactional | João Santos |
| Booking | 5d4e0381-b4fc-e911-80eb-9cd21e38f3a4 | Operations | true | A Booking is a request from a customer for arranging and/ or reserving services to be executed at a particular time. Typically, in shipping and logistics, the Booking is a contract of carriage evidencing the agreement to transport goods, and other possible related services, such as storage, transit, clearance, etc. Those services can be provided by various suppliers, in a subcontracted form. A Booking also typically includes the agreement on transport conditions such as price, time and liability. Service Plan A Booking will always have and contain a Service Plan. The Service Plan is the place where all Booking details around requested services shall be recorded. This includes, among others, required Commercial Products, Incoterms, Service Type (Port, Door, CFS, CY, etc.), Service Locations, Service Legs, Transport Provider, Transport Mode, Equipment/ Vehicle Requirements, etc. Service Locations are points between Service Legs (Place of Receipt, Port of Discharge, Final Destination, etc.), but also points of service (Place of Inspection, Place of Consolidation, etc.). | true | true | true | Transactional | João Santos |
| Transport Document | 5f540381-b4fc-e911-80eb-9cd21e38f3a4 | Operations | true | Transport documents provide an accounting record of the transaction, instructions on where and how to ship the goods and a statement giving instructions for handling the shipment. | true | true | true | Transactional | João Santos |
| Verified Gross Mass | 84375ac4-4b3b-ea11-ad95-40b034e2c22b | Operations | true | Verified Gross Mass (VERMAS or VGM), a SOLAS Convention requirement for container weight as defined by the International Maritime Organisation that transmits container weight information. | true | true | true | Transactional | João Santos |
| Work Order | 951d510c-57c1-ec11-a3fa-a0510b9e9705 | Operations | true | A Maersk internal order/ instruction to carry out the delivery of services that were requested by a customer, typically via a booking or similar request. The Work Order can therefore include and indicate work processes and activities to be carried out by Maersk employees. The Work Order typically also includes services to be executed out by vendors contracted by Maersk. | true | true | true | Transactional | João Santos |
| Seal | c5e6a557-d6f5-eb11-a3d6-a0510b9e9705 | Operations | true | Container seals are door seals that are put on international shipping containers once a shipment is loaded. This seal is meant to stay on through to the container's final destination and is removed by the consignee. Each seal has its own unique number as identification that is listed on the shipping paperwork. | true | true | true | Transactional | João Santos |
| Transport Plan | ce735fda-3c4d-ea11-ad9c-40b034e2c22b | Operations | true | Transport Plan is also known in SCM as Shipment Plan. The Transport Plan represents the planning and actual execution of a transport service (i.e. the physical journey Maersk O&L is planning for a specific transport, its locations, transportation legs, and events associated with that transport), whereby Maersk O&L contracts a Transport Provider to execute it. Such transport service will be the actual execution of a transport service request by a Customer. Typically (but not necessarily) , such transport service request comes in the shape of a Service Plan Leg from a Service Plan (see Transport Order and Service Plan SA's for more details). Relationship Between Service Plan (Legs), Transport Plan, Transport Order, Transport Leg Service Plan (Legs) can be seen as an individual service request by a Customer to move cargo from one location to another and perform other logistics services. Transport Plan is the plan and actual execution of that service, whereby Maersk O&L contracts a Transport Provider to execute 1 or more of the Service Legs. Transport Order can consider and combines Service Legs from same Service Plan and/can group Service Legs from different Service Plans (this is the case, for instance, of LCL business scenario) to execute delivery of the service. Transport Legs will be the actual physical stages of the transport, performed by a vehicle (vessel, truck, aircraft, etc.), and therefore, wont necessarily match the Service Legs. | true | true | true | Transactional | João Santos |
| Party | a7140d6e-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Taxation Information | 2c4a0381-b4fc-e911-80eb-9cd21e38f3a4 | Party | true | This domain models the data which needs to be captured and stored by Maersk on behalf of a Party (typically a Customer or Supplier/Vendor). This data includes Taxation Rates and Tax Codes. Exclusions: Tax is the actual charge amount levied or imposed on a person or organisation by a 'state' or official body, and is not part of this model. Neither does this cluster model "Tax Invoices" - that is, the tax-relevant details on "Sales/Customer Orders/Invoices" and on "Purchase/Supplier Orders/Invoices". | true | true | true | Master | João Santos |
| Vendor | 3d16603b-5fc7-ee11-b87a-44e517a1f1d9 | Party | true | The diagram illust roles vendor details that are applicable within specific Maersk business units or divisions. Key entities include the Vendor Business Unit Profile, which encapsulates details and features specific to a vendor within a particular business unit or company codes. This profile links to various related concepts, such lengths for the vendor service type provided, tax jurisdicitements, agreements, and payment terms. The Vendor Business Unit Profile entity captures crucial information locks whether the vendor is blocked for purchasing or payment within the business unit. It also contains indicators for enabling features allowing evaluated receipt settlements (ERS), auto-generated invoicing plans, individual mandatory payments, subsequent sells, and order acknowledgement requirements. The diagram depicts the Vendor Business Unit Profile's relationships with other relevant entities, such as ledger accounts for reconciliation, the assigned company code and purchasing organization, pricing procedures, shipping conditions, and communication media types for account statements and payment advices. Additionally, the Vendor Business Unit Profile connects to the Vendor entity, capturing general vendor details applicable across business units. The Vendor class, in turn, inherits from the Party class, which radically represents organizations or individuals of interest to Maersk. | true | true | true | Master | João Santos |
| Contact Address | 3f4a0381-b4fc-e911-80eb-9cd21e38f3a4 | Party | true | Data about addresses or identifiers that can be used to contact Parties (acting in speccific roles), Sites, Facilities etc. | true | true | true | Master | João Santos |
| Party Association | 4602f323-69ac-ee11-a1bf-d7e14702d112 | Party | true | The relationship between different parties involved in a transaction or operation. This can be used to support both master and transactional data associations to parties. In the context of logistics, several parties are associated with a Customer Order, for example: Consignee: The party to whom the cargo will be delivered. Agent: The party who acts on behalf of another party. Buyer: The party purchasing goods or services. Carrier: The party responsible for the transport of goods. Vendor: The party selling goods or services. Supplier: The party providing goods or services. The 'party association' also includes information about the address and name of the party. This data can be stored transactionally where it needs to be kept as it was at the creation time. If the data needs to be refreshed from the master data set, this must be a conscious action. A "Party Function" will specify what purpose the relationship with the party serves. Examples could include roles such as Agent, Consignee, Buyer, Carrier, Vendor, Supplier, Manufacturer, Shipper etc. This domain represents transactional data (not Master Data). | true | false | false | Transactional | João Santos |
| Party | 56f9e667-f688-ea11-adaa-40b034e2c22b | Party | true | Data about organisations in which Maersk has an interest. These organisations can be defined as Customers, Vendors, Carriers, Bank institutes, etc, and are identified by the Party type. Included are the party segmentations, assessments, certifications, communication preferences Exclusions: * Agreements regarding the way business is to be conducted, such as Contracts and Rate Agreements, or Customer Requirements (confirmed or otherwise) such as Bookings or standing requirements regarding the nature and mode of communications. | true | true | true | Master | João Santos |
| Customer | 5cb0f417-6de7-ee11-b885-44e517a1f1d9 | Party | true | The domain represents various aspects related to managing business relationships with customers. It covers details such as customer profiles, agreements, tax jurisdictions, credit information, exchange rates, payment conditions, and banking accounts. The central entity is the "Customer Business Unit Profile," which contains customer-specific details applicable to a particular Maersk business unit or division. This includes information like external account numbers, profit margins, credit ratings, communication preferences, and associated payment conditions, tax jurisdictions, exchange rate markups, and bank accounts. The "Customer" entity represents individuals or organizations that purchase services from Maersk. It captures general customer data like customer codes and group types (internal or external). Customers have associated credit information, currencies, exchange rate types, and payment conditions. The "Agreement" entity represents contracts or arrangements between Maersk and customers, specifying terms, conditions, and pricing for services. These agreements can have associated references for tracking purposes. Other entities include "Tax Jurisdiction" for defining tax authorities, "Ledger Account" for financial accounting, "Business Unit" representing Maersk's divisions or brands, "Dunning Type" for managing overdue payments, and reference data like currencies, exchange rate types, time frequencies, and communication media types. The diagram aims to provide a comprehensive view of the data required to effectively manage customer relationships, agreements, financial aspects, and communication within Maersk's operations. | true | true | true | Master | João Santos |
| Business Unit | 73ea0b6d-96fc-ee11-b889-44e517a1f1d9 | Party | true | This domain represents key financial and operational data to support the business activities and reporting needs of the Maersk organization and its various Business Units. It includes information about organizational structures, such as Business Activities, Reporting Units, Business Units, Brands, and Products/Services offered. These entities are connected through hierarchical and associative relationships. The diagram also encompasses financial and accounting concepts like Reporting Keys, Chart of Accounts, and Currencies used within the organization. Activity Groups and Activity Types help categorize and define the nature of operations. Geographic areas where Maersk operates are represented through Defined Areas, capturing locations relevant for business, jurisdictional, or administrative purposes. External parties, including customers, vendors, carriers, and banks, are modeled as separate entities, enabling the tracking of relationships and associated details like bank accounts. Overall, the diagram provides a comprehensive view of the interrelated data domains essential for managing Maersk's global business operations, financial reporting, and organizational structures across various geographies and product/service lines. | true | true | true | Master | João Santos |
| Bank Details | 75e4b7d1-b873-ea11-ada5-40b034e2c22b | Party | true | Models the bank account details as these are defined for a party acting in a specific party role, such as customer or supplier. | true | true | true | Master | João Santos |
| Product | 0d4a0987-c673-ea11-ada5-40b034e2c22b | true | true | ||||||
| Product | 2d373a81-b4fc-e911-80eb-9cd21e38f3a4 | Product | true | The standardized service that a customer can purchase as standalone and is replicable across many customers. A Product is offered and sold to a customer as a whole, and cannot have its components sold separately. A complete and updated version of all Products offered by Maersk can be obtained on the Maersk Product Catalogue page: https://teamsite.maerskgroup.com/sites/TransformationOffice/SitePages/Maersk-Product-Catalogue.aspx ATTENTION: It should be noted that only the values of Product defined by the Maersk Product Catalogue can be used. It is not allowed to have customized values and/or non-approved by Maersk Product Catalogue team. | true | true | true | Master | João Santos |
| Material | a007fefb-a18f-ef11-b8ac-44e517a1f1d9 | Product | true | The domain represents a framework for managing materials and their relationships within an enterprise. It encompasses various aspects, including material groups, units of measurement, ledger accounts, and their interconnections. The central entity is the Material, which represents goods and services that an enterprise can purchase, sell, produce, or store. Materials are organized into Material Groups, which logically group them from a business perspective. Each Material is associated with a Material Name, Description, Local Name, Charge Code, and Material Code for identification purposes. Materials can be linked to other Materials through Material Linkages, indicating potential counterparts or alternatives for cost and revenue estimation purposes. Materials are also associated with specific Units of Measurement for quantifying quantities, such as liters, kilograms, or units. They can be restricted based on various criteria, including brands, geographies, cargo types, routes, vessel types, equipment types, and customers. Materials are mapped to Ledger Accounts from the enterprise's Chart of Accounts, enabling financial accounting transactions and supporting the generation of financial statements. The framework also incorporates concepts like Product Groups and Product Elements, allowing Materials to be associated with product hierarchies and configurations. Additionally, the diagram includes enumerations for tracking Material Status (e.g., Active, Inactive), Profit and Loss Type, Charge Application (e.g., Origin, Freight, Destination), Charge Negotiation Type (e.g., Negotiable, Non-Negotiable), and Transport Activity. Overall, this framework provides a structured approach to managing materials, their categorization, measurement, financial accounting, and relationships within an enterprise's operations. | true | true | true | Master | João Santos |
| Product Offer | fdbdee93-58cd-ea11-adbd-40b034e2c22b | Product | true | The domain depicts a central concept called a "Product Offer," which represents a bookable offer presented to a customer for a specific set of request parameters. A Product Offer consists of one or more "Selected Products," which are transactional instances of master data "Products" offered by the organization. These Selected Products may have associated configurations or options, represented by "Selected Product Configurations" and "Product Configuration Options." The Product Offer is related to an "Agreement" or contract, which specifies terms and conditions between the organization and customers. It can also reference other entities such as "Agreement Lines," which provide details on prices, products, quantities, etc., and "Rates," which represent sets of estimated prices for goods and services. The Selected Products are linked to a "Service Plan," which defines the scope of services provided by the organization for a specific end-to-end shipment journey of a particular customer. The Service Plan includes details such as service locations ("Service Plan Locations"), service legs ("Service Plan Legs"), and other service-related information. Additionally, the Selected Products may be associated with a "Routing," which represents the various routes offered to customers for transporting cargo, and "Work Activities," which capture the actual activities performed during the work process. The domain also shows relationships between Selected Products and other entities like "Bookings," which represent customer requests for arranging services, and "Work Processes," which represent the planning and execution of business processes. | true | true | true | Transactional | João Santos |
| Reference | 6271dfdd-c573-ea11-ada5-40b034e2c22b | true | true | ||||||
| Soft Coded Value | 1c417d63-805e-ea11-ad9f-40b034e2c22b | Reference | true | A domain that supports usage of soft coded values for entities that needs this. Most database applications directly map concepts to tables. The direct approach is effective for applications with well-defined entity types and attributes. However, it fails for applications with open-ended requirements. See also: https://www.dataversity.net/softcoded-data/ | true | false | false | Transactional | João Santos |
| Language | 39393a81-b4fc-e911-80eb-9cd21e38f3a4 | Reference | true | Data about languages, language families and character sets. | true | true | true | Reference | João Santos |
| Shipping Terms | 42a9dcfa-8274-ea11-ada5-40b034e2c22b | Reference | true | International Commercial Terms ('Incoterms') are internationally recognised standard trade terms used in sales contracts. | true | true | true | Reference | João Santos |
| Currency | 518bc1a1-6075-ea11-ada5-40b034e2c22b | Reference | true | Data about currency codes and exchange rates. | true | true | true | Reference | João Santos |
| Reference | 5db193bc-d432-ec11-835e-06c2a96b6089 | Reference | true | Subject area is containing classes supporting data objects having any kind of references associated. This is useful where it is not known in advance what the references are, or there are too many references making it infeasible to list all of them specifically. | true | true | false | Reference | João Santos |
| Modality | 78f69220-968b-ea11-a3ad-a0510b9e9705 | Reference | true | Also known in the industry as "Modality", this refers to the transport mode (ocean, air, rail, road, barge) or modes that a shipment can have, as well as the service types of the shipment. The service types are the industry standard service type classifications, that are used to specify the scope/ range of service provided, i.e. what is included, in terms of parts of the end-to-end journey, consolidation/ deconsolidation, how cargo is transported, etc. | true | true | true | Reference | João Santos |
| Unit of Measurement | 7b373a81-b4fc-e911-80eb-9cd21e38f3a4 | Reference | true | This cluster models data about measurements, in which a standardised quantity of a Measured Property (which, in this model, also includes the special case of Currency) is used as a factor to express occurring quantities of that property, defined and adopted by convention and/or by law, that is used as a standard for measurement of that property. Any other value of the measured property can be expressed as a simple multiple of the unit of measurement. For example, length is a Measured Property. The metre is a unit of length that represents a definite predetermined length. When we say 10 metres (or 10 m), we actually mean 10 times the definite predetermined length called "metre". | true | true | true | Reference | João Santos |
| Calendar | af383a81-b4fc-e911-80eb-9cd21e38f3a4 | Reference | true | This model presents the data entities in the Calendar subject area. It is a Gregorian Calendar A system that organises days (or smaller periods of time) for commercial or administrative purposes. Includes: - Calendars of public holidays as defined by the relevant authorities in various geographical areas - Business defined calendars applicable in a Geographical Scope or at a location. For example exception days on which Demurrage is not chargeable due to strike action or equipment failure at a Terminal Note that the time periods modelled here are specific only to particular Geographic Defined Areas (typically countries) - time periods for availability (opening hours) of specific Facilities such as terminals are modelled in the Facility Availability entity. Note also that it is assumed that the annual standard calendar is not to be modelled here, since it is so universally available within Windows, SAP and other applications. | true | true | true | Reference | João Santos |
| Communication Media | c06bfe92-6a3d-ec11-ab95-5c879c3c5a54 | Reference | true | Mode of communication between parties. Examples: * Email * Fax * Post * Electronic Data Interchange, Classic * Application Programmers Interface * Web site (e.g. for Web based Booking) * Telephone * Telex | true | true | true | Reference | João Santos |
| Alternative Term | d1283987-1843-ea11-ad97-40b034e2c22b | Reference | true | A generic approach to handle the various alternative codes and name aliases that data can be associated to. This is extremely relevant when for example receiving and sending data from and to business partners who use their own codes and names for locations, parties etc. These all needs to be translated to names and codes used in Maersk. This subject area deals with those kind of concepts. | true | true | false | Reference | João Santos |
| Storage and Distribution | eb3e0026-f9e5-eb11-8336-06892ccaedcb | true | true | ||||||
| Warehouse Storage | 24e3c137-f9e5-eb11-8336-06892ccaedcb | Storage and Distribution | true | Enables the further breakdown of a facility into a configrued storage layout, including warehouse areas, aisles, units, shelf and bins. | true | true | true | Master | Steven Bosman |
| Inventory Management | 3ae6615f-9030-ec11-835e-0646afcad5a9 | Storage and Distribution | true | Handles data about how to manage an inventory in terms of replenishment, receipt planning etc. | true | true | true | Master | Steven Bosman |
| Inventory | 6554e12d-f9e5-eb11-8336-06892ccaedcb | Storage and Distribution | true | Contains data about the inventory of specific commodities, commodity items, packages etc. at specific facilities via facility storage. Also captures individual inventory transactions that occurs on the inventory for various purposes, e.g. receipt, return or audit. | true | true | true | Transactional | Steven Bosman |
| Warehouse Shipment | 6854e12d-f9e5-eb11-8336-06892ccaedcb | Storage and Distribution | true | Central area for warehousing to control inbound and outbound shipments to and from a warehouse. | true | true | true | Transactional | Steven Bosman |
| Label and Scanning | 8d8a53e1-1117-ea11-ad8b-40b034e2c22b | Storage and Distribution | true | Refers to all physical labels, or other physical identifies, such as barcodes or Radio Frequency Identification Tags (RFID), that are attached to Cargo Packages, as a means to properly identify them and handle them, as well as the act and business process(es) of scanning such physical identifiers. | true | true | true | Transactional | Steven Bosman |
| Appointment | f134343d-1757-ec11-836c-06971f1d0419 | Storage and Distribution | true | Contains data about truck and trailer appointments at facilities. | true | true | true | Transactional | Steven Bosman |
| Warehouse Operations | fde6e5a0-5d59-ec11-836c-065005c60085 | Storage and Distribution | true | Data about operations that take place within a warehouse, instructions from customers to Maersk about how to carry out the warehouse operations as well as master data about how commodities should be treated in the warehouse during operations. | true | false | false | Transactional | Steven Bosman |
| Supply Chain Management | 449fa061-83fa-11f0-64d1-e682385842d0 | true | |||||||
| Forwarders Cargo Receipt | 3b370e07-ed11-ea11-80ed-9cd21e38f3a4 | Supply Chain Management | true | The Forwarders Cargo Receipt (FCR) is a document stating that the cargo has been duly received by a Forwarder, or equivalent Logistics Operator. The FCR is issued to the Shipper. The Shipper can then use the FCR as proof of cargo handover in order to receive a payment (for instance, based on a Letter of Credit, in an bank agreed with Buyer/ Consignee). | true | true | true | Transactional | João Santos |
| Customer Order | 3e370e07-ed11-ea11-80ed-9cd21e38f3a4 | Supply Chain Management | true | Customer order number is the main reference provided by Maersk's customer which are intended as their purchase order, sales order or production orders. Main types of customer orders Purchase Order: Customer buys product from their shippers/ vendors; they will raise a PO to their shipper with quantity and requested shipment location. Sales Order: Customers has sold cargo to their consignee; they have a Sales Order reference that they want to ship. Production Order: Customers is sending a request to their own factory (internal transfer) or shipper's factory (buy from external party) to request for product. It is important to note that a 'Customer' to Maersk can be either a shipper or consignee. Shipper will receive the Customer Order and use the information to make a Shipper Booking with Maersk to assist with the transportation services. The order data comes with very detailed information about the products that is to be produced or bought and then shipped to a customer specified location. The data on the Customer Order's are used in many transportation related documents through the transport process. This is the reference number that is most used by external parties as this is their own reference number in their documentation and systems. | true | true | true | Transactional | João Santos |
| Shipper Booking | 7e370e07-ed11-ea11-80ed-9cd21e38f3a4 | Supply Chain Management | true | A Shipper Booking is a request to Maersk O&L to transport cargo from one location to another. The shipper will specify details in the booking to ensure the cargo is handled and shipped correctly. This includes pick up locations, cargo commodity (ie. Normal, Dangerous Goods, Reefer) to Incoterms of the shipment. The Shipper Booking can be created by the shippers themselves via online portal or by Maersk staff if the shipper books via phone or email. The Shipper Booking is a central data element in the SCM business and are closely related to a number of other important data elements like the Customer Purchase Order, Equipment Stuffing, Transport Order, Packing List, Commercial Invoice etc. A Shipper Booking does not need to be created based on a Customer Purchase Order. It is possible to create "blank shipper booking" where all information about the product is entered directly with the Shipper Booking. Shipper Booking will eventually be linked to a Carrier booking and part of Transport Plan. | true | true | true | Transactional | João Santos |
| Packing List | 85370e07-ed11-ea11-80ed-9cd21e38f3a4 | Supply Chain Management | true | This document is created by the Shipper to confirm and to declare what is shipped and packed. Document includes Shipper Name, Consignee, Product description, quantity, packages, product info such as country of origin, etc This document is commonly used as a base document for Shipping Instructions submission to generate the Carrier Bill of Lading. Details on the Packing List, Commercial Invoice and Carrier BL needs to match as they are submitted to Customs Officials for export and import customs clearance. | true | true | true | Transactional | João Santos |
| Manufacturer Production Plan | ae40f1b4-421a-ea11-ad8c-40b034e2c22b | Supply Chain Management | true | Holds the production planning dates that the Maersk customer transmits via their Customer Purchase Orders to the factories in origin. Production planning dates could impact when the cargo is ready to be shipped. | true | true | true | Transactional | João Santos |
| Vehicle | afc8c1c5-2da5-ea11-adb1-40b034e2c22b | true | true | ||||||
| Vessel Specification | 0225cfbb-9bf5-ee11-817a-c403a888648f | Vehicle | true | The detailed description of a ship or vessel's characteristics and capabilities. This includes information such as the breadth or width of the vessel at its widest point, measured at the nominal waterline. It also includes information related to the Hull, including Propeller details. | true | true | true | Master | Steven Bosman |
| Vessel Machinery | 0ad867c8-1d6a-eb11-a69c-b88a608bad70 | Vehicle | true | Details relating to the Main and Auxillary Engines. | true | true | true | Master | Steven Bosman |
| Fuel Consumption | 1a560381-b4fc-e911-80eb-9cd21e38f3a4 | Vehicle | true | Data that represents the expected behaviour/properties of Fuel consumption. The consumptions are specific per type of vehicle as the consumption parameters are specific per vehicle - for example vessel is based on draft and velocity, whereas aircraft will be on altitude and speed, etc. | true | true | true | Transactional | Steven Bosman |
| Fuel | 35520381-b4fc-e911-80eb-9cd21e38f3a4 | Vehicle | true | Data about characteristics of different fuel types. | true | true | true | Reference | Steven Bosman |
| Vessel | 66520381-b4fc-e911-80eb-9cd21e38f3a4 | Vehicle | true | A floating structure designed for the transport of cargo and/or passengers, and the various means of classifying such structures. | true | true | true | Master | Steven Bosman |
| Vehicle | 79540381-b4fc-e911-80eb-9cd21e38f3a4 | Vehicle | true | A specific transportation device designed for moving cargo and/or people. | true | true | true | Master | Steven Bosman |
| Vessel Classification | fdc7a696-2d6a-eb11-a69d-b88a608bad70 | Vehicle | true | Details related to Capacity of the vessel, including * Ancillary capacity - Fuel Capacity or People capacity, etc * Financial Capacity - Grouping for financial reasons * Capacity Class - type of Vessel - which provides generic capacities | true | true | true | Master | Steven Bosman |
| ZZ - Primitive Data Types | 87cbad77-040e-5368-ac70-a193d4d55766 | false | false | false | false | Reference | Benjamin Mogensen |