forum.clarionlife.net

finsoftrz писал(а): 20 Июль 2018, 15:46 То есть фантазировать мы можем что угодно, реальность есть реальность...

Да ! Это бизнес. Я недавно подключал франшизу международной английской школы, там крутое оборудование c DELL & Cisco и ... Win2003 и XP.
И мне московский сисадмин прямо сказал, что абсолютно незачем тратить лишний раз деньги, если всё и так работает прекрасно.
Могу предположить, что именно по той же причине ПИРИТ нашёл свою нишу на рынке дешёвых регистраторов для некоторых торговых сетей и самоисключился из конкуренции с АТОЛ & Штрих-М, а заодно и какого-либо развития. Зачем ? И так всё работает с эмулятором COM порта …

Пириты позиционируются как надежные... Там есть разные модели. Атолы и Штрихи тоже через эмуляторы com-портов работают. Только на Вашем современном компьютере какое-то исключение.

finsoftrz писал(а): 20 Июль 2018, 16:47Пириты позиционируются как надежные...

Интересно, а существует вообще производитель, который позицирует свои девайсы как ненадёжные (но зато например, дешёвые) ?

finsoftrz писал(а): 20 Июль 2018, 16:47Только на Вашем современном компьютере какое-то исключение.

Конкретно сейчас работаю на ноуте, который купил на распродаже, да ещё и по акции шесть лет назад. COM портов на нём уже действительно не было, а вот эмулятор COM портов - прекрасно работает. Только я его использую не для того, что бы записывать в порт "надёжных" Пиритов, а для эмуляции печати чеков на АТОЛ, что позволяет отлаживать кассовый софт без наличия самого ФР. Вот и всё.

По пиритам я озвучил мнение не продажников, а тех, кто эксплуатирует эту технику. Там есть и негативные отзывы по поводу сложностей с подключением к ОФД. Надо специальную программку ComProxy поднимать. И подключить можно не более 2 фискальников на 1 компьютер, что тоже не комильфо.
И зачем Вам эмулятор com-порта для Атола? Вы же вроде писали, что оно Атолу не нужно. Или еще кто-то писал. Я уже запутался...
Кстати, видели вживую, как выглядит шнур для подключения платежных терминалов у Сбербанка? Ухохочитесь, там на одном шнуре разветвляются usb и физический com-порт. А кабель питания втыкается прямо в блок com-порта. Я его вход вначале даже не заметил...
Популярен разветвитель для com-портов. Это когда втыкаешь шнур в usb компьютера, а с другой стороны блочек с 4 физическими com-портами. Потому как полно оборудования, которое иначе никак не подключишь. Бизнес, говорите, экономит на всем... Какие нехорошие люди, не дают прогрессу развиваться. А сами работаете на допотопном ноуте, древнючем кларионе. И вполне себе счастливы. Я надеюсь... Нет бы на молодежном и энергичном джава скрипте что-нибудь для андроидов клепать. Хотя андроид тоже что-то сомнительно, у него ушки древнего линукса торчат...
Вообще, это все шутки для расслабиться под конец недели...

Вот тут задумался. Некоторые разработчики кассовых программ пишут, что надо в базе данных чеков сохранять все реквизиты ккм - заводской номер, регистрационный номер, номер регистрации в ОФД, номер чека в ОФД, подпись ФП. То есть для каждого чека. Мол, вдруг какие разбирательства. Здравая мысль в этом есть, хотя практическую потребность я пока вижу только в номере чека ФД, чтобы можно было запросить и распечатать его копию...

finsoftrz писал(а): 20 Июль 2018, 17:55Вы же вроде писали, что оно Атолу не нужно. Или еще кто-то писал.

И я, в том числе, это говорил. Если был бы сам ФР АТОЛ - то он просто включается в USB или LAN порт (в зависимости от конфигурации) и работает напрямую через драйвер. Так как у меня его постоянно нет - то просто используется эмулятор, который позволяет визуализировать печтаемые чеки без наличия самого физического девайса ...

finsoftrz писал(а): 20 Июль 2018, 17:55Бизнес, говорите, экономит на всем... Какие нехорошие люди, не дают прогрессу развиваться.

Пардон, но это Вы услышали не от меня. Да, деньги не потраченные - это деньги заработанные. Я привёл пример, что бы показать, как объясняется использование устаревшего системного софта. Т.е. никто не расказывает байки про супернадёжность WinXP и т.д., а просто говорят, что мы ничего нового не покупаем, т.к. у нас и на старом всё прекрасно работает ... А сервер DELL, который работает под Win2003 - от 120 тр., т.е. на то, что нужно - деньги находятся и прогресс вполне себе развивается.

finsoftrz писал(а): 20 Июль 2018, 18:20Мол, вдруг какие разбирательства

У меня уже есть опыт общения с ОФД. Ничего Вы там записями в своей БД и номерами не докажете.
В ОФД сразу говорят - если у нас какой-то нет суммы, покажите нам ФИСКАЛЬНЫЙ КАССОВЫЙ ЧЕК.
Всё - остальное не документы, даже не смотрят. И, кстати, правильно делают.

Почему используется эмулятор com-порта для эмулятора атоловского фискальника? В то время как сам фискальник эмулятор не использует. Вы же понимаете, что использование com-портов зависит от подключаемого оборудования. Это не определяется драйвером-надстройкой. Какие-то модели поддерживают другие каналы связи с компьютером, какие-то нет. Драйвер атола универсальный...
Кстати, если поискать в интернете, то можно найти доку по низкоуровневой работе с атоловскими фискальниками, мне попадалась мимоходом. Там все очень похоже, как для пиритов описано, идеология практически одинаковая. Слать же последовательные байтики через com-порт (его эмулятор), что годами отработано и поддерживается в рамках win api, либо предлагать другие варианты (сокеты, к примеру), дело разработчиков конкретных девайсов. Лично мне, как разработчику прикладного софта, предпочтительнее, чтобы было стандартизировано и как можно проще в использовании. Остальное перпендикулярно...

Игорь Столяров писал(а): 20 Июль 2018, 18:38

finsoftrz писал(а): 20 Июль 2018, 18:20Мол, вдруг какие разбирательства

У меня уже есть опыт общения с ОФД. Ничего Вы там записями в своей БД и номерами не докажете.
В ОФД сразу говорят - если у нас какой-то нет суммы, покажите нам ФИСКАЛЬНЫЙ КАССОВЫЙ ЧЕК.
Всё - остальное не документы, даже не смотрят. И, кстати, правильно делают.

То есть Вы не видите смысла хранить в базе чеков реквизиты ккм, на которых они выводились?

А у Вас кто-нибудь из клиентов вообще сверяет ежедневно итоги с ОФД? Я тут недавно думал по поводу Егаиса, там аналогичные проблемы тоже могут всплыть. Ключ и УТМ установлены на одном компьютере (у товароведа), а чеки бьют на других. В Егаис с кассы информация шлется по заданному ip адресу и порту через УТМ. Контролировать потенциальные проблемы можно, пожалуй, только по логу УТМ. А кассовая программа к нему доступа не имеет. То есть это должен, видимо, делать бэк, но тогда из кассы должны приходить идентификаторы чеков Егаис, которые она получает в ответ на продажу от УТМ. И никто про это даже не задумывается, не то чтобы деньги платить за реализацию в софте...

finsoftrz писал(а): 20 Июль 2018, 18:54То есть Вы не видите смысла хранить в базе чеков реквизиты ккм, на которых они выводились?

Чем больше информации - тем лучше. Но это скорей не для ОФД, а для разборок с покупателями. Там вечно что-то не то списалось, какие-то непонятные требования возвратов (есть смысл проверить чек по своей базе) и т.д. Уже было несколько чеков "совсем как настоящие".

Да. Есть пендитные товарищи, которые всегда после печати Z-отчёта лезут в ОФД и сверяют сумму.


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

Есть еще один интересный вопрос по работе с ФР из Clarion, который мы походу уже обсуждали …
Если посмотреть примеры или тестовые скрипты АТОЛ или ШТРИХ-М, то там всегда показана такая схема работы:

- Инициализация подключения к ФР;
- Открытие чека (или команда на отчёт);
- Формирование и печать чека (отчёта);
- Закрытие чека (отчёта);
- Разрыв соединения с ФР.

И так по кругу, для каждого действия с ФР. С одной стороны - понятно, что как бы универсальный цикл работы.
С другой (учитывая капризы и тугодумство Clarion при работе с OLE объектами) надо ли для каждого чека выполнять
инициализацию объекта и новое подключение к ФР ? И если работать по упрощённой схеме: один раз инициализировали
подключение и печатаем чеки до конца смены (или закрытия окна кассира) - есть ли здесь какие-то "подводные камни" ?

Это надо пробовать...

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

Для розницы сейчас я сделал инициализацию один раз в окне кассира. Перед печатью делается проверка требуемого номера логического устройства и переключение, если надо (на случай подключения нескольких фискальников). Но пока плотно не тестировал.

В pos системах еще всплывает вопрос о всякого рода диагностики фискальников. Например, при входе в программу надо проверить доступность всех фискальников из списка, проверить соответствие ИНН, вывести сообщение, если чеки не отправляются в ОФД. А в случае проблемных ситуаций вывести вменяемое сообщение об ошибке, коих может быть немало разных - не закрыта смена больше 24 часов, нет бумаги и т.п.

Игорь Столяров писал(а): 22 Июль 2018, 17:08 И если работать по упрощённой схеме: один раз инициализировали
подключение и печатаем чеки до конца смены (или закрытия окна кассира) - есть ли здесь какие-то "подводные камни" ?

Именно так и сделал с самого начала (уже несколько лет). Что-то по другому не пришло в голову делать -). Работает все без проблем. Начиналось на С63. Сейчас на С10. В последней версии пустил всю работу с ФР в отдельный поток (дабы не парится с инициализацией и подключением из разных окон). Программа стартует, поток стартует, объект ФР создается и все. Откуда хочешь обращайся к объекту ФР - он глобальный (вернее ссылка на него). При обращении к методам объекта ФР происходит переключение потока для работы с ОЛЕ. Когда программа закрывается (поток для работы с оборудованием закрывается) и происходит отключение от ФР. Как-то так.

Ну вернее чуток не так. Поток для работы с оборудованием стартует только в той части программы где нужно оборудование. Вернее вызов этой части стартует два потока - один для работы с оборудованием, второй собственно прикладная часть оборудование использующая. Закрывается прикладная часть - закрывается и поток оборудования.

Глянул у пиритов, при печати фискального документа из архива ФН выводятся только общие значения. То есть, как и предполагали, в ФН полностью чек (включая товары) не хранится. Поэтому остается команда открыть копию чека и выводить строки туда повторно.