При работе с конфигурацией Бухгалтерия Предприятия 3.0 пользователи часто сталкиваются с ситуацией, когда при попытке установить фильтр в Журнале регистрации по конкретному банковскому счету, в списке выбора отображаются только собственные счета организации. Счета контрагентов при этом отсутствуют, хотя в самом справочнике БанковскиеСчета они созданы и видны через обычную форму списка. В этой статье мы детально разберем, почему так происходит, и рассмотрим несколько способов решения этой задачи: от простых настроек системы до программной корректировки через расширение.
Для начала разберем внутреннюю логику работы платформы и конфигурации. Справочник БанковскиеСчета является подчиненным справочником. Это означает, что у каждого счета есть Владелец. Владельцем может выступать либо объект справочника Организации, либо объект справочника Контрагенты.
Проблема кроется в механизмах Библиотеки стандартных подсистем (БСП), на которой построена современная «Бухгалтерия». В типовом коде формы выбора справочника БанковскиеСчета заложена проверка: если в информационной базе ведется учет только по одной организации (то есть константа ИспользоватьНесколькоОрганизаций установлена в значение Ложь), система автоматически пытается упростить жизнь пользователю. Программа полагает, что раз организация одна, то и выбирать счета контрагентов в контексте общих настроек не нужно, и принудительно устанавливает фиксированный отбор по единственной организации-владельцу.
Выясним, где именно это происходит. В модуле формы выбора справочника БанковскиеСчета в процедуре ПриСозданииНаСервере программно анализируются параметры открытия. Когда мы открываем форму выбора из Журнала регистрации, параметр Владелец не передается, так как журнал регистрации — это общий инструмент мониторинга, не привязанный к конкретному контрагенту. В этот момент срабатывает алгоритм: «Владелец не задан + организация одна = показать только счета этой организации».
Самый быстрый способ заставить систему показывать все счета — изменить логику проверки количества организаций. Рассмотрим, как это сделать:
ИспользоватьНесколькоОрганизаций) изменит поведение формы выбора.ИспользоватьНесколькоОрганизаций в значение Истина.После включения этой опции программный фильтр в процедуре ПриСозданииНаСервере перестанет устанавливаться жестко, так как условие «одна единственная организация» перестанет соблюдаться. В форме выбора Журнала регистрации появятся счета всех владельцев (и организаций, и контрагентов).
Если мы не хотим менять логику учета и включать функционал «многофирменности», нам потребуется небольшая доработка. Рассмотрим, как реализовать расширение, которое будет отключать ненужный отбор именно при вызове из журнала регистрации. Нам нужно перехватить логику инициализации формы выбора.
Проанализируем пример кода, который можно разместить в расширении для формы выбора справочника БанковскиеСчета:
&НаСервере
&После("ПриСозданииНаСервере")
Процедура ИЗМ_ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка)
// Проверяем, задан ли владелец в параметрах отбора
ВладелецЗадан = Параметры.Отбор.Свойство("Владелец");
// Если форма открыта без указания конкретного владельца (как в Журнале регистрации)
// и при этом программно был установлен фиксированный отбор
Если Не ВладелецЗадан Тогда
// Очищаем фиксированные настройки, если они ограничивают видимость счетов
ЭтаФорма.Список.КомпоновщикНастроек.ФиксированныеНастройки.Отбор.Элементы.Очистить();
КонецЕсли;
КонецПроцедуры
Важный нюанс: при использовании этого метода нужно быть осторожным, так как форма выбора используется и в документах. Если мы просто очистим все отборы, пользователь в документе РеализацияТоваровУслуг сможет случайно выбрать счет контрагента вместо счета организации. Поэтому рекомендуется добавить проверку на ИмяФормы владельца или анализировать стек вызова, чтобы понимать, что форма открыта именно для целей фильтрации Журнала регистрации.
Если задача стоит разово — найти события по конкретному счету, который не виден в списке, — рассмотрим обходные пути без изменения конфигурации:
Ctrl+F или воспользоваться поиском, можно попробовать ввести часть номера счета. Однако, как показывает практика (сообщение 13 форума), если установлен ФиксированныйОтбор по владельцу, поиск по строке также будет ограничен только объектами этого владельца..lgp или .lgf напрямую. В таких инструментах выбор объекта часто реализован через построение собственного списка, который игнорирует контекстные ограничения типовых форм 1С.Проанализировав ситуацию, мы видим, что поведение программы обусловлено жесткой привязкой справочника БанковскиеСчета к его владельцу в интерфейсных решениях БСП.
Для администраторов и программистов наиболее «правильным» решением будет использование расширения, так как оно не затрагивает бизнес-логику учета (в отличие от включения константы нескольких организаций) и при этом решает проблему доступности данных. Если же вы — пользователь и вам нужно срочно найти информацию, попробуйте воспользоваться отчетом История изменений непосредственно из карточки банковского счета, так как этот механизм работает в контексте конкретной ссылки и не требует сложных манипуляций с общими фильтрами журнала.
Также стоит помнить, что в последних релизах (начиная с 3.0.100 и выше) 1С постепенно пересматривает такие «жесткие» фильтры, делая инструменты администрирования более гибкими. Регулярное обновление конфигурации может решить проблему естественным путем.