В чем преимущество ax-классов перед непосредственной работой с таблицами?

[mazzy]

Цитата:

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

Также много других мелких положительных ньансов в использовании AxBC-классов в AIF, а не таблиц напрямую. К примеру, можно делать подмену значений прямо на лету (internal -> extrnal value и т.п.)

Можно подробнее?
Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?

[gl00mie]

Спасибо за информацию, но кое с чем не могу согласиться.

Цитата:

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

Так называемые AxBC-классы (с префиксом Ax) появились в AX 4.0 вместе с Axd-классами, как основа нового модуля AIF (Application Integration Framework).

По-моему, это AIF появился в 4.0, а AxBC-классы были и ранее, только использовались не в AIF, а в Commerce Gateway, т.е. как минимум они были уже в 3.0 (более ранние версии я не застал).

Цитата:

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

Ранее упомянутая технология touched - используется для определения, было ли данное поле изменено ранее, и если да, то defaulting его не тронет. Это принциальное отличие от использования к примеру метода modified() на таблице, где легко перезаписать уже имеющиеся данные.

Принципиальное отличие от обработчиков modifiedField(), по-моему, в том, что они срабатывают на изменение каждого поля, т.е. предполагается, что за раз может быть изменено лишь одно поле, поэтому и допускается перезапись всех прочих полей, кроме одного измененного. А на момент вызова AxBC.modified() "тронутыми" может оказаться более одного поля, поэтому и приходится проверять все поля на предмет того, можно ли перезаписывать их значения. При обработке изменения одного поля работа AxBC.modified() принципиально не будет отличаться от вызова modifiedField() на таблице.

Цитата:

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

заметьте - AxBC-классы предназначены только для использования в AIF или InterCompany, больше нигде.

Опять же не могу согласиться. Если кто пробовал добавлять свои или модифицировать штатные обработчики modifiedField(), скажем, для шапки или строк заказов и ожидал увидеть в одноименном стандартном методе привычный switch(_fieldId), то его - опять же со времен 3.0 - ждал "сюрприз":

public void modifiedField(fieldId _fieldId)
{
    AxSalesTable    AxSalesTable;
    Object          formDataSource;

    super(_fieldId);

    if (this.isFormDataSource())
    {
        if (formDataSourceHasMethod(this.dataSource(),classstr(AxSalesTable)))
        {
            formDataSource = this.dataSource();
            AxSalesTable = formDataSource.AxSalesTable();
        }
    }
    else
    {
        AxSalesTable = this.AxSalesTable();
    }

    if (AxSalesTable)
    {
        AxSalesTable.setFieldAsTouched(_fieldId);
        AxSalesTable.modify();
    }
}

Этот код остался неизменным и поныне (AX 2009 SP1).

Цитата:

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

Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?

Я так понимаю, речь о подмене кодов: скажем, код номенклатуры в одной компании может через те же внешние коды сопоставляться с кодом в другой компании и подменяться на лету.

[erudit]

Цитата:

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

Можно подробнее?
Что за подмена "прямо на лету" и почему этого нельзя сделать с таблицами?

gloomie, правильно отметил, примером может быть подмена кодов номенклатуры (ItemId) или клиента (CustAccount) везде где они используются, например классе AxSalesLine, см. методы parmItemId(), parmCustAccount(). У них везде есть код похожий на:

    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 (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.

[mazzy]

Цитата:

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

подмена кодов номенклатуры (ItemId) или клиента (CustAccount) везде где они используются, например классе AxSalesLine, см. методы parmItemId(), parmCustAccount().

Только это?

Цитата:

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

Исключения, только подтверждают правила :-) Можно найти разные примеры использования AxBC-классов вне модулей AIF и InterCompany (как упомянутый Вами), но это будет скорее побочное применение, чем оригинальная задумка.

Хм. Тогда зайдем с другой стороны
Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать?

может я чего пропустил?

вот что есть на форуме

Цитата:

Сообщение от Blog bot

· AxBC (Ax) classes that provide an object API on top of the database tables referenced in the query.

Источник: http://blogs.msdn.com/dsiebold/archi...f-top-ten.aspx

Цитата:

Сообщение от Blog bot

Источник: http://feeds.feedburner.com/~r/Insid...lbase-api.html
==============

The goal for creating Ax classes was to have an API available when creating and updating records in Dynamics AX tables. The design goals of the AxInternalBase API were as follows:

• The API must be easy to use.
• The API must handle related fields. The default value should apply when a field is updated. For example, when you update the customer account field on the sales order, the address fields should be populated with default values when you copy the address fields from the customer record to the sales order record.
• The API must handle the sequence of field updating. For example, the invoice account field is a related field, which should revert to the default value when the customer account field is updated.
• Field value defaulting might not always provide the expected end result. Consider an example: If the invoice account field is updated first and related fields' values are defaulted, and then the customer account field is updated and its related fields' values are defaulted, the defaulted value would then overwrite the explicitly provided value in the invoice account field.
• The API must handle fetching numbers or identifiers from number sequences. For example, when you create a sales order, a sales order number must be fetched from a sales order number sequence. The business logic that handles this is implemented in these classes.

New Ax classes must inherit from the base class AxInternalBase. The AxInternalBase class keeps track of which methods have been executed to set a table field to a specific value.

а также
Как часто вы кастомизируете стандартные сервисы номенклатур. (!)
axStart: InfoPath with default AIF web services (!)
dax-lessons: 3 Clicks to generate AXBC code
dax-ideas: Creating a SalesOrder through .net applications or BC classes
parm-метод для AxBC-класса
Кастом поля и AIF
Preston.Larimer: Item import from CSV file made easy (Kinda)

а также по тегу axbc и тегу aif


=========================
и по прежнему остается вопрос: В чем преимущество ax-классов перед непосредственной работой с таблицами?

в ходе обсуждения выявлены следующие вкусности axbc-классов:
1. удобство для программиста для использования во внешних системах
2. автоматическая "подмена кода" в некоторых заранее прописанных местах
3. инструменты для генерации классов-оберток.

только в чем преимущество внутри Аксапты то?
Например, для работы с журналами внутри Аксапты есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
= и классы JournalTableData, JournalTransData, journalStactic.
= и куча классов типа LedgerJournalTransUpdate* и даже локализаторское семейство LedgerJournalCreate*
= и классы LedgerJournalTransType в зачаточном состоянии (причем LedgerJournalTableType отсутствует)
= и axLedgerJournal*

Чуть проще для SalesTable. Есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов
= и SalesType*
= и axSalesTable

В чем преимущество каждого из подходов? Когда и какой применять?

[erudit]

Цитата:

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

Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать?

К сожалению, подтвердить свои слова публично доступной документацией не могу. Я много лет работаю с AIF, также общался с людьми из Микрософта которые создавали Axd-framework и AxBC-классы, на основе этого и мои выводы, но возможно я чего-то тоже не знаю.

[gl00mie]

Цитата:

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

В чем преимущество ax-классов перед непосредственной работой с таблицами?

"Управление из одной точки", отсутствие явных завязок на бизнес-логику, определяющую взаимозависимости полей, в фиговой туче мест приложения, где нужно работать с таблицей (соблюдения принципа DRY, пользуясь другой терминологией). За счет этого при необходимости изменить эту логику достаточно поправить один класс вместо десятков мест в коде. Код инициализации записи максимально упрощается: накидали известные значения полей (причем в произвольном порядке!), дернули один метод - и готово.

Цитата:

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

в ходе обсуждения выявлены следующие вкусности axbc-классов:
1. удобство для программиста для использования во внешних системах
2. автоматическая "подмена кода" в некоторых заранее прописанных местах
3. инструменты для генерации классов-оберток.

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

Цитата:

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

только в чем преимущество внутри Аксапты то?

4. Код, работающий с таблицами, намного меньше завязан на бизнес-логику, связанную с той или иной таблицей, он намного более унифицирован.
5. При необходимости начать заполнять новое поле в зависимости от других полей во всех местах, где идет создание записей в таблице, достаточно поменять один класс - не надо менять десятки мест в приложении, где об этом поле раньше никто не знал (опять же принцип DRY, снижение стоимости сопровождения).
6. Это, по-моему, очень важно: методы initFromXX могут давать разный результат в зависимости от последовательности их вызова! При реализации AxBC-класса вам вам волей-неволей приходится продумать единую систему приоритезации зависимостей полей. Это сложнее, но зато уменьшает вероятность того, что вроде бы один и тот же код будет работать иначе в разных местах приложения просто из-за разного порядка вызова методов initFromXX.

Цитата:

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

Например, для работы с журналами внутри Аксапты есть:
= и непосредственная работа с таблицами через initFrom* и переопределение (overload) системных методов

Ничем не отличается от работы с любыми другими таблицами - со всеми описанными выше проблемами.

Цитата:

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

= и классы JournalTableData, JournalTransData, journalStactic.

Не более чем код, реализующий общие моменты работы с журналами: ваучеры, номера журналов, итоги по строкам журналов в шапке, блокировки... В общем, ничего из того, что делают классы AxBC.

Цитата:

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

= и куча классов типа LedgerJournalTransUpdate* и даже локализаторское семейство LedgerJournalCreate*

Слишком узкоспециализированы

Цитата:

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

= и классы LedgerJournalTransType в зачаточном состоянии (причем LedgerJournalTableType отсутствует)

И ничего он не отсутствует Это уже ближе к теме, но все же недоразвито.

Цитата:

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

= и axLedgerJournal*

Почти ничего не отличается от "голой" обертки, генерируемой мастером. Еще, наверно, стоило упомянуть семейство LedgerJournalEngine: раньше эти классы были жуткой смесью бизнес- и презентационной логики, к тому же работавшей строго на клиенте: они управляли и заполнением одних полей при изменении других, и доступом на редактирование всей текущей записи или отдельных полей, т.е. заведомо предполагалось, что курсор связан с datasource'ом и это предположение почти нигде не проверялось. Сейчас отчасти эти косяки исправлены, но остались те же "родовые проблемы", что и при использовании initFromXX: результат очень сильно зависит от порядка заполнения полей и дергания различных методов класса, плюс идея type-классов, как всегда, реализована не до конца: в базовом классе остался вагон и маленькая тележка мест, где явно прописан тот или иной тип журнала, вместо параметризации логики и перегрузки параметрических методов в классах-наследниках. И опять получается, что если в десятках мест создается журнал определенного типа, а потом в нем надо заполнять новое поле, то надо идти и править одинаковым образом эту хренову тучу мест, а если это стандартный функционал, то проделывать эту работу снова при любом крупном обновлении приложения.

Цитата:

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

В чем преимущество каждого из подходов? Когда и какой применять?

Провокация какая-то Я лично не готов писать руководства в стиле Best Practices, могу лишь сказать, к чему пришел на собственном опыте после нескольких лет разработки: если речь идет не о контрактной работе по реализации разовых модификаций, то в долгосрочной перспективе предпочтительным видится подход с использованием AxBC-классов. Он сложнее в реализации, требует фиговой тучи промежуточного кода (который, впрочем, можно во многом сгенерить мастером), требует выворачивания на изнанку привычной логики работы методов initFromXX (там изменили одно поле - и каскадом поменялась куча других, тут надо описывать изменение каждого отдельного "другого" поля в зависимости от возможных изменений кучи "исходных" полей). Но в общем и в целом он существенно снижает стоимость поддержки приложения. А при реализации модификаций, если речь, опять же, не идет о разовой контрактной работе, нужно в первую очередь думать о перспективах поддержки, а не о стоимости решения текущей локальной задачи. Причем в стоимость поддержки входит как стоимость возможного изменения кода в будущем, так и стоимость его переноса на новые service pack'и и новые версии приложения. Более того, опять хотел бы вернуться к процитированному фрагменту из "What's New - Technical in Microsoft Dynamics AX 2012 for Development": в следующей версии штатно будет реализована возможность редактировать данные в Excel - то, о чем мечтает, по моим впечатлениям, 95% пользователей Аксапты, особенно работающих с финансами. Эта возможность напрямую будет зависеть от наличия и корректности реализации AxBC-классов, так что их реализация и использование сейчас - это еще и большой задел на будущее. Но, разумеется, в определенных условиях (таблица используется лишь в нескольких местах приложения, либо нужно сделать простое решение, а на разработку AxBC-классов никто не выделит бюджет, либо все уже слишком запущено, и на рефакторинг всего существующего кода никто не выделит бюджет) придется использовать лучшее из имеющегося либо создавать "простые" initFromXX-методы.

[Zepp]

Цитата:

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

... Присоединюсь к Zabr и спрошу - а может где-нибудь есть документация для чего ax-классы сделаны и как с ним работать? ...

Есть здесь:
APIs in the Standard Application
http://msdn.microsoft.com/en-US/library/aa873132.aspx
Application Integration Framework Overview
http://msdn.microsoft.com/en-us/library/bb496535.aspx

Также в книгах:
"Inside Microsoft Dynamics AX 4.0" Part II Chapter 9,
"Inside Microsoft Dynamics AX 2009" Part III Chapter 17.

[gl00mie]

Я тут в блогах увидел интересную сравнительную таблицу для выбора оптимального метода хранения и отборки товара на складе в зависимости от ряда параметров:

Так вот, чтобы ответить на поставленный вопрос:

Цитата:

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

когда именно эффективнее использовать одно, а когда именно другое

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

[Maximin]

Эх, интересное обсуждение прошло мимо в угаре работы...
Вставлю свои 5 копеек и попробую ответить на этот вопрос:

Цитата:

Т.е. можно ли использовать initFrom из axBC-классов? и наоборот, можно ли использовать axBC из InitFrom?
какие ограничения? при каких условиях это допустимо, а при каких нет?

В качестве продолжения идей, описанных gloomie (я полностью согласен с ним), считаю, что старый подход initFromxxx стоит использовать в процессе рефакторинга и "разрыва" порочной практики их использования и только из самих axBC в качестве готовых "наборов" для инициализации каких-то полей. Другое дело, что делать этот рефакторинг и переработку достаточно эффективно, и не думая о проблемах последующей миграции на новую версию/обновление, может только сам вендор (aka Microsoft). Так что для разработчиков, работающих уже на конкретной версии системы, думаю, стоит ограничиться "нераспространением зла" и использованием только нового API, не трогая legacy.

Далее. Расписывая прелести axBC, gloomie не счел достойным упомянуть, что при реализации конкретной необходимой функциональности, стройное дерево зависимостей инициализации полей, одну ветку из которого нарисовал mazzy, зачастую начинает обретать петли. Так бывает, когда задача ставится таким образом, что для окончательного определения значений конкретного поля, приходится сделать один "оборот" по такой петле, порой, даже насильственно перезаписывая уже единожды заполненное поле. А раз так - то прозрачная схема метода setTableFields уже становится не такой уж и прозрачной, Так, забавна ситуация, когда в пришедшей по AIF записи какое-либо из полей заполнено неправильно (т.е. значение-то корректное, но в сочетании с другими полями - нет). Существующая реализация AIF такое поле уже перезаписать штатной обработкой не сможет, setField, вызываемый в процессе обработки записи, не будет записывать уже единожды записанное поле.

[mazzy]

Цитата:

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

Существующая реализация AIF такое поле уже перезаписать штатной обработкой не сможет, setField, вызываемый в процессе обработки записи, не будет записывать уже единожды записанное поле.

О_о!
Какие рекомендации по использованию?
я так понимаю, что стиль initFrom можно объявлять legacy и по возможности использовать axBC. так?

Можно ли попросить соображения в стиле: при таких то случаях лучше делать так?...

[gl00mie]

Цитата:

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

при реализации конкретной необходимой функциональности, стройное дерево зависимостей инициализации полей, одну ветку из которого нарисовал mazzy, зачастую начинает обретать петли. Так бывает, когда задача ставится таким образом, что для окончательного определения значений конкретного поля, приходится сделать один "оборот" по такой петле, порой, даже насильственно перезаписывая уже единожды заполненное поле.

А можно пример такой ситуации с реальной таблицей и реальным полем, если только это не фин.аналитика? Изначально, как пишется везде в руководствах, задача AxBC-классов - подтягивание значений по умолчанию для одних полей в зависимости от тех или иных комбинаций значений других полей, заданных "извне". Если в заказе выбирается "счет на", то по нему можно автоматом подтянуть значение кода клиента, но если оно уже задано "извне", то нечего его перезатирать - это просто не входит в обязанности AxBC-классов. Если кто-то указал "неверное" значение поля, то это его право, но вылавливаться это должно на уровне validateField() или validateWrite(), а никак не на уровне класса, который должен подтягивать значения по умолчанию. Да, при импорте данных возникает сложность с тем, чтобы отличать, скажем, пустое значение и "отсутствие значения" (т.е. ситуацию, когда значение поля не надо задавать "извне", чтобы тот же AxBC-класс мог подтянуть корректное значение), но это уже немного другая тема. В том же .NET-е вполне себе справляются с такими ситуациями, успешно различая, когда задано пустое значение параметра и когда значение параметра "отсутствует".

Цитата:

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

Так, забавна ситуация, когда в пришедшей по AIF записи какое-либо из полей заполнено неправильно (т.е. значение-то корректное, но в сочетании с другими полями - нет). Существующая реализация AIF такое поле уже перезаписать штатной обработкой не сможет, setField, вызываемый в процессе обработки записи, не будет записывать уже единожды записанное поле.

По-моему, это совершенно правильное поведение: если внешняя или внутренняя программная логика сочла нужным установить определенное значение поля, то нечего его перезаписывать, "решая" за эту программную логику, как правильно. Ошибка, если она и возникнет, должна, по-моему, решаться по факту на уровне этой программной логики.
Не везде такой подход применим, конечно, например, какая-нить настройка фиксированной аналитики в проверке аналитик для счетов ГК, из-за которой молча могут перезатираться аналитики в проводках по этим счетам, в эту идеологию явно не вписываются.

[Maximin]

Цитата:

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

я так понимаю, что стиль initFrom можно объявлять legacy и по возможности использовать axBC. так?

Можно ли попросить соображения в стиле: при таких то случаях лучше делать так?...

1. Да. Это позволит получить правильное поведение системы при интеграции (использовании AIF), т.е. в деле пресловутый DRY; единый для многих таблиц и более доступный для обобщения API, хоть один раз и надо будет потрудиться для полного понимания механизма. Другое дело, что при этом довольно много стандартного функционала в системе УЖЕ использует старый способ. Надо как-то жить с этим. Переделывать, я повторюсь, вряд ли кто-то себе позволит, разве что есть много простаивающей рабочей силы. Опять же, в свете AX2012 это будет мартышкин труд - слишком велики изменения. Всё, что я писал в предыдущем посте, про рефакторинг и т.д. - это взгляд с точки зрения "как надо было бы сделать по фен-шую".
2. Что же касается реальной разработки, то тут варианта 2:
2.1 "Чистый новый проект" - делаем все на новых классах, за initFromxxx - бьем по рукам, параллельно допиливаем axBC (может быть, используя initFromXXX, правда, очень сомневаюсь, что оно там пригодится, заполнение полей делается несколько по-другому), т.к. из-за использования в стандарте старых подходов, чего-то будет неминуемо не хватать. На выходе - имеем допиленный API и сразу "искаропки" работающий AIF, заказчик, решивший внедрить ESB, или прикрутить свой Web-магазин счастлив.
2.2 Проект, в котором много собранного/собирающегося из кучи уже внедренных решений. Ну, что тут сказать - знающий, да содрогнется. В этой бочке меда уже есть изрядная толика дёгтя. Конечно, смотря что собиралось. Но если туда добавится еще ложка - вряд ли ей станет сильно хуже. Останавливать желающего поиметь experience это не должно. Но если есть хотя бы отдаленная перспектива взаимодействия через XML с внешними системами, переносимые доработки должны быть подвергнуты тщательному исследованию на предмет переделки на API axBC. У меня уже был опыт адаптации уже запущенного решения для нормальной работы с AIF, и я скажу, удовольствие это сильно ниже среднего, учитывая, "удобство" отладки при потреблении Web-сервисов AX внешними системами. Т.е. напилено было много чисто "по старому", и для внесения всего этого в новую схему, хотя бы в деле простого создания/редактирования записей, пришлось много потрудиться.

В целом,

Цитата:

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

в долгосрочной перспективе предпочтительным видится подход с использованием AxBC-классов

[Maximin]

Цитата:

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

По-моему, это совершенно правильное поведение: если внешняя или внутренняя программная логика сочла нужным установить определенное значение поля, то нечего его перезаписывать, "решая" за эту программную логику, как правильно. Ошибка, если она и возникнет, должна, по-моему, решаться по факту на уровне этой программной логики.

По-моему, это не всегда верно и допустимо.
Внешняя система не может или не должна знать некоторые из параметров, требуемые для полностью корректного заполнения всех полей записи. В самом деле, например, если у вас b2b взаимодействие, то должен ли ваш клиент/поставщик знать, к примеру, его группу цен? Ему главное - чтобы его заказ пришел к вам, а если ваша система будет по любому чиху отвергать его заказ, нетерпимо относясь к несколько неверно заполненному запросу, вы потеряете клиента. Так что система пр работе с внешними запросами должна допускать некий "люфт" в данных - их некоторую неполноту, автоматически исключая/корректируя внешние данные. Не будете же вы отвергать создание нового заказа из Web-магазина, из-за того, что формат адреса или телефона не соответствует заданному?
Что касается "петель", то реальный пример как раз и был связан с тем, что извне пришло пустое значение, и требовалось его переопределить, причем, в зависимости от других значений по умолчанию. А после переопределения, оно само начинало влиять на эти другие значения. Что-то вроде той же ценовой группы и группы скидок, завязанной из-за специфической схемы ценообразования на те же ценовые группы (для некоторых ценовых групп скидки были неприменимы). Сами понимаете, что вытаскивать "наружу" ценоообразование Аксапты мало того что сложно технически, но еще, зачастую, и крайне нежелательно по маркетинговым соображениям.

[gl00mie]

Цитата:

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

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

Разумеется! И какие фин.аналитики на него повешены, и какой код у его адреса доставки (если, допустим, адресам какой-то уникальный идентификатор присваивать), и с каким типом должен заказ создаться, и еще кучу всего контрагент знать не должен - и не должен указывать это в той информации по заказу, которую он присылает! Именно для этого и нужны во многом AxBC-классы - подтягивать значения по умолчанию для тех полей, которые не заполнены извне.

Цитата:

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

Так что система пр работе с внешними запросами должна допускать некий "люфт" в данных - их некоторую неполноту, автоматически исключая/корректируя внешние данные.

Тут, по-моему, идет подмена понятий: указание "пустых" значений и не указание значений вовсе. Проводя аналогию с СУБД, надо отличать пустые строки и нулевые значения от NULL, и тогда все встанет на свои места. Если пришло пустое значение, а оно недопустимо, то данные ошибочны. Если пришел NULL, а мы знаем, чем можно заполнить поле, то все в порядке, такие "неполные" данных мы успешно обработаем (наверно ).

Цитата:

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

Не будете же вы отвергать создание нового заказа из Web-магазина, из-за того, что формат адреса или телефона не соответствует заданному?

Ну как сказать... зависит от того, как организовать взаимодействие с контрагентом. Если через web-интерфейс сайта вы не можете отправить заказ, потому что указываете контактный телефон или email не в том формате, в каком просят, значит ли это, что интернет магазин по такой пустяковой причине отвергает ваш заказ? Причем магазин даже не знает, что вы пытаетесь кривые данные отослать - это Java-скрипты в браузере на вашем собственном компе отрабатывают. А если такой же результат вы получите в ответ на запрос к веб-сервису этого интернет-магазина, то что изменится? Или другой пример, который мне немного ближе: работаете вы с факторинговой компанией, которая вам оплачивает 80-90% от суммы ваших отгрузок клиентам не через 30-60 дней, как прописано у вас в договоре с клиентом, а на следующий же день - за определенные комиссионные, разумеется. Вы им каждый день выгружаете электронный или бумажный реестр документов, при необходимости сдаете стопки копий фактур, они их у себя в систему заводят, обрабатывают... И вот бывает, что одна факторинговая компания готова работать даже с документами, у которых специально для этой компании сформированный штрих-код не читается (на такой случай сидят девочки-операторы, которые вбивают информацию по документу вручную, а не простым сканированием ШК). Правда, за обработку каждого такого документа с вас берут на порядок больше, чем в случае, когда данные нормально считались по ШК, но это мелочи. А бывают и другие компании, которые мало того, что хотят получать реестры документов в своем формате, но еще и требуют, чтобы вы для них ООО "Пупкин и компания" именовали не иначе, нежели Пупкин и компания ООО (в другом порядке и без кавычек - фиг знает, может, у них какой-нить кривой импорт из csv-файлов используется), в противном случае никакие документы они не примут и финансировать ваши отгрузки не станут. Вот и получается, что обе компании сидят на мешках с деньгами, но одна проявляет гибкость, чтобы деньги эти в дело пустить, а другая - упирается рогом, потому что "формат не соответствует заданному". В общем, каждому свое...

Цитата:

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

Что касается "петель", то реальный пример как раз и был связан с тем, что извне пришло пустое значение, и требовалось его переопределить, причем, в зависимости от других значений по умолчанию. А после переопределения, оно само начинало влиять на эти другие значения. Что-то вроде той же ценовой группы и группы скидок, завязанной из-за специфической схемы ценообразования на те же ценовые группы (для некоторых ценовых групп скидки были неприменимы). Сами понимаете, что вытаскивать "наружу" ценоообразование Аксапты мало того что сложно технически, но еще, зачастую, и крайне нежелательно по маркетинговым соображениям.

Поскольку специфика вашего ценообразования мне неизвестна, судить о реализации соотв. алгоритма не берусь, хотя, по-моему, его можно было бы все же сделать нерекурсивным...