Das Release 2012.0 umfasst Änderungen und Erweiterungen für die Produkte IDL Konsis, IDL Forecast und IDL Connector sowie erstmalig die Auslieferung der Software des Produkts IDL Publisher.
Das Release IDL Konsis 2012.0 ist ein Hauptrelease und darf daher in der Releasefolge nicht ausgelassen werden. Mindestvoraussetzung für dieses Release ist das letzte Hauptrelease IDL Konsis 2011.0 vom 8. 8. 2011.
Die bis zum Release-Abschluss erfolgten Nachträge und Korrekturen zum Hauptrelease IDL Konsis 2011.0 sowie zum folgenden Zwischenrelease IDL Konsis 2011.1 sind in diesem Hauptrelease enthalten.
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 vom Installationsprogramm vor der Installation ausgegeben.
Angesichts der ständig größer werdenden Anzahl neuer IDL Konsis-Anwendungen, die den Zugriff auf die Datenbank mittels JDBC vornehmen (z.B. "Konzernstruktur (Diagramm)" (KTKGRAPH), "Reportdefinition" (REPDEF, s.u.), IDL Workflow (s.u.)), ist die Arbeit mit IDL Konsis ohne JDBC-Verbindung zur Datenbank kaum noch sinnvoll möglich. Die Konfiguration einer JDBC-Verbindung ist daher künftig obligatorisch.
Wenn noch keine JDBC-Verbindung aktiviert ist, so wird jetzt bei der Anmeldung automatisch die Seite <Optionen> geöffnet und dort die Checkbox "JDBC-Treiber aktivieren" automatisch gesetzt. Falls die JDBC-Verbindung nicht sofort konfiguriert werden kann (z.B. Treiber muss von der IT bereit gestellt werden), kann die Checkbox "JDBC-Treiber aktivieren" wieder deaktiviert werden, so dass die Anmeldung ohne JDBC-Verbindung erfolgt.
Im Anmeldefenster steht auf der "Optionen"-Seite unter der "?"-Schaltfläche auch ein Hilfetext zu dieser Konfiguration zur Verfügung. Weitere Hinweise zu diesem Thema erhalten Sie beim technischen Support der IDL.
Nach Installation eines neuen Releases muss grundsätzlich als erstes die Release-Konvertierung (s. Kap. 2.1) vorgenommen werden. Daher wird beim ersten Aufruf von IDL Konsis nach der Installation eine Meldung ausgegeben, dass die Konvertierung noch nicht erfolgt ist. Diese Meldungsbox enthält eine Schaltfläche <Konvertierung jetzt starten>. Durch Betätigung dieser Schaltfläche wird die Konvertierung automatisch gestartet. Nach erfolgreicher Durchführung der Konvertierung auf diesem Wege muss IDL Konsis nicht neu gestartet werden, sondern es stehen sofort alle Anwendungen zur Verfügung.
Wird die Konvertierung nicht in dieser Form gestartet, z.B. weil dem angemeldeten Benutzer die Berechtigung fehlt, wird der Aufruf anderer Anwendungen gesperrt. Ausgenommen sind lediglich die Anwendungen zur Pflege der Berechtigungsdaten, falls der angemeldete Benutzer wegen Verwendung individueller Berechtigungsgruppen keine Berechtigung zur Ausführung der Konvertierung hat. Nach manueller Durchführung der Konvertierung muss IDL Konsis neu gestartet werden, damit wieder alle Anwendungsfunktionen zur Verfügung stehen.
Die bis zum Release IDL Konsis 2007.1 verwendeten Konzernbewegungen (redundanter Datenbestand zu den Konsolidierungsbuchungen in den Tabellen für Spiegelbewegungen) sind mit den Standard-IDL-Berechtigungsgruppen nicht mehr verfügbar, da die Berechtigung für die zugehörigen Menüpunkte (KONANLBEW, KONKAPBEW, KONRUEBEW) entzogen wurde. Bei Bedarf muss nach Installation des Releases 2012.0 die Berechtigung über individuelle Berechtigungsgruppen wieder vergeben werden.
Die Anwendung IDL Forecast erfordert einen Hauptspeicherbedarf von 1 GB. Häufig sind jedoch nur 256 MB oder 512 MB eingestellt. Bitte überprüfen Sie daher ggf. Ihre Einstellungen zum Parameter "-Xmx" in der Verknüpfung Ihres IDL Konsis-Icons. Beim Start der Anwendung IDL Forecast (PLAN) wird bei geringerer Speicherzuweisung ein entsprechender Hinweis ausgegeben.
Die erfahrungsgemäß selten genutzte html-Hilfe ist seit dem Release 2010.1 nicht mehr auf der Release-CD bzw. in dem zum Download bereit gestellten Installationsverzeichnis enthalten. Sie kann aber bei Bedarf bei der IDL-Hotline angefordert oder vom Service-Bereich der IDL-Web-Seite heruntergeladen werden. Die in der html-Hilfe enthaltenen Hilfetexte sind aber weiterhin wie gewohnt online in der Anwendung verfügbar.
Die mit dem Release 2012.0 erstmalig ausgelieferte erste Fassung des neuen IDL Connector für die Excel-Anbindung von IDL Konsis (s.u.) setzt mindestens die Version MS Excel 2003 voraus.
Für die SAP-Anbindung wird mit diesem Release ein neuer einheitlicher Standard (pluginlauncher.jar mit IDL Importer) sowohl für das alte als auch für das neue Hauptbuch ausgeliefert. Dieser ersetzt mittelfristig die bisherigen Schnittstellen (kcusap.jar mit IDL Importer und kcusap.exe mit Funktionsbausteinen). Die bisherigen Schnittstellen werden ab dem Release 2014.0 nicht mehr unterstützt. Bitte stellen Sie Ihre Schnittstelle mit Unterstützung durch Ihren IDL-BI-Berater bis dahin auf den neuen Standard um. Fragen dazu beantwortet Ihnen Ihr IDL-BI-Berater oder der technische Support der IDL.
Beim ersten Aufruf von IDL Konsis nach der Installation wird eine Meldung ausgegeben, dass die Konvertierung noch nicht erfolgt ist. Diese Meldungsbox enthält eine Schaltfläche <Konvertierung jetzt starten>. Durch Betätigung dieser Schaltfläche wird die Konvertierung automatisch gestartet.
Das Konvertierprogramm nimmt folgende Umsetzungen in der Datenbank zusätzlich zur Konvertierung für das Zwischenrelease 2011.1 vor:
Folgende Menü-IDs sind in diesem Release neu oder mit neuen berechtigten Aktionen versehen worden. 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.
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 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.
Die folgenden Menüpunkte aus IDL Forecast werden künftig nicht mehr verwendet, so dass keine separaten Berechtigungen mehr gepflegt werden können. Ggf. bereits erteilte Berechtigungen für diese Menüpunkte werden bei der Release-Installation automatisch entfernt:
Die Menübäume (Ressourcenbaum und Schnellstarter) von IDL Konsis und IDL Winkons wurden in Bezug auf die sachlogischen Zusammenhänge überarbeitet und vereinheitlicht. Folgende Änderungen gelten für beide Produkte:
Folgende Änderungen betreffen IDL Konsis:
Folgende Änderungen betreffen IDL Winkons:
Es gibt jetzt die Möglichkeit, die Benutzerverwaltung komplett in IDL Konsis vorzunehmen. Bisher mussten die Benutzer immer auch in der Datenbank oder in einem Active Directory angelegt werden. Neben dem Benutzernamen kann dann auch ein Passwort in der Anwendung "Benutzer" (USEE) eingegeben werden, das dann verschlüsselt gespeichert wird. Zusätzlich können auch verschiedene Regeln für die Passwörter sowie eine maximale Gültigkeitsdauer festgelegt werden.
Die eigentliche Anmeldung an der Datenbank erfolgt bei diesem Verfahren ausschließlich mit einem nur dem Programm bekannten internen Benutzer, bevor die eingegebenen Anmeldedaten mit den Einträgen in der Benutzertabelle verglichen werden. Anmeldungen mit Werkzeugen außerhalb von IDL Konsis haben dann keinen Zugriff mehr auf die Datenbank mit Ausnahme des Administrator-Benutzers.
Dieses Anmeldeverfahren wird über spezielle Einträge in der ini-Datei der Benutzer gesteuert. Ohne diese Einträge sind auch die zusätzlichen Eingabemöglichkeiten in USEE nicht sichtbar.
Bitte wenden Sie sich an den technischen Support der IDL, wenn Sie dieses Verfahren nutzen wollen.
Für die Tabelle der Verarbeitungssteuerungen (VERARB) wurde eine Änderungsprotokollierung eingebaut. Im Gegensatz zur sonstigen Änderungsprotokollierung erfolgt diese unabhängig von der Lizenz und ist grundsätzlich immer aktiviert. Die Protokolltabelle wird bei der Installation des Release 2012.0 mit dem aktuellen Stand der Tabelle VERARB initialisiert.
Die Tabelle der Verarbeitungssteuerungen enthält einen Datensatz für einen Datenbestand (z.B. Kontensalden, Spiegelbewegungen eines Spiegels) je Gesellschaft, Geschäftsbereich, Periode und Datenart. Sofern Prüfsummen, die in dieser Tabelle geführt werden, aktiviert sind, ändert sich der Verarbeitungssteuerungssatz bei jeder Änderung der Daten. Dabei werden die Angaben für Zeitpunkt, Anwendung (manuelle Erfassung, Import, Vortrag, Währungsumrechnung etc.) und Benutzer festgehalten, so dass nachvollzogen werden kann, wann, vom wem und auf welche Art die Daten verändert wurden. Diese Information kann insbesondere bei der Rückverfolgung von Problemen wertvoll sein.
Dasselbe gilt auch für die Tabelle der Konzern-Verarbeitungssteuerungen (KVERARB). Hier ist die Aussagekraft allerdings eingeschränkt, da die Mehrzahl der Konzernverarbeitungen nicht in dieser Tabelle geführt wird.
Zur Ansicht dieser Daten gibt es die Übersichten "Verarbeitungssteuerung-Änderungen" (VERARBLOG) und "KTk-Verarbeitungssteuerung-Änderungen" (KVERARBLOG) mit entsprechenden Selektions- und Filtermöglichkeiten.
Die Größe von zwei Fenstern des Anwendungsbereichs kann durch Ziehen der Grenzlinie mit der Maus verändert werden. Durch einen Doppelklick mit der Maus auf die Grenzlinie kann jetzt die ursprüngliche Größe der Fenster wieder hergestellt werden.
Im Optionsdialog <Farben> kann jetzt eine Fokusfarbe definiert werden. Diese Farbe kennzeichnet in der IDL Konsis-Oberfläche das Fenster, das gerade den Fokus besitzt, also in dem Tastatureingaben wirken. Die Farbe wird in der Lasche der Registerkarte angezeigt. Diese Einstellung wirkt erst nach einem Neustart von IDL Konsis und setzt die Aktivierung des Merkmals "Farbverlauf" im Optionsdialog <Grafik> voraus.
Eine Reihe von Anwendungen (z.B. "IDL Forecast" (PLAN), "Spiegeldefinitionen" (SPIDEF), "Konzernstruktur (Diagramm)" (KTKGRAPH)) setzt die Aktivierung des Merkmals "Moderne Oberfläche / Registerkarten" im Optionsdialog <Grafik> voraus. Da das Arbeiten mit IDL Konsis ohne diese Option erheblich eingeschränkt wird, wird diese Option jetzt standardmäßig aktiviert und lässt sich nicht mehr über den Optionsdialog abschalten.
Durch die seit dem Release 2011.0 neuen Möglichkeiten durch die Nutzung der Filterzeile ist eine Reihe von Eingabemöglichkeiten in den Selektionsbereichen der verschiedenen Übersichtsanwendungen nicht mehr erforderlich und wurde zugunsten einer verbesserten Übersichtlichkeit entfernt. Dies betrifft Übersichten sowohl für Stamm- und Steuerungsdaten als auch für die Berichtsdaten. Beispiele:
Die Reduktion der Anzahl der Eingabemöglichkeiten wurde auch dazu genutzt, einige bisher nicht bezeichnete Eingabefelder mit einem Text zu versehen (z.B. Vor-/Vergleichsdatenart im Einzelabschluss-Monitor (EA)).
Die Aktion "Mengenändern" steht jetzt in fast allen Übersichten zur Verfügung und es sind alle Attribute änderbar, die auch in der Einzelsatzanwendung geändert werden können. Sofern ein '*' nicht als Inhalt eines Feldes zugelassen ist (wie z.B. bei Bezeichnungen), sorgt die Eingabe '*' für das Löschen des entsprechenden Feldinhalts.
Für die Aktion "Detailansicht" wurde ein eigenes Symbol definiert. Dieses wird jetzt in der Symbolleiste aller Anwendungen, in denen diese Aktion verwendet wird, angezeigt.
Die bisherige Beschränkung auf maximal 65.000 Zeilen beim Export einer Tabelle nach MS Excel ist entfallen.
Des Weiteren kann der Anwender durch Angabe des entsprechenden Suffix des Dateinamens jetzt entscheiden, ob eine neue Excel-Datei im MS-Office-2003-Format (Suffix ".xls") oder im MS-Office-2007-Format (Suffix ".xslx") erstellt werden soll.
Der Anwender wird auch befragt, wenn eine bestehende Datei überschrieben werden würde.
Viele Funktionen von IDL Konsis beziehen sich auf das im Periodenstamm (ABR) angegebene Periodenkennzeichen. Die falsche Vergabe dieses Kennzeichens, insbesondere des Kennzeichens 'J' (Jahresabschluss), kann zu falschen Werten führen. Daher wird jetzt eine Warnung ausgegeben, wenn das Kennzeichen 'J' vergeben wird, ohne dass der Abstand zur vorherigen sowie zur nächsten Jahresabschlussperiode 12 Monate beträgt. Dies darf nur in dem seltenen Fall von Rumpf-Geschäftsjahren der Fall sein.
Die Übersicht "Positionspläne" (POP) ermöglicht jetzt eine Verzweigung in die Anwendungen "Positionen+Konten-Zuordnung Drag&Drop" (Z-POSKTO) und "Positionen+XBRL-Konzept-Zuordnungen Drag&Drop" (Z-POSXBRL) für die selektierten Positionspläne.
Die Aktionen zum Speichern und Schließen eines Positionsplans (bisher in der Symbolleiste der Positionsplanliste) können jetzt durch Symbole in der globalen Symbolleiste ausgelöst werden. Ein weiteres Symbol ermöglicht es, die Positionsplanliste nach Selektion eines Positionsplans auszublenden. Letzteres ist auch über einen neuen Eintrag im Menü <Ansicht> möglich.
Eine erweiterte Unterstützung der XBRL-Funktionalität (z.B. E-Bilanz) wird ab 2013 durch den IDL Publisher zur Verfügung gestellt (s.u.).
Der Kontenstamm wurde um ein weiteres Referenzkonto "Planungsverdichtungskonto" erweitert. Diese Angabe wird ausschließlich in IDL Forecast (s.u.) ausgewertet. Sie dient der Reduzierung der Anzahl der in der Planung verwendeten Konten. In den Anwendungen zur Pflege des Kontenstamms wird zwar geprüft, dass verschiedene Attribute (Bilanz/GuV-Kennzeichen, Kontokennzeichen, Spiegel etc.) von Konto und Planungsverdichtungskonto übereinstimmen, aber im Fall von Abweichungen nur als Warnung gemeldet. Eine Vererbung von Attributen des Planungsverdichtungskontos auf die zugeordneten Konten erfolgt nicht.
Es wird jetzt zugelassen, dass ein Konto mit dem Kontokennzeichen 'W' (Ergebnisvortragskonto im Gesellschafts-Kontenplan) auf ein Konzernkonto mit Kontokennzeichen 'J' (Konto mit teilweisem IC-Aufriss) zugeordnet wird. Dies wird z.B. dann benötigt, wenn von dem Konzernkonto Dividenden ausgeschüttet werden und dieses Konto der Konsolidierungsverarbeitung 'SD' zugeordnet werden muss.
Die bisherige Beschränkung auf maximal 23 Controllingkennzeichen 1 (Funktionsbereiche) wurde aufgehoben. Allerdings ist die Definition von mehr als 23 Controllingkennzeichen (CK1) nur dann sinnvoll, wenn die Controllingkennzeichen ausschließlich zur flexiblen Zuordnung der Daten eines Kontos auf unterschiedliche Positionen (POSKTO) genutzt werden. Die Erstellung von Reports nach dem Umsatzkostenverfahren mit Darstellung der Funktionsbereiche in Spalten bleibt dagegen auf 23 Bereiche beschränkt. Werden mehr als 23 Controllingkennzeichen 1 definiert, werden alle weiteren Daten in der 23. Spalte saldiert.
Die Aktionen zum neu Erfassen, Bearbeiten, Speichern und Schließen eines Spiegels (bisher in der Symbolleiste der Spiegelliste) können jetzt durch Symbole in der globalen Symbolleiste ausgelöst werden. Ein weiteres Symbol ermöglicht es, die Spiegelliste nach Selektion eines Spiegels auszublenden. Letzteres ist auch über einen neuen Eintrag im Menü <Ansicht> möglich.
Die Tabelle der definierten Spiegel zeigt jetzt auch die Spalten für Gültigkeit und letzte Änderung an. Außerdem stehen ein Filter und eine Druckfunktion für diese Tabelle zur Verfügung.
Die Masken mit den Spiegelattributen, die bisher neben dieser Tabelle angezeigt wurden, sind entfallen. Die Änderung eines Spiegels erfolgt jetzt analog zur Neuerfassung über einen Assistenten. Dort können künftig auch fremdsprachige Bezeichnungen wieder gelöscht werden. Dies gilt auch für die abhängigen Daten.
Der geöffnete Spiegel wird in der Spiegelliste nur noch durch farbliche Hinterlegung gekennzeichnet. Die bisherige Kennzeichnung durch einen Pfeil ist entfallen. Die Bezeichnung des geöffneten Spiegels wird in der Titelzeile der Anwendung und in der zugehörigen Anwendungsregisterkarte angezeigt.
Im Register "Offene Aufgaben" wird jetzt angezeigt, wenn für einen Spiegel in einer Sprache keine Spaltenüberschrift definiert ist. Die Spaltenüberschrift wird u.a. im Einzelabschluss-Monitor (EA) verwendet, war aber in früheren IDL Konsis-Releases keine Pflichteingabe gewesen.
In den Spalten der Tabellen der abhängigen Daten (Buchungsschlüssel, Spiegelspalten etc.) werden logische Attribute wie in den Assistenten durch grüne Häkchen dargestellt.
Für die Zeilen der abhängigen Tabellen (Buchungsschlüssel, Spiegelspalten etc.) steht jetzt eine Kopiermöglichkeit (Erfassen mit Vorlage) zur Verfügung. Dabei muss mindestens ein neuer Schlüssel angegeben werden.
Für die neuen BSL-Verwendungskennzeichen 'NE', 'NF', 'SNE' und 'SNF' (s.u.), 'B17' und 'B18' (s.u.), 'P' (s.u.) sowie 'XZA' (s.u.) wurden entsprechende Prüfungen und mögliche "offene Aufgaben" ergänzt.
In verschiedenen anderen Anwendungen (z.B. "Spiegelbewegungen" (SPIBEW)) wurde der Aufruf der Folgeanwendung "Buchungsschlüssel" (BSL) durch den Aufruf der Folgeanwendung "Spiegeldefinitionen" (SPIDEF) ersetzt.
Neben den bisherigen Typen von Spiegelbereichen
gibt es jetzt einen vierten Typ für Spiegelbereiche.
Mit dem Begriff "saldenrelevant" wird ausgedrückt, dass Buchungen mit einem Buchungsschlüssel, der einem nicht saldenrelevanten Spiegelbereich zugeordnet ist, bei der Überleitung auf die nächste Datenart nicht zur Veränderung des Kontensaldos führen. Ebenso werden Konsolidierungsbuchungen mit einem nicht saldenrelevanten Buchungsschlüssel nicht in einem Bilanz/GuV-Report ausgewiesen.
Der neue Typ unterscheidet sich von den nicht verprobten Spiegelbereichen dadurch, dass eine Verprobung erfolgt. D.h. die Summe aller Bewegungen eines Kontos mit Buchungsschlüsseln dieses Spiegelbereichs muss gleich dem Kontensaldo sein. Ist dies nicht der Fall, führt dies zu einem [roten] Status für diesen Spiegel im Einzelabschluss-Monitor (EA) genauso, wie dies der Fall ist, wenn die Summe der saldenrelevanten Bewegungen ungleich dem Kontensaldo ist.
Bitte beachten Sie, dass die Verprobung der Spiegelbewegungen mit dem Kontensaldo für die nicht saldenrelevanten Spiegelbereiche je Spiegelbereich erfolgt, während die saldenrelevanten Spiegelbereiche in Summe mit dem Kontensaldo verglichen werden (z.B. im Anlagenspiegel Summe aus AHk und AfA).
Die Typisierung eines Spiegelbereichs wird in der Anwendung "Spiegelbereich" (SBEE) durch die drei Schalter "ohne Verprobung", "konsolidieren" und "saldenrelevant" festgelegt, wobei nicht alle Kombinationen dieser Schalter zulässig sind. Dies wird durch die automatische Setzung und Deaktivierung der entsprechenden Radio-Buttons in der Anwendung "Spiegeldefinitionen" (SPIDEF) deutlich.
Der neue Typ von Spiegelbereichen (verprobt, aber nicht saldenrelevant) ist nicht für den Spiegel 'B' (Anteilsbesitz) zugelassen. Da es keinen Beteiligungsreport auf Basis der Anteilsbesitzbewegungen gibt, wird dieser Typ dort nicht benötigt. Für Kapital- und Rückstellungsspiegel (Spiegeltyp 'K' bzw. 'R') ist nur ein verprobter Spiegelbereich zugelassen.
Es wird dringend empfohlen, nur Buchungsschlüssel, die gleichartigen Spiegelbereichen zugeordnet sind, zu einer Spiegelspalte zusammenzufassen, da die Summe der Spiegelspalte sonst nicht interpretiert werden kann. Grundsätzlich sind aber für spezielle Zwecke auch gemischte Zuordnungen zugelassen.
Mit Hilfe des neuen Spiegelbereich-Typs ist es möglich, quasi zwei (oder mehr) Spiegelaufrisse zu einem Konto zu führen. Veränderungen auf einem Konto sind dann durch zwei (oder mehr) Buchungen darzustellen, einer Buchung mit einem saldenrelevanten und einer Buchung mit einem nicht saldenrelevanten Buchungsschlüssel. Die nicht saldenrelevanten Spiegelbereiche können auch mit Buchungsschlüsseln für Vortrag, Umrechnungsdifferenzen etc. (gemäß BSL-Verwendungskennzeichen) ausgestattet werden. Ein automatischer Ausgleich zum Kontensaldo (BSL-Verwendungskennzeichen 'L') erfolgt allerdings nur für die saldenrelevanten Spiegelbereiche.
Auch die bisherige Schattenrechnung ("Steuerung des Vortrags" = 'S' in der Anwendung "Spiegel" (SPI)), wie sie z.B. für die gleichzeitige Führung eines Aufrisses nach Fristigkeiten und eines Aufrisses für die Kapitalflussrechnung benötigt wurde, kann durch einen nicht saldenrelevanten Spiegelbereich abgelöst werden. Hierzu ist folgendes Vorgehen erforderlich:
Diese Änderungen können mit der Anwendung "Spiegeldefinitionen" (SPIDEF) vorgenommen werden. Zur Minimierung von Fehleingaben werden inkonsistente Zustände dort im Fenster "Offene Aufgaben" aufgelistet.
Für nicht liquiditätswirksame Zu- und Abgänge gibt es die neuen BSL-Verwendungskennzeichen 'NE', 'NF', 'SNE' und 'SNF' (s.u.). Für konzerninterne Verkäufe von Anteilen gibt es die neuen BSL-Verwendungskennzeichen 'B17' und 'B18' für den Anteilsbesitz (s.u.). Für prozentuale Veränderungen im Anteilsbesitz gibt es das neue BSL-Verwendungskennzeichen 'P' im Kapitalspiegel (s.u.). Für die Zwischenergebniseliminierung im Anlagevermögen gibt es das neue Verwendungskennzeichen 'XZA' im Anlagenspiegel (s.u.). Daten mit diesen Verwendungskennzeichen wurden in den LieferBatch-Dateien zur Fortführung des früheren Standards ergänzt.
Das Buchungsschlüssel-Verwendungskennzeichen 'AHK' (ergebnisneutrale Verrechnung der Wertberichtigung) darf nur noch Spiegelbereichen zugeordnet werden, bei denen das AfA-Kennzeichen auf 'AHK' gesetzt ist.
Es werden nur noch vier Kartenarten für Anlagenobjekte unterstützt:
Die weiteren bisher möglichen Kartenarten 'B', 'L' und 'N' sind nicht mehr zugelassen, hatten bisher aber auch schon keine von 'K' abweichende Funktion. Bestehende Anlagenobjekte mit den Kartenarten 'B', 'L' und 'N' werden bei der Release-Konvertierung auf die Kartenart 'K' umgesetzt.
Die Übersicht "Anlagenobjekte" (ANLOBJ) zeigt jetzt keine IC-Anlagenobjekte (Kartenarten 'A' und 'Z') mehr an sondern nur noch Anlagenobjekte mit den Kartenarten 'M' und 'K'. Es ist aber weiterhin nicht möglich, ein Anlagenobjekt und ein IC-Anlagenobjekt mit demselben Schlüssel zu versehen. Bei der Eingabe eines bereits in der anderen Tabelle vergebenen Schlüssels kommt jetzt eine spezielle Fehlermeldung.
Die Eingabemöglichkeit eines Konzerns/Teilkonzerns für IC-Anlagenobjekte wurde in der Einzelsatzanwendung (ICANLOBJE) entfernt. Hintergrund ist, dass es sich um einen Datensatz der einzelnen Gesellschaft handelt und erst im Rahmen der Konsolidierung ermittelt wird, in welchem Konzernkreis der Sachverhalt verarbeitet wird.
Außerdem wurde das bisherige Eingabefeld "Verkaufsdatum" in "Abgang Konzernkreis Datum" umbenannt, um Missverständnisse zu vermeiden.
Die Bezeichnungen der Produkte und Produktgruppen für die Zwischenergebniseliminierung im Umlaufvermögen können jetzt wie andere Stammdaten in unterschiedlichen Sprachen gepflegt werden. Übersicht (PRO) und Einzelsatzanwendung (PROE) wurden um ein Eingabefeld für den Sprachschlüssel erweitert. Die neue Importanwendung (TXTPRO, s.u.) unterstützt die Mehrsprachigkeit der Bezeichnungen ebenfalls.
Prüfregeln können jetzt zu Regelgruppen zusammengefasst werden. Dazu wurde die Tabelle der Prüfregelgruppen (PRFGRP) um ein Kennzeichen erweitert, mit dem der Typ der Gruppe unterschieden wird. Folgende Prüfregel-Gruppentypen gibt es:
Die Tabelle der Prüfregeln (PRF) wurde um eine Zuordnung der Regel zu einer Regelgruppe erweitert. Im Gegensatz zur Zuordnung von Prüfregeln zu Ausschlussgruppen über eine eigene Zuordnungstabelle (PRFZUO) kann eine Prüfregel immer nur einer Regelgruppe zugeordnet werden.
Zusätzlich wurde die Tabelle der Prüfregelgruppen (PRFGRP) um eine Zuordnung zu einer "Obergruppe für Prüfregelgruppe" erweitert. Dies ermöglicht, die Prüfregeln mehrstufig in einer Baumstruktur anzuordnen. Diese Hierarchisierung ist nicht für Ausschlussgruppen möglich.
Diese Zuordnungen werden sowohl in der Übersicht der Prüfregeln selbst (PRF) als auch in der Übersicht zur Anzeige der Prüfregelergebnisse (PRFERG) zu einer Darstellung der Daten in Baumstruktur ausgewertet. Prüfregeln, die keiner Regelgruppe zugeordnet sind, werden am Ende der Tabelle auf der obersten Ebene aufgelistet.
Im Einzelabschluss-Monitor können Daten verschiedener Datenarten angezeigt werden. Das ist jetzt auch möglich, wenn die "ex Datenart" (Datenart, in der der Konzernkreis definiert ist) im Datenartenstamm (FAC) angegeben ist, setzt aber voraus, dass die "ex Datenart" für alle selektierten Datenarten einheitlich ist.
Die Statusaktualisierung im Einzelabschluss-Monitor (EA) umfasst jetzt auch den Status der Buchungen.
Die Funktion zur Berechnung der latenten Steuern im Einzelabschluss kann jetzt als Folgeanwendung (Submenü "Verarbeitungen") aus dem Einzelabschluss-Monitor (EA) heraus aufgerufen werden. Ausgenommen ist dabei das Verfahren mit Verwendung einer separaten Datenart für die Steuerbilanz, da die Steuer-Datenart ebenso wie eine Ziel-Datenart nur in der Anwendung "Latente Steuern Kopfsätze" (LTK) angegeben werden kann.
Bei der Selektion von Einzelabschlussdaten kann eine Einschränkung auf Gesellschaften eines Konzernkreises vorgenommen werden. Dabei wurde i.d.R. eine Berechtigungsprüfung für den Konzern/Teilkonzern durchgeführt. Diese Prüfung ist jetzt entfallen. D.h. auch ein Benutzer, der nur Objektberechtigungen für Gesellschaften hat, kann eine Konzernkreisselektion vornehmen, wobei nur noch eine Berechtigungsprüfung für die im Konzernkreis enthaltenen Gesellschaften erfolgt.
Die Selektion von IC-Anlagenbewegungen (ICANLBEW) und IC-Beständen im Vorratsvermögen (ICVOR) nach allen Gesellschaften eines Konzernkreises ist jetzt auf beliebigen Datenarten möglich. Zur Ermittlung der Gesellschaften wird die bei der Datenart (FAC) oder in der Vorbelegung (VOR) angegebene "ex Datenart" ausgewertet.
Die bisherigen Aktionen "Anlagenbewegungen", "Kapitalbewegungen", "Rückstellungsbewegungen" und "Spiegelbewegungen" in der Übersicht "Kontensalden" (KTOSAL) wurden durch eine einzelne Aktion "Spiegelbewegungen" ersetzt. Welche Anwendung aufgerufen wird, hängt vom Spiegel des Kontos der jeweiligen Zeile ab. Auf diese Weise kann man in die Spiegelaufrisse verschiedener Konten mit verschiedenen Spiegeln durch eine gemeinsame Markierung und eine einzige Aktion verzweigen.
Wenn Geschäftsbereiche mit Angabe einer Kontogruppe in der "Gesellschaft+Geschäftsbereich-Zuordnung" (GESUBR) definiert werden, wird die Übereinstimmung von Bilanz und GuV durch Generierung eines Ausgleichs-Kontensaldos auf dem Konto mit Kontokennzeichen 'U' automatisch hergestellt. In Summe über alle Geschäftsbereiche müssen die Kontensalden auf den 'U'-Konten zu null saldieren. Dies wird jetzt bei der Validierung der Kontensalden geprüft. Ist die Bedingung nicht erfüllt, wird der Kontensalden-Status für alle Geschäftsbereiche [rot], da die Differenz keinem einzelnen Geschäftsbereich zuordenbar ist.
In der Übersicht "IC-Kontensalden" (ICKTOSAL) sowie in der zugehörigen Einzelsatzanwendung (ICKTOSALE) wird die IC-Gesellschaft künftig mit ihrer bis zu 70 Stellen langen Bezeichnung angezeigt.
Zur besseren Abstimmung des IC-Clearings auf der Konsolidierung vorgelagerten Datenarten gibt es jetzt eine neue Übersicht "IC-Salden und Buchungen". Im Gegensatz zur Übersicht "IC-Unterkontensalden" (ICKTOSAL) werden hier auch Buchungen mit Angabe einer IC-Gesellschaft aufgelistet, so dass alle für die IC-Saldenabstimmung herangezogenen Daten gemeinsam angezeigt werden. Buchungen können anhand des Eintrags in der Spalte "Beleg Nr." erkannt werden.
Diese Anwendung kann nicht direkt aus dem Menübaum oder per Kurzwort aufgerufen werden, sondern nur als Folgeanwendung der "IC-Clearing Übersicht" (KGESGES). Dies geschieht auch durch einen Maus-Doppelklick in einer der Wertspalten. Hierbei werden die Schlüssel einer Zeile (u.a. Gesellschaft, IC-Gesellschaft, Konsolidierungsverarbeitung) als Parameter übergeben. Diese Schlüssel müssen eindeutig vorgegeben werden.
Die Anzeige erfolgt grundsätzlich in Pärchensicht, d.h. die Daten der Gesellschaft werden den Daten der IC-Gesellschaft gegenübergestellt. Ggf. erfolgt noch eine zusätzliche Untergliederung nach Paaren von Geschäftsbereichen. Die Darstellung erfolgt als Baumstruktur zum Auf- und Zuklappen.
Wie in der "IC-Clearing Übersicht" werden nur Werte in Konzernwährung (sowie ggf. Transaktionswährung) angezeigt. Die Konzernwährungswerte werden wie bei der IC-Saldenabstimmung selbst ggf. durch eine implizite Währungsumrechnung erzeugt.
Unmittelbare Änderungsmöglichkeiten sind in dieser Anwendung nicht vorgesehen. Je nach Herkunft der Daten muss dazu erst in die Übersicht "IC-Unterkontensalden" (ICKTOSAL) oder die Übersicht "Buchungen" (BUCH) verzweigt werden. Dies ist auch durch einen Maus-Doppelklick in die Spalte "Beleg Nr." möglich.
Es wird jetzt geprüft, ob alle IC-Anlagenbewegungen zu einem IC-Anlagenobjekt demselben Geschäftsbereich zugeordnet sind. Ist dies nicht der Fall, wird der im "Einzelabschluss-Monitor" (EA) angezeigte Status für IC-Anlagenbewegungen [rot].
Das Kurzwort zum Aufruf der Übersicht "IC-Bestände Vorratsvermögen" wurde von "ICBEW" auf "ICVOR" geändert, da es häufig Verwechslungen mit Spiegelbewegungen gegeben hatte.
Bei der Verzweigung von der Belegübersicht (BEL) in die Buchungen sowie bei der Aktion "Detailansicht" in der Buchungsübersicht (BUCH) wird in der folgenden Buchungsanzeige der Schalter "alle Buchungen anzeigen" gesetzt, so dass auch die im Normalfall nicht angezeigten, automatisch generierten Buchungen zu sehen sind.
In der Übersicht "Buchungen" (BUCH) können jetzt Buchungen ohne Angabe eines Controllingobjekts selektiert werden. Dazu ist ein Stern ('*') im ersten Eingabefeld (Controllingplan) einzugeben.
Buchungen mit einem Buchungsschlüssel, der einem nicht saldenrelevanten Spiegelbereich (s.o.) zugeordnet ist, werden in der Buchungsübersicht unterhalb der Summen je Buchungssatz angezeigt, da sie nichts zu diesen Summen beitragen.
Bei der Verzweigung von der Übersicht "Kontensalden-Herkunftsnachweis" (KTOHER) in die Buchungsübersicht (BUCH) werden jetzt nur noch Buchungen aus aktiven Belegen angezeigt.
In der Analyse-Übersicht für Prüfregelergebnisse (PRFERGANA) wurde die Anzeige des Geschäftsbereichs ergänzt.
Wenn Geschäftsbereiche mit Angabe einer Kontogruppe in der "Gesellschaft+Geschäftsbereich-Zuordnung" (GESUBR) definiert werden, dann wird das GuV-Ergebnis eines GuV-Geschäftsbereichs (Kontogruppe 'G') beim Vortrag auf den Bilanz-Geschäftsbereich (Kontogruppe 'B' oder 'M') umgebucht. Da dies zur Folge hat, dass die Kapitalbewegungen für die Umbuchung (Buchungsschlüssel mit Verwendungskennzeichen 'XJU') nicht mehr je Geschäftsbereich zu null saldieren, erfolgt die Prüfung der Umbuchungsspalte im Kapitalspiegel jetzt geschäftsbereichsübergreifend.
Wenn ein Anlagenkonto historisch umgerechnet wird (Umrechnungsanweisung 'FDK'), dann werden jetzt auch die IC-Anlagenbewegungen auf diesem Konto entsprechend umgerechnet, d.h. es gibt keine Kurseffekte und Umrechnungsdifferenzen.
Kurseffekte, die auf Vortrags-Spiegelbewegungen errechnet werden, die aus einer Buchung stammen, erhalten jetzt wie die Vorträge selbst den Eintrag der Ursprungs-Datenart und -Belegnummer. Dadurch wird eine doppelte Berechnung der Kurseffekte vermieden.
Es erfolgt jetzt auch ein Abgleich zwischen den IC-Beständen im Vorratsvermögen (ICVOR) und den zugehörigen Kontensalden. Ist die Summe der IC-Bestände eines Kontos in Landeswährung gleich dem Kontensaldo, dann wird dies auch in Konzernwährung gewährleistet. Ist die Summe der IC-Bestände in Landeswährung kleiner als der Kontensaldo, dann wird die Summe der IC-Bestände in Konzernwährung nicht größer als der Kontensaldo. Differenzen (es handelt sich nur um Rundungsdifferenzen) werden auf dem ersten IC-Bestandssatz ausgeglichen. Dies gilt analog für die Umrechnung von der Konzern- in die Parallelwährung.
Buchungen für latente Steuern werden künftig mit derselben Buchungssatznummer geschrieben wie die Ursprungsbuchung, so dass eine einfachere Zurückverfolgung möglich ist.
Die Einzelabschlussanwendung für die Umgliederung von Buchungen bei einer Verschmelzung (MERGESBUCH) gibt jetzt im Meldungsfenster die Information aus, dass Buchungen verarbeitet wurden.
Bisher konnte zur Berechnung der Prüfregelergebnisse nur eine Vor-/Vergleichsperiode spezifiziert werden. Damit war es nicht möglich, z.B. sowohl Prüfregeln mit Bezug auf den Vormonat als auch Prüfregeln mit Bezug auf den letzten Jahresabschluss zu definieren. Außerdem kann die freie Eingabe der Vor-/Vergleichsperiode leicht zu Fehleingaben führen.
Künftig können im Schalter für die Periodensteuerung der Seiten einer Prüfregel (PRFE) neben 'X' auch folgende Werte angegeben werden:
Eine Besonderheit wird für GuV-Konten bei den Kennzeichen 'M' und 'Q' beachtet: Da GuV-Daten zu Beginn des Geschäftsjahres mit 0,00 beginnen, wird als Vorperiodenwert immer 0,00 eingestellt, wenn die ermittelte Vorperiode das Periodenkennzeichen 'J' (Jahresabschluss) hat.
Bei der Berechnung der Prüfregelergebnisse wird bei diesen Eingaben die Vor-/Vergleichsperiode aus dem Periodenstamm unabhängig von einer gleichzeitigen expliziten Eingabe ermittelt und angewandt. Die eingegebene Vor-/Vergleichsperiode wird nur bei Eingabe 'X' im Periodenschalter der Prüfregel ausgewertet.
Bestehende Prüfregeln mit Eingabe 'X' werden damit genauso wie bisher verarbeitet. Es wird jedoch empfohlen, die Prüfregeldefinitionen auf die neuen Eingaben ('J', 'Q' oder 'M') umzustellen, da dies eindeutiger ist. Außerdem wird die Angabe 'X' voraussichtlich in einem der nächsten IDL Konsis-Releases entfallen.
Prüfregelpositionen (PRFPOS) können jetzt mit einem Minus-Operator versehen werden, damit die zugehörigen Werte negativ in die Prüfregel-Formel einfließen. Dies wird z.B. benötigt, um Prüfregeln für Differenzen zwischen aktuellen und Vorperiodenwerten zu definieren.
Prüfregelpositionen (PRFPOS) können auch nach einem Spiegelbereich eingeschränkt werden. In die Berechnung des Prüfregelergebnisses fließen dann alle Daten mit einem Buchungsschlüssel ein, der diesem Spiegelbereich zugeordnet ist.
Die hier genannten Erweiterungen gelten für die Berechnung der Prüfregelergebnisse auf Gesellschaftsebene und, sofern anwendbar, auch auf Konzernebene.
Die "KK-Spiegelumbuchung" ('KU') erfolgt im Normalfall automatisch im Rahmen der Kapital-Erstkonsolidierung ('KK'), kann aber auch (z.B. bei nachträglicher Änderung der Spiegelbewegungen) separat durchgeführt werden. Für diese Verarbeitung wurde jetzt im Konzernkreis-Monitor (KTKGES) eine eigene Statusspalte ergänzt. Der Status wird wie folgt gesetzt:
Die Erstellung eines Konsolidierungsreports (Darstellung der Beiträge der verschiedenen Konsolidierungsfunktionen in getrennten Spalten) erfordert eine Zuordnung der Konsolidierungsverarbeitungen (KVA) zu den Spalten. Diese Zuordnung war bis zum IDL Konsis Release 2010.0 fest vorgegeben. Um dem Anwender mehr Gestaltungsmöglichkeiten zu geben, wurde diese Zuordnung im Release 2010.1 flexibilisiert. Dies hatte allerdings zur Folge, dass alle neuen Anwender diese Zuordnung komplett selbst manuell vornehmen mussten. Um dies zu vermeiden, wird der frühere Standard jetzt in Form einer LieferBatch-Datei im Verzeichnis "Spaltenoptionen_Konsolidierungsreport" auf der Release-CD zur Verfügung gestellt. Das Einspielen in die Datenbank erfolgt über die neue Anwendung zum Import von Konsolidierungsverarbeitungen (s.u.).
Buchungsschlüssel mit BSL-Verwendungskennzeichen 'L' (automatisch berechnete laufende Veränderung) können jetzt in allen Konsolidierungsparametern (KTKPARxx) angegeben werden, wenn das jeweilige Konto einem automatischen Spiegel zugeordnet ist.
Hinsichtlich der zugelassenen Konten in den verschiedenen Konsolidierungsparametern (KTKPARxx) wurden diverse Einschränkungen gelockert.
Grundsätzlich gibt es keine Einschränkung eines KTKPAR-Kontos mehr auf ein einzelnes Bilanz-/GuV-Kennzeichen. Wenn also bisher z.B. nur Aktivkonten zugelassen waren, dann sind jetzt auch Passivkonten zugelassen und umgekehrt. So dürfen jetzt z.B. in diversen Konsolidierungsparametern auch Aktivkonten als Ergebnisvortragskonto eingetragen werden. Entsprechendes gilt für Aufwände und Erträge. So sind für das "Konto Dividendenertrag / phasenversetzt" im Konsolidierungsparameter 'FK' jetzt auch Aufwandskonten zugelassen.
Die Konten für "Aktivierung Geschäftswert" und "Beteiligung assoziierte Unternehmen" (nur 'EK') in den Konsolidierungsparametern 'KK' (Kapitalkonsolidierung) und 'EK' (Equity-Konsolidierung) sowie die Konten für "Impairment stille Reserven" und "Wertaufholung stille Reserven" im Konsolidierungsparameter 'EF' (Fortschreibung Equity) müssen jetzt nicht mehr einem Anlagenspiegel zugeordnet sein.
In den Konsolidierungsparametern 'KK' und 'EK' dürfen jetzt auch Konten ohne das Kontokennzeichen 'D' als Abschreibungskonten angegeben werden, obwohl mit dem Kontokennzeichen 'D' gearbeitet wird. Dies kann z.B. dann notwendig sein, wenn das Abschreibungskonto ein IC-Konto ist und das Kontokennzeichen 'J' benötigt. Des Weiteren können als Konto für "Kurseffekte auf Beteiligung" auch GuV-Konten angegeben werden.
Das bisherige Konto "Beteiligung assoziierte Unternehmen" des Konsolidierungsparameters 'EK' (Equity-Konsolidierung) wurde umbenannt in "Umbuchung des Beteiligungsansatzes", um dessen Funktion zu verdeutlichen. Außerdem wurde die Beschränkung aufgehoben, dass dieses Konto ein Beteiligungskonto (Kontokennzeichen 'B') sein muss. Dieses Konto muss für die Equity-Konsolidierung auch kein Anlagenkonto mehr sein. Allerdings wird dann immer der komplette Beteiligungssaldo verarbeitet, da bei anderen Spiegeln keine Unterscheidung zwischen Anschaffungskosten und Wertberichtigung möglich ist.
Trotz der Lockerung der Prüfungen werden in der Kontenauswahl nur die der bisherigen Regelung entsprechenden Konten angeboten, da mit großer Wahrscheinlichkeit eines dieser Konten gewählt wird. Es sind aber in vielen Fällen auch andere Konten zugelassen.
Der Begriff "Unterschiedsbetrag" wird jetzt nur noch in der Kapitalkonsolidierung verwendet. Die entsprechenden Konten in den Konsolidierungsparametern 'SK' und 'AE' für das IC-Clearing werden künftig als "Zwischenkonto" bezeichnet.
Die Eingabefelder für Controllingobjekte werden in den Einzelsatzmasken für Konsolidierungsparameter nicht mehr angezeigt, wenn der Anwender den Controllingbaustein nicht lizenziert hat.
Die Konten "Eliminierung Jahresergebnis", "Eliminierung Jahresergebnis indirekt", "Eliminierung ergebniswirksame Buchung" und "Eliminierung ergebniswirksame Buchung indirekt" aus dem Konsolidierungsparameter 'FK' (Fremdanteile) müssen das Kennzeichen "Umbuchung beim Vortrag" haben, sofern es sich um Kapitalkonten handelt. Bei bereits in den Konsolidierungsparametern verwendeten Konten wird das Kennzeichen durch die Release-Konvertierung automatisch gesetzt.
Das Konto "Beteiligung assoziierte Unternehmen" im Konsolidierungsparameter 'EK' wurde umbenannt in "Umbuchung Beteiligung", um seine Rolle zu verdeutlichen.
Die Übersicht "Konsolidierungsbuchungen" (KONBUCH) ermöglicht jetzt das Mengenkopieren von Buchungen auf eine andere Buchungssatznummer.
Durch Mengenkopieren erzeugte Konsolidierungsbuchungen erhalten jetzt immer den Buchungsstatus '5' (manuell erfasst) und sind somit anschließend beliebig änderbar, auch wenn die Herkunfts-Buchungen maschinell erzeugt worden und somit nicht änderbar waren.
Die Übersicht "Konsolidierungsbuchungen" (KONBUCH) enthält jetzt ein Eingabefeld für die Selektion nach "Beleg-Gesellschaft". Analog der entsprechenden Eingabe in der Übersicht "Konsolidierungsbelege" (KONBEL) werden nun die Buchungen nach Angabe dieser Gesellschaft in der Belegnummer gefiltert. Im Gegensatz zur Selektion nach "Gesellschaft" werden dann die Belege vollständig, also einschl. der Buchungen bei der Gegen-Gesellschaft angezeigt.
In der Übersicht "Konsolidierungsbuchungen" (KONBUCH) können jetzt Konsolidierungsbuchungen ohne Angabe eines Controllingobjekts selektiert werden. Dazu ist ein Stern ('*') im ersten Eingabefeld (Controllingplan) einzugeben.
In einer neuen Spalte der Übersicht "Konsolidierungsbuchungen" (KONBUCH) wird jetzt die Ergebniswirksamkeit in Parallelwährung ausgewiesen, sofern mit einer abweichenden Parallelwährung gearbeitet wird.
Konsolidierungsbuchungen mit einem Buchungsschlüssel, der einem nicht saldenrelevanten Spiegelbereich (s.o.) zugeordnet ist, werden in der Übersicht unterhalb der Summen je Buchungssatz angezeigt, da sie nichts zu diesen Summen beitragen. Diese Buchungen können nicht zur Berechnung von latenten Steuern oder Fremdanteilen markiert werden.
Ein Doppelklick auf die Spalte "Belegnummer" in der Übersicht "Konsolidierungsbuchungen (KONBUCH) löst jetzt die Aktion "Detailansicht" aus.
Die Bestimmungen, welche Konten in welchem Buchungssatz angesprochen werden dürfen, wurden für die Verrechnung des Unterschiedsbetrags in Kapitalkonsolidierungsbelegen (Buchungssatznummer 02 bis 08) gelockert.
Auf Datenarten (FAC), bei denen der Schalter für die Führung von Geschäftsbereichen auf 'M' (gemischt mit und ohne Geschäftsbereiche) gesetzt ist, dürfen keine Konsolidierungsbelege und -buchungen mehr erfasst werden. Für maschinell erzeugte Konsolidierungsbelege gilt diese Einschränkung schon länger. Hintergrund ist, dass die Konsolidierung eine einheitliche Führung der Daten entweder mit oder ohne Geschäftsbereich voraussetzt.
Konsolidierungsbuchungen können jetzt nicht mehr mit Buchungsschlüsseln für Anteilsbesitzbewegungen versehen werden, auch wenn das Beteiligungskonto keinem Spiegel zugeordnet ist. Diese Angabe hatte keine Funktion und führte daher zu falschen Erwartungen.
Die SK- und die AE-Spiegelumbuchung ('SU', 'AU') erzeugt Buchungen ohne Angabe von Controllingobjekten, da diese Angabe Controllingreports verfälschen könnte. Daher wird jetzt auch beim Mengenändern dieser Buchungen (z.B. zur Ergänzung eines fehlenden Buchungsschlüssels) nicht mehr geprüft, ob ein Controllingobjekt angegeben ist.
Automatisch erzeugte Neutralisierungsbuchungen dürfen künftig geändert werden (z.B. Angabe eines anderen Buchungsschlüssels oder eines anderen Neutralisierungskontos). Die Buchung wechselt ihren Status dabei von '1' (maschinell erzeugt) auf '5' (manuell erzeugt), so dass sie bei einer späteren erneuten Erzeugung von Neutralisierungsbuchungen nicht mehr verändert werden.
Verarbeitung beliebiger Konten
In der Formularerfassung für die Erstkonsolidierung können jetzt beliebige Konten angegeben werden. Bisher war dort nur die Eingabe von Kapitalkonten zugelassen. Die dazu angegebenen Werte fließen in die Berechnung des Unterschiedsbetrags ein.
Umbuchung der Währungseffekte im Anteilsbesitz
Es ist jetzt möglich, auch die Umrechnungsdifferenzen und Kurseffekte im Anteilsbesitz (durch die Währungsumrechnung erzeugte Anteilsbesitzbewegungen mit Buchungsschlüsseln mit Verwendungskennzeichen 'K' oder 'U') umzubuchen.
Zur Steuerung dieses Verfahrens wurden die Konsolidierungsparameter 'KK' und 'EK' um ein Konto "Währungsumrechnung Beteiligung" einschl. der Eingabemöglichkeit je eines zugehörigen Buchungsschlüssels und Controllingobjekts erweitert.
Der im Konzernkreis-Monitor (KTKGES) angezeigte Status 'KK' wird [rot], sobald die Voraussetzungen gegeben sind, also auch in Perioden, in denen es keine weiteren Veränderungen im Anteilsbesitz gegeben hat.
Die zusätzlichen Umbuchungen erfolgen sowohl in der maschinellen Erstkonsolidierung als auch in der Formularerfassung, sobald dieses Konto im Konsolidierungsparameter eingetragen wurde. In einem zusätzlichen Konsolidierungsbeleg wird der Konzernwährungswert der Anteilsbesitzbewegung bei der Muttergesellschaft eliminiert und auf dem im Konsolidierungsparameter angegebenen Konto wieder eingebucht. Abhängig vom Spiegelbereich des Buchungsschlüssels werden Anschaffungs-/Herstellkosten bei der Tochtergesellschaft eingebucht, Abschreibungen dagegen bei der Muttergesellschaft.
In Perioden außerhalb des Jahresabschlusses erhalten diese neuen Belege die Buchungsart 'EP'. Sie werden also unterjährig nicht vorgetragen, da sie aufgrund von Kursschwankungen in jeder Periode andere Werte enthalten.
Auf die neuen Buchungen werden indirekte Fremdanteile berechnet und gebucht, falls der jeweilige Buchungsschlüssel das Verwendungskennzeichen 'FF' hat.
Nicht-liquiditätswirksame Zu- und Abgänge
Als nicht-liquiditätswirksamer Zugang zum Konzernkreis wird eine Gesellschaft bezeichnet, die sich bereits aus Vorperioden im Anteilsbesitz befindet und an deren wertmäßigen und prozentualen Beteiligungsverhältnis innerhalb des Konzernkreises sich nichts geändert hat, die aber aufgrund anderer Kriterien von einer unwesentlichen zu einer wesentlichen Gesellschaft wird und daher erstmalig in den Konzernabschluss einbezogen wird. Ein nicht-liquiditätswirksamer Abgang ist die Umkehr dieses Vorgangs.
Für diese Vorgänge sind Konsolidierungsschritte (Erstkonsolidierung bzw. Endkonsolidierung) notwendig, ohne dass sich dies aus Änderungen im Anteilsbesitz (Zu- oder Abgang in GESGES) ergibt. Dies konnte zwar mit gewissen Tricks grundsätzlich in IDL Konsis dargestellt werden, jedoch fehlte eine Unterscheidung bei den Spiegelumbuchungen, die insbesondere für die Kapitalflussrechnung benötigt wird.
Die Verarbeitung dieser Vorgänge wird jetzt unabhängig von Anteilsbesitzbewegungen durchgeführt. Stattdessen muss eine entsprechende Angabe in einem neuen Eingabefeld "Wechsel der Konsolidierung" in der Definition der Zugehörigkeit der Gesellschaft zum Konzernkreis (KTKGESE) erfolgen. Hier sind die Angaben 'NLA' (Nicht liquiditätswirksamer Abgang) und 'NLZ' (Nicht liquiditätswirksamer Zugang) möglich. Zusätzlich ist ein Eintrag bei "Abgang Konsolidierungskreis" bzw. "Zugang Konsolidierungskreis" vorzunehmen, um den Vorgang datieren zu können. Das neue Attribut wird beim Vortrag nicht in das nächste Geschäftsjahr übernommen, da es dort seine Wirkung verliert.
Die Kapital-Erstkonsolidierung wird bei der Angabe 'NLZ' ausgelöst, wobei in diesem Fall die vorgetragenen Anteilsbesitzbewegungen wie ein Zugang behandelt und eliminiert werden. Dort erfolgt auch der Nachweis der Verarbeitung durch Eintrag von Konzern/Tk und Belegnummer. Entsprechend wird bei Angabe 'NLA' eine Endkonsolidierung durchgeführt. Die Statusermittlung verhält sich gemäß dieser Regelung.
KK-Spiegelumbuchung (KU)
Liquiditätswirksame und nicht liquiditätswirksame Zugänge werden bei der KK-Spiegelumbuchung unterschieden. Während standardmäßig eine Umbuchung auf den Buchungsschlüssel mit Verwendungskennzeichen 'E' (Zugang zum Konzernkreis) erfolgt, werden die Bewegungen für nicht liquiditätswirksame Zugänge auf einen Buchungsschlüssel mit Verwendungskennzeichen 'NE' (nicht liquiditätswirksamer Zugang zum Konzernkreis) umgebucht, sofern ein solcher definiert ist. Die Endkonsolidierung verhält sich entsprechend (BSL-Verwendungskennzeichen 'F' bzw. 'NF'). Für Spiegel mit Schattenrechnung sind zusätzliche Buchungsschlüssel mit Verwendungskennzeichen 'SNE' und 'SNF' zur Stornierung dieser Buchungen zu definieren.
Da unterschiedliche Buchungsschlüssel ggf. auch für den Kapitalspiegel benötigt werden, wurde das Verfahren der Spiegelumbuchung geändert. Künftig wird das Kapital im 'KK'-Beleg mit dem Buchungsschlüssel mit Verwendungskennzeichen 'E' bzw. 'NE' eliminiert. Zusätzlich werden auch die Kapitalbewegungen in der KK-Spiegelumbuchung verarbeitet und dort ebenfalls auf die Buchungsschlüssel mit Verwendungskennzeichen 'E' bzw. 'NE' umgebucht.
Die Voraussetzungen für die Durchführung der KK-Spiegelumbuchung wurden ebenfalls geändert. Künftig erfolgt die Umbuchung unabhängig von Anteilsbesitzbewegungen ausschließlich anhand des Datums des Konzernkreiszugangs in der Zuordnung der Gesellschaft zum Konzernkreis (KTKGESE). Damit erfolgt die KK-Spiegelumbuchung z.B. beim Zugang eines kompletten Teilkonzerns für alle Gesellschaften dieses Teilkonzerns.
Prozentuale Veränderungen des Anteilsbesitzes
Bei der Erstkonsolidierung ('KK') werden die Konsolidierungsbuchungen auf dem Fremdanteilskonto bei Beteiligungsänderungen jetzt mit einem Buchungsschlüssel mit dem neuen BSL-Verwendungskennzeichen 'P' (Prozentuale Veränderung Anteilsbesitz) versehen. Nur falls es für den Spiegel keinen Buchungsschlüssel mit BSL-Verwendungskennzeichen 'P' gibt, wird wie bisher ein Buchungsschlüssel mit BSL-Verwendungskennzeichen 'N' (Laufende Veränderung) verwendet. Damit können unterschiedliche Sachverhalte in der Spiegeldarstellung weiter differenziert werden.
Eine neue eigenständige Funktion dient der korrekten Verarbeitung von konzerninternen Verkäufen von Anteilen an verbundenen Unternehmen. Diese Funktion kombiniert die bisher unabhängigen Funktionen für den Abgang und den Zugang von Anteilen und sorgt für die erforderliche Darstellung, dass sich aus Konzernsicht nichts ändert.
Zur Beschreibung dieses Vorgangs wurden für den Anteilsbesitz zwei neue Buchungsschlüssel-Verwendungskennzeichen eingeführt:
Buchungsschlüssel mit diesen Verwendungskennzeichen wurden in den LieferBatch-Dateien (s.o.) ergänzt. Falls der LieferBatch-Standard nicht eingesetzt wird, müssen Buchungsschlüssel mit diesen Verwendungskennzeichen bei Bedarf manuell vom Anwender erfasst werden.
Für eine Anteilsbesitzbewegung mit dem Buchungsschlüssel mit Verwendungskennzeichen 'B17' sind zusätzlich die Eingaben des Mehr-/Mindererlöses, des zugehörigen Erlöskontos und der Gesellschaft, an die verkauft wurde, erforderlich. Die Erfassungsmaske für Anteilsbesitzbewegungen (GESGESE) wurde um die "Verkauft an"-Gesellschaft erweitert. Bei der dort angegebenen Gesellschaft muss eine Anteilsbesitzbewegung mit dem Buchungsschlüssel mit Verwendungskennzeichen 'B18' erfasst werden. Beide Anteilsbesitzbewegungen müssen denselben Prozentwert spezifizieren. Differenzen werden von der Funktion "Beteiligungswerte prüfen/aktualisieren" gemeldet. In dieser ersten Version dieser Funktion müssen alle bestehenden Anteile verkauft werden.
Der Konzernkreis-Monitor (KTKGES) zeigt eine zusätzliche Statusspalte für die neue Verarbeitung an. Diese hat das Kürzel 'IK'. Liegen die oben beschriebenen Anteilsbesitzbewegungen vor, wird der Status durch die Statusaktualisierung auf [rot] gesetzt.
Die neue Funktion "Konzerninterner Verkauf IK" ist im Aktions- bzw. Objektmenü des Konzernkreis-Monitors (KTKGES) im Submenü "Kapitalkonsolidierung ..." angeordnet. Sie erzeugt zwei Konsolidierungsbelege:
Die hier beschriebene Buchungslogik gilt für vollkonsolidierte Tochtergesellschaften. Für quotal oder at Equity konsolidierte Gesellschaften gilt dies aber analog.
Direkte Fremdanteile sind von diesem Vorgang nicht betroffen und bleiben daher unverändert erhalten. Indirekte Fremdanteile können dagegen zwischen verkaufender und kaufender Muttergesellschaft unterschiedlich sein. Hierfür sind ggf. weiterhin manuelle Buchungen erforderlich.
In der vorliegenden ersten Ausbaustufe dieser Funktion wird nur der Fall unterstützt, dass verkaufende und kaufende Muttergesellschaft im selben Konzernkreis enthalten sind, die Tochter nur eine Muttergesellschaft hat und alle Anteile verkauft werden. In folgenden Ausbaustufen sollen weitere Konstellationen (teilweiser Verkauf von Anteilen, mehrere Muttergesellschaften, Verkauf vom übergeordneten Konzern an den Teilkonzern und umgekehrt, Verkauf zwischen parallelen Teilkonzernen) berücksichtigt werden.
Für Fremdanteile auf andere ergebniswirksame Konsolidierungsbuchungen (Buchungssatz '09' des 'FF'-Konsolidierungsbelegs) wird jetzt die zugrunde liegende Belegnummer in den Buchungstext geschrieben, um die Abstimmung zu erleichtern.
Bei der Fortschreibung der Fremdanteile ('FF') werden die Konsolidierungsbuchungen zur Anpassung des Vortrags bei prozentualen Beteiligungsänderungen jetzt mit einem Buchungsschlüssel mit dem neuen BSL-Verwendungskennzeichen 'P' (Prozentuale Veränderung Anteilsbesitz) versehen. Nur falls es für den Spiegel keinen Buchungsschlüssel mit BSL-Verwendungskennzeichen 'P' gibt, wird wie bisher ein Buchungsschlüssel mit BSL-Verwendungskennzeichen 'N' (Laufende Veränderung) verwendet. Damit können unterschiedliche Sachverhalte in der Spiegeldarstellung weiter differenziert werden.
Wenn für eine Equity-Gesellschaft ein Einzelabschluss vorliegt, dann wird aus dessen Jahresergebnis ein anteiliges Jahresergebnis (gemäß Ergebnisanteil der Muttergesellschaft) berechnet und in die Erfassungsmaske für die Equity-Fortschreibung eingestellt. Weitere Voraussetzungen sind, dass die Konten "Anteiliger Jahresüberschuss" und "Anteiliger Jahresverlust" im Konsolidierungsparameter 'EF' angegeben sind und noch kein anteiliges Jahresergebnis gebucht wurde. Der eingestellte Wert kann manuell geändert werden.
Der Konsolidierungsparameter 'EF' für die Equity-Fortschreibung enthält jetzt eine Eingabezeile (Konto, Buchungsschlüssel, Controllingobjekt) "Aktuelle Veränderung assoz. Untern.", das durch die Release-Konvertierung mit Konto und Controllingobjekt der Felder "Umbuchung Beteiligung" des Konsolidierungsparameters 'EK' (Equity-Erstkonsolidierung) belegt wird. Es sind aber auch abweichende Angaben möglich. Dieses Konto wird jetzt für die Gegenbuchungen zu den Buchungen für "anteiliger Jahresüberschuss" und "anteiliger Jahresfehlbetrag" verwendet. Neu ist auch die Möglichkeit zur Eingabe eines Buchungsschlüssels, während bisher immer ein Buchungsschlüssel mit Verwendungskennzeichen 'KM' (Konsolidierungsmaßnahmen) ausgewählt wurde.
Die in den Konsolidierungsparametern 'SK' und 'AE' angegebenen Schwellenwertkonten können auch einem Anlagenspiegel zugeordnet werden. Um dies ohne nachträgliche manuelle Anpassung zu unterstützen, wird jetzt bei der erstmaligen Buchung auf diesen Konten automatisch ein Anlagenobjekt erzeugt, das in die Buchungen eingetragen wird.
Rundungsdifferenzen für quotale Gesellschaften bei der SK- und AE-Spiegelumbuchung ('SU', 'AU') werden jetzt ausgeglichen. Für die Ausgleichsbuchung wird bevorzugt ein Buchungsschlüssel mit dem Verwendungskennzeichen 'Q' (Änderung Quote) verwendet. Alternativ wird ein Buchungsschlüssel für laufende Veränderungen (Verwendungskennzeichen 'L' oder 'N') verwendet.
Spiegelbewegungen für Kurseffekte und Umrechnungsdifferenzen aus der Umrechnung in die Parallelwährung werden von der SK- und AE-Spiegelumbuchung ('SU', 'AU') nicht mehr verarbeitet, da die Währungsumrechnung diese Werte ansonsten ein zweites Mal buchen würde.
Die "Zwischenergebniseliminierung im Anlagevermögen" ('ZA') buchte bisher immer den konzerninternen Verkauf zurück, so dass das Anlagevermögen aus Konzernsicht bei der verkaufenden Gesellschaft ausgewiesen wurde. Jetzt besteht die Alternative, dass das Anlagevermögen bei der kaufenden Gesellschaft ausgewiesen wird, was ja real der Fall ist, allerdings auch mit dem Wertansatz, mit dem das Anlagenobjekt bei der verkaufenden Gesellschaft ursprünglich geführt wurde.
Gesteuert wird dieses Verfahren über einen neuen Schalter "Gesellschaft für Buchung" im Konsolidierungsparameter 'ZA'. Dieser Schalter wird für alle bestehenden Sachverhalte auf 'A' (Buchung bei Abgangsgesellschaft) gesetzt, was dem bisherigen Verfahren entspricht. Alternativ kann der Schalter auf 'Z' (Buchung bei Zugangsgesellschaft) gesetzt werden. Dies ist auch der neue Defaultwert für alle neuen Sachverhalte (neu erfasste Konsolidierungsparameter). Bei Einstellung 'Z' wird wie folgt gebucht:
Die Zwischenergebniseliminierung im Anlagevermögen ('ZA') bricht jetzt mit einem Fehler ab, wenn die IC-Anlagenbewegungen für ein IC-Anlagenobjekt nicht einheitlich demselben Geschäftsbereich zugeordnet sind.
Mit Einführung der Ergebnisbuchungen und der Neutralisierungsbuchungen in den Releases 2009.2 bzw. 2010.0 wurde die frühere Konsolidierungsverarbeitung 'JU' (Ergebnisverrechnung im Konzern) überflüssig. Diese Verarbeitung wird nun vollständig deaktiviert, d.h. auch aus dem Aktionsmenü des Konzernkreis-Monitors (KTKGES) entfernt. Ebenso kann auch der Konsolidierungsparameter 'JU' nicht mehr gepflegt werden. Die Berechtigungen für diese Menüpunkte werden durch die Release-Konvertierung gelöscht.
Die Währungsumrechnung der Konsolidierungsbuchungen von Konzernwährung in Parallelwährung wurde an die Währungsumrechnung von Einzelabschluss-Buchungen angepasst. Dies betrifft u.a. folgende Themen:
Für die Arbeit mit IDL Forecast wird dringend empfohlen, einen Speicher von 1 GB zu reservieren (Angabe "-Xmx1024m" im Ziel der Symbolverknüpfung für den IDL Konsis-Aufruf). Bei Angabe einer geringeren Speicherreservierung wird jetzt eine entsprechende Warnungsmeldung ausgegeben. Der maximal anforderbare Speicher wird jetzt auch in der "Info"-Anzeige (Menü <Hilfe> --> <Info>) neben dem aktuell benötigten Speicherbedarf ausgewiesen
Die Aktionen zum Speichern (bisher nur als Button im Selektionsbereich für Gesellschaft und Geschäftsbereich) sowie zum Schließen (bisher in der Symbolleiste der Szenarioliste) eines Szenarios können jetzt durch Symbole in der globalen Symbolleiste ausgelöst werden. Speichern ist jetzt auch über das Menü <Datei> möglich. Ein weiteres Symbol ermöglicht es, die Szenarioliste nach Selektion eines Szenarios auszublenden. Dies ist auch über einen neuen Eintrag im Menü <Ansicht> möglich.
Menüeinträge, die keine direkte Aktion auslösen, sondern zunächst ein Fenster öffnen, werden jetzt einheitlich durch drei Punkte hinter ihrer Bezeichnung gekennzeichnet.
Die von einem Szenario abhängigen Fenster (Konten-/Controlling-/IC-Anzeige, Geschäftsfallanzeige, Saldo-Abweichungsanzeige und Berechnungsstatistik) werden erst dann eingeblendet, wenn ein Szenario geöffnet ist. Die Bezeichnung des geöffneten Szenarios wird dann in der Titelzeile der Anwendung und in der zugehörigen Anwendungsregisterkarte angezeigt.
Das Ein- und Ausblenden der Symbole für die Regeln im Tabellenbereich erfolgt künftig über einen Eintrag im Menü <Ansicht>, das dazu anwendungsspezifisch für IDL Forecast erweitert wurde. Bisher erfolgte diese Steuerung über einen Knopf im Tabellenfenster.
Das Menü <Ansicht> wurde für IDL Forecast um zwei weitere anwendungsspezifische Menüpunkte erweitert: "Fensteranordnung speichern" und "Fensteranordnung wiederherstellen". Beim Aufruf des ersten Menüpunktes werden die aktuellen Fensterpositionen gespeichert und beim Aufruf des zweiten wiederhergestellt.
Der Optionsdialog IDL Forecast wurde um einen Eintrag "Automatisch Gültigkeiten aktualisieren" erweitert. Hierüber kann die automatische Prüfung der Zellgültigkeiten nach Rückkehr aus einer Folgeanwendung ausgeschaltet werden. Alternativ kann die Prüfung dann über den neuen Eintrag <Zellsperren aktualisieren> im Aktionsmenü ausgelöst werden.
Die Optionen "Null/Leer-Unterscheidung", "Controlling-Planung aktivieren" und "Intercompany-Planung aktivieren" wurden dagegen aus dem Optionsdialog entfernt. Da diese Einstellungen die exportierten Salden beeinflussen, dürfen sie nicht vom Benutzer abhängen. Stattdessen erfolgen diese Einstellungen jetzt je Szenario und sind entsprechend im Szenario-Manager zu pflegen. Bitte beachten: Mit Installation des Release 2012.0 werden die Einstellungen aller Szenarien auf den Standard ("Null/Leer" und "Controlling" ja, "IC" nein) zurückgesetzt!
Das aktive Szenario wird in der Szenario-Liste jetzt durch einen geöffneten Ordner (bisher Pfeil und Einrückung) gekennzeichnet.
Ein neues Tabellensymbol in der Symbolleiste der Szenarioliste ermöglicht die Steuerung, welche Spalten der Tabelle angezeigt bzw. unterdrückt werden sollen. Bisher erfolgte diese Steuerung über das Objektmenü (rechte Maustaste) der Szenarioliste. Neu ist auch, dass jetzt die im Szenario enthaltenen Reports sowie der Benutzer und der Zeitpunkt der letzten Änderung (Speicherung) des Szenarios angezeigt werden können.
Der Assistent zur Definition eines Szenarios wurde um einen Navigationsbereich erweitert, in welchem die einzelnen Seiten des Assistenten aufgelistet sind. Dadurch weiß der Nutzer, wo er sich im Assistenten befindet (durch Fettschrift gekennzeichnet), welche Schritte noch erforderlich sind (Seiten mit fehlenden oder fehlerhaften Angaben sind mit entsprechenden Symbolen gekennzeichnet) und welche Seiten deaktiviert sind (graue Schrift). Durch Anklicken einer Seite springt der Assistent direkt zu dieser Seite, vorausgesetzt, alle vorhergehenden Seiten haben einen grünen Haken. Der <Fertig>-Knopf kann ggf. auf allen Seiten betätigt werden.
Das Fenster für die Szenario-Eigenschaften wurde um ein eigenes Registerblatt für die Spezifikation der geplanten Geschäftsbereiche je Gesellschaft erweitert. Den Szenario-Eigenschaften wurde außerdem eine Seite mit statistischen Informationen zu den Szenarien (z.B. Umfang des Szenarios) hinzugefügt.
Die Anzahl der in der Planung verwendeten Konten kann jetzt durch die Verwendung von Planungsverdichtungskonten reduziert werden. Bei Zuordnung eines Kontos zu einem Planungsverdichtungskonto im Kontenstamm (s.o.) wird das Konto nicht mehr im Planungsformular aufgelistet. Auf einem Konto vorhandene Ist-Daten werden auf dem Planungsverdichtungskonto saldiert. Dies gilt auch für das Einladen von Salden auf der Forecast- und der Plan-Datenart.
Es ist jetzt möglich aus dem Planungsformular heraus die Übersichten "Konten" (KTO), "Positionen" (POS), "Positionen+Konten-Zuordnungen" (POSKTO) und "Report-Zeilenbeschreibungen" (REPZEI) aufzurufen. Dazu wurden diese Menüpunkte im Aktionsmenü ergänzt. Beim Aufruf werden ggf. die Schlüssel der selektierten Zelle als Parameter übergeben.
Die Navigation innerhalb des Formulars ist jetzt auch mit der Tabulator-Taste möglich. Die Schreibmarke springt dann in die nächste Zelle.
Neben den innerhalb des Regelwerkes hinterlegten global wirkenden Parametern (z.B. Zahlungsverhalten, PWB, Steuer) können jetzt auch Parameter mit gesellschafts- und periodenspezifischen Werten definiert werden (z.B. Steuersatz). Hierbei erfolgt die Wertermittlung bei Anwendung einer Regel in Stufen: Ist ein schlüsselspezifischer Wert definiert, wird dieser verwendet, als nächstes ein Wert mit nur teilweiser Zuordnung zu Schlüsseln und ansonsten gilt der globale Wert. Alle Daten, die einen Prozentwert darstellen, können als ein solcher Parameter definiert werden.
Parameterwerte sind im Eigenschaftenfenster des Szenariodialogs eingebbar. Parametername und -wert können direkt eingegeben werden. Der Parametername muss mit '$' beginnen. Gesellschaft und Periode sind per Doppelklick im Auswahldialog wählbar. Jeder verwendete Parameter muss einen Standard-Eintrag (d.h. ohne Gesellschaft und Periode) enthalten. Bestätigen des Fensters mit <OK> rechnet das Szenario automatisch mit den neuen Parametern durch. Über einen Knopf im Eigenschaftenfenster lassen sich die Parameter auch aus einem anderen Szenario übernehmen.
Soll ein solchermaßen definierter Parameter in einer Regel verwendet werden, so ist dies durch eine Parameterangabe (z.B. "$PWB") zu spezifizieren. Alle Felder, in denen dies möglich ist, sind gelb markiert (Farbe kann im Optionsdialog geändert werden). Die Fenster der Regelassistenten enthalten einen Knopf, über den eine Liste aller verfügbaren Parameter angezeigt werden kann. Für Regeln, die auf einen nicht definierten Parameter verweisen, wird eine Warnung ausgegeben. Diese Regeln werden auch in der Anzeige der Regelvorlagen markiert.
Eine neue Prüffunktion (Aufruf im Aktionsmenü) listet alle Referenzen auf Parameter in den Regeln des aktuellen Szenarios auf, die nicht innerhalb des Szenarios definiert sind. Eine weitere Funktion ermöglicht die Anzeige der Belegung der Parameter für die aktuell selektierte Periode. Wenn die Parameter eines Szenarios geändert wurden, erscheint beim nächsten Laden des Szenarios ein Dialog mit der Frage, ob die Änderungen übernommen werden sollen
Die Assistenten zur Definition von Regeln wurden um einen Navigationsbereich erweitert, in dem die einzelnen Seiten des Assistenten aufgelistet sind. Dadurch weiß der Nutzer, wo er sich im Assistenten befindet (durch Fettschrift gekennzeichnet), welche Schritte noch erforderlich sind (Seiten mit fehlenden oder fehlerhaften Angaben sind mit entsprechenden Symbolen gekennzeichnet) und welche Seiten deaktiviert sind (graue Schrift). Durch Anklicken einer Seite springt der Assistent direkt zu dieser Seite, vorausgesetzt, alle vorhergehenden Seiten haben einen grünen Haken. Der <Fertig>-Knopf kann ggf. auf allen Seiten betätigt werden.
Auf der Seite "Periodensteuerung" von Regel-Assistenten wurde ein Knopf <Übernehmen von ausgewählten Zellen> ergänzt. Dieser aktiviert die Periodensteuerung und stellt die Perioden der aktuell im Planungsformular selektierten Zellen automatisch in die Auswahlliste. Die Regel-Assistenten wurden außerdem um einen Knopf erweitert, mit dem in der rechten Selektionskomponente genau die Konten ausgewählt werden, die aktuell im Tabellenbereich ausgewählt sind.
Zahlungsziele werden künftig so interpretiert, dass alle Forderungen genau nach Ablauf der angegebenen Anzahl von Tagen bezahlt werden. Bisher wurde davon ausgegangen, dass die Forderungen gleichverteilt bis zu diesem Zeitpunkt bezahlt werden.
Die Angaben der Zahlungsziele in Tagen in der Umsatz- und der Materialregel bleiben jetzt in der Regelvorlage und den erzeugten Geschäftsfällen erhalten und werden beim erneuten Öffnen der Regelvorlage sowie in der Geschäftsfallübersicht angezeigt.
Beim Öffnen des Assistenten für eine neue Überleitungsregel wird automatisch eine Überleitungszuordnung für jedes im Tabellenbereich selektierte Konto vorgeschlagen. Die Überleitungsregel ermöglicht außerdem, mehreren oder allen Zuordnungen auf der rechten Seite dasselbe Konto zuzuordnen. Zu diesem Zweck wurde ein Kontoauswahlfeld mit dem Knopf "Ausgewähltes Konto als Zielkonto aller markierten Überleitungen übernehmen" ergänzt. Weiterhin gibt es folgende Änderungen:
Der Steuersatz in Umsatz-, Material-, Ertrags- und Aufwandsregeln kann künftig alternativ zur Referenz auf ein statistisches Konto auch als fester Wert in der Regel eingegeben werden.
In Umsatz-, Material-, Aufwands-, Ertrags-, Bezugswert- und Rückstellungsregeln ist jetzt ein negativer Bezugswertfaktor erlaubt. Dies ist z.B. für Anwender notwendig, die zwischen Aufwands- und Ertragskonten nicht durch unterschiedliche Bilanz/GuV-Kennzeichen unterscheiden.
In der Rückstellungsregel ist jetzt auf der ersten Seite ebenso wie in der Bezugswertregel und den anderen Regeln mit Bezugswert ein Standard-Bezugswert einstellbar, welcher dann automatisch für alle Kontenzuordnungen übernommen wird.
Die Investitionsregel und die Materialaufwandsregel wurden um die Möglichkeit der Angabe für Vorsteuern erweitert. Dazu enthält der Regelassistent eine zusätzliche Seite zur Eingabe der Vorsteuer-Parameter.
In der Auflösungsregel und anderen Regeln mit Auflösung berechnet sich das Feld für den prozentualen Anteil jetzt immer automatisch auf den Restanteil. D.h. wenn die erste Periode mit 50% Auflösungsanteil festgelegt worden ist und der Nutzer eine weitere Auflösungsperiode anklickt, dann wird der Rest von 50% automatisch in dem Feld "Anteil %" angezeigt. Jede Weitere Periode stellt den Anteil von 0% automatisch ein i.V.m. einer Meldung, dass 0% Anteil auf einen tatsächlichen Anteil angepasst werden muss.
In der Bezugswertregel wird jetzt auf den als Buchungskonten (Soll) ausgewählten Konten unabhängig vom Bilanz/GuV-Kennzeichen des Bezugswertkontos immer im Soll gebucht, sofern der Bezugswertsaldo positiv ist. Umgekehrt wird auf den als Buchungs-Gegenkonten (Haben) ausgewählten Konten immer im Haben gebucht, sofern der Bezugswertsaldo positiv ist. Bei negativem Bezugswertsaldo drehen sich die Soll/Haben-Kennzeichen der Buchung um. (Achtung: Bereits angelegte Bezugswertregelvorlagen zeigen beim Anwenden im Release 2012.0 u.U. ein anderes Verhalten als in vorherigen Releases und müssen entsprechend angepasst werden!)
Nach dem Öffnen eines Szenarios wird das Fenster für Regelvorlagen angezeigt, bevor die Regelvorlagen geladen werden. Das Fenster zeigt daher zunächst nur einen Hinweis, dass die Regelvorlagen geladen werden.
Das Kopieren von Regelvorlagen und Ordnern erfolgt künftig durch zwei Schritte: "Kopieren" (oder <Strg+C>) und die neue Aktion "Einfügen" (oder <Strg+V>). Bisher erfolgte das Kopieren sofort bei "Kopieren", wobei die Kopie im selben Ordner landete und dann verschoben werden musste.
Über das Objektmenü (rechte Maustaste) des Regelvorlagen-Baums kann jetzt ein Assistent zur Erzeugung einer Ordnerstruktur für Regelvorlagen gestartet werden. Zunächst ist anzugeben, ob sich die Ordnerstruktur gemäß Gesellschaften oder gemäß Positionen zusammensetzen soll. Desweiteren ist zu spezifizieren, nach welchen Regeln der Ordnername aus den verfügbaren Schlüsseln und Bezeichnungen zusammengesetzt werden soll. Nach Bestätigung wird für jede Position bzw. für jede Gesellschaft ein Ordner mit dem entsprechenden Namen erzeugt.
Die Eigenschaften einer Regelvorlage haben jetzt den Eintrag einer Liste aller in der Vorlage verwendeten Parameter (s.o.).
Eine Geschäftsfallgruppe erhält jetzt als Bezeichnung den Namen der Regelvorlage. Die zugehörigen Geschäftsfälle erhalten als Bezeichnung die jeweilige Periode.
Bei Markierung eines statistischen Kontos, das als Faktor (z.B. als Steuersatz) benutzt wird, wird jetzt eine Liste aller Geschäftsfälle angezeigt, die sich auf dieses Konto beziehen.
In der Geschäftsfallanzeige wird jetzt die betreffende Periode ausgewiesen. Regeln innerhalb einer Regelgruppe werden in der Geschäftsfallanzeige nach Perioden sortiert angezeigt.
Ein Parameterbezug (s.o.) wird in der Geschäftsfallanzeige hinter der betreffenden Wertanzeige dargestellt (z.B. "Steuersatz 19% (Parameter: $UST)").
Der Mauszeiger wechselt beim Zeigen auf eine Kontenverküpfung in der Geschäftsfallanzeige auf ein Handsymbol um anzuzeigen, dass mit einem Mausklick eine Folgeanzeige ausgelöst werden kann.
Beim Löschen eines Geschäftsfalls können jetzt auch alle Werte, die durch den Geschäftsfall auf Konten erzeugt wurden, mit gelöscht werden, während die Werte, die in die Regel eingesetzt werden, erhalten bleiben. Der Dialog <Sollen auch die Werte der Geschäftsfälle gelöscht werden?> bietet dazu eine entsprechende Option ("Ja, mit Werten") an.
Die Bezeichnungen der durch Regeln erzeugten Veränderungen wurden überarbeitet. U.a. werden jetzt bei Forderungen, Verbindlichkeiten und anderen Bilanzkonten Nummer und Kurztext des Bezugskontos aus der GuV angegeben.
In der Geschäftsfallansicht einer Überleitungsregel wurden bisher nur die Prozent-Anteile angezeigt, die übergeleitet werden. Künftig werden auch die Beträge angezeigt.
Die T-Konten-Darstellung der Kontenanzeige wurde überarbeitet. U.a. werden dort jetzt wie in der Listendarstellung Regelsymbole angezeigt und die Markierung eines Geschäftsfalls in der Geschäftsfallanzeige markiert auch die zugehörigen Kontoveränderungen.
An der Saldo-Abweichungsanzeige wurden folgende Änderungen vorgenommen:
Verschiedene Funktionen von IDL Forecast wurden zwecks Reduzierung der Antwortzeiten überarbeitet. Dies betrifft insbesondere folgende Aktionen:
Die Report-Idents (RID) wurden innerhalb der Datenbank in eine neue Tabelle (K064 statt K021) verlagert. Weiterhin werden die Texte für Report-Idents nicht mehr unter dem Objekttyp 'AGB', sondern unter dem Objekttyp 'RID' geführt. Für den normalen Anwender ändert sich dadurch fast nichts. Diese Umstellung wirkt sich vielmehr vor allem auf individuelle Export-Schnittstellen (z.B. für MIS/OLAP-Systeme) aus.
Auswirkungen hat diese Umstellung i.W. auf Berechtigungsdaten. Die Angaben für die Objektberechtigung von Report-Idents werden künftig auch unter dem Objekttyp 'RID' (statt bisher 'AGB') geführt. Die Berechtigung für Report-Idents kann in der Vorbelegung (VORADMIN) unabhängig von der Berechtigung für Positionspläne festgelegt werden.
Ein weiterer Vorteil dieser Umstellung ist, dass sich Report-Idents und Positionspläne nicht mehr denselben Namensraum teilen. D.h. es können Report-Idents definiert werden, die denselben Schlüssel haben wie ein Positionsplan.
Das bisherige "Kennzeichen Default-Report" (für Formularerfassung) wurde bei dieser Gelegenheit in zwei Kennzeichen aufgeteilt: "Kennzeichen Formularerfassung" (geeignet / nicht geeignet) und "Kennzeichen Default-Report" (Standard für Formularerfassung).
In diesem Zusammenhang wurde auch geändert, dass Reportgruppen künftig nicht mehr in der Tabelle der Report-Idents geführt werden. Dementsprechend ist der Report-Typ 'G' entfallen. Vielmehr gibt es zur Pflege der Reportgruppen jetzt eine eigene Anwendung "Reportgruppen", die auch mit dem Kurzwort 'RPG' aufgerufen werden kann.
Zur Pflege der Report-Idents (RID) und der Report-Zeilenbeschreibungen (REPZEI) gibt es jetzt die neue integrierte Anwendung "Reportdefinitionen", die auch mit dem Kurzwort 'REPDEF' aufgerufen werden kann. Diese Anwendung ermöglicht insbesondere eine intuitivere Pflege der Report-Zeilenbeschreibungen durch geeignete Bedienungsformen.
Ähnlich der Anwendung "Spiegeldefinitionen" zeigt diese Anwendung nach ihrem Aufruf sofort eine Liste der definierten Report-Idents mit ihren wesentlichen Eigenschaften an. Über entsprechende Symbole in den Symbolleisten können neue Report-Idents angelegt oder vorhandene bearbeitet, kopiert oder gelöscht werden.
Die Pflege der Stammdaten eines Report-Idents erfolgt über einen Assistenten, der aus zwei Seiten besteht. Auf der ersten Seite wird die Gültigkeit definiert und es können Bezeichnungen in mehreren Sprachen erfasst werden. Die zweite Seite enthält Eingabefelder für die übrigen Attribute Report-Typ, Spiegel, Referenz-Report-ID, Spaltenoptionen und Kennzeichen für die Formularerfassung.
Im unteren Teil des Bildschirms werden die Daten der Report-Zeilenbeschreibungen angezeigt. Dies erfolgt auf verschiedene Weise in verschiedenen Registerkarten:
In der Ansicht <Baum> kann die Reportstruktur mit der Maus definiert werden. Per Drag&Drop lassen sich die Zeilen in der Baumstruktur verschieben. Über Pfeil-Symbole können markierte Zeilen ein- oder ausgerückt werden. Dasselbe ist auch in der Ansicht <OLAP> möglich. Wenn ein Report geöffnet wird, der Einträge für "Zugeordnete Position" enthält, die hinter der jeweiligen Position stehen, wird eine Warnungsmeldung ausgegeben, dass diese Einträge beim Speichern entfernt werden (s.u.).
Ein weiteres Symbol ermöglicht die Anzeige einer Liste aller definierten Positionen, geordnet nach Positionsplänen, in einer zweiten Tabelle neben den Reportzeilen. Positionen aus dieser Liste können ebenfalls per Drag&Drop mit der Maus in die Baumdarstellung an der passenden Stelle eingefügt werden. Je nach Stellung der Position im Report und der Zuordnung von Konten werden bereits die gängigsten Zeilentypen vorgeschlagen. Dieses Verfahren ermöglicht insbesondere eine schnelle und intuitive Definition neuer Reports.
Die Zeilennummer wird nur noch in der Ansicht <Reportzeilen> angezeigt. Sie ist nicht mehr eingebbar, sondern wird vielmehr automatisch anhand der grafisch definierten Reihenfolge der Zeilen aufsteigend mit Abstand 1 vergeben und kann daher von der ursprünglichen Nummerierung abweichen..
Die dezidierte Bearbeitung einer Report-Zeilenbeschreibung erfolgt durch einen Assistenten, der über das Objektmenü (rechte Maustaste) der Zeile oder nach Markierung der Zeile durch das Bleistift-Icon der Symbolleiste der Tabelle aufgerufen werden kann. Der Assistent umfasst mehrere Seiten:
Die bisherige Anwendung "Report-Zeilenbeschreibungen" (REPZEI) ließ beliebige Kombinationen von Zeilentypen und Wertkennzeichen zu, obwohl diese teilweise nicht sinnvoll kombinierbar waren. Die neue Anwendung "Reportdefinition" setzt diese Kombinationen in sinnvolle Werte um, die bei der Reporterstellung in ähnlicher Weise verarbeitet werden. Diese Umsetzung kann vom Benutzer akzeptiert oder auch abgelehnt werden.
In diesem Zusammenhang wird der Zeilentyp 'R' (Postenzeile ohne Andruck) nicht mehr unterstützt. Stattdessen bietet der Zeilentyp 'E' (Summenzeile ohne Andruck (Vorlauf, negativ)) jetzt die Möglichkeit, dass der Summenspeicher im zweiten Durchlauf von dahinter liegenden Summenzeilen genutzt und dort negiert wird. Dies gilt allerdings wie bisher nicht für Spiegelreports.
Die Statusspalten werden in den Report-Übersichten (REP, REPK) jetzt direkt hinter der Versionsbezeichnung angezeigt, so dass sie im Normalfall ohne Blättern sichtbar sind. Unnötige Zusatzinformationen wie Kontenplan oder Typ des Positionsplans werden dagegen nicht mehr angezeigt.
Die Soll/Haben-Steuerung erfolgt jetzt nicht mehr durch die Reportoption, sondern durch ein eigenes Attribut des Report-Kopfsatzes und kann dadurch mit anderen Reportoptionen kombiniert werden. Die bisherige Reportoption 'N' (S/H-Steuerungen lt. Wert inkl. Buchungen) steht nicht mehr zur Verfügung. Das neue Eingabefeld für die Soll/Haben-Steuerung wird in allen Report-Kopfsätzen belegt und hat zusätzliche Eingabemöglichkeiten:
Für den Kapitalflussreport bleibt die S-/H-Steuerung ausgeschlossen (d.h. '-' muss eingetragen werden), da sie wegen des speziellen Aufbaus des Reports nicht funktionieren würde. Spiegelreports können jetzt dagegen mit einer Soll/Haben-Steuerung ungleich '-' versehen werden (s.u.).
Das Schreiben von "Positionssalden aus Reports" (POSSAL) wird jetzt nicht mehr durch die Reportoption gesteuert, sondern durch ein eigenes Attribut des Report-Kopfsatzes. Die bisherigen Reportoptionen 'P' (Bilanz/GuV-Report mit Positionssalden mit Gesellschaft) und 'S' (Bilanz/GuV-Report mit Positionssaldenausgabe) stehen nicht mehr zur Verfügung. Das neue Eingabefeld "Steuerung Positionssaldenausgabe" hat dieselben Ausprägungen 'P' und 'S', die jetzt aber mit anderen Reportoptionen kombiniert werden können.
Die Erzeugung eines Reportergebnisses mit komplettem Kontenaufriss wird jetzt nicht mehr durch die Reportoption gesteuert, sondern durch ein eigenes Attribut des Report-Kopfsatzes. Die bisherigen Reportoptionen 'K' (Bilanz/GuV-Report mit komplettem Kontenaufriss lt. POSKTO) und 'L' (Bilanz/GuV-Report mit komplettem Aufriss aller gültigen Konten lt. POSKTO) stehen nicht mehr zur Verfügung. Das neue Eingabefeld "Steuerung Komplettaufriss" hat dieselben Ausprägungen 'K' und 'L', die aber jetzt mit anderen Reportoptionen kombiniert werden können.
Die Reportoption 'I' (Report mit IC-Aufriss) steht jetzt auch für Spiegelreports (Reporttyp 'D') zur Verfügung. Unterhalb der Konten werden dann als nächste Aufrissebene die Werte der einzelnen IC-Gesellschaften aufgelistet. Daten ohne Angabe einer IC-Gesellschaft werden separat aufgelistet. Durch entsprechende Spaltenoptionen ist es möglich, die IC-Gesellschaft in Spalten (ggf. kombiniert mit Spiegelspalten) anzeigen zu lassen.
Dieser Report ist als Gesellschaftsreport und als Konzernreport verfügbar. Da Konsolidierungsbuchungen keine direkte Angabe einer IC-Gesellschaft enthalten, werden sie immer wie Daten ohne IC-Gesellschaft behandelt. Es wird daher empfohlen, die Steuerung "Einschränkung Summenabschluss/Konsolidierungsbuchungen" im Report-Kopfsatz auf 'S' (Report nur mit Summenabschluss) einzustellen.
Eine Soll/Haben-Steuerung kann jetzt auch für Spiegelreports angegeben werden und wird bei der Erstellung von Spiegelreports ausgewertet. Die Zuordnung auf eine Position wirkt dabei immer auf das gesamte Konto und wird dementsprechend durch die Summe aller Spiegelspalten gesteuert. Die Zuordnung kann vom Saldo (Summe Spiegelbewegungen) oder von der Summe aus Saldo und Buchungen abhängig gemacht werden. Die Einstellung '-' (entsprechend dem bisherigen Verhalten) für die Soll/Haben-Steuerung bewirkt jetzt nicht mehr, dass die Werte ggf. auf beiden Positionen ausgewiesen werden, sondern sorgt (wie beim Bilanz/GuV-Report) für den Ausweis auf der Position, deren Bilanz/GuV-Kennzeichen mit dem Bilanz/GuV-Kennzeichen des Kontos übereinstimmt.
Die neue Reportoption 'R' kombiniert für einen Bilanz/GuV-Report (Reporttyp 'E') die Reportoptionen 'C' (Report aus Controllingsalden) und 'T' (Report mit Teilkonzernaufriss) und ermöglicht somit einen Report nach Umsatzkostenverfahren (Zuordnung der Controllingsalden auf Positionen gemäß Controllingkennzeichen 1) mit Aufriss nach Teilkonzernen. Bei Konten ohne Controllingaufriss wird der Kontensaldo verarbeitet. Mit der Reportoption 'R' erstellte Reports haben folgende Aufrissstufen unterhalb des Kontos sofern vorhanden:
Mit entsprechenden Spaltenoptionen können die Teilkonzerne der ersten Ebene in Spalten dargestellt werden. In den Zeilen werden dann ggf. die untergeordnete Teilkonzerne der zweiten Stufe oder die Controllingobjekte aufgeklappt.
Des Weiteren kann der Controllingreport (Reporttyp 'C' / Controllingkennzeichen 1 in Spalten) jetzt mit der Reportoption 'T' (Report mit Teilkonzernaufriss) versehen werden. Dieser Report enthält dann die folgenden Aufrissstufen sofern vorhanden:
Mit entsprechenden Spaltenoptionen können die Controllingobjekte (z.B. Kostenstellen) in Spalten dargestellt werden. In den Zeilen werden die Teilkonzerne ggf. zweistufig aufgerissen.
In der Tabelle "Spaltenoptionen" (SPO) wurde ein Schalter "Gruppierung Wiederholungsspalten je Objekttyp" ergänzt. Dieser Schalter ist anzugeben, wenn ein "Objekttyp für Reportspalten" für die Spaltenoption ausgewählt wurde, so dass die Objekte der ersten Aufrissstufe des Reports (z.B. Teilkonzerne, Gesellschaften) in Spalten nebeneinander angezeigt werden. Von Bedeutung ist der neue Schalter, wenn mehrere Spalten (SPA) dieser Spaltenoption als wiederholbar (d.h. ohne das Kennzeichen "Nicht je Schlüssel wiederholen") definiert wurden. Dann ermöglicht der neue Schalter folgende alternative Darstellungen:
Über die Spaltenoption ist es möglich eine Spalte zu definieren, die den Wert aller Zeilen im Verhältnis zu einer Bezugsposition (z.B. Umsatz, Bilanzsumme) als Kennzahl darstellt. Wenn man einen solchen Report in gedrehter Ansicht anzeigte, also z.B. als Teilkonzernreport mit Spalten je Teilkonzern, so bezog sich diese Kennzahl immer auf den Wert des Gesamtkonzerns. Diese Regel wurde mit dem Release 2012.0 geändert. Künftig bezieht sich die Kennzahl immer auf den Wert der Bezugsposition für den Schlüssel der Spalte, also z.B. den Wert je Teilkonzern.
Im Selektionsbereich der Reportergebnisanzeige (REPERG) wurde ein Schalter "IC-Gesellschaft anzeigen" ergänzt. Bei Eingabe eines 'X' wird eine zusätzliche Spalte angezeigt, die für Kontenzeilen eine dem Konto fest zugeordnete IC-Gesellschaft ausweist. Diese Anzeige war bis zum Release 2010.0 standardmäßig erfolgt und ist dann entfallen. Bitte beachten Sie, dass diese Angabe aktuell aus dem Kontenstamm ermittelt wird, also nicht Bestandteil des festgeschriebenen Reportergebnisses ist.
Der neue Baustein IDL Workflow ermöglicht die Modellierung von Arbeitsabläufen (Workflows) in IDL Konsis. Voraussetzung für die Anwendung dieses Bausteins ist die Konfiguration einer JDBC-Verbindung zur Datenbank (s.o.). Die mit dem Release 2012.0 freigegebene erste Stufe dieses Bausteins umfasst eine Funktion zur grafisch-interaktiven Erfassung und Darstellung von Arbeitsabläufen, sowie eine Funktion zur Abarbeitung dieser Workflows mit Statussetzung und integrierter Aufrufmöglichkeit von IDL Konsis-Anwendungen.
Die beiden Anwendungen "Workflow-Editor" und "Workflow-Aufgaben" sind in dem neuen Menü <Workflow> enthalten, das im Menübaum als Submenü im Zweig <Extras / Systemadministration> enthalten ist. Die Workflow-Funktionalität steht allen Anwendern ohne zusätzliche Lizenz zur Verfügung.
Der Workflow-Editor kann auch mit dem Kurzwort WORKFLOWED aufgerufen werden. Nach Start der Anwendung wird zunächst eine Liste der bereits definierten Arbeitsabläufe angezeigt. Durch Doppelklick mit der Maus auf einen Arbeitsablauf öffnet der graphische Editor.
Alternativ kann zum Erstellen eines neuen Arbeitsablaufs auch das Stern-Symbol angeklickt werden. Ein neuer Arbeitsablauf ist dann in einem Assistenten mit einer Bezeichnung zu versehen.
Der Editor ist eine grafisch interaktive Anwendung, mit der ein Arbeitsablauf (Workflow) modelliert werden kann. Ein Arbeitsablauf wird aus folgenden Elementen zusammengesetzt:
Jede Aktivität kann über einen Assistenten näher definiert werden. Neben mehrsprachigen Bezeichnungen und Beschreibungen können Angaben zu Dauer oder Terminen der Aktivität und der verantwortliche Bearbeiter eingetragen werden. Eine Aktivität kann auch einer IDL Konsis-Anwendung mit Spezifikation der zugehörigen Parameter (ähnlich der Definition im Ablaufautomaten) zugeordnet werden.
Eine Aktivität kann auch einen kompletten Unter-Arbeitsablauf darstellen, so dass Arbeitsabläufe hierarchisch geschachtelt aufgebaut und damit auch komplexe Strukturen übersichtlich dargestellt werden können.
Ein so definierter Arbeitsablauf stellt erst einmal nur eine Vorlage dar. Über das Symbol <Arbeitsablauf starten> wird ein konkretes Exemplar des Arbeitsablaufs erstellt, dem zusätzlich ein Starttermin übergeben werden kann. Ein Arbeitsablauf kann auch mehrfach gestartet werden. Gestartete Arbeitsabläufe werden unter den "Workflow-Aufgaben" (s.u.) angezeigt.
Die Liste der Arbeitsabläufe zeigt an, wie oft ein Arbeitsablauf bereits gestartet wurde. Wurde ein Arbeitsablauf bereits gestartet, so kann er nicht mehr verändert werden.
Die Anwendung "Workflow-Aufgaben" kann auch mit dem Kurzwort WORKFLOWTA aufgerufen werden. Sie zeigt nach dem Aufruf eine Liste aller gestarteten Arbeitsabläufe an. Eine Beschränkung der Anzeige auf z.B. alle offenen Aktivitäten kann durch die Filterzeile vorgenommen werden.
Diese Liste ist vorerst nicht auf einzelne Benutzer beschränkt, auch wenn in den Aktivitäten Bearbeiter eingetragen wurden. Vielmehr kann jeder berechtigte Anwender die folgenden Schritte durchführen.
Durch Auswahl (Markierung) einer Aktivität oder eines Arbeitsablaufs wird dieser in einem Fenster im unteren Teil der Maske angezeigt. Die Aktivitäten und Meilensteine werden dabei mit einem Symbol versehen, das ihre Zustände anzeigt (z.B. abgeschlossen, als nächstes zu bearbeiten). Der Zustand eines Meilensteins wird abhängig vom Zustand der vorhergehenden Aktivitäten automatisch gesetzt.
Durch Doppel-Mausklick auf eine Aktivität öffnet ein Assistent. Dort ist es möglich, die jeweilige IDL Konsis-Anwendung zu starten, sofern die Aktivität einer Anwendung zugeordnet ist. Des Weiteren kann der Status gesetzt werden. Der Status kann auch auf einen niedrigeren Wert zurückgesetzt werden.
Die Steuerung der Meldungsunterdrückung beim Import im Optionsdialog <Import/Export> wurde überarbeitet und ist jetzt besser verständlich. Die bisherigen Einstellungen werden automatisch umgesetzt. Der Dialog enthält jetzt zwei Checkbox-Gruppen: <Start Import> und <Abschluss Import>.
Die Gruppe <Start Import> enthält als führende Checkbox "Startfenster unterdrücken". Damit wird angegeben, ob das erste Fenster mit der Anfrage, ob Fehler angezeigt werden sollen oder nicht, angezeigt wird. Nur wenn dieses markiert ist, wird die zweite Checkbox "Fehlermeldungen unterdrücken" aktiviert. Die Angabe in dieser zweiten Checkbox ersetzt die Eingabe im ersten unterdrückten Fenster.
Die Gruppe <Abschluss Import> enthält als führende Checkbox "Abschlussfenster unterdrücken". Damit wird angegeben, ob das abschließende Fenster mit statistischen Angaben zum Import angezeigt werden soll oder nicht. Nur wenn dieses markiert ist, wird die zweite Checkbox "Abschlussfenster automatisch drucken" aktiviert. Damit wird gesteuert, dass die auf dem Bildschirm unterdrückte Anzeige alternativ auf einem Drucker ausgegeben wird. Das ist für lang laufende Importvorgänge (z.B. über Nacht) interessant.
Für folgende Tabellen stehen jetzt Importanwendungen sowohl für den Import von Dateien als auch für den Import via DB-Tabellen zur Verfügung:
Die Standard-Import/Export-Formate ('#TXT', '#DB') für die zusätzlichen Tabellen werden mit dem Release 2012.0 in den Tabellen "Import/Export Format-Ident" (IEF), "Felder für Import/Export-Formate" (IEFDEF) und "Zuordnung Import-Felder zu Formaten" (IEFFEL) ausgeliefert. Individuelle Formate können dort ergänzt werden.
Die Aufrufanwendungen "Datenimport und -anzeige" (IMPORT) für den Datei-Import und "IE Job-Steuerungen" (IEJOB) für den Import über DB-Tabellen wurden um den Aufruf dieser Importe erweitert.
Der Import für Konsolidierungsverarbeitungen wird auch zum Einspielen der LieferBatch-Datei mit empfohlenen Zuordnungen für den Konsolidierungsreport benötigt.
Das Fehlerprotokoll wurde von sieben auf zwei Zeilen je Fehler (fehlerhaftes Feld und Fehlermeldung) reduziert.
Wird ein Import-Job bereits vor dem Start des Imports abgebrochen (z.B. bei der Meldung "Wollen Sie wirklich löschen?"), so wird der Job jetzt nicht mehr in den Fehlerstatus versetzt und kann somit erneut gestartet werden, ohne dass er zuvor kopiert werden muss.
Beim Aufrufen von IDL Konsis-Jobs aus dem IDL Importer hat es sich als unpraktisch erwiesen, alle Übergabeparameter für die Importanwendung im externen Aufruf in der %-Syntax zu übergeben. Alternativ ist es künftig auch möglich, dass die Werte in eine Datenbank-Tabelle geschrieben werden, aus der der IDL Importer dann seinerseits die Werte ausliest.
Diese neue Datenbank-Tabelle I005 enthält Spalten für alle relevanten Übergabeparameter und zusätzlich die Job-ID, den Menüpunkt der auszuführenden Funktion, den Namen der Datenbank und die Benutzer-ID.
Dieses neue Verfahren wird aktiviert durch den Eintrag "pluginlauncher.jar" im externen Menü-Aufruf. Für diesen Menü-Aufruf ist außerdem folgendes zu beachten:
Beispiele für externe Aufrufe:
Das Template muss angepasst werden, damit der IDL Importer-Job die Parameter aus der Tabelle I005 ausliest. Die Übertragung der Passwörter (SAP, IDL Importer und erneute Anmeldung am IDL Konsis) wurde auf Ebene der rstart-Kommandozeile realisiert.
Der konzernweite und der Konzern-/Teilkonzern-Datenaustausch wurden auf diverse Datenbank-Erweiterungen angepasst. Eine Kompatibilität zu früheren Releaseständen ist daher nicht gegeben.
Die Daten für Report-Idents werden wie bisher beim konzernweiten Datenaustausch verarbeitet, stehen allerdings jetzt in einer separaten Datei mit dem Suffix '.K064'.
Das Release 2012.0 enthält eine erste Fassung einer neuen Version des IDL Connector. Diese Version wird mit einem der nächsten Releases den bisherigen IDL Connector ablösen. Vorerst können beide Versionen noch parallel genutzt werden. Wir empfehlen jedoch insbesondere Benutzern mit intensiver Nutzung des IDL Connector, die neue Version bereits jetzt zu nutzen, damit die endgültige Umstellung zügig erfolgen kann.
In der vorliegenden Fassung umfasst der neue IDL Connector die Lesefunktion, jedoch noch keine Schreibfunktion und keine Funktion eines Erfassungsformulars. Folgende Möglichkeiten des bisherigen IDL Connector stehen dabei noch nicht zur Verfügung:
Der neue IDL Connector setzt mindestens die Version MS Office 2003 und das Betriebssystem Windows XP voraus. Bei MS Office 2010 muss im Sicherheitscenter im Menüpunkt „Einstellungen für den Zugriffsschutz" das Ausführen von AddIns zugelassen werden.
Der neue IDL Connector ist als eigenständige Anwendung realisiert und kann über ein Symbol auf der Oberfläche mit Verweis auf die ausführbare Anwendung IDL.IDLOffice.Office.exe gestartet werden. Standardgemäß wird die Variante für MS Office 32 Bit installiert. Wenn MS Office 64 Bit installiert ist, steht auch eine 64-Bit-Variante zur Verfügung. Bitte kontaktieren Sie in diesem Fall die technische Hotline der IDL, um die Installation entsprechend abzuändern.
Das Anwendungsfenster enthält auf der linken Seite eine Menüleiste mit den Menüs <Excel>, <Excel -> Extras>, <IDL KONSIS>, <Einstellungen>, <Einstellungen -> Aktualisieren> und <IDL OFFICE>. Auf der rechten Seite werden verschiedene Statusinformationen für die aufgerufenen Funktionen angezeigt.
Im Menü <Excel -> Extras> befindet sich der Menüpunkt "Add-In Hinzufügen", mit dem das Excel-Add-In für den neuen IDL Connector aktiviert wird. Zu diesem Zeitpunkt müssen alle Excel-Dokumente und -Anwendungen geschlossen sein.
Das Menü <Excel> ermöglicht den Aufruf von MS Excel, entweder für ein neues Dokument oder zum Öffnen eines bestehenden Dokuments. Nach Aktivierung des Add-Ins kann aber auch MS Excel direkt gestartet werden. Von dort aus wird bei Bedarf die IDL Connector-Anwendung automatisch gestartet.
Die Anmeldung (und auch Abmeldung) an einer Datenbank erfolgt im Menü <IDL KONSIS>. Dabei verbindet sich IDL Connector mit dem IDL Konsis-Server, da sämtliche Datenbank-Zugriffe des neuen IDL Connector über den IDL Konsis-Anwendungskern erfolgen. Daher erfolgt die Anmeldung auch über die Original IDL Konsis-Anmeldungsmaske.
Die Connector-Bezüge bestehender Excel-Mappen können auf das Format der Bezüge des neuen IDL Connector umgesetzt werden. Dabei können sowohl einzelne Dateien als auch ganze Verzeichnisse konvertiert werden. Entsprechende Menüpunkte befinden sich im IDL Connector-Menü <Excel -> Extras>. Bei der Konvertierung wird automatisch eine Sicherheitskopie der ursprünglichen Excel-Datei mit den alten Connector-Bezügen angelegt.
Ansonsten unterscheidet sich die Bedienung des neuen IDL Connector nicht wesentlich von der Bedienung des bisherigen IDL Connector. Die Masken zur Definition der Connector-Bezüge enthalten allerdings (mit Ausnahme von "System") keine Pflichteingabefelder mehr, werden aber ggf. gemäß den in den Anwendungseinstellungen des IDL Connector angegebenen Werten vorbelegt. Achten Sie bitte aber auch selbst darauf, dass bestimmte Schlüssel wie z.B. "Periode" und "Datenart" spezifiziert werden, da sonst ggf. die komplette Datenbanktabelle gelesen wird und unsinnige Summenwerte gebildet werden. Für Steuerparameter ("Modus", "Saldenoption") werden bei fehlender Angabe Defaultwerte verwendet.
Eine Anleitung für die ersten Schritte mit dem neuen IDL Connector ist als separate Dokumentation auf der Release-CD enthalten. Für weitere Informationen kontaktieren Sie bitte den technischen Support der IDL.
Im Erfassungsformular wurde ergänzt, dass bei den IC-Kontensalden jetzt je Controllingobjekt mehrere IC-Gesellschaften erfasst werden können. Das Erfassungsformular unterstützt jetzt auch benutzerdefinierte Dezimaltrenner.
In den Export-Funktionen verschiedener Stammdaten wurden neue Felder ergänzt.
Das interne Passwort (s.o.) wird auch von IDL Connector unterstützt.
Die Speicherauslastung und die Performance wurden optimiert. MS Excel 2007-Formeln werden durch Ausführung auf mehreren Prozessoren besser unterstützt.
Die Release-CD 2012.0 enthält ebenfalls die Komponente IDL Publisher, die zur Erstellung von Geschäftsberichten in Richtung Microsoft Word sowie ab dem Jahr 2013 für die XBRL-Berichtserstattung (z.B. für die Erstellung der E-Bilanz, den Veröffentlichen über den Bundesanzeiger oder den Bankenberichtsanforderungen (FinRep)) eingesetzt werden kann. Die Software für IDL Publisher wird nur bei Vorliegen der entsprechenden Lizenz installiert.
Bisher gab es zwei Möglichkeiten, die Baumstruktur eines Reports für die Darstellung in einem MIS/OLAP-System durch Zuordnung einer übergeordneten Position in den Report-Zeilenbeschreibungen (REPZEI) anzugeben:
Im Zuge der Realisierung der neuen Anwendung "Report-Definition" (REPDEF, s.o.) wurde die Bedeutung dieser beiden Zuordnungsmöglichkeiten wie folgt geändert:
Für die SAP-Anbindung wird mit diesem Release ein neuer einheitlicher Standard (pluginlauncher.jar mit IDL Importer) sowohl für das alte als auch für das neue Hauptbuch ausgeliefert. Dieser ersetzt mittelfristig die bisherigen Schnittstellen (kcusap.jar mit IDL Importer und kcusap.exe mit Funktionsbausteinen). Die bisherigen Schnittstellen werden ab dem Release 2014.0 nicht mehr unterstützt. Bitte stellen Sie Ihre Schnittstelle mit Unterstützung durch Ihren IDL-BI-Berater bis dahin auf den neuen Standard um. Fragen dazu beantwortet Ihnen Ihr IDL-BI-Berater oder der technische Support der IDL.
Die Release-CD 2012.0 enthält die aktuelle Fassung der DCW-Schnittstelle für das DCW-Release 3.50.
Die Schnittstelle wurde um Buchungsschlüssel für Verschmelzung erweitert.
Mit diesem Release werden folgende deutschsprachigen Dokumentationen im Verzeichnis "doku" aktualisiert oder ergänzt: