Статусы документов и аудит спецификаций в Супермаге : Супермаг Плюс (Супермаг 2000)

Спрошу ради любопытства.

Обратил внимание на термин "откатить" для акта переоценки. Я правильно понял, что в см проведенный/утвержденный документ нельзя править, не отменив проведение всего документа?

Вроде писали, что в см не ведется аудит строчных частей документов. Это на самом деле так?

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

Да, в СМ существует несколько статусов у большинства объектов. В окончательно принятом документе, например, правки недопустимы.

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

Аудит в Oracle - отдельная тема. Как настроишь, так и поедешь (можно почитать про такую прелесть, как FGA, например). Однако, штатный журнал подключений в несколько десятков Гб - обыденность. Нельзя забывать, что в Супермаге есть всякие сервисы, вроде почтового, которые генерируют большой объем информации... При сотне пользователей в центральном офисе сети магазинов с работающим почтовиком админ достаточно быстро разорит контору на ленту для бекапов журналов. Да, конечно, документ будет не целиком клонироваться в историю, но будет написано время, с какого хоста, что правил и т.п. Т.е. дело не в том, что это сделать нельзя... И есть отдельный аудит по объектам системы в самом Супермаге, т.е. можно посмотреть, что почтовик, например, прислал приходную накладную или на карточке выпилили штрихкод и поменяли цену или остатки. Большинству этого достаточно, часть других не готова платить за ресурсы, которые на аудит потребуются.

Интересно, почему? Я предполагаю, это связано с тем, что происходит именно "проведение" документа, то есть при установке какого-либо статуса в другие таблицы базы сохраняется какая-то служебная информация. А изменения задним числом могут привести к некорректным ситуациям. Когда проектировался КупецЪ, по этой причине и была принята концепция отказа от проведения документа в пользу расчетов на лету. Если надо что-то поменять в старом документе, то просто открываем и меняем. Ничего не откатывая и не пересчитывая. Запрет на изменения выставляется по мере закрытия периодов. И правами доступа, конечно. Например, пользователям можно разрешить изменять только свои документы, или разрешить изменять документы в течении какого-то периода времени, запретить утверждать документы (утверждение - это некое подобие проведения, но без записи информации в служебные таблицы) и т.п.
Как мне видится, жесткий запрет изменений документов задним числом будет сильно ограничивать область применения программы. В оптовой торговле такое в наших условиях точно не взлетит. Финансовый учет тоже вряд-ли впишется, бухи вой поднимут и придется вести его в другом софте.

При принятой идеологии, наверно так и есть. В Купце аналогично можно делать через установку статусов или заполнения каких-либо реквизитов документа.
Я думаю, что логировать записи базы данных, которые не могут изменяться пользователями, смысла нет. В Купце есть журнал полученных электронных заказов, журнал обмена сообщениями с покупателями (запросы на подключение к системе электронных заказов с сайта, к примеру). Такое нет смысла накрывать аудитом.
Журналы лога растут быстро, быстрее основной базы. Поэтому при создании резервной копии базы данных у нас из оперативного журнала лога вся информация переливается в архивный журнал. А файл архивного журнала просто периодически переименовывается определенным способом, когда станет большим (в районе 1.5 ГБ). Программа же может делать сквозной поиск по всем частям журнала лога. То есть архивировать чрезмерный объем информации не требуется, старые части достаточно архивировать 1 раз. Ну и сам журнал лога построен на топспидовских таблицах, которые автоматически упаковываются (степень сжатия их архиваторами обычно в пределах 10%).

Да, в принципе, логично же. Если согласовали бумажный документ у завсклада и директора, то при его правке придется согласовать опять, у завсклада и директора. Подразумевается, что правки недопустимы не в принципе, а именно в этом статусе. Т.е. документ надо будет вернуть обратно в статус, позволяющий редактирование, поправить и провести вверх, причем, на каждом этапе будет производиться соотвествующая проверка документа на корректность, отправка в другие подразделения и т.п.

Про "открываем и меняем без пересчета" немного не понял. Приняли 10 валенок, на остатках их 10, открыли и поставили в приход 15, на остатках 10 будет?! Практика показывает, что "вой" против структурированного и последовательного подхода удовлетворять нельзя. Проблема либо в инертности сотрудников, либо в малом понимании происходящего и нежелании избавляться от хаоса, в котором тонет либо их лень, либо какие-то махинации.

Логгируются, конечно, не все записи базы данных, а только те, которые изменяются. Можно и не только измененных, но и просматриваемых, в т.ч. каких-то определенных. Я не зря упоминал FGA, предлагаю почитать по нему материалы, могут возникнуть интересные идеи.

Что касается архиваций и прочего секционирования, то трудно найти что-то из фич (из нужного), что так или иначе не реализовано в Oracle. Там и компрессия и секции тоже есть.

А что происходит с остатками товаров в СМ при таком понижении статуса приходной накладной, к примеру? Я в разных программах с подобной логикой работы видел, что они откатываются (уменьшаются). Это приводит к возникновению некорректных остатков, маржи и т.п. на время внесения изменений. Если же понижение статуса не приводит к изменению остатков товаров (взаиморасчетов, распределению по партиям и т.п.), то вполне разумно.
Нет, на остатках станет 15. Просто логика получения остатка другая. Он не хранится, а считается динамически, в процессе формирования отчета или запроса из экранной формы. Хотя я по поводу остатка товара выразился несколько академично. Именно по товарам в Купце есть оперативные остатки, которые используются для ускорения отображения при выписке документов. Оперативный остаток по товару/складу пересчитывается после правки строки накладной. В отчетах остатки (и все остальное) всегда считаются на лету.

В СМ остатки хранятся в SMGOODS. Т.е. смена статуса меняет и остатки, мне кажется это логичным и более понятным для применения.

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

Еще вопрос. В системе аудита СМ анализируются его собственные логи или оракловские? Собственные логи регистрируют изменение информации в базе данных или только события?
В Купце есть два лога. Тот, о котором я писал ранее - это транзакционный. В нем регистрируются именно изменения в базе данных. Он используется системой аудита, а также может использоваться для восстановления информации. А есть еще событийный лог. В него пишется различная информация по факту включения в настройке. То есть пишется не всегда, а если нужно за чем-то последить. Например, может писаться, с какими параметрами пользователь запускал отчет и сколько времени он формировался, когда пользователь вошел в программу и когда вышел, когда открыл и закрыл какое-нибудь диалоговое окно и т.п. По событийному логу есть пара отчетов, позволяющих мониторить события. Это тоже часть системы аудита, но востребованность невелика, поэтому я ее редко упоминаю, понимая под аудитом именно работу с транзакционным логом.
По поводу оракловских логов я читал, что их не так просто анализировать из прикладной системы. По этой причине многие делают параллельно свои в целях аудита, а логи субд оставляют для целей восстановления система на случай мажоров.

В Купце в топе работают всего около 30 пользователей с одной базой. Но там и сервер сервером можно назвать условно. Обсчет на лету идет от границы ближайшего закрытого периода, не по всей базе. Плюс немало всяких хитростей. Я вроде размещал здесь небольшую статью на эту тему. Например, если кто-то захочет посмотреть отчет, аналогичный недавно сформированному другим пользователем и его устроит актуальность, то будет дан готовый результат. В закрытых периодах самые нагруженные итоги могут храниться в готовом виде и использоваться программой по мере обнаружения (то есть их наличие не обязательно) и т.п.
По количеству пользователей сложно судить о нагруженности системы. Кто-то может сформировать отчет и целый день смотреть на него, кто-то интенсивно вколачивать накладные. В Купце есть возможность генерации тестовой базы с заданными параметрами и затем нагрузочного тестирования. При нагрузочном тестировании авто-пользователи (их можно сделать сколько угодно) в цикле гоняют ресурсоемкие отчеты, а обычные человеки могут поработать на этом фоне и оценить уровень комфортности.
Но в целом КупецЪ позиционируется на системы до 50 конкурентных пользователей в одной базе. В этих пределах гарантировано будет все быстро и стабильно. Скорее всего, можно успешно пройти и более высокую нагрузку, на крайний случай в резерве есть первасив. Только такие предприятия - это другая ниша.

Еще бы отметил, что обычно вся база Купца (кроме лога) кэшируется в оперативной памяти, чему способствует авто-компрессия данных. Нагрузка на дисковую систему минимизируется. Блокировки при чтении данных отсутствуют в силу архитектуры системы. Код программы нативный бинарный, нет лишних преобразований и вычислений. То есть все довольно шустро работает.

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

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

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

У этой системы статусов есть свои плюшки:

Система разграничения прав доступа получается более гибкой - свой набор прав на каждый статус. В том числе на повышение и понижение статуса документа.

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

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

Вы пошли собственным путем и это замечательно, коль скоро он позволяет решать задачи пользователей.
Это вовсе не значит, что другие пути хуже ;)