Factory Inbound Appointment System: Dock Booking and ERP Integration Guide

When considering implementing a factory inbound delivery appointment system, comparing only the reservation interface does not determine the effectiveness of operations. Purchase orders (PO), supplier shipping schedules (ASN: Advance Shipping Notice), truck arrivals, dock/bay assignments, physical receipt, and posting of product receipts to ERP—all are distinct events. This article organizes a practical design applicable to factories in Thailand, clarifying which system finalizes what, and how to handle delays, quantity discrepancies, and unreserved deliveries. Items to include in your RFP (Request For Proposal), from key requirements to FAT (Factory Acceptance Test) and SAT (Site Acceptance Test) sample cases, are summarized here for pre-implementation validation.

Define the Business Issues Addressed by the Factory Inbound Delivery Appointment System

What the appointment system first manages is not the cargo itself but the “agreement of when, which vehicle will deliver which goods, to which receiving location.” Onsite reception, vehicle waiting areas, unloading, manpower allocation, and inspection preparation are all aligned to this agreement. Normally, the purchase order’s authoritative record lies in the ERP, and the record of actually received quantities or lots is contained in the WMS (Warehouse Management System) or ERP. Importantly, merely confirming a reservation must not reduce open purchase order balances or inventory.

SAP’s Dock Appointment Scheduling, for example, is described as a feature for planning vehicle arrivals and dock operations, providing visibility of bay workload per day. Oracle warehouse management documents also distinguish the phases of reservation date/time, actual arrival, dock check-in, and ASN-supported receipt. Stating these distinctions clearly in your RFP helps avoid vendors designing systems where “reservation complete = goods received.”

When defining your scope, it is safest not to mix raw materials, packaging materials, MRO parts, molds, and finished goods returns in one system process. That’s because cargo handling time, vehicle constraints, need for inspection, and how you reconcile with your POs differ. For your initial scope, decide something like “truck deliveries of raw materials based on standard purchase orders” and explicitly list out exceptions like direct shipments, hazardous materials, refrigerated goods, or urgent components. This isn’t about discarding functionality but about clarifying the gate criteria for the first stage of receipt.

Why Separate Reservation, Arrival, and Receipt

Even if a supplier reserves a morning slot, trucks can arrive late. Even when a truck arrives, receiving may be partial due to mismatched PO numbers, missing items, unreadable labels, etc. Even after receipt is registered, quality inspection or ERP product receipt posting may occur much later. Microsoft documentation likewise distinguishes between ASN-based pre-registration, dock registration, and posting of actual product receipt. Therefore, each stage should independently register its timestamp, responsible person, quantity, and status.

The Relationship of PO, ASN, Delivery Appointment, and Actual Receipt

A PO governs order terms; the ASN is the supplier’s notification of what will actually ship; the delivery appointment is the time slot for vehicle and unloading resources; the actual receipt is the verified result on-site. The GS1 Logistics Interoperability Model likewise treats despatch notification and receipt notification as different transactions; the latter communicates discrepancies between the advised shipment and the actual receipt. While an inbound appointment system may show all of them on one screen, their distinct underlying data and meaning must not be merged or erased.

A single PO may be delivered in multiple installments; a single truck may contain items from multiple POs. Therefore, avoid a system design where “reservation number = PO number” (one-to-one mapping). Separate the reservation header from related ASN and PO lines, recording both planned and actual quantities line by line. Microsoft’s loading management documentation, for example, also explains how one “load” can relate to multiple PO order lines. After understanding your contract units and packaging methods, illustrate the relationship between appointment, vehicle, ASN, PO lines, and goods receipt lines before deciding APIs.

When to Reconcile with Open Purchase Orders

When creating a reservation, you can issue warnings such as “Does a valid PO exist?”, “Are the supplier and delivery location matching?”, “Does the planned quantity greatly exceed the open PO balance?” However, changes to POs can occur after the appointment is made, meaning these checks cannot remain permanently valid. The system design should enable reconciling PO status at key points: on reservation finalization, on ASN receipt, at gate check-in, and at final goods receipt. The treatment for failed matches should differ; for example, invalid POs may be put on hold, over-quantities may await supervisor approval, and date discrepancies may just raise a warning—these rules should reflect joint purchasing and logistics agreement.

For more detail on managing open purchase orders, see Open Purchase Order Balance Management and Delivery Schedule Matching. Appointment booking is a gateway to reference open POs, but whether to grant the authority to alter POs through the reservation screen is a separate matter.

How to Structure Dock Appointment Slots for Factory Bays

Simple slots such as “one truck per hour” cannot account for variation in packaging and operation time. The master data should include the number of bays, available times, vehicle dimensions, forklift availability, unloading method, inspection effort, and safety constraints. Slot duration need not be fixed; you may compute estimates based on number of ASN lines or pallets, and allow supervisors to adjust. However, any auto-estimation formula must be tuned with real shop floor data, with both predictions and results logged for improvement.

For example, even if raw material and finished goods docks are technically the same, if handling paths or entry permits differ, they cannot be regarded as interchangeable. Other constraints such as hazardous materials, temperature-controlled items, mixed loads, or recovery of returnable containers should be modeled separately. For priority vehicle overrides, track who made the change and why. It is more important to be able to explain why certain slots are not presented (per constraints) than to focus only on calendar views.

SAP documentation refers to reservation statuses such as “tentative,” “planned,” “checkpoint arrived,” “dock arrived,” and “dock departed.” You do not need to use the exact same names, but at minimum, record distinct events (with timestamps) for reservation confirmation, gate arrival, dock arrival, unloading completion, and exit, to prevent confusion between waiting and unloading times. Slot availability should be refreshed based on actual prior job completion and post-job cleaning/safety checks, not just scheduled times.

Determining Slot Units and Capacity

Deciding whether reservations are made by “vehicle,” “shipment,” “ASN,” or “PO” depends on your on-site operation. If several POs are delivered in one truck, make “vehicle” or “shipment” the reservation header, with multiple POs as line items. If large POs are split across multiple vehicles, allow separate reservations for each. Where cargo is reassigned to multiple docks after entry, consider associating a single reservation with multiple dock events. If this design is vague, even reservation counts will not reflect actual vehicle queues.

To prevent overbooking, establish expiration times for provisional holds, and avoid double-selling the same capacity during “pending approval.” If reservations come from multiple systems at once, use identical consistency logic for available slot displays and confirmations. Deduplicate requests using request IDs so that retry transmission does not result in duplicate reservations. This is an API design issue, but suppliers should see on their screen whether the appointment is “confirmed,” “pending confirmation,” or “not approved.”

Supplier Appointment Entry Fields and Responsibilities

Requesting too many fields from suppliers can drive them back to making reservations by phone or email. At minimum, require supplier, delivery location, preferred date/time, vehicle or carrier, PO or ASN reference, estimated cargo volume, and contact info. Where possible, autofill from PO or ASN to avoid re-entry, and if changes are made, request a reason. Limit collection of driver personal data to what is needed for site entry, and define data retention and access periods.

Responsibility assignment should be visible on the interface: suppliers submit shipping and vehicle info, factory logistics confirms slot and dock compatibility, Purchasing rules on PO validity or quantity changes, Warehouse handles physical counting, and Quality handles inspection holds. Clearly split conditions for auto-approval and manual checks, and ensure emergency deliveries are possible even when the approver is absent. Do not rely only on email notifications—ensure the latest information is always visible on-screen.

Combined Use of Email, EDI, and Portal

Major suppliers may require EDI or API connectivity; smaller suppliers may use portal entry; ad-hoc shipments may be factory-registered. Regardless of entry route, ensure all arrivals converge to a common reservation ID and state transitions. Whether to strictly refuse unannounced (no ASN) arrivals, or generate provisional ASNs, depends on your products and contracts. Oracle documentation, for example, shows matching appointments with ASNs, assigning docks post-check-in, and handling ASN-based receiving. For your own operation, define who can approve unscheduled deliveries and by when follow-up data must be entered.

Consider entry field translation as well. If Japanese-speaking buyers, Thai-speaking gate staff, and English-speaking overseas suppliers all use the system at a Thai factory, headlines alone aren’t enough—cover date/time formats, time zones, phone numbers, vehicle plate formats, units, warning texts, and dropdown options for change reasons. Dates must be fixed to a time zone on entry and stored in APIs with full timezone info. Test to ensure that the appointment time does not change depending on language or screen settings.

Establish Rules for Delays, Early Arrivals, and Rebooking in Advance

When carriers advise of delays, you must not simply overwrite the original reservation time; otherwise, evidence of both the original commitment and the delay is lost. Retain the original slot, revised slot, timestamp of advisory, reason, and approver, all in the audit trail. Set different approval and reallocation rules for rebookings before departure, delay notices en route, and in-gate sequence changes. If reallocation pushes back another vehicle, notify the affected party and log the exception reason.

Sources of delay notifications include carrier self-report, location tracking/GPS, and actual check-in at the gate. Even with location data, ETA updates are still predictions, not physical arrival. Even if ETA recalculations are automated, do not automatically reassign dock slots. Gate staff should see original slot, current allocation, arrival order, and hold reasons all on one screen, and the reason for any manual overriding should be recorded. For vehicles arriving with no reservation, do not retroactively reclassify as “reserved”; explicitly track as ad-hoc entries.

No-Shows and Cancellations

Do not immediately mark as canceled any vehicle that misses its slot; set clear rules for grace periods and conditions for reassignment. Distinguish between “no-show candidate” (after missed slot but before confirmation) and “no-show confirmed,” to avoid mistakes due to communication failures or gate congestion. If the same cargo is rebooked after cancellation, reference the original appointment ID to ensure one delivery does not count as two reservations in statistics. KPIs must define their denominators: for example, “of confirmed reservations, how many…”

Dock Assignment and Onsite Reception Workflow

Onsite, match not only the reservation number, but also the vehicle number, supplier, ASN, PO, and packaging. Gate entry decision and actual dock arrival are separate events. If the gate receives POs not in the reservation, logistics evaluates acceptability and, if purchasing or warehouse approvals are required, places the transaction on hold. Mixed loads from different suppliers should allow one vehicle to carry multiple shipper records and separately process goods receipt results by line.

After dock arrival, record safety checks, unloading start, unloading completion, goods counting, and dock exit. In some operations, the dock can be released once unloading is finished, even if goods counting continues. Conversely, some require the vehicle to remain until quality inspection is complete. Do not cram all these steps into one generic “goods receipt complete” button, but divide events in line with your safety and quality rules. Include requirements for offline data capture on field devices and measures to prevent duplicate registrations upon network restoration in your RFP.

For warehouse operations after goods receipt, see the related article Warehouse Inbound/Outbound Management and Inventory Integration. If you collapse all steps from dock booking to shelf placement into a single “complete” state, it becomes impossible to analyze where delays occur. Instead, separate event times for dock arrival, goods counting, quality check, and put-away.

Boundaries to Observe in Integrating Appointment, Inbound Plan, and Goods Receipt

Define at the outset what data should flow from the appointment system to ERP. Normally, planned inbound data is displayed to purchasing and production planning, while the actual result is confirmed through WMS or ERP goods receipt functions. Canceled appointments should not automatically close POs; nor should you post a zero received quantity just because a bay is suddenly free. Conversely, if the received quantity is short, provide Purchase with both reason codes for the difference and the remaining quantity management.

Microsoft WMS documentation illustrates registering actual delivered quantities by load, then posting product receipt to inventory and accounting. In any system linking appointments and ERP, you must agree operationally and contractually on which events constitute “physical arrival,” “counted,” “posted to inventory,” and “available for invoice matching.” The business state names and timing will differ by ERP product, so never assume equal semantics purely based on vendor terminology.

Mapping IDs, Units, and Statuses

At minimum, interface keys should include appointment ID, supplier ID, delivery location, PO number and line, ASN number and line, item code, packaging type, quantity unit, and vehicle or shipment ID. For items requiring lot or serial numbers, those attributes should be included as well. Confirm whether the ERP’s PO lines allow partial deliveries, whether supplier item codes differ from internal codes, and whether unit conversions are necessary. If boxes and pieces, or kg and bags, are mixed or compared directly, discrepancy alerts are rendered useless; define the system of record for conversion factors and rounding logic.

Select states such as “created,” “applied,” “confirmed,” “rebooking applied,” “arrived,” “at dock,” “unloading complete,” “partial receipt,” “receipt complete,” and “canceled,” and then reduce as fits your operation. More important than naming is clarifying which roles, under what conditions, may progress to each next state. Support for reverting steps should log all history, and the system must prevent double receipt posting even if duplicate notifications arrive, by tracking event IDs and results. If ERP integration fails, differentiate between “awaiting resend” and “business-side completed,” and indicate on-screen which system holds the latest data.

Handling Discrepancies and Holds

Do not lump together shortage, overage, wrong item, damaged goods, mismatched lots, quality holds, and missing paperwork as generic “errors.” Warnings at the reservation phase, holds at gate check-in, receipt discrepancies after unloading, and quality holds each have distinct responsibles and next steps. If attaching photos or paperwork, specify storage locations, access rights, and reference methods for ERP. Explicitly define whether the appointment system’s scope includes processing returns or managing re-deliveries to suppliers.

Requirements to Compare in an RFP

During product demos, everything appears to work smoothly under ideal conditions. However, after implementation, what becomes burdensome are delays, mixed shipments, partial deliveries, PO changes, ASN inconsistencies, and communication breakdowns. Before listing out all the screens in your RFP, clarify on-site scenarios and pass/fail requirements. Rather than simply stating “being able to make reservations,” describe “which conditions allow reservations, who views and decides during exceptions”—this enables you to compare vendor proposals more effectively.

Do not compare price quotes by just initial implementation costs. Verify and separate support for supplier registration, EDI connection, ERP modification, gate terminal, training, operational monitoring, and version upgrade support. Ask about price components—such as what changes costs (number of reservations, locations, users, API usage). For cloud use, confirm data storage location, permissions, audit logs, backup, and alternative reception in the event of failures. Avoid assuming features from a specific product—evaluate how each proposal matches your real business scenarios.

Example Acceptance Criteria to Write in Your Requirements

You can’t properly test requirements like “Suppliers can select a PO and desired time slot.” Instead, write scenarios such as: “A user can select a valid PO line and add multiple PO lines to the same truck delivery. Unavailable dock slots are excluded from the options. A unique reservation ID is issued upon confirmation; duplicate transmissions do not create additional reservations.” For quality holds: “If an item is flagged for inspection at reception, inventory staff can record received quantity, but stock is not moved to available inventory before designated approval.” This indicates integration partners and responsibility as well.

Include not only the standard flow in your acceptance criteria, but cases like insufficient privileges, missing required fields, duplicates, reapplications after cancellation, API downtime, time zone differences, and unit discrepancies. Base system performance criteria on your own peak transaction volume and concurrent operations, avoiding arbitrary second-counts in your RFP. Go beyond just screen response time—measure the time from reservation confirmation through notification to suppliers and ERP reflection, to uncover operational delays.

Dividing Factory Inbound Appointment Testing: RFP, FAT, SAT

In FAT (Factory Acceptance Test), the configured system is verified in a test environment to ensure that contracted features and integration specifications work as agreed. SAT (Site Acceptance Test) uses the actual factory gate, dock, devices, network, staff, and ERP/WMS connections to confirm that procedures are functional in real operations. Terminology may vary by contract, so your RFP should define “who, in what environment, using what data, will approve what as passing.” A screen that passes FAT may still not be able to read real vehicle numbers or labels at your facility; thus, pass/fail is judged separately in FAT and SAT.

Test data should use anonymized cases similar to real operations: splitting a PO across two shipments, two POs in one shipment, ASN and actual receipt discrepancies, truck arriving after reservation cancellation, ERP temporarily down, and so on. Only using vendor sample data can miss unit conversions or item code differences. Record not only “success,” but also screen status, notification recipients, audit logs, ERP results, and the state after reprocessing.

Pass/Fail Criteria and Outstanding Items

Document pass/fail results per item, including input, operation, expected result, evidence, and approver—never just “it worked fine.” For example, “If the same ASN arrival event is sent twice, only one acceptance record is kept, and the second is logged as duplicate” is a reproducible test. For critical issues, establish interim procedures, responsible staff, deadlines, and retest criteria. Where manual workarounds are proposed, accept only after evaluating processing load and scope of responsibility.

End users must participate in SAT: security, logistics, warehouse, procurement, quality, IT, and main supplier representatives should at least confirm their own workflows. Check that approval notifications are received, that screens make sense in Thai/English, and that devices can identify vehicles and cargo. Note any user confusion or ambiguity without referring to manuals—and decide whether to resolve by training, screen tweaks, or permissions.

Implementation Sequence and Migration Planning

Start by observing current receipt operations: record arrival times per shipment, reasons for waiting, unloading durations, quantity variances, and intake routes. Through supplier interviews, confirm shipment release timing and the granularity at which they can provide ASN. Next, establish the data relationships, state flows, and role definitions for PO, ASN, appointment, and receipt. If you develop screens before this foundation, ERP boundaries can later become unclear.

For initial rollout, scope is limited to certain gates, docks, suppliers, and items, running parallel with current paper or phone procedures for a period. To prevent double entry from persisting, designate which record is authoritative each day. Track not just reservation rates, but also on-time arrival, gate and dock waiting, unloading time, differences between planned and actual quantities, and ERP reflection failures. The improvement goal is not just to show better numbers, but to identify and address specific causes of delay.

After go-live, periodically review the supplier onboarding burden and actual practices on-site. More required fields do not necessarily improve data quality; if much of the input is proxy-registered, either streamline fields or add more integration methods. For chronic delays, look beyond slot length to local traffic, loading/unloading setups, and inspection flows. If you see many receipt differences, examine ASN creation timing and PO change notification processes.

Data Preparation and Switch-over Judgement During Implementation

The initial master data for your reservation system should include: supplier, delivery location, gate, dock, operating days, vehicle type, item category, and handling conditions. Assign a managing department and update frequency for each. For example, if supplier codes differ between ERP and the reservation system, prepare a mapping table rather than relying on matching name strings. Reflect dock closures and facility inspections before publishing time slots. When migrating open appointments from old systems or spreadsheets, document the base date for migration, how to handle cancellations, and the correspondence between old and new reservation IDs.

On the switch-over day, the site must be able to determine for each in-progress reservation which system confirmed it. To prevent duplicate slot bookings by suppliers resubmitting migrated reservations, align both pre- and post-switch notifications and reception procedures. On day one, place a point of contact at the gate and with logistics, and prepare manual or alternate forms for issues such as unavailable reservation search, vehicle number changes, missing ASN, and ERP connection outages. Practice inputting alternate records in the right order and eliminating duplicates on recovery.

A go-live is only valid after verifying: supplier onboarding completion, reconciliation of open reservations, major exception handling in SAT, ERP/WMS send/receive and resend capability, on-site staff training, and alternative reception in case of failures. For any outstanding issues, record business impacts, interim countermeasures, responsible personnel, and deadlines—along with who authorized the go-live. This way, you won’t overlook situations where slot reservation rates rise, only for other manual workarounds to spike in the field.

Frequently Asked Questions

Can a factory inbound appointment system be implemented using only ERP?

If your ERP has delivery planning or appointment features, you may start without an additional system. However, verify whether suppliers can select time slots, if dock constraints are supported, if gate arrivals and receipt results are distinguished, and if you can track rebooking after delays. Rather than trusting product names, test with your own scenarios.

Is a factory dock (bay) appointment system the same as a WMS?

There can be overlapping areas; however, appointments are about planning future vehicles and loading/unloading resources, while WMS focuses on the actual receipt and internal warehouse processes. For example, Oracle and SAP documentation both demonstrate appointment and dock/receipt integration. Even if you use both in the same product, schedule and actual records should be managed separately.

Is ASN mandatory for suppliers’ delivery appointments?

There is no universal answer. ASN allows for pre-matching of intended delivery details—but not all suppliers can send ASN. Decide, per item and risk, whether to allow provisional appointments by PO reference alone, or to have the plant register on behalf of suppliers. Also, define what information is required and who is responsible for supplementing it before final acceptance.

What is most critical in integrating inbound schedules and actual receipts?

Never use one event to confirm reservation, arrival, physical verification, and inventory posting at once. Test what happens if scheduled and received quantities differ, duplicate events occur, ERP is down and has to resend, and with cancellation/rebooking histories. In your specifications, declare which system’s record is authoritative for each data point.

What are the minimum inclusions for RFP, FAT, SAT?

RFPs must specify data relationships, roles, state transitions, exceptions, integrations, and pass/fail criteria. FAT validates both standard and exception functionality and APIs; SAT checks end-to-end intake at your actual gates, docks, devices, users, and ERP connection. Get agreement on evidence from testing, and how to handle unresolved issues.

Conclusion

A factory inbound appointment system coordinates scheduling of vehicles and loading/unloading resources. PO is a purchase agreement, ASN is a shipment notice, and goods receipt is the physical result—each clearly owned and connected. Success in implementation depends less on fancy slot displays, and more on whether you can keep operations going during split deliveries, mixed shipments, delays, quantity variances, quality holds, and ERP outages. Write out exceptions and acceptance criteria in your RFP, verify features in FAT, and validate plant-floor workflows in SAT.

If you’d like to discuss inbound appointment or ERP/WMS integration for your Thai factory—even at the stage of organizing your current intake flow and exceptions—please contact TOMAS TECH with your locations and troublesome receipt scenarios.

References

• GS1 Logistics Interoperability Model Application Standard: Despatch and receipt notification transactions, including discrepancies between expected and actual goods.
• SAP Dock Appointment Scheduling: Explanation of vehicle arrival, handling schedules, dock capacity.
• SAP Yard Logistics: Dock Appointment Scheduling: Appointment status and check-in conditions.
• Oracle Warehouse Management: Creating Appointments: Reservation, arrivals, dock assignment, ASN receipt operations.
• Microsoft Learn: Warehouse handling of inbound loads: Load creation, registration, and product receipt posting from PO/ASN.
• Microsoft Learn: Product receipt against purchase orders: ASN pre-registration, physical registration, and distinctions in product receipt.