Доброго времени суток!
Имеется много баз предприятия, по которым уже сделаны до меня доработки от стандартной конфигурации. Также мне еще предстоит доделывать/переделывать свои доработки. В связи с тем, что доработок очень много и я уже в них теряюсь, не говоря уже о тех, которые делал не я возникают вопросы:
1. Где(Как) лучше всего хранить доработки/отличия от стандартной конфигурации 1С? Я думал может в отдельной конфигурации, чтобы потом обновил стандартно, обновил конфой с доработками и все Я прав?
2. Как тогда создать отдельную свою конфигурацию включающую только отличия от стандартной, чтобы не иметь проблем при обновлении?
3. Да и вообще очень интересует опыт обновления доработанных конфигов.



З.Ы. Хотя сам программист на С/С++, программированию в 1С только обучаюсь, так что не ругайтесь, если что

Как вы это себе представляете? Документ такой-то, строчка такая-то, изменил А на Б?

Есть конфы для учета обновлений, но лично я ними никогда не пользовался. ИМХО: каждый раз нужно всё анализировать, тем более, что сегодня можете с конфой работать вы, завтра я, а послезавтра снова вы.

Где-то просто встречал такую идею, что доработки хранить в отдельной конфигурации. И накатывать сначала стандарт, потом доработки...

Просто когда доработок много, а еще и куча в разных базах, а они еще и отличаются друг от друга - у каждого может быть свой вариант, запомнить все и не ошибиться бывает довольно трудно. Да и обновление выполняется просто очень и очень долго.
Что тогда делаете Вы?

Всё анализирую. Всегда.

Проблема еще и в том, что не всегда все доработки нужно переносить. Иногда 1С реализует в новых релизах то, что сделано Вами. При переходе на УПП 1.3, например, мы натянули ее на нашу базу и установили ее паралельно с основной пользователям, которые уже смотрели что им нужно переносить из доработанной УПП 1.2.

Вывод - без тщательного анализа - никак. Да и доработки редко ложатся строчка в строчку на новый релиз....

Нужно как можно подробнее коментировать в коде то, что добавлено/изменено и стараться создавать свои объекты, а не изменять существующие.

Однажды провела подробный анализ и составлен перечень наших изменений в типовых документах, справочниках, глобальнике и т.д.
Теперь стараюсь поддерживать его в актуальном режиме, получается не всегда, т.к работает нас несколько человек,
При обновлении он все-равно помогает - некоторые вещи обновляю до типовой, потом вношу наши изменения из писка, но во многих местах только ручками
А вообще совет тем, у кого конфигурации девственны и чешутся руки их корячить: лучше создать свой отдельный док, спр, обработку и т.д. - не усложняйте себе жизнь

nysysimara, а если баз 10 и все разные?

есть 10 накоряченных баз, нужно в каждой внести изменения до последней типовой конфигурации?

конечно проще застрелиться
но думаю задача осуществимая

или Вы что-то другое имеете ввиду

Я имел ввиду, что с одной базой, с которой работаешь сам (ну или максимум несколько человек из одного отдела) - записывать изменения может и представляет какую-то ценность. Но если работать приходящим программистом - то замахаетесь записывать .

ну так только анализ,
свои изменения обязательно обозначать ремарками

ещё хотела посоветовать не спешить с обновлением при каждом новом релизе (если там нет важных изменений), подождать, и только через 2-3 релиза обновляться,
но для приходящего программиста, если оплата почасовая, лучше приходить по-чаще(с каждым новым релизом)

Я 16 баз с разными изменелиями за 2 часа в одной фирме 2 раза обновлял. (7.7)
Но с выходом налогового кодэкса на эту фирму забил.


Неважных релизов практически не бывает.

В последнее время это да.

По теме. Пытался я как то это делать но очень быстро забил на это ведение списка изменений. Пишу всегда и везде комменты. Свои реквизиты стараюсь определять префиксами. Потом анализирую.

свої коменти + префікси на нові об*єкти і реквізити

Зачем что-то "хранить"?
Помогает подробный отчет о сравнении конфигураций.
Подсел на это еще вначале, во франче.
Стребуешь с клиента МД файл, обновишь на него соотв типовую, печать самым мелким шрифтом... пока до клиента доехал в гор транспорте - садись и пиши с листа.
В 8 стало гораздо удобнее - таблица с картинками, если еще не полениться и посворачивать по объектам - очень удобственная вещь получается.
Еще, даже "адын", работаю с Хранилищем конфигурации. Само по себе удобно, а если писать комменты при сохранении объектов - то и История получается довольно информативная.

Лично я где в конфе что-то меняю, оставляю свой комментарий, при обновлении делаю копию в ней запускаю глоб. поиск своего комментария, и мне вываливаются все ссылки что я и где делал. При объединении анализирую что лучьше заместить объект и в него вставить изменения (копированием) из копии или не изменять и добавить новые изменения вручную опять же из копии. Лучьшего не придумал, вот так...

Поделюсь своим опытом. Работала только в 7.7. но думаю что в 8 должно быть с этим меньше проблем, все-таки платформа посовершеннее.
Когда я работала фикси, у меня в каждой базе был каталог md, в нем я сохраняла все файлы md, с указанием даты когда изменение было сделано. Очень помогало при нахождении всяких косяков потом. Если изменения делала не я (было и такое), то человек все делал точно так же по моей инструкции.
Когда во франче обслуживала разных клиентов, то у меня просто были md всех конф, всех релизов, ну как по бухии, то минимум 20 последних. У клиента я определяла к какому релизу ближе тот что стоит у клиента, несмотря на то что стоит в переменной с номером релиза и на то что говорит клиент. Верим только своим глазам. Подробными коментариями я не обзаводилась, считаю что в 1с это ни к чему, просто достаточно внятно называть переменные, согласно их назначениям. Чужие комментарии мне редко помогали, т.к. снова верим только своим глазам, код 1с достаточно прозрачен. Ну и сохраненный старый md всегда обязательно. Не раз помогал оставленный предыдущим программистом.