1С *

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

Предыдущая часть: https://habr.com/ru/articles/967828/

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

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

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

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

Сегодня поговорим о феномене: странной, почти мазохистской привязанности 1С-разработчиков к своему инструменту. Это как брак, в котором ты ежедневно угрожаешь разводом, но остаёшься — потому что «а куда деваться?».

Проброс USB по сети часто нужен в виртуальных средах. В 1С нужно пробрасывать USB ключи лицензирования, для VDI токены налоговой и все это тоже нужно импортозамещать в Linux. Вот только то, что просто делается в Windows - в Linux превращается в спецоперацию с далеко идущими последствиями.

Ситуация: клиент обратился за помощью в интерпретации данных «Монитора». Были жалобы на подвисания в работе 1С и долгие запросы. При одном взгляде на долгие запросы сразу выяснилось, что сервер СУБД очень сильно нагружен. Как именно удалось это понять, рассмотрим в коротком материале. Это статья нашего партнера Андрея Бурмистрова, эксперта в сфере оптимизации производительности 1С. 

Привет! Эта статья про ценность исследований клиентского / пользовательского опыта в таких «сложных» продуктах, как API, модули для 1С и других интеграционных решениях. 

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

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

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

В мире 1С нет более известной фамилии, чем Гилев. Его тест — это своего рода «народный» стандарт, первое, что запускают администраторы для проверки производительности. Это простой и быстрый способ получить заветную цифру, которая говорит о скорости системы.

Мы и сами решили использовать этот тест, запуская новый высокопроизводительный сервис 1С. Нам нужно было понять, как себя проявят наши новые серверы с процессорами 4.0 ГГц.

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

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

Дисклеймер: Для кого эта статья? Для руководителей малого и среднего бизнеса, которые не хотят терять деньги из-за сбоев в 1С. Если вы ищете способ застраховать свой бизнес от рисков и выбрать надежного партнера по сопровождению — здесь вы найдете ответы.

Представьте, что 1С — это ваш рабочий автомобиль. Вы же не станете ждать, пока у него на полном ходу откажут тормоза, чтобы поехать в сервис? Вы регулярно проходите техосмотр, потому что это нормально и гарантирует безопасность. С 1С — то же самое. Профессиональное сопровождение — это и есть тот самый «техосмотр», который защищает вас от «аварий»: внезапных сбоев, зависаний и, не дай бог, потери данных.

Продолжая аналогию, сопровождение — это как КАСКО. Вы платите небольшую сумму ежемесячно, чтобы в случае «ДТП» — будь то сбой после обновления, уход ключевого сотрудника или простая ошибка пользователя — не платить из своего кармана сотни тысяч рублей за срочный ремонт и не терять дни и недели работы.

Сегодня поговорим о довольно частой ошибке. Не все специалисты знают, как ее пофиксить. Это статья моего коллеги Андрея Бурмистрова, эксперта в сфере оптимизации производительности 1С. Разработкой на платформе «1С:Предприятие 8» Андрей занимается уже более 10 лет и знает нюансы. Он расскажет, когда возникает такая проблема и рассмотрит способы решения.

В этом рейтинге обновлены: Gemini 3, GPT 5.1, GLM 4.6, Kimmi K2.

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

Некоторые условия эксперимента:

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

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

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

А еще приглашаем вас на бесплатный вебинар 18 ноября в 11:00 мск, где разберем реальные провалы и фатальные ошибки при работе 1С в облаке. Поговорим о том, почему CPU не покажет реальных проблем, расскажем про кейс с дедлоками при нормальных показателях железа и объясним, почему 40% нагрузки должны стать вашим новым максимумом. 

Всем зарегистрировавшимся пришлем чек-лист по критическим настройкам 1С из практики обслуживания 7000 пользователей. 

Регистрация здесь

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

Сложность в том, что другие инженерные отрасли сильно отстают от IT в плане культуры разработки. Во времена моей юности по ФИДО ходила присказка "Если бы строители строили дома, как программисты пишут программы, то первый же залетевший дятел разрушил бы цивилизацию". Скорее всего автор этого афоризма никогда не был знаком с реальными строителями. Сейчас скорее наоборот - если бы строители писали программы, мы бы не вышли из эпохи арифмометров. Мы в IT приучены к тому, что ревью кода не пропустил коммит с лишним пробелом.

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

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

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

Продолжаем знакомить вас с улучшениями СУБД Tantor Postgres для работы с продуктами 1С. В рамках предыдущей статьи о нововведениях версии 17.5 мы разобрали арсенал специализированных функций, призванных существенно ускорить выполнение типичных для 1С операций, снизить нагрузку на инфраструктуру и упростить администрирование. Сегодня мы рассмотрим, с какими проблемами можно столкнуться при высоких значениях default_statistics_target, расскажем о новых оптимизациях для ускорения выполнения запросов, и, конечно, коснемся временных таблиц.

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Прямая интеграция 1С и CRM или разных баз 1С может давать сбои. Например, в одном из недавних проектов у заказчика при стандартном обмене задваивались данные. Мы придумали, как решить проблему с помощью сервиса внутри DATAREON Platform. Короткий кейс, который показывает, как использовать возможности «посредника» для решения не совсем типовых задач.

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

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

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

"Нужно?", "Не нужно?", "А если у меня SSD-диск?", "А какой эффект от перестроения индексов?", "А я не успеваю за ночь. Что делать?"

Разберем подробно все нюансы.

Продолжаю цикл статей из серии давно минувших дней.

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

2010г: по семейным обстоятельствам я оказался в глубоком финансовом кризисе. У меня не было денег даже на бензин. Один знакомый мне предложил поработать у них в отделе 1с-ником. Оплата была небольшая (по сравнению с рынком). Я согласился поработать у них несколько месяцев, пока не найду нормальное место, такой и был изначальный уговор. В отделе 1С было 3 человека, я стал четвертым.

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

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

В том отделе 4 человека. Одна из их задач была подбирать копейки для счетов-фактур. Чтобы строки с итоговой суммой сходились. Ну вы знаете про округление. Для этого у них был целый инструмент - документ в 1С аж с десятитысячными долями в ценах! Они там сидели вручную подбирали десятые доли копеек. Этот процесс был легендарным. Считалось, что его нельзя автоматизировать - кто ни пробовал, ни у кого не получалось, так мне сказал начальник.

Да как так? Не может такого быть! Я-не-ве-рю! Покажите!