Три девятки — это в среднем один отказ на тысячу случаев.

В применении к учету и управлению случаем логично считать электронный документ.

А вот интересно, на сколько бумажных документов и на сколько страниц бухгалтерских книг допускали работники ошибку раньше? Когда считали на счетах и арифмометрах?

Типовая надежность системы, построенной на файл-серверной СУБД — три девятки. Можно добиться большего, стоить это будет — как система более продвинутая. Если денег на таковую не находится, придется довольствоваться тем, что есть. Однако переформулированная в виде «одна ошибка на тысячу документов» первая фраза данного абзаца ввергает любого руководителя в ступор, шок и трепет.

Но так и есть. Я думаю, это сравнимо с ручным способом — и даже лучше его, если грамотно выстроить систему проверок… Перепроверок… А контролирующие органы все равно найдут, за какую циферку штраф попросить.

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

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

А как у вас?

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

Решение проблемы примитивно — вам требуется ролевая модель доступа к функциям и данным. Набрал для учетной записи ролей — и всё. Обычно роль — понятие довольно обобщенное, в разные роли могут входить разные функции системы учета, то есть модель — трехэтажная.

1. Функции (подпрограммы, подсистемы, отчеты)
2. Роли (включают пересекающиеся в общем случае наборы функций)
3. Пользователи (у каждого — свой набор ролей)

Все это не удерживает пользователей (и даже администраторов) от соблазна сказать Васе пароль Коли, и пусть работает под его именем.

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

Корректно же — дать новому пользователю требуемый набор ролей.

Проблема может заключаться в доступе к частям справочников (часть клиентской базы), если ваша система рассчитана на закрепление клиента за конкретным менеджером, например. И вы не решите эту проблему, если не будет реализован доступ через группы пользователей (то бишь через роли). Однако группа не будет получать оплату за продажи ее клиентам (или будет?)

Мы видим потенциально широкое поле вариантов организации доступа к данным и функциям системы. В ваших интересах затуплять эту систему, поелику возможно.

А протоколироваться все должно исходя из того, кто именно зашел в систему.