Обмен данными в формате EnterpriseData, встроенный в прикладную конфигурацию на БСП: правила обработки данных (ПОД), конвертации объектов (ПКО) и свойств (ПКС), менеджер обмена, пакеты XDTO, версии формата, AdditionalInfo, регистрация изменений, формирование и чтение сообщения, публичные идентификаторы и сопоставление объектов. Используй, когда надо разобрать или доработать такой обмен: объект не попал в сообщение, при загрузке создался дубль вместо обновления, реквизит теряется при повторной...
Scanned 9/28/2026
Install to Claude Code
npx -y skills add mr-ske1r/1c-ai-devstart --skill enterprisedata-exch --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Enterprisedata Exch?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/mr-ske1r-enterprisedata-exch)More formats (shields.io, HTML) on the badges page.
---
name: enterprisedata-exch
description: "Обмен данными в формате EnterpriseData, встроенный в прикладную конфигурацию на БСП: правила обработки данных (ПОД), конвертации объектов (ПКО) и свойств (ПКС), менеджер обмена, пакеты XDTO, версии формата, AdditionalInfo, регистрация изменений, формирование и чтение сообщения, публичные идентификаторы и сопоставление объектов. Используй, когда надо разобрать или доработать такой обмен: объект не попал в сообщение, при загрузке создался дубль вместо обновления, реквизит теряется при повторной загрузке, не читается свойство расширения формата, нужно передать своё поле между базами или добавить правило через расширение конфигурации. Не для создания и выпуска правил в самой конфигурации «Конвертация данных 3.0» и не для написания HTTP-клиентов и файловых обменов с внешними системами."
---
# Обмены EnterpriseData через БСП
> Нормы кода — в `.claude/rules/1c-rules.md` (единственный источник правил).
> Порядок обращения к живой базе — в `.claude/rules/mcp.md`.
> Здесь — устройство механизма, порядок доказательства и практика доработки.
## Основной принцип
Определяй возможности обмена по фактическому коду и метаданным, а не по названию или предполагаемой версии БСП. Наличие метода, реквизита либо XDTO-пакета не доказывает, что механизм вызывается и поддержан по всей цепочке.
## Граница применения
Используй скилл для встроенного в прикладную конфигурацию обмена EnterpriseData: регистрация, ПОД, ПКО, ПКС, менеджер обмена, XDTO, `AdditionalInfo`, идентификация, загрузка, выгрузка и доработка через расширение.
Создание и выпуск самих правил внутри конфигурации «Конвертация данных 3.0» скилл не покрывает. Сгенерированный менеджер, уже встроенный в прикладную конфигурацию, в область входит.
## Две оси, которые нельзя смешивать
- **Направление правила** — отправка или получение. Это свойство самого ПОД или ПКО: у правила отправки и правила получения разные обработчики и разный смысл колонок ПКС.
- **Фаза процесса** — выгрузка (формирование сообщения) или загрузка (чтение сообщения).
Оси соответствуют друг другу, но называй ту, которую видишь в артефакте: у правила — направление, у цепочки вызовов — фазу. Смешение слов маскирует ошибку «правку внесли в правило противоположного направления».
## Рабочий порядок
1. Найди план обмена, его модуль менеджера и `ПриПолученииНастроек`. Зафиксируй URI формата, реально зарегистрированные версии и соответствующие менеджеры.
2. Проверь цепочку возможностей: объявление → вызов → использование результата. Не делай вывод по одному найденному имени.
3. Раздели проблему на слои: регистрация, конвертация, транспорт, идентификация и запись.
4. Отделяй наблюдаемый факт от вывода. Если исходников, сообщения или журнала не хватает, перечисли недостающий артефакт и не выдумывай поведение.
5. При изменениях выбирай минимальный устойчивый шов расширения и проверяй обе стороны обмена.
Читай исходники тем способом, который доступен в проекте: выгруженные в XML исходники конфигурации, метаданные живой базы через MCP по `.claude/rules/mcp.md`, обычный поиск по XML и BSL. Отсутствие какого-то одного инструмента не отменяет разбора — меняется только глубина доступных доказательств, и её надо назвать в выводе.
## Имена методов и структур — ориентиры, а не контракт
В файлах `references/` названы конкретные методы, структуры и реквизиты БСП. Ищи по ним, но не опирайся на них как на гарантию: состав и сигнатуры меняются между поколениями БСП, а часть механизмов в старых поколениях отсутствует целиком. Прежде чем строить вывод на имени, найди его в коде исследуемой конфигурации.
Особая осторожность с близкими именами: в одном модуле могут соседствовать `КонвертацияСвойстваСтруктурыОбъектаXDTO` и `КонвертацияСвойствСтруктурыОбъектаXDTO` — это разные методы.
**Уровень достоверности:** имена и описанное поведение сверены с исходниками XDTO-сервера двух демо-конфигураций БСП — 3.1.10.369 и 3.1.12.281. Это чтение кода механизма, а не воспроизведение обменом: ни один сценарий прогоном сообщения не проверялся.
Отдельно от этого чтения стоят утверждения о расширении XDTO-формата, взятые из методической статьи ИТС «Расширение формата обмена EnterpriseData 3.0» (30.09.2023): это официальный источник, но и он не заменяет проверки прогоном на конкретной паре баз.
Две эти версии — просто то, что было доступно, **а не границы, на которых что-то менялось**. Из них видно, что участок в одной точке устроен так, а в другой иначе; в каком выпуске произошёл переход — неизвестно, промежуточные и более старые выпуски не смотрели. Наблюдения по этим двум точкам собраны в `architecture.md`, разделе «Две проверенные точки: что в них различается». Никакое утверждение скилла не следует читать как «поддерживается начиная с версии N».
## Куда перейти
- Для модели механизма, карты метаданных, версий, ПОД/ПКО/ПКС и публичных идентификаторов полностью прочитай [references/architecture.md](references/architecture.md).
- Для выбора между правилами, `AdditionalInfo` и расширением XDTO, а также для доработки через расширение полностью прочитай [references/customization.md](references/customization.md).
- Для статической трассировки и поиска причины отсутствующей регистрации, выгрузки, загрузки или сопоставления полностью прочитай [references/diagnostics.md](references/diagnostics.md).
Если задача затрагивает несколько режимов, прочитай каждый применимый файл полностью.
## Контракт результата
Вывод должен содержать:
- найденную версию формата и доказательство её фактической поддержки;
- восстановленную цепочку до точки разрыва;
- слой, где находится проблема или изменение;
- различение фактов, выводов и неизвестного;
- решение, совместимое с обнаруженными возможностями БСП;
- проверку отправителя и получателя, если меняется контракт сообщения.
Не подменяй трассировку временным диагностическим кодом. Сначала восстанови цепочку по исходникам и сопоставь её с метаданными, XML-сообщением, регистрами и доступными журналами. Если после этого остаются нерасхождённые гипотезы, назови их и то, что должен различить код, и получи согласие пользователя — выполнение кода в его базе регулируется `.claude/rules/mcp.md`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!