Как в ЗУП 3.1 Лучше хранить английские написания фамилии, имени, отчества
Для некоторых отчетов ( к примеру англоязычный расчетный листок) требуется хранить наряду с русским еще английское написание фамилии, имени, отчества физического лица. В ЗУП 2.5 это было сделано через механизм дополнительных свойств и значений. А как лучше сделать это в ЗУП 3.1. Через дополнительные реквизиты или дополнительные сведения?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Ну и, пожалуй, стоит упомянуть, что доп.реквизиты являются элементами соответствующих справочников и доступ к ним (доп.реквизитам) имеют только те, у кого есть доступ к самому справочнику.
Доп.сведения хранятся в отдельном регистре.
А не пробовали вместо доп.реквизитов / сведений использовать типовой функционал при создании заявок на открытие счетов ?
Там есть уже готовые процедуры типа
"ОбменСБанкамиПоЗарплатнымПроектамКлиентСервер.СоответствиеСимволовЭмбоссированногоТекста()" и ОбменСБанкамиПоЗарплатнымПроектамКлиентСервер.СтрокаНаЛатинском(..).
Если же текст на латинице не будет соответствовать тому, что хотят, тогда смотреть в сторону доп.данных
Доп.сведения хранятся в отдельном регистре.
А не пробовали вместо доп.реквизитов / сведений использовать типовой функционал при создании заявок на открытие счетов ?
Там есть уже готовые процедуры типа
"ОбменСБанкамиПоЗарплатнымПроектамКлиентСервер.СоответствиеСимволовЭмбоссированногоТекста()" и ОбменСБанкамиПоЗарплатнымПроектамКлиентСервер.СтрокаНаЛатинском(..).
Если же текст на латинице не будет соответствовать тому, что хотят, тогда смотреть в сторону доп.данных
(4) А если нужно в запросе к примеру поля
То как вызывать функцию ОбменСБанкамиПоЗарплатнымПроектамКлиентСервер.СтрокаНаЛатинском() в запросе?
Сгруппировать По
ИмяФизЛица,
ФамилияФизЛиц,
ОтчествоФизЛиц
АнглИмяФизЛица,
АнглФамилияФизЛица,
АнглОтчествоФизЛица,
Упорядочить ПО АнглФамилияФизЛица
ПоказатьТо как вызывать функцию ОбменСБанкамиПоЗарплатнымПроектамКлиентСервер.СтрокаНаЛатинском() в запросе?
Вариант был предложен с той точки зрения, что есть некий типовой алгоритм, почему бы не рассмотреть его. Далее уже надо ориентироваться на прикладную необходимость:
Если используется типовой расчетный листок (р/л), то надо посмотреть, позволяет ли он корректно вывести доп.реквизиты на форму. Если позволяет, тогда не придется городить огороды с эмбоссированным текстом.
Если это Ваш отчет на базе типового р/л, то я бы тогда особо не гемороился и также остановился на доп.реквизитах.
А уж если совсем "уходить в программирование" и отказываться от доп.данных, то тогда можно попробовать так: через "Запрос.Выполнить()" получается некая виртуальная таблица (в/т), содержащая в себе поля "Физ.лицо, Фамилия, Имя, Отчество, АнглФамилия, АнглИмя, АнглОтчество". Создается своя процедура СтрокаНаЛатинском(), которая за 1 заход обрабатывает всю в/т (например, через таблицу значений), заполняя англ.значения. Затем в/т возвращается в запрос и обрабатывается по ключевому полю "Физ.лицо".
Вариант выглядит, конечно, как некие "костыли", но вполне имеет место быть.
Если используется типовой расчетный листок (р/л), то надо посмотреть, позволяет ли он корректно вывести доп.реквизиты на форму. Если позволяет, тогда не придется городить огороды с эмбоссированным текстом.
Если это Ваш отчет на базе типового р/л, то я бы тогда особо не гемороился и также остановился на доп.реквизитах.
А уж если совсем "уходить в программирование" и отказываться от доп.данных, то тогда можно попробовать так: через "Запрос.Выполнить()" получается некая виртуальная таблица (в/т), содержащая в себе поля "Физ.лицо, Фамилия, Имя, Отчество, АнглФамилия, АнглИмя, АнглОтчество". Создается своя процедура СтрокаНаЛатинском(), которая за 1 заход обрабатывает всю в/т (например, через таблицу значений), заполняя англ.значения. Затем в/т возвращается в запрос и обрабатывается по ключевому полю "Физ.лицо".
Вариант выглядит, конечно, как некие "костыли", но вполне имеет место быть.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот