Address verification, carrier integration, rate selection, label printing, shipping tracking, and ship confirmation are all essential components of D365 automation.
Address verification, carrier integration, rate selection, label printing, shipping tracking, and ship confirmation are all essential components of D365 automation.
Not necessarily. Rate shopping on the sales order was described as informational, because the actual shipment may be split across multiple containers and the real packed weight/size can differ. The accurate rating happens at packing/container level using what’s actually packed.
Rates come directly from the carrier API (DHL Express as an example), using your negotiated carrier pricing. The system sends address + weight/size and receives carrier/service options and prices back.
It’s primarily driven by Mode of delivery and the account scenario (shipper-paid vs customer/receiver-paid). Controlling carrier/account details via the Customer master.
On the Customer master, under a carrier account section. You can store different account codes per different delivery locations/addresses for the same customer.
You will receive an exception (because the system expects the receiver/customer account when that scenario is chosen).
Yes — entering this manually on the sales order when the info comes “on the fly” (e.g., third-party shipping address/account).
Yes. The label is stored and can be reprinted from Dynamics (using a reprint action; it may print to a configured/virtual printer).
No — reprint is a true reprint (not generating a new waybill/tracking).
Not directly. If a label already exists, you must refund/void the label first. Only after the label is voided can the container be reopened/changed.
Data integrity and compliance: once a label is created, the carrier has received declared contents/weight, and for international shipping the commercial invoice/manifest must match. If the box contents change, those documents must be regenerated.
It depends on the carrier: typically this is possible until the carrier accepts/picks up/scans the package (carrier rules apply).
Configurable. The ability to void/refund was not strictly blocked by confirmation, but it can be configured to prevent refunds after confirmation if that’s your process requirement.
Yes. The standard packing behavior: it reads per-item weights from product master, multiplies by quantities, sums them, and adds container tare weight if defined in container definitions.
This is a real-world issue (weights can vary by vendor/brand/packaging). That’s why scale integration is supported.
A small scale gateway app runs on the packing station. The system reads the actual scale weight and can use it instead of system weight. Optional variance checks (example: checking for large % differences).
Yes if the carrier supports it. The “master tracking” concept: you can hold labels and send multiple container details together to receive a single tracking number (carrier-dependent). Some carriers generate tracking per container; others provide a master shipment number.
The tracking is stored on the container, and also copied to the shipment and packing slip (one-to-many). If there are multiple containers, you can see multiple tracking numbers on the packing slip/order without opening each container.
Yes — Warehouse shipments → Transportation → View containers, where the tracking number appears per container (and there’s an option like “show shipped containers” depending on status).
Delivery proof/status was handled via standard Dynamics document attachments. When the carrier sends a delivery email, the system can capture it and attach it to the shipment as an email file. It’s stored wherever your Dynamics attachments are stored (not a separate system).
Yes. Setting up notification templates and a batch job that periodically checks carrier status via API. When it detects a status change (e.g., delivered), it sends the configured email notification.
This is outside the core carrier-integration scope. It can be done as a project/custom enhancement, but not treated as standard product scope. It is more Dynamics implementation scope.
Wir setzen Cookies ein, um den Website-Traffic zu analysieren und dein Nutzererlebnis für diese Website zu optimieren. Wenn du Cookies akzeptierst, werden deine Daten mit denen anderer Nutzer zusammengeführt.