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

[Lz_]

Разбираюсь с функционалом RU5.
Возник вопрос: каким образом система контролирует соответствие цен приема товара на ответственное хранение и выдачи с ответственного хранения? Ведь если ТМЦ были приняты по 3 рубля, то и возвращены они должны быть тоже по 3 рубля.

К сожалению, в документации этот момент вообще не упоминается.

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

Я правильно схему работы с функционалом понял или была какая-нибудь задумка по этому поводу?

[gene]

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

[R.Safianov]

А как это цена не имеет значение?
На сколько я понимаю эта цена потом идет в печатные документы (Акт МХ-1) в раздел Оценка-Стоимость.

[Lz_]

Цитата:

Сообщение от gene

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

Да, разобрался. Большое спасибо.

Цитата:

Сообщение от gene

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

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

Если вы "для успокоения" включите аналитику партия при поиске цены, то и при указании цены для этой номенклатуры при других видах деятельности, например, в случае, если этот товар хранится на складе на ответственном хранении и этим же товаром организация торгует, вам потребуется так же указывать цену продажи клиентам в разрезе партии. Очень сомневаюсь, что такой вариант согласуете с отделом продаж. Да и использование ценовых соглашений для хранения цены, которая всегда равна себестоимости не выглядит красивым решением. Много телодвижений и есть вероятность ошибки. В любом случае, спасибо за идею, буду думать.

Цитата:

Сообщение от gene

Партия, кстати, жестко требуется, если вы планируете на только вести учет хранения, но и биллинг услуг.

А про биллинг услуг в документации ни слова. Можно поподробнее что вы понимаете под словом биллинг услуг?

[gene]

Цитата:

Сообщение от Lz_

Насчет рояля не согласен. Цена при возврате с ответственного хранения всегда равна себестоимости. {skip}

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

Цитата:

Сообщение от Lz_

А про биллинг услуг в документации ни слова. Можно поподробнее что вы понимаете под словом биллинг услуг?

Я понимаю расчет стоимости хранения и выставление счетов за хранение. В документации на этот счет есть раздел "Расчет стоимости хранения".

[gene]

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

[Lz_]

И еще вопрос. Система при расчете стоимости и количества услуг по хранению опирается на Количество номенклатуры хранения. Это количество в системе в единицах складского учета. То есть получаем фактически стоимость штуко-дня для номенклатуры у которой единицы измерения штуки.
Клиент, как правило, получает цену за хранение одного палето-места, т.е. за палето-день.

Безусловно, можно настроить систему для пересчета количества в паллеты по коэффициенту. Но в таком случае, расчетное количество палето-мест может не совпасть с фактическим.

Например, с клиентом оговорено что сутки хранения палеты стоит 100 р. На палете размещается 50 единиц товара. Расчетная номенклатура - УслХран, у которой в качестве единицы измерения указано Палето-сутки = Количество*Дни/Коэффициент(50). В результате обработки товара в некий момент времени в системе числится (и реально лежит в ячейке) 2 палеты. П1 - 10 штук и П2 - 15 штук. При расчете стоимости услуги система рассчитает УслХран 0,5 палето-сутки * 100 р. = 50р. И выставит задолженность клиенту 50р. Хотя на самом деле занято два палето-места и стоимость хранения = 200р.

На следующий день остаток П1 - 1 штука. И эта штука лежит месяц. Та же история при расчете. За 30 дней хранения система выставит 100 р * 1шт*30дней/50шт-на-палете = 60р. Хотя реально было занято одно палето-место и стоимость хранения составляет 100*30 = 3000 р. Такой факт очень не нравится логистам .
Можно ли малой кровью заставить систему рассчитывать плату за реально занимаемые палето-места?

[gene]

Цитата:

Сообщение от Lz_

{skip}
Клиент, как правило, получает цену за хранение одного палето-места, т.е. за палето-день.
{skip}
Можно ли малой кровью заставить систему рассчитывать плату за реально занимаемые палето-места?

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

[Ich@Ru]

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

[Lz_]

Ich@Ru, идея понятна. Спасибо. Только товар из разных партий может перемешаться между палетами, не часто, но может, например, оптимизация зоны комплектации.

Еще вопрос: Может ли одной номенклатуре хранения соответствовать несколько номенклатур расчета?

Например, есть тариф на входящую обработку паллет (или штук), есть тариф на хранение палет (или штук). Можно настроить: УслугаВхОбраб ед.изм = количество, УслугаХранен ед.изм= количество*дни. При расчете берется только одна строка (судя по всему первая попавшееся, но глубоко не копал).
Уж очень не хочется параллельно плодить фиктивные номенклатуры для биллинга услуг.

[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 приходится приходовать на склад номенклатуру хранения ДопУслуги. По сути это услуга и у нее не может быть остатка, но кроме остатка еще у этой псевдо-номенклатуры обязательно должна быть партия . Мало того, по этим номенклатурам остатки постоянно увеличиваются и приходится время от времени делать списание этой номенклатуры со склада. Короче, некузяво как-то. Хотя учетную задачу решить можно.