Интеграцию оборудования(ESC/POS дисплея покупателя) есть в сервлете для ресторанов github.com/nordpos-mobi/restaurant-service По похожему принципу можно интегрировать любое другое POS-оборудование, в том числе и фискальники. Главное, что на любой клик веб-интерфейса будет срабатывать действие сервлета, который в свою очередь будет отправлять или получать команду от оборудования подключенного к Raspberry Pi.
Молодцы, что довели проект до готового решения. Сами начинали проект с той-же идей и на том-же Raspberry Pi, но дальше рабочего прототипа не ушли. При этом в нашем решении Raspberry Pi выступил в роли мини-веб-сервера для Java сервлетов. Если интересно можете глянуть исходники на ГитХабе.
Значит, специально для Вас, следующая статья будет о встроенном в NORD POS средстве синхронизации данных Pentaho Data Integration. С его помощью можно например внедрить гибридные решения, например POS на Linux, а УТ и Бухгалтерия на Windows.
У нас в Казахстане был похожий конкурс для студентов. Я так как уже давно не студент в конкурсе не участвовал, но попробовал поиграть с открытыми данными и сделал простенький Java-сервлет по статданным, есть демо и исходники. Россияне можете брать и пользоваться, мы с сегодняшнего дня в ЕАЭС и открытые данные у нас тоже должны быть теперь общими ;)
Впрямую вполне реально, но к сожалению пока не у нас. Приходится придумывать схемы, платите за железо, а софт бесплатно. Но даже это на наш малый бизнес чаще всего не срабатывает, так как зачастую и за железо не готовы платить. Я чаще всего сталкиваюсь с рассуждением, что нам проще ещё одного продавца нанять, чем 400-500 у.е. за компьютер+сканер штрих-кодов заплатить. У нас именно малый бизнес выигрыша в скорости обслуживания от автоматизации не видит. За границей немного всё по другому, с теми с кем я работал, зачастую сами за прилавком стоят и делают автоматизацию под себя, для них СПО решение это самое то. Да это не ERP, но для ежедневного ведения учёта подходит, так как оперативно можно отслеживать товарно-денежный поток проходящий через твой магазин.
Для меня проще сразу просить описание протокола нижнего уровня, а если у железа он закрыт, то лучше поискать другой вариант железа, благо это не ракетные технологии и предложений торгового оборудования всегда в избытке. Но если другого выхода нет, то можно попробовать через эмуляцию и драйверы идущие в комплекте. Я как-то так мучился с одним терминалом сбора данных, в итоги прослушал параллельный порт, посмотрел в каком виде он шлёт байты при обмене и сделал тоже самое напрямую без участия драйвера.
А по второму вопросу. Как любой OpenSource, это относительно бесплатное решение, так как вы будете либо своё время тратить на внедрение и освоение системы, либо нанимать специалиста, который это сделает за вас.
Из своего опыта скажу, что Openbravo POS обычно выбирают небольшие магазины, где хозяин готов сам освоить и внедрить систему. Более крупный ритэил выбирает Openbravo POS только если уверен, что сможет поддерживать систему самостоятельно, в этом случае экономия на стоимости лицензии при тиражировании.
К сожалению таких цифр у меня, но если брать с форками, то думаю порядка 50.000+ по миру уж точно наберётся. Точно не меньше, так как например даже в России фискальные регистраторы СПАРК шли вместе с ККС: РМК 3.0, которая была основана на версии 2.10.
Илья, спасибо за первый комментарий. Рад, что статья получилась интересной, а то я всё думал публиковать её сейчас или уже после НГ.
Я считаю, что в сфере автоматизации ритэйла, микрокомпьютеры, это в первую очередь удобное и универсальное средство подключение торгового оборудования. Они могут позволить более гибкого организовать управления торговой инфраструктурой, как на складе, так и в торговом зале.
По факту сейчас, у каждого производителя железа свой интерфейс управления, и каждый раз приходится в приложение писать отдельно интеграцию под него, да есть стандарты типа Java POS и OPOS, но для них если и есть драйвера, то только у крупных и дорогих брэндов, а у китайских более дешёвых аналогов с этим всегда проблемы. Я вижу решение в том, чтобы на уровне ПО микрокомпьютера реализовать эту интеграцию с оборудованием, а уже с микрокомпьютера для управления с тех-же POS-систем использовать веб-интерфейса типа JSON или Google ProtoBuffer. В этой схеме микрокомпьютер будет выступать в качестве сервера оборудования. Эта идея была уже реализована в коммерческой версии версии Openbravo Web POS, но там из-за необходимости запуска Java SE клиента приходится использовать как раз RPi.
К сожалению на RPi запустить NORD POS можно, но из-за интерфейса на Java Swing, он страшно тормозить. Сейчас правда пробую использовать RPi в качестве локального сервера для развёртывания Java-сервлетов, наверное и следующая статья будет об этом. Также хочу попробовать, в качестве альтернативы тяжеловесной графической оболочке сделать текстовую, к тому-же сейчас появился интересная библиотека Lanterna для реализации консольного GUI на Java.
В Openbravo POS интегрировано расширение Substance Look & Feel, так что из набора скинов вы можете подобрать подходящий для себя даже не перезапуская приложения. При этом делая форк каждый автор старается застолбить одну из тем по-умолчанию за собой, чтобы хоть чем-то отличаться в оформлении интерфейса от оригинальной Openbravo POS. Это кстати меня с моим NORD POS тоже касается, но об этом уже в следующей статье. А пока, пример той-же панели, но с темой Creme и иконками Faenza
Здесь github.com/nordpos-mobi/product-catalog/releases выложил исходники для создание простого CRUD сервлета для работы с Openbravo POS через мобильный веб-интерфейс. Из «плюшек» возможность по-умолчанию генерировать для товаров EAN-13 штрих-код.
Спасибо, но есть вариант и для Windows. По моему в драйвере Атола есть возможность прогружать символы из ОЗУ дисплея непосредственно в ПЗУ. Делал это через тест-драйвера, а вот можно делать этой из самой 1С не знаю не проверял.
В нём по аналогии с биткоинами для передачи информации о продавце используется QR-код, а для подтверждение платежа смартфон клиента.
Из своего опыта скажу, что Openbravo POS обычно выбирают небольшие магазины, где хозяин готов сам освоить и внедрить систему. Более крупный ритэил выбирает Openbravo POS только если уверен, что сможет поддерживать систему самостоятельно, в этом случае экономия на стоимости лицензии при тиражировании.
Я считаю, что в сфере автоматизации ритэйла, микрокомпьютеры, это в первую очередь удобное и универсальное средство подключение торгового оборудования. Они могут позволить более гибкого организовать управления торговой инфраструктурой, как на складе, так и в торговом зале.
По факту сейчас, у каждого производителя железа свой интерфейс управления, и каждый раз приходится в приложение писать отдельно интеграцию под него, да есть стандарты типа Java POS и OPOS, но для них если и есть драйвера, то только у крупных и дорогих брэндов, а у китайских более дешёвых аналогов с этим всегда проблемы. Я вижу решение в том, чтобы на уровне ПО микрокомпьютера реализовать эту интеграцию с оборудованием, а уже с микрокомпьютера для управления с тех-же POS-систем использовать веб-интерфейса типа JSON или Google ProtoBuffer. В этой схеме микрокомпьютер будет выступать в качестве сервера оборудования. Эта идея была уже реализована в коммерческой версии версии Openbravo Web POS, но там из-за необходимости запуска Java SE клиента приходится использовать как раз RPi.
К сожалению на RPi запустить NORD POS можно, но из-за интерфейса на Java Swing, он страшно тормозить. Сейчас правда пробую использовать RPi в качестве локального сервера для развёртывания Java-сервлетов, наверное и следующая статья будет об этом. Также хочу попробовать, в качестве альтернативы тяжеловесной графической оболочке сделать текстовую, к тому-же сейчас появился интересная библиотека Lanterna для реализации консольного GUI на Java.