Integration of Bitrix24 with 1C-EDO

Bitrix24 Integration with 1C-EDO

Bitrix24 has no built-in EDI module. The CRM can issue invoices and generate commercial proposals, but legally significant document interchange — UPD, acts, invoices with a qualified electronic signature — remains outside the system. A manager closes a deal in Bitrix24 while the accountant separately creates documents in 1C-EDO. This is a gap: the manager cannot see document status, and the accountant has no context for the deal.

Integrating Bitrix24 with 1C-EDO closes this gap: EDO document status is visible in the deal card, and document creation is automated based on pipeline stages.

Integration Architecture

1C-EDO has no direct API — it is built into the 1C configuration. Integration is therefore built through a chain:

Bitrix24 (deal won)
  → Webhook → Middleware service
    → 1C REST (create realization)
      → 1C-EDO (auto-send)
        → EDO operator → Counterparty
          → 1C: status received
            → Middleware: polling 1C for statuses
              → Bitrix24 REST API: update field in deal

The Middleware is a separate service (PHP/Node.js/Python) that acts as the glue between Bitrix24 REST and 1C REST. Its role is event translation and data synchronization.

Bitrix24 Webhook on Stage Change

// Middleware: webhook handler from Bitrix24
// POST /webhooks/bitrix24/deal-stage

class DealStageWebhookHandler
{
    public function handle(array $payload): void
    {
        $dealId     = $payload['data']['FIELDS']['ID'];
        $stageId    = $payload['data']['FIELDS']['STAGE_ID'];
        $prevStage  = $payload['data']['FIELDS']['PREVIOUS_STAGE_ID'] ?? '';

        // Only react to the specific stage (deal won)
        if ($stageId !== 'WON' && $stageId !== 'C1:WON') {
            return;
        }

        // Fetch deal data from Bitrix24
        $deal = $this->b24->call('crm.deal.get', ['ID' => $dealId]);

        // Pass to 1C
        $onecResult = $this->onec->createRealization([
            'dealId'    => $dealId,
            'inn'       => $deal['UF_CRM_INN'],
            'amount'    => $deal['OPPORTUNITY'],
            'items'     => $this->getDealProducts($dealId),
        ]);

        // Write document ID to a custom deal field
        $this->b24->call('crm.deal.update', [
            'ID'     => $dealId,
            'FIELDS' => [
                'UF_CRM_1S_DOC_ID'     => $onecResult['docId'],
                'UF_CRM_EDO_STATUS'    => 'Pending dispatch',
                'UF_CRM_EDO_SENT_DATE' => date('d.m.Y H:i'),
            ],
        ]);
    }
}

REST Service in 1C for Receiving Documents

A published HTTP service is created on the 1C side:

// In the 1C configuration:
// Publish HTTP Service → CreateRealization
// URL: /1c/hs/bitrix/create-realization

The service receives JSON with deal parameters, creates a "Sales of Goods and Services" document in 1C, posts it, and queues it in 1C-EDO for dispatch.

Synchronizing EDO Statuses Back to Bitrix24

// Cron: every 15 minutes
class EdoStatusSync
{
    public function run(): void
    {
        // Query 1C for documents with changed statuses in the past hour
        $changed = $this->onec->getChangedEdoStatuses(
            (new DateTime())->modify('-1 hour')
        );

        foreach ($changed as $doc) {
            $dealId = $this->getDealIdByDocId($doc['docId']);
            if (!$dealId) continue;

            $this->b24->call('crm.deal.update', [
                'ID'     => $dealId,
                'FIELDS' => [
                    'UF_CRM_EDO_STATUS' => $doc['edoStatus'],
                    'UF_CRM_EDO_SIGNED' => $doc['signedDate'],
                ],
            ]);

            // Add a record to the deal activity timeline
            $this->b24->call('crm.timeline.comment.add', [
                'ENTITY_TYPE' => 'deal',
                'ENTITY_ID'   => $dealId,
                'COMMENT'     => "EDO: status changed to \"{$doc['edoStatus']}\"",
            ]);
        }
    }
}

Case Study: Integration for an IT Outsourcing Company

50 managers, 200–300 closed deals per month, all service-based (acceptance acts, invoices). The accountant manually created documents in 1C after deals were closed — with a 1–3 day delay and errors in counterparty details (managers did not always pass correct information).

Implementation:

1. Deal fields were added in Bitrix24: INN, KPP, EDO BoxId, document type (act/UPD). Fields are filled during the deal workflow.

2. When the deal moves to the "Services Rendered" stage — webhook → Middleware → 1C REST. An act is created in 1C and dispatched via 1C-EDO.

3. A Bitrix24 application widget (React, embedded via CRM_DEAL_DETAIL_TAB) is shown in the deal card, displaying EDO document status for the deal with an "Open in 1C" button.

4. When the counterparty signs the act — 1C updates the deal field, and the deal automatically moves to the "Closed. Documents Signed" stage.

Cancellation and Corrections

When a deal is lost in Bitrix24 — a webhook triggers a document cancellation request in 1C-EDO. The procedure: 1C sends a cancellation proposal to the counterparty; upon agreement, the document is cancelled on the operator's side.

if ($stageId === 'LOSE' && !empty($deal['UF_CRM_1S_DOC_ID'])) {
    $this->onec->annulDocument($deal['UF_CRM_1S_DOC_ID'], [
        'reason' => $deal['COMMENTS'] ?? 'Deal cancelled',
    ]);
}

Scope of Work

• Middleware service development: webhook handlers, Bitrix24 and 1C REST clients
• HTTP service setup in 1C
• 1C-EDO configuration: auto-send rules, document types
• Custom deal fields in Bitrix24
• Status synchronization: cron + timeline comments
• Deal card widget (optional)
• Testing with real documents

Timeline: basic integration (webhook → 1C → statuses back) — 4–6 weeks. With widget and cancellation handling — 7–10 weeks.