← На главную

Ошибка «SQL: Переполнение поля» (или Arithmetic overflow) — это критическая ситуация, которая чаще всего возникает в 1С:Управление нашей фирмой (УНФ) во время выполнения регламентной операции «Закрытие месяца». Суть проблемы заключается в том, что в процессе математических вычислений (расчета себестоимости, распределения затрат или курсовых разниц) система получает число, которое физически не может быть записано в таблицу базы данных из-за ограничений разрядности (например, когда число превышает 15 знаков до запятой при стандартном описании типа Numeric(15,2)).

В этой статье мы подробно разберем, почему возникают «триллионные» суммы, как найти конкретный товар или документ-виновник и какими инструментами пользоваться для локализации ошибки. Зачастую, чтобы предотвратить такие ситуации, полезно анализировать себестоимость продаж без закрытия месяца, выявляя проблемы на раннем этапе.

Выясняем причины возникновения ошибки

Прежде чем приступать к исправлению кода, проанализируем ситуацию. В 99% случаев ошибка вызвана не багом платформы, а некорректными данными в информационной базе. Рассмотрим основные сценарии:

1. Деление на ничтожно малое число. Если в алгоритме расчета себестоимости сумма затрат делится на количество, которое из-за ошибок округления или единиц измерения превратилось в 0.0000001, итоговый результат стремится к бесконечности.
2. Зацикливание затрат (Рекурсия). В УНФ расчет себестоимости происходит итерационно. Если возникает «петля» в производстве (например, Полуфабрикат А входит в состав Полуфабриката Б, а Полуфабрикат Б в свою очередь включен в спецификацию Полуфабриката А), стоимость на каждом цикле может увеличиваться в геометрической прогрессии, пока не произойдет переполнение поля.
3. Отрицательные остатки («Краснота»). Закрытие месяца крайне чувствительно к отрицательным остаткам на складах. Когда система пытается списать стоимость при отсутствии количественного остатка, расчетные механизмы могут выдать непредсказуемые гигантские цифры.
4. Некорректные коэффициенты единиц измерения. Если в карточке номенклатуры указан коэффициент пересчета единиц измерения равный нулю или слишком большой величине, любая складская операция умножит или разделит сумму на этот коэффициент, что приведет к искажению данных.

Методика технической отладки: используем ВЫРАЗИТЬ

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

Проанализируем пример. Если в коде стоит ограничение:

ВЫРАЗИТЬ(Таблица.СуммаРазница КАК ЧИСЛО(15, 2))

Для целей отладки заменим его на более широкое поле:

ВЫРАЗИТЬ(Таблица.СуммаРазница КАК ЧИСЛО(30, 2))

Важно: Это не решение проблемы, а способ заставить систему «проглотить» ошибочное число, чтобы мы могли увидеть его в результате запроса. Посмотрите на параметры и результат выполнения этого запроса в консоли отчетов или через отладчик. Когда вы увидите сумму вида 9 999 999 999 999 999,99, вы сможете по полям группировки (Номенклатура, Склад, Заказ) понять, где именно кроется ошибка.

Поиск виновника в регистрах накопления

Если правка кода не помогает или вы не хотите менять типовую конфигурацию, перейдем к анализу данных. В УНФ основным источником проблем являются три регистра. Если в ходе анализа будут найдены некорректные записи, исправить их помогут специальные обработки для корректировки остатков. Проверим их по шагам.

1. Регистр «Запасы и затраты»
Это сердце учета себестоимости. Проанализируем его с помощью стандартного отчета «Оборотно-сальдовая ведомость» или через «Все функции» — «Регистры накопления». Также для упрощения поиска аномалий можно использовать специализированные отчеты для сравнения регистров «Запасы на складах» и «Запасы и затраты»:

• Постройте отчет за закрываемый период.
• Установите максимальную детализацию: Номенклатура, Партия, Заказ.
• Ищите строки, где конечный остаток или оборот по сумме имеет аномальное количество знаков (те самые 14-значные суммы).

2. Регистр «Выпуск продукции»
Часто переполнение происходит при распределении косвенных затрат. Проверим документы Производство и Распределение затрат. Если база распределения (например, количество выпущенной продукции) близка к нулю, а сумма распределяемых затрат велика, возникнет ошибка.

3. Проверка отрицательных остатков
Воспользуйтесь отчетом «Остатки товаров». Если на складах есть «красные» остатки на момент закрытия, их необходимо устранить документами Инвентаризация или Оприходование запасов.

Использование технологического журнала и SQL Profiler

Если визуальный анализ регистров не дает результатов, перейдем к «тяжелой артиллерии». Выясним, на какой именно таблице спотыкается SQL Server.

Рассмотрим настройку Технологического журнала (ТЖ). Нам нужно отловить событие DBMSSQL с ошибкой. В файле logcfg.xml можно задать сбор ошибок, которые содержат текст «overflow». В полученном логе будет виден полный текст SQL-запроса и значения всех параметров. Это позволит точно определить, какая временная таблица (например, #tt10) переполняется.

Если вы используете MS SQL Server, запустите SQL Server Profiler:

1. Создайте новую трассировку.
2. Выберите события Exceptions и RPC:Completed.
3. Запустите закрытие месяца в 1С.
4. В момент падения 1С профайлер зафиксирует исключение. В тексте исключения будет указано имя поля и таблицы, в которую SQL пытался записать некорректное число.

Практические рекомендации по исправлению

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

Проанализируйте спецификации. Проверьте, нет ли в производстве циклов (А делает Б, а Б делает А). Если цикл обнаружен, схему выпуска нужно пересмотреть в сторону линейной структуры.

Проверьте документ «Распределение затрат». Если он заполнен вручную, убедитесь, что в колонках количества не стоят микроскопические значения, а суммы соответствуют реальности.

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

Очистите кэш. Перед проведением глубоких работ обязательно очистите кэш сервера и клиентских машин. В редких случаях «фантомные» ошибки переполнения могут быть связаны с некорректным кэшированием планов запросов.

Подводя итог, помните: ВЫРАЗИТЬ(КАК ЧИСЛО) — это лишь верхушка айсберга. Почти всегда за этой ошибкой стоит человеческий фактор при вводе данных или сложная логическая петля в производственном учете, которую необходимо распутать методически.