Цитата: student ➤ Цитата:
FinSoft ➤ soldUnitCount не возвращает количество проданного пива из кеги
возвращает :)
1. какова вероятность того что все предыдущие списания на текущий момент там обработаны и все корректно там списано ?
2. какова вероятность того что на паре соседних касс (или магазинов сетки) толпа пионеров не покупает одно и тоже в количестве не превышающем разрешенное количество на одной кассе ?
Это все конечно так, но, собственный SQL сервер тоже может "заглючить", что-то из продаж не попало, или еще что-то... Я конечно понимаю, что в крупных магазинах для этого есть "специально-обученный" сотрудник, который следит за этим... Но, разливное пиво, это как правило мелкие "разливайки", с одной, ну максимум двумя кассами. Естественно, они себе не смогут позволить держать в штате админа, или его уровень будет таким, что лучше бы его не было совсем
Поэтому, полностью скидывать со счетов тот механизм, который предлагает ЦРПТ - ИМХО не стоит...
Запрос проверки марки у нас и так есть, параметры "innerUnitCount" и "soldUnitCount" возвращаются по любому, количество, которое хотим продать, тоже известно, ничего для этого специально делать не нужно...
Поэтому, сделать проверку на "КоличествоВЧеке <= (innerUnitCount - soldUnitCount)" по любому не помешает, даже при наличии собственного сервера. И если это условие не выполняется, блокировать продажу с выдачей месаги, типа того, что "Кег закончился. В нем осталось 1.5 литра, Вы пытаетесь продать 2.0 литра. Подключите следующий кег."
Даже если это реально не так(объява в советских пивнушках - "Тредуйте долива пива после отстоя пены!
))"), то все равно, в данном случае учет в ЦРПТ для конечного продавца более приоритетен, чем свой внутренний. Бить то в случае чего, будут не по паспорту, а по роже