Обсуждение к заданию: Доработка в документах 1С8.2 УТ10.3

• • #1
  • 20.01.2016 17:28
  0
  Поздняков Сергей

  Приватное сообщение
  Для каждого документа в 1С8.2, нужно сделать журнал регистрации любых изменений в документе. Расположить его нужно во вкладке "Действия" - так и назвать "Журнал изменений" До...  Подробнее>>
• • #2
  • 20.01.2016 17:28
  0
  Смирнов Павел Валерьевич

  Приватное сообщение
  Не боитесь, что база ой-ой как разбухнет?
• • #3
  • 20.01.2016 17:28
  0
  Смирнов Павел Валерьевич

  Приватное сообщение
  А много документов в Базе?
• • #4
  • 20.01.2016 17:30
  0
  Смирнов Павел Валерьевич

  Приватное сообщение
  Да и зависания будут. Это ж надо будет например при каждом клике на поле там, на кнопку нажатие писать куда-то действие. Например в Рег.Сведений.
• • #5
  • 20.01.2016 17:32
  0
  Поздняков Сергей

  Приватное сообщение
  база и так уже распухшая.
  Документы все связанные с торговлей - пока в среднем до 1000 каждого вида в год.
• • #6
  • 20.01.2016 17:48
  0
  Алексей

  Приватное сообщение
  http://infostart.ru/public/22167/
• • #7
  • 20.01.2016 17:48
  0
  Вадим

  Приватное сообщение
  ну писать изменения можно по факту сохранения документа. Но все равно жестко ).
• • #8
  • 20.01.2016 17:48
  0
  Константин Витальевич

  Приватное сообщение
  Коллеги правы. Если база и так уже распухшая, то окончательно умрет, даже в клиент-серверном варианте. Просто есть уже готовые решения. Например, мне вот нравится такое: http://infostart.ru/public/172052/. При желании можно найти и дешевле. Просто в плане рентабельности это пожалуй будет гораздо выгоднее, чем оплата доработки конфы (нетривиальной кстати, и обойдется не меньше) + увеличение вычислительных мощностей, чтоб база под 8.2 продолжала хоть как-то жить.
  
  #НеРеклама
• • #9
  • 20.01.2016 18:05
  0
  Артур

  Приватное сообщение
  "открыл..., провел..." зачем?
  оптимально отслеживать только изменения объектов
• • #10
  • 20.01.2016 18:07
  0
  Артур

  Приватное сообщение
  встречал базу УТ11 с включенным версионированием объектов, РС где хранились версии объектов занимал 1/3 базы
• • #11
  • 20.01.2016 18:10
  0
  Поздняков Сергей

  Приватное сообщение
  Да, наверное фиксация всего это будет жестко!
  Достаточно будет фиксации последующих внесенных изменений.
• • #12
  • 21.01.2016 10:55
  0
  Владимир

  Приватное сообщение
  А чем не устраивает журнал регистрации? там как раз ест ь: зашел, чтение, запись. А еще есть версивирование. правда - это в УПП, у УТ10 - не знаю, но вполне очень хорошая штука, за одним исключением - если по всем документам, то слишком база будет пухнуть и потом фиг удалите документ пока не вычистите его из регистра версий объектов.
• • #13
  • 21.01.2016 15:09
  0
  Константин Витальевич

  Приватное сообщение
  ЖР не устраивает по причине "Если вносились изменения - фиксировать какие изменения вносились", как указал автор. Потому и предложил свой вариант ниже.
• • #14
  • 22.01.2016 09:02
  • Отредактировано: 22.01.2016 09:03:44
  0
  AIFrame

  Приватное сообщение
  Как и ЖР, эти вещи можно писать в лог-файл. Создавать на каждый документ свой .txt и писать в него все изменения при сохранении. База от этого не разбухнет, нагрузка только в доп.таблице со списком изменений после открытия и до закрытия, которая потом обходится и построчно переносится в .тхт (тем же echo>>).
  Делать муторно-геморно, но не очень сложно.
  
  З.Ы. Деревянные решения самые надежные ;3
• • #15
  • 22.01.2016 20:40
  0
  Пастушенко Алексей Владимирович

  Приватное сообщение
  База не разбухнет, но разбухнет в другом месте.... представь себе грпповое изменение документов - да по нескольку раз! текстовый файл просто лопнет. а если писать только изменения - тогда заколебешся этот фаил/базу дергать, чтобы найти объект.. а если не дергать, как понять чего там поменялось? вручную найти предшествующее состояние?
  Имхо самый нормальный путь - подписка на событие при сохранении, и отправка данных объекта во внешний sql, который сам найдет предыдущее состояние и сопоставит его ИМХО - так быстрее и надежнее, и в лог просто так не залезть, с целью поправить, и данные в случае чего можно восстановить автоматически - но это уже отдельная работа
  
  Решение должно быть не деревянным, а железным!