Цитата:
Сообщение от
Maximin
Внешняя система не может или не должна знать некоторые из параметров, требуемые для полностью корректного заполнения всех полей записи. В самом деле, например, если у вас b2b взаимодействие, то должен ли ваш клиент/поставщик знать, к примеру, его группу цен?
Разумеется! И какие фин.аналитики на него повешены, и какой код у его адреса доставки (если, допустим, адресам какой-то уникальный идентификатор присваивать), и с каким типом должен заказ создаться, и еще кучу всего контрагент знать не должен - и не должен указывать это в той информации по заказу, которую он присылает! Именно для этого и нужны во многом AxBC-классы - подтягивать
значения по умолчанию для тех полей, которые не заполнены извне.
Цитата:
Сообщение от
Maximin
Так что система пр работе с внешними запросами должна допускать некий "люфт" в данных - их некоторую неполноту, автоматически исключая/корректируя внешние данные.
Тут, по-моему, идет подмена понятий: указание "пустых" значений и не указание значений вовсе. Проводя аналогию с СУБД, надо отличать пустые строки и нулевые значения от NULL, и тогда все встанет на свои места. Если пришло пустое значение, а оно недопустимо, то данные ошибочны. Если пришел NULL, а мы знаем, чем можно заполнить поле, то все в порядке, такие "неполные" данных мы успешно обработаем (наверно

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