Что посоветуете СуперМаг+ или Астор? : Системы автоматизации торговли

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

Идею бороться в первопричиной в СуперМаге Плюс - полностью поддерживаю. В итоге на вопросы некоторых клиентов, а как с вот этим борьба идет, бывали недопонимания, а зачем с этим бороться? нет причины, нет следствия.

Только хотел об этом написать, но потом подкорректировал комент, т.к. об этом речь не шла.
Так вот, клиентов, желающих как в буржуйских системах - каждый второй.
СуперМаг Плюс может поддерживать полный запрет на работу задним числом - это всего лишь настраиваемое право, причем по ролям, т.е. у кого то может быть, у кого-то нет. Равно как и можно запретить редактировать действующие документы :)

В итоге ни один, ни один клиент на это не согласился в действительности! Потому что это Россия :))) Если бы наши поставщики были дисциплинированы, равно как и сотрудники, которые день в день принимали бы документы - вопросов бы не было.
Но даже у себя в компании, даже пытаясь хотя бы в электронном виде получать документы как можно быстрее (скан), ерунда выходит. Все ровно только в одном случае, когда мы работаем с компанией в системе электронного документооборота. А в остальных - человеческий фактор, когда иногда ошибку в документах приходится неделями выяснять.

Дебиторка по первичке - это гемморой всех видов бизнеса. Сейчас некоторые покупатели идут другим путем: сначала весь пакет документов, потом только товар и только потом оплата. Хотя и этот путь не избавляет от проблем, т.к. приход товара и первичный документ - не всегда совпадают :))

Есть у нас Navision в Библиоглобусе. Ничего хорошего в российской действительности.

У меня противоположный опыт. У нас такой функционал был с самого начала, разрабатывался еще в 2004 году. Я уже настолько привык, что не понимаю, как может существовать учетная система для бизнеса, в которой все ходы не записаны. Честно, ощущение работы вслепую. Функционал в реальной жизни востребован более чем. У нас продвинутые пользователи пользуются самостоятельно. А уж при разборе полетов вещь незаменимая, позволяющая экономить массу нервных клеток.

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

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

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

Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.

Ну это странный аргумент, у нас каждое изменение строки логируется, в том числе количества и цен (а у многих клиентов количество одновременных пользователей существенно больше 100). Более того пользователь (с правами соответствующими естественно) может включить логирование изменение любого (!), в том числе вычисляемого (!), показателя который он видит, и они этим активно пользуются. И никакой особенной проблемы с местом не замечали. Все равно те же чеки жрут значительно больше места чем вся остальная база (даже с логами). Для этого просто создается tablespace отдельный на hdd и туда скидываются редко используемые данные (логи чеки и т.п.). При этом сейчас даже в любом ноуте больше террабайта hdd диск.

Ничего странного. Давайте от теории ближе к практике, допустим, средняя накладная из 5000 строк, сохранение деталей по каждой строке с накладными, ну, пусть 1Кб, это немного, учитывая накладные расходы, в т.ч. на индексы. Итого, 5Мб на изменение накладной. 100 человек могут выдать до 100 измененных накладных в минуту, т.е. до 500Мб в минуту прироста и записи на диск. А теперь представим, что в ЦО стекаются данные со всех магазинов и кто-то проводит инвентаризацию с простановкой цен... Очень даже круто растет база... А это еще рост и ее бекапа, т.е. диски только подносить надо будет...

Не совсем понял почему лог должен занимать больше самих данных. То есть размер лога = размер данных + размер данных * коэффициент правок (лога). Коэффициент правок хорошо если 10%. Итого размер базы увеличивается в 2.1 раза. При этом если взять чеки которые нет смысла логировать, то даже в системе класса ЕРП все остальные данные с логированием будут все равно в раза 2 меньше размера таблиц чеков. Итого общий размер с логами увеличится процентов на 20. А если учесть что логи и чеки можно положить на hdd то проблема размера логов по-любому надумана.

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