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 

Project Module - Accounting

Project Cycle
 

·         Raising a Project Quotation – with estimates of Items, Expense and Hour

·         Converting Project Quotation to Project, after contract

·         Item Requirements

·         Posting Consumption and Recognizing costs

·         Recognizing Revenue

·         Invoice to Customer

      Raising Project Quotation:

Before creating a project in the system, a project quotation is raised. This is again based on the business requirement of the firm.

A Project Quotation includes the estimates for Raw materials (items), Time (hour) and Overheads (expenses) along with the costs and revenues. Once the terms are agreed at, the quotation is converted to a Project.

Converting project quotation to Project

Once the quotation is approved, a Project is created. Projects can be directly created in the system as well, based on the requirement.

When a Project is created from a quotation, all the details from the quotation are copied into the Project

Items have to be purchased before consumption. (Otherwise is also possible if Negative Inventory is allowed. However, it is better to have physical inventory before consumption to recognize costs appropriately)

Hour and Expenses can be directly booked in the system

Item Requirements

The item requirements are fetched from Project Quotation where applicable. In case of directly creating a project, the Item Requirements must be defined.

Path: Project Management >> Common >> All Projects >> Select Project >> Item Requirements in Manage tab

Purchasing Items: Item Requirements >> Functions >> Create Purchase Order

Once PO is created, Confirm > Receive > Invoice the PO

The Accounting:

Inventory dr

To Accounts Payable (vendor account) cr

Posting Consumption and recognizing costs

Item Consumption happens through a Project Sales order. Whenever a Purchase order is created for item requirements, a Sales Order is simultaneously created for the Project.

Considering that there is no requirement to Purchase the Required item for the Project, a Sales Order is created when the Item Requirements are raised in the system.

To view the Sales Orders, go to Project >> Item tasks >> Sales Orders

Here the Sales Order has a status “Open Order” and Type “Item Requirement”. Further, all options for confirmation, picking, packing and invoice are disabled in the form. This is because the SO is not actual sales to Customer, but a consumption posting for the Items to be consumed for the Project.

Note: Sales Orders of type “Item Requirement” can only be created and posted from within the project and not otherwise.

The item consumption is posted in the system by posting a packing slip for the respective sales order, from within the project.

Path: Item Requirement >> Posting >> Post Packing Slip

Once the Packing Slip is posted for the Item, the Status of the SO changes to Invoiced. Also, there is no Unit Price or Net Amount on the Lines for the Item Consumption, since this is not booking any liability to the customer.

The Accounting:

Project Cost account dr

To WIP Cost account cr

WIP – the concept:

WIP is a system parameter. It indicates costs/ revenues that have not yet been accrued. In the case of a Project, the entire cost is not consumed at once and it is periodic, until such point that the revenue is recognized. When the Revenues are recognized, the costs are recognized at actuals.

In case the business does not wish to have a WIP account, the costs can be directly mapped to the actual Cost account.

Sales Category:

Sales can either be processed for a Sales Category or an Item. Each Category is associated with one or more Items.

While processing a Sales Order, user can either process for a sales category or for an Item. When a Sales Category is updated, the system does not allow to select the Item. However, when the item is selected on the Lines, the sales category is auto-populated where applicable.

The Accounting – for Category sales:

Customer account dr

To Sales Category account cr

The Accounting – for Item sales:

Customer account dr

To Item Sales account cr

Recognizing Revenue

Revenue recognition is a process wherein the Business decides to “recognize” or identify the revenues in the system. It is different from actual sales in the sense that there is no Invoice posting that happens at recognition. It is a system process for businesses to conclude as to the revenue that the project will bring. It is a kind of Estimation of revenues.

The Accounting:

WIP Revenue account dr

To Actual revenue account cr

Revenue estimation can be done for the entire revenue or for a part of the Revenue based on the project completion and the milestones for the project.

Let’s say that the total revenue expectation for the project is $100,000. This entire revenue can be recognized at once or in slots (equal or otherwise)

Estimating a 10% revenue will create an entry of $10,000 against the project. Estimating at 50% will create an entry of $50,000 against the project.

Invoice to Customer

The customer invoice is where the actual sales is posted in the system for the project.

The Accounting:

Project Customer (person or organization) dr

To WIP revenue account cr

Happy Learning..