Configuration and Administration Requirements

In a ShipHawk - ERP integration, an administrator must be able to do the following:

1 1. Ease of integration
2 2. Mappings Configuration
3 3. Webhook Configuration
4 4. Logs for Testing and Debugging

1. Ease of integration

An administrator must be able to easily set up the integration between the order source (ERP) and ShipHawk.

A developer should not be required in order to set up the integration.
If any tasks are needed, they must be fully documented as part of the integration.
Additionally, the administrator must be able to change their ShipHawk API key and ShipHawk hostname when needed.

Here is a screenshot of part of the ShipHawk settings page on NetSuite:

Here is a screen of one of the ShipHawk configuration pages in Acumatica:

2. Mappings Configuration

An administrator must be able to set up and easily change mappings for several different fields. There MUST be a UI for an admin to change these without custom development.

Order reference number mappings. Reference numbers in ShipHawk are used to bring custom data into ShipHawk for use on shipping documentation or on the ShipHawk Rules Engine. An administrator must be able to map at least 30 fields in the syncing entity (the ERP) to reference numbers in ShipHawk.

Customers have used these mappings for the following use cases:

To put store number information on carton labels to meet EDI requirements, customers have mapped store numbers and additional customer information
To tell ShipHawk to rate shop rates that will arrive within _ number of days, customers have mapped a custom service days field
To create customer specific rules, customers have mapped fields denoting the customer processing the shipment

Additionally, the administrator should be able to map information from the customer record, order record, shipment record, and any other important sources of data that pertains to the order object.

Here are the Order Reference number mapping settings as in the NetSuite connector:

Here is the order reference number mapping page in Acumatica:

Order field mappings. Order fields in ShipHawk are values that exist at the order level. Typically, this information can be stored in different places on the object being synced to ShipHawk. Order mappings can include a wide range of different fields in the ShipHawk order object, but the most important ones include:
1. Billing details (third party billing, collect billing, and so on)
2. Pickup and delivery instructions (for LTL)
3. Alternate return address mappings

Here are some use cases that customers have used order field mappings for:

Some companies book shipments for their customers using their carrier account. In order to do this, the third party billing information needs to be mapped from the ERP to ShipHawk
Some customers want to be able to map alternate return addresses, which are possible via order field mappings.
In some situations, the default field for some data is not the field that the customer is using. It is good to have integration flexibility out of the box

Additionally, the administrator should be able to map information from the customer record, order record, shipment record, and any other important sources of data that pertains to the order object.

Here is what the order field mapping look like in NetSuite:

Here is what order field mappings look like in Acumatica:

Line item field mappings. In some cases, line item fields are configured differently than the default.

Example use case:

When generating international documentation, ShipHawk needs the value of items in the shipment. In our NetSuite environment we have product sync enabled and can sync the SKU’s value to ShipHawk.

In some cases, however, the value may change depending on other circumstances.

For many of our NetSuite customers, line item field mappings are used to map the value of the items being shipped in that Sales Order instead of the value stored at the product/SKU level.

Additionally, the administrator should be able to map information from the item record, inventory details record and any other important sources of data that pertains to the order object.

Here is what line item field mappings look like in NetSuite:

Here is where line item fields are mapped in Acumatica:

Line item reference number mappings.

Line item reference numbers are frequently used to bring custom information at the line level onto documentation. For example, one customer has 5 T shirts of the same size and design, but just with a different color. The customer wants to be able to map the color of the shirt onto their packing slips to show their customer. Using line item reference number mappings, the user is able to bring this custom information onto their documentation.

Additionally, the administrator should be able to map information from the item record, inventory details record and any other important sources of data that pertains to the order object.

Here is what line item reference number mappings look like in NetSuite:

Here is where line item reference number are mapped in Acumatica:

Shipping method mappings. An administrator must have a way to map ShipHawk’s shipping methods to the shipping methods that are saved in the ERP.

Warehouse mappings

In order to properly sync and rate fulfillments in ShipHawk, a warehouse code must be populated in the API request. These warehouse code exists in the ShipHawk warehouse object as seen here:

There must be a page where an administrator can map the warehouse entered in the ERP to warehouse codes that the user enters.

3. Webhook Configuration

If possible, an administrator must be able to configure webhooks to receive information from ShipHawk to update shipments (see Receiving Information from ShipHawk TMS Requirements ).

4. Logs for Testing and Debugging

An administrator must be able to view logs of requests/responses to and from ShipHawk API and how they were processed by an ERP for testing and debugging purposes. We do not need there to be a new separate UI if the ERP has one to store and show logs.

Additionally, an administrator must be able to set up the automatic cleanup (deletion) of logs after a specified number of days/weeks to mange space usage. Access to at least 2 weeks of logs is required; access to 4 weeks is recommended.

Ideally, an administrator should be able to enable/disable debug mode in general. If enabled: log full requests/responses; if disabled: log only facts of events that happened, without full details.