Использование Workflow в Microsoft Dynamics AX 2009

[propeller]

Правильно ли я понимаю, для того чтобы создать свой шаблон с возможностью утверждения например клиентов, необходимо в табличку CustTable добавить поле со статусом, что-то вроде WorkflowApprovalStatus. И основываясь на этом статусе позволять пользователям утверждать/отклонять и т.п. ? (помимо того, что советуем нам Аманд)

[Ivanhoe]

Да.

[mit]

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

[Ivanhoe]

Простите, вы считаете, что Аманд привел реальный рабочий пример? Каждый раз надо на форме менять метод?? ))

Чтобы хотя бы понять, отправлен уже на рассмотрение клиент или нет, понадобится некий признак. Также если вы хотите нормально реализовать отзыв клиент (запрос на отмену утверждения), то без промежуточных статусов также не обойтись (нужен признак отзыва до срабатывания cancel самого workflow). Ну и сам факт утверждения надо как-то в системе отметить - иначе зачем весь этот workflow?

[mit]

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

[Ivanhoe]

Я не против системы Workflow, я ее использую на проектах. Мои замечания к статье Аманд - это не описание полноценного примера, это скорее туториал для ознакомления.

Последовательность действий по утверждению клиентов, судя по документу нужно:
1. Есть стандартная форма клиентов. Без статуса.
2. Заводим нового клиента - что нужно сделать администратору чтобы его послать на утверждение? Кроме настройки бизнес-правила нужно на форме поменять метод canSubmitToWorkflow()? Ок, меняем.
3. Что нужно сделать администратору, чтобы по клиенту из п.2. сделать утверждение? Поменять метод canSubmitToWorkflow() назад? Ок, меняем метод, утверждение пока не делаем - допустим ответственный думает.
4. Заводим нового клиента и хотим отправить на утверждение - опять что ли меняем метод canSubmitToWorkflow() на форме???? В этот момент, у вас по всем клиентам станет доступна только отправка на утверждение, в т.ч. по клиенту из п.2.
5. Какой признак в системе у утвержденного клиента? Кроме истории утверждения? Сама история по себе никому не нужна. Нужно, как правило, проставить некий статус, ну или, убрать блокировку с клиента, чтобы на него можно было заводить документы - это нужно явно программировать.

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

Чтобы пользователь мог настроить любое бизнес-правило, нужно правильно запрограммировать workflow - предусмотреть все возможные (вернее, нужные по бизнесу) переходы состояний. Как это сделать без статуса документа я не представляю, расскажите про свой опыт.

[mit]

Quote:

Originally Posted by Ivanhoe

Аманд - это не описание полноценного примера, это скорее туториал для ознакомления.

Согласен. писалось консалтинговой компанией. но если немного переработать статью, получается нормальная инструкция.

Quote:

Originally Posted by Ivanhoe

Последовательность действий по утверждению клиентов, судя по документу нужно:
1. Есть стандартная форма клиентов. Без статуса.
2. Заводим нового клиента - что нужно сделать администратору чтобы его послать на утверждение? Кроме настройки бизнес-правила нужно на форме поменять метод canSubmitToWorkflow()? Ок, меняем.

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

Quote:

Originally Posted by Ivanhoe

3. Что нужно сделать администратору, чтобы по клиенту из п.2. сделать утверждение? Поменять метод canSubmitToWorkflow() назад? Ок, меняем метод, утверждение пока не делаем - допустим ответственный думает.

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

Quote:

Originally Posted by Ivanhoe

4. Заводим нового клиента и хотим отправить на утверждение - опять что ли меняем метод canSubmitToWorkflow() на форме???? В этот момент, у вас по всем клиентам станет доступна только отправка на утверждение, в т.ч. по клиенту из п.2.

см. п.3

Quote:

Originally Posted by Ivanhoe

5. Какой признак в системе у утвержденного клиента? Кроме истории утверждения? Сама история по себе никому не нужна. Нужно, как правило, проставить некий статус, ну или, убрать блокировку с клиента, чтобы на него можно было заводить документы - это нужно явно программировать.

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

Quote:

Originally Posted by Ivanhoe

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

существующие шаблоны в системе ущербны

Quote:

Originally Posted by Ivanhoe

Чтобы пользователь мог настроить любое бизнес-правило, нужно правильно запрограммировать workflow - предусмотреть все возможные (вернее, нужные по бизнесу) переходы состояний. Как это сделать без статуса документа я не представляю, расскажите про свой опыт.

по большому счету, шаблоны воркфло это перечисление статусов, которые может иметь документ (строка). да, их определяет программист. ещё программист может определить, что как только по строке в статусах воркфло появилось финальное одобрямс, в таблице поле блокировки перещёлкнолось, но не этим интересен вокфло. если нужно видеть два статуса - одобрено /не одобрено, проще пользовать существующее поле, либо добавить своё. интересно вокфло вариативностью. когда сценарии ободрения различаются. пример: клиент категории "а" утверждается менеджером сразу, категория "б" - требует "ок" от менеджера направления и дополнительно визы руководителя, если клиент одновременно из сегмента "вип", то финальный ок ставится только директором. в случае, если директора нет, или директор не одобрил в течение 3-х часов, уведомление для утверждения переадресовывается системой заму (или иному сотруднику). количество вариаций и маршрутов на статусах определённых программистом не ограничено, и уже не программируется а настраивается. допустим, программист задал три статуса: отправить, согласовано, утверждено. в маршруте можно настроить обязательное последовательное согласование через десяток сотрудников. за работу всего этого отвечают таблицы, классы, формы и прочие объекты семейства с префиксом Workflow. надеюсь, что разница между разблокировкой клиента и вокфло хоть немножко стала понятнее.

[Ivanhoe]

Quote:

Originally Posted by mit

да я считаю, что аманд привел реальный рабочий пример, так как я сам по этому примеру настраивал воркфло

Quote:

Originally Posted by mit

Согласен. писалось консалтинговой компанией. но если немного переработать статью, получается нормальная инструкция.

Вы определитесь уже

Quote:

Originally Posted by mit

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

Вы точно говорите про метод canSubmitToWorkflow()?? Этот метод отвечает ТОЛЬКО за возможность первоначально запустить воркфлоу по записи. Если этот метод будет на форме возвращать "true" для всех записей, то кроме отправки на согласование ничего другого доступно не будет.

Quote:

Originally Posted by mit

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

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

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

[mit]

да уж давно определился

Quote:

Originally Posted by Ivanhoe

Вы точно говорите про метод canSubmitToWorkflow()?? Этот метод отвечает ТОЛЬКО за возможность первоначально запустить воркфлоу по записи. Если этот метод будет на форме возвращать "true" для всех записей, то кроме отправки на согласование ничего другого доступно не будет.

а если немножко иначе подойти?

public boolean canSubmitToWorkflow()
{
    boolean canSubmitToWorkflow = false;
    ;

    if(!BOMTable.Approved)
    {
        canSubmitToWorkflow = !WorkflowTrackingStatusTable::existStep(BOMTable);
    }
    return canSubmitToWorkflow;
}

Quote:

Originally Posted by Ivanhoe

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

для вокфло нет, для коллеги - возможно да

Quote:

Originally Posted by Ivanhoe

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

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

[Ivanhoe]

Приведенного кода метода canSubmitToWorkflow() достаточно. Что и требовалось доказать, пример Аманда не рабочий

Спасибо за обсуждение.

[propeller]

Попробовал сделать workflow на справочнике клиентов, CustTable входит в табличную коллекцию, которая в свою очередь принадлежит к виртуальной компании.
Результат: не заработало, полезли ошибки. Частенько в коде встречается: changecompany(record.dataareaid - ошибка: компании не существует.
Workflow не предназначен для таких таблиц?

[dmitro]

На одном проекте было реализовано; правда таблицы, подлежавшие согласованию были saveDataPerCompany = No, но в коллекцию были добавлены все системные таблицы workflow плюс таблицы, которые участвуют в конфигурации бизнес-правил. Все работало ок.

[Vadik]

Quote:

Originally Posted by propeller

Попробовал сделать workflow на справочнике клиентов, CustTable входит в табличную коллекцию, которая в свою очередь принадлежит к виртуальной компании.
Результат: не заработало, полезли ошибки. Частенько в коде встречается: changecompany(record.dataareaid - ошибка: компании не существует.
Workflow не предназначен для таких таблиц?

Workflow does not work with a table that is shared in a virtual company in Microsoft Dynamics AX 2009 Service Pack 1

Symptoms
Consider the following scenario. You set up a workflow to use a table that is shared in a virtual company in Microsoft Dynamics AX 2009. You use a placeholder for submission instruction in the workflow configuration. In this scenario, when you try to submit the workflow, you receive the an error message that resembles the following:
Stack trace: The company <Virtual Company_Name> does not exist.
(S)\Classes\WorkflowDocumentField\substitutePlaceholder - line 53
(S)\Classes\WorkflowDocumentField\substitutePlaceholderAsUser - line 22
(S)\Classes\SysWorkflowFormControls\getActionBarContentForSubmit - line 41
(C)\Classes\SysWorkflowFormControls\showSubmit - line 18
(C)\Classes\SysWorkflowFormControls\updateControls - line 29
(C)\Classes\SysSetupFormRun\updateWorkflowControls - line 4
(C)\Classes\Info\formNotify - line 30

KB2557175 (ссылка на Partnersource)