# Данные лежат в разных системах: как собрать из них один отчёт

Отчёт из трёх систем отнимает день в неделю. Разбираю, зачем нужен эталон, как собрать словарь соответствий и почему периоды хранят списком дат.

URL: https://posts.danashkin.ru/guides/dannye-v-raznyh-sistemah-odin-otchet
Обновлено: 2026-09-13

---

## Коротко

**Главное**

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

## Почему регулярный отчёт съедает день в неделю?

**Главное**

Потому что данные лежат в разных системах с разной логикой. Веб-аналитика считает по своему часовому поясу, база отдаёт сырые строки, партнёр присылает файл в свободной форме. Человек тратит время не на выводы, а на стыковку.

Знакомая картина: каждую неделю нужно собрать отчёт. Цифры посещаемости - из счётчика на сайте. Заявки - из базы. Данные партнёра - файлом на почте. Дальше всё это сводится в одну таблицу руками, и на это уходит рабочий день.

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

Я собирал такой контур для регулярной отчётности маркетингового агентства: три источника, недельная сетка, готовая книга-шаблон, куда пишутся значения. Расскажу, что там оказалось настоящей сложностью, потому что она не там, где её ждут.

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

## С чего начинать: эталон вместо технического задания

**Главное**

Нужен уже сданный, проверенный человеком период. Если расчёт воспроизводит его до единицы, дальше расчёту можно верить. Без эталона первый отчёт - гадание, и проверить его нечем.

Это правило я выучил на живом проекте, и оно экономит недели.

Прежде чем поручать сборку агенту, возьми один период, который уже закрыт и сдан. Тот, где числа проверял человек и заказчик их принял. Это твой эталон.

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

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

**Что делать, если эталона нет**

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

## Что спросить у каждого источника?

**Главное**

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

Списком, который стоит пройти до того, как писать первую строчку кода:

| Что уточнить | Почему это важно |
|---|---|
| Способ доступа: выгрузка, база, ключ доступа | от этого зависит, можно ли вообще автоматизировать |
| Часовой пояс и фильтры | счётчик может считать без роботов или со всеми, и цифры разойдутся |
| За период или нарастающим итогом | вторая неделя в нарастающем файле - это не вторая неделя |
| Кто и в каком виде присылает файл | человек в отпуске - и данные приходят в другом формате |
| Пускает ли источник с адреса, где идёт расчёт | база вполне может резать сторонние подключения |

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

Проверять это надо запросом, а не устным подтверждением. Фраза «да, доступ есть» и живой ответ сервера - разные вещи, и расходятся они регулярно.

Если у нужной системы вообще нет программного доступа, это не тупик: подробно разбирал варианты в материале про то, [как забрать данные, когда у площадки нет API](/guides/u-sayta-net-api-kak-zabrat-dannye).

## Словарь соответствий: главная работа проекта

**Главное**

Категории в источнике и в отчёте почти никогда не совпадают дословно. Нужна таблица соответствий, где каждое значение из системы привязано к строке отчёта, плюс правило приоритета для строк, подходящих под несколько категорий.

Вот место, где ломается большинство попыток.

В базе причины отказа записаны так, как их формулировал оператор. В отчёте у заказчика они названы своими словами. На моём проекте они не совпали ни одним словом. Ни одним - при том, что смысл был тот же самый.

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

Что должно быть в этом словаре:

1. **Полный список значений из источника**

   Не по памяти, а выгрузкой всех уникальных значений за большой период. То, что встречается раз в квартал, всплывёт именно тогда, когда тебя не будет рядом.

2. **Соответствие каждой строке отчёта**

   Одно значение - одна строка. Не подходит ни к одной - заводи явную категорию «прочее», а не оставляй пустоту.

3. **Правило приоритета**

   Если строка подходит под две категории сразу, укажи, какая выигрывает. Иначе результат будет зависеть от порядка обработки, а он однажды поменяется.

4. **Что делать с незнакомым значением**

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

Этот словарь - и есть та часть знания, которая раньше жила в голове человека, собиравшего отчёт. Автоматизация начинается с того, что ты её достаёшь и записываешь.

## Где число живёт в двух местах

**Главное**

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

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

Дальше происходит худшее из возможного: отчёт уходит, и расхождение внутри одного документа находит заказчик.

Что с этим делать:

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

Проверка «сходятся ли числа между собой» - это тот же принцип приёмки, о котором писал в материале про [проверку работы ИИ-агента без технического бэкграунда](/guides/kak-proveryat-ai-kod-bez-teh-bekgraunda). Машина проверяет то, что человек проверял бы глазами и однажды пропустил.

## Периоды: список дат вместо правила

**Главное**

Границы периодов надо хранить явным списком дат, а не формулой «каждые семь дней». Сетка периодов переезжает по решению заказчика, и правило, зашитое в расчёт, начинает тихо считать не то.

Случай из практики. Отчётность идёт по неделям. Первая неделя сдана, всё сходится. После этого заказчик переопределяет границы следующих периодов: у него поменялись условия акции.

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

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

Ещё пара мелочей того же семейства: одна неделя в году бывает длиннее семи дней, а «месяц» у финансистов и маркетологов иногда начинается в разные дни.

## Как поставить эту задачу агенту?

**Главное**

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

Порядок, который работает:

1. **Опиши источники словами.** Что откуда берётся, в каких единицах, за какой период. Это и есть половина задачи.
2. **Дай эталон.** Файл с числами, которые должны получиться. Прямо скажи: результат должен совпасть с ним полностью.
3. **Двигайся по одному источнику.** Первый подключён и сверен - берём второй. Так место поломки всегда очевидно.
4. **Отдельным шагом - запись в форму.** Расчёт и запись в чужую книгу - разные задачи, и вторая ломает документы чаще.
5. **Попроси отчёт о расхождениях.** Не «всё сошлось», а таблица: где сошлось, где нет и на сколько.

[Агент](/concepts/ai-agent) хорошо справляется с этой работой при одном условии: у него есть, с чем сверяться. Без эталона он тоже выдаст результат - уверенный и правдоподобный, и проверить его будет нечем.

Про то, как связать собранные данные с презентацией, чтобы отчёт не пересобирали руками каждый раз, писал отдельно в материале про [живые графики вместо картинок](/guides/zhivye-grafiki-vmesto-kartinok).

## Частые вопросы

**Главное**

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

### Частые вопросы

**Нужна ли для этого база данных?**

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

**Сколько занимает первая сборка?**

Основное время уходит не на код, а на выяснение договорённостей: словарь категорий, границы периодов, что считается принятым. Практический ориентир - несколько вечеров при готовом эталоне.

**Коллеги правят отчёт руками. Как быть?**

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

**Реально ли собрать это без программиста?**

Реально, если сложность в договорённостях, а не в нагрузке. Когда появляются десятки тысяч записей в час или чужие персональные данные, зовите специалиста хотя бы на проверку.

## Главный вывод

**Главное**

Сборка отчёта из разных систем - задача не про выгрузку, а про согласование. Эталон, словарь соответствий и явный список периодов закрывают почти все места, где такие проекты разваливаются.

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

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

Посмотри на свой регулярный отчёт. Если завтра его будет собирать другой человек, какие договорённости он не сможет угадать?

### Источники

- [Extract, transform, load - как устроен перенос данных между системами, Википедия](https://en.wikipedia.org/wiki/Extract,_transform,_load)
- [Single source of truth - принцип единственного места для значения, Википедия](https://en.wikipedia.org/wiki/Single_source_of_truth)
- [Data cleansing - обзор подходов к очистке и согласованию данных, Википедия](https://en.wikipedia.org/wiki/Data_cleansing)
- [Comma-separated values - формат выгрузок и его подводные камни, Википедия](https://en.wikipedia.org/wiki/Comma-separated_values)