← На главную

Уважаемые коллеги, при формировании документа "Резервы по оплате труда" в 1С Зарплата и управление персоналом (ЗУП) версии 3.1 пользователи могут столкнуться с критической ошибкой SQL "Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric". Эта проблема указывает на то, что числовое значение, полученное в процессе расчетов, превышает максимально допустимый диапазон или формат поля типа numeric (или decimal) в базе данных SQL Server. Разберем подробно причины возникновения этой ошибки и предложим комплексные шаги по ее диагностике и устранению.

Понимание сути ошибки SQL "Арифметическое переполнение"

Сообщение об ошибке HRESULT=80040E57, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115 указывает на стандартное арифметическое переполнение при попытке преобразования или сохранения числового значения. В контексте 1С ЗУП и формирования резервов отпусков, это часто происходит в процессе расчета эффективных ставок страховых взносов.

Анализируя трассировку стека, мы видим, что ошибка возникает в модуле ОбщийМодуль.УчетСтраховыхВзносов.Модуль(3388) в строке, где выполняется запрос. Этот запрос, предположительно, формирует временную таблицу эффективных ставок взносов для оценочных обязательств. Конкретный фрагмент, на который указывают эксперты, это использование функции ВЫРАЗИТЬ (или CAST в SQL) в запросе, например, Выразить (Взносы / База) как Число(7,4).

Что это означает? Функция ВЫРАЗИТЬ пытается привести результат деления (суммы взносов на базу взносов) к числовому типу с заданной точностью и масштабом, в данном случае ЧИСЛО(7,4). Это означает, что число может иметь максимум 7 знаков, из которых 4 знака после запятой. Таким образом, максимальное допустимое значение составит 999.9999. Если в результате деления Взносы / База получается значение, превышающее этот предел (например, 1000.0000 или больше), происходит арифметическое переполнение, и SQL Server выдает ошибку.

Причины возникновения аномально больших коэффициентов

Рассмотрим основные факторы, которые могут привести к получению коэффициентов, вызывающих переполнение:

1. Некорректные данные или расчеты "вредных" дополнительных взносов в СФР. Если в вашей конфигурации есть дополнительные взносы в Социальный Фонд России (СФР), особенно те, которые вводятся вручную или имеют специфические настройки, они могут быть причиной. Например, если сумма таких взносов очень велика, а база для их расчета (или общая база взносов по другим причинам) крайне мала, то отношение "взносы / база" может стать аномально высоким. Это часто случается, когда ручной ввод взносов не соответствует ожидаемой логике системы, и база взносов оказывается значительно меньше суммы самих взносов.

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

   ВЫРАЗИТЬ (Взносы / Базу) КАК ЧИСЛО(7,4)

   Если Взносы очень большие, а База очень маленькая (или даже нулевая в каких-то случаях), то результат деления может превысить 999.9999. В коде 1С это может быть частью более сложного запроса, например:

   Скопировать код

   
   ВЫБРАТЬ
       ...
       ВЫРАЗИТЬ(СУММА(ВзносыНаСтрахование.СуммаВзноса) / СУММА(ВзносыНаСтрахование.БазаНачисления) КАК ЧИСЛО(7, 4)) КАК ЭффективныйКоэффициентВзноса
       ...
   

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

3. Отрицательные остатки в регистрах. В некоторых сложных сценариях, особенно при расчетах себестоимости или при наличии корректировок, появление отрицательных остатков в регистрах накопления может привести к некорректным и аномально большим итоговым значениям при последующих расчетах, вызывая переполнение.

4. Изменение логики расчета в новых релизах конфигурации. Если на предыдущем релизе ЗУП (например, 3.1.30.36) документ формировался корректно, а после обновления до 3.1.31.13 начал выдавать ошибку, это может указывать на изменение алгоритма расчета эффективных ставок или ужесточение контроля в новых версиях конфигурации. Новая логика может по-другому обрабатывать пограничные или некорректные данные, которые ранее игнорировались или приводили к менее критичным ошибкам.

Комплексные шаги по диагностике и устранению проблемы

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

1. Шаг 1: Локализация проблемных данных и подразделений

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

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

   2. Анализ данных в проблемном подразделении. После выявления проблемного подразделения, сосредоточьтесь на анализе его данных. Обратите внимание на:

      • Начисления и выплаты: Проверьте аномально высокие или низкие суммы окладов, премий, компенсаций, а также их базы для страховых взносов.
      • Страховые взносы: Особое внимание уделите дополнительным взносам в СФР, если они используются. Проверьте, нет ли некорректного ручного ввода или расчетов. Сверьте базы взносов и суммы взносов. Возможно, есть сотрудники, у которых база взносов для какого-либо вида взносов оказалась нулевой или отрицательной, при этом сумма взносов была начислена, что привело к делению на ноль или очень маленькое число.
      • Сотрудники: Проверьте карточки сотрудников этого подразделения на предмет корректности данных (дата приема, увольнения, вид занятости, ставки и т.д.).
      • Документы: Проанализируйте все кадровые и расчетные документы, проведенные за период, предшествующий расчету резервов, для этого подразделения. Возможно, были введены ошибочные данные или корректировки.

      Для анализа данных по страховым взносам можно использовать стандартные отчеты ЗУП, например, "Анализ начислений сотрудникам" с детализацией по взносам, или "Сводная ведомость по взносам".

2. Шаг 2: Корректировка некорректных данных

   После выявления аномальных данных в проблемном подразделении, необходимо их исправить. Это наиболее предпочтительный и безопасный способ решения проблемы.

   Действие:

   • Если обнаружены некорректные суммы начислений или взносов, найдите соответствующие документы (например, "Начисление зарплаты и взносов", "Доначисление, перерасчет" и т.п.) и исправьте их. Возможно, потребуется перепровести документы, связанные с сотрудниками данного подразделения.
   • Если проблема связана с ручным вводом дополнительных взносов, проверьте корректность их сумм и баз. Возможно, придется скорректировать их или изменить способ их расчета.
   • Если обнаружены некорректные кадровые данные, исправьте их в соответствующих кадровых документах.

3. Шаг 3: Проверка и корректировка типов данных (с осторожностью)

   Если вы уверены в источнике проблемы и имеете опыт работы с SQL Server, можно рассмотреть возможность изменения типа поля в базе данных. Однако, это крайне не рекомендуется делать без консультации с разработчиками 1С или глубокого понимания последствий, так как это является изменением типовой конфигурации и может вызвать проблемы при обновлениях.

   Действие: В SQL Server Management Studio найдите таблицы, задействованные в запросе (например, регистры, связанные со страховыми взносами), и поля типа numeric, в которые записываются результаты расчетов коэффициентов. Если вы обнаружите, что поле, куда записывается эффективный коэффициент, имеет тип, например, numeric(7,4), и ожидаете значения больше 999.9999, можно рассмотреть увеличение его точности и/или масштаба (например, до numeric(10,4) или numeric(15,4)). Повторим, это крайняя мера и может нарушить типовую логику и обновления.

4. Шаг 4: Тестирование и исправление информационной базы (ТИИ)

   Хотя в описанном случае ТИИ не принесло значимого результата ("ТИИ не особо помогло"), это стандартная и полезная процедура для выявления и исправления логических ошибок в базе данных 1С.

   Действие: Запустите "Тестирование и исправление информационной базы" из режима Конфигуратор (Администрирование -> Тестирование и исправление...). Рекомендуем использовать все доступные опции, особенно "Проверка логической целостности", "Пересчет итогов", "Сжатие таблиц ИБ". Обязательно сделайте резервную копию базы данных перед выполнением ТИИ.

5. Шаг 5: Чистка серверного кэша

   Иногда проблемы с производительностью или ошибками могут быть связаны с некорректным кэшем. Хотя в данном случае это не помогло ("Чистка серверного кэша не помогает"), попробовать стоит.

   Действие: Остановите рабочий процесс 1С Предприятия на сервере, очистите содержимое каталога кэша (обычно находится по пути типа C:\Program Files\1cv8\srvinfo\reg_1541\snccntx\ или в профиле пользователя, от имени которого запущен сервис 1С), затем запустите рабочий процесс снова.

6. Шаг 6: Обновление платформы и конфигурации

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

   1. Обновление платформы 1С. В вашем случае используется платформа 8.3.24.1667. Рассмотрите обновление до более свежих и стабильных версий, например, 8.3.25.x или новее, если таковые имеются и рекомендованы 1С. Всегда проверяйте совместимость платформы с вашей версией конфигурации ЗУП.

      Действие: Скачайте актуальный дистрибутив платформы с портала 1С и обновите сервер 1С Предприятия и клиентские приложения. Обязательно протестируйте на копии базы.

   2. Обновление конфигурации ЗУП. Если на предыдущем релизе ЗУП (например, 3.1.30.36) документ формировался корректно, это может указывать на ошибку в текущем релизе (3.1.31.13) или изменение логики. Проверьте портал 1С на наличие исправлений для вашего релиза или обновитесь до следующего стабильного релиза, если он уже вышел и содержит исправления, связанные с расчетом резервов или страховых взносов. Также стоит поискать патчи (исправления ошибок) для вашего релиза. Например, ошибка 30179705, связанная с резервом отпусков, исправлялась патчем EF_30179700. Проверьте, не подходит ли вам похожий патч.

      Действие: Сверьтесь с информацией на портале 1С ИТС по вашему релизу ЗУП 3.1.31.13 и следующим за ним. При наличии патчей установите их. Если есть более новый стабильный релиз, рассмотрите обновление конфигурации. Всегда проводите тестирование на копии базы.

7. Шаг 7: Детальный анализ запроса и базы данных (для продвинутых пользователей и программистов)

   Если все предыдущие шаги не дали результата, потребуется более глубокий анализ, возможно, с привлечением программиста 1С и/или администратора SQL Server.

   1. Отладка в 1С. Используйте отладчик 1С, чтобы пошагово пройтись по коду в модуле ОбщийМодуль.УчетСтраховыхВзносов.Модуль(3388) или другим указанным в стеке вызовов. Это позволит увидеть значения переменных непосредственно перед выполнением проблемного запроса и после него. Особое внимание уделите параметрам, передаваемым в запрос, и результатам его выполнения.

   2. Трассировка SQL Server. Если ошибка возникает в SQL-запросе, администратор SQL Server может настроить трассировку (например, с помощью SQL Server Profiler) для перехвата запроса, вызывающего ошибку, и его параметров. Это позволит увидеть точный текст SQL-запроса, который был отправлен 1С на SQL Server, и значения, которые привели к переполнению.

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

Заключение

Ошибка арифметического переполнения при формировании резервов отпусков в 1С ЗУП 3.1 — это серьезная проблема, которая чаще всего связана с аномальными данными в базе, влияющими на расчет эффективных ставок страховых взносов. Наиболее вероятным сценарием является наличие "кривого" подразделения с некорректными данными, приводящими к чрезмерно большим коэффициентам. Системный подход к диагностике, начиная с локализации проблемы до конкретных данных и заканчивая проверкой обновлений и патчей, позволит успешно решить эту задачу.