Есть конфигурация на базе УТ 10.3. Есть некий самодельный документ. Пользователь делает в своем бизнес-процессе несколько вариантов этого документа и хочет знать, что когда кто менял.
Как лучше, быстрее, эффективнее реализовать?
1) взять из БСП версионирование
2) сделать цепочку документов, каждый следующий на основании предыдущего, и к этому какой-то отчет об изменениях
3) еще что-то?
У кого какой опыт и соображения?
Как лучше, быстрее, эффективнее реализовать?
1) взять из БСП версионирование
2) сделать цепочку документов, каждый следующий на основании предыдущего, и к этому какой-то отчет об изменениях
3) еще что-то?
У кого какой опыт и соображения?
По теме из базы знаний
- Git + 1С. Часть 1. Как подключиться к команде разработки и начать использовать Git
- Как специалист 1С может найти работу за рубежом?
- Как приручить драконов. История построения экосистемы на основе 1С
- Как Gitlab-CI и OneScript могут отсортировать массив (Часть 1)
- Как начать зарабатывать на разработке мобильных приложений уже завтра!
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) не очень понятно...
если речь идет о исправлениях документа, т.е. ошибочно ввели, потом исправили, чтобы правильно сели взаиморасчеты, или себестоимость...то это типовое версионирование, - включаем новый документ в подписку, и потом анализируем, по потребности, кто что менял.
И совсем другое дело, если этого требует бизнес процесс...тогда, мягко говоря, сам документ спроектирован неверно. Документ - как смертный приговор, доказали, создали, оформили, подписали, провели - расстреляли. Документ остался в истории.
Если там промежуточные какие то этапы, то нужно все этапы каким то образом документировать, они должны оставаться в базе, и по ним должны строится разнообразные отчеты. Тут уже перетряхивать, ваш бизнес процесс необходимо и архитектуру.
если речь идет о исправлениях документа, т.е. ошибочно ввели, потом исправили, чтобы правильно сели взаиморасчеты, или себестоимость...то это типовое версионирование, - включаем новый документ в подписку, и потом анализируем, по потребности, кто что менял.
И совсем другое дело, если этого требует бизнес процесс...тогда, мягко говоря, сам документ спроектирован неверно. Документ - как смертный приговор, доказали, создали, оформили, подписали, провели - расстреляли. Документ остался в истории.
Если там промежуточные какие то этапы, то нужно все этапы каким то образом документировать, они должны оставаться в базе, и по ним должны строится разнообразные отчеты. Тут уже перетряхивать, ваш бизнес процесс необходимо и архитектуру.
(4) это именно промежуточные этапы проектирования. Делаем предварительный проект. Сначала конструкторы нарисовали и составили список комплектующих. Потом изучили рынок, цены, конструкторы пошевелили извилинами, поменяли что-то. Поменяли предварительный проект. Потом заказчик сказал, что ему надо не синее, а зеленое в крапинку. Опять поменяли. Так может быть несколько раз до того момента, когда утвердили проект окончательно и он пошел закуперам.
Чем плох документ и архитектура, не совсем понятно. Но хотим видеть изменения.
(2), (3) с БСП опасаюсь, что требуемые ресурсы (как то время разработки, замедление работы программы) не соответствуют масштабу задачи. С другой стороны, версионирование потом можно прикрутить и к обычным документам, отслеживать, кто что менял.
Чем плох документ и архитектура, не совсем понятно. Но хотим видеть изменения.
(2), (3) с БСП опасаюсь, что требуемые ресурсы (как то время разработки, замедление работы программы) не соответствуют масштабу задачи. С другой стороны, версионирование потом можно прикрутить и к обычным документам, отслеживать, кто что менял.
(7)
как вариант,
типа корректировочного документа, как в ЗУПе, документ верхнего уровня блокируется для редактирования если есть корректировка.
Зато все по процессу и все видно.
(6)
документ, сам по себе отражает какое то событие и является учетной единицей...а вам нужно отражать и хранить много промежуточных действий - по фен шую - это много документов..а как вы там это организуете, уже процесс ваш, внутренний.
по грамотному - это (7),
более просто, это завести регистр сведений, подписку на документ при записи, и анализируем табличную часть, пишем все изменения туда.
Вытаскиваем отчетом.
самое простое - это версионирование, но нужно понимать, что это администраторский инструмент, и красиво, печатной формой, или отчетом - особо не пооперируешь
Может, сделать документ "предварительный проект", и каждое изменение делать вводом на основании предыдущего?
как вариант,
типа корректировочного документа, как в ЗУПе, документ верхнего уровня блокируется для редактирования если есть корректировка.
Зато все по процессу и все видно.
(6)
Чем плох документ и архитектура, не совсем понятно. Но хотим видеть изменения.
документ, сам по себе отражает какое то событие и является учетной единицей...а вам нужно отражать и хранить много промежуточных действий - по фен шую - это много документов..а как вы там это организуете, уже процесс ваш, внутренний.
по грамотному - это (7),
более просто, это завести регистр сведений, подписку на документ при записи, и анализируем табличную часть, пишем все изменения туда.
Вытаскиваем отчетом.
самое простое - это версионирование, но нужно понимать, что это администраторский инструмент, и красиво, печатной формой, или отчетом - особо не пооперируешь
(7) да вот я тоже думаю, что это правильнее, чем версионирование делать. Можно будет посмотреть любой промежуточный этап.
(9) ну вот и будет у меня документ отражать факт того, что кто-то что-то спроектировал. Там действительно придется аккуратно разрешения на редактирование отслеживать. Но зато все этапы будут наглядно существовать.
(9) ну вот и будет у меня документ отражать факт того, что кто-то что-то спроектировал. Там действительно придется аккуратно разрешения на редактирование отслеживать. Но зато все этапы будут наглядно существовать.
мне еще нравится, как в последней УНФ-ке сделали подсистему, обсуждения. Изменение ключевых реквизитов в документах и справочниках, регистрируются с отдельном регистре сведений, в привязкой к объекту, еще и комментировать можно и обсуждать, что и для чего было сделано. Все на пользовательском уровне.
А полное версионирование, - это ресурсоемкое, да и больше для админов, чем для обычных пользователей занятие.
А полное версионирование, - это ресурсоемкое, да и больше для админов, чем для обычных пользователей занятие.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот