Перейти до вмісту

Замовлення постачальникам

Матеріал з K2 ERP Wiki


SEO title: Замовлення постачальникам — закупівлі, ERP, постачальники, договори, поставки, склад, оплати і контроль виконання SEO description: Замовлення постачальникам: що це таке, для чого потрібне, як працює в ERP, зв’язок із заявками на закупівлю, договорами, постачальниками, складом, прийманням, рахунками, оплатами, бюджетом, статусами, KPI і контролем закупівель. SEO keywords: замовлення постачальникам, замовлення постачальнику, закупівлі, ERP для закупівель, постачальники, договори, поставки, приймання товарів, склад, рахунок постачальника, закупівельний процес, K2 ERP Alternative to:


Замовлення постачальникам — це документ або бізнес-об’єкт в ERP-системі, який фіксує намір компанії придбати товари, матеріали, послуги, обладнання або інші ресурси у конкретного постачальника на визначених умовах: за певною ціною, кількістю, строком поставки, договором, складом, валютою та способом оплати.

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

Головне. Замовлення постачальнику — це не просто “напишіть постачальнику, хай привезе”. Це контрольний документ, який відповідає на питання: що купуємо, у кого, скільки, за якою ціною, коли має приїхати, на який склад, за яким договором і хто за це відповідає.

Проста аналогія. Якщо заявка на закупівлю — це “нам потрібно”, то замовлення постачальнику — це “ми офіційно замовили”. Без нього закупівлі часто перетворюються на стиль управління “я комусь писав, воно мало приїхати”.

Що таке замовлення постачальникам

Замовлення постачальникам — це документ, який оформлює майбутню закупівлю у постачальника.

Він показує:

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

У ERP-системі замовлення постачальнику може бути підставою для надходження товарів, приймання послуг, рахунку постачальника, заявки на оплату, контролю бюджету та аналітики закупівель.

Для чого потрібне замовлення постачальнику

Замовлення постачальнику потрібне для:

  • формалізації закупівлі;
  • контролю потреби;
  • контролю цін;
  • контролю кількості;
  • контролю строків поставки;
  • контролю бюджету;
  • фіксації домовленостей із постачальником;
  • зв’язку закупівлі з договором;
  • планування складу;
  • планування оплат;
  • контролю виконання постачальника;
  • уникнення дублювання закупівель;
  • контролю поставок;
  • аналізу закупівель;
  • розрахунку KPI постачальників;
  • підготовки приймання товару або послуги.

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

Місце замовлення постачальнику в закупівельному процесі

Типовий закупівельний процес:

Потреба
  ↓
Заявка на закупівлю
  ↓
Погодження
  ↓
Вибір постачальника
  ↓
Замовлення постачальнику
  ↓
Підтвердження постачальника
  ↓
Поставка
  ↓
Приймання товару або послуги
  ↓
Рахунок постачальника
  ↓
Оплата
  ↓
Закриття замовлення

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

Основні реквізити замовлення постачальнику

Реквізит Що означає Приклад
Номер Унікальний номер документа ЗП-000125
Дата Дата створення замовлення 16.05.2026
Постачальник У кого купуємо ТОВ “Постачальник”
Договір Умови закупівлі Договір поставки №15
Склад Куди має приїхати товар Основний склад
Валюта Валюта закупівлі UAH, USD, EUR
Товари / послуги Що замовляємо Матеріал А, 100 шт
Кількість Скільки потрібно 100 шт
Ціна Ціна за одиницю 250 грн
Сума Загальна сума 25 000 грн
Дата поставки Очікувана дата отримання 25.05.2026
Відповідальний Хто контролює замовлення Закупівельник
Статус Поточний стан Підтверджено / Частково поставлено / Закрито

Приклад замовлення постачальнику

Поле Значення
Документ Замовлення постачальнику ЗП-000125
Дата 16.05.2026
Постачальник ТОВ “Пак-Сервіс”
Договір Договір поставки №8 від 01.03.2026
Склад Основний склад
Дата поставки 22.05.2026
Умова оплати 50% передоплата, 50% після приймання
Відповідальний Закупівельник Іваненко

Таблична частина:

Номенклатура Кількість Ціна Сума
Коробка пакувальна S 1 000 шт 12 грн 12 000 грн
Стрічка пакувальна 100 шт 45 грн 4 500 грн
Етикетка самоклейна 5 000 шт 0,80 грн 4 000 грн

Загальна сума: 20 500 грн.

Замовлення постачальнику і заявка на закупівлю

Замовлення постачальнику часто створюється на підставі заявки на закупівлю.

Заявка відповідає на питання:

Що потрібно бізнесу?
Хто просить?
Навіщо?
До якої дати?
За яким бюджетом?

Замовлення постачальнику відповідає на питання:

У кого купуємо?
За якою ціною?
У якій кількості?
Коли постачальник має поставити?
На який склад?
За яким договором?

Приклад:

Заявка: потрібно 5 ноутбуків для нових менеджерів
Погодження: керівник + фінанси
Замовлення постачальнику: 5 ноутбуків у ТОВ “ТехноПостач”, поставка до 25.05.2026

Замовлення постачальнику і договір

Замовлення має бути пов’язане з договором або умовами постачання.

Договір визначає:

  • постачальника;
  • організацію;
  • валюту;
  • умови оплати;
  • строки поставки;
  • відповідальність;
  • штрафи;
  • ціни;
  • ПДВ;
  • реквізити;
  • строк дії;
  • порядок повернення;
  • умови приймання.

ERP може контролювати:

  • чи є активний договір;
  • чи не закінчився строк дії;
  • чи не перевищена сума договору;
  • чи відповідають ціни;
  • чи правильна валюта;
  • чи можна створювати замовлення.

Погано:

Замовлення створено за договором, який завершився пів року тому.

Краще:

ERP блокує або попереджає: строк дії договору завершився.

Замовлення постачальнику і постачальник

У замовленні обов’язково вказується постачальник.

Картка постачальника має містити:

  • назву;
  • реєстраційний код;
  • податкові реквізити;
  • банківські рахунки;
  • контактних осіб;
  • email;
  • телефон;
  • умови оплати;
  • договори;
  • категорії товарів;
  • прайс-листи;
  • рейтинг;
  • історію поставок;
  • відповідального закупівельника;
  • статус активності.

Якщо постачальник створений у довіднику із помилками, замовлення також буде проблемним. ERP не чарівник. Якщо в довіднику “Постачальник 1”, “Постачальник новий” і “Постачальник точно правильний”, то це не база даних, а поле археологічних розкопок.

Статуси замовлення постачальнику

Типові статуси:

Статус Що означає
Чернетка Замовлення створено, але ще не підтверджено
На погодженні Очікує внутрішнього погодження
Погоджено Замовлення дозволено до відправлення постачальнику
Відправлено постачальнику Замовлення передано постачальнику
Підтверджено постачальником Постачальник підтвердив умови і строк
Частково поставлено Частина товарів або послуг уже отримана
Поставлено Замовлення виконано повністю
Прострочено Дата поставки минула, поставки немає або вона неповна
Скасовано Замовлення не буде виконуватися
Закрито Усі операції завершені

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

Життєвий цикл замовлення постачальнику

Повний життєвий цикл:

Створено
  ↓
Погоджено
  ↓
Надіслано постачальнику
  ↓
Підтверджено постачальником
  ↓
Очікується поставка
  ↓
Частково або повністю прийнято
  ↓
Отримано рахунок / документи
  ↓
Оплачено
  ↓
Закрито

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

Підтвердження постачальника

Після відправлення замовлення постачальник може підтвердити:

  • кількість;
  • ціну;
  • строк поставки;
  • умови оплати;
  • наявність товару;
  • часткову поставку;
  • заміну товару;
  • неможливість виконання.

Приклад:

Замовлено Підтверджено постачальником
100 шт товару А 80 шт зараз, 20 шт через тиждень
Ціна 250 грн Ціна підтверджена
Поставка 22.05.2026 Перша поставка 22.05.2026, друга 29.05.2026

ERP має зберігати підтверджені умови, а не покладатися на “десь була переписка”.

Часткове виконання замовлення

Замовлення може виконуватися частинами.

Приклад:

Товар Замовлено Прийнято Залишилось поставити
Товар А 100 60 40
Товар Б 50 50 0

ERP має показувати:

  • що вже прийнято;
  • що ще очікується;
  • що прострочено;
  • що можна закривати;
  • що потрібно дозаказати;
  • чи можна оплачувати частково.

Замовлення постачальнику і склад

Замовлення постачальнику пов’язане зі складом, бо закупівля часто завершується прийманням товару.

У замовленні вказують:

  • склад отримання;
  • очікувану дату;
  • товар;
  • кількість;
  • партії, якщо відомі;
  • серії, якщо потрібні;
  • характеристики;
  • одиниці виміру.

Склад використовує замовлення для підготовки приймання.

Приклад:

На 22.05.2026 очікується поставка 1 000 коробок на Основний склад.
Комірник бачить очікуване надходження і готує місце.

Приймання за замовленням постачальнику

Приймання товару може створюватися на підставі замовлення.

ERP порівнює:

  • що замовлено;
  • що фактично приїхало;
  • що прийнято;
  • що відхилено;
  • що пошкоджено;
  • які документи надані.

Приклад:

Замовлено: 100 шт
Фактично приїхало: 98 шт
Прийнято: 95 шт
Брак: 3 шт
Недопоставка: 2 шт

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

Розбіжності при поставці

Типові розбіжності:

  • недопоставка;
  • перепоставка;
  • брак;
  • неправильний товар;
  • неправильна ціна;
  • неправильна одиниця виміру;
  • неправильна партія;
  • прострочений товар;
  • пошкоджене пакування;
  • відсутні документи;
  • невідповідність серійних номерів.

ERP має дозволяти фіксувати розбіжності і передавати їх у роботу:

  • закупівельнику;
  • складу;
  • фінансисту;
  • бухгалтерії;
  • відповідальному менеджеру;
  • постачальнику.

Замовлення постачальнику і рахунок постачальника

Рахунок постачальника має звірятися із замовленням.

Потрібно перевірити:

  • постачальника;
  • договір;
  • суму;
  • валюту;
  • кількість;
  • ціну;
  • ПДВ;
  • строк оплати;
  • відповідність замовленню;
  • відповідність прийманню.

Приклад правила:

Якщо рахунок більший за суму замовлення більше ніж на 5%, потрібне додаткове погодження.

Триступеневий контроль: замовлення, приймання, рахунок

У закупівлях часто використовують 3-way matching.

Замовлення постачальнику
      ↓
Фактичне приймання
      ↓
Рахунок постачальника

ERP має перевірити:

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

Приклад:

Контроль Замовлення Приймання Рахунок Результат
Кількість 100 шт 100 шт 100 шт OK
Ціна 250 грн 250 грн OK
Сума 25 000 грн 25 000 грн Можна оплачувати

Якщо рахунок на 120 шт, а прийнято 100 шт, ERP має підняти прапор. Не білий, а червоний.

Замовлення постачальнику і оплата

Оплата може бути пов’язана із замовленням.

Варіанти оплати:

  • передоплата;
  • часткова передоплата;
  • оплата після поставки;
  • оплата після приймання;
  • оплата після отримання документів;
  • оплата за графіком;
  • відстрочка платежу;
  • оплата частинами.

Приклад:

Замовлення: 100 000 грн
Передоплата: 30 000 грн
Після приймання: 70 000 грн

ERP має показувати:

  • скільки оплачено;
  • скільки залишилось;
  • чи є аванс;
  • чи є прострочена оплата;
  • чи поставка відповідає оплаті;
  • чи можна платити залишок.

Замовлення постачальнику і бюджет

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

Бюджетний контроль може бути:

  • по підрозділу;
  • по проєкту;
  • по статті витрат;
  • по складу;
  • по категорії закупівлі;
  • по договору;
  • по організації;
  • по місяцю.

Приклад:

Стаття бюджету Бюджет Уже замовлено Нове замовлення Залишок після замовлення
Пакування 200 000 120 000 50 000 30 000

Якщо бюджет перевищено, ERP може:

  • попередити;
  • заборонити;
  • відправити на додаткове погодження;
  • дозволити з коментарем;
  • створити запит на зміну бюджету.

Замовлення постачальнику і ціни

ERP має контролювати закупівельні ціни.

Контроль може включати:

  • останню ціну закупівлі;
  • договірну ціну;
  • середню ціну;
  • максимальну допустиму ціну;
  • відхилення від плану;
  • відхилення від бюджету;
  • історію цін постачальника;
  • ціну альтернативних постачальників.

Приклад:

Товар Остання ціна Нова ціна Відхилення Дія
Матеріал А 100 грн 108 грн +8% Дозволено
Матеріал Б 250 грн 310 грн +24% Потрібне погодження

Замовлення постачальнику і валюта

Для імпортних або валютних закупівель важливо контролювати валюту.

ERP має враховувати:

  • валюту договору;
  • валюту замовлення;
  • курс;
  • дату курсу;
  • суму в базовій валюті;
  • курсові різниці;
  • митні платежі;
  • додаткові витрати;
  • вплив на собівартість.

Приклад:

Замовлення: 10 000 EUR
Курс: 43,00 грн
Планова сума: 430 000 грн
Бюджет у гривні: 450 000 грн
Залишок бюджету: 20 000 грн

Замовлення постачальнику і імпорт

Для імпорту замовлення постачальнику може включати:

  • іноземного постачальника;
  • валюту;
  • інвойс;
  • умови поставки;
  • митницю;
  • транспорт;
  • страхування;
  • брокера;
  • мито;
  • імпортний ПДВ;
  • партії;
  • сертифікати;
  • очікувану дату прибуття;
  • номер контейнера або транспортного документа.

Імпортне замовлення без контролю — це коли товар фізично ще в порту, гроші вже пішли, документи “майже готові”, а склад питає: “То воно сьогодні буде чи в наступному житті?”

Замовлення постачальнику і собівартість

Замовлення постачальнику може впливати на майбутню собівартість товару.

У планову собівартість можуть входити:

  • ціна постачальника;
  • доставка;
  • мито;
  • брокерські послуги;
  • страхування;
  • пакування;
  • сертифікація;
  • інші додаткові витрати.

ERP може розраховувати очікувану собівартість ще до фактичного надходження.

Приклад:

Складова Сума
Товар за інвойсом 100 000 грн
Доставка 8 000 грн
Мито 5 000 грн
Брокерські послуги 2 000 грн
Планова собівартість 115 000 грн

Замовлення постачальнику і товари в дорозі

Після підтвердження замовлення товари можуть вважатися очікуваними або товарами в дорозі.

ERP може показувати:

  • що замовлено;
  • що підтверджено;
  • що вже відвантажено постачальником;
  • що в дорозі;
  • що на митниці;
  • що очікує приймання;
  • що прострочено.

Це важливо для продажів, виробництва і планування складу.

Замовлення постачальнику і виробництво

Для виробничих компаній замовлення постачальникам часто створюються на основі виробничого плану.

ERP враховує:

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

Приклад:

План виробництва: 500 виробів
Потрібно матеріалу: 1 000 кг
Залишок: 300 кг
У дорозі: 200 кг
До замовлення: 500 кг

Замовлення постачальнику і послуги

Замовлення постачальнику може використовуватися не тільки для товарів, а й для послуг.

Приклади послуг:

  • доставка;
  • ремонт;
  • оренда;
  • маркетинг;
  • юридичні послуги;
  • консалтинг;
  • прибирання;
  • охорона;
  • ІТ-підтримка;
  • сервісне обслуговування.

Для послуг важливо контролювати:

  • період;
  • обсяг;
  • суму;
  • відповідального приймальника;
  • акт наданих послуг;
  • бюджет;
  • договір;
  • оплату.

Замовлення постачальнику і основні засоби

Якщо компанія купує обладнання або основні засоби, замовлення має містити додаткові дані:

  • тип активу;
  • майбутнє місце використання;
  • відповідальну особу;
  • проєкт;
  • бюджет капітальних інвестицій;
  • гарантію;
  • серійний номер;
  • введення в експлуатацію;
  • інвентарний номер після приймання.

Приклад:

Замовлення: сервер для дата-центру
Категорія: основний засіб
Погодження: ІТ-директор + CFO + CEO
Після приймання: інвентаризація і введення в експлуатацію

Замовлення постачальнику і документообіг

До замовлення можуть бути прикріплені:

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

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

Замовлення постачальнику і первинні документи

Замовлення саме по собі не завжди є первинним документом фактичної операції. Воно фіксує намір або домовленість.

Факт операції підтверджують:

  • видаткова накладна постачальника;
  • прибуткова накладна;
  • акт наданих послуг;
  • ТТН;
  • рахунок;
  • банківська виписка;
  • податкова накладна, якщо застосовується.

Приклад:

Замовлення постачальнику: хочемо купити 100 шт
Надходження: фактично отримали 100 шт
Рахунок: постачальник виставив оплату
Банківська виписка: оплату здійснено

Замовлення постачальнику і претензії

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

Причини претензій:

  • прострочення поставки;
  • недопоставка;
  • брак;
  • неправильний товар;
  • неправильна ціна;
  • відсутні документи;
  • пошкодження;
  • порушення умов договору.

Претензія має посилатися на:

  • замовлення;
  • договір;
  • приймання;
  • розбіжність;
  • фото або акт;
  • відповідального;
  • очікуване рішення.

Контроль прострочених замовлень

ERP має показувати прострочені замовлення.

Приклад:

Замовлення Постачальник Дата поставки Днів прострочення Сума Відповідальний
ЗП-000120 ТОВ “Постачальник А” 10.05.2026 6 80 000 Іваненко
ЗП-000121 ТОВ “Постачальник Б” 12.05.2026 4 25 000 Петренко

Такі звіти потрібні не для краси. Вони потрібні, щоб не дізнаватися про зрив поставки в день, коли виробництво вже стоїть і всі дивляться на закупівельника як на головного героя трагедії.

Закриття замовлення постачальнику

Замовлення можна закрити, коли:

  • товар повністю поставлено;
  • послуга повністю надана;
  • документи отримані;
  • розбіжності закриті;
  • оплата виконана або контрольовано перенесена;
  • залишок замовлення скасовано;
  • відповідальні підтвердили завершення.

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

Скасування замовлення постачальнику

Замовлення може бути скасоване, якщо:

  • потреба зникла;
  • постачальник не може виконати;
  • ціна стала неприйнятною;
  • знайдено іншого постачальника;
  • бюджет скасовано;
  • товар більше не потрібен;
  • замовлення створене помилково.

При скасуванні бажано вказувати причину.

Приклад:

Причина скасування: постачальник не підтвердив наявність товару, закупівлю передано іншому постачальнику.

Замовлення постачальнику і права доступу

Не всі користувачі мають однакові права.

Роль Що може робити Обмеження
Ініціатор Бачить свої заявки і пов’язані замовлення Не змінює постачальника і ціни
Закупівельник Створює і редагує замовлення Не погоджує сам собі великі закупівлі
Керівник Погоджує замовлення Не змінює складське приймання
Комірник Приймає товар за замовленням Не змінює закупівельні ціни
Фінансист Контролює оплату і бюджет Не змінює фактичне приймання
Бухгалтер Перевіряє документи Не обирає постачальника

Замовлення постачальнику і audit log

Audit log має фіксувати:

  • хто створив замовлення;
  • хто змінив постачальника;
  • хто змінив ціну;
  • хто змінив кількість;
  • хто погодив;
  • хто відправив постачальнику;
  • хто змінив дату поставки;
  • хто скасував;
  • хто закрив;
  • хто прикріпив документи;
  • хто дозволив оплату.

Audit log — це коли фраза “я нічого не міняв” перевіряється за 5 секунд, а не через збори, листування і колективну медитацію.

KPI замовлень постачальникам

ERP може рахувати KPI закупівель на основі замовлень.

Показники:

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

Аналітика замовлень постачальникам

Корисні звіти:

  • відкриті замовлення;
  • прострочені замовлення;
  • частково виконані замовлення;
  • замовлення по постачальниках;
  • замовлення по категоріях;
  • замовлення по складах;
  • замовлення по бюджетах;
  • очікувані поставки;
  • товари в дорозі;
  • відхилення цін;
  • замовлення без договору;
  • замовлення без рахунку;
  • замовлення без приймання;
  • замовлення з розбіжностями.

Приклад дашборду:

Показник Значення
Відкриті замовлення 128
Прострочені замовлення 14
Сума відкритих замовлень 6 800 000 грн
Часткові поставки 22
Середня затримка 3,7 дня

Замовлення постачальникам у K2 ERP

У K2 ERP замовлення постачальникам може бути частиною наскрізного процесу закупівель.

Воно може бути пов’язане з:

  • заявкою на закупівлю;
  • погодженням;
  • постачальником;
  • договором;
  • бюджетом;
  • складом;
  • WMS;
  • прийманням;
  • рахунком постачальника;
  • заявкою на оплату;
  • платіжним календарем;
  • первинними документами;
  • Power BI;
  • audit log;
  • правами доступу;
  • API;
  • документообігом.

Перевага ERP-підходу — замовлення не живе окремо. Воно пов’язане з усім ланцюжком: від потреби до оплати і аналітики.

Приклад процесу в K2 ERP

1. Ініціатор створює заявку на закупівлю.
2. Керівник і фінанси погоджують заявку.
3. Закупівельник обирає постачальника.
4. У K2 ERP створюється замовлення постачальнику.
5. Постачальник підтверджує дату поставки.
6. Склад приймає товар.
7. ERP фіксує розбіжності, якщо вони є.
8. Рахунок постачальника звіряється із замовленням і прийманням.
9. Фінанси створюють оплату.
10. Power BI показує виконання і KPI.

Інтеграції замовлень постачальникам

Замовлення постачальникам можуть інтегруватися з:

  • сайтом постачальника;
  • EDI;
  • електронним документообігом;
  • банком;
  • WMS;
  • CRM;
  • виробничим модулем;
  • Power BI;
  • поштою;
  • API постачальника;
  • системою тендерів;
  • системою управління транспортом.

Приклад інтеграції:

ERP створює замовлення → API передає його постачальнику → постачальник підтверджує дату → ERP оновлює статус → склад бачить очікуване приймання

Приклад JSON замовлення постачальнику

{
  "external_id": "PO-2026-00125",
  "date": "2026-05-16",
  "supplier": "SUPPLIER_001",
  "contract": "CONTRACT_008",
  "warehouse": "WH_MAIN",
  "currency": "UAH",
  "expected_delivery_date": "2026-05-22",
  "payment_terms": "50% prepayment, 50% after receipt",
  "items": [
    {
      "sku": "BOX-S",
      "name": "Коробка пакувальна S",
      "quantity": 1000,
      "unit": "pcs",
      "price": 12.00
    },
    {
      "sku": "TAPE-001",
      "name": "Стрічка пакувальна",
      "quantity": 100,
      "unit": "pcs",
      "price": 45.00
    }
  ]
}

Типові помилки із замовленнями постачальникам

Помилка Причина Наслідок
Замовлення створюється без заявки Немає процесу Закупівлі йдуть повз потреби і бюджет
Не вказаний договір Поспіх або поганий довідник Немає контролю умов
Неправильний постачальник Дублікати в довіднику Помилки в оплатах і документах
Немає дати поставки Не вимагається системою Неможливо контролювати прострочення
Не контролюються ціни Немає історії або правил Переплата
Рахунок оплачують без приймання Немає 3-way matching Ризик оплати непоставленого товару
Замовлення не закриваються Немає відповідального Звіти засмічені старими документами
Немає audit log Система не фіксує зміни Невідомо, хто змінив ціну або кількість

Помилка: замовлення без дати поставки

Замовлення без дати поставки — це не план, а побажання Всесвіту.

Проблеми:

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

Краще:

Кожне замовлення постачальнику має мати очікувану дату поставки або графік поставок.

Помилка: оплата без приймання

Погана практика:

Постачальник виставив рахунок → фінанси оплатили → склад потім розбирається, що приїхало.

Краща практика:

Замовлення → приймання → звірка з рахунком → погодження оплати.

Виняток — передоплата, але вона також має бути погоджена і прив’язана до замовлення.

Помилка: замовлення живе окремо від бюджету

Якщо замовлення не перевіряє бюджет, закупівлі можуть швидко перевищити план.

Приклад:

Бюджет на пакування: 200 000 грн
Уже замовлено: 190 000 грн
Нове замовлення: 80 000 грн
ERP має попередити або відправити на додаткове погодження.

Без цього бюджет стає декоративним документом. Гарний, але беззахисний.

Помилка: не закривають старі замовлення

Старі відкриті замовлення спотворюють:

  • очікувані поставки;
  • товари в дорозі;
  • план закупівель;
  • кредиторку;
  • бюджет;
  • KPI закупівель;
  • звіти по постачальниках.

Потрібно регулярно перевіряти відкриті замовлення і закривати ті, які вже не будуть виконуватися.

Чек-лист правильного замовлення постачальнику

  1. Є постачальник.
  2. Є договір або умови поставки.
  3. Є дата замовлення.
  4. Є очікувана дата поставки.
  5. Є склад або місце отримання.
  6. Є товари або послуги.
  7. Є кількість.
  8. Є ціна.
  9. Є валюта.
  10. Є відповідальний.
  11. Є зв’язок із заявкою, якщо процес це передбачає.
  12. Є перевірка бюджету.
  13. Є статус.
  14. Є контроль підтвердження постачальника.
  15. Є зв’язок із прийманням.
  16. Є зв’язок із рахунком.
  17. Є контроль оплати.
  18. Є audit log.
  19. Є можливість закриття або скасування.

Типові питання

Що таке замовлення постачальнику?

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

Чим замовлення постачальнику відрізняється від заявки на закупівлю?

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

Чи можна оплачувати рахунок без замовлення постачальнику?

Технічно можна, якщо в компанії такий процес. Але для контрольованих закупівель краще мати зв’язок: заявка → замовлення → приймання → рахунок → оплата. Інакше складно перевірити, хто і навіщо це купував.

Навіщо потрібна дата поставки?

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

Що таке часткове виконання замовлення?

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

Що таке 3-way matching?

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

Коротко

Питання Відповідь
Що це? Документ, який фіксує закупівлю у постачальника.
Для чого? Для контролю кількості, цін, строків, договорів, бюджету, поставок і оплат.
Основні зв’язки Заявка, постачальник, договір, склад, приймання, рахунок, оплата.
Головні статуси Чернетка, погоджено, підтверджено, частково поставлено, поставлено, прострочено, закрито.
Головний контроль 3-way matching: замовлення → приймання → рахунок.
Основний ризик Оплата або приймання без звірки із замовленням.

Висновок

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

Якісне замовлення постачальнику зв’язує потребу бізнесу, бюджет, постачальника, договір, склад, приймання, рахунок, оплату й аналітику. Саме цей зв’язок відрізняє керовані закупівлі від “десь замовили, колись приїде, потім оплатимо”.

Хороше замовлення постачальнику — це коли закупівельник знає, що замовив, склад знає, що чекати, фінанси знають, за що платити, а керівник знає, чому це взагалі купили.

У сучасній ERP, зокрема в K2 ERP, замовлення постачальникам має бути частиною наскрізного процесу: від заявки і погодження до приймання, оплати, audit log, Power BI-аналітики та оцінки постачальників. Тоді закупівлі працюють не як пожежна команда, а як нормальна керована система.

Див. також

Зовнішні посилання