ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ
Данная непредварительная заявка на патент США является частичным продолжением непредварительной заявки на патент США за номером 10/262,487 (Номер дела поверенного №57084-00532USPT), поданной 30 сентября 2002, по которой заявлен приоритет по дате подачи предварительной заявки на патент США за номером 60/371,488 (Номер дела поверенного №57084-00532USPL), поданной 10 апреля 2002. По данной непредварительной заявке на патент США дополнительно заявлен приоритет по дате подачи предварительной заявки на патент США за номером 60/371,488 (Номер дела поверенного № 57084-00532USPL). Предварительная заявка на патент США за номером 60/371,488 и непредварительная заявка на патент США за номером 10/262,487 полностью включены в настоящий документ посредством ссылки.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Область техники
Настоящее изобретение относится к вычислительной системе и способу, предназначенным для содействия с помощью средств электроники всем аспектам проектов, включая процесс представления проектных предложений, процесс представления заявки, процесс представления затрат и процесс управления выполнением, и конкретно, к управлению и анализу всех аспектов проектов с помощью электроники.
Предшествующий уровень техники
Корпорации, торгово-промышленные предприятия и другие типы предприятий в соответствии с правилами используют услуги поставщиков (продавцов) третьей стороны, чтобы оперировать различными торгово-промышленными функциями, например предоставлением товара или услуги. Обычно эти торгово-промышленные функции привлеченных внешних ресурсов осуществляют при наличии соглашения о "проекте", "дополнении штатным персоналом" или "консультировании" (в дальнейшем все вместе обозначены как "проектная работа") между покупателем и продавцом. Различные задачи, включенные в проектную работу, такие как обязательства продавца, руководство проектом, управление ресурсами и бухгалтерский расчет по проекту, могут быть чрезвычайно сложными, с привлечением множества организационных подразделений покупателей, например отделов по закупкам, финансам, операционных, юридических, людских ресурсов, безопасности и организации управления проектом.
Из-за сложности проектной работы общепринятым в современной среде торгово-промышленной деятельности стало использование многочисленных систем и процессов для содействия управлению проектной работой. Например, обычно отдельные системы и процессы используют для одного или более аспектов проектной работы таких, как квалификация продавца, предложение цены покупателем, ответ на запрос предложения, оценка предложений, контроль за исполнением договора, контроль за исполнением этапов/поставок, формирование подтверждающих денежных документов и управление качеством. В настоящее время существуют функционирующие в оперативном режиме системы "предложений" и "торгов", предназначенные для обработки процессов запросов о торговых предложениях и ответов на запрос предложения, системы отслеживания управления проектом для обеспечения процессов административного контроля за исполнением этапов/поставок и системы обработки финансовых операций для управления процессом формирования денежных документов (ваучеров). Однако, отсутствует единая система, предназначенная для управления всеми аспектами проектной работы.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Чтобы преодолеть недостатки предшествующего уровня техники, воплощения настоящего изобретения обеспечивают комплексную вычислительную систему, поддерживающую возможности сети web, и способ, предназначенный для содействия и управления всеми аспектами проектной работы в системе управления предложением проекта. В вариантах осуществлений настоящего изобретения вычислительная система и способ способны формировать аналитические данные, относящиеся к системе управления предложением проекта. Данные о транзакциях, относящиеся к предложению и проекту, вводят в вычислительную систему посредством осуществляемого в оперативном режиме процесса представления предложений и заявок по проекту. При использовании сохраняемых в системе данных транзакций может быть сформирован фактически любой вид аналитических данных, связанных с отдельным проектом или многими проектами, выполненными одним или несколькими продавцами для одного или более покупателей.
В одном варианте осуществления аналитические данные могут включать в себя совокупные данные транзакций, связанные со многими проектами, многими продавцами и/или многими покупателями. В других вариантах осуществления аналитические данные могут включать в себя статистические данные, вычисленные как функции данных транзакций. Если аналитические данные формируют на основании данных транзакций, связанных со многими покупателями, данные транзакций сохраняют в центральной базе данных, которая конфигурирована для приема по меньшей мере части индивидуальных данных транзакций, сохраняемых в системе баз данных покупателей, продавцов или администраторов.
В примерных воплощениях данные транзакций включают в себя по меньшей мере данные о предложении, которые вводят в поля данных о предложении в течение оперативного процесса предложения. Данные транзакций могут дополнительно включать в себя параметры отслеживания проекта, идентифицирующие один или более договорных условий проекта, связанных с техническими данными о предложении и о проекте, которые относятся к выполнению проекта продавцом. Параметры отслеживания проекта могут дополнительно включать в себя информацию о налогообложении, идентифицирующую облагаемые налогом компоненты проекта и суммы налогов, связанные с каждым из облагаемых налогом компонентов. В других вариантах осуществления данные транзакций могут дополнительно включать в себя информацию о подтверждающем денежном документе (гарантии платежа), которую в течение выполнения проекта покупатель и продавец вводят в поля данных, связанные с предложением и проектом.
В дополнительных примерных вариантах осуществления аналитические данные могут быть сформированы на основании данных транзакций исходя из типа запроса и информации, включенной в качестве части запроса. Например, запрос может включать в состав один или более фильтров, относящихся к свойствам профиля продавца, свойствам профиля покупателя, свойствам профиля проекта и/или свойствам профиля товара. Данные транзакций могут быть отфильтрованы с использованием включенных в состав фильтров, и отфильтрованные данные транзакций могут быть использованы для формирования аналитических данных. Аналитические данные могут быть представлены авторизованному пользователю на web-странице в области просмотра отчета по проекту.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Заявленное изобретение описано ниже со ссылкой на чертежи, которые показывают важные примерные варианты осуществления настоящего изобретения и которые включены в описание путем ссылки, при этом:
Фиг.1 - высокоуровневая функциональная схема процесса предложения проектной работы согласно настоящему изобретению;
Фиг.2 - схема сети для вычислительной системы согласно настоящему изобретению;
Фиг.2B - альтернативная схема сети для вычислительной системы согласно настоящему изобретению, реализованной на сети покупателя;
Фиг.3А и 3B - физическая архитектура сети вычислительной системы согласно настоящему изобретению;
Фиг.4A-4D - примерные домашние web-страницы, связанные с каждым из пользовательских модулей, показанных на фиг.2A и 2B;
Фиг.5 - блок-схема, иллюстрирующая примерные этапы для включения в процесс предложения проектной работы в соответствии с вариантами осуществления настоящего изобретения;
Фиг.6 - содействие электронными средствами процессу квалификации продавца для определения типа проектной работы, которую обеспечивает продавец и/или требует покупатель, и определения подходящих продавцов для покупателей в соответствии с вариантами осуществления настоящего изобретения;
Фиг.7 - блок-схема, иллюстрирующая примерные этапы определения подходящего продавца для покупателя в соответствии с вариантами осуществления настоящего изобретения;
Фиг.8 - выборочная обработка информации, включенная в осуществление ответа на запрос предложения и различные пользовательские функции, ответственные за обработку информации;
Фиг.9 - блок-схема, иллюстрирующая примерные этапы, предназначенные для определения и распределения различных ресурсов, включенных в процесс проектной работы в соответствии с вариантами осуществления настоящего изобретения;
Фиг.10 - таблицы базы данных, иллюстрирующие определение и распределение пользовательских функций в соответствии с вариантами осуществления настоящего изобретения;
Фиг.11 - примерное экранное представление распределения ресурсов на пользовательские функции;
Фиг.12 - блок-схема, иллюстрирующая примерные этапы для определения и распределения пользовательских функций в течение транзакции по предложению или проекту в соответствии с вариантами осуществления настоящего изобретения;
Фиг.13А и 13B - блок-схемы, иллюстрирующие примерные этапы для управления на основе пользовательских функций последовательностью действий (документооборотом), имеющим отношение к транзакциям по предложению или проекту в соответствии с вариантами осуществления настоящего изобретения;
Фиг.14 - блок-схема, иллюстрирующая примерные этапы для изменения распределения пользовательских функций в соответствии с вариантами осуществления настоящего изобретения;
Фиг.15 - схема потоков данных, иллюстрирующая инструментальное средство создания шаблона предложения и инструментальное средство создания запроса предложения для формирования запроса предложения для конкретного проекта в соответствии с вариантами осуществления настоящего изобретения;
Фиг.16A-16D - блок-схемы, иллюстрирующие примерные этапы создания шаблона предложения, запроса предложения на основе шаблона предложения и ответа на запрос предложения на основе запроса предложения;
Фиг.17 - таблица базы данных, иллюстрирующая иерархический перечень элементов (товаров/услуг) предложения, на основе которого могут быть созданы шаблоны предложения;
Фиг.18 - блок-схема, иллюстрирующая примерные этапы для доступа к иерархическому перечню элементов предложения для того, чтобы создать шаблон предложения;
Фиг.19 - экранное представление, иллюстрирующее создание шаблона предложения;
Фиг.20 - схема последовательности, иллюстрирующая примерные этапы для формирования запроса предложения с использованием шаблона предложения в соответствии с вариантами осуществления настоящего изобретения;
Фиг.21-22 - экранные представления, иллюстрирующие различные типы элементов предложения, связанных с конкретным шаблоном предложения, которые могут быть выбраны для включения в предложение согласно типу шаблона предложения;
Фиг.23 - блок-схема, иллюстрирующая примерные этапы для управления передачей квалифицированным продавцам информации о запросе предложения;
Фиг.24 - экранное представление, иллюстрирующее выбор квалифицированных продавцов для приема запроса предложения;
Фиг.25 - блок-схема, иллюстрирующая примерные этапы в процессе ответа продавца на запрос предложения в соответствии с вариантами осуществления настоящего изобретения;
Фиг.26-28 - экранные представления, иллюстрирующие процесс ответа продавца на запрос предложения;
Фиг.29 - таблицы базы данных, иллюстрирующие взаимосвязь между запросом предложения и данными ответа продавца на запрос предложения в соответствии с вариантами осуществления настоящего изобретения;
Фиг.30 - экранное представление, иллюстрирующее различные функциональные возможности обработки предложения, предоставленные покупателю;
Фиг.31 - схема потоков данных, иллюстрирующая электронное обеспечение оценки (ранжирования) ответа продавца на запрос предложения в соответствии с вариантами осуществления настоящего изобретения;
Фиг.32 и 33 - блок-схемы, иллюстрирующие примерные этапы ранжирования ответов продавца на запрос предложения в соответствии с вариантами осуществления настоящего изобретения;
Фиг.34A-34E - экранные представления, иллюстрирующие примерный процесс ранжирования ответа на запрос предложения;
Фиг.35 - таблицы базы данных, иллюстрирующие взаимосвязь между запросом предложения, ответами продавца на запрос предложения и ранжированием ответов продавца на запрос предложения, в соответствии с вариантами осуществления настоящего изобретения;
Фиг.36 - блок-схема, иллюстрирующая процесс повторного назначения цены продавцом на основе ранжирования ответа продавца на запрос предложения в соответствии с вариантами осуществления настоящего изобретения;
Фиг.37 - блок-схема, иллюстрирующая примерные этапы в процессе начальной установки администрирования проекта, в котором проект выдается продавцу, а сроки и условия договора проекта финализируются и вводятся в вычислительную систему, чтобы отслеживать этапы работы и поставки в соответствии с вариантами осуществления настоящего изобретения;
Фиг.38 - блок-схема, иллюстрирующая примерные этапы для утверждения назначенных ресурсов для проекта в соответствии с вариантами осуществления настоящего изобретения;
Фиг.39A - экранное представление, иллюстрирующее примерные функциональные возможности управления проектом для покупателя;
Фиг.39B - экранное представление, иллюстрирующее примерные функциональные возможности управления проектом для продавца;
Фиг.40A - экранное представление, иллюстрирующее интерфейс для ввода примерной информации о налогообложении для проекту;
Фиг.40B - экранное представление, иллюстрирующее примерную информацию о представлении заявок, включая введенную информацию о налогообложении для проекта;
Фиг.40C - блок-схема, иллюстрирующая примерные этапы для ввода и обработки информации о налогообложении для проекта;
Фиг.41 - таблицы базы данных, иллюстрирующие различные компоненты управления проектом, которыми оперирует вычислительная система настоящего изобретения;
Фиг.42 - экранное представление, иллюстрирующее типы элементов данных, касающихся обязательств, которые могут управляться посредством вычислительной системы настоящего изобретения;
Фиг.43 - блок-схема, иллюстрирующая примерные этапы для ввода для проекта рабочего времени подрядчика в соответствии с вариантами осуществления настоящего изобретения;
Фиг.44-46 - экранные представления, иллюстрирующие примерный процесс отслеживания времени;
Фиг.47 - таблицы базы данных, иллюстрирующие отслеживание проектных сдач/поставок и ваучеров (обязательств по платежам) в соответствии с вариантами осуществления настоящего изобретения;
Фиг.48 - электронная поддержка процесса ваучеризации платежа для представления на рассмотрение и утверждения ваучеров (гарантий платежа) и создания документа, уполномачивающего платеж (ваучера) в соответствии с вариантами осуществления настоящего изобретения;
Фиг.49 - блок-схема, иллюстрирующая процесс платежа с ваучером (гарантией платежа) в соответствии с вариантами осуществления настоящего изобретения;
Фиг.50 - таблица базы данных, иллюстрирующая формирование подлежащих оплате ваучеров в соответствии с вариантами осуществления настоящего изобретения;
Фиг.51 - экранное представление, иллюстрирующее финансовые данные проекта;
Фиг.52 - блок-схема, иллюстрирующая обмен информации между покупателем, продавцом и системой для содействия анализу информации;
Фиг.53 - примерные функциональные возможности для ввода данных о выполнении проекта, относящихся к выполнению проектов в системе в соответствии с вариантами осуществления настоящего изобретения;
Фиг.54-56 - блок-схемы, иллюстрирующие примерные этапы для ввода данных о выполнении проекта;
Фиг.57 - таблицы базы данных, иллюстрирующие хранение данных о выполнении проекта в соответствии с вариантами осуществления настоящего изобретения;
Фиг.58 - примерные данные транзакций, относящиеся к процессу предложения/проекта, сохраняемые в системе баз данных согласно настоящему изобретению;
Фиг.59 - примерная передача данных транзакций из множества баз данных покупателей в центральную базу данных;
Фиг.60 - электронная поддержка анализа и составления отчетов относительно данных транзакций в соответствии с вариантами осуществления настоящего изобретения;
Фиг.61-67 - блок-схемы, иллюстрирующие примерные этапы анализа данных транзакций и обеспечения аналитических данных в соответствии с вариантами осуществления настоящего изобретения;
Фиг.68 - электронная поддержка процесса фильтрования для осуществления фильтрования данных транзакций, чтобы получить аналитические данные, связанные с отфильтрованными данными транзакций в соответствии с вариантами осуществления настоящего изобретения;
Фиг.69 - схема последовательности, иллюстрирующая примерные этапы фильтрования данных транзакций и формирования аналитических данных на основе отфильтрованных данных транзакций в соответствии с воплощениями настоящего изобретения;
Фиг.70 - экранное представление, иллюстрирующее примерные типы отчетов проекта для формирования и отображения аналитических данных; и
Фиг.71-88 - экранные представления, иллюстрирующие примерные представления отчетов проекта, содержащие аналитические данные.
ПОДРОБНОЕ ОПИСАНИЕ ПРИМЕРНЫХ ВАРИАНТОВ ОСУЩЕСТВЛЕНИЯ
Многочисленные новаторские решения настоящей патентной заявки описаны ниже со ссылками на примерные варианты осуществления. Однако понятно, что эти варианты осуществления предоставляют только ряд примеров из множества полезных использований новаторских решений. В целом, формулировки, сделанные в описании настоящей заявки, не обязательно ограничивают какие-либо из различных заявленных изобретений. Кроме того, некоторые формулировки можно применять к некоторым признакам изобретения, но не к другим.
В соответствии с вариантами осуществления настоящего изобретения, продавец является произвольным поставщиком товаров и/или услуг, покупатель является произвольным покупателем товаров и/или услуг, подрядчик является ресурсом, используемым продавцом для проектной работы, и администратор является сторонним (третьей стороны) администратором системы или администратором проекта, нанятым покупателем. Покупатели могут запрашивать предложения от продавцов на конкретный товар и/или услугу (в дальнейшем обозначаемым как проект) в форме, заданной покупателем с использованием запроса предложения, сформированного на основании заранее установленного перечня элементов предложения, относящихся к типу проекта. Поэтому ответы на запрос предложения, представленные на рассмотрение от продавцов, имеют такую же форму, предоставляя возможность эффективной и действенной оценки ответов на запрос предложения. Варианты осуществления настоящего изобретения дополнительно объединяют процесс предложения с управлением проектом, чтобы дать возможность покупателю, продавцу, подрядчику и администратору отслеживать выполнение проекта после того, как предложение принято.
На Фиг.1 показано высокоуровневое функциональное изображение процесса предложения, включенного в настоящее изобретение. Данные 210 запроса предложения, связанные с конкретным запросом 200 предложения, поставляют от покупателя 50 в систему 30 управления проектным предложением. Покупатель 50 может быть отдельным лицом, объектом торгово-промышленной деятельности (или предприятием) или любого другого вида покупателем 50, который требует выполнения проекта. Данные 210 запроса предложения, принятые на системе 30 управления проектным предложением, находятся в форме, заранее определенной покупателем 50. Например, форма может включать один или несколько элементов предложения, выбранных из конфигурируемого заранее установленного перечня элементов предложения для конкретного типа проекта, и данные 210 запроса предложения могут относиться к одному или нескольким из этих выбранных элементов предложения.
Данные 210 запроса предложения система 30 управления проектным предложением (СУПП) форматирует и передает в качестве запроса 200 предложения одному или нескольким продавцам 10a... 10n для запрашивания соответствующих ответов на запросы 220 о предложении. Например, продавец 10 может быть отдельным лицом 10a, предприятием 10b или любым другим продавцом 10n, способным выполнять запрошенный проект. Ответы 220 на запрос предложения представляют от продавцов 10 в систему 30 управления проектным предложением для рассмотрения прежде, чем пересылать покупателю 50 надлежащие ответы 2201 на запрос предложения. Например, система 30 управления проектным предложением может быть предварительно конфигурирована, чтобы побудить заполнение продавцом требуемых элементов ответа на запрос предложения в конкретном формате данных, чтобы дать возможность системе 30 выполнить некоторое фильтрование ответов 220 на запрос предложения. Таким образом, система 30 может гарантировать, что покупатель 50 принимает только те ответы 220 на запрос предложения, которые имеют необходимые данные для оценки предложения.
В соответствии с вариантами осуществления настоящего изобретения система 30 управления проектным предложением может быть осуществлена на основе вычислительной системы 100, как показано на Фиг.2A. Пользователь 5 входит в вычислительную систему 100 через сеть 40 передачи данных с помощью web-браузера 20. Пользователь 5 может представлять собой любое лицо, ассоциируемое с продавцом 10, покупателем 50, администратором 80 (например, сторонним или нанятым покупателем администратором) или подрядчиком 15, назначенным на проект. В качестве примера, а не ограничения сеть 40 передачи данных может быть сетью Интернет (Internet) или Интранет (Intranet), и web-браузер 20 может быть любым доступным web-браузером или любым типом соединения с поставщиком услуг Интернет (ISP), которое обеспечивает доступ к сети 40 передачи данных. Пользователи-продавцы 5 осуществляют доступ к вычислительной системе посредством браузера 20b продавца, пользователи-покупатели 5 осуществляют доступ к вычислительной системе посредством браузера 20a покупателя, пользователи 5 подрядчика осуществляют доступ к вычислительной системе посредством браузера 20c подрядчика, и административные пользователи 5 осуществляют доступ к вычислительной системе через административный браузер 20d. Пользователи 5 осуществляют доступ к вычислительной системе 100 через web-сервер 120 или 125, который способен рассылать web-страницы на браузер 20a продавца, браузер 20b покупателя, браузер 20c подрядчика и административный браузер 20d соответственно.
Web-сервер 120 предложения дает возможность продавцам 10, покупателям 50, подрядчикам 15 и администраторам 80 взаимодействовать с системой 150 баз данных, поддерживающей данные, относящиеся к продавцам 10, покупателям 50, подрядчикам 15 и администраторам 80. Данные, относящиеся к каждому из продавцов 10, покупателей 50, подрядчиков 15 и администраторов 80, могут быть сохранены в одной базе данных 155, во многих общедоступных базах данных 155 или в отдельных базах данных 155 на сервере 150 базы данных с целями защиты и удобства, что показано на чертеже. Например, система баз данных 150 может быть распределенной в одном или нескольких местонахождениях в зависимости от местонахождения и предпочтения покупателей 50, продавцов 10, администраторов 80 и подрядчиков 15.
Пользовательский интерфейс для пользователей-продавцов 5 обеспечивает web-сервер 120 предложения посредством модуля 115 продавца. Например, модуль 115 продавца может заполнять web-страницы, помещенные в браузер продавца 20b, используя данные, сохраняемые в конкретной базе данных 155b продавца. Пользовательский интерфейс для пользователей-покупателей 5 обеспечивает web-сервер предложения 120 посредством модуля 110 покупателя. Например, модуль 110 покупателя может заполнять web-страницы, помещенные в браузер 20a покупателя, используя данные, сохраняемые в конкретной базе данных 155a покупателя. Пользовательский интерфейс для пользователей-подрядчиков 5 обеспечивает web-сервер 120 посредством модуля 130 подрядчика. Например, модуль 130 подрядчика может заполнять web-страницы, помещенные в браузер 20c подрядчика, используя данные, сохраняемые в базе данных 155c подрядчика. Пользовательский интерфейс для административных пользователей 5 обеспечивает web-сервер предложения 120 посредством административного модуля 135. Например, административный модуль 135 может заполнять web-страницы, помещенные в административный браузер 20d, используя данные, сохраняемые в базе данных 155d администратора. Следует отметить, что каждый модуль 115 продавца, модуль 110 покупателя, модуль 130 подрядчика и административный модуль 135 может включать в себя любые аппаратные средства, программное обеспечение и/или программно-аппаратные средства, которые необходимы, чтобы исполнять функции модуля 115 продавца, модуля 110 покупателя, модуля 130 подрядчика и административного модуля 135, и может быть осуществлен в качестве части web-сервера 120 предложения или внутри дополнительного сервера (не показан).
Вычислительная система 100 также обеспечивает дополнительный пользовательский интерфейс для административных пользователей 5 посредством административного web-сервера 125. Административный web-сервер 125 дает возможность администраторам 80 взаимодействовать с базой данных 160 верхнего уровня, поддерживающей данные, относящиеся к продавцам 10, покупателям 50 и подрядчикам 15, зарегистрированным с помощью вычислительной системы 100. Например, база данных 160 верхнего уровня может поддерживать данные об оценке продавца или квалификационные данные продавца 162, определенные покупателем данные о критериях оценки продавца 164 и данные о повторном распределении подрядчика 166.
Для осуществления доступа к информации, относящейся к продавцам 10, административный web-сервер 125 использует модуль 145 продавца для помещения в административный браузер 20d web-страниц, относящихся к продавцам 10. Например, модуль 145 продавца может осуществлять доступ к квалификационной информации 162 продавца, чтобы определить подходящих продавцов 10 для конкретного покупателя 50 или для конкретной отрасли промышленности. Подобным образом административный web-сервер 125 может помещать в административный браузер 20d web-страницы, относящиеся к определенной покупателем информации о критериях оценки продавца 164, посредством модуля 140 покупателя, чтобы определить подходящих продавцов 10 для конкретного покупателя 50. Модуль 148 подрядчика дает возможность администраторам 80 осуществлять доступ к данным 166 о повторном распределении подрядчика, введенным подрядчиками 15 посредством сервера 120 предложения и извлеченным в базу данных 160 верхнего уровня из базы данных 155 подрядчика. Данные 166 о повторном распределении могут включать в себя, например, признак подвижности подрядчика, требуемые географические зоны, навыки подрядчика, желательную оплату и другую информацию о подрядчике, которая может быть использована для помощи администраторам 80 в определении подходящих продавцов 10 для покупателей 50.
В другом варианте осуществления, как показано на Фиг.2B, вычислительная система 100 может быть реализована только на сети покупателя. На Фиг.2B показано, что пользователи-продавцы 5 входят в вычислительную систему 100 через сеть 40 передачи данных посредством браузера 20b продавца, как на Фиг.2A. Однако web-сервер 120 по Фиг.2B является web-сервером покупателя, управляемым и используемым отдельным покупателем. Система 150 баз данных хранит только данные о покупателе, связанные с этим конкретным покупателем, и только данные о продавце, подрядчике и администраторе, имеющие отношение к этому конкретному покупателю. Например, в системе 150 баз данных хранятся квалификационные данные продавца только для тех продавцов, которые определены покупателем.
На Фиг.3A показано примерное оборудование физической сети для осуществления вычислительной системы 100. Пользователь-продавец, пользователь-покупатель, пользователь-подрядчик или административный пользователь осуществляют доступ к web-серверу 120 вычислительной системы 100 посредством соединения соответственно компьютера 60a, 60b, 60c или 60d с сетью передачи данных 40. Каждый компьютер 60a-60d может быть, например, персональным компьютером, портативной ЭВМ, компьютером, соединенным с беспроводным устройством для удаленного доступа к сети передачи данных, переносным беспроводным устройством, обеспечивающим web-браузер, который способен осуществлять доступ к сети передачи данных, или другого типа устройства, в котором осуществлен web-браузер. Web-сервер 120 может быть, например, сервером информационной службы Интернет (IIS) компании Microsoft. Web-сервер 120 соединяется с соответствующей системой 150 баз данных в зависимости от типа пользователя. Система 150 баз данных может быть осуществлена, например, одним или несколькими SQL-серверами.
На Фиг.3B показаны примерные функциональные возможности, осуществленные в оборудовании физической сети для вычислительной системы 100. Пользовательский компьютер 60 может осуществлять доступ к сети 40 передачи данных, используя web-браузер 66, который постоянно находится в запоминающей среде 64 компьютера. Например, запоминающей средой может быть накопитель на дисках, оперативное запоминающее устройство (ОЗУ, RAM), постоянное запоминающее устройство (ПЗУ, ROM), компакт-диск, гибкий диск, накопитель на (магнитной) ленте или запоминающая среда любого другого типа. Процессор 62 (например, микропроцессор или микроконтроллер) компьютера 60 загружает и исполняет web-браузер 66 для осуществления доступа к сети передачи данных 40.
После ввода в компьютер унифицированного указателя информационного ресурса (URL) web-сервера 120 создается соединение между компьютером 60 и web-сервером 120. Web-сервер 120 помещает web-страницы 61 в компьютер 60 для просмотра пользователем на устройстве 65 пользовательского интерфейса. В одном варианте осуществления устройством 65 пользовательского интерфейса является экран 15 компьютера, соединенный с компьютером 60. Например, как только правомочность пользователя подтверждена (например, посредством ввода имени и пароля пользователя), пользователь может осуществлять просмотр одной или нескольких web-страниц 61 на экране 65 компьютера, причем каждая содержит подсказки пользователю для ввода различной информации в вычислительную систему 100. Для передачи через сеть 40 передачи данных на web-сервер 120 пользователь может вводить информацию в компьютер 60 с помощью интерфейса 68 ввода/вывода (I/O) и любого типа устройства 70 ввода данных такого, как "мышь", клавиатура, световое перо, сенсорный экран (не показан) или с помощью программного обеспечения распознавания речи (не показано).
На web-сервере 120 процессор (например, микропроцессор или микроконтроллер) загружает и исполняет компьютерные команды, постоянно находящиеся (резидентные) в программных модулях 128, сохраняемых в запоминающей среде 124, которая может быть запоминающей средой любого типа, как описано выше в связи с запоминающей средой 64. Компьютерные команды могут быть созданы с использованием методов программирования произвольного типа, включая объектно-ориентированное программирование. Например, программные модули 128 могут содержать компьютерные команды для модулей продавца, модулей покупателя, модулей подрядчика и административных модулей (показанные на Фиг.2A и 2B) для заполнения web-страниц 61 для пользователей-продавцов, пользователей-покупателей, пользователей-подрядчиков и административных пользователей соответственно. На основании регистрации пользователя компьютера при входе в web-сервер 120 процессор 122 осуществляет доступ к соответствующему программному модулю 128, чтобы определить систему 150 баз данных, связанную с пользователем компьютера, и извлекает данные, связанные с пользователем компьютера, для заполнения web-страниц 61, предназначенных для отображения на экране 65 компьютера (для компьютера) 60. Кроме того, программные модули 128 могут быть дополнительно настроены для сохранения данных, принятых от пользователя компьютера, в системе 150 баз данных.
Примеры web-страниц 61, отображаемых пользователям-покупателям, пользователям-продавцам, пользователям-подрядчикам и административным пользователям, показаны на Фиг.4A-4D соответственно. На Фиг.4A проиллюстрирована примерная домашняя страница 61a покупателя, отображаемая пользователю-покупателю после входа в систему и аутентификации (например, аутентификации с запросом и подтверждением) пользователя-покупателя. Как видно на Фиг.4A, имеется ряд системных возможностей, доступных пользователю-покупателю на домашней странице 6la покупателя. Например, пользователю-покупателю могут быть предоставлены гипертекстовые ссылки, чтобы обновлять их личный профиль в системе, создавать RFP/RFQ (запрос предложений/запрос на использование ресурсов) (упоминаемый здесь как запрос предложения), управлять текущими запросами предложений, утверждать ответ продавца на запрос предложения, чтобы выдавать предложение (проект) конкретному продавцу, обрабатывать текущий проект, рассматривать запросы предложения за прошлое время или осуществлять доступ к системе обработки ваучера (обязательства по платежам), чтобы просмотреть различные относящиеся к проекту запросы отслеживания событий, например хронометражные карты (карты контроля времени) подрядчика. Пользователь-покупатель может дополнительно через домашнюю страницу 6la покупателя осуществлять обновление данных, что касается системных модификаций, получать команды относительно переходов (навигации) в системе и входить в связь с системным администратором (например, сторонним администратором или администратором, нанятым покупателем) для помощи.
На Фиг.4A показано, что пользователю-покупателю на домашней странице 61a дополнительно предоставляют текущее состояние ожидающих рассмотрения предложений и проектов. Однако, должно быть понятно, что текущие действия могут быть отображены на последующих web-страницах, а не на домашней странице 61а. Например, пользователю-покупателю можно предоставить количество открытых запросов предложения (представленных на рассмотрение запросов предложения) и количество временно сохраняемых запросов предложения (созданных, но еще не представленных на рассмотрение запросов предложения). Посредством щелчка по кнопке открытого запроса предложения пользователь-покупатель может быть связан с другой web-страницей, отображающей перечень открытых запросов предложения с последующими ссылками на web-страницы, которые содержат фактические открытые запросы предложения. Следовательно, из домашней страницы 6la покупателя пользователь-покупатель может связаться с любой информацией, имеющей отношение к предложениям или проектам, к которым пользователь-покупатель имеет доступ.
На Фиг.4B проиллюстрирована примерная домашняя страница 61b продавца, содержащая ряд системных возможностей, доступных пользователю-продавцу. Например, домашняя страница 61b продавца может предоставлять ссылки, чтобы обновлять профиль продавца (например, типы товаров и/или услуг, которые поставляет продавец), отвечать на принятые запросы предложений, обрабатывать текущие проекты или осуществлять доступ к системе обработки ваучера, чтобы просматривать имеющиеся запросы о событиях завершения проекта или обрабатывать новые запросы о событиях завершения проекта. На Фиг.4B показано, что пользователю-продавцу также предоставляется текущее состояние ожидающих предложений и проектов. Например, пользователь-продавец может определить количество запросов предложений, на которые продавец должен отвечать, и количество временно сохраняемых ответов на запрос предложения, которые продавец еще не завершил. Из домашней страницы 61b продавца пользователь-продавец может осуществить ссылку на дополнительные web-страницы, чтобы завершить ответы продавца на запрос предложения или осуществлять доступ к заново принятому запросу предложения, чтобы начать ответ продавца на запрос предложения.
На Фиг.4C проиллюстрирована примерная домашняя страница 61c подрядчика, содержащая ряд системных возможностей, доступных подрядчику. Например, первый раз, когда пользователь-подрядчик входит на домашнюю страницу 61c подрядчика, пользователю-подрядчику может быть предложено согласиться с различными соглашениями работника, не являющегося служащим, прежде чем осуществить доступ к любой другой информации в системе. Каждое из соглашений работника не-служащего может быть отображено пользователю-подрядчику, и пользователю-подрядчику может быть предложено согласиться на условия или иначе принять условия соглашений прежде, чем продолжить. Как только пользователь-подрядчик заполнил все соглашения, пользователь-подрядчик может осуществлять доступ к системе отслеживания времени, чтобы ввести рабочее время подрядчика, обновить профиль квалификации или обеспечить предпочтения повторного распределения. В дополнение, текущие действия, связанные с пользователем-подрядчиком, также могут быть отображены пользователю-подрядчику на домашней странице 61c подрядчика, например, количество запрошенных интервью или интервью, предусмотренных графиком для дополнительных проектов.
На Фиг.4D проиллюстрирована примерная домашняя страница 61d администратора, содержащая ряд системных возможностей, доступных административному пользователю. Например, административный пользователь может осуществлять доступ к информации о покупателях, продавцах или подрядчиках, осуществлять ссылки на web-страницы, содержащие запросы предложений, которые нуждаются в утверждении, утверждать ответ на запрос предложения, чтобы назначить предложение конкретному продавцу, обрабатывать текущий проект или осуществлять доступ к системе обработки ваучеров (обязательств по платежам), чтобы просмотреть имеющиеся запросы продавца/подрядчика на утверждение деятельности по проекту, например хронометражной карты подрядчика. В дополнение, текущая деятельность административного пользователя также может быть отображена на домашней странице 61d администратора. Например, количество запросов предложения, ожидающих утверждения, количество новых запросов предложения и количество новых ответов продавца могут быть отображены административному пользователю. Из домашней страницы 61d администратора административный пользователь может осуществить ссылку на любую информацию, имеющую отношение к процессу предложения или управлению проектом, к которой имеет доступ административный пользователь. Например, если административный пользователь является сторонним администратором, то административный пользователь может иметь доступ к предложениям и проектам всех покупателей и продавцов, зарегистрированных с помощью системы. Однако, если административный пользователь является администратором, нанятым покупателем, то административный пользователь может иметь доступ только к предложениям и проектам, связанным с конкретным покупателем.
Примерные этапы в процессе 500 предложения/проекта, обрабатываемые системой управления предложениями проекта согласно настоящему изобретению, показаны на Фиг.5. Имеются несколько аспектов процесса предложения/проекта, которые обрабатывают прежде подаваемых на рассмотрение каких-либо запросов предложения (этап 505). Например, покупателю может быть желательно создать перечень подходящих продавцов для конкретных типов запросов предложения, чтобы уменьшить время обработки в течение запрашивания предложения, как описано более подробно ниже в связи с Фиг.6 и 7. В качестве другого примера покупателям, продавцам и администраторам может быть желательным задать конкретный персонал для обработки различных компонентов процесса предложения/проекта для эффективного направления (маршрутизации) сообщений и информации в течение процесса предложения/проекта, как описано более подробно ниже в связи с Фиг.8-14.
Как только вся деятельность по предварительному предложению завершена (этап 510), покупатель может создавать запрос предложения для проекта (этап 520), как будет описано более подробно ниже в связи с Фиг.15-29, и, если необходимо, подавать запрос предложения администратору для утверждения (этап 525), как будет описано более подробно ниже в связи с Фиг.20. Большинство компаний требуют утверждения запроса предложения для бюджетных целей. Однако, если покупателем является отдельное лицо или мелкое предприятие, то пользователь-покупатель, создающий запрос предложения, может не нуждаться в утверждении какой-либо другой стороной, чтобы подать запрос предложения.
Как только запрос предложения был утвержден, запрос предложения пересылают (например, сделав доступным продавцам с помощью системы с дополнительным уведомлением по электронной почте) подходящим продавцам (этап 530), как будет описано более подробно ниже в связи с Фиг.23, для того чтобы запрашивать продавцов об ответе на запрос предложения (этап 535). Каждый из ответов на запрос предложения оценивает покупатель, как будет описано более подробно ниже в связи с Фиг.32 и 33, для того чтобы определить, какой ответ продавца на запрос предложения является наиболее подходящим (этап 540). После того, как покупатель выбирает конкретного продавца для проекта, покупатель и продавец договариваются об окончательных условиях договора (этап 545), и эти условия договора могут быть загружены в систему с целями отслеживания проекта (этап 550), как будет описано более подробно ниже в связи с Фиг.37. После этого продавец выбирает конкретные ресурсы (подрядчиков) для проекта, и если условия проекта требуют утверждения ресурсов покупателем, то покупатель утверждает все распределенные ресурсы прежде, чем проект будет реализован (этап 555), как описано более подробно ниже в связи с Фиг.38.
Как только все действия по предложению завершены (этап 515), система далее способна к обработке действий "после предложения" (этап 560), чтобы отслеживать выполнение проекта и оплату ваучеров (обязательств по платежам) в течение проекта. Например, продавец и подрядчики, распределенные на проект, могут вводить в систему (этап 565) отработанное рабочее время и расходы для формирования подлежащих оплате обязательств по платежам, которые должны быть представлены покупателю через систему, как описано более подробно ниже в связи с Фиг.43. После приема ваучеров покупатель и/или администратор могут рассматривать и утверждать ваучеры для оплаты продавцу (этапы 570 и 575), как будет описано более подробно ниже в связи с Фиг.49. Другие параметры отслеживания проекта также могут быть введены в систему, чтобы отслеживать характеристики продавца вплоть до закрытия проекта (этап 580), как описано более подробно ниже в связи с Фиг.39 и 40. Каждый из основных компонентов процесса предложения/проекта (предварительная деятельность по предложению, деятельность по предложению и деятельность после предложения) описана отдельно ниже. Дополнительно анализ и составление отчетов о данных, накопленных в течение процесса предложения/проекта, также описаны отдельно ниже.
ПРЕДВАРИТЕЛЬНАЯ ДЕЯТЕЛЬНОСТЬ ПО ПРЕДЛОЖЕНИЮ
Как описано выше, покупателю 50 может быть желательным предварительно определить подходящих продавцов 10 для конкретных типов проектов, чтобы уменьшить объем обработки, требуемой для каждого представленного запроса предложения. Согласно Фиг.6, чтобы содействовать определению продавца для покупателей, вычислительная система 100 может давать возможность покупателям 50 устанавливать для продавцов определяемые покупателем данные 164 о критериях оценки продавца и хранить эти данные 164 в базе данных 160 верхнего уровня в основном перечне 161 покупателей. Вычислительная система 100 может дополнительно получать подходящие квалификационные данные 162 продавца от продавцов 10 и сохранять данные 162 в базе данных 160 верхнего уровня в основном перечне 163 продавцов.
Например, квалификационные данные 162 продавца могут идентифицировать конкретные товары и/или услуги, которые предоставляет продавец 10, и конкретные географические зоны, в которые продавец 10 способен поставлять эти товары и/или услуги, наряду с другой информацией о продавце, например размер (предприятия) продавца, имеет ли продавец страхование, аттестован (сертифицирован) ли продавец в некоторых отраслях промышленности и т.д. Определяемые покупателем данные 164 о критериях оценки продавца могут идентифицировать конкретные товары и/или услуги, которые покупатель 50 запрашивает, конкретные географические области, в которых(е) покупатель 50 запрашивает товары и/или услуги, и другие ограничения покупателя, например предпочтительный размер (предприятия) продавца, необходимые потребности страхования продавца, необходимые аттестации (легализации) продавца и т.д.
На основании квалификационных данных 162 продавца и определяемых покупателем данных 164 о критериях оценки продавца вычислительная система 100 может определить, какие продавцы 10 имеют необходимые характеристики для покупателей 50 и предоставляют квалификационную информацию 170 о продавце (например, имя, адрес и любую другую информацию о продавце, которая требуется покупателю) покупателю 50 для рассмотрения. Если покупатель 50 или дополнительно по выбору администратор 80 утверждает продавца 10, то покупатель 50 может добавлять информацию 170 о продавце к перечню 158 продавцов, который сохраняют в базе данных 155a покупателя. Кроме того, информация 172 о продавцах для тех продавцов 10, которых покупатель 50 предварительно квалифицировал подходящими, также может быть сохранена в перечне 158 продавцов. Кроме того, основной экземпляр перечня 158 продавцов (то есть основной перечень продавцов для покупателей 165) может быть сохранен в базе данных 160 верхнего уровня с целями резервирования и обновления.
Информация 174 о покупателе (например, имя, адрес и другая информация, которую покупатель соглашается предоставлять) также может быть загружена в базу данных 155b продавца для сохранения в перечне 159 покупателей. Кроме того, основной экземпляр перечня 159 покупателей (то есть основной перечень покупателей для продавцов 167) может быть сохранен в базе данных 160 верхнего уровня с целями резервирования и обновления. Однако, понятно, что если вычислительная система 100 осуществлена лишь в сети покупателя, то база данных 160 верхнего уровня будет сохранять основные экземпляры 165 и 167, и покупатель 50 будет осуществлять квалификацию продавца, используя только информацию 172 о продавцах, известную покупателю 50 или непосредственно предоставленную покупателю 50 продавцом 10. Подробная информация о квалификации продавцов 10 для покупателей 50 на основании квалификационных данных 162 продавцов и определяемых покупателем данных 164 о критериях оценки продавца содержится в совместно поданной и совместно переуступленной заявке на патент США за номером 10/141,801, которая полностью включена в настоящий документ посредством ссылки.
Примерные этапы квалификации продавцов для покупателей показаны на Фиг.7. Как только определенная покупателем информация о критериях оценки продавца установлена (этап 700) и от продавца принята (этап 710) квалификационная информация продавца, определенную покупателем информацию о критериях оценки продавца сравнивают с квалификационной информацией продавца (этап 720), чтобы определить, соответствует ли квалификационная информация продавца информации о критериях продавца, определенной покупателем (этап 730). Если соответствует, продавца и покупателя уведомляют относительно соответствия (этап 740), и если покупатель утверждает продавца, то информацию о продавце, связанную с продавцом, сохраняют в перечне продавцов покупателя для последующего использования в подготовке запросов предложения (этап 750). Кроме того, информация о покупателе может быть сохранена в перечне покупателей продавца для справочной информации при приеме запросов предложения и подготовке ответа на запрос предложения (этап 760).
Однако, если квалификационная информация продавца не соответствует определенной покупателем информации о критериях продавца (этап 730), то система определяет, необходима ли дополнительная квалификационная информация продавца, чтобы определить подходящего продавца для покупателя (этап 770). Если необходима, то продавца запрашивают о предоставлении этой дополнительной квалификационной информация продавца (этап 780), чтобы определить подходящего продавца для покупателя (этап 710). Если информация не является необходимой, продавца не квалифицируют для покупателя (этап 790) и продавца не добавляют к перечню покупателя.
В дополнение к квалификации продавцов для покупателей, продавцам, покупателям и администраторам может быть желательным указать определенный персонал для обработки различных аспектов процесса предложения/проекта для того, чтобы синхронизировать обработку обмена информацией по линиям связи, данных и транзакций между многими инструментальными комплексами или платформами пользователей. Например, согласно Фиг.8 процесс предложения/проекта обычно требует включения широкого спектра обработки информации и функциональных отделов, чтобы содействовать руководству и управлению процессом предложения/проекта. Такая обработка информации может включать в себя, например, рассылку запроса предложения, ответы продавца на запрос предложения, размещение предложения (оценка и решение о назначении), представление ресурса на рассмотрение, представление хронометражной карты, отслеживание сдач/поставок и ваучеризация платежей. Каждый из этих компонентов обработки информации может быть обработан одним или несколькими различными отдельными лицами или отделами, такими как заместитель директора по производственным вопросам (COO), отдел людских ресурсов (кадров), отдел обработки операций проекта пользователя и финансовых операций. Чтобы удовлетворять этой функциональной потребности, вычислительная система настоящего изобретения может предоставлять возможность общедоступной рабочей среды, в которой покупатель, продавец и/или администратор могут задавать индивидуальные пользовательские функции, которые необходимы для участия в процессе предложения/проекта и задавать персонал (ресурсы) для каждой из пользовательских функций для всех предложений/проектов или для конкретных предложений/проектов.
На Фиг.9 проиллюстрированы примерные этапы для определения позиций пользовательских функций и распределения персонала по позициям пользовательских функций для продавца, покупателя или администратора. Первоначально, продавец, покупатель или администратор определяют конкретные позиции пользовательских функций, которые необходимы для процесса предложения/проекта (этап 900). Например, как показано на примерной web-странице покупателя Фиг.11, у покупателя может иметься потребность в нескольких различных категориях пользовательских функций, таких как ответственные за утверждение финансовых вопросов (операций), ответственные за утверждение нефинансовых вопросов, ответственные за анализ хронометражных карт, представители администрации, администраторы этапов проекта, координаторы финансовых вопросов и партнеры по людским ресурсам в течение процесса проекта/предложения. Продавец, покупатель или администратор могут дополнительно определять, что для процесса предложения/проекта необходимо множество позиций пользовательских функций в рамках одной или нескольких категорий пользовательских функций. Например, как показано на Фиг.11, покупатель может определить, что есть потребность в шести лицах, ответственных за утверждение финансовых вопросов, и двух лицах, ответственных за утверждение нефинансовых вопросов.
Согласно Фиг.9, как только позиции пользовательских функций определены, файл данных подходящего персонала для продавца, покупателя, или администратора сохраняют, чтобы использовать при выборе соответствующего персонала для каждой из позиций пользовательских функций (этап 905). Один или несколько ведущих специалистов для продавца, покупателя или администратора (например, COO, пользователь проекта и т.д.) могут быть выбраны, чтобы задать конкретный персонал, который будет распределен на каждую из позиций пользовательских функций (этап 910), или в качестве альтернативы, система может распределять персонал по позициям пользовательских функций на основании информации, содержащейся в файле данных персонала. В некоторых компаниях позиции пользовательских функций являются заранее определенными (этап 915), и в этом случае данные заранее определенного персонала могут быть загружены в систему (этап 920) и сохранены в таблице пользовательских функций (этап 925). Например, для большинства продавцов персонал является заранее распределенным по различным позициям пользовательских функций для всех проектов. В других компаниях одна или несколько позиций пользовательских функций не могут быть заранее распределенными вообще или не являются заранее определенными для конкретного проекта (этап 915), и в этом случае выбранные ведущие специалисты или система могут распределять конкретный персонал по позициям пользовательских функций.
Чтобы распределить конкретный персонал по позициям пользовательских функций, выбирают конкретную позицию пользовательской функции (этап 930) и перечень персонала, который может быть распределен на эту позицию пользовательской функции, в зависимости от ограничений пользовательских функций, определенных на основании файла данных персонала (этапы 935, 940 и 945). Например, если позиция пользовательской функции требует пользователя конкретного уровня, то в перечень включают только тот персонал, который находится на конкретном уровне пользователя или выше него. Из перечня персонала для позиции пользовательской функции выбирают одного из специалистов для конкретной позиции пользовательской функции (этап 950) и выбранный персонал сохраняют в таблице пользовательских функций (этап 925). Например, как показано на Фиг.11, после выбора конкретной позиции пользовательской функции (например, посредством щелчка (указания) на позиции пользовательской функции), система может осуществлять поиск подходящего персонала для позиции пользовательской функции, и после того, как выбор сделан, выбранный персонал для позиции пользовательской функции может быть отображен.
Примеры структур данных для выбора и назначения позиций пользовательских функций для покупателя показаны в Таблицах 1-9 при этом ниже. Структуры данных для простоты проиллюстрированы представляемыми в табличном формате, причем каждая таблица включает в состав все поля, необходимые для определения и распределения позиций пользовательских функций для покупателя. Таблицы связаны иерархически и/или реляционно, так что вся необходимая информация для позиций пользовательских функций может быть точно сохраненной и к ней может быть осуществлен доступ, как будет описано при этом ниже в связи с примерной структурой 300 таблицы базы данных по Фиг.10. Однако должно быть понятно, что могут быть включены другие конфигурации пользовательских функций для покупателя, и система не ограничена конкретными конфигурациями пользовательских функций (для) покупателя, приведенными в Таблицах 1-9 или на Фиг.10.
В таблицах 1 и 2 ниже проиллюстрированы соответственно примерные категории пользовательских функций и позиции пользовательских функций в рамках каждой из категорий пользовательских функций, которые могут быть сохранены в базе данных в таблицах "tblHMPositionCategories" ("Позиция-Категории") 305 и "tblHMPositions" 306 ("Позиции") соответственно, как показано на Фиг.10. В Таблице 1 каждой категории пользовательской функции задан (приписан) идентифицирующий номер и порядок отображения для отображения на web-странице. Идентифицирующие номера категорий пользовательских функций использованы в таблице (Таблица 2) позиций пользовательских функций для соотнесения позиций пользовательских функций с конкретными категориями пользовательских функций. Однако, понятно, что могут иметься дополнительные категории и позиции в зависимости от потребностей покупателя. При первоначальном выборе позиций пользовательских функций могут отображаться категории пользовательских функций, для выбора из них пользователем, со ссылками на конкретные позиции пользовательских функций в рамках каждой из категорий. После того, как все позиции пользовательских функций выбраны для конкретного покупателя, выбранные позиции пользовательских функций и распределенный персонал могут отображаться, как, например, на Фиг.11.
Примерные категории пользовательских функций (tblHMPositionCategories)
Примерные позиции пользовательских функций (tblHMPositions)
Таблица 3 ниже иллюстрирует выборочные данные, сохраняемые в файле данных о персонале для каждого пользователя системы, которые могут быть сохранены в базе данных в таблице "tblUser" ("пользователь") 302, как показано на Фиг.10.
На основании этих пользовательских данных может быть определен подходящий персонал для каждой позиции пользовательской функции и может быть уточнена необходимая информация для каждого назначенного пользователя для каждой позиции пользовательской функции. Одним из полей в Таблице 3 является ранг предприятия (торгово-промышленной деятельности), определенный для конкретного пользователя. Ранг предприятия указывает конкретный уровень пользователя в экономической системе. Например, пользователь может соответствовать пользователю уровня 3, и эта информация будет сохранена в таблице пользователя. Доступные ранги предприятий могут быть соотнесены с позициями пользовательских функций, как показано в Таблицах 4 и 5 ниже, чтобы указать ранг предприятия, требуемый для пользователя, назначенного на каждую позицию пользовательской функции, что может быть сохранено в базе данных в таблицах "tblHMBusinessGrades" ("ранги предприятий") 303 и "tblHMPositiontoGradeMap" (соответствие позиций рангам) 304, как показано на Фиг.10.
Базисная системная таблица пользователей (tblUser)
Основная таблица рангов предприятий (tblHMBusinessGrades)
Таблица соответствия Пользовательской функции Рангу предприятия (tblHMPositiontoGradeMap)
Приведенные таблицы 6-9 будут описаны более подробно ниже в в связи с Фиг.10.
Таблица соответствия Позиции/Роли Шаблону предложения (tblHMPositionsRFXMatrix)
Таблица соответствия Пользовательских функций по умолчанию (tblHMPositionsRelationships)
Таблица соответствия Пользовательских функций Запросу предложения (tblBidHMPositions)
Соответствие иерархии Пользовательской позиции/функции Уровню утверждения (tblApprovalLevel)
Как может быть видно на Фиг.10, имеется связь между всеми полями, необходимыми для обеспечения возможности конфигурируемого разделения рабочих заданий, и конкретными компонентами последовательности действий для покупателя. Структура 300 базы данных является масштабируемой и конфигурируемой, так что даже при действии в рамках менее сложной среды базы данных, функциональные возможности тем не менее существуют, если позиции пользовательских функций определены и имеется файл данных персонала. Должно быть понятно, что аналогичные структуры таблиц базы данных доступны продавцу и администратору, как описано более подробно ниже.
Структура 300 таблицы базы данных для покупателя в качестве входных данных принимает от покупателя данные о персонале ("tblHRdata" ("данные") 301) и создает файл данных о персонале ("tblUser" 302), включающий конкретный персонал, который может быть включен в общедоступную рабочую среду. Данные о персонале показаны как таблица "tblHRdata" 301 в целях простоты. Однако должно быть понятно, что данные о персонале могут быть в любой форме в зависимости от системы базы данных покупателя. Могут выполняться периодически загрузки из таблицы "tblHRdata" 301 в таблицу "tblUser" 302, чтобы обновлять систему данными о текущих служащих для покупателя, чтобы гарантировать надлежащее распределение по позициям пользовательских функций. Различные ранги предприятий, заданные покупателем, также могут быть сохранены в таблице "tblHMBusinessGrades" 303 и соотнесены или отображены на таблицу "tblUser" 302 для индивидуального назначения рангов предприятия, как описано выше в связи с Таблицами 3 и 4. Кроме того, ранги предприятий могут быть отображены на выбранные пользовательские функции в таблице "tblHMPositiontoGrade" 304, как описано выше в связи с Таблицами 4 и 5.
Таблица категорий пользовательских функций ("tblHMPositionCategories" 305), таблица позиций пользовательских функций ("tblHMPositions" 306) и их взаимосвязи с рангами позиций и распределенным персоналом также показаны на Фиг.10. Например, таблица "tblHMPositionsRelationship" ("связь позиций") 307 включает в себя идентификатор пользователя для персонала, распределенного на каждую позицию пользовательской функции. Если позиции пользовательских функций являются связанными с конкретными типами шаблонов предложения (как описано более подробно ниже в связи с Фиг.15), позиции пользовательских функций для каждого типа шаблона предложения могут быть сохранены в таблице "tblHMPositionsRFXMatrix" ("таблица позиций RFX") 309. Более того, если позиции пользовательских функций распределены конкретно для каждой операции предложения, то идентификатор пользователя для назначенного персонала на каждую позицию пользовательской функции для конкретной транзакции может быть сохранен в таблице "tblBidHMPositions" ("позиции предложения") 308.
Примерные этапы для распределения покупателем персонала по позициям пользовательских функций в течение транзакции показаны на Фиг.12. После инициирования транзакции (этап 1200) (например, создания шаблона предложения или запроса предложения, рассылки запроса предложения, приема ответа на запрос предложения, оценка ответа на запрос предложения, назначения предложения, оплаты денежного документа, и т.д.) системный и/или ведущий специалист определяет, были ли для транзакции определены все требуемые позиции пользовательских функций (этап 1205). Если определены не все позиции, то системный и/или ведущий специалист определяет позиции пользовательских функций, необходимые для транзакции (этап 1210).
Как только позиции пользовательских функций уточнены, системный и/или ведущий специалист определяет, был ли конкретный персонал (обозначаемый при этом так же как пользователи) заранее определен для позиций пользовательских функций (этап 1215) и должен ли какой-либо из заранее определенных пользователей быть заменен для транзакции (этап 1220). Если одна или несколько позиций пользовательских функций не имеют заранее определенного пользователя или если один или несколько заранее определенных пользователей были заменены, то системный и/или ведущий специалист задает подходящего пользователя для всех позиций пользовательских функций (этап 1225) и сохраняет идентификаторы заданных пользователей для позиций пользовательских функций в таблице пользовательских функций (этап 1230) (например, "tblBidHMPositions" на Фиг.10). Если все пользователи заранее определены, то система сохраняет заранее определенный персонал (этап 1230), и если применимо, то уведомляет соответствующий персонал относительно транзакции (этап 1240).
Согласно Фиг.10, в дополнение к распределению пользователей по конкретным позициям пользовательских функций для процесса предложения/проекта структура 300 таблицы базы данных дополнительно обеспечивает возможность задания транзакций, которые требуют утверждения и конкретных ответственных за утверждение по многим основаниям. Следовательно, в таблице "tblApprovalLevel" ("уровень утверждения") 310 некоторые позиции пользовательских функций могут быть классифицированы в качестве позиций утверждения, и для каждой позиции утверждения может быть задана очередность маршрутизации для утверждения. Например, пользовательская функция позиции "ответственный за утверждение" ("Ответственный A за утверждение") может быть задана как утверждающая все транзакции, сформированные другой позицией пользовательской функции User B (Пользователь B), с тем, чтобы система автоматически направляла все транзакции от Пользователя B к Ответственному A за утверждение.
Кроме того, каждому пользователю могут быть предоставлены права доступа для просмотра и изменения данных в системе. Например, одна позиция пользовательской функции может иметь полномочия, чтобы в системе изменять или вводить данные посредством первой web-страницы, тогда как другая позиция пользовательской функции может иметь полномочия только для просмотра данных посредством второй web-страницы. Таким образом, несмотря на то, что информация, отображенная на web-странице, может быть одинаковой для обоих пользователей, фактические web-страницы являются различными в зависимости от уровня утверждения, соответствующего позиции пользовательской функции. В случае, когда пользователь входит в систему, система определяет уровень утверждения для пользователя и пересылает соответствующие web-страницы пользователю. Пример структуры данных, осуществляющей установление соответствия пользовательской функции и возможности доступа к web-страницы, показан в Таблице 10.
Таблица соответствия Пользовательской функции и Доступа к Web страницы
Чтобы непрерывно поддерживать связи между позициями пользовательских функций, внутренним персоналом и конкретными транзакциями, система согласно настоящему изобретению дополнительно принимает во внимание изменения в организационной структуре персонала предприятия и в уровне предприятий и полномочиях пользователя для персонала. На Фиг.14 проиллюстрированы примерные этапы для изменения распределений позиций пользовательских функций в соответствии с вариантами осуществления настоящего изобретения. Позиция пользовательской функции может быть повторно назначена на основании имени пользователя или типа транзакции (этап 1400). Если изменение осуществляют на основании имени пользователя (этап 1405), то изменение может быть сделано глобально для всех позиций пользовательских функций, поддерживаемых пользователем, или только для определенных позиций пользовательских функций, поддерживаемых пользователем. Для глобальных изменений (этап 1410) выбирается новый пользователь (этап 1415), и новым пользователем заменяют предыдущего пользователя для всех позиций пользовательских функций, поддерживаемых предыдущим пользователем (этап 1420). Такой вид глобального изменения необходим, например, в случае, когда служащий покидает компанию и новый служащий занимает в компании должность уходящего служащего.
Для изменений позиции функции конкретного пользователя (этап 1410) могут быть отображены все позиции пользовательских функций, поддерживаемые пользователем (этап 1425), и одна из позиций пользовательской функции может быть выбрана для изменений (этап 1430). Для этой выбранной позиции пользовательской функции выбирается новый пользователь (этап 1435), и новый пользователь заменяет предыдущего пользователя для этой выбранной позиции пользовательской функции (этап 1440). Данный процесс может быть повторен для каждой позиции пользовательской функции, которая требует изменения (этап 1445). Изменения конкретных позиций пользовательских функций могут происходить по ряду причин таких, как продвижение по службе, реорганизация, изменения в положении служащего (например, от полного рабочего дня к неполному рабочему дню), и т.д.
Если изменение осуществляется на основании типа транзакции (этап 1405), то может быть отображен перечень всех типов транзакций (например, создание запроса предложения, рассылка запроса предложения, прием запроса предложения, формирование ответа на запрос предложения, прием ответа на запрос предложения, оценка предложения, решение о назначении предложения, отслеживание времени, оплата обязательства по платежам и т.д.) (этап 1450) и выбран конкретный тип транзакции (этап 1455). Могут быть отображены все позиции пользовательских функций, связанные с этим конкретным типом транзакции (этап 1460), и может быть выбрана конкретная позиция пользовательской функции, которая подлежит изменению (этап 1465). Выбирается новый пользователь для этой выбранной позиции пользовательской функции (этап 1470), и новый пользователь используется вместо предыдущего пользователя для этой выбранной позиции пользовательской функции (этап 1475). Модификации типа транзакции могут быть полезными, например, в случае, когда конкретный пользователь для позиции пользовательской функции является неизвестным, а изменение требуется из-за претензий потребителя.
Изменения позиции пользовательской функции могут применяться к имеющимся транзакциям или только к новым транзакциям (этап 1480) в зависимости от причины для изменения и необходимости непрерывности имеющихся транзакций. Если изменение должно применяться к имеющимся транзакциям, таблица пользовательских функций обновляется с помощью нового пользователя, и предыдущая запись о пользователе модифицируется как "устаревшая" ("outdated") (этап 1485). Однако, если изменение должно быть применимо только к новым транзакциям, таблица пользовательских функций изменяется с помощью нового пользователя, но данные предыдущего пользователя не удаляются, а новый пользователь маркируется для использования только для новых транзакций (этап 1490).
Для продавца позиции пользовательских функций являются обычно заранее определенными, чтобы ограничить доступ к уже квалифицированному персоналу. Примеры структур данных, реализующих функции пользователя-продавца, показаны в Таблицах 11-13. Как видно, для персонала продавца может быть определен тип контакта с продавцом, что может быть отображено на права доступа, чтобы просматривать и изменять данные в системе, подобно описанному выше для покупателя в связи с Таблицей 10. Однако должно быть понятно, что могут быть включены другие конфигурации функций пользователя-продавца, и система не ограничена конкретными конфигурациями, приведенными в Таблицах 11-13.
Примерные Роли продавца (tblVendorRoles)
Примерные Связи продавца (tblVendorContacts)
Примерные функции продавца (tblVendorRolePermissions) ("полномочия функции продавца")
Для администратора позиции пользовательских функций могут быть определены для обеспечения возможности определения целиком групп обработки и членов группы для управления относящейся к транзакциям деятельностью, связанной с конкретным типами предложений и для конкретных местонахождений. На Фиг.13А-13В показаны примерные этапы для реализации группы обработки для административного управления. Первоначально для администратора устанавливают таблицу административных пользователей, содержащую основные данные административных пользователей (этап 1300). На основании таблицы пользователей различные пользователи могут быть распределены в одну или несколько групп пользователей, и соответствие пользователей группам пользователей может быть сохранено в таблице соответствия групп пользователей (этап 1305). Группы пользователей могут быть связаны с организационными структурными единицами в рамках компании и/или с типами транзакций. Для каждой из групп пользователей в таблице, предназначенной для прав группы пользователей, могут быть определены функциональные права и функциональная ответственность каждого пользователя в рамках группы пользователей (этап 1310). Например, каждому пользователю могут быть назначены права доступа (как обсуждено выше в связи с Фиг.10) для группы пользователей. Примеры структур данных, реализующих группы пользователей и права группы пользователей, предназначенные для администратора, показаны в Таблицах 14-19. Однако должно быть понятно, что могут быть включены другие конфигурации функций пользователя-администратора, и система не ограничена конкретными конфигурациями функций пользователя-администратора, приведенными в Таблицах 14-19.
Примерная таблица Административных пользователей
Примерные значения для Таблицы групп административных пользователей
Примерная Таблица соответствия Административных пользователей Группам пользователей
Примерная Таблица прав группы административных пользователей
Как только группы пользователей установлены, как показано на Фиг.13B, в рамках групп пользователей могут быть созданы группы обработки для обработки определенных типов транзакций (этап 1315). Всем пользователям в рамках конкретной группы пользователей могут быть поставлены в соответствие конкретные группы обработки и задана очередность маршрутизации для конкретного типа транзакции (этап 1320). Примерные структуры данных для создания и установления соответствия пользователей группам обработки показаны в Таблицах 18 и 19.
Примерная Таблица Административных групп обработки
Примерная Таблица соответствия Групп обработки административных данных Пользователю
Кроме того, для групп обработки могут быть установлены соответствия с конкретными географическими зонами, чтобы различные группы обработки могли обрабатывать одинаковый тип транзакции в различных зонах (этап 1325). Следовательно, в случае, когда конкретный тип транзакции проводят в конкретном местоположении, система может управлять (потоком документов) последовательностью действий соответствующих пользователей на основании типа транзакции и местонахождения (этап 1330). Например, соответствующие пользователи могут быть уведомлены относительно транзакции посредством электронной почты и/или обновления инструментальной панели.
Таким образом, управление функцией пользователя, поддерживаемое системой согласно настоящему изобретению, обеспечивает приспосабливаемую, масштабируемую и надежную (устойчивую) среду распределения рабочих заданий для полного процесса предложения/проекта, начиная от создания предложения до завершения проекта. В дополнение, система предоставляет возможность защищенной обработки данных информационного обмена и транзакций на основании пользовательских функций, что дает возможность пользователям взаимодействовать с надлежащим персоналом в соответствующие моменты времени при гарантиях, что просмотр данных и права доступа ограничены теми пользователями, которые имеют функциональную необходимость доступа.
ДЕЯТЕЛЬНОСТЬ ПО ПРЕДЛОЖЕНИЮ
После того, как предварительная деятельность по предложению завершена, покупатель может создавать и передавать запрос предложения одному или нескольким продавцам, чтобы запрашивать ответы продавцов на запрос предложения для конкретного проекта. Для содействия процессу предложения в контексте полного процесса предложения/проекта для того, чтобы представить возможность эффективной и действенной оценки ответов на запрос предложения, могут быть использованы шаблоны предложения для конкретных типов проекта, чтобы запрашивать от продавцов необходимую информацию для конкретного типа проекта унифицированным и всеобъемлющим образом.
Примерная функциональность для создания запроса предложения с использованием шаблона предложения показана на Фиг.15. Инструментальное средство 180 создания шаблона предложения и инструментальное средство 185 создания ответа на запрос предложения проиллюстрированы на Фиг.15 для создания шаблонов 240 предложения и ответов 200 на запросы о предложении на основании шаблонов предложения 240, соответственно, в соответствии с вариантами осуществления настоящего изобретения. Инструментальное средство 180 создания шаблона предложения и инструментальное средство 185 создания запроса предложения могут включать в себя любые аппаратные средства, программное обеспечение и/или программно-аппаратные средства, необходимые для выполнения функций инструментальных средств, и могут быть осуществлены на web-сервере 120 или дополнительном сервере (не показан). Каждый покупатель может создавать один или несколько шаблонов 240 предложения в зависимости от сущности проектной работы привлеченных покупателем внешних ресурсов разработки проекта. Например, если покупатель имеет необходимости в дополнении штатов (персонала) только в одном отделе, покупатель может создавать только один шаблон 240 предложения для обработки ответа на запросы 200 о предложении относительно дополнения штатов.
Для создания шаблона 240 предложения инструментальное средство 180 создания шаблона предложения осуществляет доступ к базе данных 155a покупателя, чтобы извлечь элементы 230 предложения, находящиеся в перечне 194 элементов предложения, и предоставить покупателю посредством модуля 110 покупателя, web-сервера 120, сети передачи данных 40 и браузера 20a покупателя перечень 230 элементов предложения для выбора из него покупателем. Элементы предложения 230 связаны с конкретными типами информации, которую нужно запрашивать от покупателя и/или продавца. Покупатель осуществляет выбор из перечня элементов 230 предложения и предоставляет одну или более выборок 235 элементов предложений для включения в шаблон 240 предложения. В зависимости от конфигураций покупателя один или более элементов 230 предложения могут быть обязательными для шаблона 240 предложения, например имя покупателя, местонахождение работы, подлежащей выполнению, и тип запрашиваемой проектной работы. Для одного или нескольких обязательных элементов 230 предложения в дополнение к включению обязательных элементов предложения 230 в шаблон 240 предложения также может быть включена конкретная информация, связанная с каждым из обязательных элементов 230 предложения, в поля, относящиеся к обязательным элементам 230 предложения в шаблоне 240 предложения. Например, имя покупателя и тип проектной работы могут быть сохранены в шаблоне 240 предложения для этого типа проектной работы. Каждый шаблон 240 предложения, созданный покупателем, сохраняется в базе данных 155a покупателя в перечне 190 шаблонов предложения для последующего использования при создании запроса 200 предложения.
Для создания запроса 200 предложения инструментальное средство 185 создания запроса предложения осуществляет доступ к базе данных 155a покупателя, чтобы извлечь шаблоны 240 предложения, сохраненные в перечне 190 шаблонов предложения, и предоставляет покупателю перечень шаблонов 240 предложения посредством модуля 110 покупателя, web-сервера 120, сети передачи данных 40 и браузера 20a покупателя для выбора из него покупателем. После выбора соответствующего шаблона 240 предложения покупатель вводит данные 210 запроса предложения в инструментальное средство 185 создания запроса предложения для включения в запрос 200 предложения для соответствующего типа шаблона 240 предложения. Например, покупатель может вводить данные 210 запроса предложения в предусмотренные поля для каждой выборки 235 элементов предложения, которая требует информации от покупателя в шаблоне 240 предложения. В качестве примера, а не ограничения, данные 210 запроса предложения могут включать в себя местонахождение работы, подлежащей выполнению, учет времени по проекту и конкретные квалификации продавца, необходимые для проекта.
Инструментальное средство 185 создания запроса предложения далее взаимодействует с базой данных 155a покупателя для доступа к перечню 158 продавцов для покупателя и определяет подходящих продавцов для принятия запроса предложения. Подходящие продавцы могут быть выбраны на основании типа шаблона 240 предложения и любых других квалификаций продавца, включенных непосредственно в запрос 200 предложения. Таким образом, перечень 158 продавцов может быть разделен на заранее квалифицированных продавцов для типов шаблона 240 предложения, чтобы дополнительно уменьшить время обработки при передаче запросов 200 предложений. Инструментальное средство 185 создания запроса предложения дополнительно использует информацию 250 о связях продавца, ассоциированную с выбранным продавцам, чтобы рассылать запрос 200 предложения подходящим продавцам (как показано на Фиг.1 и 2) посредством модуля продавца 115, web-сервера 120, сети передачи данных 40 и браузера 20b продавца, и сохраняет представленный на рассмотрение запрос 200 предложения в перечне 196 запросов предложений для покупателя.
Ответы 220 продавца на запрос предложения, принятые от запрошенных продавцов (как показано на Фиг.1, и 2), могут быть дополнительно сохранены в базе данных 155a покупателя в перечне 198 ответов на запрос предложения для последующего использования при сравнении и ранжировании ответов 220 продавцов на запрос предложения. Ответы 220 продавцов на запрос предложения формируют на основании элементов предложения, включенных в запрос 200 предложения. Более конкретно, продавец заполняет данные, связанные с продавцом и ответом на запрос предложения, в полях данных для разрешенных элементов предложения в запросе 200 предложения. Продавцы осуществляют доступ к запросу 200 предложения посредством модуля 115 продавца, чтобы просмотреть запрос предложения и заполнить ответ продавца и представить посредством модуля 115 продавца заполненные ответы 220 на запрос предложения для сохранения в базе данных 155a покупателя посредством модуля 110 покупателя (этап не показан). Ответ 220 на запрос предложения может включать в себя данные, извлеченные из базы данных 115b продавца (не показана), и они могут сохраняться в базе данных 155b продавца в процессе формирования ответа на запрос предложения и после этого.
Примерные этапы для создания шаблона предложения, запроса предложения, формируемого на основании шаблона предложения, и ответа на запрос предложения на основании запроса предложения показаны на Фиг.16A-16D с различных системных точек зрения. Основные этапы обработки, выполняемые в системе для создания шаблона предложения, показаны на Фиг.16A. Система создает шаблон предложения посредством предоставления пользователю-покупателю перечня заранее определенных элементов предложения (этап 1600). В ответ на это система принимает одну или несколько выборок элементов предложения из перечня элементов предложений для включения в шаблон предложения, сохраняемый в системе (этап 1610). Чтобы создать запрос предложения на основании шаблона предложения, система передает выборки элементов предложения, выполненные в рамках шаблона предложения, пользователю-покупателю для формирования запроса предложения с использованием выборок элементов предложения (этап 1620).
На Фиг.16B показано, что на стороне покупателя после приема перечня элементов предложения для создания шаблона предложения пользователь-покупатель выбирает один или более элементов предложения для включения в шаблон предложения (этап 1630). Для последующего формирования запроса предложения пользователь-покупатель принимает шаблон предложения, включающий выборки элементов предложения (этап 1635), и вводит данные запроса предложения в поля, связанные с выборками элементов предложения в шаблоне предложения, для создания запроса предложения (этап 1640). После того, как все применимые поля выборки элементов предложения заполнены пользователем-покупателем, запрос предложения передается в систему для рассылки подходящим продавцам (этап 1645).
Основные этапы обработки, выполняемые системой для формирования запроса предложения и рассылки, показаны на Фиг.16C. После создания шаблона предложения и сохранения выборок элементов предложения для шаблона предложения (этап 1650) система формирует запрос предложения с использованием данных запроса предложения, введенных пользователем-покупателем для запроса предложения согласно типу шаблона предложения (этап 1660). После этого система передает сформированный запрос предложения подходящим продавцам для запрашивания ответа на запрос предложения согласно типу шаблона предложения (этап 1670).
На Фиг.16D показано, что на стороне продавца продавец принимает запрос предложения, включающий разрешенные выборки элементов предложения, выбранные покупателем (этап 1680). Чтобы создать ответ предложения, пользователь-продавец вводит данные ответа предложения в поля, связанные с теми выборками элементов предложения, которые включены в запрос предложения (этап 1685), для создания ответа на запрос предложения. После того, как все применимые выборки элементов предложения поля заполнены пользователем-продавцом, ответ на запрос предложения передается в систему для пересылки покупателю (этап 1690).
Примеры структур данных, используемых для создания шаблонов предложения, показаны в Таблицах 20-25. Структуры данных для простоты проиллюстрированы представляемыми в табличной форме, причем каждая таблица включает в себя все поля, необходимые для отображения элементов предложения пользователю-покупателю, для выбора из них и сохранения выборок элементов предложения для шаблонов предложений. Таблицы связаны иерархическим и реляционным образом, как описано ниже в связи с Фиг.17. Однако понятно, что в систему могут быть включены другие конфигурации шаблонов предложения, и система не ограничена конкретной конфигурацией шаблона предложения, показанной в Таблицах 20-25 и на Фиг.17.
Таблица Основных разделов элементов предложения (tblRFXBidSections) (разделы предложений)
Таблица Основных категорий элементов предложения (tblRFXBidCategories)(категории предложений)
Таблица Основных элементов предложения (tblRFXBidItems) (элементы предложения)
Таблица Основных типов шаблонов предложения (tblRFXBidTemplates) (шаблоны предложения)
Таблица соответствия Основного шаблона предложения и Элементов предложения (tblFRXTemplateItemMatrix)
Таблица значений по умолчанию элемента предложения базы данных клиентов (tblFRXBidItemsCDV)
На Фиг.17 показана структура 400 таблицы базы данных, иллюстрирующая взаимосвязь между каждой из вышеупомянутых Таблиц 20-25. Элементы 230 предложения объединены в разделы предложений и категории предложений для удобства и логического разбиения на разделы (сегменты) обработки информации о торгово-промышленной деятельности при создании шаблонов предложения 240. Таким образом, пользователю-покупателю предоставляют разделы 250 предложения, из которых пользователь-покупатель может выбирать категорию 255 предложения для отображения элементов 230 предложения, связанных с этой категорией 255 предложения. Разбиение элементов 230 предложения на категории 255 предложения и разделы 250 предложения способствует разделенному формату, понятному для пользователя-покупателя, таким образом предоставляя возможность более эффективного и действенного процесса создания шаблона предложения.
Таблица "tblRFXBidSections" 401, которая имеет формат вышеуказанной Таблицы 20, включает в себя наименование раздела предложения и идентификацию каждого раздела 250 элементов предложения 230, наряду с указанием порядка отображения на web-странице для каждого раздела 250 предложения и комментариев, включаемых вместе с разделом 250 предложения в состав web-страницы. Каждый раздел 250 предложения может быть сохранен в качестве отдельной записи в таблице "tblRFXBidSections" 401, причем каждая запись имеет формат Таблицы 20. Внутри каждого раздела 250 предложения находятся одна или несколько категорий 255 предложения. Таблица "tblRFXBidCategories" 402, которая имеет формат вышеуказанной Таблицы 21, включает в себя наименование категории, идентифицирующий номер каждой категории 255 предложения и связанного раздела 250 предложения для каждой категории 255 предложения. Кроме того, таблица "tblRFXBidCategories" 402 дополнительно включает в себя порядок отображения на web-странице для каждой категории 255 предложения и комментарии для включения вместе с категорией 255 предложения в состав web-страницы. Каждая категория 255 предложения может быть сохранена в качестве отдельной записи в таблице "tblRFXBidCategories" 402, причем каждая запись имеет формат Таблицы 21.
Каждая категория 255 предложения дополнительно включает в себя один или более элементов 230 предложения, связанных с категорией 255 предложения. Следовательно, таблица "tblRFXBidItems" 403, которая имеет формат вышеуказанной Таблицы 22, включает наименование элементов предложения и идентифицирующий номер, наряду с категорией 255 предложения, связанной с элементом 230 предложения. Отдельная запись для каждого элемента 230 предложения может быть сохранена в таблице "tblRFXBidItems" 403, в которой каждая запись имеет формат вышеуказанной Таблицы 22. Таблица "tblRFXBidItems" 403 также включает в себя дополнительную информацию, имеющую отношение к элементу 230 предложения, например разрешено ли блокирование элементов 230 предложения, должен ли элемент предложения 230 отображаться продавцу, требует ли ответа продавца элемент 230 предложения, тип данных вводимого покупателем элемента 230 предложения, размер поля данных, вводимых покупателем, для элемента 230 предложения, тип данных, вводимых продавцом, для элемента 230 предложения и размер поля данных, вводимых продавцом, для элемента 230 предложения. Например, следующая Таблица 26 иллюстрирует выборочные элементы 230 предложения в таблице "tblRFXBidItem" 403, составляющей перечень 194 элементов предложения, как показано на Фиг.15.
ТАБЛИЦА26
Item
_ID
Lement
_Allo
wed
Dor
_Bid
_Dis
play
Dor
_Resp
onse
_Item
Categ
Ory
_ID
Data
_Type
Field
_Len
gth
_Disp
lay_
Order
_Resp
onse
_Data
_Type
_Fie
ld
_Len
gth
компании/организации)
На Фиг.17 показано, что каждый из элементов 230 предложения может быть блокирован или включен для конкретного шаблона 240 предложения в зависимости от типа проектной работы, для которого создается шаблон 240 предложения. Однако, как описано выше в связи с Фиг.15, может иметься ряд элементов 230 предложения, которые являются обязательными для включения в один или более типов шаблонов 240 предложения. Следовательно, для обязательных элементов 230 предложения блокирование не разрешено. Если полностью раздел 250 предложения или категория 255 предложения не применимы к конкретному шаблону предложения 240, то структура 400 таблиц базы данных может конфигурироваться для разрешения блокирования элементов 230 предложения целиком в разделах 250 предложения или категориях 255 предложения, если все элементы 230 предложения в таком разделе 250 предложения или категории 255 предложения могут блокироваться.
После того, как все элементы 230 предложения блокированы или включены (выборки 235 элементов предложения являются включенными элементами предложения) для конкретного шаблона 240 предложения, шаблон 240 предложения и связанные выборки 235 элементов предложения могут быть сохранены в структуре 400 таблицы базы данных. Таблица "tblRFXBidTemplates" 405, которая имеет формат вышеуказанной Таблицы 23, включает в себя наименование шаблона предложения и идентифицирующий номер шаблона предложения для использования при связывании выборок элементов 235 предложения с шаблоном 240 предложения в таблице "tblRFXTemplateItemMatrix" 404, которая имеет формат указанной выше Таблицы 24. Отдельная запись для каждого шаблона 240 предложения может быть сохранена в таблице "tblRFXBidTemplates" 405, в которой каждая запись имеет формат Таблицы 23. Кроме того, отдельная запись для каждой выборки элементов 235 предложения, включенной в конкретный шаблон 240 предложения, может быть сохранена в таблице "tblRFXTemplateItemMatrix" 404, в которой каждая запись имеет формат Таблицы 24.
Если имеются конкретные элементы 230 предложения, которые имеют заданное по умолчанию значение, применимое ко всем шаблонам 240 предложения, например для имени покупателя, то заданное по умолчанию значение для конкретного элемента 230 предложения может быть сохранено в таблице "tblRFXBidItemsCDV" 406, которая имеет формат Таблицы 25. Отдельная запись для каждого заданного по умолчанию значения, связанного с каждым элементом 230 предложения, может быть сохранена в таблице "tblRFXBidItemsCDV" 406, в которой каждая запись имеет формат Таблицы 25. Посредством предоставления выбираемых элементов предложения в структурированной, настраиваемой и масштабируемой форме, любой элемент 230 предложения может быть добавлен или удален в любой момент времени в зависимости от конкретных потребностей покупателя.
Примерные этапы для создания шаблона предложения с использованием структуры таблиц иерархической и реляционной базы данных проиллюстрированы на Фиг.18. Для создания шаблона предложения пользователь-покупатель вводит наименование шаблона, чтобы для шаблона создать запись в структуре таблицы базы данных (этап 1800). После этого пользователь-покупатель выбирает конкретный раздел предложения из перечня разделов предложений (этапы 1805 и 1810) и конкретную категорию предложения из перечня категорий предложений (этапы 1815 и 1820) для инициирования начала процесса выбора элементов предложения для включения в шаблон предложения (этап 1825).
Если один или несколько элементов предложения в выбранной категории предложения являются обязательными (этап 1830), то выборки требуемых предложений автоматически включаются в шаблон предложения (этап 1835). Другие элементы предложения выбираются на основании потребностей пользователя-покупателя для конкретного типа шаблона предложения (этап 1840). Данный процесс повторяется для каждой категории предложения, входящей в выбранный раздел предложения (1845 этап), и для каждого раздела предложения, входящего в перечень разделов предложения (1850 этап), пока не будут рассмотрены все элементы предложения, и они либо включаются в шаблон предложения, либо блокируются. Как описано выше, в других вариантах осуществления, все элементы предложения в разделе предложения или в категории предложения имеют возможность блокирования без индивидуального рассмотрения элементов предложения, если разрешено блокирование всех этих элементов предложения. После того, как для шаблона предложения осуществлены выборки элементов предложения, шаблон предложения сохраняется в перечне шаблонов предложения (этап 1855) для последующего использования при создании запроса предложения.
Экранное изображение примерной web-страницы для создания шаблона предложения показано на Фиг.19. Используя одну или более web-страниц (из которых показана одна), пользователь-покупатель может ввести наименование шаблона 240 предложения, выбрать раздел 250 предложения и выбрать категорию 255 предложения для отображения конкретных элементов 230 предложения, входящих в категорию 255 предложения, которые могут быть включены в шаблон 240 предложения. Для каждого элемента 230 предложения, входящего в отображаемую категорию 255 предложения, пользователь-покупатель может выбрать либо включение, либо блокирование этого элемента 230 предложения. Однако, если конкретный элемент 230 предложения не может быть блокирован, то кнопка блокирования является невидимой, чтобы препятствовать отключению элементов 230 предложения пользователем-покупателем. Кроме того, если вариант выбора является доступным, пользователь-покупатель может также иметь возможность блокировать все элементы 230 предложения в конкретном разделе 250 предложения или в категории 255 предложения, посредством щелчка по кнопке блокирования, соседней с разделом 250 предложения или категорией 255 предложения, отображаемыми в данный момент времени. После того, как все элементы 230 предложения включены или блокированы для шаблона 240 предложения, пользователь-покупатель может сохранить шаблон 240 предложения. В некоторых вариантах осуществления пользователь-покупатель может иметь возможность временного сохранения шаблона 240 предложения, если все выборки элементов 235 предложения еще не были завершены. В других вариантах осуществления кнопка "сохранения" остается невидимой до тех пор, пока все элементы 230 предложения не будут включены или блокированы.
На Фиг.20 проиллюстрированы примерные этапы для создания запроса предложения на основании шаблона предложения, показанного на Фиг.15, с использованием элементов предложения, представляемых в иерархическом и реляционном формате, как показано на Фиг.17. Первоначально, пользователь-покупатель из перечня шаблонов предложения выбирает шаблон предложения для запроса предложения (этап 2000). Понятно, что шаблон предложения может быть создан непосредственно перед формированием запроса предложения, или шаблон предложения может быть создан заранее, до запроса предложения. После того, как выбран конкретный шаблон предложения для запроса предложения, пользователь-покупатель вводит идентификатор запроса предложения для запроса предложения (этап 2005) такой, как наименование или номер запроса предложения. Кроме того, система будет назначать номер для отслеживания предложения, предназначенный для обращения к предложению, который применим в системе для продавца, покупателя, подрядчика и администратора.
Все выборки элементов предложения в шаблоне предложения отображаются для просмотра пользователю-покупателю в соответствии с разделом предложения и категорией предложения (этап 2010). Если одна или более выборок элементов предложения в шаблоне предложения не применимы к конкретному запросу предложения (этап 2015), и нежелательные выборки элементов предложения могут быть блокированы (этап 2020), пользователь-покупатель может блокировать выборки элементов предложения, которые не являются необходимыми для конкретного запроса предложения (этап 2025). После этого пользователь-покупатель вводит необходимые данные запроса предложения в подходящие поля для выборок элементов предложения, разрешенных в запросе предложения (этап 2030). Например, одна или несколько выборок элементов предложения могут содержать поля для покупателя, чтобы вводить данные, такие как местонахождение работы, подлежащей выполнению или тип проектной работы. Эти поля могут быть полями различных типов данных, например полями ввода текста или полями выбираемых вариантов выбора, или опций со связями на другие web-страницы, содержащие выбираемую опцию.
Пример поля выбираемой опции, которое может отображаться, включает в себя выбор из множества заранее установленных типов проектов конкретного типа проектной работы для запроса предложения. Для осуществления процесса выбора типа проекта может быть обеспечена конфигурируемая и масштабируемая структура базы данных, которая дает возможность несловесным образом ранжировать требования покупателя к торгово-промышленной деятельности для конкретной проектной работы. Посредством выбора из заранее установленных типов проектных работ, покупатель может гарантировать, что ответы продавца на запрос предложения являются синхронными с требованиями покупателя к проектной работе. Типы проектной работы также могут быть выбраны продавцом при заполнении квалификационных данных продавца (показано на Фиг.2) для выбора продавцов, которые принимают запрос предложения. Примеры структур данных, используемых для выбора типа проектной работы, показаны в Таблицах 27-29. Структуры данных для простоты иллюстрированы представляемыми в табличном формате, в котором каждая таблица включает в себя все поля, необходимые для отображения типов проектной работы пользователю-покупателю для выбора из них, и сохранения выбранного типа проектной работы в поле, входящего в соответственную выборку элементов предложения соответствующего запроса предложения. Таблицы связаны иерархическим и реляционным образом, так что к таблицам осуществляется доступ в конкретном порядке для отображения типов проектной работы пользователю-покупателю.
В Таблице 27 проиллюстрированы примерные типы проектных услуг, таких как консультирование, дополнение штата персонала и другие проектные услуги. Для каждого из типов проектных услуг может иметься один или несколько проектных секторов, как показано в Таблице 28, и в каждом из проектных секторов может быть одно или несколько проектных семейств, как показано в Таблице 29. Следовательно, чтобы выбрать конкретный тип проектной работы (проектного семейство) для запроса предложения, пользователь-покупатель может выбрать тип проектных услуг и тип проектного сектора, чтобы отобразить перечень проектных семейств для выбора из него. Понятно, что в систему могут быть включены другие конфигурации и типы проектов, и система не ограничена конкретными конфигурациями и информацией, приведенной в Таблицах 27-29.
Таблица типов проектных услуг
Таблица типа проектных секторов
Таблица типов проектных семейств
Согласно Фиг.20, как только пользователь-покупатель ввел данные запроса предложения во все из необходимых полей элементов предложения (этап 2035), запрос предложения является завершенным. Понятно, что не все поля элементов предложения требуют ввода пользователем данных запроса предложения. Например, одна или более выборок элементов предложения может быть выборкой элементов предложения из ответа продавца на запрос предложения, на которую отвечает только продавец. Для выборок элементов предложения из ответа продавца на запрос предложения пользователь-покупатель может включать или блокировать такую выборку элементов предложения и не вводить данные в поля для такой выборки элементов предложения, кроме данных, способствующих заполнению продавцом ответа предложения для этого элемента предложения. Для завершенности запроса предложения каждая разрешенная выборка элементов предложения, в которой пользователь-покупатель может вводить данные запроса предложения, предпочтительно заполняется пользователем-покупателем перед представлением запроса предложения для рассмотрения.
Во многих компаниях запросы предложения должны быть утверждены до передачи продавцам. Следовательно, если запрос предложения требует утверждения (этап 2040), инициатор запроса предложения представляет запрос предложения соответствующим лицам, ответственным за утверждение (этап 2045). В примерных вариантах осуществления, как описано выше в связи с Фиг.9-14, позиции функции пользователя, ответственного за утверждение, являются заранее определенными для всех запросов предложения или для конкретного запроса предложения, так что запрос предложения автоматически направляется к соответствующему лицу, ответственному за утверждение. Если запрос предложения утвержден (2050 этап), то инициатор информируется об утверждении запроса предложения (этап 2055), и запрос предложения передается подходящим продавцам (2060 этап). Однако, если запрос предложения не утвержден (2050 этап), то инициатор уведомляется об отклонении запроса предложения (этап 2065) и ему обеспечивается возможность редактирования запроса предложения (этап 2070), если возможно. Например, инициатор мог блокировать одну или несколько выборок элементов предложения, которые для утверждения должны быть включены в запрос предложения, или оставить незаполненным один или несколько требуемых покупателем полей данных. Если утверждение запроса предложения не требуется (этап 2040), то запрос предложения передается подходящим продавцам для запроса предложения (этап 2060).
На Фиг.21 и 22 показаны экранные представления примерных web-страниц, которые могут предоставляться пользователю-покупателю для создания запроса предложения. Используя одну или несколько web-страниц, пользователь-покупатель может ввести наименование 200 запроса предложения, выбрать раздел 250 предложения и выбрать категорию 255 предложения, чтобы отобразить конкретные выборки элементов 230 предложения в пределах категории 255 предложения, которые могут быть включены в запрос 200 предложения. На Фиг.21 показан общий вид состояния запроса 200 предложения, содержащий перечень количества выборок 235 элементов предложения в каждом разделе 250 и количество выборок 235 элементов предложения в каждом разделе 250, которые являются завершенными или блокированными. Чтобы завершить или блокировать выборку 235 элементов предложения, пользователь-покупатель может щелкнуть на разделе 250 предложения для отображения категорий 255 предложения и выборках 235 элементов предложения в пределах каждой из категорий 255 предложений. После того как все выборки 235 элементов предложения завершены или блокированы, пользователь-покупатель может щелкнуть на кнопке отправки заполненного запроса предложения для утверждения и/или передачи квалифицированным продавцам.
Как показано на Фиг.22, каждая выборка 235 элементов предложения в каждой категории 255 предложения в каждом разделе 250 предложения может просматриваться для определения того, следует ли блокировать выборку 235 элемента предложения. Некоторые из выборок 235 элементов предложения в одной или более категориях 255 могут также потребовать данных 210 запроса предложения от пользователя-покупателя. Для каждой выборки 235 элементов предложения в пределах категории 255 предложения пользователь-покупатель может включить или блокировать данную выборку 235 элементов предложения. Однако если конкретная выборка 235 элементов предложения не может быть блокирована, то кнопка блокирования остается невидимой, чтобы предотвратить блокирование пользователем-покупателем этой выборки 235 элементов предложения. Кроме того, при наличии соответствующей опции пользователь-покупатель может иметь возможность блокировать все выборки 235 элементов предложения в конкретном разделе 250 предложения или категории 255 предложения. Если выборка 235 элемента предложения включена и имеет поле 238 для ввода данных 210 запроса предложения, пользователь-покупатель может ввести данные 210 запроса предложения в соответствующее поле данных 238. Кроме того, если шаблон предложения содержит данные 210 запроса предложения устанавливаемых по умолчанию для конкретной выборки 235 элементов предложения, эти данные 210 могут по умолчанию отображаться в поле 238 данных и могут быть разрешены или не разрешены для изменения в зависимости от настроек шаблона.
Фиг.23 иллюстрирует примерные этапы для просмотра и отправки запросов предложений квалифицированным продавцам, как показано на Фиг.15. Инициатор запроса предложения может выбрать соответствующих квалифицированных продавцов из списка продавцов на основе типа шаблона предложения и введенных данных запроса предложения, или запрос предложения может быть представлен администратору проекта для выбора подходящих продавцов в зависимости от ограничений покупателя. В последнем случае новые запросы предложения могут быть отображены административному пользователю (этап 2300), чтобы выбрать требуемые запросы предложения для просмотра и передачи (этап 2305). В процессе просмотра административному пользователю может быть разрешено редактировать запрос предложения с целями управления качеством, или он может запрашивать инициатора запроса предложения о редактировании запроса предложения, если необходимы существенные изменения (этап 2310).
После того, как запрос предложения оказывается в заполненной форме, административный пользователь осуществляет доступ к перечню продавцов (этап 2315), чтобы определить подходящих продавцов для запроса предложения на основании типа шаблона предложения и введенных данных запроса предложения (этап 2320) (например, на основании проектного семейства вместе с ожидаемым географическим местонахождением работы). Если перечень подходящих продавцов является недостаточным (этап 2325), то административный пользователь также может осуществить запрос к базе данных верхнего уровня (как показано на Фиг.6) о дополнительных соответственных продавцах, чтобы добавить к перечню квалифицированных продавцов (этап 2330). В дополнение к добавлению или вместо добавления к перечню квалифицированных продавцов соответственных продавцов из базы данных верхнего уровня, административному пользователю также может быть предоставлен вариант выбора, чтобы включать (в перечень) продавцов, которые не соответствуют полностью всем данным запроса предложения (этапы 2335 и 2340).
Экранное представление примерной web-страницы, отображающей всех потенциальных продавцов, из которых должен быть сделан выбор для включения в перечень квалифицированных продавцов, показан на Фиг.24. Административный пользователь может осуществить выбор из продавцов, заключивших договор с покупателем, которые соответствуют данным из запроса предложения; из продавцов, заключивших договор с покупателем, которые не полностью соответствуют данным из запроса предложения, и из продавцов, не заключивших договор, которые соответствуют данным из запроса предложения, предоставленным базой данных верхнего уровня. Административный пользователь может выбрать продавцов для включения в квалификационный перечень продавцов на основании любого количества факторов, включая стаж (прежний опыт) договора с продавцом, репутацию продавца и пригодность продавца.
На Фиг.23 показано, что после заполнения перечня квалифицированных продавцов (этап 2345) административный пользователь передает запрос предложения квалифицированным продавцам (этап 2350) и уведомляет инициатора запроса предложения относительно состояния запроса предложения (этап 2355). Например, инициатор может быть уведомлен о конкретных продавцах, которые приняли запрос предложения, и о модификациях, выполненных в запросе предложения до передачи.
Показанные в общем виде на Фиг.1 и 15 под обозначением 220 примерные этапы для формирования и передачи ответа продавца на принятый запрос предложения представлены на Фиг.25. В примерных вариантах осуществления запросы предложения передают продавцам и направляют надлежащим пользователям-продавцам на основании конфигураций функции пользователя-продавца, как описано выше в связи с Фиг.9-14. После приема запроса предложения соответствующий пользователь-продавец может осуществлять доступ к запросу предложения через меню, либо посредством уведомления элемента управления "инструментальная панель" (этап 2500). В последующих примерных вариантах осуществления запрос предложения представляют вместе с соглашением о конфиденциальности предложения, обязывающим пользователя-продавца сохранять конфиденциальность содержимого запроса предложения до отображения содержимого запроса предложения пользователю-продавцу. Если пользователь-продавец подтверждает соглашение о конфиденциальности (например, посредством щелчка по кнопке ввода) (этап 2505), пользователь-продавец может получать доступ к содержимому запроса предложения (этап 2515). В противном случае пользователя-продавца уведомляют, что содержимое предложения не будет доступным, и запрос предложения удаляют из области обзора, видимой пользователю-продавцу (этап 2510).
Чтобы ограничить время, за которое продавцы должны представить ответы продавца на запрос предложения, запрос предложения также может включать в себя выделенный интервал времени, в течение которого продавец должен давать согласие отвечать. Если пользователь-продавец не может дать согласие на ответ в пределах выделенного интервала времени (например, посредством щелчка по кнопке ввода) (этап 2520), пользователь-продавец уведомляется, что содержимое запроса предложения больше не будет доступно пользователю-продавцу, и запрос предложения удаляется из области обзора пользователя-продавца (этап 2525). Покупатель или администратор проекта также уведомляется относительно продавцов, которые не подтверждают соглашение о конфиденциальности или из-за ограничений выделенного интервала времени, и на основании количества неподтвержденных продавцов покупатель или администратор проекта могут добавлять продавцов к перечню квалифицированных продавцов и передавать запрос предложения дополнительным продавцам, чтобы гарантировать, что принято достаточное количество ответов продавцов на запрос предложения.
Если пользователь-продавец дает согласие на ответ в пределах выделенного интервала времени (этап 2520), то продавец получает полномочия начинать заполнение ответа продавца на запрос предложения (этап 2530). Чтобы ответить на запрос предложения, пользователь-продавец обращается к выборкам элементов предложения в соответствии с разделом предложения и категорией предложения, которые требуют данных ответа продавца на запрос предложения для рассмотрения (этап 2535). Если пользователь-продавец имеет какие-либо вопросы относительно запроса предложения (например, относительно типа или количества данных ответа продавца, которые необходимы) (этап 2540), пользователь-продавец может представить вопросы покупателю для разъяснения предложения в пределах настроенного покупателем выделенного интервала времени (этап 2545). Соответствующий пользователь-покупатель (например, инициатор запроса предложения или администратор проекта) уведомляется о каждом вопросе, представленном продавцом, посредством электронной почты и/или модификации инструментальной панели (этап 2550), и этот пользователь-покупатель является ответственным за обеспечение ответа на представленные вопросы в пределах применимых ограничений времени (этап 2555). Продавцы уведомляются об ответах покупателя посредством электронной почты и/или обновленных данных инструментальной панели (этап 2560).
Например, система может обеспечивать доску объявлений о предложениях, к которой и продавцы и покупатель могут осуществлять доступ для конкретного запроса предложения. Экранное представление примерной доски 600 объявлений о предложениях показано на Фиг.27. Только покупатель и продавцы, являющиеся ответственными за конкретный запрос предложения, могут осуществлять доступ к доске 600 объявлений о предложениях. Всем продавцам может быть обеспечен доступ ко всем представленным вопросам и ответам покупателя, или только продавцу, который представлял вопрос, может быть разрешено просмотреть ответ покупателя, в зависимости от параметров настройки покупателя. Кроме того, вопросы продавца могут быть анонимными для продавцов и покупателя или только для продавцов в зависимости от предпочтений покупателя и/или продавца.
Согласно Фиг.25, если пользователь-продавец не имеет каких-либо вопросов (этап 2540) или на все вопросы продавца получен ответ (этап 2560), пользователь-продавец вводит необходимые данные ответа продавца на запрос предложения в соответствующие поля для требуемых в предложении выборок элементов предложения (этап 2565). Данные ответа продавца могут включать в себя информацию об исчислении издержек, включающую в себя калькуляционные статьи (например, требуемые ресурсы, типы расходов и т.д.), и соответственную информацию о ценах (например, ставки ресурса, объем расходов и т.д.) и информацию о сдачах/поставках, включая типы сдач/поставок (например, количество единиц, которые будут завершены, информацию об определении фаз, и т.д.) и информацию о завершении (например, дата завершения проекта, даты завершения фазы, и т.д.). Каждая из статей исчисления издержек и типов сдач/поставок связана с различной выборкой элементов предложения, чтобы предоставить возможность эффективного сравнения и ранжирования ответов продавцов на запрос предложения.
Поля элемента предложения могут быть различными типами данных, такими как поля для ввода значений text/currency/numeric (текст/денежный/числовой), и/или полями выбираемых опций. Кроме того, поля могут иметь набор уровней подробностей, связанных с единственным элементом ответа предложения для различных аспектов проекта. Например, если проект имеет несколько фаз, как определено покупателем и/или продавцом, поля ответа продавца на запрос предложения могут включать в себя отдельный раздел для каждой фазы проекта. После предпринятого продавцом представления ответа на запрос предложения система проверяет достоверность заполнения продавцом всех необходимых полей данных для выборок элементов предложения в ответе продавца на запрос предложения (этап 2570). Если все необходимые поля данные не заполнены (этап 2575), пользователю-продавцу посылается сообщение системы, указывающее недостающие выборки элементов предложения в ответе продавца на запрос предложения, и предложение заполнить требуемую выборку элементов предложения до представления на рассмотрение ответа продавца на запрос предложения (этап 2580). Как только все требуемые поля данных для выборок элементов предложения заполнены в ответе на запрос предложения (этап 2575), продавцу (после представления) посылается сообщение, указывающее, что ответ продавца на запрос предложения представлен покупателю или администратору проекта для рассмотрения (этап 2585), а соответствующий пользователь-покупатель уведомляется о новом ответе продавца на запрос предложения посредством электронной почты и/или обновления инструментальной панели (этап 2590).
На Фиг.26A и 26B показаны экранные представления примерных web-страниц, которые могут предоставляться пользователю-продавцу для формирования ответа на запрос предложения. Пользователю-продавцу предоставляются web-страницы, отображающие те выборки элементов предложения в ответе на запрос предложения, которые требуют данных ответа продавца. Например, как показано на Фиг.26A, состояние ответа продавца на запрос предложения может быть отображено пользователю-продавцу путем вывода перечня количества выборок элементов 235 предложения в каждом разделе 250, количества выборок элементов 235 предложения в каждом разделе, которые пользователь-продавец должен заполнить, и количества выборок 235 элементов предложения в каждом разделе 250, которые были заполнены. Кроме того, пользователь-продавец может осуществлять доступ к доске объявлений о предложениях, чтобы отправить вопросы продавцу, просмотреть ответы на запрос предложения в экранном формате, который является удобочитаемым, или послать резюме потенциальных подрядчиков для включения в ответ продавца на запрос предложения. Кроме того, после того как ответы продавца на все выборки элементов 235 предложения заполнены, пользователь-продавец может выполнить щелчок по кнопке представления завершенного ответа на запрос предложения для утверждения и/или передачи покупателю или администратору проекта.
Чтобы завершить ответ продавца на выборку 235 элементов предложения, как показано на Фиг.26B, пользователь-продавец может выполнить щелчок по разделу 250 предложения для отображения категорий 255 предложения и выборок 235 элементов предложения, входящих в каждую из категорий 255 предложения. Если требуется ответ продавца на конкретную выборку элементов предложения, пользователь-продавец может вводить данные 215 ответа продавца в поле 238 данных для выборки 235 элементов предложения. Как описано выше, поле 238 данных может быть полем непосредственного ввода текста или включать ссылки на другие web-страницы для выбора данных 215 ответа подходящего продавца из ответов заранее установленных продавцов. Кроме того, поле 238 данных может иметь набор уровней, имеющих ссылки на web-страницы для каждого уровня. Кроме того, поле 238 данных может иметь возможность заполнения из базы данных продавца заданными по умолчанию данными 215 ответа продавца, например имени продавца и адреса продавца. Например, после приема запроса предложения модуль продавца может осуществлять поиск конкретных выборок 235 элементов предложения и заполнять поля 238 данных для этих выборок 235 элементов предложения данными 215 ответа подходящего продавца.
Пример данных ответа продавца, выбранных из ответов заранее установленных продавцов, показан на Фиг.28. Если запрос предложения включает в себя выборку элементов предложения, требующую от продавца предоставить для проекта информацию о требуемом ресурсе, например вместе со ставками (расценками) ресурса, связанными с информацией о требуемом ресурсе, поле 238 данных может обеспечивать ссылки на другие web-страницы для выбора заранее установленных параметров профиля ресурса. Например, каждый профиль ресурса может указывать конкретный тип ресурса и связанную квалификацию, необходимую для профиля ресурса. Для обеспечения эффективного сравнения покупателем профилей ресурса и ставок продавец может выбирать из некоторого количества заранее установленных типов ресурсов и соответствующих квалификаций. Для осуществления выборок типа ресурса и квалификаций может быть обеспечена конфигурируемая и масштабируемая структура базы данных, которая дает возможность классифицировать требования продавца к конкретным ресурсам несловесным образом.
Примеры структур данных, используемых для выбора типа ресурса и соответствующих квалификаций, показаны в Таблицах 30-37. Структуры данных для простоты иллюстрированы представляемыми в табличном формате, в котором каждая таблица включает в состав все поля, необходимые для отображения пользователю-продавцу типов ресурсов и соответствующей квалификации для выбора из них и сохранения выбранного профиля ресурса в поле данных из соответствующей выборки элементов предложения. Таблицы являются связанными иерархическим и реляционным образом так, что к таблицам осуществляется доступ в конкретном порядке для отображения пользователю-продавцу типов ресурсов и соответствующих квалификаций, как описано ниже в связи с Фиг.29, на которой проиллюстрирована структура 800 таблицы базы данных, представляющая примерную схему данных, связываемую с полным ответом продавца на предложение взаимосвязью между ответом продавца на запрос предложения и запросом покупателя о предложении.
В Таблице 30 ниже проиллюстрированы примерные категории для сектора торгово-промышленной деятельности, такие как легкая промышленность, управленческая/профессиональная деятельность, учрежденческая и техническая. В каждой из категорий секторов торгово-промышленной деятельности имеются одна или несколько областей торгово-промышленной деятельности, как показано в Таблице 31, и в рамках каждой из областей торгово-промышленной деятельности имеется одно или несколько семейств торгово-промышленной деятельности, как показано в Таблице 32. Следовательно, чтобы выбрать для ответа на предложение конкретное семейство торгово-промышленной деятельности, связанное с типом ресурса, пользователь-продавец может выбрать категорию сектора торгово-промышленной деятельности и область торгово-промышленной деятельности, чтобы отобразить перечень семейств торгово-промышленной деятельности для выбора из них. После выбора семейства торгово-промышленной деятельности могут быть выбраны различные квалификации (общие функции и навыки торгово-промышленной деятельности), связанные с типом ресурса, и соотнесены с конкретным типом ресурса, как показано в Таблицах 33-37. Например, общие функции могут идентифицировать уровень квалификации, связанный с типом ресурса, категория навыков может идентифицировать типы навыков, обучение (подготовку) и опыт (стаж) работы, которым обладает тип ресурса, и один или несколько наборов навыков, связанных с каждой категорией навыков, могут идентифицировать конкретный опыт работы, связанный с типом ресурса. Кроме того, некоторые наборы навыков могут быть выделены с предпочтением над другими наборами навыков посредством установления уровня приоритета для каждого из наборов навыков для типа ресурса. Должно быть понятно, что можно обеспечивать другие варианты типа выбора ресурса и квалификации, причем система не ограничена конкретной конфигурацией и информацией, показанной в Таблицах 30-37. Более полная информация о профилировании ресурсов содержится в совместно поданной и совместно переуступленной заявке на патент США под номером 10/128,751, которая включена в настоящий документ посредством ссылки.
Примерная таблица секторов торгово-промышленной деятельности (tblBusSector) (сектор ТПД)
Примерная Таблица областей торгово-промышленной деятельности (tblBusArena) (область ТПД)
Примерная Таблица семейств торгово-промышленной деятельности (tblBusFamily) (семейство ТПД)
Примерные Общие функцииторгово-промышленной деятельности
Таблица Категорий навыков (tblCategory)
Таблица Навыков в соответствии с Категориями (tblSkillsMap)
Соответствие Семейства торгово-промышленной деятельности и Навыков (tblBusFamtoSkillCat) (семейство ТПД и категория навыков)
Примерный Деловой Приоритет Навыков
После представления на рассмотрение ответа продавца на запрос предложения все поля выборки элементов предложения заполнены данными предложения (либо данными запроса предложения, либо данными ответа продавца на запрос предложения), которое сохраняют в качестве предложения в системе (базе данных покупателя и базе данных продавца) иерархическим и реляционным образом, как показано в структуре 800 таблицы базы данных по Фиг.29. Примерные структуры данных для сохранения данных о предложении показаны в Таблицах 38-55, которые описаны в связи с Фиг.29.
В таблицах 38 и 39 проиллюстрированы примерные данные запроса предложения, связанные с конкретным запросом предложения, который может быть сохранен в базе данных в таблицах "tblRFX" ("запрос Х" (Request for Х)) 801 и "tblRFXSelectedBidItems" ("выбранные элементы предложения") 802, как показано на Фиг.29. Например, в таблице "tblRFX" 801 может быть сохранена общая информация относительно запроса предложения, такая как номер для отслеживания предложения, заданный системой запросу предложения, наименование запроса предложения, заданное инициатором, идентификатор инициатора запроса предложения, тип шаблона предложения, тип проекта, местонахождение проектной работы, объем предусмотренных сметой расходов для проекта, состояние запроса предложения (например, новый, представленный для рассмотрения, оцененный, принятый, и т.д.), приняли ли продавцы из базы данных верхнего уровня запрос предложения и требовалось ли какое-либо утверждение. Однако понятно, что также может быть включена другая информация предложения, и система не ограничена конкретной информацией, показанной в Таблицах 38 и 39.
Конкретные выборки элементов предложения, включенные в состав запроса предложения, и данные запроса предложения (комментарии покупателя), введенные инициатором для каждой из выборок элементов предложения, могут быть сохранены в таблице "tblRFXSelectedBidItems" 802. Каждая выборка элементов предложения может быть сохранена в виде отдельный записи в "tblRFXSelectedBidItems" 802, в которой каждая запись содержит все поля, показанные в Таблице 39. Таблица "tblRFXSelectedBidItems" 802 связана с общей таблицей "tblRFX" 801 информации о запросе предложения. Как описано выше в связи с Фиг.10, выборки элементов предложения, содержащиеся в таблице "tblRFXSelectedBidItems" 802, выбраны из таблицы "tblRFXBidItems" 403 и связаны с конкретным типом шаблона предложения, сохраненным в таблице "tblRFXBidTemplates" 405, через таблицу "tblRFXTemplateItemMatrix" 404.
Главная таблица предложения
(tblRFX - представление структуры БД)
Таблица Элементов Предложения RFX (tblRFXSelectedBidItems)
Примерная информация, имеющая отношение к отправке/объявлению (передаче) запроса предложения подходящим продавцам, показана ниже в Таблице 40, которая может быть сохранена в базе данных в таблице "tblRFXPost" ("почта") 803, как показано на Фиг.29. В примерных вариантах осуществления информация отправки относится к каждому конкретному продавцу, который принял запрос предложения, и может включать в себя, например, дату и время, в которое запрос предложения был представлен (отправлен/объявлен) квалифицированному продавцу, идентификатор административного пользователя, который отправил запрос предложения, идентификатор квалифицированного продавца, который принял запрос предложения, идентификатор ответа продавца на запрос предложения и балльную оценку, присвоенную продавцу, как описано ниже в связи с Фиг.31-35. Однако понятно, что в систему может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 40. Отдельная запись для каждого продавца, который принял запрос предложения, может быть сохранена в таблице "tblRFXPost" 803, в которой каждая запись включает в себя все поля, показанные ниже.
tblRFXPost
Примерная информация, имеющая отношение к приему продавцом запроса предложения и представлению ответа продавца на запрос предложения, показана в Таблице 41, которая может быть сохранена в базе данных в таблице "tblRFXResp" ("ответ на запрос") 804, как показано на Фиг.29. Например, такая информация о представлении ответа может включать в себя идентификатор ответа продавца на запрос предложения, состояние ответа продавца на запрос предложения, идентификатор продавца, дату представления продавцом ответа на запрос предложения и даты соглашений продавца о подтверждении конфиденциальности и намерении осуществить ответ. Примеры типов информации о состоянии, которая может быть включена в таблицу "tblRFXResp" 804, показана в Таблице 42, которая может быть сохранена в базе данных в таблице "tblRFXRespStatus" ("Состояние ответа на запрос") 805, как показано на Фиг.29. Таблицы "tblRFXResp" 804 и "tblRFXRespStatus" 805 связаны с таблицей "tblRFXPost" 803, которая в свою очередь связана с таблицей "tblRFX" 801, чтобы для запроса предложения связать информацию о представлении ответа продавца с информацией об отправке предложения. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблицах 41 и 42. Отдельная запись для каждого ответа продавца на запрос предложения может быть сохранена в таблице "tblRFXResp" 804, в которой каждая запись содержит поля, показанные в Таблице 41 ниже.
tblRFXResp
Примерные Данные из tblRFXRespStatus
В Таблице 43 проиллюстрированы примерные данные ответа продавца на запрос предложения в представляемом от продавца к покупателю ответе продавца на предложение, которые могут быть сохранены в базе данных в таблице "tblRFXRespMain" ("Основной ответ на запрос") 806, как показано на Фиг.29. Например, такие данные ответа продавца на запрос предложения могут включать в себя номер отслеживания предложения, идентификатор ответа продавца, идентификатор продавца, конкретную выборку элементов предложения, на которое ответил продавец, ответ продавца на эту конкретную выборку элементов предложения, какие-либо данные запроса предложения (комментарии покупателя), связанные с этой конкретной выборкой элементов предложения, идентификатор записи для ответа продавца на конкретную выборку элементов предложения и соответствующий ранг, присвоенный покупателем ответу продавца, как описано более подробно в связи с Фиг.31-35. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 43. Отдельная запись для каждой выборки элементов предложения, на которое отвечал продавец, сохраняется в "tblRFXRespMain" 806, в которой каждая запись содержит поля, показанные в Таблице 43. Таблица "tblRFXRespMain" 806 связана с "tblRFX" 801 и "tblRFXPost" 803, чтобы связать ответ продавца на запрос предложения с запросом предложения.
tblRFXRespMain
С одним или несколькими ответами продавца на выборки элементов предложения могут быть связаны один или несколько профилей ресурсов для конкретных ресурсов (подрядчиков), которые продавец идентифицировал в качестве необходимых, чтобы завершить проект. Профили ресурса могут быть созданы заранее или в виде части ответа продавца на запрос предложения. Профили ресурса формируются с использованием сектора торгово-промышленной деятельности, области торгово-промышленной деятельности, семейства торгово-промышленной деятельности, общих функций и квалификаций, обсужденных выше в связи с Фиг.28 и показанных в Таблицах 30-37 выше.
Примеры информации о профиле ресурса (тип ресурса и квалификация) для профилей ресурса показаны ниже в Таблицах 44-46, которые могут быть сохранены в базе данных в таблицах "tblResourceProfileMaster" ("основной профиль ресурсов") 807, "tblResourceProfileMasterSkills" ("квалификация для основного профиля ресурсов") 816 и "tblResourceProfileMasterGF's" ("общие функции для основного профиля ресурсов") 817, как показано на Фиг.29. В Таблице "tblResourceProfileMaster" 807 хранится тип ресурса профиля ресурсов (например, сектор, область и семейство торгово-промышленной деятельности), тогда как в таблице "tblResourceProfileMasterSkills" 816 хранятся квалификация в торгово-промышленной деятельности (наборы навыков и приоритеты наборов навыков), связанные с типом ресурса, и в таблице "tblResourceProfileMasterGF's" 817 хранятся общие функции для типа ресурса. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблицах 44-46. Отдельная запись для каждого профиля ресурсов включена в таблицы "tblResourceProfileMaster" 807, "tblResourceProfileMasterSkills" 816 и "tblResourceProfileMasterGF's" 817, в которых каждая из записей содержит все поля, показанные ниже в Таблицах 45-46. Таблица "tblResourceProfileMaster" 807 связана с таблицами "tblResourceProfileMasterSkills" 816 и "tblResourceProfileMasterGF's" 817, чтобы связать общие функции и наборы навыков с типом ресурса для каждого профиля ресурса.
tblResourceProfileMaster (представление структуры БД)
tblResourceProfileMasterGFs (представление структуры БД)
tblResourceProfileMasterSkills (представление структуры БД)
Выборочная информация, относящаяся к конкретным выбранным профилям ресурса(ов), представляемым для рассмотрения вместе с ответом продавца на запрос предложения, показана в Таблице 47 ниже, которая может быть сохранена в таблице "tblRFXResourceProiles" ("профили ресурса запроса") 818, показанной на Фиг.29. Например, такая информация о выбранном профиле ресурса может включать в себя идентификатор профиля ресурса и ожидаемое количество для этого конкретного выбранного профиля ресурса, которое необходимо, чтобы выполнить проект. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 47. Отдельная запись для каждого выбранного профиля ресурса для проекта сохраняется в "tblRFXResourceProfiles" 818, где каждая запись содержит все поля, показанные в Таблице 47 ниже. Таблица "tblRFXResourceProfiles" 818 связана с таблицей "tblRFXResourceProfileMaster" 807, чтобы связать конкретный тип ресурса, квалификацию и общие функции с выбранным профилем ресурса. Таблица "tblRFXResourceProfiles" 818 дополнительно связана с таблицей "tblRFXSelectedBidItems" 802 для связывания выбранных профилей ресурса с конкретными выборками элементов предложения, запрашивающими профили ресурса.
tblRFXResouceProfile (представление структуры БД)
В зависимости от запроса предложения в качестве части ответа продавца на одну или несколько выборок элементов предложения продавец также может предоставлять информацию о ценах, связанную с конкретными выбранными профилями ресурса для проекта. Примерная информация о цене ресурса показана в Таблице 48 ниже, которая может быть сохранена в базе данных в таблице "tblRFXResourcesProfilePricing" ("Цены для профиля ресурсов") 819, как показано на Фиг.29. Например, такая информация о ценах ресурса может включать в себя идентификатор профиля ресурса, идентификатор записи для ответа продавца на выборку элементов предложения, запрашивающую профиль ресурса и информацию о ценах, ожидаемое количество рабочих часов, в течение которых будет работать ресурс, связанный с профилем ресурса, ставки, связанные с профилем ресурса, и ожидаемую сумму по счетам для ресурса, связанного с профилем ресурса. Однако понятно, что может быть включена другая информация и система не ограничена конкретной информацией, показанной в Таблице 48. Отдельная запись для каждого ресурса, связанного с одним из выбранных профилей ресурса, сохраняется в таблице "tblRFXResourcesProfilePricing" ("цены для профиля ресурсов") 819, в которой каждая запись содержит поля, показанные в Таблице 48 ниже. Таблица "tblRFXResourcesProfilePricing" 819 связана с таблице "tblRFXResourceProfiles" 818 для связывания информации о ценах для конкретного ресурса с конкретным выбранным профилем ресурса. Кроме того, таблица "tblRFXResourcesProfilePricing" 819 связана с таблицей "tblRFXRespMain" 806 и таблицей "tblRFXSelectedBidItems" для связывания информации о цене для ресурса и выбранного профиля ресурса с ответом продавца на конкретную выборку элементов предложения.
tblRFXResourceProfilesPricing (представление структуры БД)
В дополнение к конкретным профилям ресурса и определению цен, ответ продавца на запрос предложения также может включать в себя информацию, связанную с видами материалов, необходимых для проекта. Примерная информация о материалах показана ниже в Таблице 49, которая может быть сохранена в базе данных в таблице "tblRFXRespMaterials" ("материалы в ответе") 822, как показано на Фиг.29. Например, такая информация о материалах может включать идентификатор записи ответа продавца на выборку элементов предложения, запрашивающую информацию о материалах, вид материала и стоимость материала. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 49. Отдельная запись о каждом виде материала сохраняется в таблице "tblRFXRespMaterials" 822, в которой каждая запись содержит поля, показанные в Таблице 49 ниже. Таблица "tblRFXRespMaterials" 822 связана с таблицей "tblRFXRespMain" 806 и таблицей "tblRFXSelectedBidItems" для связывания информации о материалах с ответом продавца на конкретную выборку элементов предложения.
tblRFXRespMaterials (представление структуры БД)
Ответ продавца на запрос предложения также может включать в себя информацию, относящуюся к определению фаз проекта. Информация об определении фаз показана ниже в Таблице 50, которая может быть сохранена в базе данных в таблице "tblRFXRespPhase" ("фазы в ответе") 823, как показано на Фиг.29. Например, для каждой фазы проекта информация об определении фаз может включать в себя идентификатор записи ответа продавца на выборку элементов предложения, запрашивающую информацию об определении фаз, номер конкретной фазы, описание фазы, ожидаемую продолжительность фазы и проектную сдачу/поставку в конце фазы (например, количество единиц для завершения или другие этапы проекта). Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 50. Отдельная запись для каждой фазы сохраняется в таблице "tblRFXRespPhase" ("Фазы в ответе") 823, в которой каждая запись содержит поля, показанные в Таблице 50 ниже. Таблица "tblRFXRespPhase" 823 связана с таблицей "tblRFXRespMain" 806 и таблицей "tblRFXSelectedBidItems" для связывания информации об определении фаз с ответом продавца на запрос предложения, осуществленным на конкретную выборку элементов предложения.
tblRFXRespPhase (представление структуры БД)
Все вопросы и ответы, объявленные продавцом и покупателем на доске объявлений о предложениях, и любые вопросы, представленные продавцу от покупателя относительно ответа продавца на запрос предложения, также могут быть сохранены в системе и связаны с конкретным ответом продавца на запрос предложения. Примерная информация о вопросах показана в Таблицах 51 и 52 ниже, которые могут быть сохранены в базе данных в таблицах "tblRFXQuestionsFromVendor" ("Вопросы от продавца") 820 и "tblRFXQuestionsFromBuyer" ("Вопросы от покупателя") 821, как показано на Фиг.29. Отдельные записи для каждого "вопроса продавца/ответа покупателя" и "вопроса покупателя/ответа продавца" сохраняются в таблицах "tblRFXQuestionsFromVendor" 820 и "tblRFXQuestionsFromBuyer" 821, в которых каждая запись содержит поля, показанные в Таблицах 51 и 52 ниже. Кроме того, таблицы "tblRFXQuestionsFromVendor" 820 и "tblRFXQuestionsFromBuyer" 821 связаны с таблицей "tblRFXRespMain" 806 для связывания вопросов с конкретным ответом продавца на запрос предложения.
tblRFXQuestionsfromVendor (представление структуры БД)
tblRFXQuestionsfromBuyer (представление структуры БД)
Ответ продавца на запрос предложения также может быть связан с подробностями о предшествующей проектной работе, которая была выполнена продавцом для оказания помощи в процессе ответа на запрос предложения. Пример подробностей о предшествующей проектной работе показан в Таблице 53 ниже, которая может быть сохранена в базе данных в таблице "tblRFXRespTrackRecord" ("запись отслеживания ответа") 824, как показано на Фиг.29. Например, такие подробности о предшествующей проектной работе могут включать идентификатор ответа продавца на запрос предложения, наименование проекта, имя покупателя, стоимость проекта, описание проекта, обсуждение используемых ресурсов (подрядчиков) для проекта, обсуждение рабочих характеристик продавца, даты начала проекта и даты завершения проекта. Понятно, что могут быть сохранены дополнительные подробности о предшествующей проектной работе, и система не ограничена конкретными подробностями о предшествующей проектной работе, показанными в Таблице 53.
tblRFXRespTrackRecord (представление структуры БД)
На Фиг.30 проиллюстрировано экранное представление примерной web-страницы, отображающей варианты выбора для покупателя, чтобы управлять запросом предложения и ответом продавца на запрос предложения. Из web-страницы управления запросом предложения пользователь-покупатель может представлять завершенный запрос предложения администратору (или квалифицированным продавцам), просматривать ответы продавца на запрос предложения, ранжировать ответы продавца на запрос предложения, представлять вопросы продавцу об ответе продавца на предложения, запрашивать от продавца повторное назначение цены, запрашивать собеседования по проекту с продавцами или собеседования по ресурсам с потенциальными ресурсами (подрядчиками) для участия в проекте, назначать предложение (проект) конкретному продавцу, распределять ресурсы для проекта или размещать запрос предложения на поддержание.
Как только покупатель принял один или несколько ответов продавца на конкретный запрос предложения, покупатель может ранжировать или иным образом сравнивать ответы продавца на запрос предложения для определения того, какому продавцу назначить проект. За счет использования заранее установленных элементов предложения в запросе предложения и ответах на предложения все ответы продавца на запрос предложения имеют одинаковый формат, давая возможность эффективного и действенного ранжирования и сравнения ответов продавца на запрос предложения. Следовательно, прежде чем начинать ранжирование ответов продавца на предложения, покупатель может выбрать один или несколько элементов предложения с целями ранжирования.
Примерные функциональные возможности для выбора ранжированных элементов предложения и ранжирования ответов продавца на выбранные ранжированные элементы предложения показаны на Фиг.31. Инструментальное средство 188, используемое для ранжирования, проиллюстрировано на Фиг.31 и предназначено для выбора ранжированных элементов предложения и ранжирования ответов продавца на запросы о предложении в соответствии с вариантами осуществления настоящего изобретения. Инструментальное средство 188 ранжирования может включать в себя любые аппаратные средства, программное обеспечение и/или программно-аппаратные средства для исполнения функций инструментального средства и может быть осуществлено на web-сервере 120 или дополнительном сервере (не показан).
В любой момент времени после создания запроса предложения осуществляющий ранжирование пользователь или ранжировщик (например, пользователь-покупатель или пользователь-администратор проекта), ответственный за ранжирование ответов продавца на запрос предложения, может осуществлять доступ к инструментальному средству ранжировании 188 для выбора с целями ранжирования одной или нескольких выборок 235 элементов предложения из перечня элементов предложений. Инструментальное средство ранжировании осуществляет доступ к перечню 194 элементов предложения, сохраненному в базе данных 155, извлекает выборки элементов предложения 235 из перечня 194 элементов предложения, которые включены в состав конкретного запроса предложения, идентифицированного ранжировщиком, и отображает выборки 235 элементов предложения ранжировщику посредством модуля 110 покупателя, web-сервера 120, сети 40 передачи данных и браузера 20a покупателя для выбора из них. Из выборок 235 элементов предложения ранжировщик может выбрать один или несколько ранжированных элементов 236 предложения и послать перечень ранжированных элементов 236 предложения на инструментальное средство 188 ранжирования.
После приема одного или нескольких ответов продавцов на запрос предложения инструментальное средство 188 ранжирования может осуществлять доступ к перечню 192 ответов продавца на предложения, чтобы извлечь данные 215 ответа продавца, связанные с одним из ранжированных элементов 236 предложения для одного из находящегося в перечне 192 ответов продавца на предложения. Данные 215 ответа на элементы предложения отображаются ранжировщику с целью ранжирования. На основании различных факторов (объективных и субъективных) относительно качества и информации, которые включены в состав отображаемых данных 215 ответа на элементы предложения, ранжировщик может задать ранг для этого ответа 215 на элементы предложения и передать ранг 260, соответствующий ответу на элементы предложения, на инструментальное средство ранжирования 188.
Инструментальное средство ранжирования 188 дополнительно взаимодействует с базой 155 данных, чтобы сохранить для продавца ранг 260 ответа на элементы предложения в перечне 198 рангов продавца, который содержит в перечне 192 ответов продавца на предложения ранги 260 ответов на элементы предложения для всех ранжированных элементов 236 предложения для каждого из ответов продавца на предложения. Кроме того, на основании всех рангов 260 ответов на элементы предложения, принятых инструментальным средством 188 ранжирования для всех ранжированных элементов 236 предложения для конкретного ответа продавца на запрос предложения, инструментальное средство 188 ранжирования может вычислить общую оценку (балл) 265 продавца для конкретного ответа продавца на запрос предложения и сохранить балл 265 продавца в перечне 198 рангов продавца.
Примерные этапы для выбора ранжированных элементов предложения и ранжирования ответов продавца на запрос предложения, использующие ранжированные элементы предложения, показаны на Фиг.32 и 33. Основные этапы обработки, выполняемые для ранжирования ответов на предложения, показаны на Фиг.32. После приема ответов продавца на запросы о предложении (этап 3200) идентифицируют выборки элементов предложения, подлежащие использованию с целями ранжировании (этап 3210). Выборки элементов предложения связаны с запросом предложения, запрашивая ответы продавца на запросы о предложении, и данные ответа продавца на запросы о предложении включаются в выборку элементов предложения, выбранных с целями ранжировании. Используя данные ответа продавца на запросы о предложении, находящиеся в ранжированных элементах предложения, ранжируют ответы продавца на предложения (этап 3220).
Более подробно процесс ранжирования показан на Фиг.33. После того, как запрос предложения создан, пользователю-покупателю предоставляется перечень выборок элементов предложения, связанных с запросом предложения (этап 3330). Из перечня выборок элементов предложения выбирается один или несколько ранжированных элементов предложения (этап 3305), и каждому ранжированному элементу предложения назначается весовой коэффициент (например, весовой процент) (этап 3310), чтобы некоторые ответы входили с большим весом, чем другие ответы, в окончательный балл. В некоторых вариантах осуществления весовые коэффициенты могут быть равными, таким образом исключая требование введения пользователем-покупателем конкретного весового коэффициента. Весовые коэффициенты для всех ранжированных элементов предложения должны быть заполнены до ранжирования ответов продавца на запросы о предложении (этап 3315).
После того, как все ранжированные элементы предложения выбраны и назначен весовой коэффициент, ранжировщику предоставляется перечень ответов продавца на запрос предложения (этап 3320), и ранжировщик выбирает для ранжирования один из ответов продавца на запрос предложения (этап 3325). После этого ранжировщик выбирает один из ранжированных элементов предложения (этап 3330), чтобы ранжировать данные ответа продавца на запрос предложения, включенные в ранжированные элементы предложения (этап 3335). Ранжировщик может ранжировать данные ответа продавца на запрос предложения, используя любые средства, доступные ранжировщику. В одном варианте осуществления ранжировщик может заранее устанавливать критерии ранжирования для конкретного ранжируемого элемента предложения, чтобы предоставить возможность системе автоматически ранжировать данные ответа продавца. Например, для ранжирования информации о ценах ранжировщик может заранее назначать ранги на определенные диапазоны цен, и система может автоматически обеспечивать ранг для определения цены ранжированного элемента предложения на основании цены, представленной в ответе продавца на запрос предложения. В других вариантах осуществления ранжировщик может сравнивать все данные ответа предложения продавца для конкретного ранжированного элемента предложения первоначально перед назначением рангов на основании относительных различий между данными ответа продавца на запрос предложения. В других вариантах осуществления ранжировщик может заранее установить контрольный перечень или пороговые значения для каждого ранга, который будет назначен конкретному ранжированному элементу предложения.
Ранг, назначенный данным ответа продавца для ранжированного элемента предложения, сохраняется в базе данных (этап 3340), и процесс повторяется для каждого ранжированного элемента предложения до тех пор, пока не будут ранжированы данные ответа продавца, включенные в каждый ранжированный элемент предложения, для конкретного ответа продавца на запрос предложения (этап 3345). После того, как все ранги заполнены, система вычисляет итоговый балл продавца на основании отдельных рангов, назначенных каждому ранжированному элементу предложения (этап 3350). Например, если возможными рангами являются A, B, C и D, то балл продавца может быть вычислен посредством назначения четырех пунктов для A, трех пунктов для B, двух пунктов для C и одного пункта для D.
Каждый ответ продавца на запрос предложения ранжируется таким же образом (этап 3355), чтобы дать возможность сортировать баллы продавцов в убывающем порядке (этап 3360) при отображении пользователю-покупателю (этап 3365). В дополнение к итоговому баллу, ранжировщику также могут предоставляться отдельные ранги для ранжированных элементов предложения, чтобы определить, являются ли необходимыми какие-либо повторные назначения цены. Обеспечивая ранжировщика итоговым баллом и индивидуальными рангами, ранжировщик может визуально определять, какой продавец имел самый высокий итоговый балл и какие продавцы имели самые высокие ранги для конкретных ранжированных элементов предложения, чтобы принять решение о том, какому продавцу предоставить проект. Однако понятно, что другие способы сравнения ответов на запрос предложения также могут использоваться с системой согласно настоящему изобретению вместо конкретных ранжирования и определения баллов, описанных в документе.
Экранные представления примерных web-страниц 61, которые могут быть отображены ранжировщику для выбора ранжированных элементов предложения и ранжирования ответов продавца на запрос предложения, показаны на Фиг.34A-34E. На Фиг.34A показано, что web-страница содержит перечень выборок 235 элементов предложения для выбора из него ранжировщиком. Для каждого из выбранных ранжированных элементов 236 предложения ранжировщик также может вводить весовой процент 850 для этого ранжированного элемента 236 предложения. Ранжировщик может корректировать весовые проценты 850 на основании заранее установленных критериев или личных предпочтений до тех пор, пока взвешенный процент 850 в итоге не станет равным ста процентам. Как описано выше, в других вариантах осуществления всем ранжированным элементам 236 предложения могут быть назначены равные веса, так что нет необходимости в отображении весовых процентов 850 или в выборе ранжировщиком.
Для ранжирования ответов продавца на запросы о предложении, как показано на Фиг.34B, ранжировщику может предоставляться web-страница, содержащая перечень конкретных ранжированных элементов 236 предложения, либо отображающая данные 215 ответа продавца на запрос предложения, либо представляющая ссылку на данные 215 ответа продавца на запрос предложения. Например, как показано на Фиг.34C, ссылка на профиль ресурса и связанная информацию о цене ресурса может обеспечиваться в порядке ранга конкретного ранжированного элемента предложения. Согласно Фиг.34B ранжировщику может дополнительно обеспечиваться подсказка для ввода ранга 855 для данных 215 ответа продавца на запрос предложения, связанного с ранжированным элементом предложения 236. В других вариантах осуществления ранги 855 могут автоматически назначаться системой на основании заранее установленных критериев ранжирования.
После ранжирования ответа продавца на запрос предложения, как показано на Фиг.34D, ранжировщику может предоставляться web-страница, отображающая все ранжированные элементы предложения 236, весовые проценты 850, назначенные ранжированным элементам предложения 236, и ранг 855 продавца, назначенный ранжировщиком каждому из ранжированных элементов 236 предложения. Кроме того, итоговый балл 860 продавца также может быть отображен, чтобы дать возможность ранжировщику определить итоговое качество ответа продавца на запрос предложения. Согласно Фиг.34E ответы продавцов на запрос предложения могут сопоставляться на основе итогового балла 860 продавца и индивидуальных рангах 855, назначенных каждому из ранжированных элементов 236 предложения.
Примеры структур данных, используемых для выбора ранжированных элементов предложения и сохранения рангов продавцов, показаны в Таблицах 54-56, приведенных ниже. Структуры данных для простоты иллюстрированы представляемыми в табличном формате, в котором каждая таблица включает в себя все поля, необходимые для отображения пользователю-покупателю выборок элементов предложения для выбора из них, и сохранения рангов и баллов, соответствующих ответам продавцов на запрос предложения. Таблицы связаны иерархическим и реляционным образом, как описано в связи с Фиг.35.
В Таблице 54 ниже показаны примерные выборки элементов предложения, которые могут быть включены в запрос предложения, и соответствующий ответ продавца на запрос предложения. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 54. Для каждой выборки элементов предложения имеется индикация того, является ли эта выборка элементов предложения ранжируемой. Например, не все выборки элементов предложения могут включать в себя данные ответа продавца для ранжирования. Поэтому только ранжируемые выборки элементов предложения отображают пользователю-покупателю для выбора из них.
Примерный перечень возможных ранжированных элементов предложения продавца (в соответствии с категорией)
Отдельный ранг сохраняется для каждого из ранжированных элементов предложения, как показано в Таблице 55 ниже, которая может быть сохранена в структуре 1100 таблицы базы данных в таблице "tblRFXGradeItems" ("ранг элементов") 825, как показано на Фиг.35. Наряду с назначенным рангом 855 для конкретного ранжированного элемента 236 предложения, таблица "tblRFXGradeItems" 825 может также включать идентификатор для ранжировщика пользователя-покупателя, весового процента 850 назначенного ранжированному элементу 236 предложения и идентификатор ответа продавца на запрос предложения, связанного с рангом 855. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 55. Каждый из рангов 855 продавца для каждого продавца сохраняется в отдельной записи в таблице "tblRFXGradeItems" 825, в которой каждая запись содержит поля, показанные ниже в Таблице 55. Кроме того, таблица "tblRFXGradeItems" 825 связана с таблицей "tblRFXRespMain" 806, которая связана с таблицей "tblRFX" 801, обе из которых описаны выше в связи с Фиг.29 для того, чтобы установить соответствие ранга 855 продавца с ответом продавца на предложения и запросом предложения. Кроме того, таблица "tblRFXGradeItems" 825 связана с таблицей "tblRFXSelectedBidItems" 802, чтобы связать ранг 855 продавца с конкретной выборкой элементов предложения 235.
Таблица Ранжированных элементов предложения (tblRFXGradeItems)
Вычисляемые баллы 865 для каждого из рангов 855 продавца для каждого элемента 235 предложения могут быть сохранены в виде показанных в Таблице 56, которая может быть сохранена в базе данных в таблице "RFXItemScoreVendor"("RFX элемент-балл-продавец") 826, как показано на Фиг.35. Отдельная запись для каждого ранжированного элемента предложения для каждого ответа продавца на запрос предложения сохраняется в таблице "tblRFXItemScoreVendor" 826, в которой каждая запись содержит поля, показанные в Таблице 56. Кроме того, итоговый балл 860, основанный на всех баллах продавца 865, сохраняемых в таблице "tblRFXItemScoreVendor" 826, также может быть сохранен в виде, показанном в Таблице 57, которая может быть сохранена в базе данных в таблице "tblRFXScoreVendor" ("балл продавца") 827, как показано на Фиг.35. Отдельная запись для каждого ответа продавца на запрос предложения сохраняется в таблице "tblRFXScoreVendor" 827, в которой каждая запись содержит поля, показанные в Таблице 57.
Таблица "tblRFXItemScoreVendor" 826 связана с таблицей "tblRFXGradeItems" 825, чтобы связать каждый балл 865 с подходящей рангом 855 для всех ранжированных элементов 236 предложения для конкретного ответа продавца на запрос предложения. Кроме того, таблица "tblRFXScoreVendor" 827 связана с таблицей "tblRFXItemScoreVendor" 826, чтобы связать все баллы 865 для всех ранжированных элементов 236 предложения для конкретного ответа продавца на запрос предложения с итоговым баллом 860 для этого конкретного ответа продавца на запрос предложения. Кроме того, таблица "tblRFXScoreVendor" 827 связана с описанной выше в связи с Фиг.29 таблицей "tblRFXPost" 803, чтобы обновлять таблицу "tblRFXPost" в соответствии с баллом продавца 860.
Таблицапоэлементного вычисления баллов продавца (tblRFXItemScoreVendor)
Таблица вычисления баллов продавца (tblRFXScoreVendor)
После принятия и ранжирования ответа продавца на запрос предложения, принимают и ранжируют, пользователь-покупатель может обеспечить продавцу возможность представления на рассмотрение повторного назначения цены для одного или нескольких ранжированных элементов предложения, чтобы повысить балл продавца. Например, продавец, которого пользователь-покупатель обычно выбирает или который имеет высокие ранги по другим ранжированным элементам предложения, может иметь более низкий балл чем другой продавец, и пользователю-покупателю может быть желательным дать продавцу возможность пересмотреть данные ответа продавца на запрос предложения для такого одного или нескольких ранжированных элементов предложения, которые имеют низкие ранги.
Примерные этапы для содействия процессу пересмотра цены показаны на Фиг.36. Когда ранжировщик уведомляется об одном или нескольких низких рангах для конкретного продавца по одному или нескольким ранжированным элементам предложения, ранжировщик может пригласить продавца для того, чтобы повторно назначить цену (сделать предложение) по одному или нескольким выбранным ранжированным элементам предложения (этапы 3600 и 3610). Приглашение к повторному назначению цены (этап 3620) может идентифицировать только конкретные ранжированные элементы предложения, которые продавцу разрешено повторно назначать, чтобы предотвратить от повторного назначения цены продавцом каких-либо других ранжированных элементах предложения, которые ранжировщик не хочет повторно ранжировать. Например, повторное назначение цены может включать в себя копию первоначального ответа продавца на запрос предложения и давать возможность выбора только этих повторно назначаемых элементов предложения пользователем-продавцом для ввода новых данных ответа продавца. Старые данные ответа продавца могут быть удалены или сохранены, наряду с новыми данными ответа в базе данных с целями справочной информации. Кроме того, приглашение повторного назначения цены может указывать ранг продавца для каждого повторно назначенного элемента предложения, наряду с ранжированием продавца для каждого повторно назначенного элемента предложения, и другую подобную информацию, например высший и низший ранги продавца для повторно назначенного элемента предложения.
Если продавец выбирает "повторно не назначать" в течение ограниченного покупателем выделенного интервала времени (этап 3630), первоначальное ранжирование продавца и определение баллов применяется к ответу продавца на запрос предложения (этап 3640). Однако, если продавец повторно назначает цену одному или нескольким повторно назначаемым элементам предложения (этап 3630), то пользователь-продавец может ввести новые данные ответа продавца в поля элементов предложения для выбранных повторно назначаемых элементов предложения (этап 3650). После приема повторно назначенных (элементов) (этап 3660) ранжировщик ранжирует повторно назначенные элементы предложения, используя новые данные ответа продавца и соответственно изменяет балл продавца (этап 3670).
Примерные этапы для предоставления предложения и введения параметров отслеживания проекта показаны на Фиг.37. Как только выполнено все ранжирование ответа продавца на запрос предложения и определение балла (этап 3700), предложение может быть предоставлено одному из продавцов. Если пользователь-покупатель имеет полномочия для выбора продавца на основании балла продавца и других показателях (например, личном предпочтении, знании репутации продавца, знании пригодности продавца, и т.д.) (этап 3705), пользователь-покупатель может выбрать продавца для проекта (этап 3710). В противном случае предложение присуждают продавцу, имеющему самый высокий балл (этап 3715).
После того, как продавец для проекта выбран, система уведомляет и администратора проекта (этап 3720), и назначенного продавца относительно решения о назначении предложения (этап 3725). После этого назначенный продавец и покупатель вступают в переговоры, чтобы окончательно исполнить постановления и условия проекта, как это выполняется традиционно (этап 3730). Если назначенный продавец и покупатель не могут договориться о постановлениях и условиях проекта (этап 3735), покупатель может повторно открыть процесс предложения, чтобы выбрать нового продавца на основании имеющихся баллов продавца и/или на основании новых ответов продавца на запросы о предложениях (этап 3740). Однако, если постановления и условия договора согласованы (этап 3735), то покупатель и назначенный продавец могут загружать в систему различные параметры отслеживания проекта (этап 3745), такие как дата начала проекта, даты завершения проекта, ожидаемые расходы по проекту (сумма заявок), распределенные ресурсы, график с определениями фаз проекта, график осуществления платежей по проекту, проектные сдачи/поставки, затраты на проектные материалы и затраты на проект, чтобы создать для проекта заявку на закупку. Понятно, что дополнительные параметры отслеживания проекта также могут быть загружены в систему, чтобы отслеживать выполнение проекта, и система не ограничена описанными параметрами отслеживания проекта. Как только заявка на закупку для проекта утверждена соответствующими ответственными за утверждение пользователями проекта администратором и продавцом (этап 3750), проект может начинаться.
Экранные представления примерных web-страниц 61 администратора проекта и продавца, предназначенные для загрузки в систему параметров 870 отслеживания проекта, показаны на Фиг.39A и 39B. Для администратора проекта, как показано на Фиг.39A, в систему может быть введена различная информация о заявках, такая как дата создания заявки на закупку, состояние заявки на закупку (которое может быть обновлено системой автоматически), сумма заявки на закупку, валюта заявки на закупку (например, доллары США), дата начала проекта и дата завершения проекта. Кроме того, администратор проекта также может вводить в систему различные постановления и условия договора проекта такие, как формулировка работы, сдачи/поставки товаров и услуг по проекту, договор проекта, материалы по проекту, распределенные для проекта ресурсы и учитываемые (для оплаты) ставки, затраты на проект, график определения фаз проекта и график осуществления платежа по проекту. Кроме того, администратор проекта может распределять административных пользователей на различные административные пользовательские функции, которые еще не были распределены для проекта. Кроме того, в систему также могут быть введены другие финансовые параметры отслеживания проекта, применимые к проекту, такие как назначения учетных записей, коды бухгалтерской книги, коды учетного отдела, коды проекта, коды налогообложения и предприятия учета.
Как показано на Фиг.39B, продавец в качестве администратора проекта может осуществлять доступ к введенным покупателем данным, чтобы изменить в системе предварительно введенные параметры 870 отслеживания проекта и/или ввести в систему новые параметры 870 отслеживания проекта. Например, продавец может ввести одно или несколько постановлений и условий проекта, описанных выше. Стороны могут договориться о том, кто из них собирается вводить параметры 870 отслеживания проекта, или обе стороны могут вводить и/или изменять параметры 870 отслеживания проекта, и система может обеспечивать уведомление обеих сторон, если сделаны какие-либо изменения. Понятно, что другие параметры отслеживания проекта также могут быть введены в систему, и система не ограничена параметрами отслеживания проекта, которые показаны на Фиг.39A и 39B.
Например, как показано на Фиг.40A и 40B, информация 875 о налогообложении также может быть введена в систему в виде части параметров 870 отслеживания проекта. Информация 875 о налогообложении может использоваться покупателем и продавцом, чтобы гарантировать, что в проекте учтены все налоговые управления и применимые объемы налогообложения с целями финансового администрирования и обязательств по уплате налогов. Как показано на Фиг.40A и 40B, когда номер строки для элемента (статьи) заявки создается для некоторого направления деятельности, например для материала, используемого продавцом в процессе осуществления проекта, покупатель и продавец могут определять в пределах системы всю подходящую информацию о транзакции, необходимую для надлежащей оценки суммы налога.
Например, как показано на Фиг.40A, в качестве части содержимого заявки на материалы покупатель и продавец могут создавать или обновлять информацию 875 о налогообложении, вводя информацию о местонахождении, относящуюся к местонахождению покупателя, местонахождению изготовления, адресу отгрузки, физическому адресу поставки, местонахождению продавца и т.д., которые могут указывать на соответствующее налоговое управление. Кроме того, если покупатель освобожден от обложения налогом, то покупатель может указать причину освобождения от обложения налогом. И покупатель, и продавец могут дополнительно создавать или обновлять информацию 875 о налогообложении, вводя применимые налоговые управления и налоговые процентные ставки. Как показано на Фиг.40B, в случае, когда заказ на закупку для конкретной деятельности представлен для платежа, система может осуществлять доступ к налоговым процентным ставкам, предварительно введенным покупателем и продавцом для конкретной деятельности, и вычислять сумму налога для заказа на закупки. Информация 875 о налогообложении, включающая налоговое управление, процентные ставки, суммы и другую относящуюся к налогообложению информацию о транзакции, сохраняется в базе данных с обеспечением доступа для зарегистрированных пользователей.
Примерный процесс для ввода и обработки информации о налогах показан на Фиг.40C. Когда заявка на закупку создана покупателем/администратором, который определяет все составляющие деятельности относительно проекта (параметры отслеживания проекта), включая людской труд, расходы, материалы, сдачи/поставки, единицы выполненной работы и другие прочие расходы, местонахождение пункта поставки или реализации товаров/услуг (этап 4000) и информацию о налогообложении, система может осуществлять заявку на закупку, включающую информацию о налогообложении, доступную для рассмотрения подходящему продавцу (этап 4005). В это время продавец также может вводить в систему любую подходящую информацию о налогообложении и утверждать заявку на закупку (этапы 4010 и 4015). Полная заявка на закупку, включающая в свой состав утвержденную продавцом информацию о налогообложении покупателя и информацию о налогообложении продавца, предоставляется покупателю для окончательного утверждения (этапы 4020 и 4025).
После утверждения покупателем создается заказ продавца на закупку, который выбирается продавцу (этап 4030) для начала работы по проекту (этап 4035). В начале проекта продавец выполняет один или несколько заказов на закупку указанных товаров или услуг (этап 4040). Если товар/услуга относятся к оплачиваемым по времени расходам подрядчика, подрядчик заполняет свою хронометражную карту (этап 4045), как описано более подробно ниже в связи с Фиг.42-47. Для всех других товаров/услуг продавец вводит информацию документа о гарантиях платежа (ваучер) (этап 4050), как описано более подробно ниже в связи с Фиг.48-50. После этого ваучер направляется означенному пользователю-покупателю для рассмотрения (этап 4055). После утверждения ваучера покупателем администратор системы может создавать файл (дело) составления счетов к оплате, который импортирует любую применимую сумму налога, вычисленную с использованием предварительно введенных налоговых процентных ставок, если применимо, и может представлять счет покупателю на его оплату (этап 4060). После этого покупатель осуществляет платеж администратору (этап 4065), и администратор осуществляет платеж продавцу (этап 4070). Администратор поддерживает данные о финансовых транзакциях в файле составления счетов, связанном с оплатой по документу о гарантиях платежа, разрешает доступ к данным финансовых транзакций зарегистрированному персоналу покупателя или продавца (этап 4075), и может произвольно загружать данные финансовых транзакций в базу данных верхнего уровня для последующей обработки (этап 4080), как описано более подробно ниже в связи с Фиг.59.
В качестве другого примера параметров отслеживания проекта, которые могут быть введены в систему, в ходе окончательных переговоров покупатель может запросить продавца представить для покупателя резюме кандидатов на ресурс (фактических подрядчиков) для утверждения, чтобы гарантировать, что позиции профиля ресурса, включенные в ответ продавца на запрос предложения, заполнены фактическими кандидатами с такими профилями ресурса. Примерные структуры данных для представления кандидатов на ресурс и рассмотрения кандидатов на ресурс показаны в Таблицах 58 и 59.
В Таблице 58 проиллюстрирована примерная информация о кандидате на ресурс, которая может быть представлена для каждого кандидата на ресурс, выбранного продавцом для позиции профиля ресурса в проекте. Например, информация о кандидате на ресурс может включать в себя номер для отслеживания предложения, соответствующий конкретному предложению (запрос предложения и ответ на запрос предложения), связанному с кандидатом на ресурс, идентификатор профиля ресурса для кандидата на ресурс, личную информацию о кандидате на ресурс, информацию о продавце, резюме кандидата на ресурс и состояние передачи на рассмотрение кандидата на ресурс. В Таблице 59 проиллюстрирована различная информация о состоянии передачи на рассмотрение ресурса, которая может быть включена в Таблицу 58. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 58.
Примерная Таблица передачи ресурса на рассмотрение (представление структуры БД)
Примерная Таблица состояний передачи ресурса на рассмотрение (представление данных)
Примерные этапы для утверждения кандидатов на ресурс показаны на Фиг.38. Для каждого профиля ресурса, включенного в ответ продавца на запрос предложения, продавец для позиции профиля ресурса представляет резюме потенциального кандидата на ресурс (этап 3800). Покупатель рассматривает все резюме и распределяет по позициям профиля ресурса квалифицированных кандидатов на ресурс (этап 3810).
Если один или более кандидатов на ресурс не являются подходящими (например, резюме не указывает, что кандидат на ресурс имеет необходимые навыки для профиля ресурса) (этап 3820) и нет никаких других подходящих кандидатов на позицию профиля ресурса (этап 3830), то покупатель может повторно открыть процесс предложения, чтобы обеспечить другого продавца для проекта, который может обеспечивать необходимые ресурсы (этап 3840). Однако, если все позиции профиля ресурса могут быть заполнены подходящими кандидатами на ресурс, то покупатель и/или продавец вводит информацию о ресурсе, связанную с каждым из назначенных кандидатов для ресурса (подрядчиков) в базу данных подрядчика (этап 3850). Например, в базу данных подрядчика может быть введена личная информация относительно подрядчика, такая как имя подрядчика, адрес, номера телефонов и номер служащего. Кроме того, в базу данных подрядчика может быть введена конкретная, относящаяся к проекту информация о подрядчике, такая как общее количество зарегистрированных, учитываемых для оплаты рабочих часов, учитываемых для оплаты расценок, общая сумма и тип зарегистрированных расходов и любых соглашений или документов, которые подрядчик должен исполнить или обеспечить до начального этапа работы.
Как только информация о подрядчике введена, система может аутентифицировать подрядчика для целей отслеживания времени и доступа к системе (этап 3860). Например, система может предоставлять подрядчику пользовательское имя и пароль с целью регистрации в системе и аутентификации. Кроме того, система может потребовать, чтобы подрядчик исполнил одно или несколько соглашений (например, посредством оперативного подтверждения условий соглашений) и/или обеспечил один или несколько документов перед разрешением доступа к системе хранения времени.
Экранное представление примерной web-страницы 61, отображаемой подрядчику после начальной регистрации в системе и аутентификации, показано на Фиг.42. Web-страница приводит перечень нескольких документов, которые должны быть исполнены прежде, чем подрядчик может начинать работать над проектом. Например, подрядчику может потребоваться подписать соглашение об Интеллектуальной собственности, соглашение об Конфиденциальности, соглашение о Кодексе поведения и соглашение о Подтверждении временной работы. Щелчком на каждом из перечисленных документов web-страница, показывающая соглашение, может быть отображена подрядчику, и подрядчик может щелкнуть на кнопке принятия, чтобы исполнить соглашение. Примерные структуры базы данных для сохранения информации о подрядчике и гарантирования, что соответствующие документы были приняты от подрядчика или согласованы с подрядчиком, показаны в Таблицах 60-63 ниже. Таблица 60 приводит перечень различных примерных документов, которые либо должны быть приняты от подрядчика, либо должны быть исполнены подрядчиком на некотором этапе проекта. Таблица 60 также приводит перечень временных ограничений для принятия или исполнения таких документов. Таблица 61 приводит перечень информации о подрядчике, например идентификатор подрядчика, зарегистрированное количество учитываемых для оплаты рабочих часов, зарегистрированную сумму расходов, дату исполнения различных документов и тип подрядчика. Таблица 62 приводит конкретный документ и идентифицирует, исполнил ли или представил документ подрядчик и дату этого исполнения или представления. Понятно, что отдельную запись для каждого документа сохраняют, применяя формат Таблицы 62. Таблица 63 иллюстрирует различную выборочную информацию, идентифицирующую тип подрядчиков, такую как количество дней, в течение которых подрядчик работал и не работал для покупателя. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблицах 60-63.
Примерная Таблица документов подрядчика
Примерная Таблица подрядчиков
Примерная таблица исполнительныхдат для подрядчика
Примерная Таблица типов подрядчиков
(представление структуры БД)
Примеры структур данных, используемых для сохранения параметров отслеживания проекта, показаны при этом в Таблицах 64-79. Структуры данных для простоты проиллюстрированы представляемыми в табличном формате, в котором каждая таблица включает в себя все поля, необходимые для отслеживания выполнения проекта. Таблицы связаны иерархическим и реляционным образом, как описано в связи с Фиг.41.
В таблице 64 ниже проиллюстрирована примерная общая информация о заявке на закупку, которая может быть сохранена в базе данных в таблице "tblPurchaseReq" ("заявка на закупку") 1000, как показано на Фиг.41. Например, такая общая информация о закупке может включать в себя идентификатор, заданный системой заявке на закупку, покупателя и продавца, дату создания заявки, сумму заявки, номер отслеживания предложения, соответствующий предложению (запрос предложения и ответ на запрос предложения), связанному с заявкой на закупку, дату начала и завершения проекта, наряду с любой другой подходящей информацией о заявке на закупку. Однако понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 64. Согласно структуре 1150 таблицы базы данных по Фиг.41 таблица "tblPurchaseReq" 1000 связана с таблицей "tblPurchaseReqContractors" ("подрядчики заявки на закупку") 1012 и таблицей "tblluContractorTypes" ("типы подрядчиков") 1013, которые включают в себя информацию в формате структуры данных, соответствующем Таблицам 61 и 63 соответственно, для связывания назначенных подрядчиков с заявкой на закупку.
tblPurchaseReq
В Таблицах 65-70 проиллюстрирована примерная определенная для заявки на закупку информация, связанная с кодами налогообложения, учетными предприятиями, учетными отделами, кодами проекта, назначениями учетных записей и другой подобной конкретной для покупателя информации о заявке на закупку, которая может быть сохранена в базе данных в соответствующих таблицах "tblPurchaseReqTaxCode" ("код налога - заявка на закупку") 1001, "tblPurchaseReqAcctPlant" ("учетное предприятие - заявка на закупку") 1002, "tblPuchaseReqAcctCostCenter" ("учетный отдел - заявка на закупку") 1003, "tblPurchaseReqProjectCodes" ("коды проекта - заявка на закупку") 1004, "tblPurchaseReqAcctGL" (учетная запись GL - заявка на закупку) 1005 и "tblPurchaseReqAcctAssignment" ("распределение учетных записей - заявка на закупку") 1006, как показано на Фиг.41. Однако понятно, что могут быть включены дополнительные таблицы и информация, связанная с заявками на закупку, в зависимости от требований к заявке на закупку. Таблицы "tblPurchaseReqTaxCode" 1001, "tblPurchaseReqAcctPlant" 1002, "tblPuchaseReqAcctCostCenter" 1003, "tblPurchaseReqProjectCodes" 1004, "tblPurchaseReqAcctGL" 1005 и "tblPurchaseReqAcctAssignment" 1006 связаны с таблицей "tblPurchaseReq" 1000 для связывания конкретной информации для заявки на закупку с общей информацией о заявке.
tblPurchaseReqTaxCodes
tblPurchaseReqAcctPlant
tblPurchaseReqAcctCostCenter
tblPurchaseReqProjectCodes
tblPurchaseReqAcctGL
tblPurchaseReqAcctAssignment
В Таблицах 71-75 проиллюстрирована примерная информация об оплате заявки, относящаяся к заявке на закупку. Например, такая информация об оплате заявки может включать в себя сумму платежа, основанную на проектных сдачах/поставках (например, товары и услуги, поставленные в конце проекта или в течение фаз проекта), сумму платежа, основанного на временных интервалах, сумму платежа, основанного на количестве завершенных единиц, сумму платежа, основанного на проектных материалах, и сумму платежа, основанного на проектных расходах. На Фиг.41 показана информация об оплате заявки, сохраняемая в базе данных в таблицах "tblPurchaseReqPayDeliverable" ("заявка на закупку - оплата сдач/поставок") 1007, "tblPurchaseReqPayTimeSpan" ("заявка на закупку - оплата по промежуткам времени") 1008, "tblPurchaseReqPayUnits" ("заявка на закупку - оплата единиц") 1009, "tblPurchaseReqPayMaterials" ("заявка на закупку - оплата материалов") 1010 и "tblPurchaseReqPayProjectExpenses" ("заявка на закупку - оплата затрат на проект") 1011. Каждая из таблиц "tblPurchaseReqPayDeliverable" 1007, "tblPurchaseReqPayTimeSpan" 1008, "tblPurchaseReqPayUnits" 1009, "tblPurchaseReqPayMaterials" 1010 и "tblPurchaseReqPayProjectExpenses" 1011 связана с таблицей "tblPurchaseReq" для связывания информации о платежах с общей информацией о заявках на закупку.
Понятно, что могут быть включены дополнительные таблицы или информация, в зависимости от требований к заявке на закупку. Кроме того, понятно, что одна или несколько таблиц платежа могут быть включены в зависимости от проекта. Также понятно, что отдельная запись для каждой суммы платежа включается с примением формата одной из Таблиц 71-75 ниже.
Примерная таблица tblPurchaseReqPayDeliverable
(представление структуры БД)
Примерная таблица tblPurchaseReqPayTimeSpan
(представление структуры БД)
Примерная таблица tblPurchaseReqPayUnits
(представление структуры БД)
Примерная таблица tblPurchaseReqPayMaterials
(представление структуры БД)
Примерная таблица tblPurchaseReqPayMaterials
(представление структуры БД)
В Таблицах 76 и 77 ниже проиллюстрирована примерная информация, связанная со ставками оплаты труда для подрядчиков, назначенных для выполнения заявки на закупку. Например, информация о ставке оплаты труда подрядчика может указывать тип оплаты (например, почасовая, фиксированная, сверхурочная, и т.д.) и сумму ставки (например, учитываемой ставки оплаты в час, учитываемой ставки оплаты за сверхурочный час, учитываемой суммы оплаты). Информация о ставке оплаты может быть сохранена в базе данных в таблицах "tblPurchaseReqPayRates" ("заявка на закупку - ставки оплаты труда") 1014 и "tblluContractorPayRateTypes" ("подрядчик - типы ставок оплаты труда") 1015, которые показаны на Фиг.41 связанными с таблицей "tblPurchaseReq" 1000 для связывания информации о ставке с заявкой на закупку. Понятно, что отдельная запись о ставке оплаты для каждого типа ставки оплаты для каждого подрядчика может быть сохранена в таблице "tblPurchaseReqPayRates" 1014. Также могут быть включены дополнительные таблицы или информация в зависимости от требований к заявке на закупку.
Примерная tblPurchaseReqPayRates (представление структуры БД)
tblluContractorPayRateTypes (представление структуры БД)
В Таблицах 78 и 79 ниже проиллюстрирована примерная информация об оплате, связанная с расходами подрядчика, в случае подрядчиков, назначенных для выполнения заявки на закупку. Например, информация о расходах подрядчика может указывать тип расходов и максимальную сумму, выделенную на расходы. Информация о расходах подрядчика может быть сохранена в базе данных в таблицах "tblPurchaseReqPayContractorExpenses" ("оплачиваемые расходы подрядчика на заявку на закупку") 1016 и "tblluContractorPayExpenseTypes" ("типы оплачиваемых расходов подрядчика") 1017, которые показаны на Фиг.41 связанными с таблицей "tblPurchaseReq" 1000, для связывания информации о расходах подрядчика с заявкой на закупку. Понятно, что отдельная запись о расходах подрядчика для каждого типа расходов подрядчика для каждого подрядчика может быть сохранена в таблице "tblPurchaseReqPayContractorExpenses" 1016. Кроме того, могут быть включены дополнительные таблицы или информация, в зависимости от требований к заявкам на закупку.
tblPurchaseReqPayContractorExpenses
(представление структуры БД)
tblluContractorPayExpenseTypes (представление структуры БД)
ДЕЯТЕЛЬНОСТЬ ПОСЛЕ ПРЕДЛОЖЕНИЯ
После того как проект начат, администратор проекта (или покупатель) может осуществлять контроль за ходом выполнения проекта с использованием системы отслеживания времени, в которой подрядчики вводят время в хронометражные карты для выполненной проектной работы. Хронометражные карты могут сохраняться, чтобы осуществлять доступ к информации о выполнении проекта для получения информации об оплате заявки и/или формировать документы об обязательствах по платежам на основании отработанного времени в зависимости от информации об оплате заявки. Например, если сумма оплаты заявки была основана по меньшей мере частично на ожидаемом количестве учитываемых часов для конкретного подрядчика по конкретной ставке оплаты труда и подрядчик завершил проект за количество учитываемых часов ниже ожидаемого значения, администратор проекта и продавец могут повторно договориться о сумме оплаты заявки, которая была первоначально установлена для оплаты на основании сдач/поставок, временных интервалов или единиц.
На Фиг.43 проиллюстрированы примерные этапы для осуществления системы отслеживания времени в системе согласно настоящему изобретению. После того, как подрядчик заполнил всю необходимую документацию и зарегистрирован для входа в систему отслеживания времени, подрядчик может входить в систему отслеживания времени (этап 4300), чтобы в хронометражную карту ввести хронометражную информацию (этап 4310), связанную с количеством рабочих часов, отработанных подрядчиком, (например, запись о сохраняемом времени для подрядчика). Хронометражная информация может быть введена в любое время, в которое система отслеживания времени является доступной. Например, система отслеживания времени может быть доступной только в конкретные моменты времени (например, конец недели, начало недели, и т.д.), как определено администратором проекта, или в течение того времени, в которое система отслеживания времени не находится в автономном режиме.
После того, как подрядчик ввел хронометражную информацию в хронометражную карту, хронометражная карта предоставляется администратору проекта (этап 4325) для рассмотрения и утверждения (этап 4330). Если хронометражная карта не утверждена (этап 4340), то подрядчик и продавец уведомляются о том, что хронометражная карты отклонена (этап 4350), и подрядчику дается указание осуществить доступ в систему отслеживания времени для изменения хронометражной карты (этап 4300). Например, если подрядчик не полностью заполнил хронометражную карту, хронометражная информация (например, количество рабочих часов), введенная в хронометражную карту, не является стандартной, или необоснованна, или администратору проекта известно, что хронометражная информация является неправильной, хронометражная карта может быть отклонена. Если хронометражная карта утверждена (этап 4340), все соответствующие записи в системе обновляются в зависимости от хронометражной информации (этап 4360), и любые подлежащие оплате документы с обязательствами по платежам, связанные с хронометражной информацией, извлекаются для обработки счета (этап 4370). Например, если оплата заявки основана на количестве часов, отработанных в конкретный временной интервал, то подлежащее оплате обязательство по платежам должно быть сформировано на основании хронометражной информации, введенной подрядчиком.
Экранные представления примерных web-страниц 61, предоставляемых подрядчику посредством системы отслеживания времени, показаны на Фиг.44 и 45. Примерная домашняя страница системы отслеживания времени проиллюстрирована на Фиг.44. Из домашней web-страницы подрядчик может создавать новую хронометражную карту, повторно вызывать временно сохраненные хронометражные карты с целями заполнения или просматривать предварительно представленные хронометражные карты. Кроме того, если подрядчику разрешено вводить расходы подрядчика (в зависимости от заявки на закупку), подрядчик может создавать новый расходный документ с обязательством по платежам, вызывать временно сохраненные расходные документы с обязательствами по платежам для заполнения или просмотра ранее представленных расходных документов с обязательствами по платежам.
Чтобы создать новую хронометражную карту (или заполнить временно сохраненную хронометражную карту), как показано на Фиг.45, подрядчик может вводить различную информацию 1150 отслеживания времени в хронометражную карту 1100. Например, подрядчик может вводить неделю даты завершения работы, код проекта для данного проекта и учетный отдел, ответственный за оплату. Кроме того, подрядчик может вводить количество часов по норме, отработанных в каждый день, и количество сверхурочных часов, отработанных в каждый день (по каждой сверхурочной ставке оплаты труда). Понятно, что другая хронометражная информация также может быть введена подрядчиком, и система не ограничена конкретной хронометражной информацией, показанной на Фиг.45.
Экранное представление примерной web-страницы 61, отображаемой администратору проекта для рассмотрения представленной хронометражной карты, показано на Фиг.46. В дополнение к вводимой информации об отслеживаемом времени, администратор проекта может обеспечиваться другой подходящей информацией о заявке на закупку, связанной с хронометражной картой, такой как текущая фаза проекта, код общей бухгалтерской книги, код налога за использование, код назначения учетной записи и код предприятия учетной записи. На основании отображенной информации об отслеживаемом времени администратор проекта может либо отклонить хронометражную карту, либо утвердить хронометражную карту. Если администратор проекта отклоняет хронометражную карту, то администратору проекта может быть отображено всплывающее окно, предоставляющее причину для отклонения хронометражной карты. Понятно, что другая информация может быть отображена администратору проекта с целями утверждения хронометражной карты, и система не ограничена конкретной информацией, показанной на Фиг.46.
Примерные структуры базы данных, предназначенные для сохранения хронометражной карты и расходных документов с обязательствами по платежам подрядчика, показаны в Таблицах 80-83. Структуры данных для простоты проиллюстрированы представляемыми в табличном формате, в котором каждая таблица включает в себя все поля, необходимые для сохранения хронометражных карт и расходных документов с обязательствами по платежам подрядчика. Таблицы связаны иерархическим и реляционным образом с другими таблицами, сохраняемыми в базе данных, как описано в связи с Фиг.47.
В Таблице 80 ниже проиллюстрирована примерная общая хронометражная информация, которая может быть сохранена в структуре 1160 таблицы базы данных в таблице "tblTimeCard" ("хронометражная карта") 1050, как показано на Фиг.47. Например, информация об отслеживаемом времени может включать в себя идентификатор хронометражной карты, соответственный идентификатор заявки на закупку, идентификатор подрядчика, идентификатор продавца, указание того, является ли введенное время учитываемым временем для формирования записи о составлении счетов, дата завершения недели, связанная с хронометражной картой, дата создания, дата рассмотрения и указание того, была ли утверждена хронометражная карта. Понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 80. Таблица "tblTimeCard" 1050 показана на Фиг.47, связанной с таблицей "tblPurchaseReqContractors" 1012, которая связана с таблицей "tblPurchaseReq" 1000 (обе эти таблицы описаны выше в связи с Фиг.41), для связывания хронометражной карты с подрядчиком и заявкой на закупку. Кроме того, различные другие таблицы, показанные на Фиг.41, проиллюстрированы на Фиг.47, чтобы показать взаимосвязи между различными таблицами заявки на закупку и хронометражной карты и таблицами расходных документов с обязательствами по платежам подрядчика.
Примерный tblTimeCard (представление структуры БД)
Идентификатор состояния хронометражной карты, сохраненный в таблице "tblTimeCard" 1050, может быть выбран из таблицы "tblluTimeCardStatus" 1051, которая хранит типы состояний хронометражной карты (например, временно сохраняемая, представленная, утвержденная, отклоненная, и т.д.) и ассоциированные с ними идентификаторы состояний хронометражной карты.
В Таблице 81 проиллюстрирован пример подробной хронометражной информации, которая может быть сохранена в базе данных в таблице "tblTimeCardDetails" ("подробная хронометражная карта") 1052, как показано на Фиг.47. Например, такая подробная хронометражная информация может включать в себя количество часов, введенных в качестве отработанных в конкретный день для конкретного типа ставки, ставку оплаты, связанную с типом ставки, и другую подробную хронометражную информацию. Таблица "tblTimeCardDetails" 1052 показана связываемой с таблицей "tblTimeCard" 1050, чтобы связать подробную хронометражную информацию с общей хронометражной информацией. Кроме того, таблица "tblTimeCardDetails" 1052 связана с таблицей "tblluDayCode" 1053, чтобы связать код дня, сохраненный в таблице "tblTimeCardDetails" 1052, с конкретным днем. Понятно, что отдельная запись в формате таблицы 81 сохраняется в таблице "tblTimeCardDetails" 1052 для каждого типа ставки по каждому дню, для которого подрядчик вводит время. Также могут быть включены другие таблицы и хронометражная информация, и система не ограничена конкретными таблицами и хронометражной информацией, показанной на Фиг.47.
Примерная tblTimeCardDetails (представление структуры БД)
В Таблице 82 ниже проиллюстрирована примерная общая информация о расходном документе с обязательствами по платежам подрядчика, которая может быть сохранена в базе данных в таблице "tblContractorExpenseVoucher" ("расходный документ с обязательствами по платежам подрядчика") 1054, как показано на Фиг.47. Например, такая общая информация о расходном документе с обязательствами по платежам подрядчика может включать в себя идентификатор расходного документа с обязательствами по платежам, соответственный идентификатор заявки на закупку, идентификатор подрядчика, идентификатор продавца, неделю даты завершения, связанной с денежным расходным документом, дату создания, дату рассмотрения и указание того, был ли утвержден расходный документ с обязательствами по платежам. Понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 82. Таблица "tblContractorExpenseVoucher" 1054 связана с таблицей "tblPurchaseReqContractors " 1012, которая связана с таблицей "tblPurchaseReq " 1000 (обе описаны выше в связи с Фиг.41), для связывания расходного документа с обязательствами по платежам подрядчика с конкретным подрядчиком и заявкой на закупку.
Обычная tblContractorExpenseVoucher
(представление структуры БД)
В Таблице 83 проиллюстрирован пример подробной информации о расходном документе с обязательствами по платежам подрядчика, которая может быть сохранена в базе данных в таблице "tblContractorExpenseVoucherDetails" ("подробности расходного документа с обязательствами по платежам подрядчика") 1055, как показано на Фиг.47. Например, такая подробная информация о расходном документе с обязательствами по платежам может включать в себя сумму расхода по конкретному типу расходов в конкретный день и другую подробную информацию о расходном документе с обязательствами по платежам. Таблица "tblContractorExpenseVoucherDetails" 1055 связана с таблицей "tblContractorExpenseVoucher" 1054 для связывания подробной информации о расходном документе с обязательствами по платежам с общей информацией о расходном документе с обязательствами по платежам. Кроме того, таблица "tblContractorExpenseVoucherDetails" 1055 связана с таблицей "tblluDayCode" 1053 по соответственному коду дня, сохраняемому в таблице "tblContractorExpenseVoucherDetails" 1055, с конкретным днем. Понятно, что отдельная запись в формате таблицы 83 сохраняется в таблице "tblContractorExpenseVoucherDetails" 1055 для каждого типа расходов по каждому дню, для которого подрядчик вводит сумму. Могут быть включены другие таблицы и информация о расходном документе с обязательствами по платежам подрядчика, и система не ограничена конкретными таблицами и информацией о расходном документе с обязательствами по платежам подрядчика, показанными на Фиг.47.
tblContractorExpenseVoucherDetails
(представление структуры БД)
Согласно Фиг.48 имеются некоторое различные типы информации 1160 о документах с обязательствами по платежам, которая может быть введена в систему и сохранена в базе данных 155 для формирования подлежащих оплате документов с обязательствами по платежам 1180, оплачиваемых покупателем или администратором проекта назначенному или получившему подряд продавцу. Например, информация 1160 о документе с обязательствами по платежам может включать в себя информацию 1160a о документе с обязательствами по платежам системы отслеживания времени, которая включает в себя хронометражную информацию 1150 (показанную на Фиг.45), вводимую подрядчиком, и информацию платежей по заявке, как определено введенными параметрами 870 отслеживания проектной работы (показанными на Фиг.39 и 40), имеющими отношение к хронометражной информации. Информация документа с обязательствами по платежам также может включать в себя информацию 1160b обязательств по платежам по затратам на проект, информацию 1160c обязательств по платежам по проектным сдачам/поставкам, информацию 1160d обязательств по платежам за материалы, информацию 1160e обязательств по платежам за расходы подрядчиком, информацию 1160f обязательств по платежам за выполнение единицы проектной работы и информацию 1160g о выпуске документа с обязательствами по платежам для рассчитываемой по времени оплате по проекту. Система может автоматически формировать подлежащие оплате обязательства по платежам 1180 на основании информации 1160 об обязательствах по платежам, предварительно введенной в другие контексты (например, введенные данные о параметрах отслеживания проекта, введенные данные об отслеживаемом времени, введенные данные о расходах подрядчика и/или введенные данные о затратах на проект), либо продавец, либо покупатель/администратор проекта могут формировать подлежащие оплате обязательства по платежам 1180 и вводить различные подходящие части информации 1160 обязательств по платежам (например, вводимые данные о завершении единицы работ или вводимые данные о завершении сдачи/поставки) в подлежащие оплате обязательства по платежам 1180.
На Фиг.49 проиллюстрированы примерные этапы, включенные в обработку обязательств по платежам и систему оплаты. Первоначально, различные параметры отслеживания проекта (например, информацию о заявке на закупку) вводятся в систему (этап 4400), и все обязанности продавца по товарам и услугам, подлежащие оплате и не подлежащие оплате, сохраняются в базе данных (этап 4410). Когда продавец поставляет зарегистрированные товары и услуги (как определено введенными обязанностями продавца) (этап 4420), продавец осуществляет доступ к системе, чтобы зарегистрировать выполнение товара или услуги и запросить оплату за товар или услугу (этап 4430). В других вариантах осуществления оплата может автоматически запрашиваться системой с определенными временными интервалами. Система формирует обязательство по платежам на основании параметров отслеживания проекта и другой информации обязательств по платежам (например, хронометражной информации, расходах, материалах, и т.д.) (этап 4440) и направляет документ об обязательствах по платежам соответствующему пользователю-покупателю или пользователю-администратору для его утверждения (этап 4450).
Если документ об обязательствах по платежам не утвержден (этап 4460), то продавца уведомляют и обеспечивают вариант выбора повторного представления документа об обязательствах по платежам (этап 4470). Если документ об обязательствах по платежам утвержден (этап 4460), то продавца уведомляют об утверждении (этап 4480). Если этот документ является подлежащим оплате документом об обязательствах по платежам (этап 4490), то он обрабатывается для электронного выставления счета на основании заранее заданного календарного графика (используя ограничения системы или покупателя) (этап 4495). Например, система может использовать пакетную обработку для сбора всех обязательств по платежам для покупателя (для одного или нескольких проектов), утвержденных в течение заранее определенного периода времени. Все счета могут быть генерироваться в формате, основанном на технических условиях покупателя, или в системном формате. Покупатель принимает счет(а) (этап 4498) и осуществляет платеж по счету(ов) продавцу(ам) заранее конфигурированным способом (например, EFI, по чеку, и т.д.) (этап 4499).
Примерные структуры базы данных для сохранения информации об обязательствах по платежам в подлежащих оплате документах с обязательствами по платежам и формирования записи об оплаченном документе с обязательствами по платежам показаны в Таблицах 84-92. Структуры данных для простоты иллюстрированы в табличном формате, в котором каждая таблица включает в себя все поля, необходимые для сохранения информации обязательств по платежам. Таблицы связаны иерархическим и реляционным образом с другими таблицами, сохраняемыми в базе данных, как описано в связи с Фиг.50.
В Таблице 84 проиллюстрирована примерная общая информация о соответствующем завершению проектной единицы документе с обязательствами по платежам, которая может быть сохранена в структуре 1170 таблицы базы данных в таблице "tblVoucherUnits" ("обязательство по платежам для проектных единиц") 1060, как показано на Фиг.50. Например, общая информация обязательств по платежам для завершения проектной единицы может включать в себя идентификатор обязательства по платежам на единицу, соответственный идентификатор заявки на закупку, указание того, были ли утверждены все хронометражные карты, связанные с завершением единицы, идентификатор продавца, дату недели завершения, соответствующую информации об обязательствах по платежам, дату создания, дату рассмотрения и указание того, была ли утверждена информация обязательств по платежам. Таблица "tblVoucherUnits" 1060 связана с таблицей "tblPurchaseReq" 1000, описанной выше в связи с Фиг.41, для связывания информации обязательств по платежам с заявкой на закупку. Кроме того, другие таблицы, показанные на Фиг.41, проиллюстрированы на Фиг.50, чтобы показать взаимосвязи между различными таблицами заявок на закупку и таблицами обязательств по платежам. Отдельная запись в формате таблицы 84 сохраняется в таблице "tblVoucherUnits" 1060 для каждого подлежащего оплате документа с обязательствами по платежам на единицу.
Таблица "tblContractorExpenseVoucher" 1054, показанная на Фиг.47, также рассматривается в качестве таблицы обязательств по платежам для формирования подлежащего оплате документа с обязательствами по платежам. Понятно, что могут быть включены другие таблицы и информация об обязательствах по платежам, и система не ограничена конкретными таблицами и информацией обязательств по платежам, показанными на Фиг.50.
tblVoucherUnits (представление структуры БД)
В Таблице 85 проиллюстрирован пример подробной информации обязательств по платежам, соответствующих завершению проектной единицы, которая может быть сохранена в базе данных в таблице "tblVoucherUnitsDetails" ("подробности обязательств по платежам на единицу") 1061, как показано на Фиг.50. Например, такая подробная проектная информация обязательств по платежам, соответствующая завершению проектной единицы, может включать в себя описание завершения единицы, количество зарегистрированных единиц, стоимость единицы, количество завершенных единиц и другую подробную информацию. Таблица "tblVoucherUnitsDetails" 1061 связана с таблицей "tblVoucherUnits" 1060 для связывания подробной информации обязательств по платежам для завершения единицы проекта с общей информацией обязательств по платежам для завершению единицы проекта. Кроме того, таблица "tblVoucherUnitsDetails" 1061 связана с таблицей "tblPurchaseReqPayUnits" 1009 по соответственной информации об оплате единицы заявки с информацией обязательств по платежам, соответствующих завершению единицы проекта.
Отдельная запись в формате таблицы 85 сохраняется в таблице "tblVoucherUnitsDetails" 1061 для каждого подлежащего оплате документа с обязательствами по платежам проектной единицы. Понятно, что могут быть включены другие таблицы и информация обязательств по платежам для завершения проектной единицы, и система не ограничена конкретными таблицами и информацией обязательств по платежам, соответствующей завершению проектной единицы, показанными на Фиг.50.
tblVoucherUnitsDetails (представление структуры БД)
В Таблице 86 проиллюстрирована примерная общая информация обязательств по платежам, соответствующих завершению времени выборки, которая может быть сохранена в базе данных в таблице "tblVoucherTimePayment" ("время оплаты для обязательств по платежам") 1062, как показано на Фиг.50. Например, общая информация информации по платежам, соответствующая завершению времени, может включать идентификатор "временного" денежного документа, соответственный идентификатор заявки на закупку, указание того, были ли утверждены все хронометражные карты, связанные с завершением времени, идентификатор продавца, дату недели завершения, связанную с информацией обязательств по платежам, дату создания, дату рассмотрения и указанием, была ли утверждена информация обязательств по платежам. Таблица "tblVoucherTimePayment" 1062 связана с таблицей "tblPurchaseReq" 1000, которая описана выше в связи с Фиг.41, для связывания информации обязательств по платежам с заявкой на закупку. Понятно, что отдельная запись, представленная в формате таблицы 86, сохраняется в таблице "tblVoucherTimePayment" 1062 для каждого документа с обязательствами по платежам, оплачиваемого с учетом времени.
tblVoucherTimePayment (представление структуры БД)
В Таблице 87 проиллюстрирован пример подробной информации обязательств по платежам, соответствующих завершению времени, которая может быть сохранена в базе данных в таблице "tblVoucherTimePaymentDetails" 1063, как показано на Фиг.50. Например, такая подробная информация обязательств по платежам, соответствующих завершению времени, может включать в себя дату начала работы, дату осуществления оплаты, сумму оплаты и другую подробную информацию обязательств по платежам, соответствующим завершению времени. Таблица "tblVoucherTimeCompletionDetails" ("подробности обязательств по платежам для времени оплаты") 1063 связана с таблицей "tblVoucherTimePayment" 1062 для связывания подробной информации обязательств по платежам, соответствующих завершению времени, с общей информацией обязательств по платежам, соответствующих завершению времени. Кроме того, таблица "tblVoucherTimePaymentDetails" 1063 связана с таблицей "tblPurchaseReqPayTimeSpan" 1008 по соответственной информации об оплате заявок с учетом времени с информацией обязательств по платежам, соответствующих завершению времени.
Понятно, что отдельная запись в формате таблицы 87 сохраняется в таблице "tblVoucherTimePaymentDetails" 1063 для каждого обязательства по платежам для оплачиваемой единицы. Понятно, что могут быть включены другие таблицы и информация обязательств по платежам, соответствующих завершению времени, и система не ограничена конкретными таблицами и информацией обязательств по платежам, соответствующих завершению времени, показанной на Фиг.50.
tblVoucherTimePaymentDetails (представление структуры БД)
В Таблице 88 проиллюстрирована примерная общая информация обязательств по платежам по затратам на проект, которая может быть сохранена в базе данных в таблице "tblVoucherProjectExpense" ("обязательство по платежам по затратам на проект") 1064, как показано на Фиг.50. Например, общая информация обязательств по платежам по затратам на проект может включать в себя идентификатор обязательств по платежам по затратам на проект, соответственный идентификатор заявки на закупку, указание того, были ли утвержден все хронометражные карты, связанные с затратами на проект (если таковые есть), идентификатор продавца, дату недели завершения, связанную с информацией обязательств по платежам, дату создания, дату рассмотрения и указание того, была ли утверждена информация обязательств по платежам. Таблица "tblVoucherProjectExpense" 1064 связана с таблицей "tblPurchaseReq" 1000, которая описана выше в связи с Фиг.41, для связывания информации обязательств по платежам с заявкой на закупку. Понятно, что отдельная запись в формате таблицы 88 сохраняется в таблице "tblVoucherProjectExpense" 1064 для каждого подлежащего оплате обязательства по платежам по затратам на проект.
tblVoucherProjectExpense (представление структуры БД)
В Таблице 89 проиллюстрирован пример подробной информации обязательств по платежам по затратам на проект, которая может быть сохранена в базе данных в таблице "tblVoucherProjectExpenseDetails" ("подробная информация обязательств по платежам по затратам на проект") 1065, как показано на Фиг.50. Такая подробная информация может включать в себя дату, когда расход был понесен, описание расходов по проекту, сумму расхода на проект и другую подробную информацию обязательств по платежам по затратам на проект. Таблица "tblVoucherProjectExpenseDetails" 1065 связана с таблицей "tblVoucherProjectExpense" 1064 для связывания подробной информации обязательств по платежам по затратам на проект с общей информацией обязательств по платежам по затратам на проект. Кроме того, таблица "tblVoucherProjectExpenseDetails" 1065 связана с таблицей "tblPurchaseReqPayProjectExpense" 1011 по соответственной информации об оплате связанных с заявками затрат на проект с информацией обязательств по платежам по затратам на проект.
Понятно, что отдельная запись, представленная в формате таблицы 89, сохраняется в таблице "tblVoucherProjectExpenseDetails" 1065 для каждого подлежащего оплате обязательства по платежам по затратам на проект. Могут быть включены другие таблицы, и информация обязательств по платежам по затратам на проект, и система не ограничена конкретными таблицами и информацией обязательств по платежам по затратам на проект, показанным на Фиг.50.
tblVoucherProjectExpenseDetails (представление структуры БД)
В Таблице 90 проиллюстрирована примерная общая информация обязательств по платежам по материалам, которая может быть сохранена в базе данных в таблице "tblVoucherMaterials" ("обязательства по платежам по материалам") 1066, как показано на Фиг.50. Например, общая информация обязательств по платежам по материалам может включать в себя идентификатор обязательств по платежам по материалам, соответственный идентификатор заявки на закупку, указание того, были ли утверждены все хронометражные карты, связанные с материалом (если таковые есть), идентификатор продавца, дату недели завершения, связанную с информацией обязательств по платежам, дату создания, дату рассмотрения и указание того, была ли утверждена информация обязательств по платежам. Таблица "tblVoucherMaterials" 1066 связана с таблицей "tblPurchaseReq" 1000, которая описана выше в связи с Фиг.41, для связывания информации обязательств по платежам с заявкой на закупку. Понятно, что отдельная запись, представленная в формате таблицы 90, сохраняется в таблице "tblVoucherMaterials" 1066 для каждого подлежащего оплате обязательства по платежам по материалам.
tblVoucherMaterials (представление структуры БД)
В Таблице 91 проиллюстрирован пример подробной информации обязательств по платежам по материалам, которая может быть сохранена в базе данных в таблице "tblVoucherMaterialsDetails" ("подробные обязательства по платежам по материалам") 1067, как показано на Фиг.50. Например, такая подробная информация обязательств по платежам по материалам может включать в себя дату, понесенные расходы за материал, наименование материала, описание материала, количество единиц купленного материала, стоимость единицы материала и другую подробную информацию обязательств по платежам соответственно расходам по проекту. Таблица "tblVoucherMaterialsDetails" 1067 связана с таблицей "tblVoucherMaterials" 1066 для связывания подробной информации обязательств по платежам по материалам с общей информацией обязательств по платежам по материалам. Кроме того, таблица "tblVoucherMaterialsDetails" 1067 связана с таблицей "tblPurchaseReqPayMaterials" 1010 по соответственной информации об оплате материалов по заявке с информацией обязательств по платежам по материалам.
Понятно, что отдельная запись, представленная в формате таблицы 91, сохраняется в таблице "tblVoucherMaterialsDetails" 1067 для каждого подлежащего оплате обязательства по платежам по материалам. Могут быть включены другие таблицы и информация обязательств по платежам по материалам, и система не ограничена конкретными таблицами и информацией, показанными на Фиг.50.
tblVoucherMaterialsDetails (представление структуры БД)
В Таблице 92 проиллюстрирована примерная общая информация обязательств по платежам для сдачи/поставки, которая может быть сохранена в базе данных в таблице "tblVoucherDeliverables" ("обязательства по платежам для сдачи/поставки") 1068, как показано на Фиг.50. Например, общая информация обязательств по платежам для сдачи/поставки может включать в себя идентификатор обязательств по платежам для сдачи/поставки, соответственный идентификатор заявки на закупку, указание того, были ли утверждены все хронометражные карты, связанные со сдачей/поставкой (если таковые есть), идентификатор продавца, дату недели завершения, связанную с информацией обязательств по платежам, дату создания, дату рассмотрения и указание того, была ли утверждена информация обязательств по платежам. Таблица "tblVoucherDeliverables" 1068 связана с таблицей "tblPurchaseReq" 1000, которая описана выше в связи с Фиг.41, для связывания информации обязательств по платежам с заявкой на закупку. Понятно, что отдельная запись, представленная в формате таблицы 92, сохраняется в таблице "tblVoucherDeliverables" 1068 для каждого подлежащего оплате обязательства по платежам для сдачи/поставки. Понятно, что может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 92.
tblVoucherDeliverables (представление структуры БД)
В Таблице 93 проиллюстрирован пример подробной информации обязательств по платежам для сдачи/поставки, которая может быть сохранена в базе данных в таблице "tblVoucherDeliverablesDetails" ("подробные обязательства по платежам для сдачи/поставки") 1069, как показано на Фиг.50. Например, такая подробная информация может включать описание сдачи/поставки, ожидаемую дату завершения сдачи/поставки, фактическую дату выполнения сдачи/поставки, требуемую сумму оплаты и другую подробную информацию. Таблица "tblVoucherDeliverablesDetails" 1069 связана с таблицей "tblVoucherDeliverables" 1068, чтобы связать подробную информацию обязательств по платежам для сдачи/поставки с общей информацией обязательств по платежам для сдачи/поставки. Кроме того, таблица "tblVoucherDeliverablesDetails" 1069 связана с таблицей "tblPurchaseReqPayDeliverables" 1007 по информации об оплате сдачи/поставки для заявки, соответственной информации обязательств по платежам для сдачи/поставки.
Понятно, что отдельная запись, представленная в формате таблицы 93, сохраняется в таблице "tblVoucherDeliverablesDetails" 1069 для каждого подлежащего оплате обязательства по платежам для сдачи/поставки. Могут быть включены другие таблицы и информация обязательств по платежам для сдачи/поставки, и система не ограничена конкретными таблицами и информацией, показанными на Фиг.50.
tblVoucherDeliverablesDetails(представление структуры БД)
В Таблице 94 ниже проиллюстрирован пример информации оплаченного обязательства по платежам, которая может быть сохранена в базе данных в виде таблицы "tblPaidVoucherRecords" ("записи об оплаченных обязательствах по платежам") 1070, как показано на Фиг.50. Например, такая информация может включать в себя номер счета, идентификаторы заявки на закупку, заданные покупателем и продавцом, дату утверждения обязательства по платежам, имя ответственного за утверждение, тип обязательства по платежам (например, хронометражная карта, расходы подрядчика, затраты на проект, сдачи/поставки, завершение времени или завершение единицы) и связанный идентификатор обязательства по платежам, сумму по счету, дату оплаты и другую информацию об оплаченном обязательстве по платежам.
Таблица "tblPaidVoucherRecords" 1070 связана с таблицей "tblPurchaseReq" 1000, описанной выше в связи с Фиг.41, для связывания информации об оплаченном обязательстве по платежам с заявкой на закупку. Понятно, что отдельная запись, представленная в формате таблицы 94, сохраняется в таблице "tblPaidVoucherRecords" 1070 для каждого оплачиваемого обязательства по платежам. Может быть включена другая информация, и система не ограничена конкретной информацией, показанной в Таблице 94.
Примерная tblPaidVoucherRecords (представление структуры БД)
На Фиг.51 проиллюстрировано экранное представление примерной web-страницы 61, отображающей финансовое состояние проекта. Эта web-страница может быть доступна в одном или нескольких форматах покупателю, продавцу и/или администратору, в зависимости от системных ограничений. Как следует из Фиг.51, могут быть отображены различные типы платежных документов и оцениваемых сумм для каждого из платежных документов. Может прослеживаться фактическая сумма, израсходованная по каждому из типов платежных документов, и оцениваемые дополнительные фонды, которые будут израсходованы для каждого из типов платежных документов. Таким образом, покупатель, продавец и/или администратор могут поддерживать рабочее знание относительно выполнения проекта с точки зрения финансовой перспективы. Понятно, что может быть отображена другая финансовая информация или дополнительная к конкретной финансовой информации, показанной на Фиг.51. Другая информация, относящаяся к проекту (вместо или в дополнение к финансовой информации), также может отображаться в зависимости от конфигурации для покупателя, продавца, администратора и/или системы, как описано более подробно ниже.
АНАЛИЗ И СОСТАВЛЕНИЕ ОТЧЕТОВ О ДАННЫХ ТРАНЗАКЦИЙ
В течение деятельности, предшествующей предложению, в процессе предложения и деятельности после предложения, описанных выше, различные данные транзакций, связанные с процессом предложения/проекта, принимают от покупателя, продавца и других сторон (например, администратора), включенных в процесс. Как показано на Фиг.58, данные 1195 транзакций могут включать в себя один или несколько компонентов: данные о предложении 212, параметры 870 отслеживания проекта, информацию 1160 обязательств по платежам и данные 1190 о выполнении проекта. Каждый из компонентов данных 1195 транзакций получают в течение отдельных стадий процесса предложения/проекта. Другие компоненты также могут быть включены в данные 1195 транзакций, такие как квалификационная информация продавца, информация об определенных покупателем критериях оценки продавца, информация о товарах и другие данные предварительного предложения и связанные с проектом. В итоге данные 1195 транзакций могут включать в себя любые данные, сохраняемые в системе 150 базы данных.
На Фиг.52 проиллюстрирована схема передачи сигналов, показывающая информационный обмен между покупателем 50, продавцом 10 и СУПП (в дальнейшем "система") 30. Как описано выше, первоначально покупатель 50 передает запрос предложения посредством системы 30 продавцу 10 (этап 4500). Запрос предложения содержит поля данных, содержащие введенные в них покупателем 50 данные запроса, и поля данных для продавца 10, чтобы вводить данные ответа на запрос предложения. Если продавец 10 ввел данные ответа на запрос о предложения в соответствующие поля данных, то ответ на предложение, включающий в состав данные ответа на запрос предложения, передают обратно покупателю 50 через систему 30 (этап 4510).
В совокупности данные запроса предложения и данные ответа на запрос предложения формируют данные 212 о предложении для завершенного предложения.
Данные 212 о предложении сохраняют в системной базе данных в записях, связанных с предложением, как описано выше.
Как только покупатель 50 назначил предложение конкретному продавцу 10, то оба и покупатель 50, и продавец 10 могут вводить параметры 870 отслеживания проекта (например, информацию о заявке на закупку, информацию о налогообложении, и т.д.) в систему 30 (этап 4520) для сохранения в базе данных, наряду с данными 212 предложения. Параметры 870 отслеживания проекта могут включать в себя некоторые или все постановления и условия договора), включая обязанности продавца за товары и услуги, и учитываемые для оплаты и не учитываемые для оплаты. Когда продавец 10 обеспечивает зарегистрированные товары или услуги (как определено введенными параметрами 870 отслеживания проекта), продавец 10 может осуществлять доступ к системе для представления на рассмотрение обязательства по платежам для запроса оплаты или для подтверждения покупателем завершения, если деятельность является не подлежащей оплате, за поставленные товары или выполненные услуги (этап 4530). После утверждения обязательства по платежам и последующего выставления счета покупатель осуществляет оплату продавцу посредством заранее конфигурированного способа (этап 4540). Информация, введенная покупателем 50 и продавцом 10, в процессе представления обязательства по платежам и оплаты сохраняется в базе данных в виде информации 1160 обязательств по платежам.
В течение выполнения проекта различные данные 1190 о выполнении проекта могут быть введены в систему 30 или сформированы автоматически и продавцом 10, и покупателем 50 (этап 4550), как описано более подробно ниже со ссылками на Фиг.53-57. Например, данные о выполнении проекта 1190 могут включать в себя различную информацию о состоянии, например информацию о согласовании во времени (например, указание своевременности для продавца по завершению одной или нескольких стадий или компонентов проекта) или информацию об издержках производства (например, фактическая стоимость одного или нескольких компонентов проекта по сравнению с проектными затратами (на заявки)). Данные 1190 о выполнении проекта также могут включать в себя конкретную для проекта информацию, такую как важность проекта или воздействие проекта на другие аспекты компании или другую определенную для заказчика информацию.
Данные 212 о предложении, параметры 870 отслеживания проекта, информацию 1160 обязательств по платежам и данные 1190 о выполнении проекта сохраняют в системной базе данных в качестве данных транзакций, связанных с предложением и проектом. С помощью доступа ко всем этим данным транзакций система 30 может исполнять фактически любой тип требуемого анализа и формировать отчеты на основании анализа. Таким образом, система 30 действует для приема запроса о различных типах аналитических данных от покупателя, продавца или другого пользователя на доступ к аналитическим данным (этап 4560). В соответствии с запросом система 30 исполняет анализ данных транзакций для формирования аналитических данных (этап 4570) и предоставляет аналитические данные запрашивающей стороне (например, покупателю 50, продавцу 10 или другому пользователю) (этап 4580) в области просмотра, или обзора отчета.
Например, покупатель 50 может запрашивать отчеты, содержащие аналитические данные, связанные с определенным проектом, многими проектами или многими продавцами 10. Аналитические данные могут быть направлены на финансовую информацию (например, подробности по счету, расходы (прошлые, настоящие и будущие) и другие виды финансового анализа), информацию о проекте (например, исполнение проекта, будущая деятельность по проекту и планирование проекта), информацию о продавце (например, финансовая информация о продавце, операционная информация о продавце и информация о последовательности поставок) и любой другой вид требуемой информации. Кроме того, покупатель 50 может запрашивать отчеты, содержащие аналитические данные по отрасли промышленности, или отраслевые, связанные со многими проектами, заказанными многими покупателями 50. Аналитические данные по отрасли промышленности могут быть направлены на финансовую информацию (например, процент от общей стоимости, потраченный на различные аспекты одного типа проекта или сумму процентов, потраченную как общеотраслевую на различные типы проектов), информацию о продавце (например, процент времени нахождения продавца в отрасли промышленности или процент затрат свыше/ниже сметы для продавца в отрасли промышленности) и любой другой тип информации об отрасли промышленности, как необходимо.
Подобные аналитические данные могут предоставляться продавцу 10 или другому зарегистрированному пользователю. Например, продавец 10 или администратор может запрашивать отчеты, содержащие аналитические данные, связанные с определенным проектом или со многими проектами, в проведение которых продавец 10 включен.
На Фиг.53 проиллюстрированы примерные функциональные возможности для ввода данных 1190 о выполнении проекта. Инструментальное средство выполнения 121 проекта и инструментальное средство 123 сравнения, проиллюстрированные на Фиг.53, предназначены для ввода данных о выполнении проекта в соответствии с вариантами осуществления настоящего изобретения. Инструментальное средство 121 выполнения проекта и инструментальное средство 123 сравнения могут включать в себя любые аппаратные средства, программное обеспечение и/или программно-аппаратные средства, требуемые для исполнения функций инструментальных средств, и могут быть осуществлены на сервере 120 или дополнительном сервере (не показан). Например, инструментальное средство 121 выполнения проекта и инструментальное средство 123 сравнения могут постоянно находиться в программных модулях 128 на сервере 120, как показано на Фиг.3B.
В одном варианте осуществления, данные 1190 о выполнении проекта могут быть введены непосредственно в базу 155 данных покупателем, продавцом или администратором посредством инструментального средства 180 выполнения проекта. Покупатель, продавец или администратор могут осуществлять доступ к серверу 120 из вычислительной системы 100 посредством браузера 20a покупателя, браузера 20b продавца или браузера 20c администратора, соответственно, и сети 40 передачи данных. Модуль 110 покупателя, модуль 115 продавца или модуль 135 администратора взаимодействует с инструментальным средством 121 выполнения проекта, чтобы поместить web-страницы в браузер 20a покупателя, браузер 20b продавца или браузер 20c администратора, соответственно, запрашивающими данные о выполнении проекта. Инструментальное средство 121 выполнения проекта осуществляет доступ к базе 155 данных, чтобы заполнить поля данных о выполнении проекта, связанные с конкретным проектом, в соответствии с данными о выполнении проекта, введенными покупателем, продавцом и/или администратором. Например, данные о выполнении проекта могут включать в себя комментарии покупателя, продавца и/или администратора относительно состояния или личного исполнения обязательства по проекту к настоящему моменту времени.
После принятия данных 1190 о выполнении проекта либо от покупателя, либо продавца, либо администратора инструментальное средство 121 выполнения проекта может дополнительно конфигурироваться для автоматического формирования сообщения (например, сообщения электронной почты), направляемого другим сторонам для сообщения им новых данных 1190 о выполнении проекта, таким образом давая возможность другим сторонам вводить дополнительные данные 1190 о выполнении проекта, поясняя, отвечая или предоставляя данные, не связанные с предварительно введенными данными 1190 о выполнении проекта.
В других вариантах осуществления, инструментальное средство 123 сравнения может автоматически вводить данные 1190 о выполнении проекта в базу 155 данных на основании сравнения параметров 870 отслеживания проекта и информации 1160 обязательств по платежам, связанной с конкретным проектом. Инструментальное средство сравнения извлекает необходимые параметры 870 отслеживания проекта и информацию 1160 обязательств по платежам из базы 155 данных, исполняет сравнение или анализ извлеченных параметров 870 отслеживания проекта и информации 1160 обязательств по платежам и на основании результатов сравнения или анализа вводит необходимые данные 1190 о выполнении проекта в поля данных, связанные с проектом, находящимся в базе данных 155.
В качестве примера инструментальное средство 123 сравнения может конфигурироваться для управления базой 155 данных для ввода новой информации 1160 обязательств по платежам или в противном случае может запускаться после ввода новой информации 1160 обязательств по платежам для ее сравнения с предварительно сохраненными параметрами 870 отслеживания проекта для данного проекта. Информация 1160 обязательств по платежам может содержать информацию об издержках производства, о временных параметрах или т.д., для сравнения с параметрами 870 отслеживания проекта. Результаты сравнения могут сохраняться в качестве данных 1190 о выполнении проекта в базе 155 данных. Например, информация 1160 обязательств по платежам может указывать сумму счета, оплаченную покупателем 50 по проекту, и инструментальное средство 123 сравнения может сравнивать сумму счета с суммой заявки, чтобы определить, существует ли несоответствие. В таком случае данные 1190 о выполнении проекта могут включать указание о текущем уровне издержек, например, ниже-сметы, выше-сметы или в-пределах-сметы, и суммы ниже-сметы или выше-сметы, если таковые есть.
В качестве другого примера инструментальное средство 123 сравнения может конфигурироваться для осуществления поиска в базе 155 данных для конкретных параметров 870 отслеживания проекта и ввести состояние параметров 870 отслеживания проекта в качестве данных 1190 о выполнении проекта. Например, инструментальное средство 123 сравнения может осуществить поиск в базе 155 данных по проектам с истекшими целевыми датами завершения и ввести количество дней, которые просрочены для каждого из проектов, в качестве данных 1190 о выполнении проекта, связанных с этими проектами. Инструментальное средство сравнения 123 может дополнительно осуществлять поиск информации 1160 обязательств по платежам, связанной с этими просроченными проектами, и вводить состояние проектов на основании информации 1160 обязательств по платежам. Например, если продавец представил документ с обязательствами по платежам на оплату, но покупатель оплату еще не осуществил, то состояние может указывать "представленный документ с обязательствами по платежам ожидает оплату".
Примерные процессы для ввода данных 1190 о выполнении проекта с различных системных точек зрения показаны на Фиг.54-56. На Фиг.54 проиллюстрированы примерные этапы, предназначенные, чтобы пользователь, такой как покупатель, продавец или администратор, вводил в систему данные о выполнении проекта. После принятия от пользователя данных о выполнении проекта, связанных с проектом (этап 4600), система сохраняет данные о выполнении проекта в полях данных, связанных с проектом, для последующего использования и поиска (этап 4610). Если стороны (покупатель, продавец и администратор), включенные в проект, установили условия для разрешения раскрытия некоторых или всех данных о выполнении проекта между сторонами, система формирует сообщение другим сторонам, сообщая им о принятых данных о выполнении проекта в соответствии с условиями, установленными сторонами (этап 4620). В ответ на сообщение другие стороны могут выбирать, вводить ли дополнительное данные о выполнении проекта как поясняющие, как ответ или предоставляя данные, не связанные с предварительно введенными данными о выполнении проекта. Если дополнительные данные о выполнении проекта приняты (этап 4630), система сохраняет дополнительные данные о выполнении проекта в полях данных, связанных с проектом, наряду с предварительно введенными данными о выполнении проекта, в базе данных (этап 4640).
На Фиг.55 проиллюстрированы примерные этапы для автоматического ввода в систему данных о выполнении проекта на основании предварительно сохраненных параметров отслеживания проекта и информации обязательств по платежам. После принятия системой параметров отслеживания проекта (этап 4700) и информации обязательств по платежам (этап 4710) для конкретного проекта система может сравнивать параметры отслеживания проекта с информацией обязательств по платежам (этап 4720), чтобы определить состояние проекта (этап 4730). Состояние проекта может быть введено в систему и сохранено в качестве данных о выполнении проекта, связанных с проектом (этап 4740). Например, информация обязательств по платежам может указывать для проекта фактическую дату завершения проекта, и система может сравнивать фактическую дату завершения проекта с целевой датой завершения проекта, чтобы определить, существует ли несоответствие. В таком случае данные о выполнении проекта могут включать указание состояния, например завершен вовремя, завершен после срока или завершен до срока, наряду с количеством дней просроченных или до срока.
На Фиг.56 проиллюстрированы примерные этапы для автоматического ввода в систему данных о выполнении проекта на основании состояния предварительно сохраненных параметров отслеживания проекта. После того, как система принимает параметры отслеживания проекта для конкретного проекта (этап 4750), например целевой даты завершения, система может осуществлять поиск в базе данных по проектам с истекшими целевыми датами завершения (этап 4760). Если истекшие даты завершения найдены (этап 4770), то система может определить состояние проекта (этап 4780) на основании любой информации о документе с обязательствами по платежам, которая была принята, и ввести в систему состояние проекта в качестве данных о выполнении проекта (этап 4790).
Примерные структуры базы данных для сохранения данных 1190 о выполнении проекта показаны в Таблицах 95-112. Структуры данных для простоты проиллюстрированы представляемыми в табличном формате, в котором каждая таблица включает в себя все поля, необходимые для сохранения данных 1190 о выполнении проекта. Таблицы связаны иерархическим и реляционным образом с другими таблицами, сохраняемыми в базе данных, как будет обсуждено в связи с Фиг.57.
В Таблицах 95 и 96 проиллюстрирован пример данных о выполнении проектной сдачи/поставки, которые могут быть сохранены представленными структурой 1185 таблицы базы данных в таблице "tblDeliverableTrackPerformance" ("отслеживание выполнения сдачи/поставки") 1080 и таблице "lkpDeliverableStatus" ("состояние сдачи/поставки") 1081, как показано на Фиг.57. Данные о выполнении проектной сдачи/поставки могут включать в себя состояние сдачи/поставки в виде определенных из таблицы "lkpDeliverableStatus" 1081. Например, состояниями сдачи/поставки могут быть "незавершенная - текущая", "незавершенная - после срока", "частично завершенная - текущая", "частично завершенная - после срока", "завершенная - в срок", "завершенная - после срока" или "завершенная - до срока". Идентификатор, связанный с состоянием, может быть сохранен в таблице "tblDeliverableTrackPerformance" вместе с идентификатором, связанным с параметрами отслеживания проекта для сдачи/поставки, сохраняемыми в таблице "tblPurchaseReqPayDeliverables" 1007, текущим состоянием (например, количеством дней после срока или до срока), и любыми примечаниями пользователя.
Например, если покупатель, продавец или другой пользователь ввел любые комментарии, связанные с состоянием сдач/поставок, эти комментарии могут быть сохранены в таблице "tblDeliverableTrackPerformance" 1080. Идентификатор пользователя, который ввел комментарии, наряду с датой введенных комментариев, также может быть сохранен в дополнение к комментариям. Если система конфигурирована для сообщения продавцу, когда покупатель вводит комментарии, состояние ответа продавца (например, еще не отвечал, нет ответа, ответ) также может быть сохранено.
Таблицы "tblDeliverableTrackPerformance" 1080 и "lkpDeliverableStatus" 1081 показаны связанными с таблицей "tblPurchaseReqPayDeliverable" 1007, которая, в свою очередь, связана с таблицей "tblPurchaseReq" 1000, описанными выше в связи с Фиг.41, для связывания данных о выполнении проекта с информацией обязательств по платежам и параметрами отслеживания проекта (например, заявкой на закупку). Кроме того, различные другие таблицы, показанные на Фиг.41, проиллюстрированы при этом на Фиг.57, чтобы показать взаимосвязи между различными таблицами выполнения проекта, таблицами документов с обязательствами по платежам и таблицами заявок на закупку. Отдельная запись, представленная в формате таблицы 95, сохраняется в таблице "tblDeliverableTrackPerformance" 1080 для каждой сдачи/поставки. Понятно, что могут быть включены другие таблицы и данные о выполнении проекта, и система не ограничена конкретными таблицами и данными о выполнении проекта, показанными на Фиг.57.
Примерная tblDeliverableTrackPerformance
Примерная lkpDeliverableStatus
В Таблицах 97 и 98 проиллюстрированы примерные данные о выполнении фазы проекта, которые могут быть сохранены в структуре 1185 таблицы базы данных в таблице "tblPhaseTrackPerformance" ("отслеживание выполнения фаз") 1082 и таблице "lkpPhaseStatus" ("состояния фаз") 1083, как показано на Фиг.57. Данные о выполнении фазы проекта могут включать в себя состояние фазы, как определено на основе таблицы "lkpPhaseStatus" 1082. Например, состоянием фазы может быть "открыта - текущая", "открыта - устаревшая", "открыта - будущая", "закрыта - вовремя", "закрыта - устаревшая" или "закрыта - преждевременная". Идентификатор, связанный с состоянием, может быть сохранен в таблице "tblPhaseTrackPerformance", наряду с идентификатором, связанным с параметрами отслеживания фаз проекта, сохраненными в таблице "tblPurchaseReqPhasing" 1018, которая может быть таблицей, сходной с таблицами, показанными на Фиг.41, текущим состоянием (например, количеством дней опоздания или опережения) и любыми примечаниями пользователя.
Например, если покупатель, продавец или другой пользователь ввели какие-либо комментарии, связанные с определением состояния фаз, то эти комментарии могут быть сохранены в таблице "tblPhaseTrackPerformance" 1083. Идентификатор пользователя, который ввел комментарии, наряду с датой введенных комментариев, также может быть сохранен в дополнение к комментариям. Если система конфигурирована для сообщения продавцу в случае, когда покупатель вводит комментарии, то состояние ответа продавца (например, еще не отвечал, нет ответа, ответ) также может быть сохранено.
Примерная tblPhaseTrackPerformance
Примерная lkpPhaseStatus
В Таблицах 99 и 100 ниже проиллюстрированы примерные данные о выполнении проектной единицы, которые могут быть сохранены в структуре 1185 таблицы базы данных в таблице "tblUnitsTrackPerformance" ("отслеживание проектной единицы") 1084 и таблице "lkpUnitStatus" ("состояния проектной единицы") 1085, как показано на Фиг.57. Данные о выполнении проектной единицы могут включать в себя состояния единиц, как определено по таблице "lkpUnitStatus" 1085. Например, состоянием единицы может быть "Не завершена - текущая", "Не завершена - после срока", "Завершена - вовремя", "Завершена - после срока" или "Завершена - до срока". Идентификатор, связанный с состоянием, может быть сохранен в таблице "tblUnitTrackPerformance", наряду с идентификатором, связанным с параметрами отслеживания модуля проекта, сохраняемыми в таблице "tblPurchaseReqPayUnits" 1009, текущим состоянием (например, количеством дней после срока или раньше срока) и любыми примечаниями пользователя.
Например, если покупатель, продавец или другой пользователь ввели любые комментарии, связанные с состоянием единиц, эти комментарии могут быть сохранены в таблице "tblUnitsTrackPerformance" 1084. Идентификатор пользователя, который ввел комментарии, наряду с введенной датой комментариев, также может быть сохранен в дополнение к комментариям. Если система конфигурирована для сообщения продавцу в случае, когда покупатель вводит комментарии, состояние ответа продавца (например, еще не отвечал, нет ответа, ответ) также может быть сохранено.
Примерный tblUnitsTrackPerformance
Примерная lkpUnitsStatus
В Таблицах 101 и 102 проиллюстрированы примерные данные об исполнении затрат по проекту (эффективности затрат), которые могут быть сохранены в структуре 1185 таблицы базы данных в таблице "tblCostTrackPerformance" ("отслеживание исполнения затрат") 1086 и в таблице "lkpCostStatus" ("состояние затрат") 1087, как показано на Фиг.57. Данные об исполнении затрат по проекту могут быть связаны с любым оплаченным обязательством по платежам для любого типа обязательства по платежам, включая обязательства по платежам на материалы, расходы, сдачи/поставки, соответственно фазам проекта, на единицы и на оплату по времени. Данные об исполнении затрат по проекту представлены состоянием стоимости, как определено по таблице "IkpCostStatus" 1087. Например, состояние стоимости может быть "сверх сметы", "ниже сметы" или "в пределах сметы". Идентификатор, связанный с состоянием, может быть сохранен в таблице "tblCostTrackPerformance", наряду с идентификатором, связанным с информацией обязательств по платежам, сохраняемой в таблице "tblPaidVoucherRecords" 1070, текущим состоянием (например, сумма выше сметы или ниже сметы) и любыми примечаниями пользователя.
Например, если покупатель, продавец или другой пользователь ввели какие-либо комментарии, связанные с состоянием затрат, эти комментарии могут быть сохранены в таблице "tblCostTrackPerformance" 1086. Идентификатор пользователя, который ввел комментарии, наряду с датой введенных комментариев, также могут быть сохранены в дополнение к комментариям. Если система конфигурирована для информирования продавца, когда покупатель вводит комментарии, состояние ответа продавца (например, еще не отвечал, нет ответа, ответ) также может быть сохранено.
Примерная tblCostTrackPerformance
Примерная lkpCostStatus
На Фиг.57 показаны другие таблицы, которые содержат дополнительные данные, связанные с проектом и/или продавцом или покупателем, которые будут полезными, чтобы дополнительно идентифицировать тип проекта и другие проектные переменные 10, которые не были явным образом обсуждены предварительно. Дополнительные данные также могут быть включены в данные транзакций, используемые с целями анализа и составления отчетов. Например, в Таблице 103 проиллюстрировано воздействие проекта на другие аспекты покупателя, которое может быть сохранено представленным в структуре 1185 таблицы базы данных, в таблице "lkpProjectImpactCode" ("код воздействия на проект") 1072, Таблица 104 ниже иллюстрирует значимость сдачи/поставки, которая может быть сохранена в структуре 1185 таблицы базы данных в таблице "lkpDeliverableImportance" ("значимость сдачи/поставки"), и Таблица 105 ниже иллюстрирует состояние права собственности проекта, которое может быть сохранено в структуре 1185 таблицы базы данных в таблице "lkpPMOwndershipStatus" ("состояние права собственности") 1073, как показано на Фиг.57.
Другая информация, связанная с продавцом и покупателем, может быть сохранена в дополнительных таблицах. Например, в Таблице 106 ниже проиллюстрированы основные данные продавца, которые могут быть сохранены в структуре 1185 таблицы базы данных в таблице "lkpVendorMaster" ("продавец основной") 1090, и Таблица 107 ниже иллюстрирует основные данные покупателя, которые могут быть сохранены в структуре 1185 таблицы базы данных в таблице "lkpBuyerMaster" ("покупатель основной") 1095, как показано на Фиг.57. Кроме того, Таблицы 108 и 109 ниже иллюстрируют информацию об уровне продавца, указывая группу уровня, которую покупатель назначил продавцу (например, продавцы уровня 1 являются обычно продавцами, которых используют первыми или наиболее часто), которая может быть сохранена в структуре 1185 таблицы базы данных в таблицах "lkpVendorTier" ("уровень продавца") 1091 и "tblVendorTierMap" ("соответствие продавец-уровень") 1092, как показано на Фиг.57. Кроме того, в Таблицах 110-112 ниже проиллюстрирована сегментация отраслей промышленности покупателя, информация о расходах и объемах, которая может быть сохранена в структуре 1185 таблицы базы данных в таблицах "lkpIndustrySegmentation" ("сегментация отраслей промышленности") 1096 "lkpBuyerSpendProfile" (профиль расходов покупателя) 1097 и "lkpBuyerSizeProfile" (профиль объемов покупателя) 1098, как показано на Фиг.57. Сегментация отрасли промышленности может быть проектно-определенной или применимой к покупателю в целом.
Примерная lkpProjectlmpactCode
Примерная lkpDeliverableImportance
Примерная lkpPMOwnershipStatus
Примерная lkpVendorMaster
Примерный lkpBuyerMaster
Примерная lkpVendorTier
Примерная tblVendorTierMap
lkpIndustrySegmentation
lkpBuyerSpendProfile
lkpBuyerSizeProfile
Как описано выше в связи с Фиг.52, данные о выполнении проекта формируют часть данных транзакций, которые сохраняются в базе данных. Согласно Фиг.58, данные 1195 транзакций могут включать в себя не только данные 212 о предложении, но также и параметры 870 отслеживания проекта, информацию 1160 обязательств по платежам и данные 1190 о выполнении проекта. Все данные 1195 транзакций сохраняют в системе 150 баз данных нижнего уровня, которая содержит базы данных (155, не показаны) для покупателей, продавцов и администраторов. В некоторых вариантах осуществления данные 1195 транзакций поддерживают только в базе 150 данных нижнего уровня, и следовательно, аналитические данные являются ограниченными только теми данными 1195 транзакций, которые находятся в этой базе данных нижнего уровня.
Например, покупатель/администратор или продавец могут не разрешать, чтобы к их данным транзакций осуществляли доступ какие-либо внешние (третьей стороны) источники. В этой ситуации для формирования аналитических данных, включающих данные транзакций покупателя/администратора или продавца, покупатель/администратор или продавец являются ограниченными только своими данными транзакций.
В других вариантах осуществления, как показано на Фиг.59, все или часть данных 1195 транзакций могут быть переданы на верхний уровень базы данных 160 (в дальнейшем "центральная база данных 160") для последующего использования или поиска с аналитическими целями. Данные транзакций могут быть переданы из базы 155 данных нижнего уровня на центральную базу 160 данных в любое время или по любой причине. В качестве примера, данные транзакций 1195а, 1195b и 1195c (все вместе, 1195), сохраняемые во многих базах данных 155a, 155b и 115c покупателя, соответственно, могут быть переданы на центральную базу 160 данных для сохранения в ней. Передача может происходить в исполняемом в пакетном режиме процессе, в котором данные 1195 транзакций, имеющие даты создания записей, находящиеся в пределах конкретного промежутка времени, передают пакетом на центральную базу 160 данных. Например, каждую неделю, все данные транзакций 1195, имеющие даты создания записей в течение этой недели, могут быть переданы в виде пакета на центральную базу 160 данных.
Переданные данные 1195 транзакций могут включать в себя все данные 1195 транзакций, находящиеся в базе 160 данных нижнего уровня, или только часть, как задано системой или покупателем/администратором и/или продавцом. Например, различные части данных 1195 транзакций могут не быть необходимыми для общеотраслевых аналитических целей, и следовательно, данные 1195 транзакций, передаваемые в центральную базу 160 данных, могут исключать те части, которые являются ненужными. В качестве другого примера покупатель/администратор и/или продавец могут пожелать ограничить тип данных 1195 транзакций, который делают доступным центральной базе данных 160, по причинам секретности или другим причинам.
На Фиг.60 проиллюстрированы примерные функциональные возможности для формирования аналитических данных 270. Модуль 126 или 127 составления отчетов, предназначенный для формирования аналитических данных 270, показан на Фиг.60 в соответствии с вариантами осуществления настоящего изобретения. Модуль 126 или 127 составления отчетов может включать в себя любые аппаратные средства, программное обеспечение и/или программно-аппаратные средства, требуемые для исполнения функций модуля, и может быть осуществлен на сервере 120 или 125, соответственно, или на дополнительном сервере (не показан). Например, модуль 126 составления отчетов может постоянно находиться в программных модулях 128 на сервере 120, как показано на Фиг.3B.
Аналитические данные 270 могут быть сформированы с использованием данных 1195 транзакций, находящихся в базе данных нижнего уровня (конкретно не показаны), входящей систему 150 баз данных нижнего уровня, или из центральной базы 160 данных, в зависимости от типа требуемых аналитических данных 270. Например, если пользователь-покупатель требует аналитических данных, относящихся только к тем проектам, которые связаны с покупателем, то пользователь-покупатель будет осуществлять доступ к данным транзакций 1195 внутри относящейся к нижнему уровню базы данных покупателя в системе 150 базы данных нижнего уровня. Однако, если пользователь-покупатель требует общеотраслевых аналитических данных, относящихся к проектам, связанным со многими покупателями, то пользователь-покупатель будет осуществлять доступ к данным транзакций 1195 в центральной базе 160 данных.
Чтобы принимать аналитические данные 270, использующие данные 1195 транзакций, или из системы 150 баз данных нижнего уровня, или из центральной базы 160 данных, пользователь-покупатель, пользователь-продавец, или административный пользователь осуществляют доступ к соответствующему серверу 120 или 125, соединяемому с базой 150 или 160 данных посредством браузера 20a покупателя, браузера 20b продавца или браузера 20c администратора, соответственно, и сети 40 передачи данных. Модули 110 или 140 покупателя, модули 115 или 145 продавца или административные модули 135 или 149 взаимодействуют с модулями 126 или 127 составления отчетов, чтобы поместить web-страницы в браузер 20a покупателя, браузер 20b продавца или административный браузер 20c, соответственно, чтобы оказывать помощь пользователю-покупателю, пользователю-продавцу или административному пользователю в формировании запроса 285 аналитических данных 270 конкретного типа. Например, требуемые аналитические данные 270 могут быть связаны с различными факторами цены и выполнения, как функциями (результатами) данных 1195 транзакций. Аналитические данные 270 могут быть связаны с отдельным проектом, многими проектами, многими продавцами или многими покупателями, последнее является возможным только с помощью данных транзакций 1195 центральной базы данных. Различные перестановки и возможности для различных типов аналитических данных 270, которые могут быть сформированы, являются ограниченными только типом и объемом хранимых данных 1195 транзакций. Кроме того, должно быть понятно, что, хотя не показано, в других вариантах осуществления пользователю-подрядчику можно позволить осуществлять доступ к различным аналитическим данным 270, которые подрядчик имеет полномочия просматривать, таким, как количество рабочих часов, отработанных подрядчиком по проекту до настоящего времени, количество рабочих часов, отработанных по всем проектам в течение некоторого промежутка времени, ставка оплаты для различных проектов, средняя ставка, и т.д.
В некоторых вариантах осуществления представленный на рассмотрение пользователем запрос 285 может содержать один или несколько фильтров 280, чтобы сосредоточить аналитические данные 270 на конкретных данных 1195 транзакций. Например, пользователю может потребоваться принимать аналитические данные 270, связанные только с проектами, завершенными в определенной географической зоне, или связанные с определенным типом проекта или с сегментацией (подотраслью) отрасли промышленности. Модули 126 или 127 составления отчетов используют фильтры 280 для доступа к базам данных 150 или 160, чтобы извлечь фильтрованные данные транзакций 1198, которые содержит только те данные транзакций, которые удовлетворяют требованиям фильтров 280. На основании фильтрованных данных транзакций 1198 модуль 126 или 127 составления отчетов генерирует аналитические данные 270.
Используя данные 1195 транзакций или фильтрованные данные транзакций 1198, модуль составления отчетов 126 или 127 генерирует аналитические данные 270 на основании запроса 285. Например, если запрос 285 осуществляется для финансового отчета, указывающего планируемые расходы на последующие месяцы по текущим проектам, модуль 126 или 127 составления отчетов может осуществлять доступ к данным транзакций 1195, чтобы извлечь различные параметры отслеживания проекта, связанные с объемами будущих заявок по текущим проектам, и подвести итог по объемам заявок по месяцам для формирования аналитических данных 270. В качестве другого примера, если запрос 285 предназначен для статистического отчета относительно процента расходов на (приобретение) различных компонентов проектов (например, материалов, расходов, сдач/поставок, рабочей силы, и т.д.), осуществляемых продавцами уровня 1, то модуль 126 или 127 составления отчетов может осуществлять доступ к данным транзакций 1195, чтобы извлечь различные данные о предложении (чтобы определить проекты, связанные с продавцами уровня 1), параметры отслеживания проекта, информацию обязательств по платежам) и данные о выполнении проекта, и использовать различные математические и статистические функции для формирования аналитических данных 270. Модуль составления отчетов 126 или 127 "проталкивает" на браузер покупателя 20a, браузер продавца 20b или на административный браузер 20c web-страницы, включающие в состав обзоры отчетов, содержащие аналитические данные.
Примерные процессы формирования различных типов аналитических данных 270, используя различные типы данных транзакций, показаны на Фиг.61-67. Однако понятно, что показанные процессы являются лишь примерами многочисленных процессов, которые могут выполняться с использованием системы согласно настоящему изобретению. На Фиг.61 показана примерная блок-схема, описывающая процесс формирования аналитических данных, запрошенных пользователем системы. В данном процессе принимают (этап 4800) запрос аналитических данных как функцию данных транзакций, включающих по меньшей мере данные о предложении, которые были собраны в течение оперативного процесса предложения. Запрос может быть представлен в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы данных о предложении, как представлено в предложениях. Кроме того, запрос может включать в себя один или несколько фильтров, чтобы уменьшить объем данных о предложении в пределах выбранных типов данных о предложении, используемый в формировании аналитических данных.
Как только необходимые данные транзакций идентифицированы и извлечены, аналитические данные формируют на основании данных транзакций (этап 4810). В формировании аналитических данных могут быть использованы различные математические и статистические функции, чтобы сформировать широкое разнообразие информации, запрашиваемой пользователем. Аналитические данные могут быть сформированы на основании данных о предложении, относящихся к одиночному проекту, многим проектам, многим продавцам или многим покупателям, и они могут быть представлены пользователю в разнообразных визуальных представлениях или обзорах отчетов. Например, примерные обзоры отчетов включают в себя итоговые обзоры, обзоры по совокупным данным, обзоры оценок, статистические обзоры, обзоры выполнения проекта или любую комбинацию из них. Аналитические данные могут использоваться пользователем с различными целями, включая оценку индивидуальных предложений, оценку характеристик продавца, оценку расхода или дохода, оценку инфляции в отрасли промышленности, формирование информации о тенденции в отрасли промышленности и т.д.
На Фиг.62 показана примерная блок-схема, описывающая процесс формирования аналитических данных, включая совокупные данные о выполнении проекта по текущим, прошлым и/или будущим проектам в системе. Данные о выполнении проекта система сохраняет (этап 4820), как описано выше в связи с Фиг.53-56. В данном процессе запрос совокупных данных о выполнении проекта принимают от зарегистрированного пользователя системы (этап 4830). Запрос может быть представлен в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы данных о выполнении проекта, накопленных системой. Кроме того, запрос может включать один или несколько фильтров, чтобы уменьшить объем данных о выполнении проекта в пределах выбранных типов данных о выполнении проекта, используемых в формировании аналитических данных. Понятно, что запрос состоит в том, чтобы накопить данные о выполнении проекта по многим проектам, выполняемым одним или несколькими продавцами для одного или нескольких покупателей, чтобы составить совокупные данные о выполнении проекта.
Как только необходимые данные о выполнении проекта идентифицированы и извлечены, формируют совокупные данные о выполнении проекта (этап 4840). В формировании совокупных данных о выполнении проекта могут использоваться различные операции арифметического и/или статистического анализа. Например, система может вычислять различную информацию, относящуюся к проектам, такую как процентное отношение проектов, выполняемых в срок или ниже сметы, и т.д. Совокупные данные о выполнении проекта могут быть представлены пользователю в различных обзорах отчетов. Например, примерные обзоры отчетов включают в себя итоговые обзоры, обзоры оценок или статистические обзоры. Совокупные данные о выполнении проекта могут использоваться пользователем с различными целями, включая оценку индивидуального исполнения продавца относительно других продавцов, оценку прошлого, настоящего или будущего расхода или дохода, оценку инфляции в пределах отрасли промышленности, формирования информации о тенденции в отрасли промышленности и т.д.
На Фиг.63 показана примерная схема последовательности, описывающая процесс формирования аналитических данных, включающих совокупные статистические данные о выполнении проекта, связанные с индивидуальными проектами. Данные о выполнении проекта система сохраняет (этап 4850), как описано выше в связи с Фиг.53-56. В данном процессе запрос совокупных статистических данных о выполнении проекта принимают от зарегистрированного пользователя системы (этап 4860). Запрос может быть представлен в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы данных о выполнении проекта, накопленные системой. Кроме того, запрос может включать в себя один или несколько фильтров, чтобы уменьшить объем данных о выполнении проекта в пределах выбранных типов данных о выполнении проекта, используемых в формировании аналитических данных. Понятно, что запрос состоит в том, чтобы накопить данные о выполнении проекта по многим проектам, выполняемым одним или несколькими продавцами для одного или нескольких покупателей, чтобы вычислить статистические данные, связанные с индивидуальными проектами и составить совокупные статистические данные.
Как только необходимые данные о выполнении проекта идентифицированы и извлечены, статистические данные о выполнении проекта вычисляют для индивидуальных проектов (этап 4870), используя различные операции арифметического и/или статистического анализа. Статистический анализ может вычислять различную информацию о проекте, такую как средняя стоимость по месяцам, средний расход, процент от общей стоимости для различных компонентов или аспектов проекта и т.д. После этого индивидуальные статистические данные объединяют для формирования совокупных статистических данных о выполнении проекта (этап 4880). Совокупные статистические данные о выполнении проекта могут быть представлены пользователю в разнообразных обзорах отчетов. Например, примерные обзоры отчетов включают итоговые обзоры, обзоры оценок, и т.д. Составлением совокупных статистических данных по многим проектам, выполняемым продавцами, покупатель может получить полный обзор выполняемых проектов, чтобы способствовать оценке проектов в целом.
На Фиг.64 показана примерная блок-схема, описывающая формирование аналитических данных на основании данных транзакций, при котором данные транзакций включают в себя по меньшей мере данные о предложении, параметры отслеживания проекта и данные о выполнении проекта. Данные транзакций система сохраняет (этап 4900), как описано выше в связи с Фиг.52. В этом процессе запрос аналитических данных принимают от зарегистрированного пользователя системы (этап 4910). Запрос может быть представлен в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы данных транзакций, накопленные системой. Кроме того, запрос может включать один или несколько фильтров, чтобы уменьшить объем данных транзакций в пределах выбранных типов данных транзакций, используемых в формировании аналитических данных.
Как только необходимые данные транзакций идентифицированы и извлечены, аналитические данные формируют на основании одного или нескольких компонентов данных транзакций (например, данных о предложении, параметров отслеживания проекта и/или данных о выполнении проекта) (этап 4920). В формировании аналитических данных могут использоваться различные математические и статистические функции для формирования широкого разнообразия информации, запрошенной пользователем. Аналитические данные могут быть сформированы на основании данных транзакций, относящихся к отдельному проекту, многим проектам, многим продавцам или многими покупателям, и они могут быть представлены пользователю в различных обзорах отчетов. Например, примерные обзоры отчеты включают в себя итоговые обзоры, обзоры по совокупным данным, обзоры оценок, статистические обзоры, обзоры о выполнении проекта или любую комбинацию из них. Аналитические данные могут быть отображены графически, чтобы оказывать помощь пользователю в осуществлении анализа проектов или тенденций в отрасли промышленности.
На Фиг.65 показана примерная блок-схема, описывающая более подробно процесс накопления данных транзакций и формирования аналитических данных на основании данных транзакций. Первоначально покупатель формирует предложение, в котором предложение включает поля данных для приема от покупателя и продавца данных о предложении (этап 4950). Например, поля данных могут давать возможность покупателю и продавцу ввести данные о предложении, связанные с условиями цены, количества и временем поставки. Понятно, что поля данных, включенные в предложение, связаны с выбранными элементами предложения, как описано выше в разделе "Деятельность по предложению". В случае, когда данные о предложении приняты системой от покупателя и продавца (этап 4955), данные о предложении сохраняют в системе в качестве данных транзакций (этап 4960).
После решения о назначении проекта принимают параметры отслеживания проекта для проекта, относящиеся к предложению (этап 4965), и сохраняют в качестве дополнительных данных транзакций (этап 4970). В течение выполнения проекта принимают различные данные о выполнении проекта, относящиеся к проекту, (этап 4975) и сохраняют в качестве дополнительных данных транзакций (этап 4980). Как только данные транзакций были приняты и сохранены, принимают последующий запрос аналитических данных как функции данных транзакций (этап 4985). Запрос может быть представлен пользователем в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы накопленных системой данных транзакций. Кроме того, запрос может включать в себя один или несколько фильтров, чтобы уменьшить объем данных транзакций в пределах выбранных типов данных транзакций, используемых в формировании аналитических данных.
Как только необходимые данные транзакций идентифицированы и извлечены, аналитические данные формируют на основании одного или нескольких компонентов данных транзакций (например, данные о предложении, параметрах отслеживания проекта, и/или данные о выполнении проекта) (этап 4990). В формировании аналитических данных могут использоваться различные математические и статистические функции для формирования широкого разнообразия информации, запрашиваемой пользователем. Аналитические данные могут быть сформированы на основании данных транзакций, относящихся к отдельному проекту, многим проектам, многим продавцам или многим покупателям, и они могут быть представлены пользователю в различных обзорах отчетов. Например, примерные обзоры отчеты включают в себя итоговые обзоры, обзоры по совокупным данным, обзоры оценок, статистические обзоры, обзоры о выполнении проекта или любую комбинацию из них. Аналитические данные могут быть отображены графически, чтобы оказывать помощь пользователю в осуществлении анализа проектов или тенденций отрасли промышленности.
На Фиг.66 показана примерная блок-схема, описывающая процесс формирования отраслевых аналитических данных как функции данных транзакций, формируемых в соответствии с проектами одного или нескольких покупателей. Поскольку система имеет возможность управления проектами для многих покупателей, отраслевые аналитические данные могут быть оценены на основании проектов, выполняемых по отрасли, взятой в целом. Как само собой разумеющееся в использовании системы, различные проекты использующие систему покупателей, могут быть отслежены посредством информации о транзакциях. Анализируя данные транзакций, осуществляемых многими покупателями, могут быть выявлены тенденции отрасли промышленности. Например, в отрасли промышленности сетей связи, в которой могут иметься многие проекты, связанные с установкой центральных коммутаторов, используя принципы настоящего изобретения, могут быть сформированы средняя стоимость, время разработки, время установки и интенсивности отказов центральных коммутаторов.
Первоначально процесс анализа отрасли промышленности начинается, когда система (например, административный сервер 125 по Фиг.2A) принимает запрос отраслевых аналитических данных (этап 5000). Запрос может быть от продавцов, покупателей или администратора системы. На основании запроса осуществляют доступ к данным транзакций, связанным между собой многими проектами многих покупателей, находящимся в центральной базе данных (этап 5010). Запрос может быть представлен пользователем в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы данных транзакций, накопленных системой. Кроме того, запрос может включать в себя один или несколько фильтров, чтобы уменьшить объем данных транзакций в пределах выбранных типов данных транзакций, используемых в формировании аналитических данных.
Как только необходимые данные транзакций идентифицированы и извлечены, отраслевые аналитические данные могут быть сформированы как функции данных транзакций (этап 5020). В формировании отраслевых аналитических данных могут использоваться математические и/или статистические функции для формирования разнообразных отраслевых аналитических данных, которые представляют интерес для пользователя при обзоре. Отраслевые аналитические данные могут быть представлены в различных обзорах отчетов. Например, примерные обзоры отчетов включают в себя итоговые обзоры, обзоры по совокупным данным, обзоры оценок, статистические обзоры, обзоры о выполнении проекта или любую комбинацию из них.
На Фиг.67 показана примерная блок-схема, описывающая более подробно процесс, предназначенный для накопления данных транзакций от многих покупателей посредством процесса пакетного режима и формирования отраслевых аналитических данные на основании данных транзакций. Данные транзакций для индивидуальных проектов сохраняют в базах данных нижнего уровня ассоциированными с покупателями, продавцами и администраторами, связанными с проектами (этап 5050). Чтобы обрабатывать запросы отраслевых аналитических данных, необходимые и зарегистрированные (авторизованные) данные транзакций извлекают как процесс пакетного режима из каждой из баз данных нижнего уровня в центральную базу данных, как описано выше, и как понятно в данной области техники (этап 5060). Как только данные пакета транзакций приняты и сохранены, принимают (этап 5070) последующий запрос отраслевых аналитических данных как функции данных пакета транзакций. Запрос может быть представлен пользователем в качестве запроса на поиск и/или сортировку, чтобы выбрать конкретные или общие типы данных транзакций, накопленных системой. Кроме того, запрос может включать в себя один или несколько фильтров, чтобы уменьшить объем данных транзакций в пределах выбранных типов данных транзакций, используемых в формировании аналитических данных.
На основании запроса и какого-либо фильтра система осуществляет доступ к данным пакета транзакций, чтобы идентифицировать и извлечь конкретные данные пакета транзакций, необходимые для выполнения запрошенного анализа отрасли промышленности (этап 5080). После этого отраслевые аналитические данные формируют на основании идентифицированных данных пакета транзакций (этап 5090). В формировании отраслевых аналитических данных могут использоваться различные математические и статистические функции для формирования широкого разнообразия информации, запрашиваемой пользователем. Отраслевые аналитические данные могут быть предоставлены пользователю в различных обзорах отчетов (этап 5095). Например, примерные обзоры отчетов включают в себя итоговые обзоры, обзоры по совокупным данным, обзоры оценок, статистические обзоры, обзоры о выполнении проекта или любую комбинацию из них. Отраслевые аналитические данные могут быть отображены графически, чтобы оказывать помощь пользователю в осуществлении анализа проектов или тенденций отрасли промышленности.
Как обсуждено выше, представленный пользователем запрос аналитических данных может включать в себя один или несколько фильтров, чтобы подстраивать типы данных транзакций, используемых в аналитической обработке. На Фиг.68 проиллюстрированы примерные типы фильтров 280, которые могут быть использованы для доступа к базе данных 155 или 160, чтобы извлечь фильтрованные данные транзакций 1198 с целями анализа и составления отчетов. Например, фильтры 280 могут включать в себя параметры 280a профиля продавца, параметры 280b профиля покупателя, параметры 280c профиля проекта и параметры 280d профиля товара. Параметры профиля продавца 280a включают в себя любой вид данных, связанных с продавцом, например группу уровня продавца, тип предприятия продавца, квалификационные данные продавца, географическое местонахождение продавца и т.д. Аналогично параметры 280b профиля покупателя подобным образом включают в себя любой вид данных, связанных с покупателем, например сегмент отрасли промышленности покупателя, объем (капитала) и расходы покупателя, географическое местонахождение покупателя и т.д. Параметры 280c профиля проекта включают в себя любой вид данных, связанных с проектом, например тип проекта, тип прав собственности управления проектом, тип воздействия на деятельность предприятия, географическое местонахождение проекта сектор/семейство проекта, другие параметры отслеживания проекта и т.д. Параметры 280d профиля товара включают в себя любой вид данных, связанных с товаром (например, людские или материальные ресурсы), таких как сектор/семейство проекта, связанные с товаром, профилированием ресурсов, типами деятельности, географическим местонахождением и т.д.
Примерные этапы для извлечения фильтрованных данных транзакций из базы данных показаны на Фиг.69. После того как данные транзакций сохранены в базе данных (этап 5100), может быть принят (этап 5110) последующий запрос аналитических данных как функции данных транзакций. На основании типа запроса (например, типа запрашиваемых аналитических данных) система осуществляет доступ к базе данных, чтобы извлечь типы данных транзакций, необходимые для ответа на запрос (этап 5120). Если запрос включает в себя один или несколько фильтров (этап 5130), система фильтрует извлеченные данные транзакций (этап 5140) перед формированием запрошенных аналитических данных (5150). Фильтры являются функцией уменьшения объема данных транзакций, используемых в аналитической обработке. Например, если запрос для финансового отчета, подводящего итоги ежемесячных расходов по проектам для покупателя, покупатель может фильтровать отчет, чтобы он включал только ежемесячные расходы по проектам для конкретного продавца или по проектам для конкретного типа проекта.
Экранные представления примерных web-страниц, представляющих обзоры по составлению отчетов, содержащих аналитические данные, показаны на Фиг.70-88. На Фиг.70 показано примерное изображение web-страницы 61 пользователя-покупателя "Главное меню отчетов". Понятно, что подобное "Главное меню отчетов" может быть предусмотрено для пользователей-продавцов, административных пользователей и пользователей-подрядчиков. "Главное меню отчетов" предназначено, чтобы дать возможность пользователям управлять проектами с разнообразных точек зрения. Поэтому из "Главного меню отчетов" пользователь может выбрать тип 350 составления отчетов, исходя из которого пользователь может выбрать конкретный обзор 360 отчета. Например, Фиг.70 иллюстрирует три типа 350 составления отчетов: финансовый, проектный и по капиталу продавца/человеческому. В пределах каждого из этих типов составления отчетов имеются многие обзоры 360 отчетов.
Примерами обзоров 360 отчетов в рамках финансового типа 350 составления отчетов являются обзор подробностей по счету, обзоры сводных данных по товарам, обзоры по схемам/сметам будущих расходов и обзоры финансового анализа завершенных проектов. Примерами обзоров 360 отчетов для проектного типа 350 являются обзор по исполнению проекта, обзоры по плановому развитию фаз проекта и деятельности по сдачам/поставкам и обзоры по модулю планирования управления проектом. Примерами обзоров 360 отчетов для типа 350 составления отчетов по капиталам продавца/человеческим являются финансовые обзоры, операционные обзоры и обзоры последовательностей (цепочек) поставок. Однако понятно, что настоящее изобретение не является ограниченным конкретными типами 350 составления отчетов и обзорами 360 отчетов, показанными на Фиг.70, и типы 350 составления отчетов, и обзоры 360 отчетов включены в состав показанного на Фиг.70 лишь с целями простоты и примера. Количество различных типов 350 составления отчетов и обзоров 360 отчетов ограничено только типом и количеством данных транзакций, поддерживаемых системой и требованиями пользователя.
Примеры конкретных типов обзоров 360 отчетов показаны на Фиг.71-88. Например, на Фиг.71 показан примерный экранное представление web-страницы 61, представляющей обзор 360 отчета подробностей по счету. В состав обзора 360 отчета включены аналитические данные 270, связанные с конкретными счетами (или денежными документами). Аналитические данные 270 счетов могут быть отсортированы по набору переменных, фильтруемых с использованием множества различных фильтров 280, и по ним могут быть подведены итоги в некотором количестве различных обзоров 360 отчета. Например, на основании обзора подробностей по счету данные транзакций, используемые для формирования аналитических данных в обзоре подробностей по счету, могут быть подытожены в соответствии с типом проекта и отображены в области обзора сводных данных о счете, соответствующей проекту, в качестве аналитических данных по счету для типа проекта. Фильтры 280 и дополнительные обзоры 360 отчетов, которые возможны для обзора 360 отчета, предназначенного для подробностей по счету, не являются ограниченными проиллюстрированными на Фиг.71 и могут быть расширены, чтобы включать в состав какое-либо определенное заказчиком поле (ОЗП).
На Фиг.72 показано примерное экранное представление web-страницы 61, предоставляющей основной обзор 360 сводных данных о ежемесячных расходах, содержащий аналитические данные 270, приводящие перечень общих расходов по проекту в течение текущего месяца и предшествующих месяцев. На многие дополнительные обзоры 360 отчетов о сводных данных могут быть установлены ссылки из обзора 360 отчета об основных ежемесячных сводных данных. Например, данные транзакций при формировании аналитических данных 270 могут быть подытожены в соответствии с географическим местонахождением и отображены в качестве обзора 360 сводных данных по расходам, связанным с географическим местонахождением, для того, чтобы оказать помощь пользователю в определении суммы расходов на проекты, осуществляемые в различных географических зонах.
В качестве другого примера, как показано на Фиг.73, данные транзакций при формировании аналитических данных 270 могут быть подытожены в соответствии с типом проекта и отображены на web-странице 61 в качестве обзора 360 сводных данных о расходах на виды поставок по проекту, в котором содержатся аналитические данные 270, приводящие перечень ежемесячных расходов на различные виды поставок по проекту. Например, по расходам может быть подведен итог в соответствии со сдачами/поставками по твердой цене, сдачами/поставками единиц, сдачами/поставками материалов и по времени, по времени и расходам, только по времени, договорам на услуги или другим видам поставок по проекту. Кроме того, могут быть сформированы статистические аналитические данные 270, относящиеся к данным транзакций о расходах для каждого вида поставок по проекту, для того, чтобы оказать помощь пользователю в определении процентов относительно общих расходов, сделанных по каждому виду поставки по проекту в течение каждого месяца. Однако понятно, что многие другие аналитические/статистические данные могут быть сформированы и отображены во многих других обзорах отчетов с использованием одних и тех же данных транзакций, соответствующих расходам.
Как видно в нижней части web-страницы, показанной на Фиг.73, можно предусмотреть ссылку, чтобы осуществлять обзор внешних (например, базы данных верхнего уровня) данных, относящихся к данным транзакций, соответствующим расходом. Следовательно, пользователь не нуждается в регистрации на другом сервере для доступа к данным транзакций, соответствующим верхнему уровню. Хотя должно быть понятно, что в других воплощениях может потребоваться отдельная процедура регистрации в системе. Если пользователь осуществляет щелчок по ссылке на внешние данные, то пользователю может быть представлен сводный обзор 360 отчета, такой как показан на Фиг.74.
На Фиг.74 показано экранное представление примерной web-страницы 61, содержащей отраслевые аналитические данные 270, представленные в обзоре 360 внешних данных об итоговых расходах на виды поставок по проекту. На Фиг.74 показаны два различных примера отраслевых аналитических данных 270, хотя только один из них может быть отображен в данный момент времени, в зависимости от запроса и фильтров, введенных пользователем. На верхней части web-страницы 61 показано, что статистические аналитические данные 270 определяют по отношению к общим расходам процент расходов, сделанных по каждому виду поставки по проекту в течение каждого месяца в сегменте автомобильной промышленности. В средней части web-страницы 61 показано, что статистические аналитические данные 270 определяют по отношению к общим расходам процент расходов, сделанных покупателями, имеющими сверхвысокий капитал, по каждому виду поставки по проекту в течение каждого месяца.
Как видно на web-странице 61, показанной на Фиг.74, можно предусмотреть ссылку на различные обзоры, которые сравнивают отраслевые аналитические данные с аналитическими данными конкретной компании пользователя. Если пользователь осуществляет щелчок по ссылке на внешние данные, то пользователю может быть предоставлен обзор 360 сводных отчетов, такой как показан на Фиг.75. На Фиг.75 проиллюстрировано экранное представление примерной web-страницы 61, содержащей сравнение отраслевых аналитических данных 270 и аналитических данных 270 индивидуального покупателя, которое предоставлено в обзоре 360 сводных сравнительных данных по типам поставок проекта по проекту. На Фиг.75 показаны два различных примера сравнения аналитических данных 270, хотя только один из них может быть отображен в данный момент времени, в зависимости от запроса и фильтров, введенных пользователем. В верхней части web-страницы 61 аналитические данные 270, определяющие индивидуальные ежемесячные расходы покупателя по каждому виду поставок по проекту, сравнивают со средними ежемесячными расходами по отрасли для каждого вида поставок по проекту. В нижней части web-страницы 61 аналитические данные 270, определяющие процент от общих расходов, который покупателем сделан по каждому виду поставок по проекту в течение каждого месяца, сравнивают с процентом от общих расходов, который сделан по каждому виду поставок по проекту в течение каждого месяца в отрасли.
На Фиг.76 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, связанные с конкретным проектом, который предоставлен в обзоре 360 отчета сводных данных о затратах на проект. Аналитические данные 270 могут включать в себя состояние проекта, суммарные затраты на осуществление проекта до настоящего времени, объем заявок (то есть объем, зарегистрированный для проекта), процентное отношение затраченного на данный проект по сравнению со всеми проектами, в настоящее время ведомыми покупателем, гарантии проекта и другие соответствующие определению затрат на проект аналитические данные. В нижней части web-страницы 61 находятся ссылки на различные обзоры 360 отчетов по определению затрат на проект, по которым подводят итог в соответствии с различными типами данных транзакций, такими как тип воздействия на деятельность, география, продавцы, и т.д.
На Фиг.77 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, связанные с оцениваемыми будущими (срочными) расходами для одного или нескольких проектов, которые предоставлены в обзоре 360 отчета оценки расходов по проекту. На Фиг.77 показаны два различных примера аналитических данных 270 будущих расходов, хотя только один из них может быть отображен в данный момент времени, в зависимости от запроса и фильтров, введенных пользователем. В верхней части web-страницы 61 показаны аналитические данные 270, связанные с оцениваемыми будущими расходами для конкретного проекта, тогда как в средней части web-страницы показаны оцениваемые будущие расходы для всех проектов. В нижней части web-страницы 61 находятся ссылки на различные обзоры 360 отчетов по оценке будущих расходов по проекту, по которым подводят итог в соответствии с различными типами данных транзакций, такими как тип воздействия на деятельность, география, продавцы и т.д.
В качестве примера, если пользователь осуществляет щелчок по ссылке, чтобы подвести итог оцененным будущим расходам по проекту в соответствии с сектором и семейством проекта, то обзор 360 отчета, подобный показанному на Фиг.78, может быть предоставлен пользователю на примерной web-странице 61. Обзор 360 отчета, показанный на Фиг.78, является обзором 360 отчета по оценочной модели будущих расходов по проекту, объединенных по сектору/семейству проекта, который содержит аналитические данные 270, относящиеся к оцененным будущим расходам по проектам в различных секторах/семействах проекта. Такой тип обзора 360 отчета может быть полезен для пользователей, чтобы гарантировать, что организационные инвестиции осуществляют в соответствии с планами деятельности.
На Фиг.78 показаны три различных примера оцененных будущих расходов по проекту для сектора/семейства, хотя только один из них может быть отображен в данный момент времени, в зависимости от запроса и фильтров, введенных пользователем. В верхней части web-страницы 61 аналитические данные 270 содержат оцененные будущие расходы по месяцам, которые объединены в соответствии с сектором/семейством проекта. В средней части web-страницы аналитические данные 270 содержат статистические данные, связанные с оцененными будущими расходами для конкретного семейства проекта, например оцененного процента от общих расходов, который будет делаться для конкретного семейства проекта ежемесячно. В нижней части web-страницы аналитические данные 270 содержат статистические данные, связанные с оцененными будущими расходами в конкретный сектор проекта, например оцененный процент от общих расходов, который будет делаться для конкретного сектора проекта ежемесячно. В нижней части web-страницы 61 может быть предусмотрена ссылка на внешние данные, чтобы просмотреть отчеты, содержащие внешние аналитические данные относительно намеченных будущих расходов. Такие внешние данные могут быть полезны, чтобы обеспечить понимание того, насколько общие или конкретные участники рынка инвестируют или планируют удовлетворить цели их деятельности.
На Фиг.79 показано экранное представление примерной web-страницы 61, содержащей связанные с данными о выполнении проекта для конкретного проекта аналитические данные 270, которые представлены в обзоре 360 сводного отчета по выполнению проекта. Аналитические данные 270 могут включать в себя состояние проекта, количество завершенных фаз проекта, количество фаз после срока, количество завершенных проектных сдач/поставок, количество завершенных после срока проектных сдач/поставок, процентное отношение сдач/поставок, завершенных вовремя, и другие аналитические данные о выполнении проекта. В нижней части web-страницы 61 находятся ссылки на различные обзоры 360 отчетов по выполнению проекта, по которым подводят итог в соответствии с различными типами данных транзакций, такими как тип воздействия на деятельность, география, продавцы, и т.д. Таким образом, из этой web-страницы 61 могут быть сформированы совокупные и другие статистические аналитические данные, по которым подводят итог в соответствии с типом данных транзакций.
В качестве примера, если пользователь осуществил щелчок по ссылке, чтобы подвести итог по аналитическим данным о выполнении проекта в соответствии с типом прав собственности управления проектом, то обзор 360 отчета, подобный показанному на Фиг.80, может быть предоставлен пользователю на примерной web-странице 61. Обзор 360 отчета, показанный на Фиг.80, является сводным отчетом об операционных характеристиках для проектов, управляемых в соответствии с различными типами собственности, например "в собственности покупателя", "в собственности продавца", "совместная собственность" и т.д., содержит аналитические данные 270, связанные с выполнением проектов, имеющих различные права собственности. Этот тип обзора 360 отчета может быть полезен для пользователей, чтобы понять взаимосвязи между интенсивностью успехов/отказов как функции прав собственности управления проектом. В нижней части web-страницы 61 может быть обеспечена ссылка на внешние данные, чтобы просмотреть отчеты, содержащие внешние аналитические данные о выполнении проекта, по мере их отношения к правам собственности управления проектом. В качестве другого примера, если пользователь осуществил щелчок по ссылке в нижней части web-страницы 61 по Фиг.79, чтобы просмотреть отчет по рискам/отказам, то обзор 360 отчета, подобный показанному на Фиг.81, может быть представлен пользователю на примерной web-странице 61. Обзор 360 отчета, показанный на Фиг.81, является отчетом по исключительным ситуациям при выполнении проекта, соответствующего рискам/отказам, содержит аналитические данные 270, связанные с выполнением проектов "с риском" или нарушающих условия проектов, имеющих просроченные даты или другие трудности.
На Фиг.82 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, относящиеся к планированию проекта, которые представлены в обзоре 360 отчета таблицы планирования. Аналитические данные 270 могут включать в себя, например, общие подсчеты по проекту за текущий месяц и за будущие месяцы и другие аналитические данные 270 по планированию проекта. На Фиг.83 показано экранное представление примерной web-страницы 61, содержащей аналитические данные, относящиеся к более конкретному планированию проекта, которые представлены в обзоре 360 отчет инструментального средства планирования проекта. Например, пользователь может выбрать конкретный сектор/семейство проекта и выбирать из различных "переменных воздействия" (например, фильтры 280), например географии, уровня продавца и т.д., и различных обзоров 360 отчетов по выполнению проекта, чтобы представить обзор 360 отчетов, содержащих совокупные итоговые аналитические данные 270, связанные с каждой комбинацией перечисленных переменных воздействия, связанных с конкретными данными о выполнении проекта за прошлое время. Данный тип обзора 360 отчетов может быть полезен для пользователя, чтобы обеспечить существенное понимание того, какие конфигурации торгово-промышленной деятельности (переменные сводные показатели) были благоприятными и какие не были.
На Фиг.84 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, относящиеся к тенденциям изменений расходов как функции уровней продавцов, которые представлены в обзоре 360 отчетов о расходах в соответствии с кодом уровня продавца. На Фиг.84 показаны два примера данных о расходах в соответствии с уровнем продавца, хотя только один из них может быть отображен в данный момент времени, в зависимости от запроса и фильтров, введенных пользователем. В верхней части web-страницы 61 аналитические данные 270 включают в себя суммы, израсходованные одним или несколькими продавцами в пределах конкретного уровня продавцов ежемесячно. В нижней части web-страницы 61 аналитические данные 270 включают в себя количество продавцов на данном уровне продавцов, общую сумму, израсходованную продавцами, относящимися к данному уровню продавцов, ежемесячно и другие совокупные или статистические аналитические данные 270 о расходах продавцов данного уровня.
На Фиг.85 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, относящиеся к квалификационной информации продавца, которая представлена в обзор 360 отчета о квалификации продавца. Аналитические данные могут включать в себя, например, перечень информации о определенных покупателем критериях оценки продавца, связанной с квалификационной информацией о продавце для каждого продавца, и указание того, удовлетворяет или не удовлетворяет продавец каждому из определенных покупателем квалификатору продавца. В нижней части web-страницы 61 имеются дополнительные ссылки на различные обзоры 360 отчетов о сводных данных, чтобы объединить и/или выполнить статистические анализы различных квалификационных данных продавцов.
На Фиг.86 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, относящиеся к использованию людских ресурсов как функции географии, которые представлены в обзоре 360 отчета о географическом развертывании ресурсов. Аналитические данные 270 могут включать в себя статистическую информацию, например процентное соотношение ресурсов, используемых в конкретной стране, районе или городе, и процентное соотношение времени работы в конкретной стране, районе или городе и процентное соотношение денег, израсходованных на людские ресурсы в конкретной стране, районе или городе. Аналитические данные 270 могут дополнительно включать в себя различную совокупную информацию, например общее количество ресурсов, времени и денег, израсходованных в конкретной стране, районе или городе. Данный тип обзора 360 отчетов о людских ресурсах может быть полезен для пользователя в случае, когда имеют дело с вопросами, такими как управления производственными мощностями, определением цен, совместной занятостью компании, реорганизацией и т.д.
На Фиг.87 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, относящиеся к людским ресурсам, которые представлены в обзоре 360 отчета об используемым продавцом ресурсом человеческого капитала. На Фиг.87 показаны три различных примера данных о людских ресурсах, хотя только один из них может быть отображен в данный момент времени, в зависимости от запроса и фильтров, введенных пользователем. В верхней части web-страницы 61 аналитические данные 270 включают в себя индивидуальную информацию о подрядчике как функцию выполнения проекта. В средней части web-страницы 61 аналитические данные 270 включают в себя совокупную и статистическую информацию о подрядчике, относящуюся к конкретному продавцу. В нижней части web-страницы 61 аналитические данные 270 включают в себя совокупную и статистическую информацию о подрядчике, связанную со многими продавцами. В нижней части web-страницы 61 дополнительно имеются ссылки на различные обзоры 360 сводных отчетов для объединения и/или выполнения статистического анализа на различных данных подрядчика.
На Фиг.88 показано экранное представление примерной web-страницы 61, содержащей аналитические данные 270, относящиеся к характеристикам продавца, которые представлены в обзоре 360 отчета о результате оценки продавца. Этот обзор 360 отчета включает в себя несколько фильтров 280, которые могут быть использованы, чтобы сосредоточить обзор 360 на конкретных типах данных транзакций. Хотя не показано в каждом описанном выше обзоре 360 отчета, будут доступны различные фильтры для некоторых или всех обзоров 360 отчетов. Аналитические данные 270 могут включать в себя совокупную и статистическую информацию, относящуюся к предложению, выполнению проекта и деятельности по производству расходов для различных продавцов. В нижней части web-страницы 61 дополнительно имеются ссылки на различные обзоры 360 сводных отчетов, чтобы объединять и/или выполнять статистические анализы на различных данных о характеристиках продавца. Описанные выше обзоры 360 отчетов и типы аналитических данных 270, представленные в документе, предназначены, чтобы предоставить лишь пример полноты и адекватности требований модуля составления отчетов. Специалисту в данной области техники без труда будут очевидны количество и изменения для отчетных обзоров, которые являются возможными с помощью настоящего изобретения.
Специалистам в данной области техники должно быть понятно, что новаторские концепции, описанные в настоящей заявке, могут быть модифицированы и различаться в широком диапазоне применений. Соответственно, объем патентуемой сущности изобретения не должен ограничиваться каким-либо конкретным из описанных примерных указаний, а определяется в соответствии с формулой изобретения.
Предложены комплексная вычислительная система с поддержкой сетью Интернет и соответствующий способ, обеспечивающие формирование аналитических данных, относящихся к системе управления предложениями для проекта. Данные транзакций, относящиеся к предложению и проекту, вводят в вычислительную систему посредством оперативных процессов предложения, заявок по проекту и оплаты. При использовании данных транзакций, сохраняемых в системе, может быть сформирован фактически любой вид аналитических данных, связанных с одиночными проектами или множеством проектов, выполняемыми одним или несколькими продавцами для одного или нескольких покупателей. Технический результат - упрощение системы и процесса выполнения проекта предложения. 16 н. и 145 з.п. ф-лы, 105 ил., 112 табл.
принимают запрос аналитических данных, как функцию данных транзакций, причем упомянутый прием заключается в том, что принимают запрос аналитических данных, который включает в себя один или несколько фильтров, и фильтруют данные транзакций для формирования фильтрованных данных транзакций с использованием одного или нескольких фильтров для использования при формировании аналитических данных;
в ответ на запрос формируют аналитические данные с использованием фильтрованных данных транзакций на основе данных транзакций; и сохраняют индивидуальные данные транзакций, относящиеся к предложениям и проектам, покупателя, продавца или администратора в системе баз данных соответствующего покупателя, продавца или администратора, и передают, по меньшей мере, часть данных транзакций, сохраняемых в системе баз данных, в центральную базу данных, сохраняющую множество данных транзакций из множества систем баз данных, при этом аналитические данные формируют на основании множества данных транзакций.
в поля данных, связанные с предложением, вводят параметры отслеживания проекта в качестве части данных транзакций;
в поля данных, связанные с проектом, вводят информацию обязательств по платежам в качестве части данных транзакций, и в поля данных, связанные с проектом, вводят данные о выполнении проекта в качестве части данных транзакций.
web-интерфейс, подсоединяемый для приема запроса аналитических данных, как функции данных транзакций;
систему баз данных для поддержания данных транзакций, включающих в себя, по меньшей мере, данные о предложении, включая данные запроса предложения, введенные в поля данных покупателем, связанным с предложением, и данные ответа на запрос предложения, введенные в поля данных продавцом, связанным с предложением, посредством web-интерфейса, при этом система баз данных конфигурирована для сохранения индивидуальных данных транзакций, относящихся к предложениям и проектам, покупателя, продавца или администратора, сервер, соединенный с web-интерфейсом для приема запроса и соединенный с системой баз данных для извлечения данных транзакций на основании запроса, при этом сервер дополнительно действует для приема запроса, включающего в себя один или несколько фильтров, и фильтрации данных транзакций для формирования фильтрованных данных транзакций с использованием одного или нескольких фильтров, и сервер действует для формирования, в ответ на запрос, аналитических данных на основе извлеченных фильтрованных данных транзакций.
прием запроса аналитических данных, как функции данных транзакций, причем данные транзакций включают, по меньшей мере, данные предложения по проекту, введенные в поля данных предложения, сохраненные в системе баз данных, при проведении оперативного процесса предложения,
осуществление доступа к системе баз данных для извлечения данных транзакций на основании запроса и
формирование аналитических данных на основании извлеченных данных транзакций в ответ на запрос.
в поля данных, связанные с каждым из проектов, вводят данные о выполнении проекта в качестве части данных транзакций;
в поля данных, связанные с каждым из проектов, вводят параметры отслеживания проекта в качестве части данных транзакций;
принимают запросы аналитических данных, как функции данных транзакций;
формируют совокупные данные транзакций на основании запроса на формирование совокупных данных о выполнении проекта и сохраняют индивидуальные данные транзакций, относящиеся к предложениям и проектам, покупателя, продавца или администратора в системе баз данных соответствующего покупателя, продавца или администратора и передают, по меньшей мере, часть данных транзакций, сохраняемых в системе баз данных, в центральную базу данных, сохраняющую множество данных транзакций из множества систем баз данных, при этом аналитические данные формируют на основании множества данных транзакций.
в течение оперативного процесса предложения вводят в поля данных предложения компонент данных о предложении в качестве части данных транзакций;
в поля данных, связанные с предложением, вводят компонент параметров отслеживания проекта, связанный с проектом, в качестве части данных транзакций;
в поля данных, связанные с проектом, вводят компонент данных о выполнении проекта в качестве части данных транзакций;
принимают запросы аналитических данных как функции одного или нескольких компонентов данных транзакций, и
формируют аналитические данные на основании данных транзакций в ответ на запрос.
принимают запрос на отраслевые аналитические данные как функции данных транзакций, причем данные транзакций включают в себя, по меньшей мере, данные о выполнении проекта, указывающие выполнение проектов одним или более продавцами, связанными с проектами;
осуществляют доступ к данным транзакций на основании запроса; и
в ответ на запрос формируют аналитические данные на основании данных транзакций, к которым был осуществлен доступ,
при этом индивидуальные данные транзакций, относящиеся к предложениям и проектам покупателя, продавца или администратора, сохраняют в системе баз данных соответствующего покупателя, продавца или администратора, и передают, по меньшей мере, часть данных транзакций, сохраняемых в системе баз данных, в центральную базу данных, сохраняющую множество данных транзакций из множества систем баз данных для использования при формировании аналитических данных.
машиночитаемый носитель, содержащий машиноисполняемые команды, сохраняемые в нем, и
соединенный с машиночитаемым носителем процессор, предназначенный для исполнения команд, дающих возможность выбирать выборки элементов предложения из перечня элементов предложения для последующего формирования запроса предложения с использованием, по меньшей мере, части выборок элементов предложения,
при этом процессор действует для приема от покупателя данных запроса предложения, содержащихся в полях, связанных, по меньшей мере, с частью выборок элементов предложения, для передачи запроса предложения продавцу и получения от продавца ответа на запрос предложения для рассмотрения покупателем, представляющим запрос предложения, при этом ответ на запрос предложения включает в себя выборки элементов предложения и данные ответа предложения в полях, связанных, по меньшей мере, с частью выборок элементов предложения.
прием выборок элементов предложения, выбранных из заранее установленного перечня элементов предложения;
передачу выборок элементов предложения для использования в последующем формировании запроса предложения покупателем с использованием, по меньшей мере, части упомянутых выборок;
прием данных запроса предложения от покупателя, формирующего запрос предложения;
сохранение данных запроса предложения внутри полей, связанных, по меньшей мере, с частью выборок элементов предложения для запроса предложения;
передачу запроса предложения продавцу и
формирование продавцом ответа на запрос предложения, причем ответ на запрос предложения включает в себя выборки элементов предложения и данные ответа предложения внутри полей, связанных, по меньшей мере, с частью выборок элементов предложения.
обеспечивают заранее установленный перечень элементов предложения;
принимают выборки элементов предложения, выбранные из заранее установленного перечня;
передают выборки элементов предложения для использования в последующем формировании запроса предложения покупателем с использованием по меньшей мере части выборок элементов предложения;
принимают данные запроса предложения от покупателя, формирующего запрос предложения;
сохраняют данные запроса предложения внутри полей, связанных, по меньшей мере, с частью выборок элементов предложения;
передают запрос предложения продавцу и
предоставляют возможность формирования продавцом ответа на запрос предложения, при этом ответ на запрос предложения включает в себя выборки элементов предложения и данные ответа на запрос предложения, находящиеся внутри полей, связанных, по меньшей мере, с частью выборок элементов предложения.
систему баз данных для поддержания конфигурируемого заранее установленного перечня элементов предложения и шаблона предложения для проекта, включающего в себя выборки элементов предложения, выбранные из перечня элементов предложения;
сервер, соединенный с системой баз данных и соединяемый с покупателем и продавцом посредством web-интерфейса, при этом сервер содержит модуль покупателя, предназначенный для осуществления взаимодействия между системой баз данных и web-браузером покупателя для передачи данных, относящихся к процессу предложения проекта, от покупателя и к покупателю по сети передачи данных; и
модуль продавца, предназначенный для установления связи между системой баз данных и web-браузером продавца для передачи данных, относящихся к процессу предложения проекта, к продавцу и от продавца по сети передачи данных,
при этом сервер действует для формирования запроса предложения для проекта с использованием шаблона предложения, передачи запроса предложения продавцу посредством web-интерфейса и приема от продавца ответа на запрос предложения посредством web-интерфейса, при этом ответ на запрос предложения включает в себя данные ответа предложения, связанные, по меньшей мере, с частью выборок элементов предложения;
сервер также действует для приема данных запроса предложения и сохранения данных запроса предложения внутри полей, связанных, по меньшей мере, с частью выборок элементов предложения, при этом данные ответа предложения включают в поля, связанные, по меньшей мере, с частью выборок элементов предложения, и для передачи покупателю ответа на запрос предложения после заполнения продавцом требуемых полей.
административный модуль, предназначенный для осуществления взаимодействия между системой баз данных и административным web-браузером для передачи данных, относящихся к процессу предложения проекта, к администратору и от администратора по сети передачи данных; и модуль подрядчика, предназначенный для установления связи между системой баз данных и web-браузером подрядчика для передачи данных, относящихся к процессу предложения проекта, к подрядчику и от подрядчика по сети передачи данных.
модуль покупателя, предназначенный для осуществления взаимодействия между второй базой данных и web-браузером администратора для передач административных данных, относящихся к покупателям, к администратору и от администратора по сети передачи данных;
модуль продавца для осуществления взаимодействия между второй базой данных и web-браузером администратора для передач административных данных, относящихся к продавцам, к администратору и от администратора по сети передачи данных; и
модуль подрядчика для осуществления взаимодействия со второй базой данных и web-браузером администратора для передачи административных данных, относящихся к подрядчикам, к администратору и от администратора по сети передачи данных.
сохраняют выборки элементов предложения, выбранные из конфигурируемого заранее установленного перечня элементов предложения;
формируют запрос предложения, связанный с покупателем, с использованием, по меньшей мере, части выборок элементов предложения, при этом для формирования запроса предложения принимают от покупателя данные запроса предложения и сохраняют данные запроса предложения внутри полей, связанных, по меньшей мере, с частью выборок элементов предложения;
передают запрос предложения, по меньшей мере, одному продавцу для запрашивания ответа на предложение, формируемого с помощью выборок элементов предложения, включенных в запрос предложения;
принимают от продавца ответ на запрос предложения, включающий в себя данные ответа на запрос предложении в полях, связанных, по меньшей мере, с частью выборок элементов предложения; и
передают покупателю ответы на запрос предложения после заполнения продавцом всех обязательных полей из упомянутых полей.
сравнивают квалификационные данные продавца для каждого продавца из набора продавцов с информацией о критериях оценки продавца, чтобы для покупателя определить набор подходящих продавцов; и из подходящих продавцов выбирают, по меньшей мере, одного продавца для приема запроса предложения.
идентифицируют, по меньшей мере, один ранжированный элемент предложения из выборок элементов предложения и
принимают ранг для ответа на запрос предложения, относящийся, по меньшей мере, к одному ранжированному элементу предложения, при этом ранг определяется на основе данных ответа на запрос предложения, связанных, по меньшей мере, с одним ранжированным элементом предложения.
принимают ответ на запрос предложения, содержащий данные ответа, связанные с каждой выборкой элементов предложения из набора выборок, которые предварительно выбраны из перечня заранее установленных элементов предложения, для включения в последующий запрос предложения, запрашивающий ответ предложения;
идентифицируют, по меньшей мере, один ранжированный элемент предложения из выборок элементов предложения для ранжирования ответа предложения, и
принимают ранг для ответа на запрос предложения, относящийся, по меньшей мере, к одному ранжированному элементу предложения, причем ранг определяется на основе данных ответа на предложение, связанных, по меньшей мере, с одним ранжированным элементом предложения.
поддерживают конфигурируемый заранее установленный перечень элементов предложения и шаблон предложения, включающий в себя выборки элементов предложения, выбранные из перечня элементов предложения;
формируют запрос предложения для проекта с использованием шаблона предложения;
передают запрос предложения квалифицированному продавцу посредством web-интерфейса на основании выборок элементов предложения;
принимают ответ на предложение от квалифицированного продавца посредством web-интерфейса, включающего в себя данные ответа на предложение, связанные, по меньшей мере, с частью выборок элементов предложения, и
принимают параметры отслеживания проекта после назначения проекта для отслеживания выполнения проекта.
поддерживают конфигурируемый перечень заранее установленных элементов предложения и шаблон предложения, включающий в себя выборки элементов предложения, выбранные из перечня элементов предложения;
формируют запрос предложения для проекта с использованием шаблона предложения;
передают запрос предложения квалифицированному продавцу посредством web-интерфейса на основе выборок элементов предложения;
принимают ответ на предложение от квалифицированного продавца посредством web-интерфейса, включающий данные ответа на предложение, связанные с каждой из выборок элементов предложения, и разрешают ранжирование ответа предложения с использованием данных ответа на предложение, связанных, по меньшей мере, с одним ранжированным элементом предложения, выбранным из выборок элементов предложения для решения о назначении проекта.
принимают запрос предложения посредством web-интерфейса, при этом запрос предложения включает в себя, по меньшей мере, часть выборок элементов предложения, выбранных из конфигурируемого заранее установленного перечня элементов предложения;
вводят данные ответа на предложение в поля, связанные, по меньшей мере, с частью выборок элементов предложения, включенных в состав запроса предложения, для создания ответа на запрос предложения и передают ответ на предложение посредством web-интерфейса.
выбирают выборки элементов предложения из конфигурируемого заранее установленного перечня элементов предложения для создания шаблона предложения;
включают, по меньшей мере, часть выборок элементов предложения, связанных с шаблоном предложения, в запрос предложения;
вводят данные предложения в поля, связанные, по меньшей мере, с частью включенных выборок элементов предложения, для создания запроса предложения, и
передают запрос предложения посредством web-интерфейса на рассылку запроса предложения квалифицированным продавцам.
| СПОСОБ АКТУАЛИЗАЦИИ ИНФОРМАЦИИ ДЛЯ ЕЕ ОБРАБОТКИ В ИНФОРМАЦИОННОЙ СИСТЕМЕ | 1998 |
|
RU2150143C1 |
| Приспособление для монтировки кинофильм | 1926 |
|
SU6640A1 |
| Прибор для нахождения центра в буксах паровозов | 1929 |
|
SU17744A1 |
| Топчак-трактор для канатной вспашки | 1923 |
|
SU2002A1 |
