Вот не знаю… я попробовал Flutter…
Первое впечатление действительно можно писать сложный UI, насыщенный «рюшечками» намного проще чем на java ,kotlin, радует то, что код не разнесен по файлам(xml представление и логика в java файлах) с другой стороны… памяти в смартфоне он забирает в 10 раз больше.(Обычное тоже самое на java 5-10 мб Во flutterr начиная с 60м и притормаживает…
сам размер apk(Примитивного приложения flutter) тоже внушительный от 25мб… Компилируется и собирается намного дольше java.
И попробовал скомпилировать и запустить, что-то посложнее из примеров startflutter.com/?utm_source=medium&utm_medium=article&utm_campaign=blog
И тут же «уперся рогом» в зависимости новых и старых версий пакетов,- и так не завелось.(Написал разработчикам пока без ответа)
Скажите,- тэг метки ведь должен быть в конечном итоге «строка»…
А это 62 00 51 79 17 19 00 04 05 60 5b 28 не совсем можно перевести в читабельную строку(например символы 00 04 05)?
Это у Вас статистика из телевизора?… или из опыта?.. Из моего опыта(а я занимаюсь автоматизацией, в том числе магазинов),- «немеряно» магазинчиков алкогольных закрылось или закрыли алкогольный отдел или «стали под чужую лицензию»(есть и такая схема)
Вообще конечно, это ужасно… конечно, если есть две базы «по одной и той же логике», то однажды между ними будет расхождение… и это не от того, что кто-то нарушает.
От идиотизма начинаешь уставать… Мы берем все приходные от егаиса,- автоматиом в декларацию… в конце квартала надо не забыть запросить остатки по егаису.(Он(api егаиса) не имеет данных на дату, а только текущие… Вливаем эти остатки в декларацию и прикинте… рассчитываем реализацию(Путем разницы двух множеств)… таким образом имеем Остатки егаиса=декларации… Никто к нам не придалбывается.(А в жизни остатки совсем могут быть другими)
И внимание вопрос… нафига мне этот геморой… программировать этот гребанный алгоритм расчета реализации.(где остатки и приход являются проверяемой константой.)
Добрый день… Вот Вы написали
Общение с POS-компьютером реализовано по протоколам TCP/IP или HTTP, в зависимости от настроек в веб-интерфейсе, через порт USB Type-B с использованием технологии USB over Ethernet.
— Вообще это довольно круто(TCP/ip и особенно как почти rest HTTP), ибо это низкоуровневые байтики гоняем по rs-232.
Скажите а какие модели ФР пользуют Ваш «rest-движок»?(Там наверху был штрих, но у него обычный протокол rs-232)
Но тут же не понравилось «через порт USB Type-B с использованием технологии USB over Ethernet.»… Это если ВЫ думаете что POS системы делаются только на винде.У меня POS системы на линуксе(и на винде тоже могут работать (кроссплатформенные), но флагман линукс)… ТО что я видел USB over Ethernet. не поднимается на линуксах… либо работает не удовлетворительно.
>> итого с ФНом около 1000-1300р в мес, если бизнес не окупает этих расходов, может ну его?))) )
— Как может это восприниматься нормально!!!!.. Да ещё рассуждать да ну его… станете предпринимателем поймете.
Да как же менталитет то испорчен… как можно вообще такое «ляпнуть»… да это же уже холопство на подсознании(Ну оброк вместо налога… ну и что… привыкли уже)… Законодательство надо выполнять… но и оно в свою очередь должно быть без оброка и барщины… Рашка так и из крепостного права не выбралась…
Я обслуживаю мелкий и средний бизнес… и никто не будет на каждую кассу ставить этот гребанный аппарат.(Моя ИС позволяет печатать с нескольких касс на один ФР)… И поставят один на магазин, Именно потому что это оброк., а не потому что финансы не позволяют.
Да свре ПО переписать это раз плюнуть… у меня кроссплатформенная ИС… И используются естественно кросс платформенные свои драйвера… а поскольку большинство производителей ккт обычно знают только винду, и выпускают драйвере только к ним, это вызывает проблему… как минимум надо исследовать низкоуровневый протокол… договориться… взять аппарат с новой прошивкой… у некоторых криворуких производителей надо поставить эмуляцию ФН… без него нельзя протестировать.(И это все реально начинает За###ть)
На мой взгляд нельзя интегрировать учетную систему с ЕГАИСом… Эти базы должны идти своим путем хотя бы потому что нет ключа синхронизации… один и тот же штрихкод может иметь несколько кодов ЕГАИС и наоборот.Я видел кривые решения по таблице соответствия но… они ещё больше запутывают… У меня в рознице разделено управленческий учет а ведём по штрихкоду… и отдельный в ЕГАИСЕ По марке (из которой просто вычисляем код ЕГАИСА(если однотипная продукция и мы получили код то не надо было пикать все марки, а просто ставим количество))… Раз в период проводим инвентаризацию по штрихкодам для управленческого учета и отдельно для егаисного.Кстати имеем потенциальную проблему… ибо марку они поменяют… и в ней не будет кода егаиса… Ну тогда и поменяется парадигма(техническая философия) учета.
Вы знаете, в таком виде ЕГАИС 3 работать не будет… А будет работать когда они сделают RFID акцизную марку… У меня есть ряд проектов на RFID метках… инвентаризация проходит… поставили посреди зала антенну… и всё!!!!.. Так же и тут… навели параболическую антенну на фуру с алкоголем(Или фура проехала в антенные ворота)… и одним махом всё считалось… сверяем поставку с егаис.
Логи то у меня все есть к этим сбойным базам(Обслуживаю около 40 егаис клиентов )… Но Вы поймите, это мелкий и средний бизнес… им некогда со всеми этими волчьими ямами ещё и расписывать всё… сделали инвентаризацию по егаису и всё…
А как Вам такой случай… продается продукция… и получаем оттиск что проверка не пройдена.(естественно это всё в логах зафиксировано)… Делаем разбор полетов с поставщиком… оказывается эта марка на этом магазине была всё же продана.Просто УТМ (2.05 версия)косячил с многопоточностью и создавал несколько request потоков(а логи УТМ это темный лес)… дата центр фиксировал марку… а на остальные потоки на ту же марку отвечал отказом и этот отказ УТМ возвращало мне в систему, хотя в дата центре всё верно фикисровалось.(Случаи не частые но они были… и тоже зафиксировано в логах)… в версии 2.1.6… Они этот косяк решили следующим образом… они поставили паузу около 30 секунд… т… е с интервалом менее 30 секунд Вы можете продать одну и ту же марку. (Был один случай у продакшн клиента и проверялось в тестовом контуре)
Вот ваша реплика…
. В случае с ЕГАИС проще всего продемонстрировать физическую невозможность в тот или иной момент отразить реальные остатки в системе – отсутствие доступа к сети интернет,
— Вот например были такие случаи(причем неоднократно)… И все На стыке смены гостовcкого ключа или PKI… УТМ подписывает дает оттиск… а дата центр егаиса уже не принимает пишет неверный soap заголовок.(типа расшифровать в общем не может)… У нас накопилась база подписанных но не отправленных чеков… через три дня… УТМ стал.Удаляем папку с базой данных Derbydb. УТМ стартует создает новую чистенькую свою базенку… Данные уже отправляться… У меня уже целое «кладбище» копий таких мертвых баз, к которым нет доступа (архитектор ЕГАИСа позаботился… с какой то версии derbydb все зашифровано.)
:-) Никаких статья исчерпывающая… Вы пишите о законах что касаются ИТ… и они идут «рука об руку» с низким качеством этого самого ИТ. как те понятые, что ходят парой. :-)
Вы так и не поняли(видимо привычка к низкому качеству сказывается...), что такой ситуации не могло быть в принципе…
Вот менталитет «Любой мало-мальский сотрудник, который умеет обращаться с ПК»… Да я уже запарился исправлять… то ошибки егаиса(джакарата воообще после года глючит неподетски… её надо на рутокен менять)… ошибки самого УТМ… ошибки онлайн касс. выходы из строя самих аппаратов (то ножи заклинят, то ФН сломался то процессорный блок)
Поэтому и спутники запускаются в сибирь и в океан вместо космоса.
Вот я только пришел и сразу всё понял… В росии рулит большой бизнес и все ложатся под него… Законы издаются так, чтоб большой бизнес мог заработать, как и этот закон об онлайн кассах.(ведь можно не менять ФН… можно напрямки сдавать в налоговую минуя(офд) такого себе «кунака влюблённого джигита»).Например закон ещё не был утвержден а атол уже выпустил эвотор(и кто тут лобист)… Вот большой бизнес и не пустит качественный продукт на внутренний рынок.
Никого не интересует процесс(ОФД… ККТ, Прошивка) всех интересует результат… глюк прошивки… я про такой термин только тут узнал.
И ко всем аппаратам есть «предъявы.» Никто из аппаратов не работает с наработкой на сбой как термопринтер(Корейский).( а должно работать именно так… и видел, что такая наработка на отказ и сбой возможна… причем в финансово бедной стране… просто мозги правильно сидят)
Вы знаете всё относительно(и так получилось, что мне есть с чем сравнить(Как Украина это делала и как Россия))… Я как и положено вендору ПО веду реестр инцидентов… так вот по аппаратам России он просто зашкаливает… я никогда не думал, что фискальные аппараты могут быть настолько глючными. Очень низкая наработка на сбой и на отказ… Вам просто не с чем сравнить и просто уже привыкли к низкому качеству.
Если не удаляется… Тогда это ещё больший технический оверхед.
И так чеки хранятся в датаценте ОФД… хранятся в налоговой… и аля ЭКЛЗ хранится ещё и в ФН аппарате… неудивительно, что всё глючит.
ФН нужен когда нет интернета… Тогда оно туда пишется… а когда интернет появлятся он «испражняется». :-) В моем опыте было так на маленьком объекте что то сбился интернет и фискалка остановилась(По причине заполненности ФН) через 1.5 месяца… и на большом было… через 10 дней стало.
Первое впечатление действительно можно писать сложный UI, насыщенный «рюшечками» намного проще чем на java ,kotlin, радует то, что код не разнесен по файлам(xml представление и логика в java файлах) с другой стороны… памяти в смартфоне он забирает в 10 раз больше.(Обычное тоже самое на java 5-10 мб Во flutterr начиная с 60м и притормаживает…
сам размер apk(Примитивного приложения flutter) тоже внушительный от 25мб… Компилируется и собирается намного дольше java.
И попробовал скомпилировать и запустить, что-то посложнее из примеров
startflutter.com/?utm_source=medium&utm_medium=article&utm_campaign=blog
И тут же «уперся рогом» в зависимости новых и старых версий пакетов,- и так не завелось.(Написал разработчикам пока без ответа)
А это 62 00 51 79 17 19 00 04 05 60 5b 28 не совсем можно перевести в читабельную строку(например символы 00 04 05)?
От идиотизма начинаешь уставать… Мы берем все приходные от егаиса,- автоматиом в декларацию… в конце квартала надо не забыть запросить остатки по егаису.(Он(api егаиса) не имеет данных на дату, а только текущие… Вливаем эти остатки в декларацию и прикинте… рассчитываем реализацию(Путем разницы двух множеств)… таким образом имеем Остатки егаиса=декларации… Никто к нам не придалбывается.(А в жизни остатки совсем могут быть другими)
И внимание вопрос… нафига мне этот геморой… программировать этот гребанный алгоритм расчета реализации.(где остатки и приход являются проверяемой константой.)
Общение с POS-компьютером реализовано по протоколам TCP/IP или HTTP, в зависимости от настроек в веб-интерфейсе, через порт USB Type-B с использованием технологии USB over Ethernet.
— Вообще это довольно круто(TCP/ip и особенно как почти rest HTTP), ибо это низкоуровневые байтики гоняем по rs-232.
Скажите а какие модели ФР пользуют Ваш «rest-движок»?(Там наверху был штрих, но у него обычный протокол rs-232)
Но тут же не понравилось «через порт USB Type-B с использованием технологии USB over Ethernet.»… Это если ВЫ думаете что POS системы делаются только на винде.У меня POS системы на линуксе(и на винде тоже могут работать (кроссплатформенные), но флагман линукс)… ТО что я видел USB over Ethernet. не поднимается на линуксах… либо работает не удовлетворительно.
— Как может это восприниматься нормально!!!!.. Да ещё рассуждать да ну его… станете предпринимателем поймете.
Да как же менталитет то испорчен… как можно вообще такое «ляпнуть»… да это же уже холопство на подсознании(Ну оброк вместо налога… ну и что… привыкли уже)… Законодательство надо выполнять… но и оно в свою очередь должно быть без оброка и барщины… Рашка так и из крепостного права не выбралась…
Я обслуживаю мелкий и средний бизнес… и никто не будет на каждую кассу ставить этот гребанный аппарат.(Моя ИС позволяет печатать с нескольких касс на один ФР)… И поставят один на магазин, Именно потому что это оброк., а не потому что финансы не позволяют.
А как Вам такой случай… продается продукция… и получаем оттиск что проверка не пройдена.(естественно это всё в логах зафиксировано)… Делаем разбор полетов с поставщиком… оказывается эта марка на этом магазине была всё же продана.Просто УТМ (2.05 версия)косячил с многопоточностью и создавал несколько request потоков(а логи УТМ это темный лес)… дата центр фиксировал марку… а на остальные потоки на ту же марку отвечал отказом и этот отказ УТМ возвращало мне в систему, хотя в дата центре всё верно фикисровалось.(Случаи не частые но они были… и тоже зафиксировано в логах)… в версии 2.1.6… Они этот косяк решили следующим образом… они поставили паузу около 30 секунд… т… е с интервалом менее 30 секунд Вы можете продать одну и ту же марку. (Был один случай у продакшн клиента и проверялось в тестовом контуре)
. В случае с ЕГАИС проще всего продемонстрировать физическую невозможность в тот или иной момент отразить реальные остатки в системе – отсутствие доступа к сети интернет,
— Вот например были такие случаи(причем неоднократно)… И все На стыке смены гостовcкого ключа или PKI… УТМ подписывает дает оттиск… а дата центр егаиса уже не принимает пишет неверный soap заголовок.(типа расшифровать в общем не может)… У нас накопилась база подписанных но не отправленных чеков… через три дня… УТМ стал.Удаляем папку с базой данных Derbydb. УТМ стартует создает новую чистенькую свою базенку… Данные уже отправляться… У меня уже целое «кладбище» копий таких мертвых баз, к которым нет доступа (архитектор ЕГАИСа позаботился… с какой то версии derbydb все зашифровано.)
Вот менталитет «Любой мало-мальский сотрудник, который умеет обращаться с ПК»… Да я уже запарился исправлять… то ошибки егаиса(джакарата воообще после года глючит неподетски… её надо на рутокен менять)… ошибки самого УТМ… ошибки онлайн касс. выходы из строя самих аппаратов (то ножи заклинят, то ФН сломался то процессорный блок)
Поэтому и спутники запускаются в сибирь и в океан вместо космоса.
И ко всем аппаратам есть «предъявы.» Никто из аппаратов не работает с наработкой на сбой как термопринтер(Корейский).( а должно работать именно так… и видел, что такая наработка на отказ и сбой возможна… причем в финансово бедной стране… просто мозги правильно сидят)
А насчет глюков то случай 20-21 декабря 17 года… когда все штрихи и им подобные встали… вопиющий случай… Вы не слышали… или даже не заметили
retailer.ru/generalnyj-direktor-dns-dmitrij-alekseev-vcherashnij-sboj-v-rabote-kassovoj-tehniki-ne-sluchajnost
И так чеки хранятся в датаценте ОФД… хранятся в налоговой… и аля ЭКЛЗ хранится ещё и в ФН аппарате… неудивительно, что всё глючит.