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.
Zusätzlich zu den Konvertierungen im Release 2016 Update 1 nimmt das Konvertierprogramm folgende Umsetzungen in der Datenbank vor:
Zusätzlich zu den Erweiterungen im Release 2016 Update 1 sind folgende Menü-IDs 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 bzw. IDLWIN dienen.
Folgende Menüpunkte sind ebenfalls neu, beziehen sich aber nicht direkt auf IDL.KONSIS.FORECAST-Anwendungen, sondern auf die für andere Produkte der IDL CPM Suite nutzbaren Webservices. Damit kann gesteuert werden, welche Benutzer über die anderen Produkte auf die jeweiligen Webservices zugreifen können.
Folgende Menüpunkte wurden mit diesem Release deaktiviert. Sie werden mit einem Folgerelease gelöscht werden. Bitte entfernen Sie bis dahin alle individuellen Verwendungen (Berechtigungen, Menüstrukturen) dieser Menüpunkte:
Der Menüpunkt Z-POSKTO (Positionen+Konten-Zuordnungen Drag&Drop) steht zwar nicht mehr als Anwendung zur Verfügung, dient aber der Berechtigungsvergabe für die analoge Funktion im Rahmen der Anwendung "Positionspläne" (POP).
Sofern diese Anwendungen direkt per Kurzwort aufrufbar waren, erfolgt bei der Kurzworteingabe eine automatische Umsetzung in das Kurzwort der jeweils als Ersatz zur Verfügung gestellten neuen Anwendung.
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.
Im Gegensatz zu der im vorherigen Absatz beschriebenen Verwendung der Berechtigungsstufe '0' war in vielen Anwendungen implementiert, dass die Berechtigungsangaben für die dem Benutzer zugeordnete Benutzergruppe je Menüpunkt vollständig gelten und die jeweiligen Angaben für die Referenz-Benutzergruppe überlagern, also auch dann keine Berechtigung besteht, wenn die Berechtigungsstufe leer statt '0' war. Dies wurde mit dem vorliegenden Release vereinheitlicht und bereinigt. Durch die Release-Konvertierung (s.o.) werden alle betroffenen leeren Berechtigungsstufen in die Stufe '0' umgesetzt, so dass sich für den Anwender nichts ändert. Trotzdem wird empfohlen, die Einstellungen zu überprüfen, ob sie dem gewünschten Verhalten entsprechen.
Die in einem Ablaufautomaten aufgerufenen Anwendungen werden jetzt durch die Ablaufsteuerung nicht mehr auf die Berechtigung zum Einfügen, sondern nur noch auf die Berechtigung zum Anzeigen von Daten geprüft. So können jetzt z.B. auch Formularerfassungsanwendungen nur zur Anzeige von Daten aufgerufen werden. Eine Prüfung auf Einfügerechte wird ggf. weiterhin durch die Anwendungen selbst durchgeführt.
Ist in einem Ablaufautomaten für einen Schlüssel (Konzern, Gesellschaft) die Option '#ALL' spezifiziert und wird gleichzeitig eine aktuelle Periode vorgegeben, dann erfolgt jetzt eine Prüfung der Gültigkeit der Konzerne bzw. Gesellschaften in dieser Periode. Ist ein Schlüssel nicht gültig, dann werden keine Funktionen für diesen Schlüssel erzeugt. Dies vermeidet lästige Fehlermeldung bei der Durchführung des Automaten.
Der Aufruf eines Web-Services des IDL.KONSIS.FORECAST Application Servers ist jetzt auch möglich, wenn für den Application Server keine Default-Datenbank festgelegt wurde. Die Datenbank muss dann bei der Anmeldung angegeben werden.
Stimmen bei der Verbindung eines Clíents zum Server die beiden Versionen nicht überein, dann werden jetzt aussagekräftige Hinweismeldungen angezeigt.
Das Programm zur Konfiguration des IDL.KONSIS.FORECAST Application Servers wurde Überarbeitet. U.a. wurde die Seite zur Konfiguration der Datenbanken neu gestaltet:
Außerdem wurde eine Möglichkeit geschaffen, das Session-Timeout für automatisches Beenden inaktiver Verbindungen einzustellen. Dazu muss in der Datei appserver.properties "session.timeout" auf den gewünschten Wert gesetzt werden. Der Standardwert wurde von 50 auf 90 Minuten erhöht.
Auf der Seite "SSL-Zertifikat-KeyStore" sind folgende Änderungen erfolgt:
Verschiedene Maßnahmen sorgen dafür, dass die Protokolldateien des IDL.KONSIS.FORECAST Application Servers nicht zu viel Plattenplatz einnehmen.
Das Client-Setup wird jetzt durch den IDL.KONSIS.FORECAST Application Server bereitgestellt. Entsprechende Links sind sowohl im App-Katalog des Portals als auch im Miniportal enthalten.
Die Anzeige der auswählbaren Anwendungen, die im Anwendungsfenster angezeigt wird, wenn keine Anwendung gestartet wurde, hatte bisher Überschriften (Menüknoten) unterdrückt, wenn sich darunter nur ein einzelner Menüpunkt befand. Diese Steuerung wurde jetzt entfernt. Wenn darunter die Übersichtlichkeit individueller Menüpunkte leidet, muss die Menüstruktur angepasst werden.
IDL.KONSIS.FORECAST unterstützt jetzt den E-Mail-Versand der angezeigten Daten. Über einen zusätzlichen Knopf im Druck-Dialog kann der angezeigte Inhalt, als pdf-Dokument generiert, als Anhang einer E-Mail versandt werden. Bei Knopfdruck wird der E-Mail-Client gestartet und es sind Adresse und Betreff zu ergänzen.
Ein E-Mail-Knopf befindet sich auch in Fehlerdialogen (nach Drücken des Knopfes <Details>) und anderen Meldungsdialogen. Dies ermöglicht dem Anwender, die Fehlerinformation direkt an die IDL-Hotline oder an andere Adressaten zu versenden. Bei den Fehlerdialogen wird auch eine Kopie des Info-Dialogs erstellt und an die E-Mail angehängt. Auch der Info-Dialog selbst wurde um einen E-Mail-Knopf erweitert, um diesen einfach an die IDL-Hotline übermitteln zu können.
Da sich die E-Mail-Programme unterscheiden, ist im Optionsdialog des Benutzers einzustellen, welches E-Mail-Programm verwendet wird. Unterstützt werden zunächst MS Outlook und Lotus Notes. Für weitere E-Mail-Programme (z.B. Mozilla Thunderbird) müssen evtl. zunächst Plugins installiert werden.
Die Übertragung von Tabellendaten nach MS Excel, sowohl über Kopieren und Einfügen als auch durch die Funktion "Export nach Excel", wurde erheblich beschleunigt, insbesondere für große Datenmengen.
Zum Öffnen des Zusatzdialogs (Eingabe von zusätzlichen Parametern) von Formularerfassungen kann jetzt auch die Funktionstaste <F2> verwendet werden. Bis zum Release 2014 Update 1 war dies durch die Funktionstaste <F5> möglich, die seit dem Release 2016 der Aktualisierung der Anzeige dient. Beachten Sie bitte, dass die Funktionstaste nur wirkt, wenn die Schreibmarke auf der Zelle für den Zusatzdialog steht.
In der Anwendung ABR wurde eine Funktion zum Kopieren einzelner Perioden (Erfassen mit Vorlage) ergänzt. Zum Kopieren aller Perioden eines Geschäftsjahres auf ein neues Geschäftsjahr wird aber weiterhin die Funktion "Mengenkopieren" empfohlen.
Eine der wesentlichen Änderungen in diesem Release wurde für die Positions-Konten-Zuordnungen vorgenommen. Die Daten wurden mit Gültigkeitsangaben (gültig ab, gültig bis) versehen, so dass die Zuordnungen jetzt in historisierter Form vorliegen. So kann nun ein Report für eine vergangene Periode oder auch ein aktueller Report mit den damals geltenden Zuordnungen jederzeit neu erstellt werden.
Für diese Darstellung wurde die bisherige DB-Tabelle K023 durch die neue DB-Tabelle K020 für die Positions-Konten-Zuordnungen ersetzt. Die Daten werden durch die Release-Konvertierung (s.o.) von K023 nach K020 überführt. Die Gültigkeit der Zuordnung wird dabei gemäß der Schnittmenge der Gültigkeiten von Position und Konto gesetzt.
Durch einen geänderten Primärschlüsselaufbau der Tabelle ist es jetzt auch möglich, ein Konto mit der Einschränkung nach verschiedenen Controllingkennzeichen 1 derselben Position für einen UKV-Report zuzuordnen.
Die Pflege der neuen Zuordnungstabelle erfolgt im Rahmen der Anwendung "Positionspläne" (POP). Dort werden jetzt nach Auswahl eines Positionsplans (Doppelklick oder Auge-Symbol) zwei abhängige Tabellen als Registerkarten hintereinander angezeigt, neben einer Tabelle der Positionen eine Tabelle der Positions-Konten-Zuordnungen, in der Positionen und Konten in Baumstruktur dargestellt werden.
Auf der linken Seite öffnet sich zusätzlich ein Selektionsbereich mit Eingabefeldern für eine Periode und einen Kontenplan. Die Eingabe des Kontenplans bewirkt, dass auf der rechten Seite eine Liste der Konten dieses Kontenplans als Ressourcentabelle angezeigt wird. Für den Kontenplan sind auch teilqualifizierte Angaben oder auch '%' als Eingabe zugelassen. Dann wird auch die Ressourcentabelle zu einer Baumtabelle mit den Kontenplänen als Knoten und in der Zuordnungstabelle werden die Kontenpläne als zusätzliche Knotenebene zwischen Position und Konto eingefügt.
Die Kontentabelle weist die Konten in drei verschiedenen Schriftfarben aus: In grauer Schrift werden die bereits korrekt zugeordneten Konten dargestellt, noch nicht zugeordnete Konten werden in schwarzer Schrift angezeigt und rote Schrift kennzeichnet Konten, die mehrfach zugeordnet wurde. Letzteres wird auch in der Liste der offenen Aufgaben im Fußteil des Fensters angezeigt. Dabei werden Zuordnungen auf Davon-Positionen nicht mitgezählt.
Neue Zuordnungen werden einfach durch Selektieren eines oder mehrerer Konten in der rechten Tabelle und anschließendes Fallenlassen auf der gewünschten Position definiert. Durch Ziehen und Fallenlassen kann ein Konto auch von einer Position auf eine andere verschoben werden. Dabei wird die Zulässigkeit der Zuordnung gemäß Bilanz/GuV-Kennzeichen von Konto und Position beachtet. Vorhandene Zuordnungen werden über das Lösch-Symbol oder die <Entf>-Taste entfernt.
Die Angabe der Periode im Selektionsbereich bewirkt, dass nur die Zuordnungen angezeigt werden, die in dieser Periode gültig sind. Dementsprechend zeigen die Schriftfarben in der Kontentabelle auch nur den Zustand bezogen auf diese Periode an.
Eine neue Zuordnung ist immer erst ab dieser Periode gültig. War das Konto bereits einer anderen Position zugeordnet, wird diese Zuordnung im Hintergrund mit einer Gültig-bis-Angabe einen Monat vor der eingestellten Periode versehen, so dass keine mehrfachen Zuordnungen entstehen. Ist das Konto in einer späteren Periode bereits zugeordnet, so wird die Gültigkeit einer neuen Zuordnung entsprechend beschränkt. Handelt es sich aber um die Zuordnung zur selben Position, dann werden die Sätze mit einer entsprechend längeren Gültigkeit zusammengefasst. Ausgenommen sind auch hier Zuordnungen auf Davon-Positionen. Zusätzlich werden auch die Gültigkeiten von Position und Konto berücksichtigt.
Zuordnungen können auch über einen Assistenten oder durch das Editieren in der Tabelle geändert werden. Hierbei sind nur die beiden Attribute "Soll/Haben-Kennzeichen" und "Controllingkennzeichen 1" änderbar. Der Assistent erlaubt auch das Anlegen einer neuen Zuordnung. Positions- und Kontonummer sind dann einzugeben.
Wie von der bisherigen Anwendung "Positionen+Konten-Zuordnungen Drag&Drop" (Z-POSKTO) bekannt, bewirkt die Angabe eines Soll/Haben-Kennzeichens, dass das Konto mit dem anderen Soll/Haben-Kennzeichen wieder schwarz in der Kontentabelle angezeigt wird, damit der Benutzer darauf aufmerksam wird, dass er diese Konstellation noch einer anderen Position zuordnen muss.
Eine entsprechende Steuerung gibt es jetzt auch für das Controllingkennzeichen 1. Die Angabe eines Controllingkennzeichens 1 bewirkt, dass das Konto mehrfach für alle weiteren Controllingkennzeichen 1 in der Kontentabelle in schwarzer Schrift angezeigt wird, damit eine lückenlose Zuordnung vorgenommen wird. Wie schon oben erwähnt, kann ein Konto jetzt aber mit mehreren Controllingkennzeichen 1 derselben Position zugeordnet werden.
Um einen Überblick über alle in der Tabelle K020 enthaltenen Daten unabhängig von deren Gültigkeit und ggf. für mehrere Positionspläne gleichzeitig zu erhalten, gibt es die neue Übersichtsanwendung "Positionen+Konten-Zuordnungen periodisch" (POSKTOP), die der bisherigen Übersicht "Positionen+Konten-Zuordnungen" (POSKTO) entspricht. Allerdings sind hier keine Datenänderungen möglich.
Die bisherigen Anwendungen "Positionen+Konten-Zuordnungen" (POSKTO) und "Positions-Konten-Zuordnungen Drag&Drop" (Z-POSKTO) für die Tabelle K023 entfallen.
Bei der Release-Konvertierung kann es passieren, dass vorhandene Positions-Konten-Zuordnungen nicht übernommen werden, wenn sich die Gültigkeiten von Konto und Position nicht überschneiden. Diese Daten werden bei der Konvertierung gekennzeichnet und durch die neue Übersicht "Positionen+Konten-Zuordnungen Übers für Konvertierung" (POSKTOKONV) mit den Gültigkeiten von Konto und Position angezeigt. Sollte festgestellt werden, dass diese Gültigkeitsangaben verkehrt sind, so können diese korrigiert und die Konvertierung für diese Zuordnungen durch die Aktion "Zeilenweise Konvertierung" wiederholt werden. Dies ist allerdings nur solange möglich, wie in der neuen Zuordnungstabelle noch keine weiteren Änderungen vorgenommen wurden. Die Aktion "Zeilenweise löschen" dient dazu, Daten aus dieser Anzeige zu entfernen, bei denen es korrekt ist, dass keine neuen Zuordnungen erzeugt wurden, damit die Liste übersichtlicher wird.
Sofern die Änderungsprotokollierung für Positions-Konten-Zuordnungen aktiviert ist, werden auch Änderungen an der neuen Zuordnungstabelle K020 protokolliert. Diese Daten werden jedoch ebenfalls in eine neue Protokolltabelle geschrieben. Die Ansicht dieser Daten erfolgt mit der neuen Übersicht "Positionen+Konten-Zuordnungen- periodisch - Änderungen" (POSKTOPLOG). Die Übersicht über die Änderungen an der bisherigen Zuordnungstabelle K023 (POSKTOLOG) bleibt erhalten, um die historischen Änderungen weiter zurückverfolgen zu können.
Die Möglichkeiten dieser Erweiterung werden vor allem im Reporting ausgenutzt (s.u.), während die normalen Datenanzeigen nach Position oder in Reportstruktur jeweils nur die Zuordnungen der aktuellen Periode auswerten. Das gilt insbesondere für die Anzeige und Erfassung über mehrere Perioden wie z.B. in der Formularerfassung (I-KTOSAL) und in IDL.FORECAST, wo diese Periode einstellbar ist (s.u.).
Achtung! Einschränkungen der Gültigkeit eines Kontos bewirken automatisch eine Einschränkung der Gültigkeit der zugehörigen Positions-Konten-Zuordnungen. Dies hat zur Folge, dass Daten auf ungültigen Konten nicht mehr in Reports enthalten sind. Ggf. (z.B. wenn Daten auf einem ungültigen Konto weiter vorgetragen werden) ist es daher sinnvoll, das Konto unbeschränkt gültig zu belassen und stattdessen die Erfassungskennzeichen des Kontos auf '-' zu setzen.
Der Kontenstamm wurde um ein Kennzeichen "Plankonto" erweitert. Hiermit können Konten gekennzeichnet werden, die ausschließlich in IDL.FORECAST verwendet werden, z.B. als Parameter für Regeln. So gekennzeichnete Konten dürfen ausschließlich in Datenarten verwendet werden, die ihrerseits als "Plandatenart" gekennzeichnet sind. In der Kontenauswahl für andere Datenarten wird die Anzeige dieser Konten unterdrückt.
Die Übersicht "Konten" (KTO) ermöglicht die Anzeige von Konten, die einer angegebenen Position zugeordnet sind. Für die Ermittlung wird künftig eine Periode benötigt (s.o.). Dazu wurde im erweiterten Teil des Selektionsbereichs ein Eingabefeld für eine aktuelle Periode ergänzt. Ohne Eingabe gilt die aktuelle Periode aus der Vorbelegung (VOR). Diese Periode (Eingabe oder Vorbelegung) wird auch beim Kopieren und durch die Aktion "Erstellen POSKTO-Zuordnung für Gesellschaftskonten" ausgewertet, um daraus die Gültig-ab-Periode der erzeugten Zuordnungssätze zu erstellen.
Eine neue Anwendung "Kontenplandefinition" (KTODEF) fasst die bisherigen Anwendungen "Kontenpläne" (KTP) und "Konten" (KTO) einschl. deren Einzelsatzanwendungen zu einer integrierten Anwendung zusammen. Geplant ist außerdem eine Integration der Anwendung "Kontengruppen" (KTOGRP). Die o.g. bisherigen Anwendungen sind im Release 2017 weiterhin aktiv und nutzbar, werden aber in einer der nächsten Versionen deaktiviert.
Beim Aufruf der Anwendung wird ohne Selektion sofort eine Tabelle aller definierten Kontenpläne angezeigt, also alle reinen Kontenpläne sowie Kontenpläne, die gleichzeitig Controllingpläne darstellen, aber keine reinen Controllingpläne. Um einen reinen Controllingplan auch als Kontenplan zu nutzen, ist der entsprechende Schalter für den Controllingplan in der Anwendung "Controllingdefinitionen" (CTLDEF) zu setzen.
Über das Kontextmenü kann in die Übersicht "Kontengruppen" (KTOGRP) verzweigt werden. Durch einen Doppelklick oder das Auge-Symbol wird ein Kontenplan geöffnet und es wird eine Tabelle mit allen Konten des Kontenplans angezeigt, während die Tabelle der Kontenpläne automatisch ausgeblendet wird.
Die Änderung der Daten des Kontenplankopfsatzes erfolgt über einen Assistenten, der mithilfe des Bleistift-Symbols in der globalen Werkzeugleiste geöffnet wird. Der Assistent dient auch dem Erfassen und Kopieren eines Kontenplans, wobei Kopieren das Kopieren aller Konten des Kontenplans einschließt. Der Assistent besteht aus drei Seiten:
Die Tabelle der Konten zeigt alle Kontenattribute in Spalten an. Im Gegensatz zur Anwendung "Konten" (KTO) werden aber für Gesellschaftskonten keine Attribute der zugeordneten Konzernkonten angezeigt.
Zum Einfügen, Ändern und Kopieren der Konten dient ein Assistent, in dem die Eingabemöglichkeiten auf 7 Seiten aufgeteilt sind:
Plausibilitätsprüfungen erfolgen im Prinzip genauso wie in der Einzelsatzanwendung "Konto" (KTOE). Die Abhängigkeiten der Felder werden dabei i.d.R. so geprüft, dass Fehler ggf. für das auf einer hinteren Seite angeordnete Attribut gemeldet werden, so dass der Assistent ohne Rückschritt von vorne nach hinten bearbeitet werden kann.
Editieren in der Tabelle ist auch möglich. Wegen der vielen Abhängigkeiten der Attribute untereinander werden fehlerhafte Eingaben entweder direkt abgewiesen oder als offene Aufgabe (Liste am unteren Ende des Anwendungsfensters) notiert. Solange es offene Aufgaben gibt, ist ein Speichern der Änderungen nicht möglich. Bei Betätigung des <Speichern>-Knopfs wird eine entsprechende Meldung ausgegeben.
In den Lieferbatch-Dateien für Anlagenspiegel wurde ein Buchungsschlüssel für die Aktivierung von Fremdkapitalzinsen (Anforderung durch BilRUG) ergänzt. Im alten Standard (Fortschreibung der alten Standardspiegel) ist dies der Buchungsschlüssel '40', im neuen Standard der Buchungsschlüssel '111'. Bitte vergewissern Sie sich vor dem Export des neuen Buchungsschlüssels mit IDL.XLSLINK, dass diese Nummer noch nicht anderweitig vergeben wurde.
Die Lieferbatch-Datei POP_KTP_RID.xlsm für den Kapitalspiegel-Report wurde um XLSLINK-Bezüge für die neuen Exportanwendungen für Positionspläne und Report-Idents ergänzt und kann nun komplett ohne manuelle Eingaben exportiert werden.
Bei der Erfassung in Reportstruktur (I-KTOSAL, I-CNTSAL, I-xxxBEW) werden die Daten jetzt gemäß den in der aktuellen Periode gültigen Positions-Konten-Zuordnungen angezeigt. Beachten Sie dabei bitte, dass die neue Tabelle K020 (s.o.) einen Gültigkeitszeitraum für die Zuordnungen enthält. Konten, die wegen Gültigkeitseinschränkungen keine Zuordnung in der aktuellen Periode haben, sind dann auch nicht mehr im Formular enthalten.
Werte auf Konten für statistische Mengen (Bilanz/GuV-Kennzeichen '5') können mit und ohne Soll/Haben-Kennzeichen geführt werden. Bei der Angabe ohne Soll/Haben-Kennzeichen gab es einige Unstimmigkeiten beim Abgleich der Kontensalden mit den Aufrissdaten (Spiegelbewegungen, IC-Kontensalden, Controllingsalden). Diese wurden jetzt bereinigt. Daten mit positiven Beträgen ohne Soll/Haben-Kennzeichen werden jetzt immer wie Daten im Soll behandelt, negative Beträge wie die entsprechenden Werte im Haben.
Bei der Eingabe der IC-Bestände im Vorratsvermögen (ICVOR) sind die bei der liefernden (IC-)Gesellschaft angefallenen Zu- bzw. Abschläge nicht immer bekannt. Daher können diese Margen für die liefernde Gesellschaft in einer eigenen Anwendung (PROMAR) geführt werden.
Diesem Zusammenhang wurde jetzt Rechnung getragen, indem beim gegenseitigen Aufruf dieser Anwendungen die Rollen von Gesellschaft und IC-Gesellschaft als Parameter jeweils vertauscht werden. Dies gilt auch für die jeweiligen Formularerfassungsanwendungen (I-ICVOR, I-PROMAR).
Die Daten der IC-Clearing-Übersicht (KGESGES) werden ab jetzt mit einer Prüfsumme versehen. Diese Prüfsumme setzt sich aus allen für die jeweilige Kombination aus Gesellschaft, IC-Gesellschaft und Belegkreis (KVA) verarbeiteten IC-Kontensalden und Buchungen auf IC-Konten zusammen. In die Prüfsumme fließen alle für das IC-Clearing relevanten Daten ein, u.a. Wert in Konzernwährung, Wert und WKZ in Transaktionswährung, Geschäftsbereich, IC-Geschäftsbereich, Kontonummer und auch Controllingobjekte. Diese Prüfsumme wird beim Erzeugen des IC-Clearing-Satzes durch die IC-Saldenabstimmung oder durch eine SK- bzw. AE-Konsolidierung ermittelt und gespeichert. Diese Prüfsumme wird in der IC-Clearing-Übersicht allerdings nur bei der Ansicht-Option "Interne Infospalten anzeigen" ausgegeben.
Bei Wiederholung der IC-Saldenabstimmung wird geprüft ob die neu ermittelte Prüfsumme mit der gespeicherten Prüfsumme übereinstimmt. Wenn ja, bleibt der bestehende IC-Clearing-Satz und damit auch eine evtl. bereits erteilte manuelle Freigabe erhalten.
Es ist jetzt auch möglich, unstimmige Einzelabschlüsse, z.B. nur mit Kontensalden für die GuV, umzurechnen. Dabei unterbleibt allerdings die Verbuchung von Differenzen auf den Konten für Ausgleichsposten aus der Währungsumrechnung.
Die Anzahl der konsolidierten Gesellschaften eines Konzernkreises wird jetzt streng gegen die Anzahl lizenzierter Gesellschaften verprobt. Bei Überschreitung erscheint eine Fehlermeldung anstelle der bisherigen Warnung und Konsolidierungsfunktionen können nicht mehr durchgeführt werden.
Bei der Verzweigung aus dem Konzern-Monitor (KTKGES) in den Einzelabschluss-Monitor (EA) wird jetzt der Schlüssel des Konzerns als Parameter übergeben. Dies ist Voraussetzung für die Durchführung und die Statusanzeige der IC-Saldenabstimmung.
Das Beteiligungsertragskonto aus dem Konsolidierungsparameter 'SK' (einschl. 'S0' bis 'S9') wurde entfernt, da es aufgrund anderer Änderungen keine Funktion mehr hatte.
In den 'AE'-Konsolidierungsparametern dürfen nur noch GuV-Konten als Neutralisierungskonten angegeben werden, da sonst die gewünschte Wirkung der Neutralisierung nicht gegeben ist.
Die Funktion "Sachdifferenz buchen" verbucht die ermittelte offene Differenz auf dem Schwellenwertkonto, auch wenn die Differenz größer als der angegebene Schwellenwert ist. Dabei wird jetzt auch der Schalter "Differenz kumulieren" ausgewertet. Ist dieser Schalter nicht gesetzt, werden z.B. erst nur die Aufwände der einen Gesellschaft mit den Erträgen der anderen verglichen und dann umgekehrt. Beide Differenzen werden getrennt verbucht.
In der "Zwischenergebniseliminierung Umlaufvermögen Übersicht" (ZWERGUV) werden Eliminierungsbeträge jetzt als negative Werte angezeigt, wenn es sich um Zwischenverluste handelt. Dabei wird auch berücksichtigt, dass das Umlaufvermögen im Haben steht (separate Wertberichtigungskonten). Das saldierte Zwischenergebnis lässt sich so leicht als Summe der angezeigten Werte berechnen.
Für Konsolidierungsbelege wurde die neue Buchungsart 'WT' (wiederkehrend im Teilkonzern) eingeführt. Diese wirkt einerseits wie die Buchungsart 'ET', indem die zugehörigen Buchungen nur in Konzernberichten des jeweiligen Teilkonzerns ausgewiesen werden, aber nicht auf den darüber liegenden Ebenen der Konzernstruktur. Das gilt auch für andere, reportähnliche Übersichten. Andererseits werden Belege mit der Buchungsart 'WT' analog zur Buchungsart 'WU' in Folgeperioden vorgetragen und behalten dabei die Buchungsart 'WT' bei.
Die Übersicht "Konsolidierungsbuchungen" (KONBUCH) ermöglicht jetzt (wieder) die Selektion nach dem Kennzeichen "segmentübergreifend". Die Eingabe '*' selektiert Daten ohne dieses Kennzeichen. Zwar war es auch zuvor schon möglich, in der zugehörigen Tabellenspalte einen Filter zu setzen, jedoch hat dies keine Auswirkung auf die angezeigten Summen.
Ergebniswirksame Konsolidierungsbuchungen aus Belegen mit der Buchungsart 'ET' oder 'WT' dürfen nicht mehr für die Berechnung von Fremdanteilen oder latenten Steuern gekennzeichnet werden.
Zur Erfassung und Pflege von Prüfregeln wurde eine neue integrierte Anwendung "Prüfregel-Definition" (PRFDEF) erstellt. Diese Anwendung fasst die Funktionalität folgender bisheriger Anwendungen (einschl. deren Einzelsatzanwendungen) zusammen:
Die o.g. bisherigen Anwendungen sind im Release 2017 weiterhin aktiv und nutzbar, werden aber in einer der folgenden Versionen deaktiviert.
Beim Aufruf der Anwendung werden ohne Selektionsmöglichkeit drei Tabellen angezeigt, auf der linken Seite als Registerkarten hintereinander "Prüfregelgruppen" und "Prüfregelausschlussgruppen", beide Tabellen in Baumstruktur, sowie auf der rechten Seite "Prüfregeln", eine flache alphabetisch sortierte Liste aller definierten Prüfregeln.
"Prüfregelgruppen" entspricht der Darstellung der bisherigen Anwendung "Prüfregeln" (PRF) mit dem Unterschied, dass Prüfregeln, die keiner Prüfregelgruppe zugeordnet sind, nicht angezeigt werden. Daher sind diese nicht zugeordneten Prüfregeln in der rechten Tabelle "Prüfregeln" mit hellerem Hintergrund dargestellt als Hinweis, dass auch diese einer Gruppe zugeordnet werden sollten.
Diese Zuordnung erfolgt durch Selektieren und Ziehen mit der Maus und Fallenlassen auf der gewünschten Gruppe. Entsprechend erfolgt auch die Zuordnung zu einer anderen Gruppe innerhalb der linken Tabelle. Die Zuordnung wird durch die umgekehrte Aktion oder über die Aktion "Löschen" aus dem Kontextmenü wieder entfernt. Jede Prüfregel kann in dieser Struktur nur einmal zugeordnet werden.
Auf gleiche Weise können auch Prüfregelgruppen innerhalb des Baums anderen Prüfregelgruppen untergeordnet werden. Allerdings bewirkt die Aktion "Löschen" hier, dass die Prüfregelgruppe komplett entfernt wird einschl. aller Zuordnungen von Prüfregeln, so dass diese Prüfregeln in der rechten Tabelle ihre Hintergrundfarbe ändern.
Prüfregeln können auf gleiche Weise in der zweiten Tabelle einer Prüfregelausschlussgruppe zugeordnet werden. Hier kann eine Prüfregel auch mehrfach zugeordnet werden. Die Zuordnungen zu Prüfregelausschlussgruppen haben daher keine Auswirkung auf die Darstellung in der Tabelle "Prüfregeln". Außerdem können Prüfregelausschlussgruppen nicht einander zugeordnet werden, so dass diese Baumtabelle nur einstufig ist.
Die Selektion in den drei Tabellen ist synchronisiert. D.h. die Selektion einer Prüfregel in einer der Baumtabellen führt dazu, dass diese Prüfregel auch in der Tabelle "Prüfregeln" selektiert wird, allerdings nicht umgekehrt.
Alle drei Tabellen haben einen Assistenten zum Einfügen, Ändern und Kopieren eines Satzes. Für Prüfregelgruppen und Prüfregelausschlussgruppen beschränkt sich dieser Assistent auf zwei Seiten, die standardgemäß die Eingaben für den Schlüssel und Bezeichnungen auf der ersten Seite sowie für mehrsprachige Bezeichnungen auf der zweiten Seite ermöglichen.
Der Assistent für Prüfregeln enthält auf der ersten Seite zusätzlich Eingabefelder für die Gültigkeit sowie zwei weitere Seiten "Eigenschaften" und "Zusatzangaben". In "Eigenschaften" werden der Operator, die Prüfebene (Gesellschaft/Konzern) sowie die Basiseinstellungen von linker und rechter Seite festgelegt. Toleranzen und "Je"-Schalter werden in "Zusatzangaben" gepflegt. Beim Kopieren einer Prüfregel werden (im Gegensatz zur Anwendung "Prüfregeln" (PRF)) die zugehörigen Prüfregel-Positionen mitkopiert.
Das Ändern einer Prüfregel ist allerdings erst nach dem Öffnen der Regel (Doppelklick oder Auge-Symbol) möglich. Dann werden in einer weiteren Tabelle "Prüfregeln/Positionen" die Positionen dieser Prüfregel angezeigt. Die drei zunächst angezeigten Tabellen werden dabei automatisch ausgeblendet.
Auch das Anlegen, Ändern und Kopieren der Prüfregel-Positionen erfolgt mithilfe eines Assistenten, der vier Seiten umfasst:
Plausibilitätsprüfungen erfolgen analog den o.g. bisherigen Anwendungen für Prüfregeldefinitionen. Nach Setzen des Schalters "Tabellenzeilen editierbar" im Kontextmenü können Änderungen auch direkt in der Tabelle erfolgen. Sämtliche Änderungen werden erst nach Mausklick auf das <Speichern>-Symbol in der Datenbank festgeschrieben.
Bisher konnten in Prüfregeln nur Positionen ausgewertet werden, denen direkt Konten zugeordnet sind (Positionstyp 'MP' oder 'MS'). Künftig können auch aggregierte Positionen (Positionstypen 'OP', 'OS', 'OT') verwendet werden.
Zur Ermittlung, welche untergeordneten Positionen zur Berechnung herangezogen werden müssen, wird ein Report benötigt. Dessen Report-ID ist bei der Prüfregel-Position (PRFPOSE bzw. Seite "Kontenauswahl" des Assistenten für Prüfregeln/Positionen) anzugeben. Diese Angabe entspricht der Angabe "Herkunfts-Report" in IDL.CONNECTOR und IDL.XLSLINK. Je nach Positionstyp werden dann die Angaben für zugeordnete Position oder In- und Ex-Speicher in den Reportzeilen ausgewertet.
Die "Prüfregelergebnis-Analyseübersicht" (PRFERGANA) zeigt in diesem Fall unter der aggregierten Position direkt die ermittelten zugehörigen Konten an, ohne die dazwischen angeordneten Positionen auszuweisen.
In Prüfregeln können jetzt auch Kennzahl-Positionen (Positionsplan-Typ 'K') verwendet werden. Diese werden gemäß der zugeordneten Formel (FED) ausgewertet. Enthält die Formel Summenpositionen, wird zusätzlich die Angabe einer Report-ID (s.o.) benötigt. Vergleichswerte für eine Kennzahl-Prüfregel (z.B. Eigenkapitalquote > 20%) sind in Form von statistischen Konten zu pflegen und können somit abhängig von Gesellschaften oder Perioden sein.
Die "Prüfregelergebnis-Analyseübersicht" (PRFERGANA) zeigt für Kennzahlen die Formel mit Operatoren und Operanden (einschl. Konstanten) und den ermittelten Wert der Kennzahl an, so dass das Prüfregelergebnis detailliert nachvollzogen werden kann.
Analog zu anderen 'je'-Schaltern wurde in der Definition der Prüfregeln ein Schalter "je Gesellschaft" ergänzt. Dieser Schalter wirkt nur, wenn die Prüfregel auf Konzernebene angewandt wird, und sorgt dafür, dass die Regel auf jede im Konzernkreis enthaltene Gesellschaft für sich angewandt wird. Auf Gesellschaftsebene hat der Schalter keine Auswirkungen, da ohnehin nur eine Gesellschaft verarbeitet wird.
Die "Prüfregelergebnis-Analyseübersicht" (PRFERGANA) gruppiert für Prüfregeln mit diesem Schalter die Daten ebenfalls nach Gesellschaft, um eventuelle Abweichungen direkt zuordnen zu können.
Die Berechnung des Prüfregelergebnisses für eine Gesellschaft oder einen Konzern erfordert jetzt die Berechtigung des Benutzers zum Ändern der Daten der Gesellschaft bzw. des Konzerns.
Wenn eine Prüfregel auf beiden Seiten der Regel die Werteart 'S+B' (Salden + Buchungen) spezifiziert, dann werden jetzt in der "Prüfregelergebnis-Analyseübersicht" (PRFERGANA) Salden und Buchungen getrennt ausgewiesen und miteinander verglichen. Dies erleichtert die Analyse, ob eine ggf. vorhandene Differenz aus den Salden oder aus den Buchungen herrührt. Für das Prüfregelergebnis werden dagegen weiterhin die Summen aus Salden und Buchungen verglichen.
Die "Prüfregelergebnis-Analyseübersicht" (PRFERGANA) wurde außerdem in folgenden Punkten überarbeitet und erweitert:
Die neue Funktionalität der IC-Gegenplanung sorgt dafür, dass die IC-Angaben einer Gesellschaft (z.B. IC-Umsätze) konsistent zu den IC-Angaben der Partnergesellschaft (z.B. IC-Aufwände) sind. Sofern entsprechende Regeln definiert sind, werden die entsprechenden Angaben bei der Partnergesellschaft automatisch eingebucht. Dies erfordert folgende Schritte:
Vorerst ist die IC-Gegenplanung auf GuV-Konten des Konzernkontenplans beschränkt. Bilanz-IC-Salden ergeben sich daraus aus Regeln. Damit auch die Bilanz-IC-Salden konsistent sind, müssen konsistente Regeln angewandt werden, z.B. einheitliche Zahlungsmodalitäten vereinbart werden.
Des Weiteren werden die IC-Salden immer nur in einer durch das Profil vorgegebenen Richtung übernommen. D.h. eine Gesellschaft ist jeweils führend und gibt die IC-Salden für die Partnergesellschaft vor. Diese Daten können von der Partnergesellschaft nicht mehr verändert werden, um sie an die erste Gesellschaft zurückzuspielen.
Bezüglich der Währungsumrechnung ist zu beachten, dass IDL.FORECAST dekumulierte Werte führt und zu den für den jeweiligen Monat definierten Durchschnittskursen umrechnet. Da IDL.KONSIS kumulierte zum Periodendurchschnittskurs umrechnet, kann es zu Differenzen (Kurseffekten) kommen.
Zur Pflege der im Punkt 1. angegebenen Profile gibt es die neue Anwendung "IC-Gegenplanung" (Kurzwort: ICGP). Sie besteht aus zwei Fenstern, in einem Fenster werden Profile verwaltet, im anderen Fenster die zu einem geöffneten Profil gehörenden Kontenzuordnungen. Das Fenster für die Profilverwaltung ist wie das Fenster mit den Szenarien in der Planungsanwendung links angeordnet. Wenn ein Profil geöffnet ist, wird rechts im großen Fenster eine Liste aller zum Profil gehörenden Kontenzuordnungen angezeigt.
Ein Profil ist die Zusammenfassung der für eine IC-Gegenplanung benötigten Zuordnungen. Es erhält einen eindeutigen Namen, der in Szenarien mit IC-Gegenplanung anzugeben ist. Die angegebenen Kontenzuordnungen sind auf einen anzugebenden Kontenplan beschränkt. Ein Profil kann nur dann wieder gelöscht werden, wenn es noch keinem Szenario zugeordnet ist.
Für jede im Profil definierte Zuordnung sind Quell- und Zielangaben für Gesellschaften und Konten erforderlich. Die Zuordnung gilt für die Menge angegebener Quell- und Zielgesellschaften, wobei die Angaben auch in der Form "alle Gesellschaten außer ..." erfolgen können. Einem Quellkonto können mehrere Zielkonten zugeordnet werden, auf die der Betrag mit anzugebenden Prozentsätzen aufgeteilt wird. Quell- und Zielkonto müssen demselben Belegkreis (KVA) zugeordnet sein, damit der Vorgang auch durch die Aufwands-/Ertragskonsolidierung (AE) verarbeitet werden kann.
Jede Zuordnung im Profil wird durch eine laufende Nummer eindeutig gekennzeichnet. Diese Nummer wird in Fehlermeldungen oder anderen Übersichten (z.B. IC-Gegenplanungsübersicht, s.u.) angegeben, um bei Bedarf die Zuordnung im Profil schneller zu finden und ggf. anzupassen.
Die Übernahme von IC-Angaben aus der Planung der Partnergesellschaften (s.o.) sowie auch Funktionen des neuen Splashing-Dialogs (s.u.) können in einen Planungsablauf integriert werden und können somit über den Planungs-Monitor (PM) ausgeführt werden.
Der neue Schalter zur Unterscheidung zwischen Nullsalden und leeren Werten (s.u.) kann auch als Parameter eines Planungsablaufs angegeben werden.
In den Planungsabläufen wurde eine Spalte "Parameter" ergänzt. D.h., dem Ablaufschritt kann jetzt ein Parameter zugeordnet werden, der den allgemeinen Parameter des Ablaufs je Gesellschaft überschreibt. So ist es z.B. möglich, denselben Schritt (z.B. "Salden aktualisieren") zweimal im Ablauf an verschiedenen Stellen auszuführen, einmal zum Aktualisieren der IC-Salden und einmal zum Aktualisieren der Kontensalden.
Im Planungs-Monitor gibt es für Szenarien mit aktivierter IC-Gegenplanung einen neuen Status:
Die Zeit zum Aufbau der Tabelle des Planungs-Monitors wurde deutlich verringert, insbesondere für Szenarien mit vielen Perioden und vielen Gesellschaften.
Die Anzahl der einem Szenario zugeordneten Gesellschaften wird jetzt streng gegen die Anzahl lizenzierter Gesellschaften verprobt. Einem Szenario können nicht mehr Gesellschaften zugeordnet werden.
Beim Anlegen eines Szenarios steuert ein neuer Schalter, dass im Szenario geplante IC-Salden eine IC-Gegenplanung bei den Partnergesellschaften auslösen (s.o.). Dazu muss auch ein Profil angegeben werden, das die Kontenzuordnungen festlegt. Zusätzlich kann über den Schalter "Übernommene IC-Salden verändern Kontosaldo von J-Konten" gesteuert werden, dass der geplante Drittanteil von Konten mit Kontokennzeichen 'J' bei der Übernahme der IC-Gegenplanung nicht verändert wird.
Neu ist auch die obligatorische Angabe eines Konzerns für ein Szenario mit aktivierter IC-Gegenplanung, um die Konzernwährung zu bestimmen. Sie dient auch der Vorbelegung des Konzerns bei Verzweigung in den Planungs-Monitor.
Beim Anlegen eines Szenarios wird jetzt auf der Periodenauswahlseite rechts unten eine Combobox angezeigt, mit der man aus den im Szenario enthaltenen Perioden eine Referenzperiode für die Positions-/Konten-Zuordnungen auswählen kann. Standardmäßig ist hier die erste Periode nach dem IST-Bereich eingetragen. Die Angabe kann nach dem Erstellen des Szenarios nicht mehr geändert werden.
Das Speichern eines Szenarios, insbesondere nach dem Löschen vieler Geschäftsfälle, wurde erheblich beschleunigt.
Die Erfassung der Plandaten erfolgt in der Reportstruktur. Dabei werden die Konten jetzt gemäß den in einer bestimmten Periode gültigen Positions-Konten-Zuordnungen angezeigt. Diese Periode kann beim Anlegen eines Szenarios auf der Periodenauswahlseite festgelegt werden. Voreingestellt ist jeweils die letzte Periode des IST-Zeitraums. Dies ist auch die Einstellung für bestehende Szenarien.
Beachten Sie dabei bitte, dass die neue Tabelle K020 (s.o.) einen Gültigkeitszeitraum für die Zuordnungen enthält. Konten, die wegen Gültigkeitseinschränkungen keine Zuordnung in der strukturbestimmenden Periode haben, sind dann auch nicht mehr im Formular enthalten.
Aus der IC-Gegenplanung übernommene IC-Salden sind im Szenario gegen Splashing und Änderungen durch den Anwender gesperrt. Bei 'I'-Konten ist auch der Kontosaldo gesperrt. Manuelle Veränderungen und Einzelbuchungen dürfen nicht angelegt werden. Regeln dürfen aber trotzdem angewendet werden. Die gesperrten Konten haben den Tooltip "Zielkonto der IC-Gegenplanung".
Beim Aktualisieren der Salden kann jetzt zwischen Nullsalden und leeren Werten unterschieden werden. Dies wird durch einen neuen Schalter im Dialog gesteuert, der standardmäßig die bisherige Einstellung (keine Unterscheidung) hat. Bei Setzen des Schalters werden auch Nullsalden geladen und überschreiben ggf. vorhandene Salden. Dieser Schalter kann auch als Planungsparameter für Planungsabläufe gesetzt werden.
Werden über den Dialog "Saldo-Abweichungen" Salden aktualisiert, so werden jetzt manuell gesperrte Zellen gemeldet und der Benutzer kann entscheiden, ob er auch diese aktualisieren will oder nicht. Zellen, die über eine Perioden- oder Kontensperre gesperrt wurden, werden dagegen ohne Rückfrage immer aktualisiert. Um diese Steuerung weiter zu automatisieren, können auch Zellen, die einer Perioden- oder Kontensperre unterliegen, zusätzlich manuell ge- oder entsperrt werden.
Die IC-Gegenplanungsübersicht ist eine Sicht auf alle in die aktuelle Gesellschaft übernommenen oder zu übernehmenden Salden. Sie ist eine Art Saldoabweichungsanzeige für die IC-Gegenplanung. In Szenarien mit aktivierter IC-Gegenplanung ist die Sicht zwischen der Saldoabweichungsanzeige und der Plausibilitätsprüfung unter dem Planungsformular eingehängt.
In der Tabelle werden nur die Zuordnungen angezeigt, die für die aktuelle Gesellschaft Werte ein-stellen. Insbesondere werden nicht diejenigen Zuordnungen angezeigt, in denen andere Gesell-schaften von dieser Gesellschaft Werte eingestellt bekommen.
Folgende Plausibilitätsprüfungen wurden bzgl. der IC-Gegenplanung ergänzt:
Der Dialog zum Kopieren und Verteilen von Werten wurde komplett neu gestaltet. Der neue Dialog bietet jetzt die folgenden Möglichkeiten:
Einstellungen in diesem Dialog lassen sich (ähnlich den Regelvorlagen) speichern.
Die Kopier- und Verteilfunktionen können durch einen Planungsablauf gestartet werden.
Für individuelle Tabellenblätter kann jetzt gewählt werden, ob diese für alle Gesellschaften des Szenarios gelten soll oder nur für die aktuell bearbeitete. Dazu dient eine neue Checkbox unter dem Menüpunkt "konfigurieren" im Fenster "Tabellenablage". Ist "nur für aktuelle Gesellschaft" angegeben, wird es bei anderen Gesellschaften mit einem entsprechenden Symbol angezeigt und kann nicht verwendet werden. Bei Bedarf kann aber eine Kopie als weiteres Tabellenblatt erzeugt werden.
Eine Kennzahlregel kann jetzt analog zur Umsatzregel je IC-Gesellschaft angewandt werden. Dazu enthält der IC-Aufriss des Bezugswertes jetzt folgende Optionen:
Außer bei "Kontosaldo ohne Aufriss" wird der jeweilige IC-Saldo anstelle des Kontensaldos als Kennzahl verwendet. Eine zusätzliche Seite "Intercompany" des Regelassistenten funktioniert analog anderen Regelassistenten.
Die Darstellung von Positionen mit Einschränkungen eines Kapitalflussreports war bezüglich der Angabe des Wertkennzeichens ('1' bzw. '-') missverständlich. Diese Angabe bezog sich immer auf das Wertkennzeichen des ersten Eintrags in der Einschränkungsformel. Änderungen auf der ersten Seite des Assistenten hatten keinen Einfluss. Die Radio-Buttons für 'P1' und 'P-' sind daher jetzt deaktiviert, wenn es eine Einschränkungsformel gibt. Zeilen mit Formeln, die sowohl einen Plus- als auch einen Minus-Operator enthalten, werden in der Tabelle mit 'P1/-' angezeigt.
Die Tabelle der Reportzeilen wurde um eine Spalte für ein Bilanz/GuV-Kennzeichen erweitert. Hier wird automatisch das gemäß Report-Logik für die Wahl des anzuzeigenden Vorzeichens bestimmende Bilanz/GuV-Kennzeichen, das aus einem übergeordneten Knoten vererbt wird, eingetragen. Dies erfolgt automatisch bei allen Änderungen durch die Anwendungen "Report-Definition" (REPDEF) und "Report-Zeilenbeschreibungen" (REPZEI). Eine direkte Änderung ist nicht möglich. Ausgewertet wird die Spalte bei der Erstellung des OLAP-Würfels (IDL Datamart, s.u.).
Die Report-Kopfsätze (REP/REPK) wurden um zwei neue Attribute erweitert, über die gesteuert wird, welche Positions-Konten-Zuordnungen für den Bericht angewandt werden sollen (s.u.). Zum einen kann eine andere als die aktuelle Periode angegeben werden, die die gültigen Zuordnungen enthält, zum anderen steuert ein Schalter, dass für jede Periode die jeweils dann gültigen Zuordnungen verwendet werden.
Das Standard-Reporting wertet für den Aufbau der Berichtsstruktur die neue Tabelle für Positions-Konten-Zuordnungen (K020, s.o.) aus. Es gibt künftig drei Varianten:
Die Einstellung der Varianten erfolgt über neue Eingabefelder im Report-Kopfsatz (REP). Ohne Angaben in diesen Feldern bleiben die Reports und damit auch alle bereits bestehenden Report-Kopfsätze in der "wie bisher"-Variante.
Auch (neu erstellte) Kapitalfluss-Reports werden jetzt mit Prüfsummen versehen. Dazu werden Prüfsummen für Kontensalden und Spiegelbewegungen sowie ggf. für Konsolidierungsbuchungen und Controllingsalden berechnet und im Report-Kopfsatz (REP/REPK) gespeichert. Diese Prüfsummen umfassen jeweils alle Daten unabhängig davon, ob sie im Report verarbeitet wurden oder nicht. Es kann daher sein, dass Differenzen gemeldet werden (Status [rot]), obwohl nur Daten verändert wurden, die nicht im Reportergebnis enthalten sind.
In diesem Zusammenhang wurde es notwendig, separate Prüfsummen für Controllingsalden und IC-Kontensalden einzuführen (bisher alternativ zur Prüfsumme für Spiegelbewegungen gespeichert). Eine Versionierung der Report-Kopfsätze ermöglicht es aber, dass auch alte Reports in der gewohnten Form angezeigt werden. Da IC-Kontensalden und Controllingsalden nie gemeinsam verarbeitet werden, werden diese Prüfsummen in einer gemischten Spalte angezeigt.
Konzernreports können jetzt für beliebige Datenarten auf Ebene des Konzernkontenplans erstellt werden, vorausgesetzt es ist eine "ex Datenart" (im Datenartenstamm FAC oder in der Vorbelegung VOR) spezifiziert und beide Datenarten verwenden denselben Kontenplan. Die Konzernstruktur wird dann immer aus der in "ex Datenart" angegebenen Datenart ermittelt. Eine redundante Pflege der Konzernstruktur nur für Reportzwecke ist nicht mehr notwendig.
Beim Mengen-pdf-Export von Reportergebnissen werden jetzt zusätzlich zu Report-ID und Versionsnummer auch die weiteren Schlüssel des Reports (Konzern, Gesellschaft, Periode, Datenart, Aufrissoption) in den Dateinamen aufgenommen. Dies erleichtert nicht nur die Zuordnung der erzeugten pdf-Dateien, sondern verhindert vor allem, dass die Dateien sich beim Export gegenseitig überschrieben.
Der Import der Positions-Konten-Zuordnungen wurde auf die neue Tabelle K020 umgestellt (s.o.). Zur Unterscheidung von den Daten für die alte Tabelle K023 sind die Formatdefinitionen für die neue Tabelle unter dem Import/Export-Objekttyp "POSKTOP" definiert. Für den Import über DB-Tabellen übernimmt die Tabelle I117 die Rolle der bisherigen Tabelle I107.
Standardmäßig erfolgt die Verarbeitung über Schnittstellen angelieferter Daten analog zur Dialogfunktion "Positionspläne" (POP). Bereits vorhandene Daten bleiben bestehen, neue Daten werden eingefügt, wobei eine Periode für die Gültig-ab-Angabe benötigt wird. Diese kann explizit als Parameter angegeben werden (z.B. in der Aufrufanwendung IMPORT), alternativ gilt die Angabe in der Vorbelegung (VOR) des Benutzers. Gibt es Zuordnungen des Kontos zu einer Position dieses Positionsplans, die erst ab einem späteren Zeitpunkt gültig ist, wird die eingefügte Zuordnung entsprechend begrenzt.
In der Funktionsvariante "Löschen und Import ..." werden keine vorhandenen Sätze gelöscht (ausgenommen ein Satz ist erst ab der aktuellen Periode gültig), sondern ggf. mit einer Gültig-bis-Periode (aktuelle Periode minus 1 Monat) versehen.
Um Daten 1:1 aus einer IDL.KONSIS-Datenbank in eine andere kopieren zu können, ist auch die Angabe der Gültig-ab- und -bis-Perioden in der Import-Datei bzw. -Tabelle möglich.
Die Anwendung "Import IC-GuV-Davon-Salden" (TXTICKONV) erzeugt u.U. Positions-Konten-Zuordnungen für neu generierte Konten (mit Suffix 'I' in der Kontonummer). Diese Zuordnungen werden mit der aktuellen Periode als Gültig-ab-Periode versehen. Eine Gültig-bis-Periode wird ggf. vom Ursprungskonto übernommen.
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.
Zur Vermeidung von Fremdschlüsselverletzungen wegen fehlender Anlagenobjekte beim Laden der Teilkonzerndaten war das Programm zum Entladen kürzlich dahingehend geändert worden, dass Konzernanlagenobjekte (Kartenart 'K') immer komplett entladen wurden. Dies führte in einzelnen Fällen zu sehr langen Laufzeiten beim Entladen und Laden. Jetzt werden nur noch die Konzernanlagenobjekte entladen, die in den entladenen Konsolidierungsbuchungen angegeben sind.
Die MIS-Datenbereitstellung wurde auf die neue Tabelle K020 für Positions-Konten-Zuordnungen (s.o.) umgestellt. Hierbei wird immer die Struktur angewandt, die in der führenden Periode gültig ist. Dies ist dieselbe Periode, die auch für die Auswertung der Konzernstruktur herangezogen wird.
Die Schnittstelle zum IDL.DESIGNER (IDL.Datamart) wurde auf die neue Tabelle K020 für Positions-Konten-Zuordnungen (s.o.) umgestellt. Hierbei wird immer die Struktur angewandt, die in der führenden Periode gültig ist. Dies ist dieselbe Periode, die auch für die Auswertung der Konzernstruktur herangezogen wird. Eine historisierte Form der Berichte wird vorerst nicht unterstützt.
Die Datenbank-Views zum Auslesen von Konsolidierungsbuchungen wurden um eine Spalte für das Kennzeichen für Ergebniswirksamkeit aus dem Konsolidierungsbeleg (K048) erweitert.
Das Erstellen des Datenwürfels (IDL Datamart) wurde durch Auswertung des Bilanz/GuV-Kennzeichens in den Report-Zeilenbeschreibungen (s.o.) beschleunigt.
Mit der "IDL Smart Connectivity for SAP" bietet IDL seit dem Release 2016 eine Standardschnittstelle für die Übernahme der für die Konsolidierung relevanten Daten aus SAP an. Die Schnittstelle basiert auf der Netweaver-Technologie und damit auf der modernsten Technologie für das Auslesen von Daten aus SAP. IDL Smart Connectivity steht sowohl für das alte als auch das neue Hauptbuch von SAP zur Verfügung. Es handelt sich hierbei um eine Eigenentwicklung der IDL, die unseren Kunden im Zusammenspiel mit den Microsoft Integration Services höchste Flexibilität und weitgehende Automatisierung der Übernahme von Struktur (Kontenplan, Gesellschaften, ...) und Bewegungsdaten (Kontensalden, IC-Salden, Spiegelbewegungen, ...) von SAP nach IDL.KONSIS ermöglicht. Dabei ist sichergestellt, dass die SAP-Systemrichtlinien bzgl. Berechtigungen und CTS (Change and Transport System) vollumfänglich eingehalten werden.
Die Lösung wurde von SAP zertifiziert.
Die in der Vergangenheit bei unseren Kunden realisierten Schnittstellen von SAP nach IDL.KONSIS, die basierend auf dem IDL.IMPORTER und der SAP Connectivity implementiert worden sind, können selbstverständlich weiter genutzt werden. Wir empfehlen unseren Kunden, die Migration auf die IDL Smart Connectivity for SAP zu prüfen.
Wenn Sie Interesse an der neuen SAP-Schnittstelle haben, wenden Sie sich bitte an die IDL Hotline oder Ihren Ansprechpartner im IDL-Vertrieb.
Das Release 2017 enthält die aktuelle Fassung der DCW-Schnittstelle für das DCW-Release 3.50.