Gräper Integration Research

Date: 2026-03-30 Status: Raw research — evidence collected, not yet an implementation plan

Sources Consulted

Key Extractions

d.velop d.3

API surface:

"The DMS app is the core HTTP interface to essential functionality related to documents and dossiers in the d.3ecm environment." — d.velop developer portal

"The API is a RESTful HTTP API with JSON representations, using JSON Hypertext Application Language to create links between various resources in JSON format." — d.velop developer portal

Authentication:

"The AuthSessionId must be given to every request, which can be done using the Authorization header with the Bearer scheme and a bearer token or via a cookie AuthSessionID that contains the session id." — d.velop developer portal

"For server-to-server communication, a bearer token is usually the preferred way." — d.velop developer portal

Webhooks (critical — contradicts pilot doc):

"Webhooks let you respond to events that are triggered by specific processes in a repository. When the event occurs, an HTTP POST request is sent to each entered URL." — help.d-velop.de/docs/en/pub/admin/2023.q3/administration/webhooks

Events: Create document (before/after), Update document properties (before/after), Delete document (before/after). Before-events can modify property values.

Write-back:

"You can update an existing DMS object in a d.3 repository without the need for action by the user, and no Validate hooks are executed in d.3 server while updating the DMS object without user interaction." — d.velop developer portal

SOAP deprecation:

"The d.3 API will no longer be supported starting with version Annual 2025 (Q2 2025)... converting to the Public REST API is required." — d.velop portal

On-prem vs cloud:

"The cloud-first strategy allows changes and new apps to be made available quickly in the cloud... the architecture is almost identical." — d.velop developer portal

Infor ERP LN

AP Invoice Automation (official path):

"The external solution sends purchase invoice, matching, and approval information to LN through a BDE/web service. In LN, this information is stored in staging tables and a success or error message is returned." — Infor LN 10.8 release notes

"The generated purchase invoice document number is stored in the staging tables, along with the information whether the process succeeded or failed. This information can then be retrieved by the AP invoice automation solution through a BDE/web service." — Infor LN AP automation docs

BOD-based invoice submission:

"RPA generates the Load.SupplierInvoice BOD. Using the IMS end point, this BOD is sent to the Received Purchase Invoices (tfacp1110m000) session." — Infor CSEC invoice processing flow

"Organizations can use the standard Process.SupplierInvoice BOD, which generates purchase invoices in LN Cloud Edition directly." — Infor Community

ION API Gateway:

"The ION API Gateway is a NodeJS reverse proxy application that accepts incoming HTTP requests from clients... passes the request on to the proper target server, and returns the target server's response back to the client." — Infor developer portal

"Currently, LN APIs are SOAP based. Development tools for generation of client proxies should support SOAP 1.1 and WSDL 1.1." — Infor LN web services docs

File-based import:

"Used to run the import program to transfer data on a non regular basis from sequential ASCII files to LN tables." — daxch0223m000 docs

Payment tracking:

"When the purchase invoice is paid, the PayableTracker BOD is used to provide the payment date and payment batch number to the AP invoice automation solution." — Infor LN AP automation release notes

cin1900m000: No results found in any public Infor documentation. May be customer-specific or a regional designation.

Iron Bot

No product called "Iron Bot" exists in publicly available Infor LN documentation, Infor Community forums, or general web search results.

Infor's actual RPA offering:

"Infor Robotic Process Automation (RPA) employs bots or virtual robots to automate labor-intensive, rule-based processes." — infor.com/technology/robotic-process-automation

"Mastermind is the cloud-based Multitenant component [for] orchestration, deployment, configuration, scheduling, and monitoring." — Infor RPA docs

"[Infor RPA] can integrate with third-party applications through APIs or by screen scraping the user interface." — Infor RPA docs

Analysis

A. d.velop d.3 — Fully Feasible, Better Than Expected

The pilot doc claims "No webhook support on-premises — polling required." This appears to be wrong. The d.velop documentation explicitly describes webhooks for repository events including document creation/update/deletion, with before/after event hooks, and the docs make no on-prem exclusion. The webhook configuration UI is part of the d.3 admin interface. The Power Automate connector also exposes a DynamicWebhookTrigger operation.

The REST API covers everything we need:

SDKs exist in Node.js, Go, and C#. Auth is API key -> session token, straightforward for server-to-server.

One caveat: external access to on-prem d.3 requires a gateway — Graeper needs to expose the d.3 REST API to our infrastructure, or we need a VPN/tunnel. This is a network architecture question, not an API limitation.

What's unknown: The exact metadata schema Graeper uses for invoices (customer-specific), and whether their d.3 version supports all the REST API features documented (the SOAP API was deprecated Q2 2025 — if they're on an older version, we need to verify).

d.3 REST API — Full Operation Reference

Core DMS API endpoint pattern: /dms/r/{repositoryId}/...

Concrete endpoint paths (from C# examples):

• Login: GET /identityprovider/login with Authorization: Bearer {apiKey} and Accept: application/hal+json
• Search: GET /dms/r/{repoId}/srm?sourceid={sourceId}&sourcecategories=["schriftverkehrkunde"]&sourceproperties={"belegdatum":["2018-03-11"]}
• Chunk upload: POST /dms/r/{repoId}/blob/chunk with Content-Type: application/octet-stream — returns Location header with content URI
• Store document: POST /dms/r/{repoId}/o2m with Content-Type: application/hal+json — body is JSON with filename, sourceId, sourceCategory, contentLocationUri, sourceProperties

"The length of the encoded query parameter is limited to 2000 characters." — d.velop developer portal

Update/Delete link relations:

"Items can be updated with an HTTP PUT request using the update or updateWithContent link relations."

"If you want to update only the properties with the update link relation, you do not need to provide a file."

"When calling the API via the HTTP verbs POST, PUT, DELETE and PATCH, you must specify the Origin header. The header value must correspond to the calling URL without path."

d.3 Authentication Detail

1. Call GET /identityprovider/login with Authorization: Bearer {apiKey} and Accept: application/json
2. Response returns AuthSessionInfoDto containing AuthSessionId and Expire values
3. Use the AuthSessionId for subsequent requests

"The IdentityProvider app sends a CacheControl header and defines the validity period in it with MaxAge. You should use the validity period specification to save the response for the specified number of seconds."

"API keys should be created for technical users only, and in the long term, the use of API keys for non-technical users will be prevented." — d.velop developer portal

Rate limiting (Power Automate connector): 100 API calls per connection per 60 seconds.

On-premise access:

• Default port: 6122 for web interface / HTTP API access
• d.3one application server port: 3401
• URL format: http://<host>:<port> or https://<host>:<port>

d.3 Webhook Detail

Event types (before/after pairs):

"To configure a webhook, you must provide a URI, which is called when the event occurs. The API key option lets you define an authentication key, which is also sent during the HTTP call of the webhook so the webhook can check whether the HTTP call actually originates from the DMS system."

"You can use Export and Import to export and import the webhook configurations, and the configuration data is transferred as a JSON file."

d.3 Official SDKs

B. Infor ERP LN — Multiple Viable Paths, Phased Approach Makes Sense

Three confirmed integration approaches for writing AP invoices:

Approach A — BDE/Web Service -> Staging Tables (tfacp7xxx): This is Infor's official AP automation path. External systems push invoice data via SOAP web service, data lands in staging tables (tfacp7100m000 etc.), processed by tfacp7200m000. Returns document number + success/error. This gives us the most control and feedback.

Approach B — Load.SupplierInvoice BOD via IMS: XML BOD sent to tfacp1110m000 (Received Purchase Invoices). Used by Infor's own RPA. Less direct feedback than Approach A.

Approach C — File-based via Exchange module (daxch): ASCII file import to LN tables. Lowest technical barrier, but also least automated feedback loop — you write a file, LN picks it up, you check logs.

For reading master data (POs, GRs, suppliers, chart of accounts), LN publishes outbound Sync BODs (Sync.PurchaseOrder, Sync.ReceiveDelivery, Sync.SupplierPartyMaster, Sync.ChartOfAccounts) via ION. Alternatively, BDE web services can query these directly.

The pilot doc's recommendation to start with file-based (Option A in their naming) is pragmatic — daxch import requires no ION setup, no SOAP deployment, no C4WS licensing (Product ID 7056 needed for web services). But it has the weakest feedback loop.

What's unknown:

• Graeper's exact LN version and patch level (determines which BODs/sessions are available)
• Whether C4WS is deployed and licensed (SLM Server license, Product ID 7056)
• Whether ION is configured (required for BOD-based integration)
• The cin1900m000 session referenced in the pilot doc — not found in any public documentation
• The 6 sub-account dimension structure (Kostenstelle, Kostentraeger, verb. Unternehmen, Kapitalentwicklung, Ergebnisherkunft, Produkt) — we know these map to LN dimensions but need Graeper's specific codes
• Payment block management — tfcmg1609m000 is documented for manual batch approval, but programmatic payment block removal is not clearly documented in public sources
• Whether auto-matching is enabled in their ACP Parameters (tfacp0100m000)

ION API Gateway Detail

The ION API Gateway is a NodeJS reverse proxy that sits between API consumers and LN's SOAP services.

"The ION API Gateway is a NodeJS reverse proxy application that accepts incoming HTTP requests from clients (web-apps, mobile-app, fat-clients, etc.), passes the request on to the proper target server, and returns the target server's response back to the client." — developer.infor.com

The gateway proxies to two LN backend API servers:

• C4WS (Connector for Web Services) — the SOAP web service servlet
• LN Client Service

REST vs SOAP:

"Currently, LN APIs are SOAP based. Development tools for generation of client proxies should support SOAP 1.1 and WSDL 1.1." — Infor LN web services docs

"Use the REST API Modeler for LN to add OData REST APIs in the OData REST APIs (ttadv2570m700) session." — Infor LN Cloud docs

ION itself supports both protocols through different mechanisms:

"ION Workflows have a ION API step available to connect to REST services (introduced in V.12.0.12). ION Document Flows in on-premise environments have a Web Service step available for SOAP services." — Infor Community

Authentication (OAuth 2.0):

Resource Owner Password Grant with service accounts. Required credentials (4 components):

1. Application ClientID
2. Application Client-Secret
3. Service Account AccessKey
4. Service Account SecretKey

Token request parameters:

• grant_type = "password" (fixed)
• username = Service Account AccessKey
• password = Service Account SecretKey
• client_id = Application ClientID
• client_secret = Application Client-Secret

"A Service Account can be associated to a user, making the call to the backend application on behalf of the user." — Infor ION API docs

SDK implementations available in Java, .NET, Go — see infor-cloud/ion-api-sdk.

SOAP Endpoint URL Pattern:

https://<<domain>>:<<port>>/infor/LN/c4ws/services/<ServiceName>_v2

BODs (Business Object Documents)

"Business object documents (BODs) are XML messages used to exchange data between enterprises or enterprise applications." — Infor LN BOD docs

A BOD = Verb + Noun. Example: SyncReceiveDelivery = verb Sync + noun ReceiveDelivery.

BOD Verbs:

BOD Message Structure:

"All date and time elements within a BOD are presented in Coordinated Universal Time (UTC)" using format yyyy-08-13T15:30Z.

Key metadata fields required: Tenant ID, Accounting Entity ID, Location ID, Version ID, Logical ID.

Custom data goes in UserArea elements using Property > NameValue with @name and @type attributes.

Relevant BODs for AP Integration:

SupplierPartyMaster key fields (from XSD schema):

BOD Publishing Setup:

"Before starting configuration, select the 'Prevent BOD Publishing' checkbox in the BOD Parameters session to prevent premature publishing before setup completes."

Configuration sessions:

• BOD Parameters (tcbod0100m000)
• Validate Publishing Data Setup (tcbod0300m000)
• Currency/Country/Language mapping to ISO codes (countries use 2-alpha ISO, not 3-alpha)
• Organizational structure: Tenant > Accounting Entity > Location

Financial BODs require additional setup:

• Journal Types (tfbia0119m000)
• Map Journal Type to Transaction Type (tfbia0120m000)
• BIA Parameters (tfbia0500m000)
• Flexible/Fixed Dimension Definitions (tfbia8501m000, tfbia8502m000)

SOAP Web Services (C4WS)

"Infor ES Connector for Web Services is a Java servlet that enables you to access BDE or BOI business objects on an Infor LN or Baan server." — Infor LN web services docs

BDE = Business Data Exchange (data interfaces) BOI = Business Object Interface (function interfaces)

"Web services can only be deployed for BDE business interfaces generated with LN Studio version 8.4 or later. BOD business interface WSDL files cannot be imported."

Licensing:

"To access the business objects on an Infor LN or Baan server application, you require an SLM Server license with Product ID 7056."

File-Based Integration (Exchange Module)

Key sessions:

• daxch0223m000 — Import Data (Non-Regular): one-off imports from ASCII files to LN tables
• daxch0224m000 — Import Data (Regular): recurring imports, useful in multisite environments
• Field definitions in ASCII File Fields (daxch0503m000) session
• Exchange schemes created in daxch0501m000

For cloud deployments, file-based integration uses ION Data Flows:

"1. Create custom BOD in Data Catalog using File Templates. 2. Apply Mapping to convert custom XML BOD to Sync.SupplierInvoice format. 3. Use Data Flow to receive files from sFTP, convert to Sync.SupplierInvoice, and send via API." — Infor Community

Note: Mapping functionality is exclusively available in Cloud versions.

LN Sessions Reference

tfacp2520m000 — Invoice-from Business Partner Open Entries: View open invoices and open entries. Key fields: Transaction Type, Document Number, Invoice-from Business Partner, Invoice Number, Document Date, Due Date, Discount Dates and Amounts, Invoice Amount (invoice + home currency), Invoice Status, Match with Orders indicator, Linked Purchase Order, Balance Amount.

tfacp2544m000 — Match Receipt: Receipt line matching to invoices, within the Purchase Invoice Entry (tfacp2600m000) workflow. Part of the matching chain: tfacp2541m000 (Match Order) -> tfacp2544m000 (Match Receipt) -> tfacp2254s000 (Match Landed Cost) -> tfacp2151s100 (Match Consumption) -> tfacp2546m000 (Match Freight Orders).

tfcmg1609m000 — Payment Advice: View and maintain payment advice data. Key fields: Payment Batch, Status, Approved (yes/no), Approved by, Total for Batch. Operations: Approve, Unapprove, Split Advice. When 'Payment Batch Approval' is enabled in CMG Parameters, an authorized user must approve the batch before processing.

tfacp2600m000 — Purchase Invoice Entry: Main interactive session for AP invoice entry. Used for manual invoice registration and matching.

tfacp7200m000 — Register and Process External Invoices: The key session for automated AP invoice processing. Processes data from staging tables (tfacp7xxx). Returns document number + success/error.

Staging table sessions:

• External Invoices (tfacp7100m000)
• External Invoice detail (tfacp7600m000)
• Receipts by External Invoice (tfacp7105m000)
• Cost Lines by External Invoice (tfacp7110m000)
• Project Costs (tfacp7111m000)
• Service Costs (tfacp7113m000)
• Subcontracting (tfacp7120m000)
• Tax Lines (tfacp7121m000)
• Reverse: tfacp7200m100
• Error Log: tfacp2580m000

AP Invoice Data Structure (from DocBits third-party reference)

Header fields: invoice_id, invoice_date, invoice_sub_type, total_amount, total_net_amount, currency, supplier_id, purchase_type, tax_country_1, correlation_id, idm_reference, reference. Statics: Financial Company, Rate Determiner (docd), External Rate Factor (1).

Receipt lines (PO invoices): Purchase orders, delivery numbers, quantities, amounts. Statics: OrderType (purchase), LogisticCompany, OrderSequence (1).

Cost lines (non-PO invoices): 12 custom dimensions, 2 quantity fields for ledger accounting.

Tax lines: Tax code, tax amount, tax base amount, tax country.

Invoice Processing Workflow in LN (all approaches)

After the invoice lands in LN, the standard 8-step workflow applies:

1. Optional receipt recording (tfacp1500m000)
2. Confirmation & registration
3. Hold reason removal
4. Matching to receipts/POs/freight orders
5. Error resolution (tfacp2580m000)
6. Price approval
7. Approval error resolution
8. Payment authorization

Invoice status progression: Draft -> Registered -> Matched -> Approved

Matching methods:

• Automatic — system matches when order/packing slip numbers are entered
• Manual — user matches across multiple orders
• Job-based — background jobs match ranges of invoices

"If the Automatic Matching check box in the ACP Parameters (tfacp0100m000) session is selected, LN will automatically match the invoice."

Capability Matrix

C. Iron Bot — Cannot Be Identified

"Iron Bot" does not exist as a product in the Infor ecosystem or in any publicly available RPA/automation vendor catalog. Exhaustive search across "Iron Bot", "IronBot", "iron-bot" combined with Infor, LN, ERP, RPA, booking, automation returned zero relevant results.

Products named "IronBot" that do exist are entirely unrelated:

• IronBot (Advanced Construction Robotics) — a physical rebar-placing robot
• IronBot Agency — an AI voice agent for service businesses
• IRONBOT — an algorithmic trading platform
• IronBots.ai — a virtual agent marketplace

Possibilities:

1. Internal/informal name at Graeper for a custom automation script
2. A reseller-branded version of Infor RPA
3. A custom OLE/COM automation (there's a Python library baanlib for driving LN via win32com)
4. A misremembered or translated product name

Infor's actual RPA is screen-scraping-based, managed by "Mastermind" (cloud component), and can run attended or unattended. Its external trigger API is not publicly documented. For invoice booking specifically, the BOD/BDE paths are far more robust than RPA screen automation.

This needs clarification from Graeper. Without knowing what "Iron Bot" actually is, we can't design an integration with it.

Confidence Assessment

Retractions

The pilot doc (Section 3) states:

"No webhook support on-premises — polling required"

The d.velop documentation does not support this claim. Webhooks are documented as a general repository feature without an on-prem exclusion. However, I'm flagging this rather than fully retracting it — the pilot doc author may have had version-specific or deployment-specific knowledge that I can't verify from public docs alone. This should be confirmed directly with Graeper's d.3 admin.

The pilot doc references cin 1900m000 as a file-based transfer session. I could not find this session in any public Infor documentation. I'm not retracting the pilot doc's claim (Graeper may use custom sessions), but I cannot verify it.

Integration Architecture Diagrams

d.velop d.3 Integration

flowchart TB
    classDef orcha fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px
    classDef dms fill:#8b5cf6,stroke:#7c3aed,color:#fff,stroke-width:2px
    classDef network fill:#f1f5f9,stroke:#94a3b8,color:#334155,stroke-width:1px,stroke-dasharray:5 5

    subgraph GRAEPER_NET["Graeper On-Premise Network"]
        D3["d.3 DMS Server\nREST API (HAL+JSON)\nPort 6122"]:::dms
        GW["Gateway / Reverse Proxy\n(required for external access)"]:::network
        D3 <-->|"Internal"| GW
    end

    subgraph ORCHA_CLOUD["Orcha Cloud"]
        CONNECTOR["d.3 Connector Service"]:::orcha
        INTAKE["Document Intake"]:::orcha
        WRITEBACK["Write-Back Service"]:::orcha
    end

    GW <-->|"HTTPS\nBearer AuthSessionId"| CONNECTOR

    subgraph READ_OPS["Read Operations"]
        direction LR
        R1["Webhook: document created\nHTTP POST to Orcha endpoint"]
        R2["GET /dms/r/{repoId}/sr/\nSearch by category + date"]
        R3["GET document main file\n(PDF/image download)"]
        R4["GET document metadata\n(properties, status)"]
    end

    subgraph WRITE_OPS["Write-Back Operations"]
        direction LR
        W1["PUT update properties\n(extraction results, match status)"]
        W2["POST create notes\n(verification protocol, audit trail)"]
        W3["PUT update status\n(processed, approved, error)"]
        W4["POST link documents\n(invoice to PO, invoice to GR)"]
    end

    CONNECTOR --> READ_OPS
    READ_OPS --> INTAKE

    WRITEBACK --> WRITE_OPS
    WRITE_OPS --> CONNECTOR

    AUTH["Auth Flow:\n1. POST /identityprovider/login\n   Authorization: Bearer {apiKey}\n2. Receive AuthSessionId\n3. Cache per MaxAge header"]:::network
    CONNECTOR -.-> AUTH

Infor ERP LN Integration — Phased

flowchart TB
    classDef orcha fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px
    classDef erp fill:#6366f1,stroke:#4f46e5,color:#fff,stroke-width:2px
    classDef phase1 fill:#dcfce7,stroke:#16a34a,color:#166534,stroke-width:2px
    classDef phase2 fill:#eff6ff,stroke:#0078d4,color:#1e40af,stroke-width:2px
    classDef unknown fill:#fef3c7,stroke:#f59e0b,color:#92400e,stroke-width:2px

    subgraph ORCHA["Orcha"]
        ENGINE["Invoice Processing\nEngine"]:::orcha
        EXPORT["Export Service"]:::orcha
        IMPORT["Data Import\nService"]:::orcha
    end

    subgraph PHASE_1["Phase 1: File-Based (Lowest Barrier)"]
        direction TB
        FLAT_OUT["Flat file export\nfrom LN\n(POs, GRs, Suppliers,\nChart of Accounts)"]:::phase1
        FLAT_IN["ASCII file import\nvia daxch Exchange\n(daxch0223m000)\nInvoice booking data"]:::phase1
    end

    subgraph PHASE_2["Phase 2: API-Based (Full Automation)"]
        direction TB

        subgraph READ_BODS["Outbound BODs (LN to Orcha)"]
            SYNC_PO["Sync.PurchaseOrder"]:::phase2
            SYNC_GR["Sync.ReceiveDelivery"]:::phase2
            SYNC_SUP["Sync.SupplierPartyMaster"]:::phase2
            SYNC_COA["Sync.ChartOfAccounts"]:::phase2
        end

        subgraph WRITE_PATH["Inbound (Orcha to LN)"]
            BDE["BDE/SOAP Web Service\nvia C4WS servlet\nOAuth 2.0 through ION"]:::phase2
            STAGING["Staging Tables\ntfacp7100m000\n(headers, receipt lines,\ncost lines, tax lines)"]:::erp
            PROCESS["tfacp7200m000\nRegister & Process\nExternal Invoices"]:::erp
            RESULT["Result: document number\n+ success/error"]:::erp
            BDE --> STAGING --> PROCESS --> RESULT
        end

        PAYABLE["PayableTracker BOD\n(payment confirmation\nback to Orcha)"]:::phase2
    end

    ENGINE --> EXPORT
    EXPORT -->|"Phase 1"| FLAT_IN
    FLAT_OUT -->|"Phase 1"| IMPORT
    IMPORT --> ENGINE

    EXPORT -->|"Phase 2"| BDE
    READ_BODS -->|"Phase 2\nvia ION"| IMPORT
    PAYABLE -->|"Phase 2"| IMPORT
    RESULT -.->|"Feedback"| EXPORT

    subgraph LN["Infor ERP LN"]
        LN_AP["AP Module\ntfacp sessions"]:::erp
        LN_MATCH["Auto-Matching\n(if enabled in\ntfacp0100m000)"]:::erp
        LN_PAY["Payment Processing\ntfcmg1609m000"]:::erp
        LN_AP --> LN_MATCH --> LN_PAY
    end

    FLAT_IN --> LN_AP
    PROCESS --> LN_AP

Invoice Booking Detail — What Orcha Sends to LN

flowchart LR
    classDef orcha fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px
    classDef data fill:#eff6ff,stroke:#0078d4,color:#1e40af,stroke-width:1px
    classDef erp fill:#6366f1,stroke:#4f46e5,color:#fff,stroke-width:2px
    classDef unknown fill:#fef3c7,stroke:#f59e0b,color:#92400e,stroke-width:2px

    ORCHA["Orcha\nInvoice Engine"]:::orcha

    subgraph INVOICE_DATA["Invoice Payload"]
        HEADER["Header\ninvoice_id\ninvoice_date\nsupplier_id\ntotal_amount\ncurrency\ntax_country\npurchase_type\npayment_terms\nfinancial_company"]:::data

        RECEIPT["Receipt Lines (PO invoices)\npurchase_order\ndelivery_number\narticle / quantity\namount per position\norder_type = purchase"]:::data

        COST["Cost Lines (non-PO)\nGL Account (Sachkonto)\n+ 6 Sub-Accounts:\n  1. Kostenstelle\n  2. Kostentraeger\n  3. verb. Unternehmen\n  4. Kapitalentwicklung\n  5. Ergebnisherkunft\n  6. Produkt"]:::data

        TAX["Tax Lines\ntax_code\ntax_amount\ntax_base_amount\ntax_country"]:::data
    end

    ORCHA --> HEADER
    ORCHA --> RECEIPT
    ORCHA --> COST
    ORCHA --> TAX

    subgraph LN_PROCESSING["LN Processing"]
        STAGING["tfacp7xxx\nStaging Tables"]:::erp
        REGISTER["tfacp7200m000\nRegister & Process"]:::erp
        MATCH["Auto-Match\nPO to Invoice\nGR to Invoice"]:::erp
        BOOKED["Booked Invoice\nDocument Number\nReturned"]:::erp

        STAGING --> REGISTER --> MATCH --> BOOKED
    end

    HEADER --> STAGING
    RECEIPT --> STAGING
    COST --> STAGING
    TAX --> STAGING

    UNKNOWN_DIM["Unknown:\nGraeper's exact dimension\ncodes for 6 sub-accounts\nand tax code mapping"]:::unknown
    UNKNOWN_DIM -.-> COST

End-to-End Integration (All Systems)

flowchart TD
    classDef orcha fill:#0078d4,stroke:#005a9e,color:#fff,stroke-width:2px
    classDef dms fill:#8b5cf6,stroke:#7c3aed,color:#fff,stroke-width:2px
    classDef erp fill:#6366f1,stroke:#4f46e5,color:#fff,stroke-width:2px
    classDef unknown fill:#fef3c7,stroke:#f59e0b,color:#92400e,stroke-width:2px
    classDef email fill:#f1f5f9,stroke:#94a3b8,color:#334155,stroke-width:1px

    EMAIL["Email Intake\neingangsrechnung@graeper.de\nIMAP"]:::email
    SCAN["Paper Scan\nMFD via d.capture to d.3"]:::dms

    subgraph D3["d.velop d.3 (on-premise)"]
        D3_STORE["Document Repository"]:::dms
        D3_WEBHOOK["Webhook:\ndocument.created"]:::dms
        D3_STATUS["Document Status\n& Metadata"]:::dms
    end

    SCAN --> D3_STORE
    D3_STORE --> D3_WEBHOOK

    subgraph ORCHA["Orcha Cloud"]
        INTAKE["Document Intake\n(email + d.3 webhook)"]:::orcha
        AI["AI Processing\nExtract / Verify / Match"]:::orcha
        APPROVAL["Approval Engine\nRule-based routing"]:::orcha
        LN_CONN["LN Connector\n(file-based then SOAP/BOD)"]:::orcha
        D3_CONN["d.3 Connector\nREST API write-back"]:::orcha
    end

    EMAIL --> INTAKE
    D3_WEBHOOK -->|"HTTP POST\nwith doc metadata"| INTAKE
    INTAKE -->|"Download PDF\nvia d.3 REST API"| D3
    INTAKE --> AI

    subgraph LN["Infor ERP LN (on-premise)"]
        LN_MASTER["Master Data\nPOs, GRs, Suppliers\nChart of Accounts"]:::erp
        LN_AP["AP Module\nStaging / Register\n/ Match / Book"]:::erp
        LN_PAY["Payment Module\ntfcmg"]:::erp
    end

    LN_MASTER -->|"Sync BODs or\nflat file export"| AI
    AI --> APPROVAL
    APPROVAL --> LN_CONN
    LN_CONN -->|"BDE/SOAP or\nASCII file"| LN_AP
    LN_AP --> LN_PAY
    LN_PAY -->|"PayableTracker\nBOD"| ORCHA

    APPROVAL --> D3_CONN
    D3_CONN -->|"PUT metadata\nPOST notes\nPUT status"| D3_STATUS

    IRONBOT["'Iron Bot'\nUnknown system\nNeeds clarification\nfrom Graeper"]:::unknown
    IRONBOT -.->|"?"| LN_AP

Open Questions for Graeper

These need answers before implementation design can be finalized:

1. d.3 version — Which d.3/d.velop version is deployed? Do webhooks work in their installation? Is the REST API available or are they still on the legacy SOAP/d.3 API?
2. d.3 network access — How will Orcha (cloud) reach d.3 (on-prem)? VPN tunnel? Exposed gateway? Reverse proxy?
3. Infor LN version and patch level — Determines BOD availability and tfacp7xxx staging table support
4. Is C4WS deployed? — Required for SOAP web services; needs SLM Server license (Product ID 7056)
5. Is ION configured? — Required for BOD-based integration
6. What is "Iron Bot"? — No publicly known product. Need: vendor name, documentation link, or description of what it does
7. Dimension structure — Exact codes/values for the 6 sub-accounts (Kostenstelle, Kostentraeger, verb. Unternehmen, Kapitalentwicklung, Ergebnisherkunft, Produkt)
8. Tax code mapping table — Mapping between German VAT scenarios and LN tax codes
9. cin1900m000 — Cannot be found in public docs. Need clarification or sample files
10. Auto-matching config — Is automatic matching enabled in ACP Parameters (tfacp0100m000)?

Source URLs

d.velop d.3

• API Overview
• DMS API
• DMS API for configuring d.3 repositories
• C# Example Code (GitHub)
• d.velop Power Automate Connector
• Node.js SDK - DMS Module
• d.velop Business Objects API Guide
• Cloud, on-premises or hybrid
• Basics
• Configuring webhooks
• DMS Webhooks
• d.velop documents repo export API
• SOAP API end-of-life announcement
• d.velop GitHub Organization
• DMS API First Steps Tutorial
• Searching for DMS objects

Infor ERP LN — Official

• ION API Gateway Tutorial
• How to Call an ION API
• ION API SDK (GitHub)
• ION API Administration Guide
• API Gateway Backend Authentication
• Configuring ION API Gateway with LN
• BOD Messaging
• BOD Verbs
• BOD Message Structure
• Configuring LN for BOD Publishing
• SupplierPartyMaster XSD
• SyncPurchaseOrder XSD
• tfacp2520m000 - Open Entries
• tfacp2600m000 - Purchase Invoice Entry
• tfcmg1609m000 - Payment Advice
• Matching Purchase Invoices
• Processing Purchase Invoices
• AP Invoice Automation Release Notes
• Invoice Processing Flow (CSEC)
• Connector for Web Services
• Web Services Guide (PDF)
• OData REST APIs
• daxch0223m000 - Import Non-Regular
• daxch0224m000 - Import Regular
• Infor Developer Portal

Infor ERP LN — Community / Third-Party

• ION REST vs SOAP Discussion
• Incoming Supplier Invoice Discussion
• DocBits - Suppliers and Purchase Orders
• DocBits - Export to LN Example
• DocBits - LN Configuration

Iron Bot / Infor RPA

• Infor RPA Overview
• Infor RPA Key Concepts
• Infor RPA Management
• Infor RPA Developer Tutorials
• baanlib (Python OLE wrapper)