Chapter 10: Use and Design of The Production Control Module: Objectives

Chapter 10: Use and Design of the Production Control Module
CHAPTER 10: USE AND DESIGN OF THE

PRODUCTION CONTROL MODULE
Objectives
The objectives are:
• Review the basics of bill of materials and the data model

• Introduce routes and operations.
• Describe the major features of production orders.
• Review scheduling methods, resources and jobs.
• Describe master planning and the planned production order journal
model.
• Introduce lean manufacturing, Kanban, and production flow models.
• Review Process Industries in Microsoft Dynamics® AX 2012.
Introduction
Production control in Microsoft Dynamics AX 2012 consists of many aspects of
the production environment. This includes creation, estimation, scheduling,
consumption, feedback, and cost accounting for production orders.
10-1
Microsoft Official Training Materials for Microsoft Dynamics®
Your use of this content is subject to your current services agreement
Development IV in Microsoft Dynamics® AX 2012
The major processes of the Production control module are shown in the
following figure.
FIGURE 10.1 PRODUCTION CONTROL OVERVIEW
In this chapter, you will review the following major components of the
Production control module.
• Bill of materials: A list of all parts, components, and raw materials

needed to produce a product.
• Routes: The path that the item takes from operation to operation
throughout the production life cycle.
• Production orders: A source document that defines what is to be
produced, how much (quantity), and a planned finished date.
• Scheduling: An iterative activity where the system tries to find a set
of resources that can deliver the product on or before the requested
date.
• Planned production orders: A special type of "pre" production
orders that is used to generate firmed production orders that is based
on demand and other factors.
• Lean, Kanban, and Production flow: Introduce industry best
practices for pull based production.
• Process Industries: Review of how Microsoft Dynamics AX 2012
can support process manufacturing principles.
10-2
Bill of Materials
A bill of materials (BOM) is a complete list of all the components, parts, raw
materials, assemblies and their quantities that are required to make a finished
product.
BOMs define the relationship between the components and the finished product
or sub-assembly. The item number that represents the BOM is often referred to as
the finished product, and the components that make up the finished good are
referred to as raw materials. In some cases the item number that represents a
BOM is not a finished good and is instead referred to as a sub-assembly which is
used in another BOM to create a finished product or another sub-assembly. A
clear definition of this relationship is important for the following.
• Allocation of materials
• Scheduling of operations or jobs
• Creation of production orders
• Costing of the BOM and production order
Every item that must be physically accounted for in a finished product or sub-
assembly product or financially accounted for in the costing phase must be
included in the BOM. Although BOMs define the components and their
relationships, they do not define the sequence of steps to produce or assemble the
finished item.
BOMs are made up of product types, versions, configurations, sites, levels, lines,
and information used for cost calculations. In the following sections, these
components and the data model for BOMs are reviewed to illustrate the
relationship between the tables.
BOM Product Types
BOMs can contain two types of products in Microsoft Dynamics AX 2012,

depending on whether the item is purchased or produced in-house or defined as a
service. The product types that are used in a BOM include the following.
• Item: An item in a BOM that is defined as the product type Item is

purchased from an outside source or produced in-house, depending
on the default order settings type. When the default order type is set
to purchased, then the item is purchased. When the default order type
is production or Kanban, then the item is manufactured.
• Service: An item in a BOM that is defined as the product type
Service represents and quantifies a service that is a part of the
manufacturing process. For example, you are producing
personalized, hand painted coffee mugs. The BOM for the finished
product coffee mug includes three products.
o Blank Mug: That has a product type of item.
o Paint: That has a color dimension and a product type of item.
10-3
o Painting: That has a product type of service because the

painting is not tangible and not stocked in the inventory. The
painting must be accounted for and the users must select the font
for the painting in the configuration. Certain fonts cost more, and
must be financially accounted for in the BOM.
BOM Version
A BOM can have multiple versions. When you create a BOM, you must have at
least one version. In order to use the BOM it must be approved and activated.
Later, if the BOM is no longer required, the activation and approval can be
removed. The BOM version is used to define which finished product item
numbers are linked to the BOM. You can also specify information about the date
of validity, site, quantity ranges, whether the version is active, and who approved
it.
Zero or more BOM versions can be valid or active for any item at any given
point in time. However, only one version can be applied. The applied version is
selected based on time, site, and quantity. The BOM version is useful in these
cases.
• Two products that consist of the same raw materials but different
production processes will be able to use the same BOM but different
routes. For example, the same product is produced in two different
sites by using different equipment.
• When changing the raw materials of a product over time, different
BOMs can be attached as of a specific date. In the example of the
personalized coffee mug, the paint that is used for the mug was
originally paint X, and now they are going to use paint Y to make the
mugs. This change can be reflected in a new BOM version as of the
date that the change occurs.
BOM Configuration
For planning, calculation, and consumption purposes, each BOM line must
specify whether the item has any configurations. A configuration is a standard
component combination, such as a satellite speaker and a sub-woofer that can be
specified for a BOM item during the ordering process. For example, the user
might select the size and color of speaker to be included in the home theater
system.
BOMs with Sites
A finished product can be set up so that parts of the finished good can be
produced at different production sites. A typical scenario for production at
multiple sites might involve an end item that includes component items, where
the component items are produced at and moved between different sites, and the
sites share common item numbers. Each BOM version can be linked to a specific
site, or each line of BOM can have a different site assigned.
10-4
BOM Levels
BOMs can contain many levels of goods to produce. A simple BOM is all on
level one. For example, when assembling a cabinet, you will have the frame,
shelves, and hardware. These are all on the same level, because each primary
component is in the assembly.
When a BOM contains another BOM as its component, then it is known as a

multilevel BOM, where the sub BOM is referred to as level one and its
components as level two. BOMs can consist of as many levels as necessary,
depending on the type of product being produced. For example, adult bicycles
consist of two wheels, a seat, handlebars, and a frame. All these components are
reflected in the bicycle BOM. However, the frame also consists of several
discrete items (three or four tubes welded together). Therefore, the frame has a
BOM of its own. It is known as a sub BOM, that is, a bill of material within the
bill of material for the end-product, the bicycle.
BOM Lines and Line Types
The lines in the BOM are the individual items or services that make up the BOM.
Each product has its own BOM line. An unlimited number of lines or items can
make up the BOM.
There are four types of BOM lines in Microsoft Dynamics AX 2012.
• Item: The item is a raw material or semi-finished item that must be

picked from inventory.
• Phantom: An item is a transient (non-stocked) BOM item. A
phantom BOM represents an item that is assembled, but frequently
not stocked in inventory until it is actually needed in the
manufacturing process. Phantom BOMs are used so that the Material
Requirement Planning (MRP) logic can calculate requirements for
the needed components. When a BOM includes a phantom item, no
separate production order is created for the phantom item. Instead,
the main BOM is "expanded" with the BOM lines from the phantom
item's BOM. The Phantom line type can only be specified for an
item.
• Pegged supply: Select pegged supply when you want to include an
item for which the pegging rules should apply, regardless of the type
of production. When a BOM line is set to pegged supply then that
item will be pegged (signaling a product demand requirement)
according to the method of production (lean or normal), or purchased
when the default order type is set to Purchase. Referring to the
example of the coffee mug again, when you are producing made-to-
order coffee mugs, the painting of the coffee mug can be marked as
Pegged supply to indicate that the production order should not be
created unless there is a demand (sales order) for a personalized
coffee mug.
10-5
• Vendor: A vendor provides the component item and the method

through which the item is provided depends on the default order type
for the component item. The production is conducted by using a sub-
contractor. This option can also be used for the product type Service
and for a sub-BOM.
BOM Costing
Bills of material calculations use data from several sources to calculate the
rolled-up or total costs of a manufactured item. The sources include information
about items routing details, indirect cost calculation formulas, and the costing
version. The purchased item information that is used in a standard cost BOM
calculation includes cost, cost group, and warning conditions.
The manufactured item information that is used in a standard cost BOM

calculation includes standard order quantity for inventory and warning conditions
that are embedded in the item's BOM calculation group.
The bill of material information that is used in a standard cost BOM calculation
depends on the following.
• BOM version
• BOM line item quantity
• BOM line item scrap
• BOM line item valid dates
• The default order type of the BOM line item
• Parameters for the cost calculation
• Sub-route for a manufactured component
• Effect of operation scrap percentages
BOM Data Model

The key components of the Bill of Materials Data Model are four tables, the
BOMTable, the BOM, BOM Version and the ProdBOM table. Other BOM tables
involve calculations, costs, parameters, and related information that support these
primary tables.
10-6
The following figure shows the relationship between the BOMTable, BOM and
BOMVersion. These do not include all the available fields for the tables, because
of size limitations and relevance.
FIGURE 10.2 BOM DATA MODEL
The BOMTable is the primary table of the construct. Contained within is the
setup for a Bill of Material, including Approved, BOMId, Name, Version, and
SiteId. This is best described as the header information that you must define for
the BOM. For example this is an Eight inch woofer speaker assembly.
The BOM is the line items associated with the primary table. You can have many
line items that are related to each BOMTable. Each BOM record is related to one
InventTable record to create the link for the components to the raw materials
items and services. For example, the woofer speaker assembly might include the
speakers, cabinet, and cross over assembly needed to construct the speaker. For
the speaker assemblies, they can be used for other cabinets or other
configurations.
The BOMVersion is the final table needed for the basic BOM set up. The
relationship between the BOMTable and BOMVersion is one or more versions
for each BOM. Each BOMVersion record is related to one InventTable record to
create the link to the finished product item number. For example, one version
could be used for one site and a different version for another site. Frequently
BOMs are phased out, with new components that are included in the latest
version.
10-7
The ProdBOM table is used to store the production ready, approved BOM. It is
copied from the original BOMTable (header) and BOM (lines) tables. This
follows the goods being produced throughout the life cycle of the product. This
design allows users to modify the BOM for a specific production order without
affecting the original BOM definition. Frequently it is referred to as the product
revision. From this all items or services are picked, assembled, quality assured,
reported as finished, and ended.
Routes
Routes are the path or sequence that the product takes from operation to
operation, starting with the beginning of the production process and continuing to
the end. It is a set of sequential operations, or tasks, that are required to produce a
product. The route operations describe the requirements for the resources that are
required for performing each operation. Each route includes the following:
• Operations to be performed.
• Operations relations.
• Sequence of the operations.
• Resources requirements involved in completing the operations.
• Standard times for the set up and run of the production.
One or more routes can be mapped for each product, depending on the product
and the process. You can create a completely new route, or you can base a new
route on existing route information, and then adjust or update the information to
match the new production process. The same route can also be used for multiple
products.
In the following section, you will review how to use routes and operations and
the data model associated with them.
Routes and Operations Feature Overview

Operation to be Performed
Operations are set up in sequence to establish an appropriate order and context

for the total production process of a product. An operation is a task or process
connected with the production of an item. It includes the necessary details for an
efficient production schedule. What you should know before setting up an
operation:
• Know which task or activity must be completed

• Know how many resources are needed for performing the operation,
and what those resources must be capable of. You should create
capabilities and also create resources and resource groups before you
set up the operations, because operations are closely related to
resources.
10-8
Operation Relations
Operation relations simplify and streamline the creation and maintenance of

operation base data. They are used to control which operation is customized to a
specific route or item. The main characteristics of operation relations include the
following.
• Each relation contains the information that is used by production

orders when they are created or updated. This includes the resource
requirement, route, consumption calculation, cost categories,
measurement, times, and overlap quantity that applies to the order.
o If the information that applies to the operation is general and
applies to all items, only one relation for the operation has to be
created.
o If the item or route has specific parameters for an operation that
deviates from the standard parameters for that operation,
individual relations are considered (table/group relation are
used). When the production order is created, information from
the specific relation in question is copied to the production route.
• The use of the operation relation is limited in the way it is attached to

items and routes. Each relation is attached to an item, an item group,
or all items. At the same time, each relation is attached to either a
route or all routes. This means that one operation could include
different information on times, cost categories, properties, and so on,
specified in separate relations. Therefore, the same operation can be
used in several routes by creating a relation for each route.
Sequence of Operations
Operations in a route must be attached to each other in a logical way to reflect the
production process. Depending on the complexity of the production, this can
result in a route network. For simple routes, where the operations are executed
one after the other, a route network is not required.
However, complex networks are frequently needed to reflect the production

environment. If this is the case, you can construct routes that contain several
operation branches that can be started independently.
Another network operation is concurrent operations. In this case, prerequisites

are run first, and then several operations run in parallel, ending in a completion
operation. Each operation in a route can have multiple predecessors, but only one
successor. As a consequence, a route may have multiple starting points, but only
one end-point. Therefore, only a subset of all possible networks may be modeled
as routes.
10-9
The following figure displays a simple network, a complex network, and a

network in which there are concurrent operations.
FIGURE 10.3 ROUTE NETWORKS
NOTE: Simultaneous operations can be modeled as primary or secondary

operations.
10-10
Routes and Operations Data Model

The RouteTable is connected to many different supporting tables that help define
the data model. For example, the RouteVersion table contains the key
information for Item ID that restricts the route to the current and approved item.
The following figure shows all the key Route tables.
FIGURE 10.4 ROUTE TABLE DIAGRAM
Also important for this model, is the relationship between Routes, ReqRoute, and
ProdRoute tables. For example, a regular route includes how the task or activity
is completed, the order and operation priority, and the requirements for the
resources that will perform them. The ReqRoute table is primarily populated
during master planning to record which operations are used for a production
order, and when the planned order is firmed. This data is then combined with the
operation relation to make up the production route in the ProdRoute table. This
makes sure that the route does not change mid-process and still allows planners
and schedulers to be able to update the Route table. The route on a specific
production order can be modified; much like a BOM can be, without affecting
the original route.
Production Orders
The production order contains information about what is to be produced, how
much (quantity), and the planned finish date. The system assigns an order status
to each step in the life cycle of the order. The status shows where the item is in
the production process.
The following sections include an overview of production orders, orders statuses,

the data model, the journal framework, and three production order classes.
10-11
Production Order Feature Overview

In-house Production Orders
In companies where production is conducted in-house, production orders are

frequently created for the following reasons.
• Meet sales demand when inventory is insufficient.

• Supply a BOM as subassemblies to other items in demand.
• Meet forecasted end item demand.
• Increase safety stock.
External Production Orders
If a production, or part of a production, is subcontracted and the component items

are released and provided to the vendor, the subcontracted item must be created
as a BOM. If the component that the vendor is producing is a sub-BOM, the line
type Vendor must be used. When the production order producing the item is
estimated, Microsoft Dynamics AX 2012 automatically creates a vendor
purchase order for the produced component item.
If the vendor's capacity is not scheduled, do not attach the route for the sub-
BOM. When no route is attached, the delivery time for the sub-BOM is taken
from the component items released products' base data.
If you want to schedule the vendor's capacity, create the route for the component
item and specify Vendor as the resource on the appropriate lines.
Production Order Statuses

The status on the production order reflects the sequential steps of the production
life cycle. The overview of the statuses a production order can have includes the
following.
• Created: Status of the production order when it is first created.

• Estimated: Status of the production order after you run a material
and cost estimation.
• Scheduled: Status after you run operation or job scheduling.
• Released: Status when production orders are scheduled and released
to production.
• Started: Status of the production order when production starts.
• Reported as finished: Status of the production order when
production is finished.
• Ended: Status of the production order after final costs are applied,
the item is complete, and the order is no longer active.
10-12
The first status of a production order is Created. When a production order has
this status, you can edit the production's BOM and route. However, changes to
the production's BOM or routes when it has any status other than Created, require
that the previous update jobs be run again. For example, if you make changes in a
BOM or route for a production in which the status is Released, then the prior
steps Estimated and Scheduled must be run again. Not all steps are required for a
production order. The steps that are required are based on the configuration of the
Production control parameters.
The following topics provide a review of the production control steps, with an
emphasis on how each step applies to financial journals and the interaction with
the general ledger.
Step 1 – Created
When you create production orders, you can specify the settings that determine
how production order transactions are posted to the ledger. These settings apply
to production orders created manually or automatically from a sales order or
master planning schedule.
Step 2 – Estimated
This step involves the calculation of the most likely material and labor for the
production. The system creates inventory transactions that are issue transactions
for raw materials with the status of On order and receipt transactions for the
BOM with the status of Ordered. In some cases, the system will create purchase
orders and subproductions for the production order. Items are reserved and the
prices of the finished goods are calculated based on parameter settings.
Step 3 – Scheduled
The third step in the production order life cycle is Scheduled. Production orders
can be scheduled based on operations scheduling or job scheduling.
• Operations scheduling: This scheduling method creates a rough

long-term plan. By using this method, the system assigns start and
end dates to production orders.
• Job scheduling: This scheduling method provides a detailed plan.
Each operation is broken down into individual jobs with specific
dates, times, and assigned resources. If finite capacity is used, jobs
are assigned to resources based on availability.
Step 4 – Released
In this step, the system releases the production order when the schedule is
realistic. At this point, you can print production order documents such as the job
card and the route card. Now, the status of the production order changes to
Released and indicates that the production can start.
10-13
Step 5 – Started
When a production order is started, you can post costs against the order. You can
automatically allocate estimated material and route costs to the order when it is
started. This allocation is known as forward 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 use
operations scheduling, you can allocate these costs by creating a route card
journal. If you use job scheduling, you can allocate these costs by creating a job
card journal.
Step 6 – Reported as Finished
When the production order is reported as finished, the quantity of finished goods
completed is updated in the Inventory and warehouse management module. If
you use work-in-process (WIP) accounting, the system uses the standard cost
from the On-hand form to create a ledger journal to reduce the WIP accounts
and increase the inventory of the finished goods.
If the material and labor costs associated with the production are not already
allocated in a journal or by forward flushing, they can be automatically allocated
by back-flushing. This involves the post-deducting of inventory transactions
processes.
Step 7 – Ended
Before you end production, the system calculates the actual costs for the
produced quantity and all estimated costs of material, labor, and overhead are
reversed and replaced with the actual costs. If you select the End job check box
when you run the cost calculation, the production order status changes to Ended.
This status prevents any additional costs from being unintentionally posted to a
completed production order.
10-14
Production Order Data Model

The following figure shows the data model for the primary tables related to
production orders.
FIGURE 10.5 PRODTABLE RELATIONSHIP DIAGRAM
The ProdTable is the primary production order table, which contains the header
information about all of the production orders. Each production order contains is
related to at least one InventTransOrigin and InventTrans table record. Each
production order can be connected to a planned production order, a sales order or
a project.
When a production order is created from master planning, the planned production
order is stored in the ReqPO table. The ProdTableProj table contains information
about production orders that belong to projects. Such a production order is
connected to a real production order stored in the ProdTable table and to a project
stored in the ProjTable table.
The ProdBOM table contains a productions bill of materials. This information is

copied from the BOM and BOMTable.
10-15
The ProdRoute table contains production route information. This information is

copied from the Route and RouteTable. The WrkCtrActivity table is an interface
to activities that are defined in other tables. The WrkCtrProdRouteActivity table
works as an interface to the ProdRoute table. The WrkCtrActivityRequirement
table is a supertype for activity requirements.
Production Order Journal Framework

Production journals contain a record of each different type of transactions that
occur when you are working with production orders. These transactions have a
direct effect on the company's financial records.
Production journals are located by opening Production control > Common >
Production orders > All production orders. Click the View tab in the Action
Pane, and then you can view the journal types in the Journals group. The
production journal types include the following.
• Picking list: This journal is a record of the raw materials removed

from the inventory.
• Route card: This journal is a record of the route consumption.
• Job card: This journal is a record of the resource consumption by
using feedback job cards.
• Reported as finished: This journal is a record of finished items.
When a production journal posts, all transactions are automatically transferred to

the General ledger. The General ledger is the centralized location for financial
information in Microsoft Dynamics AX 2012. Information posted from various
journals in the system is used in the General ledger when companywide financial
transactions are calculated.
Production journals consist of two main parts—the journal header and the journal
lines, or actual journal records. Journal lines reflect the actual records or entries
present in the journal. These records can include a list of production materials
ready for release, the time consumed, the number of good and defective items,
and so on.
Production Order Classes

The following are three important production classes, including sample code.
ProdMulti
You can update production orders one at a time or update multiple orders one
time. You can use the RunBaseMultiParm structure to run different parameter
(parm) tables that use the same structure. The ProdMulti class is the base class
that you can use to update production orders. It is based on the
RunBaseMultiParm class. A user interface (UI) should be implemented for
derived classes.
10-16
Syntax:
class ProdMulti extends RunBaseMultiParm
Much of the functionality is the same as what is implemented in Microsoft

Dynamics® AX 2009, with a large increase from six extensions on the base
ProdMulti class to eleven.
From the base UI form, it makes a call to ProdMulti for all updates. For example,
updating to Estimated calls ProdMultiCostEstimation::main().
1. View the ProdMultiCostEstimation::main() method:
public client server static void main(Args _args)

{
ProdMultiCostEstimation prodMultiCostEstimation;
if (_args.parmEnum() == RunChoose::Run)
{
prodMultiCostEstimation =
ProdMultiCostEstimation::construct(_args);
RunBaseMultiParm::initFromForm(prodMultiCostEstimation,_arg
s);
if (! prodMultiCostEstimation.prompt())
return;
prodMultiCostEstimation.runOnServer();
prodMultiCostEstimation.refreshCaller(_args);
}
else
{
RunBaseMultiParm::runSpecial(_args);
}
ProdMultiCostEstimation is instantiated, and then passed into the static method

RunBaseMultiParm::initFromForm(), together with args.
2. View the RunBaseMultiParm::initFromFormInternal() method:
/// <summary>
/// Initializes an instance of the <c>RunBaseMultiParm</c>
class by using a container of packed records.
/// </summary>
/// <param name="_includeRecords">
/// A Boolean parameter that indicates whether records are
included.
/// </param>
10-17
/// <param name="_packedRecords">

/// A container of packed records.
/// </param>
private void initFromFormInternal(boolean
_includeRecords,
container _packedRecords)
{
Common common;
int recordCounter;
ParmBuffer parmBuffer;
//sets the parm id

RunBaseMultiParm::initParm(this);
//init and insert update parameters that goes for all

updates.
this.insertParmUpdate(this.defaultParmUpdate());
if (_includeRecords)
{
parmBuffer = this.defaultParmBuffer();
parmBuffer.Linenum = 0;
for (recordCounter = conLen(_packedRecords);

recordCounter >= 1; --recordCounter)
{
parmBuffer.Linenum++;
common = conPeek(_packedRecords,
recordCounter);
this.insert(common,parmBuffer);
}
}
}
parmBuffer is a table map that is mapped to the different parm tables.

RunBaseMultiParm.defaultParmBuffer() is overridden in the sub-classes and
returns the appropriate parm table.
RunBaseMultiParm::initParm() retrieves saved data (from sysLastValue by

calling getLast()) and sets the ParmId used in the update.
static server void initParm(RunBaseMultiParm

runBaseMultiParm)
{
runBaseMultiParm.getLast();
runBaseMultiParm.initParmId();
}
All selected records in the form data source are added to the appropriate parm
table. If the update is called from the main menu, there is no data source and no
records are found.
10-18
3. Return to the ProdMultiCostEstimation::main() method.
public client server static void main(Args _args)

{
ProdMultiCostEstimation prodMultiCostEstimation;
if (_args.parmEnum() == RunChoose::Run)
{
prodMultiCostEstimation =
ProdMultiCostEstimation::construct(_args);
RunBaseMultiParm::initFromForm(prodMultiCostEstimation,_arg
s);
if (! prodMultiCostEstimation.prompt())
return;
prodMultiCostEstimation.runOnServer();
prodMultiCostEstimation.refreshCaller(_args);
}
else
{
RunBaseMultiParm::runSpecial(_args);
}
The prompt displays the form where the user can change the settings to update
the order. There is also a Select button on the form that the user can click to
modify the query and select more records. When the form is opened from the
main menu (Production control > Periodic > Production orders), the query is
empty and the user must click this button to select the records for update.
The run() method is then called.
4. View the ProdMultiCostEstimation.run() method:
...
while (curParmCostEstimation)
{
try
{
prodTable =
this.initProdTable(curParmCostEstimation.ProdId);
prodTable.status().runCostEstimation(curParmCostEstimation,
false,prodPurch,this);
}
catch (Exception::Deadlock)
{
retry;
}
...
10-19
next curParmCostEstimation;
}
}
All records in the parm table are looped over. The ProdStatusType sub-class is
instantiated by using the status of the prodTable record, then the update is called.
ProdStatusType
Production order updates are controlled by using the ProdStatusType class and
subclasses.
Each stage of the update process must occur. If the current status of an order is
Estimated, and you try to update it to Report as Finished, then it must be
Scheduled, Released, and Started before it can be reported as Finished. The
required status and status sequences are configured in the Production control
parameters form.
Before each update is run, the system checks to determine whether the previous
status is already processed. If the update is not installed, then the system runs that
update. It also handles which updates can occur with a production order. For
example, a production order with the status Finished, cannot be Estimated.
Update a Production Order with a Status of Released to a

Status of Report as Finished
The update to the status is called by ProdMultiReportFinished, which is

discussed in the next section.
The following steps demonstrate the use of ProdStatusType.
1. View ProdMultiReportFinish.Run().
...
while (prodParmReportFinished)
{
try
{
this.initProdTable(prodParmReportFinished.ProdId).status().
runReportFinished(prodParmReportFinished,false,this);
}
catch (Exception::Deadlock)
{
retry;
}
...
next prodParmReportFinished;
}
}
10-20
ProdMultiReportFinished.Run() instantiates the ProdStatusType_Released

subclass by using the status of the production order, and calls
ProdStatusType.runReportFinished().
2. View ProdStatusType.runReportFinished().
...
if (!_ask)
{
if
(this.shouldRunPreviousJob(ProdStatus::ReportedFinished))
{
ProdUpdReportFinished::runPreviousJob(
_prodParmReportFinished,
_multi);
}
prodTable.type().runReportFinished(
_prodParmReportFinished,
_multi);
}
return true;
...
ask is set to true only when the method is called to ask whether the update is
allowed, not to run the update.
ProdUpdReportFinished::RunPreviousJob runs the update to the status Started.
3. View ProdUpdReportFinished::RunPreviousJob.
static void runPreviousJob(

ProdParmReportFinished
prodParmReportFinished,
RunbaseRecsMapable _multi
= null)
{
ProdParmStartUp prodParmStartUp =
ProdUpdStartUp::initParmBufferFromRepFin(prodParmReportFini
shed);
prodParmStartUp.insert();
ProdTable::find(prodParmStartUp.ProdId).status().runStartUp
(
prodParmStartUp,
10-21
false,
null,
_multi);
}
A record in ProdParmStartUp is created by using the ProdParmReportFinished

record that is used for the update to Report as Finished.
The ProdStatusType_Released sub-class is instantiated by using the status of the

production order and calls ProdStatusType.runStartUp().
4. View the ProdStatusType.runStartUp() method.
if (!_ask)
{
if (this.shouldRunPreviousJob(ProdStatus::StartedUp))
{
ProdUpdStartUp::runPreviousJob(
_prodParmStartUp,
_prodPurch,
_multi);
}
prodTable.type().runStartUp(
_prodParmStartUp,
_multi);
}
return true;
Because the previous status to Started is released, and because this order is
already released, it is not necessary to run the previous job.
As soon as the update to the status Started occurs, it returns to

ProdStatusType.runReportFinished(), then runs the update to Report as Finished.
10-22
ProdUpd
The ProdUpd class is the base class of production classes used to update the
production order status. The following figure shows the class hierarchy for the
ProdUpd class.
FIGURE 10.6 PRODUPD CLASS HIERARCHY
The ProdUpd class is an abstract class, and you cannot make an instance out of it.
You can only inherit this class from other production update classes. To update
production order stage, the following classes are used:
• ProdUpdBOMCalc
• ProdUpdCostEstimation
• ProdUpdScheduling
o ProdUpdScheduling_Operation
o ProdUpdScheduling_Job
• ProdUpdRelease
• ProdUpdStartUp
• ProdUpdReportFinished
• ProdUpdHistoricalCost
To decrease production order status, the following classes are used:
• ProdUpdStatusDecrease
o ProdUpdStatusDecrease_CostEstimate
o ProdUpdStatusDecrease_Finished
o ProdUpdStatusDecrease_Release
o ProdUpdStatusDecrease_Schedule
o ProdUpdStatusDecrease_StartUp
10-23
When a production order is updated, there are two main events that can occur.
• The status is updated to the new status.

• Journals can be created and posted to consume items and operations
as required, depending on the settings on the update, the production
parameters, and the item. For example, updating to Started could
post the picking list journal and consume all items in the BOM at this
point.
ProdStatusType.RunStartUp() runs the update to the Startup status.
The following steps demonstrate the use of ProdUpd.
1. View the ProdStatusType.RunStartUp() method. This method was reviewed

earlier in the "ProdStatusType" topic.
ProdUpdStartUp is instantiated by using the parm table, and then run.
2. View the ProdUpdStartUp.run() method.
void run()
{
#OCCRetryCount
RecordViewCache viewCacheProdRoute;
setprefix(ProdMultiStartUp::description());
setprefix(#PreFixField(ProdParmStartUp,ProdId));
try
{
ttsbegin;
this.setParameters();
if (! this.validate())
{
throw Exception::Error;
}
viewCacheProdRoute = null;
viewCacheProdRoute =
ProdRoute::viewCacheProdId(prodTable.ProdId,true);
this.updateProduction();
this.updateBOMConsumption();
prodTable.status().startUpUpdateRouteJobs(this);
this.updateRouteConsumption();
this.startupReferences();
this.updateJobJournal(ParmJobStatus::Executed);
TransactionLog::create(TransactionLogType::ProdStartUp,
strfmt("@SYS76498",
10-24
prodTable.ProdId,
"@SYS77138"));
ttscommit;
this.printout();
}
...
ProdUpdStartUp.setParameters() retrieves ProdTable and initializes BomCalc. It

is called when component dimensions are used in the calculation of item
consumption.
viewCacheProdRoute activates cache on all prodRoute records for the current

production order.
3. ProdUpdStartUp.updateProduction updates the prodTable.Status,

prodTable.StartedUpQty, and prodTable.StUpDate.
void updateProduction()
{
if (prodParmStartUp.StartUpProduction)
{
prodTable.QtyStUp += prodParmStartUp.StartUpQty;
}
prodTable.ProdStatus =
prodTable.status().isBefore(ProdStatus::StartedUp) ?
ProdStatus::StartedUp : prodTable.ProdStatus;
prodTable.StUpDate = prodParmStartUp.PostDate ?
prodParmStartUp.PostDate : systemdateget();
prodTable.update();
this.addUpdateRec(prodTable);
}
4. ProdUpdStartUp.updateBOMConsumption() creates the picking list journal. If

the update is set to post the BOM consumption, it also posts the journal.
5. The production route is updated and the route journal is created and posted.
(This sample comes from the ProdUpdStartUp.run method reviewed earlier.)
this.startupReferences();
this.updateJobJournal(ParmJobStatus::Executed);
TransactionLog::create(TransactionLogType::ProdStartUp,
strfmt("@SYS76498", prodTable.ProdId, "@SYS77138"));
ttscommit;
10-25
Any references (meaning production orders that are created because of this
production order) are also updated, and the parm table record is updated to show
it is posted.
Scheduling
Scheduling is an iterative activity where the system tries to find a set of resources
that can deliver the product on or before the requested date. In the following
sections, you will review the main production scheduling concepts that provide
an overview of scheduling, resources, the resources data model, and jobs.
Scheduling Overview
The scheduling engine is aligned with the new resource model in Microsoft
Dynamics AX 2012. This introduces capabilities and priorities, and replaces
work centers and work center groups by using resources and resource groups.
You can run scheduling after the production order is created and estimated.
Production dates and other information important to the production process are
established at this point. The role of the scheduling system is to plan the actual
production process so that each operation in the production route is assigned a
starting and ending date and time, and that the materials needed for production
are available when the operation starts.
Another important role of the scheduling system is to assign jobs and operations
to a resource or resource groups. This depends on whether job scheduling or
operation scheduling is used. Running scheduling raises the production status to
Scheduled.
Resources Overview
Microsoft Dynamics AX 2012 introduces resources that are assigned to jobs and
operations. Resources can be different types including machines, tools, human
resources, vendors or locations. The scheduling engine aligns with the new
resource model and can schedule resources based on their capabilities. Resources
and capabilities replace work centers and task groups to provide for more
flexibility in setup and maintenance. In Microsoft Dynamics AX 2012, resources
can be allocated to jobs and operations by matching the capabilities of the
resources with the requirements of the operation.
Alternative resources with the same capabilities are considered, unless there are
requirements for a specific resource or resource group. This applies whether you
select to run job scheduling or operations scheduling. The selection process
consists of matching the requirements of the operation with the capabilities of the
resources. Other requirements, such as location, resource working time, and
resource type are also considered when planning the production. Microsoft
Dynamics AX 2012 has changed the following to the Operations Resource
Model.
10-26
• Separated the way resources are grouped for managing capacity from
the way resource requirements are specified for activities.
• Enabled resources to change resource groups and thereby location
(Site) over time.
• Eliminated the need for defining resources multiple times.
In the following section, you will review resources and recourse capabilities.
Resources
Resources are used throughout the production or project processes. They can be
machines, tools, people, vendors or locations that contribute to the production of
an item. After an operations resource is created, you can assign it to a resource
group and specific productions.
Resource groups have fixed location. You can move resources to another location
by reassigning them to a different resource group. However, a resource can only
be assigned to one resource group at a time. The Effective and Expiration date
fields on the Resource groups tab represent when the resource in question can
be used for production.
With this setup you can share a resource across many sites. When a resource
becomes a member of the resource group that has a different location, it
represents the physical move from one site to another. You can also copy
resources to make the setup of resources easier.
During the scheduling process, the capacity of a resource group is calculated as

the sum of the capacity of its resources. Resources are used in the detailed
planning of capacity requirements and in job scheduling. When job scheduling is
run, the operations in each resource are scheduled into individual tasks or "jobs."
Five types of resources are available.
• Vendor: Select this type when the resource is an external operations

resource, for example, with a subcontractor.
• Human resources: Select this type when the operations resource is a
worker. Typically, you schedule the human resources type if the
personnel capacity is limited.
• Machine: Select this type if the resource is considered a production
machine.
• Tool: Select this type if the resource is considered a tool. If you want
to schedule for tools, machines, or personnel at the same time, select
a primary operations resource that determines the capacity available.
• Location: Select this type if the resource is considered a location.
10-27
Resource Capabilities
Resource capabilities are a new concept in Microsoft Dynamics AX 2012. A

capability is the ability of a resource to perform a given activity relevant to
production and the scheduling of resources for production.
When designing a route, the requirements that resources must have to perform
the various operations in the route can be expressed as the set of resource
requirements. This allows the allocation of resources to be deferred until
production is scheduled.
You can define capabilities to organize the resources for your operation.
Resource planning and production scheduling depend on correctly defined
capabilities because the requirements of a production are matched with the
capabilities of a resource.
A capability must be assigned to a resource to effective. Two different resources

can have the same capability, but the specifics, such as grade, priority, or
effective date for the capability may be different for the two.
For example, a sheet metal press may have the “Aluminum sheet press”
capability assigned and have a grade of 50, whereas an older sheet metal press
would have the same capability assigned, but the older sheet metal press can only
manage a grade of 30.
Capabilities can also be assigned to resources on a temporary basis by defining a

start date and expiration date on the capability assignment. Capabilities that have
expired on a resource will prevent the resource being scheduled for production if
the production requires that capability. An expired capability can be renewed at a
later date. Additionally, a capability can also be assigned to any type of resource.
EXAMPLE:
On a route, the drilling process time is set to 10 units per hour, but the
requirement itself is defined as “Drilling”.
The capability “Drilling” is assigned to two different machine resources: M1

and M2.
M1 can drill two units per hour and M2 can drill 11 units per hour.
Both machines can be picked up by the scheduling engine because both satisfy
the requirement: “Drilling”. However, the M1 machine can only drill two units
per hour, far less than the 10 units per hour specified on the route. This will
cause production problems. To resolve this, two separate capabilities should be
created: “Low-speed drilling” and “High speed drilling”. “Low-speed drilling”
is defined by a drilling process time of one to nine units per hour. “High speed
drilling” is defined by a drilling process time of 10 to 19 units per hour.
10-28
In this setup, the M1 machine is given the “Low-speed drilling“ capability and
the M2 machine has the “High-speed drilling” capability. The scheduling engine
will then select the correct machine (M2).
Resource Requirements
When defining the requirements for a production route, you can also specify
skills, courses, certifications or title as requirements in addition to capabilities.
This does not require a relation to a worker. These values are set up in the
Human resource module and are not defined in the Capabilities form. When
defining skills, courses, certifications or title as requirements, you must have the
Human resources module enabled. You can define capabilities in the
Capabilities form that resemble or duplicate those from the Human resources
module. However, the Capabilities form does not contain the functionality that
is required to maintain skills, courses, certifications or titles.
• Skills: You can use the Skills form to create and manage
competencies that are specified for employees or jobs. An operation
can require a human resource with a specific skill, and the
scheduling engine will find resources with the specific skills. It does
this by searching for the skill information on the worker to which the
resource is linked. This is only applicable for job scheduling, and not
operation scheduling.
• Courses: You can create and maintain the courses your employees
have attended. An operation can require a human resource with a
specific course, and the scheduling engine can find resources with
specific courses. It does this by searching for the course information
on the worker to which the resource is linked. This is only applicable
for job scheduling.
• Certificate: You can add certificates to a user in human resources
and use this to track all employee certificates. An operation can
require a human resource with a specific certificate, and the
scheduling engine can find resources with specific certificates. It
does this by searching for the certificate information on the worker to
which the resource is linked. This is only applicable for job
scheduling.
• Title: The title an employee has can also be a requirement for a job.
An operation can require a human resource with a specific title, and
the scheduling engine can find resources with specific titles. It does
this by searching for the title information on the worker to which the
resource is linked. This is only applicable for job scheduling.
10-29
Resources Data Model

The resources data model is changed significantly in Microsoft Dynamics AX
2012. It moved from a work center model to a resources model that is more
flexible, date effective, and able to handle production operations.
To make sure the system can be easily upgraded from earlier versions, the table
names have not changed. For example, ResourcesTable continues to be called
WrkCtrTable in the physical data model, with the changes in the content of the
table, and in many new relationships.
An example of the new relationship model is the work center resource group,
represented by the WrkCtrResourceGroup table. Now through the association
with the Resource Calendar, WorkCalendarTable (new), and
WrkCtrResourceGroupResource, any resources can have scheduled working
times based on the calendar that is attached to a specific resource. Now the model
can support equipment downtime, swap outs, and upgrades. Additionally, it also
incorporates a more realistic model of human resource management where
workers and other personnel are not available continuously.
The following diagram shows the new resource table associations.
FIGURE 10.7 RESOURCES TABLE ASSOCIATIONS
10-30
Jobs Overview
Scheduling types differ from one another as measured by detail. Operations
scheduling is limited to scheduling by date (while calculating the duration of the
individual operation), whereas job scheduling calculates the starting and ending
times of individual operations throughout the day. Additionally, there is a
significant difference in the way operations are planned and in how scheduling is
performed in resource groups. Job scheduling splits the different operations into
jobs, and they are planned in detail, for each of the operation resources. When
allocating resources to an operation, the system examines the following resource
requirements types.
• Specific resource
• Specific resource group
• Resource type
• Capability
• Skill
• Course
• Certificate
• Title
These requirements types are important to many companies.
EXAMPLE: Food and drug companies because their modern production

facilities must be in compliance with the United States Food and Drug
Administration (FDA), Code of Federal Regulation, (CFR) Title 21, Part 11,
requirements that involve the validation and control of safe practices. The system
is designed to make sure that workers are educated in their respective positions
and can validate they are current on all training, certifications, and have
sufficient authority (through title) to complete operations.
Planned Production Orders

In Microsoft Dynamics AX 2012, master planning acts as the planning engine for
automated integration to the Production control module, and it calculates the
following.
• What to produce: Based on information about open sales orders,

on-hand inventory, and sales forecasts.
• When to produce it: Based on, for example, delivery dates for sales
orders.
• How much to produce: Based on the need to fulfill sales orders,
maintain safety stock, and cover requirements that derive from
production orders.
10-31
• Net requirements of what is needed in a production order: A plan

is usually run as an overnight batch process in most companies so
that the list of requirements that includes materials and
subcomponents, is updated with changes and additions every
morning.
When the requirements are not met by the current inventory, a planned
production order can be issued that specifies what is needed and when. Then the
planner knows what is missing and he or she can make decisions about how to
meet these requirements.
NOTE: Master planning can generate several types of planned orders such as
planned transfer, planned purchases, or kanbans, not just planned production
orders.
The following figure shows the steps for the Master planning module that must
be completed to run and generate the planned production orders.
FIGURE 10.8 MASTER PLANNING BUSINSESS PROCESS
10-32
LEAN Manufacturing
Lean manufacturing is a both a process philosophy and workable process
methodology. It introduces best practice material handling and best in class
manufacturing methods that are now standard across industries. The core
concepts for lean manufacturing provide a base level understanding of the system
functionality within Microsoft Dynamics AX 2012.
In the following section, you will review the Lean production principles, the
overview and rules for Kanban, and production flow processes.
LEAN Manufacturing Overview

Five Lean Principles
The five Lean principles include the following.
• Customer Value: When you identify the value, you specify what
creates value from the customer's perspective.
• Identify the Value Stream: The Value Stream is the sequence of
processes that start from the raw material to the final customer or
from the product concept to the market launch. If it is possible, view
the whole supply chain.
• Flow: Create flow wherever possible in the process. Use one piece of
the flow by linking all the activities and processes into the most
efficient combinations to maximize value-added content while
minimizing waste.
• Pull: Make only what is needed by the customer (short term response
to the customer’s rate of demand).
• Perfection: In striving for perfection, Lean is a journey of
continuous improvement. The goal is to economically produce
exactly what the customer wants, and exactly when the customer
wants it. Because perfection is an aspiration, anything and everything
can be improved.
Kanban Overview
In Microsoft Dynamics AX 2012, the Lean manufacturing module introduces
kanbans as a pull-based just-in-time production system. Kanbans relate to a
sequence of kanban jobs. Each kanban job has a status that indicates its current
stage in the production or transfer process. Each kanban also has a status, the so-
called handling unit status that indicates the overall state of a kanban and the
related handling unit.
10-33
Kanban means visible record in Japanese, and it is adopted by many industries as

a method of controlling production and internal supply. Kanban is an important
part of a pull system of supply, which is a very important element of the Lean
production/supply. When a Kanban is consumed, it should be passed (triggered)
to the source of supply to replenish it. This source of supply is defined through
the production flow activities that the Kanban is linked to. It provides the
definition of how the Kanban is filled.
All types of Kanbans can support manufacturing, or internal (store-to-store)

replenishment.
FIGURE 10.9 LEAN MANUFACTURING GRAPHIC
Kanbans are created based on kanban rules. Kanban rules operate on a

production flow or on part of a production flow. There are two types of kanbans:
• Withdrawal kanbans
• Manufacturing kanbans
Similarly, there are two types of kanban jobs:
• Process jobs
• Transfer jobs
10-34
Kanban and Kanban Rules Overview

Lean manufacturing in Microsoft Dynamics AX provides two Kanban types that
are used to define how the empty signal is filled—manufacturing and withdrawal.
Kanban Type: Manufacturing
A Kanban of the type “manufacturing” is assigned to at least one process that

adds value. The Kanban is assigned to a production flow activity and therefore a
resource group that has the role of a work cell, where the value is added.
Manufacturing Kanbans relate to at least one process activity. The first activity of
a manufacturing Kanban must be a process activity. A process activity can be
followed by a transfer or another process activity where the Kanban can span to
multiple activities.
Kanban Type: Withdrawal
A Kanban with the type “withdrawal” creates a transfer job that is based on a
single transfer activity. Withdrawal Kanbans are used to move a Kanban of a
specific item between supermarkets, warehouses, and production locations.
Withdrawal Kanbans do not add value.
Fixed Quantity Kanbans
A fixed quantity Kanban rule relates to a fixed number of bins or Kanban cards.
This means that the number of active Kanbans is constant. When a material
handling unit related to a Kanban is consumed (emptied), a new Kanban of the
same type is recreated. Fixed quantity Kanbans are frequently used with fixed
circulating cards, but can also be used with single use cards. When circulating
cards are used, the card is detached from the consumed Kanban and assigned to
the newly created Kanban.
Single Use Kanbans
A fixed quantity Kanban is a “make-to-stock” scenario. Additional single use

Kanbans can be used to cover additional demand to level specific exceptional
demand. Single use Kanbans are only (and always) based on fixed quantity rules
and no specific rules have to be created for this replenishment strategy. Instead,
the Kanbans have a flag that marks them as manual. You can also use event
Kanbans for exceptional demand above a certain quantity to maintain the buffer
stock of a fixed Kanban.
Scheduled Kanbans
Master planning creates scheduled Kanbans automatically for planned Kanban

orders to cover the requirements within the firm horizon of the production
forecast. Scheduled Kanbans can also be manually created.
10-35
Event Kanbans
Event Kanbans are only created out of the related demand so that those event
Kanbans belong to the category “make-to-order.” The creation of event Kanbans
is initiated when certain events occur. In Microsoft Dynamics AX 2012, these
events include when you create sales lines, estimate production orders based on
the creation of upper level Kanban demand, or when you reach a certain level of
on hand inventory.
Production Flow
Typically, a Lean manufacturing scenario is more than an accumulation of
unrelated Kanban rules or material supply policies. The flow of material and
products throughout work cells and locations for a specific production or supply
scenario is described as a sequence or small network of process or transfer
activities, which is known as a production flow.
Microsoft Dynamics AX 2012 introduces the activity based production flows to

establish a production and cost context for various Kanban scenarios. All Kanban
rules are directly connected to this predefined structure. The activity based model
is used to set up a wider range of scenarios than those supported by earlier
versions of Lean manufacturing in Microsoft Dynamics AX. Additionally, it is
now easier for shop floor workers to use because all scenarios use the same
activity based user interface.
Production Flow Function
Production flows are the backbone of Lean manufacturing, and they perform the
following functions.
• Define the process and transfer activities of the Value Stream.

• Support the Kanban rules in defining the activities a Kanban follows.
• Provide an activity based context for the planning and production
processes.
• Establish a cost context for the various Kanban production scenarios.
To better support continuous improvement, the production flows are

implemented in time-effective versions. You can copy an existing production
flow version—including all related Kanban rules—to a future version of the
production flow, and model the future-state production flow before validating
and activating it for production. Existing Kanbans from old production flow
versions are automatically related to the new version to make sure a seamless
material flow on the transition date and beyond.
Creating and Activating a Production Flow Version
To map a Lean manufacturing scenario to Microsoft Dynamics AX, the

definition of a production flow is mandatory. The production flow defines the
organizational context of a manufacturing scenario and relates to accounting and
costing.
10-36
The production flow requires the following settings.
• Unique name
• Description
• Legal entity that owns the operations in the production flow
• Operating unit of type value stream
NOTE: An operating unit can be configured to be used as a financial dimension.
• A production group.
NOTE: The production group defines the set of accounts that are used for the
financial postings that are related to the production flow. The most important
accounts are the WIP and Offset accounts. These are the basis of the variance
calculation for the production flow.
The setting of the financial dimension for the production flow is optional.
TIP: For more information about lean manufacturing, refer to the following two
whitepapers.
Lean manufacturing - kanban and pull-based manufacturing

(http://go.microsoft.com/fwlink/?LinkId=238243)
Lean Manufacturing – Production flows and activities

(http://go.microsoft.com/fwlink/?LinkId=238244)
Additionally, you can refer to the Lean Manufacturing for Microsoft Dynamics
AX 2012 course.
Process Industries
Process Manufacturing for Microsoft Dynamics AX 2012 supports a range of
manufacturing processes. This includes make to order, make to stock, and mixed
mode. Mixed mode is a hybrid environment that enables discrete, lean, and
process requirements to coexist. You can integrate production processes to build
a flexible solution that meets your needs.
Overview
Process industry requirements are reflected in the following Microsoft Dynamics
AX 2012 functionalities.
• Integration with the Manufacturing execution system

• Integration with Warehouse Management Systems II (WMSII)
10-37
• Supporting catch weight throughout multiple areas of Microsoft

Dynamics AX 2012
• Improvements to formula maintenance and control
• Improved customer rebates
• Integration with sales and purchase agreements
• Integration with delivery schedules
• Improved integration to quality management
• Improved product compliance
• New inventory batches list page used to perform most inventory
batch related actions from one form
• Improved production costing calculations
• Additional functionality and validations for batch attributes including
the ability to assign targets for all attribute types
• Enabling non-stock items, catch weight items, stocked items to work
with the Process manufacturing solution
• Improved commodity pricing to include financial dimensions
• Report modifications for easier tracking of catch weight, shelf
advice, and batch costing
Some features can be used with any license of Microsoft Dynamics AX2012,
while other features can be used only with a Process Manufacturing installation.
The two installations for Process Manufacturing include the following.
• Process Manufacturing Logistics: The Process Manufacturing

Logistics installation contains all production and manufacturing
functionality.
• Process Manufacturing Distribution: The Process Manufacturing
Distribution installation contains all inventory distribution
functionality.
If your organization wants to use the Process Manufacturing solution, you must
implement one or both of the Process Manufacturing installations.
10-38
Lab 10.1 - Bill of Material

This lab demonstrates how to modify the bill of material framework.
Estimated time to complete: 15 minutes
Scenario
Victor, the Business Systems Developer, is tasked to add a BOM line item field
to both the BOM and ProdBOM tables. Specifically, the Finance team wants a
new check box called "IsReturnable" to represent if the item or good is
returnable. The objective is to make sure that if the BOM is canceled before the
actual production, the Logistics group is aware they can receive a refund for the
unused goods that are planned for on the BOM, or picked for the ProdBOM.
Challenge Yourself!
Use the following tables, maps, and forms to create a new field for Victor to
track returnable items at the BOM line level.
• BOM table
• ProdBOM table
• ProdBOM form
• BOMConsistOf form
• BOMMap
Need a Little Help?
1. Create a new enum extended data type.

2. Create a project.
3. Drag the new data type to the project.
4. Drag the BOM table and ProdBOM tables to the project.
5. Attach the new data type to the tables.
6. Save and restore the project.
7. Drag the BOMConsistOf and ProdBOM forms to the project.
8. Drag the new fields in the BOM and ProdBOM to the
BOMConsistOf and ProdBOM forms
9. Save and compile.
10. Test and check the BOM form.
11. Drag the BOMMap to the project.
12. Attach the new enum extended data type to BOMMap.
13. Configure for both BOM and ProdBOM.
14. Save and compile.
10-39
15. Test and check the form.

16. Test and validate the Production order and Production order
details forms.
Step by Step
1. Open the Development Workspace.

2. In the AOT window, expand the Data Dictionary node and then
right-click the Extended Data Types node and select New > Enum.
3. Set the following properties.
a. Name = IsReturnable
b. Label = Is returnable
c. Help text = Item can be returned to the vendor
d. Enum Type = NoYes
4. Save the extended data type. If you are prompted to synchronize the
database, select Yes.
5. Create a project (View > Project or Ctrl+Shift+P ).
6. Right-click the Shared space, New > Project.
7. Name the project.
8. Open the project.
9. Drag the new IsReturnable extended data type to the project.
10. Find the BOM table in the AOT.
11. Drag BOM table to the project.
12. Expand to the Fields node.
13. Find the ProdBOM table in the AOT.
14. Drag the ProdBOM table to the project.
15. Expand the Fields node.
16. Right-click IsReturnable(usr) and select Open New Window.
17. From the new window drag IsReturnable to the BOM fields and the
ProdBOM tables.
18. Close the AOT window with the IsReturn(usr) extended data type.
19. Save the project.
20. In the AOT window, expand the Forms node and locate
BOMConsistOf and ProdBom.
21. Drag the forms to the project.
22. Right-click the project and select Restore.
23. Expand the BOMConsistOf form to Data Sources > BOM > Fields
> IsReturnable, and then right-click and select Open New Window.
24. Expand the BOMConsistOf form to Designs > Design >
[Group:GroupBOM] > [Tab:Tab] > [TabPage:Overview] >
[Grid:GridBOM].
25. Drag IsReturnable to the [Grid:GridBOM].
10-40
26. Close the AOT window with the IsReturnable form.

27. Expand the ProdBOM form to Data Sources > ProdBOM > Fields
> IsReturnable, and then right-click and select Open New Window.
28. Expand the ProdBOM form to Designs > Design > [Tab:Tab] >
[TabPage:Overview] > [Grid:Grid].
29. Drag IsReturnable to the [Grid:Grid].
30. Save and compile the project.
a. Test and check the BOM form. In Microsoft Dynamics AX
2012, open Product information management > Common >
Released products.
b. Select the record 11001 HomeTheaterSystem7.1High Perf.
c. Click the Engineer tab in the Action Pane. Click Lines in the
BOM group.
d. The new IsReturnable check box will display.
e. Check item number 1101.
31. In the AOT window, open Data Dictionary > Maps > BOMMap
and drag it to the project.
32. Expand BOMMap > Fields.
33. Right-click IsReturnable and select Open New Window.
34. Drag it to the BOMMap fields’ node.
35. Right-click BOMMap and select Restore.
36. Expand BOMMap > Mappings > BOM.
37. Map IsReturnable to IsReturnable in the Properties form.
38. Expand BOMMap > Mappings > ProdBOM.
39. Map IsReturnable to IsReturnable in the Properties form.
40. Save and compile the project.
41. Test and validate the Production order form.
a. In Microsoft Dynamics AX 2012, open Production Control >
Common > Production Orders > All production orders.
b. Click Production order in the New group of the Action Pane.
c. Select item number 11001 HomeTheaterSystem7.1High Perf.
d. Click Create.
e. Double-click the newly created production order.
42. Click the BOM in the Production details group of the Action Pane.
In the BOM form, verify that the Is returnable field is selected for
item number 1101.
TIP: You can import the AX2012_ENUS_DEVIV_10_01_LAB_SOL.xpo file to

verify and compare your solution.
10-41
Summary
A bill of material is a complete list of all the components, parts, raw materials,
assemblies and their quantities that are required to make a finished product. The
BOM Version identifies which BOM to use for producing an item under specific
circumstances.
Routes and operations are the path that the item takes from operation to
operation, starting with the beginning of the production process and continuing to
the end. It is a set of sequential operations, or tasks, that are required to produce
an item.
Production orders are used to track information about what is to be produced,

how much (quantity), and the planned finish date. The system assigns an order
status to each step in the life cycle of the order. The status shows where the item
is in the production process. Scheduling assigns resources and attempts to
schedule the operations on possible dates and times so that the requested date can
be met.
Planned production orders are created by master planning when requirements are
not met by current inventory. A planned production order is issued that specifies
what is needed and when. Then the planner knows what is missing and he or she
can make decisions about how to meet these requirements. This interacts with the
journals for each step for both real time information and auditing purposes.
Lean is a both a process philosophy and a workable process methodology. It

introduces best practice material handling and best in class manufacturing
methods that are now a standard across industries. Microsoft Dynamics AX 2012
integrates the concept of Kanbans and their effect on the production process.
You can integrate production processes in Microsoft Dynamics AX 2012 to build

a flexible solution that meets your needs by using process industries
functionality.
10-42
Test Your Knowledge

Test your knowledge with the following questions.
1. Which of the following are items that are found on a BOM? (Select all that
apply)
( ) Components
( ) Parts
( ) Assemblies
( ) Raw materials
2. Which of the following is not a BOM line type?

( ) Phantom
( ) Pegged
( ) Vendor
( ) Shortest route
3. The applicable resources of an operation in Microsoft Dynamics AX 2012

can be restricted by which new feature?
( ) Operations to perform
( ) Capabilities
( ) Sequence of operations
( ) Customer value
4. Which of the follow is true about Production Orders? Select all that apply.
( ) Meeting sales demand when inventory is insufficient
( ) Creating safety stock based on possible demand
( ) Developing templates for receiving control
( ) Supply the BOM as sub-assemblies to other items in demand
10-43
Quick Interaction: Lessons Learned

Take a moment and write down three key points you have learned from this
chapter
1.
2.
3.
10-44
Solutions
Test Your Knowledge
1. Which of the following are items that are found on a BOM? (Select all that
apply)
(√) Components
(√) Parts
(√) Assemblies
(√) Raw materials
2. Which of the following is not a BOM line type?

( ) Phantom
( ) Pegged
( ) Vendor
(•) Shortest route
3. The applicable resources of an operation in Microsoft Dynamics AX 2012

can be restricted by which new feature?
( ) Operations to perform
(•) Capabilities
( ) Sequence of operations
( ) Customer value
4. Which of the follow is true about Production Orders? Select all that apply.
(√) Meeting sales demand when inventory is insufficient
(√) Creating safety stock based on possible demand
( ) Developing templates for receiving control
(√) Supply the BOM as sub-assemblies to other items in demand
10-45
10-46

Chapter 10: Use and Design of The Production Control Module: Objectives

Uploaded by

Copyright:

Available Formats

You might also like

Chapter 10: Use and Design of The Production Control Module: Objectives

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 10: Use and Design of The Production Control Module: Objectives

Uploaded by

Copyright:

Available Formats

Chapter 10: Use and Design of the Production Control Module

CHAPTER 10: USE AND DESIGN OF THE

• Review the basics of bill of materials and the data model

FIGURE 10.1 PRODUCTION CONTROL OVERVIEW

• Bill of materials: A list of all parts, components, and raw materials

BOM Product Types

BOMs can contain two types of products in Microsoft Dynamics AX 2012,

• Item: An item in a BOM that is defined as the product type Item is

o Painting: That has a product type of service because the

BOMs with Sites

When a BOM contains another BOM as its component, then it is known as a

BOM Lines and Line Types

There are four types of BOM lines in Microsoft Dynamics AX 2012.

• Item: The item is a raw material or semi-finished item that must be

• Vendor: A vendor provides the component item and the method

The manufactured item information that is used in a standard cost BOM

BOM Data Model

FIGURE 10.2 BOM DATA MODEL

Routes and Operations Feature Overview

Operations are set up in sequence to establish an appropriate order and context

• Know which task or activity must be completed

Operation relations simplify and streamline the creation and maintenance of

• Each relation contains the information that is used by production

• The use of the operation relation is limited in the way it is attached to

However, complex networks are frequently needed to reflect the production

Another network operation is concurrent operations. In this case, prerequisites

The following figure displays a simple network, a complex network, and a

FIGURE 10.3 ROUTE NETWORKS

NOTE: Simultaneous operations can be modeled as primary or secondary

Routes and Operations Data Model

The following figure shows all the key Route tables.

FIGURE 10.4 ROUTE TABLE DIAGRAM

The following sections include an overview of production orders, orders statuses,

Production Order Feature Overview

In companies where production is conducted in-house, production orders are

• Meet sales demand when inventory is insufficient.

External Production Orders

If a production, or part of a production, is subcontracted and the component items

Production Order Statuses

• Created: Status of the production order when it is first created.

• Operations scheduling: This scheduling method creates a rough

Step 6 – Reported as Finished

Production Order Data Model

FIGURE 10.5 PRODTABLE RELATIONSHIP DIAGRAM

The ProdBOM table contains a productions bill of materials. This information is

The ProdRoute table contains production route information. This information is

Production Order Journal Framework

• Picking list: This journal is a record of the raw materials removed

When a production journal posts, all transactions are automatically transferred to

Production Order Classes

class ProdMulti extends RunBaseMultiParm

Much of the functionality is the same as what is implemented in Microsoft

1. View the ProdMultiCostEstimation::main() method:

public client server static void main(Args _args)

ProdMultiCostEstimation is instantiated, and then passed into the static method

2. View the RunBaseMultiParm::initFromFormInternal() method:

/// <param name="_packedRecords">

//sets the parm id