Разбираем заявку на выплату

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

Это учебная модель «Заявка на выплату», а не описание реальной конфигурации: назначение обязательно для «Оплаты услуг», а для согласования нужны один человек до 100000 рублей и два — от этой суммы. Есть также операция «Возврат средств».

1. Уточняем вопрос

Аналитик не начинает с предложения «покажите код». Он просит описать последний конкретный случай: какая операция была выбрана, какая сумма указана, что заполнили, на какой кнопке остановились и что увидели после этого. Допустим, сотрудник отвечает: «Выбрал оплату услуг, написал назначение, переключил на возврат, потом снова выбрал оплату услуг — и получил сообщение, что поле пустое».

Уточняем, не редактировал ли кто-то заявку, на каком шаге появилось сообщение и открывали ли карточку повторно. Пока известна последовательность со слов сотрудника: поле отображалось заполненным, а затем появилось сообщение о пустом значении. Одна из версий — введённое значение не сохранилось в документе; проверим её по сведениям о форме и реквизите.

2. Исследуем доступные сведения

Попросим LEM найти контекст операции, поля и их связь с данными документа, а затем подскажем, что уточнить:

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

Из найденных сведений становится понятнее, как правило связано с операцией и где соотносятся поле формы и реквизит документа. Теперь проще составить проверку на переключение: значение на экране должно пережить смену операции и повторное открытие заявки.

3. Формулируем требование

Аналитик возвращается к владельцу процесса с кратким объяснением и уточняющими вопросами: должно ли назначение сохраняться при смене операции? При возврате пустое поле допустимо; что должно произойти, если пользователь переключился обратно на оплату? Должна ли система очистить значение, сохранить его или попросить заполнить заново? В какой момент показывать сообщение — при переключении, сохранении или отправке на согласование?

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

4. Проверяем путь в тестовой базе

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

Повторите этот путь в тестовой базе 1С; для автоматизированного прогона используйте отдельно настроенный Vanessa Automation MCP. Запишите исходные данные, последовательность действий и то, что увидели после повторного открытия, чтобы коллега мог воспроизвести проверку.

Порог согласования проверяем отдельно от назначения: сумма 99999 рублей должна дать одного согласующего, 100000 рублей — двух, 100001 рубль — также двух. Значение на границе важно: именно там часто обнаруживается неясность формулировки «от ста тысяч». Если сумма меняется после начала согласования, потребуется дополнительное решение владельца процесса.

5. Разделяем выводы

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

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

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