Как в БСП правильно определять ФИО пользователя для подписи?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) А почему коряво? В конфигурациях, сделанных на БСП, обычно есть функция вида
Она выдаст структуру, которую потом скормить функции
в параметре ФамилияИмяОтчество.
Если у Вас нашлась уже готовая функция для подписей, зачем огород городить? Посмотрите только, какой функцией лучше получать ФИО НА ДАТУ, и всё!
ФизическиеЛицаУТ.ФамилияИмяОтчество(ФизическоеЛицо, Дата = Неопределено)
Она выдаст структуру, которую потом скормить функции
ФизическиеЛицаКлиентСервер.ЧастиИмени(ФамилияИмяОтчество)
в параметре ФамилияИмяОтчество.
Если у Вас нашлась уже готовая функция для подписей, зачем огород городить? Посмотрите только, какой функцией лучше получать ФИО НА ДАТУ, и всё!
(3) дело в том, что в справочнике Пользователи может быть не указано физическое лицо.
То есть, функция должна быть примерно такой:
В УПП вроде бы было что-то типа этого
То есть, функция должна быть примерно такой:
Если ЗначениеЗаполнено(ОтветственноеЛицо.Физлицо) Тогда
ФамилияИО = ФизическиеЛицаУТ.ФамилияИнициалыФизЛица(ОтветственноеЛицо.Физлицо, Дата);
Иначе
ФамилияИО = ФизическиеЛицаУТ.ФамилияИнициалыФизЛица(ОтветственноеЛицо.Наименование);
КонецЕсли;
В УПП вроде бы было что-то типа этого
БСП, с некоторых пор, не имеет подсистемы "ФизическиеЛица" (когда-то была).
Следовательно, "чистая" БСП, подозреваю, этой задачи не решает.
Суффиксы "УТ" и "ЗарплатаИКадры" - намекают на то, что это модули специфичные для конкретной конфигурации.
Следовательно, "чистая" БСП, подозреваю, этой задачи не решает.
Суффиксы "УТ" и "ЗарплатаИКадры" - намекают на то, что это модули специфичные для конкретной конфигурации.
А имя пользователя может быть любым, вовсе не обязательно ФИО. Поэтому использовать имя пользователя в качестве источника получения ФИО для подписи - как минимум странно. Т.е. типовым решением это всяко быть не может.
(6) Но всё равно, и в ЗУП, и в БП, и в УТ есть функция, получающая корректное ФИО на дату (по ссылке на Физлицо!), и функция, которая из этих ФИО сформирует подпись. И в конкретной реализации (у Автора ведь не сферическая конфигурация в вакууме, да?) лучше пользоваться именно этими функциями: ими пользуется сама 1С и если что-то изменится (да хоть, к примеру, учёт отчеств "-оглы", "-оглан"), то поправить функцию 1С - и всё заработает, везде сразу!
(7) Да кто же спорит. Я просто заагрился на "БСП" в вопросе.
Решил побыть буквоедом и подчеркнуть, что в рамках БСП задача не решается.
И это вина разработчиков БСП, которые совершенно зря исключили физ-лица из стандартных подсистем. И теперь разработчики типовых вынуждены де-факто поддерживать БСП level 2. Туда же и настройки печати комплектов. В чем была проблема реализовать их в рамках подсистемы управления печатью?
Решил побыть буквоедом и подчеркнуть, что в рамках БСП задача не решается.
И это вина разработчиков БСП, которые совершенно зря исключили физ-лица из стандартных подсистем. И теперь разработчики типовых вынуждены де-факто поддерживать БСП level 2. Туда же и настройки печати комплектов. В чем была проблема реализовать их в рамках подсистемы управления печатью?
(9) Так же, как и с Организациями, и с Контрагентами, и с Подразделениями/Складами/СтруктурнымиЕдиницами...
1С, кажется, намеренно делают свои конфы так, чтобы их невозможно было объединить в едином продукте. С учётом отсутствия ООП (это при языке-то 1С!) получается намеренно подстроенная всем ж*. Но это - не новость...
1С, кажется, намеренно делают свои конфы так, чтобы их невозможно было объединить в едином продукте. С учётом отсутствия ООП (это при языке-то 1С!) получается намеренно подстроенная всем ж*. Но это - не новость...
С БСП просто странная ситуация сложилась. Она пытается усидеть на двух стульях.
1) с одной стороны - БСП должна быть наибольшим общим делителем типовых. Чтобы у них была общая стандартизированная база, что во многом упрощает разработку, сопровождение и интеграцию.
2) БСП в идеале должна состоять из независимых подсистем, которые легко смогут использовать сторонние разработчики по своему выбору.
Но эти две задачи конфликтуют между собой, потому что многие подсистемы более близкие предметной области - взаимозависимы.
Ведь сначала были и подсистемы "Организации" и "ФизическиеЛица" и еще что-то... И в документации на внедрение были целые опусы как внедрять взаимосвязанные подсистемы при разных комбинациях выбранных подсистем. В итоге на это плюнули и выпилили к чертовой бабушке, т.к. и без этого выборочное внедрение БСП с нуля мало кто осиливает.
ИМХО, было было бы гораздо больше толку, если бы забили на второй пункт и сосредоточились на первом. Но описав взаимосвязи подсистем.
1) с одной стороны - БСП должна быть наибольшим общим делителем типовых. Чтобы у них была общая стандартизированная база, что во многом упрощает разработку, сопровождение и интеграцию.
2) БСП в идеале должна состоять из независимых подсистем, которые легко смогут использовать сторонние разработчики по своему выбору.
Но эти две задачи конфликтуют между собой, потому что многие подсистемы более близкие предметной области - взаимозависимы.
Ведь сначала были и подсистемы "Организации" и "ФизическиеЛица" и еще что-то... И в документации на внедрение были целые опусы как внедрять взаимосвязанные подсистемы при разных комбинациях выбранных подсистем. В итоге на это плюнули и выпилили к чертовой бабушке, т.к. и без этого выборочное внедрение БСП с нуля мало кто осиливает.
ИМХО, было было бы гораздо больше толку, если бы забили на второй пункт и сосредоточились на первом. Но описав взаимосвязи подсистем.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот