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