А чебы такого, сделать плохого? (шутка), а реально, чего не хватает? : Маркировка

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

А данные то ты откуда берешь? Из своей базы, или все-таки в ЧЗ запрашиваешь текущий статус марки?

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

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

Олег, я конечно понимаю, что скуль сервер - это правильно. Но, в моих мелких магазинчиках это "из пушки по воробьям"...
Отсюда вопрос - допустим, 2-3 кассы. По каждой продажи. Информация о проданных марках есть, я могу ее собирать в 1С в одну кучу, после закрытия смены. Ну, или даже, по какому-то таймеру из оперсводки в процессе, еще при открытой смене.
А можно-ли, как-то обратно на каждую из этих 2-3 касс, запихивать всю информацию о проданных, из БД 1С, по всем 2-3 кассам, на каждую из них?
Что-бы при варианте 2 - "по текущей банке", в банке была информация о продаже марок со всех касс?

Запрашивать в ЧЗ для меня не вариант, ибо:
1. долго
2. зависит от наличия интернет

Проданные марки храню в УС, в отдельных внешних файлах ДБФ (на каждую товарную группу - отдельный файл, т.к. смешивать молочку, сигареты, воду и т.д. - слишком раздует один файл).
Обращение к этим файлам из 1С - прямыми запросами.
Т.к. молочка имеет сроки годности, то можно предусмотреть периодическую чистку по дате.
Структура каждого ДБФ файла:
- дата списания + Обособка
- тип документа (чек или акт)
- ответ от сервера ИСМ (0, 5, 15)
- КМ
это если кратко...
под свою УС - сам решай, как лучше и удобней

Ну, в этом, ЧЗ дает фору ЕГАИС...
Тут нет транспортного модуля, со своим периодом опроса сервера, запросы идут прямиком на сервер, и отрабатывают мгновенно(по крайней мере, сейчас, когда их не дудосят).

А в остальном, конечно все так...

говоря "долго", я имел ввиду не сравнение с ЕГАИС, а относительное сравнение с запросами непосредственно в БД УС.
если, например, 10 позиций в чеке будут через запрос по АПИ получать статус КМ - секунды, то поиск по базе проданных КМ через прямой запрос к dbf, займёт - десятые/тысячные доли секунды.
Ну и самое главное - при отсутствии или нестабильном интернет - статус КМ получить не получится, а значит и проверка на дубли этим способом (через запрос статуса КМ) - ненадёжная.

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

Я на хостинге у провайдера делаю вместо sql. Кассовая программа просто дергает определенные php файлики с маркой в параметрах, которые пишут/читают в sqlite. Не надо поднимать и поддерживать отдельный sql сервер, чего-то дополнительно настраивать и устанавливать на кассах. На одном хостинге могут крутиться разные магазины. Отрабатывает быстро. Могут, конечно, быть проблемы у хостера, если хостинг недоступен по каким-то причинам, программа просто пропускает марку. Добиться полностью корректной работы проверки марок в принципе технически невозможно, всегда есть вероятность сбоев. Наше дело минимизировать. Органы цепляются, если дублей много, больше определенного процента. Если небольшое количество марок задублировалось, никто на это внимание не обращает.