There are two ways to learn how Dynamics AX is working. Users can do courses, read manuals, self-training, “try and fail”, blogs etc. Professionals can also read code. Each time Microsoft is releasing a new version I try to read the code for better understanding new features and possibilities.

I then often find traces of functionality that exists, but that Microsoft never took the “last mile” and created the front-end functionality. This code is often made by the best developers in the industry. And it is open and free to use for partners and customers.

One of these hidden jewels are the status arrived.

To explain what this is, we need to understand how the real physical logistics flow is translated and viewed in Dynamics AX.

Dynamics AX tries to mirror this processes with transactions, and reflect each status as both transactions and as inventory statuses. Take a look at the following Dynamics AX On-hand screen.

What I suggest, is that they should start using the Arrived status more. Because it can give some very important information. When an order processor (like Susan) take a look at the current on-hand, because she have a customer on the phone, she can see that the items has arrived, and it is probably just a few hours before the items are available in stock, and ready to be picked.

It also tells the warehouse manager how much goods has arrived to the warehouse, and how he should prioritize his workforce to do quality control and put-away.

It answers one of the most basic logistics questions: Has the items arrived yet?

You may now ask the question: Why have we not heard about this, and why isn’t we using this more?

There is a catch. In order to use the Arrived status, you need to use pallets, and pallet transports. Microsoft is describing the process in this blog. But it is actually quite few that uses pallets in their warehouses. Most SMB companies have warehouses, but just places the goods in cartons into the warehouse.

In the following section I would like to tell you how to go around this, so that you actually can use the arrived status without using pallets. It is just a small modification needed, and it will make sure that the “forgotten jewel” again can shine.

We do this, by making some small changes to how the arrival journal is working. When the user adds a record in the arrival journal we want the inventory transactions to reflect this.

This will be reflected in the on-hand screen as been before.

Here is how I made this possible.

Warning ! The following section is for developers only J, and are created for Dynamics AX 2012 R2.

1.First I need a function for summing up arrived transactions.

2.Create some static methods that controls the arrived status based on WMSJournalTrans.

3.Create event handlers on insert, update and delete methods on the table WMSJournalTrans.

4.A small correction to std. AX is also needed, so that arrived transactions can be seen from the arrival overview.

This concludes the adjustment to make status arrived work for companies that don’t do pallets.

Take care, and happy daxing.

In Dynamics AX 2012 (and 2009) we have the possibility to add Cue’s to the role center.

However, sometimes we would like to have Cue’s that reflect a dynamic time dimension. This is like: Orders today, Orders yesterday etc.

What we then can do is to use query values as today(), day(-1), LessThanDate(), RateRage() etc.

Like in the following example fetching sales order lines created today. Here I use the greaterThanDate(-1). Pay attention to the extra parentheses to make it work.

In AX 2012 you will find many such «dynamic» data query values, and you can find them in the class SysQueryRangeUtil.

Then here is the developers trick: Create your own methods to get the query range you need.

I have created my self some nice methods for getting a query rage for ThisWeek() and PrevWeek()

Or here is a way if you have a CreateDateTime field, like, and want all orders created today:

So now it is easy to create Role center cues with data like:

– Number of Sales order with value so far today/yesterday/this week/this month etc

Try it, and happy Daxing

I have several customers with retail stores.  So I wanted to create some PDA applications that can be used in the stores, that focuses on supply chain.  It actually turned out to be a small module in the PDA solution.

The retail menu is optimized for scenario’s where a central distribution center is doing automatic replenishment using transfer orders of the stores, and the stores are within the same company as the central distribution center.

In scenarios where the stores is buying directly from vendors, or intercompany transactions is used, then the purchase and arrival menus can be used.

Create transfer order

The create transfer order is all about creating transfer orders from a central distribution warehouse or from other stores/warehouses. The screen is very easy-to-use, and focuses on the core process.

To warehouse: This is the destination warehouse (or store), and is normally auto filled based on the current user.

From warehouse: This is the Source warehouse (or store), and is normally auto filled based what is the main central warehouse.

Barcode: Accepts item barcodes or EAN128 codes.
The magnifier button will open the items details for this item/barcode.

Quantity: Accepts Quantity or quantity from item barcodes or GS1-128/EAN128 codes. The field on the left show how many units are already ordered, and (hopefully) on it way. Before ordering, check this field to prevent double ordering.

The buttons in the bottom will be either add or create, depending on of there already exists an open and untouched transfer order.

Create/Pick transfer order

The create/pick transfer order is an optimization of the create transfer order. But this process will also physically pick the items while you are creating the transfer. This form is particularly useful if you want to create a transfer order based on physical items you have in the store or at the central warehouse. One of this processes is the end-of-season distribution. Returning items to central warehouse, or sending items to other stores.

To warehouse: This is the destination warehouse (or store), and is normally auto filled based on the current user.

From warehouse: This is the Source warehouse (or store), and is normally auto filled based what is the main central warehouse.

Barcode: Accepts item barcodes or EAN128 codes. The magnifier button will open the items details for this item/barcode.

Location: Scan the location where the lines is being picked from.

Quantity: Accepts Quantity or quantity from item barcodes or GS1-128/EAN128 codes.

The buttons in the bottom will be either add or create, depending on of there already exists an open and untouched transfer order.

1.3. Add transfer lines

If you already have a transfer order, and just wants to add lines to a specific transfer order, then use this function.

This form behaves just like the two previous, but here the user can specifically select the transfer order. The lookup button will only show already open transfer orders that fill the criteria of “To”-, and “From”- warehouse.

1.4. Inquire item barcode

For retailers it is important to quickly get information that is different then what a warehouse worker needs.

The sales price presented here is the price including VAT. So this is the price that the customer will get in the POS.

The minimum, is the minimum on-hand, and is used for replenishment. Adjusting this can automatically create transfer orders through the master planning. The magnifier button will show a lot of information on the scanned item. This is KPI that normally is used to set the minimum level of an item at the store. Here is an explanation of the KPI’s/statistics.

Last sales date : The last date there was a sale on this item/barcode from this store/warehouse.

Sales this/last week/month : Calculates some sales statistics on the item barcode from this store/warehouse.

Sales value on-hand : Current physical on-hand * sales price inclusive VAT.

Turnover this/last year : Calculates the turnover ratio for this item in this store/warehouse. The logics for creating this is the same as in standard AX.

Lead time : Getting the lead-time of the item. The logics is the same as standard AX is using in master planning.

Multiple : Show the multiple quantity parameter as defined on the item.

Recommended minimum : This parameter give a minimum advice. The logics is the same as how standard AX is calculating safety journals, but it is rounded up to the nearest multiple quantity.

As shown in the figure, the Print-button will print retail shelf labels, and these can be setup as wanted in the Columbus BarTender integration.

Count

Counting program for stores is very much the same as counting in a warehouse.

Inquire location

This program is the same as found in the warehouse menu.

My BarTender integration and PDA solution now supports full GS1-128 labels and application identifiers.

Pick, ship and send directly from a PDA. 

Now also available with a overview screen of shipped SSCC :

And use the Microsoft Bing to visualize the Transport route by a single click:

You can even try it out your self, by clicking here.

Take care, and happy Daxing

I wanted my customers to experience the search powers of Dynamics AX 2012 and Microsoft SQL, and decided to create a very small generic tool for finding items and products.

Suppose a user wishes to find an item, and it does not know its item number but knows few word of description and also has a small information about class, default supplier, location etc……

He can enter this info and at very next moment he would see the list displaying all the items having the various values similar to information he just entered and then he can select the required item out of it easily.

In standard AX 2012 the item lookup looks like this:

When installing the new item lookup (from my kitting solution), the lookup changes to this:

Since the lookup is attached to the itemId extended data types, this works everywhere you have items.

In the lookup form the user can fill inn filter criteria, like item name, colors, barcode, vendors/groups etc.  I can even use the product categories like this :

I see here in the top, that selecting category Accessories, and selected to only show those where I have on-hand, results in 27 records. 

If I then click on the tab “search results”, I see the items (With on-hand values)

And just to “show of” I have sorted the list with the Physical quantity descending , because it is a outer-joined database view.

All filters work “side-by-side” and together.  So I can ask for products like “Find a green phone we have on stock at warehouse 22”.

The way I do this, is to build up the query in the form, based on the selected filter criteria.

And then just execute the query in the form.  (There are off-cause much more to it, but we can take this in private sessions)

With this very small tool the searching for products will be much easier for our customers.  Remembering item numbers is so 90’s.

Happy Daxing

At a customer implementing my PDA and BarTender add-ons, are currently doing a lot of testing.  The following picture shows how one of the implementation consultants are testing this out in “real-life” :

All is barcoded and the barcodes is available in Dynamics AX. 

Happy Daxing.

In standard AX 2012 it is not possible to have negative discounts.

But it is a very small change to actually make it work.  Just change the extended data type DiscPct.

But why would any allow negative discounts ?

In many industries they have specialized on full ballet/box delivery.  If a customer needs less than a pallet/box, then a extra charge should be put on the invoice.  Then it is possible to create a line discount that increases the line amount.

But there are some aspects that you should evaluate before we start using this approach:

1. It is normally much better to use charges, but auto charges is dependent on items or quantity, so then this must be a customization.  Misc charges also have the effect to better control the ledger posting.

2. When using negative discounts, then ordinary discounts will override this.  So you are then suddenly stuck, because the real line discount is lower than the negative discount.  But this can be compensated by making sure that the real discount only kicks in in a specified quantity range. 

My recommendation is to rather extend/customize the auto charge functionality in AX 2012, and make it possible to be dependable on customer, item AND quantity :

Maybe an ide for next release of Dynamics AX ?

At as Dynamics AX consultant I get the chance to work with many customers, and see good idea’s in action. At one particular customer in Norway, that are implementing Dynamics AX 2012 we have been asked to replicate some functionality from their old system.

A normal response from a Dynamics AX consultant would be that with Dynamics AX we do things differently. We use role-centers, fact boxes, fast-tabs, buttons, go-to-main table, and Excel to give a complete picture.

But this customer was persistent, and still ordered a customization. The task felt on my shoulders, and the more I do the development, the more I really see the benefits. It saves time, and gives a much easier 360 degree view.

I wanted to share these ideas with you,; this called product inquiries, and I have used the “copy with pride” technique from other std. Dynamics AX forms J So the “footprint” in standard AX is Zero.

It all starts with the following screen:

By typing in an item, the user will get some key information, like name description etc. But also some information like on-hand, vendor, external item ID, most common locations and picture

In the tab-grid part, you see some of the information, where you normally would have to click on buttons or filter on. The tab-page here shows trade-agreements with vendors, prices, lead time etc.

On the tab purchase lines we see ONLY the open purchase lines, marking, and confirmed delivery dates.

The Sales lines shows open sales lines:

The inventory transactions, shows ONLY transactions that has affected the physical on hand. Meaning Sold, deduced, picked, purchased, received and registered transactions:

Customer invoice lines, will show all commercial transactions, related to the item:

The Posted vendor invoice lines, shows the following:

The statistics, will show statistics per month:

If wanted, the user can them self also key in the start and end date to get statistics on other intervals. The turnover ratio is also calculated.

For BOM/Kits we also have the following:

In the coming days, also price calculations per customer will be available, and then it can also be used for finding out if a specific customer should get a discount or not J

It is not revolutionary to make such screens, but I think I managed to get it working with a good performance. The number of datasources involved is large. So I have used several techniques, like caching, maps etc to get the acceptable performance.

And on the op, I have “stolen” many of the same buttons as the released products form, so these are also working.

I have also used the “Grid view” to get a very fast overview:

The conclusion is therefore to actually listen to our customers. They very often have ton’s of experience and are willing to share their knowledge.  And we as Dynamics AX consultant can help our customers to become more successful. 

Happy Daxing.

In Dynamics AX 2012(and 2009) it is possible to have delivery addresses on both the sales order header, and on the sales order line.  But it is also possible to disable the use of delivery addresses per sales order line, by disable the configuration key, like this:

If you disable this, then you will not have delivery addresses per delivery sales line.

But is you do this, and you also do do consolidated delivery/picking, then there is another issue that will appear.  The picking routes will miss a delivery address. 

In std. AX 2012 you will also see that the customer name is missing from a consolidated picking route.  I understand why, and the reason is that each picking route is unique per delivery address.

But most companies implementing AX 2012 still wants to have a picking route with customer name and delivery address, and with a few lines of code it is actually possible to get this.  For those of you that like X++, here is the needed code to get delivery address and customer name on a consolidated picking route:

Take care (kim) and happy Daxing.

When working with output orders I see some customer struggling with deleting open output orders.

They typically have open output like this:

When deleting it, they get the following error:

The reason for this, it that deleting a output order will also trigger a delete on the inventory order transaction (WMSOrderTrans).  And this delete will again try to delete the original output order(WMSOrder).

To avoid this error is to disable the OCC (Optimistic Concurrency Control) for the WMSOrder, like this :

The issue is reported to Microsoft and is expected to be available in AX 6.2 (AX 2012 R2) or the AX 7.0.

Changing from a paper process to input on a PDA with automatic wireless transmission to the main computer can dramatically boost worker productivity. Any process that involves collecting data using paper documents is potentially a candidate for a mobile solution to reduce data entry errors and speed up the reporting process.

In my crusade to simplify and PDA enable AX 2012 functionallity I have taken a look into production, and created some easy to use PDA forms.

Most manufactured items move through the production process sequentially. The sequence starts when a production order is created and ends when the product is ready for shipment. In Microsoft Dynamics AX, each sequential step is associated with a specific status. The status reflects where the item is in the production life cycle.

You can monitor the activities in each step of the production and move the production to the next status when you are ready. If you omit intervening steps when you change the status, the system automatically runs the necessary missed steps for you.

· Create – Status of the production order when it is created.
· Estimate – Status of the production order after you run a material and cost estimation.
· Scheduled – Status after you run operation or job scheduling.
· Release – Status when the production order is scheduled and has been released to production.
· Start – Status of the production order when production starts.
· Report as finished – Status of the production order when production is finished and ready for final action.
· End – Status of the production order after final costs have been applied, the item is complete, and the order is no longer active.

The PDA production covers the basic tasks for a production order centered on material and hour consumption. The PDA program will make it easier to register these transactions in environments where ordinary PC cannot operate.

The idea of the PDA production is to simplify the entry of consumption, and to report statuses. The main functionality is therefore centered on the following functions.

Start production
Start the production. This will also create the picking journal that will be used in production picking. Often the reservation of BOM-line is done when starting the production.
Report BOM Lines
Report material consumption according to the BOM picking journal.
Report Hours
Report hours on jobs and operations.
Report as Finished
Report finished goods as finished into a put-away location.
End production
End the production, and perform costing. Normally this is done in back-office.

The PDA production do not have any “create production”, because creating productions, BOM, delivery date and soon, is regarded as a back office function, and it requires more detailed information about sourcing to be sure that this is done correctly.

So the PDA production focuses on what is actually taken place on the production floor.

Start production

After a production order is started, you can post costs against the order. The system can be configured to estimate material and route costs that are allocated to the order when the order is started. This allocation is known as pre-flushing or auto consumption. You can manually allocate material to the order by creating picking list journals. You can also manually allocate labor and other route costs to the order. If you are using operations scheduling, you can allocate these costs by creating a route card journal. If you are using job scheduling, you can allocate these costs by creating a job card journal.

The start production will therefore let you perform this step.
Barcode:
Accepts item barcodes or EAN128 codes.
Lookup is filtered to only show item barcodes that has an open production order associated. View details will open the item information form. If only one production is found on the specific barcode, then the production will be auto-filled in.
Production:
This field accepts production numbers as input. Lookup is filtered to only show productions that is an open. View details will open a list view that shows the BOM-lines associated to the production.
Start:
Specify how many that should be started. This affects the creation of production picking lists and route/job cards. In the right field, show the remaining quantity to be started (scheduled quantity – started quantity)
From – To:
If only a subset of operations should be started, then specify the From-To operations here.
Post route card now:
Select the check box to automatically post the created route journal.
Post picking list now:
Select the check box to automatically post item consumption when the production is started. The program posts transactions in the picking list journal to the ledger. This pre-flushed the BOM consumption.
Print labels:
The print labels, will print item labels, when starting the production. This can be a good thing, especially, because the barcodes in on the labels can be placed on the product as they are being produced. The labels that will be used are labels associated with the production table in the Columbus BTI/Bartender module.

When done, press the start button to start the production order.

Report item consumption

Report item consumption is picking material to the production order. It is normally used to pick from the warehouse at the specified locations.

The first screen is where the production is identified. If labels where printed in the start production form, it is simply to just scan the production number. The production field also accepts scanning Item barcodes IF there are only one single open production order on the item barcode.

If there are only one open picking journal, then the PDA will fetch that picking journal identifier. The item number is just the item number of the produced item.

The rest of the fields are information fields showing item name, delivery reminder of the production, delivery date, start date and current status.

The next screen will show all the locations that should be visited to pick the picking journal lines. The PDA operator scans the location (Or push the “pick” checkmark) to pick the specified line. Then the third screen will appear where the operator can confirm the item barcode and even change inventory dimensions like location, serial, batch etc.

When the user clicks on “apply” the line is picked from the inventory, and consumed in the production order.

The last step is to finish the picking that will post the production picking journal. The finish of the production picking journal will change the status of the picked items to “Deduced”.

Report resources/Hours

The Columbus PDA can be used to report hour consumption in the production. Use of the PDA report resources is the same as using a route journal, and will report process and setup hours per operation.

The PDA screens consists of 3 screens, but if Job-ID scanning is used, than only 2 PDA screens is required.

In the first screen the user can identify what production order that we works on. The user can here also enter the operation ID, if this is known. The user can also scan the Job identifier directly to report hours. Dynamics AX 2012 do have out-of-the-box support for printing barcodes directly on the job card, as shown here:

If the user do not specify any operation or job-id, then the select operation screen will show when pressing start.

In the select operation, only the remaining operations will be shown, and the user can either enter the operation number, or click on the “pick” field.

In the third screen, the user can enter process hours, setup hours. The user can also report number of good and error units on this operation. If an operation is reported with error, then the error cause can be entered. If the operation is complete, then it is also possible to checkmark this. This will have an effect on resource reservations, and also the progress reporting. In the top, the user can also select another worker, if several workers uses the same PDA.

The registration screen is have a column showing the remaining hours/quantity in the gray fields, as shown here.

When posting the hours, a production route journal will be created and posted. In this way, the reported hours are close to real time. To correct any wrong postings, just create a journal manually, and reverse the transactions.

The PDA resource reporting is using exactly the same validations as the production journal.

Report as finished

As the production progresses, items are finished. Then the PDA operator can perform a report as finished. The report as finished is therefore a put-away process. It is possible to also use the PDA arrival functionality, but the process shown here is optimized for production.

First the PDA operator identifies the production either by scanning the item barcode or production id. The item barcode field accepts production numbers. Then the operator enters the number of units to report as finished. The PDA will then ask for additional inventory dimensions, like location, pallet batch etc, depending on what is mandatory of the item to specify. The PDA will also suggest a put-away location.

Confirm the put away by clicking “apply”, and the items are then “registered” into the location.

The user can also report number of errors/failed products. And even limit the “from-to” operations, to just report as finished selected operation. The end job, means that all remaining jobs should be marked as ended.

The operator can also print labels here that can be useful if tracking dimensions like batch or serial numbers are used in the production process.

End production

The end production is the final step in the production process, and changes the receipt and issue transactions to “purchased/sold”. The costing details must still be fetched from the rich AX 2012 production form, but the actual ending can be done with the PDA.

The Production end form on the PDA is very simple. It contains two input fields, and some quantity status fields.

If the user scans the item barcode, then the available productions order lookup will be filtered based on this. The lookup is also filtered on the current warehouse.

If there only exists one “reported as finished” production order, then this will automatically be select.

To end the production, just click post, and the production is ended.

Conclusion

With the Columbus PDA, it is possible to PDA enable your production, and take benefit of the realtime production process.  A lot of readers of this blog has asked if this PDA solution is available, and the answer to this is yes, but only for AX 2012 RTM and Feature pack.  Just contact us

My next PDA project will be …….. project .  Here is a silent preview:

Stay tuned, and happy DAXing.

In my previous post I wrote about compressing standard location, movement and counting into a single process in Dynamics AX 2012. Today I wanted to show that the my PDA solution also can save time in purchase and sales scenario’s. If there is one thing we all like so save, it is time. So to save time, some PDA features has been implemented to speed up processes, but still maintaining on hands accurately. So this post is about making life easier for those companies, that don’t need or want to have more advanced WMS capabilities and features.

1. Create a sales order, and pick it in the same operation.

This scenario is typically used in a retail scenario, where a store employee walks together with the customer, and creating sales order AND pick it while they are collecting the items. Then the last step is just to invoice the order. In this scenario, it means that the locations are updated in real-time.

2. Create a purchase order, and register it in the same operation.

This scenario is more common than you think. People is ordering goods, but they don’t create a purchase order. Not exactly best practice, but is surely happens. Here the receiver can build up and receive the goods in one single operation. Scan item barcode, specify location and quantity, and the purchase order is created, and placed into the warehouse.

In the solution there are off course the possibilities for other scenario’s, as can be seen in the Sales and Purchase menus.

Happy Daxing, and my next post will cover the new features for production on PDA. Here is a silent preview:

Kinder Surprise, (or Kinder Egg’s that is also called) is something that most kids loves. Why ? It contains 3 positive elements, and that are (normally) a surprise, chocolate and a toy.

I wanted to create a Kinder Egg function on the PDA, that simplifies 3 tasks into one task. The tasks of my choice was:

1. Set the default issue/receipt warehouse location for an item,

2. Move all on hand of this item into the new location.

3. Adjust/count the new location.

So I created the following PDA screen:

Here the PDA asks for an item barcode, and then the user can scan the new default location, and select if the system should move ALL on-hand to the new location. After the movement has been done, then the PDA will adjust the final quantity in this location. In the background the PDA used standard AX journals.

For smaller companies this truly save time. Just imagine the time you would have to spend to do this using the item warehouse setup, transfer journal and counting journal.

That is Kinder Egg

When receiving products from purchase, production or any other receipt, then most companies wants the system to present a location where the items should be placed.

Dynamics AX 2012 have the capability to find a available location in the warehouse, but this algorithm is based on that the receipt do have a pallet.

If you want to examine the standard X++ code for this, then take a look at Table\WMSPallet.findFreeLocation(..), and just move forward in the code. 

But we who have been working with logistics for many years, know that it is just a fraction of our customers, that are using pallets. Most just have pure SKU’s that they want to store in their warehouse.

So in the PDA, I implemented a way to suggest put-away locations to the warehouse operator, that works without pallets.

The algorithm is simpler than the standard DAX2012 search for pallet location, but the response I get from my customers, it that it is more practical.  So what the code basically do is :

1. If the item/warehouse have a default receipt location, then use this.

2. If the item have a default picking location, then suggest this.

3. Search for a existsing buffer location with onhand, and then suggest this.

4. Seach for a buffer location where the item has been before, but now is empty, then suggest this.

5. Search for any empty and available buffer location.

Here is the code available for the Dynamcis AX community. (it’s not perfect, but ment as an inspiration for all DAX developers that every day is creating value for our customers)

WMSLocationId suggestedWmsLocationId(ItemId _itemId, InventDimId _inventDimId)
{
    InventItemLocation inventItemLocation;
    WMSStoreZoneArea   WMSStoreZoneArea;
    InventDim          parmInventdim = InventDim::find(_inventDimId);
    InventDim          inventDim;
    InventDim          inventDimCriteria;
    InventDimParm      inventDimParm;
    InventSum          inventSum;

    InventSum          inventSum2;
    InventDim          inventDim2;
    WMSLocation        wmsLocation;


    if (parmInventdim.wmsLocation() )
         return parmInventdim.wmsLocationId;

    inventItemLocation = InventItemLocation::findFixedWarehouse(_itemId, _inventDimId);
    if (inventItemLocation)
    {
        //1. use default receipt location on item
        if (inventItemLocation.wmsLocationIdDefaultReceipt)
            return inventItemLocation.wmsLocationIdDefaultReceipt;

        //2. use picking location on item
        if (inventItemLocation.wmsPickingLocation)
            return inventItemLocation.wmsPickingLocation;
    }

    //3. Search for existing buffer locations with item onhand
    inventDimCriteria = parmInventdim;
    inventDimParm.initFromInventDim(inventDimCriteria);
    inventDimParm.wmsLocationIdFlag = false;
    inventDimParm.wmsPalletIdFlag = false;
    inventDimParm.InventBatchIdFlag = false;
    inventDimParm.InventSerialIdFlag = false;

    while select firstonly sum(PhysicalInvent) from inventSum
            group by InventDimId
            where   inventSum.ItemId == _itemId
                &&  inventSum.PhysicalInvent > 0
            #InventDimExistsJoin(InventSum.inventdimid,inventdim,inventDimCriteria, InventDimParm)
            exists join wmsLocation
                where   wmsLocation.InventLocationId        == inventDim.InventLocationId
                    &&  wmsLocation.wmsLocationId           == inventDim.wmsLocationId
                    &&  !wmsLocation.InputBlockingCauseId
                    && (wmsLocation.LocationType            == WMSLocationType::Buffer ||
                        wmsLocation.LocationType            == WMSLocationType::Pick)
    {
        if (inventItemLocation.wMSStoreZoneId) 
            {
                select firstonly WMSStoreZoneArea 
                    where   WMSStoreZoneArea.storeZoneId == inventItemLocation.wMSStoreZoneId
                        &&  WMSStoreZoneArea.storeAreaId == inventSum.inventDim().wmsLocation().storeAreaId;
            
                if (WMSStoreZoneArea)
                    return wmsLocation.wMSLocationId;   
            }
        else
            return inventSum.inventDim().wmsLocationId;
    }
    //4. Search for existing buffer locations where the item has been before, is zero, and no other items
    while select firstonly sum(PhysicalInvent) from inventSum
            group by InventDimId
            where   inventSum.ItemId == _itemId
                &&  inventSum.PhysicalInvent == 0
            #InventDimExistsJoin(InventSum.inventdimid,inventdim,inventDimCriteria, InventDimParm)
            exists join wmsLocation
                where   wmsLocation.InventLocationId        == inventDim.InventLocationId
                    &&  wmsLocation.wmsLocationId           == inventDim.wmsLocationId
                    &&  !wmsLocation.InputBlockingCauseId
                    && (wmsLocation.LocationType            == WMSLocationType::Buffer ||
                        wmsLocation.LocationType            == WMSLocationType::Pick)
    {
        select firstonly sum(PhysicalInvent) from inventSum2
            where   inventSum2.ItemId != _itemId
                &&  inventSum2.PhysicalInvent > 0
                exists join inventDim2
                    where   inventDim2.InventLocationId  == inventSum.inventDim().InventLocationId
                        &&  inventDim2.wmsLocationId     == inventSum.inventDim().wmsLocationId;
        
        if (inventSum2.PhysicalInvent == 0)
        {    
            if (inventItemLocation.wMSStoreZoneId) 
            {
                select firstonly WMSStoreZoneArea 
                    where   WMSStoreZoneArea.storeZoneId == inventItemLocation.wMSStoreZoneId
                        &&  WMSStoreZoneArea.storeAreaId == inventSum.inventDim().wmsLocation().storeAreaId;
            
                if (WMSStoreZoneArea)
                    return wmsLocation.wMSLocationId;   
            }
            else
                return inventSum.inventDim().wMSLocationId;
        }   
    }
    //5. Search for empty and available location in buffer
    while select wmsLocation order by SortCode, wmsLocationId
        where   wmsLocation.InventLocationId == parmInventdim.InventLocationId
            &&  !wmsLocation.InputBlockingCauseId
            && (wmsLocation.LocationType           == WMSLocationType::Buffer ||
                wmsLocation.LocationType           == WMSLocationType::Pick)
        exists join inventDim
            where   inventDim.InventLocationId  == wmsLocation.InventLocationId
                &&  inventDim.wmsLocationId     == wmsLocation.wmsLocationId
        exists join inventSum
            where   inventSum.InventDimId    == inventDim.InventDimId
                &&  inventSum.PhysicalInvent == 0
                &&  inventSum.Ordered        == 0
    {
        select firstonly sum(PhysicalInvent) from inventSum2
            where   inventSum2.ItemId != _itemId
                &&  inventSum2.PhysicalInvent > 0
                exists join inventDim2
                    where   inventDim2.InventLocationId  == wmsLocation.InventLocationId
                        &&  inventDim2.wmsLocationId     == wmsLocation.wmsLocationId;

        if (inventSum2.PhysicalInvent == 0)
        {    
            if (inventItemLocation.wMSStoreZoneId) 
            {
                select firstonly WMSStoreZoneArea 
                    where   WMSStoreZoneArea.storeZoneId == inventItemLocation.wMSStoreZoneId
                        &&  WMSStoreZoneArea.storeAreaId == wmsLocation.storeAreaId;
            
                if (WMSStoreZoneArea)
                    return wmsLocation.wMSLocationId;   
            }
            else
                return wmsLocation.wmsLocationId;
        }    
    }
    return ''; //No locations was found :-(
}

The warehouse menu covers ordinary tasks like counting, moving, inquiry etc.

Count from Journal:
This program will do a controlled count, based on a counting journal that has been generated. This is typical for cycle counting or when doing aisle counting.

Real-time count:
This program can be used when doing ad-hoc counting of locations.

Transfer from Journal:
This program will perform internal transfers between dimensions. Typical when moving from a location to another, but based on a transfer journal.

Real-time transfer:
This program will perform ad-hoc internal transfers between dimensions. Typical when moving from a location to another.

Inquire item barcode:
Inquire information on an item barcode, and to see where the item is located.

Inquire location:
Inquire contents of locations

Count from Journal

Journal counting is the most common way of counting in Dynamics AX. It used a counting journal to confirm the counting. The process therefore starts by creating a counting journal in Dynamics AX. The PDA journal counting cannot add new items to the journal. It can just count the lines that already exist in the journal. Several workers are allowed to work on the same journal.

The count from journal PDA form will change in the process.

Warehouse:
Enter or scan the warehouse. Normally this will be automatically filled on based on usage data.

Journal:
Select or enter the journal number. The lookup will show open journals, that is not blocked and that do have counting lines. The magnifier button will show the lines on the journal. When the journal has been filled in, then the grid will show all locations that needs to be visited.

Location:
Select or scan the location, that exists in the journal/list.

When the location has been entered, the form will change, and instead of showing next location, it will show the item barcodes available on the location.

Barcode:
Select or enter the barcode that should be counted. The lookup button will only show barcodes available on the journal. The magnifier button will show barcode details, like item name, picture and current on hand values.

Counted:
When the barcode is scanned, the cursor will jump to the corresponding line, where the worker can fill in the counted quantity. There exists more items with different tracking dimensions, then look at the dimension view in the bottom screen.

Grid line coloring:
When a line has been counted the line will “jump” to the bottom of the grid, and it will change color. White means that the line has not been counted. Green means that it has been counted with a positive value. Red means that the quantity has been counted away.

Post:
When all lines have been counted, the command button “post” will be visible, and the journal can be posted.

Real-time count

Real time counting is quite similar to journal counting, but the worker does not have a journal.

Warehouse:
Enter or scan the warehouse. Normally this will be automatically filled on based on usage data.

Location:
Select or scan the location. When the location has been entered, it will show the item barcodes available on the location.

Bar code:
Select or enter the barcode that should be counted. The lookup button will show all barcodes available. The magnifier button will show barcode details, like item name, picture and current on and values.

Counted:
When the worker has scanned in a barcode, the cursor will jump down to the lines, where the worker can specify the counted quantity.

If more mandatory dimensions must be specified, then the item dimension specification form will pop up. In the picture to the left, the PDA requires that both pallet ID and Serial must be specified.

Grid color/icon coding
To visualize progress in counting, each line have been added with a small counting symbol.

Grey – The existing line has not been counted
Green – The existing line has been counted
Blue – New line has been counted in
Red – The line has been counted out.

Post:
To commit the counting, the user must click on the post button. It the user just returns without clicking post, the counting will not be posted. All posting in the real-time counting will be posted using a counting journal. The journal is created and posted within the same transaction. The journal lines will also be marked with the worker ID, and posted date/time.

The outbound menu is related to a consolidated delivery. Processes here is related to what happens after the items have been picked is covered.

Merge pick pallets:

Merge pick pallets will combine two pallets into one pallet. This is often done for consolidated deliveries, and typical if the pick pallets actually are boxes or pick baskets.

Stage pick pallets:

Staging is the process of aligning up the delivery pallets at an outbound dock. Also to sort and organize the sequence of how the pallets should be placed in the truck

Load pick pallets:

Loading is done, when placing a pallet into the truck/carrier.

Send shipment:
Sending a shipment corresponds to the send shipment on the standard Dynamics AX form.
Here the worker and also specify if packing slip and bill of lading should be printed.

Merge Pick pallets

Merging of pallets should be done to simplify the staging and loading processes, and to keep a better overview of the contents of the outbound dock.

From Pallet:
Specify the from pallet. When filled in the delivery name and address will be displayed. The lookup will show all pallets on the current warehouse. The magnifier button will show all items that is currently on the pick pallet.

To Pallet:
Specify the destination pallet. All items and picking lines will be moved into the pallet. The lookup will show all pallet at the current warehouse. The magnifier will show all items that currently exists on the destination pallet.

There are a validation of what ”to pallet” that can be used. This is the same validation as standard AX is using, checking that you cannot combine two pallets destined for different shipments, addresses and customers.

Stage pick pallet

To stage a pallet just means that the status of the picking line changes to status “staged”. It is common to stage the pallet several time to different outbound docks. If the truck/carrier is planning to drive into another outbound dock, than all pallets can be “re-staged” to the new outbound dock.

Pallet:
Specify the staging pallet. When filled in the delivery name and address will be displayed. The lookup will show all pallets on the current warehouse. The magnifier button will show all items that is currently on the pick pallet

To location:
Specify the staging location. Normally this is a outbound dock. The lookup will show outbound docks at the current warehouse. The magnifier button will show all items that is currently on the outbound dock.

Stage:
Performs the actual staging

Load pick pallet

Pallet loading should be performed to make sure that all pallets have been correctly loaded into the truck/carrier. To reverse a loading, just stage the pallet again.

Pallet ID
Specify the pallet to load. When filled in the delivery name and address will be displayed. The lookup will show all pallets on the current warehouse that is ready to be loaded. The magnifier button will show all items that is currently on the pick pallet.In addition the working instructions will show the expected shipment that the pallet should be loaded into.

Shipment
Scan or enter the shipment where the pallet is loaded into. The lookup button will show all shipments that is not shipped at the current warehouse. The magnifier button will show all items that is currently loaded into the shipment.

Load:
Load the selected pallet into the shipment.

Send shipment

Send shipment is the last task needed to close the shipment and to generate packing slip and bill-of-lading documents. The task corresponds to doing a ”send shipment” in standard Dynamics AX 2012.

Shipment
Scan or enter the shipment where the pallet is loaded into. The lookup button will show all shipments that is not shipped at the current warehouse. The magnifier button will show all items that is currently loaded into the shipment.

Status:
Display the expedition status of the shipment

Name:
Display the name of the shipment

Loaded pallets:
Display the number of pallets that have been loaded into the shipment

Not loaded:
Displays number of pallets that have not been loaded into the shipment. If this number is larger than zero, then there are pallets that have not been loaded into the shipment yet, and the operator show wait with sending the shipment.

Print BOL:
Print Bill-of-Lading document based on what has been loaded into the shipment. The print management setup for packing slip will be used as the printer.

Packing slip:
Post and print the packing slip. This is only valid for sales orders and transfer orders.

Send:
The send button will send the shipment, and corresponds to the following standard AX function.

The picking menu supports more advanced picking features, and is regarded as advanced WMS features.

Start picking Route:
This menu will start the picking route, and also start the picking process of a route.

Create Pick Pallet:
In a consolidated delivery scenario, the worker can pick goods into pallets or pick baskets. This menu will allow the user to mass generate pick pallets.

Print pallet Label:
When picking is done, then a pallet label many wanted to be reprinted. The Pallet label will contain deliver addresses, and a pallet contents label. Printing will use the BarTender label printout when this is available.

Post picking Route:
When the picking is finished, or the worker must short ship, then the post picking route can be used. This menu will also allow the worker to generate a packing slip for the picked items.

Picking lines that have not been picked, will be cancelled, and can be repacked on the next picking route.

Cancel picking route:
If the picking route must be canceled, ten use this menu. It will cancel the picking route, and it can also unpick any picked lines.

Start picking route – Order pick

The start picking route will look differently depending on if it is a order picking, or if it is a consolidated picking. The main difference is that use of pick pallets. These two scenario’s will be covered separately.

The first scenario is order picking without pick pallets.

Picking route:
The process starts with that the worker enters or scans the picking route ID. The system confirms back with reference and delivery information and address.

The worker then starts the picking process by clicking start.

The next screen that the worker will see is a list of all the locations that he needs to pick goods from.

The worker confirms that he as arrived to a location, by scanning one of the locations specified in the list.

If the locations do not have bar codes, the worker can also click in the “pick” column in the grid.

In the bottom, the worker can se a small picture of the product, item number and other dimensions. The item text will also be visible.

When the worker confirms the location, the followig confirmation screen will pop up.

Here the worker must confirm the item barcode, bu scanning this, and also fill inn any additional dimensions, if this is missing. Like pallet, batch or serial number.

The requested quantity is on the right of the quantity field

When the quantity is filled on, the item quantity dialog will close, and the worker can start on the next picking line.

The last step in the picking process is to post a picking route. This will also generate the packing slip.

Start picking route – consolidated pick

The consolidated pick, is using output orders and shipments to control the process. The Sales order generate output orders, and they are collected in a shipment. It is important to understand the main process of consolidated picking to make sure that the steps are followed. The main thing is the use of pick pallets that must be in place to cover the following process.

The process starts with the picking process, that is quite simular to the order picking, but where the worker places the picket items on to a pick pallet. The next step is to stage the pallet at a outbound dock. Here the pallets will be placed until they are loaded into a truck or a carrier. The last step is to send the shipment, that will be the final delivery to the customer/warehouse. For more information on using output orders and shipments, please refer to standard AX 2012 documentation.

If a consolidated picking route has been generated, then the start picking route screen will change to include pick pallet. In this form a pre-created pick pallet can be selected, or the worker can create a new pick pallet, by clicking on the “new” button”. The select location screen will also have pick pallet as a criteria, where the worker can decide on whish pick pallet the goods should be collected on.

When done, the PDA will return to the ”start picking route”, ready for the next picking route.

Create pick pallet

In a consolidated pick scenario, it is often needed to generate a lot of pick pallets. Often the creation of pick pallets will also produce a label, that the pallet/pick basket can be marked with. Free pallet can look like this, if generated using Columbus BarTender integration.

The PDA used for generating pick pallets have the following fields :

Type: Enter the pallet type. This is a property on the pallet, that controls size and volume. It also controls if this is a pick basket.

Warehouse:Enter a warehouse where the pick pallet is stored.

Location:Enter a location where the pallet is located. Normally this will be a ”empty pallet” location. The default value is fetched from the empty pallet location defined on the warehouse record.

Print:Specify if the label should be printed. If Columbus BarTender integration is installed than this printer will be used.

Quantity:Enter number of pallets that should be generated.

Print pallet label

Normally each pallet is marked with an anonymous pallet label. Often it is wanted to print a new pallet label, that do contain delivery name and addresses. Sometimes a pallet contents label is printed, and placed on the physical pallet after it is wrapped. This makes it easier in the staging are to know what pallet belongs to what shipment/customer etc.

Picking route:
The field picking route is not a mandatory field, and is just used for simplifying the lookup of the pallet ID. If filled in, then only pallets belonging to the specified picking route will appear. The magnifier button will show the lines on the picking route.

Pallet:
Specify pallet ID

Num labels:
Specify number of label(copies) that is wanted.

Print:
Will print the new pallet label

1.5. Post picking route

Post picking route only have a function in when the picking route is order based and NOT consolidated. The post picking route will complete the picking route, and post the packing slip for the picked lines.

Picking route:
Spesify the picking route that is going to be posted, and packing slip updated.

The lookup will only show picking routes that have the expeditionstatus registered to loaded at current warehouse.

Post:
Post the picking route

Cancel picking route

The cancel picking route is a PDA program for cancelling a picking route. All lines will be returned to the original status, and a new picking route must be generated before they can be picked again.

Picking route:
Spesify the picking route that is going to be cancelled.
The lookup will only show picking routes that have the expedition status registered to loaded at current warehouse. The magnifier button will show the lines on the picking route.

Unpick:
If this selection is set, then any picked lines will be unpicked, and the items will be return to the original location.

Cancel:
Cancels the picking route.

The PDA sales menu is created for doing express picking and for creating sales order journals.

Express Pick:
This program will pick sales order lines when picking routes are NOT used. The program expects that the sales order has already been created and are confirmed. The user then scans the item barcodes, and picks, until the sales order is finished.

Create Sales Order:
This program will create a sales journal, and add sales order lines.

Add Sales Lines:
This functionality of this program is similar to the create sales order, but the user can upfront select the sales order. The program can also add lines to ordinary sales orders.

Packing slip update:

The packing slip update will post a packing slip for the picked lines.

Express pick

The express pick form, expects that there already exists a created sales order, that is NOT a journal. Then the user can scan the items, and PICK the lines. When all lines are done, then the sales order can be packing slip updated.

Sales:
Scan or fill in the sales number. The lookup will show all sales orders that has the sales status “backorder”, and will even be filtered on item barcode, if this already have been filled in.

If the sales order do not have any lines to pick, then the sales order will not be accepted.

The magnifier button will show “remaining lines” on the sales order. When all lines have been picked, then the list will not show any lines.

Bar code:
Accepts item barcodes or EAN128 codes.
Lookup is filtered to only show item barcodes that exists on the sales order. View details will open the released products form. The magnifier button will open the items details for this item/barcode.

Dimensions:
The express pick do not support batch and serial numbers.

Quantity:
As soon as the quantity has been filled in, the quantity will be picked. The quantity field accepts EAN128. If a negative quantity is entered, then the picked quantity will be returned.

Packing slip:
The last step is to packing slip update the picked items. This option is only allowed if all lines have been picked. The packing slip will be printed according to the print management setup.

Create Sales Order

The create sales order program will create a sales order journal. The scenario for this program, is that a warehouse worker can go around in the warehouse, and create a sales order, by scanning the products. When done, the worker can return back to a normal AX client, and make the necessary adjustments on price delivery date etc, and send a confirmation to the customer.

The Create Sales order will not pick the goods !

Customer:
Fill inn or select the customer. The lookup will not show customers that are blocked. When customer is filled in, the customer name will be visible on the name field.

Bar Code:
Accepts item barcodes or EAN128 codes. Lookup is not filtered. View details will open the released products form. The magnifier button will open the items details for this item/barcode. When “Bar code” is filled in, then the item name will be visible in the name field.

Dimensions:
The create Sales Order can only be specified with warehouse and location. Other dimensions like pallet, batch and serial must be specified in the picking process, or on a full AX client.

Quantity:
The quantity field accepts EAN128.

Create/Add:
If there already exists an open sales order journal, the sales line will be added. If not, then a new sales order journal will be created.

Add Sales Line

The Add sales line is actually the same PDA form as “Create Sales Order”. The difference is that instead of specifying a customer, the user selects an open sales order. Normal backorder sales orders can also be used.

The magnifier shows open lines related to the sales order. For the other fields, refer to the PDA form “Create Sales Order”.

Packing slip update

The PDA packing slip update will physically update of the sales order, and create a packing slip for the sales lines that have been picked.

Sales order:
Scan or enter the sales order number. The lookup is filtered to only show sales orders that have lines that are picked.

The sales name will be displayed in the Name field.

Document date:
If the lines was picked on another date then today, then the document date can be changed.

Print:
The packing slip printout will be printed using the print management feature in Dynamics AX 2012.

The arrival menu covers the main aspects of doing receipt of goods. The functionality is similar to the arrival journal in Dynamics AX 2012. The arrival menu can therefore be used for several types of receipts, and the following receipts types are possible. Purchase orders, Return sales orders(RMA), Production (report as finished), Transaction, Inventory adjustments, Transfer, Bom journal, Counting, Quarantine order, Transfer order receive and quality order. For details about these transaction types, refer to standard Dynamics AX 2012 help.

The 3 options presented to the user are:

Create Arrival Journal.

This program allows the worker to create an arrival journal, and to start the receipt process.

Registrate Arrival Lines
This program allows the worker to continue the receipt process of an existing arrival journal

Post Product Receipt
This program allows the worker to do a product receipt of an arrival journal. This is only valid for arrival journals containing lines from a purchase order or a transfer order receipt.

Create Arrival Journal

To create a arrival journal and doing the actual registration process.

Type:
The first step is to select the type. Several options are available, and the form will change according to what type is selected. If a Purchase order is selected, then the worker can select vendor and purchase number. If a production is selected, then the worker must select a production order etc.

Account:
The account field is only visible if the type is “Purchase order”, and lets you select the vendor. This is not a mandatory step, but will help to filter and narrow down the possible purchase orders to be selected.

Warehouse:
Select the warehouse where the arrival journal line will be received into. Mainly used to filter and narrow down the possible purchase orders to be selected.

Quarantine:
Select this option, if the quarantine possibilities should be used. This means that the receipt will be posted into a quarantine warehouse, and then the quarantine process will take over.

Number:
Enter of scan the reference number according to the type selected.

Packing slip:
Enter or scan the packing slip number. This number can be used later in the process, when doing product receipt posting.

Create:
When done, the press create to start the arrival registration process.

Registrate Arrival Lines

The registration of arrival lines, is the same as when happens in the arrival journal in Dynamcis AX 2012. First the lines have been create in the create arrival journal form. The form starts by scanning item barcode. The reason for this is that is seldom that any warehouse will receive the same item in two different arrival journals at the same time. It will also make the process of finding the journal ID easier for the PDA program, since most likely the goods is already barcode marked from the vendor/production etc.

To keep track of if a line is completed or not, there is a very small modification in std AX. A new Boolean field on the arrival journal lines has been added, called PDACompleted.  This field is only used in this form, and will not affect and standard AX functionality. Often the warehouse manager will generate a arrival journal, using the arrival overview screen, and create the needed arrival journals. The worker can also manually create arrival journals using the create arrival journal PDA form.

Bar code:
Accepts item barcodes or EAN128 codes.
Lookup is filtered to only show item barcodes that has a open arrival journal associated. View details will open the released products form.

The magnifier button will open the items details for this item/barcode.

Journal and journal line.
If there exists 2 open arrival journal on the same barcode, then the journal will NOT be automatically filled in, and the worker must select the correct one. This also applies, if there are several arrival lines on the same item barcode.

The magnifier button will open the a list form, showing all lines on the arrival journal, and will also show what lines that are complete, and what is still missing.

Warehouse and Location
The warehouse and location can be filled in automatically, if the item do have a standard picking location. Else, the worker must scan in this.

Additional dimensions
If additional dimensions are required(like Pallet ID, Batch ID and Serial ID), then field for these will also appear in the form.

Post Product Receipt

The post product receipt is only valid for registrations where a purchase or a transfer order receipt is done.

Journal:
Scan or enter the journal number, that should be product receipt updated. The lookup is filtered to only show journals that is posted, and that have registered inventory transactions attached. The view details will open the location journal form, filtered as default in Dynamics ax, on Open journals. The worker must therefore most likely filter to show all, and then find the correct journal. The magnifier, will show the lines on the journal.

Purchase:
Normally this field will automatically be filled in when the journal is filled on. If not, then scan or enter the purchase ID. The lookup will filter to only show registered purchase orders.

Packing slip:
Normally this field will be automatically filled in, since the packing slip ID was entered when the worker created the arrival journal. Else, fill in the packing slip.

Post:
When ready to post the journal, then click post. This corresponds to posting receipt on the arrival journal.

The purchase menu covers 2 main aspects. The ability to do express registration, and to create and process purchase orders. The 4 options presented to the user are:

Express registration.
This program allows the worker to perform a purchase line registration into a location.

Create Purchase Journal.
This program allows the worker to create a purchase journal with purchase lines that can later be confirmed and sent to a vendor.

Add Purchase lines.
This program allows the worker add purchase lines to a journal or existing purchase order.

Product Receipt posting.
This program allows the worker to post the product receipt (Purchase Packing slip update)

Express registration

Express registration is a process, where the worker very easily can do a registration of purchase lines into a location. When a purchase line is registered into a location, the quantity will be included in the physical inventory. The physical cost is not posted, and after the registration process is done, and then a product receipt posting must be done, to post the physical cost.

Field and filter explanation:
Bar code:
Accepts item barcodes or EAN128 codes.
Lookup is filtered to only show open purchase lines. If purchase is filled in, then bar code lookup will filter within the purchase.
View details will open the released products form.

The magnifier button will open the items details for this item/barcode.

Purchase:
Accepts confirmed purchase ID’s.

Lookup is filtered to only show open purchase lines with the specified item barcode. If item barcode is not filled in, then purchase lookup will filter on all open purchase orders.

View details will open the purchase order form.
The magnifier button will show all purchase lines in a separate form, showing quantity and remaining quantity.

Warehouse, location, pallet and Batch
Based on enabled storage- and tracking dimensions, the form will request dimensions like warehouse, location, pallet ID or batch number. Only enabled dimensions will show.

Serial numbers are not supported in the express receive.

Posting
When the registration is complete, the worker must press the Add button to perform the registration. When doing this, the form will be emptied, and ready for the next item/scan.

What the Columbus PDA will do when posting a express registration, it to create a single line in the Arrival Journal, and instantly post it. So all express registrations will have an arrival journal associated to the posting. The name of the arrival journal will be “Express registration, Purchase %1, Date %2”.

Other design considerations
The reason why the item barcode is the first registration is because it is most likely only the product that does have a barcode attached. But to change the scanning sequence, is a small change that can be done upon request.

Setup Considerations
The express receive will use the default arrival journal. It is therefore important to create a arrival journal name, that do NOT validate pick, buffer and transports. Set up the default arrival journal like this:

Create purchase journal

The create purchase journal is a small form, that allows the worker to build up purchase journals, based on scanning item barcodes. The process starts either by scanning/selecting vendor or by scanning item barcode. The scenario is that this form can be used by a warehouse working that walks around in a warehouse or a store, and orders refills from the primary vendor. After all scanning is done, the worker returns to a PC, and changes the purchase order from journal to order, and then completes the normal order processing of the purchase order.

Field and filter explanation:

Vendor:
Select or enter the vendor ID. The system will automatically fill inn the vendor name in the field below.

Lookup on the vendor only filtering away blocked vendors.

View details will bring up the vendor details.

In the vendor field, it is also allowed to scan item barcode. The PDA, will then fill automatically fill in the item barcode, and the primary vendor.

Bar code:
Accepts item barcodes or EAN128 codes.
Lookup is filtered to only show item barcodes that has the selected vendor as primary vendor. If not vendor is filled in, then it will show all items bar codes.

View details will open the released products form.

The magnifier button will open the items details for this item/barcode.

The item name will also be displayed when the bar code is filled in.

Warehouse
Warehouse will be automatically filled in, based on the primary and current warehouse, selected in the PDA setup.

Quantity
The quantity will accept EAN 128. If the item barcode is associated with a quantity, then this will be used.

Open orders
The open orders field is used to show other existing open purchase lines that exists for the item. This field is used to help the worker determine if he should check more before ordering.

This form have both a “create” and a “add” function, because if there already exists an open purchase journal to the same vendor, then the form will add the item barcode to the existing purchase order. If the item barcode already exists on the purchase journal, then the quantity will just increase. Else the purchase line and purchase journal will be created.

Add purchase line

The add purchase line is actually the same screen as the create purchase journal screen.

Refer to the previous form for explanation of the field. The main difference is that the vendor field has been replaced with a purchase ID field. The other difference is that it is possible to add lines to a normal purchase order on this screen. Also a magnifier button for seeing the contents of the purchase order has been added. The idea here is that the form can be used to register/create purchase orders in the receive department. One scenario could be registration of blind receipts, where goods has been ordered without having a valid purchase order. Remember to validate and confirm the purchase order as done in the normal order processing after the registration is completed.

Product receipt posting

Posting of product receipt is an important process in Dynamics AX 2012. The process will generate a product receipt formletter, and will also change the inventory transactions to status “received”. Also any item cost will be physically posted to ledger.

Purchase:
The Columbus PDA product receipt posting will ONLY post registered quantities. If the form does not accept the purchase ID you enter/select, it is because the purchase order lines are not registered. The scenario is that the worker uses express registration, and when done the worker can do a product receipt posting to complete the arrival process.

The other criteria is that the selected purchase order must be “confirmed”. Only approved purchase orders will generate a error.

The purchase magnifier will show the registered quantity, and the “remainder” quantity.

Product receipt number:
This is the vendors packingslip number, and must be entered/scanned to be allowed to post the product receipt.

Document date:
If the goods are received on another date then the current date, then the document date can be adjusted.

Print:
If the user wants a printout of the product receipt, then select the print option. The printer is determined by the print management setup of standard dynamics AX 2012.

I wanted to share with you how I have enabled the rich functionality of Dynamics AX 2012 to be run on a wireless device. What I show you here is 100% based on AX 2012 feature Pack, and everything is created in AX 2012. I decided also to have no changes on std. AX elements, and only use existing available functionality of AX 2012. 

The wireless communication can be achieved either through the customer’s wireless infrastructure or a cellular network. To speed up the data mining process, the device must support touch screen and either barcode scanning or radio frequency reading.

Each wireless device can connect to an individual session through Remote Desktop Services of Microsoft Server 2008.

The key benefits of this setup:

• The build in communication and security features of Windows are utilized.
• Maintenance and deployment tasks are centralized, because all logic are located and run on one server and not on each device.
• The customer’s own IT department can set up new devices, because only the communication information is to be set up on the device.
• No business critical data is stored or executed on the device.

Wireless device

· Microsoft Windows Mobile 6.1 or later
· Remote Desktop Service client 7.0 (build into Windows Mobile 6.1)
· VGA (640 X 480) color touch panel (Other resolutions is just a configuration)
· Wireless network adaptor or cellular adaptor (EDGE or better)
· Barcode scanner or RF-tag reader

Due to past experience with several hardware vendors, and the requirements of the PDA solution, I have can recommend the Motorola MC75 wireless device. The MC75 is available in different configurations and can fulfill the specific needs of a typical customer.

General properties of a PDA form

All forms in a PDA solution should have the same generic properties, and what I have done is the following.

In addition, it is recommended to have a visual confirmation to the user.  Like a flash green, if the input is accepted, and red permanent background if the scanned/entered data is not accepted.

Item barcodes required

To efficiently use a PDA, all items should have an item barcode associated to each item. The main reason for this, is that the item barcode will contain the unique reference to item and the product dimensions like configuration, size, color and style. If it is not a possibility to have item barcodes on the products, than use the item number as the item barcode.

To generate item barcodes, it is possible to automate this with a  set of jobs than can be ran to periodically generate standard item barcodes.

Main menu and setup

The main menu, if the first screen that the user will access. I can recommend to implement a command line parameter, to automatically start the PDA. This means that when the user logs into the RDP, an auto startup command with AX32.exe –startupCmd=PDA, that will start the PDA menu automatically.

In addition it is recommended that the Exit button do a log-out of the user from the RDP session. If the user just wants to exit the PDA menu, then press “ESC” to exit, and the RDP sessions is closed.

The PDA screens should also be configured per user in a setup.

In the setup, the user can set up a default “current warehouse”, so that lookups and scanning is limited to the specified warehouse. In addition the worker can enable/disable functional areas that are not applicable to the workers normal operations, and therefore also reduce the number of options on the main menu.

Then the user is keeping his finger down on the screen, the current selected menu.

The menu items are also attached to configuration keys, so if a configuration is disabled (like project or production), then the menu will not be visible.

Generic and common forms

In several places a magnifier glass will appear like this:

This is a menu button to drill further based on the information that is filled in. In general there are 4 main types for generic forms. Item information, dimension specification, lists and picture.

Item information

The item information form will show primary information, like item barcode, item number, item name, standard purchase and sales price. In addition there are a editable field under the “location”. This is the warehouse. Normally the default warehouse will be filled in here, but the user can change this. This will affect the display of the primary picking location, and the fields for on hand, like available physical, Physical and ordered.

In the bottom, the item barcodes product dimensions, in addition to the item description.

The default product image is also seen here. By clicking on the image, the system will bring up a full size picture of the product.

Item and dimension specification

The item dimension specification form, is typical used when there is not enough space in the form to specify all dimensions. Then a separate form will popup, where the user must specify/rescan item barcode, and also specify additional dimensions like pallet ID, Batch or Serial number.

This form is mainly used in picking situations, and what fields/dimensions that should be visible is dependent on the storage and tracking dimension group of the item.

Product picture

The product picture form is a very simple form, that just gives the user a full size picture of the product. In addition, item bar code, item number, item name and product dimensions will be shown.

Lists

In some cases the magnifier will bring up lists to give the worker an overview. This could be an overview of all purchase lines, all items on a location, all lines on a journal etc.

The list contains a list with different information, a reminder and a quantity. The list changes based on from where it is called, and what it is supposed to show.

In this example it will show open purchase lines, showing item, reminder and line quantity. In the bottom the item bar code and product description is shown.

In the bottom section all dimensions from the line will be shown. Both product, storage and tracking dimensions will be shown here.

The default product picture is clickable, and will show the picture in full format.

Summary

To have these generic and common forms and framework, the development of the functional forms become very easy, and I could focus on the actual functionality.  Drop by my blog in the weeks to follow, and I’ll show you how the functionality actually works.