Что выбрать для ЕГАИС Розница? : ЕГАИС в опте и рознице

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

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

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

Просто весной где-то в обсуждении один из представителей РАРа говорил, что этого делать нельзя, что слип-чек и отправку в ЕГАИС нужно обязательно делать в одной программе, одной транзакцией. Ну, я и поверил. Видимо, что-то поменялось в королевстве

:( ничего не поменялось
все должно быть одной транзакцией, так по крайней мере звучит в доках на утм в разделе отправки с кассы
появилось только уточнение (в интервью какого то раровца), что печать куеркода не обязательно делать на фрк, можно на стоящем рядом принтере

Как понял ваш вопрос в том, можно ли фискальный чек (для ФНС) пробивать на старой фискальной кассе, которая изолирована от кассовой программы на компьютере. А продавец будет в кассовой программе, которая в компьютере, формировать чек для ЕГАИС и программа будет отправлять xml файл в УТМ и выдавать задание на печать слип-чека с QR кодом на принтер.
Если смотреть блок схему Приложение А (описание УТМ), то там задание на печать фискального чека выдает кассовая программа, а в данном случае это задание будет выдаваться вручную, т.е. будет разрыв связи между блоками 13 и 14. Наверное это не принципиально.

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

Ваша точка зрения понятна, поэтому собственно у меня и сомнения... Представители РАР, по сути, озвучили две противоположных интерпретации своего документа. Вот и пытаюсь разобраться.

мне честно говоря все равно как оно будет :), вот только утверждение "две противоположных интерпретации" мне кажется не совсем верно, если здесь речь идет про печать на принтере - принтер не отправляет запрос в утм - печатать - да - можно, а вот насчет запроса с др места там ничего не сказано, да и про отдельный принтер не было ничего официального, кроме заявления в одном из интервью (по крайней мере мне не попадалось - если есть - киньте ссылкой)

п.6 в официальном описалове утм-а
===================
По окончанию формирования чека в случае, если он содержит алкогольную продукцию, данные о чеке и алкогольной продукции передаются в УТМ. Перечень данных о чеке, передаваемых у УТМ, описан в Приложении Б.
Выбор момента отправки xml-файла в УТМ должен обеспечивать невозможность корректировки чека после этой отправки.
Рекомендовано реализовать формирование xml-файла чека и его передачу в УТМ первой задачей в едином блоке транзакций записи чека в базу данных, физическую память, ЭКЛЗ. Если от транспортного модуля получен положительный ответ - транзакция продолжается. Если не получен положительный ответ – откат транзакции и возврат в режим формирования.
===================
ключевое здесь на мой взгляд "Выбор момента отправки xml-файла в УТМ должен обеспечивать невозможность корректировки чека после этой отправки."

мне кажется если будет разрыв (выполнение операций на разных компах\кассах) могут докапаться на полном основании

На форуме ЦентрИнформа в теме "Печать чека с QR-кодом на принтере чеков" есть косвенное подтверждение от участника форума:

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

Мне тоже. Главное, чтобы была определенность - как оно будет. И вот эта определенность в документации отсутствует напрочь (не говоря уже о комментариях ответственных лиц). Возьмем самый первый абзац из параграфа 2.1 тех. требований версии 2.0.3. (или 1.0.13 - я так и не понял, как они у них называются - на титульном листе одно, в колонтитулах - другое - и так у них во всем):

В этом крошечном абзаце уже имеется неопределенность :

1) О каком чеке идет речь? Глоссарий к документу не содержит определения, значит обращаемся к законодательству, где есть понятие "кассовый чек" - это бумажный документ, который покупатель получает при покупке. Должен ли я понимать эти требования так, что моя ККМ на КАССОВОМ чеке должна печатать этот 68-значный идентификатор? Должна ли машина записывать эти данные в фискальную память? Скорее всего нет, но это значит, что данные будут сохраняться не "в чеке", а где-то еще - в базе данных кассового или товароучетного ПО, на слипе, в базе УТМ и ЕГАИС - где угодно, но не в чеке. Но чуть ниже мы видим "на самом чеке должна быть напечатана информация в виде qr-кода" - так все-таки "на чеке" или "на слипе"?

2) Какую информацию нужно "сохранять в чеке". На марке вообще-то много разной информации. По комментариям от РАР вроде бы понятно, что имели ввиду исключительно 68-символьный код, считываемый с PDF 417 штрих-кода, но в самом документе это совершенно не очевидно. Например, читаем:
"2.2 Состав информации на марке"
Где на марке EAN-код? И зачем, с т.зр. регистрации в УТМ, нужен этот EAN-код? Ведь в последней версии в схеме xml-документа, передаваемого в ЕГАИС этот показатель сделали не обязательным. И понятно, что этот код нужен только продавцу для его внутреннего учета.
Ну и т.д., там еще огромное количество всякой ерунды - мелкой и не очень. Например, в примере PDF-417 читаем "Символы представлены цифрами и строчными латинскими буквами". При этом никаких строчных букв там нет, а есть только прописные. Значит ли это, что нужно перевести в строчные перед отправкой в УТМ или это значит, что кто-то пропускал уроки русского языка в школе? Или, в приложении А, если следовать "детальному описанию шагов схемы", то, в соответствии с п. 12 и 14 система должна слип напечатать дважды - до регистрации в фискальной памяти и после нее. Понятно, что это все косяки автора документа, но в целом возникает вопрос, если этому верить нельзя, то на чем вообще основываться, принимая решения.

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

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