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.

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.

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.

Exchange Adjustment - AX 2009

When multiple currencies are used, the exchange rate for the original transaction currency might differ from the exchange rate that is used during the conversion to the accounting currency. To recognize these differences in the exchange rate, the amounts in the main accounts have to be adjusted. The process that is used to make those adjustments is called a foreign currency revaluation or an Exchange Adjustment.

Revaluation can be done in Accounts Payable, Accounts Receivable and General Ledgers. However, the General rule of thumb is to perform the revaluation in the Accounts Payable and Accounts Receivables.

It is not suggested to perform Revaluation for Vendor and Customer Transactions in the General Ledger Module as these transactions will not reflect in the AP and AR modules respectively. Hence, Currency Revaluation is done for Accounts Payable and Accounts Receivables modules.

Prerequisites:

Before you can perform an exchange adjustment, the profit and loss ledger accounts for exchange adjustments must be. This setup is done in the General Ledger

Path: General ledger >> Setup >> Exchange rates >> Posting tab.

These accounts are essential to be setup in case when the organisation is dealing with multiple currencies.

Note: It is not necessary to use the same accounts for all the postings. Multiple accounts can also be used, depending on Company policy.

Revaluation process will generate unrealized gains/ losses whereas Settlement will generate realized gains/ losses.

Once these accounts are setup, the Exchange Adjustment can be carried out. These accounts must be setup for all the currencies that will be used.

Exchange Adjustment:

The procedure to run the Exchange Rate Adjustment is the same in Accounts Payable and Accounts Receivables Modules. The Exchange Adjustment is run from the Periodic Section in both the Modules.

Path: Accounts Payable >> Periodic >> Exchange Adjustment

Simulate an Exchange Adjustment:

Simulation is carried out to analyze the adjustments that will be made to the respective accounts after Revaluation. The simulation generates a report with all the entries and adjustments that will be made when the actual adjustment is carried out.

To run a Simulation, click on Simulation Button on the Exchange Adjustment Form

The following parameters need to be selected:

• Method
• Considered Date
• Date of Rate

In the Method field, the following options are available:

• Standard - Make exchange adjustments based on the Exchange rate used on the date specified in the Date of rate field.
• Minimum - Make an exchange adjustment if a loss occurs, but not if a profit exists.
• Invoice date - The program offsets any exchange adjustment that is not already offset, as on the date of Invoice. This causes the transaction being valued at its original value.

The Considered Date is the Date up to which the system has to fetch the “Not Settled” (Open) transactions to perform the exchange adjustment for.

The Date of Rate is the date to be considered for the exchange rate.

The default method is Standard.

The Considered Date and Date of Rate are usually the same date.

After the parameters are selected and the dates are entered, Click on OK.

The Simulation will generate a report with the adjustments that will be made if the Exchange adjustment is run. This report is used to analyze the differences and postings that will be made to the different Vendor/ Customer Accounts. 

Once the postings are verified, the Exchange Adjustment can be carried out.

Run an Exchange Adjustment:

To run the exchange adjustment, click on the Exchange Adjustment button in the form:

The parameters on the form:

Method: Standard

Considered Date and Date of Rate: As required

Use posting profile from: Select the posting profile that is used for the exchange adjustment transactions:

• Posting – The posting profile of the vendor transaction is used.
• Select - The posting profile is determined by the posting profile in the Posting profile field.

Posting Profile: If Select is selected in the Use posting profile from field, the posting profile of the exchange adjustment transactions is determined by the posting profile specified in this field.

Select among the posting profiles that have been set up for the company in the Posting profiles form.

Dimension: Select the kind of dimensions that are posted on the exchange adjustment transactions:

• None - No dimensions are posted on the exchange adjustment transactions.
• Table - The dimensions of the vendor account are posted on the exchange adjustment transactions.
• Posting - The dimensions of the transaction that is being adjusted are posted on the exchange adjustment transactions.

Print: Select this check box to print a report with details about this run of the exchange adjustment.

This report is printed on the go and is not saved in AX for future reference.

Transaction Text and Notes: These fields are for Users to enter any remarks or comments regarding the Adjustment.

Click OK to run the Adjustment.

The Exchange Adjustments are now successfully posted.

View Exchange Adjustment Transactions:

Once the Exchange Adjustment is run, the Transactions and the Vouchers posted can be verified.

To view the Ledger Transactions posted by the Exchange Adjustment, select the Adjustment entry that was created and Click on the Voucher Button in the Exchange Adjustment Form.

In order to view the Customer or Vendor Transactions posted by the Adjustment, Click on the Transactions Button on the form.

P.S. Leave your comments below :)

Credit Note for Invoiced Orders - AX 2009

There are several instances where Purchase Orders have to be processed for returns. There are also instances where the User has used incorrect dimensions or other details on the Purchase Order and it has been invoiced.

In such scenarios, a Credit Note is created.

Even in cases where the Product Receipt is processed with the wrong dimensions, it is better to invoice the order, create a credit note and then create a fresh order with the Correct entries.

Following is a step by step instruction to create a Credit Note from an Invoiced PO:

Select the Purchase Order for which the credit note needs to be created.
Click on Functions >> Create Credit Note

A form opens. In the Header of the form, uncheck the check box for Delete order lines. This is to have a track of the original as well as the reversed entries:

Note that there is a check box that is marked for Invert Sign. This ensures that the credit note is creates with a negative sign in the quantity and the amount fields.

The form has two sections, similar to the PO form. In the header are all the PO details and the Line details are in the lower section.

• Select the respective purchase order in header.
• In the line level, if the purchase order has multiple line, select particular line(s), which have purchase returns.
• Edit the return quantity.
• Click on OK button.

Depending on whether the entire order must be reversed or only some lines on the Order, select the lines by checking the Mark box

On clicking the OK button, the system pops a dialog box asking for confirmation:

Click OK.

In the PO level, we now have an additional line with the quantity and Net amounts fields with negative values.

A credit Note must also be processed in the same way that a PO is processed.

Confirm the PO:; Postings button >> Purchase Order

For a return order, the Quantity must be Picked from the inventory.

To pick, select the line with the negative quantity, Click Inventory button in the line level. 

In the picking form, check the Auto-create box against the line. A line will be automatically created in the Pick section of the form.

Click on Post All to post the picking list.

The Issue status changes from Reserved Physical to Picked.

Close the form and return to the PO form.

Here, Post Receipts List:: Postings >> Receipts List

Up to this stage, the PO has Open Order status

Post Packing Slip:: Postings >> Packing Slip

Once the Packing Slip is posted, the Order Status changes to Received

Now, Invoice the Order by selecting Quantity as Packing Slip:

Now the Order status changes to Invoiced.

Now, go to Inquiries >> Invoice

It is observed that invoice is posted with negative amount. Click on Voucher Button. The Amounts are reversed from the original accounts.

The original entries posted are completely reversed by the posting of the credit note.

Care must be taken when there are multiple currencies involved. In case of foreign currency, there will be a difference in the original posted amount and the credit note amounts where the dates of the Invoice and Credit Note are different.

To avoid the differences in the amounts, the Credit Note must be posted on the same date as that of the Invoice. Then there will not be a difference in the amounts.

Further, where there is Weighted Average Method followed, the system posts the negative inventory with the Weighted Average Cost updated in the inventory and the difference amount (if any) is adjusted in the Inventory Offset account.

All other impacts on the accounts are reversed as is.

Data Migration with AX Add-in for Excel

There is an added functionality with Excel - the AX add-in. With this add-in, data can be imported into AX in few simple steps.

To begin with, first ensure that the Add-in in enabled in Excel from Excel Options >> Add ins

The first step is in AX

• Open the form that you wish to upload: Item Master, Vendor Details etc.
• Right click on the field to be uploaded and click on Personalize
• In the window that opens, on the bottom right is a text box. Here, the name within parenthesis '(' and ')' is the Table Name. This is required to upload the Data.

We have the table name now. Next steps are in Excel

• Click on AX Dynamics
• Connect it to the Company to which the data must be uploaded
• Click on Add tables and add the required tables
• You will then have some fields populated in the excel sheet. In case data is already available in those tables, the data will also populate
• Add the data as per the Fields and save. Make sure to upload the proper data in the Mandatory Fields.

The data is now added into AX. You can verify by navigating to the respective form on AX

You are good to go.!!