Цель: не допустить двойного пробития чека.
По сути я указываю в некий реквизит GUID чека.
И если чек пробивается, то повторная попытка пробить такой чек заканчивается неудачей.

Потому что если такого нет, то нужно по идее подымать последний пробитый чек, как-то анализировать, это тот же самый чек или нет?

https://integration.atol.ru/api/#otkryt-chek - тут можно установить доп. реквизит пользователя, но там тип bytearray
как с ним работать?

Хотя наверное, можно поступить проще - перед пробитием чека продажи фиксировать количество чеков продажи в базе + 1 в регистре по кассам ЧислоЧеков. Там же фиксируем документ пробития.

После пробития чека продажи обнулять этот показатель.

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

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

Что-то типа такого.



Для запроса количества чеков необходимо вызвать метод queryData() с типом запроса LIBFPTR_PARAM_DATA_TYPE равным LIBFPTR_DT_RECEIPT_COUNT и указать тип чека LIBFPTR_PARAM_RECEIPT_TYPE.

Тип чека (LIBFPTR_PARAM_RECEIPT_TYPE) может принимать следующие значения:

LIBFPTR_RT_SELL - чек прихода (продажи);
LIBFPTR_RT_SELL_RETURN - чек возврата прихода (продажи);
LIBFPTR_RT_SELL_CORRECTION - чек коррекции прихода (продажи);
LIBFPTR_RT_BUY - чек расхода (покупки);
LIBFPTR_RT_BUY_RETURN - чек возврата расхода (покупки);
LIBFPTR_RT_BUY_CORRECTION - чек коррекции расхода (покупки).
Результатом этого запроса будет следующая информация:

Параметр    Описание    Тип
LIBFPTR_PARAM_DOCUMENTS_COUNT    Количество чеков    int

вот это генератор идей. то есть если я куплю дошик, и через минуту решу взять второй то уже низя? зачем это все? Проблема повторного пробития чека давно решена и вовсе не проблема. просто после пробития чека на ККМ в 1с возвращается ФПД и ФД, и если в документе в 1с они заполнены, то никакие операции с ним более невозможны

(3) мдя. я не пойму, это отсутствие опыта или желание продемонстрировать ЭГО.
А если ККМ пробьет чек, но не вернет ФПД и ФД (не успеет, разрыв транзакции произойдет)?
а? А? А, б...?

(4) значит программа должна выдать предупреждение и обратиться к системному администратору. Анализировать чеки, пробитые на ККМ как-то странно. А вообще есть такие бинесы, где практически все чеки идентичны по номенклатуре и сумме. Как тогда быть?

(4) да нет никакого желания демонстрировать эго. просто наблюдаю за последними темами и не понимаю одного, почему не изучить сначала как сделано у других, а потом подумать почему именно так. Если что-то непонятно, то это не значит что это непонятное плохо

ну и напоследок, решение связанное с оборудованием должно быть максимально независимо от этого самого оборудования. ну допустим сегодня у клиента Атол, а завтра Штрих, Дримкасс и тд еще пара десятков брендов

(5) А как программа поймет, что чек в неопределенном состоянии?
Она ставит чеку статус: ой, счас буду пробивать.
Потом пробивает.
Потом все заканчивается неудачно.
В 1С у чека статус - ой, счас буду пробивать.
Можно ли повторно пробить подобный чек? А ХЗ.
Поэтому да, только вмешательство суперпользователя. Но его время дорогое и это не та операция, чтобы его привлекать, касса располагает всей информацией, чтобы справитсья сама.

(6) и как же сделано у других? Правильный ответ: никак. На это просто забито.

(7) у меня у этого клиента исключительно атолл 10. Думаю, количество чеков по типу любая касса выдает. Ну и GUID чека было бы неплохо
протолкнуть в отрасль. но это несбыточная мечта.

"Двойного чека" - непонятное определение, от слова совсем.  При условии, что  операция в ККТ завершена, у чека есть признаки: дата, время ФП, есть запись в ФН. И повторить это, в пределах этого ККТ+ФН, невозможно.

...время, ФП....

он не понимает одного, что если в 1с не сохранились данные о пробитии чека по какой-либо причине, то и его механизм тоже не будет работать по этой же причине. А сама идея поиска чека в ККТ среди пробитых вообще утопия, потому как 1 - нельзя точно сопоставить чек в 1с и чек в ккт только по его составу невозможно, 2 - перебор чеков в ккт -  это жутко долго по времени, представим что чеков под 1000 за смену(но об этом точно никто не думает)

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

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

Бессмысленно пытаться автоматизировать ВСЁ. В подобных ситуациях проще не думая сделать чек коррекции (возврата и т.п.), чем выламывать мозги, пытаясь пихать в невпихуемое. Железка, подключенная к компу, работающая через безумную туеву хучу программных слоёв и прокладок, может вы**нуться в любой момент и хер его знает чего там не так и не эдак. Парсить глазами логи и в результате остаться на том же месте))) Поэтому - выбили чек коррекции и дальше спокойно работаем. ))

(4) еслипродажи с людьми с то все чеки в явном состояни всегда: в очереди, пробит, пробивается. ещё из кассы можно данные доставать, но тебя несет, ты далек от темы.

(12) не микроскопична. Если у тебя хотя бы 10 точек, будет выстреливать.
(14) автоматизировать надо то, что можно. Почему бы не пропихивать GUID чека, это решило бы проблему раз и навсегда.

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

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

(16) Нет никаких "розовых фей". Всё высказанное мною - это опыт эксплуатации более полусотни рабочих мест. Во всём должна быть разумная достаточность, а тем более тратить время на ловлю редких (!!) блох в чужих программно-аппаратных комплексах, в которых есть свои ошибки, как известные, так и неизвестные. Страдающий бухгалтер от несведённого эквайринга - это весьма неопытная женщинка )) На таких обращать внимание - только время терять.

(19) маловат опыт, а блохи вредные. Ладно, реализую проверку через количество чеков.

GUID чека есть при работе кассе в режиме web сервера.
Но по моему проблема из пальца высосана. Сотни тысяч касс живут без этого

Пусть еще в ОФД звонят после каждого пробитого чека )

(18) а при чем тут эквайринг?

(23)ну видимо проблемы бывают при пробитии чеков оплаченных картой
Количество чеков ничего не дает. Надо снимать X отчет и крыжить его с 1С

(0) костылестроение детектед

(8) >  Ну и GUID чека было бы неплохо

ФП любой ФР возвращает после пробития ФД (чека)



"ФД и ФП это фискальные признаки.

ФД — фискальный документ

ФП — фискальный признак данных, находящийся в конце чека

Наличие фискальных признаков означает, что перед вами фискальный чек и факт платежа зафиксирован в налоговом органе. Фискальный чек может быть напечатан только на контрольно-кассовой машине (ККМ), прошедшей госрегистрацию.

Нефиксальный чеки может быть напечатан на любом принтере, и не имеет юридической силы.

КЭП

(23) если дублируется чек с оплатой по безналу, потому не сходятся показания кассы (ОФД) и эквайринга, приходится выискивать вручную.

(21) то что ты чего то не встречал, не значи, что этого нет. Я эту проблему регулярно наблюдаю. Всем плевать - и 1С и производителям касс, пользователи молча кушают и терпят.

(24) как же ничего не дает, очень даже дает, покури алгоритм выше.

(26) боже мой, насколько ты не "вкурил" о чем вообще я спрашиваю в посте. Ну сделай усилие, пошевели мозгом. Реально, смешно читать такие ответы.

Ну вообще идентификатор чека это его номер. Допустим в 1С есть последний чек с номером N. Можно опросить ККТ на наличие чека с номером N+1, если такого нет, значит в ККТ чек с номером N последний. Значит можно пробивать.
Но все эти проверки, они же не просто так не делаются. Проверка занимает время, а обращение к ККТ не мгновенное.

(30) > Цель: не допустить двойного пробития чека.

видишь цель - не видишь препятствий

да хоть 10 чеков пусть печатают одинаковых

"чек пробит ошибочно, так как у покупателя оказалось недостаточно денег" :))) я такую объяснительную видел от кассира

(30) если у чека есть ФП в 1С, значит он был пробит на ФР.

бинго!

(32) Галя, у нас отмена =D

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

(31) не экономь на спичках, там копье по времени.

(33) мда.... потрясающая незамутненность. это достаточное условие, но не необходимое. Касса может начать сообщать ФП в 1С, но не успеть это сделать. Усёк, юноша?

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

КАК кто-то писал выше у нас сделано через СтатусПечатиЧека.
т.е. отправили на печать, если касса вернула ФД и ФП статус Распечатан.
если по каким то причинам ККТ не вернула признак Чека, то кассир запрашивает из кассы краткий отчет по сумме и суммы чеков пробитых в 1С.
Если суммы сходятся значит на ККТ пробитие не прошло. Можно пробивать еще раз. Иначе зовем Администратора и он сопоставляет Чек в1С и чек в ккт,  

НО это очень редко встречается.

(39) слабое место в этом звене - кассир. Может забыть, не так интерпретировать отчет и тп. Нельзя доверять такие вещи людям.

(37) "...Касса может начать сообщать ФП"

гениально... может начать.
ФП, если правильно, получается после пробития чека запросом к ккт.

(40) все решается ДенжноАдминистративными приказами. "слабое звено" сразу становится СИЛЬНЫМ.

(37) проблема в (0) у вас высосана из среднего пальца

У Гения неспособность слышать собеседников до такой степени - это уже предмет разбирательства медицины )))  Или ему потрындеть не с кем )))

(43) Да не из пальца, из отверстия.

(42) резьбу можно и сорвать, если перекрутить? Зачем напрягать человека задачей, которая легко автоматизируется. Упёртости 1С и разработчиков касс в этом вопросе не понимаю. Все решается как минимум, добавлением тега GUID чека.

(44) я слушаю не собеседников, а аргументы. на послания содержанием "0 бит" мне нечего ответить.

Просто касса это не СУБД )

(48) транзакции применимы не только в СУБД.

Определить документы со статусом подготовлен к фискализации (название условно) и не имеющие данных о самой фискализации. Провести поиск в кассе по косвенным данным - дата/время/сумма. Предложить пользователю сопоставить данные - окончательное решение должен принять человек.
В системе зафиксированы документы подготовленные к фискализации и не имеющие сведений о ней. В кассе найдены операции без соответствия в учётной системе. Сопоставьте....

Ну и подумать сценарии при замене кассы, ФН или базы 1с

(50) тут ключевое "предложите пользователю". т.е. нагружаем продавца функциями администратора в то время, когда можно обойтись без этого. Я реализую подсчет чеков и напишу разгромную статью о кризисе IT в ККМ, пусть Атоллу и Штрих-М и 1С будет стыдно.

(51) давай, займись уже чем-нибудь

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

(53) и как это поможет решению завершенности транзакции? точно так же нет возможности проверить статус чека.
и потом это решение из серии "из пушки по воробьям".
(52) да, работаю над этим проектом.

(54)Что значит нет возможности проверить статус чека? Именно эта возможность и есть, посылается запрос, анализируется ответ
Какая тут пушка? В чем пушка?

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

(56)ясно )

Считайте чеки )
Допустим у Вас 2 чека ККМ без номера, и один пробит, а второй нет. И как определите какой не пробит ?)

(58) кури выше алгоритм по количеству чеков. Что в нем не понятного? Перед каждым пробитием чека вызывается этот алгоритм и все в ажуре

(53) Работа с Веб сервером Атола становится "мутная". Даже лицензию на работу кассы с Веб сервером уже не получить самостоятельно. А партнер Атола прислал какую-то бета версию лицензии на месяц.
И Гуид в Веб сервере не для чека , а для задания. Я перед пробитием чека ищу его в своем РС и если задание для Веб сервера Атола в статусе "в прогрессе" или "готово", то просто повторяю попытку получение результата задания от Веб сервера Атола, а не посылаю чек на новое пробитие на кассе.

+60 Я кстати, такую схему работы Веб сервера Атола применяю для своих веб-сервисов. Весьма удобно. Не держишь клиента на соединении (что может быть весьма долго), а пишешь его запрос в логи и возвращаешь ему Гуид его запроса и статус 200.

(61) индивидуалисты могут использовать классные идеи, а отрасль нет. В IT кризис.

(60)так я и не говорил, что надо пробивать повторно. GUID для задания, но он решает поставленную в теме задачу

(63) Ничего оно не решает и не решит в любом случае. Потому как вебсервер точно так же работает через точно тот же самый драйвер 10.х.х.х  Толку менять прокладки, если основа одна и та же. И Серёжа не может дотумкать, что он работает не с ККТ, а с ответами от этой ККТ. И то, что она ему ответит - это ваще не точно )))  Куле толку считать количество чеков, если он физически может быть не пробит. Или пробит, но его нет в ОФД. Или не пробит, но есть в ОФД. Или пробит, есть в ОФД, но нет в ФП. И т.д. и т.п. Так можно вечно ебстись, получая удовольствие, но это не точно! )))

(64) ты не понимаешь, что даст GUID чека? Как минимум, он не даст повторно пробить один и тот же чек. Отрицание реальности? Спор ради спора? или что?

(64)Абсолютно не понял Вашего категоричного утверждения. Причем тут то, что web-аервер работает через тот же самый драйвер? Через тот же, но по другому. В этом режиме работы задания хранятся в базе данных и к ней пишутся запросы о состоянии задания. Это совсем другая история. ОФД тут тоже мало причем, если чек пробит на ККМ, то он будет и в ОФД, даже если с ОФД нет связи, рано или поздно связь будет и чеки уйдут. И что такое "чек не пробит, но есть в ОФД"? Где не пробит? Я не сторонник этой задачи, считаю ее малозначимой, но тут уже спор о сущности вещей )

Кстати о птичках. Я просто давно этим занимался, забыл нюансы. По моему, при использовании web сервера проблема пробития уже пробитого чека решается автоматически. Сервер просто отвергает задание на повторное пробитие. Мне как раз пришлось специально организовывать возможность повторного пробития (при отладке, чтобы не плодить чеки ккм и другие документы, связанные с чеками)

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

(64) это конечно бред
Если фискализация прошла, но нет в офд, то будет как только касса отаравит данные в офд
Без фискализации на кассе ничего в офд не уйдёт
Что такое пробит, но нет в ФП я вообще не понимаю - есть понятие фискализация, оно подразумевает запись в фискальный накопитель, а будет выходить на бумаге теперь вообще второстепенный вопрос

(65) научился отправлять uuid на кассу?

(70) я работаю на реальной кассе через Атолл ДТО 10. После нового года пока пробивать чеки нельзя (даже с возвратом), так что жду, когда клиент оформит документы на кассу и можно будет пробивать. Передаю не гуид, использую подсчет количества.

Берешь хэш чека с вренем отправки - закидываешь  вдоп реквизит.

Но это всё бред, в реальности менеджер будет пинать чек до логического конца и гуиды тут не помогут.

Пробитие чека - это общение с внешней системой.
Весь процесс общения нужно разбить на атомарные блоки,каждый из которых можно потом проверить,если вдруг произошла потеря связи.
Далее, в служебный регистр пишем начало и конец каждой атомарной операции.
Теперь,если где-то произошел отказ,то быстро нахрдим участок,проверяем его выполнение,если результат неизвестен,а потом продолжаем далее.
Если к одной кассе обращается несколько пользователей,то весь обмен выносим в отдельныц процесс,и при наличии незаконченного,продолжаем сначала его,а только потом текущий.

(72) можно расписать сценарий этого пинания? менеджер может делать что угодно, но защита от дурака не даст задублировать чек.
(73) Спасибо КЭП, только почему это не делает ни 1С, ни Атолл. Рассчитывают на русское Авось, которое не работает на больших объемах?

(65) Где этот гуид взять? Его должна дать железка в виде ККМ (не драйвер, а именно ККМ!!). Пока этого нет (выдачи гуида ККМ-ом), рассуждать о чем либо бессмысленно. Собснно, даже если и будет этот гуид, все равно нет 100% уверенности, что всё в системе впорядке и всё пройдёт как положено.
(66) Вебсервер возвращает гуид задания, но это не есть гарантия того, что этот вебсервер безошибочно отработает это задание. Заметьте - через тот же самый драйвер и посредством тех же самых методов )  И я привёл варианты возможных глюков при реализации множества операций при пробитии чека. На любом этапе может произойти всё что угодно. Это невозможно предугадать и всё предусмотреть. Вот я про что )   Хотя вебсервер будет думать, что всё хорошо ;)
(69) Именно, что бред. Я описал возможные варианты глюков и ненормального поведения программно-аппаратного комплекса, связки железа с приложением через кучу программных слоёв. На любом слое могут быть сбои и т.д. и т.п.

(70)Никто не говорит, что web-сервер решает проблему. Ее ничто не решает (на мой взгляд и проблемы нет, если внимательно читали). Суть беседы в том, что именно этот подход самый емкий для решения объфвленной автором задачи. Задание послано кассе. Web-сервер ставит задание в очередь (c 1с-ным гуид чека), а дальше все что угодно может быть. Могут даже кассу украсть. Но чек 2 раза не пробъется, речь об этом. Вы ек сможете сделать 2 задания с одним GUID

(75) что значит бессмысленно?
Когда 1с намеревается пробить чек, она генерит гуид и передает его с данными чека в ККМ.
При повторном пробитии чека передается этот же гуид. И если чек уже пробит, будет выдана ошибка и чек не пробьется.
Элементарно.
Но отрасль почему-то не может это переварить.

(76) Я примерно про то же - проблемы в принципе нет. Нет, она вроде как и есть, но нормального решения нет.
(77) Бессмысленно именно потому, что задача не имеет решения по причине отсутствия аппаратных возможностей, без которых никак.

(74) нажал пробить чек, чек не вышел, опять жмет пробить чек

(79) и дублируем чек, лепота.

(78) я предложил индустрии нормальное решение. Готов услышать критику.

(81) Ты предложил Мысль(концепцию, стартам), но не решение.

2 недели уже обсуждаем ) когда будут результаты опытной эксплуатации?)

точно не помню, но у атола можно запросить из ФН (накопителя) номер последнего ФД (фискального документа) и у него получить ФП (фискальный признак), который и есть ГУЙ для чека, который так хочет Г1С

"Слева выбираем кнопку "Регистры", далее вверху по центру окна выбираем в раскрывающимся поле интересующий нас регистр, например "51 - Информация о последнем чеке в ФН". И жмем кнопку в средине окна "Получить регистр".

При этом мы получаем в нижнем поле окна утилиты - драйвера

Номер ФД
Тип операции (чек продажи-прихода)
Итог - сумма чека
Дата и время чека
Фискальный признак (комбинация цифр) <- БИНГО БОНГО ЁПТА!

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

а если ашипка, нужно через драйвер запросить номер ФД и ФП, если номер и итог по чеку совпадает и есть ФП - значит чек уже есть в ФН у ФР и тогда чек пробивать не нужно, но нужно ФП дописать в чек 1С

как-то так

Нуралиев жадно читает ветку. Судьба отрасли на кону )

(83) плюс статья на хабре, главное никак в прошлый раз - окончание пшиком

(82) а в чем разница? решение простое как два байта переслать.
(83) нет доступа к ФР пока что.
(84) познавательно, но я не нашел этого в описании API, можно ли прочитать эти регистры через API атолла?
(86) торопишься слишком

(87) > познавательно, но я не нашел этого в описании API, можно ли прочитать эти регистры через API атолла?

это всё объясняет. лепите костыли, так вы и денег заработаете и статью напишете на хабр и в 1С кинете камешек

(88) 0 бит

(84) окей. там есть информация о последнем чеке.


https://integration.atol.ru/api/#informatsiya-o-poslednem-cheke

Для запроса информации о последнем чеке в ФН необходимо вызвать метод fnQueryData() с типом запроса LIBFPTR_PARAM_FN_DATA_TYPE равным LIBFPTR_FNDT_LAST_DOCUMENT.

Результатом этого запроса будет следующая информация:

Параметр    Описание    Тип
LIBFPTR_PARAM_DOCUMENT_NUMBER    Номер документа    int
LIBFPTR_PARAM_FISCAL_SIGN    Фискальный признак документа    string
LIBFPTR_PARAM_DATE_TIME    Дата и время документа    datetime


Правда, в чеках у клиента (нетленка) ФП не хранится, но все же.

Непонятно из документации, является ли Х и Z-отчеты документами. Но по сути я буду смотреть на ФП и если он поменялся (последний) до и после пробития чека, то значит, чек пробит. Окей, можно отойти от подсчета чеков.

Достаточно только проверять последний FP до и после пробития чека.

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

(90) > Правда, в чеках у клиента (нетленка) ФП не хранится, но все же.

ну добавьте реквизит чека ФП (нетленка у клиента не треснет от этого). Это правильнее, чем ГУЙ в чек для упрощения жизни в отрасли

Какая-то 0 битная тема.
На поленился глянул требования к разработке от 1С, там есть команда:
ПолучитьТекущееСостояние (GetCurrentStatus)
В которой есть все.

(93) >ПолучитьТекущееСостояние (GetCurrentStatus)

в которой почти ничего нет :) 1С недокрутила, чтобы Г1С страдал

там  из интересного только

"Номер последнего пробитого фискального чека"

а ФП у пробитого фискального чека нужно отдельно запрашивать тады для (0)

(90) > Достаточно только проверять последний FP до и после пробития чека.

костыль в стиле Г1С. рабочий вариант

статью на хабре и в бложике нужно про страдания и 1С недокрутила

(95) но еще и хранить нужно ответ (как вариант тупо добавить в нетленку галочку булево "чек точно пробит"), ибо "до и после пробития чека" не запрещает пробить чек еще раз

(90) >окей

длина тормозного пути составила две недели :)

см (26), я предлагал ФП у чека получать вместо ГУЯ и хранить в 1С :)

(97) попробовал, ФП не выдается атоллом, поэтому использую номер чека. Его можно подставлять как раз в поле "Номер чека ККМ", так что будет еще и практическая польза.

Вот такой код выдает всегда ноль:

    Объект.setParam(Объект.LIBFPTR_PARAM_DATA_TYPE, Объект.LIBFPTR_FNDT_LAST_DOCUMENT);
    Объект.queryData();    
    Значение = Объект.getParamInt(Объект.LIBFPTR_PARAM_FISCAL_SIGN);

(95) 1С сделала метод, но сама его не применяет - он сделан в других целях. Поэтому про "не докрутила" формулировочка странная.

Самый надежный способ - передавать GUID чека, тогда не нужно костылей.

Ну может лет через 20 индустрия к этому придет.

(98) Атол не докрутил значит :)

(98)

попробуй такую загогулину (найди 10 отличий). я загуглил за тебя :)

Запрос информации о последнем чеке
fptr.setParam(fptr.LIBFPTR_PARAM_FN_DATA_TYPE, fptr.LIBFPTR_FNDT_LAST_RECEIPT);
fptr.fnQueryData;
где можно получить требуемое значение
fiscalSign := fptr.getParamString(fptr.LIBFPTR_PARAM_FISCAL_SIGN);

(98) >Вот такой код выдает всегда ноль:

Значение = Объект.getParamInt(Объект.LIBFPTR_PARAM_FISCAL_SIGN);

странно, а что getParamInt из строки должен вернуть? null ?

вот еще тебе семерочного кода, может пригодится :)

//Заберем номер чека (ФД) из ФН
fptr.setParam(fptr.LIBFPTR_PARAM_FN_DATA_TYPE, fptr.LIBFPTR_FNDT_LAST_RECEIPT);
fptr.fnQueryData();
НомерЧека = fptr.getParamInt(fptr.LIBFPTR_PARAM_DOCUMENT_NUMBER);

//Сформируем ссылку чека для QRКода
fptr.setParam(fptr.LIBFPTR_PARAM_FN_DATA_TYPE, fptr.LIBFPTR_FNDT_DOCUMENT_BY_NUMBER);
fptr.setParam(fptr.LIBFPTR_PARAM_DOCUMENT_NUMBER, НомерЧека);
fptr.fnQueryData();

ДатаВремя     = fptr.getParamString(fptr.LIBFPTR_PARAM_DATE_TIME); //дата+время в формате "ГГГГ.ММ.ДД_ЧЧ.ММ.СС"
t    = Лев(ДатаВремя, 4) + Сред(ДатаВремя,6,2) + Сред(ДатаВремя,9,2) + "T" + Сред(ДатаВремя,12,2) + Сред(ДатаВремя,15,2) + Сред(ДатаВремя,18,2);
s     = Строка(fptr.getParamDouble(1020)); //сумма по чеку
i     = Строка(fptr.getParamInt(fptr.LIBFPTR_PARAM_DOCUMENT_NUMBER)); //Номер ФД
fp     = fptr.getParamString(fptr.LIBFPTR_PARAM_FISCAL_SIGN); //Фискальный признак
n     = Строка(fptr.getParamInt(1054)); //Признак расчета

fptr.setParam(fptr.LIBFPTR_PARAM_FN_DATA_TYPE, fptr.LIBFPTR_FNDT_FN_INFO);
fptr.fnQueryData();

fn     = fptr.getParamString(fptr.LIBFPTR_PARAM_SERIAL_NUMBER); //номер ФН

QRКод = "t="+t+"&s="+s+"&fn="+fn+"&i="+i+"&fp="+fp+"&n="+n;

(102) ага, спасибо. ошибку понял. Но в принципе, уже работает с номером чека корректно, ФП все равно не используется в нетленке.

(104) ФП вообще-то полезная вещь при оформлении чеков коррекции

ну всем пофиг. в следующий раз

(105) у них нет чеков коррекции. Гггг.. Ну да ладно. Вот код итоговый.

КонтролироватьПробитиеЧекаПрограммой вызываю перед пробитием чека, снятием Х и Z-отчета.
Номер там получается не только чека, но и любого нефискального документа, но там в принципе, ничего и не печатается, кроме чеков.
Поэтому пока оставлю так, по уму надо переделать на номер последнего фискального документа (для универсального случая).



//Умное пробитие чека
&НаКлиенте
Процедура КонтролироватьПробитиеЧекаПрограммой(Объект, ДокументСсылка = Неопределено) Экспорт

    //Подддерживается только в Атол 10 ДТО
    Если НЕ ЭтоДрайверАтол10() Тогда
        Возврат;
    КонецЕсли;
    
    //Только если включен контроль пробития чека
    ТекущийПользователь = Получить.Пользователь();
    Если НЕ ЛогикаСервер.КонтролироватьПробитиеЧекаПрограммойПользователя(ТекущийПользователь) Тогда
        Возврат;
    КонецЕсли;
    
    //Берем номер последнего пробитого чека
    Объект.setParam(Объект.LIBFPTR_PARAM_DATA_TYPE, Объект.LIBFPTR_DT_STATUS);
    Объект.queryData();    
    Значение = Объект.getParamInt(Объект.LIBFPTR_PARAM_RECEIPT_NUMBER);
    //НомерСмены = Объект.getParamInt(Объект.LIBFPTR_PARAM_SHIFT_NUMBER);
    

    
    //Получаем сохраненный ранее идентификатор последнего пробитого документа
    СтруктураКонтроля = ЛогикаСервер.ПолучитьКонтрольПробития(ТекущийПользователь);
    
    //Если идентификатор последнего пробитого документа поменялся, значит чек пробился
    Если
        ЗначениеЗаполнено(СтруктураКонтроля.Документ) И  //Если есть сохраненная информация по прошлому чеку
        СтруктураКонтроля.Значение <> Неопределено  И //Для чека заполнено значение предыдущего номера чека
        Значение > СтруктураКонтроля.Значение И //Номер чека стал больше, чем был (на случай перехода через смену)
        НЕ ЛогикаСервер.ДокументПробит(СтруктураКонтроля.Документ)
        Тогда
            //Указываем что документ пробит и ставим ему номер чека
            ЛогикаСервер.УстановитьДокументПробитИНомерЧекаККМ(СтруктураКонтроля.Документ, Значение);
            ВызватьИсключение "Попытка пробить уже удаленный документ: " + ДокументСсылка;
    КонецЕсли;
    
    //Сохраняем идентификатор последнего пробитого документа
    Если ЗначениеЗаполнено(ДокументСсылка) Тогда
        ЛогикаСервер.СохранитьКонтрольПробития(ТекущийПользователь, Значение, ДокументСсылка);
    КонецЕсли;

КонецПроцедуры



&НаСервере
Функция КонтролироватьПробитиеЧекаПрограммойПользователя(ТекущийПользователь) Экспорт
    Возврат ТекущийПользователь.КонтролироватьПробитиеЧекаПрограммой;
КонецФункции

&НаСервере
Функция ПолучитьКонтрольПробития(ТекущийПользователь) Экспорт
    //Результат = Новый Структура("Количество, Документ", 0, Неопределено);
    Результат = Новый Структура("Значение, Документ", Неопределено, Неопределено);
    
    УстановитьПривилегированныйРежим(Истина); //Чтобы не контролировались права на регистр контроля чеков
    
    МЗ = РегистрыСведений.КонтрольПробитияЧека.СоздатьМенеджерЗаписи();
    МЗ.Пользователь = ТекущийПользователь;
    МЗ.Прочитать();
    Если МЗ.Выбран() Тогда
        Результат.Значение = МЗ.Значение;
        Результат.Документ = МЗ.Документ;
    КонецЕсли;
    
    Возврат Результат;

КонецФункции

&НаСервере
Процедура СохранитьКонтрольПробития(ТекущийПользователь, Значение, Документ) Экспорт
    
    УстановитьПривилегированныйРежим(Истина); //Чтобы не контролировались права на регистр контроля чеков
    
    МЗ = РегистрыСведений.КонтрольПробитияЧека.СоздатьМенеджерЗаписи();
    МЗ.Пользователь = ТекущийПользователь;
    МЗ.Значение = Значение;
    МЗ.Документ = Документ;
    МЗ.Записать(истина);
    

КонецПроцедуры



&НаСервере
Функция ДокументПробит(ДокументСсылка) Экспорт
    Возврат ДокументСсылка.ЧекПробит;
КонецФункции

&НаСервере
Процедура УстановитьДокументПробитИНомерЧекаККМ(ДокументСсылка, НомерЧекаККМ) Экспорт
    ДО = ДокументСсылка.ПолучитьОбъект();
    ДО.ЧекПробит = истина;
    ДО.НомерЧекаККМ = НомерЧекаККМ;
    ДО.Записать(РежимЗаписиДокумента.Запись);
КонецПроцедуры

&НаСервере
Процедура УдалитьКонтрольПробития(ТекущийПользователь) Экспорт
    
    УстановитьПривилегированныйРежим(Истина); //Чтобы не контролировались права на регистр контроля чеков
    
    МЗ = РегистрыСведений.КонтрольПробитияЧека.СоздатьМенеджерЗаписи();
    МЗ.Пользователь = ТекущийПользователь;
    МЗ.Прочитать();
    Если МЗ.Выбран() Тогда
        МЗ.Удалить();
    КонецЕсли;

КонецПроцедуры



Статью на хабр с разносом индустрии ККМ сделаю на днях.

(106) костыли

нет чтобы ФП добавить в чек, пришлось огород городить и регистр контроля пробития :)

(108) тогда это было бы чужое решение, и тут уже статью не написать

(108) фп насколько уникальный?

(109) Статья не совсем о методе решения проблемы, скорее о ее наличии. А решений проблемы я и не встречал особо.

(107) ваще шедевр!

Если
        ЗначениеЗаполнено(СтруктураКонтроля.Документ) И  //Если есть сохраненная информация по прошлому чеку

        СтруктураКонтроля.Значение <> Неопределено  И//Для чека заполнено значение предыдущего номера чека

        Значение > СтруктураКонтроля.Значение И//Номер чека стал больше, чем был (на случай перехода через смену)

        НЕ ЛогикаСервер.ДокументПробит(СтруктураКонтроля.Документ)
        Тогда
            //Указываем что документ пробит и ставим ему номер чека

            ЛогикаСервер.УстановитьДокументПробитИНомерЧекаККМ(СтруктураКонтроля.Документ, Значение);
            ВызватьИсключение "Попытка пробить уже удаленный документ: " + ДокументСсылка;
     КонецЕсли;


а почему попытка пробить уже удаленный документ?

(112) ггг. описка. поправлю, спасибо. "уже пробитый", off course

(110) достаточно уникальный

вот товарищ гугол

"Что такое фискальный признак?

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

(114) ну в пределах смены, в принципе, да, но хз. В типовой, где используется ФП, конечно, я бы использовал ФП, но в нетленке зачем городить.

Все хочу узнать, как эта проблема решается в Магазьке. Сталкивался ли Тиутиу (или как там его) с такой проблемой.

(113) вообще ФР умеет и нефискальные документы печатать - ну там рекламу и прочую фигню. твой шедевр это учитывает?

//Номер чека стал больше, чем был (на случай перехода через смену)

(116) я об этом писал выше в (106), цитирую себя:
"Номер там получается не только чека, но и любого нефискального документа, но там в принципе, ничего и не печатается, кроме чеков.
Поэтому пока оставлю так, по уму надо переделать на номер последнего фискального документа (для универсального случая)."

но в этой нетленке только чеки печатает так что норм

(115)

теперь сможешь ответить на вопрос из (110) >фп насколько уникальный?

ФП (ФПД) — фискальный признак документа (чека). Это не номер, а уникальный идентификатор, который формируется фискальным накопителем (ФН) с помощью шифровального ключа при расчете с покупателем и передается ОФД. Представляет собой последовательность из 10 цифр и генерируется для контроля подлинности фискальных данных.

ФПД создается на основе порядкового номера фискального документа (ФД) и сведений, введенных при регистрации кассового аппарата:

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

(117) > Поэтому пока оставлю так, по уму надо переделать

это не про тебя :) где ум и где ты

(119) тут не написано "не номер, а уникальный идентификатор", но смущает, что всего 10 десятичных цифр, в отличии от GUID, видимо, уникальность не совсем уникальная.

(120) В рамках данной задачи и бюджета решение норм.

(121) это типа "хэша" для защиты от подделки инфы. в рамках твоей задачи для защиты от повторного пробития чека более чем достаточно уникальный (как и GUID, которого нет и в результате костылестроение)

(122) GUID я предлагаю применять не после пробития чека, а до его пробития, надеюсь, разница зачем, понятна?

(123) а что не применяешь GUID? накостылил в итоге - и так сойдёт!

надеюсь понятно, что правильно использовать ФП из ФР и хранить в 1С в реквизите чека, т.к. ФП может на "вырост" пригодиться для заполнения тегов по развратам и чекам коррекции

ну и в качестве ГУЯ более чем подходит для контроля "уникальности" в пределах открытой кассовой смены и защиты от дурачков на кассе

(124) >ФП (ФПД) — фискальный признак документа (чека). Это не номер, а уникальный идентификатор, который формируется фискальным накопителем (ФН) с помощью шифровального ключа

по сути гуй, но обрезанный :)

до 10 цифр

(124) Я предлагаю использовать ГУИД по другой схеме. Атолл ее не поддерживает, алло.

Еще раз - я предлагаю передавать ГУИД чека в параметрах чека. Тогда дважды его пробить не получится однозначно.

Теперь понятно, почему 1С-ников на хабре подвергают остракизму.

(127) куда передавать? в ФР? ему то зачем? он сам гуиды генерит - ФПД (фискальный признак документа) :) ешь что дают

Весь мир в ожидании прорыва индустрии ) Что будет через 20 лет никто вообще не знает)
У Атола кстати можно запросить информацию по номеру чека. В 1С вычислить ожидаемый номер чека и запросит по нему информацию
Удивительно правда, что миллионы касс работают и не знают о нашей вселенской проблеме. И даже не знают что такое ГУИД.
А есть еще и другие программы, кроме 1С, есть и на 1С 7.7, есть и автономные кассы, которые ничего не слышали про ГУИД

А чем автору поможет ФПД? Послали чек на пробитие, он пробился, а ответ не пришел. И опять та же самая шняга, можем повторно пробить ) Или я уже потерял нить рассуждений ?

(131) да, потерял. начни с (84) и далее по тексту

(129) на 129 вопросе нкоторые до сих пор еще не поняли, что передавать GUID будет 1С в ФР для защиты от дублирования. Если ФР уже пробивал в этой смене (а лучше на этой неделе) такой GUID, он ругнется и не даст пробить.
Тут есть единственный недостаток, если забудут пробить этот чек, он так и останется не пробитым, может даже в отложенных лежать.

(133) это влажные мечты.

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

ФР где-то у себя должен хранить гуиды и искать у себя в фискальном накопителе гуиды? так чтоли?

:)

(134) это к законодателям нужно, чтобы они в законе поправили эту дичь с гуями и тогда все производители ФН и ФР возьмут под козырёк и отрасль вздохнет спокойно

(133) >Тут есть единственный недостаток, если забудут пробить этот чек, он так и останется не пробитым, может даже в отложенных лежать

в отложенных в 1С чтоли?

ФР вроде бы не умеет откладывать у себя :)

(134) а в чем проблема в течении смены хранить гуй?

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

Пролистал с (84). Привязка к последнему пробитому чеку не снимает всех проблем, например при одной кассе на несколько компов. Правда 1С усиленно сопротивляется такому режиму работы. А с маркировкой там вообще все еще сложнее. Поэтому, на мой взгляд, промышленное решение здесь вряд ли возможно.
(138)Фискальный регистратор вообще никак не обязан знать, что такое 1с ) А ты хочешь ФР заставить проверять статус документа 1С )

(138) гуиды и статусы чеков в 1с у тебя уже есть.

Зачем ФРу гуид отправлять? Что ФР с ним делать будет, хранить его где? В фискальном накопителе?

А "гуид" фискального документа есть. Это ФПД и ФР при пробитии его возвращает. И есть способы запросить ФПД у последнего пробитого и даже по номеру чека/смены из фискальной памяти

(139) у него уже все сделано в самописьной нетленке у клеента

Ждём теперь разгромную статью. Г1С обещал

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

(139) (140) промышленное решение - это в случае не завершенности транзакции проверять ее состояние. Но это для программистов с прямыми руками, а не для фирмы 1С.

(143) гуид зачем отправлять в принтер чеков? Ты не ответил

(142) думаю с выходом статьи она не повысится

(144) еще раз - чтобы ФР ответил, что такой GUID уже пробит и не дал задублировать чек.

(145) отнюдь. Моя недавняя статья про учет доходов фрилансера очень даже повысила карму с -9 до -5.

(146) чтобы ФР ответил, он должен уметь это делать. Нужно начать с (135). Атол докрутит, если его свыше обяжут. Пришивкой новой или базу данных к драйверу сбоку прикрутят.... Это детали

А пока ты с таким же успехом можешь спросить у офисного МФУ. Вряд-ли факс или принтер ответит. ФР такой же по сути принтер, только с функций передачи фискальных данных в налоговую

(147) это потому что она никому не нужной оказалась. Четыре комментария, из них два твои ответы.

(100) ХЗ что там Атол не докрутил, но на запрос статуса чека я получаю даже JSON фискального документа со всеми признаками ФН, ФД и ФП
    ЗапросHTTP=Новый HTTPЗапрос("/possystem/v4/"+СокрЛП(Идентификаторы.ГруппаККМ.ИмяГруппы)+"/report/"+Идентификаторы.ИдентификаторАтол+"?token="+Токен.token);

(148) это показатель кризиса IT, когда в эксплуатацию запускают системы, не обеспечивающие целостность транзакции.
(149) Мы говорили о карме, карму она мне подняла.
(150) Чек не всегда сразу может уйти в ОФД, особенно если сбоит интернет, садись, два.

(151)Система, в которой которой есть элемент в рулоном ленты в принципе не может на 100% обеспечит целостность транзакции, либо цена вопроса будет очень высока.
Кто будет платить за это. За малозначительную проблему. Чеки из 1С бьют уже несколько десятилетий и никто особенно не страдает
Представляю себе кассу, получает запрос от 1С, сама отправляет обратно подтверждение и только потом вылазит бумажный чек. Или еще смешнее, чек сначала вылазит,
но если 1С не получила подтверждение, то чек уничтожается специальным роботом и сторнируется в ФН. Тут уж у кого какая фантазия
Было правильно сказано, что ККТ это принтер с ФН. Это цена вопроса учета оборота наличных денег и эквайринга. Задача решается. Есть малозначительные издержки.
Решения, спасающего отрасль никто не услышал. Хотя и не фанат ни 1С, ни Атолла. И в жизни есть не только 1С и Атол, хотя это и самая большая часть отрасли

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

Решение есть, перекури тему. вкратце - перед обращением к фискальному принтеру сначала проверить есть ли незавершенные транзакции и проверить их статус.

(151) Двоечник как раз ты, что мешает запрос при определённых вариантах ответа повторить. Так-то я количество чеков на десятки и сотни тысяч в сутки меряю.

(153)Мы видимо про разные транзакции говорим. Если Вы печатаете чек с помощью драйвера в обычном режиме (не WEB), то Вы и не пробьете новый чек, если не пробит предыдущий. Новый чек просто не откроется, пока предыдущий не закрыт. И про какие незавершенные транзакции спрашивать кассу? Можете спрашивать, можете не спрашивать, что изменится?

(153)Сформулируйте четко, кто,  что и как мог бы доделать, чтобы было идеально, чтобы устранить кризис в отрасли А так обсуждаем абстракцию

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

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

(157) и в чем же на ваш взгляд, может быть причина?
(155) перечитайте тему
(158) нетленка, читайте внимательно.

(158) но на типовых у меня такая же ситуация периодически на Рознице встречается - 1-2 случая в месяц на сетих из 3х точек в облаке.

перечитал уже ) кроме GUID послать что то не нашел? Послать - это намерение. а не решение. Опишите полное решение.

(159) я нетленку не видел, в коде скорее всего, может и с сетью проблема если RDP, но больше шансов - криворукий код

(160) ну хз, начиная с УТ 10.4  и по 11.5 ни разу такого не было за более 10 лет

(163) у меня за 6 лет работы с розницей и УТ было несколько раз, что надо было через тест драйвера - "продолжить печать" (когда рулон закончился)

и пару раз через тест драйвера - аннулировать чек (ну т.е. какой-то сбой и чек не закрыт и при попытке печати чека из 1С ашипка ФР).

банально - нет связи с ККМ/ выключить/включить, питание, шнуры проверить - кассиры обычно сами справлялись.

а так, чтобы как у Г1С - "не допустить двойного пробития чека" - не было :) походу нетленка криво написана

(164) и в чем же ее кривизна?

(162) 0 бит. Гипотезы ни о чем.

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

(165) (166) (167) такой ты манипулятор, где твои "из пушки по воробьям", "клиент не потянет бюджет"?

(168) ты о чем?

(169) и затем включить режим тупого, ну какой ты предсказуемый стал

(165) кривизна нетленки в том, что нетленка не контролирует завершение распределенной транзакции.

ну с помощью твоих костылей теперь будет контроль, но это неточно :)

(166) проблема в коде 146%

(166) > Цель: не допустить двойного пробития чека.

лучше напиши, как часто и почему вы чеки по два раза пробиваете. это ли не кривизна нетленки?

(173) В УТ11 вроде можно дубль чека сделать. Видел не так давно такой пример. Там ситуация следующая: пробили чек на основании ПКО, а потом это документ пометили на удаление, создали новый ПКО и пробили еще один чек. В итоге в ОФД ушло 2 чека по одной отгрузке. Других дублей я не припомню)

(172) а как ты это понял? Поплевал на палец и посмотрел, куда дует ветер? ггг
(174) мы про другие дубли

(80) чек не вышел = чек не пробит. В реальность вернись уже.

(80) не знаю какое по ты там юзаешь но с драйвером атола однозначно понятно что там с чеков. 20-30 касс по 3-5 пользователей, в пики все пять отправляют задания на кассу, всё организовано через очереди ни одного косяка за 2 года.

(177) Отлично. А теперь расскажи за счет чего это происходит. Если касса не успевает сообщить 1С, что чек пробит, как это лечится. Поставь точку останова и прерви сам. Расскажи, как 1С это пролечит. Внемлю.

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

(178) "Если касса не успевает сообщить 1С, что чек пробит, как это лечится. Поставь точку останова и прерви сам" - я так понимаю, что в этом случае чек пробьется в кассе и уйдет в ОФД, а в 1с не будет строчки в регистре фискальных операций (в крайнем случае). Вы хотите узнать, как эту строчку программно добавить, чтобы решить вопрос?

(180) > Если касса не успевает сообщить 1С, что чек пробит, как это лечится. Поставь точку останова и прерви сам

зачем такие сложности - точка останова/прерви сам. достаточно в момент пробития сервер 1С или где у вас база крутится - вырубить питание с кнопки

(180)других проблеи автор не озвучил. Ведь чеки все - вот они, или вылез или нет Ну вылез после замены  ленты, надо проставить в 1 номер пробитого чека. Как проставить - зависит от конфигурации

(182) чеки вообще могут не вылезать из ФР (если тырнет-магаз или ж0ская экономия термобумаги)

я уже у Г1С (173) спрашивал про его грусть пичаль и страдания - как часто его и клеента беспокоят дубли чеков и почему так часто. он не ответил :) 1С г.вно, нетленка теперь лучше, т.к. обеспечивает с помощью костылей "контроль целостности распределенной транзакции"

(183) контролируется "завершение распределенной транзакции" *

(182) кассир сам в состоянии себя и кассу проверить с помощью х-отчетов из ФР и эквайринга и по отчету 1С.  и уже принять осмысленное решение - ибашить дубль чека или нет. если не в состоянии  принять такое решение - попросить помощь более разумного существа

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


чтобы ФР часто не успевал сообщать 1С, что чек пробился... что-то не так в консерватории, кривизна нетленки однозначно :)

(185)так я то разве спорю )