Tutorial: License plate consolidation in Dynamics 365 for Operations (1611)

Introduction to scenarios

The Microsoft Dynamics AX Warehouse management module supports a number of advanced scenarios for warehouses, thanks to the flexibility offered by the concept of Work and work lines, which take care of any and all operations in the warehouse. The system has a number of complex configuration possibilities that determine how work is created. At the same time, AFTER it has been created, work is fixed and any necessary changes require a lot of manual supervisor interventions, or, in many cases, are not possible at all.

Imagine the following two scenarios:

Scenario 1

A customer orders a number of items from us. Based on our work template setup, multiple work orders are created to pick these items from the warehouse, say, some are picked from a cooled area, while the rest is coming from the regular picking area. All of the items are placed into a staging area location after picking, to be loaded on a delivery truck.

Scenario 2

A customer orders a number of items from us. A sales order is created in our system, released to warehouse, so work is created. The picking commences, and the goods arrive at the staging location, but are not shipped the same day, because the truck to pick them up only arrives tomorrow. The same evening, the same customer orders more items from us. Correspondingly, a new sales order is created and released to warehouse, creating more work. The pick is completed, and the goods are placed in the staging location ready to be loaded the next day. The warehouse manager decides to ship both shipments on the same truck tomorrow, adding the second shipment to the same load that contains the first shipment.

In both scenarios, we now have two license plates on the same load, that are going to the same customer, sitting in the same location. When the truck comes, they will need to be loaded separately one by one, even though in many cases, the items would fit perfectly fine on just one license plate.

Until now, the warehouse worker had no way to merge the two license plates together to ship everything on just one license plate, at least in the system (probably does happen outside of the system already).

In the Fall release of Microsoft Dynamics 365 for Operations (1611) we have added the ability of consolidating items on a license plate with items on another license place within the same location, where there is work behind one or more of the license plates. This is supported by a new type of mobile device menu item with Indirect Activity code “Consolidate license plates”.

Scenario walkthrough

All you need to do to enable this mobile device flow is create a new mobile device menu item that looks like the screenshot below:

LP consolidation mobile device menu item

For the scenario walk-through I have created two sales orders as below:

• Sales order 000781 for customer US-001, which contains two lines:
• 10 ea of item M9200 from warehouse 51
• 15 ea of item M9201 from warehouse 51
• Sales order 000782 for customer US-001, which contains one line:
• 7 ea of item M9201 from warehouse 51

Sales order 000781 was released to warehouse first, before 000782 existed, resulting in the creation of Shipment USMF-000008 on Load USMF-000010.

Sales order 000782 was then added to the same Load, and also released to warehouse, resulting in the creation of Shipment USMF-000009.

The following picking work was created for these 2 shipments:

Work order details

This scenario corresponds directly to Scenario 2 I described above.

Now, for both work orders the initial picks are executed (one or different workers), and for both the goods end up at the STAGE location, awaiting loading, as shown below:

Work order details after initial pick was executed

From here on, license plates TLP_001 and TLP_002 follow the same path in the warehouse, more specifically they both will be picked up from STAGE and loaded into the truck at BAYDOOR location.

If the warehouse worker at the outbound dock makes the decision to consolidate these two license plates (currently, this is only an ad-hoc decision by the worker, planned consolidations are not supported), he can do that using the above mobile device menu item. Here is how the flow would look on the mobile device:

Step 1

You are presented with a screen, where you need to enter the Target LP. This is the License plate, where the items will end up after the consolidation.

• This can be a new License plate. There is no way to print this new LP Tag from this screen at this point, however, so keep that in mind.
• This can be an existing empty License plate. This could, for example, be useful, if you want to merge the contents of 2 half-pallets onto 1 empty euro pallet. Another case is if the pallet, where the items currently are placed, is damaged or “unshippable”.
• This can be an existing full License plate, which is set as a Target LP on an existing work order with Work order type “Sales order” or “Transfer order issue”
• This should not be work that has a Container Id on the header or any of the lines.

LP Consolidation, Step 1

Step 2

Target LP was accepted, and now you are asked to scan in the LP you want to merge onto the Target LP.

• LP to merge needs to be a target license plate for an existing work order of Work Order Type  Sales Order or Transfer Order Issue.
• The LP to merge needs to be in the same location as the Target LP, and it cannot be the final shipping location (that’s too late, since goods are already Picked at this point).
• The LP to merge needs to relate to the same Load as the Target LP
• It should also have the same delivery information, if there are more than one shipment involved. Namely, the Delivery name, Customer account, Delivery address and Mode of Delivery should match.
• The remaining steps in the flow for both work orders being merged need to match. This is done so we ensure all relevant steps are executed, for example, that the labels are printed at the appropriate time in the flow for all consolidated items.
• This should not be work that has a Container Id on the header or any of the lines.

LP consolidation, Step 2

Step 3

When LP to merge is accepted, the worker is presented with a confirmation screen, that shows a summary of all items on that license plate. This is to help ensure that he scanned in the right LP before the actual consolidation of the two work orders happens.

In the case below, there was only one item on TLP_002, with a total quantity of 7.00 ea

LP consolidation, Step 3

Step 4

Once the worker confirms by pressing OK, the consolidation is executed, merging the two work orders together and moving all items from LP to merge to the Target LP.

The worker gets a confirmation message that the license plates were merged, and is presented with a screen where he can continue scanning in any following license plates to merge onto the Target LP.

LP consolidation, Step 4

Here is how the work looks after consolidation happens:

The work related with LP to merge, in our scenario walk-through that is TLP_002, is now marked as Closed, and by reviewing the work lines you can see the final Put step was changed, so it now points to STAGE location instead of BAYDOOR. The only thing that changed is which license plate it is put onto, namely TLP_001 instead of TLP_002.

Work order details after LP consolidation - Merge From work

The work related with Target LP, in our scenario walk-through that is TLP_001, is still In progress, and you can see the quantities on the remaining Pick/Put pair were increased accordingly with the quantity from work related with TLP_002.

Work order details after LP consolidation - Consolidated work

If you review the corresponding work transactions, you will see that an extra transaction corresponding to the load line for M9201 from sales order 000782 has been added to the Pick line to represent the additional Pick quantity.

Accordingly, the inventory transactions also reflect the fact items were moved from TLP_002 to TLP_001, and the new work reservations are based on that as well.

Mobile device menu item configuration option “Cancel remaining origin work lines”

We expect most companies to run with this configuration option turned on. It comes into play in the following situation: When there are more subsequent staging steps on both work orders, this configuration will enable you to forfeit any of the steps on the work being merged from, so the steps on the consolidated work will be the ones executed for all merged items. That specifically means that any “extra” steps on the work being merged will be Cancelled.

If there are some specific reasons why all work steps need to be executed for the merged work order separately, you should not enable the configuration option. As a result, however, you will not be able to consolidate this LP to another one.

See a more detailed explanation in the Help Text for this configuration on the menu item.

For those behind on updates :)

This feature has been back-ported to Microsoft Dynamics AX 2012 R3.

You can download it from KB number 3190562

Let us know what you think of this new feature!

Tutorial: Extending the label printing functionality in Microsoft Dynamics AX 7

Today I would like to shed a bit more light onto how to extend the label printing functionality, specifically, show how to add a new field from the work line to be displayed on the label.

This is something we have created as a demo for Tech Conf a while back, and you can still see the recording where Per and Zach from our team showcases the different label printing scenarios.
You can view the different Microsoft conference videos here.

Just as a refresher, here is a guide for how to set up label printing in Dynamics AX 7:
http://kashperuk.blogspot.dk/2016/10/tutorial-label-printing-in-microsoft.html

Technical introduction

The label printing "framework" consists of three main components:

• WHSLicensePlateLabel table, which contains the information for the label, which is substituted into the label through the variables.
• WHSLicensePlateLabelBuild class, which is responsible for populating the WHSLicensePlateLabel table with data for a particular work order (line).
• WHSDocumentRouting class, which is responsible for the actual printing of the label, as well as the substitution of variable values, using the below methods:
• initMenuFields() method is responsible for building the list of substitute fields based on the WHSLicensePlateLabel table fields
• printDocument() method finds the specific document routing record that matches the flow criteria (e.g., warehouse, work order type, carrier, etc.), performs the translation of the label and sends it to the selected printer (Note that the label can be printed to multiple printers and you can for each printer decide, which layout to use).
• translate() method is responsible for actually replacing any variables in the label layout with the corresponding values from the WHSLicensePlateLabel table

Let's take a closer look at the fields available on the WHSLicensePlateLabel table:

WHSLicensePlateLabel table fields

These fields represent the full list of potential variables that can be put into the label in the Document Routing layout. Depending on the item flow, some of these fields are not populated. Note that when setting up the placeholders in the Document Routing Layout form, only visible fields are displayed. That allows for storing some "plumbing" information for each record, like the PrinterSettings.

Adding placeholder variables to a label layout

Fragile Example extension

For some scenarios you might want to display some additional fields on the label, which are not part of the list shown above.

Imagine a scenario where we want to display a "Fragile" message on the label if the items on the work line are accordingly marked. 

Since there is no such field in the label, we will need to extend this functionality. And because we are working in AX 7, we will try to use Extension instead of Overlayering the elements, as we would do in AX 2012 R3.

Step 0 - Create a new model for our changes

First of all, let's create a new model, which will contain all the elements we add through extension.

Create a new model in Visual Studio

We will put this model into a new package, as we do not intent to overlayer existing AOT elements. We will reference the Application Suite package, so that we can access the elements defined in it, such as the ones mentioned above. 

Note that by default the new package will also reference Application Platform.

Select referenced packages for model FragileExample

Confirm the creation of the new model and create a new project for it. Name it FragileExample.

Step 1 - Extend the WHSLicensePlateLabel table and add a new field FragileCode

Since we want to display an extra field in the label, we need to add it to the WHSLicensePlateLabel table. In order to do that, let's create an extension of this table in the new model:

Adding a new table extension from Application Explorer

You need to have selected the right project in your Solution Explorer before you attempt creating an extension. This is to ensure that the extension is actually created in the right model.


We are now going to add a new field of base type String, and call it FragileCode with the corresponding label.

Note I am not going to bother with labels or Extended Data types for sake of simplifying the demo

Table extension for WHSLicensePlateLabel in FragileExample model

New field FragileCode on table extension WHSLicensePlateLabel.Extension

In order for the field to appear in the Document routing layouts form all we need to do is compile the new code and synchronize it against the database. I have decided to do that at build time by configuring it accordingly, as shown below:

Synchronize on build = true for FragileExample project

If we now reopen the Document routing layouts form, we can see that our new placeholder is available in the list and we can add it to the label:

Fragile code placeholder available in Document routing layouts form

Step 2 - Populating the Fragile code field on WHSLicensePlateLabel record

Now that we have the field available on the label, we need to populate it. 

As described in the Technical information section above, the label details are populated in the class WHSLicensePlateLabelBuild. Let's quickly examine how this happens:

Sequence of calls to build a license plate label

As you all know, any and all work creation and execution in Dynamics AX happens through the WHSWorkExecuteDisplay* classes, e.g., purchase order registration can execute WHSWorkExecuteDisplayPOItemReceiving, while general work execution flows can execute WHSWorkExecuteDisplayUserDirected, etc.

Within these classes the WHSLicensePlateLabelBuild class is initialized, and the buildLicensePlateLabels() public method is called, when a label needs to be generated and printed.

Depending on the flow, either the insertSingleLabelPrintLine or the insertSingleLabelMenuItem method will be invoked internally, after which the generated label is printed through the printDocument API of the WHSDocumentRouting class, as described above.

Note. insertSingleLabelPrintLine supports the flow where the Print step is part of the work template lines, while insertSingleLabelMenuItem is for the case, where the Print is configured through the mobile device menu item.

So, in order for us to populate the extra new field we need to look into these insert* methods. With the recent AX 2012 R3 changes these methods have been refactored in a way, where most of the logic for populating the WHSLicensePlateLabel table has been pulled out into a new private initLabel() method.

In Dynamics AX 7 this method has been extended (who could have done that? :)) and now has a delegate which is invoked at the end of the method, which means that event handlers can be created for it. With these minor changes, we can now extend this class by subscribing to the event of the initLabel method being invoked, as shown below:

Copy event handler code for labelInitialized delegate

We can now put this generated event handler signature into a new class in our model, as shown below:

Signature of the event handling method for labelInitialized delegate

This is awesome and is one of the new extensibility language features in Dynamics AX 7 - I have subscribed to the event of this method being called without touching the original class at all.
As you can see, instead I have a SubscribesTo attribute that subscribes me to the corresponding event in a static fashion. 

Now all we need to do is actually populate the Fragile code on the label. Let's do that:

Implementation for the event handling method for labelInitialized delegate

As you see above, the code is super simple, all we do is get the Filter code value from the corresponding item, and populate it into the FragileCode field.

Let's now compile everything and give it a go in AX web client.

You can download the VS project file from my OneDrive here.

AX flow steps and result

1. Modify item A0001, setting Filter Code 4 to a new value called FRAGILE
2. Create a new purchase order for 10 pcs of A0001 to WH 24
3. Modify the Mobile device menu item for Purchase receipt to "Print label"
4. Ensure you have a Document routing record matching WH 24 for Purchase orders
1. Ensure you have a document routing layout being sent to a label printer
5. Receive the above purchase order through the WMDP

As a result, you should get a new label created, which will have the Fragile code populated with the value FRAGILE, as below (I've personalized the form to show the new field):

License plate label with the populated Fragile code

Depending on your label layout you would have this message printed on the label as well.

Conclusion

With this blog post I hoped to show you how to extend the existing set of fields available on the license plate labels.

At the same time we took a look at some of the new language constructs, design paradigms and tooling that allows for a much cleaner approach to extending existing functionality, as compared to overlayering, which many are used to.

Consider extending instead of overlayering next time you need to make a change!

Tutorial: Update product receipts for loads and how to handle items missing from ASN

In my post about the ability of receiving a mixed pallet through the License plate receiving method on the mobile device, I mentioned that once the receiving and put away is complete, the next step would be to update the product receipt document. With that, the purchase order status is updated to Received and all relevant GL postings are done.

Posting a product receipt for a load can be done from two places in the new warehouse management module:

• For a selected load, whether that is from the All loads list page, Load details or from the Load planning workbench. This will execute the posting right away
• For 1 or more loads, running as a batch job in the background, using the periodic operation "Update product receipts"

The actual business flow is more or less the same regardless of where you launch the update from, and I am going to describe it below, also doing a small demonstration of the forms and data that are relevant.

One thing that I specifically want to call out in this blog post is a piece of functionality related to receiving ASN documents, namely the receiving exceptions for items missing from ASN.

Preparation

So, i guess it's clear that the first step for us to look into the product receipt process is to get a load created and corresponding work created/executed for it. This is described in my post about importing an ASN and using License plate receiving to register their arrival and complete the put-away, so I will start here by just briefly listing the data I am going to work with in this demo:

• A load with 2 purchase orders on it, with shipping carrier specified as JB Hunt:
• PO #1 with 1 line for item 000148_202, qty = 2 PL (150 ea), WH = 42
• PO #2 with 1 line for item 000147_202, qty = 1 PL (100 ea), WH = 42
• A packing structure for this load (based on ASN received from the vendor)
• 1 pallet with License plate LP2POs006
• 75 ea of 000148_202
• 100 ea of 000147_202
• 1 pallet with License plate LPMissASN001
• 75 ea of 000148_202
• Work is created and executed for LP2POs006 through License plate receiving. 
• LPMissASN001 has not been received, as it did not actually arrive on the truck.

What the last line essentially means is that the vendor planned to and believes he sent us the entire order (thus it is in the ASN document), but in reality, one of the pallets is missing. So somebody needs to get notified about this exceptional situation and act on it, ensuring we do not get billed for the missing goods.

In order to showcase the receiving exception related to items missing from load as compared to the ASN I have also specified the corresponding work exception code in the Warehouse management parameters, as shown below:

Flow description

Warehouse management parameters

The "Update product receipts" menu item is located under Warehouse management \ Periodic, and opens into a dialog, where you can select the loads you want to post product receipts for. The criteria could be, for example, the shipping carrier bringing in the loads. If you know that "JB Hunt" delivers before lunch, we can try posting product receipts for their deliveries at, say, 2 pm.

Note

The batch job flow is per my understanding going to be used more often, so this is what I am going to describe in this post. Manual posting is pretty much identical, with 1 difference mentioned below.

Once you confirm the processing, the job will be added to the queue on the batch server, and will be executed based on the recurrence you have selected on the Batch tab page.
For this demo I have not enabled it to run in the batch, so the execution happens right away.

Here's an attempt at capturing what is going to happen with the selected loads when you schedule the product receipt update for them:

• Loop through all the selected loads
• If Load has not yet been Received
• check if the load has been ship confirmed, or the state of the related route (TMS functionality) if a load is part of a route. If it is not confirmed
• ship confirm the load and all related loads that need to be confirmed at the same time (because they are on the same route)
• if at least one of these loads cannot be ship confirmed, none of the loads will be confirmed. A number of things are checked here, but they are part of the transportation management flow, which is not the focus of this post, so I will omit describing them
• As a result, the status of the load changes to Shipped 
• check the document status of the purchase orders related to the load
• if the purchase order is not confirmed, confirm it.
• This entire step is executed within 1 transaction, while the below steps are part of another transaction. So if you for example cancel the actual product receipt, your loads would stay ship confirmed.
• Loop through the load lines
• Compare the load line to the related ASN item lines, finding discrepancies between the "planned" receiving quantity on the load line and the quantity work was actually created for based on the ASN packing structure. To rephrase, we compare, how much we ask the vendor to deliver in the selected load and how much he actually delivered.
• If a discrepancy is found, create a receiving work exception with exception code selected in Warehouse management parameters \ Code for missing items from ASN

Note: We currently do not record the actual quantity discrepancies, just that there was a difference, as well as the load and order line information

• For each purchase order linked, prepare the order for posting product receipt. All load lines will be posted as part of 1 large update, so if multiple orders exist they will be posted in 1 go, with the same ParmId.
• Actually post the product receipt for all relevant orders. 
• Display the Posting product receipt dialog. Note the product receipt IDs are generated as _#, so you should be able to later identify all product receipt documents posted for a load based on such a condition (if you do not override the number with the actual vendor IDs)
• Select to update only the Registered quantity, as that is what we have received according to the warehouse
• As a result, the status of corresponding purchase orders is updated to Received, or stays Open if some of the quantity was not received in full. 
• Update the load, removing load lines that were not received at all and decreasing quantity on those that were only received partially.
• Update load status to Received
• Update status of all shipments that are part of the load to Received

Manual posting difference

When posting the product receipt manually, the button to post is actually disabled until the purchase orders in the load are all in Confirmed status.

Demonstration

Navigate to Warehouse management \ Periodic \ Update product receipts, and configure the criteria for updating all loads delivered by JB Hunt that have not been Received yet. 

Update product receipt selection criteria

When you confirm the update, the above flow is going to execute, confirming the inbound shipment and displaying the product receipt posting dialog with both purchases shown. Notice the product receipt numbers assigned, and that only the registered quantity is updated. Confirm the processing.

Product receipt posting dialog

Once the update is complete, we can go back and check on the load. As you can see, the Load Status has changed to Received, and the quantity on the first load line has been decreased to match what we actually received.

Received load information

At the same time a receiving work exception has been logged in the system, pointing to a discrepancy of type "Missing item from ASN", as shown below:

Work exceptions log

If you now take a look at the purchase orders from the All Purchase orders list page, you will see that one of them was fully updated and thus has a status of Received, while the other is still Open and has an expected delivery for the quantity that was missing from the ASN. We'll now need to contact the vendor/carrier and figure out what went wrong with this shipment.

Youtube video walkthrough

As an experiment, I have also recorded the above flow in a screen cast and uploaded it to my Youtube channel. Take a look and let me know what you think. Is that helpful at all? (I take any kind of feedback very well :))

Summary

This post was trying to address two main goals:

• Explain and demonstrate, what happens behind the scenes when posting a product receipt for loads
• Show, how you can set up a receiving exception, that will allow more easily tracking cases where something went wrong and we did not get the goods we were supposed to.

I hope it's more clear now and you'll be able to use AX to the full extent when it comes to inbound ASNs.

Tutorial: Generating shipping labels using the GS1 SSCC-18 barcode format

As a follow up to my previous post about printing labels using the new WHS solution, I wanted to describe an extra feature that is available out of the box in the new Warehouse management solution and allows to generate the license plate shipping label in the format of an 18-digit serial shipping container code (SSCC), which is "used by many companies to identify a logistics unit, which can be any combination of trade items packaged together for storage and/or transport purposes; for example, a case, a pallet or parcel.", as quoted from GS1.

Here is an example of an SSCC-18 barcode (description of each of its components is provided here):

Configuring the SSCC in Dynamics AX

Let's take each part of the code above and see where we set it up in Dynamics AX:

• Application Identifier for SSCC is always 00 and is therefore also hard-coded in the X++ code
• Extension Digit in AX is used to specify the type of the logistics unit - pallet, case, etc. This is set up in the Unit sequence groups by specifying a digit 1-9 in the field License plate packing type, and is during work execution retrieved based on the item being processed. If no item is specified, Extension Digit will be set to 0.

Note

There is currently no validation implemented for this field, meaning you can type in any integer. Typing in a value that is more than 1 digit will obviously compromise your SSCC integrity

Here is how I have set up my Unit sequence group "Ea PL" for this demonstration:

• GS1 company prefix is set up in the Warehouse management parameters and thus will be unique per company in Dynamics AX.

Note

There is currently no validation implemented for this field, meaning you can type in any string with a length of 8 or less characters. The requirement is of course that you only type in numerical data. Note also that according to the standard, the company prefix can be as large as 10 digits, which is not supported in AX right now, but is rather easy to customize if necessary.

Here is how I have set up the GS1 company prefix for this demonstration:

• Serial reference is currently only set up to be generated based on a number sequence for License plate IDs. Many people request that the Container ID (used as part of manual packing or containerization flows) is used instead, but that's as of right now not possible and requires a customization. 

Note

There is currently no validation implemented to ensure the length of the generated number is within the required 6-9 digits, or that the generated string actually only consists of digits. It is therefore your responsibility to ensure the corresponding number sequence segments are set up correctly, ensuring that the combined length of GS1 company prefix and generated license plate ID is always 16 digits.

Here is how I have set up the License Plate ID number sequence for this demonstration:

• The check digit is calculated automatically based on the generated ID and appended as the last symbol. No extra setup is required for this.

Mobile device menu item configuration

In order for all of the above to work, we need to make sure that the license plate is generated automatically by selecting the "Generate LP" check-box on the corresponding mobile device menu item.

Here is how I have set up the menu item for executing sales picking work for this demonstration:

OK, that's pretty much it. Now every time that a new target license plate is generated as part of picking sales orders, it will be in the format of a serial shipping container code. All you need to do is actually configure the work template to print the license plates, as shown in the above-mentioned post about printing labels.

The same will apply not only to sales picking work, but to many other types of mobile device flows, which as part of the flow generate a new license plate, both inbound and outbound.

Actual demonstration

To start off, I have configured the work template for sales orders to include an additional step to print the label, as shown on the screenshot below:

Next, I created a new sales order for 75 ea of item 000148_202, where a unit conversion is set up so that 1 PL = 75 ea. The order line is to be dispatched from warehouse 42, as shown below:

I reserve the line (you need to ensure there is sufficient on-hand inventory available for item 000148_202, and it is in a location, which is part of your location directives setup for Sales order picking), and release the order to warehouse, which, in turn, based on my wave template, creates a new wave and processes it, resulting in the creation of picking work that is shown on the image below:

As you can see, the Print steps is there, and the work lines are for 1 PL, which means that when printing the label, PL will be used to determine the value of the Extension digit.

Since the actual printing is already described in my previous post, I will use a different approach this time and will not setup the document routing at all. This will generate the label for me, but won't actually print it.

OK, so now let's proceed and actually execute the work. At the Pick screen, you will see the generated license plate ID, and can confirm that the format is right.

Note

The field is currently editable, so the work user can accidentally overwrite the generated value. This might improve in future AX releases to prevent human error.

Hotfix

I am afraid the contents of the generated ID are a bit off at the moment. If you type in the below SSCC code into a check digit calculator (e.g., here), you will see that the calculator produces a different check digit as compared to Dynamics AX. This is a product issue Microsoft is aware of, and it has been hot-fixed since RTM. The KB article number is 3001157 (should be available on LCS soon).

Once the Pick line is executed, the printing itself will happen, and will create a record in the License plate labels table. Go ahead and complete the Put, and let's review the label information that was persisted by navigating to Warehouse management \ Inquiries \ License plate labels. I took the liberty of hiding the uninteresting fields from the view.

As you can see, all the vital information about the license plate label, as well as the context in which this label was generated are stored, and can be used in the future.

You can, for example, reprint the label, if necessary, using a mobile device menu item with an Activity Code = Reprint label. 

That's it for today! Stay tuned for more.