| Info | ||
|---|---|---|
| ||
|
...
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 enabling 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.
...
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:
- Create new ReferenceData to be able to create Package Number steps at planned mobile documents
- 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)
...
- Verify the Tasklet standard implementation for Packages Numbers is indeed disabled in your solution (no eventsubscribers in your custom code must subscribe to codeunit "MOB Package Management"::OnAfterIsEnabled)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).
...
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.3539). 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 no.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 to when your custom implementation was last updated.