|
07.07.2010, 15:06 | #1 |
Участник
|
DAX 2009 RU5. Ответственное хранение.
Разбираюсь с функционалом RU5.
Возник вопрос: каким образом система контролирует соответствие цен приема товара на ответственное хранение и выдачи с ответственного хранения? Ведь если ТМЦ были приняты по 3 рубля, то и возвращены они должны быть тоже по 3 рубля. К сожалению, в документации этот момент вообще не упоминается. Судя по доработанному механизму Дата цены, предлагается вести цены продажи ручками, используя таблицы цен. Механизма синхронизации и контроля соответствия цен прихода и цен расхода в системе не предусмотрено. Я правильно схему работы с функционалом понял или была какая-нибудь задумка по этому поводу? |
|
09.07.2010, 10:15 | #2 |
Microsoft Dynamics
|
Вы немного неправильно поняли. Дата цены не имеет отношения к цене хранимых товаров, и используется для определения цены продажи услуги по ответственному хранению. В заказе на продажу указывается номенклатура, соответствующая услуге, и дата, на которую нужно выбрать цену услуги (ставку за хранение).
Цена хранимых товаров, по большому счету, вообще рояля в данной функциональности не играет. Однако для успокоения можно пользоваться аналитикой Партия для хранимой номенклатуры, и тогда у вас всегда будет нормальная цена возврата с ответхранения. Партия, кстати, жестко требуется, если вы планируете на только вести учет хранения, но и биллинг услуг. |
|
|
За это сообщение автора поблагодарили: Lz_ (1). |
09.07.2010, 11:48 | #3 |
Участник
|
А как это цена не имеет значение?
На сколько я понимаю эта цена потом идет в печатные документы (Акт МХ-1) в раздел Оценка-Стоимость. |
|
09.07.2010, 18:23 | #4 |
Участник
|
Ответственное хранение
Цитата:
Сообщение от gene
Вы немного неправильно поняли. Дата цены не имеет отношения к цене хранимых товаров, и используется для определения цены продажи услуги по ответственному хранению. В заказе на продажу указывается номенклатура, соответствующая услуге, и дата, на которую нужно выбрать цену услуги (ставку за хранение).
Цитата:
Если вы "для успокоения" включите аналитику партия при поиске цены, то и при указании цены для этой номенклатуры при других видах деятельности, например, в случае, если этот товар хранится на складе на ответственном хранении и этим же товаром организация торгует, вам потребуется так же указывать цену продажи клиентам в разрезе партии. Очень сомневаюсь, что такой вариант согласуете с отделом продаж. Да и использование ценовых соглашений для хранения цены, которая всегда равна себестоимости не выглядит красивым решением. Много телодвижений и есть вероятность ошибки. В любом случае, спасибо за идею, буду думать. А про биллинг услуг в документации ни слова. Можно поподробнее что вы понимаете под словом биллинг услуг? Последний раз редактировалось Lz_; 09.07.2010 в 18:47. Причина: очепятки |
|
12.07.2010, 10:50 | #5 |
Microsoft Dynamics
|
Цитата:
Я понимаю расчет стоимости хранения и выставление счетов за хранение. В документации на этот счет есть раздел "Расчет стоимости хранения". |
|
09.07.2010, 12:12 | #6 |
Microsoft Dynamics
|
Именно так.
При приемке на ответхранение печатается МХ-1, в котором цены - из строк заказа на покупку. При возврате с ответхранения - МХ-3, в котором цены - из строк заказа на продажу. Для того чтобы эти цены были как-то связаны, ничего специального не делалось. Используйте стандартные коммерческие соглашения. Больше эти цены ни на что не влияют. По задумке, соответствующие складские проводки разносятся на забалансовые счета (в соответствии с профилями учета для вида деятельности "Хранитель"), а задолженности-выручки-налоги вообще не формируются. Ну а Дата цены придумана для другой цели, как я написал выше. Для хранимой номенклатуры можно просто ничего не трогать, и все будет работать по обычной схеме. |
|
09.07.2010, 18:40 | #7 |
Участник
|
И еще вопрос. Система при расчете стоимости и количества услуг по хранению опирается на Количество номенклатуры хранения. Это количество в системе в единицах складского учета. То есть получаем фактически стоимость штуко-дня для номенклатуры у которой единицы измерения штуки.
Клиент, как правило, получает цену за хранение одного палето-места, т.е. за палето-день. Безусловно, можно настроить систему для пересчета количества в паллеты по коэффициенту. Но в таком случае, расчетное количество палето-мест может не совпасть с фактическим. Например, с клиентом оговорено что сутки хранения палеты стоит 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 р. Такой факт очень не нравится логистам . Можно ли малой кровью заставить систему рассчитывать плату за реально занимаемые палето-места? |
|
12.07.2010, 11:01 | #8 |
Microsoft Dynamics
|
Настройками это не решается. Необходимо добавить новый тип строки в "операциях над единицей измерения", доработать алгоритм формирования базы основания расчета хранения, который должен уметь считать остатки в паллетах (понятно, что это возможно только при использовании WMS, что не всем нужно). Придется определиться, как быть в случаях, если на паллете лежит товар двух наименований, или того круче - двух клиентов, переделать отчет по хранению, отвязавшись от номенклатур, ну и еще массу всяких решений принять. Короче, малой кровью, боюсь, не получится
|
|
14.07.2010, 10:44 | #9 |
Участник
|
Можно предложить и быстрое решение, но это в том случае если товар из разных партий не перекладывается между паллетами и нет бесплатных дней хранения, а также если полная паллета и паллета с одной единицей товара тарифицируются одинаково.
Складской модуль в большинстве случаев интегрирован с ТСД, все паллеты промаркированы. Достаточно с товаром приходовать и паллеты, а потом их отгружать. В результате достаточно считать хранение паллет в штуко\днях, причем отдельно по разным ставкам евро паллеты и фин паллеты. Исключить паллеты из МХ-1, МХ-3 не сложно. |
|
|
За это сообщение автора поблагодарили: Lz_ (1). |
16.07.2010, 14:59 | #10 |
Участник
|
Ich@Ru, идея понятна. Спасибо. Только товар из разных партий может перемешаться между палетами, не часто, но может, например, оптимизация зоны комплектации.
Еще вопрос: Может ли одной номенклатуре хранения соответствовать несколько номенклатур расчета? Например, есть тариф на входящую обработку паллет (или штук), есть тариф на хранение палет (или штук). Можно настроить: УслугаВхОбраб ед.изм = количество, УслугаХранен ед.изм= количество*дни. При расчете берется только одна строка (судя по всему первая попавшееся, но глубоко не копал). Уж очень не хочется параллельно плодить фиктивные номенклатуры для биллинга услуг. |
|
16.07.2010, 15:51 | #11 |
Участник
|
В текущей реализации решалась задача формирования базы для расчета хранения. Поэтому в определенный момент времени хранимому товару соответствует одна номенклатура хранения. Правила подбора описаны в разделе "Настройка и расчет стоимости хранения" (документация для RU5).
Относительно тарифа по обработке паллет. Здесь ситуация может быть более сложная: овертайм склада, работа в выходные/праздники может тарифицироваться по ставкам отличным от ставки за обработку в рабочее время. Для формирования счета за обработку паллет, видится целесообразным, формирование отчета в нужном разрезе (например, в разрезе работ в рабочее время, овертайм, выходной) за определенный период. И выставление счета на основании данных данного отчета. Ваша идея понятна, и в некотором общем варианте может быть реализован данный алгоритм. Необходимо для сформированной базы операций хранения формировать информацию по доп услугам. Но тут необходимо указать некоторый набор групп услуг. И все услуги (хранение. обработка) должны быть привязаны к одной из групп. Чтобы для каждой группы система искала нужный тариф. В целом модификация несложная, но требуется сформулировать некоторый стандартный набор услуг, который потенциально мог бы быть включен в стандартную версию. |
|
16.07.2010, 17:32 | #12 |
Участник
|
Цитата:
Цитата:
Сообщение от Ich@Ru
Относительно тарифа по обработке паллет. Здесь ситуация может быть более сложная: овертайм склада, работа в выходные/праздники может тарифицироваться по ставкам отличным от ставки за обработку в рабочее время. Для формирования счета за обработку паллет, видится целесообразным, формирование отчета в нужном разрезе (например, в разрезе работ в рабочее время, овертайм, выходной) за определенный период. И выставление счета на основании данных данного отчета.
Цитата:
Сообщение от Ich@Ru
Ваша идея понятна, и в некотором общем варианте может быть реализован данный алгоритм. Необходимо для сформированной базы операций хранения формировать информацию по доп услугам. Но тут необходимо указать некоторый набор групп услуг. И все услуги (хранение. обработка) должны быть привязаны к одной из групп. Чтобы для каждой группы система искала нужный тариф. В целом модификация несложная, но требуется сформулировать некоторый стандартный набор услуг, который потенциально мог бы быть включен в стандартную версию.
То что можно посчитать на основе данных системы: 1. Плата за обработку входящей палеты; (руб. за палету) 2. Плата за хранение одной палеты; (руб за палетоместо-сутки) 3. Плата за обработку исходящей палеты;(руб. за палету) 4. Плата за комплектацию (как правило за шт, м.куб, вес). Данные можно брать из маршрута комплектации. То что нельзя посчитать на основе данных системы: 5. Доп услуги не вошедшие в п.1-4 и вносимые вручную на складе. Иногда эти услуги могут быть вообще разовые и уникальные (см. выше пример про яблоки ). Последний раз редактировалось Lz_; 16.07.2010 в 17:36. |
|
16.07.2010, 17:55 | #13 |
Участник
|
Цитата:
Всегда хранимому товару соответствует одна номенклатура хранения
Согласен, что в перспективе можно "научить систему" рассчитывать обработку входящей/исходящей паллеты. Отдельный момент комплектация, но тоже реализуемо. |
|
16.07.2010, 20:17 | #14 |
Участник
|
Цитата:
Еще хотелось бы добавить по пункту 5 по поводу доп услуг. Для реализации функции учета доп.услуг при функционале RU5 приходится приходовать на склад номенклатуру хранения ДопУслуги. По сути это услуга и у нее не может быть остатка, но кроме остатка еще у этой псевдо-номенклатуры обязательно должна быть партия . Мало того, по этим номенклатурам остатки постоянно увеличиваются и приходится время от времени делать списание этой номенклатуры со склада. Короче, некузяво как-то. Хотя учетную задачу решить можно. |
|
Теги |
rollup, ru5, ответственное хранение, полезное |
|
|