Tuesday 24 October 2006

Dynamics Ax 4 Bug in Tax Calculation in Ledger Intercompany Accounting

Using std Axapta 4.0 with accounts not done incl. Tax.

That is in Ledger Parameters / Tab Tax untick the include VAT and in the Ledger Journals do the same either at header or setup levels.

Then create an intercompany link between two companies, with the appropriate setup.

Add a line that posts an amount with a TaxGroup and a TaxItemGroup that gives a VAT rate.

The system when checking the journal will find no error, and when you try to post will report that the document does not balance as it doubles the VAT amount.

The culcript is a new alegorithm introduced in V4 in the TaxVoucherService Class.

In order to remove the issue I have added the following in the Update now method of LedgerJournalTrans class:

Original

if (taxVoucherService)
{

if (taxVoucherService.ledgerFallbackAccount() == _ledgerJournalTrans.AccountNum)
{
taxAmount = taxVoucherService.taxAmountToPost(_ledgerJournalTrans.LineNum);
}
}

Changed

if (taxVoucherService.ledgerFallbackAccount() == _ledgerJournalTrans.AccountNum && _Posting != LedgerPostingType::InterCompany )
{ // Changed on 20 Jul 2006 at 17:44:45 by SJO

taxAmount = taxVoucherService.taxAmountToPost(_ledgerJournalTrans.LineNum);
// Changed on 20 Jul 2006 at 17:44:45 by SJO
}
}

As the VAT amount has already been added in the intercompanyupdate process earlier.


This bug is reported and will be fixed in Version 4.1 due out end 2007.

/Sven

Sunday 22 October 2006

Dynamics AX V4 Bug Tax allocation in journals

Precondition, change V4 setup in demo database to work with not including Tax amounts.

That is in GL Parameters Tab Tax remove including tax tick and do the same for the journal.

When you create a Daily journal in the GL with only ledger accounts, and set 2 or more lines with VAT with one setoff line the verification process finds no errors but posting tells you that you have a difference.

The problem is in the changed (from V3) TaxVoucherService it now stores the VAT in a MAP using the linenumber of the Journal as a link.

Now if you have f'ex

Line 1 account 1000 Amt 100 Tax 25
Line 2 account 1010 Amt 100 Tax 25
Line 3 Account 2000 Amt -200

The system should generate a Tax surcharge on line 3 of +50thus making the posting 250 on that account.

However in the Map Calculated by the TaxVoucherService class the amount for line 3 is empty.

I have as a work around introduced a new Method in the TaxVoucherService class which returns the sum of the TaxAmountToPostMap

// Changed on 20 Jul 2006 at 17:44:45 by SJO
AmountCur Sev_TaxAmountTotal()
{
LineNum _LineNum;
AmountCur total;
MapIterator iterator;
;
iterator = new MapIterator(taxAmountToPostMap);
while (iterator.more())
{
total = total + iterator.value();
iterator.next();
}
return total;
}

And in the UpdateNow method of LedgerJournalTransUpdate I now call my new Method instead of the standard code

if (taxVoucherService)
{
if (taxVoucherService.ledgerFallbackAccount() == _ledgerJournalTrans.AccountNum)
{
// Changed on 20 Jul 2006 at 17:44:45 by SJO
// This should be all the tax not the tax on the line
taxAmount = TaxVoucherService.Sev_TaxAmountTotal();
// taxAmount = taxVoucherService.taxAmountToPost(_ledgerJournalTrans.LineNum); // Changed on 20 Jul 2006 at 17:44:45 by SJO
}
}

This seems to resolve the issue for my particular case however I am not dealing with the case of several different fallback accounts / Offset accounts.

Basically the function no longer works as in V3 due to the changes made and my change may not be compatible with V3 functionality however it at least correctly posts the amounts.

The issue should be resolved in Dynamics Ax 4.01 or SP1 depending upon the title given to this release which is due out soon.

/Sven

Friday 20 October 2006

Intercompany payments BUG Dynamics Ax V4 Loc Build

In AX V4 August release the following intercompany related bug has been found.

It is possible to create intercompany Links between companies and Axapta will in those instances in V4 maintain information about the established invoices and will try to settle on both sides simoultaneously.

This works well, except in the case where you decide to use an intercompany account but not to do the full interaction, that is you untick the intercompany box. The result is you have an invoice on an account with an intercompany setup with no corresponding entry on the related account in the other company.

This could be because you want to register a fee or other invoice or it could be that the account was not intercompany but now is as you have changed your setup.

Ax will forcibly try to settle a transaction on the other set of accounts inspite of it knowing it is not there.

To correct this BUG two small changes are needed in two methods of the LedgerJournalCheckPost Class.

The Methods IntercompanyPaymentExist and IntercompanyTransferToCustPayment need to have a new variable added in the declaration in order that we can query it later in a select.

// Intercompany only if the invoice was booked with intercompany link active
VendInvoiceJour VendInvoiceJour;
// Information is stored in the invoice And the Select statement
select firstonly forceplaceholders vendSettlement
where vendSettlement.OffsetTransVoucher == ledgerJournalTrans.Voucher
join vendTrans where vendTrans.RecId == vendSettlement.TransRecId
&& vendTrans.AccountNum == vendSettlement.AccountNum
&& vendTrans.Invoice

Should have added to it the following

select firstonly forceplaceholders vendSettlement
where vendSettlement.OffsetTransVoucher == ledgerJournalTrans.Voucher
join vendTrans
where vendTrans.RecId == vendSettlement.TransRecId
&& vendTrans.AccountNum == vendSettlement.AccountNum
&& vendTrans.Invoice
// Added search
join VendInvoiceJour
where VendInvoiceJour.InvoiceId == VendTrans.Invoice
&& VendInvoiceJour.InvoiceDate == VendTrans.TransDate
&& VendInvoiceJour.InvoiceAccount == VendTrans.AccountNum;
if (vendTrans.Invoice && VendInvoiceJour.InterCompanyCompanyId)
// Added check to avoid issue
{The check on the IntercompanyId field ensures that the transaction was done using IC.
//

Hope this may help someone somewhere :-)

/Sven Jochimsen

Sunday 15 October 2006

Dynamics Ax 4.0 was launched in July 06'

The good the bad and the ugly surrounding the release of this long awaited upgrade to V3.
V3 was launched in September 2002 which means that it took Microsoft almost 4 years to launch a new version after V3.

Version 2.5 was launched in Dec 2000 and 2.1 in 1999 and 1.0 in April 1998.
It seems the product launch cycle is getting longer rather than shorter.
One could ask the question what happened.

If one compares with the other product Navision that was acquired at the same time in July 2002.
The Navision product group brought out 3.0, 3.1, 3.5, 3.7, and 4.0 during the same time frame each of which added functionality to the product.

It seems the Ax group was sitting on it's laurels, and inovation was only forthcoming from the partners through their many add-ons that functionally completed the product or vertically adapted the product.

I do not have any official story behind the above, however I have noted that at many times during the above period of time, we heard as dealers that there would be a new version and product scope was being discussed etc etc but at no time until Jan Feb 2005 was there evidence of any real project with concrete plans for any future versions.

What were the Ax developpers doing during the interim time frame ?

I believe they were otherwise engaged, all we can do is ask.

However the result is that Axapta as a product which when it came out was revolutionary and ahead of it's time has lost out.

Hopefully the MS Dynamics product group with Satya now firmly in charge will get down to the nitty gritty of providing us with a series of new versions at a more consistent and advanced pace.

/Sven Jochimsen

Sunday 1 October 2006

Dynamics Ax First Impressions

Generally I like the product as such, which should come as no surprise to those who know me, I have been working with it pretty much since it was made and before that with it's predecessor etc etc.

Anyhow notes :

Like:

AOS robustness

In V3 the AOS could at times seem a bit fragile and if you stopped a server you were certain that all the users were thrown out / off the system. With V4 some new technology has been added that allows in some instances sessions to be recovered by the other AOS's this is impressive when you realise how complicated such an operation can be, its the computer equivalent of a juggler replacing another juggler in the middle of a trick with all the balls in the air !

New dimension setup

Finally we are able to make hierarchies and to limit what and where they are used etc etc.
New financial statement generator

In the product that preceeded Ax there was a report generator enabling the users to create financial statements with accounts and dimensions as lines and the ammounts against them. Finally we can do so with less effort than before. In V3 you had to name each dimension it was basically tedious and almost impossible to do with the V3 financial statements.

Dislikes

New Menu

I find almost comical the pains that the UX team are going to to reduce usability, I am sorry it is not easy to read and furthermore I would even state that the old grid menu of XAL was from a UX point of view easier and more intuitive. As was the old tree menu that you can still by exporting and importing under another name activate as your main menu. The main problem is that the new menu eats screen space. Just try opening any of the larger screens (Inventory, Sales Orders, Purchase Orders) on a 1024*768 monitor it just does not work. I am really looking forward to the next version where this will change again to accomodate / be compatible with Office 2007 hopefully !

To be continued

/Sven Jochimsen