Здравствуйте. Подскажите, пожалуйста, можно ли заблокировать для редактирования поле Наименование в Договоре контрагента в БП 2.0(типовая, проф) не открывая Конфигурацию? Внешней обработкой.
То есть пользователь создает новый договор, заполняет форму, сохраняет. После этого поле Наименование становится не доступным для редактирования.
Это связанно с особенностями обмена данными с управленческой программой.

нет

а если подумать? внешняя обработка, которая запускается в момент, когда пользователь открывает договор и блокирует Наименование

неужели невозможно?

(2) это называется не думать, а фантазировать

(0) нет
(2) нет
(3) невозможно

(2)самое простое это подписка на событие При записи договора, проверять изменилось ли название, если изменилось посылать пользователя, обновлятся можно без проблем

(6) руки скручены: конфигуратор недоступен

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

(7) или скрЮчены )

(6) "подписка на событие" - это сложная обработка? В принципе, этот вариант тоже подойдет. Пусть хотя бы предупреждение пользователю будет.

(10) подписка тоже в конфигураторе находится )

ученица - двоечница?

надо взять себя в руки, сформулировать цель и понять, что в (0) находится ересь

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

(0)Без доступа к конфигуратору базы? Элементарно:)
(14) не кошерно
Обработка, которая открывает все существующие договора в своем сеансе и регулярно их перезаписывает. Пользователь открывает существующий договор, пытается что-то изменить - а ему хрен "Был изменен другим пользователем".

пофантазируем вместе: делаем константу "Редактирование ключей обмена", такую же функциональную опцию и раскидывам ее по реквизитам объектов конфы...

(14) интерфейс тоже внешней обработкой убирать?

а через Задачи можно? у нас есть в ЗУП внешняя обработка, которая через Задачи предупреждает кадровика за месяц об отпуске сотрудника
только для этого кадровик входит через отдельный запуск и какой-то файл надо было положить в BIN

(16) когда-то делал через РС.

ТипОбъекта \ ИмяРеквизита.

Все что в регистре для данного типа объекта - не доступно к изменению. Лучшего не придумал, чтобы настраивать без обновлений конфы. Но один раз поменять надо:)

(15) "Поле Наименование недоступно для редактирования"
все остальные реквизиты должны быть доступны. а ты блокируешь весь объект.
идея интересная, но здесь не пройдет

(18) ждём вопроса о ком-соединении

я тут подумала, что можно и полностью заблокировать договор,
это как-то упростит задачу? для такого задания можно что-то придумать?

(0) >Это связанно с особенностями обмена данными с управленческой программой.

Переделать способ синхронизации по уникальному идентификатору.

По-хорошему, надо РЛС ставить на реквизит

(23) так нельзя!!11
молодой человек, прекратите умничать, вы подрываете работу государственного учреждения!

(22) Вопрос. Если пользователь фигню в наименовании забил, или ещё где, тогда как быть?

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

(23) управленческая программа написана на БП 3.0, а бухгалтерия ведется в 2.0
программист сказал, что по ID не может синхронизировать

"программист сказал, что по ID не может синхронизировать"


))))))))))))))))))))))))))))

и послал ученицу на форум искать велосипед?

с этого и надо было начинать

(26) так вторая часть задания будет такая:
возможность менять договор для пользователя с правами Администратора

(28) гоните его в шею

программист сказал - реквизит Номенклатура в ТЧ Товары это строка - значит, строка!

(32) можешь уже сказать задачу. а не свои домыслы на тему

ой, простите, программист не виноват, это я забыла, что синхронизировать по ID нельзя, потому что Управленческая база одна, а БП предполагается несколько.

и по коду поэтому нельзя

остается только Наименование

(36) И что это меняет? У вас договора в разных БП повторяются?

ну да, наименование ведь более уникальное, чем ID.. эхх..

даже код не столь уникален, чем наименование.. эхх.. 10 лет профессиональной работы коту под хвост..

(38) не заявзывайтесь при синхронизации на строковые поля, которые могут задаваться от балды. Где у веренность, что люди в разных базах не назовут одинаково.
Можно придумать поле синхронизации. например Префикс юр лица + код в базе. Достаточно уникально будет.

Я так понимаю, вы хотите избежать дублирования договоров при заливке в упр. базу. Чтобы одинаковые договора сливались из разных БП в один в упр. базе. Так?

да

(44) А чем вас не устраивает номер и дата договора.
И как вы синхронизировали контрагентов?

(43) (44) Эмм. А откуда в разных базах одинаковые договора. У них один владелец\организация? В разных базах ведется учет по одним и тем же организациям?

ой, то есть нет, в разных базах разные договора, а вот если пользователь поменяет наименование, то в Управленке дублируется

с контрагентами проще, там есть ИНН и КПП

(47) Ещё раз, гоните программиста в шею. ID более чем достаточно.

разные базы - это разные организации, но так как холдинг один, то Управленка должна объединить данные разных БП
Контрагентын могут повторяться, а договора никогда

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

а третья бухия не умеет с разными организациями да с РИБом работать?

(47) Управленке очень важен разрез договоров? Может попросить "заказчика" определить список кретичных реквизитов для договора и искать по ним. Т.е. разные договора с одинаковым набором критичных реквизитов будут считаться для управленки одним.

Если в каждой базе есть свои - то достаточно сделать полями поиска Владельца, Организацию, Номер и Дату.
И бить по рукам пользователей, которые заводят догвора с пустыми датами и номером.

(50) а кто у вас программист на проекте?:)

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

Контрагенты значит по ИД, а договора по наименованию... весело
что будет, когда в цент базу загружаются договора с двух баз, но с одинаковым названием? при этом от разных контрагентов

(55) наведите ПОРЯДОК В БАЗАХ!!!

(54)
муж кричит в окно роддома:
- на кого похож сын?
жена:
- а какая разница, ты всё равно его не знаешь.
)))))

всем спасибо большое за помощь
вы правы, надо обмен переделывать, а не договор блокировать

(58) я имел ввиду - человек он хороший?=)

как-то не последовательно все. Мы перед внедрением УУ квартал вылизывали контрагентов по базам, создали единую точку ввода контрагентов для всех баз и т.д. и т.п. И то не все гладко, но вполне терпимо. Только потом стали интегрироваться с базой УУ. Для договоров приняли упрощение(как-раз по значимым реквизитам).

А тут так прям с наскоку=) и контрагентов синхронизировать и управленку внедрить. Или у вас маленький объем данных?

программист у нас хороший человек
но без опыта внедрения и УФ изучает по ходу работы
он уже год синхронизирует и никак не синхронизирует
наверно очень трудно сделать обмен на ОЛЕ платежек между БП3.0 и БП 2.0

эхх..

наймите уже нормального специалиста

(61) А возьмите меня, я вам 2 года делать буду ...

(64) Сделаю за полтора. Опыт есть.
ЗП от 10к в валюте упр учета.

сделаю за 5тр

заманчивое предложение))))

интим не предлагать

Холодильник, а что скажете по этому:

"По одной простой причине, по ID можно перенести что-то только через XML-файл, в любом другом случае это поле у 1С не доступно для записи. "

гоните

(61) человек может и хороший, но специалист, походу, вообще никакой.

(69) XML-файл служит только как файл хранения информации, ту же информацию можно извернувшись запихнуть в дбф, текстовый, эксель-файл, документы в базе сопоставляются  в т.ч и по ID и создаются с помощью встроенного языка 1С, никакие другие методы и языки не используются, из файлов просто перед этим забирается нужная инфа, опять же встроенным языком

(69) ок, если у вас разные ID и вы хотите сливать данные в один договор - то синхронизируйтесь не без него. Но не по наименоваванию! Добавьте отдельный реквизит КодСинхронизации, например. и он будет недоступен для пользователя. его даже на форму можно не выводить.

Лучше - по коду. синхронизируйте коды во всех базах.

И еще есть вариант - по РС СоответствиеОбъектовОбмена.
Там указывается объект(ЗначениеВСтрокуВнутр) в другой базе и объект соответствие ему в вашей. эта связка автоматически работает при синхронизации через план обмена.
Надеюсь, обмен у вас через план обмена?

(73) Конфу изменять нельзя ) Впрочем можно свойство добавить

(74) Свойство не вариант. искать его по имени или коду?
лучше уж тогда договора по коду искать. Но с условием, что  договора в базах сходятся как 1х1х1

Вот думаю, как бы ему мягко сказать, что можно по ID сделать синхронизацию.
Может кто-нибудь ссылку даст на какую-нибудь статью на эту тему. Я тогда просто дам ему ссылку.

(76) по ИД необязательно. Главное - не по наименованию.

по поводу контрагентов и договоров
если честно, я немного запуталась(((
Предположим есть ООО"Один". Оно заключает договор №1 с Контрагентом "1". Мы это перегрузили в Управленку. Всё ок. Далее начинается стройка 2 и появляется ООО "Два". Оно тоже заключает с Контрагентом "1" договор, который будет 100% не № 1, потому что в ИХ учете № 1 уже прошёл и значит договор будет под любым другим номером, например № 2.
Теперь надо в Управленку перенести данные по ООО"Два". У контрагента нет привязки к Организации, поэтому обработка обмена должна найти Контрагента по ИНН+КПП и добавить к нему договор № 2 по ООО "Два".  А у договора уже есть параметр Организация. Значит путаницы не будет, если делать синхронизацию по Организация + Наименование. Правильно?

(78) путаницы не будет, если в Управленке у вас будут организации
ООО "Управленка"
ООО "Один"
ООО "Два"

а зачем ООО "Управленка" ?