Comments 17
Приветствую, Андрей! Спасибо за подробный рассказ.
Скажи, на твой взгляд решения на базе wi-fi микро компьютеров (vocore, blackswift) применимы в нише торговли? (может быть только в складских задачах)
Как успехи с RPi?
Скажи, на твой взгляд решения на базе wi-fi микро компьютеров (vocore, blackswift) применимы в нише торговли? (может быть только в складских задачах)
Как успехи с RPi?
Илья, спасибо за первый комментарий. Рад, что статья получилась интересной, а то я всё думал публиковать её сейчас или уже после НГ.
Я считаю, что в сфере автоматизации ритэйла, микрокомпьютеры, это в первую очередь удобное и универсальное средство подключение торгового оборудования. Они могут позволить более гибкого организовать управления торговой инфраструктурой, как на складе, так и в торговом зале.
По факту сейчас, у каждого производителя железа свой интерфейс управления, и каждый раз приходится в приложение писать отдельно интеграцию под него, да есть стандарты типа Java POS и OPOS, но для них если и есть драйвера, то только у крупных и дорогих брэндов, а у китайских более дешёвых аналогов с этим всегда проблемы. Я вижу решение в том, чтобы на уровне ПО микрокомпьютера реализовать эту интеграцию с оборудованием, а уже с микрокомпьютера для управления с тех-же POS-систем использовать веб-интерфейса типа JSON или Google ProtoBuffer. В этой схеме микрокомпьютер будет выступать в качестве сервера оборудования. Эта идея была уже реализована в коммерческой версии версии Openbravo Web POS, но там из-за необходимости запуска Java SE клиента приходится использовать как раз RPi.
К сожалению на RPi запустить NORD POS можно, но из-за интерфейса на Java Swing, он страшно тормозить. Сейчас правда пробую использовать RPi в качестве локального сервера для развёртывания Java-сервлетов, наверное и следующая статья будет об этом. Также хочу попробовать, в качестве альтернативы тяжеловесной графической оболочке сделать текстовую, к тому-же сейчас появился интересная библиотека Lanterna для реализации консольного GUI на Java.
Я считаю, что в сфере автоматизации ритэйла, микрокомпьютеры, это в первую очередь удобное и универсальное средство подключение торгового оборудования. Они могут позволить более гибкого организовать управления торговой инфраструктурой, как на складе, так и в торговом зале.
По факту сейчас, у каждого производителя железа свой интерфейс управления, и каждый раз приходится в приложение писать отдельно интеграцию под него, да есть стандарты типа Java POS и OPOS, но для них если и есть драйвера, то только у крупных и дорогих брэндов, а у китайских более дешёвых аналогов с этим всегда проблемы. Я вижу решение в том, чтобы на уровне ПО микрокомпьютера реализовать эту интеграцию с оборудованием, а уже с микрокомпьютера для управления с тех-же POS-систем использовать веб-интерфейса типа JSON или Google ProtoBuffer. В этой схеме микрокомпьютер будет выступать в качестве сервера оборудования. Эта идея была уже реализована в коммерческой версии версии Openbravo Web POS, но там из-за необходимости запуска Java SE клиента приходится использовать как раз RPi.
К сожалению на RPi запустить NORD POS можно, но из-за интерфейса на Java Swing, он страшно тормозить. Сейчас правда пробую использовать RPi в качестве локального сервера для развёртывания Java-сервлетов, наверное и следующая статья будет об этом. Также хочу попробовать, в качестве альтернативы тяжеловесной графической оболочке сделать текстовую, к тому-же сейчас появился интересная библиотека Lanterna для реализации консольного GUI на Java.
Если есть драйвера для устройства под dos и x86 то можно сэмулировать с помощью qemu
Для меня проще сразу просить описание протокола нижнего уровня, а если у железа он закрыт, то лучше поискать другой вариант железа, благо это не ракетные технологии и предложений торгового оборудования всегда в избытке. Но если другого выхода нет, то можно попробовать через эмуляцию и драйверы идущие в комплекте. Я как-то так мучился с одним терминалом сбора данных, в итоги прослушал параллельный порт, посмотрел в каком виде он шлёт байты при обмене и сделал тоже самое напрямую без участия драйвера.
BarcodeString, строки 44 и 52: не используется результат String.substring.
JTicketsFinder, строка 142: не используется результат Throwable.getMessage. Как следствие, двумя строками ниже будет NullPointerException, а информация о реальном исключении потеряется.
VectorerBuilder, строка 75: используется результат toString для массива: получится строка вроде "[B@aec71234". Вряд ли это то, что действительно хотелось.
TicketLineInfo, строка 285: при выполнении этого кода гарантировано будет NullPointerException. Видимо, хотели написать attributes.remove(«product.attsetdesc»);
TaxesLogic, строка 58: сравнивать объекты типа Integer по == скорее всего некорректно. Это может работать правильно, если они все меньше 127 и создаются через Integer.valueOf (то есть берутся из кэша), но в один прекрасный день может сломаться.
Используйте статический анализ :-)
JTicketsFinder, строка 142: не используется результат Throwable.getMessage. Как следствие, двумя строками ниже будет NullPointerException, а информация о реальном исключении потеряется.
VectorerBuilder, строка 75: используется результат toString для массива: получится строка вроде "[B@aec71234". Вряд ли это то, что действительно хотелось.
TicketLineInfo, строка 285: при выполнении этого кода гарантировано будет NullPointerException. Видимо, хотели написать attributes.remove(«product.attsetdesc»);
TaxesLogic, строка 58: сравнивать объекты типа Integer по == скорее всего некорректно. Это может работать правильно, если они все меньше 127 и создаются через Integer.valueOf (то есть берутся из кэша), но в один прекрасный день может сломаться.
Используйте статический анализ :-)
Спасибо! Учту и честно признаюсь, что до чистки кода пока руки не дошли.
Вот так исправил, ещё раз спасибо за подробное замечание. А ссылки на код в GitHub делали вручную или чем-то автоматическим пользовались?
Вручную.
Сравнение Integer можно было короче написать:
Зачем возиться с больше-меньше и писать три ветки, когда это давно написано за вас? :-)
Сравнение Integer можно было короче написать:
return o1.getApplicationOrder().compareTo(o2.getApplicationOrder());Зачем возиться с больше-меньше и писать три ветки, когда это давно написано за вас? :-)
Ещё спасибо за статью про класс Comparator, а то код не мой и не до конца было понятно, почему сделано было так, как сделано :)
Скажите, а какое количество внедрений OpenbravoPOS в реальные торговые точки за эти 10 лет? И как часто отказываются в пользу традиционных платных решений?
К сожалению таких цифр у меня, но если брать с форками, то думаю порядка 50.000+ по миру уж точно наберётся. Точно не меньше, так как например даже в России фискальные регистраторы СПАРК шли вместе с ККС: РМК 3.0, которая была основана на версии 2.10.
А по второму вопросу. Как любой OpenSource, это относительно бесплатное решение, так как вы будете либо своё время тратить на внедрение и освоение системы, либо нанимать специалиста, который это сделает за вас.
Из своего опыта скажу, что Openbravo POS обычно выбирают небольшие магазины, где хозяин готов сам освоить и внедрить систему. Более крупный ритэил выбирает Openbravo POS только если уверен, что сможет поддерживать систему самостоятельно, в этом случае экономия на стоимости лицензии при тиражировании.
Из своего опыта скажу, что Openbravo POS обычно выбирают небольшие магазины, где хозяин готов сам освоить и внедрить систему. Более крупный ритэил выбирает Openbravo POS только если уверен, что сможет поддерживать систему самостоятельно, в этом случае экономия на стоимости лицензии при тиражировании.
Вы же наверное и есть тот самый специалист? Скажите, реально ли заработать на внедрении и поддержке Openbravo или форков? По моему личному опыту что-то продать мелкому бизнесу (в том числе и услуги по внедрению) крайне сложно: они как сидели на своем АМС и вели товароучет в тетрадке, так и сидят, и не понимают зачем им что-то менять.
А те кто покрупнее, вы абсолютно правы, обычно покупают популярные решения с поддержкой производителя.
А те кто покрупнее, вы абсолютно правы, обычно покупают популярные решения с поддержкой производителя.
Впрямую вполне реально, но к сожалению пока не у нас. Приходится придумывать схемы, платите за железо, а софт бесплатно. Но даже это на наш малый бизнес чаще всего не срабатывает, так как зачастую и за железо не готовы платить. Я чаще всего сталкиваюсь с рассуждением, что нам проще ещё одного продавца нанять, чем 400-500 у.е. за компьютер+сканер штрих-кодов заплатить. У нас именно малый бизнес выигрыша в скорости обслуживания от автоматизации не видит. За границей немного всё по другому, с теми с кем я работал, зачастую сами за прилавком стоят и делают автоматизацию под себя, для них СПО решение это самое то. Да это не ERP, но для ежедневного ведения учёта подходит, так как оперативно можно отслеживать товарно-денежный поток проходящий через твой магазин.
Sign up to leave a comment.
NORD POS. История о том, зачем мне нужен был ещё один форк Openbravo POS