Order save bitrix не работает

Работа с заказом в Битрикс D7

Начиная с 16 версии используется новая версия ядра магазина Битрикс, являющаяся частью ядра Битрикс D7. Многое описанное здесь может работать и в переходной версии 15.5. Все классы для работы с магазином собраны в модуле sale, поэтому для работы примером используем use для пространства модуля интернет-магазина.

Заказ (Sale\Order)

Заказ представляет собой объект класса Bitrix\Sale\Order. Нужно запомнить, что пока не вызван метод save() этот объект необязательно связан с сохранённым заказом. Также пока вы не вызовете save(), изменения в заказе не будут сохранены в базе данных.

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

Поля заказа можно получить короткими вызовами:

Также любое поле по имени можно получить так:

Список доступных полей можно получить, вызвав $order->getAvailableFields().

Заказ имеет связь один-ко-многим с несколькими объектами в виде коллекций — коллекция товаров в корзине (Sale\Basket), коллекция отгрузок (Sale\ShipmentCollection), коллекция оплат (Sale\PaymentCollection) и коллекция свойств заказа (Sale\PropertyValueCollection).

Самый простой способ получить список способов доставки и оплаты — короткие вызовы:

Чтобы получить список примененных к заказу скидок, нужно вызвать:

В массиве $discountData[‘DISCOUNT_LIST’] содержится список скидок, в $discountData[‘COUPON_LIST’] содержится список купонов. Т.к. скидки можно отключать в админке, следует проверять поле APPLY: если Y — скидка/купон применёны, если N — были отключены менеджером.

Корзина заказа (Sale\Basket)

Про работу с корзиной была отдельная статья, привязать и получить корзину заказа можно так:

Свойства заказа (Sale\PropertyValueCollection)

Свойства заказа — объекты Bitrix\Sale\PropertyValue — собраны в коллекции propertyCollection

Получить значения всех свойств и группы свойств можно так:

У многих свойств заказа есть определенное встроенное назначение (атрибуты IS_EMAIL, IS_PAYER, IS_LOCATION, IS_LOCATION4TAX, IS_PROFILE_NAME, IS_ZIP, IS_PHONE, IS_ADDRESS). Такие свойства можно получить следующими методами:

Получить значение свойства по ID:

В любом случае получаем значение свойства — экземпляр класса Bitrix\Sale\PropertyValue. Из него мы можем получить значение свойства:

И информацию о самом свойстве:

Чтобы изменить значение свойства следует вызвать метод setValue и сохранить сущность

Оплаты заказа (Sale\PaymentCollection)

Из коллекции оплат также можно получить информацию об оплате, что и из объекта заказа. Оплата с внутреннего счета также считается одной из оплат:

Коллекция содержит объекты оплаты Sale\Payment с информацией об оплатах:

Оплатить или вернуть оплату можно методами setPaid(), setReturn():

Инициировать оплату (вывести шаблон оплаты: форму, кнопку и т.п.) можно следующим образом:

Пример оформления заказа в D7

Для примера приведу простейший код оформления заказа с комментариями

Источник

Работа с заказами в битрикс D7

Для реализации возможностей интернет-магазина в системе битрикс используется модуль sale. С помощью данного модуля становятся доступными возможности работы с корзиной, оформления заказов, работа с покупателями, а также другой необходимый функционал. Для бизнеса, в большинстве случаев, стандартных компонентов оформления заказов иногда бывает достаточно. Однако это не исключает возможность реализации своего функционала для работы с заказами на уровне API. В данном посту мы рассмотрим простые примеры использования API битрикса ядра D7.

Перед использованием API для работы с заказами следует подключить модуль «sale»:

Получение полей заказа

Зная ID заказа, мы можем получить поля заказа, а также внести какие-либо изменения в них.

Используя ID заказа мы инициализировали объект заказа, посредством метода load(), и присвоили переменной $order. Для получения полей заказа, мы выполнили метод getFields(). После этого нам становятся доступны поля для работы с ними. Так в примере через метод getField() мы получили значение DELIVERY_ID. Передавая таким образом символьный код этому методу мы можем получать значение этих полей в заказе. Далее используя метод setField() мы присвоили полю PAYED значение «N». Чтобы изменения записались в системе, следует так же выполнить метод save(). Использовать этот метод нужно лишь в том случае, когда мы вносим изменения в текущий заказ, и вызывается он в последнюю очередь. Таблица с описанием полей заказа опубликована в конце статьи.

Получать значение некоторых полей можно посредством специальных методов, которые так же удобно использовать в коде:

Создание заказа в битрикс D7

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

Аналогично как и в предыдущем примере все изменения заказа сохраняются посредством метода save(). В примере выше добавляется только один товар, однако на практике можно добавлять их целое множество, посредством массива $arItems.

Обновление заказа в битрикс D7

В самом первом примере мы уже рассматривали возможность обновления полей заказа. Там, посредством использования метода setField() мы задавали значения поля заказа. При работе с заказом так же бывает требуется обновить другие данные заказа, которые обновляются немного иначе. Допустим нам требуется разрешить отгрузку заказа, для этого мы может выполнить такую операцию:

В данном примере мы добавили к заказу комментарий от покупателя — поле USER_DESCRIPTION, а также разрешили отгрузку товаров. По умолчанию для каждого заказа существует системная отгрузка, она создаётся при создании заказа. В цикле так прописано условие, которое исключает системную отгрузку, которую затрагивать нет необходимости.

Поля заказа в битрикс D7

*Стоит обратить внимание на то, что поля актуальны на момент написания данной статьи.

Источник

Битрикс — Как при сохранении заказа обновить поле пользователя

Для решения данной задачи будем использовать обработчик события и метод из API.
Разделим задачу на 2 шага.

Событие сохранения заказа в битриксе

Данное событие вызывается при обновлении заказа. Записываем его в init.php:

В данной функции вылавливаем переданные параметры:

Как видно из примера, мы ищем заполненность свойств заказа, и только в случае если они есть — записываем значение в переменную. С первой частью думаю вы разобрались, ключевой момент, это именно создать обработчик событий и убедится что он корректно работает.

Как перезаписать поля у пользователя при сохранении заказа в Битриксе

Сначала рассмотрим уже готовый код, а потом дам комментарии о том что появилось:

Из нашего обработчика события мы можем получить 3 параметра: $orderID, $fields, $orderFields.
$orderFields — мы уже использовали, там хранятся передаваемые свойства заказа.
$fields[‘USER_ID’] — хранит в себе запись ID пользователя, на которого и был оформлен заказ. По этому ID, мы записываем два пользовательских свойства: UF_VED и UF_ORDER_ID.
$orderID — (первый параметр из обработчика) как раз и поможет нам с UF_ORDER_ID.

Для каких ситуация может пригодится такой код? Предположим, после обработки заказа менеджером, в нём будет изменено какое-то свойство. И, в данном конкретном случае, нам не нужно привязываться к статусу заказа (хотя могли и так). А смотрим именно на наличие одного из свойств, и если оно есть — сохраняем в профиль пользователя.

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

автор: Dmitriy

Занимаюсь веб-разработкой с 2011 года. Посмотреть некоторые из моих работ, а также узнать чуть больше обо мне, вы можете на forwww.ru.

— Создание сайтов на 1С-Битрикс любой сложности
— Вёрстка макетов Figma, Photoshop, Zeplin
— Поддержка проектов на Битриксе
— Разработка нового функционала для сайта
— Парсинг данных
— Выгрузка из файлов в формате XML, YML, XLS, XLSX, CSV, JSON
— Интеграция по API со сторонними сервисами
и многое другое

Источник

Оплаты и отгрузки

Роман Павленко,не могли бы показать пример кода, который бы запрещал удаление документов оплаты и доставки?

Пробовал два варианта (один закомментирован) добавления ошибки:

Иван Турченко, вы почти всё делаете правильно.
Только результат надо добавлять в параметр события.

Цитата
Роман Павленко написал: Иван Турченко , вы почти всё делаете правильно. Только результат надо добавлять в параметр события.

Цитата
Иван Турченко написал: Нашёл как решить проблему, закомментировав пару строк в ядре в классе обмена документами, но хотелось бы решить задачу, не влезая в ядро.

Цитата
Иван Турченко написал: Нашёл как решить проблему, закомментировав пару строк в ядре в классе обмена документами, но хотелось бы решить задачу, не влезая в ядро.

А в каком файле/части файла это нужно сделать? И что закомментировать?

Файл /bitrix/modules/sale/lib/exchange/importonecpackage.php
Метод — http://joxi.ru/E2p0ZyiBdoB92Y

Это на случай если удаляются и отгрузки, и оплаты.

Цитата
Иван Турченко написал: Это на случай если удаляются и отгрузки, и оплаты.

Цитата
Отгружен

Номер оплаты по 1С

Дата оплаты по 1С

Номер отгрузки по 1С

Дата отгрузки по 1С

Статуса заказа ИД

Метод доставки ИД

Далее в xml идет документ оплаты данного заказа, а документ реализации(отгрузки) отсутствует в выгрузке. Хотя отмечен в изменениях.

В настройка стоит:
— Не редактировать докаменты
— Выгружать оплаты (галочка по загрузке снята)
— Выгружать отгрузки (галочка по загрузке снята)

На сайт отгрузка не приезжает.
Собственно вопрос, должен формироваться документ реализации в xml?
Если да, подскажите какую галку ткнуть и или вариант самого xml по реализации

Цитата
Дмитрий Агапкин написал: По сути при закрытии заказа, когда ставишь выбранную причину должно влиять на отмену заказа, но что бы ты не ставил всё равно отмена.Самое не маловажное это документ закрытия заказа Это не отмена заказа! Он может быть отменой конечно.

Поддерживаю, тоже столкнулись.

При импорте файла из 1с обмен возвращает «У заказа есть активные оплаты» когда заказ был закрыт в 1с.
Оказалось что битрикс пытается отменить данный заказ, но не может.

Но по логике в 1с закрытие заказа не обязательно означает отмену. Возможен случай полностью отработанного заказа с причиной закрытия «Выполнен» тогда документ закрытия не должен отменять заказ на сайте.

И тоже уже столкнулся с новым классами и особенностями нового обмена. То что обмен перешел в папку lib и теперь на ООП это классно. Но есть и недоработки на мой взгляд.

Как многие уже пишут выше при обмене доставка теперь создается из 1с даже если она уже была в битриксе.
Столкнулся с тем что наименование доставки после обмена с 1с на сайте менялось с Курьером (Доставка курьером) на Доставка курьером и 1с при последующем обмене писала — Подстановка данных не возможна. Не найдены данные.

Причина в том что при создании заказа в компоненте или через админку название доставки формируется из профиля, а в классе shipmentimport.php просто берется название доставки а не профиля.

Чтобы поправить в системном классе /bitrix/modules/sale/lib/exchange/entity/shipmentimport.php в методе add

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

Источник

Сохранение заказа: особые события

В системе заказов имеется набор особых событий, которые являются событиями с отложенной инициацией, т.е. они инициируются в жизненном цикле заказа, но вызываются при сохранении.

Событие	Описание и параметры
OnSaleOrderCanceled	Вызывается при сохранении, если был изменен флаг отмены. Параметры ENTITY Объект заказа.
OnSaleStatusOrderChange	Вызывается при сохранении, если статус заказа был изменен. Параметры ENTITY Объект заказа.
OnSaleOrderPaid	Вызывается при сохранении, если оплаченность заказа была изменена. Параметры ENTITY Объект заказа.
OnShipmentTrackingNumberChange	Вызывается при сохранении, если был изменен идентификатор отправления. Параметры ENTITY Объект отгрузки.
OnShipmentAllowDelivery	Вызывается при сохранении, если был изменен флаг разрешения отгрузки. Параметры ENTITY Объект отгрузки.
OnShipmentDeducted	Вызывается при сохранении, если был изменен флаг отгрузки. Параметры ENTITY Объект отгрузки.
OnSaleBeforeOrderDelete	Вызывается перед удалением заказа. Параметры ENTITY Объект заказа.

Пользовательские комментарии

Мы будем рады, если разработчики добавят свои комментарии по практическому использованию методов системы.

Для этого нужно всего лишь авторизоваться на сайте

Но помните, что Пользовательские комментарии, несмотря на модерацию, не являются официальной документацией. Ответственность за их использование несет сам пользователь.

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

Цитата
romansergeevitch пишет: [CODE] isPaid() or $order ->isPaid()== false ) return ; // Обрабатываем только оплаченные заказы

//Тут происходит какая то логика для оплаченного заказа
//ID заказа: $order->getId()
//ID пользователя: $order->getUserId()
//Сумма заказа: $order->getPrice()
//Размер скидки: $order->getDiscountPrice()
//Стоимость доставки: $order->getDeliveryPrice()
//Оплаченная сумма: $order->getSumPaid()
//Сумма заказа: $order->getPrice()

Сущность заказа передается в параметрах \Bitrix\Main\Event.

Чтобы получить её:

AddEventHandler( «sale» , «OnSaleOrderPaid» , «onSaleOrderSaved» ); //Событие при оплате заказа

function onSaleOrderSaved ( \Bitrix\Main\Event $event )
<
$order = $event->getParameter(«ENTITY»);

if (! $order ->isPaid() or $order ->isPaid()== false ) return ; // Обрабатываем только оплаченные заказы
//Тут происходит какая то логика для оплаченного заказа
//ID заказа: $order->getId()
//ID пользователя: $order->getUserId()
//Сумма заказа: $order->getPrice()
//Размер скидки: $order->getDiscountPrice()
//Стоимость доставки: $order->getDeliveryPrice()
//Оплаченная сумма: $order->getSumPaid()
//Сумма заказа: $order->getPrice()

Источник