In addition to typing in data using the keyboard, data may also be loaded into the SUP® Integrated Accounting System electronically, i.e. by data transfer. For the system, the subsystem (financial, invoicing, physical assets, stock records, wages etc.) from which the data originate is irrelevant. The important thing is that the data transmitted from the various subsystems meet certain requirements. A common data format is used for each subsystem (invoicing, stock, wages etc.), only the rules for filling in are different.

• Data file format
  dBase (DBF) or CSV text file conforming to the data structure described below. Data are specified in the following order: journal number – record number – record line serial number.

• Data file location
  The transferred data file has to be placed in the subfolder specified through the system parameters.

• Name of the data file
  The name of the transferred data file is ATADAS.DBF or ATADAS.CSV . It is possible to use long file names; for example, in the case of monthly data transfers, the file name can include the month number.

• Code sheet of the data file
  Win1250 code sheet. As the most frequent case is the recording of incoming/outgoing invoices in the ledger, more information relevant to this case can be found in the “Other information” field.

Data file structure

Loading of Data into the Ledger from an Invoicing Subsystem

Ledger booking is most frequently done to transfer data from an invoicing subsystem designed for special needs. Thus, invoices covering the sale of products and/or services to customers are generated in an invoicing system and then loaded into the associated SUP® Integrated Accounting System (SUP). It is important to note that it is not necessary to generate two-page accounting records when booking invoices. The system automatically ensures a two-page arrangement.

Typical Problems and Requirements Concerning Booking (Receipt of Data)

NAPLOSZ field (accounting journal)

A three-digit ID used to group records in the accounting system. A separate journal must be used for each invoice type (invoice serial number range). It is recommended to create a so-called .INI parameter for this purpose.

FOKSZLA field (ledger number)

Contains the sales revenue ledger account(s). Sales revenue accounts depend on the firm’s information needs. They are most frequently associated with a certain grouping of goods. When invoices are also issued to foreign parties, the company must make sure that domestic and international sales are recorded under separate sales revenue accounts. For certain firms, sales within the EU must be recorded under a separate ledger account from sales outside the Community. Typically, an article or group of articles must be assigned at least one sales revenue ledger number parameter. If the firm’s accounting is very simple, all sales are recorded under the same sales revenue account. In this case it may be implemented as an .INI parameter. Advance accounts must be handled in a special manner, this must be discussed with the customer separately.

FOKESZLA field (ledger controlling account)

Here the so-called account number column has to be specified.(311) Typically, a different account ledger number is used for each type of invoice (each serial number range used for invoicing). Sales realised in foreign currency must also be recorded under a different ledger number.

FOLYESZ field (partner code)

Managing partner data (synchronising partner codes) is one of the most important issues in establishing data flow. Although SUP makes it possible to handle and automatically transform partner codes stored in ‘external systems’, it is best to establish uniform codes for the two systems. SUP allows this to be done later as well: by modifying existing partner codes the system can be ‘switched over’ to codes used in the sending system. In addition to the partner code, the sending system must also supply the partner name (ELLMEGN field), as new customers are basically set up in the invoicing system. Theoretically, the so-called cash invoices may be booked in two ways, but it is recommended to use the same method as for invoices for bank transfer. It is not recommended to do otherwise unless you have a very high number of cash invoices.

Cost centres, project numbers and other groups

The use of these parameters depends on the information needs of the firm served. (They include cost centre, employee, sales agent, project number, deal number, product code, etc.) The index number denoting the group to be used is determined by the dimension configured in SUP for the ledger number (ANALCSx field). If this is required, separate consultations are necessary.

Problems with rounding up/down

Records containing more than one VAT rates and/or more than one ledger numbers must be booked in as many lines as the number of VAT rates and/or ledger numbers in the record. For example, an invoice consisting of 20 lines, which is associated with one VAT rate and two sales revenue accounts, should be booked as two lines. If this occurs, care must be taken to ensure that the sum of the lines equal the invoice amount (problem with rounding up/down). When invoices are booked, due in part to the format of the file received, invoice lines must be consolidated based on ledger numbers and VAT rates (and possibly by groups). One line will include for example the sales revenue ledger account number, the net amount, the VAT ledger account number, the VAT amount, VAT code, customer’s ledger account number, partner code, partner’s abbreviated name, groups (cost centres, project numbers, product codes etc.) The sum of the lines loaded must be equal to both the total VAT sum indicated in the invoice and the gross amount to be paid by the customer. Problems with rounding up/down usually occur when (to use the previous example) the sum of the lines of the invoice booked (i.e. the tax base and the VAT amount) does not precisely equal the sum indicated in the printed invoice. For example, when an invoice consisting of many lines contains figures with decimals, it is almost certain that the amounts consolidated to two ledger accounts will not add up precisely to the total sum indicated in the printed invoice. As the difference is usually below 1 Forint, the simplest way to eliminate differences due to rounding up/down is to add the difference to (or subtract it from) the ledger line with the highest value.

Parameters may vary according to the accounting practices of the firms, which are configured by the SUP user. The majority can be implemented as .INI or core data parameters.

Loading of Mixed Data

Another frequent type of ledger booking is the loading of ‘mixed’ accounting items. One typical example is the booking of wages. The most important thing is that when loading mixed accounting records, booking will only occur correctly if the balance of the T/K record columns is zero. This can be most simply achieved by creating an ‘expended amount’ line for each line in the record. This involves the insertion of a relevant ‘expended amount’ line after each line of the record (reversing the T/K indication and the ledger number – controlling account). It is also possible to create booking entries using the so-called ‘several debit lines – single credit line’ (or vice versa) accounting model. In this case, care needs to be taken to ensure that the correctly calculated sum (balance) of the lines within a single record is zero, taking into account the correct T/K codes. In a nutshell, when booking mixed records, the sending system must ensure the two-page arrangement of the records.