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

(0) Лучше не в реквизите всё-таки, а в файле. Незачем раздувать базу.

(0) красиво никак. сделать док служебный типа реализация2. и туда писать таблицы подчинив его основному. типа история изменений.
либо ТЗ выкидывать в файл и хранить на лиске гдето.

(1) (2) Спасибо

лучше уж не в файле а в бд какой. если скл - то можно и в тойже самой

(0) в 99% случаев эта инфа нахрен не нужна. в оставшемся проценте - пользы от нее тоже мало.
если ограничиться интерактивным изменением - то тупо писать в текстовый файл. у меня так пишется. хрен знает сколько лет. пользы никакой.. ;-)

(5) Сегодня озадаченные кладовщики прибежали - глаза по 5 рублей
-На 8.11.2019 на момент ревизии товара было 28 шт, а сейчас формируем на момент ревизии 58 шт.
Кто то из бухгалтеров помнит что что то менялось с этим товаром и что то правили задним числом а что не помнят, так вот думаю такая приблуда могла бы помочь найти концы.

(6) А не хер базу менять просто так! На каждый чих должна быть первичка. Вот по ней и устанавливается истина.

(6) Поднял бэкап и посмотрел.

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

(8) Бэкапы хранятся за 2 месяца, да и даже подняв бэк и увидев что там было 28 шт от этого не легче. Сидеть каждый документ просматривать журналом регистрации - который не всегда всю истину покажет, тоже не вариант.

(10) при каждом проведении именно при проведении писать тек ТЗ в файл. и писать также пот каким юзером

(11) Да да, так будет отлично. Еще можно запрашивать причину редактирования чтобы указывали.

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

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

(12) охереть сколько будет лишнего мусора при перевпроведении базы

вариантов изменения количеств а- не так уж и много - поступление, списание, обприходование, возвраты.
обычно - причина таких "глюков" - возвраты. они отрабатываются долго. в ТИС ордерной схемы нет, поэтому по факту пересчет/работа с возвратом закончились сегодня, а на учет задним числом поставили сзади.

(15) ничего страшного. только файлики в каталоге которые можно периодически по старости подчищать. более того можно хранить только 5 последних версий.

а перепроведение базы.. можно при перепроведении ставить константу - не писать логи.

а еще можно при проведении вычислять контр сумму табличной части. колво строк + итого колво + итого сумма ++++ несколько разного.
далее сравникать с контр суммой в посл файле. не совпадает - писать тек

(16) да вычерки которые ретактируют бухи а не склад всегда проблема для ругани со складом.
особенно если товар развозит водитель

(17) да было уже, вычислять хэш документа...
а еще можно блокчейн прикрутить - модно, стильно, молодежно!

(18) угу, это не техническая, это организационная проблема.
у меня в оперативной базе бухи вводят только выписик и проводят зачеты поставщик-покупатель. все.
.

(19) это уже лишнее. не стоит все доводить до маразма. вешать на проведения какие-то тормоза глупо. прощу тупо писать в файл без вопросов. запись файла на ФС итак время занимает

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

(22) это правильно.
занимание херней должно отнимать кучу времени, чтобы отпало желание заниматься херней.

(10) Зачем? У тебя вопрос по одной позиции. Взял отчет "Ведомость товаров" по одной позиции в разрезе документов. Сравнил, нашел по каким данным изменились движения. Там будет несколько документов. Зашел в журнал регистрации, нашел виновника, отрубил ему руки. Всё, вопрос закрыт.

В 8ке видел документ для закупок, где таблицы прайсов поставщиков хранились в строках табличной части (как хранилище значения). Один документ сжирал 100мб в базе :)

(24) Поддерживаю. я обычно так и делаю. когда последний раз делал - хз, уже и не помню...
.
один из крупных траблов был, когда я укатил в отпуск, только заселился, меня по тлф достают - база колом встала. ...ь! пришлось бегать искать инет, а это давно было, тогда инет проблемный был. убил кучу времени пока подключился. все оказалось тривиально, нашел быстро. бухгалтер "старой закалки". зашла в базу и удалила трехмесячной давности "неверный" возврат покупателя....

"ТЗ в реквизитах документа" - это не панацея.

Простой пример:
1. Ввели документ.
2. Провели.
3. Прошло два дня, выяснилось, что оператор накосячил. Нашли оператора, вставили люлей. Исправили документ.
4. Прошло два месяца. Какой-то нехороший человек, зашел в прошлый период и изменил документ.
5. Прошло какое-то время, ответственные лица по складу увидели, что остатки поплыли. Побежали разбираться.

Ситуация максимально приближенная к реальной.

И тут возникают несколько вопросов:
1. Как тебе поможет ТЗ?
2. Какая информация будет хранится в ТЗ?
3. Кто гарантирует,  что в ТЗ корректная информация?

(27)
странные вопросы. даже если док проверить через 2 сес. то дата файла то текущая. ставнив 2 последних тз можно понять что изменили
меняют то табличную чать. табличную часть самое простое выгрузить в ТЗ и сохранить файл

автору надо знать кто и что менял

(28) АВТОРУ это не надо.
стравить склад и бухов - пусть открыжат позицию как VladZ yfgbcfk - и заниматься далее своими делами.
пусть ПОТРАХАЮТСЯ так, чтобы болело все.
иначе - не дойдет.

(6) Была реализация полгода назад. Потом пометили на удаления и месяц назад запустили удаления помеченных.
Вперед ищи свое ТЗ до посинения

(30) не стоит впадать в крайности от просто идиотов. у автора задача простая.

(29) прежде чем когото в чем то ограничивать, надо доказать, что эти вот уроды..
для начала надо понять кто и где

да и автор не в праве решать орг вопросы кто когда и как правит доки.

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

1) Можно в документе создать строковый реквизит с неограниченной длинной и записывать таблицу значений ЗначениеВСтроку
2) Создать справочник где будет ИД документа и реквизит с неограниченной длинной и записывать таблицу значений ЗначениеВСтроку
3) Сохранить таблицу значений во внешний файл ЗначениеВФайл

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

Можно сделать проще (по крайней мере я так сделал в одной конфе)- разрешить править документ только автору документа, а всем остальным запретить любие действия с документом

(36) Тоже не выход: автор заболел или уволился. И к айтишнику прибегут с фразой "Красавчик, помоги!"

(37) - это уже частный случай.

(38) на складах такая текучка, что это перейдет в обычный случай

Короче! Всех - расстрелять солеными помидорами!

(40) Да я всеми руками ЗА , за отрубание кривых рук, и прочие изощренные методы инквизиции, но бухи по другому не могут.
Безнал выписывают именно они и случаи разные бывают - переместили больше чем потом пришли забирать и еще куча всяких, поэтому никак не хотят отойти от такой схемы

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

(42) это не задача прога. Это задача руководства.

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

если есть воля руководства навести порядок - он будет и без прога. Если нет - это пустая борьба и трата нервов.
А вот логи и если при разборе показат а кто - это в работе прога. И далее пусть там сами ломают труг другу головы

(43) согласен. но руководство разное бывает. и есть руководство которое до таких "мелочей" - не опускается. и тогда прог1С становится "бизнес-аналитиком" - определяет КАК делать.
.
да, руководство может дать "санкцию". сталкивался с таким. я поступал просто - говорил руководству - как бизнес-аналитик - так делать не надо. руковдство дожимает. нивапрос. делаем. потом наступает вреям когда приходится искать "ккто что сделал" - как выше. и я - этим на занимался. а так как никто разгрести это не мог - выставлял соответсвующий прайс. ибо ССЗБ.
.
но, если как "прог" - ну кому охота - то нехай тыкает в кнопки за пользователями. и сопли им подтирает. я тоже этим долгое время занимался. потом плюнул. оказалось - что так проще и спокойнее. если надо - пусть "платят" как подтирщику соплей вдобавок как прогу и БА. результат - оценивать можно по разному, в общем - не жалею. надо было еще раньше так поступить.

первый закон: бардак автоматизировать нельзя.

ну как-то же с ним надо бороться? или не надо?
мой мелкий опыт показывает - что руководство устраивает когда получает то что ожидает. а так как ожидания строятся из прошлого опыта (когда бардак-болото) то без принципиального изменения в принципах (чего*) вся автоматизация все равно скатывается в "болото", видимо у "лавочников" это неискоренимо. а вот как в других компаниях у коллег - хз. забюрократизирвоано? заадминистрировано? зарегламентировоно? шаг влево/вправо - расстрел?

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

(45) Можно, при этом получится "автоматизированный бардак". Я сто раз так делал))

У меня стоит дата запрета редактирования Текущаядата() минус неделя(количество днейОпределяется константой)
хочешь изменить задним числом, меняй, в справочник идет запись,кто менял, когда и зачем, обоснование "зачем" обязательно для изменения датызапертаредактирования, от такот
ПыСы для каждогоПользователя датазапертаредактирования своя и изменив ее у других она не меняется

в 8ке история изменений для этого есть.
почему нельзя хранить все в отдельной табличной части в виде номера версии и предыдущих значений?

и еще как сохранить консистеность данных? это только если хранить в виде таблицы в базе это дело. опять же табличная часть подходит.

(50) (51) Да нахер это не надо, надо боротся не со следствие а с причиной, раздувать базу- так себе занятие, ну бух изменила док, было 10 стало 20 или наоборот, и что дальше то? что вы ей скажите, что изменится то?
она скажет да меняла, а нахера? непомню, дальше что- премии ее лишите? она вас набуй пошлет и все на этом закончится, вот и все разборки, зато будуте гордо, во бух ссучка, 10 на 20 именила, я не я типа, сбейтесь, это нахер никому не надо, дату запрета выставил и все, надо изменить - кто зачем и почему и все

(52) самое логичное, конечно - это не давать базе разрастаться. тут я согласен.

(52) те ты отрицаешь нужность истории изменений?

Кхм... в камине 2.0 вторую табличную часть хранят в аналогичном документе, созданном в другом времени (10 лет вперед или 10 лет назад).
Хранить ТЗ в виде строки в реквизите - не есть хорошо, т.к. теряются ссылочная целостность при удалении объектов. В смысле, в ТЗ есть ссылка на объект. ТЗ лежит свернутое в строку. Объект пометили на удаление и потом удалили вовсе. Разворачиваем ТЗ из строки и видим - объект не найден.

(0) Хочешь иметь историю - ну так и храни копии базы не за 2 месяца, а за всю жизнь. Закроет твою хотелку на 99%. Что у тебя там за 7ка такая неподъёмная? Даже 100 мегабайт ежедневная копия - терабайтного диска на 3 года хватит, а если только воскресные копии, то и на 20 лет. А в 2040 году купишь себе диск побольше, или удалишь старые копии, или поставишь 1С 9.9.
Возник вопрос - поднял копию за дату, когда бух говорит всё было не так. Вывел ведомости в старой базе и текущей - скинул в Excel, скопировал на один лист, формулу написал на разность суммы - увидел с какого документа пошла проблема. Открыл в обоих базах документ - увидел, что поменяли.
Если надо больше - посмотрел в текущей базе, кто этот документ записывал по журналу регистрации и когда, открыл копии после каждой записи, сравнил до и после. Увидел, кто враг.

Хочешь хранить историю документа - храни. В отдельный mxl по каждому документу записывай при записи документа контролируемые реквизиты (можно и при печати - делал так в расходной накладной для контроля воровства). Но надо помнить про встроенные и внешние  обработки - в них тоже надо прописать запись состояния документа в mxl, если они документ записывают. В документ кнопку, по которой этот mxl открывается - ответственные бухи очень радуются.

если писать дифференциальные бэкапы,то и история будет видна и место раздуваться не будет.

(54) в первую очередь - это организационные проблемы и постановка работы с клиентами. я ж писал - у меня ведется история изменений уже хрен знает сколько лет. за последние два года я не помню чтобы я туда смотрел или был вопрос кто зачем изменил. Просто так выстроил процессы. и ничего, нормально.
.
дабы не править и не вводить задним числом в базе УУ/ОУ - я бы вообще все вводил только в ТА. и реквизиты дата и номер входящих доков (считаем что это соответсвует дате отражения данных в БУ). а при перекидке в БУ-базы - ставить доки именно по этим датам "как надо бухам". в ОУ/УУ я навскидку не придумаю о необходимости изменения доков задним числом. то что в ОУ/УУ меняют/вводят доки задним числом - это рудименты/хвосты принятой парадигмы - дата регистрации=дате проведения.