Legacy contents
BackendID [string100]
The unique identifier of the order in the backend system. This ID is used when the mobile device sends a request to get the order lines. The BackendID normally corresponds to an order ID in the backend system, but you are in complete control of its meaning. If your order data comes from multiple tables (e.g purchase orders, sales return orders and transfer orders) you can prefix the BackendID with a value signaling the order type. When the registrations are returned you can decode the BackendID value to determine in which module the order should be posted. Status [int]
Determines if the order is available or locked.
1 = Unlocked
2 = Locked
The value of the status element determines which lock icon that is displayed in the order list.Sorting [int]
When the orders are displayed on the mobile device they are sorted by this column. You can use this to put important orders at the top of the list. DisplayLine1 [string100]
This value is displayed on line 1 on the ”Order List” screen. The line is displayed in bold.
DisplayLine2 [string100]
This value is displayed on line 2 on the ”Order List” screen.
DisplayLine3 [string100]
This value is displayed on line 3 on the ”Order List” screen.
HeaderLabel1 [string20]
This value is displayed in the first header label on the ”Order Lines” screen.
HeaderLabel2 [string20]
This value is displayed in the second header label on the ”Order Lines” screen.
HeaderValue1 [string50]
This value is displayed after the first header label on the ”Order Lines” screen.
HeaderValue2 [string50]
This value is displayed after the second header label on the ”Order Lines” screen.
OrderBackendID [string100]
The unique identifier of the order in the backend system. LineNumber [string50]
The line number of the order line in the backend system. FromBin [string50]
This is where the item should be taken from. E.g. a bin code (NAV) or a location (AX). ToBin [string50]
This is where the item should be placed. E.g. a bin code (NAV) or a location (AX). ValidateFromBin [boolean]
True: The mobile user must scan the correct FromBin value before he is allowed to perform the registration.
False: The mobile user can start the registration without validating the FromBin
ValidateToBin [boolean]
True: The mobile user must scan the correct ToBin value before he is allowed to perform the registration. If the ToBin element is blank the user can scan any value. This will make the user register where the items are placed (the user decides).
False: The mobile user can start the registration without validating the ToBinItemNumber [string50]
This is the unique identifier of the item in the backend system. The user can scan this value on the order lines screen to select the line. Description [string50]
The (short) description of the item. ItemBarcode [string1000]
This is the unique barcode value for this item. The user can scan this value on the order lines screen to select the line. If multiple barcodes are associated with the item a list of barcodes can be transferred. The default separator for barcodes is “;”.
E.g. barcode1;barcode2;barcode3
This can be helpful if items are packaged inside a box and the item barcodes are not visible unless the box is opened. Typically the box will have another barcode on it (because it’s a different unit of measure). If this barcode is also sent out it can be used to select the order line.RegisterSerialNumber [boolean]
True: The mobile user must scan the serial numbers of the items to handle. Each scan of increments the registered quantity by one.
False: A quantity can be entered directly. RegisterLotNumber [boolean]
True: The mobile user must first scan a lot number and then enter a quantity.
False: A quantity can be entered directly. RegisterExpirationDate [boolean]
This flag is used in combination with the RegisterLotNumber flag. If the lot is associated with an expiration date then this date can be captured on the mobile device by setting this flag.
The mobile user is allowed to register the expiration date in the short date format of the current regional settings on the mobile device, but the date format on the registration is always:
dd-MM-yyyy (e.g. 24-12-2009)
True: The mobile user must enter the expiration date after entering the lot number (before entering the quantity).
False: The user does not have to enter an expiration date
RegisterQuantityByScan
True: The user must scan the item number / barcode to register a quantity. Every scan adds 1 to the total quantity.
This setting is used in scenarios where it is very important that the handled items are correct.
An example of this is when picking medicine that does not use item tracking. Here the user must scan each individual packet / bag to verify that they match the ordered.
False: The user is allowed to enter a quantity.
SerialNumber [string50]
If the RegisterSerialNumber element is true and this element holds a value, the mobile application will verify that the user handles this particular serial number. LotNumber [string50]
If the RegisterLotNumber element is true and this element holds a value, the mobile application will verify that the user handles this particular lot number. Quantity [decimal]
The quantity to handle on the mobile device. RegisteredQuantity [decimal]
Not used at the moment – always set this value to 0. UnitOfMeasure [string10]
The unit of measure. Status [int]
Not used at the moment – always set this value to 0. Sorting [int]
When the order lines are displayed they are sorted by this column. DisplayLine1 [string100]
This value is displayed on line 1 on the ”Order Lines” screen. The line is displayed in bold.
DisplayLine2 [string100]
This value is displayed on line 2 on the ”Order Lines” screen.
DisplayLine3 [string100]
This value is displayed on line 3 on the ”Order Lines” screen.
UnderDeliveryValidation [string]
This element determines how the application behaves when the user tries to post the order. It determines if the user will receive a warning or be blocked if an incomplete order is being posted. You can also turn off validation completely.Thevalid values are:
None
The order lines are not checked before posting.
Warn
The user is warned if incomplete lines are discovered. The user can ignore the warning and post anyway. This setting is useful as a check to see if the user has missed a line unintentionally.
Block
The user cannot post orders with unfinished lines. This setting is useful if posting of an incomplete order will cause problems in other work processes. E.g. picking for a production order.
This flag determines if the user is allowed to register other bins / locations than specified by the ERP system.
True: The user is allowed to use other bin / locations. When another bin / location is scanned the user will get a warning message, but he can ignore the warning and proceed with the registration.
False: The user is not allowed to use other bins / location. When another bin / location is scanned the user will get a message telling that changing bin / location is not allowed.
UnitOfMeasure [string10]
The unit of measure of the registration. Quantity [decimal]
The registrered quantity. LotNumber [string50]
The registered lot number. If the RegisterExpirationDate flag is set on the order line the field will contain both the lot number and the expiration date (separated by a ”,” [can be changed in the configuration file]). The mobile user is allowed to register the expiration date in the short date format of the current regional settings on the mobile device, but the date format on the registration is always: dd-MM-yyyy
SerialNumber [string50]
The registered serial number. If the RegisterExpirationDate flag is set on the order line the field will contain both the serial number and the expiration date (separated by a ”,” [can be changed in the configuration file]). The mobile user is allowed to register the expiration date in the short date format of the current regional settings on the mobile device, but the date format on the registration is always: dd-MM-yyyy
ToBin [string50]
The bin where the handled item was placed.
FromBin [string50]
The bin where the handled item was taken from.
ActionType [string: TAKE / PLACE]
The action type tells if the registration was related to taking the item or to placing it. Depending on how the order line was setup regarding the ”ValidateFromBin” and ”ValidateToBin” flags, there will either be just a TAKE / PLACE registration or a TAKE / PLACE pair.
Description
Order Processing
The Mobile WMS application can be used to handle Receive / PutAway / Pick / Count / Move orders.
Each order type is basically handled in the same way and the flow of messages between the mobile device and the ERP system is seen below.
The data sent between the mobile device and the backend system is in XML format. This format is described in the following sections.
Order Data
When the mobile device sends a request for order data it expects the following data per order:
The unique identifier of the order in the backend system. This ID is used when the mobile device sends a request to get the order lines. The BackendID normally corresponds to an order ID in the backend system, but you are in complete control of its meaning. If your order data comes from multiple tables (e.g purchase orders, sales return orders and transfer orders) you can prefix the BackendID with a value signaling the order type. When the registrations are returned you can decode the BackendID value to determine in which module the order should be posted.
Determines if the order is available or locked.
1 = Unlocked
2 = Locked
The value of the status element determines which lock icon that is displayed in the order list.
When the orders are displayed on the mobile device they are sorted by this column. You can use this to put important orders at the top of the list.
This value is displayed on line 1 on the ”Order List” screen. The line is displayed in bold.
DisplayLine2 [string100]
This value is displayed on line 2 on the ”Order List” screen.
DisplayLine3 [string100]
This value is displayed on line 3 on the ”Order List” screen.
HeaderLabel1 [string20]
This value is displayed in the first header label on the ”Order Lines” screen.
HeaderLabel2 [string20]
This value is displayed in the second header label on the ”Order Lines” screen.
HeaderValue1 [string50]
This value is displayed after the first header label on the ”Order Lines” screen.
This value is displayed after the second header label on the ”Order Lines” screen.
The data above is the only order information needed by the Mobile WMS application.
Displaying Order Information
The standard ”Order List” screens are configured to show three lines of text for each order. Here you present the information that the user will use to identify the correct order. The values on the 3 lines are controlled by the content of DisplayLine1+2+3.
When an order is selected the user is transferred to the ”Order Lines” screen. In the top of the ”Order Lines” screen there are two lines to display information about the selected order. These values are controlled by the values in the HeaderLabel/Value elements.
Example XML
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0" encoding="utf-16"?>
<response messageid="4d932552-7394-45a6-89f0-011532c65912" status="Completed" xmlns="http://schemas.microsoft.com/Dynamics/Mobile/2007/04/Documents/Response">
<description />
<responseData>
<BaseOrder xmlns="http://schemas.taskletfactory.com/MobileWMS/BaseDataModel">
<BackendID>WM000001</BackendID>
<Status>1</Status>
<Sorting>0</Sorting>
<DisplayLine1>WM000001</DisplayLine1>
<DisplayLine2>No. of lines:4</DisplayLine2>
<DisplayLine3>WHITE</DisplayLine3>
<HeaderLabel1>Order No.</HeaderLabel1>
<HeaderLabel2 />
<HeaderValue1>WM000001</HeaderValue1>
<HeaderValue2 />
</BaseOrder>
</responseData>
</response> |
Order Line Data
When the mobile device sends a request to get the order lines for a particular order it expects the following information for each line:
The unique identifier of the order in the backend system.
The line number of the order line in the backend system.
This is where the item should be taken from. E.g. a bin code (NAV) or a location (AX).
This is where the item should be placed. E.g. a bin code (NAV) or a location (AX).
True: The mobile user must scan the correct FromBin value before he is allowed to perform the registration.
False: The mobile user can start the registration without validating the FromBin
ValidateToBin [boolean]
True: The mobile user must scan the correct ToBin value before he is allowed to perform the registration. If the ToBin element is blank the user can scan any value. This will make the user register where the items are placed (the user decides).
False: The mobile user can start the registration without validating the ToBin
This is the unique identifier of the item in the backend system. The user can scan this value on the order lines screen to select the line.
The (short) description of the item.
This is the unique barcode value for this item. The user can scan this value on the order lines screen to select the line. If multiple barcodes are associated with the item a list of barcodes can be transferred. The default separator for barcodes is “;”.
E.g. barcode1;barcode2;barcode3
This can be helpful if items are packaged inside a box and the item barcodes are not visible unless the box is opened. Typically the box will have another barcode on it (because it’s a different unit of measure). If this barcode is also sent out it can be used to select the order line.
True: The mobile user must scan the serial numbers of the items to handle. Each scan of increments the registered quantity by one.
False: A quantity can be entered directly.
True: The mobile user must first scan a lot number and then enter a quantity.
False: A quantity can be entered directly.
This flag is used in combination with the RegisterLotNumber flag. If the lot is associated with an expiration date then this date can be captured on the mobile device by setting this flag.
The mobile user is allowed to register the expiration date in the short date format of the current regional settings on the mobile device, but the date format on the registration is always:
dd-MM-yyyy (e.g. 24-12-2009)
True: The mobile user must enter the expiration date after entering the lot number (before entering the quantity).
False: The user does not have to enter an expiration date
RegisterQuantityByScan
True: The user must scan the item number / barcode to register a quantity. Every scan adds 1 to the total quantity.
This setting is used in scenarios where it is very important that the handled items are correct.
An example of this is when picking medicine that does not use item tracking. Here the user must scan each individual packet / bag to verify that they match the ordered.
False: The user is allowed to enter a quantity.
If the RegisterSerialNumber element is true and this element holds a value, the mobile application will verify that the user handles this particular serial number.
If the RegisterLotNumber element is true and this element holds a value, the mobile application will verify that the user handles this particular lot number.
The quantity to handle on the mobile device.
Not used at the moment – always set this value to 0.
The unit of measure.
Not used at the moment – always set this value to 0.
When the order lines are displayed they are sorted by this column.
This value is displayed on line 1 on the ”Order Lines” screen. The line is displayed in bold.
DisplayLine2 [string100]
This value is displayed on line 2 on the ”Order Lines” screen.
DisplayLine3 [string100]
This value is displayed on line 3 on the ”Order Lines” screen.
UnderDeliveryValidation [string]
This element determines how the application behaves when the user tries to post the order. It determines if the user will receive a warning or be blocked if an incomplete order is being posted. You can also turn off validation completely.Thevalid values are:
None
The order lines are not checked before posting.
Warn
The user is warned if incomplete lines are discovered. The user can ignore the warning and post anyway. This setting is useful as a check to see if the user has missed a line unintentionally.
Block
The user cannot post orders with unfinished lines. This setting is useful if posting of an incomplete order will cause problems in other work processes. E.g. picking for a production order.
- OverDeliveryValidation [string]
This element determines how the application behaves when the user tries to register a greater quantity on an item than the Quantity element dictates. The valid values are:
None
The user is allowed to proceed with the over delivery without any interference.
Warn
The user is warned and asked whether to proceed when trying to register a quantity that exceeds the expected. This is to make sure the user is doing so intentionally.
Block
The user is not allowed to proceed with the over delivery and a warning message is displayed.
AllowBinChange [boolean]This flag determines if the user is allowed to register other bins / locations than specified by the ERP system.
True: The user is allowed to use other bin / locations. When another bin / location is scanned the user will get a warning message, but he can ignore the warning and proceed with the registration.
False: The user is not allowed to use other bins / location. When another bin / location is scanned the user will get a message telling that changing bin / location is not allowed.
Example XML
| Code Block | ||
|---|---|---|
| ||
<?xml version="1.0" encoding="utf-16"?>
<response messageid="147db121-f664-4fb7-8d08-019ddf7405b1" status="Completed" xmlns="http://schemas.microsoft.com/Dynamics/Mobile/2007/04/Documents/Response">
<description />
<responseData>
<BaseOrderLine xmlns="http://schemas.taskletfactory.com/MobileWMS/BaseDataModel">
<OrderBackendID>RE000007</OrderBackendID>
<LineNumber>10000</LineNumber>
<FromBin />
<ToBin />
<ValidateFromBin>false</ValidateFromBin>
<ValidateToBin>false</ValidateToBin>
<ItemNumber>1150</ItemNumber>
<ItemBarcode>1150</ItemBarcode>
<RegisterSerialNumber>false</RegisterSerialNumber>
<RegisterLotNumber>false</RegisterLotNumber>
<RegisterQuantityByScan>false</RegisterQuantityByScan>
<SerialNumber />
<LotNumber />
<Description>Front Hub</Description>
<Quantity>100</Quantity>
<RegisteredQuantity>0</RegisteredQuantity>
<UnitOfMeasure>PCS</UnitOfMeasure>
<Status>0</Status>
<Sorting>0</Sorting>
<DisplayLine1>1150</DisplayLine1>
<DisplayLine2>Front Hub</DisplayLine2>
<DisplayLine3>UoM: PCS</DisplayLine3>
<UnderDeliveryValidation>Warn</UnderDeliveryValidation>
<OverDeliveryValidation>Warn</OverDeliveryValidation>
<RegisterExpirationDate>false</RegisterExpirationDate>
<AllowBinChange>true</AllowBinChange>
</BaseOrderLine>
</responseData>
</response> |
Registration Data
When the mobile device is finished with an order it sends the registrations in this format. There can be several registrations related to a particular order line. The registrations are grouped under each order line.
The unit of measure of the registration.
The registrered quantity.
The registered lot number. If the RegisterExpirationDate flag is set on the order line the field will contain both the lot number and the expiration date (separated by a ”,” [can be changed in the configuration file]). The mobile user is allowed to register the expiration date in the short date format of the current regional settings on the mobile device, but the date format on the registration is always: dd-MM-yyyy
SerialNumber [string50]
The registered serial number. If the RegisterExpirationDate flag is set on the order line the field will contain both the serial number and the expiration date (separated by a ”,” [can be changed in the configuration file]). The mobile user is allowed to register the expiration date in the short date format of the current regional settings on the mobile device, but the date format on the registration is always: dd-MM-yyyy
ToBin [string50]
The bin where the handled item was placed.
FromBin [string50]
The bin where the handled item was taken from.
The action type tells if the registration was related to taking the item or to placing it. Depending on how the order line was setup regarding the ”ValidateFromBin” and ”ValidateToBin” flags, there will either be just a TAKE / PLACE registration or a TAKE / PLACE pair.
Example XML
| Code Block | ||
|---|---|---|
| ||
| Excerpt | ||
Planned functions uses Header/Lines and includes actions for posting, viewing registrations and "order locking" |
Planned functions
- Receive
- Put-away
- Pick
- Ship
- Move
- Count
- Assembly
- Production
Key points
- Displays data is in two levels. Header and Lines
- Uses a Header defined in Reference Data with search filters
- Can have Unplanned Functions as actions on both Orders and Order Lines
- Standard Steps are definned by Workflows in Mobile Configuration Files but can be changed using Customization
Hierarchy
Each order can have multiple Order Lines
Steps
Workflows are stored directly in the Mobile Configuration Files, but somewhat configurable from the backend using Order Lines GetOrderLines Response
- ValidateToBin
- ValidateFromBin
- RegisterLotNumber
- RegisterSerialNumber
- and many more..
Customization
You can customize the existing functionality or create your own Planned function.
Document Flow
The document type name is shown (parantheses)
|
|---|
|
Mobile Configuration
Page types
Planned functions always uses two pages, called "OrderList" and "OrderLines".
| Child pages (Children Display) |
|---|
Explore the Mobile WMS App
| Page Tree | ||
|---|---|---|
|