Один почтовый адрес с историей

[Владимир Максимов]

В dax2012 работа с почтовыми адресами может быть организована по двум "шаблонам" (паттернам)

1. Документ напрямую ссылается на один адрес. Пример - это справочник "Перевозчик" (SalesCarrier)
2. На одну запись документа может быть много адресов разных типов. Пример - это справочник сайтов (InventSite)

При этом история изменений почтовых адресов ведется только для второго варианта. Посмотреть историю можно через "Дополнительные параметры" \ Дополнительно \ переключатель "Вид"

Есть ли штатные инструменты, чтобы организовать ведение истории изменения адреса для первого варианта?

PS: Физически таблица LogisticsPostalAddress такое позволяет. Но есть ли готовые формы/классы? Или придется что-то самому делать?

[Raven Melancholic]

Я нудный и поэтому сказал вы, что не два, а три паттерна.
Тот, что в теме второй, работает по двум паттернам:

1. Через глобальную адресную книгу.
2. Через отдельные связи НечтоLogisticsLocation, для тех, кто не связан с ГАК.

Вот в этом:

Цитата:

Документ напрямую ссылается на один адрес. Пример - это справочник "Перевозчик" (SalesCarrier)

Так же можно привести в качестве примера банковские группы, банковские счета и т. п. то есть те, в который прямая связь с LogisticsLocation по полю самой сущности.
Там же конкретный RecId таблицы LogisticsLocation, который ссылается на конкретный LogisticsPostalAddress. То есть на запись с конкретным периодом действия.

Тут стандарт явно ничего не предложит.
Явно напрашивается либо связь с ГАК, либо свой НечтоLogisticsLocation.

[Владимир Максимов]

Цитата:

Сообщение от Raven Melancholic

Я нудный и поэтому сказал вы, что не два, а три паттерна

Связь через ГАК - это частный случай второго варианта. Просто еще один дополнительный посредник возникает. Не напрямую от документа, а сначала надо перейти к ГАК, чтобы уже от него искать адреса

DirPartLocation - это тот же НечтоLogisticsLocation

Хотя, да. Формально - это отдельный набор классов и View. Можно считать отдельным паттерном

Цитата:

Сообщение от Raven Melancholic

Так же можно привести в качестве примера

Полный список можно посмотреть в методе

\Classes \ LogisticsLocationEntity \ locationTableList

Цитата:

Сообщение от Raven Melancholic

Там же конкретный RecId таблицы LogisticsLocation, который ссылается на конкретный LogisticsPostalAddress. То есть на запись с конкретным периодом действия.

Формально. На практике, при редактировании адреса по первому паттерну делается настройка

// \Forms\LogisticsPostalAddress\Data Sources\LogisticsLocation\Methods\executeQuery


if (postalAddressForm.isMultiple())
{
	(...)
}
else
{
	(...)
	logisticsPostalAddress_ds.query().validTimeStateDateTimeRange(DateTimeUtil::minValue(), DateTimeUtil::utcNow());
	logisticsPostalAddress_ds.validTimeStateUpdate(ValidTimeStateUpdate::Correction);
}

Т.е. при редактировании не новая запись в истории создается, а правим одну и ту же существующую запись, не меняя ее период действия

Собственно, легко проверяется. После изменения существующего адреса новой записи с новым периодом действия в таблице LogisticsPostalAddress не возникает. Именно по этой причине и нет просмотра истории, поскольку нет этой самой истории. Нечего просматривать

Цитата:

Сообщение от Raven Melancholic

Тут стандарт явно ничего не предложит.
Явно напрашивается либо связь с ГАК, либо свой НечтоLogisticsLocation.

Если речь идет о создании новых справочников, то да. Самый простой путь. Но если просят изменить существующий справочник, то будут сложности с существующим функционалом, который использует этот справочник

Теоретически, тут достаточно было бы добавить новый параметр в класс LogisticsLocationFormHandler и сделать настройки по аналогии с параметром isMultiple. Но там же "наворотили" кучу всего. Это же тестировать все замучаешься