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

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..

Budgeting in AX 2009 - Overview

Budget Allocations

AX has the ability to use predefined allocation rules to perform generated allocations. Generated allocation is the distribution of posted or fixed amounts to combinations of destination accounts and dimensions at any time, for which system generates new Journal entries distributing the amount based on an allocation formula.

Allocation can be set by various methods in Ax, which includes:

- Basis

- Fixed percentage

- Fixed weight

- Spread even

The Allocation process in the system is divided into 3 segments.

• §  Ledger allocation rules definition
• §  Process Allocation request
• §  Allocation Journal.

Ledger Allocation Rules definition: - The first step in allocation is to define the allocation rules.

Creation of allocation rules requires the allocation code, allocation validity as Start Date & End Date. Then, select one of the allocation methods as fixed percentage, Basis, Fixed Weight, Spread even.

After selecting the allocation method, define the Rules for the Source Ledger account. Source Ledger accounts and dimensions can be selected where the expenses has been incurred.

Define the destination account & dimensions where the amount needs to be allocated. Also define the actual percentage or Basis based on which source amount should be allocated to destination. Once destination is defined the Ledger allocation rules are completed.

Process Allocation: -Once the Ledger Allocation rules are defined, the unique rule code will be generated. Refer the rule code in process allocation request to process the allocation entries (based on the allocation rules the system will reallocate the cost to the respective department.)

After selecting the rule code, provide start date and end date of rules and reason codes with remarks. Process the Allocation request and this generates the financial entries in allocation journal.

The allocation process collects one or more values from a source data record and distributes the totals of the values to one or more accounts or account and dimension combinations according to an allocation rule that is defined using the Ledger allocation rule form.

Allocation Journal: -Allocation journal shall show the entries passed by Process Allocation step. System would generate the entries on running the Allocation request. System shall reverse the Source Ledger a/c and book the entries against destination ledger accounts as per the allocation rule.

Budgets

Budgets are defined for each Chart of Accounts dimension wise, where dimension can be a Category/cost center/department/projects/sub department which are identified as Dimensions.

AX supports budgets to be created at the General ledger level. The budgets are maintained at the chart of account level with relevant dimension and the variance analysis will be made at the chart of account level.

Sales and Purchase Budgets:

The budgeting for sales and purchases is carried out in the Accounts Receivable & Accounts Payable module and the same will be transferred to GL. However the accounts that are affected during the transfer are only the Sales revenue accounts and the purchase inventory accounts.

The sales and purchase forecast can be entered by quantity and amount and the allocation keys will be defined to split the amount over a period of time when the forecast are transferred to GL budgets.

Budget Revisions:

There can be scenarios where the budgets are prepared and approved for the complete year, however the budgets can be revised as per the requirement. The existing budgets can be modified or a new budget created with the revised figures. 

Price Tolerance

Price tolerance defines the percentage by which the invoice net unit price can exceed the purchase order net unit price, and still be considered within the allowable tolerance for invoice matching discrepancies.

Invoice matching is the process of matching vendor invoice, purchase order, and product receipt information. Differences among these documents are called matching discrepancies. Matching discrepancies are compared with the tolerances that are specified. If a matching discrepancy exceeds the tolerance percentage or amount, match variance icons are displayed in the Vendor invoice form and in the Invoice matching details form.

For example, you enter a purchase order with one line item for 500 pencils at a price of 1.00 each. The purchase order is approved and submitted to the vendor. The vendor ships 500 pencils, and you enter a product receipt for 500 pencils at a price of 1.00 each. The inventory cost for the pencils is updated with this price.

An invoice arrives for 500 pencils at a price of 1.10 each. Your legal entity policy allows a 5 percent net unit price tolerance for this category of item. A price of 1.05 would be acceptable, but 1.10 is not. When you enter the invoice information, a price matching discrepancy is identified and you can save the invoice until the discrepancy is resolved.

A vendor price tolerance group defines the group of vendors for which such a “price tolerance” is applicable. In other words, it is a vendor group to which a specified price tolerance is applicable. In the vendor form, this field describes the “identifier” for the vendor group.

Happy learning.!

Accept Errors - Report as Finished

The Accept Errors check box allows users to post the Report as Finished journal without any validations and generating any error logs.

The checks include, but are not limited to:

• -          Whether all the items are deducted from the inventory
• -          All the prerequisite operations are completed
• -          Picking List posting quantity
• -          Whether the produced quantity is less than the RAF quantity

If you UN-check (not selected) it will generate the error info log and lets you know where the error occurred while doing Report as Finished.

For Example:

Quantity for production is 100

Picking List is 95

Report as Finished is 98

If the Accept Errors checkbox is ticked, the system will post the Journal without validating against the picking list and without generating any error logs.

If it is un-checked, the system will throw an error after validating against the Picking List.

Zero Quantity

The Accept Error checkbox does not work while reporting Zero finished quantity. Whether or not the checkbox is selected, the system will throw an error if Zero quantity is being posted after production.

A quantity must be allocated for the system to post the costs relating the production. 

In such a case, post one quantity as RAF and then write off the quantity after the production has Ended.

Fixed Assets - Depreciation Conventions

Depreciation is a periodic transaction that typically reduces the value of the fixed asset on the balance sheet, and is charged as an expenditure to a profit and loss account. Therefore, a main account is usually used for crediting the periodic depreciation on the balance sheet. An offset account is an account in the profit and loss part of the chart of accounts.

Various depreciation methods and conventions are available in the system. The purpose of the methods is to allocate the depreciable value of the fixed asset into fiscal periods. The depreciable value of the fixed asset is the acquisition price, reduced by a scrap value, if any.

Depreciable value = Acquisition price – Scrap Price (if any)

When using depreciation conventions, if  the last depreciation run date for an asset is modified, which then causes some depreciations to be skipped, the depreciation for the last year might be more than or less than is expected. The depreciation is adjusted by the number of depreciation periods affected by the modification of the last depreciation run date.

Depreciation Conventions

During the first year in service, depreciation is calculated using the depreciation method and averaging convention for the asset. The resulting depreciation amount is distributed over the period of time from the date it was placed in service to the last day of the year.

The Mid-month (1st of month), Mid-month (15th of Month), or Full Month averaging convention must be used only if the fiscal periods are set up in a manner that matches the calendar year.

The averaging convention does not change the dates an asset is retired or placed in service. It only uses a ‘pre-defined’ date to calculate the depreciation based on the averaging convention defined for the asset.

The following averaging conventions are available in Fixed Asset Management:

• None:  Assets will begin depreciating on the date it was placed in service and will be retired on the retirement date.

• Half-year:   Assets begin depreciating on the Placed in Service Date. In the year of disposal, assets are retired on the last day of the first half of the year.

Only half of the depreciation amount is taken in the year an asset is acquired. This also applies to the year in which you dispose of an asset and to the year in which the life is complete, based on the original life of the asset. The asset doesn’t depreciate after the first half of its final year.

• Mid-month (1st of month):  Assets that are placed in service in the first half of the month — days 1 through 15 — will begin depreciating on the first day of the month.

Assets that are placed in service in the second half of the month — day 16 through end of month — will begin depreciating on the first day of the next month.

Assets with a retirement date in the first half of the month — day 1 through 15 — are considered retired on the last day of the previous month.

Assets with a retirement date in the second half of the month — day 16 through end of month — will be retired on the last day of the month.

• Mid-month (15th of Month):  Assets that are placed in service at any time during the month will begin depreciating on the 16th of the month. Assets that were placed in service in February will begin depreciating on the 15th of the month.

Assets retired at any time during the month will be retired on the 15th of the month of the retirement date. Assets retired in February will be retired on the 14th of the month.

• Mid-quarter:   Assets that are placed in service at any time during the quarter will begin depreciating on the middle day of the second month of the quarter.

Assets retired at any time during the quarter are considered retired on the middle day of the second month of the quarter.

For Example: Consider a January to March quarter.

Asset A002 was acquired on 31st January; Asset A008 was acquired on 9th March and Asset A015 was acquired on 31st March. With the Mid-Quarter depreciation, all these asset will begin depreciating from the 15th of February in the same year.

Asset Z009 was retired on 21st January; Asset Z021 was retired on 12th February and Asset Z045 was retired on 21st March. Given the convention, all these assets will be considered retired on 15th February.

• Full Month:   Assets that are placed in service at any time during the month will begin depreciating on the first day of the month.

Assets retired at any time during the month are considered retired on the last day of the previous month.

Increasing the Service Life of a Fixed Asset

Increasing the Service Life of an Asset is carried out to revise the estimates done when the Asset was first acquired and increase the periods for depreciation for the Asset.
This change is not an accounting / estimation error. It is an inherent and continual process in a business.

For Example: DAT (Default Company) purchased machinery for $150,000. The company made the following estimates at the time of purchase (Year 1):

• Useful life: 15 years
• Salvage value: $0

Now, during Year 6 – after five (5) years of using and depreciating the machinery – the company understands that the machinery can be used for 15 years more from the date of change (or for a total of 20 years from the date of purchase), rather than the previous estimate. This decision is based on various factors including machine performance and maintenance as well.

In the accounting scenario, the change in depreciation from revision of useful life is calculated as follows (for Journal Entries):

There is no need to undo the previous calculations for depreciation or make any adjustments thereof. The depreciation henceforth would be adjusted based on the formula stated above.

In AX too we have a provision for increasing the Service Life of an asset long after it has been commissioned.

The Setups and prerequisites are as follows:

Prerequisite - Require Reason Code:

Reason Codes urge users to justify/ provide reasons for performing any action in the system. 

Since an increase in the Service Life of an asset has substantial Financial Implications for the business, requisite setups are available in the system to prompt the user to enter the reasons for the Update.

This setup is not mandatory, but suggested. It depends on the Business hierarchy and whether or not these rules are applicable to the scenario.

To enable Reason Codes, check mark the Require Reason Code for Fixed Asset change in General Ledger >> Parameters

Path: General Ledger >> Setup >> Parameters >> Fixed assets tab

The Reason code requirements for transactions are additional transactions for which the reason code needs to be updated. This is optional setup.

Prerequisite - Reason Code Setup:

The Reason code setup is available in the Basic module. This setup is required if Reason Code Requirement is selected in the previous step.

Path: Basic >> Setup >> Reasons

Enter the Reason Code and Default Comment. Check mark the box for Asset.

Click Ctrl+S to save

Now that we have our Reason Codes setup, we can proceed with the update.

Increase Life of FA

Path: General Ledger >> Common Forms >> Fixed Asset Details.

Select the Fixed Asset to increase life for and click on Value Models:

Go to Depreciation Tab:

In the Depreciation header, there are fields for:

• Service Life
• Depreciation Periods
• Depreciation Periods Remaining

These fields can be updated based on the requirement. When the Service Life is increased, the Depreciation Periods and Remaining Periods are automatically updated. When the Depreciation Period is updated, only the Remaining Periods are updated, but the Service Life is not updated.

Make the changes. Click Ctrl + S to save.

The system prompts for Reason Code:

Enter the Reason Code by selecting from the drop-down menu and Click OK

The Updates will be made for the asset.

To view the changes made to an Asset, Click on Inquiries >> Change History in the Value Models form.

Workflow History Form

The Workflow History form is under Basic >> Inquiries (AX2009)

Now, this form is quite fascinating because of the way it works - Its picks up the User id and then displays only those workflows that are relevant to them. For the Admin, all workflows are visible.

Here's the catch - All workflows are visible to the users assigned to the Admin group. If a user has complete Admin rights over all the modules, but is not a part of the Admin group, it still shows only related workflows.

Peculiar... Yes...

I came across this phenomenon when a client was re-assigning couple permission and were facing a problem with this form, even with complete access on the other modules. Admin group could not be added because of obvious reasons.

After a lot of assigning, re-assigning and manipulating with the user rights, I decided to dig into the code...

And Viola.!!

There is a very specific query that executed when the form is run. This query does not fetch the user id only if the user belongs to the Admin user group. Any other group, with complete access over the system - it will still fetch the user id and display specific details.

Being a Standard form, it is not advisable to play around with the code here. Just to test the case, we added another user group along with Admin, to see if it works. It did.

But.

Not sure why, but the workflows started throwing a Stopped (error) after completion - totally out of the blue. When we restored the original code, the error disappeared as silently as it had crept in. I am still on a lookout for the reason for this unusual behaviour, without any pointers.

The final establishment of the entire experiment was that the Workflow History form has a dependency on the Admin group and not on Users' access on the system. Secondly, fidgeting with the query in the code was not a very good idea.

Anyone out there with a similar problem, there does not seem to be a feasible solution here... In case any of you stumbles upon a hidden area, please share.

Happy daxing :)

Fixed Asset Additions

An addition to a fixed asset is a maintenance to or an add-on item for a fixed asset. Like Engine Oil for an automotive or an additional hard disk for a desk Computer.
An addition is considered part of a fixed asset, but is not a separate asset. Typically, an addition is maintenance or an improvement and is related to a write-up adjustment.

The addition is done as follows:

Click General Ledger >> Common Forms >> Fixed Asset Details.

Select the fixed asset to create the addition for.
Click Additions.

Press CTRL+N to create an addition.On the Overview tab, keep the default addition number and type a name for the addition, such as Laptop Battery or Wiring

Enter additional details, such as the acquisition date, unit cost, and quantity.

On the General tab, enter values for other fields as appropriate:

If the addition increases the service life of the fixed asset, select the Increases service life check box, and then modify the Service life field in the Value models form.

If not, leave it unchecked. The addition will not increase the Service Life of the asset.

Press CTRL+S to save the addition

Orphan Transactions - Changing the Dimension group of a Standard Cost Item

Update conflict. The standard cost does not match with the financial inventory value after the update. Value = ###.##, Qty = ###.##, Standard cost = #.##

This is an error we come across quite many times in AX 2009, while trying to post transactions against an item. Most often, it is during Purchase Order posting. While the cause is clear, it is still a dilemma as to how the system runs into this situation.

The Cause:

In AX, users can set Inventory Dimensions for an Item. These dimensions, once set, and once there are transactions created with them, are not changeable. In most cases, the system throws an error while trying to change the Dimensions on the Item where transactions exist for the item.

Note: There need not necessarily be 'open' transactions against the item. The default behavior is that that as long as the item is 'used' in any transaction, irrespective of whether it is open or not, the system will not allow the update.

In rare cases, and absolutely at random, the system allows the change in Dimension even when transactions exist for the item.
There is no definite reason as to why this happens. But nonetheless, it happens. When there is a Batch dimension attached to the item, it becomes a greater concern.

The Issue:

The Items for which this error occurs had the Inventory dimensions changed from one that had a Batch dimension to one that did not. These transactions then become "bad" transactions in the system and cause this error.

Depending on the item, there will either be a negative inventory (physical negative inventory enabled on the Item model Group) or there was a Positive inventory in the system, for the quantity available.
Ideally the inventory must be zeroed out before any such update is done. When trying to update the Inventory for these items, the system creates an issue. Since the Batch Dimension is no longer an active Dimension for the Item, transactions cannot be posted with a Batch number. The transactions that were already existing in the system are now "orphaned" by this update. The transactions with the batch were duplicated in the system at the same location, but without the batch dimension.

To add to the confusion, the Standard Cost does not update properly, for all the lines of a particular item in the InventSum. This is again because there are some transactions with Batch Dimension active and some without. The Standard Cost does not understand how to handle these "Orphaned" transactions and the issue compounds.

The biggest issue in this case is that the Dimensions can be changed a long while back or more recently, and the Standard Cost update will sometimes not throw any error (again, there is no logical explanation to this scenario). The point is, the updated could have happened long before the error throws up (In my most recent case, the update was done 3 years ago.!!)

How the system Works:

While looking up the totals for an Item, AX queries the InventSum table or the InventTrans table using some predefined macros. The #InventDimJoin macro queries the InventDim table and the InventDimParm table to fetch the total quantity for the Item based on the Inventory Dimensions that are Active for the item.
Here, the "orphaned"/ "bad" transactions get added into the non-batch transactions, with the same active transactions (but without batch dimension). Since Batch number is not an active dimension anymore, it gets ignored.

When the totals are calculated, some of the transactions match the Standard Cost for the Item, while some don't. If the Site-Warehouse where the transaction is being updated matches with the Standard Cost, the system allows the transaction. In case there is a mis-match, the error occurs.

The Solution:

The issue occurs at random and there is no exact reason for the system to be in this situation. There is, however, a solution to the above issue.
Do note that the solution may not always fit the problem. It is one of the possible ways to fix the issue at hand. (The Debugger is a handy tool in most situations).

 - First, evaluate the existing transactions in the system and determine the cost for each of the transactions.
- Use the fill utility to change the item's dimension group back to one that uses the Batch dimension.
Here, we are updating the dimensions for the transactions in the InventSum table for the particular Item. By using the fill utility, we ensure that the check for the Active dimension is ignored..
- Once this is done, the transactions can be updated in the system. Do ensure that the Standard Cost for the Item matches with that on the "orphaned" transactions. (The Standard Cost may have to be updated in this case)
- Use the Item Journals to add/remove the Inventory of the affected items as required.
- Use the fill utility to update the dimension group.
- Move this "updated" inventory back with appropriate costs, and without batch numbers this time

Note: The system considers both the Quantity and the Cost while building up the On-Hand for the Item. If the totals for both are not absolutely zero, the transactions will still exist in the system and there will be a record for it. This will lead to the same error in the future.

Workaround:

There are some cases where only one transaction is affected for an item. In such a case, first, determine exactly which transaction is affected for the item.

Then, go to the InventSum table and narrow down to the transaction. Here, in the PostedValue field, update the cost to match the Standard Cost of the Item. Ensure to take into consideration the Quantity posted against this particular transaction and make the update accordingly.
Be extremely careful while making the update. The InventSum is a core table for all item transactions and any error will have huge impacts in the system.

Caution: Do not directly update the Costs and Dimensions in the Live/ Production system. Try the update in the test/ development system first to check if all the transactions are being updated correctly. Then, take a DB backup of the Live system and then update the costs in the Live system.
Also ensure to totally nullify the "orphan" transactions. Otherwise the error will crop up again.

Again, this is just a suggestion as to what needs to be done. Consultant discretion is advised.

P.S. Please leave comments below in case there is any other way to fix the issue.

Hand Mark - Voucher in use

Settling Open Customer and Vendor transactions is a regular process for businesses. However, in certain cases, it creates a discrepancy which throws the "Voucher in use" error.

The "voucher" that is causing the error is identified by a Hand mark against it in the Open Transactions editing form. (This is for both the Customer and Vendor).

The Cause:

There are several reasons for the Hand-mark in the Is Marked column:
-  User started to process the settlement, but deleted the adjustment voucher and did not uncheck the transaction. Hence the transaction remained
-  The marking was done for settlement, but there was an update conflict while processing the payment. In this case, the original transaction remained and the Offset transaction was lost
-  A temporary record created in the database is not released after the form is closed. The reasons for this discrepancy:

• Power interruptions cause the transactions to be incorrectly recorded in the database
• Connectivity issues between AX client and AOS

The Solution:

One way is to trace the User ID that was used to "mark" this transaction and with that ID, un-mark the transaction. This is cumbersome when there are many users who access this form.

Second, is to remove this hanging transaction from the system from the Database itself. To do so, follow the steps below:

• For the affected transaction, get the RecID (take some technical help if you do not know how to do so). The RecID is an important identification to locate the transaction in the Database
• Navigate to the SpecTrans table in the AOT. ( The SpecTrans table keeps track of the marked transactions by creating a record for the transactions)
• Filter the RefID field with the value of the RecID of the affected transaction
• Delete the record 
• Save, Compile and Synchronize the table

Go back to the form to verify the marking has been removed.

Caution: Take care while noting the RecID of the affected transaction and navigating to the record in the table. In case any other transaction is removed, it will cause a discrepancy in the transactions that are being processed or already processed for settlement.

The issue may differ on a case-to-case basis. Consultant discretion is advised while exercising the solution.

P.S. If there are other work-arounds for the scenario, do leave your comments below.