Автоматическая синхронизация 1С и Virtuemart - [VM1] Импорт-экспорт данных

Здравствуйте. Подскажите, пожалуйста, как можно автоматически синхронизировать 1С и virtuemart?
Т.е., например, чтоб нажать на кнопку и  информация о товарах в 1С менялась если поменялось на сайте, а
на сайте менялось если поменялось в 1С. Очень нужно! Возможно за деньги. Тогда еще и приблизительную стоимость.

Народ, поделитесь опытом, кто и как решил эту проблему... неужели это так сложно
желательно с подробным описание

Это действительно достаточно сложная штука.

Стоимость решений для синхронизации VM и 1C обычно начинается с 400 у.е.

Это действительно достаточно сложная штука.

Стоимость решений для синхронизации VM и 1C обычно начинается с 400 у.е.

да, знаю что это сложная штука и дорогая.... Я и тут и на ру-мамбо форумах смотрел.... народ обсуждает этот вопрос, это злободневная проблема... но никто не пытается начать общественную разработку такого компонента или бота для Joomla! и модуля для 1С.... мне очень обидно, что я не умею программировать.... Однако!! Я уверен, стоит начать разработку, многие помогут написать, большинство рублем поддержит.... неужели не справимся.... и пускай на это неделя, 2, 3 может месяц потребуется. Однако будет инструмент.... для полноценной работы... Кто поддерживает мою точку зрения, напишите, давайте попробуем....

Думаю, что этот вопрос не к mambo/joomla разработчикам, а к разрабочикам 1С. Я знаю, что в 1 С есть поддержка импортирования/экспортирования в SQL. Как будет происходить обмен данными в 1С с MySQL на практике я не знаю, но уверен, что решение этого вопроса, не прибегаю к усилия со стороны joomla разработчиков, будет доставточно.

Это вопрос и к тем и к другим. Обмен данными происходит на XML, т.к. необходима синхронизация по разделам, товарам, документам и т.д. и т.п.

Вот тут кратенькая статья по поводу интеграции. Сегодня доделал.
http://putnik.net.ua/index.php/comps/web/2006/07/18/virtuemart-1c-integratsiya/

для 1с пишете выгрузку нужных данных в xml
пишете загрузку из xml в mysql

Вот тут кратенькая статья по поводу интеграции. Сегодня доделал.

сегодня доделал статью или интеграцию?
"3.Скрипт на сервере парсит этот файл"  - делиться будешь или как?
"4.Проверяем категории/группы - они есть или нет, можно обновить название/подчиненность при необходимости." - каким образом? при закачке каждый раз запрашивает по каждой позиции обновлять или нет?
"Для эконимии сил и времени, поскольку код у нас числовой, его вполне можно использовать как id в mysql, не полагаясь на автоинкремент. Главное не запутаться " - что тогда с артикулом в вертуе? не нужен? или приравнивать к артикулу 1С?
если артикул "опускаем" (то есть они в оф и он базах разные) то в этом случае как будет производиться отборка товара кладовщиком? вряд ли он отбирает по коду т.к. его просто нет на товаре, чисто по названию тоже не 100%, в нормальном складе его вообще отбирают по персональному месту хранения (идентификатор местонахождения товара)- "слот", код которого привязан к товару в базе 1С. вобщем этот процес мне не совсем ясен, если можно поподробнее, т.к. заказ из вертуя должен нести всю полноту инфы по идентификации товара
правда можно и так: заказ по id коду закачивается в 1С а там уже выводиться складская (отборочная) накладная у кого как заведено по техпроцессу

"Кратко это выглядит так:" - а подробнее будет?

Да, если напрямуюу в mysql до тействительно вопрос вкуса, через ксв или хмл.

сегодня доделал статью или интеграцию?

)) сегодня - статью, интеграцию дня 4 назад

"3.Скрипт на сервере парсит этот файл"  - делиться будешь или как?

Честно говоря, после того как тут говорили про "от 400 уе" - готовое решение давать не хочется. Если будут трудности, закавыки - отвечу что знаю без проблем. Пишете скрипт на любом известном Вам языке, умеющем общаться с мускулем.

"4.Проверяем категории/группы - они есть или нет, можно обновить название/подчиненность при необходимости." - каким образом? при закачке каждый раз запрашивает по каждой позиции обновлять или нет?

Да. можно запоминать для этого сеанса импорта, конечно, но стоит ли? Это имеет смысл, только если база очень большая. На паре тысяч позиций обновление (не добавление) прошло за минуту (селерон 2,4, перл, винда, коннект к мускулю по сети).

"Для эконимии сил и времени, поскольку код у нас числовой, его вполне можно использовать как id в mysql, не полагаясь на автоинкремент. Главное не запутаться " - что тогда с артикулом в вертуе? не нужен? или приравнивать к артикулу 1С?

приравнивать к коду/артикулу 1С по вкусу. насколько я разобрался, он там нужен очень, и единственное, почему вместо него не используется ид - возможность использования не только цифр.

если артикул "опускаем" (то есть они в оф и он базах разные) то в этом случае как будет производиться отборка товара кладовщиком? вряд ли он отбирает по коду т.к. его просто нет на товаре, чисто по названию тоже не 100%, в нормальном складе его вообще отбирают по персональному месту хранения (идентификатор местонахождения товара)- "слот", код которого привязан к товару в базе 1С. вобщем этот процес мне не совсем ясен, если можно поподробнее, т.к. заказ из вертуя должен нести всю полноту инфы по идентификации товара

у нас по коду, так что вопрос не стоит.Но как вариант - вполне можно, вирт афаик может вывести в заказ для склада/менеджера что угодно, втч доп поля. Там запросто хранить слот, и обновлять его из 1с, если надо.

правда можно и так: заказ по id коду закачивается в 1С а там уже выводиться складская (отборочная) накладная у кого как заведено по техпроцессу

обратно в 1С не занимался, хотя тоже решение, правда затрудняюсь сказать насколько трудоемкое.

"Кратко это выглядит так:" - а подробнее будет?

См выше

сенкс за разъяснение
кста 400 уе это несолько другой порядок интеграции, ни как не меньше чем онлайн в реалититайм, иначе вообще смысла нет, проще купить тогда настоящий инет маг а не стол заказов а ля виртуя и лепить к нему приблуды, это не к тому что "готовое решение давать не хочется" - хозяин барин
а вообще насчет проблемы

сенкс за разъяснение

немазашо

Оффтоп:

кста 400 уе это несолько другой порядок интеграции, ни как не меньше чем онлайн в реалититайм,

имхо онлайн реалтайм уже под штуку будет, и его надо расчитывать минимум под 10-100 заказов в минуту. Хотя смотря где, можбыть У нас (Киев) поробегала 1сная вакансия на 1килобакс
зы:  выгрузка из 1с у меня получилась 80 строк, загрузка в мускуль - 270 с комментами, дебагами и не шибко оптимизировано, наверное. Это я к тому, что "дорогу осилит идущий".

а вообще насчет проблемы

ы? не дошло...

ы? не дошло...

"это не к тому что "готовое решение давать не хочется" - хозяин барин, а вообще насчет проблемы"
продолжение предложения сорри

вопрос онлайн не зависит от кол-ва заказов в секунду, а относится к разряду управленчискому, логистическому и т.д.
исходное состояние организации склада:
один склад на весь товар
в разрезе инет мага это уже не катит если нет реалтайм, т.к. в нормальном маге ты должен отвечать за наличие товара, вариант есть/нет уже не катит: 
"7.под-товар: из 1С обновляется родитель, кол-во на складе (у нас - фиктивное, просто признак есть/нет), название, сертификат, цена, производитель, на всяк случ. "
чел зашел купить 100 шт товара Х и он должен видеть реальные остатки

в режиме стол-заказа (без реалтайм) на складе придется создавать вертуальное место хранение "инетмаг" и на него подвешивать товар для обеспечения ответственности перед клиентом
это создает дополнительный гемор манагерам по логистике, нужно отслеживать и расчитывать минимально оправданные товарные "остатки" по этому месту хранения и т.д. - короче эта тема уже выходит за пределы приблуды обмена между 1С и вертуя

Мужики! Вам огромный респект! Как время будет засядут, разбираться буду!
МОЛОДЦЫ!

короче эта тема уже выходит за пределы приблуды обмена между 1С и вертуя

Согласен, прекращаем оффтопить

Кстати, оч хорошая идея с одбц, если б я получше знал 1с, так бы сразу и писал.
у нас обмен с срм планируется именно так, но там мс скл.
хотя, по логике, разница небольшая... 

в разрезе инет мага это уже не катит если нет реалтайм, т.к. в нормальном маге ты должен отвечать за наличие товара, вариант есть/нет уже не катит: 
"7.под-товар: из 1С обновляется родитель, кол-во на складе (у нас - фиктивное, просто признак есть/нет), название, сертификат, цена, производитель, на всяк случ. "
чел зашел купить 100 шт товара Х и он должен видеть реальные остатки

переноси реальные остатки в jos_vm_product есть и поле product_in_stock
и остатки будут актоальные на момент выгрузки

переноси реальные остатки в jos_vm_product есть и поле product_in_stock
и остатки будут актоальные на момент выгрузки

по моему ты не доконца понимаешь о чем речь - пока ты будешь выгружать остатки, у тебя со склада уже могут половину выписать в торговом зале фирмы

по моему ты не доконца понимаешь о чем речь - пока ты будешь выгружать остатки, у тебя со склада уже могут половину выписать в торговом зале фирмы

согласен. Для меня реалтайм - это если эти остатки (и все остальное) будут отставать в разных точках не более 5 секунд.
а может и вообще 0.

в реальной торговой базе это вообще невозможно - в момент выписки товара (в момент нажатия на ввод) он блокируется и другой оператор его выписать не может, одновременного нажатия добиться очень сложно - поэтому "тормоза" не заметно и даже если это вдруг произойдет - задержка доли секунды обычно.
в момент набора кол-ва товара в операции выписки, товар вычитается с места хранения сразу, второй оператор уже видит остатки этого товара уже за минусом кол-ва введенного первым оператором, но это кол-во сидит во временном файле и все еще числиться за местом хранения и только когда дана команда записать документ, он списывается с места хранения, если же запись отменить, товар вернется на свое место хранения

гайз, извините, что встряваю в ваш умный разговор
у меня просьба - если отвечаете на предыдущий пост, то нету смысла цитировать полностью.
только если цитата текста частична
договорились?

в момент набора кол-ва товара в операции выписки, товар вычитается с места хранения сразу, второй оператор уже видит остатки этого товара уже за минусом кол-ва введенного первым оператором, но это кол-во сидит во временном файле и все еще числиться за местом хранения и только когда дана команда записать документ, он списывается с места хранения, если же запись отменить, товар вернется на свое место хранения

В 1С организация резервирования другая. Товар попадает в резер только при проведении счета (ни при его создании, ни при сохранении с товарами ничего не происходит). Так что при выписке счета (аналогом чему и является набор товаров в корзину) вполне реальна ситуация с задержкой отслеживания ситуации с товарными остатками. Посетитель сайта узнает все ли есть в наличии только на стадии оформления заказа.

Резервировать же товар "на лету" (т.е. каждый раз, когда он попадает в корзину) по понятным причинам (ресурсоемкость, задержки в обработке и т.п.) нецелесообразно. Плюс, не надо забывать о "заклятых друзьях" - конкурентах, которым вдруг захочется выписать счет на сотню холодильников...

Так что мне видится более реальным - наличие более-менее актуальной информации о количестве товаров на складе и ее подтверждении и резервировании товара в момент оформления заказа.

А есть еще и режим "витрины", в котором, мне кажется, работают 90% интернет-магазинов, когда синхронизации подлежат вообще только товары, заказы и клиенты.

Александр Фёдоров, конечно ты прав "Товар попадает в резер только при проведении счета " потому как 1С стандартно все и настраивают через "заказ" а не через скажем так "продажа"

"не надо забывать о "заклятых друзьях" - конкурентах, которым вдруг захочется выписать счет на сотню холодильников" - и это верно, но если использовать "вертуальное место хранения" и манагер спать не будет, то это фигня

"А есть еще и режим "витрины", в котором, мне кажется, работают 90% интернет-магазинов" - и  тут ты тоже на 90% прав, только это уже не "интернет-магазины" а именно витрины или столы заказов.
"интернет-магазины" по "западной классификации" -  это то, что работает с реальными остатками в реальном времени (базы он и оф лайн синхронизированы по всем необходимым параметрам) - к сожалению нам это пока не светит - цена таких пакетов о-ля-ля....

"А есть еще и режим "витрины", в котором, мне кажется, работают 90% интернет-магазинов" - и  тут ты тоже на 90% прав, только это уже не "интернет-магазины" а именно витрины или столы заказов.
"интернет-магазины" по "западной классификации" -  это то, что работает с реальными остатками в реальном времени (базы он и оф лайн синхронизированы по всем необходимым параметрам) - к сожалению нам это пока не светит - цена таких пакетов о-ля-ля....

Степень онлайновости магазина зависит больше даже не от навороченности системы, а от организованности процессов на предприятии...
Нашим же ИМам еще расти и расти до нужной самоорганизации...

И получается, что чаще всего синхронизация ограничивается именно дискретным импортом-экспортом данных о товарах и заказах.

Но даже при подобном упрощении задачи цены на подобные решения все равно не будут низкими... Эти скрипты предназначены для зарабатывания денег, значит оприори стоят дороже, чем "некоммерческие" разработки.

ну это понятно
все что должно приносить мани и само будет стоит не малые мани
будем "воровать" - а что делать?

по моему ты не доконца понимаешь о чем речь - пока ты будешь выгружать остатки, у тебя со склада уже могут половину выписать в торговом зале фирмы

А что ты хочешь? Остатки в реалтайме?
Тогда тебе не сюда, а к какомнибудь 1C Web расширение или специализирование решение.
Синхронизировать каждые 5 сек, запуская в 1С обрабоку номенклатуры в 5тыс наименований, глупость, да и будет тормозит 1С

А что ты хочешь?

я, ничего
просто попытался объяснить  разницу между магазином и столом заказов

можно сделать так. сделать в 1С обработку которая через одбс драйвер конектится к базе мускула и работает напрямую с ней с помощью sql запросов. в 1С уже вести все операции по добавлению удалению изменению и т.д товара.

Сделал риалтайм интеграцию 1С с Mysql через компоненту v7msql.dll - да вот незадача: хостер наотрез отказался от внешних коннектов к Mysql серверу. Так что пришлось все под XML переписывать  . Совет: сначала узнайте  у хостера  поддерживает ли он прямые коннекты к серваку.


Желаю удачи!!!

Я думаю, когда идёт разговор о таких вещах, проще взять VPS и делать там всё, что угодно...