1. Metapack
  2. Shipping
  3. Integrations
  4. Integrating with Manhattan EPI

Using MAWM/MAO with Delivery Manager

The sections below provide a detailed explanation of how the integration works for each feature. Each feature can be enabled/disabled by configuring the appropriate user exit.

Note

In order to enable the Void, Print or Manifest feature, the Shipping feature is required because the details sent to Metapack for each of these requests is provided via the Shipping response.

Rate Shop Call (MAWM)

Rate_Shop_Use.png

  1. When Rate Shopping is triggered in MAWM, a Rate Shop request is sent to Metapack Delivery Manager to determine the appropriate carrier/shipping method based on the business rules set up in Delivery Manager.

    Note

    The Rate Shop Ship Via sent to Delivery Manager in the Rate Shop request must be associated with an appropriate carrier 'service group' in Delivery Manager.

    The Ship Vias used to trigger a rate shop call should be set up as the RateShopShipVias in the custom configuration for Metapack. If the Ship Via is not configured in the custom configuration, then the existing Ship Via on the order will be used for the subsequent Ship and Print calls.

  2. The MAWM data elements are mapped to the Metapack attributes on the MAWM interface, and an XML request is generated and posted to Metapack Delivery Manager.

  3. The request is processed by Delivery Manager and a response is sent to MAWM using the selected carrier/shipping method.

    Note

    All carrier/shipping methods that are evaluated will be listed in the Delivery Manager response. Since the optimal carrier/shipping method is always returned as the first record in the response, MAWM will only save the first record.

  4. The Metapack component parses the response and converts it into the format expected by MAWM.

  5. If successful, MAWM updates the carrier, Ship Via and service level on the package. If the call is unsuccessful, an error is displayed to the user.

Shipping Call (MAO and MAWM)

Shipping_Use.png

  1. When a package is completed in MAO or MAWM, a Shipping request is sent to Metapack Delivery Manager to create the Consignment. The Metapack component is invoked at the point at which the user submits a package.

  2. The MAO and MAWM data elements are mapped to the Metapack attributes on the MAWM/MAO interface, and an XML request is generated and posted to Metapack Delivery Manager.

  3. The request is processed by Delivery Manager and a response is provided that confirms that the Consignment was successfully created.

  4. The Metapack component parses the response:

    1. In MAO, in the event of a successful Shipping response, the Print call will be triggered immediately to retrieve the shipping label for the user to print.

    2. In MAWM, the client-specific configuration determines whether the Print call is triggered following a successful Shipping response, or whether it is triggered later in the flow.

  5. Base logic is used to display the error in the event that the Shipping call is unsuccessful.

Note

One Shipment (Consignment) call is sent to Delivery Manager per package. Multiple packages are not supported within a single Consignment. If a new package is created, then a new Shipping request is sent to Delivery Manager.

Print Call (MAO & MAWM)

Print_Use.png

  1. When the Print function is triggered from MAWM or MAO, a Print request is sent to Metapack Delivery Manager to retrieve the shipping label. In the case of MAWM, a request may also be sent for a customs form.

    Note

    The shipping document format is configurable in the custom configuration. MAWM supports printing the shipping label in ZPL format, size 4" x 6", and MAO supports printing the shipping label in PDF format, size 4" x 6". MAWM also supports the customs form, where the configuration is expected to be set to PDF format. MAO does not by default support the customs form.

  2. The MAO and MAWM data elements are mapped to the Metapack attributes on the MAWM/MAO interface, and an XML request is generated and posted to Delivery Manager.

  3. The request is processed by Delivery Manager and a response is provided to MAO/MAWM that contains a Base64-encoded shipping label/customs document.

  4. The Metapack component parses the response and converts it to the format expected by MAO/MAWM, which includes, in the base Document Management component, the tracking number and the shipping documents.

  5. Base logic is used to print the shipping label or display the error in the event that the Shipping call is unsuccessful.

Reprint (MAO)

MAO base functionality includes the ability to support reprint in case the shipping label was not successfully printed the first time.

If the user attempts to reprint the shipping label, MAO will first check if the shipping documents exist in the Document Management component. Then:

  1. If the shipping documents exist for the package, MAO/MAWM will retrieve the existing documents for reprint.

  2. If the shipping documents do not exist for the package:

    1. If the Shipment ID (i.e. the Metapack 'DMC' Consignment reference) field is populated for the package, MAO will trigger the Print call to Metapack Delivery Manager to obtain the shipping label.

    2. If the Shipment ID is not populated, MAO will first trigger a Shipping call to Delivery Manager and then trigger the Print call to obtain the shipping label.

Note

MAWM does not have a similar concept of Reprint. Instead, the user should re-invoke the Shipping or Print call again from the UI screen, and, if successful, continue the packing process in MAWM.

Void Call (MAO & MAWM)

Void_Use.png

  1. When a user voids a package, the Metapack component is invoked.

    The Metapack component checks the package's extended attribute to see if the package has already been manifested, using the new extended attribute field on the package - MetaPackIsManifested:

    1. If the package is marked as manifested (Shipment.Packages.Extended.MetaPackIsManifested = 1) in MAO/MAWM, then an error is displayed to the user that the package has already been manifested.

  2. If the package has not been marked as manifested in MAO/MAWM, then the MAO and MAWM data elements are mapped to the Metapack attributes on the MAWM/MAO interface, and an XML request is generated and posted to Delivery Manager.

  3. The request is processed by Delivery Manager, which attempts to remove the package from the carrier manifest based on the Consignment code sent.

  4. The custom Metapack component converts the response into MAO/MAWM format.

  5. The package is updated with the Delivery Manager Void response. If there is a failed response from Delivery Manager, the error is displayed to the user, who can then retry the Void call from the UI screen.

Note

In MAWM and MAO, a user can change the Shipping method once the Consignment has been created. If this occurs, Delivery Manager expects a Void call to be triggered to remove that package from the carrier’s open manifest.

In MAWM, a user can cancel a package from the UI screen after the Consignment has been created (but before manifesting). If this occurs, Delivery Manager expects a Void call to be triggered to remove that package from a carrier’s open manifest. It is not possible to void a package from the UI after the Consignment has been created via the base MAO screens.

EOD Manifesting (MAO and MAWM)

EOD_Manifesting.png

  1. A configurable scheduled job is run to initiate the carrier manifesting process.

  2. The single threaded job picks up any packages that have the following criteria:

    1. They are past the configured remorse period.

    2. They have a null value for MetaPackManifestedStatusCode.

    3. The package Extended attribute MetaPackIsManifested has a value of ‘0’/null.

  3. The list of these eligible packages is grouped by ShipFromLocationID, and the EOD Manifest is invoked for each group.

  4. During this process the MetaPackIsManifested flag is updated to a value of ‘1’. This ensures that the tracking number will not be sent to Delivery Manager on the next manifest job run.

  5. The Metapack Status Response Code is stored in the package Extended attribute in the Metapack Status Code field.

Note

Once a consignment has been manifested, it cannot be amended.

MAO/MAWM will trigger the markConsignmentsAsReadyToManifest call to Metapack Delivery Manager for the Metapack packages in MAO/MAWM based on a configurable remorse period.

MAO/MAWM will not trigger the createManifest call to Delivery Manager. It is expected that Metapack will schedule the auto-manifesting of any shipments in a ‘Ready to Manifest’ status, after the MAO/MAWM EOD Manifesting job has been run.

Errors and Troubleshooting

Table 9. Errors resulting in Call failures

Error Condition

Description

Remedial Action

Time Out (Shipping Label, Rate Shop, Void, Print)

The REST request times out without a response from Metapack. This component returns an error back to base, and the base screen is displayed with the error.

Use the Retry functionality to trigger a new call to Metapack.

Error Response (Shipping Label, Rate Shop, Void, Print)

If the user triggers a request and Metapack responds with an error, then the error message from Metapack is displayed on the UI.

Rectify the error by following the instructions on screen.

Time Out/Error Response (EOD Manifesting)

The REST Request times out and there is either no response from Metapack or Metapack responds with an error,

Retry the EOD Manifesting call later on.

Carrier Facility Account not Configured/Incorrect 

The call to Metapack fails because either the Carrier Facility Account is not configured correctly or the Account has invalid credentials.

Reconfigure the credentials and retry the transaction.

Void manifested package

If a request is made to void a manifested package, an error is returned from Metapack and then displayed to the user.

Nothing can be done as manifested packages cannot be voided.