B11 · 24.10 · GD: автор и время удаления PAYMENT

Главная · Все таблицы · Исследования

B11 — Удаление оплаты при получении и учётная запись обмена 1С

Все 1 982 удаления оплаты из B10 выполнены под USER_ID=67667. В действующей админке 24.10.2026 у этой записи проверен логин 1c_exchange. Удаление происходит в первую зафиксированную секунду обработки заказа этим пользователем и одновременно с удалением отгрузки. В 1 970 случаях в ту же секунду статус меняется «Новый → Подтвержден». Это связывает действия с учётной записью обмена с 1С, но не определяет конкретный запрос, настройку или участок кода, вызвавший удаление.

Источник: локальная B4, снимок 22.10.2026, плюс адресный просмотр одной карточки автора в админке 24.10. Основной сегмент: Gerard Darel / s4, заказы, созданные 01.01–30.09.2026 включительно, текущие статус F, PAYED=N, PAY_SYSTEM_ID=2. Множество 1 982 ID точно совпало с B10. История рассматривается до даты снимка; отдельные события когорты сентября произошли в октябре.

Когда это происходит

Минимальная задержка — 37 секунд. 90-й перцентиль по нижнему эмпирическому рангу — 54 минуты 42 секунды; максимальная задержка — 25 дней 3 часа 50 минут 56 секунд. Это не гарантированный регламент обмена: фактические интервалы событий сохранённой выборки.

Медиана от удаления оплаты до первого статуса «Доставлен» — 3,80 дня. В 1 927 случаях удаление строго раньше первого «Отправлен»; в остальных 55 такой переход в сохранённой истории отсутствует. Поэтому история не поддерживает объяснение, что это массовая очистка оплат после доставки или выкупа.

Какие изменения идут рядом

Количество уникальных заказов с соответствующим событием в ту же секунду, что PAYMENT_REMOVE:

В 1 865 событиях изменения суммы в ту же секунду сумма заказа уменьшается на 350 ₽. Это дополнительный признак пакетного обновления заказа; не вывод о потере денег или стоимости реального выкупа. Совпадение секунд не доказывает один HTTP-запрос или одну транзакцию БД.

У 10 заказов переход в «Подтвержден» записан позже удаления оплаты, ещё у 2 такого перехода нет. До удаления ни у одного из 1 982 нет более раннего сохранённого события смены статуса. У всех сейчас заполнены ID_1C и XML_ID; текущие поля не доказывают момент их заполнения.

Реальный пример последовательности, без данных покупателя

Один из заказов январской когорты:

1. 01.01, 22:27:38 — заказ и оплата при получении созданы.
2. 01.01, 22:54:39, автор 67667 — удалены отгрузка и оплата; сумма 93 090 → 92 740 ₽; статус «Новый → Подтвержден».
3. 05.01, 18:29:58, тот же автор — «Подтвержден → Отправлен».
4. 06.01, 10:32:26, тот же автор — «Отправлен → Доставлен».

Порядок событий внутри одной секунды по ID не трактуется как доказанный порядок вызовов кода. В данном примере оплата исчезла более чем за четыре дня до статуса доставки.

Контроль вне доставленных

В той же когорте сайта есть 3 187 событий PAYMENT_REMOVE у 3 187 заказов. Все — под 1c_exchange, все — у заказов с текущим способом «Оплата при получении». По текущим статусам:

Всего текущий способ оплаты при получении указан у 3 191 заказа; у 4 событий удаления в сохранённой истории не найдено. У остальных 2 975 заказов когорты с иными/пустыми текущими способами PAYMENT_REMOVE не найден. Это текущая классификация; прежние изменения способа оплаты не реконструированы для всех контрольных заказов. Вывод ограничен данной когортой GD, не всеми сайтами и периодами.

Что установлено, а что ещё нет

В PAYMENT_REMOVE сохранены только ID, ORDER_ID, TYPE, ENTITY/ENTITY_ID, USER_ID, DATE_CREATE/DATE_MODIFY и DATA со способом оплаты. URL запроса, файл обмена, стек вызова и идентификатор транзакции в этом источнике отсутствуют. Логин проверен сейчас; историческое переименование учётной записи и исключительное использование её реквизитов только 1С отдельно не проверялись.

Чтобы установить техническую причину, достаточно начать с одного известного окна — 01.01.2026 22:54:39 МСК, затем подтвердить на нескольких заказах: сопоставить серверный журнал обмена/HTTP-запрос, входные данные заказа и соответствующий обработчик удаления PAYMENT/SHIPMENT. Нужны сохранённые логи или код и настройки обмена только для чтения. При недоступности старых логов точную причинную цепочку из этой выгрузки восстановить нельзя; новый тест обмена на реальных заказах не запускался.

Решение: уточнить у владельца обмена правило удаления оплаты при получении и механизм дальнейшего учёта денег. ASK-0008 дополнен (../../questions.md#ask-0008), не отправлен. Технические изменения и пересчёт финансового выкупа пока не обоснованы.

Проверка и материалы

17 проверок без расхождений: точное множество B10, кратность удалений, автор, временные разбиения, совпадение секунд, связь с доставкой, независимые SQL/Python-агрегаты, контроль текущих ID_1C/XML_ID и браузерное подтверждение логина.

Внешняя проверка ограничена просмотром одной карточки пользователя существующим доступом: параметры и пароли не менялись, авторизация от его имени не выполнялась, кнопки сохранения не нажимались. Исходная открытая вкладка заказов оставлена без изменений. Новых внешних API-запросов, SQL рабочей админки и массовой выгрузки не было.

Агрегаты и проверки (summary.json) · SQL (diagnostic.sql) · Скрипт (../../tools/analyze_gd_payment_removal.py) · Подтверждение автора (../../sources/bitrix/2026-10-24-payment-actor/actor.json).

Логин автора в действующей админке (../../sources/bitrix/2026-10-24-payment-actor/login-row.png)

Подробные ID и временные цепочки — только в private/bitrix-diagnostics/2026-10-24-gd-payment-removal-history/chronology.json. Контакты покупателей и произвольные комментарии не извлекались; полная карточка пользователя с контактами/сессионными ссылками не сохранялась.

Источник: analysis/2026-10-24-gd-payment-removal-history/report.md.