| |||||||||
| |||||||||
Назревает вопрос актуализации решения интеграции 1С
Пример приведенный на странице
указывает на версию 1С 7.7
В нашем случае, 8. Согласно описанию, текущая реализация исполнима при условии ручного формирования отчета и выгрузки на сайт. В свою очередь, это создает некоторые сложности.
1 Действительная база складских остатков довольно обширна и на сайт не поместится. Верней поместится, но сайт на хостинге упадет. Потребуется выносить на сервер, а это тоже, в нашем случае не решение.
2 Если отказаться от использования всей базы, а работать только с наиболее экономически актуальным ассортиментом, потребуется фильтрация остатков или вынесение в отдельную базу. Что тоже не решение.
Хотя, я в 1С не великий спец и утверждать не стану. Это лишь мои предположения.
Тем не менее, назревает вопрос в реализации плотного взаимодействия отображаемого на сайте и действительных остатков на складе.
Речь не идет о существующем сайте. Полагаю для этих целей потребуется создавать отдельный.
В этом случае, будет актуален вариант автоматизации формирования отчета в 1С по временному параметру и автоматического сопряжения и выгрузки на сайт.
Но опять же, возникает вопрос. Выгрузка будет происходить целым файлом. А если он будет весить 10-15 МБ?
При ручной загрузке ТХТ файла, на сайте есть возможность выбора обновления отдельных полей.
А реализуемо ли это при интеграции?
И, от чего-то думается, в подобном подходе к решению задач куда как целесообразней, базу разбивать на отдельные файлы таблицы характеристик.
То-бишь - ID, наименование, артикул - это одна таблица.
Цена розница, цена опт, остаток - это другая таблица.
Описания и сео - третья таблица.
В этом случае, возможно создание тхт отчета в 1С по полям ID, цена, остаток при условии изменений. Т.е. если в остатке и цене нет изменений, товар в отчет не попадает, если изменения есть - выводим в отчет. После выгрузки на сайт, индексация сопоставляет загруженное с имеющимся и изменят именно загруженную таблицу по соответствию. И даже если, загружаемый отчет будет состоять из 10т наименований, это не мегабайты.
Более того, если сопрягать и заказы, и, даже рассматривать вопрос внесения изменений в режиме настоящего времени, сама процедура обмена данными окажется весьма решаемой. А это очень серьезный подход.
Представим, что сопряжение организовано в режиме авто обновления по факту изменений. Как только в 1С происходит списание с остатка, изменение цены, поступление на остаток, автоматом формируется отчет и отсылается на сервер. В этом случае отчет не по всей базе создается, а по измененным позициям. И пакет для отправки состоит только из измененных таблиц. А это всего лишь несколько байт. На худой конец, несколько килобайт.
Подозреваю, мастер читая это, сидит и произносит, что-то типа - моп ту еть!
Однако прогресс! Он ведь на месте не стоит, за ним вообще хрен угонишься. Но пытаться-то надо...блин!
Вот сейчас и думаем, как быть-то?
Шибко уж интеграшку хочется, да не совковую.
Пример приведенный на странице
указывает на версию 1С 7.7
В нашем случае, 8. Согласно описанию, текущая реализация исполнима при условии ручного формирования отчета и выгрузки на сайт. В свою очередь, это создает некоторые сложности.
1 Действительная база складских остатков довольно обширна и на сайт не поместится. Верней поместится, но сайт на хостинге упадет. Потребуется выносить на сервер, а это тоже, в нашем случае не решение.
2 Если отказаться от использования всей базы, а работать только с наиболее экономически актуальным ассортиментом, потребуется фильтрация остатков или вынесение в отдельную базу. Что тоже не решение.
Хотя, я в 1С не великий спец и утверждать не стану. Это лишь мои предположения.
Тем не менее, назревает вопрос в реализации плотного взаимодействия отображаемого на сайте и действительных остатков на складе.
Речь не идет о существующем сайте. Полагаю для этих целей потребуется создавать отдельный.
В этом случае, будет актуален вариант автоматизации формирования отчета в 1С по временному параметру и автоматического сопряжения и выгрузки на сайт.
Но опять же, возникает вопрос. Выгрузка будет происходить целым файлом. А если он будет весить 10-15 МБ?
При ручной загрузке ТХТ файла, на сайте есть возможность выбора обновления отдельных полей.
А реализуемо ли это при интеграции?
И, от чего-то думается, в подобном подходе к решению задач куда как целесообразней, базу разбивать на отдельные файлы таблицы характеристик.
То-бишь - ID, наименование, артикул - это одна таблица.
Цена розница, цена опт, остаток - это другая таблица.
Описания и сео - третья таблица.
В этом случае, возможно создание тхт отчета в 1С по полям ID, цена, остаток при условии изменений. Т.е. если в остатке и цене нет изменений, товар в отчет не попадает, если изменения есть - выводим в отчет. После выгрузки на сайт, индексация сопоставляет загруженное с имеющимся и изменят именно загруженную таблицу по соответствию. И даже если, загружаемый отчет будет состоять из 10т наименований, это не мегабайты.
Более того, если сопрягать и заказы, и, даже рассматривать вопрос внесения изменений в режиме настоящего времени, сама процедура обмена данными окажется весьма решаемой. А это очень серьезный подход.
Представим, что сопряжение организовано в режиме авто обновления по факту изменений. Как только в 1С происходит списание с остатка, изменение цены, поступление на остаток, автоматом формируется отчет и отсылается на сервер. В этом случае отчет не по всей базе создается, а по измененным позициям. И пакет для отправки состоит только из измененных таблиц. А это всего лишь несколько байт. На худой конец, несколько килобайт.
Подозреваю, мастер читая это, сидит и произносит, что-то типа - моп ту еть!
Однако прогресс! Он ведь на месте не стоит, за ним вообще хрен угонишься. Но пытаться-то надо...блин!
Вот сейчас и думаем, как быть-то?
Шибко уж интеграшку хочется, да не совковую.
Рассматривая дальше, стоит обратить внимание на отображение количества в остатке.
Состояние склада - есть маленько, несколько абстрактно. А что если юзер хочет точное количество?
Например, на остатке 17 единиц, а юзеру надо 22
Каждый обладатель магазина знает сроки поставок той или иной номенклатуры. У нас, допустим, есть товары с исполнением заказа и 1 неделя, и 2, и 3. Если иметь характеристику - срок поставки, то ее можно будет выводить в случае фактического обнуления на складе.
Таким образом, юзер забирает остаток 17 единиц складского остатка, а на остальные ему выводится срок поставки. И при согласии, добивает заказом на отложенную поставку.
Для нас такой режим работы реален. Так и работаем в действительности. Так-что, не выдумал.
Состояние склада - есть маленько, несколько абстрактно. А что если юзер хочет точное количество?
Например, на остатке 17 единиц, а юзеру надо 22
Каждый обладатель магазина знает сроки поставок той или иной номенклатуры. У нас, допустим, есть товары с исполнением заказа и 1 неделя, и 2, и 3. Если иметь характеристику - срок поставки, то ее можно будет выводить в случае фактического обнуления на складе.
Таким образом, юзер забирает остаток 17 единиц складского остатка, а на остальные ему выводится срок поставки. И при согласии, добивает заказом на отложенную поставку.
Для нас такой режим работы реален. Так и работаем в действительности. Так-что, не выдумал.
Можно сделать обработку 1С и выгружать в след формате:
посмотреть надо сколько полей, желательно файл разделить на несколько частей, если будет огромный.
и после чего я смогу легко сделать модуль импорта остатков в магазин синхронизируясь по полю ID товара
причем забирать буду и обрабатывать все файлы по очереди из папки например /admin/1с
Насчет отображения остатков - можно придумать настройку в основных параметрах: 0-указывать мало много нет, или 1- точное значение склада.
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
ID товара|Кол-во на складе|
посмотреть надо сколько полей, желательно файл разделить на несколько частей, если будет огромный.
и после чего я смогу легко сделать модуль импорта остатков в магазин синхронизируясь по полю ID товара
причем забирать буду и обрабатывать все файлы по очереди из папки например /admin/1с
Насчет отображения остатков - можно придумать настройку в основных параметрах: 0-указывать мало много нет, или 1- точное значение склада.
Наверно да.
Сейчас вопрос актуальности подобного решения стоит только передо мной. Босс пока не видит в данном подходе расширения сбытового сегмента.
Но, я-то точно знаю, сегодня в нашей сфере покупательский контингент существенно обделен подобным вниманием.
На первом этапе, мне будет установлена локальная версия 1С и игрушечной базой, не синхронизированная с рабочей. На ее основе, мне предстоит создать игрушечный, но готовый к реальной работе сайт. По началу, где нибудь в поддомене, не индексируемый.
А уж когда все отлажу и продемонстрирую...
Пока не знаю, что считать огромным. Если рассматривать шаблон - ID, кол-во, цена, цена - файл из нескольких тыс наименований, это килобыйты. А если делать выгрузку по изменениям, даже не по факту внесения изменений, а несколько раз в день, то вообще не о чем.
Десяток-другой строк, это не объем.
Сейчас вопрос актуальности подобного решения стоит только передо мной. Босс пока не видит в данном подходе расширения сбытового сегмента.
Но, я-то точно знаю, сегодня в нашей сфере покупательский контингент существенно обделен подобным вниманием.
На первом этапе, мне будет установлена локальная версия 1С и игрушечной базой, не синхронизированная с рабочей. На ее основе, мне предстоит создать игрушечный, но готовый к реальной работе сайт. По началу, где нибудь в поддомене, не индексируемый.
А уж когда все отлажу и продемонстрирую...
посмотреть надо сколько полей, желательно файл разделить на несколько частей, если будет огромный.
Пока не знаю, что считать огромным. Если рассматривать шаблон - ID, кол-во, цена, цена - файл из нескольких тыс наименований, это килобыйты. А если делать выгрузку по изменениям, даже не по факту внесения изменений, а несколько раз в день, то вообще не о чем.
Десяток-другой строк, это не объем.
Вот я и созрел для еще раз поговорить про это.
Слегка поковырявшись, обнаружил в 1С 8.2 приятную вещицу.
Узел обмена с сайтом. Только засада в том, что он использует специальный протокол, в котором используется основанный на XML стандарт обмена коммерческой информацией CommerceML 2. Для обмена же данными в табличном или текстовом формате, надо допиливать 1с или прикупать модуль. Но и с ним засада
На 1с 8.1 конфигурации 10.3 с которой работает компания, такая штука есть. Босс убедил меня поставить 8.2 с редакцией 11.1 и, упс. Опять вызывай поддержку для их синхронизации.
В общем, кругом одни засады.
Я то наивно думал, что как нибудь исхитрюсь и создам номенклатуру простой выгрузкой. А нифига.
Чё делать хз
Слегка поковырявшись, обнаружил в 1С 8.2 приятную вещицу.
Узел обмена с сайтом. Только засада в том, что он использует специальный протокол, в котором используется основанный на XML стандарт обмена коммерческой информацией CommerceML 2. Для обмена же данными в табличном или текстовом формате, надо допиливать 1с или прикупать модуль. Но и с ним засада
На 1с 8.1 конфигурации 10.3 с которой работает компания, такая штука есть. Босс убедил меня поставить 8.2 с редакцией 11.1 и, упс. Опять вызывай поддержку для их синхронизации.В общем, кругом одни засады.
Я то наивно думал, что как нибудь исхитрюсь и создам номенклатуру простой выгрузкой. А нифига.
Чё делать хз
Вам следует покапаться в различных обработках, их полно всяких на около-1с-ных сайтах.
Работает это так (в 7.7 так было) - в меню кнопка - запуск внешней обработки - выбираете обработку и вперед.
Обработок по экспорту номенклатуры во что угодно , повторяю - полно!
Дайте описание CommerceML или кусок оного, думается это просто XML, который легко можно импортировать в базу. Даже удобнее чем XLS!
Работает это так (в 7.7 так было) - в меню кнопка - запуск внешней обработки - выбираете обработку и вперед.
Обработок по экспорту номенклатуры во что угодно , повторяю - полно!
Дайте описание CommerceML или кусок оного, думается это просто XML, который легко можно импортировать в базу. Даже удобнее чем XLS!
Посмотрел - это обычный XML с 1С-тегами (русифицированными, а як же без этого!) Экспорт на сайт происходит в файловом формате. Вот этот файл и нужен мне.
Там кстати много данных выгружается, и документы и склад и номенклатура и работники и т.п.
Там кстати много данных выгружается, и документы и склад и номенклатура и работники и т.п.
В разных редакциях разные обработки. И в большей части, сводится к тому, что надо давать денежку. Пока вопрос интеграции не решен, то денежка только за мой счет. Не очень готов к этому. А за так пока найти нужное не удалось.
XML выгрузка для обмена данными с сайтом в 1с настраиваемая. В принципе, есть даже вариант создать отдельную базу содержащую только номенклатуру и синхронизировать с основной базой по идентификатору GUID. Это штатная фича. В конфигураторе, при настройке обмена данными с сайтом, выставляются штатные параметры - обмен полным листом номенклатуры или только изменениями; временной цикл.
На сколько я понял, в 1с можно написать xml шаблон выгружаемых данных сопоставимый с товарной карточкой сайта.
Даже если учесть, что база номенклатуры для сайта будет содержать целую кучу ячеек, как в xls, а файл обмена состоять из всех полей, включая сео атрибуты, доп поля описаний и тд., то на стороне движка можно соорудить двоичный шаблон разрешения замены данных в ячейках.
Таким образом, если мы имеем структуру используемых ячеек типа:
то можем в шаблоне проставить разрешения только на те, что подлежат обработке
Согласен, это не уменьшит передаваемый файл. Но, в случае глобальных изменений в базе номенклатур, будь то на стороне 1с или сайта, защитит от не запланированной подмены данных.
А защитой от больших пакетов обмена, будет временной цикл. В любом случае, беспокоиться об этом имеет смысл при трафике из нескольких тысяч хостов в день и сотнях заказов на стороне сайта. А 1-2 десятка заказов в неделю, это не тема. Если рассматривать несколько изменений в день по складским остаткам в паре - тройке сотен позиций, то ftp передача пакетов, на вскидку, в пару мегов 1-2 раза в час, считается ли это большой движухой способной уронить сайт?
XML выгрузка для обмена данными с сайтом в 1с настраиваемая. В принципе, есть даже вариант создать отдельную базу содержащую только номенклатуру и синхронизировать с основной базой по идентификатору GUID. Это штатная фича. В конфигураторе, при настройке обмена данными с сайтом, выставляются штатные параметры - обмен полным листом номенклатуры или только изменениями; временной цикл.
На сколько я понял, в 1с можно написать xml шаблон выгружаемых данных сопоставимый с товарной карточкой сайта.
Даже если учесть, что база номенклатуры для сайта будет содержать целую кучу ячеек, как в xls, а файл обмена состоять из всех полей, включая сео атрибуты, доп поля описаний и тд., то на стороне движка можно соорудить двоичный шаблон разрешения замены данных в ячейках.
Таким образом, если мы имеем структуру используемых ячеек типа:
1|1|1|1|1|1||1|1|1|1|1||||||||||1||||||||||1|1|1|1|1|1|
то можем в шаблоне проставить разрешения только на те, что подлежат обработке
0|0|0|0|1|1||0|0|0|0|0||||||1||||0||||||||||0|0|0|0|0|0|
Согласен, это не уменьшит передаваемый файл. Но, в случае глобальных изменений в базе номенклатур, будь то на стороне 1с или сайта, защитит от не запланированной подмены данных.
А защитой от больших пакетов обмена, будет временной цикл. В любом случае, беспокоиться об этом имеет смысл при трафике из нескольких тысяч хостов в день и сотнях заказов на стороне сайта. А 1-2 десятка заказов в неделю, это не тема. Если рассматривать несколько изменений в день по складским остаткам в паре - тройке сотен позиций, то ftp передача пакетов, на вскидку, в пару мегов 1-2 раза в час, считается ли это большой движухой способной уронить сайт?