Один хороший человек, зовут Руслан, в своём тг-канале (https://t.me/prozac1c) написал небольшой текст про мой "Универсальный механизм планирования" (УМП). Руслану можно верить - он несколько раз внедрял УМП. На практике знает, насколько сложно решать реальные задачи планирования в 1С.

Думаю, опубликовать его текст будет уместным. Тем более, что УМП я распространяю бесплатно (прям здесь https://t.me/another1C/130). Кстати, Руслан когда-то тоже скачал УМП бесплатно, внедрил, и только через несколько лет я об этом узнал :)

Итак, текст Руслана.

«Как же долго я тебя искал…»

Знакомьтесь — УМП (https://infostart.ru/marketplace/690271/) , универсальный механизм планирования. Когда я впервые про него узнал, радости было ещё больше, чем от автозадач.

Почему? Потому что он умеет делать главное, что должно уметь любое планирование — распределять ограниченные ресурсы (деньги, товары, время работы оборудования и т.д.) на потребности (планы оплат, заказы клиентов, планы производства…). И, что важнее всего, делать это гибко, по любым условиям.

Разработал, кстати, всё тот же Иван Белокаменцев (подписывайтесь, если еще не). Не буду подробно рассказывать про техническую часть, это все можно прочитать в описании. Расскажу про свой опыт.

Пример из практики
Производственное предприятие, которое работает в основном под заказ.
Главный вопрос от менеджеров:
«Сможем ли сделать и отгрузить к нужной дате?»

В 90% случаев ответ упирается в одно — наличие сырья. А тут всё сложно:

• ассортимент продукции большой

• сырьё может лежать на складе

• а может быть «в пути» от поставщика

Посчитать это в типовой ERP — задачка не из простых. И тут на сцену выходит УМП.

Что мы сделали

1. Разузловали спецификации готовой продукции до конечных материалов и храним их в специальном регистре — это ускоряет расчёт.

2. В УМП распределили материалы на складе и «материалы в пути» (с учётом даты поступления и времени, необходимом на изготовление продукции) на заказы покупателей.

3. Каждый заказ получил статус:

• обеспечен

• обеспечен частично

• не обеспечен

4. В отчёте видно какого именно сырья не хватает и под какие изделия.

5. В журнале заказов добавили светофор, чтобы статус был виден сразу.

6. В АРМ «Формирование заказов по потребностям» диспетчер видит этот же статус и понимает — включать заказ в производство или нет.

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

В следующей части расскажу про автоматизацию планирования в производстве.

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

Одна из особенностей зумеров — клиповое мышление. Это данность, в которой они не виноваты — среда приучила их к контенту, нарезанному на очень маленькие кусочки.
И кусочки эти становятся всё меньше — это видно по развитию тех же соц.сетей. Например, преобладание коротких видео над длинными в большинстве платформ. Я уже не говорю про тексты — лонгриды уже давно не в чести.

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

Надо нарезать помельче весь контент и все шаги, которые надо в обучении делать.
Видео — короткие. Обучающие задачи — тоже. Предметная или техническая область, которую надо изучить при решении задачи — одна, максимум две.
Тогда норм будет.

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

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

Телеграм

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

Их трёх реакций (бей, беги, замри) любимая реакция зумеров — замри.
Вторая по частоте использования — беги.
И крайне, невероятно редко — бей.

Это немного непривычно для руководителя, который раньше с зумерами не работал. Они очень неконфликтные. Настолько неконфликтные, что с ними сложно разговаривать, если тема или тон разговора хоть немного попахивают агрессией, критикой и так далее
Зумер не защищается, не оправдывается, не спорит — он просто замолкает («замри»). И думает лишь о том, чтобы неприятный для него разговор побыстрее закончился («беги»).

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

Так что, если не можете получить от зумера какой‑то прямой понятный ответ о его работе — это нормально. Ну, для него, по крайней мере.

Телеграм

На одном из проектов перехода с УПП на ЕРП возник неожиданный субподрядчик, который добавил приключений и нам, и заказчику.

Заказчик работает с сетями, а где сети — там какой‑нибудь хитровыдуманный электронный документооборот.

В основе — просто модуль/обработка, написанная какой‑нибудь известной компанией, но обязательно — доработанная на месте под требования сети.

И вроде бы — что может случиться, если мы переходим с УПП на ЕРП, и для обеих конфигураций есть версия модуля ЭДО?
Код модуля — открыт, доработки под сеть — известны. Что может пойти не так?

Первое, что пошло не так — разработчики модуля сказали, что ни нам, ни заказчику нельзя его дорабатывать. А кто там его доработал несколько лет назад для УПП — уже никто и не помнит. Ну, ладно, хозяин‑барин — нельзя так нельзя. Спрашиваем — так, а можете нашему заказчику‑то доработать? Хотя, чего нашему — он и ваш заказчик.

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

В декабре ребята честно что‑то дорабатывали, под конец года отдали результат, и все торжественно ушли Новый Год встречать. В январе, на каникулах, мы запускаем ЕРП, ну и... Доработанные ребятами модули, конечно, не работают. Ну ладно, думаем, ничего страшного = серьёзные штуки никогда с первого раза не работают. Сейчас напишем ребятам, они помогут.

Пишем ребятам, и оказывается... Тех.поддержка не работает (в первые дни каникул).
А заказчику уже отгружать надо — сети, они такие. Там нельзя не отгрузить.
Что делать? Или самим‑таки доработать (но разработчики ЭДО грозили штрафами), или из УПП отгрузки делать. Выбрали второе — сели несчастные люди и вбили реализации в УПП, просто чтобы выгрузить в ЭДО.

Через пару дней начала работать тех.поддержка, но вот незадача... Они ничем не могли помочь с нашим доработанным модулем. Потому что помочь может только разработчик, который с их стороны модули допиливал. А он — на законных каникулах до 12 января. И связаться с ним нельзя никак и ни за какие деньги. А документации он никакой не передал, тех.поддержке ничего не объяснил, поэтому помочь они ничем не могут.

Тут у заказчика вторая волна отгрузок в сеть — ну, что поделать... Пришлось опять из УПП выгружать.

По окончании каникул подрядчик, конечно, всё быстренько починил.
Претензий нет, если что. Просто не знал, что так бывает :)
Теперь знаю. Придётся учитывать этот риск в следующих проектах.

Телеграм

Попалась на глаза статья статья (В чем плюсы использования интервальных регистров) на Инфостарте, про интервальные регистры сведений в ЗУПе. Вспомнил, что недавно использовал эту ЗУПовскую идею для совершенно другой задачи — интервального хранения цен. Но цель использования интервальных РС — та же, оптимизация скорости выполнения запросов и удобства их написания.

Проблема была такая. Есть КА1, в ней — дофигищща чеков. В чеке есть цена продажи, но нет себестоимости. Можно получать какую‑то себестоимость, если включить оценку стоимости списания при проведении документа (фифо, средняя), но это замедлит проведение документов (а их очень много).

К тому же, себестоимость не будет актуальной — документы поступления, как положено, вводятся с опозданием. Соответственно, чтобы актуализировать с/с по чекам, надо или документы перепроводить (а их, напомню, слишком много), или расчёт себестоимости ежедневно или ежечасно делать (не вариант).

У клиента уже было своё технико‑методическое решение — считать себестоимостью цену последнего закупа номенклатуры.

Но тут две проблемы. Если определять цену при проведении чека, то получаем обозначенную выше проблему — поступления вводят с опозданием, поэтому с/с при проведении чека не будет актуальной. Если же брать с/с не при проведении чека, а на лету, отчётом, то тормозит и запрос неприятный получается — кто писал запросы получения среза последних на дату документа, знает, о чём речь.

Ну я и сделал интервальный регистр сведений с ценами. Измерения — номенклатура, дата начала, дата окончания, ресурс — цена. Обращаться запросом к такому регистру — одно удовольствие. И работает сильно быстрее, чем срез последних.

Обновление интервального регистра делается рег.заданием — это быстро, где‑то одна минута на всю номенклатуру. Но всю номенклатуру обновлять надо редко. Я сделал регистр с очередью обновления, туда попадают номенклатуры из поступлений, которые записываются. Провели поступление с сотней номенклатур — сотня записей в очереди появилась. Рег.задание зашло и актуализировано интервальный регистр с ценами по сотне позиций.

Хорошая штука эти интервальные регистры. Рекомендую.

Обновлю статистику по недорогим переходам. Это формат проектов такой, специальный - перейти с одной конфигурации 1С на другую, получить некоторый прирост функциональности, но главное - не потерять того уровня автоматизации, что был в прошлой системе.

В основном такие переходы - вынужденные, вроде отказа от УПП.
Заказчику всё нравится в его УПП, но так уж вышло, что её больше не поддерживают, и придётся переходить.
Поэтому хочется всё сделать с минимальными затратами. Это один из ключевых критериев.

Понятно, что недорогие переходы - не единственный формат проекта, и не всегда лучший.
Но спрос на него есть, вот мы его и придумали.

На данный момент мы сделали 6 таких проектов:

1. Два перехода УПП - ЕРП;

2. Два перехода УПП - КА2;

3. Один переход УНФ - КА2;

4. Один переход УПП - Аренда (там БП внутри).

Ещё два проекта в процессе, их рано включать в статистику.

Средний чек проекта - 1274 часа.

https://t.me/another1C

P.S. Думаю, надо статью написать, предметную - как такие проекты делать, чтобы экономить на переходе.

Перевёл в расширение один из своих старых продуктов - управление задачами. Точнее, это часть некогда большой конфигурации Flowcon. Я выпилил из неё три подсистемы и сложил в расширение.

Перевёл потому, что один потенциальный клиент попросил - хотел посмотреть, что за штука это управление задачами Flowcon.

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

Детальное описание всего Flowcon - https://infostart.ru/marketplace/976048/
В данном расширении - часть "Управление задачами". Ещё включил "Управление компетенциями", но пока не тестировал - сделаю это позже.

А вот на что точно стоит обратить внимание - на часть про регулярный менеджмент. Это штука, которой я сам пользуюсь каждый день. Что это, зачем, и как - описано в отдельной статье - https://infostart.ru/pm/998824/

Расширение можно скачать в тг-канале: t.me/another1C

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

В обновлениях больших и нагруженных баз есть такая проблема - пролезть в "окно" (ещё его называют технологическим окном).
Это время, на которое можно остановить базу 1С для обновления, без существенных потерь для бизнеса.
В нашем случае окно было размером в 40 часов.

Вообще, это не так уж и мало, но... Надо было обновить на 4 редакции - с УТ 11.4.14 до 11.5.22.
Кто помнит обновление на 11.5.8, в котором появились распределение запасов и объекты расчетов, понимают - там время обновления измерялось, скорее сутками.
Обращаю внимание - надо было обновить все 4 редакции в одно окно 40 часов.
Так сильно дешевле, чем накатывать по одному релизу и запускать пользователей. Причём, дешевле в разных всех смыслах - не надо адаптировать конфигурацию под каждый релиз (можно это сделать один раз в конце), не надо мучить людей (заставляя переживать 4 обновления, 4 смены некоторых интерфейсов и механизмов).

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

Короче, надо было сжать 300 часов времени обновления в 40, т.е. в 7-8 раз.

Ну и чё... Получилось 😁

Применили нестандартные методы предварительной подготовки конфигурации и данных, оптимизацию обработчиков, обрезку данных - и оно зашуршало сильно быстрее.
Модных режимов, вроде обновления через копию, не применяли. Никакого вмешательства в СУБД не было. ИИ не использовали :)

Как-нибудь соберусь, напишу статью - там есть, что рассказать.

https://t.me/another1C

Снял видео про один из способов применения расширения "Рабочий стол" - дашборды рисовать. Лично для меня, как пользователя, это главный способ применения рабочих столов. Эдакий дешманский BI, с очень быстрой настройкой и перенастройкой.

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

Правда, дашборды типа "отчёт" (о которых речь в видео) - не самое эффектное представление данных, есть ещё диаграммы. Но про них я отдельное видео сниму.

А пока вот:

https://vkvideo.ru/video-208482299_456239491
https://youtu.be/1rln84eMBwc

Расширение можно скачать тут - https://t.me/another1C/48

Выложил новую версию расширения "Рабочий стол" - подрихтовал интерфейс. Он был старый, т.к. создавался под толстого клиента - см. картинку. Теперь выглядит почти как типовой 1Сный интерфейс.

Также снял видео-знакомство с простейшими функциями рабочего стола (для тех, кто раньше не видел это расширение)
https://youtu.be/-SMc-Q2EOiw
https://vkvideo.ru/video-208482299_456239487

Скачать решение можно в тг-канале https://t.me/another1C

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

Тут две ветки получается - обновление внутри одной редакции и переход между редакциями.
Если говорить про семейство ЕРП - т.е. ЕРП, ЕРПУХ, КА2 и УТ11 - то переход между редакциями там случается раз в год.

Обновления внутри одной редакции, если изменения в расширениях, обходятся в 1.5-2 раза дороже, чем при хранении изменений в конфигурации.
При большом количестве изменений в расширениях бывает и в 5 раз дороже.

Сам технический процесс обновления с расширениями проходит быстрее, т.к. в этом процессе сравниваются конфигурации (основная, старая и новая от поставщика), а не расширения.
Возня с расширениями начинается, собственно, после привычного процесса обновления. Как в шутку коверкали в нулевые название технологии Plug and Play ("подключи и играй") от Windows - Plug and Pray ("подключи и молись"). Так же и с расширениями.
Если повезёт - всё будет работать без вмешательства. Если чуть меньше, но всё-таки повезёт - вывалятся красные ошибки в расширениях, и их нужно будет исправить. Если не повезёт, красных ошибок не будет, но в процессе эксплуатации выяснится, что доработки расширения молча творят какую-то дичь.

Ну а обновления с переходом между редакциями обходятся в 5-10 раз дороже, если основная часть доработок выполнена через расширения.
Разумеется, речь о большом количестве доработок. А то вдруг в системе 5 доработок, из которых 3 - в расширениях :)

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

Ну а все типовые процедуры, изменённые в расширении с инструкциями Вместо и ИзменениеИКонтроль, приходится почти вручную адаптировать под новый релиз. Буквально пересобирать заново - брать новый текст типовой процедуры и вручную помещать туда старые изменения.

Собственно, поэтому и дороже.

https://t.me/another1C

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

Обработка подсчитывает:

1. Количество модулей и строк в них;

2. Количество модулей с изменениями;

3. Количество процедур и функций, разбитое по категориям - новые, изменённые с инструкциями ИзменениеИКонтроль, Вместо, Перед/После;

4. Количество строк в процедурах каждой категории;

5. Для ИзменениеИКонтроль подсчитывает количество изменений и количество строк в этих изменениях.

Как пользоваться:

1. Выгружаем расширение в файлы (можно несколько расширений выгрузить и скопировать в одну папку);

2. Запускаем обработку, указываем папку с выгруженным расширением;

3. Жмём "Посчитать".

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

Но понять, сколько изменений содержится в расширении, крайне затруднительно. В платформе 1С инструменты оценки изменённости есть только для конфигураций.

Обработка тут - https://t.me/another1C/148

Пришлось недавно серьёзно повозиться со сложным обновлением, давно такое интересное не попадалось.

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

В семействе ЕРП регулярно случаются длинные обработчики обновления. Например, при переходе с 17 на 22 в регистр сведений "Реестр документов" добавили измерение с уникальным идентификатором, которое обработчик и заполняет - для всех записей. В моём случае записей было 9 млн, и выполнение обработчика занимало больше суток.

Если нужно сделать 1 шаг обновления, то не страшно - в течение этих суток пользователи могут работать. Но, во-первых, бывают обработчики, которые "отключают" отдельные виды документов или целые контуры учёта, вроде взаиморасчётов или резервов. Во-вторых, мне надо в одно технологическое окно обновить на 4 версии, поэтому ждать было нельзя.

Так вот, попробовал я взять этот обработчик обновления, вынести код в обработку/расширение, самостоятельно распараллелить и запустить. Код там простой, изолированный, никаких зависимостей ни до ни после его выполнения я не нашёл.

И случилось чудо - обработчик выполнился часа за 4-5 (вместо 24+). Попробовал с другими обработчиками, которые столь же изолированные - результат по ускорению тот же.

Я думал, проблема в типовом распараллеливании, которое как-то не очень эффективно распределяет задания между потоками. Пошёл смотреть чужой опыт на партнёрке, нашёл относительно свежую тему (https://partners.v8.1c.ru/forum/t/2259464/m/2259464), где автор нашёл больше меня - дело и в распараллеливании, и в записи статистики. Правда, гарантированного и надёжного решения там найти не получилось - ребята из 1С сказали, что могут быть последствия, если просто отключить статистику. Но обещали что-нибудь придумать со скоростью обновлений.

А пока можете пользоваться тем же способом, что и я, коли возникнет схожая проблема.

https://t.me/ywhite

Полгода назад писал, что выложил конфигурацию УМП (универсального механизма планирования). И обещал со временем выложить расширение, чтобы можно было использовать УМП в современных конфигурациях.

В современных, вроде ЕРП, УМП вполне себе работает. У одного клиента с 2021 г. всё обеспечение продаж и многопередельного производства на УМП держится.

Скачать расширение можно в тг-канале - https://t.me/another1C/130

Описание решения - vk.com/@ivan.belokamentsev-universalnyi-mehanizm-planirovaniya-ump

Снял пару видео по своим разработкам "Автозадачи" и "Структура затрат". Они без видео не очень понятны, обычно. Особенно Автозадачи - чтобы получать от них пользу, надо понять логику и принципы применения.

А пользы от автозадач можно получить очень много, особенно если народу в 1С работает много, процессы сложные и запутанные, и свободы выбора у людей - чересчур.

Итак, видео по автозадачам:

https://vk.com/video-208482299_456239480, оно же https://youtu.be/4Z6Z3tZTVKM

Видео по структуре затрат:

https://vk.com/video-208482299_456239481, оно же https://youtu.be/4Z6Z3tZTVKM

Сами решения (эти и остальные) можно скачать в тг-канале: https://t.me/another1C

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

Само решение можно скачать в моём тг-канале https://t.me/another1C

В интернете есть другие версии этого решения - я никому не запрещал скачивать, как-то адаптировать и выкладывать. Но оригинал только у меня.

Итак, видео.

Первое - совсем простые примеры: https://vk.com/video-208482299_456239478

Второе - чутка посложнее, но всё равно просто: https://vk.com/video-208482299_456239479

В обоих видео показаны примеры использования без навыков программирования.

Выложил своё старое решение по планированию в 1С, можете брать и пользоваться. Проблематику планирования излагал тут, но, думаю, она и без меня понятна всем, кто сталкивался с реальными задачами планирования на практике.

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

Детальное описание решения есть тут - https://infostart.ru/marketplace/690271/
Там же можете стоимость заценить :)

Если кратко, то УМП - лучшее решение для проблемы дефицитов, обеспечения потребностей и их контроля почти в режиме реального времени. Подтверждено и моими внедрениями, и чужими.

Внимание! Внедрить эту штуку можно только с участием программиста! Там надо запросы писать и отчёты делать.
Это несложно, просто предупреждаю, чтобы у вас ожиданий неоправданных не было.

Берите и пользуйтесь. Файл лежит в тг-канале - https://t.me/another1C/92

Как быстро обновить доработанную 1С УПП на много релизов

Один коллега тут обратился с вопросом – как обновить сильно доработанную 1С УПП на 100 релизов? Я говорю – а чего такого? Есть же стандартные технологии для решения таких задач. Оказалось, он их не знает.

Если и вы не знаете, я кратко расскажу.

Раньше все программисты так делали, потому что по-другому было просто нереально. Все вокруг внедряли УПП, в ходе проекта мало кто решался обновляться, релизы копились, и потом надо было шваркнуть сразу с десяток, а то и два. Вы, возможно, удивитесь, но бюджеты таких обновлений доходили до 500 часов (сейчас это 1.5-2.5 млн. руб.).

Итак, принципиально подхода два – «Потом доделаем» и «Прыжок».

«Потом доделаем» основан на одном простом факте: выполняя промежуточные обновления, нет смысла тащить изменения в модулях, формах и ролях.

На первом шаге запускаем обновление, ставим флаг «Показывать только дважды изменённые», и смело заменяем все модули (общие, менеджера, объекта), формы и роли типовыми. Добавленные объекты метаданных в этом режиме мы даже не увидим, с ними всё будет хорошо. Изменения в структуре данных (добавленные реквизиты типовых объектов, изменения типов) – аккуратно тащим дальше.

Любой, кто обновлял доработанные конфигурации, знает: 80-99 % времени работы программиста уходит на сравнение модулей и форм, до рези в глазах. В подходе «Потом доделаем» мы от этого избавлены.

Дальше накатываем остальные релизы, до последнего. Они идут быстро и красиво, потому что все модули, формы и роли мы заменили типовыми.

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

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

Главное – покумекать придётся один раз, а не 100.

Подход «Прыжок» - несколько рискованный. Нужно хорошо понимать, что делаете.

Принцип здесь такой: мы делаем обновление на один шаг, сразу на последний релиз. Главное, что для этого надо сделать – вручную собрать все обработчики обновления и сделать заплатки там, где УПП скажет «ой, я с этого релиза на вон тот обновляться не умею». Ну и там, где она хранит версии подсистем. И, наверное, там, где в УПП проникла такая прелесть, как БСП.

Этот подход – для интеллектуалов и гиков. Пользоваться в реальности не рекомендую, лучше «Потом доделаем».

Про особенности обновления 1С ERP снял видео, текста нет:

https://youtu.be/7F02eshCKh4
https://vk.com/video-208482299_456239471

https://t.me/another1C

Я, кстати, в канале выкладываю свои старые разработки на 1С, можно забирать бесплатно. Идёте в закреплённое сообщение, там будет список, краткое описание, ссылки на полное описание и файлы для скачивания приложены.

Сейчас там доступны расширение "Проверка данных" (полное описание), расширение "Рабочий стол" (полное описание) и отчёт "Структура затрат" (всегда был здесь).

Сколько будет стоить проект перехода с УПП на ERP, если работать без ТЗ, аналитиков, дорожной карты, проектных технологий, графиков и прочих привычных атрибутов? Мне тоже было интересно, поэтому года полтора назад взялись делать такие проекты.

Мысль о том, что переходы можно делать быстрее и дешевле, пришла из прошлого опыта.

Во-первых, внедрения УПП в нулевых обходились сильно дешевле. Хотя все видели 1С впервые (внедренцы, зачастую, тоже :)), ТЗ не писали, аналитиков не было. Да, через задницу многое получалось, но бюджет в 1-2 тысячи часов был вполне средним чеком.

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

Так вот, 20-летний опыт проектов/внедрений/сопровождений говорил, что проекты можно делать за приемлемые деньги. Не было только подтверждения именно для ERP - в нулевых её не существовало, а в должности ИТ-директора только купить коробку успел.

Полтора года назад начали первые проекты делать по этой технологии. Первый завершился в апреле 24 года, обошёлся заказчику в 1930 часов. Можно, получается. Система в эксплуатации уже 11 месяцев.

Сейчас делаем ещё несколько таких проектов.

https://t.me/another1C