20 ошибок 1С, которые не ловят ни конфигуратор, ни тесты

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

9:14 утра: отчёт не сходится, хотя обновление прошло без единой ошибки

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

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

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

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

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

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

То же самое происходит с производительностью. Тест на одном рабочем месте показывает, что документ проводится за секунду. В реальности, когда 40 пользователей одновременно закрывают месяц, те же операции выстраиваются в очередь из-за блокировок объектов — а конфигуратор блокировки не эмулирует, потому что для этого нужна нагрузка, а не синтаксическая проверка.

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

Что теряет бизнес, пока ошибка остаётся незамеченной

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

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

Какие ошибки видит 1С, а какие — нет

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

🔍 20 признаков, за которыми прячется тихая ошибка

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

Деньги и учёт

• ✓Итоговая сумма в отчёте не совпадает с суммой по документам, хотя разница в пределах нескольких рублей
• ✓Разные пользователи получают разный результат при одном и том же фильтре в одном отчёте
• ✓Регламентное задание пересчитывает курс валюты иначе, чем документ, введённый вручную
• ✓Остатки по регистру расходятся с остатками по документам после массового перепроведения
• ✓Скидки округляются по-разному в зависимости от порядка применения условий

Производительность и блокировки

• ✓База виснет в одно и то же время каждый день, например при закрытии месяца
• ✓Один и тот же отчёт формируется с разной скоростью в зависимости от того, кто его запускает
• ✓Проведение документа занимает секунды у одного пользователя и минуты у другого при том же объёме данных
• ✓Очередь регламентных заданий растёт, но ошибок в журнале регистрации нет
• ✓Обмен данными между базами завершается «успешно», хотя часть записей до получателя не доходит

Права и доступ

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

Доработки и интеграции

• ✓Обмен с сайтом или маркетплейсом подтверждает получение заказа, которого в базе нет
• ✓После обновления типовой конфигурации доработанный модуль продолжает работать по старой версии интерфейса
• ✓Тест в конфигураторе проходит, но реальный документ с нестандартным набором реквизитов вызывает ошибку
• ✓Расчёт себестоимости в доработанном модуле не совпадает с типовым при одинаковых исходных данных
• ✓Регламентное задание, добавленное подрядчиком, не отражено в общем расписании и не перезапускается после сбоя

Как мы ловим такие ошибки при внедрении и сопровождении

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

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

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

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

Почему автотесты в 1С не находят ошибки в расчётах?

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

Как понять, что в базе 1С есть скрытая ошибка, если внешне всё работает?

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

Сколько стоит найти и исправить такую ошибку в 1С?

Стоимость зависит от сложности стыка между модулями, но диагностику и доработку обычно ведут по ставке сопровождения 1С от 3800 ₽ за час. Точный срок и бюджет называют после короткого разбора конкретной ошибки, а сама диагностика обычно не требует остановки работы пользователей.

Можно ли предотвратить такие ошибки ещё на этапе внедрения 1С?

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

Как часто нужно проверять базу на подобные расхождения?

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