Правила жёлтого напильника

Публикация № 1253087

Разработка - Практика программирования

Как вносить изменения в типовые конфигурации при решении задач

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

Разумеется, не утверждаю, что я во всём прав. Наверное, нет правильных правил внесения изменений – у каждого свои приёмы, проверенные временем. Поэтому конструктивная критика и предложения приветствуются.

Для кого делаются доработки

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

Я не к тому, что надо всё разжевывать, комментировать и использовать человекочитаемые имена переменных. Вам решать, какое сообщение вы хотите до идиота донести. Просто помните, что он будет, идиот-то.

Можете вволю над ним поиздеваться. Можете ему помочь. Можете позаботиться об организации. Можете очистить карму, сделав всё правильно.

Всё равно идиот скажет, что вы написали говнокод.

Типы конфигураций

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

Первый – современные, бешено развивающиеся конфигурации. Сюда относятся ERP, УТ 11, КА 2. При их доработке надо быть чертовски аккуратным, потому что в следующем релизе может измениться всё, что угодно. Вплоть до того, что объект, который вы доработали, исчезнет под какой-нибудь функциональной опцией типа «Для староверов». В такие конфигурации изменения вносить опасно, и делать это надо с оглядкой на планы разработчиков. Вполне вероятно, что функциональность, которую просит клиент, появится через пару месяцев в типовой.

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

Третий тип – полумёртвые конфигурации, вроде УПП, УТ 10.3, БП 2. Вообще, они почти не развиваются, в части основной функциональности. Но, особенно в последнее время, в них вносят кучу изменений по части вспомогательной функциональности, вроде маркировки, которую неожиданно запихали во всякое старьё (хотя полгода назад говорили, что не будут). В полумёртвых конфигурациях опасными для изменений являются модули всяких маркировок, ЭДО, регл.отчетности – в них регулярно что-то прилетает. Основные же модули и объекты почти не трогают, и можно смело вносить изменения.

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

Префиксы добавляемых объектов

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

Для франча префикс должен коррелировать с названием компании или бренда (типа «бит», «сс» и т.д.).

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

Для фрилансеров рекомендую «гв», «гн», «др», «ср» и т.д. – сразу понятно, что вы заходили ненадолго, сделали своё дело и ушли.

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

Подсистемы для объектов

Если задача напрямую не содержит прямого указания о включении доработок в определенную типовую подсистему, то создавайте свою.

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

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

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

Да, разумеется, не надо в свою подсистему добавлять типовые объекты.

Маркировка изменений

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

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

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

Маркер обязательно должен содержать дату внесения изменений. Время не нужно.

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

Номер задачи вносить в маркер есть смысл только в том случае, если ведется какой-то бесконечный реестр этих задач, и у идиота будет к нему доступ через несколько лет. Иначе смысла нет.

Изменение типовых запросов

Вообще, лучше так не делать.

В большинстве случаев, если вам понадобилось изменить типовой запрос – вы что-то делаете не так. Исключения бывают, но редко.

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

Если вам надо поменять запрос в типовой печатной форме – пишите внешнюю.

Если вам надо поменять запрос в отчете, делайте свой отчет.

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

Принципиально есть три варианта внесения изменений: закомментировать типовой запрос и написать свой, внести точечные маркированные изменения в типовой, подменить типовой своим на выходе.

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

Второй по простоте вариант – подменить текст запроса перед его выполнением. Например, в коде написано Запрос.Текст = тырыпыры, а вы после этой строки добавляете свою – вызываете функцию своего общего модуля, которая переопределяет текст запроса (лучше вынести свой текст в отдельную функцию, чтобы не оставлять длинную портянку, увеличивая трудность обновления).

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

Самый сложный вариант – внесение точечных изменений. Например, есть запрос, а вам надо в него условие добавить – достаточно в тексте внести 1-2 маркированных строки с изменениями. Тогда весь текст запроса будет сравниваться с типовым, как обычный текст, и нормально найдет ваши пару строк.

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

Если изменений в запросе много, и вы не знаете, что и как лучше промаркировать, то просто сохраните исходный и измененный текст в виде текстовых файлов и сравните их (да, 1С прекрасно умеет сравнивать текстовые файлы). Дальше дело техники.

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

Еще раз повторю: если вы хотите внести изменения в типовой запрос, то вы что-то делаете не так.

Добавление новых ссылочных объектов

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

А то знаете ведь как бывает: говорит клиент программисту «сделай мне, чтобы были разные прейскуранты, оптовый и розничный». Программист ищет по слову «прейскурант», не находит, и добавляет. И ладно если справочник – перечисление ведь, морда, добавит, со значениями «Оптовый» и «Розничный». А совсем недалеко лежит справочник «Типы цен».

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

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

А вот когда поймете, что объект не нужен, удалите его из конфигурации и нажмете F7, то испытаете удовольствие – зависнет на несколько часов, а то и суток, на реструктуризации какого-нибудь регистра сведений ВерсииОбъектов. Тут как дерево – влезть легко, слезть трудно.

Но спешу обрадовать: если брать основную массу клиентов франча, то там такой проблемы не бывает.

Если всё же столкнулись с проблемой, то можно методом Простоквашино воспользоваться: поменять имя объекта на Заготовка1, удалить все его реквизиты, элементы этого справочника (или кто у вас там), и написать в комментарии к объекту «Справочник ничей, берите кто хотите, только не удаляйте – не дождётесь реструктуризации».

А так – добавляйте свои объекты, это совершенно нормально и к проблемам не приведёт. С учетом рекомендаций, данных выше.

Добавление реквизитов в ссылочные объекты

Добавляйте, сколько хотите. Это один из самых безобидных видов доработки.

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

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

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

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

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

Добавление чего-нибудь в регистры накопления

Как правило, добавлять измерения/ресурсы/реквизиты в регистры накопления – не стоит. Делая это, надо быть уверенным в себе.

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

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

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

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

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

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

Зачастую, если вам надо сделать расширение аналитики остаточного регистра, проще поставить рядом такой же и добавить, чего вам там надо. В таком случае источником для записи в ваш регистр может служить «родительский» - можно тупо подписаться на событие его записи (если объем данных небольшой). Если же задача про большие объемы данных, то лучше сделать обработку/регламентный документ, который будет заполнять ваш регистр на основе родительского.

Добавление нового регистра накопления или регистра сведений, подчиненного регистратору

Добавляйте, сколько хотите. Главное – не поганьте типовые модули при формировании движений. Сделайте подписку на проведение документа, и там формируйте свои движения.

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

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

Можно в свойствах регистра оставить автоматическое удаление движений при отмене проведения.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Rustig 1533 19.06.20 10:16 Сейчас в теме
Не забудьте в процедуре обработки проведения, которую пишете, проверить в начале на Источник.ОбменДанными.Загрузка, чтобы не формировать движения для объекта, прилетевшего с обменом.


Конструкция кода вида:

Документ.ОбменДанными.Загрузка = Истина;
Документ.Записать(РежимЗаписиДокумента.Проведение);

вызывает исключение! поскольку проводить в режиме обмена нельзя

Поэтому вопрос: как понять вашу рекомендацию?

В типовых ни разу не видел, чтобы в процедуре проведения стояла такая проверка.
echo77; байт; awk; +3 Ответить
2. Drivingblind 127 19.06.20 10:21 Сейчас в теме
(1) много где так.
Вот пример из модуля документа ПриобретениеТоваровУслуг в ERP:
Процедура ПередЗаписью(Отказ, РежимЗаписи, РежимПроведения)
	
	Если ОбменДанными.Загрузка Тогда
		Возврат;
	КонецЕсли;
<.....>
КонецПроцедуры

вот статья по этому вопросу на ИТС: https://its.1c.ru/db/v8std#content:773:hdoc
3. Rustig 1533 19.06.20 10:37 Сейчас в теме
(2) Дривинблинд, читайте внимательно публикацию и комменты
pavlov_dv; Andreeei; Fox-trot; +3 Ответить
7. Drivingblind 127 19.06.20 10:52 Сейчас в теме
(3) извиняюсь. Поторопился
9. Rustig 1533 19.06.20 10:57 Сейчас в теме
4. 1c-intelligence 10353 19.06.20 10:41 Сейчас в теме
(1) да, вы правы, не обратил на это внимание, что такая проверка перед/при записи делаться должна. Исправлю.
5. Rustig 1533 19.06.20 10:43 Сейчас в теме
(4) у вас тут новосибирская поддержка? не глядя, заступаются :)
6. 1c-intelligence 10353 19.06.20 10:47 Сейчас в теме
(5) а я не знаю, что такое новосибирская поддержка.
8. Rustig 1533 19.06.20 10:57 Сейчас в теме
(6) :) ладно, проехали)))
(7) все нормуль :)
37. &rew 23 22.06.20 07:11 Сейчас в теме
(6)"Я свидетель! Что случилось?"
40. ILM 238 22.06.20 09:41 Сейчас в теме
(6) Нас надо знать в лицо. Приедете в Новосибирск, Вас поддержат!
17. json 2679 19.06.20 13:47 Сейчас в теме
(1) вот так надо делать при обмене, чтобы не было ошибки:

Документ.ОбменДанными.Загрузка = Истина;
Документ.Проведен = Источник.Проведен;
Документ.Записать(РежимЗаписиДокумента.Запись);


А движения приходят отдельным потоком
i.s.o; vdscom; +2 Ответить
19. Rustig 1533 19.06.20 14:01 Сейчас в теме
(17) 1) во второй строке лишнее слово ОбменДанными, а то получается что у свойства ОбменДанными есть свойство Проведен....
2) при обмене поле Документ.Проведен чаще всего равен автоматом полю Источник.Проведен. Это зависит от правил обмена, и в правилах регулируется. Дополнительно прописывать такую конструкцию мне кажется не надо.
3) в процедуре ПередЗаписью нет переменной Источник. Поэтому будет синтаксическая ошибка.

Для разных конфигураций движения отличаются, например для обмена УТ-БП....
Отдельным потоком не представляю по каким правилам они приходят.
Мне кажется проще провести документ отдельной командой, если он проведенный, тогда он сам сделает все нужные движения.
20. json 2679 19.06.20 14:16 Сейчас в теме
(19)
1. Исправил
3. Это прописывается в правилах обмена, а не в процедуре ПередЗаписью(). В типовых правилах есть переменная Источник, из которой заполняется объект

Если конфигурация идентичная и это просто узлы одной системы, то движения могут ходить.
Если конфигурации разные, то тогда обычно проведение выполняется отдельным регл. заданием. А документы для проведения помещаются в регистр, по которому работает это регл. задание
10. Synoecium 698 19.06.20 11:24 Сейчас в теме
неплохо, но тема слабо раскрыта.
1) Изменение ролей - если вам приходится менять типовые роли, вы свернули не туда. Сделайте лучше дополнительную роль с доступом к новым объектам (можно даже к типовым объектам, но лучше не надо). Копировать типовую роль и добавлять туда новые объекты тоже плохой тон
2) Добавление предопределенных значений - лучше в типовые объекты их не добавлять, велик риск потерять при обновлении. Сделайте лучше отдельный справочник предопределенных значений с значением любого типа и допиливайте его себе на здоровье. Идиот будет счастлив
3) Изменение элементов/реквизитов форм. Вообще, на сегодняшний день, я считаю что все изменения форм в типовых конфигурациях на УФ должны выполняться программно. Для этого есть переопределямые модули в современных конфигурациях, а в тех, что попроще, такие модули можно добавить 1 раз и пользоваться всю жизнь. Идиот конечно будет сильно озадачен как оно так все происходит, но после первого обновления скажет вам спасибо
4) Насчет изменения запросов, рекомендую попробовать новый объект СхемаЗапроса. С его помощью можно гораздо меньше зависеть от структуры и типовых изменений исходного запроса. Добавление полей, например, делается парой строчек. Еще парой строчек кода можно присобачить левым соединением какой-нибудь регистр сведений с нужными данными. На поля и таблицы из схемы можно опираться в своем алгоритме и прописать разные ветки условий и т.д. Для идиота это будет выглядеть сложно, но ему в любом случае будет сложно, зато мы получим некоторую устойчивость доработки к изменениям. Кстати, через схему запроса можно также дорабатывать запрос из динамического списка, что немаловажно, так как доступа к тексту запроса в модулях нет.
5) Изменение определяемых типов - лучше их не изменять. Опять же высок риск потерять изменения при обновлении, к тому же можно неявно расширить тип какого-нибудь регистратора или измерения в регистре, что может вылиться в проблемы схожие с "Добавление чего-нибудь в регистры накопления"
igee12; trest30; байт; Darklight; mip128; Rustig; +6 Ответить
11. 1c-intelligence 10353 19.06.20 11:27 Сейчас в теме
(10) до этого еще руки не дошли просто.
15. ipoloskov 121 19.06.20 12:34 Сейчас в теме
(10)
Изменение определяемых типов - лучше их не изменять. Опять же высок риск потерять изменения при обновлении

Я разработал методику, как обезопасить себя от потери данных: https://infostart.ru/public/1227685/
Изменять приходится, например, чтобы добавить присоединенные файлы к своим объектам.
21. Darklight 22 19.06.20 17:07 Сейчас в теме
(10)Плюсую, но:
4) Насколько я знаю "СхемаЗапроса" - та ещё дрянь (пробовал пользоваться пару лет назад - больше не хочу, может что-то, конечно, сейчас изменилось - не знаю - скажите коли стало лучше) - у данного инструмента три фундаментальные проблемы:
1. Очень ограниченный API на изменения - банально даже поиска нормального даже в линейном списке нет, не говоря уже о поиске нужной точки изменения во всём запрос - от того конструкции работы с этим объектом просто монструозны - с кучей вложенных циклов; и даже если создавать свой хелперский API - всё равно всё - банальные операции выливаются в десятки строк кода (и сотни-тысячи строк в хелперском кустарном API). В 98% гораздо проще просто обработать текст банальными текстовым функциями. А надёжность - да почти не пострадает (будет на уровне 50% в обоих случаях) - тут просто проблемы уже глубже лежат - внутри самого синтаксиса запросов.

2. Работать можно только очень строго последовательно - т.е. если надо добавить поле - то нужно сначала добавить источник этого поля (если его нет), а чтобы его добавить - нужно добавить все прочие источники, от которых он зависит, и настроить соединения. А когда доходит до временных таблиц - так вообще просто жесть какая-то при работе выходит. Шаг влево - шаг в право - и всё - сразу ошибка при вызове метода. От того вносить правки в запросы - ОЧЕНЬ сложно и громоздко - приходится думать минимум на три шага вперёд и "бегать" по всему API данного объекта и его производных. От того код модификации получается крайне запутанным и трудно воспринимаемым. Ну, а если исходный запрос вообще ещё требует постобработки (да хотя бы банальной сборки из нескольких частей-подзапросов и временных таблиц, а в конфигурациях такое бывает частенько) - то в схему его либо вообще не загрузить, либо если и загрузить - то по выходу потеряются все "управляющие комментарии" (или "фигурные" расширения языка запросов - да хоть для СКД).

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

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

5) ОпределяемыеТипы штука очень мощная, но криво сделанная (особенно в расширениях). Их применение в конфигурации - большое благо (могло бы быть) - как раз из-за возможности в едином месте настраивать тип общего назначения, и потом везде его применять. И 1С идёт таким путём. И чтобы расширить это назначение своими типами - гораздо надёжнее внести их именно в определяемый тип, чем лезть в реквизиты, где он используется, проконтролировать (и объединить) опредлеляемый тип при обновлении куда менее рисковано, чем контролировать все места его применения (которые могут прибавляться/убавляться)
12. pm74 176 19.06.20 11:27 Сейчас в теме
боянчик конечно , но с юмором и читается легко поэтому +
Принципиально есть три варианта внесения изменений: закомментировать типовой запрос и написать свой, внести точечные маркированные изменения в типовой, подменить типовой своим
четвертый - через схему запроса
13. ipoloskov 121 19.06.20 12:21 Сейчас в теме
Чтобы у идиота был доступ к реестру задач, нужно вести этот реестр в самой конфигурации (в расширении). Например, в общем модуле __ОписаниеИзмененийКонфигурации
Дмитрий74Чел; davdykin; mvxyz; Rustig; +4 Ответить
14. awk 717 19.06.20 12:21 Сейчас в теме
Отсутствие префикса обычно говорит либо о беспросветной тупости, либо о перетаскивании объекта из другой типовой конфигурации, либо о том, что программисту стыдно за этот объект.


Есть еще вариант. Мы работаем забегая вперед и знаем, что 1С создаст такой же объект (рано или поздно). Что бы это вовремя засечь и не плодить сущности, процитирую вас:

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


Правда - это крайне редкий случай. 99,99% случаев проще (да и нужно) ставить префикс.
16. pm74 176 19.06.20 13:31 Сейчас в теме
есть еще один класс задач по доработке (про который ничего не сказано)
требующий отдельной главы в методичке . Когда нужно добавить функциональности отдельному сегменту чего либо.
пример на скрине
Прикрепленные файлы:
Albert_2008; Rustig; +2 Ответить
25. muskul 20.06.20 04:37 Сейчас в теме
(16)разные виды номенклатуры со своим учетом по характеристикам? не?
29. pm74 176 20.06.20 10:11 Сейчас в теме
(25) уже настроены , в данном случае требуется сделать выбор вида характеристики обязательным в частном случае
32. AntonSm 27 20.06.20 16:10 Сейчас в теме
33. pm74 176 20.06.20 18:54 Сейчас в теме
(32) спасибо , мне помощь не требуется
Я говорю про общий класс задач (очень частых кстати), для решения которых применяется несколько общераспространенных методов, начиная от "НайтиПоКоду" , заканчивая приведенным вами способом. И раз уж речь идет о методичке для " стажеров и программистов" , то недурно бы дополнить для обсуждения.
18. dandykry 5 19.06.20 14:01 Сейчас в теме
Еще раз повторю: если вы хотите внести изменения в типовой запрос, то вы что-то делаете не так.


Либо разработчики КА/УТ/ЕРП что-то делают не так уже несколько лет.
К примеру в предпоследнем релизе ЕРП при печати нескольких Коммерческих предложений, все печаталось как 1 большой документ.

Тема хорошая. К примеру, у нас есть отдельные правила по маркировке исправлений косяков от 1с )
22. oleganatolievich 146 19.06.20 20:47 Сейчас в теме
1. Для кого делаются доработки
Про идиота - зачем эти эмоции лишние? Это уже давно сказано
«Пишите код так, как будто поддерживать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. Вудс.

2. Типы конфигураций.
Это разумеется само собой. Достаточно график обновлений посмотреть.

3. Префиксы добавляемых объектов
Раздражает, когда в коде читаешь кашу из ИТ, ИИ, ББ, и т. д.
Почему это этот префикс обязателен? Это в конвенции по оформлению кода от 1С прописано? А подсистемы для кого придуманы?

4. Маркировка изменений
Разумеется само собой. Зачем делать заметку об измененном коде без первоначального?

5. Изменение типовых запросов
Если правка ошибки в типовом запросе? Лучше обрабатывать текст запроса после его объявления, а не править это объявление.

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

7. Добавление чего-нибудь в регистры накопления
Уж тем более надо провести исследование, поиск ссылок на объект, прежде чем что-то трогать в таблице, которая может оказаться огромной. За названия ресурсов ИмяРесурсаX надо лишать премии.

8. Добавление нового регистра накопления или регистра сведений, подчиненного регистратору

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

Много букв. Основная мысль, которая заграфоманена в статье - "не лезь в типовую. а если лезешь, то сделай анализ изменений, и добавляй чаще, чем изменяй".
xantif_2000; aegoncharov; +2 Ответить
27. aegoncharov 20.06.20 09:46 Сейчас в теме
(22) Поддержу по п.3 про префиксы. Вопрос неоднозначный.
Особенно что касается безапелляционной рекомендации:

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


Если каждый программист начнет делать свои префиксы в зависимости от места своего трудоустройства, то без слез на конфигурацию сложно будет смотреть. То же касается и "местячковых" префиксов предприятий.
Во-первых, у владельца конфигурации, по хорошему, должна быть некоторая концепция префиксации при доработках, которой следует придерживаться всем приходящим разработчикам. Если ее нету - то внешний разработчик может предложить ее.
Во-вторых, я считаю, что префиксация в большинстве случаев должна коррелировать с самим прикладным смыслом доработки.
Если вносится какая-то универсальная подсистема, например, какой-нибудь "Контроль доступа к данным", состоящая их нескольких модулей, регистров, справочников, то этим объектам вполне удобно будет дать префикс, какой-нибудь "КДД_".
Если вносится какая-то отраслевая доработка/подсистема, то можно дать "отраслевой" префикс, например, ХБКП (хлебобулочно-кондитерское производство).
Очевидный плюс в таком подходе - эти доработки проще переносить на другие предприятия (если сравнивать с префиксацией по наименованию предприятия, которое вообще может поменяться).
Если вносятся изменения непосредственно в типовую функциональность, то тут, вероятно, вообще лучше придерживаться стандартов наименований объектов и реквизитов самой типовой конфигурации. Многие алгоритмы по обработке данных используют совпадение наименований реквизитов в зависимости от их содержания. Если есть реквизит "Контрагент", хоть типовой, хоть добавленный, уже из наименования ясно что в нем.

Да, есть проблема, когда в конфигурацию добавляют свой документ/реквизит, а потом 1С делает свой с таким же наименованием, ее надо иметь ввиду.
JohnyDeath; Infector; +2 Ответить
28. oleganatolievich 146 20.06.20 09:50 Сейчас в теме
(27)
Если каждый программист начнет делать свои префиксы в зависимости от места своего трудоустройства, то без слез на конфигурацию сложно будет смотреть.

да, согласен. видел много таких поделок.
жаль, в 1С нету аналога пакетов из Java, которые ограничивают пространство имен.
23. Labotamy 19.06.20 21:28 Сейчас в теме
Объясните плз беспросветному тупому трусу нафига префикс?
sashocq; oleganatolievich; +2 Ответить
30. davdykin 24 20.06.20 13:58 Сейчас в теме
(23) Префиксы на самом деле очень удобны:
1. Можно найти все функции в модуле, какие ты добавлял, редактировал и т.д.
2. Вы видите реквизит в конфе, которого нет в поставке, что это, артефакт от прошлого кривого обновления, дописанный реквизит? По префиксу сразу видно. Да и искать такие реквизиты среди 20-30 стандартных - значительно проще.
3. Ну.. автодополниение тоже удобно, доработки в основном все скидываю в один модуль, т.к. не удобно под 2-3 процедуры делать отдельный модуль, выделяешь префиксом ДоработкаПравил_, ДоработкаОбмена и т.д., очень удобно
Дмитрий74Чел; +1 Ответить
24. genayo 19.06.20 22:48 Сейчас в теме
А так-то, лучше во франче не работать :))
31. davdykin 24 20.06.20 13:59 Сейчас в теме
(24)По-моему для "начала" работы самое то:
1. Поработаете с разными задачами
2. Если франч путевый - посмотрите стандарты работы, это сильно помогает в дальнейшем
3. Очень большой плюс - обмен опытом.
34. genayo 20.06.20 20:38 Сейчас в теме
(31) Вот именно, если франч путёвый. А их, путёвых, не так уж и много.
35. davdykin 24 21.06.20 05:09 Сейчас в теме
(34)Даже не путевый франч, опыта вам даст больше )). Хотя сейчас франчи мне кажется кроме как "проехать по ушам какая крутая штука ИТС", на большее не способны
52. genayo 24.06.20 08:26 Сейчас в теме
(35) Я тут дорабатывал одну подсистему "от франча" - проклял всё, проще было самому с нуля написать. Нахрен такой опыт по велосипедостроению с квадратными колёсами.
56. davdykin 24 28.06.20 10:46 Сейчас в теме
(52) Ну вообще очень странно, вы по одному случаю делаете обобщающие выводы.. вы думаете те кто не во франче - сразу пилять чистый, красивый код?
59. genayo 29.06.20 13:54 Сейчас в теме
(56) Это не один случай, это просто свежий пример. Конечно, не все сразу пишут качественный код, но во многих мелких (и не очень :( ) франчах, чтобы заработать, надо быстро писать код, который хоть как-то работает, чтобы быть принятым заказчиком. А про дальнейшую доработку и поддержку думать как-то не принято...
60. davdykin 24 29.06.20 18:12 Сейчас в теме
(59)Не знаю, я всю жизнь во франче работал и работаю, и как-то стараюсь не писать работающий говнокод, потому что клиенты потом в основном обращаются к нам же за поддержкой, зачем мне создавать себе лишнюю работу... да и как-то стыдно будет, если "следующие" ребята обслуживающие увидят твои грабли
26. z86 55 20.06.20 08:23 Сейчас в теме
А мне больше нравится суфиксы в новых объектах: когда что-то пишешь то по логике можно написать Номенклатура_сд чем чих_номенклатура. Также в комментариях пишем префикс но : "//с.д. рижий 2020-06-19" потому что подобрать префикс из 2-3 бук который не повторяется в тексте очень сложно. Ище есть небольшая рекомендация - когда пишем свои функции и переменные в тексте то начинаем с префикса "сд_" или просто "_", и обязательно коменты
36. JohnyDeath 298 21.06.20 10:38 Сейчас в теме
Префиксы - зло!
Даешь постфиксы!
48. 1c-intelligence 10353 23.06.20 22:35 Сейчас в теме
(36) я вот честно не понимаю, чем постфиксы лучше.
Мыслю в стандартном контексте: вносим не очень много изменений в типовую, т.е. наиболее распространённая ситуация для франча. Допустим, 3 справочника, 1 документ, 5 регистров сведений, ну и по мелочи - роли там, подписки.

Преимущества префикса:
1. Визуально в списке объектов МД их лучше видно, т.к. по левому краю они одинаковы (а список объектов прижат влево);
2. Если кто-то решит отсортировать список МД, то все добавленные объекты останутся рядом друг с другом, не разбегутся по списку (как объекты с постфиксами);
3. В контекстной подсказке достаточно набрать префикс, и тут же под курсором окажется весь наш небольшой набор. С постфиксами так не получится - контекстная подсказка по подстроке не ищет.

В остальном всё одинаково. Поиск в дереве метаданных одинаков для префиксов и постфиксов.

Объясните?
53. JohnyDeath 298 24.06.20 09:12 Сейчас в теме
(48) Те самый плюсы, которые ты описываешь для префиксов, являются для меня минусами )
Если кто-то добавил справочник "ПунктыПогрузкиВыгрузки" или общий модуль "КоннекторХТТП", то я хочу в подсказке видеть их именно по "пункты..." или "кон.." и не вспоминать о том, какой- же у них был префикс. Я работал в конфигурации, над которой трудилось куча франчей. И вот такое правило с префиксами у заказчика было обязательным требованием при приемке работ. Так вот там найти что-то внятное было очень сложно, отсюда росли еще одни грабли, о которых ты здесь также писал: некоторые модули ил даже справочники просто-напросто дублировали друг друга только потому, что разработчик одного франча не нашел похожего объекта/модуля другого франча.

По преимуществам префиксов из списка:
1. Визуально в списке объектов МД их лучше видно, т.к. по левому краю они одинаковы (а список объектов прижат влево);

Зачем их видеть визуально в списке МД? В предприятии, надеюсь, они отображаются без префиксов? И ничего, пользователи знают и любят названия без префиксов. А чем мы хуже?
2. Если кто-то решит отсортировать список МД, то все добавленные объекты останутся рядом друг с другом, не разбегутся по списку (как объекты с постфиксами);

Так это же наоборот плюс постфиксам. Справочник "КонтрагентыПрисоединенныеФайлы_бит" я хотел бы видеть рядом со справочником "Контрагенты", и не пытаться искать его по "бит_Контрагент", "кд_Контрагенты", "вз_Контрагенты"...
3. В контекстной подсказке достаточно набрать префикс, и тут же под курсором окажется весь наш небольшой набор. С постфиксами так не получится - контекстная подсказка по подстроке не ищет.

Это если ты знаешь какой префикс и если он у тебя один на конфигурацию. Но думаю, что нужно-таки начинать набирать код отталкиваясь от смысла "ОбщегоНазначения..", "Контрагенты..", "РаботаСФайлами..", чем вспоминать создателя этого ОМ/Справочника

Очень много отраслевых решений, построенных на типовых конфигурациях, имеют в своих правилах "префиксы". И когда они доходят до клиентов, то уже на местах начинают добавлять свои префиксы. Т.е. уже на старте имеем 2 префикса.
sashocq; artbear; +2 Ответить
54. 1c-intelligence 10353 24.06.20 11:34 Сейчас в теме
(53) похоже, это все-таки дело вкуса. Как квас и кефир.
55. JohnyDeath 298 24.06.20 12:58 Сейчас в теме
(54) Можно еще посмотреть на типовые конфигурации и их Общие модули. Например "ОбщегоНазначения" и его "дети" в бухгалтерии: ОбщегоНазначенияБП, ОбщегоНазначенияБРО, ОбщегоНазначенияБТС, ОбщегоНазначенияЭДКО
Если бы разработчики каждой из этих подсистем (модулей) следовал правилу префиксов, то мы бы заимели "БП_ОбщегоНазначения" и т.п. Использовать такие ОМ крайне неудобно.
Но это лично мое мнение, никому его не навязываю. Просто с лихвой хлебанул этих префиксов у трех разных клиентов, где трудилась армия разных групп франчей. И их сортировка в дереве метаданных по префиксу, а не по смыслу только напрягает. Про контекстную подсказку можно просто забыть
38. skillman 22.06.20 07:33 Сейчас в теме
Как эта тема сейчас стала популярна!
Прям раньше жили без этого теперь опомнились или наелись обновлять типовые релизы ,которые кто-то поменял!?
39. &rew 23 22.06.20 07:47 Сейчас в теме
(38)Да нет. Просто сейчас дорабатывать типовые конфы стало сложнее. Много скрытых зависимостей. Изменились требования к аппаратной части. И если писать "за ПИСОТ рублей", то вместо базы можно в недалеком будущем получить "мертвяка". У меня так товарищ"алкашку" УТ восстанавливал после таких деятелей. Весь учет угробили. Самого бог миловал пока.
41. Mechanik21 21 23.06.20 17:53 Сейчас в теме
Не по теме: подскажите, что за классическое письмо было упомянуто в Корпоративном Ламанчском о верности работников? Я его тогда сразу нашёл и прочитал, а теперь вспомнить не могу, а случай такой, что дословно процитировать хочется)
42. 1c-intelligence 10353 23.06.20 18:10 Сейчас в теме
47. Mechanik21 21 23.06.20 21:33 Сейчас в теме
43. German 874 23.06.20 20:04 Сейчас в теме
Начал за здравие, а закончил...

Начал читать, понравилось/зацепило деление на типы конфигураций, отложил, потом выкроил свободный вечерок на чтение статьи..
А дальше хоть не читай:
Префиксы - редуцент из тех времен когда в конфигураторе не было поиска по части строки, представьте что у вас будет с конфой когда у вас работает 10 или 20 компаний подрядчиков, не удивительно что они потом у вас "ТипыЦен найти не могут"..
Внешние отчеты/обработки/заполнения в типовых - ахахаха

Мой вердикт "правила" для коллектива "мы с Тамарой пилим парой" - до 3-4 разрабов в одной полумертвой конфигурации.
Для современных с коллективом более 30 специалистов, просто запрещены к использованию. Поэтому жирный минус.

Что бы не быть голословным подготовлю к публикации наш правила/регламент которой ковался кровью в больших коллективах и современных конфигурациях
44. 1c-intelligence 10353 23.06.20 20:13 Сейчас в теме
(43) а расскажете, чем могут 30 человек одновременно заниматься в одном проекте по доработке типовой конфигурации? Правда интересно.
45. German 874 23.06.20 20:32 Сейчас в теме
(44) как вы себе представляете этот рассказ? Если вы ставите под сомнение необходимость такого огромного числа ресурсов, то могу лишь сказать, что их по факту было 2 раза больше, а дальше вопрос объема данных и масштабов компании и стоящих задач.
46. 1c-intelligence 10353 23.06.20 20:47 Сейчас в теме
(45) нет, не ставлю под сомнение, правда интересно.
Если это фуллтайм и франч, то это 10 млн. в месяц.
Если это внутренняя команда, и все разрабы, то они именно типовую дорабатывают? Ну и это всё равно 5 тыс. ч/часов в месяц - столько стоит хороший проект внедрения erp, но там не только разработка.
Если это разработка, а не доработка, то там, вроде, другие правила нужны.
49. BabySG 23.06.20 22:45 Сейчас в теме
(46) пилили овердофига. И не один франч, их было иногда 10+. Ну а детали может Герман рассказать (ему пофиг на NDA, а мне нет :) )
Разработчиков, действительно, было меньше. Но важно понимать, что может быть разработчик, который раз в месяц вносит изменение (например, это эксперт и занимается производительностью) - но от этого требования к соблюдению правил не меняются.
PS. Кстати, изначально Герман не был настроен так против внешних обработок )
50. 1c-intelligence 10353 23.06.20 22:56 Сейчас в теме
(49) ну я подожду, чё.

Я встречал людей, которые все печатные формы всех документов УПП рисовали в модуле объекта. Вроде у них было какое-то объяснение даже, но я уже не помню, какое. Интересно ваше послушать.

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

А так, мне правда интересно. Например, почему Герман назвал современной конфигурацию, в которую надо вносить бешеное количество доработок. А полумертвой - ту, в которую не надо. Весь мой опыт говорит об обратном.

В общем, жду интересного рассказа.
51. genayo 24.06.20 08:24 Сейчас в теме
(50) "Уж полночь близится, а Германа всё нет" :)
57. Tavalik 2326 29.06.20 05:57 Сейчас в теме
Вы уж, Иван, извините, но вода водянистая. А на методичку для стажеров и подавно не тянет.

Прикреплю наши правила разработки, может вам пригодятся: https://infostart.ru/public/647048/
58. 1c-intelligence 10353 29.06.20 08:43 Сейчас в теме
(57) у вас хорошо написано, но не всё объяснено - стажеры не сдадут мне экзамен, если не смогут объяснить, почему именно так надо вносить изменения.
Ну и не про все виды изменений написано. Например, ничего нет про регистры.
61. Cyberhawk 120 19.07.20 00:50 Сейчас в теме
в свойствах регистра оставить автоматическое удаление движений при отмене проведения
У регистров нет такого свойства
62. 1c-intelligence 10353 11.08.20 11:43 Сейчас в теме
Оставьте свое сообщение

См. также

Использование программных перечислений, ч.1: строковые константы Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Часто ли у вас возникает необходимость в коде выполнять сравнение на строку?

10.12.2016    36815    unichkin    46    

Программная работа с настройками СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Нюансы программной работы с настройками системы компоновки данных в отчетах и динамических списках. Обзор всех видов настроек компоновки. Что в каких случаях правильно применять. В качестве примера рассмотрена работа с отборами и группировками.

27.01.2020    22189    ids79    26    

[СКД] Программное создание схемы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Сделаем отчет на СКД полностью программно, без использования макета "схема компоновки данных".

15.01.2020    20672    John_d    22    

Последовательности событий. Шпаргалка

Практика программирования v8 Россия Бесплатно (free)

Собрал информацию о событиях/подписках/расширениях в одном месте.

30.12.2019    15434    kuzyara    33    

Вспомогательные инструкции в коде 1С Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

Помогаем редактору кода 1С помогать нам писать и анализировать код.

15.10.2018    29337    tormozit    100    

30 задач. Странных и не очень

Практика программирования v8 Бесплатно (free)

30 задач на знание языка программирования 1С и некоторого поведения платформы. Маленьких. Странных и не очень.

02.12.2019    16283    YPermitin    72    

Как передать IP адрес, который вызвал HTTP запрос в 1C (для веб-сервера Apache)

Практика программирования v8 Бесплатно (free)

Столкнулся с задачей получения IP адреса, который вызывает http сервис 1С. Итак, решение:

22.11.2019    7886    Sibars    19    

Таблица значений. Нюансы

Практика программирования v8 Бесплатно (free)

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

01.10.2019    30319    Yashazz    50    

Оформление и рефакторинг сложных логических выражений Промо

Практика программирования v8 Россия Бесплатно (free)

В сложных логических выражениях нередко самому автору спустя какое-то время тяжело разобраться, не говоря уже о других программистах. Предлагаемая методика позволяет повысить наглядность таких выражений путем оформления в виде И-ИЛИ дерева и одновременно выполнять их рефакторинг.

20.09.2012    77215    tormozit    131    

[Шпаргалка] Программное создание элементов формы

Практика программирования Работа с интерфейсом v8 1cv8.cf Бесплатно (free)

Программное создание практически всех популярных элементов формы.

06.09.2019    43887    rpgshnik    63    

Агрегатные функции СКД, о которых мало кто знает

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Пользуетесь ли Вы всеми возможными агрегатными функциями, которые предоставляет система компоновки данных? Если Вы используете только: СУММА, КОЛИЧЕСТВО, МИНИМУМ, МАКСИМУМ, СРЕДНЕЕ, то эта статья для Вас.

05.09.2019    45454    ids79    54    

Регистры бухгалтерии. Общая информация

Практика программирования Математика и алгоритмы v8 v8::БУ БУ Бесплатно (free)

Общая информация о внутреннем устройстве регистров бухгалтерии.

05.09.2019    26236    YPermitin    24    

Запись значения в поле ввода/формы со срабатыванием события ПриИзменении Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

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

11.07.2007    47511    tormozit    40    

Три костыля. Сказ про фокусы в коде

Практика программирования v8 Бесплатно (free)

Три интересных (или странных) костыля в коде, которые могут помочь в повседневных и не очень задачах.

03.09.2019    24862    YPermitin    80    

Отслеживание выполнения фонового задания

Практика программирования Универсальные функции Разработка v8 1cv8.cf Бесплатно (free)

Запуск фонового задания из модуля внешней обработки. Отслеживание выполнения задания в виде прогресса, расположенного на форме.

17.08.2019    30110    ids79    16    

Функции СКД: ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Подробное описание и использование внутренних функций системы компоновки данных: Вычислить, ВычислитьВыражение, ВычислитьВыражениеСГруппировкойМассив, ВычислитьВыражениеСГруппировкойТаблицаЗначений.

08.08.2019    72419    ids79    49    

Как сделать из &НаКлиентеНаСервереБезКонтекста почти &НаКлиентеНаСервере Промо

Практика программирования v8 1cv8.cf Россия Бесплатно (free)

Как сделать метод формы, доступный на клиенте и на сервере одновременно, и сохранить при этом удобство разработки

10.09.2017    43847    tormozit    74    

Фоновое выполнение кода в 1С - это просто

Практика программирования v8 1cv8.cf Бесплатно (free)

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

02.08.2019    31665    avalakh    22    

Разбираемся с параметрами редактирования СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Связь по типу, Параметры выбора, Связи параметров выбора

31.07.2019    21652    json    13    

СКД - наборы данных и связи между ними, создание собственной иерархии, вложенные отчеты

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Набор данных объект. Использование в схеме компоновки нескольких наборов данных. Различные варианты связи наборов: объединение, соединение. Использование иерархии в отчетах на СКД. Создание собственной иерархии, иерархия детальных записей. Использование вложенных схем в отчетах на СКД.

26.07.2019    53509    ids79    11    

Выгрузка документа по условию Промо

Практика программирования Разработка v8 Бесплатно (free)

Что делать, если документы нужно выгружать не все подряд, а по какому-то фильтру: статусу, дате, набору условий... А что если он соответствовал этим условиям, а потом перестал? А если потом опять начал? Такие ситуации заставили попотеть не одного программиста.

25.04.2019    15858    m-rv    2    

СКД - использование расширений языка запросов, секция ХАРАКТЕРИСТИКИ

Инструментарий разработчика Практика программирования v8 v8::СКД Бесплатно (free)

Автоматическое и не автоматическое заполнение полей компоновки данных. Использование расширений языка запросов для СКД «{…}», секция ВЫБРАТЬ, секция ГДЕ, параметры виртуальных таблиц. Автоматизированное использование дополнительных данных в запросе: секция ХАРАКТЕРИСТИКИ.

17.07.2019    33873    ids79    27    

Регистры сведений. За кулисами

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Небольшие заметки по внутреннему устройству регистров сведений.

09.07.2019    25153    YPermitin    14    

"Меньше копипаста!", или как Вася универсальную процедуру писал

Практика программирования Разработка v8 v8::СКД 1cv8.cf Бесплатно (free)

Программист Вася разбирает подход создания универсальных методов на примере программного вывода СКД.

04.07.2019    19300    SeiOkami    50    

Как прикрутить ГУИД к регистру сведений Промо

Практика программирования Перенос данных из 1C8 в 1C8 Разработка v8 Бесплатно (free)

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

16.04.2019    19875    m-rv    17    

Работа с настройками системы компоновки данных

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

Варианты отчетов, работа с настройками вариантов: структура группировок, поля отчета, отборы, сортировка, условное оформление, другие настройки, настройки отображения диаграмм.

02.07.2019    41860    ids79    17    

Создание отчетов с помощью СКД - основные понятия и элементы

Практика программирования Математика и алгоритмы v8 v8::СКД Бесплатно (free)

Основные принципы работы СКД. Понятия схемы компоновки и макета компоновки. Описание основных элементов схемы компоновки: наборы данных, поля, вычисляемые поля, ресурсы, параметры.

25.06.2019    48999    ids79    25    

Многопоточное ускорение однопользовательских нагрузок в 1С + Microsoft SQL Server 2017

Практика программирования Производительность и оптимизация (HighLoad) v8 v8::Запросы Бесплатно (free)

Взаимодействие с Microsoft SQL Server нередко вызывает трудности у 1С-ников, а потому интересны любые моменты, связанные с его использованием. О своем опыте работы с новым SQL Server 2017 участникам конференции Infostart-2018 рассказал директор ООО «Аналитика софт» Дмитрий Дудин.

11.06.2019    23964    dmurk    144    

Как сделать запрос на изменение данных Промо

Практика программирования v8 v8::Запросы 1cv8.cf Бесплатно (free)

В статье приведены особенности внутренней архитектуры и примеры работы с расширением языка запросов 1С.

01.06.2018    29998    m-rv    21    

Регистры накопления. Виртуальные таблицы. Часть №2: "Остатки" и "Остатки и обороты"

Практика программирования v8 1cv8.cf Бесплатно (free)

Описание работы платформы 1С:Предприятие 8.2 с виртуальными таблицами регистров накопления "Остатки" и "Остатки и обороты". Анализ SQL-запрос при работе с виртуальными таблицами

22.05.2019    22117    YPermitin    7    

Регистры накопления. Структура хранения в базе данных

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

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

16.05.2019    40461    YPermitin    30    

Выполнение внешней обработки в фоновом задании

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Подробное описание подхода к созданию длительной операции на основе внешней обработки. Реализация протестирована на 1С 8.3.12.1714 (x64).

11.05.2019    28439    Eret1k    23    

Метод формирования движений в типовых регистрах нетиповыми регистраторами Промо

Практика программирования v8 1cv8.cf Бесплатно (free)

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

05.12.2017    27998    itriot11    34    

О расширениях замолвите слово...

Практика программирования Разработка v8 Бесплатно (free)

О чём стоит задуматься при принятии решения о создании расширения конфигурации…

07.04.2019    34280    ellavs    126    

Git-репозитории для 1С-кода (опыт использования при небольших проектах)

Практика программирования v8 Бесплатно (free)

Инструкции по взаимодействию с Git-репозиторием, которые писались для тех наших программистов, которые вообще никогда не работали с Git (руководства в духе "Как получить код из git-репозитория?", "Как отправить код в git-репозиторий")...

28.03.2019    26566    ellavs    88    

Трюки с внешними источниками данных

Практика программирования Разработка v8 1cv8.cf Бесплатно (free)

Некоторые трюки для преодоления ограничений внешних источников данных.

14.03.2019    30417    YPermitin    53    

Использование классов .Net в 1С для новичков Промо

Практика программирования Разработка внешних компонент Универсальные функции v7.7 v8 Бесплатно (free)

Руководство для новичков. Написав статью http://infostart.ru/public/238584/, я понял, что многие не понимают того, что написано. Поэтому в этой статье постараюсь более подробно остановиться на азах и без кода на вражеском языке (C#)

27.01.2016    75512    Serginio    108    

Ошибки при работе с хранилищем конфигурации и способы их решения

Практика программирования v8 Бесплатно (free)

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

01.03.2019    36133    Смешной 1С    27    

Разработка и сценарное тестирование с Vanessa-ADD. Отчетность Allure. Автоматизация запуска сценариев

Практика программирования Vanessa Automation v8 Россия Бесплатно (free)

Формируем отчетность о результатах выполнения сценариев. Автоматизируем запуск.

26.02.2019    20993    Vladimir Litvinenko    27    

Автоматические и управляемые блокировки применительно к типовым конфигурациям 1С Промо

Математика и алгоритмы Практика программирования v8 v8::blocking 1cv8.cf Бесплатно (free)

Основные принципы работы с режимами автоматических и управляемых блокировок в 1С Предприятие 8. Теория и применение в типовых конфигурациях: БП, УТ, ЕРП

10.11.2018    33730    ids79    40    

Возможности типовых шаблонов ограничения доступа на уровне записей (RLS)

Практика программирования БСП (Библиотека стандартных подсистем) Роли и права v8 v8::Права Бесплатно (free)

Краткий обзор применения типовых шаблонов ограничения доступа на уровне записей в конфигурациях, созданных на базе БСП: #ПоЗначениям, #ПоНаборамЗначений, #ПоЗначениямРасширенный, #ПоЗначениямИНаборамРасширенный

03.02.2019    36984    ids79    9    

Тестер: частые вопросы Промо

Практика программирования v8 Бесплатно (free)

Ошибкам бой - тесты норма жизни!

25.07.2018    28887    grumagargler    28    

EnterpriseData – часть 2. Процесс выгрузки данных

Практика программирования Обмен через XML v8 v8::УФ Россия Бесплатно (free)

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

26.12.2018    25789    ids79    31    

Новый подход к обмену данными EnterpriseData

Практика программирования Обмен через XML v8 v8::УФ Россия Бесплатно (free)

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

14.12.2018    39600    ids79    72    

EnterpriseData - пример доработки правил конвертации без использования КД 3.0 в расширении конфигурации

Практика программирования Обмен через XML v8 v8::УФ БП3.0 УТ11 Россия Бесплатно (free)

В статье подробно описан реальный пример доработки обмена данными через EnterpriseData (универсальный формат обмена) между конфигурациями УТ 11.4 и Бухгалтерия 3.0

16.11.2018    35896    ids79    40    

Ускоряем 1С: модули с повторным использованием возвращаемых значений Промо

Практика программирования v8 Бесплатно (free)

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

04.09.2017    51816    m-rv    61    

Программное заполнение пользовательских параметров и отборов СКД

Практика программирования v8 v8::СКД 1cv8.cf Бесплатно (free)

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

13.11.2018    44140    Unk92    21