AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 24.03.2003, 17:29   #1  
Елена Сысовская is offline
Елена Сысовская
Участник
Аватар для Елена Сысовская
 
499 / 25 (1) +++
Регистрация: 30.11.2001
Адрес: планета Земля
Использование складской аналитики "Ячейка"
Задача покрытия по складам в постановке консультанта выглядит следующим образом:
Центральный склад, на который производится поставка, разделен на ряд складов по видам материалов (ГСМ, металлопрокат, химикаты и пр).
Цеховые склады могут получать материалы с любого центрального склада (в зависимости от вида материала) и, иногда, с прочих цеховых складов.
Для цеховых складов настраивается склад покрытия - Центральный склад, а его склады становятся ячеками. По материалам группа складской аналитики указывается "Склад+Ячейка".
В таком случае покрытие потребностей на цеховом складе при сводном планировании автоматически предлагается просто с центрального склада. В спланированном перемещении с центрального склада на цеховой указывается ячейка вручную.
Мне этот вариант кажется потенциально опасным, но из-за чего - не могу сформулировать.
Если же склады центрального склада оставлять как склады, то можно создать виртуальный склад "центральный", объединить его с центральными складами в группу, и настроить покрытие с него. При перемещении указать склад вручную.
Чема все-таки грозит использование ячеек? почему моя душа так против?
__________________
"...жизнь проходит, пока мы строим планы на жизнь..."
с уважением, ESys.
Старый 24.03.2003, 22:46   #2  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Вопрос интересный, как для меня. Буду рад услышать мнения остальных.

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

Использование ячеек проблему разграничения доступа не решает. Да и использование отдельных складов, впрочем, тоже. Какую реальную пользу вам даст использование ячеек? Про более удобную возможность фильтации запасов в наличии — в т.ч. и для построения отчетов — я догадываюсь. Но с этим можно бороться и другими путями.
__________________
С уважением,
glibs®
Старый 25.03.2003, 08:43   #3  
Елена Сысовская is offline
Елена Сысовская
Участник
Аватар для Елена Сысовская
 
499 / 25 (1) +++
Регистрация: 30.11.2001
Адрес: планета Земля
Есть реальность - склады, разделенные километрами, проходными, материально отвественными, и виртуальная реальность (то, что в системе) все таки должна быть логически похожа на жизнь. Я думаю, это важно. Конечно, когда привезли какой-то уголок (1шт) и машина разгружается на складе строительных материалов, то этот уголок туда вполне могут разгрузить, (не поедет машина с одним уголком на другой склад), не смотря на то, что он должен быть на складе металлов - так что жеско зафиксировать принадлежность шифра в определенному складу нельзя. Но пробелема не в этом даже. Я сомневаюсь в корректности использования ячеек для данной цели. Мне кажется (на уровне внутреннего убеждения), что разные склады - это разные склады, а не ячейки. Я не сильна в логистике, но нутром чую, что функциональный смысл ячеек отличается от предлагаемого. Может быть на данном этапе внедрения это не очевидно, но потом можно наткнуться на проблемы, созданные проивзольным использованием функционала. В частности, использование ячеек для комплектации, буферные ячейки , специальные ссылки на ячейки - источники и ячейки назначения при отгрузке - приемке, и так далее. Пока это все "жирности", а потом принятая схема может блокировать использование функционала.
Насколько я понимаю, проблема покрытия, возникшая при существующей схеме организации складов, решена в 3.0. Думаю, это надо протестирировать.
__________________
"...жизнь проходит, пока мы строим планы на жизнь..."
с уважением, ESys.
Старый 25.03.2003, 20:27   #4  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Изначально опубликовано Елена Сысовская
...Я сомневаюсь в корректности использования ячеек для данной цели....
Тут я с вами согласен. Ячейки лучше забросить (оставить для других целей).

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

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

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

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

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

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

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

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

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

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

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

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Сравнение в разрезе складской аналитики. longson DAX: Программирование 3 14.01.2008 13:45
Использование "like" при работе с классом "QueryBuildRange" poul DAX: Программирование 18 11.08.2006 12:20
Отчет типа "ОСВ по счету в разрезе аналитики" kosenkov DAX: Функционал 13 02.03.2006 16:57
Как сбросить флаг "Используется" в форме "Складской журнал" ATimTim DAX: Функционал 1 24.06.2004 19:19
Использование аналитики vs. возможные проблемы Boris DAX: Функционал 23 02.12.2002 12:07
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:56.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.