Переполнение регистра накопления Учет Затрат(упр.учет)
Добрый вечер!
Возникла следующая ситуация: не проводятся отчеты производства за смену, выдает ошибку:
{ОбщийМодуль.УправлениеПроизводствомДвиженияПоРегистрам.Модуль(3672)}: Ошибка при вызове метода контекста (Выполнить)
РезультатЗапроса = Запрос.Выполнить();
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
Microsoft SQL Server Native Client 11.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
HRESULT=80004005, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1
Снимаешь галочку Упр.учет, сразу все нормально проводится.
Посмотрела остатки и обороты по регистру Учет Затрат(упр.учет), а там полный фарш. Прилагаю скрин кусочка отчета.
Уважаемые форумчане, что можно с этим делать? Тестирование и исправление не помогло :(
Что можно предпринять в подобной ситуации?
Возникла следующая ситуация: не проводятся отчеты производства за смену, выдает ошибку:
{ОбщийМодуль.УправлениеПроизводствомДвиженияПоРегистрам.Модуль(3672)}: Ошибка при вызове метода контекста (Выполнить)
РезультатЗапроса = Запрос.Выполнить();
по причине:
Ошибка выполнения запроса
по причине:
Ошибка при выполнении операции над данными:
Microsoft SQL Server Native Client 11.0: Ошибка арифметического переполнения при преобразовании numeric к типу данных numeric.
HRESULT=80004005, SQLSrvr: SQLSTATE=22003, state=8, Severity=10, native=8115, line=1
Снимаешь галочку Упр.учет, сразу все нормально проводится.
Посмотрела остатки и обороты по регистру Учет Затрат(упр.учет), а там полный фарш. Прилагаю скрин кусочка отчета.
Уважаемые форумчане, что можно с этим делать? Тестирование и исправление не помогло :(
Что можно предпринять в подобной ситуации?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) Ни версию SQL, ни версию платформы не указываете... Не предысторию. Наверняка позавчера всё было нормально. Так что же случилось вчера.
В вашей ситуации скорее всего проблема не с 1С а с SQL сервером.
В решении данной ситуации можно пойти следующим путём.
Естественно всё надо делать на тестовой машине а не на рабочей базе.
-Положить информационную базу в файловый вариант.
-Проверить и убедиться в том, что документ проводится правильно.
-Создать новый тестовый SQL сервер на тестовой машине.
-Накатить все обновления до актуальных
-Проверить и убедиться в том, что документ проводится правильно.
Если на тестовом сервере ошибка сохранится, то понижаем версию сначала платформы, потом SQL
И так далее
В вашей ситуации скорее всего проблема не с 1С а с SQL сервером.
В решении данной ситуации можно пойти следующим путём.
Естественно всё надо делать на тестовой машине а не на рабочей базе.
-Положить информационную базу в файловый вариант.
-Проверить и убедиться в том, что документ проводится правильно.
-Создать новый тестовый SQL сервер на тестовой машине.
-Накатить все обновления до актуальных
-Проверить и убедиться в том, что документ проводится правильно.
Если на тестовом сервере ошибка сохранится, то понижаем версию сначала платформы, потом SQL
И так далее
Кроме вариантов проблемы с сервером наиболее вероятно, что у вас РАУЗ с оценкой по прямым затратам. То есть при проведении ОПЗС проводится система пытается вычислить себестоимость выпуска. А тут вступает в силу беда "отрицательные остатки по регистрам учета затрат". Все мы помним, что отрицательные остатки по МПЗ на конец месяца в принципе могут вызвать ошибки расчета (минимум зависшие суммы без кол-ва, а максимум - переполнение суммы 9-ками). На конец месяца выровнять все реально, но когда себестоимость считается на каждый документ, то вполне возможны случаи когда номенклатуру еще не списали/переместили и т.п. Отсюда оперативные минуса по регистру учета затрат с вытекающими. Так как у вас отдельно РАУЗ с отдельным УУ, то детализация БУ учета затрат ниже управленческого (в УчетЗатратРегл не ведется аналитика по сериям, характеристикам например). И если в УУ был допущен пересорт по допаналитике (которого нет БУ), то логично что в УУ учете документ падает, а в регл - нет.
На копии базы попробуйте перевести режим оценки выбытия затрат в "по нулевой стоимости" и перепроведите документ. Если ошибок не будет, то стоит попытаться убедить юзверей, что так будет реально удобнее (от промежуточных результатов по большому счету проку нет, а корректировки в конце месяца становится значительно сложнее анализировать. И чисто по опыту способ "по прямым затратам" по жизни подходит только перепродажникам.
На копии базы попробуйте перевести режим оценки выбытия затрат в "по нулевой стоимости" и перепроведите документ. Если ошибок не будет, то стоит попытаться убедить юзверей, что так будет реально удобнее (от промежуточных результатов по большому счету проку нет, а корректировки в конце месяца становится значительно сложнее анализировать. И чисто по опыту способ "по прямым затратам" по жизни подходит только перепродажникам.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот