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

- доработать обработку НастройкаПравДоступа, в ней форму НастройкаПравДоступа. Там, во-первых, требуется добавить в ПанельОбластейДанных новую страницу для вашего справочника, и, во-вторых, в коде самой формы найти создание структуры ТипыОбъектовДоступа и добавить в нее новые объекты;
- в регистре сведений НастройкиПравДоступаПользователей в тип измерения ОбъектДоступа (он составной) добавить ваши справочники;
- в ролях пользователей написать сами правила RLS для ваших справочников (можно скопировать с существующих с похожей структурой), иначе настройка работать будет, а ограничения - нет.

Делал такие изменения года 3 назад, так что не уверен, что это все, мог и забыть еще пару деталей

На первый взгляд, задача некорректна. Пример:

День Пробег
1 100
2 200
(здесь прошло обнуление)
3 210

(в первый день наездили 100, во второй тоже 100, дальше обнулили и проехали 210)

Т.е. по предложенным данным невозможно отследить ситуацию, когда в день обнуления машина наездила столько же или чуть больше, чем накопилось до того.
Вывод: нужно добавить информацию, в какие дни было обнуление. Тогда будет возможно решить такую задачу.

Похоже на НоменклатурныеГруппы. Не знаю, есть ли они в УТП, в УПП точно есть.

Это отдельный справочник, в справочнике Номенклатура есть поле со ссылкой на номенклатурную группу (т.е. в отчетах можно делать отбор Номенклатура.НоменклатурнаяГруппа = что-то-там). Для группы можно назначать единицы измерения, только в стандартной Реализации товаров и услуг выбрать ее нельзя.

Мне тут непонятно вот что: если приходуем отдельные виды номенклатуры, а продаем "группу", то что должно списываться со склада?

Тип значения элементов СпискаСотрудников и поля Ответственный совпадает? Не может быть так, что Ответственный - элемент справочника Пользователи, а в списке, например, ФизЛица?

РТиУ = документ Реализация товаров и услуг. Там предусмотрена работа со сканером ШК.

Судя по Вашему скрину, без этого не работает Сообщение как раз и означает, что не видится источник.

Предположение №2: разработка в клиент-серверной базе 1С? Тогда источник должен быть создан на сервере, и желательно в разделе "Системный DSN" ODBC Администратора (чтобы не зависеть от имени пользователя, под которым работает процесс сервера 1С).

По собственному опыту возни с ODBC и Win Server 2008 x64: 32-х битные программы, скорее всего, не увидят источников, созданных через ODBC Администратора в Панели управления. Надо ODBC-источник создавать из 32-х битного ODBC Администратора. Он лежит в %WINDIR%\SYSWoW64\odbcad32.exe (и запускать его надо "от имени администратора" вроде как, на 100% не уверен - запускал из-под админского FAR'а). Проверено с 1С и некоторыми другими 32-х битными приложениями, база (и драйвер) была Sybase SQL Anywhere 9. После использования 32-х битной версии источники начинают видеться.

Правда, я в итоге подключался к источнику из 1С через COM (ADODB.Connection), а не ВнешнийИсточникДанных (Конфигуратор не видел структуру таблиц во внешней базе - видимо, типы данных столбцов ему не нравились, хотя сами таблицы показывал).

Сразу хочу предупредить: налоговую с 5 знаками после запятой в цене клиент у вас может не принять. Что произойдет при попытке отправить такой документ на регистрацию в Едином реестре - непонятно (скорее всего, при отправке цена будет округлена до положенных 2 знаков, после чего начнет не сходиться арифметика: Цена * Количество <> Сумма, и документ может не принять уже налоговая).

Вот так должно работать для любой глубины вложенности:

И ТекущаяТаблица.Родитель.Ссылка В ИЕРАРХИИ (ПраваДоступа.ОбъектДоступа)

(никогда не использовал В ИЕРАРХИИ в RLS, не уверен, что такая конструкция будет работать достаточно быстро)

Доступ только к счетам своего филиала - это как раз то, что я предлагаю ("свои" как раз и будут "не секретными" для пользователя). Остатки и движения по счетам других филиалов тогда ему не нужны и не видны вообще, а RLS построен на контроле счета, проблемы не возникает.

А если нужно видеть именно движения по счетам, среди которых могут быть и "свои", и "чужие" в пределах одного счета, тогда регистр ДвиженияДенежныхСредств в помощь.

На мой взгляд, здесь неправильно выбран сам подход к разграничению прав доступа. Лучшим вариантом было бы завести отдельные счета и кассы для "секретных" и "не секретных" операций, тогда права настроить было бы намного проще (доступ ограничивался бы ко всему счету/кассе целиком). Без этого вводить ограничение на отдельные записи крайне нежелательно.

Рассмотрим такую ситуацию: по счету есть движения, как "видные" пользователю, так и "не видные". Пользователь смотрит остатки и обороты денежных средств по счету. Что он должен увидеть? Либо то, что у Вас в первом сообщении, либо неправильные остатки (чего, насколько я знаю, не позволит платформа). Из-за этого и трудности - Вы пытаетесь решить нерешаемую таким способом задачу.

Как еще один вариант - создайте новый отчет по этому регистру, и в запросе отчета используйте РАЗРЕШЕННЫЕ. Тогда записи "Объект не найден" туда не попадут. А доступ к записям регистра ДенежныеСредства и стандартному отчету по нему для пользователей закройте на уровне интерфейса.

Насколько я знаю, в Вашей конфигурации есть регистр ДвиженияДенежныхСредств. Вот его и нужно использовать, там измерений больше (есть и Контрагент, и СтатьяДвиженияДенежныхСредств, и т.д.) и простор для создания нужных ограничений есть. А расшифровку движений по ДенежнымСредствам тогда вообще не нужно нигде показывать, из этого регистра понадобятся только остатки.

"Структура подчиненности" работает через критерий отбора СвязанныеДокументы. Если в РТиУ добавлялся новый реквизит, то его нужно указать и в критерии отбора, иначе подчиненность по нему не будет видна.
В конфигураторе находим Общие -> Критерии отбора -> СвязанныеДокументы -> Состав -> Документы, ищем РеализацияТоваровУслуг и ставим галку напротив нового реквизита.
(по крайней мере, в УПП так. В УТП могут имена объектов отличаться, но вряд ли)

В разделе известных ошибок в УПП 1.3.19 есть вот такое:

Код ошибки: 35180
Дата публикации: 24 октября 2012 г.
Описание: В документе "Платежное поручение исходящее" с видом операции Перечисление заработной платы возможно сообщение об ошибке если в связанном документе "Зарплата к выплате организаций" фамилия одного сотрудника повторяется больше одного раза

Т.е. это известный глюк данного релиза УПП, в следующем исправят.

Это, кстати, не только в платежке - в РКО то же самое (уже столкнулся). Пришлось править код документа для удаления повторяющихся записей в этом регистре, чтобы хоть как-то провелось. Жду "правильного" фикса от ABBYY.
Возникает, например, тогда, когда в одной "Зарплате к выплате" есть начисления тому же самому человеку за разные периоды. Смотрим, кому именно, в сообщении об ошибке.

Сразу говорю - этот способ добавления регистраторов неправильный, таблица остатков при соединении с ними будет для каждой позиции повторена столько раз, сколько различных документов-регистраторов там было. Применять можно только для случая, когда регистратор всегда только один!
Правильно будет использовать таблицу РегистрНакопления.ТоварыНаКонсигнации.ОстаткиИОбороты.

И все же, если править именно этот запрос, получим примерно такое (добавлены скобки для правильного вложенного запроса, убрано лишнее условие из ГДЕ, которое и так в ЛЕВОМ СОЕДИНЕНИИ стоит):

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ТоварыНаКонсигнацииОстатки.Организация,
    ТоварыНаКонсигнацииОстатки.Консигнатор,
    ТоварыНаКонсигнации.Регистратор,
    ТоварыНаКонсигнацииОстатки.Номенклатура,
    ТоварыНаКонсигнацииОстатки.ХарактеристикаНоменклатуры,
    ТоварыНаКонсигнацииОстатки.СерияНоменклатуры,
    ТоварыНаКонсигнацииОстатки.Качество,
    ТоварыНаКонсигнацииОстатки.Склад,
    ТоварыНаКонсигнацииОстатки.КоличествоОстаток,
    ТоварыПереданныеОстатки.СуммаВзаиморасчетовОстаток
    ИЗ
    РегистрНакопления.ТоварыНаКонсигнации.Остатки КАК ТоварыНаКонсигнацииОстатки,
    РегистрНакопления.ТоварыПереданные.Остатки КАК ТоварыПереданныеОстатки

    ЛЕВОЕ СОЕДИНЕНИЕ
    (
     ВЫБРАТЬ
        ТоварыНаКонсигнации.Номенклатура КАК Номенклатура1,
        ТоварыНаКонсигнации.Регистратор
        ИЗ
        РегистрНакопления.ТоварыНаКонсигнации
    ) КАК ТоварыНаКонсигнации
    ПО ТоварыНаКонсигнации.Номенклатура = ТоварыНаКонсигнацииОстатки.Номенклатура
ГДЕ
    ТоварыПереданныеОстатки.Номенклатура = ТоварыНаКонсигнацииОстатки.Номенклатура

Заодно я поле Регистратор добавил в итоговый список полей (а иначе зачем было его получать?).
По поводу странного соединения - вот такой способ (две таблицы через запятую, условия в ГДЕ) дает результат, аналогичный внутреннему соединению.

Связь между таблицами здесь есть, только она не через СОЕДИНЕНИЕ сделана, а в блоке ГДЕ.

На серверной машине клиентская часть 1С установлена?

Выглядит все так, как будто на сервере не зарегистрирован 1с-овский COM-объект. Может оказаться, что он ставится вместе с клиентской частью, а не с серверной (или при обновлении версии платформы на сервере слетела регистрация COM-объекта, у меня такое было).

В конфигураторе проблемная форма открывается?

У меня была похожая беда на SQL-вой базе, когда во-время не обновил платформу и поставил обновление конфы, рассчитанное на более новый релиз. Формы отчетов не открывались и в конфигураторе тоже, он "падал", тестирование и исправление тоже падало. Решилось все так: обновил платформу, удалил из конфы поврежденные формы, скопировал их из cf свежего релиза (просто открыл cf в конфигураторе и перетянул объекты в рабочую конфигурацию). С тех пор перед обновлением конфы всегда проверяю, какая версия платформы указана в требованиях

В УПП для Украины, по крайней мере в 1.3.17 (текущий релиз), этот запрос сделан через временные таблицы. То ли в части типовых ошибку все же исправили, то ли в УПП ее и не было.

Выглядит это так:

    Запрос.Текст = "
    |ВЫБРАТЬ РАЗЛИЧНЫЕ
    |    РегистрСведений.СписанныеТовары.Номенклатура КАК Номенклатура
    |ПОМЕСТИТЬ 
    |    СписанныеТоварыНоменклатура
    |ИЗ
    |    РегистрСведений.СписанныеТовары
    |ГДЕ
    |    РегистрСведений.СписанныеТовары.Регистратор = &Ссылка
    |
    |;
    |
    |ВЫБРАТЬ РАЗЛИЧНЫЕ
    |    РегистрСведений.СписанныеТовары.Склад КАК Склад
    |ПОМЕСТИТЬ 
    |    СписанныеТоварыСклады
    |ИЗ
    |    РегистрСведений.СписанныеТовары
    |ГДЕ
    |    РегистрСведений.СписанныеТовары.Регистратор = &Ссылка
    |
    |;
    |
    |ВЫБРАТЬ
    |    СписанныеТовары.НомерСтрокиДокумента КАК НомерСтрокиДокумента,
    |    ПартииТоваровНаСкладах.Номенклатура,
    |    ПартииТоваровНаСкладах.ДокументОприходования КАК ДокументОприходования,
    |    "+ПараметрыЗапроса_ДатаОприходования.ДокОприходованияДата_Выбор+"
    |    ПартииТоваровНаСкладах.Склад,
    |    ПартииТоваровНаСкладах.ХарактеристикаНоменклатуры,
    |    ПартииТоваровНаСкладах.СерияНоменклатуры,
    |    ПартииТоваровНаСкладах.Качество,
    |    ПартииТоваровНаСкладах.Заказ,
    |    ПартииТоваровНаСкладах.КоличествоОстаток КАК Количество,
    |    ПартииТоваровНаСкладах.СтоимостьОстаток КАК Стоимость,
    |    ПартииТоваровНаСкладах.СтатусПартии,
    |    ВЫБОР
    |        КОГДА СписанныеТовары.СерияНоменклатуры = ПартииТоваровНаСкладах.СерияНоменклатуры
    |            ТОГДА 0
    |        ИНАЧЕ 1
    |    КОНЕЦ КАК ЧислоСерияНоменклатуры,
    |    ВЫБОР
    |        КОГДА СписанныеТовары.ДокументПартии = НЕОПРЕДЕЛЕНО
    |            ТОГДА 0
    |        ИНАЧЕ ВЫБОР
    |                КОГДА СписанныеТовары.ДокументПартии = ПартииТоваровНаСкладах.ДокументОприходования
    |                    ТОГДА 0
    |                ИНАЧЕ 1
    |            КОНЕЦ
    |    КОНЕЦ КАК ЧислоДокументОприходования,
    |    ВЫБОР
    |        КОГДА СписанныеТовары.ЗаказПартии = НЕОПРЕДЕЛЕНО
    |            ТОГДА 0
    |        ИНАЧЕ ВЫБОР
    |                КОГДА ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
    |                    ТОГДА 1
    |                ИНАЧЕ 0
    |            КОНЕЦ
    |    КОНЕЦ КАК ЧислоЗаказ,
    |    ВЫБОР
    |        КОГДА ПартииТоваровНаСкладах.СтатусПартии = &НаКомиссию
    |            ТОГДА 1
    |        ИНАЧЕ 0
    |    КОНЕЦ КАК ЧислоСтатусПартии
    |ИЗ
    |    РегистрСведений.СписанныеТовары КАК СписанныеТовары
    |        ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрНакопления.ПартииТоваровНаСкладах.Остатки(
    |        &Дат, Организация = &Организация И
    |        Номенклатура В
    |            (ВЫБРАТЬ
    |                СписанныеТоварыНоменклатура.Номенклатура
    |            ИЗ
    |                СписанныеТоварыНоменклатура)" + ?(ВестиПартионныйУчетПоСкладам, "
    |        И (Склад В 
    |            (ВЫБРАТЬ
    |                СписанныеТоварыСклады.Склад
    |            ИЗ
    |                СписанныеТоварыСклады) ИЛИ Склад = &ПустойСклад)", "") + ") КАК ПартииТоваровНаСкладах
    |        ПО СписанныеТовары.Номенклатура = ПартииТоваровНаСкладах.Номенклатура
    |            И СписанныеТовары.ХарактеристикаНоменклатуры = ПартииТоваровНаСкладах.ХарактеристикаНоменклатуры
    |            И (ВЫБОР
    |                КОГДА ПартииТоваровНаСкладах.Качество = &ПустоеКачество
    |                    ТОГДА ИСТИНА
    |                ИНАЧЕ ВЫБОР
    |                        КОГДА СписанныеТовары.Качество = &ПустоеКачество
    |                            ТОГДА ПартииТоваровНаСкладах.Качество = &КачествоНовый
    |                        ИНАЧЕ ПартииТоваровНаСкладах.Качество = СписанныеТовары.Качество
    |                    КОНЕЦ
    |            КОНЕЦ)
    |            " + ?(ВестиПартионныйУчетПоСкладам, "И (ПартииТоваровНаСкладах.Склад = СписанныеТовары.Склад ИЛИ ПартииТоваровНаСкладах.Склад = &ПустойСклад)", "") + "
    |            И (ВЫБОР
    |                КОГДА СписанныеТовары.ДопустимыйСтатус1 <> &ПустойСтатус
    |                        ИЛИ СписанныеТовары.ДопустимыйСтатус2 <> &ПустойСтатус
    |                        ИЛИ СписанныеТовары.ДопустимыйСтатус3 <> &ПустойСтатус
    |                        ИЛИ СписанныеТовары.ДопустимыйСтатус4 <> &ПустойСтатус
    |                    ТОГДА ПартииТоваровНаСкладах.СтатусПартии = &ПустойСтатус
    |                            ИЛИ ПартииТоваровНаСкладах.СтатусПартии = &СтатусПартииПоОрдеру
    |                            ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус1
    |                            ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус2
    |                            ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус3
    |                            ИЛИ ПартииТоваровНаСкладах.СтатусПартии = СписанныеТовары.ДопустимыйСтатус4
    |                ИНАЧЕ ИСТИНА
    |            КОНЕЦ)
    |    
    |        И (ВЫБОР
    |            КОГДА СписанныеТовары.СписыватьТолькоПоЗаказу = ИСТИНА
    |                ТОГДА ВЫБОР
    |                        КОГДА ПартииТоваровНаСкладах.Заказ <> СписанныеТовары.ЗаказПартии
    |                            ТОГДА ВЫБОР
    |                                    КОГДА (НЕ СписанныеТовары.ЗаказПартии = НЕОПРЕДЕЛЕНО)
    |                                        ТОГДА ЛОЖЬ
    |                                    ИНАЧЕ ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
    |                                КОНЕЦ
    |                        ИНАЧЕ ИСТИНА
    |                    КОНЕЦ
    |            ИНАЧЕ ВЫБОР
    |                    КОГДА ПартииТоваровНаСкладах.Заказ <> СписанныеТовары.ЗаказПартии
    |                        ТОГДА ПартииТоваровНаСкладах.Заказ = &ПустойЗаказ
    |                    ИНАЧЕ ИСТИНА
    |                КОНЕЦ
    |        КОНЕЦ)
    |ГДЕ
    |    СписанныеТовары.Регистратор = &ОсновнойДокумент
    |
    |УПОРЯДОЧИТЬ ПО
    |    ЧислоСерияНоменклатуры,
    |    ЧислоДокументОприходования,
    |    ЧислоЗаказ,
    |    ЧислоСтатусПартии" + ?(СтратегияСтатусПартии = Перечисления.СтретегииСписанияПартийТоваровПоСтатусам.СначалаПринятыеПотомСобств
енные, " Убыв", "") + ",
    |    "+ПараметрыЗапроса_ДатаОприходования.ДокОприходованияДата_Сортировка+"
    |    ДокументОприходования" + ?(СпособОценкиМПЗ = "ЛИФО", " Убыв","") + ",
    |    ПартииТоваровНаСкладах.Склад
    |ИТОГИ ПО
    |    НомерСтрокиДокумента";

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

ВЫБРАТЬ
   ЗапросПоследниеДаты.СчетСсылка,
   Поступление.Ссылка
ИЗ
   (
   ВЫБРАТЬ
      Счет.Ссылка КАК СчетСсылка, МАКСИМУМ(Поступление.Дата) КАК МаксДата
   ИЗ
      Документ.СчетВходящий КАК Счет
   ЛЕВОЕ СОЕДИНЕНИЕ
      Документ.ПоступлениеТоваров КАК Поступление
   ПО
      Поступление.Сделка = Счет.Ссылка
   ГДЕ Счет.Дата МЕЖДУ &НачалоПериода И &КонецПериода
   СГРУППИРОВАТЬ ПО Счет.Ссылка
   ) КАК ЗапросПоследниеДаты
ЛЕВОЕ СОЕДИНЕНИЕ
   Документ.ПоступлениеТоваров КАК Поступление
ПО
   Поступление.Сделка = ЗапросПоследниеДаты.СчетСсылка И
   Поступление.Дата = ЗапросПоследниеДаты.МаксДата

Та ошибка, о которой вся тема, в которую я написал. Всегда Ваш, К.О.

Дополнение по теме: думаю, что нашел, при каких условиях этот глюк происходит.

Требуется: сетевая версия 1С 8.2 (с другими не проверял), 2 и более компьютеров (назовем их А и Б), с которых делаются динамические обновления.

Исходные данные: на компьютере А открыт Конфигуратор с изменениями, на компьютере Б открыт "пользовательский" режим. С компьютера А применяют изменения динамически. После этого на компьютере А Конфигуратор закрывают, и открывают его на компьютере Б (не закрывая окно 1С Предприятия).

Что происходит: на машине Б в этот момент находится "неправильная" копия метаданных (в кэше метаданных), так как окно Предприятия не закрывалось и заново метаданные с сервера он не получил. Открываем Конфигуратор, и он (очень похоже на то) использует эту же самую, уже устаревшую, локальную копию! Делаем изменения. При применении изменений из такого Конфигуратора, похоже, и происходит "порча" базы.

Как избежать: после динамического обновления перед открытием Конфигуратора с другой машины обязательно на этой машине закрыть все окна 1С и очистить локальный кэш метаданных. Или, как вариант, все изменения конфигурации делать всегда с одного и того же компа.

Что, кто-то принял это "новость" всерьез?!

(зайдите на сайт-источник и кликните по ссылке "Інформація" в верхнем правом углу страницы...)

На форме открыть Свойства у добавленного поля ввода. Там найти Данные (в самом верху списка), и выбрать нужный реквизит. Он должен быть в группе ДокументОбъект.

И это должен быть именно реквизит документа, не реквизит формы. Реквизиты формы не сохраняются.

Еще по теме: вот статья на Инфостарте все о том же. Там еще и комменты почитать стоит - в них есть пример такого же "лечения" для базы на PostgreSQL. Вдруг кому поможет.

Сегодня столкнулся с этой же бедой. Почитал тему, полазил по ссылкам. В итоге помог вот этот скрипт с Мисты (выполнять в консоли SQL-сервера):

use ИмяАктуальнойБазы
go

truncate table [dbo].[Config]
truncate table [dbo].[ConfigSave]
truncate table [dbo].[DBSchema]
truncate table [dbo].[Params]
--truncate table [dbo].[Files]
go

insert into [dbo].[Config] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Config]
insert into [dbo].[DBSchema] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[DBSchema]
insert into [dbo].[Params] select * from [СтараяБазаИзБекапаНаЭтомЖеСервере].[dbo].[Params]
go

В чем вообще проблема: после каких-то динамических обновлений конфигурация оказывается запорчена. Это выражается разными симптомами - не проходит применение изменений из Конфигуратора, юзеры вылетают в винду с ошибкой basic.dll, тестирование и исправление просто закрывается и т.п.

Что нужно для исправления: заменить конфигурацию на исправную из бэкапа. Если бэкапы регулярно не делались - Вам сильно не повезло.
В чем подвох: Конфигуратор это сделать не может. Даже при попытке Загрузить конфигурацию (а не Сравнить/Объединить) Конфигуратор падает на этапе принятия изменений.
Выход: заставить SQL-сервер сделать всю работу.

Конфигурация хранится в таблице Config, ConfigSave = непримененные изменения. Мы просто затираем нашу испорченную конфигурацию и потом вставляем поверх нее рабочую из бэкапа. Данные при этом не страдают. Всего-то и нужно развернуть бекап на том же сервере, но в другую базу, и выполнить скрипт, поменяв имена баз на свои.