Суть задачи: необходимо вести партионный учет в разрезе адресов хранения с минимальными доработками. При этом было необходимо конфигурировать максимально "сбоку" от типового решения.
Решение задачи свелось к небольшим доработкам типовой УТ 10.3.
Что для этого собственно было сделано:
1. В настройках учета установлена возможность указания складов для документов поступления и реализации.
2. В формах складских документов (поступление, реализация) добавлена возможность выбора ГРУПП(!) справочника «Склады»
3. Разработана простенькая обработка табличных частей, которая на основании выбранной папки справочника склад, проставляла в табличной части соответствующие склады (смотрит по остаткам партий в соответствии с выбранной стратегией списания партий).
4. Разработаны (доработаны) стандартные печатный формы и прикреплены как внешние с новой колонкой «Адреса».
Плюсы такого подхода:
1. Минимальные доработки конфигурации, которые легко переносить (если вдруг потребуется) при обновлениях.
2. Использование стандартных складских отчетов для анализа, как остатков, так и адресной логистики
3. Автоматический подбор адресов при отгрузке товара избавил менеджеров помнить, где что лежит (как было при ручной адресации, когда перед менеджером лежала карта адресного пространства).
4. Легкое конфигурирование внешних доработок.
5. Возможность хранения разного товара на одном адресе, что каким-то образом очень сильно понравилось кладовщикам. Т.к. при ручной адресации им приходилось жестко соблюдать требование «один адрес — один товар».
6. В справочник склады можно зашить практически любую иерархическую систему адресного хранения любой глубины.
7. Потенциал для дальнейшей разработки по контролю заполняемости объема, веса ячеек на основании механизма свойств и категорий (чтобы не перегружать ячейки).
8. Самый главный плюс — довольный клиент. Тем более что решение его проблемы было предложено нами. Ну и цена соответственно для такого объема доработок довольно низкая.
Минус такого подхода:
1. Естественный минус — дополнительный ручной труд при внесении поступлений и перемещений (т.к. надо указывать адреса прибытия ТМЦ).
2. Минус сомнительный. Документ «Перемещение товаров» не имеет в табличной части колонок «Склад отправитель» и «Склад получатель». Здесь есть два варианта — допилить документ или написать внешнюю обработку, которая будет прокладкой между пользователем и массовым созданием нужных документов перемещение. (В нашем случае Заказчик решил ничего не делать и просто загрузил кладовщиков заставив последних ОЧЕНЬ ТЩАТЕЛЬНО планировать загрузку ячеек, т.к. любое необоснованное перемещение сразу же порождало введение кучи документов по перемещению. Кладовщики получили серьезный стимул для оптимизации своей работы).
3. Минус сомнительный. Выгрузка в БП при включенной настройке «Указание складов в табличных частях» не производится в разрезе складов. Решили не связываться, т.к. для бухгалтерии этот вопрос оказался не важен.
Как это работает.
1. Кладовщики разработали систему адресного хранения (это уже у них было, только велось на коленке). Эта система была отражена в иерархическом справочнике «Склады», где самым нижним элементом был конкретный адрес хранения.
2. При поступлении товара приемщик ПО ФАКТУ РАССОРТИРОВКИ ТМЦ ПО СКЛАДУ заполняет специальную форму (фактически это внешняя печатная форма «Накладная» с пустыми адресами), на основании которой вносит адрес хранения в каждую строку табличной части в поле «Склад» (в шапке склад может быть любой) документа «Поступление товаров и услуг».
3. При реализации менеджер в шапке вводит нужную ему ПАПКУ(!) (например, Склад №1), заполняет табличную часть номенклатурой и выполняет внешнюю обработку табличной части «Заполнить по адресам». Обработка пробегает по табличной части и по остаткам партий подбирает в соответствии о стратегией списания партий верхнюю или нижнюю партию и подставляет в соответствии с этим нужный адрес (который находится в иерархии склада, выбранного в шапке документа) в табличную часть. Документ абсолютно стандартно проводится. Печатается внешняя печатная форма «Накладная» с адресами из табличной части и отдается кладовщику. Он по накладной собирает заказ и отдает покупателю.
4. Если вдруг всплывает пересорт, то менеджер смотрит в отчет по остаткам или в подбор и подбирает ближайший адрес, где есть остаток ТМЦ. Разборки по пересорту оставляют на потом.
Подразумевая, что здесь мало мальски конфигурируют — не выкладываю эти простые доработки (ну не пару запросов и печатных форм ведь выкладывать).
П.С. Это моя первая публикация на инфостарте, буду благодарен критику. Надеюсь окажется кому-то полезным.
Интересный подход.
Но что вы подразумеваете под адресом? Крупную часть склада? Тогда все нормально.
У нас ячейка имеет размер палеты или какую-то долю от нее. Это сколько же складов нужно создать?
Интересно, но выскажу свое мнение.
Поддерживаю предыдущий коммент.
Адрес (ячейка) для нормального хранения должен быть минимальным в площади склада. А от сюда вылезает катастафически громоздкое дерево складов. И тут уж крайне сомнителен такой подход.
Возможно автор путает понятия «склад» и «ячейка».
А чем собственно «убог и неудобен» встроенный механизм? Может быть, вы «просто не умеете его готовить»?
Например, то что вы пишете в плюсы
— «Автоматический подбор адресов при отгрузке товара избавил менеджеров помнить где что лежит» — Оно и в типовой системе не надо помнить.
— «Возможность хранения разного товара на одном адресе, что каким то образом очень сильно понравилось кладовщикам. Т.к. при ручной адресации им приходилось жестко соблюдать требование «один адрес — один товар»» — Это что за требование такое??
Вообще, что вы подразумеваете под «ручной адресацией»?
А вот все минусы из категории «сомнительные» я бы перевел в «крайне отрицательные». По-крайней мере для нас (тоже крупная оптовая компания, лидер региональных продаж)
И еще: а как решили вопрос с инвентаризацией?
(1)(2)
Адрес в моем понимании это ячейка (ну типа так: склад1-ряд4-стеллаж8-полка3-ячейка3). Да, дерево складов получилось очень (очень! это два огромных крытых склада) громоздким. Но его заполнение производилось один раз в начале, загрузили из экселя простой обработкой. Карту адресов кладовщики знали уже наизусть в силу ручной адресации в прошлом.
Собственно намек на решение типовым способом этой задачи заставил меня задуматься. Если вы подскажете как получить остатки в разрезе ячеек с использованием типовых механизмов, я с удовольствием поучусь правильно «готовить» ;).
Важно ведь не просто указать в регистре «Места хранения» где лежит товар, в силу различных причин размещение может мигрировать по складу. Нет остатков в разрезе ячеек — нет полноценной аналитики. Кладовщик может лишь подсказать где «обычно» лежит такой товар. Какие тут могут быть варианты?
(2)не сразу увидел про инвентаризацию вопрос.
Инвентаризация тоже слегка допиливалась. Добавлена колонка Склад в табличную часть товары и пара обработок табличных частей. Одна собирает остатки по партиям и заполняет остатки в разрезе складов в табличной части.
Вторая формирует пачки документов Оприходования и Списания в разрезе складов после ввода отклонений.
Повторюсь, одним из условий задачи было минимальное конфигурирование типовой.
Если поделитесь своей ситуацией по категорическим минусам буду премного благодарен 😉 Интересен разнообразный опыт в этой области.
(2) не удобно отвечать на отредактированные сообщения ))
— «Автоматический подбор адресов при отгрузке товара избавил менеджеров помнить где что лежит» — Оно и в типовой системе не надо помнить.
в типовой конфе нет адресного хранения, т.к. система подсказывает откуда надо забирать товар, то и указание это более конкретное для кладовщика. Если большой склад, все лежит в разных местах, кладовщик забирает обычно то что ближе к нему лежит. Иногда товар (портящийся) может месяцами лежать в дальнем углу и до него могут просто не доехать. Тут же либо ФИФО либо ЛИФО и система пошлет забирать товар в нужный угол.
Вообще, что вы подразумеваете под «ручной адресацией»?
«Ручная адресация» )) это привнесенный бытовой термин, пока не было автоматизировано у кладовщиков была карта складов — пачка бумаги, где расписано где что должно лежать. Из-за того, что склад круглосуточный и товар все время движется, иметь привязку к местам хранения (аналогично как в регистре сведений) было не возможно. Тогда (до автоматизации) было принято решение руководством грузить конкретные стеллажи конкретным товаром. Но и тут у них бывало случался коллапс, когда приходил новый товарняк или фура и не хватало места в указанных местах для конкретного товара, т.к. забрать большой объем этого же товара должны были, например через пару часов. Бардак в общем. Это все велось на бумажках или в УТ писали в коментах поступлений где поставка лежит.
Ну а после автоматизации эти проблемы сами собой отвалились. Пересорт — да бывает, но его не много и он довольно быстро устраняется.
Данная идея разбивки склада на ячейки имеет право жить, не смотря на критику.
> Нет остатков в разрезе ячеек — нет полноценной аналитики.
все очень индивидуально. общие решения для частных ситуаций — могуть быть весьма трудозатратными/излишними.
по сути — любой учет, приближающийся к WMS преследует лишь одну цель — не дать сделать неправильно.
Сильно ли такой подход перегрузит сервер 1С если ячеек тысячи?
Недавно начал работать с производственной компанией, в базе чуть больше 2500 складов, оформленных как ячейки, вот откуда ноги растут….
Мне ещё 10 лет назад в 7.7 пришлось дописывать адресное хранение. Из изменений типовой части конфигурации — кнопка на формах документов товародвижения и вызов дополнительной процедуры в их обработках проведения. Четырёхкомпонентный адрес (стеллаж-стойка-ярус-ячейка), маршрутизация по оптимальному маршруту обхода склада, включая команду кладовщику развернуться, если быстрее будет вернуться к началу стеллажа, а не идти в том направлении, в котором он движется в данный момент. Для офиса ничего не изменилось, вся работа с размещением была на операторе склада, причём доступа к первичным документам они в 1С не имели.
И тоже не помню, чтобы это было как-то напряжно по объёмам доработки.
Вы пишите, что один адрес-один товар.Это, так должно быть правильно. Я кладовщик у меня на адресе к18-01-04/03 лежит 5 разных товаров( от большего к меньшему по габаритам) забрав нижний товар я часть верхнего товара переставил на соседнюю ячейку (ВВЕРХ ВНИЗ В БОК), он мне мешал взять свой товар и по цепочке он ушел с ячейки в неизвестном направлении..Гоните своих ленивых кладовщиков, либо они не союирают товар, либо они вам льстили, чтоб вы отстали. Вопрос по партиям при адресном хранении для меня остался открытым.
для 1С 7.7. торговля и склад есть готовый отлаженный модуль для адресного хранения от ZAVSKLAD.COM. всё необходимое в нем реализовано, просто, понятно и без излишеств. это конечно не монстр Управление Торговлей в 1С8, но для средних и малых складов и предприятий — как раз.