Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-1
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.
8-2
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-3
8-4
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-5
8-6
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-7
8-8
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-9
The classes have many object methods returning several amounts such as order balance, volume, weight, taxes, charges, and so on.
8-10
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-11
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-13
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-15
8-16
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-17
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-19
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-21
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-23
8-24
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-25
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); }
8-26
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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; }
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-27
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-29
8-30
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-31
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-33
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-35
8-36
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-37
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-39
8-40
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-41
8-42
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
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).
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-45
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-47
8-48
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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.
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-51
2.
3.
8-52
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
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
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement
8-53
8-54
Microsoft Official Training Materials for Microsoft Dynamics Your use of this content is subject to your current services agreement