Божидар -- Благодарим за въпроса относно "Сторниране на транзакция"
Зададен на 12-Mar-2021 15:48
Последно актуализиран на 17-Apr-2021 12:21
Вие попитахте
Здравейте,
Допустимо ли е при сторниране на транзакция да се използва подаване на отрицателно число в полето за количество "p_quantity": , а не описания от вас подход, при които се подава ID на грешната транзакция и тя на 100% се сторнира и вече не се отработва от СЕСПА при анализа.
Става дума за сценарий, в който оператор е допуснал грешка и вместо една опакова е изписал 10 в първичния документ, а реално „физически „ на насрещната страна е предоставена една опаковка.
В нашата практика описания случай се документира по следния начин:
1.Оператор Прави се разходен складов документ за 10 оп.
2.Документа автоматично се регистрира в наш специален регистър, от който на база на разработен код автоматично се докладва тази наша вътрешна транзакция към СЕСАП с "p_quantity": 10, и получаваме от вас ID на транзакцията. Маркираме в регистъра, че транзакцията е приета успешно в СЕСПА.
3.Оператора коригира грешката си с издаване на Строрниращ разходен складов документ за минус 9 оп.
4.Строрниращия документ на общо основание се регистрира във специалния регистър и очакванията ни са, че не би следвало да има проблем да се подаде към СЕСПА количеството като "p_quantity": -9,
По този начин оператора само създава първични документи и коригира грешката си.
и ние отговорихме...
Към СЕСПА не е допустимо да се подават отрицателни числа като количества.
Това решение се базира на приетия вътрешен модел на съхранение на данни и изчисляване на количества, а именно знакът да се определя от вида на транзакцията.
В този смисъл има положителни и отрицателни транзакции, и в случай на отрицателна транзакция и отрицателно количество ефектът ще е обратен вместо да намали количеството, то ще се увеличи.
Така ако допуснем подаването на отрицателни числа ще се объркат изчисленията и ще се промени логиката на работа.
Конкретно в случая на грешка начина за корекция е да се подаде транзакция за отказване на предходната, а след това да се подаде транзакция с вярното количество.
Това, което сме планирали, но още не е реализирано, е да може да се отказва транзакция и по номер на подадена ваша транзакция.
March 12, 2021
Коментирал: Божидар Халембаков from София
Здравейте,
За нас най-правилния начин е всички транзакции да позволяват отрицателно число. Още повече, имайки предвид една от основните цели на СЕСПА – анализ на потреблението, то наличието на отрицателна стойност ще доведе то правилното отчитане на реалното количеството (нетното такова) разходвано в страната за даден продукт.
Ако това обаче отрицателното количество не го позволява дизайна на СЕСПА или други съображения и би трябвало да изберем между предложените от вас два варианта, бихме избрали вариант 1.
Само да попитам. Две нови транзакции ли ще се създадат
– една за Частично сторнирането на разходна транзакция
– втора за Частично сторнирането на приходна транзакция
или ще има само една транзакция, която ще разпознавате като сторнираща и отделно в параметрите и ще се описва какъв тип транзакция се сторнира, за да може да се включва вярно в алгоритма на пресмятането на наличността в страната ?
March 12, 2021
Коментирал: б from София
И в нашата система изчисляването на количествата зависи от типа на транзакцията ( Приходен документ значи увеличаваме наличността и Разходен документ - намаляваме наличността),
но това не пречи количеството да е с отрицателна стойност.
Не разбирам вътрешния ви модел. Получавате едно количество и според вида на транзакцията то увеличава или намалява наличността.
Ако наличното ви количество е 100 оп. и получите положителна транзакция за минус 8 оп. то количеството става равно на 92 оп. (100 +(-8))
С дадения от вас отговор, по същество забранявате практиката на частично сторниране.
Followup:
Като цяло не искаме и не целим забраняване на частичното сторниране. Целта е да се направи всичко максимално лесно и удобно.
За сценарият, който описвате, позвляването на отрицателни стойности изглежда приложим и удобен.
Проблемът, който виждаме е, че може да дойде отрицателна транзакция с отрицателно количество, което тези минус осем ще ги направи плюс осем
и понеже не поддържаме наличност, а я изчисляваме динамично, не може да се предвидят последиците.
Например, ако аптека подаде продажба с отрицателна стойност, това ще е равносилно на връщане на продукти обратно в аптеката, което по принцип
не е позволено. Не ни е известно дали такива грешки се случват в аптека - да се отбележат отпуснати повече бройки и след това да се върнат
повечето, тоест да се направи частично сторниране.
Вариантите за разрешаване на частичното сторниране са:
1. Въвеждаме нова транзакция за частично сторниране, която пак приема само положителни числа, но е с отрицателен смисъл;
2. Даваме възможност на определени транзакции да се подава отрицателно число; Тук идва въпросът кои са транзакциите, на които да се разреши
отрицателната стойност - може би само на положителните и нулевите.
Бихте ли споделили Вашето мнение?
|