Information

Founded
2008
Location
Россия
Website
www.mosigra.ru
Employees
201–500 employees
Registered
Pull to refresh
Comments 261
Чеки коррекции — это такие штуки, которые позволяют проапдейтить уже выданные чеки с некоторым бухгалтерским геморроем, но зато хоть как-то. То есть не тонна бумажек и объяснительных на каждый чек, а сравнительно серийная процедура.
Т.е. покупатель проблемы не заметит, но это геммор именно для бухглатерии?
Такое решение где-нибудь было применено или вы всё же самые крутые ребята и успели всё быстро починить?
Покупатель уйдёт без чека. Но сегодня это можно, потому что есть разъяснение ФНС. Магазины не нарушают закон, поскольку признан технический сбой. Когда речь про сбой, можно не бить чеки (только в обычных условиях это сложно доказать).

Но при восстановлении кассы все чеки нужно выбить. Правильно выбивать чеки, используя механизм «чек коррекции».
Покупатель уйдёт без чека.
Вот об этом и вопрос… А как же возврат и гарантии? Или всё на доверии?
Меня бы смутило, как покупателя, что мне чек не выдают… (мало ли какие бумажки ФНС)
Для возврата и гарантии чек вообще-то не нужен. По закону. Ну и не забывайте, что те, кто на ЕНВД в регионах, вообще могут не выдавать чек — он даётся по желанию покупателя.
Век живи, век учись…

Очень круто, что так оперативно отработали и ещё пост запилили в тот же день))
Мы ещё не до конца отработали, сейчас осталось две кассы в Москве. Думаю, основные участники событий тоже подтянутся попозже, все с отвёртками в полях.
все с отвёртками в полях.

После такой эмоциональной статьи, слово "полях" прочитал сначала неправильно....

Для возврата товара надлежащего качества чек нужен.
Можно использовать другие доказательства совершения покупки в этом магазине:
Обмен непродовольственного товара надлежащего качества проводится, если указанный товар не был в употреблении, сохранены его товарный вид, потребительские свойства, пломбы, фабричные ярлыки, а также имеется товарный чек или кассовый чек либо иной подтверждающий оплату указанного товара документ. Отсутствие у потребителя товарного чека или кассового чека либо иного подтверждающего оплату товара документа не лишает его возможности ссылаться на свидетельские показания.

Товарный чек никто не отменял, а его пробить могут в любом нормальном магазине. Я ради прикола сегодня взял товарник в Магните — вопросов не было, всё сделали.
Товарник, вроде, вообще любой продаван обязан выписать, хоть от руки, главное с подписью и печатью.
День начался с того, что я попросил поддержку поправить одну минорную багу, и впервые за 9 лет увидел автоответчик на почте, мол, мы сегодня немного заняты, поэтому будем отвечать с опозданиями. Вот конкретные инженеры — они сегодня герои.
Неподготовленности.
Да, мы были неготовы к тому, что все кассы могут взять и отказать. Потому что подготовка — она явно дороже возможного простоя. Но ИТ-отдел решил всё быстро, и это хорошо. Рядом другая сеть нашего сегмента ещё не открылась вообще, к примеру.
Ого!
Ты там спал вообще?
А ты не робот? Или… на всякий случай: Cколько пальцев у меня за спиной?

:)

Спать… вышло-то удачно… или нет?
Рядом другая сеть нашего сегмента ещё не открылась вообще, к примеру.


То есть, Мосигра по итогам дня в плюсе? Хм…
Не забудьте премии айтишникам сообразить =)
В час ночи по Москве во Владивостоке отказали кассы

в 9 утра по Москве, прошивка уже была доступна с инструкцией на их форуме
 
наши точки… поднялись через 40 минут после выявления бага.

вы пофиксили багу до выхода прошивки, или я чет не понял просто?

Мы поймали багу на всех кассах кроме офисной тестовой. Узнали, что хотфикс в виде новой прошивки релизом от сегодня уже есть. Дальше надо было закрыть магазины и поставить его на все кассы, но чуть позже пришло разъяснение от ФНС.

Предположим разъяснения бы не поступило, что бы изменилост? как иначе выплывали бы из ситуации?

Так мы до него так и выплывали. Шили кассу за кассой по мере популярности магазинов и открывали их.
А обновления никак не настраиваются? Отключить нельзя, изменить репозиторий с обновлениями?
Просто как-то странно, что у всех стоял автоапдейт на кассах! в рознице!
В крупных компаниях и на windows то без тестирования не накатывают, даже после тестирования апдейты не прилетают всем сразу, у нас обычно первыми апдейты ловили мы в IT департаменте, причем по очереди. А розница и склады у нас вообще были последними по апдейтам.

Если бы было включено...


На РБК в новости есть комментарий, что если на кассе было включено автообноовление, то сбоя не было. Автообновление по умолчанию выключено на уровне заводского конфига.

Но идея с другим репозиторием — хорошая. Можно включить автообновления, настроить на свой репозиторой, в который включать только проверенные обновления. Вот только не знаю можно ли так.

Нельзя. IP жестко прописаны в коде. Мне не совсем понятно вот это сообщение:
Прошивка обновляется с нашего сервера, т.е. 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 все-таки более правильный, с точки зрения сети, вариант предложил. Негоже такой костыль (жесткий роут белого адреса) в своей сети выстраивать.
Если точка одна — то никакого туннеля не нужно. Если точек несколько — то туннель нужен в любом случае.

Получается — оба решения сводятся к одному и тому же и какое из них выбрать — вопрос вкуса.
Нам Штрих обещал в октябре сделать прошивку с возможностью обновления с наших серверов, но сказали, что сделают в низком приоритете. Так что можно, если сильно захотеть.

Баг был в прошивках, вышедших с июня (или мая?) по декабрь. Мартовские прошивки работали.
Проблема в том, что в то время было много багов и глюков в прошивках, и поэтому большинство обновлялось.

Я привык, что оборудование начиная с SOHO сегмента позволяет, как минимум поднять свой сервер обновлений, чтобы избегать ситуаций с установкой непроверенных апдейтов с сайта производителя. По этой причине многие крупные сети и не активируют автообновление.
А насколько было бы проще, активировали автообновление на свой сервер и на него выкладывать апдейты проверенные у вас на стендах и тестовых магазинах.
Даже в этой ситуации, у вас был активирован автоапдейт и все, что нужно было для исправления ситуации — это положить исправленную прошивку на сервер и передернуть кассы.
ЗЫ. Задним умом крепки все…
т.к. моя халтура это в том числе установка и обслуживание касс — сегодня утром я чуть не повесился. На данный момент у меня лежит 22 кассы снятые с точек и кучу упущенной прибыли у клиентов.

Хорошо что хоть не в пятницу… перед новым годом.

Спасибо за пост. Пойду чинить.
Ну, в нашем случае — спасибо, что не тридцатого. 30 и 31 декабря у нас очереди в три петли в зале и с хвостами на улицу на некоторых точках.
ТТТ, не кажи гоп! :)
Удачи 30 и 31. Если не привезут мне из UGear подарок для ребёнка, пойжу к вам стоять в очередь в три петли.
Мы лет пять назад научились правильно всё делать — например, больше касс ставить и выводить огромные смены продавцов, иногда сразу по 8-10 человек на зал 40 квадратных метров. Поэтому такой момент с очередью сейчас относительно короткий, обычно 30-го в 18:00-18:30 и на точках прямо у метро. Плюс ещё мы обычно оставляем один магазин 31-го допоздна работать, для тех, кто совсем не успел.

Зато утром первого января приходят совершенно очаровательные люди. Продавцы в магазинах по ним гадали в том году — было важно, какую игру купят в магазине первой за год.
Плюс ещё мы обычно оставляем один магазин 31-го допоздна работать, для тех, кто совсем не успел.

Вот за это отдельное спасибо ;)
Значит у вас банально не хватает касс, экономите ФОТ.
Площадь торгового зала не позволяет поставить 10 касс.
Помнится в макдаках год назад бегали девочки с терминалами и «что изволите?». Вряд ли именно количество Штрихов узкое место?

Т.е. «интерфейс» — на мобиле, оплата картой — mPOS какой-нибудь, и сервер со штрихом и ФНС выдает чек на выходе.

Дада, цто не нужно, я сделаю все сам. Торговый объект #1 после перепрошивки и в путь. Завтра постараюсь расписать как это видели большинство цто по стране, после работы "самоделкиных".

ЦТО тоже сегодня кончали жизнь заеданием водки…
Это «самоделкины» регулярно фаршировали багами прошивки «Штрихов» с апреля по октябрь?
баг только в августовской и октябрьских прошивках (двух последних).
В ветке на форуме «Штриха» указали, что баг присутвует в прошивках, зарелизеных с апреля по октябрь

Нет, и что? Речь шла про "мою халтуру" и то что на момент написания комментария "у меня лежит 22 кассы снятые с точек", вместо быстрого решения проблемы на месте.

Кхм. Все ЦТО нашего города приняли кассы к себе на ремонт и поставили в очередь. Вы думаете что там боги работают? Точно такие-же люди как и мы. Кстати человек с которым я халтурой данной и занимаюсь — оттуда и уволился, после 10 лет работы. Ремонт в сервисе будет от 2 до 5 дней.
С утра повалились поломки и банально почитать интернет было некогда, с самого утра информации о быстром ремонте не было.

Да считаю. Информация была. Уже на 05:20 МСК была доступна прошивка исправляющая проблему.

У вас есть право считать их богами, у меня есть право считать иначе, оглядываясь на два заваленных центра обслуживания кассового оборудования. У меня все уже отдано, у них — от двух до пяти дней. Ничуть не хвастаюсь, но я делаю это а) дешевле б) оперативней, по этому и есть халтура. Мб в вашем городе по другому.

Хех, судя по комментам на форуме предположу что у подрядчиков обидели программистов.
А вообще за такие законы о торговле и требование использовать их зарытую хрень нужно ФНС руки оторвать.

В данном случае в закрытом протоколе и одной программе — поэтому легли все сразу.

Легли все сразу у одного вендора. Как открытый протокол может гарантированно уберечь от такого рода проблем?

никак, просто проблема была бы гораздо менее маштабной

Хм. Вы точно понимаете о чем идет речь? Косяк допустил только один производитель. Допустил в своем оборудовании. Есть еще производители, есть другое оборудование. Масштаб проблемы говорит только об охвате Штрихом рынка касс в России.
При хоть сколько открытом протоколе, это никак бы не помогло не сотворить ошибку в коде.

Да, я понимаю, но из-за искусственно созданной олигополии получился достаточно широкий охват. Такая-же ситуация получится с 1С или с ошибками в windows, фигово вобщем, ладно, забейте.

Ну был бы протокол открытый. Ну накосячил бы разработчик какой-то базовой используемой всеми либы (открытой!) для реализации этого протокола — точно так же могли бы лечь все. Открытость сама по себе не спасает от ошибок. Тот же OpenSSL (Heartbleed) вспомните.
Да, утро было веселым. А разве вскрытие ККМ не означает лишение гарантии/снятие с учета? Интересно, у Атол устроили внеплановое codereview на всякий случай? :-)
Новые кассы (которые вот с этой приблудой с онлайн-отправкой вместо ЭКЛЗ) можно открывать, но они слетают с гарантии. В нашем случае слетело несколько касс, но это мелочи в сравнении с простоем.
А разве снятие с гарантии в таких случаях законно? Пусть заново опечатывает СЦ производителя за счёт погромистов, выпустивших лажовую прошивку.
Законно. Можно же было обратиться к фирме-продавцу и они бы решили вопрос по гарантии. Вот только, я уверен, что у тех ребят сейчас даже в туалете стоят кассы, ждущие прошивку.
Дефект же вызван производителем или уполномоченными им лицами. Почему ответственность должен нести пользователь? Они же не просто так туда полезли. Форс-мажорные обстоятельства.
Так гарантийные обязательства и подразумевают устранение неполадок в случае дефекта.
Это я к тому, что если тех.спецы пользователя перезалили только прошивку на официальную же и работает дальше, то весь остальной аппарат не должен сниматься с гарантии. Ведь действия пользователя не привели к повреждению оборудования.
Это не важно. Есть определенные условия при которых устройство снимается с гарантии. Если нарушение гарантийных пломб, следы вскрытия и собственноручная перезаливка прошивки не противоречит законодательству, то снятие с гарантии законно.
Это зависит от гарантийной политики производителя. По идее, в этом конкретном случае, производитель должен пойти на встречу (их вина) и с гарантии не снимать. Прийти, проверить, опломбировать заново. Если снимут- ну не в честь им. Жаль, что покупка этого оборудорвания всё равно принудительная.
Это всё понятно, и, думаю, Штрих пойдет на это, т.к. репутация подмочена капитально и это коснулось очень многих. Я имею ввиду, что пострадали не только продавцы, но и потребители. Если у какого-то ОпСоСа в регионе N упала связность, то это проблема одного оператора в одном регионе и абсолютное большинство жителей страны узнает об этом из новостей. А тут узнала вся страна. Я сам, хоть и не в рознице и не на Штрихе, до машины с утра не успел дойти как в телеге коллеги уже обсуждали как розница волосы рвет у себя и поддержки.
Ну а ваш вопрос был про законность снятия с гарантии.
Запомните пожалуйста. Производитель не может лешить/снять с гарантии. Это может сделать только суд. И производитель будет обязан доказать, что поломка была вызвана действиями пользователя. Почитайте как нибудь ЗОЗПП
Почитайте как нибудь ЗОЗПП


Какое отношение он имеет к договорным взаимоотношениям между коммерческими организациями? Он на защиту физиков заточен.
К сожалению, работало это только на тех интерфейсах, где кабель был COM 9pin — COM 9pin. На всех остальных кассах подключения к компьютерам просто не было. Потому что довольно тяжело найти компьютер с COM 25pin, например.

Не понял, в смысле Штрихи идут с 25pin? Ну это повод оборудовать рабочие места переходниками 25 на 9. А на материнках COM-порты существуют повсеместно, вот только не выведены обычно. Или у вас используются не стандартные системники, а неттопы и прочее?
У нас моноблоки или такие мелкие системники, которые типа интел-нуков, только не нуки. В любом случае, даже обычный тауэр продавец не разберёт сам. Для выездных касс ноутбуки.

Так кассы у вас к этим ноутбукам не подключены, вы хотите сказать? Или подключены по USB, а по нему обновление прошивки недоступно? А через usb-com переходник, о котором вы, кстати что-то писали?

COM-шнур нужен для сервисного доступа. Через обычный USB для стандартного аплинка не перепрошивается, через переходник фокус тоже не канал.

А должен был "канать". Я бы вам рекомендовал поискать переходники, которые будут работать с этой задачей (в основном проблема с драйверами там, и на каком уровне эмулируется COM порт), и запастись на будущее, чем черт не шутит :)

Выше Сергей написал, что у них или моноблоки или а-ля неттопы. Куда им это ставить?..
Чисто предположение: Даже если там нет PCI-Ex1 слота на МП, а если попробовать такую штуку воткнуть в PCI-E-usb3.0 райзер, как майнеры используют?
Дело тут не в скорости, а в совместимости и принципиальной возможности шить кассу через USB->COM конвертер. Но я согласен, что скорее всего не было времени подобрать рабочий, юзали что было под рукой.
А разве там не специальный usb3.0, который другим концом нужно втыкать в плату PCI-E? Просто сомневаюсь, что прокинуть эту низкоуровневую шину через обычный usb так просто, по стандарту это возможно только в 3.1 в альтернативном режиме.
Да, специальный, просто интересно стало, что будет, если воткнуть так, без PCI-E ответной части.
К проводу USB 3.0 очень высокие требования в плане кабеля и пайки, такие же высокие, как и к проводам для PCI-e-шины, поэтому их массово и используют.
Moxa n5110 спасет отца русской демократии… Тот же rs-232 теперь ещё и по езеру. Цена ~ 5 тыр. У нас пока кассы не стали с езером по дефолту- все так работали.
В качестве безумной идеи: а что с виртуальными машинами? Если прокинуть com-порт в них (даже не помню, возможно ли это) — как они работают с физическим портом?
Если прокинуть com-порт в них (даже не помню, возможно ли это)

возможно ) прокидывал в VirtualBox 5.1.26, хост — Linux Fedora 25, виртуалка — Windows 7
На VmWare — проблем нет при условии наличия физики RS-232 у сервера-хоста. На прочих — преобразователи интерфейса Moxa n5110 или аналоги. Моху привожу в качестве решения, т.к. имею опыт эксплуатации. Проблем не было. Единственно, кассы подключенные к RS-232 через моху после появления штатного езера (с подключением к ОФД) стали странно тормозить. Как следствие — перешли на езер.
Я имел ввиду, заработает ли это с драйверами китайского «COM-шнура», который не работал у Milfgard'а. Возможно виртуалки транслируют вызовы в более современный формат.
Только если «шьющая» программа работает через драйвер а не через порт 3F8, как до сих пор советуют делать некоторые туториалы.
В последний раз напрямую обращаться с портами позволяла лишь Win98, в более старших операционках такое уже не прокатывает. А у USB-переходников другая принципиальная проблема связанная с физической работой USB-шины которая иногда может стать боком если протокол обмена жестко завязан на тайминги.
Прокатывает, есть специальный драйвер (или даже несколько) который позволяет программам работающим от админа обращаться к портам.
Этот драйвер… это такая ДЫРИЩА в системе, что говорить о нём даже не хочется. Это костыль, причем такой костылище… темболее что он в 8-ке и 10-ке уже не работает. окончательно похоронили.
То, что он не работает в восьмерке и десятке — это, в понимании тех кто им пользуется, лишь причина оставаться на более старых ОС где «не поломали обратную совместимость».

По-настоящему его похоронили производители материнских плат которые перестали предусматривать на них COM- и LPT-порты. Как пришлось выбирать между поиском раритетных карт расширения для PCI и покупкой куда более распространенных переходников USB-COM/USB-LPT — так даже динозавры поняли что и правда пора учить правильные способы работы :-)
Не знаю, комп 3-х летней давности, память DDR3 а порты COM и LPT аппаратные в наличии.
Да и на современных материнских платах площадка под COM присутствует. Только планку со шлейфом и розеткой (разъемом) нужно отдельно приобретать.
… Или выудить из хламника у любого достаточно бородатого админа.
На DSUB9 может быть не только com aka rs232, но и rs485, например. Они принципиально различаются. Либо попался китайский ширпотреб. Если будете думать как уберечься от повторения полярной лисички, попробуйте конвертеры производства MOXA, это серьезное промышленное оборудование, ещё не встречал, чтобы они не подходили куда-либо.
У меня с ними проблем не было. Мне тяжело представить, где они могут не подойти. И уверен, что с кассами они будут работать.
Ну и думаю, АСУшники могут посоветовать еще несколько подобных продуктов.
Milfgard Штрихи можно прошивать через usb, используя режим dfu с помощью dfu-utils. Правда, загрузчик в Штрихе должен быть от 131 версии и выше
Спасибо, но боюсь, если есть выбор в такой ситуации между «пытаться понять, почему нет» и «взять ком-шнур и вперёд», второе как-то практичнее. Но мне до безумия интересна история аптечных сетей и Магнита, где касс на порядок больше.
Вечером в провинциальном Магните не работали с картами. Но поскольку мне надо было купить именно с карты, подробней не углядел.
Я вчера в Самаре часов в семь вечера в Магните по карте покупал без проблем.
Видимо, к вечеру решили уже.
у меня есть знакомые в магните, в пятницу могу расспросить, но не раньше.
Вот когда надо было спихивать кабеля COM 9pin-9pin-25pin от старых диалап модемов.
Вот не ожидал увидеть объяснение простоя аптеки с буфетом у меня на работе на Хабре!

Почитайте как хранится тег 1012 в ФН. ККТ пыталась прочитать время последнего документа после открытия смены и спотыкалась на преобразовании в календарное время того что хранится в ФН, все это подвисало, срабатывал сторожевой таймер и циклический ребут....

А что за волшебное значение вызывало такое поведение? Там ведь никакие не единицы вроде и не переполнения, если именно unixtime. Или там хранится не совсем unixtime?

Значение совершенно обычные. Проблема в конкретной реализации time.h и как пример в time_t mktime(struct tm *p), то что приехало на вход, на выходе получилось не таким как ожидалось...

Ну так а что за проблема-то там в реализации была?

Вы можете самостоятельно поинтересоваться у компетентных сотрудников производителя, или вы хотите ревёрсинг прошивки в комментариях?

Вы здесь написали уже кучу комментариев в ответ на вопрос о подробностях, но никаких подробностей так и не раскрыли. Означает ли это, что вы на самом деле ничего не знаете?

Если нет, то что мешает вам рассказать наконец-то что там было?
Знаете, это неуважение к посетителям сайта. Ок, посмотрел я что там в 1012м поле: дата. Спасибо Кэп. Что такое надо сделать с датой, чтобы её максимальное значение истекло 20 декабря 2017, а не в январе 2038?

Ок, как по вашему должен выглядеть ответ на данный вопрос? Кусок кода закрытой и защищенной производителем прошивки? Нет, этого не будет, можете расходится и не ждать. Если вас интересует "что такое надо сделать с датой", могу оставить ссылку на вопрос StackOverflow в котором проблема имеет такие же корни.

> Опять таки, хабр такой хабр…
Ваши комментарии выглядят так, как будто бы вы знаете реальную причину. Комментарии автора так не выглядят.

Да и в общем-то даже со стороны понятно, что это что-то вязанное с датой, если сбои пошли по часовым поясам.

> Кусок кода закрытой и защищенной производителем прошивки?
Как правило, 10 строк погоды не делают. На худой конец можно дать словесное описание того, что произошло.
Единственная проблема — признание факта присутствия бага… Но этот факт подтверждён предпринимателями по всей России.

Но всё это имеет смысл только если вы имеете доступ к исходникам либо вы делали декомпиляцию кода. Ваши комментарии намекают именно на это.

> могу оставить ссылку на вопрос
Ок, спасибо. Это проясняет ситуацию хоть как-то.

Вам действительно кажется, что этот текст отвечает на заданный вам вопрос?
> Дальнейшие препинания
Я даже не начинал это делать :D
Соответственно и продолжать тоже :D
Мы хотим понять, о чём вы говорите.
А что такое проблема-2000 мы и так знаем.
В отличии от вас, автор поста не делал вид что обладает тайным знанием.
Хоть ссылочку где читать бы, для людей далёких от ФН. Сходу не гуглится.
По фн вообще документация полное дерьмо, я так скажу. Писали её точно под какими то веществами.

Вкатали бы производителю иск. Желательно на все 10 млрд рублей потерь. Научились бы работать.

Факапы бывают у всех. Уверен, что в EULA прописано, что производитель не несет ответственности за упущенную прибыль.

Ну да, и у производителей ответственного оборудования тоже — к примеру, систем вентиляции легких.

Факапы бывают у всех

И да, в том числе в сверхкритичных областях, где уровень тестирования и ответственности несоизмеримо выше. Я не защищаю косячников, но засудить Штрих вряд ли удастся, только если этим будет заниматься на сама ФСН. Уверен, вот перед налоговой обязательства как раз есть.

Если в этом преценденте никто иск не вкатает, то остальные и сам производитель будут тестировать еще хуже — ведь ничем не рискуют...

Начинать судить нужно с самой ФСН — она внесла продукцию Штриха в реестр. )

ФНС тут не причем. Чтобы ФНС внесла продукцию в реестр, она должна получить результаты экспертизы. Так что судить надо «экспертов», давших положительное заключение по штриховской продукции, а не ФНС.
«А теперь я покажу своё кунг-фу» ©:
Статья 3.1. Экспертиза моделей контрольно-кассовой техники и технических средств оператора фискальных данных (соискателя разрешения на обработку фискальных данных). Требования к экспертным организациям

1. Экспертиза моделей контрольно-кассовой техники и технических средств оператора фискальных данных (соискателя разрешения на обработку фискальных данных) проводится экспертной организацией в соответствии с законодательством Российской Федерации о применении контрольно-кассовой техники.
2. Сведения об организациях, соответствующих требованиям, установленным настоящей статьей, вносятся в реестр экспертных организаций.
3. Для включения в реестр экспертных организаций организация направляет в уполномоченный орган заявление о включении в реестр экспертных организаций, которое должно содержать следующие сведения:
полное наименование организации;
идентификационный номер налогоплательщика;
фамилия, имя, отчество (при наличии) экспертов, общая численность работников (с учетом требований абзаца второго пункта 6 настоящей статьи);
наименования и реквизиты документов, подтверждающих соответствие организации требованиям, установленным абзацами вторым и третьим пункта 6 настоящей статьи.
Тогда ужасная ситуация получается, когда предпринимателей (которые по определению несут риск в своей деятельности) обязывают вести бизнес с учетом какого-то компонента, который риск повышает, и никто этот риск не принимает на себя.

Более справедливо (и полезно для бизнеса, наверное) было бы не просто создать приятный сегмент рынка для производителей этих касс (неплохо так им рынок на миллиарды создали), но и обязать их, если уж занимаются — компенсировать это. А то с одной стороны у нас свободы и либерализм (имеют право производить без гарантии, не надо кошмарить бизнес), а с другой — принуждение (попробуй-ка не купить эту кассу-сюрприз. захочет — будет чеки выбивать, захочет — будет играть веселые мелодии).

Всегда будет «какой-то компонент, который повышает риск». Удобство и безопасность (в данном случае вероятность отказа, т.к. сложность системы растет) на разных чашах, не устану это повторять. Можно ведь и при свечах работать и на счетах считать, выписывая товарники от руки. Но вряд ли это будет конкурентноспособно.
Ну так пусть сам предприниматель и решает, как ему работать — при свечах или ещё как. Потому что если государство обязывает предпринимателя использовать техническую хрень — то пусть то же государство обязывает производителя этой хрени гарантировать качество путём принудительной подписки на страхование предпринимателя (страховать можно самостоятельно у себя или у сторонней страховой фирмы).
Ну так оно может и будет, только за счёт предпринимателя, а он заморочится оформлением бумажек может и сам, но переложит свои расходы на потребителей. Производитель оборудования также включит эти расходы в стоимость оборудования и технического сопровождения. И снова за всё заплатят потребители. Т.е. все мы. Хотите аналог ОСАГО на всех предпринимателей? В выгоде будут только страховщики, которые ещё заплатят часть прибыли в бюджет. Я думаю законодателям понравится ваша инициатива.
Ну, хорошую идею сделать в особо циничной и извращенной форме, у нас любят, да.

Но, кмк, при правильном подходе, мне кажется, после такого инцидента, стоимость страховки для этого вендора взлетела бы до небес, так как известно, что контроль качества ПО он не осуществляет, фактически это было бы равно закрытию бизнеса. После этого все прочие вендоры свои сорцы бы наизусть перечитывали, потому что в случае фейла, было бы не «ужас как неловко», а настоящий финансовый ущерб.

У меня в юношестве было странное ощущение (мне тема безопасности всегда была интересна), что, мол, это там где я работаю — бардак в плане надежности и безопасности, все «на скотче» как-то. Но, думал, в финансовых компаниях — все иначе совсем. А когда соприкоснулся по работе с финансовыми… Да нет, так же у них, такой же бардак. Только люди гораздо более безответственные. Потому что я считал, что бардак терпим только в нашей некритичной сфере, а в финансах он недопустим, а они считают, что и в финансовой сфере можно. Ничего страшного. Ну встала целая сфера розничной торговли по всей стране. Ну не могут автомобили заправиться. Ну… неловко. Извиниться нужно и все.
Для начала — все эти затраты будут вычтены из налогооблагаемой базы.

Но принудительная страховка хотя бы затормозит скатывание экономики в копрономику (я надеюсь, Вы в курсе, что это такое и как оно возникает).
Как раз у предпринимателя есть возможность не использовать как кассы, так и свечи.
пусть то же государство обязывает производителя этой хрени гарантировать качество путём принудительной подписки на страхование предпринимателя (страховать можно самостоятельно у себя или у сторонней страховой фирмы).

Да это же шикарная идея! )) Срочно в стартап! Сколько, интересно, будет стоить страховка при внедрении касс для ритейла, вроде этой же Мосигры? На сколько вырастет цена на дженгу? Чего далеко ходить, давайте тогда и эндюзеров винды страховать от блюскринов.

UPD. ARD8S опередил.
UFO landed and left these words here
В конце лета дядя Коля обходил дома поселка и просил у хозяев по пятерке, обещая всю зиму сторожить от покражи. За такую цену никто не отказывал, и дядя Коля с карманами, полными пятерок, направлялся к магазину. Если же зимой какой-то дом все-таки взламывали (шпана из райцентра набегала), то дядя Коля шел к
хозяевам каяться: «Виноват! Оплошал, не уберег добро, родные мои! Вертаю
средства, совесть не позволяет, раз оплошал!» — и благородно возвращал
деньги. Поскольку за зиму обычно обкрадывали только две-три дачи, то дядя
Коля не оставался внакладе.
Да что вы к ним прицепились.
Они свое уже и так заплатили без всяких штрафов.
Они потеряют заметную (не очень большую, но заметную) часть рынка просто потому что люди будут помнить о двадцатом декабря и слагать легенды.
Оно может и не факт что объективно, но многие эмоционально будут принимать решения против их предложений. Ну и часть да, начнет разводить зоопарк покупая часть касс конкурентов просто для разнообразия.
Всё.
Этого достаточно чтобы их наказать.
А большие наказания их могут просто убить.
Может и черт с ними, убьют и ладно.
Я не знаю специфику этого рынка. Может они и плохие игроки и их не жалко.
Не знаю.
Но ведь другим страшно будет.
Лезть будут или отмороженные, или те у кого крыша не протекает или те кто заметно взвинтит цену. Будут больше опасаться и все такое. После каждой ошибки будут вылетать из игры, так и не набрав опыта. Кому это выгодно?
UFO landed and left these words here

У них есть описание протокола в открытом доступе (как и всех впрочем), и у меня их кассы вполне работают под Linux.

Так интереснее всего — в чём причина бага? Есть какой официальный ответ от Штрих-М? Очень похоже на умышленную диверсию. Не вижу другой причины, почему ещё это всё началось именно в этот день.
Вообще-то проблема была. То, что подавляющее большинство к ней подготовились не говорит о том, что это был фейк.
То что вас «не задело» не означает, что проблемы не было. Хорошо помню и 19100й год на форумах и спирометрию, датированную 1900м годом (снять показания эта сволочь могла в 2000м, а передать в компьютер — уже нет, так что пришлось лабораборию 1900й год отправить).

Это то, с чем лично сталкивался. Наверняка и другие косяки были. И это после того, как в предотвращение проблемы вбухали просто-таки космические деньги!

Так разверните уж! Никто так и не понимает в чем тут оно!

Речь о проблема Y2K? Ситуация похожая вышла? А так молодцы, что оперативно разработали волнообразный накат. Как-то давно работал в рознице, а там любая проблема с кассой всегда стоила нерв. т.к. не объяснишь руководству причину, они то, деньги теряют.
Чью диверсию? Атола? )) Да ну, просто в 00:00:00 20.12.2017 что-то багануло в фирмвари.
2017 != 2038.
В UNIX TIME дата факапа выглядит как 1513728000, в двоичном виде это 1011010001110011010100000000000. Я не вижу в этих числах ничего особенного.

Судя по описанию проблемы y2k на той же вики, стало понятно что тут как раз дело в этой unixtime. Скорее всего есть какая то зависимая дата от даты чека, например дата окончания хранения записи или что нибудь в это духе, которая при подсчете может переполнится.

По слухам — закладка.
Типа такой:
if(now >= '2017-12-20'){reboot;}

Но раз говорят что в налоговую приходил 2012 год. То скорее он, что то с форматом придумал/перепутал. Вместо DDMMYYYY использовал YYYYMMDD.

Инсайд подтвердил, что ошибку искусственно заложил увольняющийся программист.

Источник.
Карина, руководитель розницы и бывшая глава нашего ИТ-департамента, параноик.

Передайте Карине привет, мешок респекта и лучи уважения :)


// потому что параноиков никто никогда не слушает, но они всегда оказываются правы :)

Обеими руками и ногами ЗА такую параноидальность ) Молодец, Карина!
причем самое обидное, что Карина оказалась права один раз, а «оптимисты» каждый день. «ну ведь сегодня же запасное колесо и ремни безопасности не пригодились! Уже год зря возим».
потому что параноиков никто никогда не слушает, но они всегда оказываются правы :)


Только меня смущает, что ошибки одновременно всплыли у производителей касс? Как то странно для бага в прошивке.
Проблема произошла с кассами от Штрих-М. Предполагаю, остальные три просто делают эти же кассы на своих мощностях.
Как минимум один производитель использует ту же системную плату (с той же прошивкой), но ставит другие компоненты в блок печати чека. Маркирует своим брендом.

Разрулили, блин, оперативно. На Камчатке близилась полночь, вся страна до Урала перепрошивала изо всех сил фискальные регистраторы. ЦТО собирали от 500 рублей за перепрошивку. Люди не могли заправиться, т.к. Газпромнефть в Омске держит свой самый большой нефтезавод и заправки в городе процентов на 80 тоже принадлежат им. И тут ФНС в 20.12.2017 11:25 Москвы разрешило торговать без чеков. )


А ведь кто-то в этой самой ФНС не внес в реестр регистраторы Меркурия до 1 июля 2017, а регистраторы Штриха внес...

Собственно поэтому ФНС и сработала оперативно, а не через полгода — потому что этот кто-то в ФНС, думаю, утро начал с такой почты:
image
, причём не только на экране, но и с курьерами (позднедекабрьский день стоит летнего месяца не только у Мосигры, но и у гораздо. гораздо более крупных… алкольных например, а если ещё и нефтянка встала...). И, таки думаю, суровые разборки ещё предстоят, и достанется не только программистам, это не какой-то застрахованный спутник в море уронить…

Карине орден?

Срабатывать было нужно год-два назад прописывая в том же 54 ФЗ, что делать если:


  1. кассовый аппарат впал в кому по причине кривой прошивки/кривого фискального накопителя (когда починят неизвестно, но можно купить новый совсем не дорого)
  2. ОФД перестал выходить на связь (совсем)
  3. оператор связи перестал предоставлять связь (починят когда лед встанет/грязь просохнет)

Количество точек отказа для технически неподкованного индивидуального предпринимателя запредельное.


А обещали, что будет дешевле ЭКЛЗ… гы-гы-гы… ))

В Украине через это проходили. Одна компания поставщик на всю страну, принадлежащая Януковичам и Ко.
2. ДЦ налоговой, который она арендовала у ком.структур, ушел в оффлайн на два дня. По закону допускался один день без подачи отчетов, после второго дня остановилась работа как минимум в двух очень крупных торговых сетях. Никто не понес никакой ответственности, благо, что это произошло на этапе внедрения и эти две сети были первыми, кто перешел на новые кассовые аппараты.
3. Кассовые аппараты на этот случай шли с GSM-модулем.
2 и 3 пункт вполне прописан возможностью хранения фискальных документов в фискальной памяти до 30 дней. То есть мы имеем запас в месяц для восстановления связи.

Тут такая проблема. Поставили кассу помониторили пару дней все работает, чеки идут. А потом бац в один день касса превратилась в тыкву, т.к. 30 дней прошли. Почему она перестала ходить в сеть я так и не понял, есть версия, что во всем виноват gsm модем торчащий в компьютере — его переткнули в другой порт. Включить мониторинг у ОФД не вариант, нет там варианта по субботам и воскресеньям мы не работаем. Меня бы устроил вариант касса > 20 дней не выходила на связь, с возможностью выкидывать некоторые кассы, которые будут лежат в тумбочке больше 20 дней. Но такого нет.


Ну и за месяц ледовая переправа не появляется, т.е. паром ходить перестал, а лед еще не встал ну и наоборот. Тут в райцентр автобус весной и осенью часть трассы трактором тащат — это Россия. Мост смытый в прошлом году восстановят в следующем. Вы по прежнему уверены, что связь восстановят быстро? )

По умолчанию в обычных онлайн-ККТ при формировании X- и Z-отчета в них выводится количество документов, ожидающих отправки ОФД, и дату последней успешной отправки данных (получение подтверждения от ОФД). Не так уж страшно если их число колеблется в районе одного-двух – ККТ могла просто еще не успеть отправить документы на момент снятия отчета (некритическая ошибка в прошивке, проблемы с каналом связи на стороне продавца или ОФД, DoS на стороне ОФД). Вот если их число начинает расти (на следующий операционный день) тут же надо бить тревогу. Но в первую очередь нужно кассиров-операционистов выпороть на конюшне привлечь к дисциплинарной ответственности за халатное отношение к своим обязанностям, – следить за реквизитами фискальных чеков/отчетов и сообщать об отклонении техническому специалисту (или своему непосредственному руководителю), – их прямая обязанность, прописанная в должностной инструкции.
Что же касается онлайн-ККТ, предназначенных только для расчетов в сети Интернет (кассы для Интернет-магазинов), то тут два способа мониторинга:
  1. Мониторить личный кабинет на сайте ОФД
  2. Написать робота, который будет с некоторой периодичностью опрашивать ККТ на предмет неотправки фискальных документов
Кстати, вспомнилось ))).:
Резюме
Это всё очень круто, потому что мы в стране наконец-то отказались от устаревшего носителя, плюс получили возможность проверять всё онлайн. Да, проблемы при внедрении есть, но в целом — оно того стоит.

Кто ж мог предположить, Сергей )) Не подумайте, не злорадства для.
Я всё ещё при своём мнении. Это не ЭКЛЗ, и с ЭКЛЗ никак не связано. Плюс в том, что те, кто подключали кассы к сети, получили небольшой шанс поймать автоапдейт ещё, и если открывали смену поздно — у них всё работало. Ничего не мешало поймать сбой и на старых кассах с теми же последствиями.
А я как раз с вашим мнением и согласен. Просто мне показалось забавным, что обе статьи вашего авторства.
Надо сказать, что у «Штриха» такой факап не первый. Первый случился с моделями ФР и ФР-К (конец эпохи фискальной памяти и паспортов версий — начало эпохи ЭКЛЗ) – в случайный момент времени (три дня после ввода в эксплуатацию или спустя два-три года активной эксплуатации) фискальник «уходил в себя»: терялась связь с компьютером, одновременно загорались все имеющиеся индикаторы (выключение-включение, хард-ресет с помощью специальной перемычки на плате фискальника не помогали). Дело было в заводском браке: то ли некачественный транзистор, то ли непропай на плате (за давность лет уже не вспомню). После этого «Штрих» пошел на беспрецендентный шаг: фискальники, на котором диагностировали такую неисправность ремонтировались бесплатно (даже с истекшим гарантийным сроком).
После этого «Штрих» пошел на беспрецендентный шаг: фискальники, на котором диагностировали такую неисправность ремонтировались бесплатно (даже с истекшим гарантийным сроком).
Беспрецедентный разве что для «Штриха». Почитайте ленту новостей: автопроизводители регулярно бесплатно разные вещи меняют. Ну и Сматрфоны всякие
UFO landed and left these words here
DR нужен для того, чтобы встать после такого. DR делается на кассы, сервера магазинов, много на что. Кассы регулярно накрываются, и это — пожалуй, самый смачный пример за последние годы.
Клинический? Для реальных систем не бывает исчерпывающего набора тестов. Нет тут ветви функциональности, которая зависит от этой конкретной даты. Поэтому покрытие функциональности будет полное, но тесты эту багу могут поймать разве что случайно.
Мораль всей истории такова — не иметь кассы (жесткие диски, еще что-то выполняющие одинаковые функции) от одного производителя и одной партии в одном месте в одно время. А были бы часть касс того же атолла, можно было бы продолжать работать.

PS. У нас по области более 100 штук атоллов. Надо начальству сказать, чтобы хоть пару десятков штрихов закупить для ЗиП.
Ну, альтернатива — зоопарк. Если чуть дальше зайти.
За все надо платить. В том числе и за повышение надежности работы.

У атолла (по крайней мере у нас) недавно был другой косячек. Кассы отказались работать когда пропал доступ к серверу офд. К счастью, доступа не было не больше часа. Почти никто этого не заметил.
«Смешанный лес всегда устойчивее ко всевозможным неблагоприятным факторам и катаклизмам, чем монокультурный.»
Два вида — не зоопарк, а для сохранения рода. Пара аплинков до разных провайдеров. Да, сложнее, да, дороже. Но ведь вопрос — что важнее бизнесу. Простой или плата за «страховку». Естественно, если простой дешевле, то ну его.
Мне, как человеку который такое ставит это норма, т.к. цена установки рабочего места с кассой одинаковая, вне зависимости от производителя, а вот покупка модулей 1С для ее поддержки или еще веселей — самописные системы… это лишние проблемы и затраты для владельца бизнеса.

Насчет 1С не знаю, а вот с самописными системами не должно быть сложно, если разработчик работает в тех. отделе, а не на аутсорсе. Поддержка возможности работать с несколькими устройствами — достаточно дешевая, при более-менее грамотном подходе к разработке ПО.
Ну и в "наливку" кассовых ПК включить драйвера для обоих устройств.

Тут возникает вопрос стоимости сопровождения этого зоопарка.
Онлайн-кассы всем впарили, а теперь, в свете выявленных обстоятельств, можно их запретить и взамен продать ещё более новые кассы.
На базе Эльбруса и нанотехнологий, например.
Интересно какая практика в Европе, США по кассам.
Там тоже в онлаин режиме в налоговую чек шлют? Кто-то сталкивался?
Пока нет, но все регуляторы очень этого хотят. Так что будет со временем, скорее всего.
Говорят, маленький кусочек Казахстана тоже находится на европейском континенте. Так вот, у них там тоже чеки кассы в налоговую шлют, тоже всегда онлайн. (Правда не все кассовые аппараты, есть какие-то исключения по обороту).
Так тут проблема не в онлайне была, а в выдаче чека. АФАИР 30 дней даётся, чтобы донести чек до налоговой. Вроде вполне достаточно.

Так как "сорт оф" работаю с этим — в ЕС стандартизации нет на эту тему, отдельные решения по странам, например в Греции при печати чека на нем должна быть фискальная спец-строка, которую (упоротый и кривой) софт установленный на перехват печати ловит, валидирует, отсылает кудато-там а на чек вместо этой строки ставит снизу спец-подпись (сколько мы наплевались с хромом, который выводя чек на печать из браузера перегонял его в растр и софт не мог поймать фискальную строку...).

Вывод один, НЕ обновляться автоматически, вручную обновлять только после тестирования в лабораторных условиях, потом на мелком магазине с небольшим оборотом.
у нас по регламенту из МСК, мы обязаны обновлять FW до самой актуальной, но кто-то не заложил бапки на апгрейд и нас эта проблема обошла стороной =)
Вывод один, НЕ обновляться автоматически

Наоборот, обновление спасло бы:
На РБК в новости есть комментарий, что если на кассе было включено автообноовление, то сбоя не было. Автообновление по умолчанию выключено на уровне заводского конфига.
Нет, в данном случае сломались ВСЕ прошивки, выпущенные после 29.05.2017. Поэтому, обновление не спасло бы
Это точно? А то у нас вроде как начала года и (тьфу-тьфу) обошло.
Вот сидим, думаем — обновляться в срочном порядке или нет? )))
Milfgard пишет, что спасло бы…

Но однозначного ответа (обновляться/не обновляться) нет. В этой ситуации автообновление было благом, в другой станет багом…
вручную обновлять только после тестирования в лабораторных условиях, потом на мелком магазине с небольшим оборотом

Вот поставили вы обновление в мае на тестовую кассу. Полгода тестировали — все нормально. Еще полгода протестировали на небольшом магазине — все нормально. Распространяете обновление на все кассы. И через неделю все ложится т.к. наступил очередной 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, люди себе другую работу найдут, делов-то. А если ядерный ректор рванёт или, банальнее, плотину смоет — то это тысячи, а то миллионы, человеческих жизней.

Кассы всё-таки ближе к финансам…

Ну в начале прошлого века обанкротилось одно государство и в середине века мы потеряли сотни миллионов жизней. Не все так однозначно, политика и армия это продолжение экономики.
Ну так сервер тоже должен идти вперед на месяц. С точки зрения той кассы все должно существовать в будущем.

Это если удастся уговорить разработчика выделить такой сервер, и сделать прошивку, настроенную на него. Не забываем, что мы в данном случае не разработчики, а пользователи, которые хотят потестировать.
А зачем? Какие параметры так жизненно необходимы для касс, что не могут быть общими для всех или почти всех пользователей модели?

Тут мы приходим к понятию классов эквивалентности.Но кстати, на разном окружении( т.е. на разных ККТ) необходимо будет протестировать все заново, т.к. может отличаться железо, а значит о окружение.
Возможно, существует формальное мат.доказательство корректности алгоритма, просто каждая строчка кода становится золотой и сложность такого тестирования увеличивается в прогрессии.

Ну формальная верификация — она конечно является частью статического анализа, но она применяется только к тем частям, которые можно выразить с помощью математической модели. Не всегда это возможно, а в случае черного ящика, о котором речь шла выше — я даже не представляю, как возможно его описание
Возможно, просто очень дорого.

Как и пересчитать все песчинки на земле.

Ну так можно прикрыть любую безалаберность, зачем заботиться в безопасности ядерных станций, космических аппаратов, самолетов и автопилотов машин, если вы все равно не сможете поймать все дефекты? Вы готовы жить с ядерной станцией построенной по такому принципу?

Ну живем же. Иначе бы не было Чернобыля, Фукусимы или Трехмильного Острова. Насчет автопилотов — тоже, кажется в прошлом годубыло — что не смогли всех случаев предусмотреть. Вообще вы как-то странно переходите — почему-то решаете, что если невозможно отыскать всех дефектов — то тестировать не нужно. Это как-то странно. Тестировать нужно. Но и понимать, что дефекты все равно могут остаться — тоже нужно.

Или все таки процент имеет значение?

Какой процент, вы о чем? Вы как-то перескакиваете и я теряю нить вашего рассуждения. Вроде в предыдущих сообщениях ни про какой процент ничего не было.

Вообще изначальная тема была, что если установить тестовые кассы у пользователя, то это улучшит отказоустойчивость системы. Я считаю, что данное действие — не улучшит.
Вы не поверите… по этому принципу сейчас работают ВСЕ атомные станции! Вот возьми наугад любую реакторную установку и везде можно найти свищ в первом контуре… не говоря о более мелких дефектах, таких например как негерметичные трубки в главном теплообменнике — примерно около сотни трубок из 16000 дефектны уже прямо с производства и приходят на станцию изначально заглушенными…
Иногда речь даже не о деньгах. а о полной невозможности и бессмысленности тестирования.
Попробуйте прикинуть какое время необходимо на тестирование всех возможных вариантов операции сложения двух 32-х битных чисел, этакая очень простая элементарная операция которая сейчас считается абсолютно надёжной… но кто знает, может в ней есть косяк который проявляется при конкретной комбинации аргументов? По типу современного ROWhammer.
Речь идёт не о том что полное тестирование это дорого а о том что это практически невозможно!
А теперь представьте себе, как можно протестировать на производстве RAM-модули… к концу даже упрощённого теста модули просто разрушатся от физического износа.
Когда-то давно попадалась на глаза статейка про производство RAM, и ещё тогда пришли к выводу что память объёмом больше 128 байт(даже не кило- и мега- !) тестировать на производстве нет смысла вообще — иначе производство просто встанет из-за низкой производительности.
Ну смотря как тестировать. Что такого особенного в том чтобы прогнать всю память в несколько гигов в пару циклов чтения-записи? Буквально залить нулями, проверить что нули, залить единицами — проверить что единицы. Ну чуть сложнее сделать — через одну заливать, и потом реверс, чтобы больше ошибок увидеть.
Это займет не так много времени и ресурсов.
А вот полноценно гонять пару часов туда-сюда, проверять как она держит данные на относительно длительном периоде, нормально ли работает регенерация — это да, дорого.
Это выявит только явные дефекты. А такую фигню как зависимые ячейки — не выявит. а есть еще дефекты когда одна ячейка зависит от состояния двух других — если проверять отдельно дефект не проявляется, а если одновременно — они меняют состояние третьей. Причем это может быть даже не соседняя ячейка а совсем в другой странице памяти, просто она физически оказалась на соседнем слое и имеет утечку на соседние ячейки.
по хорошему, надо проверить установку ВСЕХ ВОЗМОЖНЫХ комбинаций состояния памяти. Учитывая что современный чип памяти имеет на борту как минимум 16гигабит… представь себе брутфорс счетчика на 16 миллиардов бит. Я чесно говоря вообще не уверен что в мире вообще есть хоть один чип памяти без того или иного дефекта — как правило он настолько причудлив что не проявляется, а если и проявляется то отрабатывается схемой ECC или на чём-то некритичном(например результат вычисления с повреждёнными битами числа отловить никак нельзя, только параллельной проверкой на другом оборудовании) и попросту остаётся незамеченным(ну подумаешь, проги периодически сбоят на ровном месте — это считают за программную ошибку).

Так вот, как итог — полная проверка чипа памяти на 512 бит по сложности сопоставима с брутфорсом 512-битного ключа шифрования на ASIC. И это без учета вероятных утечек заряда в ячейках памяти.
Все остальные тесты — лишь сокращённые версии… и тем не менее, возьмите тот же самый MEMTEST86+ — он память и то проверяет блоками по 4 мегабайта!
Вы конечно несколько утрируете, но в основном я с вами не спорю, а только уточняю. А так то:
А вот полноценно гонять пару часов туда-сюда, проверять как она держит данные на относительно длительном периоде, нормально ли работает регенерация — это да, дорого.
Нисколько не утрирую. Где-то в районе 2000-го я много читал про тестирование микросхем памяти. Все современные тесты памяти — не полные, и направлены на выявление конкретных статистически значимых дефектов. А теоретически, дефект может проявляться так что изменение одной ячейки памяти произведёт изменение бита вообще в другой логической области памяти, никак казалось бы не связанной с исследуемой ячейкой. Причем сама исходная ячейка в отдельности может показывать признаки вполне работоспособной.
И в своей жизни сталкивался с модулем памяти который сбоил, но тест памяти MEMTEST86+ не выявлял ошибок, вероятно, из-за ограничения на размер тестируемого блока(программа тестирует память отдельными блоками по 4Мб, кажется, и если ячейка вызывает связанный дефект с ячейкой вне пределов этого блока то он обнаружен не будет) и только память с блоком коррекции ошибок способна была бы обнаружить проблему и то только в случае когда записываем один бит в память и считываем ВЕСЬ объём памяти на предмет наличия изменений. А для модуля размером в 1Гб, например, это потребует порядка 1E+12 операций чтения. Ну, несколько многова-то однако.
1Е12 операций последовательного чтения при тактовой частоте в районе 2 ГГц должен выполниться за 500 секунд?
Ошибся, да. порядка 1E18-1E20 операций. И реально память работает на частоте 200-400Мгц. Это кеш L1 в процессоре может работать с такой скоростью, но мы же не кеш проверяем…
Капец, так позорно прогреметь на всю страну. Штрих-М, мы тебя не забудем!
Пара вопросов автору.
1. Нельзя было с прибора (без ком-порта) включить автообновление?
2. Автообновление — это зло или добро? Или правильный все же компромиссный вариант — автообновление из своего управляемого репозитория?
1. Можно было, только об этом надо было подумать за день до ошибки.
2. Автообновление — это вечный ответ «да» на вопрос «Почему?».
  1. Автообновление в ккт поступающих с завода — выключено, писанина в сми это обман.
    1.1. Для автообновления нужда сд-карта которая есть на УМке и некоторых ККТ, но не на всех, т.е. работает это ровно для определенных моделей ККТ.
А вы не могли продолжать продажи таким ухищрением: покупатель выбрал игру, продавец прямо в присутствии покупателя предложил оформить заказ на сайте с оплатой онлайн и выдачей в текущем магазине. Даже сам может оформить за покупателя, чтобы ускорить процесс.
Понимаю, что это потеря времени, но все-таки не полный простой.
С Магнитом понятно так не сделаешь, но Мосигра вполне могла бы такое предложить.
Я вот прямо сейчас морально не готов объяснять архитектуру и дистрибуцию. Просто поверьте, проще починить кассу, чем так делать.
А нет вообще никакого бумажного бекапа? Давно с кешем не работал, но помню раньше в Украине было предусмотрено что при поломке кассового аппарата — достаешь специальный бумажный блокнотик (бланки строгой отчетности) и работаешь ручкой в нем.
В свете того что второй чек стал цифровым — ну обязать после восстановления забивать эти чеки специальным чеком корректировки. Вроде очевидное и универсальное решение. а то так то узких мест много.
Так-то легко можно задолбаться в продуктовом магазине каждому выписывать чеки…
Ну варианты могут быть разные. Лишь бы бы были. даже подробно заполнять все товарные позиции и на счетах считать НДС со скидками — выгоднее чем просто сидеть без продаж.
Однако по нормальному — записывать только общую сумму чека без разбивки на НДСы и акцизы ибо это бекап а не основной вариант учета, т.е. просто первичка, чтобы продавец не «забыл» записать после восстановления. в таком варианте можно и в продуктовой сети работать.
День, когда прокрастинация спасла нам день продаж :)
Мы до сих пор на ЕНВД и Патенте без кассы :) тянем до последнего. Пока не нашли решение, которое бы нас устроило.
Инсайд подтвердил, что ошибку искусственно заложил увольняющийся программист.

Не важно, что с ним сделают теперь. Теперь все знают, как делают code review в Штрихе
mbr.livejournal.com/521344.html

Так в чем все таки заключалась ошибка? Запасные кассы не спасали? (Обычно они долгое время хранятся на складе и прошивки на них не самые свежие, так, что теоретически на них могли быть прошивки без ошибки)

Работать без кассы нельзя.
Лол. На наших продуктовых рынках годами так работают.
ЕНВД давал возможность работать без кассы в регионах в ряде отраслей. Сейчас всех тянут на кассы, и, по идее, скоро почти все будут на них.
На фотке кабель c разъемами DB9(DE9). Нуль модемным он мог бы быть, если бы там, как минимум, RX-TX, были взаимно перекрещены, но на фотке этого не видно.
разве я не написал, что на фотке этого не видно?

смысл поста был (подразумевался) в том, что «нульмодемные» кабели, раньше обычно применяли для соединения двух хостов. для соединения хост-контроллер, обычно, применяли просто «модемные». но, поскольку ничего (без рентгена) не увидеть, однозначно можно только утверждать про DB9.
Касса — полноценный хост, а не периферийное устройство, в ней же процессор есть. Так что скорее всего и правда нуль-модем.
Тем временем ФР Пирит, спокойно выполняли свою работу.
Помнится в 2000 производители материнок начали делать двойной БИОС. Что бы можно было бы откатится до прошлой прошивки. Некоторые особо интересные решения предусматривали обновления прошивок 2-3 способами.

Может и производители касс придут к давно разработанному решению.
Сомневаюсь в этом. Что для Штрих, что для Атол нужны ЦТО(Сервисные центры). Как канал дистрибуции, первая линия тех. поддержки, да и источник дохода. Насколько я помню ЦТО платит производителю с какой-то периодичностью какую-то сумму :-) Следовательно отдавать обслуживание техники в целом, и обновление прошивки в частности, кому-то другому (пусть даже это конечный пользователь) никому не выгодно. ЦТО ничего другого делать не умеют и не хотят, они привыкли к обязаловке во времена старых касс, когда клиенты сами за ними бегали и подписывали договор на обслуживание. А производители делиться прибылью и содержать такие центры не спешат.
Проблему 20.12.2017 можно было бы легко решить выпустив какую-то утилиту для простой тетеньки в магазине — «Вот ваша касса нашлась, нажмите далее для его обновления… Готово». Но кому оно надо? Получается, что все и так выстроились в очередь на обновление прошивки за деньги. У кого не было договора на обслуживания в ЦТО теперь уже есть.
Таких как автор, которые самостоятельно (даже лишившись гарантии) пытались восстановить работу техники единицы.
Была бы на этом рынке здоровая конкуренция не было бы таких проблем.
Проблему 20.12.2017 можно было бы легко решить выпустив какую-то утилиту для простой тетеньки в магазине — «Вот ваша касса нашлась, нажмите далее для его обновления… Готово».
При наличии машины времени — да. Вы ими торгуете?
Если магазины потребуют компенсации за простой… то может и возникнет здоровая конкуренция.
Only those users with full accounts are able to leave comments. Log in, please.