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 2017 Update 1 nimmt das Konvertierprogramm folgende Umsetzungen in der Datenbank vor:
Zusätzlich zu den Erweiterungen im Release 2017 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 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:
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.
Es besteht jetzt die Möglichkeit, einen Anwender nach drei fehlerhaften Passworteingaben zu sperren, um sicherzustellen, dass ein Benutzer nicht beliebig verschiedene Passwörter ausprobieren kann. Diese Steuerung kann je Benutzer einzeln aktiviert werden. Voraussetzung ist, dass mit der IDL.KONSIS.FORECAST-internen Passwortverwaltung gearbeitet wird (keine Authentifizierung in der Datenbank oder über das Active Directory).
Zu diesem Zweck wurde die Benutzertabelle (USE) einerseits um einen Schalter zur Aktivierung der Prüfung, andererseits um die Angabe der Anzahl an Fehlversuchen erweitert. Zur Änderung dieser Angaben werden Administratorrechte (IDLSYS oder IDLADMIN) benötigt. Das Entsperren des Benutzers erfolgt durch den Administrator
Die Authentifizierung über das Active Directory (ohne Eingabe von Namen und Passwort, "Single Sign-On") ist durch die Zulassung von Active Directory Gruppen erweitert worden. Die AD-Gruppen können mit Berechtigungsgruppen in IDL.KONSIS.FORECAST verknüpft werden, so dass eine Benutzerrechtesteuerung in IDL.KONSIS.FORECAST bereits im Active Directory erfolgen kann.
Zu diesem Zweck wurde die Tabelle der Benutzergruppen um ein Attribut für eine "Active Directory Gruppe" erweitert. Dieses Attribut kann in den Anwendungen "Benutzergruppen" (BEN) und "Benutzergruppenberechtigungen" (BENDEF) eingesehen und geändert werden. Diese Eingabe ist kundenindividuell, d.h. sie wird auch für die "IDL"-Benutzergruppen beim Releasewechsel nicht überschrieben. Es ist auf korrekte Verwendung von Klein- und Großbuchstaben zu achten.
In der Konfiguration des Application Servers kann je Datenbank-Alias separat festgelegt werden, ob die Prüfung gegen das Active Directory erfolgt. Wenn diese Prüfung aktiviert ist, ermittelt IDL.KONSIS.FORECAST bei der Anmeldung, welchen Gruppen der Benutzer im Active Directory angehört. Die dem Benutzer in IDL.KONSIS.FORECAST zugeordnete Benutzergruppe für Menü- bzw. Objektrechte muss dann auf eine der Active Directory Gruppen verweisen, der der Benutzer angehört. Ansonsten wird die Anmeldung verweigert. Das geschieht auch, wenn der Menüberechtigungsgruppe keine Active Directory Gruppe zugeordnet ist.
Zusätzlich besteht die Möglichkeit, einen neu im Active Directory angelegten Benutzer automatisch auch in IDL.KONSIS.FORECAST als Benutzer anlegen zu lassen. Voraussetzung dafür ist, dass in IDL.KONSIS.FORECAST in der Benutzertabelle (Anwendung USE) eine Benutzervorlage mit den gewünschten Standardangaben angelegt ist.
Zur Kennzeichnung der Benutzervorlage wird die Benutzertabelle (USE) um ein Attribut "Template" erweitert. Der Eintrag von 'X' in diesem Attribut kennzeichnet einen Satz als Benutzervorlage, die selbst nicht für eine Anmeldung verwendet werden darf, sondern nur als Kopiervorlage dient. Es kann zwar mehrere Benutzervorlagen geben, aber jeweils immer nur eine, die einer bestimmten Active Directory Gruppe zugeordnet ist, damit die Ermittlung der zu verwendenden Benutzervorlage eindeutig ist. Bei erfolgreicher Ermittlung der Benutzervorlage wird diese als Kopiervorlage für den neu anzulegenden Benutzer verwendet. Dabei wird die IDL.KONSIS.FORECAST-User-ID aus der Active Directory User-ID abgeleitet.
Das Installationsprogramm für ein neues Release enthält jetzt für die Angabe der Datenbank eine Drop-Down-Box mit den dem jeweiligen IDL.KONSIS.FORECAST Application Server zugeordneten Datenbanken, damit diese einfacher ausgewählt werden können.
Die Konfiguration der Datenbanken wird jetzt strenger geprüft, so dass es nicht mehr möglich ist, Datenbankkonfigurationen zu speichern, die aufgrund fehlender Parameter ungültig sind.
Der Verbindungstest für die konfigurierten Datenbanken umfasst jetzt alle Verbindungswege, so dass z.B. bereits hier festgestellt wird, wenn ein fehlerhafter OLEDB-Treiber vorliegt.
Wenn zwei Bildschirme am Rechner angeschlossen sind und das Anwendungsfenster auf den zweiten Bildschirm gezogen wurde, dann werden jetzt auch die zugehörigen Dialoge (z.B. Meldungsfenster, Hilfetextanzeige) auf diesem Bildschirm angezeigt. Bisher wurden die Dialoge häufig auf dem ersten Bildschirm angezeigt und dort leicht übersehen.
Des weiteren kann das Anwendungsfenster jetzt auch dann auf dem zweiten Bildschirm auf die Maximalgröße maximiert werden, wenn dieser eine höhere Auflösung als der erste Bildschirm hat.
Das Doppelpfeil-Symbol wird jetzt einheitlich mit dem Text "Aktualisieren" als Tooltip bezeichnet. Über der Tabelle wurde dort bisher "Anzeigen" ausgegeben.
Beim Druck von Tabellen mit Spalten mit einer Breite von mehr als 70 Zeichen (s.u.) zeigt der Dialog für die Druckoptionen eine zweite Seite "lange Texte drucken" an, in der eingestellt werden kann, wie die langen Texte gedruckt werden sollen. Angeboten werden folgende Optionen:
Für die letzten beiden Optionen kann zusätzlich die Spaltenbreite zwischen 70 und 255 eingestellt werden.
Auch für die neuen Stammdatenanwendungen (ohne Selektionsbereich, mit Assistenten statt Einzelsatzanwendung) wird jetzt der Modulname im Info-Dialog angezeigt.
Die Seiten der Assistenten der neuen Stammdatenanwendungen wurden jetzt auf eine einheitliche Größe eingestellt. Zwar enthalten einige Seiten dadurch größere Leerflächen, aber die Navigation zwischen den Seiten wird vereinfacht, weil die Knöpfe <Weiter> und <Zurück> wie auch der Navigationsbereich immer an derselben Stelle stehen.
Die in einigen Anwendungen bereits vorgenommene Anzeige der Anzahl der in den jeweiligen Tabellen angezeigten Datensätze (in Klammern hinter der Bezeichnung des Tabellenreiters) erfolgt jetzt in allen derartigen Stammanwendungen.
Combo-Boxen (Eingabefelder mit vorgegebenen Eingabemöglichkeiten) werden jetzt einheitlich so angezeigt, dass in der Auswahlliste zuerst der Schlüssel und dann die Bezeichnung angezeigt wird. Damit stimmt dies auch mit der Darstellung in den Tabellen überein. Außerdem wurden die Felder so verlängert, dass die vollständige Bezeichnung angezeigt werden kann.
In den meisten komplexen Stammdatenanwendungen (führende und abhängige Tabellen) ist es jetzt möglich, abhängige Daten von einem Objekt der führenden Tabelle auf ein anderes Objekt zu kopieren. Dazu werden die zu kopierenden Daten in der jeweiligen Tabelle des geöffneten Modells selektiert, mit der Maus in die führende gezogen und dort auf dem Zielobjekt fallengelassen. Je nach Anwendung ist diese Aktion eingeschränkt (z.B. gleicher Spiegeltyp bei Spiegeldaten), es erfolgt aber keine vollständige Plausibilisierung. Eventuelle Unstimmigkeiten werden erst nach dem Öffnen des Modells für das Zielobjekt in der Tabelle offener Aufgaben angezeigt. Diese Funktionalität wird in folgenden Anwendungen unterstützt:
Wenn in einer komplexen Stammdatenanwendung verschiedene Änderungen (Einfügen, Ändern und Löschen von Daten) durchgeführt wurden, werden diese erst beim Speichern in der Datenbank festgeschrieben. Verursachte das Löschen dabei eine Fremdschlüsselverletzung in der Datenbank, wurden alle Änderungen nicht durchgeführt und waren verloren. Dies wird jetzt dadurch vermieden, dass das Löschen von Daten in eigenen DB-Transaktionen durchgeführt wird.
Es ist jetzt möglich, durch Auswahl des entsprechenden Eintrags im Kontextmenü der Periodentabelle in eine Tabelle der für diese Periode berechtigten Benutzergruppen zu verzweigen. Dies ist eine zusätzliche Tabelle in der Anwendung "Benutzergruppenberechtigungen" (BENDEF).
Beim Erfassen einer Periode mit dem Periodenkennzeichen 'J' oder beim Ändern des Periodenkennzeichens einer Periode auf 'J' wird jetzt eine Warnung ausgegeben, wenn der zeitliche Abstand zur nächsten vorhergehenden Jahresperiode ungleich 12 Monate ist.
Das Zuordnen mehrerer Gesellschaften zu einem Konzernkreis durch Ziehen und Fallenlassen in einem Vorgang wurde erheblich beschleunigt.
Die Eingabe des Umrechnungsfaktors im Assistenten erfolgt nun über eine Radio-Button-Gruppe mit den möglichen Werten 1, 10, 100 und 1000.
In Anlehnung an andere ähnliche Anwendungen wurde die bisherige Anwendung "Positionspläne" (POP) umbenannt in "Positionsplandefinition / Kontenzuordnung" und hat auch das neue Kurzwort "POSDEF" erhalten. Bis auf weiteres kann auch das alte Kurzwort "POP" noch verwendet werden.
Als Periode für die Positions-Konten-Zuordnungen können jetzt auch Perioden angegeben werden, die nicht in der Anwendung "Perioden" (ABR) definiert sind, da sie auch bei der Gültigkeit von Konten und Positionen angegeben werden können und dann ggf. für die Positions-Konten-Zuordnungen übernommen werden.
In Positionsplänen für Kennzahlen (Typ 'K') können keine Konto-Zuordnungen auf Positionen mehr vorgenommen werden. Die entsprechenden Tabellen werden dann gar nicht mehr angezeigt. Außerdem können nur Positionen mit den Klassifizierungen 'Ox' (ohne Kontenzuordnungen) angelegt werden, aber nicht mehr 'Mx' (mit Kontozuordnungen). Wenn ein bestehender Positionsplan gegen diese Regeln verstößt, wird dies in der Liste offener Aufgaben gemeldet.
Die Aktion "Positions-/Kontenzuordnungen" der Anwendung "Positionen" (POS) verzweigt jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Die zusätzlich zu dieser Pflegeanwendung zur Verfügung gestellte Übersicht POSKTOP dient vor allem der periodenübergreifenden Anzeige der Daten in der Datenbank. Diese Anwendung wurde in "Positions+Konten-Zuordnungen - periodische Anzeige" umbenannt, um zu verdeutlichen, dass hier keine Änderungsmöglichkeit besteht. Die Aufrufmöglichkeit der Einzelsatzanwendung wurde deaktiviert.
Die Aktion "Positions-/Kontenzuordnungen" der Anwendungen "Positions+Konten-Zuordnungen - periodische Anzeige" (POSKTOP) und "Positionen+Konten-Zuordnungen- periodisch - Änderungen" (POSKTOPLOG) verzweigen jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Die Anzeige der Übersicht "Konten" (KTO) und die in vielen Anwendungen mögliche Kontenauswahl wurden durch Optimierung der Datenbankzugriffe erheblich beschleunigt. Der Effekt ist abhängig davon, in wie viele Sprachen die Kontenbezeichnungen übersetzt wurden.
Die Aktion "Positions-/Kontenzuordnungen" der Anwendungen "Kontenplandefinition" (KTODEF) und "Konten" (KTO) verzweigt jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Konten und Positionen können jetzt mit Bezeichnungen in einer Länge von bis zu 255 Zeichen versehen werden. Damit können kryptische Abkürzungen, gleiche Bezeichnungen durch abgeschnittene Texte und Textpositionen in Berichten vermieden werden. Bisher lag die Obergrenze bei 70 Zeichen.
Bevor Sie diese Möglichkeit ausnutzen, sollten Sie sich überlegen, ob nachfolgende Systeme, in denen Daten aus IDL.KONSIS.FORECAST weiterverarbeitet werden (z.B. OLAP-Reporting, XBRL-Reporting), die längeren Bezeichnungen problemlos verarbeiten und ausgeben können.
Damit keine Probleme aus versehentlichem Ausnutzen der größeren Länge entstehen, wurden die Tabellen für Konten- und Positionspläne um die Angabe der maximalen Länge der Konto- bzw. Positionsbezeichnungen erweitert. Diese Angabe wird für alle Pläne mit dem bisher gültigen Wert von 70 initialisiert. Nur wenn Sie hier einen größeren Wert eintragen, können längere Bezeichnungen erfasst werden. Dabei kann ein beliebiger Wert zwischen 70 und 255 angegeben werden.
Diese maximale Länge kann aber nur dann wieder verringert werden, wenn es noch keine längeren Bezeichnungen gibt. Ebenso ist das Kopieren von Konten oder Positionen auf einen anderen Konten- bzw. Positionsplan nur dann möglich, wenn die Bezeichnungslängen dem Grenzwert im jeweiligen Zielplan genügen.
Längere Bezeichnungen werden in den Tabellenspalten ggf. verkürzt dargestellt. Die standardmäßig eingestellte Spaltenbreite lässt die Anzeige von ca. 100 Zeichen zu. Kann der Text nicht vollständig angezeigt werden, wird er abgeschnitten und mit "..." am Ende dargestellt. Der vollständige Text kann aber immer als Tooltip angezeigt werden, wenn man mit der Maus auf einer Zelle verweilt. Die Spalten können je nach Bedarf mit der Maus (Doppelpfeil in der Überschriftszeile) breiter oder schmaler gezogen werden.
Um den Import langer Bezeichnungen zu ermöglichen, wurden die Import-/Export-Formate für Konten und Positionen um neue Felder mit einer Länge von 255 Zeichen erweitert. Wenn die Länge von 70 Zeichen nicht überschritten wird, können aber auch die bisherigen Felder weiterverwendet werden.
Der Druck langer Bezeichnungen kann auf verschiedene Weise gesteuert werden: in voller Länge, abgeschnitten oder mit Zeilenumbruch. In den letzten beiden Varianten kann die Breite der Spalte durch Angabe der maximalen Zeichenanzahl bestimmt werden. Der Zeilenumbruch erfolgt "intelligent", d.h. an Wortgrenzen oder bei bestimmten Trennzeichen. Zur Eingabe dieser Werte dient eine neue Seite (Tab-Reiter "lange Texte drucken") im Druck-Optionsdialog.
Für IDL.KONSIS.FORECAST-Reports können die Standardwerte dieser Drucksteuerung auch im Report-Kopfsatz abgelegt werden. Der Druckdialog wird dann entsprechend vorbelegt.
Die Änderungsprotokollierung für Stammdaten wurde um eine Funktion für Controllingobjekte erweitert. Die Protokollierung kann in der Steuerungsanwendung "Steuerung Änderungsprotokollierung" (LOG) in gewohnter Weise über den Tabellenschlüssel "K063" aktiviert, deaktiviert und reorganisiert werden. Das Änderungsprotokoll kann mit der neuen Übersicht "Controllingobjekt-Änderungen" (CNTLOG) eingesehen werden. Diese Funktion erfordert das Vorliegen der Lizenz für Änderungsprotokollierung.
Die Zeit zum Aufbau der Anzeige der Statuswerte des Einzelabschluss-Monitors wurde reduziert. Dies wirkt sich insbesondere bei Verwendung vieler Spiegel oder Spiegelbereiche aus.
Die Darstellung von Nullwerten aus der Datenbank als Nullwert oder als Leerwert in den Einzelsatzmasken der Berichtsdaten wurde neu und einheitlich geregelt.
Die Laufzeit der Überprüfung der Berichtsdaten wurde durch Einführung eines Caches (Zwischenspeichers) für Fehlermeldungen reduziert. Dies wirkt sich insbesondere dann aus, wenn dieselben Fehler wiederholt gemeldet werden, weil z.B. ein systematischer Fehler vorliegt.
In der Formularerfassung für Kontensalden (I-KTOSAL) kann jetzt bei den meisten Spaltenoptionen, ausgenommen die mehrspaltigen Darstellungen für Perioden ('P') bzw. Geschäftsbereiche ('U'), eine Bemerkung direkt in der Tabelle erfasst werden. Sie wird dort auch angezeigt. Bei 'P' und 'U' bleibt die Erfassung der Bemerkung im Zusatzdialog.
Wie bereits für Spiegelbewegungen kann jetzt auch für die Kontensalden ein Report als Default-Report für die Formularerfassung (hier Reportyp 'E' statt 'D') gekennzeichnet werden. Dieser wird dann bei Aufruf der Anwendung 'I-KTOSAL' als Vorbelegung eingestellt. Bisher wurde dafür immer der Report aus der Vorbelegung des Benutzers (VOR) verwendet, der jetzt unabhängig von der Formularerfassung eingestellt werden kann.
Beim Erfassen von IC-Kontensalden müssen Wert und Währungskennzeichen in Transaktionswährung immer gemeinsam angegeben werden. Der Wert kann allerdings auch 0,00 betragen.
Beim Mengenkopieren von Buchungen werden interne Herkunftsangaben der Buchungen nicht mehr mitkopiert. Dadurch verhalten sich die kopierten Buchungen jetzt genauso wie manuell erfasste Buchungen.
Es ist jetzt möglich, mehrere Überleitungsschritte mit einem Aufruf vorzunehmen. Voraussetzung dafür ist die Definition einer Datenartensequenz, die genau diese Schritte umfasst. Der Schlüssel dieser Datenartensequenz ist dann als zusätzlicher Parameter in den Aufrufanwendungen "Einzelabschluss-Monitor" (EA) bzw. "Überleitung auf neue Datenart auswählen" (GESABV) anzugeben. Beispiel:
Wie bereits im Konzernabschluss können jetzt auch im Einzelabschluss latente Steuern auf ergebnisneutrale Sachverhalte (Kapitaländerungen) berechnet und gebucht werden. Ausgenommen sind Buchungen auf dem Ergebniskonto für die Ergebniswirksamkeit, da dieser Betrag bereits über die GuV-Buchungen verarbeitet werden kann.
Die entsprechende Kennzeichnung der "kapitalwirksamen" Belege mit 'K' im Kennzeichen für Ergebniswirksamkeit war bereits gegeben. Auch diese Belege und deren Buchungen können jetzt mit dem Kennzeichen 'LT' zur Berechnung latenter Steuern versehen werden.
Um alle infrage kommenden Buchungen sehen zu können, werden jetzt bei der Verzweigung aus dem Kopfsatz für latente Steuern (LTK) alle Buchungen der für latente Steuern selektierten Belege angezeigt.
Wenn man im Einzelabschluss-Monitor (EA) per Doppelklick auf eine Statusspalte der IC-Saldenabstimmung in die "IC-Clearing Übersicht" verzweigt, so wird diese Folgeanwendung jetzt mit dem Kurzwort "EGESGES" (statt "KGESGES") angezeigt. Diese beiden Kurzwortvarianten unterscheiden sich in ihren Menüs. So fehlt z.B. in EGESGES der Kontextmenüpunkt "IC-Anlagenbewegungen" und ein Doppelklick in die Statusspalten verzweigt in die IC-Kontensalden anstatt in die Konsolidierungsbuchungen.
Wenn Buchungen auf IC-Konten mit Angabe eines Wertes in Transaktionswährung in der Währungsumrechnung zu einem Differenzausgleich führen, dann wird diese Transaktionswährung jetzt auch in die Ausgleichsbuchung eingetragen. Dadurch werden die Kurseffekte korrekt in der IC-Saldenabstimmung berücksichtigt, während es bisher zu Unstimmigkeiten zwischen den Datenarten kam (Status [rot] auf der unteren Datenart, [grün] nach Überleitung auf der nächsten Datenart).
Bisher wurde die in der Vorbelegung des Benutzers (VOR) angegebene Datenart zur Vorbelegung der Datenart in allen Übersichten verwendet. So wurde ggf. auch eine Datenart auf Ebene des Gesellschaftskontenplans in Anwendungen vorbelegt, in denen nur Datenarten auf Ebene des Konzernkontenplans erlaubt sind. Daher wird jetzt in einer Reihe von Anwendungen auf Konzernebene nicht mehr die Datenart aus der Vorbelegung des Benutzers, sondern eine Konzernkreis-Datenart voreingestellt. Deren Ermittlung erfolgt nach folgender Priorität:
Dies betrifft folgende Anwendungen:
Belegkreise, die nur zur Vermeidung von Namenskonflikten als Ergänzung zu einem Belegkreis definiert sind, werden jetzt für Konsolidierungsreports immer wie der führende Belegkreis zugeordnet. Dies betrifft die Belegkreise 'En', 'Fn', 'Kn', 'On', 'Pn', 'Rn' und 'Tn' ('n' = '0' bis '9'). Evtl. bestehende Abweichungen werden durch die Release-Konvertierung korrigiert.
Die Aktion "Positions-/Kontenzuordnungen" der Anwendung "Konsolidierungsparameter" (KTKPAR) verzweigt jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Der Konsolidierungsautomat wurde durch folgende Maßnahmen übersichtlicher gestaltet und aktualisiert:
Für nicht saldenrelevante, zu verprobende Spiegelbereiche ohne Spiegelbereichsaktivierung (ABRSBE/FACSBE) werden in der Schulden- und Aufwands-und Ertragskonsolidierung (SK/AE) keine Eliminierungsbuchungen mehr erzeugt, damit die IC-Salden nicht doppelt eliminiert werden.
Nach Änderung einer AHk-Konsolidierungsbuchung wird jetzt nicht nur die Abschreibung automatisch berechnet, sondern die geänderten Werte in Landeswährung werden auch unmittelbar in Konzernwährung umgerechnet, ohne dass die Funktion "Kurseffekt Verrechnung Unterschiedsbetrag" aufgerufen werden muss. Dies betrifft sowohl die Änderung im Dialog (KONBUCH) als auch durch einen Import (TXTKONBUCH).
Bei der Statusaktualisierung wird der Status "KLW" (Kurseffekte bei der Verrechnung des Unterschiedsbetrags in Landeswährung) nur noch dann auf [rot] gesetzt, wenn der Status zuvor leer war und es mindestens eine Konsolidierungsbuchung mit einer Buchung in abweichender Landeswährung gibt, z.B. wenn die Verarbeitung nach einem Vortrag noch nicht durchgeführt werden konnte, weil es noch keine Wechselkurse gibt.
Wenn mehrere Gesellschaften gleichzeitig auf dieselbe Gesellschaft verschmolzen wurden, konnte es zu Namenskonflikten bei den Belegen zur Eliminierung der Sachverhalte aus der Zwischenergebniseliminierung im Anlagevermögen (Belegkreise 'ZA' bzw. 'PX') kommen. Zur Vermeidung dieses Konflikts wurden neue Belegkreise 'Tn' ('n' = '0' bis '9') eingeführt, die in diesen Fällen anstelle von 'PX' verwendet werden.
Für manuell erfasste oder kopierte Verschmelzungsbelege werden Prüfungen zur Statusaktualisierung nicht mehr durchgeführt.
Bei der Berechnung und Buchung von Fremdanteilen, nachdem die Gesellschaft verschmolzen wurde, werden jetzt nur noch Anteilbesitzbewegungen berücksichtigt, die vor dem Verschmelzungsdatum liegen. Bisher wurden hier immer 100% Fremdanteile ermittelt und gebucht.
Die Währungsumrechnung für Daten auf Konzernebene (Umrechnung von Konsolidierungsbuchungen in die Parallelwährung, Verrechnung des Unterschiedsbetrags in Landeswährung, Berechnung von Kurseffekten für die Zwischenergebniseliminierung im Anlagen- und Umlaufvermögen etc.) bedient sich i.d.R. bei den Währungsumrechnungs-Parametern (WUM) und zugehörigen Daten (Konto- und Buchungsschlüssel-Umrechnungsanweisungen) der jeweiligen Gesellschaften, um die für eine Umrechnung benötigten Informationen über Wechselkursarten, Umrechnungsverfahren und Umrechnungsanweisungen zu erhalten. Ein Problem stellt es dabei dar, wenn für eine Gesellschaft gar kein Währungsumrechnungs-Parameter definiert wurde. Dies ist häufig bei entkonsolidierten Gesellschaften und bei Gesellschaften, die at-Equity konsolidiert werden, der Fall, da hier keine Einzelabschlussdaten mehr vorliegen, oder auch für Gesellschaften, die selbst in Konzernwährung geführt werden, aber einen Unterschiedsbetrag in einer abweichenden Landeswährung verrechnen.
Um hieraus resultierende Probleme im Rahmen der Konsolidierung zu vermeiden, wurde die Möglichkeit geschaffen, Währungsumrechnungs-Parameter für Konzerne zu definieren. Diese werden immer dann von den verschiedenen Konsolidierungsfunktionen verwendet, wenn es keinen Währungsumrechnungs-Parameter für die jeweilige Gesellschaft gibt.
Zur Anzeige und Pflege dieser Daten gibt es die neue Übersicht "Konzern Währungsumrechnungs-Parameter" (WUMK) mit einer zugehörigen Einzelsatzanwendung (WUMKE). Diese unterscheiden sich von den Währungsumrechnungs-Parametern der Gesellschaften in folgenden Punkten:
Werte von Neutralisierungskonten werden nur noch dann in die Endsumme einbezogen, wenn eindeutig nach einem Konto selektiert wurde. In der Übersicht "Kontensalden und Konsolidierungsbuchungen" (KONSAL) gilt dies auch für das Ergebniskonto. Bei den Knotensummen hängt die Berücksichtigung der Neutralisierungskonten von der Sortierung ab.
Prüfregeln können jetzt eingeteilt werden in "harte" Prüfregeln ('H') und "weiche" Prüfregeln ('S' von "soft"). Diese Klassifizierung erfolgt im Prüfregel-Stammsatz in der Anwendung "Prüfregel" (PRFE) oder "Prüfregeldefinition" (PRFDEF). Bestehende Prüfregeln werden zunächst standardgemäß als harte Prüfregeln eingestuft. 'H' ist auch der Standardwert beim Import von Prüfregeln, wenn keine Klassifizierung angegeben ist. Solange keine weichen Prüfregeln definiert werden, ändert sich für den Anwender nichts.
Hintergrund dieser Erweiterung ist, dass nicht erfüllte Prüfregeln bisher immer als Fehler eingestuft werden und so z.B. zu einem [roten] Status eines Einzelabschlusses führen. U.a. im Hinblick auf die kürzlich ermöglichten Prüfregeln für Kennzahlen gibt es aber neben Prüfregeln, die inkonsistente Zahlen aufdecken und durch eine Änderung der Zahlen richtig gestellt werden können, auch Prüfregeln, die zwar nicht erwünschte Zahlen aufdecken, aber nicht korrigiert werden können, da sie nun einmal so sind, wie sie sind. Letztere können jetzt als weiche Prüfregeln definiert werden.
Gibt es sowohl harte als auch weiche Prüfregeln, zeigen die Monitor-Anwendungen (EA, KTKGES) zwei Spalten für die Prüfregelergebnisse an. Jede Spalte für sich zeigt an, ob die jeweiligen Prüfregeln alle erfüllt sind ([grün]) oder nicht ([rot]). Der Status der weichen Prüfregeln hat aber keinen Einfluss auf den vorne angezeigten Gesamtstatus eines Einzelabschlusses. Der Status [gelb] zeigt wie bisher an, dass sich Berichtsdaten verändert haben und das Prüfregelergebnis neu berechnet werden muss.
Ein Doppelklick auf einen Prüfregelstatus verzweigt wie bisher in die Prüfregelergebnis-Übersicht (PRFERG bzw. PRFERGK), wobei die Prüfregelklasse als zusätzlicher Parameter übergeben wird, so dass nur die Ergebnisse der harten bzw. der weichen Prüfregeln angezeigt werden.
Die in den Monitor-Anwendungen angezeigten Stati leiten sich wie bisher aus den Daten der Verarbeitungssteuerung (VERARB bzw. KVERARB) ab, wobei es jetzt für die Prüfregeln zwei neue Check-Point-IDs 'PRFERG-H' und 'PRFERG-S' gibt, die die bisherige Check-Point-ID 'PRFERG' ersetzen.
Daten der führenden Tabelle können jetzt auch geändert werden (z.B. andere Bezeichnung), wenn das zugehörige Modell (Prüfregelpositionen) nicht geöffnet ist.
Die Aktion "Positions-/Kontenzuordnungen" der Anwendung "Prüfregel/Position" (PRFPOS) verzweigt jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Die Protokollierung der Planung kann jetzt nachträglich nicht mehr ab- und wieder angeschaltet werden.
Außer in den Szenario-Einstellungen wird das verwendete ICGP-Profil jetzt auch in der ICGP-Übersicht angezeigt. Von dort kann man direkt in die ICGP-Anwendung verzweigen, so dass immer das richtige Profil angesehen und bearbeitet wird.
Der Start eines Szenarios mit IC-Gegenplanung wurde durch Optimierung der Datenbankzugriffe beschleunigt.
Die Funktionen 'Salden aktualisieren' und 'ICGP-Übernahme' im selben Ablauf führen in den meisten Fällen nicht zum gewünschten Ergebnis, weil die vorhergehenden Gesellschaften ihre ICGP-Übernahme wiederholen müssen, wenn sich durch 'Salden aktualisieren' die Quellsalden in den nachfolgenden Quellgesellschaften ändern. Die bisherige Meldung
wurde daher ersetzt durch die aussagekräftigere Meldung
Die Meldung wurde auch in Bezug auf die Funktion "Salden kopieren/verteilen" analog angepasst.
Die Durchführung von Planungsabläufen wurde beschleunigt, indem die Szenarioliste und der Regelvorlagenbaum beim Start der Planungsanwendung durch den Planungsablauf nicht mehr aufgebaut und angezeigt werden. Auch die unteren Informationsfenster werden dann nicht mehr angezeigt.
In der Szenarioliste wird jetzt der jeweils der Gesellschaft zugeordnete Kontenplan in den Gesellschaftseinträgen unterhalb eines Szenarios angezeigt.
Als Datum "Gespeichert am" wird nicht mehr das letzte Änderungsdatum gemäß Datenbank (z.B. durch Konvertierung bei Releasewechsel) angezeigt, sondern das Datum, an dem das Szenario inhaltlich zuletzt verändert wurde.
Es ist nun möglich, im Szenario gesellschaftsspezifisch einzustellen, ob Regeln nur auf vorhandene Salden angewendet werden sollen, für Konten- und IC-Salden getrennt.
Es gibt eine neue Seite 'Szenarioeinstellungen' im Szenario-Assistenten. Die Einstellungen von der ersten Seite (Intercompany-Planung aktivieren, Plankontenverdichtung aktivieren, ...) sind dorthin umgezogen. Darunter sind die Einstellungen für 'Regeln auf Kontensalden' und 'Regeln auf IC-Salden'. Einstellbar ist jeweils:
Die Einstellung 'Regeln nur auf vorhandenen Salden' kann in den Szenarioeigenschaften im Reiter 'Gesellschaftseinstellungen' je Gesellschaft umgestellt werden.
Parameter werden jetzt mit Änderungsangaben (wann? von wem?) versehen. Die Anzeige dieser Änderungsinformation kann an- und abgeschaltet werden.
Über mehrere neue Schalter in den Szenarioeigenschaften kann jetzt eingestellt werden, ob die Konsistenzprüfungen (Verdichtung, Ergebnisvortragskonto etc.) bei jedem Start des Szenarios erfolgen sollen. Durch Weglassen dieser Prüfungen kann der Start erheblich beschleunigt werden. Die Prüfungen werden aber unabhängig von der Einstellung dieser Schalter immer beim erstmaligen Speichern einer Gesellschaft durchlaufen.
Wenn ein Konto nicht mehr in einem Szenario verwendet wird, dann wird es jetzt beim Speichern einer Gesellschaft auch aus der IC-Voreinstellung entfernt, so dass es anschließend gelöscht werden kann.
Das Starten eines Szenarios konnte durch eine Optimierung der Ermittlung der Planverdichtungskonten und weitere Maßnahmen erheblich beschleunigt werden.
Es gibt in der Werkzeugleiste der Reports einen neuen Button zum Ausblenden von leeren Konten. Die Einstellung bezieht sich nur auf den aktuellen Report und wird nicht gespeichert. Wenn durch Aktualisierung von Salden oder Regeln neue Salden auf leeren Konten entstehen, werden die Konten automatisch wieder eingeblendet.
In den Überschriften der Spalten des Planungsformulars werden die bisher in Klammern angezeigten internen Dimensionsschlüssel ('Q1', 'Q2, ... bzw. 'M01', 'M02', ...) nicht mehr angezeigt.
Quartalssummen werden standardmäßig in Jahren mit Monatsauflösung ausgeblendet.
Bisher wurden die Checkboxen für die Filter auf bestimmte Kontentypen (z.B. IC-Konten, Drittkonten, Verdichtungskonten) automatisch gesetzt, wenn das Planungsformular gar keine Konten dieses Typs enthält. Um zu verdeutlichen, dass diese Filter dann keine Rolle spielen, werden die Checkboxen jetzt in diesem Fall ausgegraut dargestellt.
Die Aktion „Vorlage/Ordner anwenden (ausgew. Periode)" kann jetzt auch dann ausgeführt werden, wenn der Mauszeiger auf der Zelle einer Position steht.
Die Dimensionseinstellungen eines Szenarios werden jetzt für jeden Anwender separat gespeichert und nicht mehr global für alle Anwender.
Der Knopf 'Zurücksetzen' setzt jetzt die Dimensionseinstellungen auf den Standard zurück. Die alte Funktion von 'Zurücksetzen', das Verwerfen der noch nicht angewendeten Änderungen an den Dimensionen, übernimmt der neue Knopf 'Verwerfen'.
In der Übersicht der Plausiprüfungen wird jetzt die Ursache als zweite Spalte angezeigt. Bisher war dies die letzte Spalte. Entsprechend werden die Zeilen auch primär nach der Ursache sortiert.
Die regelindividuellen Einstellungen, ob Regeln nur auf vorhandene Salden angewendet werden sollen, befinden sich in den Regel-Assistenten jeweils auf der letzten Seite. Die Einstellung für Kontensalden ist nur editierbar, falls Drittkonten zugeordnet sind, die Einstellung für IC-Salden ist nur editierbar, falls J- oder IC-Konten zugeordnet sind. Die Standardeinstellung für Konten- und IC-Salden ist, dass die Regel auch auf leeren Salden angewendet wird.
Die Standardeinstellung aller Regeln wurde von "von Kontoveränderung" auf "vom Schlussbestand" umgestellt.
Die Buchungssatztrennung in der Allgemeinen Regel trennt die Buchungssätze nicht nur wie bisher an der Oberfläche, sondern auch in der internen Repräsentation. Wenn die Regel Buchungssätze enthält, die außerhalb des Szenarios liegen, werden dadurch zumindest die Buchungssätze, die noch innerhalb des Szenarios liegen, angewendet und nicht wie bisher die ganze Regel nicht angewendet.
Die Bezugswert-Buchungsregel, die Umsatzregel, die Ertragsregel, die Materialaufwandsregel und die Aufwandsregel können jetzt den IC-Aufriss des Bezugswerts mitnehmen. Dafür muss der Haken für 'Bezugswert mit IC-Aufriss' gesetzt werden. Ist ein statistisches IC-Konto (IC-Kontokennzeichen 'I' oder 'J') für den Bezugswertfaktor vorhanden, wird der jeweilige IC-Saldo als Bezugswertfaktor herangezogen. Diese Regelerweiterung wird in der folgenden Version 18.1 auch für die Finanzierungsregel umgesetzt werden.
Alle Regeln mit Zahlung, Auflösung, Umsatzsteuerauflösung oder Inanspruchnahme zeigen den Status [rot] an und geben eine Meldung aus, wenn ein Konto gegen sich selbst aufgelöst wird.
Der Entfernen-Knopf kann jetzt auch in der Liste der angewendeten Regeln verwendet werden.
Beim Löschen von Geschäftsfällen entfällt der Abfrage, ob auch die Werte gelöscht werden sollen, da nur eine der angebotenen Optionen fachlich sinnvoll ist. Diese Option, nämlich dass nur die von der jeweiligen Regel erzeugten Werte gelöscht werden, wird jetzt standardmäßig durchgeführt. Es gibt daher nur noch eine Abfrage "Sind Sie sicher?".
Die Darstellung des Tabellenablage-Fensters wurde an andere Fenster (Szenarien, Regelvorlagen usw.) angepasst.
Der Name der aktuell im Vordergrund befindlichen Tabelle wird jetzt automatisch im Tabellenablage-Fenster selektiert. Umgekehrt bewirkt ein Mausklick auf die Tabellenablage, dass die entsprechende Tabelle in den Vordergrund gebracht wird.
MSAL-Formeln können für IC-Konten (IC-Kontokennzeichen 'I' oder 'J') angelegt werden. Sie werden dann automatisch auf Dritte angewandt.
Umgekehrt sind IC- und MIC-Formeln auf Drittkonten sowie auch generell in Szenarien ohne Regeln für IC-Beziehungen nicht zulässig. Diese führen jetzt zu einem Syntaxfehler.
Die dritte Seite "Einschränkungen" des Assistenten für Reportzeilenbeschreibungen der Anwendung "Reportdefinition" (REPDEF) wurde neu gestaltet. Die Auswahllisten für Spiegelspalten und Buchungsschlüssel werden jetzt als Tabellen übereinander mit Reitern dargestellt. Dadurch sind sie wesentlich größer und vereinfachen damit das Finden der gesuchten Schlüssel.
Die Aktion "Positions-/Kontenzuordnungen" der Anwendungen "Reportdefinition" (REPDEF) und "Reportzeilenbeschreibungen" (REPZEI) verzweigt jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Wie bereits für Spiegelbewegungen kann jetzt auch für die Kontensalden ein Report als Default-Report für die Formularerfassung gekennzeichnet werden. Diese Kennzeichnung ist daher jetzt auch für einen Report vom Reporttyp 'E' (Bilanz/GuV-Report) zugelassen. Dieser wird dann bei Aufruf der Anwendung 'I-KTOSAL' als Vorbelegung eingestellt.
Wenn Sie die Möglichkeit langer Bezeichnungen für Konten und/oder Positionen (s.o.) nutzen, kann durch neue Angaben im Report-Kopfsatz gesteuert werden, wie diese Bezeichnungen standardmäßig ausgedruckt werden sollen. In der Option "Drucken lange Bezeichnungen" stehen folgende Varianten zur Verfügung:
Für die ersten beiden Varianten kann zusätzlich im Feld "Stellenanzahl beim Druck langer Bezeichnungen" die gewünschte Breite der Spalte vorgegeben werden.
Beim Druck eines Reports wird die Optionsseite für lange Bezeichnungen gemäß diesen Angaben vorbelegt, kann aber bei Bedarf auch überschrieben werden.
Die Import-/Export-Formate wurden auf die aktuellen Datenbank-Erweiterungen angepasst.
Die Laufzeit der Importanwendungen wurde durch Einführung eines Caches (Zwischenspeichers) für Fehlermeldungen reduziert. Dies wirkt sich insbesondere dann aus, wenn dieselben Fehler wiederholt gemeldet werden, weil z.B. ein systematischer Fehler vorliegt.
Die Aktion "Anzeigen Übersicht" für die Zeilen "Positionspläne", "Positionen" und "Positions-/Konten-Zuordnungen" der Anwendungen "Import" (IMPORT) und "Import/Export-Job-Steuerungen" (IEJOB) verzweigt jetzt auf die entsprechende Seite der Anwendung "Positionsplandefinition / Kontenzuordnungen" (POSDEF).
Der Import von Kontostammsätzen dauerte seit dem Wechsel auf das Release 2017 deutlich länger, wenn die Konten mit sich ändernden Gültigkeitsangaben versehen waren, da die seit diesem Release periodenabhängigen Positions-Konten-Zuordnungen auf die veränderte Gültigkeit angepasst werden müssen. Der Import von Konten wurde jetzt durch Optimierung der Datenbank-Zugriffe deutlich beschleunigt. Die Gültigkeit von Konten sollte aber nur in begründeten Fällen eingeschränkt werden.
Beim Import von Konten und Positionen können jetzt auch Bezeichnungen in einer Länge von mehr als 70 Stellen übernommen werden (s.o.). Die Import-/Exportformate wurden dazu um die Felder K010-BENEL-KTO bzw. K022-BENEL-AGG erweitert. Sofern die Länge der Bezeichnungen den bisherigen Höchstwert von 70 nicht überschreitet, können alternativ auch die bisherigen Bezeichnungsfelder weiter genutzt werden. In den Import-Tabellen I105 und I106 wurden die bestehenden Spalten I105_BENE1_KTO_UC bzw. I106_BENE1_AGG_UC auf 255 Zeichen verlängert, so dass hier keine Anpassung von Schnittstellen erforderlich ist.
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.
Beim Auslesen von Teilkonzerndaten wird jetzt geprüft, ob in den ausgelesenen Währungsumrechnungs-Parametern (WUM) Referenz-Gesellschaften angegeben sind, die nicht in den Teilkonzerndaten enthalten sind. Deren Währungsumrechnungs-Parameter werden dann zusätzlich übertragen, um auf der Zieldatenbank eine Währungsumrechnung für die übertragenen Gesellschaften zu ermöglichen.
Beim Auslesen der konzernweiten Daten wird jetzt geprüft, ob es Prüfregeln/Positionen gibt, in denen Konten oder Controllingobjekte aus Gesellschafts-Konten- bzw. -Controllingplänen referenziert werden. Diese Konten und Controllingobjekte werden dann zusätzlich zu den konzernweiten Daten ausgelesen und übertragen. Diese Erweiterung ist insbesondere hilfreich, wenn der Datenaustausch dazu genutzt wird, sowohl konzernweite als auch Teilkonzerndaten von einer Quelle in dieselbe Zieldatenbank zu übertragen.
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 2018 enthält die aktuelle Fassung der DCW-Schnittstelle für das DCW-Release 3.50.