Склонен считать, что таки да.
Была такая проблема. 2-я команда 1С-ников завершала проект. 1-я на очередном этапе сошла с дистанции - "чёт не знаем как это сделать:(". В итоге, да год. Но, если сразу 2-ю команду 1С-ников (тех кто реально может) и улучшить понимание при согласовании, то 3-4 мес. вполне достаточно, даже на достаточно сложную синхронизацию.
Круто. Как по сумме, так и по срокам. А это точно,
Если правильно вас понял, то:
REPLACE [LOW_PRIORITY | DELAYED] [INTO] tbl_name [(col_name,...)] VALUES (expression,...),(...),...
Но, про мне, так лучше или UPDATE, или INSERT ....... ON DUPLICATE KEY
С одной стороны все просто, на запрос 1С ?type=sale&mode=query отдать что то похожее на
<Документ> <Ид>{%doc_id%}</Ид> <Номер>{%doc_id%}</Номер> <Дата>{%timestamp%}</Дата> <ХозОперация>Заказ товара</ХозОперация> <Роль>Продавец</Роль> <ИдМенеджера>{%manager_id%}</ИдМенеджера> <Валюта>руб</Валюта> <Курс>1</Курс> <Сумма>{%itogo%}</Сумма> <Контрагенты> <Контрагент> <Ид>{%user_id_in_site%}</Ид> <Наименование>{%user_name%}</Наименование> <Роль>Покупатель</Роль> <ПолноеНаименование>{%full_user_name%}</ПолноеНаименование> <Фамилия>{%person%}</Фамилия> <АдресРегистрации> <Представление>{%adres%}</Представление> </АдресРегистрации> <Контакты> <Контакт> <Тип>ТелефонРабочий</Тип> <Значение>{%tel%}</Значение> </Контакт> <Контакт> <Тип>Почта</Тип> <Значение>{%email%}</Значение> </Контакт> </Контакты> </Контрагент> </Контрагенты> <Время>{%time%}</Время> <Комментарий /> <Товары> {%order_list%} </Товары> </Документ> где order_list = array сформированный по шаблону: <Товар> <ИдКонтрагента>{%user_id_in_site%}</ИдКонтрагента> <Ид>{%id1c%}</Ид> <Наименование>{%item_name%}</Наименование> <БазоваяЕдиница>{%item_ed%}</БазоваяЕдиница> <ЦенаЗаЕдиницу>{%item_price%}</ЦенаЗаЕдиницу> <ЦенаПоАкции>{%item_action_price%}</ЦенаПоАкции> <Количество>{%item_cnt%}</Количество> <Сумма>{%item_summ%}</Сумма> </Товар>
По минимуму, чтобы заработало - надо:
1) иметь 1С Ид товара в базе сайта, что то типа 8f38f64e-61b8-4002-9188-95760711146b (на стороне сайта), или на стороне 1С сделать связь ИдТовараНаСайте с Ид1С
2) сделать что то с контрагентами (на стороне 1С), т.к. покупатель, чаще всего, изначально появляется на сайте и 1С про него ничего не знает. При получении нового {%user_id_in_site%} 1С его регистрирует, заводит соотв. поле {%user_id_in_site%} и при следующих покупках этого покупателя, оперирует с этим {%user_id_in_site%}, если реквизиты поменялись, то меняет их у себя в базе.
Это несложно. Нужны: 1С программист - 1шт, php программист - 1шт, x-минут/часов работы, x^3+++ часов согласований м/у заказчиком, 1С прог и php прог😂
Но, дьявол в деталях. Намерено в примере показаны некоторые вещи (ИдМенеджера, ЦенаПоАкции и т.д.) , которых нет нигде в базовой выгрузке. У всех все по разному☝ Поэтому, все может быть сильно сложней.
Это сработает (Если права есть).
А на это
Ругнется, что ХТТП обертка не поддерживает коннект который что то хочет записать
Поэтому, вам и говорят приведите
/ru/forum/development/web к https_searchengines.guru_forumdisplay.php_f_48
А предупреждали продавцы чайников 😂 И вот получите, нет публичных авторитетов в теме :(
Тем не менее, думаю лучше не уподобляться.
Во многих темах серча люди со своими тараканами и часто срач начинается от непонимания что сказал оппонент. Так же часто, особенно в темах о разработке, люди почему то считают что их вариант единственно верный. На мой взгляд, который основан на почти 20 летнем опыте php, mysql, js, css, sqlite и прочей ерунде - это ошибочно, каждую задачу можно решить уймой способов. Поэтому от однозначных толкований, типа файлы плохо, бд хорошо или наоборот лучше воздержаться. Каждый инструмент хорош по своему.
Заказать программисту.
Или самостоятельно 🍿
$inputFileType = \PHPExcel_IOFactory::identify($inputFile); $objReader = \PHPExcel_IOFactory::createReader($inputFileType); $objReader->setReadDataOnly(false); $this->sheet = $objReader->load($inputFile); .... $sheetNames = $this->sheet->getSheetNames(); foreach($sheetNames as $k=>$v) { ...... }
Ps : больше подходит для веб строительства или интернет магазинов
Все давно прочитано, но это фигня. Еще и 100500 раз испробовано. Каждый день, по много раз.
Детский вопрос знатоку, где будет тормоз? Ответ нужен для базы 5МБ и 30МБ+. Задача удалить таблицу, создать заново с новой структурой и залить в нее каких то данных. $sqlite->t - надстройка над ПДО 1-параметр SQL-запрос, 2-й (если есть) - массив данных для загрузки. В зависимости от типа запроса (INSERT, UPDATE и т.д.), комбинации параметров и структуры массива выполняет self - или просто exec или query, или prepare + execute. Когда нужно ([':id'=>1] или [0=>[':id'=>1]]) включаются транзакции (self::$I->exec('BEGIN IMMEDIATE;')).
$sql['drop_sql'] = 'DROP TABLE IF EXISTS `tbl`;'; $sql['vacuum'] = 'VACUUM;'; $sql['create_sql'] = 'CREATE TABLE `tbl` ( `id` VARCHAR (32) PRIMARY KEY NOT NULL , `model` VARCHAR (11) , `A` VARCHAR (11) , `B` REAL , `C` VARCHAR (5) , `D` TEXT , `vendor` VARCHAR (5) ) ; '; foreach($sql as $s) { $sqlite->t($s); } ------------ $a в след запросе это Array ( [0] => Array ( [:id] => cafe1cd338c7ecb5e378f91c9b17c4b0 [:model] => iPhone 6 [:A] => 4,7″, IPS, 1334×750, 326 ppi [:B] => Apple A8 @1,4 ГГц (2 ядра, 64-битная архитектура ARMv8-A) [:C] => PowerVR GX6650 [:D] => 16/64/128 ГБ [:vendor] => Apple ) ...... еще 5 записей или 100500 не суть ) ------------ $sqlite->t('INSERT INTO `tbl` (`id` , `model` , `A`, `B` , `C` , `D` , `vendor`) VALUES ( :id , :model , :A , :B , :C , :D , :vendor) ; ', $a); $sqlite->t( 'CREATE INDEX `tbl_model` ON `tbl` ( `model` , `vendor` );' , null );
Это в пику - Redis, Sphinx и предварительная индексация - не к месту они в рамках этой темы.
Не мне, но прокомментирую. Усугубляете. Не лучший вариант. Уважать надо собеседников:)
Я знаю что такое stripslashes. Пример ровно для того, чтобы показать, что имеет смысл нормализовать данные перед использованием. Не более. Иллюстрирует идею. Чтобы приложение работало, насколько возможно, корректно в т.ч. и на PHP < 5.4----
Также, не буду скрывать, пример приведен в основном в ответ на это:
Обрабатывать POST и GET т.е. их менять это вообще неправильно.
И, кстати, $this->stripSlashes не обязательно должна быть stripcslashes;)
Я такой подход юзаю, правда не для стрипслэшес, а для проверки и (или) санитарной обработки сегментов урла, _постов, _гетов и прочих _кук, как значений, так и ключей. Нормально все работает.
Могли быть сгенерированы с документа /klasnoe-avto/ из за варнинга типа - Warning: mysql_get_server_info() [function.mysql-get-server-info] , который в сущности предупреждает об ошибке и рекомендует посмотреть детали на http://php.net/manual/ru/function.mysql-get-server-info.php, но из за особенностей CMS (на Joomla попадалась похожее)
ссылка ведет на относительный адрес.
