Как принять отчёт по заказам, оплатам и позициям
Перед решением по отчёту полезно сверить его на небольшом наборе с заранее известным ответом. Возьмём три учебных заказа и подготовим проверку вместе с оплатами и составом. Такой набор можно передать специалисту до разбора рабочих данных.
Какое решение нужно принять владельцу
В отчёт добавили историю оплат, а сумма заказов выросла. Прежде чем обсуждать рост продаж, попросите показать состав результата. В документации Looker разобрана такая ошибка: соединение заказа с несколькими позициями повторяет сумму заказа в строках результата. Это называют fanout. Объяснение Looker.
Задача владельца здесь — принять конкретный отчёт по заранее известным контрольным данным. Он не обязан выбирать SQL-конструкцию. Достаточно согласовать, что считается заказом, какой итог ожидается и какие изменения детализации не должны этот итог менять. Исправление способа расчёта поручают аналитику или разработчику.
Ниже считаем согласованные суммы заказов и зарегистрированные оплаты в одной условной валюте. Это учебная сверка данных, без налогов, возвратов и правил бухгалтерского признания выручки. Распределение вклада между менеджерами — другая задача; оно уже разобрано в руководстве по командным продажам.
Сначала соберите маленький набор с известным ответом
Все записи вымышлены. Есть три заказа: O1 на 120, O2 на 120 и O3 на 80. У O1 две оплаты P1 и P2 по 60; у O2 одна P3 на 120; у O3 оплат пока нет. Полнота учебного реестра подтверждена: отсутствие платежа O3 здесь известно, а не вызвано пропущенной выгрузкой.
Состав заказа также задан полностью. У O1 две позиции L1 на 50 и L2 на 70; у O2 одна L3 на 120; у O3 одна L4 на 80. Позиции уже содержат согласованные суммы строк, поэтому количество товара повторно не умножаем.
До любого соединения контроль таков: три заказа на 320, три платежа на 240, четыре позиции на 320. Два разных заказа имеют одинаковую сумму намеренно. Третий заказ не оплачен намеренно. Без этих двух случаев ошибочная настройка может пройти слишком удобную проверку.
Почему четыре строки не означают четыре заказа
При соединении по ID заказа каждая подходящая запись справа образует строку результата. LEFT JOIN дополнительно сохраняет заказ без совпадения, оставляя поля оплаты пустыми. INNER JOIN такой заказ не сохраняет. Это документированные правила PostgreSQL, а не описание настроек любой CRM.
Для нашего LEFT JOIN получатся пары O1–P1, O1–P2, O2–P3 и O3–без оплаты. В столбце суммы заказа теперь стоят 120, 120, 120 и 80. Их сумма — 440. Заказов по-прежнему три, исходный итог — 320; дополнительные 120 появились при расчёте результата, а не в новых продажах.
Если заменить соединение на INNER JOIN, останутся три строки и сумма 360. Само число строк выглядит правильным, но уникальных заказов только два: O3 исчез. Поэтому проверка «строк столько же, сколько заказов» недостаточна. В контрольном листе отдельно сверяйте набор ID и итог.
O1 · 120
O2 · 120
O3 · 80
Вымышленные записи. Суммы в одной условной валюте; новый заказ не создавался.
Почему удаление одинаковых сумм даёт другую ошибку
В PostgreSQL DISTINCT внутри агрегата оставляет различные значения выражения. Поэтому SUM(DISTINCT сумма_заказа) различает суммы, а не заказы. Определение агрегатов.
В нашем результате разные числовые значения только 120 и 80. Получится 200 вместо 320: законная сумма второго заказа потеряется вместе с повторениями первого. Два заказа по 120 нельзя превращать в один лишь из-за равенства денег. Проверяемую единицу определяет ID заказа.
Не удаляйте строки первичных платежей ради красивого итога. P1 и P2 — две самостоятельные оплаты. Проблема находится в представлении и агрегации; исправление отчёта не должно уничтожать подтверждённые операции. Это отдельное условие приёмки предложенного решения.
Что произойдёт после добавления ещё одной детализации
Теперь к заказам слева присоединили и оплаты, и позиции, каждый раз только по ID заказа. У O1 образуются четыре сочетания: P1–L1, P1–L2, P2–L1, P2–L2. У O2 и O3 будет по одной строке; всего шесть. Такая модель не задаёт, какая оплата относится к конкретной позиции.
Наивные суммы уже расходятся в нескольких столбцах: заказы — 680, оплаты — 360, позиции — 440. Контрольные значения остаются 320, 240 и 320. Проверять только заказный итог недостаточно: удачное исправление одного показателя ещё не принимает остальные.
Для этой учебной задачи можно сначала отдельно получить по одному итогу оплат и позиций на заказ, затем присоединить эти два результата к трём исходным заказам. Проверочный расчёт возвращает 320 / 240 / 320. Но он рассчитан на уровень заказа: детализацию по конкретной позиции или платежу надо проектировать отдельно.
Не переносите одно техническое решение на все системы
Looker документирует symmetric aggregates: корректность зависит от уникального первичного ключа и правильно заданной связи. Наличие названия функции само по себе не подтверждает, что конкретная модель настроена верно. Условия Looker.
Для Power BI Microsoft обычно рекомендует связывать таблицы фактов через измерения со связями «один ко многим», а не напрямую «многие ко многим». В документации отдельно оговорены ограничения фильтрации и риск пропуска строк при нарушенной целостности данных. Рекомендации Microsoft.
Связь модели Power BI и физическое SQL-соединение — разные механизмы. Не требуйте заменить все связи одной конструкцией по этому примеру. Попросите специалиста объяснить выбранный способ, его уровень детализации и результат контрольного набора. Если отчёт нужен по товару, суммировать целый заказ в каждом товарном разделе без отдельного правила нельзя.
Как принять исправление без доступа к рабочим платежам
Передайте специалисту учебные записи и ожидаемые результаты отдельным файлом. Сохраните названия показателей, выбранный период, валюту и фильтры. Первый прогон выполняйте на копии или тестовом наборе. Для проверки расчёта не нужны настоящие клиенты, номера карт или изменение финансовых операций.
Попросите показать три вида отчёта: только заказы; заказы с оплатами; заказы с оплатами и позициями. Во всех вариантах, предназначенных для одной и той же базы заказов, проверьте присутствие O1, O2 и O3. При добавлении отдельного фильтра ожидаемый состав надо согласовать заново.
Запишите фактический результат каждого показателя и приложите раскрытие до исходных ID. Затем измените в тесте только одну сумму заказа и соответствующую позицию, заранее вычислите новый контроль и повторите проверку. Такой прогон помогает заметить исправление, подогнанное под единственный набор.
В отчётности SABSUS используйте этот набор как требование к конкретной конфигурации. Автоматическую защиту от повторного учёта или готовый способ соединения здесь не обещаем. Результат приёмки — воспроизводимая сверка и объяснение каждого показателя, которое сохраняется при согласованной детализации.
Источники и продолжение
Источники проверены 17 октября 2026 года. Записи и результаты учебные. Арифметика воспроизведена отдельно; системы Looker, Power BI и SABSUS на этих данных не испытывались.