Beim ersten Aufruf von IDL.KONSIS.FORECAST 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 für das Release 2020 keine Umsetzungen für IDL.KONSIS in der Datenbank vor, da die Umsetzung der KVA-Schlüssel bereits im Rahmen der Release-Installation erfolgt (s.u.). Es muss trotzdem einmalig gestartet werden, um die Prüfung auf Konsistenz der Releasestände zu erfüllen.
Außerdem führt das Konvertierprogramm jetzt auch Änderungen für IDL.FORECAST durch, die bisher erst beim ersten Öffnen eines Szenarios erfolgten. Dies hat zur Folge, dass Szenarien, die mit dem Release 2016 Update 1 oder einer noch älteren Version erstellt und seitdem nicht mehr konvertiert wurden, nicht mehr auf die aktuelle Version konvertiert werden können. Diese Szenarien werden mit "nicht konvertierbar, bitte löschen" gekennzeichnet.
Folgende Menü-IDs sind in diesem Release neu in IDL.KONSIS.FORECAST 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 dienen.
Wie in früheren Versionen bereits angekündigt, werden mit diesem Release folgende Menü-IDs endgültig gelöscht. Stellen Sie vor der Installation des Release 2020 sicher, dass keine individuellen Referenzen (Berechtigungen, individuelle Menüstrukturen, Ablaufautomaten) auf diese Menü-IDs mehr bestehen!
Als Alternative zur vollständigen Pflege der Berechtigungen für alle Menüpunkte wird das Verfahren zur vereinfachten Pflege von kundenspezifischen Benutzergruppen 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.
Beim automatischen Anlegen eines Benutzers auf Basis eines Benutzers im Active Directory (AD) und eines Template-Benutzers in IDL.KONSIS.FORECAST werden jetzt der Name und der Vorname des Benutzers aus dem AD übernommen. So sind die Benutzer in der IDL.KONSIS.FORECAST-Benutzerliste auch mit technischen Schlüsseln identifizierbar.
Das Werkzeug "batchrunner" dient dem Remote-Aufruf einzelner Konsis-Funktionen, z.B. über die Kommandozeile. Die neue Menü-ID "BATCHAUTOM" ermöglicht dabei den automatischen Ablauf eines Ablaufautomaten durch einen externen Aufruf über das Programm "batchrunner". Im Aufruf von "batchrunner" muss dann "BATCHAUTOM" als Menü-ID für den Parameter /start und zusätzlich die Menü-ID der eigentlichen Automatensteuerung als Parameter /AUTO_MENID angegeben werden. Neu ist, dass der Ablaufautomat neben Verarbeitungsfunktionen jetzt auch Importanwendungen enthalten kann.
In der rechten unteren Ecke des Anwendungsfensters erscheint jetzt ein Symbol, mit dem von IDL bereitgestellte Nachrichten zu Produkten und Features heruntergeladen und eingesehen werden können. Die im folgenden Fenster angezeigten Nachrichten enthalten i.d.R. einen Verweis auf ausführlichere Informationen auf der IDL-Web-Seite. Voraussetzungen für diese Funktion sind erstens, dass diese im Optionsdialog (Seite "Allgemein") aktiviert wurde, was die Standardeinstellung ist, und zweitens, dass eine Internetverbindung verfügbar ist (ggf. ebenfalls in den Optionen zu konfigurieren).
Das Fenster für die Lizenzinformationen wurde mit einem Rollbalken versehen, damit der Inhalt auch auf Bildschirmen mit geringer Auflösung vollständig angesehen werden kann.
In Fehlermeldungen bezüglich fehlender Berechtigung wird jetzt die Aktion (Anzeigen, Ändern, Einfügen, Löschen, Kopieren) explizit genannt statt der bisherigen Aktionsnummer.
Wenn man beim Speichern einer durch den Excel-Export erzeugten Excel-Datei den Dateinamen ändert, dann wird jetzt automatisch der richtige Dateityp als Suffix (z.B. '.xlsx') an den Dateinamen angehängt, sofern er bei der Namensänderung entfernt worden war.
Für das Release 2020 wurde eine Verlängerung des KVA-Schlüssels (KVA = Konsolidierungsverarbeitung) und damit einhergehend der Umbau der Konsolidierungsbelegnummern vorgenommen. Wesentliche Argumente für dieses Projekt waren
Teil 1 des Umbaus ist die Verlängerung des eigentlichen KVA-Schlüssels von bisher zwei auf künftig sechs Stellen. Diese sechs Stellen werden wie folgt aufgeteilt:
Durch die Basis-KVA an den ersten beiden Stellen bleibt die vertraute Nomenklatur in weiten Teilen erhalten. Durch die zweistellige Nummer für individuell definierbare Abstimmgruppen wird deren mögliche Anzahl deutlich erhöht. Durch die separaten Schlüssel für latente Steuern und Vorträge im KVA-Schlüssel ist es einfacher, Konsolidierungsbuchungen für eine Basis-KVA einschl. ihrer latenten Steuern und/oder Vorträge zu selektieren.
Zu beachten sind folgende Besonderheiten:
Teil 2 des Umbaus ist die Verlängerung der Konsolidierungsbelegnummern von bisher 14 Stellen auf jetzt 20 Stellen. Die Belegnummer setzt sich künftig aus sieben Teilen zusammen:
Die Fortsetzungsnummer an den letzten beiden Stellen wird in den Fällen verwendet, in denen IDL bisher die zugehörigen KVA-Schlüssel für den Fall der Fälle über die Metadaten bereitgestellt hatte. Dies betrifft
Dadurch dass diese Folgenummern nicht mehr im KVA-Schlüssel enthalten sind, sondern nur in der Belegnummer auftreten, werden diese bislang mit gleichen Attributen definierten Datensätze in der KVA-Tabelle nicht mehr benötigt.
Zu beachten ist hier, dass die betroffenen KVAs ('KK', 'FK', 'EK', 'PM', 'PP', 'PA' und 'PT') in den Belegnummern grundsätzlich mit einer Nummer versehen werden. D.h. z.B. der erste Beleg für die Kapitalkonsolidierung erhält in der Belegnummer ab Stelle 13 'KK....00'. Die Konvertierung sorgt hier für die Beibehaltung der ursprünglichen Reihenfolge:
Damit werden jetzt auch die Belege in der korrekten zeitlichen Reihenfolge sortiert (bisher immer alphabetisch, also 'K0' bis 'K9' vor 'KK').
Im Rahmen der Release-Installation werden fast alle bestehenden KVA-Schlüssel und Belegnummern durch SQL-Skripte auf die neue Nomenklatur umgesetzt, da eine Umsetzung durch das Konvertierprogramm unzumutbare Laufzeiten bedeutet hätte. Auch die SQL-Konvertierung benötigt einige Zeit und kann je nach Größe der Datenbank bis zu einer Stunde dauern.
Zu beachten ist, dass die SQL-Konvertierung keine so detaillierte Fehlerbehandlung ermöglicht wie eine programmatische Konvertierung. Eine Datenbank-Sicherung vor dem Release Upgrade wird von IDL ohnehin immer dringend empfohlen, ist in diesem Fall aber unabdingbar.
Der KVA-Schlüssel wird in folgenden Tabellen umgesetzt:
Die Konsolidierungsbelegnummer wird in folgenden Tabellen umgesetzt:
Zusätzlich wird in der Tabelle K048 der bisherige KVA-Schlüssel (Stelle 13 bis 14 der Belegnummer) in einer neuen Spalte (sichtbar nur als interne Info-Spalte) festgehalten, so dass die alte Belegnummer für Zwecke der Revision immer rekonstruiert werden kann.
Des Weiteren wurde ein neues Auswahlobjekt 'KV1' eingeführt, das an allen Stellen verwendet wird, wo nicht der sechsstellige KVA-Schlüssel, sondern nur die zweistellige Basis-KVA benötigt wird. Dieser wird in folgenden Tabellen verwendet:
Nicht konvertiert werden KVA-Schlüssel bzw. Belegnummern in folgenden Tabellen:
Die betroffenen Schnittstellen für den Import nach Konsis wurden erweitert sofern erforderlich. Zu beachten ist:
Das Lesen von Daten aus der IDL.KONSIS-Datenbank sollte wie bisher funktionieren, sofern
Ansonsten muss eine individuelle Anpassung der Abfragen erfolgen. Das gilt auch für IDL.XLSLINK-Abfragen.
Die Verzweigung aus anderen Übersichten in die Stammdatenanwendungen erfolgt jetzt i.d.R. in die neuen Anwendungen mit Assistenten (z.B. KTODEF) und nicht mehr in die alten Anwendungen mit Selektionsbereich und Einzelsatzanwendung (z.B. KTO). Ggf. dabei übergebene Parameter (z.B. Kontonummer) sorgen dann dafür, dass ein Modell (z.B. Kontenplan) geöffnet und die Tabelle auf die entsprechende Zeile positioniert wird.
In den komplexen Stammdatenanwendungen (mit einer führenden und einer oder mehreren abhängigen Tabellen) wird zur Vermeidung von Konflikten verhindert, dass zwei Benutzer gleichzeitig dasselbe Modell (z.B. Kontenplan, Spiegel) bearbeiten. Um daraus resultierende unnötige Wartezeiten zu verhindern, besteht jetzt auch die Möglichkeit, ein Modell nur zum Lesen zu öffnen. Dann sind keine Daten ändernden Aktionen möglich und es wird auch keine Sperre für andere Benutzer gesetzt. Das zugehörige Symbol im Kontextmenü der führenden Tabelle zeigt ein Auge und ein kleines Vorhängeschloss.
Der Datenartenstamm (FAC) wurde um einen Schalter "IC-Angaben bei Spiegelbewegungen" erweitert. Ist dieser Schalter gesetzt, müssen Spiegelbewegungen auf vollständig verprobten IC-Konten mit einer IC-Gesellschaft versehen werden (s.u.).
Für das "Country-by-Country-Reporting" wurde eine Lizenzkomponente eingeführt. Ohne diese Lizenz kann die Seite "Geschäftstätigkeiten" (Seite 5 des Assistenten) nicht mehr bearbeitet werden.
Spiegel mit Schattenrechnung sollen mittelfristig in IDL.KONSIS nicht mehr unterstützt werden. Als erste Maßnahme dazu wird jetzt das Anlegen neuer Spiegel mit Schattenrechnung nicht mehr zugelassen. Alternativ können je Spiegel mehrere Spiegelbereiche definiert werden.
Entsprechend der neuen Nomenklatur der Konsolidierungsverarbeitungen (s.o.) wurde das bisherige Buchungsschlüsselverwendungskennzeichen 'XZA' in 'XTA' umbenannt.
Die Tabellen "Positionen" und "Zuordnungen (Pos/Kto)" werden jetzt synchronisiert. D.h. die Selektion einer Position in der Tabelle "Positionen" führt dazu, dass diese Position auch in der Tabelle "Zuordnungen (Pos/Kto)" selektiert wird und umgekehrt.
Nach dem Öffnen eines Modells (Positionsplan) wird jetzt eine weitere Registerkarte "Zuordnungen (Kto/Pos)" angezeigt. Die Tabelle dieser Registerkarte zeigt wie "Zuordnungen (Pos/Kto)" die Position/Konto-Zuordnungen an, hier allerdings sortiert nach Kontonummer. Die Anzeige erfolgt nicht in Baumstruktur, sondern als flache Liste, da dies bessere Filter- und Sortiermöglichkeiten bietet. Änderungen sind auch in dieser Ansicht möglich durch Aufruf des Assistenten oder durch Editieren in der Tabelle, allerdings nicht durch eine Drag&Drop-Funktion.
In der Ressourcentabelle der Konten, die einer Position zugeordnet werden können, werden jetzt auch die IC-Aufrissverprobung und die Konsolidierungsverarbeitung der Konten in zusätzlichen Spalten angezeigt, so dass Konten darüber gefiltert werden können.
Im Zusammenhang mit dem Abgabe-Monitoring je Datenbestand, aber auch unabhängig davon ist es jetzt möglich, einzelne Datenbestände (Spalten im Einzelabschluss-Monitor (EA)) zu sperren, so wie dies bisher schon für die IC-Kontensalden der Fall war. Ist ein Datenbestand gesperrt, so wird dies im Einzelabschluss-Monitor in einer zusätzlichen Spalte neben dem Status des jeweiligen Datenbestands durch das Schloss-Symbol angezeigt. Nach dem Aufheben einer Sperre wird das Symbol eines geöffneten Schlosses angezeigt.
Die Information über die Sperre wird in zusätzlichen Datensätzen (Checkpoints) der Verarbeitungssteuerung (VERARB) abgelegt. Die Namenskonvention dieser Checkpoints ist "EA"+Anwendungskürzel für feste Daten (z.B. "EAKTO" für Kontensalden) bzw. "EA-"+Spiegelschlüssel für Spiegelbewegungen (z.B. 'EA-A' für Anlagenbewegungen).
Das Setzen der Sperren bzw. das Entsperren erfolgt im Monitor über neue Submenüs "Sperren" und "Entsperren" oder in den jeweiligen Übersichten oder Formularerfassungen über neue Einträge im Kontext- bzw. Aktionsmenü. Voraussetzung dafür ist in den Übersichten die eindeutige Vorgabe der Gesellschaft sowie bei Spiegelbewegungen auch des Spiegels. Das Sperren von Spiegelbewegungen durch die Aktionen im Einzelabschluss-Monitor wirkt dagegen immer auf alle Spiegel des jeweiligen Typs gleichzeitig.
Sofern die aktuelle Datenart Teil einer Datenartensequenz ist, wird die Sperre auch für alle in der Sequenz vorgelagerten Datenarten wirksam ("vererbt").
In den Formularerfassungen für gesperrte Datenbestände werden alle Eingabemöglichkeiten verhindert. Die Werte werden daher in grauer Schrift angezeigt. In den Übersichten weist eine Meldung im Selektionsbereich darauf hin, dass der Datenbestand gesperrt ist.
Die Sperren der einzelnen Datenbestände werden in allen Programmen, die diese Daten verändern (Vorträge, Überleitung, Generierungs- und Löschfunktionen, etc.), geprüft und wie die Sperre des gesamten Einzelabschlusses ausgewertet. Ausgenommen von der Prüfung ist die Währungsumrechnung, da hier nur die Werte in Konzern- und Parallelwährung verändert werden.
Die Statusanzeige für einen Datenbestand kann sich aber trotz gesetzter Sperre ändern, da hierüber auch die Konsistenz gegenüber anderen Datenbeständen visualisiert wird.
Im Aktionsmenü wurden Submenüs zum Sperren bzw. Entsperren einzelner Datenbestände ergänzt. Sofern einzelne Datenbestände gesperrt oder entsperrt sind, wird dies in zusätzlichen Spalten angezeigt. (s.o.)
Abgabetermine können jetzt in der Anwendung ABG je Gesellschaft differenziert vergeben werden. Abgabetermine mit Gesellschaft werden dann vorrangig vor Abgabeterminen ohne Gesellschaft (Anzeige mit dem Text "Alle") ausgewertet. Letztere gelten für alle Gesellschaften, für die kein eigener Abgabetermin spezifiziert wurde.
Ein Abgabetermin für eine Gesellschaft mit Checkpoint "Alle" hat Vorrang vor einem Abgabetermin für Gesellschaft "Alle" mit dem jeweiligen Checkpoint. Der Abgabetermin für eine Gesellschaft und einen Checkpoint wird somit nach folgender Priorität ermittelt:
In den Aktionsmenüs der Übersichten und Formularerfassungen wurden Aktionen zum Sperren und Entsperren der jeweils angezeigten Datenbestände ergänzt. Ist ein Datenbestand gesperrt, sind in der jeweiligen Formularerfassung keine Eingaben möglich. In den Übersichten wird darauf durch eine Meldung im Selektionsbereich hingewiesen. (s.o.)
Die Anzeige einer großen Anzahl von IC-Kontensalden wurde durch Reduzierung der Datenbankzugriffe deutlich beschleunigt.
Für verprobte, aber nicht saldenrelevante Spiegelbereiche wurde bisher nur eine Prüfung auf Konsistenz mit dem Kontensaldo durchgeführt. Jetzt erfolgt zusätzlich eine Prüfung auf Konsistenz mit den IC-Kontensalden, sofern es sich um ein Konto mit IC-Aufriss handelt.
Über einen neuen Schalter bei der Datenart (s.o.) kann jetzt gesteuert werden, dass die Angabe einer IC-Gesellschaft für Spiegelbewegungen auf voll verprobten IC-Konten Pflicht ist. Dies wird dann beim Erfassen der Bewegungen (Einzelsatz, Formularerfassung, Import) geprüft. Überdies werden fehlende Angaben in den Übersichten sowie auch im EA-Monitor durch einen [roten] Status gemeldet. Ohne Setzen dieses Schalters erfolgt die Prüfung wie bisher: Wenn es Bewegungen mit IC-Angabe gibt, dann muss sie auch vollständig sein. Gibt es keine Bewegungen mit IC-Angabe, wird dies nicht als Fehler behandelt.
Die Priorität, welche Meldung bei gleichzeitigem Vorliegen verschiedener Konstellationen, die zu Meldungen führen, in den Belegkopf geschrieben werden, wurde überarbeitet. Generell werden Fehler höher priorisiert als Warnungen und diese wiederum höher als Hinweise.
Die automatische Auszifferung der IC-Kontensalden eines Gesellschaftspaares wurde jetzt für den Fall erweitert, dass aus dem Vorsystem sowohl die Belegnummer als auch das Belegdatum übernommen wird. Wenn sowohl der Vergleich der Beträge je Belegnummer als auch der Vergleich der Beträge je Belegdatum zu Differenzen führt, dann wird jetzt in einem weiteren Schritt geprüft, ob eine Auszifferung für die IC-Kontensalden erfolgen kann, bei denen Belegnummer und Belegdatum übereinstimmen.
Die Anwendung "Belegkreise / Konsolidierungsverarbeitungen" (KVA) wurde gemäß der Erweiterung des KVA-Schlüssels (s.o.) angepasst. Insbesondere werden die Teile des Schlüssels (Basis-KVA, Abstimmgruppe, Kennzeichen für latente Steuern bzw. Vortrag) in der Tabelle als getrennte Spalten bzw. im Assistenten als getrennte Eingabefelder angezeigt.
Während die meisten hier angezeigten Daten weiterhin von IDL als Standard zur Verfügung gestellt werden, können wie gewohnt individuelle Schlüssel für die Basis-KVA-Schlüssel 'AE' (Aufwands-/Ertragskonsolidierung). 'SK' (Schuldenkonsolidierung) und 'MB' (manuelle Belege) angelegt werden. Beachten Sie hierbei folgende Unterschiede zur bisherigen Nomenklatur:
Schlüssel, die lediglich als Folgeschlüssel ansonsten gleichartiger Sachverhalte dienten (z.B. 'K0', 'K1' etc. für 'KK'), werden jetzt nicht mehr als eigenständige KVA-Schlüssel geführt und sind daher entfallen.
Beim Start der Anwendung "Konzern-Monitor" (KTKGES) sowie beim Speichern von Veränderungen in der Anwendung "Konzerndefinition" (KTKDEF) erfolgt automatisch ein Aufruf der Beteiligungsermittlung, damit die angezeigten Beteiligungsprozentsätze immer aktuell sind. Das ist jetzt nur noch für echte Konzerne der Fall, aber nicht mehr für reporttechnische Konzerne.
Für verschmolzene Gesellschaften wird jetzt auch in der Folgeperiode ein Status für erfolgte Vorträge angezeigt, obwohl diese Gesellschaften mit der Konsolidierungsart 'K' (keine Konsolidierung) geführt werden.
Die Schlüssel der IC-Clearing-Übersicht wurden auch an die neue Nomenklatur des KVA-Schlüssels (s.o.) angepasst. Die hier verwendeten Schlüssel sind (mit Ausnahme von 'SD') vierstellig bestehend aus der Basis-KVA ('SK' oder 'AE') und der Nummer der Abstimmgruppe ('00' bis '99').
Sämtliche Konsolidierungsfunktionen wurden auf die neue Nomenklatur der Belegnummer (s.o.) angepasst. Dies betrifft sowohl die verarbeiteten als auch die neu erzeugten Konsolidierungsbelege.
Konsolidierungsbelege der Kapitalkonsolidierung ('KK', 'FK', 'EK') werden jetzt grundsätzlich mit einer Folgenummer an den letzten beiden Stellen der jetzt 20-stelligen Konsolidierungsbelegnummer versehen (s.o.). Der jeweils erste Beleg erhält die Nummer '00'.
Die Anzeige der Übersicht "Verrechnen Unterschiedsbetrag" (VUB) wurde durch Optimierung der Datenbankzugriffe erheblich beschleunigt.
Konsolidierungsbelege aus der Verschmelzung, die bei gleichzeitiger Verschmelzung mehrerer Gesellschaften auf dieselbe aufnehmende Gesellschaft mehrfach vorkommen können ('PP', 'PM', 'PA', 'PT'), werden jetzt grundsätzlich mit einer Folgenummer an den letzten beiden Stellen der jetzt 20-stelligen Konsolidierungsbelegnummer versehen (s.o.). Der jeweils erste Beleg erhält die Nummer '00'.
Die Konsolidierungsbelegnummer wurde von 14 auf bis zu 20 Stellen verlängert (s.o.). Bestehende Konsolidierungsbelege und -buchungen werden automatisch auf die neue Nomenklatur umgesetzt. Neue Belege werden durch die jeweiligen Funktionen mit der neuen Nomenklatur erzeugt.
Sofern die bisherige Konsolidierungsbelegnummer aus Gründen der Revision noch einmal benötigt wird, kann der bisherige KVA-Schlüssel (Stelle 13 bis 14 der alten Belegnummer) in einer neuen Spalte (sichtbar nur als interne Info-Spalte) angezeigt werden.
Zur Selektion von Konsolidierungsbelegen und -buchungen nach Belegnummer in den Übersichten KONBEL und KONBUCH sowie beim Erfassen eines neuen Konsolidierungsbelegs stehen jetzt 7 Eingabefelder zur Verfügung:
Die vier letzten Felder sind je nach Sachverhalt optional belegt oder leer. Die Selektion für diese Teile lässt daher auch die Eingabe '*' zu zur Anzeige der Daten, in denen dieser Teil leer ist (z.B. Ausschluss von Vortragsbelegen).
In diesen wie auch in verschiedenen anderen Übersichten, in denen Belegnummern angezeigt werden, erfolgt die Ausgabe in einzelnen Spalten, die aber die gemeinsame Überschrift "Belegnummer" haben.
Die Priorität, welche Meldung bei gleichzeitigem Vorliegen verschiedener Konstellationen, die zu Meldungen führen, in den Belegkopf geschrieben werden, wurde überarbeitet. Generell werden Fehler höher priorisiert als Warnungen und diese wiederum höher als Hinweise.
Die Anzeige von Daten in der Prüfregelergebnis-Analyseübersicht wurde beschleunigt. Dies gilt insbesondere bei der Verwendung der Klausel "je Konto" in Verbindung mit sehr großen Kontenplänen.
In der Prüfregelergebnis-Analyseübersicht werden jetzt zusätzliche Bezeichnungen in den Zeilen ausgegeben. Das betrifft insbesondere Bezeichnungen für Spiegelbereiche, Spiegelspalten oder Buchungsschlüssel bei Prüfregeln für Spiegelbewegungen.
Bei der automatischen Erzeugung von Buchungen oder Konsolidierungsbuchungen für laufende Abschreibung werden bereits bestehende Buchungen für laufende Abschreibungen jetzt auch dann gelöscht, wenn in ihnen kein Anlagenobjekt angegeben ist. Dies ist u.a. dann hilfreich, wenn die Funktion "Kopieren Konsolidierungsbuchungen für reporttechnischen Teilkonzern" (REPKTK) mit dem Wechsel auf eine andere Datenart mit einem abweichenden Kontenplan verbunden wurde, so dass die bisherigen Anlagenobjekte nicht beibehalten werden konnten, sondern manuell ergänzt werden mussten, was allerdings für automatisch generierte Abschreibungsbuchungen nicht möglich war.
Das Antwortzeitverhalten von IDL.FORECAST wurde durch verschiedene Maßnahmen verbessert.
Szenarien, die mit dem Release 2016 Update 1 oder einer noch älteren Version erstellt und seitdem nicht mehr konvertiert wurden, können nicht mehr auf die aktuelle Version konvertiert werden. Diese Szenarien werden mit "nicht konvertierbar, bitte löschen" gekennzeichnet.
Wenn eine Gesellschaft des Szenarios schreibgeschützt ist oder die Berechtigung zum Ändern des Szenarios fehlt, dann wird die Gesellschaft nicht mehr gesperrt, d.h. andere Benutzer können die Gesellschaft des Szenarios öffnen, ändern und löschen.
In den Szenario-Eigenschaften werden jetzt die Auflösungseinstellungen angezeigt.
Um ein Szenario zu kopieren und dabei i.W. die Perioden anzupassen, wurde im Kontextmenü der Szenario-Übersicht die Aktion "im Szenario-Assistenten öffnen..." ergänzt. Im Assistenten wird dann das Szenario mit all seinen Eigenschaften angezeigt. Auf der Seite "Datenbereiche festlegen" gibt es neu die Möglichkeit, die angegebenen Perioden um ein Jahr vor- oder zurückzuschalten. Individuelle Tabellenblätter und Parameter werden dabei nicht übernommen und müssen daher ggfs. manuell importiert werden.
Für kopierte Szenarien wird jetzt festgehalten und angezeigt, wann und von welchem anderen Szenario diese kopiert wurden. Für Szenarien, die bereits vor dieser Erweiterung kopiert worden waren, kann nur das Kopierdatum, aber nicht die Quelle angezeigt werden.
Wenn ein Szenario für die gewählte Gesellschaft gesperrt ist, ist es jetzt trotzdem möglich, die zum Kopieren / Verteilen von Salden angelegten Profile anzuschauen und auch zu ändern.
Die Pflege von Planungsparametern unterliegt jetzt einer Berechtigungsprüfung. Zum einen muss die Berechtigung für die betroffene Gesellschaft und die jeweilige Aktion vorliegen, zum anderen muss generell die Berechtigung für den Menüpunkt 'PLANPARA' gegeben sein.
Nach Aktualisierung der Tabelle bleibt jetzt der vorherige Aufklapp-Zustand der Spalten erhalten. Bisher galt das nur für die Zeilen.
In Szenarien, wo dasselbe Jahr zwischen den Datenbereichen IST und FORECAST aufgeteilt und auch für den Datenbereich PLAN ausgewählt ist, werden jetzt die Jahressummen richtig berechnet.
Die Überleitung vom Datenbereich FORECAST in den Datenbereich PLAN erfolgt jetzt immer automatisch, wenn im Szenario definiert ist, dass die Regeln datenbereichsübergreifend wirken. Die Ausführung dieser Überleitung durch manuelle Aktion oder innerhalb eines Planungsablaufs ist nicht mehr möglich. Die Überleitung vom Datenbereich IST muss dagegen weiterhin manuell angestoßen werden.
In den Anzeigen "Saldo-Abweichungen" und "Plausibilitätsprüfung" wird jetzt das Soll/Haben-Kennzeichen der Beträge in einer separaten Spalte ausgewiesen, um die Folgebearbeitung in Excel zu vereinfachen.
Der Assistent für Einzelbuchungen wurde im Erscheinungsbild überarbeitet und vergrößert.
Wenn Datenbestände (Kontensalden, IC-Kontensalden, Controllingsalden) gesperrt sind (s.o.), können diese auch nicht durch die Plandaten aktualisiert werden.
In der Werkzeugleiste des Regelvorlagenbaums wurde ein neues Icon (Lupe) ergänzt. Hierüber wird eine Suche in den Regelvorlagen ausgelöst. Die Suche kann sich auf Konten, Parameter, Gesellschaften (Ges-Steuerung), Geschäftsbereiche (Ges-Steuerung), IC-Gesellschaften (IC-Steuerung), IC-Geschäftsbereiche (IC-Steuerung), Name der Regelvorlage oder Kommentare beziehen. Es werden allerdings nur Ergebnisse für Regelvorlagen angezeigt, für die der Benutzer mindestens Anzeige-Berechtigung hat. In der Ergebnisliste können die Regelvorlagen direkt geöffnet werden, entweder über das Kontextmenü oder einen Doppelklick, sofern ein Szenario geöffnet ist.
Umsatz-, Ertrags-, Materialaufwands- und Aufwandsregel unterstützen jetzt die Aufteilung eines Quellsaldos auf verschiedene Zielkonten. Dazu kann man auf der Zuordnungsseite analog zur Überleitungsregel zusätzliche Zuordnungen hinzufügen, die jeweils einen anzugebenden Prozentsatz des Quellwerts auf das jeweilige Zielkonto überleiten. Die Prozentwerte dürfen nicht negativ sein und müssen in Summe 100% ergeben. Steuerkonto und Steuersatz können ebenfalls per Zuordnung individuell eingestellt werden, wenn Umsatzsteuer bzw. Vorsteuer für die Regel aktiviert ist. Die Einstellungen für Zahlung, Steuerauflösung, PWB (Umsatzregel) und Sicherheitseinbehalt (Materialregel) können nicht je Zuordnung angegeben werden, beachten aber ggfs. die jeweiligen Ziel- und Steuerkonten. Rundungsdifferenzen werden verhindert.
In allen Regeln mit einer Funktion zur Zuordnung von Konten wurde auf den jeweiligen Assistentenseiten eine Suchfunktion ergänzt. Dabei kann nach Kontonummern, Kontobezeichnungen und Parametern gesucht werden. Die den Suchkriterien entsprechenden Konten werden durch eine blaue Umrandung gekennzeichnet, auf das erste davon wird die Anzeige positioniert. Ein Icon neben dem Suchfeld ermöglicht das Springen zur nächsten Fundstelle.
Alle Regeln mit Zahlungs- oder Auflösungskomponenten, deren Prozentwerte in Parametern oder statistischen Konten abgelegt waren, können jetzt einfach neu berechnet werden, wenn sich die Angaben in den Parametern bzw. statistischen Konten geändert haben. Bisher mussten die Regeln gelöscht und dann neu angewendet werden.
Auf der Gesellschaftsteuerungsseite der Regelassistenten wird jetzt durch ein schwarzes Kästchen auf Gesellschaftsebene angezeigt, dass unterhalb der Gesellschaft Geschäftsbereiche ausgewählt wurden.
Das Verfahren, um eine Gesellschaftssteuerung auf Gesellschaften und Geschäftsbereiche einzuschränken, wurde umgestaltet, so dass die Wirkung der Einstellung eindeutig ist.
Die Funktion "Anzeigen" im Kontextmenü des Tabellenablagefensters wurde (je nach aktuellem Zustand) durch die Aktion "Aktivieren" bzw. "Deaktivieren" ersetzt. Die 'M'-Formel-Veränderungen werden beim Deaktivieren der Tabelle gelöscht und beim Aktivieren wieder hergestellt.
Individuelle Tabellen können jetzt auch auf eine Teilmenge von Gesellschaften eingeschränkt werden. Dafür wurde, ähnlich wie bei den Regelvorlagen, eine Gesellschaftssteuerung ergänzt.
Das Tabellenablage-Fenster wurde um eine Spalte erweitert, in der Informationen über die eingestellte Gesellschaftssteuerung angezeigt werden.
Die Funktion "Tabellenblatt konfigurieren" ist jetzt immer aufrufbar, also auch dann, wenn die aktuelle Gesellschaft in der Gesellschaftssteuerung der Tabelle nicht selektiert ist.
Durch 'M'-Formeln in individuellen Tabellenblättern erzeugte Veränderungen werden nicht mehr wie manuelle Veränderungen behandelt und angezeigt. So können sie nicht mehr aus der Kontenaufrissanzeige heraus entsperrt und gelöscht werden, werden aber beim Löschen des Tabellenblatts mitgelöscht. Veränderungen, deren Formel beim Bearbeiten einer anderen Gesellschaft dieses Szenarios gelöscht wurde, werden beim Öffnen einer Gesellschaft automatisch gelöscht.
Periodenangaben in Formeln können jetzt Platzhalter enthalten. Hierbei stehen 'Q1', 'Q2', 'Q3' und 'Q4' anstelle der Monatszahl für die jeweiligen Quartale, 'J' für das ganze Jahr. Das Ergebnis ist immer die Summe der jeweils enthaltenen Perioden. Platzhalter funktionieren allerdings nicht in Verbindung mit Zellbezügen.
Zahlen und Perioden in Formeln und Zellbezügen werden jetzt immer in einem einheitlichen (deutschen) Format gespeichert, aber gemäß der Einstellung des jeweiligen Benutzers an der Oberfläche angezeigt und können auch in diesem Format eingegeben werden.
Der Status "Salden vorhanden" wird jetzt [rot] (bisher [gelb]), wenn es keinerlei GuV-Salden gibt. [Grün] bedeutet, dass mindestens ein GuV-Saldo vorhanden ist. Zustände von IC- und Controllingaufrissen werden nicht mehr in diesem Status dargestellt.
Der neue Status "IC-Aufriss" wird nur [grün], wenn alle IC-Aufrisse stimmig zu den Kontensalden sind. Differenzen auf vollständig verprobten IC-Konten führen zum Status [rot], negative Drittanteile auf anteilig verprobten IC-Konten zum Status [gelb]. Bis zur ersten Statusermittlung bleibt der Status [?], während [-] bedeutet, dass das Szenario ohne IC-Planung ist.
Der neue Status "CNT-Aufriss" wird nur [grün], wenn alle Controllingaufrisse stimmig zu den Kontensalden sind. Differenzen auf Controllingkonten führen zum Status [rot]. Bis zur ersten Statusermittlung bleibt der Status [?], während [-] bedeutet, dass das Szenario ohne Controllingplanung ist.
Unterhalb der Tabelle des Planungs-Monitors (PM) wird jetzt eine Infozeile mit Erläuterungen für fehlerhafte Stati ([rot] oder [gelb]) ausgegeben. Dort werden auch Ablauf und eingestellte Parameter des ausgewählten Ablaufs angezeigt.
In der Ressourcentabelle der Positionen, die einem Report hinzugefügt werden können, wird jetzt auch das Bilanz/GuV-Kennzeichen der Positionen in einer zusätzlichen Spalte angezeigt, so dass Positionen darüber gefiltert werden können.
Die Assistentenseite zur Pflege der Einschränkungen auf bestimmte Buchungsschlüssel oder Spiegelspalten kann jetzt vergrößert werden, so dass die Auswahlliste dann mehr Einträge anzeigt.
Die Einschränkung von Reportzeilen eines Kapitalflussreports auf bestimmte Konsolidierungsverarbeitungen wurde umgestellt vom Verweis auf einen KVA-Schlüssel auf den Verweis auf eine Basis-KVA (zumeist die ersten beiden Stellen des neuen erweiterten KVA-Schlüssels, s.o.). Hinweis: Diese Angabe kann nur durch die Anwendung REPZEI gepflegt werden, jedoch nicht durch die Anwendung REPDEF.
Die Berechnung der Report-Prüfsummen, sowohl bei der Reporterstellung als auch bei der Reportanzeige, wurde so angepasst, dass die neue Nomenklatur der Konsolidierungsbelegnummern (s.o.) keine Auswirkungen hat. So wird insbesondere für Reports, die noch mit der alten Nomenklatur der Konsolidierungsbelegnummer erstellt wurden, weiterhin die ursprüngliche Prüfsumme berechnet, so dass die Prüfsummenstati der Reportergebnisse [grün] bleiben.
Die Import-/Export-Formate wurden auf die aktuellen Datenbank-Erweiterungen angepasst:
Das Verhalten der Importanwendungen für Stammdaten bezüglich der Angabe von Kurzbezeichnungen (optionale oder Pflichtangabe, automatische Einstellung der ersten 10 Zeichen der Langbezeichnung) wurde an das Verhalten der jeweiligen Dialoganwendungen angepasst.
Die Laufzeit des Imports von IC-Kontensalden (TXTICKTOSAL) wurde durch verschiedene Maßnahmen deutlich reduziert.
Der konzernweite und der Konzern-/Teilkonzern-Datenaustausch wurden auf die aktuellen Datenbank-Erweiterungen angepasst. Eine Kompatibilität zu früheren Versionen ist daher nicht gegeben.
Das Programm von Laden der Teilkonzerndaten mit Anwendung einer Umsetzgruppe stellt in SK- und AE-Belegen die korrekte Reihenfolge der Gesellschaftsnummern in der Belegnummer (alphabetisch kleinere Gesellschaftsnummer vorne) her für den Fall, dass die alphabetische Reihenfolge durch die Umsetzung verändert wurde, damit eine eventuelle Wiederholung der Funktion mit den geladenen Daten zum selben Ergebnis kommt. Wenn nun aber SK- oder AE-Belege manuell erfasst worden waren, ohne dabei auf die korrekte Reihenfolge der Gesellschaftsnummern in der Belegnummer zu achten, konnte es passieren, dass zwei Belege mit derselben Belegnummer resultierten. In diesem Fall wurden nur die Buchungen für einen Beleg geladen, während die Buchungen des anderen Belegs verloren gingen. Die Korrektur der Reihenfolge der Gesellschaftsnummern in der Belegnummer erfolgt daher jetzt nur noch dann, wenn die Umsetzgruppe überhaupt eine Umsetzung von Gesellschaftsnummern vorsieht.
Die Logik zur Darstellung von Werten als positive oder negative Beträge in Abhängigkeit vom Bilanz/GuV-Kennzeichen wurde für den Fall überarbeitet, dass der oberste Knoten das Kennzeichen für statistische Mengen ('5') hat. In diesem Fall wird jetzt das Bilanz/GuV-Kennzeichen der Position der darunter liegenden Ebene (z.B. '8' für statistische Erträge) für alle untergeordneten Ebenen verwendet.
Beim Zurückschreiben von dekumulierten Werten auf GuV-Konten, die in Erfassungsreports von IDL.DESIGNER erfasst wurden, ist es jetzt nicht mehr notwendig, dass Nullwerte für im Berichtszeitraum unveränderte Werte übermittelt werden. Da dazu aber bereits vorhandene Daten vor dem Import gelöscht und aus der Vorperiode als Initialwert kopiert werden, muss der Import mit der Funktion "Löschen und Import ..." (Menü-ID TXL...) erfolgen.
Das Release 2020 enthält die letzte Fassung der DCW-Schnittstelle für das DCW-Release 3.50.