WMS and TMS Concepts, Architecture and Master Data

Introduction and Context

Logistics performance depends not only on physical assets, people and procedures, but also on the quality of information used to coordinate them. A warehouse may possess adequate storage capacity and labour, yet experience stock-outs, congestion, mis-picks and delayed dispatches because information is incomplete or delayed. Similarly, a transport operation may own sufficient vehicles but incur excessive cost because loads, routes, carriers, rates and delivery commitments are poorly integrated.

Warehouse Management Systems (WMS) and Transportation Management Systems (TMS) are enterprise applications designed to control, coordinate and improve these activities. A WMS manages the receipt, storage, movement, counting, picking, packing and dispatch of inventory within warehouses and related facilities. A TMS plans, executes, monitors and analyses the movement of goods between locations. They are distinct systems, but their processes overlap at shipment preparation, dock scheduling, carrier handover, proof of delivery and inventory visibility.

For postgraduate logistics professionals, the central issue is not simply what a WMS or TMS can do. It is how the systems should be designed, configured, integrated and governed so that operational decisions reflect business strategy. This requires an understanding of functional modules, system architecture, deployment choices, master data, transaction data, integration standards, performance measures and implementation risks.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Explain the purpose, scope and relationship of WMS and TMS.
2. Describe their principal modules, workflows and deployment models.
3. Compare common system architectures and integration patterns.
4. Distinguish master data from transactional, reference and event data.
5. Specify master-data requirements for items, locations, inventory, packaging, vehicles, carriers, routes, rates and customers.
6. Analyse data governance, implementation and interoperability challenges.
7. Apply WMS and TMS concepts to an integrated logistics case.

1. WMS and TMS as Execution and Coordination Systems

1.1 Warehouse Management Systems

A WMS is a software system that directs and records warehouse activities at an operational level. It normally receives demand and supply information from enterprise systems, converts that information into executable work, assigns tasks, records confirmations and provides inventory visibility.

Its scope commonly includes:

• inbound appointment and receiving;
• purchase-order and advance-shipping-notice processing;
• inspection, quarantine and quality status control;
• put-away and replenishment;
• location and capacity management;
• inventory status and traceability;
• cycle counting and stock adjustment;
• wave, batch, zone and discrete order picking;
• packing, labelling and shipment staging;
• labour, equipment and task management; and
• operational reporting and performance analysis.

A WMS is more than an electronic stock ledger. A stock ledger answers questions such as “How many units are recorded?” A WMS additionally answers “Where are they?”, “Which task should be performed next?”, “Who is authorised to perform it?”, “What handling restrictions apply?” and “Has the physical movement been confirmed?”

1.2 Transportation Management Systems

A TMS supports the planning, procurement, execution, monitoring and settlement of transportation. It may be used by shippers, carriers, third-party logistics providers or logistics service platforms.

Typical capabilities include:

• shipment creation and consolidation;
• mode and service selection;
• load building and capacity planning;
• route and stop sequencing;
• carrier tendering and acceptance;
• freight-rate and contract management;
• dock and appointment coordination;
• dispatch and vehicle instructions;
• in-transit tracking and exception management;
• electronic proof of delivery;
• freight audit and payment; and
• transport-cost, service and emissions analysis.

A TMS can use optimisation algorithms, but optimisation is only as reliable as the constraints and data supplied to it. A mathematically sophisticated route plan can be operationally poor if vehicle capacities, customer time windows, road restrictions or unloading times are inaccurate.

1.3 Relationship between WMS and TMS

The WMS primarily controls activities inside a facility; the TMS primarily controls movements between facilities and customer or supplier locations. The boundary is not absolute. Dock scheduling, yard management, cross-docking, parcel manifesting and shipment staging may be managed by either system or shared between them.

A common integrated sequence is:

1. An order-management or enterprise resource planning system creates demand.
2. The WMS allocates inventory and creates warehouse work.
3. The WMS confirms picked quantities, packages and shipment readiness.
4. The TMS consolidates shipments, selects carriers and plans routes.
5. The WMS stages and loads freight according to the transport plan.
6. The TMS records departure, tracking events and delivery confirmation.
7. Confirmed delivery, inventory and financial information returns to enterprise systems.

The integration principle is “one authoritative owner for each business object.” For example, the WMS may be authoritative for actual packed quantities, while the TMS is authoritative for a carrier tender and planned route. Duplication without ownership creates contradictory records.

Figure: Conceptual relationship between enterprise systems, WMS, TMS and external logistics parties.

2. Functional Modules and Workflows

2.1 WMS workflow

Inbound. The process begins with an expected receipt, often based on a purchase order, production order, transfer order or return authorisation. An appointment or advance shipping notice may provide expected cartons, pallets, item identifiers, quantities and lot information. At receipt, the WMS validates the physical goods, records discrepancies, assigns inventory status and creates handling units. Put-away rules then consider item velocity, storage compatibility, available capacity, temperature requirements, hazardous-material restrictions and future picking demand.

Storage and inventory control. The system maintains a location hierarchy, such as site, building, zone, aisle, bay, level and position. It records on-hand, allocated, available, damaged, blocked, quarantined and in-transit quantities. Inventory may be controlled by lot, serial number, expiry date, country of origin or ownership. Cycle counting replaces or supplements periodic full physical counts by generating targeted count tasks.

Outbound. Orders are released according to service commitments, inventory availability, carrier cut-off times and warehouse workload. The WMS may create waves by route, customer, product family or dispatch time. Picking can be discrete, batch, zone, cluster or goods-to-person. After picking, goods are checked, packed, weighed, labelled and assigned to a shipment or handling unit. The final confirmation should represent what was physically packed, not merely what was originally ordered.

2.2 TMS workflow

A TMS first transforms orders into transportation demand. It may consolidate compatible orders into shipments, loads or tours. Planning considers origin, destination, equipment, weight, cube, delivery windows, service requirements, legal restrictions and carrier agreements.

The system then selects a mode or carrier. Selection may be rule-based, cost-based, service-based or multi-objective. A tender is sent to a carrier, accepted or rejected, and escalated according to a tendering hierarchy. Execution includes dispatch, status events, location tracking, delay alerts and delivery confirmation. Financial close includes freight-rating, accessorial validation, invoice matching and payment approval.

2.3 Control loops and exceptions

Both systems should be designed around exceptions rather than only normal flows. Examples include short receipt, overage, damaged goods, inventory mismatch, failed tender, late departure, vehicle breakdown, temperature excursion and refused delivery. An effective exception record contains the event time, responsible party, affected object, severity, required action, deadline and resolution history.

3. System Architecture and Deployment Models

3.1 Layered architecture

A practical architecture separates:

1. User and device layer: web clients, mobile scanners, voice terminals, vehicle-mounted computers, dashboards and partner portals.
2. Application layer: receiving, inventory, picking, transport planning, rating, tracking and settlement services.
3. Data layer: master data, transaction data, event history, audit records and analytical data.
4. Integration layer: APIs, message queues, electronic data interchange, file exchange and event streaming.
5. Infrastructure and security layer: networks, identity management, encryption, monitoring, backup and recovery.

This separation supports maintainability and controlled change. Warehouse devices may require near-real-time responses even when analytical reporting is processed later. Therefore, operational databases and analytical data platforms are often separated or logically partitioned.

3.2 Architectural patterns

Monolithic suite. WMS or TMS functions are delivered as one closely integrated application. This can simplify configuration and data consistency, but upgrades may affect many functions and specialised capability may be limited.

Modular suite. Functional modules share a platform and common data model but can be deployed or upgraded with some independence. This balances integration and flexibility.

Service-oriented or microservice architecture. Functions such as rating, inventory availability, route planning and notification are exposed as services. This improves scalability and independent release, but increases operational complexity, observability requirements and data-consistency challenges.

Best-of-breed ecosystem. Specialist WMS, TMS, optimisation, yard and visibility solutions are integrated around enterprise systems. This can provide superior functional fit but requires strong interface governance and clear ownership of shared data.

3.3 Deployment models

• On-premises: the organisation owns or controls infrastructure. It provides extensive control but requires capital, technical staff, upgrades and disaster-recovery capability.
• Hosted or managed: infrastructure and often operations are provided by a technology partner.
• Software as a Service (SaaS): the provider operates a multi-tenant or dedicated cloud application, normally charging by subscription or usage. Benefits include faster deployment and regular updates; constraints may include configuration limits, data-residency issues and dependence on connectivity.
• Hybrid: core systems remain in different environments, often because of legacy applications, security requirements or local operational constraints.
• Edge-enabled: local computing or buffering supports scanners, automation and facilities where network interruption cannot stop critical work.

Deployment should be evaluated using total cost of ownership, availability requirements, cybersecurity, integration effort, data sovereignty, scalability, vendor viability, configuration freedom and exit options. Cloud adoption is not a substitute for process redesign or data governance.

4. Master Data and Information Governance

4.1 Data categories

Master data describes relatively stable business entities and their attributes: items, locations, customers, carriers and vehicles. Transactional data records business activities: purchase orders, receipts, picks, shipments, tenders and invoices. Reference data provides controlled values such as units of measure, service codes, status codes and country codes. Event data records changes over time, such as scan events, GPS positions and temperature readings.

Master data is not necessarily permanent. A product dimension, carrier contract or customer delivery window can change. The important distinction is that master data is reused across transactions and therefore has broad impact.

4.2 Data-quality dimensions

Useful dimensions include:

• accuracy: the value represents reality;
• completeness: required fields are populated;
• consistency: the same entity has compatible values across systems;
• timeliness: changes are available when needed;
• uniqueness: duplicates are controlled;
• validity: values conform to permitted formats and ranges; and
• traceability: changes have an accountable source and history.

A simple data-completeness measure can be used for a defined set of required fields:

This measure assumes that every required field has equal importance. In practice, weighted completeness may be more meaningful when a missing hazardous-material code is more consequential than a missing descriptive note. Completeness alone does not demonstrate accuracy.

4.3 Governance roles

A data owner is accountable for business meaning and policy. A data steward maintains quality, definitions and workflows. A system custodian manages technical storage, access and controls. Governance should specify who creates, approves, changes, archives and audits each data object. Critical changes should use effective dates and, where necessary, versioning rather than overwriting historical values.

5. WMS Master Data Requirements

5.1 Item master

The item master is the foundation of warehouse execution. Typical attributes include:

• unique item identifier and description;
• product family, category and ownership;
• base, ordering, purchasing and shipping units of measure;
• conversion factors between units;
• dimensions, weight, cube and dimensional tolerances;
• barcode symbologies and alternate identifiers;
• lot, serial, batch and expiry controls;
• shelf-life and minimum remaining-life rules;
• storage, handling, temperature and hazardous-material requirements;
• demand velocity or ABC classification;
• picking method and replenishment parameters;
• country of origin, regulatory and customs information; and
• packaging hierarchy and standard quantities.

A unit conversion must be unambiguous. If one case contains 24 eaches, the relationship is 1 case = 24 each. The system must also identify whether the conversion is fixed or variable. Variable-weight products cannot be safely represented by a fixed conversion alone.

5.2 Location master

Locations require identifiers, hierarchy and physical attributes. Important fields include location type, dimensions, maximum weight, cubic capacity, usable capacity, temperature zone, security classification, pick-face status, replenishment relationship, operational sequence and permitted inventory classes.

Nominal capacity is not always usable capacity. A location may have physical volume but be unavailable because of access clearance, fire regulations, mixed-SKU restrictions or equipment limitations. Location status should distinguish active, blocked, maintenance, quarantine and temporary locations.

5.3 Inventory master and inventory status

Inventory records should link item, location, quantity, unit of measure, ownership, lot or serial, condition and status. Common statuses include available, allocated, picked, damaged, expired, quarantine, quality hold and in-transit. The system should preserve an auditable movement history rather than allowing unexplained balance replacement.

Inventory accuracy may be expressed as:

The definition of “accurate” must specify tolerance. A record may be considered accurate only when system quantity equals physical quantity, or when variance is within an approved tolerance. Different methods produce different reported results.

5.4 Packaging and handling units

Packaging master data defines pallets, cartons, totes, drums, cages and other handling units. It should include external dimensions, tare weight, maximum gross weight, nesting or stacking rules, returnability, material type and barcode identity. Packaging hierarchy commonly links each, inner pack, case, pallet and container.

Poor packaging data causes incorrect cube calculations, unsuitable vehicle selection, label errors and unstable warehouse slotting. Packaging changes should be controlled because a product revision may alter both storage and transport requirements.

6. TMS Master Data Requirements

6.1 Vehicles and equipment

Vehicle data includes vehicle identifier, type, legal and operational capacity, internal dimensions, axle restrictions, temperature capability, compartments, lift-gate availability, hazardous-material permissions, ownership, availability calendar and telematics identifier.

Weight capacity and volume capacity are distinct constraints. A load may be under the vehicle’s weight limit but exceed usable cube, or fit by cube but exceed axle or legal limits. The usable capacity should reflect operational realities such as load distribution and loading clearances.

6.2 Carriers and service providers

Carrier master data should identify legal entity, operating licences, modes, service regions, contact details, insurance, compliance status, equipment types, performance history and communication capabilities. Carrier identifiers must be harmonised because the same provider may appear under different names in procurement, TMS and finance systems.

6.3 Network, routes and stops

Network data includes sites, customer locations, supplier locations, terminals, ports, cross-docks and geographic coordinates. Address validation is essential; a postal address is not always a routable vehicle location.

Route data may include lanes, permitted modes, standard transit times, distance, tolls, restrictions, border requirements and time-zone information. Planned transit time should be distinguished from actual elapsed time. Delivery windows need opening time, closing time, service duration and appointment rules.

6.4 Rates and accessorials

A freight-rate record normally includes carrier, origin and destination scope, mode, service level, effective dates, rating basis, currency, minimum charge, breakpoints, fuel mechanism and accessorial charges. Rating may be based on weight, volume, distance, pallet count, container, shipment, zone or a combination.

A simplified distance-based charge can be represented as:

This is a conceptual model, not a universal tariff formula. Its application requires clearly defined units, effective dates, minimum charges, taxes and the rule for determining billable distance. A contract may instead use zones, weight breaks or dimensional weight.

6.5 Customers and delivery requirements

Customer master data includes legal and delivery names, validated addresses, geocodes, contact details, receiving hours, holidays, delivery windows, unloading requirements, appointment rules, access restrictions, preferred carriers, service level, billing terms and proof-of-delivery requirements.

Customer-specific rules should be configurable rather than hidden in informal employee knowledge. However, excessive customer-specific customisation can make the system difficult to maintain and can undermine standard processes.

7. Integration, Security and Control

7.1 Integration mechanisms

Common mechanisms include REST or SOAP APIs, EDI messages, secure file transfer, database replication, message queues and event streams. APIs are useful for synchronous requests such as checking inventory availability. Events are useful for notifying multiple systems that something happened, such as “shipment dispatched” or “delivery confirmed.”

Interfaces need agreed identifiers, message ownership, validation rules, retry behaviour, error queues, reconciliation reports and idempotency controls. Idempotency means that processing the same message more than once does not create duplicate business effects. For example, a repeated dispatch message should not reduce inventory twice.

7.2 Cybersecurity and privacy

WMS and TMS environments can expose customer addresses, shipment contents, driver information, commercial rates and operational vulnerabilities. Controls should include least-privilege access, multi-factor authentication, encryption in transit and at rest, segregation of duties, secure device management, vulnerability management, backups and tested recovery procedures.

Privacy laws may apply to driver names, phone numbers, geolocation and delivery recipients. Data retention should be based on legal, operational and analytical requirements rather than indefinite accumulation.

7.3 Operational resilience

A warehouse cannot always stop when connectivity fails. Organisations should define degraded-mode procedures, local transaction buffering, manual fallback, recovery sequencing and reconciliation. Recovery objectives should be explicit:

• Recovery Time Objective (RTO): maximum acceptable time to restore service.
• Recovery Point Objective (RPO): maximum acceptable period of data that may be lost or reconstructed.

These are management requirements, not merely technical settings.

8. Implementation and Performance Management

Implementation should begin with process and data discovery, not software configuration. A disciplined sequence includes current-state mapping, future-state design, master-data profiling, integration specification, configuration, testing, training, pilot operation, cutover and stabilisation.

Testing should cover normal, exception, volume, security, interface, recovery and user-acceptance scenarios. Warehouse testing must include real or representative scans, labels, devices, packaging and physical constraints. Transport testing must include time windows, split shipments, tender rejection, accessorials, tracking gaps and delivery failures.

Relevant WMS measures include receiving accuracy, dock-to-stock time, pick accuracy, order cycle time, inventory accuracy, replenishment response, labour productivity and space utilisation. Relevant TMS measures include transport cost per shipment or unit, tender acceptance, on-time pickup, on-time delivery, empty kilometres, dwell time, freight-audit recovery and emissions.

Metrics require definitions. For example, on-time delivery depends on the agreed promised window, the event used as arrival, treatment of customer-caused delay and treatment of partial delivery. A dashboard without metric governance can create false confidence.

9. Applied Case: NorthStar Consumer Products

The following is an illustrative case based on common industry conditions.

Background

NorthStar Consumer Products distributes personal-care goods from two regional distribution centres to supermarkets and online customers. It operated an ERP system, a basic warehouse application and spreadsheets for carrier rates and route planning. Customer service was declining, inventory records differed between systems and transport invoices frequently required manual review.

Problem

The warehouse released orders without considering carrier cut-off times. The transport planner received shipment information late and often lacked accurate carton dimensions. Carriers were selected using informal preferences rather than current rates and service performance. A product stored under several descriptions caused duplicate item records. Cycle counts revealed repeated discrepancies in fast-moving products.

Analysis

A process review identified four root causes:

1. Item, packaging and customer data lacked common ownership.
2. The warehouse application recorded ordered quantities but not consistently confirmed packed quantities.
3. The TMS did not receive reliable shipment-ready events.
4. Carrier contracts, accessorials and effective dates were not governed centrally.

The organisation also discovered that one “case” was represented as 12 units in one system and 24 units in another. This was not merely a technical defect; it affected inventory, picking, cube, freight rating and customer billing.

Approach and solution

NorthStar established a data council with representatives from operations, procurement, finance, IT and customer service. It created an item and packaging governance process, assigned one owner to each identifier and validated dimensions through physical sampling. The WMS became authoritative for packed quantities and handling-unit identities. The TMS became authoritative for carrier tender, route plan and freight rating.

The integration design introduced a controlled “shipment ready” event containing shipment identifier, packages, weight, cube, destination, service requirement and cut-off information. Carrier rates were versioned by effective date, and accessorial rules were tested against historical invoices. The company piloted the design in one distribution centre before extending it.

Outcome

The principal improvement was not a single algorithm but improved process visibility and data discipline. Transport planning began earlier, warehouse staging aligned with route sequence, and invoice exceptions became explainable. Management could distinguish physical inventory errors from interface delays and carrier performance issues.

Learning points

• Master data is an operational capability, not an administrative afterthought.
• System boundaries must be defined through business ownership.
• A shipment-ready event is valuable only when the WMS confirms physical readiness.
• Rate automation requires versioned contracts and clear billing rules.
• Pilot implementation exposes physical and organisational problems that laboratory testing may miss.

10. Contemporary Developments and Critical Evaluation

Artificial intelligence and advanced analytics are increasingly used for demand forecasting, slotting, anomaly detection, ETA prediction, labour planning and route optimisation. Their value depends on representative historical data, explainable decision rules, monitoring for drift and human accountability. An algorithm may systematically disadvantage a carrier or service region if historical data reflects past bias or incomplete coverage.

Digital twins can combine facility layout, inventory, labour, equipment and transport data to test scenarios before implementation. Internet-of-Things devices provide temperature, shock, location and equipment information. Robotics and automated storage systems require precise item, location, packaging and task data. Blockchain is sometimes proposed for supply-chain traceability, but a shared ledger cannot make an inaccurate physical scan truthful; governance and reliable capture remain primary.

Sustainability functions increasingly calculate transport emissions, packaging waste and energy use. Such calculations require transparent boundaries, activity data and emission factors. Organisations should avoid treating a system-generated sustainability number as inherently accurate without examining its assumptions.

The strategic question is therefore not whether an organisation possesses advanced technology, but whether its processes, data, people and governance can convert technology into reliable decisions.

Chapter Summary

WMS and TMS are complementary logistics execution systems. WMS manages warehouse receipt, storage, inventory, picking, packing and dispatch; TMS manages shipment planning, carrier selection, routing, tracking, settlement and transport analysis. Their integration depends on clear ownership of business objects and reliable events, particularly the transition from warehouse completion to transport execution.

System architecture may be monolithic, modular, service-oriented or best-of-breed, and deployment may be on-premises, hosted, SaaS, hybrid or edge-enabled. The appropriate choice depends on operational, financial, security, scalability and governance requirements.

Master data provides the reusable foundation for execution. WMS requires accurate item, location, inventory and packaging information. TMS requires reliable vehicle, carrier, route, rate and customer data. Data quality includes accuracy, completeness, consistency, timeliness, uniqueness, validity and traceability. Governance assigns ownership, stewardship and technical custody.

Implementation success depends on process design, data cleansing, integration controls, realistic testing, cybersecurity, resilience and agreed performance definitions. AI, automation, visibility platforms and digital twins can enhance logistics, but they do not replace disciplined master-data management or accountable decision-making.

Key Terms

Master data: Reusable information describing business entities such as items, locations, carriers and customers.

Transactional data: Records of business activities such as receipts, picks, shipments and invoices.

Reference data: Controlled codes and permitted values used to standardise transactions.

Warehouse Management System (WMS): Application that directs and records warehouse operations.

Transportation Management System (TMS): Application that plans, executes, monitors and analyses transportation.

Handling unit: A physically managed unit such as a pallet, carton, tote or container.

Put-away: Movement of received goods to an assigned storage location.

Replenishment: Movement of inventory to restore a picking location.

Wave planning: Grouping and releasing warehouse work according to defined criteria.

Tender: An offer of a shipment or load to a carrier.

Accessorial: An additional transport charge for a service or condition beyond the base rate.

Billable distance: Distance defined by the applicable freight-rating rule.

Data owner: Person or function accountable for the meaning, policy and quality of a data object.

Data steward: Person responsible for maintaining data definitions, workflow and quality.

API: Application Programming Interface used for structured system-to-system communication.

Event: A record or notification that a business occurrence has taken place.

Idempotency: Property whereby repeated processing does not create repeated business effects.

RTO: Recovery Time Objective, the maximum acceptable time to restore service.

RPO: Recovery Point Objective, the maximum acceptable period of data loss or reconstruction.

Review Questions

Short Answer Questions

1. What are the principal differences between a WMS and a TMS?
2. Distinguish master data, transactional data and event data.
3. Why is packaging master data important to both warehouse and transport operations?
4. What is the purpose of a shipment-ready event?
5. Define RTO and RPO.

Long Answer Questions

1. Explain the major modules and workflow stages of a WMS from inbound receipt through outbound dispatch.
2. Discuss alternative WMS/TMS architectures and deployment models, including their advantages and limitations.
3. Explain the master-data requirements for a TMS and show how poor data quality affects planning and settlement.
4. Analyse the role of data ownership, stewardship and system authority in integrated logistics.
5. Develop an implementation framework for integrating a WMS and TMS in a regional distribution network.

Analytical / Application Questions

1. A warehouse records a pallet as 48 units in the WMS and 40 units in the ERP. Diagnose the likely governance and process causes, and design a corrective-control sequence.
2. A carrier rejects a load because the TMS plan satisfies weight capacity but exceeds usable cube. Identify the missing or inaccurate master data and propose validation rules.
3. Design an exception-management workflow for a late inbound vehicle that affects warehouse labour, inventory availability and customer delivery commitments.

Multiple Choice Questions with Answers

Question 1

Which system is primarily responsible for directing put-away, picking and inventory movements within a warehouse?

A. WMS

B. TMS

C. CRM

D. Payroll system

Correct Answer: A. WMS

Question 2

In an integrated WMS–TMS process, which event most appropriately signals that physical warehouse preparation is complete?

A. Purchase order created

B. Shipment ready confirmed

C. Carrier invoice received

D. Customer account opened

Correct Answer: B. Shipment ready confirmed

Question 3

Which of the following is master data rather than transactional data?

A. A completed picking task

B. A freight invoice

C. A vehicle equipment profile

D. A delivery scan event

Correct Answer: C. A vehicle equipment profile

Question 4

A case contains 24 eaches. How many eaches are represented by 15 cases?

A. 240 eaches

B. 300 eaches

C. 360 eaches

D. 480 eaches

Correct Answer: C. 360 eaches

Question 5

Which data-quality dimension asks whether a value represents the real physical condition or entity?

A. Accuracy

B. Completeness

C. Uniqueness

D. Timeliness

Correct Answer: A. Accuracy

Question 6

What is the principal purpose of a carrier tender in a TMS?

A. To assign a storage location

B. To offer a shipment to a carrier for acceptance

C. To count warehouse inventory

D. To create a customer invoice

Correct Answer: B. To offer a shipment to a carrier for acceptance

Question 7

Which architecture generally provides specialist applications integrated around shared interfaces and governance?

A. Best-of-breed ecosystem

B. Standalone spreadsheet model

C. Single-user desktop architecture

D. Unconnected batch processing

Correct Answer: A. Best-of-breed ecosystem

Question 8

A freight charge has a base charge of 500, a distance of 120 km, a rate of 4 per km and accessorials of 80. What is the charge under the stated conceptual formula?

A. 680

B. 1,000

C. 1,060

D. 1,080

Correct Answer: D. 1,080

Question 9

Which control prevents a repeated dispatch message from reducing inventory twice?

A. Idempotency

B. Slotting

C. Cross-docking

D. Wave planning

Correct Answer: A. Idempotency

Question 10

Which TMS master-data element is most directly required to calculate a customer’s delivery commitment?

A. Receiving hours and delivery window

B. Employee payroll grade

C. Warehouse paint colour

D. Supplier bank balance

Correct Answer: A. Receiving hours and delivery window