Hooking into the account code priority of PriceDiscAgreements

(0) Share

Report

Posted on by richierich79

300

I have an external application where I am reporting customer prices from Dynamics Ax 2012 R2

I know that if a customer has multiple agreements but with different account codes then the order of priority is TABLE, GROUP, ALL. There are a couple of things I was wondering...

1. To pick the right price do I ...

a. Just need to compare the item relation and the account code, and take the highest priority.

b. Or do I need to look for agreements where all columns are identical except for the account code.

2. I am aware I am duplicating functionality in an external .net application. Is there anyway to hook into Dynamics Ax functionality for this and pull a results set so I'm not developing and maintaining duplicate functionality.

Many thanks in advance for all your feedback.

*This post is locked for comments

All responses (13)

Answers (0)

Suggested answer

nmaenpaa 101,156 on at

Like (1)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

In D365FO you can't access the database directly. Only the D365FO application can access it, so your integrations will have to communicate with it.

A solution that works in AX2012 and D365FO would be to develop a custom service. Your logic should be implemented in x++ and you expose an endpoint that can be used to invoke it from external systems.

[View:https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/data-entities/custom-services]

In D365FO you can also choose to export data to external Azure SQL database (where you have full control of the db) but that is based on data entities, not tables, so your schema would be different than in the AX2012 database's price tables.

[View:https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/analytics/export-entities-to-your-own-database]
richierich79 300 on at

Like (0)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

"probably have less issues that code you would craft,"....how dare you! lol

All good points. I am going to have to support D365 and have heard the MS will lock down the DB in production, but was unclear as to whether they would allow custom deployments at clients request through support tickets.

I understand there are many ways to integrate with D365, given what I am trying to do with price agreements, would you mind giving me your opinion on what your preferred method would be in my situation?
Mea_ 60,278 on at

Like (2)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

You should avoid direct access to AX DB.

If this service exists in R2 then it would be there in R3 as well. AIF is depreciated in D365, so it is not available there, however, you cannot have direct access to DB as well, so your approach won't work anyway.

You can send multiple calls to AIF service in parallel, so performance is usually not an issue if you app is capable to do them.

Would it give you info required? We don't know what is required, so test it.

Why I think that it is the best option ? Because it is a standard service created and tested by MS that would probably have less issues that code you would craft, it is easier to support than handcrafted solution as well and you don't need to invent your own bicycle.
richierich79 300 on at

Like (0)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

Hi ievgen

Thanks for your response, and it may very well be closest to answering the original question and in the long term I may end up using it for extra confidence on accuracy.

My application updates prices and I already have well developed stored procedures to manage pricediscagreements and so should only need tweeking to get clients prices. For just retrieving prices I originally hadn't used to AIF web service as I needed more complicated relationships in the data so went directly to the DB. I do use the AIF web service to update the prices though.

My concerns over using the service to report customer prices would be...

Performance

Whether it will give me all the data I require.

How the web services differ between different versions, or if they are even present on other versions (This is developed for 2012R2 but I would want it useable for other versions)

In your opinion are these concerns valid or not?

Thanks for your feedback.
Suggested answer

Rustem Galiamov 8,072 on at

Like (1)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

The [dbo].[CustTable].[PriceGroup] field contain information about price group.
Mea_ 60,278 on at

Like (1)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

Why do you need to know this ? There is out of the box service that can return you list of prices. This serves could be consumed from any .Net application.
richierich79 300 on at

Like (0)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

Rustem

Many thanks for this, it has confirmed my understanding on using account code.

The only issue I have is where you say "for customers with this GroupId"

Where is the relationship between the customer and the [dbo].[PRICEDISCGROUP] table?

I know that a customer can be part of a customer group (GroupId in dbo].[CUSTTABLE]) but it's my understanding dbo.CUSTGROUP is completely separate to [dbo].[PRICEDISCGROUP] and no relationship exists?

If you could help clarify I would be most grateful
Suggested answer

Rustem Galiamov 8,072 on at

Like (0)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

This is price agreement journal's lines in AX:

and this is the same from SQL DB

If AccountCode's value is Table then AccountRelation must be filled by customer account code.

If AccountCode's value is Group then AccountRelation must be filled by GroupId from PriceDiscGroup table and the price will be for customers with this GroupId:

And if AccountCode's value is All then AccountRelation fields must be empty.

Search priority will be:

1. Table

2. Group

3. All
richierich79 300 on at

Like (0)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

Thanks Yohann

I am only dealing with Price agreements. My understanding is...

Find Next ticked = Will get the best price independent of the account code

Find Next not ticked = Will get a price in order of the following priority of existing agreements for that item- TABLE, GROUP, then ALL

Do you think this understanding is accurate?
richierich79 300 on at

Like (0)

Report

RE: Hooking into the account code priority of PriceDiscAgreements

Hi Rustem

Thank you for your response. Yes I am getting the price from the DB correctly.

I think my first knowledge gap is to do with the "customer group code". I was under the impression that when account code was Group it mean that the AccountRelation linked to the GroupId in dbo.PriceDiscGroupTable. Is this not the case?

I am trying to create a report of price changes for products to customers. Is there any relation between a customer and a discount group or are discount groups just for items?