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

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

(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)так я то разве спорю )