Комментарии 18
Если рассматривать систему lsFusion на уровне платформы, возможностей здесь значительно меньше, чем в 1С. И с этой точки зрения можно сказать, что lsFusion явно проигрывает
Тут смотря по количеству или по качеству сравнивать. Потому как у теслы тоже (особенно на начальном этапе) всего три возможности было - заряжаться дома, не иметь выхлопов и быстро разгоняться до ста, тогда как у остальных автомобилей было огромное число возможностей - подогрев сидений, массаж, всяческие подлокотники, подстаканники и т.п. А уж если с автомобилем сравнить самолет, так самолет вообще по всем возможностям проигрывает вчистую. Ну кроме одной он очень быстро летает.
Собственно 1С и остальные платформы попали в ту же ловушку, что и автопроизводители в свое время. Вроде из существующей технологии выжали все что могли и приходится соревноваться в свистоперделках, которые вроде прикольны, но практической пользы от них не сильно много. А чтобы добиться чего-то принципиально нового (той же модульности и скорости / простоты разработки), нужно полностью менять концепцию, а это делать никто не любит.
В lsFusion же как раз принципиально другой подход (как у SQL в свое время), что из этого получится выжать в перспективе - время покажет. Хотя даже сейчас если взять фундаментальные возможности, а не рюшечки, сравнение мягко говоря не такое однозначное.
Плюсанул за развернутый комментарий. Но таблица сравнения на которую вы ссылаетесь... Слишком уж радужную картинку рисует, такое себе.
Но таблица сравнения на которую вы ссылаетесь... Слишком уж радужную картинку рисует, такое себе
Безусловно. Маркетинг штука такая.
Но вообще основная проблема всех декларативных вещей (с более высокими уровнями абстракций, как например SQL или условный "самолет" :) ) это гибкость (так как повышение уровня абстракции неизбежно ограничивает количество элементов абстракций) и масштабируемость (за счет требований более высокой целостности и иногда накладных расходов). И вот тут действительно не все так радужно может быть. Впрочем если давать точки входа (например в Java и SQL), то можно и решить эти проблемы, но при этом может получиться каша из топора :(
Отлично было бы раскрыть тему как реализовано обновление приложений написанных на платформе? Пока сложилось впечатление что единообразия нет, кто во что горазд из разработчиков.
Учитывая, что там используется инфраструктура Java, то обновление там осуществляется точно также, как и всех Java приложений. Фактически lsf-файлы это такие же файлы ресурсов, как и любые другие ресурсные файлы.
Обновление решений - это просто остановка службы и замещение jar-файлов, содержащих lsf-файлы. А как собирать jar-ки вариантов много. Например, через Build artifact в IntelliJ IDEA, или через Maven и mvn assemble. Соответственно, можно прикручивать Jenkins к процессу сборки (мы лично так и делаем).
То есть вариантов действительно несколько, но это не что-то специфическое непосредственно для lsFusion, а общие схемы, как в Java.
lsFusion плюсы только языка платформы для меня
1. один язык и причем легко интегрируется вниз как в sql так и java (и нет искуственных sql и java недоязыков) - но нужно интегрироваться очень редко
2. типизирован и весьма весьма. если уж собрался проект то работать будет без детских ошибок.
3. очень компактный код. реально выброшено много лишнего что писать приходится в других языках.
4. Все текстовое - git наш друг до последней закорючки.
плюс удобная IDE и производительность труда программиста, дорогого ресурса нынче, высока
4. Все текстовое - git наш друг до последней закорючки.плюс удобная IDE и производительность труда программиста, дорогого ресурса нынче, высока
Вы про это (взято из статьи)?
Важно отметить что возможно использования плагина для IntelliJ IDEA для работы с LSFusion.
Кроме того, платформа lsFusion написана на Java. А этот язык нетребователен к ресурсам
С каких это пор Java не требователен к ресурсам? JVM же требует много памяти.
Вы сравниваете с С , С++, Go, Rust, Zig?
Думаю, что имелось ввиду по сравнению с Python / Ruby / JS / 1С. То есть по сравнению с интерпретируемыми языками.
Но в целом да, на голом C работало бы быстрее. Но и проблем было бы в разы больше в связи с достаточно сложной архитектурой. С одними только утечками памяти и access violation можно было бы повеситься.
Интересно, если клиентская часть работает в браузере, даже на android, то как она работает с оборудованием? Собирает broadcast события от сканера тсд, работает с com портами сканера из под windows!
Обычно просто сканеры эмулируют клавиатуру. Например, в тех же ТСД можно настраивать префикс, который пошлёт сканер при считывании штрих-кода. Если не поддерживаются клавиши F<1-12>, то можно настроить просто SPACE.
Соответственно, в форме настраивается свойство с changeKey = 'SPACE'. И дальше обрабатывается одинаково, что пользователь ввёл с клавиатуры штрих-код, что просканировало. Это надежно работает даже при очень активном использовании в том же WMS.
Но, кстати, с com портами из браузера тоже приходилось работать. А именно, приходилось считывать вес с весов, которые подключаются через com-port. Отдельная песня, что сейчас com-портов в обычных компьютерах нет, и там идет эмуляция com-порта через USB, но это решается на уровне настроек драйверов.
Чтение веса в этом случае идет через Web Serial API : https://developer.mozilla.org/en-US/docs/Web/API/Web_Serial_API . И тоже работает достаточно надежно. Теоретически можно через этот же Web Serial API реализовать и сканер, только непонятно зачем, если через буфер клавиатуры тоже работает нормально.
Для печати напрямую на принтер без предпросмотра используется https://qz.io/.
Если еще какое-то оборудование интересует, то пишите.
UPD : Да, еще забыл, что есть подход работы с оборудованием, как у того же АТОЛ с их ФР. Когда вешается рядом с оборудованием "служба/драйвер", который слушает HTTP запросы в JSON API и шлет уже по своему протоколу на оборудование. Вот пример такого API : https://app.swaggerhub.com/apis-docs/atol-dev/fptr-web-requests/1.0.4.0
И вот как вызовы в том же MyCompany сделаны : https://github.com/lsfusion-solutions/mycompany/blob/master/src/main/lsfusion/region/ru/retail/pos/cashregister/CashRegisterAtol.lsf
" Чтение веса в этом случае идет через Web Serial API " - тоесть, работает только в Firefox?
А общение с оборудованием через TCP/IP протокол как реализовываете?
" Чтение веса в этом случае идет через Web Serial API " - тоесть, работает только в Firefox?
Там если табличку посмотреть, то наоборот. Только в Firefox и не работает. Но обычно все у нас Chrome используют.
А общение с оборудованием через TCP/IP протокол как реализовываете?
Тут два варианта. Либо просто напрямую с сервера (при условии, что есть корпоративная сеть через VPN). Многие крупняки так и делают, хотя бы для удобства администрирования.
Либо, как я писал выше. Делается служба локально (не обязательно на каждом компьютере, достаточно в локальной сети), а потом с ней идет общение, например, через HTTP, а она уже шлет по TCP/IP.
Вообще, я думаю в следующей версии просто электрон можно подключить. Это собственно универсальный способ решить проблемы с оборудованием при клиенте "под браузер".
Первое, что я хочу сказать, если вы ищете именно ERP-систему, далее можете даже не читать. lsFusion ERP вам не подойдет, так как там вообще нет производства, это система для управления розничной торговлей.
Это утверждение на мой взгляд не корректно по двум причинам.
Во-первых, автор, как мне показалось, рассматривает ERP системы ориентированные исключительно на производственные предприятия. Если это так, то это утверждение не верно. Обосную.
Концепция ERP и на ее основе информационные системы вначале 90 годов пришли на смену системам класса MRP, т.к. бизнес потребовал расширения круга решаемых задач планирования бизнес-процессов (БП). Остро востребованы стали задачи не только планирование запасов материалов для производства, но и планирование финансов и человеческих ресурсов.
Так сложилось, что на первом этапе ERP системы стали внедряться на заводах и фабриках, выпускающих технические изделия: автомобили, самолеты и др. И само название ERP (управление ресурсами предприятия) в какой-то степени это отражает. Но шли годы и эти системы «обрастали» средствами информационной поддержки различных БП деятельности компаний: маркетинга, транспортного хозяйства, адресными хранением на складах, электронной коммерции, бизнес-анализа и много другого. ERP системы стали внедрятся в банках, организациях государственного управления и в других отраслях, где ВООБЩЕ нет производства, но успешно используются ERP системы. Поэтому очевиден вывод, что ERP системы — это системы не только для производства, а может быть и не столько для производства.
В конце 90 годов в России ERP системы стали внедряться в ритейле. Мне пришлось в свой трудовой деятельности это наблюдать и участвовать. Помню в конце 95 года первое появление на рынке России системы класса ERP. Это была презентация SAP/R3 еще на немецком языке в ТД ГУМ в Москве.
Опыт внедрения систем класса ERP в ритейле показал, что бизнес-процессы в розничных сетях оказались намного сложнее, чем в производственных компаниях. Это в первую очередь связано с сетевой организацией бизнеса и очень высокой трансакционностью процессов. ERP оказались не готовы для ритейла и не только в РФ. Свидетельство тому явились покупки крупными мировыми вендорами SAP, Oracle и Microsoft компаний, которые специализировались на автоматизации в ритейле. Цель этих поглощений - «встроить» технологии продуктов этих компаний в свои флагманские решения. В полной степени это не удалось и по сей день и поэтому до сих пор остается место для компаний специализирующихся на автоматизации БП в цепи поставок сетевых торговых компаний.
Можно найти много примеров, когда в ИТ ландшафте компаний, наряду с ERP системами отдельно могут присутствовать, например, системы класса BPM для стратегического финансового планирования и бюджетирования, бухгалтерские пакеты, решающие задачи финансового блока, системы бизнес-анализа всех аспектов деятельности и др. Это говорит о том, что ERP системы не могут лучшим образом обеспечивать решение задач управления БП, для которых они предназначены.
Вторая причина в некорректности утверждения автора касается функциональности системы в части автоматизации производства. В сетевой рознице есть БП, связанные с производством. Зайдите в гипермаркет, и Вы увидите кулинарию собственного производства, кафе внутри торгового зала, выпечку хлебных изделий. Могу утверждать, что от системы автоматизации в ритейле требуется не меньший функционал для управления производством, чем на производственных предприятиях.
Из вышесказанного, мне представляется, что термин «ERP система» сегодня потерял строгое определение, а также неоднозначен состава требуемых функций в системе данного класса для достаточной информационной поддержки управления БП в компаниях.
Поэтому употребление термина ERP в названии продукта на мой взгляд не является большой ошибкой, а может и вообще таковой не является.
После написания своего комментария я решил еще раз повнимательнее ознакомиться с содержанием функциональных модулей системы lsFusion ERP на сайте продута https://lsfusion-erp.com/modules.html .
Вполне обширная функциональность. Есть модуль взаиморасчетов с поставщиками и оптовыми покупателями. Этот инструмент вполне можно рассматривать как элемент финансового планирования. Модуль «собственное производство» - здесь все необходимое для учета производственных процессов. Есть блок анализ розничных и оптовых процессов сбыта, причем для розничных продаж все необходимое для персонифицированного маркетинга. Да, очевидно позиционирование продукта на ритейл. Но не вижу причин не отнести эту систему к классу ERP.
Белый поиск по вакансиям по этой системе практически ничего не выдал. Плохо ищу?
Что такое lsFusion: взгляд со стороны