Сервіс прт_Портал зсередини: маршрути і об'єкти BAS

Публікація: кореневий URL portal, сегмент /hs/ додає платформа
Кожен із 8 обробників починає з ПеревіритиАвторизацію (прт_ПорталОбщий): незбіг або порожній ТокенВхідний - 401 UNAUTHORIZED
Далі обробник сам вмикає привілейований режим (спільний модуль - Privileged=false); у безпечному режимі це не діє, тому його знімають
Роль прт_РольСервісів без прав на об'єкти; користувачу публікації її дають за інструкцією, на тестовій базі не перевірено

Зелена стрілка - запис. У типовій конфігурації сервіс пише лише документ ЗаказПокупателя; рухи при проведенні формує сама конфігурація
POST /orders: створення і проведення в одній транзакції; ключ ідемпотентності шукає до створення, фіксує після
items і lines: Записать(Проведение) наявного документа; закрите замовлення - 409 ORDER_CLOSED
cancel: ОтменаПроведения проведеного, далі СостояниеЗаказа = Завершен і ВариантЗавершения = Отменен

Сіра стрілка в маршрут - читання; ланцюжок: другий об'єкт знайдено через перший
POST /orders ще читає Организации, СтруктурныеЕдиницы, Валюты (GUID з прт_Налаштування). Маршрути /orders звертаються до СостоянияЗаказовПокупателей, а ті, що пишуть рядки, - і до СтавкиНДС
items і lines беруть ВидЦен з договору самого замовлення
GET /debt: тарний борг - ті самі РасчетыСПокупателями за договорами виду s1c_Тара

У збірці core сім власних об'єктів: HTTP-сервіс прт_Портал, спільний модуль прт_ПорталОбщий, роль прт_РольСервісів і чотири регістри
Сервіс C (прт_ПорталПуш, вивантаження довідників) у збірку не входить; його регістри прт_ЧергаПуш і прт_КурсориПуш створюються, але код A/B/D/E їх не чіпає
Пунктир - у роботі: клієнта сервісу, каналів ORDERS_CREATE_VIA і ORDERS_CHANGE_VIA та стану rejected у main порталу ще немає
За проєктом клієнт викликатиме три маршрути: POST /orders, .../items і .../cancel