Выяснилось, что на релизе 32.00.14 изменился формат RequestID | POS СБС-канал
Выяснилось, что на релизе 32.00.14 изменился формат RequestID на библиотеке sbrf.dll
Уникальный идентификатор операции RequestID (31.00.18)
Уникальный идентификатор операции – это число в формате HEX-строки от 00000001 до FFFFFFFE. Кассовая программа назначает уникальный идентификатор каждому вызову функции UPOS, и гарантирует его уникальность в течение минимум двух смен.
Формат RequestID (32.00.14)
Формат RequestID: целое число размерностью 4 байта, должно быть представлено как HEX-строка длинной 8 символом ASCII.
Диапазон RequestID: от 0x00000001 до 0xFFFFFFFE.
Альтернативный формат: должно быть задано в шестнадцатеричном формате «8AEF1C21» без «0x».
Число 0xFFFFFFFF является зарезервированным и его нельзя подавать в качестве RequestID.
Число 0x00000000 является зарезервированным и его передача будет означать режим автоматической генерации RequestID.
Партнеры, которые передают зарезервированные числа (0х) не смогут работать с 32 релизом без изменения формата передачи Request.
Пример от коллег из Вкусвилл (sbkernel_32.log):
08.09 15:51:59 SBRFv90: (PID 1080, thread 0x000015B4) SParam: Amount=600
08.09 15:51:59 SBRFv90: (PID 1080, thread 0x000015B4) SParam: RequestID=0x1013F1DD
(0x явно лишний)
08.09 15:51:59 SBRFv90: (PID 1080, thread 0x000015B4) NFun: 4000
По мимо этого в релизе 32.00.14 был обнаружен баг с тем же RequestId на библиотеке sbrf.dll
Пример. Партнер Рольф передает RequestId (RequestID=-1631286658) с отрицательным значением на что получает на любую фин операцию ошибку 16 - финансовая операция с таким RequestID уже выполнена. Данная проблема была воспроизведена на нашем стенде. В релизе 32.01 проблема уже не воспроизводится.
Коллеги, необходимо уделить отдельное внимание при тестировании релиза у партнеров работающих с RequestID на библиотеке sbrf.dll
Локально описанные ситуации можно увидеть в логе sbkernel.log:
SParam: RequestID=-1630478756
SParam: RequestID=0x1013F1DD
Такие форматы работать не будут.
