In diesem Dokument werden die Vorgehensweisen für den Umgang mit der Anwendung „Daten importieren“ bezogen auf Artikel beschrieben. Diese Vorgehensweisen enthalten allgemeine Anleitungsschritte, z. B. welche Reihenfolgen beim Import der Artikel einzuhalten sind. Sie werden außerdem über mögliche Voraussetzungen und Auswirkungen informiert.
Die Beschreibung der Anwendung „Daten importieren“, die unter anderem auch Feld- und Button-Beschreibungen enthält, finden Sie in der Dokumentation „Daten importieren“.
1 Allgemeines
Der Datenaustausch zwischen Comarch-ERP-Enterprise-Systemen wird in den Dokumentation „Daten importieren“ und „Daten exportieren“ beschrieben. Dieses Dokument beschreibt den Import aus Altsystemen mithilfe der Anwendung „Daten importieren“.
Sie können folgende Importformate verwenden:
- XML-Format
- CSV-Format
- XLS-Format
Jedes Format hat spezielle Eigenschaften, die Auswirkungen auf den Import von Daten haben, und somit haben die möglichen Formate Vor- und Nachteile.
Wenn Sie im XML-Format importieren, dann können alle gewünschten Daten in einem Importvorgang importiert werden.
Wenn der Import im CSV-Format vorgenommen wird, dann ist ein anderes Vorgehen notwendig. In einer Importdatei können keine parallelen 1:n-Beziehungen zwischen den Business Objects dargestellt werden. Deshalb ist nicht möglich, z. B. Lagerlogistik- und Vertriebsdaten aus einer Datei zu importieren.
Allerdings ist möglich, Lagerlogistikdaten und die zugehörigen Lagerortdaten zu importieren. Sowohl zwischen dem Artikel und seinen Lagerlogistikdaten besteht eine 1:n-Beziehung als auch zwischen den Lagerlogistikdaten und seinen Lagerortdaten. Diese bauen jedoch seriell aufeinander auf und lassen sich deshalb aus einer Datei importieren.
Wenn Sie sich nicht sicher sind, welches das geeignete Format der Importdatei ist, dann gehen Sie wie folgt vor: Erfassen Sie über die Anwendung „Artikel“ einen Beispiel-Artikel und exportieren Sie diesen mit dem Filter für den Import im gewünschten Format mit den gewünschten Attributen. Die so entstehende Beispieldatei lässt sich als Vorlage für die zu erzeugenden Importdateien verwenden.
2 Vorgehensweisen:
Lesen Sie nachfolgend, welche Voraussetzungen Sie für den Import von Artikeldaten erfüllen müssen und wie Sie mit der Anwendung „Daten importieren“ arbeiten:
- Daten importieren
- Notwendige Attribute für den Import aus Altsystemen
- Reihenfolge
- Neuen Artikel importieren
- Artikel mithilfe einer Vorlage importieren
- Neue Verwendung eines Artikels importieren (Mandantenebene)
- Verwendung eines Artikels für untergeordnete Organisation importieren
- Vererbungsstruktur importieren
- Besonderheiten bei Referenz-Artikeln
- Besonderheiten bei Varianten-Artikeln
- Änderung durch Import
- Löschen von Artikeln oder Verwendungen
2.1 Daten importieren
- Öffnen Sie die Anwendung „Daten importieren“.
- Lassen Sie sich den bzw. einen Filter für dieses Business Object anzeigen: cisag.app.general.obj.Item
- Der Filter für den Import der Artikeldaten wird angezeigt.
- Duplizieren oder erfassen Sie bei Bedarf einen neuen Filter für dieses Business Object.
- Ändern Sie bei Bedarf die bereits ausgewählten Attribute des Filters.
- Drücken Sie in der Standard-Symbolleiste den Button „Daten importieren“.
- Das Dialogfenster „Daten importieren“ wird geöffnet.
- Im Dialogfenster „Daten importieren“ können Sie Einstellungen für die Importdatei vornehmen. Eine Beschreibung der Felder finden Sie in der Dokumentation „Daten importieren“.
- Drücken Sie einen der Buttons „Im Hintergrund“ oder „Sofort“.
- Der Import wird ausgeführt.
Hinweis:
Beim Import von Daten ist die Funktion „Verarbeitung im Hintergrund“ nur für voneinander unabhängige Daten möglich.
2.2 Notwendige Attribute für den Import aus Altsystemen
Für den Import aus Altsystemen sind mindestens folgende Attribute pro Business Object „Artikel“ notwendig:
- Identifikationsattribute (Business-Key)
- Pflichtfelder
Ohne die Identifikationsattribute kann das Business Object „Artikel“ nicht zugeordnet werden. Fehlt ein Pflichtfeld, dann wird in jedem Fall die Nachbearbeitung gestartet. Die Pflichtfelder und Identifikationsattribute der einzelnen Business Objects werden im Kapitel „Übersicht: Identifikations- und Pflichtfelder“ aufgeführt.
Zusätzlich bestehen Beziehungen zu anderen Business Objects, die nicht direkt zum Business Object „Artikel“ gehören (Beziehungen über Fremdschlüssel, erkennbar durch Kursivschrift im Filter). Um diese Beziehungen auflösen zu können, müssen die Identifikationsattribute dieser Business Objects im Filter ausgewählt sein.
Wenn der Primärschlüssel eines Business Objects ganz oder teilweise aus Fremdschlüsseln besteht, dann muss in der Importdatei das Business Object, auf das sich dieser Fremdschlüssel bezieht, über seine Identifikationsattribute aufgelöst werden.
Zum Beispiel enthält der Primärschlüssel jeder Verwendung das Attribut „organizationalUnit“. Dieses Attribut bezieht sich auf eine Organisation, die wiederum durch eine Identifikation (String) spezifiziert wird.
2.3 Reihenfolge
Wenn Sie Daten importieren, die voneinander abhängig sind, dann müssen Sie eine bestimmte Reihenfolge einhalten.
Standardreihenfolge
- Basisdaten
- Länderdaten/Intrastat-Daten (falls diese Daten gemäß der Einstellungen in der Anwendung „Customizing“ relevant sind)
- Rechnungswesendaten
- Beschaffungs- und Vertriebsdaten
- Lagerlogistikdaten vor Dispositions- und Produktionsdaten
Hinweis:
Rechnungswesendaten und Länderdaten müssen nicht zwingend vor den anderen Verwendungsdaten importiert werden, aber aus Gründen der Systemleistung sollten Sie dieses anstreben.
Lieferanten-, Kunden-, Kunden-Klassifikations- und Kundendispositions-Artikeldaten können über eigene Importfilter importiert werden. Weitere Informationen finden Sie dazu in der Dokumentation „Artikeldaten von Kunden und Lieferanten importieren“.
Reihenfolge und Zusatzbedingungen für Multi-Site-Systeme
Wenn Sie eine der Verwendungen „Beschaffung“, „Vertrieb“, „Lagerlogistik“, „Disposition“ oder „Produktion“ importieren möchten, dann müssen Sie jeweils vor allen anderen Organisationen die Mandantendaten für die entsprechende Verwendung importieren.
Beim Import müssen Sie für jede Organisation die folgende Reihenfolge einhalten: Lagerlogistikdaten vor Disposition- und Produktionsdaten.
Der Import von Daten kann sofort oder im Hintergrund durchgeführt werden. Bei Verarbeitung im Hintergrund wird der Startzeitpunkt der Verarbeitung vom System bestimmt und kann vom Benutzer nicht beeinflusst werden. Bei der Verarbeitung im Hintergrund kann also die Einhaltung der notwendigen Reihenfolge nicht garantiert werden. Wenn z. B. im zuerst gestarteten Hintergrundauftrag der Import für die Mandantendaten und in einem folgenden Auftrag der Import der entsprechenden Daten einer untergeordneten Organisation enthalten ist, dann kann das zu fehlerhaften Importen führen. In diesem Fall muss erst der erfolgreiche Import der Mandantendaten abgewartet werden.
Hinweis:
Beim Import von Daten ist die Funktion „Verarbeitung im Hintergrund“ nur für voneinander unabhängige Daten empfohlen, d. h. der gleichzeitige Import durch verschiedene Hintergrundprozesse von abhängigen Daten führt zu Datenfehlern.
2.4 Neuen Artikel importieren
Voraussetzungen
- Im Ziel-System existiert noch kein Artikel mit der entsprechenden Identifikation.
- Ein Filter für das folgende Business Object ist vorhanden, der die zu importierenden Attribute enthält:
com.cisag.app.general.obj.Item
Anleitung
- Stellen Sie sicher, dass die Import-Datei mindestens die Artikelidentifikation (Identifikation Item) enthält.
- Achten Sie darauf, dass möglichst alle Pflichtfelder der Basisdaten angegeben sind (siehe Kapitel „Übersicht: Identifikations- und Pflichtfelder“).
- Führen Sie gemäß Kapitel „Daten importieren“ den Import aus.
2.5 Artikel mithilfe einer Vorlage importieren
Voraussetzungen
- Im Ziel-System ist eine Artikel-Vorlage vorhanden.
- Im Ziel-System existiert noch kein Artikel mit der entsprechenden Identifikation.
- Ein Filter für das folgende Business Object ist vorhanden, der die zu importierenden Attribute enthält:
com.cisag.app.general.obj.Item
Anleitung
Führen Sie gemäß Kapitel „Daten importieren“ den Import aus. Wählen Sie dazu das Attribut „template“ aus und geben Sie in der Import-Datei eine im Ziel-System vorhandene Artikel-Vorlage an.
Beim Import werden zunächst die Daten aus der Vorlage verwendet. Wenn Daten in der Import-Datei angegeben sind, die auch in der Vorlage vorhanden sind, dann werden die in der Import-Datei angegebenen Daten verwendet.
Hinweis:
Importieren Sie zunächst den Artikel mithilfe der Artikel-Vorlage. Anschließend können Sie den Artikel ändern, falls dies erforderlich ist. Dabei können Sie auch die gleiche Importdatei verwenden. Sie müssen jedoch über die Reihenfolge sicherstellen, dass in einem ersten Schritt der Artikel aus der Artikel-Vorlage erzeugt wird.
2.6 Neue Verwendung eines Artikels importieren (Mandantenebene)
Voraussetzungen
- Im Ziel-System existiert bereits ein Artikel mit der entsprechenden Identifikation, d. h. die Basisdaten wurden bereits importiert.
- Ein Filter für das folgende Business Object ist vorhanden, der die zu importierenden Attribute enthält:
com.cisag.app.general.obj.Item
- Eine Import-Datei wurde erzeugt, die als Attribut die Artikelidentifikation enthält.
- Die Daten der zu importierenden Verwendung beziehen sich auf die Organisation des Mandanten.
Anleitung
- Prüfen Sie, dass die zu erzeugende Import-Datei mindestens die Artikelidentifikation (Identifikation Item) und den Schlüssel der zu importierenden Verwendung enthält.
- Achten Sie darauf, dass möglichst alle Pflichtfelder der zu importierenden Verwendung angegeben sind (siehe Kapitel „Übersicht: Identifikations- und Pflichtfelder“).
- Führen Sie gemäß Kapitel „Daten importieren“ den Import aus.
Hinweis:
Sie müssen zuerst die Daten auf Mandantenebene für die Verwendungen „Beschaffung“, „Lagerlogistik“, „Disposition“, „Vertrieb“ und „Produktion“ erzeugen. Danach können Sie die entsprechenden Daten für untergeordnete Organisationen erzeugen.
2.7 Verwendung eines Artikels für untergeordnete Organisation importieren
Voraussetzungen
- Das System ist ein Multi-Site-System.
- Im Ziel-System existiert bereits ein Artikel mit der entsprechenden Identifikation, d. h. die Basisdaten wurden bereits importiert.
- Ein Filter für das folgende Business Object ist vorhanden, der die zu importierenden Attribute enthält:
com.cisag.app.general.obj.Item
- Bevor der Import gestartet wird, ist notwendig, dass bereits Daten für die entsprechende Verwendung auf Mandantenebene existieren.
Anleitung
- Prüfen Sie, dass die zu erzeugende Import-Datei mindestens die Artikelidentifikation (Identifikation Item) und den Schlüssel der zu importierenden Verwendung enthält.
- Achten Sie darauf, dass möglichst alle Pflichtfelder der zu importierenden Verwendung angegeben sind (siehe Kapitel „Übersicht: Identifikations- und Pflichtfelder“).
- Stellen Sie sicher, dass die untergeordnete Organisation berechtigt ist, Daten für die zu importierende Verwendung zu bearbeiten.
- Führen Sie gemäß Kapitel „Daten importieren“ den Import aus.
Hinweis:
Der Schlüssel der zu importierenden Verwendung in der Import-Datei bezieht sich auf die Organisation, die die Verwendung erhalten soll. Daneben existieren Verwendungen, die auch Referenzen auf andere Organisationen enthalten. Bitte verwechseln Sie diese nicht mit der Schlüsselorganisation der Verwendung.
2.8 Vererbungsstruktur importieren
Voraussetzungen
- Das System ist ein Multi-Site-System oder die Funktion für inhaltsbezogene Berechtigungen ist aktiv, sodass mehr als eine Organisation besteht.
- Die Organisation, die Daten erben soll, muss für diese Verwendung berechtigt sein.
- Die Organisation muss eine untergeordnete Organisation sein und ist somit nicht der Mandant.
- Im Ziel-System existiert bereits ein Artikel mit der entsprechenden Identifikation, d. h. die Basisdaten wurden bereits importiert.
- Auf der Ebene der Organisation müssen bereits Daten für die entsprechende Verwendung existieren, von der die Ziel-Organisation die Daten erben soll.
- Ein Filter für das folgende Business Object ist vorhanden, der die zu importierenden Attribute enthält:
com.cisag.app.general.obj.Item
Anleitung
Hinweis:
Da dieses Business Object normalerweise nur über die Anwendung „Artikel“ automatisch bearbeitet wird und der Benutzer keinerlei Eingriffsmöglichkeiten hat, ist beim Import besondere Sorgfalt geboten.
Hinweis:
Importieren Sie zunächst den Artikel mit den Ansichten auf Mandantenebene. Anschließend können Sie die Vererbungsstrukturen importieren. Dabei können Sie auch die gleiche Importdatei verwenden. Sie müssen jedoch über die Reihenfolge sicherstellen, dass in einem ersten Schritt die Ansichten für den Mandanten und anschließend die Ansichten für die vom Mandanten erbenden Organisationen erzeugt werden.
- Erzeugen Sie eine Import-Datei, die mindestens die Artikelidentifikation (Identifikation Item) und die Identifikationsattribute des zu importierenden Business Objects „OrganizationalUnitItems“ enthält.
- Die Vererbungsstruktur der Verwendungen ist im Business Object „OrganizationalUnitItem“ festgelegt. Jede Verwendung, die eine Vererbungsstruktur besitzt, hat in diesem Business Object ein Referenzattribut:
Verwendung | Referenzattribut |
Beschaffung | MaintainingPurchasing |
Lagerlogistik | MaintainingInventory |
Disposition | MaintainingPlanning |
Vertrieb | MaintainingSales |
Produktion | MaintainingProduction |
Tragen Sie in dem Attribut für die entsprechende Verwendung die Organisation ein, von der die Ziel-Organisation erben soll.
- Stellen Sie sicher, dass die untergeordnete Organisation die folgenden Berechtigungen besitzt:
- Berechtigung, um Daten für die zu importierende Verwendung zu bearbeiten.
- Berechtigung, die zu importierende Verwendung zu führen (z. B. kann nur eine Vertriebsorganisation die Verwendung „Vertrieb“ erben).
- Führen Sie gemäß Kapitel „Daten importieren“ den Import aus.
2.9 Besonderheiten bei Referenz-Artikeln
Ein Referenz-Artikel dient als Vorlage für Varianten. Eine Änderung bestehender Daten oder bestimmte neue Daten in der Anwendung „Artikel“ führen zu einer entsprechenden Änderung in den zugehörigen Varianten-Artikeln. Beim Import von Referenz-Artikeln erfolgt Entsprechendes.
2.10 Besonderheiten bei Varianten-Artikeln
Ein Varianten-Artikel bezieht sich immer auf einen Referenz-Artikel. Wenn Sie einen Varianten-Artikel importieren möchten, muss der zugehörige Referenz-Artikel bereits in der Datenbank existieren. Sie können für Varianten-Artikel nur die Daten importieren, die Sie in der Anwendung „Artikel“ manuell erfassen könnten. Sie können keine neuen Verwendungen des Varianten-Artikels erfassen, keine Vererbungsstruktur ändern oder erfassen und bestimmte Attribute können Sie über den Import nicht ändern. Dies sind alles Daten, die vom zugehörigen Referenz-Artikel gesteuert werden. Sollten entsprechende Daten in den Importdateien vorhanden sind, dann werden diese beim Import ignoriert. Neue Varianten-Artikel können jedoch sehr einfach importiert werden: Verwenden Sie eine Datei wie in Kapitel „Basisdatendatei für Varianten-Artikel“ beschrieben, um einen neuen Varianten-Artikel inklusive aller Verwendungen zu erzeugen.
2.11 Änderung durch Import
Mithilfe der Importfunktion können Sie auch Änderungen an existierenden Artikeln vornehmen. Wenn Sie beispielsweise bei allen Vertriebs-Artikeln die Verfügbarkeitsprüfung aktivieren möchten, dann ist dies auch durch die Importfunktion möglich.
Anleitung
Erzeugen Sie einen Filter, der die Identifikation des Artikels, das Schlüsselattribut der Verwendung und die zu ändernden Felder enthält. Exportieren Sie dann die entsprechenden Artikel z. B. im CSV-Format. In der erstellten Datei ändern Sie das entsprechende Feld auf den gewünschten Wert. Danach importieren Sie die Datei wieder mit dem erzeugten Filter. Im folgenden Beispiel wird die Verfügbarkeitsprüfung der Vertriebs-Artikel aktiviert.
Beispiel: Ändern der Verfügbarkeitsprüfung
number | SalesItems .OrganizationalUnit |
SalesItems .availabilityCheckActivated |
4711 | Mandant | true |
4711 | Organisation 1 | true |
4711 | Organisation 2 | true |
4712 | Mandant | true |
4712 | Organisation 1 | true |
4713 | Mandant | true |
2.12 Löschen von Artikeln oder Verwendungen
Sie können über den Import auch existierende Artikel oder einzelne Verwendungen zum Löschen kennzeichnen. Ebenso können Sie ein Löschkennzeichen auf diese Weise wieder aufheben. Der Import hat dieselbe Auswirkung wie das Drücken des Buttons „Löschkennzeichen setzen“ bzw. „Löschkennzeichen entfernen“ in der Anwendung „Artikel“.
Um ein Löschkennzeichen zu setzen, wird das entsprechende Business Object im Modus „delete“ importiert. Ebenso müssen Sie das entsprechende Business Object im Modus „delete“ importieren, um ein bestehendes Löschkennzeichen wieder aufzuheben. Diesen Modus können Sie nur im xml-Format setzen. Lesen Sie bitte auch die Dokumentation „Einführung: Datenaustausch“ zu diesem Thema.
Hinweis:
Ein erneuter Import im Modus „delete“ macht ebenso wie die Aktion „Löschkennzeichen entfernen“ in der Anwendung „Artikel“ den Löschvorgang nicht komplett rückgängig. Wenn Sie ein Löschkennzeichen für die Basisdaten setzen, dann werden auch alle Verwendungen des Artikels zum Löschen gekennzeichnet. Ein erneuter Import dieser Datei entfernt jedoch nur das Löschkennzeichen der Basisdaten. Lesen Sie dazu bitte auch in der Dokumentation „Vorgehensweisen: Artikel“ das entsprechende Kapitel.
XML | Wirkung |
<Item xmlns=”com.cisag.app.general.obj.Item” mode=”delete”>
<number>4711</number> </Item> |
Hat der Artikel „4711“ noch kein Löschkennzeichen, dann wird er komplett zum Löschen gekennzeichnet, d.h. alle Verwendungen in allen Organisationen erhalten ein Löschkennzeichen.
Hat der Artikel „4711“ bereits ein Löschkennzeichen, dann wird es für die Basisdaten falls möglich wieder entfernt. Die Löschkennzeichen für Verwendungen des Artikels werden nicht entfernt. Siehe auch diese Dokumentation: Vorgehensweisen: Artikel |
<Item xmlns=”com.cisag.app.general.obj.Item”>
<number>4712</number> <PurchaseItems mode=”delete”> <OrganizationalUnit> Mandant </OrganizationalUnit> </PurchaseItems> </Item> |
Hat die Verwendung „Beschaffung“ des Artikels „4712“ auf der Organisationsebene des Mandanten noch kein Löschkennzeichen, dann wird die Verwendung „Beschaffung“ komplett zum Löschen gekennzeichnet. Dazu reicht die Angabe der Daten für die Organisation des Mandanten. Eventuell auf der Ebene anderer Organisationen erfasste Beschaffungs-Artikel werden ebenfalls zum Löschen gekennzeichnet.
Hat die Verwendung „Beschaffung“ des Artikels „4712“ bereits auf Ebene des Mandanten ein Löschkennzeichen, dann wird dieses falls möglich entfernt. Die Löschkennzeichen für Beschaffungsdaten anderer Organisationen werden nicht entfernt. Siehe auch diese Dokumentation: Vorgehensweisen: Artikel, Ansicht „Beschaffung“ |
<Item xmlns=”com.cisag.app.general.obj.Item”>
<number>4713</number> <PurchaseItems mode=”delete”> <OrganizationalUnit> </PurchaseItems> </Item> |
Hat die Verwendung „Beschaffung“ des Artikels „4713“ auf der Ebene der Organisation „90000“ noch kein Löschkennzeichen, dann wird die Verwendung „Beschaffung“ auf dieser Organisationsebene zum Löschen gekennzeichnet.
Hat die Verwendung „Beschaffung“ des Artikels „4713“ auf der Ebene der Organisation „90000“ bereits ein Löschkennzeichen, dann wird dieses falls möglich entfernt. Eventuell auf der Ebene anderer Organisationen erfasste Beschaffungsdaten sind in beiden Fällen nicht betroffen. Siehe auch diese Dokumentation: Vorgehensweisen: Artikel, Ansicht „Beschaffung“ |
<Item xmlns=”com.cisag.app.general.obj.Item”>
<number>4714</number> <ItemAccountingData mode=”delete”> <OrganizationalUnit> </ ItemAccountingData> </Item> |
Hat die Verwendung „Rechnungswesen“ des Artikels „4714“ auf der Ebene der Organisation „92000“ noch kein Löschkennzeichen, dann wird die Verwendung „Rechnungswesen“ auf dieser Organisationsebene zum Löschen gekennzeichnet.
Hat die Verwendung „Rechnungswesen“ des Artikels „4714“ auf der Ebene der Organisation „92000“ bereits ein Löschkennzeichen, dann wird dieses falls möglich entfernt. Da für Rechnungswesendaten jede Firma ihre eigenen Daten erfassen muss (d. h. keine Vererbung möglich ist), ist bei Rechnungswesendaten immer nur die angegebene Organisation betroffen. Siehe auch diese Dokumentation: Vorgehensweisen: Artikel, Ansicht „Rechnungswesen“ |
3 Import mit CSV-Dateien
Aus Gründen der Systemleistung ist sinnvoll, dass Sie im ersten Importvorgang so viele Informationen wie möglich importieren. Auch mit CSV-Dateien können Sie z. B. mehrere Artikelverwendungen und Organisationen in einem Importvorgang importieren. Die Dateien sollten folgenden Aufbau haben:
- Basisdatendatei:
Die Basisdatendatei enthält alle Informationen der notwendigen Basisdaten (siehe Kapitel „Basisdaten“). Diese Datei gibt vor, welcher Artikel importiert wird.
- Datei mit Länderdaten:
In dieser Datei können die ersten n-Zeilen für den ersten Artikel aus der Basisdatendatei enthalten sein, die nächsten m-Zeilen für den zweiten Artikel usw.
- Datei mit Rechnungswesendaten:
In dieser Datei sind z. B. die ersten zwei Zeilen die Rechnungswesendaten für Artikel 1 in zwei Firmen, die nächsten drei Zeilen für Artikel 2 in drei Organisationen und weitere Zeilen sind für Artikel 4 und Artikel 3 bekommt keine Rechnungswesendaten.
- Datei mit Vertriebsdaten:
In dieser Datei ist wichtig, dass die erste Zeile, in der die Artikelidentifikation wechselt, immer die Daten für die Mandantenorganisation enthält. Dann können die Daten für untergeordnete Organisationen folgen.
- Weitere Dateien:
Analog zu den Vertriebsdaten können noch Dateien erfasst werden, die die anderen vererbbaren Verwendungen enthalten.
Wichtig ist, dass die Reihenfolge der Artikel in den einzelnen Dateien der Reihenfolge der Artikel in der Basisdatendatei entspricht. Das Fehlen einzelner Artikelidentifikationen in den Zusatzdateien ist erlaubt, wenn ein Artikel z. B. eine Verwendung nicht haben soll.
3.1 Verknüpfungen von Dateien
Voraussetzungen
- Ein Filter für das folgende Business Object ist vorhanden, der die zu importierenden Attribute enthält:
com.cisag.app.general.obj.Item
- Eine Basisdatendatei ist vorhanden, die die Basisdaten enthält.
- Eine oder mehrere Zusatzdateien mit Zusatzdaten existieren.
- Jeder Wert des verknüpfenden Attributs „Artikel“ muss auch in der Basisdatendatei enthalten sein.
Anleitung
- Öffnen Sie die Anwendung „Daten importieren“.
- Lassen Sie sich den bzw. einen Filter für dieses Business Object anzeigen: cisag.app.general.obj.Item
- Der Filter für den Import der Artikeldaten wird angezeigt.
- Duplizieren oder erfassen Sie bei Bedarf einen neuen Filter für dieses Business Object.
- Ändern Sie bei Bedarf die bereits ausgewählten Attribute des Filters.
- Drücken Sie in der Standard-Symbolleiste den Button „Daten importieren“.
- Das Dialogfenster „Daten importieren“ wird geöffnet.
- Im Dialogfenster „Daten importieren“ können Sie Einstellungen für die Importdatei vornehmen. Eine Beschreibung der Felder finden Sie in der Dokumentation „Daten importieren“.
- Drücken Sie den Button „Verknüpfungen“.
- Das Auswahldialogfenster „Verknüpfungen bearbeiten“ wird geöffnet.
- Sie können eine neue Verknüpfung mit der Angabe des Objektpfades, einer Zusatzdatei als Quelldatei, der Fehlerdatei und des verknüpfenden Attributs (bei Artikelimport „Attribut number“) erstellen.
Der Objektpfad beschreibt den Namen der Beziehung zu dem zu importierenden Business Object. Als Quell-Datei wird eine der Zusatzdateien ausgewählt. Achten Sie bitte darauf, dass die Verbindung zu der Zusatzdatei mit der Angabe des Objektpfades übereinstimmt. Wenn z. B. als Objektpfad „SalesItems“ ausgewählt wird, dann sollte die angegebene Zusatzdatei auch die Daten für Vertriebs-Artikel enthalten.
- Wiederholen Sie Schritt 8 bis alle Zusatzdateien verknüpft sind.
- Drücken Sie den Button „Übernehmen“.
- Das Auswahldialogfenster „Verknüpfungen bearbeiten“ wird geschlossen.
- Drücken Sie einen der Buttons „Im Hintergrund“ oder „Sofort“.
- Der Import wird ausgeführt.
Hinweis:
Wichtig ist, dass in den Zusatzdateien keine Schlüssel (Artikelidentifikationen) vorhanden sind, die in der Basisdatendatei nicht existieren. Datensätze, die in der Zusatzdatei diesem Datensatz folgen, werden ansonsten nicht importiert. Aus demselben Grund muss die Sortierung der verknüpfenden Schlüsselattribute in Basisdaten- und Zusatzdateien übereinstimmen.
3.2 Beispiele
Im Folgenden wird der strukturelle Aufbau der Basisdatendatei und der Zusatzdateien beschrieben. Welche Attribute Pflichtfelder sind und somit möglichst angegeben werden müssen, finden Sie im Kapitel „Übersicht: Identifikations- und Pflichtfelder“.
3.2.1 Basisdatendatei
number | description | Uoms.code | onhandAccounting | … |
4711 | Beschreibung für 4711 | St. | true | … |
4712 | Beschreibung für 4712 | kg | true | … |
4713 | Beschreibung für 4713 | St. | false | … |
3.2.2 Basisdatendatei für Varianten-Artikel
Der Import von Varianten-Artikeln ist nur möglich, wenn der zugehörige Referenz-Artikel bereits existiert. Um einen neuen Varianten-Artikel zu importieren reicht folgende Datei aus.
number | description | type | materialType | ReferenceItem | … |
REF1VAR1 | Beschreibung | MATERIAL | VARIANT_ITEM | REF1 | … |
In diesem Beispiel wird ein neuer Varianten-Artikel mit der Artikelidentifikation „REF1VAR1“ erzeugt, der auf dem Referenz-Artikel „REF1“ beruht. In einem Multi-Site-System wird auch die gesamte Organisationsstruktur des Referenz-Artikels auf den Varianten-Artikel übertragen.
3.2.3 Länderdatendatei
Artikel „4711“ erhält den Standarddatensatz und zusätzlich Länderdaten für Deutschland und die Schweiz. Artikel „4712“ erhält nur den Standarddatensatz. Artikel „4713“ erhält den Standarddatensatz und spezielle Länderdaten für Österreich.
number | ItemCountry Data.Country |
ItemCountry Data.mandatory |
ItemCountry Data.intrastat. IndexOf GoodsNumber |
… |
4711 | true | 12101000 | ||
4711 | DE | true | 12102010 | … |
4711 | CH | false | … | |
4712 | false | … | ||
4713 | true | 10011000 | … | |
4713 | AT | false | … |
3.2.4 Rechnungswesendatendatei
In diesem Beispiel erhält der Artikel „4711“ Rechnungswesendaten für die Firma „Firma 1“ und „Firma 2“. Der Artikel „4712“ erhält Rechnungswesendaten für die Firma „Firma 2“.
number | ItemAccountingData.OrganizationalUnit | … |
4711 | Firma 1 | … |
4711 | Firma 2 | … |
4712 | Firma 2 | … |
3.2.5 Datei für vererbbare Verwendungen
Als Beispiel wird die vererbbare Verwendung „Vertrieb“ angegeben. Für die Verwendungen „Beschaffung“, „Lagerlogistik“, „Disposition“ und „Produktion“ ist das Vorgehen gleich.
In diesem Beispiel erhält der Artikel „4711“ Vertriebsdaten für die Organisationen „Organisation 1“ und „Organisation 2“. Der Artikel „4712“ erhält die für den Mandanten und für die Organisation „Organisation 1“ eigene Vertriebsdaten. Artikel „4713“ hat Vertriebsdaten nur auf Mandantenebene.
Hinweis:
Wichtig ist, dass für jeden Artikel die Organisation des Mandanten voran gestellt ist.
number | SalesItems.OrganizationalUnit | … |
4711 | Mandant | … |
4711 | Organisation 1 | … |
4711 | Organisation 2 | … |
4712 | Mandant | … |
4712 | Organisation 1 | … |
4713 | Mandant | … |
4 Übersicht: Identifikations- und Pflichtfelder
Im Folgenden werden die für den Import notwendigen Attribute der einzelnen Business Objects aufgeführt. Die Identifikations- und Pflichtfelder sind Änderungen unterworfen und können durch Anpassungen erweitert werden.
Die Identifikationsattribute (Key-Attribute) werden über ein (K) gekennzeichnet.
4.1 Basisdaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
uoms[0] | 1. Artikeleinheit |
description | Bezeichnung |
onhandAccounting | Bestandsführung |
MaintainingOrganization1 | Zuständige Organisation |
ReferenceItem2 | Referenz-Artikel |
1 Nur notwendig, wenn das System ein Multi-Site-System oder die Funktion für inhaltsbezogene Berechtigungen aktiv ist.
2 Nur bei Varianten-Artikeln notwendig.
Wenn der Artikeltyp (Attribut „type“) und Materialtyp (Attribut „materialType“) nicht angegeben werden, dann wird vom Lager-Artikel ausgegangen.
4.2 EAN
Pflichtfeld/Key-Attribut (K) | Feld |
Uoms.code (K) | Einheit (1. Artikeleinheit oder Verpackungseinheit) |
Uoms.EANs.id | EAN |
Uoms.EANs.preferred | bevorzugt |
Jede der Artikel-EAN bezieht sich auf eine Artikeleinheit oder Verpackungseinheit. Pro Einheit können mehrere EAN existieren. Eine der EAN muss als bevorzugt kennzeichnet werden.
4.3 Länderdaten
Die Angabe von Länderdaten ist nur dann sinnvoll, wenn in der Anwendung „Customizing“ unter der Funktion „Länderbesonderheiten“ die Funktion „Intrastat“ aktiviert ist.
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
ItemCountryData.Country (K) | Land (bzw. leer oder Zero-GUID für die Standardwerte) |
ItemCountryData. intrastat.mandatory |
false = folgende Attribute optional
true = folgende Attribute Pflicht |
ItemCountryData.intrastat. CountryOfOrigin |
Ursprungsland |
ItemCountryData.intrastat. IndexOfGoodsNumber |
Warennummer |
4.4 Rechnungswesendaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
ItemAccountingData. OrganizationalUnit (K)1 |
Organisation |
1 Nur notwendig, wenn das System ein Multi-Site-System ist.
Die Angabe der Organisation ist nur in einem Multi-Site-System notwendig. Wird in einem Single-Site-System die Organisation nicht angegeben, dann wird sie auf die des Mandanten gesetzt.
Die folgenden Attribute der Rechnungswesendaten sind keine Pflichtfelder. Jedoch ist ratsam diese anzugeben, da sie den Sperrstatus für die Anwendungen „Beschaffung“, „Lagerlogistik“ und „Vertrieb“ mitbestimmen.
Pflichtfeld/Key-Attribut (K) | Feld |
ItemAccountingData. inputTaxClassification |
Vorsteuer-Klassifikation (für Beschaffung) |
ItemAccountingData. outputTaxClassification |
Mehrwertsteuer-Klassifikation (für Vertrieb) |
ItemAccountingData. expenseClassification |
Aufwandskonto-Klassifikation (für Beschaffung) |
ItemAccountingData. revenueClassification |
Erlöskonto-Klassifikation (für Vertrieb) |
ItemAccountingData. cogClassification |
Bestandskonto-Klassifikation (für Lagerlogistk) |
4.5 Beschaffungs-Artikeldaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
PurchaseItems. rganizationalUnit(K) |
Organisation |
PurchaseItems.classification1 | Klassifikation 1 |
Die Angabe der Organisation ist nur in einem Multi-Site-System notwendig. Wird in einem Single-Site-System die Organisation nicht angegeben, dann wird sie auf die des Mandanten gesetzt.
Bei Nichtangabe der Attribute „uom[0]“ und „pricingUom“ werden diese mit der 1. Artikeleinheit des Artikels vorgeschlagen.
4.6 Lager-Artikeldaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
InventoryItems. OrganizationalUnit(K) |
Organisation |
InventoryItems.classification1 | Klassifikation 1 |
Die Angabe der Organisation ist nur in einem Multi-Site-System notwendig. Wird in einem Single-Site-System die Organisation nicht angegeben, dann wird sie auf die des Mandanten gesetzt.
Wenn die ABC-Klassifikation nicht angegeben wird, dann wird der Wert auf „A“ gesetzt.
4.7 Dispositionsdaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
ItemPlanningData. OrganizationalUnit(K) |
Organisation |
ItemPlanningData.makeOrBuy1 | Bedarfsdeckung
Mögliche Werte sind: · BUY · BUY_INTERNAL · MAKE |
1 Für Feld „makeOrBuy“ ist der Wert „BUY“ für externe Beschaffung, „BUY_INTERNAL“ für interne Beschaffung, „MAKE“ für Produktion
Die Angabe der Organisation ist nur in einem Multi-Site-System notwendig. Wird in einer Single-Site-Umgebung die Organisation nicht angegeben, dann wird sie auf die des Mandanten gesetzt.
Je nach Einstellung im Attribut „makeOrBuy“ ist eine der folgenden Tabellen Pflicht. Diese Attribute müssen dann zusätzlich in der Importdatei vorhanden sein.
Nicht angegebene Attribute werden mit den entsprechenden Standardwerten belegt. Wenn keine Produktionsdaten in der Importdatei vorhanden sein sollen, dann muss der Wert für das Feld „useProductionData“ auf „false“ gesetzt werden. Das Feld „useProductionData“ wird mit „true“ vorgeschlagen.
Für Feld „makeOrBuy“ ist der Wert „BUY“ für externe Beschaffung gewählt:
Pflichtfeld/Key-Attribut (K) | Feld |
ItemPlanningData. usePurchaseData |
Externe Beschaffung
(Wert muss „true“ sein) |
ItemPlanningData. PurchasingOrganisation |
Beschaffungsorganisation |
ItemPlanningData. PurchasingScheduler |
Beschaffungsdisponent |
Für Feld „makeOrBuy“ ist der Wert „BUY_INTERNAL“ für interne Beschaffung gewählt:
Pflichtfeld/Key-Attribut (K) | Feld |
ItemPlanningData. useInternalPurchaseData |
Interne Beschaffung
(Wert muss „true“ sein) |
ItemPlanningData. InternalPurchasingOrganistion |
Beschaffungsorganisation |
ItemPlanningData. InternalDeliveryPartner |
Quell-Standort (muss eine Logistikorganisation sein, die zusätzlich auch Lieferant zur angegebenen Beschaffungsorganisation ist) |
ItemPlanningData. InternalPurchasingScheduler |
Beschaffungsdisponent |
Für Feld „makeOrBuy“ ist der Wert „MAKE“ für Produktion gewählt:
Pflichtfeld/Key-Attribut (K) | Feld |
ItemPlanningData. useProductionData |
Produktionsdaten anwenden
(Wert muss „true“ sein) |
ItemPlanningData.Planner | Planer |
ItemPlanningData.Scheduler | Produktionsdisponent |
4.8 Vertriebs-Artikeldaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
SalesItems. OrganizationalUnit(K) |
Organisation |
Sales.classification1 | Klassifikation 1 |
Die Angabe der Organisation ist nur in einem Multi-Site-System notwendig. Wird in einem Single-Site-System die Organisation nicht angegeben, dann wird sie auf die des Mandanten gesetzt.
Bei Nichtangabe der Attribute „uoms[0]“ und „pricingUom“ werden diese mit der 1. Artikeleinheit des Artikels vorgeschlagen.
4.9 Produktions-Artikeldaten
Pflichtfeld/Key-Attribut (K) | Feld |
number (K) | Artikel |
ProductionItems. OrganizationalUnit(K) |
Organisation |
ProductionItems.classification1 | Klassifikation 1 |
Die Angabe der Organisation ist nur in einem Multi-Site-System notwendig. Wird in einem Single-Site-System die Organisation nicht angegeben, dann wird sie auf die des Mandanten gesetzt.
Wenn gemäß der Anwendung „Customizing“ alternative Produktionsverfahren zulässig sind:
Pflichtfeld/Key-Attribut (K) | Feld |
ProductionItems. defaultProductionPlan.type |
Typ
Werte aus Valueset „ProductionPlanKeyType“ (erlaubte Werte): · BOM = „Stückliste“ · ROUTING = „Stückliste+Arbeitsplan“ · PROCESS = „Produktionsplan“) |
ProductionItems. defaultProductionPlan. BillOfMaterial.code |
Stückliste
Pflichtfeld, wenn Typ = „Stückliste“ oder „Stückliste und Arbeitsplan“ |
ProductionItems. defaultProductionPlan. BillOfMaterial.type |
Stückliste
Pflichtfeld, wenn Typ = „Stückliste“ oder „Stückliste und Arbeitsplan“ Wert = „BILL_OF_MATERIAL“ |
ProductionItems. defaultProductionPlan.Routing.code |
Arbeitsplan
Pflichtfeld, wenn Typ = „Stückliste und Arbeitsplan“ |
ProductionItems. defaultProductionPlan.Routing.type |
Arbeitsplan
Pflichtfeld, wenn Typ = „Stückliste und Arbeitsplan“ Wert = „ROUTING“ |
ProductionItems. defaultProductionPlan.Process. code |
Produktionsplan
Pflichtfeld, wenn Typ = „Produktionsplan“ |
ProductionItems. defaultProductionPlan.Process. type |
Produktionsplan
Pflichtfeld, wenn Typ = „Produktionsplan“ Wert = „PROCESS“ |
Wenn gemäß Einstellung in der Anwendung „Customizing“ keine alternativen Produktionsverfahren zulässig sind:
Pflichtfeld/Key-Attribut (K) | Feld |
ProductionItems. defaultProductionPlan. BillOfMaterial.type |
Wert = „BILL_OF_MATERIAL“ |