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