Dated per batch project costs from Dynamics AX 2009 using SSRS

Hi Experts,

I have written an SSRS report against an AX 2009 database to provide project sales revenue (accrued or invoiced) and costs, per project, per month, to keep an eye on project margins. The data comes primarily from PROJTRANSPOSTING, which suits well. It is important to note that adjustments to costs belong in the month of the adjustment, not the month of the item transaction being adjusted.

I have now been asked to provide a version of this report that drops down to batch level, where revenue can be allocated pro-rata based on batch quantity, but costs need to be those attributed specifically to the batch. The problem I'm finding is that, while PROJTRANSPOSTING has the costs and adjustments date-stamped, INVENTTRANS has (via INVENTDIM) the relevant batch / qty information but a consolidated set of costs over time for the related INVENTTRANSID / PROJADJUSTREFID.

I thought INVENTSETTLEMENT might be the solution, but have found discrepancies between dates on PROJTRANSPOSTING and INVENTSETTLEMENT, and no direct or indirect, specific relation that isn't many-to-many.

Can anyone point me in the direction of some nice little table that has just what I need, or is able to enlighten me on the appropriate relationship?

Thanks for reading,

Mark
SeeHearMarkAsked:
Who is Participating?
 
SeeHearMarkConnect With a Mentor Author Commented:
OK - I think I have a solution, based on empirical evidence rather than hard facts, so it might only work due to how we are using AX!

Essentially, I use aggregated PROJTRANSPOSTING over the LEDGERTRANSDATE / INVENTTRANSID / PROJADJUSTREF where 'an original transaction', which seems to be LEDGERPOSTINGTYPE <= 50 or =52(???), outer joined to INVENTTRANS, where I use COSTAMOUNTPOSTED for each batch, referenced via INVENTDIM. This assumes that all the rows on PROJTRANSPOSTING for an INVENTTRANSID / PROJADJUSTREF pair will have the same LEDGERTRANSDATE, which they seem to do, and I'm not sure about the LEDGERTRANSTYPE split.

Then, I union this with something very similar for the other range of LEDGERTRANSTYPE (=51 or >= 53), outer joined to INVENTSETTLEMENT on VOUCHERID / INVENTTRANSID to pick up COSTAMOUNTADJUSTMENT, getting the batch again from INVENTTRANS > INVENTDIM using the TRANSRECID = RECID relation.

This seems to work for me, until someone does something in AX they haven't done so far, and breaks it. So the question is now, can anyone tell me what might break it - where any holes are in my assumptions - so I can be preapred?

Cheers,

Mark
0
 
SeeHearMarkAuthor Commented:
Looks like not, but I'll leave my solution on here in case it's useful to others, rather than deleting the question.
0
All Courses

From novice to tech pro — start learning today.