Лично для меня, как разработчика, сложность возникала из-за того, что я не пишу множество разным модулей для bitrix, а пишу множество интеграций для одной платежной системы [B]для разных CMS[/B], среди которых есть и bitrix.
Отдельным списком решил собрать свои "открытия" при знакомстве с миром bitrix24, может кому-нибудь окажется полезным
[LIST=1]
[*]Мне было очень [B]сложно понять разницу[/B] между БУС, Bitrix24 коробкой и Bitrix24 облаком. Не уверен, что и сейчас правильно ее понимаю. Сперва казалось, что это просто облачный Bitrix, потом, что это вообще отдельный продукт. А на деле, после локальной установки коробочной версии Bitrix24, я увидел почти такую же БД и такой же набор директорий, как и в БУС. Наверное, это называется общее ядро или даже так: [B]bitrix24 - это CRM модуль для bitrix[/B] (пишу наверное. т.к. могу ошибаться и разработчики bitrix называют это иначе)
[*]В CRM есть свой раздел настроек и пока я думал о bitrix24 как об отдельном продукте, я потратил кучу время перебирая этот "урезанный" раздел, пытаясь что-то администрировать. Оказалось, что добавив [B]"/bitrix/admin"[/B] к адресу портала попадаешь в привычную зону администрирования bitrix (правда не уверен насчет облака). Наверное это очень очевидно и я настолько мало знаком с миром Bitrix. но было бы замечательно подсказать об этом в разделе для новичков.
[*]При копировании модуля в /bitrix/modules каталог должен называться [B]<vendor name>.<module name>[/B]. Но при этом важно помнить про п.8, т.е. сам ACTION_FILE и каталог в php_interface/include/sale_payment не может содержать символ точки.
[*]Платежные системы по-прежнему лежать в [B]b_sale_pay_system_action[/B]
[*]Счета (invoice) это уже не заказы и лежат не в [S]b_sale_order[/S], а в [B]b_crm_invoice. [/B]По коду они тоже уже не Bitrix\Sale\Order, а [B]Bitrix\Crm\Invoice\Compatible\Invoice[/B]. хотя и наследники
[*]При создании платежной системы из скрипта установки модуля важно указать ENTITY_REGISTRY_TYPE = [B]CRM_INVOICE[/B], а не ORDER как было в sale
[*]При создании платежной системы [S]CSalePaySystem::Add[/S] уже [B]deprecated [/B]и почему-то в комментарии даже нет рекомендации, что использовать вместо него. Bitrix\Sale\PaySystem\Manager::add вроде бы подходит, но почему-то не добавляет логотип. Перелопатив кучу кода, выяснилось что можно использовать [B]PaySystemActionTable::add[/B], но перед его вызовом надо самому дернуть CFile::SaveForDB для логотипа, итого код создания платежной системы у меня получился вот такой:[CODE]$paySystemSettings = array(
"NAME" => "Some name",
"DESCRIPTION" => "Some description",
"ACTION_FILE" => "new_ps", // очень важно!
"ACTIVE" => "N",
"ENTITY_REGISTRY_TYPE" => "CRM_INVOICE",
"NEW_WINDOW" => "N",
"HAVE_PREPAY" => "N",
"HAVE_RESULT" => "N",
"HAVE_ACTION" => "N",
"HAVE_PAYMENT" => "Y",
"HAVE_RESULT_RECEIVE" => "Y",
"ENCODING" => "utf-8",
"SORT" => 100,
);
$imagePath = Application::getDocumentRoot() . '/bitrix/images/sale/sale_payments/new_ps.png';
if (File::isFileExists($imagePath)) {
$paySystemSettings['LOGOTIP'] = \CFile::MakeFileArray($imagePath);
$paySystemSettings['LOGOTIP']['MODULE_ID'] = "sale";
\CFile::SaveForDB($paySystemSettings, 'LOGOTIP', 'sale/paysystem/logotip');
}
$result = PaySystemActionTable::add($paySystemSettings);
if ($result->isSuccess())
return $result->getId();
return 0;[/CODE]
[*]Обработчик должен лежать в файле handler.php, а имя класса обработчика [B]обязательно должно совпадать[/B] с именем родительского каталога и значением в ACTION_FILE в БД.
[*]В CRM есть такое понятие как печатная форма - эта страница с деталями о счете, доступная клиенту по публичной ссылке (ее менеджер может отправить клиенту, например по email). И как оказалось, печатная форма - это тоже handler из [B]b_sale_pay_system_action[/B] и магия в том, что платежная система считается платежной формой если ее [B]ACTION_FILE [/B]начинается с префикса [B]bill [/B](со всем нюансами из п 8.)
[*]Для того, чтобы на обработчик прислать callback через [B]sale_ps_result.php [/B]он должен наследоваться от PaySystem\[B]ServiceHandler[/B]
[/LIST]
На мой взгляд, разработка под Bitrix - это бесконечный debug. Отсутствие документации и дополнительная логика в именовании директорий и классов сильно усложняют разработку. Если еще что-то вспомню - буду дополнять[B]
[/B]
Отдельным списком решил собрать свои "открытия" при знакомстве с миром bitrix24, может кому-нибудь окажется полезным
[LIST=1]
[*]Мне было очень [B]сложно понять разницу[/B] между БУС, Bitrix24 коробкой и Bitrix24 облаком. Не уверен, что и сейчас правильно ее понимаю. Сперва казалось, что это просто облачный Bitrix, потом, что это вообще отдельный продукт. А на деле, после локальной установки коробочной версии Bitrix24, я увидел почти такую же БД и такой же набор директорий, как и в БУС. Наверное, это называется общее ядро или даже так: [B]bitrix24 - это CRM модуль для bitrix[/B] (пишу наверное. т.к. могу ошибаться и разработчики bitrix называют это иначе)
[*]В CRM есть свой раздел настроек и пока я думал о bitrix24 как об отдельном продукте, я потратил кучу время перебирая этот "урезанный" раздел, пытаясь что-то администрировать. Оказалось, что добавив [B]"/bitrix/admin"[/B] к адресу портала попадаешь в привычную зону администрирования bitrix (правда не уверен насчет облака). Наверное это очень очевидно и я настолько мало знаком с миром Bitrix. но было бы замечательно подсказать об этом в разделе для новичков.
[*]При копировании модуля в /bitrix/modules каталог должен называться [B]<vendor name>.<module name>[/B]. Но при этом важно помнить про п.8, т.е. сам ACTION_FILE и каталог в php_interface/include/sale_payment не может содержать символ точки.
[*]Платежные системы по-прежнему лежать в [B]b_sale_pay_system_action[/B]
[*]Счета (invoice) это уже не заказы и лежат не в [S]b_sale_order[/S], а в [B]b_crm_invoice. [/B]По коду они тоже уже не Bitrix\Sale\Order, а [B]Bitrix\Crm\Invoice\Compatible\Invoice[/B]. хотя и наследники
[*]При создании платежной системы из скрипта установки модуля важно указать ENTITY_REGISTRY_TYPE = [B]CRM_INVOICE[/B], а не ORDER как было в sale
[*]При создании платежной системы [S]CSalePaySystem::Add[/S] уже [B]deprecated [/B]и почему-то в комментарии даже нет рекомендации, что использовать вместо него. Bitrix\Sale\PaySystem\Manager::add вроде бы подходит, но почему-то не добавляет логотип. Перелопатив кучу кода, выяснилось что можно использовать [B]PaySystemActionTable::add[/B], но перед его вызовом надо самому дернуть CFile::SaveForDB для логотипа, итого код создания платежной системы у меня получился вот такой:[CODE]$paySystemSettings = array(
"NAME" => "Some name",
"DESCRIPTION" => "Some description",
"ACTION_FILE" => "new_ps", // очень важно!
"ACTIVE" => "N",
"ENTITY_REGISTRY_TYPE" => "CRM_INVOICE",
"NEW_WINDOW" => "N",
"HAVE_PREPAY" => "N",
"HAVE_RESULT" => "N",
"HAVE_ACTION" => "N",
"HAVE_PAYMENT" => "Y",
"HAVE_RESULT_RECEIVE" => "Y",
"ENCODING" => "utf-8",
"SORT" => 100,
);
$imagePath = Application::getDocumentRoot() . '/bitrix/images/sale/sale_payments/new_ps.png';
if (File::isFileExists($imagePath)) {
$paySystemSettings['LOGOTIP'] = \CFile::MakeFileArray($imagePath);
$paySystemSettings['LOGOTIP']['MODULE_ID'] = "sale";
\CFile::SaveForDB($paySystemSettings, 'LOGOTIP', 'sale/paysystem/logotip');
}
$result = PaySystemActionTable::add($paySystemSettings);
if ($result->isSuccess())
return $result->getId();
return 0;[/CODE]
[*]Обработчик должен лежать в файле handler.php, а имя класса обработчика [B]обязательно должно совпадать[/B] с именем родительского каталога и значением в ACTION_FILE в БД.
[*]В CRM есть такое понятие как печатная форма - эта страница с деталями о счете, доступная клиенту по публичной ссылке (ее менеджер может отправить клиенту, например по email). И как оказалось, печатная форма - это тоже handler из [B]b_sale_pay_system_action[/B] и магия в том, что платежная система считается платежной формой если ее [B]ACTION_FILE [/B]начинается с префикса [B]bill [/B](со всем нюансами из п 8.)
[*]Для того, чтобы на обработчик прислать callback через [B]sale_ps_result.php [/B]он должен наследоваться от PaySystem\[B]ServiceHandler[/B]
[/LIST]
На мой взгляд, разработка под Bitrix - это бесконечный debug. Отсутствие документации и дополнительная логика в именовании директорий и классов сильно усложняют разработку. Если еще что-то вспомню - буду дополнять[B]
[/B]