# CLARC Infinity - Complete Documentation (English) > CLARC Infinity is a cloud-native ECM & BPM platform by CTO Balzuweit GmbH. It unifies AI-powered document capturing, e-invoicing (Peppol, XRechnung, ZUGFeRD), order and invoice workflows, and audit-proof cloud archiving -- hosted in Germany, integrated with SAP, Microsoft 365 and Business Central. --- # Welcome Source: https://clarc.com/docs/en/index.md # CLARC Infinity – Documentation Welcome to the official documentation of the **CLARC Infinity Platform** — the next-generation ECM/BPM cloud platform for digital transformation in the enterprise environment. With over three decades of industry experience, CLARC Infinity provides a complete platform for document management, business process automation and AI-powered processing — flexibly deployable in the cloud, on-premises or as a hybrid model. ## Platform Highlights - **Flexible Operating Models** – Cloud, on-premises and hybrid, platform-independent and data-center neutral - **Multi-Tenant Architecture** – Each tenant receives a complete system landscape with development, test and production environments - **Zero-Trust Security** – Secure by design with advanced transport system, transaction management and change tracking - **AI-Powered Processing** – Automated invoice and order processing, data extraction and workflow control - **Seamless Integration** – SAP, Office 365, SSO and open REST API for custom integrations - **GDPR-Compliant** – EU operations on Microsoft Azure and European hyperscalers, fully on-premises possible ## Documentation Areas | Area | Content | | --- | --- | | [FAQ](#faq/index) | Frequently asked questions about the platform, modules and integration | | [Infrastructure](#infrastructure/index) | Architecture, hosting and operating models | | [System Requirements](#system-requirements) | Client and server requirements | | [Administration](#administration/index) | Configuration, CLI, transports and tenant management | | [Scripting](#scripting/index) | Scripts, events and automation | | [Users](#users/index) | User guide and instructions | :::note This documentation is continuously updated. For questions, the CLARC support team is always available — please include the **tenant**, **system class**, **message ID** and **timestamp** with technical inquiries. ::: ## Versatility and Flexibility CLARC Infinity offers unparalleled flexibility in terms of deployment options. With support for **cloud, on-premises and hybrid operating models**, the platform seamlessly adapts to the specific needs and preferences of each organisation. It is independent of data centres and cloud providers, ensuring broad compatibility and easy integration into existing infrastructures. ## Multi-Tenant Capability A central aspect of CLARC Infinity is its full multi-tenant capability. **A multi-system landscape is provided for each tenant**, encompassing development, test, production, sandbox and training environments. This structure enables flexible and low-risk development as well as the implementation of systems across different phases of the project cycle. ## Security The platform ensures **the highest security through a Zero-Trust** model ("Secure by Design") and a sophisticated transport system with transaction management. This system securely records and transfers changes between systems, ensuring the integrity and security of data at all times. ## Permission Management CLARC Infinity provides **comprehensive user, group and role management for detailed access controls**. This enables organisations to implement finely tuned access restrictions and ensure that every user only has access to the information and functions relevant to them. ## Central Data Management and Integration The platform supports central data management via **freely definable Business Objects**. It also offers advanced features such as **web scanning** from single-document to high-volume mass data capture. **Integration with Office 365** and Single Sign-On (SSO) ensures a seamless and efficient working environment. ## Intelligent Data Processing and Workflow Management Another core feature of CLARC Infinity is **intelligent AI-powered invoice and purchase order processing**, enabling **automated data extraction** of header and line item data. In addition, the platform supports the planning and execution of **workflows**, allowing organisations to design their processes efficiently and transparently. ## Infrastructure & Operations The CLARC Infinity platform is operated by default in the **Microsoft Azure Cloud**. Alternatively, it runs on **European hyperscalers** or fully **on-premises** at the customer's site — self-hosted in their own infrastructure. The underlying AI infrastructure is provided via dedicated clusters at **RunPod**, but can also be operated completely independently, as all models are developed in-house and trained on an open-source basis. All operating variants are located in the **EU** and comply with the requirements of the **GDPR**. A comprehensive **Zero-Trust security model** ensures maximum data security — regardless of the hosting model. The platform is fully multi-tenant capable, containerised and designed for **hybrid operation** — ideal for highly secure, flexible and scalable digitalisation projects. ## Summary **CLARC Infinity** is more than just a **platform**; it is a **comprehensive solution** that helps organisations master the challenges of **digitalisation** and **optimise their business processes**. With its extensive feature set, **flexibility** and **security**, CLARC Infinity represents a forward-looking choice for organisations that want to stay at the **forefront of technological progress**. --- # Frequently Asked Questions (FAQ) Source: https://clarc.com/docs/en/faq/index.md # Frequently Asked Questions (FAQ) This section provides answers to frequently asked questions about the CLARC Infinity platform, its modules, and integrations. The FAQ is aimed at users, administrators, consultants, and technical integrators, offering quick orientation on recurring topics from practice, support, and projects. The questions and answers are structured by thematic focus areas and concentrate on aspects that arise most frequently in projects — from technical connectivity and processing of business-relevant data to billing, operating models, and format standards. The goal of this section is to present key topics in a compact and understandable way, providing direct help for specific questions. The FAQ is regularly updated to reflect new features, regulatory requirements, or changed processes, ensuring a reliable information source for all users of the platform. --- ## Still Have Questions? If your questions are not answered here, our **support team** is happy to help. For technical inquiries (e.g., for errors), please ideally provide the **tenant name**, **system class**, **message ID**, and **time of the event** — this helps us process your request more quickly. --- # CLARC Infinity Platform Source: https://clarc.com/docs/en/faq/clarc-infinity-platform.md # Frequently Asked Questions about the CLARC Infinity Platform This FAQ serves as the first point of contact for frequently occurring questions about using, integrating and licensing the CLARC Infinity Platform. ## 1. Can I access local (on-premises) data sources in the Capturing (and other) processes? **Yes.** The platform supports **database access to local data sources** — e.g. for validation or lookup functions — directly in the **capturing process**. This is done via the **Cloud Connector**, which establishes a secure connection between your on-premises infrastructure and the CLARC Cloud. This allows you to retrieve master data from local ERP, SQL or other systems without having to replicate them to the cloud. ## 2. How do I integrate existing or specialized processes with an existing CLARC Enterprise installation? Integration with existing **CLARC Enterprise systems** is seamlessly possible via the **Cloud Connector**. From within the CLARC Infinity Platform, a document or task is transferred to an existing **processing queue** in CLARC Enterprise. Depending on the architecture, a **new or existing CLARC Enterprise installation** can be used — also **per tenant and multi-stage**. This allows, for example: - Use of existing processes (validation, checks, ERP integration) - Integration into the local infrastructure (archive, DMS, SAP) - Avoidance of redundancy in parallel operation of Infinity and Enterprise ## 3. Is the previous "Capture Office" from CLARC Enterprise replaced by the new "Capture in Infinity"? **Partially — depending on the deployment scenario.** The new **Capture module in CLARC Infinity** offers a modern, cloud-based user experience and is currently designed for the following **Microsoft Office integrations**: - Outlook - Word - Excel Planned extensions (in development): - Microsoft Teams integration - Native desktop extension (standalone app) If you **exclusively use these Office applications**, **no additional installation or licensing of the previous Capture Office** (from CLARC Enterprise) is required. For more complex scenarios or requirements not yet covered, parallel use may currently still be advisable. ## 4. Are there "base costs" for operating the platform? **No — no flat-rate base costs apply.** All services are included in **clearly defined service packages**. These packages include: - Use of the platform - Storage - Transactions (e.g. extraction, conversion) - Support services Service packages are booked with a **term of one year** and automatically renew for a further year unless cancelled in time. ## 5. How do I keep control over usage and costs? As a customer, you receive **monthly usage statistics** for insight into: - Number of processed documents - Usage of individual modules (e.g. Invoice Extraction, Capturing) - Storage consumption These values are **reconciled annually (or within the year in case of significant deviation)** against the **contractually agreed included services**. This allows you to always keep track of your actual usage and the underlying costs — **transparently and traceably.** ## 6. Can CLARC Infinity also be operated on-premises? **Yes, CLARC Infinity can be fully installed and operated on-premises.** This operating mode is particularly suitable for customers with special compliance requirements or in highly secure environments without cloud connectivity. The entire platform is operated in the **customer's own data center**, including the user interface, process components and optionally also the **AI infrastructure**. However, some **technical challenges** need to be considered: - **Firewall and network approvals** for internal services and external communication paths - **Operation of own AI models and resources** (GPU availability, runtime services), depending on the modules used (e.g. document extraction) - **Maintenance, updates and monitoring** are entirely the customer's responsibility On-premises operation is generally possible but **requires individual technical coordination** and project support. If interested, we are happy to provide **dedicated consulting and implementation planning**. --- # CLARC Billing for SAP Source: https://clarc.com/docs/en/faq/clarc-billing-for-sap.md # Frequently Asked Questions about CLARC Billing for SAP This FAQ answers the most important questions about electronic invoicing with CLARC Billing in conjunction with SAP. It is aimed at consultants, administrators and users who want to automate the invoicing process with PDF and XML formats (e.g. ZUGFeRD, Factur-X, XRechnung or international standards). --- ## 1. Generation of XML and PDF ### 1.1 How is the XML invoice generated? (ZUGFeRD, Factur-X, XRechnung, etc.) The XML file is generated directly from the **SAP iDoc** (e.g. INVOIC). It is based **neither on the generated PDF** nor on database tables. This makes XML generation completely structured, robust and independent of form variants. --- ### 1.2 Is the PDF reused or does it play a role in XML generation? No. The PDF is generated exclusively in SAP and optionally used for dispatch. For XML generation, only the data from the iDoc is used. --- ### 1.3 Is the XML embedded in the PDF (ZUGFeRD), or are PDF and XML generated separately? Both are possible. Whether PDF and XML are generated separately or as an embedded document (e.g. PDF/A-3 with embedded XML) is a **configuration matter** and can be defined per scenario. --- ## 2. Archiving and Filing ### 2.1 Where are PDF and XML archived? - The **PDF** is stored directly in the **SAP Content Server** during the SAP print process. - The **XML** can subsequently be automatically or manually **added to the archive** and linked to the SAP document. --- ### 2.2 Can PDF and XML be stored entirely in the CLARC archive? Yes. CLARC can **fully handle the archiving itself**, without SAP archiving. --- ### 2.3 How long are invoices archived? The retention period is **freely configurable**. In practice, archiving is based on statutory requirements (typically 10–11 years). --- ## 3. SAP Integration & Technical Implementation ### 3.1 How does the solution integrate with SAP? Integration is done via an **SAP transport** that provides all required programs. This is followed by manageable **customizing** in SAP. --- ### 3.2 Are SAP standard objects modified? No. The solution works additionally via: - iDocs - Enhancement points - Customer-side customizing The SAP standard remains untouched. --- ### 3.3 How does the interaction between the SAP print form and CLARC XML generation work? - SAP generates the **PDF** via the existing print form. - CLARC reads the structured data exclusively from the **iDoc** to generate the XML. There is _no_ dependency of the XML on the SAP print layout. --- ### 3.4 Can automated attachments (e.g. terms and conditions, delivery notes, service records) be added? Yes. Via defined **enhancement points** in SAP, further documents can be added automatically. Additionally, users can manually add attachments in the CLARC web application. --- ## 4. Dispatch Process ### 4.1 Who dispatches the invoice (PDF/XML) — SAP or CLARC? The dispatch of the invoice is handled entirely by **CLARC**. CLARC controls the entire process including generation, dispatch and optional archiving. Dispatch can take place via: - a **customer-provided mailbox**, or - directly via **CLARC** (platform-side dispatch service) Which variant is used depends on the customer scenario and compliance requirements. --- ### 4.2 How does technical delivery work? Delivery is made as an email with: - PDF - XML (e.g. ZUGFeRD, XRechnung — depending on configuration) - Optional additional attachments All attachments are assembled automatically from the process. --- ### 4.3 How are delivery failures (bounces) handled? The behavior for email bounces depends on **who operates the email mailbox** through which the invoice is sent: If the email is sent via a customer's own mailbox, **bounces are reported back to this mailbox**. This allows bounces to be handled as usual via: - Internal processes - Helpdesk- or monitoring-based workflows --- ## 5. Supported Formats ### 5.1 Which electronic invoice formats are supported? CLARC Billing supports the common and widely used e-invoicing formats: - **ZUGFeRD** - **Factur-X** - **XRechnung** - **Peppol**-based formats - International XML standards The exact list is flexible, as statutory standards change. CLARC is continuously updated to reflect new requirements. --- ## 6. Integration of Additional Systems ### 6.1 Can ERP systems other than SAP be connected? Yes. Via the **open OData interface**, other ERP systems can also be connected. This enables hybrid scenarios and central billing processes independent of the primary ERP. --- ## 7. Billing & Usage Model ### 7.1 How is the billing module charged? There are **no base costs** for the CLARC Billing module. Billing is handled entirely via **service packages** that cover all services. The most important framework conditions: - **Annual term** of service packages - **Automatic renewal** for another year each time - **Usage statistics** so customers always have transparency over volumes and consumption - **Annual reconciliation** of actual usage with contractual agreements - No hidden base fee — the packages cover all relevant functions --- ## 8. Maintenance of Business Partners & Format Control ### 8.1 Where are dispatch formats and settings maintained for customers? Settings for dispatch formats and e-billing behavior are maintained in CLARC at two levels: #### 8.1.1 Sales Organization (SalesOrg) Here the **global default configurations** are defined, e.g.: - Default dispatch format (PDF, ZUGFeRD, XRechnung, etc.) - Dispatch type: **manual**, - **automatic (scheduled)** or - **immediate** Default email templates, separated by **language** (SalesOrg level only) Default communication channels These settings serve as the _baseline_ for all associated customers. #### 8.1.2 Customer / Business Partner At the customer level, settings can be **specifically overridden**: - Individual dispatch format - Individual dispatch type - Email address - Deviating format profiles - Preferences for PDF/XML combinations (if permitted) Email addresses are — where available — taken from **SAP** but can be adjusted or supplemented in CLARC. --- # Infrastructure Source: https://clarc.com/docs/en/infrastructure.md # Infrastructure & Hosting Architecture of the CLARC Infinity Platform This section describes the infrastructure and hosting architecture of the CLARC Infinity platform. From Microsoft Azure Cloud to other hyperscalers and fully on-premises operation — the platform adapts flexibly to your IT strategy while meeting the highest requirements for security, data protection, and availability. ## 1. Flexibility through SaaS and Hybrid Cloud The CLARC Infinity platform was designed as a highly scalable, multi-tenant solution that can be operated both as **Software-as-a-Service (SaaS)** and in **hybrid cloud architectures**. Depending on customer requirements, the entire infrastructure can flexibly run in the cloud, on-premises, or in mixed environments. The modular design and decoupled architecture of the platform enable deployment across a wide range of infrastructures without sacrificing security, performance, or maintainability. --- ## 2. Standard Operation in Microsoft Azure Cloud By default, the CLARC Infinity platform operates in **Microsoft Azure Cloud** within an **EU-certified data center**. Customers benefit from: - High availability and redundancy - Scalable compute and storage capacity - Integrated security mechanisms - Automated patching and monitoring - Full support for EU GDPR and industry-specific compliance requirements --- ## 3. Support for Additional Hyperscalers In addition to Microsoft Azure, the platform also supports operation with other leading **hyperscalers** such as: - Amazon Web Services (AWS) - Google Cloud Platform (GCP) - IONOS Cloud - Open Telekom Cloud - OVHcloud Here too: all systems are operated exclusively in **EU data centers** that comply with GDPR requirements. --- ## 4. On-Premises Operation at the Customer Site The CLARC Infinity platform can alternatively be operated fully at the customer's own **data center**. This classic **on-premises approach** provides maximum control over: - System access - Data storage - Security configuration - Network connectivity to internal systems (e.g., ERP, Active Directory) Organizations with special compliance requirements or without a cloud strategy benefit particularly from this option. The system is optimized for **Windows Server** infrastructure but is also compatible with other platforms if required. --- ## 5. AI Infrastructure (AI Runtime) A special component of the platform is its **own AI infrastructure**, used for services such as extraction, classification, or semantic search (RAG). The architecture is as follows: - **Standard operation via RunPod** (in the EU): Powerful GPU resources for training and inference. - **Own hosting possible**: The models used were fully trained in-house, are based on open-source architectures, and are therefore independent of external APIs or service providers. - **Containerized deployment**: AI models are deployed as services and can be integrated in Kubernetes or Docker environments. - **Separation of AI components from core systems** for better scaling and load distribution. --- ## 6. Data Protection and Security (Zero Trust by Design) Security and data protection are an integral part of the CLARC infrastructure strategy — regardless of the hosting provider. Key aspects: | Principle | Description | | --- | --- | | **Zero-Trust Architecture** | Every access is validated, even within trusted networks. | | **Encryption** | Data in transit and at rest is encrypted (TLS, AES). | | **Access logging** | All system accesses and actions are logged traceably. | | **Tenant isolation** | Strict logical and, where necessary, physical separation of all tenant data. | | **Restricted role permissions** | Minimum permissions per role and user (Least Privilege). | | **Hosting in the EU** | All data and services remain entirely within the scope of GDPR. | --- ## 7. Infrastructure on Your Terms Whether cloud-native, hybrid, or on-premises — the CLARC Infinity platform can be precisely aligned with your IT strategy. You decide how much control, scalability, and responsibility you want to take on. Thanks to comprehensive support for containerization, standardized interfaces, and multi-tenant configuration, CLARC Infinity can be seamlessly integrated into even the most complex IT landscapes. --- # System Requirements Source: https://clarc.com/docs/en/system-requirements.md # Technical Requirements for Using CLARC Infinity For reliable and high-performance operation of the CLARC Infinity Platform, certain technical prerequisites must be met on both the client and server side. These concern both general web access and special components such as the scanning client or the Cloud Connector in on-premises deployments. ## 1. Platform Options In addition to regular cloud or hybrid operations, CLARC Infinity also offers the option of fully autonomous **on-premises operation** — i.e. without connection to the central cloud infrastructure. This operating mode is primarily intended for security-critical deployment scenarios and requires independent infrastructure as well as **individual technical consulting and planning**. The operation encompasses both the application and AI components and can be fully implemented in your own data center in compliance with all compliance requirements. ## 2. Standard Requirements The following requirements are divided by deployment scenario: ### 2.1 Client (Standard Access – Web Browser) Standard use of the CLARC Infinity Platform via the browser-based user interface requires the following prerequisites: | Component | Requirement | | --- | --- | | **Web Browser** | Current version of **Microsoft Edge** or **Google Chrome** | | **Internet Connection** | **Broadband connection** (min. 10 Mbit/s recommended) | | **Operating System** | Any OS compatible with current Edge/Chrome | | **JavaScript** | Must be enabled | | **Cookies & Local Storage** | Must be allowed | :::note These requirements apply to all users accessing functions such as capture, validation, search, approval or administration via a web client. ::: ### 2.2 Client (Scanning Component) For using the **local scanning component**, particularly for integration of TWAIN-based scanners, extended requirements apply (in addition to the prerequisites listed under 1.): | Component | Requirement | | --- | --- | | **Operating System** | **Windows 10** or **Windows 11**, 64-bit | | **CPU** | At least **2 physical CPU cores** | | **RAM** | **12 GB RAM** or more recommended | | **.NET Framework** | **Version 4.8** or higher (fully installed) | | **Scanner** | Supports **TWAIN** with a matching **64-bit driver** | :::note **Note**: The **scanning component** runs via a locally installed runtime that **must be installed before first use**. ::: ### 2.3 Server (On-Premises for Cloud Connector) For hybrid scenarios or pure on-premises connections, the **CLARC Cloud Connector** establishes a secure connection between internal systems and the platform. Installation is performed on a server provided by the customer. | Component | Requirement | | --- | --- | | **Operating System** | **Windows Server**, 64-bit, one of the following versions: | | | **Windows Server 2016** (until approx. end of support 2027) | | | **Windows Server 2019** (until approx. end of support 2029) | | | **Windows Server 2022** (until approx. support until 2031) | | | **Windows Server 2025** (recommended) | | | **Linux** (on request) | | **CPU** | At least **2 physical CPU cores** | | **RAM** | **16 GB RAM** or more recommended | | **Database** | **MongoDB** 8.0 (ERP sync scenarios) | | **Administrator Rights** | **Required for installation and service setup** | | **Network Access** | Access to local systems (e.g. SAP, SQL, filesystem) | | **Outbound Access** | HTTPS access to the CLARC platform (URL approvals required), [https://cci001.app.clarc.com](https://cci001.app.clarc.com) (or others). For operating Infinity, a stable connection between local system components (e.g. servers and synchronization services) and the Infinity cloud is required. In individual cases, the firewall in use (e.g. Sophos) may incorrectly classify this connection as insecure and block or redirect traffic. Particularly with Intrusion Prevention System (IPS) enabled, this can lead to connection issues. If this behavior occurs, an exception rule (policy) must be defined in the firewall to ensure communication with the Infinity cloud. In particular, the domain [app.clarc.com](http://app.clarc.com) should be excluded from advanced security checks. | :::note **Optionally**, the server can be operated in a **DMZ**, provided the necessary ports and protocols are approved in compliance. ::: ## 3. Summary | Area | Main Requirement | | --- | --- | | **Web Client** | Current Edge/Chrome, internet access | | **Scanning** | Windows 10/11 (x64), .NET 4.8, 12 GB RAM | | **Cloud Connector** | Windows Server (2016, 2019, 2022, 2025), admin rights | The system requirements listed are **minimum requirements**. For production environments, especially under high load or with many simultaneous connections, correspondingly more powerful hardware is recommended. :::note **Regular system updates** and security policies must be **ensured by the operator**. ::: --- # Administration Source: https://clarc.com/docs/en/administration/index.md # Administration Area Overview The **Administration** area is the technical backbone of the CLARC Infinity Platform and consolidates all functions for **system configuration, process customization, monitoring and system integration**. It is primarily intended for administrators, system owners and platform operators, and provides the tools to adapt the platform to individual environments and requirements. --- **Note on terminology and structure:** The **terms, labels and structural elements** used in this documentation are consistently aligned with the **naming and arrangement within the user interface (UI)** of the CLARC Infinity Platform. The goal is to enable an **intuitive mapping between documentation and application** and to provide administrators and functional stakeholders with **as direct orientation and recognition as possible** — both when navigating the interface and when practically implementing configuration tasks. --- ## 1. Tools and Core Customizing The **Tools** section contains system-level utilities for diagnostics, error analysis and internal control. **Core Customizing** allows deep customization of fundamental system behaviors, components and technical parameters. :::note **Note**: These areas are exclusively available to **on-premises and private cloud customers**. For tenants operating in the public cloud, these options are disabled at the system level, as maintenance and operations are handled by the platform operator. ::: --- ## 2. System Configuration The **system configuration** enables targeted control of technical instance parameters, e.g.: - Tenant context - System names and system paths - Activation or deactivation of subsystems and functional modules - Definition of transport sources and targets - Cluster roles and tenant type (e.g. Development, Productive) This configuration is essential for **multi-stage system environments**. --- ## 3. Monitoring For operational monitoring, the system provides an integrated **monitoring module**. This allows: - Monitoring of task queues and process states - Error and event logging (incl. filtering by scopes and message types) - Insight into active system processes and background services - Status control of processing components (e.g. OCR, classification, connectors) Monitoring serves both **operational stability** and the **early detection of systemic issues**. --- ## 4. Process Customizing The administration area provides access to the **customizing of all functional processes** within the system: - Capture applications (forms, validations, plausibility rules) - Workflows (flow control, decision logic, role management) - DMS functionalities (document types, metadata, repositories) - Data extraction and classification (rule sets, training models) The customizing environment allows **fine-grained customization** — modular, versioned and transport-capable. --- ## 5. Deployment & System Integration Another essential part of administration is deployment and system connectivity: - **Installation and configuration of the Cloud Connector** for connecting to **on-premises systems** - **Setup of integrations with Azure AD / Microsoft 365**, e.g. for: Single Sign-On (SSO) - Use of Office add-ins - Access to Microsoft Graph APIs Connection of external systems via API, gateway or connector This area enables **seamless integration with existing infrastructures**, whether hybrid, on-premises or cloud-based. --- ## 6. Summary The **Administration** area is the central control center of the CLARC Infinity Platform. It encompasses all relevant technical and operational functions needed for setup, ongoing operation, system customization and integration. While cloud customers can only access selected administrative functions, on-premises administrators have the full spectrum of tools available to deeply configure, extend and integrate the system into the existing IT landscape. --- # General Source: https://clarc.com/docs/en/administration/general/index.md # Technical Fundamentals of Configuration and Administration Regardless of whether the CLARC Infinity Platform is operated in the cloud, on-premises or in a dedicated cluster, all administrative areas follow uniform and overarching fundamental principles. These ensure that configurations, extensions and integrations remain **consistent, traceable and cross-system usable**. The core paradigms include: - **Configurability via structured data formats** — System and application settings are standardized in **JSON formats** or — for technical core components — in the **system registry**. These formats are human- and machine-readable, versionable and uniformly usable across all configuration areas. - **Decoupling of interface and logic** — Functional logic, UI structures, resources and behavior are managed separately. This enables **flexible customizing** without requiring changes deep in the system code. - **Environment context through parameterization** — Settings, services and paths are built in a **tenant- and system instance-specific** way. This allows central platform concepts such as _Development → Test → Production_ or multi-tenancy to be technically clearly separated and secured. - **Standardized object management** — Technical objects (e.g. scripts, conversion rules, access profiles) are managed system-wide as **structured nodes** with identity, version and metadata. This applies to both clients and backend components. - **Technology-neutral management layer** — The underlying management logic is deliberately designed to be **platform-independent** — whether in a pure browser client, on a Windows server or within a tenant-specific cluster deployment. These general principles create a **robust and consistent foundation** for all administrative tasks — from local scripting to system-wide configuration inheritance — and form the methodological framework for all subsequent sections of this documentation. --- # Tenants Source: https://clarc.com/docs/en/administration/general/tenants.md # Tenants in the Context of the CLARC Infinity Platform A _tenant_ in the CLARC Infinity Platform refers to an **independent, logically self-contained instance** that is typically assigned to a **customer, business unit, location or organizationally separate area of responsibility**. Each tenant forms an **autonomous environment** with fully separated data storage, user management, role and permission structures, and its own customizing. ## 1. System Landscape A tenant has its own **system landscape**, consisting of clearly defined environments such as: - **Development** (for development and configuration) - **Test** (for quality assurance and acceptance) - **Productive** (for live operations) - **Sandbox** (for free testing and piloting) - **Training** (for training scenarios with production-like conditions) Additionally, per tenant, **access to licensed modules**, extraction technologies, data sources and integrations can be individually configured and controlled. **Tenant isolation** is a central architectural principle and ensures: - **Data security** (no visibility across tenant boundaries) - **Configuration autonomy** (tenant-specific customizing) - **Scalability and multi-tenancy capability** (e.g. in platform operations or cluster operations) A tenant is thus the **central organizational and technical encapsulation unit** on which all administrative, operational and functional processes within the platform are built. --- ## 2. Internal Access Profiles and Access Encapsulation Within the CLARC Infinity Platform, **internal access profiles** are used that serve **exclusively for the secure separation and control of system-internal accesses**. ### 2.1 Function and Scope An internal access profile is **automatically and context-specifically generated for each session and each request**. It defines the **tenant-specific execution sphere** within the system and ensures that: - **only data and resources of the active tenant** can be accessed, - **cross-tenant accesses are technically excluded**, - and **system-internal services, scripts or tasks** operate exclusively within their assigned context. This internal access encapsulation applies to: - Server processes (e.g. workflow execution, classification) - Client requests (e.g. UI interactions, API accesses) - Integration services within the tenant (e.g. OCR, conversion, logging) - Logging and auditing (tenant-local scope only) ### 2.2 Security Effect The internal access profiles are a central component of the **multi-tenant security concept** of the platform. They form the basis for ensuring that all system-side operations are **technically isolated from the tenant context** and that clean **data and access separation** is guaranteed — even in distributed, multi-instance or cross-tenant environments (e.g. in cluster operations). ### 2.3 Summary This architecture ensures that **no data or context confusion between tenants** is possible — regardless of which service or user context is active. The internal access profiles are thus a **fundamental building block of the security and integrity architecture** of CLARC Infinity. --- # Configuration Elements Source: https://clarc.com/docs/en/administration/general/configuration-elements.md # Base Configuration of Services and Client Applications **Uniform and flexible configuration model for all system components** Both technical services and client applications within the CLARC Infinity Platform are based on a **uniform, structure-oriented configuration model**. The goal is to make configuration **cross-platform, declarative and prioritizable** — regardless of whether it is an on-premises installation, a cluster environment, or a local client. All configuration values are based on a common, hierarchical structure and can be sourced from various origins — depending on the operating model, the application purpose, or the deployment context (e.g. container, service, interactive client). --- ## 1. Priority of Configuration Sources When loading configurations, a **fixed priority order** is followed. The first definition found for a parameter is used. Sources are evaluated in the following order: | Priority | Source | Description | | --- | --- | --- | | 1 | **Launch parameters** | Passed directly at application startup (e.g. `--Log_Level=ccLL_Debug`) | | 2 | **Environment variables** | Set system-wide or per process (e.g. `Log_Level=ccLL_Debug`) | | 3 | **JSON configuration file** | Structured file on the filesystem (activated via launch parameter or environment variable `Base_ConfigFile`) | | 4 | **Windows Registry HKCU (service-specific)** | Path under `HKEY_CURRENT_USER\Software\CLARC\Infinity\` | | 5 | **Windows Registry HKLM (service-specific)** | Path under `KEY_LOCAL_MACHINE\Software\CLARC\Infinity\` | | 6 | **Windows Registry HKCU (global/system-wide)** | Path under `HKEY_CURRENT_USER\Software\CLARC\Infinity\System` | | 7 | **Windows Registry HKLM (global/system-wide)** | Path under `HKEY_LOCAL_MACHINE\Software\CLARC\Infinity\System` | :::note If a configuration value is found multiple times, **the higher-priority entry always applies.** ::: --- ## 2. Structural Principles of Configuration Values All configuration sources follow **the same logical structure**, regardless of storage location. The structure is based on the underlying **JSON configuration**, with the following conventions applying to environment variables, launch parameters and the registry: | Element Type | Conversion / Structure | | --- | --- | | **Nesting** | `.` → `_` (e.g. `Logging.Level` → `Logging_Level`) | | **Arrays** | With index access `[]` (e.g. `Workers[0]_Name`) | | **Launch parameters** | `--Path_Value=...` (e.g. `--Database_ConnectionString=...`) | | **Environment variables** | Definable directly as KEY=VALUE | | **Registry** | Hierarchical structure analogous to the JSON structure | --- ## 3. Using JSON Configuration Files To use a configuration file in JSON format, an explicit reference to the file must be set at startup — either as: - **Launch parameter**: `--Base_ConfigFile=C:\path\to\system.json` - **Environment variable**: `Base_ConfigFile=C:\path\to\system.json` This file can then contain all relevant configuration values — for example: ``` { "Base": { "ApiKey": "ThisIsASecret", "ServiceApiKey": "MoreSecrets", "RootUrl": "http://localhost:8080", "RegistryRootUrl": "http://localhost:8083", "Environment": "ccSE_OnPremises", "MaxTempFileAge": 3600, "Daemon": false, "CleanUp": false, "DefaultLanguage": "EN", "DefaultLocation": "US", "ShowStartLogo": false }, "Paths": { "Log": "c:\\clarc\\log", "Config": "c:\\clarc\\cfg", "Temp": "c:\\clarc\\temp", "Shared": "c:\\clarc\\shared", "Pub": "c:\\clarc\\pub", "Data": "c:\\clarc\\data" } } ``` --- ## 4. Default Values and Fallback Mechanism All configuration parameters have **predefined default values** that are applied when no value has been defined via any of the described sources. This ensures that services are **fundamentally startable** even with minimal or missing configuration. --- ## 5. Encryption of Sensitive Values For security-relevant configuration entries such as credentials, tokens, license keys or API secrets, the CLARC Infinity Platform offers the ability to **store configuration values in encrypted form**. This increases operational security and protects sensitive data from unauthorized access — even with local access to the registry or configuration files. ### 5.1 Encryption Principle Each encrypted configuration value is identified via an **additional flag**. The key name is supplemented with `_Encrypted` and set to `true`. ### 5.2 Example Structure (Registry or JSON): ``` "TenantAccess": { "acme": { "Development": { "User": "Service", "Password": "XK9h32asdj...==", "Password_Encrypted": true } } } ``` :::note **Important**: The actual encrypted value is already in encrypted format and cannot be created manually. ::: ### 5.3 Creating Encrypted Values Encryption of values is performed via the **CLI tool** of the CLARC Infinity Platform. This provides a command to convert a plaintext value into an encrypted entry. See [Command Line Tool (CLI)](#administration/core/cli) **Example (CLI tool):** ``` tools encrypt -t "my-secret-password" ``` **Output:** `XK9h32asdj...==` (Base64-encoded ciphertext) This value is then transferred to the configuration — together with the `_Encrypted: true` flag. ### 5.4 Usage Notes - Decryption occurs **automatically at runtime** by the respective service or client. - Encrypted values can be used in all configuration sources: registry, JSON file, environment variable. - Entries without `_Encrypted: true` are **interpreted as plaintext**. --- ## 6. Summary | Feature | Description | | --- | --- | | **Uniform Schema** | All configuration sources follow the same logical structure | | **Cross-platform** | Supports Windows Registry, environment variables, launch parameters and JSON files | | **Prioritizable** | Clearly defined priority order — configuration is easy to control and override | | **Declarative** | Configuration contents are fully structured, portable and versionable | | **Safe Fallback** | System startup with sensible default values possible when configuration is missing | --- The flexible, modular and standardized configuration model of the CLARC Infinity Platform ensures that **operation, maintenance and deployment** can be implemented **robustly, controllably and automatable** — both in local and scaling cluster operations. --- # Core Source: https://clarc.com/docs/en/administration/core/index.md # System-Wide Configuration for Self-Hosted Deployments (Core Customizing) **Core Customizing** is a special configuration area of the CLARC Infinity Platform that is exclusively available in **on-premises installations** or in a **dedicated cluster operation**. It allows system-wide control and extension of technical parameters that go beyond regular tenant-specific customizing. In Core Customizing, the following areas are centrally managed, among others: - Platform paths and global system variables - Default values for cross-tenant functions - Configuration of technical integration components - Base settings for services, directories or logs - Default values for automated tenant creation or deployment processes Core Customizing **directly affects the system-wide platform logic** and should only be used by experienced administrators with appropriate system responsibility. It forms the foundation for **operational fine-tuning and control of technical base components** that are effective in the shared context of multiple tenants or at the infrastructure level. --- # Command Line Tool (CLI) Source: https://clarc.com/docs/en/administration/core/cli.md # CLARC Infinity CLI – Command Line Tool for Administration and Integration The **CLI tool** for CLARC Infinity is a powerful instrument developed specifically for managing and interacting with CLARC Infinity via the **command line interface**. It provides a range of functions that enable users to work efficiently with various aspects of the CLARC Infinity platform. :::note The CLI tool is only available in on-premises deployments of the software and cannot be used when operating as a cloud service. ::: --- ## 1. Key Features 1. **Tenant Login:** The first and most fundamental step is logging in as a tenant. This process allows users to securely authenticate within their specific tenant context in order to access all relevant resources and functions. 2. **Setting Up a New System:** This tool allows users to quickly and efficiently configure and set up a new system within the CLARC Infinity environment. This process includes establishing the required base infrastructure and the basic configuration of the system. 3. **Browsing the C4 Database:** A central function of the tool is browsing the C4 database, which is structured like a file directory. Administrators can navigate through the database to find or manage specific information. 4. **Viewing and Creating Nodes:** Administrators can view nodes within the database and create new nodes. This functionality is important for the organization and management of data within the CLARC Infinity system. 5. **Importing Data:** Another important function is importing data and documents into the system. This allows administrators to integrate existing data into the CLARC Infinity environment. 6. **Creating New Tenants:** The CLI tool supports the rapid and standardized creation of new tenants within the CLARC Infinity platform. All components required to operate a tenant are initialized — including database structure, BLOB storage, system instances (e.g. Development, Test, Productive) as well as base permissions and configurations. Through defined templates and automated processes, tenant creation can be performed consistently, reproducibly and with minimal manual effort — a decisive advantage especially for operators of multi-tenant environments or dedicated clusters. In summary, the CLI tool for CLARC Infinity provides a comprehensive and user-friendly interface for managing and interacting with the CLARC Infinity platform, making it an indispensable tool for users who want to work efficiently with this advanced application. --- ## 2. Starting the CLI Tool The CLI tool for CLARC Infinity is started by executing the file `cci.exe`. After starting, the tool automatically initiates the login process, in which the user must enter their credentials. If necessary, this login process can be cancelled by pressing the `Esc` key to resume at a later time. The CLI tool provides a range of standard functions that are essential for efficient navigation and management of the CLARC Infinity platform. These commands allow users to perform basic tasks such as login, system navigation and displaying information. The following provides a brief overview of the available standard commands. --- ## 3. Standard Commands 1. `help` or `?`: Displays a help overview of the available commands. With the `?` tag, users can obtain specific information about particular groups or commands. 2. `exit`: Ends the current session in the CLI tool and closes the program. 3. `login`: Allows the user to log in to the CLARC Infinity environment. 4. `logout`: Logs the user out of the current session. 5. `cls`: Clears the current screen content and provides a fresh view for new commands. 6. `cd [path or >>node-ID]`: Changes the current directory or navigates to a specific node in the system structure. Users can use a path or a specific node ID to navigate. 7. `ls [-a]`: Lists all nodes in the current directory. With the `-a` flag, additional information such as the node ID is displayed. 8. `history`: Displays the most recently executed commands. --- ## 4. Additional Features - **Full Access Rights**: To execute a command with full access rights, use the `crud` prefix (create, read, update, delete) before any command. This is useful for advanced operations or administrative tasks. The use of `crud` is highlighted in color by the system and acknowledged with the text "command is executed with full access rights (crud)". - **Command Shortcuts**: Both command groups and individual commands can be abbreviated to enable faster and more efficient operation. --- ## 5. Example The command `system initialize` is an important part of the CLI tool used for the **initial configuration** and **setup of the system**. Here is an example of how this command can be used as a shortcut: `sys init` --- ## 6. Command Groups **Overview of Command Groups and Special Commands** The CLARC Infinity Command Line Interface (CLI) offers a modular structure in which commands are organized thematically by so-called **command groups**. Each group contains specific functions that can be used specifically for certain administrative, development or system operations. :::note Comprehensive help is available for each command via ` ?`. ::: Below is an overview of the most important available groups and their typical use cases: ### 6.1 sys – System Commands Manages fundamental system functions of the platform instance. | Command | Description | | --- | --- | | `info` | Displays general system information | | `initialize` | Initializes the core system (only required once per instance) | | `update` | Executes a system update | | `log` | Displays internal logs (`-t e` for errors, `-t a` for all entries) | ### 6.2 tools – Utility Commands Tools for key generation, encryption, and more. | Command | Description | | --- | --- | | `encrypt` | Encrypts a string or file (for registry/config values) | | `generate` | Generates IDs or hashes (e.g. UUIDs via `-t uuid`) | ### 6.3 c4 – C4 Configuration Management Management of nodes in the C4 file tree (customizing objects, scripts, configurations, etc.). | Command | Description | | --- | --- | | `show` | Displays the content of a C4 node | | `create` | Creates a new empty node | | `delete` | Deletes nodes (optionally recursive) | | `move` | Moves a node to a different path | | `locate` | Finds nodes by name (regex possible) | | `export` | Exports node data to a `.json` file | | `import` | Imports node data from `.json` | ### 6.4 transport – Transport Management Manages the transport of customizing objects between systems (e.g. Dev → Test → Prod). | Command | Description | | --- | --- | | `list` | Lists existing transports | | `show` | Shows details of a transport | | `create` | Creates a new transport | | `add` | Adds paths to a transport | | `remove` | Removes paths from a transport | | `import` | Imports a `.zip` transport into the local system | | `export` | Exports a transport to a `.zip` file | | `delete` | Deletes a transport | | `transport` | Executes the transport to the target system (optionally with `-a` for downgrade) | ### 6.5 repo – Repository Management Manages documents and metadata in the repository. | Command | Description | | --- | --- | | `import` | Imports documents from `.json` files into a repository (via repository and business object ID) | ### 6.6 tenant – Tenant Management Commands for creating and maintaining tenants. | Command | Description | | --- | --- | | `create` | Creates a new tenant including company name, admin email and password | | `license` | Stores or updates a license file (`.lic`) | | `update` | Updates the database structure of a tenant | --- # System Source: https://clarc.com/docs/en/administration/system/index.md # System Configuration of the CLARC Infinity Platform The CLARC Infinity Platform is a modern, multi-tenant enterprise platform for document processing, process automation and integration management. To operate it securely, scalably and operationally consistently, it has a **multi-layered system configuration** in which fundamental operating parameters are controlled per tenant, per instance and per environment. This documentation provides an overview of the **central configuration areas** and explains their tasks and interactions: --- ## 1. Tenant Configuration The **Tenant Configuration** area defines all **tenant-specific settings** at the organizational and technical level. These include: - Company and contact information - Email addresses for administration, billing and system notifications - Storage and verification of **trusted domains** (e.g. for SSO via Microsoft 365) - Display of active **functional modules and licenses** (e.g. DMS users, Invoice/Order extraction) - Display of the **tenant priority** within the cluster - Display of **functional rights** for transport import and export This area is the central control point for **tenant-wide identity, communication, security and license control**. --- ## 2. Transport Management The **transport module** forms the foundation for the **controlled transfer of configuration objects** between the system environments of a tenant. Transport chains are defined here, for example: `Development → Test → Productive` Customizing objects such as field schemas, UI scripts or workflow definitions can be versioned and transferred in a controlled manner. This is supported by: - **Simulation of transports** with logging - Options such as `Allow Downgrade`, `Overwrite` and `Force` - Export/import of transport containers (e.g. for migration or tenant backup) - Change Lock and Change History to ensure consistency and traceability Transport management is essential for the **seamless, quality-assured operation of configurations** across multiple system stages. --- ## 3. System Instance Configuration Each tenant environment consists of multiple **system instances** such as _Development_, _Test_, _Productive_, _Training_ or _Sandbox_. The following settings can be managed separately for each of these instances: - **Change Lock**: Lock for direct customizing changes - **Change Recording**: Change logging at transaction level - **Change History**: Version history with recovery options - Permitted **transport sources and targets** This configuration ensures that **system behavior, rights and transport paths are precisely defined per instance** — for maximum security, traceability and operational stability. --- ## 4. Migration For transitioning from CLARC Enterprise to CLARC Infinity, a dedicated **migration module** is available. It enables the transfer of selected configuration data from an existing system: - Importable: **Users**, **Groups**, **Field schemas** - Based on a **C4 XML export** from the legacy system - Upload, analysis and conflict checking in the target system - Selective import with optional conflict handling Migration is the recommended approach for **gradually transferring existing structures** without having to reconstruct them manually. --- The configuration areas **Tenant**, **Transport**, **System Instance** and **Migration** together form the foundation for the **operationally secure, scalable and tenant-separated use** of the CLARC Infinity Platform. They support both agile development processes and highly regulated operating models — always with the goal of **balancing flexibility and governance**. --- # Tenant Source: https://clarc.com/docs/en/administration/system/tenant.md # Tenant Configuration in the CLARC Infinity Platform The **Tenant Configuration** is the central administrative interface for managing a tenant within the CLARC Infinity Platform. It defines **fundamental properties** such as company data, contact information, system rights, security domains and the available **license modules**. The configuration is typically specified by the system or the platform provider — with limited modification options for the tenant administrator. --- **Tenant:** A _tenant_ in the CLARC Infinity Platform refers to a **logically and data-technically self-contained instance** assigned to a **customer, business unit or organizationally separate usage context**. Each tenant has its own system landscape (e.g. Development, Test, Productive), individual data storage, its own user and rights management, and specific customizing. The separation between tenants is **fully multi-tenant capable** and guarantees **data security, configuration autonomy and operational isolation**. --- ## 1. Tenant (Client) The **Tenant** section defines the official company name and an optional alternative display name. This information is used for system-internal identification and display of the tenant. --- ## 2. Address The address fields contain standard information such as: - Title, first name, last name (typically a contact person) - Street, house number - Postal code, city - Country This information is optional and serves primarily for formal assignment (e.g. for billing documents or contract partner information). --- ## 3. Contact Information Of particular importance in this area are the **email addresses**, as they serve various functional purposes and are in some cases system-critical. | Field | Meaning | | --- | --- | | **Administration Email** | Primary contact address for administrative notifications and system messages | | **Registration Email** | Address for registering the tenant. This is fixed and cannot be changed | | **Backup Email** | Alternative contact address, e.g. for recovery purposes or failover scenarios | | **Common Email** | General email address for unclassified communication | | **Information Email** | Recipient for system-related notices and status messages | | **Invoice Email** | Responsible for delivering invoices and billing information | It is recommended to use **functional email mailboxes** (e.g. `admin@`, `it@`, `finance@`) instead of personal mailboxes to ensure availability and role independence. --- ## 4. Trusted Domains The **Trusted Domains** section is relevant for **linking external identity providers** — particularly for **SSO (Single Sign-On) with Microsoft 365**. ### Purpose By storing a trusted domain (e.g. `company.com`), it can be ensured that users authenticated via Entra ID (Azure AD) or other identity services are assigned to the correct tenant configuration. ### Verification Verification is performed by setting a **DNS TXT record** with a token generated by the system. The process: 1. Enter the domain 2. System provides the DNS TXT value 3. Set the DNS record in the respective DNS zone editor 4. Confirmation and verification by the system :::note Only after successful verification is the domain considered "trusted" and valid for SSO purposes. ::: --- ## 5. License Modules (Available Features) The **available modules** section displays **which functionalities have been activated for the tenant**. These include, among others: - Number of available DMS users - Licenses for specific extraction components such as: **Invoice Extraction** - **Order Extraction** - Further AI-based classification or reading modules :::note Modules are activated on a tenant-specific basis and correspond to the contractually agreed usage rights. ::: --- ## 6. Priority in the Cluster Within the CLARC Infinity Platform, each tenant is assigned a **priority level** that determines its **processing priority in the overall cluster**. This setting particularly affects the **distribution and parallelization of background processes** such as document processing, OCR, AI extraction or workflow tasks. :::note The priority is relevant system-wide and is typically set by the platform operator or central infrastructure management. **Changes by tenant administrators are not possible**. ::: ### Available Priority Levels | Priority Value | Description | | --- | --- | | **Idle** | Operations are only processed when no higher-priority tasks are active. | | **Lowest** | Very low priority. | | **Lower** | Limited processing capacity. Suitable for tenants with low system load. Suitable for productive tenants without special SLA requirements. | | **Normal** | Standard behavior. Suitable for productive tenants without special SLA requirements. | | **Higher** | Preferred processing. | | **Highest** | Very high priority. Tenants with elevated service level requirements or productive high-load environments. | | **TimeCritical** | Highest available priority in the system. Operations are immediately prioritized, even under high overall load. Typical for time-critical automations or real-time scenarios. | ### Effect in Operation The priority directly affects the **task dispatcher logic** and **event management in the cluster**. With limited resources (CPU, RAM, processing slots), tasks from tenants with higher priority are **queued earlier and executed faster**. --- ## 7. Functional Rights This section defines whether the tenant **is permitted to export or import transport data**. These rights are security-relevant and binding across systems. | Function | Description | | --- | --- | | **Export transport** | Allows the **export of customizing packages** from this tenant | | **Import transport** | Allows the **import of transport packages** into this tenant | :::note These rights **cannot be changed by the tenant administrator** and are managed exclusively by the platform management. ::: --- ## 8. Summary The tenant configuration controls central organizational and system parameters of a tenant. It governs: - Company and contact information - Trusted external identities (domains) - Access to license and functional modules - Processing capacities in the cluster - System-wide transport rights It is therefore an essential component for **secure, consistent and tenant-separated operation** within the CLARC Infinity Platform. Changes to security-relevant fields are made exclusively through authorized representatives of the platform operator. --- # Transport Source: https://clarc.com/docs/en/administration/system/transport.md # Transport Management and Transport Concept of the CLARC Infinity Platform Transport management in the **CLARC Infinity Platform** forms the central backbone for the **systematic, traceable and consistent transfer of configuration data and customizing objects** between the various system stages of a tenant. It ensures that all changes are made in a controlled and documented manner — regardless of whether they are technical, functional or organizational in nature. --- ## 1. System Landscape (Tenant Structure) Each tenant has by default a dedicated system landscape consisting of the following environments: | System | Purpose | | --- | --- | | Development | Development, configuration, customizing | | Test | QA, acceptance and integration tests | | Productive | Production operations | | Sandbox | Free environment for tests and experiments | | Training | Training system with production-like conditions | ### 1.1 Data Architecture and Storage Separation In addition to the functional separation of the tenant landscape into **Development**, **Test**, **Productive**, **Sandbox** and **Training**, a **technical separation of the underlying data storage** also takes place. Each tenant has its own **independently logically isolated database instance** to ensure maximum **data security, tenant separation and scalability**. ### Data Layer Structure The platform distinguishes between two central storage areas: | Area | Description | | --- | --- | | **Database** | All **configurable system data** is stored here, e.g. business objects, users, workflows, customizing elements, logs, transactions and status information. The data is stored relationally in a tenant-specific database structure. | | **BLOB Storage** | Binary data such as documents, images, OCR results or conversion outputs are managed **in a separate, high-performance object store** (blob storage). This is also segmented on a tenant-specific basis. | This separation allows **optimized processing and scaling**, as structured data and mass data (e.g. scans, PDF files) can be **stored and offloaded independently of each other** — e.g. to cloud-based storage, network drives or high-performance data containers. ### Advantages of This Architecture - ✅ **Tenant separation at data level**: No mixing of system states, configurations or documents - ✅ **Scalability and performance**: Database load and file storage are scaled separately - ✅ **Security and backup concept:** Applied granularly at these levels --- ## 2. Transport Concept – Process and Principles ### 2.1 Standard Process: Transport Chain The typical workflow for transferring new processes or customizations proceeds in the following order: `Development → Test → Productive` - **Development**: Setup and development of new processes - **Test**: Review, quality assurance, integration tests - **Productive**: Release and deployment for end users ### 2.2 Transport Routes Transport targets and sources are **freely configurable per system**. For example, the test system can be **skipped** if desired (not recommended): - Example: `Development → Productive` (for urgent hotfixes) - Imports from external source systems are also possible (e.g. partner tenant or template tenant) --- ## 3. Transport Types ### 3.1 System-Internal Transport - Directly via the transport function between the configured target systems - Supports standard objects, custom objects, as well as user and group information ### 3.2 Export/Import via File - Transports can be **exported** as a file - Import into other tenants is possible (e.g. migration, tenant copies) - Per transport, it is **configurable** into **which target systems** an import is permitted (whitelist) --- ## 4. Object Types in Transport | Object Type | Transportable | Notes | | --- | --- | --- | | Customizing objects | ✅ | incl. transactions and history | | Users / Groups | ✅ | Technically possible, but **local management** is recommended | | System paths under `/CLARC/BPI/` | 🟡 | Only the "customizing shell" (node), **no configurations** such as ERP connections | :::note ERP or third-party system connections differ per system (e.g. different URLs, credentials) and must be maintained locally in the target system. ::: --- ## 5. Change Lock & Change History ### 5.1 Change Lock - **Configurable per system** - Prevents changes to customizing objects outside of transport operations - **Active by default in the production system** - Ensures consistent states across all environments ### 5.2 Change History - **Activatable per system** - All changes to customizing objects are recorded in **transactions** - Enables: **Rollback to earlier states** - **Comparison of versions** Accessible via: - Associated **transports** - Context menu of the respective customizing object --- ## 6. Control and Traceability - Each transport is **logged** by the system - Information includes: Timestamp - Source & target system - Content / object types - User Traceability via change logs and transaction references --- ## 7. Transport Simulation (Pre-Check) Before the actual transport operation, the CLARC Infinity Platform offers a **simulation function** with which the entire transport can be **dry-run** without making any changes to the target system. #### Purpose of Simulation - Validation of **transport contents** - Checking for **conflicts, inconsistencies or version issues** - Determination of **affected objects, dependencies and system reactions** - Preview of resulting **log messages** and system actions #### Result of Simulation The simulation generates a detailed **log protocol** that includes, among others, the following information: | Type | Description | | --- | --- | | Object types | Which objects in the target system would be affected | | Version conflicts | Notice for downgrade or differing timestamps | | Dependency errors | If linked objects are missing | | Validity | Check whether the target system is approved for import | | Lock status | Check for active **Change Lock** | | Customizing conflicts | Differences in system-dependent settings | --- ## 8. Transport Options When creating a transport, the **Include Metadata** option can be set. This causes object information such as descriptions and icons to be transported as well. During the actual transport, three extended options can be set to handle **deviating requirements or special cases**: | Option | Description | | --- | --- | | **Allow Downgrade** | Allows the import of older object versions than those already present in the target system. By default, the system prevents downgrades to protect against data loss. | | **Overwrite** | Overwrites existing objects in the target system even when no versioning conflicts exist. Useful for intentionally redundant deployments. | | **Force** | Forces the transport regardless of change locks, system approvals or validity checks. This option should be used exclusively for emergencies and is disabled by default. | :::note **Important**: The use of Allow Downgrade and Force should be carefully reviewed and only applied after consultation with the responsible system administrator. ::: --- ## 9. Best Practices | Topic | Recommendation | | --- | --- | | User and group management | Maintain locally in the target system | | ERP connections (e.g. RFC settings) | Reconfigure in the target system | | Production system | Always work with Change Lock enabled | | Recovery | Enable Change History, export regular snapshots | | Tests before go-live | Check transports in test system first (CI/CD principle) | --- ## 10. Conclusion The transport management of the CLARC Infinity Platform provides a **structured, traceable and secure method for transferring customizing and configuration**. It supports agile development processes as well as highly regulated operating environments. Through features such as Change Lock, versioning and cross-system transport paths, a **controlled and documented lifecycle** of processes and configurations is ensured — across all system levels. --- # Instance Source: https://clarc.com/docs/en/administration/system/instance.md # System Instance Configuration for Transport Control The configuration per system instance defines **how transports, customizing changes and change histories** are handled in a specific environment (e.g. _Development_, _Test_, _Productive_). It forms the **technical foundation for a secure and traceable transport concept**. --- ## 1. Change Control (Change Protection) The following settings define whether and how changes within the system instance may be made, recorded or versioned: | Setting | Description | | --- | --- | | **Change Lock** | Locks direct changes to customizing objects. Changes are only possible via transports. | | **Change Recording** | Activates the logging of all changes to customizing objects. | | **Change History** | Activates the versioning of objects. Earlier states are visible and can potentially be restored. | 🔒 **Change Lock** prevents direct changes and enforces a clean separation between configuration and operations. 📝 **Recording** and 📚 **History** ensure full traceability and allow rollbacks for misconfigurations. --- ## 2. Transport Paths Transport paths define **permitted sources and targets** for transports to ensure controlled movement of configurations between systems. ### 2.1 Transport Sources Specifies **from which systems transports may be imported into this instance**. ✅ Typical examples: - `Development` - `Test` - `External` 🚫 Unwanted sources can be excluded, e.g. direct transports from production systems. --- ### 2.2 Transport Targets Defines **to which systems transports may be performed from this instance**. ✅ Possible target systems: - `Test` - `Training` - `Productive` - `Sandbox` - `External` By restricting to approved targets, it is ensured that **no accidental transports** occur to critical or functionally inappropriate environments. --- ## 3. Interaction of Options | Goal | Recommended Setting | | --- | --- | | **Secure production system** | Change Lock ✅, Recording ✅, History ✅ | | **Keep development flexible** | Change Lock ❌, Recording ✅, History ✅ | | **Controlled test system** | Change Lock optional, Recording ✅ | | **Increase transparency** | Enable Change History in all systems | | **Allow targeted transports** | Define Transport Sources & Targets specifically | --- ## 4. Advantages of System Instance Configuration - Prevention of uncontrolled changes in production systems - Complete change tracking across all environments - Rollback functionality for faulty configurations - Controlled transport flow between systems - Support for cross-tenant deployments via external exports --- This configuration is a central element for implementing a **clean, maintainable and audit-safe lifecycle management** within the CLARC Infinity Platform. It enables the different requirements of development, test and production systems to be precisely reflected. --- # Migration Source: https://clarc.com/docs/en/administration/system/migration.md # Migration from CLARC Enterprise to CLARC Infinity The CLARC Infinity Platform provides an **integrated migration function** to transfer **existing configuration data** from a legacy **CLARC Enterprise system** into a new CLARC Infinity instance. The goal is to transfer central data such as users, groups and field schemas without loss, to enable a smooth system transition or a parallel new setup. --- ## 1. Supported Migration Objects The migration currently supports the following object types: | Object Type | Description | | --- | --- | | **Users** | All users including metadata, permission assignments, etc. | | **Groups** | Structured user groups incl. hierarchy and roles | | **Field Schemas** | Definitions of fields for capture applications or metadata assignments (target: business objects) | --- ## 2. Migration Process The migration is carried out in several clearly defined steps: ### Step 1: Export in the CLARC Enterprise System In the source system (CLARC Enterprise), a **data export of the C4 configuration database** must be performed. This export generates a **structured XML file** containing all relevant migration objects. - Prerequisite: Access to the administration interface of the source system - File format: `C4Export.xml` ### Step 2: Upload in CLARC Infinity In the target system (Infinity), the export file is uploaded via the **migration interface**. - Access via the administration menu: _System → Migration_ - Select the XML file from the local file system - Upload is checked and analyzed server-side ### Step 3: Analysis and Display of Migration Contents After successful upload, the system displays a **list of all migratable objects**. For each object, the following is shown: - Object type (user, group, field schema) - Name and technical ID - Migration status (e.g. "New", "Conflict", "Already exists") - Notes on possible conflicts (e.g. same IDs or name overlaps) ### Step 4: Selection of Objects to Import The administrator can specifically select **which objects should be imported**. It is possible to transfer only specific categories or individual objects. - Optional: Overwrite existing objects (with warning) - Selection via checkbox or bulk operation ### Step 5: Import into the Target Instance After confirmation, the selected objects are transferred to the current Infinity system. Each action is logged and checked for integrity. Objects with conflicts can be ignored or processed in a separate pass. --- ## 3. Conflict Handling Conflicts typically arise with: - **Name duplicates** of objects - **Duplicate IDs** for users or groups - **Different structures** in the target system (e.g. missing roles, outdated fields) The system clearly marks affected objects and allows the user to: - skip the objects - overwrite existing entries (if explicitly permitted) --- ## 4. Security and Traceability All migration operations are **fully logged**: - User, timestamp and system instance - Imported objects and their status - Log entries for errors or conflicts --- ## 5. Benefits of Migration - Smooth transfer of proven configurations - Minimization of manual post-processing - Consistency check before system change - Flexible partial migration possible (not all or nothing) - Foundation for hybrid operating scenarios --- ## 6. Summary | Step | Description | | --- | --- | | Export | XML export from the CLARC Enterprise system | | Upload | Upload the export file into CLARC Infinity | | Analysis | Display of objects and conflict checking | | Selection | Selection of desired objects for transfer | | Import | Transfer of data to the target system incl. log | --- The migration function enables a **structured system transition**, e.g. when introducing CLARC Infinity in existing customer environments or when consolidating multiple installations. Additional migration paths and object types are modularly extensible. If desired, migration can also be integrated into existing CI/CD processes via scripting interfaces or automated exports. --- # Monitoring Source: https://clarc.com/docs/en/administration/monitoring/index.md # Monitoring Processes and System States in the CLARC Infinity Platform The **Monitoring** area of the CLARC Infinity Platform provides all central tools to monitor the **state of the system and the progress of document-based processes** in real time and retrospectively. The goal is to **display the operational status transparently**, detect errors early and enable fast analysis and troubleshooting. Monitoring is an integral part of technical operations and supports both **platform administrators**, **support teams** and **functional process owners**. --- ## 1. Document Hub (Process Queue) The **Document Hub** — also known as the **Process Queue** — forms the **operational heart of all document-related operations** in the system. It monitors, controls and documents the complete lifecycle of a document from intake to final archiving or handover to a target system. ### 1.1 In Monitoring, the Document Hub includes: - **Overview of all active operations**, including status and task - **Insight into process histories** (e.g. capturing, classification, extraction, workflow) - Display of **error states, interruptions and user interactions** - **Visual status display** showing which phase a document is currently in - **History and notes** captured during processing The Hub thus enables targeted **error localization, clarification case handling and performance monitoring** — down to the individual document level. --- ## 2. Logging The **Log module** provides complete logging of all system-relevant events — from internal error states to API accesses, user actions and background processes. ### 2.1 Main functions of logging in monitoring: - **Real-time view of current messages** - Filtering by: time window, message type (Error, Info, Debug, etc.), scope (e.g. IAM, API, Workflow, Repository), tenant and system instance **Detailed view of individual log entries**, including: - Message ID and technical error code - Thread and instance assignment - Full message text including exception details The logs are therefore the primary source of information for **system diagnostics, support and security analysis**. Combined with prioritization of message types and scoping of individual subsystems, targeted root cause analysis can be performed with minimal time effort. --- ## 3. Summary The **Monitoring** area combines the **Document Hub** and the **Log module** as two complementary monitoring units: while the Document Hub provides the **process-oriented view** of document-related operations, logging enables a **technical-protocol view** of all system-wide events. Together, both components form the basis for **stable, traceable and transparent system monitoring**, which is essential for productive operation and quality assurance within the CLARC Infinity Platform. --- # Process (Document-Hub) Source: https://clarc.com/docs/en/administration/monitoring/process-document-hub.md # Managing Operations in the Central Document Hub The **Document Hub** is a **central subsystem** of the platform and represents the organizational and technical core for the **processing of all incoming and outgoing documents**. As a **process queue**, it acts as the **central control and status authority** for all document-based operations — from initial capture to final delivery or archiving. It is thus the hub for: - all documents entering via **capture channels** (e.g. scan, email, API), - all internal or external **processing steps** (e.g. OCR, classification, extraction), - and all **outgoing processes** such as filing, handover or return transfers to third-party systems. --- ## 1. Architecture and Tasks ### 1.1 Central Tasks of the Document Hub - Management of all document-related process instances - Status and task control for automated and manual workflows - Tracking of task history and history per document - Provision of upload/download mechanisms - Visualization of the current process state (incl. preview) - Control of **task distribution** via event items - Tenant-specific parallelism control ### 1.2 Typical Data Sources - **Capture systems:** e.g. scanners, email, Office integration - **Manual uploads:** e.g. by users via web portal - **Automated sources:** e.g. REST API, job imports, ERP interfaces --- ## 2. Lifecycle and Processing Steps Each operation in the Document Hub typically passes through a **standardized workflow**, consisting of several tasks and associated status values: ### 2.1 Initial Phase – Intake & Capturing | Task | Possible Status Values | | --- | --- | | `ccDT_Capturing` | `ccDS_Capturing`, `ccDS_Idle`, `ccDS_Error` | - The document is recorded via a capture channel - It is present in the hub even if it is **still being processed by the user** - Faulty or interrupted captures end in the status `ccDS_Error` ### 2.2 Automated Processing – Classification & Extraction | Task | Possible Status Values | | --- | --- | | `ccDT_Classification` | `ccDS_Classification`, `ccDS_Error` | | `ccDT_Extraction` | `ccDS_Extraction`, `ccDS_Error` | - **Classification**: Document type and context are automatically recognized (e.g. invoice, delivery note) - **Extraction**: Structured data is read out via OCR/ICR/AI ### 2.3 User Interaction (Optional) | Task | Possible Status Values | | --- | --- | | `ccDT_Validation` | `ccDS_Error` | | `ccDT_WorkflowProcessing` | `ccDS_UserDecision`, `ccDS_WorkflowProcessing` | - In unclear cases, a **user decision** is required - Alternatively, a **manual workflow** can be triggered ### 2.4 Conversion and Delivery | Task | Possible Status Values | | --- | --- | | `ccDT_Conversion` | `ccDS_Conversion`, `ccDS_Error` | | `ccDT_Delivery` | `ccDS_Delivery`, `ccDS_Error` | - The document is converted to target formats (e.g. PDF/A, TIFF) - Subsequently, the document is filed or transferred to a target system (e.g. DMS, ERP) ### 2.5 Completion and Retention Period | Task | Status | | --- | --- | | `ccDT_Finish` | `ccDS_Finished` | - The operation is fully processed and completed #### Automatic Deletion Concept - After **14 days in status** `ccDS_Finished` → status changes to `ccDS_Deleted` - After a further **14 days in status** `ccDS_Deleted` → **physical deletion** from the system --- ## 3. Execution Control ### 3.1 Task Distribution and Event Items Each **active task in the hub** is controlled by an assigned **event item**. This governs: - the distribution to available workers or services - the consideration of **tenant priorities** - the compliance with **system class-specific parallelism limits** (e.g. 10 tasks in parallel in "Sandbox", 50 in "Production") ### 3.2 Parallelism Control - Depending on the system type and tenant configuration, **limits per task type and system class** are defined - These ensure regulated resource usage and prioritization of productive processes --- ## 4. Status Overview and Visualization ### 4.1 Status Displays - Each operation in the hub is clearly identifiable via its **status** - The status display indicates: Whether the operation is in the automated process - Whether a user must intervene - Whether errors or warnings exist ### 4.2 Document Preview - Display of the original document (PDF, TIFF, etc.) - Display of associated **metadata** (extracted values, classification, etc.) - Display of captured **notes** (e.g. by user comments or system notices) --- ## 5. History and Traceability Each operation in the Document Hub has a **complete processing history** containing the following information: - All processing phases passed through and their timestamps - Status transitions incl. trigger and duration - Errors or warnings that occurred - Manual interventions or escalations - Assignment to user or system services --- ## 6. Interactions: Upload, Download, Integration - Users and systems can **download** operations (incl. metadata) - **Re-entry by upload** is also possible, e.g. after offline correction - The hub provides APIs to integrate with capture systems, DMS, workflows and external partner services --- ## 7. Benefits of the Document Hub | Feature | Description | | --- | --- | | Central Management | Unified location for all document processes | | Process Transparency | Visualization, status, history, preview | | Automation & Parallelization | Task control, event items, system optimization | | User Integration | Decisions, notes, validations | | Traceability & Compliance | History, error detection, time-controlled deletion | | Integration Openness | Capture, DMS, ERP, REST, UI | --- # Log (Message-System) Source: https://clarc.com/docs/en/administration/monitoring/log.md # Logging and Analysis The log view allows targeted analysis of technical events within a specific **tenant** and **system** (e.g. Development, Test, Production, Sandbox, Training). Each log entry contains machine-readable information as well as support-relevant information for error localization, process tracing and technical state analysis. The display is **tenant and system specific**, meaning only log entries from the currently logged-in context are visible. This ensures that isolated test environments or production systems can be analyzed independently of each other. --- ## 1. Detail View of a Log Entry The following overview describes the fields of the detail view: | Field | Description | | --- | --- | | **Id** | Unique technical ID of the log entry (UUID). Used for referencing and tracking. | | **Instance Id** | ID of the affected operation or system context (e.g. process instance, API call, task execution). | | **Time Stamp** | Timestamp in UTC format when the log entry was created. | | **Thread Id** | Technical ID of the execution thread, relevant for parallel processes or asynchronous operations. | | **Thread** | Name or category of the processing thread (e.g. `Rest`, `Workflow`, `Capture`). | | **Message Id** | System-wide error or event ID. Used for error classification and documentation in the source code. | | **Message Type** | Type or severity of the message (e.g. `Error`, `Info`, `Warning`). | | **Message Text** | Detailed description of the message, incl. technical additional information, error types, usernames, etc. | --- ## 2. Example **Example Values:** | Field | Value | | --- | --- | | Message Id | `CCI_ERR_IAM_1034` | | Message Text | `HTTP request processing exception [unauthorized] (EccException_Unauthorized - authentication failed [admin])` | | Thread | `Rest` | | Message Type | `Error` | This information indicates an **authentication error when accessing a REST API**. The message ID enables targeted feedback to support or research in the documentation. --- ## 3. Log Levels and Types The log levels are standardized and correspond to the following categorization: ### 🔥 Errors | Code | Type | Description | | --- | --- | --- | | FER | `ccMT_Fatal` | Critical error, service termination | | CER | `ccMT_Critical` | Critical exception | | ERR | `ccMT_Error` | General error | ### ⚠️ Warnings | Code | Type | Description | | --- | --- | --- | | WRN | `ccMT_Warning` | Non-critical warning | | NTC | `ccMT_Notice` | Notice, potentially relevant | ### ℹ️ Information | Code | Type | Description | | --- | --- | --- | | INF | `ccMT_Info` | General information | | SUC | `ccMT_Success` | Successfully completed | | USR | `ccMT_User` | User-related action | | REQ | `ccMT_Request` | Incoming request | | RES | `ccMT_Response` | Response to request | | PRC | `ccMT_Process` | Process-related information | | SUP | `ccMT_Startup` | System start | | SDN | `ccMT_Shutdown` | System stop | | SEL | `ccMT_Select` | Selection operation | | CRT | `ccMT_Create` | Object created | | INS | `ccMT_Insert` | Data inserted | | UPD | `ccMT_Update` | Data updated | | EDT | `ccMT_Edit` | Data edited | | DEL | `ccMT_Delete` | Data deleted | ### 🐞 Debug | Code | Type | Description | | --- | --- | --- | | DBG | `ccMT_Debug` | Developer diagnostics, only in debug mode | ### 🔍 Trace | Code | Type | Description | | --- | --- | --- | | TRC | `ccMT_Trace` | Detailed tracing, e.g. function call paths | --- ## 4. Log Scopes (Thematic Classification) The **scopes** indicate which subsystem or module the log message originates from: | Code | Description | | --- | --- | | COR | Core | | NET | Network | | ODA | OData | | BIZ | Business Object | | FSM | Filesystem | | IMG | Imaging | | TNT | Tenants | | IAM | Identity & Access Management | | API | API (internal) | | EPI | API (external) | | LIC | Licensing | | SVC | Service | | CFR | C4 | | BIL | Billing | | DBS | Database | | CRP | Cryptography | | SEC | Security | | XTR | Xtract | | PSE | Python Script Engine | | EXP | Example | | CLI | Command Line Interpreter | | CAP | Capturing | | GRA | Microsoft Graph | | SNW | SAP NetWeaver | | REP | Repository | | ASC | Anyscan | | WFL | Workflow | | OSL | OpenSSL | | ECO | Ecosio | | DHB | Document Hub | | DEV | Development | | WRP | Warp | | INS | Installer | | BPI | Business Process Interoperability | | OAI | OpenAI | | TEX | LaTeX | | NOT | Notes | | VIR | Antivirus | | QTM | Queue Task Manager | | DRE | Document Reader | | PRE | Printerceptor Engine | | BSI | Business Software Integrations | | MIG | Migration | | ADR | Address Reader | | LMX | LLM Extractor | | CSV | Comma-separated values | | MSV | Messaging Services | | SAL | SAP ArchiveLink | | MCP | MailCapture | --- ## 5. Usage Notes - The **Message Id** is central for technical support and developers. It points to the exact location in the source code or in the error documentation. - By combining **scope**, **message type** and **message ID**, events can be efficiently filtered and analyzed. - **Tenant and system context** must always be considered: An error in a test environment is not necessarily critical in production operations. --- # Customizing Source: https://clarc.com/docs/en/administration/customizing/index.md # Adapting the Platform to Functional and Technical Requirements The **Customizing** area is the heart of the CLARC Infinity platform when it comes to the **individual adaptation and configuration** of system functions to company-specific processes. It enables administrators, process owners, and consultants to configure the platform **modularly, purposefully, and maintainably** — without needing to dive deep into the source code. Customizing covers both **functional models** and **technical configurations**. These include, for example: - The definition of **Business Objects** that structure document-based processes such as incoming invoices, purchase orders, or contract management. - The design of **Capture Desktops** with associated input fields, validations, mandatory fields, and form logic. - The configuration of **workflows**, decision rules, user roles, and escalation paths. - The integration of **scripting projects** that enable dynamic, event-driven control of forms and processes. - The maintenance of **DMS structures**, document types, metadata, and storage targets. - The management and assignment of **resources**, such as parameters, text snippets, or integration links. Thanks to its consistently modular design, all customizing elements can be **versioned, transported, and maintained across systems** — for example, from a development environment to test and then to production. The close integration with transport management and change tracking ensures **complete traceability and strong governance**. Customizing not only allows the **mapping of complex functional requirements**, but also their **standardization and reuse** across tenants, organizational units, or use cases. It thus forms the foundation for a **scalable, maintainable, and adaptable platform configuration**. --- # IAM (Identity and Access Management) Source: https://clarc.com/docs/en/administration/customizing/iam/index.md # User and Group Management The system uses a hierarchical model for managing **users**, **groups**, and **role-based permissions**. Groups serve as logical containers for structuring permissions and responsibilities. Users and groups can each be **members of other groups**, enabling flexible and reusable rights assignment. Roles are assigned **exclusively at the group level** — not directly to individual users. --- ## 1. Entities and Relationships ### 1.1 Users - A user represents an individual person with a unique login. - Can be a member of one or more groups. - Inherits roles through group memberships (recursively through nested groups as well). ### 1.2 Groups - Groups bundle users and/or other groups. - Serve as the central point for rights management through role assignment. - Support recursive nesting (group within group). ### 1.3 Roles - Roles define the permission level within the system. - A group can contain multiple roles. - Users receive the sum of all roles from their group memberships. --- ## 2. Role System | Role | Description | | --- | --- | | `ccUR_Everyone` | **General access:** Basic rights for standard users. :::note Does not need to be explicitly assigned. ::: | | `ccUR_Admin` | **Administrator:** Full access to user management, system settings, and maintenance. | | `ccUR_Service` | **Service:** Technical maintenance role, often used by APIs or technical users. | | `ccUR_ScanManager` | **Scan Manager:** Configuration and management of scan processes. | | `ccUR_ScanOperator` | **Scan Operator:** Execution of scanning operations. | | `ccUR_CaptureOperator` | **Capture Operator:** Responsible for data entry and capture tasks. | | `ccUR_CaptureManager` | **Capture Manager:** Management and customization of capture applications (e.g., batches). | | `ccUR_TrainingOperator` | **Training Operator:** Execution of training tasks. | | `ccUR_TrainingManager` | **Training Manager:** Organization and management of training sessions. | | `ccUR_Developer` | **Developer role:** Access to development functions and debugging tools. | | `ccUR_BillingSpecialist` | **Billing Specialist:** Responsible for creating and managing customer invoices and billing data. | | `ccUR_MdmCustomer` | **Customer MDM:** Maintains customer (debitor) master data. | | `ccUR_MdmVendor` | **Vendor MDM:** Maintains supplier/vendor (creditor) master data. | | `ccUR_MdMProduct` | **Product MDM:** Maintains product/article master data. | | `ccUR_DmsOperator` | **DMS Operator:** Access to archives and repositories including documents, blobs and notes. | --- ## 3. Group Structure — Example ``` Group: "CaptureTeam" ├── User: "max.mustermann" ├── Group: "ScanOperators" │ └── User: "sandra.scan" └── Roles: [ccUR_CaptureOperator, ccUR_ScanOperator] ``` - **max.mustermann** and **sandra.scan** both receive the roles `ccUR_CaptureOperator` and `ccUR_ScanOperator`. - If additional roles are added to a sub-group, those roles are also inherited. --- ## 4. Rights Assignment — Principles - **Recursive inheritance:** Roles are inherited across all nested groups. - **No roles assigned directly to users:** Roles are assigned exclusively through groups. - **Multiple role capability:** A user can receive any number of roles depending on group memberships. --- ## 5. Typical Use Cases ### 5.1 Create a New User 1. Create a user (login, name, email, etc.). 2. Assign the user to one or more groups (e.g., `CaptureTeam`, `Everyone`). ### 5.2 Assign a New Role 1. Identify the target group. 2. Attach the role to the appropriate group — Example: assign `ccUR_Developer` to `DevTeam`. ### 5.3 Adjust Group Structure - Create a new group, optionally add roles. - Assign existing users or groups as members. --- ## 6. Security Notes - The `ccUR_Admin` role should be assigned **exclusively to trusted users** in dedicated admin groups. - The admin user is never locked out, not even temporarily. - Groups with extensive rights should be regularly reviewed for their members. - Group nesting should **not be too deep** to keep rights assignment traceable. --- # Users Source: https://clarc.com/docs/en/administration/customizing/iam/users.md # User Management A user represents an individual person with a unique login name. Roles are **not assigned directly** to users — exclusively through [groups](index.md). :::warning The technical username (login name) **cannot be changed** after creation. Care should therefore be taken when choosing the name during user setup. ::: --- ## 1. User Types | Class | Description | | --- | --- | | `ccUC_Common` | Standard user — represents a real person. | | `ccUC_System` | System user — for technical services or automated processes. Not intended for persons. | --- ## 2. Origin Users can be created in the system in two ways: - **Clarc (manual):** The user is created and managed directly in the system. - **SCIM (automatic):** The user is provisioned via directory synchronization (e.g., Azure Active Directory). Changes to name, email, or organization data are controlled by the external directory. --- ## 3. Account Expiry An **expiry date** can be set to limit an account's validity. After the date has passed, login is no longer possible. The account is retained and can be reactivated. --- ## 4. Status ### 4.1 Locked A user can be temporarily locked — e.g., after repeated failed login attempts. The lock reason is visible to administrators; the lock can be lifted manually. :::note The admin user can never be locked. ::: ### 4.2 Deactivated A deactivated user cannot log in. Unlike a lock, deactivation is permanent and must be explicitly reversed. ### 4.3 Presence State Users can maintain a presence state: | State | Meaning | | --- | --- | | `Available` | Available | | `Busy` | Busy | | `DoNotDisturb` | Do Not Disturb | | `Away` | Away | | `BeRightBack` | Be Right Back | | `AppearOffline` | Appear Offline | | `OutOfOffice` | Out of Office | --- ## 5. Login History The system logs login events per user: date and count of successful and failed login attempts. For failed attempts, source IP addresses are recorded. This information is used for security monitoring. --- ## 6. Contact and Organization Data For each user, **business** and **private** contact details (email, phone) as well as organization data (department, job title, company, personnel number) can be maintained. --- ## 7. Two-Factor Authentication (2FA) Users can secure their login with TOTP-based two-factor authentication. Administrators can reset the 2FA secret to allow re-enrollment on a new device. --- # Groups Source: https://clarc.com/docs/en/administration/customizing/iam/groups.md # Group Management Groups are the central unit for rights assignment in the system. Roles are assigned exclusively to groups — not directly to users. Users receive their permissions through membership in one or more groups. Groups can be **nested**: a group can be a member of another group. Roles are inherited recursively by all members. --- ## 1. Group Types | Class | Description | | --- | --- | | `ccGC_Common` | Standard group — freely configurable for users and role structures. | | `ccGC_System` | System group — reserved by the system, cannot be deleted or renamed. | | `ccGC_Team` | Team group — intended for mapping organizational teams. | --- ## 2. Origin As with users, a group can be created manually or provisioned via directory synchronization (SCIM). For SCIM-managed groups, membership is controlled by the external directory. --- ## 3. Members A group can contain the following members: - **Users** — receive all roles of the group directly. - **Sub-groups** — all members of the sub-group inherit the roles of the parent group. Nesting depth should remain manageable to keep rights assignment traceable. --- ## 4. Roles The roles assigned to a group determine the permissions of all its members. An overview of available roles can be found in the [IAM overview](index.md#2-role-system). --- ## 5. System Groups System groups are predefined by the system and cannot be deleted. They serve internal purposes and should not be used for regular user management. Role assignments can be adjusted if necessary. --- # Client Credentials Source: https://clarc.com/docs/en/administration/customizing/iam/client-credentials.md # Client Credentials Client Credentials allow **external applications and services** to authenticate against CLARC Infinity — without a user login. They are based on the **OAuth 2.0 Client Credentials Flow** and are typically used for automated system integrations, background processes, or programmatic API access. A client credentials entry consists of a **Client ID** (technical identifier) and one or more **Client Secrets**, which are used together for authentication. :::note Authentication is performed via the platform's standard OAuth2 endpoint (`oauth/token`) and is fully compatible with common OAuth2 libraries and clients. ::: --- ## 1. Configuration Fields | Field | Description | | --- | --- | | **Name** | Descriptive name of the entry (for internal identification). | | **Client ID** | Automatically generated technical identifier passed during authentication. | | **Validity** | Expiry date of the entire entry. After expiry, authentication via this entry is no longer possible, regardless of individual secrets. | --- ## 2. Client Secrets A Client Secret is the secret used together with the Client ID for authentication. :::warning The Client Secret is **shown only once at the time of creation** and cannot be retrieved afterwards. It must be saved immediately after creation. ::: **Multiple secrets** can be active simultaneously per entry. This enables controlled rotation: a new secret can be created before the old one is removed, to avoid interruptions. Secrets that are no longer needed can be removed via the corresponding function. Each secret has its own settings: | Field | Description | | --- | --- | | **Validity** | Expiry date of the secret. After expiry, authentication is no longer possible. | | **System Actor** | User whose roles and permissions are applied in the session created by this secret. The user must have the `ccUR_Service` role. | | **IP Restriction** | Optional list of allowed IP addresses. If populated, requests from unlisted addresses are rejected. | | **ProcessTask** | Optional process started upon email receipt at this secret's address (see below). | ### ProcessTask — Email-Based Process Triggering Each Client Secret can serve as an **email inbox for automated processes**. CLARC Infinity receives the email via the integrated **SMTP server** and starts the configured process. The email address for this inbox is composed of the **tenant name**, **Client ID**, and **Client Secret ID**, making it uniquely tied to a specific secret. A process can be configured per secret that is started upon email receipt: | Process Type | Description | | --- | --- | | **Document Flow** | Starts a configured document process with the incoming email as input. | | **Incoming Invoice** | Starts the incoming invoice process according to the configured invoice settings per company code. | | **Incoming Order** | Starts the incoming order process according to the configured order settings per company code. | | **Incoming Confirmation** | Starts the order confirmation process according to the configured confirmation settings per company code. | :::note This mechanism enables simple, standards-compliant process integration without additional connectors — any application capable of sending emails can trigger processes in CLARC Infinity. ::: --- ## 3. Typical Use Cases Client Credentials are used when external systems or services need to access CLARC Infinity without user interaction — e.g.: - Background processes and automated workflows - External integration platforms or middleware - Script-based or scheduled data transfers - Email-based process triggering via ProcessTask --- # BPM (Business Process Management) Source: https://clarc.com/docs/en/administration/customizing/bpm/index.md # Business Process Management (BPM) and Its Key Components **Business Process Management (BPM)** describes a systematic approach to modeling, executing, monitoring, and optimizing business operations within an organization. The goal is to make operational processes more efficient, transparent, and adaptable. Structured processes — such as processing invoices, customer orders, or contracts — are mapped into clearly defined, digitally supported workflows. A central element in BPM are so-called **Business Objects** — functional business entities that represent concrete operational content such as **invoices**, **contracts**, **delivery notes**, or **purchase orders**. They contain all relevant data and metadata required for processing within a given process. Modeling such objects forms the functional foundation for seamless digital process handling. Closely linked to BPM is the concept of **Document Flows** — document-driven workflows that control the lifecycle of a document within a process. Typically, a Document Flow begins with the **receipt of a document** (e.g., via email, scan, or API), progresses through steps such as **format conversion**, **data extraction (OCR/ICR — AI-assisted)**, and **validation**, and concludes with **transfer to a downstream system** such as an ERP, DMS, or business application. These flows are usually lean, highly automated, and designed for recurring standard operations. A particularly relevant application area in BPM is the **automated processing of incoming documents**, especially: - **Incoming invoices**, where extraction of amounts, vendor data, and purchase order references is required, - **Customer orders (purchase orders)**, which are automatically matched against existing quotations or item master data and transferred to an ERP system. By combining these concepts — structured business objects, controlled workflows, and intelligent document processing — business processes can not only be digitized but also efficiently managed, transparently documented, and continuously improved. BPM thus forms a key pillar of digital transformation in modern organizations. --- # Business Objects Source: https://clarc.com/docs/en/administration/customizing/bpm/business-objects.md # Structured Foundation for Document Capture, Metadata Management, and System Integration **Business Objects** (BOs) form the conceptual and structural foundation of the CLARC Infinity platform. They define **the functional and technical representation of documents**, including their **metadata**, **structure**, **presentation**, and **processing contexts**. A Business Object describes, for example, a document of type **Invoice**, **Purchase Order**, **Contract**, **Delivery Note**, or **Employee File** — regardless of whether it is captured, archived, displayed, or processed. The defined structure of a BO is usable across all system-wide components: including **Capture applications**, **workflows**, **repositories**, **result lists**, **scripting projects**, and integration scenarios. --- ## 1. Properties A Business Object consists of an **arbitrarily deep-structured set of properties** — fields that are presented in the application as input fields, data structures, or tables. Property types are divided into: ### 1.1 Primitive Data Types | Type | Description | | --- | --- | | `String` | Character string (text, ID, IBAN) | | `Integer` | Integer number | | `Float` | Decimal number | | `Boolean` | True/False value | | `DateTime` | Date and time values | ### 1.2 Enumerations Enumerations are **predefined selection values**, e.g., status fields such as `Open`, `Completed`, `Cancelled`. ### 1.3 Complex Types Complex types are used for **grouping multiple fields** into a structured element — e.g., an **Address** with sub-fields `Street`, `Zip Code`, `City`, `Country`. ### 1.4 Collections Any property type can also be defined as a **Collection** (a list of objects of the same type). A typical example: an **Invoice Line Item** is a collection of complex fields such as item number, quantity, and price. --- ## 2. Subtypes (Inheritance) Every Business Object can have **subtypes** — i.e., specialized variants that **inherit** all properties of the parent type and extend them further. For example, a BO `Document` can be extended by a subtype `Invoice` or `Credit Note`. The subtype structure enables: - **Reuse of shared fields** - **Specific desktops, rules, and workflows** per subtype - **Flexibility combined with structural discipline** --- ## 3. Desktops A Business Object can have **multiple desktops** — i.e., different **user interfaces** for various use cases such as: - **Capture** (data entry) - **DMS** (document display, archiving) - **Validation** - **View with restricted permissions** A desktop defines: - **Visible fields** (including access control) - **Layout and structure** - **Assignment of scripts** (TypeScript) - **UserExits** (e.g., database queries for pre-population) - **Field validations and dependencies** --- ## 4. Scripting, Validation, and Automation **Client scripts** can be connected to each desktop to dynamically control user interaction. Additionally: - **UserExits** are definable to integrate external data sources at runtime - **Events** such as `OnEnter`, `OnUserexit`, `OnChanged`, `OnStart` are programmable - Validations can be implemented individually via rule sets or scripts --- ## 5. Semantic Field Types Each field within a Business Object can additionally be assigned a **semantic type** (functional field type), e.g.: - `InvoiceNumber` - `DocumentDate` - `GrossAmount` - `IBAN` - `CustomerNumber` These semantic types serve the following purposes: - They enable **automatic population** through extraction, OCR, or external data sources. - They serve **system-internal standardization and integration**, e.g., when transferring data to archives, workflows, or ERP systems. - They facilitate **reuse and logic assignment** in capture and validation scenarios. --- ## 6. Result Lists and Search **Result list views** can be defined for Business Objects, used e.g., in the archive, search forms, or task lists. These define: - **Display columns** - **Sorting and filterability** - **Access rights for individual fields** - **Links to detail views** --- ## 7. Use Cases and Reuse Business Objects are fully **usable across systems**. One and the same object can be used in the following modules: - ✅ **Capture** - ✅ **Archiving** (Repository) - ✅ **Search and Result Lists** - ✅ **Workflows and Decisions** - ✅ **Scripting and Validation** - ✅ **Data Exports and Interfaces** Due to this universal applicability, BOs are a **central architectural principle** that combines consistency, reusability, and system logic. --- ## 8. Summary **Business Objects** are the structured model upon which all document-related processes in the CLARC Infinity platform are built. They form the basis for **capturing, displaying, processing, and integrating documents** — from the UI to automation. With their support for **inheritance, complex structures, semantic field types, and multiple use in desktops and workflows**, they offer a powerful, extensible, and future-proof model for mapping diverse business scenarios. --- # Invoice Source: https://clarc.com/docs/en/administration/customizing/bpm/invoice.md # Invoice --- # Order Source: https://clarc.com/docs/en/administration/customizing/bpm/order.md # Order --- # Documents Flow Source: https://clarc.com/docs/en/administration/customizing/bpm/documents-flow.md # Structured Document Processing The **Document Flow** is a central concept within the CLARC Infinity platform for the **simple and modular control of the document-based processing chain**. It defines how a document — after capture or extraction — is automatically transferred to a downstream target system, optionally converted, and content-transformed. A Document Flow thus represents the **final step in document-related processing**: from the raw document to a qualified, export-ready result — e.g., in an archive system, an ERP, a third-party system, or a database. --- ## 1. Configuration Elements of a Document Flow Configuration is done through three central components, as shown in the screenshot: ### 1.1 Target Access Profile This defines **where** the document or its metadata should be transferred to. The selection is made from centrally maintained **Access Profiles** (e.g., SAP, ArchiveLink, Mailbox, REST API, Database). See [Access Profiles](#administration/customizing/bpi/access-profiles/index) ### 1.2 Transformer The Transformer is an optional module that converts **structured content (e.g., extracted fields)** using **JSON-based rules** into a **target-compliant format**. This can include: - Renaming or restructuring fields - Merging or splitting values - Adding fixed metadata - Mapping to external data structures (e.g., JSON schema for an API) Transformer rules can be maintained through the user interface or directly as a JSON definition. ### 1.3 Document Conversion Optionally, documents can be **automatically converted** before transfer. This can include: - Format conversion (e.g., TIFF → PDF/A, Office → PDF) - OCR post-processing or image optimization - Resolution and color mode adjustments Conversion profiles are based on the **conversion rules** defined in the platform and are reusable. See [Document Conversions](#administration/customizing/xdc/document-conversions) --- ## 2. Document Flow Process 1. A document is captured, e.g., via a Capture application, a workflow, or an API. 2. The assigned Document Flow is triggered. 3. If configured, the document is converted. 4. The extracted metadata is (optionally) transformed. 5. The document and/or data are transferred to the target system (directly or via Cloud Connector On Premises). --- ## 3. Status Tracking in the Document Hub The **current processing states and progress of a Document Flow** are displayed in real time in the **Document Hub** of the respective process. There you can view: - Which **processing step** the document is currently in (e.g., "Conversion running", "Transfer to target system") - Whether the flow completed successfully or whether an error occurred - Which **status information or log messages** were generated during the process --- ## 4. Advantages - Separation of capture and system integration - Reusable conversion and mapping components - Consistent, traceable, and maintainable transfers to third-party systems - Modular design for various scenarios (archiving, forwarding, enrichment) --- The **Document Flow** is the link between document-oriented processes and external target systems. Through its clear structure and modularity, it enables documents to be further processed **securely, in a standardized manner, and flexibly** — without relying on complex workflows or custom development. --- # BPI (Business Process Interoperability) Source: https://clarc.com/docs/en/administration/customizing/bpi/index.md # Business Process Interoperability (BPI) and Access Profiles **Business Process Interoperability (BPI)** refers to the ability of information systems to communicate seamlessly with each other in heterogeneous IT landscapes, executing complete, consistent, and compliant business processes across system and organizational boundaries. BPI is a critical success factor for digital transformation, as modern business processes typically no longer run within a single system but must integrate a multitude of technical platforms, applications, and data sources. A central concept for implementing BPI is the use of **Access Profiles** — structured access definitions that standardize cross-system connections and authentication. Access Profiles enable a controlled, reusable, and secure interaction with various backend systems and interfaces, without requiring process designers or business users to deal with the technical details of the target systems. Typical application areas of Access Profiles include access to: - **Databases** (e.g., Microsoft SQL Server, Oracle, PostgreSQL): Read or write access to structured data for process control, decision logic, or data enrichment. - **Email systems** (IMAP, MS Graph API): Automated retrieval and sending of messages for processing incoming documents, notifications, or status updates. - **ERP systems** such as **SAP** (via RFC/BAPI, OData, IDoc) or **Microsoft Dynamics 365**: Exchange of business data such as orders, invoices, purchase orders, or master data in real time. - **Document management and archive systems** such as **EASY Archive**: Access to digital archives for filing, retrieval, and long-term storage of process-relevant documents. - **Additional systems** such as file servers, REST-based APIs, SharePoint, cloud storage, or business applications. Access Profiles encapsulate not only credentials and connection parameters, but also define technical protocols, authentication methods (e.g., OAuth, Basic Auth, certificates), and operational access controls. They promote **loose coupling** of systems and allow the reuse and centralized management of connectivity information within a process platform. In conjunction with Business Process Management (BPM), Access Profiles enable the technical realization of end-to-end processes — from capturing an incoming document through workflow processing to forwarding it to an ERP or archive system. They are therefore an indispensable tool for any platform that relies on **process integration, automation, and scalability**. --- # Access Profiles Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/index.md # Management of External Connections and Integration Endpoints The **Access Profiles** area in the CLARC Infinity platform serves the **centralized management of external connection information**. It ensures that defined systems and services — such as SAP, mail servers, file systems, or archives — can be connected **securely, reusably, and in a standardized manner**. An Access Profile represents **a specific configuration variant of a connection category** (e.g., a particular SAP system instance or a specific IMAP mailbox). Such profiles are **defined once in this area** and can then be referenced anywhere in the system customizing, e.g., in workflows, capture configurations, or extraction processes. --- ## 1. Access Profiles | Profile | Description | | --- | --- | | [SAP](sap.md) | Access to SAP ERP and SAP S/4HANA (RFC/BAPI/IDoc) | | [SAP ArchiveLink](sap-archivelink.md) | Connection to SAP ArchiveLink for audit-compliant document archiving | | [AFI](afi.md) | Integration of AFI solutions for invoice and document processing | | [Microsoft Dynamics 365 Business Central](microsoft-dynamics-365-business-central.md) | Connection to Microsoft Dynamics 365 Business Central | | [Microsoft Graph](microsoft-graph.md) | Access to Microsoft 365 services (Outlook, Teams, OneDrive, SharePoint) | | [Mailbox](mailbox-access-profile.md) | Access to email mailboxes via a configured provider (Graph, IMAP, Google) | | [IMAP](imap.md) | Direct IMAP server connection for mailbox access | | [Google](google.md) | Access to Google services via service account (e.g., Gmail) | | [Ecosio](ecosio.md) | EDI integration via the provider Ecosio | | [CLARC Enterprise](clarc-enterprise.md) | Connection to an existing CLARC Enterprise instance | | [EASY Enterprise.X](easy-enterprise-x.md) | Connection to EASY Enterprise.X archive systems | | [Database](database.md) | Access to relational databases (MS SQL, MySQL, Oracle, ODBC) | | [File Storage](file-storage.md) | Access to local or network drives for file storage and retrieval | | [Otris Documents](otris-documents.md) | Connection to the Otris Documents document management system | :::note **Any number of profiles** with different credentials, system environments, or connection types can be created per category. ::: --- ### 1.1 Application Examples - In a Capture application, an **IMAP access** from the Access Profiles is referenced to automatically retrieve incoming emails. - A workflow uses a **SAP Access Profile** to transfer document data via RFC directly to the ERP. - An archiving action uses a **SAP ArchiveLink profile** to transfer documents to SAP ArchiveLink in an audit-compliant manner. --- ## 2. Direct Access or Cloud Connector For most connections, it can be individually specified whether access: - Is **direct** (typical in on-premises or hybrid environments), or - **Via the Cloud Connector**, which enables secure communication between the platform and internal networks. This flexibility allows deployment in **cloud, on-premises, and hybrid architectures** without changes to functional processes or platform logic. --- ## 3. Transport Behavior of Access Profiles When transporting Access Profiles within the CLARC Infinity platform, **only the structural shell of the configuration is transported**, not the **system-specific connection details** such as credentials, server addresses, tokens, or interface parameters. The reason lies in the **system-dependent nature of these connections**: A development, test, and production system typically uses **different endpoints and authentication methods**, e.g.: - Different SAP clients - Separate REST API URLs - Different mail servers or mailboxes - Technically separate archive instances Therefore, the Access Profile **must be manually adjusted or fully configured in the target system after transport**. The platform supports this through clear marking of incomplete profiles and the ability to maintain existing configurations independently per target system. This separation ensures that **no sensitive credentials are accidentally transferred**, while also providing full flexibility for operation in **system-separated environments** — an essential component for a clean Dev–Test–Prod strategy. --- The **Access Profiles** area enables a **clean separation between process logic and connection configuration**. This increases reusability, maintainability, and security in complex system landscapes. Through the option of direct access or Cloud Connector, this mechanism is suitable for a wide variety of operating models — from pure cloud operation to deep on-premises integration. --- # SAP Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/sap.md # SAP Access Profile The SAP Access Profile establishes a connection to an **SAP ERP** or **SAP S/4HANA** system. It is used when processes need to exchange data with SAP via RFC, BAPI, or IDoc — e.g., for posting documents, retrieving master data, or transferring purchase orders. --- ## 1. Connection Type The connection can be established **directly** (on-premises or VPN) or via the **Cloud Connector**. The Cloud Connector enables secure access to SAP systems without direct network exposure. --- ## 2. Connection Parameters | Parameter | Description | | --- | --- | | **Application Server** | Hostname or IP of the SAP application server (for single instance). | | **Message Server** | Hostname of the SAP Message Server (for load balancing via logon groups). | | **Logon Group** | Logical group in SAP Logon (when using the Message Server). | | **System ID (SID)** | Three-character SAP system identifier (e.g., `PRD`, `DEV`). | | **System Number** | Two-digit SAP system number (e.g., `00`). | | **Client** | SAP client against which the connection authenticates. | | **Language** | Logon language (ISO 639, e.g., `EN`). | | **SapRouter** | Optional SapRouter string for access via SAP router infrastructure. | --- ## 3. Credentials | Parameter | Description | | --- | --- | | **User** | Technical RFC user in the SAP system. | | **Password** | Password of the technical user. | :::note For production use, a dedicated technical user with restricted RFC authorizations should be used — not a dialog user. ::: --- # SAP ArchiveLink Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/sap-archivelink.md # SAP ArchiveLink Access Profile The SAP ArchiveLink Access Profile enables the **audit-compliant transfer of documents to SAP ArchiveLink**. It is used when documents — e.g., incoming invoices or delivery notes — are to be linked directly to an SAP business object and stored in the SAP archive. :::note CLARC Infinity is **fully SAP-certified** for the SAP ArchiveLink interface. Additionally, CLARC itself can be operated as an **SAP ContentServer** and is available for the **SAP Business Technology Platform (BTP)** as an **SAP CMIS Archive** — in these scenarios, CLARC acts not only as a supplier but as a full-fledged archive backend for SAP. The CMIS certification (SAP S/4-BTP-CMIS) has been valid since November 2024 and is listed in the SAP Certified Solutions Directory. ::: --- ## 1. Connection Type Like the SAP profile, SAP ArchiveLink also supports access **directly** or via the **Cloud Connector**. --- ## 2. SAP Connection The SAP connection parameters correspond to those of the [SAP Access Profile](sap.md) (application server, SID, client, credentials, etc.). --- ## 3. ArchiveLink Configuration | Parameter | Description | | --- | --- | | **Scenario** | `ArchiveAndLink` — Storage and linking with SAP object. `Barcode` — Barcode-based assignment. | | **Repository** | Name of the external archive repository (max. 20 characters, e.g., `Z_ARCH`). | | **SAP Object** | SAP business object type (e.g., `BKPF` for accounting documents, `BUS2032` for purchase orders). | | **Archiving Object** | SAP archiving object type (e.g., `ZFIINVOICE`). | | **Function Module** | Optional SAP RFC function module for processing. | | **Document Class** | Document format for storage (e.g., `PDF`, `TIF`). | --- # AFI Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/afi.md # AFI Access Profile The AFI Access Profile establishes a connection to **AFI solutions** running on an SAP basis. It is used to transfer documents (invoices, purchase orders, order confirmations) to AFI processing components. **AFI Solutions** is a German software company specialized in SAP-integrated document management and invoice processing solutions. AFI Solutions has been integrated into the **DOXIS** platform by SER Group — existing AFI installations continue to be connected via this profile. :::note New projects based on SER Group / DOXIS can also be connected via this profile, as long as the AFI interface is still in use. ::: --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. SAP Connection The connection parameters correspond to those of the [SAP Access Profile](sap.md). --- ## 3. AFI Configuration | Parameter | Description | | --- | --- | | **Solution** | Type of document to be processed: `Invoice`, `Order`, `Confirmation`. | | **SAP Function Module** | Specific RFC function module for the AFI transfer. | | **Unit Mapping** | Reference to an MDM unit mapping for unit-of-measure translation. | --- # Microsoft Dynamics 365 Business Central Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/microsoft-dynamics-365-business-central.md # Microsoft Dynamics 365 Business Central Access Profile This profile establishes a connection to **Microsoft Dynamics 365 Business Central**. It is used when documents such as invoices, purchase orders, or order confirmations are to be transferred to or retrieved from Business Central. --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **URL** | API endpoint of the Business Central environment (e.g., `https://api.businesscentral.dynamics.com/...`). | | **Solution** | Type of document: `Invoice`, `Order`, `Confirmation`. | | **User** | Technical user for API access. | | **Password** | Password or API key of the technical user. | --- # Microsoft Graph Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/microsoft-graph.md # Microsoft Graph Access Profile The Microsoft Graph Access Profile enables access to **Microsoft 365 services** such as Outlook, Teams, OneDrive, and SharePoint via the Microsoft Graph REST API. It serves as a **provider** for [Mailbox Access Profiles](mailbox-access-profile.md) and can also be used for other M365 integrations. --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration Access is via a registered **Azure App Registration** in Microsoft Entra ID (formerly Azure Active Directory): | Parameter | Description | | --- | --- | | **Tenant ID** | ID of the Microsoft 365 tenant (Azure Tenant). | | **Client ID** | Application ID of the registered app in Entra ID. | | **Client Secret** | Secret of the app registration (app-only flow). | :::note The app registration requires the appropriate **Application Permissions** in Entra ID (e.g., `Mail.Read`, `Mail.ReadWrite`). Delegated permissions are not used — access is system-side without user sign-in. ::: --- # Google Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/google.md # Google Access Profile The Google Access Profile enables system-side access to **Google services** — in particular Gmail — via a Google Service Account. It serves as a **provider** for [Mailbox Access Profiles](mailbox-access-profile.md). --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **Certificate** | JSON key file of the Google Service Account, Base64-encoded. The file is generated in the Google Cloud Console when creating the service account. | :::note The service account requires **domain-wide delegation** permission in the Google Workspace Admin Console in order to access mailboxes on behalf of the organization. ::: --- # IMAP Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/imap.md # IMAP Access Profile The IMAP Access Profile defines an **IMAP server connection** and is referenced as a **provider** by [Mailbox Access Profiles](mailbox-access-profile.md). It describes which mail server and protocol are used for mailbox access. --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **Server** | Hostname or IP address of the IMAP server (e.g., `mail.company.com`). | | **Port** | IMAP port (typically `993` for TLS, `143` for STARTTLS). | | **Use TLS** | Enables an encrypted connection (recommended). | :::note The username and password for mailbox access are stored in the referencing **Mailbox Access Profile**, not here. ::: --- # Ecosio Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/ecosio.md # Ecosio Access Profile The Ecosio Access Profile enables **EDI integration via the provider Ecosio**. Ecosio is a cloud-based EDI platform through which electronic documents (invoices, purchase orders, delivery notes) can be exchanged with trading partners in a standards-compliant manner. --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **User ID** | Ecosio user identifier for the account. | | **App Key** | Application key of the Ecosio account. | | **User Key** | User-specific API key for authentication. | The credentials are provided by Ecosio when setting up the customer account. --- # CLARC Enterprise Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/clarc-enterprise.md # CLARC Enterprise Access Profile The CLARC Enterprise Access Profile establishes a connection to an existing **CLARC Enterprise** instance. It is used to exchange documents and tasks between CLARC Infinity and CLARC Enterprise — e.g., for extraction (Xtract) or export of processes. :::note This profile also applies to **EASY Capture Plus** systems, as EASY Capture Plus is based on the CLARC Enterprise platform and is connected via the same interface. ::: --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **Warp URL** | Endpoint of the CLARC Enterprise instance. | | **Task** | Type of processing: `Xtract` (extraction from CLARC Enterprise) or `Export` (transfer to CLARC Enterprise). | | **Priority** | Processing priority of the queue: `Idle`, `Lowest`, `Lower`, `Normal`, `Higher`, `Highest`, `TimeCritical`. | --- ## 3. Processing Schemes Optional schemes can be configured for specific processing steps: | Parameter | Description | | --- | --- | | **Pre-Script Scheme** | Script executed before the transfer. | | **Post-Script Scheme** | Script executed after the transfer. | | **Export Scheme** | Scheme for exporting processes. | | **Conversion Scheme** | Scheme for document conversion. | | **Export Service** | Target service for the export. | | **Xtract Project** | Project identifier for the extraction. | | **Export Target** | Target path or identifier for exported content. | --- # EASY Enterprise.X Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/easy-enterprise-x.md # EASY Enterprise.X Access Profile The EASY Enterprise.X Access Profile establishes a connection to the **EASY Enterprise.X** archive system. It is used for storing, searching, and retrieving documents from EASY archive instances. **EASY Software** is a German software company headquartered in Mülheim an der Ruhr that offers enterprise content management and archiving solutions. EASY Enterprise.X is the company's classic on-premises archive platform. --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **URL** | Address of the EASY Enterprise.X instance. | | **Instance** | Name of the EASY instance. | | **Pool** | Name of the connection pool. | | **Unit** | EASY organizational unit. | | **Scheme** | Connection scheme. | | **Language** | Connection language (ISO 639, e.g., `eng`). | | **User** | Technical user for access. | | **Password** | Password of the technical user. | | **Use Binary License** | Enables the use of a binary EASY license. | --- # Database Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/database.md # Database Access Profile The Database Access Profile enables access to **relational databases**. It is used when processes need to read or write data directly from a database — e.g., for master data queries, decision logic, or document enrichment. A typical use case is **user exits in Capture applications**: via a Database Access Profile, external master data or database content can be accessed during capture — e.g., to automatically populate fields, validate inputs, or dynamically load selection lists. The profile is referenced in the respective [Capture configuration](../../app-application/capture.md). --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Supported Database Systems | Driver | Database System | | --- | --- | | `MSSQL` | Microsoft SQL Server | | `MySQL` | MySQL / MariaDB | | `Oracle` | Oracle Database | | `ODBC` | Any ODBC data source | --- ## 3. Configuration | Parameter | Description | | --- | --- | | **Server** | Hostname or IP address of the database server. | | **Database** | Name of the target database. | | **DSN** | Data Source Name (for ODBC connections only). | | **User** | Database user. | | **Password** | Password of the database user. | :::note For ODBC connections, the DSN is configured on the server where the CLARC Infinity service runs. Server and database can be left empty in this case. ::: --- # File Storage Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/file-storage.md # File Storage Access Profile The File Storage Access Profile enables access to **local directories or network drives**. It is used for storing or retrieving files — e.g., for exporting documents to a file system or importing from an input folder. --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **Path** | Absolute directory path (local or UNC path, e.g., `\\server\share\incoming`). | | **File Name** | File name template for files to be stored. Can contain placeholders. | | **File Format** | Format of the stored file: `File` (original), `ClarcDocumentJson` (CLARC format), `Zip` (archive). | --- # Otris Documents Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/otris-documents.md # Otris Documents Access Profile The Otris Documents Access Profile establishes a connection to the **Otris Documents** document management system. It is used for storing, retrieving, and linking documents in Otris Documents. **otris software AG** is a German software company headquartered in Dortmund, specialized in document management and contract management. Otris Documents is the company's DMS platform for the structured management and archiving of documents and case files. :::note A **CLARC Infinity Repository** can be connected as an archive to Otris Documents and behaves analogously to a native Otris archive — documents are directly accessible and manageable through the Otris interface. ::: --- ## 1. Connection Type Access is established **directly** or via the **Cloud Connector**. --- ## 2. Configuration | Parameter | Description | | --- | --- | | **Base URL** | URL of the Otris Documents REST API (e.g., `https://otris.company.com/api`). | | **Access Token** | Authentication token for API access. | | **Akte** | Target case file (repository) in Otris Documents where documents are stored. | --- # Mailbox Access Profile Source: https://clarc.com/docs/en/administration/customizing/bpi/access-profiles/mailbox-access-profile.md # Configuration for Automated Email Access in Process Integration The **Mailbox Access Profile** enables the CLARC Infinity platform to **automatically access email mailboxes** in order to capture incoming messages in a structured way and trigger downstream processes (e.g., invoice processing, order intake, or classification). Access is always **machine-based** and not interactive — designed for continuous, unattended operation (machine-to-machine communication). --- ## 1. General Structure and Purpose A Mailbox Access Profile represents a **named configuration unit** that describes **which mailbox in which folder structure** should be accessed and processed via **which provider**. | Configuration Element | Description | | --- | --- | | **Name** | Internal, freely assignable name of the configuration | | **Mailbox (Email, User)** | Technical identification of the target mailbox (user address or shared mailbox). Depends on the provider | | **Folder** | Folder structure within the mailbox (see details below) | | **Provider** | Reference to an associated Access Profile of type _Graph_, _IMAP_, _Gmail_, etc., which defines the authentication details and access method | The actual authentication (e.g., via OAuth, username/password, or app access) is **not handled in the Mailbox Profile itself**, but through the assigned **Provider configuration**. --- ## 2. Provider Support The platform supports various provider types through which mailbox access is established: | Provider Type | Description | | --- | --- | | **Microsoft Graph** | Access to Microsoft 365 mailboxes via REST API (ClientId, TenantId, ClientSecret) | | **IMAP** | Standard protocol for classic mail servers (username/password required) | | **Gmail** | Access to Google Mail accounts via OAuth | Details on configuring each provider type (e.g., for Microsoft Graph) are documented in separate sections. --- ## 3. Folder Specification and Access Logic The folder structure determines **which emails in the mailbox are processed**. Access follows fixed rules to consistently address both personal and shared mailboxes. ### Personal Mailbox (Default) | Input Value | Meaning | | --- | --- | | _(empty)_ | Default: `Inbox` (user's inbox) | | `inbox` | Equivalent to empty | | `Invoices` | Accesses the "Invoices" subfolder in the user's mailbox | | `Inbox/2024/Q1` | Nested subfolder structure within the inbox | ### Shared Mailbox | Input Value | Meaning | | --- | --- | | `sharedmail@company.com` | Accesses the `Inbox` of the Shared Mailbox | | `sharedmail@company.com/Incoming` | Accesses the `Incoming` subfolder | | `sharedmail@company.com/Inbox/Q1` | Nested structure within the Shared Mailbox | Folder names must exactly match the configuration on the mail server. --- ## 4. Authentication and Access **Access authorization to the mailbox** is entirely derived from the configured Provider. There is **no additional technical configuration in the Mailbox Profile itself**, only a **reference to the defined Provider**. - With **IMAP**, access is typically performed using **username and password** - With **Gmail**, access is via a **Service Account** and a **JWT**. - With **Microsoft Graph**, a registered app is used with **TenantId**, **ClientId**, and **ClientSecret** (App-only flow) The **OBO flow (On-Behalf-Of)** is **not used** here, as this involves exclusively **system-side access**, not user sessions. --- ## 5. Use Cases Mailbox Access Profiles are typically used in the following scenarios: - Automatic email import for document processing (e.g., `.eml` or `.pdf`) - Trigger for Capture processes when new messages arrive - Capture of structured content for AI-assisted extraction or classification workflows --- ## Summary The Mailbox Access Profile is an essential component of **automated mail processing in CLARC Infinity**. It separates **functional target structure (mailbox and folder)** from **technical access credentials (provider)** and thus enables a **secure, scalable, and centrally manageable configuration** for all email-based inbound scenarios — regardless of the mail platform in use. --- # MDM (Master Data Management) Source: https://clarc.com/docs/en/administration/customizing/mdm/index.md # Master Data Management (MDM) for Enrichment and Assignment of Business Data **Master Data Management (MDM)** describes the structured handling of central, company-wide master data such as vendors, customers, items, or organizational units. In our system context, MDM primarily serves to **read and synchronize data from a leading system** (e.g., an ERP system such as SAP or Microsoft Dynamics) and make it consistently available for downstream processes. The use of MDM is particularly essential in the **processing of business documents** — such as incoming invoices, order confirmations, or delivery notes. These documents frequently contain **identifying information** that must be validated or enriched against company master data during manual or automated processes. Typical use cases include: - Validation and automatic assignment of vendors based on company names, address data, or tax numbers, - Enrichment of order data with line item details from the ERP, - Addition of missing information (e.g., company code, sales organization) for process-compliant handling. A particular focus is on **fuzzy matching** — to robustly resolve **deviating spellings** or **formal differences** — e.g., in addresses, street names, cities, or customer names. This significantly increases the automation rate in document recognition and reduces manual clarification cases. The following master data areas are regularly synchronized as part of MDM and made available system-wide: - **Vendors** (supplier master data) - **Customers** (customer master data) - **Purchase Orders (outgoing)** with line item information - **Quotations** (sales side) - **Company codes** and associated financial organizations - **Item master data** with material numbers and descriptions - **Sales organizations** (e.g., sales areas, branches) This data is not created or edited within MDM itself, but exclusively **imported from a leading system**. The prepared data set is then used in processes such as data extraction, validation, assignment, and duplicate detection — both **interactively** by users and **fully automatically** within workflows. MDM thus forms a central backbone for **data-driven business processes** and enables high process quality, consistency, and automation capability when processing structured and semi-structured information. --- # ERP Synchronization Source: https://clarc.com/docs/en/administration/customizing/mdm/erp-synchronization.md # Controlling Data Exchange Between ERP Systems and the CLARC Infinity Platform **ERP Synchronization** enables the automated reconciliation of **master data and transactional data** between a connected ERP system (e.g., SAP) and the CLARC Infinity platform. The goal is to ensure that document-based processes such as **invoice processing**, **order matching**, or **document recognition** always have access to current and consistent data — such as vendors, customers, items, or purchase orders. --- ## 1. How It Works and Configuration Options Synchronization is typically performed via the **Cloud Sync Connector**, which is installed on-premises and communicates with the connected ERP. Within the platform, a corresponding **record type** (e.g., Debtors, Articles, Orders) is configured for each data category to be synchronized. ### Elements to Configure: | Element | Description | | --- | --- | | **ERP Profile** | Specifies which technical connection profile (Access Profile) is used to communicate with the ERP. | | **Synchronization Interval** | Defines the **timing** of synchronization using **crontab syntax** (see [crontab.guru](https://crontab.guru)). | | **Function Modules (SAP)** | Optionally, customer-specific **function modules (RFCs)** can be specified. If none are defined, the **standard modules** included in the official SAP transports are used. | | **Synchronization Mode** | Depending on the target system, a choice can be made between **full or incremental synchronization**. | --- ## 2. Execution via Cloud Sync Connector Synchronization processes are typically executed via the **Cloud Sync Connector**, which is locally installed and enables secure access to internal systems. It handles communication with the ERP, loading of data, and forwarding to the platform. The connector: - Connects cyclically or manually to the ERP system - Retrieves the defined data structures and fields - Transfers them in a standardized format to the platform - Logs the status, errors, and duration of the transfer --- ## 3. Status Display (Monitoring) In the **States** section (see screenshot), the current status of each individual synchronization source can be viewed: | Column | Meaning | | --- | --- | | **Type** | Name of the synchronized data category (e.g., Debtors, Articles, Orders) | | **State** | Current status (e.g., `Idle`, `Running`, `Error`) | | **Last Duration** | Duration of the last successful synchronization | | **Last Synchronization** | Timestamp of the last execution | This overview enables a quick **status check and runtime monitoring** to detect problems early and validate data availability. --- ## 4. Typical Application Scenarios | Scenario | Example | | --- | --- | | **Invoice verification with ERP data matching** | Item numbers, vendors, and purchase orders are synchronized regularly | | **Master data reconciliation for Capture processes** | Customers and vendors are available during validation | | **Vendor recognition via IBAN or VAT ID** | Automatic matching via synchronized fields in the document and ERP | --- ## 5. Normalization for Automated Processing A key component of ERP synchronization in the CLARC Infinity platform is the **normalization of imported data**, making it optimally usable for **automated processing, recognition, and assignment** in document-based processes. The data imported from the ERP system is **intelligently analyzed, prepared, and structurally standardized** within the platform, enabling reliable identification even with deviating spellings or formatting. ### 5.1 Normalization Steps | Step | Description | | --- | --- | | **Tokenization** | Decomposition of names, terms, or codes into individual components (_tokens_) — e.g., simplified: "Müller GmbH & Co. KG" → `["mueler", "gmbh", "co", "kg"]` | | **Cleansing** | Removal of irrelevant characters, standardization of formats (e.g., VAT IDs, phone numbers, IBAN) | | **Case normalization** | Uniformization for improved comparability | | **Accent and punctuation** | Normalization of linguistic special characters (e.g., `é` → `e`) | | **Intelligent variant generation** | Addition of common spelling variants (e.g., "St." ↔ "Street") | This prepared data subsequently serves as the basis for: - **Fuzzy matching / approximate assignment** in Capture or Invoice processes - **Full-text search within synchronized data** (e.g., for vendor names) - **Automatic field population** based on extracted values (e.g., assignment of an IBAN to a vendor ID) ### 5.2 Benefits of Normalization - 🔍 **Increased matching accuracy** in automated capture processes - 🔄 **Fault-tolerant assignment** even with deviating spellings - ⚙️ **Automatable field population** without user interaction - 🔗 **Reliable ERP referencing** in system-supported validations --- The **ERP Synchronization** area ensures that all relevant ERP data is available in the CLARC Infinity platform in a **structured, up-to-date, and automated** manner. The combination of **configurable time intervals**, **customer-specific connectivity**, **standard integration (e.g., for SAP)**, and **on-premises connector technology** provides maximum flexibility and control — regardless of system size, integration depth, or industry environment. --- # Quantity Units Source: https://clarc.com/docs/en/administration/customizing/mdm/quantity-units.md # Definition of Quantity Units **Standardized Maintenance and Mapping of Units for ERP-Adjacent Processes** In the **Master Data Management (MDM)** area of the CLARC Infinity platform, **standardized master data is defined** that is required system-wide for the functional interpretation and further processing of documents. A central element here are **Quantity Units** — i.e., **units of measure** as used in business processes to designate quantities of goods, services, or time expenditures. Quantity units are maintained in the platform so that they are interpretable both: - **functionally** (e.g., "Piece", "Meter", "Hour"), and - **technically unambiguous** (e.g., `C62` per EN16931 or `ST` in SAP) --- ## 1. Purpose and Scope The definition of **Quantity Units** is necessary to: - **unambiguously assign** units recognized from documents - map different **terms and abbreviations** from incoming documents (OCR, EDI, PDF) to **standardized values** - enable **compatible transfers to ERP systems** such as SAP or Microsoft Dynamics - ensure **interoperability** with external standards such as **EN 16931** These mappings are automatically applied, e.g., in the context of: - **Invoice processes** (invoice line items) - **Order processes** (order quantities) - **Capture applications** with line item data --- ## 2. EN 16931 — Background on the Standard **EN 16931** is a European standard for the **semantic and syntactic structure of electronic invoices**. It defines, among other things, standardized **Units of Measure** (UoM) as they must be used within electronic business documents. Examples: - `C62` = "Piece" - `HUR` = "Hour" - `MTR` = "Meter" These codes are used in particular when transferring to **standard-compliant ERP systems or e-invoicing platforms**. --- ## 3. Structure and Maintenance of Quantity Units A mapping entry consists of the following elements: | Field | Description | | --- | --- | | **ERP Unit** | Technical abbreviation from the target system (e.g., `ST` for SAP) | | **Terms** | Synonyms, spellings, abbreviations (e.g., `Pcs`, `piece`, `pc.`) | | **Standard Code (EN16931)** | Official code, e.g., `C62`, for passing to standardized interfaces | | **Description** | Free text for improved readability in the UI | Multiple mapping sets can be maintained as **independent configuration entries** — e.g., specific to **SAP**, **Microsoft Dynamics**, or **industry-specific formats**. --- ## 4. Use in Processes The system can have **one or more mapping sets** registered. These are referenced in the respective **processing context**: - **Invoice solution**: Assignment of recognized units in invoice line items - **Order Capture**: Matching of units with order line items in the ERP - **Data extraction**: Normalization of extracted units before transfer - **Validation**: Verification of permitted unit combinations and consistency Application occurs **fully automatically via configuration references** — manual selection by the user is generally not required. --- ## 5. Example: SAP Standard Mapping The standard delivery includes a **preconfigured mapping for SAP**. This contains, among others: | ERP Unit | Synonyms | EN16931 Code | Description | | --- | --- | --- | --- | | `ST` | `Pcs`, `piece`, `pc.` | `C62` | Piece | | `M` | `m`, `meter`, `running meter` | `MTR` | Meter | | `H` | `hr`, `hour`, `h` | `HUR` | Hour | | `PK` | `package`, `pkg`, `pk.` | `XPK` | Package | This mapping can be **extended or overridden per tenant** if needed. --- The **definition and maintenance of Quantity Units in MDM** ensures that all process-relevant units of measure can be **unambiguously and norm-compliantly interpreted** — regardless of OCR variants, input formats, or ERP target systems. Through centralized maintenance, automatic application, and compatibility with standards such as **EN 16931**, this area forms an important foundation for **stable, valid, and interoperable document processes**. --- # Customers Source: https://clarc.com/docs/en/administration/customizing/mdm/customers.md # Customers The **Customers** section displays all customer master data available in the system. These can be imported automatically from a leading system (e.g., SAP or Microsoft Dynamics) via [ERP Synchronization](erp-synchronization.md), or **created manually**. --- ## 1. Master Data and Billing Configuration Customers are particularly relevant for the **Billing module**: customer-specific settings can be stored per customer to control the format and channel through which outgoing documents (e.g., invoices) are delivered. ### 1.1 Transfer Format Defines the format in which the document is delivered to the customer: | Value | Description | | --- | --- | | `ZUGFeRD` | Hybrid PDF format with embedded XML according to the ZUGFeRD standard. | | `X-Rechnung` | Purely structured XML format according to the XRechnung standard (German standard for public sector recipients). | | `PDF` | Classic PDF without structured embedding. | | `Paper` | Physical postal delivery. | ### 1.2 Delivery Method Specifies the channel through which the document is delivered: | Value | Description | | --- | --- | | `Postal Service` | Delivery by post (physical). | | `E-Mail` | Electronic delivery by email. | | `E-Gateway Provider` | Transmission via a connected e-invoicing network service provider. | ### 1.3 Dispatch Controls the timing and mode of delivery: | Value | Description | | --- | --- | | `Scheduled` | Delivery at a defined point in time (e.g., batch processing). | | `Immediate` | Delivery occurs immediately after approval. | | `Manual` | Delivery is triggered manually by a user. | --- ## 2. Additional Fields | Field | Description | | --- | --- | | **Routing ID** | Routing identifier for electronic invoice transmission (required in particular for public sector recipients under the XRechnung standard). | | **Participant ID** | Identifier of the participant in the e-invoicing network (e.g., Peppol Participant ID). | | **Email Recipient** | Target email address for electronic invoice delivery. | | **Country** | Country of the customer — may influence country-specific format or transmission requirements. | | **Language** | Language of the customer — can be used for document generation in the respective language. | --- # XDC (Cross Domain Configuration) Source: https://clarc.com/docs/en/administration/customizing/xdc/index.md # Managing Cross-Domain Configurations with XDC (Cross Domain Configuration) **XDC (Cross Domain Configuration)** is a central configuration module for the system-wide management of uniform, non-system-specific settings that apply across domains. Its goal is to provide reusable and consistent configuration profiles that can be used independently of specific processes, tenants, or target systems. Currently, the use of XDC focuses on managing **profiles for document conversion and optimization**, particularly in the following areas: - **Format conversion**: Definition of conversion profiles for transforming documents into standardized target formats such as **PDF** or **image formats** (e.g., TIFF, PNG, JPEG). This is especially necessary for standardized further processing, archiving, or system integration. - **Document optimization**: Provision of technical parameters for the **quality improvement, compression, resolution, and structural correction** of documents — both for PDF documents (e.g., OCR text embedding, reduction of embedded objects) and for image files (e.g., binarization, deskew, denoising). XDC profiles are centrally managed, versioned, and then made available to process-oriented components such as the Capture Engine, validation, or conversion services. XDC thus serves as an **abstract configuration layer** that defines technical specifications decoupled from their application — with the advantage of high reusability, consistency, and maintenance efficiency. --- # Document Conversions Source: https://clarc.com/docs/en/administration/customizing/xdc/document-conversions.md # Format Conversion and Optimization of Documents for Further Processing in Workflows **Document Conversion** is a central component of the CLARC Infinity platform and enables the **targeted transformation and optimization of documents** before they are used in downstream processes such as archiving, extraction, or transfer to third-party systems. Typical use cases include: - Standardizing incoming documents (e.g., Office → PDF, PDF → TIFF) - Compression and storage optimization - Ensuring compliant output formats for external interfaces Conversion is fully integrable into workflows and especially into **Document Flows**. There, a suitable conversion rule can be assigned based on **document type, format, and processing context**. --- ## 1. Integration into Processes Conversion rules are defined as independent **configuration profiles** and can be assigned at various points, e.g.: - In a **Document Flow**, before the document is transferred to a target system - Within a **workflow** for format standardization This allows the **entire lifecycle of a document** to be mapped without media breaks and in a format-consistent manner. --- ## 2. Supported Input Formats | Input Format | Description | | --- | --- | | **Image** | Single- or multi-page images (e.g., TIFF, PNG, JPEG, BMP) | | **PDF** | PDF documents, possibly with embedded text, scans, or images | Different conversion and optimization options are available depending on the input format. --- ## 3. Configuration Elements ### 3.1 Conversion Settings | Field | Description | | --- | --- | | **Document source format** | Format of the input document (`Image` or `PDF`) | | **Document target format** | Target format after conversion (e.g., `Image`, `PDF`, `PDF/A`) | | **Image target compression** | Only relevant for image formats; selection of the compression method (e.g., `CCITT Group 4`, `JPEG`, `LZW`) | | **Image target format** | Target format for converted images (e.g., `TIFF`, `JPEG`, `PNG`) | | **Quality** | Quality level for lossy compression (e.g., JPEG 75%) | | **Split or merge** | Option to **split or merge** multi-page documents | | **Keep sourcefile** | When enabled, the original document is **retained in addition to the converted version** | --- ### 3.2 Optimization Settings These functions serve for **image cleanup and orientation optimization** before conversion: | Setting | Description | | --- | --- | | **Deskew** | Corrects skew in scanned images (automatic straightening) | | **AutoRotate** | Automatically rotates the document to the correct reading orientation | | **Despeckle** | Removes pixel noise or scan artifacts to improve quality | --- ## 4. Typical Application Scenarios | Scenario | Example Configuration | | --- | --- | | **PDF to PDF/A for long-term archiving** | Source: `PDF`, Target: `PDF/A`, `Keep sourcefile: false` | | **Scan to CCITT-G4-TIFF for ERP integration** | Source: `Image`, Target: `Image`, Format: `TIFF`, Compression: `CCITTGroup4` | | **Reducing file size** | Source: `PDF`, Target: `PDF`, Compression: `JPEG`, Quality: `65` | --- ## 5. Benefits of Configurable Conversion - ✅ **Standardized formats** for further processing, filing, or interfaces - 🔁 **Reusable profiles** for various processes and target systems - ⚙️ **Fully integrable** into Document Flows, workflows, and Capture processes - 📉 **Optimization of storage space and processing time** - 🔐 **Long-term archiving capability** through PDF/A support --- ## 6. Summary **Document Conversion** is a powerful and flexible tool for **format standardization, optimization, and preparation of documents** for further processing steps. Through the ability to centrally manage conversion profiles and integrate them purposefully into processes, a **uniform, controlled, and automated conversion behavior** is achieved across the entire platform. --- # ECM (Enterprise Content Management) Source: https://clarc.com/docs/en/administration/customizing/ecm/index.md # Enterprise Content Management (ECM) and Modern Archive Management **Enterprise Content Management (ECM)** refers to the holistic management, control, and provision of unstructured information — especially documents — throughout their entire lifecycle. The goal of an ECM system is to capture, store, find, and provide information efficiently, securely, traceably, and in a rule-compliant manner — both for employees and for connected systems. A central element of an ECM system is the **document archive** or **repository**, which serves as a structured, audit-compliant storage for all business-relevant content. In modern ECM architectures, repositories not only fulfill the function of pure storage, but also provide a wide range of advanced services that enable intelligent and secure management. --- ## 1. Structured Archiving with Versioning and Retention Controls Documents stored in a repository can be managed through integrated **versioning**. Changes to documents do not overwrite existing content, but instead create new versions, so the complete change history remains traceable. For legally or operationally relevant content, the system supports **immutable retention** (WORM — Write Once Read Many) as well as a **change lock** that technically prevents manipulation or deletion for a defined period or permanently. These features are essential for compliance with regulatory requirements (e.g., GoBD, GDPR, SOX). --- ## 2. Security Features and Content Integrity To ensure the **integrity of stored documents**, an automatic check for potential threats can be performed during filing — e.g., through **virus scanners** that inspect documents for malware or manipulated content. This integrates the repository not only as an archive but also as a security mechanism within the overall security architecture. --- ## 3. Automatic Tagging and Semantic Recognition via AI An outstanding feature of modern ECM systems is the ability for **AI-assisted document analysis**. Through **automatic tagging**, content is analyzed, classified, and tagged with keywords upon filing — e.g., based on recognized document type, metadata, extracted entities, or text content. This not only improves discoverability but also enables **semantic grouping and process-oriented further processing**. --- ## 4. Search Capabilities: Full-Text and AI-Based Search For effective use of archived information, powerful **search functions** are available. In addition to classic **full-text search** across document content and metadata, the system can also draw on **AI-based search technologies**, in particular **RAG models (Retrieval-Augmented Generation)**. These combine classic index search with generative AI to deliver contextually appropriate answers to complex queries — such as knowledge questions or case-based research. --- ## 5. Interfaces: CMIS and SAP ArchiveLink For **system integration**, the ECM provides standardized interfaces. Through the **CMIS API (Content Management Interoperability Services)**, the repository can be integrated system-independently into third-party applications — both for reading and writing. Additionally, **SAP ArchiveLink** is supported, enabling the ECM system to be seamlessly embedded as an external archive system for SAP systems — e.g., for audit-compliant filing of documents, invoices, or order records. --- ## 5. Granular Rights Management A central aspect of archive management is **fine-grained rights management** that can be enforced down to the **document level**. Permissions can be defined not only at the repository or folder level, but also individually per document, version, or even based on metadata (e.g., company code, department). This enables precise and compliant access control aligned with organizational, functional, or legal requirements. --- ## 6. Summary Through the combination of structured archiving, intelligent analysis, powerful search, secure retention, and standardized integration, the ECM system forms the digital backbone for **secure, compliant, and efficient document management** in modern organizations. --- # Repositories Source: https://clarc.com/docs/en/administration/customizing/ecm/repositories.md # Repositories --- # APP (Application) Source: https://clarc.com/docs/en/administration/customizing/app-application/index.md # Setup and Management of Capture Applications The **APP (Application)** area covers the configuration, deployment, and management of functional applications within the platform, with a focus on **Capture applications**. These applications are used for capturing and pre-processing incoming information — especially documents — from various sources and in varying formats. The central Capture components handle the following tasks: - **Scanning:** Capturing physical documents via connected scanners or virtual scan sources. Technical parameters such as resolution, color depth, page formats, or scan profiles are centrally managed. - **Validation:** Verification, supplementation, or correction of automatically extracted data by users. The validation component supports plausibility checks, data comparison with master data (e.g., vendors), and rule sets for quality control. A particular feature of Capture applications is their **deep integration with Microsoft Office**, especially **Outlook**. This allows users to capture emails and their attachments directly from their inbox and assign them to a downstream business process with minimal effort — such as archiving, invoice processing, or case creation. Word or Excel documents can also be incorporated this way. Applications in the APP area are typically tailored to specific process scenarios, e.g.: - Incoming invoice processing - Order or quotation capture - Employee file management Through the close integration with backend systems (e.g., DMS, ERP, archive) and the ability to integrate into existing work environments, Capture applications enable **end-to-end, media-break-free processing** and make a decisive contribution to the efficiency and digitalization of operational business processes. --- # Capture Source: https://clarc.com/docs/en/administration/customizing/app-application/capture.md # Setup and Configuration of Capture Applications The **Capture Application** component within the CLARC Infinity platform serves the configuration of **capture applications** for the structured intake, validation, and pre-processing of documents. These applications are used particularly in the context of **scanning**, **incoming mail processing**, **invoice verification**, or **functional process validation**. Capture applications connect **Business Objects**, **desktops**, **workstacks**, **user permissions**, and (optional) automation such as **barcode recognition** into a user-friendly solution for day-to-day operations. --- ## 1. Linking to Business Object and Desktops Every Capture application is based on a **Business Object** that defines the functional structure (properties, field types, etc.). Depending on the configured Business Object, a dedicated desktop can be configured for each **capture context and the available workspace**. The available desktop contexts are: | Desktop | Description | | --- | --- | | **Common** | General fallback — used when no more specific desktop applies. | | **Capture** | General capture context (e.g., scanned documents, generic inbound). | | **Office** | Parent context for all Office-based captures. | | **Word** | Specific context for Microsoft Word documents. | | **Excel** | Specific context for Microsoft Excel documents. | | **Outlook** | Specific context for captures from Microsoft Outlook. | | **Teams** | Specific context for captures from Microsoft Teams. | **Fallback logic:** If no desktop is configured for a specific context, the next more general desktop is used automatically (e.g., Word → Office → Capture → Common). This allows shared base layouts to be defined centrally while context-specific variations can be overridden selectively. These desktops control **which fields are visible, editable, or read-only** and enable **context-dependent form control** depending on the capture situation. --- ## 2. AI-Powered Field Extraction — Ask Clara :::tip Ask Clara — Automatic Field Extraction by AI **Ask Clara** is the integrated AI function of the Capture application. It analyses all available information — email body, attachments, scanned documents, OCR results, and more — and automatically extracts all relevant data for the respective Business Object. The recognised values are populated directly into the corresponding fields of the capture form. This significantly reduces manual data entry effort and increases processing speed and quality — especially with variable or poorly structured inbound sources. ::: Ask Clara is activated per Capture application and can access all sources available in context: - **Email body** and subject line - **Email attachments** (PDF, images, Office documents) - **Scanned documents** (text processed via OCR) - **Already captured field values** as additional context The extraction is guided by the structure of the configured Business Object and populates the defined fields precisely — without the user having to transfer individual values manually. --- ## 3. Controlling the Capture Function (Inbox) With the **Disable Inbox** option, the capture function can be removed from the application. In this case, the application serves **exclusively for processing and validating already existing documents**, for example in the context of correction checks. This is particularly useful for roles with pure validation responsibility, such as specialist departments or external auditors. --- ## 4. Settings (Scan and Recognition Options) | Setting | Function | | --- | --- | | **Standard Scan Profile** | References a pre-configured scan profile (e.g., color mode, resolution) | | **Office Elements** | Defines which elements are provided from the Office integration — for example, all attachments of an email or the original Word document or its PDF equivalent | | **Single Click OCR** | When enabled, content can be transferred to the corresponding index field via a single click | | **Can Release All** | Enables a button to **release all documents in a batch** simultaneously | --- ## 5. Post Processing In the **Post Processing** section, it is defined **which downstream process** is triggered after capture or validation is completed. Examples: - Starting a **Document Flow** - Transfer to an **Invoice Solution** - Starting a **Workflow** - etc. The target definition selected here controls the automatic forwarding of completed capture operations. --- ## 6. Barcode Recognition Barcode recognition enables **automatic structuring of scanned documents** within a Capture application. It is typically used to **automatically separate, classify, or read relevant control information** from document batches — such as document numbers or process identifiers. ### Objective - Automatic recognition of barcodes directly during the scan process - Splitting a scan batch into individual processes - Assignment of values to fields or identifiers ### Configuration Options | Setting | Description | | --- | --- | | **Active** | Enables barcode recognition for this Capture application | | **Scenario** | Defines **where** in the document a barcode is expected. Available scenarios: _Barcode on first page_: Split at barcode on page 1 — _Barcode on last page_: Split at barcode on last page — _Barcode on every page_: Each page with a barcode is interpreted as an individual process | | **Delete Barcode Pages** | Deletes all pages that contain a barcode matching the configuration. Important for scenarios that use barcode separator sheets | | **Barcode types** | Selection of **barcode formats** to be recognized, e.g., Code 128, Code 39, QR Code | | **Min length / Max length** | Defines the expected length of barcode content to filter valid results | | **RegEx** | Optional regular expression for **precise pattern matching** in barcode content (e.g., only numeric IDs, specific prefixes, etc.) | ### Practical Applications - **Batch processing for incoming mail**: Barcodes on separator sheets automatically define new processes. - **Document recognition**: A scanned invoice is directly linked to a business transaction via the barcode value. - **Data pre-population**: A recognized barcode value can be used to automatically pre-fill a field in the Business Object. ### Benefits - Automated separation without user interaction - Reusability across multiple Capture applications - Combinable with OCR and validation processes - Increased speed and accuracy in document capture --- ## 7. Permissions The permissions area defines **which users or groups** are allowed to access the application. Both **individual users** and **roles or groups** (e.g., `Administrators`, `Everyone`) can be selected. This control is essential for a clean role-based task assignment within the functional department. --- ## 8. Workstacks **Workstacks** serve the **structured assignment and organization of capture operations**. They enable **fine-grained control of workload distribution** — e.g., by document type, department, incoming source, or priority. Two main types: - **Inbox**: Entry area for unprocessed documents - **Tasks**: Area for assigned work items (e.g., through automatic assignment or user selection) Additional workstacks can be created individually. Users with the **CaptureManager** role may **manage these within the application itself**, providing high flexibility when requirements in the functional department change. --- The **Application / Capture** area forms the central link between **structured document capture** and **process-driven further processing** in CLARC Infinity. Through the combination of Business Objects, desktops, scan and recognition settings, role control, and barcode automation, a fully configurable capture application is created — one that is both easy to use and deeply integrated — from the first scan step to the finished digital business process. --- # DPM (Device Profile Management) Source: https://clarc.com/docs/en/administration/customizing/dpm/index.md # Centralized Management and Dynamic Assignment of Scanner Profiles **Device Profile Management (DPM)** is a central module for the management, provision, and intelligent assignment of **scanner profiles** within the platform. Its goal is to enable standardized, location-independent, and automated use of scanning devices — regardless of whether they are locally connected devices or network scanners. Unlike classic configurations where a specific scanner is fixed to a workstation, DPM follows a **property-based approach**: scanner profiles describe **functional requirements** — such as color mode, resolution, duplex capability, format, speed, or supported drivers (e.g., TWAIN, WIA, ISIS) — rather than the physical device ID. This allows a profile to be used anywhere, and the system searches at runtime for **an available scanner** that matches these properties — either locally or on the network. This architecture provides significant advantages in distributed or dynamic capture scenarios, such as: - **Hot-desking scenarios**, where users work at different workstations each day, - **Shared services**, where multiple users access a pool of scanners, - **Fault tolerance**, since if a device fails, an alternative compatible device can be used automatically. Assignment is automated, without users needing any technical knowledge about the scanning devices or their configuration. In the respective **Capture application**, only the desired scanner profile is stored — e.g., "Duplex color scan for invoices" — and the system handles the selection of the appropriate device at runtime. DPM thus forms a central prerequisite for a **scalable, low-maintenance, and standardized capture environment**, where ease of use, flexibility, and device independence are the priority. --- # Scanner Source: https://clarc.com/docs/en/administration/customizing/dpm/scanner.md # Centralized Configuration and Assignment of Scan Profiles for Capture Applications The **Scanner Profile Setup** area serves the centralized management and configuration of **scan parameters, devices, and host systems** used for capture in Capture applications. The goal is to make scanning operations **standardized, reusable, and automated** — regardless of the workstation or scanner device used. A scanner profile contains not only basic scan settings (e.g., resolution, color mode) and image optimization options, but also information about **permitted scanner devices** and **authorized client systems (hosts)**. The **dynamic and automated assignment of a matching profile to a workstation** is handled by the Capture application — depending on configuration parameters, availability, and device properties. --- ## 1. Setting Up a Profile A new scanner profile is configured with the following parameters: ### 1.1 Scan Settings | Setting | Description | | --- | --- | | **Compression** | Compression method (depending on the target format) | | **Resolution** | Scan resolution in dpi (e.g., 200, 300, 600) | | **Pixel Type** | Color depth of the scan (e.g., `Monochrome`, `Grayscale`, `Color`) | | **Paper Size** | Expected paper size (e.g., A4, Letter, Auto) | ### 1.2 Image Processing / Optimization | Option | Function | | --- | --- | | **Duplex** | Double-sided scan (if supported by the device) | | **Discard Blank Pages** | Automatically remove blank pages | | **Deskew** | Automatically correct skew | | **Despeckle** | Remove pixel noise | | **Dilate** | Enhance outlines (e.g., for thin text) | | **Remove Borders** | Crop page margins | | **Automatic Page Size** | Dynamic page detection | | **Automatic Rotation** | Automatically adjust page orientation | --- ## 2. Device Management (Devices) Under the **Devices** section, **specific scanner devices are registered** that are permitted for use with this profile. Registration is performed by the system, typically based on: - Device name / manufacturer information - Connection type (TWAIN, WIA, network device) - Serial number or specific hardware identifier A device can be assigned to multiple profiles, e.g., for different use cases (document capture, archiving, etc.). --- ## 3. Host Management (Clients) In the **Hosts** section, **client systems are registered** on which a scanner is locally connected and that are permitted to use the profile. A host represents, e.g.: - A specific workstation (e.g., `scan-client-01`) - A terminal server user - A user group with local access A scanner profile can only be applied on registered hosts — this provides additional security and control in day-to-day operations. --- ## 4. Scanner Communication via Anyscan Client For communication with the local scanner, the **Anyscan Client** is required. This is a lightweight component installed on the host system that controls the physical device. The address of the Anyscan Client is specified in the scanner profile — e.g.: `http://localhost:4710` The client must be **reachable and running** during setup. A test can be performed directly from the interface. In case of connection errors (e.g., "No response"), ensure that: - The service is actively running - Network connection and firewall settings are correct - Port forwarding (default: `4710`) is properly configured --- ## 5. Automatic Selection in the Capture Application Profile assignment in the Capture application occurs **automatically based on the scan environment**: - When the application detects a host and a connected device, it searches for a matching profile. - If multiple profiles are applicable, the most specific or most recently used one is selected. - If no matching profile is found, a fallback selection may occur or the user is notified. This enables **flexible, user-friendly operation without manual assignment**, even when devices or workstations change. --- The **Scanner Profile Setup** area provides a powerful way to **define scanning behavior centrally and in a standardized manner**, while simultaneously enabling **fine-grained control of devices and clients**. Through the combination of clear profile specifications, device authorization, host binding, and the Anyscan Client, a **robust and scalable capture concept** is created — suitable for both small and highly distributed scan environments. --- # DEV (Development) Source: https://clarc.com/docs/en/administration/customizing/development/index.md # Central Development Environment for Scripting, Automation, and UI Customization The **DEV (Development)** area forms the technical foundation for developing, customizing, and extending applications and processes within the platform. Central development artifacts are managed, versioned, and deployed here — particularly in the form of **client scripts**, **server scripts**, and associated **resource configurations**. --- ## 1. Client Scripting — Dynamic User Interfaces and Capture Logic In the client context, scripts based on **TypeScript** are used to: - Flexibly design **Capture applications** (e.g., controlling form logic, validation rules, dynamic input elements), - Individually configure **DMS screens** (e.g., form fields, UI behavior, context elements). These scripts enable a dynamic and customizable user interface tailored to specific functional requirements — without requiring extensive backend changes. --- ## 2. Server Scripting — Process Logic and Automation For server-side control of workflows, task automation, and backend processes, a lightweight **DelphiScript framework** is used. Typical use cases include: - Controlling and branching workflows (e.g., based on OCR results or master data recognition), - Integrating external systems via APIs, - Automated processing steps such as conversion, data enrichment, or transfer to third-party systems. --- ## 3. Resource Management — Configurable Extensibility A central concept in the DEV module is **resource management**: scripts can be linked to any configuration elements — e.g., parameter tables, rule definitions, or mapping information. These resources are structured so that they **can be customized by consultants** without modifying the script itself. This enables a clear separation between developer configuration and functional configuration. --- ## 4. Development with Visual Studio Code Extension The editing, management, and deployment of scripts is done via a specially developed **Visual Studio Code Extension**. This provides: - A direct connection to the cloud-based development environment (including login and project context), - Functions for uploading and downloading scripts and resources, - Syntax checking, autocompletion, and consistency checks. The VS Code integration allows developers and power users to work in a modern and efficient environment while directly accessing the central platform — without media breaks or local exports. --- # Resources Source: https://clarc.com/docs/en/administration/customizing/development/resources.md # Structured Management of Key-Value Resources for Script-Based Customizing The resource management in the **Development (DEV)** area allows the creation of so-called **resource packages** that can be **assigned to one or more scripts**. These packages consist of **key-value pairs** that can be referenced and used within a script. The goal is to **separate functional customizing from technical logic**, making it possible for consultants or process owners to make adjustments — **without directly modifying the source code** of a script. --- ## 1. Purpose and Scope Resource packages serve as an **external parameterization layer** for script-based projects and offer the following benefits, especially in customer customization and project rollouts: - **Separation of code and configuration**: technical logic remains stable, configurable values can be flexibly adjusted. - **Maintainability**: changes are made through configuration, not through repackaging or code modifications. - **Tenant- and project-specific customizing**: different customer requirements can be met using the same scripts. Typical examples: - Enabling or disabling individual validation rules - Defining allowed values or thresholds (e.g., maximum amount, allowed currencies) - Controlling logic behavior (e.g., `ValidationMode = "Strict"`) --- ## 2. Structure of a Resource Package (Example) A resource package consists of **any number of key-value pairs**. Values are stored as **strings** but can be interpreted by the script as any data type. | Key | Value | Description | | --- | --- | --- | | `ValidationMode` | `Strict` | Controls validation behavior | | `MaxInvoiceAmount` | `10000` | Amount threshold for a check | | `AllowEmptyFields` | `false` | Toggle for mandatory field validation | --- ## 3. Usage in Scripts Within a scripting project, the resource package is accessed via the `ccResources` object. The assigned values can be used as follows: ``` if (ccResources.Exists("ValidationMode")) { const mode = ccResources.Get("ValidationMode"); if (mode === "Strict") { // Enable strict validation } } ``` Any logic branches, validation rules, or UI behavior can be controlled through these values. --- ## 4. Assignment to Scripts A resource package is assigned to one or more **scripting projects** in the platform. The assignment is done through the development interface or automated as part of the deployment process. During packaging, the resource package is **not embedded in the script**, but instead **loaded at runtime in the target system**, making it possible to change behavior without repackaging. --- ## 5. Benefits and Best Practices | Benefit | Value | | --- | --- | | ✅ No code changes required | Changes made by consultants without developers | | ✅ Tenant-specific behavior | Same code, different configurations | | ✅ Clear separation of logic and data | Higher maintainability and testability | | ✅ Version control possible | Resources can be transported and versioned | :::note **Best Practice:** Keys should be descriptive, consistent, and documented so that functional owners can understand their meaning without technical context. ::: --- **Resource management in the Development area** is an essential tool for **flexible, maintainable, and customer-oriented customizing** in the CLARC Infinity platform. It allows the control of scripts to be **externalized via configurable parameters**, reducing technical complexity and enabling adjustments more efficiently — both during development and in day-to-day operations. --- # Deployment Source: https://clarc.com/docs/en/administration/deployment/index.md # Technical Connection of Infrastructure Components and Preparation of External Integrations The **Deployment** area within the CLARC Infinity platform describes all necessary steps for **connecting external systems and environments**, particularly in the context of hybrid architectures. This is not about configuring services within the platform itself, but rather about **technical preparation and external infrastructure measures** required to enable the platform to interact securely and fully with the existing IT environment. Two central focus areas are the **installation and configuration of the Cloud Connector** and the **preparation of the Microsoft 365 / Azure integration**. --- ## 1. Installation and Configuration of the Cloud Connector The **Cloud Connector** is a lean, locally installable software module that establishes a **secure and controllable connection between the CLARC platform and internal systems**. This is particularly required when data sources, services, or storage locations are **not directly accessible via the internet** — such as on-premises installations of SAP, databases, or file systems. The _Deployment_ area describes: - Which system requirements must be met (operating system, network access) - How the connector is installed - How registration with the platform is performed - How certificates, ports, and access channels are configured - Which error sources or security requirements must be observed The goal is to set up the connector so that the platform can **securely access internal resources without a direct network connection** — completely transparent for processes and users. --- ## 2. Preparation of Integration with Microsoft 365 / Azure AD For organizations using Microsoft 365 or Azure Active Directory, the CLARC Infinity platform offers close integration — particularly for authentication (SSO), mail access, group management, or Office applications. The _Deployment_ area documents: - How to **register an application in the Azure portal** that will later be used by the CLARC platform - Which **permissions (scopes)** are required for the Microsoft Graph API - How to set up **redirect URLs and secrets (client secrets)** - How **Tenant ID and Client ID** are obtained and passed to the platform - How the trust relationship is verified through DNS TXT entries (Trusted Domains) These preparatory steps are necessary so that Azure-based functions such as **SSO, mail integration, or SharePoint archiving** can later be used in customizing. --- # CLARC for MS365 Source: https://clarc.com/docs/en/administration/deployment/clarc-for-ms365.md # Deploying the CLARC for MS365 App in the Microsoft 365 Tenant This guide describes how the **CLARC Office Integration** is centrally deployed and administered in an organization's Microsoft 365 tenant. --- ## 1. Prerequisites - Active Microsoft 365 environment (tenant) - Access to the **Microsoft 365 Admin Center** - **Administrator rights** in the target tenant - Internet connection --- ## 2. Step-by-Step Guide ### 2.1 Sign In to the Microsoft 365 Admin Center 1. Open the **Microsoft 365 Admin Center**: [https://admin.microsoft.com](https://admin.microsoft.com) 2. Sign in with an **administrator account** for your tenant. --- ### 2.2 Navigate to the Apps Area 1. In the left menu, navigate to **"Apps"**. 2. Click **"Get apps"**. This opens the **Microsoft AppSource Store**. --- ### 2.3 Search for and Install the App in the AppSource Store 1. In the AppSource window, search for **"CLARC"**. 2. Select the desired app from the results list. 3. Click **"Get it now"** to deploy the app in the tenant. --- ### 2.4 Deploy to Users or Groups 1. Specify **who the app should be deployed for**: - Individual users - Microsoft 365 Groups - The entire organization (recommended for company-wide use) --- ### 2.5 Grant Permissions 1. After selecting the deployment, click **"Accept permissions"**. 2. If required, sign in again **with an administrator account**. 3. Confirm the requested app permissions. :::note This step **must be performed by a user with admin rights**, otherwise the app will not receive access authorization. ::: --- ### 2.6 Completing the Deployment - After consent is granted, the app is successfully registered in the tenant. - **Synchronization to users' Office applications** happens automatically. :::note **Important**: The app is usually visible in the user's Office client within a few hours. In exceptional cases, this may take **up to 48 hours**. ::: --- ## 3. Management and Follow-Up ### 3.1 Access Deployed Apps 1. Navigate back to the **Apps area** in the Admin Center. 2. There you will see the list of all apps deployed in the tenant — including **CLARC**. ### 3.2 Management Options (Three-dot menu next to app entry) - **Change assignment**: Add more users or groups to the deployment - **Remove app**: Full uninstallation of the app from the tenant - **View statistics**: Usage statistics (e.g., activation, errors) --- ## 4. Azure Tenant Consent for the OBO Flow (Microsoft Graph) For using the **Microsoft Office Capture Integration** in the CLARC Infinity platform, an **Azure tenant-wide administrator consent** is required. This enables the so-called **On-Behalf-Of (OBO) flow**, through which CLARC can access Microsoft 365 resources on behalf of a signed-in user. This is particularly necessary to **extract original documents such as emails in EML format** from Outlook or to automatically capture content from SharePoint and OneDrive. The application requires delegated permissions on Microsoft Graph (e.g., `Mail.Read`, `Files.Read`, `User.Read`). Consent is granted once by a **global administrator** of the Azure tenant via the following link: ``` https://login.microsoftonline.com//adminconsent?client_id=cb7cf832-3101-4076-9797-91d8c4229964 ``` Replace `` with the **tenant ID** of your Microsoft 365 tenant. After successful consent, the application is authorized to request the necessary access tokens for Microsoft Graph in the delegated context of the respective user. The granted permissions can be viewed in the Azure portal under **"Enterprise Applications" → "CLARC" → "Permissions"** and can be adjusted or revoked there if needed. --- ## 5. Summary | Step | Purpose | | --- | --- | | Open Admin Center | Access central management interface | | Get apps | Access Microsoft AppSource Store | | Search for CLARC app | Select and install the Office integration | | Define deployment | Select target groups (users, groups, tenant) | | Grant permissions | Admin consent for system integration | | Grant tenant consent | Admin consent for OBO flow system integration | | Wait for availability | App appears automatically in Office | --- # Cloud Connector Source: https://clarc.com/docs/en/administration/deployment/cloud-connector.md # Installation and Setup of the Cloud Connector and Cloud Sync **For deployment on customer systems (On Premises)** The **Cloud Connector** establishes the connection between a local customer system and the CLARC Infinity platform. It is used to securely and efficiently integrate system-side integrations such as **ERP data synchronization (Cloud Sync)** or the **provisioning of local resources** into the cloud. For managing and running the services, the **Service Manager** is also installed. It handles **monitoring, configuration, and automatic restarts** of the individual services. --- ## 1. Installation via the Platform The required setup files are available within the platform at the following path: **Menu:** `Settings → Setups → Service Manager` This setup installs the **Service Manager** along with all associated components: - `ccservicemanager.exe` (central management service) - `cccloudconnector.exe` (Cloud Connector service) - `cccloudsync.exe` (ERP synchronization) Installation typically occurs **on a Windows Server** within the customer's network infrastructure. The Service Manager is registered **as a Windows service**. --- ## 2. How the Service Manager Works The **Service Manager** is the core of local execution. It handles the following tasks: - Starting and stopping configured services - Background monitoring of service processes - Restart on unexpected termination - Regular status queries via a **web service interface** - Automatic escalation on error states (e.g., notification, logging) This ensures **stable and self-monitored operation** of on-premises services — even during temporary errors or external disruptions. --- ## 3. Configuration Model via the Windows Registry All service configuration is done **by default via the Windows Registry**. During installation, the required registry paths and default entries are **created automatically**. **Entry point**: `HKEY_LOCAL_MACHINE\Software\CLARC\Infinity` **Sub-structure**: - `System` — global settings for all services (e.g., paths, cloud credentials) - `Services` — service-specific settings. The service name corresponds to the executable name **without file extension and in lowercase**, e.g.: `cccloudconnector`, `cccloudsync` **Configuration priority:** | Area | Precedence | | --- | --- | | `Services\` | Highest priority (specific) | | `System` | Serves as fallback (global) | See [Configuration Elements](#administration/general/configuration-elements) --- ## 4. Example Structure: Cloud Credentials The following structure path is used to manage cloud connection credentials: ``` "TenantAccess": { "acme": { "Development": { "Url": "https://cci001.app.clarc.com", "User": "Service", "Password": "" } } } ``` **Notes:** - The **tenant name** (e.g., `acme`) corresponds to the short identifier of the customer tenant. - The **system environment** (e.g., `Development`, `Productive`) is maintained in a cleanly separated structure. - Credentials should be securely managed and set once during installation. --- ## 5. Service-Specific Configuration ### 5.1 Cloud Connector (Service: cccloudconnector) Example configuration: ``` "CloudConnector": { "Tenant": "acme", "Systems": { "Development": { "Active": true } } } ``` This setting enables the Cloud Connector **for the specified tenant and the defined system environment**. --- ### 5.2 Cloud Sync (Service: cccloudsync) Example configuration: ``` "CloudSync": { "Tenant": "acme", "Systems": { "Development": { "SyncErp": true } } } ``` This configuration enables **ERP data synchronization** for the specified tenant and the respective system (e.g., development, test, production). See [ERP Synchronization](#administration/customizing/mdm/erp-synchronization) --- ## 6. After Installation After successful installation and setup: - The Service Manager automatically starts as a Windows service - It monitors all assigned services - The configured services are ready for synchronized communication with the CLARC Infinity platform - Logs, errors, or status information can be retrieved via the web service interface or viewed in the log directory --- Installing and setting up the Cloud Connector via the **Service Manager** enables a **structured, automated, and fault-tolerant connection** of on-premises systems to the CLARC Infinity platform. The **precisely separated registry-based configuration** by tenant, system, and service ensures that each environment can be individually customized, monitored, and operated securely — without manual scripts or deployment complexity. This makes the setup particularly straightforward for consultants while remaining operationally robust. --- # SCIM-Provisioning Source: https://clarc.com/docs/en/administration/deployment/scim-provisioning.md # Automatic Synchronization of Users and Groups via SCIM CLARC Infinity supports **SCIM 2.0** for automated provisioning and synchronization of **users and groups** from external identity providers. ## 1. Overview Via the SCIM interface, users and groups are: - automatically created - updated - deactivated or removed - group memberships synchronized Typically, **Microsoft Entra ID (Azure AD)** is used for this purpose. User management is thus handled centrally in the identity provider, while CLARC Infinity consistently adopts the provisioned identities. ## 2. Prerequisites The following prerequisites are required for setting up SCIM provisioning: - Access to **Microsoft Entra ID (Azure AD)** with administrative rights - A **Client ID** and **Client Secret** configured in CLARC Infinity :::note An **email address is not mandatory for users in CLARC Infinity**. Accordingly, no fixed email attribute needs to be mapped. ::: ## 3. Creating the Enterprise Application in Entra ID The SCIM integration is set up via an **Enterprise Application** in Microsoft Entra ID. Procedure (standard approach): 1. Open the **Azure Portal** 2. Navigate to **Microsoft Entra ID** 3. Go to **Enterprise Applications** 4. Click **New application** 5. Select **Create your own application** 6. Enter a name (e.g., _CLARC Infinity SCIM_) 7. Select the option **Integrate any other application you don't find in the gallery** 8. Create the application This Enterprise Application forms the technical foundation for SCIM provisioning. ## 4. Enable and Configure Provisioning After creating the application, provisioning is configured: 1. Open the Enterprise Application 2. Navigate to **Provisioning** 3. Select **Automatic provisioning** 4. Start the configuration via **Connect your application** ## 5. SCIM Connection Parameters The following parameters are entered for the connection: ### 5.1 Authentication - **Authentication Method:** OAuth 2.0 – Client Credentials - **Client ID:** from CLARC Infinity - **Client Secret:** from CLARC Infinity ### 5.2 Endpoints (Example) The following schema is used as the base URL: - **SCIM Base URL** ``` https://cci001.app.clarc.com/application/api/v1/scim ``` - **Token Endpoint** ``` https://cci001.app.clarc.com/application/api/v1/iam/oauth/token ``` After entering the parameters, the connection is verified via **Test connection**. If the test is successful, the configuration can be saved. ## 6. Scope and Synchronization Coverage In the **Provisioning Settings** section, you define which objects are synchronized: - **Users** - **Groups** - or **Users and Groups** Typically, **"Sync all users and groups"** is used to ensure complete synchronization. ## 7. Attribute Mapping CLARC Infinity is **not tied to a specific attribute structure**. The required minimum attributes are mapped internally. Typical mappings include: - Username / login - Display name - Active status - Optional additional attributes (e.g., language) :::note Mapping an email attribute is **optional** and not mandatory. ::: The mapping can be adjusted at any time without losing existing users. ## 8. Provisioning Modes After completing the configuration, two operating modes are available: ### 8.1 Automatic Provisioning - Regular background synchronization - Users and groups are automatically synchronized - Recommended standard operation ### 8.2 Provisioning on Demand - Manual provisioning of individual users or groups - Suitable for testing or targeted maintenance ## 9. Behavior on Changes Via SCIM, the following changes are reliably reflected: - Creation of new users - Changes to user attributes - Activation / deactivation - Group memberships - Deletion / deprovisioning Functional permission assignment (roles, group rights) continues to be managed **within CLARC Infinity**. ## 10. Security and Isolation - Each SCIM integration is **tenant-specific** - Access is exclusively via token-based OAuth authentication - No cross-access between tenants - All accesses are subject to internal access profiles and security scopes ## 11. Typical Use Cases - Centralized user management via Entra ID - Automatic deprovisioning during offboarding - Consistent group structures across all systems - Reduction of manual user maintenance in CLARC Infinity ## 12. Summary The SCIM interface enables **clean, secure, and automated user and group management** in CLARC Infinity. It is flexibly configurable, not bound to email addresses, and fully integrable with modern identity providers. --- # Scripting Source: https://clarc.com/docs/en/scripting/index.md # Scripting in the CLARC Infinity Platform **Customizability, automation and extensibility through scripts** With the **Scripting** area, the CLARC Infinity Platform provides a powerful tool for **flexibly adapting the platform to individual requirements**, **automating functional processes** and **extending interactive user interfaces**. Scripting supplements standardized configuration with dynamic logic and enables precise control of both **client-side interactions** and **server-side processes**. The platform fundamentally distinguishes between two scripting approaches: --- ## 1. Client Scripting (TypeScript) **Client scripting** is used wherever **dynamic behavior in the user interface** is required — such as in **capture forms (desktops)** of business objects. Development is done in **TypeScript**, a modern extension of JavaScript with static typing and support for structured, scalable programming. Typical use cases: - Real-time validation of inputs - Response to UI events (e.g. clicks, navigation, field changes) - Dynamic showing or hiding of fields - Access to structured configurations (e.g. key-value resources) - Use of reusable libraries - Integration of data sources via the Cloud Connector Client scripts are organized in scripting projects, versioned and — when needed — integrated into the platform as JavaScript bundles. Execution occurs **event-driven directly in the user's client**. --- ## 2. Server Scripting (DelphiScript) **Server scripting** is used for **controlling server-side processes and automations** within the platform. **DelphiScript** is used for this — a lightweight and declarative scripting language ideally suited for implementing: - Workflow logic (branches, conditions, decisions) - Background processing (e.g. data extraction, conversion, routing) - System integration via API calls or database access - Automatic notifications or escalations - Scheduled actions or event triggers Server scripts are stored directly in **workflow definitions**, **system events** or **task configurations** and are executed at runtime by the platform. They can interact with platform services such as logging, data access, transport or configuration. --- ## 3. Common Principles Regardless of the scripting type, the following principles apply: - ✅ **Modularization and reuse**: Functions can be outsourced to libraries - 🔒 **Security and runtime control**: Execution takes place within controlled sandbox environments - 🔧 **Tool support**: Development typically takes place via an integrated VSCode extension with access to the cloud repository and system context - 📦 **Deployable**: Scripts can be versioned, packaged, transported and used across systems --- ## 4. Conclusion The scripting system of CLARC Infinity creates the **connection between configurable standard and individual customization**. While client scripting handles **interactive, user-oriented extensions**, server scripting takes care of **intelligent process control in the backend**. Together, they enable a platform that not only can be modeled but actively behaves — context-sensitive, automated and future-proof. --- # VSCode Extension Source: https://clarc.com/docs/en/scripting/vscode-extension/index.md # Introduction to the VSCode Extension The **CLARC Infinity Development Extension** for Visual Studio Code (VSCode) is a powerful development environment developed specifically for creating, customizing and managing script extensions in **CLARC Infinity**. It provides developers with an intuitive, efficient and flexible platform to realize their projects directly within VSCode. This documentation accompanies you in understanding and making optimal use of the CLARC Infinity Development Extension. It is aimed at both beginners and experienced developers and provides a comprehensive overview of the features and operation of the extension. :::note Download [Visual Studio Code](https://code.visualstudio.com/) from Microsoft. Use the System Installer here, not the User Installer. ::: --- ## 1. Features The CLARC Infinity Development Extension offers a variety of functions specifically designed to simplify the development process and increase productivity. The core features include: ### 1.1 Script Management - Creation, editing and management of scripts within a structured project environment. - Support for syntax highlighting and auto-completion to minimize errors and improve readability. ### 1.2 Script Compilation and Packaging - Seamless compilation of scripts to check them for correctness and compatibility. - Creation of packages for smooth deployment in the CLARC Infinity platform. ### 1.3 Project Synchronization - Direct synchronization of projects with the CLARC Infinity environment to integrate changes in real time. - Support for version control and conflict management. ### 1.4 Library Integration - Access to predefined libraries and easy integration of these into scripts. - Management of custom libraries for specific requirements. ### 1.5 Business Object Integration - Direct integration of business objects from the corresponding CLARC Infinity tenant. - Automated mapping of data and functions to save development time. The combination of these features makes the CLARC Infinity Development Extension an indispensable tool for developers working in the CLARC Infinity environment. Make use of the capabilities of this extension to implement your projects more efficiently and effectively. --- ## 2. Why Visual Studio Code (VSCode) as IDE? Visual Studio Code (VSCode) has established itself as one of the most popular integrated development environments (IDEs) worldwide and offers numerous advantages that make it an ideal choice for developing script extensions in **CLARC Infinity**. ### 2.1 User-Friendliness and Flexibility VSCode is lightweight yet extremely powerful. The intuitive user interface allows for a quick start, while the high adaptability allows developers to tailor the IDE individually to their needs. ### 2.2 Extensibility through Extensions The platform supports a huge selection of extensions that add features such as syntax highlighting, debugging, version control and much more. The **CLARC Infinity Development Extension** fits seamlessly into this ecosystem and uses the flexibility of VSCode to provide a specially tailored development environment. ### 2.3 Cross-Platform Support VSCode is available on all major operating systems, including Windows, macOS and Linux. This cross-platform compatibility ensures that developers can use the same powerful environment regardless of their operating system. ### 2.4 State-of-the-Art Developer Tools VSCode offers first-class features such as integrated Git support, intelligent code highlighting, auto-completion and powerful search functions. These tools promote productive work and help identify errors early. ### 2.5 Community and Support With an active developer community and comprehensive documentation, it is easy to find help and solutions for specific problems. Regular updates are also released that provide new features and improvements. --- ## 3. Why VSCode for CLARC Infinity? The decision to integrate the **CLARC Infinity Development Extension** into VSCode is based on the numerous advantages this IDE offers: - **Optimal development environment:** The features of VSCode combined with the specialized features of the CLARC Infinity Extension make the development of script extensions efficient and intuitive. - **Modern development standards:** VSCode supports current technologies and best practices, enabling developers to create high-quality scripts. - **Future-proofness:** Thanks to regular updates and a strong community, VSCode remains a future-proof choice for developers. --- ## 4. Conclusion With **VSCode** and the **CLARC Infinity Development Extension**, you have a powerful and flexible development environment available that optimally supports both beginners and experienced developers. --- # Installation Source: https://clarc.com/docs/en/scripting/vscode-extension/installation.md # Installing the Extension Install the CLARC VSCode [Extension](https://code.visualstudio.com/docs/editor/extension-marketplace) directly from the Microsoft [Marketplace](https://marketplace.visualstudio.com/items?itemName=clarc-com.clarc-infinity-development&ssr=false#review-details) from within the development environment (search for "clarc"). --- ## 1. Setup After successfully installing the extension via the VSCode Marketplace, the CLARC icon appears in the Activity Bar on the left side. The view container can be moved to any sidebar or panel via drag & drop. --- ## 2. Welcome Page and Login Process Using the extension requires a login with a CLARC Infinity account, as well as installation of Node.js. The login process comprises four steps: Tenant, System Class, Username and Password. Each of these steps is queried via a single input field. If the login credentials are correct, the tree views are updated and the login status in the status bar shows the current tenant and system class. The user is also given the option to store the password just entered in secret storage to facilitate future logins. In the settings, the stored password can be overwritten and deleted. The green dot signals an existing stored password for the currently logged-in account. A red dot signals that no password is currently stored. A prerequisite for a successful login process is a selected root directory and a correct server URL. If these have not been entered independently, the user will be prompted to enter them before inputting login credentials. The root directory should be an empty folder at the beginning. After the initial login, the basic structure is created in the root directory and all necessary node modules are installed (particularly "@ctodev/cclibrary-types"). Node module installation (npm install) occurs if no "node_modules" folder is present in the root directory. Additionally, after each login, a check is made for a newer version of "@ctodev/cclibrary-types" and this is installed if applicable. After successful login, the available information is displayed. The individual tree views can be collapsed and arranged individually. The sidebar consists of the following elements: - CLARC Infinity Tree View, which lists all available Projects, Resources, Business Objects and Libraries, grouped by tenant and system class - Settings The status bar contains further views showing the login status and information about the currently open script. ### Configuration Options In the VSCode settings under Extensions - CLARC Infinity Development, the following settings can be configured: | **ID** | **Description** | **Default** | | --- | --- | --- | | clarc-infinity-development.Theme.Colorful | Enables the colorful mode of the extension. All icons in the tree views are displayed in blue and purple instead of white. | Enabled | | clarc-infinity-development.Login.AskToStorePassword | The user is asked after successful login whether the password for this account should be saved. | Enabled | | clarc-infinity-development.Config.ApiVersion | Defines the API version. | "v1" | :::note The server URL configuration should **not** be changed manually in the VSCode settings, but exclusively via the Settings in the tree view. ::: --- # Sidebar Functions Source: https://clarc.com/docs/en/scripting/vscode-extension/sidebar-functions.md # Overview The sidebar contains the tree views "CLARC Infinity" and "Settings". Each tree view can be collapsed and expanded and moved to different positions via drag & drop. Via the three-dot menu of the sidebar, the tree views can be hidden individually. The following describes the contents and functions of the tree views. --- ## 1. Tree View The CLARC Infinity Tree View provides a central overview and management of the following areas: ### 1.1 Projects Displays all existing projects in a hierarchical tree structure. Projects can be created, edited and deleted here. This view also enables downloading, uploading and opening of projects. ### 1.2 Resources Lists all available resources. Users can create, edit and delete resources here as well as link existing resources to projects. ### 1.3 Business Objects Displays all available business objects. These objects can be integrated into an open script to extend functionality. ### 1.4 Libraries Provides an overview of all available libraries. These can be created, edited and integrated directly into a script to provide reusable code and simplify script development. --- ## 2. Commands List of commands grouped by the mentioned areas: ### 2.1 Navigation | Name | Description | Position | | --- | --- | --- | | Refresh | Refreshes all contents of the view. | Navigation | | Adjust Sorting Mode | Opens a field to select the sorting type. | Three-dot menu | | Sign In to CLARC Infinity | Starts the login process without pre-filled tenant or system class. | Navigation | | Sign In to this Tenant | Starts the login process with pre-filled tenant. | Inline (signed out) | | Sign In to this System Class | Starts the login process with pre-filled system class. | Inline (signed out) | | Sign Out of CLARC Infinity | Starts the logout process. | Inline (signed in) | | Delete (Local) | Deletes all local data of the selected tenant. | Context menu (tenant) | ### 2.2 Projects :::note A project is considered downloaded when it is recognized in the local file system. This is indicated by a colored icon. ::: | Name | Description | Position | | --- | --- | --- | | New Project... | Creates a new project. | Inline (Shortcut: Ctrl+Shift+Alt+N) | | Search Project | Opens a field for searching all projects clearly. | Context menu (Projects root folder) | | New Folder | Creates a folder at the top level. | Context menu (Projects root folder) | | New Folder... | Creates a folder inside the clicked folder. | Context menu (Folder) | | Delete Empty Folders | Deletes all local empty folders. | Context menu (Projects root folder) | | Show Packages | Opens a field to view all existing packages. You can search for packages and delete them. | Context menu (Projects root folder) | | Delete | Deletes the project. | Context menu (Project) | | Edit | Allows editing of individual properties of the project (Name, Sub Path). | Context menu (Project) | | Download | Downloads the project. | Inline | | Open | Opens the project in the current window. | Inline (downloaded) | | Open (New Window) | Opens the project in a new window. | Context menu (Project) | | Delete (Local) | Deletes the project locally. | Context menu (Project - downloaded) | | Delete (Local) | Deletes all projects locally within the clicked folder. | Context menu (Folder) | | Compile | Compiles the project using Webpack and saves the compiled JavaScript in the dist folder. | Context menu (Project - downloaded) | | Package | Creates the deployment state by uploading the compiled JavaScript code. | Context menu (Project - downloaded) | | Link Resource | Opens a field to select the resource to link. | Context menu (Project - downloaded) | | Pull | Downloads the server-side state of the project. Local changes are overwritten. | Context menu (Project - downloaded) | | Upload | Uploads the local state of the project to the server. The server state is overwritten. | Context menu (Project - downloaded) | | Rename | Renames the folder. | Context menu (Folder) | ### 2.3 Resources | Name | Description | Position | | --- | --- | --- | | Create Resource | Creates a new resource. | Inline | | Search Resource | Opens a field for searching all resources clearly. | Context menu (Resources root folder) | | Add Property | Adds a new property to the resource. | Context menu (Resource) | | Delete | Deletes the resource. | Context menu (Resource) | | Edit | Edits the name of the resource. | Context menu (Resource) | | Link to Open Project | Connects the selected resource with the currently open project. | Inline | | Copy Value | Copies the value of the selected property. | Context menu (Property) | | Delete | Deletes the property. | Context menu (Property) | | Edit | Edits the identifier or value of the property. | Context menu (Property) | ### 2.4 Business Objects | Name | Description | Position | | --- | --- | --- | | Search Business Object | Opens a field for searching all business objects clearly. | Context menu (Business Objects root folder) | | Add to Opened Project | Adds all properties of the selected business object to the entry point script of the open project. | Inline | ### 2.5 Libraries | Name | Description | Position | | --- | --- | --- | | New Library... | Creates a new library. | Inline (Libraries root folder) | | Search Library | Opens a field for searching all libraries clearly. | Context menu (Libraries root folder) | | Download | Downloads the library. | Inline | | Open | Opens the library in the current window. | Inline (downloaded) | | Add to Opened Project | Downloads the library and adds the import to the entry point script of the open project. | Context menu (Library) | | Delete | Deletes the library. | Context menu (Library) | | Delete (Local) | Deletes the library from the local file system. | Context menu (Library - downloaded) | | Pull | Downloads the server-side state of the library. Local changes are overwritten. | Context menu (Library - downloaded) | | Upload | Uploads the local state of the library to the server. The server state is overwritten. | Context menu (Library - downloaded) | ### 2.6 Settings Tree View The Settings Tree View provides a listing and management of the various configuration options of the extension. In this view, users can directly change and adjust central settings. | Name | Description | Position | | --- | --- | --- | | Account | Provides account-relevant functions. | Store Password, Delete Stored Password, Sign In / Sign Out | | @ctodev/cclibrary-typings | Shows the current version number of the dependency "@ctodev/cclibrary-typings". | Update cclibrary-typings (Inline) | | Root Directory | Defines the top-level folder of the extension in which all further folders and files are stored. | Choose the Root Directory (Inline) | | Language | Defines the language used. | Edit (Inline) | | Server URL | Defines the URL of the server to which all requests are sent. | Edit (Inline) | --- # Explorer and Editor Source: https://clarc.com/docs/en/scripting/vscode-extension/explorer-and-editor.md # Overview CLARC Infinity Development offers features in the editor and explorer to support script development. These include the following functions: Compile Project, Package Project, Pull Project, Upload Project. The functions are located in the top right of the editor toolbar. **Set as Entry-Point:** Marks the selected file as the entry point. There is always only one entry point script. The selected file is used as the starting point for compilation within the project. It must contain "export default". Right-clicking on a script file in the explorer allows the function to be selected. ## Status Bar ### Display of login status | Status Bar | Description | | --- | --- | | Signed In/Out | Left-clicking on the options Sign In, Sign Out and Configure Server URL allows the options to be activated. | ### Resource and Entry-Point information Left-clicking on the resource allows the options "Unlink Resource" and "Link another Resource" to be activated. | Status Bar | Description | | --- | --- | | **?** | The symbol indicates that the attributes have not been checked. | | ✘ | Indicates that no resource is connected, or the open file is not marked as an entry point. | | ✔ | Indicates that the open file is marked as an entry point. | --- # Local Directory Structure Source: https://clarc.com/docs/en/scripting/vscode-extension/local-directory-structure.md # The Local Directory Structure The CLARC VSCode Extension manages all development projects in a local directory structure and synchronizes these with the associated cloud tenant. The structure also serves as the starting point for managing projects via a Git repository. ## 1. Directory Structure - `//node_modules` — Contains all Node.js modules and dependencies installed via _npm install_. `/src///` - Local management of source code divided by cluster, tenant and system class. - `/Libraries` — Cross-project libraries `/Projects` - Development projects with corresponding sources ## 2. Standard Files - `client.ts` — The main client file of the extension and simultaneously the starting point for compilation. `extension-config.json` - Contains information about configuration options and data such as the storage location of local projects and libraries. `package.json` - Contains metadata and dependencies. `package-lock.json` - Contains the exact version information of the installed Node modules. `tsconfig.json` - Configuration file for the TypeScript compiler. `webpack.config.json` - Configuration file for Webpack, responsible for packaging the TypeScript project. --- # Business Object Properties in Scripting Source: https://clarc.com/docs/en/scripting/business-object-properties.md # Accessing Complex Properties (Business Object Properties in Scripting) Nested elements or complex properties are properties that can themselves contain further subordinate properties. To access a child element of a complex property, a path is formed from the technical names of all parent properties. This path consists of the technical names of the properties separated by a slash ("/"). ## 1. Example - ParentProperty (Complex) → ChildProperty (Complex) → LeafProperty (Primitive) Access to LeafProperty is done with the following path: `ParentProperty/ChildProperty/LeafProperty` Collection properties (e.g. tables) work similarly to complex properties but can contain multiple elements (items). Access to child elements is also done by specifying the path and the row index. --- # Client Scripting Source: https://clarc.com/docs/en/scripting/client-scripting/index.md # Client Scripting in CLARC Infinity **Client scripting** is a central extension component of the CLARC Infinity Platform and enables the **creation of dynamic, custom behaviors** directly in the application's client. Based on **TypeScript**, it offers a modern, structured and scalable way to **customize user interfaces, validation logic and processes** — without modifications to the server code. Client scripts are managed within so-called **scripting projects**, which are closely linked to business objects and their user interfaces (desktops). --- ## 1. Use Cases and Capabilities Client scripting is used wherever **interactive logic should react to user inputs or UI events**. Typical use cases are: - **Real-time validation of inputs** and context-dependent display of fields - **Event-based reactions** to user actions such as clicks, input focus or leaving a form - Access to **configurations and resources** via the associated resource package - **Data connectivity** to cloud or on-premises systems via the Cloud Connector - **Reusable libraries** and modularization via cross-project libraries --- ## 2. The Role of TypeScript **TypeScript** is used as the scripting language — an extension of JavaScript with static typing. TypeScript is fully compatible with JavaScript but offers: | Advantage | Description | | --- | --- | | **Static typing** | Errors are detected at development time | | **Intelligent development tools** | Auto-completion, linting, refactoring support | | **Structured code** | Clear object definitions, modular structure | | **Scalability** | Optimal for large projects with many dependencies | | **JavaScript compatibility** | Integration of existing JS logic or libraries is straightforward | --- ## 3. Structure of a Client Script Project A scripting project consists of: - Multiple `.ts` files (TypeScript) - An optional **resource package** (key-value configurations) - Optional **imports from system libraries** - An **entry point with** `default export` The export must follow this structure: ``` { OnExport: function () { console.log("Hello World!"); }, Fields: {}, } as TccScripting.scriptResult; ``` :::note The type definition `TccScripting.scriptResult` is used for validating the project structure. ::: --- ## 4. Desktop Integration and Execution To activate a client script, it is assigned to a **business object desktop**. When this desktop is opened, the associated **scripting package** is automatically loaded and executed in the user's browser. The behavior is **event-driven** — the code is executed **not continuously** but **reactively** at defined events. --- ## 5. Event System – Global and Field-Specific ### Global Events These affect the entire desktop, e.g.: - `OnStart` (when the application starts) - `OnUserexit` (before leaving) These are defined under the `OnExport` attribute in the exported object. ### Field-Specific Events The input fields of the business object (properties) are mapped as a tree structure via the `Fields` property. Events can be defined per field, e.g.: - `OnEnter` (field receives focus) - `OnChanged` (input is changed) Nested properties (complex properties) are also represented as a hierarchical tree. --- ## 6. Asynchronous Events and Processing Control Some events are **asynchronous** — they return an `Observable`: - The application **waits for the result** - `true` → Operation continues - `false` → Execution is cancelled This enables, for example, security checks or server queries before saving. --- ## 7. Access to Application Objects Several global objects are available for interacting with the user interface: | Object | Purpose | | --- | --- | | `ccFields` | Access to field values, display properties, etc. | | `ccTable` | Table operations (e.g. adding rows) | | `ccApplication` | Status information, current events, field context | | `ccScriptEngine` | Runtime functions, package control | | `ccRootField` | Access to property tree as object structure | | `ccFactory` | Creation of new fields, services, contexts | These objects can also be imported modularly or passed as parameters to custom functions. --- ## 8. Project Structure, Modularization and Deployment - Scripts are structured in **projects** — with any number of files - Common functions can be outsourced to **libraries** and used system-wide - During deployment, the TypeScript code is **packaged** (compiled, bundled) and **stored as a JavaScript package in the system** - The package is active at runtime and is only loaded during desktop use --- ## 9. Business Objects and Properties A business object describes a **document type**, e.g. invoice or order. It contains a structured set of **properties** represented in the UI by fields. The logical nesting (e.g. positions, addresses) forms a **tree** through which client scripts can access individual fields or groups precisely. --- ## 10. Conclusion Client scripting in CLARC Infinity is a **powerful and modern extension concept** for individualizing the user interface and mapping dynamic logic in the frontend. With **TypeScript** as the foundation, a sophisticated event system, deep UI access and the ability to modularize, it supports demanding requirements in agile and scalable ECM projects — both on-premises and in the cloud. --- # ccApplication Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/index.md # Overview The `ccApplication` class in CLARC Infinity Platform client scripting is the central entry point for accessing the **currently running application** — such as a capture or validation form. It enables **context-dependent influence on the behavior of the entire application**, for example in event handlers, UI control or validation logic. Via `ccApplication`, various **system and runtime information** is available that can be queried or influenced in scripts. These include, for example, the language of the interface, the current version, the active input field or control switches for process control (e.g. error release). --- # ccApplication Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/index.md # ccApplication Properties --- # ccApplication.AllowErrorRelease Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-allowerrorrelease.md # ccApplication.AllowErrorRelease ## Property `ccApplication.AllowErrorRelease : boolean` ## Description The AllowErrorRelease property allows lifting a previously defined release block within the field event EventOnRelease. This enables the event to be triggered even in the presence of errors or restrictions. ## Example ``` let User = ccFields.GetValue("h_sinfo_user").toString(); if(User.toLowerCase() == "admin") ccApplication.AllowErrorRelease = true; else ccApplication.AllowErrorRelease = false; ``` --- # ccApplication.AllowExecuteUserexit Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-allowexecuteuserexit.md # ccApplication.AllowExecuteUserexit ## Property `ccApplication.AllowExecuteUserexit : boolean` ## Description With the AllowExecuteUserexit property, the execution of user exits can be flexibly controlled in the field event EventOnUserexit. For example, this can prevent execution when certain field contents are present. ## Example ``` OnUserExit: function(){ let BUKRS = ccFields.GetValue("h_companycode"); if(BUKRS == "") ccApplication.AllowExecuteUserExit = false; else ccApplication.AllowExecuteUserExit = true; } ``` --- # ccApplication.CurrentField Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-currentfield.md # ccApplication.CurrentField ## Property `ccApplication.CurrentField : TccField` ## Description CurrentField is the field object representing the currently active field. ## Example ``` if(ccApplication.CurrentField.Value == "RM"){ if(ccFields.GetValue("h_ordernumber").length == 0) ccFields.SetState("h_ordernumber", "ccFS_Error", "Order number required for this document type"); } ``` --- # ccApplication.Id Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-id.md # ccApplication.Id ## Property `ccApplication.Id : string` ## Description The Id property returns the current application ID. ## Example ``` ccFields.SetValue("h_sinfo_note", ccApplication.Id) ``` --- # ccApplication.Language Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-language.md # ccApplication.Language ## Property `ccApplication.Language : string` ## Description The Language property returns the current login language of the system as an ISO-639-ALPHA-3 code. For example "DEU" ## Example ``` switch(ccApplication.Language){ "ENG": ccFields.SetState("h_salestaxid", "ccFS_WARNING", "Please verify the tax number!");break; "DEU": ccFields.SetState("h_salestaxid", "ccFS_WARNING", "Bitte die Steuernummer prüfen!"); } ``` --- # ccApplication.Name Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-name.md # ccApplication.Name ## Property `ccApplication.Name : string` ## Description The Name property returns the name of the currently used application. ## Example ``` OnLoad: function(){ if(ccApplication.Name.endsWith("2000") == true) ccApplication.AllowErrorRelease = true; } ``` --- # ccApplication.Version Source: https://clarc.com/docs/en/scripting/client-scripting/ccapplication/ccapplication-properties/ccapplication-version.md # ccApplication.Version ## Property `ccApplication.Version : string` ## Description The Version property returns the current file version of the client. ## Example ``` const Version = ccApplication.Version; let VersionArray = Version.split("."); if(VersionArray[0] <= 1) return; ``` --- # ccFactory Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/index.md # Overview The `ccFactory` class serves in the scripting context of the CLARC Infinity Platform as the **central factory and management class for data-driven queries**. It provides an abstracted, uniform interface through which developers can create objects for **communication with databases and external data sources** — regardless of whether these are connected locally or remotely. In the background, `ccFactory` functions as a **base component for specialized query classes** such as: - `TccRemoteQueryDatabase` — for structured database queries - `TccRemoteQueryRepository` — for searches in document-based repositories - `TccDatabaseQueryResponse` — for processing query results --- ## 1. Functions and Scope The main task of `ccFactory` is to encapsulate and standardize the **creation, management and initialization of query objects**. This ensures that all accesses to external data sources follow a **consistent, maintainable and extensible principle**. An example of this is the method `CreateRepositoryRemoteQuery`, which enables defining, configuring and executing a remote query against a connected repository — without requiring manual initialization steps. --- ## 2. Advantages - ✅ **Abstraction** of object initialization for complex data accesses - 🔄 **Reusability** through central interface for all data sources - 🔐 **Security and control** through controlled access via the scripting framework - 🧩 **Extensibility** through clear separation of factory and query objects --- ## 3. Typical Use Cases - Dynamic data queries on SQL or NoSQL databases - Retrieval of document metadata from connected repositories - Integrations with external backend systems via remote query objects --- The `ccFactory` is thus a **key element for data-driven client scripting** in CLARC Infinity. It enables structured addressing of external data sources and dynamic integration of their contents into the user interface or process logic — with minimal technical effort and maximum reusability. --- # Factory Methods Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/factory-methods/index.md # Factory Methods --- # ccFactory.CreateDatabaseRemoteQuery Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/factory-methods/ccfactory-createdatabaseremotequery.md # ccFactory.CreateDatabaseRemoteQuery ## Method `ccFactory.CreateDatabaseRemoteQuery(SourceId : string, Query : string, QueryFields : {[FieldName : string]} : any):TccRemoteQueryDatabase` ## Description The method returns a class object with which database queries can be performed. ## Example ``` const RQ = ccFactory.CreateDatabaseRemoteQuery("lwyRzgyLEe-vV0qTCulcew","SELECT CustomerID FROM Customers"); ``` --- # ccFactory.CreateRepositoryRemoteQuery Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/factory-methods/ccfactory-createrepositoryremotequery.md # ccFactory.CreateRepositoryRemoteQuery ## Method `ccFactory.CreateRepositoryRemoteQuery(SourceId :string,Query :string) : TccRemoteQueryRepository` ## Description A class object is returned with which database queries can be performed. ## Example ``` const repo = ccFactory.CreateRepositoryRemoteQuery("90qvOJ5K1kqYsIL0FbR57w",`(City eq 'Berlin')`); ``` --- # TccRemoteQueryDatabase Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/index.md # Introduction This class provides methods and properties for interacting directly with a remote database. It enables sending queries and receiving results. Typical functions: - Establishing a connection to a remote database - Executing SQL or other query languages - Managing session information Use case: Used when direct communication with a specific database is required. --- # TccRemoteQueryDatabase Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-properties/index.md # TccRemoteQueryDatabase Properties --- # TccRemoteQueryDatabase.Query Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-properties/tccremotequerydatabase-query.md # TccRemoteQueryDatabase.Query ## Property `TccRemoteQueryDatabase.Query : string` ## Description The search command to be executed in the database. ## Example ``` const RQ = ccFactory.CreateDatabaseRemoteQuery("lwyRzgyLEe-vV0qTCulcew","Select * From Customers"); RQ.Reset(); RQ.Query = "Select * From Orders"; ``` --- # TccRemoteQueryDatabase.Response Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-properties/tccremotequerydatabase-response.md # TccRemoteQueryDatabase.Response ## Property `TccRemoteQueryDatabase.Response : TccDatabaseQueryResponse` ## Description The query result is provided here. The structure can be viewed in the [TccDatabaseQueryResponse class](../../tccdatabasequeryresponse-klasse). ## Example ``` const RQ = ccFactory.CreateDatabaseRemoteQuery("lwyRzgyLEe-vV0qTCulcew","SELECT * FROM Orders" ); RQ.ExecAsync().subscribe((result)=>{ if(result){ const RowCount = RQ.Response.Rows.length; const ColumnNameArray = RQ.Response.Columns; } } ``` --- # TccRemoteQueryDatabase.SourceId Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-properties/tccremotequerydatabase-sourceid.md # TccRemoteQueryDatabase.SourceId ## Property `TccRemoteQueryDatabase.SourceId : string` ## Description The ID of the database profile that must be created in the Infinity application. ## Example ``` const db = ccFactory.CreateDatabaseRemoteQuery("ZuF-mV7_wk6sLIRYrYawXQ",`"SELECT * FROM Customers Where City = :Feldname"`,{"Feldname": "Berlin"}); db.ExecAsync().pipe(mergeMap(success=>{ if(success){ db.Reset(); db.SourceId = "lwyRzgyLEe-vV0qTCulcew"; db.Query = `"SELECT * FROM Inventory Where Customer = :Customer"`; db.QueryFields = {"Customer":db.Response.Rows[0]["Id"]}; return db.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = db.Response.Rows.length; if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) ``` --- # TccRemoteQueryDatabase.QueryFields Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-properties/tccremotequerydatabase-queryfields.md # TccRemoteQueryDatabase.QueryFields ## Property `TccRemoteQueryDatabase.QueryFields : {[FieldName: string] : any}` ## Description QueryFields defines the fields linked in the query and passes the corresponding values. ## Example ``` ResetDb: { OnSelect: () => { const db = ccFactory.CreateDatabaseRemoteQuery("ZuF-mV7_wk6sLIRYrYawXQ",`"SELECT * FROM Customers Where City = :Feldname"`,{"Feldname": "Berlin"}); db.ExecAsync().pipe(mergeMap(success=>{ if(success){ db.Reset(); db.SourceId = "lwyRzgyLEe-vV0qTCulcew"; db.Query = `"SELECT * FROM Inventory Where Customer = :Customer"`; db.QueryFields = {"Customer":db.Response.Rows[0]["Id"]}; return db.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = db.Response.Rows.length; console.log(db.Response.Columns); if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) } }, ``` --- # TccRemoteQueryDatabase Methods Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-methods/index.md # TccRemoteQueryDatabase Methods --- # TccRemoteQueryDatabase.ExecAsync Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-methods/tccremotequerydatabase-execasync.md # TccRemoteQueryDatabase.ExecAsync ## Method `TccRemoteQueryDatabase.ExecAsync() : Observable` ## Description This method returns the [Observable](https://rxjs.dev/guide/observable) used for the asynchronous query. An Observable is a reactive programming concept that manages data streams. Observables enable efficient combination, transformation, and reaction to data streams. The RxJS implementation of this concept is used here. ## Example ``` const RQ = ccFactory.CreateDatabaseRemoteQuery( "lwyRzgyLEe-vV0qTCulcew", "SELECT COUNT(IBAN) AS IBAN FROM Customers where IBAN = :IBAN", {"IBAN" : ccFields.GetValue("h_creditoriban")} ); RQ.ExecAsync().subscribe((result)=>{ if(result){ const row = RQ.Response.Rows[0]; const IBANCount = row["IBAN"]; if(IBANCount > 0) ccFields.SetState("h_creditoriban", "ccFS_Okay"); else ccFields.SetState("h_creditoriban", "ccFS_Error", "IBAN not found in master data"); } } ``` --- # TccRemoteQueryDatabase.Reset Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequerydatabase/tccremotequerydatabase-methods/tccremotequerydatabase-reset.md # TccRemoteQueryDatabase.Reset ## Method `TccRemoteQueryDatabase.Reset() : void` ## Description The method resets the instance, i.e., the SourceId and Query are cleared. A new query can then be started with the instance. However, the SourceId and Query must be set again beforehand. Alternatively, CreateDatabaseRemoteQuery can simply be called again. ## Example ``` const RQ = ccFactory.CreateDatabaseRemoteQuery("lwyRzgyLEe-vV0qTCulcew","SELECT * FROM Orders" ); RQ.Reset(); RQ.SourceId = "GHCjrA0BEe-NxIo6m1CQ0A"; RQ.Query = "Select * From Customers"; ``` --- # TccRemoteQueryRepository Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/index.md # TccRemoteQueryRepository Class This class serves as a higher level of abstraction to organize and reuse queries efficiently. It provides a structured collection of queries that can be used for multiple operations. Typical functions: - Management of predefined database queries. - Simplification of reusability and modularity. - Abstraction from direct interaction with the database. Use case: Ideal for scenarios where multiple similar queries need to be organized or frequently repeated. --- # TccRemoteQueryRepository Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-properties/index.md # TccRemoteQueryRepository Properties --- # TccRemoteQueryRepository.Query Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-properties/tccremotequeryrepository-query.md # TccRemoteQueryRepository.Query ## Property `TccRemoteQueryRepository.Query : string` ## Description The OData filter string is added to the query to search the result set in a targeted manner. It enables the definition of criteria by which the data should be filtered. ## Example ``` const repo = ccFactory.CreateRepositoryRemoteQuery("90qvOJ5K1kqYsIL0FbR57w",`(City eq 'Berlin')`); repo.ExecAsync().pipe(mergeMap(success=>{ if(success){ repo.Reset(); repo.SourceId = "L1SCCmEC8ky-Gno5NiD6bA"; repo.Query = `(Customer eq '${repo.Response.Rows[0]["Id"]}')`; return repo.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = repo.Response.Rows.length; console.log(repo.Response.Columns); if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) ``` --- # TccRemoteQueryRepository.Response Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-properties/tccremotequeryrepository-response.md # TccRemoteQueryRepository.Response ## Property `Response : TccDatabaseQueryResponse` ## Description The query result is provided here. The structure of the result is defined and viewable in the [TccDatabaseQueryResponse class](../../tccdatabasequeryresponse-klasse). ## Example ``` ResetRepo: { OnSelect: () => { const repo = ccFactory.CreateRepositoryRemoteQuery("90qvOJ5K1kqYsIL0FbR57w",`(City eq 'Berlin')`); repo.ExecAsync().pipe(mergeMap(success=>{ if(success){ repo.Reset(); repo.SourceId = "L1SCCmEC8ky-Gno5NiD6bA"; repo.Query = `(Customer eq '${repo.Response.Rows[0]["Id"]}')`; return repo.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = repo.Response.Rows.length; console.log(repo.Response.Columns); if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) } }, ``` --- # TccRemoteQueryRepository.SourceId Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-properties/tccremotequeryrepository-sourceid.md # TccRemoteQueryRepository.SourceId ## Property `TccRemoteQueryRepository.SourceId` ## Description SourceId contains the ID of the repository to be queried. The query returns the items of the specified repository. The repository must have been created beforehand in the Infinity application. ## Example ``` const repo = ccFactory.CreateRepositoryRemoteQuery("90qvOJ5K1kqYsIL0FbR57w",`(City eq 'Berlin')`); repo.ExecAsync().pipe(mergeMap(success=>{ if(success){ repo.Reset(); repo.SourceId = "L1SCCmEC8ky-Gno5NiD6bA"; repo.Query = `(Customer eq '${repo.Response.Rows[0]["Id"]}')`; return repo.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = repo.Response.Rows.length; if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) ``` --- # TccRemoteQueryRepository Methods Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-methods/index.md # TccRemoteQueryRepository Methods --- # TccRemoteQueryRepository.ExecAsync Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-methods/tccremotequeryrepository-execasync.md # TccRemoteQueryRepository.ExecAsync ## Method `TccRemoteQueryRepository.ExecAsync() : Observable` ## Description This method returns the [Observable](https://rxjs.dev/guide/observable) used for the asynchronous query. An Observable is a reactive programming concept that manages data streams. Observables enable efficient combination, transformation, and reaction to data streams. They are frequently integrated into asynchronous frameworks such as RxJS. ## Example ``` ResetRepo: { OnSelect: () => { const repo = ccFactory.CreateRepositoryRemoteQuery("90qvOJ5K1kqYsIL0FbR57w",`(City eq 'Berlin')`); repo.ExecAsync().pipe(mergeMap(success=>{ if(success){ repo.Reset(); repo.SourceId = "L1SCCmEC8ky-Gno5NiD6bA"; repo.Query = `(Customer eq '${repo.Response.Rows[0]["Id"]}')`; return repo.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = repo.Response.Rows.length; console.log(repo.Response.Columns); if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) } ``` --- # TccRemoteQueryRepository.Reset Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccremotequeryrepository/tccremotequeryrepository-methods/tccremotequeryrepository-reset.md # TccRemoteQueryRepository.Reset ## Method `TccRemoteQueryRepository.Reset()` ## Description The method clears the SourceId and Query from the instance. This allows a new request to be sent. ## Example ``` ResetRepo: { OnSelect: () => { const repo = ccFactory.CreateRepositoryRemoteQuery("90qvOJ5K1kqYsIL0FbR57w",`(City eq 'Berlin')`); repo.ExecAsync().pipe(mergeMap(success=>{ if(success){ repo.Reset(); repo.SourceId = "L1SCCmEC8ky-Gno5NiD6bA"; repo.Query = `(Customer eq '${repo.Response.Rows[0]["Id"]}')`; return repo.ExecAsync(); } return of(false); })).subscribe(success=>{ if(success) { const rowcount = repo.Response.Rows.length; console.log(repo.Response.Columns); if(rowcount > 0) ccFields.SetState("h_inventory", "ccFS_Okay"); else ccFields.SetState("h_inventory", "ccFS_Error", "No inventory found"); } }) ``` --- # TccDatabaseQueryResponse Class Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccdatabasequeryresponse-class/index.md # Introduction This class encapsulates the results of a database query. It enables access to the data. **Typical functions:** - Storage and processing of query results. - Provision of methods for analyzing and iterating over the results. Use case: Used to return the results of a query logically and structurally to the application. --- # TccDatabaseQueryResponse Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccdatabasequeryresponse-class/tccdatabasequeryresponse-properties/index.md # TccDatabaseQueryResponse Properties --- # TccDatabaseQueryResponse.Columns Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccdatabasequeryresponse-class/tccdatabasequeryresponse-properties/tccdatabasequeryresponse-columns.md # TccDatabaseQueryResponse.Columns ## Property `TccDatabaseQueryResponse.Columns:string[]` ## Description The Columns property returns the column names of the query result as an array. The column names can be used to access the column contents in the Rows. ## Example ``` RQ.ExecAsync().subscribe((result)=>{ if(result){ for (let i = 0; i < RQ.Response.Columns; i++) { const columnName = RQ.Response.Columns[i]; for (let j = 0; j < RQ.Response.Rows.length; j++) { const row = RQ.Response.Rows[j]; console.log(`Column ${columnName} in Row ${j} has value: ${row[columnName]}`) } } } } ``` --- # TccDatabaseQueryResponse.Rows Source: https://clarc.com/docs/en/scripting/client-scripting/ccfactory/tccdatabasequeryresponse-class/tccdatabasequeryresponse-properties/tccdatabasequeryresponse-rows.md # TccDatabaseQueryResponse.Rows ## Property `TccDatabaseQueryResponse.Rows : {[fieldName:string] : any}[]` ## Description The Rows property returns the rows of the query result as a list. ## Example ``` RQ.ExecAsync().subscribe((result)=>{ if(result){ const row = RQ.Response.Rows[0]; } } ``` --- # ccFields Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/index.md # ccFields Class The `ccFields` class is a central component in CLARC Infinity Platform client scripting and enables **programmatic access to all data fields of the current application**. These fields are based on the **business object** assigned to the desktop and reflect its structured **property hierarchy**. Via `ccFields`, **field values can be read, set, validated and analyzed**, enabling targeted control of user interaction and process logic directly in the frontend. Fields are typically addressed via their **complete property path**, as derived from the business object structure — including complex and nested properties. --- ## 1. Main Functions of ccFields ### 1.1 Access to Data Fields - Enables **reading and setting of field values** at runtime. - Supports both **simple data types** (e.g. string, number, date) and **complex and nested types**. - Typical for validations, dynamic calculations or pre-populating fields. ### 1.2 Enumeration and Navigation - All defined fields of the business object can be **iterated** via `ccFields`. - Particularly useful for **collection properties** to traverse fields position by position in tables. - Enables structured analysis, such as checking mandatory fields or visibilities. ### 1.3 Metadata Access - In addition to the actual values, `ccFields` provides extensive information about each field: data type - Maximum permitted length - Write-protection status - Mandatory field definition - Visibility This metadata can be used for dynamic control of the user interface or for validation. --- ## 2. Usage Examples - Automatically clearing specific fields when a selection is changed - Checking whether all mandatory fields in a substructure have been filled - Searching position data for specific criteria - Controlling field visibility or editability depending on context --- The `ccFields` class is thus a **central tool for runtime control of the UI**. It provides a consistent and powerful model for accessing all fields of a business object in a **structured, typed and context-sensitive** way. In combination with other objects such as `ccApplication`, `ccRootField` or `ccScriptEngine`, flexible and controlled user interaction can be realized — directly in the browser and fully controllable via TypeScript. --- # ccFields Methods Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/index.md # ccFields Methods --- # ccFields.AddSelectionList Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-addselectionlist.md # ccFields.AddSelectionList ## Method `ccFields.AddToSelectionList(field : string,value : string) : boolean` ## Description The AddToSelectionList method enables adding a new entry to the selection list of a specified field. The Field parameter can be either the ID or the technical name of the field. Note that the specified field must be of type "Combobox". ## Example ``` OnLoad:function(){ ccFields.AddToSelectionList("h_companycode", "1000"); ccFields.AddToSelectionList("h_companycode", "2000"); ccFields.AddToSelectionList("h_companycode", "3000"); } ``` --- # ccFields.AddToSelectionListExt Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-addtoselectionlistext.md # ccFields.AddToSelectionListExt ## Method `ccFields.AddToSelectionListExt(field : string,value : string,meaning : string) : boolean` ## Description AddToSelectionListExt inserts a new list entry with an internal meaning into the selection list of the specified field. Field is either the ID or the technical name of the field. Note that the specified field must be of type "Combobox". ## Example ``` OnLoad:function(){ ccFields.AddToSelectionListExt("h_documenttype", "Invoice (MM)", "RM"); ccFields.AddToSelectionListExt("h_documenttype", "Invoice (FI)", "RO"); ccFields.AddToSelectionListExt("h_documenttype", "Credit Note (MM)", "GM"); ccFields.AddToSelectionListExt("h_documenttype", "Credit Note (FI)", "GO"); } ``` --- # ccFields.ClearSelectionList Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-clearselectionlist.md # ccFields.ClearSelectionList ## Method `ccFields.ClearSelectionList(field : string) : boolean` ## Description The ClearSelectionList method removes all entries from the selection list of the specified field. The Field parameter can be either the ID or the technical name of the field. Note that the specified field must be of type "Combobox". ## Example ``` if(ccResources.Get("DynamicDatabaseQuery", false) == true){ ccFields.ClearSelectionList("h_companycode"); //Fetch data from database } ``` --- # ccFields.Exists Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-exists.md # ccFields.Exists ## Method `ccFields.Exists(field : string) : boolean` ## Description The Exists function checks whether the specified field exists in the schema. It returns true if the field exists, and false if it does not. The Field parameter can be either the ID or the technical name of the field. ## Example ``` if(ccFields.Exists("h_taxbasisamount1")){ let TaxRate1 = ccFields.GetValue("h_taxrate1"); let TaxbasisAmount1 = ccFields.GetValue("h_taxbasisamount1"); let TaxAmount1 = (TaxRate1 / 100) * TaxbasisAmount1; ccFields.SetValue("taxamount1", TAxAmount1); } ``` --- # ccFields.GetDisplayText Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-getdisplaytext.md # ccFields.GetDisplayText ## Method `ccFields.GetDisplayText(field : string) : string` ## Description The GetDisplayText method returns the display text of the field specified by the Field parameter, in the currently used login language. The Field parameter can be either the ID or the technical name of the field. ## Example ``` if(ccFields.GetDisplayText("h_barcode") == "Barcode"){ ccFields.SetProperties("h_barcode", true, true); } ``` --- # ccFields.GetName Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-getname.md # ccFields.GetName ## Function Call `ccFields.GetName(fieldIndex : number) : string` ## Description The GetName method returns the technical name of the field specified by the FieldIndex parameter. If FieldIndex is outside the valid range, an empty value is returned. ## Example ``` const Fieldname = ccFields.GetName(1); ccFields.SetValue(FieldName, ccFields.GetValue(FieldName).toString().toLowerCase()); ``` --- # ccFields.GetPropertyValue Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-getpropertyvalue.md # ccFields.GetPropertyValue ## Method `ccFields.GetPropertyValue(field : string,property :"name"|"enabled"|"visible"|"mandatory") : any` ## Description The GetPropertyValue method returns the value of the specified Property of the field Fields. The Field parameter can be either the ID or the technical name of the field. ## Example ``` let allowErrorRelease = ccFields.GetPropertyValue("h_barcode", "mandatory"); if(allowErrorRelease) ccApplication.AllowErrorRelease = true; else ccApplication.AllowErrorRelease = false; ``` --- # ccFields.GetRawValue Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-getrawvalue.md # ccFields.GetRawValue ## Method `ccFields.GetRawValue(field : string) : string` ## Description The GetRawValue method returns the raw content of the field specified by the Field parameter as a WideString. The Field parameter can be either the ID or the technical name of the field. ## Example ``` GetTaxCount(): int{ let count = 0; if(ccFields.GetRawValue("h_taxrate1").length > 0) count++; if(ccFields.GetRawValue("h_taxrate2").length > 0) count++; if(ccFields.GetRawValue("h_taxrate3").length > 0) count++; return count; } ``` --- # ccFields.GetSelectionList Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-getselectionlist.md # ccFields.GetSelectionList ## Method `ccFields.GetSelectionList(field : string, getDisplayText : boolean, getFromUI : boolean) : TccKeyValuePair[]` ## Description The GetSelectionList method returns the selection list for the specified field. The Field parameter can specify either the ID or the technical name of the field. To get the display text or the corresponding meaning of the list entries in the current language, use the GetDisplayText method. If GetFromUI is set to true, the values are taken directly from the user interface. Note that the specified field must be of type "Combobox". ## Example ``` const Array = ccFields.GetSelectionList("Belegart", false, true); let Text = ""; for(let i = 0; i < Array.length; i++){ Text += Array[i].Key + " : " + Array[i].Value + "\n"; } ccFields.SetValue("h_sinfo_note", Text); ``` --- # ccFields.SetDisplayText Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-setdisplaytext.md # ccFields.SetDisplayText ## Method `ccFields.SetDisplayText(field : string,text : string) : boolean` ## Description The SetDisplayText method sets the display text of the field specified by the Field parameter. ## Example ``` ccFields.SetDisplayText("h_barcode", "Barcode"); ``` --- # ccFields.SetProperties Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-setproperties.md # ccFields.SetProperties ## Method `ccFields.SetProperties(field : string,enabled : boolean,visible : boolean) : boolean` ## Description The SetProperties method allows setting the Enabled and Visible properties for the specified field. The Field parameter can be either the ID or the technical name of the field. ## Example ``` if(ccFields.GetValue("h_grossamount") > 10000) ccFields.SetProperties("h_emailforapproval", true, true); ``` --- # ccFields.SetValue Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-setvalue.md # ccFields.SetValue ## Method `ccFields.SetValue(field : string,value : TccPrimitiveValue) : boolean` ## Description The SetValue method sets the content of the specified field. The Field parameter can be either the ID or the technical name of the field. The passed value must match the corresponding data type of the target field. Otherwise, an automatic type conversion will be attempted. ## Example ``` ccFields.SetValue("h_creditorid", "1234567890"); ``` --- # ccFields.GetValue Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-methods/ccfields-getvalue.md # ccFields.GetValue ## Method `ccFields.GetValue(field : string) : TccPrimitiveValue` ## Description The GetValue method returns the content of the field specified by the Field parameter. This parameter can be either the ID or the technical name of the field. The result is returned in the corresponding data type of the field, such as Date, Float, Integer, Boolean, or String. ## Example ``` OnExport: function () { if(ccFields.GetValue('h_mark_release') == true && ccFields.GetValue('h_sinfo_release').length > 0) { ccApplication.AllowErrorRelease = true; } else { ccApplication.AllowErrorRelease = false; } } ``` --- # ccFields Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-properties/index.md # ccFields Properties --- # ccFields.Focused Source: https://clarc.com/docs/en/scripting/client-scripting/ccfields/ccfields-properties/ccfields-focused.md # ccFields.Focused ## Property `ccFields.Focused : string` ## Description The property returns the technical name of the currently active field, or sets the focus to the specified field, depending on the usage context. ## Example ``` OnExit:function(){ if(ccFields.Focused == "h_taxrate1"){ let TaxRate = ccFields.GetValue("h_taxrate1"); let NetAmount = ccFields.GetValue("h_netamount1"); ccFields.SetValue("h_taxamount1", NetAmount * (1 + (Taxrate / 100))); } } ``` --- # ccResources Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/index.md # ccResources Class — Access to Configurable Resources in Scripting Projects The `ccResources` class provides in the scripting context of the CLARC Infinity Platform the interface for **accessing configurable resources** assigned to a script project in the **customizing area**. These resources typically consist of **key-value pairs** maintained in so-called **resource packages**. The goal of this functionality is to enable a **clear separation between code and configuration**. Scripts can thereby be **parameterized and adjusted without repackaging**. This allows UI texts, technical thresholds, control parameters or constants to be changed in customizing — without having to modify the TypeScript code itself. --- ## 1. Use Cases - Configurable validation rules without modifying the code - Language- or tenant-specific texts - Control parameters such as switches, thresholds, toggle logic - Reusable constants for processes or fields --- ## 2. Example ``` if (ccResources.Exists("ValidationMode")) { const mode = ccResources.Get("ValidationMode"); if (mode === "Strict") { // Tighten validation } } ``` --- With `ccResources`, scripting projects in the CLARC Infinity Platform can be designed in a **flexible, maintainable and configuration-based way**. The approach promotes a **clear separation of logic and parameterization**, reduces maintenance effort and allows **tenant-specific or environment-specific customizations** — without any changes to the source code. --- # ccResources Methods Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-methods/index.md # ccResources Methods --- # ccResources.Exists Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-methods/ccresources-exists.md # ccResources.Exists ## Method `ccResources.Exists(Name : string) : boolean` ## Description The Exists method checks whether a resource with the specified name exists, and returns true or false accordingly. ## Example ``` if(ccResources.Exists("ConnectionString") == true){ Const DBString = ccResources.Get("ConnectionString", ""); } ``` --- # ccResources.Get Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-methods/ccresources-get.md # ccResources.Get ## Method `ccResources.Get(Name : string, Default : any) : any` ## Description The GetResource method returns the content of the specified script resource. If the resource does not exist, the default value is used. ## Example ``` if(ccResources.Get("CheckDates", false) == true){ let DocumentDate = ccFields.GetValue("h_documentdate"); if(DocumentDate > new Date()) ccFields.SetState("h_documentdate", "ccFS_Error", "Date cannot be in the future"); } ``` --- # ccResources.Set Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-methods/ccresources-set.md # ccResources.Set ## Method `ccResources.Set(Name : string, Value : any) : boolean` ## Description The SetResource method stores the value of Value in the resource specified by Name. If the resource does not yet exist, it is created directly in the script as a local resource. ## Example ``` ccResources.Set("LastLogin", new Date()); ``` --- # ccResources Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-properties/index.md # ccResources Properties --- # ccResources.Name Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-properties/ccresources-name.md # ccResources.Name ## Property `ccResources.Name : string` ## Description The property returns the name of the assigned resource package. --- # ccResources.Id Source: https://clarc.com/docs/en/scripting/client-scripting/ccresources/ccresources-properties/ccresources-id.md # ccResources.Id ## Property `ccRessources.Id : string` ## Description The property returns the ID of the assigned resource package. --- # ccScript Source: https://clarc.com/docs/en/scripting/client-scripting/ccscript/index.md # ccScript Class — Information about the Currently Executing Script The `ccScript` class in CLARC Infinity Platform client scripting provides access to **meta-information about the currently running script project**. It serves primarily for **identification and analysis** during execution and provides simple properties to enable, for example, debugging or dynamic reactions to project information. --- # ccScript Properties Source: https://clarc.com/docs/en/scripting/client-scripting/ccscript/ccscript-properties/index.md # ccScript Properties --- # ccScript.ScriptInfo Source: https://clarc.com/docs/en/scripting/client-scripting/ccscript/ccscript-properties/ccscript-scriptinfo.md # ccScript.ScriptInfo ## Property `ccScript.ScriptInfo : string` ## Description The ScriptInfo property contains the description text defined in the script for the currently executing script. --- # ccScript.ScriptName Source: https://clarc.com/docs/en/scripting/client-scripting/ccscript/ccscript-properties/ccscript-scriptname.md # ccScript.ScriptName ## Property `ccScript.ScriptName : string` ## Description The ScriptName property returns the name of the currently executing script. ## Example ``` ccFields.SetValue("h_sinfo_memo", ccScript.ScriptName); ``` --- # Scripting Events Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/index.md # Scripting Events in the Desktop The **Scripting Events** area forms the central link between user interaction in the desktop and the underlying logic in client scripting. Events allow you to **intercept user-driven actions and influence them in a targeted way** — for example when opening a form, switching a field, or triggering a save operation. A fundamental distinction is made between **field-specific events** (which relate to specific input fields) and **global events** (which relate to the entire desktop or application context). Both event types allow you to **implement custom behavior**, perform validations, control UI dynamics, or trigger external processes. All events are processed in an **event-driven** manner and can be implemented synchronously or asynchronously — depending on the desired level of control over the subsequent flow. The event system is therefore an essential element for turning static forms into **interactive, context-driven user interfaces**. --- # Field-Specific Scripting Events Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/index.md # Field-Specific Scripting Events --- # EventOnDropDown Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/eventondropdown.md # EventOnDropDown ## Description This event is triggered when a selection list (combobox) is opened. Only the event of the corresponding field is triggered. This allows the available entries to be provided accordingly. ## Example ``` OnDropDown: function(){ let country = ccFields.GetValue("h_shippingcountry"); const arr = getStatesFor(country); ccFields.ClearSelectionList("h_province"); for(let i = 0; i < arr.length; i++) ccFields.AddToSelectionList("h_province", arr[i]); } ``` --- # EventOnEnter Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/eventonenter.md # EventOnEnter ## Description This event is triggered when entering an index field. Only the event of the corresponding field is triggered. ## Example ``` OnEnter: function(){ let invoicenumber = ccFields.GetValue("h_invoicenumber"); ccFields.SetValue("h_invoicenumber", invoicenumber.toString().trim()); } ``` --- # EventOnUserexit Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/eventonuserexit.md # EventOnUserexit ## Description This event is triggered when a user exit is called from the index field. To prevent the user exit from being executed, an exception can be thrown (Raise). Only the event of the corresponding field is triggered. This event is asynchronous, meaning an Observable must be returned as the return value. ## Example ``` OnUserExit: function(){ if(ccFields.GetValue("h_search").toString().length == 0) ccApplication.AllowExecuteUserExit = false; } ``` --- # EventOnConfirm Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/eventonconfirm.md # EventOnConfirm ## Description This event is triggered after confirming an index field with "Enter". Only the event of the corresponding field is triggered. ## Example ``` OnConfirm: function(){ let searchValue = ccFields.GetValue("h_search").toString().trim(); if(searchValue.length == 0) ccApplication.AllowExecuteUserexit = false; else ccApplication.AllowExecuteUserexit = true; } ``` --- # EventOnExit Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/eventonexit.md # EventOnExit ## Description This event is triggered when leaving an index field. Only the event of the corresponding field is triggered. ## Example ``` OnExit: function(){ let Barcode = ccFields.GetValue("h_barcode").toString(); if(Barcode.length > 5 && Barcode.length < 17) ccFields.SetState("h_barcode", "ccFS_Error", "Barcode has an invalid length"); else ccFields.SetState("h_barcode", "ccFS_Okay", ""); } ``` --- # EventOnSelect Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/field-specific-scripting-events/eventonselect.md # EventOnSelect ## Description This event is triggered when an entry from a selection list is selected or a checkbox is clicked. Only the event of the corresponding field is triggered. ## Example ``` OnSelect: function(){ const DocType = ccFields.GetValue("h_documenttype"); if(DocType == "RM" || DocType == "GM"){ if(ccFields.GetValue("h_ordernumber").toString().length = 0) ccFields.SetState("h_ordernumber", "ccFS_Error", "Document type requires order reference"); else ccFields.SetState("h_ordernumber", "ccFS_Okay", ""); } } ``` --- # Global Scripting Events Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/global-scripting-events/index.md # Global Scripting Events --- # EventOnCheck Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/global-scripting-events/eventoncheck.md # EventOnCheck ## Description This event is triggered before the index form is validated. ## Example ``` OnCheck: function(){ if(ccFields.GetValue('Name').toString().length < 5 then ccFields.SetState("Name", "ccFS_Error", "The entered name is too short - at least 5 characters required."); else ccFields.SetState("Name", "ccFS_Okay", ""); } ``` --- # EventOnExport Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/global-scripting-events/eventonexport.md # EventOnExport ## Description This event is triggered once when a document or batch is exported. ## Example ``` OnExport: function(){ const Barcode = ccFields.GetValue("h_barcode"); const RQ = ccFactory.CreateDatabaseRemoteQuery( "lwyRzgyLEe-vV0qTCulcew", "INSERT INTO BARCODES VALUES(:Barcode)", {"Barcode" : Barcode} ); RQ.ExecAsync().subscribe((result)=>{ if(result) console.log("Record has been archived"); } ``` --- # EventOnStart Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/global-scripting-events/eventonstart.md # EventOnStart ## Description This event is triggered when the indexing form is started or initialized — for example after each newly created staple. ## Example ``` OnStart(){ console.log(ccScript.ScriptName); } ``` --- # EventOnRelease Source: https://clarc.com/docs/en/scripting/client-scripting/scripting-events/global-scripting-events/eventonrelease.md # EventOnRelease ## Description This event is asynchronous, meaning an Observable must be returned as the return value. ## Example ``` OnUserExit: function(){ let User = ccFields.GetValue("h_sinfo_user").toString(); if(User.toLowerCase() == "admin") ccApplication.AllowErrorRelease = true; else ccApplication.AllowErrorRelease = false; } ``` --- # Users Source: https://clarc.com/docs/en/users/index.md # User Documentation The user documentation supports you in your daily work with the **CLARC Infinity Platform**. It is aimed at all users — regardless of whether you are capturing, validating, reviewing documents or handling tasks from workflows. The goal is to explain the functions and processes of the application clearly, practically and concisely. You will learn how to work efficiently with **capture applications**, **document views**, **task lists**, **workflows** or **email confirmations**, and how to optimally support your work processes. The CLARC Infinity user interface is deliberately designed to be intuitive — this documentation complements the operation with **context-specific notes, instructions and background knowledge** so that you can always work confidently and purposefully with the system. --- # Automatic Confirmation Emails Source: https://clarc.com/docs/en/users/automatic-confirmation-email.md # Confirmation of Your Email ### What does the automatic notification mean and what happens to your document? --- ## Why did I receive this email? You sent an email to our system — for example with an **invoice**, an **offer** or another business-relevant document as an attachment. So that you can confirm that your message has been successfully received by us, you are receiving this **automatically generated confirmation email**. The notification indicates that: - Your email was successfully received - Processing of your document has started --- ## What happens to my document? After your email is received, the document it contains is fed into a **defined process** in our system. This process may vary depending on the type of document, typically proceeding in the following steps: 1. **Capturing and saving** the document 2. **Checking and classifying**, e.g. whether it is an invoice, order or other document 3. **Extracting relevant data**, e.g. invoice number, amount, sender 4. **Forwarding to the responsible system or team** for further processing Depending on the configuration and purpose, this workflow proceeds in a **fully automated or semi-automated** defined business process. --- ## Do I need to do anything? No — in general, **no further action is required**. The confirmation message serves exclusively for your **information and transparency**. If your document cannot be processed or queries arise, a contact person will get in touch with you. --- ## Data Protection Notes Your data is **used exclusively for the intended business purpose** and processed in accordance with applicable data protection regulations. No disclosure to third parties takes place. --- ## For Questions If you have questions about the processing of your document, please contact the contact address provided in the confirmation email or directly your contact person in the company. --- **Thank you for your submission!** Your document is now being processed. --- # Privacy Policy Source: https://clarc.com/docs/en/privacy-policy.md # CLARC Infinity – Privacy Policy This privacy policy describes how personal data is processed within the **CLARC Infinity Platform**, what responsibilities exist, and what rights data subjects have under the General Data Protection Regulation (GDPR). The policy applies to all users of the platform and to all modules, services and integrations within CLARC Infinity. ## 1. Controller and Scope The controller for processing personal data is the company that operates or licenses the CLARC Infinity Platform. CLARC Infinity is operated as: - **Cloud solution (SaaS)** - **Hybrid cloud solution** - **On-premises installation** The respective tenant is responsible under data protection law for the content and data processed. The platform operator acts — depending on the model — as a **processor** in accordance with Art. 28 GDPR. ## 2. Types of Data Processed CLARC Infinity processes only data necessary to fulfill the respective customer's business processes. This includes in particular: ### 2.1 Usage and Access Data - User accounts and roles - Login information (e.g. timestamps, technical metadata) - Log data on system actions ### 2.2 Content Data (Business Documents) - Invoices, orders, contracts, delivery notes, documents of all kinds - Extraction and validation data (metadata-based) - Classification information ### 2.3 Communication Data - Email addresses and sender information for dispatch or workflows - Logs for system notifications ### 2.4 System and Integration Data - Data for ERP, DMS or archive connections - Connection data to on-premises systems within the Cloud Connector **No data is processed for advertising purposes.** ## 3. Purpose of Processing Data processing serves exclusively the following purposes: - Provision of CLARC Infinity functions - Processing and management of business-relevant documents - Execution of automated workflows, extraction and classification - User management, role and permission checking - Error diagnosis and operational security - Fulfillment of statutory archiving and retention obligations (depending on customer system) No further use takes place. ## 4. Legal Bases (GDPR) The processing of personal data is based on the following legal grounds: - **Art. 6(1)(b) GDPR** – Processing for the performance of a contract - **Art. 6(1)(f) GDPR** – Legitimate interest (e.g. stability, security, logging) - **Art. 28 GDPR** – Processing on behalf (for cloud/hybrid operations) ## 5. Data Processing in the Cloud, Hybrid Cloud and On-Premises CLARC Infinity is operated exclusively in **data centers within the European Union**. This includes: - Microsoft Azure (EU regions) - Alternative European hyperscalers - Optionally self-hosted AI clusters - On-premises systems at the customer site ### Zero-Trust Architecture The platform implements modern security principles: - Strict tenant separation - Encryption of data in transit (TLS) and at rest - Role-based access controls (RBAC) - Audit-proof logging mechanisms - No internal access without explicit authorization ## 6. Disclosure and Transfer of Data Personal data is **not shared with third parties**, except: - When required for the provision of the service (e.g. email providers, archive systems) - When the customer explicitly requests this - When a legal obligation exists Transfer to non-EU countries does **not** take place. ## 7. Storage and Retention Periods The storage duration depends on the respective tenant context: - Documents may be archived for up to statutory periods (e.g. 10–11 years) - Technical logs are deleted after internal or customer-defined periods - User and system data is deleted when no longer required The tenant can define their own retention policies. ## 8. Rights of Data Subjects Users and data subjects have the following rights under GDPR: - **Access** (Art. 15) - **Rectification** (Art. 16) - **Erasure / Right to be forgotten** (Art. 17) - **Restriction of processing** (Art. 18) - **Data portability** (Art. 20) - **Objection** (Art. 21) Fulfillment occurs via the respective tenant, as they are responsible for the content. ## 9. Security & Data Protection Measures The platform uses state-of-the-art security procedures: - Tenant isolation at database and process level - Secure configurations for Cloud Connector and on-premises integrations - Automated security updates and patch-level management - Continuous logging of security-relevant events - AI models are operated exclusively on our own, GDPR-compliant systems ## 10. Contact For data protection inquiries, please contact the controller of the respective tenant or your company's data protection officer. For technical questions about the platform, CLARC Support is available. ## 11. Changes to This Privacy Policy This privacy policy may be updated as needed to reflect technical, legal or organizational changes. The current version is always available within the CLARC Infinity documentation. --- # Terms of Use Source: https://clarc.com/docs/en/terms-of-use.md # CLARC Infinity – Terms of Use These terms of use govern access to and use of the **CLARC Infinity Platform**, including all modules, services, integrations, interfaces and optional on-premises components. By accessing or using the platform, users and the tenant accept these terms of use in their currently applicable version. ## 1. Scope The following conditions apply to: - All user accounts and roles within a tenant - All cloud-based, hybrid or locally installed components - All modules such as ECM, BPM, BPI, Capture, Billing, Workflow, Document Hub, etc. - All services, APIs and connectors connected to the platform These Terms of Use apply between the **platform provider** and the respective **tenant** that uses or makes available the services to its users. ## 2. User Accounts and Access ### 2.1 User Registration Access to the platform requires a valid user account, which is provided by the tenant or via corresponding self-service mechanisms. ### 2.2 Confidentiality of Access Credentials Users are obligated to: - Store access credentials securely - Not share them with third parties - In case of suspected misuse, notify the administrator immediately The tenant bears responsibility for all activities performed via its user accounts. ## 3. Permitted Use The user undertakes to use the platform only for lawful purposes and in accordance with these terms. The following are prohibited in particular: - Manipulation, decompilation or reverse engineering of the software - Use of the platform for illegal or harmful activities - Circumvention of security mechanisms - Unauthorized access to systems, data or integrations - Posting or processing unlawful content The platform may only be used within the scope of the intended business operations. ## 4. Responsibilities of the Tenant The tenant is responsible for: - The content accuracy of all processed documents and data - Compliance with all statutory storage and retention periods - Management of user rights and roles - Maintenance of its own infrastructure for on-premises components - Provision of data sources (e.g. ERP systems, email mailboxes, archives) The platform assumes no liability for incorrect or incomplete data delivered by the tenant or generated in its systems. ## 5. Availability and Operations ### 5.1 Cloud Operations The provider generally makes services available with high availability within European data centers. Maintenance work may cause temporary restrictions but will be announced in advance where possible. ### 5.2 Hybrid and On-Premises Operations For locally operated components (e.g. Cloud Connector, AI models or sync services), system availability is the responsibility of the tenant. ## 6. Data Processing and Privacy The processing of personal data is conducted in accordance with the **Privacy Policy** and in compliance with the GDPR. The tenant remains the owner of all data and bears legal responsibility for its processing. For cloud operations, a **Data Processing Agreement (DPA)** is concluded. ## 7. Integrations and Third-Party Services For integrations with systems such as: - SAP - Microsoft 365 / Graph API - Email providers - Archive systems (ArchiveLink, CMIS, etc.) - Peppol network the operation, availability and configuration thereof fall within the area of responsibility of the tenant or the respective third-party provider. The platform merely provides the corresponding interfaces. ## 8. Service Packages, Billing and Licensing Use of CLARC Infinity is based on: - Defined service packages - Annual term - Automatic renewal - Monthly usage statistics - Annual reconciliation with contractual volumes No base costs apply beyond the contractually agreed service packages. Licensed use is limited to the agreed tenant and scope of services. ## 9. Intellectual Property All components of the platform — including software, models, scripts, documentation and interfaces — are intellectual property of the provider. The tenant is granted a **non-exclusive, non-transferable right of use** within the scope of the contract. Transfer, rental, sale or sublicensing is not permitted. ## 10. Liability The provider's liability is — to the extent permitted by law — limited to intent and gross negligence. No liability exists for: - Data loss due to faulty customer systems - Failures caused by third-party providers - Damage caused by improper use or interference with the system - Economic consequential damages such as loss of profit or revenue ## 11. Changes to the Terms of Use The Terms of Use may be updated as needed to reflect technical, legal or organizational changes. The tenant will be notified of material changes in a timely manner. ## 12. Contact For questions about these terms of use or about using the platform, support or the provider's responsible contact person is available. --- # News & Events ## Digital Invoice Processing at Envases Öhringen GmbH Source: https://clarc.com/news/en/2026-06-03-envases-success.md Date: 2026-06-03 | Category: Partnership ### About Envases Envases Öhringen GmbH was founded in 1871 and produces high-quality tinplate packaging for paints, varnishes, chemical products and food in the INDUSTRIAL segment. In the BEVERAGE segment, the company is the world market leader in the production of tinplate party kegs. With a modern printing facility, the company prints sheet metal in photo quality. Approximately 600 employees work at three locations in Germany, Austria and Hungary. ### At a Glance - Faster invoice processing: reduced from approx. 4 days to 1.5 days - Transparency on invoice processing status - Improved quality of invoice verification - Compliance with early payment discount deadlines - Central archiving - Audit trail for the complete process ### Background Automated verification of supplier invoices had been an option for Envases Öhringen since the SAP ECC 6.0 implementation. With only a few accounting staff processing a large volume of incoming invoices, the company decided in the first quarter of 2012 to implement a corresponding solution. The goal was to manage the growing document volume and significantly reduce processing times. The company sought greater transparency and process reliability to enable period-accurate posting. Better use of early payment discounts and effective workflow design with the four-eyes principle were further motivations. ### Challenge Envases Öhringen wanted a central invoice receipt in Öhringen where all supplier invoices would be scanned. Depending on the approval level and amount, incoming invoices required additional management approvals. Since management predominantly used mobile devices, exclusive SAP access was not practical. The project team therefore opted for a browser-based web portal as the central user interface. Some incoming invoices and documents had a special document structure that OCR should detect automatically. CTO Balzuweit GmbH optimised the OCR application, defined relevant fields and trained the system accordingly. ### Why CLARC Invoice for SAP? After internal analysis and requirements gathering, Envases Öhringen conducted a targeted search for providers and selected CTO Balzuweit GmbH with CLARC Invoice for SAP, as it best matched the requirements profile. "CTO Balzuweit GmbH is our long-standing partner in the ECM sector – with great expertise and reliability." — Alfred Engel, IT Manager at Envases Öhringen ### Implementation Documents are scanned at the beginning and then processed digitally. Invoices are archived electronically and guided via workflow during the review process. Three work steps: (1) scanning, (2) OCR validation and SAP data comparison, (3) approval workflow and posting. ### Results Invoice processing time reduced from ~4 days to 1.5 days. Approximately 100 employees are involved in the approval workflow. "The project was completed 'in time and budget'." — Alfred Engel --- ## Customer Innovation Day – Strong Networks, Real Solutions Source: https://clarc.com/news/en/2026-05-28-customer-innovation-day.md Date: 2026-05-28 | Category: Event A day full of genuine conversations, fresh perspectives and direct dialogue with customers and partners. In the B2B and IT environment, the best solutions emerge through trust, the sharing of experience and the courage to tackle things together. Thank you to everyone who made this day something special. --- ## From Security Grade D to B+ – Release 1.10 Source: https://clarc.com/news/en/2026-05-15-security-score.md Date: 2026-05-15 | Category: Release CLARC Infinity climbed from 30 to 80/100 in the Mozilla Security Score through targeted HTTP Security Header hardening in Release 1.10. The security mechanisms were already fully implemented internally — what was missing was the outside perspective. For flexible platforms, balancing maximum security with maximum flexibility (local integrations, frontend scripting, open extension capabilities) is non-trivial. The next steps towards A/A+ are already underway. --- ## 100,000 Lines of Code Removed – Release 1.9 Source: https://clarc.com/news/en/2026-05-01-code-removed.md Date: 2026-05-01 | Category: Release With Release 1.9, CLARC Infinity removed 100,000 lines of code and over 100,000 lines of configuration — not because it had to, but because it could. The AI extraction strategy replaces grown logic using existing business object definitions, without additional effort for users or IT. Result: significantly less complexity, more speed, and more room for real innovation. --- ## Ad-hoc AI Extraction Directly in Microsoft 365 Source: https://clarc.com/news/en/2026-04-15-ki-extraktion-m365.md Date: 2026-04-15 | Category: Release AI-powered document extraction directly in Microsoft 365 — Outlook, Word, Excel and Microsoft Teams — without specialised AI or IT know-how. The solution uses existing business object definitions including position data and delivers structured data in an average of two seconds, ready for direct further processing. Upcoming: MCP integration to connect master data, archive data and on-premises systems securely and seamlessly. --- ## Digital Personnel Files at Griesson - de Beukelaer Source: https://clarc.com/news/en/2026-05-26-griesson-personalakten.md Date: 2026-05-26 | Category: Success Story Griesson - de Beukelaer is a family-owned company and one of the leading manufacturers of sweet and savoury biscuits in Europe. 2,000 employees produce well-known brands at three German locations. Key achievements: around 2,000 personnel files digitised, cross-site file migration across three locations, audit-proof scanning, structured indexing by document type, rapid implementation in 12 to 18 weeks. Personnel files were stored physically at individual locations. A structured digitisation project was implemented covering all steps from logistical planning through scanning to integration. Files were collected by a partner logistics company, audit-proof scanning with document-type-based indexing followed, and full-text search was created. An early review session after the first scanned documents ensured quality requirements were met. Digitised data was imported weekly so documents could be used directly in day-to-day HR operations. Result: a central, structured and audit-proof solution for managing HR documents. Information can be found faster, documents are available digitally across all locations and workload in HR has been noticeably reduced. "We are very satisfied with the collaboration. The project ran smoothly, transparently and on schedule at all times. The solution works in day-to-day operations exactly as we envisioned." -- Griesson - de Beukelaer --- ## Digital Transformation with CLARC Invoice at ANWR Group Source: https://clarc.com/news/en/2026-04-06-anwr-group.md Date: 2026-04-06 | Category: Success Story ANWR Group is a long-established trading cooperative with roots dating back to 1919, Europe's leading network in the retail sector. From its headquarters in Mainhausen, the company connects 4,500 independent businesses in shoe, sports and leather goods retail across 20 European countries -- with a business volume of over 20 billion euros. Well-known subsidiaries include SPORT 2000, DZB BANK GmbH and AKTIVBANK AG, as well as brands such as Deuter and Samsonite. Key achievements: seamless SAP CRM integration, ~50,000 incoming invoices processed annually across 15+ company codes, financial accounting automation with CLARC Invoice for SAP, early integration of structured formats (Adidas, Nike) ahead of e-invoicing mandates, modern archiving system for SAP and non-SAP documents, integration of cooperative banks AKTIVBANK AG and DZB BANK GmbH. The first milestone was implementing a powerful archiving system seamlessly connected to SAP, enabling archiving of all inbound and outbound documents and print lists -- accessible directly from the SAP interface or via a web-based research tool. Documents without an SAP reference can also be included. CLARC Invoice for SAP automates the entire invoice processing workflow -- from capture through to archiving. Intelligent OCR technology extracts invoice data automatically, an integrated approval workflow speeds up the review process, and mobile web validation allows invoices to be checked from anywhere. With the introduction of SAP CRM "Cloud for Customer" (C4C), a tailored interface to the archiving system was developed -- providing direct document access for customer-facing brands such as REXOR and GOLDKRONE. The cooperative banks AKTIVBANK AG and DZB BANK GmbH were integrated with their own archive installations, in some cases with direct connections to customer portals. This comprehensive digitalisation project significantly improved the efficiency and transparency of business processes at ANWR Group and created a solid foundation for future innovation. --- ## Release 1.8 -- AI Extraction and Extended Integrations Source: https://clarc.com/news/en/2026-04-01-release-1-8.md Date: 2026-04-01 | Category: Release Release 1.8 continues the bi-weekly release cycle established since the beginning of 2026. Instead of large, infrequent updates, new features reach the platform continuously and significantly faster. Two key focus areas: extended AI extraction with flexible schema definitions increases automation in core document processes -- documents are recognised, classified and processed more precisely. New integrations expand connectivity: from Microsoft Teams to ERP systems and additional open REST interfaces (OData), CLARC Infinity's interoperability continues to grow. Goal: an AI-driven platform that integrates seamlessly into existing system landscapes and delivers genuine value -- release by release.