О системах планирования ресурсов предприятия Scala, iScala
“ При тестировании, поступивших на вход Epicor Service Connect сообщений, для которых предусмотрено ручное утверждение, несколько раз возникала ситуация, когда на этапе утверждения сообщение редактировалось, причём неудачно, и тогда возникала необходимость посмотреть, что же было до того, как его отредактировали, или на любом другом этапе. И тут пришлось разбираться с перемещением информации из одной таблицы в другую и далее в третью. Весьма занятная аналитическая работа. Чтобы вам не разбираться в этом самостоятельно, поделюсь своими изысканиями
  • Главная
    • О проекте
      • Разъяснение о проекте и его участниках
      • Заявление / Memorandum
    • Новости проекта
    • Список опубликованных материалов основного раздела
    • Информация, перенесённая из старых форумов
    • Подписаться на новостную рассылку
  • Статьи
    • Статьи
    • Избранное
    • Мысли вслух
  • Процедуры
  • Доходчиво о сложном
    • Обучение
    • Как сделать?
    • iScala «для чайников»
    • Оч.умелые ручки
  • Структура таблиц
    • Scala 5.1 SR13
    • iScala 2.2 HF 2.3318
    • Tables structure changes history from iScala 2.2 SR2 to iScala 3.0 FSP4
    • Epicor iScala 2.3 — 2.03.3363
    • Epicor iScala 2.3 SR1
    • Epicor iScala 2.3 SR2
    • Epicor iScala 2.3 SR3
    • Epicor iScala 3.00 FSP 2 — 3.00.02254
    • Epicor iScala 3.0 FSP4 — 3.0.4267
    • Изменение структуры таблиц iScala 3.1 по сравнению с iScala 3.0 FSP4 / Table structure changes between iScala 3.0 FSP4 and iScala 3.1
    • Epicor iScala 3.1 — 3.1.0511
    • Epicor iScala 3.2 — 3.2.0317
    • Epicor iScala 3.3 — 3.3.0419
    • Epicor iScala 3.4 — 3.4.0399
    • Epicor iScala 3.5 — 3.5.0.0429
    • Изменение полей в таблицах БД iScala 3.4 по сравнению с iScala 3.2 / Difference between DB structure of iScala 3.4 and iScala 3.2
    • Изменение полей в таблицах БД iScala 3.5 по сравнению с iScala 2.2 / Difference between DB structure of iScala 3.5 and iScala 2.2
  • Материалы по модулям iScala
    • Главная Книга
    • Основные Средства
    • Книга Закупок
    • Книга Продаж
    • Заказы на Закупку
      • Требования
    • Заказы на Продажу
    • Управление Запасами
    • Установка, Администрирование
      • Настройка определений документов MSRS
    • Заработная плата
    • Структура базы данных
    • Отчётность SSRS
    • Отчётность AFR
    • Примеры отчётов
    • Примеры отчётов AFR
    • Интеграция с другими системами
    • Epicor Service Connect
  • English
  • Контакты
  • Поиск
Главная  »»»  Интеграция с другими системами  »»»  Движение информации из обрабатываемого сообщения с помощью Epicor Service Connect

Движение информации из обрабатываемого сообщения с помощью Epicor Service Connect

19.01.2023 Автор Алексей Васильев

Не всегда интеграции двух систем разрешают работать в полностью автоматическом режиме. Иногда специально добавляют шаг ручного утверждения очередного шага движения информации. Например, в начале запуска очередного типа обмениваемой информации, когда ещё остаётся вероятность, что чего-то не учли. Или, когда принять сообщение можно только тогда, когда в принимающей системе выполнены некоторые подготовительные мероприятия, например, мы уверены, что все необходимые дополнительные затраты включены в себестоимость поступившей продукции (не всегда этот процесс можно и/или нужно автоматизировать на 100%, бывают ситуации, когда это должен решить умный человек, а не безмозглый алгоритм). Коллеги попросили меня создать отчёт, визуализирующий поступившее сообщение до того, как ему будет разрешено двинуться дальше. Я об этом писал в заметке «Как посмотреть в человеческом виде, что внутри сообщения, поступившего на вход Epicor Service Connect?». При тестировании, однако, несколько раз возникала ситуация, когда на этапе утверждения сообщение редактировалось, причём неудачно, и тогда возникала необходимость посмотреть, что же было до того, как его отредактировали, или на любом другом этапе. Разумеется, это всё можно легко посмотреть в административной консоли, но нужно было сделать это доступным пользователю, у которого доступа к административной консоли никогда не было и не предвидится 🙂

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

Первоначально, если в рабочем потоке имеется элемент Task, информация попадает в таблицу ScaAssignedTasks. Затем, после прохождения этого элемента (в нашем случае ручного разрешения прохождения сообщения), информация перемещается в таблицу ScaCompletedTasks, а спустя какое-то время по мере переполнения данными (зависит от настроек инсталляции), перемещается в таблицу ScaTasksArchive.

Чтобы долго не мучиться, пытаясь объединить информацию из этих 3-х таблиц я просто создал 3 разных отчёта:

Чтобы долго не мучиться, пытаясь объединить информацию из этих 3-х таблиц я просто создал 3 разных отчёта

Внутри отчёта можно увидеть события по названию задачи:

Внутри отчёта можно увидеть события по названию задачи

На Task ID можно щёлкнуть и просмотреть информацию в человеческом виде (в каком виде её вывести уже дело техники) 🙂

Рубрика: Интеграция с другими системами Метки: Service Connect
VK Telegram

Copyright © 2023 О системах планирования ресурсов предприятия Scala, iScala.

Gammapolis WordPress Theme by ERP & Business Consulting

Прокрутка вверх