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