D365 как правильно переопределить метод в таблице.

[Skolos]

Как пример, для понимания, могу предложить следующую задачу синхронизации.
В CustTable добавляем свое enum:NoYes поле isSynch. Оно отображает синхронищзирована ли строка с другой системой.
При insert CustTable поле isSynch=NoYes::No
При update CustTable поле isSynch=NoYes::No

Пускай есть обработчик синхронизации, он фильтрует CustTable по нашему полю и забирает не синхронизированые строки, делает update CustTable поле isSynch=NoYes::Yes
В 2012 я бы добавил параметр и логику в метода update. Как мне поступить в D365?

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

Делаем таблицу myTable с двумя полями.
Enum::NoYes поле isSynch
RefRecId поле CustTableRecId

Связываем ее с CustTable. На insert CustTable вешаем создании соответственной строки и в моей новой таблице. на событие onUpdated CustTable вешаем myTable.isSynch = NoYes::No.
А обработчик синхронизации будет lделать. myTable.isSynch = NoYes::Yes

таком образом я избавляюсь от необходимости в аргументе на update.

И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?

[ax_mct]

Цитата:

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

Как пример, для понимания, могу предложить следующую задачу синхронизации.
...
И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?

Если возможно по бизнес-логике то лучше через несвязанный batch job(пакетник).

Если нужно "run-time" то postInsert подписка с хранением состояния в отдельной таблице.

[sukhanchik]

Цитата:

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

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

Делаем таблицу myTable с двумя полями.
Enum::NoYes поле isSynch
RefRecId поле CustTableRecId

Связываем ее с CustTable. На insert CustTable вешаем создании соответственной строки и в моей новой таблице. на событие onUpdated CustTable вешаем myTable.isSynch = NoYes::No.
А обработчик синхронизации будет lделать. myTable.isSynch = NoYes::Yes

таком образом я избавляюсь от необходимости в аргументе на update.

Да, это тот вариант, который предлагают другие участники. Более того, так в системе уже активно делают и еще в AX 2012, когда таблицы "режут по вертикали" и связывают 1:1 по RecId.
Вариант с myTable - хороший вариант. Более того, дополнительное поле isSynch даже не нужно. Его роль будет играть наличие записи в myTable. Собственно говоря событие update() тут и не нужно. Приходит обработчик синхронизации, забирает записи из CustTable и вставляет забранные RecId в отдельную таблицу. Это событие (с т.з. бизнес-пользователя) никак не связано с изменением какого-либо другого поля типа "Налоговая группа" непосредственно в CustTable.
Отобразить галку в CustTable можно с помощью дисплей-метода, который будет делать exists join к myTable. Фильтровать - также по (not) exists join (тут придется немного покодить, если захочется организовать пользователю фильтр по этому полю, однако задача глобально - решаема).

Так что в контексте этой задачи использовать методы insert / update для вставки своей логики - не нужно. В отношении delete, если реализовать каскадное удаление в myTable, то на delete в myTable можно будет послать какой-нибудь сигнал второй системе. Но это уже не на CustTable, а в myTable - т.о. штатный функционал не трогается.

Цитата:

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

И, я заметил, в моих таблицах с методами insert/update/delete я могу работать как угодно, и добавлять параметры. Выходит, в соответствии с новыми парадигмами, в своих таблицах этого так же стоит избегать?

Тут есть такое понятие, как модель. Править таблицу можно только в рамках одной модели. При этом не должно быть циклических ссылок моделей друг на друга. Использование же одной большой модели приведет к тому, что каждый билд будет равняться глобальной компиляции всего дополнительного (кастомного) кода. Т.о. не исключен риск того, что Вам придется делать расширения (Extensions) на объекты из другой модели, лишь бы не делать из другой модели ссылку на Вашу модель.

Поэтому на мой взгляд лучше избегать использования insert / update / delete, чтобы впоследствии не пришлось бы управлять последовательностью вызова многочисленной толпы обработчиков insert / update / delete. Ряд задач может решиться с помощью дополнительных узкоспециализированных таблиц.