1C:ZUP Synchronization with Corporate Portal

1C:ZUP Synchronization with Corporate Portal

When deploying an internal company portal, you often need to connect it to 1C:Payroll and HR Management (1C:ZUP). Without integration, employees cannot see their pay slips, leave requests remain paper-based, and the HR department wastes up to 20 hours per week manually transferring data. This not only slows down processes but also risks errors in personnel records. We automate the exchange: data from 1C:ZUP appears in the employee's personal account within minutes, and requests are instantly sent to the accounting system. The solution reduces operational costs by 40% and pays for itself in 3–6 months. On average, the HR department saves up to 160,000 RUB per month through automation.

If you want to establish seamless data exchange, contact our engineers — we will analyze your configuration and propose an architecture.

Typical Integration Scenarios

• Corporate portal — employees see pay slips, sick leave, vacations, income statements. Data comes from 1C:ZUP via REST API.
• Leave and documents — an employee submits a leave, business trip, or financial aid request through the portal. The request is created in 1C:ZUP.
• HR showcase — list of vacancies from 1C:ZUP on the company website, sending candidates back to the system.
• 1C-based authentication — for corporate portals, 1C sometimes acts as the source of truth for users.

Why REST API is the Best Choice for Integration

REST API ensures high performance and scalability. Unlike direct COM connections or file exchange, REST allows asynchronous request processing, which is critical during peak loads (end of month — bulk pay slip exports). We use 1C:Enterprise HTTP services, supported since version 8.2. For versions 8.3.10+, a built-in REST service is available without additional libraries. In our projects, we prefer REST for its flexibility and ease of monitoring.

How Personal Data Security is Ensured

Salary data and HR information are personal data under Russian Federal Law 152-FZ. Requirements:

• Channel encryption (TLS 1.2+) and data at rest encryption
• Logging all access to personal data
• Minimal necessary API user permissions
• Consent for personal data processing

We use only proven methods: if necessary, we sign NDAs and guarantee compliance with the law.

Comparison of Integration Methods

REST API outperforms HTTP services by 2–3 times in performance but requires more setup on the 1C side.

Comparison of 1C Versions for Integration

Work Stages

1. Analysis — we study your 1C:ZUP configuration, identify integration points, agree on data schema.
2. Design — develop architecture: endpoints, synchronization frequency, error handling mechanisms.
3. Implementation — write HTTP services on the 1C side, implement the API on the website (Laravel or another framework). We use standard patterns: Repository, DTO, Queue.
4. Testing — test with real data, simulate scenarios (hire/fire, leave, sick leave).
5. Deployment and support — deploy to production server, configure monitoring, hand over documentation.

Typical Mistakes in Integration

One common issue is data mismatch when org structure changes. For example, an employee is transferred to another department in 1C, but the portal still shows the old record. Our incremental synchronization mechanism captures changes every 15 minutes and updates the site cache. Another difficulty is incorrect employee matching by identifiers. We use UUIDs from 1C as foreign keys and check for duplicates before insertion.

What You Get in the End

After project completion, you receive:

• Working REST endpoints or HTTP services on 1C
• Integrated modules on the website (pay slips, requests, org structure)
• API documentation and instructions for HR specialists
• Source code of the integration layer
• Team training (2–3 hours)
• Integration warranty (3 months free support)

Pay Slip Example via REST API

// Request an employee's pay slip
$response = Http::withToken($this->getToken())
    ->get("{$this->baseUrl}/payslip", [
        'employee_id' => $employee->zup_id,
        'period' => '2023-01'  // YYYY-MM
    ]);

// Response contains accruals, deductions, payments
$payslip = [
    'gross'      => $response['Начислено'],
    'deductions' => $response['Удержано'],
    'net'        => $response['КВыплате'],
    'details'    => $response['СтрокиРасчётногоЛистка']
];

Leave Request Example

$leave = [
    'ТипОтпуска'     => 'Основной',
    'СотрудникID'    => $employee->zup_id,
    'ДатаНачала'     => $startDate->format('d.m.Y'),
    'ДатаОкончания'  => $endDate->format('d.m.Y'),
    'Комментарий'    => $request->comment
];

$result = Http::withToken($this->getToken())
    ->post("{$this->baseUrl}/leave-request/create", $leave);

Request status (pending / approved / rejected) is synchronized back via webhook or polling.

Results and Guarantees

Our experience — over 15 projects integrating 1C with corporate portals. We guarantee compliance with 152-FZ, provide source code and documentation. Integration reduces HR workload and speeds up HR processes. Integration budget starts from 250,000 RUB, payback in 4–6 months. Order a preliminary analysis of your 1C:ZUP for free — it takes one day. Our engineers will analyze your configuration and propose an architecture within a week.

Get a consultation right now — we will answer all your questions.

1C:Enterprise Integration: Product, Order, and Stock Exchange

Monday morning. The manager opens the site and sees that the item sold out on Friday is still listed as "in stock". Three customers have already paid for a product that doesn't exist. We encounter this pain regularly: the lack of synchronization between 1C and the online store hurts revenue and reputation. We solve the problem end-to-end — setting up the exchange so that the accounting system and the storefront update synchronously, without data loss, and with consistency guarantees.

1C is the accounting system of most Russian companies. The site is the storefront. They must speak the same language and do so regularly, reliably, and without data loss. Our experience: over 50 successful integrations for clients with catalogs from 500 to 200,000 SKUs.

Why isn't standard CommerceML always sufficient?

CommerceML is a standard exchange protocol supported by 1C:Trade Management, 1C:Integrated Automation, and several other configurations. WooCommerce, Shopify, and other CMS have plugins for CommerceML (e.g., "1C-Bitrix" for their products, separate plugins for WordPress). Flow: 1C initiates exchange → sends a ZIP archive with XML to the site endpoint → site parses and updates the catalog.

CommerceML format is XML with its own schema: КоммерческаяИнформация, Классификатор, Каталог, ПакетПредложений. Categories, products, characteristics, images, prices, stock. The main difficulty: the hierarchy of characteristics in 1C and product attributes on the site do not always match one-to-one. Mapping is needed. For a deep understanding of the protocol, we recommend documentation on Wikipedia — Wikipedia: CommerceML.

How we overcome CommerceML limitations

For non-standard 1C configurations or when CommerceML is not suitable — we write an HTTP service in 1C (built-in since version 8.3) and interact via REST JSON. This gives full control over the data structure and synchronization frequency, but requires development from a 1C programmer.

For enterprise tasks with multiple accounting systems — Message Broker (RabbitMQ, Apache Kafka) as an intermediary. 1C publishes events to a queue, the site subscribes and processes them. Guaranteed delivery, buffering when one side is unavailable.

What we synchronize and how

Catalog (products, categories, attributes). The most voluminous part. Full export on first run, delta updates thereafter. When importing CommerceML: parse XML via PHP SimpleXML or XMLReader (for large files — only XMLReader, otherwise memory limit). Match products by GUID from 1C, which we store in a separate database field. If a product is deleted in 1C, we hide it on the site, not delete (order history may reference it).

Stock and prices. This is a separate ПакетПредложений in CommerceML, updated more often than the catalog. It's critical to do it atomically: not update stock one by one, but in a transaction. Otherwise, during the update, the user may see an inconsistent state. Frequency: once an hour for calm mode, once every 5–15 minutes for active trading.

Orders. Two-way exchange. Site → 1C: new order is sent with items, quantities, prices, customer contact info. 1C → site: order status (paid, assembled, shipped, delivered). For order transfer — either the same CommerceML (Документы block) or a direct REST call when an order is created on the site.

What typical problems do we solve?

Duplicate products. A 1C operator created an item with a typo in the SKU, then fixed it. On the site — two items. Solution: matching by GUID from 1C (not by SKU), GUID is immutable.

Cyrillic in XML and encodings. 1C historically works with Windows-1251. A CommerceML file may come in CP1251, PHP expects UTF-8. mb_convert_encoding() or iconv() in the first lines of the parser — mandatory.

Timeouts during large exports. A catalog of 100,000 items is 50–200MB XML. PHP default execution time of 30s is insufficient. Solution: CLI command (Laravel Artisan or Symfony Console) run via cron, without HTTP timeout. Or chunked processing via XMLReader with partial commits to the database.

Images. 1C can transmit images as Base64 inside XML (bloats file by 1.3x) or as file links. The second option is preferable. Download asynchronously, convert to WebP, place in media library.

Case: auto parts online store, 85,000 SKUs. Synchronization via CommerceML every 30 minutes. Problem: full export took 18 minutes, resulting in a new export starting while the old one was still running. Solution: lock via Redis (SET nx ex), delta export (only changed items in the last 2 hours via filter in 1C), processing via queue with 20 parallel workers. Sync time: 18 minutes → 2.5 minutes, no conflicts.

Comparison of integration methods

CommerceML in typical scenarios is 2-3 times faster than REST for catalog synchronization due to binary packing of XML and compact format. However, if custom exchange logic is required, REST provides full flexibility.

Process and timeline

Audit of 1C configuration (version, configuration type, export capabilities) → data mapping design → development of receiver on site and sender in 1C → testing on real data → schedule setup → monitoring of first exchanges.

Participation of a 1C programmer on the client side is mandatory, or we involve a trusted specialist.

| Scenario | Timeline | | CommerceML, catalog + stock, WooCommerce | 2–4 weeks | | Two-way order exchange | +2–3 weeks | | Custom 1C configuration, REST API | 4–8 weeks | | Enterprise: multiple 1C databases, data bus | 2–4 months |

What's included in the result (deliverables)

• Documentation: mapping scheme, data formats, error handling logic.
• Configured synchronization schedule with execution logs.
• Access to monitoring (Grafana/ELK — by agreement).
• Training for managers: how to run manual exchange, how to read logs.
• Post-launch warranty support — 2 weeks (issue fixing).

Get a consultation

We will evaluate your project within one business day — email us or use the chat. The integration cost is calculated individually based on project complexity. With over 7 years of experience in 1C integrations, we guarantee stable synchronization without surprises.