1С *

Большая часть литературных источников, посвящённых проектированию информационных систем и использованию информационных технологий, содержит детальное описание графических нотаций по моделированию бизнес-процессов [1-3]. Читая подобные научные работы, возникает вполне закономерный вопрос: выходит, что любой проект внедрения информационной или корпоративной системы требует проектирования бизнес-операций? Так ли это на самом деле? Применим ли этот подход к проектам имплементации ERP-систем? Разберемся в этом вопросе на страницах текущей статьи. Это позволит сэкономить драгоценное время дюжины технических специалистов на проекте.

Вспомним основные моменты проектирования процессов. Под бизнес-архитектурой подразумевается совокупность двух взаимосвязанных составляющих: организационной структуры и бизнес-процессов. Оргструктура бывает линейной, функциональной, дивизионной и матричной, каких-то сложностей с ее моделированием обычно не бывает. Бизнес-процессы описывают в моделях «Как есть» и «Как будет», где последняя характеризует работу компании после внедрения ИТ-решения. Моделирование подразумевает собой последовательную декомпозицию процесса с дальнейшим проектированием операций в той или иной графической нотации. Выделяют нотации верхнего и нижнего уровней, к которым можно отнести ARIS VACD, BCM, IDEF0 и UML AD, BPMN 2.0, ARIS eEPC [1-3].

Все множество методов проектирования процессов можно соотнести с содержимым табл. 1, из которой легко заметить, что последующие графические нотации функционально усиливают предыдущие [4]. В литературе часто пишут, что проектирование элементарных операций ведется на 7-8 уровнях декомпозиции [5], в реальности же 3-5 уровней более чем достаточно.

Перфолента.NET — это на удивление профессионально выглядящий язык программирования на платформе .NET, который поддерживает объектно-ориентированное и функциональное программирование, и на котором написан даже написан другой язык, функциональный язык программирования — Перфо.NET (интерпретатор).

Мой личный опыт

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

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

Раньше сложные понятия функционального программирования давались мне тяжело, но теперь всё стало проще. Лямбда-функции, замыкания, каррирование и т.д. — всё это я теперь понимаю по-другому. Особенно когда объясняю ребёнку.

Например, лямбда-функция — это просто формула из задачника по математике. Ребёнок понял это сразу! И мы пошли дальше, не останавливаясь.

По-моему, главный эффект даёт отказ от псевдонимов и алиасов. Я долго отучался давать названия, из которых сразу понятно, что это за сущность, а не «имена, которые означают...».

Второй эффект — это «сокращение контекста». Контекстное окно человека ограничено 3–5 вещами, которые он в состоянии держать в голове и обдумывать. «Псевдонимы/алиасы» съедают это контекстное окно. Поэтому избавление от прокладок в виде «print — это печать» и замена их на простые «вывести_в_консоль», «вывести_в_файл» и т.п. сильно облегчают понимание логики кода.

Отдел планово-экономический тратил 6 часов каждый месяц на поиск ошибок в ценах МПЗ. Вручную проверяли 500 позиций из 16,000, пропуская критичные аномалии. Я автоматизировал процесс через связку SQL + MCP + Claude AI. Теперь система за 15 минут находит все отклонения, выявляет паттерны мошенничества (дробление закупок, откаты) и даёт план действий с оценкой ROI. Первый запуск выявил потенциал экономии 650K — 1.6M руб/год. Под капотом — техническая реализация с кодом, SQL‑запросами и примерами AI‑анализа.

Мобильное приложение, полностью сделанное на 1С: «Доходность ОФЗ» позволяет рассчитать доходность по облигациям федерального займа (ОФЗ), выпускаемые Минфином РФ по 2 видам доходности: 1) «Простая доходность к погашению» — это годовая доходность в процентах, которую получит владелец облигации, если купит её по рыночной цене и продержит до погашения. 2) «Эффективная доходность к погашению» — это годовая доходность с учетом реинвестирования полученных купонов. Умеет считать доходность на дистанции, С учетом удержания НФДЛ с купонов и БЕЗ.

Конфигурация «Анализ конфигураций (версия 5)» — позволяет проверять любые конфигурации, расширения, отчеты и обработки на наличие ошибок, связанных с вызовом экспортных функций и процедур общих модулей и модулей менеджеров объектов. Проверяются ошибки: 1) Метод объекта не обнаружен 2) Недостаточно фактических параметров. 3) Слишком много фактических параметров. Рекомендуется выполнять при подготовке обновлений. Анализ расширений — позволяет выводить подробный количественный состав расширений по объектам, определить случаи пересечения одного и того же функционала в разных расширения, выявить использование в модулях аннотации «вместо».

IT-специалистам на заводах РФ посвящается. Создаю контраст в противопоставление статьям Сибура про работу в IT на заводах

В статье приведен результат опроса сообщества 1С разработчиков на предмет применения ИИ в своей текущей деятельности.

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

Какие технологии «прижились» среди 1С разработчиков, а какие пока воспринимаются с опаской. Так получилось, что моя деятельность во многом связана с продвижением ИИ в среде 1С. Так вот, главный интерес заключается в том что получилось а что нет. А может некоторые практики и технологии упущены.

Также достаточно интересно с какой стороны и кто занимается внедрением практик работы с ИИ в компаниях. «Снизу» или «сверху».

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

Привет, Хабр!

Сегодня я расскажу, как можно улучшить проекты с помощью Git‑хуков в среде 1C:EDT. Если вы разрабатываете на «1С:Предприятии» и используете Git, но еще не подружились с хуками, самое время это сделать.

В экосистеме 1С исторически существовало собственное хранилище кода, и Git долгое время казался чужаком. Но прогресс не стоит на месте, сейчас 1C:Enterprise Development Tools умеет работать с Git по дефолту, поддерживает групповую разработку и Git‑хуки. Хуки — это скрипты, которые автоматом выполняются при наступлении определенных событий в репозитории: коммит, пуш, слияние и так далее.

2025 год стал для экосистемы 1С и профессионального ИТ-сообщества насыщенным на события и нововведения. В течение года мы публиковали новости о развитии платформы 1С, изменениях законодательства и отчетности, запуске новых сервисов и масштабных профессиональных событиях.

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

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

А я сажаю рядом Оппонента и даю ему возможность пару раз оспорить каждое правило.

Ежегодно 350 тысяч сотрудников Росатома создают примерно 1 200 000 обращений в поддержку. Значительная часть приходилось на систему для ведения бухгалтерского, налогового, регламентированного учета «1С: ERP 2.0 Цифровой Росатом». После внедрения ИИ-продукта «Атом.Зая» это количество сократилось на 24%. В этом тексте хочу рассказать, как мы двигались, чего удалось добиться, и какие уроки извлекли.

С 5 сентября 2025 года проверки Роскомнадзора по персональным данным (ПДн) «переехали» на обновлённую риск‑ориентированную модель: Кабмин поправил ПП № 1046 через постановление № 1286 и расширил критерии, по которым деятельность оператора относят к группам тяжести А/Б/В/Г. В 2026 году это напрямую влияет на то, кого будут «доставать» планово, а кто, скорее всего, увидит РКН только при жалобе или инциденте.

В этой статье:

Технология создания ИИ-помощника для работы с 1С:ERP.

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

И почему та же самая документация 1С, при правильной обработке, способна превратить ИИ в супер-помощника – то есть многократно его усилить.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Чаще всего в интеграциях мы сталкиваемся с настройкой обмена для баз 1С. Предположим, у нас 8 конфигураций 1С, связанных между собой, и нужно навести порядок. В статье расскажу, как мы придумали снизить стоимость разработки, а также значительно сократить время на рутинные задачи.

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

Художественная реконструкция реального эпизода 1773 года: охота за султанскими сокровищами в Средиземном море.

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

Бизнес — это тоже своего рода поход за сокровищами.

И в такой мощной программе управления, как 1С:ERP, «карта похода» — единый наглядный инструмент планирования — нужна руководителю ровно так же, как капитану — карта района плавания.

Но в 1С:ERP такой карты нет. В подсистеме планирования данной программы отсутствует рабочее место руководителя — нет визуального инструмента, который позволял бы одним взглядом охватить весь бизнес-замысел: стратегию, тактику и связи между ними.

Ниже — о том, как я создавал прототип такой карты. Создавал буквально «на коленке». И как из «карты для руководителя» неожиданно вырос ИИ-помощник по планированию в 1С:ERP.

Год назад я не знал о Kubernetes практически ничего. Сегодня у меня свой pet-проект развернут в облачном кубере, и я чувствую себя достаточно уверенно, чтобы делиться опытом. Что изменилось? Я начал преподавать в МАИ и проходить сертификацию по работе.

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

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Близится конец года, с новыми налоговыми изменениями, а значит, нужно обновить наши учетные системы. Обычно этой работой занимается свободный 1С программист, но в этом году все упорно трудятся на проектах. С основной рутинной работой по обновлению успешно справляется обновлятор, но при обновлении доработанных модулей приходится вручную разбираться с конфликтами. Работа не сложная, но требует концентрации и внимания на деталях. В этом году мы активно начали использовать ИИ в режиме чата и в режиме агента. Давайте попробуем и эту работу поручить ИИ. Кому интересен только результат, мотайте сразу до заключения, там ссылка на репо.

Я программист 1С с 18 летним опытом работы с 1С:Предприятие и общим опытом коммерческого программирования 22 года.

С начала января 2025 года я перешел на парадигму работы "AI first" с полным созданием всего необходимого посредством ИИ кодинга.

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

Эта статья - текущее подведение итогов от меня и порядка пятидесяти коллег.

Итак, что на сегодня, 12 декабря 2025 года, нейросети делают полезного для 1Сников (программистов и аналитиков)?

Большинство подобных статей в сообществе 1С почему‑то начинаются с тезисов о том, что «интеграции в 1С — это боль и страдание». Дальше обычно идет длинная статья о том, как «делать интеграции без боли».

Мы с этим подходом категорически не согласны. Интеграции в 1С — это не боль, интеграции в 1С — это нормально. Иногда даже интересно.

И как ни крути, любой разработчик грейдом выше джуна так или иначе с ними сталкивается. А уж разработчика, который дорос до ТА, чем‑то удивить в части интеграций в принципе сложно — все всё уже видели.

В каждой команде обычно есть свои наработки, подходы и проверенные временем куски кода. Мы тоже были такой командой. У нас были свои модули, подсистемы, которые через «сравнение‑объединение» перекочевывали из проекта в проект, и на каждом проекте «допиливались» под конкретные требования.