search

iiko / front.api.sdk

iikoFront Api SDK (part of iikoRMS)
34 stars 22 forks source link

Получить уникальный индификатор строки продажи #258

Open pgulyaev88 opened 3 years ago

pgulyaev88 commented 3 years ago

Добрый день. Каким образом можно получить уникальный индикатор строки продажи? Кейс такой, нам необходимо сравнивать состав заказа в фискальном регистраторе с составом заказа на фронте и если заказы отличются вносить коррекции. На данный момент нет возможности корректно это делать т.к. в заказе может быть несолько одинаковых блюд, и у нас не получается привзяться за код блюда, т.к при наличии акций iikoCard и дополнительных скидок, в ChequeSale блюда могут передаваться в несколько строк. И не понятно в какую строку вносить изменения в нашем ФР.

vcpp commented 3 years ago

Я не совсем понял ваш кейс, но какая разница, в какую из одинаковых строк вы внесёте изменения? Если между одинаковыми строками нет никакой разницы, то по какому признаку одна из них может быть более правильной для внесения изменений, чем другие?

Между блюдами в заказе (IOrderRootItem, IOrderModifierItem) и строчками в чеке (ChequeSale) нет прямого соответствия. Например, при внесении предоплаты на неполную сумму будет единственный ChequeSale с названием вида «Предоплата за заказ №42». А ещё блюда могут группироваться в чеке — могут все схлопнуться, могут схлопнуться по НДС или секциям фискального регистратора. А ещё в чеке могут печататься строки, не являющиеся блюдами — комментарии, округления. А ещё другие планы могут как угодно поменять строки чека, добавить новые строки и так далее.

pgulyaev88 commented 3 years ago

Дело в том что у нас(Республика Беларусь) по законодательству учитываются все коррекции заказов в меньшую сторону(пробили 3 стейка. потом удалили 1, сумма одного стейка уходит в сумму коррекций, счётчик коррекций увеличивается на кол-во удалённых блюд), и в дальнейшем отображаются в Z-отчёте и отправляются в налоговую в реальном времени. Т.е создали заказ, например добавили 10 напитков, на часть из них применалсь акция из iikoCard, на другие применили скидку. в ChequeSale я получаю это разными строками, потом я могу разделить часть блюд на несколько позиций, и у меня может печататься как 2. так и 3,4,5 строками. Сравнивать по блюдно не очень вариант, т.к нет прямой зависимости и понимания по каким свойствам будет произведена группировка блюд в заказе, и как добавление блюд/скидок/акций может повлиять на дальнейшую группировку блюд. На данный момент я проверяю по коду и кол-ву, но когда начали тесторовать акции и скидки. то столкнулись с проблемой что иногда блюда отдаются несолькими строками, и в дальнейшем их проблематично синхронизировать с фискальным регистратором. Поэтому и появился вопрос как нам корректно синхронизировать состав заказа с фискальным регистратором.

vcpp commented 3 years ago

Верно ли я понимаю, вы хотите, чтобы у ChequeSale было поле типа Guid со значением из IOrderRootItem.Id или IOrderModifierItem.Id?

Для РБ есть плагин Resto.Front.Api.OrderDiffUploader, он отслеживает, агрегирует и отправляет изменения в заказе. Вы хотите дополнить логику этого плагина? Или написать аналогичный с нуля?

Вы ещё не смотрели инструкцию по использованию данного плагина или пример разработки фискальника для РБ?

pgulyaev88 commented 3 years ago

Верно ли я понимаю, вы хотите, чтобы у ChequeSale было поле типа Guid со значением из IOrderRootItem.Id или IOrderModifierItem.Id

Да что то на подобии такого, что бы можно было к чему то привязаться в идеале что бы при отдаче ChequeSale заказ группировался по блюдам и Гостям

Для РБ есть плагин Resto.Front.Api.OrderDiffUploader, он отслеживает, агрегирует и отправляет изменения в заказе. Вы хотите дополнить логику этого плагина? Или написать аналогичный с нуля?

Если есть возможность доработать плагин что бы он отдавал кроме события еще и позиции для коррекции это было бы отлично. Но всё равно нужно делать синхронизацию заказа перед печатью пречека и чека, поэтому нужно как то решить вопрос с тем как отдаётся заказ в ChequeSale или получать состав заказа из плагина Resto.Front.Api.OrderDiffUploader

Вы ещё не смотрели инструкцию по использованию данного плагина или пример разработки фискальника для РБ?

Да смотрел. Это наш третий плагин для ФР, просто ФР нового типа.

pgulyaev88 commented 3 years ago

Подскажите есть ли какое решение?

ierof commented 3 years ago

Для РБ есть плагин Resto.Front.Api.OrderDiffUploader, он отслеживает, агрегирует и отправляет изменения в заказе.

OrderDiffUploader сделан сильно проще того, что тут описано. Он группирует уже итоговые суммы даже не по идентифицируемым заказам, а просто как счетчик. Примерно так:

Т.е. состав заказа через этот DiffUploader не выгружается. Модифицировать этот плагин не планировали.

Что касается какой-либо идентификации в ChequeSale, то @vcpp правильно ответил выше: https://github.com/iiko/front.api.sdk/issues/258#issuecomment-905459293 Имхо, ChequeSale не самая подходящая структура данных для подобных детальных выгрузок, потому что в ней часть данных уже отброшена или сгруппирована по правилам внутренней логики iiko. Это "зеркало" заказа iiko. Поэтому если нужна такая детализация, я бы предложила работать по IOrder. Потому что даже получая ChequeTask при пробитии чека, вы по идентификатору можете получить IOrder и работать по нему. Ну и да, чтобы понять, что именно изменилось, вероятно, вам придётся на своей стороне в нужном вам виде хранить то, относительно какого предыдущего состояния вы хотите получить изменения.