Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 7.7 и ранее

v7: Хранить ТЗ в реквизитах документа

v7: Хранить ТЗ в реквизитах документа
Я
   brenli
 
10.03.20 - 15:29
Всем привет.
Задача такая, при изменении документа задним числом записывать состояние табличной части,  и потом просматривать при необходимости.
Как можно реализовать красиво?  Понимаю что  ТЧ можно выгрузить в ТЗ и сериализовывать в файл при записи задним числом.
Что еще можно сделать? Сериализовать в строку и хранить в реквизите документа?
   Провинциальный 1сник
 
1 - 10.03.20 - 15:31
(0) Лучше не в реквизите всё-таки, а в файле. Незачем раздувать базу.
   mishaPH
 
Модератор
2 - 10.03.20 - 15:31
(0) красиво никак. сделать док служебный типа реализация2. и туда писать таблицы подчинив его основному. типа история изменений.
либо ТЗ выкидывать в файл и хранить на лиске гдето.
   brenli
 
3 - 10.03.20 - 15:32
(1) (2) Спасибо
   pechkin
 
4 - 10.03.20 - 15:32
лучше уж не в файле а в бд какой. если скл - то можно и в тойже самой
   Злопчинский
 
5 - 10.03.20 - 15:34
(0) в 99% случаев эта инфа нахрен не нужна. в оставшемся проценте - пользы от нее тоже мало.
если ограничиться интерактивным изменением - то тупо писать в текстовый файл. у меня так пишется. хрен знает сколько лет. пользы никакой.. ;-)
   brenli
 
6 - 10.03.20 - 15:42
(5) Сегодня озадаченные кладовщики прибежали - глаза по 5 рублей
-На 8.11.2019 на момент ревизии товара было 28 шт, а сейчас формируем на момент ревизии 58 шт.
Кто то из бухгалтеров помнит что что то менялось с этим товаром и что то правили задним числом а что не помнят, так вот думаю такая приблуда могла бы помочь найти концы.
   Irbis
 
7 - 10.03.20 - 15:44
(6) А не хер базу менять просто так! На каждый чих должна быть первичка. Вот по ней и устанавливается истина.
   VladZ
 
8 - 10.03.20 - 15:45
(6) Поднял бэкап и посмотрел.
   ChMikle
 
9 - 10.03.20 - 15:48
(0) т.ч. могут менять несколько раз и при этом разные данные , лучше уж тогда изменения регистрировать в журнале событий , а потом по документу или номенклатуре отбирать штатными средствами события.
   brenli
 
10 - 10.03.20 - 15:48
(8) Бэкапы хранятся за 2 месяца, да и даже подняв бэк и увидев что там было 28 шт от этого не легче. Сидеть каждый документ просматривать журналом регистрации - который не всегда всю истину покажет, тоже не вариант.
   mishaPH
 
Модератор
11 - 10.03.20 - 15:49
(10) при каждом проведении именно при проведении писать тек ТЗ в файл. и писать также пот каким юзером
   brenli
 
12 - 10.03.20 - 15:50
(11) Да да, так будет отлично. Еще можно запрашивать причину редактирования чтобы указывали.
   Злопчинский
 
13 - 10.03.20 - 15:52
(6) не пускайте бухгалтеров в базу оперативного учета. тем более в базу на которую завязаны физическими сущности склада. масимум что булгахтерам можно дать - работу только и исключительно в ТА.
   Злопчинский
 
14 - 10.03.20 - 15:53
(10) да, именно так. потом надавать всяким долбоебам пиздюлей от души так, чтобы дрожь пробиралда от одной мысли взад залезть.
   Злопчинский
 
15 - 10.03.20 - 15:54
(12) охереть сколько будет лишнего мусора при перевпроведении базы
   Злопчинский
 
16 - 10.03.20 - 15:55
вариантов изменения количеств а- не так уж и много - поступление, списание, обприходование, возвраты.
обычно - причина таких "глюков" - возвраты. они отрабатываются долго. в ТИС ордерной схемы нет, поэтому по факту пересчет/работа с возвратом закончились сегодня, а на учет задним числом поставили сзади.
   mishaPH
 
Модератор
17 - 10.03.20 - 15:58
(15) ничего страшного. только файлики в каталоге которые можно периодически по старости подчищать. более того можно хранить только 5 последних версий.

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

а еще можно при проведении вычислять контр сумму табличной части. колво строк + итого колво + итого сумма ++++ несколько разного.
далее сравникать с контр суммой в посл файле. не совпадает - писать тек
   mishaPH
 
Модератор
18 - 10.03.20 - 15:59
(16) да вычерки которые ретактируют бухи а не склад всегда проблема для ругани со складом.
особенно если товар развозит водитель
   Злопчинский
 
19 - 10.03.20 - 16:00
(17) да было уже, вычислять хэш документа...
а еще можно блокчейн прикрутить - модно, стильно, молодежно!
   Злопчинский
 
20 - 10.03.20 - 16:01
(18) угу, это не техническая, это организационная проблема.
у меня в оперативной базе бухи вводят только выписик и проводят зачеты поставщик-покупатель. все.
.
   mishaPH
 
Модератор
21 - 10.03.20 - 16:02
(19) это уже лишнее. не стоит все доводить до маразма. вешать на проведения какие-то тормоза глупо. прощу тупо писать в файл без вопросов. запись файла на ФС итак время занимает
   ChMikle
 
22 - 10.03.20 - 16:02
можно дату запрета редактирования документов сдвигать на текущую()-1 и для того чтобы какой-то документ исправить задним числом служебку с указанием причины , документа его номера , даты , позиции и исправленияреквизита
   Злопчинский
 
23 - 10.03.20 - 16:04
(22) это правильно.
занимание херней должно отнимать кучу времени, чтобы отпало желание заниматься херней.
   VladZ
 
24 - 10.03.20 - 16:12
(10) Зачем? У тебя вопрос по одной позиции. Взял отчет "Ведомость товаров" по одной позиции в разрезе документов. Сравнил, нашел по каким данным изменились движения. Там будет несколько документов. Зашел в журнал регистрации, нашел виновника, отрубил ему руки. Всё, вопрос закрыт.
   ptiz
 
25 - 10.03.20 - 16:13
В 8ке видел документ для закупок, где таблицы прайсов поставщиков хранились в строках табличной части (как хранилище значения). Один документ сжирал 100мб в базе :)
   Злопчинский
 
26 - 10.03.20 - 16:16
(24) Поддерживаю. я обычно так и делаю. когда последний раз делал - хз, уже и не помню...
.
один из крупных траблов был, когда я укатил в отпуск, только заселился, меня по тлф достают - база колом встала. ...ь! пришлось бегать искать инет, а это давно было, тогда инет проблемный был. убил кучу времени пока подключился. все оказалось тривиально, нашел быстро. бухгалтер "старой закалки". зашла в базу и удалила трехмесячной давности "неверный" возврат покупателя....
   VladZ
 
27 - 10.03.20 - 16:16
"ТЗ в реквизитах документа" - это не панацея.

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

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

И тут возникают несколько вопросов:
1. Как тебе поможет ТЗ?
2. Какая информация будет хранится в ТЗ?
3. Кто гарантирует,  что в ТЗ корректная информация?
   mishaPH
 
Модератор
28 - 10.03.20 - 16:19
(27)
странные вопросы. даже если док проверить через 2 сес. то дата файла то текущая. ставнив 2 последних тз можно понять что изменили
меняют то табличную чать. табличную часть самое простое выгрузить в ТЗ и сохранить файл

автору надо знать кто и что менял
   Злопчинский
 
29 - 10.03.20 - 16:22
(28) АВТОРУ это не надо.
стравить склад и бухов - пусть открыжат позицию как VladZ yfgbcfk - и заниматься далее своими делами.
пусть ПОТРАХАЮТСЯ так, чтобы болело все.
иначе - не дойдет.
   Aleksey
 
30 - 10.03.20 - 16:24
(6) Была реализация полгода назад. Потом пометили на удаления и месяц назад запустили удаления помеченных.
Вперед ищи свое ТЗ до посинения
 
 Рекламное место пустует
   mishaPH
 
Модератор
31 - 10.03.20 - 16:29
(30) не стоит впадать в крайности от просто идиотов. у автора задача простая.

(29) прежде чем когото в чем то ограничивать, надо доказать, что эти вот уроды..
для начала надо понять кто и где
   mishaPH
 
Модератор
32 - 10.03.20 - 16:30
да и автор не в праве решать орг вопросы кто когда и как правит доки.
   Злопчинский
 
33 - 10.03.20 - 16:34
(31) ну и пусть доказывают склад/бухия, в чьей компетенции находится ведение учета остатков.
на месте склад я бы тупо сделал - текущим числом или непосредственно перед инвентаризацией списал непонятно откуда взявшуюся разницу, чтобы итог инв. остался неизменным и все. Проблема решена.
   InfoSer
 
34 - 10.03.20 - 16:38
1) Можно в документе создать строковый реквизит с неограниченной длинной и записывать таблицу значений ЗначениеВСтроку
2) Создать справочник где будет ИД документа и реквизит с неограниченной длинной и записывать таблицу значений ЗначениеВСтроку
3) Сохранить таблицу значений во внешний файл ЗначениеВФайл
   InfoSer
 
35 - 10.03.20 - 16:42
Предложи вариант, что просто изменения отправлять на почту и не хранить все в базе. По практике знаю, что эта информация изменений никому не нужна.
   vova1122
 
36 - 10.03.20 - 17:27
Можно сделать проще (по крайней мере я так сделал в одной конфе)- разрешить править документ только автору документа, а всем остальным запретить любие действия с документом
   VladZ
 
37 - 10.03.20 - 17:29
(36) Тоже не выход: автор заболел или уволился. И к айтишнику прибегут с фразой "Красавчик, помоги!"
   vova1122
 
38 - 10.03.20 - 17:31
(37) - это уже частный случай.
   mishaPH
 
Модератор
39 - 10.03.20 - 19:30
(38) на складах такая текучка, что это перейдет в обычный случай
   Злопчинский
 
40 - 10.03.20 - 19:48
Короче! Всех - расстрелять солеными помидорами!
   brenli
 
41 - 10.03.20 - 20:34
(40) Да я всеми руками ЗА , за отрубание кривых рук, и прочие изощренные методы инквизиции, но бухи по другому не могут.
Безнал выписывают именно они и случаи разные бывают - переместили больше чем потом пришли забирать и еще куча всяких, поэтому никак не хотят отойти от такой схемы
   Злопчинский
 
42 - 10.03.20 - 20:36
(41) сделай так чтобы не могли сделать неправильно. Это делается не сильно уж трудно за исключением "нулевых" точек где все зависит от рук пользователя.
все остальное - зарубить. чтобы не могли. с бардаком - если организационно никто не борется можно бороться только так.
   mishaPH
 
Модератор
43 - 10.03.20 - 21:23
(42) это не задача прога. Это задача руководства.

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

если есть воля руководства навести порядок - он будет и без прога. Если нет - это пустая борьба и трата нервов.
А вот логи и если при разборе показат а кто - это в работе прога. И далее пусть там сами ломают труг другу головы
   Злопчинский
 
44 - 10.03.20 - 21:37
(43) согласен. но руководство разное бывает. и есть руководство которое до таких "мелочей" - не опускается. и тогда прог1С становится "бизнес-аналитиком" - определяет КАК делать.
.
да, руководство может дать "санкцию". сталкивался с таким. я поступал просто - говорил руководству - как бизнес-аналитик - так делать не надо. руковдство дожимает. нивапрос. делаем. потом наступает вреям когда приходится искать "ккто что сделал" - как выше. и я - этим на занимался. а так как никто разгрести это не мог - выставлял соответсвующий прайс. ибо ССЗБ.
.
но, если как "прог" - ну кому охота - то нехай тыкает в кнопки за пользователями. и сопли им подтирает. я тоже этим долгое время занимался. потом плюнул. оказалось - что так проще и спокойнее. если надо - пусть "платят" как подтирщику соплей вдобавок как прогу и БА. результат - оценивать можно по разному, в общем - не жалею. надо было еще раньше так поступить.
   Cthulhu
 
45 - 10.03.20 - 23:05
первый закон: бардак автоматизировать нельзя.
   Злопчинский
 
46 - 10.03.20 - 23:10
ну как-то же с ним надо бороться? или не надо?
мой мелкий опыт показывает - что руководство устраивает когда получает то что ожидает. а так как ожидания строятся из прошлого опыта (когда бардак-болото) то без принципиального изменения в принципах (чего*) вся автоматизация все равно скатывается в "болото", видимо у "лавочников" это неискоренимо. а вот как в других компаниях у коллег - хз. забюрократизирвоано? заадминистрировано? зарегламентировоно? шаг влево/вправо - расстрел?
   Сияющий в темноте
 
47 - 10.03.20 - 23:11
я при записи сраанивал с сохраненной копией и писал только изменения,предполагая,что в табличной части порядок строк не важен-получалось очень красиво.
   victuan1
 
48 - 11.03.20 - 14:28
(45) Можно, при этом получится "автоматизированный бардак". Я сто раз так делал))
   Kigo_Kigo
 
49 - 11.03.20 - 14:39
У меня стоит дата запрета редактирования Текущаядата() минус неделя(количество днейОпределяется константой)
хочешь изменить задним числом, меняй, в справочник идет запись,кто менял, когда и зачем, обоснование "зачем" обязательно для изменения датызапертаредактирования, от такот
ПыСы для каждогоПользователя датазапертаредактирования своя и изменив ее у других она не меняется
   novichok79
 
50 - 11.03.20 - 15:13
в 8ке история изменений для этого есть.
почему нельзя хранить все в отдельной табличной части в виде номера версии и предыдущих значений?
   novichok79
 
51 - 11.03.20 - 15:15
и еще как сохранить консистеность данных? это только если хранить в виде таблицы в базе это дело. опять же табличная часть подходит.
   Kigo_Kigo
 
52 - 11.03.20 - 15:26
(50) (51) Да нахер это не надо, надо боротся не со следствие а с причиной, раздувать базу- так себе занятие, ну бух изменила док, было 10 стало 20 или наоборот, и что дальше то? что вы ей скажите, что изменится то?
она скажет да меняла, а нахера? непомню, дальше что- премии ее лишите? она вас набуй пошлет и все на этом закончится, вот и все разборки, зато будуте гордо, во бух ссучка, 10 на 20 именила, я не я типа, сбейтесь, это нахер никому не надо, дату запрета выставил и все, надо изменить - кто зачем и почему и все
   novichok79
 
53 - 11.03.20 - 17:53
(52) самое логичное, конечно - это не давать базе разрастаться. тут я согласен.
   pechkin
 
54 - 11.03.20 - 17:55
(52) те ты отрицаешь нужность истории изменений?
   8 bit
 
55 - 11.03.20 - 18:00
Кхм... в камине 2.0 вторую табличную часть хранят в аналогичном документе, созданном в другом времени (10 лет вперед или 10 лет назад).
Хранить ТЗ в виде строки в реквизите - не есть хорошо, т.к. теряются ссылочная целостность при удалении объектов. В смысле, в ТЗ есть ссылка на объект. ТЗ лежит свернутое в строку. Объект пометили на удаление и потом удалили вовсе. Разворачиваем ТЗ из строки и видим - объект не найден.
   Харлампий Дымба
 
56 - 11.03.20 - 18:30
(0) Хочешь иметь историю - ну так и храни копии базы не за 2 месяца, а за всю жизнь. Закроет твою хотелку на 99%. Что у тебя там за 7ка такая неподъёмная? Даже 100 мегабайт ежедневная копия - терабайтного диска на 3 года хватит, а если только воскресные копии, то и на 20 лет. А в 2040 году купишь себе диск побольше, или удалишь старые копии, или поставишь 1С 9.9.
Возник вопрос - поднял копию за дату, когда бух говорит всё было не так. Вывел ведомости в старой базе и текущей - скинул в Excel, скопировал на один лист, формулу написал на разность суммы - увидел с какого документа пошла проблема. Открыл в обоих базах документ - увидел, что поменяли.
Если надо больше - посмотрел в текущей базе, кто этот документ записывал по журналу регистрации и когда, открыл копии после каждой записи, сравнил до и после. Увидел, кто враг.

Хочешь хранить историю документа - храни. В отдельный mxl по каждому документу записывай при записи документа контролируемые реквизиты (можно и при печати - делал так в расходной накладной для контроля воровства). Но надо помнить про встроенные и внешние  обработки - в них тоже надо прописать запись состояния документа в mxl, если они документ записывают. В документ кнопку, по которой этот mxl открывается - ответственные бухи очень радуются.
   Сияющий в темноте
 
57 - 11.03.20 - 19:16
если писать дифференциальные бэкапы,то и история будет видна и место раздуваться не будет.
   Злопчинский
 
58 - 11.03.20 - 20:33
(54) в первую очередь - это организационные проблемы и постановка работы с клиентами. я ж писал - у меня ведется история изменений уже хрен знает сколько лет. за последние два года я не помню чтобы я туда смотрел или был вопрос кто зачем изменил. Просто так выстроил процессы. и ничего, нормально.
.
дабы не править и не вводить задним числом в базе УУ/ОУ - я бы вообще все вводил только в ТА. и реквизиты дата и номер входящих доков (считаем что это соответсвует дате отражения данных в БУ). а при перекидке в БУ-базы - ставить доки именно по этим датам "как надо бухам". в ОУ/УУ я навскидку не придумаю о необходимости изменения доков задним числом. то что в ОУ/УУ меняют/вводят доки задним числом - это рудименты/хвосты принятой парадигмы - дата регистрации=дате проведения.


Список тем форума
Рекламное место пустует  Рекламное место пустует
Здесь во втором сообщении вам дадут решение, а в двадцатом дадут правильное решение. Ymryn
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.