1                     Themenübersicht

In dieser Dokumentation werden die Vorgehensweisen für den Umgang mit der Anwen­dung „Daten importieren“ bezogen auf Anzahlungsanforderungen beschrieben. Diese Vorgehensweisen ent­hal­ten allgemeine Anleitungsschritte, z. B. welche Besonderheiten zu berücksichtigen sind. Sie werden außerdem über mögliche Vorausset­zungen 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“.

2                     Allgemeines

Der Import der Anzahlungsanforderung basiert im Wesentlichen auf dem aktuellen Datenmodell, welches in der Repository-Datenbank hinterlegt ist.

Die Anzahlungsanforderungen unterstützen beim Import eine Untermenge der beim Export unterstützten Attribute. Wenn Sie also sowohl den Import als auch den Export nutzen möchten, dann ist in diesem Fall – im Gegensatz zu Stammdaten – sinnvoll, wenn Sie für den Export und den Import jeweils mindestens einen eigenen Filter erfassen.

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 (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 im Kapitel „Übersicht: Unterstützte Attribute beim Import“.

Die Anzahlungsanforderung referenziert in der Basis sogenannte Hash-Code-Business-Objects. Das sind fachlich zusammengehörende Attributgruppen, die für viele Belege immer wieder gleich sind und somit durch Wiederverwendung Speicherplatz in der Datenbank und im Hauptspeicher sparen. Über eine spezielle Konvertierung stellen sich die Hash-Code-Business-Objects für den Export bzw. Import wie Parts dar.

Bestimmte Daten der Anzahlungsanforderung, wie Hauswährungswerte, werden beim Import nicht unterstützt.

Hinweis:

Wenn Sie sich nicht sicher sind, welches das geeignete Format der Importdatei ist, dann gehen Sie wie folgt vor: Legen Sie über die Anwendung „Anzahlungsanforderungen“ eine Beispielanzahlungsanforderung an und exportieren Sie diese mit dem Filter für den Import (sic) 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.

Beim Import gelten die gleichen Regeln wie bei der Bearbeitung über die Anwendung. Attributwerte, die im aktuellen Kontext nicht übernommen werden können, werden ignoriert. Ebenso wird bei der Vorschlagswertermittlung die gleiche Logik durchlaufen, sodass sich Import und Anwendung identisch verhalten. Gleiches gilt für die Prüfungen.

Anleitung zum Daten importieren

1. Öffnen Sie die Anwendung „Daten importieren“.
2. Lassen Sie sich den bzw. einen Filter für das Business Object „cisag.app.sales.prepayment.obj.PrepaymentRequest“ anzeigen.
3. Der Filter für den Import der Anzahlungsanforderung wird angezeigt.
   (Bei Bedarf können Sie auch einen neuen Filter für dieses Business Object erfassen.)
4. Die Attribute des Filters sind bereits ausgewählt. Bei Bedarf können Sie die Auswahl anpassen.
5. Drücken Sie in der Standard-Symbolleiste den Button „Daten importieren“.
   • Das Dialogfester „Daten importieren“ wird geöffnet.
6. Im Dialogfenster „Daten importieren“ können Sie Einstellungen für die Importdatei Eine Beschreibung der Felder finden Sie in der Dokumentation „Daten importieren“.
7. Drücken Sie einen der Buttons „Im Hintergrund“ oder „Sofort“.
   • Der Import wird ausgeführt.

3                     Detailinformationen

Nachfolgend finden Sie Hinweise zu den folgenden Themen:

• Neuanlage
• Besonderheiten bei der Bearbeitung einer vorhandenen Anzahlungsanforderung
• Automatische Freigabe nach dem Import
• Altdatenübernahme

3.1               Neuanlage

Die minimal notwendigen Attribute pro Anzahlungsanforderungsobjekt sind:

• Anzahlungsanforderungsart      code
• Bezug „Vertriebsauftrag“ orderAssignmentType
  mit dem Wert „SALES_ORDER“
• Vertriebsauftragsart      Type.code
• Vertriebsauftrag      number

Hinweis:

Voraussetzung ist, dass gemäß Anzahlungsanforderungsart ein Auftrag zugeordnet werden darf.

Sofern der Bezug (orderAssignmentType) mit dem Wert Vertriebsauftrag (SALES_ORDER) per Anzahlungsanforderungsart definiert ist, ist diese Angabe nicht erforderlich.

Alternativ kann sich eine Anzahlungsanforderung auch auf eine konkrete Vertriebsauftragsposition (SalesOrderDetail) beziehen – dann muss der Bezug den Wert „SALES_ORDER_DETAIL“ haben.

Liegt kein Bezug zu einem Vertriebsauftrag oder einer Vertriebsauftragsposition vor, dann wird zudem eine Vertriebsorganisation und ein Rechnungsempfänger sowie mindestens eine Steueraufteilung benötigt, bei der zum einen der Steuerschlüssel festgelegt ist und zudem abhängig von der Betragserfassung gemäß Art entweder der Nettobetrag oder der Bruttobetrag angegeben ist.

Sofern Sie für das Attribut „Alle Steueraufteilungen entfernen“
(removeAllTaxData) den Wert „true” verwenden, werden alle ggf. automatisch ermittelten Steueraufteilungen entfernt und Sie können per Import genau die zu verwendenden Daten angegeben.

Optional können Sie bei der Neuanlage über den Import auch die Nummer (number) übergeben. In diesem Fall wird über den Nummernkreis gemäß Art keine Nummer gezogen. Zudem muss über geeignete Konventionen dafür gesorgt werden, dass die über den Import vergebene Nummer nicht mit einer automatisch gezogenen kollidiert.

Ein Minimal-XML mit fachlichen Attributen und dem Bezug zu einem Vertriebs­auftrag, bei dem sich die Vertriebsorganisation, der Rechnungsempfänger sowie die Steueraufteilungen aus den noch zur Lieferung offenen Positionen eines Auftrages ergeben, hat z. B. den folgenden Inhalt:

<?xml version=”1.0″ encoding=”UTF-8″?><semiramis xmlns=”com.cisag.app.sales.prepayment.obj.PrepaymentRequest” xsi:schemaLocation=”com.cisag.app.sales.prepayment.obj.PrepaymentRequest PrepaymentRequest.xsd” created=”2019-11-15T13:05:35.453Z” locale=”en-US-XMLSchemaCompliant” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” nlsMode=”MULTI_LANGUAGE” dateTimeMode=”NORMALIZED”>

<PrepaymentRequest xmlns=”com.cisag.app.sales.prepayment.obj.PrepaymentRequest”>

<Type>

<code>100</code>

</Type>

<orderAssignmentType>SALES_ORDER</orderAssignmentType>

<SalesOrder>

<number>VA6626</number>

<Type>

<code>100</code>

</Type>

</SalesOrder>

</PrepaymentRequest>

</semiramis>

Die restlichen Attribute erhalten in diesem Beispiel ihre Daten über die Vorschlagswerte gemäß dem angegebenen Auftrag sowie den Stammdaten etc.

3.2               Besonderheiten bei der Bearbeitung einer vorhandenen Anzahlungsanforderung

Bei der Bearbeitung einer vorhandenen Anzahlungsanforderung beachten Sie bitte Folgendes:

Beim Importieren von Anzahlungsanforderungen in Multi-Site-Umgebungen und Single-Site-Umgebungen mit aktivierten inhaltsbezogenen Berechtigungen wird zwingend eine Vertriebsorganisation benötigt. Beim Bearbeiten einer vorhandenen Anzahlungsanforderung ergibt sich die Vertriebsorganisation immer aus dem in der Datenbank gespeicherten Beleg. Eine evtl. abweichende Vertriebsorganisation in der Import-Quelle wird in diesem Fall ignoriert.

Für das Auffinden einer in der Datenbank gespeicherten Anzahlungsanforderung wird entweder die technische Identifikation (PrepaymentRequest:guid) oder die fachliche Identifikation (Type [oder type] und number) benötigt.

Bei den Steueraufteilungen können sämtliche Möglichkeiten des Imports – also insbesondere auch Löschen – verwendet werden. Auch in diesem Fall wird für das Auffinden einer gespeicherten Steueraufteilung entweder die technische Identifikation (TaxData.taxCode) oder die fachliche Identifikation (TaxData.TaxCode.code) des Steuerschlüssels benötigt.

Änderungen über den Import sind nur dann möglich, wenn keine Prüfung das verhindert.

3.3               Automatische Freigabe nach dem Import

Sofern der Import erfolgreich durchgeführt wurde, können Sie eine bearbeitete Anzahlungsanforderung automatisch nach dem Import freigeben lassen. Diese Möglichkeit ist insbesondere in Kombination mit dem Eröffnungsstatus „In Bearbeitung“ (siehe Art) sinnvoll. So verhindern Sie, dass eine noch nicht vollständig importierte Anzahlungsanforderung bereits in Folgebelegen verwendet werden kann. Während der Freigabe hat die Anzahlungsanforderung den Status „Ungültig“, sodass die Anzahlungsanforderung 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 entstehen keine sonstigen Fehler, dann wird im Meldungsprotokoll eine zusätzliche Informationsmeldung mit der Nachricht ausgegeben, dass die Anzahlungsanforderung automatisch freigegeben wurde. War dies nicht möglich, dann wird eine Warnung erzeugt.

3.4               Altdatenübernahme

Die Anzahlungsanforderungen unterstützen keine Altdatenübernahme.

4                     Übersicht: Unterstützte Attribute beim Import

In diesem Kapitel werden sämtliche beim Import von Anzahlungsanforderungen unterstützten Attribute aufgelistet. Bei Fremdschlüsselattributen steht zusätzlich der entsprechende Beziehungsname dabei. Die Attribute können Änderungen unterworfen sein und durch Anpassungen auch erweitert werden.

Bei einigen Business Objects ist für die Umwandlung fachlicher Schlüssel zu technischem Schlüssel eine Organisation (Organisation) notwendig. Bei den Attributlisten ist dies über die folgenden Anmerkungen in der Spalte „Attribut“ gekennzeichnet.

• Vertriebsorganisation (immer gemäß Basis)
• Firma (immer gemäß Basis)

Die Identifikationsattribute (Key Attribute) werden zudem über ein (K) gekennzeichnet.

4.1               Basisdaten

4.1.1          Anzahlungsanforderung (PrepaymentRequest)

4.1.2          Kundendaten (invoiceCustomerData)

Die Kundendaten in den verschiedenen Rollen 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 wurde der folgende Part-Name vergeben:

invoiceCustomerData                  Rechnungsempfänger

Die folgenden Attribute bestehen also für diese Rolle jeweils einmal.

4.1.3          Ausgabeeinstellungen (outputSettings)

Die Ausgabeeinstellungen sind in der Datenbank als Hash-Code-Business-Object abgelegt und stellen sich für den Export/Import als Part dar.

4.1.4          Texte (TextAssignments)

text

Das folgende Beispiel enthält zwei Basistexte. Der Kopftext referenziert den Textbaustein „TXT1“, und der zweite Text enthält einen freien Fußtext für die Sprachen de und en:

<?xml version=”1.0″ encoding=”UTF-8″?><semiramis xmlns=”com.cisag.app.sales.prepayment.obj.PrepaymentRequest” xsi:schemaLocation=”com.cisag.app.sales.prepayment.obj.PrepaymentRequest PrepaymentRequest.xsd” created=”2019-11-18T09:41:59.531Z” locale=”en-US-XMLSchemaCompliant” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” nlsMode=”MULTI_LANGUAGE” dateTimeMode=”NORMALIZED”>

<PrepaymentRequest xmlns=”com.cisag.app.sales.prepayment.obj.PrepaymentRequest”>

<orderAssignmentType>SALES_ORDER</orderAssignmentType>

<Type>

<code>100</code>

</Type>

<orderAssignmentType>SALES_ORDER</orderAssignmentType>

<SalesOrder>

<number>VA6626</number>

<Type>

<code>100</code>

</Type>

</SalesOrder>

<TextAssignments>

<sequence>10</sequence>

<document index=”0″>PREPAYMENT_REQUEST</document>

<type>HEADER</type>

<code>TXT1</code>

</TextAssignments>

<TextAssignments>

<sequence>20</sequence>

<document index=”0″>PREPAYMENT_REQUEST</document>

<type>FOOTER</type>

<code/>

<text>

<language>de</language>

<text>Dies ist ein Beispieltext.</text>

<contentType>text/plain</contentType>

</text>

<text>

<language>en</language>

<text>This is an example text.</text>

<contentType>text/plain</contentType>

</text>

</TextAssignments>

</PrepaymentRequest>

</semiramis>

Bei den Texten können Sie auch diverse Formatierungen verwenden. Benötigen Sie für konkrete Formatierungen Beispiele, so erfassen Sie am besten einen Muster-Beleg mit den gewünschten Textformatierungen und exportieren diesen.

Hinweis:

Normalerweise gilt beim Import von Texten die Regel „Sind in der Importdatei Texte vorhanden, dann werden evtl. Vorschlagswerte aus den Partner-Stammdaten etc. ignoriert”. Hat die Server-Property com.cisag.app.general.order.bi.applyAllwaysTextDefaults den Wert „true“, dann werden in jedem Fall normal die Vorschlagswerte ermittelt und mit den ggf. in der Importdatei vorhandenen Texten kombiniert. Hierbei ist zum einen zu beachten, dass die Nummern der Textzeilen passend gewählt sein müssen und im Ergebnis nur eine Text-Zeile pro Kopf- und Fußtext herauskommt.

4.2               Steueraufteilungen (TaxData)