Beispiel: es werden die Rechtsordnungen FRA, POR und USA in einem Ordner verwendet. Haben die Rechtsordnungen FRA und POR die gleiche Parametrisierung, wird empfohlen, einen Datensatz für die Rechtsordnung FRA und einen Datensatz für die Rechtsordnung POR anzulegen, anstatt nur einen einzigen Datensatz für alle Rechtsordnungen zu haben.
Weitere Informationen zur Leistungsverbesserung im Zusammenhang mit Multi-Rechtsordnung und die Liste der Objekte, die Sie nach Rechtsordnung ablehnen können, entnehmen Sie dem folgenden Dokument:Leistungsverbesserung: Liste der Multi-Rechtsordnung-Objekte.
Verkaufsrechnungen setzen sich aus zwei Kopfzeilendateien (SINVOICE und SINVOICEV) und einer Zeilendatei SINVOICED zusammen.
In der Importvorlage müssen Sie daher zwei Identifikatoren parametrisieren:
Für die Tabelle SINVOICE muss keine Id definiert werden, denn die Verbindung zwischen SINVOICEV UND SINVOICE ist am Objekt beschrieben.
Der Import von Rechnungen und Gutschriften ist unabhängig davon möglich, ob diese freigegeben sind oder nicht. Dies wiederum hängt von der Existenz und dem Wert des Feldes INVSTA (Tabelle SINVOICEV) in der Importvorlage ab. Wenn dieses Feld nicht in der Importvorlage vorhanden ist, so wird die Rechnung oder die Gutschrift im System für den nicht freigegebenen und nicht gedruckten Report angelegt.
Werden zwei Zeilen mit der gleichen Artikelreferenz gefunden, muss zur Unterscheidung die Zeilennummer parametrisiert und erfasst werden. Sonst wird stets die erste gefundene Zeile verändert.
Um die korrekte Funktionsweise des Systems gewährleisten zu können, muss die in SIDLIN enthaltene Nummer auch dann erfasst werden (auch bei Anlage), wenn sie von X3 vergeben wird.
Beim Rechnungsimport werden im Änderungsfall die Bestände nicht aktualisiert. Importierte Zeilen mit Bestandsaktualisierung werden im Änderungsfall vom System mit folgender Meldung zurückgewiesen: Die Meldung: „Rechnungsnummer: Artikelcode: Rechnung mit nicht zulässiger Bestandsbewegung“ wird in der Logdatei angezeigt.
Beim Import von Rechnungen und Gutschriften kann die Rechnungsfußzeile entweder automatisch vom System berechnet oder ohne Systemberechnung importiert werden. Welche Vorgehensweise gewählt wird, hängt davon ab, ob die mit der Bewertung der Rechnungsfußzeile verbundenen Daten in der Importvorlage vorhanden sind. Sind diese Daten in der Importvorlage vorhanden, so wird die Rechnung nicht vom System erneut berechnet (dies gilt insbesondere, wenn das Feld AMTATI der Tabelle SINVOICE in der Vorlage vorhanden ist).
Werden Rechnungen mit einer Vorlage importiert, mit der die Rechnungsfußzeile berechnet werden kann, so werden die Rechnungselemente in die Felder INVDTAAMT der Tabelle SINVOICEV übernommen.
Direktrechnungen können inklusive dieser Bestandsbewegungen importiert werden, sofern die importierte Rechnung nicht freigegeben ist. Andernfalls wird keine Bestandsbewegung durchgeführt, und der Indikator Bestandsbewegung wird wieder auf Nein gesetzt.
Um nicht freigegebene Direktrechnungen mit Bestandsbewegung zu importieren, muss in die Importdatei das Feld STOMVTFLG aus der Tabelle SINVOICEV aufgenommen und korrekt belegt werden. Der Abgangsbestand wird mithilfe der Reservierungsregeln der Artikelkategorie ermittelt. Keinesfalls ist es möglich, Gutschriften mit Bestandsbewegungen zu importieren. Das Feld STOMVTFLG wird in diesem Kontext ignoriert und auf Nein gesetzt.
Vom Import von Vertriebsstücklisten und Stücklisten sind lediglich Rechnungen betroffen.
Zu Gutschriften können Vertriebsstücklisten nicht als Artikelgruppe verwaltet werden. Jedes Stücklistenelement wird einzeln verwaltet.
Vertriebsstücklisten und Stücklisten können zu einer Rechnung auf zwei Arten importiert werden:
Sofern dies erforderlich ist, können Texte für die Rechnungskopfzeile, die Rechnungsfußzeile und die Rechnungszeilen importiert werden. Führen Sie diese Parametrisierung in der Importvorlage aus, indem Sie die globale Variable GIMP verwenden (in der Vorlage müssen die Felder *71 etc. angegeben werden).
Siehe Importvorlage SIHFL.
Beim Import kann in der Importvorlage der Auftragskunde spezifiziert werden. Auf diesen wird bei der Rechnungsanlage zurückgegriffen .Insbesondere wird der Auftragskunde bei der Festlegung der Preise und Nachlässe berücksichtigt, sofern diese nicht Teil der Importvorlage sind.
Es können Beziehungsfelder importiert werden, über die der Ursprung der Rechnung oder der Gutschrift oder der Ursprung der Rechnungs- oder Gutschriftszeilen ermittelt werden kann. Diese Angaben werden rein zu Informationszwecken gemacht. Die Originalbelege – sofern im System vorhanden – werden unter keinen Umständen aktualisiert.
Die offenen Posten werden nicht importiert. Sie werden aus der Zahlungsbedingung der Rechnung berechnet.
Damit der Import korrekt vonstatten geht, müssen die während des Imports verwendeten Daten zu folgenden Tabellen vorhanden sein:
In diesem Import sind die folgenden Felder Pflichtfelder:
Wenn Verkaufsstandort und (bei Rechnungen mit Bestandsbewegung) Lagerstandort nicht in der Importvorlage vorhanden sind, werden diese Standorte in der den Import ausführenden Sitzung auf den Standardverkaufsstandort und den Standardlagerstandort gesetzt.
Wenn die Verkaufseinheit nicht angegeben ist, wird sie auf die Verkaufseinheit des Kunden, dann des Artikels gesetzt.
Ist kein Rechnungstyp angegeben, wählt das System den ersten aus der alphabetischen Liste. Dadurch ist der Rechnungs- oder Gutschriftstyp festgelegt (auch bei INVTYP in der Vorlage).
Sind die Felder Rechnungsstatus (INVSTA) und Bestandsbewegung (STOMVTFLG) nicht in der Importvorlage vorhanden, werden sie auf Nein gesetzt.
Während der Erfassung können außer den generischen Meldungen folgende Fehlermeldungen auftreten: :
Beim Rechnungsimport werden alle Prüfungen durchgeführt, die auch bei der interaktiven Erfassung durchgeführt werden. Dabei handelt es sich an erster Stelle um:
Verkaufsstandort nicht vorhanden: Meldung nach der Prüfung des Verkaufsstandorts zur Rechnung.
Lagerstandort nicht vorhanden: Meldung nach der Prüfung des Lagerstandorts zur Rechnung beim Rechnungsimport mit Bestandsbewegung.
Kunde XXX Datensatz existiert nicht: Meldung nach der Prüfung auf Existenz des Kunden.
Artikel YYY: Datensatz existiert nicht: Meldung nach der Prüfung auf Existenz des Artikels und des Verkaufsartikels.
Einheit ZZZ Datensatz existiert nicht: Meldung nach der Prüfung auf Existenz und Gültigkeit der Artikeleinheit.
QTY Eingabe erforderlich: Meldung nach der Prüfung auf Existenz dieser Daten beim Import einer Rechnung.
Diese Vorlage kann sowohl beim Import als auch beim Export verwendet werden. Die Daten werden in den folgenden Tabellen aktualisiert :
Tabelle | Tabellentitel |
---|---|
BPARTNER [BPR] | |
BPCUSTMVT [MVC] | Kundenbewegungen |
BPCUSTOMER [BPC] | |
BPDLVCUST [BPD] | |
CONTSERV [CON] | |
CPTANALIN [CAL] | Kostenrechnungsbuchungszeilen |
FACILITY [FCY] | |
GACCCODE [CAC] | |
GACCOUNT [GAC] | |
GTYPACCENT [GTE] | |
HDKTASKINV [HDI] | Zu fakturierende Verbräuche |
ITMBPC [ITU] | |
ITMCATEG [ITG] | |
ITMFACILIT [ITF] | |
ITMMASTER [ITM] | |
ITMMVT [ITV] | Artikel-Standort gesamt |
ITMSALES [ITS] | |
ITMWRH [ITW] | |
LPN [LPN] | |
PRICSTRUCT [PRS] | |
SALESREP [REP] | |
SDELIVERY [SDH] | |
SDELIVERYD [SDD] | Detail Lieferung |
SERREQUEST [SRE] | |
SFOOTINV [SFI] | |
SINVOICE [SIH] | Verkaufsrechn |
SINVOICED [SID] | Detail Verkaufsrechnung |
SINVOICEV [SIV] | Verkaufsrechnung Bewertung |
SORDER [SOH] | |
SORDERP [SOP] | Verkaufsaufträge - Preise |
SORDERQ [SOQ] | Verkaufsaufträge - Mengen |
SPRICLINK [SPK] | Suche Verkaufspreise (Link) |
SPRICLIST [SPL] | Kundenpreis |
SRETURND [SRD] | Detail Retour Verkauf |
STOCK [STO] | Lager |
STOJOU [STJ] | Journal Lagerbewegungen |
STOLOT [STL] | Chargennummern |
SVCRFOOT [SVF] | Vertriebsdokument - Fußzeilenelement |
SVCRVAT [SVV] | Vertriebsdokument - Steuern |
TABCONTAINER [TCTR] | |
TABCUR [TCU] | |
TABPRTMOD [TPM] | |
TABSIVTYP [TSV] | |
TABUNIT [TUN] | |
WAREHOUSE [WRH] |