Trade agreement evaluation (TAE) policies in Microsoft Dynamics … · 2018-10-16 · Lars David Jørgensen, Software Development Engineer Send suggestions and comments about this

Microsoft Dynamics®

AX 2012

Trade agreement evaluation

(TAE) policies in Microsoft Dynamics AX 2012

Implementation Considerations

TAE policies is a feature of Microsoft Dynamics AX 2012 that helps to prevent unintentional overwriting of prices and

discounts that are manually entered, or that originate from sources other than the built-in trade agreement system. This document explains the architecture, and also provides hints for

extending and debugging TAE policies. It assumes familiarity with the concepts of sales orders, sales quotations, and

purchase orders, how they are created, and how they interact with trade agreements. Conceptual knowledge of the Microsoft Dynamics AX 2012 agreement feature is also useful.

May 2012

www.microsoft.com/dynamics/ax

Lars David Jørgensen, Software Development Engineer Send suggestions and comments about this document to

[email protected]. Please include the title with your feedback.

http://www.microsoft.com/dynamics/ax

mailto:[email protected]

2 TRADE AGREEMENT EVALUATION (TAE) POLICIES IN MICROSOFT DYNAMICS AX 2012

Table of Contents

Trade agreement evaluation (TAE) policies overview ................................. 3

Scenarios that support TAE policies with Microsoft Dynamics AX ................ 3 Sources – What are they? ...................................................................................................... 3

Trade agreements .............................................................................................................. 3 Manual input ..................................................................................................................... 4 System sources ................................................................................................................. 4 Sales and purchase agreements .......................................................................................... 4

TAE policies – More details ..................................................................................................... 4 Dynamic policies ................................................................................................................ 5 Fixed policies .................................................................................................................... 5 Summary.......................................................................................................................... 6

Manual TAE policy applied to a document header or line record .................................................. 6 Example: Manually overwriting the unit price ........................................................................ 6

System TAE policy applied to a document header and line ......................................................... 7 Example: System policy originating from a sales quotation ..................................................... 7

Manual and system TAE policies applied to the same document header and line ........................... 8 Example: Manually overwriting system policies originating from a sales quotation ..................... 8

Architecture of TAE policies in Microsoft Dynamics AX .............................. 12 Some design highlights .........................................................................................................12 ER diagram .........................................................................................................................14 Class diagrams ....................................................................................................................15

Glossary of terms ...................................................................................... 17

Appendix ................................................................................................... 19 Sequence diagrams ..............................................................................................................19 Class diagrams ....................................................................................................................22 Showcase – Extending TAE policies ........................................................................................23 Installation and upgrade .......................................................................................................25 Performance considerations...................................................................................................25 Debugging hints ..................................................................................................................25

3

TRADE AGREEMENT EVALUATION (TAE) POLICIES IN MICROSOFT DYNAMICS AX 2012

Trade agreement evaluation (TAE) policies overview

Purchase order lines, sales quotation lines, and sales order lines all include fields (trade agreement result fields: see the “Glossary of terms” section) that can be:

Entered by trade agreements.

Entered by manual input.

Set from external sources, such as sales quotations, project quotations, purchase requisitions,

requests for quotation (RFQs), agreements, projects, Application Integration Framework (AIF), and Enterprise Portal for Microsoft Dynamics® AX (EP).

The lines also include the Net amount field, which can be either calculated based on trade agreements or entered from one of the external sources.

The TAE policies feature prevents Microsoft Dynamics AX from accidentally evaluating the trade

agreements and from overwriting fields that are populated by manual input or a system source (see the “Glossary of terms” section).

Note: The TAE policies feature is used only in the context of price and discount fields on sales quotations, sales orders, and purchase orders. It is related neither to the policy framework used for designing and enforcing business rules, nor to the framework that creates extensible data security, both of which are being introduced in Microsoft Dynamics AX 2012.

Also, the TAE policies feature is not implemented in intercompany scenarios.

Scenarios that support TAE policies with Microsoft Dynamics AX

This section describes some core concepts and some of the most common scenarios in which TAE policies are implemented within Microsoft Dynamics AX.

For sales orders, purchase orders, and sales quotations, two main steps are performed:

When a trade agreement result field is either populated from a system source or updated

manually, a TAE policy is created, and a reference to the TAE policy is added to the document.

Changing a trade agreement condition field (see the “Glossary of terms” section) triggers a recalculation of the trade agreement result fields. The user is prompted for permission to overwrite the field values entered in this step.

When a line amount field is overwritten manually, and changes to a trade agreement condition field trigger a recalculation of the trade agreement result fields, the user is prompted for permission to change the manually entered value.

New sets of customer and vendor parameters control whether the different types of field entries (manually entered or entered from different system sources) should be subject to TAE policies.

Sources – What are they?

The trade agreement result fields are populated from different sources, depending on the scenario. In

this context, we divide the sources into several groups, some of which can be guarded by policies.

Trade agreements

This is the legacy price discount setup that has been present in Microsoft Dynamics AX since version 1 and is considered the default source in the default scenario: the user creates or updates a document directly from the UI.

In this scenario, no TAE policies are applied.


Manual input

The user enters a value in one of the trade agreement result fields.

A manual-type TAE policy is applied to prevent the user input from being overwritten by the trade

agreements.

System sources

Documents are created or updated by means other than the default scenario—that is, they are imported via AIF or copied from other documents.

A system-type TAE policy is applied to prevent one or more trade agreement result fields from being overwritten by the trade agreements.

For the complete list of system sources, see the “Glossary of terms” section.

Sales and purchase agreements

The agreement feature that is replacing blanket orders in Microsoft Dynamics AX 2012 can be considered a source for prices and discounts, along with the legacy trade agreement feature.

Depending on the specific agreement configuration, a subset of the price and discount values that previously came from the trade agreement setup now comes from agreements.

The agreement feature serves as a source in two ways:

As long as a document is linked to an agreement, the agreement is considered a system source. To control the mix of agreements and trade agreements, a set of fixed TAE policies (see the “Glossary of terms” section) is implemented in the price discount policy feature. The purpose is to prevent price and discount values that originate from agreements from being overwritten by trade agreements. More details about the fixed TAE policies are provided later in this document.

When a document is unlinked from an agreement, prices and discounts that originate from the agreement can be preserved. In this scenario, the agreement is considered a system source, and

a policy is applied accordingly.

TAE policies – More details

As has been mentioned, TAE policies come in two “flavors.” One is dynamic, and includes the manual and system types, and the other is static and includes the fixed type.

5


Dynamic policies

A dynamic TAE policy is represented by a record in the PriceDiscChangePolicy table that is related to one or more records in the PriceDiscPolicyFields table.

Document header

DataAreaId

<....>Id

SystemEntryChangePolicy (O) (FK)

ManualEntryChangePolicy (O) (FK)

SystemEntrySource (O)

More....

Document line

DataAreaId

InventTransId

<....>Id (FK,AK1)

LineNum (AK1)




More....

PriceDiscChangePolicy

RecId

SearchKey (AK1)

PriceDiscPolicyFields

RecId

FieldId (AK1)

ChangePolicy (FK,AK1)

Depending on the source, the ID of the record is populated in either the ManualEntryChangepolicy field or the SystemlEntryChangepolicy field of the document. In the latter scenario, the

SystemEntrySource field is also populated to identify the type of system source. The following are some characteristics of dynamic policies:

The application is parameter-controlled.

The policies are created on the fly.

The policies are immutable, and they are reused.

One document can have both a manual policy and a system policy applied at the same time, but a specific field can be controlled by only one type of policy at a time. For more details about combined policies, see the “Manual and system TAE policies applied to the same document header and line” section.

More implementation details are provided later in this document.

Fixed policies

Policies of this type are hard-coded in the PriceDiscPolicyFixed class. They are sets of rules that are applied to documents, depending on document attributes. In Microsoft Dynamics AX 2012 RTM, fixed policies are used in two scenarios:

Document lines are attached to agreements. This scenario has two sets of rules:

For quantity-based agreements, the Price, Line discount, Line discount pct., and Price unit fields are controlled by fixed policies.

For volume-based agreements, the Line discount pct. field is controlled by a fixed policy.

On category-based document lines, the Price and Markup fields are controlled by fixed policies.


Summary

In summary, the TAE policies feature implements two sets of TAE policies:

The parameter-controlled dynamic type (manual and system policies) – These policies are

attached and detached on the fly, based on user actions and dialog boxes.

The hard-coded static type (fixed policies) – These policies control how agreements and trade agreements interact.

Manual TAE policy applied to a document header or line record

A manual policy is applied to a document when the user overwrites one or more of the trade agreement result fields.

Example: Manually overwriting the unit price

For this example, a document line has a stocked product, a quantity, and a unit price. No sales agreement or purchase agreement is attached.

The unit price is then changed, and the flow illustrated in Figure 1 is executed. In this case, a policy

indicating that the unit price was changed is applied to the document line.

New record is created in the PriceDiscChangePolicy table.

Does a reuseable policy

exist?

Yes

No

The document is updated with the

policy ID.

New record is created in the PriceDiscChangePolicyFields table.

The policy is selected in the PriceDiscChangePolicy table.

Fig.1: Manually overwrite a trade agreement result field - simplified.

Next, the quantity is changed, triggering a recalculation of the trade agreement fields. The flow

illustrated in Figure 2 is executed, and three outcomes are possible:

OK is clicked:

1. The unit price is recalculated in accordance with the trade agreement setup.

2. The TAE policy is removed from the record.

The Unit price check box is cleared, and OK is clicked:

1. The manually entered unit price is kept.

2. The TAE policy remains on the record.

Cancel is clicked:

1. Update of the record is canceled, and the quantity change is rolled back.

2. The TAE policy remains on the record.

7


Even though the appearance of the dialog box differs in different scenarios, the flow and outcomes are similar.

The price discount dialog is launched.

Is a policy applied to the

document?

Yes

No

The unit price is updated.

The map field ID corresponding to the unit price is removed from the policy.

The user leaves the check mark.

Yes

No

Update of the unit price is blocked.

Is the map field ID of the unit price in the

policy?No Yes

Fig.2: Recalculation of the trade agreement result fields - simplified.

System TAE policy applied to a document header and line

A system policy is applied to a document when it is created from sources other than manual input by a user.

Example: System policy originating from a sales quotation

For this example, a sales quotation has one or more lines. The line items are all stocked products, and

no sales agreements are involved.


The confirmation process is started to create a sales order based on the sales quotation. As part of that process, the price discount policy functionality is called to apply system policies to the new sales order, as illustrated in Figure 3.

Manual and system TAE policies applied to the same document header and line

As has been mentioned, a document can be controlled or protected by both a manual policy and a system policy at the same time. However, a particular field can be subject to control by only one policy at a time. Nevertheless, the type of policy that controls a particular field can shift from manual to system, and from system to manual.

Example: Manually overwriting system policies originating from a sales quotation

For this example, a sales order is created based on a sales quotation, as described in the previous

example. Both the header and the line records have system policies applied that indicate the origin.

The source type and

docum ent header

policy is determ ined

N ew record created in

PriceD iscChangePolicy

D oes a

reuseable po licy

exists?

Yes

N o

The docum ent is

updated w ith the

po licy ID

N ew record created in

PriceD iscChangePolicyFie lds

The policy is se lected in

PriceD iscChangePolicy

The source type and

docum ent line

policy is determ ined

Creation of the

docum ent header record

A re

docum ent line

records pending

creation?

Yes:

Creation of the

docum ent line record(s)

A t the latest after first docum ent line

is processed, th is is true for rem ain ing lines.

Fig.3: System policy orig inating from a sales quotation

N o

9


Triggering a recalculation of the trade agreement opens a dialog box, and the steps that are executed are similar to the steps in Figure 2.

First, we describe the appearance of the dialog box when only the system policies are applied.

On the document header, the calculation of multiline discounts is started, and the following dialog box

appears.

This dialog box indicates that multiline discounts come from the sales quotation.

As was mentioned in the “Example: Manually overwriting the unit price” section, we can accept or cancel the dialog box. For now, assume that Cancel is clicked.

Still on the document header, the calculation of the total discount is started, and the following dialog

box appears.

This dialog box indicates that the total discount comes from the sales quotation.

Again, assume that Cancel is clicked.


Now one of the trade condition fields on the document line is changed, and the following dialog box appears.

This dialog box indicates that a system policy of type SalesQuotation that includes all five trade agreement result fields for the document line exists on the document line.

Assume that Cancel is clicked. In this case, the Discount and Discount percent fields are

overwritten.

For each overwritten field, the flow illustrated in Figure 4 is executed.

11


Is a system

policy

app lied to the

docum ent?

A new record is created in the

PriceD iscChangePolicy tab le.

D oes a

reuseable po licy

exists?

Yes N o

O ne or m ore new records are created

in the PriceD iscChangePolicyFie lds tab le.

The policy is se lected in the

PriceD iscChangePolicy tab le

N o

Yes

Is the fie ld ID

part of the

existing system

policy?

N o Yes

Is a m anual

po licy a lready

applied to the

docum ent?

N o

Yes

A new system policy

w ithout the fie ld ID should

rep lace the existing one.

A new m anual po licy w ith

on ly the new fie ld ID

should should be applied.

N o

Is the fie ld ID

sub ject to a

fixed po licy or

a lready included

in a m anual

po licy app lied to

the docum ent?

Yes

A new m anual po licy

m erging the new fie ld ID

and the existing po licy,

should be applied.

The docum ent fie ld

”M anualEntryChangePolicy”

is updated w itht the po licy ID

Fig 4: Manually overw rite a trade agreem ent result fie ld .

(More detailed )

The docum ent fie ld

”System EntryChangePolicy”

is updated w itht the po licy ID and

the ”System EntrySource” fie ld is

updated w ith the system source

in question.

A pplying a

m anual or

system policy?

System M anual


Once again, one of the trade condition fields on the document line is changed, and the following dialog box appears.

Now the dialog box indicates that both a manual policy and a system policy are applied to the document line.

Manual changes to the price discount result fields for the document header follow the same pattern: fields are “moved” from the system policies to the manual policies.

Architecture of TAE policies in Microsoft Dynamics AX

Some design highlights

The following information supports the diagrams in this section:

The implementation can be seen as divided into two major parts: the core functionality that is

common to all documents and the document-specific integration.

Whereas the integration part is tailored to the specific document scenarios, the core part consists of three subsystems of functionality and several common supporting elements.

The subsystems are as follows:

Make policy – Enables a given trade agreement result field to be included in a price discount

policy, or if no price discount policy exists, enables a new one to be created.

Prompt user – Enables a dialog box to be opened, providing the user with field-level

information about applied policies and letting the user decide whether each field should continue to be subject to policy control.

Check policy – For a given table, record, or field, answers the following question: “Is this field blocked by a policy?”

The subsystems are marked with different colors in the core functionality diagram in the “Class diagrams” section.

13


A TAE policy is a list of table field IDs.

In the database, a TAE policy is stored as one record in the PriceDiscChangePolicy table, and each table field ID belonging to a TAE policy is stored as a separate record in the PriceDiscPolicyFields table.

Both tables, PriceDiscChangePolicy and PriceDiscPolicyFields, are immutable: after records have been created, they are never updated or deleted.

When records are created in the PriceDiscPolicyFields table, the field IDs representing the policy are converted to the corresponding field IDs from the PriceDiscResultFields table map.

When policy field IDs are retrieved from the PriceDiscPolicyFields table, they are converted back to the appropriate table field IDs.


ER diagram

SalesTable

DataAreaId

SalesId




More....

SalesLine

DataAreaId

InventTransId

LineNum (AK1)

SalesId (FK,AK1)




More....

SalesQuotationTable

DataAreaId

QuotationId




More....

SalesQuotationLine

DataAreaId

InventTransId

LineNum (AK1)

QuotationId (FK,AK1)




More....

PurchTable

DataAreaId

PurchId




More....

PurchLine

DataAreaId

InventTransId

PurchId (FK,AK1)

LineNum (AK1)




More....

PriceDiscChangePolicy

RecId

SearchKey (AK1)

PriceDiscPolicyFields

RecId

FieldId (AK1)

ChangePolicy (FK,AK1)

PriceDiscPurchPolicyParameters

Id

PriceDiscPurchasePromptSystemSource (AK1)

AIF

PurchaseAgreement

CopyFromPurchaseOrder

Project

PurchaseReq

RequestForQuote

ManualEntry

ProductConfig

PriceDiscPurchasePromptSystemSource

AIF

SalesAgreement

CopyFromSalesOrder

CopyfromSalesQuotation

Project

ProjetQuotation

SalesQuotation

ManualEntry

ProductConfig

PriecDiscSalesPromptSystemSource

PriceDiscSalesPolicyParameters

Id

PriecDiscSalesPromptSystemSource (AK1)

None

CopyFromSalesOrder

CopyFromSalesQuotation

Project

SalesQuotation

CopyFromPurchaseOrder

RequestForQuote

PurchaseReq

ManualEntry

Agreement

Aif

ProductConfig

PriceDiscSystemSource

3 new enum types

New table: PriceDiscChangePolicy

15


Class diagrams

As was mentioned in the “Some design highlights” section, the core part of the implementation consists of three subsystems and several supporting elements. The following diagram is color-coded to group the elements by subsystem, and the integration with the document-specific integration is also shown.

«Class»PriceDiscPolicyCheckPolicy

«Class»PriceDiscPolicyDialog

«Class»PriceDiscPolicyFieldMappingCache

«Class»PriceDiscPolicyFindOrCreate

«Class»PriceDiscPolicyFixed

«Class»PriceDiscPolicyMakePolicy

«table»PriceDiscPurchPolicyParameters

«table»PriceDiscSalesPolicyParameters

«table»PriceDiscChangePoliciesTmp

«table»PriceDiscChangePolicy

«table»PriceDiscPolicyFields

«TableMap»PriceDiscResultFields

«Class»Runbase«table»

CustParameters

«table»SRMParameters

«subsystem»Document specific integration

Class diagram: Core functionality

Make policy

Prompt user

Check policy

Subsystem main elements

As was mentioned in the “Some design highlights” section, the document-specific integration part of the implementation is tailored to each document. The following diagram shows the purchase order


part. Diagrams covering sales orders and sales quotations are located in the appendix of this document.

+setPriceDiscChangePolicy()+setPriceDiscChangePolicyMultiLine()+modifiedField()-unlinkAgreement()

«Table»PurchTable

+setPriceDiscChangePolicy()+runPriceDiscPolicyDialog() : bool+calcLineAmountForcedInteraction() : long+unLinkAgreementLine()+modifiedField()

«Table»PurchLine

«subsystem»Core functionallity

+updateFinalDisc() : bool+updateMultiLineDisc()

«TableMap»PriceDiscHeading

Class diagram: Document specific integration - purchase orders.

+calcLineAmountForced() : long+setPriceAgreement()+setPriceDiscMarkup()+setPriceDiscPriceUnit()

«TableMap»SalesPurchLine

+corReceive() : bool

«Class»EPPurchCOR

#updatePurchaseLineDetails()

«Class»PCSourceDocumentLineUtility

+createPurchTable()+createPurchLine()

«Class»PurchAutoCreate_PurchReq

+createPurchTable()+createPurchLine()

«Class»PurchAutoCreate_RFQ

+endUpdate()+createPurchLine()

«Class»PurchAutoCreate_SalesProjectItemReq

#setPriceDiscHeaderChangePolicy()#setPriceDiscLineChangePolicy()

«Class»PurchCopying

+validateField() : bool+validateModifyInventDim() : bool+purchQtyAllowEdit() : bool+setPriceDiscChangePolicyMultiLine()

«Class»PurchLineType

17


Glossary of terms

Term Definition

Trade agreements The legacy Microsoft Dynamics AX price and discount feature used to set up price and discount rules for specific customers and products, groups of customers and products, or all customers and products.

Agreements The new Microsoft Dynamics AX 2012 feature that replaces the legacy blanket order feature.

Trade agreement condition field A field for which the value can be used as a requirement for a trade agreement rule before the trade agreement can be applied.

The trade agreement conditions are as follows:

Item number

Configuration

Size

Color

Site

Warehouse

Batch number

Serial number

Quantity

Unit

Trade agreement result field A field that can be directly set by trade agreements.

Location Field

Document header > Price/Discount tab t Total discount %

Document line details > Price/Discount tab Unit price

Discount

Disc. pct.

Multiline discount

Multiline discount %

Markup

These fields can all be found in the Purchase order details, Sales quotation details, and Sales order details forms.


Term Definition

System source When sales orders, sales quotations, and purchase orders are not created from the details forms, their origination is considered a system source.

System source Description

PurchaseAgreement A purchase order line is attached to a purchase agreement.

CopyFromPurchaseOrder A purchase order line is copied from another purchase order line.

PurchaseReq A purchase order is created based on a purchase requisition.

RequestForQuote A purchase order is created based on a request for quotation.

SalesAgreement A sales order line is attached to a sales agreement.

CopyFromSalesOrder A sales order line is copied from another sales order line.

CopyfromSalesQuotation A sales order line is copied from a sales quotation line.

ProjectQuotation A sales order is created based on a project quotation.

SalesQuotation A sales order is created based on a sales quotation.

AIF A document is created by importing an XML file.

Project A sales order is created based on a project.

Product configurator A sales price or purchase price is generated by the product configurator.

Manual-type TAE policy A TAE policy that is created based on a manual update of a trade agreement result field.

Example: On a sales line, the user has overwritten the default sales price.

System-type TAE policy A TAE policy that is created based on entries from external sources.

Example: A sales line was created by a sales quotation, and the sales price was “inherited” from a sales quotation line.

For Microsoft Dynamics AX 2012 RTM, all system policy types for the document header are the same, whereas system policy types for the document lines come in different “flavors.” The latter types are coded in Classes\PriceDiscPolicyFindOrCreate\systemLinePolicyFields.

Fixed-type TAE policy A hard-coded TAE policy that is used to control the mix of prices and discounts originating from agreements and trade agreements.

Document In this context, a sales quotation, sales order, or purchase order.

Document header A record in the SalesQuotationTable, SalesTable, or PurchTable table.

Document line A record in the SalesQuotationLine, SalesLine, or PurchLine table.

Core functionality The parts of the implementation that are common to all documents. For more details, see the “Some design highlights” section.

Document-specific integration Integration points in the legacy code. For more details, see the “Some design highlights” section.

19


Appendix

Sequence diagrams

«Table»Document


«Class»PriceDiscPolicyMakePolicy

createPriceDiscChangePolicy(...)

makePolicy(....)


run()

update()

Creation and application of a policy – simplified

Creation of a manual or system type policy is triggered.

«subsystem»Find or create policy

findOrCreateChangePolicy(...)

changePolicyId

update()


Launch of the price discount dialog - simplified.

«Table»Document


validateField(...)

runPriceDiscPolicyDialog(...)

runPriceDiscPolicyDialog(...)

«Class»priceDiscPolicyDialog (extends RunBase)

runPolicyDialog()

prompt()

getFromDialog()

updatePolicy(...)


changePolicyId «subsystem»Find or create policy

21



«Table»PriceDiscChangePolicy

findSearchKey(...)

create(...)

insert()

«Table»PriceDiscPolicyFields

insert()

If no existing policy was found in the previous call, a new one is created by calling create(..).

Subsystem: Find or create policy - simplified


changePolicyId


Class diagrams

+setPriceDiscChangePolicy()+setPriceDiscChangePolicyMultiLine()+modifiedField()-unlinkAgreement()

«table»SalesTable

+setPriceDiscChangePolicy()+runPriceDiscPolicyDialog() : bool+calcLineAmountForcedInteraction() : long+unLinkAgreementLine()+modifiedField()

«table»SalesLine






#updateSalesLineDetails()



«Class»SalesCopying

#postSalesLineUpdate()+processingRecord()

«Class»AxdSalesOrder

+createSalesLine()+createSalesTable()

«Class»SalesAutoCreate_ReleaseOrder

+insert()

SalesLineType_Project

Class diagram: Document specific integration - sales order.

+validateField() : bool+validateModifyInventDim() : bool+salesQtyAllowEdit() : bool+setPriceDiscChangePolicyMultiLine()

«Class»SalesLineType

23


+setPriceDiscChangePolicy()+setPriceDiscChangePolicyMultiLine()+modifiedField()

«table»SalesQuotationTable

+setPriceDiscChangePolicy()+runPriceDiscPolicyDialog() : bool+modifiedField()

«table»SalesQuotationLine






#updateSalesQuotationLineDetails()


Class diagram: Document specific integration - sales quotation.

+processingRecord()

«Class»AxdSalesQuotation


«Class»SalesQuotationCopying

+validateField() : bool+validateModifyInventDim() : bool+setPriceDiscChangePolicyMultiLine()

«Class»SalesQuotationLineType

Showcase – Extending TAE policies

Adding another system source to be policy-controlled requires only a few changes. The following walkthrough shows how the product configurator was added as another system source.

First, the new source should be named and parameterized by adding new outcomes to the three policy

enumerations.

DataDictionary/Base Enums/PriceDiscPurchasePromptSystemSource

#ProductConfig

PROPERTIES

Name #ProductConfig

Label #@SYS344213

EnumValue #7

ENDPROPERTIES


DataDictionary/Base Enums/PriceDiscSalesPromptSystemSource

#ProductConfig

PROPERTIES

Name #ProductConfig

Label #@SYS344213

EnumValue #8

ENDPROPERTIES

DataDictionary/Base Enums/PriceDiscSystemSource

#ProductConfig

PROPERTIES

Name #ProductConfig

Label #@SYS344213

EnumValue #11

ENDPROPERTIES

Next, the policy classes should implement the required parameter checks and the definition of the fields that are controlled for the new source. For the product configurator implementation in this example, only the price should be controlled, because discounts are coming from the trade agreements.

Classes/PriceDiscFindORCreate/systemLinePolicyFields

.....

case PriceDiscSystemSource::ProductConfig :

ret += [fieldNum(PriceDiscResultFields, Price)];

break;

.....

Classes/PriceDiscPolicyMakePolicy checkPolicyParmSetup

Starting at line 52:

.....

case PriceDiscSystemSource::ProductConfig

ret =

PriceDiscSalesPolicyParameters::isSourceEnabled(PriceDiscSalesPromptSystemSource::ProductConfig);

break;

.....

Starting at line 94:

.....

case PriceDiscSystemSource::ProductConfig :

ret =

PriceDiscPurchPolicyParameters::isSourceEnabled(PriceDiscPurchasePromptSystemSource::ProductConfi

g);

break;

.....

Finally, a call to the <document>.setPriceDiscChangePolicy(…) method should be made at the point where the new source creates or updates the document. For the product configurator, this happens in the PCSourceDocumentLineUtility class when the price is transferred.

Classes/ PCSourceDocumentLineUtility /updateSalesLineDetails

.....

_salesLine.setPriceDiscChangePolicy(PriceDiscSystemSource::ProductConfig);

.....

25


Classes/ PCSourceDocumentLineUtility /updatePurchaseLineDetails

.....

_salesQuotationLine.setPriceDiscChangePolicy(PriceDiscSystemSource::ProductConfig);

.....

Classes/ PCSourceDocumentLineUtility /updateSalesQuotationLineDetails

.....

_purchaseLine.setPriceDiscChangePolicy(PriceDiscSystemSource::ProductConfig);

.....

Installation and upgrade

By default, all TAE policy parameters are enabled.

For new installations, this is done at the same time that the default vendor and customer parameters

are generated.

In upgrade scenarios, it is done as part of the upgrade, in the following locations:

\Classes\ReleaseUpdateDB60_Cust\initiatePriceDiscPolicyParameter

\Classes\ReleaseUpdateDB60_Vend\initPriceDiscPolicyParameter

Performance considerations

Obviously, the TAE policy feature has the potential to affect performance, and several design decisions

were made with that in mind:

The affected document tables are denormalized by adding the policy columns directly to the document tables.

With regard to the PriceDiscChangePolicy and PriceDiscPolicyFields tables:

Caching of the entire table is enabled.

The tables are immutable. After records are created, they are never updated or deleted, because they are reused across all documents and legal entities.

The number of possible records is finite and is kept to a minimum by storing the field IDs of the PriceDiscResultFields table map instead of the document table field IDs.

The mapping of the document field IDs and the PriceDiscResultFields field IDs is globally cached in the PriceDiscPolicyFieldMappingCache class.

Debugging hints

As was mentioned in the “Some design highlights” section, the implementation is divided into two major logical parts: the new core elements and the document-specific integration points.

The document-specific part is detailed in the “Class diagrams” section, which includes all new and

changed methods.

As was also mentioned in the “Some design highlights” section, the core element part consists of three subsystems, and debugging hints for each are provided here:

The make policy subsystem creates policies and applies them to documents.

Placing a break point in the PriceDiscResultFields.createPriceDiscChangePolicy() table map method is a good starting point for debugging sessions, because all documents call that method.


The prompt user subsystem handles the user dialog box.

Placing a break point in the PriceDiscResultFields.runPriceDiscPolicyDialog() table map method is once again a good starting point for debugging sessions, because all documents call that method.

The get policy subsystem determines whether a specific field is blocked.

Debug by placing a break point in the \Classes\PriceDiscPolicyCheckPolicy\mustUpdateField area, because starting from here, the debugger will step through both the dynamic and fixed policies.

27


This document is provided “as-is.” Information and views expressed in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of using it. Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred. This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. © 2012 Microsoft Corporation. All rights reserved.

Microsoft Dynamics is a line of integrated, adaptable business management solutions that enables you and your people to make business decisions with greater confidence. Microsoft Dynamics works like and with familiar Microsoft software, automating and streamlining financial, customer relationship and supply chain processes in a way that helps you drive business success.

U.S. and Canada Toll Free 1-888-477-7989

Worldwide +1-701-281-6500

www.microsoft.com/dynamics

http://www.microsoft.com/dynamics