Вэнь/Миндао Консультант по облачным продажам Сюн Минь
Я столкнулся с различными конкретными сценариями многих разных клиентов.Когда эти разные сценарии сочетаются с основными функциями облака Mingdao, они внезапно обнаружат, что все они имеют одинаковые отношения.Используемые функциональные точки в основном такие же, как и конфигурация логика. Далее я поделюсь конкретным клиентским сценарием «автоматически распределять сумму платежной квитанции в соответствии с узлом контракта».
1. Анализ требований сценария
В управлении контрактами есть несколько узлов контракта, и каждый узел контракта имеет соответствующие данные, которые необходимо получить.Покупатель произведет оплату после получения счета, а финансовый отдел зарегистрирует платеж.В это время сумма платежа и соответствующий Сумма узла контракта сопоставляется и вычитается в порядке (последовательность дат узла контракта) до тех пор, пока не будет выделена текущая сумма платежа.
Когда я узнал о сцене по телефону, я был на самом деле довольно сбит с толку отношениями между объектами данных, поэтому я снова общался, записывая стыковку данных бумагой и ручкой во время общения, и соответствующую диаграмму отношений, чтобы помочь понять, изначально разобранный объект данных.
2. Начальная посадка спроса
Разобравшись в связи данных, я обнаружил, что сложность этого сценария заключается в том, что при проектировании процесса необходимо сравнивать исходные данные (сумма возврата) и существующие стандартные данные (узлы договора) по порядку (дата заказа договора узлы), и вычесть вычесть, оставшиеся данные после вычета каждого раунда сравниваются со следующими данными, и этот цикл повторяется.
После того, как я понял это, это было почти то же самое, что служба распределения интервалов оценки производительности, которую мы сделали несколько дней назад для клиента с потребностями в управлении производительностью, и это было даже проще, поэтому я спросил нашего студента по внедрению Цзян Хао, и начал реализовать требования посредством практической эксплуатации системы.
Ключевые функции: последовательное выполнение подпроцессов, использование параметров процесса.
Конфигурация системы: план посадки
1) Конфигурация рабочего листа:
Сначала завершите настройку таблицы хранения данных [рабочий лист], что очень просто, просто настройте взаимосвязь между четырьмя объектами данных.
2) Конфигурация рабочего процесса:
Проверка: введите простые данные для выполнения результатов проверки процесса.
Введите простые данные, чтобы проверить правильность конфигурации процесса.
Выявление проблем/блоков
Введите данные для выполнения теста и обнаружите, что результаты данных явно не совпадают с теорией.Начните находить проблему, понимая системные функции, в сочетании с просмотром истории выполнения рабочего процесса и ситуации с журналом рабочего листа.Причина заключается в том, что ключевая функция [параметры процесса] не следует за первой. Она обновляется до последнего значения в следующей операции сравнения и используется следующей операцией сравнения. Исходные данные (сумма возврата) всегда вводятся в операция потока.
3. Когда лендинг заблокирован, подумайте о смене ключевого объекта
Оставшееся количество каждой операции сравнения не может быть использовано [Параметры процесса], так как же мы можем использовать такие данные? Решение состоит в том, чтобы записать результаты расчета в форму, ввести процесс для использования и обновлять данные один раз за раз.
Конфигурация выглядит следующим образом:
1) «Рабочий лист квитанции об оплате»: добавлено поле [Расчетное значение ссылки на подпроцесс];
2) Рабочий процесс: параметры процесса используются для поиска данных, а не для их хранения; узел обновления добавляет обновление во вспомогательное поле [вычисляемое значение ссылки подпроцесса].
Логическая конфигурация двух схем до и после одинакова, смотрите подробное сравнение функций:
1) Сравнение рабочих листов: добавлено поле копирования для хранения данных [расчет подпроцесса]
2) Сравнение рабочего процесса:
4. Вдохновение
Процесс этой посадки спроса и продолжающийся »Разберите процесс и добавьте промежуточные данные, чтобы упростить сложность"в соответствии с идеями.
Например, эта идея использовалась для решения регулярного триггерного напоминания и итогового процесса в последний день каждого месяца. Сложности при демонтаже:
1) Объективные факты: Дата последнего дня каждого месяца не фиксирована.
2) Ограничение инструмента: триггер времени текущей системы не поддерживает вычисление даты.
Шаг 1: Решите первую задачу: как рассчитать дату последнего дня каждого месяца;
Шаг 2: Подумайте, как можно использовать существующие условия. Я знаю метод расчета, но триггер синхронизации не поддерживает расчет, а затем напрямую вычисляет данные даты последнего дня, как его использовать;
Шаг третий: демонтаж. Система имеет функцию запуска по полю даты и записывает данные операции в форму, которая используется в качестве триггера и условия «триггера по времени».