Jump to content
SpravkaCRM.ru - Ваш справочник по CRM
  • Готовые решения для SugarCRM

    Вводная

    В этом разделе собраны решения некоторых задач для SugarCRM. Все решения уже разработаны, оттестированы и внедрены для ряда компаний. В силу того, что данные функционалы мы уже разработали, мы предлагаем понравившиеся Вам идеи и их реализации по сниженной цене. Это не коробочный вариант, когда Вы приобрели модуль, установили, и пользуетесь. Все же некоторое "допиливание" под Вашу CRM-систему будет необходимо. Но вы не платите за разработку того или иного функционала "с нуля". Вы платите только небольшую стоимость за сам модуль, и за наши услуги по настройке и адаптации приобретенного модуля в своей CRM-системе. Отдельно модули не продаются. Продаются только с нашей установкой.

    Набор модулей будет постоянно расширяться, так что следите за обновлением данного раздела.

    Предлагаемые решения для SugarCRM

    SQLAccess - гибкая настройка доступов для SugarCRM

    Версии для установки
    SugarCRM CE и SugarCRM PRO
    Краткое описание
    Данный функционал будет очень полезен для установки в бесплатную версию SugarCRM CE и добавит гибкости настроек в платную версию SugarCRM Pro. Речь идет про возможность ограничения доступа тех или иных пользователей CRM-системы к записям модулей основываясь на каких-либо характеристиках этих записей. Разработанный модуль SQLAccess позволит сегментировать Ваших клиентов практически по любым признакам, будь то название контрагента, город, статус, откуда пришел клиент и какая общая сумма его сделок. И для каждого из указанных Вами сегментов можно указать пользователей, которые имеют, или наоборот, не имеют доступ к этому сегменту. В бесплатной версии SugarCRM CE такого вообще нет. Там пользователям можно или дать доступ вообще ко всем записям модуля, или только к тем, у которых он является ответственным, или вообще запретить доступ к тому или иному модулю. Разграничение доступов среди записей модуля в бесплатной версии SugarCRM CE не предусмотрено. В PRO-версии SugarCRM ситуация немного получше за счет использования команд. Но данный функционал может пригодиться и там для более гибкой настройки доступов среди сотрудников.
    Более подробное описание функционала
    В статье SQLAccess - гибкая настройка доступов в бесплатной SugarCRM CE более подробно расписан предлагаемый функционал.
    Стоимость модуля
    Сам функционал стоит 5 000 рублей.
    Стоимость внедрения для Вашей CRM-системы
    Стоимость адаптации его в Вашей CRM-системы будет зависеть от нескольких факторов:
    • Являетесь ли Вы уже нашим клиентом (тогда не надо тратить время на развертывание Вашей CRM-системы и на "погружение" в особенности Вашей CRM-системы);
    • SugarCRM какой версии у Вас стоит (SugarCRM от версии к версии может отличаться, и что было сделано и оттестировано на одних версиях, может потребовать небольшой доработки на других версиях SugarCRM);
    • Есть ли необходимость составления технической и эксплуатационной документации по вносимому функционалу;
    • Может еще что-то...
    И, все же, ориентировочная стоимость развертывания функционала будет приблизительно равна 3-4 тысячи рублей.
    Стоимость настройки
    Функционал реализован таким образом, что его настройку должен произвести специалист по SugarCRM (необходимы знания архитектуры баз данных SugarCRM). Дальнейшая эксплуатация настроенного функционала не подразумевает обслуживание техническими специалистами. Мы с удовольствием выполним для Вас данную работу. Стоимость ее будет зависеть от кол-ва сегментов, которые Вы захотите добавить в CRM-системе. Ориентировочно, настройка одного сегмента (например, по сумме сделок клиентов) будет стоить порядка 500 рублей.
    Итого
    5000 рублей за модуль + 4000 рублей за внедрение + 2000 рублей (приблизительно) за настройку модуля = 11000 рублей. Данная сумма указана приблизительно, и может быть скорректирована при обсуждении конкретной ситуации внедрения.
    • CRM на русском беcплатно

      CRMHosting.ru
      Персональная CRM-система на базе SuiteCRM. Административный доступ. Автоматизированное разворачивание в пределах 2-х минут. Бесплатное использование для небольших компаний. Да и просто чтобы протестировать. 
  • Последние публикации

  • Сообщения

    • Добрый день! Подскажите, пожалуйста, каким образом я могу отправить письмо на электронный ящик указанный в Текстовом поле. Т.е. задача такая: у меня есть модуль в нем текстовое поле. При создании записи, я заполняю это текстовое поле каким-либо e-mail, и при сохранении записи происходит обработка процесса: отправка шаблона на e-mail указанный в этом текстовом поле.  Есть идеи, каким образом это можно исполнить? Копал в сторону подстановки Адрес - Поле (условия обработки процесса) но не могу понять какие данные в форму Поле вводить. Буду благодарен за любые идеи! 
    • Как вы потом заливаете изменения из гита в конкретную папку веб-сервера?
    • Я бы копал в сторону того, чтобы просто сделать поле не активным с помощью html-параметра.
    • Добрый день! Общий принцип: исключаем файлы, которые являются автогенерируемыми (папка cache, папки Ext в /custom/modules) и так далее. Так же исключаем загружаемые файлы, историю изменений metadata-файлов, индексы поиска, служебные файлы разных GUI и прочее. Я сталкивался с тем, что некоторые системные администраторы пытаются засунуть в .gitignore core-файлы типа того, что находится в папках Zend, XTemplate и так далее обосновывая тем, что не надо эти файлы править, значит и в гите им делать нечего. Я против такого подхода. Считаю, что в git должны быть файлы, достаточные для корректного запуска SuiteCRM в том месте, где его развернули из git-репозитория. Вот файл .gitignore одного из проектов: *.log .DS_Store Thumbs.db /cache/* /.idea/* /config.php /config_override.php /tmp/ /upload/ /custom/screenshots/ /test_*.php /custom/blowfish/* /custom/history/* /custom/modulebuilder/* /custom/working/* /custom/application/Ext/ /custom/modules/*/Ext/ /custom/modules/unified_search_modules_display.php /modules/AOD_Index/Index/* /.htaccess /custom/client_secret.json /custom/appsactivity-php-quickstart.json   Такой подход комфортно работает если изменения структуры модулей делать не в студии, а вручную. Поля, добавляемые в студии, вносят meta-данные (vardef) в таблицу в БД, а она через git не обновляется. А если будете расширять список полей вручную, то вполне сможете работать через git запуская быстрое восстановление.     Не претендую на супер-универсальность и что это решение самое лучшее, но вот одна из реализаций, которой пользуемся наиболее часто: Ветки + сервера: В git-репозитории создаем ветку master. Эта ветка содержит состояние файлов на PROD-сервере В git-репозитории создаем ветку test. Эта ветка содержит состояние файлов на TEST-сервере В git-репозитории создаем произвольное кол-во веток с конкретными задачами, находящимися в работе (по 1-ой ветке на каждую задачу) Процесс работы: Берем очередную задачу в работу: из master делаем ветку с задачей. работаем в ней. Как правило это удаленная ветка, так как в процессе работы над задачей часто работают несколько человек. После выполнения задачи она окончательно пушится на сервер. Делается мерж ветки test и ветки с задачей. На тестовом сервере делаем pull ветки test и проверяем работу. Если все норм, то ветка с задачей мержится с веткой master Если что то не норм, то ветка с задачей просто уходит в доработку. Ветки test и master никогда не мержатся. Все происходит именно путем мержа ветки с задачей.   P.S. надо видимо уведомления где то тут найти чтобы на почту приходили... а то задача то наверное уже не актуальна ... больше для тех, кто по поиску потом придет...
    • Добрый день. Есть 3 сервера SuiteCRM: DEV, DEMO, PROD. Хотелось бы упростить (читай ускорить, в идеале автоматизировать) перенос доработок DEV => DEMO и DEMO => PROD. Есть идея использовать репозиторий для хранения файлов и забирать изменения из него. Но тут возникает сразу несколько вопросов: 1. Какие файлы надо исключить из контроля версий? 2. Как правильно отслеживать и применять изменения в базе? Есть опыт, что достаточно скопировать файлы .php и изменения в базе обработает "быстрое восстановление". Можно  ли всегда так делать? 3. Насколько приемлем вариант разработки сразу на площадке DEV, без создания у себя локальной копии CRM? Как в этом случае вести одновременно несколько доработок? Просьба поделиться опытом в вопросе организации репозитория и контроля версий. А также других возможных способах упрощения переноса доработок между площадками.   SuiteCRM 7.10.10, MySQL    
×