[ОТВЕТИТЬ]
24.09.2015 18:13
DMaslov
 
Здесь сказали: откат\отмена принятого акта переоценки... супермагом в интерфейсе не предусмотренно (и правильно).

Поясните тупому - почему.

Конфы писал - всегда для любого документа предусмотрена как процедура проводки, так и процедура отмены.

Понятно, что это не техническая проблема, а организационная, но с ней я не сталкивался.
24.09.2015 19:01
Stels
 
А смысл отмены?
Отмена - установка новой/старой/другой цены
А это же делается Созданием нового документа с новой ценой.
Здесь очевиден плюс в том, что видно кто и когда накосячил (если что).
И такая позиция не только в Супермаге

Это моё мнение
25.09.2015 09:07
BotMan
 
Цитата:
Stels Здесь очевиден плюс в том, что видно кто и когда накосячил (если что).
Так в СМ все равно пишется история изменений всех. Я вот тоже выражаю недоумение, почему все доки откатываются назад, даже сличительные и компенсационные, а АП нет.

Неудобно.
25.09.2015 09:27
AndreyZh
 
Цитата:
Stels А смысл отмены?
Например исправление случайной ошибки - примерно ошибаются в одном из 50 актов.

Цитата:
Stels Отмена - установка новой/старой/другой цены. А это же делается Созданием нового документа с новой ценой. Здесь очевиден плюс в том, что видно кто и когда накосячил (если что).
Как вариант, когда нет других средств вполне подойдет, но это ИМХО оправдание недоработки.

Цитата:
Stels И такая позиция не только в Супермаге
В УС Лэнд нет отката "акта переоценки", но можно удалить три порождаемых операцией документа => откатить акт.

Все "косяки" всё равно запишутся в логи действий пользователя, но зачем плодить случайно созданный "мусор"?
25.09.2015 09:41
DMaslov
 
Цитата:
Stels А смысл отмены?
Отмена - установка новой/старой/другой цены
А это же делается Созданием нового документа с новой ценой.
Телодвижений при изъятии, исправлении и проведении заново меньше, чем при создании нового.
25.09.2015 09:42
DMaslov
 
Цитата:
Stels Здесь очевиден плюс в том, что видно кто и когда накосячил (если что).
Ясно, у них же журналирования построчного не делается.
А я обычно делаю.
25.09.2015 09:43
Mtirt
 
Есть понятие "исторический след". Т.е. установка цены фиксируется в истории.
Навсегда.
А Акт ты можешь просто удалить, если на нервы действует. Только цена на товар не поменяется, и запись в истории останется.
29.09.2015 00:33
baggio
 
а моно еще раз ...
1. Если вы живете в России матушке то.... это хоть и большой кусок суши но далеко не весь... есть например Белоруссия...
2. Есть очень много странных людей... со своим видением проблем и пониманием учета...
3. История розничных цен велась не всегда... (насколько мне помнится в версии 21 и также 23 её не было...) если память не изменяет добавили в 1.24.6 или что-то около того... хотя по третьему пункту могу ошибаться...
4. Сама по себе история... не документ... очень многие хотят печать и подпись... а хвост и усы им не нравятся...

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

рассмотрим ситуацию:
1. пришел товар с артикулом 001 кол-во 10 по цене 10руб
2. создали акт переоценки. в нем поставили цену 15руб.
3. Акт запустил механизм выгрузки на кассы и через 5 мнут на всех кассах товар с артикулом 001 стоит 15руб
4. продается 5шт товара 001 по цене 15 руб
5. оператор через 15 минут замечает что она поставила кофе на накладную и понимает что ошиблась с приходной ценой
6. исправляет накладную и ставит цену 15руб приход...
7. *** по вашей логике заходит в акт переоценки и правит руками цену? ставит там 20 руб...
8. все дружно выгружается в кассу снова... и остаток 5шт продается по 20руб....

Возникает резонный вопрос:
Где найти документ основание на цену в 15 руб?
лично моё мнение - это одно из самых охренительных фишек см... нефиг править акты...
29.09.2015 11:13
akonev
 
присоединюсь. это не баг, это фича.

в штатном режиме переоценка не должна откатываться, потому что у цены есть дорога в один конец: на торговое оборудование.

за много лет работы с супермагом, попалось всего два случая, когда акт действительно пришлось откатить.
это были ошибки в массовых переоценках на многие тысячи позиций.
29.09.2015 11:41
FinSoft
 
Вставлю небольшое замечание.
Есть такое правило, программа должна иметь единообразие в подходах. Если имеется запрет или разрешение на изменения документов задним числом, то они должны распространяться на все документы. То есть если разрешено править приходную накладную, то должно быть разрешено править и акт на переоценку. Просто надо ввести ограничение на уровне прав пользователей, проверку статусов и т.п.
29.09.2015 15:20
akonev
 
Единообразие подходов - замечательная штука при единообразии процессов.

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

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

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

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

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

Не утверждаю, что запрет смены статуса актов переоценки - единственно правильный подход.
И всё же считаю его совершенно обоснованным.
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 бит и всякую такую...
всё можно сломать... было бы желание и финансирование...
и в вашей базе ТОЖЕ можно менять инфу напрямую... теоретически а возможно и практически...
в СМ при не знании пароля основного пользователя.. тоже вы ничего не сделаете...
так что тут паритет... пусть и не полный за счет менее распространенной БД...
30.09.2015 08:52
FinSoft
 
Подобие паритета будет, если скажете, что без знания пароля суперпользователя оракловскую базу смогу юзать без ограничения...

OlegON:
По расшифровке БД предлагаю продолжить тут: Расшифровка данных базы , совсем ушли от темы
30.09.2015 18:47
DMaslov
 
Цитата:
baggio нефиг править акты...
А также приходные, инвентаризации, и ваще.
30.09.2015 19:39
OlegON
 
Как я понимаю, разница в принятии или непринятии факта, что получение накладной от поставщика - вещь договорная, а уход покупателя с покупкой за определенную сумму денег - вещь необратимая. На мой взгляд, откат актов, реализация этой процедуры и всех ее нюансов в многопользовательской и (!) сетевой структуре, породит больше проблем, чем даст возможностей. Помимо того, что непоследовательный откат актов вызовет проблемы, так еще и перепосылка многократно измененного акта вывихнет мозг любому, кто попытается изменить историю изменения цен. Да, аудит можно настроить любой, но при этом затраты на хранение и обработку этого аудита (придется хранить все строки спецификаций, в т.ч. удаленных документов)... Смысл пока вижу только в том, "чтобы был", но это достаточно слабая мотивация для разработчика в данном случае. Это мое личное мнение, не выдаваемое за жизненную истину.
01.10.2015 18:24
DMaslov
 
Цитата:
OlegON На мой взгляд, откат актов, реализация этой процедуры и всех ее нюансов в многопользовательской и (!) сетевой структуре, породит больше проблем, чем даст возможностей.
Наверное, соглашусь.

Есть у кого опыт ручной правки акта переоценки?

Например, такая ситуация:

Меняли цену с 105 до 110, и проглядели, что получилось 105110. Получилась огромная сумма дооценки. Затем в следующем акте мы эту ошибку исправляем, и получается большая сумма уценки.

Если я просто поменяю SMSPEC - это ведь не сработает?
01.10.2015 18:33
OlegON
 
не сработает, конечно, в спеке - цена документа, а сами цены по видам - в SMPRICES
01.10.2015 18:34
OlegON
 
А зачем все эти танцы? Что с этими суммами и кто делает?
01.10.2015 23:39
baggio
 
да что они делают... ежику понятно...
ведут учет в розничных ценах...
только стесняются об этом сказать почемуто...
02.10.2015 09:06
akonev
 
Цитата:
DMaslov Наверное, соглашусь.

Есть у кого опыт ручной правки акта переоценки?

Если я просто поменяю SMSPEC - это ведь не сработает?
Смотря чего добиваешься.
Обычно надо еще и заголовок править.

Чтобы было меньше шансов накосячить, бывает проще отключить триггер и в smdocuments передернуть статус в единицу. Сразу обратно включить триггер.

После этого можно уже в интерфейсе супермага править акт и снова проводить.

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


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

 

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