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

[Lz_]

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

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

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

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

[gene]

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

[R.Safianov]

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

[gene]

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

[Lz_]

Цитата:

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

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

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

Цитата:

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

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

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

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

Цитата:

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

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

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

[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}

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

Цитата:

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

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

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

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

[Ich@Ru]

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

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

[Lz_]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[Ich@Ru]

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

[Lz_]

То, чего не хватает мне я уже высказал. Основное - Доп услуги. Соглашусь, что это можно реализовать и сейчас, но хотелось бы что бы это было элегантнее .
А вообще, спасибо, довольно приличный кусок вопросов по ответственному хранению разрулили.

[Ich@Ru]

Спасибо. Главное на'чать