[ТЕМА ЗАКРЫТА]
Опции темы
20.02.2013 10:28  
$piritu$
Доброго времени суток!
Делается так:
Пробили товар - сторнировали все позиции в чеке - на экране "0" - нажимаем "расчет"- выходит окно "введите сумму" - оставляем "0" - нажимаем ввод - выходит чек.
В чеке:
товаров в позиции - 0
к оплате - 0
того к оплате 0
Вопрос в том как запретить проведение нулевого чека?
 
"Спасибо" $piritu$ от:
21.02.2013 09:50  
$piritu$
есть какие ни будь предложения? Может вопрос поставил не правильно?

Добавлено через 2 минуты 25 секунд
Версия 49 sp10
 
21.02.2013 10:21  
Onesoft
Без доработки никак.
Теоретически можно попробовать реализовать это на уровне триггера БД кассы: выводить кассу в состояние ошибки при попытке записи trm_out_receipt_footer.result=0 при отсутствии товарных позиций..

Добавлено через 57 секунд
В смысле - при отсутствии нормальных товарных позиций, не аннулированных и не сторнированных..
 
21.02.2013 10:25  
Mtirt
А если попробовать отредактировать receipt.lua?
Добавить условие на сумму чека? И если она равна нулю, то чек не печатать?
 
21.02.2013 11:34  
Onesoft
Пожалуй, можно. В обоих случаях провоцируется ошибка.
Но в lua два недостатка будет:
1. На экране кассира отобразить пользовательский текст ошибки невозможно (из-за ограниченной интеграции lua с УКМ);
2. если добить товар в чек и попытаться пробить его уже с товаром, то выругается ФР, (тестировалось на СП101ФР-К) всё равно будет аннулированный чек, вслед за котором будет пробит нормально завершённый.

Вот метод lua. В функции print_receipt_footer скрипта receipt.lua вместо фрагмента:

Код:
        if __footer.result == ukm.footer.normal then
          text = text .. ukm.center("СПАСИБО ЗА ПОКУПКУ!",width," ") .. "\n" .. "\n";
          local receipt_type = __footer.receipt.header:receipt_type();
          last_receipt_is_non_fiscal = (receipt_type == ukm.header.nonfiscal) and __footer.result == ukm.footer.normal
                                       and __footer.receipt.type ~= ukm.core.copy and __footer.receipt.type ~= ukm.core.duplicate_ and __footer.receipt.type ~= ukm.core.restore_ 
                                       and __footer.receipt.type ~= ukm.core.goods_receipt;
        elseif __footer.result == ukm.footer.cancel then
Вставить фрагмент:

Код:
        if __footer.result == ukm.footer.normal then
          if __footer.receipt.subtotal.itemscount == 0 then
            ukm.debug("Чек без товарных позиций должен быть аннулирован!");
            local errr=ukm.currency("raiseerror");
          else
            text = text .. ukm.center("СПАСИБО ЗА ПОКУПКУ!",width," ") .. "\n" .. "\n";
            local receipt_type = __footer.receipt.header:receipt_type();
            last_receipt_is_non_fiscal = (receipt_type == ukm.header.nonfiscal) and __footer.result == ukm.footer.normal
                                         and __footer.receipt.type ~= ukm.core.copy and __footer.receipt.type ~= ukm.core.duplicate_ and __footer.receipt.type ~= ukm.core.restore_ 
                                         and __footer.receipt.type ~= ukm.core.goods_receipt;
          end;

        elseif __footer.result == ukm.footer.cancel then
ukm.debug позволит нам хоть по логам кассы понять, что произошло.


Вот метод триггера. Подключиться к БД ukmclient на кассе, выполнить запрос:

[ НЕЛЬЗЯ ТАК ДЕЛАТЬ ]

Плохой метод: мы предотвращаем таким образом запись в таблицу trm_out_receipt_footer, но не предотвращаем записи в другие таблицы (скидочные, например), поэтому при повторной попытке закрыть чек с нулевым товаром выскочит уже другая ошибка и ukmclient перезапустится.. А в БД будет некорректное состояние. Если уж делать триггер - то по уму, убирая записи в других таблицах, а это непросто: 1) надо понимать, в каких и 2) для каждой новой версии УКМ они могут меняться.. Короче, нельзя так делать.

Чек же на нулевую сумму вполне может быть пробит (скидка 100%), галкой "Запретить продажу товаров с нулевой ценой" в "Параметрах" -> "Параметрах" запрещается закрытие товарной позиции с нулевой ценой.
 
"Спасибо" Onesoft от:
21.02.2013 11:50  
didinap
Мне просто интересно, а зачем запрещать пробитие нулевых чеков. Чем они мешают?
 
21.02.2013 11:56  
Onesoft
Цитата:
Сообщение от didinap
Мне просто интересно, а зачем запрещать пробитие нулевых чеков. Чем они мешают?
Кассиры их таким образом "аннулируют". Бухгалтерия, например, требует от кассиров все аннулированные чеки, указанные в Z-отчёте. Вот кассиры и выкручиваются, чтобы избегать проблем. Аннулированние чека - это потенциально опасная операция, которая может быть следствием махинации..
 
21.02.2013 12:03  
Mtirt
Цитата:
Сообщение от didinap
Мне просто интересно, а зачем запрещать пробитие нулевых чеков. Чем они мешают?
Кассиры таким образом деньги из кассы "вынимают".
Продают товары, получают деньги с покупателя, отменяют позиции и закрывают чек.
Хотя, по идее, у кассира не должно быть прав на отмену позиции.
Но после установки Призмы я выяснила, что в жизни нет ничего не возможного: кассир вводил 13-значный пароль старшего кассира вручную, левой рукой в таких случаях.
 
21.02.2013 12:36  
$piritu$
Цитата:
Сообщение от Mtirt
Кассиры таким образом деньги из кассы "вынимают".
Продают товары, получают деньги с покупателя, отменяют позиции и закрывают чек.
Хотя, по идее, у кассира не должно быть прав на отмену позиции.
Но после установки Призмы я выяснила, что в жизни нет ничего не возможного: кассир вводил 13-значный пароль старшего кассира вручную, левой рукой в таких случаях.
Вот так и мы, только после просмотра призмы, заметили, как администратор ловко пробивает чек после сторнирования. И это после того как запретили аннулировать чек. Получается, если я правильно понял эту проблему, решить не получится. Нужно дорабатывать УКМ?
 
21.02.2013 12:42  
Mtirt
А почему нельзя запретить отменять позиции?
И дать права на отмену позиции только кому-нибудь самому главному?

А если уж нет этого самого главного, то закрывать чек и делать возврат. С собиранием заявлений и паспортных данных покупателей...
 
 


Опции темы



Часовой пояс GMT +3, время: 03:23.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.