Т.е. сколько живу в мире 1С, все время может быть ситуация, что касса не довела до 1с информацию, что чек пробит.
В итоге иногда бывают сбои, с ними разбираются.
Хотя нужно всего лишь опросить драйвер кассы перед повторным пробитием чека.
Получается, за эти 20 лет, этот вопрос никого не интересует.
Почему?
А в приснопамятной Магазьке вопрос решен, кстати?

(0) потому что "у семи нянек ..."

платформа 1С не умеет работать напрямую с ККТ и прочим ТО
используется прокладка в виде БПО
требуется "драйвер по формату 1С" для подключения к БПО
эти драйвера пишут хз кто в отличие от нативных драйверов ККТ

т.е. слишком длинная цепочка и слишком разное оборудования с разными возможностями/интерфейсами/драйверами
попытка причесать под одну гребенку не выходит, некоторые ККТ могут не иметь команды "опросить драйвер кассы"
и понятно дело она не реализована в БПО и драйверах-прокладках

А почему это должно волновать 1С, а не производителя кассы?

Хм,открыл ветку,не глядя на ТС,при открытии успел подумать,не Гений ли? Открылось,действительно,он.))

(2) А что тут может сделать производитель кассы если тут
https://its.1c.ru/db/metod8dev/content/4829/hdoc
нету?

(2) Или хочешь сказать что производитель кассы обязан пинать 1С чтобы они допилили проверку на пробитие чека?
Нюню.
По своему опыту пинания могу сказать что до сих пор 1С-ЭДО не умеет с Самозанятыми.

(2) ну кого-то это должно волновать. В конце конков производители пишут дрова под 1С:Совместимо и 1С могла бы сдлеать обратную связь от кассы в этот стандарт

(5) не знаю кто кого должен пинать, но кризис IT по этой теме затянулся

А как вообще решен вопрос о "синхронизации" пробития чека и проведения документа в 1С (пусть, например, это будет ПКО)..?
Каков общий алгоритм в 8-ке?
проводим документ, потом пробиваем чек? а если чек по какой-то причине не пробился?
как сделанов взаимодействие двух событий - успешность проведения и успешность пробития на ккм? просветите, плиз.

(2) А что может производитель касс если он выдал эту инфу, а 1с не записала ее (вылетела, транзакция и т.п.)?

(8) В 8-ке эти два события никак не связаны между собой.
Т.е. перед тем как пробить чек ПКО уже должно быть проведено (данные для чека берутся из движения, а не из документа)

(6) Я только один не могу понять о какой еще обратной связи идет речь? В типовой она есть и работает, после пробития он от кассы получает номер чека и сохраняет у себя его. Что еще нужно то? Плюс в качестве обратной связи есть X отчет и тому подобное

(11) Алексей, мелко плаваете, глубже надо копать.
Пробитие чека - это транзакция в разнородных средах.
Состоит из двух сред - в 1С и в кассе.
Сначала 1С сохраняет и проводит чек.
Потом дает кассе команду пробить.
Получив ответ от кассы, вносит информацию о фискализации чека в специальный регистр и помечает чек пробитым.
Сбой может быть на любом участке цепи.
Например, касса пробила чек, но не передала его в 1с.

Поэтому 1С прежде чем пробивать чек, должна спросить у ККМ, а не пробила ли она его, случаем.
Если ККМ ответит, что пробила, повторно не пробивать, а пометить как пробитым.

Аналогично и с открытием/закрытием смены. Если на ККМ смена открыта, а 1С не в курсе, она должна создать у себя новую смену, а не посылать пользователя в пешеэротическое.

Просто меня эта ситуация, конечно, кормит, но за честь IT-мундира обидно. Банльную вещь не могут договориться и реализовать.

Это все возможности для своего бизнеса

(12) в какой конфиги и документе такая последовательность?
В УТ11.5 и ПКО это не так

"1С прежде чем пробивать чек, должна спросить у ККМ, а не пробила ли она его, случаем." - что является идентификатором чека? Т.е. как касса должна понять что это один и тот же чек, а не просто 2 одинаковых? И главное нафига её эти знания? Ей дали команду, она пробивает, задача кассы пробивать, а не хранить базу чеков.
Более того если это реализуют то все равно пользователь сможет пробить на РАЗНЫЕ кассы. Опять будешь говорить что кассы должны общаться между собой и опрашивать другие кассы, даже отключенные на предмет пробит ли чек?

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

Плюс не просто писать чек аннулирован, а более подробно что тег 1228 (ИНН покупателя) заполнен не верно, и предлагать варианты решения.

Да еще бесит что нельзя пробить "очень большой чек". Размер фискального документа (количество байт) ограничен, а значит при попытки пробить чек на 250-300 строк мы гарантирована получим аннулирования чека так как полученный размер превысит максимально допустимый размер данных. И узнаем мы об этом после того как на кассе будет напечатано 250 позиций, потом без объяснения причины - чек аннулирован". Так никакой бумаги не напасешься, а 1С сволочи не хочет ничего в этом направлении делать.

(17) а сейчас как если смена открыта более 24ч?

(16) хранитб базу чеков касса обязана

(18) через БПО при попытке пробить чек просто ошибка

(16) Алексей, выключи адвоката дьявола и включи мозг. В данной задаче база чеков не нужна. Нужен результат пробития последнего чека. И да, можно передавать гуид чека, не вижу проблем, почему нет.
Вот в результате такого подхода, который можно назвать "ачётакого", в 1С и нет качества, которое есть в кассах, которые например стоят на супермаркетах. Там такие штуки АВТОМАТИЗИРОВАНЫ. А это наша цель, Шура, автоматизировать, убрать человеческий фактор.
И да, не пробивать чек, если смена больше 24 часов (хотя этот кейс счас нормально отрабатывается).

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

(22) и как ты данные из ККТ прочитаешь?

(23) не понял вопроса? вообще-то ККТ предоставляет очень много данных через драйвер. Ты о каких конкретно данных?

(21) не путайте узкоспециализированный программно-аппаратный комплекс с универсальной как плоскогубцы 1Синой.

(24) Ты плаваешь в теме раз не понял.
Открой ссылку из (4) и изучай до понимания.

Опять Гене типовые от 1С попаболь доставляют... Тяжела судьба 1С ассенизатора...

(0)Почему 1с не внедрит кнопку "Сделать всё"?)

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

(12) ключевая фраза "получив ответ от кассы"

(29) Ритейл с 10 тыс. касс вполне себе использует фронт на 1С, только там не типовые от 1С, конечно.

В свете цифровизации всего думаю этот вопрос должен уже отпасть.

(31) ну, нетиповые - это почти тот же случай что специализированный софт. Там может быть доведено до ума все необходимое сторонними, сильно заинтересованными в результате, разработчиками.

(33) Ага. Там атолу и штриху ошибки в драйверах выставляют, а Честный знак у них консультируется 😄

(26) я уже отвечал, что (4) - это не святое писание и требования надо расширить.

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

(31) и считывают обратку от драйвера, поди.

Кстати, всё то же самое касается и автоматизированного эквайринга.

(37) А как иначе в 1С? Но тут уж куда деваться, переход на что-то другое на порядок дороже будет.

(35) И кто будет расширять? И как ты это заставишь всех производителей ККТ делать?

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

(40) с основными договориться, остальные сами или просто будут несовместимы с версией N+1

(40) да, давайте оставим как есть. Ведь лошади так хороши, зачем нужны паровые и бензиновые движки. ага. Все так.

(42) слова не мальчика, но мужа. Так и происходит прогресс в IT

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

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

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

(45) можно постепенно добавлять сперва как не обязательное требование. Если касса будет давать обратную связь, меньше ошибок будет у пользователей.

(45) кстати, да, ГУИД чека рулут. При попытке пробития чека повторно, касса выдаст ошибку "Чек уже пробит на кассе", ее можно проанализировать. Тут кстати, даже протокол менять не нужно.

Сейчас у нас получается множество преобразований.
Во-первых,данные чека получаются как массив вложенных структур по данным документа и базы.
На основании этих данных формируется xml,формат которого придумала сама 1с причем для любого оборудования.
Xml передается компоненте драйвера,которая его разбирает и превращает или в набор команд формирования чекп или в json для выполнения формирования чека (последний потом преобразуется драйвером в набор команд)
Команды передаются в кассовый аппарат (фискальный регистратор).
Причем,у каждой команды есть результат,и если там ошибка,то все завершается с ошибкой.
Далее,финальная команда закрытия чека тоже возвращает результат,и онивозвращается драйверу и обратно в 1с.
И может быть успех,хотя реально кончилась бумага,и чек не напечатан.

(47) Геня подозреваю для тебя будет открытием что ГУИД может совпасть...

Я еще забыл,что вме команды передают в Фн последовптельности TLV из которых строится чек.
Кроме того,в командах есть дополнительные данные,которые хоть и не попадают в Фн,а следовательно в ОФД,но выводятся на печать и влияют на показание счетчиков ККТ.

(49)+ конечно ларька это не касается
а вот в крупной федеральной сети с десятками и сотнями тысяч ККТ вероятность этого сильно большая

(51) в одной кассе совпасть? А вы не боитесь, что вас убьет метеорит? ггг

(48) если чек не напечатан по бумаге, там можно повторить последний чек вроде как, это сейчас как-то решается.

(52) геня ты идиот
тупой
недоучка

Ты хочешь чтобы 1С формировала ГУИД чека и передавала его в ККТ для фискализации?
А память в ККТ для хранения всех пробитых ГУИД чеков ты лично за свой счет купишь?

(36) любая лишняя строчка кода влечет удорожание решения. Кому надо - доделывают, кому не надо - используют так.

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

(54) всех не надо, достаточно последнего. Хотя чеки за смену ккм и так хранит, буфера там небольшие нужны. Еще вопросы, Уотсон?

(55) там только корректно гуид чека обрабатывать и передавать его. Кода - мизер, так сказать. Но можно не решать и гнить дальше. Бабло то капает, чо уж.

(56) ты считаешь, что решение проблемы расхождения ККМ и 1С когда-нибудь будет ненужным? Алло?

(59) думаю, если это достаточно редко, то ничего страшного не произойдет.

(57) ты считаешь себя Шерлоком, который https://zen.yandex.ru/media/grimm/pochemu-sherlok-holms-schital-chto-solnce-krutitsia-vokrug-zemli-a-ne-naoborot-5ea881447963b23a2af237b2 ?

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

Думаю, когда ФФД придет к некоей стабильности, и версии 1.X перестанут появляться каждые пару лет - может, выдрочат все под какую-то одну. Лет через пять.

И да. Решение задачи избавления от ошибок при пробитии чеков очень проста.
Достаточно выкинуть БПО и "прокладку по формату 1С", вместо этого использовать нативные драйвера от производителя ККТ.
Там все есть.

(64) насколько я понимаю, именно так работают нативные решения типа того же фронтола...

(65) Так работают и кастомы с самописками на 1С.

(58) Геня, если твоим клиентам это надо - сделай и не жужжы, в чем проблема? У меня в конторе выписку загружают, вместо того чтобы платежки в 1С набивать, соответственно, я под это обработку банк-клиента переделал - разбирается НДС в назначении платежа, нумерация проверяется, еще куча хлама делается. Мне это надо. Остальным - не надо. Я ж про это не пишу на каждом столбе... На то нас и нанимают чтобы мы дерьмо подчищали.

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

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

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

(67) убогая попытка оправдать бардак в отрасли "сделай себе". Нет дружок, проблема системная

(70) то что можно, я не спорю, вопрос в том, почему эту хроническую болезнь ККТ-транзакции не решает 1С

(70) В 1С,как ни странно,нет восстановления после ошибки не только при работе с ККТ,а вообще везде.
Если документ не провелся - вылетает ошибка,а почему - не всегда очевидно.
Так что это традиция.

(72) так у 1С и спроси. Здесь вообще-то сидят люди, которые, помимо прочего, на недоработках 1С зарабатывают копейку себе. И пока 1С "в общем" проблему решает, а недоработок оставляет по минимуму, чтобы их не неделями, а днями и часами решать - к 1С не просто нет претензий, а наоборот, ей надо денег заносить.

Например,с весами еще более смешно.
БПО не позволяет передавать в них штучный товар,а часто это очень нужно.

(69) ну и чего тебя не устраивает? Можешь - доделывай и зарабатывай. Не можешь - отказывайся, других задач на твой век хватит.

В последней БП появился реквизит "ИдентификаторЧекаККМДляОбмена" Интересно зачем он

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

(11) Иногда бывает так, что касса чек не пробила, скажем кончилась контрольная лента, а в 1с он уже зарегистрировался.

(78) я в курсе, но размер памяти ФН на данный момент проблема

(80) Для супермаркетов разве что. Но там и 1с в качестве АРМ кассира не используется.

(80) для задачи из (0) достаточно хранить несколько последних, может даже 1 последнюю

(82) Для задачи из (0) ничего лишнего в ККТ хранить не надо.
Надо просто нормально драйвера ККТ использовать нативные

(83)+ нативные, без лишних кривонаписанных прокладок

(0) Странно такую тему видеть от программиста. Из разряда "почему современные игры делают не оптимизированными". Если бы была 1 вид ОС и 1 вид кассы, тогда то, что ты хочешь 1сники воплотить бы могли. А так, думаю тебе уже тут написали про драйвера и как это вообще работает. Другой вопрос что под ту же винду давно уже можно было бы придумать стандартные API что бы не было всей той дичи, что есть сейчас, но кто ж заставит всех производителей по всему миру следовать, плюс куда старое железо девать...

(84) если в драйверах все есть, то вопрос из (0) еще более уместен

(86) Еще один "гений"
Ты понимаешь разницу между:
"есть в драйверах каждого из производителей у каждого свой лисапед"
и
"единый драйвер по общему формату 1С"

(87) При чём тут единый драйвер по общему формату 1с? А что, вне 1с нет проблем со стандартами дров?
Просто единый формат выходного API. Ничего в этом сверхъестественного нет, надо что бы этот формат был разработан, принят и внедрён, плюс для совместимости придумать какую то програмную хрень. Но кто этим будет заниматься?

(85) Тут железная воля государства должна вводить стандарты. А если специально придумали такой бардак с кучей ОФД, с кучей вариантов ККМ для обеспечения кучи кормушек - чего вы тогда ждете?

(88) еще один
да откуда вы беретесь то?
да разберитесь уже в предметке, как 1С с РАЗНЫМИ ККТ единообразно работает по (4)

(88) >Просто единый формат выходного API

муахаха

(91) ну круто, чо, вместо того что бы использовать ГОСТ или международные стандарты у 1с какой-то свой. Это никак не отменяет всего того, что я писал ранее. Условно, решены же эти проблемы в тех же принтерах? Как то додумались до PLUG&PLAY.

(92) ыыы
ты и про принтеры оказывается нифуя не знаешь

ЗЫ Производитель операционной системы устанавливает стандарты
А далее производители или энтузиасты пишут драйвера принтеров

ЗЗЫ Под андроид и айос стандартов принтеров нет, в итоге херня какая то происходит

(93) *производители принтеров или энтузиасты пишут драйвера принтеров

(92) А вспомните, как первое время этот Plug and Play ругали. Прошел наверное десяток лет, пока оно стало работать без проблем.

(95) Plag&Pray

(96) *Plug&Pray https://www.youtube.com/watch?v=bTtizqtp0Fs

(93) Что я не знаю?
https://docs.microsoft.com/en-us/windows-hardware/drivers/print/generic-description-language
Блин, ты подтверждаешь мои слова, при этом прикалываешься надо мной. Что за шиза?

(92) плюх и плей - это только винда. Вы попробуйте в андроиде поднимите принтер произвольный, особенно не из первого эшелона.
Там в гугл плее такой зоопарк - мама не горюй. И половина работает не пойми как.

(98) Нихрена не знаешь. Ибо не виндой единой, есть еще линукс и мак и?

(99) (100) Я ещё в (85) написал: "Другой вопрос что под ту же винду давно уже можно было бы придумать стандартные API"
Ладно, это слишком тупо. Подтверждаете мои же слова, говоря тоже сцук самое но при этом "Нихрена не знаешь".

(100) Строго говоря, применительно к кассам такие наработки есть, и озаботился этим Атол. Я не знаю касательно 10-й версии дров, но восьмая умела работать с кучей ККТ, не только Атол, но и с тем же Штрихом. Но в случае если производитель ККМ был не Атол, нужно было заплатить денежку за драйвер.

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

(103) атол бы в купе с 1с разработали бы правильные дрова. остальные бы сами подтянулись или бы остались за бортом

но сейчас уже наверно просто боятся легаси поломать

(103) >>включить стоимость дров в стоимость касс, и вуаля...

А сейчас, по твоему, их бесплатно что ли пишут? Они и так включены в стоимость железа/софта.

(72) >> почему эту хроническую болезнь ККТ-транзакции не решает 1С

Тут ширше поставить нужно вопрос: почему это должна решать 1С? Не частый ты гость киосков-самообслуживаний. Посмотри на примере фаст-фудов, гостиниц, и прочих - которые сидят на "типовом" софте для терминалов (ркипер и прочие). Не уж то ни разу не видел - и ошибка транзакции, и касса открыта более ... часов, и неизвестная ошибка, и просто откуда-то поднятого по стеку выше - сообщения на буржуйском языке. Ни разу не было такого, что на пос-терминале оплата прошла, а тебе киоск ничего не сообщил и все ждет от тебя оплаты? Заметь, там нет 1С, а все, отчего то, тож самое, хотя вру - еще хуже. В 1сике нашем любимом ты хоть сам чот там покрутишь, поправишь и поехал, а там ты только что в тех.суппорт позвонишь, тебе тикет заведут и досвиданья. Кстати, там нет никаких "универсальных" дров под ккм. Все известные мне крупные сети с терминалами пилят свои кастомные дровки, максимально обходящие такие моменты + обслуживающие свою специфику.

(106) а это идея!
драйвера продавать отдельно и активировать в привязке к конкретной проданной ККТ

(107) Эээ. Все там есть, все эти ошибки. Просто сильно реже.

(109)+ Там особенность что нет постоянных обновлений как в 1С.
В итоге одна стабильная версия по нескольку лет стоит и пашет, пока нечто новое в ККТ не придумают.

(108) Драйвера вообще не нужны. Протокол обмена данными должен быть простым, как AT-команды диалапного модема.

(109) >> Просто сильно реже.

Нет не реже, просто если у тебя 1 касса, как у ТС - ты можешь за всю жизнь не столкнутся ни с чем. Когда у тебя 5000 касс - то у тебя просто есть бесплатный 8-800, куда ты звонишь по всем этим проблемам, и это уже не твои проблемы. Но, откинув лирику, хейт Г1С тут просто местечковый: 1С хотя бы ведет какую-то работу по унификацию  дров. А в без1сном мире - ну и кто какую унификацию по тем же кассам и дровам провел? Самое большое, кто самые продвинутые, описали формат XML на вход - кидай туда, лови ответ. А так - поглядите, какие дрова к кассам шли: *.dll и ман-книжка по разработке краткая. Играйся, не обляпайся. В этом плане, 1с с БПО ушла ото всего этого уже куда-то в космические дали, унифицировав обмен. Но, как всегда - 1сникам маловато этого, еще чет охота. То что Г1С просит, возможно и правда когда-то сделают, когда у производителей ККТ рынок сбыта ККМ под 1С будет сильно больше, чем не под 1С. Сейчас, никто в своем уме ничего этого делать не будет.

(112) Вот это я и называю "кризис IT". Все все понимают, но с грустным лицом говорят, что пользователи должны колоться и жрать, а то еще хуже будет. Ага.

(113) Отчасти согласен с подцеплением оборудования у 1С дело обстоит так себе, очень так себе, но с другой стороны, можно сделать это хорошо только для случая, если производитель софта и производитель оборудования одно и то же лицо. 1С этим заниматься не хочет, что, в общем, понятно. А как-то стандартизировать весь этот бардак иначе практически нереально.

(112) 1с как всегда ушла в сторону универсализации при этом растеряв половину вендор зависимых фич

+(114) Хотя для меня уже не первый год загадка, ну почему обработка работы с ККМ по семерку около трехсот строк, а в конфах на восьмерке - несколько тысяч, рассованых по паре десятков модулей, а результат один :-(

(116) Ваши конструктивные предложения?

(113) >>Все все понимают,

И ты поймешь, когда осознаешь, что у производителя ККТ есть основных 3 пути сбыта своих ККМ: встройка (терминалы, там нет 1С), сбоку-припеку отдельно, не отдельно, но автономно или в составе POS к фронтам не на 1С, и наконец, третий путь - источник твоего хейта - отдельная касса с подключением к 1С на базе типовой БПО (есть еще и без БПО'дрова, я о них выше писал). Вот этот третий путь сбыта, для производителей ККМ, должен перекрыть все остальные настолько, что они ажна полезут конструктивно что-то менять и автоматом пересертифицировать оные. Просто ты сильно далек от производства этих вещей. И поэтому, пока не будет ярко-выраженной экономической целесообразности или аналогичного нормативного регулирования, максимум что можно ждать - это поддержку очередного стандарта БПО в части маркировки или чет такого.

(116) Потому что в семерке не было стандарта для подключения оборудования, у тебя есть обработка обслуживания, у тебя есть *.dll, у тебя есть программа настройки кассы, все это должно биться по версиями и совместимости. Поэтому условный Мутол выпустит для тебя такой пакет сугубо под свою линейку, не забудь, драйвер еще скорее всего будет платным, и конечно, такое решение будет сильно "суше" универсального мета-БПО'шного. Не вижу, чему ты тут удивляешься так открыто?

(118) Я вообще фигею, как на ровном месте создают сложности. По сути, обычная отправка-прием через порт ввода-вывода файликов определенной структуры превратилась в многоуровневое коллективное велосипедостроение..

(119) отправка-прием через порт именно на прямую, это нулевые. Мейнстрим сего дня, как ты правильно пишешь, это гонения файло: на вход XML, а драйвер кассы переваривает. Это позволило абстрагироваться от программного API работы драйвера как такового, а свело все интеграции к формированию нужного XML и отправку онэ на ККМ. Это проще, чем погружаться на уровень абстракции ниже и возюкатся там, внизах, в этих аналах-кинках дров. Плюсом, это позволило удаленно через веб-сервер работать с кассой быстро и просто. Если ты припоминаешь, как производители решали эту проблему. А то что файло стало с учетом всей нашей нормативке и ОФДунов таким "не простым" - здесь вины ни произвоидетей ККТ, ни вендора нет. Таково общее нормативное регилулирование данной отрасли. Просто там уже давно не бывает.

(120) Ну так в чем проблемы отправить и принять файлики? Кидаешь файлик в этом самом формате ОФД (не зависящем от кассы), получаешь ответ от кассы опять же в стандартном формате с фискальными признаками.. Где здесь точка несовместимости, в упор не вижу.

+(121) Касса вполне могла бы эмулировать скажем MTP-устройство по USB, а если касса подключена по сети - то вообще WebDAV, позволяющие кидать туда-сюда файлы без необходимости драйверов.

(121) >>Ну так в чем проблемы отправить и принять файлики...в упор не вижу?

И я не вижу, ровно так все и работает.

(123) Ага, после того как кучу драйверов установишь и кучу настроек, специфичных для каждой модели кассы сделаешь..

(123) Я про то, что интерфейс взаимодействия с кассой чрезмерно усложнили не по вине формата ОФД, а просто государство пустило на самотек вопросы стандартизации именно протоколов взаимодействия, ограничившись стандартизацией форматов. А могли бы сделать по уму - чтобы всё без драйверов работало. Как флешки.

(118) не, я не пойму, как можно оправдывать наличие коричневой субстанции внутри дровишек тем, что паааанимаааешь, меняться сложно....
Надо было сделать маркировку - поменялись, как миленькие.
А облегчить жизнь юзверю - нет, мы не такие, мы на 5 копеек дороже.
Хотя все сводится к добавлению GUID чека в XML файл, отпрваляемый на кассу. Все, мизер.

(0) А в приснопамятной Магазьке вопрос решен, кстати?

почитай :

Урок № 33 "Округление в чеке (скидка, весовой товар) и копейка не сходится. Чек аннулирован"
https://clck.ru/sGZpf

(127) это не о том

(0) плохому танцору...

(129) а хороший танцор будет смотреть на страдания пользователей и рубить с них бабло? Не мой метод, прости. Это к обделенным баблом, есть тут такие жадные товарищи, вот один из Ейска, Вова.

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

(131) можно забить на страдания африканских детей, согласен. Тебе можно. Мне нет. Я не лишен эмпатии к пользователям, терзаемым кривыми изделиями.

(132) но сам плодишь кривое https://geniy1s.ru/otklyuchit-proverku-otriczatelnyh-ostatkov-organizaczii-pri-zakrytii-mesyacza-ut-11-4/

(133) а кривизна то в чем?

(134) В неправильном расчете себестоимости с вытекающей несуществующей прибылью.

(135) а, все на спичках экономите, перфекционсты, ггг... Ну вам и 0.0000000001 руб кривизна. ОК, суть претензии понял.

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

(136) Нэт дарахой! Это ты привык шаурмячные ларьки автоматизировать, а мы тут крупными производствами с интеркомпани и давальческим сырьем "рулим". И твои костыли выплывают в дикий бардак.

(137) аналогии, как обычно, хромают. Мы уже привычны..
(138) Хахаха, не смешите мои тапочки. УТ11 для крупных производств? Два чая этому безумному господину.

(139) Вполне успешно в УТ можно вести от 2 разных юрлиц, объединенных в одно предприятие "интеркампани". При больших оборотах купля/продажа + исправление доков поступления задним числом неизбежно приводит к отрицательным остаткам. И вот как раз таки твой "костыль" по отрицательным остаткам организации, приводит к заинтересованности тобой налоговой и несуществующей прибыли.

(140) еще одну хромающую аналогию подогнал. Адвокаты дьявола так забавны.

(139) а внутри ERP что в качестве торгового контура?.. разве не она плюс/минус помидорки?

(141) Уровень школьника начальных классов, которого ткнули носом в то что он не решил задачу, а подогнал к ответу на задней странице.

(142) Да черт с ним с ЕРП, геня-самоделкин понятия не имеет о минимуме бухгалтерии и партионном учете.

(143) (144) 0 бит, извини

(144) оно не услаждает твой слух, да, Сереж? :))

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

К примеру,итальянская касса Spazio Uno у нас стала Простор-1024ф.
Умела принимать команды с порта и отправлять обратно все действия,в том числе и строки печати чекп в момент его печати и ошибки.
Также принимала команды создания чека,но из-за ответа можно было видеть,что происходит на кассе.
В нашем же случае,все ФР отвечают только если их спросить,а получить текущую строку печати - никто не умеет.

(147) а еще ФН (фискальный накопитель) - это деньги из воздуха (при копеечной себестоимости неонки внутре продаётся за денежку, многократно превыщающую стоимость "рассыпухи"), ну и лицензии на каждый ККМ для печати ставки НДС :)

"Повышение ставки НДС с 18% до 20% (303-ФЗ) предполагает перепрошивку кассового оборудования до 1 января 2019 года. Для модернизации контрольно-кассовой техники Штрих-М ООО и ИП необходимо обратиться в сервисный центр производителя с заявлением об обновлении прошивки, а также для приобретения отдельной лицензии для каждой модели. После получения соответствующего документа следует осуществить апгрейд ККТ, с добавлением файла купленной лицензии, после чего техника будет готова к работе с НДС 20%. Для успешного усовершенствования ККМ лучше снова обратиться к специалисту."

(147) даже если ФР умеет только принимать, она возвращает код ошибки.
Если в нее передавать ГУИД чека, то при попытке пробить уже пробитый чек она может возвращать ошибку, что чек уже пробит.
Такой схемы достаточно для решения данной проблемы, не нужно ничего читать из ФР.

(149) ФПД йопта (фискальный признак документа). если по ошибке печати не вернулся из ФР ФПД в одноэс, в чем проблема пробить чек коррекции? если сальдо с бульдо по кассе и смене не сошлось?

(149) Что делать если ФР подключен к нескольким базам? И в принципе есть возможность послать одинаковый ГУИД?

(151) давать ошибку и нехай перегенерировывает :) На самом деле, одинаковых гуидов при условии правильной генерации их осью в соответствии со всеми рекомендациями - быть не должно.

(148) Шифрования. там самое дорогое лицензия ФСБ связанное с шифрованием

(152) в 1С ГУИДы это другое, поэтому теоретитски могут быть неуникальными

вот, даже дату и время из гуида получают https://infostart.ru/public/94234/

Возникла необходимость узнать, когда был создан документ или элемент справочника. Для получения информации используется уникальный идентификатор объекта в ИБ. Вот, собственно, и вся обработка.

PS: Дата и время показаны без учета часового пояса.

PSS: Дата и время можно получить только для ссылок созданных стандартными методами 1С (т.е только для time-based UID)

Уникальный идентификатор, созданный, например, так:

GUID = новый УникальныйИдентификатор

Времени не содержит ....

(154) вот даже "спрашивали-отвечаем" по UID/GUID и какая в опу разница

https://infostart.ru/1c/articles/635159/

(154) ну тогда просто выходит, что для чеков гуиды должны быть "настоящие", те, которые сгенерены по правилам. Также как и для любых других гетерогенных систем, где они отправляются в иное оборудование/ПО, чем 1С.