Обработка подготавливает тестовую базу для удобного тестирования и разработки.
Файлы
ВНИМАНИЕ:
Файлы из Базы знаний - это исходный код разработки.
Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы.
Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных.
Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.
Для того, чтобы протестировать новый функционал в 1С:Документооборот, нужно запускать процессы, создавать задачи.
Если у вас включены рассылки по Email, пользователи начнут получать письма из тестовой базы, эта проблема решается сбросом всех Email.
Так же вам требуется зайти под любым пользователем и проверить, как будет выглядеть процесс с правами и интерфейсом пользователя, для этого нужно зайти под ним в базу, поэтому пароли всех пользователей будет заменены.
При восстановлении базы из бэкапа в копию требуется обновить нумерацию документов, тоже выполняется.
Проверяет, что это копия базы, на рабочей не выполняется.
Штатная страховка внутри цепочки обработки умеет прятать дефекты того шага, который стоит перед ней. У нас так и вышло: валидатор чинил результат постфактум, на выходе всё выглядело корректно, и никто не видел, что предыдущий шаг молча теряет данные. Вылезло это только на независимой проверке чужими глазами. Разбираю, чем инвариант отличается от сценарного теста и почему обычное умножение вытащило дефект из красивой метрики 0,997. Отдельно про 13 дублей, которые приехали из источника ещё до всякой обработки, и про две находки, которые оказались вообще не моими: они жили в эталонной реализации, откуда я списывал логику. Вторая часть про лимит выхода модели: почему обрезка ответа по длине это тихий ноль в мониторинге и как смена формата на дельты уронила выход до 4 951 токена. Есть отклонённые гипотезы и честный список того, чего мы так и не померили.
Обработка «Изменения движений» проверяет, меняются ли движения документов после перепроведения — без изменения данных в базе (перепроведение в транзакции с откатом). Удобна после обновления конфигурации, рефакторинга проведения и для регрессии доработок, в том числе сгенерированных ИИ. Можно запускать из формы или программно (регламент, HTTP-сервис, автотесты): задаёте период, виды документов и регистров, лимит выборки — получаете отчёт и таблицу расхождений.
Четыре года в интеграторе я работал с git и EDT. Git после хранилища полюбил сразу: видно, кто и что менял. С EDT сложнее: тормозит, ошибки при обновлении ERP, автономный сервер внутри него работает только с файловой базой. На новой работе команда захотела перейти на git, я развернул EDT, и оно на второй день разрушило проект при загрузке расширения. Тогда я решил дать команде git с привычным Конфигуратором и инструмент, который за минуту доносит коммит до базы через ibcmd, вместо получасовой загрузки из файлов. На новой работе разрешили ИИ, и я написал это приложение с его помощью: от чтения документации и первого ТЗ до идей в электричке. Впервые за годы снова почувствовал себя творцом, а не закрывателем задач. По дороге приросли выгрузка, объединение и проверка конфигурации по коммитам, YAxUnit и режим MCP-сервера. В статье: схемы, скриншоты, грабли и честный список ограничений. Ссылки пока нет: хочу понять, нужно ли это кому-то, кроме меня.
В экосистеме 1С давно живут сотни инструментов: от Конфигуратора и Хранилища до систем тестирования, мониторинга, интеграции и CI/CD. Я собрал их в Ландшафт технологий, а теперь добавляю данные о реальном использовании. Рассказываю, как устроена карта, что показал первый опрос и почему в новой волне особенно нужны администраторы, аналитики и тестировщики.
Платформа 1С давно вышла за рамки учетных систем. Сегодня это полноценная среда для создания сложных, высоконагруженных и распределенных приложений. А значит, и стек технологий современного разработчика кардинально изменился. Систематизируем весь инструментарий, который превращает 1С-программиста в инженера: от EDT и Git до автотестов на YAxUnit, контейнеризации приложений в Docker, мониторинга в Prometheus и организации шины данных на Kafka. Разберемся, зачем каждый инструмент нужен, как он вписывается в жизненный цикл разработки и с чего начать его внедрение.
Шесть внешних отчётов на боевой базе крупной сети переписали за неделю. По секундомеру ускорились четыре, в акт пошли три: у одного отчёта минус тринадцать процентов оказались выбросом нагрузки прода, а не эффектом кода. Поймал это чередующийся замер до/после в одном окне, обычные три прогона с метрикой "минимум" показывали ускорение уверенно.
Дальше в тексте: почему построчная сверка выхода ломается ровно на тех правках, ради которых её заводят; из чего собирается повторяемый слепок результата и почему главную работу в нём делает нормализация, а хеш только сигнализация; где слепок не берётся вовсе и его заменяет по-колоночная сверка; чем проверять пересчёт итогов, чистку данных и операции с кластером. Отдельно - гипотеза, которую замер отклонил, и честный счёт, во что вся эта дисциплина обходится.
Пентест – это не только поиск уязвимостей, но и сложный проект, в котором ошибка может привести к простою, инциденту и потере доверия заказчика. Рассказываем, как правильно определить цели и границы работ, распределить ответственность, выстроить коммуникации и сделать неизбежные риски и изменения контролируемыми. На реальных кейсах разбираем, почему задержка с сообщением о критической уязвимости способна перечеркнуть технический успех, как управленческая рамка помогла разобраться в остановке турбины и когда выход за пределы скоупа приносит пользу бизнесу, а когда становится нарушением договоренностей.
Написать тест на 1С несложно. Дорого стоит привести базу в состояние, где прогон вообще стартует: семь шагов, каждый ломает запуск молча — без ошибки, без записи в журнале. И эту цену платит заново каждый новый человек на проекте. Разбираю молчаливый отказ окружения как класс проблем, показываю, почему его не закрывают ни документация, ни скрипт развёртывания, и предлагаю решение — фиксацию состояния в артефакте с машинно-проверяемым критерием приёмки. Подход проверен на сквозной задаче (первая задача экзамена «1С:Специалист по платформе» с юнит- и функциональными тестами), а затем перенесён на пул тестовых баз с типовыми конфигурациями. Отдельно — каталог симптомов и их настоящих причин, который пригодится независимо от инструментария.
