Предстоит дорабатывать БП (2.0. или 3.0 еще не решили). как более корректно вносить изменения?
Правильно ли мыслю:
1. если править формы объектов - то создавать свои
2. если добавлять реквизиты, то через регистр сведений, чтоб типовой объект (справочник. документ) оставался не тронутым
3. доработки проведения и записи - ловить перехватчиком и посылать с свои общие модули
4. отчеты, обработки, сервисы - все делать своими отдельными

1) да
2) при обновлении твои поделки не видны
3) зависит от обстоятельств
4) желательно

1) да
2) зависит от логики этих реквизитов
3) да
4) да

3) - а еще лучше подписки, если это возможно

нет
нет
нет
нет

Не обновлять, не дорабатывать

+(4) Не работать в 1с

(3) ловить перехватчиком = Подписки. Автор просто бывший лётчик видимо, перехватчики везде

летчик-адинеснег. ништяк

(7) Ну а чо? КВ-1С есть, будет ИЛ-1С =)

5. Выучить флажок "Показывать только дважды измененные".

1) Желательно не дорабатывать или программно форму менять
2) Зависит от задачи. Доп реквизиты при обновлении не мешают, зато можно использовать в типовых отчетах без доработок.
3) Зависит от задачи. Нет гарантии, что 1С тоже не добавит свой перехватчик.
4) Да, если зависит от алгоритма типовой выделять изменения.

а лучше попробуй обновить конфу с доработками и сразу все сложится: "как жить и что делать"...

Правильно вдоль и поперек допиленная конфа обновляется на новую версию ~15-20 минут. Ну за исключением если 1Сники внезапно решат туеву кучу общих функций по модулям перетаскать, тада на полдня работы.

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

+ сходу подсистемы свои выделить
делать префиксацию всех своих объектов и модулей

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

(13) скоро отменять нал учет и тогда заживем

(0) Делай всё через подсистемы.

(13) ну как всегда, экономят на выборе конфигурации и хотят от Бухии оперативный учет.

(0)в принципе на все ответить можно Да..
Но есть НО...
Формы постоянно могут меняться - свои потребуется менять тоже - вероятно.
Подписки для перехвата имеют туеву хучу подводных камней.

Я раньше делал тоже все отдельно. Но, потом перешел на модификацию типовых.
Если конфа на поддержке то эти изменения быстро показываются и вносятся.
Главное избежать накопления требуемых обновлений.
Просто если свои объекты - вы на них плюете и потом вылазиют грабли и причем бывают большие

(18)разумеются свои доработки большого плана пишутся отдельно

Дорабатывать формы не обязательно вручную. Можно и программно.
В некоторых типовых есть вызов процедур из общего модуля с передачей туда формы и т.п. Там удобно вставить всего одну строку - вызов своих процедур из своего модуля, а там программное добавление / изменение.
Делал так, обновлять было удобно и быстро.

(17)Товарищьььь!! По несчастию!!
Я тоже в Бухии делал производственный, оперативный учет и бюджетирование! Жесткач... Почти год на все... прошел год...вышла Бух 3.0...
)))

(20)разумно.
1000. Конечно сначала помудохаешся, зато потом минимум проблем

(21) готовое все равно проще переносить чем заново придумывать.

(22) там много оговорок и не всегда удобно делать, пусть даже мелкие, доработки

(23)в готовом производственном/оперативном/бюджетировании около 60% ненужного или необходимого для доработок - под себя. И так и так пилить

Я в одной конторе работал - там почти все доработки в УПП были на подписках.
Это реальная ж.опа. плюхи везде. Что бы найти - подня надо. Одних подписок было штук 30-35

(0) Принцип один: твои доработки должны представлять собой отдельные независимые подсистемы, а не вставлены в типовые объекты как изюм в булки, который при обновления надо выковыривать, а потом заталкивать.

спасибо. немного картина прояснилась. осталось пробовать.
ПС мне надо немножко общепита прикрутить в БП. щас стоит Бух7 и рарус.общепит7. в рарусе тока меню печатают, поэтому покупить рарус 8 наверно не разумно

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

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

Нужно ещё в конфигурацию добавить подсистему с несколькими подсистемами - изменено, добавлено, измененыметаданные и т.п., чтобы в конфигураторе можно было бы быстро отобрать изменённые объекты, чтобы быстро оценить объем работ по обновлению.

Личный опыт более-менее успешного сопровождения толпы конф:
1-я стадия: изучение методологии. Прям несколько дней или недель. Все форумы исследовать и ни каких поспешных решений
2-я стадия: огород из внешних обработок и по максимуму притягивание за уши к типовым механизмам
3-я стадия (если прошлые не помогли): отдельные подсистемы и ни как иначе.
Все. Сложный учет + народ с разных городов в нескольких базах 1Ц обновляются любым человеком, умеющим запускать конфигуратор

(25) Методологию читать не вариант?

(32)нет. делаем по хотелкам. Я могу предложить типовой вариант - как в типовых реализовано.
Право руководства согласится или нет.
Надо - допилем. Чем больше допилок - тем зависимее от меня. На иглу главное подсадить

(33) какой коварный человек )

(33) Знакомо... к сожалению у нас тоже столкнулся с геморроем про бюджетирование. Самодуры тянут одеяло на себя и хоть тресни. Но нам повезло, сумели доказать, что самодурственную аналитику надо вынасить в отдельную подсистему. Вынесли. Все прекрасно работает и обновляется

(0)не оптимально
код конечно лучше выносить в свои модули а в остальном...
ну сделай вместо реквизита регистр а потом удивись сколько отчетов нужно будет соединить с этим регистром

Желательно изменения в коде выводить в одну строку, с комментами, типа:

// cw014-2012
ДополнительныеВозможности.УстановитьЧегоТоТам(ЭтотОбъект);
// cw014-2012

И вести карту изменений в виде отдельного макета

(36) (0) Вместо РС или реквизита  - свойство. И типовые отчеты его "подхватят".

свойство которое свойство через ПХВ ?

ПВХ*

(40)зачем вам свойства при живом программисте? ларек-марек автоматизировать?

(38) А потом все это обновлять долго и упорно. Грустно...

(43)"при живом программисте" вот вот.

1. Да и лучше сразу управляемые (пригодится при переходе на БП 3.0, если всё же сначала 2.0 поставите, что на данный момент правильнее);
2. по возможности, но если реквизит будет использоваться в качестве измерения регистра - не прокатит;
3. Да. Обязательно наваять свои подписки на события и свои общие модули;
4. Да и обязательно иметь резервные копии (или dt-шники, из которых можно их быстро вытащить) внешних печформ и обработок: при обновлении они иногда затираются;

(40) Дельный совет.

(0) Когда сидел на поддержке старался формы вобще не трогать (обычные не управляемые). Если возникала необходимость создавал программно свою закладку с дополнительными элементами, ибо при обновлении самый большой геморой - это формы, а код в модуле при сравнении видно сразувидно. Таким не хитрым способом спасал себе нервы и экономил время.

(48) Было бы удобно, если бы в 1С был бы такой функционал:
Нарисовал дополнительную вкладку на отдельной форме, написал в форме код для обслуживания элементов формы, а потом выполнил код = ФормаОсновная.Прицепить(ФормаДополнительная, ЭлементФормы);
Правда потом придётся сделать такой метод:
Сообщить(ЭлементыФормы.Поле.ОткудаТыТутВзялся());  ;)

(49) Я для себя общий модль делал для этих целей. Передавал параметры создаваемого элемента (в том числе привязки) и контекст формы. Можно было создать элемент по образцу, чтобы ровненько было - т.е. передаю существующий элемент, и "прошу" создать похожий только на 10 пунктов ниже (левей правей и.т.д.). Свои элементы создавал с префиксом, поэтому всегда понятно, что он ручками создан... :)