Завдання
Щоб завести новий товар в обліковій системі BAS, виробнику потрібні дані від п'яти відділів: продакт-менеджменту, e-commerce, якості, експедиції та бухгалтерії. Після цього картку має погодити фінансовий директор, і лише тоді бухгалтерія вносить товар у BAS.
Раніше все трималось на шаблоні Excel. Файл пересилали між людьми, і через це виникали знайомі проблеми:
- незрозуміло, хто вже заповнив свою частину, а хто ні;
- один відділ міг випадково змінити дані іншого;
- частина полів потрібна лише за певних умов, але шаблон цього не враховував;
- погодження й повернення на доопрацювання губились у листуванні;
- бухгалтерії доводилось вручну переносити дані в технічний формат BAS.
Окрема складність - довідники. У 1С 168 категорій на чотирьох рівнях вкладеності і десятки значень довідників, а технічний аркуш для імпорту в BAS має 65 колонок. Помилка в будь-якій з них означає ручне виправлення вже в обліковій системі.
Клієнту потрібен був зрозумілий процес з чіткою відповідальністю кожного відділу і з результатом, який можна одразу завантажити в BAS.
Що ми зробили
Ми розробили сервіс за 6 днів (18 комітів, 16-21 вересня 2026) на Next.js 16, React 19, Tailwind CSS v4 і Supabase з розгортанням на Vercel.
Як працює процес
- Ініціатор створює заявку на новий товар.
- П'ять відділів паралельно заповнюють свої розділи: продакт, e-commerce, якість, експедиція і бухгалтерія.
- Фінансовий директор погоджує картку або повертає її на доопрацювання з коментарем.
- Бухгалтерія заводить товар у BAS і фіксує присвоєний код у сервісі.
Що всередині
- 9 екранів і 11 таблиць у базі даних;
- 168 категорій 1С на 4 рівнях і 72 значення довідників, з яких користувач обирає, а не вводить вручну;
- технічний аркуш BAS на 65 колонок вивантажується однією кнопкою.
Захист і логіка полів
Заборона редагувати чужий розділ реалізована на рівні бази даних через RLS, а не лише в інтерфейсі. Навіть якщо хтось спробує обійти екран, база не дасть змінити дані іншого відділу.
Видимість і обов'язковість полів залежать від відповідей інших відділів: якщо одна відповідь робить поле непотрібним, воно зникає, а якщо робить обов'язковим, без нього картку не відправити далі.
Сповіщення приходять у той канал, який обрав користувач: email, Telegram або Bitrix24.
Результат
Шаблон Excel замінив веб-сервіс із чітким маршрутом картки товару. Кожен відділ бачить свою частину роботи, фінансовий директор погоджує в одному місці, а бухгалтерія отримує готовий файл для BAS замість ручного перенесення 65 колонок.
Що змінилось:
- видно статус кожної картки і кожного розділу;
- відділи працюють паралельно, а не по черзі;
- дані з довідників обираються зі списку, тому менше розбіжностей з 1С;
- повернення на доопрацювання фіксуються в системі, а не губляться в листуванні;
- кожен отримує сповіщення там, де йому зручно.
Ми не вимірювали економію часу в цифрах, тому не наводимо її. Факти проєкту такі: 6 днів розробки, 9 екранів, 11 таблиць і повне покриття довідників 1С, потрібних для заведення товару.
Чим проєкт особливий
Подібні задачі часто вирішують таблицею зі спільним доступом або загальною формою. Проблема в тому, що таблиця не захищає розділи один від одного і не знає, які поля потрібні в конкретній ситуації. Тут правила процесу закладені в саму базу даних: відділ фізично не може змінити чужий розділ, а набір полів підлаштовується під відповіді колег.
Другий важливий момент - результат одразу у форматі BAS. Сервіс не просто збирає дані, а видає файл, який бухгалтерія завантажує в облікову систему без перебудови.
Опубліковано: · Оновлено: