Доработки в 1с как сделать
Для того, чтобы Вам как заказчику, консультанту или методологу понять, что нужно разработчику 1С для того, чтобы доработать Вашу систему или разработать новую, нужно понимать, какими категориями информации он оперирует в ходе своей работы. Это сильно упростит программисту понимание того, что же от него хотят.
В данной статье я постараюсь кратко и, при этом, достаточно полно объяснить, что Вам нужно написать в техническом задании помимо общих разделов с глоссарием, титульным листом и описанием бизнес-требований.
Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.
Итак, приступим.
Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:
- Формы ввода информации
- Контрольные процедуры
- Модель данных
- Алгоритмы автоматического заполнения данных
- Формы вывода информации
Формы ввода информации
Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).
Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.
Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе.
Контрольные процедуры
В бизнес-процессах эти процедуры являются предварительными контролями, чтобы вам было понятно. Т.е. это такие контроли, которые система делает сама в тот момент, когда пользователь с той или иной ролью пытается работать с системой, и выдает предупреждение или намеренно прерывает работу пользователя, не позволяя ему выполнить задуманное.
В эту категорию попадают:
- Матрицы ролевого доступа
- Правила предоставления доступа к полям форм и данных
- Проверки корректности заполнения данных в формах ввода
- Процедуры сверки данных
Модель данных
Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.
Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:
- Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться
- Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода
- Поддержка иерархичности — нужна или нет
- Сколько данных планируется хранить
- Регулярность ввода и изменения этих данных
- Нужно ли хранить в одном объекте несколько таблиц данных, и если да, то с какими аналитиками, будет ли какой-либо другой объект ссылаться на записи этих таблиц
- Поддержка хранения данных с историей по датам — нужна или нет
- Поддержка расчета итогов на какую-либо дату, или оборотов за период — нужна или нет
- Поддержка двойной бухгалтерской записи — нужна или нет
- Поддержка вытесняющих графиков величин во времени — нужна или нет
- Поддержка процессов взаимодействия пользователей по объекту — нужна или нет
Алгоритмы автоматического заполнения данных
Если у Вас формы ввода содержат много полей или таблиц, Ваши пользователи вряд ли захотят каждый раз заполнять все поля с чистого листа.
Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.
Так же, здесь Вы продумываете зависимые автоматические заполнения форм ввода в зависимости от только что измененных полей пользователем. Например, после выбора номенклатуры пользователю не надо выбирать ее основную единицу измерения, система подставит ее по-умолчанию сама.
Формы вывода информации
В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.
Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.
Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.
Формы ввода и вывода часто могут объединяться с алгоритмами заполнения данных и контрольными процедурами в функциональные интерактивные АРМы пользователей, дополняться кнопками, вызывающими определенные действия и события в системе. Тем не менее, к ним применимы те же самые принципы написания технического задания, с учетом этих особенностей.
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.
Я ленивый, просто супер ленивый! (надеюсь, потенциальные работодатели не читают Инфостарт).
Мне лень хранить лишнюю информацию в голове, ведь на это тоже уходит энергия. Мне лень удерживать в своей оперативной памяти внутреннюю реализацию какого-либо функционала: хочется сразу протестировать, отладить и высвободить память.
Чтобы доработать, например, форму документа, после реализации каждого логически завершенного блока мне нужно завершить предыдущую отладку, обновить конфигурацию, запустить 1С:Предприятие в режиме отладки, открыть меню операции, выбрать подменю документы, напечатать первые несколько символов имени документа (да, да… мне лень помнить состав меню), найти отлаживаемый документ (еще и номер помнить!). Как же мне лень!
Насколько же проще отлаживать внешние обработки:
- Ctrl+S (сохранить)
- Alt+Tab (перейти из конфигуратора в окно 1С предприятия)
- Alt+A(Ф),1 (открыть последнюю обработку из меню «Файл»)
Решение: производить максимальное количество доработок, используя внешние обработки.
Приемы:
Самый простой вариант:
в случае если предполагается отладка на одном объекте, то просто копируем форму во внешнюю обработку, а в обработчике события «ПередОткрытием» формы прописываем всего 1 строчку, которую, естественно, нужно удалить перед возвратом формы в конфигурацию: или Для более удобной отладки на реальных данных дополнительно копируем форму списка и при открытии элемента из списка «заменяем» форму конфигурации на модифицируемую форму:
- Создаем внешнюю обработку.
- Копируем форму списка и форму документа (элемента) в обработку:
- Добавляем на форму документа (элемента) реквизит "Обработка":
- Для поля списка документа (справочника) реализуем обработчики событий ПередНачаломДобавления и ПередНачаломИзменения:
- Редактируем и отлаживаем форму документа (элемента) после чего возвращаем модуль формы обратно в конфигурацию или меняем форму целиком.
Для доработки нескольких форм документов или справочников копируем их формы во внешнюю обработку. Создаем основную форму обработки, из которой открываем модифицируемые формы.
При необходимости редактирования общего модуля – помещаем его в модуль обработки. В модулях форм меняем «имя общего модуля» на «имя общего модуля» + «суффикс» и добавляем реквизит формы (тип – внешняя обработка) с таким же именем.
Удобно при рефакторинге, выносе дублирующегося функционала форм в общий модуль.
- Создаем внешнюю обработку
- Копируем общий модуль в модуль обработки.
- Копируем 2 экземпляра каждой формы в обработку (одну для редактирования и резервную копию). Называем первую по имени объекта, вторую - имя объекта + "_bak":
- Добавляем на все формы реквизит с типом внешняя обработка и называем его ИмяОбщегоМодуля + "_Обработка":
- Меняем в модулях форм текст ИмяОбщегоМодуля + "." на ИмяОбщегоМодуля + "_Обработка.":
- Добавляем основную форму обработки, создаем поля ввода, соответствующие по наименованию именам форм. Реализуем для всех полей ввода общий обработчик события "Открытие":
- Редактируем и отлаживаем формы документов (элемента) после чего возвращаем все обработано в конфигурацию, не забыв произвести обратную замену ИмяОбщегоМодуля + "_Обработка." на ИмяОбщегоМодуля + ".".
На этапе внедрения бывает удобно сохранить форму документа (справочника) в дополнительных внешних отчетах для максимально быстрой доработки формы без обновления конфигурации. Для этого достаточно заменить обработчик события "ПередОткрытием" формы в конфигурации.
Основные средства в ходе деятельности любой организации теряют свои начальные свойства: изнашиваются, ломаются. Организации приходится нести затраты на обеспечение функционирования основных средств. Важно различать такие понятия, как ремонт и модернизация. При ремонте технические показатели основного средства не изменяются, а модернизация влечет за собой улучшение качеств основного средства. Приведу простой пример: дооборудование компьютера видеокартой.
Рассмотрим, каким образом провести модернизацию основных средств в 1С 8.3 Бухгалтерия предприятия 3.0.
На 01.01.2019 на балансе организации находится основное средство “Компьютер Samsung” стоимостью 120 000 рублей и сроком полезного использования 40 месяцев. Компьютер использовался в течение года, сумма накопленной амортизации составила 36 000 рублей.
Сформируем отчет “Ведомость амортизации ОС”, чтобы посмотреть начальные данные по нашему основному средству.
В документе указываем:
- поставщика и договор, по которому приобретаем видеокарту;
- номенклатуру, количество и цену;
- счет учета 10.06 “Прочие материалы”.
Получите понятные самоучители по 1С бесплатно:
На закладке “Материалы” указываем номенклатуру, количество и счет списания 10.06.
На закладке ”Счет затрат”:
- указываем счет 08.03 “Строительство объектов основных средств”;
- объект строительства, который будем модернизировать. Для этого нужно создать новый элемент в справочнике;
- статью затрат “Списание материалов”;
- способ строительства “Подрядный”.
При проведении документа сформирована проводка по списанию материала с кредита счета 10.06 в дебет счета 08.03.
В отчете “Анализ счета” по счету 08.03 мы можем посмотреть общую сумму затрат, которые увеличат первоначальную стоимость основного средства.
На закладке “Объект строительства” укажем объект модернизации, счет 08.03. По кнопке “Рассчитать суммы” автоматически будет определена сумма затрат по счету 08.03.
На закладке “Основные средства” укажем наш компьютер и нажмем кнопку “Распределить”. При этом сумма затрат на модернизацию распределится поровну по всем указанным основным средствам. При необходимости можно изменить срок полезного использования основного средства. В рассматриваемом примере срок полезного использования не изменился.
При проведении документа сформирована проводка, которая отражает увеличение первоначальной стоимости основного средства.
Проверим расчет амортизации основного средства после модернизации.
Расчет произошел следующим образом: Остаточная стоимость ОС / Оставшийся срок полезного использования: 93 500 / 27 месяцев = 3 462,96 рублей.
1. Лучшая доработка, это доработка без изменения конфигурации. Если возможно, используем справочник "Внешние отчеты и обработки"
2. Если без доработок никак, стараемся создавать новые объекты, в частности:
2.1. При добавлении новых объектов, реквизитов обязательно добавляем префикс
2.2. Создаем общие модуля (для сервера, клиента и пр.), куда стараемся переносить все изменения. Остальные модули вызывают данный код.
2.3. Используем подписки на события для проверки значений, корректировки проведения документов.
2.3. Для новых объектов лучше создать новую роль, а не редактировать старую
2.4. Все новые и измененные объекты включаем в специально созданную для этого подсистему
3. Если необходимо изменить код модуля:
3.1. Выделяем комментарием все сделанные изменения, причем комментарий должен позволять однозначно найти все изменения конфигурации (используя глобальный поиск) и при этом не дать лишних строк. Желательно добавлять метку задачи (код), в рамках которой были изменения, дату и автора решения.
3.2. Старый код не удаляем, а оставляем закомментированным
3.3. Комментарий добавляем перед и после изменений, с открывающим и закрывающим символом соответственно (например: + и -)
3.4. Самое главное, чего, собственно, нигде не встречал и что сильно упрощает жизнь, создаем процедуру "НеТиповыеИзменения". Данная процедура должна содержать в себе копию всех комментариев по сделанным изменениям с указанием процедур в которых были внесены данные изменения . Т.е. при сравнении/объединении модуля мы вначале определяем процедуры, содержащие изменения, и не проходим по всем процедурам модуля.
Как пример на примере пункта 3.5 в конце модуля добавляется процедура:
3.5. С пасибо unichkin. Все изменения по возможности выносить в отдельные процедуры, как один из минусов сложность в анализе изменений в одном месте, отлично подходит при отсутствии пункта 3.4, пример:
3.6 Спасибо Armando . В форме можно переопределять обработчики на свои, а из своих в нужный момент вызывать типовые. Тогда в большинстве случаев процедуры-обработчики событий можно смело заменять и даже дописывать в них ничего не придется:
4. Если необходимо изменить форму:
4.1. Описываем все изменения в процедуре " НеТиповыеИзменения " см. 3.4.
4.2. Кнопки и поля формы возможно добавлять программно, как и настраивать их первоначальную видимость/доступность.
5. Спасибо unichkin. Внедрения стандартов разработки (например: Система стандартов и методик разработки конфигураций для платформы 1С:Предприятие 8 . ), позволит быстрее воспринимать код другого программиста.
Ссылки по теме (для меня это lvl-up, можно рассматривать как продолжение статьи):
Готов выслушать критику, советы по улучшению статьи как с точки зрения содержания, так и с точки зрения оформления.
Разумеется, в первую очередь доработка нужна компаниям, которые предлагают подобные услуги, тут без комментариев. Но зачем в принципе организации заказывают разработку при обилии самых разнообразных продуктов от 1С? Предлагаю узнать об этом немного подробнее, а также обсудить, как лучше всего подготовиться к доработке со стороны заказчика.
Официальных продуктов 1С великое множество и каждый из них имеет действительно широкий функционал. Дальше, как вы понимаете, пойдет НО. Все так — существует специфика отрасли, специфика вашего бизнеса и многие другие нюансы, под которые основной продукт не заточен. Помните, что программы создаются универсальными, чтобы ими могли пользоваться организации самых разных направлений, а вот заточить 1С именно под вашу контору помогает доработка.
Что конкретно она дает? Грамотном подходе вы можете получить:
- повышение скорости работы с программой;
- автоматизацию ряда процессов;
- оптимизацию бизнес-процессов, на которые напрямую влияет работа с программой.
Так как доработки могут быть самыми разнообразными, приведу здесь самые распространенные из них:
автоматизация определенных бизнес-процессов;
Глупо заказывать доработку, не ознакомившись с тем, что уже есть на рынке. Возможно, что для вашего бизнеса давно существует готовое решение, которое остается только приобрести. Чтобы не выкинуть деньги, я рекомендую для начала поискать в сети подходящие варианты 1С.
Отраслевых конфигураций достаточно много - для гостиничного, ресторанного бизнеса, туризма и даже муниципальных служб. Не буду приводить даже половину того, что на настоящий момент существует — это тема для отдельной немаленькой статьи.
Могу сказать одно: перед заказом тщательно поищите решение среди продуктов, это поможет существенно сэкономить и даст возможность получить уже проверенный, протестированный и поправленный вариант.
Итак, вы не нашли подходящего продукта, но хотите получить удобное решение, подходящее вашему предприятию. Следующим шагом, разумеется, необходимо найти исполнителя. Не буду подробно останавливаться на этом — рынок сегодня переполнен, всегда можно посмотреть портфолио, отзывы, в общем, с выбором особых проблем не возникнет. Но на этом ваше участие в процессе не заканчивается. Перед началом работ специалистов, необходимо составить все требования к программе.
Кто должен участвовать в составлении списка требований?Разумеется, не существует ответа, единого для всех организаций. По опыту, со стороны разработчика, могу сказать, что удобнее всего взаимодействовать с одним человеком. Но если речь идет о крупной доработке, затрагивающей многие процессы, важно, чтобы учитывались потребности всех задействованных отделов. Как быть? Я могу предложить следующий подход:
- Руководитель назначает одного из сотрудников главным по проекту (либо занимается им самостоятельно).
- Ответственный сотрудник составляет список отделов, которые будут взаимодействовать с программой, пожелания руководителя компании и прочие замечания.
- Ответственный сотрудник общается с руководителями отделов, чтобы зафиксировать все особенно важные моменты.
- Информация передается специалисту от разработчиков и обсуждается с ним.
- Сформированное техническое задание согласовывается с руководителем и отправляется в работу.
Помните, основная ошибка при составлении технического задания - однобокий взгляд одного специалиста. Обязательно поговорите с персоналом, соберите мнения, поймите, как еще можно оптимизировать работу. Только тогда доработка будет действительно эффективной!
Читайте также: