Ax2012 Enus Deviv 10 PDF

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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
10-1
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 subassembly 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 o Blank Mug: That has a product type of item. 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-toorder 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 subcontractor. 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. 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 subBOM. 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 partsthe 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, } prodTable.type().runStartUp( _prodParmStartUp, } return true; _prodPurch, _multi);
_multi);
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 o ProdUpdScheduling_Operation ProdUpdScheduling_Job
ProdUpdRelease ProdUpdStartUp ProdUpdReportFinished ProdUpdHistoricalCost
To decrease production order status, the following classes are used: ProdUpdStatusDecrease o o o o o ProdUpdStatusDecrease_CostEstimate ProdUpdStatusDecrease_Finished ProdUpdStatusDecrease_Release ProdUpdStatusDecrease_Schedule 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 customers 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 socalled 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 filledmanufacturing 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 versionincluding all related Kanban rulesto 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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Create a new enum extended data type. Create a project. Drag the new data type to the project. Drag the BOM table and ProdBOM tables to the project. Attach the new data type to the tables. Save and restore the project. Drag the BOMConsistOf and ProdBOM forms to the project. Drag the new fields in the BOM and ProdBOM to the BOMConsistOf and ProdBOM forms Save and compile. Test and check the BOM form. Drag the BOMMap to the project. Attach the new enum extended data type to BOMMap. Configure for both BOM and ProdBOM. 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

Ax2012 Enus Deviv 10 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Ax2012 Enus Deviv 10 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Chapter 10: Use and Design of the Production Control Module

CHAPTER 10: USE AND DESIGN OF THE PRODUCTION CONTROL MODULE

Development IV in Microsoft Dynamics AX 2012

FIGURE 10.1 PRODUCTION CONTROL OVERVIEW

Chapter 10: Use and Design of the Production Control Module

BOM Product Types

Development IV in Microsoft Dynamics AX 2012

BOMs with Sites

Chapter 10: Use and Design of the Production Control Module

BOM Lines and Line Types

Development IV in Microsoft Dynamics AX 2012

BOM Data Model

Chapter 10: Use and Design of the Production Control Module

FIGURE 10.2 BOM DATA MODEL

Development IV in Microsoft Dynamics AX 2012

Routes and Operations Feature Overview

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

FIGURE 10.3 ROUTE NETWORKS

NOTE: Simultaneous operations can be modeled as primary or secondary operations.

Chapter 10: Use and Design of the Production Control Module

FIGURE 10.4 ROUTE TABLE DIAGRAM

Development IV in Microsoft Dynamics AX 2012

External Production Orders

Production Order Statuses

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

Chapter 10: Use and Design of the Production Control Module

FIGURE 10.5 PRODTABLE RELATIONSHIP DIAGRAM

Development IV in Microsoft Dynamics AX 2012

Production Order Journal Framework

Production Order Classes

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

Update a Production Order with a Status of Released to a Status of Report as Finished

this.initProdTable(prodParmReportFinished.ProdId).status(). runReportFinished(prodParmReportFinished,false,this); } catch (Exception::Deadlock) { retry; } ... next prodParmReportFinished; } }

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

Chapter 10: Use and Design of the Production Control Module

FIGURE 10.6 PRODUPD CLASS HIERARCHY

ProdUpdRelease ProdUpdStartUp ProdUpdReportFinished ProdUpdHistoricalCost

Development IV in Microsoft Dynamics AX 2012

setprefix(ProdMultiStartUp::description()); setprefix(#PreFixField(ProdParmStartUp,ProdId)); try {

ttsbegin; this.setParameters(); if (! this.validate()) { throw Exception::Error; }

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

Chapter 10: Use and Design of the Production Control Module

Development IV in Microsoft Dynamics AX 2012

FIGURE 10.7 RESOURCES TABLE ASSOCIATIONS

Chapter 10: Use and Design of the Production Control Module

Planned Production Orders

Development IV in Microsoft Dynamics AX 2012

FIGURE 10.8 MASTER PLANNING BUSINSESS PROCESS

Chapter 10: Use and Design of the Production Control Module

LEAN Manufacturing Overview

Development IV in Microsoft Dynamics AX 2012

FIGURE 10.9 LEAN MANUFACTURING GRAPHIC

Chapter 10: Use and Design of the Production Control Module

Kanban Type: Manufacturing