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

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

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

Пять слов, которые дальше встретятся часто

Термины 1С звучат обманчиво знакомо, а значат не то, что кажется. Разберём их сразу, чтобы дальше читать без запинок.

Вот они:

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

Какие споры разбираем

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

Чаще всего это такие ситуации:

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

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

Чем 1С отличается от обычной разработки

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

Отсюда три особенности, которых нет у других систем:

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

Платформа при этом не одна: 1С:Предприятие 8.3 работает в файловом и в клиент-серверном режиме, под клиент-серверным лежит СУБД — чаще всего PostgreSQL или Microsoft SQL Server, — а сама база может быть развёрнута у вас, у партнёра или в облачном сервисе. От режима зависит, какие следы вообще существуют и что из них можно получить.

Типовое, доработанное и расширения

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

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

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

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

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

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

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

Как проверяют соответствие техническому заданию

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

Дальше каждое требование проверяют на конкретной версии конфигурации и на согласованных данных, а результат раскладывают на пять исходов:

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

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

От какой учётной записи и когда внесено изменение

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

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

Пределы у этих механизмов такие:

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

Отсюда два практических следствия. Вывод эксперт формулирует как техническое обстоятельство: операция выполнена от такой-то учётной записи, в таком-то сеансе. Отождествление учётной записи с конкретным человеком и оценка его намерений — вопрос суда. И отрицательный вывод «в журнале ничего нет, значит ничего не было» сам по себе недопустим: сначала проверяют, велась ли регистрация нужных событий и не могло ли изменение пройти мимо платформы.

Дата документа и фактическое время записи

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

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

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

Почему цифры в отчёте расходятся

Расхождение сумм — самая частая причина обращения, и почти всегда оно объясняется устройством учёта, а не ошибкой в арифметике. Отчёт в 1С строится не по документам напрямую, а по регистрам — накопления, бухгалтерии, сведений, — куда документ пишет движения в момент проведения.

Отсюда типовые причины расхождения:

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

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

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

Что ломается после обновления

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

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

• Конфигурация на поддержке с включённой возможностью изменения. Обновление вендора устанавливается штатно, но по изменённым объектам платформа предлагает разрешить конфликт вручную. Если это делает не тот, кто писал доработку, её логика теряется или смешивается с новой типовой — отсюда «после обновления всё сломалось».
• Конфигурация полностью снята с поддержки. Штатное обновление применить нельзя вообще: сравнивать и объединять приходится с полным дистрибутивом новой типовой конфигурации, вручную и целиком. Это дороже, дольше и чаще всего именно здесь теряются доработки.

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

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

Эту границу приходится проговаривать чаще всего, потому что 1С — система учёта, и вопросы к ней естественно формулируются на языке бухгалтерии. Разделение простое: мы устанавливаем, что система технически делала и какие данные в ней есть, а оценку самого учёта дают другие специальные знания.

На практике это выглядит так:

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

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

Какие объекты исследуются

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

База, конфигурация и расширения

Эти материалы собирают вместе: по отдельности они отвечают на меньшее число вопросов, а сопоставление конфигурации с эталоном поставщика и есть основная проверка.

В группу входят:

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

Настройки, журналы и документы проекта

Вторая группа объясняет, почему одна и та же конфигурация ведёт себя по-разному, и что происходило с данными.

В неё входят:

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

Отчёты и выгрузки, полученные от другой стороны, мы рассматриваем как объекты с проверяемым происхождением: значимые показатели получаем сами на переданной копии и описываем условия, в которых их получили.

Что сохранить прямо сейчас

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

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

Поручите специалисту следующее:

• снять полную копию информационной базы — выгрузку .dt или резервную копию средствами СУБД — и сохранить её отдельно от рабочей;
• отдельно скопировать файлы журнала регистрации за спорный период. Его не содержит ни выгрузка .dt, ни резервная копия средствами СУБД: в клиент-серверном варианте журнал лежит в каталоге сервера 1С и в дамп базы не попадает. Штатную операцию сокращения журнала при этом не использовать — она сохраняет записи в файл и удаляет оригинал;
• сохранить файл конфигурации и файлы всех подключённых расширений;
• снять с ротации и сохранить имеющиеся резервные копии базы на даты до спора и журналы СУБД за спорный период: копии перезаписываются по расписанию и исчезают, пока стороны переписываются;
• записать версию платформы, наименование конфигурации и номер релиза, режим поддержки и дату запрета изменения на момент фиксации;
• для каждого файла записать дату и время с часовым поясом и посчитать контрольную сумму — короткую строку, которая пересчитывается из содержимого файла и меняется при любой его правке. В Windows её считает команда Get-FileHash в приложении PowerShell. Она подтверждает, что файл не менялся с момента вычисления, — но только если само значение зафиксировано вне вашего контроля: в акте с подписями, в протоколе нотариуса или в описи материалов, поданных в суд. Хеш, записанный и хранимый одной стороной, доказывает не больше, чем её слова;
• записать, кто, когда и от кого получал материалы и что с ними делал.

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

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

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

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

К передаче подготовьте:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Формат выбирают по стадии спора:

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

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

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

Решают три вещи, и все три специфичны для 1С. Первая — объём доработок: сравнение с конфигурацией поставщика может дать десяток изменённых объектов, а может несколько сотен, и каждый из них нужно соотнести с требованием задания; разница между этими случаями кратная, поэтому ориентир — нижняя граница, а не средняя цена. Вторая — сохранность следов: база с полным журналом регистрации отвечает на вопросы о хронологии сразу, а база без него требует обходных построений и не всегда даёт определённый ответ. Третья — число баз и копий: спор о двух представленных экземплярах одной базы — это сравнение, а не два исследования, но и не одно. Дальше обычное: размер базы и режим работы, число вопросов, необходимость смежных специальных знаний — комплексное исследование с бухгалтерским экспертом считается отдельно. Ориентир для судебной экспертизы — от 100 000 ₽, ориентировочный срок — 10 рабочих дней; смету по вашему объёму называем после просмотра материалов.

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