Правильный журнал обменов отвечает на вопрос «где заявка» за десять минут и без участия программиста: менеджер вводит номер, видит цепочку из пяти шагов и точку, в которой она обрывается. Неправильный журнал — или его отсутствие — превращает тот же вопрос в расследование на два-три часа по ставке подрядчика, а иногда не даёт ответа вообще.
Разница между этими двумя состояниями — одна строка в смете и одно проектное решение, принятое в самом начале. Строка стоит 58 000 ₽. Решение — завести сквозной идентификатор заявки и протащить его через все системы — не стоит ничего, если о нём подумали до разработки, и стоит переделки половины обменов, если о нём вспомнили через полгода.
Ниже — состав записи журнала, который заказчик вправе требовать; механика сквозного идентификатора; последовательность разбора спора «мы отправили — вы не получали»; ограничения 152-ФЗ на содержимое журнала и расчёт объёма хранения на потоке в 5 000 операций в сутки. Как выглядит соседняя строка сметы — очередь и повторы, из-за которых у записи вообще появляется поле «номер попытки», — разобрано в статье про очереди и повторные попытки.
Шесть полей, без которых журнал бесполезен
Журналом часто называют файл, в который система пишет то, что считает нужным. Для разбора спора этого мало: нужны именно те поля, по которым восстанавливается путь одной конкретной заявки. Шесть обязательных и три желательных выглядят так.
| Поле | Пример значения | Зачем нужно | Обязательно |
|---|---|---|---|
| Время с точностью до секунды и часовым поясом | 3 сентября 2026, 14:07:12 (МСК) | Сопоставить запись с событиями в чужих системах, у которых своё время | Да |
| Направление | Обработчик → 1С:УТ | Понять, на каком участке маршрута оборвалась цепочка | Да |
| Сквозной идентификатор | R-20418 | Связать все записи одной заявки во всех системах маршрута | Да |
| Номер попытки | 3 из 6 | Увидеть деградацию до того, как обмен встанет совсем | Да |
| Тело запроса, с маскированными персональными данными | Заказ, 3 позиции, контрагент 7743…, телефон +7 921 ***-**-67 | Доказать, что именно было отправлено, а не что кто-то помнит | Да |
| Ответ получателя: код и текст | 400, «артикул 77-234 не найден в справочнике» | Понять причину отказа без обращения к разработчику | Да |
| Итоговый статус записи | Доставлено / повтор / в карантине | Ответить на вопрос «чем всё закончилось» одним взглядом | Желательно |
| Длительность операции | 240 мс | Заметить, что приёмник начал тормозить, за недели до отказов | Желательно |
| Кто инициировал | Вебхук сайта / ручная переотправка, оператор Иванова | Отличить работу системы от действий человека при разборе | Желательно |
И отдельное требование, без которого весь список не работает: поиск по номеру заявки и по дате. Журнал, в котором можно только листать последние записи, — это не журнал, а свалка. Проверяется это на приёмке одной фразой: «покажите мне заявку номер такой-то за прошлый вторник».
Сквозной идентификатор: одна заявка — один номер во всех системах
Сквозной идентификатор — это номер, который присваивается заявке в момент её рождения и дальше едет с ней по всему маршруту неизменным. Он не заменяет номер сделки в CRM и номер документа в учёте: те появляются позже и живут внутри своих систем. Сквозной номер нужен ровно для одного — чтобы любая из систем маршрута могла найти у себя записи, относящиеся к одной и той же заявке клиента.
Идентификатор рождается в первой системе на пути, а не в последней. Номер документа в 1С появляется в конце цепочки: если заявка до 1С не доехала, номера нет — и искать нечего. Именно поэтому номер документа получателя не годится на роль сквозного номера, хотя предлагают его чаще всего.
| Шаг маршрута | Время | Что происходит с номером R-20418 |
|---|---|---|
| Форма на сайте | 14:07:12 | Номер присваивается, показывается клиенту на экране «спасибо» |
| Приёмник событий | 14:07:12 | Номер записан в журнал, отправлено подтверждение приёма |
| Очередь | 14:07:13 | Сообщение с номером положено в буфер |
| Обработчик | 14:07:15 | Номер записан в журнал вместе с телом запроса и ответом |
| CRM | 14:07:16 | Номер сохранён в карточке сделки как отдельное поле |
| 1С:УТ | 14:07:16 | Номер сохранён в реквизите документа, документ получил свой номер 0000412 |
Стоимость такого решения — почти нулевая, если оно принято до разработки: одно дополнительное поле в каждом сообщении и один реквизит в каждой системе-получателе. Стоимость его отсутствия — переделка всех направлений обмена задним числом плюс невозможность разобрать все споры, случившиеся до переделки. Это тот случай, когда правильный вопрос подрядчику задаётся на первой встрече, а не на приёмке.
Карта связей из шести узлов, соединённых стрелками слева направо: «Форма на сайте», «Приёмник событий», «Очередь», «Обработчик», «CRM», «1С:УТ». На каждом узле — плашка с номером «R-20418» и временем: 14:07:12, 14:07:12, 14:07:13, 14:07:15, 14:07:16, 14:07:16. Подписи на связях: «новая заявка», «подтверждение приёма», «сообщение в буфере», «документ», «карточка сделки». Под узлами «CRM» и «1С:УТ» дополнительные плашки собственных номеров: «Сделка 8841» и «Документ 0000412» с подписью «появляются в конце — искать по ним нельзя». Внизу горизонтальная лента журнала с шестью строками, у всех одинаковый номер R-20418. Чертёжный стиль, подписи по-русски.
Спор «мы отправили — вы не получали»: разбор за десять минут
Это самый частый разговор в эксплуатации интеграций и самый бессмысленный, если у сторон нет общей записи фактов. Разработчик сайта говорит, что заказ ушёл. Разработчик 1С говорит, что ничего не приходило. Обе стороны искренни: у первой в логе есть строка об отправке, у второй в базе нет документа. Журнал прекращает спор, потому что показывает не мнения, а ответ принимающей стороны.
- 1Шаг 1. Получить сквозной номер
Клиент называет номер с экрана «спасибо» или из письма-подтверждения. Если номера у него нет, менеджер находит заявку в журнале по дате и телефону — поэтому в поиске нужны оба фильтра, а не только номер.
- 2Шаг 2. Открыть цепочку записей
По одному номеру журнал показывает все записи всех участков маршрута в хронологическом порядке. Это и есть главная ценность сквозного идентификатора: не приходится вручную сопоставлять времена и содержимое в трёх разных системах.
- 3Шаг 3. Найти место обрыва
Цепочка читается сверху вниз до первой записи, после которой ничего нет. Она и указывает участок. Дальше ответ определяется содержимым этой записи, и вариантов ровно три.
- 4Шаг 4. Определить исход и назвать виновный участок
Исход А: есть отправка и ответ об успехе — заявка у получателя, искать надо внутри него, вопрос снимается с интеграции. Исход Б: есть отправка и ответ с отказом — отправлено, но получатель не принял, причина написана в его же ответе. Исход В: записи об отправке нет вообще — до приёмника заявка не дошла, проблема на стороне источника.
Практический вывод для договора: исход Б встречается чаще всего, и в нём обычно виноват не подрядчик по интеграции, а справочник. Артикул не заведён, у контрагента нет ИНН, статус не описан в правилах. Поэтому в договоре стоит заранее разделить ответственность: техническая доставка — зона подрядчика, содержательная корректность справочников — зона заказчика. Как мы фиксируем это в гарантиях, видно на отдельной странице.
Нарисованный, не скриншотный, абстрактный экран журнала обменов. Сверху строка поиска с введённым значением «R-20418» и фильтром «02–03 сентября». Ниже вертикальная цепочка из шести шагов с временем и статусом: «14:07:12 Форма сайта — принято», «14:07:12 Приёмник — подтверждено», «14:07:13 Очередь — в буфере», «14:07:15 Обработчик → 1С:УТ — попытка 1, ответ 400: артикул 77-234 не найден», «14:12:15 Обработчик → 1С:УТ — попытка 4, ответ 400», «14:28:20 Карантин — 6 попыток исчерпано». Шаг с первым отказом выделен рамкой и подписан сбоку «здесь обрыв, причина — в ответе получателя». Внизу кнопка «Отправить заново» и подпись «после исправления справочника». Телефон в теле запроса показан маскированным: «+7 921 ***-**-67». Чертёжный стиль без имитации реального продукта, подписи по-русски.
Сколько стоит не иметь журнала
Модельная компания: 5 000 операций обмена в сутки — заказы, смены статусов, обновления остатков. Часть вопросов «где заявка» решается менеджером за минуту прямо в CRM, потому что заявка на месте и просто не замечена. Считаем только те случаи, которые доходят до разработчика.
Честная оговорка к расчёту: четыре разбора в месяц — это признак уже нездорового обмена. Если у вас такой случай один раз в месяц, экономия падает до 7 317 ₽, а окупаемость сдвигается на восьмой месяц. Это по-прежнему быстро, но аргумент «журнал окупается за два месяца» надо применять к своим числам, а не к чужим. Порядок цен остальных строк надёжности разобран в материале о стоимости надёжной интеграции.
Есть и вторая польза журнала, которую невозможно оценить в рублях напрямую. Он единственный источник, по которому видно, что обмен работает не так, как задумано, до того как это станет заметно в деньгах: растущее число повторов означает, что чужой сервис деградирует; повторяющаяся одна и та же причина отказа означает дыру в справочнике; всплеск отправок ночью означает, что кто-то запустил повторную выгрузку периода. На этих же данных строится мониторинг интеграций — без журнала мониторингу не на что опереться.
Чего в журнале быть не должно
Журнал обменов почти всегда содержит персональные данные: имя клиента, телефон, адрес доставки, иногда сведения о заказанных товарах или услугах. Это значит, что журнал сам по себе — информационная система персональных данных со всеми вытекающими требованиями 152-ФЗ, а не «технический файл разработчика».
| Что | Как поступать | Почему |
|---|---|---|
| Пароли, токены, ключи доступа к чужим API | Не писать никогда, ни в каком виде | Утечка журнала превращается в утечку доступов ко всем связанным системам |
| Номера банковских карт, коды подтверждения | Не писать никогда | Отдельные требования к защите платёжных данных, которым журнал не соответствует |
| Телефон и электронная почта клиента | Маскировать: +7 921 ***-**-67, i***@mail.ru | Для разбора достаточно узнаваемости, полное значение не нужно |
| Паспортные данные, сведения о здоровье | Не писать; в теле запроса заменять на признак «поле передано» | Специальные категории данных, требования к защите несопоставимо выше |
| Адрес доставки, состав заказа | Писать, но с ограниченным сроком хранения | Без них разбор спора невозможен, но хранить их годами оснований нет |
| Сам факт доступа сотрудника к журналу | Записывать: кто, когда, какую заявку смотрел | Требование к системам с персональными данными и защита от внутренних утечек |
Если журнал обменов физически лежит на серверах исполнителя, вы поручаете ему обработку персональных данных. Это оформляется отдельно: поручение обработки, перечень действий, требования к защите, срок хранения. Данные при этом должны находиться на серверах в России. Оператором остаётесь вы, и отвечать за утечку из журнала подрядчика будете тоже вы — подход к разграничению доступа мы описываем на странице безопасности.
Сравнение в три колонки. Левая «Пишем целиком»: время и часовой пояс, направление, сквозной идентификатор R-20418, номер попытки, коды и тексты ответов, состав заказа. Средняя «Маскируем»: телефон как «+7 921 ***-**-67», почта как «i***@mail.ru», ИНН как «7743…», адрес как «Москва, ул. ***». Правая «Не пишем никогда»: пароли и токены доступа, номера карт и коды подтверждения, паспортные данные, сведения о здоровье — колонка перечёркнута крест-накрест. Под колонками общая подпись: «Журнал с персональными данными — сам по себе система персональных данных: серверы в РФ, доступ по списку, ограниченный срок хранения». Чертёжный стиль, подписи по-русски.
Сколько это весит и сколько хранить
Самое частое возражение против подробного журнала — «это же терабайты». Считаем на потоке 5 000 операций в сутки: это довольно активный обмен, примерно уровень интернет-магазина с несколькими тысячами заказов в месяц плюс статусы и остатки.
Столбиковая диаграмма из трёх столбцов при 5 000 операций в сутки и записи 6 КБ. Столбцы подписаны: «Сутки — 30 МБ», «Горячее хранение, 90 дней — 2,7 ГБ», «Год с архивом, сжатие в 7 раз — 3,9 ГБ». Справа от диаграммы две сопоставленные плашки: крупная с надписью «Один разбор спора без журнала — 7 500 ₽» и маленькая с надписью «Хранение всего годового журнала — 47 ₽/мес». Под диаграммой строка: «Ограничение сверху задаёт не диск, а 152-ФЗ: дольше года хранятся только счётчики без персональных данных». Чертёжный стиль, подписи по-русски.
Разумные сроки хранения задаются не диском, а двумя другими соображениями. Снизу: вопросы про заявку приходят в течение квартала, а не недели — отсюда 90 дней быстрого поиска. Сверху: 152-ФЗ не разрешает хранить персональные данные дольше, чем требуется для цели обработки, — отсюда 12 месяцев на архив и удаление после. Всё, что нужно хранить дольше года, хранится в виде счётчиков: сколько операций, сколько отказов, сколько повторов по дням. Счётчики персональных данных не содержат и живут сколько угодно.
Что заказчик получает, кроме самих логов
Журнал, к которому есть доступ только у подрядчика, решает проблему подрядчика, а не вашу. Разница между «логи ведутся» и «журнал у вас есть» описывается четырьмя пунктами, и все они формулируются в договоре одной-двумя строками.
- Веб-интерфейс, а не доступ к серверу. Менеджер должен искать заявку через браузер по номеру и дате. Выдача сотрудникам доступа к серверу — это не решение задачи, а создание нового риска.
- Глубина поиска в договоре. Формулировка вида «журнал обменов доступен заказчику через веб-интерфейс, глубина оперативного поиска — 90 дней, архив — 12 месяцев». Без этого пункта глубина окажется равной трём дням в тот момент, когда она понадобится.
- Кнопка повторной отправки после исправления. Найти обрыв недостаточно: заявку надо доставить. Без кнопки переотправки каждый случай превращается в задачу подрядчику, то есть в счёт.
- Передача журнала при расставании. Журнал — ваши данные о ваших клиентах. Порядок его передачи и удаления у подрядчика описывается там же, где передача доступов при завершении проекта.
Когда журнал можно не покупать
Строка на 58 000 ₽ оправдана не всегда. Есть три случая, в которых мы сами предлагаем ограничиться упрощённым вариантом за 15 000–22 000 ₽: время, направление, номер заявки, статус — без тел запросов и без отдельного интерфейса.
- Меньше 300 операций в месяц. При таком потоке спорных случаев меньше одного в месяц, и разбор вручную по выгрузкам обходится дешевле, чем полноценный журнал с интерфейсом. Порог, ниже которого дешевле не строить контур, обсуждается в разделе бюджетов.
- Обмен идёт только справочными данными. Остатки, цены, курсы валют: каждое следующее обновление перезаписывает предыдущее целиком, потерянная запись не значит ничего, и восстанавливать по журналу нечего. Здесь достаточно отметки о времени последнего успешного обмена.
- Обе системы ваши, и в обеих уже есть свои журналы. Если 1С и склад пишут понятные логи и оба доступны вашим сотрудникам, добавлять третий журнал сверху смысла нет — достаточно завести сквозной идентификатор и научиться искать по нему в обеих системах. Это несколько часов работы, а не отдельная строка сметы.
Во всех остальных случаях действует простое правило: журнал покупается не для того, чтобы им пользоваться каждый день, а для того, чтобы он был в тот единственный день, когда клиент звонит и говорит, что оплаченный заказ никуда не поехал. В этот день выясняется, что 58 000 ₽ — это стоимость возможности ответить ему в течение дня, а не через неделю.
Спор двух подрядчиков решается не аргументами, а третьей записью — той, которую сделал получатель.
