«Запуск 1С» — это не финиш, а старт полосы препятствий
Привет из серверной, я СБиСик, тот самый пушистый, который любит копаться в регистрах не меньше, чем в коробке с печеньками. Сегодня разбираем странное явление: проектная команда рапортует «Система введена в эксплуатацию», ленты-розы, хлопушки… а уже на второй неделе склады в Excel, продажи в мессенджерах, отчёты пляшут как хотят. Что именно там ломается и почему это не «ошибка 1С», а стык людей, прав, данных и обменов — об этом и поговорим.
Где трещит «свежее» внедрение: короткая карта поломок
Беру тетрадку с пометкой «после запуска» и листаю последние проекты. Почти в каждом вижу повторяющийся список:
1. Права доступа. Казалось бы, роль «менеджер» протестирована. Но в бою выясняется: вчера добавили новый вид скидки, документ теперь ведёт регистр накопления, а роль доступа к нему не даёт. Человек злится, проводит руками в обход, база потом плачет от рассинхрона.
2. Обмены. Товар уехал на сайт, а обратно отгрузка не вернулась. Причина? Сайт внезапно обновил API, а в ERPs-скрипте жёстко забита старая версия. Да, на демонстрации «заказы туда-сюда» бегали бодро, но ночь после релиза вывела всё на чистую воду.
3. Отчёты. Красивый управленческий отчёт складывается шесть минут и падает по таймауту. Почему? В тесте было 5 000 строк, а в проде — 1,2 млн, плюс бухгалтерия сразу включила детализацию до номенклатуры.
4. Доработки. Любимый «магический» документ, который автоматически подставляет себестоимость, завис после обновления релиза. Код доработки цеплялся к старой форме, а теперь эта форма в конфигурации названа по-другому. Официальный релиз, кстати, честно предупреждал.
5. Производительность. На пилоте три пользователя, на бою тридцать. Проводят массово реализацию — сервер уходит на кофе-брейк, пользователи клянчат ресурсы у админа.
6. Данные. «Перенесли остатки» оказалось «перетащили всё, что лежало». Дубли контрагентов, нулевые ИНН, старая аналитика из ЗУП. Пару недель отчёты ещё держались, пока не пришёл НДС-квартал и всё это не сложилось в кашу.
Список можно продолжать, но идея ясна: ломаются стыки. Знаете, я даже завёл быстрый чек-лист и иногда забрасываю туда наблюдения в наш канал в MAX, потому что пока напишешь длинную статью — уже новая дырка вылезет у очередного клиента.
Почему «на копии всё работало», а на бою вдруг рассыпалось
Сценарии тестирования почти всегда короче жизни. В демо-сценарии менеджер оформляет один заказ, бухгалтер закрывает месяц, айтишник щёлкает «обновить справочник ЮЛ». В жизни же:
• 27 менеджеров пытаются одновременно оформить один и тот же товар по разным ценам, и только у двоих есть право редактировать ставку НДС.
• Бухгалтерия закрывает три базы параллельно, а в обмене прилетает левый код валюты.
• Руководитель требует отчёт «прямо сейчас», хотя регламентный расчёт ещё в процессе; запросы бьют по таблице движений, блокировки растут.
Получается смешная штука: система технически «стоит», но людям надо быстро продавать, закупать, списывать. Любая мелочь, которую не заметили на стенде, в полевых условиях превращается в 15-минутную паузу, потом в обход, потом в ежедневную практику. А дальше снежный ком: меняем права на лету, правим обмен «по-быстрому», добавляем условие в запрос… ещё два таких хода, и звёздный час отдела сопровождения гарантирован.
Я однажды приехал к клиенту через месяц после «успешного» релиза. Картина: склад работает в старой базе, магазин — в новой, отчёты собирают в Excel, а сервисный центр вбивает наряды сразу в три справочника. Почему? Первую неделю не успели донастроить роль «мастер», и мастерам было проще «пока что» вернуться к старой схеме. Грустно, но показательно.
Кстати, похожие истории мы иногда обсуждаем в нашем Telegram-канале: там народ делится, как ловил блокировки на расчёте зарплаты или почему отчёт «Прибыль и убытки» внезапно обнулился после обновления.
Реальные симптомы, по которым я понимаю: стык дал течь
Симптомы редко выглядят как красная табличка «Fatal error». Чаще пользователи жалуются:
— «Документ не проводится». Сразу думают на «права 1С» или кривые руки. А на деле — в конфигурации появилась новая проверка по доступности склада, старые тест-данные эту проверку не задевали.
— «Отчёт крутится бесконечно». Первое предположение — сервер не тянет. На самом деле разработчик недавно добавил пару полей в регистр и забыл индекс. На тесте пять строк — всё летало, на бою пять миллионов — летать перестало.
— «Товары пропали из обмена». База-источник и база-приёмник используют одинаковые GUID, но справочник заполняли руками и дважды выгрузили «Чай зелёный» под разными кодами. В логе обмена ошибок нет, зато на складе появляются лишние паллеты.
— «Периодически выкидывает из клиента». Админ проверяет сеть, думает, что свич моргает. Однако в серверном логе сыпятся deadlock-и из-за сильно параллельных запросов от нового отчёта руководителя. Клиент разрывает соединение, пользователь видит «ошибка соединения» и идёт делать кофе.
Заметьте, техническая причина и бизнес-проявление почти никогда не совпадают. Потому проверять надо и логи, и роли, и данные. И да, если человек копирует контрагентов вместо использования справочника, проблема не в нём одном. Система должна помогать, а не требовать телепатии.
«Ручной обход» как самая дорогая неисправность
Самое страшное — не падение сервера. Самое страшное — когда проблема кажется мелкой, и сотрудники молча придумывают лайфхак. Сколько раз видел: «Печать УПД не работает? Ладно, мы скопируем старую, переделаем даты». Десять минут хэнд-мейда умножаем на 40 документов в день, на 20 рабочих дней — выходит ощутимый минус прибыли. А ещё каждый ручной шаг — потенциальная точка ошибки, и через квартал ревизия выясняет нехватку на складе.
Один интересный случай. Магазин электроники, обмен с CRM. Заказы с сайта иногда дублировались. Менеджеры научились просто удалять дубли вручную. Красота! Пока не пришла чёрная пятница: за ночь вместо 3 000 заказов прилетело 6 000, половина из них — «копии копий». Удаляли три дня, потеряли кучу оплат. В логах обмена — ни одной критической записи, ведь для движка это был «нормальный» новый заказ.
Помните: временный обход живёт дольше вечного ремонта. Если пользователь изобрёл костыль, он им будет пользоваться, даже когда проблема уже устранена. Поэтому любая маленькая странность — звоночек, что за углом растёт снежный ком.
Что обычно путают при передаче «в эксплуатацию»
Есть классический «пакет документов» по проекту: инструкция, перечень изменений, регламент. Но когда поджимает дедлайн, список сужается до: «таблица соответствия прав» и пара скриншотов форм. Итог:
1. Никто не знает, какие отчёты были переделаны и почему.
2. В обменах нет описания полей, только общий рисунок потока.
3. Роли назначены «как на стенде», без учёта сезонных всплесков.
4. Журнал изменений к доработкам лежит у подрядчика на GitLab, доступ закрыт.
С таким багажом любая смена версии платформы — риск. Начинают звонить: «Мы обновились, а теперь документ продажи не закрывает регистр». Можно, конечно, откатиться, но вперёд надо как-то идти. А без описания — куда? В тумане.
Тут многие говорят: «нужна автоматизированная проверка». Нет, сначала нужна дисциплина: фиксируйте, что меняли, и кому передали. А уже потом добавляйте роботизированные тесты. Доработка без журнала — как двигатель без мануала, вроде пока шумит приятно, но когда прихватит, шансов меньше.
Кстати, пока писал этот абзац, клиент прислал подскозка (!) о том, что после обновления исчезла кнопка «Экспорт в Excel». Уже догадываюсь, где копать, но об этом позже…
Мы ещё не добрались до того, как правильно организовать контроль изменений и тестирование правок, да и истории про производительность я оставил за скобками. Дальше будет про то, как отличить пользовательскую опечатку от реальной ошибки в регистре, а ещё покажу лайф-чеклист «Запуск прошёл, что смотрим в первую очередь» — он пригодился почти во всех проектах за последний год. Продолжим через абзац…
Как найти корень, а не лепестки: мини-методика разборки
Сначала кажется, что каждая «ошибка 1С» уникальна. На деле 90 % случаев разбираются одной логикой: «Симптом → Лог → Проверка прав → Проверка данных → Повтор на копии». Работает даже там, где пользователи уверены, что «всё сломалось само».
1. Снимаем первый скрин и берём слова дословно. Не «ничего не работает», а «документ “Поступление” не проводится по кнопке F5». Эта фраза потом ляжет в фильтр лога и в ухо разработчику.
2. Смотрим журнал регистрации. 60 % поломок сразу выдают сообщение о том, что не хватает права записи или идёт конфликт блокировок. Если в журнале тишина, включаем режим отладки на копии и повторяем шаг.
3. Проверяем роли. Часто в карточке сотрудника осталось наследие тестов: два лишних профиля доступа, и «права 1С» попросту конфликтуют. Одну роль снимаем — сценарий лечится без кода.
4. Открываем данные. Нули в “Количество”, невалидный ИНН, пустой разрез аналитики — система падает, ведь «настройка 1С» честно ждёт корректных значений. Пока данные не поправим, никакая доработка не спасёт.
5. Повторяем на копии. Если баг воспроизводится в изолированной базе, идём в конфигурацию или обмен. Не воспроизводится — ищём сетевое, кеш-клиента, тонкости профиля пользователя.
Три кейса, где бизнес сам себе ставил подножку
Кейс «Блокировка при закрытии месяца». Бухгалтер запускала регламентное задание ровно в 18:00, когда отдел продаж массово проводил отгрузки. Лог блокировки упирался в один длинный запрос отчёта, который каждую минуту перезапускал руководитель. Лекарство: разнести задачи по времени, добавить индекс, в отчёте убрать лишнюю группировку. Стоимость простоя — два часа в день, два бухгалтера в переработке, нервный директор.
Кейс «Таинственные минусы на складе». Магазин добавил два новых подразделения, но забыли прописать их в правилах распределения. Документы приходовали товар в “Центральный склад”, а списание шло из “Интернет-точка”. Минусы всплыли после инвентаризации. Решение заняло четыре клика: дописали правило, сделали перемещение, пересчитали остатки. А убыток — 170 000 ₽ замороженного товара.
Кейс «Зависающий обмен ЭДО». Подрядчик расширил схему, добавив новый тег “CorrInvoiceID”. На тесте всё ок, в проде сертификат старого формата. У 1С нет права чтения нового атрибута — обмен в цепочке кликов падает. Исправили обновлением библиотеки и добавлением назначения прав к каталогу. Итог — три дня без накладных, штраф от контрагента.
Мини-чек-лист «Запуск прошёл — что смотрим в первую очередь»
1. Право на всё лишнее. Пользователь не должен видеть документы чужого юрлица? Проверяем отчёт “Движения документа” и просмотр справочников без фильтрации.
2. Обмены идут? В логе нет ошибок — не повод расслабляться. Смотрим количество и дату последнего пакета, сравниваем с внешней системой.
3. Регламентные задания. Включены ли оповещения о зависании? Таймаут — не меньше 30 минут, иначе длинные процедуры убьют очередь.
4. Данные чисты? Отчёт “Дубли контрагентов” и “Справочник номенклатура: пустой артикул” дают быстрый срез, пока база ещё маленькая.
5. Доработки в списке изменений. Если строки “Версия” и “Комментарий” пусты, вторая же попытка обновления превратится в русскую рулетку.
Эти пять пунктов закрывают 70 % фатальных историй первых трёх месяцев. Дальше уже идёт тонкая настройка отчётов, индексов и аппаратуры. Но старт без них — гарантия, что «сломалось после внедрения» превратится в хронику.
На этом пока точка. Какие ещё сюрпризы встретили после релиза? Давайте обсуждать — у каждого свой зоопарк, а коллективный опыт экономит часы и нервы.
