Themenübersicht
Wenn Sie die Daten von bereits erledigten Vertriebsaufträgen aus einem Altsystem in Ihr ERP-System übertragen möchten, um bspw. gesetzliche Aufbewahrungsfristen für Geschäftsbelege einzuhalten, verwenden Sie die Anwendung Daten importieren mit dem Importfilter für historische Vertriebsaufträge.
In dieser Dokumentation werden die Vorgehensweisen für den Umgang mit der Anwendung Daten importieren bezogen auf historische Vertriebsaufträge beschrieben. Diese Vorgehensweisen enthalten allgemeine Anleitungsschritte und Informationen darüber, welche Besonderheiten zu berücksichtigen 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.
Allgemeines
Der Import eines historischen Vertriebsauftrages basiert im Wesentlichen auf dem aktuellen Datenmodell, welches in der Repository-Datenbank hinterlegt ist. Für den Datenexport stehen mehr Attribute als für den Datenimport zur Verfügung. Deshalb ist sinnvoll, für den Export und Import separate Filter festzulegen.
1:1-Beziehungen basieren im Datenmodell in der Regel auf einem technischen GUID-Attribut. Je nach Anwendungsfall kann beim Import entweder das technische GUID-Attribut verwendet werden oder der fachliche Schlüssel aus dem Ziel-Objekt (meist code oder number). Bei einigen Business Objects ist für die Umwandlung fachlicher Schlüssel zu technischem Schlüssel eine Organisation notwendig. Die jeweils relevante Organisation steht im Normalfall nicht direkt in der Import-Quelle, sondern ist über den Belegkontext vorgegeben. Weitere Informationen dazu finden Sie in diesem Kapitel: Übersicht: Attribute
Bestimmte Daten der historischen Vertriebsaufträge wie Hauswährungswerte, Dispositionsmengen, Artikelkonfiguration und deren Konfigurationspositionen sowie interne Hilfsattribute können nicht importiert werden.
Die importierten historischen Vertriebsauftragsdaten werden in folgenden Business Objects gespeichert:
- Identifikation und GUID
- Beleg-Reorganisationsdaten: com.cisag.app.general.obj.DocumentReorganizationDataHinweisZur Unterscheidung von den historischen Daten, die durch die Reorganisation von Vertriebsaufträgen entstanden sind, wird für die importierten historischen Vertriebsauftragsdaten das Attribut
createdByReorganizationauffalsegesetzt. - Belegposition-Reorganisationsdaten: com.cisag.app.general.obj.DocumentDetailReorganizationData
- Beleg-Reorganisationsdaten: com.cisag.app.general.obj.DocumentReorganizationData
- Weitere Daten
- Historischer Vertriebsauftrag: com.cisag.app.sales.orderarchive.obj.SalesOrderArchive
- Historische Vertriebsauftragsposition: com.cisag.app.sales.orderarchive.obj.SalesOrderArchiveDetail
Die importierten historischen Vertriebsaufträge können Sie in der Anwendung Cockpit: Historische Vertriebsaufträge abfragen.
Hash-Code-Business-Objects als Parts
Sowohl in der Basis als auch in der Position eines historischen Vertriebsauftrages werden Hash-Code-Business-Objects referenziert. Das sind fachlich zusammengehörende Attributgruppen, die für viele Belege immer wieder gleich sind und deren Wiederverwendung einigen Speicherplatz in der Datenbank und im Hauptspeicher spart. Über eine spezielle Konvertierung stellen sich die Hash-Code-Business-Objects für den Export bzw. Import wie Parts dar.
Vorlage für Importdatei
Wenn Sie sich nicht sicher sind, welches das geeignete Format der Importdatei ist, dann können Sie wie folgt vorgehen:
- Erfassen Sie über die Anwendung Vertriebsaufträge einen Beispiel-Vertriebsauftrag.
- Legen Sie fest, dass für diesen Auftrag bei der Reorganisation historische Daten erzeugt werden sollen. Erfassen Sie dazu einen Eintrag in der Anwendung Beleg-Reorganisationseinstellungen/Historische Daten, der z. B. nur für die Belegart Ihres Beispiel-Vertriebsauftrags gilt.
- Reorganisieren Sie den Vertriebsauftrag.
Der reorganisierte Vertriebsauftrag wird als historischer Vertriebsauftrag gespeichert. - Exportieren Sie den historischen Vertriebsauftrag 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. Siehe auch diesen Abschnitt: Beispiel einer Importdatei
Erzeugung neuer historischer Vertriebsaufträge
Mindestanforderungen
Die mindestens erforderlichen Attribute pro Basisobjekt sind:
- Auftraggeber – customerData.CustomerPartner
- Erfassungsdatum – date
- Rechnungsempfänger (falls nicht vorhanden, wird der Auftraggeber verwendet) – invoiceCustomerData.CustomerPartner
- Vertriebs-Auftragsart – TypeHinweisPrüfen Sie, ob es in Ihrem Fall sinnvoll ist, für den Import historischer Vertriebsaufträge, z. B. aus Fremdsystemen, eine eigene Vertriebsauftragsart zu verwenden.
- Vertriebsorganisation (in Single-Site-Systemen mit deaktivierten inhaltsbezogenen Berechtigungen ist das automatisch der Mandant) – invoicingPartyData.Partner
- Währung – currency
Optional können Sie mithilfe des Imports auch die Nummer (number) übergeben. In diesem Fall wird die über den Nummernkreis gemäß Art ermittelte Nummer ignoriert. Zudem muss über geeignete Konventionen dafür gesorgt werden, dass die über den Import vergebene Nummer nicht mit einer bereits vergebenen oder zukünftig automatisch zu vergebenen übereinstimmt.
Die mindestens erforderlichen Attribute pro Positionsobjekt sind:
- Artikel (ggf. Pseudo-Artikelbezeichnung) – item
- Gesamtmenge (empfohlen außer für Verrechnungs-Artikel; ggf. mit Einheit) – totalQuantity
- Wunschtermin (falls nicht vorhanden, wird der Auftraggeber verwendet) – preferredDate
- Liefertermin – deliveryDate
- Lieferant (falls benötigt und nicht vorbelegt) – supplier
- Lieferempfänger (falls abweichend zu Auftraggeber; falls nicht vorhanden, wird der Auftraggeber verwendet
– deliveryCustomerData.customer - Lagerort (falls benötigt und nicht vorbelegt) – storageArea.warehouse
- Beschaffungsanbindung (falls abweichend zu Belegart) – purchasingReference
- Nettopreis (empfohlen außer für Naturalrabatte; für Belege mit Endverbraucherpreisen zusätzlich Nettopreis inkl. Steuern) – netPrice und retailNetPrice
Optional können Sie mithilfe des Imports einer Position auch eine Nummer (number) übergeben.
Beispiel einer Importdatei
Ein entsprechendes Minimal-XML mit fachlichen Attributen und zwei Positionen hat z. B. den folgenden Inhalt:
<?xml version="1.0" encoding="UTF-8"?>
<semiramis xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive" xsi:schemaLocation="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive SalesOrderArchive.xsd" created="2023-07-27T05:53:59.154Z" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SalesOrderArchive xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive">
<customerOrderData>
<purchaseOrder/>
<date>
<value/>
</date>
</customerOrderData>
<date>2022-07-25T22:00:00.000Z</date>
<number>VA0001714</number>
<customerData>
<CareOfPartner>
<number>71002</number>
</CareOfPartner>
<CustomerPartner>
<number>10010</number>
</CustomerPartner>
</customerData>
<invoiceCustomerData>
<CareOfPartner>
<number>71002</number>
</CareOfPartner>
<CustomerPartner>
<number>10010</number>
</CustomerPartner>
</invoiceCustomerData>
<invoicingPartyData>
<CareOfPartner xsi:nil="true"/>
<Partner>
<number>90000</number>
</Partner>
</invoicingPartyData>
<Currency>
<isoCode>EUR</isoCode>
</Currency>
<Type>
<code>100</code>
</Type>
<Details>
<totalQuantity>
<amount>1</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<preferredDate>
<value>26#08#2023</value>
</preferredDate>
<deliveryDate>2023-08-25T18:00:00.000Z</deliveryDate>
<purchasingReference>NONE</purchasingReference>
<storageArea>
<warehouse>100</warehouse>
</storageArea>
<netPrice>
<amount>1024.1</amount>
<Currency>
<isoCode>EUR</isoCode>
</Currency>
</netPrice>
<retailNetPrice>
<amount>0</amount>
<Currency>
<isoCode>EUR</isoCode>
</Currency>
</retailNetPrice>
<deliveryCustomerData>
<CareOfPartner>
<number>71002</number>
</CareOfPartner>
<CustomerPartner>
<number>10010</number>
</CustomerPartner>
</deliveryCustomerData>
<deliveryPartnerData>
<careOfName/>
<CareOfPartner xsi:nil="true"/>
</deliveryPartnerData>
<Item>
<number>10010</number>
</Item>
<PseudoItemDescription xsi:nil="true"/>
<SupplierPartner xsi:nil="true"/>
</Details>
<Details>
<totalQuantity>
<amount>4</amount>
<Uom>
<code>Stk</code>
</Uom>
</totalQuantity>
<preferredDate>
<value>26#08#2023</value>
</preferredDate>
<deliveryDate>2023-08-25T18:00:00.000Z</deliveryDate>
<purchasingReference>NONE</purchasingReference>
<storageArea>
<warehouse>100</warehouse>
</storageArea>
<netPrice>
<amount>59.35</amount>
<Currency>
<isoCode>EUR</isoCode>
</Currency>
</netPrice>
<retailNetPrice>
<amount>0</amount>
<Currency>
<isoCode>EUR</isoCode>
</Currency>
</retailNetPrice>
<deliveryCustomerData>
<CareOfPartner>
<number>71002</number>
</CareOfPartner>
<CustomerPartner>
<number>10010</number>
</CustomerPartner>
</deliveryCustomerData>
<deliveryPartnerData>
<careOfName/>
<CareOfPartner xsi:nil="true"/>
</deliveryPartnerData>
<Item>
<number>10020</number>
</Item>
<PseudoItemDescription xsi:nil="true"/>
<SupplierPartner xsi:nil="true"/>
</Details>
</SalesOrderArchive></semiramis>
Die restlichen Attribute werden in diesem Beispiel über die Vorschlagswerte gemäß z. B. den Stammdaten hinzugefügt.
Sie können darüber hinaus weitere Werte importieren und statt der fachlichen Attribute auch technische verwenden. Eine Auflistung der Attribute finden Sie in diesem Kapitel: Übersicht: Attribute
Stornierte Positionen
Wird eine Position erzeugt, dann kann sie nicht mit demselben Import storniert werden (der Fall canceled=true steht nicht zur Verfügung). Möchten Sie eine neue Position stornieren, dann müssen Sie zwei Importe durchführen. Im ersten erzeugen Sie die Position mit allen Daten (ohne das Attribut canceled) und im zweiten stornieren Sie die Position, indem Sie das Attribut canceled auf true setzen. Beachten Sie, dass im zweiten Import jede weitere Änderung an dieser Position ignoriert wird.
Bearbeitung bestehender historischer Vertriebsaufträge
Für den Import von historischen Vertriebsaufträgen steht keine Korrektur-Anwendung zur Verfügung. Das bedeutet, dass Sie fehlerhafte Daten mithilfe einer Importdatei und eines erneuten Importvorgangs korrigieren müssen.
Beim Importieren von historischen Vertriebsaufträgen in Multi-Site-Systemen und Single-Site-Systemen mit aktivierten inhaltsbezogenen Berechtigungen wird eine Vertriebsorganisation benötigt. Beim Bearbeiten eines bestehenden historischen Vertriebsauftrages ergibt sich die Vertriebsorganisation immer aus dem in der Datenbank gespeicherten Beleg. Eine evtl. abweichende Vertriebsorganisation in der Importdatei wird in diesem Fall ignoriert.
Für das Auffinden eines in der Datenbank gespeicherten historischen Vertriebsauftrages wird entweder seine technische Identifikation (SalesOrderArchive:guid) oder seine fachliche Identifikation (Type [oder type] und number) benötigt.
Bei den Positionen können sämtliche Möglichkeiten des Imports – also insbesondere auch das Löschen – verwendet werden. Auch dazu wird für das Auffinden einer gespeicherten Position entweder die technische Identifikation (SalesOrderArchiveDetail:guid) oder die fachliche Identifikation (number) benötigt.
Änderungen über den Import sind nur dann möglich, wenn keine Prüfung dies verhindert.
Stornierte Positionen
Für stornierte Positionen und für Positionen, die beim Importieren storniert werden (Attribut canceled wird auf true gesetzt), werden keine weiteren Daten aus der Importdatei übernommen.
Wird für eine Detailposition das Stornokennzeichen entfernt, dann wird auch für die dazugehörige Grundposition das Stornokennzeichen entfernt. Hierbei ist zu beachten, dass die Werte der Grundposition nicht aus der Importdatei übernommen werden. Sie können jedoch Daten für die Grundposition als zusätzlichen Block nach den Detailpositionen aufführen.
Mit folgender XML-Datei wird z. B. in der Detailposition 10-10 des historischen Vertriebsauftrages „100-VA12345“ die Stornierung aufgehoben und gleichzeitig in der Grundposition das Feld „Bezug“ auf den Text „abc“ gesetzt:
<?xml version="1.0" encoding="UTF-8"?><semiramis xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive" xsi:schemaLocation="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive SalesOrderArchive.xsd" created="2023-07-26T15:10:45.999Z" locale="en-US-XMLSchemaCompliant" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" nlsMode="SINGLE_LANGUAGE" dateTimeMode="COMPACT"> <SalesOrderArchive xmlns="com.cisag.app.sales.orderarchive.obj.SalesOrderArchive"> <number>VA12345</number> <Type> <code>100</code> </Type> <Details> <number>10</number> <SubDetails> <number>10</number> <subNumber>10</subNumber> <canceled>false</canceled> </SubDetails> </Details> <Details> <number>10</number> <reference>abc</reference> </Details> </SalesOrderArchive> </semiramis>
Alternativ können Sie auch für die Grundposition die Stornierung aufheben, wodurch automatisch bei allen Detailpositionen dieser Position das Stornokennzeichen ebenfalls entfernt wird.
Automatische Freigabe nach dem Import
Wenn der Import erfolgreich durchgeführt wurde, können Sie einen historischen Vertriebsauftrag automatisch nach dem Import freigeben lassen. So verhindern Sie, dass ein noch nicht vollständig importierter historischer Vertriebsauftrag bereits verwendet werden kann. Während der Freigabe hat der historische Vertriebsauftrag den Status „Ungültig“, sodass er auch in diesem Schritt nicht verwendet werden kann.
Für diese Funktionalität müssen Sie für die relevante Instanz das virtuelle Basis-Attribut autoRelease auf den Wert true setzen.
Ist diese Funktion aktiviert und bestehen keine sonstigen Fehler, dann wird im Meldungsprotokoll eine zusätzliche Informationsmeldung mit dem Hinweis ausgegeben, dass der historische Vertriebsauftrag automatisch freigegeben wurde. War dies nicht möglich, dann wird eine Warnung ausgegeben.
Beachten Sie, dass ab der Freigabe nur noch eine Reorganisation möglich ist. Belege im Status In Bearbeitung (com.cisag.app.general.obj.DocumentReorganizationData:archiveDataStatus) können Sie z. B. per Import wieder löschen. Verwenden Sie dazu den Importmodus mode=“delete“, siehe Dokumentation Einführung: Datenaustausch.
Vorgehensweise: Historische Vertriebsaufträge importieren
-
- Öffnen Sie die Anwendung Daten importieren.
- Lassen Sie sich den bzw. einen Filter für dieses Business Object anzeigen: cisag.app.sales.orderarchive.obj.SalesOrderArchive
→ Der Filter für den Import von historischen Vertriebsaufträgen wird geöffnet. - 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.
Die importierten historischen Vertriebsaufträge können Sie in der Anwendung Cockpit: Historische Vertriebsaufträge abfragen.
Übersicht: Attribute
Nachfolgend sind die Attribute der einzelnen Business Objects aufgeführt, die für den Import zur Verfügung stehen. Bei Fremdschlüsselattributen steht zusätzlich der entsprechende Beziehungsname dabei. Die Identifikations- und Pflichtfelder sind Änderungen unterworfen und können durch Anpassungen erweitert werden.
Bei einigen Business Objects ist für die Umwandlung fachlicher Schlüssel zu technischem Schlüssel eine Organisation notwendig. Bei den Attributlisten ist dies über die Anmerkung „Vertriebsorganisation“ (immer gemäß Basis) in der Spalte Attribut gekennzeichnet.
Die Identifikationsattribute (Key-Attribute) werden über ein „(K)“ gekennzeichnet.
Basisdaten
Historischer Vertriebsauftrag (SalesOrderArchive)
Attribut Beziehung Erläuterung autoRelease Automatisch freigeben (virtuelles Attribut), siehe dieses Kapitel: Automatische Freigabe nach dem Import currency Währung Muss angegeben werden und vorhanden sein. Darf nicht mehr geändert werden, sobald Positionen vorhanden sind.
customerData Siehe dieses Kapitel: Kundendaten (customerData, invoiceCustomerData) customerOrderData.
purchaseOrderFremdbelegnummer customerOrderData.
dateFremdbelegdatum date Erfassungsdatum guid (K) Technische Identifikation für die Änderung/Löschung bereits gespeicherter Daten, wenn bekannt invoiceCustomerData Siehe dieses Kapitel: Kundendaten (customerData, invoiceCustomerData) invoicingPartyData.careOf invoicingPartyData.
CareOfPartnerVertriebsorganisation: zu Händen Es ist nicht notwendig, dass der Ansprechpartner ein aktueller Ansprechpartner der Vertriebsorganisation ist.
invoicingPartyData.
careOfNameVertriebsorganisation: zu Händen Name invoicingPartyData.partner invoicingPartyData.
PartnerVertriebsorganisation - Muss angegeben werden und als gültige Vertriebsorganisation vorhanden sein.
- Muss für die Belegart Pflege-Berechtigung haben.
- Darf nach der Neuanlage nicht mehr geändert werden.
number (K) Nummer (fachliche Identifikation) - Optional bei Neuerzeugung (falls leer, wird sie aus Nummernkreis gemäß Belegart ermittelt)
- Pflichtattribut, wenn bei Änderung/Löschung die GUID nicht angegeben wurde.
responsible ResponsiblePartner Zuständiger Mitarbeiter Es ist nicht notwendig, dass der Partner aktuell ein Mitarbeiter ist.
salesRepresentatives[0..2] SalesRepresentatives[0..2] Vertreter 1 bis 3 Es ist nicht notwendig, dass der Partner aktuell ein Vertreter ist.
type (K) Type Art (fachliche Identifikation): - Pflichtattribut, wenn bei Änderung/Löschung die GUID nicht angegeben wurde.
- Darf für die Neuerzeugung kein Löschkennzeichen besitzen. Darf nach der Neuerzeugung nicht mehr geändert werden.
- Bei Bedarf kann das Löschkennzeichen nachträglich gesetzt werden.
Kundendaten (customerData, invoiceCustomerData)
Die Kundendaten in den beiden Verwendungen sind in der Datenbank als Hash-Code-Business-Object abgelegt und stellen sich für den Export/Import als Part dar. Das gleiche gilt für die Adressdaten. Analog zu den technischen Attributnamen wurden die folgenden Part-Namen vergeben:
- customerData (Auftraggeber)
- invoiceCustomerData (Rechnungsempfänger)
Die folgenden Attribute bestehen demnach pro Verwendung jeweils einmal.
Attribut Beziehung Erläuterung addressData.city Adresse – Ort addressData.country addressData.Country Adresse – Land addressData.district Adresse – Distrikt addressData.poBox Adresse – Postfach addressData.
poBoxCityAdresse – Postfach Ort addressData.
poBoxPostalCodeAdresse – Postfach PLZ addressData.
postalCodeAdresse – Postleitzahl addressData.region addressData.Region Adresse – Region addressData.street Adresse – Straße customer CustomerPartner Kunde Für die Verwendungen
„Auftraggeber“ (customerData) und „Rechnungsempfänger“ (invoiceCustomerData) kann dieses Attribut nicht durch den Import geändert werden, wenn Auftragspositionen vorhanden sind. Die Daten in der Importdatei werden in diesem Fall beim Import ignoriert.careOf CareOfPartner Zu Händen careOfName Zu Händen Name (Ansprechpartnername) name Kundenname Positionsdaten (Grundpositionen und Detailpositionen)
Historische Vertriebsauftragspositionen (SalesOrderArchiveDetail)
Attribut Beziehung Erläuterung canceled Storniert Beachten Sie bitte dieses Kapitel: Erzeugung neuer historischer Vertriebsaufträge
deliveryCustomerData Siehe dieses Kapitel: Lieferempfängerdaten (deliveryCustomerData) deliveryCustomerData.Tax
IdentificationNumberUmsatzsteuer-ID
LieferempfängerdeliveryDate Liefertermin deliveryPartnerData - deliveryPartnerData.careOf
- deliveryPartnerData.
careOfName
CareOfPartner Lieferpartner: - zu Händen
- zu Händen Name (Ansprechpartnername)
ean Europäische Artikelnummer (EAN) Weitere Informationen finden Sie in dieser Dokumentation: Belegposition mithilfe einer EAN importieren
guid (K) Technische Identifikation (Position) für die Änderung/Löschung bereits gespeicherter Daten – sofern bekannt item Item Artikel number (K) Nummer (fachliche Identifikation) optional bei der Neuerzeugung, wird sonst automatisch ermittelt
Pflicht, wenn bei Änderung/Löschung die GUID nicht angegeben wurde
preferredDate.value Wunschtermin priceDimension Preisdimension priceUom PriceUom Preiseinheit pseudoItemDescription Pseudo-Artikelbezeichnung Nur für Pseudo-Artikel. Für alle anderen wird die Angabe ignoriert.
purchasingReference Beschaffungsanbindung reference Bezug storageArea.
warehouseLagerort supplier SupplierPartner Lieferant totalQuantity - totalQuantity.
amount - totalQuantity.uom
Uom
Gesamtmenge - Menge
- Mengeneinheit
Lieferempfängerdaten (deliveryCustomerData)
Die Lieferempfängerdaten sind in der Datenbank als Hash-Code-Business-Object abgelegt und stellen sich für den Export/Import als Part dar. Das gleiche gilt für die Adressdaten. Analog zu dem technischen Attributnamen wurde der Part-Name deliveryCustomerData vergeben.