Integration of 1C-Bitrix with the SBIS electronic document management system

1C-Bitrix Integration with SBIS EDI System

SBIS (Tensor) is the second most widely used EDI operator in Russia after Diadoc. A number of large suppliers and government entities operate exclusively through SBIS, making integration with it a mandatory requirement for B2B platforms dealing with specific counterparties. Technically, SBIS provides its own JSON API that differs from the REST concept used by Diadoc — it uses session-based authorization and a distinctive request structure.

SBIS API: Key Characteristics

SBIS uses a JSONRPC-like protocol. All calls go to a single endpoint:

POST https://online.sbis.ru/service/

With a request body in the following format:

{
    "jsonrpc": "2.0",
    "method": "СБИС.АутентифицироватьПоПаролю",
    "params": {
        "Логин": "[email protected]",
        "Пароль": "***"
    },
    "id": 1
}

Method names are in Russian. This is unconventional but stable — Tensor has maintained this notation since 2014.

Authorization and Session

class SbisClient
{
    private string $baseUrl = 'https://online.sbis.ru/service/';
    private ?string $sid = null; // session id

    public function __construct(
        private string $login,
        private string $password,
        private string $inn
    ) {}

    public function authenticate(): void
    {
        $response = $this->call('СБИС.АутентифицироватьПоПаролю', [
            'Логин'   => $this->login,
            'Пароль'  => $this->password,
        ]);
        $this->sid = $response['result'];
    }

    public function call(string $method, array $params): array
    {
        $payload = [
            'jsonrpc' => '2.0',
            'method'  => $method,
            'params'  => $params,
            'id'      => uniqid(),
        ];

        $headers = ['Content-Type: application/json; charset=utf-8'];
        if ($this->sid) {
            $headers[] = 'X-SBISSessionID: ' . $this->sid;
        }

        $ch = curl_init($this->baseUrl);
        curl_setopt_array($ch, [
            CURLOPT_POST           => true,
            CURLOPT_POSTFIELDS     => json_encode($payload),
            CURLOPT_HTTPHEADER     => $headers,
            CURLOPT_RETURNTRANSFER => true,
        ]);

        $body = curl_exec($ch);
        return json_decode($body, true);
    }
}

The session is stored in Redis/APC and reused. On expiry (typically 24 hours) — automatic re-authentication.

Sending a Document

In SBIS, documents are sent via the СБИС.ОтправитьДокумент method:

public function sendDocument(\Bitrix\Sale\Order $order): string
{
    // Build the SBIS document structure
    $document = [
        'Документ' => [
            'Тип'    => 'ДокОтгрВх', // type: inbound shipment document
            'Дата'   => date('d.m.Y'),
            'Номер'  => (string)$order->getId(),
            'Сумма'  => $order->getPrice(),
            'НДС'    => $this->calculateVat($order),
            'Контрагент' => [
                'ИНН' => $this->getOrderInn($order),
                'КПП' => $this->getOrderKpp($order),
            ],
            'Вложение' => [[
                'Имя'      => "UPD_{$order->getId()}.xml",
                'ДвоичныеДанные' => base64_encode($this->generateXml($order)),
            ]],
        ],
    ];

    $result = $this->call('СБИС.ОтправитьДокумент', ['Документ' => $document]);

    return $result['result']['Идентификатор'] ?? '';
}

The SBIS document structure differs from Diadoc — field names are in Russian, but the logic is the same: XML with a QES signature plus metadata.

Retrieving Statuses

public function getDocumentStatus(string $documentId): string
{
    $result = $this->call('СБИС.ПолучитьДокумент', [
        'Идентификатор' => $documentId,
    ]);

    return $result['result']['Документ']['Состояние'] ?? 'Неизвестно';
}

// SBIS status values:
// 'Отправлен' (Sent), 'Доставлен' (Delivered), 'Подписан' (Signed),
// 'Отказано' (Rejected), 'Аннулирован' (Cancelled)

Case Study: Integration for a Food Wholesale Supplier

A wholesale food supplier operating across multiple EDI operators simultaneously (some counterparties use Diadoc, some SBIS, some the FTS EDI Lite service). Requirement: a unified interface in Bitrix for working with all EDI operators without switching between web portals.

Architecture:

An abstract EdoProvider class was created with send(), getStatus(), and getList() methods. Implementations: DiadokProvider, SbisProvider, FnsEdoProvider. Provider selection via a registry keyed by the counterparty's BoxId.

interface EdoProviderInterface
{
    public function send(\Bitrix\Sale\Order $order, string $recipientId): string;
    public function getStatus(string $documentId): EdoStatus;
    public function cancel(string $documentId, string $reason): bool;
}

When an order is created, the system automatically identifies the counterparty's EDI operator via a shared directory. The manager sees a unified "EDI Documents" block in the Bitrix order card regardless of which operator the counterparty uses.

Roaming Between Operators

SBIS supports roaming with Diadoc and other operators. A document sent via SBIS is automatically delivered to a counterparty in Diadoc. This resolves the "we use SBIS, they use Diadoc" problem in most cases. In code, this means: one API call to SBIS, delivery is transparent to the sender.

Electronic Signatures on the Server

SBIS supports cloud signing via the "SBIS Cloud Signature" service — the certificate is stored on Tensor's servers, signing occurs via API without needing CryptoPro installed on the production server. This significantly simplifies deployment:

public function signWithCloudCert(string $xmlContent, string $certId): string
{
    $result = $this->call('СБИС.ПодписатьОблачнойПодписью', [
        'Сертификат'     => $certId,
        'ДвоичныеДанные' => base64_encode($xmlContent),
    ]);
    return base64_decode($result['result']['ПодписанныеДанные']);
}

Scope of Work

• SBIS registration, obtaining API access
• Cloud signature or CryptoPro CSP setup
• PHP SBIS API client development
• XML document generation in FTS format
• Bitrix event handlers: send on order status change
• Status synchronization via polling (cron)
• Status display in the order card

Timeline: basic integration — 3–4 weeks. Multi-operator EDI with a unified interface — 8–12 weeks.