Интересны ли подобные публикации на тему ERP?

[Vals]

Цитата:

Не корректируйте заказ на закупку на основании приходных документов. Если по факту товар пришел раньше или позже согласованной даты, или объем отличается от согласованного — все это необходимо отразить в приходных документах по заказу на закупку, не изменяя сам заказ. Помните — в заказе — ваши плановые значения, в приходном документе — фактические.

Уже много раз обсуждалось: заказы на покупку и продажу могут быть удалены как ручками так и стандартными функциями очистки и удаления (галки в параметрах).
Данные в заказе/ закупке должны изменяться по факту, иначе вы не с сможете распечатать соответствующие документы. Процедура работы и изменения заказов/закупок несколько отличается в версиях 4.0 и 2009.

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

Цитата:

8.
Управляйте отклонениями. Регулярно формируйте список строк заказов на закупку, поставка по которым просрочена и акцентируйте свое внимание на этих заказах. Сопоставляйте плановые и фактические даты поставки, размеры партий для корректировки плановых значений при следующем цикле планирования закупок.

Хз как к этому относиться, вроде в общем всё верно, а применительно к системе раскрыто не до конца. В системе существует процедура обработки перепоставок и недопоставок. Существует соответствующий отчёт, который отображает отклонения.

По моему мнению в тезисах, если они относятся к системе, нужно делать ссылку на соответствующую функциональность системы.
Например:

Цитата:

исполнение платежей в соответствии с условиями оплат по заказам на закупку
на основании условий оплаты, определенных в заказах на закупку, формируются заявки на оплату авансовых платежей и платежей по факту поставки;

- Предложения по платежам.

Цитата:

уведомление о возможных изменениях в поставке
отражение взаимодействия с поставщиком — фиксация изменений в обещанных сроках поставки для оповещения подразделений-потребителей закупаемой продукции;

Где в системе? В данном случае в заказе изменится срок поставки и вы получаете противоречие с пунктом о невозможности редактирования заказа.

Цитата:

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

Вопрос интерпретации.

Цитата:

Если "Purchase Order" не калькировать дословно, а назвать так как он у нас называется "Договор с поставщиком", то люди будут вводить и регулярно, и вовремя

В четверёке я бы не согласился. А в 2009, когда предложения вынесли в... - да

Цитата:

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

Что делать со сводным планированием? Типом заказа Предложение? Как только вы создали заказ на покупку , вы получите проводки со статусом Заказано. Сводное этот статус интерпретирует как однозначную поставку. Какой же тут план поставок?

Цитата:

Заказ на закупку должен создаваться раньше или непосредственно перед первым обращением к поставщику. Именно с помощью заказа на закупку готовится Заявка на поставку — документ, который отправляется поставщику для согласования цен, сроков и объемов.

Всё верно, только вот Предложения вынесены из заказов. И обязательно нужно уточнять статусы проводок в этом случае.
Итого, если у вас есть заказа на покупку с типом Заказ на покупку, то сколько бы вы заявок не делали, для системы это будет поставка, а не этап согласования

На самом деле я подробно этот момент обсосал в видео по тренингу логистика 1 часть. Надо бы выложить, а у большинства партнёров это видео есть.

[mazzy]

Цитата:

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

Вопрос интерпретации

И я об этом же

Vals, по-моему автор пока не заглубляется в особенности конкретной системы, а пытается обсуждать в целом системы ERP.

[ds1678]

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

Цитата:

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

Уже много раз обсуждалось: заказы на покупку и продажу могут быть удалены как ручками так и стандартными функциями очистки и удаления (галки в параметрах).

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

Цитата:

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

Данные в заказе/ закупке должны изменяться по факту, иначе вы не сможете распечатать соответствующие документы. Процедура работы и изменения заказов/закупок несколько отличается в версиях 4.0 и 2009.

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

Цитата:

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

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

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

Цитата:

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

Где в системе? В данном случае в заказе изменится срок поставки и вы получаете противоречие с пунктом о невозможности редактирования заказа.

Для этого и заведено 2 даты: Дата поставки и Подтверждено. Дату поставки сохраняем неизменной, она фиксирует, когда нам нужна была это строка. Подтверждено – дата поставщика, она может актуализироваться сколь угодно много раз. Если она заполнена, то именно она вместо Даты поставки попадает в строку проводки (в поле Ожидаемая дата) по номенклатуре и все вокруг видят, когда это ожидается к приходу. Через проводки.

Цитата:

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

Что делать со сводным планированием? Типом заказа Предложение? Как только вы создали заказ на покупку, вы получите проводки со статусом Заказано. Сводное этот статус интерпретирует как однозначную поставку. Какой же тут план поставок?

Сводное планирование видит проводку по закупке (в статусе Заказано) и резонно ожидает приход. Все верно. Только здесь, часто в условиях нестабильных отношений с поставщиками, начинаются серьезные отклонения. Срывы сроков поставки, брак в поставке, отклонения в количестве. Поэтому закупка – элемент самого нижнего, оперативного плана, и остается таковой до момента закрытия. Уточненная дата Подтверждено даст информацию сводному плану об актуальной ожидаемой дате поставки. На мой взгляд, только с таким подходом, можно выровнять отношения с поставщиками и добиться большей стабильности в поставках. А это залог того, что ваш сводный (MRP, детальный, объемно-календарный) план будет более актуален и стабилен.
А Журнал, Предложение – это некие нюансы реализации. Вы можете использовать черновой вариант, не учитываемый сводным планом вообще, можете использовать статус Предложение для неподтвержденных закупок, и учитывать его в некоторых сценариях планирования, а можете использовать Закупку с механизмом «Обработка – Заявка» для отражения согласования с поставщиком. Я бы рекомендовал использовать Предложение, когда это позволяет делать цикл поставки (время упреждения). А как только наступает дата Х, когда необходимо размещать заказ, чтобы успеть во время, переводил в статус Закупка.

[Atar]

Цитата:

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

Для этого и заведено 2 даты: Дата поставки и Подтверждено. Дату поставки сохраняем неизменной, она фиксирует, когда нам нужна была это строка. Подтверждено – дата поставщика, она может актуализироваться сколь угодно много раз. Если она заполнена, то именно она вместо Даты поставки попадает в строку проводки (в поле Ожидаемая дата) по номенклатуре и все вокруг видят, когда это ожидается к приходу. Через проводки.

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

Цитата:

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

На самом деле основной тезис "ЛикБеза" а поддерживаю.

Ага, ага!

[ds1678]

Цитата:

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

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

Правда и моя, и ваша, коллеги. Тут все завит от целей, которые мы преследуем. Совсем недавно ознакомился с одним новым правилом уровня сервиса. Выглядит просто:

90-95-98-95-98

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

Подтвержденная дата поставки при этом используется нами одинаково, разница лишь в том, как интерпретировать Дату поставки.