Откуда взялась эта сумма

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

Начните с конкретного числа и контекста

Сначала попросите пользователя назвать место, где видна сумма, период или объект, к которому она относится, и действие непосредственно перед появлением результата. Уточните, ожидает он начисление, оплату, остаток или итог за несколько периодов. Эти слова часто звучат похоже, но отвечают на разные вопросы. Запишите известные входные значения и момент наблюдения; неизвестное пока пометьте как вопрос.

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

Проследите цепочку, не перескакивая к формуле

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

Запрос к LEM стоит сделать предметным и ограничить объектом, сценарием и вопросом:

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

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

Отличайте состав суммы от момента её учёта

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

Например, начислено 3000 рублей, за тот же период поступило 1200, ожидаемый остаток после учёта оплаты — 1800. Сначала выясните, не включает ли исходное поле уже эту оплату: иначе она будет вычтена дважды.

Сравните расчёт с наблюдаемыми данными

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

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

Зафиксируйте вывод и следующий вопрос

Короткое объяснение удобно строить так: исходные значения; найденный путь их отбора и преобразования; подтверждённое правило; точка, которую ещё нужно проверить; ожидаемый результат для конкретного набора данных. Если источник не раскрывает условие, напишите «не найдено в доступных материалах», а не заполняйте пробел догадкой.

Для случая, где остаток родительской платы не уменьшился на поступившую оплату, см. разбор поиска типовой возможности в БГУ. Он показывает, как команда исследовала типовой механизм до обсуждения доработки. Общий маршрут аналитика собран в материале «Как аналитику работать с LEM»; отделять найденное правило от ожидания помогает статья «Найденное правило и требование — не одно и то же».

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