Реализация ордерного ячеистого склада непосредственно в конфигурации 1С:Бухгалтерия 8 (БП) является нетиповой задачей. Конфигурация БП изначально разработана для ведения бухгалтерского и налогового учета, и ее функционал не включает полноценный оперативный складской учет с детализацией до ячеек и ордерной схемой. Для таких целей обычно используются специализированные решения, такие как 1С:Управление торговлей (УТ) или 1С:ERP Управление предприятием.
Однако, когда установка отдельной конфигурации (например, УТ) или использование обменов с другой базой нежелательна, возникает потребность в адаптации 1С:Бухгалтерии. Рассмотрим различные подходы к решению этой задачи, анализируя их преимущества, недостатки и технические особенности. Мы сосредоточимся на том, как можно организовать количественный учет по ячейкам, приход, расход, перемещение между ячейками и формирование бухгалтерских документов с заполнением на основе этих данных, а также рабочее место кладовщика.
Этот подход является наиболее гибким и наименее инвазивным для типовой конфигурации 1С:Бухгалтерия. Он позволяет реализовать полноценный оперативный складской учет, не затрагивая при этом логику бухгалтерских проводок и остатков по БУ-счетам.
Для минимизации изменений в типовой конфигурации и упрощения будущих обновлений, всю новую функциональность рекомендуется реализовывать с помощью РасширенияКонфигурации. В расширении мы создадим:
ЯчейкиХранения: Для ведения списка всех ячеек склада. Можем предусмотреть иерархию (например, по зонам, стеллажам) или дополнительные реквизиты (тип ячейки, вместимость).ЗоныХранения (опционально): Если требуется дополнительная аналитика по зонам.Эти документы будут фиксировать факты движения товаров на складе, не создавая при этом бухгалтерских проводок. Ордерная схема подразумевает, что фактическое движение товара и его отражение в управленческом учете происходит независимо от финансового документа.
ОрдерНаПоступлениеТоваров: Фиксирует факт физического поступления товаров в конкретные ячейки. Может заполняться на основании типовых документов ПоступлениеТоваровУслуг или вводиться отдельно.ОрдерНаОтгрузкуТоваров: Фиксирует факт физической отгрузки товаров из конкретных ячеек. Может заполняться на основании РеализацияТоваровУслуг.ПеремещениеМеждуЯчейками: Документ для внутренних перемещений товаров между ячейками склада. Это движение не должно отражаться в бухгалтерском учете, поскольку с точки зрения БУ товар остается на одном складе.ИнвентаризацияЯчеек: Для проведения инвентаризаций по ячейкам.Для хранения остатков и движений товаров в разрезе ячеек. Эти регистры будут хранить данные управленческого учета.
ОстаткиТоваровВЯчейках: Регистр остатков, который будет хранить информацию о количестве и, возможно, стоимости (для управленческих целей) товаров в каждой ячейке.ДвиженияТоваровПоЯчейкам (опционально): Регистр оборотов для анализа истории перемещений.Пример структуры регистра ОстаткиТоваровВЯчейках:
РегистрНакопления.ОстаткиТоваровВЯчейках (ВидРегистра = Остатки)
Измерения:
Номенклатура (СправочникСсылка.Номенклатура)
Характеристика (СправочникСсылка.ХарактеристикиНоменклатуры) - если используется
Серия (СправочникСсылка.СерииНоменклатуры) - если используется
Ячейка (СправочникСсылка.ЯчейкиХранения)
Ресурсы:
Количество (Число)
Стоимость (Число, опционально)
Основная идея заключается в том, что типовые бухгалтерские документы (ПоступлениеТоваровУслуг, РеализацияТоваровУслуг, ПеремещениеТоваров) будут продолжать работать по типовой логике, отражая агрегированные данные по складу в целом (например, по счету 41.01). Наши же ордерные документы будут детализировать движения до ячеек.
Для связки мы можем:
ПоступлениеТоваровУслуг, и на его основании вводит ОрдерНаПоступлениеТоваров, указывая фактическое размещение в ячейках.ПоступлениеТоваровУслуг или РеализацияТоваровУслуг на основе данных из ордеров, если нужно отслеживать расхождения. Например, в документе РеализацияТоваровУслуг пользователь выбирает номенклатуру, а затем специальная форма позволяет выбрать ячейки, из которых будет отгружен товар, и автоматически подставить количество.Для обеспечения корректности управленческого учета по ячейкам, необходимо встроить механизм контроля остатков. Рассмотрим, как это можно сделать, не меняя типовой механизм:
ПоступлениеТоваровУслуг и РеализацияТоваровУслуг (или других, которые влияют на складские остатки) с помощью расширения.ОстаткиТоваровВЯчейках.Сложность заключается в том, что одна строка из первичного бухгалтерского документа может "разъезжаться" по разным ячейкам. Для этого можно:
ПоступлениеТоваровУслуг и РеализацияТоваровУслуг добавляем кнопку или команду, которая открывает специальную форму подбора товаров по ячейкам.Пример кода (концептуальный) для вызова формы:
// В расширении, в модуле формы документа ПоступлениеТоваровУслуг
&НаКлиенте
Процедура ЗаполнитьЯчейки(Команда)
// Получаем данные текущей строки табличной части
ТекущаяСтрока = Элементы.Товары.ТекущиеДанные;
Если ТекущаяСтрока = Неопределено Тогда
Возврат;
КонецЕсли;
ПараметрыФормы = Новый Структура;
ПараметрыФормы.Вставить("Номенклатура", ТекущаяСтрока.Номенклатура);
ПараметрыФормы.Вставить("Количество", ТекущаяСтрока.Количество);
// Дополнительные параметры, если нужно
// Открываем форму выбора ячеек (из нашего расширения)
ОткрытьФорму("Документ.ОрдерНаПоступлениеТоваров.Форма.ФормаВыбораЯчеек", ПараметрыФормы, , , , , РежимОткрытияФормы.БлокироватьОкноВладельца);
// После закрытия формы, можно получить выбранные ячейки
// и создать движения по ОрдеруНаПоступлениеТоваров
КонецПроцедуры
Потребуются собственные отчеты по остаткам и движениям ТМЦ в разрезе ячеек. Можно взять за основу отчеты из подсистемы "Руководителю" (управленческие отчеты). Создание этих отчетов через расширения может быть трудоемким, так как для полноценной работы может потребоваться засосать значительную часть конфигурации в расширение. Альтернативно, можно сделать внешние отчеты, построенные на СКД (Система Компоновки Данных), и предоставить их пользователям как "особые" отчеты.
Данный подход предполагает попытку использования существующих механизмов бухгалтерского учета для детализации по ячейкам.
Можно добавить дополнительное субконто, например, Ячейка, к счетам учета товаров (например, 41 "Товары" или 10 "Материалы"). Это позволит вести остатки по номенклатуре в разрезе ячеек непосредственно на бухгалтерских счетах.
Для реализации нам потребуется:
ЯчейкиХранения.ПланСчетов.Хозрасчетный) для счетов 10 и 41 добавить новое субконто с типом СправочникСсылка.ЯчейкиХранения.ПоступлениеТоваровУслуг, РеализацияТоваровУслуг, ПеремещениеТоваров), чтобы они запрашивали и записывали информацию о ячейках.Этот подход имеет серьезные недостатки и не рекомендуется вендором 1С, особенно при использовании метода оценки МПЗ по FIFO (First In, First Out) или LIFO (Last In, First Out).
Этот подход малопригоден для полноценного ячеистого склада, особенно если требуется ордерная схема и высокая производительность. Может быть рассмотрен только для очень простых случаев с небольшим количеством ячеек и без сложных методов оценки запасов.
Это вариант, который позволяет избежать изменения типовой логики учета на балансовых счетах, но требует значительного ручного труда и не предоставляет полноценной автоматизации.
Можно создать новый забалансовый счет, например, ЗБ.Ячейки, и настроить для него аналитики (субконто): Номенклатура и Ячейка. Все движения по ячейкам будут отражаться ручными бухгалтерскими справками или специально разработанными документами, формирующими записи только по этому забалансовому счету.
Приход товара в ячейку оформляется как Дебет ЗБ.Ячейки (Номенклатура, Ячейка), расход – как Кредит ЗБ.Ячейки.
Оборотно-сальдовая ведомость по счету для ЗБ.Ячейки.Этот подход может быть использован как временное или "бюджетное" решение для очень небольшого склада с малым количеством операций, где ручной контроль приемлем. Он не является полноценной заменой ячеистого учета.
Когда потребности в ячеистом учете достаточно велики, а возможности 1С:Бухгалтерии сильно ограничены, можно рассмотреть более радикальный вариант.
Создание отдельной небольшой базы данных для складского учета, специально заточенной под ячейки, а затем настройка обмена данными с основной базой 1С:Бухгалтерия.
Такая микро-база может быть реализована на платформе 1С:Предприятие с минимальным набором объектов: 2-3 документа, 3-4 справочника и один-два регистра накопления.
Альтернативно, это может быть специализированная система WMS (Warehouse Management System), которая предназначена исключительно для управления складом и затем интегрируется с БП.
Этот вариант подходит для компаний, у которых серьезные требования к ячеистому учету, но при этом они категорически не хотят использовать типовые УТ/ERP из-за их избыточности. Это более масштабируемое решение, чем глубокая доработка БП.
Для очень простых случаев, когда фактическое количество ячеек невелико, а оперативный контроль не является жестким требованием, можно обойтись без сложной автоматизации.
Ограничиться справочной информацией о расположении товаров. Например, можно использовать:
Подойдет только для компаний, где ячеистый учет не является критически важным, и где текущие процессы могут быть покрыты простейшими справочными данными.
Независимо от выбранного подхода, мы всегда должны помнить о некоторых общих принципах и возможных сложностях:
Важнейший принцип – это четкое разделение бухгалтерского учета (БУ) и управленческого учета (УУ). 1С:Бухгалтерия предназначена для БУ, и любые попытки "запихнуть" туда детальный управленческий учет по ячейкам будут либо нежизнеспособными, либо очень дорогими в поддержке. Наша цель – создать параллельный УУ для склада, который затем будет агрегировать данные для заполнения типовых БУ-документов.
Мы настоятельно рекомендуем использовать расширения конфигурации для всех доработок. Это позволяет:
Однако даже с расширениями могут возникнуть сложности при серьезных изменениях в логике типовой конфигурации 1С, например, в механизмах контроля остатков или ценообразования. Поэтому проектирование должно быть максимально осторожным.
Обязательно предусмотрите удобное рабочее место для кладовщика. Оно должно быть максимально простым и интуитивно понятным, чтобы сотрудник склада мог легко принимать, размещать, перемещать и отгружать товары, видя текущие остатки по ячейкам. Возможно, потребуется интеграция с терминалами сбора данных (ТСД) для автоматизации процесса.
Разработайте комплект отчетов, которые позволят анализировать остатки и движения товаров в разрезе ячеек, а также контролировать расхождения между управленческим и бухгалтерским учетом (если таковые могут возникнуть).
Необходимо четко осознавать, что любая нетиповая реализация ячеистого склада в 1С:Бухгалтерии будет иметь высокую стоимость владения. Это включает в себя затраты на разработку, внедрение, обучение пользователей, а также постоянную поддержку и адаптацию при обновлениях конфигурации. Часто эти затраты превышают стоимость внедрения и поддержки типового решения (УТ или ERP) в отдельной базе с обменом.
Перед началом разработки критически важно провести глубокий анализ бизнес-процессов на складе. Иногда то, что на первый взгляд кажется сложным "ячеистым складом", на самом деле может быть решено простой "Виртуальной Печатной Формой с разбивкой по участкам", чтобы кладовщикам было удобнее собирать товар и делать ревизии по товарной группе. Не всегда требуется городить сложный учет там, где достаточно справочной информации.
В заключение, хотя внедрение ордерного ячеистого склада в 1С:Бухгалтерии возможно, мы рекомендуем тщательно взвесить все "за" и "против". Наиболее жизнеспособным и гибким представляется подход с параллельным управленческим учетом через расширения и регистры накопления. Однако, если потребности в складском учете растут, рано или поздно компания придет к необходимости использования специализированных систем, таких как 1С:Управление торговлей или 1С:ERP.