Атестаційні завдання K2 ERP/Надходження товарів
Атестаційне завдання K2 ERP — Надходження товарів — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у частині складського обліку, документів надходження, партій товарів, друкованих форм і звітності.
У межах завдання потрібно розробити або налаштувати модуль обліку надходження товарів на склад. Модуль має працювати як повноцінна частина ERP-системи: з довідниками, журналом документів, табличною частиною, проведенням, рухами, партіями, друком і звітами.
Коротко. Завдання перевіряє, чи вміє спеціаліст реалізувати типовий складський бізнес-процес: постачальник привозить товар, користувач створює документ надходження, система формує партії, збільшує залишки на складі, друкує накладну та показує рух товарів у звіті.
Назва завдання
Модуль обліку надходження товарів на склад з управлінням партіями.
Мета завдання
Мета завдання — перевірити здатність спеціаліста реалізувати в K2 ERP повний цикл надходження товарів на склад.
У результаті має бути створений модуль, який дозволяє:
- вести довідник товарів;
- вести довідник постачальників;
- створювати документи «Надходження товарів»;
- заповнювати табличну частину документа;
- автоматично розраховувати кількість, ціну, суму та ПДВ;
- формувати партії товарів;
- проводити документ;
- збільшувати залишки на складі;
- друкувати товарну накладну;
- формувати звіт руху товарів за період.
Головний принцип. Документ надходження товарів не повинен бути просто формою для введення даних. Після проведення він має створювати реальний складський рух і впливати на залишки товарів.
Бізнес-сценарій
Постачальник привозить товар на склад. Користувач відкриває в K2 ERP документ «Надходження товарів», обирає постачальника, додає товари в табличну частину, вказує кількість, ціну закупки та, за потреби, дату виробництва або термін придатності.
Після збереження система розраховує суми, ПДВ і підсумки документа. Після проведення товар зараховується на склад, по кожній позиції формується партія, а документ стає доступним у журналі, друкованій формі та звіті руху товарів.
Основні об’єкти модуля
| Об’єкт | Призначення |
|---|---|
| Довідник товарів | Зберігає інформацію про номенклатуру, одиниці виміру, виробників і стандартні ціни закупки |
| Довідник постачальників | Містить контрагентів, від яких надходять товари |
| Документ «Надходження товарів» | Фіксує факт приходу товарів на склад |
| Таблична частина документа | Містить перелік товарів, кількість, ціну, суму та партійні дані |
| Партії товарів | Дозволяють обліковувати надходження за партіями, датами виробництва та термінами придатності |
| Журнал документів | Показує список документів надходження з фільтрами, статусами й підсумками |
| Друкована форма | Формує товарну накладну |
| Звіт руху товарів | Показує рух надходжень за період, складом, постачальником або товаром |
Довідник товарів
Довідник товарів має містити номенклатуру, яка використовується в документах надходження.
Мінімальний склад полів:
| Поле | Опис |
|---|---|
id
|
Унікальний ідентифікатор товару |
| Код | Внутрішній код або артикул |
| Назва | Назва товару |
| Одиниця виміру | Штуки, кілограми, літри, метри або інша одиниця |
| Тип товару | Категорія або класифікація товару |
| Виробник | Виробник товару |
| Стандартна ціна закупки | Ціна, яка пропонується за замовчуванням у документі |
Довідник має підтримувати створення, редагування, видалення, пошук за назвою або кодом і вибір товару в документі через AJAX-підказки.
Довідник постачальників
Довідник постачальників містить контрагентів, від яких підприємство отримує товари.
Мінімальний склад полів:
| Поле | Опис |
|---|---|
id
|
Унікальний ідентифікатор постачальника |
| Код | Внутрішній код постачальника |
| Назва | Назва компанії або ФОП |
| Контактні дані | Телефон, email, адреса або інша контактна інформація |
Постачальник має обиратися в документі з довідника. Пошук повинен працювати без повного перезавантаження сторінки.
Журнал документів «Надходження товарів»
Журнал документів показує список усіх документів надходження товарів.
У журналі потрібно бачити основну інформацію по кожному документу: номер, дату, постачальника, кількість позицій, суму та статус.
| Колонка | Опис |
|---|---|
| Номер документа | Унікальний номер надходження |
| Дата | Дата створення або проведення документа |
| Постачальник | Контрагент, від якого надійшли товари |
| Кількість товарних позицій | Кількість рядків у табличній частині |
| Загальна сума | Сума документа |
| Статус | Чернетка, проведений або анульований |
Статуси документа
| Статус | Значення |
|---|---|
| Чернетка | Документ збережено, але він ще не впливає на залишки |
| Проведений | Документ сформував рух товарів і збільшив залишки на складі |
| Анульований | Документ скасовано або виключено з обліку |
Фільтри журналу
Журнал має підтримувати фільтрацію за датами, постачальником, статусом і пошук за номером документа.
За обраним періодом потрібно показувати підсумки: загальну кількість товарів і загальну суму надходжень.
Форма документа «Надходження товарів»
Форма документа складається із заголовка та табличної частини.
Заголовок документа
У заголовку документа потрібно передбачити:
| Поле | Опис |
|---|---|
| Номер документа | Генерується автоматично при збереженні |
| Дата документа | За замовченням поточна дата |
| Постачальник | Обирається з довідника через AJAX-пошук |
| Склад | Склад, на який надходить товар |
| Статус | Чернетка, проведений або анульований |
| Коментар | Додаткова інформація до документа |
Таблична частина
Таблична частина документа має бути багаторядковою. Користувач повинен мати змогу додавати кілька товарів в один документ.
Мінімальний склад колонок:
| Колонка | Опис |
|---|---|
| Товар | Обирається з довідника через AJAX-пошук |
| Одиниця виміру | Підтягується автоматично з картки товару |
| Кількість | Вводиться користувачем |
| Ціна закупки | Пропонується автоматично, але може бути змінена вручну |
| Сума | Розраховується автоматично за формулою кількість × ціна закупки
|
| Номер партії | Генерується автоматично або задається системою за правилом |
| Дата виробництва | Опціональне поле |
| Термін придатності | Опціональне поле |
Партії товарів
Для кожного рядка документа потрібно передбачити партійний облік.
Номер партії може формуватися автоматично на основі дати постачання та коду товару.
Приклад логіки:
Партія = дата постачання + код товару
Партійний облік потрібен для товарів, де важливо контролювати дату виробництва, термін придатності, серію, постачальника або конкретне надходження.
Важливо. Якщо товар обліковується партіями, залишки мають зберігатися не лише по товару загалом, а й по конкретній партії.
Збереження документа
Збереження документа має виконуватися без повного перезавантаження сторінки.
Потрібно реалізувати AJAX-збереження, щоб користувач міг працювати з документом у сучасному web-інтерфейсі.
Після збереження документ може залишатися в статусі «Чернетка» і ще не впливати на складські залишки.
Проведення документа
Проведення документа переводить його у статус «Проведений».
Після проведення система повинна:
- зарахувати товар на склад;
- сформувати складські рухи;
- зафіксувати партії товарів;
- оновити залишки;
- зберегти інформацію про користувача, який провів документ;
- заборонити неконтрольоване редагування проведеного документа.
Критично. Проведений документ має впливати на залишки. Якщо документ має статус “проведений”, але не створює рухів по складу, задача виконана неправильно.
Розрахунки в документі
У документі потрібно реалізувати автоматичні розрахунки.
Розрахунки в табличній частині
Для кожного рядка:
Сума = Кількість × Ціна закупки
Підсумки документа
Після збереження або зміни рядків потрібно розрахувати:
| Показник | Опис |
|---|---|
| Підсумкова кількість | Загальна кількість товарів у документі |
| Загальна сума | Сума всіх рядків документа |
| ПДВ 20% | Окремий розрахунок суми ПДВ |
Приклад формули ПДВ, якщо сума вказана без ПДВ:
ПДВ = Сума × 20 / 100
Якщо сума вже включає ПДВ, формула має бути іншою і повинна бути описана в налаштуваннях модуля.
Друк документа
Потрібно створити друковану форму «Товарна накладна».
Друкована форма може бути реалізована у форматі HTML або PDF. Для формування друкованих форм можна використовувати Stimulsoft або внутрішні механізми друку K2.
У друкованій формі потрібно показати:
| Блок | Дані |
|---|---|
| Шапка документа | Постачальник, дата, номер документа, склад |
| Таблична частина | Товари, одиниці виміру, кількість, ціна, сума |
| Підсумки | Загальна кількість, загальна сума, сума ПДВ |
Звіт «Рух товарів за період»
Потрібно реалізувати звіт «Рух товарів за період».
Звіт має показувати, які товари надходили на склад за вибраний період.
Мінімальні дані звіту:
| Поле | Опис |
|---|---|
| Товар | Назва товару |
| Кількість надходжень | Скільки товару надійшло |
| Загальна сума закупок | Сума надходжень по товару |
| Постачальник | Контрагент, від якого надійшов товар |
| Склад | Склад, на який товар був зарахований |
| Партія | Партія товару, якщо використовується партійний облік |
Звіт має підтримувати фільтрацію по складу, постачальнику та товару. У звіті потрібно формувати підсумки по кількості та сумі.
Вимоги до frontend
Frontend модуля має працювати без зайвих перезавантажень сторінки.
Потрібно передбачити:
- AJAX-збереження документа;
- пошук товарів і постачальників через підказки;
- автоматичне підтягування одиниці виміру та ціни;
- автоматичний розрахунок сум;
- таблиці з сортуванням і фільтрацією;
- підсумки по кількості та сумі;
- зрозумілу роботу зі статусами документа.
Можна використовувати DataTables, власну реалізацію або стандартні компоненти K2.
Вимоги до backend
Backend має відповідати логіці ERP-документів.
Потрібно реалізувати:
- роботу з базою даних через ORM або SQL;
- збереження чернеток;
- проведення документів;
- формування рухів по складу;
- формування або збереження партій;
- розрахунок підсумків;
- логування змін;
- контроль статусів документа.
Логування має фіксувати, хто створив документ, хто змінив документ і хто провів документ.
Технічні вимоги
| Напрям | Вимоги |
|---|---|
| Backend | PHP 8+ або Python для K2 |
| База даних | MySQL або PostgreSQL |
| Архітектура | Власний або стандартний MVC-фреймворк K2 |
| Frontend | HTML5, JavaScript |
| AJAX | jQuery, Fetch API або Axios |
| Таблиці | DataTables, K2 Grid або інший табличний компонент |
| Друк | HTML/PDF, Stimulsoft або внутрішній механізм K2 |
Практичне завдання
У межах атестації спеціаліст має продемонструвати робочий сценарій.
Мінімальний сценарій:
- створити кілька товарів;
- створити постачальника;
- створити документ «Надходження товарів»;
- додати в документ кілька товарів;
- перевірити автоматичне підтягування одиниці виміру та ціни;
- змінити кількість і ціну;
- перевірити розрахунок суми;
- зберегти документ як чернетку;
- провести документ;
- перевірити, що товар зараховано на склад;
- перевірити створення партій;
- відкрити документ у журналі;
- надрукувати товарну накладну;
- сформувати звіт руху товарів за період.
Критерії оцінювання
| Критерій | Бали | Що перевіряється |
|---|---|---|
| Правильність структури бази даних | 10 | Таблиці, зв’язки, документи, рядки документа, товари, постачальники, партії |
| Реалізація довідників | 10 | Створення, редагування, видалення, пошук і вибір товарів та постачальників |
| Журнал документів і підсумки | 15 | Список документів, фільтри, статуси, підсумки за період |
| Форма документа з AJAX-збереженням | 20 | Заголовок, таблична частина, підказки, збереження без перезавантаження |
| Проведення документа і партії | 15 | Зміна статусу, формування рухів, зарахування на склад, створення партій |
| Друкована форма | 10 | Товарна накладна з шапкою, рядками, сумами та ПДВ |
| Звіт руху товарів | 10 | Фільтри, підсумки, дані по товарах, постачальниках і складах |
| Якість коду | 10 | Читабельність, безпека, логування, підтримуваність |
| Разом | 100 | Максимальна оцінка |
Шкала оцінювання
| Бали | Рівень | Опис |
|---|---|---|
| 90–100 | Відмінно | Модуль працює повністю, логіка документів і партій реалізована коректно, код придатний для підтримки |
| 75–89 | Добре | Основна логіка реалізована, є незначні недоліки, які не ламають бізнес-процес |
| 60–74 | Зараховано | Базовий сценарій працює, але є помилки або неповна реалізація окремих частин |
| 0–59 | Не зараховано | Модуль не забезпечує повний процес надходження або має критичні помилки |
Критичні помилки
Критичними помилками вважаються ситуації, коли:
- проведений документ не збільшує залишки;
- партії не формуються або формуються неправильно;
- суми в документі розраховуються некоректно;
- документ неможливо знайти в журналі;
- проведений документ можна неконтрольовано змінити;
- друкована форма не містить основних даних;
- звіт руху товарів не відповідає проведеним документам;
- відсутнє розділення чернетки та проведеного документа.
Умова складання. Завдання не може бути зараховане, якщо документ надходження не формує складський рух і не впливає на залишки товарів.
Очікуваний результат
У результаті виконання атестаційного завдання має бути створений модуль K2 ERP для обліку надходження товарів на склад.
Модуль має підтримувати довідники товарів і постачальників, журнал документів, форму документа з табличною частиною, AJAX-збереження, проведення документа, управління партіями, друк товарної накладної та звіт руху товарів за період.
Примітка
Це завдання імітує реальну задачу, яка щодня виникає в торгових, виробничих або дистриб’юторських компаніях.
Воно підходить для атестації розробників, які працюватимуть із бізнес-логікою K2 ERP, складським обліком, документами, партіями, звітами та інтерактивним web-інтерфейсом.
Коротко
| Питання | Відповідь |
|---|---|
| Що потрібно розробити? | Модуль надходження товарів на склад |
| Які довідники потрібні? | Товари та постачальники |
| Який головний документ? | Документ «Надходження товарів» |
| Що має робити проведення? | Зараховувати товар на склад і формувати партії |
| Яка друкована форма потрібна? | Товарна накладна |
| Який звіт потрібен? | Рух товарів за період |
| Що є критичною вимогою? | Проведений документ має впливати на залишки товарів |