Планирование закупок

[RobiBaggio]

Коллеги, такой вот question у меня.
Думаем тут над планированием закупок. В карточке товара есть поле "Цикл Возобновления". Прочитали help, как обычно он очень много информации дал... Приходится обращаться к Вам.
Подскажите, что это за поле, и как его использовать.
На всякий случай Navision 4.0 SP2

[apanko]

Перед сертификацией разбирался и записывал

_______________________________________
В карточке товара, закладке Планирование есть параметр Цикл возобновления. Используется он для объединения нескольких заказов на поставку покрывающих спрос в определенном временном интервале. Принимается во внимание системой планирования при политике дозаказа Лот для лота или Фиксированное количество дозаказа.
Объединение происходит по следующему алгоритму:
В интервале планирования, задаваемом на закладке Параметры пакетного задания Расчет Плана – Производственный план, система отбирает данные о спросе в хронологическом порядке. Далее система находит первый несбалансированный спрос, дата которого вместе со значением параметра цикл возобновления является основой для расчета интервала объединения (например, первый спрос был 05-го числа, цикл возобновления равен 1Н, значит, в интервал войдут даты с 05 по 12-е (05+1Н)). Весь спрос в пределах этого интервала будет сбалансирован одним заказом на поставку с самой ранней датой поставки. Т.е. система находит следующий несбалансированный спрос и проверяет его дату, если она принадлежит интервалу объединения – то данный спрос включается в заказ на поставку, а если нет, то на основании этого спроса определяется следующий интервал объединения.

Пример 1:
На условный товар с циклом возобновления=1Н существует несбалансированный спрос 05-го, 12-го, 14-го, 16-го. Система найдет первый спрос, это будет спрос от 05-го, далее вычисляется интервал объединения, в нашем примере это будет с 05 по 12-е. Далее система находит следующий несбалансированный спрос и проверяет, входит ли он в указанный интервал. Спрос от 12-го числа входит в интервал объединения, поэтому он будет присоединен к спросу от 05-го. Эти два спроса будут сбалансированы одним заказом на поставку. А вот спрос от 14-го числа уже не входит в рассчитанный интервал объединения, поэтому интервал объединения рассчитывается заново и будет с 14 по 21-е. Т.е. спрос от 14-го и от 16-го также будет сбалансирован одним заказом на поставку.

Пример 2:
Представим, что мы создали два заказа на поставку, как и рекомендовала нам система (первый для балансировки спроса от 05 и 12, второй для спроса от 14 и 16). Также в систему введен новый спрос от 03-го числа. Заказы на поставку не резервировались.
Так как первый спрос в системе имеет дату 03, то в первый интервал объединения войдут даты с 03 по 10-е, а во второй интервал объединения с 12 по 19-е число.
В результате система даст следующие указания:
* перепланирование и изменение количество в первом заказе на поставку (изменить дату с 05 на 03, добавить количество по спросу от 03-го, убрать количество по спросу от 12-го числа),
* перепланирование и изменение количество во втором заказе на поставку (изменить дату с 14 на 12, добавить количество по спросу от 12-го числа).

[RobiBaggio]

Спасибо. Ответ более чем полный. Однако расстроил Ты меня маленько. Думал, что с помощью данного поля можно влиять на планирование по периодам. К примеру, указываем 1М, и в журнале заявок формируется строка с указанием колличества из поля "Фикс. Кол-во для Заказа" и датой заказа = последний заказ для этого товара +1М

[apanko]

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

Вы бы поточнее сформулировали алгоритм пополнения...

[RobiBaggio]

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

[NeNavision_imported]

Вместо производственного прогноза можно использовать общий заказ. Эффект тот же.

[RobiBaggio]

Zitat:

Zitat von NeNavision

Вместо производственного прогноза можно использовать общий заказ. Эффект тот-же.

А ну ка расскажи, плиз, как это настроить периодическое формирование заказа с общего заказа

[apanko]

Эффект тот же, если клиент совпадет и в заказе на продажу указать ссылку на общий производственный заказ.

[RobiBaggio]

Господа.
Еще раз напоминаю, что клиент НЕ КУПИЛ производство. Поэтому решения с приминением функционала производства не проходят цензуру.

[NeNavision_imported]

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

[Ируля]

Zitat:

Zitat von NeNavision

Вместо производственного прогноза можно использовать общий заказ. Эффект тот же.

Каким образом можно использовать ощий заказ, если мы указываем дату отгрузки ( поставки), а система будет тулить планирование всего количества товара именно на эту дату?
А RobiBaggio необходимо распределить отгрузку товара на весь месяц, например с учетом среднедневного потребления, оптимального размера партии и т.д.

[apanko]

2RB

Zitat:

Эффект тот же, если клиент совпадет и в заказе на продажу указать ссылку на общий производственный заказ.

Естественно не общий производственный заказ, а общий заказ на продажу.

Извините ®.

[Ируля]

Zitat:

Zitat von apanko

2RB

Zitat:

Эффект тот же, если клиент совпадет и в заказе на продажу указать ссылку на общий производственный заказ.

Естественно не общий производственный заказ, а общий заказ на продажу.

Извините ®.

А детали можно описать?

[apanko]

Есть предложение упростить вариант предложенный NeNavision и не использовать общие заказы продажи. Вместо этого сформировать заказы покупки, а чтобы система планирования не предлагала их отменить - указать в строках параметр Гибкость планирования = Нет.




2Ируля. Кое-что можно. Таблицы сюда не вставляются - поэтому она пойдет ссылкой.

__________________________________

Общие заказы продажи при планировании (Navision).

Общие заказы продажи (далее ОЗПрод) представляют собой электронную форму долгосрочного договора продажи. Как обычный заказ продажи, является инструментом для формирования накладных и счетов, так и ОЗПрод является инструментов для формирования самих заказов продажи.

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

Таблица

Примечания:
1. Общие заказы продажи описаны в учебном курсе "Производство Microsoft Business Solution 3.60" глава 11.4 "Общие заказы продажи". Отмечу, что в версии 3.7 и выше система поддерживает трассировку общих заказов продажи, хотя в указанном учебном курсе утверждается обратное.
2. При учете как заказов продажи, так и счетов, если в них присутствует ссылка на ОЗПрод, количество Товара для отгрузки в соответсвующей строке ОЗПрод уменьшается.
3. ОЗПрод и Производственный прогноз дополняют друг друга. Так ОЗПрод создается для конкретного клиента, а Производственный прогноз - при прогнозировании отгрузок в целом по компании.
__________________________________

[Ируля]

Господа, хотелось бы с вами обсудить одну идею.
Я для планирования закупок хорошо прогнозируемого товара хочу использовать доработанный документ "План закупок" (типа заявок). В этом плане закупок собираюсь указывать количество закупаемого товара и поставщика, который будет его поставлять.
Для того, чтобы распланировать даты поставок, отгрузок и заказов, собираюсь использовать поля "Время обработки заказа" ... Поскольку спрос на товар стабилен, можно легко и с уверенностью посчитать для него среднедневную потребность. И исходя из этого и оптимального размера заказа можно будет пропланировать даты заказов, отгрузок и поставок. И автоматически формировать уже из этого документа общие заказы покупки с указанными в строках датами.
Что вы об этом всем скажете?
Жду конструктивных замечаний

[apanko]

2Ируля. Извините не совсем понял задачу.

2Сам себе.
Можно не создавать заказ на покупку с многими строками (например на год), т.к. это не совсем красиво.
Более грамотным представляется использование типового журнала заявок, где указываются следующие реквизиты:
Метод повтора = Фиксированный
Период повтора = 1М
Тип = Товар
Товар = требуемый товар
Указание = Новое
Принять указание = Да
Количество = требуемое количество
Дата заказа = соответственно дата заказа.
Постащик Но.

После этого можно сколько угодно раз на день заходить в данный журнал и нажимать функцию "Выполнить указания", Дата заказа будет увеличиваться согласно формуле указанной в поле Период повтора. Журнал не будет учитываться если Дата заказа > Рабочая дата.

[Ируля]

Zitat:

Zitat von apanko

2Ируля. Извините не совсем понял задачу.

Задача - автоматизировать процесс создания заказов для закупки определенного количества товара в течении месяца

Zitat:

Zitat von apanko

2Сам себе.
Можно не создавать заказ на покупку с многими строками (например на год), т.к. это не совсем красиво.
Более грамотным представляется использование типового журнала заявок, где указываются следующие реквизиты:
Метод повтора = Фиксированный
Период повтора = 1М
Тип = Товар
Товар = требуемый товар
Указание = Новое
Принять указание = Да
Количество = требуемое количество
Дата заказа = соответственно дата заказа.
Постащик Но.

После этого можно сколько угодно раз на день заходить в данный журнал и нажимать функцию "Выполнить указания", Дата заказа будет увеличиваться согласно формуле указанной в поле Период повтора. Журнал не будет учитываться если Дата заказа > Рабочая дата.

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

[RobiBaggio]

Zitat:

Zitat von apanko

2Сам себе.
Можно не создавать заказ на покупку с многими строками (например на год), т.к. это не совсем красиво.
Более грамотным представляется использование типового журнала заявок, где указываются следующие реквизиты:
Метод повтора = Фиксированный
Период повтора = 1М
Тип = Товар
Товар = требуемый товар
Указание = Новое
Принять указание = Да
Количество = требуемое количество
Дата заказа = соответственно дата заказа.
Постащик Но.

После этого можно сколько угодно раз на день заходить в данный журнал и нажимать функцию "Выполнить указания", Дата заказа будет увеличиваться согласно формуле указанной в поле Период повтора. Журнал не будет учитываться если Дата заказа > Рабочая дата.

Одна небольшая проблемка - метод повтора каждый месяц будет меняться, исходя из необходимого количества закупаемого товара(планируемого среднедневного потребления).
[/quote]
Метод повтора может быть плавающий. В случае плавающего метода после учета обнуляется поле "Количество". Соответственно перед новым использованием необходимо провести обновление данного поля. Это возможно двумя методами:
Вручную
Написанием функции.
Второе мне кажется в данном случае предпочтительней, особенно зная параметры пополнения.

[Fordewind]

Zitat:

Zitat von RobiBaggio

Метод повтора может быть плавающий. В случае плавающего метода после учета обнуляется поле "Количество". Соответственно перед новым использованием необходимо провести обновление данного поля. Это возможно двумя методами:
Вручную
Написанием функции.
Второе мне кажется в данном случае предпочтительней, особенно зная параметры пополнения.

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

[RobiBaggio]

Zitat:

Zitat von Fordewind

Zitat:

Zitat von RobiBaggio

Метод повтора может быть плавающий. В случае плавающего метода после учета обнуляется поле "Количество". Соответственно перед новым использованием необходимо провести обновление данного поля. Это возможно двумя методами:
Вручную
Написанием функции.
Второе мне кажется в данном случае предпочтительней, особенно зная параметры пополнения.

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

Тут в первую очередь надо определить параметры на основании которых будут рассчитываться количества.
В нашем случае это: Оптимальный размер заказа, Минимальный\максимальный уровень товара на складе, Страховой запас, Колличество продаж за период, Заявки от торговых подразделений. Некоторых из этих параметров в стандарте Нави нет. Будем добавлять.