Документація – вступна сторінка
AyMINE – Technical doc. (in English)
abra
crm
- Модуль Контакти та адресної книги
- Системні права та налаштування CRM-модуля
- Огляд замовлень клієнтів
- Довідник
- Список і управління каталогами
- Політика конфіденційності та ділової інформації
- Надсилайте масові повідомлення відповідно до GDPR
- Патік масової електронної пошти
- Вихід і встановлення преференцій
для масової - Як коректно забути дані про людину
- Масові повідомлення електронної пошти
- Контракти, договори
- Партнер за контрактом
- Групи клієнтів
- Каталог або люди і компанії
- Контакти
- Швидко доступні контакти
sabre
hr
- Модуль персоналізації
- Цифровий кадровий архів
- Персоналізація – права користувача
- Облік кандидатів на роботу
- Посада
- Член команди – Працівник
- Огляд працівника
- Огляд власного персоналу
- Відповідальний персоналіст
- Синхронізація працівників та користувачів системи
- Трудовий договір
- modulesafety
- personalfolder
sys
- Системний модуль фреймворку AyMINE
- Клієнт
- Настроювання шлюзів для зовнішніх повідомлень
- Повідомлення із зовнішнім світом
- Правила для зовнішніх повідомлень
- Документи
- Додаткові функції з файлами
- Копіювання та переміщення файлів між об'єктами
- Презентація зображення
- Публічне посилання на документ
- Останні файли
- Дошка
- Розташування об'єкта на дошці оголошень
- Елементи клієнта
- Огляд і коментарі
- Безпека повідомлень і внутрішніх дискусій
- Переклади
- Зв'язки між об'єктами
- Типи сесій (відносин)
- Ролі та команди груп
- Користувач системи
- Адміністрація користувача
- GDPR та користувачі системи
- Безпечний вхід
- Адміністрація користувача
- Криптогаманець
- moduleclientoptions
frm
- introhelp
- introhelp_objectdetail
- AyMINE Framework
- Політика зберігання паролів
- Права користувача framework
- Модулі AyMINE
- Замки користувача
- Системні дозволи
- introhelp_deleting
- introhelp_settings
- introhelp_objectlist
- introhelp_dashboard
- introhelp_generalinfo
- introhelp_icons_dnadrhal9000_mar-22-220246-2023_caseconflict
- introhelp_icons
- Записи AyMINE
tsk
- 8D report
- Основним елементом FMEA
- FMEA
- FMEA - ймовірність виявлення
- Процес аналізу FMEA
- FMEA - ймовірність виникнення
- FMEA - оцінка тяжкості
- Модуль керування завданнями та інформаці
- Адміністрація модуля Управління завданнями
- Системні права модуля керування завданнями
- Події
- Акції, події та наради
- Персональний календар
- Журнал активності
- Згода керівника
- Чому не можна видалити деякі дані
- Область
- Область / проект / методологія
- Огляд областей
- Шаблони міток
- Управління тегами
- Мої області
- Подія
- Архівний пакет
- Кваліфікація, здібності / вміння
- Рівні компетентності та кваліфікації
- Необхідні здібності
- GDPR та облік кваліфікацій
- Право на управління кваліфікацією користувачів
- Кваліфікація користувача або контакту
- Команда проекту
- Рішення
- Об'єкти, які приймаються рішення
- Варіант прийняття рішень
- Шаблон плану / стратегії
- Визначення проекту
- Зразок запису
- Зразок ризику
- Визначення пакета
- шаблон завдання
- Активація події із завдання
- Управління відповідальністю – RACI matice
- Повідомлення про події
- Об'єкти, що відносяться до шаблонного завдання
- Події, що починаються
- Призначення нового завдання
- Обговорення
- Бізнес-подія
- Кнопки для активації події
- Події подій
- Покращення та запобіжні заходи
- Інформація
- Ключове слово
- Проведення наради
- Методики та правила
- Обов'язок
- Поняття
- Директиви та політики
- Управління змінами в проекті
- Проблеми, тікети та їх управління
- Центр обслуговування клієнтів
- Внутрішня довідка
- Об'єкти, яких стосується проблема
- Управління інцидентами, невідповідність якості
- Проект
- Графік проекту
- Команда проекту або команда до робочого процесу
- RACI-матриця для project
- Повернути план проекту за baseline
- Записи та журнали
- Записані дії
- Вимоги
- Вимоги до вступників
- Ризик
- Завдання
- Терміни викликів
- Огляд завдань
- Вплив завдання на право змінювати підключений obje
- Особисте завдання
- Член команди
- Об'єкти, які обробляються в задачі або вирішуються
- Завдання працівника
- Тест
- Типи тестів
- Попередження
- Попередження – приклад використання
- Попередження для себе
- tsktask_kanban
- moduleclientoptions
am
- amasset
- Модуль управління активами
- Процедура відбору та закупівлі
- Аналітична модель
- Постачальник продукту
- Категорія продуктів
- Властивість продукту або продукту
- Мета проекту
- Комерційна пропозиція
- Перерахувати пропозицію та замовлення
- Права доступу до пропозицій і цін
- Системний запит про стан замовлення
- Продукти та товари
- Стан продукту та його зміна
- Одиниці продуктів
- Критерії якості
- Про критерії якості продукції
- HARA продукту
Бізнес-подія
Подія в системі виражає, що в реальному світі відбулася конкретна подія. Прикладами подій є:
- початок місяця,
- вимога податкової інспекції,
- Прихід працівника.
Об'єкт подія описує події, на які система може якось реагувати. Події можуть відбуватися неодноразово, кожного разу відбувається так звана поява події (вона фіксується в системі окремо).
Активація події означає, що виникають умови виникнення події, система створює нове виникнення і запускає дії, які пов'язані з виникненням події.
Коли відбуваються події
Події відбуваються в одному з наступних випадків:
- Події, задані часом, наприклад, початок дня, місяця або року
- Події, пов'язані зі зміною об'єкта відбуваються, коли відбувається дана зміна – об'єкт створюється, видаляється або змінюється його стан. (Наприклад, виконано завдання)
- Події, що активуються вручну являють собою подію, яку система сама не може/не може розпізнати, але в ній є процеси, за допомогою яких повинна реагувати на дану подію. Прикладом такої події є Запит фінансового органу на інформацію, стихійна подія і т.д.
Активувати події вручну дає можливість запускати процеси, за допомогою яких потрібно реагувати на подію. Працівник, який активує подію, може не знати, як система повинна реагувати на подію, він використає знання про необхідність активації події.
Зв'язок події з об'єктом
Подія, якщо вона відбувається на основі зміни стану об'єкта, повинна відноситися до об'єкта управління. Але це не обов'язково має бути відношення до об'єкта, за змінами якого дійсно стежать. Наприклад, для подій, керованих завданням, виникнення події регулюється появою або зміною стану завдання, але визначення події відноситься до визначення завдання. Таким чином, подія повинна бути переведена на визначення завдання, а сама система забезпечує, щоб виникнення події регулювалося зміною стану завдання, створеного на основі цієї моделі.
Категорія події
AyMINE розділяє 2 категорії
- Системні події визначаються системою. Користувачі можуть користуватися ними, але їх не можна ні активувати, ні змінювати.
- Події користувача є більш цікавими, оскільки вони описують події в бізнесі / житті користувача. Їх можна вільно управляти і вручну активувати.
Обмеження генерації події
Якщо подія має встановлені дати з якого часу та/або до якого часу вона може бути активована, вона ніколи не активується поза цими межами, незалежно від того, чи відбулася подія, яка повинна її запустити.
Регулярне генерування події
Події можуть бути встановлені, щоб генеруватися регулярно протягом певного інтервалу (наприклад, один раз на рік). Таким чином, система подбає про те, щоб вони були запущені в потрібний час. (Точність часу, з яким запускається подія, залежить від налаштувань системи і коливається від 5 хвилин до години.)
Події неможливо вручну встановити на 1-й місяць. Для цього потрібно використовувати системну подію.
Ручна активація події
Подію можуть вручну активувати працівники, які виконують одну з ролей, призначених події. (Роль може бути і більше.) Працівники події бачать доступну активацію в огляді подій для активації в меню стартової сторінки системи. Таким чином, події, що активуються таким чином, завжди вільні від прив'язки до будь-якого об'єкта, тому, наприклад, неможливо активувати подію з прив'язкою до задачі.
Активізувати події з прив'язкою до об'єкта можна тільки через даний об'єкт, зазвичай змінюючи його стан (наприклад, завершення). Виключно для об'єкта може бути операція, яка безпосередньо веде до генерації події.