1с как разобраться в типовых конфигурациях
Типовые прикладные решения фирмы «1С» предназначены для автоматизации типовых задач учета и управления предприятий. При разработке типовых прикладных решений учитывались как современные международные методики управления (MRP II, CRM, SCM, ERP, ERP II и др.), так и реальные потребности предприятий, не укладывающиеся в стандартный набор функциональности этих методик, а также опыт успешной автоматизации, накопленный фирмой «1С» и партнерским сообществом. Состав функциональности, включаемой в типовые решения, тщательно проработан. Фирма «1С» анализирует опыт пользователей, применяющих программы системы «1С:Предприятие» и отслеживает изменение их потребностей.
- «1С:Бухгалтерия 8» (включая версию КОРП, базовую версию и специализированные поставки базовой версии «1С:Упрощенка 8» и «1С:Предприниматель 8»);
- «1С:Управление нашей фирмой 8» (включая базовую версию);
- «Управление торговлей» (включая базовую версию);
- «1С:Розница 8» (включая базовую версию); » (включая версию КОРП и базовую версию);
- «1С:ERP Управление предприятием 2»;
- «1С:Комплексная автоматизация 8»;
- «1С:Управление холдингом 8»;
- «1С:Документооборот 8»;
- «1С:Налогоплательщик 8»;
- «1С:Платежные документы 8»;
- «1С:Электронное обучение».
- «1С:Бухгалтерия государственного учреждения 8»;
- «1С:Бюджетная отчетность 8»;
- «1С:Зарплата и кадры государственного учреждения 8»;
- «1С:Документооборот государственного учреждения 8»;
- «1С:Свод отчетов 8»;
- «1С:Вещевое довольствие 8».
Стандартизация типовых решений
В типовых решениях реализуются функции, отвечающие массовым потребностям предприятий. Это позволяет обеспечить соответствие типовых решений отечественной специфике как по методологии учета, так и в части управления деятельностью предприятия, в то же время сделав эти решения достаточно компактными и простыми в использовании. При этом удается обеспечить эффективную поддержку и развитие типовых решений.
Типовое прикладное решение можно представить в виде набора стандартных элементов — объектов конфигурации, которые обеспечивают реализацию той или иной функциональности. Один и тот же стандартный элемент может присутствовать в разных тиражных прикладных решениях. Стандартизация элементов прикладных решений облегчает освоение типовых прикладных решений пользователями, упрощает техническую поддержку, обновление и доработку силами сертифицированных специалистов фирм-партнеров, а также облегчает создание новых специализированных и индивидуальных прикладных решений на базе типовых прикладных решениях фирмы «1С».
Автоматизация отдельных задач или комплексная автоматизация
При выборе системы автоматизации требуется принять решение о разделении различных подсистем автоматизации или, наоборот, о централизации путем внедрения комплексного решения. Современные тенденции развития экономических систем и мировой опыт показывают, что универсального рецепта для решения этой проблемы не существует.
Использование обособленных решений проще и эффективнее, если отдельные задачи автоматизации на предприятии мало пересекаются. Комплексные решения эффективнее при сильной увязке различных задач автоматизации и готовности предприятия к формированию единого информационного пространства. Для принятия решения о выборе общих принципов и конкретных систем автоматизации целесообразно обратиться к компетентным представителям партнерского сообщества фирмы «1С». Система программ «1С:Предприятие 8» предоставляет возможность реализации обоих подходов: как внедрение комплексного решения, так и внедрение отдельных прикладных решений, которые будут работать автономно или интегрировано с другими решениями «1С» и сторонних разработчиков.
Поддержка и сервис
При выборе системы важно оценить перспективы эксплуатации и развития системы.
Стандартизация платформы и прикладных решений во всех программах «1С:Предприятия 8» обеспечивает возможность эффективной поддержки системы со стороны фирмы «1С» и партнерского сообщества. Фирма «1С» обеспечивает регулярную поддержку типовых прикладных решений и самой платформы. Платформа «1С:Предприятие 8» обеспечивает возможность совмещения обновлений прикладного решения, производимого фирмой «1С» или разработчиком специализированного решения, с индивидуальными изменениями, внесенными при внедрении системы.
В России, странах СНГ и Балтии работают десятки тысяч специалистов, профессионально занимающихся внедрением и адаптацией прикладных решений «1С:Предприятия». В каждом регионе существует большое количество франчайзинговых фирм, оказывающих весь спектр услуг по комплексной автоматизации на базе программ системы «1С:Предприятие» — начиная от консультаций по выбору наиболее подходящих программ системы и заканчивая обучением и индивидуальной настройкой системы. Многие из специалистов, занимающихся внедрением «1С:Предприятия», решают не только задачи, связанные с поддержкой или развитием прикладных решений, но и оказывают консалтинговые услуги, помогая принимать правильные решения при постановке учета и управления на предприятии. Фирма «1С» проводит регулярное обучение и сертификацию специалистов.
Весьма важной может оказаться возможность быстрого привлечения специалистов по развитию и поддержке прикладного решения. Устройство системы «1С:Предприятие» позволяет достаточно быстро вводить в курс дела новых специалистов и передавать поддержку прикладного решения тому, кто сможет обеспечить наилучшее обслуживание. Таким образом, наличие реальной индустрии внедрения и поддержки решений системы «1С:Предприятие» является гарантией отсутствия проблем сопровождения и развития информационной системы.
Курс "Внедрение прикладного решения "1С:Зарплата и управление персоналом 8" в 1С:Учебном центре №1 с 16 по 19 мая 2022 года 05.05.2022 12:26:00
Старт продаж новых тарифных планов на 1 месяц при подключении онлайн-касс к оператору фискальных данных "Такском" через сервис "1С-ОФД" 04.05.2022 17:30:00
Очные курсы в 1С:Учебном центре №1. Начало продаж. Расписание на май-июнь 2022 года 29.04.2022 17:08:00
Открытие новых сертифицированных экзаменационных центров (1С:СЭЦ) в городах Брянск и Тверь 29.04.2022 16:19:00
Во всех вакансиях есть требование - умение читать чужой код. Но ни на одних курсах специально этому не учат. Чтобы устранить это противоречие, пишу данную статью. Рассмотрю случаи, в которых нам необходимо разбирать чужой код, поймём, чей код мы пытаемся разобрать, зачем и главное как. В статье описан личный опыт длиною в 18 лет начиная с версии платформы 7.7. Статья будет большой, набираемся терпения). Статья содержит в себе описание сценариев разбора кода, т.е. набор шагов. В статье не получится показать это на практике. Для этого планирую сделать онлайн или оффлайн курс, где на примерах будет показан разбор незнакомого кода. Статья разбита на 4 публикации для удобства изучения.
Сразу напишу вопросы, которые в статье не будут рассматриваться:
1. Разбор и отладка правил конвертации
2. Отладка фоновых заданий.
3. Отладка асинхронных вызовов.
Здесь если начать описывать данный процесс, то получится статья о том, как они работают. А смысла писать давно описанное нет. Для меня пп. 2 и 3 это обычный код, который разбирается в других кейсах.
Кейс 3. Доработка типовой конфигурации.
Большинство разработчиков и руководителей проектов считают, что дорабатывать типовую конфигурацию нужно только в крайних случаях. Все стремятся решить задачу либо внешней обработкой/отчетом, подпиской на событие, либо регламентным заданием. Сейчас к этому списку вредоносных решений добавились расширения. В своей практике крайне редко пользуюсь подобными приёмами программирования, т.к. хорошо владею инструментами обновления конфигураций. Не испытываю сильных трудностей при пропуске большого числа релизов и сильно переработанном коде. Надеюсь, благодаря статье и у Вас появится больше инструментов для работы.
Итак, как мы выяснили, главное, что нужно сделать, - разобраться со сценариями работы типовой конфигурации. Т.к. конфигурация типовая, мы всегда можем найти огромное количество инструкций, описаний, статей, книг и т.д. Вот в какой последовательности стараюсь изучать типовое решение, точнее каждый блок в типовом решении:
1. Предметная область. Все типовые конфигурации довольно сильно привязаны к предметной области. Отсутствие знаний по предметной области не позволит Вам полноценно разобраться в происходящих бизнес-процессах. Как следствие, выявить все сценарии работы пользователей, подлежащие автоматизации - затруднительно. Настоятельно рекомендую начинать именно с этого. В моей сфере (ЗУП), предметной областью является законодательство (ТК РФ, НК РФ), правила заполнения отчетности, локальные нормативные документы общества (положение об оплате труда, положение о ведении кадрового учета, положение о премировании).
2. Архитектура решения. На этом этапе необходимо разобраться, в нужной Вам подсистеме. Вот что следует изучить:
а. Какие операции выполняются в рамках подсистемы.
б. Какая справочная информация используется. Какие особенности заполнения справочной информации.
в. Какие регистры, и как используются для обеспечения работоспособности подсистемы.
г. Какая отчетность на основании каких данных формируется.
Конечно, не для каждой задачи требуется столь глубокий анализ. Но при решении сложных задач, требующих больших доработок это необходимо.
3. Назначение объектов метаданных. Для более мелких задач можно начать с разбора конкретного документа/справочника/отчета и т.д. Для некоторых задач не имеет никакого значения, в какой подсистеме этот объект метаданных, и как подсистема функционирует. На данном этапе необходимо выяснить, на основании каких данных объект заполняется, и какие данные объект меняет.
4. Сценарии работы. Сценарии работы - основа любой разработки! Этот пункт является основным, и пропускать его ни в коем случае нельзя! Сценарии работы следует изучить не только в месте доработки, но и в связанных объектах метаданных. Если поменять движения документа, и не разобраться, как формируются отчеты на основе измененных движений - сломаем отчет. Если по регистру заполняет другой документ - сломаем авто заполнение другого документа. Если изменения вносятся в интерфейс или печать - необходимо изучить эти механизмы до выполнения доработок.
5. Работа интерфейса. Данный пункт является продолжением изучения сценариев работы. Выделил его в отдельный пункт, т.к. часто сталкиваюсь либо со сломанным интерфейсом, т.е. в неучтённых ситуациях появляются ошибки, либо неверно отображается форма. Либо пишут новые кнопки, которые на самом деле уже есть! В типовых конфигурациях следует учитывать наличие динамически создаваемых реквизитов, т.е. их нет на форме, они создаются программным путём. На наличие таких элементов указывает наличие пустых групп в дереве реквизитов управляемой формы (слева вверху). Например, в типовых документах встречаются пустые группы "ПодписиГруппа" для указания подписантов, или "ГруппаИсправление" для отображения универсальных команд механизма исправления, или "ГруппаДополнительныеРеквизиты" для отображения дополнительных реквизитов, указанных для конкретного документа. Аналогичные группы есть и в шапке документов. Всё это необходимо учитывать при изменении интерфейса.
6. Программный код. Изучение программного кода позволяет лучше понять каждый в отдельности сценарий работы. При прохождении отладчиком сценария можно увидеть, как именно срабатывает код, какие данные возвращают запросы, какие движения пишутся в регистры, откуда получаются данные, как работает печать и почему именно так и т.д.
Код типовой конфигурации часто усложнён универсальными процедурами или целыми модулями. Они сложны для понимания, но зачастую программный интерфейс конфигурации следует воспринимать как ещё одну процедуру или функцию встроенного языка. Никто же из Вас не пытается вникнуть, как срабатывают функции встроенного языка. Мы просто изучаем, что у них на входе и что на выходе. Также и здесь, подробнее ниже.
Программный код типовых решений содержит сценарии для всей страны. Поэтому на данном этапе требуется локализовать место, которое Вы планируете доработать. И уже изучать более мелкий участок кода.
Разобрав все указанные аспекты типовой конфигурации, скорей всего, у Вас получится выполнить доработку аккуратно, не сломав сценарии типовых объектов метаданных.
Также Ваша доработка должна быть выполнена в общей стилистике дорабатываемой конфигурации. Необходимо соблюдать стандарты разработки, делать так, чтоб решение легко обновлялось. Детали обновления описаны ниже.
Кейс 4. Обновление доработанной типовой конфигурации.
Прежде, чем описывать сам кейс, хочу развенчать некоторые мифы и дать некоторые подсказки к обновлению:
Миф №1. Не нужно дорабатывать типовую конфигурацию, иначе не сможем её потом обновлять. Главное - дорабатывать грамотно, соблюдать стандарты разработки, не создавать дубли типовых объектов метаданных для изменения и т.д. Если не делать глупостей в процессе разработки - обновление довольно несложный процесс.
Миф №2. Нельзя дорабатывать формы типовых объектов, будет сложно их обновить. Сильно ли Вы удивитесь, если узнаете, что перенести свои новые реквизиты на обновленную форму можно через простое действие Скопировать + Вставить. Не нужно каждый новый реквизит создавать заново! Не обязательно новые элементы на форму добавлять программно! Так Вы ещё один или несколько модулей сделаете нетиповыми.
Миф №3. Обновить конфигурацию может только самый опытный сотрудник. Ничего подобного! Мне 15 лет назад дали в хлам переписанную Бухгалтерию 7.7 и за месяц я её обновил! На тот момент мой опыт составлял 3,5 года. Учитывая то, что начинал я в регионе, опыт был так себе! Главное не бояться и придумать какую-то систему для переноса доработок в новый релиз.
Теперь подсказки:
Подсказка №1. Неважно, сколько Вы пропустили релизов, обновлять нужно сразу на последний! Часто слышу от коллег, что при пропуске 5-10 релизов, они последовательно выполняют обновление своей конфигурации на каждый из пропущенных релизов. Ничего хуже и придумать невозможно, как выполнить одну и ту же работу 5-10 раз! Почему так делают:
-- Обработчики обновления могут неверно сработать, если запустить их сразу на все релизы. Это впору записать в очередной миф. Обработчики обновления так написаны, что выполняются последовательно, вне зависимости от количества пропущенных релизов. Сам выполнял обновление, когда не релиз поменялся, а редакция!
-- Не получится сохранить СФ из-за большого количества изменений. Ни разу с таким не сталкивался. Имеется ввиду, что при сохранении возникнут какие-то конфликты в данных. Например, если в регистре есть записи, то могут быть проблемы с сохранением такой конфигурации. Об этом можно подумать заранее, и найти решение.
Подсказка №2. Выполнять обновление необходимо в режиме "Показать дважды измененные объекты". Можете почитать что это за режим в деталях. Главный его плюс - экономия времени! Ведь обновить требуется только те объекты метаданных, которые и Вами были доработаны и фирма 1С изменила объект в одном из пропущенных релизов. Остальные объекты Вы можете считать уже обновлёнными!
Подсказка №3. Для обновления на новый релиз Вам необходимо создать несколько баз. Перечислю их и опишу зачем каждая:
База 1. Копия до обновления. Здесь мы можем смотреть код и состояние форм, которые были до перехода на новый релиз. Часто неудобно оценивать правильность кода через сравнение объединение объектов.
База 2. Типовая конфигурация старый релиз. Здесь можно проверить как было в типовом релизе до доработок. Это требуется, т.к. не все разработчики понятным образом отмечают границы своих доработок.
База 3. Типовая конфигурация новый релиз. Аналогично база нужна, чтоб посмотреть как сделано в новом релизе. Рекомендуется здесь иметь демо-базу, чтоб иметь возможность тестировать новые механизмы.
База 4. Обновляемая база. Здесь всё просто - после завершения работ именно в этой базе будет новая конфигурация с выполненными ранее доработками.
База 5. Типовая конфигурация старый релиз для сравнения. В этой базе мы запускаем сравнение/объединение с конфигурацией нового релиза. Это требуется, чтоб понять объём доработок в отдельных объектах метаданных. Иногда нужно сделать выбор, что переносить: свои доработки или доработки типового релиза. Бывает какие-то процедуры мы сильно переписали, а в типовой конфигурации всего пару строк поменяли. Соответственно проще в эту процедуру внести изменения типового релиза. Это сильно экономит время!
Пора описать подробности кейса:
Надо понимать, что здесь будет не инструкция "Как обновить нетиповую конфигурацию". Кейс с разбором запросов осознанно написан позднее, т.к. для обновления эти знания не нужны. Вопросы обновления форм здесь также не затрагиваются. Рассказ ведется как ответ на вопрос: "Как найти место, куда вставить дописанный код?"
Итак будет 3 ситуации:
1. Изменения внесли в запрос.
2. Изменения внесли в обычный код.
3. Изменен запрос схемы компоновки данных.
1. Перенос изменений в запросах:
а. Первым делом нужно проверить, изменился ли структурно запрос, в котором была доработка? Т.е. в типовой конфигурации могли всего лишь добавить поля новые в запрос, переместить временную таблицу в другую часть запроса, часть запроса убрать в другую процедуру в результате рефакторинга кода. Это всё не страшно, Вы просто ищете по наименованию временной таблицы (в которую поместили), либо по названию таблицы источника запроса. Вставляете свои доработки в найденное место и радуетесь, что не надо писать заново.
б. Если в текущей процедуре/функции не обнаружен кусок запроса, не стоит впадать в панику. Нужно сделать следующий шаг: посмотреть, после какого кода был Ваш кусок кода? Что сейчас на этом месте? Очень часто Вы обнаружите переход в функцию общего модуля. Зайдя в неё можно легко обнаружить нужный запрос и внести в него изменения.
в. Если всё таки запрос был структурно изменен. Сначала, что значит структурно изменен?
-- Изменилась таблица, из которой данные получались. Иногда в типовой конфигурации меняют состав регистров, состав измерений регистра. Т.е. старый помечают как Удалить. А новый создаётся с другим составом измерений.
-- Запрос начал делаться в 2 этапа. Такие события происходят для оптимизации работы с использованием индексов.
В такой ситуации Вам нужно понять, что было изменено в запросе в версии до обновления:
-- Добавилась связь между таблицами
-- Добавилась собственно новая таблица и всё вышеперечисленное.
Очень полезно в сложных случаях через отладчик смотреть, как выглядит таблица после доработки. Вы тогда можете сравнить её с таблицей "до" и станет понятно, какие изменения внесены в запрос.
Далее начинаете к новой архитектуре по частям применять внесённые ранее изменения. Ситуаций, когда вот совсем некуда вставить свой код, не так уж много! Если разбить код на маленькие кусочки, то каждый маленький кусочек становится вполне понятным, даже если неизвестна ни постановка, ни сценарий работы! Как видно из описания, знать это необязательно!
2. Перенос изменений в коде.
На самом деле. алгоритм вставки кусков обычного кода (не запросов) точно такой же!
а. Ищем исходное место кода, определяем - есть куда вставить или нет? Возможно, часть кода вынесли в отдельную процедуру/функцию. Здесь искать надо прямо целую строку, которая предшествует написанному Вами коду. Если её нашли и далее код похож на то место, в которое Вы его вставили - радуемся результату.
б. Возможно написали в другом месте. Часто процедуры целиком переносят в другие общие модули. В таком случае надо поискать по названию процедуры/функции по всем текстам. Этот совет также помогает, когда Вы использовали типовой программный интерфейс и в том виде, как написано, не срабатывает.
в. Если опять плохой вариант, то пробуем следующие действия:
-- Для начала необходимо определить, где старый код реализован по-новому. Код бесследно не стирают, его оптимизируют, проводят рефакторинг, делают более универсальным и т.д. Крайне редко в типовых конфигурациях удаляют реализацию каких-то сценариев. Обычно добавляют новые.
-- Для того, чтобы найти, необходимо ответить на вопрос: "Каким действием пользователя запускается код?". Иногда код может запускаться без пользователя через подписки на события и регламентные задания. Чтобы найти путь к новому коду, нужно посмотреть сначала тот же путь в старом решении. Здесь поможет установка точки останова в месте доработки и через стек вызовов (пункт меню в конфигураторе) можно найти путь к месту, из которого вызван нужный Вам код.
-- Когда определён путь в старой реализации, начинаем искать его в новой реализации. Для этого через стэк вызовов пошагово смотрим, на каком шаге изменилась реализация? Т.е. где-то код свернёт в другой модуль, в этом другом модуле процедура/функция будет иметь примерно такое же название, как и раньше.
-- Когда определили место новой реализации, пытаемся разобраться в старой реализации, что было добавлено? Как и с запросами, мы смотрим на добавленные условия, дополнительная обработка коллекций значений, какая-то дополнительная функция для обработки этой коллекции. Когда мы разложили весь код на простые составляющие, можно понять, что нужно написать в новой реализации, даже не зная сценария работы!
Конечно, может возникнуть ситуация, когда нужно вникать в новые сценарии и заново проводить доработку по какой-то задаче. Но ситуация эта не распространённая. В моей практике, описанные шаги помогают провести обновление.
ВАЖНО: Не нужно бояться ситуаций, когда требуется доработка с нуля. Об этом необходимо смело информировать руководителя проекта или архитектора. Наверняка эти люди попытаются ускорить обновление и найдут исполнителя на новую задачу. Если Вы тратите излишне много времени на решение нерешаемого - это негативно сказывается на сроках обновления и Вашей карме!
Остальные части доступны по ссылкам:
Добавляйте себе в избранное, ставьте "+". Статья разрабатывалась 1,5 месяца, а опыт копился 18 лет!
Также напомню о своих предыдущих публикациях, в особенности про статью об архитекторе. Текст статьи полностью переработан, сглажены углы. Будет интересно, даже если уже читали. Вот ссылки:
Типовые конфигурации слишком сложные, при этом сложность не соответствует сложности предметной области. Разработка на 1с уже давно не так проста, как это есть на уровне возможностей платформы, по причине необоснованного усложнения ТК. В конфигурациях должен быть небольшой по объему и понятный по сути код. Ведь основные сложные проблемы программирования решены на уровне СУБД (MS SQL, Oracle и т.д.) и самой платформы 1С, что по идее должно позволять создавать простые и понятные конфигурации
- Рост сложности не связан с усложнением предметной области или средств платформы (платформа в целом даже улучшилась, но недостаточно). Скорее всего рост сложности в ТК произошел из-за того, что УМЫШЛЕННО создаются монстрообразные алгоритмы объемом в тысячи, а то и десятки тысяч строк кода, вызывается множество объемных и неочевидных по алгоритму процедур. Рост сложности конфигураций влечет за собой рост сложности настройки и трудозатрат при изменениях под клиента, а оплата за доработки и настройку почти всегда пропорциональна количеству выставленных клиенту часов. «Выгода» очевидна, только кому? На форумах даже используют термин «коммерческий» код. При том что чтобы средствами платформы например сделать запрос и сформировать проводку как правило не нужно больше двухсот строк кода, модули проведения или заполнения документов могут занимать десятки тысяч строк кода! В них вызывается множество громоздких и неочевидных процедур. Стандартным стало использование в ТК в модулях проведения нескольких таблиц значений, все это выгружается-загружается-сворачивается-обрабатывается и т.д. на встроенном языке 1с. Разобраться в этих гигантских процедурах достаточно непросто. На форумах даже спрашивают, не роботы ли или инопланетяне пишут ТК. Если раньше практически любой алгоритм можно было понять относительно просто через конфигуратор и отладчик, то сейчас проще спросить на форуме возможные причины формирования или неформирования проводок, чем с негарантированным результатом неделю копаться в гигантских модулях. ТК стали изучать через видеокурсы, а не через конфигуратор как это было в 7.7 версии. Регулярно возникают одни и те же темы на форумах, например как закрыть 20 счет, ведь разобраться достаточно непросто даже опытному специалисту, учитывая неадекватно большой и сложный код в закрытии месяца.
- Другим аспектом сложности ТК является то, что при решении каких-либо задачи предметной области зачастую выбираются неадекватно сложные методики и алгоритмы, как следствие даже опытному пользователю сложно в режиме работы с базой разобраться что нужно сделать чтобы выполнить какие-либо регламентные процедуры, также это усложняет и программный код. Принципиальный момент в том, что сложность не соответствует сложности решаемых задач.
Эта статья является логическим продолжением цикла статей «Первые шаги в разработке на 1С». В ней описывается среда разработки на платформе 1С, которая получила название “Конфигуратор”. Изучив данный материал, вы узнаете:
- Что такое дерево объектов, для чего оно нужно и как с ним работать?
- Для чего нужна палитра свойств, как её открыть, как в ней что-то отыскать?
- Когда нужно настраивать различные параметры конфигуратора и как это сделать?
- Что нужно сделать, чтобы можно было внести изменения в типовую конфигурацию?
- Как запустить конфигурацию в режиме отладки?
- Как подключиться к клиентской сессии в режиме отладки и посмотреть, что там происходит?
Рекомендуем ознакомиться с этой информацией не только начинающим программистам, но и всем тем, кто уже работал с конфигуратором и хочет ознакомиться с тонкостями его работы.
Применимость
В статье рассматривается платформа «1С:Предприятие» версии 8.3, поэтому вся информация актуальна для текущих релизов.
Основные приемы работы в конфигураторе
Дерево объектов – это первое, с чем Вы сталкиваетесь при запуске конфигуратора.
После запуска конфигурации для разработки, чтобы увидеть дерево объектов, необходимо выбрать один из двух пунктов меню Конфигурация (Открыть конфигурацию, если конфигурация еще не открыта, или Окно конфигурации, если закрыто просто само окно конфигурации).
Также можно использовать соответствующие кнопки.
Дерево объектов конфигурации отображает: какие сущности есть в конфигурации.
С помощью дерева объектов можно создавать новые элементы, редактировать, добавлять новые реквизиты и свойства.
Данное окно имеет режим закрепления. Кнопка с пиктограммой в виде скрепки в правом верхнем углу окна Конфигурация позволяет делать его прячущимся в тот момент, когда оно не активно.
Возможен поиск нужного объекта по первым буквам. Курсор автоматически позиционируется на нужном объекте.
Иногда дерево объектов называют метаданными. Во встроенном языке есть специальное свойство, которое так и называется Метаданные (т.е. данные о данных).
Одна из функций конфигуратора – это выгрузка/загрузка информационной базы. При выгрузке информационной базы получается упакованный файл с расширением dt.
Эту функцию мы уже подробно рассматривали в предыдущих статьях. Она используется в следующих случаях:
- для переноса базы данных из одного места в другое;
- как один из вариантов выполнения архивирования;
- для перевода файлового режима работы базы в клиент-серверный.
Для редактирования свойств объектов конфигурации существует три метода. Первый из них – вызов окна редактирования объекта (двойным кликом мыши).
Удобен для объектов с большим количеством свойств. Окно редактирования объекта «Документ1» представлено на рисунке.
Данный метод существует не для всех объектов. Например, исключением являются константы.
Следующий метод редактирования свойств объектов – с помощью палитры свойств, которая есть у всех объектов (и у простых, и у сложных). Соответственно, ее можно вызвать для любого объекта.
Вызов осуществляется через контекстное меню, пункт Свойства объекта (комбинация клавиш Alt+Enter).
В палитре все свойства представлены в виде списка. Можно выбирать соответствующие свойства и редактировать.
Метод удобен для объектов с небольшим количеством свойств, но может быть применен для любого объекта.
У палитры свойств есть режим закрепления (т.е. окно можно либо закрепить, либо сделать его прячущимся).
Свойства могут группироваться либо по категориям (как на рисунке), либо быть упорядоченными по алфавиту (удобно, когда точно известно название свойства, но не известна его категория). Группировки свойств можно сворачивать и разворачивать.
Возможно отображение только важных свойств. Переход в данный режим осуществляется нажатием на кнопку в виде воронки.
Если Вы не можете найти какое-то свойство, то, скорее всего, у Вас нажата данная кнопка.
Для каждого свойства существует описание (отображается внизу окна). Описание может быть скопировано в буфер и использовано для поиска по справке.
Возможно расположить категории свойств на отдельных закладках. Для включения данного режима на самой палитре свойств в контекстном меню выбирается пункт Закладками. Однако чаще удобнее работать именно списком.
С помощью палитры свойств удобно редактировать однотипные свойства для нескольких объектов, так как при переходе от одного объекта к другому палитра свойств отображается уже для другого объекта, при этом курсор остается на том же свойстве.
Еще один метод редактирования свойств объектов при помощи окна «Дополнительно». Для открытия этого окна выбирается объект конфигурации, затем в контекстном меню выбирается пункт Дополнительно.
В этом окне можно проставлять различные свойства данного объекта, которые, в основном, представлены в виде различных галочек.
Удобно использовать данное окно, если нужно провести классификацию нескольких объектов, например, по подсистемам. В этом случае вызывается данное окно и при переключении по объектам присваивается вхождение в подсистемы данного объекта.
Аналогично можно поступать с правами доступа, функциональными опциями, настройками командного интерфейса. Для того, чтобы настроить конфигуратор, нужно в меню Сервис выбрать пункт Параметры.
Откроется окно с достаточно большим количеством настроек и закладок.
На закладке Запуск 1С:Предприятия можно указать, какое приложение автоматически будет использоваться при запуске из конфигуратора (тонкий клиент, толстый клиент (управляемое приложение) и т.д.).
Если установлено значение Выбирать автоматически, то система будет ориентироваться на настройки самой конфигурации.
Внимание! Данная настройка влияет только на запуск из конфигуратора.
Здесь же можно настроить использование низкой скорости соединения (т.е. использование группировки данных, передаваемых на сервер, в пакеты).
При отладке, чтобы понять, как приложение работает на тонких каналах связи, можно настроить имитацию задержки при вызовах сервера.
На закладке Запуск 1С:Предприятие есть также подзакладка Дополнительные, где с помощью галочек можно установить ряд дополнительных параметров, которые влияют на запуск приложения из конфигуратора (будут ли отображаться показатели производительности, будет ли отображаться команда Все функции и т.д.).
На закладке Общие указывается: нужно ли только создавать объекты управляемого приложения или следует создавать объекты, которые есть и в обычном приложении.
На закладке Тексты можно настроить принципы редактирования и отображения текста (указываются шрифт, ширина табуляции и другие параметры).
На закладке Модули существует ряд подзакладок. Здесь настраивается, каким образом будет отображаться текст в модулях.
Каким образом будет выполняться Проверка, Группировка и Контекстная подсказка.
На закладке Справка указывается, каким образом будет выводиться справка.
Галочками можно указать те разделы, которые интересуют.
Чтобы получить возможность редактировать (видоизменять) типовую конфигурацию, необходимо в меню Конфигурация выбрать пункт Поддержка, далее Настройка поддержки.
Появится форма «Настройка поддержки». В данной форме следует нажать на кнопку Включить возможность изменения.
Система сделает предупреждение, что в дальнейшем невозможно будет обновлять конфигурацию полностью автоматически.
Если мы все же намерены вносить изменения, требуется нажать на кнопку Да. Появится окно «Настройка правил поддержки».
Если мы не стремимся к глобальным изменениям конфигурации, а будем пытаться обходиться лишь добавлением некоторых объектов, то изменять параметры по умолчанию в данной форме не стоит. Следует сразу нажать на кнопку ОК.
После этого нужно будет настроить правило поддержки для всей конфигурации в целом.
Для этого следует в табличной части формы «Настройка поддержки» в верхней строке (в которой указывается название конфигурации) в поле справа двойным кликом мыши вызвать форму «Настройка правил поддержки» (для данного объекта).
В появившейся форме необходимо выбрать правило Объект поставщика редактируется с сохранением поддержки и нажать на кнопку ОК.
Фому «Настройка поддержки следует закрыть». В результате произведенных действий у нас появится возможность добавления новых объектов. В окне конфигурации активизируется кнопка Добавить.
Если потребуется вносить изменения в уже существующие объекты конфигурации, то для каждого из этих объектов можно также изменить правило поддержки, как это мы сделали для всей конфигурации в целом.
Следует отметить, что программист не напрямую видоизменяет конфигурацию базы данных, а работает со своей конфигурацией, которая называется основной.
Если в основную конфигурацию были внесены какие-либо изменения, то в заголовке окна конфигурация появится маленькая звездочка (*).
Если основную конфигурацию требуется сохранить, то можно использовать пункт Сохранить из меню Файл или нажать соответствующую кнопку с пиктограммой дискеты.
В этом случае конфигурация базы данных еще не обновлена, о чем будет свидетельствовать восклицательный знак в названии окна «Конфигурация ».
Для обновления конфигурации базы данных в соответствии с произведенными программистом изменениями нужно вызвать пункт Обновить конфигурацию базы данных из меню Конфигурация, использовать клавишу F7 или соответствующую кнопку.
Чтобы запустить конфигурацию в пользовательском режиме можно выбрать пункт 1С:Предприятие из меню Сервис или использовать сочетание клавиш Ctrl+F5.
Можно запустить конфигурацию в режиме отладки (пункт Начать отладку из меню Отладка, клавиша F5 или соответствующая кнопка командной панели).
Отличие режима отладки от запуска в пользовательском режиме в том, что возможна остановка приложения в нужные моменты времени, считывание значений переменных и т.д.
При разработке в случае изменения конфигурации удобно сразу начинать отладку, система автоматически предложит сохранить базу данных, останется только дать подтверждение.
Если приложение запущено пользователем (не в режиме отладки), тем не менее при необходимости можно подключиться к процессу пользователя из конфигуратора и сделать отладку.
Сначала для заданного сеанса в режиме 1С:Предприятие через главное меню Сервис/Параметры нужно открыть окно «Параметры» и установить галочку Отладка в текущем режиме разрешена.
На будущее можно поставить галочку Устанавливать режим разрешения отладки при запуске.
После этого в конфигураторе нужно выбрать пункт Подключение из меню Отладка.
При этом появится окно «Предметы отладки» со списком процессов, которые можно отлаживать. В этом списке необходимо выбрать требуемый предмет отладки (сеанс пользователя) и осуществить к нему подключение нажатием на кнопку Подключить.
В следующих статьях цикла мы еще не раз будем обращаться к изучению возможностей конфигуратора. Так что не переживайте, если что-то в его интерфейсе вам пока не понятно.
Кстати, в следующей статье мы рассмотрим специальный инструмент конфигуратора – отладчик, без знания которого разработчику практически невозможно отладить свой программный код.
PDF-версия статьи для участников группы ВКонтакте
Если Вы еще не вступили в группу – сделайте это сейчас и в блоке ниже (на этой странице) появятся ссылка на скачивание материалов.
Статья в PDF-формате
Если Вы уже участник группы – нужно просто повторно авторизоваться в ВКонтакте, чтобы скрипт Вас узнал. В случае проблем решение стандартное: очистить кеш браузера или подписаться через другой браузер.
Комментарии / обсуждение (14):
Есть еще один полезный прием – быстро найти в дереве метаданных редактируемый объект по Ctrl+T
Понятие конфигурации и базы данных. Обзор трёх конфигураций, заложенных в любой информационной системе 1С.
Известно, что сама конфигурация необходима для того, чтобы определить структуру базы данных, то есть, какие будут таблицы в базе данных, какие поля, их типы данных, а также она содержит в себе алгоритмы, которые определяют, как реагировать на те или иные действия оператора.
Давайте рассмотрим это более детально. Что же действительно содержится внутри информационной базы? Информационная база, это достаточно большой блок информации, и, во-первых, в ней содержаться пользовательские данные. Иными словами, это некоторые элементы справочников, который формирует оператор, документы и данные в регистрах накопления. Помимо всего прочего, в информационной базе содержится, как минимум, две конфигурации. Это конфигурация основная, и конфигурация базы данных. Для файл-серверной архитектуры в обязательном порядке всё это содержится непосредственно в специальном файле, с названием 1cv8.1cd.
Для чего же нужны эти две конфигурации? Всё дело в том, что разработчик работает именно с основной конфигурацией. То есть, когда разработчик вносит какие-либо изменения, все изменения делаются именно в основной конфигурации. А с конфигурацией общей базы данных работают операторы, они обращаются к ней и вносят изменения в данные информационной базы.
Для чего необходима такая схема? Дело в том, что разработчик при такой схеме взаимодействия может менять основную конфигурацию, вносить в неё какие-либо изменения, а параллельно могут осуществлять работу операторы со своей конфигурацией. В тот момент, когда настанет необходимость синхронизации двух конфигураций, можно попросить пользователей выйти из информационной системы, когда разработчики будут готовы сделать обновление, и выполнить обновление конфигурации новой базы данных до основной конфигурации.
Кроме того, что существует две конфигурации, описанные выше, есть также и конфигурация поставщика. Её может не быть, если прикладное решение разрабатывалось с нуля, то есть из пустой информационной базы, но если база была установлена из шаблона и она находиться на поддержке поставщика, то здесь же, внутри информационной базы храниться конфигурация поставщика.
Стоит отметить, если возможность изменения не включена, то вполне очевидно, что все три конфигурации являются одинаковыми. В этом случае система не хранит конфигурацию поставщика, поскольку она точно такая же, как и основная.
Читайте также: