Das Release 5.3.0 ist ein Hauptrelease und darf daher in der Releasefolge nicht ausgelassen werden. Voraussetzung für das Release 5.3.0 ist das letzte Hauptrelease 5.2.0 vom 29. 9. 2003. Die Nachträge und Korrekturen zum Release 5.2.0 sowie das Zwischenrelease 5.2.1 mit seinen Nachträgen und Korrekturen sind im Release 5.3.0 enthalten. Die bereits mit dem Release 5.2.1 enthaltenen Änderungen sind in der Dokumentation zum Release 5.2.1 beschrieben.
Wichtiger Hinweis:
Wegen der Umstellung des Verfahrens zur AfA-Verrechnung und zum AfA-Vortrag sowie des Vortrags von Anlagenbewegungen für Ausleihungen aus der Schuldenkonsolidierung ist es notwendig, dass dieses Release nach Abschluss einer Periode vor dem Vortrag der Konzerndaten in die nächste Periode installiert wird. Sollte der Releasewechsel zu einem anderen Zeitpunkt erfolgt sein, muss der Konzernvortrag wiederholt werden.
Das neue Oracle-Release 10g wird unterstützt. Dabei wird auch die Möglichkeit geboten, bei der Anmeldung auf die Datenbank auf die Anmeldung am System/Netzwerk durchzugreifen.
Das Transaktions-Handling der Datenbank-Schnittstelle wurde umgestellt. Dies führt zu geringfügigen Performance-Verbesserungen (ca. 10%) bei den Datenbank-Systemen DB2 und ORACLE. Für MS SQL Server ergibt sich keine Änderung.
Beim Start von IDL Konsis werden nach dem Login die Versionen der Datenbankstrukturen, der Metadaten und der Konvertierung überprüft.
Die Anzeige von Übersichten ist jetzt auch als Baumdarstellung möglich (bisher implementiert für Konzernstruktur, Reportergebnis und Reportkopfsätze). Das Auf- und Zuklappen einzelner Zweige erfolgt dabei analog zum Menübaum. Daneben gibt es im Menü <Bearbeiten> folgende neuen Menüpunkte:
Anwendungsspezifische Kürzel wie Konto-Kennzeichen, Soll/Haben-Kennzeichen etc., zu denen in Eingabefeldern eine Combo-Box definiert ist, erhalten jetzt in Tabellen eine Tooltip-Funktion. Verweilt der Mauszeiger auf einer derartigen Zelle, so erscheint die entsprechende Betextung als Tooltip.
In der "About-Box", die über die Aktion <Hilfe> -> <Über IDL KONSIS> angezeigt wird, wird jetzt zusätzlich ausgegeben, mit welchem Datenbank-Management-System (DBMS: DB2, ORACLE oder MS SQL Server) die Anwendung arbeitet.
Auch Menüpunkte, die aus dem Menübaum heraus ausgewählt wurden, werden jetzt in die Kurzwort-Historie (Drop-Down-Box des Kurzwort-Eingabefeldes) aufgenommen und können so schnell ein weiteres Mal aktiviert werden. Umgekehrt wird bei Eingabe eines Kurzwortes der entsprechende Menüpunkt im Menübaum markiert. Zuvor wird ggfs. der entsprechende Zweig aufgeklappt.
Die Aufbereitung der Titelzeile erfolgt für Einzelsatzanwendungen analog zur Titelzeile für Übersichten in der Reihenfolge Kurzwort, Bezeichnung 1 sowie, falls abweichend vom Kurzwort, in Klammern die Menü-Id, z.B. "POSE Position (AGGE)".
Über eine neue Einstellung im Optiondialog (Rubrik <Darstellung>) kann das optische Design der Oberfläche ("Look and Feel") zwischen "Metal" (bisherige Form) und "Windows" (Windows-artige Darstellung mit hellerem Hintergrund) gewählt werden. Die vollständige Aktualisierung der Oberfläche erfolgt allerdings erst nach einem Neustart von IDL Konsis.
Ein neuer Anwendungstyp "Formularerfassung" wird jetzt unterstützt. Dieser ermöglicht Eingaben in einer Tabellenform sowie verschiedene automatische Summierungen. Erste Anwendung für diesen Typ ist die Formularerfassung für Kontensalden.
Werden in einer Übersicht mehrere Zeilen markiert und dann die Aktion <Löschen> betätigt, kommt eine Dialogbox mit der Frage "Löschen der Sätze ohne Einzelbestätigung?". Betätigte man den <Schließen>-Button dieser Dialogbox, so wurde dies bisher wie "Nein" interpretiert. Jetzt führt die Betätigung des <Schließen>-Buttons zum Abbruch des gesamten Vorgangs.
Wird in der Übersicht nur eine Zeile zum Löschen markiert, so erfolgte bisher immer ein Wechsel in die Einzelsatzanwendung, wo erneut der Button <Löschen> betätigt werden musste. Jetzt kommt wie beim Markieren mehrerer Zeilen zum Löschen o.g. Dialogbox. So kann zum Löschen ein Dialogschritt gespart werden.
Nach dem Löschen und Kopieren von Zeilen aus einer Übersicht heraus wurde dieser Vorgang bisher immer durch eine Dialogbox mit der Angabe der Anzahl gelöschter bzw. kopierter Zeilen bestätigt. Diese Dialogbox entfällt jetzt, so dass die Bestätigung dieser Box eingespart wird.
Die Druckvorschau enthält jetzt eine Symbolleiste. Die dort enthaltenen Symbole ermöglichen
Im Fußteil des Fensters ist ein neuer Button <PDF-Export> zur Ausgabe des Druckbildes in eine pdf-Datei. Die Ausgabe in eine pdf-Datei ist auch in der Online-Hilfetext-Anzeige über ein entsprechendes Icon möglich.
Im Kopfteil des Druckbildes wird jetzt (wie im Dialog) die aktuelle IDL Konsis-Version ausgegeben.
Für englischsprachige Benutzer werden die Kürzel 'S' und 'H' für das Soll/Haben-Kennzeichen künftig mit den englischen Kürzeln 'D' (Debit) und 'C' (Credit) dargestellt. Dies betrifft sowohl die Ausgabe in Masken und Tabellen als auch die Eingabe und Anzeige in den zugehörigen Comboboxen.
Das Konvertierprogramm für das Release 5.3.0 nimmt folgende Umsetzungen in der IDL Konsis-Datenbank vor:
Folgende Menü-IDs sind in diesem Release neu. Falls kundenspezifische Benutzergruppen verwendet werden, müssen für diese Menüpunkte ggfs. Berechtigungen (BENMEN) gepflegt werden. Als Vorlage können i.d.R. die Menüberechtigungen der Benutzergruppe IDLKON dienen.
In der Anwendung USEE ist jetzt zugelassen, dass die Benutzeranmeldung auch die Sonderzeichen '_' (Unterstrich) und '%' (Prozent) enthalten darf. Diese Sonderzeichen dienen ansonsten als Platzhalter bei Datenbank-Selektionen.
In der Anwendung USEE wird jetzt nach einfachen und Sonderrechten unterschieden. Mit einfachen Rechten ist es möglich einen neuen Benutzer anzulegen, der dieselben Rechte hat wie der aktuelle Benutzer selbst. Nur mit Sonderrechten kann ein Benutzer mit abweichender Berechtigung eingerichtet werden.
Neben den bisherigen IDL-definierten Benutzergruppen IDLADMIN, IDLKON, IDLKON1 und IDLVIEW gibt es jetzt eine fünfte Benutzergruppe IDLSYS. Diese Benutzergruppe hat nur die Berechtigungen für die Anwendungen zur Benutzerverwaltung (USE, BEN, BENMEN, VORADMIN). Sie ist gedacht für Unternehmen, in denen ein fachfremder Mitarbeiter der IT-Abteilung anwendungsspezifisch neue Benutzer einrichten soll ohne die Möglichkeit die IDL Konsis-Anwendungsdaten einzusehen.
Die bisherigen Anwendungen "AGB" und "AGG" (einschließlich Einzelsatz- und Import-Anwendungen) enthielten Daten, die unterschiedlichen Zwecken dienten. Um hier mehr Klarheit zu schaffen, wurden diese in drei Anwendungsgruppen aufgeteilt:
Im Menübaum finden Sie die Anwendungen "Positionspläne", "Positonen" und "Positions+Konten-Zuordnungen" im Menüzweig "Stamm- und Steuerungsdaten". Die Anwendungen "Report-Idents", "Report-Zeilenbeschreibungen", "Report-Spaltenoptionen", "Report-Spaltenbezeichnungen" und "Formel-Editor" befinden sich dagegen im Menüzweig "Berichtswesen".
In diesem Zusammenhang wurden auch diverse Auswahlfunktionen so angepasst, dass je nach Kontext nur noch die jeweils sinnvollen "AGB"s bzw. "AGG"s zur Auswahl angeboten werden.
Die Anwendung RID (Report-Id) wurde um die Angabe einer Referenz-Report-Id erweitert (Verwendung s. Kapitel Report-Übersichten).
Bei der Vergabe der Konto-Kennzeichen für ein Konto wurden folgende Plausibilitätsprüfungen eingeführt:
Bei der Pflege von Gesellschaftskonten werden automatisch einige Attribute (Konto-Kennzeichen) aus dem zugeordneten Konzernkonto übernommen, um die Konsistenz beim Vortrag zu gewährleisten. Diese automatische Anpassung erfolgt jetzt auch bei der Pflege von Konzernkonten. Wird eines der relevanten Attribute eines Konzernkontos verändert, so werden automatisch alle zugeordneten Gesellschaftskonten angepasst. Eine Aufstellung der angepassten Konten wird in einem Meldungsfenster angezeigt. Diese Steuerung funktioniert ggfs. auch mehrstufig in der Konstellation, dass mehrere aufeinander zugeordnete Konzernkontenpläne definiert sind.
Das Konto-Kennzeichen 'W' steht für Konten des Konzernkontenplans nicht mehr zur Verfügung. Stattdessen wird das Ergebnisvortragskonto im Datenartenstamm angegeben.
Ein neues Attribut "Rechnungslegungsart" wurde sowohl im Kontenplan als auch im Kontenstamm ergänzt. Die Angabe beim Kontenplan ist nur für Gesellschaftskontenpläne, die Angabe beim Konto nur für Konzernkonten zugelassen. Zur Verwendung dieses Attributs s. Abschnitt Prüfungen auf Rechnungslegungsart.
Diese Änderungen bzw. Erweiterungen gelten analog für die Importanwendung TXTKTO. Dabei wird eine Information über angepasste Konten in die Protokolldatei geschrieben.
Bei der Selektions-Option 'F' (Anzeige von Konten, die nicht einem Positionsplan zugeordnet sind) ist jetzt auch eine teilqualifizierte Angabe der Positionsnummer möglich. Dies ist z.B. sinnvoll, wenn ein Positionsplan GKV- und UKV-Positionen enthält, so dass GuV-Konten ggfs. mehrfach zuzuordnen sind.
Für Konzern-Anlagenobjekte kann jetzt neu die AfA-Art 'F' (fester Abschreibungsbetrag) vorgegeben werden. Zusätzlich ist dieser Abschreibungsbetrag in einem neuen Eingabefeld anzugeben. Diese Angabe ist sinnvoll, wenn ein runder AfA-Wert gewünscht wird oder wenn eine automatische AfA-Berechnung aufgrund von Sonderabschreibungen zu falschen Ergebnissen führen würde.
Der feste AfA-Betrag bezieht sich immer auf die Abschreibung pro Jahr. Für Zwischenabschlüsse werden entsprechende Anteile dieses Betrages gebucht (je Monat 1/12).
Bei Wechsel der Position (bei Sort-Option 'A') wird für die Position eine Quasi-Summenzeile ergänzt. In der Summenzeile wird für die Kontonummer '*' ausgegeben. Die Positionsbezeichnung entfällt als eigene Spalte und wird in der Summenzeile unter den Konten-Bezeichnungen ausgegeben. Das gleiche gilt für das Bil/GuV-Kennzeichen der Position.
In der Tabelle der Buchungsschlüssel wurde ein Attribut für einen Referenz-Buchungsschlüssel ergänzt. Hier ist für einen Einzelabschluss-BSL anzugeben, welcher BSL auf Konzernebene zu dessen Eliminierung verwendet werden soll. Diese Angabe ist für kundenindividuelle BSL auf Einzelabschlussebene zu ergänzen. Für individuelle Spiegel ist diese Angabe nicht notwendig, da hier nicht nach Einzelabschluss- und Konzernebene unterschieden wird.
Buchungsschlüssel für individuelle Spiegel können jetzt beliebig (z.B. nummerisch '00' bis '99') vergeben werden. Bisher bestand die Beschränkung auf die Namenskonvention für kundenspezifische Buchungsschlüssel (1. Stelle = 'K').
Die Zuordnung einer Spiegelspalte ist für Buchungsschlüssel jetzt eine Pflichtangabe. Die Angabe des BSL-Kennzeichens 2 (AHk oder AfA) ist für kundenindividuelle Anlagen-Buchungsschlüssel jetzt ebenfalls eine Pflichtangabe. Bereits erfasste BSL sollten noch einmal überprüft werden, ob dies erfolgt ist.
Außerdem wurde die Anzahl der Spiegelspalten für individuelle Spiegel von bisher 10 auf 20 erhöht (s. auch Abschnitt Reportergebnisanzeige).
Für den Konzern-Eigenkapitalspiegel wurde die Spiegelspalte 11 für Veränderungen des Konsolidierungskreises ergänzt. Dieser Spalte ist der neue Buchungsschlüssel 32 zugeordnet. Die Spalte wurde für die Reportanzeige auch bei der Spaltenoption #KAPK ergänzt.
Ein neues Attribut "Rechnungslegungsart" wurde im Datenartenstamm ergänzt. Die Angabe ist nur auf der Ebene der Konzernkontenpläne zugelassen. Zur Verwendung dieses Attributs s. Abschnitt Prüfungen auf Rechnungslegungsart.
Ein neues Attribut "Ergebnisvortragskonto" ersetzt die bisherige Angabe des Konto-Kennzeichens 'W' im Konzernkontenplan. Auf diese Weise können je Datenart unterschiedliche Ergebnisvortragskonten angegeben werden. Die Release-Konvertierung sorgt für die automatische Überleitung des bisherigen 'W'-Kontos in das neue Attribut.
Die Angabe eines Ergebnisvortragskontos ist für Datenarten auf der Ebene von Konzernkontenplänen Pflicht. Ausnahme: Bei Neueinrichtung einer Datenbank darf das Feld leer bleiben, wenn zu dem angegebenen Konzernkontenplan noch keine Konten definiert sind.
Das Perioden-Kennzeichen ('J'ahres-, 'Q'uartals- oder 'M'onatsabschluss) ist jetzt eine Pflichtangabe. Für bestehende Perioden ohne Angabe wird per Konvertierprogramm der Defaultwert 'J' eingetragen.
Eine neue Anwendung ermöglicht die formulargestützte Erfassung von Kontensalden. Eindeutig vorzugeben sind die Schlüssel Periode, Datenart, Gesellschaft sowie ggfs. Geschäftsbereich. Über eine Sort-Option können folgende Varianten unterschieden werden:
Die Darstellung und Erfassung der Werte erfolgt ohne Soll/Haben-Kennzeichen in der vom Report gewohnten Form. D.h. bei der Formularerfassung ist das Bil/GuV-Kennzeichen der übergeordneten Position maßgebend, z.B. für Aktiv-Positionen sind positive Werte im Soll, negative Werte im Haben, für Passiv-Positionen umgekehrt. Bei der Komplett- und der Schnellerfassung ist dagegen das Bil/GuV-Kennzeichen des Kontos entscheidend für das Vorzeichen.
Neben dem Betrag kann auch die Bemerkung erfasst werden. Um die Anzeige kompakt zu halten, wird eine vorhandene Bemerkung nicht mit ihrem vollen Text, sondern nur als Häkchen dargestellt. Der Text wird als Tooltip angezeigt, wenn der Mauszeiger auf dieser Zelle verweilt. Nach Markieren der Bemerkungszelle lässt sich über das Objektmenü der Zeile durch die Aktion <Bemerkung ändern> eine Dialogbox öffnen, in der eine Bemerkung erfasst bzw. geändert werden kann.
Durch einen neuen Button <Speichern> werden die angezeigten und erfassten Daten an die Import-Anwendung (TXTKTOSAL) weitergeleitet, wo sie geprüft und in die Datenbank geschrieben werden. Die Import-Anwendung führt je nach Vorhandensein von Daten einen Insert oder Update auf der Tabelle KTOSAL durch. Auf diese Weise bleiben Zeilen für auf null gesetzte Werte erhalten.
Durch die Angabe einer Vergleichsperiode (z.B. Vorperiode) und/oder einer Vergleichsdatenart (z.B. Plandatenart) wird in der Formular- und Kompletterfassung eine weitere Spalte mit den Vergleichswerten angezeigt. Die Werte dieser Spalte werden wie die Eingabewerte summiert. Die Anwendung kann daher unabhängig von der Erfassung auch zur vergleichenden Anzeige von Werten zweier Perioden oder Datenarten im Reportschema verwendet werden, ohne dass ein Report erstellt werden muss.
Über das Aktionsmenü kann in die Kontensalden-Übersicht verzweigt werden, um die erfassten Daten in bisheriger Form anzuzeigen, sowie in die Übersichten der Aufrisse, um diese Daten zu erfassen oder zu verproben. Die Formularerfassung kann auch als Folgeanwendung aus der Reportübersicht (REP, REPK oder REPSTR) heraus aufgerufen werden.
Die Erfassungsanwendung kann über das Kurzwort I-KTOSAL aufgerufen werden. Da weitere Erfassungsanwendungen geplant sind, wurde im Menübaum ein neuer Menüknoten 'Formularerfassung' eingerichtet, unter dem derzeit I-KTOSAL (Einzelabschluss Kontensalden) der einzige Menüpunkt ist.
In der Statusanzeige der Anwendung EA wird jetzt zwischen Fehlern (rot) und Warnungen (gelb) unterschieden. Die Unterscheidung erfolgt anhand der Meldungsart der in der Verarbeitungssteuerung eingetragenen Meldungsnummer. In die Kategorie Warnung (gelb) zählen derzeit Meldungen aufgrund folgender Plausibilitätsprüfungen:
Alle übrigen Meldungen werden wie bisher als Fehler (rot) ausgegeben. Inwieweit der Status Warnung ignoriert wird oder wie ein Fehler behandelt wird, der zu korrigieren ist, liegt in der Entscheidung des Anwenders und ist organisatorisch zu lösen.
Der Status für Bewegungsaufrisse wird jetzt nicht mehr als fehlerhaft (rot) angezeigt, wenn es keinerlei Bewegungen (z.B. Anlagenbewegungen), aber auch keine Kontensalden auf Konten (z.B. Anlagenkonten) für diesen Aufriss gibt. Kontensalden mit Wert 0,00 werden in diesem Zusammenhang wie nicht vorhanden gewertet.
Der Status für die SK- bzw. AE-Saldenabstimmung wird jetzt nicht mehr für die als "ex-Datenart" deklarierte Datenart angezeigt, da auf dieser Konsolidierungs-Datenart bereits die "echte" Schulden- bzw. Aufwands-/Ertrags-Konsolidierung erfolgt, die jedoch nicht aus der Anwendung EA heraus angestoßen werden kann.
In der Anwendung EA wird in den Spalten <Änd.User>, <Änd.Datum> und <ÄndZt> jetzt angezeigt, wer wann die Einzelabschluss-Sperre für eine Gesellschaft zuletzt gesetzt oder zurückgesetzt hat. Es werden dort die Angaben des VERARB-Satzes für den Checkpoint 'EA' ausgegeben.
Aus EA heraus lassen sich die neue Anwendungen zum Löschen aller Konten-, IC- und Controllingsalden je Gesellschaft aufrufen. Alle Löschanwendungen wurden dazu im Aktionsmenü zu einem neuen Submenü <Löschen> zusammengefasst.
Neben der Sperre eines kompletten Einzelabschlusses gegen weitere Änderungen (Aktionen "Einzelabschluss freigeben" bzw. "Einzelabschluss-Freigabe aufheben" in EA) gibt es jetzt die Möglichkeit, nur die IC-Salden des Einzelabschlusses gegen weitere Veränderungen zu sperren. Dies ist insbesondere dann sinnvoll, wenn die Abstimmung der IC-Salden der Gesellschaften vor der Abgabe des kompletten Einzelabschlusses erfolgt.
Die Sperre wird (analog der Einzelabschlusssperre) durch einen neuen Checkpoint ("EAIC") in der Verarbeitungssteuerung geführt und kann in dieser Anwendung auch selektiert werden.
Das Setzen der Sperre erfolgt über die Aktion <IC-Salden freigeben> in der Anwendung EA, das Aufheben der Sperre durch die Aktion <IC-Salden aufheben Freigabe>. Diese beiden Aktionen wurden gemeinsam mit den Aktionen zur Freigabe bzw. Aufhebung der Freigabe des Einzelabschlusses unter dem neuen Submenü <Freigabe/Sperren> zusammengefasst.
Eine neue Statusspalte "IC-Frei" neben der Spalte "IC-Sal" zeigt an, ob eine Sperre gesetzt ist (grün) oder ob eine gesetzte Sperre wieder aufgehoben wurde (rot). Wird diese Funktion nicht genutzt, bleibt die Spalte leer und wird nicht angezeigt, wenn die Option <leere Spalten unterdrücken> gesetzt ist.
Bei der automatischen Generierung des Kapitalaufrisses für das JÜ-Konto bleiben jetzt die vom Vortrag erzeugten Kapitalbewegungen mit BSL 01 (maschineller Vortrag) und 17 (Kapital-Umbuchung Gesellschaftsvortrag) erhalten, wenn ihre Summe (wie vom Vortrag erzeugt) null beträgt. Erzeugt wird in jedem Fall eine Bewegung in Höhe des JÜ-Saldos mit BSL 05 (Einstellung JÜ akt. Periode) oder BSL 16 (Einstellung JF akt. Periode). Weitere Kapitalbewegungen werden gelöscht.
Als neue Folgeanwendung kann eine Funktion zum Löschen aller Kontensalden einer Gesellschaft aufgerufen werden.
In der IC-Salden-Übersicht wurden (neben der bisherigen globalen Restwertanalyse 'RW') die IC-Selektionsoptionen 'RI' und 'RE' ergänzt. Bei 'RI' werden nur die Restwerte gegenüber Gesellschaften innerhalb des Konzernkreises ausgewiesen, bei 'RE' nur die Restwerte gegenüber externen Gesellschaften.
In der Pärchensicht (Angabe einer IC-Sel-Option) der Anwendung ICKTOSAL mit mehrdeutiger Angabe der IC-Gesellschaft werden jetzt auch IC-Salden von IC-Gesellschaften an die aktuelle Gesellschaft angezeigt, wenn die aktuelle Gesellschaft keine IC-Salden gegen diese IC-Gesellschaft gemeldet hat.
Die in der Pärchensicht angezeigten Daten werden jetzt auch nach Transaktionswährung sortiert und mit Zwischensummen versehen, um eine Abstimmung nach Transaktionswährung bei verschiedenen Währungen zu erleichtern.
Werden IC-Salden mit Angabe von Controllingobjekten geführt und gleichzeitig auch Controllingsalden geführt, so erfolgt jetzt eine Verprobung, ob die IC-Salden einen stimmigen Aufriss zu den Controllingsalden darstellen. Differenzen werden analog zu Differenzen zu den Kontensalden gemeldet und führen zum Status <rot> in EA.
Als neue Folgeanwendung kann eine Funktion zum Löschen aller IC-Kontensalden einer Gesellschaft aufgerufen werden.
Zur kompakteren Darstellung wurden Bezeichnungsspalten zusammengefasst. Je nach Sortieroption wird die Bezeichnung des Sortierschlüssels nur noch in den Summenzeilen ausgegeben.
Bei der Verprobung von Controllingsalden wird jetzt auch geprüft, ob diese gemäß der Zuordnung von Konten und Controlling-Kennzeichen zu einer Position (POSKTO) zuordenbar sind. Der für die Prüfung benötigte Positionsplan wird aus der Vorbelegung des aktuellen Benutzers ermittelt. Enthält POSKTO keine Einschränkung nach Controlling-Kennzeichen, entfällt diese Prüfung.
Analog zu anderen Aufrissdaten werden jetzt auch für die Controllingsalden Prüfziffern errechnet und gespeichert. Die Prüfziffer eines Checkpoints (Gesellschaft, Geschäftsbereich, Periode, Datenart) berücksichtigt die Attribute Gesellschaft, Konto, Controllingobjekt, Soll/Haben-Kennzeichen, Wert-LW, Wert-KW und Wert-PW. Diese Prüfziffer wird auch in Controlling-Reports gebildet und verprobt.
Als neue Folgeanwendung kann eine Funktion zum Löschen aller Controllingsalden einer Gesellschaft aufgerufen werden.
Die Steuerung, welche Eingaben beim Erfassen von Bewegungen als Soll- und welche als Haben-Beträge gespeichert werden, wurde überarbeitet. Das Soll-/Haben-Kennzeichen ist kein Eingabefeld mehr. Vielmehr wird das Soll-/Haben-Kennzeichen bei Eingabe positiver Werte gemäß folgenden Prioritäten automatisch vergeben:
Die Eingabe negativer Werte ist wieder zugelassen. Der Wert wird dennoch als positiver Wert gespeichert, aber die Zuordnung des Soll/Haben-Kennzeichens erfolgt genau umgekehrt wie bei Anwendung obiger Regeln.
Diese Regeln gelten beim Erfassen neuer Daten unabhängig davon, ob der erste Satz erfasst wird (Eingabemaske ist noch leer) oder ob ein weiterer Satz erfasst wird (Eingabemaske enthält die Daten des zuvor erfassten Satzes). Betroffen sind von dieser Änderung die Anwendungen ANLBEWE, KAPBEWE, RUEBEWE, SPIBEWE und GESGESE. Dieselben Regeln gelten auch bei den korrespondierenden Import-Anwendungen.
Die Anwendungen KAPBEW und GESGES enthalten jetzt gegenseitige Folgeanwendungsaufrufe im Aktionsmenü. Diese dienen insbesondere der Abstimmung der Daten vor Durchführung der Kapitalkonsolidierung.
Die LW-Prüfziffern von Kapital- und Rückstellungsbewegungen konnten sich durch die Währungsumrechnung ändern. Dieses Problem wurde behoben, wobei sich jetzt aber die KW- und PW-Prüfziffern für diese Daten ändern können.
In der Tabelle für den Anteilsbesitz (GESGES) wurde ein Attribut für den IC-Geschäftsbereich ergänzt. Damit können Beteiligungen danach unterschieden werden, an welchem Geschäftsbereich der Tochtergesellschaft sie bestehen. Geplant ist, daraus auch eine differenzierte Kapitalkonsolidierung abzuleiten.
Um Anteilsbesitz und Anlagenvermögen parallel pflegen zu können, wurde das Attribut IC-Geschäftsbereich auch in der Tabelle für Anlagenbewegungen (ANLBEW) ergänzt. Die Erweiterungen werden auch in verschiedenen weiteren Anwendungen berücksichtigt (u.a. Import-Anwendungen, Vortrag, Währungsumrechnung, KONDAT, MIS).
Die Aktionen <Setzen Verarb.Knz auf B=verarbeiten> und <Löschen Verarb.Knz von B auf I=Info> in der Übersicht BEL sind entfallen und wurden ersetzt durch die Möglichkeit, das Attribut "Verarbeitungs-Kennzeichen" über die Aktion <Mengen-Ändern> zu ändern.
Das Kopieren von Belegköpfen (z.B. in eine andere Periode oder Datenart) ist jetzt möglich, sofern es unter den Zielschlüsseln noch keine Belege mit denselben Belegnummern gibt. Bisher wurde das Kopieren verhindert, wenn es unter den Zielschlüsseln bereits irgendwelche Belege gab.
Für die latenten Steuern im Einzelabschluss wurde eine Zieldatenart im Belegkopf ergänzt. Bei Angabe der Zieldatenart werden die Buchungen nur bei Vortrag auf diese Zieldatenart berücksichtigt. Außerdem wurde in den Buchungen ein LT-Kennzeichen ergänzt.
Die Datenbank-Tabelle für IC-Bewegungen (Anwendung ICBEW) wurde restrukturiert. Vorlage war dabei die Tabelle der IC-Kontensalden. Folgende Änderungen wurden dabei berücksichtigt:
Die Überleitung der Daten der alten Datenbank-Tabelle auf die neue Datenbank-Tabelle erfolgt durch das Konvertierprogramm.
Für die Verarbeitung der IC-Bewegungen in der neuen Datenbank-Tabelle im Connector muss die aktuelle Version 2.2.3 des IDL Connector verwendet werden.
Ein Attribut Rechnungslegungsart kann in den Anwendungen FAC (nur Konzernebene), KTP (nur Gesellschaftsebene) und KTO (nur Konzernebene) eingegeben werden. Als Ausprägungen werden einerseits die (neutralen) Werte '1' (intern) und '2' (extern), andererseits die gebräuchlichen Rechnungslegungsarten 'H' 'HGB', 'I' (IFRS) und 'U' (US-GAAP) zur Verfügung gestellt, die vom Anwender je nach Bedarf genutzt werden können.
Bei Änderungen am Kontenstamm (Dialog oder Import) wurde für Gesellschaftskonten die Prüfung ergänzt, dass bei Angabe einer Rechnungslegungsart im Gesellschaftskontenplan als zugeordnetes Konzernkonto nur ein Konto mit der gleichen Rechnungslegungsart oder ohne Angabe einer Rechnungslegungsart zugelassen ist.
In allen Anwendungen, in denen Berichtsdaten erfasst oder eingefügt werden können, wurde die Prüfung ergänzt, dass auf einer Datenart mit der Angabe einer Rechnungslegungsart nur Daten für Konten mit Angabe derselben Rechnungslegungsart oder ohne Angabe einer Rechnungslegungsart geführt werden dürfen. Eine derartige Prüfung wurde auch in den Prüfmodulen für die Berichtsdaten ergänzt. Ein Verstoß gegen die Regel führt zu einer entsprechenden Meldung in der Verarbeitungssteuerung und als Folge zu einem roten Status im Einzelabschluss-Monitor.
Damit ein unzulässiges Konto nicht bei einer automatischen Verarbeitung herangezogen wird, wurden entsprechende Prüfungen auch in den Anwendungen Konsolidierungsparameter und Währungsumrechnung Kopfsatz für Steuerungsdaten ergänzt.
Die Maske der Anwendung IMPORT wird jetzt mit dem Konzern/Tk aus VOR vorbelegt. So wird standardmäßig für die Übernahme von Bewegungsdaten eine Einschränkung der Gesellschaften auf den jeweiligen Konzernkreis vorgenommen.
Die bisher enthaltene Prüfung, dass Konzern/Tk und Gesellschaft nicht gleichzeitig eingegeben werden dürfen, ist entfallen.
Ist bei der Übernahme von Stammdaten (z.B. Konten) das Gültig-ab-Datum nicht angegeben, so wird jetzt als Defaultwert das Gültig-ab-Datum eines übergeordneten Stammobjekts (z.B. Kontenplan) eingestellt. Diese Änderung betrifft neben den Konten (TXTKTO) auch Positionen (TXTAGG, Übernahme vom Positionsplan) und Kostenstellen (TXTKST, Übernahme vom Kostenstellenplan).
Beim Import von Stammdaten wird jetzt in der Protokolldatei protokolliert, zu welchen Schlüsseln Daten eingefügt oder verändert wurden. Diese Erweiterung betrifft die Anwendungen TXTGES (Gesellschaften), TXTKTO (Konten), TXTKST (Controllingobjekte), TXTAGG (Positionen) und TXTANLOBJ (Anlagenobjekte).
In SAP werden je Kostenstelle mehrere Datensätze mit unterschiedlichen Gültigkeitsständen geführt. Die Importanwendung für Controllingobjekte (TXTKST) sorgt jetzt im Zusammenspiel mit der SAP-Schnittstelle dafür, dass diese Datensätze in IDL Konsis zu einem Datensatz mit der Gültigkeit aller Datensätze zusammengefasst werden. Der Inhalt dieses Satzes entspricht dem neuesten Stand aus SAP.
Wenn der Import für IC-Salden (TXTICSALD) ohne Löschen gestartet wird, so werden die Daten übernommen, auch wenn bereits Daten vorhanden sind. Dies kann aber leicht dazu führen, dass Daten doppelt übernommen werden, die dann nur mühselig und fehleranfällig wieder gelöscht werden können. Daher wird jetzt eine Warnung ausgegeben, wenn bereits Daten für die jeweiligen Schlüssel vorhanden sind und der Verarbeitungssteuerungs-Satz fehlerfrei ist.
Die Übernahme von Anlagenbewegungen (TXTANLBEW) aus einem SAP-System ist jetzt auch auf einer Datenart mit Gesellschaftskontenplan möglich. Möglich ist auch eine Übernahme, wenn der SAP-Kontenplan als Konzern-Kontenplan in IDL Konsis verwendet wurde. Dazu wurde das Import-Format um die Angabe des Kontenplans erweitert.
In der Anwendung TXTKAPBEW bei der Aktion <Löschen Daten + Neu-Import TXT-Datei> bleiben jetzt neben den Kapitalbewegungen mit Buchungsschlüssel 01 auch die Bewegungen mit BSL 17 erhalten, wenn in IMPORT der Schalter <mit Vortrag> nicht gesetzt ist.
Beim Import von Buchungen (TXTBUCH) und Konsolidierungsbuchungen (TXTKONBUCH) wird jetzt die Aktion <Löschen Daten + Neu-Import TXT-Datei> unterstützt. Das Löschen wird dabei nicht global, sondern einzeln für jeden angesprochenen Beleg durchgeführt.
Beim Import von Buchungen (TXTBUCH) und Konsolidierungsbuchungen (TXTKONBUCH) wird jetzt die Reihenfolge der Buchungen aus der TXT-Datei beibehalten. Dies ist insbesondere bei größeren Belegen hilfreich, wo die Zusammengehörigkeit von Buchungspaaren bisher nicht gewährleistet war.
Beim Import von Konsolidierungsbuchungen wird die Angabe von reservierten Buchungsschlüsseln (z.B. V1 oder V2 für Anlagenkonten) jetzt wie in der Einzelsatzanwendung (KONBUCHE) nicht mehr als Fehler gemeldet, sondern nur noch mit einer Warnung versehen.
Wird beim Ausführen der Anwendung "Löschen + Erstellen Gesellschaftsabschluss neue Datenart" (LOEVORSAL) festgestellt, dass in den auf der Zieldatenart bereits vorhandenen IC-Salden das Feld BuchTk befüllt ist, wird jetzt eine Meldung ausgegeben, die den Abbruch der Verarbeitung ermöglicht. Gleichzeitig wird in der Meldung darauf hingewiesen, dass beim Fortsetzen der Verarbeitung die SK- und AE-Konsolidierung erneut durchzuführen sind.
Die Anwendungsvariante "Abgleich Ges-Abschluss neue Datenart" (SIMVORSAL) kann jetzt auch ohne Änderungsberechtigung aufgerufen werden, da ja auch keine Daten verändert werden.
Das Protokoll dieser Anwendung wurde neu gestaltet. Es werden jetzt drei Blöcke für Abweichungen in GuV, in der Bilanz sowie beim Jahresüberschuss ausgegeben.
In der Anwendung Löschen Salden (aufrufbar aus EA) wird jetzt neben den Salden auch der zugehörige Herkunftsnachweis mitgelöscht.
Eine neue Funktion <Abgleich Ges.Vorträge neue Periode> ermöglicht eine Überprüfung, ob die vorgetragenen Daten noch konsistent zu den Vorperiodendaten sind. Diese Prüfung bezieht sich auf die Bewegungsaufrisse (Anlagen-, Kapital-, Rückstellungsbewegungen, Anteilsbesitz, individuelle Spiegel). Analog zur Funktion <Abgleich Ges.Abschluss neue Datenart> werden zwar die Ergebnisse wie beim echten Vortrag berechnet, aber nicht in die Datenbank geschrieben. Die Differenzen werden im Meldungsfenster ausgegeben. Die neue Funktion kann aus EA und PERGES heraus aufgerufen werden.
Das Ergebnisvortragskonto beim Vortrag auf Konzernkontenplänen wird jetzt nicht mehr anhand des Konto-Kennzeichens 'W' aus dem Kontenplan ermittelt, sondern aus der Angabe im neuen Attribut der Datenart.
Im WUM-Kopfsatz wurde ein neues Attribut <Referenz-Gesellschaft> ergänzt. Die Angabe einer Referenz-Gesellschaft bewirkt, dass sämtliche Steuerungsdaten für die Währungsumrechnung (Umrechnungsverfahren, Wechselkursart, Behandlung Umrechnungsdifferenz, Differenzkonten und Konto-Umrechnungsanweisungen) nicht mehr aus den Angaben für die aktuelle Gesellschaft, sondern aus den Angaben für die Referenz-Gesellschaft herangezogen werden. Bei Angabe einer Referenz-Gesellschaft ist die Angabe von Steuerungsdaten im aktuellen WUM-Kopfsatz nicht mehr zulässig. Gespeichert werden hier (gesellschaftsbezogen) nur noch die Umrechnungsdifferenzen.
Die Angabe einer Referenz-Gesellschaft setzt voraus, dass die Umrechnungsanweisungen beider Gesellschaften gleich sind, so dass durch die Zuweisung das Stetigkeitsprinzip nicht verletzt wird. Bei Datenarten auf der Ebene von Gesellschaftskontenplänen müssen außerdem die Kontenpläne übereinstimmen. Bei Gesellschaften mit unterschiedlichen Landeswährungen müssen vorgegebene Kurse (Umrechnungsanweisung 'VK') aber weiterhin je Gesellschaft gepflegt werden.
Sollen alle Gesellschaften des Konzerns nach denselben Steuerungen umgerechnet werden, so müssen die Steuerungsdaten künftig nur noch für eine Gesellschaft gepflegt werden, wenn diese bei allen anderen Gesellschaften als Referenz-Gesellschaft angegeben ist. Ggfs. ist noch nach einer Referenz-Gesellschaft für Konzernwährungsgesellschaften und einer Referenz-Gesellschaft für Fremdwährungsgesellschaften zu unterscheiden.
Um die Umstellung auf die Verwendung einer Referenz-Gesellschaft zu vereinfachen, gibt es zwei neue Funktionen:
Neu ist das Umrechnungsverfahren 'MZK', das die in der Praxis häufig verwendete Konstellation darstellt, dass nur die Kapitalkonten historisch ('FDK') umgerechnet werden, die Anlagenkonten dagegen zum Stichtagskurs ('SK').
Gemäß den Ausführungen im vorigen Abschnitt werden auch die Konto-Umrechnungsanweisungen nicht mehr für eine Gesellschaft benötigt, sofern im WUM-Kopfsatz für diese Gesellschaft eine Referenz-Gesellschaft angegeben ist.
Aber auch bei der Referenz-Gesellschaft muss nicht mehr wie bisher für jedes Konto eine Umrechnungsanweisung angegeben werden. Fehlt eine Umrechnungsanweisung, so unterstellt die Währungsumrechnung den Defaultwert gemäß dem im WUM-Kopfsatz angegebenen Umrechnungsverfahren:
In der Tabelle für Konto-Umrechnungsanweisungen müssen also nur noch für diejenigen Konten Datensätze erfasst werden, deren Umrechnungsanweisungen vom Standard des Umrechnungsverfahrens abweichen (z.B. AfA-Konten mit 'SK' statt 'PDK'). Gleichzeitig ist die Anwendung <Aktualisieren Konto-Umrechnungsanweisungen> entfallen, da sie durch diese Steuerung nicht mehr benötigt wird.
Durch diese Neuregelung ist die große Mehrzahl der bisher vorhandenen Sätze der Tabelle KTOUAW überflüssig. Diese Sätze werden daher durch das Konvertierprogramm automatisch gelöscht.
Die Übersicht Konto-Umrechnungsanweisungen zeigt aber weiterhin Zeilen für alle Konten des Kontenplans an. Sofern keine abweichende Anweisung in der Datenbank hinterlegt ist, wird der Standardwert gemäß Umrechnungsverfahren bzw. Umrechnungsanweisung der Referenz-Gesellschaft angezeigt, somit die Anweisung, mit der ein Kontensaldo auf diesem Konto ggfs. umgerechnet wird. In der Datenbank vorhandene Sätze mit vom Standard abweichenden Umrechnungsanweisungen werden durch die Farbe <gelb> in der Spalte 'S' (Standard-Kennzeichen) gekennzeichnet, sonst <grün>
Zum Ändern der Daten stehen in den Anwendungen KTOUAW und KTOUAWE die Aktionen <Ändern> und <Set UAW Standard> zur Verfügung. Bei <Ändern> wird ggfs. auch ein Satz in die Datenbank eingefügt. Bei <Set UAW Standard> wird ein Datenbanksatz gelöscht, um den Standardwert lt. Umrechnungsverfahren einzustellen.
Da Umrechnungsanweisungen nur noch in Sonderfällen explizit in der Datenbank gespeichert werden, wurde die Ablage der bei der Umrechnung tatsächlich verwendeten (Wechselkurs) und ermittelten Werte (Umrechnungsdifferenzen) in die Datenbank-Tabelle für Kontensalden verlagert. Dies bewirkt gleichzeitig, dass bei Führung der Daten nach Geschäftsbereichen auch die Umrechnungsdifferenzen nach Geschäftsbereich differenziert geführt werden.
Zur Anzeige dieser Werte dient eine neue Übersicht Umrechnungsnachweis, die als Folgeanwendung aus der Übersicht Währungsumrechnung KW+PW heraus aufgerufen werden kann. Im Gegensatz zur bisherigen Anwendung KTOUAW werden nur Zeilen für vorhandene Salden (aktuelle Periode oder Vorperiode) angezeigt, so dass die Übersicht kompakter ist.
Das Release-Konvertierprogramm sorgt für die Übertragung der Umrechnungsinformationen in die Kontensalden-Tabelle. Bei Führung nach Geschäftsbereichen werden die Differenzen dem jeweils alphabetisch kleinsten Geschäftsbereich zugeordnet. Eine entsprechende Umsetzung erfolgt auch bei der Übernahme von Teilkonzerndaten, wenn der Teilkonzern noch einen älteren Releasestand hat.
Zur Unterstützung der Einhaltung der Plausibilitätsbedingungen zwischen Anlagen- und Rückstellungsbewegungen einerseits und den korrespondierenden GuV-Konten (AfA-Konten, Zuführung/Auflösung von Rückstellungen) andererseits, nimmt die Währungsumrechnung vor der Umrechnung folgende Umsetzungen vor:
Die Umrechnung des Anlagespiegels nach der Zeitbezugsmethode wurde überarbeitet, um den Anforderungen von IFRS gerecht zu werden. Wenn ein Anlagenkonto mit der Umrechnungsanweisung FDK umgerechnet werden soll, dann ...
Wurden im WUM-Kopfsatz und in den Konto-Umrechnungsanweisungen bisher keine Angaben für die Umrechnung in die Parallelwährung gemacht, so erfolgte die PW-Umrechnung mit gewissen Annahmen (Wechselkursart gemäß gefundener Kurse, Umrechnungsanweisungen analog KW-Umrechnung). Die dabei verwendeten Parameter werden jetzt im WUM-Kopfsatz und in den Konto-Umrechnungsanweisungen eingetragen, so dass sie für die Folgeperiode vorgetragen werden. Die Variante mit fehlenden Angaben wird dann in einem späteren IDL Konsis-Release nicht mehr unterstützt.
Um die Entwicklung der Steuersätze über einen Zeitraum hinweg verfolgen zu können, wurde in der Übersicht LTK eine Selektion über mehrere Perioden zugelassen. Dazu wurde ein Eingabefeld "ab Periode" ergänzt.
Der LT-Kopfsatz wurde für die latenten Steuern im Einzelabschluss um einige Attribute erweitert (s.u.).
Eine neue Gruppe von Anwendungen unterstützt die Ermittlung und Darstellung von latenten Steuern im Einzelabschluss, wie sie u.a. vom IFRS gefordert wird.
Anwenderseitig werden dazu zwei neue Datenarten benötigt: eine Datenart, auf der die Steuerbilanz geführt wird (z.B. S4) und eine Datenart, auf die der IFRS-Abschluss ohne latente Steuern (z.B. I4) unter Einbeziehung der Buchungen für latente Steuern vorgetragen wird (z.B. I5). Die Basiswerte für die latenten Steuern ergeben sich dabei aus der Differenz zwischen dem IFRS-Abschluss (I4) und der Steuerdatenart (S4). Hier sind zwei Verfahren möglich:
Da es auf der Datenart I4 zwei Sorten von Buchungen gibt, zur Überleitung auf die Steuerdatenart S5 bzw. zur Überleitung auf die Konsolidierungsdatenart I5, wurde im Belegkopf (Anwendung BEL) ein Attribut Zieldatenart ergänzt. Belege, in denen eine Zieldatenart angegeben ist, werden nur beim Vortrag auf diese Datenart berücksichtigt. Die Buchungen über die Differenz zwischen I4 und S4 müssen bei einem Beleg mit der Zieldatenart S4 stehen. Entsprechend erhalten die später berechneten Buchungen für die latenten Steuern die Zieldatenart I5.
Die Buchungen der Differenz zur Steuerbilanz müssen gemäß ihrer Verarbeitung für die latenten Steuern klassifiziert werden. Dazu wurde ein Attribut LT-Kennzeichen in den Buchungen (Anwendung BUCH) ergänzt. Folgende Angaben sind möglich:
Bei der Generierung dieser Buchungen wird als Defaultwert 'permanent' eingestellt, damit der Anwender die für die latenten Steuern relevanten Buchungen explizit kennzeichnen muss. Fehler in der Vorperiode gemäß IAS 8 dürfen nicht zu einer nachträglichen Korrektur der Vorperiodenbilanz führen. Die Korrektur muss also über eine weitere Korrekturdatenart erfolgen. Hierfür bietet IDL Konsis aber keine maschinelle Unterstützung.
Latente Steuern werden auf den Buchungen auf der Datenart I4 gerechnet, in deren Belegkopf die Steuerbilanz-Datenart (S4) als Zieldatenart oder keine Zieldatenart angegeben ist. Es werden dabei nur die Buchungen berücksichtigt, die als temporär (erfolgswirksam oder erfolgsneutral) klassifiziert sind. Der Buchungsbetrag wird dabei mit dem Mischsteuersatz gemäß LTK-Satz (aktuelle Gesellschaft oder Referenz-Gesellschaft) multipliziert. Der resultierende Beleg besteht aus drei Buchungen:
Die vier Konten für diese Buchungen werden (neu) im Konsolidierungsparameter LT geführt. Diese Verarbeitung wird aus der Anwendung LTK heraus aufgerufen.
Eine weitere Folgeanwendung von LTK dient der Verarbeitung des Verlustvortrags in Folgeperioden. Aufgerufen wird die neue Anwendung LTVV. In deren Einzelsatzanwendung LTVVE können folgende Werte eingegeben werden:
Jeder dieser Werte kann in drei Spalten angegeben werden, die mit Bundessteuer, Landessteuer und Tax credit bezeichnet sind. Welche Spalten anzugeben sind, hängt vom jeweiligen Landesrecht ab. Zusätzliche Ausgabefelder sind je Spalte
Während die ersten beiden Werte nur dokumentarischen Zweck haben, wird die Angabe der dritten Zeile (verwendbarer Verlustvortrag) mit dem jeweiligen Steuersatz multipliziert. Die Prozentsätze sind (neu) in der Anwendung LTK anzugeben. Die berechneten Beträge werden mit einem Buchungspaar je Steuerart in einem Beleg gebucht von <Veränderung aktiver latenter Steuern auf steuerliche Verlustvorträge> an <latente Steuern lt. GuV auf aktivierte steuerliche Verlustvorträge>. Diese beiden Konten sind (neu) im Konsolidierungsparameter LT anzugeben.
Bei Angabe eines Organträgers zu einer Steuerart im LT-Kopfsatz (LTK) erfolgt keine Berechnung und Verbuchung des Verlustvortrages. Dies muss dann bei der Organträger-Gesellschaft erfolgen. Umgekehrt müssen bei der Bearbeitung eines Organträgers alle zugeordneten Organkreis-Gesellschaften zusammengefasst behandelt werden. Die Eingabewerte müssen vom Anwender entsprechend manuell eingegeben werden. Für die (automatische) Anzeige betrifft dies nur die Summe der temporären Differenzen, die dann über alle Organkreisgesellschaften summiert werden müssen.
In der Konsolidierungsparameterübersicht werden jetzt nur noch die Konten, aber nicht mehr die Controlling-Objekte angezeigt. Zur Ansicht der Controlling-Objekte muss in die jeweilige Einzelsatzanwendung verzweigt werden.
Im Konsolidierungsparameter für die Schuldenkonsolidierung (KTKPARSK) werden jetzt Bilanzkonten als Konten für Währungsdifferenzen zugelassen.
Für die neue Anwendung Konzernergebnis verrechnen wurde ein neuer Konsolidierungsparameter 'JU' mit der zugehörigen Einzelsatzanwendung KTKPARJU definiert.
Im Konsolidierungsparameter EK können jetzt als Konto für "sonstige Erträge" bzw. "sonstige Aufwendungen" auch Bilanzkonten angegeben werden.
Im Konsolidierungsparameter LT wurden mehrere Konten für die latenten Steuern im Einzelabschluss ergänzt.
In der Maske der Konzernkreisübersicht (KTKGES) wurde ein Eingabefeld für die SortOption ergänzt. Die Eingabe 'A' führt zu der bisherigen Anzeige mit Sortierung nach Konsolidierungsart. Alternativ sind die Angaben 'B' und 'K' möglich, durch die die Anzeige in Baumform (wie bei der Verarbeitungsaktion "Anzeigen/Prüfen Konzern/Tk-Struktur") ausgelöst wird. Bei 'K' erfolgt die Anzeige je Teilkonzern ebenfalls sortiert nach Konsolidierungsart, bei 'B' dagegen alphabetisch nach Gesellschaft.
Default-Einstellung für die Sort-Option ist 'K'. Ist die Konzernstruktur fehlerhaft definiert, kann es sein, dass keine Baumdarstellung möglich ist. In diesem Fall wird nur eine Fehlermeldung ausgegeben. Zur Anzeige der fehlerhaften Datenzeilen und zu deren Korrektur muss dann die Sort-Option 'A' gewählt werden.
Die Teilkonzernzeilen enthalten die Summe des gesamten Anteilsbesitzes der direkt in diesem Teilkonzern liegenden Gesellschaften, nicht der Gesellschaften untergeordneter Teilkonzerne. Die einzelnen Zweige können beliebig auf- und zugeklappt werden. Weitere Steuerungen stehen im Menü und in der Symbolleiste zur Verfügung.
Ergänzt wurde auch ein Eingabefeld für die Gesellschaft. Die Selektion nach Gesellschaft kann sinnvoll sein, wenn für die Gesellschaftsnummern Nummernkreise gebildet wurden.
Wird in der Maske von KTKGES die aktuelle Periode geändert, so erfolgt jetzt automatisch eine Anpassung der angegebenen Vorperiode. Eingestellt wird jeweils die im Periodenstamm (ABR) angegebene Vorperiode zur aktuellen Periode.
In der Maske gibt es eine neue Selektion nach Verarbeitungsstatus. Zur Auswahl stehen die Werte, die nach Markieren einer Zeile in den Statusfeldern sichtbar werden (z.B. 'E' für Fehler/rot, 'W' für Warnung/gelb). Auf diese Weise kann eine umfangreiche Anzeige auf die Zeilen reduziert werden, in denen eine Verarbeitung noch fehlt oder fehlerhaft war. Die Spalte <EA> wird bei dieser Selektion nicht berücksichtigt.
In der Statusdarstellung für die einzelnen Konsolidierungsverarbeitungen werden jetzt zwei fehlerhafte Zustände unterschieden. Die Farbe rot zeigt an, dass eine Konsolidierungsverarbeitung, die notwendig ist, noch nicht durchgeführt wurde. Die Farbe gelb zeigt an, dass die Konsolidierungsverarbeitung zwar durchgeführt wurde, aber weitere Schritte notwendig sind (z.B. Verrechnen des Unterschiedsbetrags in der Kapitalkonsolidierung, Verbuchen offener Differenzen in der Schuldenkonsolidierung).
Eine neue Aktion im Submenü <Übersichten> ermöglicht jetzt die Verzweigung aus der Konzernkreisübersicht (KTKGES) in die Übersicht der zugehörigen Konsolidierungsparameter (KTKPAR).
Aus KTKGES heraus kann die IC-Clearing-Übersicht (KGESGES) jetzt auch als globale Folgeanwendung, d.h. gesellschaftsübergreifend aufgerufen werden. Die entsprechenden Aktionen sind in den Submenüs für die SK-, AE- und ZA-Konsolidierung ergänzt worden.
Ähnlich der Freigabe eines Einzelabschlusses mit der Folge, dass die Einzelabschlussdaten nicht mehr verändert werden dürfen, gibt es jetzt auch eine Konzernabschluss-Freigabe, um weitere Änderungen am Konzernabschluss zu unterbinden.
Die Freigabe erfolgt durch eine entsprechende Aktion <Konzernabschluss freigeben> der Konzernkreisübersicht. Dieser Zustand wird durch ein 'X' in der neuen Spalte <Freigabe> in der Zeile des jeweiligen Konzerns/Teilkonzerns (nur in der Baumdarstellung) dokumentiert.
Die Freigabe kann durch die Aktion <Konzernabschluss aufheben Freigabe> wieder zurückgenommen werden. Dieser Zustand wird durch ein 'W' in der Konzern/Teilkonzern-Zeile dokumentiert.
Eine Übersicht der gesetzten Sperren ist durch eine neue Anwendung möglich, die über das Kurzwort KVERARB aufgerufen werden kann. Die hier angezeigte Tabelle ist analog der Verarbeitungssteuerung für Einzelabschlüsse aufgebaut. Der Checkpoint für die Konzernabschlussfreigabe wird mit "KTKAB" bezeichnet.
Die Prüfung, ob ein Konzernabschluss freigegeben ist, wurde in allen möglichen Konzernverarbeitungen ergänzt. Die neue Datenbanktabelle K019 wurde im konzernweiten Datenaustauschergänzt.
Da seit IDL Konsis-Version 5.2.0 auch KA-Belege in der Folgekonsolidierung KF vorgetragen werden, muss auch für Gesellschaften in einem übergeordneten Teilkonzern mit (bisherigem) KF-Status = 'T' eine KF durchgeführt werden, falls eine KA notwendig ist oder schon durchgeführt wurde (KA-Status = 'X' oder KA-Status = '4'). In diesem Fall wird der KF-Status jetzt mit '4' vorbelegt. Ausnahme: Die Gesellschaft ist erst in der aktuellen Periode neu hinzugekommen. Ist der KF-Vortrag bereits erfolgt, bleibt der Status 'X' erhalten.
Aus diesem Grund ist für die Beteiligungsermittlung jetzt die Angabe einer Vorperiode im aufrufenden Programm (KTKGES) erforderlich.
Wenn für den gesamten Konzern/Teilkonzern keine Beteiligung vorliegt (z.B. Vorträge noch nicht durchgeführt), wird eine entsprechende Warnung ausgegeben.
Das Thema Abschreibungen wurde mit dem aktuellen Release komplett überarbeitet. Die bisher explizit anzustoßenden Funktionen <Erstellen AfA Anlagenbewegungen (GA)> und <Erstellen AfA KapKons-Buchungen (KL)> entfallen dabei. Die neue Lösung basiert auf folgenden Grundprinzipien:
Diese Vorgehensweise hat die folgenden Auswirkungen, die zu beachten sind:
Entspricht die automatisch berechnete AfA nicht den benötigten Werten, stehen die folgenden beiden Möglichkeiten zur Verfügung:
Die AfA-Berechnung und -Verbuchung erfolgt jetzt ggfs. differenziert nach Geschäftsbereichen.
Die Warnungsmeldung KON1279 ("Achtung: Vorhandene Ergebnisse ... werden gelöscht!") bei der Aktion <Löschen + ...> für die SK- oder AE-Konsolidierung hat sich bei der Mengenverarbeitung als unpraktikabel erwiesen und wird daher jetzt nicht mehr ausgegeben. Stattdessen enthalten die Submenüs vor dieser Aktion einen Trennstrich, um versehentliches Auslösen zu vermeiden.
Maschinell erstellte SK- und AE-Belege dürfen nicht mehr manuell gelöscht werden. Das Löschen ist nur noch durch Löschen des zugehörigen IC-Clearingsatzes in der Anwendung KGESGES möglich. Auf diese Weise ist die Konsistenz der Buchungen mit der Statusdarstellung in KGESGES und KTKGES gewährleistet.
Der Schalter <Ausrichtung nach Aufwand/Ertrag> wird in der Aufwands-/Ertragskonsolidierung jetzt wieder unterstützt. Dabei werden verschiedene Sonderfälle unterstützt. Ausführliche Beispiele zur Buchungslogik befinden sich im Hilfetext zur Anwendung SKAEAUTO.
Bei der Schulden- und der Aufwands-/Ertragskonsolidierung wird die frühere Buchungslogik wieder hergestellt. D.h. Differenzen im Soll führen zu Buchungen auf dem Aufwandskonto, Differenzen im Haben zu Buchungen auf dem Ertragskonto.
In der IC-Clearing-Übersicht wird jetzt neben der Status-Spalte eine farbige Spalte analog den Statusspalten in EA und KTKGES angezeigt. Für die Statuswerte '1', '2', '3', '5' und 'T' wird die Farbe grün ausgegeben, für den Statuswert '4' dagegen rot. Hierdurch werden die Gesellschaftspaare hervorgehoben, für die noch eine manuelle Nachbearbeitung der Belege erforderlich ist.
Die Spalte <Wert aus TW-Clearing> wurde umbenannt in <Diff aus TW-Clearing>, die Spalte <Differenz> in <Sachdifferenz>. Der in <Diff aus TW-Clearing> angezeigte Wert wird jetzt von dem bisher in <Differenz> angezeigten Wert subtrahiert, so dass sich die Gesamtdifferenz aus der Summe beider Spalten ergibt.
Enthält ein SK- oder AE-Beleg nur Buchungen auf statistischen Konten, so wurde bisher kein Abstimmsatz in die IC-Clearing-Übersicht geschrieben. Jetzt wird auch für statistische Sachverhalte ein solcher Satz geschrieben und mit Status '1' versehen.
Werden im Rahmen der Schuldenkonsolidierung Spiegelkonten (Anlagen, Kapital, Rückstellungen oder individuelle Spiegel) angesprochen, so erfolgte bisher nur eine Anpassung von Anlagen (Ausleihungen), aber auch diese nur mit dem Standard-Buchungsschlüssel '41' (Zugang AHk). Die eigentlichen Bewegungen auf diesem Konto (z.B. Abgänge, Umbuchungen, Abschreibung) wurden nicht gemäß dem Anlagenspiegel des Einzelabschlusses eliminiert, so dass in den Spalten des Konzern-Anlagenspiegels Werte offen blieben, obwohl der Kontensaldo korrekt eliminiert war. Diese Lücke wird jetzt durch die neue Konsolidierungsverarbeitung "Spiegelumbuchung" geschlossen.
Die Schuldenkonsolidierung (SK) selbst setzt in die Buchungen auf Spiegelkonten einen Standard-Buchungsschlüssel (Umbuchung) und erzeugt dazu eine korrespondierende Konzernbewegung. Dies eliminiert wie bisher die Kontensalden auf IC-Konten. Anlagenvorträge werden künftig nicht mehr verarbeitet. Beim Konzernvortrag werden die Bewegungen aus der Schuldenkonsolidierung künftig nicht mehr vorgetragen, da sie in der nächsten Periode immer neu ermittelt werden.
Die neue Anwendung "SK-Spiegelumbuchung" erzeugt je Gesellschaft einen Beleg mit nur einer Gesellschaft in der Belegnummer und der Konsolidierungsverarbeitung 'SU'. Zunächst werden die bei der Schuldenkonsolidierung erzeugten Buchungen auf Spiegelkonten (summiert über alle IC-Gesellschaften) wieder mit denselben Buchungsschlüsseln eliminiert. Dagegen werden Buchungen gestellt, die spaltengerecht (einschl. der Vorträge) den Spiegel aus dem Einzelabschluss eliminieren.
Der benötigte Konzern-Buchungsschlüssel wird aus der (neuen) Angabe des Referenz-Buchungsschlüssels des Gesellschafts-Buchungsschlüssels entnommen (s. Anwendung BSL). Da hier die Bedingung besteht, dass der Referenz-Buchungsschlüssel derselben Spiegelspalte zugeordnet sein muss wie der Gesellschafts-Buchungsschlüssel, wird der Einzelabschluss spaltengerecht eliminiert und der Konzernspiegel sauber dargestellt.
Einzige Ausnahme ist ein Teikonzern, der IC-Salden aufweist, die über den Teilkonzernkreis hinausgehen. Hier wird über die IC-Salden nur ein Teil des Saldenbetrags verarbeitet, über den Einzelabschluss-Spiegel aber der komplette Kontensaldo, so dass eine Differenz offen bleibt. Diese Differenz muss manuell verbucht werden.
Da die neue Anwendung "SK-Spiegelumbuchung" erst nach Abschluss der Schuldenkonsolidierung für alle Gesellschaften laufen darf, werden ggfs. bereits vorhandene SU-Belege bei Neuerstellung der SK gelöscht.
Es wurde eine neue Konsolidierungsverarbeitung mit Namen "Ergebnisverrechnung Konzern" (Kurzwort KTKERGV) erstellt. Diese Anwendung erstellt einen Beleg mit der (neuen) Konsolidierungsverarbeitung 'JU'. Die Belegnummer erhält als erste Gesellschaft die Muttergesellschaft des Konzerns (bei Gleichordnungskonzernen die alphabetisch erste), die zweite Gesellschaft bleibt leer.
Für diese Anwendung wird ein neuer Konsolidierungsparameter 'JU' benötigt. Er enthält drei Konten: das JÜ-Konto, ein Verrechnungskonto Bilanz und ein Verrechnungskonto GuV. Die Konten sind optional. Fehlen sie, wird der entsprechende Teil der Verarbeitung nicht durchgeführt. Zur Pflege wurde die neue Einzelsatzanwendung KTKPARJU erstellt.
Die neue Anwendung KTKERGV liest alle anderen Konsolidierungsbuchungen des Konzerns und summiert diese je Gesellschaft nach folgenden Kriterien:
In der Anwendung REPKTK wird dieser Beleg nicht in einen reporttechnischen Teilkonzern übernommen, da aus der Belegnummer nicht ersichtlich ist, welche Gesellschaften in den Buchungen angesprochen werden. Der Beleg muss für den reporttechnischen Teilkonzern neu erstellt werden.
Die neue Anwendung wird als Folgeanwendung von KTKGES aufgerufen. Da sie nach allen anderen Konsolidierungsverarbeitungen laufen muss, wurde sie am Ende des Aktionsmenüs eingeordnet.
In KTKGES wurde eine Statusspalte für diese Verarbeitung (Überschrift 'JU') ergänzt, die nur anzeigt, ob diese Verarbeitung gelaufen ist und dabei Daten erzeugt hat (grün/'X') oder nicht (weiß/'-'). Wenn die Verarbeitung nicht aufgerufen wurde oder ein erzeugter Beleg wieder gelöscht wurde, bleibt die Spalte leer, desgleichen wenn der Konsolidierungsparamter 'JU' nicht definiert ist (Bedeutung: Anwender will diese Funktion nicht nutzen). Da die Verarbeitung nicht je Gesellschaft, sondern für den gesamten Konzern erfolgt, erfolgt die Statusanzeige auch nicht je Gesellschaft, sondern je Konzern/Teilkonzern und daher nur in der Baumstruktur (nur dort Konzern/Teilkonzern-Zeile).
Die manuelle und maschinelle Erstkonsolidierung (KE bzw. KM) unterstützt jetzt auch den Fall, dass der Anteilsbesitz auf mehrere Beteiligungskonten aufgeteilt ist. Es wird dann je Beteiligungskonto ein Anlagenobjekt für den Beteiligungsansatz generiert. Im Namen dieser Anlagenobjekte wird dann statt bisher fest 'KK' variabel 'Kn' verwendet, wobei 'n' von '0' bis '9' variieren kann. Somit sind maximal 11 Beteiligungskonten möglich.
Zur zweifelsfreien Spaltenzuordnung im Konsolidierungsreport werden die EM-Belege aus der Equity-Erstkonsolidierung nicht mehr mit der Konsolidierungsverarbeitung 'KK', sondern mit der Konsolidierungsverarbeitung 'EK' versehen. Für bestehende Belege erfolgt diese Umsetzung durch die Release-Konvertierung. Beim Verrechnen der Unterschiedsbeträge (VUB) werden Equity-Belege durch die Selektion nach Konsolidierungsverarbeitung 'EK' selektiert.
Die Stornierung von KF-Buchungen bei der Endkonsolidierung (KS) erfolgt jetzt nicht mehr mit Vortrags-Buchungsschlüsseln, sondern mit Buchungsschlüsseln für den Abgang aus dem Konsolidierungskreis.
Rundungsdifferenzen, die bei der Endkonsolidierung aufgrund eines nur teilweisen Abgangs entstehen können, werden jetzt auf dem Konto für Endkonsolidierung aus dem Konsolidierungsparameter KK verbucht.
Bei der Equity-Erstkonsolidierung ('EM') wird u.a. ein mit 'EM+' im Namen beginnendes Anlagenobjekt generiert. Dieses war der Tochtergesellschaft zugeordnet und enthielt auch die Tochtergesellschaft im Namen. Damit war dieses Anlagenobjekt nicht mehr eindeutig, wenn mehrere Konzerngesellschaften an einer Equity-Gesellschaft beteiligt waren.
Das 'EM+'-Anlagenobjekt wird daher künftig mit der Muttergesellschaft anstelle der Tochtergesellschaft im Namen generiert. Bei der Equity-Fortschreibung (Anwendung FORTEQE) werden ggfs. KF-Buchungen auf Anlagenobjekte in alter Nomenklatur storniert und auf Anlagenobjekte neuer Nomenklatur umgebucht.
Bei der Equity-Fortschreibung (Anwendung FORTEQE) werden die Werte in den Zeilen für <Abschreibungen Mehrwert/Goodwill> und <Abschreibungen stille Reserven> nicht mehr auf Basis der Anlagenbewegungen, sondern auf Basis der Konsolidierungsbuchungen (EM- bzw. KF-Beleg) ermittelt.
Der Vortrag von Buchungen für indirekte Fremdanteile erfolgt jetzt in einem separaten Beleg, der die Konsolidierungsverarbeitung 'KV' in der Belegnummer enthält, aber (zur Unterscheidung von indirekten Fremdanteilen alter Buchungstechnik) 'KF' als Attribut im Belegkopf. Die Verarbeitungsfolge über mehrere Perioden sieht dann folgendermaßen aus:
Bei der Verbuchung indirekter Fremdanteile wird jetzt auch die Thesaurierung bzw. Minderung des Eigenkapitals berücksichtigt. Hat sich das Eigenkapital (Kontensalden) gegenüber der Erstkonsolidierung (Buchungen im KF-Beleg, Buchungssatz-Nr. 01) verändert, werden auf die Differenzen Fremdanteile berechnet und verbucht. Berücksichtigt wird jetzt auch der Fall, dass im Einzelabschluss auf einem Kapitalkonto kein Saldo vorhanden ist, sondern nur Konsolidierungsbuchungen.
Ist das Konto "Fremdanteil - ind. Unterschiedsbetrag" im Konsolidierungsparameter KK nicht angegeben oder identisch zum Konto "Fremdanteil - Ausgleichsposten", so wird bei der Verbuchung der Fremdanteile jetzt eine Fehlermeldung ausgegeben, wenn dieses Konto verwendet wird, da in folgenden Verarbeitungsschritten (VUB-KA) die Ermittlung des Unterschiedsbetrags nicht oder nicht eindeutig möglich wäre. In KTKPARKK wird jetzt auch geprüft, dass die beiden Konten nicht identisch sein dürfen.
Für Kurseffekte wird jetzt nur noch der anteilige Wert berücksichtigt. Bisher wurde der gesamte Wert verbucht.
Hat eine Gesellschaft mit indirekten Fremdanteilen mehrere Muttergesellschaften, so wird dies jetzt korrekt berücksichtigt. Ebenso wird der Fall, dass die Beteiligung auf mehrere Konten verteilt ist, berücksichtigt.
Bei der Zwischenergebniseliminierung im Anlagenvermögen werden jetzt unabhängig vom Buchungsschlüssel zu allen Anlagenbewegungen für Zu- und Abgangskarten ZA-Konsolidierungsbuchungen erzeugt. Bisher war dies auf bestimmte BSL beschränkt. Ausgenommen sind Anlagenbewegungen des automatischen Vortrags, die im Konzernvortrag durch Buchungen im VX-Beleg wiedergegeben werden, sowie die laufende Afa, die jeweils automatisch neu berechnet wird (s. Kapitel Abschreibungen auf Konzernanlagenobjekte)
In die IC-Clearing-Übersicht werden jetzt nur noch Sätze für die Gesellschaftspaare eingetragen, für die ZA-Sachverhalte vorliegen.
Maschinell erstellte ZA-Belege dürfen nicht mehr manuell gelöscht werden. Das Löschen ist nur noch durch Löschen des zugehörigen IC-Clearingsatzes in der Anwendung KGESGES möglich. Auf diese Weise ist die Konsistenz der Buchungen mit der Statusdarstellung in KGESGES und KTKGES gewährleistet.
Die Anwendungen zur Zwischenergebniseliminierung im Umlaufvermögen wurden an die neue Datenbank-Tabelle für IC-Bewegungen angepasst. Zur besseren Zuordnung von IC-Bewegungen zu Konsolidierungsbuchungen wird jetzt für jedes Buchungspaar eine eigene Buchungssatz-Nummer vergeben.
In diesem Zusammenhang wurde auch eine konsequente Versorgung des Geschäftsbereichs in den Konsolidierungsbuchungen ergänzt.
Bei Aufruf der Anwendung KONBUCH aus KONBEL oder KONBUCH ("Detailansicht") heraus wird die Konsolidierungsverarbeitung nicht mehr als Parameter übergeben.
Die bereits in KONBUCH implementierte Sicht "KTk einschließlich aller untergeordneten Teilkonzerne" ist jetzt auch in der Übersicht KONBEL möglich. Dazu wurde neben dem Konzern/Tk ein Eingabefeld ergänzt, das nur in der erweiterten Sicht ausgegeben wird.
Beim Löschen eines maschinell erstellten Konsolidierungsbeleges wird auch der zugehörige Statusschalter der Konzernkreis-Übersicht KTKGES auf leer gesetzt.
In der Tabelle der Übersicht KONBEL wurde eine Kurzwort-Übersetzung der beiden in der Belegnummer enthaltenen Gesellschaften ergänzt.
Die Aktionen <Setzen Verarb.Knz auf B=verarbeiten> und <Löschen Verarb.Knz von B auf I=Info> in der Übersicht KONBEL sind entfallen und wurden ersetzt durch die Möglichkeit, das Attribut "Verarbeitungs-Kennzeichen" über die Aktion <Mengen-Ändern> zu ändern.
Die Darstellung der Reportübersichten (REP, REPK) erfolgt jetzt immer in einer einstufigen Baumstruktur. Als Knoten werden diejenigen Report-Ids verwendet, die in der Anwendung REPE als Report-Gruppe eingetragen sind. Die Report-Gruppen müssen in der Anwendung RIDE angelegt und mit dem Report-Typ 'G' (Gruppe) versehen werden. Damit wird auch verhindert, dass für diese Report-Idents Reportzeilenbeschreibungen oder Reportkopfsätze angelegt werden können. Auf diese Weise können die verschiedenen Reports nach anwenderspezifischen Kriterien sortiert werden. Report-Ids, für die keine Report-Gruppe angegeben ist, werden unter der Dummy-Report-Gruppe 'REP' bzw. 'REPK' zusammengefasst.
Eine andere Art der Baumdarstellung der Report-Übersicht kann durch das Kurzwort REPSTR aufgerufen werden. Hierbei muss ein Konzern/Tk sowie eindeutig die Report-Id und die Report-Version angegeben werden. Die Anzeige erfolgt dann über alle Konzern- und Gesellschafts-Reports in der Konzernstruktur. Somit kann geprüft werden, ob ein Standard-Report für alle Gesellschaften und Teilkonzerne fehlerfrei (einschl. korrekter Prüfziffern) erstellt wurde. REPSTR kann aus REPK heraus als Folgeanwendung aufgerufen werden.
In den Report-Übersichten (REP, REPK) wurden weitere Spalten für Prüfziffern des Einzelabschlusses ergänzt. Es wird jetzt nach Prüfziffern für Kontensalden und Prüfziffern für Aufrisse unterschieden. Bei einfachen Bil/GuV-Reports sind wie bisher nur die Prüfziffern für Kontensalden belegt. Bei den Spiegeln werden die bisherigen Prüfziffern der Spiegeldaten in den Prüfziffern für Aufrisse angezeigt und zusätzlich die Prüfziffern der Kontensalden. Neu ist auch die Darstellung von Prüfziffern für Controllingsalden in den Aufriss-Prüfziffern für Controlling-Reports.
In der Reportergebnisübersicht wird die Prüfziffer der Kontensalden sowie auch ggfs. die Prüfziffern für Aufrisse und für Konsolidierungsbuchungen angezeigt.
Die Umsetzung bzw. Neuberechnung der bisher fehlenden Prüfziffern erfolgt im Release-Konvertierprogramm auch für ältere Reports. Dadurch wird vermieden, dass diese mit abweichenden Prüfziffern gemeldet werden.
Für alle Bil/GuV-Reports wird überdies geprüft, ob sich die VERARB-Sätze der zugehörigen IC-Salden seit der Report-Erstellung verändert haben, um zu prüfen, ob der Report auch in Bezug auf die IC-Salden und damit auf die SK/AE-Konsolidierung aktuell ist. Das Ergebnis dieser Prüfung wird in einer entsprechenden neuen Spalte in Ampeldarstellung angezeigt.
Die Objektberechtigung für den Objekttyp "AGB" (Positionsplan, Report-Ident, Spaltenoption) wirkt jetzt nicht mehr bei der Erstellung eines Reports einschränkend, sondern nur noch für die Pflege der zugehörigen Stammdaten (POP, POS, RID, SPO, SPA) und Strukturdaten (POSKTO, REPZEI, FED).
Da ein Report-Ident als Kopfsatz einer Report-Zeilenbeschreibung nur einem Report-Typ (z.B. Bil/GuV-Report, Periodenreport, Konsoldierungsreport) zugeordnet werden kann, mussten bisher identische Zeilenschemata für die verschiedenen Report-Typen gepflegt werden. Um dies künftig zu vermeiden, kann jetzt einem Report-Ident ein Referenz-Report-Ident zugeordnet werden, über den das Zeilenschema spezifiziert wird. Ist kein Referenz-Report-Ident angegeben, spezifiziert wie bisher der Report-Ident selber das Zeilenschema.
Durch Nutzung von neuen Möglichkeiten der programminternen Speicherverwaltung konnte die Laufzeit von Reports in der Phase <Berechnen> deutlich reduziert werden.
Die Soll/Haben-Steuerung zur seitengerechten Darstellung der Konten wurde für einige Spezialfälle korrigiert.
Über den neuen Report-Typ 'V' (Angabe in der Anwendung Report-Ident) kann ein Report als Konsolidierungs-Report deklariert werden. Dieser Report unterscheidet sich vom herkömmlichen Bil/GuV-Report darin, dass die Konsolidierungsbuchungen gemäß ihrer Konsolidierungsverarbeitung auf verschiedene Spalten der Reportergebnistabelle aufgeteilt werden. Diese Aufteilung erfolgt anhand der Konsolidierungsverarbeitung, die als einzelnes Attribut im Belegkopf eingetragen wird. Zur einheitlichen Belegung dieses Attributs wird dieses jetzt analog zur Referenz-KVA, die in der Anwendung KVA der Konsolidierungsverarbeitung aus der Belegnummer zugeordnet wird, vergeben. Die genaue Spaltenbelegung entnehmen Sie bitte dem Hilfetext zur "AGB" #REP#.
Zur Anzeige eines Konsolidierungsreports wurde zunächst die Spaltenoption #KVA von IDL definiert. Hier werden die Konsolidierungsbuchungen auf die folgenden 8 Anzeigespalten verdichtet: Vortrag (VK), Kapitalkonsolidierung (KE, KM, KF, KS, KA), Equity-Konsolidierung (EM, EF), Aufwands-/Ertragskonsolidierung (AE), Schuldenkonsolidierung (SK), Zwischenergebniseliminierung (ZA, ZU), Latente Steuern (LT), Manuelle Buchungen (MB, AO). Zusätzlich gibt es wie im Bil/GuV-Report die Spalten für den Summenabschluss, den Konzernabschluss und den Konzernabschluss der Vorperiode. Alternative Spaltenoptionen können kundenspezifisch ergänzt werden.
Über den neuen Report-Typ 'C' (Angabe in der Anwendung Report-Ident) kann ein Report als Controlling-Report deklariert werden. Bei diesem Report werden die Werte je Controlling-Kennzeichen 1 (Herstellkosten, Vertriebskosten, ...) in Spalten dargestellt.
Die Reportergebnisspalten enthalten immer paarweise Saldo und Buchungen. Die ersten beiden Spalten enthalten den Gesamtwert der aktuellen Periode. Darauf folgen die beiden Spalten für die Vorperiode. In den übrigen 20 Spalten können bis zu 10 Wertepaare für Ausprägungen des Controlling-Kennzeichens 1 untergebracht werden. Derzeit werden davon 12 Spalten für 6 Ausprägungen benötigt.
Zur Anzeige eines Controlling-Reports werden die neuen Spaltenoptionen #CALT, #CBUC, #CKON, #CKTK, #CNEU und #CSUM zur Verfügung gestellt.
Reports für individuelle Spiegel werden jetzt unabhängig von der Einstellung des Schalters "exKonBuch" im Periodenstamm immer auf Basis der Konsolidierungsbuchungen erstellt, da für individuelle Spiegel keine Konzernbewegungen geführt werden.
Spaltenoptionen, die kundenseitig insbesondere für die individuellen Spiegel angelegt werden müssen, können jetzt auch ohne Zuordnung auf Gesellschafts- bzw. Konzernebene definiert werden. Damit können sie auf beiden Ebenen verwendet werden.
Entsprechend der Darstellung im Einzelabschluss wird jetzt bei der Prüfung der Spiegeldaten im Report zwischen Fehlern und Warnungen unterschieden. Differenzen bei den spaltenbezogenen Prüfungen (z.B. Umbuchungsspalte saldiert nicht zu null, Abweichungen zwischen Afa-Konten und Anlagenbewegungen für Spalte laufende AfA) werden als Warnung ausgegeben. Liegen keine Fehler, sondern nur Warnungen vor, wird anstelle der Meldung "Es sind Fehler aufgetreten" die Meldung "Es sind nicht alle Plausibilitäten erfüllt" ausgegeben.
Neben dem Feld "Kontenplan" wurde ein Eingabefeld für die Konto-Nr. ergänzt. Dies ermöglicht die Detailansicht auf einzelne Konten. Bei Aktion <Detailansicht> auf einer Zeile mit Konto-Nr. wird die Konto-Nr. automatisch zusätzlich zur Positions-Nr. in den Kopfteil eingestellt. Achtung: Bei Gesellschafts-Reports ist diese Steuerung nur bei eindeutigem Kontenplan möglich.
Die Auswahl auf dem Eingabefeld für das Währungskennzeichen beschränkt die Anzeige jetzt auf die verfügbaren Währungen (KW, PW sowie ggfs. LW). Die bisherigen Anzeigefelder für die verfügbaren Währungen entfallen. Die verfügbaren Währungen werden bei der Reporterstellung in den Report-Kopfsatz eingetragen.
In der Reportergebnisanzeige ist jetzt die Ausgabe von bis zu 20 Wertspalten möglich (bisher 14). Entsprechende Spaltenoptionen sind kundenspezifisch zu definieren. Dies kann z.B. für individuelle Spiegel genutzt werden oder zur Erstellung eines Anlagenspiegels mit allen definierten Spiegelspalten.
Reportergebnisse können jetzt als Baumstruktur angezeigt werden. Die einzelnen Zweige können beliebig auf- und zugeklappt werden. Weitere Steuerungen stehen im Menü und in der Symbolleiste zur Verfügung.
Zur Anzeige in der Baumstruktur dienen die neuen Aufrissoptionen, die ein 'B' enthalten:
Von den bisherigen Aufrissoptionen bleiben damit nur noch 'A', 'A0' und 'F' erhalten. Bei diesen Aufriss-Optionen wird der Report in der herkömmlichen Weise angezeigt.
Die evtl. im Report-Kopfsatz vorgegebene Default-Aufrissoption zur Anzeige dieses Reports wird per Konvertierprogrammgemäß obiger Aufstellung umgesetzt.
Die Programme zum Teilkonzern-Datenaustausch wurden für verschiedene Tabellenerweiterungen angepasst.
Hat der Teilkonzern noch einen älteren Releasestand, so werden die Umrechnungsinformationen aus der Tabelle für Konto-Umrechnungsanweisungen in die Tabelle für Kontensalden verschoben.
Die Programme zum konzernweiten Datenaustausch wurden für verschiedene Tabellenerweiterungen angepasst.
Die Angabe von '#KEY' in einem der Schlüsselparameter führt jetzt dazu, dass beim Aufruf der Automatenanwendung der Selektionsbereich ein entsprechendes Muss-Eingabefeld enthält, in dem dieser Schlüssel dann zur Laufzeit eingegeben werden muss. Diese Eingabefelder werden gemäß der Vorbelegung des aktuellen Benutzers mit Werten vorbelegt. Bei der Gesellschaft sind auch mehrdeutige Eingaben (z.B. '%') zulässig. Die Eingaben unterliegen der Berechtigungsprüfung.
Wird in MENMENE durch die Angabe Gesellschaft = '#KTK' gesteuert, dass die Menge der zu verarbeitenden Gesellschaften aus einem Konzernkreis zu ermitteln ist, wird für den Zugriff auf den Konzernkreis neben der aktuellen Datenart auch die ex-Datenart aus der Vorbelegung des Benutzers verwendet. Damit ist diese Steuerung jetzt auch für Datenarten unterhalb der Konsolidierungsdatenart möglich.
Mit dem IDL Konsis Release 5.3.0 wird die Version 2.2.4 des IDL Connector ausgeliefert. Zur Beschreibung s. hierzu die gesonderte Dokumentation.
Anwender, die mit IC-Bewegungen (Vorratsvermögen, Anwendung ICBEW) arbeiten, müssen zwingend die neue Version des Connectors verwenden. Ansonsten ist weder eine Erfassung noch eine Anzeige dieser Daten im Connector möglich.
Auf der CD "IDL IDL Konsis 5.3.0" finden Sie die aktuellen Transportaufträge für die unterschiedlichen SAP-Releases in entsprechenden Unterverzeichnissen.
Die SAP-Schnittstelle wurde um eine weitere Funktion f=UKV erweitert, um Salden aus dem UKV-Ledger (Tabelle GLFUNCT) aus SAP auszulesen.
Der Funktionsaufruf erhält dabei folgende Parameter (Schlüssel):
Beim Auslesen werden drei Varianten unterschieden, die in der Datei kcusap.ini im Bereich [Settings] eingestellt werden:
[Settings] UkvMitIC=x
Weiterhin ist jetzt die Möglichkeit gegeben, die IC-Salden zzgl. Transaktionswährung auszulesen.
Einzelheiten zu ggf. notwendigen Anpassungsmaßnahmen sind im Dokument doku\Interfaces\SAP\kcusap.pdf auf der CD "IDL IDL Konsis 5.3.0" enthalten.
Die Schnittstellen für die DCW-Releases 3.4.5 und 3.5 sind wesentlich erweitert worden, so z.B. für das Problem der "internen Belege", das selektive Auswählen über DCW-Mandantenkreise und das Auslesen mehrerer Mandanten auch bei abweichenden Geschäftsjahren.
Die Schnittstellen für das DCW-Release 3.5 müssen installiert sein, wenn Sie in DCW mit unterschiedlichen Rechnungslegungen (HGB / IFRS) arbeiten.
Für die Überleitung der IDL Konsis-Daten auf eine MIK-OLAP-Datenbank wurde eine Reihe neuer Views definiert. Diese Views sind DBMS-unabhängig. Sie können nur in Verbindung mit einem MIK-Olap-Server genutzt werden.
Nachdem es bei einem Kunden zum Überlauf der Protokolldatei für die Erstellung von MIS-Datenbeständen gekommen war, wird die Datei jetzt in Abhängigkeit vom Freigabe-Kennzeichens im MIS-Parameter vor einem Lauf gelöscht (bei 'J') bzw. nicht gelöscht (bei 'N'). Tritt bei der Aktion <Erstellen MIS-Datentabellen> ein Fehler auf, wird das Freigabe-Kennzeichen auf 'N' gesetzt, damit das Fehlerprotokoll beim nächsten Start nicht automatisch gelöscht wird.
Mit dem Release 5.3.0 wurden folgende Dokumentationen aktualisiert: