Використання визначуваних типів
<em>Область застосування: керований застосунок, звичайний застосунок.</em>
Область застосування: керований застосунок, звичайний застосунок.
1. Визначувані типи призначені для визначення типів даних, які описують часто використовувані сутності або з високим ступенем ймовірності можуть змінюватися під час упровадження прикладного рішення. Вони дають змогу багаторазово використовувати описуваний тип або набір типів без уточнення складу в різних місцях конфігурації (у реквізитах, властивостях об'єктів, форм тощо).
Див. також статтю на ІТС: «Об'єкти конфігурації – Визначувані типи»
2. Визначувані типи рекомендується використовувати в таких випадках:
2.1. Для визначення простого типу та його кваліфікаторів, що має прикладний зміст і використовується в різних реквізитах, ресурсах, реквізитах форм, макетах тощо в межах будь-якої підсистеми або в усьому прикладному рішенні. Це гарантує однакову довжину, точність даних у всіх місцях використання, спрощує доопрацювання в разі зміни вимог.
Наприклад:
- НомерСчетаФактуры - Рядок, довжина 30. Регламентує формат номера рахунка-фактури в різних документах: ПоступлениеТоваровИУслуг, ЗаписьКнигиПокупок, ВозвратТоваровОтКлиента та ін.
- АдресДоставки - Рядок, 500. Текстове подання адреси доставки в документах ЗаказПоставщику, АдресДоставкиПеревозчика, в обробці ПомощникПродаж, у реквізиті АдресДоставкиПеревозчика документа ЗаявкаНаВозвратТоваровОтКлиента та ін.
2.2. Для визначення складеного типу, який масово використовується в об'єктах будь-якої підсистеми або в усьому прикладному рішенні. Визначуваний тип гарантує однаковий склад (тип) даних у всіх місцях використання, а також спрощує доопрацювання та впровадження підсистем у прикладні конфігурації.
Наприклад, у конфігурацію впроваджено підсистему Взаимодействия, яка призначена для ведення листування електронною поштою, реєстрації дзвінків і зустрічей. Під час упровадження цієї підсистеми розробник ухвалив рішення про склад об'єктів метаданих, які можуть виступати як «контакти взаємодій» - це елементи довідників ФизическиеЛица, Партнеры, КонтактныеЛицаПартнеров, і задав цей склад типів у визначуваному типі КонтактВзаимодействий, передбаченому в підсистемі. Своєю чергою, визначуваний тип масово використовується в реквізитах об'єктів і формах підсистеми (у документах Встреча, ЗапланированноеВзаимодействие - таблична частина Участники, у документі СообщениеSMS – таблична частина Адресаты, у документі ТелефонныйЗвонок - реквізит АбонентКонтакт, у загальних формах АдреснаяКнига, ВыборКонтакта – реквізити КонтактыПоПредмету,у параметрі макета ИерархияВзаимодействийКонтакт журналу документів Взаимодействия тощо) Інакше, без використання визначуваного типу КонтактВзаимодействий довелося б знімати об'єкти підсистеми з підтримки та задавати необхідний склад типів у всіх перелічених місцях.
2.3. Під час розроблення впроваджуваної підсистеми - для перевизначення прикладного типу, який буде уточнений під час упровадження.
Наприклад, тип підсистеми Поставщики під час упровадження може бути замінений на прикладний тип конфігурації Контрагенты.
3. Некоректно використовувати визначувані типи для задання «синоніма» наявному типу, «підміни» сутностей, для локального (не масового) використання в межах однієї підсистеми (конфігурації) без потреби впровадження в інші конфігурації, лише з міркувань легкості доопрацювання. Як правило, це свідчить про помилку проєктування або про методологічно неправильний вибір початкової назви типу.
Наприклад, у конфігурації передбачено довідник Контрагенты, посилання на який є в кількох регістрах відомостей, реквізитах форм та інших об'єктах конфігурації. Водночас довідник не є ані частиною вбудовуваної підсистеми, ані прикладною сутністю, яку можна розширити іншими типами. Тоді некоректно створювати додатковий визначуваний складений тип, що складається з єдиного типу Контрагенты, на «всякий випадок», для «механічного» спрощення можливої зміни конфігурації надалі, оскільки це розмиває прикладний зміст сутності.
