Что такое доработка в 1с

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

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

У вас есть вопрос, нужна помощь консультанта?

Каковы самые частые доработки 1С?

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

Примеры модификаций 1С

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

Стоимость услуг специалиста по работе с 1С

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

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

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

Аналитик.

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

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

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

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

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

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

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

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

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

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

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

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

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

Работа аналитика по выявлению, формированию и формализации технических требований оплачивается заказчиком (даже если в результате клиента не устроила оценка стоимости реализации задачи, и стороны не смогли договориться о приемлемых условиях, что почти не встречается в нашей практике). Причина этого в том, что результат работы аналитика имеет ценность сам по себе, выражается в виде отчуждаемых ценностей, а именно – в виде проектного документа, реализация которого может быть передана любому другому разработчику 1С (затрат на анализ уже не будет), если он сможет предложить лучшие условия реализации. Это нормальная, общепринятая практика.
Если трудоемкость и срок выполнения работы не превышают 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С?

Вам нужно расширить функционал 1С ? Вам нужно, чтобы программа решала не только типовые, но и специфические задачи вашего предприятия? Услуга доработок 1С от «Актив-АйТи» поможет вам быстро решить эти вопросы.

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

Сроки выполнения работ - до 5 дней. В случае задержки до 10 дней - мы делаем для вас доработку бесплатно.

Ещё одно преимущество сотрудничества с нами - мы всегда выполняем свою работу добросовестно. Мы не работаем по схеме «получили техническое задание ==> сделали работу ==> сдали и забыли». Мы получаем техническое задание, качественно выполняем свою работу, даём вам оценить результат и, в случае необходимости, корректируем доработку без дополнительной оплаты.

Стоимость работы программиста 1С

Стоимость доработки конфигурации: 1500 руб. за час работы программиста.

Как итог вы получаете:

Сотрудничество с опытными программистами.
Создание и внедрение доработок абсолютно любого уровня сложности.
Выполнение работы в кратчайшие сроки - до 5 дней.
Гарантия возврата денег в случае задержки по времени.
Гарантия качества.

Заказывайте доработки 1С Бухгалтерия от «Актив-АйТи»!
Настройте работу 1С под специфику вашего предприятия вместе с нами.

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

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

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

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

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

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

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

//++ VION 20.07.2016 0001234 Доработка на старте //-- VION 20.07.2016

//++ — начало блока
//— — конец блока
VION — имя (или ник) разработчика
0001234 — номер задачи по трекеру, ставится только в открывающем комментарии, чтобы в результаты глобального поиска по номеру задачи каждое изменение кода попадало только один раз
Доработка на старте — произвольный комментарий, используется при необходимости, но если номер задачи отсутствует, то краткий пояснительный текст обязателен

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

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

2.1 Вставка кода

Пример :

Процедура ПриОткрытии() Если ЭтоНовый() Тогда ЗаполнитьПоляПоУмолчанию(); КонецЕсли; НастроитьЭлементыФормы(); //++ VION 20.07.2016 0001234 НастроитьДополнительныеЭлементы(); //-- VION 20.07.2016 УстановитьВидимостьПолей(); КонецПроцедуры

2.2 Удаление кода

Пример :

Процедура ПриОткрытии() //++ VION 20.07.2016 0001234 //Если ЭтоНовый() Тогда // ЗаполнитьПоляПоУмолчанию(); //КонецЕсли; НастроитьДополнительныеЭлементы(); //-- VION 20.07.2016 УстановитьВидимостьПолей(); КонецПроцедуры

2.3 Изменение существующего кода

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

Пример :

Процедура ПриОткрытии() Если ЭтоНовый() Тогда //++ VION 20.07.2016 000123 //ЗаполнитьПоляПоУмолчанию(); НастройкаЗаполненияПолей = ПолучитьНастройкуЗаполненияПолей(); ЗаполнитьПоляПоУмолчаниюРасширенная(НастройкаЗаполненияПолей); //-- VION 20.07.2016 КонецЕсли; НастроитьЭлементыФормы(); УстановитьВидимостьПолей(); КонецПроцедуры

2.4 Добавление процедур и функций в модуле

Для добавляемых процедур и функций, а также для объявления переменных модуля типовых объектов действуют дополнительные правила оформления комментариев:

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

Пример :

//++ VION 20.07.2016 000123 Перем мНастройкаЗаполненияПолей; Процедура ДоработатьФормуПрограммно() ... ... КонецПроцедуры //-- VION 20.07.2016 //++ VION 20.07.2016 000123 Процедура ДатаОтгрузкиОбработкаВыбора() ... ... КонецПроцедуры //-- VION 20.07.2016

Данное правило позволяет легко переносить изменения в модуле в «попроцедурном сравнении» конфигураций.

Если же закрывающий комментарий поставить на следующей строке:

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

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

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

Синонимы (видимые пользователю имена) добавленных объектов верхнего уровня должны начинаться с префикса, заключённого в круглые скобки: (АБ) . В результате эти объекты будут визуально выделяться в списках и сгруппировано располагаться в их начале (что облегчает и тестирование, и использование).

В комментарии создаваемого объекта следует указать имя разработчика, дату и номер задачи, по аналогии с добавляемого кода, но без знаков «++». Это обеспечит привязку объекта конфигурации к задаче, отыскиваемую глобальным поиском.

Пример : Создать справочник «Проекты».

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

Имя: АБ_Проекты
Синоним: (АБ) Проекты

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

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

4.1 Добавление подчиненных объектов в типовые объекты конфигурации

Подчинённые объекты, добавляемые в существующие (типовые) объекты конфигурации, должны снабжаться префиксами : АБ_ДополнительныйРеквизит , АБ_НоваяТабличнаяЧасть , АБ_ФормаНастроекПользователя , АБ_МакетСпециальнаяНакладная . Но при этом синонимы таких подчинённых объектов создаются без префикса .

Пример : Создать реквизит «Проект» документа «Авансовый платеж».

Действия разработчика : в конфигурации создается следующий реквизит:

Имя: АБ_Проект
Синоним: Проект
Комментарий: // VION 20.07.2016 000123

4.2 Добавление подчиненных объектов в объекты, добавленные в рамках проекта

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

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

Пример : Создать реквизит «Ответственный» у справочника «(АБ) Проекты».

Действия разработчика : Если задача отличная от той, в которой создавался справочник «(АБ) Проекты», то в конфигурации создается следующий реквизит:

Имя: Ответственный
Синоним: Ответственный
Комментарий: // VION 20.07.2016 000456

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

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

5.1 Добавление предопределенных элементов в типовые объекты конфигурации

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

Пример: В план счетов «Хозрасчетный» добавить предопределенный счет 10.15 — Бланки строгой отчетности.

Действия разработчика : Добавить следующий предопределенный счет:

Имя: АБ_БланкиСрогойОтчетности
Код: 10.15
Наименование: Бланки строгой отчетности

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

5.2 Добавление предопределенных элементов в объекты, добавленные в рамках проекта

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

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

Неоднократно используемые в конфигурации процедуры и функции, обработчики подписок и регламентных заданий размещаются в общих модулях. Для этих целей следует добавлять собственные модули , добавленные по объектов верхнего уровня, оставляя типовые модули неизменными . При разработке будут полезны следующие общие модули («АБ_» - префикс):

АБ_ОбщегоНазначения (клиент, сервер, внешнее соединение) - для размещения обычных процедур и функций.
АБ_Серверный (только сервер) - для процедур и функций, которые обязательно должны исполняться в среде сервера.
АБ_Глобальный - для процедур и функций, вызов которых стандартным способом (через имя модуля и точку) неудобен.
АБ_Привилегированный - для процедур и функций, которые всегда нужно исполнять под полными правами.
АБ_ПовторноеИспользование - для кэширования возвращаемых значений некоторых функций.

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

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

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

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

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

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

Действия разработчика :

1. Создать подписку «АБ_ДокументыОбработкаПроведения» (если такая подписка не была создана раннее), в качестве источника указать все документы, событие — «ОбработкаПроведения».

2. Создать общий серверный модуль «АБ_ДокументыОбработкаПроведения».

3. В модуле создать экспортную процедуру «ОбработкаПроведения». Выбрать данную процедуру в качестве обработчика созданной ранее подписки. В процедуре, в зависимости от типа документа, вызываются необходимые обработчики.

4. Модуль документа «Авансовый платеж» должен остаться без изменений.

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

8.1 Редактирование форм типовых объектов

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

Пример : На основную форму документа «Авансовый платеж», добавить реквизит «(АБ) Проект».

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

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

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

В процедуре «ПриСозданииНаСервере» общего модуля «МодификацияКонфигурацииПереопределяемый» можно вызвать свой обработчик.

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

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

8.2 Редактирование форм объектов, добавленных в рамках проекта

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

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

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

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

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

10. Внешние отчеты и обработки

Большинство доработок в системе может быть выполнено с помощью механизма Дополнительных отчетов и обработок.

В конфигурациях на основе БСП 2 (ERP, УТ 11, БП 3.0, ЗУП 3.0 и т. д) этот механизм значительно расширен. С его помощью без изменения конфигурации возможно создавать внешние отчеты и обработки (с размещением команды запуска в командном интерфейсе и возможностью настройки доступа различным пользователям), обработки заполнения документа, обработки создания документа на основании, дополнительные печатные формы и др.

Помогла ли вам данная статья?