In December of 2016, Nucleus Research released their ERP Technology Value Matrix 2016. In the report, they identified Microsoft Dynamics 365 as one of the leading ERP solutions – and predicted its path to keep improving in terms of usability and functionality.

While we expect the adoption of Microsoft Dynamics 365 to increase in the marketplace compared to non-Microsoft solutions (like NetSuite or SAP) – adoption among Microsoft Dynamics AX, GP, and NAV users will be even higher.

In either instance, below are five reasons to trust Merit Solutions with your Microsoft Dynamics 365 upgrade or migration:

1. Our Rapid365 pre-configured best practices upgrade speeds migration and adoption.
2. Maximize the value of a “mobile first, cloud first” platform by working with a Microsoft Mobility MVP.
3. MeritCare provides ongoing support and system optimization services for Dynamics 365 and Azure.
4. Ensure project success with a partner who has a 96% client satisfaction rating over the past 5 years.
5. Rely on a long-term partnership with the only Microsoft Dynamics 365 partner on Deloitte’s 2016 Technology Fast 500 list.

If you are considering a Microsoft Dynamics 365 upgrade or migration – please browse some of the white papers on our website for access to free resources during your evaluations.

The post 5 Reasons to Trust Merit Solutions for your Dynamics 365 Upgrade appeared first on Merit Solutions.

A new feature for cross-docking from a production or batch order to a transfer order has been released together with KB 3207958.

Input about this feature has come from manufacturers that produce in high volume – for example, food manufacturers. These manufacturers are constantly shipping their finished goods from the bay doors of the manufacturing site to distribution centers. This flow is reflected in the layout of the production floor, where the palletizers at the end of the production lines are located close to the bay doors. The transportation plan is based on the production plan. Therefore, in most cases, when a product is reported as finished, a transfer order is waiting, so that the finished good can be shipped to a distribution center right away.

This scenario starts at the end of the production line, where goods are reported as finished. When goods are reported as finished, work of the Finished goods put away type is usually created to guide the warehouse worker to pick the goods from the production output location and put to a location that is determined by the location directive for Finished goods put away. This feature enables a process where, during the process of reporting goods as finished, the system looks for an opportunity to cross-dock the goods to the bay door locations where there is transfer order demand. From a system perspective, the cross-docking opportunity is a transfer order that is released to the warehouse. This transfer order represents the transportation between the manufacturing plant and a distribution center. If a released transfer order exists, the system generates work of the Transfer issue type instead of the Finished goods put away type. This work suggests that the warehouse worker pick from the production output location and put to a location that is determined by the Transfer issue location directive for the Put work order type. The following illustration shows this process.

In the preceding illustration, the truck driver picks up the pallet at the end of the production line. If a released transfer order exists, the system directs the forklift driver to the bay door location. If there is no demand at the bay door, the system directs the truck driver to a location in the warehouse.

How to configure cross docking

You configure the cross-docking process in work policies. A work policy includes a work order type, a location, and a product. In the following example, cross-docking is configured for product X and location Y.

Work order types

• Work order type: Finished goods put way
• Work creation method: Cross docking
• Cross docking policy name: Transfer orders

Inventory locations

• Warehouse: 51
• Location: Y

Products

• Item number: X

Currently, cross-docking can be configured for only two work order types:

• Finished goods put away
• Co-product and by-product put away

In the cross-docking policy, you define which document types are applicable for cross-docking. Currently, the only document type that is supported is Transfer orders . The following example shows the configuration of a cross-docking policy.

Cross docking policy name: Transfer order

• Sequence number: 10
• Work order type: Transfer issue
• Cross docking demand requires location: False
• Cross docking strategy: Date and time

The sequence number indicates the priority of the document type. Currently, Transfer issue is the only type that is supported. Therefore, the sequence number will become relevant only when more work order types are supported.

The cross-docking policy also sets the policy for the prioritization of transfer order demand. For example, if multiple transfer orders exist for the same product, the scheduled date and time that are set on the load and associated with the transfer order determine the prioritization between the orders. The scheduled date and time can be set directly on the load, or they can be set on an appointment schedule that is associated with the load. The prioritization is determined by the cross-docking strategy. Currently, there is only one strategy: Date and time.

In the cross-docking policy, you can set up a criterion to require that transfer orders have an assigned location in order to be eligible for cross-docking. This criterion is set in the Cross docking demand requires location field. In this case, the location on the appointment schedule that is associated with the load is used as the final location for the goods that are being cross-docked. If the Cross docking demand requires location field isn’t set, the transfer order can be eligible for cross-docking even if a location isn’t set on the appointment schedule. In this case, the final location for the goods that are being cross-docked is determined by the location directive for Transfer issue for the Put work order type. You might find it useful to set the Cross docking demand requires location field in a scenario where the finished goods should be cross-docked only if a trailer is assigned to a bay door. In this scenario, the goods are moved directly from the production line into the trailer. When a trailer is assigned to the bay door, a user will assign the location to the appointment schedule and will therefore make the location applicable for cross-docking.

The following sections walk you through two examples.

Scenario 1 – Cross-docking to bay door locations

Finished good L0101 is reported as finished to production output location PRODRECV in warehouse 51. Transfer orders for L0101 are set up to manage transportation between location BAYDOOR in warehouse 51 and a receipt location in warehouse 61. If a released transfer order for L0101 exists, the product should be cross-docked to the BAYDOOR location when the product is reported as finished.

Scenario 2- Cross-docking to a bay door location assigned a trailer

Finished good L0101 is reported as finished to production output location PRODRECV in warehouse 51. Transfer orders for L0101 are set up to manage transportation between location BAYDOOR in warehouse 51 and a receipt location in warehouse 61. If a released transfer order exists for L0101, the product should be cross-docked to the BAYDOOR location when the product is reported as finished.

Scenario 1 – Cross docking to bay door locations

Use company USMF.

2. Enable a new number sequence for cross-docking

Go to the Number sequences page, and select the Generate button. A wizard will guide you through the process.

2. Create a Cross docking policy

Go to the Cross docking policy page, and create a new policy that is named Cross docking to transfer order.

Note that the only work order type that you can select is Transfer issue, and the only cross-docking strategy that is available is Date and time.

3. Create a Work policy

Go to the Work policies page, and create a new work policy that is named Cross Dock L0101.

4. Set up loads so that they are created automatically for transfer orders.

In the warehouse parameters, set up loads so that they are created automatically when transfer orders are created. A load is a prerequisite for making the transfer order eligible for cross-docking.

5. Set up the item load mapping.

Go to the Item load mapping page, and set up a standard load template for the CarAudio item group. This mapping will automatically insert the load template on the load when the transfer order is created.

6. Create a transfer order

Create a Transfer order for item number L0101

7. Release the transfer order from the Load planning workbench

On the Ship tab, select the menu item for the Load planning workbench.

Release the transfer order from the load by selecting Release to warehouse on the Release menu on the load line.

An open wave line of type Transfer issue now exists for the transfer order.

8. Create a production order

Go to the production order list page, and create a production order for product L0101.

Estimate and start the production order by using the settings in the following screenshot. Note that the Post picking list now field remains set to No.

9. Report as finished from the mobile device

Go to the mobile device portal and select menu item: Report as finished and put away. Now report as finished L0101 from the hand held device.

Note that the put location is BAYDOOR. This location is found from the Transfer issue location directive for the Put work order type.

Also notice that work of type Transfer issue has been created and completed. Go to the transfer order Work details to verify the work.

Now try to start 20 pieces more on the production order

Now try to report 20 ea as finished by using the handheld device.

This time, location LP-001 is suggested as the put location. This location is found from the location directive for Finished goods put away. This location directive is being used, because no opportunity for cross-docking exists. The transfer order for LP-001 was completely fulfilled by the first cross-docking activity.

Work of type Finished goods put away was created and processed

Scenario 2- Cross-docking to a bay door location assigned a trailer

Use company USMF.

1. Change Cross-docking policy

Change the cross-docking policy that you created in scenario 1 by selecting the Cross docking demand requires location check box.

2. Create a new transfer order

Create a transfer order, and go to the Load planning workbench.

Open the Load planning workbench.

3. Create an Appointment schedule.

From the Load planning workbench, go to the Loads section, and select Appointment schedule on the Transportation menu.

Create a new appointment schedule. Note that the appointment schedule has a reference to the transfer order in the Order number field. In the Planned start date/time at location field, you can set the date and time for the appointment. This date and time will be used when cross-docking demand is prioritized during the cross-docking process. The date and time that you set in this field will update the Scheduled load shipping date and time field on the corresponding load. The location on the Shipping details FastTab determines the location that the transfer order is shipped on.

Back on the Load planning workbench release to the warehouse

4. Create a production order

Create a production order for item number L0101, and set it in status Started, as you did in scenario 1.

5. Report as finished from the mobile device

Go to the mobile device portal, and select the Report as finished and put away menu item. Now report item L0101 as finished from the handheld device.

Note that the put location is now BAYDOOR 2. This location is found from the appointment schedule instead of the Transfer receipt location directive.

Flow diagram

The flow is explained in below flow chart diagram:

Additional information

• The cross docking scenario is supported for batch and serial controlled items, both with the batch and serial number dimensions defined above and below location, in the reservation hierarchy.
• The quantity that is being reported as finished cannot be split to a transfer order demand that is lower. If, for example, 20 pieces is being reported as finished and a transfer order exist for 5 pieces, then the transfer order will not be found applicable for cross docking.

Construction equipment dealers work with very rigorous and wide-ranging service requirements—for newly bought equipment, current equipment in depots, trade-in equipment, and equipment that is being sold. Whether you both rent and sell construction equipment or focus solely on the dealership aspect, you deal with different business processes and requirements for service needs. Every purchase, inspection, sales process, and delivery has a roster of services associated with it, including advanced service planning, spare part management, checklists, certificates, and so forth.

At HiGH software, we’re finding that construction equipment dealers can meet those needs fully with the combined asset management and service management capabilities offered in DynaRent for Microsoft Dynamics.

DynaRent Equipment Management supports common-to-complex equipment processes and lifecycles from initial purchase through final sign-off or scrap. Name your need and we can meet it—the benefit of working with asset management software for equipment-driven rental and services is that it covers so many bases. You’ll have automated but highly specific processes to follow for your entire equipment procurement and lifecycle process that cover all financial and operational perspectives for you and your customer. DynaRent Works from the start as part of Microsoft Dynamics 365 for Operations and Dynamics AX, with shared databases, intuitive graphical dashboards and multi-channel, mobile connectivity.

What’s equally important is that DynaRent Service Management weaves together all service requirements for asset management. Using streamlined template, advanced service management can be configured for all your construction equipment processes, from initial purchase delivery inspection, through sales delivery inspections and periodic maintenance. You’ll work with one business solution that covers you end-to-end, and connects the fine details of equipment management with planning, scheduling, and execution for all service.

"What’s key to remember is that our solution can handle the rigors of diverse service demands—DynaRent is designed for multi-site, high-usage equipment lifecycles that may see all sorts of variables in their lifespan. Construction equipment dealers need that depth and breadth—plus that flexibility!"

For more about our integrated solution suite, download our pdf or visit www.highsoftware.com.

Image 1: Screenshot of DynaRent's Service Plan Board

How to use inventory value report: part 1

Inventory value report was released from AX 2009 SP1. It’s a very powerful report. Most of the users uses this report to do reconciliation between general ledger and inventory. In this article, we will discuss how to use this report to do the reconciliation between general ledger and inventory.

When we try to view inventory report, we need firstly define the below parameters. Let’s firstly explain the Date interval parameter. The ‘Date interval code’ is used when you want to view the predefined period instead of giving the ‘From date’ and ‘To date’. For example, if you select ‘current period’ in this parameter, AX will calculate the ‘From date’ and ‘To date’ based on the current AX session date. Let’s say the current AX session date is Jan 13 2017, then the ‘From date’ is Jan 1 2017 and the ‘To date’ is Jan 31 2017. If you don’t use date interval code, you can manually filling the ‘From date’ and ‘To date’ based on your need. Actually, ‘From date’ doesn’t change the report figures as the report will calculated the inventory value/quantity and GL balance cutting off on the ‘To date’.

There is one known issue. When you select the same date for both ‘From date’ and ‘To date’ and also enable ‘include beginning balance’ option in inventory value report ID, you may get incorrect beginning balance. This is a by-design scenario.

All the filters in the ‘inventory value’ section will be applied to the inventory transactions but not the G/L balance. So, when you try to use these filters, please keep this in mind. Otherwise, you may see the discrepancy between inventory and G/L account which is caused improper usage of the filters. This topic will be discussed furtherly in the following parts.

In Part 2, we will discuss how to create the most import parameter: inventory value report ID.

In this part, we will discuss the columns’ meaning showing in the inventory value report after you create the inventory value report ID. For how to set up the inventory value report ID, please click here.
In AX, there are two import conceptions, financial updated and physical updated. Financial updated means the inventory transactions are already invoiced (For production orders, it’s production order end.). Physical updated means the inventory transactions are not invoice but received or shipped. (For production order, it means material picked or production order report as finished). After understanding the two concepts, it will be easy to understand the below columns.
Inventory: Financial Quantity – the quantity that are financially updated.
Inventory: Financial Amount –the amount value of inventory that are financially updated.
Inventory: Physical Quantity Posted – the quantity that are physical updated.
Inventory: Physical Amount Posted – the amount value of inventory that are physical updated.
Inventory: Physical Quantity Not Posted –the quantity that has inventory transactions but not posted to the GL. For example, you have item model group which has the options ‘post physical inventory’ and ‘post financial inventory’ disabled. Then you have an item which linked to this item group. Then you have a purchase order, you receive it and invoice it. Then if you check the inventory value report for this item, you will see the quantity and the value in this purchase order are actually under the column ‘Inventory: Physical Quantity Not Posted’ and ‘Inventory: Physical Amount Not Posted’
Inventory: Physical Amount Not Posted – please do not include this amount when you do the inventory reconciliation because this amount is not post into G/L.
Inventory: Quantity –the total quantity of all the qty columns in the report.
Inventory: Amount – the total quantity of all the amount columns in the report. Like the note above, please do not use this column to do the inventory reconciliation if you have the ‘Inventory: Physical Amount Not Posted’ showed in the report. You need to exclude ‘Inventory: Physical Amount Not Posted’ from the total amount.
Average unit cost – total amount divided by total quantity.
How to use inventory value report: part 1
How to use inventory value report: part 2

If your company is considering an upgrade from Dynamics AX to Dynamics 365 and currently has external business integrations, understanding the new integration framework will be critical to your planning and success. While looking forward to the benefits that the feature-rich Dynamics 365 platform promises to deliver, the integration technologies that have been added and deprecated warrant an overall evaluation of your integration strategy.

The post Can Mobile Technologies Make Field Service Workers More Productive? appeared first on Merit Solutions.

At one of our customers, the Open transactions report for customers was not showing data in some of the fields. There should have been amounts on the report but there was just empty space. The weird thing was that this was only happening on PROD and not on ACC or TST.

After some digging, we noticed that the fields that were empty had the Visible property set to No on the temporary table that was used by the data provider. Thanks to Bill Thompson for pointing us in the right direction: Microsoft Dynamics AX 2012 Report Development Tip – Data Not Showing in Report.
No changes to the report were required, simply set the fields on the temporary table to Visible = Yes and restart the report service. Then the data should show up.

However, although this was a solution, the real problem was that the kernel versions of the AOS and the AX components that were installed on the report server didn’t match. After updating the components to the matching kernel (in our case 6.0.1108.7889-KB3053474-Binary) and restarting the report service, the report worked fine even with the visible property set to No.

So in conclusion, Always check if the kernel versions of all components match when facing weird problems like this.

AOS - Application Object Server

This error always elicits a lot of groans and calls to IT.

Multiple AOS

How do I know which AOS I am connecting to?

The server that the client is connected to can be seen at the top of your AX environment.