Das Release IDL KONSIS 2007.0 (analog IDL Winkons 2007.0, PP Consis 2007.0 und CS.KON 2007.0) ist ein Hauptrelease und darf daher in der Releasefolge nicht ausgelassen werden. Mindestvoraussetzung zur Installation dieses Releases ist das letzte Hauptrelease 2006.0 vom 17. 9. 2006.
Die Erweiterungen des Zwischenreleases IDL KONSIS 2006.1 (bzw. IDL WinKons 2006.1, PP Consis 2006.1, CS-KON 2006.1) sowie die bis zum Release-Abschluss erfolgten Nachträge und Korrekturen zu diesen Releases sind im Hauptrelease 2007.0 enthalten.
Diese Dokumentation beschreibt die Erweiterungen seit dem letzten Zwischenrelease IDL KONSIS 2006.1 (bzw. IDL WinKons 2006.1, PP Consis 2006.1, CS-KON 2006.1). Sofern dieses Zwischenrelease noch nicht zuvor installiert war, wird empfohlen sich auch über die Erweiterungen im Zwischenrelease 2006.1 zu informieren.
Wegen der mit Release 2006.1 geänderten Prämissen für die Entkonsolidierung (es muss eine Bilanz für die abgehende Gesellschaft vorliegen, die dann auch in den Konzern-Report einbezogen wird), führen Konzern-Spiegelreports sowie Kapitalflussrechnungs-Reports, die abgehende Gesellschaften enthalten, nicht mehr zum selben Ergebnis wie in vorangegangenen Releases. In diesen Fällen sollten Konzern-Reports nur für Perioden neu erstellt werden, in denen auch die Entkonsolidierung mindestens mit dem Release 2006.1 erfolgt ist.
D.h. es sollten keine Konzern-Spiegel- und Kapitalfluss-Reports für abgeschlossene Perioden neu erstellt werden, wenn diese abgehende Gesellschaften enthalten. Auf Bilanz- und GuV-Reports hat diese Änderung dagegen keinen Einfluss, da die Kontensalden von abgehenden Gesellschaften (Eintrag Abgangsdatum in KTKGES) auch vorher schon in den Konzern-Reports berücksichtigt wurden.
Die Entwicklungsplanung sieht vor, dass Konzernbewegungen (Anlagen, Kapital und Rückstellungen) mit dem nächsten Hauptrelease 2008.0 nicht mehr unterstützt werden. Dieser Datenbestand ist redundant zu den Konsolidierungsbuchungen und enthält keine zusätzlichen Informationen. Bisher bestehende Unterschiede beim Konzernvortrag werden durch die in diesem Release erfolgten Änderungen aufgehoben (s.u.). Die Anwender werden daher aufgefordert
Aufgrund diverser Erweiterungen (u.a. Unicode, Controlling) wurden verschiedene Import/Export-Formate erweitert oder Feldlängen geändert. Bitte überprüfen Sie Ihre individuellen Import/Export-Formate (IEFFEL), ob sie noch kompatibel zu den aktuellen Definitionen (IEFDEF) sind.
Im Zusammenhang mit der Erweiterung des Controlling-Bausteins (s.u.) wurde der Menüpunkt zum Entladen von Controllingsalden aus einem Fremdsystem von "UNLKSTSAL" auf "UNLCNTSAL" umbenannt. Wer diesen Menüpunkt nutzt und dort einen kundenspezifischen externen Aufruf hinterlegt hat, muss diesen externen Aufruf auf den neuen Menüpunkt kopieren.
Desweiteren wurde der Datenbestand für Import/Export-Formate für Controllingsalden von "KSTSAL" auf "CNTSAL" umbenannt. Wer zu diesem Datenbestand individuelle Import/Export-Formate definiert hat, muss diese auf den neuen Datenbestand kopieren. Die Feld-IDs für die neuen Formate müssen den Prefix "K041-" anstelle des alten Prefix "K064-" haben.
Der IDL Connector unterstützt - wie bereits seit über einem Jahr avisiert - die Version MS Excel 97 seit dem Hauptrelease 2006.0 nicht mehr, zumal auch der Hotline-Service für MS Excel 97 durch Microsoft inzwischen eingestellt wurde. Bitte rüsten Sie daher auf eine aktuellere Excel-Version auf.
Mit diesem Hauptrelease 2007.0 wird der frühere Application Server (einzige Variante bis zum Release 5.3.1) nicht mehr unterstützt, sondern nur noch der neue Application Server (verfügbar seit dem Release 5.4.0, seit Release 5.4.1 die Standardlösung). Stellen Sie daher bitte auf den neuen Application Server um, wenn Sie noch den alten im Einsatz haben.
Seit Längerem besteht die Anforderung, Berichtsdaten mit ausführlicheren Texten zu dokumentieren, als dies die bisherigen Bemerkungs- und Buchungstexte (maximal 35 Zeichen) zulassen. Es lässt sich aber keine vernünftige Obergrenze für eine derartige Betextung festlegen. Daher wurde jetzt eingebaut, dass neben dem Bemerkungs- oder Buchungstext eine beliebig lange Beschreibung hinterlegt werden kann.
Diese Beschreibung erfolgt analog zu den Hilfetexten, die zu Stammdaten (z.B. Konten, Positionen) hinterlegt werden können. Im Gegensatz zu den meisten Stammdaten werden diese Texte aber nicht sprachabhängig gespeichert. D.h. es gibt maximal eine Beschreibung je Datensatz.
Diese Erweiterung betrifft folgende Daten:
In den Aktionsmenüs der zugehörigen Übersichten und Einzelsatzanwendungen wurden die Aktionen <Hilfetext anzeigen> und <Hilfetext editieren> ergänzt.
Bitte beachten Sie, dass diese Texte für maschinell erzeugte Daten bei Wiederholung der maschinellen Anwendung wie z.B beim Konzernvortrag nicht erhalten bleiben, sondern neu erfasst werden müssen.
Mit dem vorliegenden Release 2007.0 steht ein Verfahren zur Auszifferung von IC-Kontensalden zur Verfügung. Ausziffern bedeutet, dass manuell oder maschinell Paare oder größere Gruppen von IC-Kontensalden zwischen zwei Gesellschaften markiert werden können, dass sie korrespondierende Sachverhalte darstellen. Auf diese Weise wird die Ermittlung von IC-Kontensalden, die ohne korrespondierenden Sachverhalt bei der IC-Gesellschaft gemeldet wurden, vereinfacht.
Tabellenerweiterungen
Die Datenbanktabelle für IC-Kontensalden wurde um drei Attribute erweitert:
Die beiden Attribute "Referenzbeleg-Nummer" und "Referenzbeleg-Datum" können in der Einzelsatzanwendung (ICKTOSALE) und in der Formularerfassung (I-ICKTOSAL) erfasst werden. Die Importanwendungen (TXTICSALD, TXTICKONV) ermöglichen die Übernahme aller drei neuen Attribute, wobei das Kennzeichen für maschinelle Auszifferung (s.u.) nicht akzeptiert wird.
Manuelle Auszifferung
Die manuelle Auszifferung von IC-Kontensalden erfolgt über die Aktion <Mengenändern>. Nach Markieren der auszuziffernden IC-Kontensalden ist im Dialogfenster eine Auszifferungsnummer zwischen '02' und '99' anzugeben.
Die manuelle Auszifferung erfolgt sinnvollerweise in einer Pärchenanzeige, damit die IC-Kontensalden beider Gesellschaften in einem Rutsch bearbeitet werden. Für diesen Zweck wurde eine spezielle Auszifferungssicht (s.u.) geschaffen.
Die manuelle Auszifferung hat auf die Schulden- und Aufwands-/Ertragskonsolidierung nur in folgendem Fall eine Auswirkung:
Ansonsten dient die manuelle Auszifferung nur der Sichtkontrolle zur Ermittlung einseitig gemeldeter IC-Kontensalden.
Maschinelle Auszifferung
Das Auszifferungskennzeichen kann automatisch auf '01' gesetzt werden für IC-Salden, für die noch kein manuelles Auszifferungskennzeichen gesetzt worden ist. Dies erfolgt nicht durch eine eigene Abstimmfunktion, sondern im Rahmen der Schulden- bzw. Aufwands-/Ertrags-Konsolidierung bzw. (auf Datenarten unterhalb der Konsoliderungsebene) der aus dem Einzelabschluss-Monitor (EA) heraus aufrufbaren IC-Salden-Abstimmung. Dies erfolgt nach folgenden Regeln:
Beim Löschen einer SK/AE-Konsolidierung (durch Löschen in der IC-Clearing-Übersicht (KGESGES) oder Ändern eines Konsolidierungsparameters) werden in den betroffenen IC-Kontensalden auch maschinelle Auszifferungskennzeichen ('01') gelöscht.
Visualisierung der Auszifferung
Zur besseren Selektion der ausgezifferten bzw. nicht ausgezifferten IC-Kontensalden wurde in der Übersicht ICKTOSAL eine spezielle Sicht ergänzt. Diese wird über die Eingabe 'AZ' im Eingabefeld "IC-Selektionsoption" gesteuert. Desweiteren müssen hier die Gesellschaft und die IC-Gesellschaft eindeutig vorgegeben werden, da die Daten nicht nach Gesellschaft sortiert werden. Zusätzlich einschränkende Selektionen (z.B. nach Kontonr.) dürfen nicht eingegeben werden, ausgenommen eine Selektion nach Auszifferungskennzeichen. Durch Selektion nach Auszifferungskennzeichen '*' können alle noch nicht ausgezifferten IC-Salden selektiert werden, durch Angabe '%' alle ausgezifferten.
Die Anzeige dieser Daten erfolgt sortiert nach
Diese spezielle Sortierung soll einerseits die Unterscheidung von ausgezifferten und nicht ausgezifferten Daten vereinfachen, andererseits die manuelle Auszifferung, z.B. von Daten mit gleichen Beträgen und unterschiedlichem Vorzeichen, erleichtern.
Der Controlling-Baustein (kostenpflichtige Zusatzkomponente) wurde mit dem vorliegenden Release erheblich erweitert. Insbesondere ist es jetzt möglich, die Berichtsdaten mit bis zu 10 parallelen Controlling-Informationen (= Dimensionen) zu versehen.
Stammdaten
Ein Anwender, der die zusätzlichen Möglichkeiten nutzen will, muss zunächst spezifizieren, welche Dimension er mit welchem Inhalt belegen will. Dazu sind Einträge in der neuen Anwendung "Controlling-Dimensionen" (CDM) erforderlich. Die maximal 10 Dimensionen sind hier einzufügen und (ggf. mehrsprachig) mit Texten zu versehen, die dann in anderen Anwendungen die Eingabemöglichkeiten und Anzeigen erklären. Wenn Controllingaufrisse bereits genutzt wurden, ist die erste Dimension bereits mit der Bezeichnung "Kostenstelle" durch das Release-Konvertierprogramm angelegt worden. Ohne Definition weiterer Dimensionen enthalten die weiteren Anwendungen auch keine entsprechenden Eingabemöglichkeiten.
Für die zusätzlichen Controllingdimensionen sind Controllingpläne einzurichten. Dies erfolgt wie gewohnt über die Anwendung "Konten- und Controllingpläne" (KTP). Neu ist hier, dass für Controllingpläne anzugeben ist, für welche Dimension dieser Plan dient. Bereits definierte Controllingpläne wurden durch das Release-Konvertierprogramm automatisch auf die erste Controlling-Dimension zugeordnet. Controllingpläne für andere Dimensionen können nicht gleichzeitig ein Kontenplan sein. Eine Änderung der Dimensionszuordnung (Controllingplan-Typ) ist nur zugelassen, wenn der Controllingplan noch nicht im Datenarten- (FAC) oder Gesellschaftsstamm (GES) eingetragen ist (s.u.).
Zu den Controllingplänen sind natürlich auch zugehörige Controllingobjekte einzurichten. Dies erfolgt wie gewohnt durch die Anwendung "Controllingobjekte", deren Kurzwort aus diesem Anlass von 'KST' auf 'CNT' geändert wurde.
Werden weitere Controllingdimensionen verwendet, müssen für Datenarten auf Ebene des Konzernkontenplans im Datenartenstamm (FAC) die jeweiligen Controllingpläne angegeben werden. Für Datenarten auf Ebene der Gesellschaftskontenpläne sind entsprechende Angaben im Gesellschaftsstamm (GES) notwendig. Nur für die erste Controlling-Dimension gilt weiterhin, dass der Controllingplan gleich dem Kontenplan ist (FAC) oder sein kann (GES).
Im Kontenstamm (KTO) ist zu spezifizieren, welche Controllingaufrisse für welches Konto zu führen sind (z.B. Aufriss nach Regionen nur für Umsatzkonten, Aufriss nach Produktgruppen auch für Bestandskonten). Diese Spezifizierung ist für die zugehörigen Berichtsdaten (s.u.) ggf. verpflichtend. Hierzu wurden im Kontenstamm entsprechende Schalter ergänzt. Der Schalter für die erste Dimension wird durch das Release-Konvertierprogramm für alle Konten gesetzt, für die es im System einen Controllingsaldo gibt. Diese Schalter werden automatisch von einem Konzernkonto auf die zugeordneten Gesellschaftskonten "vererbt".
Neu ist hierbei, dass die bisherige Unterscheidung zwischen Bilanz und GuV aufgehoben wird. D.h. auch Bilanzkonten können mit einem Controllingaufriss versehen werden. Auch kann jetzt (bei der bisherigen Stellung '0' des Schalters im Datenartenstamm (FAC)) genau spezifiziert werden, welche GuV-Konten mit Controllingaufriss geführt werden und welche nicht, auch wenn die zusätzlichen Controlling-Dimensionen nicht genutzt werden. Die FAC-Schalterstellung '0' entfällt. '0' und '1' werden durch das Release-Konvertierprogramm auf 'X' umgesetzt.
Berichtsdaten
Für die Controllingsalden wurde eine neue Datenbanktabelle (K041) angelegt. Die Daten der bisherigen Tabelle für Controllingsalden (K064) werden durch das Release-Konvertierprogramm von der alten auf die neue Tabelle übertragen. Ein Unterschied ist u.a., dass jetzt je Controllingobjekt (bzw. Kombination von Controllingobjekten) mehrere Datensätze geführt werden können. Das Kurzwort der zugehörigen Übersicht wurde bei dieser Gelegenheit von 'KSTSAL' auf 'CNTSAL' geändert.
Beim Erfassen oder Importieren von Controllingsalden müssen künftig Controllingobjekte zu den im Kontenstamm spezifizierten Dimensionen angegeben werden. Controllingobjekte zu den übrigen Dimensionen dürfen nicht angegeben werden. Die Controllingobjekte müssen dem jeweiligen im Datenarten- bzw. Gesellschaftsstamm angegebenen Controllingplan zugeordnet sein.
Die Tabellen für IC-Kontensalden (ICKTOSAL), Buchungen (BUCH) und Konsolidierungsbuchungen (KONBUCH) wurden um Attribute für die zusätzlichen Controlling-Dimensionen erweitert. Die Übersichten zeigen diese an und die Einzelsatzanwendungen erlauben die Eingabe in Abhängigkeit von den spezifizierten Controlling-Dimensionen und den Controlling-Schaltern für das jeweilige Konto.
Die Abstimmung zwischen IC-Kontensalden (mit Angaben von Controllingobjekten) und Controllingsalden erfolgt prinzipiell wie bisher, nur dass jetzt die weiteren Controllingdimensionen mit berücksichtigt werden. D.h. unvollständige Angaben in den IC-Kontensalden werden als Differenz gemeldet.
Import
Da die manuelle Pflege der Daten für mehrere Controlling-Dimensionen sehr aufwendig wäre, wird die Erweiterung in den meisten Fällen nur dann sinnvoll nutzbar sein, wenn die Controlling-Informationen aus einem Fremdsystem übernommen werden können.
Die Import-Formate für die verschiedenen erweiterten Tabellen (Stamm- und Berichtsdaten) wurden erweitert. Im Standard-Format '#TXT' wurden die neuen Attribute am Ende angehängt, so dass bisherige Schnittstellen weiterlaufen wie bisher. Bei der Definition neuer Schnittstellen ist evt. die Verwendung individueller Formate empfehlenswert, um unabhängig von diesen gewachsenen Formaten zu sein.
Die Controllingpläne sind durch die Angaben von Datenart und Gesellschaft eindeutig und brauchen daher in den einzulesenden Datensätzen nicht enthalten sein. Sie werden ggf. automatisch ergänzt.
Die spezielle Anwendung zum Import von GuV-Davon-IC-Salden (TXTICKONV) unterstützt die aktuellen Erweiterungen nicht. Insbesondere kann kein automatisches Splitten der Controllingsalden zwischen Original-Konto und IC-Konto mehr erfolgen, wenn es je Controllingobjekt mehrere Datensätze geben kann, da dann nicht mehr eindeutig ist, welcher der Datensätze zu splitten ist.
Die Tabellenerweiterungen wurden auch beim konzernweiten wie beim Teilkonzern-Datenaustausch berücksichtigt.
Verarbeitungsfunktionen
Die Währungsumrechnung führt wie bisher einen Abgleich zwischen IC-Kontensalden und Controllingsalden durch, falls die IC-Kontensalden mit Controllingobjekten versehen sind. Dieser Abgleich umfasst jetzt alle verwendeten Controlling-Dimensionen.
Entsprechend wurde auch die Funktion zur Generierung von Controllingsalden aus IC-Kontensalden erweitert. Die Funktion zum Löschen von Controllingsalden wurde auf die neue Datenbanktabelle umgestellt.
Auch die Vortragsanwendungen berücksichtigen die zusätzlichen Controlling-Dimensionen. Dies betrifft den Periodenvortrag von Buchungen und Konsolidierungsbuchungen wie auch den Datenartenvortrag von Controllingsalden und IC-Kontensalden sowie die Generierung dieser Daten aus den Buchungen. Der durch den Datenartenvortrag erzeugte Kostenstellen-Herkunftsnachweis (KSTHER) bleibt aber auf die erste Controlling-Dimension beschränkt.
Als einzige Konsolidierungsverarbeitungen verarbeiten die Schulden- und die Aufwands/Ertrags-Konsolidierung (SK/AE) die Erweiterung auf 10 Controlling-Dimensionen, vorausgesetzt die verarbeiteten IC-Kontensalden sind mit Angabe von Controllingobjekten geführt. Dann werden diese Angaben in die daraus generierten Konsolidierungsbuchungen übernommen. Damit sind wesentliche Teile der GuV, dem Haupteinsatzgebiet von Controllingaufrissen, abgedeckt.
Weitere Anwendungen unterstützen die zusätzlichen Controlling-Dimensionen zunächst nicht. Dies gilt insbesondere für die Formularerfassung, die weiteren Konsolidierungsverarbeitungen und die MIS-Bereitstellungsfunktion.
Auch die Eingabe von bis zu 9 weiteren Controllingobjekten je Konto in den Konsolidierungsparametern ist nicht praktikabel. Es wird aber jetzt anhand der Schalter im Kontenstamm geprüft, ob für das angegebene Konto die Angabe eines Controllingobjekts der ersten Dimension erforderlich ist oder nicht. Es kann daher eine Reihe von Konsolidierungsbuchungen geben, in denen die fehlenden Controllingobjekte manuell nachgetragen werden müssen.
Auch das Reporting wird nicht umgestellt, zumal die beschränkte Dimensionalität der Reportergebnistabelle maximal zwei Controlling-Dimensionen gestatten würde, und auch dies nur in speziellen Fällen. Controlling-Reports beschränken sich daher weiterhin auf die erste Controlling-Dimension. Für eine mehrdimensionale Auswertung wird die Überleitung in eine OLAP-Datenbank empfohlen.
Die MIS-Bereitstellungsfunktion für die Überleitung der IDL Konsis-Daten in eine OLAP-Datenbank wurde nicht um die zusätzlichen Dimensionen erweitert, da eine neue Funktion in Vorbereitung ist, mit der mit Hilfe des IDL Importers die Daten direkt in die OLAP-Datenbank übernommen werden können.
Durch neue Datenbanktabellen und Anwendungen besteht jetzt die Möglichkeit zur Definition individueller Plausibilitätsbedingungen im Einzelabschluss. Die Einhaltung dieser Plausibilitäten wird durch eine zusätzliche Statusspalte im Einzelabschluss-Monitor angezeigt.
Prüfregel-Definition
Eine erste neue Tabelle für die Prüfregeln enthält einen 20stelligen Schlüssel und diverse Attribute zur Beschreibung der Daten auf der linken und rechten Seite der Prüfregel. Es wird eine Übersicht (PRF), eine Einzelsatzanwendung (PRFE) und eine Importanwendung (TXTPRF) zur Verfügung gestellt.
Eine zweite neue Tabelle enthält die Zuordnung von Positionen und Konten zu einer Prüfregel, getrennt für die linke und die rechte Seite der Prüfregel, d.h. die Daten, die verglichen werden sollen. Dazu gehört auch eine Möglichkeit zur Einschränkung einer Position oder eines Kontos auf eine Spiegelspalte oder einen Buchungsschlüssel. Es wird eine Übersicht (PRFPOS), eine Einzelsatzanwendung (PRFPOSE) und eine Importanwendung (TXTPRFPOS) zur Verfügung gestellt.
Prüfergebnis ermitteln
Eine neue Anwendung ermittelt aus den Prüfregeln je Gesellschaft, Periode und Datenart ein Prüfergebnis. Aus Performance-Gründen wird diese Anwendung nicht immer automatisch aufgerufen, wenn sich Daten ändern. Vielmehr lässt sich diese Anwendung per Aktion aus dem Einzelabschluss-Monitor (EA, Submenü <Verarbeitungen>) oder aus der neuen Übersicht der Prüfergebnisse (PRFERG, s.u.) heraus starten.
Das Ergebnis der Prüfung wird je Prüfregel in einer weiteren neuen Tabelle abgelegt. Zusätzlich wird für das Gesamtergebnis aller Prüfregeln ein Datensatz in die Verarbeitungssteuerung (VERARB, Checkpoint PRFERG) geschrieben.
Es ist zu beachten, dass bei der Verwendung von Konten in den Prüfregeln der zugehörige Kontenplan für die zu prüfende Datenart bzw. Gesellschaft eventuell nicht gültig ist. In diesem Fall wird für die Prüfregel eine spezielle Meldung gesetzt. Auf das Gesamtergebnis der Prüfung hat dies dann aber keinen Einfluss. (Die Prüfregel wird als nicht existent betrachtet.)
Da eventuell Positionen und Konten gemischt in einer Prüfregel vorkommen könnten, wird für die Vorzeichenbestimmung eines Wertes nur das Soll/Haben-Kennzeichen berücksichtigt, während für die Vorzeichenbestimmung im Report immer das Bilanz/GuV-Kennzeichen der Positionen verwendet wird, das aber bei der Angabe einzelner Konten in der Prüfregel nicht bekannt oder nicht eindeutig ist.
Das Prüfergebnis für eine einzelne Prüfregel wird je Währung ermittelt (in Abhängigkeit vom Schalter für Währungsumrechnung in der Datenart/FAC). Für das Gesamtergebnis wird nur ein einziger Datensatz in die Verarbeitungssteuerung geschrieben, der nur dann fehlerfrei ist, wenn für alle geprüften Währungen die Prüfregeln fehlerfrei waren.
Prüfergebnis visualisieren
Zur Anzeige der so ermittelten Prüfergebnisse dient eine neue Übersichtsanwendung (PRFERG).
Das Gesamtergebnis der Prüfung über alle Regeln gemäß Meldung im neuen Satz der Verarbeitungssteuerung (VERARB) wird im Einzelabschluss-Monitor (EA) je Gesellschaft angezeigt. Dafür dient eine neue Statusspalte. Bei einem Doppelklick auf diese Spalte wird in die Übersicht zur Anzeige der Prüfergebnisse (PRFERG) verzweigt.
Um eine sinnvolle Anzeige im Einzelabschluss-Monitor auch dann zu gewährleisten, wenn sich nach erfolgter Prüfung die zugrundeliegenden Daten ändern, wird in diesem Fall in den entsprechenden Satz der Verarbeitungssteuerung die Meldung 'Prüfergebnis nicht aktuell' gesetzt. Dies führt zur Statusanzeige <gelb>. Dies setzt allerdings voraus, dass der Anwender das Prüfziffernverfahren aktiviert hat.
Schon immer bestand in IDL Konsis das Problem, dass Spiegelinformationen aus Konsolidierungsbuchungen nicht vorgetragen wurden, wenn diese in Einmalbelegen (Buchungsart 'E') enthalten waren. Zwar erfolgte ein Vortrag für die parallel geführten Konzernbewegungen, jedoch liefen dadurch einerseits Konzernbewegungen und Konsolidierungsbuchungen auseinander (Differenzen im Protokoll der Aktion <Verproben Konzernbew./Kons.-Buch.> in den Bewegungsübersichten für Konzernbewegungen), andererseits sollen Konzernbewegungen ganz abgeschafft werden (s.o.), um redundante Datenhaltung zu vermeiden. Diese Vortragsbuchungen fehlen auch für den Kapitalfluss-Report.
Dieselbe Problematik stellt sich auch für ergebniswirksame Buchungen in Einmalbelegen. Auch hier fehlte bisher die Umbuchung auf das Ergebnisvortragskonto.
Aus diesen Gründen wurden die Vortragsregeln überarbeitet mit dem Ziel, dass Spiegelinformationen unabhängig von der Buchungsart des Belegs vorgetragen werden. Konsolidierungsbuchungen auf Konten, die einem Spiegel mit Vortrag (Buchungsschlüssel mit Verwendungskennzeichen 'V' ist definiert) zugeordnet sind, und ergebniswirksame Buchungen werden immer vorgetragen. Handelt es sich um Einmalbelege (Buchungsart 'E', ggf. auch Buchungsart 'WX'), so wird zusätzlich eine Buchung erzeugt, die den Vortrag wieder eliminiert, allerdings nicht mit dem Vortrags-Buchungsschlüssel, sondern mit einem Buchungsschlüssel für laufende Veränderungen. Bei automatischen Spiegeln ist dies der Buchungsschlüssel mit Verwendungskennzeichen 'L', für andere Spiegel ist dafür ein Buchungsschlüssel mit dem neuen Verwendungskennzeichen 'N' zu definieren. Für die Standard-Spiegel (Anlagen, Kapital, Rückstellungen) werden dazu neue Buchungsschlüssel ausgeliefert.
Belege aus der Schuldenkonsolidierung (SK) sind von dieser Vortragslogik ausgenommen, da sie Einzelabschlusswerte je Periode eliminieren. Der Vortrag dazu ist in den Vortragswerten im Einzelabschluss der Folgeperiode enthalten. Dies gilt aber nur für die Buchungen auf den IC-Konten. Buchungen zur Eliminierung von Differenzen oder Unterschiedsbeträgen, Differenzen aus der Währungsumrechnung sowie manuelle Buchungen werden gemäß obiger Regel vorgetragen. Als Ausnahme werden daher nur Buchungen auf Konten mit Angabe einer Konsolidierungsverarbeitung im Kontenstamm (KTO) behandelt.
Zur Klarstellung der Sachverhalte wurden verschiedene Konsolidierungsverarbeitungen daraufhin geändert, dass sie die erzeugten Konsolidierungsbelege mit einer Buchungsart versehen, die ihrer Vortragslogik entspricht. So wird für die Konsolidierungsbelege aus der Kapitalkonsolidierung jetzt die Buchungsart 'WU' statt bisher 'E' vergeben.
Die Buchungsart 'WV' (Vortrag eines Beleges nur als Schablone ohne Werte) kommt nur in manuellen Belegen (Mx) vor. Um zu verhindern, dass Verwirrung entsteht, werden die vorgetragenen Buchungen mit Werten gemäß obiger Vortragsregel in einen Vortragsbeleg mit Konsolidierungsverarbeitung 'Vx' geschrieben. Der Vortrag der Buchungsschablone aus Gesellschaften, Konten und Buchungsschlüsseln mit Nullwerten dagegen erfolgt in einen neuen 'Mx'-Beleg.
Durch diese Vortragsregeln wird der nachträgliche Vortragsabgleich für automatische Spiegel (FU-Beleg) überflüssig. Die zugehörige Verarbeitung "Umbuchung autom. Spiegel (FU)" wird aber nicht sofort abgeschafft, sondern steht für eine Übergangszeit zur Abstimmung noch zur Verfügung.
Diese, soweit für Konsolidierungsbelege beschriebene Vortragslogik wird analog auch für den Vortrag von Buchungen aus dem Einzelabschluss (BUCH) angewandt.
Zwei neue Übersichten ermöglichen die gemeinsame Anzeige von Einzel- und Konzernabschlussdaten:
Die Übersichten dienen ideal zur Analyse und Abstimmung von Reportergebnissen (z.B. nach Folgeaufruf aus REPERG mit Selektionskriterien gemäß der selektierten Zeile). Sie können ggf. für ad-hoc-Analysen auch die Erstellung eines Reports ersetzen.
Die Einträge für die beiden Übersichten finden sich im Menübaum im Zweig "Konzernabschluss". Sie können außerdem als Folgeanwendungen (Aktionen) aus dem Konzernkreis-Monitor (KTKGES) und der Reportergebnisanzeige (REPERG) heraus aufgerufen werden.
Beide Anwendungen ermöglichen die Selektion der Daten nach Konzern (mit Option zur Einbeziehung untergeordneter Teilkonzerne analog KONBUCH), Gesellschaft, ggf. Geschäftsbereich, Periode, Datenart, Position und Konto. KONBEW kann zusätzlich nach Spiegelspalte und/oder Buchungsschlüssel einschränken. Die angegebene Sprache wirkt analog zu anderen Übersichten auf die angezeigten Bezeichnungen von Konten, Positionen etc. Durch Eingabe einer Währung ('KW' oder 'PW') wird gesteuert, in welcher Währung die Werte angezeigt werden.
Folgende Sortier-Optionen stehen zur Verfügung:
Die Anzeige der Daten erfolgt gemäß der gewählten Sortier-Option in Baumstruktur, wobei die Werte in der Struktur auf die Knoten summiert werden. Schlüssel, nach denen eindeutig selektiert wurde, werden in der Baumstruktur nicht mehr wiedergegeben. Zusätzlich gibt es am Ende der Tabelle noch die Gesamtsummen aus Einzelabschluss, Konzernabschluss und deren Summe.
Auf der untersten Ebene des Baumes werden die einzelnen Datensätze (Kontensalden, Einzelabschluss-Bewegungen, Konsolidierungsbuchungen) angezeigt und dabei durch die Konsoldierungsbelegnummer oder durch geeignete Texte ("EA-Kontensaldo", "EA-Bewegung") gekennzeichnet.
Neben dem Schlüssel (Positionsnummer, Kontonummer, Gesellschaft, Geschäftsbereich, Spiegelspalte oder Buchungsschlüssel) und dessen Bezeichnung enthalten die Tabellen nur eine Wertspalte und ein Soll/Haben-Kennzeichen. Zusätzlich können die Änderungsinformationen für die einzelnen Datenzeilen angezeigt werden.
Die Fortschreibung Equity (EF) wurde um eine Reihe von Eingabemöglichkeiten erweitert. Die erweiterte Eingabemaske steht jetzt in Form einer Formularerfassung zur Verfügung, in der die getätigten Eingaben zur automatischen Berechnung von Zwischen- und Endsummen führen. Die Übernahme der erfassten Daten in die Datenbank erfolgt durch den Button <Speichern>.
Die Erfassungsmaske zur Equity-Fortschreibung besteht aus 3 Blöcken:
Erstübernahme Equity
Der Block für die Erstübernahme gliedert sich in zwei Teile:
Die Entwicklung der kumulierten Buchwertfortschreibungen setzt sich aus folgenden Positionen zusammen:
Die Position "Sonstiges Erstübernahme/Vortrag" zeigt Buchungen aus früheren Equity-Fortschreibungen, die nicht auf einem Konto des neuen Konsolidierungsparameters 'EF' gebucht wurden.
Die Korrektur eines negativen Equity-Wertansatzes setzt sich aus folgenden Positionen zusammen:
Laufende Fortschreibungen
Der Block für laufende Veränderungen bietet folgende Eingabemöglichkeiten oder (aus dem 'EK'- oder 'KF'-Beleg) angezeigten Werte:
Die Anzeigedaten werden aus dem 'KF'-Beleg gelesen. Sie müssen dort ggf. manuell gebucht werden.
Ausgleich negativer Wertansatz
Der Block für den Ausgleich eines negativen Wertansatzes gliedert sich in zwei Teile:
Bei Entstehung oder Erhöhung eines negativen Wertansatzes gibt es folgende Eingabemöglichkeiten:
Bei Verringerung eines negativen Wertansatzes gibt es folgende Eingabemöglichkeiten:
Bei der Eingabe im dritten Block sind folgende Bedingungen einzuhalten:
Sonstiges
Die für die Equity-Fortschreibung benötigten Konten (sowie ggf. Buchungsschlüssel) sind in zwei neuen Konsolidierungsparametern anzugeben: 'EF' (Equity-Fortschreibung laufende Veränderungen) und 'EN' (Equity-Fortschreibung negativer Wertansatz). Sind optionale Konten dort nicht angegeben, fehlen die zugehörigen Eingabemöglichkeiten in der Erfassungsmaske.
Neben der aktuellen Periode kann auch eine Vorperiode angegeben werden. Dann werden in der Erfassungsmaske weitere Spalten für die in diesem Periodenintervall enthaltenen Jahresabschlüsse ausgegeben. Diese Spalten enthalten die entsprechenden Werte der vorherigen Jahre, allerdings ohne Eingabemöglichkeit.
Verschiedene Report-Funktionalitäten wurden ergänzt. Dies sind u.a.
IDL Konsis unterstützte bisher nur Zeichen des westeuropäischen Standard-Zeichensatzes (Windows-Codepage 1252). Zeichen von osteuropäischen Sprachen sowie andere Zeichensätze (griechisch, kyrillisch, hebräisch, japanisch etc.) konnten in IDL Konsis nicht verwendet werden. Dies wird mit dem vorliegenden Release geändert.
Für die bisherige Codierung der Zeichen genügte ein Byte je Zeichen. Codierungen für internationale Zeichensätze, realisiert durch den Unicode-Standard, benötigen mehrere Bytes je Zeichen.
Auswirkungen auf die Datenbank
Es wurde festgelegt, Unicode-Zeichen nicht in der gesamten IDL Konsis-Datenbank zu unterstützen, sondern nur in den Tabellen für mehrsprachige Bezeichnungen und für Hilfetexte, die jeweils zentral definiert sind. Diese Tabellen wurden neu definiert (neue Datentypen für die betreffenden Spalten). Das bedeutet u.a., dass Schlüssel (z.B. Kontonummern, Gesellschaftsnummern) weiterhin nur aus den auch bisher möglichen Zeichen bestehen dürfen.
Bezeichnungen, die bisher in den jeweiligen Datenbanktabellen direkt enthalten waren, mussten daher in die zentrale Bezeichnungstabelle ausgelagert werden. Dies betrifft neben einigen Stammtabellen (Anlagenobjekte) vor allem die Bemerkungen und Buchungstexte von Berichtsdaten (Salden, Bewegungen, Belege und Buchungen). Diese Texte werden allerdings auch weiterhin nicht mehrsprachig unterstützt.
Die Umsetzung erfolgt für die von IDL ausgelieferten Metadaten im Rahmen der Metadaten-Übernahme beim Einspielen dieses Releases. Für kundenspezifische Daten erfolgt die Umsetzung durch das Release-Konvertierprogramm, das dadurch je nach Umfang der Kundendaten längere Laufzeiten benötigt.
Die Unterstützung von Unicode-Zeichensätzen durch die Datenbanksysteme ist unterschiedlich. Die Möglichkeiten zur Nutzung der Erweiterung sind daher nach Datenbanksystem zu unterscheiden:
Import und Export
In der Tabelle "Felder für Import/Export-Formate" (IEFDEF) wurden die in der Tabelle für Bezeichnungen geführten Felder mit dem neuen Datentyp "UNICODE" versehen (bisher "CHAR"), z.B. Bezeichnung 1 und Kurzwort für Konten (Formattyp 'KTO'). Dadurch wird festgelegt, dass diese Felder Zeichen aus internationalen Zeichensätzen enthalten dürfen.
Die Standard-Import-Formate #TXT sind (abgesehen von einigen anwendungsspezifischen Erweiterungen) unverändert, so dass bisherige Überleitungswege ohne Anpassung weiter genutzt werden können.
Zum Import von Daten mit bisher nicht unterstützten Zeichen muss die gesamte Importdatei in einer abweichenden Codierung (z.B. UTF-8) gehalten werden. Die Angabe der Codierung erfolgt durch spezielle Byte-Folgen am Anfang der Datei (möglich für UTF-8 und UTF-16), über den Steuerparameter "$$ CODEPAGE" im Kopf der Importdatei oder durch die Zuordnung einer Codepage zum Import/Export-Format (IEF). Letztere Angabe ist auch notwendig zum Erstellen einer Exportdatei in einer abweichenden Codierung. Ohne Angabe einer Codepage wird die bisherige Standard-Codepage Windows-1252 unterstellt.
Enthalten Nicht-Unicode-Daten (z.B. Schlüsselfelder) in einer Importdatei Zeichen, die sich nicht in die Standard-Codepage (Windows 1252) umsetzen lassen, werden diese Zeichen durch Fragezeichen ersetzt. Ggf. führt dies zu Folgefehlern.
Das Erstellen oder Lesen von Importdateien in abweichenden Zeichensätzen erfordert einen Editor, der diese Zeichensätze beherrscht.
Ein Konflikt entsteht bei der bisherigen Form der Protokollausgabe, da Ausgabe der fehlerhaften Datensätze einerseits, der Fehlerinformation andererseits in verschiedenen Codierungen sein können, so dass sie nicht gleichzeitig gelesen werden können. Die Protokollausgabe wurde daher unterteilt:
Die Version 9 der Datenbank IBM DB2 wird jetzt unterstützt.
Die in der Online-Dokumentation enthaltenen Bilder werden jetzt nicht mehr in der Datenbank abgelegt, sondern in eigenen Dateien im Dateisystem. Dadurch verkürzt sich die Dauer der Installation spürbar.
Die Möglichkeit zur Änderung des Passworts (Button <Erweitert> im Anmeldefenster) ist jetzt auch für MS SQL Server-Datenbanken gegeben.
Im Zusammenhang mit der Unicode-Umstellung wurde die zentrale Datenbanktabelle für mehrsprachige Bezeichnungen neu gestaltet. U.a. ist dadurch die bisherige Bezeichnung 2 entfallen, sofern sie keine weitere Verwendung (z.B. als Tabellenüberschrift) hatte. Anwenderdaten, die eine Bezeichnung 2 enthielten, werden durch das Release-Konvertierprogramm so bearbeitet, dass die bisherige Bezeichnung 2 jetzt in den Hilfetext geschrieben wurde, damit sie nicht einfach entfällt. Dies betrifft z.B. den Gesellschaftsstamm (GES). Der Anwender sollte prüfen, ob diese Information im Hilfetext weiter benötigt wird.
Enthält eine Übersicht eine Tabellenanzeige in Baumstruktur, so wird der Aufklapp-Zustand nach Möglichkeit auch bei Schlüsselwechsel beibehalten (z.B. beim Wechsel der Währung oder der Gesellschaft in der Reportergebnisanzeige).
Zur besseren Lesbarkeit von Fehlermeldungen werden darin enthaltene Kontonummern jetzt ohne vorangestellten Kontenplan angezeigt. Der zugehörige Kontenplan ergibt sich in der Regel aus dem Kontext der Meldung (Datenart, Gesellschaft).
Das Konvertierprogramm für dieses Release nimmt folgende Umsetzungen in der Datenbank vor:
Zusätzlich werden auch die Konvertierungen aus dem Zwischenrelease 2006.1 durchgeführt, sofern dieses Zwischenrelease nicht installiert wurde.
Folgende Menü-IDs sind in diesem Release neu. Falls 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.
Für die Rolle eines Einzelabschluss-Entscheiders wurde eine neue Standard-Benutzergruppe IDLEE (bzw. IDLWINEE für IDL WinKons) definiert. Ein Benutzer, dem diese Benutzergruppe zugeordnet wird, darf sich alle Einzelabschlussdaten nur ansehen, aber nicht ändern. Zusätzlich darf er den Einzelabschluss freigeben. Diese Freigabe darf er aber nicht selbst wieder aufheben.
Im Menübaum wurde das neue Submenü <Prüfregeln> im Menüzweig <Stamm- und Steuerungsdaten> ergänzt. Darunter finden sich die neuen Anwendungen für individuelle Plausibilitäten.
Im Menübaum wurde das neue Submenü <Stammdatenprotokollierung> im Menüzweig <Stamm- und Steuerungsdaten> ergänzt. Darunter finden sich die alten und neuen Anwendungen zur Protokollierung von Stammdatenänderungen. Diesen Menüzweig sehen Sie nur, wenn Sie die Komponente "Stammdatenprotokollierung" lizenziert haben (s. nächstes Kapitel).
Beim Aufbau des Menübaums werden jetzt die lizenzierten Zusatzfunktionen (Controlling, Stammdatenprotokollierung) ausgewertet und die Einträge für die nicht lizenzierten Menüpunkte werden unterdrückt. Die zugehörigen Anwendungen lassen sich somit weder aus dem Menübaum auswählen noch per Kurzwort aufrufen.
Des weiteren erfolgt jetzt auch eine Prüfung auf lizenzierte fremdsprachige Oberflächen (englisch, französisch). Beim Versuch, sich mit Einstellung einer nicht lizenzierten Sprache anzumelden, bricht IDL Konsis nach Ausgabe einer entsprechenden Fehlermeldung ab. Bei Problemen wenden Sie sich bitte an die IDL Hotline.
In der neuen Anwendung "Controlling-Dimensionen" (Kurzwort CDM) kann ein Anwender spezifizieren, ob er zusätzliche Dimensionen für seinen Controlling-Aufriss nutzen will. Die dazu angegebenen Bezeichnungen werden in anderen Anwendungen verwertet. Im Menübaum finden Sie diese Anwendung unter <Stamm- und Steuerungsdaten> im Zweig <Konten & Positionen>.
Die Tabelle für Konten-/Controllingpläne wurde um ein Attribut für die Controlling-Dimension erweitert. Dieses Attribut muss für Controllingpläne (KTP-Typ 'C' oder 'M') angegeben werden.
Der Kontenstamm wurde um eine Schalterleiste erweitert, mit der definiert wird, welche Controllingaufrisse für ein Konto erforderlich sind und welche nicht zugelassen sind. Diese Schalterleiste ersetzt in gewisser Weise das frühere Kontokennzeichen 'C', so dass die Steuerung von Controllingaufrissen je Konto erfolgen kann. Diese Schalterleiste wird automatisch von Konten des Konzernkontenplans an die zugeordneten Gesellschaftskonten weitergegeben.
Bei der Zuordnung von Verdichtungskonten können jetzt Bilanz- bzw. GuV-Konten beliebig aufeinander zugeordnet werden (z.B. Aktiv- auf Passivkonto, Ertrags- auf Aufwandskonto), ohne dass das Bil/GuV-Kennzeichen verändert wird. Bisher wurde das Bil/GuV-Kennzeichen des Verdichtungskontos immer in das Konto übernommen.
Das Kurzwort für die Anwendung "Controllingobjekte" wurde von KST auf CNT umbenannt.
Das Controllingkennzeichen 1 zur Zuordnung von Kostenarten für das Umsatzkostenverfahren (UKV) wurde um 9 individuell nutzbare Controllingbereiche mit den Schlüsseln 'Z1' bis 'Z9' ergänzt. Diese können benutzt werden, wenn die bisherige Standard-Klassifizierung ('A' = Verwaltungskosten, 'F' = Forschung und Entwicklung, 'H' = Herstellkosten, 'V' = Vertriebskosten, 'U' = Umlagen, 'S' = Sonstige Kosten) nicht ausreicht. Eine Möglichkeit zur individuellen Betextung der neuen Kennzeichen besteht nicht.
Die neuen Kennzeichen können wie die alten in der Konten-Positions-Zuordnung (POSKTO) zur differenzierten Steuerung der Salden auf unterschiedliche Positionen genutzt werden. Sie können auch in UKV-Reports (Reporttyp 'C') in eigenen Spalten ausgewiesen werden.
Aus der Maske der Einzelsatzanwendung "Position" (POSE) wurde das Eingabefeld für "Referenz-Position" entfernt, da dieses Attribut keine Bedeutung mehr hat.
Analog anderen Stammdaten können Anlagenobjekte (ANLOBJ) jetzt mit einer längeren Beschreibung (= "Hilfetext") versehen werden. Diese Texte können allerdings nicht parallel in verschiedenen Sprachen angegeben werden. Dies gilt auch für IC-Anlagenobjekte.
Für den Kapital- und den Rückstellungsspiegel wurden jeweils die neuen Buchungsschlüssel '18' und '36' mit dem neuen Verwendungskennzeichen 'N' ergänzt. Mit diesen Buchungsschlüsseln werden Vorträge aus Einmalbelegen eliminiert.
Im Anlagenspiegel wurde der Buchungsschlüssel '30' ergänzt. Er hat das Verwendungskennzeichen 'U' (Umrechnungsdifferenz) für den Spiegelbereich 'B' (Abschreibungen).
Die Tabelle für Gesellschaften wurde um Attribute für Controllingpläne für die zusätzlichen Controlling-Dimensionen erweitert. Die Eingabe ist in Abhängigkeit von den definierten Controlling-Dimensionen (CDM) und des Schalters für Controlling-Aufrisse Pflicht.
Die Tabelle für Datenarten wurde um Attribute für Controllingpläne für die zusätzlichen Controlling-Dimensionen erweitert. Die Eingabe ist in Abhängigkeit von den definierten Controlling-Dimensionen (CDM) und des Schalters für Controlling-Aufrisse Pflicht.
Der Schalter für Controlling-Aufrisse unterscheidet jetzt nur noch zwischen '-' (ohne Controllingsalden) und 'X' (mit Controllingsalden). Eine differenzierte Steuerung erfolgt je Konto.
Die Protokollierung von Stammdatenänderungen (kostenpflichtiger Zusatzbaustein) ist jetzt auch für folgende Tabellen möglich:
Zur Aktivierung der Protokollierung geben Sie in der Anwendung "Steuerung Stammdatenprotokollierung" (LOG) den jeweiligen Tabellennamen ein und wählen die Aktion <Stammdatenprotokollierung aktivieren>. Durch diese Aktion wird der aktuelle Zustand der angegebenen Tabelle in die Protokolltabelle kopiert. Bei der Aktivierung sollten keine anderen Benutzer mit der Datenbank verbunden sein. Anschließend werden alle Änderungen an dieser Tabelle in der Protokolltabelle festgehalten.
Zur Ansicht und Analyse der protokollierten Daten gibt es je Tabelle eine neue Übersichtsfunktion:
Diese Übersichten zeigen die Protokollsätze an, ermöglichen eine Selektion nach den wesentlichen Attributen (ähnlich der jeweiligen Stammdatenübersicht) und zusätzlich Abfragen nach Art (Einfügen, Ändern, Löschen) und Zeitpunkt der Änderung. So können alle Änderungen ab einem bestimmten Zeitpunkt selektiert werden oder auch der Zustand der Originaltabelle zu einem bestimmten Zeitpunkt.
Der Status für den Abgleich des Periodenvortrags (Spalte "Abgleich Vorträge") wird jetzt automatisch auf <gelb> gesetzt, wenn vortragsrelevante Daten (Spiegelbewegungen, Beteiligungen, Buchungen) in der Vorperiode verändert werden, vorausgesetzt
Durch Wiederholung des Abgleichs wird der Status je nach Art der Änderung <grün> oder <rot>.
Eine neue Statusspalte "Abgleich Datenarten-Vorträge" zeigt das Ergebnis der Aktion "Abgleich Ges.Abschluss neue Datenart" an. Durch Aufruf dieser Aktion wird der Status aktualisiert.
Eine neue Statusspalte "Prüfregel Ergebnis" zeigt das Ergebnis der Prüfung individueller Plaubilitätsbedingungen (s.o.) an. Ein Doppelklick in diese Spalte verzweigt in die neue Übersicht PRFERG für Prüfregelergebnisse. Durch Aufruf der Aktion <Berechnen des Prüfregelergebnisses> im Submenü <Verarbeitungen> wird dieser Status aktualisiert.
Das Aufheben der Freigabe eines Einzelabschlusses (Funktion des Einzelabschluss-Monitors EA) ist jetzt nicht mehr möglich, wenn der Konzernabschluss für einen Konzern/Teilkonzern, dem die betreffende Gesellschaft angehört, bereits freigegeben wurde (Funktion des Konzernkreis-Monitors KTKGES).
Zu den Berichtsdaten (Salden, Bewegungen, Belege, Buchungen) können jetzt längere Beschreibungen ("Hilfetexte") hinterlegt werden (s.o.).
Die Übersicht Kontensalden (KTOSAL) gibt bei Selektion nach Konzernkreis, wie sie u.a. bei Verzweigung aus dem Konzernreport erfolgt, in einem Meldungsfenster eine Liste der Gesellschaften aus, für die Kontensalden vorliegen, aber der jeweilige Benutzer keine Ansichtsrechte besitzt, so dass sie nicht angezeigt werden. Dies erklärt ggf. auftretende Differenzen zwischen Reportergebnis und Saldensummen.
Die Aktionen "Hilfetext anzeigen" (alternativ <F1>) und "Hilfetext editieren" (alternativ <Strg-F1>) beziehen sich jetzt nicht mehr auf den Hilfetext des jeweiligen Kontos, sondern auf den (neu eingeführten) Hilfetext zum Kontensaldo (s.o.).
Wird in einer Übersicht für Aufrissdaten (Controllingsalden / CNTSAL, IC-Unterkontensalden / ICKTOSAL, Anteilsbesitzbewegungen / GESGES, Anlagenbewegungen / ANLBEW, Kapitalbewegungen / KAPBEW, Rückstellungsbewegungen / RUEBEW, individuelle Spiegelbewegungen / SPIBEW) nach einem Konto selektiert (z.B. bei Aufruf via Doppelklick auf das Kontokennzeichen in KTOSAL), dann wird jetzt eine Differenz zwischen der Summe der Aufrissdaten und dem Kontensaldo in der bisherigen Leerzeile zwischen Aufrissdaten und Vergleichswert aus den Kontensalden angezeigt. Dieser Wert ist rot hinterlegt. Diese Anzeige erfolgt ggf. in allen drei Währungen. Dieser Wert muss für einen neuen Aufrisssatz verwendet werden, um die offene Differenz zum Kontensaldo auszugleichen.
Die Tabelle für Controllingsalden wurde neu definiert (neues Kurzwort: CNTSAL), so dass jetzt bis zu 10 Controllingobjekte zu verschiedenen Controlling-Dimensionen parallel angegeben werden können. Die Angabe ist in Abhängigkeit von neuen Schaltern im Kontenstamm Pflicht. Je Controllingobjekt (bzw. Kombination von Controllingobjekten) können mehrere Datensätze geführt werden.
Die Übersicht Controllingsalden (CNTSAL) gibt bei Selektion nach Konzernkreis in einem Meldungsfenster eine Liste der Gesellschaften aus, für die Controllingsalden vorliegen, aber der jeweilige Benutzer keine Ansichtsrechte besitzt, so dass sie nicht angezeigt werden.
Die Tabelle für IC-Kontensalden wurde um Attribute für das neue Auszifferungsverfahren erweitert. Die neuen Attribute Referenzbeleg-Nummer und Referenzbeleg-Datum werden angezeigt und sind eingebbar (ICKTOSALE). Die neue Aktion <Mengenändern> in der Übersicht ICKTOSAL dient dem Setzen eines manuellen Auszifferungskennzeichens.
Die Tabelle für IC-Kontensalden wurde analog zu den Controllingsalden um Attribute für weitere Controllingobjekte erweitert, so dass unter gewissen Voraussetzungen in der Einzelsatzanwendung ICKTOSALE bis zu 10 Controllingobjekte zu verschiedenen Controlling-Dimensionen parallel angegeben werden können.
In der Abstimmsicht (Pärchendarstellung), wie sie beim Aufruf aus der "IC-Clearing-Übersicht" (KGESGES) erfolgt, führt die Übersicht "IC-Kontensalden" (ICKTOSAL) eine implizite Währungsumrechnung durch. Bisher war dies immer eine einfache Umrechnung zum Stichtagskurs (SK). Jetzt erfolgt die implizite Umrechnung der GuV-IC-Kontensalden zum Periodendurchschnittskurs (PDK), wenn es einen Währungsumrechnungs-Kopfsatz (WUM) gibt und dieser ein anderes Umrechnungsverfahren als 'RST' (reiner Stichtagskurs) angibt. Dies gilt analog für die IC-Saldenabstimmung im Einzelabschluss.
Die Übersetzung der IC-Gesellschaft in der Spalte "Bezeichnung" der Übersicht IC-Unterkontensalden (ICKTOSAL) erfolgt jetzt durch die Langbezeichnung statt wie bisher durch das Kurzwort.
Die Verprobung der laufenden Abschreibungen gegen GuV-Kontensalden für Konten mit Kontokennzeichen 'D' erfolgt jetzt nur noch für Anlagenbewegungen auf nicht-statistischen Konten. Entsprechendes gilt für die Prüfungen von Zuführungen und Auflösungen von Rückstellungen (Kontokennzeichen 'Y' und 'Z') sowie für die Prüfungen für die Umbuchungsspalten (Summe aller Bewegungen muss null ergeben). Für die Bewegungen auf statistischen Konten erfolgen keine Prüfungen.
Die Prüfung auf plausible Prozentwerte (Anteilsbesitz zwischen 0% und 100%) erfolgt jetzt nicht nur für das Ende der aktuellen Periode, sondern auch für alle Zwischentermine (z.B. Datum für Konzernkreisabgang).
Außerdem wird ausgeschlossen, dass zwei Anteilsbesitzbewegungen mit unterschiedlichen Buchungsschlüsseln dasselbe Bewegungsdatum haben, da dann deren Reihenfolge für die Abarbeitung nicht mehr eindeutig ist. Ausnahme ist ein Sonderfall der Endkonsolidierung, nämlich wenn die Mutter einer Gesellschaft den Konzernkreis verlässt. Dann ist für die Gesellschaft ein Abgang und ein Zugang mit demselben Bewegungsdatum zu pflegen.
Für Beteiligungen (GESGES) wurde ein neuer BSL '13' eingeführt. Er beschreibt Kurseffekte für den Fall, dass die Beteiligung in einer Fremdwährung gehalten wird (z.B. Buchwert der Anteile an einem Fond). Die Kurseffekte muss der Anwender jährlich im Einzelabschluss auf dem Beteiligungskonto mit diesem Buchungsschlüssel melden. Ein GESGES-Satz mit BSL '13' darf keine Prozentsätze enthalten.
In der Übersicht "Anteilsbesitzbewegungen" (GESGES) wurde eine Möglichkeit zur Verzweigung in die Übersicht "Anlagenbewegungen" (ANLBEW) ergänzt.
Für die IC-Bewegungen im Vorratsvermögen können jetzt durch die Eingabe negativer Werte sowohl Bestände im Soll als auch Bestände im Haben erfasst werden.
Die Tabelle für Buchungen (BUCH) wurde analog zu den Controllingsalden um Attribute für weitere Controllingobjekte erweitert, so dass unter gewissen Voraussetzungen in der Einzelsatzanwendung BUCHE bis zu 10 Controllingobjekte zu verschiedenen Controlling-Dimensionen gleichzeitig angegeben werden können. Beim Datenarten-Vortrag werden daraus entsprechende Controllingsalden sowie ggf. auch IC-Kontensalden erzeugt.
Die Übersichten Belege (BEL) und Buchungen (BUCH) geben bei Selektion nach Konzernkreis in einem Meldungsfenster eine Liste der Gesellschaften aus, für die Belege bzw. Buchungen vorliegen, aber der jeweilige Benutzer keine Ansichtsrechte besitzt, so dass sie nicht angezeigt werden.
Die Hinweismeldung, dass ein Beleg Buchungen auf statistischen Konten enthält, wurde ersatzlos gestrichen.
In der Übersicht "Buchungen" (BUCH) wird die Spalte für den Buchungsschlüssel analog zu den Konsolidierungsbuchungen (KONBUCH) jetzt weiter vorne angezeigt, so dass sie ohne Blättern zu sehen ist.
Beim Erfassen einer Buchung auf einem Konto für einen automatischen Spiegel (z.B. 'S9') wird jetzt automatisch der Buchungsschlüssel für laufende Veränderungen (Verwendungskennzeichen 'L') eingestellt.
Bei der automatischen Berechnung der laufenden AfA werden jetzt auch angebrochene Monate immer voll berücksichtigt. D.h. für den Monat der Anschaffung eines Anlagenobjekts wird eine AfA unabhängig vom Tag der Anschaffung berechnet. Bisher wurde dieser Monat nur dann berücksichtigt, wenn der 1. des Monats als Anschaffungsdatum angegeben war. Dies betrifft die AfA-Berechnung sowohl im Einzelabschluss als auch im Konzernabschluss.
Bei Angabe einer festen jährlichen Abschreibung (AfA-Art = 'F') wird jetzt auch das Anschaffungsdatum berücksichtigt. Liegt das Anschaffungsdatum nach Ende der aktuellen Periode, wird für die aktuelle Periode keine AfA berechnet und gebucht.
Nach dem Speichern von erfassten Aufrissdaten erfolgt eine Plausibilitätsprüfung der Daten. Das Ergebnis dieser Prüfung wird jetzt in einem Meldungsfenster angezeigt, sofern es nicht fehlerfrei war.
Die Formularerfassung von Kontensalden für mehrere Geschäftsbereiche oder für mehrere Perioden (z.B. Plandaten) ist jetzt in einer Maske möglich. Dazu dienen die beiden neuen Spaltenoptionen 'U' (für Geschäftsbereiche) und 'P' (für Perioden).
Bei Spaltenoption 'U' wird je Geschäftsbereich eine eigene Eingabespalte angezeigt. Die Menge der Geschäftsbereiche wird aus der Tabelle für Gesellschafts-/Geschäftsbereichs-Zuordnungen (GESUBR) ermittelt. Die Eingabe im Feld "Geschäftsbereich" wird nicht ausgewertet.
Bei Spaltenoption 'P' ist eine Vorperiode sowie ein Periodenabstand (in Monaten) anzugeben. Aus diesen Angaben werden dann (wie im Periodenreport) die eingebbaren Perioden ermittelt, die natürlich in den Perioden (ABR) definiert sein müssen.
Die Formularerfassung von Spiegelbewegungen (Anlagen-, Kapital-, Rückstellungs- und individuelle Spiegelbewegungen) mit der Spaltenoption 'FS' (lt. BSL spaltenweise) ist jetzt auch dann möglich, wenn für einen Buchungsschlüssel für ein Konto bereits mehr als eine Bewegung existiert. In der zugehörigen Zelle wird der saldierte Wert dieser Bewegungen angezeigt. Allerdings ist eine Änderung dieses Wertes nicht möglich, da es keine eindeutige Zuordnung zu einer Bewegung gibt.
Die Funktionen zur Schnellerfassung, die bisher in den Übersichten "Kontensalden" (KTOSAL), "IC-Unterkontensalden" (ICKTOSAL) und "Controllingsalden" (CNTSAL) enthalten waren, wurden deaktiviert, da diese Funktionalität durch die Formularerfassung übernommen wurde.
U.a. aufgrund der Neugestaltung der zentralen Bezeichnungstabelle haben sich folgende Import-Formate (Möglichkeiten bezgl. Feldern in IEFDEF sowie Zuordnungen im Standardformat #TXT in IEFFEL) geändert:
In der Übersicht "Umsetzgruppen Zuordnungen" (UMSOBJ) ist jetzt eine Selektion der Daten nach "ab Änderungsdatum" möglich.
In der Tabelle der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) werden jetzt nur noch die Zeilen angezeigt, für die der Benutzer die Berechtigung zum Aufruf der jeweilgen Importanwendung hat. Bisher erfolgte die Berechtigungsprüfung nur auf Ebene der Knoten der Baumdarstellung.
Infolge der Unicode-Umstellung wurde die Protokollausgabe für den Import neu gestaltet:
Der Import von Kontensalden ohne vorheriges Löschen arbeitet jetzt grundsätzlich im "Update-Modus". D.h. der Import von Kontensalden für eine Gesellschaft ist auch dann möglich, wenn es bereits Kontensalden für diese Periode und Datenart gibt. Somit ist es möglich, z.B. die Kontensalden für Bilanz, GuV sowie Anhangsdaten nacheinander aus getrennten Quellen zu übernehmen. Ist ein Kontensaldo bereits vorhanden, so wird er jetzt überschrieben.
Einziges mögliche Problem dieser Steuerung ist, dass bereits vorhandene Kontensalden nicht gelöscht werden, wenn dieser Saldo bei einer erneuten Übernahme fehlt. In diesem Fall (mehrfache Übernahme der Salden für gleiche Konten) sollte die Funktion "Löschen Daten und Neu-Import ..." verwendet werden, wie dies ja auch bisher notwendig war.
Im Eingabefeld "Mit Vortrag" der Aufrufanwendung "Datenimport und -anzeige" (IMPORT) kann jetzt als neue Ausprägung auch ein '-' ("Keine Vorträge importieren") eingegeben werden. Ist dieses Feld mit '-' belegt, so werden die in der Importdatei enthaltenen Datensätze für automatische Periodenvorträge (Buchungsschlüssel mit Verwendungskennzeichen 'V', 'SV', 'M' oder 'SM') nicht mehr verarbeitet. Somit kann ein in IDL Konsis erfolgter Periodenvortrag nicht durch die importierten Daten verändert werden. Diese Änderung betrifft alle Importanwendungen für Spiegelbewegungen (Anteilsbesitz-, Anlagen-, Kapital-, Rückstellungs- und individuelle Spiegelbewegungen).
Die übrigen Schalterstellungen ('X' = "Mit Vortrag" bzw. leer = ohne Vortrag) wirken dagegen wie bisher nur bei der Aktion "Löschen Daten und Neu-Import ..." auf das Löschen vorhandener Daten vor dem Import: Bei 'X' werden alle Daten gelöscht, bei leer werden Daten für den automatischen Vortrag vom Löschen ausgenommen und bleiben erhalten.
Der automatische Eintrag eines Geschäftsbereichs, wenn dieser in den Eingangsdaten fehlt, wurde für alle Anwendungen, in denen Geschäftsbereiche verarbeitet werden, wie folgt überarbeitet:
Der automatische Eintrag eines IC-Geschäftsbereichs, wenn dieser in den Eingangsdaten fehlt, wurde für alle Anwendungen, in denen IC-Geschäftsbereiche verarbeitet werden, wie folgt überarbeitet:
Buchungen auf Spiegelkonten (nur Spiegel mit Vortrag) sowie ergebniswirksame Buchungen werden jetzt auch bei Buchungsart 'E' (Einmalbelege) des Belegs vorgetragen (s.o.). Zusätzlich erfolgt eine Gegenbuchung auf dem gleichen Konto mit dem Buchungsschlüssel für laufende Veränderungen (Verwendungskennzeichen 'L' oder 'N').
Vorgetragene Buchungen werden jetzt nicht mehr grundsätzlich mit der Umrechnungsanweisung 'VKW' (vorgegebene Konzernwährung) versehen, sondern nur noch dann, wenn sie auch in der Vorperiode die Umrechnungsanweisung 'VKW' aufwiesen.
Beim Vortrag auf die nächst höhere Datenart wird geprüft, ob dort bereits Daten vorliegen. Bei Bestätigung der zugehörigen Warnung wurden bisher alle bereits vorhandenen Daten einschließlich der Periodenvorträge gelöscht. Künftig wird jetzt abgefragt, ob evt. vorhandene Periodenvorträge (aus Spiegeln) erhalten bleiben sollen. Es gibt dann folgende Reaktionsmöglichkeiten:
Beim Vortrag der IC-Kontensalden wird neben den Attributen Referenzbeleg-Nummer und Referenzbeleg-Datum auch das Auszifferungskennzeichen in die nächste Datenart übernommen. D.h. ein manuell oder maschinell gesetztes Auszifferungskennzeichen durch eine IC-Saldenabstimmung im Einzelabschluss wirkt auch auf Konzernebene.
Die Anwendung "Abgleich Ges.Abschluss neue Datenart" (aufrufbar aus dem Einzelabschluss-Monitor EA) erzeugt jetzt für das Ergebnis ihrer Prüfung einen Satz in der Verarbeitungssteuerung (VERARB) mit dem Checkpoint "SIMVOR". Die dort eingetragene Meldung bestimmt die zugehörige neue Statusanzeige in EA.
Beim globalen Löschen von Kontensalden (Aktion im Einzelabschluss-Monitor EA) wird jetzt auch ein zugehöriger Herkunftsnachweis mitgelöscht, da der Herkunftsnachweis ohne das Ergebnis keine Bedeutung mehr hat.
Konsolidierungsbuchungen auf Spiegelkonten (nur Spiegel mit Vortrag) sowie ergebniswirksame Konsolidierungsbuchungen werden jetzt auch bei Buchungsart 'E' (Einmalbelege) des Belegs vorgetragen (s.o.). Zusätzlich erfolgt eine Gegenbuchung auf dem gleichen Konto mit dem Buchungsschlüssel für laufende Veränderungen (Verwendungskennzeichen 'L' oder 'N').
Mit der neuen Buchungsart 'EP' (einmalig in dieser Periode) können Konsolidierungsbelege gekennzeichnet werden, die beim Vortrag aus einem Zwischenabschluss (Monat, Quartal) nicht in die Folgeperiode vorkopiert werden sollen.
Beim Kopieren von Konsolidierungsbuchungen für einen reporttechnischen Teilkonzern (Aufrufanwendung REPKTK) werden jetzt auch Konsolidierungsbuchungen für Gesellschaften kopiert, die nicht konsolidiert werden (Konsolidierungsart 'K' im reporttechnischen Teilkonzern). Anwender, die dies nicht wünschen, müssen die betreffenden Gesellschaften ganz aus dem Konzernkreis des reporttechnischen Teilkonzerns entfernen.
In der Übersicht "Währungsumrechnung KW+PW" (WUM) führt ein Doppelklick auf die Spalten für die Umrechnungsdifferenzen (Bilanz oder GuV) jetzt direkt zur Übersicht "Konto-Umrechnungsnachweis" (KTOUMR). Die Anzeige erfolgt je nach Spalte eingeschränkt auf Bilanz- oder auf GuV-Konten, ggf. auch für die Vorperiode.
Beim Mengen-Kopieren von Währungsumrechnungs-Kopfsätzen auf eine andere Periode wird die Vorperiode jetzt als letzter Jahresabschluss (Periodenkennzeichen = 'J' in ABR) vor der neuen aktuellen Periode ermittelt und eingestellt. Dies gilt auch für das Kopieren (Erfassen mit Vorlage) in der Einzelsatzanwendung (WUME).
Beim Kopieren von Währungsumrechnungs-Kopfsätzen (Übersicht und Einzelsatz) werden jetzt auch die zugeordneten Konto-Umrechnungsanweisungen (KTOUAW) mitkopiert.
Bei Änderung des Umrechnungsverfahrens erfolgt die Aktualisierung der Konto-Umrechnungsanweisungen jetzt differenziert. D.h. bei Änderung des KW-Umrechnungsverfahrens werden nur die KW-Umrechnungsanweisungen aktualisiert, bei Änderung des PW-Umrechnungsverfahrens nur die PW-Umrechnungsanweisungen.
Für die Währungsumrechnung kann jetzt optional eine abweichende Vordatenart verwendet werden. Wie die Vorperiode kann diese Vordatenart im Umrechnungs-Kopfsatz (WUME) eingetragen werden und wird im zugehörigen Verarbeitungssteuerungssatz (VERARB zum Checkpoint WUM) gespeichert. Dort wird sie auch maschinell bei einem Periodenvortrag (PERGES) mit abweichender Vordatenart eingetragen. Die Währungsumrechnung selbst sowie die Anzeige der Konto-Umrechnungsdifferenzen (KTOUMR) verwenden dann bei der Ermittlung der Vorperiodenwerte auch die Vordatenart.
Eine Währungsumrechnung ist jetzt auch möglich, wenn es für eine Gesellschaft keine Kontensalden gibt, sondern nur Aufrissdaten, die aber jeweils auf null saldieren. Zu den vorhandenen Aufrissdaten wird wie bisher ein Kontensaldo mit Nullwerten erzeugt. Sind die Kontensalden fehlerhaft (Status <rot>), ist weiterhin keine Währungsumrechnung möglich.
Die Währungsumrechnung für Anteilsbesitzbewegungen (GESGES) auf Konten mit historischer Umrechnung (Umrechnungsanweisung FDK) erfolgt jetzt differenziert nach IC-Gesellschaft entsprechend einem parallelen Aufriss für Anlagenbewegungen (ANLBEW), vorausgesetzt die Anlagenbewegungen sind vollständig (und konsistent zu den Anteilsbesitzbewegungen) mit Angabe der IC-Gesellschaft versehen. Bisher wurde in diesem Fall der Kurseffekt der Anteilsbesitzbewegungen immer nur der ersten IC-Gesellschaft zugeordnet.
Wird ein Beteiligungskonto nicht historisch umgerechnet, dann werden die Kurseffekte auf den Vortrag jetzt ebenfalls nach IC-Gesellschaft differenziert ermittelt und gespeichert.
Die Währungsumrechnung unterstützt jetzt auch die historische Umrechnung eines Beteiligungskontos, wenn dieses einem individuellen Spiegel statt wie meist üblich dem Anlagenspiegel zugeordnet ist. Die historische Umrechnung bezieht sich in diesem Fall auf den individuellen Spiegel. Die Konsistenz zwischen Beteiligungen und individuellem Spiegel in Landeswährung ist vom Anwender selbst zu gewährleisten.
Die Abstimmung der umgerechneten Werte zwischen IC-Kontensalden und Controllingsalden wurde auf die zusätzlichen Controlling-Dimensionen ausgedehnt.
Die Umrechnungsanweisung 'PDK' wird für das Jahresergebnis-Konto (Kontokennzeichen 'E') nur noch dann ausgewiesen, wenn die GuV-Differenzen auf Bilanzkonten verrechnet werden und die GuV-Kontensalden alle einheitlich mit dem Periodendurchschnittskurs (PDK) umgerechnet wurden.
Neben den Kurseffekten für historisch umgerechnete Konten (Umrechnungsanweisung 'FDK') werden jetzt auch Kurseffekte für GuV-Konten mit Umrechnungsanweisung ungleich 'SK' in den Konto-Umrechnungsnachweis (KTOUMR) geschrieben. Somit kann auch die GuV-Umrechnungsdifferenz auf die Konten verteilt betrachtet werden. Ein Doppelklick in der Übersicht WUM auf die Zellen für Umrechnungsdifferenzen sorgt für eine entsprechende Verzweigung in den Konto-Umrechnungsnachweis.
Ist ein Konto für Differenzen aus dem Umrechnungs-Kopfsatz (WUM) einem automatischen individuellen Spiegel (z.B. 'S9') zugeordnet, so wird jetzt zu dem auf diesem Konto erzeugten Saldo auch eine passende Spiegelbewegung erzeugt. Diese Bewegung erhält den Buchungsschlüssel für Umrechnungsdifferenz (Verwendungskennzeichen 'U').
Die für die Differenzkonten erzeugten (Kapital-)Bewegungen erhalten jetzt einen Buchungstext ("Diff. GuV aktuelle Periode", "Diff. Bil aktuelle Periode" oder "Vortrag Diff. Bil Vorperiode").
Ggf. (s.o.) für GuV-Konten ermittelte Kurseffekte (Differenz zwischen Periodendurchschnittskurs/PDK und Stichtagskurs/SK) werden jetzt im Konto-Umrechnungsnachweis angezeigt. Für GuV-Konten werden aber keine Vorperiodendifferenzen ausgewiesen.
Enthält eine vorgetragene Konsolidierungsbuchung die Umrechnungsanweisung 'VPW' (vorgegebene Parallelwährung), das Konto aber die PW-Umrechnungsanweisung 'SK' (Stichtagskurs), so wird jetzt analog zum Einzelabschluss eine zusätzliche Konsolidierungsbuchung auf diesem Konto mit der PW-Differenz aus dem vorgetragenen PW-Wert und der Umrechnung des KW-Wertes zum aktuellen SK erstellt. Der KW-Wert bleibt null. Diese Buchungen sind u.a. an ihrem Buchungstext ("PW-Kurseffekt auf Vortrag") erkennbar.
Für Spiegelkonten wird dazu der Buchungsschlüssel für Kurseffekte (Verwendungskennzeichen 'K') oder, falls nicht vorhanden, der Buchungsschlüssel für Umrechnungsdifferenzen (Verwendungskennzeichen 'U') verwendet. Im Anlagenspiegel wurde zu diesem Zweck der Buchungsschlüssel '30' für den Spiegelbereich 'B' (Abschreibungen) eingerichtet. Für Spiegel mit Schattenrechnung wird nach Ursprungs-BSL differenziert: 'U'-BSL für den eigentlichen Spiegel, 'K'- oder 'D'-BSL für die Schattenrechnung, 'SK'- oder 'SD'-BSL für die Stornierung der Schattenrechnung.
Die relevanten Vortragsbuchungen werden daran erkannt, dass sie in einem Vortragsbeleg (KVA = 'KF', 'KV', 'KW' oder 'Vx') stehen und den Buchungsstatus '1' (automatisch erzeugte Buchung) haben. Die Gegenbuchung erfolgt summarisch pro Buchsatznummer als ein Wert auf dem Währungsdifferenzkonto für PW laut WUM-Kopfsatz der Gesellschaft bzw. der Referenzgesellschaft.
Die so erzeugten Konsolidierungsbuchungen für Kurseffekte werden beim Periodenvortrag mit den Ursprungsbuchungen zusammengefasst, so dass sich die Anzahl der Buchungen nicht von Jahr zu Jahr erhöht.
Im Aktionsmenü (Submenü <Übersichten>) der Anwendung Konzernkreisübersicht + Konzern-Monitor (KTKGES) wurde die neue Anwendungen "Kontensalden und Konsolidierungsbuchungen" (KONSAL) (s.o.) ergänzt.
Nicht konsolidierte Gesellschaften (Konsolidierungsart 'K') wurden bisher in mehrstufigen Konzernen immer der obersten Ebene (Weltkonzern) zugeordnet. Dies diente für den Fall, dass die Gesellschaft in mehreren Teilkonzernen enthalten ist und sich nicht eindeutig zuordnen lässt. Ist die Gesellschaft nur in einem Zweig zugeordnet, dann erfolgt jetzt der Ausweis auch in diesem Zweig.
Der Status 'T' (Konsolidierungsverarbeitung im Teilkonzern) wird jetzt (bei Einstellung von Farben in der Tabelle) nicht mehr auf grünem, sondern auf weißem Grund angezeigt, denn dieser Status sagt nur aus, dass die Verarbeitung im Teilkonzern zu erfolgen hat, aber nicht, ob sie tatsächlich bereits erfolgt ist.
Bei Aufruf der Folgeanwendung "Kontensalden" (KTOSAL) wird jetzt der aktuelle Konzern/Tk als Parameter übergeben, so dass bei Selektion einer quotalen Gesellschaft auch die Kontensalden quotiert angezeigt werden.
Für die überarbeitete Funktion Fortschreibung Equity gibt es zwei neue Konsolidierungsparameter 'EF' (Equity-Fortschreibung laufende Veränderungen) und 'EN' (Equity-Fortschreibung negativer Wertansatz) mit entsprechenden Konten (detaillierte Beschreibung s.o.). Der Konsolidierungsparameter 'EK' enthält nur noch diejenigen Konten, die für die Erstkonsolidierung ('EK'), die Folgekonsolidierung ('KF') und die Endkonsolidierung ('KS') von Equity-Gesellschaften benötigt werden.
Durch Ergänzung immer weiterer Konsolidierungsparameter (z.B. 'EF' und 'EN' mit diesem Release) schien es nicht mehr sinnvoll, sämtliche Konten sämtlicher Konsolidierungsparameter in Spalten nebeneinander anzuzeigen. Daher werden jetzt ohne Einschränkung nach Konsolidierungsverarbeitung (leer oder '%') nur noch einige wenige Konten in den Spalten angezeigt, die in mehreren Konsolidierungsparametern verwendet werden, nämlich das Ergebnisvortragskonto und das UB-Interimskonto.
Bei eindeutiger Angabe einer Konsolidierungsverarbeitung (KVA) werden aber weiterhin alle (maximal) 18 Konten und andere Attribute mit spezifischen Überschriften angezeigt. Dies gilt auch, wenn (z.B. durch Eingabe von 'SK') die KVA als Referenz-KVA interpretiert wird und ggf. mehrere KTKPAR-Sätze mit gleicher Kontenbelegung angezeigt werden. Teilqualifizierte Angaben für die KVA (z.B. 'S%') werden nicht mehr zugelassen. Statt 'S%' kann aber auch 'SK' angegeben werden. Controllingobjekte und Buchungsschlüssel werden weiterhin nicht in der Übersicht angezeigt.
Im Konsolidierungsparameter (KTKPAR) 'KK' wurde ein Konto für "Umbuchung Kurseffekte aus Beteiligungen in Fremdwährung" ergänzt (s.u.).
Analog anderen Konsolidierungsparametern ist jetzt auch im KTKPAR 'EK' (Erstkonsolidierung Equity) die Eingabe von Controllingobjekten zu den angegebenen Konten möglich.
Die Beteiligungs- und Statusermittlung prüft nicht nur, ob die Beteiligungsverhältnisse zwischen Welt- und Teilkonzern gleich sind, sondern nun auch, ob die Voraussetzungen für eine Kapital-Konsolidierungsverarbeitung (z.B. durch entsprechende GESGES-Sätze) gegeben sind. Ist dies der Fall, wird wie bisher der Status <T> vergeben. Findet dagegen mangels Daten auch im Teilkonzern keine Verarbeitung statt, wird der Status auch im Weltkonzern nicht auf <T>, sondern auf <-> gesetzt.
Der Status 'KA' für Fremdanteile wird für eine Gesellschaft auf <-> gesetzt, wenn die Gesellschaft nur indirekte Fremdanteile hat und der Schalter "ohne indirekte Fremdanteile" (in KTKGESE) gesetzt ist.
Hat eine Gesellschaft den KA-Status <->, weil keine relevanten Daten vorhanden sind und daher kein Beleg erzeugt wurde, dann wird dieser Status durch eine erneute Beteiligungs- und Statusermittlung nicht mehr verändert.
Der Status 'KA' wird auf <rot> gesetzt, auch wenn auf der aktuellen Konzernebene keine Fremdanteile bestehen, wenn in dem darunterliegenden Teilkonzern Fremdanteile bestanden, die auf der aktuellen Ebene zu stornieren sind.
Für Beteiligungen (GESGES) wurde ein neuer Buchungsschlüssel (BSL) '13' eingeführt. Er beschreibt Kurseffekte für den Fall, dass die Beteiligung in einer Fremdwährung gehalten wird (z.B. Buchwert der Anteile an einem Fond). Die Kurseffekte muss der Anwender jährlich im Einzelabschluss auf dem Beteiligungskonto mit diesem BSL melden. Ein GESGES-Satz mit BSL '13' darf keine Prozentsätze enthalten.
Ein GESGES-Satz mit diesem BSL führt zu einem roten Status 'KK' in KTKGES durch die Beteiligungs- und Statusermittlung. Im Konsolidierungsparameter (KTKPAR) 'KK' wurde ein Konto für "Umbuchung Kurseffekte aus Beteiligungen in Fremdwährung" ergänzt.
Ist ein GESGES-Satz mit BSL '13' vorhanden und das neue Konto im KTKPAR angegeben, dann erstellt die Erstkonsolidierung im KK-Beleg im Buchungssatz '01' ein Buchungspaar. Die eine Buchung eliminiert den GESGES-Satz mit BSL '13', die Gegenbuchung erfolgt auf dem neuen KTKPAR-Konto. Dies erfolgt sowohl bei der maschinellen als auch bei der manuellen Erstkonsolidierung, wobei im manuellen Fall die Beträge änderbar sind.
Die KK-Spiegelumbuchung (Umbuchung der Einzelabschluss-Vorträge in die Spalte Zugang Konzernkreis) wird nicht mehr durchgeführt, wenn in der aktuellen Periode eine Anteilsbesitzbewegung (GESGES) mit Buchungsschlüssel '04' (manuelle Einstellung des Vortrags) existiert, da die Gesellschaft dann gar nicht neu im Konzernkreis ist.
Die Fortschreibung Equity (EF) wurde um eine Reihe von Eingabemöglichkeiten erweitert und neu gestaltet (s.o.).
Vor Durchführung der Schulden- oder Aufwands-/Ertragskonsolidierung wird jetzt geprüft, ob für Gesellschaften mit abweichender Landeswährung eine fehlerfreie Währungsumrechnung durchgeführt wurde. Ist dies nicht der Fall, wird die Konsolidierung nicht durchgeführt. In den IC-Clearing-Satz (KGESGES) wird eine entsprechende Meldung eingetragen. Die Prüfung bezieht sich sowohl auf die selektierte Gesellschaft als auch auf die in den IC-Kontensalden angegebenen IC-Gesellschaften.
Bei der Schulden- und Aufwands-/Ertragskonsolidierung wie auch bei der IC-Saldenabstimmung der Einzelabschlüsse wird für stimmige Daten das Auszifferungskennzeichen maschinell gesetzt (s.o.). Außerdem werden alle KW-Differenzen aus der Summe aller mit dem gleichen manuellen Auszifferungskennzeichen versehenen IC-Salden als Kursdifferenz behandelt und in einer Buchungssatznummer des SK/AE-Belegs verbucht, wenn die beiden betrachteten Gesellschaften unterschiedliche Landeswährungen haben, auch wenn die IC-Salden keine TW-Angaben enthalten.
Sind für einen IC-Saldo die Währungskennzeichen der Landeswährung von Gesellschaft und IC-Gesellschaft, der Konzernwährung und der angegebenen Transaktionswährung gleich und ist auch der TW-Betrag gleich dem LW/KW-Betrag, dann wird der TW-Wert nicht weiter berücksichtigt. Auf diese Weise sind jetzt auch IC-Salden zwischen zwei Konzernwährungsgesellschaften abstimmbar, wenn die eine Gesellschaft die IC-Salden mit, die andere Gesellschaft aber ohne Transaktionswährung meldet. Differenzen werden immer als Sachdifferenzen gemeldet, da es in diesen Fällen keine Kursdifferenzen geben kann.
Die Schulden- und Aufwands-/Ertragskonsolidierung übernimmt die Angaben für Controllingobjekte zu den zusätzlichen Controlling-Dimensionen aus den IC-Kontensalden in die daraus generierten Konsolidierungsbuchungen.
Die Tabelle für Konsolidierungsbuchungen wurde analog zu den Controllingsalden um Attribute für weitere Controllingobjekte erweitert, so dass unter gewissen Voraussetzungen in der Einzelsatzanwendung KONBUCHE bis zu 10 Controllingobjekte zu verschiedenen Controlling-Dimensionen gleichzeitig angegeben werden können.
Bei der Verprobung der Konsolidierungsbuchungen wird jetzt auch geprüft, ob die Buchungen die gemäß Kontenstamm (KTO) erforderlichen Angaben für Controllingobjekte enthalten. Wenn nicht wird dies gemeldet und auch eine Meldungsnummer in den Belegkopf eingetragen. Ausgenommen von dieser Prüfung sind die Konsolidierungsbelege für Spiegelumbuchungen (Konsolidierungsverarbeitungen KU, SU, FU, QU, s.u.).
Die Hinweismeldung, dass ein Konsolidierungsbeleg Buchungen auf statistischen Konten enthält, wurde ersatzlos gestrichen.
Die bereits für Einzelabschluss-Belege (BEL) verfügbare Buchungsart 'EP' (einmalig in Zwischenperiode) steht jetzt auch für manuelle Konsolidierungsbelege (KONBEL) zur Verfügung. Derartige Belege werden beim Konzernvortrag nicht aus einer Zwischenperiode (Monat oder Quartal) in die nächste Zwischenperiode vorkopiert.
Zu den Konsolidierungsbelegen und -buchungen können jetzt längere Beschreibungen ("Hilfetexte") hinterlegt werden (s.o.).
Die in der Reportergebnisanzeige (REPERG) eingebbare Objektsortiervorgabe (für die Darstellung der ersten Aufrissstufe in Spalten) kann jetzt durch eine entsprechende Angabe im Report-Kopfsatz (REPE) vorbelegt werden.
Ein weiteres neues Eingabefeld für den Report-Kopfsatz (REPE) dient der Steuerung zur Erzeugung von Reports mit dekumulierten Werten (s.u.).
Bei dieser Gelegenheit wurde der Aufbau der Einzelsatzmaske (REPE) überarbeitet. U.a. haben jetzt auch die Eingabefelder für Einschränkung und Schlüsselanzeige eigene Prompttexte.
In den Übersichten für Report-Kopfsätze (REP, REPK) wurden die Eingabefelder für Aufrissoption, Schlüsselanzeige und Spaltenoption entfernt. Diese Felder dienten der Vorbelegung der entsprechenden Felder bei Verzweigung in die Reportergebnisanzeige. Dies wird jedoch inzwischen i.d.R. über die Attribute des betreffenden Report-Kopfsatzes gesteuert.
In diesen Übersichten (REP, REPK) werden die Spalten für Konzern- und Parallelwährung (Währungskennzeichen, Prüfsummen etc.) nicht mehr angezeigt, wenn die Umrechnung in diese Währungen in der Datenart (FAC) ausgeschaltet ist. Hier wie auch bei der Reporterstellung werden entsprechende Hinweismeldungen unterdrückt.
Die Funktion "Generieren Report-Kopf in alle GES" erzeugte aus einem Konzern-Report-Kopfsatz analoge Report-Kopfsätze für alle im Konzernkreis enthaltenen Gesellschaften. Diese Funktion wurde jetzt dahingehend erweitert, dass einerseits keine Report-Kopfsätze mehr für Gesellschaften mit Konsolidierungsart 'K' (keine) und 'E' (Equity) erzeugt werden.
Andererseits werden jetzt auch Report-Kopfsätze für alle untergeordneten Teilkonzerne erzeugt (neue Bezeichnung der Funktion daher "Generieren Report-Kopf in alle Ges. und Tk").
Die beiden Reportergebnisanzeigen "Report" (REPERG) und "Report gespiegelt" (REPERGS) lassen sich jetzt gegenseitig via Aktionsmenü aufrufen.
Im Aktionsmenü wurde die Aktion "Aufriss Salden und Bewegungen + Buchungen" ergänzt. Diese Aktion verzweigt je nach Art des Reports und der Aufrissebene in die neue Anwendung "Kontensalden und Konsolidierungsbuchungen" (KONSAL) oder "Bewegungen und Konsolidierungsbuchungen" (KONBEW) (s.o.) zur Analyse der Werte der jeweiligen Zeile.
Wird auf einer Zeile für ein Konto des IC-Vorratsvermögens (Kontokennzeichen = 'V') die Aktion "Restwertanalyse" aufgerufen, so erfolgt jetzt eine Verzweigung in die Übersicht "Vorratsvermögen IC-Bestände" (ICBEW). Zwar werden diese Konten durch die Zwischenergebniseliminierung im Umlaufvermögen (ZU) nicht leergeräumt, jedoch kann es zu keinen Überschneidungen kommen, da auch die übrigen Verzweigungen der Restwertanalyse (IC-Kontensalden/ICKTOSAL, Anteilsbesitzbewegungen/GESGES) auf dem Kontokennzeichen ('I' bzw. 'B') basieren.
Reportergebnisse belegen relativ viel Speicherplatz in der Datenbank. Um den Umfang einer Datenbank zu reduzieren, mag es sinnvoll sein, Reportergebnisse früherer Perioden zu löschen. Dazu dient eine neue Funktion, die als Folgeanwendung aus den Übersichten für Report-Kopfsätze (REP, REPK, REPSTR) heraus aufgerufen werden kann. Es wird nur das Reportergebnis gelöscht, nicht der Report-Kopfsatz, so dass der Report bei Bedarf einfach neu erstellt werden kann. Achtung: Das selbe Ergebnis resultiert nur dann, wenn sich die zugrundeliegenden Strukturen (Report-Zeilenbeschreibung, Positions-Konten-Zuordnung) in der Zwischenzeit nicht verändert haben. Beachten Sie bitte auch den Hinweis zu Konzern-Reports.
Werden mehrere Reports mit der Report-Option 'S' (Schreiben von Positionsalden) versehen, dann kann es sein, dass ein Report die von einem anderen Report geschriebenen Positionssalden überschreibt, wenn beide Reports dieselbe Position enthalten. Abhängig von der Report-Definition können dies verschiedene Werte sein. Um zumindest zu vermeiden, dass ein echter Wert durch einen Nullwert überschrieben wird, werden künftig keine Positionssalden mehr für Positionen auf Reportzeilen mit den Zeilentypen 'E', 'F' oder 'R' geschrieben, sondern nur noch für Positionen auf Reportzeilen mit den Zeilentypen 'P' oder 'S'.
Es ist jetzt eine Reportdarstellung möglich, in der über mehrere Monate hinweg ein Plan/Ist-Vergleich je Monat dargestellt wird (z.B. Planwert / Istwert / Abweichung absolut / Abweichung prozentual). Für diese Darstellung wurde der neue Reporttyp 'S' geschaffen. Report-IDs dieses Typs können auf eine andere Report-ID (z.B. vom Reporttyp 'E') referenzieren (Anwendung RID), damit keine redundante Erfassung von Report-Zeilenbeschreibungen erforderlich ist.
Dieser Reporttyp unterstützt bis zu 12 Perioden. Je Periode werden Daten der aktuellen und der Vergleichsdatenart verarbeitet und getrennt nach Salden und Buchungen im Reportergebnis gespeichert (d.h. bis zu 48 Wertspalten). Die Vergleichsdatenart 2 hat bei diesem Reporttyp keine Bedeutung. Ansonsten erfolgt die Verarbeitung analog zum Periodenreport (Reporttyp 'P').
Zur Anzeige derartiger Reports wurden die neuen Standard-Spaltenoptionen #ALTS, #BUCS, #KONS, #KTKS, #NEUS und #SUMS eingerichtet.
Bisher wurden immer nur kumulierte Werte (ab Beginn des Geschäftsjahres) in den Reportergebnissen gespeichert. Eine dekumulierte Darstellung von reinen Monatswerten war nur durch spezielle Spaltenoptionen möglich, in denen der Wert des Vormonats vom Wert des jeweiligen Monats subtrahiert wird. Dieses Verfahren hat u.a. den Nachteil, dass die Spaltenoptionen immer die gleiche Anzahl von Perioden und die gleiche Position des Jahresabschlusses in der Folge der Perioden voraussetzen.
Jetzt ist es möglich, ein Reportergebnis mit dekumulierten Werten direkt bei der Reporterstellung zu erzeugen. Hierzu dient ein neues Eingabefeld "Steuerung der Dekumulierung" im Report-Kopfsatz (REP/REPK). Folgende Eingaben sind hier möglich:
Diese Steuerung für die Dekumulierung ist möglich für Periodenreports (Reporttypen 'P' und 'S') sowie für Bilanz/GuV-Reports (Reporttyp 'E'). Bei Bilanz/GuV-Reports muss dann zusätzlich ein Periodenabstand angegeben werden, der den Abstand zur Dekumulierungsperiode bestimmt.
Ist die Vorperiode einer Periode ein Geschäftsjahresabschluss, darf keine Subtraktion erfolgen, da die Kumulierung immer ab Geschäftsjahresbeginn erfolgt. Der Geschäftsjahresabschluss wird am Periodenkennzeichen im Periodenstamm (ABR) erkannt. Ein 'J' kennzeichnet die Jahresabschlussperiode und damit die letzte Periode des Geschäftsjahres. Gesellschaften mit abweichendem Geschäftsjahreswechsel sollten dabei kein Problem darstellen, da ihre Werte ohnehin nach dem Geschäftsjahr des Konzerns kumuliert werden müssen, damit ein konzerneinheitlicher Jahresabschluss möglich ist.
Die Dekumulierung erfolgt unabhängig vom Bilanz/GuV-Kennzeichen des Kontos oder der Position, also auch für die Bilanz, obwohl i.d.R. eine dekumulierte Darstellung nur für die GuV benötigt wird.
Um bei Bilanz/GuV-Reports eine gleichzeitige Darstellung dekumulierter und kumulierter Werte zu ermöglichen, werden die dekumulierten Werte in den Ergebnisspalten 01 bis 24 gespeichert, parallel dazu die kumulierten Werte in den Ergebnisspalten 25 bis 48. Die Anzeige muss dann über entsprechende Spaltenoptionen erfolgen.
Konzern-Bilanz- und GuV-Reports können jetzt (HB I / HB II-)Buchungen (BUCH) und Konsolidierungsbuchungen (KONBUCH) gleichzeitig verarbeiten, vorausgesetzt diese liegen auf unterschiedlichen Datenarten vor, z.B. Buchungen auf Datenart I3, Konsolidierungsbuchungen auf Datenart I4.
Liegen auf einer Datenart beiderlei Daten vor, werden nur die Konsolidierungsbuchungen verarbeitet. D.h. Buchungen werden nur dann verarbeitet, wenn es auf derselben Datenart keine Konsolidierungsbuchungen gibt.
Die neuen Controlling-Kennzeichen 1 (s.o.) können in Reports für das Umsatzkostenverfahren (Reporttyp 'C') in eigenen Spalten ausgewiesen werden. Die Standard-Spaltenoptionen für diesen Zweck ('#CALT', '#CBUC', '#CKON', '#CKTK', '#CNEU', '#CSUM') wurden entsprechend erweitert.
Bilanz/GuV-Reports verarbeiten jetzt keine Konsolidierungsbuchungen mehr aus den Verarbeitungen für Spiegelumbuchungen (Konsolidierungsverarbeitungen KU, SU, FU, QU). Diese Belege enthalten nur Buchungspaare auf demselben Konto und haben daher für einen Bilanz/GuV-Report keine Auswirkung. Dies betrifft insbesondere Controllingreports (auf Basis von Controllingsalden und Konsolidierungsbuchungen mit der Angabe von Controllingobjekten), denn in diesen Buchungen fehlt in der Regel die Angabe von Controllingobjekten, da sie auf Basis der Einzelabschluss-Bewegungen erzeugt werden, so dass deren Einbeziehung bei der Reporterstellung zu unnötigen Fehlern führen würde.
Der Datenaustausch (konzernweit und Teilkonzern) ist zwischen den IDL Konsis Releases 2007.0 und älteren Releaseständen nicht kompatibel. Dies wird durch eine entsprechende Fehlermeldung gemeldet.
Für den Datenaustausch (konzernweite wie auch Teilkonzerndaten) kann jetzt im Optionsdialog (Seite "Import/Export") ein eigener Pfad angegeben werden. Bisher war der Pfad für den Datenaustausch immer an den Import-Pfad gekoppelt.
Die Tabelle für den Kontensalden- und Kostenstellensalden-Herkunftsnachweis (Anzeige über die Anwendungen KTOHER bzw. KSTHER) wurde im Teilkonzern-Datenaustausch ergänzt. Die Daten werden nur dann nicht übertragen, wenn die Herkunftsdatenart auf der Ebene des Gesellschaftskontenplans ist, die für den Datenaustausch angegebene(n) Datenart(en) aber nicht, so dass keine Konten der Gesellschaftskontenpläne übertragen werden.
Desweiteren wurde auch die Tabelle für Positionssalden (Anzeige über die Anwendung POSSAL) im Teilkonzern-Datenaustausch ergänzt. Die Übertragung erfolgt in Abhängigkeit von der Übertragung der Reportergebnisse (Abfrage beim Entladen). Übertragen werden die Positionssalden für den jeweiligen Teilkonzern und dessen untergeordnete Teilkonzerne sowie für die dem Teilkonzern zugeordneten Gesellschaften.
Außerdem wurde die neuen Tabelle für Prüfregelergebnisse (PRFERG, s.o.) im Teilkonzern-Datenaustausch ergänzt. Die Plausibilitäten müssen daher in der Zentrale nicht erneut geprüft werden.
Fremdschlüsselverletzungen beim Laden von Teilkonzerndaten (z.B. wegen fehlender Stammdaten) werden jetzt detallierter gemeldet und auch in die Protokolldatei geschrieben.
Die neuen Tabellen für Prüfregeln (PRF und PRFPOS, s.o.) wurden im konzernweiten Datenaustausch ergänzt. Die Prüfregeln sollten daher immer konzernweit gelten.
Die Positions-Konten-Zuordnungen (POSKTO) werden beim konzernweiten Datenaustausch immer komplett übertragen unabhängig von einem vorgegebenen Änderungsdatum. Damit keine gelöschten Zuordnungen in der Zieldatenbank erhalten bleiben, werden die Zuordnungen vor der Übernahme gelöscht. Dieses Löschen erfolgte bisher je in den Daten enthaltenem Konzernkontenplan. Künftig erfolgt das Löschen auch je enthaltenem Positionsplan. Dadurch bleiben Zuordnungen auf einen teilkonzernspezifischen Positionsplan, der nicht in der Zentrale gepflegt wird, erhalten.
Die Wechselkurse (WKZWKA, Tabelle K008) gehören beim Datenaustausch zu den konzernweiten Daten, weil das Datenaustauschkonzept davon ausgeht, dass die Kurse zentral gepflegt werden, damit sie konzerneinheitlich sind. Es gibt allerdings Teilkonzerne mit einer abweichenden Konzernwährung, wobei auch in den Teilkonzernen Fremdwährungsgesellschaften vorkommen können. Daher beziehen sich die Wechselkurse im Weltkonzern auf eine andere Konzernwährung als die Wechselkurse im Teilkonzern und dürfen nicht so übernommen werden. Daher ist das Entladen von Wechselkursen jetzt optional und wird in einem eigenen Meldungsfenster nach Start des Exports abgefragt. Ist in den Optionen (Seite "Import/Export") die Option "Meldungsdialog unterdrücken" gesetzt, unterbleibt diese Abfrage und Wechselkurse werden wie bisher entladen.
Die Übertragung von Benutzerdaten (Tabellen "Benutzer"/USE und "Vorbelegung"/VOR) ist jetzt optional im konzernweiten Datenaustausch möglich. Dazu wird der Benutzer in einem Meldungsdialog beim Entladen befragt. Damit ist es möglich, die Benutzer und deren Berechtigungen auch für die Teilkonzerninstallationen zentral zu pflegen und dann zu verteilen. Ist in den Optionen (Seite "Import/Export") die Option "Meldungsdialog unterdrücken" gesetzt, unterbleibt diese Abfrage und Benutzerdaten werden wie bisher nicht entladen.
Bei der Funktion "Löschen archivierter Teilkonzerne" erfolgt jetzt eine zusätzliche Abfrage der selektierten Schlüssel, deren Eingabe in einem Fenster wiederholt werden muss, damit sichergestellt ist, dass nur die "richtigen" Daten gelöscht werden.
Die Erweiterungen am IDL Connector werden separat dokumentiert.
In der IDL-SAP-Schnittstelle wurde eine Funktion zum Auslesen von Kapitalbewegungen ergänzt. Der zugehörige Aufruf mit der Option /f=KAPBEW ist unter dem Menuepunkt UNLKAPBEW einzutragen. Diese Funktion nutzt den Funktionsbaustein Z_GET_ACCRUALS_TRANSACTIONS, der mittlerweile so modfiziert ist, dass aus der Tabelle GLT3 sämtliche Bewegungsdaten ohne Einschränkung übernommen werden können. Um die Anzahl reklamierter Datensätze beim Import zu reduzieren, kann in der kcusap.ini im Abschnitt Settings der Parameter PrefixKapbewBwasl= eingetragen werden, um Kapitalbewegungen zu identifizieren. Die Umsetzung der SAP-Bewegungsarten in IDL Konsis-Buchungsschlüssel erfolgt über Umsetzgruppen (UMSOBJ).
Zu dem Themenbereich
wurde eine anwendungsübergreifende Dokumentationen neu erstellt. Diese Dokumentationen steht zunächst nur in deutscher Sprache zur Verfügung und ist im Ressourcenbaum im Zweig für die Anwendungsfunktionen ("Stamm- und Steuerungsdaten" -> "Prüfregeln") erreichbar. Sie ist nicht als separates pdf-Dokument im doku-Verzeichnis der CD enthalten, diese kann aber bei Bedarf jederzeit über das Symbol <Export als pdf> aus der Hilfetextanzeige generiert werden. Die Anwendungshilfe der zugehörigen Anwendungen (<F2>) enthält einen Verweis auf diese anwendungsübergreifende Dokumentation.
Mit diesem Release werden folgende deutschsprachigen Dokumentationen im doku-Verzeichnis aktualisiert oder ergänzt: