Recurring Journal Entry
This function is used to:
- Allocate a charge or a revenue whose invoicing only takes place globally on a given date for the periods of time concerned:
- from a global amount levelled on the basis of a time allocation structure,
- from a fixed amount to be allocated based on a given frequency.
- To generate an actual or simulated journal from a reference journal.
Once the recurring journal has been created, the "Recurring Journal generation (Financials/Frequent processes/Recurring Journal generation) needs to be used to generate a journal in accounting (see Recurring journal generation).
At the end of the recurring journal entry, it must be necessary to be able to adjust the recurring journal if the accumulated amount does not match the total of the recurring journal, or else in case of revaluation of the amount and closure of the account on an expenses account. The "Recurring journal closure" process is used to perform this levelling operation (see the Recurring journal closure documentation).
DGI Conformity
If the User needs to be conform to DGI, the FRADGI set up must be set at 'yes".
In this case:
- If a recurring journal holds at least one actual journal generated (temporary or final): it is not possible to modify or delete the recurring journal.
It is only possible to update the status "Active".
- If a recurring journal holds only simulated journals generated: it is possible to modify the recurring journal, but not to delete it.
Prerequisite
Refer to documentation Implementation
Screen management
Header
Recurring journal entries are managed from two tabs:
- a header tab gathering all the information on the recurring journal entry,
- a generation tab defining the characteristics of the journals that will be generated.
Once the setups of the recurring journal entry have been defined, its application and allocation are dependent on a template journal created on journal entry.
Each recurring journal entry must be designated with a recurring journal code and a description to be defined.
Recurring entry (field COD) |
Alphanumerical code over ten characters. |
field DESTRA |
Title of the recurring task, alphanumerical, on thirty characters. |
Active (field ENAFLG) |
This field makes it possible to extract from the circuit a recurring journal form without deleting it so as not to delete any generated entries. |
Tab Header
General
Short description (field SHOTRA) | ||||||||
The short description replaces the standard description when display or print constraints require it. By default the short title, the long title or the column header of a data are recorded (on creation/update) in the connection language of the user.
A user who logs on with this language will view the short description, long description or column header in their connection language if a translation exists. Otherwise, these descriptions will be available in the folder language. The connection language must be defined as a default language for thefolder. |
||||||||
Template journal (field REFTYP) | ||||||||
Indicate the reference of the template journal to be used for this recurring journal. The template journal can be an actual journal or not, but it is not recommended to modify it during the course of the recurring task, especially for a levelled recurring journal. This template journal will be used as a model for the generation of the actual or simulated journals depending on the parameterization of the recurring journal. The template journal must be created on journal entry (see the Journal entry documentation). The following elements are defined in this journal:
Depending on whether this is a fixed or levelled recurring journal, the Debit/Credit fields of this journal must be completed differently:
For instance: A supplier invoice is allocated on two expense accounts (75% for the first account, 25% for the second). The lines of the template journal can be entered as follows:
Thus, if the recurring task generates journals where only two accounts are balanced, a coefficient of 1 can be used. If the expense/revenue that is made recurring is liable for VAT, the fact that the template journal must not take this aspect into accunt must be checked. The "tax code" field of the template journal must be empty or refer to an exonerated code. Indeed, taxes are managed upon receipt of the invoice. |
||||||||
field REFNUM | ||||||||
No help linked to this field. |
||||||||
Type (field TYP) | ||||||||
The amount of the recurring journal can be:
|
Characteristics
Start date (field STRDAT) |
The start date represents the date of the first recurring journal entry, as well as the start date of the frequency calculation. The user should always check that the range is wide enough, to within a day, to cover all the open items of the recurring journal. For instance, within the framework of a "1 month" frequency recurring journal, if the start date is set to the 11 January, and the end date, to the 2 February, the system will only generate one monthly payment. There would have been two monthly payments if the end date had been set to the 11 February. |
End date (field ENDDAT) |
Frequency (field PERNBR) |
Define the sequencing. |
field PERTYP |
It is possible here to select the frequency:
|
Due date (field DUDDAT) |
This optional field is a payment condition used, if need be, to determine the open item date for each journal generated with respect to its accounting date. Defined here the payment condition of the open items: Check for cash, Transfer, Promissory note etc. |
Reversal date (field RVSDAT) |
The reversal date is unique for all generated entries. It is used to cancel each actual recurring journal that has been generated by reversing it. This field is optional. |
Standard recurring entry
Distribution (field DSPTMP) |
A levelled recurring journal requires the allocation of a time allocation key used to set up a payment schedule, as well as various weighings from one month to another (see the Time allocation documentation). It is important to check the consistency of this key with the frequency and the date ranges previously defined. If the date ranges do not include the allocation key in its entirety, the amount of the open items will be calculated in proportion to the rates of the period defined by these ranges. For instance: An allocation key determines that in January, 50% of the total amount will be settled, in June, 20% and in Decembrer 30%. For a total amount of 1000, the recurring journal over one year should give rise to three open items: 500, 200 and 300. If the date ranges reduce the period from January to May, the whole amount will be settled in January (50%/50%Þ 100%) The same principle applies in the case of an inconsistency between the frequency and the allocation key. |
Amount (field AMT) |
The amount to be registered corresponds to the global amount to be distributed for the whole period of the recurring task and it must be posted to the account of the first line of the template journal. |
field CUR |
The currency that is displayed corresponds to the one defined in the template journal. |
Total amount (field AMTCUM) |
No help linked to this field. |
Tab Generation
Actual generation
Entry type (field TYP1) |
What is defined here is the type of document and the journal that will be used for the generation of the actual and simulation journals. They can be different from the template journal. In effect, for reasons of journal consistency, it is possible, for instance, to decide that no template journal shall be created in a sales, purchase or other... journal. Yet, those journals generated by the recurring task can be invoices, cash collections, miscellaneous operations etc. The document type and journal proposed by default are those of the template journal. |
Journal (field JOU1) |
Formulas
Reference formula (field FORREF) |
You can define a reference or title (or both) using a formula. They will be used by default when generating the entry (displayed in journal entry or inquiry). If these fields are not entered, the reference and title will be recopied from the template journal. In formulas, you can use all the variables of the GACCENT0, GACCENT1 and GACCENT2 screens that make up the STD entry structure. They are open using the abbreviations HAE0, HAE1 and HAE2. The global variables and system variables (datesyst) are also used, as well as the NEWDAT variable, that determines the generation date of the current journal. As for the title, it represents the line number (0...N-1). If the reference or title is made of text, you must enter the description between quotation marks. You can also resort to formulas and use information from other fields. |
Formula title (field FORDES) |
Last documents
Actual/simulated entry (field LASTYP) |
Entry (field LASNUM) |
Accounting date (field LASDAT) |
Reports
By default, the following reports are associated with this function :
ABONNEMENT : Recurring entries
This can be changed using a different setup.