Доработка 1с предприятие. Недостатки доработки конфигураций

Ну а всем остальным, добро пожаловать под кат.

Правила и приемы доработки типовых конфигураций 1С для облегчения их дальнейшей поддержки и обновления

Итак, когда мы делаем некоторый проект (под словом «Мы» я понимаю всех людей, которые заняты в автоматизации бизнес-процессов), то надеемся, что потом он плавно перетечет в поддержку. Как правило, если все выполнено хорошо и заказчик доволен, так и происходит.

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

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

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

9 простых правил оформления модификаций в типовых конфигурациях

1. Концепция минимизации «разрушений» типовой конфигурации

Первое - это даже не правило, это некая концепция минимизации «разрушений» типовой конфигурации.

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

2. Комментирование изменений кода

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

У нас в компании мы используем следующую схему:

• В начале изменения находится открывающий комментарий (начинается со знаков //++ )
• В конце - закрывающий комментарий (начинается со знаков //-- )
• А те изменения, который выполнил разработчик, находятся в середине .

Это - обязательное правило для любых изменений.

У открывающего и закрывающего комментария указывается метка изменения . Она содержит в себе следующие составляющие :

• Префикс проекта - по умолчанию мы используем ФТО
• Доменное имя разработчика . Оно формируется очень удобно: компания большая, распределенная, и если ты разработчика не знаешь, но его надо о нем что-то спросить, можно взять его ник из этой метки, поставить справа @fto.com.ru и отправить ему письмо, чтобы таким образом с ним связаться.
• Дальше идет дата изменений . Когда изменения идут в рамках нескольких задач, эти связки комментариев могут быть вложенными одна в другую, и не всегда понятно, к какому открывающему блоку относится этот закрывающий комментарий, поэтому мы ориентируемся на дату. Кроме этого, по дате сразу видно, когда была сделана модификация: три года назад, полгода назад или вчера.
• Затем идет номер задачи , который ставится только в открывающем комментарии . Почему только там? Чтобы при глобальном поиске по номеру задачи в выборку попадало только начало изменений кода, от которого дальше уже можно вниз смотреть, иначе будет двоиться. Например, при передаче задачи на code-review очень удобно искать именно по метке.

Примеры

Вот так выглядит вставка кода:

Вот так выглядит удаление кода - мы не удаляем код полностью, мы комментируем код. За счет этого всегда видно, что было закомментировано, и в случае чего можно быстро вернуться назад.

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

Отдельное правило работает для добавления процедур, функций и глобальных переменных модулей . В этом случае закрывающий комментарий ставится на той же строке, что и ключевое слово КонецПроцедуры . Зачем это сделано? Для того чтобы было удобно переносить модификации с помощью «попроцедурного сравнения».

Здесь на картинке видно, что используя «попроцедурное сравнение» можно просто выделить эту процедуру при объединении , и она вся полностью (вместе с метками) перенесется. Или наоборот, можно снять напротив нее галочку, чтобы не переносить.

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

3. Добавление объектов верхнего уровня

Следующее правило - это добавление в конфигурацию объектов верхнего уровня (справочников, документов, регистров и т.д.).

Это правило заключается в том, что имена объектов обязательно должны начинаться с префикса. Для чего?

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

Синонимы объектов должны начинаться с префикса в круглых скобках . Это позволяет выделить наш добавленный объект в интерфейсе.

Конечно же, это очень спорное правило, и его применение нужно согласовывать с заказчиком . Наших клиентов такая схема устроила, поэтому она у нас прижилась и попала в правила. Но тут решать только вам и клиенту - надо так делать или не надо.

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

Итак, подытожим:

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

4. Добавление подчиненных объектов

Под добавлением подчиненных объектов я подразумеваю добавление реквизитов, макетов, форм и т.д. в объекты конфигурации.

Здесь нужно сразу выделить две ситуации, куда мы добавляем подчиненный объект:

• В типовой объект конфигурации
• Или в какой-то объект, который был добавлен ранее в рамках проекта.

Рассмотрим каждую из этих ситуаций отдельно.

Для добавления подчиненных объектов в типовые объекты конфигурации действуют следующие правила.

• Имена должны начинаться точно так же с префикса . За счет этого мы добиваемся уникальности имени и визуально тоже всегда понятно, что это - наш объект.

• Синоним заполняется без префикса , потому что здесь уже нет необходимости выделять наши объекты, наши реквизиты.

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

Итак, давайте подытожим, как происходит добавление подчиненных объектов в типовые объекты конфигурации:

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

А если мы добавляем подчиненные объекты в те объекты, которые были ранее добавлены в рамках проекта и уже содержат в своем имени префикс, то:

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

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

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

А теперь подытожим, как добавляются подчиненные объекты в объекты, добавленные в рамках проекта:

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

Если это правило объединить для обоих случаев и «разложить по полочкам», то получится следующая табличка:

• Новые объекты:
  • Имя начинается с префикса.
  • Синонимы - с префиксом в круглых скобках.
  • Комментарий содержит метку.
• Подчиненные объекты, которые мы добавляем в типовые объекты:
  • Имена начинаются с префикса,
  • Синоним по общим правилам
  • В комментарий ставим метку.
• А если мы добавляем подчиненные объекты в объекты, добавленные в рамках проекта, то
  • Для них никаких специальных правил не действует,
  • Но если задача другая, то в комментарий точно так же ставим метку.

5. Добавление предопределенных элементов

Следующее правило - добавление предопределенных элементов.

Здесь точно так же можно выделить две ситуации:

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

Если мы добавляем предопределенный элемент в типовой объект конфигурации ,

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

А если мы добавляем предопределенные элементы в объекты, добавленные в рамках проекта , то

• Его имя не будет содержать префикса , так как нет необходимости его как-то выделять.

Итак, если провести аналогию с предыдущей таблицей, то:

• Предопределенные элементы для типовых объектов добавляются с префиксом,
• А все остальные - по общим правилам, никаких специальных добавлять префиксов не надо.

6. Использование общих модулей и их строгая структура

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

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

Во-вторых, обратите внимание, что общие модули добавляются по правилам добавления объектов верхнего уровня (имя и синоним с префиксом, метка в комментарии и т.д.)

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

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

• ФТО_ОбщегоНазначенияКлиент,
• ФТО_ОбщегоНазначенияСервер,
• ФТО_ОбщегоНазначениеГлобальный,
• ФТО_РегламентныеЗаданияСервер
• И т.д.

А какие-то большие отдельные задачи можно (и, наверное, нужно) выносить в отдельные общие модули .

7. Использование подписок и их строгая структура

Следующее правило - это использование подписок и их строгая структура. В чем его суть?

Подписки следует использовать для обработки различных событий, связанных с типовыми объектами , таких как:

• Перед записью
• При записи
• И т.д.

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

Подписка добавляется согласно следующим обговоренным правилам:

1. Для всех однотипных событий в системе добавляется только одна подписка . Например, если мне нужно для различных справочников в событии «Перед записью справочника» задействовать свой алгоритм, то для всех этих справочников я использую только одну добавленную подписку «Перед записью справочника».
2. В источнике выделяются все объекты в рамках этого класса (например, все справочники)
3. Для добавленной подписки создается отдельный модуль, который называется точно так же (просто для удобства).
4. В основном обработчике события определяется условие, анализирующее вид объекта (вид справочника).
5. И уже в зависимости от вида объекта выполняются те или иные действия .

Могу показать на примере. Предположим, есть такая задача: при проведении документа «Авансовый отчет» делать записи в добавленный ранее регистр накопления.

Сначала мы добавляем общий модуль ФТО_ДокументыОбработкаПроведения по всем правилам.

• В качестве источника указываем ДокументОбъект (все документы);
• В качестве обработчика - наш добавленный выше модуль.

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

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

В результате, порядок действий для создания подписки такой:

• Одна подписка,
• Один общий модуль
• И ничего другого уже не надо: модуль документа остается неизменным - в «дважды измененных» он уже не покажется.

8. Редактирование форм

Следующее правило - редактирование форм.

Здесь точно так же выделим два момента, две ситуации:

• Когда мы редактируем типовые формы;
• И когда мы редактируем формы, добавленные в рамках проекта.

Первая ситуация - это редактировани е типовых форм, форм типовых объектов . Это самый спорный пункт правил. В свое время, еще во времена обычных форм, когда проекты в основном делались на УПП, у нас было много дискуссий по поводу того, что делать с формами. Какие были варианты?

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

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

В конфигурациях на базе БСП 2 (таких, как ERP, Бухгалтерия и т.д.) добавился обработчик СобытияФорм.ПриСозданииНаСервере() , который среди прочего, заходит еще и в переопределяемый модуль .

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

Кажется, что это сложно, что эта схема - громоздкая, но на деле, если все проекты делаются по таким правилам, то разработчик, получая задачу, уже сразу знает, куда ему смотреть, где что добавлять. Поэтому мне кажется, что это очень удобно.

Кроме того, в конфигурациях на базе БСП 2 переопределены еще и другие обработчики форм - такие как ПриЧтенииНаСервере(), ПередЗаписьюНаСервере() и т.д. И в этих обработчиках также можно активно использовать переопределение вызываемых процедур. Тем более что поставщиком переопределяемый модуль теоретически не меняется, и там можно без боязни конфликтов писать свой код.

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

9. Принципы работы с ролями

И последнее правило - это принципы работы с ролями.

Принципы работы с ролями заключаются в следующем:

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

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

Итак, я перечислил все девять простых правил оформления модификаций.

Дополнительные объекты и приемы, облегчающие жизнь

В заключение я расскажу о некоторых объектах и приемах, которые могут облегчить жизнь разработчику.

1. Самоидентификация тестовых баз

Первый прием - это самоидентификация тестовых баз.

Суть в том, что:

• есть некоторая константа, в которой хранится адрес рабочей продуктивной базы .
• При старте системы происходит проверка этого адреса : соответствует он адресу рабочей базы или не соответствует.
• И если не соответствует (база не рабочая), то происходит замена заголовка системы .

На скриншоте показано, как это выглядит. Это особенно полезно тогда, когда у разработчиков (или у консультантов) открыто много баз (рабочая, тестовая, разработческая и т. д.) и они могут нечаянно ошибиться и поменять данные в рабочей базе. А если заголовок изменен, то уже «на автомате» - глаза в левый верхний угол, смотришь, что это за база - ага, тестовая, можно менять.

Таким образом, мы делаем изменение данных в информационных базах более безопасным.

Кроме того, проверку значения этой константы полезно также применять при выполнении некоторых регламентных заданий . А именно:

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

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

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

2. Обработка инициализации

Следующий прием - обработка инициализации.

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

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

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

На схеме этот порядок работы показан так:

• Старт системы
• Сравнение версии константы с версией обработки .
• Если не совпадает , выполняются последовательно все необходимые обработчики ,
• Устанавливается новое значение константы .

В результате везде, во всех базах данные обновлены.

3. Справочник предопределенных значений

Следующий прием - это справочник предопределенных значений.

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

Какие тут есть варианты реализации?

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

Этот справочник содержит в себе только один реквизит с типом СправочникСсылка (ссылка на все справочники).

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

И потом уже в коде обработки инициализации либо руками я заполняю значение этого справочника нужным мне контрагентом.

Соответственно, после этого я смогу обратиться к этому контрагенту через справочник предопределенных значений . За счет этого достигается то, что:

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

4. Просмотр временных таблиц в отладчике

Ну и последний прием - это просмотр временных таблиц в отладчике.

• При отладке сложных запросов с временными таблицами нужна возможность просматривать содержимое этих временных таблиц .
• Для этих целей можно использовать специальную функцию для просмотра временных таблиц.
• Эту функцию удобно расположить в глобальном модуле .

• И назвать как-нибудь коротко, например ВТ()

В этом случае:

• Я ставлю точку останова в месте, где у меня есть запрос.
• В окне «Вычислить выражение» пишу ВТ(Запрос) ;
• Нажимаю «Рассчитать» и получаю структуру временных таблиц запроса , чтобы просмотреть, что там за данные.

Это очень удобная функция, мы ее постоянно используем. Особенно при расчете себестоимости, или в таких конфигурациях, как ЗУП. Я если честно, не понимаю, как другие без нее живут.

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

Заключение

Всем спасибо. У меня есть небольшой сайт, на этом сайте в подробном изложении выложены все эти правила и не только они - заходите, читайте, пишите мне на почту или в скайп.

Мне эта тема интересна, я готов по ней общаться. Мне правда важно, чтобы у вас тоже все получилось.

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

Обычно 1С доработка включает в себя: доработка печатных форм, доработка отчетов или разработка новых отчетов, разработка обработок для анализа, для экономии времени обработки информации или заполнения информации, доработка конфигурации с созданием новых объектов конфигурации (справочников, документов, регистров, их реквизитов) Что бы доработать 1С вам необходимо воспользоваться услугами опытного программиста.

В программе 1С Предприятие применяется встроенный язык программирования, на котором написаны все без исключения конфигурации 1С - типовые и не типовые. Обладая навыками работы с программой 1С Предприятие в режиме - Конфигуратор - , специалист имеет возможность вносить произвольные изменения в тот или иной алгоритм работы конфигурации 1С, менять внешний вид элементов программы, создавать новые объекты конфигурации и т.д.

Именно поэтому система программ 1С Предприятие универсальная. Взяв за основу типовую конфигурацию, к примеру, 1С Управление Торговлей, программист может адаптировать ее к специфике предприятия любой сферы деятельности путем доработки 1С механизмов и объектов конфигурации.

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

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

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

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

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

Типовые конфигурации написаны для типовых учетов и ориентированы на некоторую среднюю и практически идеальную организацию.

В реальной жизни хозяйственный учет может иметь достаточно сложные и нестандартные ситуации. Бухгалтеры и специалисты хотят видеть тот или иной отчет в несколько измененной форме, а штатная возможность выгрузки информационных данных из одной программы в другую (например, из Бухгалтерии в Торговлю или из Зарплаты в Бухгалтерию) не учитывает всей специфики организации.

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

Преимущества доработанной конфигурации

Для возможности внесения даже незначительных изменений (печатные формы документов, внешний вид документов и справочников) в типовые прикладные решения на базе 1С:Предприятие платформы 7.7 необходимо было снимать конфигурацию с поддержки. Для платформы, начиная с 8.0, эта проблема частично решена: внешние печатные формы, отчеты и бланки можно модифицировать или создавать вновь без изменения структуры конфигурации, а управляемые формы платформы 8.3 предоставляют еще больше возможностей.

Открытые для изменений модули прикладных решений 1С:Предприятия позволяют модифицировать и настраивать любое прикладное решение «под себя». Доработка программы 1С дает ряд преимуществ:

1. Первое и самое основное — программное решение адаптируется под требования определенного учета в организации.
2. С помощью вновь разработанных и введенных в структуру конфигурации прав и ролей пользователей возможно более гибко описывать разрешенные и запрещенные действия при работе с документами и справочниками одного или группы сотрудников.
3. Настройка и изменение пользовательских интерфейсов (для управляемых приложений многое реализовано штатным способом).
4. Возможность изменения печатных форм документов, бланков и отчетов.
5. Изменение механизмов внутренних программных расчетов, настройки сложных вычислений, производственных формул, сложнорасчетных полей документов и т.д.
6. Возможность изменения внешнего вида документов, журналов документов, пользовательских регистров, элементов справочников.
7. Возможность добавления визуального представления объектов.

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

Недостатки доработки конфигураций

При всех явных преимуществах доработка типовых конфигураций 1С влечет за собой и некоторые неприятные последствия:

1. Снятое с техподдержки фирмы 1С для возможности доработки типовое решение теряет возможность автоматического обновления . Если все же обновление будет выполнено, то все внесенные в архитектуру конфигурации изменения будут утеряны. Обновление программы сможет выполнять только квалифицированный специалист, который перенесет все написанные вручную усовершенствования в обновленную версию программы.
2. Довольно часто бывает, что доработанные самописные механизмы конфигурации в дальнейшем реализуются разработчиками 1С штатным образом и вносятся в составе одного из обновлений. Таким образом, в ранее выполненных модификациях уже нет необходимости.
3. У каждого программиста 1С, как у художника, — свой собственный стиль: кто-то опытный пишет более грамотно и квалифицированно, кто-то более самобытно. Разобраться при необходимости в коде другого человека бывает весьма непросто, вплоть до того, что быстрее написать модуль с нуля, чем внести изменения в чужой код. Таким образом, существует некоторая привязка к программисту, который вносит в программу изменения.
4. Не всегда заказчик обладает достаточной квалификацией, чтобы составить для программиста грамотное техническое задание и понятно объяснить, какой же конечный результат он хочет видеть. Вследствие этого, между двумя сторонами может возникнуть недопонимание и потребность в дальнейшей корректировке заказа.

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

Состав команды проекта по доработке 1С.

Менеджер, или руководитель проекта (в зависимости от объема требований).

Функции: планирование, организация, контроль выполнения работ.

Аналитик.

Функции: обследование, постановка и формализация задачи, контроль разработки и консультирование программиста в процессе выполнения, внутреннее тестирование, внешнее тестирование (презентация, сдача заказчику).

Программист 1С.

Функции: Разработка, внутреннее тестирование доработок конфигураций 1С.

Краткое описание этапов проекта

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

Информация передается аналитику, после чего он удаленно или в офисе заказчика (в зависимости от объема и сложности задачи и ряда организационных моментов) декомпозирует цели заказчика до уровня конкретных решений, при этом:

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

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

После того как цели клиента стали понятными и декомпозировались до уровня технических решений (зафиксированы в виде ТЗ/ПТИ), задача передается программисту, который оценивает трудозатраты на ее реализацию. Оценка осуществляется с применением рекомендованных нормировочных таблиц, статистических данных (при выполнении аналогичной работы на других проектах), а также экспертных знаний одного или нескольких программистов.

Программист предоставляет результат оценки менеджеру с необходимыми комментариями, а при необходимости – с разъяснениями ограничений и допущений в реализации требований заказчика.

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

Бюджет и сроки выполнения доработки согласовываются с клиентом и, при необходимости обосновываются на доступном уровне.

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

1. Работа аналитика по выявлению, формированию и формализации технических требований оплачивается заказчиком (даже если в результате клиента не устроила оценка стоимости реализации задачи, и стороны не смогли договориться о приемлемых условиях, что почти не встречается в нашей практике). Причина этого в том, что результат работы аналитика имеет ценность сам по себе, выражается в виде отчуждаемых ценностей, а именно – в виде проектного документа, реализация которого может быть передана любому другому разработчику 1С (затрат на анализ уже не будет), если он сможет предложить лучшие условия реализации. Это нормальная, общепринятая практика.
2. Если трудоемкость и срок выполнения работы не превышают 40 чел./часов и 1 неделю соответственно (доработки локального характера) – аванс не вносится и задание выполняется без предоплаты. Оплату заказчик осуществляет после успешной реализации и приемки работ. Если же трудоемкость и срок реализации больше указанного значения, работа считается проектной. В этом случае порядок взаиморасчетов оговаривается отдельно (в т.ч. проектные работы осуществляются в рамках отдельных договоров). При этом размер аванса заказчика не может превышать 50% от общего согласованного бюджета работ.

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

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

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

Наша компания предоставляет годовую гарантию на результаты всех проведенных работ. Если в течение 12 месяцев возникнет ошибка, связанная с проведенными работами, мы осуществим исправление в полном объеме и в минимальные сроки.

Стоит отметить, что ошибки в системе могут возникать по самым разным причинам. Поэтому, прежде чем приступать к исправлению, мы запустим процедуру верификации проблемы и оценки ее связи с выполненными настройками/доработками системы. Если будет выявлено, что проблема возникла в виду неточностей реализации, анализ и непосредственное исправление выполняются бесплатно. Если будет выявлено, что ошибка возникла не по вине разработчика (например, ошибка при ведении учета пользователем), то трудозатраты на ее анализ подлежат оплате, равно как и трудозатраты по исправлению (устранению) проблемы. Это общепринятая практика, которая гарантирует нашу полную ответственность за все результаты работ, и вместе с тем, защищает нас от возникновения убытков по причинам, не связанным с виной наших специалистов.

Оставьте свое имя и номер телефона, оператор свяжется с Вами в рабочее время в течение 2 часов.

Москва Санкт-Петербург Самара

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

Преимущества работы с нами

• Все услуги доработки 1С 8.2 выполняются по отлаженной технологии, сертифицированной по международной системе менеджмента качества ISO 9001:2001.
• Мы гарантируем минимальные сроки выполнения работы, при условии активного сотрудничества Заказчика с экспертами нашей компании.
• Мы установили минимальные цены , чтобы и начинающие, и крупные компании могли произвести необходимые доработки 1С.
• Мы контролируем качество выполнения работ. За каждым сотрудником закреплен эксперт 1С, который контролирует работу.
• Мы даем гарантии на выполненные работы. Если в течение двух месяцев Заказчик обнаружит ошибки и неисправности в работе программ 1С, мы их исправим абсолютно бесплатно.

Что такое доработки 1С?

Доработка 1С – это некий «тюнинг» программ 1С, которые вы чаще всего используете в работе.

На базе существуют различные доработки, которые максимально охватывают предприятия, компании и организации, представленные на международном рынке. Но, нельзя угодить всем, ведь каждая компания уникальна. Именно такие «локальные» доработки и производят специалисты компании 1С:Франчайзи Виктория.

Когда следует выполнять доработку 1С?

Перед выполнением доработок 1С необходимо ответить для себя на несколько вопросов:

• Реализована ли специфика организации в типовом функционале? Наш опыт позволяет нам констатировать, что большинство решений о доработке принимаются скоропалительно. В результате компании вкладывают большие деньги на доработки и модификации, но не получают ожидаемого результата. А ведь им достаточно было всего лишь проконсультироваться со специалистом.
• Процессы, которые стремиться автоматизировать организация, действительно ли важны именно в том виде, в котором они сложились в компании? При разработке конфигураций для 1С специалисты компании 1С:Франчайзи Виктория используют методики ведения учета, проверенные временем и опытом многих компаний. Такие методики максимально эффективны, поэтому лучше довериться нашему опыту и немного перестроить некоторые бизнес-процессы в компании.

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

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

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

В нашей компании выполнение доработок конфигураций 1С выполняется в соответствии с требованиями международной системы качества ISO 9001:2001.

Как производится доработка 1С?