Функционал Портала Ax2009

[Narayana]

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

Оно бы, конечно, можно было бы найти отмазку, сославшись на то, что весь функционал описан для традиционного пользовательского интерфейса, но ведь реально Портал предназначен для работы с внешними пользователями.
К тому же, такая вещь, как корзина покупок, каталоги номенклатур, публикация фоток номенклатур, регистрация внешних пользователей, хождение почты...

Как-то было бы странным, если бы все это оставалось недокументированным.
Но, за несколько лет ничего подобного не встречалось.

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

[Dreadlock]

+1

[Narayana]

Цитата:

Сообщение от Dreadlock

+1

Надеялся на то, что вы в очередной раз как фокусник вытащите зайца из шляпы и будет мне решение. Но, похоже, не все коту масленица

Но, все-таки, может быть, расскажите про логику работы с корзиной для покупок?
У меня что-то из под админа она не хочет работать.
При попытке открыть страницу Домашняя > Заказы на продажу > Корзина для покупок , появляется сообщение "При создании корзины не задан контакт".

Я так понимаю, модуль Продажи дает возможность корпоративным клиентам заходить в этот раздел и оформлять для себя заказы?
Но, с корзиной что-то непонятно.

В коде идет работа с таблицами SalesBasket и SalesBasketLine, но в конечном итоге записи появляются и в SalesTable, и в SalesLine. Причем, сразу же при создании Заказа на продажу.
SalesBasket и SalesBasketLine используются как промежуточное звено?
А может быть, создание Заказа на продажу и появление товаров в корзине для покупок, это разная функциональность?
Заказы на продажу должен создавать сотрудник, а в корзину товар отбирать должен корпоративный клиент? И уже после появления строк в корзине, сотрудник на базе этих строк создает заказ?

В общем, вроде, не ахти какой сложный вопрос, но без документации как-то не комильфо сидеть и догадываться.

[Dreadlock]

Да, надо создать контакт (по моему в модуле CRM) и иметь включеные лицензии (Роль продовец или покупатель и дистанционное обслуживание клиентов). Создать католог товаров и вперед. SalesBasket - это карзина.

Я не использовал в свое время этот функционал, т.к. клиенту он не понравился. И еще учтите, что справочник товаров отображается на странице полностью, т.е. если у вас 10 000 позиций, то они все будут отображаться на странице (в разрезе групп товаров правда), в свою очередь это сильно скажется на нагрузке веб сервера.

[nikos2001]

1. Контакт вместе с клиентом задаются на форме Администрирование > Пользователи > Пользовательские связи > Разное
2. Каталог продуктов находится в Администрирование > Настройка > Интернет > Корпоративный портал > Диспетчер каталога продуктов > Группы продуктов. Каталог имеет древообразную структуру (родительская группа > дочерняя группа), при этом стартовая группа указывается на форме Администрирование > Настройка > Интернет > Корпоративный портал > Дистанционное обслуживание клиентов > Параметры > Структура каталога товаров > Каталог продуктов
3. Чтобы корзина товаров не была временной (содержимое сохранялось и при следующем посещении клиентом портала), поставте флаг "Сохранять корзину продаж" (Дистанционное обслуживание клиентов > Параметры > Разное)

Ну и примеры кастомизации каталога продуктов:
http://www.formedesign.ca
http://www.technosport.com
http://www.www.cycleslambert.com
https://shop.zeg-holz.de (довелось быть главным разработчиком )

[Narayana]

Цитата:

Сообщение от Dreadlock

Да, надо создать контакт (по моему в модуле CRM) и иметь включеные лицензии (Роль продовец или покупатель и дистанционное обслуживание клиентов). Создать католог товаров и вперед. SalesBasket - это карзина.

Я не использовал в свое время этот функционал, т.к. клиенту он не понравился. И еще учтите, что справочник товаров отображается на странице полностью, т.е. если у вас 10 000 позиций, то они все будут отображаться на странице (в разрезе групп товаров правда), в свою очередь это сильно скажется на нагрузке веб сервера.

...м-м-м ...то есть, ознакомиться с каталогом клиент может в соответствии с предложенной ему структурой каталога (группы, картинки), а выбирать в заказ только из всего списка номенклатур?
Но, мы ведь можем выделить группы номенклатур, доступные этой группе клиентов?

[Narayana]

Цитата:

Сообщение от nikos2001

1. Контакт вместе с клиентом задаются на форме Администрирование > Пользователи > Пользовательские связи > Разное
2. Каталог продуктов находится в Администрирование > Настройка > Интернет > Корпоративный портал > Диспетчер каталога продуктов > Группы продуктов. Каталог имеет древообразную структуру (родительская группа > дочерняя группа), при этом стартовая группа указывается на форме Администрирование > Настройка > Интернет > Корпоративный портал > Дистанционное обслуживание клиентов > Параметры > Структура каталога товаров > Каталог продуктов
3. Чтобы корзина товаров не была временной (содержимое сохранялось и при следующем посещении клиентом портала), поставте флаг "Сохранять корзину продаж" (Дистанционное обслуживание клиентов > Параметры > Разное)

Ну и примеры кастомизации каталога продуктов:
http://www.formedesign.ca
http://www.technosport.com
http://www.www.cycleslambert.com
https://shop.zeg-holz.de (довелось быть главным разработчиком )

Ах, черть, красиво-то как!
Много работы с такой настройкой стилей и дополнительным дизайном?
Воодушевляет на подвиги... )

[nikos2001]

Да, конечно. Это полноценный вэбсайт компании, ориентированный на клиентов. Тут без помощи профессионального дизайнера не обойтись!

[Narayana]

Цитата:

Сообщение от nikos2001

Да, конечно. Это полноценный вэбсайт компании, ориентированный на клиентов. Тут без помощи профессионального дизайнера не обойтись!

Так все-таки, Аксапта и Портал подходит как инструмент для создания и фронт-офиса?
Помнится, как-то здесь как раз на тему фронт-офиса народ выражался пессимистично.
Тонким местом считали необходимость создания пользователя домена для входа в портал и то, что может создаваться слишком много розничных заказов.
А как у вас эта проблема решена?

...посмотрел повнимательнее, - кажется, это сайты для оптовиков...?

[nikos2001]

Да, это вэб-магазины по модели B2B (business-to-business). Думаю, для такой модели портал подходит (примеры выше тому подтверждение).

Лишний домен для внешнего доступа рекомендован майкрософтом, но не обязателен (т.н. perimeter network). Можно создавать аккаунты и во внутреннем домене, в собственной Organizational Unit c ограниченными правами доступа. Кстати в AX2012 наконец-то появилась возможность хранить внешние аккаунты в базе данных.

[Narayana]

Товарищи, помогите разобраться с алгоритмом регистрации нового пользователя Портала.

При определенных настройках в меню появляется пункт "Регистрация".
У меня два вопроса по этому поводу.

Первый: при каких условиях этот пункт меню оказывается видимым и при каких условиях кнопка "Отправить" (форму-заявку на регистрацию) оказывается активной.
Второй: какова логика и последовательность событий при регистрации.

Еще раз повторю ранее сказанное, - рад бы почитать, да негде.

Попробую пояснить, почему мне здесь не все понятно.

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

И дальше происходит нечто абсурдное.
Вы в форме регистрации должны выбрать из списка или ввести данные компании.
Эти даные затем появятся в форме обработки запросов на регистрацию в Аксапте.
Вопрос: зачем кому-то регистрироваться, если он уже и так зашел на Портал под существующей учетной записью?
Но, мало того, если пользователь в Аксапте сопоставлен с сотрудником, клиентом, поставщиком или деловым отношением с помощью формы Пользовательские связи, данные как раз этого клиента-посатвщика-сотрудника и появляются в форме заявки на регистрацию на Портале.
Тчк.
Это как понимать-то, вообще?
Регистрировать то, что уже и так зарегистрировано?

Ну, хорошо, допустим, видимость формы заявки на регистрацию на Портале зависит от пользовательстких связей. Или, точнее, того, кем мы объявляем пользователя. Хотя, чтобы понять это, нужно пару дней поупражняться, меняя ролевые привязки пользователя и при этом разглядывая Портал на предмет, а что там изменится?
Но, блин, вот нам Портал показал три поля: имя пользователя, е-мэйл пользователя, язык, которые нужно заполнить и нажать кнопочку "отправить", а когда вы ее нажмете, система обрадует вас сообщением инфолайна о том, что нужно заполнить еще несколько полей (компания, адрес, телефон и т.д.), которые в данный момент на форме скрыты...

Теперь я, кажется, понимаю, почему нет документации на функционал Портала.
Если ее опубликовать, то придется описывать то, что еще просто не работает...
Нет?

Но, может быть кто-нибудь может описать каноническую последовательность действий при регистрации?

При создании заявки от гостевой учетной записи что дальше происходит?
В моем понимании разрыв...
То ли система должна выдать пользователю временную учетную запись, чтобы войдя под ней, пользователь ввел бы дополнительные данные о своей компании (а как с частными лицами?) и снова отправил заявку на утверждение.
Но для этого в домене должна быть создана доменная учетная запись.
Кто ее создает? По кнопочке "Создать" в форме администрирования регистрации, вроде бы, создается новая запись в форме "Клиенты", но не новый пользователь домена...

Уф...
Но, раз есть рабочие сайты, кто-то ведь с этим разобрался...? )

[Narayana]

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

Но, вот, собственно, об интересном.
На одном из шагов в работе с формой Аксапты "Регистрация", система генерит временный пароль и его можно посмотреть, нажав кнопочку Пароль.
Вопрос: а что это за пароль?
На Портал юзер входит, используя доменную учетную запись и, естественно, пароль, созданный для этой учетной записи на контроллере домена.
При этом в письме пользователю есть слова, что пользователь может изменить пароль при первом входе в систему. А вот никаких средств для изменения пароля система, вроде, не предлагает. Да и как она может их предложить, если я для этой учетной записи в домене поставил галочку, что пользователь не может менять пароль?

[nikos2001]

Эта система регистрации досталась в наследство еще с портала AX 3.0, когда еще не было входа через домен. С годами микрософт ничего там не меняла, и весь этот сумбур так и перешел в 2009. Потому и документации не существует. Короче без серьезной доработки "все это" использовать нельзя.

[Narayana]

Цитата:

Сообщение от nikos2001

Эта система регистрации досталась в наследство еще с портала AX 3.0, когда еще не было входа через домен. С годами микрософт ничего там не меняла, и весь этот сумбур так и перешел в 2009. Потому и документации не существует. Короче без серьезной доработки "все это" использовать нельзя.

Стало быть, документация отчасти должна существовать в Ах 3.0?
А на Ах2012 переделали, не знаете?

[nikos2001]

На AX2012 не знаю, но там и сам процесс регистрации пользователей отличается (для входа можно использовать не только домен). Документация из AX3, если она есть, будет релевантна только в части создания клиента в аксапте, который уже привязан к пользователю. Процесс создание самого пользователя в 2009, естественно, отличается от 3.0

[Narayana]

Цитата:

Сообщение от nikos2001

На AX2012 не знаю, но там и сам процесс регистрации пользователей отличается (для входа можно использовать не только домен). Документация из AX3, если она есть, будет релевантна только в части создания клиента в аксапте, который уже привязан к пользователю. Процесс создание самого пользователя в 2009, естественно, отличается от 3.0

Ну, да... ну, да.
То есть, насколько я понял, есть два разных пункта меню с одним названием "Регистрация". Один для создания клиента, - он работает. То есть, дает возможность отправить заявку на регистрацию.
А второй отображает ту же страницу, но с названием "Создать нового пользователя".

При этом, в одном случае используется Managed content EPCSSCustSignUpGuest, в другом EPCSSCustSignUpUser.
Но, оба они как объект используют контрол EPCSSCustSignUp.
Разница только в том, что у Guest есть конфигурационный ключ EP, а у User никакого нет.
Интересно, что бы это значило?
То, что User должен появляться при самых малых правах при заходе анонимом?

[nikos2001]

Идея в том, что с помощью EPCSSCustSignUpUser запрашивается первичный доступ в AX. Администратор AX должен будет вручную создать пользователя в AD и AX, и с помощью формы ECPCustSignUpRequest привязать его к создаваемому на этой же форме клиенту и контакту.

С помощью EPCSSCustSignUpUser запрашивается доступ клиентов на получение дополнительных логинов. Например, если клиент имеет несколько филиалов и каждый филиал должен иметь свой логин. В этом случае Администратор AX должен вручную создать пользователя в AD и AX и с помощью формы ECPCustSignUpRequest и сделать привязку пользователя к создаваемому там же новому контакту.

[Narayana]

Цитата:

Сообщение от nikos2001

Идея в том, что с помощью EPCSSCustSignUpUser запрашивается первичный доступ в AX. Администратор AX должен будет вручную создать пользователя в AD и AX, и с помощью формы ECPCustSignUpRequest привязать его к создаваемому на этой же форме клиенту и контакту.

С помощью EPCSSCustSignUpUser запрашивается доступ клиентов на получение дополнительных логинов. Например, если клиент имеет несколько филиалов и каждый филиал должен иметь свой логин. В этом случае Администратор AX должен вручную создать пользователя в AD и AX и с помощью формы ECPCustSignUpRequest и сделать привязку пользователя к создаваемому там же новому контакту.

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

И еще одна очень неприятная вещь...
У пользователей интернета нет культуры ввода логина в окошке запроса логина винды вместе с именем домена. Тем более, что отдельного поля для имени домена в форме запроса логин-пароля сейчас нет (было в 2003 сервере).
Соответственно, это вызывает у пользователей смущение.
А если человек не айтишник, то, вообще, не догадается, что запись должна быть "домен\логин" или логин@домен.
Я решил переделать письмо новому пользователю, чтобы логин представлял собой уже запись с доменом, но боюсь, что это все-равно вызовет какой-то процент отказов от регистрации.

[nikos2001]

Цитата:

Сообщение от Narayana

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

Я ж говорю, интеграции с Active Directory (AD) здесь нет никакой. Вся эта функциональность досталась в наследство от предыдущих версий. Посылка этого емэйла - полная бессмыслица в данной реализации! Пароль хранится в поле ECPCustSignUp.TmpPassword

Цитата:

Сообщение от Narayana

И еще одна очень неприятная вещь...
У пользователей интернета нет культуры ввода логина в окошке запроса логина винды вместе с именем домена. Тем более, что отдельного поля для имени домена в форме запроса логин-пароля сейчас нет (было в 2003 сервере).

Чтобы не вводить домен, можно использовать Basic Authentication в IIS. В этом случае домен прописывается при конфигурации Basic Authentication и пользователи вводят обычный логин-пароль. Но Basic Authentication вещь не безопасная (пароль передаются открытым текстом по каналам инета) и поэтому обязательным условием ставится использование протокола HTTPS. Еще можете поиграть с Digest Autherntication в IIS, там домен тоже конфигурируется. Но в свое время я столкнулся с проблемой, что Firefox постоянно переспрашивал логин-пароль, когда использовалась Digest Autherntication

[Narayana]

Посмотрел как обстоят дела в Ax2012, - вроде бы, уже все сделано по человечески.
Форма регистрации нового пользователя в Портале подчищена и, вообще, такое ощущение, что работе с порталом уделено большое внимание. Наверное, то, что разработку перенесли полностью в VS2010, как раз избавляет от необходимости прыгать из одной среды в другую при разработке контролов Портала.