Доопрацювання BAS ERP — Штрихкодування виробничого циклу

12Об'єкти у BAS — огляд

Доопрацювання у вигляді розширення конфігурації (.cfe). Типова не модифікується.

Доопрацювання типових об'єктів: документ «Виробнича операція» — обробник ПередЗаписом для звіряння з вкладкою «Забезпечення».

13Регістр «ЖурналПроходженняШК»

Зберігає кожну подію сканування на проміжних виробничих етапах.

Періодичність: у межах секунди (щоб не агрегувати події у межах одного запису).

Хто пише: тільки модуль «МобільнийСканерAPI» при обробці RegisterTransitScan. Ручне редагування — тільки адмін.

14Довідник «ПристроїСканування»

Auto-додавання нових пристроїв

При першому запиті від невідомого Code:

1. Створюється елемент з Активний = false
2. Назва = «НОВИЙ: <Code> (підтвердити адміну)»
3. HTTP-сервіс повертає 403 з повідомленням
4. Мобільний показує «Зверніться до адміна, ID: ...»
5. Адмін заходить, перейменовує і ставить Активний = true

15Налаштування Етапів (= Видів робочих центрів)

«Етап мобільного» = «Вид робочого центру» у BAS (типовий обʼєкт). Адмін активує які саме ВРЦ доступні мобільному.

Обробка «НалаштуванняЕтапівМобільного»:

• Таблична частина: Вид робочого центру · Активний у мобільному (галочка) · Точка входу (тільки одна може бути true) · Підрозділ (auto, read-only)
• Кнопка «Перевірити налаштування» валідує: є хоча б 1 точка входу, всі активні мають підрозділ
• Зміни зберігаються у регістр «АктивніЕтапиМобільного»

Як використовується: метод GetActiveStages повертає лише ті ВРЦ де Активний = true. Якщо адмін відключає етап — мобільний через ~1 хв (TTL кешу) перестає його показувати.

16Документ «Передача матеріалів до комори»

Типовий BAS-документ. Структура НЕ змінюється. HTTP-сервіс програмно створює і заповнює.

Що заповнює HTTP-сервіс

Підтягування номенклатури

1. За ШК шукаємо документ «Приймання листа»
2. Беремо: Номенклатура, Характеристика, Серія (= ШК)
3. Кількість = 1, ціна — пусто

Проведення: за замовч. НЕ проводимо — зберігаємо як чернетку для перевірки обліковцем. Якщо у налаштуваннях «Авто-проводити» — провести в момент створення.

17Документ «Виробнича операція» — звіряння через Забезпечення

Типовий BAS-документ. Доопрацювання — обробник ПередЗаписом + кнопка «Сканувати ШК» на формі.

Що додаємо у форму

• На вкладці «Використані листи» — кнопка «Сканувати ШК»
• Сканований ШК → додається рядок з auto-заповненням Номенклатури/Серії

Логіка звіряння при збереженні

1. Беремо ШК з таблиці «Використані листи»
2. Беремо ШК з вкладки «Забезпечення» етапу
3. Перевіряємо що кожен «Використаний» є у «Забезпеченні»
4. Якщо ні — попередження: «Лист <ШК> не у Забезпеченні етапу, продовжити? Так/Ні»
5. У «Жорсткому» режимі (налаштування) — замість попередження видаємо помилку, документ не записується
6. За замовч. — «Попередження» (не блокувати, але повідомити)

18HTTP-сервіс «МобільнийСканер» — структура

4 операції. JSON через POST або GET. Авторизація — Basic Auth з користувачем «МобільнийСканерAPI».

Загальні правила обробки

1. Кожен запит містить device_id
2. Сервіс шукає пристрій у «ПристроїСканування» за Code
3. Не знайдено — auto-додає як новий, повертає 403
4. Знайдено, але Активний=false — 403 з повідомленням
5. ОК — оновлюємо «ДатаОстанньоїАктивності», обробляємо
6. Лог запиту у регламентний журнал BAS

Формат помилок: JSON з error_code (константа), message (українською), details (об'єкт).

Приклади запитів і відповідей (4 методи)

{
  "sheets": [
    { "code": "5901234123457", "nomenklatura": "Лист 1420×6000×12",
      "supplier": "ТОВ Метінвест", "in_stock": true },
    { "code": "5901234123458", "nomenklatura": "Лист 1220×6000×10",
      "supplier": "ТОВ Метінвест", "in_stock": true }
  ],
  "as_of": "2026-05-22T10:15:00Z"
}

{
  "stages": [
    { "code": "FREZ", "name": "Фрезерування", "is_entry_point": true },
    { "code": "PLAZMA", "name": "Плазмовий різ", "is_entry_point": false },
    { "code": "WELD", "name": "Зварювання", "is_entry_point": false }
  ]
}

{
  "device_id": "abc123def456",
  "stage": "FREZ",
  "sheets": ["5901234123457", "5901234123458"],
  "timestamps": ["2026-05-22T10:32:14Z", "2026-05-22T10:33:02Z"]
}

{
  "ok": true,
  "document_id": "ПМК-2026-05-22-00018",
  "accepted_sheets": 2,
  "rejected": []
}

{
  "device_id": "abc123def456",
  "stage": "PLAZMA",
  "events": [
    { "sheet": "5901234123457", "ts": "2026-05-22T14:05:23Z" },
    { "sheet": "5901234123458", "ts": "2026-05-22T14:08:11Z" }
  ]
}

{
  "ok": true,
  "registered": 2,
  "shift_resolved": "Зміна-2 (14:00-22:00)"
}

19Звіт «Виконання операцій для ЗП»

Параметри

Структура виводу

• Якщо період > 1 дня → перше групування за Датою
• Друге — Етап
• Якщо підрозділ зі змінами — третє за Зміною
• У рядках — ШК, час, ім'я пристрою
• Колонка-підсумок «Кількість листів» по групах

Експорт: стандартні Excel / PDF.

20Алгоритм: сканування на точці ВХОДУ

Послідовність при обробці RegisterEntryScan:

1. Перевірити device_id. Якщо не пройшло — 403
2. Перевірити що stage відповідає ВРЦ з Точка входу = true. Якщо ні — 400
3. Перевірити що sheets не порожній. Інакше — 400
4. Для кожного ШК:
   • Знайти документ «Приймання листа»
   • Не знайдено → rejected з причиною «not_in_receiving»
   • ШК уже у регістрі за 24 год → rejected з «already_in_production» + інформація з якого пристрою/коли
   • Інакше → accepted
5. Якщо accepted порожній — 409 з переліком rejected
6. Створити документ «Передача матеріалів до комори»: один документ на всі accepted ШК, заповнення з «Приймання»
7. Записати документ (без проведення, якщо «Авто-проведення» вимкнено)
8. Повернути 200 з document_id і списками accepted/rejected

Транзакційність: кроки 5-7 — в одній транзакції BAS. Якщо запис впав — нічого не зберігається, повертаємо 500.

21Алгоритм: сканування на проміжному етапі

Обробка RegisterTransitScan:

1. Перевірити device_id
2. Перевірити stage — активний ВРЦ? Інакше — 404
3. Перевірити events: не порожній, кожна подія має sheet + ts
4. Для кожної події:
   • Перевірити чи ШК існує у системі (у «Прийманні листа»). Не існує → rejected
   • Визначити зміну за часом і графіком підрозділу етапу (див. §23)
   • Створити запис у «ЖурналПроходженняШК»
5. Повернути 200 з registered і rejected

Дедуплікація: дублювання одного ШК на одному етапі в межах 60 секунд — один запис. Другий ігноруємо, мобільному не повідомляємо помилку.

22Алгоритм: ОТК + звіряння з Забезпеченням

Виконується у BAS-формі документа «Виробнича операція», без мобільного.

1. ОТК відкриває документ → вкладка «Використані листи»
2. Натискає «Сканувати ШК» → відкривається допоміжна форма з полем введення (приймає Enter — стандарт USB-сканера у HID-режимі)
3. На кожен сканований ШК:
   • Шукаємо лист у системі
   • Знайдено → додаємо рядок у таблицю з номенклатурою/серією
   • Не знайдено → повідомлення «Лист не знайдено»
4. «Закрити» — закриває форму сканування
5. ОТК натискає «Провести і закрити»
6. Обробник ПередЗаписом робить звіряння з Забезпеченням (див. §17)
7. Якщо все ОК — документ проводиться, готовий виріб має зв'язок до листів
8. Якщо є невідповідність — попередження (або помилка у «Жорсткому» режимі)

23Прив'язка події до зміни — алгоритм

Як автоматично визначається «Зміна» при запису у регістр:

1. З Етапу події → отримуємо Підрозділ (реквізит ВРЦ)
2. З Підрозділу → Графік роботи (типовий реквізит)
3. Тип графіку:
   • «Без змін» → у «Зміна» записуємо «—»
   • «Зі змінами» → для часу події знаходимо зміну з інтервалом що включає цей час. Записуємо назву
4. Якщо подія потрапляє у пересмінку → записуємо попередню зміну + коментар: «Пересмінка (наступна Зміна-3)»
5. Графік не налаштований → «Зміна не визначена», подія потрапляє у звіт як аномалія

24Поведінка мобільного додатку (бізнес-вимоги)

Це НЕ архітектура. Описуємо що робить додаток, без подробиць як закодовано. Розробник вирішить технічну реалізацію.

При першому запуску

• Додаток отримує і зберігає свій ідентифікатор (Android ANDROID_ID)
• Першим екраном — налаштування адреси HTTP-сервісу + тест зʼєднання
• При першому з'єднанні — пристрій авто-додається у BAS у статусі «потребує підтвердження»
• До підтвердження адміном — додаток показує «Зверніться до адміна» і не дає сканувати

При повторних запусках

• Підтверджений пристрій → показується останній етап і кнопка «Сканувати»
• Якщо є несинхронізовані сканування — індикатор «N не синхронізовано»

При втраті мережі

• Нові сканування зберігаються локально зі статусом «не синхронізовано»
• UI показує що мережі нема, але дозволяє продовжувати сканувати
• Список дозволених ШК — використовується останній відомий

При відновленні мережі

• Авто-синхронізація накопичених сканувань (без участі робітника)
• Після синхронізації — сканування → read-only
• Якщо BAS повернув валідаційну помилку — статус «відхилено» з причиною українською

Переключення етапу

• Робітник у налаштуваннях обирає інший етап з активних
• Незавершені сканування з попереднього — не втрачаються, синхронізуються як були
• Нові сканування пишуться у новий етап

25Межові випадки

26Тестові сценарії

Описи українською для перевірки реалізації. Формат: ситуація — дії — очікуваний результат.

1. Перше використання нового пристрою

Ситуація: новий планшет, адмін не додав у BAS. Дії: робітник встановлює додаток, налаштовує адресу HTTP. Очікується: у BAS з'явився новий пристрій (Активний=false). Додаток показує «Не активований, ID: ...». Сканування недоступне.

2. Підтвердження пристрою адміном

Дії: адмін перейменовує («Цех №1 — Сканер А»), ставить Активний=true. Очікується: робітник перезапускає (або чекає 1 хв) — пристрій працює, доступний вибір етапу.

3. Успішне сканування на точці ВХОДУ

Дії: робітник на Фрезеруванні сканує ШК «5901234123457» (валідний). Синхронізує. Очікується: у BAS створений документ «Передача матеріалів до комори» у чернетках з 1 рядком (Лист 1420×6000×12). У мобільному ШК → «синхронізовано».

4. ШК не знайдено у Прийманні

Дії: сканує «9999999999999» (нема у Прийманні). Очікується: поле червоне, «Лист не знайдено у Прийманні». У буфер НЕ додається.

5. Конфлікт — лист уже у виробництві

Ситуація: робітник №1 о 09:00 відсканував ШК і синхронізував. Робітник №2 о 09:15 теж сканує цей ШК. Очікується: BAS повертає 409. ШК → «відхилено» з причиною «Лист уже у виробництві, пристрій Цех №1 — Сканер А о 09:00».

6. Робота без мережі і подальша синхронізація

Дії: у цеху без Wi-Fi робітник сканує 10 ШК. Виходить у зону з Wi-Fi. Очікується: авто-синхронізація. У BAS у регістрі 10 записів зі зміною за часом і графіком підрозділу.

7. Дублювання сканування на проміжному етапі

Дії: ШК о 14:00 і 14:00:30 (помилково). Очікується: у регістрі — один запис (другий через дедуплікацію). Мобільний показує обидва успішні скани.

8. Звіряння у ОТК — успіх

Ситуація: у Забезпеченні листи «5901234123457» і «5901234123458». Дії: ОТК сканує обидва, проводить документ. Очікується: документ проводиться, готовий виріб має зв'язок з 2 листами.

9. Звіряння у ОТК — невідповідність

Ситуація: у Забезпеченні «5901234123457». ОТК сканує «9999999999999». Очікується (Попередження): «Лист 9999999999999 не у Забезпеченні, продовжити?». Жорстко: документ не проводиться.

10. Звіт за період

Дії: запустити звіт за період 01.05–31.05. Очікується: групування Дата → Етап → Зміна → ШК. У підсумках — кількість листів. Фільтри за підрозділом і пристроєм.

11. Адмін відключає етап під час роботи

Дії: адмін знімає галочку «Активний у мобільному» для одного етапу. Очікується: робітник може закінчити поточне сканування і синхронізувати. Через 1 хв — етап зникає зі списку.

12. Запит з неактивованого пристрою

Ситуація: хтось викачав APK і налаштував з'єднання. Очікується: BAS отримує запит з невідомим device_id, auto-додає у довідник зі статусом «потребує підтвердження», повертає 403.

27Що НЕ входить у проект

• Інтерфейс друку етикеток зі ШК для нових листів — типовий механізм BAS
• Звіт «Трасування виробу» (виріб → листи-сировина → постачальник) — типовий BAS
• Звіт «Незавершені листи» — типовий BAS
• iOS-додаток — тільки Android
• Push-нотифікації робітнику — не передбачено у першій черзі
• Інтеграція з Google Play Store — внутрішнє розповсюдження APK
• Технологічний стек мобільного (Android API level, фреймворки, бібліотеки) — окремий артефакт «Engineering choices», оновлюється перед стартом розробки