так я потому и спросил про событие чтобы на него повесить пересчет заказа
Если использовать событие создания/обновления элемента никуда заходить и пересохранять не нужно, тот же самый импорт за вас все сделает, просто после создания/обновления взять из свойства и проставить в параметры. До текущего момента это так и делалось на проектах. Но минус этого
|
|||||
|
|
|
|
|||
|
|
|
|
|||
|
|
|
|
Всем привет.
Натолкнулся на такую проблему: мне нужно создать файл если дескрипшн детальной картинки равен определенному значению. делаю getlist, в котором получаю массив по картинкам, так вот стоит вызвать CFile::GetFileArray и при создании файла получаю failed to open stream: Too many open files лимит на сервере увеличен в 10 раз до 10240, но это не помогает |
|
|
|
|
|
у вас написано Too few arguments to function CTszhPayment::FormatCurrency()
т.е. на старом php у вас вывод предупреждений не был включен, и многие вещи вы не видели, а разработчики игнорировали, работает и ладненько. С переходом на версию повыше это уже стало ошибкой. решением будет либо найти разработчиков которые согласятся вам исправить эти моменты(раз вы к сайтостроению отношение имеете далекое), либо откатиться к старой версии php еще можно написать разработчикам модуля citrus.tszhpayment, который и вызвал ошибку. |
|||
|
|
|
|
У кого-нибудь было такое? клиент делает заказ, заказ уходит в 1С, но к примеру этого товара уже нет, его списал магазин себе. клиент соглашается на замену. Меняем состав в 1С приходит об этом информация на сайт, а в ответ фиг вам, состав на сайте не меняется, но дата изменения просталяется и обмен падает с ошибкой. при следующем запросе так как дата заказа сменилась, то старый состав улетает в 1С и изменяет уже новый и так по кругу.
что я сделал - создал статус на который можно перевести такой заказ и он не будет уходить в 1С. Отчасти это помогло, но в самой 1С стаусы же меняются у заказа и они идут на сайт, и опять проблема из-за такого заказа обмен падает с ошибкой и не все заказы обновляются. А раз завершения не было, то эти заказы раз за разом выгружаются и выгружаются. пока проблемный заказ не выкинешь из обмена. Но ему опять сменили статус к примеру в пункте выдачи, и все по новому кругу. может кто подскажет что можно придумать |
|
|
|
|
|
в списке заказов можно использовать фильтр "Купон, использованный в заказе"
так вы получите все заказы с этим купоном Других вариантов с информацией по купону, насколько я знаю, нет. Все остальное нужно самому писать выборки.
|
|||
|
|
|
|
Пользовательских полей у инфоблоков не существует, только у разделов и элементов. Инфоблок это по сути просто оболочка с минимальными настройками для группы элементов. Так же как тип инфоблока это только группировка инфоблоков не имеющая ничего, просто для удобства отображения в админке.
|
|
|
|
|
|
в php5 не было жесткой проверки с чем вы работатете с массивом или строкой, в 7 версии есть
объявите сначала переменную, затем присвойте ей значение
а про подробности вас спрашивают что этим вы хотите получить, зачем вам это условие вообще, если у вас и так это значение отсутсвует |
|||
|
|
|
|
Есть ситуация: выгружается каталог товаров, когда их меньше ~400, то торговых предложений тоже не так много ~2000 файлы приходят и обрабатываются без проблем. Но как только товаров переваливает за 400-500, тут начинается проблема - файл импорта обрабатывается нормально, а файл оферса (свыше 3000 ТП) нет, в логах сервера нет даже запроса на импорт оферсов. По логам обмена 1С же получаем что при обращении мы имеем 502 ошибку. Я закинул bx_1c_import_lite на сайт и запустил обработку оферсов. Да долго(~30 минут), но все отрабатывает без ошибок. Запрос идет на дефолтную /bitrix/admin/1c_exchange.php что от 1С, что от скрипта.
Кто-то может что-то подсказать как победить проблему? Просто во время проведения акций, распродаж это выливается в большую проблему, наличие сети офлайн-магазинов в этом случае за 15 минут(переодичность обмена, меньше нельзя устанавливать, так как после обмена еще и обработчики сайта должны все отработать) на обмен до 1000+ товаров могут зарегистрировать. |
|
|
|
|
|
Вот так точно сказать, не думаю что кто-то сможет.
Я предполагаю тут скорее всего один из двух вариантов: либо есть еще один компонент, который должен что-то выводить в карточке товара, но не выводит из-за отсутствия данных или настроек и возвращает поэтому статус 404 когда не выводит; либо в коде компонента есть какое-то условие, которое и возвращает такой статус из-за того что где-то что-то не заполнено у элемента. |
|
|
|
|