Универсальный платежный агрегатор Tegro.money
Описание:
Tegro.money - это инновационный платежный агрегатор, разработанный командой специалистов для оптимизации и упрощения процесса приема платежей на сайтах их клиентов. Эта система объединяет различные платежные инструменты в едином пользовательском интерфейсе, предоставляя продавцам и покупателям удобное и быстрое решение для проведения платежных операций.
Основные возможности:
1. API-сервис: Этот сервис позволяет принимать платежи, осуществлять возвраты и узнавать статусы операций. Для работы по API клиентам потребуется создать магазин в системе Tegro.money. Подробная доступна для изучения.
2. Регистрация аккаунта: Клиенты могут быстро и легко зарегистрировать аккаунт для интеграции своего магазина. Начните принимать платежи, перейдя на .
3. Создание платежа: Система предоставляет удобный интерфейс для создания платежей. Достаточно передать необходимые параметры на .
4. Интеграция с GitHub: В представлена вся необходимая документация для разработчиков.
5. Презентация продукта: Ознакомьтесь с для получения дополнительной информации.
Цель:
Основная цель команды Tegro.money - привлечение инвестиций для дальнейшего развития и масштабирования своего продукта. Они стремятся стать лидерами в сфере платежных агрегаторов, предоставляя клиентам надежные и удобные решения.
Описание:
Tegro.money - это инновационный платежный агрегатор, разработанный командой специалистов для оптимизации и упрощения процесса приема платежей на сайтах их клиентов. Эта система объединяет различные платежные инструменты в едином пользовательском интерфейсе, предоставляя продавцам и покупателям удобное и быстрое решение для проведения платежных операций.
Основные возможности:
1. API-сервис: Этот сервис позволяет принимать платежи, осуществлять возвраты и узнавать статусы операций. Для работы по API клиентам потребуется создать магазин в системе Tegro.money. Подробная доступна для изучения.
2. Регистрация аккаунта: Клиенты могут быстро и легко зарегистрировать аккаунт для интеграции своего магазина. Начните принимать платежи, перейдя на .
3. Создание платежа: Система предоставляет удобный интерфейс для создания платежей. Достаточно передать необходимые параметры на .
4. Интеграция с GitHub: В представлена вся необходимая документация для разработчиков.
5. Презентация продукта: Ознакомьтесь с для получения дополнительной информации.
Цель:
Основная цель команды Tegro.money - привлечение инвестиций для дальнейшего развития и масштабирования своего продукта. Они стремятся стать лидерами в сфере платежных агрегаторов, предоставляя клиентам надежные и удобные решения.
По следам переписки на форуме:
Предлагаю добавить дополнительный параметр в telephony.externalcall.finish чтобы при завершении звонка не менять ответственного за сущность
Предлагаю добавить дополнительный параметр в telephony.externalcall.finish чтобы при завершении звонка не менять ответственного за сущность
Сейчас для настройки СМС-сервисов, в частности SMS-ru нужно проходить полный квест с регистрацией и вводом всех данных клиента.
Но часто у клента уже есть кабинет в сервисе и уже есть заранее созданный Ключ API. И приходится несколько дней со скриншотами и ссылками на документацию объяснять клиенту, почему мы не можем его "просто прописать", а заставляем проходить процедуру регистрации заново.
Пожалуйста, добавть в админке опцию "просто вписать параметры интеграции руками".
PS. идея для Управления сайтом, случайно создал в другом разделе, но ни перенести ни удалить и создать заново её нельзя.
Но часто у клента уже есть кабинет в сервисе и уже есть заранее созданный Ключ API. И приходится несколько дней со скриншотами и ссылками на документацию объяснять клиенту, почему мы не можем его "просто прописать", а заставляем проходить процедуру регистрации заново.
Пожалуйста, добавть в админке опцию "просто вписать параметры интеграции руками".
PS. идея для Управления сайтом, случайно создал в другом разделе, но ни перенести ни удалить и создать заново её нельзя.
В виде задач "сроки" добавить отображение базовой задачи в карточках задач, как можно включить отображение проекта.
Сейчас в БП есть возможность получить сведения о сотруднике, но только из основных полей:
Я бы хотел получить данные из стандартного поля "Пол", которого почему-то нет в списке, чтобы формировать строку "действующий/действующая", а также из пользовательского поля "№ доверенности", "ФИО родительном падеже" и т.д.
Не хочется из-за таких мелочей углубленно изучать PHP, API-запросы и прочее. Хотя конечно поражает, насколько не глубоки возможности БП и роботов без необходимости лезть в код
UPD: Также хотелось бы иметь возможность через простой активити (без PHP) изменять поля карточки любого контакта. Сейчас такой возможности, почему-то нет
Я бы хотел получить данные из стандартного поля "Пол", которого почему-то нет в списке, чтобы формировать строку "действующий/действующая", а также из пользовательского поля "№ доверенности", "ФИО родительном падеже" и т.д.
Не хочется из-за таких мелочей углубленно изучать PHP, API-запросы и прочее. Хотя конечно поражает, насколько не глубоки возможности БП и роботов без необходимости лезть в код
UPD: Также хотелось бы иметь возможность через простой активити (без PHP) изменять поля карточки любого контакта. Сейчас такой возможности, почему-то нет
В форме редактирования элемента CRM есть возможность настроить отображение поля Клиент (показывать контакта или нет, показывать компанию первой, показывать адрес, показывать реквизиты и т.д.). Нам нужно только поле с компанией.
К сожалению, при настройке быстрого создания карточки в канбане поле "Клиент" всегда показывается с контактом, реквизитами, телефоном, адресом и т.д. Это очень мешает. А изменить это нельзя. Можно только выбрать какие поля показывать, но не как их показывать.
По идее, параметры отображения поля должен совпадать с настройками отображения в обычной карточке элемента CRM, а не показываться "по дефолту".
Кроме того, должна быть возможность, если выбрана компания при выборе контакта показать сотрудников этой компании. Я не понимаю, зачем выводить вообще всех контактов - Елен, Александров и т.д.
Понятное дело, что мне нужна конкретная Елена, работающая в выбранной компани, а не случайная Елена из списка всех 2000 Елен в списке контактов нашего CRM. Либо возможность ввести новую Елену (если конкретной нет).
К сожалению, при настройке быстрого создания карточки в канбане поле "Клиент" всегда показывается с контактом, реквизитами, телефоном, адресом и т.д. Это очень мешает. А изменить это нельзя. Можно только выбрать какие поля показывать, но не как их показывать.
По идее, параметры отображения поля должен совпадать с настройками отображения в обычной карточке элемента CRM, а не показываться "по дефолту".
Кроме того, должна быть возможность, если выбрана компания при выборе контакта показать сотрудников этой компании. Я не понимаю, зачем выводить вообще всех контактов - Елен, Александров и т.д.
Понятное дело, что мне нужна конкретная Елена, работающая в выбранной компани, а не случайная Елена из списка всех 2000 Елен в списке контактов нашего CRM. Либо возможность ввести новую Елену (если конкретной нет).
Если настроить триггер на изменение поля, скажем, "Тип договора" - и при создании элемента смарт-процесса сразу его заполнить, то триггер не отработает. И элемент не передвинется на другую стадию
Нам нужно чтобы при создании элемента (договора), первоначально нужно было заполнить тип договора, а тогда при создании нового договора элемент сразу же перенесся на вторую стадию и в зависимости от выбранного типа договора, все поля элемента СП заполнились бы дефолтными для данного типа договора значениями, а также заполнились бы другие поля на основании выбранного клиента.
Сейчас же такое реализовать не получается. Т.е. нужно сначала создать элемент, а уже потом при следующем изменении - триггер срабатывает.
Нам нужно чтобы при создании элемента (договора), первоначально нужно было заполнить тип договора, а тогда при создании нового договора элемент сразу же перенесся на вторую стадию и в зависимости от выбранного типа договора, все поля элемента СП заполнились бы дефолтными для данного типа договора значениями, а также заполнились бы другие поля на основании выбранного клиента.
Сейчас же такое реализовать не получается. Т.е. нужно сначала создать элемент, а уже потом при следующем изменении - триггер срабатывает.
Хотелось бы иметь возможность в бизнес-процессах (как в CRM, так и в списках) простым действием получить/зарезервировать следующий номер определенного нумератора CRM для документа еще до генерации печатной формы этого документа.
Это нужно, например, для того, чтобы в смарт-процессе "Договоры с клиентами" получить следующий номер договора на одной из начальных стадий согласования договора и причем не только зафиксировать его в печатной форме (PDF-документе), но и сохранить его в поле TITLE элемента смарт-процесса — чтобы можно было его искать, вставлять в печатную форму, использовать в оповещениях и т.п.
Это нужно, например, для того, чтобы в смарт-процессе "Договоры с клиентами" получить следующий номер договора на одной из начальных стадий согласования договора и причем не только зафиксировать его в печатной форме (PDF-документе), но и сохранить его в поле TITLE элемента смарт-процесса — чтобы можно было его искать, вставлять в печатную форму, использовать в оповещениях и т.п.
Прошу сделать возможным при указании физических адресов объектов создавать страницы данных объектов на которых будет собрана информация в каких сделках данный объект участвовал и какие задачи относятся к данному объекту.
Также не плохо было бы видеть информацию на инерактивной карте (за основу можно взять яндекс карту или любую другую) по каким объектам созданы сделки и задачи с привязанными физическими адресами.
Также не плохо было бы видеть информацию на инерактивной карте (за основу можно взять яндекс карту или любую другую) по каким объектам созданы сделки и задачи с привязанными физическими адресами.
Сегодня у нас де-факто существует 2 версии API: старый CCrm* с событиями и новый подход с фабрикой и операциями. Я не являюсь сторонником старого подхода, однако в новом подходе партнеры разрабатывающие тиражные приложения получили существенный недостаток - их лишили возможности динамически подписываться на события.
В новом подходе архитектурно у нас нет событий в их текущем виде и для того чтобы добавить свое поведение в какой-нибудь СП необходимо перекрывать фабрику этого СП и добавлять Action, что в свою очередь пораждает проблемы в тиражном приложении: невозможно поставить 2 тиражных приложения каждое из которых перекрывает одну и ту же фабрику.
Предлагаю свое компромисное решение: мы будем использовать событие, которое будет добавлять Action's к Operation.
Мне совершенно не нравится идея когда мы будем тащить события для обратной совместимости как это было со сделками, однако сам механизм событий показал себя вполне хорошо.
Предлагаю расширить методы получения операций `get*Operation` в `Bitrix\Crm\Service\Factory` чем-то вроде такого:
Таким образом можно получить следующие преимущества:
1. Возможность динамического расширения операций без кастомизации фабрик.
2. Как следствие пункта 1 - возможность использовать это в модулях для маркетплейса
Почему в `OnBuildOperation` не передается операция?
Сама операция является высокоуровневым действием и ее настройки, а так же опции должны конфигурироваться вызываемой строной, в то время как прямая передача ее в событие позволит значительно менять поведение системы, что сильно усложнит отладку.
К тому же - событие является глобальным, а значит что для определения нужного смарт-процесса в таком случае необходимо все равно было бы тащить туда данные текущей фабрики.
Для определения типа операции предлагается использовать название класса операции или возможно Enum из значений доступных операций (предпочтительнее).
В новом подходе архитектурно у нас нет событий в их текущем виде и для того чтобы добавить свое поведение в какой-нибудь СП необходимо перекрывать фабрику этого СП и добавлять Action, что в свою очередь пораждает проблемы в тиражном приложении: невозможно поставить 2 тиражных приложения каждое из которых перекрывает одну и ту же фабрику.
Предлагаю свое компромисное решение: мы будем использовать событие, которое будет добавлять Action's к Operation.
Мне совершенно не нравится идея когда мы будем тащить события для обратной совместимости как это было со сделками, однако сам механизм событий показал себя вполне хорошо.
Предлагаю расширить методы получения операций `get*Operation` в `Bitrix\Crm\Service\Factory` чем-то вроде такого:
public function get*Operation(Item $item, Context $context = null): Operation\Add
{
$operation = new Operation\Add($item, $this->getOperationSettings($context), $this->getFieldsCollection());
// ....
$event = new Event("crm", "OnBuildOperation", [
'factory' => $this,
'actionClass' => get_class($operation)
]);
$event->send();
if ($event->getResults())
{
foreach($event->getResults() as $eventResult)
{
if ( $eventResult->getResultType() !== EventResult::SUCCESS )
{
continue;
}
$eventParameters = $eventResult->getParameters();
if ( isset($eventParameters['ACTIONS']) && is_array($eventParameters['ACTIONS']) )
{
foreach ($eventParameters['ACTIONS'] as $action)
{
if ( !is_object($action['OBJ']) || !($action['OBJ'] instanceof Operation\Action) )
{
continue;
}
$operation->addAction(
$action['PLACE'],
$action['OBJECT'],
);
}
}
}
}
return $operation;
} |
Таким образом можно получить следующие преимущества:
1. Возможность динамического расширения операций без кастомизации фабрик.
2. Как следствие пункта 1 - возможность использовать это в модулях для маркетплейса
Почему в `OnBuildOperation` не передается операция?
Сама операция является высокоуровневым действием и ее настройки, а так же опции должны конфигурироваться вызываемой строной, в то время как прямая передача ее в событие позволит значительно менять поведение системы, что сильно усложнит отладку.
К тому же - событие является глобальным, а значит что для определения нужного смарт-процесса в таком случае необходимо все равно было бы тащить туда данные текущей фабрики.
Для определения типа операции предлагается использовать название класса операции или возможно Enum из значений доступных операций (предпочтительнее).
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
