Есть предложение к разработчику данного плагина. По протоколу обмена данными участвует уникальный идентификатор UUID. Каждый объект имеет свой уникальный идентификатор. Объект в данном случае - это категория, заказ, клиент, товар, артикул, тип цены, склад, учетные единицы и "моя любимая" характеристика. В последних версиях синхронизация происходит по человекодоступным полям. Например, если изменить название характеристики, появляется дубль со старым названием. Или меняешь символ в названии товара, создаётся новый дубль. А если по протоколу, то данные объекты должны обновиться, так как не может существовать два объекта с одинаковыми uuid. Можно посмотреть одну внешнюю обработку 1с которая называется, помоему "ВыгрузкаЗагрузкаДанныхXML83.epf". Данная обработка существует давно, служит для синхронизации одинаковых баз.
Нужно учесть момент загрузки схемы данных. Нужен инструмент управления характеристиками. Чтобы можно сгруппировать по типам товаров. Так как, например, ширина смартфона, это не тоже самое, что ширина телевизора.
При создании какого либо объекта в магазине, нужно генерировать uuid. Во все модели данных нужно внести соответствующие изменения. При импорте копировать или обновлять объекты в зависимости от наличия uuid.
Если данное предложение возьмёте в работу, дайте знать
13 комментариев
Поддерживаю
Ещё маленькое предложение по отладке. Добавить в настройку галочку (checkbox) пункт "включить запись xml обмена" И при включённым записывать в директорию логов в файлы все что передаётся с 1с.
Поддерживаю! UUID - это основа должна быть как при загрузке номенклатуры из 1С, так и при загрузке характеристик (свойств, категорий и прочего имеющего не простой (строка, число, булево), а ссылочный тип) этой номенклатуры, тем более что UUID при выгрузке из 1С на сайт передаются как для товара так и для его характеристик.
Я посмотрел схему обмена, сейчас используется 2.05, в ней у Объекта "ХарактеристикиТовара" нет "Ид".
<xsd:complexType name="ХарактеристикиТовара"> <xsd:annotation> <xsd:documentation>Уточняет характеристики поставляемого товара. Товар с разными характеристиками может иметь разную цену</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="ХарактеристикаТовара" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="Наименование" type="cml:НаименованиеТип"/> <xsd:element name="Значение" type="cml:ЗначениеТип"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType>Но в 2.06 "Ид" появилась.
<xsd:sequence> + <xsd:element name="Ид" type="cml:ИдентификаторГлобальныйТип" minOccurs="0"/> <xsd:element name="Наименование" type="cml:НаименованиеТип"/> <xsd:element name="Значение" type="cml:ЗначениеТип"/> </xsd:sequence>Плюсы данной схемы:Например: Характеристика/свойство "Ширина". Для одного типа товара значения в метрах (1.2, 1.4, 2.6, ...), а для другого в миллиметрах (800, 940, 1005, ...)
Может перейдем к версии 2.08? Хотя, для данного реализованного функционала движа хватит 2.06
Почему в схеме версии 2.05 у объекта "Свойство" есть "Ид", а в коде не используется?
<xsd:complexType name="Свойство"> <xsd:annotation> <xsd:documentation>Описывает свойство товара и возможные варианты значений этого свойства</xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="Ид" type="cml:ИдентфикаторГлобальныйТип"> ...Проблема в том, помимо версий стандартов есть кастомные надстройки (как это было с поддержкой информации об остатках на нескольких складах — изначально это появилась как ручная доработка/патч для битрикс/1С, поскольку ребята договорились; а после это уже вошло в стандарт) и в общем случае надо поддерживать обратную совместимость (хотя бы на уровне настройки - какую версию CML использовать)
Неоднозначности сопоставления характеристик действительно представляют проблему при наполнении магазина из 1С. Использование уникальных идентификаторов позволит её решить, но есть неясность — первичное сопоставление характеристик 1С и существующих в shop. Если есть возможность выгрузить все характеристики 1С в виде отдельного списка с названием и идентификатором, то это было бы решением. При текущем варианте: загрузка файла в ручном режиме, холостой прогон для получения списка характеристик, встретившихся в файле и их сопоставление существующим характеристикам (без UUID), либо указание типа характеристики, если она добавляется как новая.
UUID - генерируется всегда рандомно при первом создании любого объекта. Следовательно мы создаем свои новые UUID текущим характеристикам в shop. Например когда пользователь уже использует shop и установил плагин cml1c. Дальнейшие его действия, импорт характеристик и свойств к себе 1с.
Предлагаю - каталог по типам характеристик/свойств товаров взять за основу наработки Яндекс Маркета
Ролик - "Откуда берутся свойства и характеристики в 1с". Почему бы не взять нам там же?
Приглашаю всех желающих к участию разработки плагина cml1c GitHub.com. А так же разработчиков Webasyst. Хотя бы в роли модератора.
Добавленный функции:
"На повестке дня":
Всех адекватных добавлю в со авторы.
С радостью приму участие в тестировании со стороны 1С, к сожалению в остальном не силен. Как с вами связаться?
С точки зрения "обратной совместимости" лучше было бы сделать форк от репозитория shop и дальше вносить свои правки. Это позволить видеть полную историю плагина, а также позволит делать Pull request-ы в основной репозиторий и получать наши исправления и доработки. Так же в этом случае все пользователи смогут получать улучшенный плагин через инсталлер, пусть и с задержкой (если вы не против). И не будет проблем с конфликтом идентификаторов плагина — вы используете тот же идентификатор и пользователь сейчас установив вашу версию кода сможет обновиться в инсталлере на "старую" версию кода.
По коду обязательно подскажем и проконсультируем (после беглого осмотра есть мелкие замечания, но они пока не существенны).
Давайте так и начнем. Я не нашел репозиторий shop. Готов перезалить, нужна ссылка.
Этот репозиторий закрытый, для получения доступа потребуется формальная регистрация
Предлагаю написать REST API, т.к. более универсально и гибко чем CML, и для серьезных задач "типовую выгрузку 1С" все равно править нужно (как минимум регистрация изменений того что дошло а не только того что отправлено). Заготовка есть.