AX 2012 R2: как лучше ссылаться на договор в своих модификациях?

[gl00mie]

В локализованной AX 2012 R2 имеется следующее:

• стандартная таблица AgreementHeader и связанный с ней функционал. Первичный ключ на таблице - суррогатный, альтернативного ключа нет;
• стандартные таблицы SalesAgreementHeader и PurchAgreementHeader, являющиеся наследниками AgreementHeader. Первичный ключ на них - суррогатный, но на каждой таблице есть еще альтернативный ключ - SalesNumberSequence + SellingLegalEntity и PurchNumberSequence + BuyingLegalEntity, соответственно; иными словами, в стандартном приложении предполагается, что SalesAgreementId/PurchAgreementId уникальны лишь для того или иного контрагента;
• локализаторская таблица AgreementHeaderExt_RU, не являющаяся наследником AgreementHeader и ссылающаяся на нее по RecId. Первичный ключ - суррогатный, но есть альтернативный ключ - AgreementId. Еще есть производные от нее таблицы SalesAgreementHeaderExt_RU и PurchAgreementHeaderExt_RU, но с точки зрения хранения ссылок на договор их наличие ничего особо не меняет. NB! индекс по ссылке на AgreementHeader.RecId в локализаторской таблице зачем-то сделан неуникальный, хотя по всем признакам кардинальность связи двух таблиц при включенной локализации должна быть 1:1;
• локализаторские же таблички вроде SalesTable_RU/PurchTable_RU, которые ссылаются на AgreementHeaderExt_RU.RecId;
• куча локализаторского функционала, которая также использует ссылку на AgreementHeaderExt_RU.RecId;
• некий общий подход к использованию суррогатных ключей в качестве первичных и, как следствие, ссылок на сущности по суррогатному ключу (RecId);
• строки журналов ГК, в которых - единственных, кажется - ссылки на договора для счета/кор.счета реализованы локализаторами через строковый AgreementId, а не через суррогатный ключ.

Чего хочется:

1. использовать в своих модификациях унифицированный подход для ссылок на договоры
2. использовать в своих модификациях как стандартный, так и локализаторский функционал, работающий с договорами, с минимумом дополнительных телодвижений
3. нормально пользоваться стандартным функционалом просмотра подробных сведений там, где есть ссылка на договор
4. нормально пользоваться стандартным функционалом reference group для выбора договоров и отображения дополнительных полей из них на формах, где в источниках данных есть ссылка на договор
5. обязательно отображать на формах и в отчетах текстовый идентификатор как минимум клиентских договоров
6. при ручном выборе договора дать возможность пользователям сужать выборку по группам договоров (AgreementClassification)
7. уметь нормально вводить ссылку на договор в диалогах, т.е. через unbound-контролы
8. на некоторых формах - фильтровать записи по названию групп договоров (AgreementClassification.Name)
9. при всем при этом не плодить шибко много join'ов и не утяжелять запросы, а если и плодить join'ы, то опять же максимально за счет стандартных средств и возможностей (reference data sources, navigation methods, etc)

Какой подход к реализации ссылок на договоры в "своих" таблицах , по-вашему, лучше выбрать с учетом описанных хотелок и имеющихся в стандарте особенностей реализации? AgreementHeaderExtRecId_RU вроде всем хорош, но не вполне удовлетворяет требованиям 3, 4, 8, 9. AgreementHeaderRecId более симпатичен, но не вполне удовлетворяет требованиям 2, 5 (если неизвестно, клиентский у нас договор или поставщический), 7. Как вы дорабатываете (если дорабатываете) стандартную схему данных договоров с учетом локализации? Возможно, в хотелках не указано явно что-то важное с учетом особенностей реализации договоров в стандартном приложении, если так, то что именно?

[slava]

Цитата:

Сообщение от gl00mie

иными словами, в стандартном приложении предполагается, что SalesAgreementId/PurchAgreementId уникальны лишь для того или иного контрагента;

можно уточню: по этим полям уникальность в рамках компании, в моем понимании

[gl00mie]

Нет, договора хранятся в 2012 R2 без разделения по компаниям, т.е. они общие для всего partition'а, равно как и DirPartyTable. Таким образом, значения SalesAgreementId/PurchAgreementId уникальны в разрезе контрагентов для всех компаний partition'а.

[slava]

наверное мы одно и то же имели ввиду

[S.Kuskov]

Подскажите, пожалуйста, на каком варианте вы остановились в итоге. Что оказалось удобнее на практике?

[Logger]

Всем привет.
В данной тебе это возможно оффтопик, но спрошу.

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

Кто-нибудь так пробовал делать ?

[Raven Melancholic]

Ну и, через год тоже попробую спросить:

Цитата:

Подскажите, пожалуйста, на каком варианте вы остановились в итоге. Что оказалось удобнее на практике?