Грабли синхронизации PDP Mobile с 1С:ERP для бухгалтерии и счётчиков

«У одного электросчётчика оказалось три показания на одну дату».

В PDP Mobile подключали синхронизацию с 1С:ERP: лицевые счета, начисления, показания счётчиков и квитанции. На бумаге задача выглядит как обычный обмен с учётной системой. В реализации быстро всплыли места, где нельзя срезать углы: идентификаторы счётчиков, временные ряды показаний и тарифные зоны.

Ниже — три грабли, которые мы обошли в этой интеграции.

Грабля 1. Привязать показания только к лицевому счёту

Лицевой счёт — удобная сущность для пользователя: он видит объект, начисления, квитанции. Но для бухгалтерии показание принадлежит не абстрактному «счёту», а конкретному счётчику в 1С:ERP.

Поэтому каждый счётчик в PDP Mobile хранит идентификатор из учётной системы. Не локальный номер из мобильного приложения, не адрес, не тип ресурса, а именно id счётчика в 1С:ERP. Это поле становится опорной точкой при передаче показаний.

Если отправлять только лицевой счёт и набор значений, на стороне 1С остаётся слишком много догадок: какой прибор принять, куда отнести историю, что делать при замене счётчика. Мы убрали эту неоднозначность на уровне модели: сначала находим счётчик как объект учёта, потом передаём его показания.

Живая деталь: больше всего обсуждали не PDF-квитанции, а то, где проходит граница между «данными для экрана» и «данными для бухгалтерии». На экране можно показать компактно. В интеграции компактность быстро превращается в потерю смысла.

Грабля 2. Считать показание одним числом

Для однотарифного счётчика это соблазнительно: дата и значение. Но в проекте есть трёхтарифный электросчётчик, а значит на одну дату приходят отдельные значения по зонам T1, T2 и T3.

Мы не стали сворачивать их в одно поле и не стали передавать «общую сумму». Показания уходят как временные ряды: дата плюс значения по тарифным зонам. Для трёхтарифного электросчётчика T1/T2/T3 передаются отдельно.

Такой формат важен не только для красивой структуры. Начисления в 1С:ERP завязаны на тарифные зоны. Если зона потерялась на входе, дальше бухгалтерия видит данные, которые уже нельзя корректно разложить обратно.

Минимальная форма записи выглядит так:

{
  "meterAccountingId": "id-в-1С",
  "date": "2024-..-..",
  "zones": {
    "T1": "...",
    "T2": "...",
    "T3": "..."
  }
}

Здесь важен не сам JSON, а контракт: дата не отделяется от значений, а зоны не смешиваются. Для счётчиков с одной зоной структура остаётся той же логически, просто набор зон короче.

Грабля 3. Генерировать квитанцию отдельно от данных 1С

Квитанция в PDF — видимая часть для пользователя, поэтому её легко начать собирать на стороне приложения: взять начисления, лицевой счёт, период, нарисовать шаблон. Но тогда появляются две версии одной финансовой сущности: данные в 1С:ERP и PDF, который приложение собрало само.

Мы пошли от учётной системы. PDF-квитанции формируются из данных 1С. PDP Mobile получает результат, который соответствует тому, что бухгалтерия считает источником расчётов.

Это особенно важно рядом с начислениями и показаниями. Пользователь передал показания, 1С обработала данные, сформировала начисления, затем из этих данных появилась квитанция. Если разорвать цепочку и рисовать PDF отдельно, расхождения будут выглядеть как баг приложения, хотя причина может быть в расхождении источников.

Что зафиксировали в контракте обмена

В этой интеграции мы держали несколько правил:

• лицевой счёт синхронизируется как бухгалтерская сущность, а не только как карточка в приложении;
• каждый счётчик связан с идентификатором в 1С:ERP;
• показания передаются временным рядом с датой;
• тарифные зоны T1/T2/T3 не объединяются;
• PDF-квитанция строится на данных 1С.

Самое неприятное место — не транспорт и не файл PDF. Ошибка обычно появляется раньше, в модели данных: один счётчик принимают за одно число, а лицевой счёт — за достаточный идентификатор прибора. Для электросчётчика в контракте остаются дата, id счётчика из 1С:ERP и отдельные значения T1/T2/T3.