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 :)

Purchase Order Accounting

Purchase order posting is a very common process in a business and is done on a daily basis.

The financial impacts of the postings, therefore, form a very important aspect for a business.

Postings happen only once the Receipts are posted. Confirmations and registrations do not have any physical or financial impacts in the system.

Product Receipt: A receipt is what confirms that the Items (stocked, tangible items) have been received into the inventory/ stock. Once the Items are in, only then there are impacts to the Ledgers. 

When a product receipt is recorded for a stocked item, two accounting processes take place:

One accounting process creates an accounting entry for the accrued liability. The accounting entry amount is for the received quantity of the stocked item, multiplied by the currency amount per unit for the purchase order. In the following example, ### denotes the currency amount of the accounting entry.

Debit Purchase expenditure, un-invoiced ###

Credit Purchase, accrual ###

Another accounting process accounts for the cost in inventory for the received quantity of the stocked item by crediting the expenditure ledger account and capitalizing the cost in an inventory asset ledger account.

Debit Product receipt ###

Credit Purchase expenditure, un-invoiced ###

Purchase Invoice: When an Invoice is posted, it indicates that the Vendor has issued a bill for the goods that have been transferred. A Vendor Invoice is what creates the liability towards the Vendor.

When a vendor invoice is recorded for a stocked item and accounting entries are created, two accounting processes take place:

First, the accounting entries on the product receipt for accrued liability are reversed. The amount that is reversed is based on the quantity of stocked item on the vendor invoice that is matched to the product receipt. Then, the accounting entry is created to record the liability for the vendor invoice. .

Credit Purchase expenditure, un-invoiced ###

Debit Purchase, accrual ###

Debit Purchase expenditure for product ###

Credit Vendor balance (Accounts payable) ###

Second, the accounting entry on the product receipt that records the inventory cost is reversed. The amount that is reversed is based on the quantity of the stocked item on the vendor invoice that is matched to the product receipt.

Additional account entries are created to record the inventory cost under a new inventory ledger account classification.

Credit Product receipt ###

Debit Purchase expenditure, un-invoiced ###

Debit Purchase, product receipt ###

Credit Purchase expenditure for product ###

Notes:
Where the Inventory runs on Weighted Average costing, there is a chance that the Vendor accounts and the Inventory accounts are posted with different amounts. These differences are in tandem with the Calculations that the system does for arriving at the Weighted Average cost of the Item.

The Budget Paradox

Every situation today has a paradox to it. A paradox is a statement that apparently contradicts itself and yet might be true (or wrong at the same time). Budgeting is no different.

Budgeting, as defined, is a process wherein a certain amount of resources (funds) are allocated to each expense. This ensures that the resources are optimally utilized and there is no dissatisfaction.

The Paradox, however, makes a different statement:

There needs to be a certain level of dissatisfaction within an organisation before it starts to examine its current situation and search for alternatives. It seems that some momentum for change needs to exist before changes are considered

What it means is that there has to already be some under/ over utilized resources, which are resulting in in-satisfactory outputs. Only then will the organisation think up of adding a budget, knowing very well that if they do not use budgeting, they will end up in a situation depicted in the former statement.

Well, it  seems more like human nature to do such things... In short, the paradox says that Organisations will dig the well only after there is a severe short supply of water and while they are at it, they will face all the more resource crunch. All this, when they are fully aware of the depletign water supply :P