Monday, February 23, 2015

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.


Friday, February 13, 2015

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.


Thursday, February 12, 2015

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

Tuesday, February 10, 2015

Supply Chain Functions


Supply Chain is a broader umbrella of the Trade and Logistics functionality in AX. Here are a few questions that are addressed by the Supply Chain functionality...

Demand Forecasting - 
What is the expected demand in the foreseeable future

Supply Forecasting - 
How much to manufacture/ procure to meet the demands

Product Procurement - 
When to buy, how much to buy, from whom to buy and when to buy.

Transportation Procurement - 
Who will do it, what are the costs

Transportation Planning - 
What will be the routes, the products shipped together, stacking and storage on the transport, stops and pickups on the route.

Transportation Management - 
What are the total costs, minimal cost routes, feasibility, tracking and modes of transport

Trade Compliance - 
Licencing and Legal compliance, trade permits, docking, cross-border compliance

Inventory Management - 
Warehousing, Logistics, Locations, Stocks to keep, Inventory Classifications, Costs, product movement principles, maintenance and expenses, arrivals and issues, counting and tracking

Order Management - 
What is the Order processing time, time to ship/ receive, scheduling orders, blanket orders, subscription management, payments and returns

Customer Management - 
What are the customer preferences, personal details (birthdays, anniversaries), account, shopping habits, experience surveys and ratings

These are just a few queries that are addressed. However, there is an ocean of capabilities where Supply Chain is concerned. All it takes is a little bit of understanding and applying.

Happy Daxing :)

Sunday, February 8, 2015

Transactions in AX

The every day activities of a business are "stored" in the system as transactions. It is these transactions that are summarized to provide the management with a view of the business, what is happening and what is forecast for the foreseeable future.

Every entry in the system is a transaction and these transactions are recorded by a process known as "posting".

A "posted" transaction is one that has been recorded in the system and will reflect the impacts.

Before a transaction is posted in the system, a New Fiscal year must be created. The  Fiscal year must then be divided into periods. No transactions can be posted unless a period is created for the date of posting.

AX posts transactions according to dates as opposed to periods. Each transaction has a posting date attached to it. The dates are the basis for summarizing the transactions in a period/ year.

Periods are equal length intervals in a fiscal year. Usually, a fiscal year is divided into 12 periods, one for each month. These are called accounting periods.

In AX, however, 2 additional periods are created for every fiscal year. These are Opening and Closing Periods. These are used to record the closing and opening balances for the year.

The accounting periods are used to record the daily transactions in the system. No entries can be made in the opening and closing periods.

This is a short summary of a very important process. More details in the posts that follow :)


.

Saturday, February 7, 2015

Transfer Order - Location Selection


Locations are assigned to Items when they are received into the Inventory. If the Location dimension is mandatory, then the location must be specified for all the inventory transactions for the Item.

One of the frequent queries is how the Location dimension is automatically picked by the system - i.e. what is the order of selection and the preference for locations in a warehouse.

To answer this query, consider the following scenario:

Items                      Location                    Quantity
Caps                       A01                                     5
Caps                       A05                                   15
Boots                     B03                                     8
Boots                     B08                                   25

Here, we have 2 items distributed over four Locations. For the purpose of illustration, let us assume that both the items are in the same warehouse. (Please note that the example holds good even if each item is in a different warehouse)

Consider a Transfer Order with the following quantity:

Item               Quantity
Caps                      3
Boots                    2

The system considers the first Location in alphabetical order. In this case, both the locations have sufficient on-hand quantity, so the Items are picked in total from the first available location.

The status of the On-hand quantity for the items after the TO is completed is as follows:

Items                      Location                    Quantity
Caps                       A01                                     2
Caps                       A05                                   15
Boots                     B03                                     6
Boots                     B08                                   25

Note the decrease in quantity at locations A01 and B03.

Now, consider a Transfer Order with the following quantity:

Item               Quantity
Caps                     15
Boots                   10

In this case, the on-hand at the first location is insufficient, but there is sufficient quantity in the second locations (A05 and B08)

The picking happen as follows:

Items                      Location                    Quantity
Caps                       A01                                     2
Caps                       A05                                   13
Boots                     B03                                     6
Boots                     B08                                     4

The quantity is split and picked from two different locations. The system picks the available quantity from the first location, then the remaining quantity from the second location (in ascending order). The system continues to move to the next location until the complete requirement is satisfied.

The On-hand status after the TO is completed is as follows:

Items                      Location                    Quantity
Caps                       A05                                    2
Boots                     B08                                   21

In conclusion: 

The system considers the first location, in ascending order, to pick an item.

If sufficient quantity is available in the first location, the entire quantity is picked from the same Location. If not, the quantity is split and the system picks the available quantity from the first location and then moves on to the next location to pick the remaining quantity. The process continues till the required quantity is picked.

The above illustration pertains to automatic selection of locations while processing a transfer order. However, users have the option of manually selecting the Locations for the items. In such case, the system picks the quantity from the location specified by the user and will prompt in case there is no sufficient on-hand available at the location for the item.

:)

Thursday, February 5, 2015

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.

Tuesday, February 3, 2015

Prices and Discounts

AX allows businesses to define price - discount combinations for different combination of Items and Vendors/ Customers. These prices are fetched when Orders are processed against the Items/ Vendors/ Customers for whom the price/ discount has been defined.

There can be different Prices and Discounts defined for different combination of Vendors, Customers and Items. The system uses a predefined sequence of searching to find the prices and apply to the transaction lines.

Below is the sequence followed by AX to determine the prices/ discounts applicable for the Order Lines.
Note: The sequence is same for Customers and Vendors. Below is sequence for Vendors. The same sequence is applicable for Customers.

Sequence of finding a Price:


Vendor (table) - Item + Size (table)
Vendor group (group) - Item + Size (table)
All Vendors (all) - Item + Size (table)

Vendor (table) - Item (table)
Vendor group (group) - Item (table)
All Vendors (all) - Item (table)

Sequence of Finding Discount:


Vendor (table) - Item + Size (table)
Vendor (table) - Item (table)
Vendor (table) - Item group (group)
Vendor (table) - All Items (all)

Vendor group (group) - Item + Size (table)
Vendor group (group) - Item (table)
Vendor group (group) - Item group (group)
Vendor group (group) - All Items (all)

All Vendors (all) - Item + Size (table)
All Vendors (all) - Item (table)
All Vendors (all) - Item group (group)
All Vendors (all) - All Items (all)

Note: The labels table, group and all specified in brackets refer to the Account Type field while specifying the Prices and Discounts.

The system picks the first available Price/ discount from the tables based on this sequence. The dates during which the Prices and discounts are applicable is the criteria for filtering multiple lines with the same combination.

There can never be mote than one price/ discount applicable for the same Item - Vendor combination unless the start date and end dates are different. In case there is another defined price/ discount for the Item-Vendor combination defined earlier, the system considers the previous definition to be null from the date when the new definition is applicable.

More on AX in future.
:)

Monday, February 2, 2015

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


Sunday, February 1, 2015

Year End Closing - AX 2009


Year End Closing is an inevitable process for all businesses. Yet, many of us are not completely aware of the details of the task in AX.

Following are the details of the process in AX 2009:

Prerequisites to Fiscal Year-End Close
  • Related General Ledger Parameters for Fiscal Year Close:
  • Set the Periods status to ‘STOPPED’: 
  • Periods form – Module status tab 

Make any adjusting entries by using the general journal
Transfer Opening Balances


Prerequisites to Fiscal Year-End Close:


1. Run the Inventory Close process through the end of the fiscal year. 

Path: Inventory Management >> Periodic >> Closing and Adjustment

The Inventory Close process will take into account the Inventory Valuation selection you have selected on the Inventory Model Group from the Weighted Average Method that is used during the month.

2. Create a new Fiscal Year 

Path: General Ledger >> Setup >> Periods >> Periods 

Create the next Fiscal Year that you will be creating transactions for. This step may have been done previously if the Fiscal Year is not closed right at Year End. 

3. Set the appropriate Periods to Stopped in the current Fiscal Year. Also Open the Closing Period to allow posting of the Closing Entries. 

Path: General Ledger >> Setup >> Periods >> Periods

Change the status of any period that should not have further transactions posted to it to Stopped. In case the period is set to Stopped, it can be reopened. Change the status to Closed only if there is no possibility of any transactions being posted to this period.
Note: A Closed Period may can not be reopened.

4. Backup Data. 

Backup the Ax data. 

5. Make Adjusting Entries. 

Make adjusting entries by passing Journals where necessary

6. Print final Financial Statements. 

Path: General Ledger >> Reports >> Periodic >> Financial Statement

Print the Final Financial Statements. This would include the Cash Flow Statement, Statement of Stockholder's Equity, Profit and Loss Statement (Income Statement), and Balance Sheet. 

7. Print 1099s for any Vendor that requires a 1099 statement. 

Path: General Ledger >> Periodic >> Tax 1099 >> Report 1099 

For any Vendor that requires a 1099 statement, please be sure to set up the 1099 forms as well as the Vendor. Please note that 1099 reports can be reprinted. 

8. Transfer Opening Balances into the new Fiscal Year. 

Path: General Ledger >> Periodic >> Fiscal Year Close >> Opening Transactions

Use this job to move the Balance\Asset Account Balances forward into the New Fiscal Year. This job will also move the balances of your Profit & Loss\Cost\Revenue accounts to the Year-end Result account which is set up in the System Accounts (General Ledger >> Setup >> Posting >> System Accounts).

Related General Ledger Parameters for Fiscal Year Close:


Path: General Ledger >> Setup >> Parameters >> Ledger Tab

  • Delete close-of-year transactions during transfer:

If this check box is selected, opening transactions and system-generated closing transactions that exist for the year to be closed are deleted when the transfer is processed again (process is repeated), in the Opening Transactions form. So with this selection, we can process the transfer multiple times, if needed, while Opening entry will be only one.

  • Create closing transactions during transfer:

If this check box is selected, the system creates closing transactions when running the Opening Transactions job. In that case, the system posts closing transactions to all profit and loss accounts and all balance accounts, although Opening Transactions are posted on balance accounts only.
  • Set period status to year closed:

If this check box is selected, the system displays a status of Year closed for all fiscal periods for the year that is being closed (when you run the ‘Opening Transactions’ job).

NOTE: Care should be taken while selecting this check box, as we may have to run Opening Transactions job several times.
  • Voucher number must be filled in:

If this check box is selected, a voucher number must be entered when opening transactions are created for a new fiscal year.

Set the Periods status to ‘STOPPED’:


When we create a new fiscal year, we may have to control or stop transactions from updating to the ledger accounts during the closing process. To stop transactions set the period(s) to Stopped status.

Periods form – Module status tab


Close all the modules, except for the General Ledger during the closing process. Often only allow for specific user groups to enter transactions and leave the period open.
To set up module status for every module, go to the Module status tab on the Periods form and select the User group in the Module user group filed area who can update the respective module.

Note: Open the year-end closing period in the fiscal year being closed to enable posting of any necessary closing entries.

Make any adjusting entries by using the general journal:


Print the trial balance in order to look for any variations and make adjustments before closing the period.

Transfer Opening Balances:


Transfer opening balances into the new fiscal year.
  • In the opening transactions process, System creates a line for the opening transaction which makes up the opening balance for the New Year.
  • The system also creates a transaction for each currency and dimension. It is necessary to maintain this to keep statistics and financial reporting. You can transfer balances as frequently as needed during the year-end close process.
I Path: General Ledger >> Periodic >> Fiscal year close >> Opening transactions

II Enter the End date of the fiscal year

III Profit and loss accounts are always reset by the system. You must specify the transfer method for the balance sheet accounts. In the balance accounts fields, you should specify one of the following two options:
  • Reset: Reset the balance accounts and enters the opening balances for the balance sheet accounts manually.
  • Closing > Opening: continues with the balance sheet accounts, and has the opening transactions created automatically by the system.
IV Enter the ‘Account for transfer of year-end result’ in the system account.

V Enter the Voucher number for the opening transactions that are created automatically.
Click OK when all the fields are entered. This process may take several minutes, depending on the amount of data.

When the process is complete, check the account balances or print the Trial balance. You can run the year-end job as many times as needed. The opening balances will update correctly.


:)