Использование складской аналитики "Ячейка"

[Елена Сысовская]

Задача покрытия по складам в постановке консультанта выглядит следующим образом:
Центральный склад, на который производится поставка, разделен на ряд складов по видам материалов (ГСМ, металлопрокат, химикаты и пр).
Цеховые склады могут получать материалы с любого центрального склада (в зависимости от вида материала) и, иногда, с прочих цеховых складов.
Для цеховых складов настраивается склад покрытия - Центральный склад, а его склады становятся ячеками. По материалам группа складской аналитики указывается "Склад+Ячейка".
В таком случае покрытие потребностей на цеховом складе при сводном планировании автоматически предлагается просто с центрального склада. В спланированном перемещении с центрального склада на цеховой указывается ячейка вручную.
Мне этот вариант кажется потенциально опасным, но из-за чего - не могу сформулировать.
Если же склады центрального склада оставлять как склады, то можно создать виртуальный склад "центральный", объединить его с центральными складами в группу, и настроить покрытие с него. При перемещении указать склад вручную.
Чема все-таки грозит использование ячеек? почему моя душа так против?

[glibs]

Вопрос интересный, как для меня. Буду рад услышать мнения остальных.

Вы допускаете работу в одном складе с разделением реальных складов ячейками. А для чего этот склад тогда вообще делить? Вы говорите, что центральный склад разделен по видам материалов. Стало быть вопросов о том, к какому реальному складу принадлежит то или иное ТМЦ у вас возникать не должно (если ГСМ, то это склад ГСМ, если металопрокат — склад металопроката, и т.д.).

Использование ячеек проблему разграничения доступа не решает. Да и использование отдельных складов, впрочем, тоже. Какую реальную пользу вам даст использование ячеек? Про более удобную возможность фильтации запасов в наличии — в т.ч. и для построения отчетов — я догадываюсь. Но с этим можно бороться и другими путями.

[Елена Сысовская]

Есть реальность - склады, разделенные километрами, проходными, материально отвественными, и виртуальная реальность (то, что в системе) все таки должна быть логически похожа на жизнь. Я думаю, это важно. Конечно, когда привезли какой-то уголок (1шт) и машина разгружается на складе строительных материалов, то этот уголок туда вполне могут разгрузить, (не поедет машина с одним уголком на другой склад), не смотря на то, что он должен быть на складе металлов - так что жеско зафиксировать принадлежность шифра в определенному складу нельзя. Но пробелема не в этом даже. Я сомневаюсь в корректности использования ячеек для данной цели. Мне кажется (на уровне внутреннего убеждения), что разные склады - это разные склады, а не ячейки. Я не сильна в логистике, но нутром чую, что функциональный смысл ячеек отличается от предлагаемого. Может быть на данном этапе внедрения это не очевидно, но потом можно наткнуться на проблемы, созданные проивзольным использованием функционала. В частности, использование ячеек для комплектации, буферные ячейки , специальные ссылки на ячейки - источники и ячейки назначения при отгрузке - приемке, и так далее. Пока это все "жирности", а потом принятая схема может блокировать использование функционала.
Насколько я понимаю, проблема покрытия, возникшая при существующей схеме организации складов, решена в 3.0. Думаю, это надо протестирировать.

[glibs]

Цитата:

Изначально опубликовано Елена Сысовская
...Я сомневаюсь в корректности использования ячеек для данной цели....

Тут я с вами согласен. Ячейки лучше забросить (оставить для других целей).

У меня тут идейка появилась...

Значит номенклатура, которой положено лежать на одном складе, может храниться и на другом... Это существенное уточнение к изложенной выше задаче. Остается еще один очень существенный вопрос. У цеховых складов один склад пополнения — центральный — или несколько. То, что они могут получать и с прочих складов я прочитать смог. Вопрос стоит так: устроит ли вас то, что система будет автоматически генерировать предложения на перемещение только с центрального склада. Перемещения же во всех остальных направлениях (с цехового склада на цеховой склад, с одного центрального склада на другой центральный склад) вам придется создавать вручную?

Если такое вам подходит, то можно пойти другим путем. Я несколько упрощу задачу, чтобы было меньше текста.

Имеем Центральный склад ГСМ (ЦСГ), Центральный склад металопроката (ЦСМ), Центральный склад химикатов (ЦСХ). Есть n цеховых складов. Рассмотрим только один. Для него в Аксапте можно завести аж три склада: Склад ГСМ первого цеха (СЦ1Г), Склад металопроката первого цеха (СЦ1М), Склад химикатов первого цеха (СЦ1Х).

Настраиваем покрытие (покрывемый склад <<<<< основной склад):

СЦ1Г <<<<< ЦСГ
СЦ1М <<<<< ЦСМ
СЦ1Х <<<<< ЦСХ

и т.д. для всех остальных складов n-1 цехов.

Т.о. единый с физической точки зрения склад цеха будет в Аксапте реализован несколькими складами (в понятиях системы). Думаю, что это не страшно, т.к. для каждой номенклатуры можно указать «свой» склад, который будет попадать в строки производственных журналов или в строки заказов (уж не знаю, чем вы там занимаетесь). По идее, степень автоматизации работы пользователей от такой схемы не должна пострадать. Хотя все зависит от обстоятельств.

Надеюсь, это вам хоть в чем-то поможет. Спасибо за интересный вопрос.

Цитата:

Изначально опубликовано Елена Сысовская
...Насколько я понимаю, проблема покрытия, возникшая при существующей схеме организации складов, решена в 3.0. Думаю, это надо протестирировать...

Что вы имеете в виду? Разница в системе покрытия в 3.0 и 2.5 существенная. Возможно многоуровневое покрытие, а также индивидуальная (для мест хранения) настройка большинства параметров, влияющих на механизм покрытия. Но для решения данной проблемы я ничего кардинального не вижу.

Может я проблему не так понял? Или что-то не досмотрел? Если что-то найдете, напишите, пожалуйста.