Agility Shipping - Service Type not found in mapping table

 Overview

Pick Pack is where Agility Shipping's small-package rules live — how a Macola ship via code turns into an actual UPS, FedEx, or USPS label.

All Pick Pack setup starts from the same place inside Agility Explorer:

File → Options → Pick Pack

From here, three areas govern how a shipment gets rated and labeled: Ship Via mapping (which carrier service and payment method a Macola ship via code resolves to), Freight Pay Code mapping (how Macola's N/C/P freight codes translate to a payment type per carrier), and Table Maintenance (account-level and address-level exceptions like third-party billing and drop-ship "ship from" overrides). Most shipment-processing errors — including the one this article walks through — trace back to a gap in one of these three tables rather than a bug in the shipment itself.

Ship Via mapping

Use this screen to map each Macola ship via code used for small-package shipments to the correct carrier service type and payment method. Every ship via code a customer or order can carry needs a row here for every carrier it might ship through — a ship via code that exists in Macola but has no corresponding row (or an incomplete one) on this screen is the single most common cause of shipment failures in Agility Shipping.

Payment methods available per carrier

UPS service type definitions (Ground, 2nd Day Air, Next Day Air, etc.) are maintained by UPS directly — check their service guide before mapping an unfamiliar code.

Freight pay code mapping

Maps Macola's three default freight pay codes to a payment type, per carrier.

1. Select the carrier, then click New.
2. Enter the pay code and description from Macola (N, C, or P).
3. Highlight the new freight code under that carrier, then use the Payment Type dropdown to map it — e.g. Carrier = UPS, Pay Code = N, Description = No Charge → Payment Type = No Freight.
4. Repeat for each remaining carrier using the same freight code.

Note: Once a pay code is entered for one carrier, it becomes available under all carriers — but it still needs its own Payment Type mapped per carrier.

Table maintenance

Account and address exceptions that sit underneath the mapping tables above.

File → Options → Pick Pack → Table Maintenance

Third Party Accounts

Used when a UPS/FedEx/USPS account is billed to neither the sender nor the recipient but to a separate entity — for example, a drop-shipped order billed to your customer's own carrier account. When an order is flagged as third party in Macola, Agility checks the exact alternate address first, then the "SAME" alt address, then "[DEFAULT]" — in that order. If none of the three has account information on file, the shipment errors out.

Drop Ship Addresses

Lets a shipment show a different "Ship From" address on the label than the shipping location actually processing it — useful when a customer wants an order to appear as though it shipped from their own address rather than yours.

Troubleshooting: Service Type not found

Why Agility Shipping throws this error at the moment a shipment is processed, and how to close the gap in the mapping table.

Runtime error:
Agility — Failed: Ship:LoadAllShipmentData:LoadShippingDataObject: Passed in Service Type not found in mapping table:-1

This fires while Agility Shipping is building the shipment object, right at the point it looks up which carrier service type applies to the ship via code on the order. A return value of -1 means the lookup ran and came back empty — the code exists, but nothing usable was mapped to it.

Why "the ship via code is already set up" isn't the whole story

It's a natural first check, and it's usually right — this error is well known to occur when a ship via code has no Ship Via mapping row at all. But the code can exist in that table and the error can still fire, because the row itself is incomplete: the code is present, but its Service Type column was left blank or unmapped for that specific carrier. Agility finds the row, finds nothing in the column it needs, and returns -1 rather than a valid service type.

Resolution steps

1. Open File → Options → Pick Pack → Ship Via and locate the exact ship via code used on the failed shipment.
2. Confirm a row exists for the specific carrier the order shipped under — a code mapped for FedEx does not cover a UPS shipment using the same ship via code.
3. Check that the Service Type field on that row is populated, not blank. This is the field that most often gets missed when a new ship via code is added quickly.
4. If it's blank, map it to the correct carrier service type, then confirm the Payment Method is also set.
5. Re-run the shipment. If it still fails on the same code, re-check the mapping row was actually saved — a value selected but not saved reverts on screen refresh.

Known-issue pattern: The same failure mode shows up under a different label in ticket history: Payment Type not found in mapping table:-1. That case traced to null values in the underlying wsPkgShipPmtMapping.APIPaymentTypeCode column and was closed by an updated mapping script shipped in Synergy 3.0 (06/29/21). If every row visibly shows a Service Type in the UI but the error persists, the same class of bug is worth ruling out here — a null underlying code value beneath a row that looks complete. Escalate to WiSys support with the specific ship via code and carrier if manual re-mapping doesn't clear it.

Reference

Full setup screens, figures, and menu paths for every option covered here are maintained in the official WiSys documentation:

support.wisys.com — Agility Options: Pick Pack