Изменение маршрута производственного заказа

[sashanka]

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

Решению, которое нашла я:
Откатывала журналы карты заданий

    ProdJournalCheckPostRoute    prodJournalCheckPostRoute;
    ProdJournalCreateRoute       prodJournalCreate;
    ProdJournalTable             prodJournalTable;

    ;

    prodJournalCreate = ProdJournalCreateRoute::newStatusDecrease( m_prodTable.ProdId );
    prodJournalCreate.run();

    prodJournalTable = prodJournalCreate.usedProdJournalTable();

    if ( prodJournalTable.RecId && prodJournalTable.JournalId )
    {
        prodJournalCheckPostRoute = ProdJournalCheckPostRoute::newPostJournal( prodJournalTable.JournalId, true );
        prodJournalCheckPostRoute.run();
    }

Для обновления маршрута я не вводила все необходимые параметры ручками при формировании новых записей в ProdRoute

А использовала бубен и танцы с таблицей ReqRoute,
а именно создавала там маршрут с помощью ReqTrans.createRoute(), далее практически скопипастив метод ReqTransPoMarkFirm.createProdRoute создавала записи в ProdRoute
для обновления заданий пробегала ProdRoute и переписывала задания с помощью

while select prodRoute
    order by OprNum,OprPriority
where prodRoute.ProdId == m_prodTable.ProdId
{
    prodJobUpdate     = ProdJobUpdate::newProdIdOprNum( prodRoute.ProdId, prodRoute.OprNum);
    prodJobUpdate.run();
}

Теперь вопрос, насколько ужасно мое решение? -__-
Знает кто-нибудь менее шаманский способ?

[S.Kuskov]

Цитата:

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

Для обновления маршрута я не вводила все необходимые параметры ручками при формировании новых записей в ProdRoute

А использовала бубен и танцы с таблицей ReqRoute,
а именно создавала там маршрут с помощью ReqTrans.createRoute(), далее практически скопипастив метод ReqTransPoMarkFirm.createProdRoute создавала записи в ProdRoute

Я правильно понял задачу? У вас изменился маршрут на номенклатуре и вам нужно обновить маршрут на прозводственном заказе? Чем стандартный класс ProdRouteUpdate не подходит (Производственный заказ \ Маршрут \ Функции \ Обновить маршрут)?

[sashanka]

Ну наскольк я знаю менять маршрут можно двумя путями:
1. В стандарте Производственный заказ \ Маршрут менять руками добавлять/изменять строки в ProdRoute
2. Подменять ссылку (что посути делаю я) в ProdTable и после этого уже обновлять маршрут.
был RouteId - id1
стал RouteId - id2

При подмене ссылки и Производственный заказ \ Маршрут \ Функции \ Обновить маршрут изменения не отображаются.

[S.Kuskov]

Если меняется версия маршрута, то это тогда Производственный заказ \ Маршрут \ Функции \ Копировать (метод: Заменить)

[sashanka]

Цитата:

Сообщение от S.Kuskov

Если меняется версия маршрута, то это тогда Производственный заказ \ Маршрут \ Функции \ Копировать (метод: Заменить)

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

UP: единственный возможный статус который позволяет проводить такое Производственный заказ \ Маршрут \ Функции \ Копировать (метод: Заменить)
изменение маршрута это Создано

[Maxim Gorbunov]

А насколько у вас новый маршрут от старого отличается? Другое количество операций? Другие операции? Другая длительность операций?

Кроме того, не совсем понял, откуда берутся новые позиции спецификаций при обновлении маршрута. Вы не могли бы пояснить?

[sashanka]

Цитата:

Сообщение от Maxim Gorbunov

А насколько у вас новый маршрут от старого отличается? Другое количество операций? Другие операции? Другая длительность операций?

Кроме того, не совсем понял, откуда берутся новые позиции спецификаций при обновлении маршрута. Вы не могли бы пояснить?

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

Со спецификацией немного проще: мы изначально хотя бы примерно представляем какие номенклатуры входят в состав.Но может измениться какая-то деталь.
банальный пример: был один винтик item1 решили использовать другой Item2, но Item1 мы уже списали с со складов и использовали при производстве и обратно его никак не сможем вернуть. Или если забыли что-то внести.

[Starling]

Цитата:

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

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

А может отразить загрузку человеческих ресурсов в проектах?
Т.е. создать проект "разработка новых изделий" и списывать на него фактическое время.

[Maxim Gorbunov]

А по каким причинам вас не устроил "стандартный" подход к решению подобных проблем: после того, как пробный экземпляр произведён, разбить производственный заказ, оставив в старом только произведённую единицу. Старый заказ закрыть, а в новом, так как его статус теперь позволяет, записать новый маршрут и спецификацию.

Кстати, какая у вас модель учёта себестоимости для такой продукции?

[sashanka]

Цитата:

Сообщение от Maxim Gorbunov

А по каким причинам вас не устроил "стандартный" подход к решению подобных проблем: после того, как пробный экземпляр произведён, разбить производственный заказ, оставив в старом только произведённую единицу. Старый заказ закрыть, а в новом, так как его статус теперь позволяет, записать новый маршрут и спецификацию.

Кстати, какая у вас модель учёта себестоимости для такой продукции?

Пользователи хотят иметь возможность вносить изменения в производственный заказ задним числом.

Себестоимость по FIFO модели.

Видимо мое решение проблемы совсем-совсем ужасно)

[Maxim Gorbunov]

Цитата:

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

Пользователи хотят иметь возможность вносить изменения в производственный заказ задним числом.

Изменения какого характера? Например?

[sashanka]

Цитата:

Сообщение от Maxim Gorbunov

Изменения какого характера? Например?

Менять маршрут и спецификацию ПЗ в статусе ReportedFinished;
Маршрут менять как полностью, так и просто добавлять какие-то операции,со спецификацией аналогично

[Maxim Gorbunov]

Поясню про модель учёта себестоимости: теоретически, если у вас FIFO или LIFO, то общие расходы на производственный заказ могут не распределиться корректно на первую пробную единицу при разбиении. Если средняя, то проблем, в общем-то, и нет - в конце концов всё равно всё усреднится. Но, даже в случае FIFO и LIFO, есть способы распределить затраты на оба заказа (без программирования).

[Starling]

ну как вариант наверно можно сделать так:
1. Создать новую виртуальную номенклатуру (можно одну на все случаи жизни).
2. Создать для этой номенклатуры новый ПЗ с уже четко известным маршрутом.
3. Списать задним числом на этот ПЗ все трудозатраты задним числом.
4. Списать задним числом новую виртуальную номенклатуру в исходный ПЗ.
5. Для надежности промаркировать производство виртуальной номенклатуры и ее списание в исходный.
Еще можно виртуальную номенклатуру изначально вставлять в спецификацию исходного ПЗ с типом строки Производство. В результате исходный ПЗ и новый будут жестко между собой связаны.

[sashanka]

Цитата:

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

ну как вариант наверно можно сделать так:
1. Создать новую виртуальную номенклатуру (можно одну на все случаи жизни).
2. Создать для этой номенклатуры новый ПЗ с уже четко известным маршрутом.
3. Списать задним числом на этот ПЗ все трудозатраты задним числом.
4. Списать задним числом новую виртуальную номенклатуру в исходный ПЗ.
5. Для надежности промаркировать производство виртуальной номенклатуры и ее списание в исходный.

Я правильно вас поняла,что мы по сути делаем делаем все те же манипуляции с подлогом,но теперь уже для виртуальной номенклатуры?)

Цитата:

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

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

Это точно сделать нельзя, так как на номент создания исходного ПЗ еще не знаем маршрут, по которому производить виртуальную номенклатуру.

[Starling]

Цитата:

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

Я правильно вас поняла,что мы по сути делаем делаем все те же манипуляции с подлогом,но теперь уже для виртуальной номенклатуры?)

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

Цитата:

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

Это точно сделать нельзя, так как на номент создания исходного ПЗ еще не знаем маршрут, по которому производить виртуальную номенклатуру.

Ну и что? У вас при оценке исходного ПЗ создается подчиненный ПЗ для виртуальной номенклатуры без маршрута. Исходный ПЗ вы обрабатываете, а вот подчиненный ему нет. После того как маршрут уже известен вы вносите по факту новый маршрут в подчиненный ПЗ и отчитываетесь о его выполнении.

[sashanka]

Цитата:

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

У вас при оценке исходного ПЗ создается подчиненный ПЗ для виртуальной номенклатуры без маршрута. Исходный ПЗ вы обрабатываете, а вот подчиненный ему нет. После того как маршрут уже известен вы вносите по факту новый маршрут в подчиненный ПЗ и отчитываетесь о его выполнении.

У нас закрыта такая возможномть программно, так как дописан модуль комплектации заказа. Для выполнения исходного ПЗ нам необходимо иметь в наличии подчиненные номенклатуры.Если бы не это условие, предложенный вами вариант был бы оптимален.

[Maxim Gorbunov]

А почему бы просто не регистрировать потребление по факту? Какую номенклатуру использовали, такую и списали. Почему надо что-то изобретать?