Коллеги из удаленной тех. поддержки периодически косячат в рабочей базе создавая новые данные или изменяя существующие. Урона практически никакого, однако, некоторых сердобольных юзеров это изрядно напрягает и те желают господам извне запретить модификацию данных на юридическом уровне. В общем, есть ли у кого рыба, шаблон, пример такого соглашения?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
ИМХО, совсем запрещать неправильно - они тогда вообще ничего не смогут (не станут) делать, надо просто оговорить ответственность за нежелательную модификацию.
То, что вам нужно:
сердобольных юзеров это изрядно напрягает и те желают господам извне запретить модификацию данных на юридическом уровне.
А если данные модифицируются типовыми обновлениями, выпущенными 1С?
ИМХО, совсем запрещать неправильно - они тогда вообще ничего не смогут (не станут) делать, надо просто оговорить ответственность за нежелательную модификацию.
есть ли у кого рыба, шаблон, пример такого соглашения?
Да эти рыбы где только не плавают, например, тут:
То, что вам нужно:
7. ОТВЕТСТВЕННОСТЬ СТОРОН
7.1. Исполнитель гарантирует Заказчику, что в течение срока действия настоящего Договора, в случае сбоя в созданных Исполнителем настройках ПП в процессе их эксплуатации все работы по восстановлению работоспособности программы будут выполнены силами Исполнителя в согласованный с Заказчиком срок.
7.2. Исполнитель не несет ответственности за сбой в работе ПП, модифицированных Заказчиком, либо третьими лицами по заданию Заказчика. В данном случае все работы по диагностике и восстановлению работоспособности программного продукта выполняются за счет Заказчика.
7.1. Исполнитель гарантирует Заказчику, что в течение срока действия настоящего Договора, в случае сбоя в созданных Исполнителем настройках ПП в процессе их эксплуатации все работы по восстановлению работоспособности программы будут выполнены силами Исполнителя в согласованный с Заказчиком срок.
7.2. Исполнитель не несет ответственности за сбой в работе ПП, модифицированных Заказчиком, либо третьими лицами по заданию Заказчика. В данном случае все работы по диагностике и восстановлению работоспособности программного продукта выполняются за счет Заказчика.
(2)
ИМХО, совсем запрещать неправильно - они тогда вообще ничего не смогут (не станут) делать, надо просто оговорить ответственность за нежелательную модификацию.
Да, вы правы - они могут и должны менять данные всяческих сервисных объектов. И конечно они обновляют базу. Увы, разговоры не принесли должного результата.
Тут речь не совсем о техническом сбое и настройках. Приведу пример - изменение в бухгалтерских данных закрытых периодов. Да что там, пусть даже в текущем периоде - все равно это может создать некоторый напряг. Или создание нескольких тестовых номенклатурных позиций, которые укажут операторы в своих рабочих документах. Операторы не имеют знаний о том какой из элементов должен находится в базе, а который нет. Такие вещи не очевидны и могут принести проблемы в будущем. Можно еще кучу подобных ситуаций выдумать.
ИМХО, совсем запрещать неправильно - они тогда вообще ничего не смогут (не станут) делать, надо просто оговорить ответственность за нежелательную модификацию.
Да, вы правы - они могут и должны менять данные всяческих сервисных объектов. И конечно они обновляют базу. Увы, разговоры не принесли должного результата.
Тут речь не совсем о техническом сбое и настройках. Приведу пример - изменение в бухгалтерских данных закрытых периодов. Да что там, пусть даже в текущем периоде - все равно это может создать некоторый напряг. Или создание нескольких тестовых номенклатурных позиций, которые укажут операторы в своих рабочих документах. Операторы не имеют знаний о том какой из элементов должен находится в базе, а который нет. Такие вещи не очевидны и могут принести проблемы в будущем. Можно еще кучу подобных ситуаций выдумать.
(3)
И это вовсе не единичный случай, сам лично в этом году столкнулся с такой же ситуацией - организация в 2017 году перешла с БП 2.0 на отраслевую конфигурацию (на базе БП 3.0), так в отчет СЗВ-СТАЖ из 400 сотрудников 140 выгрузились без записей стажа.
Такой отчет невозможно сдать, какого бухгалтера это устроит?
А для исправления штатными методами требуется перепроведение документов прошлых лет, либо колдовать над самопальной обработкой, которая заполнит нужный регистр нужными данными. Что, как вы понимаете, обойдется дороже и при этом не гарантирует правильных результатов.
Какой способ вам кажется более приемлемым?
Да вот и пример
Приведу пример - изменение в бухгалтерских данных закрытых периодов.
Я вам тоже приведу пример:
И это вовсе не единичный случай, сам лично в этом году столкнулся с такой же ситуацией - организация в 2017 году перешла с БП 2.0 на отраслевую конфигурацию (на базе БП 3.0), так в отчет СЗВ-СТАЖ из 400 сотрудников 140 выгрузились без записей стажа.
Такой отчет невозможно сдать, какого бухгалтера это устроит?
А для исправления штатными методами требуется перепроведение документов прошлых лет, либо колдовать над самопальной обработкой, которая заполнит нужный регистр нужными данными. Что, как вы понимаете, обойдется дороже и при этом не гарантирует правильных результатов.
Какой способ вам кажется более приемлемым?
Да вот и пример
(1) Добрый день. Я бы лучше у юристов заказал данный договор. Т.к. это все - таки юридически обязывающий документ, и он должен быть оформлен правильно и корректно с юридической точки зрения с учетом особенностей Вашей организации и организации Вашей техподдержки. А так если с рыбки сделать - то там куча будет дыр.
(5) Ну вот в этом уже Вам никакие "рыбы" с интернета и юристы не помогут. Нужно Вас самим определить круг тех данных которые могут менять, а какие нет. Обычно делают так - в закрытом периоде - ничего менять нельзя + нельзя добавлять данные и изменять данные ИНТЕРАКТИВНО (т.е. руками) и программно исключая типовые изменения от фирмы - поставщика конфигурации. Т.е. 1С или кто там является разработчиком Вашей конфигурации. В случае вопросов - можно посмотреть что меняется при обновлении конфигурации - вот это и разрешено изменять. Остальное - нет - только с ведома ответственного с Вашей стороны.
(6) предлагаете перечислить все объекты нетиповой УПП и определить уровень доступа к ним со стороны тех. поддержки? Есть ведь проблема еще и в том, что состав объектов УПП, а так же уровень доступа может меняться в зависимости от выполняемой Исполнителем задачи. Я рассчитывал получить емко и точно, а главное грамотно юридически сформулированное предложение, примерно похожее на пункт 7.1 из 2 сообщения.
(7) Нет, я предлагаю абстрагироваться от объектов конфигурации, и перейти к ситуационному описанию. Т.е. если - то. Иначе без конкретики - Вы ничего никому не докажете. Всегда есть простой уход - "так требовалось для нашей работы". А в пункте 7.1 второго поста - там это уже реакция на само изменение, а не запрет изменения. Вам же нужно юридически запретить именно ИЗМЕНЯТЬ, а не ЧТО делать, если УЖЕ изменили? - так?
(9) Интересно будет посмотреть на текст - что Вы понимаете под недостоверной информацией? - позвонил в службу тех поддержки Ваш бухгалтер - у него не закрывается 25 счет. Оператор тех поддержки указал, что в одном документе указана номенклатурная группа по которой не было выпуска. Рекомендовано сменить номенклатурную группу. В результате затратная часть увеличилась на другой номенклатурной группе, что не устроили главного бухгалтера. Вопрос - это как характеризовать? - ошибочная информация или нет?
(9) И натыкаться Вы будете сплошь и рядом на такие моменты. Тут или есть делегирование полномочий Вашей службе поддержки или просто все сами делаете, а они только обновлениями занимаются. Так что тут не знаю как Вы сможете ограничить их. Эта их работа все таки. Умышленная порча информации - это да - но тоже как это доказать?
(9) Я бы просто протоколирование всех действий с запросом на изменение ввел. Чтобы Ваши операторы прежде чем давать задачу службе тех. поддержке сначала фиксировали ее в программе hepl-desc - и уже работа шла со всеми записями в нее чтобы потом можно было понять кто и что.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот