Каталог решений - Как не надо изменять конфигурацию или Как облегчить жизнь при обновлении

Предыстория:

Как-то я устроился на новую работу, в помощь и поддержку бухгалтерии. Стояла на предприятии Бухгалтерия 3.0.18.5.

Контора перешла с 7.7 на самую новую, на 3.0 соответственно. В новую загружены остаточки на 2013, ну и доки за начало 2013. Ну что, нормальная практика.

Но как я глянул на конфу, немного офигел. В ней аж 3 Приходника,  3 Расходника, и 3 Авансового, ну и так еще пару-тройку документов, а сделано это потому, что у конторы имеются 3 подразделения. Собственно, одно основное и два обособленных, а, как известно, по законодательству для «обособок» нужно вести свою кассовую книгу (а почему бы не купить сразу «Корпоративную версию», она же из коробки поддерживает учет по обособленным).

И всю эту … надо еще и обновлять.

История:

Анализ изменений, а изменений тут было до…

1. В план счетов добавлена предопределенно еще пачка счетов, также 4-е субконто, притом на счетах расчетов с контрагентами зачем-то добавлена ставка НДС. НИКОГДА, слышите, НИКОГДА не добавляйте в конфигураторе счета в план счетов и вообще лезть к предопределенным элементам это кощунство. Если что-то нужно, добавьте в пользовательском режиме, остерегайтесь изменения структуры плана счетов, типа добавления еще одного субконто. Кстати, если удалить предопределенный элемент, в пользовательском режиме объект просто пометится на удаление.
2. Все созданные объекты не привязаны к половине перегруженных событий, или привязано не до конца или не все. Вообще добавлять документы в конфу не стоит, старайтесь обойтись типовым функционалом. Если все-таки без этого не обойтись, постарайтесь не привязывать созданные объекты к типовому учету. Посмотрите на документ, на основе которого вы делаете свой, и учтите, что функционал документа описывается не только документом, там еще участвуют «перегрузка событий», «Функциональные опции», «общие команды», кое-какие «регистры сведений» типа «ПервичныеДокументы», и, конечно, есть ссылки в реквизитах документов типа «ДокументОснования».
3. И т.д.

Решение (Выводы):

1. Если вам посчастливилось выбирать продукт для перехода или вообще для запуска с нуля, подойдите к выбору очень внимательно. Например, если организация только оказывает услуги и работают там 3 калеки, зачем им брать УПП? С более крупной конфигурации сложнее перейти на более простую. В общем, семь раз отмерь — один отрежь. Не знаю, как скажут гуру, но мое мнение: управленческий учет желательно отделить от бухгалтерского. То есть бухгалтерский в отдельной базе, управленческий в отдельной, так же с зарплатой, и уже либо агрегированные данные передаешь в разные базы, либо документы. Свести к минимуму обмены. Где возможно отказаться от распределенной, использовать, например, RDP.
2. Старайтесь избегать изменения типового механизма учета, например: делать желательно с помощью внешних обработок, заполнялок, и вообще изучите типовой функционал, возможно, то, что вы делаете, уже сделано, а как говорится, на фига нам велосипед.

Например, нужно сделать дополнительные данные в документе или в справочнике. Делаешь с помощью механизма «доп. реквизиты объекта» и внешнюю печатную форму или обработку заполнения с формой заполнения этих реквизитов.

Если все-таки приходится изменять стандартный механизм учета, то желательно весь код вынести в общий модуль, например: «РБ_Доб», и в модулях объектов использовать одну-две функции. И, самое главное, это КОММЕНТАРИИ, надо писать код не для себя, а для других, и вообще пишите красивый код:

Так кодить нельзя:

с=0;
пока с

Так кодить можно:

с = 0;
Пока с < 1000 Цикл
               с = с + 1;
КонецЦикла;

Все созданные объекты именовать по какому-то правилу, используйте префикс, например: Документ.РБ_ПутевойЛист, Справочник.РБ_Тарифы.

Пользуйтесь механизмом Подсистем, удобная штука.

Еще что вспомню, дополню.

ЗЫ: Коллеги, дополняйте, комментируйте…