УТ11 последних релизов, хочу в типовой регистр сведений "Цены номенклатуры" добавить измерение, тип булево.
Чем может грозить? Не порушатся ли типовые механизмы конфигурации?

Обязательно порушится. По законам Паркинсона.

(1) Конкретных идей нет? На мой взгляд ничего не должно слететь. Что там интересного связано с этим регистром? Подстановка цен в документы и обработка Прайс-лист. Вроде всё?

(0) Т.к. булево может принимать два значения - "Истина" или "Ложь", то это грозит "задвоением" записей по каждому набору ключевых измерений.
То есть, например, для одной номенклатуры и одному типу цен может появиться две записи - со значением твоего измерения "Истина" и со значением твоего измерения "Ложь".
Если это нормально и ты намеренно ожидаешь такого поведения от системы, то всё нормально.
Ожидает ли типовая конфигурация такого варианта развития событий (наличия двух записей по одному ключу) - надо анализировать и думать.

(3) Естественно я ожидаю такого поведения системы, поскольку именно для этого и добавляю измерение.
Вопрос в том, может ли кто-то навскидку сказать (может он это уже раньше проанализировал и обдумал), как отнесется типовая конфигурация к такому развитию событий?
Пока вы анализируете развитие событий, я проверил пару мест: документ установки цен и заказ клиента, там система отнеслась благосклонно к такому развитию событий.

А чего хотите добиться?

(4) При наличии двух записей по одному старом ключу все обращения к этому РС будут вести себя непредсказуемо.

(5) Концепция поменялась. Не хочу добавлять измерение, хочу реквизит. Хочу добиться того, чтобы при срезе последних, было видно, руками изменялась цена или обработкой.

(7) Тьфу, не реквизит, а ресурс в регистр

Не лучше ли сделать условный допреквизит "проведен вручную" у документа "установка цен"?

(9) А потом захотят видеть какие именно строчки в установке цен поменяли вручную)

(10) вот именно

(8) Может версионирование какое-нибудь "прикрутите"

(7) Для этой разовой задачи вполне достаточно ЖР.

(12) Нет, нужно знать, цена изменялась вручную или обработкой, причем построчно для каждой номенклатуры, а не для всего документа установки цен

(13) Задача не разовая, часть механизма ценообразования

добавляй ресурс

(7) >>Хочу добиться того, чтобы при срезе последних, было видно, руками изменялась цена или обработкой.
И зачем для этого трогать РС? Типовой РС "ЦеныНоменклатуры" подчинен регистратору... вот и определяй по нему кто что установил.

(17) да можно и так, только придется внутреннее соединение с таблицей регистратора делать

(0) бывают запросы вида "срез последних на разные даты". И вот тут-то твоё измерение выйдет боком

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

но зачем измерение? достаточно реквизита

Вообще, не знаю какие сейчас тенденции в УТ, но в ЗУП сейчас практически все реквизиты в документе переводятся в состояние "сохраняемых", т.е. при открытии существующего или заполнении нового запоминается состояние реквизитов и при изменении они все помечаются жирным. Может стоит подождать и в УТ такая же фишка появится?

(10) С телепатией под вечер беда. Но, думаю, еще чуть-чуть, и мы поймем, что ТС хочет увидеть в случае, когда пользователь с правами на установку цен 1) установит цены обработкой 2) поменяет часть цен вручную 3) продаст что-нибудь 4) установит цены обработкой на исходную позицию.

(18) оно и так есть неявно: Регистратор.ДобавленоОбработкой

(23) Обработка установки цен работает каждую ночь автоматически. Если в регистре цен взведен флаг ручного изменения цен, эти цены не обрабатываются. Вот и всё. Продаст или не продаст кто-то там что-то, вообще никого не волнует.

(25) Уточню: цены вручную никто никогда не заводит?

(25) а, понял

(25) А если запретить менять цены в документе, созданным обработкой? Хотят ставить цены вручную- пусть и ставят отдельно, а не лезут в готовый документ.

(28) Да вроде никто и не собирается менять цены в документе, созданном обработкой. Проблема в самой обработке, она как-то должна понимать, трогать ей цены или держаться от этой номенклатуры подальше, поскольку там горит флажок "Не трогай! Эту цены поменяли руками не просто так! Пропусти эту цену!!!"

(29) если никто не собирается менять цены в документе, созданном обработкой, значит ли это, что они создают отдельный документ и на уровне табличной части документа можно ничего не рассматривать?
Так мы и до (9) дойдем.

(30) хм.. н-да.. Да не зацикливайся ты на документах. Есть срез последних, не важно какие регистраторы у этого среза. Просто срез. По номенклатуре, цене и этому флагу. Теперь нужно эти цены обработать по некоторому алгоритму, алгоритм должен принимать во внимание этот флаг. Вот и всё.

(31) не важно какие регистраторы у этого среза
а какие есть регистраторы у этого среза? :)

Ладно, не смотря на все сообщения в теме, мы всё ещё друг друга не понимаем, и это хорошо для бизнеса.

(32) у регистратора есть табличная часть. Часть строк может иметь флаг "Введено вручную", а часть - нет. Поэтому ссылка на шапку регистратора - не прокатит. Нужно делать внутреннее соединение с табличной частью регистратора, а чем я и написал в (18). Но мне проще добавить ресурс в регистр. Элементарно всё, Ватсон.

(34) если для ручного изменения ТОЛЬКО создавать новый документ, а не редактировать существующий, можно и реквизитом шапки обойтись
только дату ручного документа ставить позже автоматического

(35) В моей системе пользователь может руками создать документ, у которого часть строк будут автоматическими, а часть ручными. Как тебе такое, Илон Маск?