Assumptions

The SOAP Shipping API for Metapack Delivery Manager will be used.

All Metapack calls are direct SOAP requests in XML format and do not go through middleware.

The carrier service (the combination of carrierCode and carrierServiceCode in Metapack) identified by Delivery Manager during a Rate Shop is mapped to a Manhattan Ship Via.

The carrierCode and carrierServiceCode values from Delivery Manager will be no longer than 50 characters.

Manhattan will not save the cost data returned from a Rate Shop as these are estimates.

MAO and MAWM make a Consignment call to Metapack Delivery Manager for each individual parcel and there will not be multiple parcels within a Consignment. It is not in scope to have multiple package shipments, master tracking numbers, or X of Y processing.

The shipping labels provided by Metapack meet the language and legal requirements of shipping in Europe after Brexit. There is no requirement by Manhattan to translate any shipping labels.

Metapack shipping labels are generated in the standard 4" x 6" label size. Manhattan does not perform any label resizing.

The Metapack shipping document file format for the Print call is configurable in Manhattan in order for each application to support its base functionality.

In MAO/MAWM, after a successful Shipping call has been made to Metapack Delivery Manager to create a Consignment, no edits to to add or remove parcels are permitted. It is out of scope to use appendParcelsToConsignment.

The Unit of Measure sent to Metapack is derived from the respective Manhattan Master UOM Item. Manhattan does not convert UOM in the request to Delivery Manager. Metapack supports both metric and imperial UOM.

Parcel dimensions must be sent to Delivery Manager, although it does accept values of “0”.

Manhattan can only send a Void Shipment request to Metapack if the Consignment has not yet been manifested.

MAO/MAWM sends a request to MetaPack to mark shipments as ready to manifest based on a scheduled process and a configurable remorse period.

If the shipping label call to the carrier fails, the user has the option to retry from the User Interface. This is applicable for integration with Metapack for all of Rate Shopping, Shipping and Printing.

Each Manhattan-enabled Fulfillment Location has a unique Metapack customer number.

Each Manhattan customer is responsible for configuring facility account information for each location.

The customer is responsible for supplying appropriate label stock and for any printer configurations both inside and outside of Manhattan.

Manhattan is responsible for marking the consignments as ready to manifest. The manifests will be sent on a scheduled basis by Metapack.

Each customer is responsible for ensuring that the frequency of the Manifest process (as well as any additional manifests triggered on an ad hoc basis) is aligned with any billing limitations set by their respective carriers.

Metapack Delivery Manager functionality re-evaluates the optimal shipping method during each of the Rate, Shipping and Print calls. It is therefore possible that Metapack can change the selected carrier for a Consignment between these calls. Because of this, Metapack expects the Rate ShopShip Vias to always be sent in the Booking Code field of the API request to allow for re-evaluation to occur.

MAO SOF package weight includes the item weight only. MAO does not maintain the package weight (box/envelope).

Metapack Delivery Manager supports moving the packages in each fulfillment to a status of 'shipped automatically’, i.e. without actual confirmation from the carrier that the package has been picked up. If confirmation from the carrier is required, then additional changes need to be specified and taken up by the respective project teams.

MAO standard behaviour does not allow a user to cancel/void a package after it has been submitted via the UI screens. If voiding a package from the UI screens after it has already been submitted to Metapack is required, then additional changes need to be specified and taken up by the project teams.

Rate Shop capabilities are not standard behaviour in MAO. However, due to the nature of Metapack Delivery Manager, it is possible for Metapack to change the Ship Via in the Shipping and/or Print calls that are generated from MAO.

Distribution Orders that require integration with Metapack will be marked by the host or integration layer with a Distribution Ship Via where the associated carrier is configured as an 'external' carrier. (This may not be necessary for a Rate Shop.)

Only individual oLPNs are integrated with Metapack, not Pallets of oLPNs.

An EPI Rate Shop will only be done during a routing wave or as part of the routing pipeline.

In the 'golden flow', the EPI Shipping process (i.e. Consignment creation and allocation in Metapack Delivery Manager) is performed through UI-WM Pack Station or as part of the WM Mobile Packing transaction. In the event that the message fails, this is re-sent through the UI-oLPN>Weight & Manifest screen.

An EPI Rate Shop works at the order level, and LPN level routing is not supported.

Pick Up, Drop Off/Locker Services are outside the scope of this implementation.

This solution will use the last updated user on the LPN to determine the most accurate print requestor for reprinting Customs documents/Commercial Invoices sent from Metapack.

This allows the user who has manifested the oLPN to reprint the documents manually via the oLPN UI, which will call the appropriate print requestor associated with that user.

For printing linked to the normal Pack Station flow (i.e. automatically printing documents after packing), the invoice will be printed at the Pack Station that was configured by the print requestor under the Printing Document Strategy.

The MAWM oLPN package weight includes the item weight only. MAWM does not maintain the package weight (box/envelope).