1C Integration with Mobile Application
1C is the most widely used accounting system in post-Soviet markets, and the task "connect a mobile application to 1C" comes up for nearly every second B2B client. The complexity lies not in the integration itself, but in the zoo of 1C configurations: Accounting, Trade Management, ERP, Unified Commercial, HR—each has its own data structure, and what works in Trade Management 11 won't work in ERP 2.5.
Connection Methods to 1C
HTTP Services in 1C — the native way for modern configurations. In the Configurator, you create an HTTP service with methods (GET, POST, PUT). Business logic is written in 1C's embedded language. The result is a REST API that the mobile application calls directly.
Pros: logic stays inside 1C, no third-party components. Cons: you need a 1C developer on the project, performance is limited (1C isn't optimized for high-concurrency HTTP requests).
OData Interface in 1C — automatically publishes configuration objects (directories, documents, registers) as OData v4. Enabled by publishing on a web server without writing code. Convenient for quick prototypes, but 1C OData queries have limitations: not all filter operators work, nested expand often fails.
External Component + COM — an outdated approach for desktop integrations, not applicable to mobile.
Middleware (recommended) — a Node.js / Go / .NET service calls 1C via HTTP services or OData, caches directories, transforms responses, and returns concise JSON to the mobile client.
Authentication
1C supports Basic Auth out of the box (1C username and password). For production, this is acceptable only over HTTPS and using a technical user with minimal required permissions in 1C.
OAuth 2.0 in 1C — no native support in standard configurations. Options: configure a custom mechanism through 1C:Enterprise Development Tools or use an external IdP (Keycloak) with token mapping to a 1C user in middleware.
On the mobile client: never store Basic Auth credentials in SharedPreferences or UserDefaults in plain text. Use Android Keystore + EncryptedSharedPreferences, iOS Keychain.
Typical Tasks and Their Complexities
Getting stock balances — a popular task. 1C stores balances in accumulation registers (BalanceRegister.GoodsInWarehouses). OData query: GET /odata/standard.odata/AccumulationRegister_GoodsInWarehouses/Balance?$filter=... — works, but slow on large databases without optimization from the 1C developer.
Better: HTTP service in 1C with optimized query (SELECT + GROUP BY), cache balances in middleware with 2-5 minute TTL.
Creating a document (order, bill)—requires a transaction on the 1C side. HTTP POST → 1C creates object, posts document, returns number. If posting fails (no balance, no counterparty) — 1C should return meaningful error, not "Error 500". Agree on error format with the 1C developer in advance.
Directory synchronization (product catalog, counterparties). A product directory with 50,000 items can't be loaded in full every time. The 1C HTTP service with modified_since parameter should return only changed items. Implemented via ThisObject.ChangeDate in the query. Sync frequency: directories — every 30-60 minutes, prices — when opening a document.
Offline for Mobile Warehouse
Scenario: a mobile data terminal (barcode scanner) on Android in a warehouse with poor WiFi. The operator scans barcodes, creates inventory—locally in Room. When complete or on connection—send to 1C in one batch.
1C side: HTTP service accepts array of items, creates inventory document, returns result. On mobile: while document isn't confirmed by 1C, status is "pending". After confirmation—status is "sent", local copy marked as synchronized.
Common Integration Errors
Publishing 1C on IIS without SSL—all data (balances, prices, bills) transmitted in plain text. HTTPS with valid certificate is mandatory.
Ignoring 1C user permissions—technical user with administrator rights. Violates least privilege principle: if mobile app only reads balances, technical user should have read-only access to that register.
No timeout on 1C requests. A heavy query in 1C might run 30-60 seconds. Mobile client hangs without timeout. Middleware sets timeout: 15s on 1C call, returns 504 to client, which shows retry button.
Timeline
1C configuration audit and integration design: 3-5 days. Basic integration (reading directories and balances, creating documents) via HTTP services: 3-6 weeks. Full offline support, delta-sync of directories, proper 1C error handling: plus 2-3 weeks. Cost calculated individually—heavily depends on 1C configuration and customization scope.