В статье на "Итланде" встретил такое понятие как "регистры Правил" и это касалось 1С 7.7, может кто подскажет ..что это такое?
Может новинка в 25 релизе ?

Не уж то не кто не знает ..!?

Дай ссылку почитать

http://itland.ru/lib/index.php?id=341

О, это тема! Давно такое хотел замутить, вот есть что почитать теперь.

Так это что объект методанных..!?

В 7.7 - нет, не слышал что-то. Хочу делать на обычных справочниках

А почитать не судьба? Регистр правил - это понятие введенное авторами. Он реализуется на обычном регистре.

(7) - В 7.7 на регистрах?

(8) А что, а 7.7 нету регистров?

(9) - Регистры в 7.7? Счас, надо поискать, не видел че-то я их там никогда :-)

в v8 реализуется на регистре сведений.

11 Про 8.0 все понятно ..Регистр сведений озднозначно ..
а вот в 7.7 только на справочниках и хитроумного кода помоему так!

(10) Ну поищи

(0) спрашивает про 7.7, а не 8. В 7.7 то, что написано в (3), на регистрах реализовать, конечно, можно, но бессмысленно, по-моему, в большинстве случаев, поскольку придется еще и документ для установки прав лабать. А на справочниках все просто и удобно, как и сделано, опять же, в (3). Просмотрите ее, пожалуйста, все, кто тут чего-то пишет. Тема интересная, может, кто что подскажет по реализации такой вещи?

(0) Основная идея статьи управление выполнением программы на основании данных.
(12) Регистр сведений легко делается и в v7.
смотри http://www.mista.ru/articles1c/hare/article.76.html<br>(14)Регистр лучше чем справочник. Отменил проедение документа и нет правила

(15) - Я это же поставил как недостаток. Можно документами изменять и периодические реквизиты справочников, для чего тут регистр тогда?

Имхо, справочник и только, поскольку будет работать вне зависимости от установленных компонент.

(17) - Точно говоришь, как это я мог такое забыть? Проклятый склероз :-)

(14) - что имеено интересует в реализации? все уже давно реализованно (демку можно скачать с сайта фирмы КИНТ) в вообще несложно создать отдельную конфигурацию "ресгитры правил" которая будет прикручивается к любой конфе мин за 30 мин.
(15) - Регистр лучше чем справочник, но хуже чем документ (по том простой причине что он не нужен впринципе)

(16) Читай статью из 15. Регистры сведений гораздо лучше чем переодич.
реквизиты справочников ( ИМНО) как по логическому представлению так и
физической реализацией и в dbf и sql.
На регистрах сведений элементарно строятся регистры правил.

(20) - речь идет о 7.7. Откуда там регистры сведений?

Хорошая статья. Полгода как у меня такая вещь работает.
Сделана на справочнике + 50 строк кода в глобальном модуле (для одного "регистра правил")

(19) Основная идея регистра (и в том числе и регистра правил)
Это Отношение ( функция ) на множестве документов ( видах документов) (
множестве проведенных документов).

(21) читай ссылку из 15
Статья называется "Регистры сведений на v7"

Регистр сведений как объект метаданных отсутствует в 7.7. Я говорил именно об этом, а вот с чем ты не согласен, я так и не понял.

(23) - Если речь идет о регистрах накопления (v7 нет регистров сведений), то у данных регистров ресурс может быть только числом а у регистра правил рерус может быть любой так что в v7 регистры накопления для реализации регистров правил отпадают. В документе же все реализовать гораздо проще и лучше чем на справочнике т.к. в документе есть табличная часть которая почти идеально подходит для реализации РП.

Реализация на справочнике:
1. Длина кода = 0
2. Длина наименования = 0
3. Реквизит Идентификатор, строка, сортировка // идентификатор записи
4.5.6... Реквизит <Измерение>, любой тип, доступный отбору (необязательно)
Ключевой вопрос - формирование уникального идентификатора записи, для измерений конкретного типа справочника, документа, и др. ссылок это строка, полученная путем сложения шестисимвольных идентификаторов измерений, полученных из внутреннего значения и сжатых в 36-ти значное представление _SrtToID(). Дли количества таких измерений не более четырех можно в качестве идентификатора использовать код справочника.
Таким образом реализуется быстрый доступ к записи по набору измерений, а также контроль уникальности записи в регистре-справочнике.
В общем случае при использовании любых типов данных строится универсальная функция ВнутрИдентификтор(Значение, Тип, Длина, Точность), а длина реквизита Идентификатор подбирается с учетом длины представлений значений этих типов.
Недостатки: длинные строки не поддаются реализации,
Достоинства: логика, скорость, ресурсы любого типа, периодические измерения не требуют дополнителього кода.

(25) Да я со всем согласен. Мысль регистр сведений из v8 легко реализуется
на платформе v7 c помощью регистров накоплений v7 ( или регистров оборотов).
(26)
Постулат (определение) :
регистрах накопления (v7) без измерений и ресурсов
только с реквизитами - это регистр сведений на v7.
( Реквизит регистра накопления может быть любым объектом v7)

(27) сори.. в последней строке - "периодические ресурсы"

А что за демка на КИНТе? Я слил, но там ДЛЛ-ка, хотел не парить голову и содрать код, теперь вот придется парить, все-таки..

(28) Теория с практикой порой расходятся :) Попробуйтереализовать РП на справочниках, документах и регистрах и сами увидите что лучше.

Вопрос ко всем: для какой цели используете регистры правил?
(Можно просто перечислить назначение и общее количество регистров).

(30) dll которая там есть к РП отношения ни какого не имеет.

(31) Я привел реализацию регистра сведений, регистр правил это немного другое понятие. Но в общем не спорю, поскольку на регистрах и документах не делал.

(32) Почитайте
часть1: itland.ru/lib/index.php?id=48
часть2: itland.ru/lib/index.php?id=247

(28)
> Постулат (определение) :
> регистрах накопления (v7) без измерений и ресурсов
> только с реквизитами - это регистр сведений на v7.
А как таки быть с уникальность набора измерений и ручным изменением регистра?

(31) У меня давно работает логика регистров правил на регистре сведений в v7.
Кратко постановка задачи ( попробуйте свои подходы)
Есть поставщики, склады, товары ( могут быть и группы товаров одна цена на всю группу товаров).
Для некоторых таких троек мы задаем спец цены . Цены естественно меняются
во времени. Этот регистр вычисляется при проведении определенных
документов - разных типов документов. Если отменим проведение документа то
регистр пропадет. проведем сново появиться. Минус Ваших решений придеться
писать свой аналог включить выключить правило. Я же не говорю что нельзя реализовать но на мой взгляд сложнее. Опять же все зависит от задачи.
(ИНМО) - на v7 Регистры Правил лучше всего реализовывать с помощью
регистра накоплений содержащий только реквизиты ( такой регистр я называю регистром сведений v7 - он очень близок к регистру сведений v8).

(35)
Я читал
http://www.itland.ru/lib/index.php?id=48<br>http://www.itland.ru/lib/index.php?id=247<br> ;и еще вот это:
http://www.itland.ru/lib/index.php?id=341<br>Меня интересует для чего ПРАКТИЧЕСКИ применяется эта технология.

(37) - меня смущает одно - методы получения итогов из регистров и справочников. Мне не нужно динамически менять правила, их нужно записать один раз и применять для документов, вот и все, что треба, как видите, все просто

(31) включить выключить правило - для справочника действует УстановитьРеквизитСправочника() в применении к периодическому ресурсу, хотя проблема лишней записи остается. Но здесь мы с вами смешали в кучу вышеназваннон достоинство периодического реквизита v7 и понятие регистра сведений. Разве в v8 проведение документа поддерживает откат изменений РС? Интересуюсь искренне, поскольку практики в v8 не имею.

(40) читать в заголовке не 31 а 37

(40) Я не против периодического реквизита v7 ( для простых отношений)но посмотрите как периодич. реквизиты реализованы на уровне базы данных в v7 -все в одной неуправляемой таблице.
Опять сложное отношение (см 37) уже не сделаешь на переодич элементах
справочника v7.

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

(38) Вообщето в статьях были примеры для чего применяются РП. Возможно надо прочитать еще раз...

(44)
А вот язвить не надо!
Сам ты для чего используешь сабж?

(45) Вообщето я не язвил а говорил вполне серьезно (в каждой статье есть пример использования).
Вот только несколько применений
1.Права доступа
2.Установка значений реквизитов документов (Типов цен, скидок и т.д.)

(43) Для контроля уникальности набора реквизитов есть чУдная процедура (в таблице значений) - свертка.

(46)
Ну возьмем, хотя бы, права доступа. Для своей базы я с ходу могу придумать штук 30 различных наборов детерминатов и еще неизвестно сколько появится по ходу работы. Т.е. в базу надо будет добавить 30 справочников. Вот я о чем.

(48) Разумеется нет.
Существует 3 вида РП
1.Служебный (детерминанты и корни нам известны)
2.Системный (детерминанты и корни нам известны, но сам РП строится на таблице mlx так данные в нем не аргегатного типа, например РП склонения слов)
3.Произвольный (детерминанты и корни нам НЕ известны)
так вот для описанной выше задачи используется произвольный РП - он один, вне зависимости сколько измерений и ресурсов вы придумаете.

to Палыч:
Преимущества технологии "Регистров правил" становятся наиболее очевидны в тиражных продуктах. В "доработанных под клиента" конфигурациях логику можно (опять же до определенного момента) прописывать в коде. Тиражный продукт должен удовлетворять множеству различных требований (правил) клиентов, причем непротиворечивым образом.
Поскольку конфигурация "Учет. Анализ. Управление" (КИНТ) одна и та же для всех клиентов, то естественно, что регистры правил в ней широко используются.
Один из примеров (практических!). Выбор типовой операции в документе (какие движения и проводки должен сделать документ). В текущем релизе УАУ детерминант РП "Установка ТОП" состоит из 12(!) измерений. Не поленюсь перечислить (без расшифровки семантики): Приоритет, Направление, Вид документа, Товар, Категория товара, ОС, Фирма, Контрагент, Подразделение, Бизнес-цикл, Категория клиента, Префикс УРБД. Данный набор определяет контекст, от значения которого зависит выбор операции в документе. Не существует альтернативы регистрам правил для решения подобных задач (а их множество, если оглядеться повнимательнее) в общем виде.

(47) Боюсь, что вы не поняли.
Регистр сведений суть функциональная зависимость от нескольких аргументов, и значение каждого ресурса определено однозначно.
А вот при использовании движений регистра v7 два документа могут установить два значения одного и того же ресурса.
Вот я и спрашиваю сторонников регистров: как вы решаете эту проблему?

(51) Я вообще не сторонник ни регистров, ни справочников, ни документов :).
В (47) я лишь намекнул на то, что в принципе любой из этих объектов можно выгрузить в ТЗ и проконтролировать уникальность детерминанта через операцию свертки.

(49,50)
Ага!
Но как обобщить детерминанты из различных областей логики программы: скажем, от склонения фамилий и выбора печатной формы документа до разграничения прав на выдачу наличности из кассы и товаров со склада?
90% элементов детерминантов - не пересекаются!
зы: я имею ввиду не тиражное решение

(51) До конца не понимаю зачем нужна одназначность.
Если есть в измерении время то это не совсем наверное правильно.
Если нет времени то тогда действительно регистры сведений нужно реализовывать в v7 на справочниках.
Но даже приведенные в этой ветке примеры ( Права доступа,
Установка значений реквизитов документов ) зависят от времени.
Для меня понятие в понятии Регистр явно или неявно связано со временем.
В Ваших задачах наверное по другому, поэтому мы вкладываем разный смысл в одинаковые термины.

(53) В третьей статье из итланда, на которую вы мне указали, по картинкам:)можно полагать, что все регистры правил реализованы автором одним справочником плюс служебными подчиненными.

(53) А для чего надо обобщать детерминанты? Они не пересекаются и... правильно делают. Каждый РП имеет свой (уникальный) детерминант.
Или я не понял вопроса?

(51) В том то и дело, что по определению не может быть в регистре сведений две записи с одинаковым набором измерений. И время как специфическое измерение не является исключением. Точно так в v7 нельзя установить два разных значения периодического реквизита на одну дату (один документ).
Вот и получается, что для реализации РС, требующего регистрацию изменений документами, регистр накопления v7 подходит, а для всех прочих РС, даже периодических, но не требующих регистрации, НЕ БУДЕТ РАБОТАТЬ, в отличие от того же справочника.

Заинтересовало. Где взять демо-конфу с РП на "пощупать-поизучать"?

to Палыч:
Сопоставил (53) и (48) и понял, что вам не хотелось бы создавать 30 справочников, реализующих различные пользовательские детерминанты. Ок, вопрос понятен.
В УАУ (там РП на справочниках) справочники не размножаются по причине использования подчиненных (и еще каких-то хитрых механизмов вроде ссылочного детерминанта).
Но вообще, последние веяния - реализация пользовательских РП на документах (реализовано). Один РП - один документ (сами правила - в табличной части).
---
По поводу реализации в V8. Не уверен, что регистры сведений впрямую подойдут для реализации РП.

(54)
Согласен!
Продолжим рассуждение: в статьях на итланде приведена лишь идея (весьма полезная) с иллюстрациями. Единственный пример реального ее использования - "Учет. Анализ. Управление" от КИНТ-а (если ошибаюсь, примеры, пожалста, в студию).
Вопросы технической реализации РП оставим, пока, в стороне.
Как мы уже выяснили, область применения РП довольно обширна: от RLS до описания бухгалтерских проводок.
Так вот, когда я себе представляю конфигурацию хотя бы только с RLS на РП, то вижу этакого "монстра", в котором количество справочников РП сравнимо (если не превышает) количество "основных" справочников.
Пока я ничего не утверждаю - плохо это или хорошо. Просто хочу услышать мнение аудитории, особенно имеющих практический опыт в этом вопросе.

(60) было для (56)

(55) неправ. Там журнал документов и открытый документ.

Насчет реализации: для меня пока актуальны 7.7, SQL и 1С++, поэтому, думаю, достаточно в конфигураторе завести справочник и потом обращаться с ним как с обычной SQL-ной таблицей.

(62) Научите меня еще различать пиктограммы на дочерних окнах и панелях инструментов.

Кстати, вне зависимости от способа реализации, для обработки большого объема данных РС в отчетах красиво смотрится метод Запрос.Получить(Группировка1, Группировка2,..) в запросе с группировками по измерениям без итогов. Прям как для этого создан.

(65) в этом весь смысл. Нужная информация получается простейшим запросом.

(62) Облажался. Действительно справочники.

(66) Когда дело касается всего одной записи, например при пересчете строки документа нужно бысто найти запись по измерениям и выдать значение ресурса, то запрос по всему РС в этом случае - просто расточительство. Потому-то в реализации и нужен некий ИД записи, "естественный" или искуственный.

(60) Насчет "монстра".
Вспомнил, что вначале служебные РП в УАУ реализовывались именно как отдельные справочники. А потом, когда их количество перевалило за десяток, спохватились и свели все служебные РП в пару справочников.

(69)
А, ну вот...

(60) Реально алгоритмы подобного рода нужны при действительно сложной
задаче. Например такое я делал для того чтобы сделать перевод с одного
плана счетов на другой (Украина) не только остатки но и движения за полгода. Делалось это еще в 2000 году, статей Дмитрия Малюгина я правда не читал ж))
А идею взял из старой старой проги файрвола AtGuard, где он сам динамически всплывает с предложением задать набор атрибутов типа порт, ИПвходящий, TCP/UDP и так далее, а на выходе дается либо Разрешить либо Нет.
У меня же было так: первичными атрибутами являлись атрибуты стандартной бух проводки (СчетДебет, СубконтоДебет1, ... СчетКредит, ..., Суммма.
Иногда входящий набор был не только 1 проводкой, а серией проводок,
то есть Атомом считалось более одной проводки.
А выход был последовательным преобразованием входа в выход (функциями, а не только жесткими детерминантами). Делал на документах. Перехватил стандартную Операция.Записать и при проведении любого документа перебирались документы ПравилаПереноса и если правила не находилось то всплывал НовыйДокумент с уже заданными входящими параметрами и предлагал выбрать (настроить) выход. Если же правило было - конвертировалось по нему. За неделю простого проведения разных документов динамически заполнили все правила и вуаля ж))
Насколько целесообразно это применять в простой конфигурации тут вопрос.
Больше этот алгоритм мне лично никогда не потребовался ж))
А если вопрос в коэффициенте угла пальцев дык есть более интересные способы повеселиться ж))

(71)
Ха! Чё-та все сложные, блин, задачи попадаются ;-)
И где вы простые берете? ;-)

to Палыч
Кстати, было бы неплохо, если бы кто-нибудь сподвигнулся создать в 1С++ класс такой - РП... :)

(73)
Да класс-то не проблема.
Идея должна созреть!
зы: Посмотрел я УАУ. Действительно "тиражное" решение.

(74) А почему "тиражное" в кавычках?

Ну в смысле, оно действительно ТИРАЖНОЕ, читай - требует доработки ;-)