В конфигурации 1С Управление торговлей 8 стоимостной учет товаров отделен от количественного. Это приводит к тому, что их данные периодически расходятся между собой.

На этом скришноте картина, хорошо знакомая всем пользователям "Управления торговлей": 2 отчета, которые должны показывать одно и то же, показывают разные цифры. После чего возникает впоне естественный вопрос: почему это произошло и какому отчету верить ?

Дело в том, что процедура определения партии товара более сложная и на больших объемах приводит к длительному времени проведения документов. А это значит, что если обслуживаются одновременно много клиентов, другие должны ждать.

В программе есть настройка: , которая полностью разделяет эти процессы. Если данный фладок снять, то при проведении документа проводки по регистру "Партии товаров на складах" не делаются, а делаются они отдельной обработкой.

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

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

Стоимостной учет может содержать и ошибки именно в стоимости товаров, то есть не связанные с расхождениями в количестве между регистрами. Наиболее распространенная ошибка - не соответствие себестоимости по которое товар списан той себестоимости, по которой он оприходован. Возникает это из-за внесения в базу изменений "задним числом".

Вообще после таких изменений базу полагается перепроводить. И в УТ есть даже средство контроля последовательности документов. Только вот средство это весьма примитивное - перепровели документ - последовательность показывает что теперьс его даты надо все перепроводить. А действительно надо ли, и какова текущая ошибка, она ответа не дает. Вполне обычная ситуация, когда:

• имеем базу, в которую внесены изменения задним числом
• нужно срочно подготовить какой-нибудь отчет, связанные с себестоимостью

Понятно, что наличие изменений задним числом означает, что может быть неверен. Но насколько он неверен? Есть большая разница в между ошибками в себестоимости на сумму 1000 руб и на сумму 1 коп. А может быть, что внесенные изменения вообще не затрагивали себестоимость (например изменили комментарий к документу).

Для того, чтобы быстро оценить состояние базы и возможные ошибки, можно, например, воспользоваться отчетом "Проверка движений по партиям".