Фішки Fiori

В попередній статті про новації інтерфейсу Fiori були розглянуті загальні принципи побудови нового інтерфейсу, але то все теорія, а от що цікавого, як для користувача, має новий інтерфейс. 

З нашої точки зору, концепція розробки перейшла у поле одна операція = одна плитка Fiori. Тобто, якщо подумати про кола підходу до змін,  все повертається до того, що вже було, але на новому рівні.  Наприклад, до версії 4.6 для руху матеріалу було 3 транзакції: одна на надходження, одна для переміщення запасів і третя для відпуску/списання запасів. Потім пішла тенденція транзакцій одного екрану і була розроблена транзакция MIGO, яка замінили три транзакції, все можна зробити в ній. Як виявилось, універсальний “швейцарський ніж”, штука гарна, але складна. Деякі операції  вимагають введення більшої кількості параметрі, які говорять транзакції одного екрану, що ви хочете зробити. А тому нове коло розробки інтерфейсу повернулось до концепції одна плитка = одна дія і тепер у системі є багато плиток, типу: виконати надходження до замовлення на закупівлю, виконати надходження до виробничого замовлення, виконати надходження до вхідної поставки і таке інше, як на малюнку нижче.

Які переваги? Ну, наприклад, не треба вводити код типу руху, тому що він прописаний відразу до однієї дії і тому вже відомий. Однак, виникає інша проблема – якщо ви створите свій код типу руху, то, нажаль, присвоїти його операції буде не просто. З іншого боку, якщо вам потрібні нестандартні типи руху, то транзакція MIGO все ще доступна, як окрема плитка, і, сподіваюсь, що саму транзакцію не видалять у наступних версіях системи.

Розглянемо як виглядає надходження до замовлення на закупівлю. Відразу після старту система має одне поле вводу, де вам необхідно внести або номер замовлення, або вказати постачальника, або код заводу і тоді система зрозуміє, що вам необхідно внести надходження до замовлення на переміщення запасу.

Якщо вказати код постачальника, то система виведе номери документів замовлень постачальника.

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

А так виглядає надходження у транзакції MIGO, де треба спочатку вказати тип бізнес операції, посилальний тип документу та вказати код типу руху.

Як бачимо, екран ведення надходження через плитку Fiori, значно простіше, ніж такий же екран транзакції MIGO. Ще простіше виглядає екран переміщення запасів між заводами / складами або між типами запасу. Там розробники підійшли до вирішення питання виходячи з того, що не тільки одна операція = одна плитка, а навіть, що один документ переміщення = один матеріал. Чому так зроблено? Ну, напевне, розрахунок був на те, що більшість користувачів, яким треба щось зробити з матеріалом, не роблять це на постійній основі, а тому запам’ятовувати коди типів руху та що куди вводити у транзакції MIGO, якщо це робиться 3-5 разів на місяць, іноді складно, а тому ось вам проста плитка переносу запасу, де ви вказуєте матеріал та потім мишкою обираєте звідки який тип запасу та куди необхідно перенести.

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

Ще одним спрощенням є додавання екрану історії до документів системи. Якщо хтось працював з модулем збуту, то знає про таку штуку як потік документів. От щось схоже було додано до багатьох документів системи. Ця функціональність знаходится зазвичай у секції “Хід процесу” до позицій документа або у заголовку документа. Або можна використати окрему плитку “Потік документів”, де можна вказати будь-який тип документу та отримати розгорнутий потік пов’язаних операцій. Функціональність потоку документів більш розширена, ніж операції відображені у документах.

Давайте розглянемо, як виглядає блок “Хід процесу”, наприклад, у документі заявки на закупівлю. Заявка була трансформована у запит постачальнику, до якого потім був створений відгук цінової пропозиції. Далі було створено замовлення на закупівлю,  до якого було виконано надходження та рахунок фактура постачальника. Тобто повний процес від заявки до отримання запасу. Кнопки плюс та мінус дозволяють змінити масштаб відображення, але при зменшенні масштабу на елементах процесу зникає деяка деталізація типу дат, кодів постачальника та інше. Як бачите, можна прослідкувати за всім процесом обробки заявки на закупівлю, а по-друге, картки документів процесу активні і, зробивши вибір на документі, можна перейти до перегляду документа або до переліку дій, які налаштовані та пов’язані з кожним документом. Таким чином, користувач, який створив заявку, може доволі легко зрозуміти на якому етапі знаходиться обробка його запиту по системі. І такі блоки процесу доступні практично для всіх документів системи, тобто можна легко контролювати наступний поток документів.

Ще більш цікава плитка це “Display Document Flow”, яка показує, крім потоку операційних документів, також і потік пов’язаних документів головної книги, тобто фінансові документи. Виглядає це десь так, як на малюнку нижче, причому якщо ви обираєте документ, який пов’язаний з документами головної книги, то буде підсвічений відповідний документ головної книги. 

Ще з цікавого – можна переглянути обрані документи головної книги у вигляді, так названих, Т-рахунків. Таке відображення дуже полюбляють фінансисти та бухгалтери. Для цього обираєте документи які необхідно відобразити у Т-поданні, та переходите до режиму “Відобразити як Т-рахунки”

Після чого отримуєте таке представлення операцій, як на малюнку нижче. У представленні було включено відображення тільки по головному регістру 0L, відображення допоміжної книги було вимкнуто, для спрощення. 

Таким чином компанія при розробці нового інтерфейсу рухається у напрямку як спрощення так і збільшення наочності відображення інформації для користувача.

З однієї сторони, світ рухається в сторону спрощення та візуалізації, а з іншої це призводить до того, що під таким спрощенням ховається технічне ускладнення систем, задіювання все більш складних алгоритмів та прогнозів, але користувачу це не важливо – важливо просто, швидко виконати свої операції, а аналітику швидко і доступно отримати дані і зв’язки між операціями і документами.