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

Атестаційні завдання K2 ERP/Надходження товарів: відмінності між версіями

Матеріал з K2 ERP Wiki
Перенос з Гугл документа
 
Немає опису редагування
 
Рядок 1: Рядок 1:
'''Атестаційне завдання K2 Cloud ERP — Надходження товарів''' — практична задача для розробника K2 Cloud ERP, що передбачає створення веб-модуля обліку надходження товарів на склад з управлінням партіями.
{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Надходження товарів}}
 
'''Атестаційне завдання K2 ERP — Надходження товарів''' — це практична задача для перевірки навичок розробника або впроваджувача [[K2 ERP]] у частині складського обліку, документів надходження, партій товарів, друкованих форм і звітності.
 
У межах завдання потрібно розробити або налаштувати модуль обліку надходження товарів на склад. Модуль має працювати як повноцінна частина ERP-системи: з довідниками, журналом документів, табличною частиною, проведенням, рухами, партіями, друком і звітами.
 
<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Коротко.''' Завдання перевіряє, чи вміє спеціаліст реалізувати типовий складський бізнес-процес: постачальник привозить товар, користувач створює документ надходження, система формує партії, збільшує залишки на складі, друкує накладну та показує рух товарів у звіті.
</div>
 
__TOC__
 
== Назва завдання ==


== Назва ==
'''Модуль обліку надходження товарів на склад з управлінням партіями'''.
'''Модуль обліку надходження товарів на склад з управлінням партіями'''.


== Опис задачі ==
== Мета завдання ==
Необхідно розробити веб-модуль для обліку приходу товарів на склад.


Кожен прихід реєструється у системі у вигляді документа '''«Надходження товарів»'''. Документ має містити детальну інформацію про партії товарів:
Мета завдання — перевірити здатність спеціаліста реалізувати в K2 ERP повний цикл надходження товарів на склад.


* кількість;
У результаті має бути створений модуль, який дозволяє:
* ціна закупки;
* дата виробництва;
* дата постачання.


Кожен документ повинен:
* вести довідник товарів;
* вести довідник постачальників;
* створювати документи '''«Надходження товарів»''';
* заповнювати табличну частину документа;
* автоматично розраховувати кількість, ціну, суму та ПДВ;
* формувати партії товарів;
* проводити документ;
* збільшувати залишки на складі;
* друкувати товарну накладну;
* формувати звіт руху товарів за період.


* реєструватися у журналі документів;
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
* мати можливість друкуватися у вигляді товарної накладної;
'''Головний принцип.''' Документ надходження товарів не повинен бути просто формою для введення даних. Після проведення він має створювати реальний складський рух і впливати на залишки товарів.
* відображатися у звіті руху товарів.
</div>


Модуль повинен працювати без перезавантаження сторінки — через AJAX, з можливістю:
== Бізнес-сценарій ==


* пошуку товарів та постачальників у довідниках;
Постачальник привозить товар на склад. Користувач відкриває в K2 ERP документ '''«Надходження товарів»''', обирає постачальника, додає товари в табличну частину, вказує кількість, ціну закупки та, за потреби, дату виробництва або термін придатності.
* автоматичного розрахунку сум;
* формування підсумків по кількості та сумі у таблиці.


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


=== 1. Створити довідники ===
== Основні об’єкти модуля ==
Потрібно створити такі довідники:


==== Товари ====
{| class="wikitable" style="width:100%;"
Довідник товарів має містити поля:
! Об’єкт
! Призначення
|-
| Довідник товарів
| Зберігає інформацію про номенклатуру, одиниці виміру, виробників і стандартні ціни закупки
|-
| Довідник постачальників
| Містить контрагентів, від яких надходять товари
|-
| Документ «Надходження товарів»
| Фіксує факт приходу товарів на склад
|-
| Таблична частина документа
| Містить перелік товарів, кількість, ціну, суму та партійні дані
|-
| Партії товарів
| Дозволяють обліковувати надходження за партіями, датами виробництва та термінами придатності
|-
| Журнал документів
| Показує список документів надходження з фільтрами, статусами й підсумками
|-
| Друкована форма
| Формує товарну накладну
|-
| Звіт руху товарів
| Показує рух надходжень за період, складом, постачальником або товаром
|}


* <code>id</code>;
== Довідник товарів ==
* код;
* назва;
* одиниця виміру;
* тип товару;
* виробник;
* стандартна ціна закупки.


==== Постачальники ====
Довідник товарів має містити номенклатуру, яка використовується в документах надходження.
Довідник постачальників має містити поля:


* <code>id</code>;
Мінімальний склад полів:
* код;
* назва;
* контактні дані.


==== Функціональність довідників ====
{| class="wikitable" style="width:100%;"
Довідники мають підтримувати:
! Поле
! Опис
|-
| <code>id</code>
| Унікальний ідентифікатор товару
|-
| Код
| Внутрішній код або артикул
|-
| Назва
| Назва товару
|-
| Одиниця виміру
| Штуки, кілограми, літри, метри або інша одиниця
|-
| Тип товару
| Категорія або класифікація товару
|-
| Виробник
| Виробник товару
|-
| Стандартна ціна закупки
| Ціна, яка пропонується за замовчуванням у документі
|}


* створення записів;
Довідник має підтримувати створення, редагування, видалення, пошук за назвою або кодом і вибір товару в документі через AJAX-підказки.
* редагування записів;
* видалення записів;
* пошук по назві або коду;
* вибір із довідника при заповненні документів;
* підказки через AJAX.


=== 2. Створити журнал документів «Надходження товарів» ===
== Довідник постачальників ==
Журнал документів має відображати список документів надходження товарів.


==== Колонки журналу ====
Довідник постачальників містить контрагентів, від яких підприємство отримує товари.
Таблиця журналу повинна містити такі колонки:


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


==== Функціональність журналу ====
{| class="wikitable" style="width:100%;"
Журнал документів має підтримувати:
! Поле
! Опис
|-
| <code>id</code>
| Унікальний ідентифікатор постачальника
|-
| Код
| Внутрішній код постачальника
|-
| Назва
| Назва компанії або ФОП
|-
| Контактні дані
| Телефон, email, адреса або інша контактна інформація
|}


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


==== Підсумки журналу ====
== Журнал документів «Надходження товарів» ==
За обраним періодом потрібно показувати:


* загальну кількість товарів;
Журнал документів показує список усіх документів надходження товарів.
* загальну суму надходжень.


=== 3. Створити форму введення документа «Надходження товарів» ===
У журналі потрібно бачити основну інформацію по кожному документу: номер, дату, постачальника, кількість позицій, суму та статус.
Форма документа складається із заголовка документа та табличної частини.


==== Заголовок документа ====
{| class="wikitable" style="width:100%;"
Заголовок документа повинен містити:
! Колонка
! Опис
|-
| Номер документа
| Унікальний номер надходження
|-
| Дата
| Дата створення або проведення документа
|-
| Постачальник
| Контрагент, від якого надійшли товари
|-
| Кількість товарних позицій
| Кількість рядків у табличній частині
|-
| Загальна сума
| Сума документа
|-
| Статус
| Чернетка, проведений або анульований
|}


* номер документа — автоматична генерація при збереженні;
=== Статуси документа ===
* дата документа — за замовченням поточна дата;
* постачальник — пошук у довіднику через AJAX.


==== Таблична частина ====
{| class="wikitable" style="width:100%;"
Таблична частина має бути багаторядковою формою та містити такі поля:
! Статус
! Значення
|-
| Чернетка
| Документ збережено, але він ще не впливає на залишки
|-
| Проведений
| Документ сформував рух товарів і збільшив залишки на складі
|-
| Анульований
| Документ скасовано або виключено з обліку
|}
 
=== Фільтри журналу ===
 
Журнал має підтримувати фільтрацію за датами, постачальником, статусом і пошук за номером документа.
 
За обраним періодом потрібно показувати підсумки: загальну кількість товарів і загальну суму надходжень.
 
== Форма документа «Надходження товарів» ==
 
Форма документа складається із заголовка та табличної частини.
 
=== Заголовок документа ===
 
У заголовку документа потрібно передбачити:
 
{| class="wikitable" style="width:100%;"
! Поле
! Опис
|-
| Номер документа
| Генерується автоматично при збереженні
|-
| Дата документа
| За замовченням поточна дата
|-
| Постачальник
| Обирається з довідника через AJAX-пошук
|-
| Склад
| Склад, на який надходить товар
|-
| Статус
| Чернетка, проведений або анульований
|-
| Коментар
| Додаткова інформація до документа
|}
 
=== Таблична частина ===
 
Таблична частина документа має бути багаторядковою. Користувач повинен мати змогу додавати кілька товарів в один документ.
 
Мінімальний склад колонок:
 
{| class="wikitable" style="width:100%;"
! Колонка
! Опис
|-
| Товар
| Обирається з довідника через AJAX-пошук
|-
| Одиниця виміру
| Підтягується автоматично з картки товару
|-
| Кількість
| Вводиться користувачем
|-
| Ціна закупки
| Пропонується автоматично, але може бути змінена вручну
|-
| Сума
| Розраховується автоматично за формулою <code>кількість × ціна закупки</code>
|-
| Номер партії
| Генерується автоматично або задається системою за правилом
|-
| Дата виробництва
| Опціональне поле
|-
| Термін придатності
| Опціональне поле
|}


* товар — пошук у довіднику через AJAX;
== Партії товарів ==
* одиниця виміру — підтягується автоматично;
* кількість — ручне введення;
* ціна закупки — автоматично пропонується, але може бути змінена вручну;
* сума — розраховується автоматично за формулою <code>кількість × ціна закупки</code>.


==== Приховані або бекенд-розрахунки для товару ====
Для кожного рядка документа потрібно передбачити партійний облік.
Для кожного товару необхідно передбачити:


* номер партії — автоматичне генерування на основі дати постачання та коду товару;
Номер партії може формуватися автоматично на основі дати постачання та коду товару.
* дата виробництва — опціонально;
* термін придатності — опціонально.


=== 4. Реалізувати збереження та проведення документа ===
Приклад логіки:
Потрібно реалізувати:
 
<pre>
Партія = дата постачання + код товару
</pre>
 
Партійний облік потрібен для товарів, де важливо контролювати дату виробництва, термін придатності, серію, постачальника або конкретне надходження.
 
<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Важливо.''' Якщо товар обліковується партіями, залишки мають зберігатися не лише по товару загалом, а й по конкретній партії.
</div>
 
== Збереження документа ==
 
Збереження документа має виконуватися без повного перезавантаження сторінки.
 
Потрібно реалізувати AJAX-збереження, щоб користувач міг працювати з документом у сучасному web-інтерфейсі.
 
Після збереження документ може залишатися в статусі '''«Чернетка»''' і ще не впливати на складські залишки.
 
== Проведення документа ==
 
Проведення документа переводить його у статус '''«Проведений»'''.
 
Після проведення система повинна:
 
* зарахувати товар на склад;
* сформувати складські рухи;
* зафіксувати партії товарів;
* оновити залишки;
* зберегти інформацію про користувача, який провів документ;
* заборонити неконтрольоване редагування проведеного документа.
 
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Критично.''' Проведений документ має впливати на залишки. Якщо документ має статус “проведений”, але не створює рухів по складу, задача виконана неправильно.
</div>
 
== Розрахунки в документі ==
 
У документі потрібно реалізувати автоматичні розрахунки.
 
=== Розрахунки в табличній частині ===
 
Для кожного рядка:


* збереження документа без перезавантаження сторінки — через AJAX;
<pre>
* проведення документа;
Сума = Кількість × Ціна закупки
* переведення статусу документа у '''«Проведений»''';
</pre>
* зарахування товару на склад після проведення документа.


=== 5. Розрахунки ===
=== Підсумки документа ===


==== Розрахунки після збереження документа ====
Після збереження або зміни рядків потрібно розрахувати:
Після збереження документа потрібно:


* розрахувати підсумкову кількість товарів;
{| class="wikitable" style="width:100%;"
* розрахувати загальну суму документа;
! Показник
* розрахувати окремо ПДВ 20%.
! Опис
|-
| Підсумкова кількість
| Загальна кількість товарів у документі
|-
| Загальна сума
| Сума всіх рядків документа
|-
| ПДВ 20%
| Окремий розрахунок суми ПДВ
|}


==== Розрахунки у списку документів ====
Приклад формули ПДВ, якщо сума вказана без ПДВ:
При виведенні списку документів потрібно підраховувати:


* загальну кількість товарних позицій за вибраний період;
<pre>
* загальну суму за вибраний період.
ПДВ = Сума × 20 / 100
</pre>


=== 6. Друк документів ===
Якщо сума вже включає ПДВ, формула має бути іншою і повинна бути описана в налаштуваннях модуля.
Потрібно створити шаблон друку '''«Товарна накладна»'''.


==== Дані для друку ====
== Друк документа ==
У друкованій формі потрібно виводити:


* шапку документа:
Потрібно створити друковану форму '''«Товарна накладна»'''.
** постачальник;
 
** дата;
Друкована форма може бути реалізована у форматі HTML або PDF. Для формування друкованих форм можна використовувати Stimulsoft або внутрішні механізми друку K2.
** номер;
 
* табличну частину:
У друкованій формі потрібно показати:
** товари;
 
** одиниці виміру;
{| class="wikitable" style="width:100%;"
** кількість;
! Блок
** ціна;
! Дані
** сума;
|-
* підсумки:
| Шапка документа
** загальна сума;
| Постачальник, дата, номер документа, склад
** сума ПДВ.
|-
| Таблична частина
| Товари, одиниці виміру, кількість, ціна, сума
|-
| Підсумки
| Загальна кількість, загальна сума, сума ПДВ
|}


Шаблон може бути реалізований у форматі HTML/PDF і використовувати Stimulsoft або внутрішні механізми друку K2.
== Звіт «Рух товарів за період» ==


=== 7. Звіт «Рух товарів за період» ===
Потрібно реалізувати звіт '''«Рух товарів за період»'''.
Потрібно реалізувати звіт '''«Рух товарів за період»'''.


==== Дані звіту ====
Звіт має показувати, які товари надходили на склад за вибраний період.
У звіті потрібно показати:


* товари;
Мінімальні дані звіту:
* кількість надходжень;
* загальну суму закупок.


==== Фільтри звіту ====
{| class="wikitable" style="width:100%;"
Звіт має підтримувати фільтрацію:
! Поле
! Опис
|-
| Товар
| Назва товару
|-
| Кількість надходжень
| Скільки товару надійшло
|-
| Загальна сума закупок
| Сума надходжень по товару
|-
| Постачальник
| Контрагент, від якого надійшов товар
|-
| Склад
| Склад, на який товар був зарахований
|-
| Партія
| Партія товару, якщо використовується партійний облік
|}


* по складу;
Звіт має підтримувати фільтрацію по складу, постачальнику та товару. У звіті потрібно формувати підсумки по кількості та сумі.
* по постачальнику;
* по товару.


==== Підсумки звіту ====
== Вимоги до frontend ==
У звіті потрібно формувати підсумки по всіх стовпцях.


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


==== Фронтенд ====
Потрібно передбачити:
Фронтенд має відповідати таким вимогам:


* використання AJAX без повного перезавантаження сторінок;
* AJAX-збереження документа;
* пошук товарів і постачальників через підказки;
* автоматичне підтягування одиниці виміру та ціни;
* автоматичний розрахунок сум;
* таблиці з сортуванням і фільтрацією;
* таблиці з сортуванням і фільтрацією;
* можна використовувати DataTables або власну реалізацію.
* підсумки по кількості та сумі;
* зрозумілу роботу зі статусами документа.


==== Бекенд ====
Можна використовувати DataTables, власну реалізацію або стандартні компоненти K2.
Бекенд має відповідати таким вимогам:


* робота з базою даних через ORM або SQL;
== Вимоги до backend ==
* чітке розмежування обробки чернеток і проведених документів;
 
* логування змін документів:
Backend має відповідати логіці ERP-документів.
** хто створив документ;
 
** хто провів документ.
Потрібно реалізувати:
 
* роботу з базою даних через ORM або SQL;
* збереження чернеток;
* проведення документів;
* формування рухів по складу;
* формування або збереження партій;
* розрахунок підсумків;
* логування змін;
* контроль статусів документа.
 
Логування має фіксувати, хто створив документ, хто змінив документ і хто провів документ.


== Технічні вимоги ==
== Технічні вимоги ==


* PHP 8+ або Python для бекенду K2;
{| class="wikitable" style="width:100%;"
* MySQL або PostgreSQL;
! Напрям
* власний або стандартний MVC-фреймворк K2;
! Вимоги
* HTML5;
|-
* JavaScript;
| Backend
* jQuery або Fetch API/Axios для AJAX.
| PHP 8+ або Python для K2
|-
| База даних
| MySQL або PostgreSQL
|-
| Архітектура
| Власний або стандартний MVC-фреймворк K2
|-
| Frontend
| HTML5, JavaScript
|-
| AJAX
| jQuery, Fetch API або Axios
|-
| Таблиці
| DataTables, K2 Grid або інший табличний компонент
|-
| Друк
| HTML/PDF, Stimulsoft або внутрішній механізм K2
|}
 
== Практичне завдання ==
 
У межах атестації спеціаліст має продемонструвати робочий сценарій.
 
Мінімальний сценарій:
 
# створити кілька товарів;
# створити постачальника;
# створити документ '''«Надходження товарів»''';
# додати в документ кілька товарів;
# перевірити автоматичне підтягування одиниці виміру та ціни;
# змінити кількість і ціну;
# перевірити розрахунок суми;
# зберегти документ як чернетку;
# провести документ;
# перевірити, що товар зараховано на склад;
# перевірити створення партій;
# відкрити документ у журналі;
# надрукувати товарну накладну;
# сформувати звіт руху товарів за період.
 
== Критерії оцінювання ==


== Критерії оцінки ==
{| class="wikitable" style="width:100%;"
{| class="wikitable"
! Критерій
!Критерій
! Бали
!Бали
! Що перевіряється
|-
|-
|Правильність структури БД
| Правильність структури бази даних
|10
| 10
| Таблиці, зв’язки, документи, рядки документа, товари, постачальники, партії
|-
|-
|Реалізація довідників з пошуком і вибором
| Реалізація довідників
|10
| 10
| Створення, редагування, видалення, пошук і вибір товарів та постачальників
|-
|-
|Журнал документів і підсумки
| Журнал документів і підсумки
|15
| 15
| Список документів, фільтри, статуси, підсумки за період
|-
|-
|Форма документа з AJAX-збереженням
| Форма документа з AJAX-збереженням
|20
| 20
| Заголовок, таблична частина, підказки, збереження без перезавантаження
|-
|-
|Проведення документа і розрахунок партій
| Проведення документа і партії
|15
| 15
| Зміна статусу, формування рухів, зарахування на склад, створення партій
|-
|-
|Шаблон друку документа
| Друкована форма
|10
| 10
| Товарна накладна з шапкою, рядками, сумами та ПДВ
|-
|-
|Формування звітів і підсумків
| Звіт руху товарів
|10
| 10
| Фільтри, підсумки, дані по товарах, постачальниках і складах
|-
|-
|Загальна якість коду: читабельність, безпека
| Якість коду
|10
| 10
| Читабельність, безпека, логування, підтримуваність
|-
|-
!Разом
! Разом
!100
! 100
! Максимальна оцінка
|}
|}
== Шкала оцінювання ==
{| class="wikitable" style="width:100%;"
! Бали
! Рівень
! Опис
|-
| 90–100
| Відмінно
| Модуль працює повністю, логіка документів і партій реалізована коректно, код придатний для підтримки
|-
| 75–89
| Добре
| Основна логіка реалізована, є незначні недоліки, які не ламають бізнес-процес
|-
| 60–74
| Зараховано
| Базовий сценарій працює, але є помилки або неповна реалізація окремих частин
|-
| 0–59
| Не зараховано
| Модуль не забезпечує повний процес надходження або має критичні помилки
|}
== Критичні помилки ==
Критичними помилками вважаються ситуації, коли:
* проведений документ не збільшує залишки;
* партії не формуються або формуються неправильно;
* суми в документі розраховуються некоректно;
* документ неможливо знайти в журналі;
* проведений документ можна неконтрольовано змінити;
* друкована форма не містить основних даних;
* звіт руху товарів не відповідає проведеним документам;
* відсутнє розділення чернетки та проведеного документа.
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Умова складання.''' Завдання не може бути зараховане, якщо документ надходження не формує складський рух і не впливає на залишки товарів.
</div>


== Очікуваний результат ==
== Очікуваний результат ==
У результаті виконання атестаційного завдання має бути створений модуль K2 Cloud ERP для обліку надходження товарів на склад, який підтримує довідники товарів і постачальників, журнал документів, форму документа з табличною частиною, AJAX-збереження, проведення документа, управління партіями, друк товарної накладної та звіт руху товарів за період.
 
У результаті виконання атестаційного завдання має бути створений модуль K2 ERP для обліку надходження товарів на склад.
 
Модуль має підтримувати довідники товарів і постачальників, журнал документів, форму документа з табличною частиною, AJAX-збереження, проведення документа, управління партіями, друк товарної накладної та звіт руху товарів за період.


== Примітка ==
== Примітка ==
Це завдання імітує реальну задачу, яка виникає щодня в роботі торгових, виробничих або дистриб'юторських компаній. Воно підходить для атестації розробників, які будуть працювати з бізнес-логікою у K2 Cloud ERP.
 
Це завдання імітує реальну задачу, яка щодня виникає в торгових, виробничих або дистриб’юторських компаніях.
 
Воно підходить для атестації розробників, які працюватимуть із бізнес-логікою K2 ERP, складським обліком, документами, партіями, звітами та інтерактивним web-інтерфейсом.
 
== Коротко ==
 
{| class="wikitable" style="width:100%;"
! Питання
! Відповідь
|-
| Що потрібно розробити?
| Модуль надходження товарів на склад
|-
| Які довідники потрібні?
| Товари та постачальники
|-
| Який головний документ?
| Документ '''«Надходження товарів»'''
|-
| Що має робити проведення?
| Зараховувати товар на склад і формувати партії
|-
| Яка друкована форма потрібна?
| Товарна накладна
|-
| Який звіт потрібен?
| Рух товарів за період
|-
| Що є критичною вимогою?
| Проведений документ має впливати на залишки товарів
|}


== Див. також ==
== Див. також ==


* [[K2 Cloud ERP]]
* [[K2 Cloud ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Надходження товарів]]
* [[Надходження товарів]]
Рядок 257: Рядок 602:
* [[Управління партіями товарів]]
* [[Управління партіями товарів]]
* [[Звіт руху товарів]]
* [[Звіт руху товарів]]
* [[Товарна накладна]]
* [[Постачальник]]
* [[Номенклатура]]
[[Категорія:K2 ERP]]
[[Категорія:Атестаційні завдання K2]]
[[Категорія:Складський облік]]
[[Категорія:Надходження товарів]]
[[Категорія:WMS]]
[[Категорія:Партійний облік]]
[[Категорія:Корпоративна Wiki]]

Поточна версія на 18:09, 1 травня 2026


Атестаційне завдання 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

Практичне завдання

У межах атестації спеціаліст має продемонструвати робочий сценарій.

Мінімальний сценарій:

  1. створити кілька товарів;
  2. створити постачальника;
  3. створити документ «Надходження товарів»;
  4. додати в документ кілька товарів;
  5. перевірити автоматичне підтягування одиниці виміру та ціни;
  6. змінити кількість і ціну;
  7. перевірити розрахунок суми;
  8. зберегти документ як чернетку;
  9. провести документ;
  10. перевірити, що товар зараховано на склад;
  11. перевірити створення партій;
  12. відкрити документ у журналі;
  13. надрукувати товарну накладну;
  14. сформувати звіт руху товарів за період.

Критерії оцінювання

Критерій Бали Що перевіряється
Правильність структури бази даних 10 Таблиці, зв’язки, документи, рядки документа, товари, постачальники, партії
Реалізація довідників 10 Створення, редагування, видалення, пошук і вибір товарів та постачальників
Журнал документів і підсумки 15 Список документів, фільтри, статуси, підсумки за період
Форма документа з AJAX-збереженням 20 Заголовок, таблична частина, підказки, збереження без перезавантаження
Проведення документа і партії 15 Зміна статусу, формування рухів, зарахування на склад, створення партій
Друкована форма 10 Товарна накладна з шапкою, рядками, сумами та ПДВ
Звіт руху товарів 10 Фільтри, підсумки, дані по товарах, постачальниках і складах
Якість коду 10 Читабельність, безпека, логування, підтримуваність
Разом 100 Максимальна оцінка

Шкала оцінювання

Бали Рівень Опис
90–100 Відмінно Модуль працює повністю, логіка документів і партій реалізована коректно, код придатний для підтримки
75–89 Добре Основна логіка реалізована, є незначні недоліки, які не ламають бізнес-процес
60–74 Зараховано Базовий сценарій працює, але є помилки або неповна реалізація окремих частин
0–59 Не зараховано Модуль не забезпечує повний процес надходження або має критичні помилки

Критичні помилки

Критичними помилками вважаються ситуації, коли:

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

Умова складання. Завдання не може бути зараховане, якщо документ надходження не формує складський рух і не впливає на залишки товарів.

Очікуваний результат

У результаті виконання атестаційного завдання має бути створений модуль K2 ERP для обліку надходження товарів на склад.

Модуль має підтримувати довідники товарів і постачальників, журнал документів, форму документа з табличною частиною, AJAX-збереження, проведення документа, управління партіями, друк товарної накладної та звіт руху товарів за період.

Примітка

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

Воно підходить для атестації розробників, які працюватимуть із бізнес-логікою K2 ERP, складським обліком, документами, партіями, звітами та інтерактивним web-інтерфейсом.

Коротко

Питання Відповідь
Що потрібно розробити? Модуль надходження товарів на склад
Які довідники потрібні? Товари та постачальники
Який головний документ? Документ «Надходження товарів»
Що має робити проведення? Зараховувати товар на склад і формувати партії
Яка друкована форма потрібна? Товарна накладна
Який звіт потрібен? Рух товарів за період
Що є критичною вимогою? Проведений документ має впливати на залишки товарів

Див. також