Case: Create a custom implementation for Package Numbers

Minimum Requirements

  • Extension version MOB5.39
  • Android App version 1.8.0
  • Business Central BC18 (or newer)

Case

A new custom implementation for Package Numbers in Mobile WMS is required to meet demands from other customizations or a vertical solution.

Please read the entire article Whitepaper Use tracking by package number in reservation and tracking system before creating a new custom Mobile WMS implementation for Package Numbers.

That article explains the current state of Package Numbers implementation in Business Central and discusses what alternatives exists for how to implement Package Numbers in the Mobile WMS.


You may have created a new vertical solution or customizations for a customer that expands the functionality of the Package Number dimension in the standard Business Central application. Your customizations likely changed workflows and added new functionality derived from the Package Numbers.
In this case having our standard implementation for Package Numbers in Mobile WMS enabled is likely to do more harm than good.  Our standard implementation supports a specific standard workflow, and when this changes it is likely you rather should create your own custom implementation for Package Numbers in Mobile WMS.

(from Whitepaper Use tracking by package number in reservation and tracking system)

Overview

In standard Business Central the "Package Management" codeunit implements the new Item Tracking Dimension using all eventsubscribers. However, this standard codeunit can only deal with processes known to the base Business Central application and will lack any knowledge of (and support for) processes and fields specific to Mobile WMS. Attempting to post anything set up for Packages Numbers from mobile devices will fail as no Package Numbers is being collected from mobile devices and no values are being transferred though the system to journals etc.


We have created a "framework" (or, pattern) consisting of a rather large number of events (35+) to "fill in the blanks" and implement anything related to Mobile WMS for a new item tracking dimension. Overall these events will be used to:

  • Add new Package Number steps to planned documents and adhoc functions when Item Tracking Codes are set up for package tracking is required
  • Show pre-populated Package Numbers at the mobile device
  • Save Package Numbers from Mobile WMS Registrations
  • Copy Package Numbers between various internal tables in Mobile WMS
  • Apply filters accordingly
  • Populate datasets for our Cloud Print solution (if used)
  • (and more) 


All events in this framework will need a subscriber (an implementation) for Package Numbers to fully work with every mobile DocumentType at the mobile devices.


Proposed solution

Our (disabled) standard implementation for Package Numbers are using this same framework of 35+ eventsubscribers to implement its solution. The existing code and all neccessary eventsubscribers can be seen in codeunit "MOB Package Management" in the Mobile WMS App. 

Creating a starting point for your custom implementation could be done as:

  • Verify the Tasklet standard implementation for Packages Numbers is indeed disabled in your solution (Mobile WMS Setup, field “Package No. Implementation”).
  • Download the full Mobile WMS sourcecode from University.taskletfactory.com
  • Clone codeunit "MOB Package Management" to your own custom app (changing the object name and object number)
  • Remove the "EventSubscriberInstance = Manual;" condition from your cloned codeunit
  • Deploy the codeunit to your development server
  • Verify that that Package Numbers is now working from the mobile device (note: not every process at the mobile device may work as intended if your existing customizations or vertical solution has changed the processes at mobile devices).


You now have a codeunit in your app ready to edit and modify as needed.

  • Start refactoring eventsubscribers in your codeunit clone to match your existing customizations that has already been made to Mobile WMS
  • Implement other customizations or your vertical solution using our general development API (see API Documentation)
  • Edit or add additional eventsubscribers as needed to implement new custom DocumentTypes or RegistrationTypes


All-in-all your customizations to processes and workflows may consist of changes to standard BC, changes to mobile application.cfg, modifed and new DocumentTypes, new mobile Lookup pages etc.  This is almost guaranteed to make up the major part of your customizations and the most time consuming part of your project. The custom implementation for Package Numbers is just on top of that to make sure the tracking dimension works "behind the scenes". When organizing your project the actual changes to processees and frontend are best done from other codeunits to make it easier to maintain your custom Package Number implementation (see below).


Maintaining your custom implementation

The number of events in our "framework" is around 35 events in our initial release of the framework (MOB5.39). Future versions of Mobile WMS could likely add new events to the framework. This may cause both existing and new features of Mobile WMS to longer work as intended with your custom Package Numbers implementation.

Every once in a while you may need to investigate if new events are needed for your custom implementation. Unfortunately this can currently only be done the hard, manual way. Below is a suggestion of how your may process this:

  • Keep a copy of the original and unchanged "MOB Package Management" codeunit in your project (rename project file to include original MOB version number and to no longer be an .al file: It should be a text-only file and must not be included when your app compiles)
  • Download the source code of the most recent Mobile WMS version
  • Create another text-only clone - now the most recent "MOB Packing Management" codeunit (manually rename the file, MOB version number, also not .al)
  • Compare the two textfiles for changes that may need to be transferred to your actual .al codeunit file (by moving such changes manually or implementing new corresponding changes)

Keeping text-only (unchanged) clones in your project with MOB versions numbers will make it easier to compare changes and allow you to know when your custom implementation was last updated.