Экспертиза 1С

Исследуем базу 1С, конфигурацию, расширения и журналы: что доработано, выполнено ли техническое задание, когда менялись документы и почему расходятся отчёты. Вывод зависит от сохранности спорного состояния и технических следов.

Экспертиза 1С — направление экспертизы ERP-систем. Она отвечает на технические вопросы о платформе, прикладном решении и данных, но не решает, кто нарушил договор, правильно ли исчислен налог и какую сумму должен взыскать суд.

Когда экспертиза 1С подходит для спора

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

На практике к такому исследованию обращаются в следующих ситуациях:

• подрядчик сдал внедрение или доработку 1С:Бухгалтерии, 1С:ЗУП, 1С:ERP, 1С:Управления торговлей либо отраслевого решения, а заказчик оспаривает выполнение измеримого технического требования в указанной версии и сценарии;
• нужно отделить возможности поставки от изменений основной конфигурации, расширений, внешних отчётов и обработок;
• после обновления или миграции изменились расчёты, отказали доработки либо пропали данные;
• представленный отчёт не воспроизводится на базе или расходится с другим экземпляром;
• требуется исследовать зарегистрированные события с документом: создание, изменение, проведение, отмену проведения или удаление;
• две стороны представили разные копии одной базы и спорят об их составе и происхождении;
• обмен с ЭДО, банком, сайтом или другой системой передаёт неполные либо отличающиеся данные;
• после сбоя, ошибочного действия или инцидента информационной безопасности нужно установить технический механизм утраты.

Экспертиза 1С проверяет конкретный объект и конкретный технический критерий — например, реализован ли указанный пункт задания в определённой версии базы и заданном сценарии. Если требуется оценить весь результат разработки по совокупности критериев, проводят экспертизу соответствия работ техническому заданию; фактический объём и стоимость исследуют в рамках экспертизы выполненных работ по разработке ПО, а качество сопровождения и сроки реакции — экспертизы сопровождения и SLA. Вопросы толкования договора и ответственности решает суд.

Предварительная оценка и прогноз результата

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

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

Что нужно для первого шага и что вы получите. Файлы пока не присылайте. Опишите спор, назовите конфигурацию и период, перечислите доступные копии, журналы и документы. По этому описанию специалист определит применимость экспертизы, срочные меры сохранения и минимальный комплект для дальнейшей оценки. Результат зависит от формата работы: консультация, письменное предварительное исследование либо заключение эксперта. В итоговом документе указывают исследованные объекты, выполненные проверки, ответ на каждый вопрос и ограничения. Если надёжный ответ невозможен, это прямо фиксируют с указанием причины.

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

Из чего состоит исследуемая система 1С

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

Паспорт объекта включает следующие элементы:

• Платформа 1С:Предприятие. Это исполняемая среда. Фиксируют сборки клиента и сервера, разрядность, режим совместимости и способ размещения; номер релиза прикладного решения не заменяет эти сведения.
• Основная конфигурация и конфигурация базы данных. Первая представляет редактируемое описание прикладного решения, вторая — применённое к информационной базе состояние, которое определяет доступные пользователям структуру и поведение. Эти состояния могут различаться.
• Конфигурация поставщика. Для решения на поддержке она служит одним из эталонов сравнения. У заказной конфигурации такого эталона может не быть, а у отраслевого решения поставщиков бывает несколько.
• Расширения. Подключённые расширения хранятся в информационной базе. У каждого есть редактируемая версия и применённое к базе состояние; они могут различаться. Само подключение ещё не доказывает, что расширение работало в спорном сеансе. Эксперт проверяет его активность и применимость для нужных пользователей и данных, порядок подключения, совместимость с платформой и ограничения безопасности. Состояния сравнивают штатными средствами; файлы .cfe, отчёты сравнения и другие экспорты хешируют раздельно. Отдельно учитывают добавленные расширением реквизиты, собственные объекты и данные.
• Прикладные данные и эксплуатационные настройки. Это документы, справочники и записи регистров, назначения ролей и профилей пользователям, значения функциональных опций, варианты отчётов, текущие значения разделителей и параметры обменов. Определения ролей, функциональных опций и разделителей относятся к конфигурации, а их назначения и значения — к состоянию информационной базы.
• Журналы и внешняя среда. Журнал регистрации 1С хранится отдельно от информационной базы. Технологический журнал, журналы СУБД, операционной системы, интеграций и провайдера тоже являются самостоятельными объектами.

1С работает в файловом и клиент-серверном режимах; во втором случае под платформой находится, например, PostgreSQL или Microsoft SQL Server. Система может быть локальной, размещённой у подрядчика либо в облаке. От архитектуры зависят способ согласованного копирования, доступные журналы и возможность восстановить состояние на прошлую дату.

Что эксперт может и чего не может установить

Технический вывод должен следовать из поставленного вопроса и представленных объектов. При полной цепочке копий и журналов и при единственной текущей выгрузке один и тот же вопрос даст ответы разной определённости.

При достаточном материале эксперт может установить:

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

Вместе с тем сами по себе эти объекты не позволяют сделать следующие выводы:

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

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

Как отделяют поставку от доработок

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

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

У заказной конфигурации может не быть поставщика, а нужный релиз отраслевого решения может отсутствовать среди представленных материалов. Тогда сравнивают версии между собой и используют историю разработки: хранилище конфигурации, репозиторий EDT, сборочные артефакты, файлы .cf и .cfe, реестр выпусков, заявки и передаточные документы. Такие источники позволяют связать изменение с версией, записью и учётной идентичностью. Личность автора, достоверное время и принадлежность работы договору устанавливают только после проверки происхождения истории, порядка аутентификации, использования общих записей, настроек времени и сопоставления с независимыми документами и журналами.

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

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

Как исследуют журнал регистрации и время изменений

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

До анализа устанавливают исходный формат и место хранения. Исходное хранилище журнала фиксируют целиком после прекращения записи либо средствами согласованного снимка; если это невозможно, штатно сохраняют копию журнала на зафиксированную границу и документируют способ, время и неизбежные изменения. Затем фиксируют период и границы файлов, настройки уровней регистрации, возможные пропуски и операции сокращения. Отдельно проверяют часовой пояс информационной базы и сеанса, узел сервера, источник синхронизации времени и доступные сведения об изменении часов.

Журнал не входит ни в выгрузку .dt, ни в резервную копию самой базы средствами СУБД: в файловом режиме он находится в отдельном каталоге рядом с базой, а в клиент-серверном — в каталоге кластера 1С. Загрузка .dt не переносит исходный журнал регистрации и не очищает журнал целевой информационной базы. Поэтому записи рядом с развёрнутой исследовательской копией нельзя относить к исходной системе без отдельного подтверждения их происхождения. Настройку детализации можно изменить, а старые записи — сократить с сохранением в архив или без него; отрицательный вывод возможен только после проверки полноты источника.

Изменение может не оставить предметной записи 1С, если оно выполнено в обход прикладных механизмов, например прямой правкой таблиц СУБД или заменой состояния базы из копии. Восстановление или загрузка выгрузки не создаёт подробную историю прежних операций с каждым объектом. Внешнее соединение, веб-клиент и фоновые задания, напротив, работают через платформу; возможность увидеть их действия зависит от настроек регистрации и конкретного события.

У документа также различают прикладной реквизит «Дата» и время зарегистрированного события. Реквизит может заполнить пользователь или программный код, а журнал отражает показания системных часов. Для проверки времени используют независимые источники с установленным происхождением: квалифицированные метки службы времени, квитанции оператора ЭДО, транспортные протоколы, журналы инфраструктуры. Наличие электронной подписи без доверенной метки времени само по себе дату создания документа не подтверждает.

Отчёты, обновления и технические сбои

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

При проверке рассматривают несколько объяснений:

• документ записан, но не проведён либо его движения изменились после перепроведения;
• применены другие настройки учёта, функциональные опции, отборы или права либо состояния баз разошлись после ограничения операций датой запрета изменения;
• результат формирует доработанный отчёт, расширение, внешняя обработка или интеграция;
• обновление изменило объект поставщика, а конфликт с доработкой был разрешён иначе;
• миграция перенесла не весь состав, преобразовала значения либо нарушила связи;
• причина находится в производительности, блокировках, СУБД, инфраструктуре или внешнем сервисе.

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

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

Граница с бухгалтерской и налоговой экспертизой

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

Разделение выглядит так:

• техническое извлечение реквизитов документов, записей регистров и событий журнала регистрации, а также исследование алгоритма и настроек относятся к компьютерно-технической части;
• достоверность отражения хозяйственных операций и соответствие отчётности данным учёта относятся к бухгалтерской экспертизе;
• проверка расчёта налоговой базы и суммы по заданным фактам и правовым предпосылкам требует налоговой экспертизы и, при необходимости, иных специальных знаний;
• выбор применимой нормы, правовая квалификация операции, толкование договора, вина, наличие убытков и сумма, подлежащая взысканию, относятся к компетенции суда.

Эксперт по 1С может показать, по какому алгоритму система получила сумму и какие исходные записи использовала. Он не подтверждает этой операцией, что первичный документ достоверен, налог рассчитан верно или отчётность соответствует законодательству.

Какие объекты и документы нужны

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

Для разных задач обычно нужны следующие сочетания:

• Доработки и техническое задание: конфигурации, расширения, внешние обработки, точные версии среды, договорные документы, задания, заявки, акты и история версий; учётные данные нужны только для воспроизведения конкретного сценария.
• Хронология: исходная копия состояния на согласованную дату, отдельный журнал регистрации с настройками, сведения о часах и пользователях, а при наличии — журналы доступа, инфраструктуры и СУБД.
• Расхождение отчётов: база, вариант и настройки отчёта, права тестового пользователя, спорные экземпляры, период и формализованный критерий расчёта.
• Обновление или миграция: состояния до и после, журналы работ, файлы поставки, правила преобразования, контрольные показатели и документация исполнителя.
• Сбой или утрата: неизменённый текущий объект, резервные копии, цепочка журналов транзакций или WAL при её наличии, технические журналы и описание первых действий после события.

Для фиксации файлового режима предпочтительна копия закрытого файла 1Cv8.1cd вместе с отдельными каталогами журналов. Для клиент-серверного режима получают транзакционно согласованную резервную копию средствами конкретной СУБД; вынесенное хранилище двоичных данных при его наличии фиксируют на согласованный момент либо документируют временной разрыв. Выгрузка .dt может быть достаточна для отдельных вопросов, но не заменяет регламентную резервную копию и не содержит журнал регистрации.

Если требуется восстановление на момент времени, одного текущего журнала транзакций недостаточно. Для PostgreSQL нужна пригодная базовая копия и сохранённая цепочка WAL, для Microsoft SQL Server — совместимая последовательность резервных копий с журналами в соответствующей модели восстановления. Возможность проверяют до любых восстановительных действий.

Что сохранить до обращения к эксперту

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

Работу организуют через три уровня: исходную контрольную копию, рабочую копию для исследования и, когда это допустимо, производную копию с минимизированными данными. Для исходной копии сразу вычисляют контрольную сумму SHA-256, затем запрещают запись в неё и хранят с отдельным контролем доступа. Для каждого объекта записывают источник, способ и время получения с часовым поясом, размер, контрольную сумму, отправителя, получателя и все последующие передачи.

До начала исследования специалисту поручают:

• сохранить доступные штатные резервные копии до и после спорного события и снять их с плановой ротации;
• для файловой базы прекратить сеансы и скопировать файл базы вместе с каталогами журналов, не открывая полученную исходную контрольную копию для работы;
• для клиент-серверной базы создать согласованную копию штатными средствами СУБД, синхронно сохранить вынесенное хранилище двоичных данных при его наличии и отдельно скопировать каталог журнала регистрации 1С;
• администратору СУБД сохранить пригодную резервную копию и непрерывную цепочку журналов штатными средствами; активные журналы вручную не перемещать и не сжимать;
• отдельно сохранить технологический журнал 1С, журналы интеграций и провайдера, если они относятся к вопросу, не запуская их очистку или сокращение;
• зафиксировать сборки платформы, режим совместимости, основную конфигурацию и конфигурацию базы данных, поставщиков, расширения, внешние обработки, роли и настройки обменов;
• сохранить документы проекта, заявки, акты, переписку и спорные отчёты в исходных форматах вместе с их метаданными;
• вести журнал действий: кто, когда, каким средством и с каким результатом получил каждый объект.

Контрольная сумма позволяет при последующей сверке проверить, совпадает ли файл по байтовому содержимому с состоянием на момент первичного вычисления; сама по себе она не подтверждает его происхождение, дату или непрерывную неизменность между проверками. Эти обстоятельства оценивают по акту получения, независимой фиксации, серверным журналам и процессуальному порядку истребования. Не копируйте чужую систему и не используйте чужие учётные записи: доступ получают на предусмотренном законом или договором основании, в том числе с согласия владельца либо в порядке, определённом назначившим органом.

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

Как передать материалы безопасно

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

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

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

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

Как проводится исследование

Сначала составляют реестр объектов и проверяют их пригодность. Эксперт фиксирует контрольные суммы, формат, заявленные источник и дату состояния, документы и технические признаки, на которых эти сведения основаны, а также различает исходные контрольные объекты и созданные из них рабочие копии. Неполный или повреждённый комплект не подменяют предположениями: указывают, для какого вопроса и какого шага его недостаточно.

Затем разворачивают изолированный стенд. В нём воспроизводят необходимые сборки клиента и сервера 1С, режим совместимости, конфигурации, расширения, СУБД, роли и разделители данных. Для каждого сценария отдельно фиксируют исходный снимок или контрольную точку, существенные версии и настройки ОС и СУБД, региональные параметры и часовой пояс, лицензии, внешние и нативные компоненты, профиль безопасности и условия нагрузки. Исходящие обмены, почту, банк, ЭДО, регламентные и фоновые задания отключают либо заменяют контролируемыми заглушками, чтобы исследовательская копия не обратилась к рабочим сервисам. Все отличия стенда от исходной среды фиксируют.

Дальнейший алгоритм зависит от вопроса:

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

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

Примеры вопросов на экспертизу

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

Вместо общей просьбы «проверить базу» укажите конфигурацию, спорный сценарий, документ, отчёт или журнал. Существенные реквизиты включают в вопрос или однозначно определяют в перечне объектов. Возможные формулировки:

1. Каковы основная конфигурация и конфигурация базы данных представленного объекта, какие различия между ними имеются, какой режим совместимости установлен, какие конфигурации поставщиков и режимы и правила поддержки зафиксированы?
2. Какие различия имеются между конфигурацией базы данных представленного объекта и конфигурацией поставщика указанной версии и контрольной суммы?
3. Какие расширения подключены, различаются ли их редактируемые состояния и состояния в конфигурации базы данных, какие из них фактически применимы в указанной области и сеансе и каково их влияние на спорный сценарий, включая добавленные ими объекты и данные?
4. Выполняется ли проверяемый критерий указанного пункта технического задания при заданном сценарии, исходных данных, роли пользователя и программной среде?
5. Какой результат формирует указанный отчёт при заданных варианте, параметрах, периоде, роли и состоянии базы и какие прямо заданные арифметические и логические правила указанной методики реализует его алгоритм?
6. Какие сведения об указанных документах и их движениях содержатся в представленной информационной базе на дату её фиксации?
7. Какие события в отношении указанного документа содержатся в представленном журнале регистрации, с какими учётными записями, сеансами, приложениями, статусами транзакций и системными отметками времени они связаны?
8. Совпадают ли значения контрольных сумм представленных файлов и какие различия имеются в выбранных данных и конфигурациях, содержащихся в них информационных баз?
9. Какие изменения между состояниями до и после обновления или миграции относятся к конфигурации, расширениям и данным и с каким техническим механизмом связан указанный отказ?
10. Позволяет ли представленный комплект воспроизвести указанный сценарий в заданной среде и какие компоненты, данные, лицензии или параметры для этого отсутствуют?

Компьютерно-техническому эксперту не ставят вопросы о достоверности отчётности, правильности налогообложения и размере убытков. Бухгалтерский или экономический эксперт может выполнить профильную проверку по заданным исходным данным; правовую квалификацию, наличие убытков и сумму взыскания определяет суд. Формулу «когда и кем» заменяют вопросом о сведениях технических источников.

Форматы работы и результат

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

При возможности ответить итоговый документ содержит:

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

Если обязательный объект отсутствует или непригоден, эксперт не заменяет его догадкой. Во внесудебном документе это отражается как ограничение или невозможность ответа; в назначенной экспертизе эксперт действует в установленном процессуальном порядке и сообщает назначившему органу о препятствии. Заключение не имеет заранее установленной силы и оценивается судом вместе с другими доказательствами.

От чего зависят стоимость и срок

Стоимость зависит не от названия конфигурации, а от объёма проверяемой работы. Сравнить несколько изменённых объектов проще, чем исследовать сотни доработок; изучить одну сохранённую копию — чем восстановить цепочку состояний; повторить отчёт — чем воспроизвести сбой, зависящий от нагрузки, СУБД и внешних сервисов.

При расчёте учитывают:

• число вопросов, баз, версий и спорных периодов;
• размер базы и файловый, клиент-серверный либо облачный режим;
• число конфигураций поставщиков, расширений, внешних обработок и интеграций;
• сохранность журнала регистрации, резервных копий, WAL или журналов транзакций;
• необходимость восстановить среду, сравнить состояния и воспроизвести нагрузку;
• участие бухгалтерского, налогового, экономического или иного эксперта.

Ориентир для судебной экспертизы — от 100 000 ₽, ориентировочный срок — от 10 рабочих дней. Точную смету и момент начала срока определяют после согласования вопросов и проверки комплектности материалов; получение дополнительных объектов через суд может изменить календарный срок.

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