The global application 'Create company carry forward for the new period' (PERGES) is designed to transfer various business-related data from a source area over to a target area.
The selection fields V Company, V-GB, V Period and V Type of data are available for the source area while the selection fields Company, G Area, Period and Type of data are available for the target area.
The application shows all of the applications that can be carried forward with the help of this function in the column entitled "Menu item".
Image: Overview of PERGES
Image: Actions in PERGES
[Display list] : Marking a menu line in the overview and activating the action menu "Display list" will allow you to branch off directly into the menu item you have marked.
[Create company carry forwards for a new period (without the globe)] : By carrying out this action, the carry forwards from the marked application will be performed for the company selected.
[Create company carry forwards for a new period (global)] : By carrying out this action, the carry forwards from all applications displayed will be performed for the company selected.
[Check carry forwards for a new period] : The application PERGES will be run for simulation purposes if this application is activated. The target data will not be written, however, but rather the new transactions that are detected will be compared with the transactions that already exist for this period and any differences will be displayed. In this case, only the databases listed in the period (previous and current period) and master database according to the switch setting will be checked.
[Processing control] : Branch off into the overview application processing controlls
Due to the fact that the PERGES application only allows you to carry forward the data from one company, mass processing offers you an alternative means of forming carry forwards: across all of the companies from the company financial statements + monitor . In this case, you must mark the relevant companies and activate the respective types of processing in the action column. With mass processing, processing can also be initiated even for those companies for which no data on forming carry forwards exists. In this case, IDL Konsis sends a message that says that no data exists. You can ignore this message. Afterwards, IDL Konsis will continue processing the next company.
Image: Create company carry forwards in company financial statements + monitor
The message window produced by the period carry forward contains a summary status message at the foot. Here, a distinction is made between general errors, warnings and a note for each currency. By marking the checkbox 'Do not display this message again', you can prevent all of the message windows that contain the same summary status message from being displayed during mass processing (mark multiple companies in the company financial statements + monitor, for example). In this case, the same user reaction (for example, 'no processing and continue') will be assumed. The contents of the message window will be collected and displayed in an overall message window when mass processing has been completed.
If the previous period is an annual financial statement (period symbol J according to the application ABR), the carry forwards will be formed depending on the type of posting specified in the voucher header:
CAUTION! If the previous period is a monthly or quarterly statement, (period marked M or Q according to the application ABR), then the postings will be transferred over to the following period 1:1, without summaries, relocations or reclassifications.
In any case, the voucher number of the posting from the previous period will be retained.
Note: If it is determined that a voucher was mistakenly not posted as recurrent or erroneously directed to recurrent during the previous period, the type of posting for this voucher can be modified afterwards for the previous period. During the next carry forward, the desired formation of the carry forward can be achieved by deleting the existing vouchers and postings that have the same voucher numbers in the target period and replacing them with the voucher that is to be carried forward. If the voucher that already existed during the target period was created using the posting type E, an error message will be generated.
Postings in accounts for transaction development to convert using weighted monthly average curves MDK (posting key with the usage code 'M') will be carried forward like the transactions on this transaction development over the course of the year with the conversion rule 'VKW' or 'VPW' so that a weighted monthly average price can be calculated. These types of postings are not deleted during calculation of current depreciation, therefore perhaps only the depreciation for the last month needs to be calculated and recorded. When transferring the data over to the next type of data, the carry forwards calculated on the basis of monthly prices during the course of the year will be taken into consideration accordingly.
With a carry forward from a period, a check will be performed on whether accounts are listed in the control blocks carried forward for currency conversion (WUM) and the calculation of deferred taxes (LTK) that are no longer valid during the target. If this is the case, appropriate notice will be given. The carry forward will still be performed, however.
Development transactions
The application "Create company carry forwards for the new period" (PERGES) shows one line for every transaction development, for the status to be displayed on the one hand and to initiate an individual carry forward of this transaction development as a line action. The lines for the transaction development are determined dynamically with the help of the transaction development defined in the application SPI. Here, the respective checkpoint ID ("SPI-" + transaction development key) serves as a replacement "Menu ID". Transaction developments without carry forwards according to the definition in SPI will be suppressed.
The allocation of usage tags in the application BSL is of particular importance. Here, we would like to point to the documentation BSL-Usage tag . Of particular importance is the allocation of usage tag in the application BSL.
Fixed asset transactions are only carried forward if the fixed asset transaction mark in the application type of data/transaction development (FACSPI) has been selected for the current type of data. All of the transactions from the previous period will be carried forward. All of the carry forwards that already existed during the target period will be deleted in the process.
A carry forward on capital transactions is only performed if the checkmark for capital transactions has been entered for the current type of data in the application Fact/development (FACSPI). All of the transactions from the previous period will be deleted in the process.
Image 1: Capital transactions in I3 in 2008
Image 2: Posting that affects results in I3 in 2008
Image 3: Capital transactions in I4 in 2008
Image 4: transactions in I3 in 2009
Image 5: Carried forward posting that has an effect on results in I3 in 2009
Image 6: Capital transactions in I4 in 2009
Provision transactions are only carried forward if the tag for provision transactions has been set in the application Fact/development (FACSPI) for the current type of data.
Development transactions are only carried forward if the code for the respective development transactions has been entered in the current type of data in the application type of data /transaction development (FACSPI).
The framework data for currency conversion from an individual company that is stored under currency conversion header records (WUM) is carried forward. In this case, the cumulative balance sheet conversion difference is transferred and entered into the field entitled "Difference balance previous period". No carry forward is to be performed if data already exists in the target period.
The carry forward of account conversion rules is directly linked with the carry forward of currency conversion header records KW/PW from a content standpoint. If the conversion rule for an account deviates from the standard for the conversion process that has been selected, then this table will contain the link between these accounts with the respective conversion rules, for example "subscribed capital = updated average price (FDK)".
Comment: If a prescribed price has been entered under account conversion rules (VK) (VK = 90.00, for example), then this rate will be used 1:1 during the target period. Perhaps this rate will need to be adjusted manually for the current period.
The deferred tax header records for a company (without specifying a group/sub-group) will be transferred over to the current period from the respective previous period if no report header records have been defined there yet. No carry forward is to be performed if data already exists in the target period. When carrying forward, the comparison period is to be modified in such a manner (analogous to copying into REP) that the difference between the current and the comparison period is preserved.
All of the company report header records from the previous period are to be carried over into the current period. No carry forward is performed if data already exists in the target period.
Report header records whose report ID is invalid during the target period are not carried forward.
With a carry forward of report header records that specify a previous period, the period code of the previous period is to be evaluated. This ensures that a previous period that represents an annual account is retained if the current period it comes from does not represent an annual financial statement, or is increased by 3 if the current period is carried forward to a quarterly or monthly financial statement from an annual account. In the same manner, previous periods that represent a quarterly financial statement are retained if the current period represents a monthly financial statement, or is increased by 3, if the current period is carried forward to a monthly financial statement from an annual or quarterly financial statement. In all other cases, the previous period is always increased by the carry forward interval.
When this application is activated, the carry forward for a period is performed for simulation purposes. The target data is not rewritten, however. The new transactions that are calculated are compared with the existing transactions from this period and any differences that might occur are shown in a protocol. The application generates a file on the results of its evaluation in the processing control system (VERARB) using the checkpoint 'SIMPER'. The message entered here determines the respective status that is displayed in the company financial statements + monitor.
If the source period contains absolutely no data, the company financial statements + monitor will show '–' as the status of the comparison.
will show '–' as the status of the comparison. The status for the comparison of carry forwards will be automatically set to 'yellow' (Result of the comparison is no longer current), if carry forward data from the current period has been changed. Additional files (checkpoints) are put to use in the company processing controls (VERARB) for this purpose. In fact, a checkpoint of its own is used for carry forwards for each defined transaction development area. This also enters a control value for carry forward data, in other words all transactions with posting keys that are contained in the same transaction development column like a posting key for automatic carry forwards (with the appropriate control in the data type (FACSPI)) for automatic carry forwards (usage tag 'V'). The change in the control value changes the status of the comparison of carry forwards.
This function includes the possibility of suppressing immediate display of protocols. Therefore, this function can also be activated as mass processing in the company financial statements + monitor or in an automated process machine without having to confirm this step for every company processed. The complete protocol for all of the companies will be displayed once processing has been completed.
Generally, the last available annual financial statement will be reproduced inside the consolidation system when IDL Konsis is first implemented. For this reason, it is impossible to work with previous periods in the reporting part during the year that the software is first introduced. Therefore, initially no previous period will be made available in the year that follows with respect to a carry forward of report header files. If you are interested in working with the comparative period during the second year of reporting, then the comparison period can be added after the carry forward.
A more elegant approach, however, would be to use 'change quantities' (under action) with respect to the previous period for all companies, especially when there is a large number of report header files. In this case, the desired comparative period will also be shown when the process is changed.
Image: Change quantities company report header files
The change process should be initiated before PERGES carry forward. The recommended process also applies for interim financial statements.
The carry forward by way of PERGES can be performed any number of times. Carry forwards that already exist in the transaction development applications from the target period will be deleted before the new entries can be added to the current period.
Attention: Additions made manually by entering them in the carry forward postings for the target period will be deleted when a new carry forward is formed. The following applies for transaction development applications: When there is a repeat carry forward from a starting period = annual financial statement in the period that follows, all of the manual changes that were made in the carry forwards from the target period will be deleted. If the carry forward from a starting period = repeat of the interim statement, then all of the development transactions that already exist for the target period will be deleted.
Image: Message panel in the event of a repeat carry forward
The message that appears above must be confirmed using "Write data", if the repeat carry forward is to be performed.
A carry forward from the previous period to the new period also needs to be performed for the data type I4 (trade balance II). This is necessary for all companies that use foreign currencies so that the historical carry forwards are saved in group currency.
Chronologically speaking, however, the formation of this carry forward should take place after the GESABV from the data type I3 to the data type I4 because the transaction development data from I3 to I4 will be automatically deleted before they are converted over to the target type of data (I4). This means that the historical values in group currency will be missing in the target type of data. Nevertheless, these will definitely be needed in order to be able to link into the historical group currency amounts (per 01/01 of the respective fiscal year, for instance) and thus arrive at the proper calculation of the balancing item from the currency conversion as well as exchange rate differences in the development transactions.
Recommended procedure:
If it is determined that the currencies (WKZ) for group and/or parallel currencies from the previous start up data (VORADMIN) deviate with the carry forward for a company financial statement (or a partial function for individual databases) for a period whose currencies have not yet been determined, a tracking query will be initiated (similar to currency conversion) that is designed to serve as the currency code for the new period and that of the previous period or as a standard preset value. The currency code for the new period will be entered accordingly.
The application GESABV is designed to carry forward balances and transactions from one type of data to another during the same accounting period. Simultaneous carrying forward of data types for multiple companies can be started by using the action "Create company statement for new type of data" from the company financial statements + monitor. Unlike the application GESABV, however, it is not possible to limit the carry forward to individual areas, for instance, only the account balances, in the company financial statements + monitor.
The application GESABV shows one line for each transaction development, to display the status, on the one hand, and to initiate an individual transfer of this transaction development as an action line. The lines for the transaction development will be generated dynamically based on the defined transaction developments in the application. Here, the respective checkpoint ID ("SPI-" + transaction development code) serves as a replacement "Menu ID".
Image: Selection of the GESABV processing
Aggregation of values takes place successively. Every step uses the aggregated values from the previous step, which means that an account change takes place with the aggregated values of an account for aggregation, if available. The aggregation code in the set of master data (FAC) also works with controlling balances. Controlling balances will then only be aggregated inside an aggregated controlling object if a check mark has been placed for the aggregation code.
Summarization takes place in the following order:
In the event that no account balances exist, but rather only postings are to be processed, then at least one account balance has to be entered with zero. Otherwise, the application will abort the calculation with an error message.
Image: Message panel with repeat activation of GESABV
With a carry forward to the next higher type of data, the system checks whether data already exists there. If the respective warning signal is confirmed, an inquiry is made on whether existing carry forwards for the period should be preserved or overwritten. You then have the following reaction possibilities:
1. Balance plus postings
Every account balance from the area of its origin will be aggregated together with all of the respective postings.
| DA | Acc.no. | Balance | Debit-posting | Credit-posting |
|---|---|---|---|---|
| I3 | 20000 | 15.000,00 S | ||
| I3 | 20000 | 17.500,00 | ||
| I3 | 20000 | 500,00 | ||
| I3 | 20000 | 2.000,00 | ||
| I3 | 20000 | 5.000,00 | ||
| I4 | 20000 | 5.000 H |
2. Account Aggregation
If an account for aggregation exists for multiple accounts, then the account balances will be aggregated inside this account if the aggregation mark has been entered in the target data type. If, at the same time, the chart of accounts is changed, then aggregation will take place in the background first and the aggregated balance will be carried forward to the respective account for aggregation.
| DA | Acc.no. | Aggregation Acc. | Balance |
|---|---|---|---|
| I3 | 20000 | 20000 | 15.000,00 S |
| I3 | 20001 | 20000 | 96.000,00 S |
| I3 | 20002 | 20000 | 30.000,00 H |
| I3 | 20003 | 20000 | 9.000,00 S |
| I4 | 20000 | 90.000,00 S |
3. Change of account
If an account of exchange exists for an account and the balance deviates from the standard value of the balance sheet / profit and loss code for the account, then the account balance will be aggregated during the carry forward for the type of data together with the balance of the account of exchange.
| DA | Acc.no. | B+S and P/L code | Acc.of change | Balance |
|---|---|---|---|---|
| I3 | 10000 | 1 (Aktiv) | 20000 | 30.000,00 S |
| I3 | 20000 | 2 (Passiv) | 10000 | 90.000,00 S |
| I4 | 20000 | 120.000,00 S |
4. Transition to group chart of accounts
If the chart of accounts is changed while a type of data is being carried forward, for instance from a company chart of accounts to the group chart of accounts, then the balances of the chart of accounts from this origin will be aggregated in the respective accounts of the target chart of accounts.
| DA | Company acc. | Group acc. | Balance |
|---|---|---|---|
| I3 | 20000 | 2000 | |
| I3 | 20010 | 2000 | 25.000,00 H |
| I3 | 20020 | 2000 | 1.000.000,00 H |
| I4 | 2000 | 1.025.000,00 H |
By calling up this application, the carry forward will be performed for simulation purposes for the type of data, however, the target data will not be rewritten. The new transactions that are calculated will be compared with the existing transactions from this period and any differences will be listed in a log report. The application generates a file on the results of its audit in the processing control system (VERARB) with the checkpoint 'SIMVOR'. The message entered there determines the status that will be displayed in the company financial statements + monitor. If no data whatsoever is available for the comparative type of data, then, '-' will be displayed as the status in the column 'Compare carry forwards for type of data'.
By using a switch in the master type of data (FAC), you will be able to control whether the status of the transition comparison displayed in the company financial statements + monitor (EA) should refer to all of the data, including the statistical accounts 'S', only the balance 'B', or only the P+L 'G'. The log report on the comparison will not be limited by this.
If the target type of data is allocated to an accounting type and reconciliation would result in data being generated in accounts allocated to a different accounting type, this information will be shared with the user in a message window and he will be asked whether only the appropriate data that fits in with the accounting type should be reconciled. The answer will then apply globally for all of the data that follows under this constellation.
The message windows offered when types of data are reconciled contain a recapitulative statement at the foot. Here, a distinction is made between general errors and the various warnings included in the possible answers shown. By marking off the checkbox 'Do not display this message again', you'll be able to stop this message window from being displayed with the same recapitulative message during mass processing (for instance, marking multiple companies in the company financial statements + monitor). The same user reaction (for instance, 'no processing and continue') will be assumed. The contents of the message window will be collected and displayed in a total message window at the end of mass processing.
The target account of an IC balance corresponds to the target account of the respective main account balance that is ascertained as described above. The IC balances are aggregated for each target account, IC company, currency code of the transaction currency and controlling object if the aggregation code has been checked off in the target data type. Otherwise, they will be carried forward in their complete level of detail.
If an account with an IC company in the account master (main IC account) is carried forward to an account without an IC company, a sub-account balance will be generated automatically for this target account.
If an IC company is specified together with a posting to an IC account, then this posting will not only be aggregated to include the main account balance, but an IC balance that is of the same value as the posting will be generated.
With carry forwards for types of data, both the clearing code and the attributes 'reference receipt number' and 'reference receipt date' will be assumed by the next type of data by way of an IC balance reconciliation. This means that a clearing code that is set either manually or by machine will have an effect at the group level due to an IC balance reconciliation within the company financial statement.
The status checking function for the group financial statement will check, among other things, for whether a consolidation receipt number has already been entered in the relevant IC account balances as a way of documenting consolidation. When the company financial statement data is transferred again from the previous type of data, this entry will be retained if the data has not changed at all so that the status of the respective consolidation processing ('SK' and 'AE') will remain 'green'. The message "It is necessary to perform SK and AE in current Per. again after carry forward" will only be displayed if receipt numbers were already entered in the previous data and the new data do not match completely. Please take note that manual chargebacks will be retained with the action "Delete +autom. debt consolidation SK." when the debt or expense/income consolidation has been repeated. Manual postings will be recognized based on the posting status '5'. Perhaps they will be assigned to another posting record number in accordance with the transaction currency and/or business division combination. Exception: manual chargebacks (and perhaps different types of additional postings) from a previous clearing will then not be added to the KONBUCH if a) the amounts of the IC balances were changed and now perfectly match receivables and liabilities, or b) a new consolidation receipt was not generated during a repeat SK clearing because no more IC balances existed for the respective pair.
The following applies for all transactions: The carry forward is only to be performed if the corresponding mark has been entered in the application type of data (FAC).
If, during a carry forward, a change is made from a company to a group chart of accounts, then there will be a recoding of the transactions to the target account of the corresponding main account balance. In the event of a fixed asset transaction, the carry forward will be made to the assigned fixed asset objects for the group chart of accounts. .
If posting keys for the respective details are listed in postings, then these postings will not only be aggregated together with the main account balance, but rather the respective transactions that are equal in value to the postings will also be generated.
The ascertainment of the status of the group financial statement checks, among other things, for whether a consolidation receipt number has already been entered in share ownership transactions that are of relevance to consolidation as proof of consolidation. When the company financial statement data from the previous type of data is transferred once again, this entry will be retained as long as the data has not changed in any way so that the status of the respective consolidation processing ('KK') will remain 'green'. If an individual set is changed, then the voucher number will only be deleted for this particular set. The message "Repeat performance of KK for company xx necessary after carry forward!" will only be displayed if a share ownership set that has already been consolidated has been removed completely. In this case, there will be no change in status (remains 'green'). The user himself must now perform the necessary consolidation steps.
Inside the processing control system, sets of their own (checkpoints) will be stored for data that is carried forward for each defined transaction development. The name of these checkpoints will be the checkpoint name of the respective transaction development + "VOR", in other words "ANLBEWVOR" or "SPIBEW9VOR", for example. This processing control set (assuming the appropriate control for the type of data) also contains a control value for the data that is carried forward. Here, all transactions that have posting keys entered in the same transaction development column as a posting key for an automatic carry forward (usage tag 'V') are considered to be carried forward data. These sets will be needed to compare the carry forwards for a period.
Controlling balances are only carried forward if the respective mark for controlling balances has been entered for the target type of data in the application FAC (in this case, the controlling balances do not need to be complete). If an aggregation controlling object exists for multiple controlling objects, then the balances will be cumulated inside this controlling object. Analogous to the account balances, aggregation is controlled using an aggregation tag. An aggregation controlling object is not allowed to have an aggregation tag.
If, during a carry forward, there is a change from a company to a group chart of accounts, the controlling balances will be recoded to the assigned group controlling objects. The target account corresponds with the target account of the respective main account balance that is determined as described above.
If a controlling object has been specified in a posting, then this posting will not only be aggregated together with the main account balance, but rather a controlling balance that is equal in value to the posting will also be generated.
It is possible to distribute account balances across business divisions and this is generally done based on the controlling balances even if the source type of data of the switch for managing controlling balances has not been activated. Then, controlling balances will not be taken into consideration and reconciliation will only be performed for the divisions specified in the account master and/or chart of accounts. Here, the original controlling objects (CNT) must each be assigned to a business division in the accounts master.
With "UBR Split", the company-division allocations (GESUBR) must be taken into consideration as follows:
For accounts with controlling details, a check for whether the details match the account balance will be performed first. Then, the controlling balances will be allocated to the business divisions and the account balance will be distributed accordingly. Due to the fact that what are perhaps parallel details of IC balances cannot be divided correctly, this type of detail will be allocated to the respective accounts of a random business division and a warning will be issued.
With a UBR Split, annual net profit is not usually divided evenly between the balance and P+L. In order to be able to compensate for the resulting difference, an account can be set up with the account code ="U" in the target chart of accounts. This account can be an active, passive, expenditure or earnings account. Compensation balances will then be generated automatically in this account in the event of a carry forward.
An input field entitled "Account group for comparing transfers to a type of data" that manifests itself in the following forms: 'B' for comparing the balance, 'G' for P+L and 'S', including static accounts, can be found in the master for the type of data (FACE).
Abbildung:'FACE' settings
When 'S' is entered, no limit will be made to the Balance/Profit and loss code during the comparison of a carry forward (SIMVORSAL).
The three currency values will be treated differently with a carry forward:
If the target account or one of the interim accounts for the period is invalid, then an error message will be sent during aggregation. This contains the account of origin that will allow for the invalid account to be searched for.
With detail data, an error in the area of origin will only result in a warning. The data will still be carried forward. With IC balances, this warning to will be suppressed if the code for processing of the division has been entered in the type of data of origin and not in the target type of data.
In addition, the attribute target type of data (entry in FAC) can be used to produce an origin list for the accounts and/or controlling balances during creation of a carry forward. This will allow you to understand what detail of origin data a balance in the target area consists of.