Финансовый анализ кабинета Wildberries: как я создал движок для точного разбора данных

В процессе работы с финансовыми отчетами Wildberries (WB) я столкнулся с проблемой, когда итоговые суммы совпадали, но детализированные данные по артикулам оказывались неверными. Это побудило меня разработать собственный движок для анализа финансовых данных на Python с использованием библиотек pandas и openpyxl. Мой инструмент принимает на вход Excel-выгрузки и предоставляет результат по каждому артикулу, а также объясняет, куда ушли деньги.

Проблема с детализацией

На первый взгляд, совпадение итоговой суммы с отчетом WB может показаться достаточным для подтверждения правильности расчетов. Однако, как показала практика, это не всегда так. В детализации WB данные представлены в строках различных типов: строки продажи или возврата содержат информацию об артикулах, выручке, вознаграждении WB и сумме «К перечислению продавцу». В то же время строки логистики содержат только артикул и стоимость доставки. Другие расходы, такие как хранение и штрафы, не привязаны к конкретным артикулам, что создает сложности при анализе. Сумма по колонке может оставаться верной, даже если логистика или другие расходы неправильно распределены между артикулами. Это означает, что совпадение итогов не гарантирует корректности данных по каждому товару.

Два источника данных

Для проверки правильности расчетов я использую два источника данных: 1. Сводный еженедельный отчет от WB, который разбивает кабинет на статьи: продажи, логистика, хранение и другие удержания. Эти числа служат контрольными суммами. 2. Построчная детализация (обоснования для оплаты), из которой строится вся информация по артикулам. Каждая статья сводного отчета должна совпадать с ее агрегатом в детализации. Оба файла генерируются WB, что обеспечивает независимость в агрегировании данных. Сравнение позволяет подтвердить, что я правильно прочитал цифры WB, но не гарантирует, что начисления были выполнены без ошибок.

Независимость кода

В процессе разработки первой версии проверки я использовал тот же резолвер колонок и агрегаты, что и в основном расчете. Однако это создало риск, что переименование колонок может привести к ошибкам. Чтобы избежать этого, я изменил подход: теперь верификатор читает исходный файл .xlsx или .zip напрямую через openpyxl, без использования pandas. Это позволяет сопоставлять имена колонок только по точным совпадениям.

Как устроена сверка

Прием и обработка данных зависят от типа файла. В детализации присутствует «Тип документа», а в сводном — «Итого к оплате». Ключом для недели является дата начала. WB может предоставить два отчета за неделю: «Основной» и «По выкупам», которые необходимо суммировать. Дублирующие строки не учитываются повторно. В белом списке находятся имена для форматов на 73, 74, 82 и 83 колонках, что позволяет двигателю обращаться к колонкам только по имени. Сверка осуществляется в два прохода: сначала по точным совпадениям, затем по нечётким.

Суммирование и инварианты

Выручка и сумма «К перечислению» суммируются с учетом знака по «Типу документа»: продажи учитываются с плюсом, возвраты — с минусом. Остальные статьи берутся по своим колонкам. Итог недели восстанавливается по тождеству, где учитываются все статьи, кроме вознаграждения WB, которое уже вычтено из «К перечислению». Инварианты по артикулам включают:

Сумма выручки по артикулам равна «Продаже» сводного отчета.

Сумма «К перечислению» равна одноименной статье.

Сумма логистики равна логистике.

Остаток от WB (к перечислению минус логистика) равен «Итого к оплате».

Что считается расхождением

Допуск в сверке статей составляет одну копейку, в верификаторе — полкопейки. Если возникают расхождения, выводится список ошибок по неделям. Неполный сводный отчет не считается расхождением, а недели с меньшим количеством строк помечаются как «проверено только тождеством».

Примеры и ошибки

Рассмотрим пример с тремя артикулами за четыре недели. У ART-001 продажи составили 19 000,00 ₽, возврат — 1 000,00 ₽, а у ART-002 — 5 000,00 ₽. Итоговая сумма по товарам составила 13 300,00 ₽, а «К перечислению» — 10 740,00 ₽. Однако, если неправильно сложить выручку или учесть расходы, это может привести к ошибкам в расчетах.

Автоматизация и ручной контроль

Автоматизированные процессы включают определение типов файлов, сборку недель, разрешение колонок и сверку статей. Однако ручной контроль остается необходимым для анализа реальных архивов, так как конфиденциальные данные не попадают в автоматизированные системы. Я сам запускаю анализ на реальных отчетах и ожидаю, что расхождения будут равны нулю.

Заключение

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