Многие специалисты, перешедшие на 1С:Управление торговлей версии 11.4 (и выше) с более ранних редакций, сталкиваются с неожиданным поведением системы: при попытке отменить проведение (распровести) документ «Приобретение товаров и услуг» или другой приходный документ, программа выдает ошибку о нехватке остатков. На первый взгляд это кажется нелогичным — мы не увеличиваем расход, а просто отменяем приход. В этой статье мы разберем, почему разработчики 1С заложили именно такую логику, проанализируем работу регистров ГТД и выясним, как корректно решать подобные ситуации.
Давайте разберем ситуацию с точки зрения архитектуры системы. В 1С:УТ 11 реализован строгий партионный учет и жесткие цепочки товародвижения. Рассмотрим стандартный процесс: мы оприходовали товар (Документ А), затем этот товар был распределен по ГТД, зарезервирован под заказ клиента или уже продан (Документ Б). Если система позволит нам беспрепятственно отменить Документ А, то Документ Б останется «висеть в воздухе». Его движения по регистрам будут ссылаться на несуществующую партию или пустой остаток.
Проанализируем основные причины, по которым контроль остатков срабатывает «назад»:
Рассмотрим подробнее специфическую ошибку, связанную с ГТД. Часто пользователи видят сообщение: «Превышен остаток товара к оформлению на складе... по документу Приобретение товаров и услуг». Проанализируем, почему это происходит. Данная ошибка генерируется процедурой ПроведениеСерверУТ.СообщитьОбОшибкахПроведенияПоРегиструТоварыКОформлениюТаможенныхДеклараций.
Этот регистр ведет учет товаров, которые поступили по импорту, но по которым еще не полностью распределены номера ГТД в соответствующем документе «ГТД по импорту». Если вы уже провели таможенную декларацию, она «забрала» остатки из этого регистра. Попытка отменить «Приобретение» приведет к тому, что в регистре образуется отрицательный остаток в разрезе документа-основания. Система видит это и блокирует действие, защищая налоговый и управленческий учет от рассогласования.
Прежде чем прибегать к программированию и изменению кода, проверим наличие прав доступа. В 1С:УТ 11 существует опция, позволяющая обходить контроль остатков. Рассмотрим, как ее задействовать:
В профиле групп доступа (или в настройках пользователя) есть флаг «Допускается проведение/отмена проведения документов без контроля остатков». Если этот флаг установлен, система при проведении или отмене проведения будет игнорировать ошибки по регистру ТоварыНаСкладах и ТоварыОрганизаций.
Важное ограничение: Как показывает практика, эта настройка часто не влияет на регистр ТоварыКОформлениюТаможенныхДеклараций. Контроль по ГТД часто прописан в модулях проведения более жестко, так как это напрямую влияет на формирование себестоимости и корректность книги покупок/продаж.
Самый правильный и безопасный метод — это работа с «деревом» документов. Давайте разберем по шагам, как найти причину блокировки:
Если вы решили исследовать проблему программно, обратите внимание на процедуру проведения. В современных версиях УТ используется механизм отложенного проведения и фоновых заданий. Посмотрим на пример того, где обычно кроется проверка по ГТД:
// Фрагмент логики в модуле ПроведениеСерверУТ
Процедура СообщитьОбОшибкахПроведенияПоРегиструТоварыКОформлениюТаможенныхДеклараций(ТаблицаОшибок, Отказ) Экспорт
// Здесь система проверяет остатки в разрезе документа-основания
// Даже при отмене проведения (РежимПроведенияДокумента.ОтменаПроведения)
// выполняется запрос к остаткам регистра.
КонецПроцедуры
Проанализируем ситуацию: если вы решите «закомментировать» этот контроль, вы столкнетесь с тем, что в регистре ТоварыКОформлениюТаможенныхДеклараций появятся записи с пустым или отрицательным количеством, которые «зависнут» там навсегда. Это приведет к тому, что в отчетах по ГТД появятся пустые строки, а при попытке ввести следующую декларацию система будет выдавать непредсказуемые ошибки.
Не стоит забывать и про регистры взаиморасчетов. С приходом «Новой архитектуры взаиморасчетов» в УТ 11.4, документы делают движения в сложные регистры накопления (например, РасчетыСПоставщикамиПоСрокам). При отмене проведения прихода система проверяет, не были ли эти суммы уже «зачтены» по слиянию (merge) с авансами или другими документами. Если цепочка оплат уже сформирована, распроведение первичного документа потребует пересчета всей цепочки платежей по данному контрагенту.
Подводя итог, можно сказать, что контроль остатков при распроведении — это не ошибка, а механизм защиты базы данных. Чтобы успешно работать в таких условиях, рекомендуем следующее:
Рассмотренные механизмы подчеркивают сложность и строгость учета в современных решениях 1С. Понимание этих процессов позволит вам более эффективно диагностировать ошибки и поддерживать базу данных в актуальном и непротиворечивом состоянии.