Comments 262
Чеки коррекции — это такие штуки, которые позволяют проапдейтить уже выданные чеки с некоторым бухгалтерским геморроем, но зато хоть как-то. То есть не тонна бумажек и объяснительных на каждый чек, а сравнительно серийная процедура.Т.е. покупатель проблемы не заметит, но это геммор именно для бухглатерии?
Такое решение где-нибудь было применено или вы всё же самые крутые ребята и успели всё быстро починить?
Но при восстановлении кассы все чеки нужно выбить. Правильно выбивать чеки, используя механизм «чек коррекции».
Покупатель уйдёт без чека.Вот об этом и вопрос… А как же возврат и гарантии? Или всё на доверии?
Меня бы смутило, как покупателя, что мне чек не выдают… (мало ли какие бумажки ФНС)
Да, мы были неготовы к тому, что все кассы могут взять и отказать. Потому что подготовка — она явно дороже возможного простоя. Но ИТ-отдел решил всё быстро, и это хорошо. Рядом другая сеть нашего сегмента ещё не открылась вообще, к примеру.
Ты там спал вообще?А ты не робот? Или… на всякий случай: Cколько пальцев у меня за спиной?
:)
Спать… вышло-то удачно… или нет?
Рядом другая сеть нашего сегмента ещё не открылась вообще, к примеру.
То есть, Мосигра по итогам дня в плюсе? Хм…
Не забудьте премии айтишникам сообразить =)
В час ночи по Москве во Владивостоке отказали кассы
в 9 утра по Москве, прошивка уже была доступна с инструкцией на их форуме
наши точки… поднялись через 40 минут после выявления бага.
вы пофиксили багу до выхода прошивки, или я чет не понял просто?
Предположим разъяснения бы не поступило, что бы изменилост? как иначе выплывали бы из ситуации?
Просто как-то странно, что у всех стоял автоапдейт на кассах! в рознице!
В крупных компаниях и на windows то без тестирования не накатывают, даже после тестирования апдейты не прилетают всем сразу, у нас обычно первыми апдейты ловили мы в IT департаменте, причем по очереди. А розница и склады у нас вообще были последними по апдейтам.
Если бы было включено...
На РБК в новости есть комментарий, что если на кассе было включено автообноовление, то сбоя не было. Автообновление по умолчанию выключено на уровне заводского конфига.
Но идея с другим репозиторием — хорошая. Можно включить автообновления, настроить на свой репозиторой, в который включать только проверенные обновления. Вот только не знаю можно ли так.
Прошивка обновляется с нашего сервера, т.е. IP адреса зашиты в прошивке, поднять свой FTP, выкладывать туда прошивки и обновляться оттуда не получится. forum.shtrih-m-partners.ru/index.php?PHPSESSID=rurrk0gm1uejmone31dkesra44&topic=32987.msg144443#msg144443
Черт с ним, ну не хотят они работать с энтерпрайсом как все. Пусть будет хардкод. Это конечно глупо звучит и не совсем правильно, но я бы жестко сроутил их IP на свой сервер и раздавал бы прошивки с него, если конечно там простой FTP, TFTP, HTTP без проверки сертификатов.
Ну или в крайнем случае подключил бы к касам MOXA nPort и обновлял бы через COM после нормального теста, но это добавит лишние 50-100(не знаю сколько сейчас они стоят) долларов к стоимости места кассира.
Я не сетевик, хоть и связист. В моем представлении проще прописать жесткие маршруты на 30ые подсети поднятые во внутренней сети.
На самом свежем оборудованиb думаю еще проще сделать можно было бы.
1) Ваш — поставить свой сервер, заставить его откликаться на зашитый адрес и добавить маршрутизацию на него. При этом придётся поднять туннели до локальной сети, в которой живёт этот сервер — ведь провайдеры о том, что пакеты нужно пересылать в вашу сеть, а не на оригинальный сервер не знают.
2) splav_asv предлагает вмешаться в трафик, подменив адрес (чем-нибудь типа snat) на фаерволле/граничном роутере. При этом на самом сервере ничего не требуется делать, да и маршрутизация у провайдера в таком случае вас уже не волнует.
Я как бы подразумеваю, что есть локальная сеть. Оба варианта сводятся к вопросу «а как выходим в интернет?». Поскольку в обоих случаях нам придется либо настраивать все на ядре, либо на каждой торговой точке.
Но splav_asv все-таки более правильный, с точки зрения сети, вариант предложил. Негоже такой костыль (жесткий роут белого адреса) в своей сети выстраивать.
Получается — оба решения сводятся к одному и тому же и какое из них выбрать — вопрос вкуса.
Баг был в прошивках, вышедших с июня (или мая?) по декабрь. Мартовские прошивки работали.
Проблема в том, что в то время было много багов и глюков в прошивках, и поэтому большинство обновлялось.
А насколько было бы проще, активировали автообновление на свой сервер и на него выкладывать апдейты проверенные у вас на стендах и тестовых магазинах.
Даже в этой ситуации, у вас был активирован автоапдейт и все, что нужно было для исправления ситуации — это положить исправленную прошивку на сервер и передернуть кассы.
ЗЫ. Задним умом крепки все…
Хорошо что хоть не в пятницу… перед новым годом.
Спасибо за пост. Пойду чинить.
Удачи 30 и 31. Если не привезут мне из UGear подарок для ребёнка, пойжу к вам стоять в очередь в три петли.
Зато утром первого января приходят совершенно очаровательные люди. Продавцы в магазинах по ним гадали в том году — было важно, какую игру купят в магазине первой за год.
Дада, цто не нужно, я сделаю все сам. Торговый объект #1 после перепрошивки и в путь. Завтра постараюсь расписать как это видели большинство цто по стране, после работы "самоделкиных".
Нет, и что? Речь шла про "мою халтуру" и то что на момент написания комментария "у меня лежит 22 кассы снятые с точек", вместо быстрого решения проблемы на месте.
С утра повалились поломки и банально почитать интернет было некогда, с самого утра информации о быстром ремонте не было.
Да считаю. Информация была. Уже на 05:20 МСК была доступна прошивка исправляющая проблему.
Хех, судя по комментам на форуме предположу что у подрядчиков обидели программистов.
А вообще за такие законы о торговле и требование использовать их зарытую хрень нужно ФНС руки оторвать.
Дело не в закрытой хрени.
В данном случае в закрытом протоколе и одной программе — поэтому легли все сразу.
никак, просто проблема была бы гораздо менее маштабной
При хоть сколько открытом протоколе, это никак бы не помогло не сотворить ошибку в коде.
Да, я понимаю, но из-за искусственно созданной олигополии получился достаточно широкий охват. Такая-же ситуация получится с 1С или с ошибками в windows, фигово вобщем, ладно, забейте.
Ну а ваш вопрос был про законность снятия с гарантии.
К сожалению, работало это только на тех интерфейсах, где кабель был COM 9pin — COM 9pin. На всех остальных кассах подключения к компьютерам просто не было. Потому что довольно тяжело найти компьютер с COM 25pin, например.
Не понял, в смысле Штрихи идут с 25pin? Ну это повод оборудовать рабочие места переходниками 25 на 9. А на материнках COM-порты существуют повсеместно, вот только не выведены обычно. Или у вас используются не стандартные системники, а неттопы и прочее?
Так кассы у вас к этим ноутбукам не подключены, вы хотите сказать? Или подключены по USB, а по нему обновление прошивки недоступно? А через usb-com переходник, о котором вы, кстати что-то писали?
А должен был "канать". Я бы вам рекомендовал поискать переходники, которые будут работать с этой задачей (в основном проблема с драйверами там, и на каком уровне эмулируется COM порт), и запастись на будущее, чем черт не шутит :)
Если прокинуть com-порт в них (даже не помню, возможно ли это)
возможно ) прокидывал в VirtualBox 5.1.26, хост — Linux Fedora 25, виртуалка — Windows 7
По-настоящему его похоронили производители материнских плат которые перестали предусматривать на них COM- и LPT-порты. Как пришлось выбирать между поиском раритетных карт расширения для PCI и покупкой куда более распространенных переходников USB-COM/USB-LPT — так даже динозавры поняли что и правда пора учить правильные способы работы :-)
Есть, привет unixtime.
Почитайте как хранится тег 1012 в ФН. ККТ пыталась прочитать время последнего документа после открытия смены и спотыкалась на преобразовании в календарное время того что хранится в ФН, все это подвисало, срабатывал сторожевой таймер и циклический ребут....
А что за волшебное значение вызывало такое поведение? Там ведь никакие не единицы вроде и не переполнения, если именно unixtime. Или там хранится не совсем unixtime?
Значение совершенно обычные. Проблема в конкретной реализации time.h и как пример в time_t mktime(struct tm *p), то что приехало на вход, на выходе получилось не таким как ожидалось...
Вы можете самостоятельно поинтересоваться у компетентных сотрудников производителя, или вы хотите ревёрсинг прошивки в комментариях?
Если нет, то что мешает вам рассказать наконец-то что там было?
Непосредственно для вас, да.
Ок, как по вашему должен выглядеть ответ на данный вопрос? Кусок кода закрытой и защищенной производителем прошивки? Нет, этого не будет, можете расходится и не ждать. Если вас интересует "что такое надо сделать с датой", могу оставить ссылку на вопрос StackOverflow в котором проблема имеет такие же корни.
Ваши комментарии выглядят так, как будто бы вы знаете реальную причину. Комментарии автора так не выглядят.
Да и в общем-то даже со стороны понятно, что это что-то вязанное с датой, если сбои пошли по часовым поясам.
> Кусок кода закрытой и защищенной производителем прошивки?
Как правило, 10 строк погоды не делают. На худой конец можно дать словесное описание того, что произошло.
Единственная проблема — признание факта присутствия бага… Но этот факт подтверждён предпринимателями по всей России.
Но всё это имеет смысл только если вы имеете доступ к исходникам либо вы делали декомпиляцию кода. Ваши комментарии намекают именно на это.
> могу оставить ссылку на вопрос
Ок, спасибо. Это проясняет ситуацию хоть как-то.
Опять таки, хабр такой хабр… Автору поста в связи с его "высоким статусом" можно верить на слово, здесь же нам разжуйте и положите в рот, печально это.
Вкатали бы производителю иск. Желательно на все 10 млрд рублей потерь. Научились бы работать.
Ну да, и у производителей ответственного оборудования тоже — к примеру, систем вентиляции легких.
Факапы бывают у всех
И да, в том числе в сверхкритичных областях, где уровень тестирования и ответственности несоизмеримо выше. Я не защищаю косячников, но засудить Штрих вряд ли удастся, только если этим будет заниматься на сама ФСН. Уверен, вот перед налоговой обязательства как раз есть.
Если в этом преценденте никто иск не вкатает, то остальные и сам производитель будут тестировать еще хуже — ведь ничем не рискуют...
Начинать судить нужно с самой ФСН — она внесла продукцию Штриха в реестр. )
Экспертов назначает/выбирает/держит в штате ФНС.
https://www.nalog.ru/rn77/related_activities/registries/kkt/
Более справедливо (и полезно для бизнеса, наверное) было бы не просто создать приятный сегмент рынка для производителей этих касс (неплохо так им рынок на миллиарды создали), но и обязать их, если уж занимаются — компенсировать это. А то с одной стороны у нас свободы и либерализм (имеют право производить без гарантии, не надо кошмарить бизнес), а с другой — принуждение (попробуй-ка не купить эту кассу-сюрприз. захочет — будет чеки выбивать, захочет — будет играть веселые мелодии).
Но, кмк, при правильном подходе, мне кажется, после такого инцидента, стоимость страховки для этого вендора взлетела бы до небес, так как известно, что контроль качества ПО он не осуществляет, фактически это было бы равно закрытию бизнеса. После этого все прочие вендоры свои сорцы бы наизусть перечитывали, потому что в случае фейла, было бы не «ужас как неловко», а настоящий финансовый ущерб.
У меня в юношестве было странное ощущение (мне тема безопасности всегда была интересна), что, мол, это там где я работаю — бардак в плане надежности и безопасности, все «на скотче» как-то. Но, думал, в финансовых компаниях — все иначе совсем. А когда соприкоснулся по работе с финансовыми… Да нет, так же у них, такой же бардак. Только люди гораздо более безответственные. Потому что я считал, что бардак терпим только в нашей некритичной сфере, а в финансах он недопустим, а они считают, что и в финансовой сфере можно. Ничего страшного. Ну встала целая сфера розничной торговли по всей стране. Ну не могут автомобили заправиться. Ну… неловко. Извиниться нужно и все.
Но принудительная страховка хотя бы затормозит скатывание экономики в копрономику (я надеюсь, Вы в курсе, что это такое и как оно возникает).
пусть то же государство обязывает производителя этой хрени гарантировать качество путём принудительной подписки на страхование предпринимателя (страховать можно самостоятельно у себя или у сторонней страховой фирмы).
Да это же шикарная идея! )) Срочно в стартап! Сколько, интересно, будет стоить страховка при внедрении касс для ритейла, вроде этой же Мосигры? На сколько вырастет цена на дженгу? Чего далеко ходить, давайте тогда и эндюзеров винды страховать от блюскринов.
UPD. ARD8S опередил.
хозяевам каяться: «Виноват! Оплошал, не уберег добро, родные мои! Вертаю
средства, совесть не позволяет, раз оплошал!» — и благородно возвращал
деньги. Поскольку за зиму обычно обкрадывали только две-три дачи, то дядя
Коля не оставался внакладе.
Они свое уже и так заплатили без всяких штрафов.
Они потеряют заметную (не очень большую, но заметную) часть рынка просто потому что люди будут помнить о двадцатом декабря и слагать легенды.
Оно может и не факт что объективно, но многие эмоционально будут принимать решения против их предложений. Ну и часть да, начнет разводить зоопарк покупая часть касс конкурентов просто для разнообразия.
Всё.
Этого достаточно чтобы их наказать.
А большие наказания их могут просто убить.
Может и черт с ними, убьют и ладно.
Я не знаю специфику этого рынка. Может они и плохие игроки и их не жалко.
Не знаю.
Но ведь другим страшно будет.
Лезть будут или отмороженные, или те у кого крыша не протекает или те кто заметно взвинтит цену. Будут больше опасаться и все такое. После каждой ошибки будут вылетать из игры, так и не набрав опыта. Кому это выгодно?
Это то, с чем лично сталкивался. Наверняка и другие косяки были. И это после того, как в предотвращение проблемы вбухали просто-таки космические деньги!
Так разверните уж! Никто так и не понимает в чем тут оно!
Судя по описанию проблемы y2k на той же вики, стало понятно что тут как раз дело в этой unixtime. Скорее всего есть какая то зависимая дата от даты чека, например дата окончания хранения записи или что нибудь в это духе, которая при подсчете может переполнится.
Типа такой:
if(now >= '2017-12-20'){reboot;}
Но раз говорят что в налоговую приходил 2012 год. То скорее он, что то с форматом придумал/перепутал. Вместо DDMMYYYY использовал YYYYMMDD.
Инсайд подтвердил, что ошибку искусственно заложил увольняющийся программист.
Источник.
Карина, руководитель розницы и бывшая глава нашего ИТ-департамента, параноик.
Передайте Карине привет, мешок респекта и лучи уважения :)
// потому что параноиков никто никогда не слушает, но они всегда оказываются правы :)
потому что параноиков никто никогда не слушает, но они всегда оказываются правы :)
Разрулили, блин, оперативно. На Камчатке близилась полночь, вся страна до Урала перепрошивала изо всех сил фискальные регистраторы. ЦТО собирали от 500 рублей за перепрошивку. Люди не могли заправиться, т.к. Газпромнефть в Омске держит свой самый большой нефтезавод и заправки в городе процентов на 80 тоже принадлежат им. И тут ФНС в 20.12.2017 11:25 Москвы разрешило торговать без чеков. )
А ведь кто-то в этой самой ФНС не внес в реестр регистраторы Меркурия до 1 июля 2017, а регистраторы Штриха внес...
, причём не только на экране, но и с курьерами (позднедекабрьский день стоит летнего месяца не только у Мосигры, но и у гораздо. гораздо более крупных… алкольных например, а если ещё и нефтянка встала...). И, таки думаю, суровые разборки ещё предстоят, и достанется не только программистам, это не какой-то застрахованный спутник в море уронить…
Карине орден?
Срабатывать было нужно год-два назад прописывая в том же 54 ФЗ, что делать если:
- кассовый аппарат впал в кому по причине кривой прошивки/кривого фискального накопителя (когда починят неизвестно, но можно купить новый совсем не дорого)
- ОФД перестал выходить на связь (совсем)
- оператор связи перестал предоставлять связь (починят когда лед встанет/грязь просохнет)
Количество точек отказа для технически неподкованного индивидуального предпринимателя запредельное.
А обещали, что будет дешевле ЭКЛЗ… гы-гы-гы… ))
2. ДЦ налоговой, который она арендовала у ком.структур, ушел в оффлайн на два дня. По закону допускался один день без подачи отчетов, после второго дня остановилась работа как минимум в двух очень крупных торговых сетях. Никто не понес никакой ответственности, благо, что это произошло на этапе внедрения и эти две сети были первыми, кто перешел на новые кассовые аппараты.
3. Кассовые аппараты на этот случай шли с GSM-модулем.
Тут такая проблема. Поставили кассу помониторили пару дней все работает, чеки идут. А потом бац в один день касса превратилась в тыкву, т.к. 30 дней прошли. Почему она перестала ходить в сеть я так и не понял, есть версия, что во всем виноват gsm модем торчащий в компьютере — его переткнули в другой порт. Включить мониторинг у ОФД не вариант, нет там варианта по субботам и воскресеньям мы не работаем. Меня бы устроил вариант касса > 20 дней не выходила на связь, с возможностью выкидывать некоторые кассы, которые будут лежат в тумбочке больше 20 дней. Но такого нет.
Ну и за месяц ледовая переправа не появляется, т.е. паром ходить перестал, а лед еще не встал ну и наоборот. Тут в райцентр автобус весной и осенью часть трассы трактором тащат — это Россия. Мост смытый в прошлом году восстановят в следующем. Вы по прежнему уверены, что связь восстановят быстро? )
Что же касается онлайн-ККТ, предназначенных только для расчетов в сети Интернет (кассы для Интернет-магазинов), то тут два способа мониторинга:
- Мониторить личный кабинет на сайте ОФД
- Написать робота, который будет с некоторой периодичностью опрашивать ККТ на предмет неотправки фискальных документов
Резюме
Это всё очень круто, потому что мы в стране наконец-то отказались от устаревшего носителя, плюс получили возможность проверять всё онлайн. Да, проблемы при внедрении есть, но в целом — оно того стоит.
Кто ж мог предположить, Сергей )) Не подумайте, не злорадства для.
После этого «Штрих» пошел на беспрецендентный шаг: фискальники, на котором диагностировали такую неисправность ремонтировались бесплатно (даже с истекшим гарантийным сроком).Беспрецедентный разве что для «Штриха». Почитайте ленту новостей: автопроизводители регулярно бесплатно разные вещи меняют. Ну и Сматрфоны всякие
Было бы интересно узнать первопричину.
PS. У нас по области более 100 штук атоллов. Надо начальству сказать, чтобы хоть пару десятков штрихов закупить для ЗиП.
У атолла (по крайней мере у нас) недавно был другой косячек. Кассы отказались работать когда пропал доступ к серверу офд. К счастью, доступа не было не больше часа. Почти никто этого не заметил.
Насчет 1С не знаю, а вот с самописными системами не должно быть сложно, если разработчик работает в тех. отделе, а не на аутсорсе. Поддержка возможности работать с несколькими устройствами — достаточно дешевая, при более-менее грамотном подходе к разработке ПО.
Ну и в "наливку" кассовых ПК включить драйвера для обоих устройств.
На базе Эльбруса и нанотехнологий, например.
Там тоже в онлаин режиме в налоговую чек шлют? Кто-то сталкивался?
В Чехии шлют. EET называется.
Так как "сорт оф" работаю с этим — в ЕС стандартизации нет на эту тему, отдельные решения по странам, например в Греции при печати чека на нем должна быть фискальная спец-строка, которую (упоротый и кривой) софт установленный на перехват печати ловит, валидирует, отсылает кудато-там а на чек вместо этой строки ставит снизу спец-подпись (сколько мы наплевались с хромом, который выводя чек на печать из браузера перегонял его в растр и софт не мог поймать фискальную строку...).
у нас по регламенту из МСК, мы обязаны обновлять FW до самой актуальной, но кто-то не заложил бапки на апгрейд и нас эта проблема обошла стороной =)
Вывод один, НЕ обновляться автоматически
Наоборот, обновление спасло бы:
На РБК в новости есть комментарий, что если на кассе было включено автообноовление, то сбоя не было. Автообновление по умолчанию выключено на уровне заводского конфига.
Но однозначного ответа (обновляться/не обновляться) нет. В этой ситуации автообновление было благом, в другой станет багом…
вручную обновлять только после тестирования в лабораторных условиях, потом на мелком магазине с небольшим оборотом
Вот поставили вы обновление в мае на тестовую кассу. Полгода тестировали — все нормально. Еще полгода протестировали на небольшом магазине — все нормально. Распространяете обновление на все кассы. И через неделю все ложится т.к. наступил очередной Y2K. Тестирование может показать только наличие дефектов, но не их отсутствие. Все возможные случаи протестировать также невозможно. Особенно учитывая, что тестировать вы будете черный ящик без знания конкретных спецификаций. Так что лично мне такое кажется лишней тратой денег. За те же деньги — лучше иметь ККТ нескольких производителей, чтобы при факапе на одном — можно было продолжить работать на другом.
И через неделю все ложится т.к. наступил очередной Y2K.
Против этого спасла бы текстовая касса работающая на месяц впереди всей остальной планеты. Точнее N тестовых класс под каждую модель и параметр настройки.
Все возможные случаи протестировать также невозможно.
Возможно протестировать до 99.999999....9%, просто очень дорого.
кажется лишней тратой денег.
Это вообще задача производителей, а не пользователей. Кстати, интересно страхуют ли страховые такие случаи, по идее должны.
Против этого спасла бы текстовая касса работающая на месяц впереди всей остальной планеты.
Или не спасла бы, если бы ошибка проявлялась только если дата на кассе и на сервере одинаковая, а на настроенной на месяц вперед все было бы нормально.
Точнее N тестовых класс под каждую модель и параметр настройки.
Допустим 12 моделей на каждой от 5 до 17 параметров, которые могут принимать от 2 до 80 предустановленных значений, часть полей — строки, часть целочисленные, часть — с плавающей запятой. Вопрос — сколько тестовых касс нужно будет и сколько тестовых случаев на каждой из них?
Возможно протестировать до 99.999999....9%, просто очень дорого.
Ну как я и сказал «Все возможные случаи протестировать также невозможно.» Немножко дополню — кроме некоторых тривиальных случаев типа «Hello World». А кроме того — долго. И все равно не гарантирует отсутствия дефектов.
Это вообще задача производителей, а не пользователей.
Так производители и тестируют. Для сведения — задач тестировщика — не выловить все баги, т.к. это невозможно по определению. Задача тестировщика — доказать, что продукт соответствует поставленным требованиям(ТЗ), если он соответствует. Ну или завести задачи на исправление поведения продукта. Другое дело, что дефекты могут быть обнаружены на этапе составления ТЗ, и это заметно удешивит стоимость их исправления. Но не исключит их совсем. А тестировать самим все возможные случаи не зная спецификаций и ТЗ — я считаю лишней тратой денег, это называется exploratory testing и применяется не часто, т.к. в большинстве случаев его эффективность низка. Дефекты таким методом можно найти только случайно. Лучше их потратить на обеспечение отказоустойчивости иными методами, как я писал выше, к примеру — закупкой ККТ разных фирм.
Или не спасла бы, если бы ошибка проявлялась только если дата на кассе и на сервере одинаковая,
Ну так сервер тоже должен идти вперед на месяц. С точки зрения той кассы все должно существовать в будущем.
Допустим 12 моделей на каждой от 5 до 17 параметров, которые могут принимать от 2 до 80 предустановленных значений, часть полей — строки, часть целочисленные, часть — с плавающей запятой. Вопрос — сколько тестовых касс нужно будет и сколько тестовых случаев на каждой из них?
А зачем? Какие параметры так жизненно необходимы для касс, что не могут быть общими для всех или почти всех пользователей модели?
Все возможные случаи протестировать также невозможно
Возможно, существует формальное мат.доказательство корректности алгоритма, просто каждая строчка кода становится золотой и сложность такого тестирования увеличивается в прогрессии.
Для сведения — задач тестировщика — не выловить все баги, т.к. это невозможно по определению
Возможно, просто очень дорого.
Немножко дополню — кроме некоторых тривиальных случаев типа «Hello World». А кроме того — долго. И все равно не гарантирует отсутствия дефектов.
Ну так можно прикрыть любую безалаберность, зачем заботиться в безопасности ядерных станций, космических аппаратов, самолетов и автопилотов машин, если вы все равно не сможете поймать все дефекты? Вы готовы жить с ядерной станцией построенной по такому принципу? Или все таки процент имеет значение?
А зачем? Какие параметры так жизненно необходимы для касс, что не могут быть общими для всех или почти всех пользователей модели?В случае если это закладка, как говорят? Абсолютно любые.
Ну так можно прикрыть любую безалаберность, зачем заботиться в безопасности ядерных станций, космических аппаратов, самолетов и автопилотов машин, если вы все равно не сможете поймать все дефекты? Вы готовы жить с ядерной станцией построенной по такому принципу?А вот собственно поэтому инженеров дрючат куда сильнее, чем каких-нибудь финансистов.
Потому как если финансист напортичит — ну обанкроится какая-нибудь Nokia, люди себе другую работу найдут, делов-то. А если ядерный ректор рванёт или, банальнее, плотину смоет — то это тысячи, а то миллионы, человеческих жизней.
Кассы всё-таки ближе к финансам…
В случае если это закладка, как говорят? Абсолютно любые.
Тогда тем более кол-во разных параметров должно быть минимальным.
Потому как если финансист напортичит — ну обанкроится какая-нибудь Nokia, люди себе другую работу найдут, делов-то. А если ядерный ректор рванёт или, банальнее, плотину смоет — то это тысячи, а то миллионы, человеческих жизней.
Кассы всё-таки ближе к финансам…
Ну в начале прошлого века обанкротилось одно государство и в середине века мы потеряли сотни миллионов жизней. Не все так однозначно, политика и армия это продолжение экономики.
Ну так сервер тоже должен идти вперед на месяц. С точки зрения той кассы все должно существовать в будущем.
Это если удастся уговорить разработчика выделить такой сервер, и сделать прошивку, настроенную на него. Не забываем, что мы в данном случае не разработчики, а пользователи, которые хотят потестировать.
А зачем? Какие параметры так жизненно необходимы для касс, что не могут быть общими для всех или почти всех пользователей модели?
Тут мы приходим к понятию классов эквивалентности.Но кстати, на разном окружении( т.е. на разных ККТ) необходимо будет протестировать все заново, т.к. может отличаться железо, а значит о окружение.
Возможно, существует формальное мат.доказательство корректности алгоритма, просто каждая строчка кода становится золотой и сложность такого тестирования увеличивается в прогрессии.
Ну формальная верификация — она конечно является частью статического анализа, но она применяется только к тем частям, которые можно выразить с помощью математической модели. Не всегда это возможно, а в случае черного ящика, о котором речь шла выше — я даже не представляю, как возможно его описание
Возможно, просто очень дорого.
Как и пересчитать все песчинки на земле.
Ну так можно прикрыть любую безалаберность, зачем заботиться в безопасности ядерных станций, космических аппаратов, самолетов и автопилотов машин, если вы все равно не сможете поймать все дефекты? Вы готовы жить с ядерной станцией построенной по такому принципу?
Ну живем же. Иначе бы не было Чернобыля, Фукусимы или Трехмильного Острова. Насчет автопилотов — тоже, кажется в прошлом годубыло — что не смогли всех случаев предусмотреть. Вообще вы как-то странно переходите — почему-то решаете, что если невозможно отыскать всех дефектов — то тестировать не нужно. Это как-то странно. Тестировать нужно. Но и понимать, что дефекты все равно могут остаться — тоже нужно.
Или все таки процент имеет значение?
Какой процент, вы о чем? Вы как-то перескакиваете и я теряю нить вашего рассуждения. Вроде в предыдущих сообщениях ни про какой процент ничего не было.
Вообще изначальная тема была, что если установить тестовые кассы у пользователя, то это улучшит отказоустойчивость системы. Я считаю, что данное действие — не улучшит.
Попробуйте прикинуть какое время необходимо на тестирование всех возможных вариантов операции сложения двух 32-х битных чисел, этакая очень простая элементарная операция которая сейчас считается абсолютно надёжной… но кто знает, может в ней есть косяк который проявляется при конкретной комбинации аргументов? По типу современного ROWhammer.
Речь идёт не о том что полное тестирование это дорого а о том что это практически невозможно!
А теперь представьте себе, как можно протестировать на производстве RAM-модули… к концу даже упрощённого теста модули просто разрушатся от физического износа.
Когда-то давно попадалась на глаза статейка про производство RAM, и ещё тогда пришли к выводу что память объёмом больше 128 байт(даже не кило- и мега- !) тестировать на производстве нет смысла вообще — иначе производство просто встанет из-за низкой производительности.
Это займет не так много времени и ресурсов.
А вот полноценно гонять пару часов туда-сюда, проверять как она держит данные на относительно длительном периоде, нормально ли работает регенерация — это да, дорого.
по хорошему, надо проверить установку ВСЕХ ВОЗМОЖНЫХ комбинаций состояния памяти. Учитывая что современный чип памяти имеет на борту как минимум 16гигабит… представь себе брутфорс счетчика на 16 миллиардов бит. Я чесно говоря вообще не уверен что в мире вообще есть хоть один чип памяти без того или иного дефекта — как правило он настолько причудлив что не проявляется, а если и проявляется то отрабатывается схемой ECC или на чём-то некритичном(например результат вычисления с повреждёнными битами числа отловить никак нельзя, только параллельной проверкой на другом оборудовании) и попросту остаётся незамеченным(ну подумаешь, проги периодически сбоят на ровном месте — это считают за программную ошибку).
Так вот, как итог — полная проверка чипа памяти на 512 бит по сложности сопоставима с брутфорсом 512-битного ключа шифрования на ASIC. И это без учета вероятных утечек заряда в ячейках памяти.
Все остальные тесты — лишь сокращённые версии… и тем не менее, возьмите тот же самый MEMTEST86+ — он память и то проверяет блоками по 4 мегабайта!
А вот полноценно гонять пару часов туда-сюда, проверять как она держит данные на относительно длительном периоде, нормально ли работает регенерация — это да, дорого.
И в своей жизни сталкивался с модулем памяти который сбоил, но тест памяти MEMTEST86+ не выявлял ошибок, вероятно, из-за ограничения на размер тестируемого блока(программа тестирует память отдельными блоками по 4Мб, кажется, и если ячейка вызывает связанный дефект с ячейкой вне пределов этого блока то он обнаружен не будет) и только память с блоком коррекции ошибок способна была бы обнаружить проблему и то только в случае когда записываем один бит в память и считываем ВЕСЬ объём памяти на предмет наличия изменений. А для модуля размером в 1Гб, например, это потребует порядка 1E+12 операций чтения. Ну, несколько многова-то однако.
1. Нельзя было с прибора (без ком-порта) включить автообновление?
2. Автообновление — это зло или добро? Или правильный все же компромиссный вариант — автообновление из своего управляемого репозитория?
2. Автообновление — это вечный ответ «да» на вопрос «Почему?».
- Автообновление в ккт поступающих с завода — выключено, писанина в сми это обман.
1.1. Для автообновления нужда сд-карта которая есть на УМке и некоторых ККТ, но не на всех, т.е. работает это ровно для определенных моделей ККТ.
Понимаю, что это потеря времени, но все-таки не полный простой.
С Магнитом понятно так не сделаешь, но Мосигра вполне могла бы такое предложить.
В свете того что второй чек стал цифровым — ну обязать после восстановления забивать эти чеки специальным чеком корректировки. Вроде очевидное и универсальное решение. а то так то узких мест много.
Однако по нормальному — записывать только общую сумму чека без разбивки на НДСы и акцизы ибо это бекап а не основной вариант учета, т.е. просто первичка, чтобы продавец не «забыл» записать после восстановления. в таком варианте можно и в продуктовой сети работать.
Мы до сих пор на ЕНВД и Патенте без кассы :) тянем до последнего. Пока не нашли решение, которое бы нас устроило.
Инсайд подтвердил, что ошибку искусственно заложил увольняющийся программист.mbr.livejournal.com/521344.html
Не важно, что с ним сделают теперь. Теперь все знают, как делают code review в Штрихе
Так в чем все таки заключалась ошибка? Запасные кассы не спасали? (Обычно они долгое время хранятся на складе и прошивки на них не самые свежие, так, что теоретически на них могли быть прошивки без ошибки)
Суть ошибки заключалась в том, что при конвертации даты 20.12.2017 во внутренний формат устройства операция «печать чека» становилась циклической, то есть не могла быть завершена — ККТ «зависла». На настоящее время проблема выявлена и устранена.
Работать без кассы нельзя.Лол. На наших продуктовых рынках годами так работают.
смысл поста был (подразумевался) в том, что «нульмодемные» кабели, раньше обычно применяли для соединения двух хостов. для соединения хост-контроллер, обычно, применяли просто «модемные». но, поскольку ничего (без рентгена) не увидеть, однозначно можно только утверждать про DB9.
Может и производители касс придут к давно разработанному решению.
Проблему 20.12.2017 можно было бы легко решить выпустив какую-то утилиту для простой тетеньки в магазине — «Вот ваша касса нашлась, нажмите далее для его обновления… Готово». Но кому оно надо? Получается, что все и так выстроились в очередь на обновление прошивки за деньги. У кого не было договора на обслуживания в ЦТО теперь уже есть.
Таких как автор, которые самостоятельно (даже лишившись гарантии) пытались восстановить работу техники единицы.
Была бы на этом рынке здоровая конкуренция не было бы таких проблем.
Однако, поздравляю с 5-ти летним юбилеем!
Сегодня день толстой полярной лисички розницы — ошибка касс Штрих-М по всей стране