Цитата:
Сообщение от
mazzy
Можно подробнее?
Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?
gloomie, правильно отметил, примером может быть подмена кодов номенклатуры (ItemId) или клиента (CustAccount) везде где они используются, например классе AxSalesLine, см. методы parmItemId(), parmCustAccount(). У них везде есть код похожий на:
X++:
if (this.valueMappingOutbound())
{
return this.axCustAccount(salesLine.CustAccount);
}
else
{
return salesLine.CustAccount;
}
Что означает, если в данном документе, для данного поля таблицы (в примере вверху это SalesLine.CustAccount) настроен value mapping, то будет происходить подмена значений "на лету" всегда когда это поле будет использоваться системой (доступ к полям в AIF производится только используя parm-методы Ax-классов).
Цитата:
Сообщение от
gl00mie
По-моему, это AIF появился в 4.0, а AxBC-классы были и ранее, только использовались не в AIF, а в Commerce Gateway, т.е. как минимум они были уже в 3.0 (более ранние версии я не застал).
Тут Вы 100% правы, AIF и Axd-классы появились в 4.0, а AxBС-классы были ещё в 3.0
Цитата:
Сообщение от
gl00mie
Опять же не могу согласиться. Если кто пробовал добавлять свои или модифицировать штатные обработчики modifiedField(), скажем, для шапки или строк заказов и ожидал увидеть в одноименном стандартном методе привычный switch(_fieldId), то его - опять же со времен 3.0 - ждал "сюрприз":
Исключения, только подтверждают правила :-) Можно найти разные примеры использования AxBC-классов вне модулей AIF и InterCompany (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.