Организация складского учета — это одна из наиболее ресурсоемких задач для любого растущего бизнеса. Особенно остро встает вопрос, когда компания сталкивается с необходимостью внедрения динамического адресного хранения. В отличие от статического (закрепленного) хранения, при динамическом подходе одна и та же ячейка (или место на полке) в разные периоды времени может быть занята совершенно разными товарами. Это позволяет максимально эффективно использовать складские площади, но накладывает жесткие требования к информационной системе.
Ситуация усложняется, если учет ведется в программе 1С:Бухгалтерия 3.0 (БП 3.0), которая изначально разрабатывалась для регламентированного и финансового учета, а не для детального управления складом. Если к этому добавляется работа в облачном сервисе 1С:Фреш (1С:Предприятие через интернет), у многих пользователей и разработчиков возникает ощущение тупика. Проанализируем эту ситуацию, развенчаем популярные мифы и детально разберем четыре практических сценария реализации адресного хранения прямо в БП 3.0 в облаке.
Для начала разберем важное заблуждение, прозвучавшее в обсуждении: якобы в облаке 1С:Фреш невозможно использовать расширения конфигурации. Это устаревшая информация.
Сервис 1С:Фреш уже давно поддерживает механизм расширений. Пользователи могут загружать собственные уникальные разработки. Однако существует важный нюанс — обязательный аудит (модерация) со стороны специалистов фирмы 1С. Ваше расширение не должно содержать:
Как только расширение проходит аудит, оно становится доступным для установки в вашу базу БП 3.0 во Фреше. Таким образом, технический инструмент кастомизации системы нам полностью доступен.
Рассмотрим простейший вариант, который отлично подойдет для небольших складов, где номенклатура закреплена за конкретными полками, либо где кладовщику достаточно знать ориентировочное (основное) место нахождения товара. Этот способ не требует изменения программного кода и полностью реализуется штатными средствами БП 3.0.
Выясним, как это настроить по шагам:
Номенклатура и добавим новый дополнительный реквизит с наименованием "Адрес хранения" (тип значения — "Дополнительное значение" или просто "Строка").2-1-3).Для того чтобы кладовщик видел эти адреса при сборке заказов или приемке товаров, нам понадобятся печатные формы. Поскольку мы работаем во Фреше, мы не можем менять макеты в самой конфигурации напрямую. Вместо этого мы зарегистрируем внешнюю печатную форму через раздел "Дополнительные отчеты и обработки".
В коде внешней печатной формы (например, для Расходной накладной) мы переопределим заполнение табличной части. Посмотрим на пример кода, который извлекает созданный нами дополнительный реквизит:
Функция ПолучитьАдресХранения(СсылкаНоменклатуры) Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| НоменклатураДополнительныеРеквизиты.Значение КАК Адрес
|ИЗ
| Справочник.Номенклатура.ДополнительныеРеквизиты КАК НоменклатураДополнительныеРеквизиты
|ГДЕ
| НоменклатураДополнительныеРеквизиты.Ссылка = &СсылкаНоменклатуры
| И НоменклатураДополнительныеРеквизиты.Свойство.Наименование = ""Адрес хранения""";
Запрос.УстановитьПараметр("СсылкаНоменклатуры", СсылкаНоменклатуры);
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Выборка = РезультатЗапроса.Выбрать();
Выборка.Следующий();
Возврат СокрЛП(Выборка.Адрес);
КонецЕсли;
Возврат "";
КонецФункции
Этот адрес мы выводим в отдельную колонку печатной формы рядом с наименованием товара. Сборщик получает бумажный лист с четким указанием, куда идти за товаром.
Главный минус данного подхода: хранение является жестко статическим. Система не ведет учет остатков в разрезе ячеек. Если товар Товар А сегодня лежит в ячейке 2-1-3, а завтра мы переложили его в 3-2-1, нам придется вручную менять карточку номенклатуры, что делает динамическое адресное хранение невозможным.
Проанализируем ситуацию, когда нам необходимо именно динамическое хранение. То есть система должна четко знать: в ячейке 2-1-3 сейчас лежит 5 штук Комплектующего Х и 10 штук Комплектующего Y, а ячейка 1-1-1 сейчас полностью свободна.
Для реализации этого сценария нам потребуется разработать расширение конфигурации. Разберем архитектуру такого расширения.
Нам необходимо создать следующие объекты метаданных внутри расширения:
Склады. Структура наименования может генерироваться по шаблону "Стеллаж-Полка-Место".Склад, Ячейка, Номенклатура и ресурсом Количество.Далее нам потребуется перехватить проведение документов ПоступлениеТоваровУслуг, РасходнаяНакладная (Реализация) и ПеремещениеТоваров. Сделать это нужно через механизмы общего модуля расширения с использованием аннотации &После или &Вместо для процедур проведения документов.
Рассмотрим пример логики, которую мы заложим в обработчик проведения документа поступления в расширении для распределения товара по ячейкам:
&После("ОбработкаПроведения")
Процедура Расш1_ОбработкаПроведенияПоступления(Отказ, РежимПроведения)
// Проверяем, включено ли адресное хранение для склада документа
Если Не ЭтотОбъект.Склад.АдресныйСклад Тогда
Возврат;
КонецЕсли;
// Записываем данные в наш регистр сведений "АдресныйСкладОстатки"
Для Каждого СтрокаТЧ Из ЭтотОбъект.Товары Цикл
// Здесь должна быть логика поиска свободной ячейки или открытия формы распределения
ЯчейкаНазначения = ОпределитьОптимальнуюЯчейку(ЭтотОбъект.Склад, СтрокаТЧ.Номенклатура, СтрокаТЧ.Количество);
МенеджерЗаписи = РегистрыСведений.Расш1_АдресныйСкладОстатки.СоздатьМенеджерЗаписи();
МенеджерЗаписи.Склад = ЭтотОбъект.Склад;
МенеджерЗаписи.Ячейка = ЯчейкаНазначения;
МенеджерЗаписи.Номенклатура = СтрокаТЧ.Номенклатура;
// Считываем текущий остаток в ячейке
МенеджерЗаписи.Прочитать();
МенеджерЗаписи.Количество = МенеджерЗаписи.Количество + СтрокаТЧ.Количество;
МенеджерЗаписи.Записать();
КонецЦикла;
КонецПроцедуры
Внимание, важный риск! Как справедливо замечено в Сообщении 8, 1С:Бухгалтерия 3.0 обновляется крайне часто (иногда несколько раз в неделю в связи с изменениями законодательства). Любое сложное расширение, которое вмешивается в проведение стандартных документов, рискует "слететь" при очередном обновлении структуры метаданных конфигурации-поставщика. Стоимость поддержки и постоянной адаптации такого расширения силами программиста 1С может быстро превысить стоимость покупки готового решения.
Это один из самых надежных и современных способов решить задачу динамического хранения во Фреше, не ломая код Бухгалтерии. Мы выносим всю сложную складскую логику за пределы 1С.
Для этого используются специализированные мобильные платформы для терминалов сбора данных (ТСД), например:
Выясним, как работает эта схема:
1С:Бухгалтерия 3.0 обменивается с сервером ТСД стандартными документами (Поступление, Перемещение, Реализация). Обмен происходит через готовые модули интеграции, которые поддерживают работу с 1С:Фреш по Web-сервисам (OData или веб-сервисы интеграции).Этот вариант обеспечивает 100% точность учета, минимизирует человеческий фактор и полностью снимает риски сбоев при обновлениях 1С:Бухгалтерии.
Если доработки БП 3.0 кажутся слишком рискованными, а покупка ТСД пока не планируется, рассмотрим самый изящный архитектурный вариант. В рамках подписки 1С:Фреш пользователям часто доступна программа 1С:УНФ (Управление нашей фирмой).
В отличие от Бухгалтерии, в 1С:УНФ складской блок развит значительно сильнее. В нем есть готовый, встроенный "из коробки" функционал — Ячеистые склады.
Разберем, как реализовать задачу в УНФ по шагам:
Как связать это с Бухгалтерией 3.0?
В сервисе 1С:Фреш настраивается стандартный, регулярный и полностью автоматический обмен данными между 1С:УНФ и 1С:Бухгалтерия 3.0.
Проанализируем пункт 4 из запроса автора темы: как вести учет товаров, которые закупаются для перепродажи, но физически не поступают на адресный склад предприятия, а приходят сразу в офис и оттуда же отгружаются клиенту.
Если мы попытаемся проводить такие транзитные товары через единый адресный склад, система заставит нас распределять их по ячейкам стеллажей, которых физически не существует в офисе. Это приведет к путанице и лишним трудозатратам.
Методологически правильное решение заключается в разделении зон ответственности на уровне справочника Склады:
Поступление товаров и услуг и Реализация товаров и услуг оформляются исключительно на склад "Офис (транзитный)".Проанализировав все возможные варианты, сопоставим их по ключевым параметрам, чтобы принять взвешенное решение:
| Критерий | Вариант 1. Справочные реквизиты | Вариант 2. Свое расширение БП | Вариант 3. Интеграция с ТСД | Вариант 4. Связка УНФ + БП |
|---|---|---|---|---|
| Динамическое хранение | Нет (только статическое) | Да | Да (идеально) | Да (штатный режим) |
| Стоимость внедрения | Минимальная (бесплатно) | Средняя (оплата программиста) | Высокая (лицензии + ТСД) | Средняя (настройка обмена) |
| Сложность поддержки при обновлениях | Низкая (нечему ломаться) | Высокая (риск сбоев расширения) | Низкая (интеграция через API) | Низкая (типовой обмен) |
| Удобство для кладовщика | Среднее (бумажные листы) | Низкое (работа у монитора ПК) | Высокое (мобильность с ТСД) | Высокое (удобные АРМ) |
Таким образом, если бюджет компании сильно ограничен, а динамика склада невысокая — начните со схемы виртуального разделения складов (Офис/Склад) и использования статических дополнительных реквизитов (Вариант 1). Если же требуется реальная автоматизация производства с минимизацией ошибок при сборке комплектующих — оптимальным выбором будет переход на связку 1С:УНФ + БП 3.0 (Вариант 4), либо подключение ТСД с готовым решением (Вариант 3).