Das Release 5.1.3 ist ein Zwischenrelease und kann daher in der Releasefolge ausgelassen werden. Voraussetzung für das Release 5.1.3 ist das letzte Hauptrelease 5.1.0 vom 7. 10. 2002. Die Nachträge und Korrekturen zum Release 5.1.0 sowie die Zwischenreleases 5.1.1 und 5.1.2 mit ihren Nachträgen und Korrekturen sind im Release 5.1.3 enthalten. Die bereits mit den Releases 5.1.1 und 5.1.2 enthaltenen Änderungen sind in der Dokumentation zum Release 5.1.1 bzw. Dokumentation zum Release 5.1.2 beschrieben.
Zur Erreichung der Kompatibilität mit der Datenbank MS SQL Server erfolgte ein komplettes Redesign der Datenbank-Schnittstelle von IDL Konsis (technische Basis OLE DB). Dies betrifft neben der Anwendung IDL Konsis selbst auch die Hilfesprogramme zum Einspielen von DB-Struktur-Änderungen und Metadaten.
Für diesen neuen Stand ist bei der Datenbank IBM DB2 mindestens das Release 7.2 erforderlich (entspricht 7.1 + Fixpak 3), bei der Datenbank Oracle mindestens das Release 8.1.7. Es ist daher erforderlich, dass die Anwender vor Installation des IDL Konsis-Releases 5.1.3 auf diese Releasestände aufrüsten. Bei Oracle empfehlen wir gleich den Upgrade auf Release 9.0 oder 9.2. Wir weisen daruf hin, dass gemäß Software-Voraussetzungen bei Oracle-Datenbanken Server und Client auf demselben Releasestand sein müssen. Das gleiche gilt für DB2 ab Release 8.1.
Im Test mit DB2 auf einer AS/400 wurde eine deutliche Verschlechterung der Antwortzeiten festgestellt. Sollte sich dies auch im Echtbetrieb bestätigen, besteht in diesem Release noch die Möglichkeit, auf die alte DB-Schnittstelle zurückzustellen. Kontaktieren Sie in diesem Fall bitte die IDL Hotline.
Unter dem Titel "Internet-Client" wurde eine Installations-Variante implementiert, in der die Oberfläche und die Anwendungsschicht auf unterschiedlichen Systemen ablaufen, die durch ein Netzwerk (z.B. Internet) miteinander verbunden sind. Es muss aber darauf hingewiesen werden, dass die Antwortzeiten bei Modem- oder ISDN-Verbindungen nicht zufriedenstellend sind.
Die automatische Installation des IDL Konsis Internet-Clients wird erst ab dem kommenden Release unterstützt. Dann wird auch eine Installationsmöglichkeit über Web-Start möglich sein. Die mit diesem Release ausgelieferte Version ist für die Installation bei Pilotkunden vorgesehen. Die Installation von Datenbank-Software auf dem Client ist nicht mehr notwendig.
Da größere Anwender in der Regel über eine eigene Verschlüsselung der über das Netz übertragenen Daten verfügen, wurde auf eine zusätzliche Verschlüsselung durch IDL verzichtet.
Im Zusammenhang mit dem Internet-Client wurden u.a. folgende Anwendungsfunktionen realisiert:
Die in der Anwendung USE je Benutzer angegebene Sprache war im Zuge der Umstellung auf die neue Benutzeroberfläche durch eine Einstellung im Options-Dialog abgelöst worden und wurde zuletzt nicht mehr verwendet. Jetzt wird diese Angabe wieder verwendet als Defaultwert für die Benutzersprache in verschiedenen Anwendungen, um z.B. die Benennung von Konten in der jeweiligen Landessprache anzuzeigen. Es sind dann auch Angaben für Sprachen (z.B. 'POL' = polnisch) möglich, die im Options-Dialog nicht ausgewählt werden können.
Im Zuge der Reduzierung der Eingabefelder in den Masken (s.u.) wurde die Sprache in Übersichten zu einer optionalen Eingabe. Bei fehlender Eingabe wird die in USE angegebene Sprache verwendet.
Im Options-Dialog sind folgende zusätzliche Einstellungen möglich:
Bei der Ausgabe von Zahlen mit mehr als zwei Nachkommastellen in Tabellenspalten wird die Anzahl der Nachkommastellen jetzt auf die signifikanten Stellen (ungleich null) reduziert. Beispiele für diese Änderung sind die Prozentwerte in KTKGES und GESGES sowie die Wechselkurse in WKZWKA.
In der Symbolleiste ("Toolbar") des Anwendungsfensters wurde ein Symbol ("Icon") für die Druck-Vorschau (Seitenansicht) ergänzt.
In den Fenstern zur Hilfetextanzeige sowie zum Erfassen von Hilfetexten wurde eine Symbolleiste ("Toolbar") ergänzt, u.a. zur vereinfachten Druckausgabe.
Die Anzeige in den Combo-Boxen (Button mit nach unten gerichtetem Pfeil am Eingabefeld) für Eingabewert und Bezeichnung erfolgt jetzt spaltengerecht. Dies macht die Anzeige insbesondere dann übersichtlicher, wenn die Eingabewerte unterschiedliche Länge haben (z.B. Aufriss-Option im Report).
Der IDL Konsis-Menübaum (Ressourcenbaum) enthält einige Menüpunkte, hinter denen sich keine ausführbare Anwendung, sondern nur ein Hilfetext verbirgt (z.B. "Was ist neu im Release 5.1.3 ?" für vorliegenden Text). In diesen Fällen startet ein Doppelklick auf den Menüpunkt die Hilfetextanzeige.
In diesem Zusammenhang muss auch eine automatische Anpassung kundenspezifischer Menüs durch das Release-Konvertierprogramm erfolgen.
Für die unterschiedlichen Objekte im Menübaum (Ressourcenbaum) wurden verschiedene Symbole gewählt:
Im Zusammenhang mit der besseren Unterstützung kundenspezifischer Menüs wurde der Menübaum (Ressourcenbaum) von IDL Konsis umgestaltet. In der Stufe unterhalb von IDL Konsis befinden sich jetzt keine ausführbaren Anwendungen mehr, sondern nur noch untergeordnete Menüknoten. Im einzelnen wurden folgende Änderungen vorgenommen;
Entsprechend wurde auch die Menüstruktur des Projektes Architek bzw. die weitgehend gleiche Struktur des IDL Konsis-Menüpunktes "Systemadministration" durch Submenüs besser strukturiert. Es sind jetzt folgende Submenüs enthalten:
Die Funktion zum Aufbau des Menübaums (Ressourcenbaum) wurde so geändert, dass Menüpunkte, die keine Anwendung, sondern nur eine Dokumentation (Hilfetext) enthalten, immer berechtigt sind. Daher muss u.a. die Berechtigung für diesen Hilfetext für kundenspezifische Berechtigungsgruppen nicht extra erteilt werden.
Falls dies für kundenspezifische Benutzerfruppen nicht gewünscht wird, muss die Berechtigung auf den übergeordenten Menüknoten entzogen werden.
Folgende Menü-IDs sind in diesem Release neu. Falls kundenspezifische Benutzergruppen verwendet werden, müssen für diese Menüpunkte ggfs. Berechtigungen (BENMEN) gepflegt werden. Als Vorlage können i.d.R. die Menüberechtigungen der Benutzergruppe IDLKON dienen.
Für die neue Funktion Schnellerfassung muss für die betreffenden Anwendungen KTOSAL, ICKTOSAL und KSTSAL die Berechtigung zum Einfügen gesetzt werden.
Es ist jetzt auch in der Anwendung VOR (bisher nur in VORADMINE) möglich, die Vorbelegung für einen neuen Benutzer zu erfassen. Hierzu dient die Kopierfunktion der Übersicht, so dass der neue Benutzer immer die gleichen Rechte erhält wie die aktuelle Benutzer.
Die Berechtigungs-Schalter in der Vorbelegung werden in der Anwendung VORADMINE zu Musseingaben, so dass die vergebene Berechtigung leichter ersichtlich ist. Bisher wurde in diesem Fall immer die Berchtigungsstufe '0' (Schlüssel nur lt. Vorbelegungswert) angenommen. Daher erfolgt im Release-Konvertierprogramm eine Umsetzung von Leerwerten in den Wert '0'.
Für die Berechtigung für Perioden wurde der neue Wert '3' eingeführt. Dieser funktioniert im Normalfall wie die Objektberechtigung (Steuerung über BENABR), erlaubt jedoch zusätzlich für abgeschlossene Perioden noch neue Reports zu definieren und diese einmalig zu erzeugen.
Die Stammtabelle für Perioden ABR wird künftig zu einer Pflichttabelle analog anderen Stammdaten. D.h., bevor Daten für eine Periode erfasst werden können, muss zuvor ein Stammsatz für diese Periode angelegt werden.
Zu diesem Zweck erzeugt das Release-Konvertierprogramm ABR-Stammsätze für alle Perioden, die in den Berichtsdaten verwendet werden. Nicht berücksichtigt werden dabei Periodenangaben für die Gültigkeit von Stammdaten. Die Definition von Fremdschlüsseln in der Datenbank zur Sicherstellung dieser Bedingung kann erst in einem späteren Release erfolgen, so dass die Aktion <Löschen> in der Anwendung ABR zunächst nicht zugelassen wird.
Vorteil dieser Änderung ist, dass jetzt alle Eingabefelder für Perioden in diversen Masken mit Auswahlunterstützung versehen sind und dass Falscheingaben in diesen Feldern nicht zur Erfassung von Daten für unsinnige Perioden führen können.
Die Folgeanwendung ABRLOCK, die bisher nur zur Verwendung in Automatensteuerungen definiert war, kann jetzt auch als Folgeanwendung aus ABR heraus aufgerufen werden. Dabei werden in allen BENABR-Sätzen für die ausgewählte Periode die Änderungsberechtigungen entzogen, so dass Daten für diese Periode nicht mehr änderbar sind.
Die Anwendung GES war in der Vergangenheit zu einer Statusübersicht für den Einzelabschluss und zu einer Aufrufanwendung für die zugeordneten Verarbeitungen erweitert worden. Weitere Anforderungen waren nicht mehr mit der Funktion einer Stammübersicht vereinbar, so dass beschlossen wurde, die Anwendung zu teilen in die Stammdatenübersicht (Kurzwort GES) und den Einzelabschluss-Monitor (Kurzwort EA). Selektionsmöglichkeiten, die nur für EA von Bedeutung sind, sind in GES jetzt entfallen. Im Menübaum ist GES nur noch im Menü <Stamm- und Steuerungsdaten> enthalten.
In der Einzelsatzanwendung KTOE wie auch beim Import von Konten wurde eine Prüfung ergänzt, dass Anlagenkonten (Konto-Kennzeichen 2 = 'A') nicht gleichzeitig Abschreibungskonten (Konto-Kennzeichen 1 = 'D') sein dürfen.
Die Prüfung, dass im Gesellschaftskontenplan kein Wechselkonto angegeben werden darf, wurde aufgehoben.
Der Begriff Kostenstelle war zu eng gefasst. Auch bisher wurden unter diesem Schlüssel auch Kostenträger geführt. Es soll daher künftig von Controllingobjekten gesprochen werden. Für diese Controllingobjekte soll eine Klassifizierung erfolgen. Dazu wird das bisher ungenutzte Kostenstellenkennzeichen 2 aktiviert. Dazu wurden die Controllingobjektklassen C (Kostenstellen), T (Kostenträger), X (Profit Center), P (Produkte) und R (Regionen) eingerichtet. Es wird empfohlen, die Controllingobjekte gemäß ihrer Controllingobjektklasse mit verschiedenen Prefices zu versehen. So kann durch Vorgabe des Prefix die Auswahl der Controllingobjekte eingeschränkt werden.
In der Übersichtstabelle der Anwendung AGGKTO wurden vor der Spalte für die Positionsbezeichnung Spalten für Gültig-ab- und Gültig-bis-Periode des Kontos ergänzt.
Im Selektionsbereich wurde eine Selektionsmöglichkeit nach der Gültigkeit des Kontos ergänzt. Eingaben in den neuen Eingabefeldern für Gültig-ab- und -bis-Periode werden analog den Stammübersichten KTO, AGG und KST interpretiert.
Beim Mengen-Kopieren wird jetzt für den Ziel-Kontenplan nur noch die Leseberechtigung benötigt. Die Schreibrechte werden nur noch für den Positionsplan geprüft.
Das Attribut "Einzel-/Gruppenkarte" für Anlagenobjekte wurde gestrichen, da es keine wesentliche Bedeutung mehr hatte. Stattdessen kann eine Selektion auf Kartenart oder Konzern erfolgen, da Konzernkarten immer Einzelkarten sein mussten und Gesellschaftskarten in der Regel Gruppenkarten darstellten.
Für Kapital- und Rückstellungsbewegungen auf Konzernebene gibt es jeweils den neuen Buchungsschlüssel 33 für die manuelle Buchung von Währungsdifferenzen. Bewegungen mit diesem Buchungsschlüssel werden auch durch die Konzern-Währungsumrechnung nicht wieder gelöscht. Diese Buchungsschlüssel werden jetzt auch für die Kurseffekte bei der Fremdanteilsermittlung verwendet.
Die Anwendung GES war in der Vergangenheit zu einer Statusübersicht für den Einzelabschluss und zu einer Aufrufanwendung für die zugeordneten Verarbeitungen erweitert worden. Weitere Anforderungen waren nicht mehr mit dem Status einer Stammübersicht vereinbar, so dass beschlossen wurde, die Anwendung zu teilen in die Stammdatenübersicht (Kurzwort GES) und den Einzelabschluss-Monitor (Kurzwort EA). Selektionsmöglichkeiten, die nur für GES von Bedeutung sind, sind in EA jetzt entfallen. Im Menübaum ist EA im Menü <Summen- und Einzelabschluss bis HBII..> enthalten. Der Doppelklick auf eine angezeigte Zeile verzweigt in die Kontensalden-Übersicht (KTOSAL).
Bei Selektion nach Konzernkreis erfolgt die Sortierung der Gesellschaften nach Konsolidierungsart: 1. V (vollkonsolidiert), 2. Q (quotal), 3. E (At Equity), 4. K (nicht konsolidiert). Die Konsolidierungsart wird dann in einer zusätzlichen Spalte ausgegeben.
Es ist möglich, in EA die Datenart und/oder den Unternehmensbereich (UBR) mehrdeutig vorzugeben (z.B. '%', 'I%'). Dann wird für jede Datenart bzw. für jeden Unternehmensbereich eine eigene Zeile mit den entsprechenden Statuswerten ausgegeben, allerdings nur wenn überhaupt Daten vorhanden sind. Datenarten, auf die noch nicht hochgeschlüsselt wurde, wie auch UBRs, die bei einer Gesellschaft nicht vorkommen, werden somit nicht angezeigt. Ist die UBR-Eingabe leer, wird nur eine Zeile für die Gesamtgesellschaft angezeigt, auch wenn mit UBRs gearbeitet wird. Die Sortierreihenfolge ist Gesellschaft - UBR - Datenart. UBR und Datenart werden ggfs. als zusätzliche Schlüsselspalten ausgegeben.
In der Statusanzeige wird jetzt nicht mehr nach '-' (Meldung "keine Daten" im Checkpoint/VERARB-Satz) und leer (kein Checkpoint/VERARB-Satz vorhanden) unterschieden. In beiden Fällen wird '-' ausgegeben. Wenn es mindestens einen Checkpoint/VERARB-Satz ohne die Meldung "keine Daten" gibt, wird 'X' (Daten fehlerfrei) oder '4' (Daten fehlerhaft, wenn Checkpoint/VERARB-Satz mit Meldung) gesetzt. Andere Ermittlungsverfahren gelten für die Spalten "SK" und "AE" (s.u.) sowie für Buchungen, deren Status aus den Meldungen in den Belegköpfen (BEL) ermittelt wird.
In der neuen Folgeaktion "Status prüfen/aktualisieren" werden die angezeigten Statuswerte noch einmal verifiziert. Es werden alle Prüfmodule für die Schlüssel der markierten Zeile aufgerufen und die Statuswerte aktualisiert. Die Schlüssel der markierten Zeile (u.a. Unternehmensbereich) müssen dazu eindeutig sein.
Zusätzliche Status-Spalten 'SK' und 'AE' werden ausgegeben, wenn das IC-Clearing für Einzelabschlüsse (s. IC-Kontensalden) ausgeführt wurde. Die Statuswerte entsprechen der Anzeige in KTKGES.
Beim Aufruf der Übersicht der Währungsumrechnungs-Kopfsätze (WUM) aus EA wird jetzt der Parameter für Konzern/Tk wie in EA angegeben übergeben und in die Maske eingestellt.
Bei Selektion nach einem Periodenintervall in VERARB erfolgt die Sortierreihenfolge jetzt absteigend nach Periode (analog der Anwendung ABR).
Zur möglichst effizienten Erfassung von Berichtsdaten (u.a. in Zusammenhang mit dem Internet-Client) wurde eine neue Dialogform Schnellerfassung realisiert. Die Schnellerfassung wird in diesem Release für die Anwendungen KTOSAL, ICKTOSAL und KSTSAL zur Verfügung gestellt.
Die Schnellerfassung wird aus einer Übersichtsanwendung heraus gestartet, in der auch die gleichbleibenden Schlüssel (Gesellschaft, Periode, Datenart, evtl. Konto) vorgegeben werden. Beim Start der Schnellerfassung öffnet sich im unteren Teil des Anwendungsbereichs ein Fenster mit einer Eingabezeile. Die Eingabefelder wurden hierbei auf die minimale Anzahl reduziert:
Die Dialogführung wurde dabei so gestaltet, dass die Bedienung mit dem Ziffernblock der Tastatur möglich ist. Mit der <Enter>-Taste erfolgt (analog <Tab>) der Sprung in das nächste Eingabefeld bzw. beim letzten Eingabefeld wird die erfasste Zeile nach oben geschoben und eine neue Eingabezeile geöffnet. Ein Eingabefeld für das Soll/Haben-Kennzeichen ist nicht vorgesehen. Vielmehr gilt die Konvention: Sollwerte sind als positive Beträge, Habenwerte als negative Beträge zu erfassen.
Die so erfassten Daten werden nicht sofort verarbeitet, sondern nur lokal auf dem Bildschirm gespeichert. Nach erfolgter Erfassung wird die Übernahme durch Betätigung eines entsprechenden Buttons ausgelöst. Dann erfolgt die Verprobung und Speicherung in der Datenbank durch die zugehörige Import-Anwendung. Fehlerhafte Daten werden zurückgemeldet und im Schnellerfassungsbereich zusammen mit der Fehlerbeschreibung ausgegeben, wo sie editiert und erneut übernommen werden können. Nicht zu übernehmende Zeilen können per Objektmenü (rechte Maustaste) aus der Tabelle entfernt werden. Alternativ können die erfassten Daten durch den Button <Abbrechen> auch komplett verworfen werden.
Speziell für die Arbeit mit dem Internet-Client wurde eine Möglichkeit geschaffen, erfasste, aber noch nicht verarbeitete Daten lokal zwischenzuspeichern (<in Datei speichern>) und auch wieder zurückzuladen (<aus Datei laden>). Auf diese Weise können erfasste Daten bei Unterbrechung der Netzwerkverbindung gerettet werden. Auch diese Funktionen sind über das Objektmenü (rechte Maustaste) der Schnellerfassungstabelle verfügbar.
Bei der Verprobung der Kontensalden mit Ermittlung des JÜ-Betrags wird jetzt das JÜ-Konto unter Berücksichtigung der Gültigkeitsangaben (gültig-ab, gültig-bis) ermittelt. Ist z.B. ein JÜ-Konto bis zur Periode 12.2002 gültig, ein anderes ab 01.2003, so wird dies nicht mehr als Fehler gemeldet, sondern korrekt (je nach aktueller Periode) verarbeitet.
Bei der Berechnung von Prüfsummen werden jetzt Salden mit Wert 0,00 nicht mehr berücksichtigt. Dadurch wird u.a. die Prüfsumme in Landeswährung durch eine Währungsumrechnung nicht mehr verändert.
Die Fremdschlüsselverknüpfung in der Datenbank zwischen Kontensalden (KTOSAL) und IC-Kontensalden (ICKTOSAL) wurde aufgehoben. Es können jetzt IC-Salden erfasst oder importiert werden, auch wenn noch kein Saldensatz für dieses Konto existiert.
Eine weitere Konsequenz daraus ist, dass in Anwendungen, die Kontensalden löschen (z.B. Löschen und Import, Löschen und Vortrag) die zugehörigen IC-Salden nicht automatisch mitgelöscht werden, sondern erhalten bleiben. So ist z.B. jetzt in GESABV ein Hochschlüsseln der Kontensalden möglich, ohne dass die vorgetragenen IC-Salden verändert werden. Falls noch nicht vorhanden, wird ein Saldo mit Nullwerten durch die Währungsumrechnung erzeugt, wenn es IC-Salden für ein Konto gibt.
Diese Änderung war Voraussetzung für die neue Funktion des IC-Salden-Abgleichs auf der Ebene der Einzelabschlüsse. In der Anwendung EA wurden dazu die Anwendungen Schuldenkonsolidierung, Aufwands/Ertrags-Konsol. , und IC-Clearing-Übersicht als Folgeaktionen ergänzt, zu finden in Untermenüs wie in KTKGES. Als Parameter wird dabei neben der aktuellen (Gesellschafts-)Datenart auch die angegebene Ex-Datenart in Verbindung mit dem Konzern/Tk übergeben.
Die IC-Clearing-Funktion liest die IC-Salden gemäß der Verarbeitungsdatenart, mit der auch die IC-Clearing-Sätze geschrieben werden. Die Ex-Datenart dient zur Ermittlung der IC-Gesellschaften aus dem Konzernkreis und der Konsolidierungsparameter. Die Verarbeitung erfolgt aber ohne Erzeugung von Belegen und Buchungen. Es werden nur KGESGES-Sätze geschrieben. Voraussetzung ist die Umrechnung in Konzernwährung für Fremdwährungsgesellschaften. Ein Gesamtstatus je Gesellschaft wird in zusätzlichen Spalten der Anwendung EA ausgegeben.
Da das IC-Clearing jetzt auch über die Transaktionswährung (TW) unterstützt wird, gibt die Übersicht ICKTOSAL in der Pärchen-Sicht (IC-Sel-Option = 'SK' oder 'AE') auch die Summen der Werte in TW aus. Diese Pärchen-Sicht ist jetzt auch bei mehrdeutiger Angabe (z.B. '%') der IC-Gesellschaft möglich. Es werden dann alle Gesellschaftspaare mit ihren Summen und Differenzen nacheinander ausgegeben. Zusätzlich ist auch eine Selektion von Salden in einer bestimmten Transaktionswährung möglich.
Die Restwertanalysefunktion in ICKTOSAL ist jetzt auch bei der Sort-Option 'IG' möglich. Bei Aufruf der Restwertanalyse aus der Reportergebnisübersicht wird jetzt auch die Sort-Option 'IG' eingestellt.
Zur besseren Verständlichkeit der IC-Salden-Übersicht insbesondere in der Sicht der Restwertanalyse erfolgten folgende Änderungen bezüglich der Übersetzungen von Gesellschaft und IC-Gesellschaft je nach Sort-Option:
In der Einzelsatzanwendung ICKTOSALE sind die Felder für Gesellschaft und Unternehmensbereich jetzt keine Eingabefelder mehr. Diese Schlüssel müssen von der Übersicht eindeutig vorgegeben werden. Damit verhalten sich die drei Saldenanwendungen (KTOSALE, ICKTOSALE, KSTSALE) in dieser Beziehung gleich.
Analog zur Ersetzung des Begriffs Kostenstelle durch Controllingobjekt wird auch der Begriff Kostenstellensalden durch den Begriff Controllingsalden ersetzt. Um Controllingsalden einer Controllingobjektklasse selektieren zu können, wurde in der Übersicht KSTSAL die Selektion nach Controlling-Kennzeichen 2 ergänzt.
Wenn im Report für das Umsatzkostenverfahren eine Aufteilung der Salden auf die Positionen nach Controllingobjekt erfolgt, dann wird jetzt beim Erfassen von Controllingsalden die Zuordnung des Kontos zu einer Position (AGGKTO) gemäß dem jeweiligen Controlling-Kennzeichen 1 geprüft. Der Positionsplan für diese Prüfung wird der Vorbelegung entnommen.
In den Einzelsatzmasken der Bewegungsanwendungen (ANLBEWE, KAPBEWE, RUEBEWE und GESGESE) wurden die Ausgabefelder für Periode und Datenart entfernt, da sie eindeutig von der Übersicht vorgegeben und dort auch im Selektionsbereich angezeigt werden.
Das Löschen von Anlagenbewegungen, die auf einem für die Datenart falschen Kontenplan erfasst wurden, ist jetzt möglich. Bisher kam eine Fehlermeldung, die auch das Löschen der Daten verhinderte.
In der Einzelsatzanwendung ICBEWE wurden die bisherigen Eingabefelder für Konzern und Gesellschaft zu Ausgabefeldern. Die Felder für Periode und Datenart werden ganz aus der Maske entfernt. Bisher konnten alle vier Schlüssel in der Einzelsatzanwedung verändert werden, ohne dass erfasste Werte anschließend in der Übersicht angezeigt wurden. Dies war insbesondere bei der Konsolidierung der Zwischenergebniseliminierung im Umlaufvermögen gefährlich.
Beim Wechsel von der Belegübersicht BEL in die Buchungsübersicht BUCH wird jetzt nicht mehr die Buchungssatz-Nr. '01' eingestellt, so dass standardgemäß alle Buchungen des Beleges ausgegeben werden. Wenn dann in BUCH ohne Vorgabe einer Buchungssatz-Nr. die Aktion <Erfassen> gewählt wird, wird in der Einzelsatzanwendung die Buchungssatz-Nr. '01' als Defaultwert verwendet. Zur Erfassung von Buchungen mit anderen Buchungssatz-Nrn. muss diese wie bisher in BUCH vorgegeben werden.
Die Maske der Einzelsatzanwendung BUCHE wurde zwecks besserer Übersichtlichkeit neu gestaltet. U.a. wird anstelle der Soll- bzw. Haben-Summen des aktuellen Belegs jetzt eine ggfs. noch offene Differenz auf der Soll- oder Haben-Seite angezeigt. Dies ist insbesondere beim Erfassen neuer Buchungen hilfreich, um die Stimmigkeit des Beleges zu erreichen.
Die Buchungsart 'WU' (wiederkehrend mit Umbuchung) darf jetzt auch für Belege auf Datenarten mit Gesellschaftskontenplan verwendet werden.
Über die Aktion <Kopieren> ist es künftig auch möglich, Belege und Buchungen von einem Unternehmensbereich auf einen anderen zu kopieren.
Über ein neues Prüfmodul werden Buchungen bei jeder Änderung verprobt auf Stimmigkeit und Ergebniswirksamkeit. Die ausgewiesenen Statuswerte sind somit auch nach Aktionen wie Vortrag oder Währungsumrechnung richtig.
Zur Verbesserung der Lesbarkeit wurden die Texte der in IMPORT angezeigten Anwendungen überarbeitet. Die Bezeichnung enthält jetzt nicht mehr den Dateinamen. Der Default-Dateiname (ohne den Suffix ".TXT") steht stattdessen in der Spalte Kurzwort.
Bisher wurden die Import-Dateien (KPxxx.TXT) von den Anwendungsprogrammen selbst gelesen. Mit der Einführung des "Internet-Client" erfolgt aber eine Trennung zwischen Oberfläche und Anwendungsschicht, so dass die Anwendung nur noch Dateizugriffe auf dem Anwendungs-Server durchführen kann. Da die Import-Dateien aber auf dem lokalen Rechner (Client) liegen, mussten die Dateizugriffe in die Oberflächenschicht (GUI) verlegt werden. Entsprechend wird auch die Protokolldatei auf dem lokalen Rechner geschrieben. In diesem Zuge konnten folgende Verbesserungen erreicht werden:
Ohne Änderung der Einträge im Options-Dialog erfolgt der Import wie bisher mit fest vorgegebenen Pfad- und Dateinamen.
Beim Import von Positions-/Konten-Zuordnungen (TXTAGGKTO) wird jetzt für den Ziel-Kontenplan nur noch die Leseberechtigung benötigt. Die Schreibrechte werden nur noch für den Positionsplan geprüft.
Der Import von Positions-/Konten-Zuordnungen (TXTAGGKTO) steht jetzt auch in der Variante "Löschen und Import" zur Verfügung. Durch das Löschen wird sichergestellt, dass keine veralteten Zuordnungen mehr übrigbleiben.
Für die Funktionen zum Auslesen von Positionen oder Positions-/Konten-Zuordnungen aus Fremdsystemen (UNL...) erfolgt jetzt eine Vorbelegung des Positionsplans in IMPORT mit dem Wert aus der Vorbelegung. Dieser Schlüssel wird bei Angabe einer Umsetzgruppe ggfs. in den Schlüssel des Fremdsystems umgesetzt.
Bei Vorgabe einer Gesellschaft oder eines Konzernkreises in IMPORT werden die Daten der Eingabedatei jetzt auch gegen diese Schlüssel geprüft. Daten für andere Gesellschaften werden nicht übernommen. Bisher war diese Prüfung nur für die Schlüssel Periode und Datenart enthalten sowie für Gesellschaften in der Variante "Löschen und Import".
Die Funktion "Löschen und Import" ist jetzt auch für mehrere Perioden und Datenarten auf einmal möglich. Für die Perioden wurde dazu in IMPORT ein Eingabefeld für die ab-Periode ergänzt, für die Datenart können Platzhalter (z.B. 'I%') eingegeben werden. Gelöscht werden nur Daten für Perioden und Datenarten, die auch in der Eingabedatei enthalten sind. Außerdem erfolgt eine Berechtigungsprüfung für die Schlüssel der zu löschenden Daten.
Für Umsetzgruppen-Zuordnungen von Gesellschaften ist jetzt eine Zusatzangabe möglich, ob sich eine Umsetzung nur auf die Gesellschaft oder nur auf die IC-Gesellschaft beziehen soll. Dies ist wichtig für die Übernahme von Daten aus dem SAP-System, wo die Gesellschaften als Buchungskreis bzw. als Partnergesellschaft in getrennten Stammtabellen geführt werden, die unterschiedliche Schlüsselsysteme haben können. Neben dem Import für IC-Salden wird diese Unterscheidung auch in diversen anderen Import-Anwendungen getroffen, wenn dies so angegeben ist.
Analog können Umsetzgruppen-Zuordnungen für Unternehmensbereiche zwischen dem UBR selbst und dem IC-UBR unterschieden werden.
Wurden IC-Salden für Konten übernommen, die eine von der Angabe im Kontenplan ( KTP) abweichende Länge hatten, so wurde ein Fehler gemeldet. Dieser Fehler wird jetzt unterdrückt.
Die im Dialog ausgegebenen Warnungen betreffs fehlender Zusatzparameter (IC-Ges, AnlObj, BSL, KST) bei Buchungen auf Konten mit entsprechenden Aufriss-Kennzeichen werden jetzt auch beim Import von Buchungen ausgegeben (Anwendung TXTBUCH).
Für den Import von IC-Bewegungen (s. Anwendung ICBEW) wurde wie für andere Berichtsdaten die Variante <Löschen und Import> ergänzt.
Die folgenden Anwendungen wurden betreffs Parameterübergabe und Berechtigungsprüfung überarbeitet, so dass sie in der Automatensteuerung zum Einsatz kommen können: TXTKTKGES, TXTKONBEL, TXTKONBUCH, TXTICBEW, TXTBEL, TXTBUCH, TXTICKONV.
Werden Daten auf eine Datenart vorgetragen, in der Umrechnungs-Kopfsätze bereits definiert sind, so wird der Status der WUM-Kopfsätze auf "Währungsumrechnung muss noch durchgeführt werden" gesetzt.
Werden die Daten beim Vortrag auf mehrere Unternehmensbereiche (UBRs) aufgeteilt, dann wird jetzt nur noch für die gültigen UBRs (Angabe "gültig bis" in UBR) ein Kontrollsatz (Checkpoint) in der Tabelle VERARB angelegt.
Im Herkunftsnachweis für Kostenstellensalden (KSTHER) wurde eine Zwischensumme je Herkunftskonto ergänzt.
Bisher wurden keine Buchungen vorgetragen, deren Konto in der aktuellen Periode nicht mehr gültig ist. Es wurde ein Fehler gemeldet und das Ergebnis waren unstimmige Belege. Künftig wird die Buchung vorgetragen, aber der Beleg wird auf Verarbeitungskennzeichen 'I' (inaktiv) gesetzt. Dieser Sachverhalt wird nicht als Fehler, sondern als Hinweis gemeldet.
Durch die strengere Verprobung der Bewegungsaufrisse werden seit Release 5.1.2 Unstimmigkeiten zu den Salden als Fehler in der Tabelle VERARB eingetragen. Dies führte zunächst dazu, dass der Vortrag dieser Daten nicht durchgeführt wurde. Jetzt werden diese Bewegungen auch trotz Unstimmigkeiten vorgetragen.
Bei der Umschlüsselung von Buchungen auf Controlling-Konten auf das Ergebnisvortragskonto (Konto-Kennzeichen = 'W') wird die Angabe der Kostenstelle jetzt nur noch dann übernommen, wenn auch das Ergebnisvortragskonto ein Controlling-Konto (Konto-Kennzeichen 2 = 'C') ist.
Das Ergebnisvortragskonto (Konto-Kennzeichen = 'W') wird jetzt unter Berücksichtigung der Gültigkeitsangaben im Kontenstamm (KTO) ermittelt. So ist es möglich, mehrere Ergebnisvortragskonten anzulegen, wenn sich deren Gültigkeit nicht überschneidet.
Analog zum Vortrag von Konsolidierungsbuchungen wird jetzt auch beim Vortrag von Buchungen (HBI/HBII) eine Hinweismeldung ausgegeben, wenn ergebniswirksame Belege nicht vorgetragen wurden, weil die Buchungsart des Belegs auf 'E' (Einmalbuchung) oder weil das Verarbeitungskennzeichen auf 'I' (inaktiv) steht.
Beim Konzern-Vortrag wird jetzt geprüft, ob die angegebenen Gesellschaften aufgrund der Stammsatz-Angabe <Gültig bis> in der aktuellen Periode nicht mehr gültig sind. Konsolidierungsbuchungen, Konzernbewegungen und Report-Kopfsätze werden dann nicht mehr vorgetragen (auch bei Angabe einer ungültigen Gesellschaftsnr. in der Belegnr.). Eine entsprechende Meldung wird ausgegeben.
Weiterhin wird jetzt geprüft, ob in der Vorperiode Konsolidierungsbuchungen vorliegen, die von der Teilfunktion FOLGEKON (KF) verarbeitet werden (Konsolidierungsverarbeitungen KE, KM, KS, KL, EM, EF, LK oder LE). Ist dies nicht der Fall, wird nicht mehr wie bisher ein Fehler gemeldet, sondern das Status-Flag für KF in KTKGES wird auf '-' gesetzt.
Beim Vortrag von Konsolidierungsbuchungen bleibt jetzt die Buchungssatz-Nummer erhalten. Dies ist z.B. interessant für manuelle Belege (MB), in denen die Buchungen für verschiedene Sachverhalte auf verschiedenen Buchungssatz-Nummern erfasst wurden.
Beim Vortrag von Konsolidierungsbuchungen auf Controlling-Konten bleibt die Angabe des Controlling-Objekts aus der Ursprungsbuchung jetzt erhalten.
Beim Vortrag von Konsolidierungsbuchungen auf Anlagen-, Kapital- oder Rückstellungskonten wird jetzt der Buchungsschlüssel auf den entsprechenden Vortrags-Buchungsschlüssel (V1 bzw. V2 bei Anlagen, 21 bei Kapital und Rückstellungen) umgesetzt. Dadurch werden die Buchungen auch je Buchungsschlüssel konsistent zu den Bewegungsdaten.
Die vorgetragenen Konzernbewegungen enthielten fälschlicherweise eine Belegnummer aus der Vorperiode. Dieser Fehler wurde jetzt behoben.
Für reporttechnische Konzerne wurde der Vortrag auf die Tabellen KTKGES (Konzernkreis) und REP (Report-Kopfsätze) beschränkt. Konsolidierungsparameter, Konsolidierungsbuchungen und Konzernbewegungen werden nicht mehr vorgetragen.
In der Wechselkursübersicht WKZWKA wurde ein Eingabefeld "ab Stichtag" ergänzt, damit die Entwicklung eines Kurses über mehrere Perioden angezeigt werden kann. Die Sortierreihenfolge bezüglich des Stichtages wurde umgekehrt, so dass die aktuellen Kurse jetzt am Anfang der Tabelle stehen.
Des weiteren wurde eine Spalte ergänzt, die die Wirkung des Wechselkurses anhand einer Formel verdeutlicht, z.B. "1 EUR = 1,955830 DEM". So wird die unterschiedliche Wirkung der Wechselkursarten 'M' und 'R' ebenso verdeutlicht wie der Bezug auf die jeweilige Konzernwährung, abhängig von der Periode.
Für Umrechnungskopfsätze ist in der Anwendung WUM jetzt eine Mengenänderung der Wechselkursart möglich, z.B. zur Umstellung von 'M'- auf 'R'-Kurse. Nach diesem Attribut kann auch selektiert werden.
Die noch bestehenden Beschränkungen zur Durchführung einer Währungsumrechnung auf einer Datenart mit Gesellschafts-Kontenplan wurden aufgehoben. U.a. können jetzt auch Umrechnungsanweisungen auf Basis des Umrechnungsverfahrens generiert werden.
Die Behandlung der Umrechnungsdifferenz 'M' wird jetzt nicht mehr unterstützt.
Für das JÜ-Konto wird in den Umrechnungsanweisungen (KTOUAW) jetzt nach Möglichkeit die praktisch resultierende Umrechnungsanweisung eingetragen, also im Normalfall 'SK', bei Verbuchung der bilanziellen Umrechnungsdifferenz auf ein GuV-Konto aber 'PDK'. Die Umrechnungsanweisung des JÜ-Kontos wird bei der Erzeugung von Umrechnungsanweisungen (UPDUMST) nicht mehr vorbelegt.
Ist das JÜ-Konto gleichzeitig ein Kapitalkonto, so werden Kapitalbewegungen erzeugt, die für die Stimmigkeit des Kapitalaufrisses für das JÜ-Saldo auch in Konzern- und Parallelwährung sorgen.
Ist ein Differenzkonto gleichzeitig ein Kapitalkonto, so wurde bisher eine Kapitalbewegung in Höhe der kumulierten Differenz erzeugt. Jetzt bleiben Vorträge auf dem Konto erhalten, so dass nur noch die aktuelle Differenz als Kapitalbewegung erzeutgt wird.
Die Unterscheidung der Kurseffekte in historische und aktuelle Differenzen (z.B. BSL 00 und 12 für Kapitalbewegungen) von Bewegungsaufrissen erfolgt jetzt nur noch, wenn sich die Währungen gegenüber der Vorperiode nicht verändert haben. Bisher konnten durch falsche Interpretation der Kurse riesige Beträge entstehen, die sich erst in der Summe eliminierten.
Die Währungsumrechnung (LW/KW/PW) führt jetzt den Differenzausgleich für Buchungen auf echten und auf statistischen Konten separat durch, vorausgesetzt dass in Landeswährung Soll/Haben-Gleichheit besteht. Die Verrechnung der Differenzen erfolgt auf den Buchungen selbst.
Die Umrechnungsanweisung in den Bewegungen für die KW-Umrechnung wird jetzt, falls angegeben, auch für die PW-Umrechnung verwendet, so wie bisher bereits die Umrechnungsanweisung in KTOUAW für die Umrechnung der Salden in KW und PW verwendet wird. Bei Umrechnungsverfahren MST (Bilanz mit SK, GuV mit PDK) kam es sonst zu PW-Differenzen zwischen lfd. AfA (AnlBew) und AfA-Salden, wenn für die Anlagenbewegungen die Umrechnungsanweisung PDK eingestellt wurde.
Die Umrechnung der IC-Bewegungen (s. Anwendung ICBEW) erfolgt jetzt unabhängig vom Konzern/Tk für alle Daten der jeweiligen Gesellschaft. Daher ist die Angabe eines Konzern/Tk in den Anwendungen WUM, WUME und EA auch nicht mehr Voraussetzung für die Währungsumrechnung, wenn für die Gesellschaft IC-Bewegungen geführt werden. Die Angabe des Konzern/Tk dient jetzt nur noch der Verprobung der Währungskennzeichen für Konzern- und Parallelwährung gegen die Angaben in KTK.
Die Konzern-Währungsumrechnung (KW/PW) führt jetzt auch einen Differenzausgleich für Konsolidierungsbuchungen auf statistischen Konten durch, vorausgesetzt dass in Konzernwährung Soll/Haben-Gleichheit besteht. Mangels statistischer Konten im WUM-Kopfsatz erfolgt die Verrechnung der Differenzen auf den Buchungen selbst.
Vorträge von Anlagenbewegungen zu A- und Z-Anlagenobjekten (Umrechnungsanweisung VKW) werden jetzt auch in PW nicht neu gerechnet, sondern der vorgetragene Wert wird übernommen.
Als Clearing-Konten ("KtoDiffAufwand" und "KtoDiffErtrag") für die Aufwands/Ertrags-Konsolidierung (AE) dürfen nur nur noch GuV-Konten angegeben werden (Anwendung KTKPARAE).
Für das Konto für sonstige Aufwände in der Anwendung KTKPAREK sind jetzt neben Konten mit Bil/GuV-Kennzeichen '4' auch Konten mit Bil/GuV-Kennzeichen '3' zugelassen.
In KTKPARKK wurde ein Eingabefeld für Abschreibungen auf Goodwill ergänzt. Wenn angegeben, wird dieses bei diesem Sachverhalt anstelle des allgemeinen Abschreibungskontos herangezogen.
Durch die Erweiterung für Latente Steuern (KTKPARLT) hat der Misch-Steuersatz in KTKPARKK keine Funktion mehr. Er ist daher in der Einzelsatzmaske nicht mehr enthalten und wird auch nicht mehr in neue Perioden vorgetragen. In der Übersicht KTKPAR wird er aber noch angezeigt, um Vergleiche mit früheren Perioden zu ermöglichen.
Die Vorperiode wird nur noch dann aus der Vorbelegung übernommen, wenn sie kleiner ist als die (z.B. von einer Voranwendung als Parameter übergebene) aktuelle Periode.
Die Sortierung der Gesellschaften in der Konzernkreisübersicht KTKGES erfolgt jetzt nach Konsolidierungsart: 1. V (vollkonsolidiert), 2. Q (quotal), 3. E (At Equity), 4. K (nicht konsolidiert). Das gilt auch für die Anzeige der Konzernstruktur über die Folgeaktion <Anzeigen/Prüfen Konzern/Tk-Struktur>.
Die beiden bisherigen Statusspalten <KtoSal> und <WUM> wurden zu einer Spalte mit der Überschrift <EAB> zusammengefasst, da sie den Gesamtstatus des Einzelabschlusses wiederspiegeln. Einzelheiten werden nach Aufruf der Folgeanwendung <Einzelabschluss> im Submenü <Übersichten> für die markierte Gesellschaft angezeigt.
Es wurde eine zusätzliche Statusspalte für die Abschreibungen aus der Kapitalkonsolidierung (KL) ergänzt. Eine Vorbelegung durch die Vortragsanwendung erfolgt bisher nicht, so dass der Status zunächst auf leer steht. Nach Durchführung wird der Status auf 'X' gesetzt, wenn Daten (Anlagenbewegungen für lfd. AfA) vorhanden waren, ansonsten auf '-'.
Nach Markierung einer Menge von Gesellschaften kam es beim Start einiger Konsolidierungsverarbeitungen zum Abbruch der Verarbeitungsfolge, wenn eine Equity-Gesellschaft markiert worden war. Jetzt wird dies nicht mehr als Fehler gemeldet. Vielmehr wird der entsprechende Status auf '-' (keine Verarbeitung notwendig) gesetzt.
Um verschiedene, in manuellen Buchungen zu erfassende Sachverhalte für eine Gesellschaft oder ein Gesellschaftspaar besser unterscheiden zu können, können jetzt mehrere Konsolidierungsbelege angelegt werden. Dazu können (ähnlich wie bereits für Schulden- und Aufwands/Ertragskonsolidierung) kundenspezifische Konsolidierungsverarbeitungen für manuelle Sachverhalte definiert werden (Anwendung KVA) gemäß der Konvention: 1. Zeichen = 'M', 2. Zeichen nummerisch (z.B. 'M1', 'M2'). Diese KVA kann dann in der Belegnummer angegeben werden.
Dadurch ist es jetzt auch möglich, manuelle Buchungen mit unterschiedlicher Buchungsart (z.B. einmalig bzw. wiederkehrend) zu unterscheiden. Wiederkehrende Buchungen werden allerdings beim Vortrag zu einem VM-Beleg zusammengefasst, so dass dann keine Unterscheidung zwischen wiederkehrend festen und wiederkehrend variablen Buchungen mehr erfolgt.
Die Schulden- bzw. Aufwands-/Ertrags-Konsolidierung berücksichtigt jetzt auch die Angaben der Werte in Transaktionswährung in den IC-Kontensalden. Stimmen für ein Gesellschaftspaar die gemeldeten Werte in der Transaktionswährung überein, so wird die Differenz in Konzernwährung auf das in KTKPAR angegebene Kurseffekt-Konto gebucht. Der Status in KGESGES wird auf '3' gesetzt.
Bei der Schuldenkonsolidierung für Anlagenkonten wird der ursprüngliche LW-Wert aus den IC-Salden in die generierten Anlagenbewegungen eingetragen (ggfs. saldiert). Dieser Wert wird dann vorgetragen, so dass die Berechnung von Kurseffekten erfolgen kann, ohne dass dieser Wert manuell erfasst werden muss.
Die maschinelle (KE) wie auch die manuelle (KM) Erstkonsolidierung erfolgt jetzt nur noch dann, wenn beide Gesellschaften nicht gleichzeitig in einem untergeordneten Teilkonzern enthalten sind. Bisher konnte es in einer solchen Konstellation (z.B. Haupt-Muttergesellschaft im Teilkonzern, aber Minderheitsbeteiligung auf Weltkonzernebene) zu doppelten Buchungen (auch im Report) kommen.
Der in KTKGES angezeigte Status für die maschinelle und manuelle Erstkonsolidierung (KE bzw. KM) wird jetzt analog der Schulden- und Aufwands/Ertrags-Konsolidierung (SK/AE) in Abhängigkeit von der Verrechnung des Unterschiedsbetrags (VUB) vergeben:
In der Anwendung UBMAN (Einzelsatzverarbeitung der Übersicht KONKTO, Konsolidierungsverarbeitung KM) wurde ein Eingabefeld für den Unternehmensbereich (UBR) ergänzt. Dieser UBR wird dann in die Konsolidierungsbuchung auf dem Kapitalkonto eingetragen. Der UBR wird auch in der Übersicht KONKTO jetzt als Spalte ausgegeben. Bisher musste der UBR nachträglich in der Anwendung KONBUCHE ergänzt werden.
Bei der Verrechnung des Unterschiedsbetrags (VUB) wird jetzt für ein zu generierendes Anlagenobjekt als Anschaffungsdatum (darauf basiert die AfA-Berechnung) sowie als Gültig-ab-Datum das Bewegungsdatum des zugrundeliegenden Beteiligungszugangs vorgeschlagen. Dieses wird auch als Bewegungsdatum für eine generierte Anlagenbewegung verwendet.
Bei Verrechnung des Unterschiedsbetrags auf stille Reserven können jetzt mehrere Buchungen auf unterschiedliche Konten erfolgen, wobei jeweils ein neues Anlagenobjekt erzeugt wird, falls es noch nicht vorhanden ist.
Wenn in der manuellen Erstkonsolidierung der Erwerb in mehreren Tranchen dokumentiert werden soll, so müssen ggfs. auch mehrere Anlagenobjekte für die Aktivierung des Geschäftswerts angelegt werden. Bisher war dies wegen restriktiver Prüfungen der Namenskonventionen in KONBUCHE nicht möglich. Künftig können im Schlüssel des Anlagenobjekts auch Vergangenheitsperioden angegeben werden. Die Erfassung muss aber manuell erfolgen.
KL-Belege (Abschreibungen aus der Kapitalkonsolidierung) werden jetzt analog den ursprünglichen Belegen (KE, KM, KF) mit zwei Gesellschaften in der Belegnummer geführt. Dadurch werden die Buchungen auch korrekt in einen reporttechnischen Teilkonzern (Anwendung REPKTK) übernommen. Entsprechend den Ursprungsbelegen werden die KL-Buchungen auch in unterschiedlichen Buchungssatznummern (z.B. '02' für Geschäftswert, '06' für stille Reserven) geführt. Entsprechend erfolgt auch der Vortrag dieser Buchungen durch KF.
Bei der Generierung von Konsolidierungsbuchungen für Abschreibungen aus der Kapitalkonsolidierung (KL) wird jetzt nicht immer nur das Abschreibungskonto aus KTKPARKK herangezogen, sondern Konten nach folgender Priorität:
In den KL-Buchungen wird jetzt wie in den zugrundeliegenden Anlagenbewegungen der Buchungsschlüssel '69' eingetragen. Damit stimmen Buchungen und Bewegungen auch in den Buchungsschlüsseln überein.
Die Berechnung von Kurseffekten in den Anwendungen zur Buchung der direkten und indirekten Fremdanteile führte zu einem Fehler, wenn ein im WUM-Kopfsatz angegebenes Verrechnungskonto ein Kapitalkonto ist. Jetzt werden für diese Konten (LW-Wert ist null) keine Kurseffekte mehr berechnet.
Beide Anwendungen prüfen jetzt auch das Vorhandensein von Kontensalden. Sind keine Salden vorhanden, wird eine Meldung ausgegeben und die Statusanzeige in KTKGES auf '-' gesetzt.
Die im Release 5.1.2 eingeführte neue Funktionalität für latente Steuern wurde mit diesem Release um die folgenden Punkte erweitert:
Die Verprobung der Soll/Haben-Gleichheit erfolgt jetzt nur noch für echte Konten, statistische Konten werden bei der Kontrollrechnung nicht mehr berücksichtigt. Entsprechende Differenzmeldungen im Konzern-Report (z.B. bei statistischen Halbbuchungen) kommen daher nicht mehr vor.
Beim Wechsel von der Belegübersicht KONBEL in die Buchungsübersicht KONBUCH wird jetzt nicht mehr die Buchungssatz-Nr. '01' eingestellt, so dass standardgemäß alle Buchungen des Beleges ausgegeben werden. Das gilt auch für den Aufruf von KONBUCH aus anderen Anwendungen (KGESGES, VUB). Wenn dann in KONBUCH ohne Vorgabe einer Buchungssatz-Nr. die Aktion <Erfassen> gewählt wird, wird in der Einzelsatzanwendung die Buchungssatz-Nr. '01' als Defaultwert verwendet. Zur Erfassung von Buchungen mit anderen Buchungssatz-Nrn. muss diese wie bisher in KONBUCH vorgegeben werden.
Die Maske der Einzelsatzanwendung KONBUCHE wurde zwecks besserer Übersichtlichkeit neu gestaltet. U.a. wird anstelle der Soll- bzw. Haben-Summen des aktuellen Belegs jetzt eine ggfs. noch offene Differenz auf der Soll- oder Haben-Seite angezeigt. Dies ist insbesondere beim Erfassen neuer Buchungen hilfreich, um die Stimmigkeit des Beleges zu erreichen.
Beim Kopieren eines Konsolidierungsbelegs (Einzelsatz-Erfassung mit Vorlage) werden alle zugeordneten Konsolidierungsbuchungen mitkopiert. Dabei wurde bisher das Verarbeitungs-Kennzeichen beibehalten, so dass aus als "maschinell erzeugt" gekennzeichneten Buchungen wieder maschinell erzeugte Buchungen wurden, deren Änderung eingeschränkt ist. Jetzt werden die kopierten Buchungen als "manuell erzeugt" gekennzeichnet, so dass sie frei geändert werden können.
Die automatische Generierung von Anlagenbewegungen bei der Erfassung oder Erzeugung von Konsolidierungsbuchungen berücksichtigt jetzt negativ rechnende Kartenarten ('B', 'Z') und ändert entsprechend das Soll/Haben-Kennzeichen.
Verschiedene Konsolidierungsverarbeitungen wie auch Vortragsprogramme wurden daraufhin geändert, dass die Pflichteingaben für Konsolidierungsbelege (Konsolidierungsverarbeitung, Buchungsart, Verarbeitungskennzeichen, Belegdatum und Belegtext) jetzt immer belegt werden, so dass diese bei einem späteren Update nicht mehr manuell ergänzt werden müssen. Für bestehende Daten werden fehlende Angaben durch das Release-Konvertierprogramm ergänzt.
Bei Angabe der neuen Berechtigungsstufe '3' für Perioden in der Vorbelegung ist zugelassen, auch für abgeschlossene Perioden noch neue Reports zu definieren und einmalig zu erzeugen.
Die Report-Programme (Report-Erstellung) führen jetzt Prüfungen durch, ob die angegebenen Report-Optionen überhaupt unterstützt werden. Wenn nicht, wird ein Fehler gemeldet.
Für die Report-Zeilenbeschreibungen (Anwendung REPZEI) ist jetzt eine Mengen-Änderung für die Attribute Summe-In, Summe-Ex, Zeilentyp und Wertkennzeichen möglich. Nach diesen Attributen kann jetzt auch in der Übersicht selektiert werden.
Die Übersichtsanzeige für Konzern-Reports (bisher nur als Folgeanwendung nach REP-Aufruf mit Vorbelegung für Gesellschafts-Report möglich) ist jetzt durch ein eigenes Kurzwort 'REPK' für die Konzern-Vorbelegung vereinfacht. Mit 'REP' erhält man wie gehabt die Gesellschafts-Report-Vorbelegung allerdings jetzt auch mit der Überschrift 'Gesellschafts-Reportverzeichnis'. Im Menübaum gibt es dann auch analog beide Auswahlmöglichkeiten.
Zur Verbesserung der Antwortzeiten der Anwendung REP (und REPK) werden der erstellende Benutzer, das Erstellungsdatum und die Anzahl der Report-Ergebnissätze in den Report-Kopfsatz direkt eingetragen, so dass die Ergebnistabelle (REPERG) nicht mehr je angezeigtem Report-Kopfsatz dazugelesen werden muss.
Da eine Konvertierung von Alt-Reports zu zeitaufwendig wäre, arbeitet REP nun zweigleisig (alte Reports mit Dazulesen REPERG, neue Reports ohne). Zur Unterscheidung von neuen und alten Reports steht zukünftig bei noch nicht erstellten Reports die Meldung KON0036 (keine Daten vorhanden) im Meldungsfeld.
Für jeden Report können jetzt eine Default-Spaltenoption und eine Default-Aufrissoption im Report-Kopfsatz selbst hinterlegt werden. Diese Optionen überschreiben beim Aufruf der Reportergebnisübersicht (REPERG) die bisherige Voreinstellung aufgrund der benutzerspezifischen Vorbelegung (VORE) oder der fest im Programm vorgegebenen Defaultwerte.
Im Report-Kopfsatz wurde ein neues Attribut 'Anzahl Perioden mit Vergleichsdatenart' hinzugefügt. Dieses Attribut gibt bei einem Periodenreport an, in wie vielen Perioden die Vergleichdatenart statt der aktuellen Datenart verwendet werden soll (bisher immer eine). Diese neue Funktionalität wird für einen Monatsreport mit Plan-/Ist-Vergleich benötigt, wenn Ist-Daten nur für einige Monate des Jahres vorliegen.
Bei der Aufrißoption 'A' werden die Positionen nicht mehr als Summenzeilen dargestellt.
Eine neue Aufrissoption 'A0' wurde eingeführt. Diese unterscheidet sich von der Aufrissoption 'A' nur darin, dass hier die Schlüsselspalte (Positionsnummer) nicht ausgegeben wird. Die Zeile beginnt mit der Positionsbezeichnung.
Die Aufrissoptionen '1AK', '1AK2' und '1A2' wurden jetzt richtig gestellt und können genutzt werden. In dieser Kürzeln ist die Sortier-/Aufrissfolge angegeben, hierbei steht
Die verschiedenen Aufrissebenen im Report werden jetzt mehrfarbig dargestellt. Die zusätzlichen Farben können im Optionsdialog (Zeile1 bis Zeile5) geändert werden.
Der Aufruf der Folgeaktion <Restwertanalyse> ist jetzt nicht nur auf Kontenzeilen, sondern auch auf Positionszeilen (dann Parameterübergabe der Position) und Gesellschaftszeilen (dann Parameterübergabe Konto und Gesellschaft) möglich.
Aus REPERG heraus ist jetzt das erneute 'Berechnen Report' möglich; z.B. nachdem über Aufriss-Aktionen Basisdaten korrigiert wurden.
Vor der Erstellung eines Reports wird jetzt überprüft, ob die Währungen der einbezogenen Daten miteinander konsistent sind.
Im Konzern-Bil/GuV-Report werden die Gesellschaften, für die bisher eine separate Summenzeile erzeugt wurde, dieser Summenzeile untergeordnet. Dazu wird nach dem Ermitteln der Konzernstruktur diese so modifiziert, dass zusätzliche Teilkonzerne eingeschoben werden, um isolierte Gesellschaften einzusammeln. Beispiel:
Dies führt dazu, dass die Gesellschaften quasi automatisch im Report auf diesem neuen Teilkonzern summiert und unter diesem eingerückt werden. Als Nebeneffekt werden im Beispiel bei der Aufrißoption 'A1' nicht mehr die Gesellschaften, sondern nur noch der Weltkonzern mit den Teilkonzernen angezeigt (letzterer mit der Summe der Gesellschaften der obersten Ebene).
Etwas gewöhnungsbedürftig könnte sein, dass bei einer mehrstufigen Konzernstruktur ein Teilkonzern auf zwei verschiedenen Ebenen auftauchen kann. Auf der oberen Ebene enthält er alle Gesellschaften des Teilkonzerns und auf der unteren Ebene die Gesellschaften, die unmittelbar (ohne Zwischenstufe) in diesem Teilkonzern liegen.
Wenn bei der Erstellung eines Reports mit Tk-Aufriss (Reportoption 'T') gleichzeitig Daten mit UBR-Aufriss und mindestens zwei Stufen in der Konzernstruktur vorlagen, kam es bei der Reporterstellung zu einem SQL-Fehler. Die Ursache war, das Tk-Ebene1, Tk-Ebene2, GES und UBR insgesamt vier Aufrissstufen ergeben. Die Reportergebnistabelle lässt aber nur drei Aufrissstufen zu. Um dies in Zukunft zu verhindern, wird bei einem Report mit Tk-Aufriss (Reportoption 'T'), der mehr als eine Tk-Ebene enthält, auf den UBR-Aufriss verzichtet.
Beim Bil/GuV-Report wurden bisher Daten für bis zu zwei Schlüsselsätze erzeugt. D.h., für die fünf aktuellen Schlüssel werden immer Daten erzeugt und für die fünf Vergleichsschlüssel werden Daten erzeugt, wenn die Schlüssel nicht leer sind. Dabei werden jeweils vier Werte in die Reportergebnistabelle geschrieben.
In Zukunft werden noch zwei weitere Datenblöcke geschrieben, falls sowohl aktuelle und Vergleichsperiode unterschiedlich sind als auch bei den übrigen vier Schlüsseln zwischen Aktuell und Vergleich mindestens einer abweicht. Die Daten werden wie folgt in die Reportergebnistabelle geschrieben.
| Aktuelle Periode | Vergleichs-Periode | |
|---|---|---|
| Aktuelle Datenart, Gesellschaft... | Wert01 bis Wert04 | Wert13 bis Wert16 |
| Vergleichs-Datenart, -Gesellschaft... | Wert09 bis Wert12 | Wert05 bis Wert08 |
Weitere Informationen über die Belegung der Wertfelder in der Reportergebnistabelle sind im Hilfetext der Tabelle K066 zu finden.
Die Soll-/Haben-Steuerung in den Bil-/GuV-Reports erfolgte bisher immer auf der untersten Ebene. Dies war mit Ausnahme der Unternehmensbereichs- und Kostenstellen-Aufrisse (wo dies akzeptiert wurde) auch immer korrekt. Mit der Einführung der Reports mit Herkunftsnachweis, wo die Soll-/Haben-Steuerung nun auf der Ebene der Gesellschaftskonten erfolgte, war das nicht mehr akzeptabel, weil dadurch eine Abstimmung mit den normalen Reports verhindert wurde. In Zukunft erfolgt die Soll-/Haben-Steuerung nicht mehr je Gesellschaftskonto, Kostenstelle oder Unternehmensbereich, sondern auf der jeweils ersten darüber liegenden Ebene.
Die Programme zum konzernweiten und zum Teilkonzern/Gesellschafts-Datenaustausch wurden bezüglich diverser Datenbank-Änderungen angepasst (z.B. neue DB-Tabelle K004 für ABR). Dabei wurde auf die Kompatibilität zu früheren Release-Ständen geachtet.
Die (interne) Parameterübernahme der KONDAT-Anwendungen zum konzernweiten wie auch zum Teilkonzern/Gesellschafts-Datenaustausch wurde an den Standard angepasst, so dass diese Programme in die Automatensteuerung eingebunden werden können. Die Angabe <ab Änderungsdatum> ist im Automaten aber nicht möglich.
Der Eingabewert "ab Änderungsdatum" in der Aufrufanwendung KONDAT wirkt jetzt auch beim Entladen der Teilkonzerndaten und zwar auf die transferierten Stammdaten (KTO, KST und ANLOBJ). Dadurch kann die Übertragung vieler bereits in der Zentrale bekannter Daten vermieden werden.
Das Programm zum Laden von Teilkonzern- bzw. Gesellschaftsdaten führt jetzt eine Berechtigungsprüfung auf die Schlüssel Teilkonzern oder Gesellschaft, Periode und Datenart durch. Ist die Berechtigung zum Einfügen und Löschen nicht gegeben, bricht die Anwendung mit einer Fehlermeldung ab. Bei mehrdeutiger Angabe der Datenart (z.B. 'I%') erfolgt die Prüfung anhand einer Aufstellung der tatsächlich entladenen Datenarten, die beim Entladen in die Log-Datei geschrieben wurden.
Seit dem Release 5.1.2 wird auch die Report-Ergebnistabelle (REPERG) in den Teilkonzern-Datenaustausch einbezogen. Diese kann allerdings ggfs. sehr umfangreich werden. Es wurde daher jetzt die Möglichkeit geschaffen, diese Tabelle nicht zu entladen. Dazu gibt das Programm eine entsprechende Warnung mit Antwortmöglichkeiten aus. Diese Abfrage wird unterdrückt, wenn die Import-Option "Meldungsdialog unterdrücken" gesetzt ist.
Die Tatsache, dass beim Laden der Teilkonzerndaten die Reportergebnistabelle nicht mehr unbedingt erwartet wird, führt auch dazu, dass Daten, die mit einem älteren Releasestand entladen wurden, wieder fehlerfrei geladen werden können.
Für die DB-Tabelle K038 (Kapital- und Rückstellungsbewegungen) wird jetzt bei der Übernahme eine neue laufende Nummer für den Schlüssel gebildet, um Überschneidungen mit ggfs. bereits vorhandenen Bewegungen auf Konzernebene zu vermeiden. Da die laufende Nummer an der Oberfläche nicht sichtbar ist, fällt diese Änderung nicht auf.
In Folge dieser Änderung wurden die Funktionen "Laden von Gesellschafts- bzw. Teilkonzerndaten" gestrichen, da die Daten für die Tabelle K038 sonst bei Wiederholung des Ladevorgangs doppelt vorhanden wären. Es gibt jetzt nur noch die Funktionen "Löschen und Laden ...", die in der Praxis auch ausreichen.
Zusätzlich zu Dunkelsteuerungen (Import und andere Verarbeitungen ohne Maske) können nun auch Übersichtsanwendungen in den Automaten eingebunden werden, z.B. um die Verarbeitungsergebnisse sofort anzeigen zu lassen.
Analog anderen Aufrufanwendungen wurde im Selektionsbereich ein Eingabefeld für die Sprache ergänzt. In Abhängigkeit dieser Sprache werden die Betextungen der angezeigten Menüpunkte gelesen.
Die Aufbereitung der Werte in den Spalten <Akt.Per> und <V-Periode> erfolgt jetzt im Periodenformat. Die Tageszahl ("01.") wird dabei unterdrückt.
Durch Markieren einer Zeile in einer Automatenanwendung und Taste <F1> wird der Hilfetext zu der in der markierten Zeile angegebenen Anwendung angezeigt.
Das Release-spezifische Konvertierprogramm KONV0513 führt zusätzlich zu den bereits in KONV0512 enthaltenen Verarbeitungen folgende Schritte durch:
Mit dem Release 5.1.3 wurden folgende Dokumentationen aktualisiert:
Mit dem Release 5.1.3 wird das Release 2.2.1 des IDL Connectors ausgeliefert. Einzelheiten entnehmen Sie bitte Was ist neu im Release 2.2.1 ?
Die auf der CD "IDL IDL Konsis 5.1.3" enthaltenen Schnittstellen zum SAP-System enthalten folgende Erweiterungen:
Einzelheiten zu evtl. notwendigen Anpassungsmaßnahmen sind im Dokument doku \ Interfaces \ SAP \ kcusap.pdf auf der CD "IDL IDL Konsis 5.1.3" enthalten.
Mit dem Release 5.1.3 wird ein neuer Stand der DCW-Schnittstellen ausgeliefert. Gegenüber dem seit Release 5.1.1 enthaltenen Stand ist folgende Änderung erfolgt: