Manifest management

This chapter gives a brief overview of how the XML Manifest are imported into the TnT2 system.

The manifest import process is divided into four separate services that are described below. In every step the result can be seen in the TnT2 clients manifest view, where the user will be notified of errors in the process and will be able to rectify and re-import failed manifests.

The first step of the import process is the importing of the XML manifest files from the source into the TnT2 database. This is done by the Manifest Importer Service. This service is modular and contains different parsers and readers. The reader is responsible for picking the manifest data up from a remote source and providing it to the importer service. Currently the following readers are implemented:

• FileReader - reads the manifest from a configured file area
• FTPReader - reads the manifest from a configured FTP site

After being read the data is inspected and the service tries to find a suitable parser for the manifest. Specific parsers can be implemented for each supplier.

If no suitable parser is found the service falls back to the STDParser.

As of version 1.2 of the ManifestImporter service a new, more efficient, way of manging manifests in the TnT2 system is implemented. The TnT2 ManifestImporter will first search for a parser in the /parsers/v2 folder and if found the v2 parser and Manifest service flow will be used. The main improvement in the v2 flow is that the internal size of the manifest data in the database has been significantly shrunk. This allows using larger manifests without hitting the 16MB document size limit in MongoDB.

The configuration of the Manifest Importer Service is done in the TnT2 database, in the collection called manifestsources. Follow the link to the specific reader in the list above to see samples of configuration for that specific reader.

When the manifest has been successfully imported into the TnT2 database the next step is to find a valid Purchas Order to match with the manifest. This is done through the PurchasOrderImporter (POImporter) service. Te POImporter is a modular service with a possibility to connect to different PO source systems, currently the implemented modules are:

• SIB Integration platform

The POImporter checks the XML manifest for the required PONum, and looks the PO up in the source system. If there's an error the service will set the manifest to the error state and wait for user action through the TnT2 Client, otherwise the PO data is added to the manifest in the database.

The Manifest Validator Service checks the manifest for compliance with the TnT2 specs. It verifies that all producerproductcodes can be translated to an ITEMNUM that the procurement system can understand and that everything is OK with the manifest for pack/item creation.

If there's anything wrong with the manifest it will be set to the error state and user action through the TnT2 client is required, otherwise it's set to the verified state.

When the manifest is in the Validated state it's all ok for pack and item creation. It will stay in the Validated stat until a Shipment Receipt is triggered by a user, either in the TnT2 Client or in the Scanner app. When the receipt is triggered the Manifest Builder Service creates all the packs and items on the manifest in the TnT2 database and triggers the Shipment Receipt integration.