Опять о магнитных катах

[PavelShu]

Имеются следующие виды магнитных карт:
1. Скидочная
2. Бонусная
3. Кредитная
4. КредитноСкидочная
5. КредитноБонусная

С 1-2 все ясно,вопрос с остальными:
Клиент предъявляет кредитную карту, кассир читает ее и видит,
что карта кредитная (оплата будет в конце месяца, на закрепленное юр.лицо)
и не требует оплаты с клиента, клиенту печатается чек.

С 4 и 5 тоже самое, что с 3, только клиент еще видит скидку или может управлять бонусами.

Как это можно привязать к таблице фиксированных скидок?
Еще нужно как-то запретить воспользоваться несколькими видами карт в одном чеке.

[Alexander]

Клиент предъявляет кредитную карту, кассир читает ее и видит,
что карта кредитная (оплата будет в конце месяца, на закрепленное юр.лицо)
и не требует оплаты с клиента, клиенту печатается чек.

Получается наличие карты в данном случае просто фиксирует тип оплаты.
Надо подумать, на текущий момент такого функционала нет.
С одной стороны явно надо расширять список типов оплаты, но с другой стороны не все модели ФР такое поддерживают. В Меркурий-MSK, например, вообще только нал/безнал, насколько я помню.

Собственно, кредитно-бонусная и кредитно-скидочная карты в таком ключе ничем не отличаются от "просто" бонусных и скидочных - только одновременной фиксацией типа оплаты.

Если все это привязано к фиксированным скидкам, то несколько карт из общего списка фиксированных скидок зарегистрировать в чеке не получится - одна будет просто заменять собой другую.

[Spike]

А я давно говорил что "тип оплаты" надо расширять.
У нас к примеры используются банковские кредиты. И хотя для фискальника это одно и тоже (оплата безналом), в 1с приходится постоянно править отчеты, и проставлять где пластиковая карта (догор эквайринга), где банковский кредит (к тоже у нас три разных банка,и у всех свои настройки).

[Alexander]

Предложите, как это должно выглядеть в интерфейсе (с учетом предварительно настраиваемого и, потенциально, неограниченного списка "виртуальных" типов оплаты, которые настройками можно привязать к аппаратным типам). Интересует не настройка, а именно максимально простой и понятный для кассира вариант реализации интерфейса закрытия чека с таким вот расширенным списком типов оплаты.

Возвращаясь к теме - в принципе добавить правила для кредитных карт (фиксация типа оплаты) на первый взгляд не так уж сложно. И для комбинированных типов карт остальные условия остаются текущие - надо только добавить эту самую фиксацию, ну и со списком типов оплаты все-таки поработать, т.к. на текущий момент привязать фактически не к чему.

[PavelShu]

Предложите, как это должно выглядеть в интерфейсе (с учетом предварительно настраиваемого и, потенциально, неограниченного списка "виртуальных" типов оплаты, которые настройками можно привязать к аппаратным типам). Интересует не настройка, а именно максимально простой и понятный для кассира вариант реализации интерфейса закрытия чека с таким вот расширенным списком типов оплаты.

В интерфейсе это должно выглядеть так:

После регистрации всех покупок, кассир считывает магнитную карту клиента или штрихкод.
В случае скидки/бонуса все остается как есть, если есть привязка одного
Варианта оплаты (нал, безнал, кредит и т.д.) то на экран выходит этот вариант.
Если к карте привязано несколько вариантов оплат, то кассир должен выбрать вариант из предложенного списка и этот вариант должен через обмен попасть в учетную систему.
Комбинированный способ оплаты можно представить в виде табличной части (Тип оплаты, сумма) или пока можно не реализовывать.

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


Что касается ФР, то в нашем случае он выступает в качестве ЧПУ.
Эквайринговая система работает автономно (не привязана к кассовому модулю) и кассир выбирает в кассовом модуле (не денси:касса) вариант оплаты для переноса в учетную систему.

По поводу «запретить воспользоваться несколькими видами карт в одном чеке»
Провел такой эксперимент:
1. Выбили товар
2. Провели скидочной картой и получили скидку
3. Тут же провели бонусной картой и вылез диалог с бонусами (вот на этом месте следовало бы поругаться), причем скидка может быть на юр.лицо, а бонусная карта на частное лицо.

Для перехода на денси, требуется разрешить ряд этих проблем, пока мы заняты разработкой учета бонусов в учетной системе 1с77 ТиС и реализацией протокола обмена Денси.

Возвращаясь к теме - в принципе добавить правила для кредитных карт (фиксация типа оплаты) на первый взгляд не так уж сложно. И для комбинированных типов карт остальные условия остаются текущие - надо только добавить эту самую фиксацию, ну и со списком типов оплаты все-таки поработать, т.к. на текущий момент привязать фактически не к чему.

Как скоро на это можно будет рассчитывать?

PS Работаем с клиентской учетной системой, а окончательное внедрение стало под вопросом.

[PavelShu]

Можете хотя бы обнадежить, есть ли в Ваших ближайших планах реализация привязки видов оплат к фиксированным скидкам?

Можно пока без удобств, в виде интерфейса занесения новых видов оплат, и расширения протокола обмена (в БД занесем, через внешний скрипт).

[Rafta]

По поводу бонусов.
Клиент купил товара на определенную сумму, ему выдается бонусная карта со штрих-кодом, как зафиксировать продажу на выдаваемую бонусную карту? Пока никак. Нулевая скидка и нулевой бонус не порождают 37 транзакцию, в которой и можно только передать штрих-код. Может мы чего-то недопонимаем?

[PavelShu]

По поводу бонусов.
Клиент купил товара на определенную сумму, ему выдается бонусная карта со штрих-кодом, как зафиксировать продажу на выдаваемую бонусную карту? Пока никак. Нулевая скидка и нулевой бонус не порождают 37 транзакцию, в которой и можно только передать штрих-код. Может мы чего-то недопонимаем?

Почему бы не добавить новый тип транзакции?
Если не хочется засорять таблицу transaction, можно создать другую и писать
в нее, когда это нужно.

Если не получается сделать просто кредитную карту, то сделать
хотя бы кредитноскидочную и кредитнобонусную (бонусы можно не учитывать в учетной системе).

PS Есть еще проблема активации карт кассиром, о которой я пока молчу.

[PavelShu]

Предложите, как это должно выглядеть в интерфейсе (с учетом предварительно настраиваемого и, потенциально, неограниченного списка "виртуальных" типов оплаты, которые настройками можно привязать к аппаратным типам). Интересует не настройка, а именно максимально простой и понятный для кассира вариант реализации интерфейса закрытия чека с таким вот расширенным списком типов оплаты.

Еще один вариант:

Типы оплат вообще не привязываются к фиксированным скидкам и хранятся отдельно.

Т.е. в базу LinCash добавить 2 таблицы:
1. payment_type с вариантами оплаты (pt_id,name)
2. cards (c_id,name,pt_id,barcode,cardcode) со штрих и магнитными кодами и привязанным типом оплат по иду из payment_type


После регистрации всех товаров, кассир считывает карту для расчета скидки/бонусов.
Далее нажимает комбинацию клавиш для выбора типа оплаты и считывает ту же самую карту второй раз!
Если код карты находится в таблице cards не в единственном экземпляре выходит диалог выбора типа оплаты.
В базу Transaction пишется транзакция с кодом карты и новым типом транзакции (вид оплаты).

[Rafta]

Почему бы не добавить новый тип транзакции?
Если не хочется засорять таблицу transaction, можно создать другую и писать...
PS Есть еще проблема активации карт кассиром, о которой я пока молчу.

Да не будет засоряться transaction добавится только новая транзакция с номером 77 - Отдали даром, т.е в кредит и не надо переделывать систему выгрузки, только подправить обработки обмена.
Проблем с активацией карт нет, сначала они загружаются в товароучетную прогамму с именами Дисконт1, Дисконт2,потом выгружаем в Дэнси кассу с нулевыми скидками (бонусами), при выдаче карты Покупателем заполняется анкетка, карта штрихуется в чеке, вместе с которым и выдается, применяется нулевая скидка (бонус) и если будет создана 37 транзакция (или 77), то обработкой можно будет в товароучетку загрузить отдельными Отчетами ККМ и в них будет уже указан контрагент. Затем меняем имя Дисконт1 на имя из анкеты и присваиваем скидку или бонус на следующие операции.
Может немного субурно, но переделок в Дэнси в этом случае минимум.
Хотелось бы узнать как Вы видите работу бонусной системы.