Как вывести в отчет связанные поля

Добрый вечер! Возникла трудность, мне необходимо сделать отчет, в котором будут некоторые данные о моем кастомном объекте и также было бы неплохо вставить туда данные из объекта пользователи. Но в типа отчета нельзя выбрать тип Пользователи и мой кастомный объект или Кастомный объект и пользователи. Но в моем кастомной объекте есть взаимосвязь поиска на пользователя. Поэтому такой вопрос, можно ли как-то вытянуть через эту взаимосвязь, данные из другого бъекта в отчет? Прошу прощение за этот бред, просто не знаю как по-другому объяснить ((

Sergey Ayvazyan

Добрый вечер! Возникла трудность, мне необходимо сделать отчет, в котором будут некоторые данные о моем кастомном объекте и также было бы неплохо вставить туда данные из объекта пользователи. Но в типа отчета нельзя выбрать тип Пользователи и мой кастомный объект или Кастомный объект и пользователи. Но в моем кастомной объекте есть взаимосвязь поиска на пользователя. Поэтому такой вопрос, можно ли как-то вытянуть через эту взаимосвязь, данные из другого бъекта в отчет? Прошу прощение за этот бред, просто не знаю как по-другому объяснить ((

Привет Сергей,

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

Все что я могу подсказать, это дать ссылки на литературу по отчетам. У SF есть спец учебники по всем требуемым темам.

ВОт Analytics workbook:
http://www.salesforce.com/us/developer/docs/workbook_analytics/index.htm

также базовые знания по отчетам есть в фундаменталс воркбук:
http://www.salesforce.com/us/developer/docs/fundamentals/index.htm

и главное, попробуй сформулировать свой вопрос на английском и погугли, на большинство вопросов уже есть ответы.

Den Brown

Привет Сергей, 

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

Все что я могу подсказать, это дать ссылки на литературу по отчетам. У SF есть спец учебники по всем требуемым темам. 

ВОт Analytics workbook:
[url]http://www.salesforce.com/us/developer/docs/workbook_analytics/index.htm[/url]

также базовые знания по отчетам есть в фундаменталс воркбук:
[url]http://www.salesforce.com/us/developer/docs/fundamentals/index.htm[/url]

и главное, попробуй сформулировать свой вопрос на английском и погугли, на большинство вопросов уже есть ответы.

В принципе конечно можно подтягивать данные из связанных объектов.
Для этого стоит посмотреть в сторону FORMULA type Fields. В них можно обращаться к связанным объектам.
Также как вариант (костыль) можно при создании (апдейте) кастомного объекта повесить триггер, который будет заполнять "служебные" поля нужной информацией, которую потом можно показывать в репортах.

Dmitry Shnyrev

В принципе конечно можно подтягивать данные из связанных объектов.
Для этого стоит посмотреть в сторону FORMULA type Fields. В них можно обращаться к связанным объектам.
Также как вариант (костыль) можно при создании (апдейте) кастомного объекта повесить триггер, который будет заполнять "служебные" поля нужной информацией, которую потом можно показывать в репортах.

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

Строить приложение и структуру базы данных нужно исходя из репортов, которые планируется использовать.

Я то думал что репорты это последнее дело, а как оказалось на "самом верхнем уровне" (как-то было дело наша компания разрабатывала что-то непосредственно для самого SF) планирование разработки начинается именно с определения типов и вида репортов, а затем под данные репорты строится модель данных. Оказывается это актуальная проблема, как в случае Сергея.

Dmitry Shnyrev

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

[b]Строить приложение и структуру базы данных нужно исходя из репортов, которые планируется использовать.[/b]

Я то думал что репорты это последнее дело, а как оказалось на "самом верхнем уровне" (как-то было дело наша компания разрабатывала что-то непосредственно для самого SF) планирование разработки начинается именно с определения типов и вида репортов, а затем под данные репорты строится модель данных. Оказывается это актуальная проблема, как в случае Сергея.

Dmitry Shnyrev

Строить приложение и структуру базы данных нужно исходя из репортов, которые планируется использовать.

<img src="{SMILIES_PATH}/icon_e_surprised.gif" alt=":o" title="Удивлён" /> Это отрезвляющая мысль. Не слишком ли категоричная? Строить приложение и структуру базы данных нужно исходя из бизнес процессов, которые нужно "описать" в приложении, и имеющихся у нас технических возможностей. Но нужно и учитывать потребности будущих отчетов.
Но "учитывать потребности отчетов" и "Строить ... исходя из репортов" - это все таки разные вещи. Но в этом что-то есть, нужно эту мысль "Строить ... исходя из репортов" хорошенько "продумать" потому что она уводит нас в другую тему: а что есть Репорт? насколько он отражает содержание бизнес процессов? На каком этапе должны готовится требования в Репортам?

Den Brown

[quote="Dmitry Shnyrev"]

[b]Строить приложение и структуру базы данных нужно исходя из репортов, которые планируется использовать.[/b]

[/quote]
 <!-- s:o --><img src="{SMILIES_PATH}/icon_e_surprised.gif" alt=":o" title="Удивлён" /><!-- s:o --> Это отрезвляющая мысль. Не слишком ли категоричная? Строить приложение и структуру базы данных нужно исходя из бизнес процессов, которые нужно "описать" в приложении, и имеющихся у нас технических возможностей. Но нужно и учитывать потребности будущих отчетов.
Но "учитывать потребности отчетов" и "Строить ... исходя из репортов" - это все таки разные вещи. Но в этом что-то есть, нужно эту мысль "Строить ... исходя из репортов" хорошенько "продумать" потому что она уводит нас в другую тему: а что есть Репорт? насколько он отражает содержание бизнес процессов? На каком этапе должны готовится требования в Репортам?

Согласен, я точно также отреагировал.
Не то чтобы я теперь стал поклонником данной системы, но в это действительно что-то рациональное есть. Суть любой приложения на SF - это в конечном итоге получить какие-то отчеты. Это же бизнес, здесь все должно быть завязано на промежуточные, итоговые и какие там еще бывают отчеты (даже если мы пока об этом не задумывались). И вот какие данные должны быть представлены в этих отчетах стоит задуматься, чтобы создать под них соответствующие объекты и своевременно их заполнить.

Конечно как выход, потом можно просто писать дополнительный код, который будет просчитывать базу, заполнять промежуточные данные и представлять их для отчетов, но это будет уже костыль.

Так что не призываю на этом зациклиться, но запомнить мне кажется это стоит и задать заказчику вопрос на этапе программирования я думаю будет не лишним.

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

Dmitry Shnyrev

Согласен, я точно также отреагировал. 
Не то чтобы я теперь стал поклонником данной системы, но в это действительно что-то рациональное есть. Суть любой приложения на SF - это в конечном итоге получить какие-то отчеты. Это же бизнес, здесь все должно быть завязано на промежуточные, итоговые и какие там еще бывают отчеты (даже если мы пока об этом не задумывались). И вот какие данные должны быть представлены в этих отчетах стоит задуматься, чтобы создать под них соответствующие объекты и своевременно их заполнить.

Конечно как выход, потом можно просто писать дополнительный код, который будет просчитывать базу, заполнять промежуточные данные и представлять их для отчетов, но это будет уже костыль.

Так что не призываю на этом зациклиться, но запомнить мне кажется это стоит и задать заказчику вопрос на этапе программирования я думаю будет не лишним.

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