MercuryGate Implementations

1
MercuryGate Implementations

• Systems Integration Overview

2
Systems Integration

• MercuryGate transmits and accepts electronic data
  in standard and custom formats
• Data is exchanged between shippers, 3PLs,
  carriers, suppliers, and any other business
  integration partner
• MercuryGate provides a high-volume data
  integration architecture
• gt 60,000 inbound transactions per day

3
Inbound (to MG) Data

• Master Data
• Enterprises (Companies)
• Locations
• Carriers
• Master Items, Ship Units
• Containers
• Transaction Data
• Orders
• Shipments
• Loads
• Invoices
• Checks
• Status Messages
• Tender Info

4
Outbound (from MG) Data

• Master Data
• Enterprises (companies)
• Locations
• Carriers
• Transaction Data
• Shipments
• Loads
• Invoices / Accounting Data
• Status
• Tender info

5
Data Formats

• XML
• Default MG XML is preferred format
• EDI
• Mainly versions 4010, 4030
• 204, 210, 214, 856, 990, 997, etc.
• Custom versions for specific companies, carriers
  (Example Pepsi (shipper), CSX (rail carrier)
• CSV specific inbound types (Shipment, Check,
  Credit Limit, Location)
• SAP BAPI and IDoc
• EDIFACT Cargo Imp, INTRRA
• Custom as needed

6
Data Transmissions

• Variety of data transmission alternatives are
  available, customer chooses
• FTP
• Preferred format we can push to customer server
  or customer can pull from our server
• Secure FTP available FTP/SSL, FTP/SSH
  with/without client key
• IBM MQ series
• Web Service / SOAP transmission
• VPN

7
Inbound Loading Architecture

• For all format and transmission types
• Data is routed by communications server to
  customers production server
• Production server maintains queue of files
  waiting to load
• Batch process kicks off loaders according to
  schedule
• Results of loading are available for viewing on
  server and/or transmitted back to customer system

8
Extract Architecture

• Extracts in all formats are triggered in multiple
  different ways in the TMS
• Manual execution for list/detail screens
• Automated based on process changes / completion
  (code-defined rule sets)
• Automated based on data changes (user configured
  notifications)
• Customers extract format is configured in the
  system via codes tables

9
Best Practices

• Identify system of record
• Avoid 2-way data replication
• Spend adequate time to on requirements for
  changes (updates, cancels, etc.)
• Automate after process is validated
• Automation of incorrect process creates a large
  volume of bad data
• Use existing technical skills
• Avoid switching to a new format / building skills
  in a new area (e.g. XML)

10
Implementation Process