[ТЕМА ЗАКРЫТА]
20.02.2013 10:28
$piritu$
 
Доброго времени суток!
Делается так:
Пробили товар - сторнировали все позиции в чеке - на экране "0" - нажимаем "расчет"- выходит окно "введите сумму" - оставляем "0" - нажимаем ввод - выходит чек.
В чеке:
товаров в позиции - 0
к оплате - 0
того к оплате 0
Вопрос в том как запретить проведение нулевого чека?
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%), галкой "Запретить продажу товаров с нулевой ценой" в "Параметрах" -> "Параметрах" запрещается закрытие товарной позиции с нулевой ценой.
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
 
А почему нельзя запретить отменять позиции?
И дать права на отмену позиции только кому-нибудь самому главному?

А если уж нет этого самого главного, то закрывать чек и делать возврат. С собиранием заявлений и паспортных данных покупателей...
21.02.2013 12:50
$piritu$
 
Сторнированием и возвратами занимается администратор. Директору некогда. Ссылаются на то что и так времени нет еще возвратами завалят. Вообщем будем думать.....
21.02.2013 12:51
Onesoft
 
Цитата:
Mtirt А почему нельзя запретить отменять позиции?
И дать права на отмену позиции только кому-нибудь самому главному?

А если уж нет этого самого главного, то закрывать чек и делать возврат. С собиранием заявлений и паспортных данных покупателей...
Например, у нас в магазинах в основном по 2 (максимум 4) кассы, поэтому постояннодействующего старшего кассира нет, его роль выполняют директор или зам. По каждому поводу бегать тяжело, а достаточно часто бывает, что покупатели отказываются от покупки.. Вот и получается, что кассиры набирают пароли старшего кассира, под диктовку по телефону из кабинета или уже наизусть, а однажды я даже картонку с паролями запалил.
Случаи такие выявляем, виновных наказываем, пароли меняются по регламенту, доработка такая нам как бы и не нужна..
21.02.2013 13:03
Mtirt
 
У нас касс побольше, обычно.
И охранник на крик кассира "Девчонки, у кого бэйджик" голову поворачивает - посмотреть, что там на кассе происходит.
У нас пароли в виде штрих-кода на бэйджике (без цифр, только штрихи). Поэтому до ввода цифр надо было еще додуматься...
Картонки с паролями КРО уже несколько раз в магазинах находили, это приводит к смене паролей у всего персонала магазина.
У людей с правами старших кассиров бэйджи планово меняются раз в квартал.
Еще есть люди, которые обязаны просматривать аннулированные и сторнированные позиции в УКМ4 ежедневно. И разбираться, был ли умысел.

Кстати, $piritu$, не поможет тебе ограничение на сумму чека.
Что помешает кассиру закрыть не нулевой чек, а с одним пакетом, например?
Или убирать только 2-3 последние позиции?
21.02.2013 14:42
vdm
 
Ошибку выдать на экран кассира вполне можно.
Пример про чуть другое, но на ту же тему.

Код:
-- Максимально допустимая сумма чека
receipt_max_subtotal=200000

function print_receipt_close(__core, __print_data)

    -- Проверка на максимальную сумму чека
    if __core:subtotal_exists() and __core:footer_exists() then
      if (__core.subtotal.amount > ukm.currency(receipt_max_subtotal)) and
         (__core.footer.result == ukm.footer.normal) and
         (__core.header.receipt.type ~= ukm.core.copy)
      then
        error("ЗАПРЕЩЕНА ОПЛАТА БОЛЕЕ ".. tostring(receipt_max_subtotal) .." руб.");
      end
    end
Работает оно так: чек начинает печататься, ближе к его завершению в lua генерируется ошибка, УКМ показывает ее кассиру, в ФР чек аннулируется, а на экране остается висеть.
Т.е. его можно только аннулировать.
21.02.2013 16:54
akonev
 
Цитата:
Mtirt ...А если уж нет этого самого главного, то закрывать чек и делать возврат. С собиранием заявлений и паспортных данных покупателей...
Не, вот это уже точно не вариант. Чего ради я, как покупатель, начну писать какие-то заявления, если у меня, к примеру, денег не хватило? Деньги я не отдал, товар не забрал. Сделки не было. Не буду я рассказывать паспортные данные людям, которым собственное начальство не верит :)
21.02.2013 17:01
akonev
 
Цитата:
Mtirt ...
Еще есть люди, которые обязаны просматривать аннулированные и сторнированные позиции в УКМ4 ежедневно. И разбираться, был ли умысел...
Вот единственный вариант, наверное. При наличии наблюдения можно чего-то добиться.
Замечательную историю помню со сговором кассира, старшего кассира и охранника.
21.02.2013 17:01
Mtirt
 
В положении о ведении кассовых операций сиё чудо написано. Не виноватая я...
22.02.2013 16:05
whitewizard
 
Цитата:
Mtirt У нас пароли в виде штрих-кода на бэйджике (без цифр, только штрихи). Поэтому до ввода цифр надо было еще додуматься...
Я сделал пароли не в виде цифр, а
_кодкарты

соответственно знак "_" на клаве набрать не могут.
копировали, правда, бэйджики на сканере, но за это по голове получали.
Опции темы


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

 

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