[ОТВЕТИТЬ]
Опции темы
29.09.2015 15:20  
akonev
Единообразие подходов - замечательная штука при единообразии процессов.

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

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

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

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

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

Не утверждаю, что запрет смены статуса актов переоценки - единственно правильный подход.
И всё же считаю его совершенно обоснованным.
 
"Спасибо" akonev от:
29.09.2015 17:51  
FinSoft
Ну, я имел ввиду общий принцип, а не частный случай. То, что акт на переоценку связан с выгрузкой цен на кассы - это частный случай и это разные бизнес-функции. Если мы ограничиваем возможность корректировки акта переоценки задним числом правами доступа, то получаем идентичный функционал.
Хотя все это достаточно условно, ведь, как я понимаю, в СМ можно вносить изменения в базу данных и в обход программы.
Запрет изменения акта на переоценку, видимо, фича, связанная со специализацией системы. Другого никто не спрашивал и не оплачивал, поэтому сделали так, как показалось проще и надежнее.
 
29.09.2015 17:53  
baggio
да да.. единообразие вообще весчь хорошая...
давайте еще разрешим править кассовые документы...
да и что там...
давайте и чеки давать править... а то вдруг пользователю захочется...
и вообще нужно сделать специальный раздел с функциями... чтоб можно было править функции оракловые прям из интерфейса см... а что... а вдруг надо...
а права разграничить по пользователям...

З,Ы, еще раз... молитесь что в программе этого сделать нельзя...
вы себе даже не представляете какое количество геморроя вы бы имели... было бы это возможно...
 
29.09.2015 18:08  
FinSoft
Я бы еще предложил четко позиционировать, про какую часть системы идет речь - про бэк или фронт.
В случае с фронтом оптимально использовать схему с полным запретом изменений всех документов задним числом. По моему опыту, в этом случае
обеспечивается наименьший геморрой с поддержкой.
В случае с бэком такой подход проблематичен, так как там более сложные процессы, заморочки с соответствием законодательству и т.п. Если бэк полноценный, конечно.
Если же фронт и бэк совмещены в одной базе, то я не вижу криминала в возможности править пробитые чеки. У нас так люди работают без проблем. Конечно, продавцы ничего править не могут, а все правки легко отслеживаются в блоке аудита.
 
29.09.2015 18:14  
FinSoft
Цитата:
Сообщение от baggio
да да.. единообразие вообще весчь хорошая...
давайте еще разрешим править кассовые документы...
да и что там...
давайте и чеки давать править... а то вдруг пользователю захочется...
и вообще нужно сделать специальный раздел с функциями... чтоб можно было править функции оракловые прям из интерфейса см... а что... а вдруг надо...
а права разграничить по пользователям...

З,Ы, еще раз... молитесь что в программе этого сделать нельзя...
вы себе даже не представляете какое количество геморроя вы бы имели... было бы это возможно...
Я не могу в СМ скриптом при наличии прав доступа изменить цифры в пробитом чеке? У нас архитектура системы несколько иная, в обход программы в базу не влезешь. Поэтому несколько разный угол зрения.
 
29.09.2015 19:32  
baggio
Цитата:
Сообщение от FinSoft
Я не могу в СМ скриптом при наличии прав доступа изменить цифры в пробитом чеке?
в см - нет...
в БД... можно...

Цитата:
Сообщение от FinSoft
У нас архитектура системы несколько иная, в обход программы в базу не влезешь. Поэтому несколько разный угол зрения.
Если у вас закрытая БД... то вам только кажется что в базу нельзя записать
напрямую..
 
29.09.2015 20:28  
FinSoft
База упакованная, зашифрованная, запрятанная...
При включенной защите на сервере до физических файлов доберетесь только под админскими правами. Сможете убить или испортить файлы (аналогично, как и файлы оракловской базы).
А чтобы реально что-то изменить в базе в обход программы, нужно иметь еще специальный софт и знать значения ключей шифрации.
 
29.09.2015 20:59  
baggio
Цитата:
Сообщение от FinSoft
База упакованная, зашифрованная, запрятанная...
При включенной защите на сервере до физических файлов доберетесь только под админскими правами. Сможете убить или испортить файлы (аналогично, как и файлы оракловской базы).
А чтобы реально что-то изменить в базе в обход программы, нужно иметь еще специальный софт и знать значения ключей шифрации.
я вас умоляю... при наличии желания и знаний...
 
29.09.2015 22:29  
FinSoft
Не вижу смысла убеждать...

Если оставить в стороне вопросы взлома ntfs, я не слышал, чтобы были прецеденты взлома топспидовских баз с их 256-битными ключами шифрования. У буржуев поднимался вопрос, что в каких-то конторах безопасники требовали использования сертифицированных алгоритмов шифрования. Это было, и деньги под это нашли. Сейчас при необходимости можно использовать алгоритм на выбор. А если есть мания преследования, то у нас базу можно периодически автоматом перешифровывать.
 
30.09.2015 00:04  
baggio
аналогично ...
не вижу смысла спорить...
просто не ведитесь на 256 бит и всякую такую...
всё можно сломать... было бы желание и финансирование...
и в вашей базе ТОЖЕ можно менять инфу напрямую... теоретически а возможно и практически...
в СМ при не знании пароля основного пользователя.. тоже вы ничего не сделаете...
так что тут паритет... пусть и не полный за счет менее распространенной БД...
 
 


Опции темы



Часовой пояс GMT +3, время: 21:27.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.