АПИ Заказов

    Вопросы из карточки 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 выставляющий счет (Ид счета, модель счета, модель описывающую что получилось и почему или еще что-то)?" - еще как вариант ИД счета + сам счет. выставил + сразу получил, что выставил

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

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

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

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