Повторные операции в маршрутах

[Hard]

Добрый день!
Вопрос у меня в общем-то риторический, но все же.
Имеется маршрут на бумаге:
10 "Токарная операция" "Токарный станок1" 0,5 часа След:20
20 "Проверка качества" "Контролер ОТК" 0,1 часа След:30
30 "Токарная операция" "Токарный станок1" 0,3 часа След:40
40 "Проверка качества" "Контролер ОТК" 0,05 часа След:0

Так вот подобную схему в Аксапте не реализовать. Уникальный ключ в RouteOpr: Код операции + РЦ + Код маршрута + Код номенклатуры (всегда использую код маршрута "Маршрут" и Код связи "Номенклатура")).

Я понимаю так: разработчики Аксапты сделали невозможным задать для 10 и 30 (а также для 20 и 40) операций разные времена и призывают создавать более конкретные операции, например "Токарная - первая обточка" и "Токарная - вторая обточка", либо довольствоваться тем, что обе токарные операции будут иметь один норматив.

Вопрос: это как-то можно побороть без изменения состава операций?
P.S.: в чем сакральный смысл создания двух таблиц RouteOpr и Route вместо одной? Если бы была одна, то все было бы чудненько, номер операции обеспечил бы уникальность.
Сильно камнями не забрасывайте, пытаюсь решить проблему малой кровью, чтобы не менять устоявшийся у заказчика перечень операций.

[S.Kuskov]

Route - это последовательность операций, RouteOpr - это характеристика операции. Т.е. в стандарте одна и таже операция (с одной и той же характеристикой) может быть задействована несколько раз, возможно даже в нескольких маршрутах, так же как и одна и таже последовательность операций может быть использована для комбинации операций с различными характеристиками. Зачем? Для простоты настройки однотипных технологий (бывают и такие )
Если вы всегда используете код маршрута "Маршрут" и Код связи "Номенклатура", то можно сделать вывод, что все эти прелести вам не нужны. Тогда смело рассматривайте RouteOpr как связанную с Route по принципу один к одному. Для этого действительно прийдётся в справочник операций добавить по несколько "токарных" операций. Возможно даже с одинаковым названием (уникальность наименования операции не контролируется). Ещё возможно допилить форму для выбора очередной операции при вводе маршрутов

[Hard]

Цитата:

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

Для этого действительно прийдётся в справочник операций добавить по несколько "токарных" операций. Возможно даже с одинаковым названием (уникальность наименования операции не контролируется). Ещё возможно допилить форму для выбора очередной операции при вводе маршрутов

Это-то как раз я понимаю. А теперь представьте, что мы все маршруты загружаем из другой системы, и они организованы описанным выше способом. Сотни тысяч строк!!!
Первое что я сообщил заказчику - это то, что написали Вы. Ответ: как вы себе это прдставляете? Я предложил нагенерить при загрузке клонов операций, но сразу ответ: как потом их вести? И вот тут-то я в ступоре. Что называется: верхи не могут - низы не хотят.
Заставить вводить новые операции вручную трудно, но теоретически можно. Но как их потом перепровязать с их неконкретными операциями, которые сейчас лежат в их системе, из которой грузим?

[S.Kuskov]

Цитата:

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

Я предложил нагенерить при загрузке клонов операций, но сразу ответ: как потом их вести?

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

Цитата:

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

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

У нас сейчас сделано следующим образом. В справочнике наименований операций (RouteOprTable) введены десять операции с наименованием "Токарная". Если в маршруте токарная операция встретилась впервые, то используется первый "код токарной" операции, если в этом маршруте токарная операция встретится ещё раз, то будет использован второй код токарной операции и т.д.
Для того чтобы не нагружать пользователей подсчётом количеств повторений операции на форме маршрутов сделана модификация, которая перехватывает ввод пользователем операции и заменяет её на следующий ещё не использованный.

[Hard]

Цитата:

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

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

Вот и мы пока пришли к такому же решению, если конечно не получится заставить их вести технологию по-человечески.

[Vals]

Если поговорить с технологами по душам и залезть в тех документацию, то можно будет увидеть что:
- Это разные операции (по сути операции). "Токарная операция" имеет своё название чётко определяющее суть операции, например, "снять фаску", "нарезать резьбу 2.5" и т.д. Кладезь инфы в технологической документации.

- Это разные полуфабрикаты. (реально зависит от настройки спецификаций и прочих подходов к реализации).

Цитата:

чтобы не менять устоявшийся у заказчика перечень операций.

Да, в старой системе у них так и что теперь?

Цитата:

в чем сакральный смысл создания двух таблиц RouteOpr и Route вместо одной

На каждую операцию и норму (связь операции + маршрут+номенклатура+РЦ) вы можете задать время выполнения и описание операции, которое затем печатается в в карте задания и маршрутной карте.

[Hard]

Цитата:

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

Если поговорить с технологами по душам и залезть в тех документацию, то можно будет увидеть что:
- Это разные операции (по сути операции). "Токарная операция" имеет своё название чётко определяющее суть операции, например, "снять фаску", "нарезать резьбу 2.5" и т.д. Кладезь инфы в технологической документации.

- Это разные полуфабрикаты. (реально зависит от настройки спецификаций и прочих подходов к реализации).

Конечно имеет свое название, но!!! в их системе это не требовалось и не велось, все требования к сути операции велись где угодно, но не в системе.

Цитата:

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

На каждую операцию и норму (связь операции + маршрут+номенклатура+РЦ) вы можете задать время выполнения и описание операции, которое затем печатается в в карте задания и маршрутной карте.

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

[S.Kuskov]

Цитата:

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

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

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

[Vals]

Цитата:

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

Потому что следует отличать "нормы выполнения операции" (Связь операции) с Версией маршрута. В версии маршрута появляется порядковый номер операции.

Цитата:

в их системе это не требовалось и не велось, все требования к сути операции велись где угодно, но не в системе

Вы хотите Аксаптушку 21-го века превратить в их старый ФОКС из середины 20-го?

Сводное вы не используете толком, производственно планирование тоже на коленке, маршруты как в старой системе Что поменялось то?

[Hard]

Цитата:

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

Потому что следует отличать "нормы выполнения операции" (Связь операции) с Версией маршрута. В версии маршрута появляется порядковый номер операции.

Ну нет же. Нормы различны в разных маршрутах, а не версиях. А раз указан маршрут и предопределена уникальность операции в этом маршруте - почему в RouteOpr было не добавить порядковый номер? Я бы понял если бы нормировалась операция для рабочего центра и номенклатуры, но ведь указан маршрут-то!

Цитата:

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

Вы хотите Аксаптушку 21-го века превратить в их старый ФОКС из середины 20-го?

Сводное вы не используете толком, производственно планирование тоже на коленке, маршруты как в старой системе Что поменялось то?

Ну с чего Вы взяли, что сводное планирование я не использую. Да я очень ограниченно использую Спланированные заказы. Но этим планирование не ограничивается. Причины уже писал. Мне надо запустить систему с большим функционалом и большим количеством НСИ, но сразу объять необъятное я не пытаюсь. Запустимся, переведем людей из старой Системы на аксапту, наладим учет и полуручное планирование и будем эволюционировать.

[S.Kuskov]

Цитата:

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

Ну нет же. Нормы различны в разных маршрутах, а не версиях. А раз указан маршрут и предопределена уникальность операции в этом маршруте - почему в RouteOpr было не добавить порядковый номер? Я бы понял если бы нормировалась операция для рабочего центра и номенклатуры, но ведь указан маршрут-то!

Ещё раз. Не "указан маршрут", а "может быть указан маршрут" ... а может и не быть указан. RouteOpr.RouteRelation может хранить ссылки не только на маршрут (всё зависит от значения RouteOpr.RouteCode). Как в прочем и ItemRelation.
Посмотрите на систему шире. Её сфера применения не ограничивается только машиностроительным производством. Очевидные для вас вещи могут быть уже не столь очевидны, если посмотреть на них в другом ракурсе.

[Hard]

Цитата:

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

Ещё раз. Не "указан маршрут", а "может быть указан маршрут" ... а может и не быть указан. RouteOpr.RouteRelation может хранить ссылки не только на маршрут (всё зависит от значения RouteOpr.RouteCode). Как в прочем и ItemRelation.

Согласен. Проникся.

[niksen]

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

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

p.s. маршрут накидан просто так.

[S.Kuskov]

Цитата:

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

Что я должен указывать в закладке снизу? Конкретно говоря по "связь номенклатуры" - это поле немного убивает. Какую номенклатуру нужно указывать? Ту, которая нужна на данной операции или ту, которую производим?

Ту, которую производите.

А что касается поля "связь номенклатуры", то это часть, так называемого, паттерна "Таблица/Группа/Все". В аксапте есть ещё много мест где используется данный приём. Суть его в том чтобы реализовать универсальную связь, дав возможность пользователю в каждой конкретной ситуации выбирать будет ли вводимая настройка относится к конкретной записи связанной таблицы (режим "Таблица"), к нескольким записям объеденённым в группу (режим "Группа") или же ко всем записям (режим "Все") В вашем случае из-за уникальности всех операций, скорее всего, использовать нужно режим связи "Таблица".
http://books.google.ru/books?id=jHrP...attern&f=false

[EVGL]

1) Чтобы появлялся список операций в спецификациях, надо открывать форму прямо из карточки изделия, а не из главного меню.

2) Ту, которую производим. Опять-таки, специфичный для изделия маршрут удобно редактировать формы номенклатуры.

[niksen]

EVGL
1) Карточка изделия - форма "сведения о номенклатуре"?
2) Если ту, которую производим, то как я понимаю, в таблице будет связь "таблица" и номенклатура, которую производим, когда же редактируем из формы номенклатуры, то это проставляется автоматически.

[niksen]

S.Kuskov
Я этот паттерн частенько встречаю и везде обычно "таблица" и конкретная запись из-за того, что всё так специфично. Его варианты "группа" и "все", как я понял, нужны для типичных маршрутов, когда не нужно залезать в каждый отдельно и что-то там редактировать, так ведь?

Именно поэтому редактируя маршрут из формы номенклатуры, маршрут сохраняется сразу в таблицу ProdRoute, а редактируя маршрут из модуля "производство" и создавая его для конкретной номенклатуры, он находится в таблице Route.

[S.Kuskov]

Цитата:

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

Именно поэтому редактируя маршрут из формы номенклатуры, маршрут сохраняется сразу в таблицу ProdRoute, а редактируя маршрут из модуля "производство" и создавая его для конкретной номенклатуры, он находится в таблице Route.

Нет. Это вы что-то путаете. ProdRoute - это матршрут производственных заказов. Записи в этой таблице создаются в момент создания производственного заказа копированием соответствующего маршрута номенклатуры.

Возможно вас ввела в заблуждение форма RouteInventProd. На мой всзгляд это самая ужасная форма в аксапте

[EVGL]

Цитата:

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

Именно поэтому редактируя маршрут из формы номенклатуры, маршрут сохраняется сразу в таблицу ProdRoute, а редактируя маршрут из модуля "производство" и создавая его для конкретной номенклатуры, он находится в таблице Route.

Вы ошибаетесь. Редактирутся в ProdRoute, а сохраняется в Route+RouteOpr.

[niksen]

RouteInventProd, именно она. А копирует маршрут из Route в ProdRoute класс ProdRouteCopyProd?