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

[Maximin]

Цитата:

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

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

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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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