В практике работы с программами 1С нередко возникают ситуации, когда после технического сбоя (отключения электричества, аварийного завершения работы сервера) в документах обнаруживаются некорректные цифры. Самое частое объяснение со стороны пользователей — "программа сама поменяла данные". Разберем подробно, возможно ли самопроизвольное смещение запятой или появление новых цифр в числе с технической и юридической точек зрения, а также выясним, как найти доказательства реальных действий пользователя.
Рассмотрим ситуацию, описанную в теме: в поле был установлен процент 40,00, бухгалтер утверждает, что вводила 25,30, но после сбоя в базе оказалось 2540,30. Проанализируем механику работы платформы 1С. Числовые данные в базе хранятся в строгом соответствии с типами данных SQL. Платформа 1С:Предприятие не обладает встроенными алгоритмами, которые бы при сбое питания произвольно модифицировали значения в ячейках таблиц путем «склеивания» старых и новых данных.
Рассмотрим наиболее вероятную причину — человеческий фактор при вводе данных:
Ctrl+A или не сделал двойной клик) и начал вводить «25», эти цифры просто добавятся к существующим «40». В итоге получится 2540.Таким образом, «самопроизвольное» появление цифры 40 внутри числа 2530 — это типичный результат некорректного редактирования поля ввода человеком, а не программного сбоя. Программа не может «вспомнить» предыдущее значение и вставить его в середину нового без команды пользователя.
Если возник спор о том, кто именно виноват в некорректном значении, проанализируем имеющиеся в 1С инструменты аудита:
1. Журнал регистрации
Это первый инструмент, который мы должны проверить. В нем фиксируются события Данные.Изменение. Мы можем увидеть:
Если время записи в журнале совпадает с секундами перед аварией, это подтверждает, что пользователь нажал кнопку записи с уже введенным ошибочным числом.
2. Механизм версионирования объектов
Если в конфигурации (например, в «1С:ЗУП» или «1С:ERP») включено версионирование, мы можем просмотреть историю изменений конкретного документа. Рассмотрим подробнее:
Если в версии четко прописано 2540,30, значит, именно такое число пришло с клиента на сервер.
3. Технологический журнал (ТЖ)
Для системных администраторов это наиболее мощный инструмент. Если настроен сбор ТЖ с событиями DBMSSQL, можно увидеть текст прямого SQL-запроса UPDATE. Это неопровержимое доказательство того, какие именно данные платформа отправила в СУБД.
Вопрос квалификации ошибки крайне важен для работодателя, так как от этого зависит возможность взыскания излишне выплаченных сумм с сотрудника. Разберем позицию судов и законодательства:
Что НЕ является счетной ошибкой:
Согласно позиции Верховного Суда РФ, счетной считается только ошибка, допущенная в результате арифметических действий (сложение, вычитание, умножение). Ошибка ввода (человеческий фактор) под это определение не подпадает.
Что МОЖНО признать счетной ошибкой:
В рассматриваемом случае, если бухгалтер ввела 2540,30 вместо 25,30, это квалифицируется как техническая ошибка ввода (опечатка), и взыскать эти деньги с сотрудников без их добровольного согласия будет крайне сложно.
Чтобы исключить подобные инциденты в будущем, проанализируем и внедрим следующие меры защиты:
Если Объект.ПроцентПремии > 100 Тогда
Отказ = Истина;
Сообщение = Новый СообщениеПользователю;
Сообщение.Текст = "Процент премии не может превышать 100%!";
Сообщение.Сообщить();
КонецЕсли;
Резюме: Самопроизвольное изменение данных программой 1С при сбое — это миф, порожденный спецификой работы интерфейса и невнимательностью при вводе. Все следы действий сохраняются в системе, и их можно выявить при грамотном техническом анализе.