Home GP Modules FreightMaster

FreightMaster

Multi-carrier shipping management system that converts GP Sales Orders into consignments and routes them to SmartFreight (external couriers) or Radaro (internal driver pool).

Source: Freight@Aidacare.docx App Server: AIDASMFR01V Database: HANDR Support: Travis
Note — Legacy Name: FreightMaster is also referred to as SmartFreight within Dynamics GP (a legacy name from when the system only had SmartFreight integration). Radaro was added later. The GP interface still shows "SmartFreight" but the full system is FreightMaster, supporting both SmartFreight and Radaro carriers.
Version
4.0.0
FreightMaster
App & DB Server
AIDASMFR01V
FreightMaster host
Tech Stack
React + NodeJS
SQL Server GP
Carrier Integrations
SmartFreight + Radaro
External & internal delivery
GP Database
HANDR
Consignment staging DB
Support
Travis / Envisage
Application support

System Details

Freight & Logistics
System NameFreightMaster (also called SmartFreight in GP — legacy)
URLhttp://10.26.21.49:8080 (TBC)
App ServerAIDASMFR01V (FreightMaster Installation)
Database ServerAIDASMFR01V
GP DatabaseHANDR (GP SQL Server)
Tech StackReact, NodeJS, SQL Server GP
Version4.0.0
Carrier IntegrationsSmartFreight (SaaS — external couriers), Radaro (SaaS — internal drivers)
GP Entry PointLaunched from GP Sales Transaction window
SupportTravis / Envisage
SmartFreight APITBC — API details not yet confirmed
Radaro APITBC — API details not yet confirmed
SourceFreight@Aidacare.docx

What FreightMaster Does

Logic Layer

FreightMaster is the Logic Layer between Dynamics GP and the two carrier platforms. It does not perform delivery itself — it creates delivery instructions and routes them to the correct carrier. It has four core functions:

Data Translation
Converts complex GP Sales Orders into the simplified "Consignment" format required by SmartFreight and Radaro APIs. Acts as the data transformation bridge.
Carrier Routing
Determines whether a delivery should go to an external courier via SmartFreight, or to Aidacare's internal driver pool via Radaro, based on carrier/shipping method configuration in the order.
Validation
Ensures delivery addresses, phone numbers, and warehouse location codes are present and valid before the consignment is "Imported" to a carrier cloud platform. Prevents failed deliveries caused by bad data.
Centralized Logging
Maintains a single SQL-based audit trail (in the HANDR database) for all outgoing shipments. Every consignment lifecycle event and any API errors are recorded for traceability and troubleshooting.

FreightMaster System Screenshot

System UI
FreightMaster system screenshot

FreightMaster back-office interface — consignment management and carrier routing overview.

Three-Way Integration Architecture

GP → FreightMaster → Carriers

FreightMaster sits at the centre of a three-way integration between Dynamics GP, SmartFreight (external courier SaaS), and Radaro (internal driver SaaS). It monitors GP for triggers, processes and validates orders, then dispatches to the correct carrier.

Data Flow
Dynamics GP
Sales Transaction Entry
→
FreightMaster
AIDASMFR01V — Logic Layer
→
HANDR SQL
ConsignmentRequests staging
→
Carrier Routing
Background service
SmartFreight API
SaaS — external courier agencies
Radaro API
SaaS — internal Aidacare drivers

From GP → FreightMaster

Trigger

FreightMaster is launched directly from the GP Sales Transaction Entry window. The GP add-in DLL (vstcontrols.smartfright.dll) monitors UI events — specifically button clicks and transaction saves — in that window. When a user saves a qualifying Sales Order, the DLL detects the transaction and initiates the hand-off to FreightMaster's SQL stored procedures.

FreightMaster also reads directly from the HANDR GP SQL database, pulling Sales Order details, customer data, and warehouse/location codes needed to build a consignment.

FreightMaster → SmartFreight

External Couriers

When the carrier/shipping method on a Sales Order resolves to an external courier, FreightMaster identifies this and a background service ("The Messenger") picks up the staged consignment record from the HANDR database. It converts the record to a JSON payload and pushes it to the SmartFreight API over HTTPS.

SmartFreight then assigns the delivery to an external courier agency. API details are TBC.

FreightMaster → Radaro

Internal Drivers

When the carrier/shipping method resolves to Aidacare's internal driver pool, FreightMaster pushes the consignment to the Radaro API. The same background service constructs the JSON payload and transmits it over HTTPS to Radaro's cloud platform, where a delivery job is created and assigned to a driver.

Radaro returns a Job ID upon success; this ID is written back into the HANDR database (consignmentNo column) to link the GP order to the Radaro job.

Carrier Response → GP (HANDR)

Write-back

FreightMaster is directly integrated with the GP SQL database (HANDR). After a carrier accepts a consignment and returns a success response, the background service updates the HANDR staging tables: status is set to Imported (3), the carrier's Job ID is recorded in ConsignmentRequestReferences, and the action is logged in ConsignmentRequestHistory.

This creates a closed-loop audit trail entirely within the HANDR database.

Architecture — System Screenshot

Reference
FreightMaster architecture screenshot

FreightMaster architecture — illustrating the integration between Dynamics GP, FreightMaster, SmartFreight, and Radaro.

End-to-End Flow: GP → FreightMaster → Radaro / SmartFreight

6 Steps

The following six steps describe the complete lifecycle of a delivery from the moment a Sales Order is entered in Dynamics GP through to confirmation of delivery job creation in the carrier platform.

1 Origin — Dynamics GP: A user enters a Sales Order in Dynamics GP (Sales Transaction Entry window). Upon saving the order, the GP add-in DLL file (vstcontrols.smartfright.dll) detects the transaction event. This DLL "hooks" into the GP user interface, monitoring button clicks and save events in the Sales Transaction window to trigger FreightMaster logic.
2 Logic Processing — FreightMaster (SmartFreight layer): The DLL calls the smartFreightConsignmentRequestCreate stored procedure in the HANDR database. This stored procedure reads the full Sales Order details from GP's SOP tables, translates the data into the Consignment format, and writes a new record into the ConsignmentRequests staging table with a status of Draft (1). At this point the consignment exists in HANDR but has not yet been sent to any carrier.
3 Validation — API Key & Address Check: The system checks the ConsignmentRadaroApiKeyMappings table to ensure a valid API key exists for the warehouse/location associated with the order. It also validates that the delivery address, phone number, and location codes are present and correctly formatted. If validation fails, the record is marked as Failed (4) and the error is logged in ConsignmentRequestHistory. No carrier API call is made.
4 The Hand-off — Background Service ("The Messenger"): A background service continuously monitors the ConsignmentRequests table for records with Draft status. When it finds one, it converts the consignment record into a JSON payload and dispatches it via HTTPS to the appropriate carrier API — either Radaro or SmartFreight — based on the carrier/shipping method resolved during logic processing. The status is updated to Processing (2) while the API call is in flight.
5 Completion — Carrier Receives Job: The carrier platform (Radaro or SmartFreight) receives the consignment payload, validates it on their end, and creates the delivery job or task. For Radaro, a driver task is created in the Radaro platform and becomes visible to dispatchers in real time. Radaro sends a Success response back to FreightMaster's background service, including the Radaro Job ID.
6 Final Update — HANDR Write-back: Upon receiving the success response, the background service updates the HANDR staging tables: the consignment status is set to Imported (3), the carrier-issued Job ID is written into the consignmentNo column of ConsignmentRequests, and the complete timeline is recorded in ConsignmentRequestHistory. The GP order is now fully linked to the carrier job via ConsignmentRequestReferences.
Consignment Status Lifecycle
1 — Draft
Record created in HANDR
→
2 — Processing
API call in flight
→
3 — Imported
Carrier accepted
4 — Failed
Validation or API error

If a push fails (status 4), the error detail is recorded in ConsignmentRequestHistory. The record must be corrected and re-submitted manually.

End-to-End Flow — Screenshot Reference

Reference
FreightMaster end-to-end flow screenshot

Visual reference for the GP to FreightMaster to Radaro/SmartFreight end-to-end consignment flow.

Legacy Name Context: SmartFreight is one of FreightMaster's two carrier integrations. Because SmartFreight was the original integration (Radaro was added later), Dynamics GP still refers to the whole FreightMaster system as "SmartFreight." This naming convention persists throughout GP interfaces, stored procedures, and DLL filenames.

What is SmartFreight?

SaaS — External Courier
TypeSaaS (cloud-based)
Carrier TypeExternal courier agencies
Delivery ModelThird-party couriers (not Aidacare internal drivers)
API IntegrationTBC — API endpoint and credentials not yet confirmed
Integration ModelFreightMaster pushes JSON payload via HTTPS to SmartFreight API
GP ReferenceCalled "SmartFreight" throughout GP — legacy naming

SmartFreight is a freight management SaaS platform used to dispatch deliveries to external courier agencies. When FreightMaster determines a consignment should go to an external courier (based on the carrier/shipping method on the GP Sales Order), it routes the consignment through the SmartFreight API.

SmartFreight handles carrier selection, label generation, and tracking for these external deliveries, operating entirely in the cloud with no on-premises components at Aidacare's side.

FreightMaster → SmartFreight Integration

Push Model

How the Integration Works

1 GP Sales Order saved with a carrier/shipping method that maps to an external courier — SmartFreight is selected as the target carrier by FreightMaster's routing logic.
2 Consignment record written to ConsignmentRequests in HANDR with status Draft (1) by the smartFreightConsignmentRequestCreate stored procedure.
3 Background service ("The Messenger") detects the Draft record, constructs a JSON payload from the consignment data, and sends it via HTTPS POST to the SmartFreight API.
4 SmartFreight accepts the consignment, assigns it to a courier agency, and returns a carrier ID. Background service updates HANDR: status → Imported (3), carrier ID stored in ConsignmentRequestReferences.
API Details TBC: SmartFreight API endpoint, authentication credentials, and full field mapping are marked as TBC in the source documentation. Confirm with Travis before troubleshooting API-level issues.

SmartFreight Integration — Screenshot Reference

Reference
SmartFreight integration screenshot

SmartFreight integration reference — consignment routing to external courier agencies via the SmartFreight SaaS platform.

What is Radaro?

SaaS — Internal Drivers

Radaro is a cloud-based enterprise logistics and last-mile delivery management platform. Aidacare uses Radaro to manage its internal driver pool — staff drivers who perform deliveries directly rather than using third-party courier agencies. Radaro provides four core capabilities:

Live Driver Tracking
Real-time "Uber-style" map view of all active drivers and their current delivery status. Dispatchers can monitor the entire fleet from a single dashboard.
Customer Notifications
Automatic SMS or email alerts sent to customers with a live tracking link, keeping them informed of their delivery status without manual dispatcher intervention.
Digital Proof of Delivery (POD)
Captures signatures, photos, and GPS timestamps via the Radaro mobile app. Eliminates paper manifests and provides a digital record of every completed delivery.
Route Optimisation
AI-powered delivery sequencing to determine the most efficient delivery path across multiple stops, reducing travel time and fuel costs for Aidacare's driver fleet.
TypeSaaS (cloud-based)
Driver TypeAidacare internal drivers
API DetailsTBC — not yet confirmed

How Radaro Connects to GP

Staging & Sync Model

Radaro does not connect directly to Dynamics GP. FreightMaster acts as the intermediary, using the HANDR database as a staging area. The connection follows a Staging and Sync model:

1 GP writes to HANDR: FreightMaster's stored procedure reads from GP SOP tables and writes a Consignment record to ConsignmentRequests (status: Draft).
2 API Key Validation: ConsignmentRadaroApiKeyMappings is checked to retrieve the correct Radaro API credentials for the dispatching warehouse/location.
3 Background service pushes to Radaro: JSON payload is constructed from the staged record and sent via HTTPS to the Radaro API. Status updates to Processing.
4 Radaro confirms: Radaro creates the driver task and returns a Radaro Job ID. Background service sets status to Imported (3) and records the Job ID in consignmentNo and ConsignmentRequestReferences.
The HANDR database is the single source of truth for all Radaro consignment data. Every action — creation, API push, success, or failure — is recorded in ConsignmentRequestHistory.

Radaro Integration Tables (HANDR Database)

7 Tables
Table Name Role Key Data
ConsignmentRequests Master header table — primary staging table linking GP to Radaro Links GP SOPNUMBE (Sales Order number) to Radaro job details, including consignmentNo (Radaro Job ID)
ConsignmentRadaroApiKeyMappings Stores unique Radaro API credentials per GP Warehouse/Location Per-location API keys and endpoint configuration — used by smartFreightConsignmentRequestSecurity to authenticate each push
ConsignmentRequestStatus Reference table defining the consignment lifecycle states Status codes: 1 = Draft, 3 = Imported, 4 = Failed
ConsignmentRequestHistory Audit log tracking every status change, API response, and timestamp Full timeline of events including API error messages when a push fails — primary troubleshooting table
ConsignmentRequestReferences Cross-reference table between GP and Radaro external identifiers Maps internal GP Order Numbers to external Radaro Job IDs and carrier reference numbers
ConsignmentRequestRadaroLabels Metadata tags to categorise and identify jobs within the Radaro dashboard Label metadata applied to Radaro jobs — supports filtering and categorisation in the Radaro platform
ConsignmentRequestRadaroDriverSkills Maps specific driver capability requirements to delivery jobs Driver skill tags (e.g., "Heavy Lift", "Specialist Equipment") — ensures correct driver type is assigned to specialist deliveries

Radaro Stored Procedures (HANDR)

2 Procedures
smartFreightConsignmentRequestCreate

The main engine stored procedure for creating new delivery requests. Gathers all relevant data from GP's SOP (Sales Order Processing) tables, translates it into the consignment format, and populates the ConsignmentRequests staging table. This is the first stored procedure called when a GP Sales Order triggers FreightMaster.

smartFreightConsignmentRequestSecurity

Handles authentication logic for the Radaro API. Validates the API keys stored in ConsignmentRadaroApiKeyMappings for the specific warehouse/location code on the consignment, ensuring the correct credentials are used before any data is transmitted to the Radaro cloud. Prevents unauthorised API calls and cross-location credential mismatches.

Radaro Platform — Screenshot Reference

Reference
Radaro platform screenshot

Radaro last-mile delivery management platform — driver dispatch, live tracking, and delivery job management.

HANDR Database — Consignment Tables

4 Core Tables
Table Name Description Lifecycle Role Key Columns / Notes
ConsignmentRequests Primary staging table where GP Sales Order data is stored after being "logicalized" by FreightMaster. This is the master record for every consignment. Created when a GP Sales Order is submitted to FreightMaster. Exists throughout the full lifecycle. consignmentNo — stores the carrier-issued Job ID (Radaro or SmartFreight) after successful push. Links to GP SOPNUMBE.
ConsignmentRequestStatus Reference / lookup table that defines all valid lifecycle states for a consignment. Controls what status transitions are valid. Tracks current status of each consignment throughout its lifecycle: Draft → Processing → Imported (or Failed). Status codes: 1 = Draft, 2 = Processing, 3 = Imported, 4 = Failed
ConsignmentRequestHistory Append-only audit log that records a timestamped entry for every action taken on a consignment — status changes, API calls, success responses, and error messages. Audit trail and error diagnostics. First place to check when a consignment fails or is stuck. Contains full API error messages when a push to Radaro or SmartFreight fails. Essential for troubleshooting.
ConsignmentRequestReferences Cross-reference mapping table that links internal GP Order Numbers to external carrier-assigned IDs from Radaro or SmartFreight. Post-import — used for tracking, reconciliation, and linking carrier events back to the originating GP order. Maps GP SOPNUMBE to Radaro Job IDs and SmartFreight Carrier IDs. Used to look up delivery status in carrier portals.

Stored Procedures (HANDR Database)

2 Procedures

Both stored procedures reside in the HANDR database and form the SQL-side core of FreightMaster's GP integration. They are called by the GP DLL add-in and by FreightMaster's NodeJS application layer.

smartFreightConsignmentRequestCreate Main Engine

The primary stored procedure that drives consignment creation. When triggered by the GP DLL add-in, it:

  • Reads Sales Order header and line data from GP's SOP tables in HANDR (SOP10100, SOP10200)
  • Translates the complex GP order structure into the simplified Consignment format
  • Validates required fields (address, phone, location code)
  • Inserts a new record into ConsignmentRequests with status Draft (1)
  • Records the creation event in ConsignmentRequestHistory

This stored procedure is the "insert new delivery request" entry point — it does not push to any carrier API. That is handled by the background service.

smartFreightConsignmentRequestSecurity Authentication

Handles all authentication logic for carrier API connections. Before any consignment data is transmitted to Radaro or SmartFreight, this procedure:

  • Looks up ConsignmentRadaroApiKeyMappings using the warehouse/location code from the consignment
  • Retrieves the correct API key for that specific location
  • Validates that the API key is present and correctly formatted
  • Ensures the correct credentials are passed to the carrier API — prevents cross-location authentication errors

This procedure is the security gate — if it fails (e.g., missing or expired API key), the consignment is not transmitted and the error is logged in ConsignmentRequestHistory.

GP Add-in Logic File — vstcontrols.smartfright.dll

GP Addins Folder
Compiled DLL: This file is a compiled binary. Exact GP field mappings and internal logic cannot be verified without the source code. Obtain source code or mapping documentation from Envisage if detailed inspection is required.

File Details

Filenamevstcontrols.smartfright.dll
LocationGP Addins folder on the GP client / server
TypeCompiled .NET DLL — GP Add-in
Note on NameFilename uses "smartfright" (one 'e') — legacy name, predates Radaro
Source CodeTBD — obtain from Envisage

Role & Behaviour

  • Hooks into the GP UI: Registers event listeners against the Dynamics GP Sales Transaction Entry window
  • Monitors UI events: Watches for button clicks (e.g., Save, Post) within the Sales Transaction window
  • Triggers FreightMaster logic: On the qualifying event, calls smartFreightConsignmentRequestCreate stored procedure in HANDR
  • Bridge role: Acts as the hand-off mechanism between the GP window and the FreightMaster SQL layer — the human-to-machine trigger point
  • No carrier calls: The DLL itself does not push to SmartFreight or Radaro APIs — that is the background service's responsibility

Full Table Reference — Radaro Integration (HANDR)

7 Tables
Table Name Purpose
ConsignmentRequests Master header table. Links GP SOPNUMBE to Radaro job details. Contains consignmentNo (Radaro Job ID written back after successful push).
ConsignmentRadaroApiKeyMappings Stores unique Radaro API credentials for each GP Warehouse/Location code. Used by the security stored procedure to authenticate each API call correctly.
ConsignmentRequestStatus Lifecycle state reference. Values: 1 = Draft, 3 = Imported, 4 = Failed. Controls valid state transitions for every consignment record.
ConsignmentRequestHistory Append-only audit log. Every status change, API call, success message, and error message is timestamped here. Primary table for troubleshooting failed consignments.
ConsignmentRequestReferences Cross-reference between GP internal order numbers and external Radaro Job IDs / carrier reference numbers. Used for tracking and reconciliation.
ConsignmentRequestRadaroLabels Metadata label tags applied to Radaro jobs. Allows jobs to be categorised, filtered, and identified within the Radaro dispatcher dashboard.
ConsignmentRequestRadaroDriverSkills Maps specific driver capability requirements to consignment jobs — e.g., "Heavy Lift", "Specialist Equipment handling". Ensures the correct driver type is assigned in Radaro.