На счета посмотрите, а не только на то, есть номенклатура или нет. Если ее оприходовали на счет 41, а пытаются списать со счета 10, тогда на счете 10 возникнут отрицательные остатки.

Возможно, просто глюк. Пересчитай итоги по регистрам.

ShuhardGaryaВозможно, просто глюк. Пересчитай итоги по регистрам.
поржал
измерение Регистра стало глюкомА что не так?
В 1С регистры накопления, которые должны, по идее выдавать корректный результат после последовательности "было 0", "пришло 10", "ушло 4" - в остатках должно быть 6, а иногда в результате глюков выводится какая-то чушь. Я запускал переиндексацию и пересчет итогов по регистрам - после этого выводило то, что должно выводиться.

Мальчики, не ссорьтесь... :)
Я себе так представляю. Регистр накопления в 1С - некий эквивалент многомерного куба "со специализацией". Как минимум, он физически содержит в себе хранимые агрегаты - промежуточные значения приходов/расходов за определенные периоды - для того, чтобы не вычислять их "от царя Гороха" каждый раз, когда они потребуются. При этом возможны ситуации, например, связанные с некорректным завершением работы программы, когда исходные данные в регистр накопления уже записаны, а агрегаты пересчитаться еще не успели. В этом случае регистр может выводить данные, не соответствующие исходным данным. Такие ошибки наиболее вероятны для тех случаев, когда для хранения данных не используются СУБД, поддерживающие на уровне ядра принципы ACID для транзакций. Если это файловая база данных, они, насколько мне известно, регулярно возникают.
Если я в чем-то ошибаюсь, прошу меня поправить.

КритерийОтбораGaryaКак минимум, он физически содержит в себе хранимые агрегаты - промежуточные значения приходов/расходов за определенные периоды - для того, чтобы не вычислять их "от царя Гороха" каждый раз, когда они потребуются

не совсем.

там условно две таблицы в одной все движения, во второй итоги этих движений помесячно."Итоги всех этих движений помесячно" - это и есть хранимые агрегаты.

КритерийОтборасоответственно "итоги на сейчас" это ближайшие подходящие итоги + движения от них и до сейчасЭто соответствует моим представлениям. Вместо того, чтобы рассчитывать итог "от царя Гороха", итог рассчитывается от ближайшего ранее рассчитанного хранимого агрегата. Если хранимый агрегат (содержимое второй таблицы) по каким-либо причинам оказалось не соответствующим исходным данным (содержимому первой таблицы), а это возможно, в частности, по причине некорректного прерывания транзакций в среде, в которой требования ACID транзакций не могут быть гарантированы, тогда регистр содержит "глючные значения".

КритерийОтбораGaryaТакие ошибки наиболее вероятны для тех случаев, когда для хранения данных не используются СУБД, поддерживающие на уровне ядра принципы ACID для транзакций. Если это файловая база данных, они, насколько мне известно, регулярно возникают.

все возможно

но это не тот случайМожет быть и не тот. А может быть и тот. ТС, к сожалению, не сообщил, использует ли он файл-серверный либо SQL-серверный вариант. В файл-серверном с такой проблемой мне довольно часто приходилось сталкиваться.