Das Release IDL.KONSIS.FORECAST 2009.2 ist ein Zwischenrelease und kann daher in der Releasefolge ausgelassen werden. Mindestvoraussetzung für dieses Release ist das letzte Hauptrelease IDL.KONSIS.FORECAST 2009.0 vom 19. 8. 2009. Es kann aber auch nachfolgend zur Installation des Zwischenreleases 2009.1 vom 26. 11. 2009 installiert werden.
Die bis zum Release-Abschluss erfolgten Nachträge und Korrekturen zum Hauptrelease IDL.KONSIS.FORECAST 2009.0 und zum Zwischenrelease 2009.1 sind in diesem Zwischenrelease enthalten.
Diese Dokumentation beschreibt die Erweiterungen seit dem Zwischenrelease IDL.KONSIS.FORECAST 2009.1.
Vor Installation eines neuen Releases sollte grundsätzlich eine Datenbank-Sicherung vorgenommen werden. Um den Anwender vor Datenverlust zu schützen, wird ein Hinweis auf die notwendige Datensicherung vom Installationsprogramm am Anfang der Installation ausgegeben.
Wie bereits für die Kapitalkonsolidierung mit Bezug auf die Anteilsbesitzbewegungen wird jetzt auch für die Schulden- (SK) sowie die Aufwands-/Ertragskonsolidierung (AE) geprüft, ob alle relevanten IC-Kontensalden einen Eintrag einer Konsolidierungsbelegnummer als Nachweis ihrer Verarbeitung aufweisen. Ist dies nicht der Fall, wird der betreffende Status im Konzernkreis-Monitor (KTKGES) auf [rot] gesetzt.
Um zu vermeiden, dass sich Statuswerte abgeschlossener Perioden dadurch ändern, wird dringend empfohlen, diese Perioden zu sperren, sofern die Konzernabschlüsse nicht gesperrt wurden. Voraussetzung dafür ist die Aktivierung der Objektberechtigung für Perioden für alle Benutzer. Das Sperren der Konzernabschlüsse ist nur vor dem Einspielen dieses Releases möglich, da mit dem neuen Release die Statusänderung bereits vor der Sperre erfolgt.
Wegen der Einführung eines neuen Verfahrens zur Darstellung der Ergebniswirksamkeit von Konsolidierungsbelegen (s.u.) sollte ein Konzernabschluss entweder noch komplett mit dem bisherigen Releasestand durchgeführt werden oder komplett einschl. der Konzernvorträge, aber ohne die Funktion "Konzernergebnisverrechnung" mit dem neuen Releasestand.
Nach Installation eines neuen Releases muss grundsätzlich als erstes die Release-Konvertierung (s. Kap. 3.1) vorgenommen werden. Vor Durchführung der Konvertierung wird der Aufruf anderer Anwendungen gesperrt. Ausgenommen sind lediglich die Anwendungen zur Pflege der Berechtigungsdaten, falls der angemeldete Benutzer wegen Verwendung individueller Berechtigungsgruppen keine Berechtigung zur Ausführung der Konvertierung hat.
Aus technischen Gründen kann die Konvertierung von IDL.FORECAST-Daten vorerst nicht im Rahmen der allgemeinen Release-Konvertierung erfolgen. Die Konvertierung muss daher für IDL.FORECAST-Daten separat gestartet werden. Dazu dient ein neuer Eintrag im Aktionsmenü der Anwendung "Planungsformular" (PLAN).
In der Entwicklung für die Excel-Anbindung IDLCONNECTOR von IDL.KONSIS.FORECAST befinden sich zusätzliche Funktionen, die mindestens die Version MS Excel 2003 voraussetzen. Wir empfehlen daher die Aufrüstung auf MS Excel 2003 oder noch besser MS Excel 2007.
Die Probleme mit der "Look & Feel"-Einstellung Nimbus wurden behoben.
Für Sperren wurden bisher die Symbole gemäß "Ampeldarstellung" für die Statusanzeige verwendet: grüner Haken = gesperrt, gelbes Warndreieck: Sperre aufgehoben. Diese Sperrzustände werden jetzt durch neue eigene Symbole dargestellt: geschlossenes Vorhängeschloss mit grünem Haken bzw. offenes Vorhängeschloss mit gelbem Warndreieck. Dies betrifft die Monitor-Anwendungen (EA, KTKGES) sowie die Übersichten für Reports (REP, REPK) und Konsolidierungsbelege (KONBEL).
Das Konvertierprogramm für dieses Release nimmt folgende Umsetzungen in der Datenbank vor:
Folgende Menü-IDs sind in diesem Release neu. Falls vollständig gepflegte kundenspezifische Berechtigungsgruppen verwendet werden, müssen für diese Menüpunkte ggf. Berechtigungen (BENMEN) gepflegt werden. Als Vorlage können i.d.R. die Menüberechtigungen der Benutzergruppe IDLKON bzw. IDLWIN dienen.
Als Alternative zur vollständigen Pflege der Berechtigungen für alle Menüpunkte wird das Verfahren zur vereinfachten Pflege von kundenspezifischen Berechtigungsgruppen empfohlen. Für diese Funktionalität kann für eine Menü-Berechtigung (BENMENE) auch die neue Berechtigungsstufe '0' angegeben werden. Diese besagt, dass eine für die Referenz-Benutzergruppe verfügbare Berechtigung für die angegebene Benutzergruppe nicht gegeben sein soll.
Die Menüpunkte 'EABVORxxx', 'LOEVORxxx' und 'PERGESxxx' ('xxx' = 'ANL', 'BET', 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') sowie 'REPERGGxxx' und 'REPERGKxxx' ('xxx' = 'KAP', 'RUE', 'SP0', 'SP1', ... 'SP9') wurden bereits mit dem Release 2009.0 deaktiviert und haben keine Bedeutung mehr. Sie müssen alle individuellen Berechtigungen für diese Menüpunkte vor Installation dieses Releases gelöscht haben, damit diese Menüpunkte selbst bei der Installation dieses Folgereleases 2009.2 gelöscht werden können. Erhalten bleibt in diesen Fällen nur jeweils ein Menüpunkt mit 'xxx' = 'SPI'.
Konten dienen i.d.R. der Erfassung von Berichtsdaten. Daher werden die mit dem Release 2009.1 eingeführten Erfassungskennzeichen je Periodentyp jetzt beim Erfassen eines neuen Kontos vorbelegt, so dass sie nicht mehr explizit gesetzt werden müssen.
Auch beim Import wird unterstellt, dass gesetzte Erfassungskennzeichen den Normalfall darstellen. Sind diese Attribute in den Eingabedaten leer, so werden sie beim Einfügen des Datensatzes gesetzt. Um Konten ohne Erfassungskennzeichen zu erzeugen, muss in den Eingabedaten explizit das Löschkennzeichen '*' angegeben werden. Ausgenommen sind lediglich Spezialkonten mit den Kontokennzeichen 'E' oder 'Q', für die die Erfassungskennzeichen ohnehin nicht gesetzt werden dürfen.
Eine Änderung der Erfassungskennzeichen eines Konzernkontos wurde auch bisher schon an die zugeordneten Gesellschaftskonten weitergegeben. Jetzt erfolgt auch eine Übernahme der Erfassungskennzeichen bei der Änderung des zugeordneten Konzernkontos für ein Gesellschaftskonto. Dies betrifft die gewöhnliche Pflege des Kontenstamms wie auch das Laden der konzernweiten Daten (KONDAT) in einer Teilkonzern-Datenbank.
Die Auswahlanzeige von Konten wurde im Hinblick auf die Erfassungskennzeichen wie folgt überarbeitet: In den Anwendungen zur Erfassung von Berichtsdaten (Einzelsatz, Formularerfassung) werden nicht erfassbare Konten in der Auswahl nicht angeboten, in allen anderen Anwendungen (Übersichten, Parameteranwendungen) werden dagegen wieder alle Konten zur Selektion der Daten angezeigt.
In der Übersicht "Positionen + Konten-Zuordnungen" wurden Selektionsmöglichkeiten nach Kontokennzeichen, Spiegel und Rechnungslegungsart des Kontos ergänzt.
Bei der Sortieroption 'P' (nur Konten mit abweichender Positionszuordnung des zugeordneten Konzernkontos) besteht zusätzlich die Möglichkeit zur Selektion nach dem Fehlerstatus ('1' = unterschiedliche Soll/Haben-Steuerung, '2' = keine Positionszuordnung des Konzernkontos, '3' = keine Positionszuordnung des Gesellschaftskontos, '4' = Konzern-Wechselkonto und Soll/Haben-Steuerung, '5' = fehlende Positionszuordnung für Konzernkonto mit Wechselkonto, '6'= überflüssige Positionszuordnung des Konzernkontos).
Für Konten mit fest zugeordneter IC-Gesellschaft (sogenannte IC-Hauptkonten) wird jetzt sichergestellt, dass das Konto nicht länger gültig ist als die IC-Gesellschaft, da sonst ungültige Daten erzeugt werden könnten. Die Erweiterung der Gültigkeit des Kontos verursacht einen Fehler. Die Einschränkung der Gültigkeit der Gesellschaft wird an das Konto vererbt.
Die Beschränkung der Gültigkeit eines Konzernkontos wird jetzt automatisch an die zugeordneten Gesellschaftskonten weitergegeben. Dies betrifft die gewöhnliche Pflege des Kontenstamms wie auch das Laden der konzernweiten Daten (KONDAT) in einem Teilkonzern.
Hierarchien für Controllingobjekte können jetzt für alle definierten Controllingdimensionen aufgebaut werden. Bisher war dies nur für die erste Controllingdimension möglich. Dies betrifft sowohl das Setzen des Aggregationskennzeichens im Controllingobjektstamm (CNT) und die Zuordnung in der Zuordnungstabelle CNTCNT als auch die Anzeige in der Übersicht "Controllingsalden" (CNTSAL).
In der Übersicht "Controllingobjekt-Hierarchien" wird jetzt bei Baumdarstellung zusätzlich die Hierarchie-Ebene angezeigt. Diese wird ggf. für Steuerungen von Reports (s.u.) benötigt.
Der (ehemalige Standard-)Kapital-Buchungsschlüssel '05' wurde durch die Konvertierung für das Release 2009.0 mit dem Verwendungskennzeichen 'JU' versehen. Obwohl gleichzeitig festgelegt wurde, dass der Buchungsschlüssel mit dem Verwendungskennzeichen 'JU' als reserviert gilt, d.h. nicht für manuell erfasste Daten verwendet werden darf, fehlte dieser Eintrag in der Konvertierung, so dass die manuelle Verwendung möglich war. Bei einer beliebigen Änderung des BSL-Stammsatzes (z.B. der Bezeichnung) wurde das Reservierungskennzeichen jedoch gesetzt und der Buchungsschlüssel konnte nicht mehr frei verwendet werden. Damit dies bei allen Anwendern wieder einheitlich funktioniert, setzt das Konvertierprogramm für das Release 2009.2 das Reservierungskennzeichen für den Buchungsschlüssel mit Verwendungskennzeichen 'JU'. Sollte der Bedarf für eine manuelle Buchung in diese Spiegelspalte bestehen, so kann jederzeit ein weiterer Buchungsschlüssel definiert werden oder der Buchungsschlüssel '16' verwendet werden, der nicht automatisch das Verwendungskennzeichen 'JU' erhalten hatte.
In der Übersicht "Gesellschafts+Geschäftsbereichs-Zuordnungen" wurde eine Aktion zum Mengenändern ergänzt. Dort kann das Attribut "Kontogruppe" geändert werden.
Die Funktion "Mengenändern" der Übersicht "Perioden" wurde erweitert. Jetzt können hier auch die Attribute "Periodenkennzeichen" und "Prüfregel-Ausschlussgruppe" für mehrere markierte Perioden geändert werden.
Die Spalte für das Attribut "Prüfregel-Ausschlussgruppe" wird in der Übersicht weiter vorne vor den Schaltern für die Aufrissdaten angezeigt.
Eine völlig neue Funktionalität ermöglicht den Durchgriff ("Drill through") auf vorgelagerte Systeme, um anzeigen zu lassen, wie sich die in IDL.KONSIS.FORECAST geführten Werte aus Daten des Herkunftssystems zusammensetzen. Diese Funktion wird zunächst für Kontensalden zur Verfügung gestellt und durch eine Aktion aus der Übersicht "Kontensalden" (KTOSAL) oder der Formularerfassung für Kontensalden (I-KTOSAL) aufgerufen.
Die Schlüsselwerte für Periode, Datenart, Gesellschaft, Geschäftsbereich und Kontonummer werden an die neue Anwendung übergeben und dort im Selektionsbereich angezeigt. Ist eine Konfiguration für diese Abfrage bereits hinterlegt, kann die Schaltfläche <Anzeigen> betätigt werden und in der Tabelle werden die aus der Herkunftsdatenbank selektierten Werte angezeigt.
Ist noch keine Konfiguration definiert, so ist die zweite Registerkarte "Konfiguration" des Selektionsbereichs zu aktivieren. Dort gibt es auf der linken Seite Eingabefelder (URL der Verbindung, Java-Klasse des Treibers, Benutzername für die Anmeldung) für die Verbindung zur externen Datenbank. Auf der rechten Seite ist ein Eingabefeld für den SQL-Befehl zur Abfrage der Daten. Die Eingaben in diesen Feldern werden durch die Schaltfläche <Speichern> in der Datenbank festgehalten und stehen für folgende Aufrufe dieser Funktion zur Verfügung.
Aus Gründen der Datensicherheit, wird in der IDL.KONSIS.FORECAST-Datenbank nur der Benutzername für die Anmeldung gespeichert, aber nicht das Passwort. Das Passwort ist daher in einer Anmeldemaske anzugeben, die jeweils vor der Anzeige der Daten auszufüllen ist.
Technischer Hinweis: Die Zugriffe auf die externe Datenbank erfolgen mittels JDBC. Ein passender JDBC-Treiber für das Datenbanksystem muss anwenderseitig zur Verfügung gestellt werden.
Der Status für Sperren der Einzelabschlüsse oder der IC-Kontensalden wird jetzt durch neue Symbole (s.o.) angezeigt.
Es ist jetzt möglich, auf IC-Hauptkonten Daten für die feste IC-Gesellschaft als Schlüssel-Gesellschaft zu erfassen, wenn dem IC-Hauptkonto zusätzlich ein fester IC-Geschäftsbereich zugeordnet ist, der sich vom Schlüssel-Geschäftsbereich unterscheidet. Entsprechend war es auch bisher schon möglich, z.B. IC-Kontensalden zu erfassen, bei denen Gesellschaft und IC-Gesellschaft gleich waren, wenn Geschäftsbereich und IC-Geschäftsbereich verschieden waren.
In der Tabelle der Übersicht "Kontensalden" wurde eine Spalte für das Attribut "Umbuchung beim Vortrag" aus dem Kontenstamm ergänzt.
Die Übersicht "Controllingsalden" ermöglicht jetzt eine Selektion nach Controllingobjekten aus beliebigen Controllingdimensionen. Dazu muss im Selektionsbereich zumindest der Controllingplan der betreffenden Controllingdimension angegeben werden. In der Tabelle werden dann die Controllingobjekte dieser Dimension im festen Bereich dargestellt. Dies umfasst auch die Baumdarstellung bei Definition von Hierarchien von Controllingobjekten.
Zur Generierung von Controllingsalden aus IC-Kontensalden mit Angabe von Controllingobjekten steht jetzt eine zweite Funktion im Aktionsmenü der Übersicht "IC-Unterkontensalden" (ICKTOSAL) zur Verfügung. In dieser Funktion werden auch für Konten mit dem Kontokennzeichen 'J' Controllingsalden erzeugt. Beachten Sie bei Anwendung dieser Funktion bitte, dass die Summe der erzeugten Controllingsalden nicht dem Kontensaldo entspricht, wenn die Summe der IC-Kontensalden nicht dem Kontensaldo entspricht, da das Konto auch Sachverhalte gegenüber Dritten enthält.
Bei Verzweigung aus der IC-Clearing-Übersicht (KGESGES), d.h. in der Pärchensicht und bei eindeutiger Vorgabe der Konsolidierungsverarbeitung, sowie bei Schalterstellung "Behandlung TW-Differenz als Sachdifferenz" im jeweiligen Konsolidierungsparameter werden in zusätzlichen Spalten der Transaktionswährungswert umgerechnet in die Konzernwährung sowie dessen Differenz zum eigentlichen Wert in Konzernwährung (umgerechnet aus dem Wert in Landeswährung) dargestellt. So können die nach diesem Verfahren verbuchten Werte direkt nachvollzogen werden. Dafür entfällt in diesem Fall die bisherige Gliederung nach Transaktionswährungen.
Das Attribut "Mehr/Mindererlös Wert KW", das anzugeben ist, wenn eine Gesellschaft den Konzernkreis verlässt, war in der Datenbank mit nur 9 Stellen vor dem Komma definiert. Dadurch konnten keine Beträge größer als 1.000.000.000 angegeben werden. Um wie für andere Beträge 13 Stellen vor dem Komma zuzulassen, musste ein neues Datenbankfeld definiert werden. Dieses wird durch die Release-Konvertierung mit den Werten des bisherigen Feldes belegt. An der Oberfläche ändert sich dadurch nichts.
Für ergebniswirksame Belege wird jetzt automatisch eine zusätzliche Buchung in Höhe der Ergebniswirksamkeit auf dem Ergebniskonto (mit Kontokennzeichen 'E') erzeugt. Diese Buchung wird natürlich nicht in die Berechnung der Soll/Haben-Gleichheit und der Ergebniswirksamkeit eingerechnet. Sie wird auch nicht in die Berechnung der Prüfsumme des Belegs einbezogen.
Die Erzeugung dieser zusätzlichen Buchung erfolgt bei jeder Verprobung der Belege, also bei Anzeige der Buchungen sowie bei jeder Änderung. Diese Buchungen werden aber nicht für gesperrte Perioden und gesperrte Einzelabschlüsse erzeugt.
Beim Import von Buchungen (z.B. nach Export aus einer anderen IDL.KONSIS.FORECAST-Installation) werden Buchungen auf dem Ergebniskonto ignoriert, ohne dass dies gemeldet wird. Diese Buchungen werden aber durch die anschließende Verprobung wieder neu erzeugt.
Beim Vortrag von Buchungen in die nächste Periode werden diese Buchungen auf dem Ergebniskonto ebenfalls ignoriert, so dass der Vortragsbeleg gleich bleibt unabhängig davon, ob in der Vorperiode bereits eine Buchung auf dem Ergebniskonto erzeugt wurde oder nicht.
Auch bei der Währungsumrechnung werden diese Buchungen nicht verarbeitet. Vielmehr werden diese Buchungen bei der anschließenden Verprobung mit Werten in allen drei Währungen (Landes-, Konzern- und Parallelwährung) erzeugt.
Bei der Überleitung auf die nächste Datenart werden diese Buchungen ebenfalls ignoriert. Die Ergebniswirksamkeit spiegelt sich aber wie bisher durch eine Veränderung des Kontensaldos auf dem Ergebniskonto wider.
In der Formularerfassung für Buchungen (I-BUCH) werden diese Buchungen auf dem Ergebniskonto zwar angezeigt, können aber nicht geändert werden. Sie werden natürlich auch nicht zur Berechnung von Differenzen herangezogen.
Die Programme zur Erstellung von Reports wurden nicht geändert, da die Berücksichtigung der Buchungen auf dem Ergebniskonto genau dem Zweck entspricht, zu dem diese Buchungen eingeführt wurden. Insbesondere führen jetzt Kapitalfluss-Reports auf Datenarten unterhalb der Konsolidierungsebene unter Einbeziehung dieser Buchungen zum richtigen Ergebnis. Verbesserungen ergeben sich auch für Reports mit Herkunftsnachweis.
Weiterer Vorteil dieser Buchungen auf dem Ergebniskonto ist die Möglichkeit der Vortragsabstimmung und anderer Konsistenzprüfungen mit Hilfe von Prüfregeln auf Datenarten mit Buchungen.
Die Kennzeichnung von Buchungen zur Berechnung latenter Steuern ist jetzt für alle automatisch erzeugten Buchungen (z.B. automatische AfA-Berechnung) zugelassen, auch wenn der Benutzer nicht über Sonderberechtigung (z.B. zum Ändern von Buchungen mit reservierten Buchungsschlüsseln) verfügt.
Die Anwendungen zur Formularerfassung von Berichtsdaten (Kontensalden, IC-Kontensalden) werten jetzt das Attribut "Kontogruppe" aus der Gesellschafts+Geschäftsbereichs-Zuordnung (GESUBR) aus. Ist z.B. für eine Gesellschaft ein Geschäftsbereich mit 'G' (nur GuV) attributiert, so werden keine Bilanzkonten zur Erfassung angeboten.
Die Formularerfassung für Kontensalden ermöglicht jetzt gleichzeitig die Anzeige einer nicht erfassbaren Spalte mit Vergleichswerten (z.B. Ist-Saldo des letzten Jahresabschlusses) und die Eingabe mehrerer Perioden (z.B. Plandaten für die Quartale des laufenden Jahres) nebeneinander. Dazu erhielt der Selektionsbereich statt des Eingabefeldes "Vorperiode" jetzt zwei Eingabefelder "ab Periode" für den Anfang des Erfassungsintervalls (Eingabe nur bei Spaltenoption 'P' erlaubt) und "Vergleichsperiode" (Eingabe bei den Spaltenoptionen 'P' und 'D' erlaubt).
Die Möglichkeiten zum Erfassen und Ändern von Bewegungen für reservierte Buchungsschlüssel wurden an die Einzelsatzanwendungen angepasst. Liegt eine Sonderberechtigung für die Aktionen "Ändern" und "Einfügen" vor, so können derartige Daten auch in der Formularerfassung erfasst und geändert werden.
Auf Datenarten mit Führung der Daten nach Geschäftsbereichen können Buchungen für alle Geschäftsbereiche jetzt in einem Formular erfasst werden. Das Selektionsfeld für den Geschäftsbereich erlaubt dazu auch die Eingabe '%' zur Selektion aller Geschäftsbereiche oder entsprechender teilqualifizierter Angaben.
Folgender neuer Prüfregel-Operator wurde ergänzt:
Diese Prüfregel kann auch unter Angabe von Toleranzen definiert werden.
Toleranzen können jetzt für weitere Prüfregeln angegeben werden, insbesondere auch für Prüfregeln mit Ungleich-Operatoren, z.B. "L>=R". Diese Prüfregel gilt damit auch dann erfüllt, wenn die linke Seite kleiner als die rechte Seite ist, sofern die Differenz kleiner als die angegebene Toleranz ist. Bisher konnten Toleranzen nur für Gleichheits-Operatoren angewandt werden.
Das Löschen von (z.B. testweise angelegten) Prüfregeln gestaltete sich schwierig, wenn es bereits zugeordnete Daten für diese Prüfregeln gab. Dies wurde jetzt dadurch vereinfacht, dass beim Löschen einer Prüfregel auch alle bereits dazu definierten Prüfregelpositionen automatisch mitgelöscht werden. Bereits bestehende Prüfregel-Ergebnisse müssen aber weiterhin manuell entfernt werden.
Wenn (z.B. durch die Definition und Zuordnung einer Prüfregel-Ausschlussgruppe) für einen Einzel- oder Konzernabschluss überhaupt keine Prüfregeln anzuwenden waren, wird der zugehörige Status jetzt auf [-] gesetzt. Bisher wurde der Prüfregel-Status auf [grün] (alle Prüfregeln erfüllt) gesetzt.
Für gesperrte Einzel- oder Konzernabschlüsse können jetzt keine neuen Prüfregelergebnisse mehr berechnet werden. Bisher war dies möglich und hatte ggf. zur Folge, dass der Prüfregelstatus von [grün] auf [rot] wechselte, weil neue Prüfregeln definiert worden waren oder weil sich Daten in einer Vergleichsperiode oder -datenart geändert hatten, während die Daten des aktuellen Abschlusses unverändert waren.
Die Einzelabschlussdaten von Gesellschaften, die die Konsolidierungsart 'K' (nicht konsolidiert) oder 'E' (at Equity) aufweisen, werden in das Konzern-Prüfregelergebnis nicht mehr einbezogen. Konsolidierungsbuchungen für diese Gesellschaften werden aber (in Übereinstimmung mit Konzern-Reports, den Übersichten "Kontensalden und Konsolidierungsbuchungen" (KONSAL) und "Bewegungen und Konsolidierungsbuchungen" (KONBEW) sowie dem Teilkonzern-Datenaustausch) weiterhin einbezogen.
Der Periodenvortrag trägt jetzt Buchungen mit der Umrechnungsanweisung 'MDK' unterjährig mit der Umrechnungsanweisung 'VKW' bzw. 'VPW' vor. Derartige Buchungen werden bei der Berechnung der laufenden Abschreibungen nicht mehr gelöscht, so dass ggf. nur noch die Abschreibung für den letzten Monat errechnet und gebucht wird. Beim Überleiten der Daten auf die nächste Datenart werden mit Monatskursen umgerechnete unterjährige Vorträge entsprechend berücksichtigt.
Es ist möglich, Gesellschaften zu konsolidieren, deren Beteiligungsbuchwerte und Beteiligungsprozentwerte null sind. Die zugehörige Anteilsbesitzbewegung (GESGES) wird jetzt vorgetragen, obwohl alle Werte null sind, damit die Beteiligungsermittlung auch in der Folgeperiode korrekt erfolgt. Wird hingegen ein Vortrag durch einen Abgang eliminiert, wird kein Vortragssatz erstellt.
Der Periodenvortrag für Konzerndaten gibt eine Warnungsmeldung aus, wenn es in der Zielumgebung bereits Daten für eine Konzernkreis-Definition gibt. Die Wiederholung dieser Meldung kann jetzt für eine eventuelle Mengenverarbeitung über eine Automatensteuerung unterdrückt werden.
Die Statusermittlung für den Konzernabschluss prüft u.a., ob in den konsolidierungsrelevanten Einzelabschlussdaten (IC-Kontensalden, Anteilsbesitzbewegungen) bereits eine Konsolidierungsbelegnummer als Nachweis der Konsolidierung eingetragen ist. Beim erneuten Überleiten der Einzelabschlussdaten aus der vorhergehenden Datenart bleibt dieser Eintrag jetzt erhalten, sofern sich diese Daten überhaupt nicht verändert haben, damit der Status der zugehörigen Konsolidierungsverarbeitungen ('SK', 'AE', 'KK) [grün] bleibt. Die Meldung "Nach Vortrag erneute Durchführung der SK und AE in akt. Per. notwendig" kommt jetzt nur noch, wenn bereits Belegnummern in den vorherigen Daten eingetragen waren und die neuen Daten nicht völlig übereinstimmen.
Für die Umrechnung von (GuV-)Konten zu monatlich gewichteten Durchschnittskursen (MDK) müssen die betreffenden Konten in den Konto-Umrechnungsanweisungen (KTOUAW) mit der Umrechnungsanweisung 'FDK' (fortgeschriebener Durchschnittskurs) versehen werden. Damit dies nicht für alle neuen GuV-Konten gepflegt werden muss, wurde ein neues Umrechnungsverfahren 'MMW' (modifiziert mit monatlich gewichteten Durchschnittskursen) eingeführt, das in den Währungsumrechnungs-Kopfsätzen eingetragen werden kann. Ohne explizite Angabe in den Konto-Umrechnungsanweisungen gilt dann die Umrechnungsanweisung 'SK' (Stichtagskurs) für alle Bilanzkonten und 'FDK' für alle GuV-Konten.
Für IC-Anlagenbewegungen werden jetzt Kurseffekte berechnet und gebucht, auch wenn es keinen Kontensaldo als Abstimmwert gibt. Stattdessen wird die Summe aller Bewegungen zu einem Anlagenobjekt, mit dem Stichtagskurs von der Landes- in die Konzernwährung umgerechnet, als Abstimmwert verwendet.
Wie bereits für die Kapitalkonsolidierung mit Bezug auf die Anteilsbesitzbewegungen wird jetzt auch für die Schulden- (SK) sowie die Aufwands-/Ertragskonsolidierung (AE) geprüft, ob alle relevanten IC-Kontensalden einen Eintrag einer Konsolidierungsbelegnummer als Nachweis ihrer Verarbeitung aufweisen. Ist dies nicht der Fall, wird der betreffende Status auf [rot] gesetzt.
Hinweis: Um zu vermeiden, dass sich Statuswerte abgeschlossener Perioden dadurch ändern, wird dringend empfohlen, diese Perioden zu sperren, sofern die Konzernabschlüsse nicht gesperrt wurden. Voraussetzung dafür ist die Aktivierung der Objektberechtigung für Perioden für alle Benutzer.
Der Status für Sperren der Konzernabschlüsse wird jetzt durch neue Symbole (s.o.) angezeigt.
Beim Löschen von Belegen zur Schuldenkonsolidierung (SK) durch Änderungen des zugehörigen Konsolidierungsparameters oder Löschen einer Zeile in der IC-Clearing-Übersicht (KGESGES) werden jetzt auch die zugehörigen Belege zur Spiegelumbuchung mitgelöscht und der Status 'SU' wird auf [rot] gesetzt.
Die Schulden- und Aufwands-/Ertragskonsolidierung bei Schalterstellung "Behandlung TW-Differenz als Sachdifferenz" im jeweiligen Konsolidierungsparameter wurde dahingehend modifiziert, dass die aus den TW-Differenzen berechneten Sachdifferenzen nicht mehr je Transaktionswährung, sondern je Gesellschaft gebucht werden. Da auch die bisherige Unterteilung in Soll- und Haben-Werte je Gesellschaft beibehalten wird, ergeben sich bis zu 4 Buchungen für eine Sachdifferenz. Die bisherige Aufteilung auf Buchungssätze je Transaktionswährung entfällt.
Werden bei diesem Verfahren IC-Salden ohne TW-Angaben gemeldet, so wird einfach die Konzernwährung als Transaktionswährung verwendet.
Außerdem entfällt der bisherige Vergleich der TW-Differenzen mit dem TW-Schwellenwert. Daher wird bei der Pflege des Konsolidierungsparameters jetzt geprüft, dass bei Schalterstellung "Behandlung TW-Differenz als Sachdifferenz" kein TW-Schwellenwert angegeben sein darf.
Die Schulden- und Aufwands-/Ertragskonsolidierung bei Schalterstellung "Behandlung TW-Differenz als Sachdifferenz" im jeweiligen Konsolidierungsparameter führt eine Umrechnung der Transaktionswährungswerte in die Konzernwährung durch. Dazu werden die Einstellungen in den Währungsumrechnungs-Kopfsätzen (WUM) der beiden Gesellschaften verwendet. Handelt es sich aber um zwei Konzernwährungsgesellschaften, sind evtl. gar keine WUM-Kopfsätze definiert. Bisher erfolgte in diesem Fall eine Umrechnung aller Werte zum Stichtagskurs ('SK'). Dies wurde dahingehend geändert, dass die Umrechnung von GuV-Daten jetzt zum Periodendurchschnittskurs ('PDK') erfolgt, da dies in der Praxis weitaus häufiger der Fall ist.
In der Formularerfassung der Erstkonsolidierung (I-ERSTKON) wurden die Zeilen "Unterschiedsbetrag" und "Fremdanteil" zusammengefasst und in "Summe" umbenannt.
Weiterhin wird jetzt unterstützt, dass es mehrere Konsolidierungsbuchungen auf demselben Konto mit demselben Buchungsschlüssel gibt. Diese können erfasst werden, werden dann auch getrennt gespeichert und bei erneutem Aufruf getrennt angezeigt und sind einzeln änderbar. Für eine Abstimmung über die Spalte "Restwert" müssen dann allerdings mehrere Zeilen gemeinsam bewertet werden.
Die Konsolidierungsverarbeitung 'AO' wird nicht mehr zur Erfassung neuer Belege zugelassen. Alternativ stehen die Konsolidierungsverarbeitungen 'MB' sowie 'M0' bis 'M9' zur Verfügung.
Der Status für Sperren der Konsolidierungsbelege wird jetzt durch neue Symbole (s.o.) angezeigt.
Beim Sperren und Entsperren eines Konsolidierungsbelegs werden die Angaben für die letzte Änderung (Benutzer, Datum, Uhrzeit) nicht mehr überschrieben, da die Angaben, wer eine Sperre wann gesetzt oder zurückgesetzt hat, unabhängig davon in eigenen Spalten festgehalten werden.
Für ergebniswirksame Konsolidierungsbelege werden jetzt automatisch zusätzliche Konsolidierungsbuchungen in Höhe der Ergebniswirksamkeit auf dem Ergebniskonto (mit Kontokennzeichen 'E') erzeugt. Es wird eine Konsolidierungsbuchung je Buchungssatz, je Gesellschaft sowie ggf. je Geschäftsbereich erzeugt. Diese Konsolidierungsbuchungen werden nicht in die Berechnung der Soll/Haben-Gleichheit und der Ergebniswirksamkeit eingerechnet. Sie werden auch nicht in die Berechnung der Prüfsumme des Konsolidierungsbelegs einbezogen.
Die Übersicht KONBUCH bezieht diese Konsolidierungsbuchungen nicht in die berechneten Summen mit ein. Das gilt auch für die Anzeige offener Differenzen in der Einzelsatzanwendung KONBUCHE. Eine manuelle Bearbeitung dieser Konsolidierungsbuchungen ist nicht möglich (keine Verzweigung in den Einzelsatz). Auch die Formularerfassung I-KONBUCH zeigt die neuen Konsolidierungsbuchungen zwar an, sie dürfen dort aber nicht geändert werden und ihre Beträge fließen auch nicht in die angezeigten Summen ein.
Ist das Ergebniskonto einem Kapitalspiegel zugeordnet, so werden die neuen Konsolidierungsbuchungen mit dem Buchungsschlüssel mit dem Verwendungskennzeichen 'JU' versehen. Ist das Konto einem anderen Spiegel zugeordnet, so wird der Buchungsschlüssel für Änderungen in der laufenden Periode (Verwendungskennzeichen 'L' oder 'N') verwendet.
Die Erzeugung dieser zusätzlichen Konsolidierungsbuchungen erfolgt bei jeder Verprobung der Konsolidierungsbelege, also bei Anzeige der Konsolidierungsbuchungen sowie bei jeder Änderung. Diese Konsolidierungsbuchungen werden aber nicht für gesperrte Perioden, gesperrte Konzernabschlüsse und gesperrte Konsolidierungsbelege erzeugt.
Die neuen Konsolidierungsbuchungen ersetzen die wesentliche Funktion der bisherigen Anwendung "Konzernergebnisverrechnung" ('JU'). Daher werden die Konsolidierungsbuchungen auf dem Ergebniskonto nicht erzeugt, wenn es bereits einen 'JU'-Beleg gibt. Die "Konzernergebnisverrechnung" wird nur noch dann benötigt, wenn dort die Konten für "Verrechnung Bilanz" und "Verrechnung GuV" angegeben sind. Die Funktion für das "Konto für Jahresergebnis" kann dagegen nicht mehr ausgelöst werden.
Beim Import von Konsolidierungsbuchungen (z.B. nach Export aus einer anderen IDL.KONSIS.FORECAST-Installation) werden Konsolidierungsbuchungen auf dem Ergebniskonto ignoriert, ohne dass dies gemeldet wird. Diese Konsolidierungsbuchungen werden aber durch die anschließende Verprobung wieder neu erzeugt. Dementsprechend können diese Konsolidierungsbuchungen auch nicht zur Berechnung von Fremdanteilen oder latenten Steuern markiert werden.
In diversen Verarbeitungen (Vortrag in die nächste Periode, Währungsumrechnung, Kopieren auf reporttechnischen Teilkonzern sowie alle Konsolidierungsverarbeitungen, die auf anderen Konsolidierungsbuchungen basieren) werden diese Konsolidierungsbuchungen auf dem Ergebniskonto ebenfalls ignoriert, so dass die erzeugten Konsolidierungsbelege gleich bleiben. Vielmehr werden diese Konsolidierungsbuchungen bei der anschließenden Verprobung immer wieder neu erzeugt.
Die Programme zur Erstellung von Reports wurden nicht geändert, da das Ergebniskonto entweder gar nicht direkt im Report enthalten ist oder die Berücksichtigung der Konsolidierungsbuchungen auf dem Ergebniskonto genau zum korrekten Ergebnis führt. Weiterer Vorteil dieser Buchungen auf dem Ergebniskonto ist die Möglichkeit der Vortragsabstimmung und anderer Konsistenzprüfungen mit Hilfe von Prüfregeln.
Aus technischen Gründen kann die Konvertierung von IDL.FORECAST-Daten vorerst nicht im Rahmen allgemeinen Release-Konvertierung erfolgen. Die Konvertierung muss daher für IDL.FORECAST-Daten separat gestartet werden. Dazu dient ein neuer Eintrag im Aktionsmenü der Anwendung "Planungsformular" (PLAN).
Das Öffnen eines nicht konvertierten Szenarios wird mit einer entsprechenden Fehlermeldung verhindert.
Auch die Werte in Summenspalten (Quartale, Jahre) sind jetzt änderbar. Eine Änderung wird automatisch auf die zugehörigen Monate verteilt, entweder proportional im Verhältnis der bestehenden Werte oder gleichverteilt, falls noch keine Werte vorlagen.
Die Änderung eines Kontensaldos wird jetzt innerhalb einer Zelle proportional (bisher gleichverteilt) zu den bereits bestehenden Werten auf die Veränderungen verteilt.
Wurde eine manuelle Veränderung an eine Zelle gehängt, dann wird diese Zelle jetzt durch ein Symbol (Hand) gekennzeichnet. Dies ist auch dann der Fall, wenn die Summe aller manuellen Veränderungen 0,00 ist. Hat man dagegen einen Anfangsbestand und eine automatische Veränderung, die in der Summe 0,00 ergeben, dann wird dies an der Oberfläche mit einem grünen Punkt visualisiert. Der Punkt zeigt an, dass im T-Konto mindestens eine automatische Veränderung vorhanden ist, also das T-Konto nicht leer ist.
Für markierte Zellen können jetzt alle automatischen Veränderungen in manuelle Veränderungen umgewandelt werden. Das kann vor allem dann interessant sein, wenn die automatischen Veränderungen nicht automatisch verrechnet werden sollen. Nach Markierung der Zellen ist dazu das Symbol mit der Roboterhand zu betätigen. Dadurch werden alle automatischen Veränderungen der gewählten Zellen umgewandelt. Waren Positionen selektiert, dann erfolgt die Umwandlung auch für alle untergeordneten Konten. Im Dialog wird ein Text für die manuelle Veränderung abgefragt. Die umgewandelten automatischen Veränderungen sind dann manuelle Veränderungen mit dem neuen Text.
Um selektierte Zellen von manuellen Buchungen zu befreien, wurde eine neue Aktion "Buchung löschen" zur Verfügung gestellt. Analog gibt es eine Aktion "Kontoveränderung löschen", die die Kontoveränderungen aus den markierten Zellen löscht.
Über einen Knopf in der Titelleiste des Tabellenbereichs kann jetzt gesteuert werden, ob die Regel-Symbole in der Tabelle angezeigt werden sollen, da der Tabellenbereich bei sehr vielen Regeln in einem Szenario leicht unübersichtlich wird.
Es erfolgt jetzt eine Prüfung auf Gleichheit des Jahresergebnisses von Bilanz und GuV auch für die erfassten Planzahlen. Differenzen werden wie in der Übersicht "Kontensalden" (KTOSAL) in einem Abstimmblock am Ende der Tabelle angezeigt.
Ist ein Konto per Soll/Haben-Steuerung (Angabe in den Positions-Konten-Zuordnungen POSKTO) zwei Positionen zugeordnet, so wird es jetzt im Planungsformular auch zweimal angezeigt. Der Saldo wird aber in Abhängigkeit des S/H-Kennzeichens nur in einer von beiden Zellen angezeigt. In der anderen Zelle wird kein Wert angezeigt, aber ein Symbol, welches darauf hinweist, dass es sich hierbei um eine Soll-/Haben-Steuerung handelt.
Das Aktualisieren der Daten durch Übernahme von Kontensalden aus IDL.KONSIS.FORECAST kann jetzt differenziert erfolgen. Dazu wurde eine Aktualisierungsfunktion geschaffen, die sowohl im Aktions-Menü als auch im Kontextmenü enthalten ist und lediglich die selektierten Bereiche aktualisiert. Daneben gibt es eine Aktualisierungsfunktion, die alle übrigen aus dem Aktions-Menü ersetzt. Damit werden nicht mehr die einzelnen Bereiche (IST, FORECAST, PLAN) aktualisiert, sondern über einen Dialog die Perioden für die jeweiligen Szenarien abgefragt.
Das Speichern eines Szenarios wurde vom Speichern der Kontensalden getrennt. Dazu wird im Selektionsbereich ein neuer Button "Kontensalden schreiben" erstellt, der das Speichern der Kontensalden und des Szenarios übernimmt. Der alte Button "Speichern" speichert nur das Szenario ohne Schreiben der Kontensalden.
Es ist jetzt möglich, eine Planung auf der Ebene der Controllingobjekte durchzuführen. Dazu gibt es nach dem Laden eines Szenarios im Selektionsbereich eine zweite Registerkarte "Controlling-Filter". Dort können für die definierten Controllingdimensionen einzelne Controllingobjekte spezifziert werden.
Ist für jede Dimension eine Ausprägung gewählt worden, dann wird die Tabelle nach Klicken auf <Anwenden> ausgetauscht. Man sieht nur noch die Controllingsalden für die gewählte Ausprägung. Tippt man Zahlen ein oder ändert diese, dann wird die Änderung in einem parallelen T-Konto (weiteres Panel) angezeigt.
Controllingdimensionen müssen nicht vollständig ausgewählt werden. Wählt man Controllingobjekte nur für eine Teilmenge von Controllingdimensionen aus, dann wird die Summe über alle Ausprägungen in der Tabelle angezeigt.
Erfolgt die Planung auf der Ebene von Controllingobjekten, können die IDL.KONSIS.FORECAST-Controllingsalden analog zu den Kontensalden erzeugt, aktualisiert oder auch eingelesen werden.
In der Szenario-Verwaltung wird jetzt zusätzlich auch der Ersteller eines Szenarios angezeigt.
Es ist jetzt möglich, ein Szenario zu schließen, ohne die Anwendung "Planungsformular" (PLAN) zu beenden.
Der Aufruf von Folgeanwendungen (z.B. Kontensalden, Einzelabschluss-Monitor) ist jetzt nur noch möglich, wenn das Szenario keine ungespeicherten Daten enthält. Ansonsten bestünde die Gefahr, dass die jeweilige Registerkarte geschlossen wird, ohne in das Planungsformular zurückzukehren, wodurch dann alle ungespeicherten Änderungen verloren wären.
Die Bezeichnungen von Schaltflächen in den Assistenten zur Definition von Regeln wurden überarbeitet, um deren Funktion klarer zu beschreiben:
Außerdem werden "Regel-Templates" jetzt als "Regel-Vorlagen" bezeichnet.
Die Sortierung der Anzeige der Regel-Vorlagen kann jetzt vom Benutzer eingestellt werden. Möglich ist eine Sortierung nach Änderungsdatum (wie bisher), nach Regeltyp und alphabetisch nach Regelnamen.
Bei Übernahme von Regeln aus einem Set von Regel-Vorlagen übernehmen diese Regeln auch den Namen der Vorlage.
Bei Anwendung eines Sets von Regel-Vorlagen wird jetzt eine Fortschrittsanzeige ausgegeben, da dieser Schritt ggf. auch länger dauern kann.
Die Größen der Seiten eines Assistenten wurden vereinheitlicht, damit die Schaltflächen immer an derselben Stelle des Bildschirms stehen.
Im Assistenten für Investitionsregeln sind jetzt für das Zahlungskonto Passivkonten genauso zugelassen wie Aktivkonten.
Für die Regeltypen Material-, Personal-, Rückstellungs- und Bezugswertregel wurde die Eingabe eines negativen Bezugswertfaktors ausgeschlossen, da dies fachlich keinen Sinn ergibt.
Geschäftsfälle erhalten jetzt neben der Bezeichnung auch eine eindeutige Nummer. Diese Nummer wird in der Geschäftsfallanzeige hinter jedem Geschäftsfall angezeigt.
Beim Löschen einer Regel erschien bisher ein Dialog "Regel wirklich löschen? Ja/Nein". Dieser Dialog wurde erweitert zu "Auch Werte der Regel löschen? Ja/Nein/Abbrechen". Durch <Nein> werden die Werte der Regel auf den referenzierten Konten in eine automatische Veränderung übernommen. Bei <Ja> verhält sich das Löschen wie bisher. Bei <Abbrechen> wird nicht gelöscht.
Wenn Regeln aus einer Regel-Vorlage übernommen werden, dann kann jetzt (wie auch bisher schon bei der Definition der Regeln im jeweiligen Assistenten) gesteuert werden, dass die Regeln nur auf bestimmte Perioden (nur Plan, nur Forecast) angewandt werden sollen.
Regeln werden jetzt zur eindeutigen Identifizierung auch durch eine laufende Nummer gekennzeichnet. Bitte beachten Sie, dass unterschiedliche Nummern vergeben werden, wenn die Regel auf mehrere Konten oder mehrere Perioden angewandt wird.
Die Angaben in einer T-Konto-Darstellung können jetzt markiert, kopiert und in eine andere Anwendung (z.B. MS Excel) eingefügt werden.
Eine neue Geschäftsfallanzeige ermöglicht es, die Zusammenhänge der Veränderungen und Regeln innerhalb eines Geschäftsfalls darzustellen. Die Konto-Anzeige zeigt dazu jetzt zusätzlich an, zu welcher Buchung bzw. zu welchem Geschäftsfall eine Veränderung gehört. Wenn man mit der Maus auf den Geschäftsfall-Namen drückt, wird jetzt in der Geschäftsfall-Ansicht der komplette Geschäftsfall angezeigt. Für jede Buchung und jeden Geschäftsfall wird zur Identifikation eine eindeutige Nummer angezeigt. Alle Veränderungen, die zu einem Geschäftsfall gehören, werden gruppiert angezeigt.
Der Detailbereich der Geschäftsfallanzeige ist in drei Registerkarten "Übersicht", "Buchungen" und "Tabelle" aufgeteilt. In der Karte "Übersicht" werden allgemeine Informationen angezeigt. Die Karte "Buchungen" zeigt alle Buchungen, die direkt etwas mit dem Geschäftsfall zu tun haben. Die Karte "Tabelle" zeigt alle wichtigen Zahlen der Regel in Tabellen-Form.
In der Regel- und der Geschäftsfallanzeige wird jetzt grundsätzlich die Kontonummer zusätzlich zur Konto-Bezeichnung angezeigt.
Bei der Pflege der Reportzeilenbeschreibungen wird der Reporttyp 'Q' (Mehrperioden-Kapitalflussreport) jetzt genauso wie der Reporttyp 'F' (normaler Kapitalflussreport) behandelt. Für einen Mehrperiodenreport können daher eigene Reportzeilenbeschreibungen angelegt werden, ohne auf einen einfachen Kapitalflussreport verweisen zu müssen.
Das Wertkennzeichen '-' (negierte Wertebildung gemäß POSKTO) war für die Kapitalflussrechnung eingeführt worden, um Differenzen berechnen zu können (z.B. Saldo - Vortrag = laufende Änderung). Dieses Wertkennzeichen in den Reportzeilenbeschreibungen (REPZEI) steht jetzt allen Reporttypen zur Verfügung. Die einzelnen Konten einer Position werden wie gewohnt saldiert, aber mit dem umgekehrten Vorzeichen ausgewiesen. Diese Vorzeichenumkehr wirkt dann auch in die Summierung auf übergeordnete Positionen.
Zur differenzierteren Steuerung von Controllingreports wurde die Tabelle der Report-Kopfsätze um ein Attribut für die Controllingdimension erweitert.
Zur Unterstützung von Reports für Verdichtungen von Controllingobjekten und Geschäftsbereichen wurde die Tabelle der Report-Kopfsätze um Attribute für ein Controllingobjekt, einen Geschäftsbereich und eine Hierarchieebene erweitert.
Der Status für Sperren der Reports wird jetzt durch neue Symbole (s.o.) angezeigt.
Controllingreports auf Gesellschafts- und Konzernebene können jetzt für alle definierten Controllingdimensionen (CDM) erstellt werden. Zur Steuerung wurde der Report-Kopfsatz um einen Parameter für die Controllingdimension erweitert, in dem für Controllingreports ein Wert zwischen 'CD01' und 'CD10' angegeben werden kann. Bei der Reporterstellung werden dann alle Konten, die einen Aufriss gemäß dieser Controllingdimension führen (Angabe im Kontenstamm KTO) nach den zugehörigen Controllingobjekten aufgerissen. Alle übrigen Controllingdimensionen werden nicht berücksichtigt.
Ohne Angabe einer Controllingdimension wird jedes Konto wie bisher nach Controllingobjekten der ersten für dieses Konto zugeordneten Controllingdimension aufgerissen. Dies können dann unterschiedliche Controllingdimensionen sein.
Ein gleichzeitiger Aufriss nach mehreren Controllingdimensionen ist nicht möglich. Der Controllingsalden-Herkunftsreport wird weiterhin nur in Bezug auf die erste Controllingdimension unterstützt.
Für Controllingobjekte und Geschäftsbereiche können schon seit dem Release 2008.0 Hierarchien (Verdichtungsstufen) definiert werden. Diese Hierarchien können jetzt auch in Reports, die Controllingobjekte bzw. Geschäftsbereiche als Aufrissstufe enthalten, ausgewertet werden. Dazu sind im Report-Kopfsatz (REP) der oberste Knoten (Hierarchie-Aggregat) und eine Ebene zu spezifizieren:
Eine Darstellung der kompletten Hierarchie im Report ist vorerst aus technischen Gründen nicht möglich.
Die neue Reportoption 'F' sorgt dafür, dass für einen Konzern-Spiegelreport der Anteil der Konsolidierungsbuchungen nach Konsolidierungsverarbeitung aufgeschlüsselt wird. Die Konsolidierungsverarbeitungen stehen in alphabetischer Reihenfolge auf einer Ebene neben dem Anteil des Einzelabschlusses (Schlüssel 'G'). Für andere Reports kann die Reportoption 'F' nicht angegeben werden. Dies gilt auch für den Konzernanlagenspiegel, bei dem die entsprechende Aufrissebene durch den Schlüssel Anlagenobjekt belegt ist.
Die Aufteilung nach Konsolidierungsverarbeitungen erfolgt gemäß der KVA-Angabe in den jeweiligen Konsolidierungsbelegköpfen. Für eines der nächsten Releases ist aber geplant, hierfür eine individuelle Gliederung der Konsolidierungsverarbeitungen für Reportzwecke zu ermöglichen.
Die Verzweigung in die Restwertanalyse-Ansicht der IC-Kontensalden wird jetzt auch für Konten mit dem Kontokennzeichen 'J' unterstützt.
Unter dem Schlüssel "#HB1/2" steht jetzt eine neue Standard-Spaltenoption für Überleitungsreports mit Spalten für HB I-Abschluss, HB I-Buchungen, HB II-Abschluss, Konsolidierungsbuchungen und Konzernabschluss zur Verfügung.
In der Funktion "Verdichten Teilkonzern auf Einzelabschluss" resultieren Kontensalden mit Differenzen im Ergebnis zwischen Bilanz und GuV, wenn mit Geschäftsbereichen gearbeitet wird und es segmentübergreifende Buchungen gibt. Dieses Problem kann dadurch gelöst werden, dass in der Gesellschafts/Geschäftsbereichs-Zuordnung (GESUBR) die Kontengruppe 'M' angegeben wird. Dann werden diese Differenzen auf dem Ausgleichskonto mit dem Kontokennzeichen 'U' ausgeglichen. Daher werden neu erzeugte GESUBR-Sätze für die Ziel-Gesellschaft von dieser Funktion jetzt gleich mit der Kontengruppe 'M' versehen.
In dieser Anwendung wurde zusätzlich die Prüfung ergänzt, ob die verarbeiteten Konsolidierungsbelege Soll/Haben-Gleichheit aufweisen. Ist dies für mindestens einen Beleg nicht der Fall, wird ein Meldungsfenster ausgegeben, in dem alle unstimmigen Belege angezeigt werden. Der Anwender kann dann entscheiden, ob die Verarbeitung fortgesetzt oder abgebrochen werden soll. Auch hier würde ein Einzelabschluss mit unterschiedlichen Ergebnissen für Bilanz und GuV resultieren.
In Menüpunkten mit externen Aufrufen (MEN) kann jetzt neu der Parameter '%UI' angegeben werden. Dieser wird beim Ausführen des Aufrufs durch die aktuelle, maximal 8-stellige Benutzer-Id ersetzt, die in IDL.KONSIS.FORECAST u.a. als Eintrag des Änderungs-Benutzers verwendet wird.
Diese Erweiterung betrifft i.w. individuelle Menüpunkte, die in Automatensteuerungen eingesetzt werden, und die Menüpunkte "UNL...", die per Aktion "Auslesen Daten aus Fremdsystem" aus der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) aufgerufen werden können. In dem aufgerufenen Prozess kann dieser Parameter z.B. dazu benutzt werden, um eine Job-Id für ein nachfolgendes Schreiben in die Importtabellen (I1xx) zu ermitteln.
Bei Aufruf einer der Folgeanwendungen zum Auslesen von Kontensalden (UNLSALD), IC-Kontensalden (UNLICKTOS, UNLICKONV) und Controllingsalden (UNLCNTSAL) wird jetzt die Warnung "Sie lesen jetzt alle Gesellschaften aus" ausgegeben, wenn die Eingabefelder Gesellschaft und Geschäftsjahresvariante beide leer sind.
Die Masken der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) und der Übersicht "IE Job-Steuerungen" (IEJOB) wurden um ein Eingabefeld für die Spiegel-Id erweitert. Ein hier eingegebener Wert wird insbesondere beim Aufruf des Entladens von Spiegelbewegungen aus einem Fremdsystem und der Übersichtsanzeige für Spiegelbewegungen weitergegeben.
Die SAP-Schnittstelle (kcusap.jar) wurde dahingehend erweitert, dass dieser Parameter ausgewertet wird, so dass gesteuert über diesen Parameter Daten für unterschiedliche Spiegel ausgelesen werden können.
Eine neue Importanwendung TXTIEF ermöglicht den Import von Import/Export-Definitionen, die z.B. aus einer Test-Datenbank exportiert wurden. Die Formatbeschreibungen können Sie den Übersichten "Felder für Import/Export-Formate" (IEFDEF) und "Zuordnung Import-Felder zu Formaten" (IEFFEL) entnehmen. Die neue Importanwendung kann sowohl aus der allgemeinen Import-Aufrufanwendung IMPORT als auch aus der speziellen Anwendung IARIMP (nur für autorisierte Benutzer) aufgerufen werden.
Die Bezeichnungen der Schlüssel wurden von bisher "Objekt-ID" und "Herkunfts-Objekt-ID" auf "interne Objekt-ID" und "externe Objekt-ID" umbenannt. Die Begriffe "Herkunft" und "Ziel" waren missverständlich, wenn die Umsetzgruppe auch für den Export benutzt wurde.
Die Tabelle IEJOB zur Steuerung des Imports und Exports über spezielle Datenbanktabellen anstelle von TXT-Dateien wurde um zwei Attribute erweitert:
Zwei zusätzliche Spalten der Übersicht zeigen die Importtabelle, in der die zu importierenden Daten stehen, und die Anzahl der Sätze dort an.
Die Übersicht analysiert außerdem die für die angezeigten Jobs gespeicherten Daten nach Eindeutigkeit der für den jeweiligen Objekttyp relevanten Schlüssel. Eindeutige Schlüssel werden in der Übersicht IEJOB in entsprechenden Spalten (Periode, Datenart, Gesellschaft, Kontenplan, Positionsplan) angezeigt und erleichtern so die Orientierung, welcher Job welche Daten beinhaltet.
Zusätzlich wurde eine Übersicht "IE Tabellendaten" geschaffen, mit der die Inhalte der zu importierenden Daten eines Jobs angezeigt werden können. Der Aufruf dieser Übersicht aus IEJOB erfolgt durch Markieren der Zeile eines Jobs und Auswahl aus dem Aktions- oder Objektmenü (rechte Maustaste) oder durch Doppelklick auf die Spalte mit der Anzahl der Zeilen. Aus dieser neuen Übersicht kann wiederum in die Import-Protokoll-Anzeige verzweigt werden.
Hinweis, falls mit Umsetzgruppen gearbeitet wird: In den DB-Tabellen stehen noch die Originaldaten (externe Objekt-Id) und werden von der Übersicht "IE Tabellendaten" auch so angezeigt. Die IDL.KONSIS.FORECAST-Schlüssel können nur über die Umsetzgruppen-Zuordnungen (UMSOBJ) ermittelt werden.
Beim Starten der Funktion "Löschen + Neuladen Teilkonzerndaten" erfolgt jetzt eine Sicherheitsabfrage, ob das Löschen wirklich erfolgen soll. Diese Sicherheitsabfrage nennt auch das Datum der gefundenen Protokolldatei vom Entladen der Daten. Dadurch kann sichergestellt werden, dass kein veralteter Datenbestand neu eingespielt wird.
Um die Gefahr zu verringern, dass versehentlich verkehrte Daten geladen werden, wird jetzt der Name der Datenbank, aus der die Daten entladen wurden, in die Entlade- und in die Lade-Protokolldatei geschrieben. Der Datenbankname wird auch in der Sicherheitsabfrage vor dem Löschen und Neu-Laden von Teilkonzerndaten angezeigt.
Bei Fremdschlüsselverletzungen bricht die Verarbeitung jetzt nicht mehr sofort ab, sondern arbeitet bis zum Ende der Daten der jeweiligen Tabelle weiter und gibt dann die gesammelten Meldungen aus. Die Meldungen geben jetzt auch explizit den fehlenden Fremdschlüssel an. So können systematisch fehlende Daten leichter identifiziert und der Fehler schneller behoben werden.
Um die Gefahr zu verringern, dass versehentlich verkehrte Daten geladen werden, wird jetzt der Name der Datenbank, aus der die Daten entladen wurden, in die Entlade- und in die Lade-Protokolldatei geschrieben.
Ist ein Konzernkonto in seiner Gültigkeit begrenzt, so wird die Gültigkeitsangabe ggf. an alle zugeordneten Gesellschaftskonten weitergegeben.
Der Datenzugriff durch die KONDAT-Programme kann für nummerische Felder nicht zwischen Nullwerten und leeren Inhalten unterscheiden. Da diese Unterscheidung aber wesentlich für IDL.FORECAST-Daten ist, waren die von KONDAT geschriebenen Daten nicht kompatibel. Die enthaltenen Szenarien ließen sich nicht mehr öffnen. Da eine kurzfristige Behebung des Problems nicht möglich war, mussten diese Funktionen vorerst aus dem Menü der Aufrufanwendung "Konzern-Teilkonzern-Datenaustausch" (KONDAT) herausgenommen werden.
Der Aufruf der Funktion "Export Teilkonzern Salden und Aufrisse komplett" wurde in der Aufrufanwendung "Konzern-Teilkonzern-Datenaustausch" (KONDAT) reaktiviert, ohne dass das Export-Format geändert wurde. Vielmehr werden die ausgelesenen Daten auf dieses Format gekürzt, d.h. der Spiegelschlüssel wird auf eine Stelle, die Buchungsschlüssel-Nummer auf zwei Stellen gekürzt. Kunden, die diese Schnittstelle nutzen, sollten daher entsprechende Erweiterungen ihrer Spiegeldefinitionen vermeiden.
In der Lesefunktion des Konzernabschluss wurde die Funktionalität der IC-KONTENSALDEN erweitert. Es können für den angegebenen Konzern, Teilkonzern oder reporttechnischen Teilkonzern die IC-Daten des Summenabschlusses, der Konsolidierungsbuchungen bzw. des Konzernabschlusses ausgelesen werden.
SAP-Schnittstelle mit IDL.IMPORTER
Der in der Aufrufanwendung IMPORT ergänzte Parameter "Spiegel-Id" kann jetzt auch in der SAP-Schnittstelle dazu ausgewertet werden, Daten für spezielle Spiegel auszulesen.
Zur Unterstützung der Anzeige der Daten mit dem Werkzeug Power OLAP von PARIS Technologies wurde eine Reihe von Sichten auf die Datenbank definiert, mit deren Hilfe die Daten ohne separat anzustoßende Bereitstellungsfunktion zur Verfügung gestellt werden. Für diese Funktion benötigen Sie zusätzliche Lizenzen.
Mit diesem Release werden folgende deutschsprachigen Dokumentationen im doku-Verzeichnis aktualisiert oder ergänzt: