Допустим нужно понять когда и как изменялся документ в базе ут 10, версий и регистрации изменений по нему не велось, но есть массив бекапов sql по дням, ожно как-то не разворачивая каждый вытащить из них одну таблицу или док ? документ списание товаров. Или может по регистру можно вытащить время когда он перепроводился задним числом? через консоль запросов видно что при перезаписи неоперативной меняется Version поле в большую сторону, кажется что как-то зашифровано datetime в нем или нет?

Сначала определить по ЖР в каких датах менялся этот документ.

(1) ЖР такие вещи у нас не фиксировал. Фиксировала обработка контроль изменений, но каким-то чудом этот документ не стоял на контроле. Так что процесс изменений можно отследить либо сравнением построчно либо по полю Version которое как будто инкрементальное, но это без гарантий. Зато оно точно меняется при любом изменении задним числом и становится свежее

(0) Зачем?!

(3) +1
чтобы лазать и искать по инкрементам или бекапам надо иметь выгоду, что такого даст эта информация?

(4) Это займёт туеву хучу времени и сил, а всё ради чего? Чтобы прижучить какого-то буха или манагера?

(3) Увидеть все разом спи...ли или инкрементально. и более точный отрезок времени чем с января 23 по март 24

(5) от тайминга сильно зависит круг причастных...

(5) А еще можно в результате такого расследования выйти на самого себя 🤣

(8) Это пол беды. Хуже когда на ген дира или непосредственного начальника.

(2) ЖР не вёлся вообще?

(7) Вы не вели журналы и лог версий. У Вас ничего не получится.

(0) Ох был у меня такой секас, но за отдельные деньги. Искали за полгода. Бекапы были ежедневные. Задачу решил так.
В текущей базе нашел в какой таблице хранится нужные доки. Нашел их гуиды
Бралась чистая машина. Скриптами поднимал базы в скуль, чисто базы. Без всякой 1С.
Сначала поднимал за каждую неделю, на воскресенье вроде.
Скриптом тоже искал в нужной таблице нужные гуиды и выгружал в новую базу там было всего несколько таблиц повторяющую структура таблиц в 1С, для того чтобы поймать расхождения.
Потом запросом искал период в котором если расхождения. Их уже грузил по дням, и аналогично сравнивал.
По итогу нафуй никому это было не надо, так как этой фигней страдал зам, близкий друг бигбосса, и он когда узнал что начали рыть, сам признался.
Так что работу я эту не доделал. Но в принципе схема рабочая.

(0) >но есть массив бекапов sql по дням
(6) >более точный отрезок времени чем с января 23 по март 24

есть место для такой кучи бекапов, а место под ЖР, который периодически вырезать и в папку, нету? ну или на историю изменения.

просто действительно пройтись по ЖР по событию Данные.Изменение, а дальше чекать в эти даты бекапы

(13) ут 10.3.8   платформа 8.3.10.2772, честно не видел там такого, чтоб писать изменения была вкручена подсистема регистрации изменений, когда это внедрялось основной упор был на риски работы с наличкой, про склад тогда никто не думал тк все было четко. Просто 10 лет прошло, нашелся умник менять списания 16 года... а контролить все уже никто не хотел вот и ищем теперь

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

Начсклада уволился, директор слег в больницу, остальные после ковида так и остались на удаленке. итог печален.

(0) Если не найдете способов вытянуть информацию без разворачивания целиком базы из бэкапа, то можно методом деления пополам. Если факт изменения документа только один, конечно. Например за 30 дней найти получится за 5 действий:
15, 7, 4, 2, 1
А за 60 дней - за 6: 30, 15, 7, 4, 2, 1

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

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

А докапываются до истины пусть пинкертоны. Просто как здраво отметили выше, скорее всего что придется полностью менять всех кто как минимум имел какое-то отношение к складу от кладовщиков до закупщиков и замдиров. Т.к. очевдно: несмотря на то, что хищение было обставлено довольно скрытно технически, но физически вынести 6 часть оборота за 2 года, так что никто не заметил, это надо либо со всеми поделиться, либо глухота и потеря памяти сопровождаемая легкой классовой ненавистью к эксплуататорам..

Не взлетит. Даже , если будет найден "злоумышленник", это не доказательства. А методы 90-х помогают  и без поиска по бэкапам.

(18) направление тебе дали в (12).
1. пишешь скрипт:
1.1 разворачивающий бэкап в общую промежуточную базу
1.2 создающий промежуточные базы на каждый бэкап (день)
1.3 копирующий таблицы требуемого РН из общей промежуточной базы в базу бэкапа
2. пишешь запрос, считающий остатки по РН на "дату первого бэкапа", получаешь его sql-вид (трассировкой, техжурналом, можно и руками написать)
3. применяешь этот sql-запрос попарно к "базам бекапов", и получаешь расхождения в остатках... (аналогично расхождения по документам - хоть все чохом, хоть только по выявленым расхождениям в остатках)

зы. только чем это поможет?

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

(20) Решение красивое, но да, уже сложность превышает полезность. Я понл что ничего не выйдет уже когда осознал что сжатые бекапы это по сути солид архив, который потребуется развернуть целиком.. Но все равно спасибо что приняли участие, стадия принятия все ближе и ближе)

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

(23) "и в старых накладных "
а что вы период не закрываете ?

(21) БД не является доказательством, но помогает искать виновного.

(24)Кто Вы? я у них не работаю. Что хотят закрывают. Мне до их периода дела нет. И вообще, если бы работал, программист должен закрывать периоды ?

(23) Т.е. регулярных инвентаризаций не делали в принципе?

(22) Да ничего особо сложного нет. Да, бэкап (даже и нежатый) - это цельный файл, разворачивать целиком. Но не руками же это делаете - комп железный, пусть он и пыхтит... хоть сутками в несколько потоков... Скрипт - ну, за час с отладкой пишется...
просто максимальный результат, который получается извлечь из бэкапов - это "в ночь с пятницы на понедельник изменен документ xxx, в нем у товара yyy количество изменено с mmm на nnn"

(27)не делали, типа семейный коллектив. Склад огромный по числу позиций

(26) это я подсказываю как начать разговор после выяснения ситуации с этим клиентом

(27) каждую неделю пересчитывать 10к+ позиций муторно, у нас кстати тоже примерно столько и инвентарки делались регулярно, но он получил доступ к компу бывшего замдира у которого были полные права чтоб косяки в документах исправлять. и списывал в 16 году, нашел я случайно наткнувшись на несовпадение цифр прошлых периодв которые помнил, там же все едет... периоды относительно закрывались но это все разговоры в пользу бедных. Дело не в базах и не в правилах а в кадрах. В сизо допустим режим один из самых строгих. однако в камерах всегда запреты. было бы желание... и отсутствие страха.

какой порядок убытков? а то окажется, что кусок колбасы  съел, а шороху - как на состав с золотом

(32) ну судя по (21):

>злоумышленник найден но просто не бьется его личность с обьемом

там не кусок колбасы.

(32) естественно ощутимый. скажем так пятая часть оборота по этой номенклатуре за год. Ладно, я что мог выяснил, дальше сидеть ломать голову над тем что оборотни узнают через 20 минут допроса смысла нет. Главное выяснено, убыток не бумажный, по крайней мере один и тот же кекс в одно и то же время когда он оставался наедине с халатно брошеным открытым терминалом внес около ста позиций в 3 документа на протяжении недели. Вопрос в том конечно, что большая часть изменений сделана неизвестно когда но точно раньше на полгода. Зачем он опять туда полез непонятно, не полез бы и не запалился (как раз так совпало, что код собирающий имя машины и юзера клиента рдп я воткнул за пару дней до)
Ну гадать о мотивах психопатов мы не будем надеюсь следствие выяснит это быстро, мориарти всякие и прочие кайзеры сузе бывают в основном в голивудских триллерах, а тут суда по всему панальная жадность, безнаказанность и вера в свой гениальный план...