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

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

Сначала я решил, что проблема в данных, которые мы забираем из 1С. И меня посетила абсурдная идея..

«Ладно, какой план вы считаете правильным?» - спросил я, и получил выгрузки из той же 1С, но с другим набором скважин. Странно, но ладно. Я остановился на том, что скрипт обмена планами с учетной системой и с dwh разный, поэтому есть расхождение (спойлер: это не так).

Примерно полгода я регулярно запрашивал у заказчика Excel-выгрузки из 1С с правильным планом - иногда до 20 файлов за раз. Написал обработку на Pandas, которая собирала эти файлы, вытаскивала нужные данные и загружала их в наш dwh (благо, шаблон был одинаковый).

Проблема в том, что даже этот вариант периодически переставал соответствовать ожиданиям. Почему-то тут тоже оказывалось, что скважин не хватало, причем теперь могла быть проблема и в плане, и в факте. В какой-то момент я понял, что дальше бессмысленно перепроверять код и переписывать загрузку - нужно разобраться, как сам план живёт внутри 1С. Я пошёл к специалистам по 1С и начал разбирать процесс уже вместе с ними.

Оказалось, что каждый заказчик работает со своим планом внутри своего сценария. Но конечные системы не работают напрямую с этими промежуточными планами. Для них существует отдельная сущность - «Оперативный план». Он формируется по определённым процессам, например раз в месяц, либо ответственный сотрудник может сформировать его вручную по кнопке. И вот здесь возникает интересный промежуток: один сотрудник уже внёс изменения в свой план, а второй ещё не перенёс их в оперативный. Для первого план уже изменился, а для конечных систем этих изменений пока не существует. Получается своеобразная «потеря данных» между двумя состояниями.

После этого стало понятно, почему мы могли бесконечно искать ошибку в загрузке и всё равно не находить её. Данные в базе могли быть абсолютно корректными. Система показывала не тот этап процесса, который в голове был у заказчика. В итоге я перестал воспринимать расхождение как автоматически техническую проблему и сначала стал проверять, дошли ли изменения до оперативного плана.

Мораль, которую я перекладываю на другие проекты такова: сначала убедиться в качестве исходников, потом переделывать код.

А как вы чинили не в том месте, где была проблема?