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

Даже если ну никак - ладно, я смирюсь с такой кривотой и буду последовательно ставить все обновления, решая на каждом этапе конфликты. НО, меня интересует следующая ситуация (сразу оговорюсь, я не знаю 1С от слова "вообще", поэтому опишу ситуацию на псевдоязыке):
В основной конфигурации сторонними разработчиками написан класс B, который является потомком класса А (он есть в старой конфигурации поставщика). Класс А имеет публичные (никакой инкапсуляции, только хардкод) поля "name" и "surname". Где-то в коде этот класс (В) используется, например, выводится "surname". Ставлю обновление - в классе А поле surname удалено. При этом весь остальной код в новой конфигурации поставщика, естественно, использует обновленный класс А, чтобы корректно работать (ведь релиз официальный). Конфликтов в этом случае не будет: класс А успешно перекочует с полями из новой конфигурации поставщика, наш класс В, написанный в отдельном файле, будет тоже успешно перенесен. Проблема только в одном: как только мы начнем использовать вывод "surname" из объекта класса В где-то в своем коде, все упадет))
Иными словами - с какой вероятностью может возникнуть ситуация, что введенные производителем изменения нужно будет адаптировать под написанный собственноручно (не мной) код? Потому что решить конфликты - это одно, а вот чтобы все работало потом - это другое