Доработка программы 1с. Принципы работы с ролями

Оставьте свое имя и номер телефона, оператор свяжется с Вами в рабочее время в течение 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С.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как мы осуществляем доработку программ 1С

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

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

Наиболее распространённые доработки 1С

Ниже перечислим особо востребованные доработки в программах 1С:

Создание справочников, реквизитов . Создание дополнительных мест хранения информации таких как, например, номера автомобилей
Доработка или разработка новых печатных форм . Изменение внешнего вида счетов, счет-фактур и прочих печатных форм документов согласно запросам Вашей организации.
Создание новых или изменение существующих отчетов . Создание дополнительных или редактирование существующих отчетов для бухгалтеров, менеджеров или директоров компании.
Настройка прав доступа . Ограничение или расширение доступа пользователям к информации в базе данных.
Разработка обработок. Создание обработок для упрощения систем ввода информации, анализа деятельности предприятия, автоматически выполняемых функций, например, вывод на печать пакета документов или загрузка информации из файла Excel(*.xls).
Настройка обмена 1С. Импорт/экспорт данных из одной программы 1С в другую.
Консультирование пользователей 1С. Разъяснение или обучение пользователей работе с внедренными доработками.
Обновление изменённых конфигураций. Мы обновляем изменённые, как нашими, так и сторонними программистами 1С конфигурации.

Преимущества поручения доработок в 1С нам

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

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

Компания 1С прочно закрепились в нише программ для автоматизации деятельности предприятий. «Бухгалтерия предприятия », «Управление торговлей », «Зарплата управление персоналом » и т.д. – стали визитными карточками компании и успешно применяются как в маленьких, так и больших предприятиях.

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

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

Проблема

Перед тем как начать говорить о решениях озвучим проблему. Типовые решения не могут выполнить все «хотелки» компании и единственный способ их реализовать – обратиться к сторонним/своим разработчикам. Если «хотелка» затрагивает типовые механизмы (объекты, формы, алгоритмы), то конфигурация становится непригодной для автоматического обновления.

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

Документирование, инструменты

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

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

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

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

Конфигурирование

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

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

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

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

Одну и ту же печатную форму можно сделать разными способами: воспользоваться механизмом, предоставляемым БСП (библиотека стандартных подсистем) или написать код напрямую в модуль формы/менеджера определенного объекта. Результат будет один и тот же – клиент получит желаемое, а вот поддержка решения усложнится.

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

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

Внешние печатные формы

Технология не является платформенной, а реализуется при помощи возможностей БСП (Библиотека стандартных подсистем). Поскольку все типовые решения строятся на базе БСП, никаких проблем с поддержкой возникнуть не должно.

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

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

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

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

Особое внимание стоит обратить на следующие свойства:

МассивНазначений. Содержит название объектов метаданных, для которых будет регистрировать печатная форма. Допускается несколько вариантов указания объектов: «Документ.ПриходныйКассовыйОрдер», «Документ.*». Последняя запись подразумевает все документы, доступные в системе.
Вид. Определяет вид внешней обработки. Обработки разных видов регистрируются по-разному. Для печатных форм указываем «ПечатнаяФорма», остальные доступные виды привел в комментариях.
Наименование. Название обработки в системе.
Идентификатор. Используется в нескольких местах, рекомендуется присваивать осмысленное имя. Чаще всего здесь указывает имя обработки, например: «РогаИКОпыта_ФормированиеМакетаКассовогоОрдера».
Модификатор. Если в качестве макета используется табличный документ, то указываем «ПечатьXML».

Процедура «Печать » выполняет служебную роль и вызывается встроенными механизмами системы. В большинстве случае ее содержимое остается неизменным за исключением параметров вызова «ВывестиТабличныйДокументВКоллекцию» (см. тело процедуры).

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

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

Имя для сохранения параметров печати. Чаще пользуются шаблоном: «ПАРАМЕТРЫ_ПЕЧАТИ_ИмяПечатнойФормы».
Макет. В методе «ПолучитьМакет» требуется указать имя макета.

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

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

Обработки для заполнения

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

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

Начало процесса разработки обработки заполнения стандартное: создаем новую обработку и описываем в модуле служебную функцию – «СведенияОВнешнейОбработке» (см. листинг 1).

Листинг 1. Заготовка для обработки заполнения

ПараметрыРегистрации = ДополнительныеОтчетыИОбработки.СведенияОВнешнейОбработке("2.1.2.1"); ПараметрыРегистрации.Вид = ДополнительныеОтчетыИОбработкиКлиентСервер.ВидОбработкиЗаполнениеОбъекта(); ПараметрыРегистрации.Назначение.Добавить("Документ.КонтСтраховойПолис"); ПараметрыРегистрации.Наименование = НСтр("ru= "Заполнение способов урегулирования убытков""); ПараметрыРегистрации.БезопасныйРежим = Ложь; ПараметрыРегистрации.Информация = "Демонстрирует механизм создания обработок заполнения"; ПараметрыРегистрации.Версия = "1.0.1"; НоваяКоманда = ПараметрыРегистрации.Команды.Добавить(); НоваяКоманда.Представление = НСтр("ru = "Заполнить способами урегулирования убытков""); НоваяКоманда.Идентификатор = "ЗаполнитьСпособыУрегулированияУбытков"; НоваяКоманда.Использование = ДополнительныеОтчетыИОбработкиКлиентСервер.ТипКомандыОткрытиеФормы(); Возврат ПараметрыРегистрации;

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

Рассмотренной функции достаточно для создания каркаса обработки-заполнения. Дальше все зависит от решаемой задачи. Если требуется создать форму обработки и наладить связь с объектом заполнения, вам потребуется описать в форме несколько параметров:

ОбъектыНазначения (Произвольный) – массив ссылок на объекты заполнения.
Идентификатор (Строка) – идентификатор команды.
ДополнительнаяОбработкаСсылка (СправочникСсылка.ДополнительныеОтчетыИОбработки).

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

Модернизация типовых форм

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

После расширения типовых объектов необходимо отредактировать основную форму. В самом просто случае вывести созданные элементы и прописать для них какую-нибудь логику. Банальное редактирование формы – подобно смерти, т.к. мы сразу напарываемся на проблему, описанную в начале статьи. Для элегантного решения подобных задач на платформенном уровне был создан механизм расширений.

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

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

Для создания нового расширения нажимаем кнопку «Добавить» и в появившемся окне заполним поля (рисунок 4):

Имя. Стандартные правила именования объектов метаданных 1С.
Синоним.
Префикс. Дополнительное значение, которое будет автоматически добавляться для всех созданных сущностей в расширении.

Нажимаем “Ok” и перед вами отобразится дополнительное дерево конфигурации (рисунок 5).

Принцип работы с деревом конфигурации расширения мало чем отличается от работы со стандартным деревом конфигурации информационной базы. Отличие заключается в ограничениях (http://its.1c.ru/db/v839doc#bookmark:dev:TI000001513).

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

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

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

Попробуйте поместить в созданную заготовку любой объект метаданных. Свои эксперименты я провожу на конфигурации «Бухгалтерия некредитной финансовой организации КОРП», но все сказанное будет актуально для большинства решений, построенных на базе БСП.

Я расширил документ «КонтСтраховойПолис » (добавил табличную часть и новые реквизиты), а затем добавил основную форму документа в созданное расширение (контекстное меню «Добавить в расширение»).

Вместе с формой будут перенесены связанные реквизиты, а также ряд других объектов (рисунок 6).

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

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

Идеи для расширений

Не стоит думать о расширениях, как о своеобразных костылях для модификации объектов. Это полноценная система плагинов с большим потенциалом на развитие. Уже сегодня расширения позволяют создавать: подсистемы, общие модули, роли, общие формы, обработки, отчеты, HTTP-сервисы, WS-ссылки, XDTO-пакеты. Перечисленных объектов хватит для решения многих реальных задач.

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

Аналогичным образом обстоят дела с интеграцией КИС и CMS. Стандартные механизмы обменов в виде громоздкого CommerceML – не самый удобный и быстрый способ выгружать номенклатуру на сайт. Расширения от разработчиков CMS могут запросто решить эту проблему и не создать пользователю типовых решений проблем с последующим обновлением.

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

На что еще способны расширения

О механизме расширений конфигурации можно говорить долго и написать отдельную статью. Технология постоянно развивается и пополняется новыми возможностями. Наиболее интересные новинки произошли с релизом платформы 8.3.9. Свет увидела первая концепция перехвата/подмена функций в модулях (расширение модулей).

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

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

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

&Перед, &Вместо, &После. Например: &Вместо ("РассчетСтраховойПремии") Функция РассчетСтраховойПремииСДополнительнымиРисками(Параметр) // Какой-то код КонецФункции

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

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

Подписки на события

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

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

Программная доработка форм

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

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

Модификация ролей

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

В идеальном варианте – старайтесь максимально дробить роли. Выделяйте роли на чтение и запись документов/справочников, не соединяйте права в одну роль. Конечно, не стоит это делать для каждого документа/справочника конфигурации, но делать нужно хотя бы для групп объектов. Рассмотрим пример – «Кассовые документы». К ним относятся как минимум «ПКО» и «РКО». Таким образом легко формировать гибкие профили безопасности (БСП).

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

Не ленитесь

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

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

КАТЕГОРИИ