Доработка 1С без сюрпризов: сценарии вместо описаний, приёмка

Кому и когда это нужно

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

Как это делается: 6 шагов

1. Назовите задачу одной фразой с результатом для бизнеса: «расход сверх лимита не проводится без согласования».
2. Выпишите роли: кто вводит, кто согласует, кто проводит, кто смотрит отчёт. Для каждой нужны свои права, см. статью про права доступа в 1С.
3. Для каждой роли опишите сценарий: что открывает, что вводит, какую кнопку нажимает, что должно произойти.
4. Добавьте граничные случаи: пустые данные, отмена проведения, повторное проведение, пользователь без права.
5. Запишите, где лежит доработка. Расширение переживает обновления лучше правки типовой конфигурации, причины в статье про расширения. Если расширением не выходит, подрядчик объясняет и согласует это до работы.
6. Договоритесь, что приёмка идёт по сценариям на копии базы, а оплата привязана к приёмке, как в статье про оплату этапами.

Шаблон сценария на полстраницы. Пример на условной доработке «лимит расхода», цифры условные.

• Сценарий 3, роль «прораб»: вводит требование-накладную, права проводить сверх лимита нет.
• Дано: лимит по материалу 100 шт, списано 90, в согласовании 0.
• Шаги: прораб вводит расход 20 шт и нажимает «Провести».
• Ожидается: проведение запрещено, сообщение «Превышение лимита на 10 шт», документ остаётся записанным, остаток лимита прежний.
• Граничные случаи: расход ровно 10 шт; пустая строка материала; повторное проведение после согласования; отмена проведения возвращает остаток.

Что записать в ТЗ

Инструменты и шаблоны: копия, версии, пакет

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

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

Каждая сборка получает номер версии. Замечания пишите списком: что сделали, что ждали, что получилось, снимок экрана. Исполнитель отвечает номером версии, где исправлено. У «Контроля материалов» версии прошли путь от 1.0.0 до 1.1.2, у палетного учёта для ТСД от 2.0.0 до 2.4.0. Замечания с проверки на сервере заказчика уходили в следующую версию.

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

Где ошибаются чаще всего

«Сделайте отчёт как раньше». Прежний отчёт знал один человек, теперь у каждого своё «как раньше». Приложите образец и пример чисел.

Нет тестовой базы. Проверяют на живой, и тестовый документ уходит в учёт.

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

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

Нет контроля версий и паспорта: через год непонятно, какая сборка стоит и что она трогает.

Где здесь поможет автоматизация

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

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

Сколько сценариев нужно на одну доработку?

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

Можно ли принять доработку без тестовой копии?

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

Сценарии написал программист. Это нормально?

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

Коротко о главном

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

Хотите, чтобы я разобрал вашу доработку, написал сценарии приёмки и проверил результат на копии? Напишите мне в Telegram слово «ТЗ1С».