Структурна схема: портал Green Co і 1С

Межі

Портал: Next.js на Vercel, база і планувальник у Supabase, фото в приватному Cloudflare R2 за шлюзом у Worker сайту
Сайт-візитка приймає весь домен і передає порталу всі шляхи, крім власних
Вхід у розділи: proxy.ts перевіряє сесію і роль; адмін - це менеджер із прапорцем admin
Сервер 1С: стандартний OData, розширення прт_Портал і база BAS
Між ними: шлюз до 1С і окремий виконавець на машині з приватним доступом до 1С

Хто ходить до 1С

Сервер порталу наживо: борг, перевірка перед зміною, зміни замовлення; створення - лише при ORDERS_DISPATCH_MODE=inline
Синк-модуль: види цін, каталог, ціни, залишки, контрагенти, борг - у репліку; у режимі inline ще й добирає чергу
Окремий виконавець: доставка черги (у режимі inline - страховка), знімок історії замовлень, борг, фото
З хмари - на одну HTTPS-адресу шлюзу із заголовком X-Portal-Key; далі OData перевіряє Basic, сервіс - Bearer

Що портал тримає сам

Репліка: products, prices, stock, customers, orders_snapshot
Черга orders_outbox: queued, creating, posted, failed
Власні таблиці: order_sidecar, price_offers, portal_members, portal_settings
Маршрути /api/sync, кожен зі своїм ключем: run (планувальник), inbound (знімки), orders-outbox (claim і report черги)
Фото віддає лише сховище: маршрут /api/product-image до 1С не звертається

Пунктир - у роботі

Адаптер до сервісу /hs/portal: перемикачі ORDERS_CREATE_VIA і ORDERS_CHANGE_VIA, типово odata
Через сервіс підуть створення замовлення, додавання позиції і скасування; решта лишається на OData
Клієнт сервісу отримає кожен, хто доставляє чергу; у черги з'явиться стан rejected
У main цього ще немає: до 1С портал ходить лише через OData
Розширення вже має маршрути orders, debt, photo; push із 1С у збірку не входить