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