Форум

У вас сам функционал (не важно на чем) соберет сотни человекочасов (если вы хотите собрать хотя бы половину той CRM что есть). Ну и сам корпортал крайне сложен будет для понимания, если вы не понимаете даже специфику модулей БУС.

Мне кажется, проще такой план:
- составляете список чего не хватает
- сообщаете Битрикс, слушаете что он ответит и что когда реализует, что по сути не надо, а что (быть может) решает другой модуль
- по остаткам составляете ТЗ
- разработчик делает
- ???
- profit

А как вы увидите внутренности чужих порталов?

Хм, интересный баг получается - вы не сможете на демке расширить этот функционал, ибо что доступно в МБ (кол-во типов цен, к примеру) зашито в обфусцированном модуле каталога.

Рекомендую снести модуль каталога (с сохранением таблиц) и с удалением с диска, и закачать заново.

Хм. Вообще-то, "вакансия всегда чья-то" © кот Матроскин. В данном случае, это вакансия Юли, которая ищет сотрудника.

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

[QUOTE]eShopMaster пишет:
100 000 транзакций за одну секунду
[/QUOTE]Такие вопросы не задают на форуме, "получив заказ на разработку". На это выделяют миллионы и этим занимается hl-команда, а не один человек. Они не делятся этим опытом, и не пишут на хабрике.

Битрикс... Битрикс тут как-то поверхностно и размыто участвует.

Я не ставил целью вас задеть или обидеть, я лишь показал, что заказчик прежде всего не понимает что такое 100 000 в секунду, и что не у всех акул интернет-бизнеса такие обороты. Но миллионы он уже должен доставать, раз уверен в таком обороте.

Я бы рекомендовал отмотать назад и поставить вопрос так - "а что нам надо на первом шаге" и "в перспективе 2 лет"? Поверьте, через два года все технологии поменяются.

Отвечая на ваш вопрос - нет, такую систему на каком-либо универсальном ПО создать невозможно. Все пишется с нуля и дрочатся над каждым байтом кода.

[QUOTE]golovach пишет:
Для решения этой проблемы инфоблоки нужно перевести в [url=http://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=43&LESSON_ID=2723]Режим хранения свойств в отдельных таблицах[/url] , в этом случае для свойства будет отдаваться массив значений. Либо можно не указывать свойства в параметрах выборки, а получать их значения на каждом шаге перебора выборки с помощью _CIBElement::GetProperties().
[/QUOTE]Какой ужас написан в документции. Это просто жесть. Нельзя так делать!

В ИБ+ переводят не для решения этой проблемы, а для других целей. Для решения этой проблемы итерации загоняются в общий массив, а если там данные по ID уже есть, то они дополняются.

А вот за второе я лишал бы права на разработку. Потом у людей сотни запросов на странице появляются. А это затолкали в документацию черт.

Нет слов.

[QUOTE]Денис Харченко пишет:
увидев что большое количество запросов блокируется
[/QUOTE]Блокируется на уровне продукта опять же. А это все раво хиты, все равно обращения. То есть, если кто-то начинает долбить Битрикс, проактивка по хитам не спасает. Только грамотный тюнинг сервера.

Ну и смотрите выше - кому надо так "заддосить" сервер - подделает заголовки  и заддосит.

А им какой смысл?
Тут надо плясать от "а зачем вам".
Откроют напрямую - увидят что-то страшное? Так кому надо - откроет хоть как.
Просто красиво? Получите больше геморроя, когда сервер или еще кто порежет заголовок.
Поисковики? disallow /ajax/ спасет ситуацию.

[url=http://dev.1c-bitrix.ru/api_help/sale/classes/csaleorder/csaleorder__getlist.41061294.php]CSaleOrder::GetList[/url]

Есть куча примеров, в том числе в комментах.