Setup > Financials > Accounting interface > Automatic journals 

Use this function to define the structure for journals that must be posted for all modules. This includes posting a sales or purchase invoice entry, a depreciation charge, a payment, an automatic reversal, etc.

Each module generates entries for accounting validation in this way. This transfer is done by a standard subprogram by transferring a code for the operation. For example, the BPCIN code is called when validating a customer business partner invoice.

The application programs control the code used and the time of the call to the generation subprogram.

Setup basics and grouping lines

To set up automatic journals you need to define:

  • The header code on the journal entry screen
  • The detailed characteristics for the entry set to be transferred

You can also set up automatic journal groups to define automatic journals generated simultaneously by identifying which entries to match.

The definition of an automatic entry is made by defining

  • The entry header characteristics
  • The line characteristics by means of a series of associated line definitions


SEEINFODefining a line can lead to the creation of a group of entry lines. Indeed, the type of the lines can be unique, repetitive, or in linked table. The latter two cases can potentially lead to the creation of a group of lines.

Conversely, the lines can be automatically grouped, provided the following criteria are identical on the lines concerned:

  • The general ledger
  • The business partner (if the general ledger is a control account)
  • The site
  • The nature
  • The label for the line
  • The tax code
  • The distribution key if a distribution key exists on the line; if it is a dimension, having different dimensions does not prevent grouping lines, an analytical distribution is created.
  • The sign if the debit/credit compensation check box is not selected

Defining journals by currencies

You can define a journal by currency by indicating the posting currency in the header fields.
At this stage, managing the currency exchange rates to determine the amounts in accounting and reporting currency is made as follows:

  • The amounts in the currency and those in other the currencies are set for all the entry lines by defining the formulas for the Company amount and Reporting amount fields.
    This supposes that the calculated amounts are actually balanced in all the currencies. If not, a "Journal not balanced in currency..." error displays.
    In all other cases, (i.e., if at least one company and reporting amount is calculated), there is an automatic transfer of the conversion variance lines if not all are balanced in the reporting or company currencies.
  • If the reporting and company currencies are not defined for certain lines, the formulas defined for the Exchange rate and Reporting exchange rate fields defined in the document header are used: The non-defined amounts are then calculated by applying the rates.
  • If the previous case is found, but without the formula for the Exchange rate and/or Reporting exchange rate fields, the exchange rate type is used to determine the exchange rate on the accounting date for the entry posting. Finally, failing this, it is possible to use the exchange rate type associated with the document type to determine the exchange rate to be applied to calculate the missing amounts.

Pure analytical entries

Defining an analytical general ledger is made in the same way as a general document, but imposes an adapted document type and only entering the natures and dimensions concerned, which then becomes mandatory.

Prerequisites

SEEREFERTTO Refer to documentation Implementation

Screen management

Click Lines to open a screen where you can define the journal entry lines to generate.

Header

Fields

The following fields are present on this tab :

Enter a unique code to identify the entry structure used to validate a document in accounting.

  • Description (field DESTRA)

 

  • Short description (field SHOTRA)

 

Close

 

Entry screen

Presentation

Linked table list

Define the tables linked the triggering table. You can use the fields in these tables in the calculation formula for the previous grid.
Example: Information linked to the business partner record (BPSUPPLIER) for the journal entries can be linked to the invoice.
The second column in this grid defines the field in the triggering table whose value defines the linked record to be read. There are several possibilities: For an invoice, this can be the invoicing BP or the paying BP. Click the Selection icon for a list of possible fields.

Formulas associated with the header fields

In this grid, you can define the calculation formulas used to calculate the value of the fields in the journal entry header. The calculation formulas in this grid must be of the correct type. For example, if the amounts must be numeric, the journal code must be alphanumeric.

These calculation formulas can simply be constants in the most simple case. For example, the sales journals can be constant and called SAL: In this case, a calculation formula "SAL" is sufficient to define the journal. They can also be more complicated and include fields extracted either from the triggering table or from the links tables defined by the Linked table list explained above. In certain cases, a default value is assigned to the field if no calculation formula has been defined.

The VAT date defaults from the accounting date or the document date, depending on the DCLVATDAT – Date for tax declaration parameter (CPT chapter, VAT group) setting. However, you can enter a formula to use a custom date. This date must comply the legislation rules for the declaration.

Key fields in the header:

  • Category: a local menu field for which a numeric value must be returned: 1= Actual, 2 = Active simulation, 3 = Inactive simulation, 4 = Off balance sheet, 5= Template. The default value is 1.
  • Status: 1=Temporary, 2 = Final. The default value is 1.
  • Journal entry type: Mandatory, the journal entry number, which is assigned automatically if it is not set, and the accounting journal. If it is not assigned, the journal associated by default with this journal entry type is used.
  • Site: The default site for the user if another site it not entered.
  • Different dates: The accounting date is the current date by default. The open item date is the accounting date by default.
  • Currency: The site currency is the default. The type of exchange rate, by default, is the one associated with the journal entry type, 1 if not entered.

Close

 

Fields

The following fields are present on this tab :

Selection

  • Module (field MODULE)

Select the module where the posting originates.

 

Enter the table code where the current records triggering the accounting structure are found. For example, to validate the sales invoices, enter the table storing the invoice headers.

  • field TBLDES

 

  • Index (field KEYTBL)

Enter the database table where the master record or records are found with respect to the posting transfer.

For example:

For invoices, it is the sales or purchasing invoices. During the posting generation phase, the current record for this table is used.

This table is covered in the order of a given index.

SEEINFO By default, it is the first index. This parameter can be modified.

  • Grouping (field GRPFLG)

Select 1 Journal per line or Grouped journal to process a group of lines in the triggering table. You can choose an accounting document by line or a single global document.

1 Journal per line: This option generates one accounting journal entry when recording the triggering table. Example: When generating invoice account posts, for each record in the invoice file, an accounting journal entry is generated. The current record in the table at this time defines the invoice to be posted.

Grouped journal: This option includes all the records in the triggering table. In this case, the table possesses a principal key in N sections and all the records are covered with the first P sections of the given key (P < N).

Example: For open item statements (SOI automatic journal, GACCDUDATE table), the DUD2 key is used in three parts (the statement number, the internal identifier of the open item and the line number). One post is generated per open item statement. The table with the first part of the constant key (statement number) is browsed, exploring all its open items, to generate a single accounting document per note for all the open items browsed.

You can generate several documents based on a defined break in a detail table linked to the triggering table.

Enter the name of the field where the break must be made. In the next field, you can enter the name of the break field.

The lines in this type of journal entry are inevitably all Linked table lines corresponding to table in which the break criteria are found.

Example 1

In the group of automatic journals linked to a payment, there is an inter-currency general ledger journal that defines the variance postings linked to the payment in a given currency of a debt issued in another currency:

This journal entry is created from the PAYMENTH table (payment header), with or without grouping, to determine whether to create one journal entry per payment or, if necessary, by note.

Independent of the group, the journal entry is created by using the payment details, and if necessary a set of lines balanced by payment line: each journal entry line is a Linked table type, and the table in question is the PAYMENTD table. A "natural" grouping of lines that can be aggregated can do this. In this way, if the accounts used by the inter-currency general ledgers do not depend on the currency, there is a set of single lines even if several currencies are concerned in the note. If this is not the case, there is a single journal entry containing a set of lines per currency concerned.

Example 2

If you want to create a different inter-currency general ledger document, you need to set up in the Journal breakdown sections the name of the PAYMENTD table and the currency field name (CURLIN). The simple fact of carrying out this setup is enough to split the groups of lines created in the different journal entries.

This process can work only if all the journal lines are Linked table types based on PAYMENTD. It would not be possible to "cut" a single line on which criterion the amount of each line should be determined.

  • Field code (field REIFLD)

You can generate several documents based on a defined break in a detail table linked to the triggering table.

Enter the name of the field in which the break occurs.

The Entry split table field specifies the name of the table in which the break should be made.

  • Link subprogram (field ACTLIK)

You can intervene in the posting process in some places by calling subprograms. The action name corresponds to the label name defined in the process run when generating the automatic journal.

You can intervene at two stages in the posting process:

  • After the links defined on the automatic journal header (Link subprogram field). This is used, for instance, to anticipate the opening of additional tables, to assign global variables, or to read information specifically linked to the triggering context.
  • After the journal creation (Journal subprogram field)
  • Processing (field PRGLIK)

 

  • Journal subprogram (field ACTAFTVCR)

 

  • Processing (field PRGAFTVCR)

 

Grid Linked table list

Enter the name of the tables that must be on the line during the accounting validation of the documents.

  • Field (field LIKFLD)

Enter the name of the field in the principal table whose value is used to identify the key for the linked table. For example, in the case of an invoice, if access to the customer is required, you need to provide the field that is used to identify the customer code. In this example, there is a choice between several codes: bill-to customer, paying customer, statistical customer, etc.

Grid Legislations

  • Active (field ACT)

This check box is selected if the automatic journal is active for the corresponding legislation set up in the folder.

This field displays the legislation set up in the folder.

Block number 5

  • Negative amounts (field NEGAMT)

Select this check box to authorize negative amounts in a posting. If it is not selected, a line containing a negative amount to the credit of an account becomes a line with a positive amount to the debit of this same account and a negative amount to the debit of an account becomes a positive amount to the credit of this same account.

 
  • First date (field DATFLG)

Select this check box to accept entries that fall within a closed period that are then posted on the first date of the first open period.

If it is not selected, the automatic posting is not created and an error is generated in the log file.

  • Reference (field TYPVCR)

Select the internal naming structure when the triggering table is PAYMENTH:

  • Main account
  • Account journal – business partner
  • Bank journal – account
  • Treasury currency MO
  • Currency MO
  • Business partner MO
  • Account transfer
  • Notes P/R posting
  • Notes P/R risk closing
  • Tax stamp

The selection triggers automatic processes such as doubtful receipt entry, storage of intermediary treasury accounts, etc. The value is stored in the PAYACCNUM table and is also used to define the stages in payment entry.

Special features

  • Filter (field FORCND)

Use this field to define the filter carried out on the triggering table. The posting is generated only if the value of the expression is verified.

The fields of the triggering table and the different linked tables can be used in this expression.

Example of expression :

[TABLE]FIELD = VALUE where [TABLE] is the header triggering table. Only the recordings of the triggering table for which the FIELD = VALUE is used.

If VGLOBALE = VALUE, the table will be used only if VGLOBALE = VALUE

  • Condition (field FORCND2)

Use this field to enter a formula such as AFNC.PARAM("FRAVAT",[F:SIH]CPY)="2". If a recording is not verified by the specified condition, it is not taken into account.

SEEWARNING The recordings must be filtered before the condition is tested on each one of them.

Grid Formulas

  • Description (field INTIT)

 

  • Formula (field FORCLC)

The evaluation of this expression is used to enter the value of the corresponding field in the accounting document header that will be generated by the structure.
The fields in the triggering table and the linked tables can be used in this expression, which must be of a (numeric, alphanumeric or date) type that corresponds to the field type entered.

Two formulas specific to fixed asset automatic journals

The two following functions can be used to retrieve the label of an automatic journal or that of its automatic journal lines. This information is then used in the setup of the journal to fill the label, the description, etc. of the posting.

  • Function that can be used to retrieve the label of the automatic journal lines (DES of GAUTACED)
    (in order to put it in the posting label, for example DES of GACCENTRYD):
    func TRTCPTINT3.GET_LIN_DES

    With GET_LIN_DES which calls the LECTEXTRA function, which is identical to the supervisor sub-program of the same name that is used for retrieving the label of a field translated in the folder connection language.
  •  Function that can be used to retrieve the label of the automatic journal header (DES of GAUTACE)
    (in order to put it in the posting label):
    func TRTCPTINT3.LECTEXTRA("GAUTACE","DESTRA","PIHI","")

    With:
    1 - The name of the table in which the label is located
    2 - The name of the field containing the translatable label
    3 - The first element of the key
    4 - The second element of the key (if necessary)

Close

 

Action icon

Select all
De-select all
Inverse selection

 

Close

 

Tab Traceability

Presentation

Use these fields to link grouped accounting documents to related original transactions in the main general ledger only. This in turn enables a direct link (Tracking/Payments) to related documents from the journal entry lines.

This is only possible for automatic journal groups and where auto journals are used in the payment process.

There are two tracking options:

1. Data linked to an accounting document such as an invoice or a payment.

Upstream traceability is automatic when you select the Traceability check box. Then, you select the Triggering table and Index.

This enables the following option on the accounting document line:

Payments: Provides direct access to each original payment.

Tracking: Opens the Follow-up of an accounting line screen to view a summary of original triggering documents. This screen displays a summary line for each payment and a total for all lines based on the fields entered in the Parameters grid. You can click the Payment line action for each payment to see details.

2. Data not linked to an accounting document such as open items, stock, fixed assets, etc.

Upstream traceability is not automatic and a detailed set up is required. In addition to the steps above, you need to enter an Action and set up the Parameters to display accurate data from the triggering table.

 

Fields

The following fields are present on this tab :

Block number 1

  • Traceability (field TRCFLG)

Select this check box to enable tracking. When you select this check box, the remaining fields for traceability become available.

Enter the table that represents the link between the original document and the accounting entry. For example, between payments or stock movements and the accounting entry.

  • Index (field TRCKEY)

Enter the index code from the triggering table to include that data on the accounting entry lines.

Block number 2

Enter the generic action GASACCNUM1 to trigger the link.

You also have the option to enter standard actions such as Object management, Inquiry, or Window entry.

The action you enter affects the fields entered in the Parameters grid.

Grid Parameters

  • field TRCCODPAR

This field displays the code for the field.

  • field TRCVALPAR

Enter fields from the triggering table to display data when you select Tracking to open the Follow-up of an accounting line screen.

This is required when setting up traceability for data not linked to an object. These fields maintain the link between the source data and the related accounting document lines.

 

Reports

By default, the following reports are associated with this function :

 GAUTACE : Automatic journals

This can be changed using a different setup.

Menu Bar

The following fields are included on the window opened through this button :

Grid Legislations

  • Active (field ACT)

 This field indicates if the automatic journal line is active for every legislation set up in the folder.

 

Grid Ledgers

  • Ledgers (field LEDTYP)

 

Tables

Defined here is the name of the linked table, from which will make it possible to generate the different entries in the accounting document.

Defined here is a second table linked to the first, if multiple analytical postings need be given to each line in the entry.

  • Analytical link (field LIKTBL2)

This field is used to describe the analytical key and thus to create a link between the records of the general table (General field) and the ones of the analytical table (Analytical field).

Grid Linked tables

  • Linked fields (field LIKFLD)

Line type

  • Line type (field LINTYP)

This field takes one of the following values:

  • unique: only a single entry line is generated; its characteristics are given by the next fields of the screen.
  • repetitive: a variable number of lines are generated, according to the value of an index that varies within a range evaluated from the formulas shown in the table below. 
  • linked table: an entry is generated for each record in a table linked to the first table (generally a table of lines associated with the header table). In this case, it is possible to have a second linked table to specify analytical distributions.


  • Condition (field FORCND)

This is one of three logical conditions relating to the values of the fields of the principal table, as well as the general table if it is a line of linked table type (this includes, if necessary, constants and functions). If these conditions exist, they must be verified for the line to be generated. In the case of the setup of a repetitive type line, these conditions can use the index variable.

The conditions differ depending to the type of line:

  • linked table: use the values of the principal and general tables. If these conditions exist, they must be verified for the line to be generated.
  • repetitive: use the index value in the conditions.

If this condition, expressed in the form of a logical expression, is false, then the entry is not generated.


Dimensions

This code is used to assign default dimensions different from those defined in the setups used to assign dimensions to the original documents of the entry. Use of this code remains exceptional.
For example, in the case of inter-company BP invoices: when counterpart entry lines are generated, if the counterpart account is processed in analytical mode and one or several companies contain an analytical ledger checked Mandatory dimension type entry, Sage X3 only considers the default dimension setup when assigning dimensions to the propagated analytical accounts.
When an analytical ledger is not checked Mandatory dimension type entry but a dimension type is defined as Mandatory at company level in the associated dimension, Sage X3 initializes the dimension linked to the account record as a last resort.
Finally, note that the corresponding setup must only use the variables linked to the on-line tables as they are defined in the automatic journal (no mask is on-line in the execution context).

  • Detail line condition (field DETCND)

This field may contain a logical expression. If this expression exists, it is evaluated and it conditions the use of the detail criterion to aggregate or breakdown the lines (this criterion will only be used if the condition is true). If the expression does not exist, the detail criterion is used (as if the expression exists and if its result is true).

  • Netting (field DEBCDT)

If the answer to this field is No, all the entries generated from this parameter line are grouped together only if they are have all the characteristics listed below in common:
site, general account, business partner account, analytical distribution, nature, tax code, sign
Thus, two entries that have opposite signs but the other characteristics in common are not accumulated.
If the answer is Yes, entries with opposite signs and common characteristics are offset (if the resulting amount is null, the entry is not generated).
Entries done with postings on analytical dimensions without distribution will be grouped together if the other characteristics are identical (a distribution in amount, associated with the general entry line, will then be created)

When several lines generated by a repetitive or linked table line type have the same characteristics (general ledger account, site, BP account, nature, tax code and analytical distribution in the case of of postings done with distribution keys), they are grouped into a single line. If the postings differ by the analytical dimensions, a distribution of the analytical posting amount is created by grouping on a single line at the level of the general accounting. This tick box is used to specify whether the posting sign must also be taken into account during the generation. If the box is ticked, the postings with similar characteristics and different signs are grouped (the total amount being the algebraic sum of the amounts). If not, there will be a posting line for the debit and another for the credit posting.


  • Control account (field FLGDUD)

The "Control accounts" box is checked by default on the first line of the automatic journals of the purchase, sales and BP invoices. This first line is used to generate the BP tax incl. line.

If an invoice automatic journal is set up to generate the BP line elsewhere than the first line, the "Control accounts" box must be checked. Upon invoice validation, the BP tax incl. line is associated with its open items, and the invoice is then matched.

  • Double entry line (field CPALIN)
  • Group of lines (field LINGRP)

 

  • Traceability (field TRCFLG)

Grid Accounting codes

  • No. (field NUMLI2)

 

  • Accounting code (field TYPACCCOD)

This field defines the accounting code type used. This local menu defines all the tables in which an accounting code that may be used in the entry generation can be found.

There are numerous accounting code types. These include the following types: Product, Customer, Supplier, Commercial, Buyer, Document, Company, Site, Currency, Tax, Footer, Discount, Bank, Payment, Fixed asset, etc.

For a given type, a group of definition lines characterized by a title is attached. For example, Purchase modifier, Sales modifier, Fixed asset modifier… in the case of a Product code type. Each of these lines is used to define either a general account, or a general account section (the non-defined characters being represented by x) and an analytical nature. The setup that is used to define the lines associated with an accounting code is defined in a dedicated function.

During the automatic generation of the journal entries, the determination of the general account is made by successive searches of the accounting codes in the order declared, by looking to assign only the portions of the account not yet determined. The analytical nature is successively searched for by checking the accounting codes and stopping when a nature is defined.


  • Index (field ACCNUM)

The index you enter refers to the accounting code line to be used. The selection function displays the exact title of the accounting code lines.
Reminder:

  • The set of lines linked to an accounting code type is defined at the level of the Accounting code lines function.
  • The standard titles of accounting code lines are taken from Local menu 853 - Texts of accounting code lines and the specific and editable titles are defined and recorded in Local menu 2820 - Account specific text (853).
  • Description (field LIBIND)

This non modifiable field displays the title of the selected index.

  • Identification key (field ACCKEY)

The user specifies here an expression that assign the value of the table key, for which the accounting code is searched for.

  • Condition (field ACCCND)

If this field is filled, the search for the account code is only done if the result of the evaluation of this logical expression is true.

Close

The definition of the characteristics of the entry lines is is triggered by the corresponding button. There is the possibility to select the different lines with the help of a left list, or to create new ones. These entry lines are characterized by a type, general conditions and a list of formulas so as to evaluate the various fields of the lines.

The link grid

This grid is used to define the tables where the contents must be on-line for the determination of the posting line characteristics. The defined characteristics are the table name and the field that will give the value of the principal key. Only the tables directly linked either to the principal table of the automatic journal or to the general table (for the lines of the type Linked table) can be selected.

The accounting code grid

This table is used to:

define the links between the table of the lines and the annex tables (for example the products on the invoice line), in order to use the fields in the tables linked in this way in the field expressions for each line of the entry.

determine the General account field (if it not determined completely by an expression, or if the expression is not defined) and Nature field (if it is not defined) by successively applying accounting codes (with respect to the order of the table declaration).

An accounting code is an alphanumeric code present in the database records of the software, which is used to influence the entries generated from the information coming from the corresponding record. The accounting code table is characterized by the code type and the alphanumeric code defined for the user (for example FRANCE, EXPORT in the case of the codes linked to the customers, SERVICES, PRODUCTS in the case of the codes linked to the products).

There are numerous accounting code types: Product, Customer, Supplier, Commercial, Buyer, Document, Company, Site, Currency, Tax, Footer, Discount, Bank, Payment, Fixed asset etc.

For a given type, a group of definition lines characterized by a title is attached. For example, Purchase modifier, Sales modifier, Fixed asset modifier… in the case of a Product code type. Each of these lines is used to define either a general account, or a general account section (the non-defined characters being represented by x) and an analytical nature. The setup that is used to define the lines associated with an accounting code is defined in a dedicated function.

During the automatic generation of the journal entries, the determination of the general account is made by successive searches of the accounting codes in the order declared, by looking to assigned only the portions of the account not yet determined. The analytical nature is successively searched for by passing through the accounting codes which only stops when a nature is defined.

For instance:

For a sales line, the accounting code is defined by the expression " 7xxxxxxx" and the following elements are present in the table of modifiers:

Product

Sales modifier

Sales executive

Sales modifier

Site

Sales modifier

Currency

Sales modifier

  • if the product present on the line has the accounting code SERVICE, and that in the accounting code table the Account = "xx23xxx",
  • if the commercial present in the line has the accounting code Export, and that in the accounting code table the Account ="xx2x2",
  • if the site present in the line has the accounting code NORTH, and that in the accounting code table the Account ="xxxxxxx48",
  • if the currency present in the document has the accounting code EURO, and that in the accounting code table the Account ="xxxxx45xx",

the accounting code is determined by 6 successive passes:

starting from the original code, that is :

7xxxxxxx

the mask x23xxx is applied, giving :

723xxxxx

the mask xx2x2, giving :

723x2xxx (the 1st 2 is ignored)

the mask xxxxxxx48, giving :

723x2xx48

the mask xxxxx45xx, giving :

723x24548

no other mask is applied, the remaining x are replaced by zeros to give the final account :


723024548

If the nature is not defined by a formula, searches are performed successively in:

  • the nature in the product accounting code,
  • the commercial accounting code,
  • the site accounting code,
  • the accounting code associated with the currency.


SEEINFOThis procedure is very flexible and makes it possible to use the roots given for the accounts with the sections of the account depending on the context. It is not mandatory to define the accounts of the type. If the sales account is required to be defined by 703 followed by the characters 2 to 3 for the TSICOD field (statistical group should be numeric) for the product table (the abbreviation ITM), then a formula of the following type will be defined for the account.

"703"+seg$([F :ITM]TSICOD,2,3)

the link to the product table is defined by an account code line.

List of the fields to be completed in the accounting code grid.

1. the accounting code type, the line number, which are used for the search for the account and the nature (the number is entered and the title is displayed, the selection window displays the title directly).

2. An expression is entered where the value corresponds to the key in the table linked (product, customer, supplier).

3. An optional logical expression. If this expression exists, the link to the table and the application of the accounting code are only implemented if the result of the expression evaluation returns the results equal to true.

In the group of entered expressions, it is possible to use fields extracted from the on-line tables, which are:

  • the principal table defined in the header screen,
  • the tables that are linked to the principal table in the header screen.
  • the tables defined in thegeneral table andanalytical table if the line type to be generated is Linked table.
  • the tables that are linked in the line screen.
  • the call to the dedicated functions, using the syntaxfunc TRT.FUNCT(arguments), whereTRT is the name of the process andFUNCT is the name of the function to be called. A certain number of functions that are particularly interesting for the automatic journal context have been defined in the AFNC process: these functions are defined in the following grid.

Function

Parameters

Result

AFNC.ACTIV(COD)

COD=activity code (alpha)

0 if the activity code is inactive for the folder, 1 if it is active

AFNC.PARAM(PARAM,SITE)

PARAM=parameter code (alpha)
SITE=site code (alpha)

the setup value (alphanumeric over a maximum of 30 characters)

AFNC.CONSULT(ACCES)

ACCES=access code (alpha)

1 if access is in display mode for the resource controlled by the access code, 0 if not (if the access code is empty, the result is 1)

AFNC.MODIF(ACCES)

ACCES=access code (alpha)

Identical to the previous, for the modification rights

ADNC.EXEC(ACCES)

ACCES=access code (alpha)

Identical to the previous, for the execution rights

The following fields are included on the window opened through this button :

Block number 1

  • field OBJET

 

  • field CLES

 

Block number 2

  • From folder (field DOSORG)

Use this field to define the folder from which the record will be copied. The possible syntaxes are described in the Dedicated appendix.

  • All folders (field TOUDOS)

Use this option to copy the record to all the folders defined in the dictionary (ADOSSIER table of the current solution).

  • To folder (field DOSDES)

Use this field to define the folder to which the record will be copied. The possible syntaxes are described in the Dedicated appendix.

Close

This button is used to copy an automatic journal to another folder.

The grid of the formulas associated with the fields in the posting lines

This table is used to define calculation formulas for all the fields of each accounting document line. The calculation formulas must be of the correct type: the amounts must be numerical, the account code alphanumeric.

These calculation formulas can be constants in the simplest cases. They can be more complicated and include fields extracted from the tables previously described, to which are added the tables defined by the accounting code table.

You can use the index variable if the line type to be generated is repetitive.

A group of variables exist that can be used by means of the syntax V_XXXXX. These variables are loaded by a call to a sub-program defined in the variable setup function. Otherwise, the call to a sub-program uses parameters.

From the Formula field, select Parameters from the Actions icon menu to define the values for these parameters, by specifying an expression that can use constants, operators, functions and all the fields in the online tables.

The Formula wizard is also available from the Actions icon menu to help write valid formulas.

The most noteworthy fields in the entry lines are:

  • Account/s:This can be a formula with or without variables, like X, or left blank. When an account is not completely defined, the accounting codes table is used to define them.
  • Business partner:The BP code when the account previously given is a control account.
  • Amount: This is positive unless an entry is to be passed is negative, and the quantity if the work units are used.
  • Sign: This should be +1 if the entry is to be passed as a debit to the account and -1 if it must be passed as a credit.
  • The different analytical allocations
  • Site: for the line
  • Stat code: There are 3 standard.
  • The detail criterion. This field is particularly important in the case of entries relating to payments. It is used to define if one or several entry lines are generated. The lines with identical characteristics, (i.e.,site, general account, or BP) are grouped if they have equal detail criteria values.
    If the value is different, lines are split. Note that having multiple analytical dimensions is not a splitting criterion if they are not distributions. A distribution is created with an amount pro rata.


The grid below gives examples from the payments:

Grouping expression

Explanation

[F :PYD]LIN

A line by payment allocation, without attempting to group identical lines.

[F:PYD]VCRNUM

One line per invoice, (i.e., the allocations of several open items for the same invoice are grouped together)

  • Free reference: This field is used in the matching and can serve as a matching criterion. It can be entered by any field.
  • The label: Two functions are used to recover the title of an automatic document or its automatic document lines and to use them in the setting up a document (title, description, etc.).

func TRTCPTINT3.GET_LIN_DES

Is used to recover the title of the line of the current automatic journal

func TRTCPTINT3.LECTEXTRA("GAUTACE","DESTRA","code de la pièce auto","")

Is used to recover the title of the automatic document header.

For BPCIN and BPSIN automatic journal codes:

  • Project: By default, the project code is filled with this formula (func PIMPL_CSTD_PROGS.PJM_KEY_SPLIT_OPPNUM(GACTX,[F:PIL]PJTLIN)) that splits the code between the budget and project. However, you should replace it with: ([F:PIL]PJTLIN) to include the project code in automatic journal entries.
  • Cost type: Enter the cost type so that it is included on related accounting documents from upstream functions.

The actions grid

This grid is used to define calls to the sub-programs for specific technical events in the accounting process. These sub-programs, identified by the name of the label and the process name are supplied as standard. It is therefore advisable to avoid modifying them. It is possible, within the framework of certain specific/custom processes, to write new processes associated with these actions.

The technical events that exist are:

Action before line creation

Used to define two criteria, CRITIMP and CRITMTC, according to the fields in the principal table with the abbreviation TB0 or the secondary table with the abbreviation [TB1]). These criteria are used, in the management of the entries linked to the payments and to group or not the lines. This action is used as standard with the following values:

 

Action values

Effect

 

REGROUP / PAYCPTA

To manage the grouping or the detail of certain entries on the intermediary accounts (same principle as the Detail criterion, but 'hard-wired' by the standard process logic).

Action after line creation

It is used in the management of entries linked to payments. This action is used as standard with the following values:

 

Action values

Effect

 

APLIGBAN / PAYCPTA

Storage of the treasury account in a variable to be processed later, and triggering the devaluation of the cash management.

 

 APLIGFAC / PAYCPTA

Update of open items on the movement lines of the bill-to BP with the payment open item number in order to manage accounts on customer and supplier orders.

 

REGROUP / PAYCPTA

Management the grouping of certain entries in intermediate accounts.

Link action

It is used to call a sub-program to read the information linked in a non-standard fashion (it is placed at the level of each line).

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

'Syntax error' (followed by explanatory details)

The syntax of the Adonix expression entered is not correct (for example the number of arguments of a function is not correct or even a bracket is missing). It should be noted that it is impossible to detect the more complex errors in the expressions (for example, division by zero, non-existent variable…). These errors will be detected at the time of the generation of the entries, a complete list will be found later.

'Link not possible'

This signifies that an attempt has been made to link from the triggering table to a table for which the dictionary does not recognize the link (for example, a link between the invoice header and the product table).

This can also arise if the link field is incorrect (when a table to be linked has been entered, the possible link fields can be chosen from a selection window).

'Incorrect Index'

This message is displayed if the index number used for an accounting code does not exist (for example, if an attempt is made to use index no.4 for a Buyer accounting code).

Error messages on the execution of the journal entry

The errors given below can arise during the generation of the entries (on accounting validation of the invoice for example). The majority of these errors come from an imperfect setup. Some only happen if the maintenance operations have altered certain data.

'Non-existent Parameter Code'

The setup code called by the generation operation does not exist.

'Triggering Table not Referenced'

The triggering table is not accessible at the time of the generation.

'Non-existent Triggering Table'

The triggering table does not exist.

'Incorrect Number of Arguments'

The number of elements in the keys for the principal table does not correspond to the expected number.

'Non-existent Key'

The value of the key corresponding to the current record in the principal table no longer exists or does not respond to the generation conditions.

'Non-existent Secondary Table: XXX'

The secondary table XXX given in the setups for the generation of a line does not exist.

'Non-existent Analytical Table: XXX'

The analytical table XXX given in the setups for the generation of a line does not exist.

'ZZZ : Error in Field Evaluation'

(followed by an error message)

During the evaluation of the ZZZ field at the time of the journal entry generation, the error corresponding to the message that followed it has occurred. This error can be due to several reasons (non-existent variable, division by zero, etc.).

'Incorrect Link on . . . XXX'

The link to table XXX linked to the header cannot be made (for example, in the case of an invoice, if XXX is BPC, the invoiced BP code does not exist).

'nnn: Non-existent Account Code'

This signifies that a reference has been made to a non-existent accounting code or a non-existent line number (the no. nnn) for a given accounting code (for example, the code no. 12 for the product accounting code).

'Non-existent Sequence Number'

The sequence number counter attached to the type of journal entry to be generated does not exist.

'Sequence Number exceeded'

The range of numbers assigned to the type of journal entry to be generated has been exceeded.

'XXX: Non-existent Site'

The site field makes a reference to a non-existent site code after evaluation.

'XXX: Non-existent Company'

The company field makes a reference to a non-existent company code after evaluation.

'No Currency Exchange Rate'

The exchange rate corresponding to the given setups could not be found.

'ttt: Non-existent Journal Type'

The type of journal entry ttt is non-existent.

'Transaction Cancelled'

The transaction could not be carried out (normally another error message will have appeared).

'Actual Journal already exists'

An attempt has been made to create a journal entry with a journal number corresponding to a journal entry that already exists in accounting.

'Temporary Journal already exists'

An attempt has been made to create a journal entry with a journal number already assigned to a temporary journal entry.

'No Line'

An attempt has been made to generate a journal entry without lines.

'Unbalanced Journal'

An attempt has been made to generate an unbalanced journal entry.

'Unbalanced Distribution'

An attempt has been made to create an unbalanced analytical distribution (in amount).

'Unbalanced Distribution (quantity)'

An attempt has been made to create an un-balanced analytical distribution (in quantity).

'Non-existent Account'

An attempt has been made to pass a posting to a non-existent account (this can only happen if the setup that makes the automatic creation of non-existent accounts possible has been deactivated).

'XXX xxxxx: error message'

This message type can arise during the control phases before the passing of the posting. These messages can be very varied, XXX being the code of the table and xxxxxxx the key on which the error occurred. For example, if the site and the company set up are not coherent, it is possible to have a message of the following type:

FCY  AAA: This site is in the ZZZ company

(here, FCY is the abbreviation of the site table and AAA the corresponding site code) 

Tables used

SEEREFERTTO Refer to documentation Implementation