Das Release 5.1.2 ist ein Zwischenrelease und kann daher in der Releasefolge ausgelassen werden. Voraussetzung für das Release 5.1.2 ist das letzte Hauptrelease 5.1.0 vom 7. 10. 2002. Die Nachträge und Korrekturen zum Release 5.1.0 sowie das Zwischenrelease 5.1.1 mit seinen Nachträgen und Korrekturen sind im Release 5.1.2 enthalten. Die bereits mit dem Release 5.1.1 enthaltenen Änderungen sind in der Dokumentation zum Release 5.1.1 beschrieben.
An der Datenbank-Schnittstelle gab es im Release 5.1.2 keine Änderungen. Zur Erreichung der Kompatibilität mit der Datenbank MS SQL Server erfolgt derzeit aber ein komplettes Redesign der Datenbank-Schnittstelle. Dieser Stand wird voraussichtlich im nachfolgenden Release 5.1.3 im Juni 2003 ausgeliefert werden. 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 sinnvoll, wenn die Anwender bereits in der nächsten Zeit auf diese Releasestände aufrüsten. Bei Oracle empfehlen wir gleich den Upgrade auf Release 9.0 oder 9.2.
Im Menüpunkt <Extras> -> <Optionen> -> <Darstellung> gibt es die neue Einstellung "Daten sofort anzeigen". Ist diese Einstellung gesetzt, erfolgt beim Start einer Anwendung nach Kurzworteingabe oder Auswahl aus dem Menübaum sofort die Datenanzeige, ohne dass der Button <Aktualisieren> oder die Taste <Enter> betätigt werden muss, falls alle Musseingabefelder der Maske vorbelegt sind. Diese Einstellung bleibt für folgende IDL.KONSIS.FORECAST-Aufrufe erhalten.
Im Menüpunkt <Extras> -> <Optionen> -> <Allgemein> gibt es die neue Einstellung "autom. Start der letzten Anwendung". Ist diese Einstellung gesetzt, erfolgt beim Start von IDL.KONSIS.FORECAST der Aufruf der bei einer Beendigung von IDL.KONSIS.FORECAST zuletzt noch aktiven Anwendung, ohne dass eine Kurzworteingabe oder Auswahl aus dem Ressourcenbaum notwendig ist. Diese Einstellung bleibt für folgende IDL.KONSIS.FORECAST-Aufrufe erhalten.
Mehrere Anwendungen hatten Masken mit einer Breite, dass bei Standard-Anzeige des Ressourcenbaums nicht mehr alle Felder im Fenster ausgegeben werden konnten, so dass ein horizontaler Scroll-Bar erschien. Diese Masken wurden überarbeitet, so dass dieser Effekt jetzt nur noch auftritt, wenn das Fenster noch kleiner eingestellt wird. Dazu wurden teilweise Übersetzungen abgekürzt oder Felder umsortiert.
Folgende Menü-IDs sind in diesem Release neu. Falls kundenspezifische Benutzergruppen verwendet werden, müssen für diese Menüpunkte Berechtigungen (BENMEN) gepflegt werden. Als Vorlage können die Menüberechtigungen der Benutzergruppe IDLKON dienen.
Im Menüzweig Systemadministration bzw. im Projekt Architek wurde die neue Stammanwendung MED ergänzt. Diese Anwendung dient der Vorbereitung der geplanten Möglichkeit, Bilder in die Online-Dokumentation aufzunehmen, kann aber derzeit noch nicht genutzt werden.
Bei Einschränkung der Benutzerberechtigung für Positions- und Kontenpläne (Berechtigungsstufe '2' in VORADMINE) erfolgt jetzt bei der Zuordnung von Konten zu Positionen für den Kontenplan nur noch eine Berechtigungsprüfung auf die Aktion <Lesen>. Der Positionsplan wird dagegen weiterhin gemäß der aktuellen Aktion (<Einfügen>, <Löschen>) geprüft.
Es wurde die Möglichkeit geschaffen, für die Kontensalden zu einem Schlüssel (Gesellschaft, Ubr, Periode, Datenart) Prüfsummen ermitteln zu lassen. Diese Prüfsummen werden nach dem CRC-Verfahren (Cyclic Redundancy Check) in allen Anwendungen neu ermittelt, in denen die Salden geändert werden können und in der Tabelle/Anwendung VERARB gespeichert bzw. angezeigt. Zusätzlich erfolgt eine Anzeige im Summenblock der Übersicht KTOSAL. In die Prüfsumme fließen neben den Werten auch die Kontonummern und die Gesellschaftsnummer ein. Es gibt jeweils eine Prüfsumme für Landes-, Konzern- und Parallelwährung.
Zur Steuerung, ob die Prüfsummenberechnung genutzt werden soll, wurde eine Einstellung in der Anwendung FAC ergänzt. Wird hier kein Eintrag vorgenommen, erfolgt keine Prüfsummenberechnung. In der Praxis dürfte die Prüfsummenberechnung nur für Datenarten interessant sein, auf denen Reports erstellt werden.
Die Prüfsummen dienen u.a. der Kontrolle, ob Salden nach der Zertifizierung eines Reports noch geändert wurden. Dazu wird die aktuelle Prüfsumme bei der Ausgabe eines Reports (REPERG) im Kopfteil angezeigt und damit auch ausgedruckt, falls der Report auf eindeutigen Schlüsseln (nur eine Gesellschaft und ein Unternehmensbereich) beruht.
Damit für abgeschlossenen Perioden keine Änderung der Checkpoint-Angaben (Übersicht VERARB) mehr erfolgt, wird eine Berechtigungsprüfung auf die Periode durchgeführt. Bei aktiviertem Berechtigungsschutz für Perioden wird daher keine Prüfsumme für gesperrte Perioden gebildet.
In den Übersichten ICKTOSAL und GESGES wird die Spalte IC-Gesellschaft (einschl. des zugehörigen Kurzwortes) jetzt vor dem Wert-LW in der Tabelle angeordnet.
Wenn mit der AGGKTO-Steuerung nach Kostenstellenkennzeichen gearbeitet wird, erfolgt jetzt bei der Selektion der Kostenstellensalden nach Positionsnummer eine Überprüfung der Übereinstimmung des Kostenstellen-Kennzeichens mit dem der Position zugeordneten Kostenstellen-Kennzeichen.
Analog zu den Saldentabellen wird jetzt auch die Stimmigkeit der Bewegungsaufrisse in den jeweiligen Übersichten (ANLBEW, KAPBEW, RUEBEW, GESGES) sowie in allen Anwendungen, die diese Daten ändern (Einzelsatz, Import, Vortrag, Währungsumrechnung) überprüft und in einem Checkpoint-Satz (Übersicht VERARB) hinterlegt. Der Zustand für eine Gesellschaft wird in der Übersicht GES in zusätzlichen Spalten ausgegeben. Neben der Konsistenz zu den Kontensalden werden folgende Sachverhalte geprüft:
In diese Prüfungen werden nur die Gesellschaftsbewegungen einbezogen. Die Konzernbewegungen und deren Konsistenz zu den Konsolidierungsbuchungen werden nicht überprüft.
Damit für abgeschlossene Perioden keine Änderung der Checkpoint-Angaben (Übersicht VERARB) mehr erfolgt, wird jetzt eine Berechtigungsprüfung auf die Periode durchgeführt. Bei aktiviertem Berechtigungsschutz für Perioden werden daher keine VERARB-Sätze für gesperrte Perioden erzeugt.
In den Einzelsatzanwendungen für Bewegungsdaten (ANLBEWE, KAPBEWE, RUEBEWE, GESGESE) wird jetzt auch bei Buchungsschlüsseln mit fester Soll/Haben-Zuordnung die Eingabe negativer Werte zugelassen, um Daten mit umgekehrtem Soll/Haben-Kennzeichen erfassen zu können. Statt der bisherigen Fehlermeldung kommt jetzt nur noch eine Warnung.
Für den Konzern-Rückstellungsspiegel gibt es den neuen Buchungsschlüssel 32 für Veränderungen des Konsolidierungskreises. Da hier keine Zuordnung eines Soll/Haben-Kennzeichens erfolgt ist, sind Haben-Werte als positive Eingabewerte, Soll-Werte dagegen als negative Werte zu erfassen.
Analog zu den Konsolidierungsbuchungen (s.u.) wird jetzt auch in der Beleg-Übersicht BEL der ergebniswirksame Betrag eines ergebniswirksamen Beleges in einer neuen Spalte ausgewiesen.
Damit für abgeschlossene Perioden keine Änderung der Belegköpfe mehr erfolgt, wird jetzt eine Berechtigungsprüfung auf die Periode durchgeführt. Bei aktiviertem Berechtigungsschutz für Perioden werden für gesperrte Perioden die Fehlerinformationen und die Ergebniswirksamkeit der Belege nicht mehr aktualisiert.
Ein in der TXT-Datei angegebenes Soll/Haben-Kennzeichen für Salden wird jetzt immer verwendet und nicht durch einen Defaultwert überlagert. Nur wenn das Soll/Haben-Kennzeichen leer ist, wird der Standard gemäß Bil/GuV-Kennzeichen eingestellt. Bei Eingabe negativer Werte wird dieses Soll/Haben-Kennzeichen gedreht, damit nur positive Werte gespeichert werden.
Die Aktion "Löschen und Import" kann nicht aufgerufen werden, wenn die Periode nicht eindeutig ist. Dazu wird jetzt eine Fehlermeldung von der Aufrufanwendung IMPORT ausgegeben.
Da die Bewegungen ähnlich wie die IC- und Kostenstellen-Salden auf Eingangsdatenarten nicht immer stimmig sind, soll ein Vortrag auch im Fehlerfall möglich sein. Es wird nur eine Warnung ausgegeben.
Wenn die Herkunftsdatenart mit UBR-Führung und die Zieldatenart ohne UBR-Führung definiert ist, dann wird auch bei einem Fehler in den IC-Salden keine Warnung mehr ausgegeben.
Die Währungsumrechnung prüft jetzt, ob die Währungskennzeichen (WKZ) gemäß Stammdaten (GES sowie KTK bzw. VOR) mit den Währungskennzeichen gemäß Salden-Checkpoint (VERARB) übereinstimmen. Wenn es Abweichungen gibt, wird ein Meldungsfenster mit einem entsprechenden Hinweis ausgegeben. Der Benutzer kann dann wählen zwischen der Umrechnung nach WKZ gemäß Stammdaten und der Umrechnung nach WKZ gemäß Salden-Checkpoint.
Für die AfA-Konten (Konto-Kennzeichen = 'D') kann jetzt (in der Anwendung KTOUAW) die Umrechnungsanweisung 'FDK' angegeben werden. Dies bewirkt, dass diese Konten mit dem durchschnittlichen Wechselkurs aller Anlagenbewegungen für die laufende AfA (Spiegelspalte 13) umgerechnet werden. Als Ergebnis sollte die Summe der umgerechneten AfA-Kontensalden der Summe der Anlagenbewegungen für die laufende AfA entsprechen, abgesehen von Rundungsdifferenzen. Die entsprechende Bedingung des Anlagenspiegels wird dadurch automatisch erfüllt, wenn die Werte in Landeswährung übereinstimmten. Diese Funktion ist insbesondere dann hilfreich, wenn die Abschreibung gemäß der Wechselkurse zum Anschaffungszeitpunkt gerechnet werden soll.
Bei der Währungsumrechnung von Konten mit Umrechnungsanweisung 'FDK' wird die Kursdifferenz jetzt je Konto ermittelt und gespeichert. Die Speicherung erfolgt in der Tabelle KTOUAW. Die im WUM-Kopfsatz angegebene gesamte Bilanzdifferenz sollte durch diese Differenzen je Konto erklärt werden können, abgesehen von Rundungsdifferenzen. Wie die Gesamtdifferenz werden auch die Differenzen je Konto in die Folgeperiode vorgetragen. Daraus wird in KTOUAW ggfs. der Kurseffekt aus der aktuellen Periode errechnet.
Auch wenn Anlagenkontensalden nicht historisch (mit 'FDK') umgerechnet wurden, kann es sein, dass nach Verbuchung der Kurseffekte durch zusätzliche Anlagenbewegungen eine (Rundungs-)Differenz zum Kontensaldo übrigbleibt, die auf dem Kontensaldo verrechnet wird. Neben der Bemerkung "Anlagenspiegel Differenz" wird auch der Differenzbetrag in der neuen Spalte der Übersicht KTOUAW ausgewiesen.
Der Wechsel in die Übersicht KTOUAW aus der Übersicht WUM bzw. der Einzelsatzanwendung WUME ist jetzt auch für Inlandsgesellschaften (Landeswährung = Konzernwährung) möglich, damit ggfs. Umrechnungsanweisungen für die PW-Umrechnung gepflegt werden können. Das gleiche gilt auch für die automatische Aktualisierung des Umrechnungsstamms.
Die Übersicht KTOUAW weist jetzt unter bestimmten Bedingungen (s.o.) die Abweichungen zwischen der Umrechnung von Bilanz-Kontensalden zur reinen Stichtagskursumrechnung in einer zusätzlichen Spalte aus.
Bei der Erfassung oder Änderung von Umrechnungsanweisungen, die vom Standard gemäß dem im WUM-Kopfsatz angegebenen Umrechnungsverfahren abweichen, wird keine Warnung mehr ausgegeben. Stattdessen zeigt die Übersicht durch eine besondere Meldung in der Meldungszeile an, wieviele Konten mit einer vom Standard abweichenden Umrechnungsanweisung versehen sind. Dadurch wird insbesondere die Mengenänderung vereinfacht.
Die ab-Periode in der Übersicht KTKPAR wird jetzt nicht mehr vorbelegt, so dass in der Standardanzeige nur noch die Daten für die aktuelle Periode angezeigt werden.
In der Übersicht KTKPAR werden leere Spalten nicht mehr ausgegeben. Das erleichtert insbesondere die Anzeige verschiedener Parameter für eine Konsolidierungsverarbeitung (z.B. SK).
Es gibt jetzt einen neuen Konsolidierungsparameter für latente Steuern (LT) (s.u. ).
Zur Vereinfachung des Aufrufs der automatischen Konsolidierungsverarbeitungen SK, AE, KE, KS, KA und KV wurde eine Automatensteuerung geschaffen. In dieser Folgeanwendung der Anwendung KTKGES wird eine Liste ausgegeben, die die Kombination aller Gesellschaften des KTK mit o.g. Konsolidierungsverarbeitungen enthält. Zur Ausführung müssen alle Zeilen markiert (z.B. über das Menü <Bearbeiten>) und dann die Verarbeitung durch die Aktion <Ausführen der markierten Anwendung> gestartet werden. Die Verarbeitungsprogramme wurden so geändert, dass einfache Hinweismeldungen die Verarbeitungsfolge nicht unterbrechen. Das Ergebnis kann über den Status in KTKGES kontrolliert werden.
Bei der Beteiligungsermittlung werden jetzt zusätzlich auch folgende Flags in KTKGES voreingestellt.
Wenn eine Verarbeitung bereits durchgeführt ist (Status 'X' bzw. 'T' im Teilkonzern), wird der Status nicht verändert.
Die Aktion <Ausschluss KapKons-Buchungen aus Teilkonzern> setzt jetzt bei übereinstimmenden Prozentsätzen das Kennzeichen 'T' auch für die Konsolidierungsverarbeitungen KA und KM. Diese Verarbeitungen können dann im aktuellen Konzern nicht durchgeführt werden.
Die Funktion der Vortragsanwendungen für Konsolidierungsbuchungen (KF und VK) wurde in den Konzernvortrag (PERKTK/VORPERKTK) integriert. Der Vortrag erfolgt dort automatisch für alle Gesellschaften eines Konzernkreises. Die Übersichten KONBEL und KONBUCH wurden als Folgeanwendungen in der Aufrufanwendung PERKTK ergänzt. Die bisherigen Anwendungen können aber vorerst auch noch für sich und je Gesellschaft aufgerufen werden, wenn sich Änderungen an den Vorperiodendaten ergeben haben. VK wurde aber an das Ende des Aktionsmenüs von KTKGES verlegt.
Werden beim Vortrag mehrere Belege mit unterschiedlichen Buchungsarten zu einem Beleg zusammengefasst, so wird die Buchungsart des neuen Belegs jetzt nach festen Regeln vergeben und bleibt nicht mehr leer.
Bei der Eliminierung der direkten (KA) und der indirekten (KV) Fremdanteile werden jetzt nicht mehr für jeden Unternehmensbereich Buchungen auf den Eliminierungskonten erzeugt, sondern nur noch dann, wenn diese Werte ungleich null enthalten.
In der Übersicht ZWERGUV zur Anzeige der IC-Bewegungen für die Zwischenergebniseliminierung im Umlaufvermögen wird jetzt die aktuelle Gesellschaft angezeigt.
Die Anwendung ZWERGUV überprüft jetzt den ZU-Status der Übersicht KTKGES und setzt ihn ggfs. neu, z.B. wenn neue IC-Bewegungen hinzugekommen sind.
Es ist jetzt möglich, in der Anwendung ICBEWE den Eliminierungsbetrag als Absolutwert anzugeben. Diese Eingabe wird mit Vorrang vor der Angabe eines Zu/Abschlags-%-Wertes behandelt. Die Eingabe negativer Werte entspricht der Angabe eines negativen Zu/Abschlags-%-Satzes.
Der Buchungsbetrag bei der Zwischenergebniseliminierung im Umlaufvermögen errechnet sich nach folgender Formel:
Zu/Abschlags-%-Wert
Buchungsbetrag = ------------------------- * Wert(ICBEW)
Zu/Abschlags-%-Wert + 100
Der Zu/Abschlags-%-Satz, der in den Anwendungen ICBEW oder PRODAT angegeben werden kann, durfte dabei nicht größer als 100 werden. Der Buchungsbetrag konnte daher maximal die Hälfte des Wertes aus ICBEW betragen.In der Praxis gibt es jedoch Fälle, in denen ein größerer Betrag zu buchen gewesen wäre. Es wird daher künftig ein Prozentsatz im Wertebereich {-99,99 ... +999,99} zugelassen. Falls ein Prozentsatz von 1000 oder mehr notwendig wäre, muss der Eliminierungsbetrag absolut eingegeben werden (s.o.).
Die Funktion der Berechnung und Verbuchung von latenten Steuern wurde komplett überarbeitet. Zur Unterscheidung von Belegen, die noch manuell oder mit der alten Funktionalität für latente Steuern erstellt wurden, erhalten die neu erstellten Belege die Konsolidierungsverarbeitung 'LT' anstelle von 'LS'. Dazu wurden folgende Änderungen vorgenommen:
Damit für abgeschlossene Perioden keine Änderung der Belegköpfe mehr erfolgt, wird jetzt eine Berechtigungsprüfung auf die Periode durchgeführt. Bei aktiviertem Berechtigungsschutz für Perioden werden für gesperrte Perioden die Fehlerinformationen und die Ergebniswirksamkeit der Konsolidierungsbelege nicht mehr aktualisiert.
Beim Kopieren von Konsolidierungsbuchungen auf einen anderen Konzern/Tk werden jetzt die Angaben von Anlagenobjekten nicht mehr mitkopiert, weil Anlagenobjekte immer fest einem Konzern/Tk zugeordnet sind. Dementsprechend werden für die kopierten Buchungen auch keine korrespondierenden Anlagenbewegungen erzeugt. Dasselbe Problem stellt sich auch für reporttechnische Teilkonzerne, für die daher kein Anlagenspiegel möglich ist.
Bisher wurde beim Komplettaufriss ein Konto mit S/H-Steuerung nur auf der Standardseite gezeigt (z.B. ein Aktivkonto unter der Position, der es mit Soll-Steuerung zugeordnet war). Auf der Nicht-Standard-Seite wurde ein Konto allerdings zusätzlich dann gezeigt, wenn der Kontensaldo in irgendeiner Periode einen abweichenden Wert ergab (z.B. ein Haben-Saldo auf einem Aktiv-Konto). In diesem Fall wurde die betreffende Kontenzeile zusätzlich mit der Meldung 'KON0456I' versehen. In Zukunft wird das Konto auch auf der Nicht-Standard-Seite immer gezeigt.
Bisher wurden bei einem Periodenreport die Parameter für eine Reportspalte (Periode und Datenart) nicht gesetzt, wenn in eine Spalte Daten aus mehreren Reportperioden eingeflossen waren. Da dies bei einer Monats-GuV mit Darstellung der Aufwendungen und Erträge nicht möglich ist (ab 2. Monat Differenz zum Vormonat), wurde dies geändert. In Zukunft wird immer die Periode des ersten gefundenen Reportwertes verwendet. Die Fehlervermeidung muss also ab sofort bei der Definition der Spaltenbeschreibung erfolgen.
Bisher fehlte eine Möglichkeit, auf die Werte der letzten Periode im Periodenreport bei einer Spaltenbeschreibung zuzugreifen, da die letzte Periode in Abhängigkeit von den Schlüsseln im Reportkopfsatz variiert. Zu diesem Zweck werden die neuen Positionen '#REP# AKTSALD' und '#REP# AKTBUCH' eingeführt, die in der Anwendung REPERG durch die Werte der letzten (aktuellen) Periode ersetzt werden.
Ausserdem wird in Zukunft bei der Reportanzeige jede Spalte angezeigt, die sich aus Daten gültiger Perioden ergibt. Bisher wurden gültige Spalten nicht mehr angezeigt, wenn sie hinter einer ungültigen Spalte standen.
Für den Konzern-Rückstellungsspiegel gibt es den neuen Buchungsschlüssel 32 für Veränderungen des Konsolidierungskreises. Dieser ist der neuen Spalte 08 im Konzern-Rückstellungsspiegel zugeordnet. In der Standard-Spaltenoption #RUEK für den Rückstellungsspiegel wurde die neue Spalte zwischen den Spalten für Umbuchung und für automatische Differenzenklärung eingefügt. Wird der neue Buchungsschlüssel nicht verwendet, wird diese Spalte in der Reportanzeige unterdrückt. Kundenindividuelle Spaltenoptionen für den Konzern-Rückstellungsspiegel sind ggfs. entsprechend anzupassen.
Der Teilkonzern- und Gesellschafts-Datenaustausch wurde um die Reportergebnistabelle erweitert. Die Report-Kopfsätze waren bereits enthalten. Die so verursachten längeren Laufzeiten werden dadurch kompensiert, dass die Teilkonzern-Reports in der Zentrale nicht mehr neu erstellt werden müssen.
Der Teilkonzern- und Gesellschafts-Datenaustausch wurde aufgrund verschiedener Tabellenerweiterungen so angepasst, dass die Übernahme von Daten aus älteren Releaseständen (ab Release 5.03, Korrekturstand B) möglich ist.
Zum Release 5.1.2 gehört ein Konvertierprogramm, das nach Einspielen des neuen Releases gestartet werden sollte. Dieses Programm überprüft, ob Bilanz-IC-Konten mit der Konsolidierungsverarbeitung AE versehen wurden, so dass AE-Konsolidierungsbelege ergebniswirksam sein können. Dies sollte vermieden werden, wenn die neue Funktionalität für latente Steuern genutzt werden soll, weil AE-Belege nicht zur Berechnung latenter Steuern herangezogen werden können. Die Lösung besteht darin, diese Konten in die Schuldenkonsolidierung (SK) einzubeziehen.
Mit dem Release 5.1.2 wurden folgende Dokumentationen aktualisiert:
Mit dem Release 5.1.2 wird das Release 2.20 des IDL Connectors ausgeliefert. Es enthält erstmals den Erfassungsbaustein KVM100 als integrierte Zusatzkomponente. Einzelheiten entnehmen Sie bitte der Dokumentation excel \ IDL_Connector_220_-_Was_ist_neu.doc
Die auf der CD "IDL IDL.KONSIS.FORECAST 5.1.2" 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.FORECAST 5.1.2" enthalten.
Mit dem Release 5.1.2 wird der bereits im Release 5.1.1 enthaltene Stand der DCW-Schnittstellen ausgeliefert. Einzelheiten dazu siehe in der Dokumentation zu Release 5.1.1.