Round Trip of a Receipt

As an example, the Receipt function has been selected on the device (Purchase Receipts in Microsoft Dynamics 365 Business Central). In reality, all transactional functions on the device use the same mechanism meaning that the device client focuses purely on rendering a user interface while the framework plus extensions drive the entire transaction.

The user is currently signed into the WHITE warehouse.

Round Trip #1

The first-round trip is made. At this point the device has no validation or contextual data and does not know what Data Items are required to process the receipt.

The framework/WMS Devices returns the following response data…

No ColumnStyle data is returned, we do not have anything to display at this point (Although we could if we needed to).

When a Data Item is marked as Locked the device will not prompt for it. This data may be there for contextual or display purposes, or it may be unlocked later in the process.

Notice that the SourceDocument, SourceType, Description, UnitOfMeasure and QtyOutstanding DataItems are locked at the outset. These will be used for display purposes to guide the user as the transaction progresses.

Notice that VariantCode, LotNo, SerialNo, ExpirationDate and WarrantyDate are not currently locked – these may or may not become locked once ItemNo is entered or scanned dependent upon whether the Item is ‘Item Tracked’.

Round Trip #2

Now the device knows what pieces of data are required to complete a receipt transaction and it asks the user to enter the first unlocked DataItem: DocumentNo. The user enters the purchase order number on the supplied documentation (For the sake of the example let’s say Purchase Order No. 106044).

The following validation data is sent.

We have not collected much contextual data so far, but it is also passed to the WMS Device Framework

As previously stated, the framework does not maintain context internally – it’s far simpler to maintain the small amount of contextual data on the device and pass it with each round trip.

Why do we do this? Because as the transaction progresses, we need to retain this information to complete the receipt; we cannot complete a receipt without the document number, item number, variant (If required), quantity etc. and we cannot validate an item without knowing the document number.

Clever WMS Devices now knows that it needs to validate a Document No. of 106044. It finds the purchase order number and collects a set of response data to return…

Notice that DocumentNo has now been locked, we do not want the device to prompt for the source document again as we have collected that data.

We also want to display this information, so we prepare a ColumnStyleGroup encapsulating the following ColumnStyle data.

Notice that the caption for DocumentNo has changed, we know it’s a purchase order and want to use that as the caption on the device.

This is what the device screen now displays…

The device is displaying only the ColumnStyle data returned, even though more data has been collected.

The device is now prompting for Item No. as the next unlocked DataItem.

Round Trip #3

The user is required to enter an Item No. as the next unlocked DataItem.

The user could enter each piece of information separately but in this case, scans a GS1-128 barcode which contains three pieces of information: Item No., Lot No. and Quantity.

Even though the device is prompting for Item No. Clever WMS Devices and the framework have told the device which DataItems match up to the GS1 identifiers for Item No., Lot No. and Quantity, so they are automatically assigned to the correct DataItem.

The solution is designed so that this only requires one round trip rather than three separate trips. There is a time-cost with each round-trip that is largely authentication with the web service, so it is more expedient to collect the information together.

The following collected validation data is sent… Along with the collected contextual data so far…

Clever WMS Devices uses the contextual data of the purchase order number 106044 and matches it to one or more lines matching the item number 1200.

The lot number in this case is ignored because item number 1200 is not lot tracking on this system.

The Quantity is checked that it is a number, and that there is sufficient outstanding to cover the receipt.

Because the item has no variants, and is not item tracking the appropriate DataItems are locked off.

The following response data is returned to device…

All DataItems are now locked, we have enough data to process a receipt line.

The following ColumnStyle data is returned for display…

The device displays the returned data as instructed…

Round Trip #4 – Post!

The device has collected all necessary data to process a receipt line, namely the order number, the item number, and the quantity.

The Post button becomes available on the device.

When the user clicks Post all collected contextual data is passed to the framework with a request type of Post…

• The Receipt Post function performs the following actions…

• Creates a Warehouse Receipt if required.

• Finds the Source Document Line.

• Populates the Qty. to Receive column on the Warehouse Receipt Line.

• Calls Codeunit 5760 Whse.-Post Receipt which posts the receipt.

Finally, the DataItems are reset so that the next receipt line may be processed.