В процессе тестирования функционала столкнулись с тем, что система работает
некорректно в части создания регулярных задач, а именно, системой
игнорируется интервал повторения в определенное количество месяцев, вместо
этого задача создается каждый день.
Например, если сделать повторение каждый 1 любой день с интервалом 2 месяца, то задача будет создаваться ежедневно, а не один раз в два месяца.
некорректно в части создания регулярных задач, а именно, системой
игнорируется интервал повторения в определенное количество месяцев, вместо
этого задача создается каждый день.
Например, если сделать повторение каждый 1 любой день с интервалом 2 месяца, то задача будет создаваться ежедневно, а не один раз в два месяца.
Добрый день.
Предлагаю доработки "Бронирования" которые на мой взгляд привлекли к вам больше клиентов в виде стоматологий, салонов и других бизнесов.
1. Учёт графика работы.
При бронировании ресурсов нет учёта графика работы сотрудников. Но при этом функционал графика работы на портале есть и есть график отсутствий. Приходится лепить костыли.
2. Редактирование карточки на календаре бронирования.
Чтобы бронирование ресурсов было хоть каплю информативно приходится все данные пихать в название. Нет возможности выделения карточек цветами. При этом в календаре личном или компании половина функционала есть.
3. Календарь бронирования ресурсов
На календаре не возможно увидеть занятость всех сотрудников, либо колонками, либо строками. Чтобы взглянув на календарь можно было сразу увидеть, У Васи и Ивана свободны 14 часов. Сейчас это не возможно.
4. Обязательное заполнение поля бронирования ресурсов.
У всех полей есть функционал, чтобы поле было обязательно только на определённых стадиях, у этого нет. Хотелось бы чтобы был данный функционал.
5. Различные наборы условий выбора в бронировании.
Например, стоматология имеет 3 клиники по 10 врачей в каждой. Если создать 1 поле то администраторы будут видеть список из 30 врачей, 10 своих и 20 с других клиник. В этом хаосе невозможно найти свободное время.
А если делать отдельное поле для каждой клиники, то наступает полный ужас при попытке сделать любую автоматизацию в БП. приходится постоянно лепить проверки какое именно поле было заполнено, а так же заказчик звонит и говорит открываем 4 клинику и масштабировать это становится почти невозможно.
6. Баг при редактировании поля бронирование ресурсов.
Создаю поле, указываю 3-х сотрудников. Решаю добавить 4-го, нажимаю редактировать, а первых 3-х уже и нет и нужно снова их задавать. В общем поле не сохраняет своё состояние в поле сотрудники.
7. Нет синхронизации данных из лида в сделку при бронировании ресурсов.
Приходится мутить всё через БП, при этом ещё и сбрасывать запись в лиде, после передачи данных в сделку. Хотелось бы это видеть из коробки.
Мне кажется эти доработки позволили бы предлагать ваш продукт большему количеству бизнесов.
Предлагаю доработки "Бронирования" которые на мой взгляд привлекли к вам больше клиентов в виде стоматологий, салонов и других бизнесов.
1. Учёт графика работы.
При бронировании ресурсов нет учёта графика работы сотрудников. Но при этом функционал графика работы на портале есть и есть график отсутствий. Приходится лепить костыли.
2. Редактирование карточки на календаре бронирования.
Чтобы бронирование ресурсов было хоть каплю информативно приходится все данные пихать в название. Нет возможности выделения карточек цветами. При этом в календаре личном или компании половина функционала есть.
3. Календарь бронирования ресурсов
На календаре не возможно увидеть занятость всех сотрудников, либо колонками, либо строками. Чтобы взглянув на календарь можно было сразу увидеть, У Васи и Ивана свободны 14 часов. Сейчас это не возможно.
4. Обязательное заполнение поля бронирования ресурсов.
У всех полей есть функционал, чтобы поле было обязательно только на определённых стадиях, у этого нет. Хотелось бы чтобы был данный функционал.
5. Различные наборы условий выбора в бронировании.
Например, стоматология имеет 3 клиники по 10 врачей в каждой. Если создать 1 поле то администраторы будут видеть список из 30 врачей, 10 своих и 20 с других клиник. В этом хаосе невозможно найти свободное время.
А если делать отдельное поле для каждой клиники, то наступает полный ужас при попытке сделать любую автоматизацию в БП. приходится постоянно лепить проверки какое именно поле было заполнено, а так же заказчик звонит и говорит открываем 4 клинику и масштабировать это становится почти невозможно.
6. Баг при редактировании поля бронирование ресурсов.
Создаю поле, указываю 3-х сотрудников. Решаю добавить 4-го, нажимаю редактировать, а первых 3-х уже и нет и нужно снова их задавать. В общем поле не сохраняет своё состояние в поле сотрудники.
7. Нет синхронизации данных из лида в сделку при бронировании ресурсов.
Приходится мутить всё через БП, при этом ещё и сбрасывать запись в лиде, после передачи данных в сделку. Хотелось бы это видеть из коробки.
Мне кажется эти доработки позволили бы предлагать ваш продукт большему количеству бизнесов.
Универсальный платежный агрегатор 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-запросы и прочее. Хотя конечно поражает, насколько не глубоки возможности БП и роботов без необходимости лезть в код
Я бы хотел получить данные из стандартного поля "Пол", которого почему-то нет в списке, чтобы формировать строку "действующий/действующая", а также из пользовательского поля "№ доверенности", "ФИО родительном падеже" и т.д.
Не хочется из-за таких мелочей углубленно изучать PHP, API-запросы и прочее. Хотя конечно поражает, насколько не глубоки возможности БП и роботов без необходимости лезть в код
В форме редактирования элемента 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С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
