Required поле в схеме AIF документа

[kitty]

Две таблицы связаны по RecId (SurrogateKey: ChildTable.TableRefRecId = ParentTable.RecId). Есть соответствующий relation
TableRefRecId поле в ChildTable таблице обязательное (Mandatory = yes)

На основе этих двух таблиц создан запрос и соответвующий document service.

С чем связано, что, не смотря на то, что это surrogate key, в схеме документа автоматически для TableRefRecId проставляется required = yes (т.е minOccurs = 1) ?

AX2012 R2

[ax_mct]

Цитата:

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

Две таблицы связаны по RecId (SurrogateKey: ChildTable.TableRefRecId = ParentTable.RecId). Есть соответствующий relation
TableRefRecId поле в ChildTable таблице обязательное (Mandatory = yes)

На основе этих двух таблиц создан запрос и соответвующий document service.

С чем связано, что, не смотря на то, что это surrogate key, в схеме документа автоматически для TableRefRecId проставляется required = yes (т.е minOccurs = 1) ?

AX2012 R2

Как раз смотря на это. Почему другие ожидания для surrogate key?

[kitty]

Не логично, тк при импорте документа , если TableRecid - required, то валидация документа провалится с ошибкой.
На момент импорта ParentTable.RecID вообще еще не существует (
присвоится только при вставке ParentTable записи в Ax и потом должно соответствующее значение автоматически присвоится childTable.TableRecId)

Причем, в prepareForSaveExtended есть соответсвующий код, присваивающий потомкам tableRecId родителя

[ax_mct]

Цитата:

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

Не логично, тк при импорте документа , если TableRecid - required, то валидация документа провалится с ошибкой.
На момент импорта ParentTable.RecID вообще еще не существует (
присвоится только при вставке ParentTable записи в Ax и потом должно соответствующее значение автоматически присвоится childTable.TableRecId)

Причем, в prepareForSaveExtended есть соответсвующий код, присваивающий потомкам tableRecId родителя

Сдается мне в прикладной логике ошибка, зачем импортировать несохраненные записи? Какой прикладной смысл?

Система просто рендерит свойство поля таблицы в схему. Раз обязательно там значит обязательно и здесь. Железная логика.

[kitty]

наверное, мы друг друга не понимаем)
Представьте, что вы импортируете заказ. У него еcть шапка и линии
Как можно требовать в сообщении указывать recid шапки на строках, если этот RecId создается только в момент вставки шапки заказа.

[gl00mie]

Может, у вас схема документа получилась "какая-то не такая"? Посмотрите, какая схема у тех же заказов на продажу - там прекрасно создаются шапка и строки, несмотря на то, что SalesId создаваемого заказа в строках явно не указывается.

[kitty]

Проблема в том, что на одном приложении все прекрасно, а на другом - нет((

Пытаюсь понять в чем разница. все relations есть. Сравнила классы, таблицы -все одинаковые, перекомпилила не раз, update document service делала, refresh service, пересоздала порт сам и все никак. Схема упорно требует заполнения parentRecid (((.
Временно пришлось сделать поле как mandatory = no.. - подхватил и сделал поле необязательным в схеме Но это ж не выход, на таблице оно должно быть Mandatory((.

[nano3]

ну может попробовать в методе initMandatoryFieldsExemptionList класса Ax<Имя таблицы> прописать строчку для этого поля - тогда не придется св-во Mandatory поля менять. Хотя конечно странно все это...

[ax_mct]

Цитата:

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

наверное, мы друг друга не понимаем)
Представьте, что вы импортируете заказ. У него еcть шапка и линии
Как можно требовать в сообщении указывать recid шапки на строках, если этот RecId создается только в момент вставки шапки заказа.

Ступил я. Всегда путал экспорт с импортом и дебит с кредитом

На индексе в таблицах свойство AllowDublicates одинаковое?