Error: A currency to convert from is required to retrieve exchange rate information.

While posting Pending Invoices in AX 2012, there are cases when this error message is shown and the posting is cancelled.

What is more annoying than the error is that the infolog is very cryptic and reads:

Error: Exception has been thrown by the target of an invocation. A currency to convert from is required to retrieve exchange rate information.

More often than not, the currencies and exchange rates are available in the system and other related configurations for multi - currency transactions are set. This issue was common in the Feature pack, but is sometimes observed in R2 as well.

There is no known KB or hotfix available for this and no defined cause for its occurrence. It is as random as can be and will pop up when least expected.

Although no permanent fix is available, it can be sorted, until further occurrence. And considering it is rare to encounter this issue, one can ensure the client that the issue is fixed for good.

Caution: Please try in test environment before applying to Live instance. Take necessary backups before performing the activity in Live.

Resolution:

Make note of the Purchase Order number for which the Pending Invoice posting is causing the error.

Delete Pending Invoices and matching history for the related Purchase Order:

Accounts Payable >> Common >> Vendor Invoices >> Pending Vendor Invoices

Accounts Payable >> Inquiries >> History >> Approval Journal history and matching details

Sometimes, even after deleting the pending invoices, the issue persists. Then the details must be deleted from the DB as in some cases there are multiple records at the table which may or may not reflect on the form.

Note: the erroneous records have a status: Waiting in the table. DO NOT, in any case delete any records with status: Executed

For this:

- Note the PO and Invoice details

- Go to VendInvoiceInfoTable

- Filter by PO number/ pending invoice number

- Select all available records, that have a status other than Executed and delete.

This is an alternate solution and has to be applied with discretion. It may not always solve the issue and deleting records from the Table must only be done by experts after taking all necessary precautions.

Any other solutions, do leave comments below :)

Block a Dimension - AX 2009

In some cases, a business may require to block an existing dimension from being selected while posting a transaction. It can be a temporary or a permanent requirement.

While the AX system does not allow users to delete dimensions once transactions are posted with the dimension, it does allow blocking the dimension from being selected.

Path: General Ledger >> Common Forms >> Dimensions

Select the Dimension from the drop-down in the header section of the form. Filter for the particular dimension value that needs to be blocked in the Line level of the form.

Check the closed check box.

The users will not be able to select or view the closed dimension at postings.

Note: In cases where a new dimension is created and assigned in the Dimension Structure appropriately, yet the user is unable to select the dimension, it is advised to check if the dimension is set to closed in the Dimensions Master.

Inventory to Fixed Asset Journal

There is quite some confusion with regards to how a Fixed Asset can be bought in without creating a Vendor Liability again (the asset is bought, but not marked as a Fixed Asset at purchase).

This post is an attempt to simplify the Inventory to Fixed Asset Journal usage.

There are 2 main Journals that are used to post Fixed Asset adjustments, depending on the scenario:

- Inventory to Fixed Asset Journal

- Fixed Asset Journal.

The Inventory to Fixed Asset Journal is used when an asset that is already bought in, needs to be added to the FA master – here there will be no additional Vendor Liability that will be booked. In essence, it is used to move an already purchased item into the FA master

The Inventory to FA Journal picks the price from the Item master (Inventory management >> Common >> Item Details >> On-hand button >> Cost Price). The price on the Item master is available once the item is purchased/ brought into the inventory, in the system. Even if there is a different cost/ price specified on the Journal, it will be over-ridden by the cost on the item master. The system does not consider the amount on the Journal; it is picked from the Item master.

The Fixed Asset Journal is used for any sort of adjustment to be made to the posted Fixed Assets.

For example: to post an acquisition adjustment, the user must use the Fixed Asset Journal and post the entry. The system will then pick the price mentioned on the Journal, and the cost will be updated accordingly.

Scenario for reference:

Case 1:

-  Purchased Item (XYZ) at USD 500 without checking the New Fixed Asset check box in the Purchase Order

-  System adds inventory for the item, but FA is not created.

-  Invoice is posted, therefore a Vendor Liability is already created for the Asset.

The asset cannot be purchased again, as it will create another Vendor Liability in the system and this is not acceptable. 

To make this item a Fixed Asset, use the Inventory to FA Journal and transfer the item to the FA Master. The cost will be picked from the Item Master and no additional liability will be booked.

Another way is to create a credit note for the PO and then raise it again. But this becomes cumbersome if there are multiple currencies involved (exchange adjustments must be considered) or if the period is already closed. 

Case 2:

-          Purchased Item (ABC) at USD 650, by checking the New FA check box.

-          System creates a FA in the Master and the cost is USD 650

-          Additional charges were incurred at USD 150

These costs need to be loaded on the FA itself, considering they were incurred as a part of the purchase of the FA. These costs are added to the FA using the FA Journal, with transaction type Acquisition Adjustment. It will create a new transaction line in the FA transactions as Acquisition adjustment.

The total value of the FA will be the acquisition cost + the adjustment (USD 800 in this case). The depreciation will be calculated on the total cost and not just the acquisition cost of the Asset.

Cross Rate - Settlement without Exchange Adjustment impact - AX 2009

Settlement of open transactions is an important task within the AX system. When there is only a single currency involved, it is a fairly simple task to settle one transaction against the other. But when there are multiple currencies involved, there is more to the settlement functionality than a straightforward "knock-off".

When a transaction is posted in the system, it is posted on the exchange rate defined on the currency master, unless over-ridden while posting. It is common that the transactions to be settled have been posted with different exchange rates, depending on the amount of exchange volatility the business allows. 

While settling, again, the exchange rate can be different. This leads to exchange rate gains/losses and adjustments to be posted in the Ledgers.

There are many cases wherein it is desired to settle open transactions at a particular rate as against the system defined rates. It may be to reduce exchange losses or to honor an agreement.

Cross Rate functionality in AX allows to do just that. One can use a cross rate to settle open transactions, and the lines are in a currency different from that of the reporting/default currency. One of the lines to be settled is marked as a primary payment and the cross rate is specified. This rate is then used to settle the selected transactions.

Note: This is applicable to both Payable and Receivables.

The process:

Go to Open transactions Editing form

Select the transactions to settle

Select the payment line and click on Mark Payment button

The cross rate field becomes editable on the marked line and the transaction gets marked as primary payment.

In the Cross Rate field, enter the exchange rate at which the transactions should be settled.

Update the transactions.

The transactions will now be settled at the rate specified on the line. There will be no exchange rate differences posted to the ledgers and the settlement is posted at the specified rate.

:)

Workflow stuck in Pending State - AX 2009

There have been cases wherein the Workflows seem to be stuck at one point of evaluation. Mostly, the case is that the step is evaluated to false, and yet the WF does not seem to move ahead. Even after all the assignees have completed their task, the WF does not move to the next step. It remains in the same state for over a day. Sometimes, they are pending for weeks or more.

There are quite some scenarios wherein this happens:

WF Batch - Check if the batch is set to run at say hourly intervals, to ensure the records are processed on the same day.

WF Batch configuration - The WF batch is configured to run at Server (If it is client, reset it to Server)

WF Configuration is not active - Activate and default the correct version of the WF

Users Check - Check if all the users that are a part of the configuration are active in the system. If not, deactivate that version, reconfigure the WF without the users that are inactive and activate the new version.

Error Log - Check to see if all connectors and WF servers are up and running.

The aforementioned cases are known and are almost always the case for the pending records. There is however, another case, unknown to most, as to why the Workflows do not process - Old and pending WF records.

While troubleshooting, it appears that there is nothing wrong with the configurations or the setups. At first, it just seems to be hung up because of slow processing. But when the Tutorial Processor is tun, the WF moves just one more step, and then halts. No Work items are created and no Assignments are made. It is just stuck.!! The error log, however, shows threading and deadlock issues in the same time frame that the WF is hung up. No other logs are recorded.

A lot of pending Workflows - those that will not be processed further - are caused either because they are no longer part of the active configuration of the Workflow or because the records are no longer required. These records are set to Pending state and every time the WF engine runs, it picks up these records as those that need processing. This means that these un-wanted records keep interrupting with the new records causing an excess load on the engine.

This is an issue with AX 2009 WF. The pending records keep interfering with the new threads (for the newer WF) and since they cannot be processed, enter into a deadlock situation eventually. This scenario is not common and happens over a long period of time, when there are a substantial number of WF created in the system.

To this situation, there is a simple, yet complex resolution. Do note that the solution is to be applied only during system downtime, and when there is no pending tasks by any users in the system.

Resolution steps:

1- Cancel any WF pending for over a quarter and those that are not a part of the active WF configuration or those which no longer need to be a part of the WF as they are not needed any more.

2- Stop AOS

3- Delete AUC files: This is to ensure that any pending WF that might be cached are flushed. The system will rebuild the cache once the AOS is restarted and the users login to their systems. This step will also flush the user preferences and other user specific cache from the system. Also, auc files need to be cleared from all users.

4- Restart Dynamics Ax service (AOS)

5- Compile form AOT the entire tree: This will clear up any other issues, just in case

6- Synchronize data dictionary: To ensure that the schema and data are in sync and there are no discrepancies.

7- Test your workflow.

It might take some time till the WF are processed normally. Since the cache was cleared, the system will build up the cache from scratch, and it might be a while before any difference in processing is noticed. Usually, it takes at least 3-4 days to observe differences in processing speed.

It is advised to do the activity in the weekends, so that the system can build up the cache while the users are offline and there is no hindrance for the users as well.

To prevent such build up in the future, ensure to cancel any WF that are pending for long in the system, every quarter. This will ensure that there are no threads that are left hanging to interfere with the processing in the system.

Hope this helps :)