Система и способ наделения полномочиями организаций-субподрядчиков и управления ими
Изобретение относится способам и системам наделения полномочиями организаций-субподрядчиков и управления ими. Техническим результатом является обеспечение инструмента для создания и автоматической обработки заявки по проекту. Для этого способ содействия процедуре заявки на подряд по проекту включает в себя генерирование связанного с покупателем запроса на заявку с использованием, по меньшей мере, части вариантов выбора пунктов заявки из сохраненного списка пунктов заявки, передачу связанного с покупателем запроса на заявку, по меньшей мере, одному поставщику с просьбой о генерировании ответа поставщика на заявку с вариантами выбора пунктов заявки, использованными в связанном с покупателем запросе на заявку, генерирование связанного с поставщиком запроса на заявку с использованием, по меньшей мере, части вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку, и передачу связанного с поставщиком запроса на заявку, по меньшей мере, одной организации-субподрядчику с просьбой о генерировании ответа организации-субподрядчика на заявку с вариантами выбора пунктов заявки, использованными в связанном с поставщиком запросе на заявку. 6 н. и 90 з.п. ф-лы, 32 ил., 41 табл.
Перекрестная ссылка на связанные заявки
Настоящая патентная заявка является заявкой в частичное продолжение Патентной заявки США № 10/412096 (Досье поверенного № 57084-00532USP1). Патентная заявка США № 10/412096 является заявкой в частичное продолжение Патентной заявки США № 10/262487 (Досье поверенного № 57084-00532USPT), поданной 30 сентября 2002 г. Патентная заявка США № 10/262487 испрашивает приоритет Предварительной патентной заявки США № 60/371,488 (Досье поверенного № 57084-00532USPL), поданной 10 апреля 2002 г. Патентная заявка США № 10/412096 испрашивает приоритет Предварительной патентной заявки США № 60/371,488 (Досье поверенного № 57084-00532USPL). Настоящая патентная заявка включает в себя посредством ссылки полное раскрытие Предварительной патентной заявки США № 60/371488 и Патентных заявок США № 10/262487 и 10/412096. Настоящая патентная заявка также включает в себя посредством ссылки полное раскрытие Патентной заявки США № 10/141801 (Досье поверенного № 57084-00542USPT), поданной 9 мая 2002 г.
Область техники
Настоящее изобретение в целом относится к способу и системе наделения полномочиями организаций-субподрядчиков и управления ими. Более конкретно, в качестве примера, настоящее изобретение относится к содействию электронными средствами, различным аспектам использования организации-субподрядчика (ОСП) при работах по проекту, включающих в себя, в частности, предоставление полномочий ОСП, процедуру заявки на подряд, процедуру требования на закупку, процедуру расходования средств и процедуру управления производительностью.
История развития предшествующего уровня техники
Общепринятой деловой практикой среди поставщиков услуг/товаров, в частности среди основных поставщиков товаров или услуг, в секторе работ по проектам, является использование поставщиков второго уровня из цепочки поставок и даже последующих более низких уровней. Такие поставщики второго и далее уровней называются организациями-субподрядчиками (ОСП). ОСП - это любой поставщик товаров и/или услуг, поставляющий товары и/или услуги покупателю с согласия основного поставщика товаров и/или услуг и во взаимодействии с ним. ОСП используются для доставки, в целом или частично, доставляемых материалов при работе над проектом, затребованных конечными пользователями или покупателями. Вышеописанное использование ОСП может осуществляться уполномоченным поставщиком по различным причинам, например, для расширения возможностей поставки товаров/услуг покупателям, когда основной поставщик не может удовлетворить требования спроса в силу логистики или технологии, а также для снижения затрат основного поставщика, когда ОСП может поставить товары/услуги по более конкурентоспособной цене.
Независимо от причин, лежащих в основе использования ОСП, использование ОСП общепринято в секторе работ по проектам. Во многих случаях поставщики, использующие ОСП при работах по субподрядам, делают это таким образом, что покупатель практически не замечает использования ОСП поставщиками. Хотя использование ОСП направлено на предоставление покупателю необходимых доставляемых материалов/результатов работ по проекту, такая относительно скрытая природа работ по субподрядам может привести, по меньшей мере, к одному из следующих последствий: 1) рост потенциальных рисков ответственности; 2) отстранение покупателя от контроля над управлением ОСП; 3) сокрытие данных об издержках/ценах ОСП; 4) сокрытие дополнительного увеличения основным поставщиком издержек/цен ОСП; 5) затруднение измерения покупателем производительности ОСП; 6) затруднение измерения покупателем производительности, связанной с товарами/услугами, непосредственно предоставленными основными поставщиками; 7) снижение возможностей проверок деятельности и обработки данных; и 8) снижение для покупателя способности эффективного управления продуктом работ по проекту и использования деловых возможностей, которые могли бы иметь место, если бы деятельность ОСП была более видимой и управляемой.
Сущность изобретения
Способ содействия процедуре заявки на подряд по проекту включает в себя генерирование покупательского запроса на заявку с использованием, по меньшей мере, части вариантов выбора пунктов из сохраненного списка пунктов заявки, передачу покупательского запроса на заявку, по меньшей мере, одному поставщику, с просьбой о генерировании ответа поставщика на заявку с вариантами выбора пунктов заявки, использованными в покупательском запросе на заявку, генерирование запроса поставщика на заявку, с использованием, по меньшей мере, части вариантов выбора пунктов, использованных в покупательском запросе на заявку, и передачу запроса поставщика на заявку, по меньшей мере, одной организации-субподрядчику с просьбой о генерировании ответа организации-субподрядчика на заявку с использованием вариантов выбора пунктов из запроса поставщика на заявку.
Компьютерная система для содействия процедуре заявки на подряд по проекту с участием покупателя, поставщика и, по меньшей мере, одной организации-субподрядчика включает в себя систему базы данных для поддержания конфигурируемого, заранее установленного списка пунктов заявки и шаблона заявки для проекта и сервер, связанный с системой базы данных, с возможностью связи с покупателем, поставщиком и, по меньшей мере, одной организацией-субподрядчиком. Шаблон заявки включает в себя выборку пунктов заявки из списка пунктов заявки. Сервер обеспечивает генерирование покупательского запроса на заявку при помощи шаблона заявки, передачи покупательского запроса на заявку поставщику, генерирование запроса поставщика на заявку посредством синтаксического анализа запроса поставщика на заявку, передачи запроса поставщика на заявку, по меньшей мере, одной организации-субподрядчику, получения ответа организации-субподрядчика на запрос поставщика на заявку и получение ответа поставщика на заявку. Указанный ответ поставщика на заявку включает в себя, по меньшей мере, частично, данные из ответа организации-субподрядчика на заявку.
На машиночитаемом носителе, содержащем сохраненные инструкции, выполняемые компьютером, указанные выполняемые компьютером инструкции включают в себя средство для генерирования покупательского запроса на заявку с использованием, по меньшей мере, части выбранных пунктов заявки из сохраненного списка пунктов заявки, средство для передачи покупательского запроса на заявку, по меньшей мере, одному поставщику с просьбой о генерировании ответа поставщика на заявку, с выбранными пунктами заявки, использованными в покупательском запросе на заявку, средство для генерирования запроса поставщика на заявку, с использованием, по меньшей мере, части выбранных пунктов заявки, использованных в покупательском запросе на заявку, и средство для передачи запроса поставщика на заявку, по меньшей мере, одной организации-субподрядчику с просьбой о генерировании ответа организации-субподрядчика на заявку, с выбранными пунктами заявки, использованными в запросе поставщика на заявку.
Способ управления процедурой заявки на подряд по проекту включает в себя получение запроса на предоставление полномочий организации-субподрядчику и получение запроса аффилирования в отношении основного поставщика. Запрос аффилирования требует, чтобы организация-субподрядчик была аффилирована с основным поставщиком. Способ также включает в себя передачу покупательского запроса на заявку поставщику, передачу организации-субподрядчику цепочечной расценки, связанной с покупательским запросом на заявку, и получение заполненной цепочечной расценки от организации-субподрядчика. Заполненная цепочечная расценка включает в себя соответствующие заполненные пункты из цепочечной расценки, которая была передана организации-субподрядчику. Указанный способ также включает в себя обновление ответа поставщика на заявку, в отношении покупательского запроса на заявку, с использованием, по меньшей мере, некоторых соответствующих заполненных пунктов из цепочечной расценки и передачу обновленного ответа поставщика на заявку покупателю.
На машиночитаемом носителе, содержащем сохраненные инструкции, выполняемые компьютером, указанные выполняемые компьютером инструкции включают в себя средства получения запроса на предоставление полномочий организации-субподрядчику, средство для получения запроса аффилирования основным поставщиком, причем указанный запрос требует, чтобы организация-субподрядчик была аффилирована с основным поставщиком, средство для передачи поставщику покупательского запроса на заявку, средство для передачи организации-субподрядчику цепочечной расценки, связанной с покупательским запросом на заявку, и средство для получения заполненной цепочечной расценки от организации-субподрядчика. Указанная заполненная цепочечная расценка включает в себя соответствующие заполненные пункты из цепочечной расценки, которая была передана организации-субподрядчику. Указанные машиночитаемые инструкции также включают в себя средство для обновления ответа поставщика на заявку, относящегося к покупательскому запросу на заявку, с использованием, по меньшей мере, некоторых из соответствующих заполненных пунктов цепочечной расценки, и средство для передачи покупателю обновленного ответа поставщика на заявку.
Компьютерная система управления процедурой заявки на подряд по проекту включает в себя систему базы данных и сервер, связанный с системой базы данных. Сервер обеспечивает получение запроса на предоставление полномочий организации-субподрядчику, получение запроса аффилирования с основным поставщиком, причем указанный запрос требует, чтобы организация-субподрядчик была аффилирована с основным поставщиком, передачу покупательского запроса на заявку поставщику, передачу организации-субподрядчику цепочечной расценки, связанной с покупательским запросом на заявку и получение заполненной цепочечной расценки от организации-субподрядчика. Заполненная цепочечная расценка включает в себя соответствующие заполненные пункты цепочечной расценки, относящиеся к цепочечной расценке, которая была передана организации-субподрядчику. Сервер также обеспечивает обновление ответа поставщика на заявку, относящегося к покупательскому запросу на заявку, с использованием, по меньшей мере, некоторых соответствующих заполненных пунктов цепочечной расценки, а также передачу обновленного ответа поставщика на заявку покупателю.
Краткое описание чертежей
Более полное понимание способа и системы, соответствующих настоящему изобретению, может быть обеспечено путем отсылки к приведенному ниже Подробному описанию типичных вариантов осуществления изобретения, иллюстрируемых чертежами, на которых:
Фиг.1A-B иллюстрируют типичный способ управления ОСП;
Фиг.2A-B иллюстрируют типичные элементы конфигурации, управляющие использованием и оценкой различных ОСП;
Фиг.3A-E иллюстрируют техническую модель/схему базы данных, которая может использоваться в связи с элементами конфигурации, показанными на Фиг.2A;
Фиг.4 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с иллюстративными элементами конфигурации, показанными на Фиг.2B;
Фиг.5A-B показывают типичную схему высокого уровня, иллюстрирующую, каким образом ОСП может получить полномочия и стать связанной с основным поставщиком;
Фиг.6 представляет техническую модель/схему базы данных, которая может использоваться в связи с типичной процедурой предоставления полномочий ОСП, показанной на Фиг.5A-B;
Фиг.7 является типичной блок-схемой, показывающей, как основной поставщик может выбирать ОСП и включать его (их) в покупательский запрос на заявку;
Фиг.8 является типичной блок-схемой, показывающей, как ОСП может обрабатывать цепочечную расценку, выданную основным поставщиком.
Фиг.9 является типичной блок-схемой, показывающей, как основной поставщик может обрабатывать ответ ОСП на цепочечную расценку;
Фиг.10 является типичной блок-схемой, показывающей, как основной поставщик может использовать инструмент анализа расценок в отношении расценок, предоставленных ОСП;
Фиг.11 является типичной блок-схемой, показывающей, как основной поставщик может добавить дополнительную цену к принятым расценкам ОСП;
Фиг.12 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с типичным цепочечным ответом ОСП на заявку, изображенную на Фиг.7-11;
Фиг.13 является типичной блок-схемой, показывающей, как покупатель может обрабатывать ответ основного поставщика на заявку;
Фиг.14 иллюстрирует типичную техническую модель/схему базы данных, которая может использоваться в связи с созданием записи ОСП и прослеживанием элементов расценки ОСП на уровне требования на закупку;
Фиг.15 является типичной блок-схемой, показывающей, как может обрабатываться оценка налогообложения и принятие требования на закупку при прохождении цепочечного требования на закупку;
Фиг.16 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с обработкой данных при цепочечном требовании на закупку;
Фиг.17 является типичной блок-схемой для обработки покупателем конфигурации и создания заказа на поставку в отношении требования на закупку, на которое воздействует ОСП.
Фиг.18 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с обработкой заказа на поставку в отношении требования на закупку, на которое воздействует ОСП.
Фиг.19 является типичной блок-схемой, показывающей, как могут обрабатываться расписки ОСП с выставлением счета/требованием оплаты;
Фиг.20 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с расписками ОСП с выставлением счета/требованием оплаты;
Фиг.21 является типичной блок-схемой возможного выставления счетов/оплаты ОСП.
Фиг.22 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с извлечением файлов данных счетов/оплаты ОСП.
Фиг.23A изображает традиционное представление цепочки поставок для покупателя.
Фиг.23B является блок-схемой, иллюстрирующей улучшенное представление цепочки поставок для покупателя; и
Фиг.24 иллюстрирует, как различные варианты осуществления изобретения могут воздействовать на цепочку поставок для покупателя.
Подробное описание типичных вариантов осуществления изобретения
Различные варианты осуществления изобретения будут более подробно описаны ниже, со ссылкой на соответствующие чертежи. Однако настоящее изобретение может быть осуществлено во многих различных видах и не должно истолковываться как ограниченное изложенными здесь вариантами осуществления. Настоящее изобретение следует рассматривать только как ограниченное пунктами формулы изобретения в том виде, в котором они существуют в настоящее время, и их эквивалентами.
В настоящем подробном описании описаны различные организации, например организация-субподрядчик (ОСП), основной поставщик и покупатель. Специалистам в данной области техники должно быть понятно, что если различные действия описаны как выполняемые одной из различных указанных организаций, то указанные действия могут быть выполнены отдельным пользователем, связанным с указанной организацией.
Различные специализированные рабочие процессы, которые могут быть осуществлены покупателем, основным поставщиком или ОСП, не обсуждаются подробно, чтобы не затемнить характерные аспекты изобретения. Специалистам в данной области техники должно быть понятно, что специализированные рабочие процессы могут быть реализованы надлежащим образом без отклонения от сущности и объема настоящего изобретения.
Различные варианты осуществления изобретения обеспечивают комплексные, основанные на WWW, систему и способ для содействия и управления всеми аспектами использования ОСП в отношении работ по проектам, включая наделение ОСП полномочиями, процедуру заявки на подряд по проекту, процедуру требования на закупку, процедуру затрат и процедуру управления производительностью. В различных вариантах осуществления изобретения организация-покупатель способна не только наблюдать, как первичные поставщики используют ОСП, но также устанавливать и конфигурировать правила управления ОСП на протяжении всего цикла работ по проекту.
Традиционно скрытая информация в отношении использования ОСП может быть введена структурированным и конфигурированным образом, что обеспечивает как наблюдаемость для покупателя, так и управление со стороны покупателя. После наделения ОСП полномочиями основные поставщики могут использовать ОСП конфигурированным и интегрированным образом, в целях дополнения ответов на заявки, отсылаемых покупателю, таким образом, чтобы обеспечить наблюдаемость и связанность с ОСП для конкретных элементов ответов на заявки, в том числе, в частности, данных о расценках/ценообразовании.
Использованные в различных вариантах осуществления изобретения способы, предоставляющие ОСП возможность ответа на заявку, предоставляют также дополнительные функциональные возможности, применимые к требованиям на закупку и к обработке заказов. ОСП, связанные с утвержденным ответом основного поставщика на заявку, получают возможность, например, предоставить необходимые данные по налогам и по приемке требования на закупку в интегрированной среде для элементов требования на закупку, применимых к указанным ОСП.
Различные варианты осуществления изобретения также позволяют покупателю сконфигурировать и составить заказ на поставку таким образом, чтобы учесть элементы ОСП в заказе на поставку и обработку расписки ОСП по требованию оплаты прямого счета в ходе проекта. Варианты осуществления изобретения, допускающие наблюдаемость и обработку заказов на поставку ОСП и расписок по требованиям оплаты счетов, позволяют оценивать производительность отдельных ОСП, а также производить прямую и косвенную обработку финансовых платежей. Посредством сравнительного анализа элементов заказа на поставку и соответствующих расписок по требованиям оплаты счета в подзаписях и/или записях обработки дискретных данных, основную функцию обработки данных можно применять как к основным поставщикам, так и к ОСП-поставщикам услуг/товаров. Различные варианты осуществления изобретения обеспечивают улучшенную наблюдаемость и возможность обработки данных для покупателей, основных поставщиков и ОСП.
Статус ОСП может быть предоставлен основному поставщику покупателя; в таком случае определенный поставщик товаров и/или услуг может функционировать для покупателя одновременно как основной поставщик и как ОСП. ОСП действуют в контексте процедуры жизненного цикла. Термин «процедура жизненного цикла» означает жизненный цикл проекта, описанный, например, на Фиг.5A и в соответствующем тексте Патентной заявки США № 10/262,487, поданной 30 сентября 2002 г. Процедура жизненного цикла подразделяется на этапы, от оценки и выбора основного поставщика до оплаты счетов и отчетности.
На Фиг.1A-B показаны примеры наделения ОСП полномочиями и управления ОСП. На Фиг.1A последовательность 100 включает в себя шаги 102-194. Шаги 102-106 относятся к наделению ОСП полномочиями. Шаги 108-142 относятся к обработке ответа на заявку с цепочечной расценкой. Шаги 144-150 относятся к обработке ответа на заявку покупателем. На Фиг.1B шаги 152-170 и 176 относятся к обработке требования на закупку. Шаги 172-174 и 178-184 относятся к обработке расписки. Шаги 186-192 относятся к обработке документов к оплате. Шаг 194 относится к использованию системы поддержки решения. Специалисты в данной области техники обратят внимание на то, что из некоторых узлов принятия решения, включенных в последовательность 100, выходит только одна стрелка. В таких случаях решения, отличные от решения, указанного стрелкой, выходящей из узла принятия решения, считаются не имеющими отношения к приведенному здесь обсуждению, и поэтому опущены, чтобы не затемнять характерные признаки настоящего изобретения.
Последовательность 100 начинается с шага 102, на котором правила шага конфигурируются покупателем для ОСП. На шаге 104 ОСП получает полномочия, и устанавливаются программно конфигурированные требования, загруженные поставщиком. На шаге 106 ОСП связывается с одним или несколькими утвержденными поставщиками. На шаге 108 утвержденный поставщик получает от покупателя запрос на расценки/запрос на предложение/запрос на заявку (RFx). На шаге 110 утвержденный поставщик решает выдать цепочечную расценку (ЦР). Термин «цепочечная» использован в контексте обработки и передачи элементов последовательности работ между организациями, при этом одна или более записей получена из основной записи путем анализа. Проанализированные записи затем передаются от одной организации к другой так, что получающая организация имеет доступ к проанализированным и переданным записям. После дальнейшей обработки проанализированные переданные записи могут вновь интегрироваться в основную запись для дальнейшей обработки как части последовательности работ. Цепочечная расценка и цепочечное приобретение являются примерами использования принципа цепочки в контексте описываемой здесь процедуры последовательности работ. В ответ на решение, на шаге 110, выдать цепочечную расценку утвержденный поставщик на шаге 112 выбирает пункты ответа на заявку для включения в цепочечную расценку. Пункты, включенные в цепочечную расценку, должны содержать как минимум один выбранный пункт услуг/товаров, по которому может быть выписан счет.
После шага 112 выполняется шаг 114. На шаге 114 утвержденный поставщик выбирает желательных, аффилированных ОСП, которым следует направить цепочечную расценку. На шаге 116 утвержденный поставщик направляет цепочечную расценку, и инициируются стандартные уведомления о решениях. Стандартные уведомления о решениях включают в себя, например, так называемые уведомления на онлайновой доске объявлений, а также уведомления по электронной почте. После шага 116 выполняется шаг 118. На шаге 118 получающая ОСП оформляет соответствующие соглашения с покупателем для получения доступа к цепочечной расценке. После оформления соответствующих соглашений с покупателем на шаге 118 выполняется шаг 120. На шаге 120 ОСП заполняет соответствующие пункты расценки. На шаге 122 ОСП пересылает заполненную цепочечную расценку поставщику.
На шаге 124 утвержденный поставщик обращается к цепочечной расценке ОСП. После шага 124 может выполняться либо шаг 126, либо шаг 128. Если на шаге 124 утвержденный поставщик решает использовать необязательное средство анализа расценки, то выполнение переходит к шагу 126. Однако если утвержденный поставщик не хочет использовать средство анализа расценки, то выполнение переходит непосредственно к шагу 128. На шаге 126 утвержденный поставщик может задействовать необязательные средства анализа расценки. Средства анализа расценок позволяют осуществить сортировку и оценку для цепочечной расценки. На шаге 128 утвержденный поставщик может принять или отклонить цепочечную расценку ОСП. Если утвержденный поставщик принимает цепочечную расценку ОСП, то выполнение переходит к шагу 130.
На шаге 130 утвержденный поставщик выбирает пункты ответа по цепочечной расценке. Например, утвержденный поставщик может выбрать все или часть из пунктов ответа по цепочечной расценке, полученной от ОСП, в случае, когда определенные пункты ответа приемлемы для утвержденного поставщика, а другие - неприемлемы. Выбранные пункты ответа должны включать в себя как минимум один пункт услуг/товаров, подлежащий расписке. После выбора требуемых пунктов ответа по цепочечной расценке исполнение переходит к шагу 132. На шаге 132 определяется, осуществлены ли все необходимые подтверждения. Например, подтверждение не проходит, если утвержденный поставщик попытался выбрать несколько пунктов ответа на заявку для одного и того же пункта заявки. Если не определено, что все необходимые подтверждения осуществлены, то исполнение возвращается к шагу 130. Однако если определено, что все необходимые подтверждения осуществлены, то исполнение переходит от шага 132 к шагу 134.
На шаге 134 ответ поставщика на заявку обновляется при помощи величин из цепочечной расценки, подтвержденных на шаге 132. На шаге 136 осуществляются соответствующие изменения статуса цепочечной расценки ОСП и ответа поставщика на заявку. Например, после того, как выбранные пункты ответа по цепочечной расценке приняты поставщиком, статус указанных пунктов может измениться с отложенного на принятый. На шаге 138 выдаются стандартные уведомления для ОСП. На шаге 140 утвержденный поставщик может при желании редактировать ценообразование ОСП, чтобы отразить применимые надбавки поставщика. В различных вариантах осуществления изобретения редактирование ценообразования ОСП утвержденным поставщиком не должно снижать цены, установленные ОСП, и должно соответствовать сконфигурированным допустимым процентным надбавкам, которые установил покупатель. После шага 140 выполняется шаг 142. На шаге 142 утвержденный поставщик представляет покупателю ответ на заявку.
На шаге 144 покупатель принимает ответ на заявку. На шаге 146 утвержденный покупатель может при желании получить доступ через интерфейс пользователя ко всем подробностям ответа аффилированной ОСП на заявку. На шаге 148 покупатель обрабатывает ответы на заявку. На шаге 150 покупатель передает заявку на подряд поставщику(ам). После шага 150 исполняется шаг 152. На шаге 152 покупатель составляет требование на закупку. На шаге 154 покупатель подает поставщику указанное требование для его принятия и оценки налогообложения. На шаге 156 поставщик подает проанализированное требование соответствующим ОСП для принятия и налоговой оценки соответствующих элементов требования. На шаге 158 соответствующие ОСП выполняют транзакцию с требованием и возвращают заполненное требование поставщику.
После шага 158 исполняется шаг 160. На шаге 160 поставщик агрегирует все представленные ОСП пересмотренные требования. На шаге 162 поставщик представляет покупателю принятое требование с оценкой налогообложения. На шаге 164 покупатель обрабатывает требование на закупку. Обработка покупателем требования на закупку на шаге 164 происходит в соответствии с конфигурациями программы, которые могут варьироваться в соответствии с товарами и/или услугами, в зависимости от проекта. На шаге 166 предоставляется окончательное утверждение покупателем, и инициируется процедура обработки заказа на поставку.
После шага 166 начинает исполняться шаг 168. На шаге 168 определяется, является ли текущая программа оплачиваемой для ОСП. Программа, оплачиваемая для ОСП, определяется как программа, по которой покупатель может предоставлять финансовые средства непосредственно ОСП. Если это так, то исполняется шаг 176, в противном случае исполняется шаг 170. На шаге 176 заказы на поставку размещаются у поставщика, статьи заказа на поставку анализируются для сегментирования деталей ОСП, инициируются сконфигурированные уведомления, и задействуется система расписок. После шага 176 исполняется шаг 178. На шаге 178 начинается работа по проекту, и ОСП составляет расписку после доставки товаров/услуг. На шаге 180 расписка ОСП передается поставщику.
На шаге 170 заказ на поставку размещается только у поставщика, инициируются сконфигурированные уведомления, и включается система расписок. После шага 170 исполняется шаг 172. На шаге 172 начинается работа по проекту, и поставщик составляет расписку в ответ на доставку товаров/услуг.
Как после шага 172, так и после шага 180 исполняется шаг 174. На шаге 174 расписка поставщика передается сконфигурированному анализатору покупателя. После шага 174 исполнение переходит к шагу 182. На шаге 182 расписка на товары/услуги, предоставленная на шаге 174, обрабатывается покупателем. Например, различные процедуры обработки и утверждения могут быть осуществлены так, как желает покупатель. Система поддержки решений может использоваться, например, для агрегирования различных данных, относящихся к жизненному циклу работ по проекту, в целях оценки основных поставщиков и ОСП в отношении товаров/услуг, предоставленных непосредственно основным поставщиком или ОСП в отношении товаров/услуг, на которые у данных организаций имеется субподряд. На шаге 184 расписка утверждается покупателем.
После шага 184 выполняется шаг 186. На шаге 186 сконфигурированная командная стандартная подпрограмма извлекает детали утвержденной расписки. На шаге 188 передается файл счета-фактуры покупателя. На шаге 190 покупатель оплачивает счет-фактуру. На шаге 192 оплачивается работа поставщика (поставщиков) услуг. На шаге 194 используется система поддержки решений.
Наделение ОСП полномочиями связано с тем, как ОСП получают доступ к системе и в последующем используются покупателями и основными поставщиками. Наделение ОСП полномочиями в соответствии с различными вариантами осуществления изобретения позволяет улучшить контроль покупателя над использованием, обеспечивает управление риском, прозрачность коммерческих процессов/возможности аудита и информированность о товаре. В вариантах осуществления изобретения структурированный метод управления товарами в отношении использования ОСП может, когда он задействован, сделать покупателя лицом, контролирующим использование ОСП, в противоположность цепочке контроля основного поставщика. На Фиг.2A-B приведены примеры элементов конфигурации, управляющих использованием и оценкой ОСП.
Элементы 200 конфигурации включают в себя конфигурации 202 товарного разрешения для проекта, конфигурации 204 организационного разрешения, конфигурации 206 товарного разрешения на дополнение персонала, конфигурации 208 разрешения на шаблон, конфигурации 210 географического разрешения и конфигурации 212 разрешения на статус основного поставщика.
Конфигурации 202 разрешения для проекта включают в себя, например, конфигурации, связанные с сектором и серией проекта, и могут быть установлены согласно SIC, NAICS или иной структуре товаров, требуемой для покупателя. Конфигурации 204 организационного разрешения, например, разрешают покупателю определить, могут ли ОСП использоваться основным поставщиком, ведущим дела с покупателем, в зависимости от отдела, коммерческого подразделения, расчетного центра и пр. покупателя, с которым основной поставщик ведет дела. Конфигурация 206 товарного разрешения на дополнение персонала допускает установку конфигураций покупателем согласно, например, набору навыков отдельных лиц, привлекаемых к работе по проекту, к примеру, покупатель может сконфигурировать конторские услуги как услуги субподрядчика, а инженерные услуги - как не предоставляемые субподрядчиком. Конфигурации 208 разрешения на шаблон разрешают применять в шаблонах заявок конфигурации, подобные тем, что описаны в связи с другими конфигурациями Фиг.2A, и могут быть, например, установлены в соответствии с типом заявки. Конфигурации 210 географического разрешения позволяют настроить конфигурации, например, в соответствии со страной, регионом или городом. Конфигурации 212 разрешения на статус основного поставщика позволяют покупателю установить различные статусы основных поставщиков и разрешать или отклонять участие заявки на подряд в соответствии с указанными статусами. Например, покупатель может установить, что только покупатели первого класса могут использовать субподрядчиков при сделках с данным покупателем или что основной поставщик, имеющий статус не соблюдающего контракт, не может подавать заявку на подряд или иначе участвовать в системе, пока его статус не изменился на статус соблюдения.
Фиг.2B иллюстрирует типичные элементы конфигурации, управляющие требованиями к бизнесу ОСП. В элементах 250 конфигурации показаны квалификационные требования 252 по страхованию бизнеса ОСП и требования 254 к информации о бизнесе ОСП. Требования 252 и 254 могут совпадать с требованиями к основному поставщику, установленными покупателем, или отличаться от указанных требований. Например, требования 252 и 254 могут быть либо менее строгими, либо более строгими, чем требования к основному поставщику, которые желает предъявлять покупатель.
Фиг.3A-E иллюстрируют техническую модель/схему базы данных, которая может использоваться в связи с элементами конфигурации, проиллюстрированными на Фиг.2A. В частности, Фиг.2A и Фиг.3A-E иллюстрируют типичные переменные, которые могут быть сконфигурированы покупателем для настройки конфигурации, наиболее подходящей для бизнеса покупателя. Типичные переменные, показанные на Фиг.2A и 3A-E, отражают широкий ассортимент переменных, относящихся к ключевым элементам конфигурации, таким как, например, география организации покупателя, класс товара, тип шаблона заявки и статус основного поставщика. Конфигурация классификатора ОСП может считаться аналогичной конфигурации основного поставщика, как описано в Патентных заявках США № 10/262487 и 10/412096, и может, по существу, представлять собой осуществление аналогичных функций на другом уровне бизнеса. Фиг.3A-E приведены в концентрированной форме, для иллюстрации подробностей, относящихся к ОСП.
Примеры структур данных для использования в конфигурации ОСП приведены в Таблицах 113-118. Структуры данных для простоты показаны как организованные в формате таблицы, причем каждая таблица содержит все поля, необходимые для конфигурации ОСП. Таблицы взаимосвязаны иерархическим и/или реляционным способом так, что может обеспечивать точное хранение и доступ по всей необходимой информации для конфигурации ОСП, как более подробно описано ниже в связи с Фиг.3A-3E. Однако следует понимать, что могут быть включены другие конфигурации и что данная система не ограничена конкретными конфигурациями, перечисленными в Таблицах 113-118 или на Фиг.3A-3E.
| ТАБЛИЦА 113 | ||
| tblSCECommodityConfig (Товарные конфигурации ОСП) (представление структуры базы данных) |
||
| Название столбца | Тип данных | Длина |
| ProjectFamilyID (Идентификатор серии проекта) | Int (целое число) | 4 |
| SCEPermitted (Разрешенная ОСП) | Сhar (символьный) | 1 |
| RecordID (Идентификатор записи) | Int (целое число) | 4 |
| ТАБЛИЦА 114 | ||
| tblSCEGeoConfig (Географические конфигурации ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| RegionID (Идентификатор региона) | Int (целое число) | 4 |
| CityID (Идентификатор города) | Int (целое число) | 4 |
| LocationID (Идентификатор местоположения) | Int (целое число) | 4 |
| SCEPermitted (Разрешенная ОСП) | Сhar (символьный) | 1 |
| RecordID (Идентификатор записи) | Int (целое число) | 4 |
| ТАБЛИЦА 115 | ||
| tblSCEBUConfig (Конфигурации ОСП по коммерческим подразделениям) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| BUCode (Код коммерческого подразделения) | varсhar (символьная переменная) | 50 |
| SCEPermitted (Разрешенная ОСП) | сhar (символьный) | 1 |
| RecordID (Идентификатор записи) | int (целое число) | 4 |
| ТАБЛИЦА 116 | ||
| tblSCECCConfig (Конфигурации ОСП по расчетным центрам) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| [Dept/Cost_Center] (Отдел/Расчетный центр) | varсhar (символьная переменная) | 50 |
| SCEPermitted (Разрешенная ОСП) | char (символьный) | 1 |
| RecordID (Идентификатор записи) | int (целое число) | 4 |
| ТАБЛИЦА 117 | ||
| tblSCECCConfig (Конфигурации ОСП по шаблону) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| RFX_Template_ID (Идентификатор шаблона RFx) | Int (целое число) | 4 |
| SCEPermitted (Разрешенная ОСП) | Char (символьный) | 1 |
| RecordID (Идентификатор записи) | Int (целое число) | 4 |
| ТАБЛИЦА 118 | ||
| TblSCETierConfig (Конфигурации ОСП по уровню) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| TierCode (Код уровня) | Int (целое число) | 4 |
| SCEPermitted (Разрешенная ОСП) | Сhar (символьный) | 1 |
| RecordID (Идентификатор записи) | Int (целое число) | 4 |
Таблицы 113-118 иллюстрируют образцы конфигураций ОСП, которые могут храниться в таблицах базы данных. Товарные конфигурации ОСП, показанные в Таблице 113, могут храниться в таблице 304 товарных конфигураций ОСП, географические конфигурации ОСП, показанные в Таблице 114, могут храниться в таблице 310 географических конфигураций ОСП, конфигурации ОСП по коммерческим подразделениям, показанные в Таблице 115, могут храниться в таблице 324 конфигураций ОСП по коммерческим подразделениям, конфигурации ОСП по расчетным центрам, показанные в Таблице 116, могут храниться в таблице 320 конфигураций ОСП по расчетным центрам, конфигурации ОСП по шаблону, показанные в Таблице 117, могут храниться в таблице 328 конфигурации ОСП по шаблону, а конфигурации ОСП по уровню, показанные в Таблице 118, могут храниться в таблице 332 конфигураций ОСП по уровню.
На Фиг.3A схема базы данных для управления конфигурациями ОСП по стоимости и роду деятельности содержит таблицу 302 серии проекта, таблицу 304 товарных конфигураций ОСП, таблицу 306 рода деятельности и таблицу 308 товарных конфигураций ОСП. Взаимосвязь между таблицей 302 серии проекта и таблицей 304 товарных конфигураций ОСП показана на Фиг.3A. Таблица 302 включает в себя столбцы для идентификатора (ID) серии проекта, названия серии проекта, порядка сортировки и ID сектора проекта для каждой серии проекта из таблицы 302 серии проекта. Таблица 304 включает в себя ID товарной записи, дату деактивации, дату утверждения, ID утвержденного пользователя, ID типа утвержденного пользователя, ID текущего статуса, максимальный процент надбавки для основного поставщика, предел надбавки для основного поставщика, поле разрешенной ОСП и ID серии проекта, использованный в таблице 302. Таким образом, таблицы 302 и 304 взаимосвязаны через ID серии проекта.
Таблица 306 рода деятельности включает в себя ID рода деятельности, место деятельности, название рода деятельности, видимый признак и ID сортировки. Таблица 308 товарных конфигураций ОСП аналогична таблице 304 товарных конфигураций ОСП, причем таблицы 306 и 308 связаны через ID рода деятельности.
На Фиг.3B проиллюстрированы географические конфигурации ОСП. Таблица 310 географических конфигураций содержит столбцы для ID страны, ID региона, ID города, ID местоположения, разрешенной ОСП и ID записи. Каждая из следующих таблиц: таблица страны 312, таблица географического региона 314, географическая таблица городов 316 и таблица географического местоположения 381, находится во взаимосвязи с таблицей 310 географических конфигураций, как указано на Фиг.3B.
На Фиг.3C проиллюстрированы конфигурации ОСП по коммерческим подразделениям и расчетным центрам. Таблица 320 конфигураций ОСП по расчетным центрам и таблица 324 конфигураций по коммерческим подразделениям связаны, соответственно, с таблицей 322 расчетного центра и с таблицей 326 расчетного центра. На Фиг.3D показаны конфигурации шаблона ОСП. Таблица 328 конфигурации шаблона ОСП связана с таблицей 330 шаблона заявки RFx. Таблицы 328 и 330 позволяют связать конфигурации шаблона ОСП с шаблонами RFx, как описано выше. Фиг.3E содержит таблицу 332 конфигурации кода уровня ОСП и таблицу 334 шаблона заявки RFx. Таблицы 332 и 334 позволяют связать код уровня, присвоенный данной ОСП, с конкретным шаблоном заявки RFx.
Фиг.4 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с иллюстративными элементами конфигурации, представленными на Фиг.2B. Обе Фиг.2B и 4 иллюстрируют заданные покупателем спецификаторы основного поставщика для ОСП. Спецификаторы основного поставщика для ОСП - это заданные покупателем правила страхования и общих требований к бизнесу, которые должна выполнять ОСП. На Фиг.4 приведено сконцентрированное предоставление подробностей относительно ОСП. Оценка основного поставщика подробно описана в Патентной заявке США № 10/412,096. Специалистам в данной области техники должно быть понятно, что процедура, аналогичная описанной в Патентной заявке № 10/412,096, может быть применена для оценки бизнеса ОСП, и что могут быть установлены различные требования для каждого из основных поставщиков и для ОСП.
Примеры структур данных для оценки основного поставщика применительно к ОСП показаны в Таблицах 120-125. Структуры данных для простоты проиллюстрированы как организованные в формате таблицы, причем каждая таблица включает все необходимые поля для оценки ОСП основным поставщиком. Таблицы 120-125 связаны иерархическим и/или реляционным образом, таким образом, что обеспечивается точное хранение и доступ по всей необходимой информации, как описано ниже в связи с Фиг.4. Однако следует понимать, что могут быть включены другие поля спецификатора основного поставщика для ОСП, и что настоящая система не ограничена полями, перечисленными в Таблицах 120-125 или на Фиг.4.
| ТАБЛИЦА 120 | ||
| lkpInsuranceType (Тип страхования) (представление структуры базы данных) | ||
| InsuranceTypeID (ID Типа страхования) |
Описание | CoverageTypeAllowed (Допустимый тип страхового покрытия) |
| 1 | Гражданская ответственность | 1 |
| 2 | Ошибки, случаи бездействия | 0 |
| 3 | Автомобиль | 0 |
| 4 | Мошенничество | 0 |
| 5 | Компенсации работникам | 0 |
| 6 | Пожар | 1 |
| 7 | Кража | 1 |
| 8 | Морское страхование | 1 |
| ТАБЛИЦА 121 | ||
|
lkpInsuranceType (Тип страхования)
(представление структуры базы данных) |
||
| Название столбца | Тип данных | Длина |
| InsuranceCoverageTypeID (ID типа страхового покрытия) | int (целое число) | 4 |
| InsuranceCoverageType (Тип страхового покрытия) | varchar (символьная переменная) | 50 |
| InsuranceTypeID (ID типа страхования) | int (целое число) | 4 |
| ТАБЛИЦА 122 | ||
|
lkpInsuranceType (Тип страхования)
(представление структуры базы данных) |
||
| Название столбца | Тип данных | Длина |
| InsuranceTypeID (ID типа страхования) | int (целое число) | 4 |
| InsuranceCoverageTypeID (ID типа страхового покрытия) | int (целое число) | 4 |
| SCERequired (Требуемое ОСП) | сhar (символьный) | 1 |
| SCERequired$Amount ( сумма в $, требуемая ОСП) | money (денежный) | 8 |
| CurrentStatusID (ID текущего статуса) | int (целое число) | 4 |
| ApprovedUserTypeID (ID типа утвержденного пользователя) | int (целое число) | 4 |
| ApprovedUserID (ID утвержденного пользователя) | int (целое число) | 4 |
| ApprovalDate (Дата утверждения) | datetime (дата, время) | 8 |
| DeactivationDate (Дата деактивации) | datetime (дата, время) | 8 |
| RecordID (ID записи) | int (целое число) | 4 |
| ТАБЛИЦА 123 | ||
| tblSCEQualifiersBusiness (Классификаторы бизнеса ОСП) (табличное представление) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| Contracted (Контрактный) | char (символьный) | 1 |
| vBusinessEntityTypeID (ID типа предприятия) | sql_varianl | |
| vFedIdentity (Фед. идентификатор) | char (символьный) | 1 |
| vIncorporationCountryID (ID страны регистрации) | int (целое число) | 4 |
| vMinimumYearsInBusiness (Минимальный срок в бизнесе в годах) | numeric (численный) | 9 |
| vDBECertification (Сертификация DBE) | char (символьный) | 1 |
| vSmallBusinessDesignationID (ID обозначения малого предприятия) | char (символьный) | 1 |
| vISOCertified (Сертифицирован в ISO) | char (символьный) | 1 |
| vMinimumNetFinancialWorth (Минимальная чистая финансовая стоимость) | money (денежный) | 8 |
| vUses_FT_W2_employees (Использует FT W2 сотрудников) | char (символьный) | 1 |
| vStaffSupplementation (Добавление персонала) | char (символьный) | 1 |
| vProjectSupplementation (Дополнение проекта) | char (символьный) | 1 |
| vEDICabable (Возможность EDI) | char (символьный) | 1 |
| vEFTCabable (Возможность EFT) | char (символьный) | 1 |
| CurrentStatusID (ID текущего статуса) | int (целое число) | 4 |
| ApprovedUserTypeID (ID типа утвержденного пользователя) | int (целое число) | 4 |
| ApprovedUserID (ID утвержденного пользователя) | int (целое число) | 4 |
| ApprovalDate (Дата утверждения) | datetime (дата, время) | 8 |
| DeactivationDate (Дата деактивации) | datetime (дата, время) | 8 |
| RecordID (ID записи) | int (целое число) | 4 |
| ТАБЛИЦА 124 | |
| tblSCEQualifiersBusiness (Классификаторы бизнеса ОСП) (примеры значений) (представление структуры базы данных) | |
| Название столбца | Значение |
| Contracted (Контрактный) | Y (Да) |
| vBusinessEntityTypeID (ID типа предприятия) | 1,2,4,7,10 |
| vFedIdentity (Фед. идентификатор) | Y (Да) |
| vIncorporationCountryID (ID страны регистрации) | 213 |
| vMinimumYearsInBusiness (Минимальный срок в бизнесе в годах) | 3 |
| vDBECertification (Сертификация DBE) | Y (Да) |
| vSmallBusinessDesignationID (ID обозначения малого предприятия) | N (Нет) |
| vISOCertified (Сертифицирован в ISO) | N (Нет) |
| vMinimumNetFinancialWorth (Минимальная чистая финансовая стоимость) | $1 000 000,00 |
| vUses_FT_W2_employees (Использует FT W2 сотрудников) | Y (Да) |
| vStaffSupplementation (Добавление персонала) | N (Нет) |
| vProjectSupplementation (Дополнение проекта) | Y (Да) |
| vEDICabable (Возможность EDI) | Y (Да) |
| vEFTCabable (Возможность EFT) | Y (Да) |
| CurrentStatusID (ID текущего статуса) | 1 |
| ApprovedUserTypeID (ID типа утвержденного пользователя) | 1 |
| ApprovedUserID (ID утвержденного пользователя) | 134 |
| ApprovalDate (Дата утверждения) | 3/9/2003 |
| DeactivationDate (Дата деактивации) | NULL (значение не определено) |
| RecordID (ID записи) | 1 |
| ТАБЛИЦА 125 | ||
| lkpProcessType (Тип процесса) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| id (идентификатор) | int (целое число) | 4 |
| DocType (Тип документа) | varchar (символьная переменная) | 20 |
| Description (Описание) | varchar (символьная переменная) | 250 |
| WaitingForApprovalStatusID (ID статуса ожидания утверждения) | int (целое число) | 4 |
| ApprovedStatusID (ID статуса утверждения) | int (целое число) | 4 |
| DeclinedStatusID (ID статуса отклонения) | int (целое число) | 4 |
| TableName (Наименование таблицы) | varchar (символьная переменная) | 128 |
| IdFieldName (Наименование поля идентификатора) | varchar (символьная переменная) | 128 |
| StatusFieldName (Наименование поля статуса) | varchar (символьная переменная) | 128 |
| ApprovalDateFieldName (Наименование поля даты утверждения) | varchar (символьная переменная) | 128 |
| DeclineDateFieldName (Наименование поля даты отклонения) | varchar (символьная переменная) | 128 |
| ProcessingMatrix (Матрица обработки) | char (символьный) | 1 |
| ApprovalSortPriority (Приоритет сортировки утверждения) | int (целое число) | 4 |
На Фиг.4 показаны таблица 402 классификаторов страхования ОСП, таблица 404 типа страхования, таблица 406 типа страхового покрытия, таблица 408 типа процесса, таблица 410 классификаторов бизнеса ОСП и таблица 412 текущего статуса. Таблицы 402-412 взаимосвязаны, как показано на Фиг.4. Таблица 120 иллюстрирует образцы данных, которые могут храниться в таблице 404 типа страхования. Таблица 121 иллюстрирует образцы данных, которые могут храниться в таблице 406. Таблица 122 иллюстрирует образцы данных, которые могут храниться в таблице 402. Таблица 124 иллюстрирует образцы данных, которые могут храниться в таблице 410. Таблица 124 перечисляет примеры значений классификаторов бизнеса ОСП, которые могут храниться в таблице 410. Таблица 125 перечисляет примеры значений, которые могут храниться в таблице 408.
Таблица 402 классификаторов страхования ОСП содержит различные данные относительно требований по страхованию, предъявляемых покупателем к ОСП. Таблица 404 типа страхования содержит разнообразную информацию относительно требуемого типа страхования для ОСП. Аналогичным образом таблица 406 типа страхового покрытия содержит различные данные относительно типа страхового покрытия, требуемого для ОСП.
На Фиг.5A-B показана типичная блок-схема высокого уровня, иллюстрирующая, как ОСП может быть наделена полномочиями и связана с основным поставщиком. В процессе наделения ОСП полномочиями конфигурации покупателя могут использоваться совместно с последовательностью работ, для управления контролируемым потоком нагрузки ОСП. В последовательности 500 нагрузки ОСП, показанной на Фиг.5A-B, различные участвующие организации могут получить возможность наблюдения сегментов применимых к ним процессов и владения ими.
Последовательность 500 начинается с шага 502. На шаге 502 квалифицированный поставщик активирует ссылку «Управление ОСП» с базовой страницы поставщика. На шаге 504 отображается список всех связанных с ним ОСП и их текущего статуса. На шаге 506 появляются функциональные опции в ответ на выбор конкретной ОСП. На шаге 508 представлены четыре типичные опции: 1) просмотр подробных сведений об ОСП; 2) просмотр деятельности ОСП; 3) деактивация ОСП и 4) добавление новой ОСП.
После шага 508, если выбрана опция 1), на шаге 510 отображаются выбранные основные данные для уполномоченных пользователей покупателя. В вариантах осуществления настоящего изобретения данные, отображаемые на шаге 510, предназначены только для чтения. Если на шаге 508 выбрана опция 2), то на шаге 512 отображаются выбранные данные с обзором отчетности о работе ОСП. В вариантах осуществления настоящего изобретения данные, отображаемые на шаге 512, предназначены только для чтения. Если на шаге 508 выбрана опция 3), то на шаге 514 отображаются выбранные данные по ОСП, с предупреждением о том, что ОСП не может использоваться после деактивации. Если на шаге 508 выбрана опция 4), то на шаге 516 отображается список утвержденных ОСП. После шага 514 исполнение переходит к шагу 520. На шаге 520 может быть выбрана деактивация ОСП или отмена деактивации ОСП.
От шага 520, если выбрана отмена деактивации ОСП, исполнение возвращается к шагу 508. Если выбрана деактивация ОСП, то исполнение переходит к шагу 522. На шаге 522 устанавливается, есть ли у ОСП, подлежащей деактивации, незавершенная деятельность. Если на шаге 522 установлено, что у ОСП, подлежащей деактивации, есть незавершенная деятельность, то исполнение переходит к шагу 524. На шаге 524 отображается сообщение для поставщика с указанием на то, что деактивация не может быть осуществлена, поскольку существует текущая деятельность для ОСП, подлежащей деактивации.
Если на шаге 522 не установлено, что у ОСП, подлежащей деактивации, есть текущая деятельность, то исполнение переходит к шагу 526. На шаге 526 поставщику предоставляется системное операционное сообщение о деактивации. От шага 526 исполнение переходит к шагу 528. На шаге 528 ОСП получает уведомление по электронной почте, и происходит обновление системы в отношении деактивации ОСП.
От шага 516 исполнение переходит к шагу 518. На шаге 518 определяется, отображается ли требуемая ОСП. Если на шаге 518 определено, что отображается требуемая ОСП, то исполнение переходит к шагу 530. На шаге 530 отображается список утвержденных ОСП. Специалистам в данной области техники, должно быть понятно, что факторы, связанные с бизнесом могут потребовать, чтобы полный список всех утвержденных ОСП не демонстрировался некоторым организациям, использующим данную систему.
На шаге 532 определяется, отображается ли требуемая ОСП. Если это определено, то исполнение переходит к шагу 534. Если на шаге 532 не определено, что отображается требуемая ОСП, то исполнение переходит к шагу 536. На шаге 534 поставщик выбирает ОСП (одну или несколько) и вводит выбор в систему. На шаге 538 поставщику предлагается подтвердить или отредактировать варианты выбора, которые он сделал на шаге 534. Если поставщик подтверждает выбор, сделанный на шаге 534, то исполнение переходит к шагу 540. Если поставщик редактирует выбор, то исполнение возвращается к шагу 530.
На шаге 540 отображается сообщение для поставщика о том, что ОСП (одна или несколько) будут уведомлены о запросе поставщика на активацию. На шаге 542 уведомление о запросе на активацию направляется ОСП по электронной почте, и система обновляется так, чтобы отображать запрос на активацию от основного поставщика для ОСП. Специалистам в данной области техники должно быть понятно, что активация отношения ОСП/поставщик не является односторонней обязанностью от поставщика к ОСП, но должна быть утверждена как ОСП, так и основным поставщиком. На шаге 544 ОСП получает доступ к системе. На шаге 546 ОСП может принять или отклонить запрос на аффилирование. Если на шаге 546 ОСП отклоняет запрос на аффилирование, то исполнение переходит к шагу 548. На шаге 548 поставщик получает уведомление об отклонении запроса на аффилирование со стороны ОСП.
Если на шаге 546 ОСП принимает запрос на аффилирование, то исполнение переходит к шагу 550. На шаге 550 поставщик уведомляется по электронной почте о принятии ОСП запроса, и система обновляется таким образом, чтобы отразить указанное принятие ОСП. На шаге 552 факт аффилирования сохраняется в прикладной базе данных, и отношение поставщик/ОСП обозначается как активное отношение. Хотя это не проиллюстрировано явно на Фиг.5A-5B, процесс аффилирования поставщика и ОСП может включать в себя установку ограничений на отношение ОСП/поставщик, аналогичных тем ограничениям, которые описаны выше для отношения основной поставщик/покупатель, включая, в частности, товарные или географические ограничения на товары и/или услуги, которые ОСП предоставляет основному поставщику.
Как отмечалось выше, если на шаге 532 не определено, что отображается требуемая ОСП, то исполняется шаг 536. На шаге 536 поставщику предоставляется экран для ввода, куда он вводит соответствующие контактные данные. После шага 536 исполняется шаг 554. На шаге 554 поставщик направляет запрос программному администратору и уведомляется об успешной передаче запроса. На шаге 556 программный администратор уведомляется по электронной почте о запросе на добавление ОСП, и система обновляется. На шаге 558 программный администратор создает запись ОСП и присваивает надлежащие полномочия для входа в систему. На шаге 560 ОСП уведомляется о входных полномочиях, предоставленных на шаге 558. На шаге 562 ОСП получает доступ к системе с входными полномочиями, созданными на шаге 558.
На шаге 564 ОСП предоставляется экран ввода информации для поставщика. На шаге 566 ОСП заполняет форму ввода информации и подает ее в систему. На шаге 568 программный администратор уведомляется по электронной почте о подаче формы от ОСП, и система обновляется. После шага 568 выполняется шаг 570. На шаге 570 определяется решение о том, утвердил ли администратор форму ввода информации. Если на шаге 570 определено, что администратор утвердил форму ввода информации, то исполнение переходит к шагу 574. На шаге 574 происходит активизация ОСП в системе, и предоставляются стандартные уведомления ОСП и основному поставщику относительно активизации ОСП. После шага 574 исполнение возвращается к шагу 532, на указанном шаге в данный момент отображается требуемая ОСП, и может начаться процесс аффилирования ОСП. Если на шаге 570 администратор не утвердил форму ввода информации, то исполнение переходит к шагу 572. На шаге 572 поставщик и ОСП уведомляются об отклонении утверждения ОСП.
Поскольку по определению ОСП не получают непосредственной просьбы об ответе на заявки на подряд, то коммерческие отношения между покупателем и ОСП могут создаваться только посредством аффилирования с основным поставщиком. В различных вариантах осуществления настоящего изобретения никакие отношения не могут быть созданы без согласия всех сторон.
Примеры структур данных для использования при наделении ОСП полномочиями и в ассоциации с основным поставщиком приведены в Таблицах 126-129. Указанные структуры данных для простоты проиллюстрированы как организованные в формате таблицы, причем каждая таблица содержит все поля, необходимые для наделения ОСП полномочиями и ассоциирования с основным поставщиком. Таблицы взаимосвязаны иерархическим и/или реляционным образом так, что отслеживается точное хранение и доступ ко всей информации, необходимой для наделения ОСП полномочиями и ассоциирования с основным поставщиком, как более подробно описано ниже в связи с Фиг.6. Однако следует понимать, что могут быть включены другие конфигурации и что данная система не ограничена конкретными конфигурациями, перечисленными в Таблицах 113-118 или на Фиг.6.
| ТАБЛИЦА 126 | ||
| tblSCESetupRequest (Запрос на установку ОСП) (представление структуры базы данных) | ||
| Столбец | Тип данных | Длина |
| PSVendorID (ID основного поставщика как продавца) | int (целое число) | 4 |
| UserID (ID пользователя) | int (целое число) | 4 |
| RequestDate (Дата запроса) | datetime (дата, время) | 8 |
| SCECandidateName (Название кандидата в ОСП) | varchar (символьная переменная) | 100 |
| SCECandidateContactFN (Имя контактного лица кандидата в ОСП) | varchar (символьная переменная) | 50 |
| SCECandidateContactLN (Фамилия контактного лица кандидата в ОСП) | varchar (символьная переменная) | 50 |
| SCECandidateContactTitle (Должность контактного лица кандидата в ОСП) | varchar (символьная переменная) | 50 |
| SCECandidateContactPhone (Телефон контактного лица кандидата в ОСП) | varchar (символьная переменная) | 50 |
| SCECandidateContactEmail (Электронный адрес контактного лица кандидата в ОСП) | varchar (символьная переменная) | 50 |
| SCEApprovalStatus (Статус утверждения ОСП) | int (целое число) | 4 |
| RecordID (ID записи) | int (целое число) | 4 |
| ТАБЛИЦА 127 | ||
| tblSCEAffiliationRequest (Запрос на аффилирование ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| PSVendorID (ID основного поставщика как продавца) | int (целое число) | 4 |
| PSVendorContactID (ID контактного лица основного поставщика как продавца) | int (целое число) | 4 |
| RequestDate (Дата запроса) | datetime (дата, время) | 8 |
| SCECandidateVendorID (ID кандидата в ОСП как продавца) | int (целое число) | 4 |
| SCEApprovalStatus (Статус утверждения ОСП) | int (целое число) | 4 |
| UserTypeReviewerID (ID анализатора типа пользователя) | int (целое число) | 4 |
| ReviewerUserID (ID анализатора пользователя) | int (целое число) | 4 |
| ReviewerDispositionDate (Дата распоряжения анализатора) | datetime (дата, время) | 8 |
| SCEStatusDispositionCode (Код распоряжения о статусе ОСП) | int (целое число) | 4 |
| RecordID (ID записи) | int (целое число) | 4 |
| ТАБЛИЦА 128 | ||
| lkpSCERequestStatusDisposition (Распоряжение статусом запроса ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEStatusDispositionCode (Код распоряжения о статусе ОСП) | int (целое число) | 4 |
| SCEStatusDispositionDesc (Описание распоряжения о статусе ОСП) | varchar (символьная переменная) | 25 |
| ТАБЛИЦА 129 | ||
| tblSCEMapPrimarySupplier (Соответствие ОСП и основного поставщика) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEVendorID (ID ОСП как продавца) | int (целое число) | 4 |
| PrimarySupplierID (ID основного поставщика) | int (целое число) | 4 |
| CurrentStatusID (ID текущего статуса) | int (целое число) | 4 |
| SCEMapRecord (Запись о соответствии ОСП) | int (целое число) | 4 |
В таблицах 126-129 приведены примеры уполномочивающих данных для ОСП, которые могут храниться в таблицах базы данных. Уполномочивающие данные для ОСП, показанные в Таблице 126, могут храниться в Таблице 608 запроса на установку ОСП. Уполномочивающие данные для ОСП из Таблицы 127 могут храниться в Таблице 604 запроса аффилирования ОСП. Уполномочивающие данные для ОСП из Таблицы 128 могут храниться в Таблице 612 распоряжения статусом запроса. Уполномочивающие данные для ОСП из Таблицы 128 могут храниться в Таблице 610 соответствия ОСП и основного поставщика.
Фиг.6 представляет техническую модель/схему базы данных, которая может использоваться в связи с типичной уполномочивающей процедурой для ОСП, определенной на Фиг.5A-B. На Фиг.6 схема базы данных для наделения ОСП полномочиями содержит главную Таблицу 602 основного поставщика, Таблицу 604 запроса аффилирования ОСП, Таблицу 606 контактов с основным поставщиком, Таблицу 608 запроса на установку ОСП, Таблицу 610 соответствия ОСП и основного поставщика, Таблицу 612 распоряжения статусом запроса и Таблицу 614 текущего статуса ОСП. Взаимоотношения между различными Таблицами 602-614 таковы, как показано на Фиг.6.
Фиг.7 является типичной блок-схемой, показывающей, как основной поставщик может отбирать ОСП и включать их в покупательский запрос на заявку. Последовательность 700 начинается с шага 702, на котором квалифицированный поставщик получает отправленные консолидированные RFx покупателя. Требуемая заранее процедура составления покупателем отправляемых консолидированных заявок RFx более подробно описана в Патентной заявке США № 10/262,487.
На шаге 704 определяется, желает ли основной поставщик пригласить связанную с ним ОСП (или несколько ОСП) в процедуру ответа на заявку. Если определено, что поставщик желает пригласить связанные с ним ОСП в процедуру ответа на заявку, то выполняется шаг 706. На шаге 706 поставщик активирует функцию расценок ОСП. Если на шаге 704 не определено, что поставщик желает пригласить связанные с ним ОСП в процедуру ответа на заявку, то выполняется шаг 705, на котором процедура заканчивается.
После шага 706 выполняется шаг 708, на котором система отображает список аффилированных ОСП поставщика, которые соответствуют квалификационным критериям покупателя. На шаге 710 определяется, есть ли в списке хоть одна ОСП. Если на шаге 710 определено, что это так, то на шаге 712 поставщику предлагается выбрать желательную ОСП. Если на шаге 710 не определено, что в списке есть хоть одна ОСП, то исполняется шаг 714. На шаге 714 поставщику предоставляется сообщение с указанием о том, что функции последовательности 700 могут выполняться, только если аффилирования ОСП активны и ОСП соответствует квалификационным критериям покупателя.
От шага 712, после выбора поставщиком требуемой ОСП, исполнение переходит к шагу 716. На шаге 716 поставщику предоставляется список пунктов заявки RFx, требующих ответа поставщика. На шаге 718 поставщику предлагается выбрать желательные пункты для расценки ОСП. От шага 718 исполнение переходит к шагу 720, в ответ на выбор поставщиком желательных пунктов. На шаге 720 отображается список выбранных поставщиком пунктов расценки ОСП. На шаге 722 определяется, необходимо ли редактирование выбранных пунктов заявки. Если на шаге 722 определено, что это необходимо, то исполнение возвращается к шагу 718. Если на шаге 722 это не определено, то исполнение переходит к шагу 724.
На шаге 724 определяется, требуется ли редактирование (нескольких) ОСП. Если на шаге 724 определено, что это требуется, то активируется функция редактирования ОСП, и исполнение переходит к шагу 726. Если на шаге 724 не определяется решение о том, что поставщик желает добавить дополнительные ОСП к списку рассылки, то активируется функция рассылки, и исполнение переходит к шагу 728.
На шаге 726 отображается список других ОСП, которые не были ранее выбраны поставщиком. На шаге 732 определяется, находится ли в списке хотя бы одна ОСП. При положительном решении исполнение переходит к шагу 734. На шаге 734 поставщику предлагается выбрать желательную(ые) ОСП. От шага 734, в ответ на выбор, сделанный поставщиком, исполнение возвращается к шагу 724. Если на шаге 732 не определено, что в списке находится хотя бы одна ОСП, то исполнение переходит к шагу 736, на котором поставщику предлагается отправить запись в адрес ОСП. После шага 736 активируется функция отправки, и исполнение переходит к шагу 728.
Как отмечено выше, исполнение переходит от шага 724 к шагу 728, если не определено, что поставщик желает редактировать ОСП, входящие в список рассылки. На шаге 728 поставщик отправляет расценки ОСП, и профиль расценок ОСП сохраняется в базе данных. После шага 728 исполнение переходит к шагу 730. На шаге 730 система отображает регистрацию передачи данных. После шага 730 исполнение возвращается к шагу 702.
Хотя это не изображено явно на Фиг.7, основной поставщик может создавать стандартные профили расценок ОСП, которые систематически приводят ОСП в соответствие с конкретными элементами ответа на заявку. Например, основной поставщик может сконфигурировать конечную группу ОСП для услуг по проектированию с участием человеческого капитала, так, что каждый раз, когда основной поставщик получает заявку, в которой требуется данный конкретный элемент ответа на заявку, система автоматически генерирует конкретный профиль расценок ОСП для конфигурируемой ОСП (или нескольких ОСП). Основному поставщику может быть предоставлена возможность создавать различные профили расценок ОСП, включающие в себя сочетание как пунктов заявки, так и выбранных ОСП.
Фиг.7 указывает, что пункты профиля расценок ОСП ограничены пунктами, содержащимися в Заявке RFx покупателя. Однако в некоторых вариантах осуществления изобретения профиль расценок ОСП может быть расширен так, чтобы включать в себя динамические пункты, созданные основным поставщиком. Процесс отправки расценок ОСП, описанный в отношении Фиг.7, аналогичен процессу отправки заявки RFx покупателем основному поставщику, как раскрыто в Патентной заявке США № 10/262,487.
Примеры структур данных для использования при отборе ОСП и их включении в запрос покупателя на заявку показаны в Таблицах 130-132. Указанные структуры данных для простоты проиллюстрированы как организованные в формате таблиц, причем каждая таблица включает в себя все поля, необходимые для отбора ОСП и их включения в запрос покупателя на заявку. Таблицы взаимосвязаны иерархическим и/или реляционным образом, таким образом, что может обеспечиваться точное хранение и доступ ко всей информации, необходимой для отбора и включения ОСП. Однако следует понимать, что могут быть включены другие конфигурации и что система не ограничена конкретными конфигурациями, перечисленными в Таблицах 130-132.
| ТАБЛИЦА 130 | ||
| tblSCEQuoteProfiles (Профили расценки ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| vResponse_ID (ID ответа) | int (целое число) | 4 |
| vUserID (ID пользователя) | int (целое число) | 4 |
| CurrentStatus_ID (ID текущего статуса) | int (целое число) | 4 |
| DateCreated (Дата создания) | datetime (дата, время) | 8 |
| SCEProfileID (ID профиля ОСП) | int (целое число) | 4 |
| ТАБЛИЦА 131 | ||
| tblSCEQuoteProfilesPost (Отправка профилей расценки ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEProfileID (ID профиля ОСП) | int (целое число) | 4 |
| SCEPrimary supplierID (ID основного поставщика ОСП) | int (целое число) | 4 |
| Post_Date (Дата отправки) | datetime (дата, время) | 8 |
| PostingRecordID (ID записи об отправке) | int (целое число) | 4 |
| ТАБЛИЦА 132 | ||
| tblSCEQuoteProfilesItems (Пункты профилей расценки ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEProfileID (ID профиля ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| RecordID (ID записи) | int (целое число) | 4 |
Таблицы 130-132 являются типичными таблицами ОСП, используемыми в связи с последовательностью 700 на Фиг.7. Таблицы 130-132 используются для основного хранения пунктов заявки. Таблица 130 содержит столбцы для ID ответа, ID пользователя, ID текущего статуса, даты создания и ID профиля. Таблица 131 действует как запись об отправке, которая содержит ID основного поставщика, ID профиля, дату отправки и запись об отправке. Таблица 132 может использоваться для облегчения автоматической пересылки в случае, когда ответные расценки ОСП приемлемы для основного поставщика.
Фиг.8 является типичной блок-схемой, показывающей, как ОСП может обрабатывать цепочечную расценку, выпущенную первичным поставщиком. В различных вариантах осуществления изобретения ОСП могут получить функциональные возможности, аналогичные тем, что имеются у первичных поставщиков при обработке ответа на заявку, как описано в Патентной заявке США № 10/262487. Обработка расценок ОСП, показанная на Фиг.8, следует логике, аналогичной той, что использовалась для первичных поставщиков, как описано в Патентной заявке США № 10/262487. На Фиг.8 представление профиля расценок для ОСП ограничено пунктами, которые были выбраны первичными поставщиками; однако любой элемент заявки RFx может быть отображен для ОСП, если основной поставщик считает, что это имеет отношение к ответу ОСП.
На Фиг.8 последовательность 800 начинается с шага 802. На шаге 802 ОСП получает запрос поставщика на расценки через разрешенный системный доступ. На шаге 804 определяется, необходимо ли оформить соглашения с покупателем. Например, покупатель может потребовать, чтобы основной поставщик оформил соглашение о неразглашении, как условие перехода к процедуре заявки. Аналогичным образом основной поставщик, от которого требуется оформление соглашения о неразглашении, может потребовать от ОСП, аффилированных с первичным поставщиком и подлежащих процедуре цепочечной расценки, также оформить соглашение о неразглашении. Если на шаге 804 определено, что необходимо оформить указанные соглашения, то исполнение переходит к шагу 806. На шаге 806 определяется, оформила ли ОСП необходимые соглашения в требуемые сроки. Если на шаге 806 определено, что ОСП оформила необходимые соглашения в требуемые сроки, то исполнение переходит к шагу 810. На шаге 810 ОСП получает доступ к расценке. Если на шаге 804 не определено, что необходимо оформить соглашения с покупателем, то исполнение переходит к шагу 810. На шаге 808, если не определено, что ОСП оформила необходимые соглашения в требуемые сроки, ОСП исключается из процедуры расценки, и поставщик уведомляется о том, что ОСП не соблюдает условия выполнения соглашения.
От шага 810 исполнение переходит к шагу 812. На шаге 812 определяется, заполнила ли ОСП все требуемые элементы входных данных в установленные временные рамки. Если на шаге 812 определено, что ОСП заполнила все требуемые элементы входных данных в установленные сроки, то исполнение переходит к шагу 814. На шаге 814 расценка ОСП считается приемлемой для представления поставщику. На шаге 816 ОСП представляет поставщику расценку ОСП, и поставщик уведомляется посредством электронной почты и системного уведомления.
Если на шаге 812 не определено, что ОСП заполнила все требуемые элементы входных данных в установленные сроки, то исполнение переходит к шагу 818. На шаге 818 ОСП исключается из процесса предоставления расценок, и поставщик, выдавший запрос, уведомляется о несоблюдении сроков представления расценок.
Примеры структур данных для использования при обработке в ОСП цепочечных расценок, выпущенных основным поставщиком, приведены в Таблицах 133-142. Для простоты структуры данных проиллюстрированы как организованные в формате таблиц, причем каждая таблица содержит все поля, необходимые для обработки в ОСП цепочечных расценок, выпущенных основным поставщиком. Таблицы связаны иерархическим и/или реляционным образом так, что обеспечивается точное хранение и доступ для всей информации, необходимой для конфигурирования ОСП. Однако следует понимать, что могут быть включены другие конфигурации и что данная система не ограничена конкретными конфигурациями, перечисленными в Таблицах 133-142.
| ТАБЛИЦА 133 | ||
| tblSCEQuoteResp (Ответ на расценки ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEPostingRecordID (ID записи об отправке ОСП) | int (целое число) | 4 |
| SCEQuoteStatusID (ID статуса расценки ОСП) | int (целое число) | 4 |
| SCEQuoteCreateDate (Дата создания расценки ОСП) | datetime (дата, время) | 8 |
| SCEQuoteSubmitDate (Дата представления расценки ОСП) | datetime (дата, время) | 8 |
| SCEQuoteResponseID (ID ответа на расценку ОСП) | int (целое число) | 4 |
| ТАБЛИЦА 134 | ||
| tblSCEQuoteRespMain (Основная таблица ответной расценки ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseID (ID ответной расценки ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| Required_Item (Требуемый пункт) | char (символьный) | 1 |
| SCE_Response (Ответ ОСП) | varchar (символьная переменная) | 5000 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Save_Date (Дата последнего сохранения) | datetime (дата, время) | 8 |
| RFX_Section_id (идентификатор раздела RFx) | int (целое число) | 4 |
| RFX_Category_id (идентификатор категории RFx) | int (целое число) | 4 |
| RFX_Response_Complete (полный ответ RFx) | char (символьный) | 10 |
| RFX_Grade (Степень RFx) | char (символьный) | 1 |
| RFX_Points (Очки RFx) | int (целое число) | 4 |
| ТАБЛИЦА 135 | ||
| tblSCEQuoteRespMaterials (Таблица ответных расценок ОСП по материалам) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseMainID (ID основной ответной расценки ОСП) | int (целое число) | 4 |
| SCEProfileItemID (ID профильного пункта ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| Identity_Key (ключ идентификации) | int (целое число) | 4 |
| RFXRespMaterialRowID (ID строки материала в ответе на RFx) | int (целое число) | 4 |
| Material_Category (Категория материала) | varchar (символьная переменная) | 100 |
| Material_Name (Название материала) | varchar (символьная переменная) | 100 |
| Material_Description (Описание материала) | varchar (символьная переменная) | 1000 |
| Material_Manufacturer (Производитель материала) | varchar (символьная переменная) | 100 |
| Unit_Count (Количество единиц) | int (целое число) | 4 |
| Unit_Cost (Стоимость единицы) | money (денежный) | 8 |
| Line_Item_Cost (Стоимость пункта статьи) | money (денежный) | 8 |
| Client_Comments (Клиентские комментарии) | varchar (символьная переменная) | 1000 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_User_ Contact_ID (ID контактного пользователя ОСП) | int (целое число) | 4 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Edit_Date (Дата последнего редактирования) | datetime (дата, время) | 8 |
| SCEMatRecordID (ID записи ОСП по материалу) | int (целое число) | 4 |
| ТАБЛИЦА 136 | ||
| tblSCEQuoteRespDeliverables (Таблица ответных расценок ОСП по доставляемым материалам) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseMainID (основной ID ответной расценки ОСП) | int (целое число) | 4 |
| SCEProfileItemID (ID профильного пункта ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| Identity_Key (ключ идентификации) | int (целое число) | 4 |
| RFXRespDeliverableRowID (ID строки доставляемого материала в ответе на RFx) | int (целое число) | 4 |
| DeliverableName (Название доставляемого материала) | varchar (символьная переменная) | 50 |
| DeliverableDescription (Описание доставляемого материала) | varchar (символьная переменная) | 1000 |
| AnticipatedCompletionDate (Дата предполагаемого завершения) | datetime (дата, время) | 8 |
| BillableDeliverable (Доставляемый материал с выставлением счета) | char (символьный) | 1 |
| PaymentAmount (Сумма платежа) | money (денежный) | 8 |
| PartialPaymentAuthorized (Разрешен частичный платеж) | char (символьный) | 1 |
| Client_Comments (Клиентские комментарии) | varchar (символьная переменная) | 1000 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_User_ Contact_ID (ID контактного пользователя ОСП) | int (целое число) | 4 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Edit_Date (Дата последнего редактирования) | datetime (дата, время) | 8 |
| SCEDelRecordID (ID записи ОСП по доставляемому материалу) | int (целое число) | 4 |
| ТАБЛИЦА 137 | ||
| tblSCEQuoteRespUnits (Таблица ответных расценок ОСП по структурным единицам) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseMainID (основной ID ответной расценки ОСП) | int (целое число) | 4 |
| SCEProfileItemID (ID профильного пункта ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| Identity_Key (ключ идентификации) | int (целое число) | 4 |
| RFXRespUnitRowID (ID строки структурной единицы в ответе на RFx) | int (целое число) | 4 |
| UnitName (Название структурной единицы) | varchar (символьная переменная) | 50 |
| UnitCompletionDescription (Описание завершения структурной единицы) | varchar (символьная переменная) | 1000 |
| UnitCount (Количество единиц) | float (с плавающей запятой) | 8 |
| UnitCost (Стоимость единицы) | float (с плавающей запятой) | 8 |
| LineUnitCost (Стоимость единицы в статье) | float (с плавающей запятой) | 8 |
| UnitsAuthorised (Авторизованные единицы) | char (символьный) | 1 |
| BillableUnits (Единицы с выставлением счета) | char (символьный) | 1 |
| PartialPaymentAuthorized (Разрешен частичный платеж) | char (символьный) | 1 |
| Client_Comments (Клиентские комментарии) | varchar (символьная переменная) | 1000 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_User_ Contact_ID (ID контактного пользователя ОСП) | int (целое число) | 4 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Edit_Date (Дата последнего редактирования) | datetime (дата, время) | 8 |
| SCEUnitRecordID (ID записи ОСП по структурной единице) | int (целое число) | 4 |
| ТАБЛИЦА 138 | ||
| tblSCEQuoteRespProjExp (Таблица ответных расценок ОСП на расходы по проекту) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseMainID (основной ID ответной расценки ОСП) | int (целое число) | 4 |
| SCEProfileItemID (ID профильного пункта ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| Identity_Key (ключ идентификации) | int (целое число) | 4 |
| RFXRespProjExpID (ID расходов по проекту в ответе на RFx) | int (целое число) | 4 |
| ProjectExpenseName (Название расходов по проекту) | varchar (символьная переменная) | 50 |
| ProjectExpenseDescription (Описание расходов по проекту) | varchar (символьная переменная) | 1000 |
| BillableExpense (Расходы с выставлением счета) | char (символьный) | 1 |
| MaxAmount (Максимальная сумма) | money (денежный) | 8 |
| PartialPaymentAuthorized (Разрешен частичный платеж) | char (символьный) | 1 |
| Currency ID (Идентификатор валюты) | int (целое число) | 4 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_User_ Contact_ID (ID контактного пользователя ОСП) | int (целое число) | 4 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Edit_Date (Дата последнего редактирования) | datetime (дата, время) | 8 |
| SCEProjExpID (ID записи ОСП по проектным расходам) | int (целое число) | 4 |
| ТАБЛИЦА 139 | ||
| tblSCEQuoteRespStaffProfiles (Таблица профиля персонала для ответных расценок ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseMainID (основной ID ответной расценки ОСП) | int (целое число) | 4 |
| SCEProfileItemID (ID профильного пункта ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| RFXStaffingProfileID (ID профиля персонала в RFx) | int (целое число) | 4 |
| pAnticipatedHours (Предполагаемые часы) | int (целое число) | 4 |
| pQuantity (Количество) | int (целое число) | 4 |
| pBilling (Выписывание счета) | money (денежный) | 8 |
| Client_Comments (Клиентские комментарии) | varchar (символьная переменная) | 1000 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_User_ Contact_ID (ID контактного пользователя ОСП) | int (целое число) | 4 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Edit_Date (Дата последнего редактирования) | datetime (дата, время) | 8 |
| SCEStaffingRecordID (ID записи ОСП по персоналу) | int (целое число) | 4 |
| ТАБЛИЦА 140 | ||
| tblSCEQuoteRespStaffProfilePrice (Таблица цен профиля персонала для ответных расценок ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEStaffingRecordID (ID записи ОСП по персоналу) | int (целое число) | 4 |
| SCEStaffingProfilePriceID (ID цены профиля персонала ОСП) | int (целое число) | 4 |
| Anticipated_Hours (Предполагаемые часы) | float (с плавающей запятой) | 8 |
| Bill_Rate (Ставка по счету) | money (денежный) | 8 |
| Anticipated_Billing (Предполагаемое выставление счета) | money (денежный) | 8 |
| RecordCreateDate (Дата создания записи) | datetime (дата, время) | 8 |
| RecordID (Идентификатор записи) | int (целое число) | 4 |
| ТАБЛИЦА 141 | ||
| tblSCEQuoteRespStaffProfileExpense (Таблица расходов по профилю персонала для ответных расценок ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEStaffingRecordID (ID записи ОСП по персоналу) | int (целое число) | 4 |
| ContractorExpenseTypeID (ID типа расходов подрядчика) | int (целое число) | 4 |
| ContractorExpenseTypeMax (максимум типа расходов подрядчика) | money (денежный) | 8 |
| SCEContractorExpenseID (ID расходов подрядчика ОСП) | int (целое число) | 4 |
| RecordCreateDate (Дата создания записи) | datetime (дата, время) | 8 |
| RecordID (Идентификатор записи) | int (целое число) | 4 |
| ТАБЛИЦА 142 | ||
| tblSCEQuoteRespPhasing (Таблица поэтапного распределения для ответных расценок ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCEQuoteResponseMainID (основной ID ответной расценки ОСП) | int (целое число) | 4 |
| SCEProfileItemID (ID профильного пункта ОСП) | int (целое число) | 4 |
| RFX_Item_ID (ID пункта RFx) | int (целое число) | 4 |
| RFXRespPhaseID (ID этапа в ответе на RFx) | int (целое число) | 4 |
| Project_Phase_Number (Номер этапа проекта) | int (целое число) | 4 |
| Project_Phase_Description (Описание этапа проекта) | varchar (символьная переменная) | 3200 |
| Start_Date (Дата начала этапа) | datetime (дата, время) | 8 |
| End_Date (Дата окончания) | datetime (дата, время) | 8 |
| Total_Days (Общее количество дней) | numeric (числовой) | 9 |
| Client_Comments (Клиентские комментарии) | varchar (символьная переменная) | 1000 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_User_ Contact_ID (ID контактного пользователя ОСП) | int (целое число) | 4 |
| Record_Create_Date (Дата создания записи) | datetime (дата, время) | 8 |
| Last_Edit_Date (Дата последнего редактирования) | datetime (дата, время) | 8 |
| SCEPhaseRecordID (ID записи ОСП по этапу) | int (целое число) | 4 |
Таблицы 133-142 являются типичными таблицами ОСП, используемыми в связи с последовательностью 800, показанной на Фиг.8. Таблицы 133-142 аналогичны таблицам основного поставщика, использованным для отношения основного поставщика с основным поставщиком, как описано в соответствующих заявках. Хотя модель данных в Таблицах 133-142 аналогична модели данных, описанной для таблиц основного поставщика, использованных для отношения основного поставщика с основным поставщиком в предыдущих заявках, однако специалистам в данной области техники будут очевидны многие отличия, в том числе функция синтаксического анализа, которая более подробно описана ниже.
Фиг.9 является типичной блок-схемой, демонстрирующей, как основной поставщик может обрабатывать ответную цепочечную расценку ОСП. Выбор ответных расценок ОСП и их повторное интегрирование в ответ основного поставщика на заявку показаны на Фиг.9. В различных вариантах осуществления изобретения схема базы данных и процедура синтаксического анализа пункта ответа на заявку позволяют основному поставщику выбрать требуемые элементы расценок ОСП и вновь встроить выбранные элементы расценок ОСП на их места согласно меткам. Фиг.9 не иллюстрирует в явном виде способность ОСП принять или отклонить принятие расценки ОСП основным поставщиком; однако эта способность может быть легко сконфигурирована в соответствии с принципами настоящего изобретения.
Согласно Фиг.9, последовательность 900 начинается с шага 902. На шаге 902 поставщик получает ответную расценку ОСП (нескольких ОСП). На шаге 904 поставщик получает доступ к ответу на заявку при помощи стандартной обработки RFx. На шаге 906 отображается статус ответа на заявку поставщика и указывается, существуют ли какие-либо действующие профили расценок, и получены ли какие-либо расценки ОСП, соответствующие профилю расценок ОСП. После шага 906 и активации поставщиком ссылки на профиль расценок ОСП исполнение переходит к шагу 908. На шаге 908 отображается список ОСП, связанных с соответствующим профилем (профилями) расценок ОСП.
На шаге 910 поставщик при желании создает схему анализа профиля расценок ОСП, чтобы управлять множеством расценок, соответствующих одному профилю расценок ОСП. Аналогично тому, как покупатель может переменным образом ожидать пунктов ответа на заявку поставщика, поставщик может переменным образом ожидать пункты ответа на заявку ОСП, для упрощения анализа и потенциального утверждения заявки. На шаге 912 поставщик сортирует индивидуальные расценки ОСП. На шаге 914 подсчитываются очки для индивидуальных расценок ОСП. На шаге 916 поставщик оценивает сводку с анализом профиля расценок, чтобы сравнить соответствующие очки для расценок ОСП.
На шаге 918 принимается решение о том, принимает ли поставщик расценки ОСП, или отклоняет их. Если на шаге 918 поставщик принимает расценки ОСП, то исполнение переходит к шагу 920. На шаге 920 поставщик выбирает конкретную запись из расценок ОСП и активирует функцию «Принять». На шаге 922 предоставляется напоминание «Вы уверены?». В случае ответа «Да» исполнение переходит к шагу 924. В случае ответа «Нет» исполнение возвращается к шагу 918.
На шаге 924 отображается расценка ОСП. В различных вариантах осуществления изобретения все пункты, применимые к ответу на заявку поставщика, имеют сопутствующие отмечаемые кнопки, и указанные отмечаемые кнопки неактивны для любых пунктов, для которых соответствующий пункт ответа на заявку уже отнесен к альтернативной принятой ОСП. На шаге 934 поставщик выбирает соответствующие требуемые пункты расценки и активирует функцию «Принять выбор». На шаге 936 определяется, выбрал ли поставщик хотя бы один пункт, содержащий услугу или материал, по которым может быть выставлен счет. Если на шаге 936 это не определено, то выполнение переходит к пункту 938. На шаге 938 отображается сообщение об ошибке, и предоставляется напоминание о необходимости повторного выбора пунктов расценки. От шага 938 исполнение возвращается к шагу 934.
Если на шаге 918 поставщик отклоняет расценку ОСП, то исполнение переходит к шагу 926. На шаге 926 выбираются отдельные записи по расценкам ОСП, и активируется функция «Отклонение». В различных вариантах осуществления изобретения отдельные записи расценок ОСП могут быть выбраны посредством соответствующих отмечаемых кнопок. На шаге 928 отображается напоминание «Вы уверены?». В случае ответа «Да» исполнение переходит к шагу 930. На шаге 930 статус расценки ОСП корректируется на «Отклонено». В случает ответа «Нет» исполнение переходит от шага 928 к шагу 918.
Если на шаге 936 определено, что поставщик выбрал хотя бы один пункт, содержащий услугу или материал с возможностью выставления счета, то исполнение переходит к шагу 940. На шаге 940 определяется, принял ли поставщик всю расценку ОСП или ее часть. Если на шаге 940 все пункты расценки ОСП приняты поставщиком, то исполнение переходит к шагу 942. На шаге 942 поставщику предоставляется сообщение о Принятии, и значения расценки сохраняются в ответе поставщика на заявку. Если на шаге 940 поставщик принимает только часть расценки ОСП, то исполнение переходит к шагу 944. На шаге 944 поставщику предоставляется сообщение о Принятии, и значения расценки сохраняются в ответе поставщика на заявку. Кроме того, статус расценки ОСП изменяется на «Частично принято». Как после шага 942, так и после шага 944 исполняется шаг 932. После шага 930 исполняется шаг 932.
На шаге 932 выдается стандартное уведомление посредством обновления системы и сообщения по электронной почте.
Фиг.10 является типичной блок-схемой, показывающей, как основной поставщик может использовать средство анализа расценки в отношении расценок, предоставленных ОСП. Фиг.10 показывает, как основные поставщики, подобно покупателям, могут использовать средства оценки ответов на заявку для упрощения процедуры расценок. Фиг.10 не иллюстрирует явно возможность конфигурировать автоматическую загрузку наилучшего результата ОСП в ответ на заявку основного поставщика; однако эта возможность может быть сконфигурирована в соответствии с принципами настоящего изобретения.
На Фиг.10 последовательность 1000 начинается с шага 1002. На шаге 1002 поставщик выбирает требуемый профиль расценок ОСП. В различных вариантах осуществления изобретения список профилей расценок ОСП отображается посредством кнопок с зависимой фиксацией, и поставщик может активировать требуемый профиль расценок ОСП через активацию ссылки, связанной с конкретной кнопкой. На шаге 1004 определяется, существует ли несколько расценок ОСП для конкретного профиля расценок ОСП. Если на шаге 1004 определено, что это не так, то исполняется шаг 1006. На шаге 1006 поставщику предоставляется сообщение о том, что средство анализа с оценкой может использоваться только для нескольких расценок. Если на шаге 1004 решено, что существует несколько расценок для конкретного профиля расценок ОСП, то исполнение переходит к шагу 1008.
На шаге 1008 исполнитель может использовать прикладное средство взвешивания и оценки для сортировки расценок по качеству. Средство сортировки, которое может использоваться покупателем при сортировке ответов основного поставщика на заявку, подробно описано в Патентной заявке США 10/262487. Описанное здесь средство сортировки для оценки качества расценок в ответах ОСП на заявку может выполнять функции, аналогичные описанным в Патентной заявке США, серийный № 10/262487. На шаге 1010 отображается список пунктов ответной расценки, содержащихся в соответствующем профиле расценок ОСП. На шаге 1012 поставщик указывает, какие пункты ответа на заявку будут использованы при анализе, и устанавливает соответствующий вес значимости выбранных пунктов. На шаге 1014 поставщику предоставляется выбор: редактировать или сохранить параметры настройки. Если на шаге 1014 поставщик решает редактировать настройки, то исполнение возвращается к шагу 1010. Если на шаге 1014 поставщик решает сохранить настройки, то исполнение переходит к шагу 1016.
На шаге 1016 выборка, содержащая пункты ответа на заявку, которые должны использоваться при анализе, сохраняется как схема анализа профиля расценок ОСП. В различных вариантах осуществления изобретения соответствующие расценки ОСП доступны для анализа с сортировкой и оценкой. На шаге 1018 поставщик выбирает требуемые расценки ОСП и активирует функцию «Сортировка». Например, могут использоваться сортировка по шкале от A до E, посредством которых пользователь уполномоченного поставщика сортирует ОСП согласно заранее заданным критериям. На шаге 1020 расценка ОСП отображается для поставщика, высвечиваются пункты ответа, применимые к установленной схеме анализа профиля расценок ОСП, и включается поле сортировки для ввода поставщиком. На шаге 1022 поставщик сортирует соответствующие пункты, например, по шкале A-E.
В различных вариантах осуществления изобретения возможность сохранить настройки неактивна, пока поставщик не отсортирует все требуемые пункты. После сортировки всех требуемых пунктов активируется возможность управлять сохранением настроек, и исполнение переходит к шагу 1024. На шаге 1024 поставщику предоставляется выбор: редактировать или сохранить настройки. Если на шаге 1024 поставщик решает редактировать настройки, исполнение возвращается к шагу 1022. Если на шаге 1024 поставщик решает сохранить указанные настройки, то исполнение переходит к шагу 1026.
На шаге 1026 поставщику предоставляется сообщение об успешной операции, и сохраняются классы расценок ОСП. На шаге 1028 поставщику напоминается, желает ли поставщик сравнить расценки ОСП. Если поставщик на шаге 1028 принимает решение сравнить расценки ОСП, то исполнение переходит к шагу 1030.
На шаге 1030 определяется, существует ли несколько отсортированных расценок ОСП для схемы анализа профиля расценок ОСП. Если определено, что существует несколько отсортированных расценок ОСП для схемы анализа профиля расценок ОСП, то исполнение переходит к шагу 1032. На шаге 1032 поставщик выбирает требуемый профиль расценок ОСП. В различных вариантах осуществления изобретения список может отображаться посредством одной или нескольких кнопок с зависимой фиксацией, которые могут быть активированы поставщиком как ссылки.
На шаге 1034 отображается список всех расценок ОСП. В различных вариантах осуществления изобретения в отображаемый список входят все оцениваемые пункты, применимая сортировка, назначенный вес значимости пункта и общая оценка пункта. Общие оценки для расценок и статистическое ранжирование могут также отображаться в виде сводной таблицы. В дополнение к вышесказанному, поставщик может дополнительно обратиться к аналитической сводке из основного меню ответов на RFx.
Фиг.11 является типичной блок-схемой, показывающей, как основной поставщик может добавить дополнительную цену к принятым расценкам ОСП. В частности, Фиг.11 показывает, как основные поставщики могут модифицировать или увеличить расценки ОСП для покупателя. В различных вариантах осуществления изобретения покупатель может конфигурировать или ограничить разрешенную надбавку. Описанные ранее таблицы данных могут использоваться для поддержки функциональных возможностей, показанных на Фиг.11. Например, таблицы ответов на заявку ОСП, показанные в таблицах 130-142, поставляют данные для таблиц ответов основного поставщика на заявку, описанных в Патентной заявке США № 10/267487.
На Фиг.11 последовательность 1100 начинается с шага 1102. На шаге 1102 поставщик получает доступ к ответу на заявку, содержащему принятые элементы расценок ОСП. На шаге 1104 поставщик может принять решение о повышении цен для принятых элементов расценок. Если на шаге 1104 поставщик решает повысить цены, то исполнение переходит к шагу 1106. Если поставщик решает не повышать цены, то исполнение переходит к шагу 1130.
На шаге 1106 поставщик может выбрать функцию редактирования цен ОСП. В ответ на выбор функции редактирования цен ОСП исполнение переходит от шага 1106 к шагу 1108. На шаге 1108 отображается список принятых элементов расценок ОСП и соответствующие цены. На шаге 1110 поставщик выбирает требуемые пункты и активирует функцию модификации цен. На шаге 1112 принимается решение о том, желает ли поставщик определить конкретный процент надбавки или редактировать надбавки вручную. Если на шаге 1112 поставщик желает определить конкретный процент надбавки, то исполнение переходит к шагу 1114. Если на шаге 1112 поставщик желает редактировать надбавки вручную, то исполнение переходит к шагу 1118.
На шаге 1114 поставщику предоставляются отображенные данные и поле для ввода процента. На шаге 1116 поставщик вводит требуемый процент надбавки и активирует функцию обновления цены. На шаге 1118 поставщику предоставляется отображение с полем численного ввода денежной величины для каждого пункта ОСП. На шаге 1120 поставщик вводит желаемую цену, применимую к каждому пункту, и активируется функция обновления цены.
Как от шага 1116, так и от шага 1120 исполнение переходит к шагу 1122. На шаге 1122 входные данные, полученные от поставщика на шаге 1116 или 1120, оцениваются в сравнении с конфигурационными спецификациями. Например, как показано на Фиг.2A и 3A, покупатель может конфигурировать предел максимальной надбавки, которая может быть введена основным поставщиком. На шаге 1124 принимается решение о том, успешно ли прошли проверки, выполненные на шаге 1122. Если на шаге 1124 определено, что проверки, выполненные на шаге 1122, не прошли успешно, то поставщику на шаге 1126 предоставляется сообщение об ошибке, с указанием о неблагоприятном исходе проверки. После шага 1126 выполняется шаг 1112.
Если на шаге 1124 определено, что проверки, выполненные на шаге 1122, прошли успешно, то исполнение переходит к шагу 1128. На шаге 1128 система обновляет ответ поставщика на заявку при помощи новых цен и соответствующих записей из базы данных. На шаге 1130 поставщик использует стандартный способ обработки для представления покупателю ответа поставщика на заявку поставщика. На шаге 1132 системные уведомления рассылаются соответствующим сконфигурированным сторонам.
Фиг.12 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с типичным цепочечным ответом ОСП на заявку, как изображено на Фиг.7-11. Поскольку Фиг.12 может демонстрироваться в качестве примера, то ответ основного поставщика на заявку собран в нескольких таблицах, а не в одной таблице. В результате, Основная таблица 1208 ответа на RFx может собирать сведения из Таблицы 1210 ответа на RFx по материалам, из Таблицы 1212 ответа на RFx по доставляемым материалам, из Таблицы 1214 ответа на RFx по структурным единицам, из Таблицы 1216 ответа на RFx по проектным расходам, из Таблицы 1218 профиля ответа на RFx, и из Таблицы 1220 ответа на RFx по этапам. Таким образом, приведенные выше Таблицы 132-140 являются избыточным набором установленных для ОСП таблиц ответа на заявку, в которых хранятся соответствующие особые пункты заявки. В соответствии с принципами изобретения, различные пункты заявки содержат множество элементов с множеством полей, к примеру, с ценами на материалы. Например, пункт материала - это пункт заявки, допускающий заполнение множеством материалов в предварительно сформированной таблице.
Как показано на Фиг.12, для каждой таблицы, из которой Основная таблица 1208 ответа на RFx может собирать сведения, имеется соответствующая таблица ОСП. Например, Таблица 1210 ответа на RFx по материалам взаимосвязана с Таблицей 1234 ответных расценок ОСП по материалам, Таблица 1212 ответа на RFx по доставляемым материалам взаимосвязана с Таблицей 1236 ответных расценок ОСП по доставляемым материалам, Таблица 1214 ответа на RFx по структурным единицам взаимосвязана с Таблицей 1238 ответных расценок ОСП по структурным единицам, Таблица 1216 ответа на RFx по проектным расходам взаимосвязана с Таблицей 1240 ответных расценок ОСП по проектным расходам, а Таблица 1220 ответа на RFx по этапам взаимосвязана с Таблицей 1242 ответных расценок ОСП по этапам. Аналогичным образом Таблица 1218 профиля ответа на RFx, Таблица 1222 ценового профиля ресурсов RFx и Таблицы 1224 затрат по профилю ресурсов RFx взаимосвязаны с Таблицей 1228 расходов по профилю персонала для ответных расценок ОСП, с Таблицей 1230 цен на профиль персонала для ответных расценок ОСП и с Таблицей 1232 профиля персонала для ответных расценок ОСП, как показано на Фиг.12.
Аналогично описанному выше, Таблица 1246 основных ответных расценок ОСП взаимосвязана с каждой из Таблиц 1234, 1236, 1238, 1240, 1232 и 1242. Также показано, что с Таблицей 1246 основных ответных расценок ОСП связаны Таблица 1248 ответных расценок ОСП, Таблица 1250 пунктов профилей расценок ОСП и Таблица 1252 доставки профилей расценок ОСП. Показано, что Таблица 1254 профилей расценок ОСП взаимосвязана с каждой из Таблиц 1250, 1252 и 1204. Аналогичным образом, показано, что главная Таблица 1202 основного поставщика взаимосвязана с Таблицей ответов 1204 и Таблицей 1206 соответствия ОСП для основного поставщика. Таблица ответов 1204 взаимосвязана с главной Таблицей 1208 ответов на RFx.
Как показано на Фиг.12, модель/схема базы данных допускает поток информации как от основного поставщика к ОСП, так и в обратном направлении. Синтаксический анализ данных может осуществляться до передачи в любом направлении. Модель/схема базы данных, показанная на Фиг.12, допускает установление связанности между пунктом заявки покупателя, пунктом ответа основного поставщика на заявку и пунктом ответа ОСП (или нескольких ОСП) на заявку.
Фиг.13 является типичной блок-схемой, показывающей, как покупатель может обрабатывать ответ основного поставщика на заявку. Фиг.13 также иллюстрирует, как покупатель может обеспечить визуальный контроль над включением ответа ОСП на заявку. Фиг.13 отображает сортировку ответа на заявку, утверждение ответа на заявку и компоненты требования на закупку этапа обработки покупателем ответа на заявку.
В различных вариантах осуществления изобретения сортировка/оценка покупателем ответа на заявку и утверждение ответа на заявку для основных поставщиков может осуществляться способом, аналогичным тому, что описан в Патентной заявке США № 10/262487. В соответствии с принципами изобретения, наблюдаемость элементов расценок ОСП для покупателя обеспечивает дополнительную информацию по ценообразованию и использованию, которая может просматриваться покупателем либо в совокупности, либо по отдельности. Доступная покупателю информация по ценообразованию и использованию может существенно улучшить процесс принятия решения покупателем в отношении наилучшего ответа и предоставить покупателю дополнительные средства для переговоров о ценообразовании и/или услугах.
На Фиг.13 последовательность 1300 начинается с шага 1302. На шаге 1302 покупатель обращается к списку ответов на заявку. В различных вариантах осуществления изобретения оценка покупателем ответов на заявку выполняется при помощи стандартной функции обработки, описанной в Патентной заявке США № 10/262487. На шаге 1304 покупатель оценивает ответ основного поставщика на заявку. На шаге 1306 система обеспечивает дополнительные средства управления для оценки сводки поставщика по использованию активов ОСП, или покупатель может оценить отдельные ответы на заявку. Например, сводка поставщика по использованию активов ОСП может позволить покупателю определить относительный вклад в проект основного поставщика, по сравнению с ОСП, многими различными способами, в отношении различных категорий выставления счетов.
После шага 1306, если активируется управление сводкой, исполнение переходит к шагу 1308. На шаге 1308 система отображает подробности сводки основного поставщика по ответу на заявку. Подробности сводки основного поставщика по ответу на заявку могут включать в себя, например: 1) идентификацию ОСП, включенных в ответ на заявку; 2) отдельные сводки по используемым активам ОСП; 3) сводку по используемым активам основного поставщика; 4) сводку по надбавке основного поставщика; 5) сводку по совокупной процентной доле ОСП (нескольких ОСП) в общих расходах и 6) сводку по совокупной процентной доле основного поставщика в общих расходах.
Если на шаге 1306 покупатель оценивает отдельный ответ на заявку, то исполнение переходит к шагу 1310. На шаге 1310 система указывает покупателю, какой элемент (элементы) ответа связан(ы) с расценкой ОСП, и система предоставляет средства управления для оценки деталей расценки ОСП. На шаге 1312 покупатель может активировать средство управления деталями расценки ОСП. На шаге 1314 система отображает покупателю детали пункта ответа на заявку. Детали ответа на заявку, отображаемые на шаге 1314, могут включать в себя, например: 1) идентификацию ОСП; 2) первоначальную расценку ОСП; 3) процент надбавки основного поставщика и 4) величину надбавки основного поставщика. На шаге 1316 покупатель обрабатывает ответы на заявки в соответствии с конфигурацией покупателя. На шаге 1318 происходит сортировка ответов на заявку. На шаге 1320 происходит утверждение ответа на заявку. На шаге 1322 генерируется требование на закупку. Специалистам в данной области техники должно быть понятно, что каждый из шагов 1316-1322 может включать в себя дополнительные последовательности работ, сконфигурированные покупателем в соответствии с потребностями бизнеса покупателя. Типичные последовательности работ, которые могут быть включены в состав шагов 1316-1322, более подробно описаны в Патентной заявке США № 10/262487.
Хотя Фиг.13 не иллюстрирует явно возможности покупателя просматривать сортировку/ оценку ответа основного поставщика на заявку с включением или без включения элементов ответа ОСП на заявку, но эту возможность несложно осуществить без отклонения от принципов изобретения. Аналогичным образом ОСП, при желании, могут оцениваться независимо.
Фиг.14 иллюстрирует типичную модель/схему базы данных, которая может использоваться в связи с созданием записи ОСП и отслеживанием элементов расценок ОСП на уровне требования на закупку. Фиг.14 подробно описывает, каким образом данные ОСП могут переноситься на стадиях требования на закупку/ заказа на поставку.
Таблица 1402 требования на закупку может собирать сведения из следующих таблиц: Таблицы 1404 оплаты доставляемых материалов по требованию на закупку, Таблицы 1406 оплаты структурных единиц по требованию на закупку, Таблицы 1408 оплаты материалов по требованию на закупку, Таблицы 1410 оплаты проектных расходов по требованию на закупку, Таблицы 1428 ставок оплаты по требованию на закупку, Таблицы 1430 подрядчиков по требованию на закупку и Таблицы 1432 расходов на выплаты подрядчикам по требованию на закупку. Соответствующие таблицы на уровнях ответа на RFx и расценок ОСП взаимосвязаны с соответствующими таблицами требований на закупку. В частности, данные могут перемещаться в любом направлении между Таблицами 1404, 1412 и 1420, между Таблицами 1406, 1414 и 1422, между Таблицами 1408, 1416 и 1424 и между Таблицами 1410, 1418 и 1426. Аналогичным образом данные могут перемещаться в любом направлении между Таблицами 1428, 1434 и 1440, между Таблицами 1430, 1436 и 1442 и между Таблицами 1432, 1438 и 1444.
Модель/схема базы данных, проиллюстрированная на Фиг.14, допускает так называемую функцию автоматической загрузки, при которой утверждение ответа на заявку генерируется таким образом, что покупателю не требуется повторно вводить данные. В некоторых вариантах осуществления изобретения покупатель может иметь возможности редактирования; однако указанные возможности редактирования необязательно должны использоваться покупателем.
В соответствии с моделью/схемой базы данных на Фиг.14, может осуществляться сбор данных из ответной расценки ОСП для ввода основным поставщиком в ответ на RFx. Аналогичным образом данные могут браться из ответа основного поставщика на RFx и вводиться в требование покупателя на закупку. Таким образом, обеспечивается отслеживание базы данных на всем пути от создания цепочечной расценки ОСП до требования покупателя на закупку.
Фиг.15 является типичной блок-схемой, показывающей, как может обрабатываться оценка налогообложения и принятие требования на закупку в ходе цепочечного требования на закупку. Фиг.15 иллюстрирует последовательность 1500. В различных вариантах осуществления изобретения последовательность 1500 обеспечивается посредством технических баз данных, допускающих синтаксический анализ и перегруппировку характерных для ОСП элементов требования на закупку. Обработка первичным поставщиком оценки налогообложения и согласия на требование описаны в Патентной заявке США № 10/412096. Процедура цепочечного вспомогательного требования ОСП, показанная на Фиг.15, аналогична обработке первичным поставщиком оценки налогообложения и согласия на требование, и допускает получение надлежащей информации от соответствующей стороны способом, допускающим аудит и обеспечивающим интеграцию. Последовательность 1500 может использоваться, например, для обеспечения информированности всех участвующих сторон обо всех элементах и условиях требования на закупку, а также для обеспечения их согласования указанными сторонами.
Последовательность 1500 начинается с шага 1502. На шаге 1502 основной поставщик оценивает требование покупателя на закупку, содержащее элементы требования на закупку к ОСП. На шаге 1504 система указывает, какие элементы требования на закупку являются элементами требования на закупку, обеспечиваемыми со стороны ОСП. На шаге 1506 система предоставляет основному поставщику активные средства управления для создания вспомогательного цепочечного требования ОСП. В ответ на шаг 1506 и активацию поставщиком управления вспомогательным требованием исполнение переходит к шагу 1508. На шаге 1508 система предоставляет краткий обзор всех ОСП и соответствующих элементов требования на закупку. Система также допускает указание отдельных элементов, отправляемых в ОСП для оценки налогов и принятия, или обработку элементов ОСП от имени ОСП. В различных вариантах осуществления изобретения указание может осуществляться посредством отмечаемой кнопки.
На шаге 1510, когда выбраны все элементы ОСП, основному поставщику предоставляется активное средство управления «Принять выбор». В различных вариантах осуществления изобретения элементы ОСП могут выбираться посредством соответствующей отмечаемой кнопки. В ответ на шаг 1510 и активацию поставщиком средства управления «Принять выбор» исполнение переходит к шагу 1512.
На шаге 1512 система отображает для основного поставщика сводные данные по обработке. Отображаемые сводные данные по обработке указывают, какие ОСП были уведомлены о том, что отложенное вспомогательное цепочечное требование ОСП ожидает обработки. В различных вариантах осуществления изобретения система также предоставляет поставщику список элементов ОСП требования на закупку, который включает элементы, выбранные для обработки первичным поставщиком. На шаге 1514 система передает соответствующему (соответствующим) ОСП сообщения по электронной почте и системные уведомления.
На шаге 1516 ОСП оценивает вспомогательное цепочечное требование. На шаге 1518 ОСП предоставляется интерфейс оценки налогообложения. Типичный интерфейс налогообложения описан в Патентной заявке США № 10/412096. На шаге 1520, когда ОСП выполнила оценку налогообложения для всех соответствующих элементов, предоставляется активное средство управления «Представить на обработку». В ответ на шаг 1520 и активацию средства управления со стороны ОСП, исполнение переходит к шагу 1522. На шаге 1522 система предоставляет ОСП отображение с указанием о том, что оценка налогообложения завершена, и предоставляет средство управления «Принять элементы требования».
В ответ на шаг 1522 и активацию со стороны ОСП активного средства управления «Принять элементы требования» исполнение переходит к шагу 1524. На шаге 1524 система обрабатывает указанную транзакцию, и ОСП получает сообщение «Транзакция завершена». В дополнение к этому основной поставщик получает уведомление, посредством обновления системы и электронной почты, о том, что завершенное вспомогательное цепочечное требование доступно для обработки. На шаге 1526 основной поставщик оценивает требование покупателя на закупку, содержащее элементы ОСП требования на закупку. Основному поставщику также предоставляется активное средство управления «Управлять вспомогательным цепочечным требованием ОСП». В ответ на шаг 1526 и на активацию основным поставщиком активного средства управления «Управлять вспомогательным цепочечным требованием ОСП» система отображает для поставщика сводные данные по обработке. Отображаемые сводные данные по обработке указывают, какие применимые ОСП содержатся в активном цепочечном вспомогательном требовании, а также предоставляют статус ответа ОСП. Также предоставляется активное средство управления «Просмотр подробностей».
В ответ на шаг 1528 и активацию для вспомогательного цепочечного требования активного средства управления «Просмотр подробностей», исполнение переходит к шагу 1530. На шаге 1530 основному поставщику предоставляются подробные сведения о вспомогательном цепочечном требовании ОСП. Основному поставщику также предоставляется активное средство управления «Добавить к требованию на закупку».
В ответ на шаг 1530 и активацию основным поставщиком активного средства управления «Добавить к требованию на закупку» исполнение переходит к шагу 1532. На шаге 1532 система обновляет требование на закупку, и основному поставщику предоставляется сообщение о загрузке. На шаге 1534 основной поставщик обновляет все применимые элементы вспомогательного цепочечного требования в требованиях на закупку. На шаге 1536 основной поставщик заполняет все элементы требования на закупку, принадлежащие основному поставщику. На шаге 1538 основному поставщику предоставляется активное средство управления «Принять требование покупателя на закупку». В ответ на шаг 1538 и активацию основным поставщиком активного средства управления «Принять требование покупателя на закупку» исполнение переходит к шагу 1540, на котором система обрабатывает указанную транзакцию и выдает стандартные уведомления. Кроме того, на шаге 1540 требование на закупку доступно для окончательной обработки покупателем.
Различные варианты осуществления изобретения предусматривают интегрированную модель данных, переносящую подробные сведения об ОСП и основном поставщике из ответа на заявку в требование на закупку, причем ОСП вводится в процессы оценки налогообложения и согласия с требованием на закупку, и предоставляющую покупателю возможность конфигурирования и проявления гибкости в отношении настройки требования на закупку и моделей обработки данных. Гибкое составление расписок по проектным товарам/услугам в соответствии с принципами настоящего изобретения позволяет осуществлять обработку финансовых данных, при которой покупатель может обрабатывать финансовые данные ОСП требуемым образом.
Примеры структур данных для использования при оценке налогообложения и принятии требования на закупку показаны в Таблицах 143-147. Структуры данных для простоты проиллюстрированы как организованные в формате таблицы, включая все поля, необходимые для оценки налогообложения и принятия требования на закупку. Таблицы взаимосвязаны иерархическим и/или реляционным образом так, что обеспечивается точное хранение и доступ для всей информации, необходимой для конфигурации ОСП, как более подробно описано ниже в связи с Фиг.16. Однако следует понимать, что могут быть включены другие конфигурации и что система не ограничена конкретными конфигурациями, перечисленными в Таблицах 143-147 или на Фиг.16.
| ТАБЛИЦА 143 | ||
|
tblTaxNode (Налоговый узел)
(представление структуры базы данных) |
||
| Наименование столбца | Тип данных | Длина |
| TaxNodeID (Идентификатор налогового узла) | int (целое число) | 4 |
| ParentGUID (Идентификатор родительского GU) | uniqueidentifier (уникальное имя) | 16 |
| ParentTable (Родительская таблица) | varchar (символьная переменная) | 100 |
| Parent ID (Родительский идентификатор) | int (целое число) | 4 |
| CurrentStatusID (Идентификатор текущего статуса) | int (целое число) | 4 |
| SpendingTypeID (Идентификатор типа расходов) | int (целое число) | 4 |
| ReqID (Идентификатор требования) | int (целое число) | 4 |
| ТАБЛИЦА 144 | ||
| tblTaxLineItem (Пункт статьи налогообложения) (представление структуры базы данных) | ||
| Наименование столбца | Тип данных | Длина |
| TaxNodeID (Идентификатор налогового узла) | int (целое число) | 4 |
| ItemValue (Значение пункта) | varchar (символьная переменная) | 1000 |
| TemplateGUID (Идентификатор шаблона GU) | uniqueidentifier (уникальное имя) | 16 |
| TaxAuthorityID (Идентификатор налогового управления) | int (целое число) | 4 |
| TaxableAmount (Сумма, облагаемая налогом) | numeric (численный) | 9 |
| TaxPercent (Процент налогообложения) | float (с плавающей запятой) | 8 |
| TaxBurden (Сумма уплачиваемого налога) | numeric (численный) | 9 |
| UserID (Идентификатор пользователя) | int (целое число) | 4 |
| RecordDate (Дата записи) | datetime (дата, время) | 8 |
| TaxLineRecordID (ID записи по статье налогообложения) | int (целое число) | 4 |
| ТАБЛИЦА 145 | ||
| TblTaxAuthority (Налоговое управление) (представление структуры базы данных) | ||
| Наименование столбца | Тип данных | Длина |
| rowid (идентификатор строки) | int (целое число) | 4 |
| SpendingGUID (Идентификатор расходов GU) | uniqueidentifier (уникальное имя) | 16 |
| TaxAuthorityName (Наименование налогового управления) | varchar (символьная переменная) | 100 |
| Tax_Percent (Процент налогообложения) | float (с плавающей запятой) | 8 |
| RegionID (Идентификатор региона) | int (целое число) | 4 |
| CountyID (Идентификатор округа) | int (целое число) | 4 |
| CountryID (Идентификатор страны) | int (целое число) | 4 |
| CityID (Идентификатор города) | int (целое число) | 4 |
| MuniID (Идентификатор муниципалитета) | int (целое число) | 4 |
| TaxAuthorityID (Идентификатор налогового управления) | int (целое число) | 4 |
| ТАБЛИЦА 146 | ||
| tblSCETaxNode (Налоговый узел ОСП) (представление структуры базы данных) | ||
| Наименование столбца | Тип данных | Длина |
| TaxNodeID (Идентификатор налогового узла) | int (целое число) | 4 |
| ParentGUID (Идентификатор родительского GU) | uniqueidentifier (уникальное имя) | 16 |
| ParentTable (Родительская таблица) | varchar (символьная переменная) | 100 |
| ParentID (Родительский идентификатор) | int (целое число) | 4 |
| RecordAvailableDate (Дата доступности записи) | datetime (дата, время) | 8 |
| PrimaryVendorContactID (Контактный ID основного продавца) | int (целое число) | 4 |
| CurrentStatusID (Идентификатор текущего статуса) | char (символьный) | 10 |
| SCESubmitDate (Дата представления ОСП) | datetime (дата, время) | 8 |
| RecordID (Идентификатор записи) | int (целое число) | 4 |
| SCEVendorID (Идентификатор продавца ОСП) | int (целое число) | 4 |
| ТАБЛИЦА 147 | ||
| tblSCETaxLineItem (Пункт статьи налогообложения для ОСП) (представление структуры базы данных) | ||
| Наименование столбца | Тип данных | Длина |
| TaxNodeID (Идентификатор налогового узла) | int (целое число) | 4 |
| ItemValue (Значение пункта) | varchar (символьная переменная) | 1000 |
| TemplateGUID (Идентификатор шаблона GU) | uniqueidentifier (уникальное имя) | 16 |
| TaxAuthorityID (Идентификатор налогового управления) | int (целое число) | 4 |
| TaxableAmount (Сумма, облагаемая налогом) | numeric (численный) | 9 |
| TaxPercent (Процент налогообложения) | float (с плавающей запятой) | 8 |
| TaxBurden (Сумма уплачиваемого налога) | numeric (численный) | 9 |
| SCEUserID (Идентификатор пользователя ОСП) | int (целое число) | 4 |
| RecordDate (Дата записи) | datetime (дата, время) | 8 |
| SCENodeRecordID (ID записи из узла ОСП) | int (целое число) | 4 |
| SCETaxLineRecordID (ID записи по статье налогообложения для ОСП) | int (целое число) | 4 |
Таблицы 143-147 иллюстрируют базы данных, используемые для обработки данных по цепочечному требованию на закупку. Данные по налоговому узлу, показанные в Таблице 143, могут храниться в Таблице 1618 налогового узла. Данные по пункту статьи налогообложения, показанные в Таблице 144, могут храниться в Таблице 1622 пункта статьи налогообложения. Данные о налоговом управлении, показанные в Таблице 145, могут храниться в Таблице 1620 налогового управления. Данные по налоговому узлу ОСП, показанные в Таблице 146, могут храниться в Таблице 1624 налогового узла ОСП. Данные по пункту статьи налогообложения ОСП, показанные в Таблице 147, могут храниться в Таблице 1626 пункта статьи налогообложения ОСП.
Фиг.16 иллюстрирует модель/схему технической базы данных, которая может использоваться для создания возможностей обработки данных по цепочечному требованию на закупку, как показано на Фиг.15. На Фиг.16 Таблица 1602 требования на закупку может обмениваться данными с любыми из следующих таблиц: Таблица 1604 платных материалов по требованию на закупку, Таблица 1606 платных поставок по требованию на закупку, Таблица 1608 платных единиц по требованию на закупку, Таблица 1610 оплаты расходов подрядчика по требованию на закупку, Таблица 1612 повышения оплаты по требованию на закупку, Таблица 1614 оплаты проектных расходов по требованию на закупку, главная Таблица 1616 продавца и Таблица 1618 налогового узла. Также показаны Таблица 1620 налогового управления, Таблица 1622 пункта статьи налогообложения, Таблица 1624 налогового узла ОСП и Таблица 1626 пункта статьи налогообложения ОСП, которые взаимосвязаны, как показано на Фиг.16. Модель/схема базы данных, проиллюстрированная на Фиг.16, допускает обработку данных цепочечного требования на закупку от уровня ОСП через уровень основного поставщика до уровня покупательского требования на закупку.
Фиг.17 является типичной блок-схемой, показывающей, как покупатель может управлять конфигурацией и созданием заказа на поставку в отношении требования на закупку, связанного с ОСП. В соответствии с принципами изобретения, заказ на поставку может быть сконфигурирован, как минимум, тремя различными способами: 1) без учета ОСП; 2) с отслеживанием обработки финансовых данных ОСП, но без прямого контакта с ОСП; 3) непосредственная совместная работа с ОСП, в целях выставления счетов и оплаты. Таким образом, принципы данного изобретения могут использоваться для расширения возможностей покупателя при обработке данных и ведении дел.
На Фиг.17 последовательность 1700 начинается с шага 1702. На шаге 1702 покупатель принимает требование на закупку, заполненное и принятое основным поставщиком. На шаге 1704 покупатель обрабатывает подтверждения требования на закупку надлежащим и конфигурируемым образом, согласно программе в соответствии с последовательностью работ покупателя. На шаге 1706 требование на закупку подтверждается. На шаге 1708 покупатель уведомляется о подтверждении требования на закупку. На шаге 1710 покупатель использует стандартный интерфейс системы для обработки заказа на поставку основному поставщику. На шаге 1712 покупателю предоставляются меню предпочтений при обработке финансовых данных. На шаге 1714 покупатель может выбрать один из трех вариантов: (1) обработка разрешена только для основного поставщика; (2) платежи основному поставщику, но отслеживание и аудит обработки деятельности по цепочке вниз для ОСП; и (3) обработка разрешена как для основного поставщика, так и для ОСП.
Если на шаге 1714 выбран вариант (1), то исполнение переходит к шагу 1716. На шаге 1716 покупатель конфигурирует события проекта с выставлением счета так, чтобы удовлетворить предпочтения клиентского заказа на поставку. На шаге 1718 покупатель принимает предпочтение заказа на поставку. На шаге 1720 создается клиентский заказ на поставку и заказ основного поставщика на поставку. На шаге 1722 подаются уведомления основному поставщику, и задействуется компонента расписок.
Если на шаге 1714 выбран вариант (2), то исполнение переходит к шагу 1724. На шаге 1724 покупатель конфигурирует события проекта с выставлением счета так, чтобы удовлетворить предпочтительным методам обработки клиентского заказа на поставку, в соответствии с последовательностью работ покупателя. На шаге 1726 покупатель принимает предпочтение заказа на поставку. На шаге 1728 создается клиентский заказ на поставку и заказ основного поставщика на поставку. Кроме того, на шаге 1728 клиентский заказ на поставку содержит флаг цепочечной обработки Уровня 2. На шаге 1730 подаются уведомления основному поставщику, и задействуется компонента расписок.
Если на шаге 1714 выбран вариант (3), то исполнение переходит к шагу 1732. На шаге 1732 покупатель конфигурирует события проекта с выставлением счета так, чтобы удовлетворить предпочтением клиентского заказа на поставку. На шаге 1734 покупатель принимает предпочтение заказа на поставку. На шаге 1736 создается клиентский заказ на поставку и заказ основного поставщика на поставку. Кроме того, на шаге 1736 клиентский заказ на поставку содержит флаг цепочечной обработки Уровня 1. На шаге 1738 подаются уведомления основному поставщику, и задействуется компонента расписок.
Как показано на Фиг.17, в различных вариантах осуществления изобретения существуют три основных метода обработки заказов на поставку, относящиеся к настройке и соотношениям пунктов заказа на поставку во взаимосвязи с покупателем и основным поставщиком, а также покупателем, основным поставщиком и ОСП. Вариант (1) указывает, по существу, на отсутствие предпочтительной обработки с точки зрения обработки данных и отслеживания для отношения между покупателем и основным поставщиком. В варианте (1) в процессе обработки почти игнорируется существование ОСП. Вариант (2) представляет собой метод Уровня 2, в этом случае предпочтение покупателя с точки зрения обработки данных все еще служит для поддержки, по большей части, взаимно однозначного отношения при оплате счетов между покупателем и основным поставщиком. Однако в варианте (2) существует намерение отслеживать и проверять предоставление финансовых средств от основного поставщика к ОСП. Например, возможно наличие двух основных причин, по которым покупатель может пожелать отслеживать и проверять предоставление финансовых средств от основного поставщика к ОСП.
Первая причина может заключаться в том, что покупатель желает обеспечить целостность платежной системы для субподрядчика с точки зрения управления продавцами, к примеру, в диверсифицированной программе затрат, присутствующей во многих государственных контрактах, которая требует, чтобы определенные денежные суммы предоставлялись по государственным контрактам диверсифицированной фирме, представляющей интересы меньшинства. В некоторых случаях возможность варианта с Уровнем 2 указывает на то, что, с точки зрения правительства, отношения по оплате счетов не должны быть взаимно однозначными отношениями между покупателем и ОСП, но могут вместо этого осуществляться через третью сторону, которой в данном случае является основной поставщик. Однако в целях обеспечения целостности диверсифицированных кредитов может потребоваться внедрение механизма проверок и отслеживания.
Таким образом, в варианте (2) покупатель может по-прежнему выписывать счета для оплаты непосредственно через основного поставщика, но при этом вводить механизмы проверок и отслеживания, посредством которых гарантируется предоставление финансовых средств для ОСП.
В варианте (3) у покупателя могут существовать основания, с точки зрения бизнеса и отчетности, для ведения дел непосредственно с ОСП. Например, если определенная доля финансовых средств по конкретному проекту должна быть израсходована совместно с диверсифицированной организацией, то многие государственные контракты требуют, чтобы взаимоотношения на уровне счетов/оплаты существовали непосредственно между покупателем и поставщиком услуг (например, ОСП). Таким образом, в варианте (3) требование на закупку может быть подвергнуто синтаксическому анализу, и на его основе могут быть созданы заказы на поставку, упрощающие обработку данных непосредственно между покупателем и ОСП для соответствующих пунктов счета/оплаты, и покупатель может непосредственно оплачивать ОСП указанные пункты. В качестве другого примера, покупателю может потребоваться возможность отслеживания локальных затрат, независимо от того, какие основные поставщики используются в проектах, в целях связей с общественностью. Это может быть важным, в случае, когда местоположение ОСП, выполняющей работы по проекту, отличается от местоположения основного поставщика.
Примеры структур данных для использования в обработке заказа на поставку, относящегося к требованию на закупку, связанному с ОСП, показаны в Таблицах 148-152. Структуры данных для простоты проиллюстрированы как организованные в формате таблиц, причем каждая таблица содержит все поля, необходимые для обработки заказа на поставку (ЗП), относящегося к требованию на закупку, связанному с ОСП. Таблицы взаимосвязаны иерархическим или реляционным образом, таким образом, что обеспечивается точное хранение и доступ для всей необходимой информации для конфигурации ОСП, как описано более подробно в связи с Фиг.18. Однако следует понимать, что могут быть включены другие конфигурации и что система не ограничена конкретными конфигурациями, перечисленными в Таблицах 148-152 или на Фиг.18.
| ТАБЛИЦА 148 | ||
| tblPO_Vendor (ЗП (заказ на поставку) продавца ) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| POIdentityID (ID идентификации ЗП) | int (целое число) | 4 |
| POIdentity (Идентификация ЗП) | Uniqueidentifier (уникальное имя) | 16 |
| ClientPONum (Клиентский номер ЗП) | Varchar (символьная переменная) | 12 |
| PurchaseReqID (ID требования на закупку) | int (целое число) | 4 |
| POStart (Начало ЗП) | Datetime (дата, время) | 8 |
| POEnd (Окончание ЗП) | Datetime (дата, время) | 8 |
| POApprovedAmount (Утвержденная сумма ЗП) | Money (денежный) | 8 |
| POProjectedAmount (Запланированная сумма ЗП) | Money (денежный) | 8 |
| CurrencyID (ID валюты) | int (целое число) | 4 |
| POVersion (Версия ЗП) | int (целое число) | 4 |
| VersionEffectiveDate (Дата вступления версии в силу) | Datetime (дата, время) | 8 |
| VendorPONum (Номер ЗП продавца) | Varchar (символьная переменная) | 14 |
| POProcessorID (ID узла обработки ЗП) | int (целое число) | 4 |
| ProcessFee (Взнос за обработку) | Numeric (численный) | 9 |
| CurrentStatusID (ID текущего статуса) | int (целое число) | 4 |
| Response_id (ID ответа) | int (целое число) | 4 |
| Order_ID (ID заказа) | int (целое число) | 4 |
| OrderGUID (ID GU заказа) | Uniqueidentifier (уникальное имя) | 16 |
| Vendor_ID (ID продавца) | int (целое число) | 4 |
| PO_RFX_TemplateID (ID шаблона RFx для ЗП) | int (целое число) | 4 |
| PO_Project_Type_ID (ID типа проекта для ЗП) | int (целое число) | 4 |
| PODays (Дни ЗП) | int (целое число) | 4 |
| POStatusID (ID статуса ЗП) | int (целое число) | 4 |
| User_ID (ID пользователя) | int (целое число) | 4 |
| User_type (Тип пользователя) | int (целое число) | 4 |
| ClientPOSetUpStatus (Статус настройки ЗП клиента) | int (целое число) | 4 |
| POApprovedTaxAmount (Утвержденная сумма налога по ЗП) | Money (денежный) | 8 |
| PMOwnerShipID (ID отправки собственника PM) | int (целое число) | 4 |
| ProjectImpactCodeID (ID кода воздействия проекта) | int (целое число) | 4 |
| PODynamicTypeID (ID динамического типа ЗП) | int (целое число) | 4 |
| PO_Modified (ЗП модифицирован) | Datetime (дата, время) | 8 |
| POApprovedAmount_Modified (Утвержденная сумма ЗП изменена) | Datetime (дата, время) | 8 |
| ТАБЛИЦА 149 | ||
| TblPOClient (ЗП клиента) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| POClientID (ID ЗП клиента) | int (целое число) | 4 |
| POIdentityID (ID идентификации ЗП) | int (целое число) | 4 |
| POClientIdentity (Идентификация ЗП клиента) | Uniqueidentifier (уникальное имя) | 16 |
| POIdentity (Идентификация ЗП) | Uniqueidentifier (уникальное имя) | 16 |
| CreatedDate (Дата создания) | Datetime (дата, время) | 8 |
| SCETier1PO (ЗП Уровня 1 для ОСП) | char (символьный) | 1 |
| SCETier2PO (ЗП Уровня 2 для ОСП) | char (символьный) | 1 |
| ТАБЛИЦА 150 | ||
| TblPOClientLine (Статья ЗП клиента) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| POClientLineIdentityID (ID идентификации статьи ЗП клиента) | Int (целое число) | 4 |
| POClientID (ID ЗП клиента) | Int (целое число) | 4 |
| POClientLineIdentity (Идентификация статьи ЗП клиента) | Uniqueidentifier (уникальное имя) | 16 |
| POClientIdentity (Идентификация ЗП клиента) | Uniqueidentifier (уникальное имя) | 16 |
| PoIdentity (Идентификация ЗП) | Uniqueidentifier (уникальное имя) | 16 |
| LineName (Название статьи) | Varchar (символьная переменная) | 100 |
| Description (Описание) | Varchar (символьная переменная) | 1000 |
| SortOrder (Порядок сортировки) | Int (целое число) | 4 |
| CreatedDate (Дата создания) | Datetime (дата, время) | 8 |
| PoLineNumber (Номер статьи ЗП) | Int (целое число) | 4 |
| LastModified (Последнее изменение) | Datetime (дата, время) | 8 |
| ТАБЛИЦА 151 | ||
| TblPOClientSubLine (Пункты статьи ЗП клиента) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| POClientSubLineIdentityID (ID идентификации пункта статьи ЗП клиента) | Int (целое число) | 4 |
| POClientLineIdentityID (ID идентификации статьи ЗП клиента) | Int (целое число) | 4 |
| POClientSubLineIdentity (Идентификация пункта статьи ЗП клиента) | Uniqueidentifier (уникальное имя) | 16 |
| POClientLineIdentity (Идентификация статьи ЗП клиента) | Uniqueidentifier (уникальное имя) | 16 |
| ActivityType (Тип деятельности) | Varchar (символьная переменная) | 5 |
| EarningCode (Код дохода) | Varchar (символьная переменная) | 5 |
| ParentRefGuid (Указатель родительской ссылки) | Uniqueidentifier (уникальное имя) | 16 |
| ParentRefTableName (Название таблицы родительской ссылки) | Varchar (символьная переменная) | 200 |
| ActivityGuid (Указатель деятельности) | Uniqueidentifier (уникальное имя) | 16 |
| Poidentity (Идентификация ЗП) | Uniqueidentifier (уникальное имя) | 16 |
| ActivityTypeName (Наименование типа деятельности) | Varchar (символьная переменная) | 50 |
| SortOrder (Порядок сортировки) | Int (целое число) | 4 |
| CreatedDate (Дата создания) | Datetime (дата, время) | 8 |
| LastModified (Последнее изменение) | Datetime (дата, время) | 8 |
| PRPDeliverableID (ID доставляемого материала по оплачиваемому требованию на закупку (ОТЗ)) | Int (целое число) | 4 |
| PRPMaterialBundleID (ID партии материала по ОТЗ) | Int (целое число) | 4 |
| ProjectExpensesID (ID проектных расходов) | Int (целое число) | 4 |
| PurchaseReqPayRateID (ID тарифа по ОТЗ) | Int (целое число) | 4 |
| ContractorExpensesBundleID (ID партии расходов подрядчика) | Int (целое число) | 4 |
| PRPUnitID (ID структурной единицы по ОТЗ) | Int (целое число) | 4 |
| SCETier1PO (ЗП Уровня 1 для ОСП) | Char (символьный) | 1 |
| SCETier2PO (ЗП Уровня 2 для ОСП) | Char (символьный) | 1 |
| ТАБЛИЦА 152 | ||
| tblSCEPOTier (Уровень ЗП для ОСП) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| POClientID (ID ЗП клиента) | Int (целое число) | 4 |
| SCEVendorID (ID продавца ОСП) | Int (целое число) | 4 |
| TierPOType (Тип Уровня ЗП) | Int (целое число) | 4 |
| RecordID (ID Уровня) | Int (целое число) | 4 |
Таблицы 148-152 иллюстрируют данные, которые могут храниться в таблицах базы данных, используемых для обработки заказа на поставку, относящегося к требованию на закупку, связанному с ОСП. Данные, показанные в Таблице 148, могут храниться в Таблице 1816 заказа на поставку для продавца. Данные, показанные в Таблице 149, могут храниться в Таблице 1818 заказа на поставку для клиента. Данные, показанные в Таблице 150, могут храниться в Таблице 1820 статьи заказа на поставку для клиента. Данные, показанные в Таблице 151, могут храниться в Таблице 1822 пунктов статьи заказа на поставку для клиента. Данные, показанные в Таблице 152, могут храниться в Таблице 1824 уровня заказа на поставку.
Фиг.18 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с обработкой заказа на поставку, относящегося к требованию на закупку, связанному с ОСП. На Фиг.18 проиллюстрированы Таблицы 1802-1822. Таблица 1802 требования на закупку может собирать данные из любых нижеуказанных таблиц: из Таблицы 1804 оплаты расходов подрядчика по требованию на закупку, из Таблицы 1806 тарифов оплаты требования на закупку, из Таблицы 1808 оплаты проектных расходов по требованию на закупку, из Таблицы 1810 оплаты материалов по требованию на закупку, из Таблицы 1812 оплаты доставляемых материалов по требованию на закупку и из Таблицы 1814 оплаты структурных единиц по требованию на закупку. Каждая из Таблиц 1804-1814 взаимосвязана с Таблицей 1822 пунктов статьи заказа на поставку для клиента, которая также взаимосвязана с Таблицей 1820 статьи заказа на поставку для клиента. Таблица 1818 заказа на поставку для клиента может собирать данные из Таблицы 1824 уровня заказа на поставку, и взаимосвязана с Таблицей 1816 заказа на поставку для продавца. Таблица 1816 заказа на поставку для продавца взаимосвязана с Таблицей 1802 требования на закупку. Модель/схема базы данных, проиллюстрированная на Фиг.18, поддерживает три варианта возможности конфигурирования, в том числе взаимно однозначное соответствие, связь одной стороны со всеми и переменный формат. Термин «переменное форматирование» относится к способу, которым пункты статей требования переносятся в заказ на поставку. Первый вариант позволяет принять конфигурацию, которая создает статью заказа на поставку для каждого соответствующего пункта статьи требования на закупку. Вторым вариантом является конфигурация форматирования, позволяющая покупателю поместить все пункты статей требования в одну основную статью клиента в заказе на поставку. Третий вариант допускает переменное конфигурирование, при котором покупатель вручную выбирает отдельные пункты статей требования на закупку и по-разному конфигурирует их путем создания пунктов статей заказа на поставку. Таким образом, десять пунктов статей требования могут быть преобразованы, по выбору покупателя, в запись заказа на поставку, состоящую из трех статей, причем все материалы содержатся в одной статье, все трудовые затраты - в другой статье, и еще одна статья соответствует доставляемым материалам. Заказ на поставку может создаваться в любом формате, который требуется покупателю.
Фиг.19 является типичной блок-схемой, демонстрирующей, как могут обрабатываться расписки ОСП по счетам/требованиям оплаты. Фиг.19 относится к обработке расписок по проектным работам основным поставщиком и ОСП; основная обработка расписок описана в Патентной заявке США № 10/262478. Способность ОСП обрабатывать расписки на выполненные услуги или доставленные товары инициирует начало процесса составления расписок без вмешательства посредника; таким образом, можно избежать неправильного толкования безусловных сведений, передаваемых от ОСП основному поставщику и затем покупателю. Если составление расписок привязано к ОСП, то оценка производительности возможна на более подробном и уместном уровне. Кроме того, маршрутизация расписок ОСП через основного поставщика обеспечивает улучшенную прозрачность операций. Составление расписок в соответствии с принципами данного изобретения позволяет улучшить отслеживание выполнения проекта, контроль над качеством и возможности платежей. Функция составления расписок, проиллюстрированная на Фиг.19, во многих отношениях аналогична той, что описана в Патентной заявке США № 10/262487 и теперь расширена на другой уровень процессов (например, на уровень ОСП).
На Фиг.19 процесс 1900 начинается с шага 1902. На шаге 1902 начинаются работы по проекту. На шаге 1904 ОСП обращается к компоненте составления расписок. На шаге 1906 ОСП обращается к конкретным деталям проекта/заказа на поставку. На шаге 1908 ОСП отбирает соответствующий пункт (пункты) статей расписки для обработки. На шаге 1910 ОСП обрабатывает расписку. На шаге 1912 расписка предоставляется основному поставщику. На шаге 1914 основной поставщик обращается к компоненте составления расписок. На шаге 1916 основной поставщик обращается к расписке, которую представила ОСП. На шаге 1918 определяется, принял ли основной поставщик расписку ОСП. Если на шаге 1918 основной поставщик не принял расписку ОСП, то исполнение переходит к шагу 1920. Например, основной поставщик на шаге 1918 может заметить ошибку в расписке, которую предоставила ОСП, в отношении фактов, известных основному поставщику. Поэтому в подобной ситуации на шаге 1920 основной поставщик направляет ОСП замечания и отклоняет указанную расписку, что позволяет основному поставщику избежать предоставления неправильной расписки покупателю. На шаге 1920 основной поставщик направляет замечания ОСП и отклоняет расписку. От шага 1920 исполнение возвращается к шагу 1908.
Если на шаге 1918 основной поставщик принимает расписку ОСП, то исполнение переходит к шагу 1922. На шаге 1922 основной поставщик направляет покупателю необязательные замечания и представляет расписку на утверждение покупателя. В различных вариантах осуществления настоящего изобретения активизированы стандартные уведомления. От шага 1922 исполнение переходит к шагу 1924. На шаге 1924 покупатель обращается к расписке, поданной основным поставщиком. На шаге 1926 покупатель может принять или отклонить расписку основного поставщика. Если на шаге 1926 покупатель принимает расписку основного поставщика, то исполнение переходит к шагу 1936. Если на шаге 1926 покупатель не принял расписку основного поставщика, то исполнение переходит к шагу 1928. На шаге 1928 основной поставщик направляет замечания ОСП и отклоняет расписку. От шага 1928 исполнение возвращается к шагу 1916. На шаге 1936 статус расписки обновляется, и активизируются уведомления системы. Кроме того, на шаге 1936 запись по расписке становится доступной в целях выписки счета. Специалистам в данной области техники должно быть понятно, что шаги 1926, 1928 и 1936 могут включать в себя множество шагов, в соответствии с последовательностью работ, сконфигурированной покупателем.
Типичная структура данных для использования в связи с расписками ОСП на счета/требования оплаты показана в Таблице 153. Структура данных для простоты проиллюстрирована как организованная в формате таблицы, причем Таблица 153 содержит все необходимые поля для составления расписок ОСП на счета/требования оплаты. Понятно, что могут быть включены другие конфигурации и что система не ограничена конкретными конфигурациями, перечисленными в Таблице 153 или на Фиг.20.
| ТАБЛИЦА 153 | ||
| tblSCEVoucherMaterialDetails (Расписка ОСП - сведения по материалам) (представление структуры базы данных) | ||
| Название столбца | Тип данных | Длина |
| SCE_Mat_vRecord_ID (ID записи v ОСП по материалам) | int (целое число) | 4 |
| SCEMatRecordID (ID записи ОСП по материалам) | int (целое число) | 4 |
| ppmRecordID (ID записи ppm) | int (целое число) | 4 |
| Expense_Incurred_Date (Дата понесенных расходов) | datetime (дата, время) | 8 |
| Material_Name (Наименование материала) | varchar (символьная переменная) | 100 |
| Material_Description (Описание материала) | varchar (символьная переменная) | 500 |
| Unit_Count (Количество единиц) | numeric (численный) | 9 |
| Unit_Cost (Стоимость единицы) | money (денежный) | 8 |
| Line_Item_Cost (Стоимость пункта статьи) | money (денежный) | 8 |
| SCE_User_ID (ID пользователя ОСП) | int (целое число) | 4 |
| SCE_Submit_Date (Дата представления ОСП) | datetime (дата, время) | 8 |
| Status_ID (ID статуса) | int (целое число) | 4 |
| PsApproval_Date (Дата утверждения основным поставщиком) | datetime (дата, время) | 8 |
| PsDeclination_Date (Дата отклонения основным поставщиком) | datetime (дата, время) | 8 |
| psNotes (Примечания основного поставщика) | varchar (символьная переменная) | 1000 |
Фиг.20 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с расписками ОСП по счетам/требованиям оплаты. На Фиг.20 проиллюстрированы только события с выставлением счета, относящиеся к материалам; однако специалистам в данной области техники должно быть понятно, что аналогичная модель/схема базы данных может использоваться для каждой категории событий с выставлением счета. Фиг.20 содержит Таблицы 2002-2032, как показано на иллюстрации.
Фиг.21 является типичной блок-схемой, показывающей, как может осуществляться выставление счета/оплата ОСП. В различных вариантах осуществления изобретения покупатель может просматривать показатели финансовой деятельности по всей цепочке поставок, а не только с точки зрения платежей покупателя основным поставщикам. В некоторых вариантах осуществления изобретения покупатель может обрабатывать финансовые транзакции таким образом, чтобы учитывать платежные кредиты поставщика как на Уровне 1, так и на Уровне 2, причем указанная возможность часто используется в связи с бизнесом диверсифицированных/малых предприятий и, в частности, при деятельности по проектам/контрактам государственных агентств.
В последовательности 2100, проиллюстрированной на Фиг.21, процесс извлечения для обработки финансовых данных зависит от предыдущих данных по транзакциям, выбранных покупателем, и значений сохраненных в базе данных. Процесс извлечения может конфигурироваться покупателем, это означает, что переменные, относящиеся к выбору времени и к организации, могут затрагивать групповые процессы или процессы в реальном времени.
В некоторых вариантах осуществления изобретения обработка документов к оплате Уровня 2 представляет собой ограниченную версию обработки документов к оплате Уровня 1. В большинстве случаев ожидается, что покупатель желает обеспечить, чтобы поставщики услуг получали компенсацию согласно контракту. Однако в некоторых случаях приемлемо признание затратных кредитов на Уровне 2 для диверсифицированных предприятий.
На Фиг.21 последовательность 2100 начинается с шага 2102. На шаге 2102 активируется процедура извлечения времени выставления счета из утвержденной расписки. На шаге 2104 все конфигурированные, применимые на интервале утвержденные расписки, извлекаются для обработки. На шаге 2106 определяется, содержит ли извлеченная выборка какие-либо утвержденные записи расписок для заказов клиента на поставку, помеченных для обработки либо на Уровне 1 ОСП, либо на Уровне 2 ОСП.
Если на шаге 2106 определяется, что никакие заказы клиента на поставку не маркированы для Уровня 1 ОСП или Уровнем 2 ОСП, то исполнение переходит к шагу 2108. На шаге 2108 создается стандартный файл выставления счета. На шаге 2110 все документы с выставлением счета/к оплате проходят только через покупателя и основного поставщика. На шаге 2112 основной поставщик и ОСП проводят автономные сделки, если использовалась ОСП, но покупателю не желательно чтобы ОСП отслеживала финансовую обработку данных.
Если на шаге 2106 определено, что заказ на поставку маркирован как заказ на поставку Уровня 1 ОСП, то исполнение переходит к шагу 2114. На шаге 2114 создаются проанализированные файлы выставления счетов. Проанализированные файлы выставления счетов, созданные на шаге 2114, включают в себя файл основного поставщика и файл ОСП. В различных вариантах осуществления изобретения файл основного поставщика содержит только виды деятельности по непосредственному предоставлению услуг/товаров для дополнительного выставления счетов для соответствующих записей ОСП, подлежащих выставлению счетов/оплаты, в которых клиент согласился выплатить основному поставщику надбавку сверх цены ОСП, что позволяет основному поставщику получить соответствующую надбавку по пунктам выставления счетов, за которые ОСП получает плату непосредственно от покупателя. В различных вариантах осуществления изобретения файл ОСП содержит только виды деятельности по непосредственному предоставлению услуг/товаров, предназначенные для обработки заказа на поставку ОСП на Уровне 1. На шаге 2116 платежи покупателя предоставляются непосредственно основному поставщику и ОСП, соответственно. Кроме того, на шаге 2116 разрешаются оплачиваемые кредиты Уровня 1 для ОСП. На шаге 2118 платежи агрегируются в системе, чтобы точно отразить общую историю платежей по проекту и по заказам на поставку.
Если на шаге 2106 определено, что заказ на поставку маркирован для обработки на Уровне 2 ОСП, то исполнение переходит к шагу 2120. На шаге 2120 создается стандартный файл выставления счетов. От шага 2120 исполнение переходит как к шагу 2122, так и к шагу 2124. На шаге 2122 создается файл отслеживания и проверки Уровня 2 ОСП. На шаге 2124 собираются документы по выставлению счетов/документы к оплате через покупателя и основного поставщика. На шаге 2126 основной поставщик осуществляет платеж в адрес соответствующих ОСП. На шаге 2128 ОСП подтверждает получение платежа, и разрешаются оплачиваемые кредиты Уровня 2 ОСП. От шага 2128 исполнение возвращается к шагу 2122.
Фиг.22 иллюстрирует техническую модель/схему базы данных, которая может использоваться в связи с извлечением файла данных счета/платежа ОСП. На Фиг.22 Таблица 2202 взаимосвязана как с Таблицей 2204 счета-фактуры ОСП для Уровня 2, так и с Таблицей 2206 счета-фактуры ОСП для Уровня 1. Каждая из Таблиц 2202-2206 содержит различные поля для выписки счетов-фактур и разрешает осуществлять выписку счетов-фактур на Уровне 1 и Уровне 2, как описано выше.
Фиг.23A изображает традиционное представление цепочки поставок для покупателя. В блоке 2300 показаны составляющие блоки 2302, 2304, 2306 и 2308. Таким образом, традиционно покупатель может наблюдать только расходы 2302 основного поставщика, производительность 2304 основного поставщика, географический и товарный опыт 2306 основного поставщика и управление риском 2308 основного поставщика. Поскольку покупатель не может наблюдать или получать информацию по другим аспектам цепочки поставок, за пределами составляющих блоков 2302-2308, то покупатель не может оценивать или измерять прочие аспекты, или управлять ими.
Фиг.23B является блок-схемой, иллюстрирующей улучшенную наблюдаемость цепочки поставок для покупателя в соответствии с принципами настоящего изобретения. Блок 2350 включает в себя блоки 2352-2366. В различных вариантах осуществления изобретения покупатель может получать информацию в отношении расходов 2352 основного поставщика и расходов 2354 ОСП-поставщика. Аналогичным образом покупатель может оценить производительность 2356 основного поставщика, а также производительность 2358 ОСП. Кроме того, покупатель может определить географический и товарный опыт основного поставщика, а также географический и товарный опыт ОСП. Кроме того, в различных вариантах осуществления изобретения покупатель может оценивать как управление риском 2364 основного поставщика, так и управление риском 2366 поставщика ОСП.
С учетом вышеизложенного очевидно, что принципы настоящего изобретения допускают дальнейшее расширение на ОСП (или на несколько ОСП) средств оценки и измерения производительности, подобных тем, что описаны в Патентной заявке США № 10/412096, а также очевидно, что производительность основного поставщика может быть лучше оценена путем агрегирования и разделения использования цепочки основного поставщика, с включением или без включения подробных сведений об ОСП. В некоторых вариантах осуществления изобретения может оцениваться деятельность и производительность ОСП, а также влияние указанной деятельности и производительности на основную цепочку поставок.
Фиг.24 иллюстрирует, каким образом варианты осуществления изобретения могут воздействовать на цепочку поставок покупателя. Фиг.24 включает в себя область 2402 деятельности ОСП, область 2404 деятельности основного поставщика и область 2406 деятельности покупателя в виде концентрических кругов, причем область 2406 деятельности ОСП находится в центре. Различные варианты осуществления изобретения позволяют покупателю оценивать данные не только в области 2406 деятельности покупателя и в области 2404 деятельности основного поставщика, но также в области 2402 деятельности ОСП. Информация, полученная таким образом от покупателя, может использоваться для улучшения различных аспектов деятельности покупателя, включая, в частности, управление общей цепочкой поставок, управление риском, ценообразование/калькуляцию издержек, географические возможности предоставления товаров/услуг, стратегические альянсы, осуществление доставки, поддержку диверсифицированного бизнеса и управление расходами.
Предыдущее описание относится к варианту (вариантам) осуществления изобретения, и объем изобретения не должен ограничиваться указанным описанием. Вместо этого объем настоящего изобретения определяется следующими пунктами формулы изобретения и их эквивалентами.
1. Компьютерно-реализуемый способ содействия процедуре заявки по проекту, включающий в себя:
генерирование серверным компьютером связанного с покупателем запроса на заявку;
передачу связанного с покупателем запроса на заявку от серверного компьютера к, по меньшей мере, одному поставщику для побуждения ответа поставщика на заявку;
генерирование связанного с поставщиком запроса на заявку;
передачу связанного с поставщиком запроса на заявку, по меньшей мере, одной организации-субподрядчику;
передачу ответа поставщика на заявку;
прием ответа организации-субподрядчика на заявку;
прием выбора, по меньшей мере, части данных ответа на заявку, включенных в ответ организации-субподрядчика на заявку; и
обновление ответа поставщика на заявку выбранной, по меньшей мере, частью данных ответа на заявку, включенных в ответ организации-субподрядчика на заявку.
2. Способ по п.1, в котором этап генерирования связанного с покупателем запроса на заявку дополнительно включает в себя:
прием данных связанного с покупателем запроса на заявку от покупателя для связанного с покупателем запроса на заявку и
сохранение данных связанного с покупателем запроса на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки.
3. Способ по п.2, в котором ответ поставщика на заявку включает в себя данные ответа на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку.
4. Способ по п.3, в котором ответ организации-субподрядчика на заявку включает в себя данные ответа на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с поставщиком запроса на заявку.
5. Способ по п.4, дополнительно включающий в себя передачу ответа поставщика на заявку покупателю после заполнения поставщиком всех требуемых полей.
6. Способ по п.5, дополнительно включающий в себя передачу ответа организации-субподрядчика на заявку поставщику после заполнения всех требуемых полей организацией-субподрядчиком.
7. Способ по п.4, дополнительно включающий в себя
прием одобрения ответа организации-субподрядчика на заявку.
8. Способ по п.7, дополнительно включающий в себя передачу покупателю ответа поставщика на заявку.
9. Способ по п.8, дополнительно включающий в себя прием запроса покупателя на доступ к данным, относящимся к ответу организации-субподрядчика на заявку.
10. Способ по п.3, в котором этап передачи связанного с покупателем запроса на заявку включает в себя выбор, по меньшей мере, одного поставщика для приема связанного с покупателем запроса на заявку с использованием данных связанного с покупателем запроса на заявку.
11. Способ по п.4, в котором этап передачи связанного с поставщиком запроса на заявку включает в себя выбор, по меньшей мере, одной организации-субподрядчика для приема связанного с поставщиком запроса на заявку с использованием данных связанного с поставщиком запроса на заявку.
12. Способ по п.10, в котором этап выбора, по меньшей мере, одного поставщика дополнительно включает в себя:
поддержку информации о поставщике, связанной, по меньшей мере, с одним поставщиком; и
сравнение данных связанного с покупателем запроса на заявку с информацией о поставщике для выбора, по меньшей мере, одного поставщика.
13. Способ по п.11, в котором этап выбора, по меньшей мере, одной организации-субподрядчика дополнительно включает в себя:
поддержку информации об организациях-субподрядчиках, связанной, по меньшей мере, с одной организацией-субподрядчиком; и
сравнение данных связанного с поставщиком запроса на заявку с информацией об организациях-субподрядчиках для выбора, по меньшей мере, одной организации-субподрядчика.
14. Способ по п.1, дополнительно включающий в себя:
прием утверждения заявки поставщика;
передачу поставщику требования на закупку;
передачу проанализированного требования на закупку организации-субподрядчику; и
причем проанализированное требование на закупку является подмножеством требования на закупку.
15. Способ по п.14, в котором требование на закупку предоставляется поставщику с целью его принятия и оценки налогообложения.
16. Способ по п.14, в котором проанализированное требование на закупку предоставляется организации-субподрядчику с целью его принятия и оценки налогообложения.
17. Способ по п.14, дополнительно включающий в себя:
прием заполненного проанализированного требования на закупку от организации-субподрядчика и
генерирование заполненного требования на закупку.
18. Способ по п.17, в котором этап генерирования заполненного требования на закупку включает в себя агрегирование, по меньшей мере, одного заполненного требования на закупку.
19. Способ по п.17, дополнительно включающий в себя:
генерирование связанного с покупателем заказа на поставку поставщику;
генерирование связанного с поставщиком заказа на поставку организации-субподрядчику;
в ответ на определение, что организация-субподрядчик может получать плату непосредственно от покупателя, генерирование связанного с покупателем заказа на поставку организации-субподрядчику.
20. Способ по п.1, в котором этап генерирования связанного с поставщиком запроса на заявку дополнительно включает в себя:
прием данных связанного с поставщиком запроса на заявку от поставщика для связанного с поставщиком запроса на заявку;
при этом данные связанного с поставщиком запроса на заявку выбираются из данных связанного с покупателем запроса на заявку; и
сохранение данных связанного с поставщиком запроса на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку.
21. Компьютерная система для содействия процедуре заявки по проекту с участием покупателя, поставщика и, по меньшей мере, одной организации-субподрядчика, причем компьютерная система включает себя:
систему базы данных;
сервер, соединенный с системой базы данных и имеющий возможность соединения с покупателем, поставщиком и, по меньшей мере, одной организацией-субподрядчиком;
причем сервер выполнен с возможностью:
генерирования связанного с покупателем запроса на заявку, при этом сервер принимает данные связанного с покупателем запроса на заявку от покупателя для связанного с покупателем запроса на заявку;
передачи связанного с покупателем запроса на заявку поставщику;
генерирования связанного с поставщиком запроса на заявку посредством анализа связанного с поставщиком запроса на заявку;
передачи связанного с поставщиком запроса на заявку, по меньшей мере, одной организации-субподрядчику;
передачи ответа поставщика на заявку;
приема ответа организации-субподрядчика на заявку;
приема выбора, по меньшей мере, части данных ответа на заявку, включенных в ответ организации-субподрядчика на заявку; и
обновления ответа поставщика на заявку выбранной, по меньшей мере, частью данных ответа на заявку, включенных в ответ организации-субподрядчика на заявку.
22. Компьютерная система по п.21, в которой генерирование связанного с покупателем запроса на заявку дополнительно включает в себя:
прием данных связанного с покупателем запроса на заявку от покупателя для связанного с покупателем запроса на заявку и
сохранение данных связанного с покупателем запроса на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки.
23. Компьютерная система по п.22, в которой ответ поставщика на заявку включает в себя данные ответа на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку.
24. Компьютерная система по п.23, в которой ответ организации-субподрядчика на заявку включает в себя данные ответа на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с поставщиком запросе на заявку.
25. Компьютерная система по п.21, в которой сервер дополнительно выполнен с возможностью передачи покупателю ответа поставщика на заявку.
26. Компьютерная система по п.25, в которой сервер дополнительно выполнен с возможностью передачи поставщику ответа организации-субподрядчика на заявку.
27. Компьютерная система по п.24, в которой сервер дополнительно выполнен с возможностью приема одобрения ответа организации-субподрядчика на заявку.
28. Компьютерная система по п.27, в которой сервер дополнительно выполнен с возможностью передачи покупателю ответа поставщика на заявку.
29. Компьютерная система по п.28, в которой сервер дополнительно выполнен с возможностью приема запроса покупателя на доступ к данным, относящимся к ответу организации-субподрядчика на заявку.
30. Компьютерная система по п.23, в которой передача связанного с покупателем запроса на заявку включает в себя выбор, по меньшей мере, одного поставщика для приема связанного с покупателем запроса на заявку, с использованием данных связанного с покупателем запроса на заявку.
31. Компьютерная система по п.24, в которой передача связанного с поставщиком запроса на заявку включает в себя выбор, по меньшей мере, одной организации-субподрядчика для приема связанного с поставщиком запроса на заявку, с использованием данных связанного с поставщиком запроса на заявку.
32. Компьютерная система по п.30, в которой выбор, по меньшей мере, одного поставщика дополнительно включает в себя:
поддержание информации о поставщике, связанной, по меньшей мере, с одним поставщиком; и
сравнение данных связанного с покупателем запроса на заявку с информацией о поставщике для выбора, по меньшей мере, одного поставщика.
33. Компьютерная система по п.31, в которой выбор, по меньшей мере, одной организации-субподрядчика дополнительно включает в себя:
поддержку информации об организациях-субподрядчиках, связанной, по меньшей мере, с одной организацией-субподрядчиком; и
сравнение данных связанного с поставщиком запроса на заявку с информацией об организациях-субподрядчиках для выбора, по меньшей мере, одной организации-субподрядчика.
34. Компьютерная система по п.31, в которой сервер дополнительно выполнен с возможностью:
приема утверждения заявки поставщика;
передачи поставщику требования на закупку;
передачи проанализированного требования на закупку организации-субподрядчику;
причем проанализированное требование на закупку является подмножеством требования на закупку.
35. Компьютерная система по п.34, в которой требование на закупку предоставляется поставщику для целей принятия и оценки налогообложения.
36. Компьютерная система по п.34, в которой проанализированное требование на закупку предоставляется организации-субподрядчику для целей принятия и оценки налогообложения.
37. Компьютерная система по п.34, в которой сервер дополнительно выполнен с возможностью:
приема заполненного проанализированного требования на закупку от организации-субподрядчика и
генерирования заполненного требования на закупку.
38. Компьютерная система по п.37, в которой генерирование заполненного требования на закупку включает в себя агрегирование, по меньшей мере, одного заполненного требования на закупку.
39. Компьютерная система по п.37, в которой сервер дополнительно выполнен с возможностью:
генерирования связанного с покупателем заказа на поставку для поставщика;
генерирования связанного с поставщиком заказа на поставку для организации-субподрядчика; и
в ответ на определение, что организация-субподрядчик может получать оплату непосредственно от покупателя, генерирования связанного с покупателем заказа на поставку для организации-субподрядчика.
40. Компьютерная система по п.21, в которой генерирование связанного с поставщиком запроса на заявку дополнительно включает в себя:
прием данных связанного с поставщиком запроса на заявку от поставщика для связанного с поставщиком запроса на заявку;
причем данные связанного с поставщиком запроса на заявку выбираются из данных связанного с покупателем запроса на заявку; и
сохранение данных связанного с поставщиком запроса на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку.
41. Машиночитаемый носитель, имеющий сохраненные на нем исполняемые компьютером инструкции, которые при исполнении их процессором побуждают процессор:
генерировать связанный с покупателем запрос на заявку;
передавать связанный с покупателем запрос на заявку, по меньшей мере, одному поставщику для побуждения ответа поставщика на заявку;
генерировать связанный с поставщиком запрос на заявку;
передавать связанный с поставщиком запрос на заявку, по меньшей мере, одной организации-субподрядчику;
передавать ответ поставщика на заявку;
принимать ответ организации-субподрядчика на заявку;
принимать выбор, по меньшей мере, части данных ответа на заявку, включенных в ответ организации-субподрядчика на заявку; и
обновлять ответ поставщика на заявку выбранной, по меньшей мере, частью данных ответа на заявку, включенных в ответ организации-субподрядчика на заявку.
42. Машиночитаемый носитель по п.41, в котором исполняемые компьютером инструкции, побуждающие процессор генерировать связанный с покупателем запрос на заявку, дополнительно побуждают процессор:
принимать данные связанного с покупателем запроса на заявку от покупателя для связанного с покупателем запроса на заявку и
сохранять данные связанного с покупателем запроса на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки.
43. Машиночитаемый носитель по п.42, в котором исполняемые компьютером инструкции дополнительно побуждают процессор включать в ответ поставщика на заявку данные ответа на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку.
44. Машиночитаемый носитель по п.43, в котором исполняемые компьютером инструкции дополнительно побуждают процессор включать в ответ организации-субподрядчика на заявку данные ответа на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с поставщиком запросе на заявку.
45. Машиночитаемый носитель по п.44, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать покупателю ответ поставщика на заявку после заполнения всех требуемых полей поставщиком.
46. Машиночитаемый носитель по п.45, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать поставщику ответ организации-субподрядчика на заявку после заполнения всех требуемых полей организацией-субподрядчиком.
47. Машиночитаемый носитель по п.44, в котором исполняемые компьютером инструкции дополнительно побуждают процессор принимать одобрение ответа организации-субподрядчика на заявку.
48. Машиночитаемый носитель по п.47, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать покупателю ответ поставщика на заявку.
49. Машиночитаемый носитель по п.48, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор принимать запрос покупателя на доступ к данным, относящимся к ответу организации-субподрядчика на заявку.
50. Машиночитаемый носитель по п.43, в котором исполняемые компьютером инструкции, побуждающие процессор передавать связанный с покупателем запрос на заявку, побуждают процессор выбирать, по меньшей мере, одного поставщика для приема связанного с покупателем запроса на заявку с использованием данных связанного с покупателем запроса на заявку.
51. Машиночитаемый носитель по п.44, в котором исполняемые компьютером инструкции, побуждающие процессор передавать связанный с поставщиком запрос на заявку, побуждают процессор выбирать, по меньшей мере, одну организацию-субподрядчика для приема связанного с поставщиком запроса на заявку с использованием данных связанного с поставщиком запроса на заявку.
52. Машиночитаемый носитель по п.50, в котором исполняемые компьютером инструкции, побуждающие процессор выбирать, по меньшей мере, одного поставщика дополнительно побуждают процессор:
поддерживать информацию о поставщике, связанную, по меньшей мере, с одним поставщиком; и
сравнивать данные связанного с покупателем запроса на заявку с информацией о поставщике для выбора, по меньшей мере, одного поставщика.
53. Машиночитаемый носитель по п.51, в котором исполняемые компьютером инструкции, побуждающие процессор выбирать, по меньшей мере, одну организацию-субподрядчика, дополнительно побуждают процессор:
поддерживать информацию об организациях-субподрядчиках, связанную, по меньшей мере, с одной организацией-субподрядчиком; и
сравнивать данные связанного с поставщиком запроса на заявку с информацией об организациях-субподрядчиках для выбора, по меньшей мере, одной организации-субподрядчика.
54. Машиночитаемый носитель по п.51, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор:
принимать утверждение заявки поставщика;
передавать поставщику требования на закупку;
передавать организации-субподрядчику проанализированное требование на закупку;
причем проанализированное требование на закупку является подмножеством требования на закупку.
55. Машиночитаемый носитель по п.54, в котором требование на закупку представляется поставщику в целях принятия и оценки налогообложения.
56. Машиночитаемый носитель по п.54, в котором проанализированное требование на закупку представляется организации-субподрядчику в целях принятия и оценки налогообложения.
57. Машиночитаемый носитель по п.54, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор:
принимать заполненное проанализированное требование на закупку от организации-субподрядчика и
генерировать заполненное требование на закупку.
58. Машиночитаемый носитель по п.57, в котором исполняемые компьютером инструкции, побуждающие процессор генерировать заполненное требование на закупку, побуждают процессор агрегировать, по меньшей мере, одно заполненное требование на закупку.
59. Машиночитаемый носитель по п.57, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор:
генерировать связанный с покупателем заказ на поставку поставщику;
генерировать связанный с поставщиком заказ на поставку организации-субподрядчику и
генерировать связанный с покупателем заказ на поставку организации-субподрядчику в ответ на определение, что организация-субподрядчик может получать оплату непосредственно от покупателя.
60. Машиночитаемый носитель по п.51, в котором исполняемые компьютером инструкции, побуждающие процессор генерировать связанный с поставщиком запрос на заявку, дополнительно побуждают процессор:
принимать данные связанного с поставщиком запроса на заявку от поставщика для связанного с поставщиком запроса на заявку;
при этом данные связанного с поставщиком запроса на заявку выбираются из данных связанного с покупателем запроса на заявку; и
сохранять данные связанного с поставщиком запроса на заявку в полях, связанных, по меньшей мере, с частью вариантов выбора пунктов заявки, использованных в связанном с покупателем запросе на заявку.
61. Компьютерно-реализуемый способ управления процессом заявки по проекту, включающий в себя:
прием запроса на наделение полномочиями в отношении организации-субподрядчика;
прием запроса аффилирования в отношении основного поставщика, причем запрос аффилирования требует, чтобы организация-субподрядчик была аффилирована с основным поставщиком;
передачу связанного с покупателем запроса на заявку поставщику для побуждения ответа поставщика на заявку;
передачу, по меньшей мере, одной организации-субподрядчику цепочечной расценки, связанной со связанным с покупателем запросом на заявку;
передачу ответа поставщика на заявку;
прием заполненной цепочечной расценки, причем заполненная цепочечная расценка содержит надлежащие заполненные пункты цепочечной расценки, входящие в переданную цепочечную расценку;
обновление посредством компьютера ответа поставщика на заявку для связанного с покупателем запроса на заявку с использованием, по меньшей мере, некоторых из надлежащих заполненных пунктов цепочечной расценки и
передачу покупателю обновленного ответа поставщика на заявку.
62. Способ по п.61, дополнительно включающий в себя:
передачу поставщику покупательского утверждения заявки;
передачу поставщику требования на закупку;
анализ требования на закупку и
передачу проанализированного требования на закупку организации-субподрядчику.
63. Способ по п.62, дополнительно включающий в себя:
прием заполненного требования на закупку от организации-субподрядчика;
агрегирование заполненного требования на закупку, полученного от организации-субподрядчика; и
передачу заказа на поставку, по меньшей мере, одному из поставщика и организации-субподрядчика.
64. Способ по п.63, в котором этап передачи заказа на поставку включает в себя:
определение, может ли организация-субподрядчик получать оплату непосредственно от покупателя; и
в ответ на определение, что организация-субподрядчик может получать оплату непосредственно от покупателя:
передачу поставщику заказа на поставку;
анализ переданного заказа на поставку для сегментирования деталей заказа на поставку, относящихся к организации-субподрядчику; и
передачу проанализированного заказа на поставку организации-субподрядчику.
65. Способ по п.63, в котором этап передачи заказа на поставку включает в себя:
определение, может ли организация-субподрядчик получать оплату непосредственно от покупателя; и
в ответ на определение, что организация-субподрядчик не может получать оплату непосредственно от покупателя, передачу заказа на поставку поставщику.
66. Способ по п.63, дополнительно включающий в себя передачу поставщику расписки организации-субподрядчика.
67. Способ по п.63, дополнительно включающий в себя передачу покупателю расписки поставщика.
68. Способ по п.66, дополнительно включающий в себя передачу покупателю расписки поставщика.
69. Способ по п.67, дополнительно включающий в себя прием подтверждения расписки покупателем.
70. Способ по п.68, дополнительно включающий в себя прием подтверждения расписки покупателем.
71. Способ по п.69, дополнительно включающий в себя передачу счета-фактуры покупателю.
72. Способ по п.70, дополнительно включающий в себя передачу счета-фактуры покупателю.
73. Машиночитаемый носитель, имеющий сохраненные на нем исполняемые компьютером инструкции, которые при исполнении их процессором побуждают процессор:
принимать запрос на наделение полномочиями в отношении организации-субподрядчика;
принимать запрос аффилирования в отношении основного поставщика, причем запрос аффилирования требует, чтобы организация-субподрядчик была аффилирована с основным поставщиком;
передавать поставщику связанный с покупателем запрос на заявку для побуждения ответа поставщика на заявку;
передавать, по меньшей мере, одной организации-субподрядчику цепочечной расценки, связанной со связанным с покупателем запросом на заявку;
передавать ответ поставщика на заявку;
принимать заполненную цепочечную расценку, причем заполненная цепочечная расценка содержит надлежащие заполненные пункты цепочечной расценки, входящие в переданную цепочечную расценку;
обновлять ответ поставщика на заявку для связанного с покупателем запроса на заявку с использованием, по меньшей мере, некоторых из надлежащих заполненных пунктов цепочечной расценки и
передавать покупателю обновленный ответ поставщика на заявку.
74. Машиночитаемый носитель по п.73, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор:
передавать поставщику утверждения заявки покупателем;
передавать поставщику требования на закупку;
анализировать требование на закупку и
передавать проанализированное требование на закупку организации-субподрядчику.
75. Машиночитаемый носитель по п.74, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор:
принимать от организации-субподрядчика заполненное требование на закупку;
агрегировать заполненное требование на закупку, полученное от организации-субподрядчика; и
передавать заказ на поставку, по меньшей мере, одному из поставщика и организации-субподрядчика.
76. Машиночитаемый носитель по п.75, в котором исполняемые компьютером инструкции, побуждающие процессор передавать заказ на поставку, дополнительно побуждают процессор:
определять, может ли организация-субподрядчик получать оплату непосредственно от покупателя; и
в ответ на определение, что организация-субподрядчик может получать оплату непосредственно от покупателя:
передавать поставщику заказ на поставку;
анализировать переданный заказ на поставку для сегментирования деталей заказа на поставку, относящихся к организации-субподрядчику; и
передавать организации-субподрядчику проанализированный заказ на поставку.
77. Машиночитаемый носитель по п.75, в котором исполняемые компьютером инструкции, побуждающие процессор передавать заказ на поставку, дополнительно побуждают процессор:
определять, может ли организация-субподрядчик получать оплату непосредственно от покупателя, и
передавать поставщику заказ на поставку в ответ на определение, что организация-субподрядчик не может получать оплату непосредственно от покупателя.
78. Машиночитаемый носитель по п.75, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать поставщику расписку организации-субподрядчика.
79. Машиночитаемый носитель по п.75, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать покупателю расписку поставщика.
80. Машиночитаемый носитель по п.78, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать покупателю расписку поставщика.
81. Машиночитаемый носитель по п.79, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор принимать утверждение расписки покупателем.
82. Машиночитаемый носитель по п.80, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор принимать утверждение расписки покупателем.
83. Машиночитаемый носитель по п.81, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать счет-фактуру покупателю.
84. Машиночитаемый носитель по п.82, в котором исполняемые компьютером инструкции при исполнении дополнительно побуждают процессор передавать счет-фактуру покупателю.
85. Компьютерная система для управления процессом заявки по проекту, причем компьютерная система содержит:
систему базы данных;
сервер, соединенный с системой базы данных, причем сервер выполнен с возможностью:
приема запроса на наделение полномочиями организации-субподрядчика;
приема запроса аффилирования в отношении основного поставщика, причем запрос аффилирования требует, чтобы организация-субподрядчик была аффилирована с основным поставщиком;
передачи связанного с покупателем запроса на заявку поставщику для побуждения ответа поставщика на заявку;
передачи, по меньшей мере, одной организации-субподрядчику цепочечной расценки, связанной со связанным с покупателем запросом на заявку;
приема заполненной цепочечной расценки, причем заполненная цепочечная расценка содержит надлежащие заполненные пункты цепочечной расценки, входящие в переданную цепочечную расценку;
обновления ответа поставщика на заявку для связанного с покупателем запроса на заявку с использованием, по меньшей мере, некоторых из надлежащих заполненных пунктов цепочечной расценки; и
передачи покупателю обновленного ответа поставщика на заявку.
86. Компьютерная система по п.85, в которой сервер дополнительно выполнен с возможностью:
передачи поставщику утверждения заявки покупателем;
передачи поставщику требования на закупку;
анализа требования на закупку и
передачи организации-субподрядчику проанализированного требования на закупку.
87. Компьютерная система по п.86, в которой сервер дополнительно выполнен с возможностью:
приема заполненного требования на закупку от организации-субподрядчика;
агрегирования заполненного требования на закупку, полученного от организации-субподрядчика; и
передачи заказа на поставку, по меньшей мере, одному из поставщика или организации-субподрядчика.
88. Компьютерная система по п.87, в которой передача заказа на поставку включает в себя:
определение, может ли организация-субподрядчик получать оплату непосредственно от покупателя; и
в ответ на определение, что организация-субподрядчик может получать оплату непосредственно от покупателя:
передачу поставщику заказа на поставку;
анализ переданного заказа на поставку для сегментирования деталей заказа на поставку, относящихся к организации-субподрядчику, и
передачу организации-субподрядчику проанализированного заказа на поставку.
89. Компьютерная система по п.87, в которой передача заказа на поставку включает в себя:
определение, может ли организация-субподрядчик получать оплату непосредственно от покупателя, и
в ответ на определение, что организация-субподрядчик не может получать оплату непосредственно от покупателя, передачу поставщику заказа на поставку.
90. Компьютерная система по п.87, в которой сервер дополнительно выполнен с возможностью передачи поставщику расписки организации-субподрядчика.
91. Компьютерная система по п.87, в которой сервер дополнительно выполнен с возможностью передачи покупателю расписки поставщика.
92. Компьютерная система по п.90, в которой сервер дополнительно выполнен с возможностью передачи покупателю расписки поставщика.
93. Компьютерная система по п.91, в которой сервер дополнительно выполнен с возможностью приема подтверждения расписки покупателем.
94. Компьютерная система по п.92, в которой сервер дополнительно выполнен с возможностью приема подтверждения расписки покупателем.
95. Компьютерная система по п.93, в которой сервер дополнительно выполнен с возможностью передачи счета-фактуры покупателю.
96. Компьютерная система по п.94, в которой сервер дополнительно выполнен с возможностью передачи счета-фактуры покупателю.
