Изменения в типовых конфигурациях 1C: зло или благо?

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

Работая с типовыми конфигурациями 1С:Предприятия, вы рано или поздно сталкиваетесь с необходимостью внесения в них изменений. Необходимость в изменении конфигурации может быть объективна. Но очень часто бывает и так, что в доработках нет особой нужды, а делаются они просто в угоду пользователям.

Поначалу это может быть даже интересно. Это поднимает ваш авторитет в глазах пользователей и ваших собственных глазах. Но, как говорится, аппетит приходит во время еды. Стоит только начать изменять конфигурацию "под себя", пользователи быстро входят во вкус. Их желания начинают расти как снежный ком, и скоро конфигурация, некогда бывшая типовой, может её напоминать лишь отдаленно.

До поры до времени такое положение дел может всех устраивать. Но только до тех пор, пока наше правительство не решит что-нибудь кардинально поменять в правилах учета. 1С отреагирует выпуском новой редакции конфигурации. И было бы все легко и просто, если бы ваша конфигурация оставалась нетронутой. Но теперь обновление конфигурации до актуального релиза с сохранением всех сделанных наработок - задача нудная и кропотливая.

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

В качестве примера приведу реальную ситуацию из моей практики. В 2000 году, когда моя карьера программиста только начиналась, я оказался участником масштабного проекта по внедрению конфигурации "1С:Бухгалтерский учет" на платформе "1С:Предприятие 7.7". У нас была достаточно крупная организация с филиалами, разбросанными по районам. Я работал в одном из филиалов. К тому времени каждый филиал вел учет сам по себе в разных программах, в основном 1С шестой и седьмой версий. Консолидированную отчетность по предприятию в целом получали "вручную".

Руководством было принято решение консолидировать учет в единой для всех конфигурации 1С с использованием компоненты "Управление распределенными базами данных". Первое, с чего решено было начать, - собрать всех бухгалтеров в одном месте и спросить: "Что вам не хватает для учета в этой программе?" Бухгалтерия, рассмотрев предложенную систему, выдала целый список пожеланий. Как я уже отметил, многие уже вели учет в 1С и не только знали, что система в принципе конфигурируема, но и успели уже почувствовать вкус подобных экспериментов.

Сейчас я точно знаю, что тот список "хотелок", минимум процентов на 80 состоял из совершенной чепухи, которую следовало бы выкинуть из головы. Но тогда я еще был начинающим специалистом и предпочитал, говоря словами профессора Преображенского, "молчать и слушать". Да дело было, даже не в этом. Из более опытных коллег также никто не высказался против изменения типовой конфигурации. Даже наоборот, все рвались в бой. И мне тоже было интересно, не скрою.

Это была присказка, а теперь яркий пример того, как делать не нужно.

Типовая конфигурация "1С:Бухгалтерский учет" построена таким образом, что приходные документы по различным видам номенклатуры различные - "Поступление материалов" для материалов, "Поступление ОС" для основных средств, "Поступление оборудования" для оборудования, требующего монтажа, и так далее. Одно из замечаний, высказанных относительно нового программного обеспечения, касалось как раз этого набора приходных документов. Дескать, не удобно делать приход отдельными видами документов, да к тому же еще отдельно вводить полученные счета-фактуры! Из этого последовал вывод, что взамен набору типовых приходных документов нужно сделать один универсальный супердокумент, в котором можно было бы вводить и материалы, и оборудование, и основные средства и там же до кучи ввести реквизиты счета-фактуры!

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

Проблемы начали проявляться довольно быстро. Одни изменения по цепочке влекли за собой другие. Что значит, например, заменить типовые приходные документы собственным, как поступили мы? Это значит, что документ "Запись книги покупок" и отчет "Книга покупок" автоматически перестали работать, поскольку они были предназначены для работы с типовыми объектами. Как следствие была сделана собственная "Запись книги покупок" и собственная "Книга покупок".

Подобные проблемы преследовали нас практически на всех участках учета, где были внесены изменения в конфигурацию. Добавленные субсчета (такая мелочь с точки зрения бухгалтера) влекли за собой изменения в процедурах проведения документов. Переставали работать специализированные отчеты и документы.

Но мы продолжали отважно бороться с трудностями, которые сами же для себя создавали. А от пользователей тем временем поступали все новые и новые требования, и мы все дальше и дальше перепахивали конфигурацию. В результате через пару лет такой "продуктивной деятельности" из типового функционала мы пользовались, пожалуй, только стандартными бухгалтерскими отчетами.

Проблема обновления конфигурации тоже довольно всплыла на поверхность. В 2001 году значительные изменения претерпел план счетов. Изменялись типовые печатные формы документов, появлялись изменения в правилах учета. Но эти изменения были еще не столь значительными, и мы худо-бедно, не без проблем, но все же справлялись.

Но настал 2002 год и грянул налоговый учет. Даже 1С, помнится, слегка запоздала с выпуском новой редакции конфигурации. Когда же она появилась, у нас все окончательно приуныли. Изменения были столь существенны, что реализовать всё в нашей конфигурации никто уже не решался. Ситуацию на некоторое время спас КАМИН, выпустивший свой легендарный программный продукт "КАМИН: Налоговый учет" для ведения налогового учета по налогу на прибыль в "1С:Бухгалтерии 7.7". Решили пока работать в том, что есть, но с новыми изменениями остепенились.

В 2003 году мне предложили из филиала перебраться в управление, и поручили курировать наш многострадальный "Бухгалтерский учет". Тяжелое наследие же мне досталось! Программа напоминала вселенский хаос. Это была вышеописанная ситуация - проще было начать с чистого листа. Взвесив все "за" и "против", я предложил провести реформу и вернуться к использованию типовых объектов конфигурации.

Сколько крови выпили у меня бухгалтера за это решение, это тема отдельного разговора. Меня просили вернуть приходный супердокумент и другие суперобъекты. Но я твердо стоял на своем: "Нужно пользоваться типовыми объектами!" Доработки, которые были сделаны по объективным причинам, пришлось воспроизвести снова. Но на этот раз все делалось более аккуратно, более изящно. И цель, в результате, была достигнута. Несмотря на большое количество изменений, на этот раз конфигурация все же осталась обновляемой.

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

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

Необходимость внесения изменений должна подлежать безусловному обсуждению. Приучите пользователей обосновывать состоятельность их требований. Попросите объяснить, чем они продиктованы - изменениями в законодательстве, требованиями учетной политики, приказами руководства и т. п. Это будет работать как психологический фактор. Нельзя давать пользователям думать, что вы пляшите под их дудку. Дайте им понять, что не они, а вы отвечаете за работоспособность и актуальность программы. Когда мне пользователи задают вопрос: "А что, неужели это нельзя сделать?", я им отвечаю: "Программа устроена так, что в ней можно сделать вообще всё, вплоть до того, что она станет неработоспособной. Но мы же этого не хотим?"

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