А вот интересно, как при сертификации приложения борятся с ошибками и предупреждениями Best Practices, вылезающими на стандартном приложении? Не править же стандартное приложение только ради того, чтобы при компиляции измененных на твоем слое объектов не вылезали "чужие" ошибки BP? См. также
Проверки Best Practices только для объектов на текущем слое
Или вот, к примеру, \Classes\SysBPCheckClassNode\checkRunBaseImplementation блюдет возможность классов-наследников RunBase переключаться между клиентом и сервером при выполнении prompt() и
ругается, если у класса свойство RunOn отличается от Called from. Но пардон, ведь есть класс-наследник RunBase, у которого выставлен, к примеру, RunOn Server, а ты наследуешь свой класс от него, ты же в наследнике никак на это свойство не можешь уже повлиять. Так что эта проверка BP должна по идее ругаться только на тот класс-наследник RunBase, у родительского класса которого RunOn еще равно Called from, а она вместо этого ругается на все семейство классов, производных от класса-"нарушителя". Это я к чему: есть, к примеру, класс LedgerJournalCheckPost, наследник RunBase, у которого на sys-слое выставлено RunOn Server, и вот создаешь ты производный от него класс разноски журналов ГК, в котором свойством RunOn управлять уже не можешь. И что, теперь твой класс должен по жизни вылезать в списке нарушителей BP?..