Recurring Journal Entry

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

• 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.
You can add your translation in another language using the Translation function:

• Click Translation from the Actions icon in the corresponding field.
• In the Translation window, add a new language code with the translation in this language.

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:

• the entry transaction,
• the site,
• the account postings,
• the propagation on the different reference types, the analytical postings.

Depending on whether this is a fixed or levelled recurring journal, the Debit/Credit fields of this journal must be completed differently:

• for a fixed recurring journal, the amount to be made recurring must be entered.
• for a levelled recurring journal, a coefficient must be entered on the first line.
  This coefficient will be used as the basis for the allocation of the open item amount in proportion to the coefficients of the next lines.

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:

• Fixed: a fixed amount to be paid according to a specified frequency (every n days, weeks, decades, months etc.). Each generated journal will be the true copy of the template journal.
• Levelled: a variable amount to be paid according to a specified frequency (every n months). The global amount will be defined and posted to the account of the first line of the template journal for the entire duration of the recurring journal. Each generated journal will then be so generated in proportion to a time allocation key.

• 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 end date limits the calculation of the recurring journals

 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:

• day,
• week,
• decade,
• two weeks,
• month.

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

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

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

Indicate the journal code to be used for the actual generation.

• 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, GACCENT1and GACCENT2screens 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)

• Actual/simulated entry (field LASTYP)

• Entry (field LASNUM)

• Accounting date (field LASDAT)