Сводное планирование: История чистых потребностей...

[Индра]

Коллеги, добрый день.

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

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

Кто как решал эту проблему в практике ? Можно конечно в каждом модуле вводить функционал отмены документов (в базе остаются документы и их строки, удаляются лишь складские проводки), но тогда отчет "плановый заказ / фактическое потребление" должен понимать формат всех исходных модулей. Второй вариант - фиксировать (разносить) сами чистые потребности по результатам цикла планированя (что-то типа таблицы "ReqTransPosting", куда придется добавить много дополнительных полей).

Буду благодарен за мысли, или отсыл в правильном методологическом направлении...

[fed]

Можете добавить складскую аналитику "Владелец" и сделать ее аналитикой покрытия. Только напаритесь вы с разработкой дисциплины списаний и отслеживания чей товар в повседневном учете... Хотя если вы хотите наводить дисциплину - все равно придется как-то все списания либо к инициатору заказа привязывать, либо вообще к исходному заказу с потребностью. Так что проблема встанет независимо от ее реализации в Аксапте...

[Vals]

Цитата:

Сводное планирование ежемесячно генерирует цепочку складских перемещений

В смысле ежемесячно? Месяц это цикл планирования?


Если у вас не тройка, то использовать два плана.
Также смотреть на генерацию действий. Наверняка при такой постановке вопроса она орала во всю глотку своими предложениями "отменить, отсрочить, ускорить" и т.д.

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

Теперь по лечению:
1. Есть журнал работы пользователей - его вы можете использовать для разбора конкретных случаев "вредительства": удаления и проч. К слову, в журналах открытых строк не должно быть, вернее они не должны висеть днями и портить потребности.
Можете, например, сделать несколько планов и исключать складские проводки. (хотя это слишком сложно )
2. Процедурный вопрос: разобраться с отменой и удалением потребностей.
Если производство - поставить галку "Потребности по версии спецификации"
Проанализировать методику покрытия номенклатур: Под заказ, Мин макс, период и проч.
Отработать процессы связанные с производством и проектами.
3. Посадить толковую голову на утверждение закупок, а именно на проработку действий.

Итого:
- Локализовать причины
- Проверить бизнес-процессы
- Проверить настройки системы.

[S.Kuskov]

В системе есть стандартная операция копирования сводного плана. Можно сразу после планирования делать копию сводного плана. Тогда позже в любой момент в чистых потребностях можно будет выбрать этот сохраннный план. По сохранённому плану также будет доступна функция развёртывания потребности. Там можно будет увидеть причину создания закупки - источник потребности. Или я не понял сути проблемы?

[Индра]

Большое спасибо всем. Аналитику "Владелец" мы уже сделали (правда финансовую), но это мало. Надо иметь максимальную информацию - кто и для чего заказывал. Если это модуль ТОиР - надо знать код единицы оборудования, если это производство - надо знать номенклатуру ГП, код производственного центра и т.д. В чистых потребностях есть ссылка на исходный документ, но через 3 месяца он может быть либо изменен, либо удален, поэтому бэкап сводного плана решит проблему лишь частично.

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

Эхх, мечты, мечты...

[Vals]

Цитата:

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

А дальше то что? Зафиксируете вы картинку, а жизнь то всё равно изменяется. Укажете на фиксы в планировании, а производственники вам совершенно логично и оправдано ответят, что жизнь штука непредсказуемая и что вот эта зафикшенная херь ну никак не нужна

[fed]

Цитата:

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

А дальше то что? Зафиксируете вы картинку, а жизнь то всё равно изменяется. Укажете на фиксы в планировании, а производственники вам совершенно логично и оправдано ответят, что жизнь штука непредсказуемая и что вот эта зафикшенная херь ну никак не нужна

Угу - только введение складской аналитики "Виноватый" спасет отца русской демократии Вообще конечно - это из серии: "Ищем виновных, вместо поиска решения проблемы. Хотя с другой стороны - видел кучу фирм, где без поиска и жесткой, гм, мотивации виновных, никакие решения не искались...

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

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

[Индра]

Цитата:

А дальше то что? Зафиксируете вы картинку, а жизнь то всё равно изменяется. Укажете на фиксы в планировании, а производственники вам совершенно логично и оправдано ответят, что жизнь штука непредсказуемая и что вот эта зафикшенная херь ну никак не нужна

Это понятно, что жизнь меняется. Но оперативность планирования всегда ограничивается самым медленным звеном - у нас это закупки. То есть потребность не может все время "плавать", иначе закупки будут вечно не успевать, склад затовариваться всяким барахлом, а инициаторы не будут чувствовать ответственности. Я сторонник регламента - выбираем минимальный период планирования, согласуем все планы "на берегу", а потом - каждый отвечает за свой план. Если заявитель не потребил то, что заказывал - он плохо планирует, и это надо в явном виде показать всем участникам процесса.

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

[Индра]

Цитата:

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

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

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

[Vals]

Цитата:

Сообщение от Индра

Это понятно, что жизнь меняется. Но оперативность планирования всегда ограничивается самым медленным звеном - у нас это закупки. То есть потребность не может все время "плавать", иначе закупки будут вечно не успевать, склад затовариваться всяким барахлом, а инициаторы не будут чувствовать ответственности. Я сторонник регламента - выбираем минимальный период планирования, согласуем все планы "на берегу", а потом - каждый отвечает за свой план. Если заявитель не потребил то, что заказывал - он плохо планирует, и это надо в явном виде показать всем участникам процесса.

У вас действия включены? Скриншотик сделайте

[glibs]

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

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

В заказе на продажу есть Тип заказа. Можно сделать так, чтобы заказы создавались с типом "Журнал" (параметр в стандартной функциональности... раньше по крайней мере был). Такие заказы на продажу в сводное планирование не идут. А дальше...

Либо усложнить смену типа заказа на продажу на "Заказ на продажу". Чтобы было осознано. Как усложнять — дело хозяйское. Можно через руководителя, или под ответственность самого продавца. Можно при этом фиксировать состав заказа, хотя мне не очень нравится такое. Как вариант можно ограничить или усложнить его редактирование в части номенклатуры, количества и/или других реквизитов, влияющих на сводное планирование.

Либо перевод заказа в тип "Журнал" опять же усложнить через согласование с руководителем, либо как минимум запротоколировать факт изменения в заказе и кто инициировал.

Либо отказаться от планирования по открытым проводкам, а на основании введенных заказов верстать план продаж, который утверждать и планировать от плана. Бюрократично... Но не лишено здравого смысла, если сделать по уму.

История развертывания заказа на покупку в чистом виде может не дать желаемый результат. Предположим я заказал нечто, потом переиграл что-то и перевел на другой заказ на покупку. Склад я не затоварил, но заказ на продажу отменил. А переиграть что-то бывает необходимым.

Либо неудачно купленный мною товар продал кто-то другой. Тоже нет затоваривания. А как это отследить что в данном случае все ОК на самом деле?

[Rezervforall]

Кто как решал эту проблему в практике ? Можно конечно в каждом модуле вводить функционал отмены документов (в базе остаются документы и их строки, удаляются лишь складские проводки), но тогда отчет "плановый заказ / фактическое потребление" должен понимать формат всех исходных модулей. Второй вариант - фиксировать (разносить) сами чистые потребности по результатам цикла планированя (что-то типа таблицы "ReqTransPosting", куда придется добавить много дополнительных полей).

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