MetaPack

INTRODUCTION

This document describes the required screens to be used in setting up the MetaPack functionality in the warehouse. Other guides describe the set up of company, user, warehouse, EDI etc.

This is a client specific guide based on the version of the WMS system at the time of writing.

It can also be used by clients to specify their specific data values to aid initial system set up as well as for future reference.

Functional Specification

Log Number 287295 (MB-8F7K97)

Process Overview

01. Orders will be sent via an external sales ordering system via the standard EDI process and upload into the WMS with a new additional step to interface to MetaPack. Manually raised orders will not be sent to MetaPack.
02. At this point the orders will remain on the WMS EDI inbound transient tables
03. Once a confirmation response is received from MetaPack the order will progress into the WMS and follow existing processes
04. If an exception occurs then an alert will be generated to update Vision and the existing EDI validation screens will be used to amend the data
05. Once the data is amended the order will be resent to MetaPack and upon confirmation will progress as point 3
06. Pack confirmation will be amended to send an order update to MetaPack to print the required carrier labels
07. Orders will be manifested on the MetaPack system and upon completion will update the WMS
08. A new process will be developed to run on a timed basis to place a call on MetaPack to confirm the status of an order, if the order is at the correct status the process will despatch confirm the order to allow EDI processing
09. A new WMS screen will be developed to view the MetaPack audit log?
10. A new screen will be developed in Vision to view the MetaPack exceptions
11. The new audit log file will be added to the Oracle Data Extract suite for reporting

Pre-requisites and Setup

Printer Setup (Local PC)

To ensure the carrier labels are printed in the correct orientation and size, a zebra printer must be setup on the local PC.

Select the zebra printer option on your local PC, right click and select Printing Preferences -

Selecting Printer Preferences -

Ensure that values are set as above, with main values being the Paper Format and Size settings.

Order Priority (SOS1600) -

For Metapack processing, the WMS ‘Order Priority’ data setup must correspond to the same data in the Metapack ‘SERVICE GROUP’ data setup.

For Order Management Layer, the order priority will be set to the value received on the EDI order file in the emergency order flag field. This is expected to be ‘Y’ or ‘N’. These two values will need setting up on ‘Order Priority Maintenance’ screen.

Warehouse Maintenance (STKWHSE01A)

A valid Warehouse Id and full address details must be maintained to pass validation on MetaPack. This is to accomodate any returns back to the warehouse.

Warehouse Maintenance, UOM

Requires setting up to ensure the correct unit of measure is sent to MetaPack

Note: Metapack will by default store weights in grams and other dimensions in Metres.

Values required -

• Weight = GRM
  
• Length = MT

Stock Maintenance (STKSTOC01B)

Gross weight of the product is used to calculate the finished weight of the package, if not populated then the default weight will be passed to MetaPack.

Pallet Maintenance (WHS0045)

The Depth, Width, Max Height and weight of the Pallet/Package Type must be entered to be passed over to MetaPack else the default values will be sent.

Carrier Code Maintenance (WHS0055)

Ensure that carrier codes setup on MetaPack are maintained in the WMS, though not required for Sales Order validation it can be used for reporting and enquiry purposes.

Generally, carrier codes for own fleet and for any other carriers (e.g. DHL Express) will need to be created.

The carrier codes are created at Company level.

Owner Maintenance (STS1000)

External Interfaces Tab -

A new tab 'External Interfaces' will hold a MetaPack indicator which must be set to 'Yes' for the MetaPack functionality to be called.

Simple Object Access Protocol (SOAP) Connection Control Maintenance (XFM1001)

The Metapack SOAP name will need to be set as follows, and the SOAP WSDL will need to be configured to match the correct URL.

SOAP NAME	SOAP WSDL
METAPACK_DEALLOCATE	http://test1.metapack.com/dm/services/AllocationService
METAPACK_UPDATE	http://test1.metapack.com/dm/services/ConsignmentService
METAPACK_ALLOCATE	http://test1.metapack.com/dm/services/AllocationService
METAPACK_CONS_EXIST	http://test1.metapack.com/dm/services/ConsignmentSearchService
METAPACK_CONS_STATUS	http://test1.metapack.com/dm/services/ConsignmentSearchService
METAPACK_GET_CONS_REF	http://test1.metapack.com/dm/services/ConsignmentSearchService
METAPACK_CREATEANDALLOCATE	http://test1.metapack.com/dm/services/AllocationService
METAPACK_DELETE_CONS	http://test1.metapack.com/dm/services/ConsignmentService

NB: The SOAP WSDL listed above are the URL's for the test system at the time of writing, MetaPack will provide any updated URL's and the URL's for the production system.

• CreateandAllocate – This runs the Metapack ‘createAndAllocateConsignmentsWithBookingCode’ message.

• Deallocate – This runs the Metapack ‘Deallocate’ message.

• Update – This runs the Metapack ‘updateConsignments’ message.

• Allocate – This runs either the Metapack ‘AllocateConsignment’ or ‘allocateConsignmentWithBookingCode’ message.

• Cons_Exist, Cons_Status and Get_Cons_Ref – These 3 messages all run the Metapack ‘findConsignmentsByOrderReference’ message.

• Delete_Cons – This runs the ‘deleteConsignment’ message.

Authentication

• “Soap User” / “Soap Password” – This stores the username / password provided to access Metapack.

• “Maximum Batch Size” – This controls the maximum number of records which are sent in any one ‘batch’ of data records.

• “Timeout” – This is the maximum length in time (seconds) before a time-out is generated by the WMS process.

Package Defaults

• “Default Width” / “Depth” / “Weight” and “Height” – these are defaults to be used if none are provided for box size. If no value is provided, the system will default a value of 1.

• Sender Code - Used in MetaPack for reporting purposes, the sender code is the warehouse id as known by MetaPack else the value 'DEFAULT' is entered.

EDI Despatch Via MetaPack

NB: For the setting up of EDI processes see - EDI Setup and Processing

A local EDI process will be created and controlled by the EDI poller. The process will select for the owner and warehouse all orders whose order status is ‘6’ (Pick Confirmed) and has the MetaPack Confirm flag set to ‘Y’.

If the order is held in Metapack as status ‘Manifested’, ‘Tracking’ or ‘Complete’, then the EDI process will initiate the WMS despatch process, down-dating the stock and updating the order as despatched.

Should the response be any other value i.e. ‘Allocated’, then the process will not do anything to the order, and the order will be reprocessed the next time the poller runs.

XF Monitor Key Fields and Values

Field	Value
Transfer Type	N/a
Send/Receive	Local Process

Message Configuration

Description	EDI Common Name	XFM Command Screen	Process Code (XF Monitor)	Database Package Name	Notes
EDI Despatch via MetaPack	META_DESP	User Definable	META_DESP	dp_edigen_out_metapack.despatch_check	-

Process

Order Number Cross Reference Codes

WMS Value	Corresponding MetaPack Value
Order Reference (Order Description)	Order Ref
Customer Ref (Customer PO Ref)	Custom 1

Sales Orders

Sales Orders will be uploaded into the system and validated as standard, but if the MetaPack flag is set to 'Yes' for the owner then the orders will be held on the transient table and a call will be generated to MetaPack to send the order information over for additional validation.

Once the orders have been validated on MetaPack they will send a message back marking the order as either successful or failed.

Note: Any orders which generate a WMS error will not be sent to Metapack. Orders must be valid within the WMS prior to their sending to Metapack.

If successful the order will be uploaded into the WMS and will be ready for processing. If the order has failed validation on MetaPack then the a valid error message will also be returned which can be viewed in the SOP Validation Screen PFS1541.

Note: Regardless of the number of errors in a file, only the first error message is displayed within the ‘response’ message.

So if an order contains more than 1 error, the order may need to be amended several times to correct it as the user will only see the next error. For each run, a ‘SENT’ record will be generated, followed by either an ‘ERROR’ or ‘CONFIRMED’ record.

Exception Handling

Should for whatever reason, a situation arise where messages are failing to be successfully sent to, or, a valid response be received back from Metapack, a manual override is required to allow the orders to be uploaded into the WMS.

To do this, a check will be added to look at the owner level ‘Metapack Required’ flag.

If this flag is set to ‘No’ and orders exist in the EDI transient level files not approved by Metapack, but with NO WMS errors, the system will mark these orders as ‘Approved’, allowing these orders to be uploaded into the WMS.

Note: If the orders fail to be successfully sent there is no system option to re-send the orders.

Pick Wave, Allocation, Pick Confirmation

The above processes are all internal to the WMS and do not interact with MetaPack.

Packing

Packing will continue with no changes until the pack has been closed - Once an order is marked as ‘fully packed’, a series of new Metapack outbound calls will be made to indicate to Metapack that labels are required and for Calidus to get the correct tracking references.

An initial check will be run to check to see that the order exists in Metapack.

If this check fails, an information message will be generated informing the user that the order does not exist in Metapack, so no labels will be generated.

When the order is initially generated, it is assumed that all orders will only be packed into a single box. However only once the order is fully packed is it possible for the system to actually know how many packs an individual order will use.

NB: At this point the order is then ready for Manifesting on the MetaPack system. Once the order status has been updated then the EDI Despatch process will run (controlled by XF Monitor) and will down-date the stock and update the order as despatched. (see below)

NB: Error validation - Should connection to Metapack be lost, and a label fail to print, an appropriate error is generated. The user would need to go into Metapack and update the packing details and print the labels.

Despatch

A new local EDI process will be created and the running of this process will be controlled by the EDI poller. The process will select for the owner and warehouse all orders whose order status is ‘6’ (Pick Confirmed) and has the MetaPack confirm flag set to ‘Y’. The process will check each order at status '6' (Pick Confirmed) on the WMS for the status on MetaPack.

If the order is held in Metapack as status ‘Manifested’, ‘Tracking’ or ‘Complete’, then the EDI process will initiate the WMS despatch process, down-dating the stock and updating the order as despatched. If required an outbound EDI Despatch Message can also be generated at this point.

Should the response be any other value i.e. ‘Allocated’, then the process will not do anything to the order, and the order will be reprocessed the next time the poller runs.

Audit Trail and Reporting

MetaPack Audit (WHS4100)

Expected Status Values

• Sent
  
• Error
  
• Confirmed
  
• Packed
  
• Despatched
  

Audit screen displaying errors -

Reporting for Metapack auditing -

VISION

The Calidus Vision tool allows the user to view the audit log in real time. This will allow them to highlight and quickly deal with issues as they arise.

Glossary

Term or Acronym	Meaning
MetaPack	3rd Party Software used to manage parcel deliveries
WMS	Warehouse Management System. The OBS WMS is Calidus 3pl
SOAP	Simple Object Access Protocol. SOAP is a simple XML-based protocol to let applications exchange information over HTTP.
EDI	Electronic Data Interchange. The electronic transfer of documents or business data from one computer system to another computer system, i.e. from one trading partner to another trading partner without human intervention.
LOV	List of Values

Document History

Version	Date	Status	Reason	Initials
Version 1	08/07/2011	Complete	User Guide	LBW

Copyright OBS Logistics © 2008

The information contained herein is the property of OBS Logistics and is supplied without liability for errors or omissions. No part may be reproduced or used except as authorised by contract or other written permission. The copyright and foregoing restriction on reproduction and use extend to all media in which the information may be embodied