Fixlist for the Financial Management Area

This document is a compilation of the fixes that are built into Microsoft Dynamics AX 3.0 with Service Pack 6 (SP6). All issue numbers are bug numbers that Microsoft and its partners can use to track these problems to resolution. Microsoft Knowledge Base (KB) numbers, when they are available, are linked to the published Knowledge Base on Partner Source (you must have access to Partner Source to access these links).
This document contains information similar to what can be found in the Microsoft Knowledge Base for a customer fix request escalation. Because some Microsoft Knowledge Base articles for these fixes are not yet published, this information is only as complete and accurate as is currently possible.

(Microsoft Dynamics AX 3.0) Accounts payable
(Microsoft Dynamics AX 3.0) Accounts receivable
(Microsoft Dynamics AX 3.0) Bank
(Microsoft Dynamics AX 3.0) Cost accounting
(Microsoft Dynamics AX 3.0) General ledger


(Microsoft Dynamics AX 3.0) Accounts payable

Request No. KB Article No. Short Description Detailed Description Object Description
#2675 Not available The system disregarded the C.O.D. terms of payment when the user posted the Invoice journal and the invoice without settlement and disregarding cash account. •  Problem
The system disregarded the C.O.D. terms of payment when the user posted the Invoice journal and the invoice without settlement and disregarding cash account.
The issue occurred because the vendor voucher was not supplied with the payment information.

•  Solution
To correct the issue, the newVendVoucherJournal method of the VendVoucher class has been modified to make invoice transaction correct when the user used the C.O.D. terms of payment. This correction applies only to the Invoice journal.

 \Classes\VendVoucher\newVendVoucherJournal
#2866 Not available An incorrect error message appeared noting that transactions were not balanced if the user registered an invoice, fetched it, entered some lines with and without taxes in the Invoice approval journal and validated it. •  Problem
An incorrect error message appeared noting that transactions were not balanced if the user registered an invoice in the Invoice register (Accounts payable > Invoices > Invoice register), fetched it, entered some lines with taxes and some lines without taxes in the Invoice approval journal (Accounts payable > Journals > Invoices > Invoice approval journal) and validated it.
The issue occurred because the validation and posting routines did not allow for the current tax setup of the Invoice approval journal. During the validation and posting, the approval voucher was validated and posted in deferent ways. That is why posting and validation sometimes gave different results.

•  Solution
The code has been modified to perform sales tax processing during validation and posting of the Invoice approval journal in the same manner.

 \Classes\TaxReverseTax\calcAndPost()
\Classes\TaxReverseTax\post()
\Classes\TaxReverseTax\saveAndPost()
\Classes\LedgerJournalCheckPostApproval\movePostedTaxes()
\Classes\LedgerJournalCheckPost\checkJournal()
\Classes\LedgerJournalCheckPost\movePostedTaxes()
\Classes\LedgerJournalTransUpdate\ledgerVoucherCheck()
#3034 Not available Incorrect invoice amounts were transferred to the Invoice approval journal if invoice lines excl. sales tax on them were broken down in the Invoice register. •  Problem
Incorrect invoice amounts were transferred to the Invoice approval journal if invoice lines excl. sales tax on them were broken down in the Invoice register.
The issue was caused by the ledger journal transfer job that disregarded whether the sales tax was included or excluded in the Invoice register. The mentioned job always subtracted the sales tax from the net amount even if it was a net amount that was completely incorrect.

•  Solution
The transferring procedure has been corrected in order to have the correct figures in the Invoice approval journal.

 \Classes\LedgerTransferToJournal\insertLedgerJournalTrans()
#3387 Not available The Invoice specification report showed an incorrect sales balance and tax amount. •  Problem
The Invoice specification report showed an incorrect sales balance and tax amount.
Incorrect amount in SalesBalance was based on an incorrect SumTax calculation. SumTax was calculated based on the taxTotalVoucher static method of the Tax class, which included the Use tax amount into calculation.

•  Solution
To avoid subtraction of the Use tax amount from the sales balance, the code has been corrected to use the taxTotal static method of the Tax class.

 \Classes\VendVoucher\createInvoiceJournal
#4764 Not available The system doubled currency requirements if invoice registering was linked to a purchase order. •  Problem
The system doubled currency requirements if invoice registering was linked to a purchase order.
Invoices linked to a purchase order were also reflected in the cashflow forecast. The forecast engine analyzed purchase orders, opened transactions and so on to update the currency requirements table. This caused the doubling of the required sum.

•  Solution
The cashflow forecast engine will not allow for opened transactions with the Purchase order field filled in.

 \Data Dictionary\Tables\VendTransOpen\Methods\updateLedgerCov
#8319 Not available The Vendor/Ledger reconciliation report showed a difference on exchange adjustment transactions when filtering by the used posting profile. •  Problem
The Vendor/Ledger reconciliation report showed a difference on exchange adjustment transactions when the user used filtering by the used posting profile.
In the \Classes\CustVendReversePosting\reverseExchAdjustment method, CustTrans\VendTrans generated for an exchange adjustment did not inherit the posting profile from the base transaction. The Posting profile field remained empty. When, in the Vendor/Ledger reconciliation report, the user used filtering by the posting profile, CustTrans/VendTrans for the exchange adjustment fell within scope.

•  Solution
The setting of the posting profile has been added in the customer/vendor transaction for the exchange adjustment.

 \Classes\CustVendReversePosting\reverseExchAdjustment
#8628 Not available Transaction text was missing on some tax transactions created by posting the Invoice register. •  Problem
Transaction text was missing on some tax transactions created by posting the Invoice register.
In the \Classes\LedgerJournalCheckPostApproval\movePostedTaxes, the select statement returned nothing, because the TaxGroup of the record was empty. Therefore, taxReverseTax.adjustTaxes was run. The following subsequent calls resulted in adding new objects to a voucher in taxReverseTax.post. These were voucher objects for tax transactions. These objects were the first objects in a voucher. Therefore, the LedgerVoucher value of lastTransTxt was empty. Therefore, the transaction text of these objects was empty.

•  Solution
The forced initialization of transaction text of a ledger voucher object in the taxReverseTax.post method has been added.

 \Classes\TaxReverseTax\post
#8659 Not available The value of the Approved by field could be removed from the Invoice approval journal and the journal could be posted with the Approved by field empty. •  Problem
The value of the Approved by field could be removed from the Invoice approval journal and the journal could be posted with the Approved by field empty.
The issue occurred because the Approved by field was not mandatory and, therefore, could be emptied and no warnings appeared during posting.

•  Solution
The Approved by field on the VendTrans data source of the LedgerJournalTransApprove form has been made mandatory.

 \Forms\LedgerJournalTransApprove\Data Sources\VendTrans\Fields\ApprovedBy
#8835 Not available Incorrect rounding occurred in some situations in the Open-transaction editing in several currencies form in the Accounts payable and Accounts receivable modules if a payment was in one currency and invoices were in a different currency. •  Problem
Incorrect rounding occurred in some situations in the Open-transaction editing in several currencies form in the Accounts payable and Accounts receivable modules if a payment was in one currency (for example, EUR) and invoices were in a different currency (for example, USD).
The issue occurred because the total amount calculation was made without the rounding.

•  Solution
Rounding has been added to the total amount calculation in the Open-transaction editing in several currencies form.

 \Forms\VendOpenTrans\Methods\updateRemainAmountCur
\Forms\CustOpenTrans\Methods\updateRemainAmountCur
#9054 Not available When different dimensions were used in the Invoice register and Invoice approval journal, the final transaction created in the Invoice approval journal had an incorrect dimension on the summary account of the vendor. •  Problem
When different dimensions were used in the Invoice register (Accounts payable > Journals > Invoices > Invoice register) and Invoice approval journal (Accounts payable > Journals > Invoices > Invoice approval journal), the final transaction created in the Invoice approval journal had an incorrect dimension on the summary account of the vendor.
The Vendor transaction could have had an indefinite value of the Dimension field after the journal was posted.
In line 98 of the \Classes\LedgerJournalCheckPost\postTrans method, there was a call of the initFromLedgerJournalTransApproval method (of the VendTrans table), and this method was called as many times as the number of Ledger transactions the user had in the voucher. Finally, VendTrans was populated with the dimension of the last selected ledger transaction. (Note that one vendor transaction refers to multiple Ledger transactions, and multiple Ledger transactions refer to only one vendor transaction.)
It was not that the users had an incorrect dimension in VendTrans after they had posted the Invoice approval journal, but they could not know for sure about exactly what dimension it would be.

•  Solution
The dimension in the vendor transactions are not changed during the posting of the Invoice approval journal, because the ledger and vendor transactions on the summary account already exist, and dimensions are specified correctly.

 \Data Dictionary\Tables\VendTrans\Methods\initFromLedgerJournalTransApproval
#9173, 9174 Not available When the user generated a payment in the Accounts payable module and printed the check, the text did not match the amount of the check if the amount was larger than 2,147,483,647.
Also, when the user generated a payment in the Accounts payable module and printed the check with the Spanish layout, in most situations the amount was printed only partially.		 •  Problem
When the user generated a payment in the Accounts payable module and printed the check, the text did not match the amount of the check if the amount was larger than 2,147,483,647.
Also, when the user generated a payment in the Accounts payable module and printed the check with the Spanish layout, in most situations the amount was printed only partially.
The issue occurred because of the incorrect declaration of variables that were used in converting numbers to the text. The variables were declared as integers instead of being declared as real. Therefore, the critical amount of 2,147,483,647, which is the limit of the integer type.
The second issue occurred because of a lack of one of the branches that formed the text out of numerals.

•  Solution
The issue with the large numbers has been resolved by declaring certain variables as real and rewriting the code lines responsible for rounding.
The issue with the Spanish layout has been resolved by adding some branches that will fully convert a numeral to text.

\Classes\Global\numeralsToTxt
\Classes\Global\numeralsToTxt_ES
#9182 Not available No sales tax reversal transactions appeared if the user made the unsettlement procedure over transactions with overpayment or underpayment with the Sales tax on over-/underpayment check box selected in the General ledger parameters form. •  Problem
No sales tax reversal transactions appeared if the user made the unsettlement procedure over transactions with overpayment or underpayment with the Sales tax on over-/underpayment check box selected in the General ledger parameters form.
The issue occurred because the code for creating reverse tax transactions was absent in the reversePennyDiff() method of the CustVendReversePosting class.

•  Solution
A routine that will reverse tax has been added to the reversePennyDiff() method of the CustVendReversePosting class.

 \Classes\CustVendReversePosting\reversePennyDiff
#9394 Not available The company currency conversion caused an incorrect ledger transaction to be posted when updating the inventory settlement. •  Problem
The company currency conversion caused an incorrect ledger transaction to be posted when updating the inventory settlement.
To calculate the difference between the sums of the posted corrections in InventorySettlement and the sums of the amounts in LedgerTrans, two numbers were summed up and compared to zero. Because both these sums had the same sign, this returned an incorrect result, because balanceSheetAccount behaved as an ordinary account during the posting.

•  Solution
The postDiffInvent method has been updated to post the correct adjustment difference. Also, the CurrencyConversation form has been updated to enable the user select a new currency in the drop-down list.

 \Classes\ConvRecalculateSums\postDiffInvent
\Forms\ConvCompanyCurrency\Designs\Design\[Group:CurrencyConversion]\[Group:Fields]\StringEdit:NewCompanyCurrency\Methods\modified
#9946 Not available Incorrect cash discount information was attached in the Invoice journal when transfer from the Invoice pool was used. •  Problem
Incorrect cash discount information was attached in the Invoice journal when transfer from the Invoice pool was used.
Cash discount information was corrupted while the system was retrieving invoices from the Invoice pool.
The issue occurred because the cash discount link engine used an incorrect reference to the newly transferred invoice line.

•  Solution
The discount link engine has been corrected.

 \Forms\LedgerJournalTransVendInvoice\Methods\insertFromInvoicePool
#10371 Not available In the vendor Invoice approval journal, an incorrect posting type for the arrival account transaction was used. •  Problem
In the vendor Invoice approval journal, an incorrect posting type for the arrival account transaction was used.
When the Invoice register journal was posted, transactions were created from vendor transactions according to a posting profile and had the ‘VendBalance’ type. However, in the Invoice approval journal, the transaction for LedgerTrans was created from ledger transactions. Therefore, by default, the posting type was set to ‘LedgerJournal’.

•  Solution
In the \Classes\LedgerVoucherTransObject\newTransLedgerJournal method, a correction exists for the posting type on the summary account transaction. A new condition has been added to this statement to change the posting type for the arrival account transaction. Also, verification, which identifies whether the voucher or transaction date is changed, has been added. The latest verification helps identify the vendor transaction if the vendor voucher or transaction date has been changed in the Invoice approval journal.

 \Classes\LedgerVoucherTransObject\newTransLedgerJournal
#10503 Not available Sales tax on a cash discount did not reverse during the unsettlement procedure if it was the use-tax. •  Problem
Sales tax on a cash discount did not reverse during the unsettlement procedure if it was the use-tax.
The select statement that prepares a tax transaction on a cash discount to be reversed did not allow for transactions that had been created for sales tax that had the Use-tax check box selected in the Sales tax group. The select statement that disregarded the mentioned transactions was located in the calcAndInsertTaxes() method of the TaxReverseTax class. The mentioned select statement was supplied with the condition that did not enable the user to select use-tax transactions because use-tax was calculated in another way.

•  Solution
The select statement has been supplied with an additional condition to have tax on cash discount transactions correctly reversed.

 \Classes\TaxReverseTax\calcAndInsertTaxes
#10832 Not available The payment ID validation in the Posting invoice form was always performed for the default vendor’s bank account and disregarded the setup of the purchase order. •  Problem
The payment ID validation in the Posting invoice form was always performed for the default vendor’s bank account and disregarded the setup of the purchase order.
The payment ID validation routine was always called without specifying the vendor’s bank account parameter. That was why the default vendor’s bank account validation was used instead of the validation specified for the bank account of the Posting invoice form.

•  Solution
The payment ID validation routine has been corrected to pass the order’s bank account as a parameter to the payment ID validation engine.

 \Forms\PurchEditLines\Data Sources\PurchParmTable\Methods\checkPaymentId
\Forms\PurchEditLines\Data Sources\PurchParmTable\Fields\VendBankAccountID\Methods\modified
#11852 Not available An unnecessary warning appeared while the system was validating vendor Payment journal if ‘Ledger’ was used as the offset account and if the Check sales tax groups check box was selected. •  Problem
An unnecessary warning appeared while the system was validating vendor Payment journal if ‘Ledger’ was used as the offset account and if the Check sales tax groups check box was selected.
The issue occurred because the sales tax combination check was performed for all type of journals, which caused unnecessary warning messages to appear.

•  Solution
The Journal line validation engine will now check the sales tax group combination only for transactions with the invoice number that is specified.

 \Classes\LedgerJournalTransUpdate\checkTaxCombination
#12054 KB909519 After closing the Edit payment proposal form, journal lines with checks generated on them were aggregated in one line. •  Problem
After closing the Edit payment proposal form, journal lines with checks generated on them were aggregated in one line.
The issue occurred because the \CustVendCreatePaymJournal\aggregateLedgerJournalTrans method did not take the payment status into account when it made an aggregation of journal lines.

•  Solution
Journal lines with Payment status set to ‘Sent’ will be excluded from the scope of the aggregation process. Also, grouping by payment status has been added to save the sensible value in the Payment status field on the aggregated journal lines.

 \Classes\CustVendCreatePaymJournal\aggregateLedgerJournalTrans
#12436 Not available A cash discount was not recalculated when a total discount was changed. •  Problem
A cash discount was not recalculated when a total discount was changed.
The issue occurred because the code for performing the recalculation was missing.

•  Solution
The Modified method of the EndDisc field of the form’s data source has been updated. Now the ReCalculate field value was set to ‘Yes’, which initiates the discount recalculation.

 \Forms\PurchParmTableTotals\Data Sources\PurchParmTable\Fields\EndDisc\Methods\modified
#13041 Not available In the Invoice journal, the Invoice pool function was available only if the Invoice register and invoice approval journal configuration key was enabled. •  Problem
In the Invoice journal (Accounts payable > Journals > Invoices > Invoice journal), the Invoice pool function was available only if the Invoice register and invoice approval journal configuration key was enabled.
The issue occurred because the Invoice pool used the Invoice register and invoice approval journal (VendInvoiceRegisterApproval) configuration key, which was used to control access to the Invoice register and Invoice approval journals.

•  Solution
The configuration key for the VendTransInvoicePool (Invoice pool) menu item has been changed to Invoice pool excl. posting (VendInvoicePool).

 \Menu Items\Display\VendTransInvoicePool
#13141 Not available The Retrieve fixed asset transactions in the fixed asset journal function enabled transactions to be retrieved into an already posted journal. This resulted in incorrect journal reports and created data inconsistency. •  Problem
The Retrieve fixed asset transactions in the fixed asset journal function enabled transactions to be retrieved into an already posted journal. This resulted in incorrect journal reports and created data inconsistency.
The issue occurred because the Retrieve fixed asset transactions button functionality was never managed in the Fixed assets journal form.

•  Solution
The code has been modified to manage the Retrieve fixed asset transactions button functionality, depending on the active journal’s "Posted" status.

 \Forms\LedgerJournalTransAsset
#13621 Not available Reverse settlement transactions were posted with incorrect exchange rates. •  Problem
Reverse settlement transactions were posted with incorrect exchange rates. This occurred when customer or vendor transactions were posted with regulated (manually modified in the journal lines) exchange rates on different summary accounts because of the different posting profiles.
The issue occurred because of the absence of the exchange rate variable that should have been passed to the ledger voucher. Originally, the ledger voucher was supplied only with the currency name and currency amount. Therefore, the MST amount was always calculated using the default exchange rates.

•  Solution
The code has been modified so that the actual exchange rates will be passed to the reversal routine and settlement transactions will be posted in the transaction currency.

\Classes\CustPrePaymentReversal\reversePostingProfileBalance
\Classes\CustPrePaymentReversal\reversePrePayment
\Classes\CustPrePaymentReversal\reverseReversePrePayment
\Classes\VendReversePostingProfile\reversePostingProfileBalance
\Classes\CustVendSettle\settleNow
#13649 Not available When the user posted vendor invoice transactions of the ‘Acquisition adjustment’ type the cash discount was not deducted on an asset. •  Problem
When the user posted vendor invoice transactions of the ‘Acquisition adjustment’ type the cash discount was not deducted on an asset.
The issue occurred because the cash discount settlement functionality in the Accounts payable module was not designed to handle fixed asset cash discount transactions for the asset transaction that was created and that had the ‘Acquisition adjustment’ transaction type.

•  Solution
The code responsible for posting vendor invoice cash discounts to fixed assets has been modified to handle vendor invoices transaction lines for fixed assets that were assigned the ‘Acquisition adjustment’ transaction type.

 \Classes\CustVendSettle
#14307 Not available The Offset account was incorrectly updated in the Invoice register journal line when the account was modified. •  Problem
The Offset account field was incorrectly updated in the Invoice register journal line when the account was modified.
When the user created the line, the value of the Offset account field was correctly retrieved based on the Account field. However, when modifying the Account field, the Offset account field was not updated.
The Offset account field was not updated when it already had a value, even after the Account field was modified.

•  Solution
Modifications have been made so that the Offset account field is updated regardless of its previous value.

 \Classes\LedgerJournalEngine\accountModified
#15521 Not available When reversing a settlement where a cash discount was taken during the payment and the Deduct cash discount check box was selected, the asset was not adjusted during the reversal. •  Problem
When reversing a settlement where a cash discount was taken during the payment and the Deduct cash discount check box was selected, the asset was not adjusted during the reversal.
The issue occurred because the ability to update reverse the Fixed asset cash discounts table was never implemented in the Vendor, Closed-transaction editing, and Reverse option processes.

•  Solution
The reversal process has been modified to handle the reversal of fixed asset cash discounts.

 \Classes\CustVendReversePosting
#15767 Not available Sales tax on a cash discount was not reversed (or was reversed incorrectly) when the Invoice approval journal was posted with a new voucher number or a new date and sales tax in the Invoice approval journal was modified comparing to the Invoice register. •  Problem
Sales tax on a cash discount was not reversed (or was reversed incorrectly) when the Invoice approval journal was posted with a new voucher number or a new date and sales tax in the Invoice approval journal was modified comparing to the Invoice register.
The issue was caused by incorrect information being passed to the sales tax reversing procedure. Whenever sales tax on a cash discount was going to be reversed, the initial (from the Invoice register) voucher number and transaction date were passed. These variables were completely correct except for one situation: when the voucher number and transaction date were modified in the Invoice approval journal and new sales tax information was set for the Invoice approval journal. In the depicted situation, the sales tax reversal procedure was supplied with an obsolete voucher number and transaction date and therefore an incorrect (or no) sales tax amount was reversed.

•  Solution
The voucher number and transaction date from the Invoice approval journal will be passed to the reversal procedure to the reverse correct sales tax amount that will be coherent with the sales tax information from the Invoice approval journal.

 \Classes\CustVendSettle\approvalVoucherDate
\Classes\CustVendSettle\taxCashDisc
\Classes\CustVendSettle_Vend\approvalVoucherDate
#15930 Not available The Payment advice report showed incorrect information when the cheque that the user reported on was generated against an invoice with an overdue cash discount, but cash discount was forced by selecting ‘Always’ in the Use cash discount field during the settlement. •  Problem
The Payment advice report (Bank > Reports > External > Payment advice) showed incorrect information when the cheque that the user reported on was generated against an invoice with an overdue cash discount, but the cash discount was forced by selecting ‘Always’ in the Use cash discount field during the settlement.
The issue was caused by the vendCashDiscAmountIfPossible() method of the SpecTrans table. In this method, a possible cash discount amount was retrieved from the VendTransCashDisc table. The transaction date was always passed to the findCashDisc() method of the VendTransCashDisc table, ignoring the possibility to have (or not have) a cash discount independent of the transaction date (for example, the Use cash discount option in the Open-transaction editing form). In the depicted scenario, the transaction date was not within the cash discount. Therefore, no cash discount was retrieved. However, the Use cash discount option (set to ‘Always’) was not taken into account while the system was defining the cash discount amount. This means that the system should not pay attention to the transaction date when the Use cash discount option was set to ‘Always’ or ‘Never’.

•  Solution
The Transaction date variable will be modified according to the Use cash discount option selected in the Open-transaction editing form during settlement. When this option is set to ‘Normal’, the actual transaction date will be used. Otherwise, dateNull() or maxDate() will be used to define the possible cash discount amount.

 \Data Dictionary\Tables\SpecTrans\Methods\custCashDiscAmountIfPossible
\Data Dictionary\Tables\SpecTrans\Methods\vendCashDiscAmountIfPossible
#16047 KB918220 The Sales tax payment report showed incorrect figures if sales tax that had 100% exempt was posted through the Invoice journal (or purchase order) that had sales tax included into the amount. •  Problem
The Sales tax payment report showed incorrect figures if sales tax that had 100% exempt was posted through the Invoice journal (or purchase order) that had sales tax included into the amount.
The issue occurred during the sales tax posting. If the journal had the Amount in the journal includes sales tax check box selected (Price incl. sales tax in purchase order) the calculated sales tax base amount plus the sales tax amount could be not equal to the journal amount. This could be caused by sales tax amount rounding during the calculation. In this situation, the tax amount was adjusted accordingly. If taxInCostPrice was equal to taxAmount (100% tax exempt), taxInCostPrice should also be updated. The issue was that the tax in the cost price was adjusted only in the source currency and ignored the MST currency and tax code currency. Later, during the posting these "untouched" (MST and tax code currency) were used during reporting. Because the mentioned tax amounts were not adjusted, the Sales tax payment report contained incorrect figures.

•  Solution
The code has been modified to adjust tax in cost price amounts in all currencies if sales tax exempt is equal to 100%.

 \Classes\TaxLedgerJournal\adjustPennyDiff
\Classes\Tax\adjustPennyDiff
#16861 KB920046 The incorrect sign of the currency amount appeared in the Draw promissory note journal if a promissory note was created automatically. •  Problem
The incorrect sign of the currency amount appeared in the Draw promissory note journal if a promissory note was created automatically.
The issue occurred because, if VendTransOpen.AmountCur was already in credit, assigning the extra ‘-’ in front of it made ‘-’ & ‘-’, which became ‘+’.

•  Solution
The procedure that automatically creates a promissory note when an invoice is posted has been corrected.

 \Classes\VendVoucher\settleAndDrawNegotiableInstrument
\Reports\PurchPromissoryNote\Designs\ReportDesign1\AutoDesignSpecs\Body:VendPromissoryNoteTrans_Body\Real:VendPromissoryNoteTrans_AmountCur
#16978 KB920043 The conditional tax amount was calculated and posted incorrectly if an invoice was settled with several payments. •  Problem
The conditional tax amount was calculated and posted incorrectly if an invoice was settled with several payments.
The issue was caused by an incorrect calculation of the settlementFactorOrigDebet(/Credit) variable that controls how much of the invoice amount was settled by the previous payment. It was calculated correctly, but not in the appropriate location of the CustVendSettle.settleNow() method. This variable was updated only when a new invoice was fetched for settlement. Therefore, when an invoice was settled by the second payment, this variable was not modified (which was incorrect because some part of the invoice was settled by the first payment) and an incorrect percentage was passed to the settle conditional tax routine.

•  Solution
The code has been modified to update the settlementFactorOrigDebet(/Credit) variable every time that the invoice (payment) transaction is (fully/partially) settled.

 \Classes\CustVendSettle\settleNow
#17655 KB921195 Incorrect ledger transactions were generated during settlement of the invoice with the defined cash discount and payment with the same posting currency and different exchange rates. •  Problem
Incorrect ledger transactions were generated during settlement of the invoice with the defined cash discount and payment with the same posting currency and different exchange rates. The issue occurred when the payment amount was close to the full invoice amount. In this situation the cash discount should be administered according to the method that was defined in the customer/vendor parameters, and if the "unspecific" method is used, the granted discount will be deducted from the payment.
The problem was that the granted cash discount amount in the posting currency corresponds to different amounts in the company currency (MST) for the invoice and payment. Therefore, many incorrect adjustment transactions could be generated or the cash discount would be not administered at all.
The issue occurred because the calculation of the defined cash discount during the cash discount administering was incorrect.

•  Solution
The code has been corrected to use the payment exchange rate to determine the MST amount of the granted cash discount, which will be compared with the over/under payment MST amount to decide whether the discount should be reverted or not. Despite this fact cash discount transactions will always be posted using the invoice exchange rate.

 \Classes\CustVendSettle\settleNow
#17913 KB922605 Incorrect ledger transactions were generated when the user was running the Invoice date exchange adjustment for an invoice splintered by the due date. •  Problem
Incorrect ledger transactions were generated when the user was running the Invoice date exchange adjustment for an invoice splintered by the due date. The exchange adjustment engine reversed the full amount of the unrealized exchange adjustment for each part of the invoice.
The issue was based on an incorrect determination of the amount that should be reversed. This functionality was covered by \Classes\CustVendExchAdjTrans\exchAdjustTrans and was defined as reverseAmountMST = -custVendTrans.exchAdjustmentUnrealized;. However, when the user previously split this invoice into three parts, this amount would be reversed three times instead of the particular reversing of this amount.
The second issue was an incorrect ledger posting type for ledger transactions when reversing the previous exchange adjustment.

•  Solution
The code has been corrected to reverse the corresponding part of the unrealized exchange adjustment for each part of the splintered invoice.

 \Classes\CustExchAdjTrans\posting
\Classes\VendExchAdjTrans\posting
\Classes\CustVendExchAdjTrans\posting
\Classes\CustVendExchAdjTrans\adjust
\Classes\CustVendExchAdjTrans\exchAdjustTrans
#18118 KB922457 Users could not use the Functions > Purchase Order posting functionality if they canceled the invoice registration because of an incorrect amount and then create a new one with the same date and invoice number. •  Problem
Users could not use the Functions > Purchase Order posting functionality if they canceled the invoice registration because of an incorrect amount and then create a new one with the same date and invoice number.
The issue occurred because of the invoice fetching engine, which uses the invoice date and number to find the appropriate invoice. However, if there is an invoice cancellation and recreation of the same invoice within the same date this relation referred to the original invoice, invoice cancellation record and a newly created invoice. In this situation the system always fetched the first invoice registration with the specified invoice number and posting date and disregarded that it was canceled.

•  Solution
The code has been modified to use the invoice number, invoice date and ledger voucher number to identify the correct invoice registration.

 \Data Dictionary\Tables\CustInvoiceJour\Methods\findFromCustTrans
\Data Dictionary\Tables\CustInvoiceJour\Methods\findFromCustTransExt
\Data Dictionary\Tables\VendInvoiceJour\Methods\findFromVendTrans
\Data Dictionary\Tables\VendInvoiceJour\Methods\findFromVendTransExt
\Data Dictionary\Tables\CustTrans\Methods\existInvoice
\Data Dictionary\Tables\VendTrans\Methods\existInvoice
\Classes\CustVendReversePosting\findInvoice
\Classes\CustVendReversePosting\taxCashDisc
\Classes\CustVendReversePosting\taxSettlement
\Classes\CustVendSettle\findInvoice
\Classes\CustVendSettle\taxCashDisc
\Classes\CustVendSettle\taxSettlement
\Classes\CustVendSettle_Cust\findInvoice
\Classes\CustVendSettle_Vend\createBankChequeTrans
\Classes\CustVendSettle_Vend\findInvoice
\Classes\CustReversePosting\findInvoice
\Classes\PurchFormLetter_ApproveJournal\findInvoiceJour
\Classes\VendReversePosting\findInvoice

Top


(Microsoft Dynamics AX 3.0) Accounts receivable

Request No. KB Article No. Short Description Detailed Description Object Description
#3063 Not available The Cashflow forecast form showed an incorrect forecast amount when the sales order was created with the payment schedule set up. The same incorrect amounts appeared in the Purchase order and Free text invoice forms. •  Problem
The Cashflow forecast form (started from Accounts receivable > Sales order > Inquiries > Cashflow forecasts) showed an incorrect forecast amount when the sales order was created with the payment schedule set up. The same incorrect amounts appeared in the Purchase order and Free text invoice forms.
The issue was caused by incorrect information that was passed to the updateSum() method of the LedgerCoverage class. An incorrect account to be forecasted was passed, which led to inconsistency in the cashflow forecast.

•  Solution
The methods that call the updateSum() method of the LedgerCoverage class have been corrected and the correct ledger account will be passed to be forecasted. Also, the clearingPeriod() method of CustInvoiceTable has been corrected in order to return the correct value.

 \Classes\SalesTableType\updateLedgerCov
\Classes\PurchTableType\updateLedgerCov
\Data Dictionary\Tables\CustInvoiceTable\Methods\updateLedgerCov
\Data Dictionary\Tables\CustInvoiceTable\Methods\clearingPeriod
#4596 Not available Bank account of the customer/vendor transaction was always the default bank account for the selected customer/vendor. •  Problem
Bank account of the customer/vendor transaction was always the default bank account for the selected customer/vendor. This was caused by the absence of the routine that copies the bank account from the ledger transaction to the customer (vendor) transaction.

•  Solution
The bank account initialization code has been added to the initFromLedgerJournalTrans method of the CustVendTrans map.

 \Data Dictionary\Maps\CustVendTrans\Methods\initFromLedgerJournalTrans
#5065 Not available It was not possible to post an invoice when the user was using sales tax limits in cooperation with the US tax system. •  Problem
It was not possible to post an invoice when the user was using sales tax limits in cooperation with the US tax system. This issue occurred because the "tax in cost price" amount limitation was absent. Therefore, the voucher became unbalanced.

•  Solution
The CalcTax method of the Tax class has been corrected to update the "tax in cost price" value accordingly to the predefined tax amount limitation.

 \Classes\Tax\calcTax
#5439 Not available The CreatedDate property of the CustTable was set to ‘Yes’ in the SYP layer, but, in the DIP layer, this property was set to ‘No’. •  Problem
The CreatedDate property of the CustTable was set to ‘Yes’ in the SYP layer, but, in the DIP layer, this property was set to ‘No’.
The issue occurred because of the over layering problem.

•  Solution
The CreatedDate of \Data Dictionary\Tables\CustTable on the GLP layer has been changed from ‘No’ to ‘Yes’.

 \Data Dictionary\Tables\CustTable
#8791 Not available When a payment schedule was used with an invoice in a currency other than the main company currency, settlement against the payment on the same amount in some situations left an open transaction with a zero value in the main company currency and non-zero amount in a currency of the transaction. •  Problem
When a payment schedule was used with an invoice in a currency other than the main company currency, settlement against the payment on the same amount in some situations left an open transaction with a zero value in the main company currency and non-zero amount in a currency of the transaction.
The issue occurred because during the calculation of the payment schedule, amounts of installments in the transaction currency are used, but nothing was done to the rounding differences between the total amount of an invoice and the sum of the amounts of the installments.

•  Solution
The calculation of payment schedule installments has been modified to include the rounding amount in the maximum installment. If the installments have the same amount, the rounding amount is included in the latest installment.

 \Classes\PaymSchedCalc\createCustVendTransaction
#9336 Not available The External customer account statement showed an incorrect opening balance if the last settlement date transaction existed after the "From date". •  Problem
The External customer account statement showed an incorrect opening balance if the last settlement date transaction existed after the "From date".
The issue occurred because the Opening balance calculation engine disregarded the difference in dates between the settlement and the offset settlement transaction, resulting in an incorrect opening balance.

•  Solution
An incorrect opening balance calculation was based on the difference between the settlement and the offset settlement transaction dates in CustSettlement/VendSettlement for one settlement. Therefore, the Customer/vendor balance per date calculation engine has been corrected to calculate transactions as opened if the settlement and the offset settlement transaction date were after the target date.

 \Data Dictionary\Tables\CustTrans\Methods\transactionPerDate
\Data Dictionary\Tables\VendTrans\Methods\transactionPerDate
#9410 Not available Sales tax on prepayment was lost when there was a settlement with several invoices. Also, sales tax on prepayment accounts became imbalanced if a cash discount or penny difference was used during the settlement. •  Problem
Sales tax on prepayment was lost when there was a settlement with several invoices. Also, sales tax on prepayment accounts became imbalanced if a cash discount or penny difference was used during the settlement.
The reversePrepayment() method of the CustPrepaymentReversal class calculates the percentage of sales tax on the prepayment to be reversed. For the first settled invoice, this percentage was correct, but for the following invoices to be settled, the percentage was calculated incorrectly. To calculate the percentage for the current part of the settled prepayment, the system performed the following steps: first, it calculated the quotient from the whole prepayment amount and the amount that was to be settled. And second, the system reduced this quotient on the sum of the previous settled customer/vendor transactions in the transaction currency. Therefore, the percentage was calculated incorrectly. Also, incorrect sales tax amounts were reversed during unsettlement because of an incorrect sales tax percentage calculation.

•  Solution
The code has been modified to perform the calculation of the specific part of prepayment to be settled. After that, the percentage calculation will be performed correctly. Also, the reverse procedure has been updated to reverse the correct tax amounts. The Sales tax on prepayment posting routine has been added to the cash discount and penny difference posting to post the respective tax amount if there is a prepayment.

 \Classes\CustPrePaymentReversal\reversePrePayment
\Classes\CustPrePaymentReversal\reverseReversePrePayment
\Classes\CustVendReversePosting\reversePennyDiff
\Classes\CustVendSettle\postDiscTrans
\Classes\CustVendSettle\postPennyDiff
#10433 Not available Dimension on over/underpayment transactions was incorrect. •  Problem
Dimension on over/underpayment transactions was incorrect.
The issue occurred because the dimension of the invoice was always used for under/overpayment open transaction.

•  Solution
The _dimension additional parameter has been added to the \Classes\CustVendSettle\postPennyDiff and \Classes\CustVendSettle\postPennyDiffOnCashDisc methods to pass the correct dimension value.
Also, the NoYes stillOpenRecIsCredit[]; array has been added to the \Classes\CustVendSettle\settleNow method that stores information about the open record whether this record is a payment or an invoice. This value is used to pass the correct value to \Classes\CustVendSettle\postPennyDiff in \Classes\CustVendSettle\settleNow.

\Classes\CustVendSettle\postPennyDiff
\Classes\CustVendSettle\postPennyDiffOnCashDisc
\Classes\CustVendSettle\settleNow
#10573 Not available The performance of the payment proposals procedure was very poor. •  Problem
The performance of the payment proposals procedure was very poor. If the database stored many records for customers or vendors, the payment proposals procedure was very slow.
The issue occurred because the progress bar usage took too much time while estimating the transaction quantity, which should have been processed if there were many transactions (approximately ten thousand or more).

•  Solution
The code has been modified to avoid using the progress bar.

 \Classes\CustVendCreatePaymJournal_Vend\searchTransactions
\Classes\CustVendCreatePaymJournal_Cust\searchtransactions
#10684 Not available The collection letter fee that was shown in the Collection letter note form was doubled. •  Problem
The collection letter fee that was shown in the Collection letter note form was doubled.
The issue was caused by the \Data Dictionary\Tables\CustCollectionLetterJour\Methods\sumAmount display method. The query calculated the amount of all transactions including fee transactions in CustCollectionLetterTrans and then this method added the fee amount from the current CustCollectionLetterJour record.

•  Solution
A condition to remove fee transactions from the selection has been added.

 \Data Dictionary\Tables\CustCollectionLetterJour\Methods\sumAmount
#11980 Not available Order posting was not possible if the Deduct cash discount before sales tax calculation and Prices include sales tax check boxes were selected in a sales order invoice and the tax marginal base was set to ‘Net amount per line’. •  Problem
Order posting was not possible if the Deduct cash discount before sales tax calculation and Prices include sales tax check boxes were selected in a sales order invoice and the tax marginal base was set to ‘Net amount per line’.
The issue occurred because the calculated cash discount value was not rounded. Therefore, in some situations the penny difference engine tried to post a value that was less than ‘0.01’.

•  Solution
The line discount calculation engine has been modified to round up the discount and tax base amount values before posting the penny difference.

 \Classes\TaxSales\calc
#11985 Not available The Language texts set for the particular interest codes were not picked when the user created interest notes with the Periodic job using these interest codes. •  Problem
The Language texts set for the particular interest codes were not picked when the user created interest notes with the Periodic job using these interest codes.
The line of code for picking the interest code texts was missing in the code that creates interest notes.

•  Solution
The CustinterestCreate::createJournal method has been modified to insert the text taken from the interest code setup.

 \Classes\CustinterestCreate::createJournal
#12037 Not available When the user imported payments from the file, settlement against the invoices did not allow for the over/under payment setup. •  Problem
When the user imported payments from the file, settlement against the invoices did not allow for the over/under payment setup.
When the payment was imported from the file, the process searches for the corresponding invoice. If it succeeds, it tries to mark this CustTransOpen record for settlement. Marking was made by creating a new specOffsetVoucher that adds a new record to SpecTrans. However, by mistake the amount of payment was used instead of the amount of invoice. This caused incorrect calculations during settlement.

•  Solution
The amount to settle on the payment has been changed from the invoice amount to the payment amount.

 \Classes\CustInPaym
\Classes\CustInPaymBank1
\Classes\CustInPaymCH
\Classes\CustInPaymCH_DebitDirect
\Classes\CustInPaymCH_ESR
\Classes\CustInPaymNO
\Classes\CustInPaymNO_OCRAG
\Classes\CustInPaymSE
\Classes\CustInPaymSE_BGAA
\Classes\CustInPaymSE_BGOCR
\Classes\CustInPaymSE_PGOCR
\Classes\CustInPaym\createLedgerJournalTrans
\Classes\CustInPaymCH_ESR\fromDisk2Journal
\Classes\CustInPaymCH_DebitDirect\fromDisk2Journal
#13217 Not available Incorrect summary accounts were used during the settlement of customer and vendor transactions if they were posted with regulated exchange rates. •  Problem
Incorrect summary accounts were used during the settlement of a customer and vendor transaction if they were posted with regulated exchange rates (exchange rates were modified immediately before posting). An incorrect summary account led to the imbalance of summary accounts.
The issue occurred because the incorrect customer transaction was selected for adjustment in the checkPostExchRateDiff() method of the CustVendSettle_Cust class. Because of the additional conditional statement, an incorrect customer transaction was selected for adjustment and therefore the incorrect summary account was used.

•  Solution
The code has been modified to use the correct transaction for adjustment. When transactions have different posting profile credits (payment), the transaction will be adjusted. The only exception is for prepayment transactions. If there is a prepayment, the debit (invoice) transaction will be adjusted because the prepayment settlement is performed for the prepayment exchange rates.

 \Classes\CustVendSettle_Cust\checkPostExchRateDiff
#13226 Not available Summary accounts became unbalanced when the user settled the invoice with a prepayment if the prepayment transaction used a particular posting profile and the exchange rate was manually changed in the Payment journal. •  Problem
Summary accounts became unbalanced when the user settled the invoice with a prepayment if the prepayment transaction used a particular posting profile and the exchange rate was manually changed in the Payment journal.
The issue occurred because the reversePrePayment() method of the CustPrePaymentReversal class did not allow for possible exchange rates changes in the Payment journal and calculated the MST payment amount based on the default exchange rates.

•  Solution
The prepayment exchange rate will now be picked not from the default values, but from the current prepayment transaction. Because the reverse posting occurs in the prepayment transaction currency, settlement amount will also be passed to the reversePrePayment() method in the prepayment currency. Also, the reversePrePayment() method of the CustPrepaymentReversal class has been modified to remove variables that were not used.

 \Classes\CustPrePaymentReversal\reversePrePayment
\Classes\CustVendSettle\settleNow
#13361 Not available During the settlement/unsettlement procedures over the customer/vendor transactions that were posted by the different posting profiles, no auxiliary transactions were created. This led to incorrect information representation in the Customer auditor report and Reconciliation report. •  Problem
During the settlement/unsettlement procedures over the customer/vendor transactions that were posted by the different posting profiles, no auxiliary transactions were created. This led to incorrect information representation in the Customer auditor report and Reconciliation report.

•  Solution
The code has been corrected so that when the settlement/unsettlement procedure is performed over the transactions that were posted with the different posting profiles, the additional auxiliary transactions will be created. For this purpose new methods have been created (postingProfileSettle() of the CustVendSettle_Vend/CustVendSettle_Cust classes). These methods will create the customer/vendor voucher object that will post the customer/vendor transaction into the Accounts receivable and Accounts payable modules and afterward post the derived ledger transactions.

 \Data Dictionary\Base Enums\LedgerTransType
\Data Dictionary\Base Enums\LedgerTransTxt
\Classes\CustVendSettle\settleNow
\Classes\CustVendSettle_Cust\postingProfileSettle
\Classes\CustVendSettle_Cust\balancePostingProfile
\Classes\CustVendSettle_Vend\postingProfileSettle
\Classes\CustVendSettle_Vend\balancePostingProfile
\Classes\CustVoucher\post
\Classes\CustVendVoucher\post
\Classes\CustPrePaymentReversal\reversePostingProfileBalance
\Classes\VendReversePostingProfile\reversePostingProfileBalance
\Classes\CustPrePaymentReversal\reversePrePayment
\Classes\CustPrePaymentReversal\reverseReversePrePayment
#13432 Not available Preparation of the Aging report took too much time if the database contained many customer/vendor transactions. •  Problem
Preparation of the Aging report took too much time if the database contained many customer/vendor transactions.
The query used to retrieve data for the Aging report was designed to retrieve and process every CustTransOpen record. However, if the report was started without the Details or Payment positioning options turned on, the mentioned CustTransOpen transactions were processed immediately by a single select statement.

•  Solution
If there is a simple report (without using the Details or Payment positioning options), to increase performance, the aggregate SQL query will return the amount being processed on the SQL server.

 \Reports\CustAgingReport\Methods\fetch
\Reports\VendAgingreport\Methods\fetch
\Classes\CustVendBalanceList\classDeclaration
\Classes\CustVendBalanceList\new
\Classes\CustVendBalanceList\construct
\Classes\CustBalanceList\calculateDetails
\Classes\CustBalancelistTransactionDate\calculateDetails
\Classes\VendbalanceList\calculateDetails
\Classes\VendBalancelistTransactiondate\calculateDetails
#13978 Not available The user was able to combine the Percentage and Amount methods when the user was setting up Payment lines for the payment schedule, although this should not have been possible. •  Problem
The user was able to combine the Percentage and Amount methods when the user was setting up Payment lines for the payment schedule, although this should not have been possible.
The issue occurred because there was no validation on the methods of the payment schedule.

•  Solution
The calculation method check has been added to the validateWrite method.

 \Data Dictionary\Tables\PaymSchedLine\Methods\validateCalculationMethod
\Data Dictionary\Tables\PaymSchedLine\Methods\validateWrite
#14442 Not available Settlements for a customer/vendor could be deleted when the user was using the Edit payment proposal form that was called from an empty journal. •  Problem
Settlements for a customer/vendor could be deleted when the user was using the Edit payment proposal form that was called from an empty journal.
The issue occurred because of an incorrect journal number determination for empty journals. Therefore, transactions marked for settlement from other journals could be shown in the Edit payment proposal form.

•  Solution
The Edit payment proposal query has been corrected. Now the journal number will be retrieved from the LedgerJournalEngine object instead of processing the LedgerJournalTrans record.

 \Forms\CustPaymProposal\Data Sources\LedgerJournalTrans\Methods\init
\Forms\VendPaymProposal\Data Sources\LedgerJournalTrans\Methods\init`;
#16012 Not available The user could sell an already-sold fixed asset using the free text invoice functionality. •  Problem
The user could sell an already-sold fixed asset using the free text invoice functionality.
The issue occurred because the necessary validation of the AssetTrans record was not done before the user updated the AssetTrans table and posted the fixed assets from the customer free text invoice process.

•  Solution
The posting process for customer free text invoices has been modified to validate an asset transaction before posting it.

 \Classes\CustPostInvoice
#16663 KB919774 A collection letter was not canceled if the transaction due date was moved forward, hence canceling the collection letter. •  Problem
A collection letter was not canceled if the transaction due date (transactions that were used for the collection letter creation) was moved forward, hence canceling the collection letter.
This issue occurred when many transactions that formed the collection letter had the due date moved forward. The issue was caused by the selection conditions that had been used during the data retrieval. A collection letter was retrieved for processing if at least one transaction from the collection letter has due date earlier than the collection letter date. Therefore, if all collection letter transactions had the due date after the collection letter date, this collection letter will not be taken into processing and will not be canceled.

•  Solution
To update the collection letter status when all collection letter transactions have the due date later then collection letter date, the query that has been used for the creation will be supplied with the additional data sources to identify which collection letters should be cancelled.

 \Classes\CustCollectionLetterCreate\updateCreatedCollectionLetter
\Classes\CustCollectionLetterCreate\run
#18435 KB923059 Sales order totals and sales tax values were incorrect when the cash discount with the Deduct cash discount before sales tax calculation option was used. •  Problem
Sales order totals and sales tax values were incorrect when the cash discount with the Deduct cash discount before sales tax calculation option was used.
The issue occurred because the cash discount value was not taken into account when calculating the amount with sales taxes and, therefore, totals were also calculated incorrectly.

•  Solution
The declaration of the \Classes\Tax\baseAmountExclTax method has been extended with the cash discount percent parameters. The code of this method has also been modified to subtract the specified discount from the calculated taxes. Several tables’ methods have also been corrected to pass the cash discount percent to the base amount calculation engine if the Deduct cash discount before sales tax calculation functionality will be used.

 \Data Dictionary\Maps\SalesPurchTable\Fields\CashDisc
\Data Dictionary\Maps\SalesPurchLine\Methods\amountExclTax
\Data Dictionary\Tables\CustInvoiceTrans\Methods\amountExclTax
\Data Dictionary\Tables\VendInvoiceTrans\Methods\GrossAmount
\Data Dictionary\Tables\PurchParmLine\Methods\amountExclTax
\Data Dictionary\Tables\SalesParmLine\Methods\lineAmountExclTax
\Data Dictionary\Tables\smmQuotationLine\Methods\amountExclTax
\Classes\Tax\baseAmountExclTax
\Classes\TaxPurch\calc
\Classes\TaxSales\calc

Top


(Microsoft Dynamics AX 3.0) Bank

Request No. KB Article No. Short Description Detailed Description Object Description
#2957 Not available The Reconciliation Summary report showed incorrect information when the report was run as of the date when some reconciled bank transactions were unreconciled. •  Problem
The Reconciliation Summary report (Bank > Bank accounts > Functions > Account reconciliation > Print > Reconciliation Summary) showed incorrect information when the report was run as of the date when some reconciled bank transactions were unreconciled. For example, if the bank transaction was reconciled on 15/06/06 and the report was run as of 10/06/06, no information was shown about the mentioned bank transaction in the unreconciled section of the report.
The issue was caused by the data selection for the report. If the bank transaction had the Reconciled field set to ‘True’, the mentioned transaction would not be retrieved for the report even if the report was run as of the date when the mentioned transaction was not reconciled.

•  Solution
Data retrieving has been modified to have the correct information in the report.

 \Reports\BankReconciliationSummary\Methods\ClassDeclaration()
\Reports\BankReconciliationSummary\Methods\UnclearedTransactions()
\Reports\BankReconciliationSummary\Methods\sendUncleared()
\Reports\BankReconciliationSummary\Methods\summary
#4331 Not available The Account statement report did not show the Sales tax information if the dimension settings for the Ledger account were fixed. •  Problem
The Account statement report (General ledger > Reports > Transactions > Account statement) did not show the Sales tax information if the dimension settings for the Ledger account were fixed (the ‘Fixed’ value in the fields of the Mandatory dimension field group).
The posting engine creates a relation between the ledger transaction and tax transaction based on dimensions. However, dimensions for a tax transaction did not allow for Ledger account dimension settings. In this situation, tax transaction dimensions and ledger posting dimensions were different.

•  Solution
The code has been modified to correctly update the Tax reference Id field.

 \Classes\LedgerVoucherObject\AddTrans()
#5897 Not available A critical stop error occurred during the data upgrade preventing the operation from continuing. •  Problem
A critical stop error occurred during the data upgrade preventing the operation from continuing.
Two scripts were executed for the data upgrade at about the same time. An error occurred because there were two upgrade methods (\Classes\ReleaseUpdateDB_V25toV30\updateBankAccountValidation and \Classes\ReleaseUpdateDB_V25toV30\updateVendRemittanceAdviceParm) both called the same code to check for the existence of the record in the \Data Dictionary\Tables\BankParameters table and, if it did not exist, inserted the records with the default values.

•  Solution
The dependence has been created between the \Classes\ReleaseUpdateDB_V25toV30\updateBankAccountValidation and \Classes\ReleaseUpdateDB_V25toV30\updateVendRemittanceAdviceParm methods.

 \Classes\ReleaseUpdateDB_V25toV30
#10044 Not available When the user printed checks, the amount in written text could be incorrect. •  Problem
When the user printed checks, the amount in written text could be incorrect.
The issue occurred because the @SYS5511 label was used in the Global::num2Text method to translate number ‘2’ as ‘to’ instead of ‘two’.

•  Solution
The @SYS26621 label will be used instead of @SYS5511.

 \Classes\Global\num2Text
#10225 Not available A bank cheque was printed on the second page if bottom alignments were used. •  Problem
A bank cheque was printed on the second page if bottom alignments were used.
The issue occurred because the printable paper length calculation disregarded the top non-printable margin.

•  Solution
The paper length calculation has been corrected to allow for top and bottom non-printable page margins.
Now six millimeters will be used as the top non-printable margin.

\Classes\VendCheque\slipTxtLines
\Classes\BankPrintTestCheque\createTestCheque
#11596 Not available The "No More Checks for account …" error message appeared if the user had the particular check layout settings and tried to generate payment with the settled invoices. •  Problem
The "No More Checks for account …" error message appeared if the user had the particular check layout settings (Check number method = Fixed, Check form = USA check format, Paper length = 11 inches, Check Start position = 2 inches) and tried to generate payment with the settled invoices.
The issue occurred because of an incorrect line quantity calculation. The endLines variable under the previously mentioned conditions became equal to ‘zero’ and this led to inalterability of the specTransLines variable which led to the end-of-check loop.

•  Solution
The code has been modified to decrease the endLines variable only by the necessary value for the header and another particular line quantity. Also, the slip lines quantity for the DKStyle checks has been modified. Now the slip line is formed when the check has sufficient room for the header, vendor information and slip transactions. Also, spaces between the header fields were decreased to make the header less awkward (the "Payment amount" phrase did not fit into one line and the "amount" word was transferred to the next line, which led to the extirpation of subtotals and perplexed header).

 \Classes\VendCheque\fillCheque
\Classes\VendCheque\fillSlipTxt
#12732 Not available Check cancellation failed if a bank transaction with the same payment reference existed. •  Problem
Check cancellation failed if a bank transaction with the same payment reference existed.
The issue occurred because the Payment reference field was used instead of the Bank cheque field for searching the appropriate bank transaction.

•  Solution
The bank transaction relation has been corrected to use the Cheque number field instead of the Payment reference field.

 \Classes\BankChequeCancel\bankAccountTrans
#13857 Not available The bank cheque reversing transaction was always unreconciled whether the user wanted to reconcile transaction or not. •  Problem
The bank cheque reversing transaction was always unreconciled whether the user wanted to reconcile transaction or not.
The issue occurred because the bank cheque reversing transactions were always marked as reconciled.

•  Solution
The appropriate check box has been added to the Payment reversal form. Now the reconciliation mark for transactions depends on the user input.

 \Classes\BankChequeCancel\ClassDeclaration
\Classes\BankChequeCancel\cancelCheque
\Classes\BankChequeCancel\createBankTrans
\Classes\BankChequeCancel\dialog
\Classes\BankChequeCancel\getFromDialog
\Classes\BankChequeCancel\unpack
\Classes\BankChequeCancel\parmReconcile
\Classes\BankChequeCancel\newBankChequeTable
#18671 KB923710 An error message appeared when the scheduled payments were used to pay off invoices and partially pay more than one scheduled payment and then reverse the payment. •  Problem
An error message appeared when the scheduled payments were used to pay off invoices and partially pay more than one scheduled payment and then reverse the payment (Account receivable > Customers > Transactions > Cancel payment).
The \Data Dictionary\Tables\SpecTrans table contains records for canceling the payment. Some records were inserted there two times by the \Classes\BankPaymCancel\reverseSettlement method.

•  Solution
The code has been modified to check the \Data Dictionary\Tables\SpecTrans table for the existence of the record before inserting it.

 \Classes\BankPaymCancel

Top


(Microsoft Dynamics AX 3.0) Cost accounting

Request No. KB Article No. Short Description Detailed Description Object Description
#16548 KB919338 The performance of Cost accounting Special calculation query was low. •  Problem
The performance of Cost accounting Special calculation query (Cost accounting > Inquiries > Special calculation query) was low. It took about thirty five minutes to execute this query and it blocked subsequent work.
The issue occurred because of unnecessary read/write operations in \Forms\COSBalancesDimHier\Methods\fillFirstTabPage.

•  Solution
The code has been modified to avoid unnecessary read/write operations.

 \Forms\COSBalancesDimHier\Methods\fillFirstTabPage()

Top


(Microsoft Dynamics AX 3.0) General ledger

Request No. KB Article No. Short Description Detailed Description Object Description
#829 Not available The Sales tax payment report showed incorrect information if the Include corrections check box was selected in the General ledger parameters form and the report layout was set to ‘English report layout’. •  Problem
The Sales tax payment report showed incorrect information if the Include corrections check box was selected on the Sales tax tab of the General ledger parameters form (General ledger > Setup > Parameters) and the report layout was set to ‘English report layout’ on the General tab of the Authority form (General ledger > Setup > Sales tax > Sales tax authorities).
The issue occurred because the Sales tax payment report was not designed to print corrections from the previous period. However, after Microsoft Dynamics AX 3.0 with Service Pack 3 (SP3), some modifications that enabled this report to be printed were implemented. Unfortunately, these changes did not cover the whole calculation process and the UK report provided the user with incorrect data when the report was run with the Include corrections check box selected in the General ledger parameters form.

•  Solution
The Sales tax payment report has been modified so that now it will not be printed with ‘English report layout’ set if the Include corrections check box is selected in the General ledger parameters form. The ‘Default’ report layout will be used if the Include corrections check box is selected.

 \Reports\TaxReport_UK\Methods\initAmounts
\Classes\TaxReportAdjustTrans\printout
\Classes\TaxReport_ReportUK\initFromArgs
#1540 Not available The journal became out-of-balance, if, in the multiline voucher, the user changed the Date field value and fixed another exchange rate for this date. •  Problem
The journal became out-of-balance, if, in the multiline voucher, the user changed the Date field value and fixed another exchange rate for this date.
The issue occurred because the information in the Total debit and Total credit fields was incorrectly refreshed.

•  Solution
The code has been modified so that the Total debit and Total credit fields are updated every time that the date is changed.

 \Classes\LedgerJournalEngine_Server\adjustDate
#1554 Not available In a multiline journal, the Account name/Offset account name fields obtained incorrect values if these fields had been moved to the grid. •  Problem
In a multiline journal, the Account name/Offset account name fields received incorrect values (all lines always displayed the account name/offset account name of a current line) if these fields had been moved to the grid.
The display methods for some fields in forms were assigned to the current record in the data source. This caused the fields to be displayed incorrectly when they were included in the grid.

•  Solution
A parameter has been added to retrieve the appropriate table record for calculating the correct value of the display method based on this record.

 \Data Dictionary\Tables\LedgerBudget\Methods\accountName
\Forms\LedgerJournalTransDaily\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransDaily\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransAsset\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransAsset\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransAssetBudget\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransAssetBudget\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransCustPaym\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransCustPaym\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransCustBillOfExchange\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransCustBillOfExchange\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransVendInvoice\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransVendInvoice\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransVendPaym\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransVendPaym\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
\Forms\LedgerJournalTransVendPromissoryNote\Data Sources\LedgerJournalTrans\Methods\accountName
\Forms\LedgerJournalTransVendPromissoryNote\Data Sources\LedgerJournalTrans\Methods\offsetAccountName
#3225 Not available The Trial balance report showed incorrect information about closing transactions if the period closing date differed from December, 31. •  Problem
The Trial balance report showed incorrect information about closing transactions if the period closing date differed from December, 31.
The issue occurred because during the closing balance calculation the system selected the closing transaction with the transaction date equal to 31.12.xx ignoring the fact that the closing transaction could have been performed on another day because of the period setup.

•  Solution
The CalcClosingBalance() method has been modified to select the closing transaction in accordance to the specificity of the period setup.

 \Reports\LedgerTrialBalance\Methods\CalcClosingBalance
#3894 Not available Copying a fixed asset was very slow if the number of fixed assets in the system was more than thirty thousand. •  Problem
Copying a fixed asset was very slow if the number of fixed assets in the system was more than thirty thousand.
The main method in the assetCopy class calls the assetCopy.run() method to create a duplicate record of an asset. After the record was created, the form needed to display the most current information and set the focus on the newly created record. To achieve this, the data source query was executed again. The call to formDataSource.executeQuery() rebuilds the filter, sorting and so on and re-executes the query, which slows the performance down.

•  Solution
To show the most recent data, the call to executeQuery has been replaced by the formDataSource.research() method, which is faster and achieves the intended result.

 \Classes\AssetCopy\main
#4130 Not available When posting a fixed asset transaction of the ‘Disposal – sales’ type, the transaction text entered in the Fixed assets journal was not transferred to the ledger voucher. •  Problem
When posting a fixed asset transaction of the ‘Disposal – sales’ type, the transaction text entered in the Fixed assets journal was not transferred to the ledger voucher.
The issue occurred because, in the AssetPostDisposal class, ledger voucher records were created by using the ledgerVoucherTransObject::newCreateTrans() method, but the ledgerVoucherTransObject.parmTransTxt() method was not called to add the journal text to the ledger voucher records.

•  Solution
A call to the ledgerVoucherTransObject.parmTransTxt() method has been added when ledger voucher records are created to add the journal text to the ledger voucher records.

 \Classes\AssetPostDisposal\post
\Classes\AssetPostDisposal\createAssetTrans
#4848 Not available Transactions with the Transaction text field empty, a cash discount specified and offset account set to ‘Bank’, ‘Customer’, and ‘Vendor’, were posted with an incorrect text. •  Problem
Transactions with the Transaction text field empty, a cash discount specified and offset account set to ‘Bank’, ‘Customer’, and ‘Vendor’, were posted with an incorrect text (a text from the discount transaction).
The algorithm of voucher posting used the lastTransTxt property of LedgerVoucherObject to store the previous value of the Transaction text field and used this value when it posted a set of transactions, which was logically united (for example, for posting the cash discount transaction). However, when a transaction with an empty transaction text was posted, the LedgerVoucherObject.AddTrans function could not differentiate whether the old set of transactions ended and the text of the previous transaction was set.

•  Solution
Code has been added to clear the transaction text in the voucher transaction object (used during posting) after the discount transaction has been posted.

 \Classes\CustVendSettle\postDiscTrans
#4872 Not available Manual postings on the use-tax payable account led to a difference in the Reconciliation sales tax/ledger report. •  Problem
Manual postings on the use-tax payable account led to a difference in the Reconciliation sales tax/ledger report (General ledger > Reports > Reconciliation > Sales tax).
There were two main queries in the report. One retrieved the ledger data, and the other retrieved tax data. The issue occurred because, in the ledger query, the use-tax payable offset account was omitted, although in the tax query it was expected.

•  Solution
The code has been modified to add the use-tax payable offset account when setting up a query.

 \Classes\TaxReport_LedgerReconciliation
#5842 Not available The calculation of depreciation was incorrect in the assetBalances report. •  Problem
The Depreciation column in the AssetBalances report showed the total of the depreciation value and depreciation adjustment value, although it should have also included the extraordinary depreciation value. Therefore, the calculation of depreciation was incorrect.
The issue occurred because the depreciationValue() method of the AssetBalances report returned the sum of the depreciation and the depreciation adjustment and did not add extraordinary depreciation.

•  Solution
The extraordinary depreciation value has been included in the calculation of depreciation. Now the depreciation column will reflect the sum of the depreciation, the depreciation adjustment, and extraordinary depreciation.

 \Reports\AssetBalances\Methods\depreciationValue
#6152 Not available When the user ran the depreciation proposal in the Fixed assets journal, the system dropped the voucher created when the user opened the journal. •  Problem
When the user ran the depreciation proposal in the Fixed assets journal, the system dropped the voucher created when the user opened the journal.
The issue occurred because the proposal functionality disregarded whether there were any unsaved vouchers in the journal and used the next voucher number.

•  Solution
The code has been modified to use the voucher created when the user created a journal in the following processing of the depreciation proposal.

 \Classes\AssetProposal\main
#6665 Not available A critical stop error occurred when the user changed Sales tax information in the Periodic journal with the Invoice number field filled in. •  Problem
A critical stop error occurred when the user changed Sales tax information in the Periodic journal with the Invoice number field filled in.
The issue was based on the cash discount calculation, which occurred when the user was using the Cust/Vend account with the Invoice number field filled in. The find method of custVendCashDiscList caused a critical stop error because object initialization was absent.

•  Solution
To resolve the issue, the CustVendCashDiscList initialization code has been added.

 \Classes\LedgerJournalEngine_LedgerPeriodic
#6822 Not available Deleting journal lines could lead to deleting incorrect journals. •  Problem
Deleting journal lines could lead to deleting incorrect journals. The issue was caused by the user using the last "Previously used query" functionality, which was not applicable for deleting journal lines.

•  Solution
The code has been corrected to prohibit the loading of the last-used query by default when the user is using the query editing functionality of the DeleteJournalLines dialog box.

 \Classes\LedgerJournalDeleteTransaction\classDeclaration
\Classes\LedgerJournalDeleteTransaction\new
#6982 Not available After the user posted the Fixed asset budget journal (or at least clicked the Posting button) and the Journal voucher form was closed, the number of a newly created journal duplicated the previous one. •  Problem
After the user posted the Fixed asset budget journal (or at least clicked the Posting button) and the Journal voucher form was closed, the number of a newly created journal duplicated the previous one.
The issue occurred because of an error in the clicked() method of the Posting menu button. The code that selected LedgerJournalTable and enabled/disabled buttons was put in an incorrect location and contained a mistake. For example, whenever the user clicked the Posting button, but did not actually post the transaction, the Depreciation proposal and Validate buttons were disabled.

•  Solution
The clicked() method has been modified and moved from the Posting menu button to its item buttons. These changes prevent the system from assigning existent voucher numbers to new vouchers.

 \Forms\LedgerJournalTransAssetBudget\Designs\Design\[ButtonGroup:ButtonGroup]\[MenuButton:AssetPosting]\MenuItemButton:AssetBudgetUpdate\Methods\clicked
\Forms\LedgerJournalTransAssetBudget\Designs\Design\[ButtonGroup:ButtonGroup]\[MenuButton:AssetPosting]\MenuItemButton:AssetBudgetUpdateAndTransferLedger\Methods\clicked
\Forms\LedgerJournalTransAssetBudget\Designs\Design\[ButtonGroup:ButtonGroup]\[MenuButton:AssetPosting]\Methods\clicked
#7410, 8152 Not available The Ledger transaction list report and the Sales tax specification by ledger transaction report showed incorrect tax amounts for sales tax transactions that were reversed because the settlement had used a cash discount. •  Problem
The Ledger transaction list report (General ledger > Reports > Transactions with the Sales tax specification check box selected) and the Sales tax specification by ledger transaction report showed incorrect tax amounts for the sales tax transactions that were reversed because the settlement had used a cash discount. The issue occurred only when two (or more) invoices that both had similar cash discounts and sales tax setups were settled with one payment and the general ledger parameters were set up to reverse sales tax on cash discounts.
The issue occurred because of incorrect references between the cash discount transaction and the reverse sales tax transaction.
Originally, the system regarded the payment transaction as a source transaction for the reverse sales tax on the cash discount transaction (because that cash discount was calculated only after the invoice was settled against the payment and therefore the payment was the source of the cash discount) and this was partially correct.
However, when several invoices (and therefore several cash discounts) had been settled upon one payment, the tax reference received the same recId value (payment transaction recId) for every reverse sales tax transaction. This led to the creation of tax transactions (with the same RefRecId, which was the most crucial point) that were identical for the Ledger transaction list and Sales tax specification by ledger transaction reports. Therefore the report retrieved both tax transactions for every invoice transaction and that was why tax amounts in the report were doubled.

•  Solution
The code has been modified to treat the invoice transaction as a source transaction for the reverse sales tax on cash discount transactions. Therefore, strict compliance will be achieved, because cash discount is applied to the invoice transaction. Because of the changed compliance logic, the paymentTableID and paymentRecId variables of the TaxCashDisc class have been renamed to cashDiscSourceTableId and cashDiscSourceRecId.

 \Classes\CustVendSettle\postCashDisc
\Classes\CustVendSettle\taxCashDisc
\Classes\TaxCashDisc\classDeclaration
\Classes\TaxCashDisc\calcAndPost
\Classes\TaxCashDisc\new
\Classes\TaxCashDisc\sourceRecId
\Classes\TaxCashDisc\sourceTableId
#8054 Not available The voucher allocation engine proposed to use voucher numbers that were already used. •  Problem
In the Import account statement (transactions) functionality, the voucher allocation engine proposed to use voucher numbers that were already used.
The allocation of new vouchers was performed by using the Make decision later option. However, this allocation was never confirmed or rejected. Therefore, vouchers with the same numbers could be allocated once again.

•  Solution
The voucher allocation engine has been corrected to perform voucher registration without using the Make decision later option.

 \Classes\LedgerInAccountStatement\loadVoucherNum
#8178 Not available The Tax deviation report disregarded the deviation value if the Deviations only option was used. •  Problem
The Tax deviation report disregarded the deviation value if the Deviations only option was used.
The Record validation engine used an incorrect condition. Therefore all deviation records were shown ignoring the minimum deviation percentage value.

•  Solution
The transaction selection criteria has been corrected to meet the report description.

 \Reports\TaxDeviation\Methods\send
#8566 Not available When the user was using the Breakdown of voucher functionality in the Journal voucher form, users under certain conditions had incorrect sales tax amount(s) after they clicked the Update button. •  Problem
When the user was using the Breakdown of voucher functionality in the Journal voucher form (go to Accounts payable > Journals > Invoices > Invoice journal, and then click Functions > Breakdown of voucher), users had incorrect sales tax amount(s) under certain conditions after they clicked the Update button.
Initially, in the process of updating the taxWorkRegulationLines and tmpLedgerJournalSplitLines temporary tables undergoes packing and unpacking. Note: these tables are linked by the taxWorkRegulationLines.headingRecId=tmpLedgerJournalSplitLines.recId relation. Then, while these tables are being unpacked, the new RecIds are assigned to the records, and they are supposed to be the same as before packing, but this was not the case. The above relation stopped working when the new RecId differed from the original RecId, which led to incorrect sales tax amount calculation in the \Classes\LedgerJournalSplitPosting\fillLedgerTrans method.

•  Solution
An additional adjusting block of code has been added when updating and transferring amounts from the temporary tables to the Journal voucher form.
The system will now save the original RecIds and restore them if the new ones differ from the original while unpacking the taxWorkRegulationLines table.

 \Classes\LedgerJournalSplitPosting\unpack
#8608 Not available Voucher numbers in the Ledger journal were incremented if the Continuous and Manual check boxes were cleared in the journal voucher number sequence setup. •  Problem
Voucher numbers in the Ledger journal were incremented if the Continuous and Manual check boxes were cleared in the journal voucher number sequence setup.
The issue was caused by a double call to the linkActive() method in the data source object of the ledgerJournalTransDaily form. Because the linkActive() method performs the preparation of the number sequence object to provide the journal with the next number, this method should be called one time.

•  Solution
The delayActive property of the LedgerJournalTable data source of the LegderJournalTable form has been set to ‘NO’. This way linkActive() on the ledgerJournalTrans data sources of the LedgerJournalTrans(*) form will be executed once.

 \Forms\LedgerJournalTable\Data Sources\LedgerJournalTable
#9055 Not available When the user was making a settlement and receiving a cash discount for a tax code that had exempt tax, the related to cash discount record was not created causing faulty reporting. •  Problem
When the user was making a settlement and receiving a cash discount for a tax code that had exempt tax, the related to cash discount record was not created. This caused faulty reporting.
The issue occurred because exempt sales taxes were not recorded.

•  Solution
The code has been modified to enable exempt sales tax recording.

 \Classes\TaxReverseTax\calcAndInsertTaxes
\Classes\TaxCashDisc\calcAndInsertTaxes
#9184 Not available When the user posted a project transaction line in the General journal with the Transaction text field filled in, the text of this field was not reflected on the ledger transaction. •  Problem
When the user posted a project transaction line in the General journal with the Transaction text field filled in, the text of this field was not reflected on the ledger transaction.
The issue occurred because the code for filling in ledger transaction with the transaction text according to the General journal line was missing.

•  Solution
The code for filling in ledger transaction with the transaction text according to the General journal line has been added.

 \Classes\ProjPost\postCost
#9368 Not available The total amount of split sales tax amounts exceeded the total sales tax amount. •  Problem
The total amount of split sales tax amounts exceeded the total sales tax amount. If a voucher was represented by several journal lines, the total tax amount of each journal line could differ from the total tax journal amount.
The issue occurred because of a mathematical calculation inaccuracy.

•  Solution
The code has been modified so that if a mathematical calculation difference exists and the journal has the Amount in the journal includes sales tax check box selected, the sales tax amount and the sales tax base amount of the journal line with the largest expense amount will be adjusted.
Because the tax calculation is performed for each journal line separately, the aforementioned code modifications impact the sales tax calculation performance. This occurs when recalculating taxes for the whole voucher when the largest expense line is processed. Therefore, this recalculation will be performed only when the posting is performed.

\Classes\TaxLedgerJournal\calcAndPost
\Classes\TaxLedgerJournal\loadRoundingDiff
#9600 Not available Sales tax was incorrectly calculated when a fixed exchange rate was used. •  Problem
Sales tax was incorrectly calculated when a fixed exchange rate was used. The sales tax was always calculated with the current exchange rate, after that the tax records were adjusted line by line using the predefined fixed exchange rate. In this situation, the total rounding difference could have been inappropriate.
The issue occurred because the line by line tax adjustment method could generate unacceptable rounding differences in the total.

•  Solution
The tax amount adjustment engine has been modified to use the total by tax code adjustment method.

 \Classes\Tax\adjustAmount
\Classes\Tax\adjustAmountData
\Classes\Tax\adjustAmountLine
#9626 Not available Incorrect sales tax calculation with the following rounding led to an error while the user was posting orders. •  Problem
Incorrect sales tax calculation with the following rounding led to an error while the user was posting orders. If the currency rounding was set to decimals and the price included sales tax, an incorrect origin amount was calculated, which led to an error and posting was interrupted.
The baseAmountExclTax() method of the Tax class, which calculates the amount origin, performed incorrect calculation of the base amount. The tax amount was calculated based on the rounded base amount excluding tax. After that the whole order amount was subtracted from the tax amount. Therefore, an incorrect tax base amount was calculated.

•  Solution
The code has been modified to correct the calculation and rounding of the real tax base amount and not on the rounded amount.

 \Classes\Tax\baseAmountExclTax
#9886 Not available The Sales tax payment report (in the UK layout) ignored the From date parameter. •  Problem
The Sales tax payment report (in the UK layout) ignored the From date parameter.
The issue occurred during the initialization of the taxPeriodCountry variable in \Reports\TaxReport_UK\Methods\initAmounts. The Nulldate() value was used instead of the defined From date parameter.

•  Solution
The code of \Reports\TaxReport_UK\Methods\initAmounts has been corrected to initialize taxPeriodCountry using the From date parameter.

 \Reports\TaxReport_UK\Methods\initAmounts
#10038 Not available The Approved and Approved by fields remained blank if the Load ledger transaction engine was used. •  Problem
The Approved and Approved by fields remained blank if the Load ledger transaction engine was used.
The issue occurred because the code responsible for filling in the mentioned fields was missing in the Load ledger transaction engine.

•  Solution
The Load ledger transaction engine has been corrected to set the Approved by field to the current user ID.

 \Classes\LedgerJournalGetTrans\updateNow
#10080 Not available When the user ran the Import account statement in a 3-tier configuration of Microsoft Dynamics AX 3.0, an incorrect value for the bridging account was used. •  Problem
When the user ran the Import account statement in a 3-tier configuration of Microsoft Dynamics AX 3.0, an incorrect value for the bridging account was used.
When the LedgerInAccountStatement (or its descendant) was run on the server it should pack the data and transfer it to the client to open the appropriate dialog box. The packing of data was made by the standard pack method, but the structure used to store the class information did not contain enough information to construct the object on the client.

•  Solution
The packing list for the pack/unpack operation has been extended for the transactions grouping mode and import method values. To avoid the system loading the last used values while creating the dialog box, the Main method of the LedgerInAccountStatement class has been extended with a call to the getLast method before initialization.

 \Classes\LedgerInAccountStatement\classDeclaration
\Classes\LedgerInAccountStatement\unpack
\Classes\LedgerInAccountStatement\main
\Menu Items\Action\LedgerInAccountStatementTrans
#10355 Not available An incorrect account number was shown in the Ledger journal report for transactions where Account type was set to ‘Project’. •  Problem
An incorrect account number was shown in the Ledger journal report for transactions where Account type was set to ‘Project’.
The issue occurred because the break statement was missing in the \Reports\LedgerJournal\Methods\AccountNum method.

•  Solution
To resolve the issue, the break statement has been added in line 22 of the \Reports\LedgerJournal\Methods\AccountNum method.

 \Reports\LedgerJournal\Methods\AccountNum
#10529 Not available The acquisition value was not reduced for a cash discount if the user posted an invoice with several fixed assets. •  Problem
The acquisition value was not reduced for a cash discount if the user posted an invoice with several fixed assets.
The Cash discount allocation engine was unable to process several fixed assets per invoice. In this situation only the acquisition value of the first fixed asset was reduced for a cash discount.

•  Solution
The Cash discount allocation engine has been corrected to process several fixed assets per invoice.

 \Classes\CustVendSettle\postDiscTrans
#11285 Not available The consistency check analysis created imbalances between the LedgerTrans and Balances tables. If a voucher was not balanced, the consistency check routine created a new ledger transaction to balance it, but the Balances tables were not updated. •  Problem
The consistency check analysis created imbalances between the LedgerTrans and Balances tables. If a voucher was not balanced, the consistency check routine created a new ledger transaction to balance it, but the Balances tables were not updated.

•  Solution
The balance update code has been added to resolve this issue.

 \Data Dictionary\Tables\LedgerTrans\Methods\checkFixBalance
#11472 Not available Deviation between tax and ledger transactions appeared when the user posted a purchase order with a currency different from the main company currency. •  Problem
Deviation between tax and ledger transactions appeared when the user posted a purchase order with a currency different from the main company currency.
There was a balance procedure in the tax module that distributes the whole tax amount in the main company currency among lines in sales/purchase orders. However, there was a lack of this procedure in the ledger module. Therefore, changes that were made by the balance procedure in the tax module were not reflected in the ledger module.

•  Solution
To retrieve the same tax amounts on ledger transactions, the exchange rate will be calculated by using tax amounts in a currency and the main company currency calculated in the tax module while the user is posting ledger transactions.

 \Classes\Tax\saveAndPost
\Classes\TaxFreeInvoice_Invoice\post
\Classes\TaxProjInvoice\post
\Classes\TaxPurchInvoice\post
\Classes\TaxReverseTax\post
\Classes\TaxSalesInvoice\post
\Classes\TaxSettlement\saveAndPost
\Classes\TaxReverseTax\postAdjust
\Classes\TaxReverseTax\saveAndPost
\Classes\TaxReversePrePayment\calcPostAndInsertTaxes
\Classes\TaxLedgerJournal\saveAndPost
\Classes\TaxCashDisc\saveAndPost
#11476 Not available The fee ledger journal line was not populated with the dimension information when the user changed the dimension in the main journal line. •  Problem
The fee ledger journal line was not populated with the dimension information when the user changed the dimension in the main journal line.
When a ledger journal line for a fee transaction had been created no consequent updates were performed with the fee information. When the user changed or entered the dimension information in a journal line, fee journal lines were not filled with this information.

•  Solution
Necessary modifications have been made so that the fee ledger journal lines are updated if the dimension information has been changed on the main journal line.

 \Classes\LedgerJournalEngine\write
\Classes\LedgerJournalEngine\updateFeeLedgerTrans
#11489 Not available DB/CR requirements were violated when the user posted a sales order with mixed lines if the Credit note as correction option was used. •  Problem
DB/CR requirements were violated when the user posted a sales order with mixed lines (credit notes and normal lines) if the Credit note as correction option was used.
The issue was based on the storno mark usage, which was applied only if order amount was negative. If a credit note line was present in the order with the positive amount, the storno mark was not applied, because the resulting posting to a ledger account did not fit the requirements.

•  Solution
The UpdateNow method of the SalesFormLetter_Invoice and PurchFormLetter_Invoice classes has been updated to determine the storno mark for each line.

 \Classes\SalesFormLetter_Invoice\initJournalLineLedger
\Classes\SalesFormLetter_Invoice\updateCreditNoteStatus
\Classes\SalesFormLetter_Invoice\updateNow
\Classes\PurchFormLetter_Invoice\initJournalLineLedger
\Classes\PurchFormLetter_Invoice\updateCreditNoteStatus
\Classes\PurchFormLetter_Invoice\updateNow
#11819 Not available An incorrect sales tax base amount was posted in the tax module if the Invoice journal had the Amount in the journal includes sales tax check box selected, the Use-tax check box selected for the sales tax group and the user adjusted sales tax amount. •  Problem
An incorrect sales tax base amount was posted in the tax module if the Invoice journal had the Amount in the journal includes sales tax check box selected, the Use-tax check box selected for the sales tax group and the user adjusted sales tax amount.
The issue occurred because of an error in the method that performed the tax amount regulation. Whenever the amount in the journal included sales tax and the sales tax origin had nothing to do with the amount per unit calculation, the base amount was always recalculated because of the latest sales tax amount adjustment.

•  Solution
The sales tax base amount recalculation will be prevented if the processed sales tax has the Use-tax origin.

 \Classes\TaxLedgerJournal\taxAmountRegulation
#11923 Not available The database stored references on transactions that were removed, even after the user removed the consolidation history. •  Problem
The database stored references on transactions that were removed, even after the user removed the consolidation history.
When consolidation was performed twice or more times, Microsoft Dynamics AX 3.0 deletes ledger transactions (but not reference ledgerConsolidateHistRef transactions) from the previous consolidations. When the user removed transactions from the consolidation history, the system deleted only those reference records that had ledger links. Because the second consolidation deleted these ledger transactions, no reference transactions were deleted.

•  Solution
The delete action has been created on \Data Dictionary\Tables\LedgerConsolidateHist to keep reference integrity. Also, the \Classes\ReleaseUpdateDB_V30toV30SP\updateConsolidationHistory method has been added to the Upgrade check list to clean up the old transactions in the database.

 \Classes\ReleaseUpdateDB_V30toV30SP\initJobs
\Classes\ReleaseUpdateDB_V30toV30SP\updateConsolidationHistory
\Data Dictionary\Tables\LedgerConsolidateHist\DeleteActions\LedgerConsolidateHistRef
#12061 Not available If the journal account number of the ‘Vendor’ or ‘Customer’ account type was changed, recalculation of the due date did not allow for the document date that was set before. •  Problem
If the user set the document date (therefore the due date was recalculated respectively) and after that changed the Vendor/Customer account, the due date was recalculated based on the terms of payment for a new Vendor/Customer account without allowing for the already specified document date.
The issue occurred because, when the user changed Vendor/Customer account, a new due date was calculated considering only terms of payment that was populated from the Customer/Vendor setup. However, the document date should have also been considered when a Customer/Vendor account was changed.

•  Solution
The code has been modified to allow for the terms of payment and the document date while it calculates the due date if the specified Customer/Vendor account is changed.

 \Classes\LedgerJournalEngine\initFromCustTable
\Classes\LedgerJournalEngine\initFromVendTable
\Classes\LedgerJournalEngine_CustBillOfExchange\initFromCustTable
\Classes\LedgerJournalEngine_CustPayment\initFromCustTable
\Classes\LedgerJournalEngine_VendInvoice\initFromVendTable
\Classes\LedgerJournalEngine_VendInvoicePool\initFromVendTable
\Classes\LedgerJournalEngine_VendInvoiceRegister\initFromVendTable
\Classes\LedgerJournalEngine_VendPayment\initFromVendTable
\Classes\LedgerJournalEngine_VendPromissoryNote\initFromVendTable
#12257 Not available The bar code output was not formatted correctly in the Fixed asset bar codes report. •  Problem
The bar code output was not formatted correctly in the Fixed asset bar codes report (General ledger > Reports > Base data > Various > Fixed asset bar codes). The bar code output required that the data used for the bar code was encoded for a specific bar code type before printing. In the Fixed asset bar codes report, the bar code information about an asset (ASCII string) was sent directly to the printer without any encoding.
The issue occurred because the bar code data of an asset was output without being formatted as a bar code.

•  Solution
In order to correctly format the bar code of an asset for output, the user will be provided with the means of selecting one bar code format as part of the Fixed asset bar codes dialog box interface. The selected format will be applied to the bar code data for each asset selected for printing.
The report will validate and print the bar code data of an asset using the Microsoft Dynamics AX 4.0 bar code formats created from Code128, Code39, and Interleaved 2 of 5. The report will use the existing Microsoft Dynamics AX 4.0 bar code validation for these formats.

\Data Dictionary\Tables\BarcodeSetup
\Classes\AssetReport_Barcode
\Reports\AssetBarcode
#12562 Not available When a budget depreciation proposal was run for an asset that had several budgeted acquisitions in different periods, the depreciation was the same for all periods. It was calculated from the total of acquisitions.

When a fixed asset had real and budgeted acquisitions, only the real ones were considered when calculating budget depreciations.		 •  Problem
When a budget depreciation proposal was run for an asset that had several budgeted acquisitions in different periods, the depreciation was the same for all periods. It was calculated from the total of acquisitions.

When a fixed asset had real and budgeted acquisitions, only the real ones were considered when calculating budget depreciations.

The code for determining the correct amount to depreciate for proposal depreciation transactions in the \Classes\AssetTableMethod\setAmountToDepreciate method was incorrect. It summarized all available acquisition type budget transactions instead of allowing for a date restrictive result. Additionally, the total returned did not allow for the other transaction types that can affect the total amount to depreciate for an asset.

•  Solution
The code in \Classes\AssetTableMethod\setAmountToDepreciate has been corrected to call the new \Data Dictionary\Tables\AssetBudget\Methods\AmountToDepriciate method that will in turn call another new \Data Dictionary\Tables\AssetBudget\Methods\AmountMSTPerDateTranstype method. These new methods will correct the date restrictive and transaction type omission problems.

 \Data Dictionary\Tables\AssetBudget
\Classes\AssetTableMethod
#12566 Not available The Reconciliation bank/ledger report showed the difference between the Ledger balance and Bank balance when deposit slips were used. •  Problem
The Reconciliation bank/ledger report showed the difference between the Ledger balance and Bank balance when deposit slips were used.
The issue occurred because the deposit slip transactions appeared in the selection from the Bank transaction table, which was incorrect.

•  Solution
Deposit slip transactions have been excluded from the Reconciliation bank/ledger report.

 \Classes\BankReport_LedgerReconciliation\bankTrans
#12691 Not available In the post and transfer functionality, if account type was not ‘Ledger’, the Account field was empty and the journal contained several correctly filled lines, the correct lines were never posted. •  Problem
In the post and transfer functionality, if account type was not ‘Ledger’, the Account field was empty and the journal contained several correctly filled lines, the correct lines were never posted.
The issue occurred because the system displayed an error message if no customer account (or any except ‘Ledger’) was present in the journal line. That was why the posting routine aborted without information about how many incorrect lines were present in the journal. Without this information, the correct lines could not be posted.

•  Solution
The code has been modified to call checkJournal(), which will insert incorrect vouchers in voucherErrorList. Therefore, vouchers from voucherErrorList will be ignored during posting and transferred to a new journal. Also, the Invoice journal has been corrected to update the journal after posting and transfer.

\Classes\LedgerJournalCheckPost\checkJournal
\Classes\LedgerJournalCheckPost\isVoucherInErrorList
\Classes\LedgerJournalCheckPost\numOfVouchersBooked
\Classes\LedgerJournalCheckPost\postJournal
\Classes\LedgerJournalCheckPost\run
\Classes\LedgerJournalCheckPost\totalVoucher
\Classes\LedgerJournalCheckPostApproval\checkJournal
\Classes\LedgerVoucher\classDeclaration
\Classes\LedgerVoucher\check
\Classes\LedgerVoucher\getErrorList
\Classes\LedgerVoucher\new
\Forms\LedgerJournalTransVendInvoice\Designs\Design\[ButtonGroup:ButtonGroup]\[MenuButton:Posting]\MenuItemButton:LedgerJournalPostTransfer\Methods\clicked
#12810 Not available The Sales tax specification report displayed doubled figures for project invoices posted with several lines. •  Problem
The Sales tax specification report displayed doubled figures for project invoices posted with several lines.
When the user posted two (or more) project invoices with one voucher number in the same currency within equal dimensions, the posting routine created two (or more) identical tax transactions. Therefore the Sales tax specification report selected the whole bunch of tax transactions for each invoice.

•  Solution
The code has been modified to make tax references more detailed. The detailSummary variable of the TaxReference object is now equal to ‘Detail’ when the Transactions by project parameter (Project > Parameters) is set to ‘Line’; and if the Summary parameter is mentioned, it is set to ‘Total’.

 \Classes\TaxProj\new
#12828 Not available It was not possible to set the New voucher field in the Journal setup form to ‘In connection with balance’ if the user previously changed the default value of this field. •  Problem
It was not possible to set the New voucher field in the Journal setup form (General ledger > Setup > Journal names) to ‘In connection with balance’ if the user previously changed the default value of this field. An Infolog error message was shown noting that the New voucher field should only be set to ‘Manual’.
The issue occurred because the code in the Validate method of the New voucher field (in the data source of the LedgerJournalSetup form) verified that New voucher was ‘Manual’ when Journal type was ‘Approval’.

•  Solution
The verification in the Validate method of the New voucher field has been changed from ‘Manually’ to ‘BalanceSheet’ (in the data source of the LedgerJournalSetup form) when the journal type is ‘Approval’.

 \Forms\LedgerJournalSetup\Data Sources\LedgerJournalName\Fields\NewVoucher\Methods\validate
#12852 Not available The performance of the General journal was poor while it was accepting bridged transactions, if there were many journal transactions stored in the database. •  Problem
The performance of the General journal was poor while it was accepting bridged transactions if there were many journal transactions stored in the database.
The issue was caused by the Ledgertrans2LedgerjournalTrans method that used the select statement in the Ledgertransfurtherposting table. Therefore, a full table scan was performed.

•  Solution
The index for the furtherpostingrecid field has been created on the LedgerJournalTrans table. Also, the select statement has been corrected in the LedgerTrans2LedgerJournalTrans method of the LedgerTransFurtherPosting table, which uses this index.

 \Data Dictionary\Tables\LedgerJournalTrans\Indexes\FurtherPostingIdx
\Data Dictionary\Tables\LedgerTransFurtherPosting\Methods\LedgerTrans2LedgerJournalTrans
#12887 Not available The Sales tax direction option for the ledger account was ignored when the tax-code posting occurred in a journal with the Sales tax direction check box selected. •  Problem
The Sales tax direction option for the ledger account was ignored when the tax-code posting occurred in a journal with the Sales tax direction check box selected.
The issue occurred because, when the journal transaction for a single tax-code was posted, no tax direction setup for a ledger account was used if the Sales tax direction check box was selected.

•  Solution
The tax calculation procedure has been modified to take the ledger account setup (the Sales tax direction option) into account.

 \Classes\TaxLedgerJournal\vatTransactionDirection
#12888 Not available Data changes that were made to the details on an asset depreciation profile were not always reflected in the Asset book form. •  Problem
Data changes that were made to the details on an asset depreciation profile were not always reflected in the Asset book form.
The issue occurred because the code in the \Forms\AssetBook\Data Sources\AssetBook\Methods\active method was only updating the form if the asset depreciation profile(s) was changed or if the profile’s "method" was changed. Unfortunately the details (asset accrual, depreciation year) of the "method" can be changed without actually changing the "method". Therefore, the displayed details did not accurately reflect the asset depreciation profiles current data.

•  Solution
The code that synchronizes the selected asset book in the Asset book form has been modified to update the form with all the changes that could have occurred to the asset depreciation profile details.

 \Forms\AssetBook
#13098 Not available The voucher number was duplicated when the exchange adjustment was performed over some ledger accounts and the last account being adjusted did not generate any transactions. •  Problem
The voucher number was duplicated when the exchange adjustment was performed over some ledger accounts and the last account being adjusted did not generate any transactions.
In this situation the original voucher was posted, but because the last account being adjusted did not generate any transactions, the system regarded this voucher as empty and released its number. This means that the same voucher number could be used in the next adjustment.
The run() method of the LedgerExchAdj class has the foundDiff Boolean variable that controls whether the exchange adjustment occurred or not. Unfortunately the foundDiff variable stored information only about the last account processed. That was why, if the last account did not need any adjustment, the voucher number was released, even though other accounts could have had adjustments. Because foundDiff stored the FALSE value (because the last processed account did not need adjustment), the system released the voucher number and considered that no adjustment was done.

•  Solution
The adjustment routine has been modified to store the correct information about the voucher that was already used. The foundDiff variable will be set to TRUE if any of the accounts is adjusted.

 \Classes\LedgerExchAdj\run
#13472 Not available An incorrect MST amount was posted to a ledger account during an intercompany posting. •  Problem
An incorrect MST amount was posted to a ledger account during an intercompany posting. When the main ledger journal account was identified as an intercompany one with a currency that had different exchange rates, the current company transactions that should have been posted in the current company were done with an incorrect MST amount.
During the intercompany vendor selection (when the user selects vendor on the journal line where the Company accounts field was filled in with the inter company name), the Exchange rate field was also updated together with other fields.
The issue was that when the journal account was an intercompany account, the Exchange rate field was filled in with the exchange rates relevant to the company that the mentioned vendor originated from.
The issue became apparent when current company transactions were posted to a ledger account that had the exchange rate from the Ledger journal line which was incorrect, because the mentioned exchange rate represented another company’s exchange rate setup.

•  Solution
The MST amount recalculation during posting has been corrected in order to have correct MST amounts in the current company.

 \Classes\LedgerJournalEngine\accountModified
#14223 Not available The corrected sales tax value in a ledger transaction could be damaged if the user clicked the Previous or Next button on the tab other than Overview. •  Problem
The corrected sales tax value in a ledger transaction could be damaged if the user clicked the Previous or Next button on the tab other than Overview.
The issue was based on the corrected sales tax value updating performed only when the appropriate text box was displayed (this text box is located on the Overview tab), although in other situations the local value contained the amount of the last viewed corrected sales tax. Therefore, when the record was written, this local value was applied to the current record.

•  Solution
The Active method of the LedgerJournalTrans data source has been updated to invoke the local value of the corrected sales tax amount recalculation. Now, regardless of what tab is active, the local corrected sales tax amount will always contain the correct value.

 \Forms\LedgerJournalTransDaily\Data Sources\LedgerJournalTrans\Methods\active
#14323 Not available The tax information for posted fixed asset transactions was not displayed in the Ledger transaction list report. •  Problem
The tax information for posted fixed asset transactions was not displayed in the Ledger transaction list report (General ledger > Reports > Transactions > Ledger transaction list).
The issue occurred because during the posting the tax reference was missing. When the sales tax is being posted, the taxReference class keeps ledgerJournalTrans.recId for a tax reference, but when a fixed asset transaction was to be posted, assetTrans.recId was passed to the voucher to create the tax reference. That was why the relation between sales taxes and fixed asset transactions was lost and therefore the tax information was not displayed in the report.

•  Solution
The code has been modified to pass ledgerJournalTrans.recId for creating the tax reference when the posting routine deals with the main (not derived) fixed asset transaction.

 \Classes\AssetPost\post
\Data Dictionary\Tables\AssetBookTableDerivedJournal\Methods\existRefRecId
#14659 Not available The LedgerVoucherBalancesList table was not updated with the Quantity value entered in the Ledger journal line. •  Problem
The LedgerVoucherBalancesList table was not updated with the Quantity value entered in the Ledger journal line.
The issue occurred because the line of code in the write method responsible for transferring the Quantity value to the LedgerVoucherBalancesList table was missing.

•  Solution
The write method of the LedgerVoucherBalancesList class has been updated to save the Quantity value.

 \Classes\LedgerVoucherBalancesList\write
#14847 Not available Incorrect information was displayed in the Sales tax specification by ledger report after posting a sales or purchase order if this order had two (or more) miscellaneous charges transactions with the same sales taxes for both. •  Problem
Incorrect information was displayed in the Sales tax specification by ledger report after posting a sales or purchase order if this order had two (or more) miscellaneous charges transactions with the same sales taxes for both. If miscellaneous charges codes were set to debit (if there was a purchase order) or credit (if there was a sales order) and the same ledger account, but with different posting types, incorrect information was displayed in the report.
The miscellaneous charges transactions did not merge into one record in the ledger transaction table because these transactions had the same account but different posting types.
Therefore, there were ledger transactions with the same account number, but different posting types. And, when the tax engine processed these transactions to calculate taxes, it detected the same operation account and the same sales tax group and item tax group settings. Therefore, it merged tax transactions into one. Therefore, the Sales tax specification by ledger report retrieved the same, common for both, tax transaction for each ledger transaction. Therefore, the report contained doubled tax information.

•  Solution
The code has been modified to update the sales tax reference if the originating transactions were not merged. Therefore, unnecessary merging is avoided.

 \Classes\Markup\updateTaxReferenceOnMarkupTrans
\Classes\Markup\postInvoiceAmount
\Classes\Tax\updateTaxWorkTransRefRecId
\Classes\TaxReference\parmDetailSummary
#15429 Not available Creating a depreciation proposal for many fixed assets was extremely slow. •  Problem
Creating a depreciation proposal for many fixed assets was very slow. Performance appeared to decrease as it progressed in the process. For example, when a depreciation proposal was generated for 65,000 assets that had one value model and used Straight Line depreciation, the first 30,000 assets would be processed in approximately one hour. Processing the remaining 35,000 would take approximately four hours. Toward the end of the process, the system was only processing around 150 assets per minute.
The issue occurred because depreciation was made within one transaction, and all the data was stored in the computer memory until the transaction was committed.

•  Solution
The ttsbegin and ttscommit operators have been added within the loop, which makes a number of short transactions instead of one huge transaction. The code change will commit the transaction every time that 1,000 journal lines are created and the asset/book changes.

 \Classes\AssetProposalDepreciation\run
#16090 KB918341 A journal line could be posted with a duplicate voucher number within one fiscal year even if the Reject copy within fiscal year ledger parameter was selected. •  Problem
A journal line could be posted with a duplicate voucher number within one fiscal year even if the Reject copy within fiscal year ledger parameter was selected.
The issue occurred because the incorrect date was identified as the start date of the period. Instead of the first date of the fiscal year this date was assigned to the first date of the current period within one fiscal year. In other words, if the fiscal year ‘January, 01 2006 – December, 31 2006’ was divided into twelve months and the transaction date was, for example, ‘March, 15 2006’, the fromDate() date variable would have been be assigned to ‘March, 01 2006’ instead of ‘January, 01 2006’.

•  Solution
The verification procedure with the correct date has been added to prevent posting a voucher if a voucher with the same number has been already posted within the same fiscal year and the Reject copy within fiscal year ledger parameter was selected.

 \Data Dictionary\Tables\LedgerParameters\Methods\checkDuplicate
#16231 Not available Posting an intercompany invoice did not include the sales tax amount when the user posted ledger transactions in the original company. •  Problem
Posting an intercompany invoice did not include the sales tax amount when the user posted ledger transactions in the original company.
The issue occurred because the analyseVoucher method of the TaxVoucherService class did not calculate the intercompany sales taxes. Therefore, ledger transactions in the original company were never adjusted with the tax amount.

•  Solution
The code has been modified to include intercompany taxes into the original transaction amount.

 \Classes\LedgerJournalCheckPost\postTrans
\Classes\LedgerJournalTransUpdateLedger\updateNow
\Classes\TaxVoucherService\classDeclaration
\Classes\TaxVoucherService\analyseVoucher
\Classes\TaxVoucherService\mapAmount
\Classes\TaxVoucherService\mapAmountInvertSign
\Classes\TaxVoucherService\new
\Classes\TaxVoucherService\postTaxOnErrorAccount
\Classes\TaxVoucherService\taxAmountPrePayment
\Classes\TaxVoucherService\taxAmountToPost
\Classes\TaxVoucherService\updateMapAmount
#16251 Not available Sales tax settlement transactions were posted and printed incorrectly if they had a penny difference amount or when the sales transactions originated from the credit note transaction. •  Problem
Sales tax settlement transactions (adjustment transactions that originated in the period that was already tax-settled) were posted and printed incorrectly if they had a penny difference amount or when the sales transactions originated from the credit note transaction.
The issue with the incorrect posted penny difference amount occurred in the calcAdjustments() method of the TaxCalcBASFields class where the condition statement prohibited the adjustment (tax transaction from the previous period) calculation when the user selected the Post and settle GST check box.
The incorrect printing and posting sales tax transactions that originated from the credit notes were caused by using the ABS() function in the BAS calculation. That was why the system regarded the credit note’s taxes as normal (to the current module) taxes and therefore printed and posted tax transactions with the positive sign, which led to incorrect amounts in the BAS report. Also, sales tax settlement amounts were incorrect.

•  Solution
The Sales tax settlement procedure has been corrected for the BAS report to have the correct penny difference transactions (if any) and correct sales tax settlement amounts if the sales tax originated from the credit note transaction. Also, the signed value will be used in the report and settlement amount calculation.

 \Data Dictionary\Tables\TaxTrans\Methods\taxAmountByTaxDirectionAndReportId
\Classes\TaxReport_AU\settleOtherAmounts
\Classes\TaxCalcBASFields\addAdjustment
\Classes\TaxCalcBASFields\calcAdjustments
\Classes\TaxCalcBASFields\calcTotalsAndRound
#16264 Not available The Fixed asset note report printed incorrect information if the assets transaction details included transactions for disposal or scrap. •  Problem
The Fixed asset note report printed incorrect information if the assets transaction details included transactions for disposal or scrap. The ‘Opening’ and ‘Closing’ balances for the asset appeared in the report for the year next to the year the asset was scrapped or sold in.
The \Classes\AssetReport_BalanceReportColumns\columnAdjStartPeriod() method had an error in the code that caused the ‘WriteUp’ and ‘WriteDown’ adjustment amounts for the asset’s prior years to be included two times in the method’s arithmetic statement.

•  Solution
The duplicate code lines have been removed from \Classes\AssetReport_BalanceReportColumns\columnAdjStartPeriod().

 \Classes\AssetReport_BalanceReportColumns
#16304 Not available The system did not automatically generate bar codes when the user created a new fixed asset. •  Problem
The system did not automatically generate bar codes when the user created a new fixed asset. When the system generated a fixed asset, the bar code number was blank even if the bar code sequence was specified for the group.
New assets are set up using the AssetTable form. When a new record is created, the create() method on the data source is invoked, and, in the create method, the logic initializes the bar code number. But at this point the asset group was not yet selected. Therefore, no bar code numbers are generated. If the user selected the group and saved the record, the write() method was called. The write() method did not contain the code to initialize the bar code numbers and the record was saved without the bar codes. Also, the write method did not initialize bar codes to asset number if assetParameters.barcodeEqualsAssetNumber was set.

•  Solution
The code has been modified to assign a bar code to a newly created fixed asset automatically.

 \Forms\AssetTable\Methods\ClassDeclaration
\Forms\AssetTable\Data Sources\AssetTable\Methods\write
\Forms\AssetTable\Data Sources\AssetTable\Methods\create
#16710 Not available An asset with the Straight line depreciation calculation method could not be fully depreciated if the Round-off depreciation feature of the fixed asset value model was used. •  Problem
An asset with the Straight line depreciation calculation method could not be fully depreciated if the Round-off depreciation feature of the fixed asset value model was used. The most common result was a final depreciation amount that resulted in a negative net book value position.
The \Classes\AssetTableMethod_SL\calc() method performed validation for the occurrence of the last depreciation, but it did not verify whether that depreciation amount created a negative net book balance.

•  Solution
The Straight line depreciation calculation method has been corrected to prevent the over-depreciation of an asset.

 \Classes\AssetTableMethod_SL
#16915 KB919147 The Annual sales tax report showed an incorrect sales tax amount when the user was using a tax value adjustment. •  Problem
The Annual sales tax report showed an incorrect sales tax amount when the user was using a tax value adjustment.
The issue was caused by the Invoice journal creating engine which disregarded the sales tax amount adjustments.

•  Solution
The incorrect tax amount in the Annual sales tax report was based on the incorrect SumTax calculation. SumTax was calculated basing on the calcTaxonInvoice static method of the LedgerJournalTrans class, which disregarded the sales tax manual adjustments. Now the TaxTotal static method of the Tax class is used to correctly calculate the sales tax value. The code has also been corrected to separate the calculation of tax amounts for lines with and without adjustments instead of summing these values.

 \Classes\CustVoucher\createInvoiceJournal
\Classes\Tax\taxTotal
#16969 Not available When the Fixed assets journal with a transaction of the ‘Acquisition’, ‘Acquisition adjustment’ or ‘Transfer from reserve’ type of was posted, the acquisition date on the asset was updated with the journal transaction date. •  Problem
When the Fixed assets journal with a transaction of the ‘Acquisition’, ‘Acquisition adjustment’ or ‘Transfer from reserve’ type of was posted, the acquisition date on the asset was updated with the journal transaction date. The acquisition date should only be updated when the transaction type is ‘Acquisition’.
The issue occurred because of a mistake in the code.

•  Solution
The posting code has been changed to only update the acquisition date when the user is posting transactions of the ‘Acquisition’ type.

 \Classes\AssetPost\Post
#17422 KB922824 Splitting the invoice by using the Breakdown of Voucher functionality could cause incorrect journal amounts and sales taxes calculation. •  Problem
Splitting the invoice by using the Breakdown of Voucher functionality could cause incorrect journal amounts and sales taxes calculation.
The issue occurred because the sales tax adjustment was always performed for the last line of the split voucher.

•  Solution
The code has been corrected to adjust the transaction with the maximum amount.

 \Classes\LedgerJournalSplitPosting\updateLedgerJournal
#17470 KB920796 Duplicate voucher numbers were generated in Microsoft Dynamics AX 3.0. •  Problem
Duplicate voucher numbers were generated in Microsoft Dynamics AX 3.0. This occurred if there were one saved and some unsaved journal lines with the same voucher. In this situation the deletion of the last saved line marked the voucher as free and disregarded that unsaved lines still used this voucher. Therefore, a journal line created by another user could use the same voucher number.
The delete method of the LedgerJournalTrans table released the voucher number if other transactions with the same voucher were absent. However, this method did not check the data source for the unsaved records that could also use the same voucher number.

•  Solution
The delete method of the LedgerJournalTrans table has been corrected to find the unsaved record with the same voucher in the form data source, and if it exists, mark this voucher as "Active". The formMethodDataSourceWrite method of the NumberSeqFormHandlerLedgerJournal class has been corrected to remove the appropriate voucher from the pool when a transaction turned into the saved state.

 \Data Dictionary\Tables\LedgerJournalTrans\Methods\deleteVoucher
\Data Dictionary\Tables\LedgerJournalTrans\Methods\checkVoucherNotUsedDataSource
\Classes\NumberSeq\markAsActive
\Classes\NumberSeq\markAsUsed
\Classes\NumberSeqFormHandlerLedgerJournal\formMethodDataSourceDelete
\Classes\NumberSeqFormHandlerLedgerJournal\formMethodDataSourceWrite
#17515 KB920888 The Ledger transaction list report did not show the sales tax specification for the ledger transactions of a fixed asset created by the vendor Invoice journal if the Amount in the journal includes sales tax check box was selected. •  Problem
The Ledger transaction list report did not show the sales tax specification for the ledger transactions of a fixed asset created by the vendor Invoice journal if the Amount in the journal includes sales tax check box was selected.
The issue occurred because of an incorrect determination of the operation account for the fixed asset transactions and, as a result, tax transactions were not linked to ledger transactions.

•  Solution
The code of the calcAndPost method of the TaxLedgerJournal class has been corrected. Now the ledgerAccountNum method of the LedgerJournalTrans table is used to determine the operation for the fixed asset transactions.

 \Classes\TaxLedgerJournal\calcAndPost
\Classes\AssetPost\post
#17538 KB921892 An incorrect tax amount was calculated when the user posted taxes using a tax code with a fixed exchange rate. •  Problem
An incorrect tax amount was calculated when the user posted taxes using a tax code with a fixed exchange rate.
The issue occurred because of the tax posting routine that disregarded the predefined fixed exchange rate and always used the rate per posting date functionality.

•  Solution
The code of the calcAndPost method of the TaxLedgerJournal class has been corrected to pass the defined exchange rate as a parameter to the saveVATTransaction and saveAndPost methods.

 \Classes\TaxLedgerJournal\calcAndPost
\Classes\TaxLedgerJournal\saveVATTransaction
#18001 KB922013 When the ledger allocation with closing negative percentage was used, the allocation lost pennies and there was no compensating penny difference transaction. •  Problem
When the ledger allocation with closing negative percentage was used, the allocation lost pennies and there was no compensating penny difference transaction.
The issue occurred because the code in the \Classes\LedgerVoucherObject\allocate method only posted penny difference when the total allocation percentage was +100%.

•  Solution
The code has been corrected to calculate penny difference separately for the positive and negative allocations.

 \Classes\LedgerVoucherObject\allocate
#18065 KB922262 An incorrect amount in the "VAT reclaimed in this period on purchases and other input (including purchase in the EC)" line was shown in the English Sales tax payment report if the sales tax that had a percentage exempt from sales tax was used. •  Problem
An incorrect amount in the "VAT reclaimed in this period on purchases and other input (including purchase in the EC)" line was shown in the English Sales tax payment report if the sales tax that had a percentage exempt from sales tax was used.
The issue occurred because the amount in "VAT reclaimed in this period on purchases and other input (including purchase in the EC)" was shown with the part of sales tax that should be excluded.

•  Solution
The MakeReport() method of the TaxReport_UK report has been modified to correct the amount shown.

 \Reports\TaxReport_UK\Methods\classDeclaration
\Reports\TaxReport_UK\Methods\initAmounts
\Reports\TaxReport_UK\Methods\MakeReport
#18591 KB923493 If a cash discount was set up on a vendor account, and if users settled a posted vendor invoice transaction with a vendor credit note transaction, they received different amounts for the debit balance and credit balance in vendor accounts, ledger accounts and the printout of the Balance list report. •  Problem
If a cash discount was set up on a vendor account and, if users settled a posted vendor invoice transaction with a vendor credit note transaction, they received different amounts for the debit balance and credit balance in vendor accounts, ledger accounts, and the printout of the Balance list report.
The issues occurred because the correction flag for vendors transactions was not considered. Also, the debit and credit values of ledger balance were updated even if ledger transactions were grouped and not posted on ledger at all.

•  Solution
The code of the \Classes\CustVendVoucher\initCustVendTrans and \Classes\CustVendSettle\postDiscTrans methods has been updated to use the correction flag for vendor transactions. Two new methods have been created: \Data Dictionary\Tables\CustTrans\Methods\postLoad and \Data Dictionary\Tables\VendTrans\Methods\postLoad to enable amount alignment in the grid and reports according to the correction flag (the same method is used for the ledgertrans table). To correct ledger balances updating, the updating engine has been moved from \Classes\LedgerVoucher\postGroup to \Classes\LedgerVoucher\post. Now ledger balances updating will be performed after transactions grouping.

 \Data Dictionary\Tables\CustTrans\Methods\postLoad
\Data Dictionary\Tables\VendTrans\Methods\postLoad
\Classes\CustVendVoucher\initCustVendTrans
\Classes\CustVendSettle\postDiscTrans
\Classes\LedgerVoucher\post
\Classes\LedgerVoucherDraft\end

Top