Zusatzmodule

• 1: Schnittstellen
• 1.1: Schnittstellen - Installation und Einrichtung
• 1.2: URA (Universal REST API)
• 1.2.1: Request Aufbau
• 1.2.2: Einrichtung und Konfiguration Universal REST API
• 1.2.3: GUI-Tool
• 1.2.4: Beispiele
• 1.2.5:
• 2: Rechnungsmanager
• 3: konfipay-Service Integrator
• 4: DATEV Connector
• 5: Aareon Connect in Microsoft Entra ID
• 6: Archiv kompakt (AAk)
• 6.1: Benutzer Synchronisierung mit Mandantenberechtigung
• 6.1.1: Neustart mit RELion und Archiv kompakt
• 6.1.2: Update RELion ONE bei Companial
• 6.1.3: Migration zu Saas
• 6.2: Einrichtung Entra-ID
• 6.3: Prozessablauf Archiv kompakt
• 7: OpenImmo Connector

1 - Schnittstellen

Dieser Abschnitt enthält Information zu den Schnittstellen in RELion ONE.

1.1 - Schnittstellen - Installation und Einrichtung

Schnittstellen - Installation und Einrichtung

Überblick und Zuständigkeiten

flowchart TD
    classDef Aareon_blue fill:#051163,stroke:#051163,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Bright_blue fill:#086DFB,stroke:#086DFB,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Sand        fill:#F7F3F0,stroke:#F7F3F0,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Stone       fill:#EBE3DC,stroke:#EBE3DC,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Coral       fill:#FF7F62,stroke:#FF7F62,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Peach       fill:#FFD8CA,stroke:#FFD8CA,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Green       fill:#50B214,stroke:#50B214,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Light_green fill:#B9E99C,stroke:#B9E99C,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Baby_blue   fill:#A4CBFF,stroke:#A4CBFF,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Burgundy    fill:#550000,stroke:#550000,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Dark_green  fill:#2F630E,stroke:#2F630E,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif

    E[Microsoft Entra ID]:::Coral
    RP[RELion<br>Produktiv]:::Green
    RS[RELion<br>Sandbox]:::Green
    NSTP[Business Central Dienst<br>Produktiv]:::Bright_blue
    NSTS[Business Central Dienst<br>Sandbox]:::Bright_blue

    subgraph SGE["`**Kunde - Entra-Admin**`"]
        E
    end
    class SGE Peach

    subgraph SGR["`**Kunde - Super-User**`"]
        E --> RP
        E --> RS
    end
    class SGR Light_green

    subgraph SGNST["`**Aareon RELion - Dev-Ops**`"]
        RP --> NSTP
        RS --> NSTS
    end
    class SGNST Aareon_blue

1.2 - URA (Universal REST API)

Mit der Universal REST API bietet RELion eine Möglichkeit, auf jede Tabelle über einen REST API Aufruf zuzugreifen. Der schematische Aufbau des Calls ist für jede Tabelle identisch und eine Ausführung der RELion Business Logik gewährleistet. Es stehen Standardfunktionen für die Interaktion mit RELion zur Verfügung:

• Einfügen
• Ändern
• Kombiniertes Einfügen und Ändern
• Löschen eines Datensatzes
• Lesen (einzelner Datensatz oder mehrere Daten)
• Ändern des Primärschlüssels eines Datensatzes

Weitere ergänzende Funktionen sind:

• der Bulk Modus
• die Verwendung von verschiedenen Konfigurationen
  
  

Universal REST API in sechs Schritten

1. Identifizierung der RELion Tabelle in der GUI
2. BC Tabellen Nummer und Feldnummern heraussuchen
3. Erstellen des REST Requests, bestehend aus oa. Nummern und dem Payload
4. Senden des Requests an die universal REST API
5. Verarbeitung des Request durch RELion
6. Rückmeldung der Verarbeitung
   a. Verarbeitung war fehlerfrei, Rückmeldung mit dem angelegten oder geänderten Datensatz
   b. Verarbeitung lief auf einen Fehler, Rückmeldung des Fehlers in Klartext

Die Business Logik in BC basiert stark auf der Reihenfolge, wie der Anwender Felder in einer Tabelle füllt, auch diesen Umstand berücksichtig die REST API, die Reihenfolge der Felder im JSON Body entsprechen der Reihenfolge, indem die API die Daten in die RELion Tabelle schreibt. Eine Umstellung ist jederzeit durch eine Umsortierung der Felder im Request möglich. Mit weiteren Parametern kann die REST API auch komplexe Einfügeoperationen in RELion abbilden (z. B. kombinierte Einfüge und Update Anweisungen oder das Überspringen von Validierungen).

Anders als bei SQL-Abfragen auf BC-Tabellen, kann die universal REST API auch die Flow Fields einer Tabelle zurückgeben. Dies bezieht sich auf Tabellenfelder, berechnete Felder, welche nur auf den Pages oder in Infoboxen vorhanden sind, berücksichtigt die API nicht. Durch die mögliche Verwendung von verschiedenen Konfigurationen pro REST API Aufruf, kann die API, je nach Anwendungszweck, diese Daten in die Antwort aufnehmen oder nicht.

Darüber hinaus sind auch gebündelte Operationen möglich. In einem REST API Aufruf sind dann mehrere Datensätze zum Einfügen oder Ändern enthalten, dies spart dann die Zeit für dem Aufbau der Webserviceverbindung pro Datensatz und kann die Laufzeit bei einer großen Menge an Daten senken. Auch diese Bulk-Übertragungen haben die identischen Möglichkeiten eines Aufrufes pro Datensatz.

In dem Beispiel wird der Übertrag eines Debitors aus einem Fremdsystem nach RELion dargestellt, vor allem die Ableitung aus der RELion Tabelle und den daraus resultierenden Request.

Das Auslösen der Kommunikation und der Abgleich der Tabellen und Felder ist nicht Bestandteil dieser Dokumentation.

1.2.1 - Request Aufbau

Aufbau eines Request

Base URL

Die Requests sind an die Adresse der URA zu senden. Diese ist

OnPrem:
https://{{base URL}}:{{port}}/{{serverinstance}}/api/aareon/universalapi/v1.0/companies({{Company-Id}})/universalRequests?$expand=entitySet

URA GET

Die GET-Methode zeigt lediglich die Verfügbarkeit der API an, die Universal REST API steht für alle Mandaten zur Verfügung und benötigt zur Identifikation des Mandanten noch die Mandanten ID in der URL. Die Prüfung, ob die API verfügbar ist benötigt diesen Zusatz nicht.

Die Adresse für die GET-Methode setzt sich aus vier Komponenten zusammen:

1. Webadresse des Servicetiers
2. Port der BC OData Services
3. BC Dienstnamen
4. restliche Pfad: /api/aareon/universalapi/v1.0/$metadata

Eine vollständige Adresse für einen GET Aufruf wäre somit:
http://MeinServer:14048/MeinServiceTier/api/aareon/universalapi/v1.0/$metadata
Zurück kommt ein XML-File mit allen aktiven API’s:

URA POST

Für einen Request wird immer ein POST-Request an den Endpunkt geschickt. Dieser enthält einen Body mit einem JSON. Das JSON besteht aus zwei Teilen, der Definition der Tabelle und den Daten, welche auf die Tabelle anzuwenden sind. Die verschiedenen Ausprägungen des Bodys sind in JSON Body beschrieben.

Beispiel:

Lesen aus der Tabelle mit der ID 5050. Es werden die Felder mit der ID 1 und ID 2. Die ersten 620 Datensätze werden übersprungen und dann werden 100 Datensätze geliefert.

Request:

{
    "tableNo":  "5050",
    "operation":  "READ",
    "top": "100",
    "skip":"620",
    "entitySet":  [
                      {
                          "subOperation":  "Done",
                          "responseFields":  "1|2"
                      }
                  ]
}

Response:

{
  "@odata.etag": "W/\"JzIwOzE2Mjg3NjY1MDI0ODQ3NzE5ODM0MTswMDsn\"",
  "headerId": "8804c1b9-444c-42cb-809c-6ea49e0dc91e",
  "lineNo": "10000",
  "fieldNo": 0,
  "filter": false,
  "dimensionSetId": false,
  "dimensionSetIdMutation": 0,
  "dimension": false,
  "dimensionCode": "",
  "validate": false,
  "value": "",
  "subOperation": "DONE",
  "resetFilter": false,
  "singleCommit": false,
  "responseFields": "1|2",
  "totalCount": 625,
  "skippedRows": 620,
  "numberOfRows": 625,
  "moreRows": false,
  "done": false,
  "countOfReturnRows": 5,
  "ResponseJson2": "eyJEYXRhIjpbeyJOby4iOiJLMDEwMDA0IiwiTmFtZSI6IkRldXRzY2hlIFRlbGVjb20gQUcifSx7Ik5vLiI6IkswMTAwMDUiLCJOYW1lIjoiRGViaXRvIFJlc2VzIn0seyJOby4iOiJLMDEwMDA2IiwiTmFtZSI6IlRydWRlbCBXZXJlcyJ9LHsiTm8uIjoiSzAxMDAwNyIsIk5hbWUiOiJEZWxvcmVzIDEwMDAifSx7Ik5vLiI6IkxFRVIiLCJOYW1lIjoiTGVlciJ9XX0="
}

Im Feld ResponseJson2 gibt die REST API den angelegten Datensatz in Base64 Kodierung zurück. Encodiert ist es JSON. Sie können die Anzahl der Felder, welche die API zurückgibt, über den Parameter responseFields einschränken. Ohne den Eintrag gibt die API immer alle Felder aus der Tabelle zurück.

Decodiert steht nun da:

{
  "Data": [
    {
      "No.": "K010004",
      "Name": "Deutsche Telecom AG"
    },
    {
      "No.": "K010005",
      "Name": "Debito Reses"
    },
    {
      "No.": "K010006",
      "Name": "Trudel Weres"
    },
    {
      "No.": "K010007",
      "Name": "Delores 1000"
    },
    {
      "No.": "LEER",
      "Name": "Leer"
    }
  ]
}

Die Prüfung der Datenfelder erfolgt durch Business Central. Bei nicht passenden Kombinationen (z. B. Text in ein Zahlenfeld zu schreiben oder nicht vorhandene Werte in verbundenen Tabellen), beendet die API den Request mit einer Fehlermeldung.

URA JSON Body

Json Header

Der Body besteht aus einem “Kopf”, dem universalRequest und dann einen Array von zusammenhängenden Befehlsblöcken, dem entitySet. Eine Suboperation schließt jeweils einen Befehlsblock logisch ab.

Die Befehlsblöcke setzen sich aus verschiedenen Attributen zusammen, je nach Verwendungszweck des Blockes. Die API arbeitet die Blöcke sequenziell ab, die Reihenfolge legt somit auch die Filter und Validierungsreihenfolge in BC fest.

Die BC Tabelle ist pro Aufruf konstant, alle Operationen führt die API nur auf dieser Tabelle durch, Kopf und Zeilen Strukturen benötigen zwei API aufrufe. Die benötigten Daten liefert die API nach Abschluss der gesamten Operation zurück.

Die API liefert als Antwort nochmals den gesamten Aufruf als Body mit, dies ist technisch begründet und kann nicht unterbunden werden. In jedem Suboperation Block ist das Attribut response vorhanden, in diesem Attribut kann die API den neuen / geänderten Datensatz nach der jeweiligen Operation zurückliefern, je nach Suboperation und Anwendungsfall.

Das Feld response ist BASE64 codiert und enthält ein JSON mit den Daten der Tabelle, ein Filter kann die zurückgegebenen Felder einschränken.

Der Aufbau des entitySet Bereiches ist variabel, um die verschiedensten Konstellationen in BC abzubilden, die drei am meisten genutzten Anwendungsbereiche sind dabei:

1. Einzelanweisung, ein Datensatz ohne komplexe Trigger und Validierungen über die API einfügen oder verändern.
2. Kombinierte Anweisung, INSERT und UPDATE in einem Aufruf. Komplexe Trigger und Validierungen über die API. simulieren, beispielsweise setzt der Inserttrigger beim Einfügen eines Debitors die Debitorennummer und einige Defaultwerte, diese können dann im folgenden UPDATE Teil, innerhalb eines Aufrufes, auf die gewünschten Werte angepasst werden.
3. Einfügen einer großen Datenmenge mit wenigen Aufrufen (BULK – Modus). Ziel ist es, die Minimierung des Overheads für die Kommunikation über die API. In einem Aufruf sind 30 bis 50 Datensätze enthalten, welche die API in einer Datenbank Transaktion verarbeitet.

• tableNo - Tabellen Nummer
  Das Attribut tableNo spezifiert die Tabellen in BC auf welche die Operation angewendet werden soll. Es ist die Nummer der Tabelle aus BC anzugeben. Diese ist abrufbar unter anderem über den Punkt Info zu der Seite.

• operation - Funktionen auf BC Tabellen
  Es stehen diese Funktionen zur Verfügung: Einer dieser Operationen ist in der Ebene universalRequest anzugeben, sie definiert den übergeordneten Anwendungsfall. Reicht eine Operation pro Webrequest, so ist dieser mit der subOperation DONE in der Ebene entitySet zu bestätigen. Verschiedene Anwendungsfälle, wie ein INSERT gefolgt von einem UPDATE oder BULK Operationen, lassen sich mit den subOperationen in der der Ebene entitySet abbilden.

  • INSERT
    Mit der INSERT – Operation fügt die API die im Bereich entitySet definierten Daten der definierten BC Tabelle hinzu, ob der BC Insert Trigger dabei zur Ausführung kommt, bestimmt ein weiterer Parameter. Die Reihenfolge in der die API die einzelnen Felder in die BC Tabelle einfügt, ist durch die Reihenfolge der Daten in entitySet Bereich festgelegt, über diesen Mechanismus sind verschiedene Feldvalidierungsreihenfolgen abbildbar.
  • UPDATE
    Mithilfe der UPDATE – Operation, kann die API Daten eines bestehenden Datensatzes verändern. Filterkriterien um den Datensatz zu bestimmen sind im entitySet Bereich zu definieren.
  • DELETE
    Der DELETE-Operator benötig einen Filter, der nur einen Datensatz als Ergebnis liefert, bei mehr als ein Datensatz pro Operation liefert die API einen Fehler, damit sind Löschvorgange auf einen ganzen Bereich in einer Operation ausgeschlossen.
  • RENAME
    BC unterscheidet zwischen einer Änderung von Daten und einem Umbenennen von Daten, bei der Änderung sind keine Felder des Primärschlüssel, den eindeutigen Identifier des Datensatzes in der Tabelle, betroffen. Ein Primärschlüssel (PS) kann mehrere Felder einschließen, ist nur ein Feld von einer Änderung betroffen, so geht BC und damit auch die API von einem Rename aus.
  • READ
    Die API kann zusätzlich zu den Schreiboperationen auch Datensätze aus Tabellen zurückliefern. Die READ-Operation liefert je nach mitgegeben Filter 0 bis alle Datensätze einer Tabelle zurück. Die maximale Anzahl der zurückgelieferten Daten bestimmt der Wert numberOfEntitiesToRead in der Konfiguration, im Standard 100.
  • READLAST
    Die API kann zusätzlich zu den Schreiboperationen auch Datensätze aus Tabellen zurückliefern. Die READLAST Operation liefert je nach mitgegeben Filter keinen oder den letzten Datensatz passend zu dem Filter aus einer Tabelle zurück. Der Request ist immer mit der “subOperation”:“DONE” abzuschließen. Mehrfache Operationen sind nicht zulässig.

• runTrigger – Attribut
  BC Tabellen haben für jede Art der Änderung an Tabellen Trigger, welche Code ausführen können. Dieses Attribut steuert, ob die API den jeweiligen Triggers ausführt (true) oder nicht (false). Der Insert-Trigger auf der Debitorentabelle (18) führt verschiedene Prüfungen durch, unter anderem prüft er, ob eine Debitorennummer vorhanden ist, sollte dies nicht der Fall sein, holt sich der Trigger diese aus den Nummernserien.

• setupCode – Attribut
  Ohne die Angabe oder mit der Angabe eines nicht definierten setupCode’s verwendet die API immer die Konfiguration mit leeren Code Feld.

• entitySet – Attribute
  Attribute teilen sich in MUSS und KANN Attribute auf, fehlt ein MUSS Attribut quittiert dies die API mit einem Fehler. KANN Attribute haben Standardwerte, diese sind in dem entsprechenden Kapitel erläutert. Die verschiedenen Attribute sind sechs Gruppen zuzuordnen und nur in diesen Gruppen zu verwenden:

  1. Abschluss einer Operation oder Suboperation
  2. Einfügen von Daten
  3. Ändern von Daten
  4. Löschen von Daten
  5. Lesen von Daten
  6. obsolete Attribute

• Operation und Suboperation
  Jeder Request ist mit einer Suboperation abzuschließen, diese löst die Verarbeitung der Daten in der API aus. Ein Aufruf mit Blöcken ohne eine Suboperation am Ende hat keine Auswirkung auf das System, RELion speichert den Aufruf ohne diesen auszuführen.

  Die Anordnung der Blöcke entspricht der Verarbeitungsreihenfolge, dies hat direkte Auswirkung auf die Validierungsreihenfolge in RELion. Das Einfügen einer Objektnummer ohne vorheriges Füllen des Eigentümer/Mieter Kennzeichens löst beispielsweise eine Fehlermeldung aus. Oft sind die Feldreihendfolgen auf den BC Pages eine Orientierung für die korrekte Reihenfolge der Felder für die API.

  Auch Suboperationen beziehen sich auf die im tableNo Attribut definierte Tabelle, es ist nicht möglich Daten durch Suboperationen in unterschiedliche Tabellen zu schreiben.

  Die Anwendung von Suboperationen ist in drei Bereich aufzuteilen:

  1. Insert – Update Aufrufe, um Daten, welche RELion bei der Ausführung des Insert Triggers durch Default Werte ersetzt mit einem anschließenden Update Teil in einem Aufruf einzufügen.
  2. Insert - …… -Insert (BULK) Einfügeoperationen, ein Aufruf schreibt mehrere Datensätze in die Datenbank.
  3. Update - …… - Update Änderungsoperationen, ein Aufruf ändert verschiedene Datensätze.

  Der kombinierte Aufruf von Insert – Update vereinfacht das Einfügen von Daten, wenn der RELion Insert Trigger, beispielsweise die Nummer aus der Nummernserie holt und dann weitere Default Werte setzt, aber die Daten genau diese Default Werte ändern. Hier sind dann nicht mehr zwei Aufrufe mit der Verarbeitung der Antwort nötig. Die API behält den neu angelegten Datensatz im Fokus und führt dann die gewünschte Änderung nach dem Einfügen der Daten in die Datenbank in einem API Aufruf durch.
  

  Die BULK Bereiche Insert und Update, dazu gehört auch eine mehrfach kombinierte Insert – Update Anweisung, ist vor allem für große Datenmengen konzipiert. Der Overhead für den Aufbau und Abbau der Verbindung fällt nur einmal für die Anzahl der gemeinsam übertragenden Daten an, nicht für jede Operation.

  • Gültige Attribute für den Suboperationsbereich
    Vier Attribute sind zulässig:

    "subOperation": "DONE….",
    "resetFilter": false, 
    "singleCommit": false, 
    "responseFields": "1|2"
    

    Das Attribut subOperation ist zwingend und beschreibt die Vorgehensweise mit welcher die API die vorher übergebenen Blöcke verarbeitet. Die möglichen Ausprägungen sind:

    1. DONE
       Schließt die im Attribut operation definierte Operation ab und füllt das Attribut response. DONE beachtet die Option responseFields, alle anderen Optionen bleiben unbeachtet. Die Operationen READ sind immer mit einem DONE abzuschließen, ebenso bei Aufrufen mit einer Operation.

    2. INSERT
       Mittels INSERT fügt die API einen Datensatz mit den übergebenen Werten in die spezifizierte Tabelle ein. Ein INSERT erstellt keinen Inhalt im Attribut response. Für weitere Operationen speichert die API eine Referenz auf den neuen Datensatz. Diese Suboperation macht keinen Gebrauch von weitere Attributen. Beispiel für zwei Inserts, einmal der Wert 10 und einmal der Wert 20 in das Feld 100:

       { 
         "tableNo": "5358944", 
         "operation": "INSERT", 
         "runTrigger": true, 
         "entitySet": [
           {
              "fieldNo": 100,
              "validate": true, 
              "value": 
              "10" 
            },
            { 
              "subOperation": "INSERT" 
            }, 
            {
              "fieldNo": 100, 
              "validate": true, 
              "value": "20" 
            }, 
            { 
              "subOperation": "INSERT"
            }
          ]
        }
       

    3. INSERT_RESPONSE
       Zusätzlich zum Einfügen der Daten in die Datenbank, erstellt ein INSERT_RESPONSE auch das Rückgabe-JSON in dem Attribut response. Für jeden Datensatz erstellt die API den Rückgabewert in dem zugehörigen Suboperationsbereich. Mit dem Attribut resonseFields lassen sich die Felder in dem Rückgabewert einschränken. Das gleiche Beispiel wie im Beispiel Suboperation INSERT, nur diesmal mit INSERT_RESPONSE:

       { 
           "tableNo": "5358944", 
           "operation": "INSERT", 
           "runTrigger": true, 
           "entitySet": [ 
               { 
                   "fieldNo": 100, 
                   "validate": true, 
                   "value": "10" 
               }, 
               { 
                   "subOperation": 
                   "INSERT_RESPONSE", 
                   "responseFields": "1|100" 
               }, 
               { 
                   "fieldNo": 100, 
                   "validate": true, 
                   "value": "20" 
               }, 
               {
                   "responseFields": "1|100", 
                   "subOperation": 
                   "INSERT_RESPONSE" 
               }
           ] 
       }
       

       In der Antwort ist aber nun auch das ResponseJson2 wie beim READ gefüllt.

    4. UPDATE
       Ein UPDATE ändert einen bestehenden Datensatz, Anpassungen von mehreren Datensätzen in einer Suboperation, über einen Filter, der mehr als einen Datensatz liefert, unterstütz die API nicht. Eine Update Anweisung, ohne vorheriges Einfügen eines Datensatzes, benötig einen Filter zur Identifizierung. Ein Filter besteht aus dem Tripel von Attributen fieldNo, value und filter, diese sind vor der Suboperation zu definieren. Das Attribut value nimmt Werte eines Standard BC Filters, wie “>10” oder “1|2”, entgegen. Bei der Suboperation UPDATE erzeugt die API keine Antwort wie auch beim INSERT.
       
       

       Bei kombinierten Anweisungen behält die API den Fokus auf dem vorherigen Datensatz. Damit ist es möglich weitere Anweisungen auf dem identischen Datensatz auszuführen ohne einen neuen Filter zu definieren. Um Updates auf verschiedenen Datensätzen kombiniert durchzuführen, setzt das Attribut resetfilter den Filter nach der Suboperation zurück.

    5. UPDATE_RESPONSE
       Die Vorbedingungen für die Suboperation UPDATE_RESPONSE sind identisch mit den aus SubOperation UPDATE, im Unterschied zum UPDATE erzeugt die API beim UPDATE_RESONSE eine Antwort im response Attribut.
       Mittels dieser Operation sind Konstellationen wie Einfügen und Ändern von Datensätzen mit Rückmeldung möglich, auch mehrfache Updates mit einem UPDATE_RESPONSE am Ende liefern dann den endgültigen Datensatz zurück, der Overhead eine Rückmeldung für jede Suboperation zu erstellen und auszuwerten entfällt. Beispiel:

       {
           "tableNo": 5358944", 
           "operation": "INSERT", 
           "runTrigger": true, 
           "setupCode": "", 
           "entitySet": [ 
               {
                   "fieldNo": 100, 
                   "validate": true, 
                   "value": "10" 
               }, 
               { 
                   "fieldNo": 2,
                   "validate": true, 
                   "value": "99"
               }, 
               { 
                   "subOperation": "INSERT" 
               }, 
               { 
                   "fieldNo": 3, 
                   "validate": true, 
                   "value": "99" 
               }, 
               { 
                   "subOperation": "UPDATE" 
               }, 
               { 
                   "fieldNo": 2, 
                   "validate": true, 
                   "value": "199" 
               }, 
               { 
                   "responseFields": "100|2|3", 
                   "subOperation": "UPDATE_RESPONSE" 
               }
           ] 
       }
       

       Die API fügt einen neuen Datensatz in die Tabelle ein, dabei ist der Wert des Feldes 2 = 99 und das Feld 3 ist leer. Im zweiten Schritt erfolgt ein Update auf den eingefügten Datensatz, da die Definition eines neuen Filters für die Update Operation fehlt. Im letzten Schritt überschreibt die API das Feld 2 mit dem Wert 199, die Operation erfolgt immer noch auf dem eingefügten Datensatz. Schließlich erzeugt die Suboperation UPDATE_RESPONSE eine Antwort mit den Feldern 100,2 und 3.
       

    6. RENAME
       Analog zu der Operation RENAME, ist die serielle Verarbeitung mehrere Umbenennungen über die Suboperation RENAME möglich.

       { 
           "tableNo": "5358944", 
           "operation": 
           "RENAME", 
           "runTrigger": true, 
           "setupCode": "", 
           "entitySet": 
           [ 
               { 
                   "fieldNo": 1,
                   "filter": true, 
                   "value": "{53cd97b6-cc44-40ce-8f6b-4a8167f9422c}" 
               }, 
               { 
                   "fieldNo": 1, 
                   "validate": true, 
                   "value": "{53cd97b6-cc44-40ce-8f6b-4a8167f9422d}" 
               }, 
               { 
                   "responseFields": "1|2|100", 
                   "subOperation": "RENAME" 
               }, 
               { 
                   "fieldNo": 1, 
                   "filter": true, 
                   "value": "{68cd97b6-cc44-40ce-8f6b-4a8167f9422c}" 
               }, 
               { 
                   "fieldNo": 1, 
                   "validate": true, 
                   "value": "{68cd97b6-cc44-40ce-8f6b-4a8167f9422d}" 
               }, 
               { 
                   "responseFields": "1|2|100", 
                   "subOperation": "RENAME" 
               }
           ] 
       }
       

       Die API berücksichtigt Tablerelations, somit ist zu berücksichtigen, dass mehrfach Umbenennungen durchaus in einen Timeout der API laufen können.

    7. READ
       Die Suboperation kann zur Anwendung kommen, wenn zwei oder mehr Datensätze in einem Request aus BC zu lesen sind und dies nicht über einen Filter möglich ist oder das aufrufende System keine mehrfachen Datensätze im responseJson Attribut verarbeiten kann.

    8. DELETE
       Analog zu der RENAME Suboperation, kann der DELETE Suboperator mehrere Datensätze in einem REST API Call löschen, pro Operation jedoch nur einen Datensatz. So könnte man Zeilen zu einem spezifischen Kopf löschen. Zuerst die Zeilen per READ auslesen und dann alle Zeilen in ein DELETE Request aufnehmen. Beispiel für das löschen mehrerer Datensätzen in einem Request:

       { 
           "tableNo": "5358944", 
           "operation": "DELETE", 
           "runTrigger": true, 
           "setupCode": "", 
           "entitySet": [
               { 
                   "fieldNo": 1, 
                   "filter": true, 
                   "value": "{7df044ad-e5a8-4f61-83cc-0014e8837af8}" 
               }, 
               { 
                   "subOperation": "DELETE" 
               }, 
               { 
                   "fieldNo": 1, 
                   "filter": true, 
                   "value": "{576044cd-e7a8-4c61-82cc-001cdedd7af8}" 
               }, 
               { 
                   "subOperation": "DELETE" 
               }
           ] 
       }
       

    
    Die API speichert den Verweis auf den Datensatz, welche bei der Ausführung der Suboperation im Zugriff war. Soll die API auf ein anderer Datensatz mit einem folgenden Bereich zugreifen, so löst "resetFilter": true den Filter auf den Datensatz auf und eine neue Definition eines Filters ist möglich. Das Attribut ist im Standard false und nur bei Bedarf zu füllen.

    Im Standard ist ein API Aufruf auch eine Transaktion. Dabei schreibt BC alle Änderungen gesammelt am Ende in die Datenbank, tritt ein Fehler bei der Verarbeitung auf, dann speichert BC keine Änderung. Mit dem Attribut “singleCommit”: true ändert die API das Verhalten und schreibt jeden abgeschlossenen Bereich in die Datenbank. Dem Vorteil, jeden Block sofort in der Datenbank zu speichern, stehen eine wesentlich geringere Performance und aufwendigere Aufbereitung der fehlerhaften Daten gegenüber. Bis auf besondere Fälle ist das Standardverhalten ein Aufruf gleich einer Transaktion dem singleCommit vorzuziehen.

    Die Fehlerbehandlung bei mehreren Insert Bereichen ist je nach dem Attribut singleCommit anzupassen. Da die Daten mit aktivierten singleCommit bis zum Fehler in der Datenbank vorhanden sind, bei deaktivierten hingegen nicht.

    Ohne das Attribut responseFields gibt die Schnittstelle immer alle Felder der Tabelle im response JSON zurück. Um die Anzahl der Felder einzuschränken, nimmt die API im Attribut responseFields einen BC Filterstring mit den Feldnummern der Tabelle auf. Soll im response nur die Felder 3,5,50001 und 5358755 enthalten sein, so ist das Attribut “responseFields”: “3|5|50001|5358755” der Suboperation hinzuzufügen. Jeder Suboperation kann eine unterschiedliche Ausprägung des Attributes zugeordnet sein.

1.2.2 - Einrichtung und Konfiguration Universal REST API

Einrichtung

Um eine sichere Verbindung zwischen den Systemen aufbauen zu können, wird der Standard OpenID Connect verwendet. In Bezug auf Microsoft Dynamics 365 Business Central lautet das Stichwort hier “Service-to-Service” Authentication (S2S): https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/automation-apis-using-s2s-authentication

Somit sind grundsätzlich Tätigkeiten in drei Ebenen nötig.

flowchart TD
    classDef Aareon_blue fill:#051163,stroke:#051163,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Bright_blue fill:#086DFB,stroke:#086DFB,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Sand        fill:#F7F3F0,stroke:#F7F3F0,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Stone       fill:#EBE3DC,stroke:#EBE3DC,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Coral       fill:#FF7F62,stroke:#FF7F62,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Peach       fill:#FFD8CA,stroke:#FFD8CA,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Green       fill:#50B214,stroke:#50B214,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Light_green fill:#B9E99C,stroke:#B9E99C,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Baby_blue   fill:#A4CBFF,stroke:#A4CBFF,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Burgundy    fill:#550000,stroke:#550000,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Dark_green  fill:#2F630E,stroke:#2F630E,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif

    E[Microsoft Entra ID]:::Coral
    RP[RELion<br>Produktiv]:::Green
    RS[RELion<br>Sandbox]:::Green
    NSTP[Business Central Dienst<br>Produktiv]:::Bright_blue
    NSTS[Business Central Dienst<br>Sandbox]:::Bright_blue

    subgraph SGE["`**Kunde - Entra-Admin**`"]
        E
    end
    class SGE Peach

    subgraph SGR["`**Kunde - Super-User**`"]
        E --> RP
        E --> RS
    end
    class SGR Light_green

    subgraph SGNST["`**Aareon RELion - Dev-Ops**`"]
        RP --> NSTP
        RS --> NSTS
    end
    class SGNST Aareon_blue

1. Registrieren Sie in Ihrem Entra ID-Tenant muss durch Ihren Entra-Admin eine zusätzliche Unternehmensanwendung je zugreifendem Programm registriert werden.

   1. Beispiel

      1. Eine Applikation für das RELion Consulting zur Einrichtungskontrolle
      2. Eine Applikation für das DMS
      3. Eine Applikation für das Vermietungsportal
      4. …

   2. Die entsprechende Anleitung zum Registrieren der Anwendung finden Sie hier: https://learn.microsoft.com/de-de/dynamics365/business-central/dev-itpro/administration/automation-apis-using-s2s-authentication#task-1-register-a-microsoft-entra-application-for-authentication-to-business-central

      1. In “Task 1” der Microsoft Dokumentation wird die Anwendung in Ihrem Entra ID Tenant registriert.
      2. Als API-Berechtigungen werden folgende Dynamics 365 Business Central Anwendungsberechtigungen benötigt
         1. API.ReadWrite.All
         2. Automation.ReadWrite.All
      3. Bitte teilen Sie uns Tenant ID, Client ID und Client Secret (zufallsgeneriertes Passwort, 40 Stellen) für die Applikation zur Einrichtungskontrolle durch das RELion Consulting über einen verschlüsselten Weg mit.

2. Jede unter Punkt 1 angelegt Applikation muss durch Ihren RELion-Super-User jeweils in beiden Instanzen (Produktiv und Sandbox) auf der Seite Microsoft Entra-Anwendungen separat angelegt, aktiviert und berechtigt werden.

   1. Folgende Berechtigungssätze sind für die Ersteinrichtung sinnvoll.
      1. RE URA
      2. SUPER (DATA)
      3. D365 AUTOMATION
   2. Eine Einschränkung bzw. feinere Einrichtung kann und soll im Laufe der Anbindung des jeweiligen zugreifenden Programms vorgenommen werden.
   3. Bitte teilen Sie uns die grundlegende ODataV4-URL der jeweiligen Instanz mit. Sie finden diese auf der Seite Webdienst und sieht zum Beispiel so aus: https://kunde.dynamicstocloud.com:1103/ST-123456

3. Von Seiten Aareon RELion wird die Installation der Universal REST API-Extension vorgenommen und die notwendigen Einstellungen an den beiden Instanzen (Produktiv und Sandbox) vorgenommen.

Konfiguration

Hier werden alle Einrichtungen mit deren Verhalten beschrieben. Die Obsolete Einrichtungen werden zwar in der Einrichtungsoberfläche noch angezeigt, haben aber keine Auswirkung mehr und werden hier auch nicht mehr näher beschrieben.

Es können pro Mandant verschiedene Einrichtungen vorgenommen werden. Wenn der von uns empfohlene Standard genutzt werden möchte, dann brauchen die Einstellungen nicht angepasst zu werden.

Empfehlung: In allen Mandanten die gleiche Einrichtung zu verwenden.

Code

Code – Feld, über den Wert dieses Feldes kann bei einem Request eine bestimmte Konfiguration gewählt werden. Die Konfiguration mit einem leeren Code Feld ist die Konfiguration, die als Standard zur Anwendung kommt, wenn keine Konfiguration bei einem Request enthalten ist.

Debug

Aktivert das Dugging. Folgende Einstellungen sind hier möglich:

• Off: kein Logging von eingehenden Aufrufen und Antworten
• Full: Logging von Aufrufe und Antworten
• Request: nur Logging der Aufrufe
• Response: nur Logging der Antworten

ACHTUNG: Nicht unnötg aktivieren, da hierdurch zum einem Daten und damit Speicher belegt wird und zum anderen dadurch die Performance eines Request deutlich vermindert wird.

Response Format

Es kann zwischen den Standard Formaten 0,1,2 und 9 gewählt werden. Es kann nur ein Responseformat für alle Datentypen gewählt werden. Die unterschiede zwischen den Format Typen kann der Microsoft Doku entnommen werden: https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-format-property

Wir empfehlen das Format 9 zu verwenden, da es Regions und Sprachunabhängig immer Eindeutig ist. Auch wenn Microsoft es als “XML” Format bezeichnet, wird selbstverständlich ein JSON zurück geliefert. Mit XML-Format ist gemeint, dass es so formatiert wird, dass es auch in einer XML-Datei genau so formatiert ist.
Beispiel: es gibt bei Zahlen keinen Tausender Trennzeichen und das “Komma” ist immer in allen Sprachen ein “Punkt”.

Enum Possible Values

Manchmal benötigt ein System, die Information, welche Options/Enum-Werte möglich sind bei einem Feld. Wird dies Einstellung auf true gesetzt, so wird das Response Object immer so erweitert, das zu einem Enum/Option auch die dazu gehörigen Möglichkeiten geliefert werden.

Empfehlung: Diese Einstellung nur in der Entwicklung auf true lassen. Eventuel ein Setup “DEV” anlegen, wo dieser Wert auch true ist. Ansonsten werden hier sonst unnötige Datenmengen im Trafik erzeugt werden.

Number of Entities To Read

Gibt die maximale Anzahl an Datensätzen an, die in einem request übertragen werden sollen. Dieser Wert kann im Request über den “top” Parameter übersteuert werden.

Field Name Replace From/To Char

Mit diesen beiden Werten kann ein allgemeines Suchen und Ersetzen im Feldnamen umgesetzt werden. Wenn also Als Beispiel die Leerzeichen durch ein Unterstrich im Feldnamen ersetzt ode rganz entfernt werden sollen.

1.2.3 - GUI-Tool

Übersicht

Dieses PowerShell-Skript stellt eine grafische Benutzeroberfläche (GUI) zur Verfügung, um das Erstellen von JSON-Anfragen für die Universal REST API zu erleichtern. Es ist darauf ausgelegt, Systemadministratoren und Entwicklern durch interaktive GUI-Elemente den Prozess des korrekten Aufbaus einer Anfrage zu führen.

GUI-Komponenten

Server-Informationen

• RELion Server: Geben Sie hier die Adresse des RELion-Servers ein. Dieser kann in apiConfig.json im Parameter server gespeichert werden.
• RELion API Service: Geben Sie den spezifischen Dienstnamen für den RELion-Server ein. Dieser kann in apiConfig.json im Parameter service gespeichert werden.
• Service Protokoll: Wählen Sie https, um eine sichere Datenübertragung zu gewährleisten. Dieser kann in apiConfig.json im Parameter protocol gespeichert werden.
• Zertifikat Prüfung: Aktivieren Sie dieses Kästchen, um die Zertifikatüberprüfung für zusätzliche Sicherheit zu aktivieren. Dieser kann in apiConfig.json im Parameter checkCert gespeichert werden.
• Mandant GUID: Geben Sie hier die GUID des Mandanten zur Identifizierung ein oder verwenden Sie den ⭮-Button um die vorhandenen Mandanten per WebService einzulesen und danach einen auszuwählen. Die GUID kann in apiConfig.json im Parameter companyGuid gespeichert werden.

Zugangsdaten

• Credentials: Wählen Sie über dieses Dropdown-Menü die Authentifizierungsmethode aus, die am RELion-Dienst eingerichtet ist.
  • Windows: Steht für RELion ONE nicht zur Verfügung.
  • User & Password
    • Benutzer: Geben Sie den Benutzernamen ein. Dieser kann in apiConfig.json im Parameter user gespeichert werden.
    • Passwort: Geben Sie das Passwort ein. Dieses kann nicht in apiConfig.json gespeichert werden.
  • OAuth 2.0
    • Tenant-Id: Die eindeutige Kennung Ihres Microsoft-Tenants muss hier eingegeben werden. Diese kann in apiConfig.json im Parameter tenant gespeichert werden.
    • Client-Id: Geben Sie die Anwendungsidentifikation ein. Diese kann in apiConfig.json im Parameter app gespeichert werden.
    • Client-Secret: Geben Sie das Anwendungsgeheimnis ein. Dieses kann nicht in apiConfig.json gespeichert werden.

URA-Kopfdaten

• RELion Tabelle: Wählen Sie die gewünschte Tabelle anhand ihres internen (englischen) Namens aus. Sie können in dem Feld auch schreiben und per Pfeil-runter-Taste die Tabelle auswählen.
• Operation: Wählen Sie die Art der Operation, wie zum Beispiel READ, aus diesem Dropdown-Menü. Weitere Informationen zu den einzelnen Optionen entnehmen Sie bitte der Dokumentation zur Universal REST API.

URA-Suboperationen

• Feld hinzufügen: Ein neues Feld zur Anfrage hinzufügen.
• Typ ergänzen: Zeigt den Datentyp und ggf. die Optionen zu den hinzugefügten Felder an.
• Operation hinzufügen: Eine neue Operation in die Anfrage einfügen.
• Antwortfeld hinzufügen: Ein neues Antwortfeld für die Anfrage hinzufügen.
• Body erstellen: Den JSON-Body für die Anfrage konstruieren.
• Senden: Die Anfrage an den Server senden.
• Alles Zurücksetzen: Alle Felder und Auswahlmöglichkeiten im Bereich der uRA-Suboperationen auf den Standardzustand zurücksetzen.

Bedienprozess

flowchart TD
    classDef Aareon_blue fill:#051163,stroke:#051163,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Bright_blue fill:#086DFB,stroke:#086DFB,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Sand        fill:#F7F3F0,stroke:#F7F3F0,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Stone       fill:#EBE3DC,stroke:#EBE3DC,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Coral       fill:#FF7F62,stroke:#FF7F62,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Peach       fill:#FFD8CA,stroke:#FFD8CA,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Green       fill:#50B214,stroke:#50B214,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Light_green fill:#B9E99C,stroke:#B9E99C,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Baby_blue   fill:#A4CBFF,stroke:#A4CBFF,color:#081326,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Burgundy    fill:#550000,stroke:#550000,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif
    classDef Dark_green  fill:#2F630E,stroke:#2F630E,color:#FFFFFF,font-family:Segoe UI, Arial, Helvetica,sans-serif

    %% linkStyle default color:#ffffff

    A["Skript (neu) starten"]:::Aareon_blue
    B["Server-Informationen erfassen"]:::Aareon_blue
    C["Zugangsdaten erfassen"]:::Aareon_blue
    D1["Mandanten einlesen und auswählen"]:::Aareon_blue
    D2["Mandanten-Guid erfassen"]:::Aareon_blue
    E["Tabelle und Operation auswählen"]:::Bright_blue
    F1["Benötigte Anzahl Felder hinzufügen"]:::Stone
    F2{"Alle Felder definiert?"}:::Stone
    F3["Feld auswählen"]:::Stone
    F4["Falls Filterfeld, entsprechend markieren"]:::Stone
    F5["Wert angeben"]:::Stone
    G1["Operation hinzufügen"]:::Stone
    G2["Operation 'DONE' auswählen"]:::Stone
    H["Reiter 'Antwortfelder' auswählen"]:::Sand
    I1["Benötigte Anzahl Antwortfelder hinzufügen"]:::Sand
    I2{"Alle Antwortfelder definiert?"}:::Sand
    I3["Antwortfeld auswählen"]:::Sand
    J["Reiter 'Body' auswählen"]:::Coral
    K["Body erstellen"]:::Coral
    L["Reiter 'Result' auswählen"]:::Peach
    M["Senden"]:::Peach

    A --> B
    B --> C
    C --> D1
    C --> D2
    D1 --> E
    D2 --> E
    E --> F1
    F1 --> F2
    F2 -->|"Nein"| F3
    F3 --> F4
    F4 --> F5
    F5 --> F2
    F2 -->|"Ja"| G1
    G1 --> G2
    G2 --> H
    H --> I1
    I1 --> I2
    I2 -->|"Nein"| I3
    I3 --> I2
    I2 -->|"Ja"| J
    J --> K
    K --> L
    L --> M

Versionsgeschichte und Änderungsprotokoll

v1.0.1.3 (Vorab-Version)

• Erhöhung der Parse-Tiefe in der JSON-Verarbeitung, um die möglichen Optionswerte zu unterstützen
• Umbau auf Auswahl der Authentifizierungsmethode per ComboBox
• Hinzufügen der Unterstützung von OAuth 2.0
• Added RENAME-operation

v1.0.1.0

• Umstellung auf vollständig dynamische Parameter bei Invoke-RestMethod. Dadurch auch abwärtskompatible Verwendung von -AllowUnencryptedAuthentication.
• Leeren der Ergebnisbox bei erfolgreichem Aufrufen des Mandanten- bzw. Feld-WebService
• Speicherung der per WebService erhaltenen Feld-Informationen. Dazu werden die im Tool ausgelieferten Informationen mit den neu erhaltenen überschrieben und in einer neuen Datei abgespeichert.
• Mandantennamen werden anstelle leerer Mandanten-Anzeigenamen verwendet.

v1.0.0.0

• Erstveröffentlichung mit vollständiger Funktionalität für das Erstellen von JSON-Anfragebodies über die GUI.

Hinweis

Dieses Dokument wird aktualisiert, sobald neue Funktionen hinzugefügt oder Änderungen am Skript vorgenommen werden.

1.2.4 - Beispiele

Einfache Beispiele

Lesen

Kreditor lesen

REQUEST

{
   "tableNo": "23",
   "operation": "READ",
   "runTrigger": true,
   "setupCode": "",
   "entitySet": [
      {
         "fieldNo": "1",
         "filter": true,
         "value": "*"
      },
      {
         "subOperation": "DONE",
         "responseFields": "1|2"
      }
   ]
}

RESPONSE (Auszug)

{
    "Data": [
        {
            "No.": "700001",
            "Name": "Hausmeisterei"
        },
        {
            "No.": "700002",
            "Name": "Tischlerei Markus Wratschko e.U."
        },
        {
            "No.": "700003",
            "Name": "Gemeinde St. Georgen am Kreischberg"
        },
        ...
    ]
}

Schreiben

Einkaufsrechnung schreiben

REQUEST

{
   "tableNo":  "38",
   "operation":  "INSERT",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "validate":  true,
         "value":  "2"
      },
      {
         "fieldNo":  "2",
         "validate":  true,
         "value":  "700001"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "2|3"
      }
   ]
}

RESPONSE

{
    "Data": [
        {
            "Buy-from Vendor No.": "700001",
            "No.": "10R20-00013"
        }
    ]
}

Aktualisieren

In diesem Beispiel wird das Update der in obigem Beispiel übermittelten Einkaufsrechnung dargestellt. Das kann zum Beispiel interessant sein, wenn die Rechnung erneut an RELion übermitteln werden soll.

Dazu werden zwei Arten von Felder übergeben: Filter-Felder (filter = true) und Schreib-Felder (validate = true/false).

Wichtig ist dabei, dass genügend Filter-Felder angegeben werden, um den zu aktualisierenden Datensatz eindeutig zu identifizieren. Hierzu empfiehlt sich die Angabe aller Primärschlüsselfelder.

REQUEST

{
   "tableNo":  "38",
   "operation":  "UPDATE",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "2"
      },
      {
         "fieldNo":  "3",
         "filter":  true,
         "value":  "10R20-00013"
      },
      {
         "fieldNo":  "99",
         "validate":  true,
         "value":  "2024-02-28"
      },
      {
         "fieldNo":  "24",
         "validate":  true,
         "value":  "2024-03-10"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "3|24|99"
      }
   ]
}

RESPONSE

{
    "Data": [
        {
            "No.": "10R20-00013",
            "Due Date": "2024-03-10",
            "Document Date": "2024-02-28"
        }
    ]
}

Umbenennen

Verteilungscode ändern

REQUEST

{
  "tableNo": "5052255",
  "operation": "RENAME",
  "runTrigger": true,
  "setupCode": "",
  "entitySet": [
    {
      "fieldNo": "1",
      "filter": true,
      "value": "2"
    },
    {
      "fieldNo": "2",
      "filter": true,
      "value": "140701"
    },
    {
      "fieldNo": "3",
      "filter": true,
      "value": "0-QM-NFL"
    },
    {
      "fieldNo": "1",
      "validate": true,
      "value": "2"
    },
    {
      "fieldNo": "2",
      "validate": true,
      "value": "140701"
    },
    {
      "fieldNo": "3",
      "validate": true,
      "value": "0-QM-NF"
    },
    {
      "subOperation": "DONE",
      "responseFields": ""
    }
  ]
}

RESPONSE

{
    "Data": [
        {
            "Owner / Tenant": "2",
            "Object No.": "140701",
            "Allocation code": "0-QM-NF",
            "Description": "m² Nutzfläche",
            "Description on accounting": "0",
            "Total factor": "532.92",
            "Absolute factor": "false",
            "Extrapolation": "0",
            "Sum lower units/objects": "0",
            "Automatically determined": "false",
            "Fixed date": "2021-01-19",
            "$systemId": "{712E0A5F-D86B-EB11-B843-005056958D1C}",
            "SystemCreatedAt": "",
            "SystemCreatedBy": "{00000000-0000-0000-0000-000000000000}",
            "SystemModifiedAt": "2024-09-27T09:17:21.748Z",
            "SystemModifiedBy": "{7682B4AA-F082-4DCA-802D-E36C1455D4C5}"
        }
    ]
}

Löschen

Einkaufsrechnung löschen

REQUEST

{
   "tableNo":  "38",
   "operation":  "DELETE",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "2"
      },
      {
         "fieldNo":  "3",
         "filter":  true,
         "value":  "10R20-00013"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "3"
      }
   ]
}

RESPONSE

{
    "Data": [
        {
            "No.": "10R20-00013",
            "Due Date": "2024-03-10",
            "Document Date": "2024-02-28"
        }
    ]
}

Letzte Zeile lesen

Kreditor lesen

REQUEST

{
   "tableNo": "23",
   "operation": "READLAST",
   "runTrigger": true,
   "setupCode": "",
   "entitySet": [
      {
         "fieldNo": "1",
         "filter": true,
         "value": "*"
      },
      {
         "subOperation": "DONE",
         "responseFields": "1|2"
      }
   ]
}

RESPONSE

{
    "Data": [
        {
            "No.": "WEG14581",
            "Name": "WEG St. Georgen ob Murau Bau 12"
        }
    ]
}

Fortgeschrittene Beispiele

Schreiben von Bemerkungszeilen

In diesem Beispiel werden zusätzliche Einkaufsrechnungszeilen angelegt, die nur Bemerkungszwecken dienen.

REQUEST

{
   "tableNo":  "39",
   "operation":  "INSERT",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "validate":  true,
         "value":  "2"
      },
      {
         "fieldNo":  "3",
         "validate":  true,
         "value":  "10R20-00013"
      },
      {
         "fieldNo":  "4",
         "validate":  true,
         "value":  "30000"
      },
      {
         "fieldNo":  "11",
         "validate":  true,
         "value":  "Bemerkungstext"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|3|4|11"
      }
   ]
}

RESPONSE

{
   "Data":  [
      {
         "Document Type":  "2",
         "Document No.":  "10R20-00013",
         "Line No.":  "30000",
         "Description":  "Bemerkungstext"
      }
   ]
}

Mehrere Sub-Operationen

Einkaufsrechnungskopf

In diesem Beispiel wird ein Einkaufsrechnungskopf (Purchase Header, 38) angelegt und direkt anschließend mit Beleg- und Fälligkeitsdatum aktualisiert. Durch die besondere Natur der BC-Standard-Programmierung ist dieser Zugang beim Einkaufsrechnungskopf notwendig.

REQUEST

{
   "tableNo":  "38",
   "operation":  "INSERT",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "validate":  true,
         "value":  "2"
      },
      {
         "fieldNo":  "2",
         "validate":  true,
         "value":  "700001"
      },
      {
         "subOperation":  "INSERT",
         "responseFields":  ""
      },
      {
         "fieldNo":  "99",
         "validate":  true,
         "value":  "2024-02-28"
      },
      {
         "fieldNo":  "24",
         "validate":  true,
         "value":  "2024-03-10"
      },
      {
         "subOperation":  "UPDATE_RESPONSE",
         "responseFields":  "3|24|99"
      }
   ]
}

RESPONSE

{
   "Data":  [
      {
         "No.":  "RG24-0015632",
         "Due Date":  "2024-03-10",
         "Document Date":  "2024-02-28"
      }
   ]
}

Einkaufsrechnungszeilen

In diesem Beispiel werden mehrere Einkaufsrechnungszeilen (Purchase Line, 39) angelegt. Durch die gemeinsame Übertragung werden entweder alle Datensätze angenommen oder bei einem Fehler gar keiner. Zu beachten ist, dass trotz INSERT_RESPONSE bei der ersten Suboperation nur die Antwort der letzten Suboperation zurückgegeben wird. Somit hat es keine Auswirkung, wenn statt INSERT_RESPONSE “nur” INSERT verwendet wird.

REQUEST

{
   "tableNo": "39",
   "operation": "INSERT",
   "runTrigger": true,
   "setupCode": "",
   "entitySet": [
      {
         "fieldNo": "1",
         "validate": true,
         "value": "2"
      },
      {
         "fieldNo": "3",
         "validate": true,
         "value": "RG24-0015632"
      },
      {
         "fieldNo": "4",
         "validate": true,
         "value": "10000"
      },
      {
         "fieldNo": "5052250",
         "validate": true,
         "value": "2"
      },
      {
         "fieldNo": "5052251",
         "validate": true,
         "value": "140701"
      },
      {
         "fieldNo": "5052254",
         "validate": true,
         "value": "4410207"
      },
      {
         "fieldNo": "15",
         "validate": true,
         "value": "1"
      },
      {
         "fieldNo": "22",
         "validate": true,
         "value": "100"
      },
      {
         "subOperation": "INSERT_RESPONSE",
         "responseFields": "1|3|4|5052250|5052251|5052254|15|22"
      },
      {
         "fieldNo": "1",
         "validate": true,
         "value": "2"
      },
      {
         "fieldNo": "3",
         "validate": true,
         "value": "RG24-0015632"
      },
      {
         "fieldNo": "4",
         "validate": true,
         "value": "20000"
      },
      {
         "fieldNo": "5052250",
         "validate": true,
         "value": "2"
      },
      {
         "fieldNo": "5052251",
         "validate": true,
         "value": "140701"
      },
      {
         "fieldNo": "5052254",
         "validate": true,
         "value": "4410215"
      },
      {
         "fieldNo": "15",
         "validate": true,
         "value": "1"
      },
      {
         "fieldNo": "22",
         "validate": true,
         "value": "400"
      },
      {
         "subOperation": "DONE",
         "responseFields": "1|3|4|5052250|5052251|5052254|15|22"
      }
   ]
}

RESPONSE

{
  "Data": [
    {
      "Document Type": "2",
      "Document No.": "RG24-0015632",
      "Line No.": "20000",
      "Quantity": "1",
      "Direct Unit Cost": "400",
      "RelC Owner/Tenant": "2",
      "RelC Object No.": "140701",
      "RelC Object Account No.": "4410215"
    }
  ]
}

Beschränkte Anzahl an Rückgabezeilen

Aus technischen Gründen wird die Anzahl an Datensätzen, die von der Universal Rest API zurückgegeben werden, limitiert. In Fällen, wo die benötigte Anzahl größer ist als das Limit sind somit folgende Eingriffe nötig und möglich.

Pagination

In allen Tabellen lässt sich über die Parameter top und skip ein seitenweises Lesen (Pagination) erreichen.

• top gibt dabei die Anzahl an (falls vorhanden) zurückzugebenden Datensätzen dar
• skip gibt an, wie viele Datensätze davor übersprungen werden sollen

D.h. in untenstehendem Beispiel werden zuerst 6 Datensätze übersprungen und dann die nächsten 3 zurückgegeben.

REQUEST

{
   "tableNo":  "17",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "top": "3",
   "skip": "6",
   "entitySet":  [
      {
         "subOperation":  "DONE",
         "responseFields":  "1|3|4"
      }
   ]
}

WebService-Response (Auszug)

{
    ...
    "skip": 6,
    "top": 3,
    "entitySet": [
        {
            ...
            "totalCount": 24447,
            "skippedRows": 6,
            "moreRows": true,
            "countOfReturnRows": 3,
            "ResponseJson2": ...
        }
    ]
}

WebService-Response sind folgende Parameter in diesem Zusammenhang interessant:

• totalCount gibt die Anzahl der insgesamt dem Filter entsprechenden Datensätze zurück. Dieser Wert ist von den Request-Parametern skip und top unabhängig.
• skippedRows gibt die tatsächlich übersprungene Anzahl an Datensätzen zurück und entspricht somit dem kleineren folgender Werte: skip, totalCount
• countOfReturnRows gibt die tatsächliche Anzahl an zurückgegebenen Datensätzen an und bewegt sich somit zwischen 0 und top.
• moreRows ermöglicht eine einfache Schleifenbedingung für die Abfragen und gibt die Werte true oder false zurück.

RESPONSE (Auszug)

{
    "Data": [
        {
            "Entry No.": "7",
            "G/L Account No.": "80600501",
            "Posting Date": "2019-01-01"
        },
        {
            "Entry No.": "8",
            "G/L Account No.": "190016",
            "Posting Date": "2019-01-01"
        },
        {
            "Entry No.": "9",
            "G/L Account No.": "1420",
            "Posting Date": "2019-01-01"
        }
    ]
}

Wiederholtes Lesen mit verändertem Filter auf dem Primärschlüssel-Feld

Welches Feld bzw. welche Felder je Tabelle den Primärschlüssel bilden, können Sie in der Seitenüberprüfung (Strg+Alt+F1) sehen.

In der Antwort der Universal REST API werden auf der selben Ebene wie das ResponseJson2 noch die Felder numberOfRows und moreRows zurückgegeben.

• numberOfRows gibt die Anzahl an Datensätzen an, die insgesamt gefunden wurden. In untenstehendem Beispiel wird sie also bei jedem Aufruf kleiner.
• moreRows gibt einen boolschen Wert zurück, der anzeigt, ob noch mehr Datensätze vorhanden sind, die aufgrund des Limits nicht übertragen wurden.

Ein Beispiel für das Lesen der Sachkonten, würde wie folgt aussehen:

1. REQUEST

{
   "tableNo":  "15",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  ">0"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|2|4"
      }
   ]
}

1. RESPONSE (Auszug)

{
   "Data": [
      {
      "No.": "000-",
      "Name": "Anlagevermögen",
      "Account Type": "3"
      },

      ...

      {
      "No.": "08100",
      "Name": "Ausleihungen an verbundene Unternehmen",
      "Account Type": "0"
      }
   ]
}

Nun muss auf Basis des zuletzt zurückgegebenen Primärschlüssels der nächste Request aufgebaut werden.

2. REQUEST

{
   "tableNo":  "15",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  ">08100"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|2|4"
      }
   ]
}

2. RESPONSE (Auszug)

{
   "Data": [
      {
      "No.": "08130",
      "Name": "Ausleihungen an verbundene UN, PersG",
      "Account Type": "0"
      },

      ...

      {
      "No.": "12960",
      "Name": "WB Forderg.gg.UN m.Beteiligg.verh. b.1J",
      "Account Type": "0"
      }
   ]
}

Das Ganze muss wiederholt werden, bis das Feld moreRows den Wert false zurückgibt.

3. REQUEST

{
   "tableNo":  "15",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  ">12960"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|2|4"
      }
   ]
}

usw.

Maximalanzahl der zu übertragenden Datensätze in der uRA-Einrichtung erhöhen

Dies stellt eine grundsätzliche Möglichkeit dar. Allerdings ist zu beachten, dass bei einer zu großen Anzahl an Datensätzen, die Anfrage an die Universal Rest API in ein Timeout laufen wird. Daher stellt dies die schlechteste Möglichkeit dar und ist hier nur mehr der Vollständigkeit halber erwähnt.

Filterung nach Änderungsdatum

Eine Abfrage aller RELion-Objekte mit Änderungen seit 01.03.2023 würde wie folgt aussehen.

Zu beachten ist, dass die Datumsformatierung standardmäßig auf XML-Format eingestellt ist. Diese ist im Sinne einer Systemkompatibilität klar zu bevorzugen, kann aber in der Universal Rest API Settings je Mandant und Einrichtungscode geändert werden.

REQUEST

{
   "tableNo":  "5052250",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "2000000003",
         "filter":  true,
         "value":  ">2023-03-01T00:00:00Z"
      },
      {
         "subOperation":  "READ",
         "responseFields":  "1|2|2000000003"
      }
   ]
}

RESPONSE

{
    "Data": [
        {
            "Owner / Tenant": "1",
            "No.": "416502",
            "SystemModifiedAt": "2023-10-09T14:20:40.247Z"
        },
        {
            "Owner / Tenant": "2",
            "No.": "416501",
            "SystemModifiedAt": "2023-10-09T14:20:41.427Z"
        }
    ]
}

RecordLinks

Links und Notizen werden in der Tabelle 2000000068 abgelegt.

Für die folgenden Beispiele werden verwendet:

Schreiben von Links

Das folgende Beispiel zeigt das Hinzufügen eines Links zu einem Einkaufsrechnungskopf. Zu beachten ist dabei vor allem die korrekte Angabe im Feld Record ID. Diese besteht aus dem Tabellennamen und allen Primärschlüsselfeldern des Datensatzes, dem der Link hinzugefügt werden soll.

REQUEST

{
   "tableNo": "2000000068",
   "operation": "INSERT",
   "runTrigger": true,
   "setupCode": "",
   "entitySet": [
      {
         "fieldNo": "2",
         "validate": true,
         "value": "Purchase Header: Invoice,ER1802820"
      },
      {
         "fieldNo": "3",
         "validate": true,
         "value": "http://www.aareon.com"
      },
      {
         "fieldNo": "7",
         "validate": true,
         "value": "URL"
      },
      {
         "fieldNo":  "10",
         "validate":  true,
         "value":  "2024-02-29 11:00:00"
      },
      {
         "fieldNo":  "11",
         "validate":  true,
         "value":  "AAREON\\HIEDEN"
      },
      {
         "fieldNo": "12",
         "validate": true,
         "value": "10_Mietverwaltung"
      },
      {
         "subOperation": "DONE"
      }
   ]
}

RESPONSE

{
   "Data":  [
      {
         "Link ID":  "21782",
         "Record ID":  "Purchase Header: 2,ER1802820",
         "URL1":  "http://www.aareon.com",
         "Description":  "URL",
         "Type":  "0",
         "Note":  " ",
         "Created":  "29.02.24 11:00",
         "User ID":  "AAREON\\HIEDEN",
         "Company":  "10_Mietverwaltung",
         "Notify":  "0",
         "To User ID":  "",
         "$systemId":  "01D1865D-C7D7-EE11-AD31-00505699FC69",
         "SystemCreatedAt":  "29.02.24 11:00",
         "SystemCreatedBy":  "7FEAA26B-6F07-4EF6-9BDA-6537D587E5C3",
         "SystemModifiedAt":  "29.02.24 11:00",
         "SystemModifiedBy":  "7FEAA26B-6F07-4EF6-9BDA-6537D587E5C3"
      }
   ]
}

Schreiben von Notizen

In diesem Beispiel wird eine Notiz der selben Einkaufsrechnung hinzugefügt.

REQUEST

{
   "tableNo": "2000000068",
   "operation": "INSERT",
   "runTrigger": true,
   "setupCode": "",
   "entitySet": [
      {
         "fieldNo": "2",
         "validate": true,
         "value": "Purchase Header: Invoice,ER1802820"
      },
      {
         "fieldNo": "8",
         "validate": true,
         "value": "1"
      },
      {
         "fieldNo": "9",
         "validate": true,
         "value": "MURpZXNlIE5vdGl6IHd1cmRlIHBlciB1bml2ZXJzYWwgUmVzdCBBUEkgZXJ6ZXVndC4="
      },
      {
         "fieldNo":  "10",
         "validate":  true,
         "value":  "2024-02-29 11:00:00"
      },
      {
         "fieldNo":  "11",
         "validate":  true,
         "value":  "AAREON\\HIEDEN"
      },
      {
         "fieldNo": "12",
         "validate": true,
         "value": "10_Mietverwaltung"
      },
      {
         "subOperation": "DONE",
         "responseFields": "1|2|3|7|8|9"
      }
   ]
}

RESPONSE

{
    "Data": [
        {
            "Link ID": "9288",
            "Record ID": "Purchase Header: 2,ER1802820",
            "URL1": "",
            "Description": "",
            "Type": "1",
            "Note": "MURpZXNlIE5vdGl6IHd1cmRlIHBlciB1bml2ZXJzYWwgUmVzdCBBUEkgZXJ6ZXVndC4="
        }
    ]
}

Änderung von RecordLinks

In diesem Beispiel wird das Ziel des RecordLinks geändert. Hierzu muss nicht mehr die Record ID angegeben werden, sondern es reicht, die einfacher zu verwendende Link ID zu übermitteln, die wir beim Hinzufügen erhalten haben.

REQUEST

{
   "tableNo":  "2000000068",
   "operation":  "UPDATE",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "21782"
      },
      {
         "fieldNo":  "3",
         "validate":  true,
         "value":  "http://www.relion.de"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|2|3"
      }
   ]
}

RESPONSE

{
   "Data":  [
      {
         "Link ID":  "21782",
         "Record ID":  "Purchase Header: 2,ER1802820",
         "URL1":  "http://www.relion.de"
      }
   ]
}

Lesen von RecordLinks

In diesem Beispiel werden die RecordLinks (Links & Notizen) einer Einkaufsrechnung gelesen.

REQUEST

{
   "tableNo": "2000000068",
   "operation": "READ",
   "runTrigger": true,
   "setupCode": "",
   "entitySet": [
      {
         "fieldNo": "2",
         "filter": true,
         "value": "Purchase Header: Invoice,ER1802820"
      },
      {
         "subOperation": "DONE",
         "responseFields": "1|2|3|7|8|9"
      }
   ]
}

RESPONSE

{
   "Data":  [
      {
         "Link ID":  "21782",
         "Record ID":  "Purchase Header: 2,ER1802820",
         "URL1":  "http://www.relion.de",
         "Description":  "URL",
         "Type": "0",
         "Note": ""
      }
   ]
}

Dimensionen

Lesen von Dimensionswerten

In diesem Beispiel werden die Dimensionswerte auf den Sachposten ausgelesen.

REQUEST

{
   "tableNo":  "17",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "24",
         "filter":  true,
         "value":  "WEG SCHW."
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|3|17|23|24|481|482|483|484|485|486"
      }
   ]
}

RESPONSE (Auszug)

{
  "Data": [
      {
         "Entry No.": "2559",
         "G/L Account No.": "608076",
         "Amount": "-50",
         "Global Dimension 1 Code": "OBJ001",
         "Global Dimension 2 Code": "WEG SCHW.",
         "Shortcut Dimension 3 Code": "",
         "Shortcut Dimension 4 Code": "",
         "Shortcut Dimension 5 Code": "",
         "Shortcut Dimension 6 Code": "",
         "Shortcut Dimension 7 Code": "",
         "Shortcut Dimension 8 Code": ""
      },
      {
         "Entry No.": "2560",
         "G/L Account No.": "200010",
         "Amount": "50",
         "Global Dimension 1 Code": "OBJ001",
         "Global Dimension 2 Code": "WEG SCHW.",
         "Shortcut Dimension 3 Code": "",
         "Shortcut Dimension 4 Code": "",
         "Shortcut Dimension 5 Code": "",
         "Shortcut Dimension 6 Code": "",
         "Shortcut Dimension 7 Code": "",
         "Shortcut Dimension 8 Code": ""
      },
      ...
   ]
}

Auslesen möglicher Dimensionswerte

In diesem Beispiel werden die möglichen Dimensionswerte für die Dimension ABTEILUNG ausgelesen.

REQUEST

{
   "tableNo":  "349",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "ABTEILUNG"
      },
      {
         "fieldNo":  "4",
         "filter":  true,
         "value":  "0"
      },
      {
         "fieldNo":  "6",
         "filter":  true,
         "value":  "0"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "1|2|3"
      }
   ]
}

RESPONSE (Auszug)

{
   "Data":  [
      {
         "Dimension Code":  "ABTEILUNG",
         "Code":  "100",
         "Name":  "Bau allgemein"
      },
      {
         "Dimension Code":  "ABTEILUNG",
         "Code":  "110",
         "Name":  "Planung"
      },
      {
         "Dimension Code":  "ABTEILUNG",
         "Code":  "120",
         "Name":  "Bauleitung"
      },

      ...
   ]
}

Dimensionswert schreiben

In diesem Beispiel wird der Dimensionswert für die Dimension ABTEILUNG in einer Einkaufsrechnungszeile aktualisiert.

REQUEST

{
   "tableNo":  "39",
   "operation":  "UPDATE",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "2"
      },
      {
         "fieldNo":  "3",
         "filter":  true,
         "value":  "R22-05048"
      },
      {
         "fieldNo":  "4",
         "filter":  true,
         "value":  "10000"
      },
      {
         "fieldNo":  "480",
         "dimensionSetId":  true,
         "dimensionSetIdMutation": "1"
      },
      {
         "dimension":  true,
         "dimensionCode":  "ABTEILUNG",
         "value":  "100"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "3|480"
      }
   ]
}

RESPONSE

{
   "Data":  [
      {
         "Document No.":  "R22-05048",
         "Dimension Set ID":  "22481"
      }
   ]
}

Tabellen- und Feldinformationen

Über die Universal Rest API ist es auch möglich, die Tabellen und Feldinformationen aus den System-Tabellen AllObjWithCaption und Field auszulesen.

Tabelleninformationen

Die System-Tabelle AllObjWithCaption beinhaltet Informationen zu allen in der Business Central-Instanz vorhandenen Programmobjekte (Tabellen, Seiten, Berichte, …). Für die Arbeit mit der Universal Rest API sind für allem die Informationen zu den vorhandenen Tabellen relevant.

REQUEST

{
   "tableNo":  "2000000058",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "1"
      },
      {
         "subOperation":  "DONE",
         "responseFields":  "3|4"
      }
   ]
}

RESPONSE (Auszug)

{
   "Data": [
      {
         "Object ID":  "3",
         "Object Name":  "Payment Terms"
      },
      {
         "Object ID":  "4",
         "Object Name":  "Currency"
      },
      {
         "Object ID":  "5",
         "Object Name":  "Finance Charge Terms"
      },
      ...
   ]
}

Feldinformationen

Die System-Tabelle Field beinhaltet Informationen zu allen in der Business Central-Instanz vorhandenen Tabellenfeldern.

REQUEST

{
   "tableNo":  "2000000041",
   "operation":  "READ",
   "runTrigger":  true,
   "setupCode":  "",
   "entitySet":  [
      {
         "fieldNo":  "1",
         "filter":  true,
         "value":  "5052250"
      },
      {
         "fieldNo":  "8",
         "filter":  true,
         "value":  "1"
      },
      {
         "subOperation": "DONE",
         "responseFields": "1|2|3|4|5|6|7|9|20|23|24|28"
      }
   ]
}

RESPONSE (Auszug)

{
   "Data":  [
      {
         "TableNo":  "5052250",
         "No.":  "1",
         "TableName":  "RelC Object",
         "FieldName":  "Owner / Tenant",
         "Type":  "35583",
         "Len":  "4",
         "Class":  "0",
         "Type Name":  "Option",
         "Field Caption":  "Owner / Tenant",
         "SQLDataType":  "0",
         "OptionString":  "None,Owner,Tenant",
         "IsPartOfPrimaryKey":  "true"
      },
      {
         "TableNo":  "5052250",
         "No.":  "2",
         "TableName":  "RelC Object",
         "FieldName":  "No.",
         "Type":  "31489",
         "Len":  "20",
         "Class":  "0",
         "Type Name":  "Code20",
         "Field Caption":  "No.",
         "SQLDataType":  "0",
         "OptionString":  "",
         "IsPartOfPrimaryKey":  "true"
      },
      ...
   ]
}

1.2.5 -

2 - Rechnungsmanager

Einführung

Der RELion Rechnungsmanager (kurz: RRM) ist ein Modul, welches automatisiert Ihre Rechnungen und andere Dokumente erfasst und verarbeitet. Es basiert auf dem Produkt Document Capture von der Continia Software GmbH. Document Capture wurde ergänzt, um z. B. Objektnummern und Objektkonten in den Registrierungsprozess einzufügen.

Eingehende Rechnungen und Dokumente können direkt als Scan oder als vorhandene PDF-Datei, mittels OCR-Technologie in RELion importiert werden. Ebenso können mit dem Zusatzmodul importierte XML-Rechnungen (X-Rechnungen) bearbeitet werden. Der Rechnungsmanager verwendet vordefinierte Dokumentenvorlagen, um die Daten den richtigen Feldern zuzuordnen. Diese Vorlagen können Sie jederzeit ändern, anpassen sowie neue Vorlagen erstellen. Mit dem Rechnungsmanager erhalten Sie einen Überblick über alle Rechnungen, die aktuell zur Genehmigung anstehen. Außerdem wird der Bestätigungsprozess angezeigt.

Wir konzentrieren uns zu 100 % auf Microsoft Dynamics 365 Business Central und darauf, was Microsoft-Kunden bei einer automatisierten Dokumentenverarbeitung und -Genehmigungslösung benötigen. Dass der RELion Rechnungsmanager innerhalb des Dynamics 365 Business Central-Systems aufgebaut ist, bedeutet, dass man eine gut bekannte Anwenderschnittstelle und -technologie benutzt. Vertrautes Arbeiten in einer allseits bekannten und gewohnten Benutzeroberfläche, die Ihnen sofort vertraut vorkommt.

Informationen zu Continia Document Capture erhalten Sie auch auf dem Lernportal von Continia.  

Einrichtung

Um mit dem Rechnungsmanager arbeiten zu können, müssen Sie zuerst die umfangreiche Continia Document Capture Einrichtung vornehmen. Eine korrekte Einrichtung des Services ist Voraussetzung für den korrekten Ablauf des Prozesses. Bitte entnehmen Sie diese Informationen direkt aus der Herstellerinformation. Eine eingehende Beratung für den Einsatz des Produktes wird empfohlen. In dieser Anwenderdokumentation wird speziell auf die RELion Erweiterungen im Rechnungsmanager eingegangen.

Standardkonfiguration von Document Capture

Document Capture beinhaltet einen Konfigurationsassistenten, mit dem die wichtigsten Punkte komfortabel eingerichtet werden können. Starten Sie den Einrichtungsassistenten über Document Capture Konfigurationsassistent oder über die Document Capture Einrichtung.

Wählen Sie die Aktion Import Konfiguration und importieren die Online-Konfiguration für Deutschland (Germany) und klicken auf Nächster.

Alternativ können Sie auch die Datei DE Setup.xml aus dem Ordner des Produktverzeichnisses auswählen.

Der Konfigurationsassistent führt Sie jetzt durch das Setup von Document Capture. Es werden alle Inhalte der Setup Datei angezeigt. Normalerweise sind alle Inhalte notwendig, jedoch können Sie einzelne Inhalte aktivieren bzw. deaktivieren. Alle Einstellungen können jederzeit nachträglich importiert werden.

Klicken Sie weiter, bis Sie nach den Client Credentials gefragt werden. Tragen Sie die Client Credentials direkt ein oder wählen sie es aus der Liste aus. Diese werden genutzt, um Ihren Mandanten bei Continia zu aktivieren sowie für die Cloud OCR, falls diese in der Lizenz vorhanden ist. Das Continia Web Approval Portal (gehostet bei Continia) nutzt ebenfalls die Client Credentials, um die jeweiligen Mandanten zu aktivieren. Diese Client Credentials werden Ihnen nach Bestellung von Document Capture durch Continia zur Verfügung gestellt.

Klicken Sie auf den Button Nächster und der Assistent informiert Sie, dass die Add-lns heruntergeladen werden. Im Anschluss erhalten Sie eine Bestätigungsmitteilung, dass die Verbindung erfolgreich ist und die Client Credentials gültig sind. Geben Sie nun einen Mandantencode ein und setzen den Haken bei Benutze Cloud OCR.

Sie erhalten eine Mitteilung über die erfolgreiche Aktivierung und dass die Konfigurationsdateien exportiert wurden. Falls Sie das Web-Approval lizensiert haben, wählen Sie in der nächsten Konfiguration Web Genehmigungen aktivieren sowie Benutzen Sie das Continia Online Web Portal. Überprüfen Sie den Domänennamen.

Die Felder Windows Web-Service URL und Datenbank Web-Service URL werden automatisch mit den Vorschlagswerten, basierend auf der aktiven NAV Service Tier Verbindung, gefüllt. Bitte überprüfen Sie, ob die vorgeschlagene Service-URL diejenige ist, die verwendet werden soll.

Bei der Verwendung der Cloud-Genehmigung (Continia Online Web Approval Portal) müssen Sie die URLs so einrichten, dass sie auf eine externe Adresse verweisen. Für die Einrichtung wenden Sie sich an Ihren System Administrator.

Folgende Felder sind für das Web Approval notwendig:

Klicken Sie auf Nächster und beenden anschließend den Konfigurationsassistenten.

Belegkategorie

Dokumente können Sie mit Belegkategorien gruppieren. Beispielsweise durch die Registrierung von Einkaufsrechnungen in einer Gruppe und von Auftragsbelegen in einer anderen Gruppe. Belegkategorien enthalten Vorlagen, die Feldwerte beim Erkennen und Registrieren von Dokumenten wie Rechnungsnummer, Fälligkeitsdatum und Betrag für die Einkaufsrechnungsbelege und Absender, Eingangsdatum und Auftragsnummer für Auftragsdokumente angeben.

Die Standardkonfiguration von Document Capture enthält mehrere Belegkategorien, wie z. B. EINKAUF für Einkaufsrechnungsbelege und KONTAKT für kontaktbezogene Dokumente, die als Aktivitätenprotokollposten gespeichert werden.

Es gibt zwei Arten von Belegkategorien:

• OCR-Kategorie
• Drag & Drop-Kategorie

Sie können einen Dokumenttyp entweder als OCR-Kategorie oder Drag & Drop-Kategorie konfigurieren. Eine Belegkategorie mit aktivierter OCR wird verwendet, um den Inhalt des importierten Dokuments wie Rechnungsnummer, Preise oder Projektnummer zu erkennen. Die Drag & Drop-Kategorie hat keine OCR-Verarbeitung aktiviert. Diese Art von Kategorien ermöglicht es Ihnen, Dokumente zu jeder Seite und jeder Tabelle in Business Central hinzuzufügen. Sie können sogar eine Drag & Drop-Kategorie einer bestimmten Tabelle zuweisen.  

OCR Erkennung

In der Belegkategorie EINKAUF ist die Konfiguration für die OCR Erkennung zu hinterlegen.

Wichtig

Nachdem die Konfiguration einer OCR-Belegkategorie abgeschlossen ist, bzw. geändert wird, müssen Sie die OCR-Konfigurationsdateien exportieren. Auf jeden Fall ist dies erstmalig bei Installation durchzuführen.

Arbeiten Sie mit Barcodeerkennung, achten Sie bitte darauf, dass der Schlüssel des Barcodes korrekt (Groß-Kleinschreibung) in das Feld Barcode Text eingetragen wurde.

Wichtig

Nachdem die Konfiguration einer OCR-Belegkategorie abgeschlossen ist, bzw. geändert wird, müssen Sie die Funktion OCR-Konfigurationsdateien exportieren ausführen. Auf jeden Fall ist dies erstmalig bei Installation durchzuführen. Dafür geben Sie in die Suche OCR Konfigurationsdateien exportieren ein.

Kreditorenerkennung

Damit die Belege im Mandanten automatisch einem Kreditor zugeordnet werden, ist eine Einrichtung in der Belegkategorie EINKAUF vorzunehmen. Hierfür steht eine weitere Vorlage, die EINKAUF-ID Vorlage zur Verfügung. Zur Bearbeitung öffnen Sie die Belegkategorie EINKAUF und führen die Aktion Identifikationsfelder aus.

Folgendes Fenster wird geöffnet:

In diesem Beispiel hat die USt-IDNr. Die höchste Einstufung, danach wird somit zuallererst gesucht. Die Suche nach USt-IDNr können Sie noch weiter spezifizieren, indem Sie die Vorlage direkt bearbeiten. Führen Sie folgende Schritte durch:

Arbeiten mit mehreren Mandanten

Richten Sie Mandanten Suchtexte ein, wenn die Belegverarbeitung in mehreren Mandanten stattfindet. Diese Tabelle ist global. Hier geben Sie den Mandantencode ein und als Suchbegriff ist der Begriff einzutragen, der auf dem Layout der Rechnung steht.

Werden Belege in einen anderen Mandanten verschoben, führen Sie die die Funktion Felder erkennen manuell aus. Dies kann über eine Aufgabenwarteschlange automatisiert werden. Dazu verwenden Sie den Report 6085580 CDC Batch Register Documents.

RELion Konfiguration

Belegkategorie EINKAUF

Die Codeunit 5359130 RELRRM CDC Purch. Doc.-Reopen ist in die Belegkategorie EINKAUF einzutragen. Diese Codeunit enthält die RRM-Funktionalität Bemerkungen anzeigen bei Ablehnung des Beleges im Genehmigungsablauf. (siehe Ablehnen einer Rechnung)

RELion Mastervorlage

Für RELion gibt es eine eigene Mastervorlage, die importiert werden muss. Importieren Sie die Mastervorlage unbedingt vor dem ersten Belegtraining. Sie erkennen die fehlende RELion Mastervorlage daran, dass Sie beim Belegtraining keine RELion Felder wie Objektnummer zur Verfügung haben. Gehen Sie beim Import der Vorlage wie folgt vor: Der Konfigurationsassistent (Unterstütztes Setup für Document Capture) ist zu starten. Der Ablageort der RELion -Mastervorlage muss bekannt sein.

Wählen Sie im nächsten Schritt unter Belegkategorie Einkauf nur die Vorlage RELion aus.

Wichtig

Die Mastervorlage ist gezielt auf die RELion Funktionalitäten hin abgestimmt. Änderungen an der Mastervorlage können dazu führen, dass der Prozess nicht mehr wie gewünscht durchgeführt werden kann. Somit empfehlen wir, Änderungen nur im Ausnahmefall und mit entsprechenden Rechnungsmanager- und Document-Capture-Kenntnissen durchzuführen.

Informationen zur RELion Mastervorlage

Folgende CodeUnits sind für den Rechnungsmanager hinterlegt:

Arbeiten Sie mit Objektkonten, die unterschiedlich zu den Sachkonten sind, dann muss in der Vorlage im Feld Objektkonto folgende Codeunit im Feld Überprüfen hinterlegt werden: 5359131 RE CDC [Align GLAcc With ObjAcc].

Im Feld Sachkonto darf keine Formel hinterlegt werden, die das Objektkonto einträgt.

RELion Felder

RELion Abrechnungskreis

Damit der Abrechnungskreis beim Registrieren mit in die Einkaufsrechnung übertragen wird, muss in der RELion Master und in den entsprechenden Kreditorenvorlagen das Feld Abrechnung mit dem Code ACCOUNTINGGROUP angelegt werden.

Dieses Feld kann entweder als Kopffeld oder als Zeilenfeld in der Vorlage definiert werden. Ist es als Kopffeld hinterlegt, gilt der Abrechnungskreis für alle Zeilen. Wird es als Zeilenfeld hinterlegt, wird für jede Zeilen ein eigener Abrechnungskreis definiert.

RELion Funktion Automatische Weiterbelastung

Wird mit der Funktionalität automatischen Weiterbelastung (RELion Modul) gearbeitet, ist es notwendig in der Kreditorenvorlage ein Vorlagenfeld Aufteilungsregel (OBJCOSTALLOCRULE) hinzuzufügen Tabellen ID 5163991.

Zusätzlich ist in dem neuen Feld noch folgendes zu hinterlegen:

Ist das Feld vor der Registrierung des Beleges befüllt so wird dieser Wert beim Registrieren der Rechnung in die Einkaufszeile übernommen.

Ergebnis:

Die Felder Objektkosten Aufteilungsregel ID und Objektkosten Aufteilungssatz ID sind belegt. Die automatische Weiterbelastung ist in der EK-Zeile somit initial vorbelegt. Ist am Objektkonto eine Aufteilungsregel hinterlegt, ist es nicht notwendig das Feldes Objektkosten Aufteilungsregel ID in der Kreditorenvorlage zu definieren. Die Funktion arbeitet beim Registrieren des Beleges wie erwartet.

Dimensionen (z. B. 35A)

Das Dimensionsfeld § 35 wird in die EK-Zeile übernommen, wenn es als Kopffeld definiert wurde und entsprechend befüllt ist.

Zahlungsverkehr

Die RELion Standard-Vorlage wurde um Felder aus dem Zahlungsverkehr ergänzt. Standardmäßig werden diese Felder mit den Daten aus dem Kreditorenstamm vorbelegt. Diese können Sie individuell ändern. Anschließend werden die Daten in den Belegkopf der Einkaufsrechnung automatisch übernommen.

Eigentümer/Mieter Kennzeichen

Wir empfehlen den Datentyp Nummer zu verwenden (1 = Eigentümer; 2= Mieter).

Auflistung aller unterstützter RELion Felder

Folgende Felder werden von RELion unterstützt. Die Übersicht ist aufgeteilt in Kopf und Zeilenfelder. Es wird jeweils unterschieden, ob die Felder bei Beauftragung holen automatisch von der Beauftragung in die Einkaufsrechnung übernommen werden oder ob die Felder in der Kreditorenvorlage zusätzlich in der Spalte Felder Registrieren hinzugefügt werden. In diesem Fall achten Sie unbedingt auf die korrekte Schreibweis des Feldes in der Kreditorenvorlage. Dies muss dem Eintrag im Excel File in der Spalte Code-Feld in RRM entsprechen.

Kopffelder:

Übertrage Master in Vorlage

Diese Funktion dient zur Übertragung von speziellen Einrichtungen aus der RELion Master Vorlage in alle Kreditorenvorlagen. Die Funktion ist aus der RELion Master Vorlage über die Funktion Vorlagenfelder übertragen auszuwählen. Der Bericht ist für Bestandskunden entwickelt worden, die die neuen Funktionalitäten rund um Belegzeilenerkennung und Beauftragungszeilen holen nutzen möchten. Der Bericht deckt nur diesen Use Case ab. D. h., in der Umkehrung, nicht alle möglichen Definitionen innerhalb der Kreditorenvorlagen werden übertragen.

Durch Aktivierung der Optionen Setze Beauftragung automatisch, Setze Beauftragungszeilen holen und Setze Rolle Sachbearbeiter wird der entsprechende Wert aus der Mastervorlage in alle Kreditorenvorlagen übertragen. Ein automatisches Anlegen der Rolle Sachbearbeiter wird nicht durchgeführt. Diese Einrichtungen müssen bereits vorhanden sein. Ist das Feld Setze Rolle Sachbearbeiter leer, dann wird auch leer in die Kreditorenvorlagen eingetragen.

Zusätzlich werden die definierten Zeilenübersetzungen (Dokumentübersetzungen - Tabelle CDC Data Translation 6085584) aus Nr. in die Kreditorenvorlagen kopiert, wenn die Option Übersetzungen übernehmen gesetzt ist.

Eine Filterung auf einzelne Kreditorenvorlagen oder andere Filterwerte wird nicht unterstützt. Es werden immer ALLE Vorlagen geändert.

RE Bankkonto für Zahlung

Bei der Auswahl über die Standardtabelle Bankkonto stehen für den Benutzer nicht alle Informationen zum Bankkonto zur Verfügung. Oft weiß der Benutzer nicht, zu welchem Objekt das Bankkonto gehört, ob es gültig ist und ob es die Bank für den Zahlungsausgang ist. Diese Informationen stehen in der Tabelle RE Objektbank zur Verfügung. Damit die Auswahl über die RE Objektbank richtig funktioniert ist bei der Einrichtung folgendes zu beachten:

Die Spalte Code muss identisch mit der Spalte Bankkonto sein.

Damit das Registrieren und die ausgewählte Bankverbindung korrekt funktioniert, gibt es zwei Fälle, die unterschieden werden.

1. Spalten sind identisch

Nur wenn beide Spalten identisch sind, sollte die folgende Einrichtung durchgeführt werden:

Als Herkunftstabelle ist die RE Objektbank und als Herkunftsfeld das Feld Code einzutragen. Die Filter für das Feld Anzahl von Herkunftstabellenfiltern wird folgend gesetzt:

Die Felder in der Spalte Filter können aus einer Übersicht ausgewählt werden. Damit wird die Ansicht der Objektbanken auf das aktuelle Objekt und das Bankkonto für den Zahlungsausgang gefiltert. Da nur bei einem Konto der Haken gesetzt sein kann, steht immer nur ein Konto zur Auswahl, welches ggf. automatisch beim Einscannen eingetragen wird.

2. Spalten sind nicht identisch

Nur wenn beide Spalten nicht identisch sind, sollte die folgende Einrichtung durchgeführt werden:

Genehmigungsworkflow

Um den Document Capture Genehmigungsworkflow zu nutzen, ist in der Instandhaltung Einrichtung die NAVISION-Standard Beleggenehmigung auszuwählen:

Für die Document Capture Genehmigungseinrichtung öffnen Sie die Document Capture Einrichtung. Öffnen Sie die Funktion Einkaufsgenehmigung.

Aktivieren Sie im Inforegister Allgemein das Feld Genehmigung von Rechnungen aktivieren. Dadurch werden im Hintergrund die entsprechenden Workflows erzeugt und aktiviert.

Alternativ können Sie die Workflows manuell erzeugen, gehen Sie dazu wie folgt vor:

1. Öffnen Sie die Liste Workflows.
2. Führen Sie über Aktionen die Funktion Neuer Workflow aus Vorlage aus.
3. Erstellen Sie den Rechnungsmanager Genehmigungsworkflow Einkaufsrechnung und bestätigen mit OK.

Prüfen Sie die Eingaben in den entsprechenden Feldern.

Im Inforegister RELion besteht die Möglichkeit EK-Dokumente im Genehmigungsprozess editierbar zu machen. Dazu haben Sie im Feld EK-Dokumente editierbar unter ausstehender Genehmigung folgende Optionen:

• nein = Es sind nur die Felder editierbar, die der BC-Standard zulässt (es sind nur wenige Felder editierbar).
• durch Genehmiger = Nur der aktuelle Genehmiger kann Felder der EK-Rechnung inkl. Rechnungszeile bearbeiten.
• durch jeden Anwender = Die Anwender, die im Genehmigungsprozess hinterlegt sind, können Felder der EK-Rechnung inkl. Rechnungszeile editieren.

Ggf. sind neben der RELion Einrichtung die Angaben in der Spalte Darf Buchungszeilen editieren der Continia Benutzereinrichtung entsprechend zu aktivieren.

Zusätzlich ist es notwendig, dass Sie geteilte Genehmigungen einrichten. Hierfür in der Tabelle Geteilte Genehmigung die entsprechenden Benutzer eintragen.

Wichtig

Erlauben Sie das Editieren der Belege inkl. der Belegzeilen, kann es vorkommen, dass der erste Genehmiger einen Beleg genehmigt, der am Ende der Genehmigungskette gänzlich anders aussieht. Um dies zu vermeiden, empfehlen wir mit der Option EK-Dokumente editierbar unter ausstehender Genehmigung = nein zu arbeiten. Hier ist die Genehmigung mit einer Bemerkung abzulehnen, danach der Beleg zu bearbeiten und erneut den Genehmigungsworkflow zu starten.

Hinweis

Die Einrichtung der Web-Genehmigungen ist nur bei entsprechender Lizenzierung notwendig bzw. möglich.

Anschließend gehen Sie zurück zur Anwendungseinrichtung des Rechnungsmanagers. Über die Suche öffnen Sie die Continia Benutzereinrichtung. Wählen Sie Liste bearbeiten und legen Sie einen Benutzer an (z. B. A-SRVDEMO-01\User). Weisen Sie diesem den entsprechenden Verk.-/Einkäufercode zu und den Grenzbetrag bis zu welchen der Benutzer genehmigen darf. Dann hinterlegen Sie die entsprechende E-Mail-Adresse.

In der Spalte Genehmiger ID legen Sie den Mitarbeiter fest, der im Prozess als nächstes genehmigen soll. Legen Sie einen User an, der unbeschränkt genehmigen darf, indem Sie den Haken bei Unbegrenzte Einkaufsgenehmigung setzen.

Beispiel eines erweiterten Genehmigungsprozesses:

Arbeiten Sie mit der Genehmigung über Web-Portal, dann gehen Sie wie folgt vor:

Wenn Sie alle Benutzer konfiguriert haben, wählen Sie Benutzer exportieren in der Continia Benutzereinrichtung. Diese Funktion exportiert alle Benutzer in das Continia Web Approval Portal, sodass sich diese später anmelden können. Beachten Sie bitte, dass Sie die Funktion jedes Mal ausführen müssen, wenn Sie neue Benutzer hinzufügen oder etwas an der Web-Konfiguration von Benutzern ändern.

Sie erhalten nun eine Meldung, das X-Benutzer von X-Mandanten exportiert wurden. Es werden nur die Benutzer exportiert, die in der Spalte Genehmigungs-Client den Wert Webclient zugewiesen bekommen haben. Überprüfen Sie in der Document Capture Einrichtung den Status und die Web-Genehmigungen. Wir empfehlen Ihnen diese Einrichtungen mit einem Fachberater auszuführen.

Einkaufsbeleg erstellen

Fallbeispiel

Zur vereinfachten Darstellung verwenden wir in unserem Fallbeispiel Musterrechnungen. Alle eingehenden Rechnungen (Papier, PDF-Datei, XML-Datei) können automatisiert verarbeitet werden.

Zunächst werden die Eingangsrechnungen (Purchase lnvoice) an die E-Mail-Adresse gesendet, die in der Belegkategorie EINKAUF hinterlegt ist. Für jeden Mandanten gibt es eine eigene E-Mail-Adresse. Die OCR-Erkennung wird bei Continia Online ausgeführt und die Rechnung nach der OCR-Erkennung zum Import bereitgestellt. Im Rollencenter im Register Rechnungsmanager Aktivitäten stehen eine Reihe von Kacheln zur Bearbeitung von Rechnungen und Gutschriften bereit, die den Prozessablauf abbilden.

Zur Verdeutlichung werden im Folgenden die einzelnen Rechnungsmanager Aktivitäten für die folgenden Teilbereiche erläutert:

• Einkaufsrechnungen OCR erkennen, registrieren, genehmigen bzw. ablehnen von Rechnungen

Da die einzelnen Schritte für Einkaufsrechnung identisch sind zu Einkaufsgutschriften, wird hier nur der Teilbereich Einkaufsrechnungen beschrieben.

Erste Schritte

Mit der Funktion Dateien importieren werden die Rechnungen für die Registrierung bereit gestellt.

Hinweis

Den Import können Sie auch automatisieren. Dazu legen Sie einen – sich wiederholenden – Aufgabenwarteschlangenposten mit der Codeunit CDC Document lmporter (6085577) an.

Durch Klick auf die Kachel Bereit zur Registrierung öffnet sich der Registrierungsseite.

Wurde eine Rechnung eines Kreditors schon einmal trainiert, wird das in der Spalte Vorlagennr. durch Anzeige der entsprechenden Vorlagennummer gekennzeichnet. Ist das nicht der Fall, muss diese Rechnung zunächst trainiert werden. Die Rechnung wird ausgewählt und die Funktion Felder erkennen angeklickt. Diese Funktion versucht möglichst viele Informationen automatisch zu erkennen. Dies wird auf der rechten Seite im Dokument angezeigt. Gibt es bereits mehrere Vorlagen, da der Kreditor für mehrere Gewerke arbeitet, können Sie die entsprechende Vorlage auswählen.

Jetzt werden im Inforegister Belegkopf alle erkannten Felder angezeigt und zusätzlich im Dokument farblich gekennzeichnet. Orange umrandete Felder werden als Ankerfelder bezeichnet, blau umrandete sind Wertfelder. Im Inforegister Bemerkungen werden alle fehlenden Informationen rot dargestellt. Diese können jetzt nachbearbeitet werden.

Sind die ursprünglichen Belegfelder im Dokument leer, bleibt die Spalte Wert ebenfalls leer.

In diesem Schritt Bereit zur Registrierung stellt Continia Document Capture sehr viel Logik und Funktionalitäten bereit. Diese sind durch die unterschiedlichsten Einrichtungen mit Hilfe von Suchtexten, Formeln, Regeln und Übersetzungen abbildbar und sind in den Kreditorenvorlagen, die aus der RELion Mastervorlage erstellt werden, hinterlegt. Zusätzliche Felder können ebenfalls in die Kreditorenvorlage eingefügt und im Nachgang konfiguriert werden.

Hinweis

Änderungen am Kreditor wirken sich nicht auf die Kreditorenvorlagen aus.

Belegtraining

Jeder neue Beleg eines Kreditors muss einmal trainiert werden. Sendet der Kreditor Belege mit unterschiedlichen Layouts ( z. B. je Gewerk eine andere Rechnungsform), muss jede Rechnungsform eintrainiert werden, da z. B. das Rechnungsdatum oder die Rechnungsnummer in der Rechnung an anderen Stellen stehen könnten. Der Rechnungsmanager versucht mit der Aktion Felder erkennen möglichst viele Felder aufgrund der Mastervorlagen zu erkennen. Die restlichen nicht erkannten Felder müssen einmal trainiert werden. Beim Training ist jeweils ein Ankerfeld und das zugehörige Wertfeld zu bestimmen. Es können sowohl variable Felder als auch feste Felder trainiert werden.

Im nachfolgenden Beispiel wird ein variables Feld Ursprüngliche Belegnummer und ein Feld mit festem Wert Ursprüngliche Belegart trainiert.

Training des variablen Feldes

Der Mauszeiger wird im Inforegister Belegkopf in die Spalte Wert der Zeile Ursprüngliche Belegnummer gestellt. Danach wird im Beleg das Ankerfeld Ihre Bestellnr. mit der gedrückten rechten Maustaste umfahren. Das Ankerfeld wird nun orange markiert.

Weiterhin bleibt der Mauszeiger im Inforegister Belegkopf in der Spalte Wert der o. g. Zeile stehen. Danach wird auf dem Beleg das Wertfeld MNAB22-00013 mit der gedrückten linken Maustaste umfahren. Das Wertfeld wird nun blau markiert. Die Beauftragungsnummer wird in die Zeile Ursprüngliche Belegnummer der Spalte Wert übernommen. Damit ist dieses Feld trainiert worden und wird in die Vorlage T000002 übernommen, sodass es beim nächsten vorliegenden gleichen Beleg des Kreditors automatisch erkannt wird.

Training eines Feldes mit festem Wert

Da es in RELion verschiedene Belegarten gibt, muss in dem Feld Ursprüngliche Belegart noch die Belegart für Beauftragungen hinterlegt werden. Dieser Wert ist immer konstant und wird deshalb als fester Wert hinterlegt. Gleiches könnte z. B. auch beim Eigentümer/Mieter Kennzeichen der Fall sein. Um den festen Wert zu hinterlegen, klicken Sie den Assist Button in der Zeile Ursprüngliche Belegart an. Es öffnet sich die Vorlage Feld Karte. Hier tragen Sie im Feld Formel eine 1 ein. Die 1 steht für Belegart Beauftragungen. Die Eingabe bestätigen Sie mit OK.

Für den RELion Rechnungsmanager ist eine Funktion hinterlegt, die aufgrund der Belegart 1 und der Belegnummer automatisch prüft, ob eine solche Beauftragung vorliegt. Ist dies der Fall, werden alle benötigten Werte aus der Beauftragung automatisch mit der Funktion Felder erkennen übernommen. Wird in der Einrichtung ein automatisches Felder erkennen und eine automatische Registrierung eingerichtet, und werden alle Wertfelder korrekt erkannt, wird sofort eine Eingangsrechnung erstellt, die dann zum Prüfen und Buchen bereitsteht. Selbst das Buchen könnte noch automatisiert werden.

Es lässt sich jederzeit prüfen, ob eine Beauftragung zu dieser Rechnung vorliegt. In der Spalte Anz. Einkaufsbestellungen wird die Anzahl der Beauftragungen angezeigt, die zurzeit für den Kreditor Kuhberger GmbH vorhanden sind. Per DrillDown öffnet sich die Liste aller Beauftragungen. Die Beauftragungen mit dem Status Freigegeben können übernommen werden. Um die einzelne Einkaufsbestellung zu bearbeiten, öffnen Sie die Karte über Zugehörig. In der Spalte RE Projekt Nr. erkennen Sie, ob es sich um eine Projektrechnung handelt.

Die in der Rechnung angegebene Beauftragungsnummer ist ebenfalls vorhanden und hat den Status Freigegeben und ist keine Projektrechnung. Durch Klicken auf den Button Schließen wird die Übersicht geschlossen und die Rechnung kann nun weiterbearbeitet werden.

Falls Fehler beim Felder erkennen erkannt wurden, die in der Beauftragung hinterlegt sind, wie z. B. Objektnummer oder Mieter/Eigentümer nicht korrekt, dann werden diese im Inforegister Bemerkungen angezeigt. Die Meldung Rechnungsnr. ist nicht korrekt bedeutet, obwohl richtig eingelesen wurde, dass sich etwas am Format der Rechnungsnummer geändert hat. Dies wird automatisch korrigiert, sodass die Rechnungsnummer des Kreditoren, wie im Beleg angegeben, übernommen wird.

Beispiel für das Anlernen von Betragsfeldern

Um die Betragsfelder Brutto, Netto und MwSt. korrekt zu belegen, können Sie die Einrichtung wie folgt vornehmen:

Tipp

Wir empfehlen am Kreditor im Inforegister Fakturierung das Feld EK-Preise inkl. MwSt. zu aktivieren. Sollten bereits Kreditorenvorlagen für diesen Kreditor vorhanden sein, aktivieren Sie auch dort dieses Feld. Nur so ist gewährleistet, dass bei jeder möglichen steuerlichen Einrichtung an den Sachkonten oder in den Steuerdaten am Objekt die Rechnungsbeträge korrekt in den Einkaufsbelegen verarbeitet werden. Dabei hinaus ist es wichtig, dass dann das Vorlagenfeld Betrag, brutto in die Einkaufszeile in das Feld EK-Preis übernommen wird.

Belegzeilenerkennung

Der Rechnungsmanager unterstützt die Belegzeilenerkennung hinsichtlich der Objektkontenfindung. Hierfür ist eine Übersetzung einzurichten. Diese sind an der Kreditorenvorlage zu hinterlegen.

Zusätzlich ist im Vorlagenfeld Objektkonto im Feld Formel das Feld Nr zu hinterlegen.

Hinweis

Um die Kreditorenvorlagen alle mit den Übersetzungen anzureichern, gibt es einen Report. Dieser ist in dem Kapitel beschrieben.

Beauftragung

Belegung der Felder

Wird in der Rechnung des Kreditors auf die RELion Beauftragungsnummer verwiesen, können Sie dies trainieren. Da in der RELion Beauftragung alle benötigten RELion Felder schon vorhanden sind, werden diese Informationen beim entsprechenden Training automatisch in den Beleg reingeholt und den Feldern zugewiesen. Dazu aktivieren Sie in der Kreditorenvorlage das Feld Beauftragung automatisch holen.

Wenn die Beauftragungsnummer auf dem Einkaufsbeleg hinterlegt ist, erreichen Sie einen deutlich höheren Automatisierungsgrad, da die Anzahl der Bemerkungen zu angezeigten Fehlern entweder deutlich verringert bzw. ganz aufgehoben wird.

Beauftragung holen

Neben der Variante, die Einkaufsbestellung über die Felder ursprüngliche Belegart und ursprüngliche Belegnummer erkennen zu lassen, gibt es auch die Möglichkeit, explizit die Funktion Beauftragung holen zu nutzen. Es öffnet sich ein Fenster mit den freigegebenen Einkaufsbestellungen des Kreditors.

Nun kann die gewünschte Einkaufsbestellung ausgewählt und mit OK bestätigt werden. Werte aus der Beauftragung werden nun in die Felder des Belegkopfes übernommen. Der Vorgang ähnelt dem „Beauftragung holen“, welcher aus dem Einkaufsbeleg bekannt ist. Die Beauftragung wird nicht beim Holen der Beauftragung archiviert, dieser Schritt wird ggf. beim Buchen der Rechnung durchgeführt. Vergleichen Sie dazu auch Kapitel Buchen der Rechnung.

Beauftragungszeilen

Neben dem Beauftragungskopf können auch die Beauftragungszeilen in den Beleg übernommen werden. Die Zeilen werden beim Holen der Beauftragung mit übernommen, wenn folgende Einrichtung in der Kreditorenvorlage hinterlegt ist.

Ist das Feld Beauftragungszeilen holen aktiviert, werden die Beauftragungszeilen in die Ansicht bei Bereit zur Registrierung eingefügt. Die Funktion erfolgt sowohl beim automatischen Beauftragung holen als auch bei Beauftragung holen per Schaltfläche. Sie können die Zeilen auf der Dokumentenkarte einsehen und unabhängig von der Einkaufsbestellung bearbeiten. Diese Zeilen werden beim Registrieren in die neu erstellte Rechnung eingetragen.

Welche Felder mit der Funktion belegt im Einkaufsbeleg übernommen werden, entnehmen Sie bitte der Tabelle in dem Kapitel RELion Felder. Nach Ausführung der Aktion Beauftragung holen verlassen Sie die Dokumentenkarte und öffnen sie erneut. Die Aktualisierung der Seite funktioniert vom System nicht.

Wichtig

Felder der Beauftragungszeile, die in den EK-Beleg übernommen werden sollen (z. B. Abrechnungskreis oder Beschreibung), müssen in den Zeilen der Dokumentenkarte als Vorlagenfeld erstellt werden.

Die Einrichtung der Übersetzungen gilt ebenfalls für das Verarbeiten der Beauftragungszeilen.

Beleg registrieren

Nachdem alle Felder richtig erkannt wurden, wird in der Spalte OK ein Haken gesetzt. D. h., dass die Rechnung jetzt durch Aufrufen der Funktion Registrieren als Eingangsrechnung in RELion erzeugt wird.

Ist ein Genehmigungsworkflow installiert, erscheint beim Registrieren folgende Meldung:

Bestätigen Sie mit OK und es öffnet sich die Eingangsrechnung. Falls erforderlich, können Sie die Rechnung jetzt noch nachbearbeiten. Es wird sowohl der Beleg als auch der Genehmigungsprozess angezeigt. Der Genehmigungsprozess wird hier näher erklärt.

Nachdem die Rechnung erstellt und für den Genehmigungsprozess bereitgestellt wurde, ändert sich die Anzahl in den markierten Kacheln.

Hinweis

Für Projektrechnungen gilt, wie vorher beschrieben, das Gleiche. Wird eine Projektrechnung registriert, erhält der Anwender im Belegkopf eine Information. Sie müssen jetzt entscheiden, ob es eine Teil- oder eine Schlussrechnung ist. Zusätzlich wird im Kalkulationsschema in der Projektentwicklung das Dokument in der Infobox angezeigt.

Hinweis

Verarbeitung von Versorgerrechnungen über den RRM Es besteht keine Verknüpfung zum Wiederkehrenden Buchblatt, sodass die Freigabe/Zahlung von Dauerrechnungen nicht über den Rechnungsmanager abgebildet werden kann. Eine Einbindung vom Modul Dauerzahlungen oder wiederkehrenden Buchblättern in den Rechnungsmanager ist nicht geplant, da diese Module hauptsächlich die Zahlungsströme aus Abschlagsrechnungen abwickeln. In der EK-Rechnung gibt es zudem bereits eine Verbindung zu den Dauerzahlungen. Eine weitere Anbindung der Funktionalitäten an den Rechnungsmanager wird nicht durchgeführt.

Wartungsvertrag mit Einkaufsbeleg verknüpfen

Rechnungen des Rechnungsmanagers mit Wartungsverträgen können mit Dienstleistungsverträgen verknüpft werden. In dem Zusammenhang wird immer von Wartungsverträgen gesprochen. Die Funktionalität gilt jedoch in gleicher Weise für die Dienstleistungsverträge.

Dazu gibt es auf der Vorlagenkarte zwei Felder:

Wenn Sie z. B. Wartungsvertragszeilen holen aktivieren, dann werden die Zeilen aus dem Wartungsvertrag heraus im EK-Beleg angelegt, andernfalls nur die Kopfinformationen.

Es werden nur Zeilen aus dem Wartungsvertrag geholt, deren Felder letzte Faktura am und nächste Faktura am leer sind oder das Belegdatum zwischen letzte Faktura am und nächste Faktura am liegt. Diese Vorgehensweise entspricht dem RELion Standard sowie die Funktionalitäten des weiteren Einkaufsprozesses. Es gibt dann keinen Unterschied, ob Sie eine Einkaufsrechnung mit Bezug zu einem Wartungsvertrag mit oder ohne Rechnungsmanager erstellt haben.

Die Verarbeitung der Rechnungszeilen folgt nach dem Continia Document Capture Prozess. Hier gelten bzgl. der Einrichtungen für Continia Document Capture und dem Rechnungsmanager die gleichen Vorgaben, die Sie schon von der Funktion Beauftragung holen kennen.

Wenn Sie in der Dokumentenkarte die Aktion Dokument/Wartungsvertrag holen ausführen, werden ggf. die Zeilen mit in die Dokumentenkarte übernommen. Das Übernehmen der Zeilen funktioniert auch beim automatischen Holen des Wartungsvertrages. Auf der Dokumentenkarte können die Zeilen unabhängig von der Wartungsvertrag bearbeitet werden. Diese Zeilen werden beim Registrieren in die neu erstellte Rechnung eingetragen. Für die Bearbeitung der Zeilenfelder, die aus dem Wartungsvertrag geholt wurden, können die Continia Document Capture Standard Funktionalitäten verwendet werden. Nach Ausführung der Funktion Wartungsvertrag holen schließen Sie die Dokumentenkarte und öffnen sie erneut. Die Page Seite wird nicht automatisch aktualisiert.

Folgende Einrichtung nehmen Sie in der Vorlage vor:

• Das Feld Ursprüngliche Belegnummer mit dem Code ORIGDOCNO muss als Kopffeld definiert werden.
• Das Feld Wartungsvertragsnr. (Code: MAINCONTRACTNO) muss in der Vorlage als Kopffeld definiert werden. In dem Vorlagenfeld wählen Sie im Feld Wert übertragen nach Einkaufskopf und in Einkaufszeile jeweils Wartungsvertragsnr. aus.

Beim Einlesen des Einkaufsbeleges fügen Sie die externe Wartungsvertragsnummer in das Feld Wartungsvertragsnr. ein (ggf. durch anlernen im Beleg, z. B. A-02346-35234XR9). Die Nr. wird automatisch in das Feld eingetragen, wenn Sie manuell die Funktion Wartungsvertrag holen ausführen. Dieses Feld wird programmtechnisch in die interne RELion Wartungsvertragsnummer (z. B. WV-00004) umgesetzt und in das Feld Wartungsvertragsnr. sowie in die ursprüngliche Belegnummer eingetragen.

Zusätzlich legen Sie in der Vorlage die Zeilenfelder Wartungsvertragnr. und Wartungsvertragzeilennr. an. Bei beiden müssen die Werte in die Einkaufszeile übertragen werden.

Voraussetzung für die Verarbeitung der Belegzeilen ist, dass es entsprechende Zeilen in der Tabelle Übersetzungen Nummer gibt. Die Informationen in der Spalte Übersetzen nach Nr. greift jedoch nicht, sondern die Informationen werden aus dem Objektkontenplan gezogen. (RELion Standard). Es wird empfohlen, die verwendeten Konten in der RELion Mastervorlage zu hinterlegen. Diese Übersetzungen werden dann in neue Kreditorenvorlagen übernommen.

Soll die Beschreibung aus den Wartungsvertragszeilen übernommen werden, muss dafür in der Kreditorenvorlage der Haken gesetzt sein bei Zeilenerkennung (Continia Standard) und zusätzlich im Zeilenfeld Beschreibung hinterlegt sein, dass dieses in die Einkaufszeile übernommen wird.

Wichtig

Es gibt nur ein Betragsfeld in den Wartungsvertragszeilen, daher ist es aktuell nicht möglich zu unterscheiden, ob der Betrag brutto oder netto ist. Handelt es sich um einen Bruttobetrag, dann sind die Felder Preis pro Einheit und Zeilensumme in den Zeilen bei Bereit zur Registrierung zu editieren, eine Registrierung ist andernfalls nicht möglich. Es ist geplant die Wartungsverträge hier zu erweitern, damit die korrekten Werte übertragen werden und zukünftig keine Korrektur bei der Verarbeitung notwendig wird.

Genehmigungsprozess

Genehmigen einer Rechnung

Den Genehmigungsprozess für eine Einkaufsrechnung können Sie über die Kachel Offene Rechnungen starten. Es öffnet sich die Übersicht aller offenen Rechnungen. Aus dieser Übersicht können Sie nun eine Genehmigungsanforderung senden. Die Genehmigungsanforderung wird an den Einkäufer gesendet, der in der Rechnung hinterlegt ist. Durch Klicken der Aktion Genehmigungsanforderung senden wird der Genehmigungsprozess manuell gestartet. Es erscheint eine Meldung, dass die Genehmigungsanforderung gesendet wurde.

Nach der Bestätigungsmeldung ist die Rechnung nicht mehr in der Ansicht Offene Rechnungen zu finden, sondern in Rechnungen zur Genehmigung. Die Genehmigung kann direkt über die Übersicht der Rechnungen zur Genehmigung erfolgen.

Alternativ können Sie den Beleg öffnen und die gesamte Rechnung einsehen. Hier besteht auch die Möglichkeit eine Genehmigungsbemerkungen anzugeben. Dies ist über den Aufruf Bemerkungen im Menübandbereich Genehmigen möglich.

Sobald Sie den Button Genehmigen betätigen, wird die Rechnung vom ersten Genehmigungsuser genehmigt und an den zweiten Genehmiger übermittelt. Im Feld Genehmigung durch wird nun der Name des zweiten Genehmigers angezeigt und ebenfalls die Genehmigungsbemerkungen.

Der zweite Genehmiger hat die Möglichkeit, ebenfalls eine Bemerkung einzustellen und drückt dann den Button Genehmigen. Der Rechnungsmanager prüft nun, ob alle zur Buchung notwendigen Angaben vorhanden sind. Fehlen buchungsrelevante Angaben, erscheint ein entsprechender Hinweis. Erst wenn alle benötigten Angaben erfasst wurden, können Sie die Rechnungen buchen.

Wichtig

Sie können die Genehmigung ablehnen, indem der Genehmiger die entsprechende Aktion im Menü wählt. Danach wird die Rechnung entsprechend überarbeitet, je nach Grund der Ablehnung. Die bearbeitete Rechnung muss schließlich noch einmal den gesamten Genehmigungsprozess durchlaufen.

Wichtig

Eine Objektänderung während des Genehmigungsprozess sollte nicht vorgenommen werden. Hier kann es zu Problemen mit der Objektdimension kommen, was Auswirkungen auf Auswertung haben kann (z. B. bei der Auswertung des Kontenschematas mit Bezug auf DIM Objekte). Die Probleme treten u.a. auf, wenn Sie mit dem gleichen Nummernkreis für ungebuchte wie für gebucht Rechnungen arbeiten. Sollten Objektänderungen vorgenommen werden, so ist das Dokument abzulehnen, das Objekt zu ändern und der Genehmigungsworkflow erneut zu starten.

Einkäufercode – Unser Kontakt

Wird weder auf der Rechnung noch in der Bestellung ein Einkäufer-/Verkäufer-Code gefunden, können Sie den Rechnungsmanager so einrichten, dass der zuständige Sachbearbeiter am Objekt die Genehmigungsanforderung erhält. Gibt es keinen Objektsachbearbeiter oder wird mit der Funktion nicht gearbeitet, wird alternativ der Einkäufer am Kreditor verwendet. Folgende Suchreihenfolge wird hierbei ausgeführt:

1. Es gibt einen angelernten Kontakt aus dem Beleg, und einen entsprechenden Einkäufercode.
2. In der Kreditorenvorlage ist ein Objektsachbearbeiter hinterlegt. Es gibt an dem Objekt einen Sachbearbeiter mit dieser Rolle.
3. Der Einkäufercode des Kreditors wird verwendet.

Dazu muss folgende Einrichtung durchgeführt werden:

1. Ein Rollencode muss definiert werden. Über das Suchfeld können Sie den RE Bearbeiter Rollen auswählen.
2. Jetzt wird die entsprechende Rolle über die Aktion Neu angelegt und anschließend mit OK bestätigt.

Dann definieren Sie am Objekt einen entsprechenden Mitarbeiter.

Wichtig

Bei der Rolle Rechnungsmanager hat das Feld Hauptsachbearbeiter keine Wirkung.

Damit der Rechnungsmanager diese Einrichtungen erkennt, muss folgende Einrichtung in den Belegkategorien durchgeführt werden. In der Mastervorlagenkarte legen Sie die Rolle Sachbearbeiter fest.

Jetzt werden alle Rechnungen für das entsprechende Objekt an den Sachbearbeiter zur Genehmigung geschickt, wenn die in der Einleitung zu diesem Kapitel beschriebenen Optionen zutreffen.

Wichtig

Voraussetzung dafür, dass der Sacharbeiter mit der entsprechend hier festgelegten Rolle bei der Felderkennung auch wie gewünscht gezogen wird, ist, dass im Vorfeld die Mieter/Eigentümer-Kennung richtig gesetzt wird.

Ablehnen einer Rechnung

Wird eine Rechnung im Status Genehmigung ausstehend durch einen Genehmiger mit einer Bemerkung abgelehnt, steht diese Bemerkung in dem abgelehnten Beleg zur Verfügung.

Beispiel: Eine Rechnung, die sich im Status Genehmigung ausstehend befindet wird mit einer Bemerkung abgelehnt. Diese Rechnung hat nun wieder den Status Offen und kann über die Kachel offene Rechnungen geöffnet werden. Es gibt nun mehrere Möglichkeiten, wie Sie weiter verfahren können.

1. Sie können die offene Rechnung korrigieren und den Genehmigungsprozess erneut starten.
2. Muss die Rechnung durch den Kreditor korrigiert werden, können Sie die offene Rechnung löschen. Hierfür gibt es wieder zwei Wege:

a. In dem offenen EK-Beleg wechseln Sie auf die Dokumentenkarte und ändern den Status über die Schaltfläche Status zurücksetzen.

Die Genehmigungsbemerkungen finden Sie nun in dem Beleg Bereit zur Registrierung in den Bemerkungen.

Im Anschluss wählen Sie im Menü unter Aktionen auf Ablehnen. Dann können Sie eine E-Mail an den Kreditor senden. Sie finden den Beleg unter den Abgelehnten Belegen, auch hier ist die Bemerkung einsehbar. Der Prozess beginnt nun komplett von vorne, wenn die neue Rechnung des Kreditors eingeht. Arbeiten Sie mit Belegzeilen, werden ggf. geänderte Beschreibungen in den Belegzeilen wieder auf die Ausgangsbeschreibung zurückgesetzt (Document Capture Standard).

b. Die Rechnung wird direkt aus der Übersicht der offenen Rechnungen gelöscht.

Sowohl bei Punkt a als auch bei Punkt b gilt folgendes:

Wichtig

Bei gleichem Nummernkreis für ungebuchte und gebuchte Rechnungen wird ein sog. Nullbeleg gebucht und ist über die Ansicht gebuchte Rechnungen einsehbar. Dieser Beleg dient dazu, einen lückenlosen Nummernkreis nachweisen zu können. Die Genehmigungsbemerkungen werden in diesen Nullbeleg übernommen, wenn eine Einkaufsrechnung abgelehnt und dann direkt gelöscht oder über Status zurücksetzen aus der Dokumentenkarte heraus gelöscht wird. Nähere Information erhalten Sie unter Kapitel Buchen der Rechnung.

Arbeiten Sie nach Punkt b, gibt es in den gebuchten Beleg nur einen Anhang. Voraussetzung für die Funktionalität ist in der Belegkategorie Einkauf die Einrichtung einer Codeunit in der Belegkategorie EINKAUF RELion Mastervorlage.  

Buchen der Rechnung

Wurde eine Rechnung komplett genehmigt, steht diese über die Kachel Freigegebene Rechnungen zum Buchen zur Verfügung.

Zunächst wird wieder die Übersicht angezeigt, aus der Sie die Rechnung zum Bearbeiten aufrufen können. Es sind alle Genehmigungsbemerkungen (auch Vertreterregelung) in der ungebuchten EK-Rechnung dokumentiert. Rufen Sie diese über Genehmigen/Bemerkungen auf: Die Rechnung können Sie jetzt buchen.

Die Genehmigungsbemerkungen werden in die gebuchte Rechnung übernommen. Alle Genehmigungen können Sie über Rechnung / Genehmigungen / Bemerkungen aufrufen.

Gibt es eine freigegebene Beauftragung zur Rechnung?

Falls ja, wird die Beauftragung beim Buchen der Rechnung aus der Übersicht der offenen Beauftragungen gelöscht und archiviert (es gibt einen neuen Eintrag in der Übersicht Bestellarchive), wenn dies in der Kreditoren & Einkaufseinrichtung hinterlegt ist. Die Löschung und Archivierung wird nur für folgende Beauftragungen durchgeführt:

• Beauftragung hat den Status Freigegeben.
• Wenn der Betrag (inkl. Steuer) der Beauftragung gleich oder kleiner des Betrags (inkl. Steuer) der EK-Rechnung ist.
• Es gibt keine Verknüpfung zu einem Projekt. Ausnahme: wenn Sie mit der Schlussrechnungsfunktionalität des Projektmoduls arbeiten, wird eine zugehörige Beauftragung beim Buchen einer Schlussrechnung gelöscht/archiviert.

Andernfalls verbleibt die Beauftragung in der Übersicht der offenen Beauftragungen. Ggf. kann hierfür noch eine weitere Rechnung eingehen.

Wichtig

Im Fehlerfall prüfen Sie bitte die Einrichtung, die in der Kreditorenvorlage nötig ist, damit die Beauftragungsnummer korrekt im Beleg Einkaufsrechnung hinterlegt wird, siehe Training des variablen Feldes und Training eines Feldes mit festem Wert.

Weiterführende Themen und Sonstiges

Genehmigungen über Web-Portale

Das Continia Web Approval Portal ist ein Zusatzmodul von Continia für die Freigabe von Dokumenten. Als Benutzer des Rechnungsmanager können Sie wählen, ob das Continia Web Approval Portal entweder in der Cloud (gehostet von Continia Software auf Azure) oder auf Ihrem eigenen Internet Information Server vor Ort installiert werden soll.

Das Portal ist als responsive Website konzipiert, d. h., das Portal bietet genau die gleiche Funktionalität, egal ob Sie einen PC, ein Tablet oder ein Smartphone verwenden. Bevor Sie sich am Continia Web Approval Portal anmelden, müssen Sie sicherstellen, dass alle Genehmiger korrekt eingerichtet worden sind.

Wichtig

Im Web Approval Portal können keine RELion Felder geändert werden, da diese hier nicht zur Verfügung stehen.

Continia Web Approval Portal verwenden

Starten Sie einen Webbrowser und öffnen Sie die entsprechende Seite https://continiaonline.com. Beim Zugriff auf das Portal, melden Sie sich mit Ihrer Windows-Benutzer-ID und dem Passwort an.

Hinweis

Wenn Sie Continia Online verwenden, entsprechen die Benutzernamen den E-Mail-Adressen, welche den Benutzern in Business Central zugewiesen worden sind.

Danach erscheint eine Übersicht aller ausstehenden Genehmigungen, die Ihnen zugeordnet wurden.

Durch Anklicken der entsprechenden Genehmigung werden alle Details wie im BC-Client angezeigt. Wählen Sie Genehmigen, Ablehnen, Weiterleiten oder Auf abwarten setzen. Sie können auch den Genehmigungsposten aufrufen, angehängte Dokumente betrachten bzw. ergänzen oder auch die Buchungszeilen anpassen.

Teilen und zusammenführen

Die Belegtrennung zur Aufteilung einer PDF-Datei kann manuell oder automatisch stattfinden. Bei der manuellen Aufteilung können Sie ein mehrseitiges PDF-Dokument wählen, und angeben, ab welcher Seite es geteilt werden soll. Analog dazu können Sie auch mehrere vorhandene PDF-Dateien wählen und diese in ein Dokument zusammenführen. Die automatische Aufteilung kann anhand folgender Kriterien eingerichtet werden:

• Leerseiten,
• ein definierter Barcode,
• Kreditorenerkennung,
• Rechnungsnummer.

Ab der Continia Version 5.50 muss die automatische Aufteilung aktiviert werden. Über die Suche öffnen Sie die Tabelle Belegkategorie und wählen den Datensatz EINKAUF. Aktivieren Sie im Inforegister OCR Verarbeitung eine der Optionen Dokumente automatisch teilen, Bei leerer Seite aufteilen, Herkunfts-ID und Trennzeichen Felder sowie Barcode.

Aufteilung beim Auftreten leerer Seiten

Werden die eingehenden Papierrechnungen beim Scannen im Stapel jeweils durch eine Leerseite getrennt, kann der Rechnungsmanager die zusammenhängende PDF-Datei so interpretieren, dass die Einzelrechnungen erkannt werden und jeweils als PDF-Datei zur Verfügung stehen. Die weiteren, vorher gezeigten, Optionen arbeiten identisch.

Manuelle Aufteilung

Für manuelles Aufteilen und Zusammenführen klicken Sie im Menü auf Teilen und zusammenführen.

Löschen Sie dann die Leerseiten. Dazu markieren Sie die Seiten und wählen die Aktion Löschen aus. Falls einzelne Belege aufgeteilt werden, markieren Sie bitte die entsprechende Seite und dann die Funktion Dokumente trennen ausführen. Bei Belegen die zusammengeführt werden müssen, markieren Sie die Seite 1 und 2 und wählen dann die Funktion Zusammenführen. Anschließend können Sie die Belege registrieren.

Übersetzungen

Beim Registrieren von Rechnungen und anderen Dokumenten kann es notwendig sein, die Vorlage oder Vorlagenfelder anzupassen, um Buchstaben, Wörter oder Zahlen in andere Werte zu übersetzen. Die Gründe hierfür können von Beleg zu Beleg unterschiedlich sein.

Beispiele, welche die Verwendung von Übersetzungen notwendig machen, können sein: Irreführende Angaben auf der Rechnung oder ein von der OCR-Software falsch erkannter Text. Des Weiteren gibt es auch allgemeine Übersetzungsregeln beim Erzeugen von Einkaufszeilen. Es wird zwischen vier Übersetzungsarten unterschieden:

1. Betragskonto-Übersetzung
2. Zeilenübersetzung
3. Verkäufer/Einkäufer-Übersetzung
4. Feldübersetzung

Die ersten drei Übersetzungsarten können Sie aus dem Belegjournal bzw. der Belegkarte aufrufen, indem Sie im Menüband die Funktion Übersetzungen anklicken.

Betragskonto-Übersetzung

Die Übersetzung von Konten für Beträge ist davon abhängig, mit welchem Konto der Betrag gebucht werden soll, der auf der Rechnung ausgelesen wurde. Sie können für verschiedene Beträge, wie zum Beispiel Frachtkosten, spezifische Buchungskonten einrichten. In diesem Zusammenhang besteht auch die Möglichkeit, weitere Werte wie Dimensionen oder MwSt.-Konten zu hinterlegen, welche dann in der jeweiligen Buchungszeile hinterlegt werden.

Hier können Sie auch einen Betragsverteilungscode auswählen. Dieser wird in der Einrichtung von Document Capture hinterlegt und definiert die Verteilung von Beträgen.

Zeilenübersetzung

Zeilenübersetzungen können verwendet werden, wenn auch die Belegzeilen erkannt und verarbeitet werden sollen. Hier können Sie definieren, wie z. B. eine Artikelnummer Ihres Kreditors aus der Einkaufsrechnung in eine eigene Artikelnummer übersetzt werden soll. Genau wie bei den Betragsübersetzungen, können Sie auch bei den Zeilen weitere Informationen (z. B. Dimensionen) ergänzen oder anpassen.

Verkäufer/Einkäufer-Übersetzung

Es kann Fälle geben, bei denen ein anderer Einkäufercode verwendet werden soll als der Code, der anhand der Vorlage ermittelt wurde. Des Weiteren kann es notwendig sein, den Einkäufercode anhand von Informationen zu setzen, die auf der Einkaufsrechnung gefunden werden, bspw. ein Projektname oder ein Abteilungscode. Dies können Sie durch die Verkäufer/Einkäufer-Übersetzung einrichten.

Diese Übersetzung kann sowohl für alle Kreditoren als auch für einzelne Kreditoren, wie im nachfolgenden Beispiel gezeigt wird, durchgeführt werden.

Feldübersetzung

Die vierte Übersetzungsmöglichkeit ist die Feldübersetzung. Sind die spezifischen Vorlagenfelder bearbeitet, können Sie über die Funktion Übersetzungen individuelle Feldübersetzungen einrichten. Dies kann bspw. verwendet werden, um falsche Buchstaben oder Zahlen in valide Werte umzuwandeln.

In dem folgenden Beispiel wurden mehrere Übersetzungen für das Feld Rechnungsnr. eingerichtet, die Werte übersetzen, welche möglicherweise nicht korrekt von der OCR-Software erkannt wurden. Wenn die Rechnung z. B. 1- enthält, wird der Wert als 1 übersetzt. Des Weiteren werden diverse Werte entfernt, die in der Regel nicht korrekt sind. Diese zwei Übersetzungen sorgen dafür, dass die Rechnungsnr. korrekt ist, auch wenn die OCR-Erkennung fehlerhafte Werte zurückgibt. Der erkannte Wert 1- soll in Zukunft ohne Minuszeichen übernommen werden:

Mehrfache Beträge

Sie können mit Document Capture auch mehrere Beträge eines Belegs auslesen, ohne die jeweiligen Rechnungszeilen auslesen zu müssen. Wenn Sie Document Capture einrichten, enthält die Master Vorlage schon diverse Betragsfelder. Um die Vorlage so einzurichten, dass auch weitere Felder ausgelesen werden können, wählen Sie über die Funktion Vorlagenfeld hinzufügen das gewünschte Feld aus der Vorlagenfeldliste aus.

Wenn die Kreditorenrechnung bspw. einen Betrag in anderer Währung enthält, können Sie das Feld Währung der Vorlage hinzufügen und mit dem Wert aus der Rechnung füllen lassen.

In manchen Fällen ist es notwendig, dass der Betrag des Feldes vom Rechnungsbetrag abgezogen werden muss, damit die Einkaufszeilen mit den korrekten Beträgen erzeugt werden können. Dies können Sie über das Feld Betrag bei Registrierung abziehen von erreichen. Hier entscheiden Sie, von welcher Summe (z. B. Betrag exkl. MwSt.) die Frachtkosten abgezogen werden sollen.

Verschieben in Mandanten

Document Capture kann die Dokumente beim Import auch in die konfigurierten Mandanten verschieben. Damit das funktioniert, müssen Suchbegriffe definiert werden, die dafür sorgen, dass Belege dem jeweils richtigen Mandanten zugewiesen werden können.

In der Tabelle Mandanten Suchtexte werden die Mandantenbezeichnungen erfasst. Beim Import der Belege wird der Adressbereich ausgewertet und die Belege entsprechend verschoben.

Das Verschieben kann auch manuell erfolgen.

Archivierung des Belegs über Archiv kompakt

Es gibt die Möglichkeit, das eingelesene Dokument bei der Buchung des entsprechenden Belegs automatisch über die Archiv kompakt-Schnittstelle zu archivieren.

Um diese Option zu nutzen, muss das Dokumentmanagementsystem Archiv kompakt (AAK) installiert werden und mit den grundsätzlichen Einrichtungen auf dem Archiv kompakt-Manager versehen sein. Näheres dazu finden Sie in der Anwenderdokumentation RELion Dokumente. Es ist keine Einrichtung im RRM durchzuführen. Jedoch ist eine zusätzliche Einrichtung bei Archiv kompakt notwendig. In der RELion Dokumente Einrichtung sind bei den Tabellen ein eindeutiges Rechnungsmanager Archiv zu hinterlegen. Sowohl für die Einkaufsrechnungen als auch für die Einkaufsgutschriften:

Bitte beachten Sie, dass diesem Archiv im Archiv Manager kein Schlagwort als Pflichtfeld zugewiesen ist. Der Dokumentenname im Archiv richtet sich nach der Einrichtung in Document Capture im Feld Dateiname der Einkaufsbelegdateien.

Wir empfehlen, hier die Einstellung Gebuchte Belegnummer zu verwenden. Gerade, wenn mit DATEV gearbeitet wird, sollte diese Einstellung vorgenommen werden. Beim Buchungsvorgang eines Einkaufbelegs wird die Archivierung des angehängten PDFs vorgenommen.

Drag & Drop-Infobox mit Standard Drag & Drop-Kategorie

Wenn Sie die Anforderung erhalten, ein Dokument bzw. einen Anhang an einen Datensatz in Business Central anzuhängen, können Sie eine von Document Capture zur Verfügung gestellte Infobox in jeder Karte oder Liste integrieren. Die Drag & Drop Infobox kann zu jeder möglichen Page hinzugefügt werden.

Navigation mittels Erkunden

Wird das Menü Document Capture in RELion unter Weitere Rollen entdecken nicht angezeigt, sind folgende Punkte zu prüfen:

• Document Capture muss lizensiert sein. Dazu geben Sie in der Suche Document Capture Einrichtung.
• Der Benutzer muss mindestens die Rollen CDC ALL und CSC BASIC besitzen.
• Er muss im richtigen Rollencenter sein, der Document Capture verwendet. Das sind: Accountant, Accounting Manager, Accounts Payable Coordinator, Bookkeeper, Business Manager
• Beim Benutzer prüfen, ob die Benutzerrechte für den gewünschten Mandanten freigeben sind (Feld Mandant).

XML-Einkaufsbelege mit Continia Document Capture

Das folgende gilt für die Nutzung von Continia Document Capture in Verbindung mit dem Rechnungsmanager ohne Continia eDocuments (Continia Delivery Network).

Einrichtung und Nutzung

Hinweis

Die XML-Files kommen per Mail in das System. Hierfür senden Sie die XML/ZUGFeRD-Rechnung an die E-Mail Adresse, die unter Belegkategorie eingerichtet wurde. Bitte beachten Sie erst ab ZUGFeRD 2.0 wird die integrierte XML ausgewertet. (siehe Unterstützte Dateiformate)

Importieren der Mastervorlagen

Starten Sie den Document Capture Konfigurationsassistenten.

Wählen Sie unter Belegkategorie Einkauf die entsprechend in Ihrem Unternehmen genutzten Vorlagen aus.

Wichtig

Wählen Sie sowohl die Vorlage als auch die Identifikation aus.

Auswahl der Mastervorlagen

Wählen Sie nun die Belegkategorie Einkauf aus und Bearbeiten diese.

Wichtig ist, dass sie in der Spalte XML-Identifikationsvorlage die entsprechende ID-Vorlage eintragen. Dann wird die Mastervorlage auch verwendet. In dem ID-File ist z. B. auch hinterlegt, dass die USt-IDNr. für die Kreditorenfindung verwendet wird.

Eintragung von CodeUnits

Folgende Relion CodeUnits müssen in der Mastervorlage hinterlegt werden:

Felder für Rechnungsmanager anlegen

Folgende Felder müssen mindestens in der XML-Mastervorlage vorhanden sein, damit der Rechnungsbeleg korrekt registriert werden kann.

Sie können in den Feldern mit Regeln und Formeln arbeiten. Andernfalls sind die Felder vor der Registrierung manuell zu belegen. Vorschlag für die Einrichtung der Felder (Kopffelder):

Mit Herkunftsfilter:

Einlesen von XML-Einkaufsrechnungen

Die XML-Datei senden Sie an die E-Mail Adresse, die unter Belegkategorie EINKAUF eingetragen ist. Danach importieren Sie die Datei und sie unter Bereit zur Registrierung zur Verfügung. Der Genemigungsablauf kann analog zu den PDF-Dokumenten verwendet werden.

ZUGFeRD

Bei ZUGFeRD handelt es sich um eine hybride Form von Belegen, d.h., der Beleg besteht aus einer PDF-Datei und eine im Anhang beigefügte XML-Datei. In der Belegkategorie kann mandantenweit folgende Einrichtung vorgenommen werden, mit der Sie entscheiden, ob der PDF-Teil (OCR-Erkennung) verarbeitet wird oder die XML-Datei zur Anwendung kommt:

Arbeiten Sie mit der XML-Datei, dann wird abhängig von der ZUGFeRD Datei, u. U. die Mastervorlage XRECH-CII verwendet. Wenn diese Vorlage zum Einsatz kommt, dann ist die Mastervorlage anzupassen. Folgen Sie dazu den Anweisung des Kapitels XML-Einkaufsbelege.

Ein Viewer zur Visualisierung der Rechnung steht hier zur Verfügung. Alternativ kann das PDF angezeigt werden, dazu ist in der Identifikations-Mastervorlage die Option Eingebettete PDF-Datei als Standard anzeigen zu aktivieren.

3 - konfipay-Service Integrator

Einführung

Mit dem Webservice konfipay der windata GmbH & Co.KG (https://www.konfipay.de/) können Sie Ihre Geschäftsprozesse im digitalen Zahlungsverkehr automatisieren und sicher gestalten. Als Dienstleister verfügt windata (https://www.windata.de/) über höchste Sicherheitsstandards (EBICS / ISO 20022 und Rechenzentren in Deutschland) und übernimmt die Übertragung Ihrer Zahlungsaufträge und den Abruf Ihrer Kontoumsätze.

Einrichtung

Um die Konfipay-Erweiterung einzurichten, können Sie die Konfipay Unterstützte Einrichtung auf der Seite Unterstützte Einrichtung in RELion starten. Sie starten die Seite über Einstellungen. Mit dieser unterstützten Einrichtung können Sie alle erforderlichen Informationen für die weitere Arbeit mit der Erweiterung einrichten.

Hinweis

Bevor Sie mit Konfipay arbeiten können, müssen Sie für das Zusatzmodul eine Lizenz beantragen.

Folgende Einstellungen müssen vom Benutzer bereitgestellt werden, um mit der RELion Konfipay Erweiterung arbeiten zu können:

Die folgenden Einstellungen werden im Konfipay-Einrichtungsassistent standardmäßig als funktionierende Konfipay-API-Einstellungen bereitgestellt. Derzeit ist keine Änderung dieser Werte erforderlich. Eine Änderungsmöglichkeit ist jedoch vorgesehen, falls die Werte in Zukunft auf der Konfipay-Seite angepasst werden, sodass sie auch in der RELion Konfipay Erweiterung angepasst werden können:

• Api Basis URL
• Pain Api Endpunkt
• Camt Api Endpunkt
• MT940 Api Endpunkt

Im Konfipay-Einrichtungsassistent können Sie automatisch das Senden von Pain-Format Zahlungsdateien von Business Central an Konfipay nach Erstellung einer Zahlungsdatei in den Debitoren- oder Kreditoren-Zahlungen aktivieren oder Sie können das nachträgliche Senden von Pain-Format Zahlungsdateien aktivieren, welches später manuell oder durch die Aufgabenwarteschlange erfolgen muss.

Die Aktivierung oder Deaktivierung des Imports von Camt- und MT940-Zahlungsdateien kann ebenfalls im Konfipay-Einrichtungsassistent festgelegt werden. Sie können die Einstellungen auch direkt auf der Seite Konfipay Einrichtung vornehmen. Alle Standardwerte werden automatisch ausgefüllt, wenn die Seite geöffnet wird. Darüber hinaus stehen auf der Seite folgende Aktionen zur Verfügung:

Integration Zahlungsprotokolleinträge

Die Integration Zahlungsprotokolleinträge ist der zentrale Speicherort für eingehende (Camt und MT940) und ausgehende (ISO20022 Pain) Zahlungsdateiinformationen. Einträge werden hier entweder durch den Import von Zahlungsdateien von Konfipay oder durch das Erzeugen von Zahlungsdateien in den Debitoren- oder Kreditoren-Zahlungen erstellt. Direkt von der Integration Zahlungsprotokolleinträge können Sie die Sende- und Importprozesse für Zahlungsdateien starten sowie zu Kontoauszug, Aufgabenwarteschlange, Zahlungsdateiinhalte, Konfipay-Einrichtung navigieren.

Die Seite enthält folgende Felder:

Es ist auch möglich, von der Seite Integration Zahlungsprotokolleinträge Zahlungsdateien in einer einzelnen ZIP-Datei herunterzuladen, indem Sie die benötigten Einträge auswählen und die Funktion Dateien herunterladen anklicken. Außerdem kann die Antwort von Konfipay überprüft werden, indem die Aktionen Anfragedaten anzeigen oder Antwortdaten anzeigen angeklickt werden.

Import von Konfipay-Zahlungsdateien und Weiterverarbeitung in Importierte Kontoauszüge – Global

Der Import von Zahlungsdateien erfolgt pro IBAN. Daher wurde ein neues Feld mit dem Namen Provider Typ zur Bankkonto-Karte und zur Bankkonto-Liste hinzugefügt. Stand jetzt gibt es nur zwei Optionen in diesem Feld: „ “ und Konfipay. Der Provider Typ mit dem Wert Konfipay darf für jede IBAN nur einmal in einem Bankkonto gesetzt werden. Wird eine IBAN beispielsweise in mehren Bankkonten verwendet und es wurde bereits eines dieser Bankkonten für Konfipay aktiviert, ist es nicht mehr möglich, bei den anderen Bankkonten mit derselben IBAN ebenfalls die Option Konfipay zu setzen.

Es gibt manuelle und automatische Wege, um Zahlungsdateien von Konfipay zu importieren. Beide Wege funktionieren nur, wenn der Import von Dateien in der Konfipay Einrichtung aktiviert ist:

Um Dateien manuell zu importieren, öffnen Sie die Seite Integration Zahlungsprotokolleinträge und klicken im Menü Konfipay auf die Aktion Zahlungsdateien importieren. Die Zahlungsdateien werden dann in die Zahlungsprotokolleinträge importiert. Wenn keine Fehler auftreten, sind die Zahlungsprotokolleinträge bereit, weiter in Importierte Kontoauszüge – Global verarbeitet zu werden. Andernfalls erhalten die Zahlungsprotokolleinträge den Status fehlgeschlagen mit einem angegebenen Fehlertext.

Um Dateien mit der Aufgabenwarteschlange zu importieren, aktivieren Sie die Aufgabenwarteschlange in der Konfipay Einrichtung.

Nachdem alle Zahlungsdateien importiert wurden, können sie weiter in Importierte Kontoauszüge – Global verarbeitet werden. Dies kann ebenfalls auf zwei Arten erfolgen:

Um Dateien manuell in Importierte Kontoauszüge – Global zu importieren, wählen Sie die benötigten Einträge in Zahlungsprotokolleinträge aus und klicken auf die Aktion Import in Kontoauszüge.

Um Dateien mit der Aufgabenwarteschlange zu importieren, aktivieren Sie die Aufgabenwarteschlange durch Auswählen der Aktion Zeitplan Import Kontoauszügen Aufgabenwarteschlange auf der Seite Zahlungsprotokolleinträge und ändern Sie die Standardeinstellungen bei Bedarf.

Hinweis

Die Aufgabenwarteschlange für den Import in Kontoauszüge soll vor der Aufgabenwarteschlange für den Dokumentenimport aus Konfipay laufen.

Nachdem die Zahlungsprotokolleinträge in Kontoauszüge importiert wurden, sind diese beiden Entitäten miteinander verknüpft. Der verknüpfte Eintrag kann durch Anklicken der Aktion Kontoauszug auf der Seite Zahlungsprotokolleinträge angezeigt werden.

Falls der Import der Zahlungsprotokolleinträge in die Kontoauszüge fehlschlägt, wird der Status des Zahlungsprotokolleintrags auf Fehler geändert. Nachdem das Problem behoben wurde, kann der Status mit der Aktion Status zurücksetzen wieder auf Importiert gesetzt werden und Sie können den Import erneut durchzuführen.

ISO20022 Pain-Zahlungsdateien senden

Es gibt folgende Möglichkeiten, Pain-Zahlungsdateien an Konfipay zu senden:

Wenn in der Konfipay Einrichtung das Senden von Pain-Dateien aktiviert ist Sie eine Zahlungsdatei in Debitoren- oder Kreditoren Zahlungen erstellen, wird ein neuer Eintrag in Integration Zahlungsprotokolleinträge generiert. Anschließend markieren Sie den Eintrag und senden ihn an Konfipay, indem Sie die Aktion Pain-Datei senden in Zahlungsprotokolleinträge auswählen. Das Gleiche können Sie auf der Seite Debitoren- oder Kreditoren Zahlungen mit der Aktion Senden an Konfipay machen.

Anschließend können Sie die Datei automatisch über die Aufgabenwarteschlange an Konfipay senden, die in der Konfipay Einrichtung durch Anklicken der Aktion Zeitplan Senden Dokumente Aufgabenwarteschlange eingerichtet werden kann.

Eine Zahlungsdatei kann auch sofort automatisch nach der Erstellung in Debitoren- oder Kreditoren Zahlungen an Konfipay gesendet werden, wenn Sie die Funktion Dokumente automatisch senden in der Konfipay Einrichtung auf Ja setzen.

Hinweis

Sie haben die Möglichkeit, in der RELion Core-Erweiterung eine in Debitoren- oder Kreditoren Zahlungen erstellte Zahlungsdatei zu stornieren. Falls bereits Zahlungsprotokolleinträge zur Übermittlung dieser Datei an Konfipay erstellt wurden, wird der Status des Eintrags auf Storniert gesetzt. Wenn die Datei jedoch bereits an Konfipay gesendet wurde, erscheint vor der Stornierung der Zahlungsdatei nur eine Warnung. Es ist nicht möglich, eine Zahlungsdatei von der Bank zurückzuziehen, nachdem sie von Konfipay verarbeitet wurde.

4 - DATEV Connector

Einführung

Der RELion DATEV Connector ist ein Modul, der erweitert die Funktionalitäten der Sievers© Exportschnittstelle zu DATEV (https://www.sievers-group.com/datev-schnittstelle) von der SIEVERS-SNC Computer & Software GmbH & Co. KG.

In Microsoft Dynamics Business Central stellt ein Mandant eine Gesellschaft dar. Die DATEV-Schnittstelle vom Hersteller Sievers exportiert grundsätzlich alle Stammdaten und Posten aus einem Mandanten und läuft in ihrer Formalprüfung auch immer alle Stammdatensätze durch.

Durch die Branchenlösung RELion ist es ermöglicht worden, mehrere Gesellschaften innerhalb eines Mandanten zu buchen. Die Gesellschaften sind im RELion durch die Zuständigkeitseinheit gekennzeichnet. Das Kontenmapping für Sachkonten, Debitoren und Kreditoren kann pro Zuständigkeitseinheit definiert werden, um die Daten für den jeweiligen Empfänger aufzubereiten. Der Export lässt sich auf die Daten einer oder mehrere Zuständigkeitseinheiten filtern. Bei teiloptierten Objekten ist der Bruttoexport der DATEV-Schnittstelle nicht sinnvoll nutzbar. Hier muss mit der Netto-Methode gearbeitet werden. Der allgemein Arbeitsprozess ist:

• DATEV Empfänger anlegen für jede Zuständigkeitseinheit
• DATEV Einrichtung für jeden Empfänger erstellen
• RE Datev Kontenplan Mapping für jeden Empfänger einrichten
• RE Datev Debitoren Export Mapping für jeden Empfänger einrichten
• RE Datev Kreditoren Export Mapping für jeden Empfänger einrichten
• RE Formalprüfung ausführen
• RE Datev Export ausführen  

Suchoptionen

Alle DATEV Funktionen finden Sie im Webclient über die Suchfunktion.

Zusätzlich können Sie die Funktionen aus dem RELion Menü ausführen.

Berechtigungssätze

Es gibt zwei DATEV Berechtigungssätze, einen von SIEVERS und einen von RELion. Diese Sätze müssen jedem Benutzer, der mit dem DATEV Connector arbeitet und keine SUPER Rechte hat, hinzugefügt werden.

Einrichtung

DATEV-Empfänger

Die Liste der DATEV-Empfänger ist die zentrale Stelle, von der aus die DATEV-Schnittstelle für RELion eingerichtet und bedient wird.

Der DATEV-Empfänger wird definiert über einen Code im Feld DATEV-Empfänger Code und eine frei definierbare Beschreibung. Im Feld Zuständigkeitseinheit können Sie die ZE auswählen.

DATEV Einrichtung erstellen

Jeder DATEV-Empfänger muss mit einer eigenen Einrichtung verknüpft werden. Um die Einrichtung zu erstellen öffnen Sie die Funktion Datev Einrichtungen.

Eine neue Einrichtung mit Standardoptionen wird automatisch erstellt.

Öffnen Sie die Einrichtung und prüfen die Einstellungen in den Bereichen Allgemein und Export und passen es, falls notwendig, an.

Prüfen Sie insbesondere den Wert des Feldes RE Datev Empfänger: Datev Kontonummernlänge. In dieses Feld muss für jeden Empfänger die Datev Kontonummernlänge eingetragen werden. Der Wert darf vom Wert der Sievers DATEV Kontonummernlänge abweichen und wird nur mit RE Datev Export pro Zuständigkeit verwendet.

Vor dem RE Datev Export richten Sie die folgenden Felder ein:

• Datev Empfänger Kontomapping
• DebitorenKontomapping
• KreditorenKontomapping

Bitte beachten Sie, dass sämtliche Einrichtungen zum Empfänger gespeichert werden und bei verschiedenen Empfängern für jeden Empfänger separat einzurichten sind.

Hinweis

Der Wert des Feldes Datev Kontonummernlänge muss in jeder Datev Einrichtung für jeden RELion Datev Empfänger gleich sein.

Tipp

Aktivieren Sie die Option Buchungsbeschreibung mit mehr als 60 Zeichen kürzen in jeder Datev Einrichtung und für jeden RELion Datev Empfänger.

RE Datev Kontenplan Mapping einrichten

Für jeden DATEV-Empfänger muss die Tabelle RE Datev Kontenplan Mapping eingerichtet werden. Dazu öffnen Sie die Funktion Kontomapping ausführen.

Bei erstmaligen Start der Seite werden die Konten, die in der ZE gebucht wurden, initialisiert, der DATEV Empfänger ist bereits gefiltert.

Die DATEV Kontoart und die DATEV Kontonr. können Sie nun einrichten.

Diese Arbeiten nehmen Sie für jeden DATEV-Empfänger vor, auch dann, wenn für alle Empfänger mit der gleichen Einrichtung gearbeitet werden soll. Diese Einrichtung ersetzt die übliche DATEV-Einrichtung am Sachkontostammdaten.

Über die Funktion Sachkonten ergänzen können Sie ein Sachkonto dem RE Datev Kontenplan Mapping hinzufügen.

Diese Ergänzung kann notwendig sein, wenn das Konto für DATEV von Bedeutung ist aber in RELion noch nichts gebucht wurde. (z. B., wenn Kontonr. Saldenverrechnung dem DATEV Einrichtung hinzugefügt wird).

RE Datev Debitoren Export Mapping einrichten

Für jeden DATEV-Empfänger muss die Tabelle RE Datev Debitoren Export Mapping eingerichtet werden. Dazu wählen Sie die Funktion DebitorenKontomapping.

Die Einrichtung der Tabelle für die Debitoren erfolgt analog der Einrichtung RE Datev Kontenplan Mapping.

Die Datev Kontennummern können entweder manuell zugewiesen oder durch Hilfsfunktionen angereichert werden:

Diese Arbeiten nehmen Sie für jeden DATEV-Empfänger vor. Auch dann, wenn für alle Empfänger mit der gleichen Einrichtung gearbeitet werden soll. Diese Einrichtung ersetzt die übliche DATEV-Einrichtung an Debitorenstammdaten. Mit der Funktion Debitoren ergänzen kann ein Debitor dem RE Datev Debitoren Export Mapping hinzugefügt werden.

Diese Ergänzung könnte notwendig sein, wenn eine Ersatz Debitornr. der DATEV Einrichtung hinzugefügt wird:

RE Datev Kreditorenkonten einrichten

Für jeden DATEV-Empfänger richten Sie die Tabelle RE Datev Kreditoren Export Mapping ein. Dazu öffnen Sie die Funktion KreditorenKontomapping.

Die Einrichtung der Tabelle für die Kreditoren erfolgt analog der Einrichtung RE Datev Kontenplan Mapping.

Die Konten können entweder manuell zugewiesen oder durch Hilfsfunktionen angereichert werden:

Diese Arbeiten nehmen Sie für jeden DATEV-Empfänger vor. Auch dann, wenn für alle Empfänger mit der gleichen Einrichtung gearbeitet werden soll. Diese Einrichtung ersetzt die übliche DATEV-Einrichtung an Kreditorenstammdaten. Mit der Funktion Kreditoren ergänzen kann ein Kreditor dem RE Datev Kreditoren Export Mapping hinzugefügt werden.

Diese Ergänzung kann notwendig sein, wenn Ersatz Kreditornr. der DATEV Einrichtung hinzugefügt wird.

Export ausführen

Export der Daten

Um Export der Daten zu starten, führen Sie die Funktion Datev Export durchführen aus.

Die entsprechende DATEV Einrichtung wird geöffnet. Prüfen Sie die Stammdaten vor dem Export über die Funktion RE Formalprüfung.

Es wird geprüft, ob im Kontenmapping des Datev Empfängers jedes Sachkonto, die in der Einrichtung zur DATEV hinterlegten Kontonummernlänge, vorhanden ist. Ist eine DATEV Kontonr. eingetragen, wird nur diese geprüft.

Die Datev Debitoren- und Kreditorennummern müssen mit einer Ziffer von 1 bis 9 beginnen und eine Ziffer länger sein als die Sachkontonummern. Das Feld Name soll in allen Stammdaten einen numerischen Wert enthalten.
Das Ergebnis der Formalprüfung wird als Protokoll angezeigt und überschreibt ein evtl. vorhandenes Protokoll:

Anschließend erscheint eine Mitteilung, dass die Prüfung ohne Fehler beendet wurde.

Mit der Aktion RE Export starten werden die Daten von der DATEV-Einrichtung zum Empfänger exportiert.

Der Ablauf ist, mit Ausnahme der abweichenden Ausgangsposition vom Empfänger aus für den DATEV-Export gegenüber dem Standardprozess nicht anders als gewohnt. Die Exporteinstellungen können vor der Verarbeitung noch angepasst werden:

Die Exportergebnisse werden als Protokoll angezeigt und überschreibt ein evtl. vorhandenes Protokoll. Die Export Datei- wird im Download-Ordner Benutzers Browsers gespeichert. Wenn es mehrere Export-Dateien (Stammdaten, Sachkontobeschriftungen, Buchungen) gibt, werden sie alle in einer ZIP-Datei gesammelt:

DATEV-Abrechnungen

Von der Liste der DATEV-Empfänger ausgehend, kann eine empfängerbezogene Ansicht der durchgeführten Exporte aufgerufen werden:

Hier stehen die gewohnten Daten und Aktionen, wie Annulliere Zeile oder Annulliere letzte Zeile zur Verfügung, mit dem Unterschied, dass diese Funktionen zum gefilterten Empfänger ausgeführt werden.

5 - Aareon Connect in Microsoft Entra ID

Azure-Portal

Verwenden Sie das Azure-Portal, um die Aareon Connect Anwendung für Business Central bzw. RELion auf Ihrem Microsoft Entra Mandanten zu registrieren. Im Rahmen der Registrierung gewähren Sie den entsprechenden Diensten auch Zugriff auf die Anwendung. Der Zweck der Registrierung besteht darin, sicherzustellen, dass Business Central lokal und die Dienste die Microsoft Entra ID-Details des jeweils anderen kennen.

In den folgenden Schritten wird beschrieben, wie Sie eine neue Anwendung registrieren. Wenn Sie jedoch die Microsoft Entra Authentifizierung verwenden, haben Sie bereits eine registrierte Anwendung für Business Central.

Folgende Schritte müssen ausgeführt werden:

1. Melden Sie sich beim Azure-Portal an, und registrieren Sie eine Anwendung für Aareon Connect im Microsoft Entra Mandanten. Befolgen Sie die allgemeinen Richtlinien unter Registrieren Ihrer Anwendung bei Ihrem Microsoft Entra Mandanten. Wenn Sie einem Microsoft Entra Mandanten eine Anwendung hinzufügen, müssen Sie die folgenden Informationen angeben:

Wichtig

Die URL muss mit der URL des Webclients übereinstimmen, wie sie in der Browseradresse des Computers angezeigt wird, an dem Sie arbeiten. Auch wenn die tatsächliche URL beispielsweise lauten könnte, entfernt der Browser normalerweise die Portnummer.

Nach Abschluss des Vorgangs wird im Portal eine Übersicht für die neue Anwendung angezeigt.

Kopieren Sie die Anwendungs-ID (Client-ID), der die Anwendung zugewiesen wurde, sowie die von Ihnen angegebene Umleitungs-URL. Sie werden diese Informationen später verwenden.

2. Erstellen Sie einen geheimen Clientschlüssel für die registrierte Aareon Connect Anwendung. Befolgen Sie die allgemeinen Richtlinien zu Ihrer Webanwendung.

Bevor Sie die Seite Zertifikate und Geheimnisse verlassen, kopieren Sie den Wert des Geheimnisses (Secret ID) an einen temporären Speicherort. Auf den Wert können Sie nicht mehr zugreifen, sobald Sie die Seite verlassen. Sie benötigen diesen Schlüssel, um es später an das Aareon Connect Team zu kommunizieren.

3. Erteilen Sie der registrierten Anwendung delegierte Berechtigungen für den Zugriff auf die erforderlichen Dienst-APIs (z. B. API.ReadWrite.all und Automation.ReadWrite.All für Dynamics 365 Business Central und User.Read für Microsoft Graph). Wählen Sie auf der Übersichtsseite der registrierten Anwendung API-Berechtigungen > Berechtigung hinzufügen aus. Verwenden Sie dann den Bereich API-Berechtigungen anfordern, um die API zu suchen und Berechtigungen hinzuzufügen.

Weitere Informationen finden Sie in der Azure-Dokumentation.

4. Konfigurieren Sie die Zustimmung für jede API-Berechtigung gemäß den Richtlinien Ihrer Organisation. Die Zustimmung ist ein Prozess, bei dem Benutzer oder Administratoren einer Anwendung den Zugriff auf eine Ressource autorisieren, z. B. das Profil oder das Postfach eines Benutzers, je nach Dienst. Wenn ein Benutzer zum ersten Mal versucht, sich bei der registrierten App anzumelden, fordert die App die Berechtigung an, und der Benutzer muss zustimmen, um fortzufahren. Als Administrator können Sie im Namen aller Benutzer zustimmen, damit sie dies nicht tun müssen.

Weitere Informationen finden Sie hier zu API-Berechtigungen und Einführung in Berechtigungen und Einwilligung.  

Einrichtung in RELion

Nachdem Sie die Anwendungsregistrierung erstellt haben, besteht die nächste Aufgabe darin, den Business Central-Mandanten für die Verwendung zu konfigurieren.

Sie benötigen die folgenden Informationen zur Anwendungsregistrierung:

• Umleitungs-URL
• Anwendungs-ID (Client-ID)
• geheimer Clientschlüssel.

Zudem benötigen Sie Informationen zur App RELion Aareon Connect.

• Dazu wählen Sie in Business Central die Suche 🔍 aus und geben Erweiterungsverwaltung ein.
• Aus der Liste Aareon Connect auswählen.
• Die Seite in die maximale Breite vergrößern, um Informationen komplett zu sehen.
• Notieren Sie sich die App-ID und den Name.

Danach die folgenden Schritte:

1. Wählen Sie in der oberen rechten Ecke das Symbol 🔍 aus, geben Microsoft Entra Anwendungen ein und wählen Sie dann den zugehörigen Link aus.

2. Wählen Sie Microsoft Entra Anwendungen aus, dann wird die Microsoft Entra Anwendungen geöffnet.
3. Wählen Sie den Menüpunkt Neu.
4. Geben Sie im Feld Client ID die Anwendungs-ID (Client-ID) der Aareon Connect Anwendung in Microsoft Entra-ID an, die Sie in der vorherigen Aufgabe kopiert haben.
5. Tragen Sie im Feld Beschreibung Aareon Connect ein.
6. Im Feld App-ID unter Extension tragen Sie die ID des Aareon Connects ein und im Feld App-Name, der Name des Aareon Connects.

Wichtig

Unter User Information wird automatisch eine Benutzer ID und einen Benutzername definiert.

7. Im Inforegister Benutzerberechtigungssätze wählen Sie bitte folgenden Berechtigungssätze aus:

• D365 AUTOMATION
• EXTEN. MGT. – ADMIN
• RELion Berechtigungssätze

Die Aareon Connect Anwendung ist nun registriert und bereit, eine Verbindung mit dem Aareon Connect Partnersystem herzustellen.

Bitte informieren Sie Ihren Ansprechpartner für die Integration und stellen Sie über gesicherte Wege die Informationen (Client-Id, Client-Secret, Redirect URI usw.) zur Verfügung, damit das Partnersystem via Aareon Connect mit RELion kommunizieren kann.

6 - Archiv kompakt (AAk)

Anleitungen, die Sie bei der Archiv kompakt (AAK) Anbindung unterstützen. Anhand drei Scenarien werden Ihnen die Einrichtung der Authentifizierung erklärt.

6.1 - Benutzer Synchronisierung mit Mandantenberechtigung

Anhand drei Scenarien werden Ihnen die Einrichtung der Authentifizierung erklärt.

6.1.1 - Neustart mit RELion und Archiv kompakt

Einrichtung der Authentifizierung (OAuth2 als S2S)

Um die Authentifizierung mittels OAuth2 als Server-zu-Server (S2S) einzurichten, ist es erforderlich, dass die Archiv kompakt Microsoft Entra Applikation korrekt in Azure registriert und in RELion aktiviert ist. Dies beinhaltet die Überprüfung und Anpassung der Einstellungen für die RELion Archiv kompakt Connector Extension gemäß der Dokumentation zu Microsoft Entra Archiv kompakt.

Für den Zugriff auf die notwendigen Informationen zur RELion Archiv kompakt Connector Extension in Business Central, nutzen Sie die Suchfunktion, indem Sie auf die Lupe in der rechten oberen Ecke klicken und Erweiterungsverwaltung eingeben. Wählen Sie aus der Liste die RELion Archiv kompakt Connector aus. Vergrößern Sie die Seite, um alle Informationen einsehen zu können, und notieren Sie sich die App-ID sowie den Namen der Applikation. Diese Informationen sind für die weitere Konfiguration und Nutzung der S2S-Authentifizierung essentiell.

Wie die Archiv kompakt Entra Application einzurichten ist, finden Sie hier: Einrichtung Entra-ID

Mit der Installation des neuen RELion Archiv kompakt Connector sind zwei Berechtigungssätze ausgeliefert:

• RELAAK Basic
• RELAAK Extended

Schritt 1 – Archiv kompakt Entra Application vorbereiten

Die Integration von Berechtigungssätzen wie RELAAK Basic und RELAAK Extended ist entscheidend für die Funktionalität und Sicherheit der Archiv kompakt Applikation innerhalb von RELion. Diese Berechtigungssätze ermöglichen es den Nutzern, auf die erforderlichen Module und Funktionen zuzugreifen, während gleichzeitig die Integrität und der Schutz sensibler Daten gewährleistet werden.

Bitte hinterlegen Sie diese neuen Berechtigungssätzen in Ihrem Archiv kompakt Entra Application entweder manuell ein oder per aktivieren/deaktivieren des Schalters Aktiviert auf der RELion Dokument Einrichtung Seite.

Für die manuelle Einrichtung öffnen Sie über die Suche die Funktion Entra. Wählen Sie aus der Liste die Microsoft Entra Anwendungen aus, dann auf die Zeile Archiv kompakt und klicken auf bearbeiten. Hier Können Sie in den Berechtigungssätzen die zwei neue Berechtigungssätze RELAAK Basic und RELAAK Extended hinzufügen.

Bei der Automatisierung öffnen Sie über die Suche RE Dok Einrichtung. Wählen Sie aus der Liste die RELion Dokument Einrichtung aus, anschließend klicken Sie auf den Schalter Aktiviert um zu deaktivieren bzw. aktivieren der Archivierung. Bei dieser Aktion werden beide Berechtigungssätze bei der Archiv kompakt Entra Applikation automatisch hinterlegt.

Benutzername aus der Archiv kompakt Entra Application in Archiv kompakt Manager hinterlegen

Bitte öffnen Sie wieder die Entra Application Seite und kopieren in die Zwischenablage den Benutzername.

Öffnen Sie den Archiv kompakt Manager und wählen im Menüband Benutzer aus, dann klicken Sie auf Neue Benutzer.

Fügen Sie den Benutzernamen aus der Zwischenablage ein.

Setzen Sie den Haken bei Administrator ordnen Sie die administrative Berechtigungsgruppe zu.

Schritt 2 – RELion Benutzer in Archiv kompakt anlegen

Benutzer, die in Archiv kompakt angelegt werden sollen, werden dem Berechtigungssatz RELAAK Basic zugeordnet. Gegebenfalls dem Mandant zuordnen, falls der Benutzer Berechtigungen nur in einem bestimmten Mandant haben sollte.

Bitte gehen Sie wie folgt vor:

• Wählen Sie über die Suchfunktion Benutzer und öffnen die Seite Benutzer.

• Wählen Sie in der Tabelle einen Benutzer aus, den Sie in Archiv kompakt anlegen möchten.

• Wählen Sie in den Berechtigungssätzen, den Berechtigungssatz [RELAAK Basic] aus. Dazu klicken Sie in einer Zeile auf die drei Punkte um weitere Optionen anzeigen zu lassen. Falls der Benutzer nur für bestimmte Mandanten berechtigt ist zu archivieren, bitte auch den Mandant in der Spalte Mandant hinterlegen.

• Schließen Sie die Benutzerkarte und gehen Sie gleich vor für alle Benutzer, die Sie in Archiv kompakt anlegen möchten.

Nachdem Sie alle Benutzer, die Sie in Archiv kompakt benötigen, eingerichtet haben, besteht die nächste Aufgabe darin, die eingerichteten Benutzer nach Archiv kompakt anzulegen.

Dazu gehen Sie wie folgt vor:

• Wählen Sie über die Suchfunktion RELion Dokument Einrichtung und öffnen die Seite.

• Wählen Sie im Menüband Aktionen die Funktion Anlegen RELion Benutzer.

Folgend werden alle Benutzer, die Sie bei dem Schritt davor eingerichtet haben, in Archiv kompakt mit folgende Informationen angelegt:

Bitte lesen Sie folgende Information und bestätigen mit Ja.

Anschließend geben Sie ein Initial-Passwort ein, das im Moment gültig ist für die Benutzer, die im Archiv kompakt angelegt werden. Bitte beachten Sie die Komplexitätsregel des Archiv kompakt Servers.

Wichtig

Benutzer informieren über die Zugangsdaten. Das Passwort muss nach erst Anmeldung in Archiv kompakt geändert werden von den jeweiliger Benutzer.

Zum Schluss berechtigen Sie Ihren Benutzern in Archiv kompakt, in dem Sie zu ihn einer Gruppe zuordnen.

Wichtig

RELion gibt vor welcher Benutzer ein Archiv kompakt Benutzer sein darf und seine Berechtigungen. Ein Freier Benutzer, der nur Archiv kompakt Benutzer sein kann, wird nicht mehr unterstützt.

6.1.2 - Update RELion ONE bei Companial

Einrichtung der Authentifizierung (OAuth2 als S2S)

Um die Authentifizierung mittels OAuth2 als Server-zu-Server (S2S) einzurichten, ist es erforderlich, dass die Archiv kompakt Microsoft Entra Applikation korrekt in Azure registriert und in RELion aktiviert ist. Dies beinhaltet die Überprüfung und Anpassung der Einstellungen für die RELion Archiv kompakt Connector Extension gemäß der Dokumentation zu Microsoft Entra Archiv kompakt.

Für den Zugriff auf die notwendigen Informationen zur RELion Archiv kompakt Connector Extension in Business Central, nutzen Sie die Suchfunktion, indem Sie auf die Lupe in der rechten oberen Ecke klicken und Erweiterungsverwaltung eingeben. Wählen Sie aus der Liste die RELion Archiv kompakt Connector aus. Vergrößern Sie die Seite, um alle Informationen einsehen zu können, und notieren Sie sich die App-ID sowie den Namen der Applikation. Diese Informationen sind für die weitere Konfiguration und Nutzung der S2S-Authentifizierung essentiell.

Wie die Archiv kompakt Entra Application einzurichten ist, finden Sie hier: Einrichtung Entra-ID

Mit der Installation des neuen RELion Archiv kompakt Connector sind zwei Berechtigungssätze ausgeliefert:

• RELAAK Basic
• RELAAK Extended

Schritt 1 – Archiv kompakt Entra Application vorbereiten

Die Integration von Berechtigungssätzen wie RELAAK Basic und RELAAK Extended ist entscheidend für die Funktionalität und Sicherheit der Archiv kompakt Applikation innerhalb von RELion. Diese Berechtigungssätze ermöglichen es den Nutzern, auf die erforderlichen Module und Funktionen zuzugreifen, während gleichzeitig die Integrität und der Schutz sensibler Daten gewährleistet werden.

Bitte hinterlegen Sie diese neuen Berechtigungssätzen in Ihrem Archiv kompakt Entra Application entweder manuell ein oder per aktivieren/deaktivieren des Schalters Aktiviert auf der RELion Dokument Einrichtung Seite.

Für die manuelle Einrichtung öffnen Sie über die Suche die Funktion Entra. Wählen Sie aus der Liste die Microsoft Entra Anwendungen aus, dann auf die Zeile Archiv kompakt und klicken auf bearbeiten. Hier Können Sie in den Berechtigungssätzen die zwei neue Berechtigungssätze RELAAK Basic und RELAAK Extended hinzufügen.

Bei der Automatisierung öffnen Sie über die Suche RE Dok Einrichtung. Wählen Sie aus der Liste die RELion Dokument Einrichtung aus, anschließend klicken Sie auf den Schalter Aktiviert um zu deaktivieren bzw. aktivieren der Archivierung. Bei dieser Aktion werden beide Berechtigungssätze bei der Archiv kompakt Entra Applikation automatisch hinterlegt.

Benutzername aus der Archiv kompakt Entra Application in Archiv kompakt Manager hinterlegen

Bitte öffnen Sie wieder die Entra Application Seite und kopieren in die Zwischenablage den Benutzername.

Öffnen Sie den Archiv kompakt Manager und wählen im Menüband Benutzer aus, dann klicken Sie auf Neue Benutzer.

Fügen Sie den Benutzernamen aus der Zwischenablage ein.

Setzen Sie den Haken bei Administrator ordnen Sie die administrative Berechtigungsgruppe zu.

Schritt 2 – RELion Benutzer in in Archiv Kompakt umbenennen und den RELAAK Basic Berechtigungssatz hinterlegen

Bitte gehen Sie wie folgt vor:

• Wählen Sie über die Suchfunktion RELion Dokument Einrichtung und öffnen die Seite.

• Wählen Sie im Menüband Aktionen die Funktion Benutzer Upgrade und Synchronisiere RELion Benutzer.

Folgend wird allem Benutzern aus der Tabelle Benutzerzuordnung den Berechtigungssatz (RelAAK Basic) hinterlegt und anschließend wird der Archiv kompakt Benutzername in RELion Benutzername umbenannt. Alle anderen Informationen bleiben unverändert in Archiv kompakt.

Nachdem diesen Schritt erfolgreich abgeschlossen wurde, können Sie sich im Archiv kompakt Client bzw. Manager mit dem RELion Benutzername anmelden und die Tabelle Benutzerzuordnung in RELion leeren.

Dazu gehen Sie wie folgt vor:

• Wählen Sie über die Suchfunktion RELion Dokument Einrichtung und öffnen die Seite.

• Klicken Sie auf die Anzahl im Feld Benutzerzuordnung und es öffnet sich die Seite Archiv kompakt Benutzerzuordnung.

• Wählen Sie den ersten Benutzer bzw. erste Zeile aus und klicken auf die drei Punkte um weitere Zeilen auszuwählen. Nachdem alle Zeilen markiert worden sind, klicken Sie auf den Button Löschen. Dadurch werden alle Datensätze in der Tabelle Benutzerzuordnung gelöscht.

Wichtig

RELion gibt vor welcher Benutzer ein Archiv kompakt Benutzer sein darf und seine Berechtigungen. Ein Freier Benutzer, der nur Archiv kompakt Benutzer sein kann, wird nicht mehr unterstützt.

6.1.3 - Migration zu Saas

Einrichtung der Authentifizierung (OAuth2 als S2S)

Um die Authentifizierung mittels OAuth2 als Server-zu-Server (S2S) einzurichten, ist es erforderlich, dass die Archiv kompakt Microsoft Entra Applikation korrekt in Azure registriert und in RELion aktiviert ist. Dies beinhaltet die Überprüfung und Anpassung der Einstellungen für die RELion Archiv kompakt Connector Extension gemäß der Dokumentation zu Microsoft Entra Archiv kompakt.

Für den Zugriff auf die notwendigen Informationen zur RELion Archiv kompakt Connector Extension in Business Central, nutzen Sie die Suchfunktion, indem Sie auf die Lupe in der rechten oberen Ecke klicken und Erweiterungsverwaltung eingeben. Wählen Sie aus der Liste die RELion Archiv kompakt Connector aus. Vergrößern Sie die Seite, um alle Informationen einsehen zu können, und notieren Sie sich die App-ID sowie den Namen der Applikation. Diese Informationen sind für die weitere Konfiguration und Nutzung der S2S-Authentifizierung essentiell.

Wie die Archiv kompakt Entra Application einzurichten ist, finden Sie hier: Einrichtung Entra-ID

Mit der Installation des neuen RELion Archiv kompakt Connector sind zwei Berechtigungssätze ausgeliefert:

• RELAAK Basic
• RELAAK Extended

Schritt 1 – Archiv kompakt Entra Application vorbereiten

Die Integration von Berechtigungssätzen wie RELAAK Basic und RELAAK Extended ist entscheidend für die Funktionalität und Sicherheit der Archiv kompakt Applikation innerhalb von RELion. Diese Berechtigungssätze ermöglichen es den Nutzern, auf die erforderlichen Module und Funktionen zuzugreifen, während gleichzeitig die Integrität und der Schutz sensibler Daten gewährleistet werden.

Bitte hinterlegen Sie diese neuen Berechtigungssätzen in Ihrem Archiv kompakt Entra Application entweder manuell ein oder per aktivieren/deaktivieren des Schalters Aktiviert auf der RELion Dokument Einrichtung Seite.

Für die manuelle Einrichtung öffnen Sie über die Suche die Funktion Entra. Wählen Sie aus der Liste die Microsoft Entra Anwendungen aus, dann auf die Zeile Archiv kompakt und klicken auf bearbeiten. Hier Können Sie in den Berechtigungssätzen die zwei neue Berechtigungssätze RELAAK Basic und RELAAK Extended hinzufügen.

Bei der Automatisierung öffnen Sie über die Suche RE Dok Einrichtung. Wählen Sie aus der Liste die RELion Dokument Einrichtung aus, anschließend klicken Sie auf den Schalter Aktiviert um zu deaktivieren bzw. aktivieren der Archivierung. Bei dieser Aktion werden beide Berechtigungssätze bei der Archiv kompakt Entra Applikation automatisch hinterlegt.