Коллеги, приветствую.

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

И вот я озадачился вопросом: есть ли относительно стандартный инструмент проверки вводимого в кассе документа до его сохранения и получения стандартного номера кассового документа?

В настройках кассовой книги есть галка, которая активирует замещения.
Это жирно намекает, что проводка по кассе 100% интегрируется в общую архитектуру.
Сами попроверяйте, разве не интересно? Проверить можно стандартные проверки, open fi и пр.
Отладить это вряд ли выйдет, там фоновый запуск, как у F110. Но видно же сразу будет.

Если ничего не сработает, то я не случайно написал про замещения. Да, в нормальном человеческом виде замещения замещают, а не проверяют.
Но при использовании пользовательской подпрограммы выкинуть сообщение можно. Весь вопрос в том, насколько выброс сообщения органично вольется в логику экранов в кассе. Есть программы, где выбрасывание сообщения через message реально нарушают структуру процесса и ломают экранную логику (например, вывод сообщения с типом E в 940 событии в open fi).

Но в данном конкретном случае я уверен, что сообщение не сломает кассу даже из замещений.

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

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

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

Аргументация понятна, соглашаюсь.
Но это просто будет противоречить задаче автора из топика, потому что он как раз и хочет запретить проводки задним числом.
Что касается программы по изменению нумерации, то это вроде бы технически не трудно, но как это будет соотноситься с ордерами, выданными на руки клиентам/сотрудникам и пр.?
У него на руках документ о выдаче/приеме средств под номером 71, а завтра он из-за пропущенной операции в нашей системе становится уже 72?
Хотя я вот задумался, квиточки на руки по-прежнему из кассы выдаются или там только чек. Просто и мой текущий заказчик тоже перебивает номера постоянно.. Похоже, это все же возможно.

Делал когда то эту фигню. Получился кадавр, но работал как часы.

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

Все это на самом деле блажь. Лучше объяснить что не нужно этого.

Это не решает проблемы нумерации при сторно документа, проведенного несколько дней назад.
Даже если предположить, что на документ сторно будет выделен свой номер, который позднее будет успешно проигнорирован и тот же номер получит нормальный ордер, в нумерации старых ордеров образуется дырка. Нельзя подшить в книгу ордера с дыркой, потому что после 72 должен идти 73, а 73 сторнирован.
Присвоить 73 номер более позднему ордеру также нельзя, потому что тогда нарушена будет хронология.

Внутри замещения сообщения поднимать запрещено. Это как раз связано с моментом работы и тем что можно сломать стандартные LUW процессы. Так что такую практику лучше не применять.

Все это можно покрыть в алгоритме, но нагружающем ресурсы. С выборкой из табл по всем документам с определением сторно по данному дню и т.д. Операции должны сходится в пределах дня. Я это решал проверкой на нумерацию в течении дня, если было сторно в тот день, взять тот номер. Так закроется дырка. Хронология соблюдается, а если нет, то кассир сам виноват и будет сторнировать весь день до конца чтобы сделать один номер. Но в итоге картинка цельная.

Все это можно разрулить АБАПом, но не нужно. Это должно решаться организационно, процессом.