1С *

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

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

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

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

Обычно, в 1С много показателей и отчётов по ним, а при желании почти каждый можно собрать под свои потребности, так как платформа гибкая и легко поддается доработке. Но это долго и разработка стоит дорого, особенно если речь про кастомный отчёт под руководителя. А с обработкой можно получать короткий отчет сразу в Telegram.

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

Привет, Хабр! Меня зовут Александр Любин, я архитектор 1С в CDEK. В этой статье расскажу про наш опыт интеграции 1С в ERP‑систему и личный кабинет. Расскажу, с какими проблемами мы сталкивались, как их решали, какие инструменты использовали. 

Мой опыт в разработке — 15 лет. Последние три с половиной года — в CDEK.За это время мы с командой смогли в корне изменить позиционирование 1C в компании от «что‑то там для бухгалтерии» до фундамента финансового, регламентированного и оперативного учёта. Смогли доказать, что 1C может быть средой быстрой разработки и инструментом, который позволяет обеспечить потребности как фронт, так и бэк контуров. Я расскажу, как у нас всё проходило.

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

Для начала разберемся с тем, что именно подразумевается под словом “саботаж”.

* Этимология слова саботаж. Французское происхождение: sabotage от слова sabot — «деревянный башмак, сабо».В XIX веке рабочие во Франции носили такие деревянные башмаки — сабо. По одной версии, когда они протестовали против машин и механизации, они бросали свои сабо в механизмы ткацких станков, чтобы заблокировать их работу. Отсюда — «ломать машины сабо» → «саботировать работу».

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

В статье будет рассмотрена большая часть современных агентских IDE которые хоть кто то из знакомых и подписчиков использовал, а именно: Cursor, Kiro, Claude Code (Расширение), Roo Code, Kilo Code, Antigraviry, Cline, WindSurf, Continue, TRAE, Qode, Warp ADE, Zed

Для тех кто не любит читать итоговая табличка конечно же в начале:

Локальный Rebase в 1С:EDT - это мощная и достаточно продвинутая операция по актуализации вашей локальной ветки (синхронизация с последними изменениями) перед тем, как выполнять слияние с главной веткой.

Давайте разберём подробно, что это такое, зачем нужно и как работает.

Для начала примем договорённость: в удалённом репозитории Git существует главная ветка с именем dev. Обычно главной ветке дают такие имена, как main, develop или просто dev. В нашем примере имя главной ветки - dev.

Зачем это нужно в 1С:EDT?

Прежде всего - для вашей локальной ветки. Например, вы создали от главной ветки dev свою локальную ветку и переименовали её в feature/my-branch.

Сеть кофеен — это текучка, гибкие графики, подмены, совместители и десятки локаций. А если считать зарплату вручную, это еще и боль. Особенно когда всё построено на Excel: где-то не проставили смену, забыли штраф, не учли роль. На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Рассказываю, как мы автоматизировали расчёт зарплаты в сети кофеен, в которой более 150 сотрудников и нестандартизованной системой мотивации.

Расскажу о своем опыте использования кассового фронта на 1С, отдельно для РИБ (когда каждый фронт является отдельной базой, обменивающейся данными с центральной базой) и отдельно для облака (когда все фронты работают в центральной базе).

Конец месяца. На столе три вещи: оборотно‑сальдовая ведомость по счёту 62 (авансы полученные), оборотно‑сальдовая ведомость по счёту 76 (расчёты с покупателями и заказчиками) и уже остывший кофе. Нужно свести дебет с кредитом, найти ошибки и понять, почему в одной ведомости одна сумма, а в другой — другая.​

Классический алгоритм такой: открыть Excel, выгрузить две таблицы, начать искать совпадения по контрагентам, проверять суммы, делать VLOOKUP, потом ещё один VLOOKUP, потом выясняется, что данные не совпадают по датам, и всё приходится переделывать. Несколько часов или даже дней работы — норма для компании с сотнями контрагентов.​

Решение — автоматизировать эту сверку в Power Query. Я написал скрипт в Power Query для сверки счетов 62 и 76 без ручного поиска ошибок.​

Единственное что я знал про 1С до начала работы с ним — это очень сложный механизм, внешне напоминающий свой собственный браузер со своим собственным фреймворком, что код 1С модулей пишется на своём языке стандарта ecmascript, на кириллице — по‑русски, который после сурового frontend выглядит забавно.
И вот что ещё я теперь знаю.

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

Работаю в ИТ с 2004 года. Пришёл осознанно в индустрию не за деньгами - по любви к технологиям и тишине, когда можно заставить машину делать нужные вещи. Начинал с настольных приложений на Delphi, бэкенд на Python, немного React. Сейчас Финтех.

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

Начну с далёкой предыстории. В одном из чатиков нашего Холдинга аналитик задал вопрос: «Как по отчёту 1С получить список таблиц, из которых отчёт берёт данные?»  Началось бурное обсуждение, много предложений. Пара человек предложила взять запрос из СКД отчёта и скормить его ИИшечке с умным промптом. Так как явно по тексту запроса все таблицы не выловишь (да и таблицы могут быть не только в СКД), я отнёсся скептически к возможности получить хороший результат. Но автор предложения быстренько сделал пример, и аналитик ушёл из чатика довольным. Я взял результат на заметку, особо его не разглядывая.

Потом в чатике начали гадать, а зачем всё это нужно. Оказалось — для назначения прав на таблицы. Уже позже обращается как-то пользователь: беда, расшифровка регламентированного отчёта не работает в ЗУПе.

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

Для компаний с разветвленной филиальной сетью оцифровка внутреннего документооборота уже давно стала необходимостью. ЭДО создает единое информационное пространство, позволяя моментально находить, подписывать и отслеживать приказы и заявки, а также значительно сокращает операционные затраты. Сегодня поделимся опытом федерального ритейлера, где потребовалось автоматизировать массовую выдачу УНЭП. Решение будет также полезно для крупных производственных и строительных предприятий.

Что такое 1С?
Почему 90% предприятий малого и 50% крупного и среднего бизнеса используют 1С?

Почему до сих пор НЕТ АЛЬТЕРНАТИВ и не будет?
Давайте разбираться.

Переходим к заключительной третьей части регламентного обслуживания баз данных. И сегодня акцент сделаем на обслуживании статистик в СУБД PostgreSQL. Актуальные статистики в PG важны ничуть не менее, чем в MS SQL, но разница в настройках и алгоритмах есть, соответственно, подходы будут чуть различаться.

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

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

В статье показываю, как доработать конфигурацию 1С:Бухгалтерия предприятия (КОРП 3.0) так, чтобы использовать произвольную динамичную базу распределения без изменения учетной политики и без расширения прав сотрудников. Разбираем добавление нового значения перечисления, корректировку представлений, создание пользовательского документа для ежемесячного ввода базы, интеграцию с подсистемой распределения расходов и реализацию запроса для автоматического получения данных.

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

В этой части добавил Claude Opus 4.5 и GPT 5.1-Codex-Max

Предыдущая часть

Для тех, кто не любит читать, результат сразу тут:

Волею судеб мне по работе пришлось посмотреть несколько занятий по подготовка к сертификации 1С:Специалист. И от одного лектора вдруг услышал, что использование в условиях виртуальной таблицы массивов, когда можно применить таблицу, — это плохо и медленно. А на сомнения слушателя он ответил: «Я гарантирую это». Думаю, ошибается человек, чего не бывает. И тут в другом занятии другой лектор говорит то же самое. Тут уже волей-неволей задумаешься: а вдруг я чего не помню уже? Но ведь не раз ускорял запросы, меняя таблицы на массивы. И захотелось проверить. Чем не повод для первой статьи на Хабре?

Привет, Хабр! В этой статье поговорим о том, как принципы GitOps можно применить к разработке конфигураций 1С:Предприятия.