EBSH Trade: B2B-кабінет та інтеграція з BAS/1C

Публічний багатомовний сайт на Next.js пояснює послуги, містить документи та приймає звернення. Окремий кабінет на React і Vite працює з профілями компаній, договорами, фінансами та споживанням. Адміністративні екрани дають команді постачальника інструменти керування споживачами, користувачами та синхронізацією.

Backend на NestJS зберігає дані у PostgreSQL через Prisma. Фоновий worker обробляє інтеграцію з BAS/1C через OData; Redis і BullMQ використовуються для організації цієї роботи. Нижче — спрощена схема реалізованих відповідальностей, без адрес інфраструктури, клієнтських даних і секретів.

Браузер не підключається до BAS напряму. Інтеграція читає облікові дані на сервері; локальні зміни в кабінеті не означають запис назад у BAS. Це дає змогу окремо керувати доступом, імпортом і відображенням інформації.

Частина профілю компанії має локальні CRM-коригування поверх імпортованих значень. Чергова синхронізація не повинна стирати такі зміни. Для споживання, EIC-кодів і завантажених документів джерелом є сам кабінет.

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

Умовний приклад: початковий борг 100, нарахування 300 та оплата 250 дають кінцевий борг 150, якщо інших операцій немає. Це пояснення логіки періоду на навчальних числах, а не фінансові результати EBSH або його клієнтів. Деталі облікових правил потрібно погоджувати з відповідальними за BAS.

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

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

HTTP-обробник може поставити синхронізацію в чергу; worker виконує роботу з BAS окремо від відповіді інтерфейсу. Стани запусків і помилки допомагають адміністратору зрозуміти, що завершилося, а що потребує розбору.

Для імпорту використовуються стабільні ключі джерела, контрольні точки та Redis-блокування конкурентних запусків. Локальні назви й CRM-коригування не використовуються як ідентифікатор імпортованого об'єкта. Це відокремлює зміни відображення від зіставлення даних.

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

Обсяги електроенергії зберігаються у МВт·год. Дані вносять адміністратори; фільтри пов'язують їх із періодом, компанією та договором. Такий облік не слід описувати як автоматичний збір показників лічильників або імпорт споживання з BAS.

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

Матеріал підготовлено за реалізацією EBSH Trade та описом виконаних робіт. Навантаження, економія часу й комерційні результати тут не оцінюються. Екрани в кейсі платформи містять явно позначені демонстраційні дані.

• Почати з карти джерел: BAS, локальні поля та похідні показники.
• Перевірити періоди фінансів і вибір компанії на конкретних сценаріях.
• Передбачити історію синхронізації та розбір помилок.
• Показувати користувачу лише функції й дані погодженого scope.