При переходе с устаревших конфигураций (например, 1С:Управление торговлей 10.3) на современные решения платформы 1С:Предприятие 8.3 (УТ 11, КА 2, ERP 2) технические специалисты часто сталкиваются со специфическим поведением системы. Одной из наиболее распространенных и неочевидных проблем является ситуация, когда документ Приобретение товаров и услуг успешно проводится, но не формирует никаких движений по регистру накопления Товары на складах (то есть остатки товаров на складе не увеличиваются).
Давайте подробно разберем, почему возникает эта проблема, проанализируем внутренние механизмы работы конфигурации «Управление торговлей 11» и рассмотрим пошаговые сценарии ее решения.
Для успешного расследования нам потребуется углубиться в архитектуру регистров, особенности переноса данных, а также логику работы складского и финансового учета в управляемом интерфейсе.
---
Это самая частая причина в ситуациях, когда по одним складам в базе движения формируются корректно, а по другим — отсутствуют полностью, хотя визуально настройки складов выглядят абсолютно идентичными. Разберемся в механике этой ошибки.
В 1С:УТ 11 существует глобальная функциональная опция Ордерные склады (путь в интерфейсе: НСИ и администрирование -> Склад и доставка -> Склад -> Ордерные склады). Если этот флаг в настройках системы отключен, то в карточке самого склада (справочник Склады) полностью скрывается раздел настроек ордерной схемы («При поступлении», «При отгрузке» и т. д.).
Однако при программном переносе данных из УТ 10.3 с помощью правил обмена или обработок загрузки реквизиты объекта базы данных ИспользоватьОрдернуюСхемуПриПоступлении могут записаться со значением Истина непосредственно в СУБД. При этом в пользовательском интерфейсе этот флаг будет скрыт из-за отключенной глобальной опции.
В результате программная логика проведения документа Приобретение товаров и услуг считывает из базы реальное значение реквизита склада. Система «считает» склад ордерным и ожидает, что фактическое оприходование на склад будет выполнено отдельным документом Приходный ордер на товары. Финансовый документ закупки при этом делает только взаиморасчетные движения, минуя складской регистр остатков.
Как решить эту проблему по шагам:
---
Еще один частый «подводный камень» связан со схемами раздельного оформления закупок (например, неотфактурованные поставки или товары в пути). Эти параметры хранятся в реквизитах договора контрагента или соглашения об условиях закупок.
Если в системе отключена опция неотфактурованных поставок, то элементы управления для настройки вариантов приемки скрываются из формы договора. Тем не менее в базе данных после переноса эти реквизиты могут иметь некорректные или пустые значения.
Если в реквизите договора ВариантОформленияЗакупок установлено значение, отличное от «Не разделять» (например, «Товары в пути» или «Фактуровка поставки»), система рассматривает документ Приобретение товаров и услуг как чисто финансовый реестр. Остатки на склад при такой схеме должны приходоваться документом Поступление товаров на склад.
Проанализируем структуру договора с помощью несложного запроса. Нам нужно проверить два ключевых реквизита: ВариантОформленияЗакупок и ВариантПриемкиТоваров.
Рассмотрим пример запроса, который поможет быстро выявить проблемные договоры в базе данных:
ВЫБРАТЬ
Договоры.Ссылка КАК Договор,
Договоры.ВариантОформленияЗакупок КАК ВариантОформления,
Договоры.ВариантПриемкиТоваров КАК ВариантПриемки
ИЗ
Справочник.ДоговорыКонтрагентов КАК Договоры
ГДЕ
Договоры.ВариантОформленияЗакупок <> ЗНАЧЕНИЕ(Перечисление.ВариантыОформленияЗакупок.НеРазделять)
ИЛИ Договоры.ВариантПриемкиТоваров <> ЗНАЧЕНИЕ(Перечисление.ВариантыПриемкиТоваров.РазделенаТолькоПоНакладным)
Если запрос вернул список договоров, которые используются в ваших документах приобретения, их необходимо скорректировать. Сделать это можно с помощью стандартной обработки Групповое изменение реквизитов, установив для реквизита ВариантОформленияЗакупок значение НеРазделять (в интерфейсе отображается как «Одним документом»), а для ВариантПриемкиТоваров — значение РазделенаТолькоПоНакладным.
---
При написании собственных обработок переноса данных программисты часто совершают ошибку при заполнении табличной части Товары документа приобретения. Специфика платформы и архитектуры метаданных УТ 11 заключается в разделении физического количества и количества в упаковках.
В форме документа колонка с заголовком «Количество» на самом деле связана с реквизитом объекта КоличествоУпаковок. А реальный реквизит Количество (базовое количество) часто рассчитывается автоматически при интерактивном вводе или скрыт.
Если программный загрузчик перенес данные из УТ 10.3 напрямую в реквизит КоличествоУпаковок, но при этом забыл рассчитать и заполнить реквизит Количество, то при проведении документа движения по складу не сформируются. Система видит, что физическое базовое количество равно нулю.
Проверим состояние табличной части документа с помощью консоли запросов:
ВЫБРАТЬ
ПриобретениеТовары.НомерСтроки,
ПриобретениеТовары.Номенклатура,
ПриобретениеТовары.Количество,
ПриобретениеТовары.КоличествоУпаковок
ИЗ
Документ.ПриобретениеТоваровУслуг.Товары КАК ПриобретениеТовары
ГДЕ
ПриобретениеТовары.Ссылка = &СсылкаНаДокумент
Если в результате выполнения запроса колонка Количество окажется пустой или равной нулю при заполненной колонке КоличествоУпаковок, мы нашли причину сбоя. Для устранения проблемы необходимо доработать алгоритм загрузки данных, обеспечив обязательный вызов обработчиков событий при записи документа или принудительно рассчитывая базовое количество по формуле: Количество = КоличествоУпаковок * КоэффициентУпаковки.
В качестве быстрого теста можно попробовать вручную перевыбрать количество в одной из строк проблемного документа прямо в интерфейсе 1С и перепровести его. Если движение по складу появилось — проблема однозначно в некорректной работе загрузчика данных.
---
В процессе конвертации данных из старой базы УТ 10.3 в новую УТ 11 могла произойти системная ошибка сопоставления типов номенклатуры. В УТ 11 жестко разграничено поведение системы для разных типов позиций. Чтобы избежать сбоев корректности реквизитов при переходе, применяется обработка переноса данных из УТ 10.3 в УТ 11 с корректно настроенными правилами конвертации справочников и документов.
Если загруженным товарам ошибочно присвоился тип номенклатуры Услуга или Работа вместо типа Товар, то при проведении закупки программа спишет их стоимость на финансовые расходы или зафиксирует затраты предприятия, но не сделает никаких записей в складской регистр остатков. Услуги и работы не имеют физического остатка и не хранятся на складах.
Что необходимо сделать:
---
В комплексных конфигурациях 1С (УТ 11, ERP, КА) ключевую роль в движениях товаров играет механизм распределения по видам запасов. При проведении любого товарного документа система обращается к механизму ВидыЗапасов, который определяет, под какую организацию, налогообложение или под какое назначение приходуется или списывается товар.
Если при переносе документов были допущены логические нестыковки (например, не перенесены настройки учетной политики организаций, не заполнена схема налогообложения или неверно указаны хозяйственные операции), механизм автоматического расчета видов запасов может дать сбой.
Для проверки этой гипотезы проанализируем состояние видов запасов в конкретном документе:
Приобретение товаров и услуг.---
Мы подробно разобрали внутренние механизмы проведения складских документов в 1С:УТ 11. Для быстрой диагностики проблемы рекомендуем использовать следующий чек-лист:
Товары реквизит Количество заполнен физическим числовым значением.Товар.Используя эти методы, вы сможете быстро локализовать проблему, восстановить корректный учет складских остатков и обеспечить стабильный старт работы пользователей в новой редакции программы 1С:Управление торговлей 11.