Приймання у клієнтському застосунку
Цей документ описує наскрізний процес приймання так, як він відбувається у клієнтському застосунку (на робочій станції — настільному компʼютері або планшеті керівника зміни). Усі вісім етапів — від створення документа до його закриття — оператор бачить як вкладки й чек-листи у повному робочому інтерфейсі.
Якщо ви шукаєте опис приймання на ТЗД — див. Приймання на ТЗД. Заявка на надходження не входить у цей процес: вона є входом у нього і документується окремо.
Скористайтеся пікером варіацій праворуч (на вузькому екрані — згорнутим блоком над текстом), щоб адаптувати процес під налаштування вашого складу; залиште будь-який вимір без вибору, щоб побачити всі гілки.
Часті сценарії
Етап 1. Створення документа приймання
Документ приймання — це робочий документ, на якому далі тримається весь процес: до нього прив'язуються факти отримання товару, контейнери, розбіжності й закриття. У системі він проходить невеликий набір статусів — Чернетка, поки документ готують, До приймання, щойно його передано в роботу, Прийнято, коли приймання завершене, і Скасовано, якщо документ скасували. Створення документа — перший крок процесу в клієнтському застосунку.
Документ створюється одним із двох способів — на підставі наявної заявки на надходження або з нуля. Вибір способу — це рішення на конкретну поставку, а не налаштування складу: один і той самий склад регулярно використовує обидва шляхи.
Заявка на надходження не входить у процес приймання — це окремий документ, що описує те, що склад очікує отримати. Вона є входом у процес: коли вона існує і вантаж надходить, її використовують як основу для документа приймання. Якщо заявки немає (аварійна поставка, повернення, помилка) — створюють документ приймання без неї.
Спосіб створення документа
Створення із заявки на надходження
Коли керівник зміни відкриває існуючу заявку на надходження, система пропонує побудувати документ приймання на її основі. Користувач підтверджує або налаштовує:
- система формує перелік рядків приймання з рядків заявки, ураховуючи залишок, який ще не запланували приймати іншими документами;
- якщо у заявці вказано контейнери, вони підтягуються у документ повними гілками (включно з вкладеними) — оператору не треба переносити їх вручну;
- кількості у рядках дорівнюють тому, що залишилося отримати; типи пакувань зберігаються з оригіналу, якщо немає часткового приймання;
- користувач може звузити перелік — наприклад, обмежити документ окремими товарами, партіями або контейнерами, якщо машина привозить лише частину заявки.
Після підтвердження документ створюється у статусі Чернетка. Рядки можна коригувати, поки документ у статусі Чернетка або До приймання; редагування закривається після переходу в Прийнято або Скасовано.
Створення без заявки
Коли заявки на надходження немає, документ приймання створюють з нуля:
- користувач вказує склад, постачальника (якщо відомий) і за потреби — інші реквізити документа;
- рядки додаються вручну з каталогу товарів;
- кількості й типи пакувань вводяться оператором;
- контейнери, якщо вони використовуються, додаються окремими діями вручну.
Типові випадки, коли цей шлях доречний: аварійні або позапланові поставки, повернення від клієнтів, переміщення з інших складів без попередньої заявки, виправлення помилок у вже закритих документах через створення нового.
Етап 2. Очікування поставки
Після того, як відділ закупівель оформив замовлення постачальникові, інформація про очікуване надходження потрапляє у систему — або вручну, або автоматично через інтеграцію з ERP. У результаті:
- на складі знають, що очікується вантаж від конкретного постачальника, з конкретним переліком товарів і кількістю;
- керівник зміни може запланувати ресурси: виділити приймальників, підготувати зону приймання, перевірити вільне місце для розміщення;
- у разі затримки система фіксує факт несвоєчасної поставки — це згодом використовується для оцінки постачальника.
Етап 3. Прибуття машини й первинна перевірка
Коли машина під'їжджає до воріт, приймальник:
- знаходить документ очікуваного приймання у системі;
- перевіряє відповідність транспортних документів очікуваному вантажу — постачальник, перевізник, кількість палет, цілісність пломб.
Якщо вже на цьому етапі видно невідповідності (наприклад, інший постачальник або інший перевізник), система дозволяє оформити подію та зупинити приймання до з'ясування.
Обробка контейнерів відправника
Контейнери відправника приймаються на зберігання
Якщо вантаж приходить у палетах відправника, які залишаються на складі як одиниці зберігання, приймальник додатково перевіряє цілісність кожної палети — упаковку, плівку, маркування, цілісність пломб. Будь-яке пошкодження фіксується одразу. Кількість палет звіряється зі списком очікуваних палет, який уже в системі.
Контейнери відправника приймаються для розміщення
Якщо вантаж приходить у палетах відправника, що йтимуть на розміщення разом із товаром, приймальник перевіряє цілісність кожної палети — пошкоджена тара або порушені пломби стають підставою зупинити приймання. Кількість палет звіряється зі списком очікуваних палет.
Контейнери відправника — лише для пошуку
Якщо контейнери відправника використовуються лише як ідентифікатор партії — наприклад, для пошуку та звірки, а не для зберігання — приймальник фіксує номери цих контейнерів. Сама тара на склад не приймається: товар із неї буде розвантажений на наступному етапі.
Контейнери відправника не використовуються
Якщо постачальник доставляє товар без палет — навалом або в транспортних коробах, що належать перевізнику — додаткових перевірок цілісності палет не виконується. Приймальник зосереджується на стандартних транспортних документах: постачальник, перевізник, кількість позицій, пломби.
Етап 4. Розвантаження та сканування
Розвантаження машини відбувається паралельно з фіксацією у системі. Сканування — і камерою, і апаратним сканером — працює лише в режимі ТЗД, тому ця частина фази виконується на терміналі (див. Приймання на ТЗД). На ТЗД приймальник:
- сканує штрихкоди палет або ящиків, що вивантажуються;
- сканує штрихкоди товарів усередині;
- вводить кількість, якщо її немає у штрихкоді (для вагових товарів кількість зчитується автоматично);
- зазначає партію, термін придатності й інші характеристики товару, якщо це вимагається політикою.
У реальному часі система:
- зіставляє відскановані позиції з очікуваннями;
- підсвічує надлишки, недостачі й товари, яких узагалі не очікувалось;
- розраховує темп приймання — це допомагає керівнику бачити навантаження на зміну.
Обробка контейнерів відправника
Контейнери відправника приймаються на зберігання
Якщо палети відправника залишаються на складі як одиниці зберігання, перед скануванням позицій усередині приймальник сканує штрихкод самої палети. Палета стає цільовим контейнером, у який система записує всі позиції з неї, і одразу реєструється на балансі складу.
Контейнери відправника приймаються для розміщення
Якщо палети відправника підуть на розміщення разом із товаром, перед скануванням позицій усередині приймальник сканує штрихкод палети. Палета реєструється на балансі та отримує позначку «йде на розміщення»; усі позиції з палети система автоматично прив'язує до неї.
Контейнери відправника — лише для пошуку
Якщо контейнери відправника використовуються лише як ідентифікатор партії, приймальник сканує номер контейнера — система зберігає його як джерело для пошуку, але сам контейнер не приймається на баланс. Позиції з нього потрапляють або у зону приймання, або у складський контейнер, залежно від вимоги до контейнера приймання.
Контейнери відправника не використовуються
Якщо постачальник не використовує контейнерів, приймальник сканує безпосередньо позиції товару. Жодних попередніх кроків зі сканування тари немає — кожна позиція потрапляє у систему як окрема позиція приймання.
Вимога до контейнера приймання
Приймання без контейнера
Якщо приймання відбувається без контейнерів, кожна відсканована позиція приписується до конкретної комірки зони приймання. Оператор вказує комірку, у яку фізично кладеться товар; контейнер як ціль не використовується.
Приймання в контейнер відправника за наявності
Якщо контейнер обирати не обов'язково, але дозволено приймати у палету відправника, оператор має два варіанти: коли палета відправника наявна та дозволена обраним процесом, позиції зберігаються в неї; якщо палети немає, позиції потрапляють напряму у комірку зони приймання. Самостійно обрати складську чи тимчасову палету в цьому режимі не можна.
Обов'язковий контейнер для приймання
Якщо приймання у контейнер обов'язкове, оператор не може записати позицію в комірку напряму — потрібно або обрати наявну палету відправника, або створити складську чи тимчасову тару й сканувати позиції у неї. Без указаного контейнера сканування не реєструється.
Оператор ідентифікує SKU — комбінацію товару, його характеристик (якщо ведуться), партії (якщо ведеться) та типу пакування — через сканування штрихкоду або вручну зі списку. Які поля обов'язкові — залежить від налаштувань товару. Як працює вибір SKU.
Кількість вводиться в полі кількості — зі штрихкоду, вручну або через калькулятор, з кнопками − і + для зміни; поруч стоїть тип упаковки. Як працює поле кількості.
Режим введення кількості
Кількість підтверджується у формі
У клієнтському застосунку приймальник найчастіше працює із формою рядка приймання: відкриває рядок із плану, вибирає SKU (якщо ще не зіставлений автоматично), вказує фактичну кількість, тип упаковки і — за потреби — партію й характеристики, після чого зберігає факт. Кожен збережений факт одразу відображається у вкладці «Приймання» з прогресом по рядку.
«+1»: швидке збереження
Режим швидкого збереження «+1» належить ТЗД-екрану, а не клієнтському застосунку: він вмикається кнопкою «+1» у хедері списку рядків на екрані приймання ТЗД і за замовчуванням вимкнений — окремого складського налаштування чи перемикача у клієнті не існує. З увімкненим режимом сканування зберігає факт одразу, без відкриття форми: кількість береться зі штрихкоду або дорівнює одиниці. Як поводиться режим — анімація на екрані, помилки, коли він виправдовується — описано у ТЗД-фазі «Реєстрація факту».
Етап 5. Контроль якості
Для тих категорій товару, де перевірка якості обов'язкова, система автоматично запускає процедуру:
- частина прийнятого товару виокремлюється у зону карантину;
- спеціаліст з якості отримує завдання на перевірку;
- результати перевірки фіксуються — товар може бути визнано придатним, частково придатним, повністю забракованим;
- у разі браку оформлюється інцидент якості з фотографіями, описом причини, рекомендованими діями (повернення постачальнику, утилізація, продаж зі знижкою).
Детальний опис контролю якості — у відповідному модулі (ще не описаний у цій документації).
Етап 6. Розв'язання розбіжностей
Розбіжності між очікуваним і фактичним вантажем — буденна частина роботи. Система допомагає швидко та документально їх вирішити:
- кожна розбіжність фіксується у акті із зазначенням товару, очікуваної та фактичної кількості, причини;
- на цій основі формується претензія до постачальника або акт про надлишок;
- історія розбіжностей накопичується в картці постачальника та використовується для його рейтингування.
Якщо рішення приймається не одразу (наприклад, треба зв'язатися з постачальником), документ приймання лишається в роботі: спірний товар не потрапляє у вільні залишки, але й не списується, поки не буде ухвалено остаточне рішення.
Розбіжність із надлишком — прийшло більше, ніж очікувалося планом — обробляється прямо у документі, якщо на ньому ввімкнено Дозволити надлишкове приймання:
Етап 7. Передача на розміщення
Коли основне приймання завершено й контроль якості пройдено, прийнятий товар готовий до переміщення у зони зберігання. У цей момент:
- система помічає прийняті позиції як такі, що очікують розміщення;
- запускається процес підбору комірок — на основі правил розміщення товару;
- товар фізично залишається у зоні приймання до моменту, коли його заберуть на розміщення.
Кожне переміщення під час розміщення сканується, тому система точно знає, де саме лежить кожна одиниця товару після прийому.
Деталі правил і виконання розміщення — у модулі «Розміщення на зберігання» (ще не описаний у цій документації).
Обробка контейнерів відправника
Контейнери відправника приймаються на зберігання
Якщо палети відправника прийнято як одиниці зберігання, на розміщення передаються готові палети. Система пропонує комірку для всієї палети, а не для окремих позицій усередині; розукомплектація палет на цьому етапі не виконується.
Контейнери відправника приймаються для розміщення
Якщо палети відправника прийнято з призначенням «йде на розміщення», на розміщення передаються ці самі палети. Система враховує характеристики тари — тип палети, ваговий клас — при пошуку оптимальної комірки.
Контейнери відправника — лише для пошуку
Якщо контейнери відправника використовувались лише як ідентифікатор партії, на розміщення передаються або окремі позиції з зони приймання, або складські контейнери, у які приймали — залежно від вимоги до контейнера приймання. Контейнер відправника на цьому етапі вже не фігурує.
Контейнери відправника не використовуються
Якщо контейнери відправника не використовуються, на розміщення передаються або позиції безпосередньо із зони приймання, або складські контейнери — залежно від вимоги до контейнера приймання. Передача оформлюється на рівні позицій, не палет.
Етап 8. Закриття документа приймання
Коли всі позиції оброблено, приймальник або керівник зміни закриває документ приймання. У цей момент:
- залишки на складі офіційно збільшуються на прийняту кількість;
- товар стає доступним для продажу й відбору під замовлення;
- автоматично формується пакет документів — акт приймання, акт розбіжностей (якщо є), претензії якості (якщо є);
- ERP-система отримує оновлені дані через інтеграцію;
- постачальник може бути сповіщений про підтвердження поставки.
Що отримує бізнес від цього процесу
- Швидкість і прозорість. Усі вісім етапів зведено у єдиний інтерфейс; керівник зміни бачить прогрес у реальному часі.
- Контроль якості з самого початку. Бракований товар не потрапляє у залишки, а виявлені проблеми фіксуються документально.
- Об'єктивна картина по постачальниках. Дані про своєчасність, повноту й якість поставок накопичуються у розрізі постачальника.
- Гнучкість сценаріїв. Один і той самий процес обслуговує і планові поставки за заявкою, і позапланові без неї — без перемикання режимів.