12.7.1. Accounts Gain/Loss Revaluation

The accounts revaluation process is used to obtain the revaluation of the accounts balances that have transactions in foreign currency, as indicated in OG 3055 from 2009, applicable starting with 01.01.2010.

Account Set

The process takes into account the transactions for a user-defined set of

accounts and only for amounts expressed in a currency different from the the organization's main one. The accounts set can be defined in the Account Set window,located in the Performance Analysis menu. The following fields are available:

• Name - relevant name for the record;

• Type - indicates how the account set will be used:

  • "Revaluation"

  • "Capitalization"

• Account Set Details tab - is used to define which accounts are contained by the set;

Notes:

• Each set has a Name, and it is possible to define multiple sets;

• A set can be "Active", otherwise it cannot be used in the revaluation process;

• A set can contain one or more accounts, depending on the user's choice. The decision whether to include an account or not belongs to the user.

Recommendation: do not include the accounts which have a distinct revaluation process in the accounts set (e.g. 401, 404, 411,408).

Account Gain/Loss Revaluation

The Account Revaluation process used to evaluate the ending balance of the revaluation account set (for the foreign currency transactions) for each organization at then end of the period at a certain currency type. The revaluation result is made up of obtaining the accounting records corresponding to the exchange rate differences resulting from the revaluation. The revaluation itself is kept historically and will have effects in time, from one revaluation to another.

This is an independent document, with its own sequence and with the "Reevaluare contabilă" Document Type. The document has a specific workflow, with the following standard statuses: Drafted, Completed and Re-activated. The elements contained by the Account Revaluation document are:

• Organization - the organization on the document is the one you wish to compile the revaluation for; this can also be a node, in which case the revaluation is done for all the children organizations of that node;

• Document type, Document number, Description

• Accounting Schema - schema corresponding to the organization on the document, which will be used to post the document;

• Account Date - last day of the corresponding accounting period;

• Period - the period for which the account revaluation is done;

• Currency type - the user can choose the desired currency type for the revaluation: the one defined at the account date selected above;

• Account Revaluation Synthetic - old functionality, unavailable on version 13.11;

• Account Revaluation Detailed by B.Partners (available starting with version 13.11) - is used to start the calculation process for gain/loss, which will generate records in the Account Lines tab;

• Document Status - document uses the standard workflow: "Drafted", "Completed" and "Re-Opened";

• Processed - indicates whether the document was completed;

• Document Action button - is used to manage document statuses;

Note: You must never use the two options above alternatively (i.e. always stick to the first choice). This way you can decide that, starting with a certain month, the revaluation be done detailed on business partners, so that the Account Revaluation Synthetic button may never again be used.

Calculation process particularities:

• the computation is done strictly chronologically;

• the computation is meant to be done once a month (on the last day). However, should you skip a month, the corresponding transactions will be contained in the next revaluation., so that no period is left not re-evaluated;

• all revaluations have influences upon the future revaluations;

• the reporting hierarchy - determines the organization - a filter for the organization of the transactions that are taken into account; if you choose a node-type organization on the document to indicate the whole revaluation of a parent organization, then all the children organizations belonging to the node will be included, as per the indicated hierarchy;

• the calculation period will be broken down into calendar dates (From....To.....) during the process according to the calendar; this interval will be automatically completed by the system if the latter can find a gap (a missing period) in the revaluations with the first day of the last period being the filled in the From field.

Example: there is a revaluation for January, but none for February. You run the revaluation process for March. In this case, the revaluation needs to contain the transactions from February as well, since, in that month, the revaluation has been omitted. This algorithm can only be applied if the revaluation done is not the first one (i.e. you cannot determine any other previous revaluation); the revaluation period is established for each account that needs to be reevaluated.

• the "To" date is always the last day of the period indicated on the document; this is the date used to determine currency types used for the revaluation;

• the account you are doing the revaluation for, from the lines of the account set indicated on the document;

• the currency you are doing the revaluation for - determine all the currencies you need to be evaluated depending on how many currencies you can find in the accounting transactions corresponding to the re-evaluated account, except for the main currency (the currency in the tenant accounting schema).

The content of a revaluation is made up of:

• the accounts indicated by the account sets if they have had transactions in currencies other than the main one;

• the organizations contained in the indicated hierarchy when you have selected an organization node on the document, otherwise only the organization on the document;

• the currencies different from the main one (corresponding to the main accounting schema from the tenant definition);

• the accounting transactions based on the currencies described above, including those from the previous revaluations;

• start date: "From"; end date: "To";

• revaluation currency type - keep a record of these so as to verify whether these have changed along the time;

• beginning balance of period debit - in foreign currency;

• beginning balance of period credit - in foreign currency;

• beginning balance of period debit - in RON (main currency);

• beginning balance of period credit - in RON;

• period debit movement - in foreign currency;

• period credit movement - in foreign currency;

• period debit movement - in RON;

• period credit movement - in RON;

• ending balance of period debit - in foreign currency;

• ending balance of period credit - in foreign currency;

• ending balance of period debit - in RON (not re-evaluated);

• ending balance of period credit - in RON (not re-evaluated);

• ending balance of period debit - in RON re-evaluated from the foreign currency ending balance at the revaluation currency type;

• ending balance of period credit - in RON re-evaluated from the foreign currency ending balance at the revaluation currency type;

• exchange rate differences - +/- between re-evaluated ending balance of D/C RON and the not re-evaluated ending balance of D/C RON.

Starting with version 13.11, the revaluation process calculates the exchange rate differences up to business partner level, generating lines grouped by business partner, currency and account (for those transactions without a business partner).

The rule, as according to the account element definition:

• for the active accounts, the beginning and ending balances are Debit;

• for the passive accounts, the beginning and ending balances are Credit;

• there are no bi-functional accounts for the revaluation; should there be any such account, it is considered active.

For those accounts whose balances (RON and foreign currency) arrive at 0 at the end of a revaluation period, but grouped by organizations (i.e. debit-credit not on the same organizations), these records will be marked as "0 Ending Balance" in the respective period. In this case, the beginning balance will be initialised with 0 for the subsequent periods (RON and foreign currency). This is useful so as not to carry the balances through all the revaluations if these are, in fact, only balanced on different organizations. The new transactions will be re-evaluated starting with a 0 balance.

Furthermore, verify the way an account that starts with a 0 balance (RON or foreign currency) has transactions in a month and is only balanced in a foreign currency. In this case, if there are differences in RON that cannot be written off, these will be re-evaluated and balanced.

Other revaluation-related notes:

• a revaluation document found in the Completed status can be:

  • posted - in order to produce its accounting effects;

  • re-activated - in this case, the accounting effects will be erased and the calculation process can be recommenced (it can also be wholly erased).

    • the re-activation can only be achieved if the calendar period is open.

• revaluations can only be done in chronological order; you cannot run a revaluation for a period older than that of the last revaluation;

• a document cannot be completed, re-activated or posted if the period is closed;

• you cannot generate a revaluation for a period, if another revaluation has already been done for said period;

• it cannot be verified if, following a revaluation, other foreign currency transactions have been entered in the re-evaluated period!!!

Posting the document

Completing the document will close the editing for the respective document and the computation process. A completed document can be posted.

The accounting transactions that have resulted due to the posting will only be on the principal accounting schema (RON), on the last date of the period indicated on the document and broken down on each organization on the line.

Up to version 13.12, the posting rules were:

a. for the Debit accounts:

a1. if the difference is positive then it is a favourable difference, so the posting will be of the form:

Debit account = re-evaluated account

Credit account = 765 "Realized Gain Acct"

a2. if the difference is negative then it is an unfavourable difference, so the posting will be of the form:

Debit account = 665 "Realised Loss Acct"

Credit account = re-evaluated account

with the difference in absolute amount!

b. for the Credit accounts:

a1. if the difference is positive then it is an unfavourable difference, so the posting will be of the form:

Debit account = 665 "Realised Loss Acct"

Credit account = re-evaluated account

a2. if the difference is negative then it is a favourable difference, so the posting will be of the form:

Debit account = re-evaluated account

Credit account = 765 "Realized Gain Acct",

with the difference in absolute amount!

Starting with version 13.12, the accounts used to post the document are those entered in the Unrealized Gain Acct and Unrealized Loss Acct fields in the General section of the Defaults tab of the Accounting Schema window.