March Blog Series: Connectivity
Insights from: Kumar Nishat (Fullscope Software Developer)
The capability to print labels directly from Microsoft Dynamics AX was introduced in Dynamics AX 2012 R3 as part of the new Warehouse management module. Prior to R3, users typically created integrations with popular external systems such as Bartender and Loftware for all label related functionalities.
This blog explains some technical aspects of the label printing capability and provides a general list of steps to leverage it to other processes.
How it works:
Notice the project WHS.DeviceCom under Visual Studio Projects ->C Sharp Projects. AX uses the static method SendStringToPrinter(string printerName, string Value) to send a string containing raw ZPL code directly to the printer. Zebra Programming Language (ZPL) is a page description language from Zebra Technologies and is a common format for labels.
Dynamics AX allows the user to save this ZPL code and to insert placeholders for fields in the code via context menus. When the transaction is processed, the placeholders in the ZPL code are replaced with the corresponding field name and field values and sent to the printer directly. It is not possible to preview the label in AX at this time. Typically, any user with a ZPL compatible printer will have access to the label designing software and ZPL code can be generated from these programs and copied over to AX. There is an online conversion engine (http://labelary.com/) which lets the user preview the design based on the raw ZPL code. The example shown above is from the labelary website. Note that a specific design is valid only for a label with certain specifications (label length, label width, print density of printer). The example above is for a label 4''x6'' label and a printer with print density 8dpmm.
Extending to other transactions:
The following steps give a very brief outline of modifications to extend label printing to other transactions:
Step 1: Create a table and form for storing the ZPL code
Create a simple table with at least three fields – Layout identification (EDT WHSLayoutId), description and a field for storing the ZPL code (EDT WHSZPL). Some clients may need labels for different kinds of transactions, labels of different sizes and the need to direct labels to different printers. In that case, it'll help to have additional fields for storing label length, label width and print density.
Check out table and form WHSDocumentRoutingLayout for more details. The context menu is generated by first creating a RecordSortedList based on table TmpSysTableField. This table is capable of storing field level information from any given table. The next step is to populate the list from the particular table crucial to the transaction in question which in case of document routing is the WHSLicensePlateLabel. Class PopupMenu handles the actual generation of the context menu by using the list generated previously.
Step 2: Create a class to handle the actual label-printing
Create a class that will be eventually used somewhere along the transaction processing to print the labels. Within this class the temp table TmpSysTableField will be populated again in the same way. Then the ZPL code will search for field placeholders, replacing each one with the corresponding field name and field value available from the transactions. The final transformed ZPL code is then sent to the printer: Microsoft.Dynamics.AX.WHS.DeviceCom.Printer:SendStringToPrinter(printer name, transformed ZPL). Check out class WHSDocuementRouting for more details.
Notice that the static method needs a printer name as well and this can be done by using a lookup similar to WHSDocumentRoutingLine::lookupPrinters(FormStringControl _ctrl).