Chapter 8: Use and Design of the Sales and Purchase ModulesCHAPTER 8: USE AND DESIGN OF THE SALES AND PURCHASE MODULES Objectives The objectives are: • • • • • • • • • • • • • • • • • • • • • • • Review the general features that are supported with sales and purchase orders. Describe how sales and purchase orders integrate with other modules, Discuss the primary tables used in the purchase order flow. Describe how the PurchType, PurchLineType, and PurchTotals classes work. Describe how trade agreements are used and set up. Review the data model for trade agreements. Discuss how the trade agreement classes are used and can be extended. Describe how sales and purchase agreements are used and set up. Review the data model for sales and purchase agreements. Discuss how the sales and purchase agreement classes are used and can be extended. Describe how pricing policies are used. Describe how charges are used and set up. Review the data model for charges. Describe how the FormLetter framework is used. List the various documents that are processed through the FormLetter framework. Describe the data model for updating documents. Describe how the FormLetter classes relate to each other and generally work. Describe how to make modifications to the FormLetter framework. Describe the differences between the sales order and the sales quotation features, data model, and classes. Describe the differences between the purchase order and the request for quotation features, data model, and classes. Describe the differences between the purchase order and the purchase requisitions features, data model, and classes. Explain how to use and set up categories and category hierarchies. Review the data model for categories and category hierarchies. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-1 Development IV in Microsoft Dynamics® AX 2012 Introduction The sales and purchasing processes are important components of every business. Microsoft Dynamics® AX 2012 provides functionality businesses can use to manage purchase and sales information with the integration to inventory and the general ledger. The order to cash process is also referred to as the sales process, and involves many steps. These steps include gathering leads and opportunities that drive the creation of prospective customers, followed by the quotation process, and after the quotation is accepted, generating confirmed sales orders. Next is the picking and shipping of the products and then invoicing or billing the customer. After the customer receives the goods payment must be collected. Because every business has different processes the source to sell process steps can be conducted differently, Microsoft Dynamics AX 2012 helps businesses manage these processes that are usually controlled by the type of customer that includes, business-to-business (B2B), business-to-customer (B2C) or by specific business requirements. The procure to pay process is also referred to as the purchase process, and it also includes many steps, and is similar to the source to sell process. These steps include requesting and qualifying a new vendor, submitting purchase requisitions by employees requiring various products, followed by the request for quotation process with the vendor. When the purchase requisitions and, or the request for quotations are approved, purchase orders are generated and then confirmed with the vendor. After the products are delivered, a product receipt is generated and the invoice is recorded for the purchase order, and then payments must be generated to the vendor. This course introduces the features in Microsoft Dynamics AX 2012 that support the sales and purchase processes, and it also reviews the data models and coding patterns for many of the features. Since the customer and vendor data models and coding patterns are similar, the details of both will not be discussed. Sales and Purchase Orders This topic introduces the primary features available for sales orders and purchase orders in Microsoft Dynamics AX 2012. Additionally, the data models for sales and purchases will be reviewed and the coding patterns for purchases will also be discussed. Sales Order Feature Overview Sales orders in Microsoft Dynamics AX 2012 can be accessed from the Accounts receivable module and the Sales and marketing module. Although there are additional list pages and reports in each module that are different, the basic sales order information that is available in each module is identical. 8-2 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement Chapter 8: Use and Design of the Sales and Purchase Modules The primary components of a sales order consist of a header and one or more lines. Each sales order header is linked to one specific customer account. Each line of a sales order is linked to one specific item number or one specific sales category. When a sales order line is linked to an item number, the category field is defaulted based on the category assigned to the item. You can leave the item number field blank, and select only a category. Several types of sales orders exist and each has different functionality. • Journal: Does not have any inventory transactions, and cannot be processed. Most often it is used as a template or place holder for a future sales order. Sales order: The standard sales order that does have inventory transactions and can be processed. Subscription: Special sales order used for repeating, for example a magazine subscription. Return order: Used when a customer is returning items previously purchased on a sales order. The quantities on this order are always negative. Item requirements: Special sales order used with the Project management and Accounting module. These cannot be created manually, and can only be generated from a project. • • • • After a sales order is created and the customer, item or category, quantity, and pricing information are entered, the order must be processed. The four steps to process a sales order include the following. 1. Confirmation: The order entry process is completed and the details are printed or emailed to the customers to "confirm" the order. 2. Picking list: A document called a picking list is generated for the warehouse workers. The warehouse workers use this document to find the required items in the warehouse and bring them to a packaging or staging location for delivery. This is also referred to as "picking" the items. When this process is completed, the inventory is updated to show a status of picked so that the items cannot be used on other sales orders. 3. Packing slip: A document called a packing slip is generated for the delivery of the items. The warehouse workers will use this document to verify the items that need to be packaged or delivered, and this document is usually sent with the shipment to the customer. When this process is completed, the inventory is updated to remove the quantities from the on hand inventory. 4. Invoice: A document called an invoice is generated. When the invoice is generated for a sales order, it is the final step of the sales order process where the customer is effectively billed or "invoiced" for the items that are delivered. This process creates an open transaction on the customer’s account that must be paid for by the customer. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-3 Development IV in Microsoft Dynamics® AX 2012 As a sales order is processed, the status of the order is updated and the related inventory transactions are simultaneously updated. Sales orders also support other features such as the following. • • • • • • Support for multiple delivery addresses. Delivery schedules used to schedule one line for delivery on different dates. Ability to override pricing and discount information at the line level. Options to add charges such as freight or installation fees. Functions to create a purchase order or a production order from a sales order. Options for reserving inventory. A reservation of inventory on a sales order ensures that the items will be available for delivery on the date agreed upon with the customer. Sales Order Integrations The Sales module is used to keep track of sales activities. The following figure shows the interface with other modules in Microsoft Dynamics AX. FIGURE 8.1 SALES ORDER INTEGRATIONS WITH OTHER MODULES 8-4 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement Chapter 8: Use and Design of the Sales and Purchase Modules Purchase Order Feature Overview Purchase orders in Microsoft Dynamics AX 2012 can be accessed from the Accounts payable module and the Procurement and sourcing module. Although there are additional list pages and reports in each module that are different, the basic purchase order information that is available in each module is identical. The primary components of a purchase order consist of a header and one or more lines. Each purchase order header is linked to one specific vendor account. Each line of a purchase order is linked to one specific item number or one specific procurement category. When a purchase order line is linked to an item number, the category field is defaulted based on the category assigned to the item. You can leave the item number field blank, and select only a category. Unlike sales orders, a purchase order only has three order types available―Journal, Purchase order, and Returned order. Additionally, when a purchase order is processed, the steps include a confirmation that is similar to the sales order confirmation, a receipts list, a product receipt, and an invoice. A receipts list is a record of received items. The task is performed for physical accepting of the goods. Products updated on a receipts list are still not physically available. A packing slip is the document that accompanies physical delivery. It describes the contents of the delivery with the focus on the delivery’s physical characteristics. Recording the packing slip is completed by registering a product receipt from the vendor. Purchase orders also support other features such as the following. • • • • • • Support for multiple delivery addresses. Delivery schedules used to schedule one line for delivery on different dates. Ability to override pricing and discount information at the line level. Options to add charges such as freight or installation fees. Ability to create and acquire fixed assets on purchase order lines. Integration with planned purchase orders generated from the Master planning module. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-5 Development IV in Microsoft Dynamics® AX 2012 The Purchase module is used to keep track of procurement activities.2 PURCHASE ORDER INTEGRATIONS WITH OTHER MODULES 8-6 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . The following figure shows the interface with other modules in Microsoft Dynamics AX. FIGURE 8. A purchase order is always related to a vendor to whom the goods in the purchase order will be received from. A different vendor account might be specified to receive the invoice. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-7 .Chapter 8: Use and Design of the Sales and Purchase Modules Purchase Order Data Model The following figure shows the purchase order data model. FIGURE 8. whereas the related lines are stored in the PurchLine table.3 PURCHASE ORDER DATA MODEL The PurchTable table holds a record for each purchase order. When the value is DeliveryLine. The InventDim table has many indexes related to individual inventory dimensions. such as size. labeled InventDim. color. There are other scenarios. and there is "master" record for the original purchase order line. However. when a delivery schedule exists on a purchase order line. the line is one of the scheduled deliveries. there are scenarios where inventory transactions do not exist. Additionally. Inventory transactions are used to store the status and history of the inventory receipts and issues. Inventory dimensions for the purchase order lines. By default the relationship between the InventTransOrigin and the InventTrans is a one-to-one relationship. such as partial receipts and invoices that can cause multiple inventory transaction records to be created. the line is original order line that has a delivery schedule attached. such as purchase orders with the type of journal or purchase lines with products that are not stocked. or purchase order lines that are category based. The LineDeliveryType field is used to determine whether the line has a single delivery or multiple deliveries. Each InventTransOrigin record is related to one or more InventTrans table records. even if all inventory dimensions have blank values. When the value is OrderLine there is only one delivery. and configuration. 8-8 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . multiple InventTrans records are created. When the value is OrderLineWithMultipleDeliveries. are saved in a separate table. The InventDimId field creates the relationship between a purchLine and the record holding dimension values. Each purchase order line has one related record in the InventTransOrigin table. This design is used because it reduces the number of indexes in tables holding inventory dimensions. the PurchLine table stores one record for each delivery date. The purchase order lines are always related to a record in the InventDim table. All indexes in the InventDim table can be used with the PurchLine table through a join between the two tables. This join only requires one index (InventDimIdx) on the PurchLine.Development IV in Microsoft Dynamics® AX 2012 When there is a delivery schedule on a purchase order line. 5 PURCHLINETYPE TYPE HIERARCHY BROWSER On the PurchTable and PurchLine an object method called type() is used to construct the actual object. the call is redirected to the object constructed by the object method type(). FIGURE 8. Instead of using many if-statements to separate the functionality about the order type. validateWrite(). return orders. Sales orders use the class hierarchies called SalesTableType and SalesLineType. A modification to these methods should be implemented on the classes instead of on the table object method. Each order type supports different tasks and functionality. The dataflow object method called initFrom…() is also implemented on the classes. Object methods such as insert(). update(). delete(). and purchase and sales orders. FIGURE 8. the properties and methods are isolated on the class hierarchies PurchTableType and PurchLineType. The following figure shows the PurchTableType class hierarchy.Chapter 8: Use and Design of the Sales and Purchase Modules Purchase Order Classes Microsoft Dynamics AX 2012 supports several different types of orders such as journals.4 PURCHTABLETYPE TYPE HIERARCHY BROWSER The following figure shows the PurchLineType hierarchy. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-9 . However. The object method on the table is activated by the kernel. and validateField() are implemented on the classes. The total amounts of the purchase order are not stored in the database. charges. add the default property to the root class and override it on the subclass in question.Development IV in Microsoft Dynamics® AX 2012 If you must have a new property on an existing or new subclass of these hierarchies. a purchase order consists of a header and several purchase order lines. start by adding a new element to the purchase order type base enumeration. This is handled by several subclasses to the PurchTotals class. instead they are calculated when the information is needed. The totals are calculated in relation to the inquiry from the purchase order. but reporting and inquiries slower. This class extends TradeTotals which Extends TradeTotalsBased which are also used for calculating sales totals. and so on. volume. check of the credit limit. The following figure shows the PurchTotals class hierarchy. update to an invoice.6 PURCHTOTALS TYPE HIERARCHY BROWSER The classes have many object methods returning several amounts such as order balance. As discussed earlier. The scope of the calculation can range from one single purchase order line to a summary of multiple purchase orders. weight. The totals of a purchase order are calculated by using the PurchTotals class. FIGURE 8. 8-10 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . and so on. Add methods to the new class that override the base methods in the PurchTableType and PurchTableLine classes. Then you must modify the construct() method on the classes to call the appropriate "type" class for each purchase order header and line. taxes. and then create a new class that extends the PurchTableType and PurchLineType classes. To create a new order type. This approach makes data entry faster. The commitment type also determines how the agreement is being managed to determine when the commitment is fulfilled. and vendors.Chapter 8: Use and Design of the Sales and Purchase Modules Agreements The Agreement framework offers users of Microsoft Dynamics AX a broad set of tools for applying and following up on commercial agreements between the company and its customers and vendors regarding of buying/selling a certain quantity or/and volume of an particular item as well as a range of items within a certain category with a special policies applied to achieve an agreed price for trading goods and/or services. You can specify the agreement commitment type on the purchase and sales agreements. and final discounts. is an ongoing task. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-11 . Trade Agreements Prices of sold and purchase items should be maintained. Prices can be set up specifically for individual items. The price structure also includes line. or prices can be set up for a group of customers or vendors. multiline. Administration of sales prices and purchase prices that includes publishing to the organization and customers. The prices and discounts of the sales or purchase agreement overrule any prices and discounts stated in any trade agreements that could exist. or for all customers as one group. customers. This controls what information is required on the agreements. InventItemSalesSetup.Development IV in Microsoft Dynamics® AX 2012 Trade Agreements Data Model The basic or default purchase price specified directly for the item is stored in the InventTableModule table: FIGURE 8.7 INVENTTABLEMODULE DATA MODEL Purchase price information is stored in the following fields: • • • Price PriceUnit Markup Each item in InventTable has exactly three related records in InventTableModule and one record each in InventItemPurchSetup. 8-12 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . and in InventItemInventSetup tables. line discounts. vendors. The search for a price or discount must use a priority between the several combinations. Trade agreements allow you to set up purchase prices. multiline discounts. quantities. Item Vendor Group All 1 4 7 Group 2 5 8 All 3 6 9 Price groups are used to create the groups of customer. and total discounts. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-13 . This is controlled by the Relation field on the PriceDiscTable. you can use Trade agreements to define detailed pricing information for specific vendors. and total discounts) and for each group of transactions (customers. or items that you want to handle in the same way for prices. Each specification in the price agreement table contains item and vendor dimensions. or date ranges. line discounts. vendors.8 PURCHASE PRICE AND DISCOUNT DATA MODEL When more complex pricing is required. multiline discounts. FIGURE 8.Chapter 8: Use and Design of the Sales and Purchase Modules The following figure shows the design of the purchase price and discount data model. and items). A separate price group can be created for each type of pricing (prices. • • • Table: Specific item and vendor Group: Group of items and vendors All: All items and vendors This creates up to nine different levels of specification. Many different relations exist between the PriceGroup table and the PriceDiscTable. currencies. Development IV in Microsoft Dynamics® AX 2012 If no price is found in the PriceDiscTable the price specified in InventTableModule is used. you must create a price and discount journal and make the modifications in the journal. You cannot change the information in PriceDiscTable directly. the records are updated or created in PricDiscTable. 8-14 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . whereas PriceDiscAdmTrans contains the individual price agreements. then it will be related to the existing record in PriceDiscTable (RecId). The following figure shows the design for the price and discount journal function: FIGURE 8. It can be relevant to change this setting. Instead. The PriceDiscTable is configured to Found caching in the standard application. depending on the amount of data in the table. If the journal line is loaded from the existing agreements. PriceDiscAdmTable contains the header for each journal. When the journal is posted. The design of the price searches does not support found (single-record) caching as it contains criteria on quantity and date intervals.9 PRICE AGREEMENT JOURNAL DATA MODEL The PriceDiscAdmName table contains the journal names that are defined in the setup. • Ability to express in the system a contractual commitment of sale of purchase for a specific amount of quantity of a certain item. The prices are not recalculated during updates. because there is no need for entities stored in database to carry properties that do not make sense for agreements. It is activated from the Sales and Purchase module when a line is created or changed. The agreement framework in Microsoft Dynamics AX 2012 includes the following features. Enforces price agreements on the purchases or sales when they’re done according to agreement.Chapter 8: Use and Design of the Sales and Purchase Modules Trade Agreements Classes The PriceDisc class is used to search for price and discount information. In previous versions. The search for information in the PriceDisc class is executed in the findPriceAgreement() object method. or discounts with a specific customer/vendor. The PriceDiscAdmAdjustment class is used to select existing trade agreements and make changes to existing trade agreements. Price and discount agreement journals are posted by using the PriceDiscAdmCheckPost class. You can specify the agreement commitment type on the purchase and sales agreements. so you have the opportunity to make manual adjustments to the price and discounts on the individual sales line. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-15 . Sales and Purchase Agreements The agreement is a contract that commits the customer/vendor to buy/sell a product in a certain quantity or amount over a period in exchange for special prices and. The prices and discounts of the sales or purchase agreement overrule any prices and discounts stated in any trade agreements that might exist. Follow up on sales or purchases to see if the contractual obligations have been fulfilled. category or any item/category. This controls what information is required on the agreements. This separation helps to optimize data structure. you used the blanket order type in sales orders to set up these agreements. • • Sales and Purchase Agreement Data Model In Microsoft Dynamics AX 2012 the agreement framework’s data model is completely separated form general purpose order data model. The commitment type also determines how the agreement is being managed to determine when the commitment is fulfilled. Development IV in Microsoft Dynamics® AX 2012 The agreement framework physical data model design uses the table inheritance feature and implement all data sub-types needed by the framework and their behavior deviations as a table inheritance ladder.10 PURCHASE AGREEMENT DATA MODEL 8-16 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . With that done the need for supporting class hierarchy behind the used data tables was completely eliminated. encapsulating both data. The following figure show the data model for purchase agreements.specializations within a single type of objects – AX Data Tables.and functional. FIGURE 8. Functionality does not change with different types. Classifications help group agreements into different types.Chapter 8: Use and Design of the Sales and Purchase Modules Agreement Classifications Agreement classifications are a required field on agreements. FIGURE 8. These values can be used for reporting and analysis. The following figure shows the data model for agreement classifications. Purchase agreement classifications are setup on the form at the following location: Procurement and sourcing > Setup > Purchase agreements > Purchase agreement classification.11 AGREEMENT CLASSIFICATION DATA MODEL Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-17 . Development IV in Microsoft Dynamics® AX 2012 Agreement History The agreement framework in Microsoft Dynamics AX2012 enables users to create a snapshot of the current agreement state at any given time.and base. These snapshots called “Agreement History” are stored by the system as separate records in a database so persisted state for particular agreement can be reconstructed by the system and accessed by user for later analysis.entities are established for only a few entities (exactly only for AgreementHeader and AgreementHeaderHistory as well as for AgreementLine and AgreementLineHistory).12 AGREEMENT HISTORY DATA MODEL Explicit relations between history. all other similar relations would be redundant for the data model and therefore were not implemented. 8-18 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . To enable this functionality the agreement framework defines a number of history entities shown in the following figure. Besides them. FIGURE 8. You can see in the previous figure that there is no relation between AgreementHeaderHistory and AgreementLineHistory entities. You can also relate a purchase agreement to a purchase order from the Create purchase order form in the Purchase agreement field. Each purchase order line can have one purchase agreement linked. Charges can be linked to the header or the lines of the orders. You can use additional functionality that is created automatically during certain types of updates based on parameter settings to link between purchase orders and purchase agreements. Charges A charge is an additional fee or cost that can be added to a purchase or sale order. or when you create purchase orders through Master planning. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-19 . They can be added manually to an order. Sales and Purchase Agreements Classes Purchase agreements can be linked to a purchase order manually by creating a release order from the Purchase agreements form. The last option for manually creating a link between the purchase agreement and purchase order is to use a button on the line of each purchase order to link to a selected purchase agreement. the explicit relation between these two entities is not established by the data model because for the performance reason the AgreementLineHistory instances are allowed to be shared between several AgreementHeaderHistory instances. or a rule can be configured to have charges automatically added to an order.Chapter 8: Use and Design of the Sales and Purchase Modules Also it is important to note that History entities for agreement headers and lines do not directly implement “Header-Lines” pattern. For example. you can select an option for the system to search for purchase agreements when you create a purchase order from a sales order. While logically each agreement header history instance contains several agreement line history instances still. Another option on the set up of the charge code is used for the charge to be assessed to the item.Development IV in Microsoft Dynamics® AX 2012 The following figure shows the data model for the relation of charges with a sales order. Additionally. For example. a sales charge can be assessed as a fee that will post to the customer's account this type of charge increases the invoice amount of the order. FIGURE 8. For purchase orders there are additional options to select a method for allocating a charge that is applied to the header to the lines of that order. The charge code defines how the charge will be assessed.13 SALES ORDER CHARGES DATA MODEL Each charge that is added to an order is defined by the charge code. This type is most often used as a landed cost that increases the inventory cost but does not increase the invoice amount to be paid by the customer. options exist on the charge code set up to determine which main account the cost or fees should post to when invoice updating the order. Similar options exist for purchase orders. 8-20 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . whereas registrations related to the sales order and purchase order are stored in the MarkupTrans table.14 PURCHASE ORDER INVOICE CHARGES DATA MODEL Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-21 . The following figure shows charges and their relation to Purchase order invoicing. FIGURE 8.Chapter 8: Use and Design of the Sales and Purchase Modules Definitions of charge codes are stored in the MarkupTable. When the invoice is generated. The copy is related to the original record by the OrigTableId and OrigRecId fields. a copy of the charge transaction is created that is related to the invoice journal. then the related information in the Account/Item-relation is a specific customer or item. Group: If the value is Group.Development IV in Microsoft Dynamics® AX 2012 An alternative to entering charges manually for each order is to define automatic charges.15 AUTOMATIC CHARGES DATA MODEL The AccountCode and ItemCode fields are enumerations with the following entries. then the related information is blank. • Automatic charges can be related to a specific customer or item combinations. The following figure shows the design of automatically generated charges: FIGURE 8. • • Table: If the value is Table. Only charges related to a sales line or purchase line can have an ItemCode that differs from All. The MarkupAutoTable and MarkAutoLine tables can be ignored if all charges will be manually created. When an order or order line is created. All: If the value is All. the application will search for related information in the MarkupAutoTable. If the search finds some information. then the related information is a specific group that is defined in the Markup group of the type customer or item. then the related information in the MarkupAutoLine table is copied to the MarkupTrans table. 8-22 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . and performance. FormLetter Framework: Base Classes In Microsoft Dynamics AX 2012. the FormLetter framework is refactored to separate the functionality required for the posting process into different classes. Now. there are a number of new class hierarchies. extensibility.Chapter 8: Use and Design of the Sales and Purchase Modules FormLetter Framework The FormLetter framework in Microsoft Dynamics AX is used when posting documents for sales or purchase orders. in Microsoft Dynamics AX 2012. The following object model shows the new set of base classes and how the classes interact with each other. This lesson describes the Microsoft Dynamics AX 2012 version of the framework. This framework is refactored in Microsoft Dynamics AX 2012 to provide better support for customizations. FIGURE 8.16 FORMLETTER BASE CLASSES IN MICROSOFT DYNAMICS AX 2012 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-23 . 17 DOCUMENT POSTING BASE CLASSES 8-24 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . The following figure shows how the various base classes are used when posting a document for an order. Switching to the SysOperation framework has the advantage of executing the code on the server tier during posting in Common Intermediate Language (CIL). Client callbacks result in an exception. Because of the switch to the SysOperation framework.Development IV in Microsoft Dynamics® AX 2012 FormLetter Framework: Document Posting Flow The base FormLetter class used in Microsoft Dynamics AX 2009 is now split into eight base classes. It is also updated to run under the SysOperation framework. FIGURE 8. client callbacks from code running on the server tier are no longer supported. the SalesEditLines form). The FormLetterServiceController invokes the FormLetterService class when the run method is called. The FormLetterServiceController class is executed on the client tier. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-25 . The class gathers the information needed during the posting process and passes these values to the FormLetterService class by using the data contract class pattern. FIGURE 8.18 SALES ORDER PACKING SLIP CLASS POSTING FLOW FormLetter Framework: FormLetterServiceController The FormLetterServiceController class is the entry point for the FormLetter framework and can be used to interact with the posting form (for example.Chapter 8: Use and Design of the Sales and Purchase Modules The following figure shows the various class hierarchies used when posting a sales order packing slip document. All functionality that does not relate to the interaction with the Posting form is moved to other class hierarchies.parmDirectDeliveryUpdate()) { return salesFormLetterContract. The pattern used to assign values to the data contract classes are the parm methods from Microsoft Dynamics AX 2009 that changed and use the data contract class instead of a global class variable. public boolean parmDirectDeliveryUpdate(boolean _directDeliveryUpdate = salesFormLetterContract. are updated so that they extend the FormLetterServiceController class.parmDirectDeliveryUpdate(_directDel iveryUpdate). The data contract classes pass data from the FormLetterServiceController to the FormLetterService.Development IV in Microsoft Dynamics® AX 2012 The following figure shows the FormLetterServiceController class hierarchy. The following code sample is an example of a parm method. 8-26 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . such as SalesFormLetter. each class in the FormLetterServiceController class hierarchy has a corresponding data contract class. FIGURE 8. The class variables that are assigned a value to use during the posting process in earlier releases are moved to the data contract classes. The data contracts follow the same class hierarchy structure as the FormLetterServiceController classes. Therefore. } FormLetter Framework: FormLetterContract The FormLetterContract class is the base data contract class in the FormLetter framework.19 FORMLETTERSERVICECONTROLLER CLASS HIERARCHY The module specific classes. } Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-27 .20 FORMLETTERCONTRACT CLASS HIERARCHY Parm methods are used to set and get the data from a contract class. FIGURE 8. The following code sample is an example of a parm method: [DataMemberAttribute] public NoYes parmDirectDeliveryUpdate(NoYes _directDeliveryUpdate = directDeliveryUpdate) { directDeliveryUpdate = _directDeliveryUpdate.Chapter 8: Use and Design of the Sales and Purchase Modules The following figure shows the FormLetterContract class hierarchy. return directDeliveryUpdate. return outputContract. this. posts the documents. creates the journal. and then calls the logic to print the document if required. [SysEntryPointAttribute] FormLetterOutputContract postSalesOrderPackingSlip(SalesFormLetterPackingSlipContrac t _contract) { formletterContract = _contract. meaning that there can be no client callbacks from this class. such as PostSalesPackingSlip. FIGURE 8. Client callbacks result in an exception.21 FORMLETTERSERVICE The run method initializes the objects required for posting. The following figure illustrates some of the FormLetterService class methods.run(). } 8-28 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 FormLetter Framework: FormLetterService The FormLetterService class can be used to control the posting flow for a number of journals. The class is bound to the server tier and executes in Common Intermediate Language (CIL). The class also has a service operation method for each of the document types that can be posted by this service. General update parameters are stored in SalesParmUpdate. Information in SalesParmLine refers to the sales order that contains the invoice with the SalesId field.22 FORMLETTERPARMDATA CLASS HIERARCHY The SalesTable and SalesLine tables contain information manually entered in the sales table form. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-29 . The update is activated by using a button in the Action Pane of the Sales order form. SalesParmTable. whereas the OrigSalesId field contains the ID of the sales order that relates to the line(s) in question. FIGURE 8. The SalesParmSubTable holds one record for each sales order that contributes to such invoices. Specifications related to one sales order are stored in SalesParmTable. whereas individual lines are specified in SalesParmLine. This creates an update specification in the SalesParm-tables. The following figure shows the data model for a sales order update. Lines from different sales orders can be collected in one invoice. such as SalesParmUpdate.Chapter 8: Use and Design of the Sales and Purchase Modules FormLetter Framework: FormLetterParmData The FormLetterParmData class hierarchy can be used to create and maintain posting data in the parm tables. SalesParmSubLine contains sales order line update relations. and SalesParmLine. for example.Development IV in Microsoft Dynamics® AX 2012 The base class uses a template pattern that defines a template for how to create records in the parm tables. CustPackingSlipSalesLink. such as SalesFormLetterParmDataPackingslip. • • • CreateData: Creates the required data in the parm tables. 8-30 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . CustPackingSlipJour. There are module specific classes such as SalesFormLetterParmData. ReSelect: Recreates the data based on the specQty in the posting form. The class has three public Application Programming Interfaces (APIs). ReArrange: Rearranges the data in the tables based on summary update settings. which can be found in the FormLetterJournalCreate.createJournal() method. for example CustPackingSlipTrans. and a number of lines. and one class for each document type supported.23 FORMLETTERPARMDATA CLASS HIERARCHY FormLetter Framework: FormLetterJournalCreate The FormletterJournalCreate class hierarchy creates one journal with a header. FIGURE 8. The following figure shows the FormletterParmData class hierarchy. and related journal data. The template is similar to the following code sample. for example. The base class uses a template pattern that defines how to create a journal. if (this. //Create the journal header. this. { this.endCreate(). //Create journal lines.Chapter 8: Use and Design of the Sales and Purchase Modules if (this.//Initialize the journal header.//Insert all records into the database. } } Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-31 .insertRecordList().//Finalize journal creation. this. this.isJournalCreated()) //If a journal were successfully created.initJournalHeader().check())//Validate that the journal can be created.createJournalHeader(). { this.createJournalLines(). 24 FORMLETTERJOURNALCREATE OBJECT MODEL There are also document specific classes for each of the documents created by the framework. 8-32 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . Those document classes that support having multiple versions of the same document extend the FormLetterVersionableJournalCreate class. The FormLetterService class instantiates this class hierarchy for each of the journals it needs to create and calls run. FIGURE 8. These classes hold the logic specific for a document.Development IV in Microsoft Dynamics® AX 2012 The following figure shows the FormLetterJournalCreate class hierarchy. such as SalesPackingSlipJournalCreate. This class hierarchy requires that a journal is created and passed in. to update the ledger and inventory. These classes hold the logic specific for a document. FIGURE 8.25 FORMLETTERJOURNALPOST CLASS HIERARCHY Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-33 . There is also a document specific class for each of the documents posted by the framework. The base class uses a template pattern that defines how to post a journal. The following figure shows the FormletterJournalPost class hierarchy. The FormletterService class instantiates this class for each of the journals it needs to post and calls run.Chapter 8: Use and Design of the Sales and Purchase Modules FormLetter Framework: FormLetterJournalPost The FormletterJournalPost class hierarchy can be used to post one journal. for example SalesPackingSlipJournalPost. for example. The following figure shows the data model for a sales order invoice document. regardless of which sales order owns the invoice.26 SALES ORDER INVOICE DOCUMENT DATA MODEL CustInvoiceJour contains information copied from SalesTable. FIGURE 8. and the ability to delete obsolete information in these tables without destroying reporting capabilities. SalesTable and SalesLine can be changed or deleted after invoice update. the sales order invoice creates transactions into the customer invoice tables. could be needed later. then only one of the sales IDs will be stored in CustInvoiceJour. If multiple sales orders contribute sales lines to one invoice. So it is important to only use information that is stored in CustInvoiceJour and CustInvoiceTrans when you design reports and calculate statistics. For example. the data from the parm tables is copied to another set of tables that are used for balancing the ledger to the sub-ledger.Development IV in Microsoft Dynamics® AX 2012 When a document is posted. Although information in the SalesParm-table is saved after the update. They are designed to only control updates. reporting should not be based on these tables. whereas CustInvoiceTrans is created based on information in SalesLine. 8-34 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . Both tables can be affected by information specified in the SalesParm-tables when updates are ordered. CustInvoiceSalesLink is used to show all invoices related to a sales table. .... VendInvoice. -Trans. VendReceiptsList. VendPurchOrder. and-Link CustQuotation..Chapter 8: Use and Design of the Sales and Purchase Modules TIP: A periodic job can be used to clean up and delete records from the parm tables. The FormLetterService class instantiates this class either for each of the journals being posted. Module Sales Document Quotation Confirmation Picking list Packing slip Invoice Purchase Confirmation Receipts list Packing slip Invoice -Jour... CustPackingSlip.. WMSPickingRoute...... CustConfirm. CustQuotationConfirmation.. FormLetter Framework: FormLetterJournalPrint The FormLetterJournalPrint class hierarchy can be used to control the printing of one or more journal documents. The previous pattern is repeated many times. VendPackingSlip.. There is a document-specific class for each the documents that can be printed by the framework. one for each type of update in the sales and purchase areas.... or once with a list of all posted journals. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-35 ... CustInvoice. FIGURE 8.Development IV in Microsoft Dynamics® AX 2012 The following figure shows the FormLetterJournalPrint class hierarchy. The following figure shows the FormLetterProvider class hierarchy. FIGURE 8.28 FORMLETTERPROVIDER CLASS HIERARCHY 8-36 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . There is one child class for each module. for example. SalesFormLetterProvider.27 FORMLETTERJOURNALPRINT CLASS HIERARCHY FormLetter Framework: FormLetterProvider The FormLetterProvider class can be used to provide module specific data to each of the other class hierarchies. initFrom() methods. When you post an invoice.initFromCustTable(). When a new sales order is created. or Sales order confirmation the SalesEditLines form is displayed in the user interface. This field should contain instructions for the payment of invoices sent to the customer.Add a Field to the Sales Invoice Actively participating during this workshop will help you to understand the use of the SalesParm tables and become familiar with the use of . with a limit of 100 characters. This task is typically implemented by creating an object method in the destination table named initFrom<sourcetable>. Estimated time to complete: 30 minutes Scenario The solution should contain a new field in the customer table. Controlling the Layout of the SalesEditLines Form When you use the path Sales and marketing > Periodic > Sales update and select one of the menu items such as Packing slip. this field should be copied to the sales order. Picking list. The layout of this form depends on the kind of posting selected. You should be able to change the value for specific sales orders.Chapter 8: Use and Design of the Sales and Purchase Modules Lab 8. Extension of the existing flow of information can typically only be resolved by adding fields to the tables and to the corresponding initFrom-methods. InitFrom Transfer of information from one table to another is frequently used when you create records and save transactions from updates. other criteria such as the settings of the Sales order module can also change the layout of the SalesEditLines form. The field should be implemented as a multiline field. you should be able to change the field without overwriting the original value in the sales table. Technical Issues This section outlines additional information that is required to implement the new field. However.1 . Creating a record in a sales table in this manner involves the activation of the following logic salesTable. The value specified while ordering the update should be printed on the invoice. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-37 . Methods of this class hierarchy are called from the form to control the layout of the form. } This method is overridden in the SalesEditLinesForm_invoice class: public boolean billOfLading() { return SalesParameters::find(). Depending on the menu item that is selected.visible(salesEditLinesForm. 8-38 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . A method is implemented in the SalesEditLinesForm class: public boolean billOfLading() { return false. 2. } This method is called in the init method of the form as shown: tabPageBillOfLading. The dialog method of the SalesFormLetter object opens the SalesEditLines form. SalesParmTable and CustInvoiceJour tables with the new field that contains the instructions for the payment of invoices sent to the customer. 3.useBillOfLadingOnInvoice(). 4. Create a new field in the tables that is required to implement the requested possibilities to change and store the information. Create a new project to store all of the objects that you modify or create as a part of this lab. Add a field to the SalesInvoiceTmp table for the payment instructions and modify the SalesInvoiceDP class to populate the field. The Bill of lading tab page is only visible if you are posting to an invoice. 1. Make an extended data type defining properties of the payment instruction. Implementation Extend CustTable.billOfLading ()). In the init method of the SalesEditLines form an object of one of the classes in the SalesEditLinesForm hierarchy is instantiated. Add fields to the relevant forms to view the current value and possibly edit this value. 5.Development IV in Microsoft Dynamics® AX 2012 The SaleFormLetter class hierarchy is used for this posting. SalesTable. Then include the field in the header of the SalesInvoice report. the appropriate subclass of SalesFormLetter is instantiated. The pattern used can be explained by viewing how the display of the Bill of lading tab page is controlled in SalesEditLines. 1. Right-click the Shared node and then click New > Project. follow these steps. To add the payment instruction extended data type. DisplayHeight = 3 e. Drag the newly created PaymentInstruction extended data type into the project that you created earlier. Right-click the new project and select Rename. 3. HelpText = Instruction on how the customer should pay the invoice. expand tables and locate the CustTable. Open the Projects window. Expand the CustTable table. Right-click the Field groups node and then click New Group. Enter a name for the project such as NewFieldOnInvoiceLab. d. Step by Step: Add the Payment Instruction Field Follow these steps to create a new project. Open the Development workspace. 4. and then close the Projects window. In the Properties window. StringSize = 100 4. Under the Data Dictionary node in the AOT window. 3. 6. SalesTable. 1. Double-click the project to open it. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-39 .Chapter 8: Use and Design of the Sales and Purchase Modules 6. Save the table. Verify implementation by using an example. 2. 2. Name = PaymentInstruction b. 5. 4. 1. Use the pattern explained to make the new field visible when you are posting to an invoice and not visible when doing other postings. Label = Payment instruction c. 6. Select the PaymentInstruction extended data type and drag it to the Fields node of the CustTable table. 7. To add the payment instruction field to the CustTable. In the AOT window expand the Data Dictionary node. 5. Right-click the Extended Data Type node and select New > String. SalesParmTable. and CustInvoiceJour tables. a. 2. Drag the table into the project that you created earlier. 3. follow these steps. set the following values on the new real. Save the extended data type. 5. ) 7. Name = PaymentInstruction b. 5. 10. 3. 9. (To locate the TabSetup.) 10. (To locate the TabHeaderSetup. Right-click the CustTable form and then click Restore. To add the payment instruction field to the CustTable. browse to Designs > Design > Tab:Tab > TabPage:TabPageDetails > Tab:TabHeader > TabPage:TabPageSales in the CustTable form. 8. Drag the Payment Instruction field group into the bottom of the Sales order defaults FastTab (TabPageSales) under the Design node of the form. SalesEditLines forms. Label = Payment instruction 8.Development IV in Microsoft Dynamics® AX 2012 7. Verify that the new Payment instruction field is available. browse to Designs > Design > Tab:MainTab > TabPage:TabPageDetails > Tab:DetailsTab > TabPage:HeaderView > Tab:HeaderDetailsTab > TabPage:TabHeaderSetup in the SalesTable form. expand Forms and then locate the CustTable form. 9. follow these steps. Drag the CustTable form into the project that you created earlier. browse to Designs > Design > Tab:TabSalesParmTable > TabPage:TabSetup in the SalesEditLines form. Repeat steps 1-9 for the SalesTable. Repeat steps 1-8 for the SalesTable form. (To locate the TabPageSales tabpage. Place the field group on the Setup (TabSetup) tab on the form. SalesParmTable. 8-40 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . Place the field group on the Setup (TabHeaderSetup) FastTab of the Header view on the form. and CustInvoiceJour tables. and then click the Invoice tab in the Action Pane.) NOTE: You cannot open this form directly. 4. SalesTable. click Continue. 6. and then click Invoice in the Generate group. Save the project. a. Save the table. and then drag it into the PaymentInstruction Field group. Repeat steps 1-8 for the SalesEditLines form (the field group is in the SalesParmTable data source). In the AOT window. you must open it from the Sales order form by selecting a delivered sales order. 2. 1. Select the Payment instruction field from the Fields node on the CustTable table. Right-click on the CustTable form and then click Open. If the Synchronize table window opens. In the Data Sources node of the form browse to CustTable > Fields and then select the Payment Instruction field group (folder) from the list. Set the following values in the Properties window. TIP: The code samples for this lab can be found in the AX2012_ENUS_DEVIV_08_01_LAB_CODE. } 5. } return custInvoiceJour. You can copy and paste these code samples into the correct methods. Use the following code sample to guide you. _paymentInstruction). PaymentInstruction). this. public PaymentInstruction parmPaymentInstruction(PaymentInstruction _paymentInstruction = '') { if (!prmisdefault(_paymentInstruction)) { this. AXSalesParmTable.PaymentInstruction. 4. fieldnum(CustInvoiceJour. Modify the setTableFields method in the AXCustInvoiceJour class to call the new setPaymentInstruction method that you created in step 2. Create a new method called parmPaymentInstruction to the AXCustInvoiceJour class. and AXSalesTable classes. 1.txt file. Repeat steps 1-4 for the AXCustTable.isMethodExecuted(funcname(). Use the following code sample to guide you. PaymentInstruction))) { return. 2.setPaymentInstruction(). Use the following code sample to guide you. Create a new method called setPaymentInstruction to set the value of the field. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-41 .Chapter 8: Use and Design of the Sales and Purchase Modules Step by Step: Add Code to Populate the Field To add logic for populating the Payment instruction field.setField(fieldnum(CustInvoiceJour. Add the AXCustInvoiceJour class to the project. protected void setPaymentInstruction() { if (this. } } 3. follow these steps. ReturnReturnOrderIn_SalesTable.get_Attribute(#PaymentInstruction). } 10. NOTE: The code will vary slightly for each method. } return this. 8-42 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . Make sure to use the correct table and field for each class. public PaymentInstruction parmPaymentInstruction(PaymentInstruction _value = '') { if (!prmisdefault(_value)) { this. 11. Repeat steps 6-9 for the ProdProjEInvoice_CustTable.Development IV in Microsoft Dynamics® AX 2012 NOTE: The code will vary slightly for each method. Create a new parm method called parmPaymentInstruction.exists(#PaymentInstruction). Use the following code sample to guide you. ReturnReturnOrderOut_SalesTable. Use the following code sample to guide you. Create a new method that returns a false. SalesSalesEInvoice_CustInvoiceJour. } 9. SalesSalesOrder_SalesTable. Create a new method called existsPaymentInstruction to check of the payment intruction exists. _value). 12.PaymentInstruction('PaymentInstruction') 8. Add the CustCustomer_CustTable class to the project. Use the following code sample to guide you. and the SalesSalesPackingSlip_SalesParmTable classes. SalesSalesInvoice_CustInvoiceJour. 6. Use the following code sample to guide you. #define. Modify the classDeclaration to declare a macro for the payment instruction. Add the SalesEditLinesForm class to the project. SalesSalesEInvoice_CustTable. public boolean existsPaymentInstruction() { return this. 7. Make sure to use the correct table and field for each class.set_Attribute(#PaymentInstruction. 8-43 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . locate the SSRS report called SalesInvoice. 4. Add a line of code to the bottom of the //Invoice section after line 79 to set the temporary tables payment instruction field equal to the custInvoiceJour payment instruction field. Locate the insertIntoSalesInvoiceTmp method and then right-click and select View Code. public boolean PaymentInstruction() { return true.Chapter 8: Use and Design of the Sales and Purchase Modules public boolean PaymentInstruction() { return false. Add the SalesEditLinesForm_Invoice class to the project. 5.PaymentInstruction = custInvoiceJour. 2. To modify the SalesInvoiceDP class to populate the Payment instructions field. Locate the SalesInvoiceDP class and drag it into the project that you created earlier. To modify the sales invoice report. 2. } Step by Step: Modify the Sales Invoice Report To add a field to the SalesInvoiceTmp table for the Payment instructions. 14. Select the PaymentInstruction extended data type and drag it to the Fields node of the SalesInvoiceTmp table. 4. } 13. Create a new method that returns a true.PaymentInstruction. follow these steps. Expand the SalesInvoiceTmp table. follow these steps. expand tables and locate the SalesInvoiceTmp. 3. salesInvoiceTmp. Drag the table into the project that you created earlier. 1. Use the following code sample to guide you. In the AOT window. follow these steps. Save and compile the class. Under the Data Dictionary node in the AOT window. 2. Add the Sales Invoice report to the project that you created earlier. Use the following code sample to guide you. 3. Save the table. 1. 1. When Visual Studio 2012 opens.Development IV in Microsoft Dynamics® AX 2012 3. Add the payment instruction field into the header section of the report. TIP: You can compare your solution to the AX2012_ENUS_DEVIV_08_01_LAB_SOL. 6. Create a new sales order by using the path Accounts receivable > Common > Sales order and select the customer modified in step 1. and to post and print the invoice. 2. Open the Customers form by using the path Accounts receivable > Common > Customers > All customers and specify a value in the new field that has the payment instruction. Change the payment instruction inherited from the sales order. 8-44 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . locate the SalesInvoice report in the Solution Explorer window and then double-click it to open. Add a line to the sales order for item number 10007. Save the report. 4. build the project. 4. 5. 1. Test Use the following steps to create a new sales order. You can repeat the test by creating a new sales order. Make a modification to the payment instruction inherited from the customer. Post the invoice by clicking the Invoice tab of the Action Pane and then click Invoice in the Generate group. Locate the SalesInvoiceReport project in the Visual Studio Projects node of the AOT window. Expand the Datasets node and then right-click the SalesInvoiceDS and select Refresh. 5. Expand the Designs node and then right-click the Report node and select Edit Using Designer. 8. 3. Select to print the invoice and specify the screen as the destination of the report by clicking the Printer Setup->Invoice button and change the print destination to screen on the Print destination settings form. 9. 7.xpo file provided with the training image by importing the XPO file and then comparing the objects. and deploy the report. Right-click the project and select Edit. A standardized document state model enabling change management with workflow approvals. Microsoft Dynamics AX 2012 introduces a pattern for how modifications to such documents can be effectively managed and efficiently represented in the database. Document History and Change Management Many of the documents stored in Microsoft Dynamics AX are not static. It can be configured at the legal entity. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-45 . They can be changed or corrected by users based on changes in the environment they describe or when errors are found. Documents are editable only when they are in a draft. When not activated the purchase order is always considered pre-approved. Intercompany. When activated any change to order data requires workflow approval. • Purchase order The purchase order is the most complex use of the versioning pattern in Microsoft Dynamics AX 2012. The following lesson introduces sales quotations. Any change that is identified as part of the contract requires new order confirmation before an invoice or product receipt can be processed against it. vendor or specific order level. A new version is recorded upon approval. in review and rejected states. request for quotations. At any time a new version of the document can be recorded. This applies also when change management is not activated for an order and thus the change tracking functionality is always available (every confirmation creates a new version of the document).Chapter 8: Use and Design of the Sales and Purchase Modules Other Features There are many additional features in the Sales and Purchase Order modules. The two main functional benefits of applying the versioning pattern are: • Full traceability (history) of changes made to a document. and categories. purchase requisitions. Any two versions of the document can be compared with a generic version comparison tool. Direct Delivery and production/master planning derived orders never have change management enabled. The change management functionality for purchase orders is optional in Microsoft Dynamics AX 2012 and turned off by default. Besides the traceability and change management with workflow integration it also enabled other procurement functionality extensions like encumbrance accounting for confirmed purchase orders. Intercompany direct delivery packing slip corrections are also supported. White entities were present in earlier AX versions: PurchaseOrder (PurchTable). However. Typically nodes would be stored in various database tables with fields corresponding to document note type attributes. only received/delivered quantity can be corrected and only downwards.Development IV in Microsoft Dynamics® AX 2012 Product receipt and packing slip Product receipts and packing slips use of the pattern is limited to versioning and no workflow integration is enabled. They define the basic PO tree structure with the PurchaseOrder being the root node. The versioning pattern defines how multiple versions of a document can be stored in a relational database to minimize data repetition with efficient access to any of the versions. The following figure illustrates an abstract document model. PurchaseOrderLine(PurchLine) and the *MiscCharge* entities (MarkupTrans). PurchaseOrderLine its child node type and MiscCharge nodes that could be children of both PurchaseOrder and PurchaseOrderLine. There is no limit to the depth of the tree.29 ABSTRACT DOCUMENT VERSIONING DATA MODEL The following purchase order logical data model shows how the versioning pattern is applied to the purchase order document. FIGURE 8. The highlighted entities were added to support versioning. Product receipt and packing slip documents can be explicitly corrected in Microsoft Dynamics AX 2012. The document to be versioned has a tree structure with nodes represented by records in database tables and parent-child relations between nodes represented by foreign keys between corresponding database tables. 8-46 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . PurchLineHistory. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-47 . PurchLine and MarkupTrans in such queries). for example.ItemId) to help simplify queries against the archived versions (in other words. FIGURE 8. Documents for which the form is to be used need to provide a subclass implementing all the abstract methods. there is no need to join PurchTable.Chapter 8: Use and Design of the Sales and Purchase Modules Physical table names of the history tables are based on the physical table names of the corresponding node tables. For the selected node there is list of changed attributes shown on the right side of the form with old and new value columns. It displays document tree on the left side with icons indicating changed/deleted/added nodes. The form uses VersioningCompare abstract class as a data provider interface.30 PURCHASE ORDER DOCUMENT HISTORY DATA MODEL The VersioningCompare form can be used to visualize differences between document versions. The physical model adjustments include the use of the IsModified flag and duplication of most of the immutable attributes to the history tables (for example. the physical table name for the purchase order line history entity is PurchLineHistory. Request for Quotations Request for quotations are documents that you send to one or more vendors requesting them to quote a price.Development IV in Microsoft Dynamics® AX 2012 Sales Quotations A quotation is a proposal to a customer to make an order. it will be transformed into a sales order. or lost. When the quotation is confirmed the inventory transactions related to the quotation line are replaced by inventory transactions related to the created sales line. and the PurchRFQTable stores one record for each vendor on a specific case. Sales quotations can be included in the master planning. Options are available to create a request for quotation. These inventory transactions will have a status called Quotation issue or Quotation receipt (a negative quantity on a quotation line). or rejected. If a quotation is accepted. The PurchRFQCaseTable stores one record for each case. fully or partly and transfer the request for quotation to a purchase order. The user can accept or reject the request for quotation. receive and compare the request for quotation replies and create a purchase order from a request for quotation. 8-48 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . The SalesQuotationLine is related with one or more inventory transactions from the record that is created until it is confirmed. The details of the quote are stored in PurchRFQCaseLine. and typically the company issuing the quotes does not expect to receive orders from all the recipients of the quotation. The details of the quotation are stored in SalesQuotationLine. The quotation can be sent to prospects that are not existing customers or existing customers. delivery terms. When the quote is accepted the data is transferred to the purchase order that is described in the following section. The PurchRFQCaseTable is related with one or more inventory transactions from the record that is created until it is accepted. When the quote is accepted the inventory transactions related to the quotation line are replaced by inventory transactions related to the created Purchase line. The SalesQuotationTable table stores one record for each quotation. and terms of payment for materials to be purchased. canceled. These inventory transactions will have a status called Quotation issue or Quotation receipt. returned. When the quote is confirmed the data is transferred to the sales order that is described in the following section. • • Request items and services from a procurement catalog. The PurchReqTable table contains one record for each purchase requisition. Suggest a vendor from whom to order an item or service. They can be submitted through the Order Products page on Enterprise Portal or created and submitted through the rich client. The system can be configured to require business justifications. You can also request items and services that are not listed in a catalog. Submit the purchase requisition for review and approval. or in a legal entity or operating unit other than the one in which you hold a primary position. Request items or services on behalf of someone else.Chapter 8: Use and Design of the Sales and Purchase Modules Purchase Requisitions You can use a purchase requisition to submit a request for items or services that you must have to perform your job function. • • • • Purchase requisitions require a workflow to be configured for approval. The business justifications for each purchase requisition and line are stored in PurchReqBusJustification. By using purchase requisitions. Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-49 . The details of each product or category on the purchase requisition are stored in the PurchReqLine table. Perform budget checking on the purchase requisition if your organization uses budget checking. Distribute an amount on a purchase requisition line to multiple financial accounts and dimensions. you can do the following. The PurchReqExternalSource table contains the identifier that is used for the purchase requisitions in an external source system when the requisition originates from such a system. Each purchase requisition and line on a purchase requisition can contain a reason or business justification for the request. charges and document history. The functionality and data structures that are used with each are very similar. pricing.Development IV in Microsoft Dynamics® AX 2012 Summary Sales orders and purchase orders are two of the main transactions in Microsoft Dynamics AX. Both areas integrate with the agreements feature which allows you to define basic contracts for sales or purchases. Several different frameworks are provided with Microsoft Dynamics AX to help you manage basic order information. Sales orders and purchase order have many integrations with other areas and modules of the system. packing slips. The FormLetter framework allows you to manage the data for posting documents such as confirmations. and invoices. 8-50 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement . .. tables Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-51 .Chapter 8: Use and Design of the Sales and Purchase Modules Test Your Knowledge Test your knowledge with the following questions. ( ) PurchPriceTable ( ) EcoResPriceTable ( ) InventTableModule ( ) InventTablePrice 4. Describe what happens to MarkupTrans when an invoice transaction is posted. If no price is found in the PriceDiscTable which table is used to select the price. Which set of tables is used to store document generation information before a document is posted for sales orders? ( ) SalesUpdate. tables ( ) SalesParm.... Which class is used to control functionality about each type of order? ( ) PurchOrderType ( ) PurchTableType ( ) InventOrderType ( ) InventTableType 2. tables ( ) SalesPost. 1. tables ( ) SalesDocument. 3.... 2. 3. 8-52 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 Quick Interaction: Lessons Learned Take a moment and write down three key points you have learned from this chapter 1. If no price is found in the PriceDiscTable which table is used to select the price. a copy of the charge transaction is created that is related to the invoice journal... tables (•) SalesParm... 3. The copy is related to the original record by the OrigTableId and OrigRecId fields... tables Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement 8-53 ..Chapter 8: Use and Design of the Sales and Purchase Modules Solutions Test Your Knowledge 1. Which set of tables is used to store document generation information before a document is posted for sales orders? ( ) SalesUpdate. MODEL ANSWER: When the invoice is generated. Describe what happens to MarkupTrans when an invoice transaction is posted. tables ( ) SalesDocument.. ( ) PurchPriceTable ( ) EcoResPriceTable (•) InventTableModule ( ) InventTablePrice 4. tables ( ) SalesPost. Which class is used to control functionality about each type of order? ( ) PurchOrderType (•) PurchTableType ( ) InventOrderType ( ) InventTableType 2. Development IV in Microsoft Dynamics® AX 2012 8-54 Microsoft Official Training Materials for Microsoft Dynamics® Your use of this content is subject to your current services agreement .