Прописать в документации на самом видном месте и несколько раз, что при использовании стандартных модулей обмена товарами между 1С и Битрикс товары никак не смогут быть выгружены в качестве торговых предложений, если в 1С номенклатура забита как обычные товары, а не как товары с характеристиками.
Для меня всегда было загадкой, как же 1С понимает, как делить товары на торговые предложения. Ну нигде не встречалась мне эта информация, пока не поставили вопрос ребром. Подавляющее большинство сайтов использует простые товары, без торговых предложений. Пару часов поиска (довольно неоднозначного, и всё встало на свои места).
Всё оказалось просто. В 1С есть обычная номенклатура и номенклатура с характеристиками. В первом случае вам никак не удастся выгрузить товары на сайт в качестве торговых предложений без дополнительного допиливания модуля обмена или изобретения обходных путей. Однако такой простой истины, на мой взгляд, нигде в документации не прописано.
Сегодня техподдержка официально подтвердила этот момент.
Для меня всегда было загадкой, как же 1С понимает, как делить товары на торговые предложения. Ну нигде не встречалась мне эта информация, пока не поставили вопрос ребром. Подавляющее большинство сайтов использует простые товары, без торговых предложений. Пару часов поиска (довольно неоднозначного, и всё встало на свои места).
Всё оказалось просто. В 1С есть обычная номенклатура и номенклатура с характеристиками. В первом случае вам никак не удастся выгрузить товары на сайт в качестве торговых предложений без дополнительного допиливания модуля обмена или изобретения обходных путей. Однако такой простой истины, на мой взгляд, нигде в документации не прописано.
Сегодня техподдержка официально подтвердила этот момент.
При настройке обмена товарами и заказами между ИМ и 1С'кой часто сталкиваемся с проблемами. Решаем их всегда одинаково: при завершении импорта, пока в папке еще лежат XML, копируем их в upload/xml/текущая дата и время/
И тогда пусть 1С сделает хоть 100 выгрузок, у нас останутся на сервере для "расследования" все ее XML'ки
Очень хотелось бы, чтобы такой механизм копирования файлов обмена с 1С был встроен в продукт изначально.
И тогда пусть 1С сделает хоть 100 выгрузок, у нас останутся на сервере для "расследования" все ее XML'ки
Очень хотелось бы, чтобы такой механизм копирования файлов обмена с 1С был встроен в продукт изначально.
Иногда бывает удобно отменять заказы в 1С, было бы удобно если их отмена корректно выгружалась на сайт.
Предлагаю, сделать отправку признака отмены заказа из 1С на сайт при отмене всех позиций в заказе в 1С и отправки причины отмена для первой строки в заказе в 1С.
Предлагаю, сделать отправку признака отмены заказа из 1С на сайт при отмене всех позиций в заказе в 1С и отправки причины отмена для первой строки в заказе в 1С.
Свойства товаров в 1С имеют параметр "назначение", при указании которого это свойство применимо к тем или иным товарам.
Необходимо автоматически вычислять свойства, применимые к товарам, участвующим в обмене, и только их записывать в таблицу свойств ИБ с товарами.
В нынешней ситуации имея в 1С каталог с тысячами свойств, при выгрузке части такого каталога (даже ничтожной), в ИБ попадут все эти тысячи. С товаром работать невозможно, с настройками ИБ работать невозможно.
Есть возможность настроить список выгружаемых свойств в настройке обмена, но:
Автоматический учёт назначения свойств при формировании файлов выгрузки позволит:
Необходимо автоматически вычислять свойства, применимые к товарам, участвующим в обмене, и только их записывать в таблицу свойств ИБ с товарами.
В нынешней ситуации имея в 1С каталог с тысячами свойств, при выгрузке части такого каталога (даже ничтожной), в ИБ попадут все эти тысячи. С товаром работать невозможно, с настройками ИБ работать невозможно.
Есть возможность настроить список выгружаемых свойств в настройке обмена, но:
- Выбрать пару сотен свойств из нескольких тысяч - задача для самых упорных и внимательных
- Чтобы не ошибиться, надо очень хорошо знать номенклатуру и её свойства (десятки тысяч позиций)
- Если номенклатура выгружается в несколько инфоблоков в рамках одной настройки обмена (разнести по разным нельзя, потому что они не должны пересекаться по времени во имя предотвращения удаления файлов выгрузки и таблицы b_xml_tree), то настройка выгружаемых свойств будет применена ко всем инфоблокам, что потребует выбрать все свойства.
Автоматический учёт назначения свойств при формировании файлов выгрузки позволит:
- уменьшить объём данных, передаваемых на сайт;
- снизит нагрузку на сайт при обработке загружаемых данных;
- повысить прозрачность работы с товарами на сайте.
По умолчанию, в последней Рознице данные выгружаются в Битрикс криво. Хотелось бы иметь правильный обмен из Розницы в Битрикс, т.к. далеко не все используют УТ, в силу её громоздкости. Хотелось бы, чтобы этот обмен происходил в реальном времени и позволял выгружать дополнительные свойства номенклатуры в HL-инфоблоки и привязывать элементы этих инфоблоков к соответствующим товарам.Продукт родственный а обмен не реализован. Надо исправлять.
По умолчанию, в последней Рознице данные выгружаются в Битрикс криво. Хотелось бы иметь правильный обмен из Розницы в Битрикс, т.к. далеко не все используют УТ, в силу её громоздкости.
Продукт родственный а обмен не реализован. Надо исправлять.
Продукт родственный а обмен не реализован. Надо исправлять.
Бесплатное дополнение к 1С слишком дорого обходится нам и клиентам.
Клиента надо предупреждать. что из-за этого дополнения он теперь всегда будет обновляться не сам, а со специалистом. И отдельно платить за тестирование и установку.
-----------
Причина в том, что дополнение изначально неправильно спроектировано и сделано. Сделано по принципу: берем 1С, и меняем в ней код.
Битрикс взял конфигурацию 1С, изменил в ней несколько объектов, и выложил это "дополнение".
Потом надо дополнение объединить со своей конфигурацией.
Это не дополнение, это "изменение".
"Дополнение" всегда идет для какой-то конкретной версии 1С. С другой может не работать. Это ИЗМЕНЕНИЕ мешает клиенту безопасно обновляться.
Клиент должен ждать выхода нового "дополнения", обновить 1С и поставить "дополнение". Причем, для строго определенной версии.
-----------
Надо сделать дополнение менее зависимым от объектов конфигурации 1С.
Спроектировать дополнение таким образом, чтобы при установке оно не изменяло стандартные объекты, а добавляло только новые.
Если необходимо что-то изменить в стандартном объекте платформы (добавить пункт в меню, например) — делать это через API 1С мастером настройки
Реализовать систему обновлений. Чтобы новый функционал приходил через систему обновлений и мастер настройки настраивал бы то, что надо.
Опубликовать перечень важных объектов конфигурации, с которыми работает дополнение. Нужно для установки на изменёные конфигурации.
Сделать Автотест наличия важных объектов конфигурации. Например, если в 1С отсутствует справочник "номенклатура", система обновления должна выдать предупреждение об ошибке, со списком обязательных объектов конфигурации.
----------
Когда-то Виртуальная машина Битрикса прошла этот путь. Были конфигурации 1.6, 2.0, 3.0, 3.1, которые не обновлялись, и это всех задалбывало. Системные требования Битрикса менялись и надо было заново настраивать сервер и переносить сайт.
Теперь 4.0, 4.1, 4.2, 4.3 - худо-бедно обновляются. Это круто. Без полной переустановки появились Push and Pull на nginx и поиск сфинкс.
-----------
Надеюсь, дополнение к 1С достаточно созрело, чтобы быть отдельным, и меньше зависеть от конфигурации.
Тогда можно будет автоматизировать выпуск критических обновлений под все платформы, если в какой-то версии обнаружился страшный глюк. И все легко обновятся.
Клиента надо предупреждать. что из-за этого дополнения он теперь всегда будет обновляться не сам, а со специалистом. И отдельно платить за тестирование и установку.
-----------
Причина в том, что дополнение изначально неправильно спроектировано и сделано. Сделано по принципу: берем 1С, и меняем в ней код.
Битрикс взял конфигурацию 1С, изменил в ней несколько объектов, и выложил это "дополнение".
Потом надо дополнение объединить со своей конфигурацией.
Это не дополнение, это "изменение".
"Дополнение" всегда идет для какой-то конкретной версии 1С. С другой может не работать. Это ИЗМЕНЕНИЕ мешает клиенту безопасно обновляться.
Клиент должен ждать выхода нового "дополнения", обновить 1С и поставить "дополнение". Причем, для строго определенной версии.
-----------
Надо сделать дополнение менее зависимым от объектов конфигурации 1С.
Спроектировать дополнение таким образом, чтобы при установке оно не изменяло стандартные объекты, а добавляло только новые.
Если необходимо что-то изменить в стандартном объекте платформы (добавить пункт в меню, например) — делать это через API 1С мастером настройки
Реализовать систему обновлений. Чтобы новый функционал приходил через систему обновлений и мастер настройки настраивал бы то, что надо.
Опубликовать перечень важных объектов конфигурации, с которыми работает дополнение. Нужно для установки на изменёные конфигурации.
Сделать Автотест наличия важных объектов конфигурации. Например, если в 1С отсутствует справочник "номенклатура", система обновления должна выдать предупреждение об ошибке, со списком обязательных объектов конфигурации.
----------
Когда-то Виртуальная машина Битрикса прошла этот путь. Были конфигурации 1.6, 2.0, 3.0, 3.1, которые не обновлялись, и это всех задалбывало. Системные требования Битрикса менялись и надо было заново настраивать сервер и переносить сайт.
Теперь 4.0, 4.1, 4.2, 4.3 - худо-бедно обновляются. Это круто. Без полной переустановки появились Push and Pull на nginx и поиск сфинкс.
-----------
Надеюсь, дополнение к 1С достаточно созрело, чтобы быть отдельным, и меньше зависеть от конфигурации.
Тогда можно будет автоматизировать выпуск критических обновлений под все платформы, если в какой-то версии обнаружился страшный глюк. И все легко обновятся.
У нас каждый второй клиент спрашивает: "почему я не могу выгрузить только те товары, которые есть на складе?"
Сейчас выгрузка изменений работает так:
- добавление нового товара - реализовано
- изменение товара - реализовано
- удаление товара с сайта - не сделано
При выгрузке изменений возможны ситуации, когда неактуальные в 1С товары не удаляются, а остаются на сайте.
Наши клиенты покупают Битрикс для обмена с 1С. К сожалению, более 5 лет в обмене есть ошибки, о которых постоянно спрашивают на форуме, но их не стремятся исправлять.
Ошибка с выгрузкой изменений портит жизнь многим работающим проектам, и заставляет партнеров придумывать костыли.
Как исправить? Очень просто. Давайте постучим по голове программистам 1C, чтобы в новой версии дополнения была опция "При выгрузке измений учитывать всю номенклатуру".
В плане обмена есть измения о всех товарах. Почему-то обмен с 1С выбирает только те, которые попали в отбор.
Пусть 1С передает все товары из плана обмена:
- товары, которые попали в отбор выгружаются целиком,
- товары, которые не попали в отбор - передать только гуид. Например: так:
Программисты 1С могут возразить: можем ли мы передавать ГУИД номенклатуры, которой на сайте не было нет и не будет?
Да можем. Мы не знаем был ГУИД d0e820f4-2b68-4d7f-ba39-000000001 раньше на сайте или нет, но мы можем сообщить сайту, что этот товар изменился и если он на сайте есть, пусть удалится или деактивируется в зависимости от настроек сайта.
Сейчас выгрузка изменений работает так:
- добавление нового товара - реализовано
- изменение товара - реализовано
- удаление товара с сайта - не сделано
При выгрузке изменений возможны ситуации, когда неактуальные в 1С товары не удаляются, а остаются на сайте.
Наши клиенты покупают Битрикс для обмена с 1С. К сожалению, более 5 лет в обмене есть ошибки, о которых постоянно спрашивают на форуме, но их не стремятся исправлять.
Ошибка с выгрузкой изменений портит жизнь многим работающим проектам, и заставляет партнеров придумывать костыли.
| Пример: фирма покупает одежду из Китая. Продает. Покупает новую номенклатуру. Продает.... Товары, остаток которых 0, на сайте больше не нужен. Поэтому логично в 1С поставить условие отбора "Остаток >0". Это позволяет не выгружать лишние старые товары с десятками гигабайт картинок. 1С при выгрузке изменений не выгружает товары которые не попали в отбор. При выгрузке изменений если товара в 1С стало 0, то в обмен он не попадает и товар остается на сайте. Потом магазин исключают из Яндекс-маркета. |
В плане обмена есть измения о всех товарах. Почему-то обмен с 1С выбирает только те, которые попали в отбор.
Пусть 1С передает все товары из плана обмена:
- товары, которые попали в отбор выгружаются целиком,
- товары, которые не попали в отбор - передать только гуид. Например: так:
<?xml version="1.0" encoding="UTF-8"?> <КоммерческаяИнформация ВерсияСхемы="2.04" ДатаФормирования="2013-09-03T13:05:11"> ... <Каталог СодержитТолькоИзменения="true"> ... <Товары> <Товар> <Ид>d0e820f4-2b68-4d7f-ba39-9d3683fcb0e7</Ид> <Наименование> Нитки Ирис 25г. 150м</Наименование> ... </Товар> // товары, которые есть в плане обмена, но не попали в отбор по фильтру тоже должны выгружаться. // Хотя бы так. <Товар Удален="true"> <Ид>d0e820f4-2b68-4d7f-ba39-000000001</Ид> </Товар> <Товар Удален="true"> <Ид>d0e820f4-2b68-4d7f-ba39-000000002</Ид> </Товар> <Товар Удален="true"> <Ид>d0e820f4-2b68-4d7f-ba39-000000003</Ид> </Товар> </Товары> </Каталог> </КоммерческаяИнформация> |
Программисты 1С могут возразить: можем ли мы передавать ГУИД номенклатуры, которой на сайте не было нет и не будет?
Да можем. Мы не знаем был ГУИД d0e820f4-2b68-4d7f-ba39-000000001 раньше на сайте или нет, но мы можем сообщить сайту, что этот товар изменился и если он на сайте есть, пусть удалится или деактивируется в зависимости от настроек сайта.
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
