DAX 2009 RU5. Ответственное хранение.

[Ich@Ru]

В текущей реализации решалась задача формирования базы для расчета хранения. Поэтому в определенный момент времени хранимому товару соответствует одна номенклатура хранения. Правила подбора описаны в разделе "Настройка и расчет стоимости хранения" (документация для RU5).
Относительно тарифа по обработке паллет. Здесь ситуация может быть более сложная: овертайм склада, работа в выходные/праздники может тарифицироваться по ставкам отличным от ставки за обработку в рабочее время. Для формирования счета за обработку паллет, видится целесообразным, формирование отчета в нужном разрезе (например, в разрезе работ в рабочее время, овертайм, выходной) за определенный период. И выставление счета на основании данных данного отчета.
Ваша идея понятна, и в некотором общем варианте может быть реализован данный алгоритм. Необходимо для сформированной базы операций хранения формировать информацию по доп услугам. Но тут необходимо указать некоторый набор групп услуг. И все услуги (хранение. обработка) должны быть привязаны к одной из групп. Чтобы для каждой группы система искала нужный тариф. В целом модификация несложная, но требуется сформулировать некоторый стандартный набор услуг, который потенциально мог бы быть включен в стандартную версию.

[Lz_]

Цитата:

Сообщение от Ich@Ru

В текущей реализации решалась задача формирования базы для расчета хранения. Поэтому в определенный момент времени хранимому товару соответствует одна номенклатура хранения. Правила подбора описаны в разделе "Настройка и расчет стоимости хранения" (документация для RU5).

Да, читал. С этим вопросов не возникло. Всегда хранимому товару соответствует одна номенклатура хранения . Другое дело номенклатура расчета. В этом случае, хотелось бы видеть соответствие одной номенклатуре хранения нескольким номенклатурам расчета, которые, в свою очередь, имеют разные единицы измерения и формулы расчета этих единиц измерения. Тем самым можно закрыть стандартные (типовые) наборы услуг см ниже п.1-4.

Цитата:

Сообщение от Ich@Ru

Относительно тарифа по обработке паллет. Здесь ситуация может быть более сложная: овертайм склада, работа в выходные/праздники может тарифицироваться по ставкам отличным от ставки за обработку в рабочее время. Для формирования счета за обработку паллет, видится целесообразным, формирование отчета в нужном разрезе (например, в разрезе работ в рабочее время, овертайм, выходной) за определенный период. И выставление счета на основании данных данного отчета.

Это справедливо для крупного логистического центра с режимом работы 24/7. В таком случае, ИМХО, решение с приходыванием номенклатур расчета на склад выглядит не сильно красивым и гибким в плане ценообразования и работы с тарифами за обработку. На мой взгляд, более гибкое решение получилось бы, если бы была возможность увязки результатов расчета не с Управлением запасами через приход/расход номенклатуры, а с модулем Проекты. В таком случае можно разрулить изменения цен за дополнительный дискомфорт (ночь, праздники, выходные) через категории. Используя функциональность Проектов можно лепить дополнительные услуги стандартными журналами модуля проект, например, натерли все яблоки клиента до блеска - 300 рублей, и автоматически включать эти суммы в выставляемые счета. То есть включается весь функционал выставления счетов по проектам и т.д и т.п. Но модуль Проекты есть не у всех, а из тех у кого он есть - мало кто им пользуется. А зря .

Цитата:

Сообщение от Ich@Ru

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

В большинстве случаев, на складах с WMS используют стандартный набор услуг и простые механизмы привязанные к палето-месту:
То что можно посчитать на основе данных системы:
1. Плата за обработку входящей палеты; (руб. за палету)
2. Плата за хранение одной палеты; (руб за палетоместо-сутки)
3. Плата за обработку исходящей палеты;(руб. за палету)
4. Плата за комплектацию (как правило за шт, м.куб, вес). Данные можно брать из маршрута комплектации.
То что нельзя посчитать на основе данных системы:
5. Доп услуги не вошедшие в п.1-4 и вносимые вручную на складе. Иногда эти услуги могут быть вообще разовые и уникальные (см. выше пример про яблоки ).

[Ich@Ru]

Цитата:

Всегда хранимому товару соответствует одна номенклатура хранения

Некорректно написал в первоначальном ответе. Надо читать как: Поэтому в определенный момент времени хранимой номенклатуре соответствует одна номенклатура расчета.

Согласен, что в перспективе можно "научить систему" рассчитывать обработку входящей/исходящей паллеты. Отдельный момент комплектация, но тоже реализуемо.

[Lz_]

Цитата:

Сообщение от Ich@Ru

Некорректно написал в первоначальном ответе. Надо читать как: Поэтому в определенный момент времени хранимой номенклатуре соответствует одна номенклатура расчета.

Я не понял к чему такое ограничение. Что нарушается в алгоритме формирования базы расчета, если одной номенклатуре хранения соответствует несколько номенклатур расчета?

Еще хотелось бы добавить по пункту 5 по поводу доп услуг. Для реализации функции учета доп.услуг при функционале RU5 приходится приходовать на склад номенклатуру хранения ДопУслуги. По сути это услуга и у нее не может быть остатка, но кроме остатка еще у этой псевдо-номенклатуры обязательно должна быть партия . Мало того, по этим номенклатурам остатки постоянно увеличиваются и приходится время от времени делать списание этой номенклатуры со склада. Короче, некузяво как-то. Хотя учетную задачу решить можно.

[Ich@Ru]

Решалась задача расчета хранения. Для товарной единицы в любой момент времени может быть только один действующий тариф за хранение.

Приходование номенклатуры расчета хранения позволяет контролировать, что надо продать клиенту (остаток по данной номенклатуре должен быть ноль), партия позволяет определить дату, на которую следует найти ставку для номенклатуры расчета хранения.
Относительно Доп услуг тут в принципе необходимо оприходовать на склад работу-услугу (с помощью склад журнала), желательно с аналитиками Владелец и Партия, что позволит идентифицировать кому и по чем продать. Счет же выставляется за период, а ставка в течении периода могла изменяться.

[Lz_]

Цитата:

Сообщение от Ich@Ru

Решалась задача расчета хранения. Для товарной единицы в любой момент времени может быть только один действующий тариф за хранение.

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

Цитата:

Сообщение от Ich@Ru

Приходование номенклатуры расчета хранения позволяет контролировать, что надо продать клиенту (остаток по данной номенклатуре должен быть ноль), партия позволяет определить дату, на которую следует найти ставку для номенклатуры расчета хранения.

Ок. Понятно. С этим я разобрался .

Цитата:

Сообщение от Ich@Ru

Относительно Доп услуг тут в принципе необходимо оприходовать на склад работу-услугу (с помощью склад журнала), желательно с аналитиками Владелец и Партия, что позволит идентифицировать кому и по чем продать. Счет же выставляется за период, а ставка в течении периода могла изменяться.

Если работу-услугу оприходовать на склад аналогично номенклатуре расчета, указав при этом аналитики Владелец и Партия, то система красиво "подхватит" эти доп услуги и внесет их в заказ клиента. Но, доп услуг не будет в отчете по хранению. А отчет должен совпадать с результирующим заказом и в итоге со счетом. Вот и приходится доп услуги оприходовать на склад подобно номенклатуре хранения, которая имеет свою номенклатуру расчета ед.изм=количество. В таком случае получаем красивый отчет по хранению и совпадающий с ним заказ на продажу (счет).

Это я побрюзжал немножко, прошу мое брюзжание не принимать близко к сердцу

[Ich@Ru]

Lz_, основная задача - это предоставить платформу, на которой уже гораздо проще выполнять доработки под клиента. Необходимо было реализовать задачи, которые нельзя было решить стандартными средствами, например, расчет хранения. Обработку паллет и услуги за работы можно решить стандартными способами (собрать статстистику по приходу\расходу паллет, а работы проводить через склад журналы).
Сделать веритикальное решение, которое удовлетворит любого клиента и не потребует доработок нереально. Касательно, той же обработки паллет, как говорил, кроме того что влияет время обработки (овертайм, выходные), еще влияют типы работ (ручная выгрузка, механизированная, наемная бригада и прочее). Если в процессе дискуссии проявляются вещи, которые позволят усилить функционал, они будут учтены в дальнейшем.