Как принимать программное обеспечение в 1С

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

Главная проблема приёмки в 1С — проверяющий часто не знает, что именно проверять. Разработчик показывает «работающий» сценарий на своих тестовых данных, заказчик подписывает акт, а через неделю выясняется, что обработка падает на реальных документах, портит проводки или конфликтует с обновлением конфигурации. Чтобы этого не произошло, приёмку нужно строить по формальной процедуре: от критериев в техническом задании до контрольного прогона на копии рабочей базы.

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

Подготовьте критерии приёмки до начала проверки

Приёмка невозможна без эталона, с которым сравнивается результат. Таким эталоном служит техническое задание или хотя бы письменное описание задачи в переписке. Если доработка делалась «по устной договорённости», первый шаг — зафиксировать требования постфактум и согласовать их с исполнителем, иначе спор о том, «входило это в объём работ или нет», не решить.

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

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

Поднимите тестовую среду и запретите приёмку в рабочей базе

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

Для файловой базы копия создаётся через выгрузку в dt (Конфигуратор → Администрирование → Выгрузить информационную базу) или простым копированием файла 1Cv8.1CD при остановленной работе пользователей. Для клиент-серверной базы копию обычно делает администратор через средства СУБД. Проверьте, что копия открывается, пользователи и права работают, а внешние обработки и расширения на месте.

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

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

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

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

Каждый результат фиксируйте сразу: скриншот, номер документа, текст ошибки. Формулировка «вроде вчера не работало» не даёт исполнителю ничего, а «при проведении реализации № 1234 от 15 числа возникает ошибка деления на ноль, скриншот прилагается» — позволяет исправить дефект за один цикл.

Что проверить в доработках документов и проведения

Если менялась логика проведения, сравните движения документа до и после доработки: откройте движения по регистрам на тестовой базе со старым кодом (если есть эталонная копия) и с новым. Суммы, количества и набор регистров должны отличаться только в той части, которая предусмотрена заданием. Любое «побочное» изменение движений — дефект.

Что проверить в отчётах

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

Контрольные точки

Как проверить результат

Движения документа после доработки

Норма

Изменились только те регистры и суммы, которые указаны в задании

Тревожный признак

Появились лишние записи, изменились суммы несвязанных регистров

Повторный запуск обработки

Норма

Результат идемпотентен: дублей и задвоения данных нет

Тревожный признак

Каждый запуск создаёт новые записи или дубли документов

Работа под ограниченными правами

Норма

Функция доступна тем ролям, которым предназначена, остальным отказано корректно

Тревожный признак

Ошибка доступа или, наоборот, доступ у всех подряд

Итоги отчёта

Норма

Сходятся с типовым отчётом или ОСВ на тех же данных

Тревожный признак

Расхождения без объяснимой причины

Проверьте влияние на обновление и смежные механизмы

Доработка, которая работает сегодня, но блокирует обновление конфигурации завтра, — скрытый долг. Если изменения внесены в типовые объекты конфигурации (а не вынесены в расширение), уточните у исполнителя, как будет проходить обновление на новый релиз. Современная практика — реализовывать доработки через расширения конфигурации, не снимая основную конфигурацию с поддержки.

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

Отдельно оцените производительность, если доработка работает с массовыми данными. Обработка, выполняющаяся 2 минуты на 100 документах тестовой базы, может занять часы на миллионе записей рабочей. Для таких случаев закладывайте в критерии приёмки замер времени на объёме, близком к реальному.

Оформите замечания и организуйте итерации исправлений

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

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

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

1. 1
   Сформулируйте проверяемые критерии приёмки на основе ТЗ и зафиксируйте их документом
2. 2
   Сделайте свежую копию рабочей базы и разверните на ней доработку
3. 3
   Прогоните все сценарии, включая граничные случаи и права доступа
4. 4
   Сверьте цифры с независимым источником и проверьте влияние на смежные процессы
5. 5
   Зафиксируйте замечания письменно, получите исправления, проведите повторную проверку
6. 6
   Подпишите акт и перенесите доработку в рабочую базу после резервного копирования

Перенесите результат в рабочую базу и подпишите акт

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

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

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

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

Частые вопросы о приёмке ПО в 1С

Можно ли принимать доработку без технического задания?

Можно, но рискованно. Минимальный вариант — письменно зафиксировать в переписке, что именно должно работать, и согласовать это с исполнителем до начала проверки. Без зафиксированных требований любой спор о «недоделках» превращается в спор мнений.

Кто должен проводить приёмку, если в компании нет программиста 1С?

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

Что делать, если после подписания акта нашлась ошибка?

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

Обязательно ли требовать перенос доработок в расширение конфигурации?

Не всегда, но желательно. Расширение сохраняет возможность обновлять типовую конфигурацию штатно. Изменения типовых объектов оправданы там, где расширение технически не может решить задачу, — тогда заранее обсудите с исполнителем порядок и стоимость сопровождения при обновлениях.

Сколько времени должна занимать приёмка?

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

Что делать, если исполнитель отказывается исправлять замечания?

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