Почему нельзя отменить акт переоценки : Супермаг Плюс (Супермаг 2000)

Единообразие подходов - замечательная штука при единообразии процессов.

С движением товара всё понятно: провели накладную = прибавили товар на остатки.
Откатили накладную = вычли товар.

С ценами интереснее.
Даже если опустить из внимания механизм маркетинговых акций, который затейливо меняет порядок назначения цены...
Если принят акт 1, потом акт 2, то какая цена должна встать на кассы при откате акта 1 ???

Ещё важный аспект:

Цена прихода может быть изменена.
Путем замены приходной накладной на такую же с другими ценами.

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

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

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

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

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

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

Я не могу в СМ скриптом при наличии прав доступа изменить цифры в пробитом чеке? У нас архитектура системы несколько иная, в обход программы в базу не влезешь. Поэтому несколько разный угол зрения.

в см - нет...
в БД... можно...

Если у вас закрытая БД... то вам только кажется что в базу нельзя записать
напрямую..

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

я вас умоляю... при наличии желания и знаний...

Не вижу смысла убеждать...

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

аналогично ...
не вижу смысла спорить...
просто не ведитесь на 256 бит и всякую такую...
всё можно сломать... было бы желание и финансирование...
и в вашей базе ТОЖЕ можно менять инфу напрямую... теоретически а возможно и практически...
в СМ при не знании пароля основного пользователя.. тоже вы ничего не сделаете...
так что тут паритет... пусть и не полный за счет менее распространенной БД...