АПИ Заказов

Вопросы из карточки https://yt.skbkontur.ru/issue/BO-68

Что должен возвращать метод API выставляющий счет (Ид счета, модель счета, модель описывающую что получилось и почему или еще что-то)?
Можно отдавать идентификатор счета, по которому из Калькулятора Цен можно достать подробности расчета цены; из Заказов по нему можно достать состояние и состав заказа (покупки), включая товары/получателей/плательщика; из Документов - документы по этому счету; из Платежей платежи по нему. Мнение Миши Федченко: https://developer.paypal.com/docs/api/invoicing/v2/ они при создании инвойса возвращают целиком результат, чтобы их лишний раз не дергали за метод получения инфы по существующим инвойсам.

С какой абстракцией должен работать API выставления счета (Плательщик, Абонент, Лицевой счет или что-то еще)? Сегодня обсудили этот вопрос - договорились до Абонента (как в плательщике, так и в получателе). При этом надо дать возможность по реквизитам однозначно определить Абонента (даже если реквизиты изменились).

С какими скидками должен работать API выставления счета (позиционные + всякие ручные акции)?
В скидках у нас поддерживаются позиционные скидки (проценты/рубли); ручные акции надо, чтобы характеризовались параметром вкл/выкл

Хотим ли мы поддержать кастомное выставление счета в основном методе или мы хотим сделать для этого отдельный метод?
Надо прорабатывать

Должны ли в API просочиться постоплатные, промо счета?
Постоплата - кажется это частный случай кастомного счета (указывается товар-цена-объём)

Хотим ли мы поддерживать дальше платформу?
Мы хотим однозначно по API-key источника вызова определять кто выставил счёт

Нужно ли сохранять контекст продажи - API Key, Менеджер, СЦ или еще что-то?
Если развиваться в сторону отдельного сервиса Biller, то нужно

Как работать с ценовой зоной определять автоматически или ожидать в API?
Предложил три формата: передавать на всю покупку, на каждую позицию, уйти в сторону правильного приготовления скидок

Дистрибуция, дистрибуция в разрезе менеджеров и партнеров уедет в партнерку или API CRM? Дистрибуцию надо максимально отделить от Заказов и сделать входной точкой для канала продаж Партнёрка. Тогда туда уйдут настройки размера скидок партнера/менеджера.

Откуда клиентам API брать PackageId?
Продуктовый каталог может возвращать сразу данные о том, что куда докупается; возможно существует метод получения "портрета" пользователя, по которому эту информацию можно понять, но тогда надо отойти в сторону от OrderPackageId.

"Что должен возвращать метод API выставляющий счет (Ид счета, модель счета, модель описывающую что получилось и почему или еще что-то)?" - еще как вариант ИД счета + сам счет. выставил + сразу получил, что выставил

"Дистрибуцию надо максимально отделить от Заказов и сделать входной точкой для канала продаж Партнёрка. Тогда туда уйдут настройки размера скидок партнера/менеджера." для канала продаж*- для любого, не только партнерки

У меня нет пруфа, что окружающие тоже думают в терминах СЦ. Может быть там будет магазин/пользователь или ещё какие-нибудь кривоногие абстракции. И тут вопрос - мы хотим сделать универсальную дистрибуцию, которая параметризуется и не работает с понятиями партнер/менеджер или предложим сделать дистрибуцию каналам продаж?

Про сам счет - не согласен, потому что непонятно будет кто и что понимает под счетом и какие данные ему нужны. Лучше пусть каждый подпродукт даст возможность узнать по идентификатору счета максимум информации, которая у них есть и даст эти методы наружу. Главное, чтобы они работали моментально. Получил идентификатор - сразу дернул методы. Есть способ, к которому все готовы - возможность лонгполлинга или реально сделать нормальную ленту новостей

допускаю, что у каждого канала будет своя дистрибуция. которую может и сам делать будет. но это прям гипотезы на какое-то будущее