Das Release IDL.KONSIS.FORECAST 2009.0 ist ein Hauptrelease und darf daher in der Releasefolge nicht ausgelassen werden. Mindestvoraussetzungen zur Installation dieses Releases ist das letzte Hauptrelease 2008.0 vom 3. 9. 2008.
Die Erweiterungen des Zwischenreleases IDL.KONSIS.FORECAST 2008.1 sowie die bis zum Release-Abschluss erfolgten Nachträge und Korrekturen zu diesen Releases sind in diesem Hauptrelease 2009.0 enthalten.
Diese Dokumentation beschreibt die Erweiterungen seit dem letzten Zwischenrelease IDL.KONSIS.FORECAST 2008.1. Sofern dieses Zwischenrelease noch nicht zuvor installiert war, wird empfohlen, sich auch über die Erweiterungen im Zwischenrelease 2008.1 zu informieren.
Vor Installation eines neuen Releases sollte grundsätzlich eine Datenbank-Sicherung vorgenommen werden. Um den Anwender vor Datenverlust zu schützen, wird ein Hinweis auf die notwendige Datensicherung jetzt auch vom Installationsprogramm selbst am Anfang der Installation ausgegeben.
Nach Installation eines neuen Releases sollte grundsätzlich als erstes die Release-Konvertierung vorgenommen werden. Wegen der umfangreichen Umstellungen in diesem Release (s. Kap. 4.1) ist dies beim Release 2009.0 zwingend. Die Konvertierung kann je nach Größe der Datenbank einige Zeit in Anspruch nehmen.
Anwender, die bisher mit der historischen Umrechnung von Anlagen (Umrechnungsanweisung 'FDA' oder Umrechnungsverfahren 'MZB') gearbeitet haben, müssen künftig eine analoge Steuerung über die Buchungsschlüssel-Umrechnungsanweisungen (BSLUAW) definieren. Hinweise dazu finden Sie in den Kapiteln 2.1 und 10.1.
Wegen der Umstellung der Funktionen zur Kapitalkonsolidierung und den Fremdanteilen sollte das Release 2009.0 nicht während eines Konzernabschlusses installiert werden. Der Konzernvortag in die aktuelle Periode kann bereits mit dem Release 2009.0 für bereits abgeschlossene Konzernabschlüsse als Quelle durchgeführt werden. Alle weiteren Konsolidierungsverarbeitungen sollen dann für den neuen Konzernabschluss ausschließlich mit dem Release 2009.0 durchgeführt werden.
Wegen umfangreicher Umstrukturierungen der Datenbank sind die Datenaustauschformate des Releases 2009.0 und älterer Releases nicht miteinander kompatibel. Es ist erforderlich, dass sowohl die entladene als auch die ladende Installation den Stand 2009.0 haben. Dies betrifft sowohl den konzernweiten als auch den Teilkonzern-Datenaustausch.
Mit dem vorliegenden Release 2009.0 wird auch die aktuelle Version 11g der Datenbank Oracle unterstützt.
In der Entwicklung für die Excel-Anbindung IDLCONNECTOR von IDL.KONSIS.FORECAST befinden sich zusätzliche Funktionen, die mindestens die Version MS Excel 2003 voraussetzen. Wir empfehlen daher die Aufrüstung auf MS Excel 2003 oder noch besser MS Excel 2007.
Neue Tabellen und Anwendungen zur Spiegeldefinition
Zur Definition von Spiegeln, Spiegelspalten und Spiegelbereichen gibt es jetzt eigene Datenbank-Tabellen und neue zugehörige Anwendungen (jeweils Übersicht, Einzelsatz und Import) mit den Kurzworten SPI (Spiegel), SSP (Spiegelspalten) und SBE (Spiegelbereiche). Hier werden sowohl die Definitionen der bisherigen Standardspiegel (Anlagen, Beteiligungen, Kapital, Rückstellungen) als auch der bisherigen individuellen Spiegel geführt. Die bisherigen Anwendungen ISP (Texte für individuelle Spiegel), ISS (Texte für individuelle Spiegelspalten) und ISB (Spiegelbereiche) entfallen dafür.
Ein wesentlicher Unterschied zu der bisherigen Lösung besteht darin, dass diese Stammdaten mit spezifischen Attributen versehen werden können. Für Spiegel (SPI) sind dies:
Der Schlüssel einer Spiegelspalte (SSP) setzt sich aus dem Schlüssel eines Spiegels und der Spaltennummer (wie bisher maximal 50) zusammen. Für Spiegelspalten gibt es folgende Attribute:
Der Schlüssel eines Spiegelbereichs (SBE) setzt sich aus dem Schlüssel eines Spiegels und dem einstelligen Bereichskennzeichen zusammen. Für Spiegelbereiche gibt es folgende Attribute:
Diese drei neuen Tabellen werden durch das Konvertierprogramm mit den Daten der bisher bereits definierten Spiegel (sowohl individuelle als auch bisherige Standardspiegel) sowie einigen bisher fest codierten Zuordnungen belegt. Dazu werden auch die Eigenschaften der zugeordneten Buchungsschlüssel ausgewertet, so dass die Spezifikation der Spiegel sofort vollständig sein sollte, wenn die Definitionen konsistent waren.
Alle drei neuen Tabellen wurden im konzernweiten Datenaustausch ergänzt. D.h. bei verteilten Datenbanken im Konzern sollte die Pflege der Spiegeldefinitionen ausschließlich in der Zentrale erfolgen.
Änderungen bestehender Stammdaten-Tabellen
Im Buchungsschlüssel-Stamm (BSL) verweisen die Attribute "Spiegelspalte" und "Spiegelbereich" jetzt auf die neuen o.g. Tabellen (SSP bzw. SBE). Entsprechend den Definitionen der Spiegel müssen die zugeordneten Buchungsschlüssel bestimmte Regeln hinsichtlich der angegebenen Verwendungskennzeichen einhalten.
Das bisherige BSL-Kennzeichen 1 (Unterscheidung zwischen Buchungsschlüsseln für den Einzelabschluss und den Konzernabschluss, im Anlagevermögen auch noch separate Buchungsschlüssel für IC-Abgangs- und IC-Zugangskarten) wurde für die bisherigen Standardspiegel ('A', 'K', 'R') abgeschafft. Für bisherige individuelle Spiegel war dies von vornherein gar nicht unterstützt worden. Dadurch gibt es jetzt eine Reihe von weitgehend redundanten Buchungsschlüsseln, z.B. 'A01', 'A41', 'A80' und 'A91' im Anlagenspiegel, von denen nur noch einer benötigt wird. Buchungsschlüssel, die dadurch nicht mehr benötigt werden, können mit einer Gültig-bis-Periode versehen werden.
Durch diese Änderung ist auch die bisherige Angabe eines Referenz-Konzern-Buchungsschlüssels im BSL-Stamm weitgehend überflüssig, da Funktionen wie die Spiegelumbuchungen (z.B. 'SU') jetzt auf Konzernebene denselben Buchungsschlüssel wie im Einzelabschluss verwenden können. Dieses Attribut wird daher durch die Release-Konvertierung gelöscht. Ausgenommen davon sind die Referenz-Buchungsschlüssel für Beteiligungen, da diese auf einen anderen Spiegel (i.d.R. den Anlagenspiegel) verweisen. Falls Sie einen der bisherigen Konzern-Buchungsschlüssel deaktivieren wollen, prüfen Sie bitte, ob dieser noch als Referenz-Buchungsschlüssel für Beteiligungen verwendet wird. In diesem Fall ist der Referenz-Buchungsschlüssel durch einen der weiterhin gültigen Buchungsschlüssel zu ersetzen.
Im Kontenstamm (KTO) wurde das bisherige "Kontokennzeichen 2" durch das neue Attribut "Spiegel" mit Bezug auf die neue Tabelle (SPI) ersetzt. Dieses stellt weitgehend den gleichen Inhalt wie bisher dar mit folgenden Ausnahmen:
Die in verschiedenen Übersichten mögliche gleichzeitige Selektion nach zwei "Kontokennzeichen 2" war primär für die gleichzeitige Selektion nach 'K' und 'L' eingeführt worden. Da 'L' nun abgeschafft wurde, entfällt in diesen Masken auch das Eingabefeld für das zweite Kontokennzeichen 2 bzw. einen zweiten Spiegel.
Das verbleibende "Kontokennzeichen 1" wird künftig nur noch als "Kontokennzeichen" bezeichnet.
Die Erweiterungen des Kontenstamms werden auch bei der Änderungsprotokollierung berücksichtigt. Die Übersicht "Konto-Änderungen" (KTOLOG) wurde entsprechend erweitert.
Bei den Prüfregelpositionen (PRFPOS) werden ggf. angegebene Kontokennzeichen 2 in ein neues Attribut "Spiegel" mit Bezug auf die neue Tabelle (SPI) verlegt. Das Kontokennzeichen 2 = 'L' wird dabei in den Spiegel 'K' umgesetzt, so dass Prüfregeln, die sich ausschließlich auf die Konten mit dem bisherigen Kontokennzeichen 2 = 'L' bezogen, künftig nicht mehr möglich sind. Als Alternative müssen Prüfregeln mit expliziter Angabe der jeweilig Konten oder Positionen definiert werden.
Die Stammtabellen für Report-Idents (RID) und Spaltenoptionen (SPO) wurden um ein Attribut "Spiegel" mit Referenz zur neuen Tabelle "Spiegel" (SPI) erweitert. Hier trägt die Konvertierung für alle Spiegel-Reports bzw. Spiegel-Spaltenoptionen den jeweiligen Spiegel ein, der bisher im Reporttyp geführt wurde. Die bisherigen Reporttypen 'A', 'K', 'R' sowie 'S1' bis 'S9' werden dafür durch den neuen Reporttyp 'D' (Spiegel) ersetzt. Der Spiegel muss und darf nur bei Reporttyp 'D' angegeben werden.
Bei den Reportzeilenbeschreibungen (REPZEI) werden ggf. (für Kapitalfluss-Reports) angegebene Spiegelspalten in ein neues Attribut mit Bezug auf die neue Tabelle (SSP) verlegt. Für den Anwender ändert sich dadurch fast nichts.
Die Tabelle für Reportergebnisse (REPERG) wurde ebenfalls um ein Attribut "Spiegel" erweitert, das bei neu erstellten Reports anstelle des bisherigen Kontokennzeichens 2 gefüllt wird. Eine Konvertierung von Altdaten findet hier allerdings wegen des möglicherweise sehr großen Datenvolumens nicht statt. Vielmehr zeigt die Reportergebnisanzeige ggf. auch noch das Kontokennzeichen 2 an.
Vollständige Individualisierung der Buchungsschlüssel
Bisher gab es eine Unterscheidung zwischen Spiegeldefinitionen, die von IDL je Release mit den Metadaten ausgeliefert und gepflegt wurden, und Daten, die in der Obhut des Anwenders lagen (Erweiterungen an den Standardspiegeln sowie alle individuellen Spiegel). Künftig liegen sämtliche Spiegeldefinitionen in der Hand des Anwenders. Dies umfasst
Diese Daten werden künftig nicht mehr mit den Metadaten der IDL.KONSIS.FORECAST-Releases automatisch aktualisiert. Als Alternative werden Muster für Spiegeldefinitionen im Verzeichnis "LieferBatch" zur Verfügung gestellt, so wie dies in der Vergangenheit bereits für individuelle Erweiterungen der Standardspiegel oder die Einrichtung individueller Spiegel praktiziert wurde. Der Anwender kann sich entscheiden, ob er diese Muster übernimmt oder lieber eigene Definitionen erstellt.
Eine weitere Konsequenz ist, dass die Buchungsschlüssel genauso wie die neuen Tabellen für Spiegeldefinitionen (SPI, SSP, SBE) jetzt beim Datenaustausch zwischen verschiedenen Teilkonzern-Installationen komplett im Rahmen der konzernweiten Daten übertragen werden.
Eine Möglichkeit, die sich jetzt dem Anwender bietet, ist die Umstellung der bisherigen Standardspiegel auf eine eigene Nomenklatur von Buchungsschlüsseln. Dazu sind die neuen Buchungsschlüssel zunächst parallel zu den alten zu definieren, wobei die neuen Buchungsschlüssel mit einer Gültig-ab-Periode (z.B. "01.2010") versehen werden, die alten dagegen mit einer davor liegenden Gültig-bis-Periode (z.B. "12.2009"). Beim Vortrag in das nächste Jahr erfolgt dann ein Übergang auf die neuen Vortrags-Buchungsschlüssel. In den Anwendungen zur Datenerfassung werden auch nur die jeweils gültigen Buchungsschlüssel in der Auswahlmaske angeboten.
Buchungsschlüssel können nur dann gelöscht werden, wenn sie nirgends verwendet werden. Wenn die alten Buchungsschlüssel weiterhin in den Altdaten angegeben sind, empfiehlt es sich nicht, diese mit einer neuen Bedeutung zu belegen. Um trotzdem eine neue Systematik entwerfen zu können und bei nummerischen Buchungsschlüsseln zu bleiben, wurde die mögliche Länge der Buchungsschlüssel auf drei Stellen erweitert. So können alte (zweistellig) und neue (dreistellig) Buchungsschlüssel einfach auseinander gehalten werden. Bitte beachten Sie, dass der BSL-Schlüssel nicht nummerisch ist. D.h. die Buchungsschlüssel '01' und '001' z.B. sind verschieden.
Für die IDL.KONSIS.FORECAST-Anwendungsprogramme bedeutet dies, dass kein Buchungsschlüssel mehr explizit vergeben werden darf. Vielmehr müssen Buchungsschlüssel, die in automatisch erzeugten Bewegungen und Buchungen stehen, auf andere Weise eindeutig ermittelt werden. Dies geschieht i.d.R. durch die Vergabe von Verwendungskennzeichen für spezielle Buchungsschlüssel, die daher auch bei individueller Pflege der Buchungsschlüssel sorgfältig vergeben werden müssen.
Da künftig mehr Verwendungskennzeichen benötigt werden, wurde dessen Länge von einer auf drei Stellen vergrößert. Neben den bereits bisher bestehenden BSL-Verwendungskennzeichen 'D', 'E', 'F', 'K', 'L', 'M', 'N', 'Q', 'SD', 'SE', 'SF', 'SK', 'SL', SM', 'SQ', 'SV', 'U', 'V' und 'X' werden folgende neuen BSL-Verwendungskennzeichen eingeführt:
Für die BSL-Verwendungskennzeichen wurde eine neue ausführliche Dokumentation erstellt, die Sie auch über die Taste <F1> für die zugehörigen Eingabefelder in den Masken erreichen.
Weitere automatisch verwendete Buchungsschlüssel werden anhand anderer Attribute der Spiegeldefinitionen ermittelt, z.B. anhand des Verwendungskennzeichens 'UMB' der Spiegelspalte für Umbuchungen.
Lässt sich für einen bestimmten Zweck kein spezieller Buchungsschlüssel ermitteln, so wird ein Buchungsschlüssel für laufende Veränderungen verwendet. Dies ist für automatische Spiegel der Buchungsschlüssel mit dem Verwendungskennzeichen 'L', für andere Spiegel ein Buchungsschlüssel mit Verwendungskennzeichen 'N'. Wird auch so kein Buchungsschlüssel gefunden, bleibt dieser leer und muss manuell ergänzt werden.
Buchungsschlüssel mit Verwendungskennzeichen sind i.d.R. für automatische Verarbeitungen reserviert und dürfen daher in manuell erfassten Bewegungen und Buchungen nicht angegeben werden. Ausgenommen davon sind neben dem alten Verwendungskennzeichen 'N' jetzt auch Buchungsschlüssel mit den Verwendungskennzeichen 'AHK', 'Bnn' und 'KM'.
Generell unterstützt wird künftig eine Unterscheidung der vergebenen Buchungsschlüssel je nach Richtung (Soll/Haben) der Veränderung, so wie z.B. das Ergebnis bei Gewinn ('K05') mit einem anderen Buchungsschlüssel in den Kapitalspiegel eingestellt wird als ein Verlust ('K16'). Voraussetzung dafür sind zwei Buchungsschlüssel mit demselben Verwendungskennzeichen, aber unterschiedlichen Soll/Haben-Kennzeichen. Notwendig ist diese Differenzierung vor allem dann, wenn die beiden Buchungsschlüssel unterschiedlichen Spiegelspalten zugeordnet sind.
Hinweis zur Währungsumrechnung von Anlagen zu historischen Kursen
Die Umrechnungsanweisung 'FDA' (Fortgeschriebener Durchschnittskurs für Anlagenbewegungen) wird nicht mehr explizit unterstützt. Diese Umrechnungsanweisung wurde bisher automatisch für Anlagenkonten bei Angabe des Umrechnungsverfahrens 'MZB' im Währungsumrechnungs-Kopfsatz (WUM) angewandt. Alternativ war auch eine direkte Zuordnung zu einem Konto über die Konto-Umrechnungsanweisungen (KTOUAW) möglich. Bei Umrechnungsanweisung 'FDA' wurden folgende Sonderbehandlungen durchgeführt:
Diese speziell behandelten Spiegelspalten sind jetzt nicht mehr identifizierbar, so dass diese Verarbeitung so nicht mehr erfolgen kann. Alternativ kann dasselbe Ergebnis aber durch entsprechende Steuerungen in den BSL-Umrechnungsanweisungen (BSLUAW) erzielt werden:
Die Umrechnungsanweisung 'FDA' kann zwar weiterhin in den Konto-Umrechnungsanweisungen (KTOUAW) angegeben werden und wird beim Umrechnungsverfahren 'MZB' (modifizierte Zeitbezugsmethode) auch als Default-Umrechnungsanweisung für Anlagenkonten angegeben, unterscheidet sich aber nicht mehr von der Umrechnungsanweisung 'FDK' (Fortgeschriebener Durchschnittskurs).
Verlängerung des Spiegelschlüssels und Individualisierung der Spiegeldefinitionen
Wie die Buchungsschlüssel können auch die Spiegel selbst, die Spiegelbereiche und die Spiegelspalten künftig komplett anwenderspezifisch vergeben werden. Die Verarbeitung erfolgt ausschließlich anhand der Attribute der neuen Tabellen für Spiegeldefinitionen (SPI, SSP, SBE). Bei den Spiegelbereichen ist zu beachten, dass diese mit gleichen Schlüsseln für Anlagenspiegel und Beteiligungen gewählt werden müssen, wenn ein Abgleich beider Datenbestände bei der Währungsumrechnung gewünscht wird.
Der Schlüssel für Spiegel ist künftig bis zu drei Stellen lang. Bei der Konvertierung wird dies für die individuellen Spiegel ausgenutzt, deren Spiegelschlüssel (bzw. Kontokennzeichen 2 oder Reporttyp) bisher an der Oberfläche zwar als 'S1', 'S2', etc. dargestellt wurde, in der Datenbank aber als '1', '2', etc. eingetragen wurde, was insbesondere bei den Formaten für den Import zu beachten war. Jetzt wird auch 'S1', 'S2', etc. in die Datenbank geschrieben. Die Umsetzung erfolgt durch die Release-Konvertierung.
Die Verlängerung des Spiegel-Schlüssels betrifft nicht nur die Spiegeldefinitionen selbst, sondern auch alle Anwendungen, in denen der Spiegelschlüssel angegeben werden kann, u.a. bei den Buchungsschlüsseln (BSL), Konten (KTO), Report-Idents (RID), Spaltenoptionen (SPO), Reportzeilenbeschreibungen (REPZEI), Prüfregelpositionen (PRFPOS), Konto-Umrechnungsanweisungen (KTOUAW), Bewegungen und Konsolidierungsbuchungen (KONBEW) und Spiegelbewegungen (SPIBEW).
Durch die Verlängerung des Spiegelschlüssels kann es künftig eine nahezu beliebige Anzahl von Spiegeln geben. Dies hat Auswirkungen auf die Steuerung der Führung von Spiegeldaten je Datenart (FAC) und Periode (ABR), die Statusanzeige im Einzelabschluss-Monitor (EA), den differenzierten Vortrag einzelner Spiegel auf die nächste Periode (PERGES) bzw. Datenart (GESABV) sowie die Checkpoint-IDs für die Verarbeitungssteuerung (VERARB).
Die Schlüssel der Checkpoint-IDs von Spiegeln für die Verarbeitungssteuerung werden nicht mehr fest vorgegeben, sondern setzen sich generisch aus einem festen Präfix ("SPI-" für den Spiegel insgesamt, "VOR-" für die Vortragswerte) und dem Spiegelschlüssel zusammen. Die bisherigen Checkpoint-IDs (z.B. "ANLBEW", "SPIBEW9", "KAPBEWVOR") sowie deren Verwendung in Verarbeitungssteuerungssätzen werden durch die Release-Konvertierung auf die neuen Namen (z.B. "SPI-A", "SPI-S9", "VOR-K") umgesetzt. Die Checkpoint-IDs anderer Datenbestände (z.B. "KTOSAL") ändern sich nicht.
Die Anzahl der Statusspalten für Spiegel im Einzelabschluss-Monitor (EA) ist künftig ebenfalls beliebig. Die Spalten werden mit den Spaltenbezeichnungen der Spiegeldefinitionen (SPI) betextet. Die Auswahl der Datenbestände für die Selektion nach Status bestimmter Datenbestände wurde entsprechend angepasst.
Die Aufrufanwendungen "Erstellen Einzelabschluss neue Datenart" (GESABV) und "Erstellen Gesellschaftsvorträge aktuelle Periode" (PERGES) zeigen wie bisher eine Zeile für jeden Spiegel an, zum einen für eine Statusanzeige, zum anderen zum Anstoß eines einzelnen Vortrags dieses Spiegels als Zeilenaktion. Die Zeilen für die Spiegel werden künftig dynamisch über die in der Anwendung SPI definierten Spiegel ermittelt. Als Ersatz-"Menü-Id" dient dabei die jeweilige Checkpoint-Id. Spiegel ohne Vortrag werden in PERGES unterdrückt.
Zur Steuerung, welche Spiegel in welcher Periode bzw. auf welcher Datenart geführt werden, gibt es eine neue Datenbanktabelle, die über die Anwendungen "Periode/Spiegel" (ABRSPI) bzw. "Datenart/Spiegel" (FACSPI) angezeigt und gepflegt werden kann. Hier wird je Kombination Periode/Spiegel bzw. Datenart/Spiegel ein Schalter geführt, der 'X' (mit diesem Spiegel) sowie bei Perioden '0' (teilweise mit diesem Spiegel) bzw. bei Datenarten 'A' (Erstellen der Salden aus dem Spiegel) enthalten kann. Die bisherige Schalterstellung '-' (ohne diesen Spiegel) muss nicht mehr eingetragen werden, weil in diesem Fall kein Satz notwendig ist.
Diese Tabelle wird gemäß den bisherigen Einstellungen im Perioden- (ABR) bzw. Datenartenstamm (FAC) für die Spiegel durch die Release-Konvertierung belegt. Die weitere Pflege obliegt dem Anwender. Die Übersichten zeigen im Normalfall den Tabelleninhalt in Matrixform an, d.h. eine Zeile je Periode bzw. Datenart und eine Spalte je Spiegel. Es kann aber auch eine Darstellung als einfache Liste gewählt werden.
Die Übersichten "Perioden" (ABR) und "Datenarten" (FAC) zeigen die Schalter für die Führung von Spiegeln aus der neuen Tabelle (ABRSPI bzw. FACSPI) weiterhin an. Beim Kopieren (Mengenkopieren in ABR sowie Erfassen mit Vorlage) werden diese Daten auch immer mit kopiert. Ein Doppelklick mit der Maus in die Spalten für die Spiegelschalter verzweigt in die neuen Anwendungen.
Im Rahmen des Datenaustauschs (KONDAT) zwischen getrennten Teilkonzerninstallationen ist die neue Tabelle (K074) Bestandteil der konzernweiten Daten. Die Zuordnungen sollten daher nur in der Zentrale gepflegt werden.
Durch das geänderte Datenbankformat der Buchungsschlüssel und die Umsetzung der Schlüssel für individuelle Spiegel ergibt sich auch eine abweichende Berechnung von Prüfsummen. Um bereits bestehende Prüfsummen nicht abzuändern, werden diese jetzt intern mit einer Versionsnummer versehen. Eine Neuberechnung alter Prüfsummen erfolgt dadurch gemäß den alten Datenstrukturen, sofern die bisher gültigen Einschränkungen (Buchungsschlüssel zweistellig) eingehalten werden. Neue Prüfsummen werden immer gemäß den neuen Datenstrukturen berechnet.
Die Verwendung von Umsetzgruppen für Buchungsschlüssel wird dadurch übersichtlicher gestaltet, dass jetzt zwei getrennte Eingabefelder für den Spiegel und die Buchungsschlüssel-Nummer zur Verfügung gestellt werden. In der Übersicht "Umsetzgruppen-Zuordnungen" (UMSOBJ) muss daher vor Verzweigung in die Einzelsatzanwendung der Objekttyp eindeutig vorgegeben werden.
Da künftig auch die Spiegelspalten individuell definiert werden können, ist es nicht mehr möglich, allgemeingültige Standard-Spaltenoptionen für Spiegel-Reports zu definieren. Die bisherigen Standard-Spaltenoptionen (SPO) für Spiegel-Reports (z.B. '#ANLG', '#KAPK') werden einschließlich ihrer Spaltenbezeichnungen (SPA) und Formeln (FED) sowie ihrer Verwendung als Default-Spaltenoption in den Report-Kopfsätzen (REP) durch die Release-Konvertierung in individuelle Spaltenoptionen umgesetzt, indem das '#' durch ein '$' ersetzt wird. Auch diese Spaltenoptionen unterliegen künftig der Pflege durch den Anwender.
Fortschreibung der bisherigen Standardspiegel durch Batch-Dateien
Anwender, die die bisherigen Standardspiegel (Anlagen, Kapital, Rückstellungen) nicht selbst pflegen wollen, können die zugehörigen Definitionen weiterhin durch IDL pflegen lassen. IDL stellt dazu mit jedem Release Musterlösungen im Verzeichnis LieferBatch der Release-CD zur Verfügung. Die dort enthaltenen Import-Dateien für Buchungsschlüssel, Spiegeldefinitionen und (mit '$' beginnenden) Report-Spaltenoptionen können bei Bedarf importiert werden.
Dieser Schritt sollte mit jedem Release erfolgen, da die Import-Dateien aufeinander aufbauen. So werden z.B. mit diesem Release 2009.0 alle Buchungsschlüssel, die durch den Wegfall des BSL-Kennzeichens 1 überflüssig geworden sind, mit einer Gültig-bis-Periode (12.2009) versehen. In folgenden Releases werden diese Buchungsschlüssel nicht mehr enthalten sein, damit neue Anwender bereits mit einer reduzierten Anzahl von Buchungsschlüsseln arbeiten können.
Eine Beschreibung der Änderungen durch die Batch-Dateien ist im jeweiligen LieferBatch-Unterverzeichnis enthalten.
Die Kapitalkonsolidierung und die Berechnung von Fremdanteilen auf das Kapital erfolgen künftig in gemeinsamen Funktionen. Die wesentlichen Vorteile sind
Neue Konsolidierungsverarbeitungen
Diese Erweiterung erfordert eine neue Nomenklatur der Konsolidierungsverarbeitungen. Künftig beginnen die Konsolidierungsverarbeitungen für Fremdanteile mit 'F' (bisher 'KA', 'KV'):
Um die Belege und Buchungen verschiedener Konsolidierungsverarbeitungen gemeinsam selektieren zu können, enthalten die Übersichten "Konsolidierungsbelege" (KONBEL) und "Konsolidierungsbuchungen" (KONBUCH) jetzt zwei Eingabefelder für die ausgewählten Verarbeitungen. Bisher war dies durch die Eingabe 'K%' möglich. In diesem Zusammenhang wurde auch das Selektionsfeld für die Belegnummer in drei Eingabefelder für 1. Gesellschaft, 2. Gesellschaft und Konsolidierungsverarbeitung aufgeteilt, so wie dies bereits bisher in der Einzelsatzanwendung "Konsolidierungsbeleg" (KONBELE) der Fall war.
Kapitalkonsolidierung und Fremdanteile
Die Berechnung und Verbuchung der direkten Fremdanteile am Eigenkapital erfolgt jetzt im Rahmen der Kapitalkonsolidierung. Dies gilt sowohl für die maschinelle als auch für die manuelle Kapitalkonsolidierung.
Bei der Kapitalkonsolidierung einer Gesellschaft mit Fremdanteilen entsteht sowohl ein 'KK'-Beleg als auch ein 'FK'-Beleg. Liegen mehrere Beteiligungsveränderungen innerhalb der Abrechnungsperiode vor, wird für die zweite Veränderung ein 'K0'- und ein 'F0'-Beleg, für die nächste Veränderung ein 'K1'- und ein 'F1'-Beleg usw. erzeugt.
Neu ist, dass in diesem Rahmen auch Beteiligungsabgänge (Teilabgänge) verarbeitet werden, sofern die Tochtergesellschaft dadurch nicht aus dem Konzernkreis ausscheidet. In der Funktion "Endkonsolidierung" ('KS'-Belege) werden nur noch Abgänge aus dem Konzernkreis behandelt, die durch die Angabe eines Abgangsdatums in der Beziehung "Konzernkreis/Tk-Gesellschaft" (KTKGESE) gekennzeichnet sind. Dementsprechend ist jetzt auch der Status 'KS' für die Endkonsolidierung im Konzernkreis-Monitor (KTKGES) zu verstehen. Bei der Endkonsolidierung werden auch die neuen Fremdanteilsbelege entsprechend berücksichtigt.
Wie bereits oben erwähnt, werden bei der maschinellen Kapitalkonsolidierung auch die direkten Fremdanteile am Eigenkapital ermittelt und gebucht. Bei mehreren Beteiligungsveränderungen wie z.B. sukzessivem Erwerb wird auch die Entwicklung der Fremdanteile durch verschiedene Belege dargestellt. In Summe der Belege werden alle Eigenkapitalkonten komplett eliminiert.
Die manuelleKapitalkonsolidierung einschl. der direkten Fremdanteile erfolgt in einer neuen Erfassungsanwendung "Formularerfassung Erstkonsolidierung" (I-ERSTKON), die aus der Anwendung "Konzernkreise + Konzern-Monitor" (KTKGES) heraus im Submenü "Kapitalkonsolidierung" für eine Tochtergesellschaft aufgerufen werden kann.
Die Erfassungsmaske enthält einen Block je Beteiligungsveränderung im betrachteten Zeitraum. Jeder Block enthält (mindestens) eine Zeile für die Beteiligungsveränderung sowie je Kapitalkonto und -Buchungsschlüssel, für den im Einzelabschluss ein Kontensaldo bzw. eine Kapitalbewegung vorhanden ist. Zusätzliche Zeilen ermöglichen die Erfassung von Buchungen für Konten oder Buchungsschlüssel, die im Einzelabschluss nicht angegeben waren. Dazu werden folgende Wertspalten ausgegeben:
Der Jahresüberschuss wird nur in den Spalten für die Eigenanteile berücksichtigt, da es hier nur darum geht, das Ergebnis aus dem Zeitraum vor Beginn der Konzernzugehörigkeit zu eliminieren, während das Ergebnis während der Konzernzugehörigkeit dem Konzern zusteht. Die Fremdanteile am Ergebnis sind dagegen nicht nur bei Beteiligungsänderungen, sondern in jeder Periode zu berücksichtigen und werden daher in der Funktion "Buchen Fortschreibung Fremdanteile" (s.u.) verarbeitet.
Während in der Horizontalen der Restwert je Kapitalkonto bestimmt wird, wird in der Vertikalen die Differenz aus den Eliminierungsbuchungen auf die Beteiligung und das Eigenkapital gebildet und als Unterschiedsbetrag bzw. als Anteile im Fremdbesitz dargestellt. Um diese Berechnungen nachvollziehbar zu machen, werden hier generell alle Sollwerte als positive Werte und alle Habenwerte als negative Werte dargestellt und sind auch so einzugeben.
Um die angezeigten und erfassten Werte zu speichern, muss abschließend einmalig die Schaltfläche <Speichern> betätigt werden.
Bei Arbeit mit Geschäftsbereichen gibt es je Kombination der Geschäftsbereiche von Mutter und Tochter einen eigenen Erfassungsblock. Die Werte werden wie bisher in Buchungssätzen mit den Nummern '01', '11', '21' usw. geführt.
Im Rahmen der maschinellen bzw. manuellen Kapitalkonsolidierung erfolgt auch die Eliminierung von Buchungen aus untergeordneten Teilkonzernen, falls dort abweichende Beteiligungsverhältnisse vorliegen (z.B. Fremdanteil im Teilkonzern wird zu Eigenanteil im Weltkonzern). Diese Buchungen erfolgen wie bisher in Buchungssatz Nummer '10'.
Diese Anwendung kommt auch für die Erstkonsolidierung von Equity-Gesellschaften zum Einsatz. Allerdings werden dort keine Fremdanteile gebucht. Da kein verwertbarer Einzelabschluss vorliegt, müssen die zu bebuchenden Kapitalkonten und -buchungsschlüssel alle manuell eingegeben werden.
Fortschreibung Fremdanteile
Die Funktion zum Berechnen und Buchen der Fremdanteile wird jetzt unter dem Titel "Buchen Fortschreibung Fremdanteile" geführt. Diese enthält i.W. die Funktionen der bisherigen Anwendung "Buchen Fremdanteile" mit Ausnahme der Eliminierung des Eigenkapitals im Fall von Beteiligungsänderungen, u.a.
Im Gegensatz zur Kapitalkonsolidierung ist diese Funktion in jeder Periode und nicht nur bei Veränderung der Beteiligungsverhältnisse aufzurufen. Es werden Buchungen für direkte und indirekte Fremdanteile erstellt, wobei unterschiedliche Belege (eine bzw. zwei Gesellschaften in der Belegnummer) erzeugt werden. Neu ist, dass jetzt alle indirekten Fremdanteile (also z.B. auch am Ergebnis) ggf. auf mehrere Muttergesellschaften aufgeteilt und ausgewiesen werden.
Formatierung von Reportspalten
Es ist jetzt möglich, die Formatierung von Reportspalten vorzugeben. Für Reportspalten sind Schriftschnitt (fett, kursiv), Schriftgrad (Größe), Vordergrundfarbe, Hintergrundfarbe sowie eine Trennlinie zwischen den Spalten (d. h. vor jeder Wertspalte) individuell einstellbar.
Des Weiteren können jetzt Balkengrafiken in einer Reportspalte dargestellt werden. Die Grafik zeigt je Zeile einen dem Wert entsprechenden Balken in grüner (bei positiven Werten) oder roter (bei negativen Werten) Farbe an. Über die Zusatzangabe "Wertanzeige" kann gesteuert werden, ob der Wert neben dem Balken ausgegeben wird oder nicht. Diese Ausgabe kann als kompletter Wert oder gerundet auf ganze Zahlen, 1.000 Währungseinheiten oder 1.000.000 Währungseinheiten erfolgen. Für den Druck kann zusätzlich eine minimale Druckbreite dieser Spalte (in mm) angegeben werden, wenn die Standardeinstellung zu klein ist.
Die Definition der Attribute erfolgt dabei in der Anwendung "Report-Spaltenbezeichnungen" (SPA). Die Einzelsatzanwendung "Report-Spaltenbezeichnung" (SPAE) wurde um entsprechende Eingabefelder erweitert, wobei die Vorder- und die Hintergrundfarbe über einen speziellen Farb-Dialog ausgewählt werden.
Auch das Importformat für die Spaltenbezeichnungen wurde um entsprechende Attribute erweitert. Vorder- und Hintergrundfarbe müssen hier allerdings als nummerische RGB-Werte angegeben werden. Dasselbe gilt für den Export.
Die Reportspalten, die von IDL mit jedem Release als Metadaten ausgeliefert werden (Spaltenoption beginnend mit '#'), nutzen diese Formatierungsmöglichkeiten i.d.R. nicht. Wollen Sie eine solche Spaltenoption mit Formatierungen versehen, müssen Sie die ausgelieferte Spaltenoption (SPO) zunächst (einschl. der Spaltenbezeichnungen (SPA) und Formeln (FED)) auf eine individuelle Spaltenoption (beginnend ohne '#') kopieren. Dann können die Spaltenbezeichnungen dieser individuellen Spaltenoption mit den Formatierungsangaben belegt werden.
Ausnahmen sind die Spaltenoptionen mit Spalten zur Darstellung relativer Abweichungen: #ALTD, #BUCD, #KOND, #KTKD, #NEUD und #SUMD. Zu diesen Spaltenoptionen gibt es jetzt eine weitere Spaltenoption mit Suffix 'G' (z.B. #ALTDG), in der die in der originalen Spaltenoption errechnete relative Abweichung in Prozent als Balkendiagramm ausgegeben wird.
Hinweis: Bei gleichzeitiger Formatierung der Reportzeile (möglich seit Release 2008.1) und der Reportspalte werden beide Formatierungsangaben nach Möglichkeit in der Zelle kombiniert. Bei widersprüchlichen Angaben hat die Formatierung der Spalte Vorrang.
Formatierung der Druckausgabe
Die Texte im Kopfteil von ausgedruckten Reports lassen sich künftig flexibel gestalten, indem folgende Parameter in der Bezeichnung der Report-Id oder der Report-Version angegeben werden:
Ist nur dieser Parameter angegeben, wird der jeweilige Schlüssel anstelle des Parameters ausgegeben. Durch Anhängen eines Formatierungssuffixes an den Parameter kann aber auch eine Bezeichnung des Objektes ausgegeben werden (z.B. '{GES!L}'). Hierbei steht:
Die Abrechnungsperiode (ABR) kann durch Angabe einer Formatierung beliebig gestaltet werden. Diese kann z.B. so aussehen: '{ABR!yyyy-MM-uu}'. Wird keine Formatierung angegeben, erfolgt die Ausgabe so, wie es für die aktuelle landesspezifische Einstellung üblich ist. Die Formatierungszeichen haben folgende Bedeutung:
Der Report-Kopfsatz wurde um die folgenden Attribute erweitert, die die Druckausgabe steuern, sofern im Druckdialog keine abweichenden Angaben erfolgen. In den Übersichten (REP, REPK) werden diese Attribute angezeigt und in der Einzelsatzanwendung (REPE) können sie eingegeben werden.
Im Fußteil werden die Prüfsummen ausgegeben, wenn der Selektionsbereich nicht ausgedruckt wird.
Eine neue Funktionalität ermöglicht die Freigabe von Konsolidierungsbelegen und damit eine Sperre der enthaltenen Konsolidierungsbuchungen gegen weitere Änderungen nach dem Vier-Augen-Prinzip. D.h. der Benutzer, der einen Beleg sperrt, darf nicht gleichzeitig als Bearbeiter einer enthaltenen Konsolidierungsbuchung eingetragen sein.
Die Freigabe geschieht durch eine neue Aktion, die aus der Übersicht "Konsolidierungsbelege" (KONBEL) oder der Einzelsatzanwendung "Konsolidierungsbeleg" (KONBELE) heraus aufgerufen werden kann. Durch diese Aktion wird ein Freigabestatus im Belegkopf gesetzt und gleichzeitig der jeweilige Benutzer und der Zeitpunkt der Freigabe eingetragen. Alle Informationen werden danach in KONBEL und KONBELE angezeigt. Die Übersicht KONBEL ermöglicht zudem eine Selektion nach dem Freigabe-Status.
Eine weitere neue Aktion "Belegfreigabe aufheben" ermöglicht das Aufheben des Freigabe-Status. Der Status des Belegs wird auf "Freigabe aufgehoben" gesetzt. Gleichzeitig werden Freigabe-Benutzer und Freigabe-Zeitpunkt mit den aktuellen Werten überschrieben. Diese Aktion setzt den vorherigen Freigabe-Status "freigegeben" voraus.
Der Freigabe-Status wird von allen Anwendungen, die Konsolidierungsbelege oder -buchungen einfügen oder ändern, geprüft. Freigegebene Belege dürfen auch nicht wieder gelöscht werden, wenn sie noch Konsolidierungsbuchungen enthalten. Ausnahmen sind der Teilkonzern-Datenaustausch (KONDAT), die Währungsumrechnung von Konsolidierungsbuchungen in die Parallelwährung und das Umspeichern von Währungsdaten (WKZEXCH).
Beide neuen Aktionen unterliegen der üblichen Menüberechtigung. Standardmäßig erhalten die Benutzergruppen IDLADMIN und IDLKON bzw. IDLWINAD und IDLWIN diese Berechtigung.
Diese neue Funktionalität ist gekoppelt an die Änderungsprotokollierung von Konsolidierungsbuchungen, damit z.B. nachvollzogen werden kann, welche Änderungen nach dem Aufheben der Freigabe eines Beleges noch durchgeführt wurden. Ohne Aktivierung dieser Änderungsprotokollierung sind die neuen Aktionen nicht freigeschaltet und die zusätzlichen Attribute werden nicht angezeigt. Für einen Benutzer ohne aktivierte Änderungsprotokollierung für Konsolidierungsbuchungen, zumal wenn ohne die erforderliche Lizenz für Änderungsprotokollierung, ändert sich also nichts.
Die Änderungsprotokollierung für Konsolidierungsbuchungen wird wie andere Änderungsprotokollierungen über die Anwendung "Steuerung Stammdatenprotokollierung" (LOG) aktiviert, auch wenn es sich bei Konsolidierungsbuchungen nicht um Stammdaten handelt. Das Änderungsprotokoll kann über eine neue Übersicht "Konsolidierungsbuchungen Änderungen" (KONBUCHLOG) eingesehen werden. Diese Übersicht ermöglicht Selektionen nach den wesentlichen Attributen von Konsolidierungsbuchungen sowie spezielle Abfragen nach Zustand zu einem bestimmten Zeitpunkt oder Änderungen innerhalb eines bestimmten Zeitintervalls.
Eine weitere Änderung in diesem Zusammenhang ist, dass eine Sperre für eine Periode insgesamt (Aktion "Sperren Periode" in der Übersicht "Perioden" (ABR)) nur dann erfolgen darf, wenn alle Konsolidierungsbelege dieser Periode freigegeben sind, sofern überhaupt mit Belegfreigabe gearbeitet wird, was wiederum über die aktivierte Änderungsprotokollierung der Tabelle K049 (Konsolidierungsbuchungen) ermittelt werden kann.
Bei der Erstellung von Konzernreports wird eine Meldung ausgegeben, wenn sie gleichzeitig Konsolidierungsbuchungen von freigegebenen und von nicht freigegebenen Belegen enthalten.
An der Planungskomponente IDL.FORECAST gab es eine Vielzahl von Erweiterungen, die im Kapitel IDL FORECAST im Detail beschrieben sind.
Das Startbild, das vor dem Erscheinen des Anmeldedialogs angezeigt wird, enthält jetzt den Text IDL.KONSIS.FORECAST anstelle von IDL.KONSIS.FORECAST, da diese Anmeldung inzwischen zum Aufruf verschiedener IDL-Anwendungen genutzt wird.
Das Anmeldefenster für IDL.KONSIS.FORECAST enthält jetzt eine Drop-Down-Box zur Auswahl der Datenbank. Diese enthält die Namen aller Datenbanken, bei denen sich der Benutzer nach Installation dieses Releases erfolgreich anmelden konnte. Die zuletzt benutzte Datenbank wird dabei wie bisher voreingestellt, so dass sich für Benutzer, die nur mit einer Datenbank arbeiten, nichts ändert.
Beim Beenden von IDL.KONSIS.FORECAST werden die Positionen von Ressourcenbaum und Schnellstarter (sichtbar oder im Rand) in der ini-Datei gespeichert, so dass die Anzeige beim nächsten Neustart exakt in dieser Form erfolgt. Bisher waren diese Elemente nach dem Neustart immer im Rand.
Einige Einstellungen der Benutzeroberfläche konnten bisher nur über einen Schieberegler konfiguriert werden, dessen Auswirkungen aber schwer nachvollziehbar waren. Der Schieberegler wurde daher jetzt durch eine eigene Seite "Grafik" im Optionsdialog ersetzt. Dort können jetzt die verschiedenen Merkmale separat ein- oder ausgestellt werden. Schaltet man alle Merkmale ab, so bleibt die klassische frühere Oberfläche übrig.
Auf der Seite "Farben" des Optionsdialogs können jetzt auch die Hintergrundfarben für die Perioden der verschiedenen Wertarten im Erfassungsformular von IDL.FORECAST (Ist, Plan, Forecast) eingestellt werden.
Die Seite "Grafik" des Optionsdialogs enthält darüberhinaus eine weitere Checkbox "Registerkarten". Die Markierung dieser Checkbox setzt die Markierung der Checkbox "Verschiebbare Oberfläche" voraus.
Ist die Checkbox "Registerkarten" markiert, erscheinen am unteren Rand des Fensters Registerlaschen: Eine mit dem Kurzwort der gerade aktiven Anwendung und eine zweite mit einem Symbol für eine neue Registerkarte. Ein Mausklick auf diese Lasche rückt die zweite Registerkarte (zunächst ohne gestartete Anwendung) in den Vordergrund. Über Kurzworteingabe oder Auswahl aus dem Ressourcenbaum oder dem Schnellstarter kann hier eine Anwendung gestartet werden. Gleichzeitig erscheint im Fuß eine weitere Registerlasche mit dem Symbol für eine neue Registerkarte.
Sind jetzt Anwendungen in mehreren Registerkarten gestartet, so kann der Benutzer dazwischen hin und her wechseln. Das Öffnen einer zweiten IDL.KONSIS.FORECAST-Anwendung ist damit in vielen Fällen nicht mehr erforderlich.
Folgende Einschränkungen sind zu beachten: Ein Wechsel zwischen den Registerkarten ist nicht möglich, wenn in der aktiven Karte eine Verarbeitung gestartet wurde, die noch nicht beendet wurde. Diese Technik kann also nicht dazu benutzt werden, während lang laufender Verarbeitungen (z.B. Erstellung eines Konzernreports) in einer anderen Anwendung weiter zu arbeiten.
Beim Kopieren von Daten mit Hilfe von Einzelsatzanwendungen (Erfassen mit Vorlage) wurden bisher automatisch immer alle zugehörigen Bezeichnungen und alle Hilfetexte in allen Sprachen mit kopiert. Während man die Bezeichnungen in der aktuell selektierten Sprache sieht und an den neuen Sachverhalt anpasst, sind Bezeichnungen in anderen Sprachen wie auch Hilfetexte nicht sichtbar, so dass leicht übersehen wird, dass auch diese anzupassen sind.
Beim Kopieren von Daten in Einzelsatzanwendungen wird daher jetzt geprüft, ob es mit zu kopierende Bezeichnungen in anderen Sprachen oder Hilfetexte gibt. Ist dies der Fall wird der Benutzer mit einer Warnungsmeldung befragt, ob er diese Daten mit kopiert haben will oder nicht. Bei <OK> werden diese Daten wie bisher mit kopiert. Bei <Abbrechen> dagegen werden nur die in der Maske sichtbaren Daten gespeichert, während anderssprachige Bezeichnungen und Hilfetexte nicht übernommen werden.
Das Konvertierprogramm für dieses Release nimmt folgende Umsetzungen in der Datenbank vor:
Zusätzlich werden auch die Konvertierungen aus dem Zwischenrelease 2008.1 durchgeführt, sofern dieses Zwischenrelease nicht installiert wurde.
Wegen der umfangreichen Änderungen in diesem Release kann das Konvertierprogramm bei größeren Datenbanken einen längeren Zeitraum in Anspruch nehmen.
Folgende Menü-IDs sind in diesem Release neu. Falls vollständig gepflegte kundenspezifische Berechtigungsgruppen verwendet werden, müssen für diese Menüpunkte ggf. Berechtigungen (BENMEN) gepflegt werden. Als Vorlage können i.d.R. die Menüberechtigungen der Benutzergruppe IDLKON bzw. IDLWIN dienen.
Außerdem ist zu beachten, dass zum Löschen von Prüfregelergebnissen (s.u.) die Löschberechtigung für die Menü-IDs PRFERG bzw. PRFERGK zusätzlich benötigt wird.
Die Menüpunkte 'EABVORxxx', 'LOEVORxxx' und 'PERGESxxx' ('xxx' = 'ANL', 'BET', 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') sowie 'REPERGGxxx' und 'REPERGKxxx' ('xxx' = 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') wurden deaktiviert und haben keine Bedeutung mehr. Bitte löschen Sie alle individuellen Berechtigungen für diese Menüpunkte, damit diese Menüpunkte selbst bei der Installation des Folgereleases 2009.1 oder 2010.0 gelöscht werden können. Erhalten bleibt in diesen Fällen nur jeweils ein Menüpunkte mit 'xxx' = 'SPI'.
Als Alternative zur vollständigen Pflege der Berechtigungen für alle Menüpunkte wird das Verfahren zur vereinfachten Pflege von kundenspezifischen Berechtigungsgruppen empfohlen. Für diese Funktionalität kann für eine Menü-Berechtigung (BENMENE) auch die neue Berechtigungsstufe '0' angegeben werden. Diese besagt, dass eine für die Referenz-Benutzergruppe verfügbare Berechtigung für die angegebene Benutzergruppe nicht gegeben sein soll.
Von der Übersicht für Vorbelegung und Berechtigungsschutz der Benutzer (VORADMIN) können Sie jetzt per Aktionsmenü oder Objektmenü in die Übersicht für Objektberechtigungen (BENOBJ) bzw. Periodenberechtigungen (BENABR) verzweigen. Dabei ist jeweils die dem Benutzer zugeordnete Berechtigungsgruppe voreingestellt.
Die Protokollierung von Datenänderungen (kostenpflichtiger Zusatzbaustein) ist jetzt auch für die Tabelle K049 für Konsolidierungsbuchungen möglich. Diese Protokollierung ist Voraussetzung für und eng verbunden mit der Freigabe von Konsolidierungsbelegen nach dem Vier-Augen-Prinzip (s.o.).
Zur Aktivierung der Protokollierung geben Sie in der Anwendung "Steuerung Stammdatenprotokollierung" (LOG) den Tabellennamen K049 ein und wählen die Aktion <Stammdatenprotokollierung aktivieren>. Durch diese Aktion wird der aktuelle Zustand der angegebenen Tabelle in die Protokolltabelle kopiert. Bei der Aktivierung sollten keine anderen Benutzer mit der Datenbank verbunden sein. Anschließend werden alle Änderungen an dieser Tabelle in der Protokolltabelle festgehalten.
Zur Ansicht und Analyse der protokollierten Daten gibt es die neue Übersichtsfunktion "Konsolidierungsbuchungen Änderungen" (KONBUCHLOG). Diese Übersicht zeigt die Protokollsätze an, ermöglicht eine Selektion nach den wesentlichen Attributen (ähnlich der Übersicht KONBUCH) und zusätzlich Abfragen nach Art (Einfügen, Ändern, Löschen) und Zeitpunkt der Änderung. So können alle Änderungen ab einem bestimmten Zeitpunkt selektiert werden oder auch der Zustand der Originaltabelle zu einem bestimmten Zeitpunkt.
Von der Übersicht für Menüpunkte (MEN) können Sie jetzt per Aktionsmenü oder Objektmenü in die Übersicht für Menüberechtigungen (BENMEN) verzweigen. Dabei ist jeweils der markierte Menüpunkt voreingestellt.
Die Stammtabelle für Positionen wurde um eine Spalte für ein XBRL-Concept (Schlüssel für eine Angabe in einem XBRL-Dokument) erweitert. Diese Angabe wird für den XBRL-Export ausgewertet. Das neue Attribut wird in der Übersicht (POS) angezeigt und ist in der Einzelsatzanwendung (POSE) eingebbar.
Das Kontokennzeichen 2 wurde im Kontenstamm durch das neue Attribut "Spiegel" mit Verweis auf die Tabelle SPI ersetzt (s.o.). Wie diese Referenztabelle ist das Attribut dreistellig. Ausnahmen:
Die im Kontenstamm und anderen Übersichten mögliche gleichzeitige Selektion nach zwei "Kontokennzeichen 2" war primär für die gleichzeitige Selektion nach 'K' und 'L' eingeführt worden. Da 'L' nun abgeschafft wurde, entfällt auch das Eingabefeld für das zweite Kontokennzeichen 2 bzw. einen zweiten Spiegel.
Das bisherige "Kontkokennzeichen 1" wird jetzt nur noch "Kontokennzeichen" genannt.
Die Erweiterung um die neuen Attribute "Spiegel" und "Umbuchung beim Vortrag" wurde auch für die Änderungsprotokollierung und die Übersicht "Konto-Änderungen" (KTOLOG) durchgeführt.
Einem Ergebnisvortragskonto aus dem Gesellschaftskontenplan (Kontokennzeichen 'W') darf jetzt ein Konto mit dem Kontokennzeichen 'X' als zugeordnetes Konzernkonto zugeordnet werden.
Mit dem neuen Kontokennzeichen 'F' kann das Konto "JÜ-Anteil fremder Gesellschafter" gekennzeichnet werden. Dies ermöglicht abweichende Positionszuordnungen für den Report (s.u.).
Zur Pflege der Positions/Konten-Zuordnungen wurde eine neue Anwendung (Kurzwort Z-POSKTO) entwickelt, die die Pflege der Zuordnungen durch eine Drag-and-Drop-Technik ermöglicht. Diese Anwendung ist ein Muster für weitere Zuordnungsanwendungen, die in nächster Zeit entstehen sollen.
Für die Pflege der Positions/Konten-Zuordnungen sind die Selektionsparameter Positionsplan und Kontenplan eindeutig vorzugeben. Eine Einschränkung nach Positionsnummern oder Kontonummern ist nicht vorgesehen. Die Einschränkung auf bestimmte Bilanz/GuV-Kennzeichen ist möglich. Eine Einschränkung auf in einer Periode gültige Positionen und Konten ist zwar vorgesehen, wird im Moment aber noch nicht unterstützt. Über das optionale Eingabefeld "Sprache" kann die Anzeige der Positions- und Kontobezeichnungen in einer bestimmten Sprache forciert werden.
Nach Betätigen der Aktion <Anzeigen> werden im unteren Teil des Fensters zwei Tabellen angezeigt. Auf der linken Seite wird eine vollständige Liste der Positionen des gewählten Positionsplans angezeigt. Sofern Kontenzuordnungen bereits vorhanden sind, werden die Konten in Baumstruktur als Zweige unter den Positionen ausgegeben. Auf der rechten Seite wird eine Liste der noch nicht zugeordneten Konten ausgegeben. Dadurch ermöglicht diese Anwendung auch eine einfache Kontrolle der vollständigen Zuordnung der Konten.
Eine Zuordnung erfolgt, indem der Benutzer in der rechten Tabelle ein oder mehrere Konten markiert, dann mit mit der linken Maustaste "greift" und bei gedrückter Maustaste auf eine Position in der linken Tabelle fallen lässt, indem er die Maustaste loslässt. Dabei wird die Zulässigkeit der Zuordnung gemäß Bilanz/GuV-Kennzeichen von Position und Konto geprüft. Ist die Zuordnung nicht erlaubt, kann das Konto nicht fallengelassen werden. Dies wird beim Bewegen der Maus durch die Anzeige eines Halteverbots-Symbols visualisiert.
Zum Löschen einer Zuordnung wird das Konto in der linken Baumtabelle markiert. Über das Objektmenü (rechte Maustaste) kann dann die Aktion "Löschen" ausgewählt werden. Die Zuordnung wird aus der linken Baumtabelle entfernt und das Konto wird wieder in die rechte Tabelle noch nicht zugeordneter Konten aufgenommen.
Mehrfach-Zuordnungen eines Kontos sind möglich, wenn es sich bei den zusätzlichen Positionen um Davon-Positionen handelt. Dann kann ein Konto auch innerhalb der Baumstruktur gegriffen und auf eine weitere Position gezogen werden. Die Zeile wird dabei kopiert. Wird das Konto dabei allerdings von einer echten Position auf eine andere echte Position gezogen, so wird es verschoben und nicht kopiert.
Mehrfach-Zuordnungen sind auch bezüglich der Soll/Haben-Steuerung möglich. Dazu kann bei einem (ohne Einschränkung nach Soll/Haben-Kennzeichen) zugeordneten Konto über eine Drop-Down-Box in der entsprechenden Zelle das Soll/Haben-Kennzeichen auf 'S' oder 'H' gesetzt werden. Dabei erhalten auch alle zusätzlichen Zuordnungen zu Davon-Positionen automatisch dieselbe Einschränkung auf dieses Soll/Haben-Kennzeichen. Außerdem wird das Konto wieder in der rechten Tabelle der noch nicht zugeordneten Konten als zuordenbar ergänzt, allerdings beschränkt auf die Zuordnung mit dem jeweils entgegen gesetzten Soll/Haben-Kennzeichen. Dadurch ermöglicht diese Anwendung auch eine einfache Kontrolle der vollständigen Zuordnung für die Soll/Haben-Steuerung. Eine Mischung aus Zuordnung mit und ohne Soll/Haben-Zuordnung wird nicht unterstützt.
Bisher noch nicht unterstützt werden Mehrfach-Zuordnungen eines Kontos gemäß Differenzierung nach Controlling-Kennzeichen für den UKV-Report. Dies wird in einem späteren Release ergänzt werden.
Die vorgenommenen Änderungen werden (wie in der Formularerfassung) nicht sofort in der Datenbank gespeichert, sondern erst durch explizite Betätigung der Schaltfläche <Speichern> bzw. der entsprechenden Aktion aus dem Menü. Beim Beenden der Anwendung oder bei Wechsel der Schlüssel ohne vorheriges Speichern erscheint eine Kontrollabfrage, ob die erfassten Änderungen erst gespeichert werden sollen.
Die Zuordnung ist i.d.R. nur zwischen Konten und Positionen mit verwandten Bilanz/GuV-Kennzeichen möglich, z.B. ist '1' (Aktiva) mit '2' (Passiva) zugelassen, '1' mit '3' (Erträge) dagegen nicht. Eine Ausnahme stellt das Ergebniskonto (Kontokennzeichen 'E') dar, das als Passivkonto ('2') einer Ertragsposition ('3') zugeordnet werden darf. Eine weitere gleichartige Ausnahme ist jetzt für das Konto "JÜ-Anteil fremder Gesellschafter" möglich, das durch das neue Kontokennzeichen 'F' gekennzeichnet werden kann.
In der Übersicht "Controllingobjekte" (CNT) bei der Aktion "Mengenändern" wurde die Möglichkeit zur Änderung des Aggregationskennzeichens ergänzt.
In der Übersicht "Controllingobjekt-Hierarchiezuordnungen" (CNTCNT) wurde die Aktion "Mengenkopieren" ergänzt, um eine definierte Hierarchie von einem Controllingplan auf einen anderen zu kopieren.
Zur Definition von Spiegeln (SPI), Spiegelspalten (SSP) und Spiegelbereichen (SBE) gibt es jetzt eigene Datenbanktabellen und neue Anwendungen für Übersicht, Einzelsatz und Import. Die neuen Tabellen sind oben im Detail beschrieben. Geändert werden dabei insbesondere folgende Sachverhalte:
Die neuen Tabellen werden durch die Release-Konvertierung gemäß der bisherigen Programmlogik und den Buchungsschlüssel- und Spiegeldefinitionen belegt. Die bisherigen Anwendungen für individuelle Spiegeldefinitionen und -erweiterungen (ISP, ISS, ISB) entfallen.
Buchungsschlüssel können künftig mehr Stellen umfassen: bis zu drei Stellen für den Spiegel und bis zu drei weiteren Stellen für die Buchungsschlüssel-Nummer. Die bestehenden Buchungsschlüssel werden durch die Release-Konvertierung ohne inhaltliche Änderung auf das neue Format umgesetzt.
Erweiterte Formate gelten auch für die Attribute Spiegelspalte (jetzt mit Verweis auf die neue Tabelle SSP), Spiegelbereiche (jetzt mit Verweis auf die neue Tabelle SBE) und Verwendungskennzeichen (jetzt dreistellig). Auch dies wird durch die Release-Konvertierung eingestellt.
Wie die Spiegeldefinitionen werden auch die Buchungsschlüssel künftig komplett durch den Anwender gepflegt. Bei Releasewechsel erfolgt keine Änderung mehr durch die ausgelieferten Metadaten. Die Anwendungsprogramme dürfen aus diesem Grund keine fest codierten Buchungsschlüssel mehr enthalten. Daher werden jetzt mehr Buchungsschlüssel als bisher mit Verwendungskennzeichen versehen. Es gibt auch einige neue Verwendungskennzeichen (s.o.).
Das BSL-Kennzeichen 1 (vor allem zur Unterscheidung von Buchungsschlüsseln für Einzel- bzw. Konzernabschluss) ist entfallen. D.h. künftig können alle Buchungsschlüssel sowohl im Einzel- als auch im Konzernabschluss benutzt werden. Der Referenz-(Konzern-)Buchungsschlüssel ist daher nur noch für Anteilsbesitz-Buchungsschlüssel erforderlich, die auf einen anderen Spiegel (i.d.R. Anlagenspiegel) verweisen.
Durch Setzen des Gültig-bis-Datums für nicht mehr benötigte Buchungsschlüssel hat der Anwender jetzt die Möglichkeit, die Anzahl der verfügbaren Buchungsschlüssel zu reduzieren. Durch Definition neuer (z.B. dreistelliger) Buchungsschlüssel kann ein Spiegel auch auf eine neue Nomenklatur umgestellt werden.
Die Übersicht "Buchungsschlüssel" (BSL) zeigt jetzt zusätzlich das Reservierungskennzeichen an. Dieses Kennzeichen dient der Prüfung, welche Buchungsschlüssel in einer manuell erfassten Buchung oder Bewegung angegeben werden dürfen oder in den Auswahllisten angeboten werden. Das Reservierungskennzeichen kann nicht explizit gesetzt werden, sondern wird automatisch für bestimmte Verwendungskennzeichen gesetzt. Dies war auch bisher schon der Fall, allerdings können gewisse Verhaltensweisen besser nachvollzogen werden, wenn man sehen kann, ob das Reservierungskennzeichen gesetzt ist.
Die Stammtabelle für Konzerne/Teilkonzerne wurde um eine Spalte für eine URL (Internet-Adresse der Homepage) erweitert. Diese Angabe wird ggf. für den XBRL-Export ausgewertet. Das neue Attribut wird in der Übersicht (KTK) angezeigt und ist in der Einzelsatzanwendung (KTKE) eingebbar ("http://www....").
Die Stammtabelle für Gesellschaften wurde um eine Spalte für eine URL (Internet-Adresse der Homepage) erweitert. Diese Angabe wird ggf. für den XBRL-Export ausgewertet. Das neue Attribut wird in der Übersicht (GES) angezeigt und ist in der Einzelsatzanwendung (GESE) eingebbar ("http://www....").
In der Übersicht "Perioden" (ABR) wurde die Aktion "Mengenkopieren" ergänzt. Hierüber ist es möglich die markierten Zeilen (Perioden) auf ein neues Jahr zu kopieren. So ist es z.B. möglich, alle 12 Monate eines neuen Geschäftsjahres in einem Rutsch anzulegen. Sämtliche Schalterstellungen (z.B. für Aufrissdaten) werden dabei aus dem gleichen Monat des Quelljahres übernommen. Jahreszahlen in den Bezeichnungen werden automatisch in die angegebene Ziel-Jahreszahl umgesetzt. Bereits vorhandene Perioden werden nicht überschrieben.
Da die Anzahl der Spiegel künftig beliebig ist (s.o.), können die Schalter zur Pflege der Spiegel je Periode nicht mehr im Periodenstamm (ABRE) gepflegt werden. Vielmehr gibt es dafür jetzt eine eigene Anwendung "Perioden/Spiegel" (ABRSPI).
Wenn die Änderungsprotokollierung von Konsolidierungsbuchungen und damit das Vier-Augen-Prinzip für die Freigabe von Konsolidierungsbelegen (s.o.) aktiviert wurde, kann eine Periode nur noch dann gesperrt werden (Aktion "Sperren Periode"), wenn alle Konsolidierungsbelege dieser Periode freigegeben sind.
Da die Anzahl der Spiegel künftig beliebig ist (s.o.), können die Schalter zur Pflege der Spiegel je Datenart nicht mehr im Datenartenstamm (FACE) gepflegt werden. Vielmehr gibt es dafür jetzt eine eigene Anwendung "Datenarten/Spiegel" (FACSPI).
Die Übersicht für (mehrsprachige) Bezeichnungen und Hilfetexte von Stammdaten (TXT) wurde um eine Selektion nach "ab Änderungsdatum" erweitert. Bei der Sortieroption 'T' (mit Hilfetexten) wirkt diese Selektion auf die letzte Änderung des Hilfetextes, ansonsten auf die letzte Änderung der Bezeichnungen.
Eine neue Sortieroption 'E' ermöglicht die Sortierung der selektierten Daten nach externem Schlüssel (analog zu Langtext, Kurztext und Spaltenüberschrift).
Bei Doppelklick auf die Spalte mit dem Typ des Hilfetextes öffnet sich der Hilfetext-Editor für diesen Hilfetext. Dies gilt ggf. auch für die Anzeige einer zweiten Sprache.
Der Export dieser Übersicht wurde an das Format der neuen Importanwendung für Bezeichnungen angepasst. Ausnahme ist auch hier die Sortieroption 'T', bei der der Export im Import/Export-Format für Hilfetexte erfolgt.
Ein Erläuterungstext (Hilfetext) zu einem Einzelabschluss insgesamt kann jetzt direkt in der Anwendung Einzelabschluss-Monitor (EA) über die Aktion "Hilfetext editieren" erfasst und über die Aktion "Hilfetext anzeigen" eingesehen werden. Dazu ist es auch nicht mehr notwendig, dass der Einzelabschluss zuvor gesperrt wurde. Der Hilfetext kann aber nur noch mit Sonderberechtigung angelegt oder verändert werden, wenn der Einzelabschluss bereits gesperrt ist. Die Existenz eines Hilfetextes wird durch eine Spalte mit Überschrift 'H' angezeigt. Bisher war das Anlegen und Anzeigen eines Hilfetextes nur über die Übersicht "Verarbeitungssteuerungen" (VERARB) möglich.
Die Anzahl der Statusspalten für die Spiegel ist künftig entsprechend der Anzahl definierter (gemäß der neuen Anwendung SPI, s.o.) und aktivierter (gemäß den neuen Anwendungen ABRSPI und FACSPI) Spiegel variabel. Die Spaltenüberschrift wird dabei aus dem Stammsatz des Spiegels entnommen.
Entsprechend ist auch die Selektion nach Status eines Datenbestands variabel gestaltet. Alternativ zu den festen Kürzeln der übrigen Datenbestände kann auch der Schlüssel eines Spiegels angegeben werden.
Werte für statistische Mengen (Bilanz/GuV-Kennzeichen = '5') können i.d.R. nicht nach Soll und Haben eingestuft werden. Sie werden daher im Normalfall ohne Soll/Haben-Kennzeichen gespeichert. Dementsprechend können die statistischen Mengen jetzt auch negative Werte annehmen. Bisher wurde die Eingabe eines negativen Wertes ohne Soll/Haben-Kennzeichen immer zu einem positiven Wert mit einem willkürlichen Soll/Haben-Kennzeichen. Diese Änderung gilt auch für importierte oder mit der Formularerfassung erfasste Daten.
Beim Erfassen und Ändern von Kontensalden auf IC-Hauptkonten (Konten mit fest zugeordneter IC-Gesellschaft) wird jetzt geprüft, ob die IC-Gesellschaft in der aktuellen Periode gültig ist. Wenn nicht, wird eine Fehlermeldung ausgegeben.
In den Funktionen zum Generieren von Kontensalden aus Controllingsalden sowie von Controllingsalden aus IC-Kontensalden wurde jetzt die Möglichkeit zur Unterdrückung der Protokolle ergänzt. Diese Funktionen können daher jetzt auch als Mengenverarbeitung im Einzelabschluss-Monitor (EA) oder in einem Ablaufautomaten angestoßen werden, ohne dass der Vorgang für jede verarbeitete Gesellschaft bestätigt werden muss. Am Ende der Verarbeitung wird das gesammelte Protokoll für alle Gesellschaften angezeigt.
Die Übersichten "Anlagenbewegungen" (ANLBEW), "Anteilsbesitzbewegungen" (GESGES), "Kapitalbewegungen" (KAPBEW), "Rückstellungsbewegungen" (RUEBEW) und "Spiegelbewegungen" (SPIBEW) ermöglichen seit dem Release 2008.0 eine Selektion der Gesellschaften nach Konzernkreis. In diesem Fall werden jetzt auch die Bewegungen quotaler Gesellschaften mit ihren quotierten Werten angezeigt, so wie dies bisher auch schon für die Salden und Buchungen der Fall war.
Das Belegdatum wird jetzt beim Erfassen eines neuen Belegs in der Einzelsatzanwendung "Beleg" (BEL) nicht mehr mit dem Ersten des Monats der aktuellen Periode vorbelegt, sondern mit dem Ultimo dieses Monats.
Die Übersicht "Belege" (BEL) ermöglicht jetzt eine Verzweigung in die Formularerfassung für Buchungen (I-BUCH). Diese Aktion kann sowohl als Zeilenaktion für einen bestimmten Beleg als auch als globale Aktion für alle Belege eines Einzelabschlusses ausgelöst werden.
In der Übersicht "Buchungen" (BUCH) wird die Eingabe '*' im ersten Eingabefeld für den Buchungsschlüssel (Spiegel) zugelassen. Es werden dann alle Buchungen ohne Eintrag eines Buchungsschlüssels selektiert.
Abschreibungen werden automatisch neu berechnet und gebucht, wenn Änderungen an den zugrundeliegenden Buchungen vorgenommen werden. Werden jedoch die Abschreibungs-Parameter im Anlagenobjektstamm geändert, so hat dies keine Auswirkungen auf die bereits gebuchten Abschreibungen. Um eine Neuberechnung auszulösen, musste eine der beteiligten Buchungen manuell geändert und dann wieder zurück geändert werden.
Um dieses umständliche Verfahren zu vereinfachen, wurde in der Übersicht "Buchungen" (BUCH) die Aktion "Automatische AfA-Generierung" ergänzt, mit der die Neuberechnung der Abschreibungen ausgelöst werden kann. Dazu muss die Buchungszeile mit dem geänderten Anlagenobjekt markiert werden. Werden Zeilen ohne Anlagenkonto/-objekt markiert und die AfA-Berechnung gestartet, passiert einfach nichts. Das ist praktisch, wenn man mehrere Änderungen vorgenommen hat und für einen gesamten Beleg die Zeilen markiert und die Aktion startet.
Wegen der künftig beliebigen Anzahl von Spiegeln (s.o.) können die Verarbeitungssteuerungssätze für Spiegel nicht mehr mit festen Checkpoint-IDs belegt werden. Sie setzen sich jetzt generisch aus einem festen Präfix ("SPI-" für den Spiegel insgesamt, "VOR-" für die Vortragsprüfsummen) und dem Spiegelschlüssel zusammen.
Die Anwendungen zur Formularerfassung können jetzt auch dann aufgerufen werden, wenn für die selektierten Schlüssel (Periode, Datenart, Gesellschaft) nur eine Anzeigeberechtigung besteht. Die Wertspalten, die zu nicht zur Änderung berechtigten Schlüsseln gehören, werden aber gegen Eingabe gesperrt. Dies betrifft insbesondere die Mehrperiodenerfassung, wenn die selektierten Perioden teils gesperrt, teils aber noch änderbar sind.
Die Erfassung von IC-Kontensalden ist jetzt (wie für die Kontensalden) für mehrere Perioden gleichzeitig möglich. Dazu wurden im Selektionsbereich (ähnlich der Formularerfassung für Kontensalden) Eingabefelder für eine Spaltenoption, Vorperiode, Periodenabstand und Vergleichsdatenart ergänzt.
Die Spaltenoption 'K' (ist auch Defaultwert beim Direktaufruf) sorgt für die bisherige Erfassungsansicht. Zusätzlich kann dabei eine Vorperiode und/oder eine Vergleichsdatenart angegeben werden. Dann wird neben der Erfassungsspalte eine Spalte mit den Vergleichsdaten angezeigt, in der vorhandene Daten dargestellt werden, aber keine Eingabe möglich ist. Dies ermöglicht eine Vorbelegung der Erfassungszeilen mit den IC-Gesellschaften, die in der Vergleichsumgebung auch angesprochen wurden.
Bei der Spaltenoption 'P' sind auch Vorperiode und Periodenabstand zu spezifizieren. Wie in der Formularerfassung für Kontensalden (I-KTOSAL) gibt es dann eine Erfassungsspalte je spezifizierter Periode. In dieser Variante wird je IC-Gesellschaft immer nur eine Zeile ausgegeben. Gibt es für eine IC-Gesellschaft bereits mehrere Datensätze, so wird deren Summe zwar angezeigt, der Wert ist aber nicht änderbar.
Wird nun bei der Spaltenoption 'P' zusätzlich eine Vergleichsdatenart angegeben (dies kann dieselbe Datenart wie im vorherigen Eingabefeld sein), so werden die beiden zuvor genannten Möglichkeiten kombiniert. Die erste Spalte für die Vorperiode wird zu einer Anzeigespalte für Vergleichsdaten ohne Eingabemöglichkeit. Dies kann z.B. dazu genutzt werden, Plandaten für 4 Quartale des neuen Jahres zu erfassen und dazu die Istdaten des Vorjahres als Vergleichswerte anzuzeigen.
Bei der Formularerfassung von Buchungen wird jetzt nach dem Speichern eine Warnung ausgegeben, wenn die erfassten Buchungen zu einem Beleg ohne Soll/Haben-Gleichheit führen.
Zur Erfassung von IC-Beständen im Vorratsvermögen wurde eine neue Erfassungsanwendung erstellt, die aus dem Menübaum im Zweig "Formularerfassung" oder durch das Kurzwort I-ICBEW aufgerufen werden kann.
Im Selektionsbereich sind die Schlüsselfelder Gesellschaft, Geschäftsbereich, Periode und Datenart eindeutig vorzugeben. Es sind nur Datenarten auf Ebene des Konzernkontenplans erlaubt. Optional sind zusätzliche Einschränkungen nach IC-Gesellschaft, IC-Geschäftsbereich, Konto (nur Produktkonten, Kontokennzeichen = 'V') oder Produkt/Produktgruppe möglich.
Die Eingabe einer Vorperiode ist optional. Bei Angabe einer Vorperiode werden die ermittelten Vorperiodenwerte aber nur als Summe zum Produkt bzw. Konto ausgewiesen, da die Bewegungen nicht eindeutig zuordenbar sind.
Über die Angabe der Sortier-Option wird gesteuert, ob die Datenanzeige gruppiert nach Produkt/Produktgruppe ('P') oder nach Konto ('K') erfolgt. Entsprechend werden auch Summenzeilen ausgegeben. Die Sortier-Option wird mit 'P' vorbelegt.
Je Produkt werden alle bereits erfassten IC-Bewegungen angezeigt. Diese Daten können geändert, aber nicht gelöscht werden. Zusätzlich gibt es je Produkt eine leere Eingabezeile, in der neue Datensätze erfasst werden können, und eine Zwischensummenzeile, in der die Summe aller erfassten Werte sowie evtl. die Werte der Vorperiode der jeweiligen IC-Bewegungen angezeigt werden.
Direkte Eingabemöglichkeiten bestehen für die Spalten IC-Gesellschaft, IC-Geschäftsbereich, Wert in Landeswährung sowie Zu-/Abschläge für den KW-Wert in Prozent oder als absoluter Betrag. Für die IC-Gesellschaft und den IC-Geschäftsbereich gibt es in den Eingabezellen eine Auswahlunterstützung (Auswahl-Button oder <F4>). Analog zur Formularerfassung für Kontensalden (I-KTOSAL) gibt es keine Eingabemöglichkeit für das Soll/Haben-Kennzeichen. Dieses wird vielmehr gemäß dem Bilanz/GuV-Kennzeichen des Kontos ermittelt. Abweichende Soll/Haben-Kennzeichen können durch die Eingabe negativer Werte erzielt werden.
Ein Zusatzdialog, der durch Doppelklick in die Spalte <Zusatzdaten> öffnet, ermöglicht die Eingabe eines Bemerkungstextes, von Wertfeldern für Konzern- und Parallelwährung, eines Eliminierungskontos sowie ggf. von Controllingobjekten.
Über das Aktionsmenü sind Verzweigungen in die Folgeanwendungen "Einzelabschluss-Monitor" (EA), "Vorratsvermögen IC-Bestände" (ICBEW), "Produkte/Produktgruppen" (PRO, auch bei Doppelklick in die Spalte "Produktgruppe/Produkt"), "Form.Erfassung Kontensalden" (I-KTOSAL, auch bei Doppelklick in die Spalte "Konto-Kennzeichen") und "Form.Erfassung IC-Unterkontensalden" (I-ICKTOSAL) möglich.
Die Anwendung kann auch als Folgeanwendung aus der Formularerfassung für Kontensalden (I-KTOSAL) heraus aufgerufen werden.
Die neuen Prüfregeloperatoren "L EXIST" und "L NOT EXIST" definieren neue Arten von Prüfregeln, mit denen geprüft werden kann, ob auf einem (auf der linken Seite angegebenen) Konto ein Saldo erfasst bzw. kein Saldo erfasst ist. Der Saldo kann dabei auch einen Nullwert enthalten. Bei Angabe von mehreren Konten muss mindestens ein Konto bzw. darf keines dieser Konten einen Saldo aufweisen.
Analog zum Kontenstamm (s.o.) wird auch in den Prüfregelpositionen das Attribut "Kontokennzeichen 2" durch das Attribut "Spiegel" mit Verweis auf die neue Tabelle SPI ersetzt. Prüfregeln, die sich auf das entfallene Kontokennzeichen 'L' beziehen, sind dadurch nicht mehr möglich und werden durch die Konvertierung auf den Spiegel 'K' umgesetzt. Soll sich eine Prüfregel nur auf Konten mit dem früheren Kontokennzeichen 'L' beziehen, müssen diese Konten jetzt explizit in den Prüfregelpositionen spezifziert werden.
Ist einer Seite einer Prüfregel eine Position zugeordnet, dem zugehörigen Positionsplan aber kein Konto des für die jeweilige Datenart relevanten Kontenplans, so wird jetzt die Meldung KON2053W ("Prüfregel nicht verarbeitet, da Positionsplan ohne zugeordnete Konten") in das Prüfregelergebnis geschrieben. Analog zur Meldung "Prüfregel nicht anwendbar" wird der Prüfregel-Status im Einzelabschluss-Monitor (EA) [grün]. Bisher wurde in diesem Fall die Prüfregelberechnung fehlerhaft abgebrochen.
Die Übersichten für Prüfregelergebnisse im Einzelabschluss bzw. Konzernabschluss (PRFERG/PRFERGK) wurden um eine Löschfunktion erweitert. Durch die Aktion "Löschen Prüfregelergebnisse" werden immer alle Ergebnisse des Einzel- bzw. Konzernabschlusses gelöscht, so als ob die Prüfregeln niemals berechnet worden wären. Der Verarbeitungssteuerungssatz dazu (VERARB/KVERARB) wird allerdings nicht gelöscht, sondern mit der Meldung KON1894W (Prüfregelergebnis nicht aktuell) versehen, die zum Status [gelb] im Einzel- bzw. Konzernabschluss-Monitor führt.
Die Aufrufanwendung "Erstellen Gesellschaftsvorträge aktuelle Periode" (PERGES) zeigt wie bisher eine Zeile für jeden Spiegel an, zum einen für eine Statusanzeige, zum anderen zum Anstoß eines einzelnen Vortrags dieses Spiegels als Zeilenaktion. Die Zeilen für die Spiegel werden jetzt allerdings dynamisch über die in der Anwendung SPI (s.o.) definierten Spiegel ermittelt. Als Ersatz-"Menü-Id" dient dabei die jeweilige Checkpoint-Id ("SPI-" + Spiegelschlüssel, s.o.). Spiegel ohne Vortrag gemäß Definition in SPI werden unterdrückt.
Beim Vortrag von Report-Kopfsätzen mit Angabe einer Vorperiode wird jetzt das Periodenkennzeichen der Vorperiode ausgewertet. So bleibt eine Vorperiode, die einen Jahresabschluss darstellt, künftig erhalten, wenn die aktuelle Herkunftsperiode keinen Jahresabschluss darstellt, bzw. wird um 3 erhöht, wenn die aktuelle Periode von einem Jahres- auf einen Quartals- oder Monatsabschluss vorgetragen wird. Entsprechend bleiben Vorperioden, die einen Quartalsabschluss darstellen, erhalten, wenn die aktuelle Periode einen Monatsabschluss darstellt, bzw. um 3 erhöht, wenn die aktuelle Periode von einem Jahres- oder Quartalsabschluss auf einen Monatsabschluss vorgetragen wird. Bisher wurde die Vorperiode immer um das Vortragsintervall erhöht. Das ist jetzt nur noch in allen sonstigen Fällen so.
In der Funktion zum Abgleich des Perioden-Vortrags im Einzelabschluss wurde jetzt die Möglichkeit zur Unterdrückung der sofortigen Anzeige der Protokolle ergänzt. Diese Funktion kann daher jetzt auch als Mengenverarbeitung im Einzelabschluss-Monitor (EA) oder in einem Ablaufautomaten angestoßen werden, ohne dass der Vorgang für jede verarbeitete Gesellschaft bestätigt werden muss. Am Ende der Verarbeitung wird das gesammelte Protokoll für alle Gesellschaften angezeigt.
Die Aufrufanwendung "Erstellen Einzelabschluss neue Datenart" (GESABV) zeigt wie bisher eine Zeile für jeden Spiegel an, zum einen für eine Statusanzeige, zum anderen zum Anstoß einer einzelnen Überleitung dieses Spiegels als Zeilenaktion. Die Zeilen für die Spiegel werden jetzt allerdings dynamisch über die in der Anwendung SPI (s.o.) definierten Spiegel ermittelt. Als Ersatz-"Menü-Id" dient dabei die jeweilige Checkpoint-Id ("SPI-" + Spiegelschlüssel, s.o.).
Das Verdichtungskennzeichen im Datenartenstamm (FAC) wirkt jetzt auch auf Controllingsalden. Controllingsalden werden nur noch dann auf ein Verdichtungs-Controllingobjekt aggregiert, wenn das Verdichtungskennzeichen gesetzt ist.
Die Aufteilung von Kontensalden auf Geschäftsbereiche ("UBR-Split"), die i.d.R. anhand der Controllingsalden erfolgt, ist jetzt auch dann möglich, wenn bei der Quell-Datenart der Schalter für die Führung von Controllingsalden nicht gesetzt ist. Dann werden Controllingsalden nicht berücksichtigt und die Überleitung erfolgt nur auf die im Kontenstamm bzw. Kontenplan angegebenen Geschäftsbereiche.
Beim "UBR-Split" werden jetzt auch die Gesellschafts-Geschäftsbereichs-Zuordnungen (GESUBR) berücksichtigt:
In der Funktion zum Abgleich der Überleitung auf die nächste Datenart im Einzelabschluss wurde jetzt die Möglichkeit zur Unterdrückung der sofortigen Anzeige der Protokolle ergänzt. Diese Funktion kann daher jetzt auch als Mengenverarbeitung im Einzelabschluss-Monitor (EA) oder in einem Ablaufautomaten angestoßen werden, ohne dass der Vorgang für jede verarbeitete Gesellschaft bestätigt werden muss. Am Ende der Verarbeitung wird das gesammelte Protokoll für alle Gesellschaften angezeigt.
Die Konsolidierungsbuchungen der neuen Fremdanteilsbelege mit Konsolidierungsverarbeitung 'FF', 'FK', 'F0', 'F1' usw. (s.o.) werden wie die bisherigen 'KA'-Buchungen auf Konsolidierungsbelege mit Konsolidierungsverarbeitung 'FV' (bisher 'KV') vorgetragen. Relevante Informationen dazu werden aus dem neuen Konsolidierungsparameter 'FK' (bisher 'KA') entnommen.
Beim Vortrag von Report-Kopfsätzen mit Angabe einer Vorperiode wird jetzt das Periodenkennzeichen der Vorperiode analog zum Perioden-Vortrag im Einzelabschluss (s.o.) ausgewertet.
Die Übersicht "Latente Steuern Kopfsätze" (LTK) zeigt jetzt je Gesellschaft auch das Länderkennzeichen aus dem Gesellschaftsstamm (GES) an. So kann leichter erkannt werden, für welche Gesellschaften welcher Steuersatz anzugeben ist.
Die neue Umrechnungsanweisung 'VPK' (Vorperiodenkurs) steuert, dass eine Spiegelbewegung mit dem historischen Durchschnittskurs der Vorperiode des Kontensaldos umgerechnet wird. Bei Bewegungen auf IC-Konten erfolgt die Berechnung des historischen Durchschnittskurses differenziert nach IC-Gesellschaft. Die Umrechnungsanweisung 'VPK' kann Spiegelbewegungen und Buchungen auf Spiegelkonten über die Buchungsschlüssel-Umrechnungsanweisungen (BSLUAW) zugeordnet werden, nicht jedoch dem Konto insgesamt (KTOUAW).
Die direkte Zuordnung von 'VPK' zu einer Bewegung oder Buchung ist zwar möglich, wird jedoch (analog 'SK' und 'PDK') durch die Steuerungen gemäß BSLUAW oder KTOUAW überlagert, so dass sie nur als Nachweis der so erfolgten Umrechnung, aber nicht als Vorgabe dient.
Die Umrechnungsanweisung 'VPK' ersetzt die Steuerung, die bisher über die (Konten-)Umrechnungsanweisung 'FDA' (Fortgeschriebener Durchschnittskurs für Anlagen, Standard für Anlagenkonten bei Umrechnungsverfahren 'MZB') erfolgte. Sie kann jetzt aber flexibel auf beliebige Buchungsschlüssel und auch auf andere Spiegel angewandt werden. Sie wirkt außerdem nicht nur auf Bewegungen, sondern auch auf Buchungen.
Auch die zweite Sonderfunktion der Umrechnungsanweisung 'FDA', die Umrechnung der laufenden Zuschreibungen mit derselben Umrechnungsanweisung wie die laufenden Abschreibungen, ist entfallen. Auch diese Steuerung muss jetzt über die Buchungsschlüssel-Umrechnungsanweisungen (BSLUAW) erfolgen. 'FDA' unterscheidet sich damit nicht mehr von der Umrechnungsanweisung 'FDK' (Fortgeschriebener Durchschnittskurs).
Die Übersicht "Konto-Umrechnungsnachweis" (KTOUMR) zeigt jetzt auch dann Umrechnungsdifferenzen an, wenn die Konzern- oder die Parallelwährung nicht eindeutig ist. Dies wird durch die Anzeige des Währungskennzeichens '%' in der Spaltenüberschrift gekennzeichnet.
Diese Übersicht wurde durch eine Gruppierung der Spaltenüberschriften für Konzern- bzw. Parallelwährung übersichtlicher gestaltet.
Besteht zwischen der Summe der je Konto ermittelten Umrechnungsdifferenzen und der im WUM-Kopfsatz angezeigten Gesamt-Differenz (Bilanz oder GuV) eine Rundungsdifferenz, so wird diese jetzt in einer Zusatzzeile als Rundungsdifferenz ausgewiesen, so dass die Summen übereinstimmen.
Die Übersicht "Konto-Umrechnungsanweisungen" (KTOUAW) zeigte für die Konzern- und die Parallelwährung jeweils zwei Spalten an: eine mit der Umrechnungsanweisung und eine Farbspalte, die signalisierte, ob die Umrechnungsanweisung abweichend vom Standard gemäß Umrechnungsverfahren ist. Diese Spalten wurden jetzt zusammengefasst, so dass die Spalten mit der Umrechnungsanweisung selbst farbig hinterlegt sind.
Außerdem erfolgte in den Spaltenüberschriften eine Gruppierung der Spalten für Konzern- bzw. Parallelwährung.
In der Übersicht "Wechselkurse" (WKZWKA) ist der Parameter "Stichtag" jetzt eine Pflichteingabe. Bei direktem Aufruf dieser Übersicht aus dem Menübaum oder per Kurzworteingabe wird das Feld mit dem Ultimo der aktuellen Periode aus der Vorbelegung (VOR) vorbelegt. Das gilt auch bei Aufruf aus Voranwendungen, die unabhängig von der aktuellen Periode sind (z.B. "Währungskennzeichen" (WKZ)).
Erfolgt der Aufruf aus der Übersicht "Währungsumrechnung KW + PW" (WUM) wird neben der aktuellen Periode auch die Vorperiode als Parameter übergeben und in das Eingabefeld "ab Periode" eingetragen. So werden in dieser Ansicht auch die Vorperiodenkurse angezeigt, die ja ggf. ebenfalls bei der Währungsumrechnung angewandt werden.
Der in der Übersicht "Konzernkreise + Konzernmonitor" (KTKGES) angezeigte Status für die Prüfregelergebnisberechnung wird jetzt automatisch auf [gelb] (Warnung) gesetzt, wenn sich Konsolidierungsbuchungen nachträglich ändern, vorausgesetzt der Status war vorher bereits [grün]. In den zugehörigen Satz der Konzern-Verarbeitungssteuerung (KVERARB, Checkpoint 'PRFERG') wird die Meldung KON1894W (Prüfregelergebnisse nicht aktuell - Daten haben sich geändert) eingetragen.
Der in der Übersicht "Konzernkreise + Konzernmonitor" (KTKGES) angezeigte Status für die Konzern-Ergebnisrechnung ('JU') wird jetzt automatisch auf [gelb] (Warnung) gesetzt, wenn sich Konsolidierungsbuchungen nachträglich ändern, vorausgesetzt der Status war vorher bereits [grün]. In den zugehörigen Satz der Konzern-Verarbeitungssteuerung (KVERARB, Checkpoint 'KTKERGV') wird die Meldung KON2123W (JU-Status nicht aktuell - Daten haben sich geändert) eingetragen.
In beiden Fällen wird die Änderung von Konsolidierungsbuchungen an der Änderung der Prüfsumme eines Konsolidierungsbelegs erkannt. Die Führung von Prüfsummen ist somit Voraussetzung für diese Automatik.
Wenn der Anwender eigene individuelle Konsolidierungsverarbeitungen für manuelle Buchungen ('M0', 'M1' etc.) definiert hat, so kann er künftig dazu auch eigene Konsolidierungsparameter anlegen. D.h. dass für die verschiedenen manuellen Konsolidierungsverarbeitungen unterschiedliche Ergebnisvortragskonten oder Steuerungen zur Zusammenfassung von Vorträgen angeben werden können. Ohne Definition eines eigenen Konsolidierungsparameters gelten wie bisher die Angaben im Konsolidierungsparameter 'MB'.
Wird in der Übersicht "Konsolidierungsparameter" (KTKPAR) die Konsolidierungsverarbeitung 'MB' vorgegeben, so werden auch die Konsolidierungsparameter für die individuellen manuellen Konsolidierungsverarbeitungen angezeigt, sofern sie angelegt wurden.
Konten und andere Parameter zur Berechnung und Buchung von Fremdanteilen werden jetzt in einem Konsolidierungsparameter 'FK' (s.o.) geführt. Dieser ersetzt den bisherigen Konsolidierungsparameter 'KA'.
Im Konsolidierungsparameter 'FK' (bisher 'KA', s.o.) können jetzt die Konten (und Controllingobjekte) zur Eliminierung des Jahresergebnisses und zur Eliminierung von ergebniswirksamen Konsolidierungsbuchungen nach direkten und indirekten Fremdanteilen unterschieden werden. Zusätzlich wurde für alle Konten des Konsolidierungsparameters (mit Ausnahme der Konten für Entkonsolidierung und Ergebnisvortrag) die Eingabe eines Buchungsschlüssels ermöglicht.
Die Kontenauswahl für den Fremdanteils-Konsolidierungsparameter 'FK' wird jetzt so gesteuert, dass jeweils nur noch die Konten angeboten werden, die gemäß ihren Attributen normalerweise fachlich sinnvoll sind. Die Prüfungen der Eingaben wurden jedoch nicht geändert, so dass auch andersartige Angaben weiterhin möglich sind, sofern sie auch bisher zugelassen waren.
Im Konsolidierungsparameter 'KK' ist das Konto "Verrechnung mit Gewinnrücklagen" jetzt eine optionale Angabe, da es zumindest gemäß IFRS nicht benötigt wird.
Im Konsolidierungsparameter 'KK' kann zum Konto "Verrechnung passivischer UB" jetzt auch ein Buchungsschlüssel angegeben werden, sofern es sich um ein Spiegelkonto handelt. Dieser Buchungsschlüssel wird dann auf Buchungen für dieses Konto automatisch eingestellt.
In den Konsolidierungsparametern 'KK' und 'EK' kann als Konto "Verrechnung passivischer UB" jetzt auch ein GuV-Konto angegeben werden, so dass eine ergebniswirksame Verrechnung passiver Unterschiedsbeträge im Buchungssatz '03' erfolgen kann. Bisher war dies nur im Buchungssatz '08' (sonstige Verrechnungen) möglich.
Gemäß der veränderten Funktion der Endkonsolidierung (s.u.) wird der Status 'KS' jetzt nur noch dann auf [rot] gesetzt, wenn die Gesellschaft den Konzernkreis verlässt, nicht jedoch, wenn sich der Anteil an der Gesellschaft nur verringert, diese aber im Konzernkreis verbleibt. In diesem Fall wird der Status 'KK' für die Kapitalkonsolidierung auf [rot] gesetzt.
Der Status 'FF' (Fortschreibung Fremdanteile) wird jetzt auch für quotale Gesellschaften mit indirekten Fremdanteilen gesetzt.
Bei der Kapitalkonsolidierung werden jetzt nicht nur die Eigenanteile, sondern auch die direkten Fremdanteile am Eigenkapital berechnet und verbucht (s.o.). Außerdem werden in dieser Funktion jetzt auch Verminderungen der Eigenanteile verarbeitet, sofern die Tochtergesellschaft nicht den Konzernkreis verlässt.
Die Kapital-Erstkonsolidierung bezieht sich jetzt nicht mehr auf die in der Aufrufanwendung "Konzernkreise + Konzernmonitor" (KTKGES) angegebene Vorperiode, sondern ermittelt selbstständig den letzten vorhergehenden Jahresabschluss anhand der Periodenkennzeichen in der Tabelle "Abrechnungsperioden" (ABR). Die bisherige Logik führte bei Angabe eines vorhergehenden Zwischenabschlusses ggf. zur Ermittlung falscher Werte für den anteiligen Jahresüberschuss.
Falls Kapitalkonsolidierungsbelege unterjährig aus einem vorhergehenden Zwischenabschluss vorgetragen wurden, so bleiben diese erhalten. Neu konsolidiert (und ggf. vorher gelöscht) werden daher nur Beteiligungsänderungen, die noch nicht bereits in einer vorhergehenden Zwischenperiode verarbeitet wurden. Falls weitere Belege neu erstellt werden sollen, müssen die vorgetragenen Belege zuvor manuell gelöscht werden.
Die Ausgabe von Beteiligungsprozentwerten in den Buchungstexten erfolgt jetzt mit acht statt bisher zwei Nachkommastellen.
Eine Buchung auf dem Interimskonto für den Unterschiedsbetrag erfolgt jetzt nur noch, wenn der Unterschiedsbetrag ungleich null ist.
Die Berechnung und Buchung von Fremdanteilen wurde neu konzipiert und strukturiert (s.o.). Insbesondere erfolgt die Buchung der direkten Fremdanteile am Eigenkapital jetzt im Rahmen der Kapital-Erstkonsolidierung, während die Buchung anderer Fremdanteile durch die neue Funktion "Fortschreiben Fremdanteile" erfolgt.
Die Berechnung von Fremdanteilen bezieht sich jetzt nicht mehr auf die in der Aufrufanwendung "Konzernkreise + Konzernmonitor" (KTKGES) angegebene Vorperiode, sondern ermittelt selbstständig den letzten vorhergehenden Jahresabschluss anhand der Periodenkennzeichen in der Tabelle "Abrechnungsperioden" (ABR).
Durch Erweiterung des Konsolidierungsparameters können jetzt die Fremdanteile am Jahresergebnis und an ergebniswirksamen Konsolidierungsbuchungen durch unterschiedliche Konten nach direkten und indirekten Fremdanteilen unterschieden werden.
Im Konsolidierungsparameter 'FK' wurden optionale Konten "Fremdanteile an Kurseffekten" und "Fremdanteile an Kurseffekten indirekt" ergänzt. Ist dort ein Konto angegeben, wird es anstelle des allgemeinen Fremdanteilskontos in den Konsolidierungsbuchungen für Kurseffekte verwendet.
Bei der Berechnung indirekter Fremdanteile wird der Fremdanteil am Unterschiedsbetrag aus der Kapital-Erstkonsolidierung gebucht. Dazu wird jetzt auch die anteilige Verrechnung des Unterschiedsbetrages gemäß Kapital-Erstkonsolidierung gebucht. Der 'FF'-Status wird dann auch nicht wie bisher auf [gelb], sondern gleich auf [grün] gesetzt. In der Regel muss für die Verrechnung des Fremdanteils am Unterschiedsbetrag keine weitere Aktion mehr erfolgen.
Die Berechnung indirekter Fremdanteile wird jetzt auch für quotale Gesellschaften unterstützt.
Die Buchungstexte der erzeugten Buchungen wurden überarbeitet und dabei weiter differenziert. Die Ausgabe von Beteiligungsprozentwerten in den Buchungstexten erfolgt dabei mit acht statt bisher zwei Nachkommastellen.
Für Anlagenobjekte, die im Rahmen der Verrechnung von Unterschiedsbeträgen neu erzeugt werden, wird jetzt vorgeschlagen, dass diese ohne automatische AfA-Berechnung (AfA-Art = 'K') definiert werden. Die bisherige Vorbelegung (AfA-Art = 'L', AfA-Dauer 10 Jahre) war ebenfalls willkürlich und umständlicher anzupassen.
Die Aktivierung eines Geschäftswertes in Landeswährung ist jetzt unabhängig von der Rechnungslegungsart der Datenart (bisher nur bei 'I' = IFRS) bei einem wählbaren Unternehmen möglich. Im Unterschied zu IFRS ist allerdings eine planmäßige Abschreibung des Geschäftswertes in Landeswährung möglich.
Der Buchungstext für die erzeugten Konsolidierungsbuchungen kann jetzt in einer Länge von 70 Zeichen angegeben werden.
Die Funktion "Endkonsolidierung" verarbeitet jetzt nur noch Abgänge aus dem Konzernkreis (Eintrag eines Abgangsdatums in "Konzern/Tk-Kreis-Gesellschaft" (KTKGESE)). Beteiligungsverminderungen werden jetzt dagegen wie Beteiligungserhöhungen im Rahmen der "Kapital-Erstkonsolidierung" behandelt einschl. der Erhöhung der Fremdanteile.
Die Endkonsolidierung quotaler Gesellschaften berücksichtigt jetzt auch die indirekten Fremdanteile an diesen.
Die Zwischenergebniseliminierung im Anlagenvermögen ist jetzt für Gesellschaften mit Konsolidierungsart 'K' (keine Konsolidierung) oder 'E' (Einbeziehung at Equity) nicht mehr möglich.
Bestimmte Konsolidierungsverarbeitungen dienen nur zur Spiegelumbuchung und wirken sich daher auf die Bilanz bzw. GuV gar nicht aus. Zwecks Optimierung der Laufzeiten werden diese Belege daher bei der Erstellung der Bilanz/GuV-Reports auch gar nicht berücksichtigt. Dies führte in der Vergangenheit häufiger zu Problemen, da Anwender manuelle Buchungen an diese Umbuchungsbelege anhängten, die durchaus Auswirkungen auf die Bilanz oder GuV gehabt hätten, aber nicht verarbeitet wurden. Um derartige Probleme künftig zu vermeiden, werden die Umbuchungsbelege jetzt daraufhin geprüft, dass die Summe der Buchungen je Gesellschaft, Geschäftsbereich und Konto null ergeben muss. Ist dies nicht der Fall, wird eine entsprechende Meldungsnummer in den Belegkopf eingetragen.
Die Konsolidierungsbelege für SK- und AE-Spiegelumbuchungen ('SU', 'AU') belegten bisher immer zwecks Übersichtlichkeit eine Buchungssatznummer je Spiegel ('01' = Anlagen, ..., '04' = individueller Spiegel 'S1', ..., '12' = individueller Spiegel 'S9'). Da die Anzahl der Spiegel künftig beliebig ist, kann dieses Verfahren nicht mehr beibehalten werden. Es wird daher nur noch eine Buchungssatznummer je Spiegeltyp (gemäß Spiegeldefinition SPI) vergeben: '01' = Anlagen, '02' = Kapital, '03' = Rückstellungen, '04' = sonstige Spiegel.
Der Ablaufautomat für alle Konsolidierungsverarbeitungen eines Teilkonzerns wurde durch Ergänzung folgender Konsolidierungsfunktionen vervollständigt:
Die Übersichten "Konsolidierungsbelege" (KONBEL) und "Konsolidierungsbuchungen" (KONBUCH) enthalten jetzt zwei Eingabefelder für die ausgewählten Konsolidierungsverarbeitungen, um Belege verschiedener Verarbeitungen gemeinsam selektieren zu können.
Das Selektionsfeld für die Belegnummer wurde in diesen Anwendungen in drei Eingabefelder für 1. Gesellschaft, 2. Gesellschaft und Konsolidierungsverarbeitung aufgeteilt, so wie dies bereits bisher in der Einzelsatzanwendung "Konsolidierungsbeleg" (KONBELE) der Fall war. Durch Eingabe '*' für die zweite Gesellschaft können Belege mit nur einer Gesellschaft in der Belegnummer selektiert werden.
Das Löschen von Vortrags-Konsolidierungsbelegen in der Einzelsatzanwendung "Konsolidierungsbeleg" (KONBELE) ist analog dem Löschen von automatisch erstellten Konsolidierungsbuchungen in KONBUCHE nur noch mit Sonderberechtigung zugelassen. Diese Sonderberechtigung ist keiner der Standard-Berechtigungsgruppen zugewiesen.
Die Übersicht "Konsolidierungsbelege" (KONBEL) ermöglicht jetzt eine Verzweigung in die Formularerfassung für Konsolidierungsbuchungen (I-KONBUCH). Diese Aktion kann sowohl als Zeilenaktion für einen bestimmten Beleg als auch als globale Aktion für alle Belege eines Konzernabschlusses ausgelöst werden.
Weitere neue Aktionen der Übersicht "Konsolidierungsbelege" (KONBEL) sowie der Einzelsatzanwendung "Konsolidierungsbeleg" (KONBELE) ermöglichen die Freigabe bzw. das Aufheben einer Freigabe eines Konsolidierungsbelegs nach dem Vier-Augen-Prinzip (s.o.). Nach Durchführung dieser Aktionen werden Freigabe-Status sowie der jeweilige Benutzer und der Zeitpunkt der letzten Aktion angezeigt. Voraussetzung für diese Aktionen und Anzeigen ist die aktivierte Änderungsprotokollierung für Konsolidierungsbuchungen.
Verschiedene veraltete Konsolidierungsverarbeitungen (u.a. 'EE', 'KE', 'KM') wurden jetzt so eingestellt, dass keine neuen Konsolidierungsbelege und -buchungen mehr dazu erfasst werden können. Bestehende Belege lassen sich aber weiterhin anzeigen.
In der Übersicht "Konsolidierungsbuchungen" (KONBUCH) wird die Eingabe '*' im ersten Eingabefeld für den Buchungsschlüssel (Spiegel) zugelassen. Es werden dann alle Buchungen ohne Eintrag eines Buchungsschlüssels selektiert.
Wenn der Währungsumrechnungsschalter der aktuellen Datenart (FAC) nicht auf 'P' (Umrechnung in Parallelwährung) steht, werden die Konsolidierungsbuchungen eines Beleges nicht mehr auf stimmige Werte in Parallelwährung geprüft. Bisher führte diese Prüfung ggf. zu Fehlermeldungen bei der Erstellung von Reports.
Abschreibungen werden automatisch neu berechnet und gebucht, wenn Änderungen an den zugrundeliegenden Konsolidierungsbuchungen vorgenommen werden. Werden jedoch die Abschreibungs-Parameter im Anlagenobjektstamm geändert, so hat dies keine Auswirkungen auf die bereits gebuchten Abschreibungen. Um eine Neuberechnung auszulösen, musste eine der beteiligten Buchungen manuell geändert und dann wieder zurück geändert werden.
Um dieses umständliche Verfahren zu vereinfachen, wurde in der Übersicht "Konsolidierungsbuchungen" (KONBUCH) die Aktion "Automatische AfA-Generierung" ergänzt, mit der die Neuberechnung der Abschreibungen ausgelöst werden kann. Dazu muss die Buchungszeile mit dem geänderten Anlagenobjekt markiert werden. Werden Zeilen ohne Anlagenkonto/-objekt markiert und die AfA-Berechnung gestartet, passiert einfach nichts. Das ist praktisch, wenn man mehrere Änderungen vorgenommen hat und für einen gesamten Beleg die Zeilen markiert und die Aktion startet.
Die Übersichten "Kontensalden und Konsolidierungsbuchungen" (KONSAL) und "Bewegungen und Konsolidierungsbuchungen" (KONBEW) zeigen jetzt auch die Konsolidierungsbuchungen von nicht konsolidierten Gesellschaften (Konsolidierungsart 'K') an, da diese Buchungen auch in Konzernreports verarbeitet werden. Konsolidierungsbuchungen aus untergeordneten Teilkonzernen, deren Beleg die Buchungsart 'ET' hat, werden dagegen nicht mehr angezeigt, da diese Buchungen von den Konzernreports nicht verarbeitet werden.
Die Übersicht "Bewegungen und Konsolidierungsbuchungen" (KONBEW) ermöglicht jetzt auch eine Selektion nach Spiegelbereich, was speziell für den Anlagenspiegel interessant ist.
Ein ausgewähltes Szenario wird in der Vorbelegung des Benutzers gespeichert und beim nächsten Aufruf der Anwendung "Planungsformular" (PLAN) voreingestellt.
Das Aktionsmenü wie auch verschiedene Kontextmenüs in der Anwendung PLAN wurden erweitert und durch Trennlinien und Submenüs übersichtlicher gestaltet.
Neben der direkten Eingabe in den Zellen und dem Anlegen von Regeln gibt es jetzt auch die Möglichkeit, eine einzelne Buchung vorzunehmen. Diese findet nur in einer einzelnen Periode statt und ihr Buchungsbetrag ist fest, ist also weder vom Benutzer im T-Konto oder Regelviewer veränderbar noch nimmt sie am automatischen Verteilen teil. Dazu wurde im Objektmenü einer Zelle der Menüpunkt 'Buchung' ergänzt. Durch Auswählen dieses Menüpunktes öffnet sich ein Fenster, in dem der Benutzer das Soll-Konto und das Haben-Konto einstellen kann. Das Soll-Konto ist bereits vorbelegt mit dem Konto, zu dem die ausgewählte Zelle gehört. Desweiteren ist der Buchungsbetrag eingebbar. Für Buchungen über mehr als zwei Konten kann der Benutzer auf der Soll oder der Habenseite zusätzliche Konten einfügen. Außerdem kann ein Name für die Buchung festgelegt werden, welcher dann im T-Konto dargestellt wird. Der "Fertig"-Button wird erst aktiviert, wenn alle Konten, alle Buchungsbeträge und der Buchungsname festgelegt wurden. Außerdem muss die Summe der Buchungsbeträge auf der linken und rechten Seite gleich sein.
Im Kontextmenü (rechte Maustaste) einer Zelle gibt es jetzt einen Eintrag, mit dem festgelegt wird, ob die Zelle gesperrt ist oder nicht. Ist die Zelle gesperrt, sind keine Eingaben auf der Zelle möglich und sie wird auch nie automatisch verändert. Für das Positions-Konten-Splashing wird die Zelle behandelt, als wäre sie nicht vorhanden. Regeln, die zu einer Veränderung dieser Zelle führen würden, werden automatisch mit gesperrt, so dass auch in den durch die Regel verknüpften Zellen keine Eingaben mehr möglich sind. Das Sperren einer Position sperrt automatisch alle untergeordneten Konten mit.
Sämtliche Änderungen sowohl an den Planwerten als auch an den Regeln und Regelmustern (Templates) sowie deren Anwendung können durch einen "Undo"-Knopf wieder rückgängig gemacht werden. Dies ist in bis zu 100 Schritten möglich. Versehentlich zu viel rückgängig gemachte Änderungen können durch Betätigung eines "Redo"-Knopfes erneut vorgenommen werden. Nach <Speichern> der Änderungen in der Datenbank lassen sich diese allerdings nicht mehr zurücknehmen.
Die Hintergrundfarben für die Spalten von Ist-, Forecast- und Plandaten sind jetzt über den Dialog <Optionen> frei einstellbar.
Der Benutzer kann jetzt mehrere Perioden auswählen und für diese Perioden automatisch Werte aus anderen Perioden kopieren. Dazu werden die Ziel-Perioden paarweise mit Quell-Perioden aus z.B. Ist-Daten-Perioden verbunden. Die Werte aus den Quell-Perioden können beim Kopieren optional mit einem Faktor multipliziert werden, bevor das Ergebnis in die Ziel-Perioden übertragen wird. Die Benutzerführung erfolgt durch einen geführten Dialog (Assistent). Der Kopiervorgang bezieht sich nur auf Kontensalden, nicht auf Positionssalden, weil diese sich automatisch berechnen.
Durch Aktionen im Aktionsmenü (Submenü "Aktualisieren Kontensalden") können Endbestände von Istdaten nun auf die Anfangsbestände im Forecast- und Plan-Bereich übertragen (vorgetragen) werden. Eine automatische Anpassung erfolgt aber nicht.
Kontensalden können für die einzelnen Bereiche Ist, Forecast und Plan aus den Kontensalden der Anwendung KTOSAL nachgeladen werden.
Die Planungsanwendung basiert auf einer Verwaltung von Szenarien. Ein Szenario ist die Zusammenfassung aller Parameter für ein Planungsformular. Diese setzen sich zusammen aus den Randparametern für verwendete Datenarten und Perioden, Anfangs- und Endbestände, sowie Regeln und Veränderungen auf Konten innerhalb einer Periode.
Um den Benutzer eine Übersicht über alle aktuell im System existierenden Szenarien zu ermöglichen, müssen die Szenarien über den Namen und die Kurzbeschreibung in einer dafür vorgesehenen Liste visualisiert werden.
Ein neues Szenario kann über rechte Maustaste "Neues Szenario", Icon "Neues Szenario", Aktion -> Neues Szenario erstellt werden. Der geführte Dialog (Assistent) zum Erstellen eines Szenarios wird entsprechend durch eine dieser Aktionen aufgerufen.
Ein Szenario kann über Doppelklick, über rechte Maustaste "Laden", Icon "Laden", Drücken von <Enter> oder Aktion "Szenario laden" aktiviert werden. Ein aktiviertes Szenario wird mit einem Pfeil gekennzeichnet.
Ein Szenario kann über <Entf>-Taste, rechte Maustaste "Löschen", Icon "Löschen" oder Aktion "Aktuelles Szenario löschen" auch wieder gelöscht werden.
Die Regel-Anzeige wurde überarbeitet. Alle Regeln auf einem selektierten Konto werden in einer Baumstruktur übersichtlich dargestellt. Dadurch ist es möglich, die Anzeige auf genau eine Regel oder Komponenten dieser Regel einzuschränken.
Die geführten Dialoge (Assistenten) zum Erstellen von Regeln wurden vereinheitlicht und erweitert. Der Dialog besteht nun aus 2 Seiten.
Die Umsatzregel wurde folgenderweise erweitert:
Ein neuer Regeltyp für Personalaufwand wurde eingeführt. Der zugehörige geführte Dialog fragt die zugeordneten Konten für ab. Dieser Dialog kann über ein neues Symbol in der Titelzeile des Regelbereichs oder über das Aktionsmenü gestartet werden.
Ein neuer Regeltyp für Rückstellungen wurde eingeführt. Der zugehörige geführte Dialog fragt die zugeordneten Konten für Aufwand und Rückstellungen ab. Dieser Dialog kann über ein neues Symbol in der Titelzeile des Regelbereichs oder über das Aktionsmenü gestartet werden.
Ein neuer Regeltyp für Investitionen wurde eingeführt. Die Anschaffung kann dabei als Anlagen an Kasse oder als Anlagen an Verbindlichkeiten spezifiziert werden. Sowohl für die Abschreibungen als auch für die Verzinsung und Tilgung können Laufzeiten sowie zugehörige Konten angegeben werden. Aufgrund dieser Angaben werden auch für die Folgeperioden Buchungen vorgenommen.
Es können jetzt Regeln definiert werden, die periodenübergreifend wirken. Dies gilt insbesondere für allgemeine Regeln, so kann z.B. die Begleichung einer Forderung mit Bezug auf die Forderung in der Vorperiode definiert werden.
Die Definition einer Regel als Zuweisungsregel bedeutet, dass diese Regel immer den auf der linken Seite angegebenen Wert aus den auf der rechten Seite angegebenen Werten errechnet. Der Wert der linken Seite darf nicht verändert werden.
Zur Anzeige aller Regeln, die auf eine Zelle wirken, wurde eine neue Regelübersicht erstellt. Der neue Regelviewer weist ein zweigeteiltes Fenster auf: Im linken Teil wird eine geordnete Kurzübersicht aller Regeln der selektierten Zelle angezeigt, in welcher jede Regel durch eine einzige Textzeile dargestellt wird. Der Benutzer kann hier eine oder mehrere Regeln auswählen, zu welchen dann im rechten Teil detailliertere Informationen angezeigt werden.
Alle definierten Regeln können jetzt auch als Vorlage ("Regel-Template") für andere Szenarien gespeichert werden. Regel-Templates sind daher unabhängig von Szenarien, Gesellschaften oder Geschäftsbereichen.
Das Speichern von Regel-Templates erfolgt im jeweiligen Regel-Assistenten beim Editieren von Regeln. Dabei ist es auch möglich, unvollständig definierte Regeln als Regel-Template zu speichern, die dann noch zur echten Anwendung vervollständigt werden müssen, z.B. wenn sich verschiedene Regeln nur durch einzelne Konten oder Faktoren (z.B. landesspezifischer Steuersatz) unterscheiden. Auch bereits angewandte Regeln können als Regel-Template gespeichert werden.
Umgekehrt können in einem Szenario die hinterlegten Regel-Templates angewandt, d.h. zu Regeln gemacht werden (Aktion "Template anwenden"), sofern das Template vollständig gefüllt ist. Fehlen dagegen noch Angaben, kann das Regeltemplate durch die Aktion "im Assistent öffnen" in einen Regel-Assistenten geladen werden, um die fehlenden Angaben zu ergänzen.
Regel-Templates lassen sich zu Template-Gruppen (Template-Sets) zusammenfassen. Dies dient vor zum Einen der besseren Übersichtlichkeit, zum Anderen können so alle Regel-Templates eines Template-Sets in einem Rutsch auf ein Szenario angewandt werden. Die Darstellung im Template-Manager erfolgt in Baumstruktur.
Regel-Templates können auch wieder gelöscht werden, sofern der Benutzer über die entsprechende Berechtigung verfügt.
Kontensalden und Veränderungen auf einem Konto können nun wahlweise in einer T-Konten-Ansicht oder als einfache Liste angezeigt werden.
Die Betextungen zu den Kontoveränderungen wurden überarbeitet.
Stammen Veränderungen auf einem Konto aus einer Regel, so kann direkt in der Kontenansicht ein Wert angepasst werden. Die betroffenen Regeln rechnen sich automatisch durch.
Es ist jetzt möglich, ausgewählte Werte als Säulendiagramm anzeigen zu lassen. Dazu muss der Anwender zunächst eine Reihe von Zellen (horizontal, vertikal oder beliebig) mit der Maus selektieren und dann die Aktion "Säulendiagramm" aus dem Aktionsmenü wählen. Die selektierten Werte werden dann in einem eigenen Bereich des Anwendungsfensters als Säulendiagramm angezeigt. Die Säulen sind je nach Art der Selektion mit den Kurztexten der Positionen, Konten oder Perioden beschriftet. Dieser Bereich kann analog anderen Bereichen auf der Oberfläche positioniert oder in den Rand verschoben werden.
Die Säulendiagramme können auch zur Eingabe von Planwerten verwendet werden, indem die Säulenhöhe mit der Maus verändert wird.
Das Attribut "Reporttyp" im Stammsatz für Report-Idents (RID) enthält jetzt für alle Spiegel-Reports einheitlich den neuen Wert 'D' (Spiegel). Die Information, um welchen Spiegel es sich handelt, wurde in ein neues Attribut "Spiegel" mit Verweis auf die neue Tabelle SPI (s.o.) verlagert.
Das Attribut "Spiegelspalte" wurde in den Reportzeilenbeschreibungen (REPZEI) durch ein gleichnamiges Attribut mit Verweis auf die neue Tabelle SSP ersetzt (s.o.).
Der Report-Kopfsatz (REP, REPK) wurde um die folgenden Attribute (s.o.) erweitert, die die Druckausgabe steuern, sofern im Druckdialog keine abweichenden Angaben erfolgen. In der Übersichten (REP, REPK) werden diese Attribute angezeigt und in der Einzelsatzanwendung (REPE) können sie eingegeben werden.
Die Texte der Report-Id und des Report-Kopfsatzes können jetzt mit Platzhaltern versehen werden (s.o.), die beim Ausdrucken durch entsprechende Schlüssel oder Bezeichnungen ersetzt werden.
Die Übersichten für Report-Kopfsätze (REP und REPK) ermöglichen jetzt eine Selektion nach Meldung. Hierfür wurden zwei Eingabefelder, Projekt ('IAR' bzw. 'KON') und vierstellige Meldungsnummer, ergänzt. Teilqualifizierte Eingaben (Verwendung von '%' und '_') sind möglich. Um alle mit einer Meldung versehenen Report-Kopfsätze zu selektieren, ist im ersten Eingabefeld '%' anzugeben, während die Eingabe '*' in diesem Feld für die Selektion aller Report-Kopfsätze ohne Eintrag einer Meldung sorgt.
Das bisherige Attribut "Kontokennzeichen 2" wird im Reportergebnis durch ein neues Attribut "Spiegel" ersetzt. Für bereits bestehende Reports wird in dieser Spalte weiter das bisherige "Kontokennzeichen 2" angezeigt.
Konzernreports (Bilanz, GuV, Kapitalfluss, Spiegel) werden jetzt mit einer Meldung versehen, wenn sie gleichzeitig Konsolidierungsbuchungen von freigegebenen und von nicht freigegebenen Belegen enthalten (zur Freigabe von Konsolidierungsbelegen s.o.).
Controlling-Reports (Report-Typ 'C' oder Report-Option 'C', 'D' oder 'Y') verarbeiten jetzt auch Kontensalden, wenn die Reportstruktur Konten ohne Controllingaufriss enthält. Für den Aufriss nach Controllingobjekten wurde ein Dummy-Controllingobjekt '******NOCO' eingeführt, unter dem alle Werte aus Kontensalden geführt werden. Beim Reporttyp 'C' (UKV-Report) wird bei Konten ohne Controllingaufriss nur die Saldenspalte mit Werten gefüllt. Die Fehlermeldung KON01030 (Es sind für diesen Report Buchungen ohne Controllingobjekt vorhanden) wird nur noch angezeigt, wenn es Konsolidierungsbuchungen ohne Controllingobjekt auf Controllingkonten gibt. Die Differenzprüfung (Zeilentyp 'S', Wert-Knz '2') ist für Controllingreports außer Reporttyp 'C' wieder aktiviert. Die Fehlermeldung "Keine Daten vorhanden" wird nur noch dann ausgegeben, wenn weder Controllingsalden noch Kontensalden für den Report verarbeitet wurden. Wurden nur Kontensalden verarbeitet, erscheint jetzt die neue Hinweismeldung "Keine Controllingsalden vorhanden".
Die Konsolidierungsbuchungen der neuen Konsolidierungsverarbeitungen 'FK', 'F0', ... 'F9' (Erstkonsolidierung Fremdanteil Eigenkapital) und 'FK' (Fortschreibung Fremdanteile) (s.o.) werden im Konsolidierungsreport der Spalte "Fremdanteile" zugeordnet.
Das Attribut "Reporttyp" im Stammsatz für Spaltenoptionen (SPO) enthält jetzt für alle Spiegel-Reports einheitlich den neuen Wert 'D' (Spiegel). Die Information, um welchen Spiegel es sich handelt, wurde in ein neues Attribut "Spiegel" mit Verweis auf die neue Tabelle SPI (s.o.) verlagert.
Da alle Spiegeldefinitionen jetzt individuell erfolgen (s.o.), müssen auch die Spaltenoptionen zur Anzeige von Spiegel-Reports individuell gepflegt werden. Die bisherigen Standard-Spaltenoptionen (SPO) für Spiegel-Reports beginnend mit '#' (z.B. '#ANLG', '#KAPK') werden einschließlich ihrer Spaltenbezeichnungen (SPA) und Formeln (FED) sowie ihrer Verwendung als Default-Spaltenoption in den Report-Kopfsätzen (REP) durch die Release-Konvertierung in individuelle Spaltenoptionen umgesetzt, indem das '#' durch ein '$' ersetzt wird. Gibt es bereits eine Spaltenoption mit dem neuen Namen, wird eine Spaltenoption mit einem anderen Sonderzeichen an der ersten Stelle des Namens angelegt.
Zu den Spaltenoptionen mit Spalten zur Darstellung relativer Abweichungen (#ALTD, #BUCD, #KOND, #KTKD, #NEUD und #SUMD) gibt es jetzt jeweils eine weitere Spaltenoption mit Suffix 'G' (z.B. #ALTDG), in der die in der originalen Spaltenoption errechnete relative Abweichung in Prozent als Balkendiagramm ausgegeben wird.
Es ist jetzt möglich, die Formatierung von Reportspalten vorzugeben (s.o.). Die Definition der Attribute erfolgt dabei in der Anwendung "Report-Spaltenbezeichnungen" (SPA). Die Einzelsatzanwendung "Report-Spaltenbezeichnung" (SPAE) wurde um entsprechende Eingabefelder erweitert.
Für Reportspalten sind Schriftschnitt (fett, kursiv), Schriftgrad (Größe), Vordergrundfarbe, Hintergrundfarbe sowie eine Trennlinie zwischen den Spalten (d. h. vor jeder Wertspalte) individuell einstellbar. Eine Trennlinie vor der Schlüsselspalte wird ggf. automatisch ergänzt. Für die Farben steht ein spezieller Farbdialog mit verschiedenen Eingabevarianten zur Verfügung. Der Schriftschnitt "normal" dient dazu, eine Standardformatierung mit fetter oder kursiver Schrift zu überlagern.
Des Weiteren können Spalten definiert werden, die die enthaltenen Werte in Form eines Balkendiagramms darstellen. Die Skalierung erfolgt dabei relativ zum Maximalwert. Dazu ist in der Report-Spaltenbezeichnung (SPAE) das neue Eingabefeld "Grafik Typ" auf den Wer 'B' zu setzen. Über das neue Eingabefeld "Wertanzeige" kann gesteuert werden, ob die Spalte nur die Grafik (Eingabe leer) oder diese zusammen mit dem Wert anzeigen soll. Hierfür sind verschiedene Varianten (kompletter Wert, ohne Nachkommastellen, Wert in 1.000 oder 1.000.000) verfügbar. Durch Angabe im Feld "Druckbreite" kann die Breite der Spalte in mm im Druckbild vergrößert werden, falls die automatisch ermittelte Minimalbreite nicht genügt.
Die Übersicht "Positionssalden" (POSSAL) dient jetzt auch als Aufrufanwendung für den XBRL-Export. Ein entsprechender Menüpunkt wurde im Aktionsmenü ergänzt.
XBRL ist ein internationaler Standard zur Weitergabe von Geschäftsergebnissen. Als XML-Format sind die erzeugten XBRL-Instanzdateien nicht direkt lesbar, sondern können nur durch geeignete Software ausgewertet und angezeigt werden.
Innerhalb des allgemeinen XBRL-Standards gibt es verschiedene Taxonomien für verschiedene Rechnungslegungsarten (IFRS, HGB, US-GAAP etc.), die wiederum ständigen Änderungen und Erweiterungen unterliegen. Jede Taxonomie besteht aus einer xml-Definition (xsd), die wiederum die Fachbegriffe, denen dann Werte zuzuordnen sind, als sogenannte Concepts enthält.
Die Verbindung zwischen den in IDL.KONSIS.FORECAST geführten Daten und den XBRL-Taxonomien wird über den Positionsstamm (POS) hergestellt. Dort kann zu jeder Position ein XBRL-Concept eingetragen werden. Sollen XBRL-Dateien für verschiedene Rechnungslegungsarten erstellt werden, so ist je Rechnungslegungsart ein eigener Positionsplan zu definieren.
Die Werte für den XBRL-Export werden der Tabelle für Positionssalden entnommen. Für den XBRL-Export ist es daher Voraussetzung, dass zuvor ein Report erstellt wurde, für den die Erzeugung von Positionssalden spezifiziert wurde (Reportoption = 'S' oder 'P'), so dass die Positionssaldentabelle Werte enthält.
Dies kann sowohl ein Konzernreport als auch ein Gesellschaftsreport sein, da XBRL-Instanzdateien für beide Ebenen möglich sind. Die Identifikation dieses Schlüssels erfolgt in der XBRL-Instanzdatei über eine URL (Internet-Adresse). Zu diesem Zweck wurden sowohl der Konzern/Teilkonzern-Stamm (KTK) als auch der Gesellschaftsstamm (GES) um ein Attribut "URL" erweitert, das für den Zweck des XBRL-Exports gepflegt sein muss.
Die Erzeugung einer XBRL-Instanzdatei wird aus der Übersicht "Positionssalden" (POSSAL) heraus durch die neue Aktion "XBRL-Export" angestoßen. Voraussetzung ist eine eindeutige Vorgabe der Schlüssel Konzern/Tk (ggf. '*' wenn leer), Gesellschaft, Geschäftsbereich (ggf. '*' wenn leer) und Positionsplan im POSSAL-Selektionsbereich. Periode und Datenart müssen ohnehin eindeutig angegeben werden. Weitere Einschränkungen (z.B. nach Positionsnummer, Herkunftsreport oder Bilanz/GuV-Kennzeichen haben dagegen keinen Einfluss. Name und Pfad der zu erzeugenden Datei werden über einen Dateidialog abgefragt. Alles Weitere erfolgt dann automatisch.
Geplant ist, mit einem der nächsten Releases folgende XBRL-Taxonomien weitergehend zu unterstützen, indem die Zuordnung der Concepts zu den IDL.KONSIS.FORECAST-Positionen über einen Zuordnungsdialog erfasst werden kann:
Die Import/Export-Formatdefinitionen für Spiegelbewegungen, Buchungen und Konsolidierungsbuchungen enthalten (historisch gewachsen) bis zu drei verschiedene Eingabefelder für Buchungsschlüssel: das ursprüngliche dreistellige (einstelliger Spiegel + zweistellige BSL-Nummer) Feld ...-K037-BSL, ein für die Umsetzung in der SAP-Schnittstelle (dreistellige Bewegungsartengruppen) erweitertes vierstelliges Feld ...-K037-BSLEG sowie ein mit diesem Release neues 20-stelliges (6-stelliger Spiegel + 14-stellige BSL-Nummer) Feld für die ermöglichten Verlängerungen. Diese Felder können in folgender Form benutzt werden:
Spiegelbewegungen mit reservierten Buchungsschlüsseln (z.B. automatischer Vortrag, Kurseffekte) können jetzt importiert werden, wenn diese Daten durch einen Export aus IDL.KONSIS.FORECAST heraus erzeugt wurden, so dass ein IDL.KONSIS.FORECAST-zu-IDL.KONSIS.FORECAST-Datentransfer möglich ist. Daten aus externen Quellen (z.B. Schnittstellen zu Buchhaltungssystemen) dürfen jedoch weiterhin keine reservierten Buchungsschlüssel enthalten.
Die Möglichkeit zum Import von Daten ohne Dateien im Dateisystem durch temporäres Schreiben der Daten in eine spezielle Datenbanktabelle (s. Neu im Release 2008.1) wurde erweitert für den Import folgender Datenbestände:
Die Übersicht "IE Job-Steuerung" (IEJOB) zeigt jetzt die Jobs immer absteigend sortiert nach der Job-Nummer an. Im Aktionsmenü ist der Menüpunkt "Löschen Daten + Neu-Import" entfallen, weil der Verarbeitungsmodus (mit oder ohne Löschen) bereits im Job selbst festgelegt ist.
In der Anwendung "IE Job-Steuerung" (IEJOBE) kann das Startdatum "Import ab" gelöscht werden, um zu definieren, dass der Job sofort gestartet werden kann.
Es ist möglich, die Daten eines Jobs in einen dabei neu erstellten zu kopieren. Dabei kann sofern vorhanden ausgewählt werden, ob nur die als fehlerhaft markierten Datensätze kopiert werden sollen.
Die Verwendung von Umsetzgruppen für Buchungsschlüssel wird dadurch übersichtlicher gestaltet, dass jetzt zwei getrennte Eingabefelder für den Spiegel und den eigentlichen Buchungsschlüssel zur Verfügung gestellt werden. In der Übersicht "Umsetzgruppen-Zuordnungen" (UMSOBJ) muss daher vor Verzweigung in die Einzelsatzanwendung der Objekttyp eindeutig vorgegeben werden.
Es gibt neue Importprogramme zum Import von Daten für die neuen Tabellen zur Definition von Spiegeln (SPI), Spiegelspalten (SSP) und Spiegelbereichen (SBE) (s.o.). Die zugehörigen Standardformate können in der Übersicht "Import/Export Format Ident" (IEF) und deren Folgeanwendungen "Felder für Import/Export-Formate" (IEFDEF) und "Zuordnung Import-Felder zu Formaten" (IEFFEL) zu den Import/Export-Objekten SPI, SSP bzw. SBE eingesehen werden. In der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) wurde der Aufruf dieser Anwendungen im Zweig "Import Stammdaten" ergänzt. Diese Anwendungen können u.a. dazu benutzt werden die von IDL im Verzeichnis "LieferBatch" der Auslieferungs-CDs zur Verfügung gestellten Musterdefinitionen für Spiegel zu importieren.
Es gibt neue Importprogramme zum Import von Controllingobjekt-Hierarchiezuordnungen (CNTCNT) und Geschäftsbereich-Hierarchiezuordnungen (UBRUBR). Die zugehörigen Standardformate können in der Übersicht "Import/Export Format Ident" (IEF) und deren Folgeanwendungen "Felder für Import/Export-Formate" (IEFDEF) und "Zuordnung Import-Felder zu Formaten" (IEFFEL) zu den Import/Export-Objekten CNTCNT bzw. UBRUBR eingesehen werden. In der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) wurde der Aufruf dieser Anwendungen im Zweig "Import Stammdaten" ergänzt.
Ein weiteres neues Importprogramm ermöglicht die Übernahme von Bezeichnungstexten unabhängig von den jeweiligen Stammobjekten. Auf diesem Wege kann z.B. die außerhalb von IDL.KONSIS.FORECAST erfolgte Übersetzung der Kontenbezeichnungen eines Kontenplans übernommen werden. Das zugehörige Standardformat kann in der Übersicht "Import/Export Format Ident" (IEF) und deren Folgeanwendungen "Felder für Import/Export-Formate" (IEFDEF) und "Zuordnung Import-Felder zu Formaten" (IEFFEL) zum Import/Export-Objekt TXT eingesehen werden. Dieses Format ist auf die in der Datenbank mögliche Maximallänge der Texte ausgelegt, die aber von den Anwendungen gar nicht unterstützt wird. Für die praktische Arbeit wird daher die Verwendung individueller Import/Export-Formate empfohlen. In der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) wurde der Aufruf dieser Anwendung im Zweig "Import Sonstiges" ergänzt.
Das Importformat für die Spaltenbezeichnungen wurde um die neuen Attribute zur Spaltenformatierung (s.o.) erweitert. Schrift- und Hintergrundfarbe müssen hier allerdings als nummerische RGB-Werte angegeben werden. Dasselbe gilt für den Export von Spaltenbezeichnungen.
Wegen umfangreicher Umstrukturierungen der Datenbank sind die Datenaustauschformate des Releases 2009.0 und älterer Releases nicht miteinander kompatibel. Es ist erforderlich, dass sowohl die entladene als auch die ladende Installation den Stand 2009.0 haben. Dies betrifft sowohl den konzernweiten als auch den Teilkonzern-Datenaustausch.
Als Altlast des früheren Betriebssystems DOS sind auch in einigen Windows-Versionen bestimmte Dateinamen reserviert und daher nicht frei verfügbar. So führte z.B. der Versuch, eine Datei namens "CON.L_E" für das Entladen von Teilkonzerndaten des Teilkonzerns 'CON' zu erzeugen, zu einer Fehlermeldung betreffs unerlaubten Dateizugriffs. Analog den Dateinamen für den konzernweiten Datenaustausch (Präfix 'K_' vor dem Schlüssel des Konzerns) und den Gesellschafts-Datenaustausch (Präfix 'G_' vor dem Schlüssel der Gesellschaft) werden daher jetzt auch die Dateinamen für den Teilkonzern-Datenaustausch aus einem Präfix ('T_') und dem Schlüssel des Teilkonzerns zusammengesetzt.
Die neuen Tabellen (s.o.) für Spiegel (SPI), Spiegelspalten (SSP), Spiegelbereiche (SBE), Perioden/Spiegel (ABRSPI) und Datenarten/Spiegel (FACSPI) wurden im konzernweiten Datenaustausch ergänzt.
Die Protokollausgabe (Log-Dateien) der Anwendungen zum Datenaustausch wurde überarbeitet, so dass die Informationen jetzt weniger technisch enthalten sind.
Neu wird jetzt beim Entladen auch die Nummer des aktuellen IDL.KONSIS.FORECAST-Releases in das Protokoll geschrieben, so dass vor dem Laden geprüft werden kann, ob eine Datenübernahme problemlos möglich ist.
Die Felderweiterungen aus IDL.KONSIS.FORECAST wurden weitestgehend mit in den IDLCONNECTOR übernommen. Die neuen Spiegelkennungen wurden sowohl bei den Lesefunktionen, als auch bei den Exportformaten integriert.
Im IDLCONNECTOR-Erfassungsformular wurde sowohl die veränderte Logik des Ergebnisvortrages, als auch die Erweiterungen für die Spiegel und Buchungsschlüssel berücksichtigt.
Im MIS-Parameter (MISPAR) können jetzt 8 statt bisher 4 Konzerne/Teilkonzerne angegeben werden. Die zusätzlichen Konzerne/Teilkonzerne werden analog zu den bisherigen 4 verarbeitet.
SAP-Schnittstelle mit Funktionsbausteinen (kcusap.dll)
Die SAP Schnittstelle ist für die Anmeldung am SAP-System jetzt auch in der Lage, eine Anmeldung am Message Server mit Load Balancing durchzuführen.
Die SAP-Schnittstelle wurde um eine Unicode-fähige Variante "kcusapu.exe" ergänzt, damit auch Bezeichnungen, die Zeichen außerhalb des westeuropäischen Standard-Zeichensatzes enthalten, korrekt übernommen werden können.
SAP-Schnittstelle mit IDL.IMPORTER
Die Verbindungsdaten für die Anmeldung am SAP-System wurden bisher immer der Datei kcusap.ini entnommen. Diese musste ggf. auf dem Client und auf dem Schnittstellenserver vorhanden sein und synchron gehalten werden. Künftig können die Verbindungsdaten zentral in der IDL.KONSIS.FORECAST-Datenbank abgelegt werden, wenn dieser Modus durch den Eintrag
UseK9xxx=yes
im Abschnitt [Connection] der Datei kcusap.ini spezifiziert wurde. Ohne diesen Eintrag verbleibt die Steuerung im Datei-Modus.
Um Daten für mehrere Gesellschaften auf einmal aus SAP zu entladen, musste eine Liste von Buchungskreisen in einer Datei CompanyCodes.txt auf dem Server angelegt werden. Diese Datei kann jetzt ersetzt werden durch ein Skript im IMD-File, welches anhand der vom Modul kcusap.jar übergebenen Parameter sGroup, sExFaxt, iPeriodTo und sUmsGrp die Liste der auszulesenden Buchungskreisen aus den in IDL.KONSIS.FORECAST definierten Konzern-/Teilkonzernkreisen erstellt.
Die Skripte der im Einsatz befindlichen Jobs können dahingehend modifiziert werden, dass sämtliche Schreib-Operationen nicht mehr jeweils Dateien zum Ziel haben, sondern eine DB-Tabelle als Ziel nennen können. Damit kann das mit Release 2008.1 eingeführte und mit diesem Release erweiterte Verfahren zum Import über temporäre Daten in DB-Tabellen auch für die SAP-Schnittstelle genutzt werden. Dazu muss die Einrichtung der ODBC-Datenquelle zur IDL.KONSIS.FORECAST-DB für den Schnittstellenserver vorgenommen werden.
Die IC-Gesellschaft von Anlagenbewegungen wird jetzt aus der Übergabestruktur in die Zieldatei/Tabelle übertragen. Hinweis: Das in diesem Zusammenhang verwendete Skript muss modifiziert werden, um die IC-Gesellschaft in der Übergabestruktur bereitzustellen.
Mit diesem Release werden folgende deutschsprachigen Dokumentationen im doku-Verzeichnis aktualisiert oder ergänzt: