A new flow for the handheld device has been released with KB article: 3148600. This flow enables the user to register the finished good serial number when reporting as finished in production. This flow is targeting a process where the finished good serial number is generated under the following conditions:

It is assigned by the system at the time when the production or batch order is created.

It is configured to be unique per one single unit of the production order. If, for example, a production order of five pieces is created, five unique serial numbers are created.

Configuration of the flow

This section provides information about how the flow is configured.

Create a new Mobile device menu item, and name it, for example, Register serial number. In the field Work creation process select Register report as finished by serial number.

The menu item can be added to a menu, for example, the Production menu, as shown below.

Use the flow in production

This section provides information about how the new flow can be used in production.

Create a finished good

Create a new finished good that is controlled by serial number.

As this is an item enabled for the new warehouse processes, make sure the Number sequence group ID is added the product. Note: This flow is only applicable for a product that is enabled for a managed warehouse.

Associate a Serial number group, with this setup, with the released product.

With this setting, a serial number per quantity of the finished good will be created, when the production or batch order is created.

Create a production order

Create a production order for the finished product.

When the production order is created, open the Transactions form and notice each of five transactions has a serial number assigned.

Estimate and start the production order

Open the menu for the handheld device and register report as finished for the serial number: 000006.

Open the Transactions form again and notice that the serial number has been reported as finished to the inventory.

Open the Work details form and notice that work of type Finished goods put away has been created.

]]>https://blogs.msdn.microsoft.com/axmfg/2016/11/29/using-the-handheld-device-for-reporting-serial-numbers-as-finished-in-production/feed/0Using the Work Policy for warehouse processes in productionhttps://blogs.msdn.microsoft.com/axmfg/2016/09/21/using-the-work-policy-for-warehouse-processes-in-production/
https://blogs.msdn.microsoft.com/axmfg/2016/09/21/using-the-work-policy-for-warehouse-processes-in-production/#respondWed, 21 Sep 2016 12:05:40 +0000https://blogs.msdn.microsoft.com/axmfg/?p=1346Warehouse processes don’t always include warehouse work. By using the new warehouse work policy introduced with KB3184505, you can omit work warehouse processes in production for specific products and locations.

Below figure shows a scenario how the Work Policy can be used (double-click on the figures to make them bigger).

In this scenario, we have two production orders; one for painting Comp-1 and one for the assembly of Fg-1. The production order for Comp-1 is reported as finished to the location 001. The production order for Fg-1 is later consuming Comp-1 and Rm-1 from location 001. When the production order for Fg-1 is released, warehouse work for raw material picking is generated to move Rm-1 from the Bulk locations to 001.

For this scenario, we can set up following requirements for the warehouse processes:

No warehouse work for Finished goods put away should be created when reporting as finished Comp-1 to location 001 because Comp-1 is later consumed on the same location by the Assembly operation.

No Work for Raw Material Picking should be generated for Comp-1 when releasing the Assembly operation to the warehouse.

Work for Raw material picking should be generated for Rm-1 when releasing the production order for the Assembly operation to the warehouse.

It should be possible to define location 001 as non-license plate controlled, as it acts both as a production input location and a production output location (so far it has not been possible to define the production output location as non-license plate controlled).

The following walkthrough shows how these requirements are supported by the Work Policy. First we will set up a Work policy named NoPickPutAway-001-FG1 as shown below

As it can be seen from the figure, the Work policy uses the following three criteria to define work creation:

The Work Order Type

The Location

The Product (selected or all products)

Above policy will prevent Finished good put away work to be generated when Reporting as finished product Comp-1 to location 001 in warehouse 51.

The policy will also prevent Work for raw material picking to be generated when releasing a production order that is consuming product Comp-1 from production input location 001.

Location 001 is defined as a non-license plate controlled location. It is pre requisite for defining a non-license plate output location, that a work policy exists for the location that prevents work for Finished goods put-away from being created.

Let’s take a closer look at the setup of the products and then how the work policy works in this scenario. Product Comp-1 has a Painting operation which is associated a resource group with output location 001

The Assembly operation for the production order for FG-1 is consuming the products Comp-1 and RM-1 from the input location 001. The input location is setup on the resource requirements for the Assembly operation

The active bill of material version for Fg-1 is setup for materials Comp-1 and Rm-1

Now we create a production order for Comp-1 for 20 pieces

The production order is Started

The production order is Reported as finished from the hand-held device in the below flow

In this case Comp-1 was reported as finished directly to location 001 and no put-away work was generated because of the Work policy.

Now we create a production order for FG-1

The production order is Estimated and Released

Work for raw material picking has been generated for Rm-1, because the Work policy is only preventing work for raw material picking for product Comp-1 to be generated from location 001

In the first release of the Work policy only the following three Work order types for production are supported

Raw material picking

Finished goods put away

Co-product and by-product put away

]]>https://blogs.msdn.microsoft.com/axmfg/2016/09/21/using-the-work-policy-for-warehouse-processes-in-production/feed/0Reporting raw material consumption with the hand held devicehttps://blogs.msdn.microsoft.com/axmfg/2016/08/16/reporting-raw-material-consumption-with-the-hand-held-device/
https://blogs.msdn.microsoft.com/axmfg/2016/08/16/reporting-raw-material-consumption-with-the-hand-held-device/#respondTue, 16 Aug 2016 11:10:30 +0000https://blogs.msdn.microsoft.com/axmfg/?p=1195With KB-3164415 a new work flow for the hand held device has been introduced. This work flow enables the user to report raw material consumption for production and batch orders.

This work flow is for example relevant when there is a strict requirement for material traceability. In that case e exact time and quantity for must be reported for the consumption. This process can be seen opposed to back-flushing .

Let’s look at a simple scenario that explains how the new work flow can be used. A production process is consuming a raw material RM that is stored on a license plate 4543 with two batches B1 and B2. The material is registered consumed on a continuous basis.

Configuration of the new flow

First create a new Mobile device menu item with the activity code: Register material consumption

Add the menu item to a Mobile device menu

Make the consumption registration on the hand held device

Create a production order for the finished product FG

The production order has a simple bill of material with a raw material RM The Bill of Material line is set up with a flushing principle: Manual.

The raw material is on-hand with two batches on a license plate on location 00901.

The production order is started.

The production order is now in status: Started.

Let’s look at an example where the user registers the consumption of 100 lbs. of the raw material RM.

Some additional comments to the flow:

If the user cancels the flow after a journal line is created, then the journal is in an un-posted state.

If the same user starts up the flow again, for the same production order, then any new line will be created in the existing open journal.

The new flow is also supporting the registration of serial numbers.

It is only possible to register an item number that is defined in the bill of material or formula for the selected production or batch order.

It is possible to over-consume a material. If a material for example is estimated to be consumed with the quantity of 100 lbs., then it is possible to over-consume with a quantity of for example 105 lbs.

The figure above, is a high level illustration of how user interactions in general are processed on the Enterprise Portal (EP) for Microsoft Dynamics AX 2012. The clients access the AOS through EP, which is a web implementation built on top of Microsoft Sharepoint, hosted on a web server (IIS). The communication between EP and the AOS is synchronous using the .NET Business Connector RPC call. Each RPC call must be completed and returned, before http request timeout is exceed on the IIS.

To understand what implications the above has, when using the Product configuration module, we will go through the sequence of events, which take place when the user loads a configuration model and assigns a value to an attribute.

The above illustrates the sequence of loading a configuration model and assigning an attribute a value on the Enterprise portal.

Loading a configuration model

When the user wants to configure a product, e.g. from a sales order, the requests will be handled by EP. The EPPCConfigurator web control will be loaded, inside the web control a proxy Instance of the PCEnterprisePortalMain class is created. This proxy is used to interact with the AOS Product configuration logic.

On the AOS, the XML representation for the specific configuration model is retrieved from the database. Then the XML string is passed as argument to Product Configuration Server API, which unlike the Client API is design to support synchronous execution. In the creation of the ProductConfigurationServer instance, the XML is parsed and supporting data structures are created, just like on the Windows client implementation.

Once the data structures have been created, the configurator instance can start processing the constraints and calculations of the configuration model. Unlike the Windows client however, the processing on EP needs to respect a fixed time limit, in order not to cause a timeout on the web server.

Another difference between the Windows client an EP is the way the model is being processed. The EP implementation will attempt populate all visible enumeration and Boolean attributes. This is the equivalent of opening all the visible attribute controls on the active component in the form, and letting the configurator deduce feasibility of the values of each attribute.

The more attributes that are visible, the less time that is available to process each attribute. For components with over 20 enumeration and boolean attributes, it can happen that there is not enough time to process the feasibility of all values within the domain of the attribute.

Assigning values to attributes

When the user makes an assignment to an attribute, the web form is then posted back to EP and a request to assign the attribute is made on to the AOS. On the AOS, each call from EP executes in its own context, this implies that a new instance of the configurator is created. This instance must again parse the XML representation of the configuration model, before being able to process the user assignment. After this, the instance is disposed and a new one is created to process the assignment , same as before.

The main problem can be seen from the diagram in Figure 2, is the activation line of the ProductConfigurationServer object. Unlike the Windows client implementation , the configurator instance is not kept alive throughout the configuration session. The synchronous execution combined with the time limitation is the main limiting factor, which forces us to create and dispose instances of the configurator for each request.

The consequence of this is that the EP implementation of the configuration module, is not able to deliver a user experience which is similar to that of the Windows client for models of medium to high complexity.

Please keep this in mind when considering implementations of the Product Configuration module on Enterprise Portal for Microsoft Dynamics AX 2012.

Client 1 loads a configuration model using an RPC call to the AOS to retrieve an XML representation of the configuration model. After this the processing of the configuration session happens on the client.

When Client 2 wants to load a configuration model, it goes through the same process as Client 1, by retrieving its own XML representation of the configuration model, which it wants to load. Then processing of this model happens solely on Client 2. In this way processing is distributed on the hardware of the different clients.

However, the reality for many of our customers and partners is a bit different to the picture shown Figure 1.

Figure 2

The setup in Figure 2 should be more familiar to those of you who have experience with Microsoft Dynamics AX 2012. Instead of having fat clients as in Figure 1, the users are instead connecting to the Dynamics AX windows client, using a remote desktop session, set up on a Windows server running Terminal services.

Thus when Client 1 wants to load a configuration model, it happens via the Terminal service, which is then retrieving the XML representation of the configuration model from the AOS. The processing of the configuration session then happens in the context of the remote desktop session, which is on the host of the terminal services.

The same thing repeats itself when Client 2 wants to load a configuration model. The difference between this and the previous setup is, that processing for both configuration sessions are now centralized on the host of Terminal services. This processing includes not only the processing of the underlying configuration model, but also the processing related to handling the rendering of the UI.

When we look at what is happening at a lower level, with more details, the picture looks like this:

Figure 3

The diagram in Figure 3 shows what happens when the XML representation of the configuration model has already been retrieved from the AOS. From the Xpp client it is then passed on to the Product Configuration .NET component crossing the CLR interop. In the loading phase of the configuration model inside the .NET component, the following action are executed:

Parsing the XML representation of the configuration model

Creation of supporting data structures

After these processes the .NET component starts to process the loaded model and then starts to issue events whenever it is able to deduce that an attribute must take on a certain value. These events are send back to the Xpp client which updates the page accordingly.

At some point the user will want to accept the configuration and this is done by pressing the OK button on the dialog. When this happens a method is invoked on the .NET component, which aborts any running task, and starts a new task which verifies whether the configuration is complete. The definition of a complete configuration is that all mandatory attributes have been assigned a value.

If the verification fails in the first attempt, the configurator will issue a new task to attempt to deduce any unassigned mandatory attributes. In the illustrated example, the configurator is not able to deduce all mandatory attributes, and so a message will be shown that informs the user that additional assignments are required. The user must then assign values to the remaining mandatory attributes. Here the user makes a new assignment and then presses the Ok button again, to complete the configuration. This time the verification passes as all mandatory attributes now have a value.

An important thing to notice is that the configurator instance is active or ‘alive’ throughout the configuration session. As you may know, the .NET configuration component uses a background thread to process the configuration model without locking the UI. In this way the configurator is always able to act on new user input.

]]>https://blogs.msdn.microsoft.com/axmfg/2016/04/04/microsoft-dynamics-ax-2012-product-configuration-windows-client-processing/feed/0Round up work for raw material picking to match the handling unithttps://blogs.msdn.microsoft.com/axmfg/2016/01/18/round-up-work-for-raw-material-picking-to-match-the-handling-unit/
https://blogs.msdn.microsoft.com/axmfg/2016/01/18/round-up-work-for-raw-material-picking-to-match-the-handling-unit/#respondMon, 18 Jan 2016 01:24:00 +0000https://blogs.msdn.microsoft.com/axmfg/2016/01/18/round-up-work-for-raw-material-picking-to-match-the-handling-unit/This blog post describes the functionality of a new hofix that is released in the Microsoft Knowledge base (KB) in article 3120530.

After installing this hotfix it is now possible to configure the location directive for raw material picking, so work can be rounded up to the nearest handling unit in which the material is picked for production.

Consider following scenario:

A food manufacturer uses a special flour for making a powdered soup mix. The flour is stored on pallets in 50 lb bags in the bulk warehouse. For making 4,475 lb of the powdered soup mix 510.15 lb of flour is needed. This corresponds to 10 x 50 lb bags + 10.15 lb. As the material is always picked in bags (the handling unit), the warehouse worker will in this case pick 11 bags. After the 11 bags are moved to the production floor, the bags are broken and 510.15 lb is weighed off and applied to the production process. The remaining quantity from the last bag will remain on the input location and either be consumed by the next batch order or moved back to the warehouse.

Before the release of this hotfix it was possible to set up in which handling unit the material should be picked, but it was not possible to round-up the quantity to the nearest handling unit. In the above example, work for raw material picking would have been created for 10 x 50 lb bags and 10 lb i.e. for the same work the material would be picked in two different units. This scenario is still supported, and is relevant for some customers who wants to weigh of the material at the warehouse location (in this case the remaining 10.15 lb).

Let us take a closer look at how the mechanism to round up work to the nearest handling unit has been enabled.

Setting up the location directive for raw material picking

In the location directive for raw material picking a new field Round up to handling unit has been introduced:

This field works together with the field Restrict by unit. In this example the location directive is set up to pick in the unit of Bag, and selecting Round up to handling unit indicates that the work generated out of the directive should be rounded up to a multiple of one handling unit.

Setting up formula and ingredient

In this example a formula version for making the soup mix is set up with a batch size of 4475 lb, consuming 510.15 lb of Flour

A unit conversion has been set up for the Flour ingredient between the unit’s bag and lb.

The following Unit sequence group is used for the item. The inventory unit must be the first unit in the sequence group, in this case lb.

Releasing work for raw material picking

A batch order is now created and released for the batch size of 4475 and warehouse work for raw material picking is generated.

As it can be seen from the work details work is in this case rounded up to 11 bags. The batch order is still only reserving the required quantity 510.15 which can be seen from the work transactions form that can be opened from the work details form:

If the rounding option had not been used on the location directive, then the resulting work would have looked like this:

In this case the warehouse worker would have to pick 10 bags and weigh of the remaining 10.15 lb on a warehouse location. This process is enabled in the location directive by adding a line that is not restricted by unit. This line will make work for the remaining quantity.

]]>https://blogs.msdn.microsoft.com/axmfg/2016/01/18/round-up-work-for-raw-material-picking-to-match-the-handling-unit/feed/0Support for BOMs that includes items with different product dimensions of the same itemhttps://blogs.msdn.microsoft.com/axmfg/2015/12/22/support-for-boms-that-includes-items-with-different-product-dimensions-of-the-same-item/
https://blogs.msdn.microsoft.com/axmfg/2015/12/22/support-for-boms-that-includes-items-with-different-product-dimensions-of-the-same-item/#commentsTue, 22 Dec 2015 06:32:00 +0000https://blogs.msdn.microsoft.com/axmfg/2015/12/22/support-for-boms-that-includes-items-with-different-product-dimensions-of-the-same-item/This blog post describes new functionality released with the Microsoft Knowledge base (KB) in article 3089402.

When using one or multiple of the product dimensions in production, you can have situations where you would like to produce an item, based on a different variant of the same item. There are many scenarios where this can be useful, e.g.• A Green variant of a specific item that is produced using a white variant of the same item.• An item variant produced using a different configuration of the same item. • Large item variant cut into multiple smaller variants of the same item.

Until now it has been mandatory to use different items for the parent and child product respectively. If this was not the case, the user would get a warning from the BOM check that circular reference is not allowed. If the warning was ignored MRP might fail. This warning was caused by the fact that the level check and the BOM level calculation was done per item.

With KB3089402 you can use the same item as both parent and child in a BOM – as long as minimum one product dimension differs.

This means that an item can now have multiple levels. In this case: • Item A Config 1 is level 0• Item A Config 2 is level 1 • Item A Config 3 is level 2

Required setupInventory model: To ensure correct costing, items with BOMs including variants of the same item must use standard cost.BOM check: Circularity check strategy have to be set to ‘Optimize for high complexity’. The other option ‘Optimize for low complexity’ has not been updated, and will detect circularity for item variants produced from the same item.

High level KB changes• Update BOM level calculation for planning: Will include any used product dimensions (Configuration, Size, Color, Style).• A correct configured BOM will need to have at least one product dimension that differs. Blank is not a value. The product dimension that differ must be set on both parent and child item in the BOM structure.• MRP, Predetermine cost calculation, and Actual cost calculation (inventory closing) is updated to use item and product dimensions with the new BOM levels.

Important implementation noteEnsure that the reqItemLevel table is empty before the first MRP (Master Schedule) run. Any change, like creating or modifying an item, will generate entries to the table and as a result it will not be empty.The simplest way to do this is to truncate the reqItemLevel table, and then run a full MRP (regenerative with no filters). Otherwise MRP will not generate any planned orders!

Q: Will this require additional setup?A: Only adding the relevant product dimensions to the BOMs, and ensuring to use Standard cost as well as the Circularity check strategy Optimize for high complexity. Also notice the implementation note regarding reqItemLevel.

Q: Will BOM circularity be checked for local changes on Production and Batch orders?A: No, this KB is not changing what triggers the circularity check, as this is beyond the scope of the KB.

Q: Will this KB address issues related to rework scenarios, where exactly the same item and product dimensions are both input and output of production/batch order?A: No, rework is outside the scope of this KB.

Q: What is the impact on performance?A: Impact is none or minimal for both circularity check and MRP. There is a bit more data to process, but information is now stored outside InventTable. MRP tasks are per Product and BOM level, so multi thread of products with variants on different BOM levels is possible and can give minor performance improvements. Our tests have shown less than 5% change in performance based on this KB.

Q: Can I produce a specific variant from “any variant” – e.g. a Red variant from any (Blank) variant of the same item?A: No, blank is not a value. The product dimension that differs must be set on both parent and child item in the BOM structure. So in this example you will have to choose a color for the used component.

Q: Will the BOM level calculation be stored in the same location for both Planning and Costing?A: No, that changed with this KB. Costing will continue to use the current BOM level calculation stored in the InventTable. For planning (MRP) a new table is created to store the BOM levels with both Item and Product dimension information. This design will make it possible in the future to differentiate the processed data for Planning vs costing, e.g. ensuring that ended production orders are not included in BOM level calculation for MRP planning.

Q: Will the BOM consistency check uptake support for product dimensions as well?A: Yes, with Circularity check strategy set to Optimize for high complexity.

Q: Does this mean that we now have the same options for product dimensions as for items?A: No, but this is a step on the road to full variant support in AX – and a very important step

T-Shirt example with screenshotsA Green variant of a T-Shirt item is produced, using a white variant of the same item.

First we set the Circularity check strategy to Optimize for high complexity. Optimize for low complexity does not support BOMs that includes items with different product dimensions of the same item.

Create new T-Shirt item with Product dimension for Size and Color, using standard cost

Define size and colors for the product

Create all the variants for the product. We now have 9 variants of the T-Shirt: – Size: Small, Medium and Large – Each size in the Color: White, Red, Green

We can now create a BOM for producing a medium green T-Shirt, using a medium white T-shirt

The Circularity check will pass, since the color dimension differ

Say we made a mistake and tried to produce a medium green T-shirt from the same medium green. Then we would get an error, indicating that we have a circularity loop in our BOM:

Let’s modify the item coverage to ensure that the white T-Shirt is purchased. The green T-Shirt is produced and with a minimum of 3 to trigger a supply when running MRP

Now let’s run MRP and look at the planned orders generated for the T-Shirt

Notice that we get planned orders to produce 3 medium green T-Shirts, and purchase 3 medium white T-Shirts. Also, looking at the Explosion, you can see that the two colors have different levels

]]>https://blogs.msdn.microsoft.com/axmfg/2015/12/22/support-for-boms-that-includes-items-with-different-product-dimensions-of-the-same-item/feed/5Reporting as finished with the option to mark the order as endedhttps://blogs.msdn.microsoft.com/axmfg/2015/12/21/reporting-as-finished-with-the-option-to-mark-the-order-as-ended/
https://blogs.msdn.microsoft.com/axmfg/2015/12/21/reporting-as-finished-with-the-option-to-mark-the-order-as-ended/#commentsMon, 21 Dec 2015 02:48:00 +0000https://blogs.msdn.microsoft.com/axmfg/2015/12/21/reporting-as-finished-with-the-option-to-mark-the-order-as-ended/This blog post describes a new hofix that is released in the Microsoft Knowledge base (KB) in article 3124753.

When reporting a batch order or a production order as finished with End job, the order state will be updated to Reported as finished. This state indicates that no more finished goods are going to be reported and no more time and material is going to be consumed by the order. As a consequence, any inventory transactions with remaining quantities for both materials and the finished goods will be closed.

So far the End job option has only been supported when reporting as finished from the AX Client and not from the hand held device. With this hotfix the End job option is now also available with reporting as finished from the hand held device.

This hot fix also leverages the Physical reduction parameter in the production control parameters. Setting this parameter can be helpful in for example material back flushing scenarios where it will prevent the reporting as finished process to error out in case of material stock out.

Configuration of the menu item

A new parameter End job has been introduced in the Mobile device menu item for the work creation process Report as finished and put away.

When setting this parameter the End job field will be visible when reporting as finish on the hand held device.

Reporting as finished with End job

Reporting as finished with the End job option can be demonstrated by using a simple Formula FinGood with a formula line named Ingredient. A batch order is created for FinGood

The formula line is set up with flushing principle Finish

Also note that the formula line is set up with a variable scrap percentage of 5.

The batch order is now Released and warehouse work for raw material picking is created.

The work for raw material picking is processed and the ingredient is now available and physically reserved on the production input location.

Note that the quantity is 1050 as it includes the estimated 5% scrap.

The batch order is Started and after some time a partial quantity of 500 is reported as finished from the hand held device

Note that the field End job is set to No as we are reporting a partial quantity.

After reporting as finished is completed a quantity of 500 pieces of the finished product is on-hand and the material Component has been back flushed proportional to the reported as finished quantity which can be seen on the material inventory transactions.

Now the last quantity of the FinGood is reported as finished. To indicate it is that last quantity the End job field is set to Yes.

In this example the batch order is over producing with a quantity of 3 (500+ 503), because less material than the estimated 5% was scrapped during the production thereby enabling more finished goods to be produced. As back flushing is consuming proportional to the reported as finished quantity, the system will in this case try to consume 503 + 5% = 528. As there is only 525 left on the input location this will cause the process to error out due to material shortage

As only 525 was consumed (because we had a lower scrap than estimated) we want the system to consume the remaining quantity of 525 on the input location and not try to consume more.

To support this scenario, the Physical reduction property, that is set up in the Production control parameters, can be used. Using it, will ensure that the system will only try to consume the physical available quantity during back flushing. The parameter is only leveraged, in this scenario, when the End job is set to Yes on the hand held device.

With the Physical reduction parameter set, let us again try to report a quantity of 503 as finished with End job

Looking at the batch order, the status has now changed from Started to Reported as finished

In total a quantity of 1003 has been reported as finished

With the consumption of the original estimated quantity of 1050 of the ingredient

]]>https://blogs.msdn.microsoft.com/axmfg/2015/12/21/reporting-as-finished-with-the-option-to-mark-the-order-as-ended/feed/2Recommended settings for materials that acts as consumables in productionhttps://blogs.msdn.microsoft.com/axmfg/2015/10/04/recommended-settings-for-materials-that-acts-as-consumables-in-production/
https://blogs.msdn.microsoft.com/axmfg/2015/10/04/recommended-settings-for-materials-that-acts-as-consumables-in-production/#commentsSun, 04 Oct 2015 23:50:00 +0000https://blogs.msdn.microsoft.com/axmfg/2015/10/04/recommended-settings-for-materials-that-acts-as-consumables-in-production/The core team has been engaged in a couple of requests about how to set up raw materials that acts as consumables in production. In these requests the following characteristics has been used for consumables:

They are never stored in the raw material warehouse, but filled up directly at the production locations, therefore warehouse work for raw material picking is never needed for these materials.

They often represent a low value and are not accounted for at time of consumption, but cycle counted at a periodic basis.

They are often set up to allow for physical negative inventory to avoid blocking issues when they are back-flushed in production.

As we encountered some issues using items that are WMS-enabled for consumables with the above mentioned properties, we recommend to use items that are NOT WMS-enabled for this purpose. With this item is possible to:

Setup a default issue location either at the item-warehouse level or by the resource (resource consumption). This location will be defaulted to the production bill of material line, and act as the production input location i.e. the material will be consumed from this location.

Use it in a warehouse that is WMS-enabled, and there is no problem setting up this product to allow for negative inventory.

Ensure that warehouse work will never be generated for this item.

The problem with using a WMS-enabled item in combination with allowing for negative inventory is, that warehouse work will be generated in case there is no on-hand on the production input location. This happen instead of deducting the input location with a negative quantity, which would be the expected behavior. An attempt to back-flush the material in a later stage will result in a blocking error “Item XXX does not have enough inventory”.

The recommendation of using a WMS-enabled item for consumables, will not support a scenario where the warehouse processes is applicable for the item in other processes, for example, in the product receipt process. Supporting these different scenarios for the same item is currently identified as a gap, but we are currently investigating possible solutions to enable this capability.

]]>https://blogs.msdn.microsoft.com/axmfg/2015/10/04/recommended-settings-for-materials-that-acts-as-consumables-in-production/feed/1New support for serial number registration in productionhttps://blogs.msdn.microsoft.com/axmfg/2015/09/30/new-support-for-serial-number-registration-in-production/
https://blogs.msdn.microsoft.com/axmfg/2015/09/30/new-support-for-serial-number-registration-in-production/#commentsWed, 30 Sep 2015 00:59:00 +0000https://blogs.msdn.microsoft.com/axmfg/2015/09/30/new-support-for-serial-number-registration-in-production/The hotfix in Microsoft Knowledge Base (KB) article 3093049, which is planned for release in mid-October, enables scenarios where registration of a component’s serial number can be postponed until the time of consumption in production. Here is one of the customer scenarios we have been looking at:

Most of the components we use for our machine assemblies are delivered from vendors. These components are typically received on pallets packed in a quantity of for example 200 pieces. Each component has a unique engraved serial number, but we don’t need to register the serial numbers at product receipt. We just register the receipt of the pallet, so that we don’t have to spend time breaking up the pallet and registering each serial number individually. The serial number also isn’t registered when the warehouse worker picks the component for the production order. However, when the assembly worker mounts the component in the assembly, she reads the engraved serial number on the component and updates it in the system. By registering the serial number at the time of consumption, we can print a list that shows exactly which component serial numbers were used in a given assembly. Then, if we receive a complaint, and the issue that is reported can be tracked to a specific component, we can communicate the serial number back to the vendor. In a worst-case scenario, if the issue is systematic (for example, a batch of bad-quality rubber sealing has been used in the component), the vendor will track all the components that are affected and communicate the serial numbers affected back to us. Because we can track the serial number that is used in a given assembly, we can now identify all the assemblies that are affected and take the necessary measures.

This scenario is now supported in Dynamics AX and can be demonstrated by using a simple bill of materials (BOM) that is named Assembly and a serial-controlled item that is named Component.

In the warehouse, the component is tracked only by location and license plate. The serial number of the individual components on the license plate aren’t known at this point.

A production order is released for the assembly, and warehouse work is created to pick up the component.

The warehouse work is processed without specifying the serial number of the picked component.

The production order is started, and the production picking list journal is created.

The picking list journal can’t be posted unless a serial number is specified. Any attempt to do so will cause the following error message:

This message indicates that a serial number must be registered before the picking list journal can be posted. The new Register serial numbers menu item that has been added to the Inventory Action Pane button can be used to resolve this error.

The journal can now be posted, and the serial number is updated on the issue transaction for the production material line.

The bill of serial for the assembly can now be printed from the tracing tool.

A new field Register serials before consumption has been added to the Tracking dimension groups form to enable this scenario. This field works together with the Capture serial field for the values Picking and Packing. For example, when Picking is selected in the Capture serial field, the serial number also needs to be provided at the time of picking.