Ax2012 Enus Deviv 08 PDF

Chapter 8: Use and Design of the Sales and Purchase Modules
CHAPTER 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

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 customers account that must be paid for by the customer.
8-3

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

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 availableJournal, 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 deliverys 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.
8-5

The Purchase module is used to keep track of procurement activities. The following figure shows the interface with other modules in Microsoft Dynamics AX.
FIGURE 8.2 PURCHASE ORDER INTEGRATIONS WITH OTHER MODULES
8-6

Purchase Order Data Model
The following figure shows the purchase order data model.
FIGURE 8.3 PURCHASE ORDER DATA MODEL
The PurchTable table holds a record for each purchase order, whereas the related lines are stored in the PurchLine table. 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.
8-7

When there is a delivery schedule on a purchase order line, the PurchLine table stores one record for each delivery date, and there is "master" record for the original purchase order line. The LineDeliveryType field is used to determine whether the line has a single delivery or multiple deliveries. When the value is OrderLine there is only one delivery. When the value is OrderLineWithMultipleDeliveries, the line is original order line that has a delivery schedule attached. When the value is DeliveryLine, the line is one of the scheduled deliveries. Inventory dimensions for the purchase order lines, such as size, color, and configuration, are saved in a separate table, labeled InventDim. The InventDimId field creates the relationship between a purchLine and the record holding dimension values. This design is used because it reduces the number of indexes in tables holding inventory dimensions. The InventDim table has many indexes related to individual inventory dimensions. 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. The purchase order lines are always related to a record in the InventDim table, even if all inventory dimensions have blank values. Inventory transactions are used to store the status and history of the inventory receipts and issues. Each purchase order line has one related record in the InventTransOrigin table. Each InventTransOrigin record is related to one or more InventTrans table records. By default the relationship between the InventTransOrigin and the InventTrans is a one-to-one relationship. However, when a delivery schedule exists on a purchase order line, multiple InventTrans records are created. There are other scenarios, such as partial receipts and invoices that can cause multiple inventory transaction records to be created. Additionally, there are scenarios where inventory transactions do not exist, 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.
8-8

Purchase Order Classes
Microsoft Dynamics AX 2012 supports several different types of orders such as journals, return orders, and purchase and sales orders. Each order type supports different tasks and functionality. Instead of using many if-statements to separate the functionality about the order type, the properties and methods are isolated on the class hierarchies PurchTableType and PurchLineType. Sales orders use the class hierarchies called SalesTableType and SalesLineType. The following figure shows the PurchTableType class hierarchy.
FIGURE 8.4 PURCHTABLETYPE TYPE HIERARCHY BROWSER
The following figure shows the PurchLineType hierarchy.
FIGURE 8.5 PURCHLINETYPE TYPE HIERARCHY BROWSER
On the PurchTable and PurchLine an object method called type() is used to construct the actual object. Object methods such as insert(), update(), delete(), validateWrite(), and validateField() are implemented on the classes. The object method on the table is activated by the kernel. However, the call is redirected to the object constructed by the object method type(). A modification to these methods should be implemented on the classes instead of on the table object method. The dataflow object method called initFrom() is also implemented on the classes.
8-9

If you must have a new property on an existing or new subclass of these hierarchies, add the default property to the root class and override it on the subclass in question. To create a new order type, start by adding a new element to the purchase order type base enumeration, and then create a new class that extends the PurchTableType and PurchLineType classes. 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. As discussed earlier, a purchase order consists of a header and several purchase order lines. The total amounts of the purchase order are not stored in the database, instead they are calculated when the information is needed. This approach makes data entry faster, but reporting and inquiries slower. The totals of a purchase order are calculated by using the PurchTotals class. This class extends TradeTotals which Extends TradeTotalsBased which are also used for calculating sales totals. The totals are calculated in relation to the inquiry from the purchase order, check of the credit limit, update to an invoice, and so on. The scope of the calculation can range from one single purchase order line to a summary of multiple purchase orders. This is handled by several subclasses to the PurchTotals class. The following figure shows the PurchTotals class hierarchy.
FIGURE 8.6 PURCHTOTALS TYPE HIERARCHY BROWSER
The classes have many object methods returning several amounts such as order balance, volume, weight, taxes, charges, and so on.
8-10
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. The prices and discounts of the sales or purchase agreement overrule any prices and discounts stated in any trade agreements that could exist. You can specify the agreement commitment type on the purchase and sales agreements. This controls what information is required on the agreements. The commitment type also determines how the agreement is being managed to determine when the commitment is fulfilled.
Trade Agreements
Prices of sold and purchase items should be maintained. Prices can be set up specifically for individual items, customers, and vendors, or prices can be set up for a group of customers or vendors, or for all customers as one group. The price structure also includes line, multiline, and final discounts. Administration of sales prices and purchase prices that includes publishing to the organization and customers, is an ongoing task.
8-11

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, InventItemSalesSetup, and in InventItemInventSetup tables.
8-12

The following figure shows the design of the purchase price and discount data model.
FIGURE 8.8 PURCHASE PRICE AND DISCOUNT DATA MODEL
When more complex pricing is required, you can use Trade agreements to define detailed pricing information for specific vendors, currencies, quantities, or date ranges. Trade agreements allow you to set up purchase prices, line discounts, multiline discounts, and total discounts. This is controlled by the Relation field on the PriceDiscTable. Each specification in the price agreement table contains item and vendor dimensions. 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. The search for a price or discount must use a priority between the several combinations. 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, vendors, or items that you want to handle in the same way for prices. A separate price group can be created for each type of pricing (prices, line discounts, multiline discounts, and total discounts) and for each group of transactions (customers, vendors, and items). Many different relations exist between the PriceGroup table and the PriceDiscTable.
8-13

If no price is found in the PriceDiscTable the price specified in InventTableModule is used. You cannot change the information in PriceDiscTable directly. Instead, you must create a price and discount journal and make the modifications in the journal. When the journal is posted, the records are updated or created in PricDiscTable. The PriceDiscTable is configured to Found caching in the standard application. It can be relevant to change this setting, depending on the amount of data in the table. The design of the price searches does not support found (single-record) caching as it contains criteria on quantity and date intervals. The following figure shows the design for the price and discount journal function:
FIGURE 8.9 PRICE AGREEMENT JOURNAL DATA MODEL
The PriceDiscAdmName table contains the journal names that are defined in the setup. PriceDiscAdmTable contains the header for each journal, whereas PriceDiscAdmTrans contains the individual price agreements. If the journal line is loaded from the existing agreements, then it will be related to the existing record in PriceDiscTable (RecId).
8-14

Trade Agreements Classes
The PriceDisc class is used to search for price and discount information. It is activated from the Sales and Purchase module when a line is created or changed. The prices are not recalculated during updates, so you have the opportunity to make manual adjustments to the price and discounts on the individual sales line. The search for information in the PriceDisc class is executed in the findPriceAgreement() object method. Price and discount agreement journals are posted by using the PriceDiscAdmCheckPost class. The PriceDiscAdmAdjustment class is used to select existing trade agreements and make changes to existing trade agreements.
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, or discounts with a specific customer/vendor. In previous versions, you used the blanket order type in sales orders to set up these agreements. The prices and discounts of the sales or purchase agreement overrule any prices and discounts stated in any trade agreements that might exist. You can specify the agreement commitment type on the purchase and sales agreements. This controls what information is required on the agreements. The commitment type also determines how the agreement is being managed to determine when the commitment is fulfilled. The agreement framework in Microsoft Dynamics AX 2012 includes the following features. Ability to express in the system a contractual commitment of sale of purchase for a specific amount of quantity of a certain item, category or any item/category. Enforces price agreements on the purchases or sales when theyre done according to agreement. Follow up on sales or purchases to see if the contractual obligations have been fulfilled.
Sales and Purchase Agreement Data Model

In Microsoft Dynamics AX 2012 the agreement frameworks data model is completely separated form general purpose order data model. This separation helps to optimize data structure, because there is no need for entities stored in database to carry properties that do not make sense for agreements.
8-15

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, encapsulating both data- and functional- specializations within a single type of objects AX Data Tables. With that done the need for supporting class hierarchy behind the used data tables was completely eliminated. The following figure show the data model for purchase agreements.
FIGURE 8.10 PURCHASE AGREEMENT DATA MODEL
8-16

Agreement Classifications
Agreement classifications are a required field on agreements. Classifications help group agreements into different types. Functionality does not change with different types. These values can be used for reporting and analysis. Purchase agreement classifications are setup on the form at the following location: Procurement and sourcing > Setup > Purchase agreements > Purchase agreement classification. The following figure shows the data model for agreement classifications.
FIGURE 8.11 AGREEMENT CLASSIFICATION DATA MODEL
8-17

Agreement History
The agreement framework in Microsoft Dynamics AX2012 enables users to create a snapshot of the current agreement state at any given time. 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. To enable this functionality the agreement framework defines a number of history entities shown in the following figure.
FIGURE 8.12 AGREEMENT HISTORY DATA MODEL
Explicit relations between history- and base- entities are established for only a few entities (exactly only for AgreementHeader and AgreementHeaderHistory as well as for AgreementLine and AgreementLineHistory). Besides them, all other similar relations would be redundant for the data model and therefore were not implemented.
8-18

Also it is important to note that History entities for agreement headers and lines do not directly implement Header-Lines pattern. You can see in the previous figure that there is no relation between AgreementHeaderHistory and AgreementLineHistory entities. While logically each agreement header history instance contains several agreement line history instances still, 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.
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. You can also relate a purchase agreement to a purchase order from the Create purchase order form in the Purchase agreement field. 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. Each purchase order line can have one purchase agreement linked. 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. 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, or when you create purchase orders through Master planning.
Charges
A charge is an additional fee or cost that can be added to a purchase or sale order. Charges can be linked to the header or the lines of the orders. They can be added manually to an order, or a rule can be configured to have charges automatically added to an order.
8-19

The following figure shows the data model for the relation of charges with a sales order.
FIGURE 8.13 SALES ORDER CHARGES DATA MODEL
Each charge that is added to an order is defined by the charge code. The charge code defines how the charge will be assessed. 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. Another option on the set up of the charge code is used for the charge to be assessed to the item. 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. Similar options exist for purchase orders. Additionally, 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. 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.
8-20

Definitions of charge codes are stored in the MarkupTable, whereas registrations related to the sales order and purchase order are stored in the MarkupTrans table. When the invoice is generated, a copy of the charge transaction is created that is related to the invoice journal. The copy is related to the original record by the OrigTableId and OrigRecId fields. The following figure shows charges and their relation to Purchase order invoicing.
FIGURE 8.14 PURCHASE ORDER INVOICE CHARGES DATA MODEL
8-21

An alternative to entering charges manually for each order is to define automatic charges. The following figure shows the design of automatically generated charges:
FIGURE 8.15 AUTOMATIC CHARGES DATA MODEL
The AccountCode and ItemCode fields are enumerations with the following entries. Table: If the value is Table, then the related information in the Account/Item-relation is a specific customer or item. Group: If the value is Group, then the related information is a specific group that is defined in the Markup group of the type customer or item. All: If the value is All, then the related information is blank.
Automatic charges can be related to a specific customer or item combinations. Only charges related to a sales line or purchase line can have an ItemCode that differs from All. When an order or order line is created, the application will search for related information in the MarkupAutoTable. If the search finds some information, then the related information in the MarkupAutoLine table is copied to the MarkupTrans table. The MarkupAutoTable and MarkAutoLine tables can be ignored if all charges will be manually created.
8-22
FormLetter Framework
The FormLetter framework in Microsoft Dynamics AX is used when posting documents for sales or purchase orders. This framework is refactored in Microsoft Dynamics AX 2012 to provide better support for customizations, extensibility, and performance. This lesson describes the Microsoft Dynamics AX 2012 version of the framework.
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, in Microsoft Dynamics AX 2012, there are a number of new class hierarchies. The following object model shows the new set of base classes and how the classes interact with each other.
FIGURE 8.16 FORMLETTER BASE CLASSES IN MICROSOFT DYNAMICS AX 2012
8-23

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. Switching to the SysOperation framework has the advantage of executing the code on the server tier during posting in Common Intermediate Language (CIL). Because of the switch to the SysOperation framework, client callbacks from code running on the server tier are no longer supported. Client callbacks result in an exception. The following figure shows how the various base classes are used when posting a document for an order.
FIGURE 8.17 DOCUMENT POSTING BASE CLASSES
8-24

The following figure shows the various class hierarchies used when posting a sales order packing slip document.
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, the SalesEditLines form). The FormLetterServiceController class is executed on the client tier. 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. The FormLetterServiceController invokes the FormLetterService class when the run method is called.
8-25

The following figure shows the FormLetterServiceController class hierarchy.
FIGURE 8.19 FORMLETTERSERVICECONTROLLER CLASS HIERARCHY
The module specific classes, such as SalesFormLetter, are updated so that they extend the FormLetterServiceController class. All functionality that does not relate to the interaction with the Posting form is moved to other class hierarchies. 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 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. The following code sample is an example of a parm method.
public boolean parmDirectDeliveryUpdate(boolean _directDeliveryUpdate = salesFormLetterContract.parmDirectDeliveryUpdate()) { return salesFormLetterContract.parmDirectDeliveryUpdate(_directDel iveryUpdate); }
FormLetter Framework: FormLetterContract

The FormLetterContract class is the base data contract class in the FormLetter framework. The data contracts follow the same class hierarchy structure as the FormLetterServiceController classes. Therefore, each class in the FormLetterServiceController class hierarchy has a corresponding data contract class. The data contract classes pass data from the FormLetterServiceController to the FormLetterService.
8-26

The following figure shows the FormLetterContract class hierarchy.
FIGURE 8.20 FORMLETTERCONTRACT CLASS HIERARCHY
Parm methods are used to set and get the data from a contract class. The following code sample is an example of a parm method:
[DataMemberAttribute] public NoYes parmDirectDeliveryUpdate(NoYes _directDeliveryUpdate = directDeliveryUpdate) { directDeliveryUpdate = _directDeliveryUpdate; return directDeliveryUpdate; }
8-27

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), meaning that there can be no client callbacks from this class. Client callbacks result in an exception. The following figure illustrates some of the FormLetterService class methods.
FIGURE 8.21 FORMLETTERSERVICE
The run method initializes the objects required for posting, creates the journal, posts the documents, and then calls the logic to print the document if required. The class also has a service operation method for each of the document types that can be posted by this service, such as PostSalesPackingSlip.
[SysEntryPointAttribute] FormLetterOutputContract postSalesOrderPackingSlip(SalesFormLetterPackingSlipContrac t _contract) { formletterContract = _contract; this.run(); return outputContract; }
8-28

FormLetter Framework: FormLetterParmData
The FormLetterParmData class hierarchy can be used to create and maintain posting data in the parm tables, such as SalesParmUpdate, SalesParmTable, and SalesParmLine. The following figure shows the data model for a sales order update.
FIGURE 8.22 FORMLETTERPARMDATA CLASS HIERARCHY
The SalesTable and SalesLine tables contain information manually entered in the sales table form. The update is activated by using a button in the Action Pane of the Sales order form. This creates an update specification in the SalesParm-tables. General update parameters are stored in SalesParmUpdate. Specifications related to one sales order are stored in SalesParmTable, whereas individual lines are specified in SalesParmLine. Lines from different sales orders can be collected in one invoice. The SalesParmSubTable holds one record for each sales order that contributes to such invoices. Information in SalesParmLine refers to the sales order that contains the invoice with the SalesId field, whereas the OrigSalesId field contains the ID of the sales order that relates to the line(s) in question. SalesParmSubLine contains sales order line update relations.
8-29

The base class uses a template pattern that defines a template for how to create records in the parm tables. There are module specific classes such as SalesFormLetterParmData, and one class for each document type supported, such as SalesFormLetterParmDataPackingslip. The class has three public Application Programming Interfaces (APIs). CreateData: Creates the required data in the parm tables. ReSelect: Recreates the data based on the specQty in the posting form. ReArrange: Rearranges the data in the tables based on summary update settings.
The following figure shows the FormletterParmData class hierarchy.
FIGURE 8.23 FORMLETTERPARMDATA CLASS HIERARCHY
FormLetter Framework: FormLetterJournalCreate

The FormletterJournalCreate class hierarchy creates one journal with a header, for example, CustPackingSlipJour, and a number of lines, for example CustPackingSlipTrans, and related journal data, for example, CustPackingSlipSalesLink. The base class uses a template pattern that defines how to create a journal. The template is similar to the following code sample, which can be found in the FormLetterJournalCreate.createJournal() method.
8-30

if (this.check())//Validate that the journal can be created. { this.initJournalHeader();//Initialize the journal header. this.createJournalHeader(); //Create the journal header. this.createJournalLines(); //Create journal lines. if (this.isJournalCreated()) //If a journal were successfully created. { this.insertRecordList();//Insert all records into the database. this.endCreate();//Finalize journal creation. } }
8-31

The following figure shows the FormLetterJournalCreate class hierarchy.
FIGURE 8.24 FORMLETTERJOURNALCREATE OBJECT MODEL
There are also document specific classes for each of the documents created by the framework, such as SalesPackingSlipJournalCreate. These classes hold the logic specific for a document. 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.
8-32

FormLetter Framework: FormLetterJournalPost
The FormletterJournalPost class hierarchy can be used to post one journal, for example, to update the ledger and inventory. The base class uses a template pattern that defines how to post a journal. There is also a document specific class for each of the documents posted by the framework, for example SalesPackingSlipJournalPost. These classes hold the logic specific for a document. This class hierarchy requires that a journal is created and passed in. The FormletterService class instantiates this class for each of the journals it needs to post and calls run. The following figure shows the FormletterJournalPost class hierarchy.
FIGURE 8.25 FORMLETTERJOURNALPOST CLASS HIERARCHY
8-33

When a document is posted, the data from the parm tables is copied to another set of tables that are used for balancing the ledger to the sub-ledger. For example, the sales order invoice creates transactions into the customer invoice tables. The following figure shows the data model for a sales order invoice document.
FIGURE 8.26 SALES ORDER INVOICE DOCUMENT DATA MODEL
CustInvoiceJour contains information copied from SalesTable, whereas CustInvoiceTrans is created based on information in SalesLine. Both tables can be affected by information specified in the SalesParm-tables when updates are ordered. If multiple sales orders contribute sales lines to one invoice, then only one of the sales IDs will be stored in CustInvoiceJour. CustInvoiceSalesLink is used to show all invoices related to a sales table, regardless of which sales order owns the invoice. SalesTable and SalesLine can be changed or deleted after invoice update. So it is important to only use information that is stored in CustInvoiceJour and CustInvoiceTrans when you design reports and calculate statistics. Although information in the SalesParm-table is saved after the update, reporting should not be based on these tables. They are designed to only control updates, and the ability to delete obsolete information in these tables without destroying reporting capabilities, could be needed later.
8-34

TIP: A periodic job can be used to clean up and delete records from the parm tables. The previous pattern is repeated many times, one for each type of update in the sales and purchase areas. Module Sales Document Quotation Confirmation Picking list Packing slip Invoice Purchase Confirmation Receipts list Packing slip Invoice -Jour, -Trans, and-Link CustQuotation... CustQuotationConfirmation... CustConfirm... WMSPickingRoute... CustPackingSlip... CustInvoice... VendPurchOrder... VendReceiptsList... VendPackingSlip... VendInvoice...
FormLetter Framework: FormLetterJournalPrint

The FormLetterJournalPrint class hierarchy can be used to control the printing of one or more journal documents. There is a document-specific class for each the documents that can be printed by the framework. The FormLetterService class instantiates this class either for each of the journals being posted, or once with a list of all posted journals.
8-35

The following figure shows the FormLetterJournalPrint class hierarchy.
FIGURE 8.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. There is one child class for each module, for example, SalesFormLetterProvider. The following figure shows the FormLetterProvider class hierarchy.
FIGURE 8.28 FORMLETTERPROVIDER CLASS HIERARCHY
8-36
Lab 8.1 - 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 .initFrom() methods. Estimated time to complete: 30 minutes Scenario The solution should contain a new field in the customer table. This field should contain instructions for the payment of invoices sent to the customer. The field should be implemented as a multiline field, with a limit of 100 characters. When a new sales order is created, this field should be copied to the sales order. You should be able to change the value for specific sales orders. When you post an invoice, you should be able to change the field without overwriting the original value in the sales table. The value specified while ordering the update should be printed on the invoice.
Technical Issues
This section outlines additional information that is required to implement the new field.
InitFrom
Transfer of information from one table to another is frequently used when you create records and save transactions from updates. This task is typically implemented by creating an object method in the destination table named initFrom<sourcetable>. Creating a record in a sales table in this manner involves the activation of the following logic
salesTable.initFromCustTable();
Extension of the existing flow of information can typically only be resolved by adding fields to the tables and to the corresponding initFrom-methods.
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, Picking list, or Sales order confirmation the SalesEditLines form is displayed in the user interface. The layout of this form depends on the kind of posting selected. However, other criteria such as the settings of the Sales order module can also change the layout of the SalesEditLines form.
8-37

The SaleFormLetter class hierarchy is used for this posting. Depending on the menu item that is selected, the appropriate subclass of SalesFormLetter is instantiated. The dialog method of the SalesFormLetter object opens the SalesEditLines form. In the init method of the SalesEditLines form an object of one of the classes in the SalesEditLinesForm hierarchy is instantiated. Methods of this class hierarchy are called from the form to control the layout of the form. The pattern used can be explained by viewing how the display of the Bill of lading tab page is controlled in SalesEditLines. The Bill of lading tab page is only visible if you are posting to an invoice.
A method is implemented in the SalesEditLinesForm class: public boolean billOfLading() { return false; } This method is overridden in the SalesEditLinesForm_invoice class: public boolean billOfLading() { return SalesParameters::find().useBillOfLadingOnInvoice(); } This method is called in the init method of the form as shown: tabPageBillOfLading.visible(salesEditLinesForm.billOfLading ());
Implementation
Extend CustTable, SalesTable, SalesParmTable and CustInvoiceJour tables with the new field that contains the instructions for the payment of invoices sent to the customer. 1. Create a new project to store all of the objects that you modify or create as a part of this lab. 2. Make an extended data type defining properties of the payment instruction. 3. Create a new field in the tables that is required to implement the requested possibilities to change and store the information. 4. Add fields to the relevant forms to view the current value and possibly edit this value. 5. Add a field to the SalesInvoiceTmp table for the payment instructions and modify the SalesInvoiceDP class to populate the field. Then include the field in the header of the SalesInvoice report.
8-38

6. Verify implementation by using an example. 7. Use the pattern explained to make the new field visible when you are posting to an invoice and not visible when doing other postings.
Step by Step: Add the Payment Instruction Field

Follow these steps to create a new project. 1. 2. 3. 4. 5. 6. Open the Development workspace. Open the Projects window. Right-click the Shared node and then click New > Project. Right-click the new project and select Rename. Enter a name for the project such as NewFieldOnInvoiceLab. Double-click the project to open it, and then close the Projects window.
To add the payment instruction extended data type, follow these steps. 1. In the AOT window expand the Data Dictionary node. 2. Right-click the Extended Data Type node and select New > String. 3. In the Properties window, set the following values on the new real. a. Name = PaymentInstruction b. Label = Payment instruction c. HelpText = Instruction on how the customer should pay the invoice. d. DisplayHeight = 3 e. StringSize = 100 4. Save the extended data type. 5. Drag the newly created PaymentInstruction extended data type into the project that you created earlier. To add the payment instruction field to the CustTable, SalesTable, SalesParmTable, and CustInvoiceJour tables, follow these steps. 1. Under the Data Dictionary node in the AOT window, expand tables and locate the CustTable. 2. Drag the table into the project that you created earlier. 3. Expand the CustTable table. 4. Select the PaymentInstruction extended data type and drag it to the Fields node of the CustTable table. 5. Save the table. 6. Right-click the Field groups node and then click New Group.
8-39

7. Set the following values in the Properties window. a. Name = PaymentInstruction b. Label = Payment instruction 8. Select the Payment instruction field from the Fields node on the CustTable table, and then drag it into the PaymentInstruction Field group. 9. Save the table. If the Synchronize table window opens, click Continue. 10. Repeat steps 1-9 for the SalesTable, SalesParmTable, and CustInvoiceJour tables. To add the payment instruction field to the CustTable, SalesTable, SalesEditLines forms, follow these steps. 1. In the AOT window, expand Forms and then locate the CustTable form. 2. Drag the CustTable form into the project that you created earlier. 3. Save the project. 4. Right-click the CustTable form and then click Restore. 5. In the Data Sources node of the form browse to CustTable > Fields and then select the Payment Instruction field group (folder) from the list. 6. Drag the Payment Instruction field group into the bottom of the Sales order defaults FastTab (TabPageSales) under the Design node of the form. (To locate the TabPageSales tabpage, browse to Designs > Design > Tab:Tab > TabPage:TabPageDetails > Tab:TabHeader > TabPage:TabPageSales in the CustTable form.) 7. Right-click on the CustTable form and then click Open. 8. Verify that the new Payment instruction field is available. 9. Repeat steps 1-8 for the SalesTable form. Place the field group on the Setup (TabHeaderSetup) FastTab of the Header view on the form. (To locate the TabHeaderSetup, browse to Designs > Design > Tab:MainTab > TabPage:TabPageDetails > Tab:DetailsTab > TabPage:HeaderView > Tab:HeaderDetailsTab > TabPage:TabHeaderSetup in the SalesTable form.) 10. Repeat steps 1-8 for the SalesEditLines form (the field group is in the SalesParmTable data source). Place the field group on the Setup (TabSetup) tab on the form. (To locate the TabSetup, browse to Designs > Design > Tab:TabSalesParmTable > TabPage:TabSetup in the SalesEditLines form.) NOTE: You cannot open this form directly, you must open it from the Sales order form by selecting a delivered sales order, and then click the Invoice tab in the Action Pane, and then click Invoice in the Generate group.
8-40

Step by Step: Add Code to Populate the Field
To add logic for populating the Payment instruction field, follow these steps. TIP: The code samples for this lab can be found in the AX2012_ENUS_DEVIV_08_01_LAB_CODE.txt file. You can copy and paste these code samples into the correct methods. 1. Add the AXCustInvoiceJour class to the project. 2. Create a new method called setPaymentInstruction to set the value of the field. Use the following code sample to guide you. protected void setPaymentInstruction() { if (this.isMethodExecuted(funcname(), fieldnum(CustInvoiceJour, PaymentInstruction))) { return; } } 3. Modify the setTableFields method in the AXCustInvoiceJour class to call the new setPaymentInstruction method that you created in step 2. Use the following code sample to guide you. this.setPaymentInstruction(); 4. Create a new method called parmPaymentInstruction to the AXCustInvoiceJour class. Use the following code sample to guide you. public PaymentInstruction parmPaymentInstruction(PaymentInstruction _paymentInstruction = '') { if (!prmisdefault(_paymentInstruction)) { this.setField(fieldnum(CustInvoiceJour, PaymentInstruction), _paymentInstruction); } return custInvoiceJour.PaymentInstruction; } 5. Repeat steps 1-4 for the AXCustTable, AXSalesParmTable, and AXSalesTable classes.
8-41

NOTE: The code will vary slightly for each method. Make sure to use the correct table and field for each class. 6. Add the CustCustomer_CustTable class to the project. 7. Modify the classDeclaration to declare a macro for the payment instruction. Use the following code sample to guide you. #define.PaymentInstruction('PaymentInstruction') 8. Create a new method called existsPaymentInstruction to check of the payment intruction exists. Use the following code sample to guide you. public boolean existsPaymentInstruction() { return this.exists(#PaymentInstruction); } 9. Create a new parm method called parmPaymentInstruction. Use the following code sample to guide you. public PaymentInstruction parmPaymentInstruction(PaymentInstruction _value = '') { if (!prmisdefault(_value)) { this.set_Attribute(#PaymentInstruction, _value); } return this.get_Attribute(#PaymentInstruction); } 10. Repeat steps 6-9 for the ProdProjEInvoice_CustTable, ReturnReturnOrderIn_SalesTable, ReturnReturnOrderOut_SalesTable, SalesSalesEInvoice_CustInvoiceJour, SalesSalesEInvoice_CustTable, SalesSalesInvoice_CustInvoiceJour, SalesSalesOrder_SalesTable, and the SalesSalesPackingSlip_SalesParmTable classes. NOTE: The code will vary slightly for each method. Make sure to use the correct table and field for each class. 11. Add the SalesEditLinesForm class to the project. 12. Create a new method that returns a false. Use the following code sample to guide you.
8-42

public boolean PaymentInstruction() { return false; } 13. Add the SalesEditLinesForm_Invoice class to the project. 14. Create a new method that returns a true. Use the following code sample to guide you. public boolean PaymentInstruction() { return true; }
Step by Step: Modify the Sales Invoice Report

To add a field to the SalesInvoiceTmp table for the Payment instructions, follow these steps. 1. Under the Data Dictionary node in the AOT window, expand tables and locate the SalesInvoiceTmp. 2. Drag the table into the project that you created earlier. 3. Expand the SalesInvoiceTmp table. 4. Select the PaymentInstruction extended data type and drag it to the Fields node of the SalesInvoiceTmp table. 5. Save the table. To modify the SalesInvoiceDP class to populate the Payment instructions field, follow these steps. 1. Locate the SalesInvoiceDP class and drag it into the project that you created earlier. 2. Locate the insertIntoSalesInvoiceTmp method and then right-click and select View Code. 3. 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. Use the following code sample to guide you. salesInvoiceTmp.PaymentInstruction = custInvoiceJour.PaymentInstruction; 4. Save and compile the class. To modify the sales invoice report, follow these steps. 1. In the AOT window, locate the SSRS report called SalesInvoice. 2. Add the Sales Invoice report to the project that you created earlier.
8-43

3. Locate the SalesInvoiceReport project in the Visual Studio Projects node of the AOT window. 4. Right-click the project and select Edit. 5. When Visual Studio 2012 opens, locate the SalesInvoice report in the Solution Explorer window and then double-click it to open. 6. Expand the Datasets node and then right-click the SalesInvoiceDS and select Refresh. 7. Expand the Designs node and then right-click the Report node and select Edit Using Designer. 8. Add the payment instruction field into the header section of the report. 9. Save the report, build the project, and deploy the report.
Test
Use the following steps to create a new sales order, and to post and print the invoice. 1. 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. 2. Create a new sales order by using the path Accounts receivable > Common > Sales order and select the customer modified in step 1. Make a modification to the payment instruction inherited from the customer. 3. Add a line to the sales order for item number 10007. 4. Post the invoice by clicking the Invoice tab of the Action Pane and then click Invoice in the Generate group. Change the payment instruction inherited from the sales order. 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. 5. You can repeat the test by creating a new sales order. TIP: You can compare your solution to the AX2012_ENUS_DEVIV_08_01_LAB_SOL.xpo file provided with the training image by importing the XPO file and then comparing the objects.
8-44
Other Features
There are many additional features in the Sales and Purchase Order modules. The following lesson introduces sales quotations, request for quotations, purchase requisitions, and categories.
Document History and Change Management

Many of the documents stored in Microsoft Dynamics AX are not static. They can be changed or corrected by users based on changes in the environment they describe or when errors are found. Microsoft Dynamics AX 2012 introduces a pattern for how modifications to such documents can be effectively managed and efficiently represented in the database. The two main functional benefits of applying the versioning pattern are: Full traceability (history) of changes made to a document. At any time a new version of the document can be recorded. Any two versions of the document can be compared with a generic version comparison tool. A standardized document state model enabling change management with workflow approvals. Documents are editable only when they are in a draft, in review and rejected states. A new version is recorded upon approval.
Purchase order
The purchase order is the most complex use of the versioning pattern in Microsoft Dynamics AX 2012. Besides the traceability and change management with workflow integration it also enabled other procurement functionality extensions like encumbrance accounting for confirmed purchase orders. The change management functionality for purchase orders is optional in Microsoft Dynamics AX 2012 and turned off by default. It can be configured at the legal entity, vendor or specific order level. When activated any change to order data requires workflow approval. When not activated the purchase order is always considered pre-approved. Intercompany, Direct Delivery and production/master planning derived orders never have change management enabled. 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. 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).
8-45

Product receipt and packing slip
Product receipts and packing slips use of the pattern is limited to versioning and no workflow integration is enabled. Product receipt and packing slip documents can be explicitly corrected in Microsoft Dynamics AX 2012. However, only received/delivered quantity can be corrected and only downwards. Intercompany direct delivery packing slip corrections are also supported. 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 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. There is no limit to the depth of the tree. The following figure illustrates an abstract document model. Typically nodes would be stored in various database tables with fields corresponding to document note type attributes.
FIGURE 8.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. White entities were present in earlier AX versions: PurchaseOrder (PurchTable), PurchaseOrderLine(PurchLine) and the *MiscCharge* entities (MarkupTrans). They define the basic PO tree structure with the PurchaseOrder being the root node, PurchaseOrderLine its child node type and MiscCharge nodes that could be children of both PurchaseOrder and PurchaseOrderLine. The highlighted entities were added to support versioning.
8-46

Physical table names of the history tables are based on the physical table names of the corresponding node tables, for example, the physical table name for the purchase order line history entity is PurchLineHistory. 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, PurchLineHistory.ItemId) to help simplify queries against the archived versions (in other words, there is no need to join PurchTable, PurchLine and MarkupTrans in such queries).
FIGURE 8.30 PURCHASE ORDER DOCUMENT HISTORY DATA MODEL
The VersioningCompare form can be used to visualize differences between document versions. It displays document tree on the left side with icons indicating changed/deleted/added nodes. For the selected node there is list of changed attributes shown on the right side of the form with old and new value columns. The form uses VersioningCompare abstract class as a data provider interface. Documents for which the form is to be used need to provide a subclass implementing all the abstract methods.
8-47

Sales Quotations
A quotation is a proposal to a customer to make an order. The quotation can be sent to prospects that are not existing customers or existing customers, and typically the company issuing the quotes does not expect to receive orders from all the recipients of the quotation. If a quotation is accepted, it will be transformed into a sales order. The SalesQuotationTable table stores one record for each quotation. The details of the quotation are stored in SalesQuotationLine. When the quote is confirmed the data is transferred to the sales order that is described in the following section. The SalesQuotationLine is related with one or more inventory transactions from the record that is created until it is confirmed, canceled, or lost. These inventory transactions will have a status called Quotation issue or Quotation receipt (a negative quantity on a quotation line). Sales quotations can be included in the master planning. When the quotation is confirmed the inventory transactions related to the quotation line are replaced by inventory transactions related to the created sales line.
Request for Quotations

Request for quotations are documents that you send to one or more vendors requesting them to quote a price, delivery terms, and terms of payment for materials to be purchased. The user can accept or reject the request for quotation, fully or partly and transfer the request for quotation to a purchase order. Options are available to create a request for quotation, receive and compare the request for quotation replies and create a purchase order from a request for quotation. The PurchRFQCaseTable stores one record for each case, and the PurchRFQTable stores one record for each vendor on a specific case. The details of the quote are stored in PurchRFQCaseLine. 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, returned, or rejected. These inventory transactions will have a status called Quotation issue or Quotation receipt. When the quote is accepted the inventory transactions related to the quotation line are replaced by inventory transactions related to the created Purchase line.
8-48

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. By using purchase requisitions, you can do the following. Request items and services from a procurement catalog. You can also request items and services that are not listed in a catalog. Request items or services on behalf of someone else, or in a legal entity or operating unit other than the one in which you hold a primary position. Suggest a vendor from whom to order an item or service. Distribute an amount on a purchase requisition line to multiple financial accounts and dimensions. Perform budget checking on the purchase requisition if your organization uses budget checking. Submit the purchase requisition for review and approval.
Purchase requisitions require a workflow to be configured for approval. They can be submitted through the Order Products page on Enterprise Portal or created and submitted through the rich client. The PurchReqTable table contains one record for each purchase requisition. The details of each product or category on the purchase requisition are stored in the PurchReqLine table. Each purchase requisition and line on a purchase requisition can contain a reason or business justification for the request. The system can be configured to require business justifications. The business justifications for each purchase requisition and line are stored in PurchReqBusJustification. 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.
8-49
Summary
Sales orders and purchase orders are two of the main transactions in Microsoft Dynamics AX. The functionality and data structures that are used with each are very similar. Sales orders and purchase order have many integrations with other areas and modules of the system. Several different frameworks are provided with Microsoft Dynamics AX to help you manage basic order information, pricing, charges and document history. Both areas integrate with the agreements feature which allows you to define basic contracts for sales or purchases. The FormLetter framework allows you to manage the data for posting documents such as confirmations, packing slips, and invoices.
8-50
Test Your Knowledge

Test your knowledge with the following questions. 1. Which class is used to control functionality about each type of order? ( ) PurchOrderType ( ) PurchTableType ( ) InventOrderType ( ) InventTableType 2. Describe what happens to MarkupTrans when an invoice transaction is posted.
3. If no price is found in the PriceDiscTable which table is used to select the price. ( ) PurchPriceTable ( ) EcoResPriceTable ( ) InventTableModule ( ) InventTablePrice 4. Which set of tables is used to store document generation information before a document is posted for sales orders? ( ) SalesUpdate... tables ( ) SalesParm... tables ( ) SalesPost... tables ( ) SalesDocument... tables
8-51
Quick Interaction: Lessons Learned

Take a moment and write down three key points you have learned from this chapter 1.
2.
3.
8-52
Solutions
Test Your Knowledge
1. Which class is used to control functionality about each type of order? ( ) PurchOrderType () PurchTableType ( ) InventOrderType ( ) InventTableType 2. Describe what happens to MarkupTrans when an invoice transaction is posted. MODEL ANSWER: When the invoice is generated, a copy of the charge transaction is created that is related to the invoice journal. The copy is related to the original record by the OrigTableId and OrigRecId fields. 3. If no price is found in the PriceDiscTable which table is used to select the price. ( ) PurchPriceTable ( ) EcoResPriceTable () InventTableModule ( ) InventTablePrice 4. Which set of tables is used to store document generation information before a document is posted for sales orders? ( ) SalesUpdate... tables () SalesParm... tables ( ) SalesPost... tables ( ) SalesDocument... tables
8-53
8-54

Ax2012 Enus Deviv 08 PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Ax2012 Enus Deviv 08 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Chapter 8: Use and Design of the Sales and Purchase Modules

CHAPTER 8: USE AND DESIGN OF THE SALES AND PURCHASE MODULES

Development IV in Microsoft Dynamics AX 2012

Sales and Purchase Orders

Sales Order Feature Overview

Chapter 8: Use and Design of the Sales and Purchase Modules

Development IV in Microsoft Dynamics AX 2012

Sales Order Integrations

FIGURE 8.1 SALES ORDER INTEGRATIONS WITH OTHER MODULES

Chapter 8: Use and Design of the Sales and Purchase Modules

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.2 PURCHASE ORDER INTEGRATIONS WITH OTHER MODULES

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.3 PURCHASE ORDER DATA MODEL

Development IV in Microsoft Dynamics AX 2012

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.4 PURCHTABLETYPE TYPE HIERARCHY BROWSER

The following figure shows the PurchLineType hierarchy.

FIGURE 8.5 PURCHLINETYPE TYPE HIERARCHY BROWSER

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.6 PURCHTOTALS TYPE HIERARCHY BROWSER

Chapter 8: Use and Design of the Sales and Purchase Modules

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.7 INVENTTABLEMODULE DATA MODEL

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.8 PURCHASE PRICE AND DISCOUNT DATA MODEL

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.9 PRICE AGREEMENT JOURNAL DATA MODEL

Chapter 8: Use and Design of the Sales and Purchase Modules

Sales and Purchase Agreements

Sales and Purchase Agreement Data Model

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.10 PURCHASE AGREEMENT DATA MODEL

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.11 AGREEMENT CLASSIFICATION DATA MODEL

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.12 AGREEMENT HISTORY DATA MODEL

Chapter 8: Use and Design of the Sales and Purchase Modules

Sales and Purchase Agreements Classes

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.13 SALES ORDER CHARGES DATA MODEL

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.14 PURCHASE ORDER INVOICE CHARGES DATA MODEL

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.15 AUTOMATIC CHARGES DATA MODEL

Chapter 8: Use and Design of the Sales and Purchase Modules

FormLetter Framework: Base Classes

FIGURE 8.16 FORMLETTER BASE CLASSES IN MICROSOFT DYNAMICS AX 2012

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.17 DOCUMENT POSTING BASE CLASSES

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.18 SALES ORDER PACKING SLIP CLASS POSTING FLOW

FormLetter Framework: FormLetterServiceController

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.19 FORMLETTERSERVICECONTROLLER CLASS HIERARCHY

FormLetter Framework: FormLetterContract

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.20 FORMLETTERCONTRACT CLASS HIERARCHY

Development IV in Microsoft Dynamics AX 2012

FIGURE 8.21 FORMLETTERSERVICE

Chapter 8: Use and Design of the Sales and Purchase Modules

FIGURE 8.22 FORMLETTERPARMDATA CLASS HIERARCHY

Development IV in Microsoft Dynamics AX 2012