«Ничего не работает» или «отчёт врёт» — такие заявки возвращаются с уточняющими вопросами, а исправление растягивается на дни. Разбираем, как описать проблему программисту 1С так, чтобы он воспроизвёл её с первого раза: три опоры заявки, шаги воспроизведения, текст ошибки и готовый шаблон.
Почему «ничего не работает» — дорогая формулировка
Бухгалтер и программист говорят на разных языках: первый знает учёт, но не пишет код, второй пишет код, но не знает всех нюансов учёта. Задачу «сделайте как надо» каждая сторона понимает по-своему, и разрыв выясняется уже после сдачи работы.
Дальше программист делает три вещи подряд: задаёт уточняющие вопросы, ищет нужный документ среди тысяч похожих и пытается воспроизвести проблему наугад. В практике тестирования этот сценарий описан давно: отчёт об ошибке без шагов воспроизведения возвращается с вопросом «как повторить?», и вместо часа работы получается несколько дней переписки.
Способы сообщить о проблеме знакомы любой поддержке: звонок руководителю, фото экрана в мессенджер, письмо, где из полезного — только скриншот. В таком виде программист получает головоломку вместо задачи. Хорошее описание — часть исправления, а не бюрократия.
Три опоры заявки: симптом, доказательство, эталон
Перед тем как писать, соберите проблему на трёх опорах. Это дисциплинирует и нередко закрывает вопрос без участия программиста.
- Симптом. Что именно происходит, в каком документе или отчёте, при каком действии. Не «отчёт врёт», а «в отчёте по остаткам на складе „Основной“ минус по позиции кабеля».
- Доказательство. Почему вы считаете это ошибкой: правило учёта, пункт нормативного документа, прежнее поведение программы или указание главбуха. Нередко на этом шаге выясняется, что программа права, а ожидание было ошибочным — тогда вопрос идёт к методологу, а не к разработчику.
- Эталон. Контрольный пример: документ и цифры, которые показывают правильный результат. «Должно быть правильно» — не эталон; «по инвентаризационной описи от 31.10 — 8 штук» — эталон.
Если эталона нет, запросите его у главбуха до отправки заявки. Если спор о правилах учёта — укажите пункт документа: программист не должен искать основание сам.
Часть «ошибок» оказывается проблемами данных: дубли в справочниках, неверные реквизиты, непроведённые документы. Проверьте данные до заявки — обработка «Сравнение данных документов и справочников» показывает расхождения между документами и справочниками, а почему дубли обходятся дорого — в статье «Дубли в справочниках 1С».
Костяк описания: заголовок, шаги, факт, ожидание
Практика описания ошибок в разработке ПО выработала стандартный костяк — он подходит и для 1С:
- Заголовок. Одна строка на вопросы «что, где, когда»: «При проведении реализации от 31.10 ошибка „Поле объекта не обнаружено“».
- Шаги воспроизведения. Нумерованный путь от понятного старта до ошибки, с конкретными значениями: раздел, документ, кнопка.
- Фактический результат. Что программа сделала: текст сообщения, неверная цифра, поведение.
- Ожидаемый результат. Что должно было произойти и почему: правило, нормативный документ или контрольный пример.
Три правила делают костяк рабочим. Пройдите шаги заново с чистого листа перед отправкой — это ловит пропущенные действия. Не дробите каждое движение мыши в отдельный пункт, но избегайте двусмысленности: «нажать кнопку» плохо, «нажать „Провести и закрыть“» хорошо. И одна заявка — одна проблема: несколько ошибок в одной карточке застревают, пока не починят все.
Если проблема плавающая, укажите частоту: «примерно в одном случае из пяти» полезнее, чем «иногда». Для плавающих сбоев приложите короткую запись экрана — она заменяет десяток уточняющих вопросов.
Критичность и срочность — разные вещи
В практике тестирования давно разделяют серьёзность сбоя и срочность исправления: это разные оценки, и они не обязаны совпадать. В заявке программисту 1С опишите обе человеческими словами.
- «Отгрузки остановлены, обходного пути нет» — высокая критичность: система не выполняет ключевую функцию.
- «Опечатка в шапке счёта, но завтра отправка крупному клиенту» — система работает, а срочность высокая.
Такое разделение помогает программисту выстроить очередь, а вам — получить исправление важного раньше остального.
Специфика 1С: окружение, текст ошибки, скриншоты
Инструкции сервисных компаний для пользователей разбирают несколько приёмов, специфичных для 1С.
- Точные имена объектов — как в базе. «Реализация товаров и услуг», а не «накладная»; «Контрагенты», а не «клиент». Смотрите, как называются пункты меню и виды документов.
- Номер и дата документа, код элемента справочника. В большой базе найти «вчерашнюю накладную на Ромашку» нереально; ссылка на объект решает проблему за один клик.
- Окружение. Конфигурация и релиз, версия платформы, имя пользователя, под которым возникает ошибка: под разными правами и на разных релизах одно действие ведёт себя по-разному.
- Текст ошибки — не только картинка. В окне ошибки откройте «Подробно» и скопируйте текст через
Ctrl+AиCtrl+C. В свежих релизах полный текст спрятан за ссылкой отчёта об ошибке — включите флажок подробного текста или загляните в «О программе» → «Информация для технической поддержки». - Скриншоты окон целиком. Не фото экрана телефоном: окно ошибки, окно «Обнаруженные ошибки», служебные сообщения внизу экрана.
Рис. 1. Окно ошибки с кнопкой «Подробно»: скопируйте текст ошибки, а не только скриншот.
Рис. 2. «О программе» → «Информация для технической поддержки»: версия платформы, релиз конфигурации и текст ошибок.
Добавьте контекст: что менялось перед появлением проблемы — обновление конфигурации, установка расширения (.cfe), загрузка данных. Если вопрос в том, кто менял документ, ответ даст журнал регистрации — как его читать, разбирали в статье «Как через журнал регистрации узнать, кто работал с документом».
Одна и та же проблема — два описания
Пример условный: подставьте свои объекты и цифры.
| Элемент | Плохо | Хорошо |
|---|---|---|
| Заголовок | «Остатки кривые, срочно!!!» | «Отчёт „Остатки товаров на складах“: минус по кабелю ВВГ на складе „Основной“ на 31.10.2026» |
| Шаги | «Зашла в отчёт, там ерунда» | 1. Склад → Остатки товаров на складах. 2. Период 01.10–31.10.2026, склад «Основной». 3. Сформировать. |
| Фактический результат | «Цифры не те» | Строка «Кабель ВВГ 3×2,5»: остаток −12 шт. |
| Ожидаемый результат | «Должно быть правильно» | Остаток неотрицательный; по инвентаризационной описи от 31.10 — 8 шт (контрольный пример приложен). |
| Окружение | — | Бухгалтерия предприятия 3.0, релиз и платформа из «О программе», пользователь «Бухгалтерия». |
| Вложения | Фото экрана в мессенджер | Скриншот отчёта целиком, ссылка на документ списания, текст ошибки. |
Шаблон заявки и кто его заполняет
- Заголовок: что сломалось, где и при каком действии.
- Шаги воспроизведения: нумерованные, с точными названиями и значениями.
- Фактический результат: что программа сделала.
- Ожидаемый результат и основание: правило, НПА или контрольный пример.
- Окружение: конфигурация, релиз, платформа, пользователь.
- Вложения: скриншоты окон целиком, текст ошибки, ссылки на объекты.
- Критичность и срочность: остановка или неудобство, всегда или через раз.
В командах с линией поддержки полное описание готовит аналитик или консультант: часть обращений закрывается консультацией, часть — доработкой инструкций, и до разработчика доходит только то, что действительно требует кода. В небольшой компании шаблон заполняет инициатор: десять минут на описание экономят часы переписки.
Если проблема требует доработки или адаптации конфигурации — оставьте заявку на индивидуальный заказ: оценим задачу по вашему описанию. Готовые отчёты и обработки для проверки данных — в каталоге ExtLab.