Многим известен алгоритм кастомизации обмена с 1С.
Создать свою страницу в админке
Разместить на ней кастомный компонент обмена sale.export.1c
Переписать \CSaleExport::ExportOrders2Xml
К сожалению, все вызовы в этом классе -- статические и делаются через self:: Например, ExportOrders2Xml вызывает getXmlContragents как self::getXmlContragents. То есть, если даже мы унаследуем класс CSaleExport и переопределим getXmlContragents (не трогая огромный ExportOrders2Xml) то вызываеться будет именно старая версия getXmlContragents. Собственно идея: чтобы облегчить изменение этого класса все self:: вызовы достаточно заменить на static:: (LSB -- http://php.net/manual/ru/language.oop5.late-static-bindings.php)
Раз уж переходим к ООП в компонентах, то давайте делать и следующие шаги в этом направлении. Похоронили component.php, покусимся и на .parameters.php, .desсription.php. Ведь фразы вроде “Есть возможность наследования компонент” не выдерживают критики. Да, когда нужно создать похожий компонент, мы копируем не три файла, а всего два (+ не забываем про шаблоны). Почему бы не сделать в CBitrixComponent два новых метода - getDescription и getParameters, которые бы заменили эти старые добрые процедурные файлы?
P.S. К слову о шаблонах - почему бы не давать компоненту пользоваться шаблонами родительского компонента?