Начало ранее в постах.   Методологии по расширениям много, в интернете есть все, а как применять на практике?   Мало кто понимает суть расширений в 1С в контексте текущих доработок. Оно даёт изменить код поставщика, но оно не даёт вам право, убивать этот код. Знайте одно, поставщик не знает о вас ничего, и ему пофиг что у вас там написано. Завтра он перечеркнет лично созданный алгоритм и напишет новый, а ваши старания пойдут в топку, а к тому времени вы уже забудете про свои старания.   И еще, расширения бывают большим злом в мире программирования 1С, например в РИБ'ах, когда твой код из расширения меняет алгоритм запуска или план обмена, он приходит последним при обновлениях подчинённых, и просто рушит всю твою идиллию. А иногда это расширение просто не может примениться и падает во внутреннюю ошибку платформы, после чего приходится изучать часами тех журнал и применять все знакомые тебе фокусы.   По факту и расширения получаются не удел? При должном понимании, этот инструмент имеет большие возможности.   В первую очередь, ни при каких обстоятельствах не меняйте алгоритм поставщика. Если это необходимо, то переспите с этой мыслью хотя бы ночку, и завтра у вас будет другое решение. Этим решением может стать аккуратная врезка в код из одной строки, или изменение входящих данных процедуры, а может вы просто сможете подменить результаты выполнения процедуры.   Второе, если ваша задача никак не влияет на работу алгоритмов поставщика, смысл его пихать в расширение? Потом это может стать причиной задержек при обновлениях. Вообще в чем сложность обновлений. Представьте, у вас три варианта кода, вариант старого релиза, вариант нового релиза, и ваши надписи. Теперь их нужно соединить в один универсальный четвертый рабочий код. Чем больше изменяли, тем дольше будете сидеть сращивать и вероятность ошибки будет намного больше, потратите время на отладку, да и пользователь залезет через другое место, из которого вы даже не ожидали. Т.е если вы делаете собственную надстройку, свою обработку данных, или добавляете свои данные, не меняющие логику поставщика, то снимайте корень основной конфы с поддержки, и делайте что хотите со своими объектами в основной конфе, особенно касается нового плана обмена. Только старайтесь выделить эти новые объекты, показав тем самым, что это собственный код не меняющий вокруг себя ничего. Корень потом просто объединить с поставщиком, а ваши наработки проще проверить в основной конфе встроенной проверкой кода. Там еще целый ряд причин, например, та же проверка расширения не понимает реквизитов из основной конфы. Или при удалении расширения можно потерять все данные расширения, знающие поймут.   Главная заповедь, не навреди поставщику, он делает свою работу, ты свою и его работа важнее.   Теперь вам приедется думать на несколько шагов вперед, не все коту масленица, учите шахматы.   Далее разберём приемчики кунг фу 1С, поговорим о самых нужных аннотациях Перед и После.