Мне тут пришлось писать методичку для стажеров и программистов по внесению изменений в типовые конфигурации. Вдруг и вам будет полезна.
Разумеется, не утверждаю, что я во всём прав. Наверное, нет правильных правил внесения изменений – у каждого свои приёмы, проверенные временем. Поэтому конструктивная критика и предложения приветствуются.
Для кого делаются доработки
Примите за правило: с вашими доработками будет возиться полный идиот. Он не будет знать вас, вашу компанию, решаемую задачу, заказчика и т.д.
Я не к тому, что надо всё разжевывать, комментировать и использовать человекочитаемые имена переменных. Вам решать, какое сообщение вы хотите до идиота донести. Просто помните, что он будет, идиот-то.
Можете вволю над ним поиздеваться. Можете ему помочь. Можете позаботиться об организации. Можете очистить карму, сделав всё правильно.
Всё равно идиот скажет, что вы написали говнокод.
Типы конфигураций
Когда принимаете решение о внесении изменений – учитывайте, с какой конфигурацией работаете. Принципиально их можно разделить на четыре типа.
Первый – современные, бешено развивающиеся конфигурации. Сюда относятся ERP, УТ 11, КА 2. При их доработке надо быть чертовски аккуратным, потому что в следующем релизе может измениться всё, что угодно. Вплоть до того, что объект, который вы доработали, исчезнет под какой-нибудь функциональной опцией типа «Для староверов». В такие конфигурации изменения вносить опасно, и делать это надо с оглядкой на планы разработчиков. Вполне вероятно, что функциональность, которую просит клиент, появится через пару месяцев в типовой.
Второй – современные, но консервативные конфигурации. Сюда относятся БП, ЗУП. Консервативные они потому, что пользователи у них не большие выдумщики – бухгалтеры, расчетчики, кадровики, и бОльшая часть функциональности конфигураций регламентирована законодательством – сильно не разбежишься при разработке. К тому же, действуют законы продуктового маркетинга – «маленькие» конфигурации не могут и не будут повторять функциональность «больших», иначе никто не будет покупать ERP. В такие конфигурации вносить изменения можно и нужно. Но и сюрпризы бывают – например, в БП3 появился путевой лист, которые многие разрабатывали сами.
Третий тип – полумёртвые конфигурации, вроде УПП, УТ 10.3, БП 2. Вообще, они почти не развиваются, в части основной функциональности. Но, особенно в последнее время, в них вносят кучу изменений по части вспомогательной функциональности, вроде маркировки, которую неожиданно запихали во всякое старьё (хотя полгода назад говорили, что не будут). В полумёртвых конфигурациях опасными для изменений являются модули всяких маркировок, ЭДО, регл.отчетности – в них регулярно что-то прилетает. Основные же модули и объекты почти не трогают, и можно смело вносить изменения.
Четвертый тип – мёртвые конфигурации, вроде КА1. Среди конфигураций от 1С таких немного, а среди отраслевых – полно. Вплоть до того, что не существует уже компании-разработчика и конфигурацию тупо не купить. Вот тут полный простор для творчества – испортить уже невозможно.
Префиксы добавляемых объектов
У всех добавляемых объектов – неважно, справочник это, или реквизит документа – должен быть префикс. Отсутствие префикса обычно говорит либо о беспросветной тупости, либо о перетаскивании объекта из другой типовой конфигурации, либо о том, что программисту стыдно за этот объект.
Для франча префикс должен коррелировать с названием компании или бренда (типа «бит», «сс» и т.д.).
Для завода вынужден рекомендовать какой-нибудь префикс, коррелирующий с названием организации. Например, если завод называется «Уренгойские штаны», то префиксом может быть «уш». Однако, чисто из жизненного опыта – лучше префикс «ит», который означает «ИТ-отдел», и когда на новой работе будете таскать доработки со старой, не придется переделывать префиксы и код.
Для фрилансеров рекомендую «гв», «гн», «др», «ср» и т.д. – сразу понятно, что вы заходили ненадолго, сделали своё дело и ушли.
Префикс лучше делать с подчеркиванием («бит_», «сс_», «ит_»). Вообще, выглядит лучше без подчеркивания, но визуально проще заметить подчеркнутый префикс.
Подсистемы для объектов
Если задача напрямую не содержит прямого указания о включении доработок в определенную типовую подсистему, то создавайте свою.
Понятное дело – если вы пишете пару функций своего общего модуля, то не надо свою подсистему отображать в интерфейсе.
В платформе есть прекрасные возможности сравнения/объединения и фильтрации по подсистемам, даже если это толстый клиент и какая-нибудь УПП. Подсистема выступит просто как носитель группировки объектов.
Не забывайте, что подсистемы иерархичны, и если вы делаете значительный объем доработок, относящихся к разным предметным областям (продажи, закупки, бух.учет и т.д.), то неплохо бы разнести их по разным подсистемам, подчиненным одной, главной, держащей все добавленные объекты.
Да, разумеется, не надо в свою подсистему добавлять типовые объекты.
Маркировка изменений
Маркер изменений должен содержать тот же префикс, что и добавленные объекты. Не надо издеваться над идиотами, используя разные буквы в префиксах и маркерах – они этого не переживут.
Маркируются любые изменения в коде – добавление, удаление, изменение. При изменении и удалении кода обязательно оставлять закомментированный исходный код, ничего к нему не добавляя, в т.ч. пробелы.
Маркер должен содержать фамилию того, кто вносит изменения. Допустимо использовать какой-нибудь четырехзначный код вместо фамилии, если это принято в вашей компании.
Маркер обязательно должен содержать дату внесения изменений. Время не нужно.
Маркер должен содержать комментарий, поясняющий изменения. Если вы вносите несколько изменений в одну процедуру/функцию, то развернутый комментарий достаточно дать в одном из маркеров, а в остальных написать пару слов, обозначающих принадлежность изменений к одной задаче.
Номер задачи вносить в маркер есть смысл только в том случае, если ведется какой-то бесконечный реестр этих задач, и у идиота будет к нему доступ через несколько лет. Иначе смысла нет.
Изменение типовых запросов
Вообще, лучше так не делать.
В большинстве случаев, если вам понадобилось изменить типовой запрос – вы что-то делаете не так. Исключения бывают, но редко.
Например, если вам надо поменять запрос, заполняющий таб.часть – пишите обработку заполнения табличной части.
Если вам надо поменять запрос в типовой печатной форме – пишите внешнюю.
Если вам надо поменять запрос в отчете, делайте свой отчет.
Если вам надо поменять запрос в общих модулях зарплаты или страховых взносов, то мне вас искренне жаль. Всеми силами постарайтесь этого избежать.
Принципиально есть три варианта внесения изменений: закомментировать типовой запрос и написать свой, внести точечные маркированные изменения в типовой, подменить типовой своим на выходе.
Закомментировать запрос целиком – самая простая в реализации, но самая дурацкая идея, потому что никакой идиот не справится потом с обновлением, которое будет содержать изменения того же запроса – сравнивалка/объединялка просто не сможет понять, что новый типовой и старый, но закомментированный – одно и то же.
Второй по простоте вариант – подменить текст запроса перед его выполнением. Например, в коде написано Запрос.Текст = тырыпыры, а вы после этой строки добавляете свою – вызываете функцию своего общего модуля, которая переопределяет текст запроса (лучше вынести свой текст в отдельную функцию, чтобы не оставлять длинную портянку, увеличивая трудность обновления).
В этом варианте будет меньше проблем при сравнении/объединении – по сути, он покажет изменения в трех строках, где вы вызываете функцию с переопределением текста + две строки маркера. Но если разработчики типовой внесли в запрос существенные изменения, меняющие состав полей или вообще источники данных, и последующий код поменялся, то несчастного идиота ждет треш – по сути, надо будет решить задачу заново.
Самый сложный вариант – внесение точечных изменений. Например, есть запрос, а вам надо в него условие добавить – достаточно в тексте внести 1-2 маркированных строки с изменениями. Тогда весь текст запроса будет сравниваться с типовым, как обычный текст, и нормально найдет ваши пару строк.
Главная проблема этого варианта – невозможность внесения изменений конструктором запросов. Открыться-то он откроется, но нажмете ОК – и все маркеры исчезнут. Поэтому доработка таких, уже доработанных, запросов – не самое приятное дело. Надо открыть запрос конструктором, внести изменения, а потом скопировать текст, не нажимая ОК. Отладить запрос нужно будет где-то в другом месте, типа консоли.
Если изменений в запросе много, и вы не знаете, что и как лучше промаркировать, то просто сохраните исходный и измененный текст в виде текстовых файлов и сравните их (да, 1С прекрасно умеет сравнивать текстовые файлы). Дальше дело техники.
Ну и напоследок – если вы знаете, что запрос не бешеный, выполняется быстро, и вам надо всего лишь добавить сортировку, фильтр, или простой пересчет значения какого-то поля, то сделайте лучше постобработку – например, отсортировав или отфильтровав таблицу значений, в которую результат запроса выгрузился (если там таблица значений, конечно).
Еще раз повторю: если вы хотите внести изменения в типовой запрос, то вы что-то делаете не так.
Добавление новых ссылочных объектов
Сначала стандартная рекомендация: убедитесь, что объекта, который вы хотите добавить, в типовой нет. Не по названию, а по назначению. Если конфигурация незнакомая, спросите у того, кто в ней шарит.
А то знаете ведь как бывает: говорит клиент программисту «сделай мне, чтобы были разные прейскуранты, оптовый и розничный». Программист ищет по слову «прейскурант», не находит, и добавляет. И ладно если справочник – перечисление ведь, морда, добавит, со значениями «Оптовый» и «Розничный». А совсем недалеко лежит справочник «Типы цен».
Вторая рекомендация нестандартная: еще раз подумайте, нужен ли вам этот объект. Особенно, если у клиента – тяжелая база. Потому что вы задолбаетесь его потом удалять.
Проблема в чем: в некоторых конфигурациях, вроде УПП, есть объекты с реквизитами типа ЛюбаяСсылка, или СправочникСсылка, и добавленный вами справочник влезет в состав типов. Но на этом этапе вы никаких трудностей не испытаете.
А вот когда поймете, что объект не нужен, удалите его из конфигурации и нажмете F7, то испытаете удовольствие – зависнет на несколько часов, а то и суток, на реструктуризации какого-нибудь регистра сведений ВерсииОбъектов. Тут как дерево – влезть легко, слезть трудно.
Но спешу обрадовать: если брать основную массу клиентов франча, то там такой проблемы не бывает.
Если всё же столкнулись с проблемой, то можно методом Простоквашино воспользоваться: поменять имя объекта на Заготовка1, удалить все его реквизиты, элементы этого справочника (или кто у вас там), и написать в комментарии к объекту «Справочник ничей, берите кто хотите, только не удаляйте – не дождётесь реструктуризации».
А так – добавляйте свои объекты, это совершенно нормально и к проблемам не приведёт. С учетом рекомендаций, данных выше.
Добавление реквизитов в ссылочные объекты
Добавляйте, сколько хотите. Это один из самых безобидных видов доработки.
Тут, конечно, тоже есть вероятность наткнуться на долгую реструктуризацию, но она очень низка. Просто интересуйтесь до начала работы размером базы или количеством объектов нужного вам типа, и, если цифры вас напугают – будьте внимательны и проверяйте скорость реструктуризации на тестовой базе. Просто добавьте реквизит и нажмите F7.
Принципиально есть два пути, если хочется, чтобы у справочника или документа появился реквизит: добавить его в объект или использовать механизмы доп.реквизитов. Второй вариант хорош тем, что не надо конфигурацию дорабатывать – если это критично, то пользуйтесь доп.реквизитами. Типовые отчеты будут нормально их показывать, фильтроваться и сортироваться – там использование доп.реквизитов предусмотрено. А вот все нетиповые отчеты, конечно, сядут в лужу.
В современных конфигурациях доп.реквизиты лежат в табличной части самого объекта, и пользоваться ими легко, в т.ч. благодаря возможности указать имя доп.реквизита. Ну и обвес есть, типа получения значения конкретного доп. реквизита.
В старых конфигурациях, вроде УПП или УТ 10.3, доп. реквизиты лежат в регистре сведений – одном на всех. Обращаться к нему уже сложнее, хотя бы из соображений производительности. Но в некоторых случаях он удобнее – например, если надо получить значение одного и того же свойства у объектов разных типов. В современных конфигурациях пришлось писать бы сложный запрос и не забывать его обновлять при изменении состава назначений доп.свойства.
Добавление реквизита в конфигурацию, если это допустимо условиями клиента – лучше. Этот реквизит сразу появится во всех отчетах, настройках дин.списков, его можно будет использовать в коде без обвеса.
Добавление чего-нибудь в регистры накопления
Как правило, добавлять измерения/ресурсы/реквизиты в регистры накопления – не стоит. Делая это, надо быть уверенным в себе.
Добавить-то легко, но потом надо будет найти все места в коде, которые в этот регистр пишут, и внести изменения, чтобы ваше поле тоже заполнялось.
Дальше вилка. Если это оборотный регистр, то пофиг – проблем не будет, даже если один документ будет заполнять ваше измерение, а второй не будет.
Если же регистр остаточный, и в приходе у вас будет заполняться новое измерение, а в расходе – не будет, то регистр тупо перестанет закрываться. А это жуткий косяк разработчика. И методически, и технически (если не заметят, через пару лет реальная и виртуальные таблицы регистра будут весить жуткие гигабайты).
Примерно то же самое с ресурсами. Если вы добавите в регистр товаров «Количество2», но забудете его минусовать, то таблица остатков будет пухнуть – ей же придётся помнить все остатки за всю историю в разрезе всех измерений.
Реквизиты добавляйте, если надо. Другое дело, что в регистрах накопления ими редко пользуются, только от безысходности – например, в регистрах УчетЗатрат, чтобы хранить кор.аналитику. Не забывайте, что значения реквизитов доступны только в реальной таблице регистра, а в остатках/оборотах их не будет.
Самые безопасные, повторю – оборотные регистры, особенно узкого назначения (а они почти все такие), типа ВыпускПродукции, Продажи – в них пишет не много документов, и найти все точки записи легко.
Зачастую, если вам надо сделать расширение аналитики остаточного регистра, проще поставить рядом такой же и добавить, чего вам там надо. В таком случае источником для записи в ваш регистр может служить «родительский» - можно тупо подписаться на событие его записи (если объем данных небольшой). Если же задача про большие объемы данных, то лучше сделать обработку/регламентный документ, который будет заполнять ваш регистр на основе родительского.
Добавление нового регистра накопления или регистра сведений, подчиненного регистратору
Добавляйте, сколько хотите. Главное – не поганьте типовые модули при формировании движений. Сделайте подписку на проведение документа, и там формируйте свои движения.
Если при этом надо получить что-то из типовой обработки проведения, то для этого есть ДополнительныеСвойства – предопределенное свойство любого объекта, в которое можно засунуть практически всё, что угодно. При этом посмотрите сначала на типовой код – вполне возможно, там уже весь контекст в объект засунут. Если же нет, добавьте одну строчку, которая поместит нужные вам данные в ДополнительныеСвойства – например, обработанную таблицу товаров или текущие остатки для контроля.
Не забудьте про очистку движений. Обычно, в типовых документах, используется универсальная процедура общего модуля для удаления движений. Ей пофиг, типовой регистр или ваш – она спросит у метаданных, и почистит всё, что найдет. В этом случае париться не надо.
Можно в свойствах регистра оставить автоматическое удаление движений при отмене проведения.
