Mit dieser Anwendung können Sie die in einer externen Datei gespeicherten Kontendaten in IDLKONSIS importieren. Sie können die Daten mehrfach übernehmen. Dabei werden nur die Veränderungen gespeichert.
Fehlerfreie Daten können Sie sich über die Anwendung Konten Übersicht (KTO) anzeigen lassen oder nachbearbeiten. Fehlerhafte Daten werden in eine Datei geschrieben, die Sie sich über die Anwendung Daten-Import und -anzeige (IMPORT) anzeigen lassen können.
Seit Einführung der <Flexiblen Import/Export-Formate> stehen die bisher im nächsten Abschnitt beschriebenen Angaben jetzt für
zur Verfügung.
Die nachfolgende Tabelle beschreibt das IDLKONSIS-Standard-Übergabeformat für die Konten-Daten KPKONTEN.TXT. Folgende Abkürzungen werden verwendet:
- in der Spalte "Kann/Muss-Feld" (*):
- in der Spalte "Feld-Ausrichtung" (Ausr):
Anmerkung:Enthält ein Kann-Feld einen '*', so wird ein in IDLKONSIS bereits bestehender Wert/Eintrag gelöscht.
Anmerkung:Attributewerte der Account Methoden brauchen nicht mit SPACE aufgefüllt werden.
| Feldname | * | Stellen | Länge | Ausr | Bezeichnung/Erläuterung | Account Methoden Name |
|---|---|---|---|---|---|---|
| MD | M | 1 - 2 | 2 | Konstante: 'KP' | - | |
| PROJID | M | 3 - 5 | 3 | Projekt-ID Konstante: 'KON' | - | |
| Aktion | M | 6 | 1 | Konstante: '3' | - | |
| KTP | M | 7 - 12 | 6 | L | Kontenplanschlüssel | setAccountPlanId |
| KTO | M | 13 - 26 | 14 | L | Kontonummer | setAccountNumberId |
| SPRID | M | 27 - 29 | 3 | L | Sprachenschlüssel lt. SPR z.B. 'DEU' oder 'ENG' | setDescriptionLanguageId |
| BENE-KTO | M | 30 - 99 | 70 | L | Kontobezeichnung | setDescription BENE1+2 mit Länge 70! |
| KURZW-KTO | 100 -109 | 10 | L | Kontokurzwort | setShortDescription | |
| BIL/GuV-KNZ | m | 110 | 1 | '1' für Aktiva, '2' für Passiva, '3' für Ertrag, '4' für Aufwand | setBsplCode | |
| KTO-KNZ1 | 111 | 1 | Konto-Kennzeichen 1, z.B. 'I' für Intercompany oder 'B' für Beteiligungen | setAccountFlag | ||
| AN-GES | 112-117 | 6 | L | IC-Gesellschaft lt. Gesellschaften und Ges.Verarbeitung (GES) bei IC-Hauptkonten | setInterCompanyId | |
| V-KTO | 118-131 | 14 | L | Verdichtungskonto | setAggregationAccountAccountNumberId | |
| W-KTO | 132-145 | 14 | L | Wechselkonto | setChangeAccountAccountNumberId | |
| KONZ-KTP | 146-151 | 6 | L | Konzern-Kontenplan lt. Kontenpläne/Kostenstellenpläne (KTP) | setGroupAccountAccountPlanId | |
| KONZ-KTO | 152-165 | 14 | L | Konzern-Konto lt. Konten (KTO) in Verbindung mit dem Konzern-Kontenplan | setGroupAccountAccountNumberId | |
| GUELTIG-AB | m | 166-175 | 10 | L | In Form von TT.MM.JJJJ. Fehlt das Datum und ist unter dieser Kontonummer noch kein Stammsatz in IDLKONSIS gespeichert, so wird das Gültig-ab-Datum des Kontenplans als Default-Wert übernommen. | setValidFrom |
| GUELTIG-BIS | 176-185 | 10 | L | In Form von TT.MM.JJJJ | setValidUntil | |
| KTO-KNZ2 | 186 | 1 | gültiges Konto-Kennzeichen 2 | setAccountFlag2 | ||
| AN-UBR | 187-192 | 6 | L | IC-Unternehmensbereich lt. UBR bei IC-Hauptkonten | setInterCompanyBusinessUnitId | |
| KONS-VERARB | 193-194 | 2 | L | Konsolidierungsverarbeitung lt. Konten-Verwendung in KVA | setConsolidationFunction | |
| UBR | 195-200 | 6 | L | Unternehmensbereich lt. UBR | setAccountBusinessUnitId | |
| E-KTO-GEN | 201 | 1 | 'X' = E-Konto generieren (bei Bilanz-Konten - Saldierungsverbot) | setGenerateEAccount | ||
| E-RELART | 202 | 1 | Gültige Rechnungslegungsart. Die Angabe ist nur bei Konzernkonten zugelassen. Bei einem Gesellschaftskonto wird das Kennzeichen aus dem KTP entnommen. Dieses Kennzeichen muss mit dem Kennzeichen des zugeordneten Konzernkontos übereinstimmen, falls bei diesem ein Rechnungslegungskennzeichen hinterlegt ist. | setAccountingType |
Vor der eigentlichen Verarbeitung der Eingabedaten werden diese eventuell programmintern mit Standard-Werten belegt oder umgesetzt.
Enthält das ensprechende Feld in dem Eingabesatz den Wert '*', werden die dazu gehörenden Felder AN-GES, AN-UBR und KONS-VERARB ebenfalls als gelöscht gekennzeichnet und bei Änderung eines vorhandenen Datensatzes auf leer gesetzt.
Ist in dem Eingabesatz das Kontokennzeichen 1 mit dem Wert 'I' belegt und enthält das Konto in der Anwendung Konten (KTO) in dem Kontokennzeichen den Wert 'B' , so bleibt der Wert 'I' aus dem Eingabesatz unberücksichtigt. 'B' bleibt erhalten.
Ist in dem Eingabesatz kein Bilanz-/GuV-Kennzeichen enthalten, so wird die Ermittlung für die Standardbelegung in folgender Reihenfolge vorgenommen:
Ist in dem Eingabesatz ein Verdichtungskonto enthalten, so werden das Bilanz-/GuV-Kennzeichen, das Kontokennzeichen 1, das Kontokennzeichen 2 (Ausnahme: es handelt sich um ein Anlagenkonto) und die Konsolidierungsverarbeitung aus dem Verdichtungskonto übernommen.
Ist in dem Eingabesatz eine zugeordnete Konzernkontonummer ohne Konzernkontenplan vorhanden, so wird als Standardbelegung für den Konzernkontenplan der dem Kontenplan lt. Kontenpläne/Kostenstellenpläne (KTP) zugeordnete Konzernkontenplan übernommen.
Die in der Eingabedatei vorhandenen Felder Kontenplan, Konzern-Kontenplan, Gesellschaft und Unternehmensbereich können durch die Angabe einer Umsetzgruppe in der Aufrufanwendung von einem externen Schlüsselsystem in die IDLKONSIS-Schlüssel umgesetzt werden. Das ist z.B. der Fall, wenn Sie in IDLKONSIS eine abweichenden Kontenplan verwenden wollen Voraussetzung für die Umsetzung ist die Pflege von Umsetzgruppen mit Hilfe der Anwendungen Umsetzgruppen (UMS) und Umsetzgruppen zuordnen (UMSOBJ).
Wurde mit Hilfe der Anwendung Kontenpläne/Kostenstellenpläne (KTP) für den Kontenplan aus der Eingabedatei eine Längenangabe für die Kontonummer hinterlegt, so werden folgende für alle Kontonummern in der Eingabedatei folgende Prüfungen vorgenommen:
Enthält der Eingabesatz einen Hinweis auf eine E-Kontogenerierung, so wird, neben dem eigentlichen Konto-Stammsatz ein zweiter Stammsatz mit folgenden Abweichungen generiert:
Wenn die nachstehenden Attribute eines Konzernkontos geändert werden, erfolgt eine Anpassung aller darauf zugeordneten Gesellschaftskonten. Diese Anpassung wird jedoch nur vorgenommen, wenn dem Konzernkonto kein weiteres Konto zugeordnet ist. Betroffen von diesen Änderungen sind die Attribute:
Die Import-Vorgang geschieht in zwei Schritten. Der erste Schritt öffnet eine Transaktion, die erst mit erfolgreichen zweiten Schritt abgeschlossen wird.
Im ersten wird schon das Änderungs- Datum und Benutzer verändert.
Kommt es im zweiten Schritt nun zu einer Unstimmigkeit zwischen Angaben, die sich auf Angaben der Datenbank beziehen, wird der gesammte Import-Vorgang abgebrochen.
Die Änderungs- Datum und Benutzer -Information bleibt nach erfolglosen Import im Veränderten Zustand.