| |||||||||
| |||||||||
05.06.2013 12:54
Назревает вопрос актуализации решения интеграции 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С происходит списание с остатка, изменение цены, поступление на остаток, автоматом формируется отчет и отсылается на сервер. В этом случае отчет не по всей базе создается, а по измененным позициям. И пакет для отправки состоит только из измененных таблиц. А это всего лишь несколько байт. На худой конец, несколько килобайт.
Подозреваю, мастер читая это, сидит и произносит, что-то типа - моп ту еть!
Однако прогресс! Он ведь на месте не стоит, за ним вообще хрен угонишься. Но пытаться-то надо...блин!
Вот сейчас и думаем, как быть-то?
Шибко уж интеграшку хочется, да не совковую.