Интересны ли подобные публикации на тему 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

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

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