MX2007009333A

MX2007009333A - Cambio de trabajo de proyecto en el sistema y el metodo de sinergia de informacion administrativa y de negocios en el plan/alcance.

Info

Publication number: MX2007009333A
Application number: MX2007009333A
Authority: MX
Inventors: Leonid Zilberman; Andrew A Cullen Iii; Steven A Shaw
Original assignee: Volt Inf Sciences Inc
Priority date: 2005-02-11
Filing date: 2006-02-10
Publication date: 2007-10-10
Also published as: AU2006213709A1; EP1913534A4; WO2006086690A2; US20060190391A1; EP1913534A2; CN101283317A; WO2006086690A3; SG159530A1; JP2008530692A; JP5172354B2

Abstract

Un metodo de gestion administrativa de trabajo de proyecto incluye recibir, de un comprador, configuraciones de administracion de proyecto, almacenar los datos de trabajo del proyecto de transacciones relacionados con el trabajo del proyecto a ser realizado para el comprador por un proveedor, recibir del comprador, la configuracion de los registros de declaracion del trabajo (SOW) del proyecto, procesar un cambio de proyecto en el conjunto de registros del plan/alcance del comprador, procesar un cambio de proyecto en el conjunto de registro de plan/alcance del proveedor, y crear un cambio de proyecto integrado en el conjunto de registros de plan/alcance usando el conjunto de registros del comparador y el conjunto de registros del proveedor.

Description

CAMBIO DE TRABAJO DE PROYECTO EN EL SISTEMA. Y EL MÉTODO DE SINERGIA DE INFORMACIÓN ADMINISTRATIVA Y DE NEGOCIOS EN EL PLAN/ALCANCE ANTECEDENTES DE LA INVENCIÓN Campo Técnico de la Invención La presente invención se refiere a un sistema computarizado y un método para facilitar electrónicamente la administración de empresas, el procesamiento de datos, la colaboración y administración del flujo de trabajo con relación a cambios en el plan o el alcance pertinentes al trabajo del proyecto. Descripción de la Técnica Relacionada La cotización y la administración subsecuente del trabajo de proyectos puede ser un proceso extremadamente complejo aun cuando todas las actividades de la declaración del trabajo (SOW) y de la planeación del proyecto proceden como se programóó originalmente. A menudo, sin embargo, hay retardos y/o abatimientos del programa que representan cambios en el plan (CIP) que necesitan actividades administrativas. Además, algunas veces existe una necesidad por actividades de cambios importantes en el alcance (CIS) que se definen por el comienzo de un proyecto. Estas actividades de CIP y CIS pueden tener impactos significativos no sólo en las funciones de planeación del proyecto, sino en las adquisiciones, la administración del proveedor, la contabilidad, el embarque y recepción, y en algunos casos en la empresa completa. Estas actividades de CIP y CIS pueden tener impactos amplios para los proyectos, tales como, pero no limitados a, los Costos/Presupuestos del Proyecto, la Duración/planificación del proyecto, los Entregables/Resultados del proyecto, la Declaración de Trabajo del Proyecto, la Utilización de los Proveedores del Proyecto, la Disponibilidad de Recursos Humanos del Proyecto, el Suministro de los Equipos del Proyecto, los Términos y Condiciones de los Contratos, y la Liberación de Pagos a los Proveedores. Por lo tanto existe una necesidad en cuanto a un sistema y un método por medio de los cuales se puedan definir, administrar, y manejar estas actividades de CIP y CIS dentro de un ambiente de procesamiento de aplicación individual, proporcionado por ello visibilidad, apoyo de decisiones, capacidad de procesamiento de datos administrativos, y sinergia en todas las partes impactadas del trabajo de proyecto que tratan con los elementos del ciclo de vida del trabajo de proyecto de: Administración de Licitaciones, Procesamiento de Ordenes de Compra, Administración de Recursos Humanos, Administración de Activos, Aprovisionamiento de la SOW, Procesamiento de emisión de comprobantes, Aseguramiento de la Calidad, Administración de Proveedores, Embarque/Recepción, Preparación de Presupuestos, Contabilidad, Auditorias y otros roles funcionales específicos que las empresas necesitan implementar en su ambiente de trabajo cooperativo . BREVE DESCRIPCIÓN DE LA INVENCIÓN Un método de gestión administrativa de proyectos-trabajo incluye recibir de un cliente o comprador, configuraciones de administración del proyecto, almacenar los datos de trabajo transaccionales del proyecto, relativos al trabajo del proyecto a ser llevado a cabo para el cliente o comprador por un proveedor, recibir del cliente o comprador, la configuración de los registros de la declaración de trabajo del proyecto (SOW) , procesar un cambio del proyecto en el conjunto de registros del plan/alcance del cliente o comprador, procesar un cambio del proyecto en el conjunto de registros del plan/alcance del proveedor y crear un cambio del proyecto integrado en el conjunto de registros del plan/alcance usando el conjunto de registros del cliente o comprador y el conjunto de registros del proveedor. Un método de creación de registros del portafolios del proyecto incluye crear un registro del grupo de proyectos adaptado para almacenar los atributos del grupo de proyectos, la organización del cliente o comprador, y los datos de responsabilidad del propietario del negocio, crear al menos un registro principal del proyecto, adaptado para almacenar los datos del proyecto del cliente o comprador, almacenar una asociación entre el registro del grupo del proyecto y el al menos un registro principal del proyecto, almacenar las relaciones de dependencia aplicables entre el al menos un registró principal del proyecto, y almacenar los datos de organización y propiedad del negocio del cliente o comprador por defecto, aplicables al grupo de proyecto. Un método para configurar los registros de entregables del proyecto incluye asociar los rubros de linea de la orden de compra de la actividad del trabajo del proyecto no entregables con al menos un rubro de linea entregable de la orden de compra de un registro de entregables de la orden de compra, especificar los datos de atributos relativos al registro de entregables de la orden de compra, crear al menos un registro de formación de fases de trabajo del proyecto, especificar los datos de atributos relativos a al menos un registro de formación de fases del proyecto, configurar las dependencias de los registros de entregables de la orden de compra, y configurar las afiliaciones de los registros de entregables de la orden de compra con los registros de datos principales . Un método para evaluar un cambio en el plan/alcance del proyecto incluye llevar a cabo un análisis de dependencias de entregables del proyecto y de afiliación de los registros principales en respuesta a la disposición del cliente o comprador de comprobantes de recibo del trabajo del proyecto presentados por el proveedor, identificar los registros de entregables de la orden de compra que están fuera de cumplimiento con relación a una fecha de terminación programada, recibir la selección de al menos un registro de entregables fuera de cumplimiento, generar una sesión de comunicaciones en riesgo del proyecto, transmitir un paquete de comunicaciones en riesgo del proyecto, recibir una respuesta al paquete de comunicaciones en riesgo del proyecto, y procesar la respuesta del paquete de comunicaciones en riesgo del proyecto. Un método de procesamiento de un cambio en el plan/alcance del proyecto incluye crear un paquete de aceptación del cambio en el plan/alcance del proyecto, transmitir el paquete de aceptación del cambio en el plan/alcance del proyecto, procesar el paquete transmitido de aceptación del cambio en el plan/alcance del proyecto, y proporcionar el paquete transmitido a la terminación, y proporcionar el paquete de aceptación del cambio en el plan/alcance del proyecto transmitido, completado. Un método para crear un conjunto integrado de registros del cambio en el plan/alcance del proyecto, incluye crear al menos una orden de cambio en el plan/alcance del proyecto, procesar la al menos una orden de cambio en el plan/alcance del proyecto, procesar al menos un registro de datos principal en respuesta a la aprobación de la al menos una orden de cambio, del cambio en el plan/alcance del proyecto, y actualizar al menos un registro principal de los datos procesados . BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención descrita se describirá con referencia a los dibujos anexos, los cuales muestran las modalidades de muestra importantes de la invención, y los cuales se incorporan en la especificacion.de la misma como referencia, en donde: La FIG. 1 es una vista funcional de nivel superior del proceso de licitación de trabajo del proyecto involucrado en la presente invención; la FIG. 2A es un diagrama de red del sistema computarizado de la presente invención; la FIG. 2B es un diagrama de red alternativo del sistema computarizado de la presente invención, implementado en la red del cliente o comprador; las FIGs. 3A y 3B ilustran la arquitectura fisica de la red del sistema computarizado de la presente invención; las FIGs. 4A-4D son páginas de red de inicio asociadas con cada uno de los módulos de usuario mostrados en las FIGs. 2A y 2B; la FIG. 5 es un diagrama de flujo que ilustra los pasos ejemplificantes para participar en un proceso de licitación de trabajo del proyecto, de acuerdo con las modalidades de la presente invención; la FIG. 6 ilustra la facilitación electrónica de un proceso de calificación de proveedores o vendedores para definir el tipo de trabajo del proyecto que un proveedor o vendedor proporciona y/o que un cliente o comprador requiere y para que los clientes califiquen a los proveedores o vendedores, de acuerdo con las modalidades de la presente invención; la FIG. 7 es un diagrama de flujo que ilustra los pasos ejemplificantes para que un cliente o comprador califique a los proveedores o vendedores, de acuerdo con las modalidades de la presente invención; la FIG. 8 ilustra el procesamiento de la información de muestra involucrado al responder a una solicitud de licitación y los varios papeles del usuario responsable por el procesamiento de la información; la FIG. 9 es un diagrama de flujo que ilustra los pasos ejemplificantes para definir y asignar los varios recursos involucrados el en proceso de trabajo del proyecto, de acuerdo con las modalidades de la presente invención; la FIG. 10 es una vista de la tabla de base de datos que ilustra la definición y la asignación de los papeles del usuario, de acuerdo con las modalidades de la presente invención; la FIG. 11 es una captura de imagen en pantalla de la asignación de recursos a los papeles de usuario; la FIG. 12 es un diagrama de flujo que ilustra los pasos ejemplificantes para definir y asignar los papeles de usuario durante una licitación o proyecto de transacción, de acuerdo con las modalidades de la presente invención; las FIGs. 13A y 13B son diagramas de flujo que ilustran los pasos ejemplificantes para manejar el flujo de trabajo perteneciente a una licitación o proyecto de transacción con base en la funciones del usuario, de acuerdo con las modalidades de la presente invención; la FIG. 14 es un diagrama de flujo que ilustra los pasos ejemplificantes para modificar las asignaciones de funciones de usuario, de acuerdo con las modalidades de la presente invención; la FIG. 15 es un diagrama de flujo de datos que ilustra una herramienta de creación de plantillas de licitación y una herramienta de creación de solicitudes de licitación para generar una solicitud de licitación para un proyecto particular, de acuerdo con las modalidades de la presente invención; las FIGs. 16A-16D son diagramas de flujo que ilustran los pasos ejemplificantes para crear una plantilla de licitación, una solicitud de licitación a partir de la plantilla de licitación y una respuesta a la licitación a partir de la solicitud de licitación; la FIG. 17 es la vista de una tabla de base de datos que ilustra una lista jerárquica de los rubros de licitación a partir de la cual se pueden crear plantillas de licitación; la FIG. 18 es un diagrama de flujo que ilustra los pasos ejemplificantes para acceder a la lista jerárquica de rubros de la licitación para crear una plantilla de licitación; la FIG. 19 es una captura de imagen de pantalla que ilustra la creación de una plantilla de licitación; la FIG. 20 es un diagrama de flujo que ilustra los pasos ejemplificantes para generar una solicitud de licitación utilizando una plantilla de licitación, de acuerdo con las modalidades de la presente invención; las FIGs. 21-22 son capturas de imagen de pantalla que ilustran varios tipos de rubros de licitación asociados con la plantilla de licitación particular, que pueden ser seleccionados para incluirlos en una licitación del tipo de la plantilla de propuestas; la FIG. 23 es un diagrama de flujo que ilustra los pasos ejemplificantes para administrar la comunicación de una solicitud de licitación a los proveedores o vendedores calificados; la FIG. 24 es una captura de imagen de pantalla que ilustra la selección de los proveedores o vendedores calificados para recibir la solicitud de licitación; la FIG. 25 es un diagrama de flujo que ilustra los pasos ejemplificantes en el proceso de respuesta de una licitación del proveedor o vendedor, de acuerdo con las modalidades de la presente invención; las FIGs. 26-28 son capturas de imagen de pantalla que ilustran el proceso de respuesta a la licitación del proveedor o vendedor; la FIG. 29 es la vista de una tabla de base de datos que ilustra la interrelación entre la solicitud de licitaciones y los datos de respuesta a las licitaciones del proveedor o vendedor, de acuerdo con las modalidades de la presente invención; la FIG. 30 es una captura de imagen de pantalla que ilustra las varias caracteristicas de procesamiento de licitaciones proporcionadas a un cliente o comprador; la FIG. 31 es un diagrama de flujo de datos que ilustra la facilitación electrónica de calificación de respuestas a las licitaciones del proveedor o vendedor, de acuerdo con las modalidades de la presente invención; las FIGs. 32 y 33 son diagramas de flujo que ilustran los pasos ejemplificantes para calificar las respuestas a las licitaciones del proveedor, de acuerdo con las modalidades de la presente invención; las FIGs. 34A-34E son capturas de imagen de pantalla que ilustran un proceso de calificación de respuestas de muestra a las licitaciones; la FIG. 35 constituye vistas de tablas de bases de datos que ilustran la interrelación entre la solicitud de licitaciones, las respuestas a las licitaciones de los proveedores y la calificación de las respuestas de licitación de los proveedores, de acuerdo con las modalidades de la presente invención; la FIG. 36 es un diagrama de flujo que ilustra un proceso de re-cotización del proveedor o vendedor con base en la calificación de la respuesta a la licitación del proveedor o vendedor, de acuerdo con las modalidades de la presente invención; la FIG. 37 es un diagrama de flujo que ilustra los pasos ejemplificantes en un proceso de organización de la administración del proyecto, en el cual el proyecto se otorga a un proveedor o vendedor y los términos y las condiciones del proyecto se finalizan y se ingresan en el sistema computarizado para rastrear los eventos importantes y los entregables, de acuerdo con las modalidades de la presente invención; la FIG. 38 es un diagrama de flujo que ilustra los pasos ejemplificantes para la aprobación de los recursos asignados a un proyecto, de acuerdo con las modalidades de la presente invención; la FIG. 39A es una captura de imagen de pantalla que ilustra las caracteristicas ejemplificantes de administración de proyectos del cliente o comprador; la FIG. 39B es una captura de imagen de oantalla que ilustra las caracteristicas ejemplificantes de la administración de proyectos del proveedor o vendedor; la FIG. 40A es una captura de imagen de pantalla que ilustra una interfaz para ingresar la información ejemplificante de cobro de impuestos del proyecto; la FIG. 40B es una captura de imagen de pantalla que ilustra la información de requisición ejemplificante que incluye la información de cobro de impuestos del proyecto; la FIG. 40C es un diagrama de flujo que ilustra los pasos ejemplificantes para ingresar y procesar la información de cobro de impuestos del proyecto; la FIG. 41 es la vista de una tabla de la base de datos que ilustra los varios componentes de administración del proyecto manejados por el sistema computarizado de la presente invención; la FIG. 42 es una captura de imagen de pantalla que ilustra los tipos de asuntos de responsabilidad u obligación que pueden ser manejados por el sistema computarizado de la presente invención; la FIG. 43 es un diagrama de flujo que ilustra los pasos ejemplificantes para ingresar el tiempo del contratista para un proyecto, de acuerdo con las modalidades de la presente invención; las FIGs. 44-46 son capturas de imagen de pantalla que ilustran un proceso de registro del tiempo de muestra; la FIG. 47 es la vista de una tabla de base de datos que ilustra el rastreo de los entregables y la emisión de comprobantes del proyecto, de acuerdo con las modalidades de la presente invención; la FIG. 48 ilustra la facilitación electrónica de un proceso de emisión de comprobantes de pago para enviar y aprobar comprobantes de pago y crear un comprobantes de pago, de acuerdo con las modalidades de la presente invención; la FIG. 49 es un diagrama de flujo que ilustra un proceso de pago con comprobante, de acuerdo con las modalidades de la presente invención; la FIG. 50 es la vista de una tabla de base de datos que ilustra la generación de comprobantes que se pueden pagar, de acuerdo con las modalidades de la presente invención; la FIG. 51 es una captura de imagen de pantalla que ilustra los datos financieros del proyecto; la FIG. 52 es un diagrama de flujo que ilustra el intercambio de información entre el cliente o comprador, el proveedor o vendedor y el sistema para facilitar el análisis de la información; la FIG. 53 ilustra la funcionalidad ejemplificante para ingresar los datos de realización del proyecto relacionados con la realización de los proyectos en el sistema, de acuerdo con las modalidades de la presente invención; las FIGs. 54-56 son diagramas de flujo que ilustran los pasos ejemplificantes para ingresar los datos de realización del proyecte- la FIG. 57 es la vista de una tabla de base de datos que ilustra el almacenamiento de los datos de realización del proyecto, de acuerdo con las modalidades de la presente invención; la FIG. 58 ilustra los datos ejemplificantes relativos a las transacciones relacionadas con el proceso de licitación/proyecto almacenados en el sistema de base de datos de la presente invención; la FIG. 59 ilustra una transferencia ejemplificante de los datos transaccionales, desde varias bases de datos de clientes o compradores a una base de datos central; la FIG. 60 ilustra la facilitación electrónica de análisis y presentación de reportes de los datos transaccionales, de acuerdo con las modalidades de la presente invención; las FIGs. 61-67 son diagramas de flujo que ilustran los pasos ejemplificantes para analizar los datos transaccionales y proporcionar datos analíticos, de acuerdo con las modalidades de la presente invención; la FIG. 68 ilustra la facilitación electrónica de un proceso de filtrado para filtrar los datos transaccionales para proporcionar los datos analíticos relacionados con los datos relativos a los datos trasnacionales filtrados, de acuerdo con las modalidades de la presente invención; la FIG. 69 es un diagrama de flujo que ilustra los pasos ejemplificantes para filtrar los datos transaccionales y generar datos analíticos a partir de los datos transaccionales filtrados, de acuerdo con las modalidades de la presente invención; la FIG. 70 es una captura de imagen de pantalla que ilustra los tipos ejemplificantes de reportes del proyecto para generar y desplegar los datos analíticos; las FIGs. 71-88 son capturas de imagen de pantalla que ilustran vistas ejemplificantes de reportes del proyecto, cada una que contiene datos analíticos; la FIG. 89 es una vista de una dinámica compleja de negocios empresariales asociada con el trabajo del proyecto y los cambios aplicables a los planes y el alcance; la FIG. 90 es un diagrama que representa un ambiente de procesamiento de aplicación de negocios; la FIG. 91 es un diagrama de flujo que ilustra los pasos ejemplificantes para participar en un proceso de gestión administrativa del trabajo del proyéctela FIG. 92 es un diagrama de flujo que ilustra los pasos ejemplificantes para participar en la solución PCIP/S sin dependencia de la funcionalidad de procuración necesaria; la FIG. 93 es un diagrama de flujo de proceso que representa una metodología de negocios PCIP/S global empleada en varias modalidades de la invención; la FIG. 94A es un diagrama de flujo de proceso que representa la creación de un registro del grupo de proyéctela FIG. 94B es un diagrama de flujo de proceso que representa la creación de un registro principal del proyecto; la FIG. 95A es un diagrama de flujo de proceso que representa la creación de un registro del grupo de presupuestos; la FIG. 95B es un diagrama de flujo de proceso que representa la creación de un registro principal de presupuestos; la FIG. 96A es un diagrama de flujo de proceso que representa la creación de un registro del grupo de activos; la FIG. 96B es un diagrama de flujo de proceso que representa la creación de un registro principal de activos; la FIG. 97 es un diagrama de flujo de proceso que representa la creación de un registro principal de contratos; la FIG. 98 es un diagrama de flujo de proceso que representa la creación de un registro de eventos de negocios; la FIG. 99 es un diagrama de flujo de proceso que representa la asignación de un registro principal del proyecto a los otros componentes de datos principales; la FIG. 100 ilustra una interfaz de usuario de la página principal de administración ejemplificante del proyecto para un usuario cliente o comprador; la FIG. 101 ilustra un esquema de base de datos que permite el esquema de base de datos que soporta actividades de adquisición, almacenamiento y configuración, de datos de pre-adquisición; la FIG. 102 es un flujo de trabajo de proceso modificado con el cual tiene lugar la integración del registro principal del proyecto al proceso de licitación RFx; la FIG. 103 es un esquema modificado de la base de datos que soporta la integración del registro principal del proyecto a los datos de transacciones de trabajo del proyecto; la FIG. 104 es un diagrama de una dinámica de declaración de trabajo (SOW) en el contexto de los principios de la invención; la FIG. 105 es una página de red principal de proyectos ejemplificante del usuario cliente o comprador accedida desde la página principal de administración de proyectos via la navegación del usuario y la selección del registro; la FIG. 106 es un diagrama de flujo de trabajo del proceso ejemplificante que representa la afiliación del trabajo del proyecto con los registros de entregables/SOW; la FIG. 107 es un diagrama de flujo de proceso ejemplificante que representa la creación de registros de formación de fases del proyecto; la FIG. 108 es un diagrama de flujo de proceso ejemplificante que representa la afiliación/asignación de los registros SOW de la orden de compra con los registros de formación de fases del proyecto; la FIG. 109 es un diagrama de flujo de proceso ejemplificante que representa la afiliación de los registros SOW con los registros SOW y la configuración de la dependencia; la FIG. 110 es un diagrama de flujo de proceso ejemplificante que representa la afiliación de los registros de SOW con los registros de presupuestos; la FIG. 111 es un diagrama de flujo de proceso ejemplificante que representa la afiliación de los registros de SOW con los registros de activos; la FIG. 112 es un diagrama de flujo de proceso ejemplificante que representa la afiliación de los registros de SOW con los registros de contratos; la FIG. 113 es un diagrama de flujo de proceso ejemplificante que representa la afiliación de los registros de SOW con los registros de eventos de negocios; la FIG. 114 es una página de red de interfaz de usuario ejemplificante que representa un resumen de reporte para los grupos del proyecto y los registros principales del proyecto; la FIG. 115 es un esquema de base de datos ejemplificante que soporta cía onfiguración de los registros SOW; la FIG. 116 es un diagrama de flujo de proceso ejemplificante por medio del cual se usan los datos de procesamiento y rastreo de datos transaccionales de trabajo del proyecto para la transmisión de reportes pertinentes a los registros de datos principales SOW y afiliados dependientes en riesgo y los registros de datos principales afiliados; las FIGs. 117-119 son diagramas de flujo de proceso ejemplificantes que representan una sesión de comunicaciones de riesgos PCIP/S; la FIG. 120 es un esquema de base de datos ejemplificante que soporta sesines de comunicaciones de riesgo del PCIP/S; las FIGs. 212-122 son diagramas de flujo de trabajo ejemplificantes del proceso que representan un paquete de aceptación del proveedor; y la FIG. 123 es una vista expandida de la Fig. 120 a la cual se ha integrado el esquema de base de datos de soporte para el paquete de aceptación del proveedor de PCIP/S. la FIG. 124 ilustra un flujo de proceso de la sesión de aprobación e integración de registros PCIP/S. BREVE DESCRIPCIÓN DE LAS TABLAS Además de las Tablas 1-112 de base de datos, varias modalidades de la invención se describirán con referencia a las tablas de bases de datos anexas, en donde: La Tabla 113 es una tabla de almacenamiento ejemplificante que aloja la identidad y los datos de negocios generales para los Grupos del Proyecto utilizados por una Entidad cliente o Comprador; la Tabla 114 es una tabla de almacenamiento ejemplificante que almacena la identidad y los datos de negocios generales para los Registros Principales del Proyecto utilizados por una Entidad Cliente o Comprador; la tabla 114A es una tabla de almacenamiento ejemplificante que aloja las relaciones entre los proyectos contenidos en un Grupo de Proyectos; la Tabla 115 es una tabla de almacemamiento ejemplificante que aloja los valores respectivos usados para definir las relaciones entre los Proyectos en un Grupo de Proyectos; la tabla 116 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos básicos aplicables a los Centros de Costos, también conocidos como Departamentos, utilizados en una Entidad Cliente o comprador; la Tabla 117 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los Centros de Costos y los Proyectos; la Tabla 118 es una tabla de almacenamiento ejemplificante que aloja la identidad y los datos de negocios generales para los Grupos de Presupuestos utilizados por una Entidad Cliente o comprador; la tabla 119 es una tabla de almacenamiento ejemplificante que aloja la identidad y los datos de negocios generales para los Registros Principales de Presupuestos utilizados por una Entidad Cliente o Comprador; la tabla 120 es una tabla de almacenamiento ejemplificante que aloja la relación de afiliación entre los Proyectos y los Presupuestos; loa tabla 121 es una tabla de almacenamiento ejemplificante que aloja la identidad de, y los datos de negocios generales para los Eventos de Negocios utilizados por una Entidad Cliente o Compradora; la tabla 122 es una tabla de almacenamiento ejemplificante que aloja la relación de afiliación entre los Proyectos y los Eventos de Negocios la tabla 123 es una tabla de almacenamiento ejemplificante que aloja la identidad de, y los datos de negocios generales para los registros de Contratos utilizados por una Entidad Cliente o Compradora; la tabla 124 es una tabla de almacenamiento ejemplificante que aloja la relación de afiliación entre los Proyectos y los Contratos; la tabla 125 es una tabla de almacenamiento ejemplificante que aloja la identidad de, y los datos de negocios generales para los Grupos de Activos utilizados por una Entidad Cliente o Compradora; la tabla 126 es una tabla de almacenamiento ejemplificante que aloja la identidad de, y los datos de negocios generales para los Registros Principales de Activos utilizados por una Entidad Cliente o Compradora; la tabla 127 es una tabla de almacenamiento ejemplificante que aloja la relación de afiliación entre los Proyectos y los Activos; la tabla 128 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los Proyectos y las Licitaciones de RFx; la tabla 129 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los Proyectos y las Requisiciones de Ordenes de Compra; la tabla 130 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos asociados con una Orden de Compra del Proveedor; la tabla 131 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos básicos asociados con una Orden de Compra del Cliente o Comprador; la tabla 132 es una tabla de almacenamiento ejemplificante que aloja que aloja la identidad y los atributos básicos asociados con una Linea de Orden de Compra del Cliente o Comprador; la tabla 133 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos asociados con las actividades de trabajo del proyecto contenidas en una Linea de Orden de Compra del Cliente o Comprador; la tabla 134 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos asociados con un registro de Declaración de Trabajo (SOW) PO del Cliente; la tabla 135 es una tabla de alojamiento ejemplificante que aloja la relación de asignación entre las actividades de trabajo del proyecto contenidas en las Ordenes de Compra y los registros de SOW; la tabla 136 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos asociados con una registro de formación de fases del Proyecte- la tabla 137 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los registros de formación de fases del Proyecto y los registros de SOW; la tabla 138 es una tabla de almacenamiento ejemplificante que aloja las relaciones de dependencia aplicables entre los registros de SOW; la tabla 139 es una tabla de almacenamiento ejemplificante que aloja los tipos de dependencia utilizados de los valores de SOW con los registros de SOW; la tabla 140 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los registros de SOW y los Presupuestos; la tabla 141 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los registros de SOW y los Activos; la tabla 142 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los registros de SOW y los Contratos; la tabla 143 es una tabla de almacenamiento ejemplificante que aloja la relación de asignación entre los registros de SOW y los Eventos de Negocios; la tabla 144 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos asociados con una Sesión de Riesgo de PCIP/S del Cliente o Comprador; la tabla 145 es una tabla de almacenamiento ejemplificante que aloja los valores aplicables a los Códigos de Estado de las Sesiones de Riesgo de PCIP/S utilizados; la tabla 146 es una tabla de almacenamiento ejemplificante que aloja los valores aplicables a los Códigos de Tipos de Sesiones de Riesgo de PCIP/S utilizados; la tabla 147 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos aplicables a los registros de SOW contenidos en una sesión de PCIP/S; la tabla 148 es una tabla de almacenamiento ejemplificante que aloja los valores aplicables a los códigos de estado de las respuestas del Usuario Cliente o Comprador durante una sesión de PICP/S; la tabla 149 es una tabla de almacenamiento ejemplificante que aloja las modificaciones de las condiciones o de los datos variables hechas a los registros de actividad de ordenes de compra del trabajo del proyecto durante una sesión de PICP/S; la tabla 150 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos aplicables a las nuevas actividades de trabajo de proyecto creadas durante una sesión de PICP/S; la tabla 151 es una tabla de almacenamiento ejemplificante que aloja los valores utilizados que definen los tipos de modificación del campo de datos variables de actividades del trabajo del proyecto; la tabla 152 es una tabla de almacenamiento ejemplificante que aloja los valores utilizados que definen las acciones de modificación del campo de datos variables; la tabla 153 es una tabla de almacenamiento ejemplificante que aloja las modificaciones de datos variables hechas a los registros de Datos Principales durante una sesión de PICP/S; la tabla 154 es una tabla de almacenamiento ejemplificante que aloja los valores utilizados que definen los tipos de modificaciones del campo de datos variables de los Datos Principales; la tabla 155 es una tabla de almacenamiento ejemplificante que aloja los valores utilizados que definen las acciones de modificación del campo de datos variable de los Datos Principales; la tabla 156 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos asociados con una Sesión de Paquete de Aceptación del Proveedor PCIP/S del Cliente; la tabla 157 es una tabla de almacenamiento ejemplificante que aloja los valores utilizados aplicables a los Códigos de Estado de la Sesión del Paquete de Aceptación del Proveedor PCIP/S del Cliente; la tabla 158 es una tabla de almacenamiento ejemplificante que aloja la identidad y los atributos aplicables a un registro de Trasmisión/Envió postal del Proveedor afiliado con una Sesión del Paquete de Aceptación del Proveedor de PCIP/S; la tabla 159 es una tabla de almacenamiento ejemplificante que aloja los valores utilizados aplicables a los Códigos de Estado de Respuesta de la Sesión del Paquete de Aceptación del Proveedor PCIP/S; la tabla 160 es una tabla de almacenamiento ejemplificante que aloja las respuestas de verificación de datos y de evaluación del cobro de impuestos pertinentes a los registros procesados durante una Sesión del Paquete de Aceptación del Proveedor de PCIP/S; y La tabla 161 es una tabla de almacenamiento ejemplificante que aloja las respuestas de provisión de datos, verificación de datos y evaluación del cobro de impuestos del Proveedor, pertinentes a los registros de actividades nuevas procesados durante una sesión del Paquete de Aceptación del Proveedor de PCIP/S. DESCRIPCIÓN DETALLADA DE LAS MODALIDADES PREFERIDAS Las varias enseñanzas novedosas de la presente solicitud se describirán con referencia particular a las modalidades ejemplificantes. Sin embargo, se debe entender que estas modalidades proporcionan sólo unos cuantos ejemplos de los muchos usos ventajosos de las enseñanzas novedosas de la misma. En general, las declaraciones hechas en la especificación de la presente solicitud no delimitan necesariamente ninguna de las varias invenciones reclamadas.

Además, algunas declaraciones se pueden aplicar a algunas caracteristicas inventivas, pero no a otras. De acuerdo con las modalidades de la presente invención, un proveedor o vendedor es cualquier proveedor de bienes y/o servicios, un cliente o comprador es cualquier comprador de los bienes y/o servicios, un contratista es un recurso empleado por un proveedor o vendedor para el trabajo proyectado y un administrador en un administrador externo del sistema o el administración del proyecto empleado por el cliente o comprador. Los clientes o compradores pueden solicitar licitaciones de los vendedores por una mercancía y/o servicio particular (denominado de aqui en adelante como un proyecto) en una forma especificada por el cliente o comprador usando una solicitud de licitación generada a partir de una lista pre-establecida de rubros de la licitación relacionados con el tipo de proyecto. Por lo tanto, las respuestas a la licitación enviadas por los clientes o vendedores tienen todas la misma forma, lo que permite la evaluación eficiente y efectiva de las respuestas de licitación. Las modalidades de la presente invención combinan además el proceso de licitación con la administración del proyecto para permitir que el cliente o comprador, el proveedor o vendedor, el contratista y el administrador rastreen la realización del proyecto después que se adjudica la licitación. Un sistema y un método habilitados por computadora de acuerdo con los principios de la invención se proporcionan para integrar las actividades del trabajo del proyecto con otras organizaciones de negocios y de personal de la empresa aun cuando las organizaciones de negocios no sean participantes en el proyecto en si. Se proporciona una funcionalidad de gestión administrativa de cambios en el plan/alcance del proyecto (PCIP/S), la cual permite que las empresas limiten los riesgos aplicables a los cambios en el plan/alcance y optimicen el procesamiento de datos y las tareas de administración de negocios a través del modelado de dependencias de la Declaración De Trabajo (SOW) y el procesamiento del flujo de trabajo colaborativo. Una modalidad tipica incluye procesos para los siguientes: 1) la configuración de la administración de proyectos; 2) adquisición y almacenamiento de los datos transaccionales del trabajo del proyecto; 3) configuración de los registros de SOW; 4) modelado del impacto del PCIP/S; 5) sesión de comunicación de riesgos; 6) sesión del paquete de aceptación del PCIP/S; y 7) administración de la modificación de registros de PCIP/S. Varios procesos de la modalidad tipica pueden ser soportados por medio de los siguientes componentes de aplicación y funciones; a) un esquema de gestión administrativa del proyecto y una herramienta de aplicación que permitan a la entidad cliente o compradora llevar a cabo uno o más de los siguientes : 1) crear registros de los grupos del proyecto; 2) crear registros principales del proyecto; 3) asociar los registros principales del proyecto con un grupo del proyecto; 4) definir las relaciones entre los proyectos dentro de un grupo de proyecto (una jerarquía del proyecto) ; 5) asociar los varios atributos de negocios tanto con los grupos de proyectos y los proyectos; 6) crear registros de SOW; 7) asociar los registros de SOW con los proyectos; 8) asociar los registros de SOW mutuamente; 9) definir las relaciones en las SOW asociadas; 10) crear registros relativos a los eventos de negocios dentro de la entidad de cliente o comprador; 11) asociar los registros de eventos de negocios con los proyectos; 12) asociar los registros de eventos de negocios con las SOW; 13) crear registros del grupo de presupuestos; 14) crear registros principales de los presupuestos; 15) asociar los registros principales de los presupuestos con los registros del grupo de presupuestos; 16) asociar los registros principales de presupuestos con los registros del proyecto; 17) asociar los registros principales de presupuestos con los registros de SOW; 18) crear registros de contratos; 19) asociar los registros de contratos con los registros de proyectos; 20) asociar los registros de contratos con los registros de SOW; 21) crear registros del grupo de activos; 22) crear registros principales de activos; 23) asociar los registros principales de activos con los registros del grupo de activos; y 24) asociar los registros principales de activos con los registros de SOW. b) una funcionalidad de aplicación que vincule el esquema de gestión administrativa del proyecto con los procesos del ciclo de vida de solución del trabajo del proyecto via un sub-módulo de SOW; 1) Licitaciones de RFx, respuestas de licitación, otorgamiento de licitaciones; 2) requisiciones de compra (elementos de la SOW) ; 3) ordenes de compra (elementos de la SOW); 4) comprobantes (solicitudes del proveedor para hacer que el cliente apruebe/verifique que el (los) elemento (s) de la SOW que han sido completados); 5) facturación (detalles del comprobante extraídos sistemáticamente, aplicables a los comprobantes aprobados por la entidad cliente o compradora); 6) pagos; y 7) envió de reportes. c) Un esquema de gestión administrativa y una herramienta de aplicación que permitan a una entidad cliente o compradora: 1) administrar/configurar los registros en el módulo de gestión administrativa de proyectos; 2) visualizar la función de transmisión de identificación de dependencia/envio de reportes para los proyectos relacionados/dependientes, los elementos de las SOW relacionados/dependientes, y los registros de negocios relacionados/dependientes; 3) seleccionar registros de SOW específicos y modificar la condición o los datos de atributos de los registros, tales como, por ejemplo, un estado o fecha de terminación prevista, para generar un reporte de riesgo de diagnostico del sistema que indica, con base en la configuración previa del usuario, el impacto a los registros de negocios relacionados, la transmisión del reporte de riesgo de diagnóstico que proporciona típicamente vistas en los entregables impactados, unidades de servicio, mercancias/embarques, formación de fases del proyecto, asignación de recursos humanos, planificación de ordenes de compra/flujo de efectivo, presupuestos/valores devengados, eventos de negocios relacionados, gestión de activos, proveedores, y usuarios impactados; 4) crear una sesión de comunicaciones por medio de la cual las partes con trabajo del proyecto impactado pueden ser provistas con la información aplicable a los elementos y proyectos en riesgo de la SOW, en donde las comunicaciones se pueden transmitir en, por ejemplo, modos micro o macro dependiendo de la configuración del usuario y los registros transmitidos configurados de manera tal que permitan una capacidad bidireccional de procesamiento de los datos aplicables a un elemento en riesgo de la SOW; 5) procesar el acuerdo mutuo sobre los registros de la sesión de comunicaciones en una manera tal que se actualice sistemáticamente el elemento SOW de la aplicación, la orden de compra y/o otros registros relacionados en tanto que se mantiene un historial de los registros de comunicaciones, asi como del elemento de la SOW, los registros de ordenes de compra y otros registros relacionados reemplazados; 6) iniciar sistemáticamente los cambios en el código de condición/estado, global/macro de un conjunto de registros con base en un cambio supuesto del tipo de condición/estado del registro de la SOW; 7) inicial sistemáticamente los cambios en el atributo de los registros globales/macro de un conjunto de registros, con base en un cambio supuesto del tipo de condición/estado; 8) enviar notificaciones a las partes impactadas sobre las modificaciones de actualización sistemática de los registros; 9) generar sistemáticamente un reporte que consiste de los registros de respuestas a la licitación RFx pertinentes, aplicables a un elemento en riesgo de la SOW; 10) utilizar sistemáticamente los elementos de rubros de la licitación RFx asi como los elementos de rubros de a licitación RFX para crear una nueva licitación RFx que pueda ser transmitida en tanto que se retiene un respaldo dirigido al elemento y las relaciones de la SOW original; 11) recibir, revisar y analizar sistemáticamente la respuesta de licitación del proveedor y otorgar una nueva orden de compra en tanto que se retiene un respaldo del registro de la base de datos dirigido al elemento y las relaciones de la SOW original; 12) heredar sistemáticamente por la integración de los elementos de la SOW de la orden de compra via el sub-módulo de establecimiento de trabajo, todas las asociaciones y dependencias anteriores aplicables al elemento de la SOW original/fallido en el cual se utilizaron los detalles del registro RFx para procesar un nuevo RFx; y 13) permitir una capacidad de edición/modificación por el usuario comprador o cliente para aquellos registros de la SOW que heredan la dependencias y las relaciones, a través de la herramienta administrativa de PCIP/S. Refiriéndonos ahora a las FIGURAS, la FIG. 1 es una vista funcional de nivel superior del proceso de licitación involucrado en la presente invención. Los datos 210 de la solicitud de licitación asociados con una solicitud 200 de licitación particular se proporcionan por un cliente o comprador 50 a un sistema 30 de administración de licitaciones de proyectos. El cliente o comprador puede ser un individuo, una entidad de negocios o cualquier otro tipo de cliente o comprador 50 que requiera la realización de un proyecto. Los datos 210 de la solicitud de licitación recibidos en el sistema 30 de administración de licitaciones de proyectaos están en una forma pre-designada por el cliente o comprador 50. Por ejemplo, la forma puede incluir uno o más rubros de la licitación seleccionados de una lista pre-establecida, configurable de rubros de licitación para el tipo de proyecto particular, y los datos 210 de la solicitud de licitación se pueden relacionar con uno o más de estos rubros de licitación.

Los datos 210 de la solicitud de licitación se formatean por el sistema 30 de gestión de licitaciones de proyectos y se transmiten como una solicitud 200 de licitación a uno o más proveedores o vendedores 10a... lOn para solicitar las respuestas 220 respectivas a la licitación. Por ejemplo, el proveedor o vendedor 10 puede ser un individuo 10a, una entidad 10b de negocios o cualquier otro proveedor o vendedor lOn que sea capaz de llevar a cabo el proyecto solicitado. Las respuestas 220 a la licitación se envían por los proveedores o vendedores al sistema 30 de gestión de licitaciones de proyectos para su revisión antes de transmitir las respuestas 220? calificadas al cliente o comprador 50. Por ejemplo, el sistema 30 de gestión de licitaciones de proyectos se puede pre-configurar para forzar la terminación del proveedor o vendedor de los rubros de respuesta a la licitación requeridos en un formato de datos especifico para permitir que el sistema 30 lleve a cabo algún filtrado de las respuestas 220 a la licitación del proveedor o vendedor. De esta manera, el sistema 30 puede asegurar que el cliente o comprador 50 sólo reciba las respuestas 220 a la licitación que tienen los datos necesarios para la evaluación de la licitación. De acuerdo con las modalidades de la presente invención, el sistema 30 de gestión de licitaciones de proyectos se puede implementar en un sistema 100 computarizado, como se muestra en la FIG. 2A. Un usuario 5 ingresa al sistema 100 computarizado a través de una red 40 de datos via un navegador de red. Un usuario 5 incluye cualquier persona asociada con un proveedor o vendedor 10, un cliente o comprador 50, un administrador 80 (por ejemplo, un administrador externo o contratado por el cliente o comprador) o un contratista 15 asignado a un proyecto. A manera de ejemplo. Pero sin limitación, la red 40 de datos puede ser la Red internacional o una Red interna y el navegador 20 de red puede ser cualquier navegador de red disponible o cualquier tipo de conexión de Proveedor de Servicios de Red internacional (ISP) que proporcione acceso a la red 40 de datos. Los usuarios proveedores o vendedores 5 acceden al sistema computarizado a través de un navegador 200 del proveedor o vendedor, los usuarios 5 clientes o compradores acceden al sistema computarizado via un navegador 20a del cliente o comprador, los usuarios 5 contratistas acceden al sistema computarizado via un navegador 20c del contratista y los usuarios 5 administrativos acceden al sistema computarizado a través de un navegador 20d administrativo. Los usuarios 5 acceden al sistema 100 computarizado a través de un servidor, 120 o 125, de red capaz de transmitir páginas de red al navegador 20a de proveedores o vendedores, el navegador 20b de clientes o compradores, el navegador 20c de contratistas y el navegador 20d administrativo, respectivamente.

Un servidor 120 de red de licitaciones permite que los proveedores o vendedores 10, los clientes o compradores 50, los contratistas 15 y los administradores 80 se interconecten con un sistema 150 de base de datos que mantiene los datos relativos a los proveedores o vendedores 10, los clientes o compradores 50, los contratistas 15 y los administradores 80. Los datos relacionados con cada uno de los proveedores o vendedores 10, los clientes o compradores 50, los contratistas 15 y los administradores 80 se puede almacenar en una sola base de datos 155, en varias bases de datos 155 compartidas o en bases de datos 155 separadas dentro del servidor 150 de bases de datos, para propósitos de seguridad y conveniencia, se ilustran las ultimas. Por ejemplo, el sistema 150 de base de datos se puede distribuir a través de una o más ubicaciones, dependiendo de la ubicación y la preferencia de los clientes o compradores 50, los proveedores o vendedores 10, los administradores 80 y los contratistas 15. La interfaz de usuario para los usuarios 5 proveedores o vendedores se proporciona por el servidor 120 de licitaciones a través de un módulo 115 de proveedores o vendedores. Por ejemplo, el módulo 115 de proveedores o vendedores puede alimentar los datos en las páginas de red transmitidas al navegador 20b de proveedores o vendedores usando los datos almacenados en la base de datos 155b de proveedores o vendedores particular. la interfaz de usuario para los usuarios 5 clientes o compradores se proporciona por el servidor 120 de licitaciones a través de un módulo 110 de clientes o compradores. Por ejemplo, el módulo 110 de clientes o compradores puede alimentar datos a las páginas de red transmitidas al navegador 20a de clientes o compradores, usando los datos almacenados en la base de datos 115a de clientes o compradores particular, la interfaz de usuario para los usuarios 5 contratistas se proporciona por el servidor 120 a través de un módulo 130 de contratistas. Por ejemplo, el módulo 130 de contratistas puede alimentar datos a las páginas de red transmitidas al navegador 20c de contratistas usando los datos almacenados en la base de datos 155c de contratistas. La interfaz de usuario para los usuarios 5 administrativos se proporciona por el servidor 120 de licitaciones a través de un módulo 135 administrativo. Por ejemplo, el módulo 135 administrativo puede alimentar datos a las páginas de red transmitidas al navegador 20d administrativo usando los datos almacenados en la base de datos 155d de administradores. Se debe notar quie el módulo 115 de proveedores o vendedores, el módulo 110 de clientes o compradores, el módulo 130 de contratistas y el módulo 135 administrativo pueden incluir cada uno cualquier componente fisico, componente lógico y/o soporte lógico inalterable requerido para llevar a cabo las funciones del módulo 115 de proveedores o vendedores, el módulo 110 de clientes o compradores, el módulo 130 de contratistas y el módulo administrativo 135, se puede implementar como parte del servidor 120 de licitaciones, o dentro de un servidor adicional (no se muestra) . El sistema 100 computarizado proporciona además una interfaz de usuario adicional para los usuarios 5 administrativos a través de un servidor 125 administrativo. El servidor 125 administrativo permite que los administradores se interconecten con una base de datos 160 de nivel superior que mantiene los datos relacionados con los proveedores o vendedores 10, los clientes o compradores 50, y los contratistas 15 registrados con el sistema 100 computarizado. Por ejemplo, la base de datos 160 de nivel superior puede mantener los datos 162 de calificación de los proveedores o vendedores, los datos 164 de criterios de proveedores o vendedores definidas por los clientes o compradores, y los datos 166 de re-despliegue de los contratistas. Para ingresar la información relacionada con los proveedores o vendedores 10, el servidor 125 administrativo utiliza un módulo 145 de proveedores o vendedores para transmitir las páginas de red al navegador 20d administrativo relacionadas con los proveedores o vendedores 10. Por ejemplo, el módulo 145 de proveedores o vendedores puede ingresar la información 162 de calificación de proveedores o vendedores para calificar a los proveedores o vendedores para un cliente o comprador 50 particular o para una industria particular. Del mismo modo, el servidor 125 administrativo puede transmitir al navegador 20d administrativo las páginas de red relacionadas con la información 164 de criterios de proveedores o vendedores definidos por el cliente o comprador a través de un módulo 149 de clientes o compradores con el fin de calificar a los proveedores o vendedores 10 para un cliente o comprador 50 particular, un módulo 18 de contratistas permite que los administradores 80 accedan a los datos 166 de re-despliegue de los contratistas ingresados por los contratistas 15 a través del servidor 120 de licitaciones y recuperados en la base de datos 169 de nivel superior por desde una base de datos 155 de contratistas. Los datos 166 de re-despliegue pueden incluir, por ejemplo, un indicación de la movilidad de los contratistas, áreas geográficas, habilidades de los contratistas, el pago deseado y otra información de los contratistas que se puede usar para ayudar a los administradores 80 a calificar a los proveedores o vendedores 10 para los clientes o compradores 50. En otra modalidad, como se muestra en la FIG. 2B, el sistema 100 computarizado se puede implementar solamente en la red de clientes o compradores. En la FIG. 2B, los usuarios 5 proveedores o vendedores ingresan al sistema 100 computarizado por medio de una red 40 de datos a través de un navegador 20b de proveedores o vendedores, como en- la FIG. 2A. Sin embargo, el servidor 120 en la FIG. 2B es un servidor de clientes o compradores controlado y operado por un sólo comprador. El sistema 150 de base de datos almacena sólo los datos del cliente o comprador relacionados con ese cliente o comprador particular y sólo los datos de proveedores o vendedores, contratistas y administradores pertinentes a ese comprador particular. Por ejemplo, sólo se almacenan en el sistema 150 de base de datos, los datos de calificación de proveedores o vendedores sólo para aquellos proveedores o vendedores que se califican por el cliente o comprador. Refiriéndonos ahora a la FIG. 3A, se muestra el equipo fisico de red ejemplificante para implementar el sistema 100 computarizado. Un usuario proveedor o vendedor, un usuario cliente o comprador, un usuario contratista o un usuario administrativo acceden al servidor 120 del sistema 100 computarizado conectado una computadora 60a, 60b, 60c, o 60d, respectivamente a una red 40 de datos. Cada computadora, 60a-60d puede ser, por ejemplo, una computadora personal, una computadora portátil, una computadora conectada a uyn dispositivo inalámbrico para acceso remoto a la red de datos, un dispositivo inalámbrico portátil que proporciona un navegador capaz de acceder a la red de datos u otro tipo de máquina que implemente un navegador. El servidor 120 de red puede ser, por ejemplo, un Servidor de Información para Red internacional de Microsoft (SSI). El servidor 120 de red se conecta con un sistema 150 de base de datos apropiado, dependiendo del tipo de usuario. El sistema 150 de base de datos se pueden implementar, por ejemplo, en uno o más servidores SQL. Volviendo ahora a la FIG. 3B, se muestra la funcionalidad ejemplificante implementada en el equipo de red fisica del sistema 100 computarizado. Una computadora 60 de usuario puede acceder a la red 40 de datos usando un navegador 66 de red residente en un medio 64 de almacenamiento de la computadora. Por ejemplo, el medio de almacenamiento puede ser un accionador de disco, una memoria de acceso aleatorio (RAM) , una memoria de sólo lectura (ROM) , un disco compacto, un accionador de cinta o cualquier otro tipo de medio de almacenamiento. Un procesador 62 (por ejemplo, un microprocesador o microcontrolador) dentro de la computadora 60 carga y corre el navegador 66 de red para acceder a la red 40 de datos. Tras ingresar el Localizador de Recursos Uniforme (URL) del servidor 120 en una computadora, se crea una conexión entre la computadora 60 y el servidor 120. El servidor 120 transmite las páginas 61 de red a la computadora 60 para su visualización por el usuario en un dispositivo 65 de interfaz de usuario. En una modalidad, el dispositivo 65 de interfaz de usuario es una pantalla 15 de computadora conectada a la computadora 60. Por ejemplo, una vez que el usuario ha sido validado (por ejemplo, ingresando un nombre de usuario y contraseña) , el usuario puede visualizar una o más páginas 61 de red en la pantalla 65 de la computadora, cada una que contiene indicadores para que el usuario ingrese diversa información en el sistema 100 computarizado. El usuario puede ingresar la información en la computadora 60 para su transmisión via la red 40 de datos al servidor 120 por medio de una interfaz 68 I/O y cualquier tipo de dispositivo 70 de entrada, tal como, por ejemplo, un ratón, teclado, lápiz óptico, pantalla táctil (no se muestra) o un programa de reconocimiento de voz (no se muestra) . En el servidor 120, un procesador (por ejemplo, un microprocesador o microcontrolador) carga y ejecuta las instrucciones de computadora residentes en los módulos de programa 128 almacenados en un medio 124 de almacenamiento, el cual puede ser cualquier tipo de medio de almacenamiento, como se discute arriba en conexión con el medio 64 de almacenamiento. Las instrucciones de computadora se pueden crear usando cualquier tipo de técnica de programación, incluyendo técnicas de programación orientada a objetos. Por ejemplo, los módulos 128 de programa pueden contener las instrucciones de computadora para los módulos del proveedor o vendedor, los módulos del cliente o comprador, los módulos del contratista y los módulos administrativos (mostrados en las FIGs. 2A y 2B) para alimentar los datos a las páginas 61 de red para los usuarios proveedores o vendedores, los usuarios clientes o compradores, los usuarios contratistas y los usuarios administrativos. Con base en el inicio de sesión del usuario en el servidor 120, el procesador 122 accede al módulo 128 de programa apropiado para determinar el sistema 150 de base de datos asociado con el usuario de la computadora y recupera los datos relacionados con el usuario de la computadora para alimentar los datos a las páginas 61 de red para desplegarlos en la pantalla 65 de la computadora 60. Además, los módulos 128 de programa se pueden configurar adicionalmente para almacenar los datos recibidos por el usuario de la computadora dentro del sistema 150 de base de datos. Los ejemplos de páginas 61 de red desplegadas a los usuarios clientes o compradores, los usuarios proveedores o vendedores, los usuarios contratistas y los usuarios administrativos se muestran en las FIGs. 4A-4D, respectiva. La FIG. 4A ilustra una página 61a de inicio de muestra del cliente o comprador desplegada a un usuario cliente o comprador tras el inicio de sesión y la autentificación del usuario cliente o comprador (por ejemplo, una autentificación de requerimiento y respuesta) del usuario cliente o comprador. Como se puede observar en la FIG. 44, existe un número de caracteristicas del sistema disponibles para los usuarios clientes o compradores en la página 61a de inicio del cliente o comprador. Por ejemplo, el usuario cliente o comprador puede ser proveído con enlaces para actualizar su perfil personal en el sistema, crear un RFP/RFQ (denominado aqui como una solicitud de licitaciones), administrar las solicitudes de licitaciones actuales, aprobar la respuesta de licitación de un proveedor o vendedor para otorgarle la licitación (proyecto) a un proveedor o vendedor particular, procesar un proyecto actual, visualizar las solicitudes de licitaciones históricas o acceder a un sistema de procesamiento de comprobantes para visualizar las solicitudes de rastreo de eventos relacionadas con varios proyectos, tales como tarjetas de registro de horario del contratista. Los usuarios clientes o compradores pueden permanecer además actualizados acerca las modificaciones del sistema, las instrucciones recibidas sobre como maniobrar a través del sistema y contactar a un administrador del sistema (por ejemplo, un administrador externo o un administrador empleado por el cliente o comprador) para asistencia a través de la página 61a de inicio . En la FIG. 4A, se provee además al usuario cliente o comprador con el estado actual de las licitaciones y los proyectos pendientes, en la página 61a de inicio. Sin embargo, se debe entender que las actividades actuales se pueden desplegar en páginas de red subsecuentes, en lugar de en la página 61a de inicio. Por ejemplo, se puede proveer al usuario cliente o comprador con el número de solicitudes de licitaciones abiertas (las solicitudes de licitaciones enviadas) y el número de solicitudes de licitaciones salvadas temporalmente (solicitudes de licitaciones creadas pero aun no enviada) . Al hacer click en el botón de solicitudes de licitación abiertas, el usuario cliente o comprador puede ser conectado a otra página de red desplegando una lista de las solicitudes de licitaciones abiertas con enlaces subsecuentes a las páginas de red que contienen las solicitudes de licitaciones abiertas actuales. Por lo tanto, de la página 81a de inicio del cliente o comprador, el usuario cliente o comprador puede enlazarse a cualquier información pertinente a las licitaciones o los proyectos a los cuales el cliente o comprador tiene acceso.

La FIG. 4B ilustra una página 61b de inicio de muestra del proveedor o vendedor que contiene un número de caracteristicas del sistema disponibles para los usuarios proveedores o vendedores. Por ejemplo, la página 61b de inicio del proveedor o vendedor puede proporcionar enlaces para actualizar el perfil del proveedor o vendedor (por ejemplo, los tipos de mercancías y/o servicios que proporciona el proveedor o vendedor) , responder a las solicitudes de licitaciones recibidas, procesar los proyectos o acceder a un sistema de procesamiento de coprobantes para visualizar las solicitudes de completación de eventos del proyecto existentes o procesar las nuevas solicitudes de compleción de eventos del proyecto. En la FIG. 4B, se provee al' usuario proveedor o vendedor con el estado actual de las licitaciones y los proyectos pendientes. Por ejemplo, el usuario proveedor o vendedor puede determinar el número de solicitudes de licitaciones a las cuales el proveedor o vendedor necesita responder y el número de respuestas de licitaciones salvadas temporalmente que el proveedor o vendedor no ha completado aun. De la página 61b de inicio del proveedor o vendedor, el usuario proveedor o vendedor puede enlazarse a páginas de red adicionales para completar las respuestas a las licitaciones o acceder a una solicitud de licitación recién recibida para iniciar la respuesta a la licitación del proveedor o vendedor.

La FIG. 4C ilustra una página 61a de inicio de muestra del contratista que contiene un número de caracteristicas del sistema disponibles para el contratista. Por ejemplo, la primera vez que un contratista accede a la página 61c de inicio del contratista, el usuario contratista puede ser dirigido para convenir varios acuerdos de trabajador no empleado antes de acceder a cualquier otra información en el sistema. Cada uno de los acuerdos de trabajador no empleado se puede desplegar al usuario contratista, y el usuario contratista puede ser motivado a convenir o aceptar de otra manera los términos de los acuerdos antes de continuar. Una vez que el contratista ha completado todos los acuerdos, el usuario contratista puede acceder al sistema de registro de tiempo para ingresar el horario del contratista, actualizar su perfil de habilidades o proporcionar preferencias de re-despliegue. Además, las actividades actuales asociadas con el usuario contratista también se pueden desplegar al usuario contratista en la página 61c de inicio del contratista, tales como el número de entrevistas solicitadas o entrevistas programadas para proyectos adicionales . La FIG. 4D ilustra un ilustra una página 61d de inicio de muestra del administrador que contiene un número de caracteristicas disponibles para un usuario administrativo.

Por ejemplo, el usuario administrativo puede ingresar información sobre los clientes o compradores, los proveedores o vendedores o los contratistas, enlazarse a páginas de red que contienen las solicitudes de licitaciones que necesitan ser aprobadas, aprobar una respuesta a la licitación para otorgar la licitación a una proveedor o vendedor particular, procesar un proyecto actual o acceder a un sistema de procesamiento de comprobante para visulizar las solicitudes de proveedor o vendedor/contratistas para la aprobación de las actividades del proyecto, tales como las tarjetas de registro de horarios del contratista. Además, las actividades actuales del usuario administrativo también se pueden desplegar en la página 61d de inicio del administrador. Por ejemplo, el número de solicitudes de licitaciones que esperan su aprobación, el número de nuevas solicitudes de licitaciones y el número de nuevas respuestas de los proveedores o vendedores se pueden desplegar al usuario administrativo. De la página 61d de inicio del administrador, el usuario administrativo puede enlazarse a cualquier información pertinente el procesamiento de licitaciones o a la gestión de los proyectos a los cuales el usuario administrativo tiene acceso. Por ejemplo, si el usuario administrativo es un administrador externo, el usuario administrativo puede tener acceso a las licitaciones y a los proyectos de todos los clientes o compradores y proveedores o vendedores registrados con el sistema. Sin embargo, si el usuario administrativo es un administrador empleado por el cliente o comprador, el usuario administrativo sólo puede tener acceso a las licitaciones y los proyectos asociados con el cliente o comprador particular. Los pasos ejemplificantes en el procesamiento 500 de licitaciones/proyectos manejados por el sistema de gestión de licitaciones de proyectos de la presente invención se muestran en la FIG. 5. Hay varios aspectos del procesamiento de licitaciones/proyectos que se manejan antes de cualquier solicitud de licitaciones sea transmitida (paso 505). Por ejemplo, un cliente o comprador puede desea crear una lista de proveedor o vendedor calificados para los tipos de solicitudes de licitaciones particulares, para reducir el tiempo de procesamiento durante la solicitud de licitaciones, como se describirá con más detalle abajo en conexión con las FIGs. 6 y 7. Como otro ejemplo, los clientes o compradores, proveedor o vendedor y administradores pueden desear designar al personal particulas para manejar los diferentes componentes del procesamiento de licitaciones/proyectos para el encaminamiento eficiente de los mensajes y la información durante el proceso de licitaciones/proyectos, como se describirá con más detalle abajo en conexión con las FIGs. 8-14.

Una vez que se completan todas las actividades pre-licitaciones (paso 510), un cliente o comprador puede crear una solicitud de licitación para un proyecto (paso 520) , como se describirá con más detalle abajo en conexión con las FIGs. 15-29, y enviar la solicitud de licitaciones a un administrador para su aprobación (paso 525), si es necesario, como se describirá con más detalle abajo en conexión con la FIG. 20. La mayoría de las compañías requieren la aprobación de las solicitudes de licitaciones para propósitos presupuestarios. Sin embargo, si el cliente o comprador es un individuo o un negocio pequeño, el usuario cliente o comprador que crear la solicitud de licitaciones puede no necesitar la aprobación de ninguna otra parte para enviar la solicitud de licitaciones . Una vez que se ha aprobado la solicitud de licitaciones, la solicitud de licitaciones se transmite (por ejemplo, se pone a disposición de los proveedores o vendedores via el sistema con una notificación opcional via correo electrónico) a los proveedor o vendedor calificados (paso 530), como se describirá con más detalle abajo en conexión con la FIG. 23, para solicitar una respuesta a la licitación de los proveedores o vendedores (paso 535) . Cada una de las respuestas a las licitaciones se evalúa por el comprador, como se describirá con más detalle abajo en conexión con las FIGs. 32 y 33, para determinar cual respuesta a la licitación de un proveedor o vendedor es la más calificada (paso 540) . Después que el cliente o comprador selecciona un proveedor o vendedor particular para el proyecto, el cliente o comprador y el proveedor o vendedor negocian los términos finales y las condiciones del contrato (paso 545) y estos términos y condiciones se pueden cargar en el sistema para propósitos de seguimiento del sistema (paso 550), como se describirá con más detalle abajo en conexión con la FIG. 37. Después, el proveedor o vendedor selecciona los recursos específicos (contratistas) para el proyecto, y si los términos del proyecto requieren la aprobación de los recursos por el cliente o comprador, el cliente o comprador aprueba todos los recursos asignados antes de que se efectué el proyecto (paso 555), como se describirá con más detalle abajo en conexión con la FIG. 38. Una vez que se completa toda la actividad de licitaciones (paso 515), el sistema es capas además de manejar la actividad post-licitaciones (paso 560) para dar seguimiento a la realización del proyecto y el pago de los comprobantes durante el curso del proyecto. Por ejemplo, el proveedor o vendedor y los contratistas asignados al proyecto pueden ingresar el tiempo trabajado y los costos al sistema (paso 565) para la generación de comprobantes pagables pagaderos a ser transmitidos al cliente o comprador a través del sistema, como se describirá con más detalle abajo en conexión con la FIG. 43. Tras la recepción de los comprobantes, el cliente o comprador y/o el administrador puede revisar y aprobar los comprobantes para el pago al proveedor o vendedor (paso 570 y 575), como se describirá con más detalle abajo en conexión con la FIG. 49. Otros parámetros de seguimiento del proyecto también se pueden ingresar en el sistema para dar seguimiento al desempeño del proveedor o vendedor a través del cierre del proyecto (paso 580) como se describirá con más detalle abajo en conexión con las FIGs. 39 y 40. Cada uno de los componentes principales del proceso de licitaciones/proyecto (la actividad pre-licitación, la actividad de licitación, y la actividad post-licitación) se discutirán ahora por separado de aqui en adelante. Adicionalmente, el análisis y la presentación de reportes para los datos colectados durante el proceso de licitación/proyecto se discutirán por separado de aqui en adelante . ACTIVIDAD PRE-LICITACIÓN Como se discute arriba, un cliente o comprador 50 puede desear proveedores o vendedores 10 pre-calificados para tipos de proyectos particulares para reducir la cantidad de procesamiento requerido para cada solicitud de licitación enviada. Refiriéndonos ahora a la FIG. 6, para facilitar la calificación del proveedor o vendedor por los clientes o compradores, el sistema 100 computarizado puede permitir que los clientes o compradores 50 establezcan datos 164 de criterios de proveedores o vendedores, definidos por el usuario, para los proveedores o vendedores y almacena los datos 164 de criterios de proveedores o vendedores, definidos por el usuario en la base de datos 160 de nivel superior en una lista principal 161 de clientes o compradores. El sistema 100 computarizado puede adquirir además los datos de calificaciones 162 pertinentes de los proveedores o vendedores 10 y almacena los datos 162 de calificaciones de los proveedores o vendedores en la base de datos 160 de alto nivel en una lista 163 principal de proveedores o vendedores. Por ejemplo, los datos 162 de calificaciones de proveedores o vendedores pueden especificar las mercancías y/o los servicios específicos que proporcionan los proveedores o vendedores 10 y las áreas geográficas a las cuales los proveedores o vendedores son capaces de distribuir estas mercancías y/o servicios, junto con otra información de los proveedores o vendedores, tal como el tamaño de los proveedores o vendedores, si los proveedor o vendedor tiene un seguro, si los proveedores o vendedores están certificados en ciertas industrias etc. Los datos de criterios de proveedores o vendedores definidos por el usuario pude identificar las mercancías y/o servicios específicos que el cliente o comprador 50 desea, las áreas geográficas especificas en las cuales el cliente o comprador 50 desea las mercancías y/o servicios y otras restricciones del cliente o comprador, tales como el tamaño preferido de los clientes o compradores, las necesidades de aseguramiento requisito de los proveedores o vendedores, las certificaciones requisitos de los proveedores o vendedores, etc. Con base en los datos 162 de calificación de los proveedores o vendedores y los datos 164 de criterios de los proveedores o vendedores, definidos por el usuario, el sistema 100 computarizado puede terminar cuales proveedores o vendedores 100 tienen las calificaciones requisitos para los clientes o compradores 50 y proporciona la información 170 de los proveedores o vendedores calificados (por ejemplo, el nombre, dirección, y cualquier otra información de los proveedores o vendedores que los clientes o compradores necesiten) a los clientes o compradores 50, para su revisión. Si el cliente o comprador 50 u opcionalmente el administrador 80 aprueba a un proveedor o vendedor 10, el cliente o comprador 50 puede agregar la información 170 del proveedor o vendedor a una lista 158 de proveedores o vendedores, la cual se almacena en la base de datos 155a del cliente o comprador. Además, la información 172 del proveedor o vendedor para aquellos proveedores o vendedores 10 que el cliente o comprador 50 calificó previamente, también puede ser almacenada en la lista 158 de proveedores o vendedores. Además, una copia principal de la lista 158 de proveedores o vendedores (es decir, la Lista Principal de Proveedores o vendedores para los Clientes o compradores 165) se puede almacenar en la base de datos 160 de nivel superior para propósitos de redundancia y actualización. La información 174 del comprador (por ejemplo, el nombre, dirección y otra información que el cliente o comprador acepte proporcionar) también puede ser descargada a la base de datos 155b de proveedores o vendedores para su almacenamiento en una lista 159 de clientes o compradores en esta. Además, una copia principal de la lista 159 de clientes o compradores (es decir, la Lista Principal de Compradores para los Proveedores o vendedores 167) se puede almacenar en la base 160 de datos de nivel superior para propósitos de redundancia y actualización. Sin embargo, se debe entender que si el sistema 100 computarizado se implementa solamente en la red del cliente o comprador, la base de datos 160 de nivel superior no almacenarla las copias, 165 y 167, principales, y el cliente o comprador 50 llevarla a cabo la calificación de los proveedores o vendedores usando sólo la información 172 de los proveedores o vendedores conocida por el cliente o comprador 50 o proporcionada directamente al cliente o comprador 50 por los proveedores o vendedores 10. Para una discusión completa de la calificación de los proveedores o vendedores 10 por los clientes o compradores 50 basada en los datos 162 de calificación de los proveedores o vendedores y los datos 164 de criterios de los proveedores o vendedores, definidos por el cliente o comprador, se hace referencia a la Solicitud de Patente Norteamericana, en tramite con la presente, y cedida de manera común, con número de serie 10/141,801, la cual se incorpora aqui como referencia en su totalidad. Los pasos ejemplificantes para la calificación de los proveedores o vendedores por los clientes o compradores se muestran en la FIG. 7. Una vez que se establece la información de criterios de los proveedores o vendedores, definidos por el usuario (paso 700) y se recibe la información de calificación de los proveedores o vendedores de un proveedor o vendedor (paso 710), la información de criterios de proveedores o vendedores definida por el cliente o comprador se compara con la información (etapa 720) de calificación del proveedor o vendedor para determinar si la información de calificación del proveedor o vendedor iguala a la información de criterios del proveedor o vendedor definidos por el usuario (paso 730) . Si es asi, se notifica al proveedor o vendedor y al cliente o comprador de la correspondencia (paso 740) y si el cliente o comprador aprueba al proveedor o vendedor, la información del proveedor o vendedor asociada con el proveedor o vendedor se almacena en la lista de proveedores o vendedores del cliente o comprador para su uso posterior para preparar las solicitudes de licitaciones (paso 750). Además, la información del cliente o comprador se puede almacenar en la lista de clientes o compradores del proveedor o vendedor para referencia cuando se reciban las solicitudes de licitaciones y para preparar las respuestas a las licitaciones (paso 760) . Sin embargo, si la información de calificación del proveedor o vendedor no corresponde a la información de criterios del proveedor o vendedor definidos por el usuario (paso 730), el sistema determina si es necesaria información de calificación del proveedor o vendedor adicional para que el cliente o comprador califique al proveedor o vendedor (paso 770) . Si es asi, se solicita al proveedor que proporcione esta información de calificación del proveedor o vendedor adicional (paso 780) para que el cliente o comprador califique al proveedor o vendedor (paso 710) . Si no es asi, el cliente o comprador no califica al proveedor o vendedor (paso 790), y el proveedor o vendedor no se agrega a la lista del cliente o comprador .

Además, para que los clientes o compradores califiquen a los proveedores o vendedores, los proveedores o vendedores, los clientes o compradores, y los administradores puede desra designar a cierto personal para manejar varios aspectos del proceso de licitación/proyecto para sincronizar las comunicaciones, los datos y el procesamiento de transacciones a través de plataformas de usuarios múltiples. Por ejemplo, refiriéndonos a la FIG. 8, el proceso de licitación/proyecto típicamente requiere la inclusión de un espectro amplio de procesamiento de información y departamentos funcionales para facilitar la administración y la gestión del proceso de licitación/proyecto. Tal procesamiento de información puede incluir, por ejemplo, la transmisión de solicitudes de licitación, las respuestas de los proveedores o vendedores a las licitaciones, disposición de las licitaciones (evaluación y otorgamiento), envió de recursos, envió de tarjetas de registro de horarios, rastreo de entregables y pago de comprobantes. Todos estos componentes de procesamiento de información se pueden manejar por uno o más individuos o departamentos diferentes, tales como el COO, el departamento de Recursos Humanos, el Usuario del Proyecto y el Procesador Financiero. Para satisfacer esta necesidad funcional, el sistema computarizado de la presente invención puede permitir un ambiente de trabajo compartido, donde los clientes o compradores, los proveedores o vendedores y/o los administradores puedan especificar varios papeles de usuario personalizados que necesitan para participar en el proceso de licitación/proyecto y designar al personal (recursos) para cada uno de los papeles de usuario para todos los o licitaciones/proyectos o para licitaciones/proyectos particulares . Refiriéndonos ahora a la FIG. 9, se ilustran ejemplos ejemplificantes para especificar las posiciones de las funciones de usuario y asignar personal a las posiciones de las funciones de usuario para un proveedor o vendedor, cliente o comprador o administrador. Inicialmente, el proveedor o vendedor, cliente o comprador o administrador determina las posiciones de las funciones de usuario que se necesitan para el proceso de licitación/proyecto (paso 900) . Por ejemplo, como se muestra en la página de red del cliente o comprador de muestra de la FIG. 11, el cliente o comprador puede determinar que hay una necesidad en cuanto a varias diferentes categorías de las funciones del usuario, tales como aprobadores financieros, aprobadores no financieros, revisores de tarjetas de registro de horarios, delegados administrativos, administradores de eventos importantes del proyecto, coordinadores financieros y asociados de recursos humadnos durante el proceso de proyecto/licitaciones. Los proveedores o vendedores, los clientes o compradores o los administradores pueden además determinar que se necesitan varias posiciones de las funciones de usuario de usuario en una o más categorías de las funciones de usuario para el proceso de licitación/proyecto. Por ejemplo, como se muestra en la FIG. 11, el cliente o comprador puede determinar que hay una necesidad por ser aprobadores financieros y dos aprobadores no financieros . Refiriéndonos otra vez a la FIG. 9, una vez que se determinan las posiciones de las funciones de usuario, un archivo de datos para el personal pertinente del proveedor o vendedor, el cliente o comprador o el administrados se almacena para usarse al seleccionar el personal apropiado para cada una de las posiciones de las funciones de usuario (paso 905) . Una o más personas clave del proveedor o vendedor, el cliente o comprador o el administrados (por ejemplo, el COO, el Usuario del Proyecto, etc.) se pueden seleccionar para designar el personal particular a ser asignado a cada una de las posiciones de las funciones de usuario (paso 910), o alternativamente, el sistema puede asignar el personal a las posiciones de las funciones de usuario con base en la información contenida en el archivo de datos personales. En algunas compañías, las posiciones de las funciones de usuario se pre-designan (paso 915) , y en este caso, el personal pre- designado puede ser cargado en el sistema (paso 920) y almacenado en una tabla de papeles de usuario (paso 925) . Por ejemplo, para la mayoría de los proveedores o vendedores, el personal se pre-asigna para varios cargos de función de los usuarios para todos los proyectos. En otras compañías, uno o más de los cargos de función de los usuarios pueden no ser pre-designadas en absoluto o no se pre-asignan para un proyecto particular (paso 915) , y en este caso, el personal clave seleccionado o el sistema pueden asignar el personal especifico para los cargos de función de los usuarios. Para asignar el personal especifico a los cargos de función de los usuarios, el cargo de función del usuario especifico se selecciona (paso 930), y una lista de personal que puede ser asignado a ese cargo de la función del usuario, dependiendo de las restricciones de función del usuario, se determina a partir del archivo de datos del personal (paso 935,940 y 945) . Por ejemplo, si un cargo de función de usuario requiere un usuario de nivel particular, sólo ese personal al nivel de usuario particular o superior se incluye en la lista. De la lista de personal para el cargo de función del usuario uno del personal se selecciona para el cargo de función particular (paso 950) y el personal seleccionado se almacena en la tabla de funciones de los usuarios (paso 925) . Por ejemplo, como se muestra en la FIG. 11, tras seleccionar una función de cargo de un usuario particular 8por ejemplo, haciendo click sobre una posición de cargo del usuario) , el sistema puede buscar al personal calificado para el cargo de función del usuario, y después que ha hecho una selección, se puede desplegar el personal seleccionado para el cargo de función del usuario. Los ejemplos de estructuras de datos para seleccionar y asignar los cargos de función de los usuarios para un cliente o comprador se muestran en las tablas 1-9 a continuación. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tablas, con cada tabla que incluye todos los campos necesarios para definir y asignar los cargos de función de los usuarios para el cliente o comprador. Las tablas se relacionan en una manera jerárquica y/o relacional, se manera tal que toda la información necesaria para las posiciones de función de los usuarios se puede almacenar y acceder con exactitud, como se describirá enseguida en conexión con la estructura 300 de tablas de base de datos ejemplificante de la FIG. 10. sin embargo, se debe entender que se pueden incluir otras configuraciones de cargos de usuario del cliente o comprador, y el sistema no se limita a las configuraciones de funciones de usuario del cliente o comprador listadas en las Tablas 1-9 de la FIG. 10.

Las Tablas 1 y 2 de abajo ilustran las categorías de funciones de usuario y los cargos de función de usuario dentro de cada una de las categorías de funciones de usuario, respectivamente, las cuales se pueden almacenar en la base de datos en las tablas tbIHMPosicionCategorias 305 y tbIHMPosiciones 306 respectivamente, como se muestra en la FIG. 10. En la tabla 1, a cada categoría de función de usuario se le asigna un número de identificación y un orden de despliegue para desplegarlo en la página de red. Los números de identificación de categorías de función de usuario se usan dentro de la tabla de posiciones de funciones de usuario (tabla 2) para correlacionar las posiciones de la función de usuario con las categorías de funciones de usuario especificas. Sin embargo, se debe entender que podrian haber varias categorías y posiciones adicionales, dependiendo de las necesidades del cliente o comprador. Cuando se seleccionan inicialmente las posiciones de funciones de usuario, las categorías de funciones de usuario se pueden desplegar para que el usuario las seleccione, con enlaces a las posiciones de función de usuario especificas dentro de cada una de las categorías. Después que se han seleccionado todas las posiciones de funciones de usuario para el cliente o comprador particular, las posiciones de función de usuario seleccionadas y el personal asignado pueden ser desplegadas como en la FIG. 11.

TABLA 1 La Tabla 3 de abajo ilustra los datos de muestra almacenados en el archivo de datos de personal para cada usuario del sistema, el cual se puede almacenar en la tabla de base de datos tbIUsuario 302, como se muestra en la Fig. 10. A partir de estos datos de usuario, se pueden determinar el personal calificado para cada posición de función de usuario, y se puede determinar la información necesaria para cada usuario asignado para cada posición de las funciones de usuario. Uno de los campos en la Tabla 3 es el grado de negocios asignado al usuario particular. El grado de negocios indica el nivel particular del usuario en el sistema de negocios particular. Por ejemplo, el usuario puede ser un usuario de nivel 3, y esta información se almacenarla en la tabla de usuarios. Los grados de negocios disponibles se pueden asignar a las posiciones de funciones de usuario, como se muestra en las Tablas 4 y 5 de abajo para indicar el grado de negocios requerido para el usuario asignado a cada posición de las funciones de usuario, los cuales se pueden almacenar en las tablas de base de datos tbIHMNegociosGrados 303 y tbIHMPosiciónEnGradosAsignación 304, como se muestra en la FIG. 10.

Tabla 5 Tabla de Asignación de las Funciones de Usuario al Grado de Negocios tblHMPosiciónaGradoAsi nación Las Tablas 6-9 enseguida se describirán abajo en mayor detalle con relación a la Fig. 10.

Tabla 6 Tabla de Asignación de Posición/Cargo de la Plantilla de Licitaciones Tabla 7 Tabla de Asignación de Funciones de Usuario por Defecto i tblHMPosiciónRelaciones Tabla 8 Tabla de Asignación de Funciones para la Solicitud de Licitación tblLicitaciónHMPosiciónes Tabla 9 Posición/Función del Usuario para Asignación de Nivel y Jerarquía de Aprobación tbIA robaciónNivel Como se puede observar en la FIG. 10, existe una relación concisa entre todos los campos necesarios para permitir la compartición de trabajo configurable y componentes de flujo de trabajo específicos para el cliente o comprador. La estructura 300 de la base de datos es escalable y configurable, de tal manera que cuando se opera dentro de un ambiente de base de datos menos sofisticado, la funcionalidad aun existe siempre y cuando las posiciones de funciones de usuario se especifiquen y un archivo de datos del personal se encuentre disponible. Se debe entender que las estructuras de la tabla de base de datos están disponibles para el proveedor o vendedor y el administrador, las cuales se discutirán con más detalle a continuación. La estructura 300 de la tabla de base de datos para el cliente o comprador toma como entrada los datos del personal (tblHRdatos 301) del cliente o comprador y crea un archivo de datos del personal (tblUsuario 302) que incluye el personal especifico que puede estar involucrado en el ambiente de trabajo compartido. Los datos del personal se muestran como la tabla tblHRdatos 301 para propósitos de simplicidad. Sin embargo, se debe entender que los datos del personal pueden estar en cualquier forma, dependiendo del sistema de base de datos del cliente o comprador. Se pueden llevar a cabo descargas periódicas de la tabla tblHRdatos 301 a la tabla tblUsuario 302 para actualizar el sistema en cuanto a los empleados actuales del cliente o comprador, para asegurar que las posiciones de las funciones de usuario están asignadas apropiadamente. Los varios grados de negocios designados por el cliente o comprador también se pueden almacenar en la tabla tbIHMNegociosGrados 303 y se asignan a la tabla tblUsuario 302 para la asignación individual de los grados de negocios, como se discute arriba en conexión con las Tablas 3 y 4. Además, los grados de negocios se pueden asignar a las funciones de usuarios seleccionados en la tabla tblHMPosicionesGrado 304, como se discute arriba en conexión con las Tablas 4 y 5. La tabla de categorías de funciones de usuario (tblHMPosicionesCategorias 305) y la tabla de posiciones de funciones de usuario (tbIHMPosiciones 306) y su interrelación con los grados de posición y el personal asignado también se muestran en la FIG. 10. por ejemplo, la tabla tblHMPosicionesRelación 307 incluye la ID o identificación del personal asignado para cada posición de función de usuario. Si las posiciones de las funciones de usuario se asocian con los tipos de plantillas de licitación específicos (como se describe con más detalle a continuación en conexión con la FIG. 15), las posiciones de funciones de usuario para cada tipo de plantilla de licitación se pueden almacenar en la tabla tblHMPosicionesRFXMatriz 309. Además, si las posiciones de funciones de usuario se asignan específicamente a cada transacción de licitación, la ID o identificación de usuario del personal asignado a cada posición de función de usuario para una transacción especifica se puede almacenar en la tabla tblLicitaciónHMPosiciones 308. Los pasos ejemplificantes para asignar el personal a las posiciones de funciones de usuario durante una transacción se muestran en la FIG. 12. Tras el inicio de una transacción (paso 1200) (por ejemplo, la creación de una plantilla de licitación o solicitud de licitación, transmisión de la solicitud de licitación, recepción de la respuesta de licitación, evaluación de la respuesta de licitación, otorgamiento de la licitación, pago de comprobante, etc.), el sistema y/o el personal clave determina si todas las posiciones de funciones de usuario requeridas para la transacción han sido definidas (paso 1205) . Si no, el sistema y/o el personal clave define las posiciones de funciones de usuario necesarias para la transacción (paso 1210).

Una vez que se han determinado las posiciones de funciones de los usuarios, el sistema y/o el personal clave determina si el personal especifico (denominados también aqui como usuarios) han sido pre-designados en cuanto a las posiciones de funciones de usuario (paso 1215) y si alguno de los usuarios pre-asignados necesita ser cambiado para la transacción (paso 1220) . Si una o más posiciones de funciones de usuario no tienen un usuario pre-designado o si uno o más usuarios pre-designados deben ser cambiados, el sistema y/o el personal clave designa al usuario apropiado para todas las posiciones de la función del usuario (paso 1225) y almacena la identidad de los usuarios designados para las posiciones de funciones de usuario en la tabla de funciones de usuario (paso 1230) (por ejemplo, la tblLicitaciónHMPosiciones en la FIG. 10). Si todos los usuarios están predesignados, el sistema almacena el personal pre-designado (paso 1230) y si es aplicable, notifica al personal apropiado de la transacción (paso 1240) . Refiriéndonos otra vez a la FIG. 10, además de asignar los usuarios a las posiciones de funciones de usuario especificas para un proceso de licitación/proyecto, la estructura 300 de la base de datos proporciona además la habilidad de designar las transacciones que requieren aprobación y los aprobadores específicos por una variedad de razones. Por lo tanto, en una tabla tblAprobaciónNivel310, ciertas posiciones de funciones de usuario se pueden calificar como posiciones de aprobación, y para cada posición de aprobación, se puede especificar el orden de encaminamiento para la aprobación. Por ejemplo, una posición de función de usuario aprobador (aprobador A) se pueden designar para aprobar por otra posición de función de usuario (Usuario B) , de modo tal que el sistema automáticamente encamina todas las transacciones del Usuario B al Aprobador A. Además, se puede proporcionar a cada usuario con derechos de acceso para visualizar y modificar los datos en el sistema. Por ejemplo, una posición de función de usuario puede tener la autoridad para modificar o ingresar datos en el sistema a través de una primera página de red, en tanto que otra posición de función de usuario sólo puede tener la autoridad para visualizar los datos a través de una segunda página de red. Por lo tanto, aunque la información desplegada en la página de red puede ser la misma para ambos usuarios, las páginas de red actuales son diferentes, dependiendo del nivel de aprobación de la posición de la función del usuario. Cuando un usuario se registra en el sistema, el sistema determina el nivel de aprobación del usuario y transmite las páginas de red apropiadas para el usuario. Un ejemplo de una estructura de datos que implementa la asignación de las funciones de usuario al acceso a las páginas de red se muestra abajo en la tabla 10.

Tabla 10 Tabla de Asi nación De la Función del Usuario al Acceso de las Pá inas de Red Con el fin de mantener la relación entre las posiciones de las funciones de usuario, el personal interno y las transacciones especificas en una manera continua, el sistema de la presente invención se diseña además para ser responsable de los cambios en el personal organizativo y el nivel de negocios y la autoridad del personal. Refiriéndonos ahora a la FIG. 14, se ilustran los pasos ejemplificantes para modificar las asignaciones de posición de las funciones de usuario, de acuerdo con las modalidades de la presente invención. La posición de las funciones de usuario se puede reasignar con base en el nombre de usuario o el tipo de transacción (paso 1400) . Si la modificación se basa en el nombre de usuario (paso 1405), el cambio se puede hacer globalmente a todas las posiciones de funciones de usuario poseídas por el usuario o sólo para las posiciones de las funciones de usuario especificas poseídas por el usuario. Para los cambios globales (paso 1410) , se selecciona a un nuevo usuario (paso 1415) y el usuario se substituye por el usuario previo para todas las posiciones de funciones del usuario por el usuario previo (paso 1420) . Este tipo de cambio global es necesario, por ejemplo, cuando un empleado abandona la compañía, y un nuevo empleado toma la posición del empleado saliente dentro de la compañía . Para cambios específicos de posición de la función del usuario (paso 1410), todas las posiciones de la función del usuario poseídas por el usuario se pueden desplegar (paso 1425), y una de las posiciones de la función del usuario se puede seleccionar para los cambios (paso 1430) . Se elige un nuevo usuario para esa posición de la función del usuario seleccionada (paso 1435) y el nuevo usuario se substituye por el usuario previo para esa posición de función del usuario (paso 1440) . Este proceso se puede repetir para cada posición de la función del usuario que requiera un cambio (paso 1445). Los cambios específicos de la posición del función del usuario pueden ocurrir por varias razones, tales como la promoción, reorganización, cambios de estatus de los empleados (por ejemplo, de tiempo completo a tiempo parcial), etc. Si la modificación se hace con base en el tipo de transacción (paso 1405) , un listado de todos los tipos de transacciones (por ejemplo, creación de solicitudes de licitación, transmisión de solicitudes de licitación, recepción de solicitudes de licitación, generación de respuestas de licitación, recepción de respuestas a la licitación, evaluación de licitaciones, otorgamiento de la licitación, registro del tiempo, emisión de comprobantes de pago, etc.) se pueden desplegar (paso 1450) y se selecciona un tipo particular de transacción (paso 1455). Se pueden desplegar todas las posiciones de función del usuario asociadas con ese tipo de transacción particular (paso 1460) y la posición de función del usuario particular a ser modificada se selecciona (paso 1465) . Se elige un nuevo usuario para esa posición de función del usuario (paso 1470), y el nuevo usuario se substituye por el usuario previo para esa posición de función del usuario (paso 1475) . Las modificaciones del tipo de transacción pueden ser benéficas, por ejemplo, cuando se desconoce el usuario particular para una posición de función del usuario, pero un cambio se requiere debido a inconformidades del cliente. Las modificaciones de la posición de función del usuario se pueden aplicar a las transacciones existentes o sólo a las transacciones nuevas (paso 1480) , dependiendo de la razón para la modificación y la necesidad de continuidad en las transacciones existentes. Si la modificación debe ser aplicada a las transacciones existentes, la tabla de funciones del usuario se actualiza con el nuevo usuario y el registro previo del usuario se modifica para actualizarlo (paso 1458). Sin embargo, si la modificación sólo debe ser aplicada a las transacciones nuevas, la tabla de funciones del usuario se actualiza con el nuevo usuario, pero el usuario previo no se elimina, y el nuevo usuario se marca sólo para las nuevas transacciones (paso 1490) . Para el proveedor o vendedor, las posiciones de función del usuario típicamente se pre-designan para limitar el acceso al personal calificado. Los ejemplos de estructuras de datos que implementan funciones de usuario den proveedor o vendedor se muestran en las Tablas 11-13 a continuación. Como se puede observar, al personal del proveedor o vendedor se le puede asignar un tipo de contacto del proveedor o vendedor, el cual se puede asignar a los derechos de acceso para visualizar y modificar los datos dentro del sistema, de manera similar lo que se describe arriba para el cliente o comprador en conexión con la Tabla 10. Sin embargo, se debe entender que se pueden incluir las configuraciones de las funciones de usuario del proveedor o vendedor, y el sistema no se limita a las configuraciones especificas listadas en las Tablas 11-13.

TABLA 11 Funciones Ejemplificantes del Proveedor o Vendedor tbIProovedor VendedorFunciones TABLA 12 Contactos Ejemplificantes del Proveedor o Vendedor tblProovedor/VendedorContactos TABLA 13 Autorizaciones Ejemplificantes de las Funciones del Proveedor o Vendedor tblProovedor VendedorAutorizaciones Para el administrador, las posiciones de las funciones de usuario se pueden definir para permitir que los equipos de procesamiento completo y los miembros del equipo sean especificados con el fin de administrar las actividades transaccionales asociadas con los tipos de licitaciones específicos para las ubicaciones especificas. Refiriéndonos ahora a las FIGs. 13A-13B, se muestran los pasos ejemplificantes para implementar un equipo de procesamiento administrativo. Inicialmente se establece una tabla de usuario administrativo por el administrador, la cual contiene los datos principales del usuario administrativo (paso 1300) . De la tabla de usuarios, se pueden asignar varios usuarios a uno o más grupos y la asignación de los usuarios a grupos de usuarios se pueden almacenar en una tabla de asignación de grupos de usuarios (paso 1305) . Los grupos de usuarios se pueden asociar con unidades de negocios dentro de una compañía o tipos de transacciones o ambos. Para cada uno de los gripos de usuarios, los derechos funcionales y las responsabilidades de cada usuario dentro del grupo de usuarios se pueden definir en una tabla de derechos de grupos de usuarios (paso 1310) . Por ejemplo, a cada usuario se le pueden asignar derechos de acceso (como se discute arriba en conexión con la FIG. 10) para el grupo de usuarios. Los ejemplos de estructuras de datos que implementan los grupos de usuarios y los derechos de grupos de usuarios para el administrador se muestran en las Tablas 14-19 a continuación. Sin embargo, se debe entender que se pueden incluir las configuraciones de funciones de usuario del administrador, y el sistema no se limita a las configuraciones de funciones de usuario del administrador listadas en las Tablas 14-19.

TABLA 14 (continuación) Tabla de Usuario Administrativo Eem lificante TABLA 16 Tabla de Asignación Ejemplificante de los Usuarios Administrativos al Grupo de Usuarios TABLA 17 Tabla E em lificante de Derechos de Gru o de Usuarios Administrativos Una vez que se han determinados los grupos de usuarios, como se muestra en la FIG. 13B, se pueden crear los equipos de procesamiento dentro de los grupos de usuarios, para manejar tipos específicos de transacciones (paso 1315) . Todos los usuarios dentro de un grupo de usuarios particular se pueden asignar a equipos de procesamiento específicos y se asignan a un orden de encaminamiento para el tipo de transacción particular (paso 1320) . Las estructuras de datos ejemplificantes para crear y asignar usuarios a los equipos de procesamiento se muestran en las Tablas 18 y 19 a continuación.

Además, los equipos de procesamiento se pueden asignar a regiones geográficas especificas, de tal manera que los diferentes equipos de procesamiento pueden manejar el mismo tipo de transacciones en diferentes regiones (paso 1325) . Por lo tanto, cuando se conduce un tipo particular de transacción en una ubicación particular, el sistema puede manejar el flujo de trabajo para los usuarios apropiados con base en el tipo de transacción y la ubicación (paso 1330). Por ejemplo, los usuarios apropiados pueden ser notificados de la transacción via aun correo electrónico y/o la actualización del tablero. Por lo tanto, la administración de las funciones de usuario soportada por el sistema de la presente invención proporciona, un ambiente flexible, escalable y robusto para el proceso completo de licitación/proyecto desde la creación de la licitación a la terminación del proyecto. Además, el sistema permite las comunicaciones y el procesamiento de transacciones seguros con base en las funciones de usuario, lo cual permite que los usuarios se interconecten con el personal correcto en el momento correcto en tanto que se asegura que la vista de los datos y los derechos de acceso se limiten para aquellos usuarios que tienen una necesidad funcional por el acceso. ACTIVIDADES DE LICITACIÓN Después que se completan las actividades per-licitación, un cliente o comprador puede crear y transmitir una solicitud de licitación a uno o más proveedores o vendedores para solicitar una respuesta de la bis de los proveedor o vendedor para una proyecto particular. Para facilitar el proceso de licitación en el contexto del proceso completo de licitación/proyecto, las plantillas de licitación se pueden usar para los tipos de proyectos específicos, para solicitar la información necesaria de los proveedores o vendedores para el tipo de proyecto especifico en una manera uniforme e integral para permitir la evaluación eficiente y efectiva de las respuestas de la licitación. La funcionalidad ejemplificante para crear una solicitud de licitación que utiliza una plantilla de licitación se muestra en la FIG. 15. Una herramienta 180 de creación de plantillas de licitaciones y una herramienta 185 de creación de solicitudes de licitación se ilustran en la FIG. 15 para la creación de plantillas 240 de licitación y solicitudes 200 de licitación a partir de las plantillas 240, respectivamente, de acuerdo con las modalidades de la presente invención. La herramienta 180 de creación de plantillas de licitación y la herramienta 185 de creación de solicitudes de licitación pueden incluir cualquier elemento fisico, elemento lógico y/o soporte lógico inalterable requeridos para llevar a cabo las funciones de las herramientas, y se pueden implementar dentro del servidor 120 de red o un servidor adicional (no se muestra) . Cada cliente o comprador puede crear una o más plantillas 240 de licitación dependiendo de la naturaleza del trabajo del proyecto subcontratado por el cliente o comprador. Por ejemplo, si el cliente o comprador tiene una necesidad por la implementación de personal en sólo un departamento, el cliente o comprador puede crear sólo una plantilla 240 de licitación para manejar la solicitud 200 de licitación de complemento de personal. Para crear una plantilla 240 de licitación, la herramienta 180 de creación de plantillas de licitación accede a la base de datos 155a del cliente o comprador para recuperar los rubros 230 de licitación dentro de una lista 194 de rubros de licitación y provee al cliente o comprador con la lista 230 de rubros de licitación via el módulo 110 de clientes o compradores, el servidor 120 de red, la red 40 de datos y el navegador 20a del cliente o comprador para que el cliente o comprador los elija. Los rubros 230 de licitación se asocian con tipos específicos de información para ser solicitados por el cliente o comprador, el proveedor o vendedor o ambos. De la lista de rubros 230 de licitación, el cliente o comprador selecciona y proporciona una o más selecciones 235 de rubros de licitación para su inclusión en una plantilla 240 de licitación. Dependiendo de las configuraciones del cliente o comprador, uno o más de los rubros 230 de licitación pueden ser obligatorios para la plantilla 240 de licitación, tales como el nombre del cliente o comprador, la ubicación del trabajo a ser llevado a cabo y el tipo de trabajo del proyecto solicitado. Para uno o más de los rubros 230 obligatorios de la licitación, además de incluir los rubros 230 obligatorios de la licitación en la plantilla 240 de licitación, la información especifica asociada con cada uno de los rubros 230 obligatorios de la licitación se puede incluir además en los campos asociados con los rubros 230 obligatorios de la licitación dentro de la plantilla 240 de licitación. Por ejemplo, el nombre del cliente o comprador y el tipo de trabajo del proyecto se pueden almacenar en la plantilla 240 de licitación para ese tipo de proyecto. Cada plantilla 240 de licitación creada por el cliente o comprador se almacena en la base de datos 155a de clientes o compradores dentro de una lista 190 de plantillas de licitación para su uso posterior al crear una solicitud 200 de licitación. Para crear una solicitud 200 de licitación, la herramienta 185 de creación de solicitudes de licitación accede a la base de datos 155a de clientes o compradores para recuperar las plantillas 240 de licitación almacenadas dentro de la lista 190 de plantillas de licitación y proporciona una lista de plantillas 240 de licitación al cliente o comprador, via el módulo 110 del cliente o comprador, el servidor 120 de red, la red 40 de datos y el navegador 20a del cliente o comprador para que el cliente o comprador elija. Tras seleccionar una plantilla 240 de licitación apropiada, el cliente o comprador proporciona los datos 210 de la solicitud de licitación a la herramienta 185 de creación de solicitudes de licitación para su inclusión en una solicitud 200 de licitación del tipo de la plantilla 240 de licitación. Por ejemplo, el cliente o comprador puede ingresar los datos 210 de la solicitud de licitación en los campos proporcionados para cada selección 235 de rubros de la licitación que requieren la información del cliente o comprador dentro de la plantilla 240 de licitación. A manera de ejemplo, pero sin limitación, los datos 220 de la solicitud de licitación podrian incluir la ubicación del trabajo a ser llevado a cabo, el tiempo del proyecto y las calificaciones de los proveedores o vendedores necesarios para el proyecto. La herramienta 185 de creación de licitación se interconecta además con la base de datos 155a de clientes o compradores para acceder a la lista 158 de proveedores o vendedores y determina los proveedores o vendedores apropiados para recibir la solicitud de licitación. Los proveedores o vendedores apropiados se pueden seleccionar con base en el tipo de plantilla 240 de licitación y otras calificaciones de los proveedores o vendedores incluidas dentro de la solicitud 200 de licitación en si. Por lo tanto, la lista 158 de proveedor o vendedor se puede separar en proveedores o vendedores pre-calificados para los tipos de plantillas 240 de licitación para reducir adicionalmente el tiempo de procesamiento cuando se transmiten las solicitudes 200 de licitación. La herramienta 185 de creación de solicitudes de licitación utiliza además la información 250 de contacto de los proveedores o vendedores asociada con los proveedores o vendedores asociados para difundir (transmitir) la solicitud 200 de licitación a los proveedores o vendedores apropiados (como se muestra en las FIGs. 1 y 2) via el módulo 115 de proveedores o vendedores, el servidor de red, la red 40 de datos y el navegador 20b del proveedor o vendedor, y almacena la solicitud 200 de licitación transmitida en una lista 196 de solicitudes de licitación para el cliente o comprador. Las respuestas 220 de los proveedores o vendedores a la bis recibidas de los proveedores o vendedores solicitados (como se muestra en las FIGs. 1 y 2) se pueden almacenar adicionalmente en la base de datos 155a de clientes o compradores en una lista 198 de respuestas a la bid para su uso posterior para comparar y calificar las respuestas 220 a la licitación de los proveedores o vendedores. Las respuestas 220 a la licitación de los proveedores o vendedores se generan a partir de los rubros incluidos en la solicitud 200 de licitación. Específicamente, el proveedor o vendedor alimenta los datos asociados con el proveedor o vendedor y la respuesta a la licitación en los campos de datos dentro de los rubros de la licitación en la solicitud 200 de licitación. Los proveedores o vendedores acceden a la solicitud 200 de licitación via el módulo 115 de proveedores o vendedores para visualizar la solicitud de licitación y completar la respuesta del proveedor o vendedor y enviar las respuestas 220 a la licitación completadas via el módulo 115 del proveedor o vendedor para su almacenamiento en la base de datos 155a de clientes o compradores via el módulo 110 de clientes o compradores (no se muestra el paso) . La respuesta 220 a la licitación puede incluir los datos recuperados de una base de datos 115b de proveedores o vendedores (no se muestra) y se pueden almacenar en la base de datos 155b de proveedores o vendedores durante y después de la creación de las respuestas.

Los pasos ejemplificantes para crear una plantilla de licitación, una solicitud de licitación a partir de la plantilla de licitación y una respuesta a la licitación a partir de la solicitud de licitación desde las varias perspectivas del sistema se muestran en las FIGs. 16A-16D. Los pasos principales del procesamiento llevado a a cabo en el sistema para la creación de plantillas de licitación se muestran en la FIG. 16A. El sistema crea una plantilla de licitación al proporcionar a un usuario cliente o comprador una lista de rubros predeterminados de la licitación (paso 1600) . En respuesta a ello, el sistema recibe unoa o más reelecciones de rubros de la licitación de la lista de rubros de licitación para su inclusión dentro de una plantilla de licitación almacenada en el sistema (paso 1610) . Para crear una solicitud de licitación a partir de la plantilla de licitación, el sistema comunica las selecciones de rubros de la licitación dentro de a plantilla de licitación al usuario cliente o comprador para la generación de la solicitud de licitación usando las selecciones de rubros de la licitación (paso 1620) . En la FIG. 16B, en el lado del cliente o comprador, tras la recepción de la lista de rubros de la licitación, para crear la plantilla de licitación, el cliente o comprador selecciona uno o más rubros de licitación a ser incluidos en la plantilla de licitación (paso 1630). Para la generación subsecuente de una solicitud de licitación, el cliente o comprador recibe la plantilla de licitación que incluye las selecciones de rubros de la licitación (paso 1635) e ingresa los datos de la solicitud de licitación en los campos asociados con las selecciones de rubros de la licitación en la plantilla de licitación, para crear la solicitud de licitación (1640) . Después que se han completado por el usuario cliente o comprador todos los campos de selección de rubros de la licitación aplicables, la solicitud de licitación se transmite al sistema para su difusión a los proveedores o vendedores calificados (paso 1645) . Los pasos de procesamiento principal llevado a cabo por el sistema para la generación y difusión de solicitudes de licitación se muestran en la FIG. 16C. Después de la creación de una plantilla de licitación y el almacenamiento de las selecciones de rubros de la licitación para la plantilla de licitación (paso 1650), el sistema genera una solicitud de licitación usando los datos de la solicitud de licitación ingresados por el usuario cliente o comprador para la solicitud de licitación del tipo de la plantilla de licitación (paso 1660). Después, el sistema transmite la solicitud de licitación generada a los proveedores o vendedores calificados para solicitar una respuesta de la licitación del tipo de la plantilla de licitación (paso 1670). En la FIG. 16D, en el lado del proveedor o vendedor, el proveedor o vendedor recibe la solicitud de licitación que incluye las selecciones de rubros de la licitación permitidos, seleccionados por el cliente o comprador (paso 1680) . Para crear una respuesta de la licitación, un usuario proveedor o vendedor ingresa los datos de respuesta de la licitación en los campos asociados con las selecciones de rubros de la licitación incluidos en la solicitud (paso 1685) para crear la respuesta de la licitación. Después que se han completado por el usuario proveedor o vendedor todos los campos de selecciones de rubros de la licitación, la respuesta a la licitación se transmite al sistema para enviarla al cliente o comprador (paso 1690).

Los ejemplos de estructuras de datos usados para crear las plantillas de licitación se muestran en las Tablas 20-25 a continuación. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tabla, con da atabla que incluye todos los campos necesarios para desplegar los rubros de la licitación al usuario cliente o comprador para seleccionar y almacenar las selecciones de rubros de las licitación para las plantillas de licitación. Las tablas se relacionan en una manera jerárquica y relacionar, como se describirá a continuación en conexión con la FIG. 17. Sin embargo, se debe entender que se pueden incluir otras configuraciones de las plantillas de licitación, y el sistema no se limita a la configuración de la plantilla de licitación mostrada en las Tablas 20-25 y la FIG. 17.

TABLA 20 Tabla Base de Secciones de Rubros de la Licitación tblRFXLicitaciónSecciones TABLA 21 Tabla Base de Cate orías de Rubros de la licitación tblRFXLicitaciónCate orías TABLA 24 Tabla de Asignación de la Platilla de Licitación Base a los Rubros de la Licitación ftblRFXLicitacionRubrosCDV TABLA 25 Tabla Base de Valores por Defecto de Rubros de la Licitación del Cliente (tblRFXLicitaciónRubrosCDV) Nombre de la Columna Tipo de Datos Longitud RFX Rubro ID Int Cliente PorDefecto Valor carchar 7500 Refiriéndonos ahora a la FIG. 17, se muestra una estructura 400 de tabla de base de datos que ilustra la interrelación entre cada una de las Tablas 20-25 de arriba. Los rubros 230 de la licitación se muestran organizados en secciones de la licitación y categorías de la licitación por conveniencia y segmentación lógica de la información de negocios cuando se crean las plantillas 249 de licitación. Por lo tanto, a los usuarios clientes o compradores se les presentan las secciones 250 de la licitación, de las cuales los usuarios clientes o compradores pueden seleccionar una categoría 255 de la licitación para desplegar los rubros 230 de la licitación asociados con esa categoría 255 de licitaciones. Dividir los rubros 255 de la licitación en categorías 255 de licitación y secciones 250 de licitación promueve un formato de compartimientos que se entiende fácilmente por los usuarios clientes o compradores, permitiendo por ello un proceso de creación de plantillas de licitación más eficiente y efectivo. La tabla tblRFX_LicitaciónSecciones 401, la cual tiene la forma de la Tabla 20 de arriba, incluye el nombre y la identificación de las secciones de licitación de cada sección 250 de los rubros 230 de la licitación, junto con una indicación del orden de despliegue para cada sección 250 de la licitación en una página de red y cualquier comentario a ser incluido en la sección 250 de licitación en la página de red. Cada sección 250 de la licitación se puede almacenar como un registro separado en la tabla tblRFXLicitaciónSecciones 401, con cada registro que tiene la forma de la Tabla 20. Dentro de cada sección 250 de la licitación se encuentra una o más categorías 155 de licitación. La tabla tblRFXLKicitaciónCategorias 402, la cual tiene la forma de la Tabla 21 de arriba, incluye la categoría nombre, el número de identificación de cada categoría 155 de la licitación y la sección 250 de la licitación asociada para cada categoría 255 de la licitación. Además, la tabla tblRFXLicitaciónCategorias 402 incluye además el orden de despliegue para cada categoría 255 de la licitación en la página de red y cualquier comentario a ser incluido con la categoría 255 de la licitación en la página de red. Cada categoría 255 de la licitación se puede almacenar como un registro separado en la tabla tblRFXLicitacionCategorias 402, con cada registro que tiene la forma de la Tabla 21. Cada categoría 255 de la licitación incluye además uno o más rubros 230 de la licitación asociados con la categoría 255 de la licitación. Por lo tanto, la tabla tblRFXLicitaciónRubros 493, la cual tiene la forma de la Tabla 22 de arriba, incluye el nombre del rubro de la licitación y el número de identificación, junto con la categoría 255 de la licitación asociada con el rubro 230 de la licitación. Un registro separado para cada rubro 230 de la licitación se puede almacenar en la tabla tblRFXLicitacionRubros 403, con cada registro que tiene la forma de la Tabla 22 de arriba. La tabla tblRFXLicitacionRubros 403 incluye además la información adicional perteneciente al rubro 230 de la licitación, tal como. Si se permite o no la deshabilitación de los rubros 230 de la licitación, si los rubros 230 de la licitación se despliegan al proveedor o vendedor, si los rubros 230 de la licitación requieren una respuesta del proveedor o vendedor, el tipo de datos ingresados por el cliente o comprador para los rubros 230 de la licitación, la longitud del campo para los datos ingresados por el cliente o comprador para los rubros 230 de la licitación, el tipo de datos ingresados por el proveedor o vendedor para los rubros 230 de la licitación y la longitud del campo para los datos ingresados por el proveedor o vendedor para los rubros 230 de la licitación. Por ejemplo, la siguiente Tabla 26 ilustra los rubros 230 de licitación de muestra en la tabla tblRFXLicitaciónRubros que constituyen una lista 194 de rubros de la licitación, como se muestra en la FIG. 15.

Tabla 26 Refiriéndonos otra vez a la FIG. 17, cada uno de los rubros 230 de la licitación se pueden deshabilitar o habilitar para una pkantilla 240 de licitación particular, dependiendo del tipo de trabajo del proyectp para el que se crea la plantilla 240 de licitación particular, como se discute arriba en conexión con la FIG. 15, piedem haber algunos rubros 230 que se requiere incluir en uno o más tipos de plantillas 240 de licitación. Por lo tanto, para los rubros 230 requeridos de la licitación, no se pemite la desactivación. Si una sección 250 o catgeoria 255 completa de la licitación no es aplicable para una plantilla 240 de licitación particular, la estructura 400 de tabla de base de datos se puede configurar para permitir que se deshabilitem los rubros 230 de la licitación en las secciones 250 completas de la bid o la scategorias 255 de la licitación, si todos los rubros 230 de la licitación dentro de esa seccon 250 de la licitación o categoría de la licitación pueden ser deshabilitadis . Una vez que todos los rubrod 230 de la licitación han sido deshabilitados o habilitados (las selecciones 235 de rubros de la licitación son rubros habilitados de la licitación) para una plantilla 2430 de licitación particular, la plantilla 240 de licitación y las selecciones 235 de rubros de la licitación asociadas se pueden almacenar en la estructura 400 de tabla de base de datos. La tabla tblRFXLicitaciónPlantillas 405, la cual tiene la forma de la Tabla 23 de arriba, incluye el nombre de la plantilla de licitación y el número de identificación de la plantilla de licitación para usarse en asociación con las selecciones 235 de rubros de la licitación con la plantilla 240 de licitación en la tabla tblRFXPlantillaRubrosMatriz 404, la cual tiene la forma de la Tabla 24 de arriba. Un registro separado para cada plantilla 240 de licitación se puede almacenar en la tabla tblRFXLicitaciónPlantillas 495, con cada registro que tiene la forma de la Tabla 23. Además, un registro separado para cada selección 235 de rubros de la licitación incluido dentro de una plantilla 240 de licitación particular se puede almacenar en la tabla tblRFXPlantillaRubrosMatriz 404, con cada registro que tiene la forma de la Tabla 24. Si hay rubros 230 de licitación específicos que tienen un valor por defecto aplicable a todas las plantillas 240 de licitación, tales como el nombre del cliente o comprador, el valor por defecto para ese rubro 230 de la licitación particular se puede almacenar en la tabla tblRFXLicitaciónRubrosCDV 406, la cual tiene la forma de la Tabla 25. Un registro separado para cada valor por defecto asociado con cada rubro 230 de la licitación se puede almacenar en la tabla tblRFXLicitaciónRubrosCDV 406, con cada registro que tiene la forma de la Tabla 25. Proporcionando rubros de licitación seleccionables en un formato estructurado, configurable, y escalable, cuaquier rubro 230 de la licitación puede ser agregado o eliminado en cualquier momento dependiendo de las necesidades especificas del cliente o comprador. Los pasos ejemplificantes para crear una plantilla de licitación usando la estructura de tabla de base de datos jerárquica y relacional se ilustran en la FIG. 18. Para crear una plantilla de licitación, un usuaario cliente o comprador ingresa un nombre para la plantilla, para crear un registro para la plantilla en la estructura de tabla de base de datos (paso 1800) . Después, el usuario cliente o comprador selecciona una sección particular de la licitación de una lista de secciones de licitación (pasos 1805 y 1810) y una categoría particular de la licitación de una lista de categorías de licitación (pasos 1815 y 1820) para comenzar el proceso de selección de rubros de la licitación para su inclusión en la plantilla de licitación (paso 1825). Si se requiere uno o más de los rubros de licitación en la categoría de licitación seleccionada (paso 1830) , las selecciones de licitación requeridas se incluyen automáticamente en la plantilla de licitación (paso 1835) . Otros rubros de la licitación se seleccionan con base en las necesidades del usuario cliente o comprador para el tipo particular de plantilla de licitación (paso 1840) . Este proceso se repite para cada categoría de licitación dentro de la sección de la licitación seleccionada (paso 1845) y para cada sección de la licitación dentro de la lista de secciones de licitación (paso 1850), hasta que se han revisado todos los rubros de la licitación y se han habilitado (seleccionado) o bien deshabilitado para la plantilla de licitación. Cvomo se discute arriba, en otras modalidades, todos los rubros de la licitación dentro de una sección de la licitación o catgeoria de la licitación ser desabilitados son revisión de los rubros individuales de la licitación si se permite la deshabilitacion de todos esos rubros de la licitación. Una vez que se han hecho las selecciones de rubros de la licitación para la plantilla de licitación, la plantilla de licitación se almacena en la lista de plantillas de licitación (paso 1855) para su uso posterior el crear una solicitud de licitación. Una imagen de captura de pantalla de una página de red para crear una plantilla de licitación se muestra en la FIG. 19. Usando una o más páginas de red (de las cuales se muestra sólo una) , el usuario cliente o comprador puede ingresar el nombre 240 de la plantilla de licitación, selecciona una sección 250 de la licitación y selecciona una categoría 255 de la licitación para desplegar los rubros 230 específicos de la licitación dentro de la categoría 255 de la licitación, que pueden ser incluidos en la plantilla 240 de licitación. Para cada rubro 230 de la licitación dentro de una categoría 255 de la licitación desplegada, el usuario cliente o comprador puede seleccionar ya sea habilitar o deshabilitar ese rubro 230 de la licitación. Sin embargo, si un rubro 230 particular no puede ser deshabilitado, el botón de deshabilitar se vuelve difusa para evitar que el usuario cliente o comprador desahabilite el rubro 230 de la licitación. Además, si la opción está disponible, también se puede permitir que el usario cliente o comprador deshabilite todos los rubros 230 de la licitación dentro de una sección 250 particular de la licitación o categoría 255 de la licitación haciendo click en un botón de deshabilitar enseguida de la sección 250 de la licitación o categoría 255 de la licitación depslegada actualmente. Una vez que todos los rubros 230 de la licitación han sido habilitados o deshabilitados para la plantilla 240 de licitación, el usuaro cliente o comprador puede salvar la plantilla 240 de licitación. En algunas modalidades, el usuario cliente o comprador pyede ser capaz de salvar temporalmente la plantilla 240 de licitación si no se han completado aun todas las selecciones 235 de rubros. En otras modalidades, el botón de salvar se vuelve difuso hasta que todos los rubros 230 de la licitación han sido habilitados o deshabilitados . La FIG. 20 ilustra los pasos ejmplificantes para crear una solicitud de licitación a partir de una plantilla de licitación, como se muestra en la FIG. 15, usando los rubros de licitación organizadios en un formato jerárquico y relacional, como se muestra en la FIG. 17. inicialmente se selecciona una plantilla de licitación por un usuario cliente o comprador, de la lista de plantillas de licitación para la solicitud de licitación (paso 2000). Se debe entender que la plantilla de licitación puede ser creaada inmediatamente antes de la generación de la solicitud de licitación o la plantilla de licitación puede ser creada con antelación de la solicitud de licitación. Después que se selecciona la plantilla de licitación particular para la solicitud de licitación, el usuario cliente o comprador ingresa un identificador de la solicitud de licitación para la solicitud de licitación (paso 2005), tal como un nombre o número de la solicitud de licitación. Además, el sistema asignará un número de seguimiento de la licitación para referirse a la licitación cuando está se solicita a través del sistema al proveedor o vendedor, el cliente o comprador, el contratista y el administrador. Todas las selecciones de rubros de la licitación en la plantilla de licitación se despliegan por la sección de la licitación y la categoría de la licitación al usuario cliente o comprador para su revisión (paso 2010) . Si una o más de las selecciones de rubros en la plantilla de licitación no son aplicables a la solicitud de licitación particular (paso 2015) , y se pueden deshabilitar las selecciones de rubros de la licitación no deseados pueden ser deshabilitados (paso 2020) , el usuario cliente o comprador puede deshabilitar aquellas secciones de rubros de la licitación que no son necearlos para la solicitud de licitación particular (paso 2025) . Después, el usuario cliente o comprador ingresa los datos necesarios de la solicitud de licitación en los campos apropiados para las selecciones de rubros de la licitación habilitados en la solicitud de licitación (paso 2030). Por ejemplo, una o más selecciones de rubros de la licitación pueden contener un campo para que el cliente o comprador ingrese datos, tales como ubicación del trabajo a ser llevado a cabo o el tiempo de trabajo del proyecto. Estos campos pueden ser campos de datos de tipo variable, tales como campos de entrada de texto o campos de opciones seleccionables con enlaces a otras páginas de red que contienen la opción seleccionable. Un ejemplo de un campo de opciones selecionables que se puede desplegar involucra la selección de un tipo particular de trabajo del proyecto para la solicitud de licitación de un número de tipos de proyectos preestablecidos. Para implementar el proceso de selección de tipo del proyecto, se puede proporcionar una estructura de base de datos que permita que se clasifiquen en un modo no común los requerimientos de negocios de trabajo del proyecto específicos del cliente o comprador. Por la selección de los tipos de trabajo del proyecto preestablecidos, el cliente o comprador puede asegurarse de que las respuestas de los proveedores o vendedores a la licitación están sincronizadas con los requerimientos de trabajo del proyecto del cliente o comprador. Los tipos de trabajo del proyecto también se pueden seleccionar por los proveedores o vendedores cuando se completan los datos de calificación de los proveedores o vendedores (mostrados en la FIG. 2) para la selección de los proveedores o vendedores para recibir la solicitud de licitación. Los ejemplos de estructuras de datos usadas para seleccionar el tipo de trabajo del proyecto se muestran en las Tablas 27-29 a continuación. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para depslegar los tipos de trabajo del proyecto al usuario cliente o comprador para seleccionar y almacenar el tipo de trabajo del proyecto dentro del campo de la selección de rubro de la licitación asociado de la solicitud de licitación. Las tablas se relacionan en una manera jerárquica y relacional, de manera tal que las tablas se acceden en un orden particular para desplegar los tipos de trabajo del proyecto al usuario cliente o comprador.

La tabla 27 de abajo ilustra los tipos de servicios de muestra del proyecto, tales como consutoria, complemento de personal y otros servicios del proyecto. Dentro de cada uno de los tipos de servicios puede haber uno o más sectores de proyectos, como se muestra en la Tabla 28, y dentro de cada uno de los sectores de proyectos pueden haber una o más familias de proyectos, como se muestra en la Tabla 29. Por lo tant, para seleccionar un tipo trabajo del proyecto particular (familia del proyecto) para la solicitud de licitación, el usuario puede seleccionar un tipo de servicios del proyecto y un tipo de sector del proyecto para depslegar una lista de familias de proyectos para la selección. Se debe entender que se pueden incluir otras configuraciones y tipos de proyectos y que el sistema no se limita a las configuraciones especificas y a la información listada en las Tablas 27-29.

TABLA 27 Tabla de Ti os de Servicios del Pro ecto TABLA 28 Tabla de Ti o del Sector del Pro ecto TABLA 29 Tabla de Ti os de Familias de Pro ectos Refiriéndonos otra vez a la FIG. 20, una vez que el usuario cliente o comprador ha ingresado los datos de la solicitud de licitación en todos los campos de rubros requeridos de la licitación (paso 2035), se completa la solicitud de licitación. Se debe entender que no todos los campos de rubros de la licitación reuieren que el usuario ingrese los datos de la solicitud de licitación. Por ejemplo, una o más de las selecciones de rubros de la licitación pueden ser una selección de rubros de la licitación de respuesta del proveedor o vendedor a la licitación a los cuales sólo responde el proveedor o vendedor. Para las selecciones de rubros de la licitación de respuesta a la licitación del proveedor o vendedor, el usuario cliente o comprador puede habilitar o deshabilitar esas selecciones de rubros de la licitación, y no ingresa ningún datos en los campos para esas selecciones de rubros de la licitación excepto los datos que puedan ayudar al proveedor o vendedor para completar la respuesta a la licitación para esos rubros de la licitación. Para la complecion de la solicitud de licitación, cada selección de rubros de la licitación habilitados donde el usuario cliente o comprador puede ingresar los datos de la solicitud de licitación se llenan preferiblemente por el usuario cliente o comprador antes que se trasmita la solicitud de licitación. En muchas compañias, las solicitudes de licitación deben ser aprobadas antes de su transmisicon a los proveedores o vendedores. Por lo tanto, si la solicitud de licitación requiere aprobación (paso 2040) , el creador de la solicitud de licitación envia la solicitud de licitación a los aprobadores apropiados (paso 2045) . En las modalidades ejemplificantes, como se discute arriba en conexión con las FIGs. 9-14, las posiciones de funciones de usuarios de aprobación se pre-designan para todas las solicitudes de licitación o para la solicitud de licitación particular, de modo tal que la solicitud de licitación se encamina automáticamente al aprobador apropiado. Si se aprueba la solicitud de licitación (paso 2050), se informa al creador de la aprobación de la solicitud de licitación (paso 2055) , y la solicitud de licitación se transmite a los proveedores o vendedores calificacos (paso 2060) . Sin embargo, si la solicitud de licitación no se aprueba (paso 2050), se notifica al creador de la declinación de la solicitud de licitación (paso 2065) , y se proporciona la aportunidad de editar la solicitud de licitación (paso 2070), si es posible, por ejemplo, el creador puede haber deshabilitado una o más selecciones de rubros de la licitación que necesitam ser incluidos én la solicitud de licitación para propósitos de aprobación, o ha dejado en blanco uno o más campos de datos requeridos por el cliente o comprador. Si no se requiere aprobación de la solicitud de licitación (paso 2040) , la solicitud de licitación se transmite a los proveedores o vendedores calificados para la solicitud de licitación (paso 2060). Las FIGs. 21 y 22 son capturas de imagen de pantalla de páginas de red ejemplificantes que pueden ser proporcionadas al usuario cliente o comprador para la creación de solicitudes de licitación. Usando una o más páginas de red, el usuario cliente o comprador pued eingresar el nombre 200 de la solicitud de licitación, selecciona una sección 250 de la licitación y selecciona una categoría 255 de la licitación para desplegar las selecciones 230 de rubros de la licitación especifica dentro de la categoría 255 de la licitación que puede ser incluidos en la solicitud 200 de licitación. La FIG. 21 muestra una vista general del estado de la solicitud 200 de licitación que lista el número de selecciones 235 de rubros de la licitación en cada sección 250 y el número de selecciones 235 de rubros de la licitación en cada sección 250 que se completan o se deshabilitan. Para completar o deshabilitar una selección 235 de rubros de la licitación, el usuario cliente o comprador puede hacer click sobre la selecion 250 de la licitación para desplegar las categorías 255 de la licitación y las selecciones 235 de rubros de la licitación dentro de cada una de las categorías 255 de la licitación. Una vez que se han completado o deshabilitado todas las selecciones 235 de rubros de la licitación, el usuario cliente o comprador puede hacer click en un botón para transmitir la solicitud de licitación para su apriobacion y/o la tramsmision a los proveedores o vendedores calificados. Como se muestra en la FIG. 22, cada selección 235 de rubros de la licitación en cada categoría 255 de la licitación dentro de cada sección 250 de la licitación puede ser revisada para detemrinar si la selección 235 de rubros de la licitación debe ser deshabilitada o no. Algunas de las selecciones 235 de rubros de la licitación en una o más de las categorías también pueden requerir datos 210 de la solicitud de licitación del usuario cliente o comprador. Para cada una de las selecciones 235 de rubrbs de la licitación dentro de una categoría 255 de la licitación, el usuario cliente o comprador puede habilitar o bien deshabilitar esa seleeccion 235 de rubros de la licitación. Sin embargo, si no se puede deshabilitar una selección 255 de rubros de la licitación particular, el botón de deshabilitar se vuelve difuso para evitar que el usuario cliente o comprador deshabilite la selección 235 de rubros de la licitación. Además, si la opción está dispinible, también se puede permitir que el usuario cliente o comprador deshabilite todas las selecciones 235 de rubros de la licitación dentro de una sección 250 particular de la licitación o categoría 255 de la licitación. Si se habilita una selección 235 de rubros de la boid y tiene un campo 238 para ingresar datos 210 de la solicitud de licitación, el usuario cliente o comprador puede ingresar los datos 210 de la solicitud de licitación en el campo 238 de datos asociado. Además, si la plantilla de licitación contiene datos 210 de la solicitud de licitación por defecto para una selección 235 de rubros particular de la licitación, los datos 210 por defecto se pueden depslegar en el campo 238 de datos y se puede permitir o no que sean cambiados, depenbiendo de los parámetros de la plantilla. La FIG. 23 ilustra los pasos ejemplificantes para revisar y transmitir las solicitudes de licitación a los proveedores o vendedores calificados, como s emuestra en la FIG. 15. el creador de la solicitud de licitación puede seleccionar ios proveedores o vendedores calificados, arpaopiados, de la lista de vendirs, con base en el tipo de plantilla de licitaciones y los datos de la solicitud de licitaciones ingresados o la csolicitud de licitación puede ser transmitida a un administrador del proyecto para elegir los proveedores o vendedores calificados, dependiendo de las restricciones del cliente o comprador. Si fuera lo último, las nuevas solicitudes de licitación pueden ser desplegadas a un usuario administrativo (paso 2300) para seleccionar la solicitud de licitación deseada para su revisión y transmisión (paso 2305) . Durante el proceso de revisión, se puede permitir que el usuario administrativo edite la solicitud de licitación para propósitos de control de calidad o puede solictar que el creador de la solicitud de licitación edite la solicitud de licitación, si son necesarios cambios significativos (paso 2310) . Una vez que está en una forma completa, el usuario administrativo accede a la lista de proveedores o vendedores (paso 2315) para determinar los proveedores o vendedores calificados para la solicitud de licitación con base en el tipo de plantilla de licitaciones y los datos de la solicitud de licitación ingresados (paso 2320) (por ejemplo, con base en la familia del proyecto en conjunción con la ubicación geográfica anticipada del trabajo) . Si la lista de vendorsa calificados es insuficiente (paso 2325) , el usuario administrativo también puede consultar la base de datos de nivel superior (como se muestra en la FIG. 6) por loe vendedores correspondientes adicionales, para agregar la lista de proveedores o vendedores calificados (paso 2330) . Además de o en lugar de complementar la lista de proveedores o vendedores calificados con los proveedores o vendedores correspondientes de la base de datos de nivel superior, el usuario administrativo también puede ser proveído con la opción de incluir los proveedores o vendedores que no corresponden completamente a todos los datos de la solicitud de licitación (pasos 2335 y 2340) . Una captura de imagen de pantalla de una página de red ejemplificante que despliega todos los proveedores o vendedores potenciales a ser seleccionados para incluirlos en la lista de proveedores o vendedores calificados se muestra e la FIG. 24. El usuario administrativo puede seleccionar los proveedores o vendedores contratados por el cliente o comprador, que corresponden a los datos de la solicitud de licitación y los proveedores o vendedores no contratados que corresponden a los datos de la solicitud de licitación proporcionados por la base de datos de nivel superior. El usuario administratrivo puede seleccionar los proveedores o vendedores para su inclusión en la lista de calificación de proveedores o vendedores con base en cualquier número de factores, incluyendo la experiencia de contratos previos con el proveedor o vendedor, la reputación del proveedor o vendedor y la disponibilidad del proveedor o vendedor. Volciendo a la FIG. 23, una vez que se finaliza la lista de proveedores o vendedores calificados (paso 2345), el usuario administrativo transmite la solicitud de licitación a los proveedores o vendedores calificados (paso 2350), y notifica al creador de al solicitud de licitación sobre el estado de la solicitud de licitación (paso 2355) . Por ejemplo, el creador puede ser notificado de los proveedores o vendedores particulares que recibieron la solicitud de licitación y de cualquier modificación hecha a la solicitud de licitación antes de su transmisión. Los pasos ejemplificantes para la generación y transmisión de las respuestas de los proveedores o vendedores a la licitación, como se muestra de manera general en las FIGs. 1 y 15 en 220, a una solicitud de licitación recibida se muestran en la FIG. 25. En las modalidades ejemplificantes, las solicitudes de licitación se transmiten a los vendirs y se encaminan a los usuarios proveedores o vendedores apropiados con base en las configuraciones de funciones de usuario del proveedor o vendedor, como se discute arriba en conexión con las FIGs. 9-14. Tras la recepción de una solicitud de licitación, un usuario proveedor o vendedor apropiado puede acceder a la solicitud de licitación via un menú o una notificación de control del tablero (paso 2500) . En las modalidades ejemplificantes adicionales, las respuestas a la licitación se transmiten con un acuerdo de confidencialidad de la licitación que compromete al usuario vendir a mantener los contenidos de la solicitud de licitación en confidencia antes de desplegar los contenidos de la bite al usuario proveedor o vendedor. Si el usuario proveedor o vendedor acepta el acuerdo de confidencialidad (por ejemplo, haciendo click sobre un botón de aceptación) (paso 2505), el usuario proveedor o vendedor puede obtener el acceso a los contenidos de la solicitud de licitación (paso 2515) . De otra manera, se notifica al usuario proveedor o vendedor que lois contenidos de la licitación no esteran accesibles y que la solicitud de licitación se retira de la vista del usuario proveedor o vendedor (paso 2510). Para limitar la cantidad de tiempo que tienen los proveedores o vendedores para enviar las respuestas de los proveedores o vendedores a la licitación, la solicitud de licitación puede incluir también un marco de tiempo dentro del cual el proveedor o vendedor debe aceptar respondfer. Si el usuario proveedor o vendedor no puede aceptar responder dentro del marco de tiempo (por ejemplo, haciendo click en un botón de aceptación) (paso 2520), se notifica al usuario proveedor o vendedor que los contenidos de la solicitud de licitación no estaran más disponibles para el usuario proveedor o vendedor y que la solicitud de licitación se retira de la vista del usuario proveedor o vendedor (paso 2525). El cliente o comprador o el administrador del proyecto también se notifica de los proveedores o vendedores que no aceptaron el acuerdo de confidencialidad o las restricciones del marco de tiempo, y con base en el número de proveedores o vendedores sin aceotacion, el cliente o comprador o el administrador del proyecto puede agregar proveedores o vendedores a la lista de proveedores o vendedores calificados y transmite la solicitud de licitación a los proveedores o vendedores adicionales para segurarse de que se reciba un número suficiente de respuestas de los proveedores o vendedores a la licitación. Si el usuario proveedor o vendedor acepta responder dentro del marco de tiempo (paso 2520) , se autoriza al proveedor o vendedor comenzar la compleci?n de la respuesta del proveedor o vendedor a la licitación (paso 2530) . Para responder a la solicitud de licitación, el usuario proveedor o vendedor accede a las selecciones de rubros de la licitación por la sección de la licitación y la categoría de la licitación que requieren los datos de respuesta del proveedor o vendedor para su revisión (paso 2535) . Si el usuario proveedor o vendedor tiene alguna pregunta con respecto a la solicitud de licitación (por ejemplo, el tipo o la cantidad de datos de respuesta del proveedor o vendedor que se requieren) (paso 2540) , el usuario proveedor o vendedor puede enviar las preguntas al cliente o comprador para la clarificación de la licitación, dentro de un marco de tiempo configurado por el cliente o comprador (paso 2545) . Un usuario cliente o comprador apropiado (por ejemplo el creador de la solicitud de licitación o el administrador del proyecto) se notifica de cada pregunta enviada poir un proveedor o vendedor via correo electrónico y/o actualización del tablero de intrumentos (paso 2550) y ese usuario cliente o comprador es responsable de proporcionar una respuesta a las preguntas enviadas dentro de las restricciones de tiempo aplicables (paso 2555) . Los proveedores o vendedores se notifican de las respuestas del cliente o comprador via correo electrónico y/o actualización del tablero de instrumentos (paso 2560). Por ejemplo, un tablero de mensajes de la licitación se puede proporcionar por el sistema, al cual pueden acceder tanto los proveedores o vendedores y los clientes o compradores para una solicitud de licitación particular. Una captura de imagen de pantalla de un tablero 600 de mensajes ejemplificante de la licitación se muestra en la FIG. 27. sólo el cliente o comprador y los proveedores o vendedores que responden a una solicitud de licitación particular pueden acceder al tablero 600 de mensdajes de la licitación. Todos los proveedores o vendedores pueden ser proveídos con el acceso a todas las preguntas enviadas y las respuestas del cliente o comprador, o sólo a los proveedores o vendedores que enviaron las preguntas se les puede permitir visualizar la respuest del cliente o comprador, depoendiendo de los parámetros del cliente o comprador. Además, las preguntas del proveedor o vendedor pueden ser anominas para los proveedores o vendedores y el cliente o comprador o sólo para los proveedores o vendedores, dependiendo de la spreferencias del proveedor o vendedor y/o del cliente o comprador. Volviendo de nuevo a la FIG. 25, si el usuario proveedor o vendedor no tiene ninguna preguntra (paso 2540) o todas las preguntas del vendir han sido respondidas (paso 2560) , el usuario vendir ingresa los datos de respuesta del proveedor o vendedor necesarios en los campos apropiados para las selecciones de rubros de la licitación requeridos en la licitación (paso 2565) . Los datos del respuesta del vendir pueden incluir la información de estimación de costos que incluye los elementos de la estimación de costos (por ejemplo, los requerimientos de recursos, los tipos de gastos, etc.) y la información de cotización (por ejemplo, la starifas de los recursos, las cantidades de gastos, etc.) y la información de los entregables que incluiye los tipos de entregables (por ejemplo, el número de unidades a ser completadas, la información de formación de fases, etc.) y la información de terminación (por ejemplo, la fecha de terminación del proyecto, las fechas de terminación de fase, etc.) . Cada uno de los elementos de la estimación de costos y los tipos de entregables se asocian con una selección direferente de los rubros de la licitación para permitir la comparación efectiva y la calificación de las respuestas de los proveedores o vendedores a la licitación. Los campos de rubros de la licitación pueden ser de varios tipos de datos, tales como texto/moneda/Campos de entradas numéricas y/o campos de opciones seleccionables. Además, los campospueden tener múltiples niveeles de detalle asociados con un rubro de respuesta a la licitación singular para diferentes aspetos del proyecto. Por ejemplo, si un proyecto tiene varias fases, como se determine por el cliente o comprador y/o el proveedor o vendedor, los campos de respuesta del vendoir puede incluir una sección separada para cada fase del proyecto. Tras el intento de envió de la respuesta del proveedor o vendedor a la licitación, el sistema valida la complecion del proveedor o vendedor de todos los campos de datos necesarios para las selecciones de rubros de la licitación en la respuesta del proveedor o vendedor a la licitación (paso 2570) . Si no están completos todos los campos de datos requeridos (paso 2575) , se proporciona al usuario proveedor o vendedor un mensaje del sistema que indica las selecciones de rubros deficientes de la respuesta del proveedor o vendedor a la licitación, y se le pide completar las selecciones de rubros requeridos de la licitación antes de enviar la respuesta del proveedor o vendedor a la licitación (paso 2580) . Una vez que se completan toos los campos de datos para las selecciones de rubros de la licitación en una respuesta a la licitación (paso 2575) , se proporciona al proveedor o vendedor (tras el envió) un mensaje que indica que la respuesta del proveedor o vendedor a la licitación ha sido tramsmitida al cliente o comprador o al administrador del proyecto para su revisión (paso 2585) y se notifivca al cliente o comprador apropiado de una nueva respuesta del proveedor o vendedor a la licitación via correo electrónico y/o la actualización del tablero de instrumentos (2590). Las FIGs. 26A y 26B son capturas de imagen de pantalla de páginas de red ejemplificabtes que se pueden proporcionar al usuario proveedor o vendedor para la geenracion de respuestas a la licitación. El usuario proveedor o vendedor se provee con páginas de red que de spliegan las selecciones de rubros de la licitación dentro de la solicitud e licitación que requieren los datos de respuesta del proveedor o vendedor.

Por ejemplo, como se muestra en la FIG. 26A, el estado de la respuesta del proveedor o vendedor a la licitación se puede desplegar al usuario proveedor o vendedor listando el número de selecciones 235 de rubros de la licitación en cada sección 250, el número de selecciones 235 de rubros de la licitación en cada sección que el usuario proveedor o vendedor debe completar y el número de selecciones 235 de rubros de la licitación en cada sección 50 que deben ser completadas. Además, el usuario proveedor o vendedor puede acceder al tablero de mensajes de la licitación para enviar las preguntas del vendir, ver la respuesta a la licitación en un formato en linea que sea legible fácilmente o enviar curriculos de contratistas potenciales a ser incluidos en la respuesta del proveedor o vendedor a la licitación. Además, una vez que se han completado las respuestas del proveedor o vendedor a todas las selecciones 235 de rubros de la licitación, el usuario proveedor o vendedor puede hacer click en el botón de enviar la respuesta completada de la licitación para su aprobación y/o la transmisión al cliente o comprador o el administrador del proyecto. Para completar una respuesta del proveedor o vendedor a una selección 235 de rubro de la licitación, como se muestra en la FIG. 26B, el usuario proveedor o vendedor puede hacer click sobre la sección 250 de la licitación para desplegar las categorías 255 de la licitación y las selecciones 235 de rubros de la licitación dentro de cada una de las categorías 255 de la licitación. Si se requiere una respuesta del proveedor o vendedor a una selección particular de un rubro de la licitación, el usuario proveedor o vendedor puede ingresar los datos 215 de respuesta del proveedor o vendedor en un campo 238 de datos para la selección 235 de un rubro de la licitación. Como se discute arriba, el campo 238 de datos puede ser un campo de entrada de texto directa o incluye enlaces a otras páginas de red para la selección de los datos 215 de respuesta del proveedor o vendedor apropiados de respuestas de proveedor o vendedor pre-establecidas . Además, el campo 238 de datos puede tener varios niveles, con enlaces a las páginas de red para cada nivel. Además el campo 238 de datos puede ser capaz de ser alimentado con datos directamente desde la base de datos del vdnros con datos 215 de respuesta del proveedor o vendedor por defecto, tales como el nombre del proveedor o vendedor y/o la dirección del proveedor o vendedor. Por ejemplo, tras la recepción de una solicitud de licitación, el módulo del proveedor o vendedor puede biscar las selecciones 235 de rubros de la licitación particulares y alimenta los campos 238 de datos para aquellas selecciones 235 de rubros de la licitación con los datos 215 de respuesta del proveedor o vendedor apropiados .

Un ejemplo de datos de respuesta del proveedor o vendedor seleccionados de respuestas del proveedor o vendedor pre-establecidas se muestrta en la FIG. 28. Si la solicitud de licitación incluye una selección de rubro de la licitación que requiere que el proveedor o vendedor proporcione información de requierimientos de recursos para el proyecto, junto con, por ejemplo, los precios de los recursos asociados con la información de requerimientos dde recursos, el campo 238 de datos puede proporcionar enlaces a otras páginas de red para la selección de los parámetros prestablecidos del perfil de recursos. Por ejemplo, cada perfil de recurtsos puede incdicar un tipo de recurso particular y las habilidades asicadas necesarias para el perfil de recursos. Para facilitar la comparación de los perfiles de recursos y los precion por el cliente o comprador, el vendir puede seleccionarlos de un número de tipos de recursos prestablecidos y las habilidades asociadas. Para implementar las selecciones del tipo de recursos y las habilidades, se puede proporcionar una estructura de base de datos configurable y escalable que permita que los proveedores o vendedores especifiquem los requerimientos de recursos para ser cladsificados en una manera no común. Los ejemplos de estructuras de datos usadas para seleccionar el tipo de recursos y las habilidades asociadas se muestrean en las Tablas 30-37 a continuación. Las estructuras de datos se ilustran pro simplicidad, como organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para desplegar los tipos de recursos y las habilidades asociadas al usuario proveedor o vendedor para seleccionarlos y almacenar el perfil de recursos dentro del campo de datos de la selección del rubro de la licitación asociado. Las tablas se relacionan en una manera jerárquica y relacional, de manera tal que se acceden en un orden particular para desplegar los tipos de recursos y las habilidades asociadas al usuario proveedor o vendedor, como se describirá a continuación en conexión con la FIG. 29, la cual ilustra una estructura 800 de tabla de base de datos que representa un esquema de datos ejemplificante asociado con la repuesta completa del proveedor o vendedor a la licitación, la interrelación entre la repuesta del proveedor o vendedor a la licitación y la solicitud de licitación del cliente o comprador . La tabla 30 de abajo ilustra las categorías del sector de negocios de muestra, tales como industria ligera, administración/profesional, oficina y técnico. Dentro de cada una de las categorías del sector de negocios se encuentra una o más arenas de negocios, como se muestra en la Tabla 31, y dentro de cada una de las arenas de negocios se encuentran una o más familias de negocios, como se muestra en la Tabla 32. Por lo tanto, para seleccionar una familia de negocios particular asociada con el tipo de recursos para la respuesta a la licitación, el usuario proveedor o vendedor puede seleccionar la categoría del sector de negocios y la areana de negocuos para desplegar una lista de familias de negocios para seleccionarlos. Una vez que se selecciona la familia de negocios, las varias habilidades (las funciones generales y habilidades de negocios) asociadas con el tipo de recurso se pueden seleccionar y asignar al tipo de recurso particular, como se muestra en las Tablas 33-37. Por ejemplo, las funciones generales pueden identificar el nivel de experiencia asociado con el tipo de recursos, la categoría de habilidads puede identificar el tiempo de habilidades, entrenamiento y experiencia que posee el tipo de recurso y uno o más conjuntos de habilidades asociados con cada categoría de habilidades puede identificar la experiencia especifica asociada con el tipo de recursos. Además, ciertos conjuntos de habilidades pueden ser enfatizados sobre otros conjuntos de habilidades estableciendo un nivel de prioridad para cada uno de los conjuntos de habilidades del tipo de recurso. Se debe entender que se pueden proporcionar otras selecciones de tipo de recurso y habilidades, y el sistema no se limita a la configuración y la información particular mostrada en las Tablas 30-37. Para una discusión más completa del perfilado de recursos, se hace referencia a la Patente Norteamericana asignada en común, en tramite junto a la presente, con Número de Serie 10/128,751, la cual se incorpora aqui como referencia en su totalidad.

TABLA 32 Tabla Eem lificante de Familias de Ne ocios tblNe Familia) Tabla 34 Tabla de Categorías de Habilidades (tblCategoría) Nombre de Columna Tipo de Datos Longitud Habilidades Categoría ID Int Habilidades Categoría Nvarchar 255 TABLA 36 Asignación de la Familia de Negocios a la Categoría de Habilidades tblFamaHabilidadesCat Tras el envió de la respuesta a la licitación del proveedor o vendedor, todos los campos de selección de rubros de la licitación se llenan con los datos de la licitación (ya sea los datos de la solicitud de licitación o los datos de la respuesta del proveedor o vendedor) , los cuales se almacenan en el sistema (la base de datos del clientes o compradores o la base de datos de proveedores o vendedores) como una licitación en una manera jerárquica y relacional, como sde muestra en la estructura 800 de tabla de base de datos de la FIG. 29. las estructuras de datos ejemplificantes para almacenar los datos de la licitación se muestran a continuación en las Tablas 38-55, las cuales se discutirán en conexión con la FIG. 29. Las tablas 38 y 39 a continuación ilustran los datos ejeplificabtes de la solicitud de licitación asociados con una solicitud de licitación particular que pueden ser almacenados en la base de datos en tablas tblRFX 801 y tblRFXSEleccionadosLicitaciónRubros 802, como se muestra en la FIG. 29. Por ejemplo, en la tabla tblRFX 801 se puede almacenar la información general que concierne a la solicitud de licitación, tal como el número de rastreo de la licitación asignado a la solicitud de licitación por el sistema, el nombre de la solicitud de licitación asignado por el creador, la identidad del creador de la solicitud de licitación, el tipo de plantilla de licitación, el tipo de proyecto, la ubicación del trabajo del proyecto, la cantidad de los gastos presupuestados para el proyecto, el estrado de la solicitud de licitación (por ejemplo, nueva, enviada, evaluada, otorgada, etc.), si los proveedores o vendedores de la base de datos de nivel superior recibieron la solicitud de licitación o no y si se requirió alguna aprobación. Sin embargo, se debe entender que también se puede incluir otra información de la licitación, y el sistema no se limita a la información especifica mostrada en las Tablas 38 y 39. Las selecciones de rubros específicos de la licitación incluidas dentro de la solicitud de licitación y los datos de la solocitud de licitación (comentarios del cliente o comprador) ingresados por el creador para cada una de las selecciones de rubros de la licitación se pueden almacenmar en la tabla tblRFXSEleccionadosLicitaciónRubros 802. Cada selección de rubros de la licitación se puede almacenar como un registro separado en tblRFXSEleccionadosLicitaciónRubros 802, con cada registro que contiene todos los campos mostrados en la Batería objetivo 39 a continuación. La Tabla rfxSEleccionadosLicitaciónRubros 802 se vincula con la tabla de información egenral de la solicitud de licitación tblRFX 801. Como se discute arriba en conexión con la FIG. 10, las selecciones de rubros de la licitación contenidas dentro de la tabla tblRFXSeleccionadosLicitaciónRubros 802 se seleccionan de la tabla tblRFXLicitaciónRubros 403 y se asocian con un tipo de planrtilla de licitación particular almacenado dentro de la tabla tblRFXLicitaciónPlantillas 402 a través de la tabla tblRFXPlantillaRubrosMatriz 404.

TABLA 38 Tabla Principal de Licitación (tblRFX - Vista de la Estructura de la bd) TABLA 39 Tabla de Rubros de Licitación RFX (tblRFXSeleccioandoLicitaciónRvibros La información de muestra perteneciente al envió postal (transmisión) de la solicitud de licitación a los proveedores o vendedores calificados se muestra a continuación en la Tabla 40, la cual se puede almacenmar en la base de datos en la tabla tblRFXEnvío 903 como se muestra en la FIG. 29. En las modalidades ejemplificantes, la información de reparto se relaciona con cada proveedor o vendedor particular que recibe la solicitud de licitación, y puede incluir, por ejemplo, la fecha y la hora en que se envió (envió postal) la solicitud de licitación a los proveedores o vendedores calificados, la identidad del usuario administrativo que envió la solicitud de licitación, la identidad del proveedor o vendedor vcalificado que recibe la solicitud de licitación, el identificador de respuesta a la licitación del proveedor o vendedor, y la calificación asignada al proveedor o vendedor, como se describe a continuación en conexión con las FIGs. 31-35. Sin embargo, se debe entender que se puede incluir otra información, y el sistemo no se limita a la información especifica mostrada en la Tabla 40. Un registro separado para cada proveedor o vendedor que recibe la solicitud de licitación se puede almacenar en la tabla tblRFXEnvio 803, con cada registro que incluue todos los campos mostrados a continuación .

TABLA 40 tblRFXEnvío La información de muestra que pertenece a la recepción de la solicitud de licitación por el proveedor o vendedor y el envió de la respuesta a la licitación del proveedor o vendedor se muestra a continuación en la Tabla 41, la cual se puede almacenar en la base de datos en la tabla RFXResp 804, como se muestra en la FIG. 29. Por ejemplo, tal información de envió de la respuesta puede incluir el identificador de la respuesta a la licitación del proveedor o vendedor, el estado de la respuesta la licitación del proveedor o vendedor, la identidad del proveedor o vendedor, la fecha de envió de la respuesta a la licitación del proveedor o vendedor y las fechas en que el proveedor o vendedor acepta los acuerdos de confidencialidad e intenta responder. Los ejemplos de los tipos de información de estado que puede ser incluida en la tabla tblRFXREsp 804 se muestran a continuación en la Tabla 42, la cual se puede almacenar en la base de datos en la tabla tblRFXRespEStado 805, como se muestra en la FIG. 29. Las tablas tblRFXResp 804 y tblRFXRespEstado 805 se vinculan con la tabla tblRFXEnvio, la cual a su vez, se vincula con tbRFX para asociar la información de envió de ña respuesta del proveedor o vendedor con la información de envió postal de la licitación para la solicitud de licitación. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en las Tablas 41 y 42. Un registro separado para cada respuesta a la licitación de los proveedores o vendedores se puee almacenar en tblRFXResp 804, con cada registro que contiene los campos mostrados en la Tabla 41 a contonuacion.

TABLA 42 Datos Ejemplificantes de tblRFXRespEstado 1 Nuevo 2 Conf?dencialidad_Términos_Aceptados 3 Conf?dencialidad_Términos_No_Aceptados 4 Respuesta Prevista 5 Respuesta Declinada 6 Temporalmente_Salvado 7 Respuesta_Transmitida 8 Licitación_No_Aceptada 9 Esperando Re-Licitación 10 Re-Licitación Declinada 1 1 Licitación Aceptada 12 Licitación En Espera 13 Esperando— Licitación Descripción La tabla 43 a continuación ilustra los datos de muestra de la respuesta del proveedor o vendedor enviada en una respuesta del proveedor o vendedor a la licitación de un proveedor o vendedor a un cliente o comprador, los cuales se pueden almacenar en la base de datos en la tabla tblRFXRespPrincipal 806, copmo se muestra en la FIG. 29. Por ejemplo, tales datos de la respuesta a la licitación del proveedor o vendedor pueden incluir el numero de rastreo de la licitación, el identificador de la respuesta del proveedor o vendedor, la identidad del proveedor o vendedor, la selección particular de rubros de la licitación a la cual ha respondido el proveedor o vendedor, la respuesta del proveedor o vendedor a esas selección particular de rubros, cualquier dato de la solicitud de licitación (comentarios del cliente o comprador) asociado con esa selección particular de rubros de la licitación, el identificador del registro para la respuesta del proveedor o vendedor a la selección particular de rubros de la licitación y cualquier calificación dada a la respuesta del proveedor o vendedor por el cliente o comprador, como se describirá con más detalle a continuación en conexión con las FIGs. 31-35. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 43. Un registro separado para cada selección de rubros de la licitación respondida por el proveedor o vendedor se almacena en tblRFXRespPrincipal 806, con cada registro que contiene los campos mostrados en la Tabla 43 a continuación. La Tabla tblRFRXRespPrincipal 806 se vincula con tblRFX 801 y tblRFXEnvio 803 para asociar la respuesta del proveedor o vendedor a la licitación con la solicitud de licitación.

TABLA 43 tblRFXRes Princi al Asociados con una o más de las respuestas de los proveedores o vendedores a las selecciones de rubros de la licitación "pueden haber uno o más perfiles de recursos de los recursos particulares (contratistas) que el proveedor o vendedor identifica como necesarios para completar el proyecto. Los perfiles de recursos pueden ser cre4ados antes o como parte de la respuesta de la licitación. Los perfiles de recursos se generan usando el sector de negocios, la arena de negocios, la familia de negocios, las funciones generales y las habilidades discutidas arriba en conexión con la FIG. 28 y mostradas en las Tablas 30-37 arriba. Los ejemplos de información del perfil de recursos (el tipo del recurso y las habilidades) para los perfiles de recursos se muestran a continuación en las Tablas 44-46, la cual se puede almacenar en la base de datos en las tablas tblRecursoPerfilPrincipal 807, tblRecursoPerfil PrincipalesHabilidades 816 y tblRecursoPerfilPrincipalGF' s 817, como se , muestra en la FIG. 29. La tabla tblRecusoPerfilPrincipal 807 almacena el tipo de recurso del perfil de recurso (por ejemplo, el sector, el área y la familia de negocios) en tanto que la tabla tblRecursoPerfilPrincipalesHabildiades 816 almacena las habilidades de negocios (los conjuntos de habilidades y las prioridades de los conjuntos de habilidades) asociadas con el tipo de recursos y la tabla tblRecursoPerfilPrincipalGf' s almacena las funciones generales del tipo de recurso. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en las Tablas 44-46. Un registro separado para cada perfil de recursos se incluye en las tablas tblRecursoPerfilPrincipal 807, tblRecursoPerfilPrincipalHabilidades 816 y tblRecursoPerfilPrincipalGF' s 817, con cada uno de los registros que contiene todos los campos mostrados a continuación en las Tablas 45-46. La tabla tblRecursoPerfilPrincipal 807 se vincula con las tablas tblRecursoPerfilPrincipalesHabilidades 816 y tblRecursoPerfilPrincipalGF' s 817 para asociar las funciones generales y los conjuntos de habilidades con el tipo de recursos de cada perfil de recursos. TABLA 44 tblRecursoPerfilPrincipal (vista de la estructura de la bd) La información de muestra relativa a los perfiles de recursos particulares seleccionados enviados con la respuesta a la licitación del proveedor o vendedor se muestran en la Tabla 47 a continuación, la cual se puede almacenar en la tabla tblRFXRecursosPerfiiles 818 en la FIG. 29. Por ejemplo, tal información de perfiles seleccionados puede incluir la identidad del perfil del recurso y la cantidad anticipada de ese perfil de recursos seleccionado particular que es necesaria para completar el proyecto. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 47. Un registro separado para cada perfil de recursos seleccionado para el proyecto se almacena en tblRFXRecursosPerfiles 818, con cada registro que contiene todos los campos mostrados en la Tabla 47 a continuación. La tabla tblRFXRecursosPerfiles 818 se vincula con la tabla tblRFXRecursoPerfilPrincipal 807 para asociar el tipo de recurso particular, las habilidades y las funciones generales con el perfil de recursos seleccionado. La tabla tblRFXRecursosPerfiles 818 se vincula además con la tabla tblRFXSeleccionadosLicitaciónRubros 802 para asociar los perfiles de recursos seleccionados con las selecciones de rubros particulares de la licitación que solicitan los perfiles de recursos.

Dependiendo de la solicitud de licitación, como parte de la respuesta de licitación del proveedor o vendedor a una o más selecciones de rubros de la licitación, el proveedor o vendedor también puede proporcionar información de tarifas asociadas con los perfiles de recursos seleccionadosparticulares para el proyecto. La información de tarifas de recursos de muestra se muestra en la Tabla 48 a continuación, la cual se puede almacenar en la base de datos en la tabla tblRFXREcursosPerfiTarifass 819, como se muestra en la FIG. 29. por ejemplo, tal información de tarifas de los recursos puede incluir el identificador del perfil de recurso, la identidad del registro de respuesta de licitación del proveedor o vendedor para la selección de rubros de la licitación que solicita el perfil del recursos y la información de tarifas, el numero de horas anticipadas que trabajara recurso asociado con el perfil del recurso, la tarifa de facturación asociada con el perfil del recursos y la cantidad de facturación anticipada del recurso asociado con el perfil del recurso. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 48. Un registro separado para cada recurso asociado con uno de los perfiles de recursos seleccionado se almacena en la tabla tblRFXRecursosPerfileTarifas 819, con cada registro que contiene los campos mostrados en la Tabla 48 a continuación. La tabla tblrfxRecursosPerfilTarifas 819 se vincula con la tabla tblRFXRecursosPerfiles 818 para asociar la información de tarifas del recurso para un recurso particular con un perfil de recurso seleccionado particular. Además, la tabla tblRFXRecursosPerfilTarifas 819 se vincula con la tabla tblRFXRespPrincipal 896 y la tabla tblRFXSeleccionadosLicitaciónRubros para asociar la información de tarifas del recurso y el perfil del recurso seleccionado con la respuesta del licitación del proveedor o vendedor a una selección particular de rubros de la licitación. TABLA 48 tblRecursosPerfilesTarifas vista de la estructura de la bd Además de los perfiles de recursos particulares y las tarifas, la respuesta de licitación del proveedor o vendedor puede incluir también, la información relacionada con los tipos de materiales necesarios para el proyecto. La información de materiales de muestra se muestra a continuación en la Tabla 49, la cual se puede almacenar en la base de datos en la tabla tblRFXRespMateriales 822, como se muestra en la FIG. 29. Por ejemplo, tal información de los materiales puede incluir la identidad del registro de la respuesta de licitación el proveedor o vendedor "para la selección de rubros de la licitación que solicita la información de los materiales, el tipo de materiales y el costo de los materiales. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 49. Un registro separado para cada tipo de material se almacena en la tabla tblRFXRespMateriales 822, con cada registro que contiene los campos mostrados en la Tabla 49 a continuación. La tabla tblRFXRespMateriales 822 se vincula con la tabla tblRFXRespPrincipal 806 y la tabla tblRFXSeleccionadosLicitaciónRubros para asociar la información de los materiales con la respuesta de licitación del proveedor o vendedor con una selección particular de rubros de la licitación.

TABLA 49 tblRes Materiales vista de la estructura de la bd La respuesta de licitación del proveedor o vendedor también puede incluir la información relacionada con la formación de fases del proyecto. La información de la formaciónde fases de muestra, se muestra a continuación en la Tabla 50, la cual se puede almacenar en la base de datos en la tabla tblRFXRespFase 823, como se muestra en la FIG. 29. Por ejemplo, para cada fase del proyecto, la información de la formación de fases puede incluir la identidad del registro de la respuesta de licitación del proveedor o vendedor para la selección de rubros de la licitación que solicita la información de formación de fases, el número de la fase particular, una descripción de la fase, la duración anticipada de la fase y los entregables del proyecto al final de la fase (por ejemplo, el número de unidades a ser completadas u otras etapas importantes del proyecto) . Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 50. Un registro separado para cada fase se almacena en la tabla tblRFXRespFase 823, con cada registro que contiene los campos mostrados en la Tabla 50 a continuación. La tabla tblRFXRespFase 823 se vincula con la tabla tblRFXRespPrincipal 806 y la tabla tblRFXSeleccionadosLicitaciónRubros para asociar la información de formación de fases con la respuesta de licitación del proveedor o vendedor a una selección particular de rubros de la licitación.

Todas las preguntas y respuestas enviadas por el proveedor o vendedor y el cliente o comprador en el tablero de mensajes de licitación y cualquier pregunta enviada al proveedor o vendedor por el cliente o comprador con respecto a la respuesta de licitación del proveedor o vendedor también se pueden almacenar en el sistema y se asocian con la respuesta de licitación del proveedor o vendedor particular. La información de preguntas de muestra se muestra en las Tablas 51 y 52 a continuación, la cual se puede almacenar en la base de datos en las tablas tblRFXPreguntasDelVendedor tblRFXPreguntasDelVendedor 820 y tblRFXPreguntasDelComprador 821, como se muestra en la FIG. 29. Un registro separado para cada pregunta del proveedor o vendedor/respouesta del cliente o comprador y pregunta del cliente o comprador/respuesta del proveedor o vendedor se almacena en las tablas tblRFXPreguntasDelVendedor 820 y tblRFXPreguntasDelComprador 821, con cada registro que contiene los campos mostrados en las Tablas 51 y 52 a continuación. Además de las tablas tblRFXPreguntasDelVendedor 820 y tblRFXPreguntasDelComprador 821 se vinculan con la tabla tblRFXRespPrincipal 806 para asociar las preguntas con la respuesta de licitación del proveedor o vendedor particular.

TABLA 51 tblRFXPre untasDelVendedor vista de la estructura de la bd TABLA 52 tblRFXPre untasDelCliente vista de la estructura de la bd La respuesta de licitación del proveedor o vendedor también se puede asociar con los detalles sobre el trabajo de proyectos previos que ha sido llevado a cabo por el proveedor o vendedor para ayudar al proceso de respuesta de licitación. Los detalles del trabajo de proyectos previos se muestran en la Tabla 53 a continuación, los cuales se pueden almacenar en la base de datos en la tabla tblRFXRespRastreoRegistro 824, como se muestra en la FIG. 29. Por ejemplo, tales detalle del trabajo de proyectos previos pueden incluir el identificador de la respuesta del licitación del proveedor o vendedor, el nombre del proyecto, el nombre del cliente o comprador, el valor del proyecto, una descripción del proyecto, una discusión de los recursos desplegados (contratistas) para el proyecto, una discusión del desempeño del proveedor o vendedor, la fecha de inicio del proyecto y la fecha de finalización del proyecto. Se debe entender que se pueden almacenar detalles adicionales del trabajo de proyectos previos, y el sistema no se limita a los detalles del trabajo de proyectos previos específicos mostrados en la Tabla 53.

TABLA 53 tbIRFXRes RastreoRe istro vista de la estructura de la bd Refiriéndonos ahora a la FIG. 30, se ilustra una captura de imagen de la pantalla que una página de red de muestra que despliega las opciones al cliente o comprador para la administración de las solicitudes de licitación y las respuestas de licitación de los proveedores o vendedores. De la pagina de administración de solicitudes de licitación, el usuario cliente o comprador puede enviar una solicitud de licitación completada a un administrador (o a los proveedores o vendedores calificados) , visualizar las respuestas de licitación del proveedor o vendedor a una solicitud de licitación, calificar las respuestas de licitación de los proveedores o vendedores, enviar "peguntas a los proveedores o vendedores sobre las respuestas de licitación de los proveedores o vendedores, solicitar un re-cotización de un proveedor o vendedor, solicitar entrevistas con los proveedores o vendedores o entrevistas de recursos con los recursos (contratistas) potenciales para un proyecto, otorgar la licitación (proyecto) a un proveedor o vendedor particular, asignar los recursos para un proyecto o poner una solicitud de licitación en espera. Una vez que el cliente o comprador ha recibido una o más respuestas de licitación de los proveedores o vendedores para una solicitud de licitación particular, el cliente o comprador puede calificar o comparar de otra manera las respuestas de licitación de los proveedores o vendedores con el fin de determinar cual proveedor o vendedor se adjudicará el proyecto. Con el uso de los rubros de la licitación preestablecidos en la solicitud de licitación y las respuestas de licitación, todas las respuestas de licitación de los proveedores o vendedores tienen el mismo formato, permitiendo una calificación y comparación eficiente y efectiva de las respuestas de licitación de los proveedores o vendedores. Por lo tanto, antes de iniciar la calificación de las respuestas de licitación de los proveedores o vendedores, el cliente o comprador puede seleccionar uno o más rubros de la licitación para propósitos de calificación.

La funcionalidad ejemplificante para seleccionar rubros de la licitación clasificados y respuestas de licitación del proveedor o vendedor, clasificadas, para los rubros de la licitación clasificados seleccionados se muestra en la FIG. 31. Una herramienta 188 de calificación se ilustra en la FIG. 31 para la selección de rubros de la licitación clasificados de las respuestas de licitación de los proveedores o vendedores, de acuerdo con las modalidades de la presente invención. La herramienta 188 de calificación puede incluir cualquier componente fisico, componente lógico y/o soporte lógico inalterable requerido para llevar a cabo las funciones de las herramientas y puede ser implementada dentro del servidor 120 de red o un servidor adicional (no se muestra) En cualquier momento después de la creación de la solicitud de licitación, un clasificador (por ejemplo, el usuario cliente o comprador o el usuario administrador del proyecto) responsable de calificar las respuestas de licitación de los proveedores o vendedores puede acceder a la herramienta 188 de calificación para seleccionar una o más selecciones 235 de rubros de la licitación de la solicitud de licitación para propósitos de calificación. La herramienta de calificación accede a la lista 194 de rubros de la licitación almacenada en la base de datos 155, recupera las selecciones 235 de rubros de la lista 194 de rubros de licitación que se incluye dentro de la solicitud de licitación particular identificada por el clasificador y despliega las selecciones 235 de rubros de la licitación al clasificador via el módulo 101 del cliente o comprador, el servidor 120 de red, la red 40 de datos y el navegador 20a del cliente o comprador para hacer la selección. De las selecciones 235 de rubros de la licitación, el calificador puede seleccionar uno o más rubros 236 de la licitación calificados y proporciona una lista de los rubros 236 de la licitación calificados a la herramienta 188 de calificación. Tras la recepción de una o más respuestas de licitación de los proveedores o vendedores, la herramienta 188 de calificación puede acceder a una lista 192 de respuestas de licitación de los proveedores o vendedores para recuperar los datos 215 de la respuesta del proveedor o vendedor asociados con uno de los rubros 236 de la licitación calificados para una de las respuestas de licitación del proveedor o vendedor en la lista 192. Los datos 215 de la respuesta de rubro de la licitación se despliegan al calificador para propósitos de calificación calificación. Con base en varios factores ( objetivos y subjetivos) relacionados con la calidad y la información incluida en los datos 215 de la respuesta del rubro de la licitación desplegados, el calificador puede asignar una calificación para esa respuesta 215 del rubro y transmite una calificación 269 de la respuesta del rubro de la licitación a la herramienta 188 de calificación. La herramienta 188 de calificación se interconecta además con la base de datos 155 para almacenar la calificación 260 de la respuesta del rubro de la licitación para el proveedor o vendedor en una lista 198 de calificación del proveedor o vendedor que contiene las calificaciones 260 de las respuestas a los rubros de la licitación para todos los rubros 236 de la licitación para cada una de las respuestas a la licitación del proveedor o vendedor en la lista 192 de respuestas 192 a la licitación de los proveedores o vendedores, con base en todas las calificaciones 269 de los rubros de la licitación recibidas por la herramienta 188 de calificación para todos los rubros 236 de la licitación calificados para una respuesta de licitación de un proveedor o vendedor particular, la herramienta 188 de calificación puede calcular una calificación 265 global del proveedor o vendedor para la respuesta de licitación del proveedor o vendedor particular y almacena la calificación 265 del proveedor o vendedor en la lista 198 de calificaciones de proveedores o vendedores . Los pasos ejemplificantes para seleccionar los rubros de la licitación calificados y las respuestas de licitación de los proveedores o vendedores calificadas usando los rubros de la licitación calificados se muestran en las FIGs. 32 y 33. Los pasos de procesamiento principales llevados a cabo para la calificación de las respuestas de licitación se muestran en la FIG. 32. Tras la recepción de las respuestas de licitación de los proveedores o vendedores (paso 3200), se identifican las selecciones de rubros de la licitación a ser usadas para propósitos de calificación (paso 3210). Las selecciones de rubros de la licitación se asocian con la solicitud de licitación que solicita las respuestas de licitación de los proveedores o vendedores, y los datos de respuesta de licitación de los proveedores o vendedores se incluyen en las selecciones de rubros de la licitación elegidos para propósitos de calificación. Las respuestas de la licitación de los proveedores o vendedores se califican (paso 3220) usando los datos de la respuesta de licitación del proveedor o vendedor dentro de los rubros de la licitación calificada. Un proceso de calificación más detallado se muestra en la FIG. 33. Después que se crea una solicitud de licitación, se provee a un usuario cliente o comprador con una lista de las selecciones de rubros de la licitación asociadas con la solicitud de licitación (paso 3330). De la lista de selecciones de rubros de la licitación, se eligen uno o más rubros de la licitación calificada (paso 3305), y a cada rubro de la licitación calificada se le puede asignar un factor de ponderación (por ejemplo, un porcentaje de ponderación) (paso 3310) para ponderar ciertas respuestas con más peso que otras respuestas en la calificación final. Se debe notar que en ciertas modalidades, los factores de ponderación pueden ser iguales, eliminando con ello el requerimiento de que el usuario cliente o comprador ingrese un factor de ponderación especifico. Los factores de ponderación para todos los rubros de la licitación calificada se deben completar entes que se puedan calificar las respuestas de licitación de los proveedores o vendedores (paso 3315) . Una vez que se han elegido todos los rubros de la licitación calificados y se les asigna un valor de ponderación, se provee al calificador con una lista de respuestas de licitación de los proveedor o vendedor s (paso 3320) y se selecciona una de las respuestas de licitación del proveedor o vendedor para propósitos de calificación (paso 3325) . Después, el calificador selecciona uno de los rubros de la licitación calificados (paso 3330) para calificar los datos de la respuesta de licitación del proveedor o vendedor incluidos en los rubros de la licitación calificada (paso 3335) . El calificador puede calificar los datos de la respuesta de licitación del proveedor o vendedor usando cualquier mecanismo disponible para el calificador. En una modalidad el calificador puede preestablecer los criterios de calificación para un rubro de la licitación calificada para permitir que el sistema califique automáticamente los datos de la respuesta del proveedor o vendedor. Por ejemplo para calificar la información de tarifas, el calificador puede pre-asignar calificaciones a los rangos de tarifas específicos, y el sistema puede proporcionar automáticamente una calificación para un rubro de tarifas de la licitación calificada con base en el precio enviado en la respuesta de licitación del proveedor o vendedor. En otras modalidades, el calificador puede comparar inicialmente todos los datos de la respuesta de licitación del proveedor o vendedor para un rubro particular de la licitación calificada, antes de asignar las calificaciones con base en las diferencias relativas entre los datos de las respuestas de licitación de los proveedores o vendedores. Aun otras modalidades adicionales, el calificador puede preestablecer una lista de comprobación o umbrales para cada calificación a ser asignada a un rubro de la licitación calificada . La calificación asignada a los datos de la respuesta del proveedor o vendedor para los rubros de la licitación calificada se almacenan en la base de datos (paso 3340) , y el proceso se repite para cada rubro de la licitación calificada hasta que se califican (paso 3345) los datos de la respuesta del proveedor o vendedor incluidos en cada rubro de la licitación calificada para una respuesta de licitación del proveedor o vendedor particular. Una vez que se han completado todas las calificaciones, el sistema calcula la puntuación total del proveedor o vendedor con base en las calificaciones individuales asignadas a cada rubro de la licitación calificada (paso 3350). Por ejemplo, si las calificaciones posibles son A, B, C y D, la puntuación del proveedor o vendedor se puede calcular asignando cuatro puntos para una A, tres puntos para una B, dos puntos para una C y un punto para una D. Cada respuesta de licitación de los proveedores o vendedores se califica de la misma manera (paso 3335) para permitir que las calificaciones de los proveedores o vendedores se clasifican en orden descendente (paso 3360) para desplegarlas al usuario cliente o comprador (paso 3365) . Además de la puntuación total, también se provee al calificador con las calificaciones individuales para los rubros de la licitación calificada, para determinar si son necesarios algunas re-cotizaciones. Al proveer al calificador con las puntuaciones totales y las calificaciones individuales, el calificador puede terminar visualmente cual proveedor o vendedor tuvo la mayor puntuación global y cuales proveedores o vendedores tuvieron las mayores calificaciones para los rubros particulares de la licitación calificadas con el fin de hacer una decisión en cuanto al proveedor o vendedor al que se le otorgará el proyecto. Sin embargo, se debe entender que se pueden usar otras técnicas de comparación de respuestas de licitación con el sistema de la presente invención, en lugar de la calificación y puntuación especifica descrita aqui. Las capturas de imagen de pantalla de las paginas 61 de red ejemplificantes que se pueden desplegar al calificador para la selección de los rubros de la licitación calificada y la calificación de las respuestas de licitación de los proveedores o vendedores se muestran en las FIGs. 34A-34E. En la FIG. 34A, la página de red contiene una lista de selecciones 235 de rubros de la licitación para que el calificador los seleccione. Para cada uno de los rubros 236 seleccionados de la licitación calificada o clasificada, el calificador puede ingresar también un porcentaje 850 de ponderación para ese rubro 236 de la licitación calificada. El calificador o clasificador puede ajustar los porcentajes 850 de ponderación con base en los criterios preestablecidos o las preferencias personales hasta que el porcentaje 850 ponderado total iguale al cien por ciento. Como se discute arriba, en otras modalidades, a todos los rubros 236 de la licitación calificada se les pueden asignar pesos iguales, de manera tal que los porcentajes 850 de ponderación no necesitan ser desplegados o seleccionados por el calificador. Con el fin de calificar las respuestas de licitación de los proveedores o vendedores, como se muestra en la FIG. 34B, el calificador puede ser proveído con una página de red que lista los rubros 236 particulares de la licitación calificada y que despliega los datos 215 de la respuesta de los rubros de la licitación o bien que proporciona un enlace a los datos 215 de respuesta de la licitación del proveedor o vendedor. Por ejemplo, como se muestra en la FIG. 34C, se puede proporcionar un vinculo al perfil del recurso y la información de las tarifas asociadas del recurso con el fin de calificar un rubro particular de la licitación calificada. Refiriéndonos otra vez a la FIG. 34B, el calificador puede ser proveído además con un indicador para ingresar la calificación 855 para los datos 215 de la respuesta de la licitación del proveedor o vendedor asociados con los rubros 236 de la licitación calificada. En otras modalidades, las calificaciones o clasificaciones pueden ser asignadas automáticamente por el sistema, con base en criterios de calificación preestablecidos . Una vez que se ha calificado la respuesta de la licitación del proveedor o vendedor, como se muestra en la FIG. 34D, el calificador puede ser proveído con una página de red que despliega todos los rubros 236 de la licitación calificada, los porcentajes 850 de ponderación asignados a los rubros 236 de la licitación calificada y la calificación 855 del proveedor o vendedor asignada a cada uno de los rubros 236 de la licitación calificada. Además, la puntuación 860 total del proveedor o vendedor también puede ser desplegada para permitir que el calificador determine la calidad total de la respuesta de licitación el proveedor o vendedor. Refiriéndonos ahora a la FIG. 34E, las respuestas de la licitación de los proveedores o vendedores se pueden comparar lado a lado con base en la puntuación 860 total de los proveedores o vendedores y las calificaciones 855 individuales asignadas a cada uno de los rubros 236 de la licitación calificada. Los ejemplos de estructuras de datos usadas para seleccionar los rubros de la licitación calificada y almacenar las calificaciones de los proveedores o vendedores se muestran en las Tablas 54-56 a continuación. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para desplegar las selecciones de rubros de la licitación al usuario cliente o comprador para seleccionarlos y almacenar las calificaciones y las puntuaciones para las respuestas de licitación de los proveedores o vendedores. Las tablas se relacionan en una manera jerárquica y relacional, como se discutirá en conexión con la FIG. 35.

Las selecciones de rubros de la licitación de muestra que podrian ser incluidos en una solicitud de licitación y la respuesta de licitación el proveedor o vendedor asociada se muestra en la Tabla 54 a continuación. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 54, para cada selección de rubros de la licitación, hay una indicación de si ese rubro de la licitación se puede calificar o no. Por ejemplo, no todas las selecciones de rubros de la licitación pueden incluir datos de respuesta del proveedor o vendedor para calificar. Por lo tanto, sólo se despliegan al usuario cliente o comprador para su selección las selecciones de rubros de la licitación que se pueden calificar.

TABLA 54 Listado Ejemplificante del Proveedor o vendedor de Rubros de la Licitación Calificados Potenciales Por Cate oría Una calificación o clasificación separada se almacena para cada uno de los rubros de la licitación caslificada, como se muestra en la Tabla 55 a continuación, las cuales se pueden almacenar en la estrucyira 1100 de table de base de datos en la tabla tblRFXCalificaciónbRubros 825, como se muestra en la FIG. 35. Junto con la calificación 855 asignada para un rubro 236 particular de la licitación calificada, la tabla tblRFXCalificaciónRubros 825 también puede incluir la identidad del calificador de usuario cliente o comprador, el porcentaje 850 de ponderación asignado al rubro 236 de la licitación calificada y el identificador de la respuesta de licitación del proveedor o vendedor con la calificación 855. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 55. Cada calificación 855 del proveedor o vendedor para cada proveedor o vendedor se almacena en un registro separado en la tabla tblRFXCalificaciónRubros 825, con cada registro que contiene los campos mostrados abajo en la Tabla 55. Además, la tabla tblRFXCalificaciónRubros 825 se vincula con la tabla tblRFXRespPrincipal 806, la cual se vincula con la tabla tblRFX 801, ambas de las cuales se describen arriba en conexión con la FIG. 29, con el fin de asociar la calificación 855 del proveedor o vendedor con la respuesta de licitación del proveedor o vendedor y la solicitud de licitación. Además, la tabla tblRFXCalificaciónRubros 825 se vincula con la tabla tblRFXSEleccionadosLicitaciónRubros 802 para asociar la calificación 855 del proveedor o vendedor con las selecciones particulares 235 de rubros de la licitación.

TABLA 55 Tabla de Rubros de la Licitación Calificada tblRFXCalificaciónRubros Las puntuaciones 865 calculadas para cada una de las calificaciones 855 de los proveedores o vendedores para cada rubro 235 de la licitación se puedena lmacenar como se muestra a contidnuacion en la Tabla 56, la cual se puede almacenar en la base de datos en la tabla RFXRubroPuntuaciónProveedor 826, como se muestra en la FIG. 35. Un registro separado para cada rubro de la licitación calificada para cada respuesta de licitación de los proveedores o vendedores se almacena en la tabla tblRFXRubroPuntuaciónProveedor 826, con cada registro que contiene los campos mostrados en la Tabla 56. Además, la puntuación 860 total basada en todas las puntuaciones 865 del proveedor o vendedor almacenados en la tabla tblRFXRubroPuntuaciónProveedor 826 se puede almacenar en la Tabla 57 a continuación, la cual se puede almacenar en la base de datos en la tabla tblRFXPuntuaciónProveedor 827, como se muestra en la FIG. 35. Un registro separado para cada respuesta de licitación de los proveedores o vendedores se almacena en la tblRFXPuntuaciónProveedor 827, con cada registro que contiene los campos mostrados en la Tabla 57. La tabla tblRFXRubroPuntuaciónProveedor 826 se vincula con la tabla tblRFXCalificaciónRubros 825 para asociar cada puntuación 865 con la calificación 855 pertinente para todos los rubros 236 de la licitación calificada para una respuesta de licitacióndel proveedor o vendedor. Además, la tblRFXPuntuaciónProveedor 827 se vincula con la tabla tblRFXRubroPuntuaciónProveedor 826 pata asociar todas las puntuaciones 865 para todos los rubros 236 de la licitación calificada para una respuesta de licitación del proveedor o vendedor con la puntuación 860 total para esa respuesta de licitación del proveedor o vendedor particular. Además, la tabla tblRFXPuntuaciónProveedor 827 se vincula con la tabla tblRFXEnvio 803, la cual se describe arriba en conexión con la FIG. 29, para actualizar la tabla tblRFXEnvio con la puntuación 860 del proveedor o vendedor.

TABLA 56 Tabla de Puntuación de Rubros del Proveedor o Vendedor tblRFXRubroPuntuaciónProveedor) TABLA 57 Tabla de Puntuación del Proveedor o vendedor tblPuntuaciónProveedor) Después que se recibe y se califica la respuesta de licitación el proveedor o vendedor, el cliente o comprador puede proporcionar la oportunidad para que un proveedor o vendedor envié una re-cotizacion en uno o más rubros de nid calificados para mejorar la puntuación del proveedor o vendedor. Por ejemplo, un proveedor o vendedor que el usuario cliente o comprador elige tiepicfamenté o que tiene calificaciones altas en otros rubros de la licitación calificadas puede tener una puntuación mejor que otro proveedor o vendedor, y el usuario cliente o comprador puede desear proporcionar al proveedor o vendedor la oportunidad para revisar los datos de la respuesta de licitación del proveedor o vendedor para el uno o más rubros de la licitación calificada que tiene calificaciones o grados bajos. Los pasos ejemplificantes para facilitar el proceso de re-cotizacion se muestran en la FIG. 36. Cuando el calificador se percata de una o más clificaciones bajas para un proveedor o vendedor particular en uno o más rubros de la licitación calificada, el calificador puede invitar al proveedor o vendedor a re-cotuzar en uno o más de los rubros de la licitación calificada (paso 3600 y 3610) . La invitación para re-cotizar (paso 3620) puede identificar sólo los rubros particulares de la licitación calificada que se permite que el proveedor o vendedor re-cotice para evitar que el proveedor o vendedor re-cotice cualquier otro de los rubros de la licitación calificada que el calificador no desea re-calificar. Por ejemplo, la re-cotización puede incluir una copia de la respuesta de licitación original del proveedor o vendedor y permite sólo aquellos rubros de la licitación re-cotizados a ser seleccionados por el usuario proveedor o vendedor para ingresar nuevos datos de la respuesta del proveedor o vendedor. Los datos de la respuesta del proveedor o vendedor anteriores se pueden borrar o almacenar junto con los nuevos datos de respuesta en la base de datos para propósitos de referencia. Además, la invitación de recotización puede indicar la calificación del proveedor o vendedor para cada rubro de la licitación re-cotizado, junto con la posición del proveedor o vendedor para cada rubro de la licitación re-cotizado, y otra información similar, tal como las calificaciones del proveedor o vendedor altas y bajas para los rubros de la licitación re-cotizados. Si el proveedor o vendedor elige no re-cotizar dentro del marco de tiempo limitado por el cliente o comprador (paso 3630), se aplican las calificaciones y el puntaje originales del proveedor o vendedor a la respuesta de la licitación del proveedor o vendedor (paso 3640). Sin embargo, si el proveedor o vendedor no re-cotiza en uno o más de los rubros de la licitación re-cotizados (paso 3660), el usuario proveedor o vendedor puede ingresar nuevos datos de la respuesta del proveedor o vendedor en los campos de los rubros de la licitación para los rubros de la licitación re-cotizados seleccionados (paso 3650). Tras la recepción de la re-cotización (paso 3660), el calificador califica los rubros de la licitación re-cotizados usando los nuevos datos de la respuesta del proveedor o vendedor y modifica la puntuación del proveedor o vendedor en consecuencia (paso 3670). Los pasos ejemplificantes para otorgar la licitación e ingrsar los parámetros de rastreo del proyedcto se muestran en la FIG. 37. Una vez que se completan todas las calificaciones y puntuaciones de los proveedores o vendedores (paso 3700) la licitación puede ser otorgada a uno de los proveedores o vendedores. Si el usuario cliente o comprador tiene la autoridad para seleccionar el proveedor o vendedor con base en la puntuación del proveedor o vendedor y otos factores (por ejemplo, las preferencias personales, el conocimiento de la reputación del proveedor o vendedor, el conocimiento de la disponibilidad del proveedor o vendedor, etc.) (paso 3705), el usuario cliente o comprador pyuede seleccionar el proveedor o vendedor para el proyecto (paso 3710) . De lo contrario, el proveedor o vendedor con la puntuación más alta se adjudica la licitación (paso 3715). Una vez que se ha seleccionado en proveedor o vendedor para el proyecto, el sistema notifica tanto al administrador del proyecto (paso 3720) y al vendedor premiado (paso 3725) . Después, el vededor premiado y el cliente o entran en negociaciones para finalizar los términos y las condiciones del proyecto, como se hace convencionalmente (paso 3730) . Si el proveedor o vendedor premiado y el cliente o comprador pueden concordar con los términos y/u las condiciones del proyecto (paso 3735), el cliente o comprador puede re-abrir el proveso de licitación para seleccionar un nuevo proveedor o vendedor con base en las calificaciones de los proveedores o vendedores existentes, con base en buevas respuesta de licitación de los proveedores o vendedores o ambas (paso 3740) . Sin embargo, si se acuerdan los términos y las condiciones (paso 3735) , el cliente o comprador y el proveedor o vendedor premiado puede cargar en el sistema varios parámetros de rastreo del proyecto (paso 3745), tales como la fecha de inicio del proyecto, la fecha de finalizcion del proyecto, el costo anticipado del proyecto (cantidad de la requisición) , los recursos asignados, la programación de formación de fase del proyecto, la programación de liberación de pagos del proyecto, los entregables del proyecto, los materiales del proyecto y los costos del proyecto para crear una requisición de compra para el proyecto. Se debe entender que se pueden cargar parámetros de rastreo del proyecto adicionales en el sistema para rastrear la realización del proyecto, y el sistema no se limita a los paremytros de rastreo del proyecto descritos aqui. Una vez que se aprueba la requisición de compra por los usuarios de aprobación apropiados para el administrador del proyectop y el proveedor o vendedor (paso 3750), el proyecto puede comenzar. Las capturas de imagen de pantalla de paginas 61 de red ejemplificantes para que el administrador del proyectop y el proveedor o vendedor carguen los parámetros 870 de rastreo del proyecto en el sistema se muestran en las FIGs. 39A y 39B. Para el administrador del proyecto, como se muestra en la FIG. 39A, se puede ingresar diversa información de la requisición en el sistema tal como la fecha de creación de la requisición de comopra, el estado de la requisición de compra (el cual se puede actualizar automáticamente por el sistema) , la cantidad de la requisición de compra, la moneda de la requisición de compra (por ejemplo dólares Norteamericanos), la fecha de inicio del proyecto, y la fecha de finalización del proyecto. Además, el administrador del proyecto también puede ingresar en el sistema varios términos y condiciones del proyecto, tales como la declaración de trabajo, los entregables de mercancías y servicios del proyecto, el contrato del proyecto, los materiales del proyecto, los recursos asignados al proyecto y las tazas facturables, los costos del proyecto, la programación de formación de fases del proyecto y la programación de liberación de pagos del proyecto. Además, el administrador del proyecto puede asignar a usuarios administrativos para varias funciones de usuario administrativo que no han sido asignadas aun para el proyecto. Además, también se pueden ingresar en el sistema parámetros de rastreo financiero del proyecto aplicables, tales como tareas de contabilidad, códigos del libro de contabilidad, códigos de centro de costos, códigos del proyecto, códigos de impuestos y plantas de contabilidad.

Como se muestra en la FIG. 39B, el proveedor o vendedor puede acceder en el sistema los datos ingresados por el cliente o comprador para modificar los parámetros 870 de rastreo del proyecto, ingresados previamente y/o ingresa nuevos parámetros 870 de rastreo del proyecto en el sistema como el administrador del proyecto. Por ejemplo, el proveedor o vendedor puede ingresar uno o más de los temrinos y condiciones del proyecto discutidos arriba. Las partes pueden acordar quien va a ingresar los parámetros 870 de rastreo del proyecto, o ambas partes pueden ingresar y/o modificar los parámetros 870 de rastreo del proyecto, y el sistema puede proporcionar una notificación a ambas partes si se hacen cambios. Se debe entender que se pueden insertar en el sistema otros parámetros de rastreo, y el sistema no se limita a esos parámetros de rastreo mostrados en las FIGs. 39A y 39B. Por ejemplo, como se muestra en las FIGs. 40A y 40B, la información 875 de los impuestos también puede ser ingresada en el sistema como parte de los parámetros 870 de rastreo del proyecto. La información 875 de los impuestos se puede usar por el cliente o comprador y el proveedor o vendedor para asegurarse de que todas las autoridades tributarias y las cantidades de impuestos aplicables sean contabilizadas en el proyecto para propósitos de administración financiera y de responsabilidad tributaria. Como se muestra en las FIGs. 40A y 40B, cuando se crea un número de linea de rubro de la requisición para una actividad, por ejemplo, el material usado por el proveedor o vendedor durante el cirso del proyecto, el cliente o comprador y el proveedor o vendedor pueden designar dentro del sistema toda la información transaccional pertinente que seria necesaria para evaluar apropiadamente los impuestos . Por ejemplo, como se muestra en la FIG. 40A, como parte de la entrada de requisición de material, el cliente o comprador y el proveedor o vendedor puede crear o actualizar la información 875 de impuestos al ingresar la información de ubicación relacionada con la ubicación del cliente o comprador, la ubicación de origen, la dirección de embarque, la dirección de entrega fisica, la ubicación del proveedor o vendedor, etc., toda la cual puede indicar una auitoridad tributaria aplicable. Además, si el cliente o comprador está exento de impuestos, el cliente o comprador puede designar una razón de la exención de los impuestos. Tanto el cliente o comprador como el proveedor o vendedor pueden crear u actualizar además la información 875 de impuestos al ingresar las autoridades tributarias aplicables y las tasas porcentuales de los impuestos. Como se muestra en la FIG. 40B, cuando una orden de compra para una actividad particular se transmite para el pago, el sistema puede acceder a las tas porcentuales de impuestos ingresadas previamente por el cliente o comprador y el proveedor o vendedor para la actividad particular y calcula la cantidad de los impuestos para la orden de compra. La información 875 de impuestos, que incluye las autoridades tributarias, las tasas porcentuales, las cantidades, y otra información transaccional relacionada con los impuestos, se almacena en la base de datos y se ponde a disposición de los usuarios autorizados. Un proceso ejemplificante para ingresar y rocesar la información de impuestos se muestra en la FIG. 40C. Cuando se crea una requisición de compra por el cliente o comprador/administrador que especifica todos los elementos de una actividad del proyecto (parámetros de rastreo del proyecto) , incluyendo el trabajo humano, los gastos, los materiales, entregables, trabajo unitario y otros gastos mescelaneos, la ubicación donde se entregarán o se llevarán a cabo los bienes/servicios (paso 400) y la información tributaria, el sistema puede poner a disposición la requisición de compra que incluye la información tributaria para que el proveedor o vendedor la revise (paso 4005) . En ese momento, el proveedor o vendedor también puede ingresar cualquier información tributaria pertinente en el sistema y aprueba la requisición de compra (pasos 4010 y 4015) . La requisición de compra completa, que incluye tanto la información tributaria del cliente o comprador aprobada por el proveedor o vendedor y la información tributaria del proveedor o vendedor se proporciona al cliente o comprador para su aprobación final 8pasos 4020 y 4025) . Tras la aprobación por el cliente o comprador, la orden de compra del proveedor o vendedor se crea y se envia al proveedor o vendedor (paso 4030) para comenzar el trabajo sobre el proyecto (paso 4035) . Durante el comienzo del proyecto uno o más bienes o servicios designados por la orden de compra se realizan por el proveedor o vendedor (paso 4040) . Si los bienes/servicios se relacionan con gastos de tiempo facturables de un contratista, el contratista completa su tarjeta de registro de tiempo (paso 4045) , como se describirá con más detalle a continuación en conexión con las FIGs. 42-47. Para todos los otros bienes/servicios, el proveedor o vendedor ingresa otra información del comprobante (paso 4050) como se describirá con más detalle a continuación en conexión con las FIGs. 48-50. Después, el comprobante se encamina al usuario cliente o comprador designado para su revisión (paso 4055) . Tras la aprobación del comprobante por el cliente o comprador, el administrador del sistema puede crear un archivo de facturación que importa cualquier cantidad de impuesto aplicable calculada usando las tasas porcentuales de impuestis ingresadas previamente, cuando sea aplicable, y envia una factura al cliente o comprador para el pago de la misma (paso 4060). Después, el cliente o comprador paga al administrador (paso 4065) y el administrador paga al proveedor o vendedor (paso 4070). El administrador mantiene los datos transaccionales financieros en el arhivo de facturación relacionado con el pago del comprobante y otorga el acceo a los datos de transaccones financieras al personal del cliente o comprador o el proveedor o vendedor (paso 4075), y opcionalmente puede cargar los datos de transacciones financieras a la base de datos de nivel superior para su procesamiento siubsecuente (paso 4080), como se describirá con más detalle a continuación en conexión con la FIG. 59. Como otro ejemplo de parámetros de rasteo del proyecto que pueden ser ingresados en el sistema, durante la negociación final, el cliente o comprador puede solicitar al proveedor o vendedor que envié curriculos de candidatos de recursos (contratistas actuales) pata que el cliente o comprador los apruebe, para asegurarse de que se llenen las posiciones de perfiles de recursos en la respuesta de licitación del proveedor o vendedor por los candidatos actuales que tienen los perfiles de recursos. Las estructuras de datos ejemplificantes para el envió de los candidatos de recursos y la revisión de los candidatos de recursos se muestran en las Tablas 58 y 59 a continuación.

La Tabla 58 a continuación ilustra la información de los candidatos de recursos de muestra, que puede ser enviada para cada candidato de recursos, seleccionado por el proveedor o vendedor para una posición del perfil de recursos en el proyecto. Por ejemplo, la información del candidato de recursos puede incluir el número de rastreo de la licitación de la licitación particular (la solicitud de licitación y la respuesta de licitación) asociada con el candidato de recurso, la identidad del perfil del recurso parea el candidato de recurso, la información personal del candidato del recurso, la información del proveedor o vendedor, el curriculo del candidato del recurso y el estado de transmisión del candidato del recurso. La Tabla 59 ilustra diversa información de estado de transmisión del recurso que puede ser incluida en la Tabla 58. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 58.

Los pasos ejemplificantes para aprobar los candidatos de recursos se muestran en la FIG. 38. Para cada perfil del recurso incluido en la respuesta de la licitación del proveedor o vendedor, el proveedor o vendedor envia un curriculo de un candidato de recurso potencial para la posición del perfil del recurso (paso 3800). El cliente o comprador revisa todos los curriculums y asigna los candidatos de recursos calificados a las posiciones del perfil de recursos (paso 3810) . Si uno o más de los candidatos del recursos no son aceptables (por ejemplo, el curriculo no indica que el candidato del recursos tiene las habilidades necesarias para el perfil del recurso) (paso 3820), y no hay otros candidatos aceptables para la posición del perfil del recurso (paso 3830), el cliente o comprador puede re-abrir el proceso de licitación para asegurar otro proveedor o vendedor para el proyecto que pueda proporcionar los recursos necesarios (paso 3840) . Sin embargo, si todas las posiciones del perfil de recursos puedne ser llenados por los candidatos de recursos calificados, el cliente o comprador y/o el proveedor o vendedor ingresa la información de los recursos asociada con cada uno de los candidatos de recursos (contratistas) asignados, en la base de datos de contratistas (paso 3850) . Por ejemplo, se puede ingresar en la base de datos de contratistas la información personal concerniente a los contratistas, tal como el nombre del contratista, dirección, números de teléfono y numero de empleados. Además, se puede ingresar en la base de datos de contratistas la informcion de los contratistas relacionada con el proyecto especifico, tal como el número total de horas facturables autorizadas, la tasa de facturación, la cantidad total y el tipo de gastos autorizados y cualquier acuerdo o documentos que el contrartiusta necesite ejecutar o proporcionar antes de comenzar el trabajo. Una vez que se ingresa la información de los contratistas, el sistema puede autentificar los contratistas para propósitos de registro del tiempo y acceso al sistema (paso 3860). Por ejemplo, el sistema puede aproporcionar un nombre de usuario y contraseña a los contratistas para propósitos de ingreso al sistema y autentificación. Además, el isstema puede requerir que los contratistas ejecuten uno o más acuerdos (por ejemplo, aceptando los términos de los acuerdos en linea) y/o proporcionen uno o más documentos antes de permitirles el acceso al sistema de registro del tiempo. Una captura de imagen de pantalla de una página 61 de red ejemplificante desplegada a un contratrista tras el inicio de sesión y la autentificación iniciales se muestra en la FIG. 42. La página de red lista varios documentos que deben ser ejecutados antes que el contratista pueda comenzar el trabajo en el proyecto. Por ejeplo, el contratista puede necesitar firmar un acuerdo de Propiedad Intelectual, un acuerdo de Confidencialidad, un acuerdo de Código de Conducta y un acuerdo de Aceptación de Trabajo Temporal. Haciendo clic en cada uno de los documentos listados, se puede desplegar al contratista una página de red que muestra el acuerdo y el contratista puede hacer clic sobre un botón de aceptación para ejecutar el acuerdo. Las estructuras de base de datos ejemplficantes para almacenar la información de los contratistas y asegurar que se obtengan los documentos relevantes de los contratistas o sean acordados por el contratista se muestran en las tabls 60-63. La tabla 60 lista varios documentos de muestra que necesitan ser obtenidos de los contratistas o que los contratistas necesitan ejecutar en algún punto durante el proyecto. La tabla 60 también lista las restricciones de tiempo para obtener o ejecutar tales documentos. La tabla 61 lista la información de los contratistas, tal como la identidad del contratista, el número de horas facturables autorizadas, la cantidad de gastos autorizados, la fecha de ejecución de varios documentos y el tipo del contrato. La tabla 62 lista el documento particular e identifica si el contratista ha ejecutado o proporcionado ese documento y la fecha de tal ejecución o entrega. Se debe entender que se almacena un registro separado para cada documento que tiene el formato de la Tabla 62. La tabla 63 ilustra diversa información ejemplificante que identifica los tipos de contratistas, tal como el número de dias que el contratista ha trabajado o no para el cliente o comprador. Sin embargo, se debe entender que se puede incluir otra información, y que el sistema no se limita a la información especifica mostrada en las Tablas 60- 63.

TABLA 60 Tabla E em lificante de Documentos del Contratista TABLA 62 Tabla E em lificante de Fechas de E ecución del Contratista Los ejemplos de estructuras de datos usadas para almacenar los parámetros de rastreo del proyecto se muestran en las Tablas 64-79 a continuación. Las estructuras de datos por simplicidad se ilustran como estando organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para rastrear la realización del proyecto. Las tablas se relacionan en una manera jerárquica y relacional, como se discutirá en conexión con la FIG. 41. La tabla 64 de abajo ilustra la información general de la requisición de compra, la cual puede ser almacenada en la base de datos en la tabla tblCompraReq 1000, como se muestra en la FIG. 41. Por ejemplo, tal información de compra general puede incluir la identidad asignada a la requisición de compra por el sistema, el cliente o comprador y el proveedor o vendedor, la fecha de creación de la requisición, la cantidad de la requisición, el número de rastreo de la licitación para la licitación (la solicitud de licitación y la respuesta de licitación) asociada con la requisición de compra, las fechas de inicio y terminación del proyecto, junto con cualquier otra información petinente de la requisición de compra. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 64. Refiriéndonos ahora a la estructura 1150 de tabla de base de datos en la FIG. 41, la tabla tblCompraReq 1000 se muestra vinculada con la tabla tblCompraReqContratistas 1012 y la tabla tblluContratistasTipos 1013, las cuales incluyen la información en el formato de la estructura de base de datos correspondiente a las Tablas 61 y 63 de arriba, respectivamente, para asociar los contratistas asociados con la requisición de compra.

Las tablas 65-70 ilustran la información de la requisición de compra especifica de muestra asociada con los códigos de impuestos, plantas de contabilidad, centros de costos, códigos del proyecto, asignación de contabilidad y otra información de la requisición de comra especifica del cliente o comprador, todas las cuales se pueden almacenar en la base de datos en las tablas respectivas tblCompraReqlmpuestosCódigo 1001, tblCompraReqAccPlanta 1002, tblCompraRerqAcctCosctosCentro 1003, tblCompraReqProyectoCódigos 1004, tblCompraReqAcctGL 1005, y tblCompraReqAcctAsignación 1006, como se muestra en la FIG. 41. Sin embargo, se debe entender que se pueden incluir tablas e información adicional a la requisición de compra, dependiendo de los requerimientos de la requisición de compra. Las tablas tblCompraReqlmpuestosCódigo 1001, tblCompraReqAccPlanta 1002, tblCompraRerqAcctCosctosCentro 1003, tblCompraReqProyectoCódigos 1004, tblCompraReqAcctGL 1005, y tblCompraReqAcctAsignación 1006, se vinculan con la tabla tblCompraReq 1000 para asociar la información especifica de la requisición de compra con la información general de la requisición de compra.

TABLA 65 tblCom raRe lm uestosCódi os TABLA 66 Las tablas 71-75 a continuación ilustran la información de muestra de pago de la requisición relacionada con la requisición de compra. Por ejemplo, tal información de pago de la requisición puede incluir las cantidades de pago basadas en los entregables del proyecto (por ejemplo, las mercancías o los servicios entregados al final del proyecto o durante las fases del proyecto) , las cantidades de pago basadas en periodos de tiempo, las cantidades de pagos basadas en el número de unidades completadas, las cantidades de pago basadas en los materiales del proyecto y las cantidades de pago basadas en los costos del proyecto. En la FIG. 41, la información de pago de la requisición se muestra como almacenada en la base de datos en las tablas tblCompraReqPagoEntregable 1007, tblComopraReqTiempoPeriodo 1008, tblCompraReqPagoUnidades 1009, tblCompraReqPagoMateriales 1010, y tblCompraReqPagoGastos 1011. Cada una de las tablas tblCompraReqPagoEntregable 1007, tblComopraReqTiempoPeriodo 1008, tblCompraReqPagoUnidades 1009, tblCompraReqPagoMateriales 1010, y tblCompraReqPagoGastos 1011 se muestran vinculadas con la tabla tblCompraReq para asociar la información de pago con la información general de la requisición de compra. Se debe entender que se pueden incluir tablas o información adicionales, dependiendo de los requerimientos de la requisición de compra. Además, se debe entender que se pueden incluir una o más de las tablas de pagos, dependiendo del proyecto. Además, se debe entender que se incluye un registro separado para cada cantidad de pago, el cual tiene el formato de una de las Tablas 71-75 a continuación.

Las tablas 77 y 78 ilustran la información de muestra asociada con las tasas de pagos para los contratistas asignados a la requisición de compra. Por ejemplo, la información de la tasa de pago del contratista puede indicar el tipo de pago (por ejemplo, por hora, fijo, horas extras, etc.) y la cantidad de la tasa de pago (por ejemplo, tasa facturable por hora, tasa facturable por horas extras, cantidad facturable) . La información de las tasas de pago se puede almacenar en la base de datos en las tablas tblCompraReqPagoTasas 1014 y tblContratistaPagoTasaTipo 1015, las cuales se muestrean en la FIG. 41 vinculaadas con la tabla tblCompraReq 1000 para asociar la información de las tasas de pago con la requisición de compra. Se debe entender que un registro para cada tipo de tasa de pago de cada contratista se puede almacenar en la tabla tblCompraReqTasas 1014. Se debe entender además que se pueden incluir tablas o información adicional, dependiendo de los requerimientos de la requisición de compra.

TABLA 76 tblCom raRe Pa oTasas vista de la estructura de la bd TABLA 77 tblContratista Pa oTasaTi o vista de la estructura de la bd Las tablas 78 y 79 ilustran la información de pagos de muestra asociada con los gastos del contratista para los contratistas asignados a la requisición de compra. Por ejemplo, la < información de gastos del contratista se puede indicar el tipo y la cantidad máxima asignada para los gastos. La información de gastos del contratista se puede almacenar en la base de datos en las tablas tblCompraReqPagoContratistaGastos 1016 y tblluComtratistaPAgoGastosTipos 1017, las cuales se muestran en la FIG. 41 vincukladas con la tabla tblCompraReq 1000 para asociar la información de gastos del contratista con la requisición de compra. Se debe entender que un registro separado de gastos del contratista para cada tipo de gastos del contratista se puede almacenar en la tabla tblCompraReqPagoContratistaGastos 1016. Se debe entender además que se pueden incluir tablas o información adicionales, dependiendo de los requerimientos de la requisición de compra.

TABLA 78 tbICom raRe Pa oContratistaGastos vista de la estructura de la bd TABLA 79 tblContratistaPa oGastosTi os vista de la estructura de la bd ACTIVIDAD POST-LICITACION Una vez que ha comenzado el proyecto, el administrador del proyecto (o el cliente o comprador) puede monitorear el progreso del proyecto usando un sistema de registro del tiempo, en el cual los contratistas ingresan el tiempo en tarjetas de registro de tiempo para el trabajo del proyecto realizado. Las tarjetas de registro de tiempo se pueden almacenar para evaluar la realización del proyecto para la información de pagos de la requisición y/o para generar comprobante de pago basados en el tiempo trabajado, dependiendo de la información de pagos de la requisición. Por ejemplo, si la cantidad de pago de la requisición se basó, al menos en parte, en el número anticipado de horas facturables de un contratista particular a una tasa de pago particular, y el contratista completa el proyecto bajo el número anticipado de horas facturables, el administrador del proyecto y el proveedor o vendedor pueden re-negociar la cantidad de pago de la requisición que se estableció inicialmente para el pago basado en entregables, periodos de tiempo o unidades. Refriéndonos ahora a la FIG. 43, se ilustran ahi los pasos ejemplificantes para implementar un sistema de registro del tiempo dentro del sistema de la presente invención. Después que el contratista ha completado toda la documentación necesaria y se le autoriza ingresar al sistema de registro del tiempo, el contraruista puede ingresar al sistema de registro del tiempo (paso 4300) pata ingresar la información de reghistro del tiempo (paso 4310) asociada con el número de horas trabajadas por el contratista en una tarjeta de registro de tiempo (por ejemplo, un registro de tiempo para el contratista) , la información de registro del tiempo se puede ingresar en cualquier momento en quie el sistema de registro del tiempo esté accesible. Por ejemplo, el sistema de registro del tiempo puede estar accesible sólo en horarios específicos (por ejemplo, al fiunal de la semana, al inicio de la semana, etc.) como se determina por el administrador del proyecto o durante los horarios en que el sistema de registro del tiempo no está fuera de linea. Una vez que el contratista ha ingresado la información de registro del tiempo en la tarjeta de registro de tiempo, la tarjeta de registro de tiempo se proporciona al administrador del proyecto (paso 4225) para su revisión y aprobación (paso 4330) . Si no se aprueba la tarjeta de registro de tiempo (paso 4340), el contratista y el proveedor o vendedor son notificados del rechazo de la tarjeta de registro de tiempo (paso 4350) y se intruye al contratista para acceder al sistema de registro del tiempo para modificar la tarjeta de registro de tiempo (paso 4300). Por ejemplo, si el contratista no ha llenado completamente la tarjeta de registro de tiempo, la información de registro del tiempo (por ejemplo, el número de horas) ingresada en la tarjeta de registro de tiempo está fuera de lo normal o lo razonable o el administrador del proyecto tiene conocimiento de que la información de registro de tiempo es incorrecta, la tarjeta de registro de tiempo puede ser rechazada. Si la tarjeta de registro de tiempo se aprueba (paso 4340) , todos los registros aplicables dentro del sistema se actualizan con la información de registro del tiempo (paso 4360) y cualquier comprobante pagable asociado con la información de registro del tiempo se extrae para su procesamiento de cobro (paso 4370) . Por ejemplo, si el pago de la requisición se basa en el número de horas trabajadas dentro de un periodo de tiempo particular, un comprobante pagable necesita ser generado con base en la información de registro del tiempo ingresada por el contratista. Las capturas de imagen de pantalla de paginas 61 de red ejemplificantes proporcionadas al contratista a través del sistema de registro del tiempo se muestran en las FIGs. 44 y 45. Una página principal del sistema de registro del tiempo de muestra se ilustra en la FIG. 44. De la página de red principal, el contratista puede crear una nueva tarjeta de registro de tiempo, recuperar las tarjetas de registro de tiempo guardadas temporalmente para propósitos de terminación o visualizar las tarjetas de registro de tiempo enviadas previamente. Además, si se permite que el contratista ingrese los gastos de contratista (dependiendo de los requisición de compra) , el contratista puede crear un nuevo comprobante de gastos, recuperar un comprobante de gastos guardado temporalmente para su terminación, o visualizar los comprobantes de gastos enviados previamente. Para crear una nueva tarjeta de registro de tiempo (o completar una tarjeta de registro de tiempo guardada temporalmente) , como se muestra en la FIG. 45, el contratista puede ingresar diversa información 1150 de registro del tiempo en la tarjeta 1100 de registro de tiempo. Por ejemplo, el contratista puede ingresar la fecha de trabajo del fin de semana, el código del proyecto para el proyecto y el centro de costos responsable del pago. Además, el contratista pued eingrear el número de horas regulares trabajadas cada dia y el número de horas extras trabajadas cada dia (a cada tasa de pago de horas extras) . Se debe entender que también se puede ingresar otra inofmracion de registro del tiempo por el contratista, y el sistema no se limita a la información de registro del tiempo particular mostrada en la FIG. 45. Una capotura de imagen de pantalla de una página 61 de red de muestra desplegada al administrador del rpoeyctp para la revcision de la starjetas de registro de tiempo enviadas se muestra en la FIG. 46. Además de la información de registro de tiempo ingresada, el administrador del proyecto también puede ser provedido con otra información de la requisición de compra pertinente asociada con las tarjetas de registro de tiempo, tal como la fase actual del proyecto, el código del libro de contabilidad, el código de uso de impuestos, el código de sdsignacion de contabilidad, y el código de la planta de contabilidad. Basado en la información de registro de tiempo desplegada, el administrador del proyecto puede rechazar la tarjeta de registro de tiempo o bien aprobar la tarjeta de registro de tiempo. Si el administrador del proyecto rechza la tarjeta de registro de tiempo, una ventana emergente puede ser desplegada por el administrador del proyecto para proporcionar una razón para el rechazo de la tarjeta de registro de tiempo. Se debe entender que se puede desplegar otra información al administrador del proyecto para propósitos de aprobación de las tarjetas de registro de tiempo y el sistema no se limita a la información especifica mostrada en la FIG. 46. Las estructuras de base de datos para almacenar las tarjetas de registro de tiempo y los comprobantes de gastos de los contratistas se muestran en las Tablas 80-83. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para almacenar las tarjetas de registro de tiempo y los comprobantes de gastos de los contratistas. Las tablas se relacionan en una manera jerárquica y relacional con otras tablas almacenadas en la base de datos, como se discurtira en conexión con la FIG. 47.

La tabla 80 a continuación ilustra la información de registro de tiempo general de muestra, la cual puede ser almacenada en la estructura 1160 de tabla de base de datos en la tabla tblTiempoTarjetal050, como se muestra en la FIG. 47. Por ejemplo, la información de registro del tiempo puede incluir el identificador de las tarjetas de registro de tiempo, el deitnficador de la requisición de compra asociada, el identificador del contratista, el identificador del proveedor o vendedor, una indicación de si el tiempo ingresado es tiempo facturable o no para la generación de un registro de facturación, la fecha de fin de semana asocuiada con la tarjeta de registro de tiempo, la fecha de creación, la fecha de revisión y una indicación de si la tarjeta de registro de tiempo ha sido aprobada o no. Sin embargo, se debe entender qiue se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 80. La tabla tblTiempoTarjeta 1050 se muestra en la FIG. 47 vinculada con la tabla tblCompraReqContratistas 1012, la cual se vincula con la tabla tblCompraReq 1000, ambas de las cuales se discuten arriba en conexión con la FIG. 41, para asociar la tarjeta de registro de tiempo con el contratista y la requisición de compra. Además, en la FIG. 47 se ilustran varias otras tablas mostyradas en la FIG. 41 para mostrar la interrelacion entre las varias tablas de requisición de compra y las tablas de tarjeta de registro de tiempo y de comprobantes de gastos del contratista.

TABLA 80 tblTiem oTar eta E em lificante vista de la estructura de la bd El identificador de estado de la tarjeta de registro de tiempo almacenado en la tabla tblTie poTarj eta 1050 puede ser seleccionado de una tabla tblluTiempoTarjetaEstado 1051, la cual almacena los tipos de estado de las tarjetas de registro de tiempo (por ejemplo, guardada temporalmente, transmitida, aprobada, rechazada, etc.) y sus identificadores de estado de la tarjeta de registro de tiempo. La tabla 81 ilustra la información de registro del tiempo detallada de muestra, la cual puede ser almacenada en la base de datos en la tabla tblTiempoTarjetaDetalles 1052, como se muestra en la FIG. 47. Por ejemplo, tal información detallada de registro de tiempo puede incluir el número de horas ingresadas como trabajadas en un dia particular para un tipo de tasa de pago particular, la tasa de pago asociada con el tipo de tasa de pago y otra información de registro del tiempo detallada. La tabla tblTiempoTarjetaDetalles 1052 se muestra vinculada con la tabla tblTiempoTarjeta 1050 para asociar la información de registro del tiempo detallada con la información de registro del tiempo general. Además, la tabla tblTiempoCarjetaDetalles 1052 se vincula con la tabla tblluDiaCódigo 1053 para asociar el código del dia almacenado en la tabla tblTiempoTarjetaDetalles 1052 con el dia particular. Se debe entender que un registro separado en el formato de la Tabla 81 se almacena en la tabla tblTiempoTarjetaDetalles 1052 para cada tipo de tasa de pago para la cual el contratista ingresa el tiempo. Se debe entender además que se pueden incluir otras tablas e información de registro del tiempo, y el sistema no se limita a las tablas especificas y la información de registro del tiempo mostradas en la FIG. 47.

TABLA 81 tblTiem oTar etaDetalles E em lificante vista de la estructura de la bd La tabla 82 a continuación ilustra la información general del comprobante de gastos del contratista, la cual puede ser almacenada en la base de datos en la tabla tblContratistaGastosComprobante 1054, como se muestra en la FIG. 47. Por ejemplo, tal información general de comprobante de gastos del contratista puede incluir el identificador del comprobante de gastos, el identificador de la requisición de compra asociada, el identificador del contratista, el identificador del proveedor o vendedor, la fecha de fin de semana asociada con el comprobante de gastos, la fecha de creación, la fecha de revisión y una indicación de si el comprobante de gastos ha sido aprobado o no. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 82. La tabla tblContratistaGastosComprobante 1054 se muestra vinculada con la tabla tblCompraReqContratistas 1012, la cual se vincula con la tabla tblCompraReq 1000, ambas de las cuales se discuten arriba en conexión con la FIG. 41, para asociar el comprobante de gastos del contratista con el contratista y la requisición de compra particular.

TABLA 82 tblContratistaGastosCom robante Estándar vista de la estructura de la bd La tabla 83 a continuación ilustra la información detallada ejemplificante del comprobante de gastos de contratista, la cual puede ser almacenada en la base de datos en la tabla tblContratistaGastosComprobanteDetalles 1055, como se muestra en la FIG. 47. Por ejemplo, tal información detalkada di comprobante de gastos puede incluir la cantidad de los gastos de un tipo de gasto particular en un dia particular y otra información detallada de gastos. La tabla tblContratistaGastosComprobanteDetalles 1055 s emuestra vinculada con la tabla tblContratistaGastosComprobante 1054 para asociar la información detallada del comprobante de gastos con la información general del comprobante de gastos. Además, la tabla tblContratistaGastosComprobanteDetalles 1055 se vincula con la tabla tblluDiaCódigo 1053 para asociar el código de dia almacenado en la tabla tblContratistaGastosComprobanteDetalles 1055 con el dia particular. Se debe entender que un registro separado en el formato de la Tabla 83 se almacena en la tabla tblContratistaGastosComprobanteDetalles 1055 para cada tipo de gasto en cada dia para el cual el contratista ingresa una cantidad. Se debe entender además que se pueden incluir otras tablas e información del comprobante de gastos del contratista, y el sistema no se limita a las tablas especificas y la información del comprobante de gastos del contratista, mostrada en la FIG. 47.

TABLA 83 TblContratistaGastosComprobanteDetal.es Estándar (vista de la estructura de la Refiriéndonos ahora a la FIG. 48, hay un número de tipos diferentes de información 1160 del comprobante que puede ser ingresada en el sistema y almacenada en la base de datos 155 para la generación de un comprobante 1180 pagable a ser pagado por el cliente o comprador o el administrador del proyecto al proveedor o vendedor premiado. Por ejemplo, la información 1160 del comprobante puede incluir la información 1160a de registro de tiempo del comprobante, la cual incluye la información 1150 de registro del tiempo (mostrada en la FIG. 45 arriba) ingresada por el contratista y la información de pago de la requisición como se determina por los parámetros 870 de rastreo de trabajo del proyecto ingresados (mostrados en la FIG. 39 y 40 arriba) que pertenecen a la información de registro del tiempo. La información del comprobante puede incluir también la información 1160b del comprobante de gastos, la información 1160c del comprobante de entregables del proyecto, la información 1160d del comprobante de materiales del proyecto, la información 1160e del comprobante de gastos del contratista, la información 1160f del comprobante de terminación de unidades del proyecto y la información 1160g del comprobante de liberación de pagos programados del proyecto. El sistema puede generar automáticamente los comprobantes 1180 pagables con base an a información 1160 del comprobante ingresada previamente en otros contextos (por ejemplo, las entradas de parámetros de rastreo del proyecto, las entradas de registros de tiempo, las entradas de gastos del contratista y/o las entradas de gastos del proyecto) , o el proveedor o vendedor o el cliente o comprador/administrador del proyecto pueden generar los comprobantes 1180 pagables e ingresan varias porciones aplicables de la información 1160 del comprobante (por ejemplo, las entradas de terminación de unidades o las entradas de terminación de entregable) en los comprobantes 1180 pagables. Refiriéndonos ahora a la FIG. 49, se ilustran los pasos ejemplificantes involucrados en un sistema de procesamiento y pago de comprobantes. Inicialmente, se ingresan en el sistema (paso 4400) varios parámetros de rastreo del proyecto (por ejemplo, la información de requisición de compra) y todas las responsabilidades del proveedor o vendedor en cuanto a los bienes y servicios, tanto facturables y no facturables se almacenan en la base de datos (paso 4410). Cuando el proveedor o vendedor proporciona un bien o servicio autorizado (como se determina por las responsabilidades del proveedor o vendedor ingresadas (paso 4420), el proveedor o vendedor accede al sistema para registrar el bien o el servicio llevado a cabo y solicita el pago por el bien o el servicio (paso 4430) . En otras modalidades, el pago puede ser solicitado automáticamente por el sistema a ciertos intervalos de tiempo. El sistema genera un comprobante con base en los parámetros de rastreo del proyecto y otra información del comprobante (por ejemplo, la información de registro del tiempo, los gastos, los materiales, etc.) (paso 4440) y encamina el comprobante al usuario cliente o comprador apropiado o el usuario administrador para la aprobación del comprobante (paso 4450).

Si el comprobante no se aprueba (paso 4460), el proveedor o vendedor se notifica y se le proporciona la opción de re-transmitir el comprobante (paso 4470). Si el comprobante se aprueba (paso 4460), se notifica al proveedor o vendedor de la aprobación del comprobante (paso 4480). Si el comprobante es un comprobante facturable (paso 4490) el comprobante se procesa para el cobro electrónico con base en la programación prescrita (usando las restricciones del sistema o del cliente o comprador) (paso 4495). Por ejemplo, el sistema puede emplear un proceso por lotes para colectar todos los comprobantes de pago para el cliente o comprador (para uno o más de posproyectos) aprobados durante un periodo de tiempo pre-designado. Todos los cobros se pueden generar en un formato basado en las especificaciones del cliente o comprador o en un formato definido por el sistema. El cliente o comprador recibe el (los) cobro (s) (paso 4498) y libera el pago del (de los) cobro (s) al (a los) proveedores o vendedores via un método pre-configurado (por ejemplo, RFI, cheque, etc.) (paso 4499) . Las estructuras de base de datos ejemplificantes para almacenar la información del comprobante en los comprobantes pagables y generar un registro de comprobantes pagados se muestra en las Tablas 84-94 a continuación. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para almacenar la información del comprobante. Las tablas se relacionan en una manera jerárquica y relacional con otras tablas almacenadas en la base de datos, como se discutirá en conexión con la FIG. 50. La tabla 84 a continuación ilustra la información general de los comprobantes de terminación de unidades del proyecto, la cual puede ser almacenada en la estructura 1170 de tabla de base de datos en la tabla tblComprobanteUnidades 1060, como se muestra en la FIG. 50. Por ejemplo, la información general de los comprobantes de terminación de unidades del proyecto puede incluir el identificador del comprobante, el identificador de la requisición de compra asociada, una indicación de si han sido aprobadas las tarjetas de registro de tiempo asociadas con la terminación de la unidad o no, el identificador del proveedor o vendedor, la fecha de final de semana asociada con la información de comprobante, la fecha de creación, la fecha de revisión y una indicación de si ha sido aprobada la información de comprobante o no. La tabla tblComprobanteUnidades 1060 se muestra vinculada con la tabla tblCompraReq 1000, la cual se discute arriba en conexión con la FIG. 41, para asociar la información de los comprobantes con la requisición de compra. Además, varias otras tablas mostradas en la FIG. 41 se ilustran aqui en la FIG. 50 para mostrar la interrelación entre las varias tablas de requisición de compra y las tablas de comprobantes. Se debe entender que un registro separado en el formato de la Tabla 84 se almacena en la tabla tblComprobanteUnidades 1060 para cada comprobante de unidad pagable . Además, aunque no se muewstra, la tabla tblContratistaGastosComprobante 1054, mostrada en la FIG. 47, también se considera una tabla de comprobante para la generación de un comprobante pagable. Se debe entender que se pueden incluir otras tablas e información, y el sistema no se limita a las tablas especificas y la información del comprobante mostrada en la FIG. 50.

TABLA 84 TblCom robanteUnidades vista de la estructura de la bd La Tabla 85 a continuaqcion ilustra la información detallada de los comprobantes de terminación de unidades del proyecto, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteUnidadesDetalles 1061, como se muestra en la FIG. 50. Por ejemplo, tal información detallada de los comprobantes de terminación de unidades del proyecto puede incluir la descripción de la terminación de la unidad, el número de aunidades autorizadas, el costo por unidad, el número de unidades completadas y otra información detallada de los comprobantes de terminación de unidades del proyecto. La tabla tblComprobanteUnidadesDetalles 1061 se muestra vinculada con la tabla tblComprobanteUnidades 1060 para asociar la información detallada de los comprobantes de terminación de unidades del proyecto con la información general de los comprobantes de terminación de unidades del proyecto. Además, la tabla tblComprobanteUnidadesDetalles 1061 se vincula con la tabla tblCompraReqPagoUnidades 1009 para asociar la información de pago de unidades de la requisición con la información de los comprobantes de terminación de unidades del proyecto . Se debe entender que un registro separado en el formato de la Tabla 85 se almacena en la tabla tblComprobanteUnidadesDetalles 1061 para cada comprobante de unidad pagable. Se debe entender además que se pueden incluir otras tablas de información de los comprobantes de terminación de unidades del proyecto, y el sistema no se limita a las tablas especificas y la información de los comprobantes de terminación de unidades del proyecto mostrada en la FIG. 50.

La tabla 86 a continuación ilustra la información general de los comprobantes de información de terminación de tiempo de muestra, la cual se puede almacenar en la base de datos en la tabla tblComprobanteTiempoPago 1062, como se muestra en la FIG. 50. Por ejemplo, la información general de los comprobantes de terminación de tiempo puede incluir el identificador del comprobante de tiempo, el identificador de la requisición de compra asociada, una indicación de si se han aprobado todas las tarjetas de registro de tiempo asociadas con la terminación de tiempo, el identificador del proveedor o vendedor, la fecha de terminación de la semana asociada con la información del comprobante, la fecha de creación y una indicación de si se ha aprobado la información del comprobante o no. La tabla tblComprobanteTiempoPago 1062 se muestra vinculada con la tabla tblCompraReq 1000, la cual se discute arriba en conexión con la FIG. 41, para asociar la información de los comprobantes con la requisición de compra. Se debe entender que un registro separado en el formato de la Tabla 86 se almacena en la tabla tblComprobanteTiempoPago 1062 para cada comprobante de tiempo pagable.

La tabla 87 a continuación ilustra la información detallada de los comprobantes de terminación de tiempo de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteTiempoPagoDetalles 1063, como se muestra en la FIG. 50. Por ejemplo, tal información detallada de los vouchres de terminación de tiempo puede incluir la fecha de inicio del trabajo, la fecha de liberación del pago, la cantidad del pago y otra información detallada de los comprobantes de terminación de tiempo. La tabla tblComprobanteTiempoPagoDetalles 1063 se muestra vinculada con la tabla tblComprobanteTiempoPago 1062 para asociar la información detallada de los comprobantes de terminación de tiempo con la información general de los comprobantes de terminación de tiempo. Además, la tabla tblComprobanteTiempoPagoDetalles 1063 se vincula con la tabla tblCompraReqPagoTiempoPeriodo 1008 para asociar la información del pago de tiempo de la requisición con la información de los comprobantes de terminación de tiempo. Se debe entender que un registro separado en el formato de la Tabla 87 se almacena en la tabla tblComprobanteTiempoPagoDetalles 1063 para cada comprobante de unidad pagable. Se debe entender además que se pueden incluir otras tablas e información de los comprobantes de terminación de tiempo, y el sistema no se limita a las tablas especificas y la información de los comprobantes de terminación de tiempo, mostradas en la FIG. 50.

La Tabla 88 a continuación ilustra la información general de los comprobantes de gastos del proyecto de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteProyectoGastos 1064, como se muestra en la FIG. 50. Por ejemplo, la información general de los comprobantes de gastos del proyecto puede incluir el identificador del comprobante de gastos del proyecto, el identificador de la requisición de compra asociada, una indicación de si se han aprobado todas las tarjetas de registro de tiempo asociadas con los gastos del proyecto (si hay alguno), el identificador del proveedor o vendedor, la fecha de terminación de la semana asociada con la información del comprobante, la fecha de creación, la fecha de revisión y una indicación de si se ha aprobado la información del comprobante o no. La tabla tblComprobanteProyectoGastos 1064 se muestra vinculada con la tabla tblCompraReq 1000, la cual se discute arriba en conexión con la FIG. 41, para asociar la información de los comprobantes con la requisición de compra. Se debe entender que un registro separado en el formato de la Tabla 88 se almacena en la tabla tblComprobanteProyectoGastos 1064 para cada comprobante de gastos del proyecto pagable.

TABLA 88 tblCom robantePro ectoGastos vista de la estructura de la bd La tabla 89 a continuación ilustra la información detallada de los comprobantes de gastos del proyecto de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteGastosDestalles 1065, como se muestra en la FIG. 50. Por ejemplo, tal información detallada de los comprobantes de gastos puede incluir la fecha en que se incurrió en el gasto, una descripción del gasto del proyecto, la cantidad del gasto del proyecto y otra información detallada de los comprobantes de gastos del proyecto. La tabla tblComprobanteGastosDestalles 1065 se muestra vinculada con la tabla tblComprobanteProyectoGastos 1064 para asociar la información detallada de los comprobantes de gastos del proyecto con la información general de los comprobantes de gastos del proyecto. Además, la tabla tblComprobanteGastosDestalles 1065 se vincula con la tabla tblCompraReqPagoproyectoGastos 1011 para asociar la información de pagos de gatos del proyecto de la requisición con la información de los comprobantes de gastos del proyecto.

Se debe entender que un registro separado en el formato de la Tabla 89 se almacena en la tabla tblComprobanteGastosDestalles 1065 para cada vouche de gastos del proyecto pagable. Se debe entender además que se pueden incluir otras tablas e información de los comprobantes de gastos del proyecto, y el sistema no se limita a la información de los comprobantes de gastos del proyecto mostrada en la FIG. 50.

TABLA 89 tblComprobantePro ectoGastosDetalles vista de la estructura de la bd) La tabla 90 a continuación ilustra la información general de los comprobantes de materiales de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteMateriales 1066, como se muestra en la FIG. 50. Por ejemplo, la información general de los comprobantes de materiales puede incluir el identifgicador del comprobantes de materiales, el identificador de la requisición de compra asociada, una indicación de si se han aprobado todas las tarjetas de tiempo asociadas con el material (si hay alguna), el identificador del proveedor o vendedor, la fecha de terminación de la semana asociada con la información del comprobante, la fecha de creación, la fecha de revisión y una dincacion de si se ha aprobado la información del comprobante o no. La tabla tblComprobanteMateriales 1066 se muestra vinculada con la tabla tblCompraReq 1000 para asociar la información de los comprobantes de materiales con la requisición de compra. Se debe entender que un registro separado en el formato de la Tabla 90 se almacena en la tabla tblComprobanteMateriales 1066 para cada comprobante de material pagable.

TABLA 90 tblCom robanteMateriales vista de la estructura de la bd La tabla 91 a continuación ilustra la información detallada de los comprobantes de materiales de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobante aterialesDetalles 1067, como se muestra en la FIG. 50. Por ejemplo, tal información detallada de los comprobantes de materiales puede incluir la fecha en que se incurrió en el gasto del material, el nombre del material, una descripción del material, el número de unidades compradas del material, el costo por unidad del material otra información detallada del comprobante de gastos del proyecto. La tabla tblComprobanteMaterialesDetalles 1067 se muestra vinculada con la tabla tblComprobanteMateriales 1066 para asociar la información detallada de los comprobantes de materiales con la información general de los comprobantes de materiales. Además, la tabla tblComprobanteMaterialesDetalles 1067 se vincula con la tabla pantalla 1010 de recordatorios para asociar la información información de pagos del material de la requisición con la información del comprobante de material. Se debe entender que un registro separado en el formato de la Tabla 91 se almacena en la tabla tblComprobanteMaterialesDetalles 1067 para cada comprobante de material pagable. Se debe entender además que se pueden incluir otras tablas e información de los comprobantes e materiales, y el sistema no se limita a las tabalas especificas y la información de los comprobantes de materiales mostradas en la FIG. 50.

TABLA 91 tblCom robanteMaterialesDetalles vista de la estructura de la bd) La tabla 92 a continuación ilustra la información general de los comprobantes de entregables de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteEntregables 1068, como se muestra en la FIG. 50. Por ejemplo, la información general de comprobantes de entregables puede incluir el identificador de los comprobantes de entregables, el identificador de la requisición de compra asociada, una indicación de si han sido aprobadas todas las tarjetas de registro de tiempo asociadas con los entregables (si hay alguno) , el identificador del proveedor o vendedor, la fecha de terminación de semana asociada con la información de los comprobantes, la fecha de creación, la fecha de revisión y una indicación de si se ha aprobado la información del comprobante o no . La tabla tblComprobanteEntregables 1068 se muestra vinculada con la tabla tblCompraReq 1000, la cual se discute arriba en conexión con la FIG. 41, para asociar la información de los comprobantes con la requisición de compra. Se debe entender que un registro separado en el formato de la Tabla 92 se almacena en la tabla tblComprobanteEntregables 1068 para cada comprobante de entregables pagable. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica, mostrada en la Tabla 92.

TABLA 92 tblCom robanteEntre ables vista de la estructura de la bd La Tabla 93 ilustra la información detallada de los comprobantes de entregables de muestra, la cual puede ser almacenada en la base de datos en la tabla tblComprobanteEntregablesDetalles 1069, como se muestra en la FIG. 50. por ejemplo, tal información detallada de los comprobantes de entregables puede incluir una descripción del entregable, la fecha de terminación anticipada del entregable, la fecha de terminación actual del entregable, la cantidad de pago solicitada y otra información detallada de los comprobantes de entregables. La tabla tblComprobanteEntregablesDetalles 1069 se muestra vinculada con la tabla tblComprobanteEntregables 1068 para asociar la información detallada de los comprobantes de entregables con la información general de los comprobantes de entregables. Además, la tabla tblComprobanteEntregablesDetalles 1069 se vincula con la tabla tblCompraReqPagoEntregables 1007 para asociar la información del pago de entregables de la requisición con la información de los comprobantes de entregables. Se debe entender que un formato separado en el formato de la Tabla 93 se almacena en la tabla tblComprobanteEntregablesDetalles 1069 para cada comprobante de entregables. Se debe entender además que se pueden incluir otras tablas e información de comprobantes de entregables, y el sistema no se limita a las tablas especificas y la información de comprobantes de entregables mostradas en la FIG. 50.

TABLA 93 La Tabla 94 a continuación ilustra la información de muestra de los comprobantes de pago, la cual puede ser almacenada en la base de datos como la tabla tblPagadoComprobanteRegistros 1070, como se muestra en la FIG. 50. Por ejemplo, tal información de comprobantes pagados puede incluir el número de factura, las identidades de las requisiciones de compra asignadas por el cliente o comprador y el proveedor o vendedor, la fecha de aprobación del comprobante, el nombre del aprobador, el tipo de comprobante (por ejemplo, tarjeta de registro de tiempo, gastos del contratista, gastos del proyecto, entregables, terminación de tiempo o de terminación de unidades) y el identificador del comprobante asociado, la cantidad de la factura, la fecha de pago y otra información de los comprobantes pagados.

La tabla tblPagadoComprobanteRegistros 1070 se muestra vinculada con la tabla tblCompraReq 1000, la cual se discute arriba en conexión con la FIG. 41, para asociar la información de los comprobantes pagados con las requisiciones de compra. Se debe entender que un registro separado en el formato de la Tabla 94 se almacena en la tabla tblPagadoComprobanteRegistros 1070 para cada comprobante pagado. Sin embargo, se debe entender que se puede incluir otra información, y el sistema no se limita a la información especifica mostrada en la Tabla 94.

Refiriéndonos ahora a la FIG. 51, se ilustra una captura de imagen de pantalla de una página 61 de red ejemplificante que muestra el estado financiero del proyecto. Esta página de red puede estar accesible en uno o más formatos para el cliente o comprador, el proveedor o vendedor y/o el administrador, dependiendo de las restricciones del sistema. Como se puede observar en la FIG. 51, se pueden desplegar los tipos diferentes de comprobantes de pago, y la cantidad estimada para cada uno de los comprobantes de pago. Además, también se puede rastrear la cantidad actual gastada por cada uno de los tipos de comprobantes de pago y los fondos adicionales estimados a ser gastados para cada uno de los tipos de comprobantes de pago. De esta manera, el cliente o comprador, el proveedor o vendedor y/o el administrador pueden mantener un conocimiento práctico de la realización del proyecto desde una perspectiva financiera. Sin embargo, se debe entender que se puede desplegar otra información financiera en lugar de o además de la información financiera especifica mostrada en la FIG. 51. Además, se debe entender que se puede desplegar otra información relacionada con el proyecto (en vez de o además de la información financiera) dependiendo de la configuración del cliente o comprador, el proveedor o vendedor y/o el administrador, como se discute con más detalle a continuación. ANÁLISIS Y GENERACIÓN DE REPORTES DE DATOS TRANSACCIONALES Durante las actividades pre-licitación y post-licitación descritas arriba, varios datos transaccionales relacionados con el proceso de licitación/proyecto se obtienen del cliente o comprador, el proveedor o vendedor, y/u otras partes (por ejemplo, el administrador) involucrados en el proceso. Como se muestra en la FIG. 58, los datos 1195 transaccionales pueden incluir uno o más componentes: datos 212 de la licitación, parámetros 870 de rastreo del proyecto, información 1160 de los comprobantes y datos 1190 de realización del proyecto. Cada uno de los componentes de los datos 1195 transaccionales se obtiene durante etapas separadas del proceso de licitación/proyecto. Otros componentes también pueden ser incluidos en los datos 1195 transaccionales, tales como la información de calificación de los proveedores o vendedores, la información de criterios de los proveedores o vendedores definidos por el cliente o comprador, la información de productos y otros datos pre-licitación y relacionados con el proyecto. En suma, los datos 1195 transaccionales pueden incluir cualquier datos almacenado en el sistema 150 de base de datos . Por ejemplo, refiriéndonos ahora a la FIG. 52, se ilustra un diagrama de señalización que muestra el intercambio de información entre el cliente o comprador 50, el proveedor o vendedor 10 y el PBMS (de aqui en adelante el sistema) 30. Como se discute arriba, inicialmente un cliente o comprador 50 transmite una solicitud de licitación por medio del sistema 30 al proveedor o vendedor 10 (paso 4500) . La solicitud de licitación contiene los campos de datos que tienen los datos de la solicitud de licitación ingresados en la misma por el cliente o comprador 50 y los campos de datos para que el proveedor o vendedor 10 ingrese los datos de respuesta de las licitaciones. Cuando el proveedor o vendedor 10 ha ingresado los datos de respuesta de la licitación en los campos de datos apropiados, una respuesta de licitación que incluye los datos de respuesta de la licitación se transmite de regreso al cliente o comprador 50 por medio del sistema 30 (paso 4510) . En conjunto, los datos de la solicitud de licitación y los datos de respuesta de la solicitud de licitación forman los datos 212 de la licitación de la licitación completada. Los datos 212 de la licitación se almacenan en la base de datos del sistema en registros asociados con la licitación, como se describe arriba.

Una vez que el cliente o comprador 50 ha otorgado la licitación a un proveedor o vendedor 10 particular, tanto el cliente o comprador 50 y el proveedor o vendedor 10 pueden ingresar los parámetros 870 de rastreo del proyecto (por ejemplo, la información de requisición de compra, la información de impuestos, etc.) en el sistema 30 (paso 4520) para su almacenamiento en la base de datos, junto con los datos 212 de la licitación. Los parámetros 870 de rastreo del proyecto pueden incluir algunos o todos los términos y condiciones de los contratistas, incluyendo las responsabilidades del proveedor o vendedor en cuanto a los bienes y servicios, tanto facturables y no facturables. Cuando el proveedor o vendedor 10 proporciona un bien o servicios autorizado (como se determina por los parámetros 870 de rastreo del proyecto ingresados) , el proveedor o vendedor 10 puede acceder al sistema para enviar un comprobante para solicitar el pago, o la aceptación del cliente o comprador de la terminación en el caso de que la actividad sea no facturable, por el bien proporcionado o el servicios llevado a cabo (paso 4530). Tras la aprobación del comprobante y la facturación subsecuente para el mismo, el cliente o comprador libera el pago al proveedor o vendedor via un método preconfigurado (paso 4540). La información ingresada por el cliente o comprador 50 y el proveedor o vendedor 10 durante el proceso de transmisión y pago del comprobante se almacena como la información 1160 del comprobante en la base de datos. Durante la realización del proyecto, varios datos 1190 de realización del proyecto pueden ser ingresados en el sistema 30, o generados automáticamente tanto por el proveedor o vendedor 10 y el cliente o comprador 50 (paso 4550), como se describirá con más detalle a continuación con respecto a las FIGs. 53-57. Por ejemplo, los 1190 pueden incluir diversa información de estado, tal como la información de tiempo (por ejemplo, una indicación de las lineas de tiempo del proveedor o vendedor tras la terminación de una o más fases o componentes del proyecto) , o información de costos (por ejemplo, el costo actual de uno o más componentes del proyecto en comparación con los costos respectivos proyectados (requisición) ) . Los datos 1190 de realización del proyecto también pueden incluir información especifica del proyecto, tal como la importancia del proyecto o el impacto del proyecto sobre otros aspectos de la compañía, u otra información especifica del cliente. Los datos 212 de la licitación, los parámetros 870 de rastreo del proyecto, la información 1160 de los comprobantes y los datos 1190 de realización del proyecto se almacenan todos en la base de datos del sistema como los datos transaccionales relacionados con la licitación o el proyecto.

Con el acceso a todos estos datos transaccionales, el sistema 30 puede llevar a cabo virtualmente cualquier tipo de análisis deseado y genera reportes basados en el análisis. Por lo tanto, el sistema 30 es operable para recibir solicitudes para ciertos tipos de datos analíticos por el cliente o comprador, el proveedor o vendedor u otros usuarios con acceso a los datos analíticos (paso 4660) . De acuerdo con la solicitud, el sistema 30 lleva a cabo un análisis de los datos transaccionales para generar los datos analíticos (paso 4570) y proporciona los datos analíticos al solicitante (por ejemplo el cliente o comprador 50, el proveedor o vendedor 10 u otros usuarios) (paso 4580) en una vista de reporte. Por ejemplo, un cliente o comprador 50 puede solicitar reportes que contengan datos analíticos relacionados con un proyecto especifico, varios proyectos o varios proveedores o vendedores 10. Los datos analíticos pueden apuntar a información financiera (por ejemplo, detalles de facturación, gastos (pasados, presentes y futuros) y otros tipos de análisis financieros), información del proyecto (por ejemplo, realización del proyecto, actividades futuras del proyecto y planificación del proyecto) , información del proveedor o vendedor (por ejemplo, información financiera del proveedor o vendedor, información operacional del proveedor o vendedor e información de cadenas de abastos) y cualquier otro tipo de información deseada. Además, un cliente o comprador 50 puede solicitar reportes que contienen datos analíticos de la industria relacionados con varios proyectos comisionados por varios clientes o compradores 50. Los datos analíticos de la industria pueden apuntar a información financiera (por ejemplo, el porcentaje total de los costos erogados sobre varios aspectos de un tipo de proyecto o la cantidad porcentual erogada en la industria sobre varios tipos de proyectos), la información del proveedor o vendedor (por ejemplo, el porcentaje puntual del proveedor o vendedor en la industria o el porcentaje de costo sobre/bajo el presupuesto del proveedor o vendedor en la industria) y cualquier otro tipo de información deseada de la industria. Datos analíticos similares pueden ser proporcionados a un proveedor o vendedor 10 u otros usuarios autorizados. Por ejemplo, un proveedor o vendedor 10 o administrador puede solicitar reportes que contienen datos analíticos relacionados con un proyecto especifico o varios proyectos en los cuales el proveedor o vendedor 10 esta involucrado en conducir. Volviendo ahora a la FIG. 53, se ilustra la funcionalidad ejemplificante para ingresar los datos 1190 de realización del proyecto. Una herramienta 121 de realización del proyecto y una herramienta 123 de comparación se ilustran en la FIG. 53 para el ingreso de los datos de realización del proyecto, de acuerdo con las modalidades de la presente invención. La herramienta 121 de realización del proyecto y la herramienta 123 de comparación pueden incluir cualquier componente fisico, componente lógico y/o soporte lógico inalterable requeridos para llevar a cabo las funciones de las herramientas, y se pueden implementar dentro del servidor 120 o un servidor adicional (no se muestra) . Por ejemplo, la herramienta 121 de realización del proyecto y la herramienta 123 de comparación pueden estar residentes en módulos 128 de programa dentro del servidor 120 como se muestra en la FIG. 3B. En una modalidad, los datos 1190 de realización del proyecto pueden ser ingresados directamente en la base de datos 155 por un cliente o comprador, proveedor o vendedor o administrador a través de la herramienta 180 de realización del proyecto. El cliente o comprador, el proveedor o vendedor o el administrador puede acceder al servidor 120 del sistema 100 computarizado por medio del navegador 20a del cliente o comprador, el navegador 20b del proveedor o vendedor o el navegador 20c administrativo, respectivamente, y la red 40 de datos. El módulo 110 del proveedor o vendedor, el módulo 115 del proveedor o vendedor o el módulo 135 administrativo se interconectan con la herramienta 121 de realización del proyecto para enviar las páginas de red al navegador 20a del cliente o comprador, el navegador 20b del proveedor o vendedor o el navegador 20c administrativo, respectivamente, que solicitan los datos de realización del proyecto. la herramienta 121 de realización del proyecto accede a la base de datos 155 llenar los campos de datos de realización del proyecto asociados con un proyecto particular con los datos de realización del proyecto ingresados por el cliente o comprador, el proveedor o vendedor y/o el administrador. Por ejemplo, los datos de realización del proyecto pueden incluir comentarios por el cliente o comprador, el proveedor o vendedor y/o el administrador sobre el estado o la satisfacción personal del proyecto hasta el momento. Tras recibir los datos 1190 de realización del proyecto del cliente o comprador, el proveedor o vendedor o bien el administrador, la herramienta 121 de realización del proyecto puede ser configurada adicionalmente para generar automáticamente un mensaje (por ejemplo un mensaje de correo electrónico) para las partes, informándoles de los nuevos datos 1190 de realización del proyecto, permitiendo por ello que las otras partes ingresen datos 1190 de realización del proyecto adicionales, clarificando, respondiendo o proporcionando datos no relacionados con los datos 1190 de realización del proyecto ingresados previamente.

En otras modalidades, la herramienta 123 de comparación puede ingresar automáticamente los datos 1190 de realización del proyecto en la base de datos 155 con base en una comparación de los parámetros 870 de rastreo del proyecto y la información 1160 de los comprobantes asociadas con un proyecto particular. La herramienta de comparación recupera los parámetros 870 de rastreo del proyecto y la información 1160 de los comprobantes necesarios, de la base de datos 155, lleva a cabo una comparación o análisis de los parámetros 870 de rastreo del proyecto y la información 1160 de los comprobantes, y basada en los resultados de la comparación o el análisis, ingresa cualquier dato 1190 de realización del proyecto en los campos de datos asociados con el proyecto en la base de datos 155. Como un ejemplo, la herramienta 123 de comparación puede ser configurada para monitorear la base de datos 155 en cuanto a nuevas entradas de información 1160 de los comprobantes o de lo contrario, se activa tras la entrada de nueva información 1160 de los comprobantes para comparar la información 1160 de los comprobantes ingresada con los parámetros 870 de rastreo del proyecto almacenados previamente para el proyecto. La información 1160 de los comprobantes puede contener información de costos, tiempos u otra información con la cual compara los parámetros 870 de rastreo del proyecto. los resultados de la comparación se pueden almacenar como los datos 1190 de realización del proyecto en la base de datos 155. Por ejemplo, la información 1160 de los comprobantes podria indicar una cantidad de facturación pagada por el cliente o comprador 50 sobre un proyecto, y la herramienta 123 de comparación puede comparar la cantidad de facturación con la cantidad de la requisición para determinar si existe una discrepancia. En este caso, los datos 1190 de realización del proyecto podrian incluir una indicación del estado del costo, tal como bajo el presupuesto, por arriba del presupuesto, o en el presupuesto, y la cantidad por encima o abajo del presupuesto, si hay alguna. Como otro ejemplo, la herramienta 123 de comparación puede ser configurada para investigar la base de datos 155 por los parámetros 870 de rastreo del proyecto, e ingresa el estado de los parámetros 870 de rastreo del proyecto como los datos 1190 de realización del proyecto. Por ejemplo, la herramienta 123 de comparación puede investigar la base de datos 155 en cuanto a las fechas de terminación objetivo expiradas o los proyectos, e ingresa el número de dias que cada proyecto está atrasado como los datos 1190 de realización del proyecto relacionados con esos proyectos. La herramienta 123 de comparación puede buscar además la información 1160 de los comprobantes relacionados por aquellos proyectos atrasados e ingresa el estado de los proyectos con base en la información 1160 de los comprobantes. Por ejemplo, si el proveedor o vendedor ha enviado un comprobante para el pago, pero el cliente o comprador no ha hecho aun el pago, el estado podria indicar "comprobante transmitido, pago en espera". Los procesos ejemplificantes para ingresar los datos 1190 de realización del proyecto desde varias perspectivas del sistema se muestran en las FIGs. 54-56. La FIG. 54 ilustra los pasos ejemplificantes para que un usuario, tal como un cliente o comprador, proveedor o vendedor o administrador, ingrese los datos de realización del proyecto en el sistema. Tras recibir los datos de realización del proyecto de un usuario asociado con un proyecto (paso 4600), el sistema almacena los datos de realización del proyecto en los campos de datos asociados con el proyecto para su uso y recuperación posterior (paso 4610) . Si las partes (el cliente o comprador, el proveedor o vendedor y el administrador) involucradas en el proyecto han establecido las condiciones para habilitar la divulgación de algunos o todos los datos de realización del proyecto entre las partes, el sistema genera un mensaje para las otras partes informándoles de la recepción de los datos de realización del proyecto de acuerdo con las condiciones establecidas por las partes (paso 4620) . En respuesta al mensaje, las ptras partes pueden elegir ingresar datos de realización del proyecto adicionales que clarifican, responden o proporcionan datos no relacionados con los datos de realización del proyecto ingresados previamente. Si se reciben datos de realización del proyecto adicionales (paso 4630) , el sistema almacena los datos de realización del proyecto adicionales en los campos de datos asociados con el proyecto. Junto con los datos de realización del proyecto ingresados previamente, dentro de la base de datos (paso 4640). La FIG. 55 ilustra los pasos ejemplificantes para ingresar automáticamente los datos de realización del proyecto en el sistema con base en los parámetros de rastreo del proyecto y la información de los comprobantes almacenados previamente. Después que el sistema recibe tanto los parámetros de rastreo del proyecto (paso 4700) y la información de los comprobantes (paso 4710) para un proyecto particular, el sistema puede comparar los parámetros de rastreo del proyecto con la información de los comprobantes (paso 4720) para determinar el estado del proyecto (paso 4730) . El estado del proyecto puede ser ingresado en el sistema y almacenado como los datos de realización del proyecto relacionados con el proyecto (paso 4740) . Por ejemplo, la información de los comprobantes puede indicar la fecha de terminación actual del proyecto en un proyecto, y el sistema puede comparar la fecha de terminación actual del proyecto con la fecha de terminación objetivo del proyecto para determinar si existe una discrepancia. En este caso, los datos de realización del proyecto podrian incluir una indicación del estado, tal como terminación a tiempo, terminación atrasada o terminación antes de tiempo, junto con el número de dias de atraso o de anticipación. La FIG. 56 ilustra los pasos ejemplificantes para ingresar automáticamente los datos de realización del proyecto en el sistema con base en el estado de los parámetros de rastreo del proyecto almacenados previamente. Después que el sistema recibe los parámetros de rastreo del proyecto para un proyecto particular (paso 4750), tal como la fecha de terminación objetivo, el sistema puede investigar la base de datos por las fechas de terminación objetivo expiradas en los proyectos (paso 4760). Si se encuentran fechas de terminación expiradas (paso 4770), el sistema puede determinar el estado del proyecto (paso 4780) con base en cualquier otra información que haya sido recibida, e ingresa el estado del proyecto en el sistema como los datos de realización del proyecto (paso 4790) . Las estructuras de base de datos ejemplificantes para almacenar los datos 1190 de realización del proyecto se muestran en las Tablas 95-112 a continuación. Las estructuras de datos se ilustran por simplicidad como organizadas en un formato de tabla, con cada tabla que incluye todos los campos necesarios para almacenar los datos 1190 de realización del proyecto. Las tablas se relacionan en una manera jerárquica y relacional con otras tablas almacenadas en la base de datos, como se discutirá en conexión con la FIG. 57. Las Tablas 95 y 96 a continuación, ilustran los datos de realización del proyecto de entregables de muestra, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla tblEntregablesRastreoRealización 1080 y la tabla lkpEntregablesEstado 1081, como se muestra en la FIG. 57. Los datos de realización del proyecto de entregables pueden incluir el estado de los entregables como se determina por la tabla lkpEntregablesEstado 1081. Por ejemplo, el estado de los entregables puede ser incompletos-al corriente, incompletos-atrasados, parcialmente completos-al corriente, parcialmente completos-atrasados, completos-a tiempo, completos-atrasados o completos-antes de tiempo. El identificador asociado con el estado puede ser almacenado en la tabla tblentregablesRastreoRealización, junto con el identificador asociado con los parámetros de rastreo del proyecto de entregables almacenados en la tabla tblCompraReqPagoEntregables 1007, el estado actual (por ejemplo el número de dias de atraso o de anticipación) y cualquier nota de los usuarios.

Por ejemplo, si el cliente o comprador, el proveedor o vendedor u otro usuario ha ingresado cualquier comentario relacionado con el estado de los entregables, estos comentarios pueden ser almacenados en la tabla tblEntregablesRastreoRealización 1080. La identidad del usuario que ha ingresado los comentarios, junto con la fecha en que se ingresaron los comentarios se pueden almacenar también, además de los comentarios. Si el sistema se configura para informar al proveedor o vendedor cuando el cliente o comprador ingresa comentarios, el estado de la respuesta del proveedor o vendedor (por ejemplo, aun sin respuesta, sin respuesta, respuesta) también se puede almacenar. Las tablas tblEntregablesRastreoRealización 1080 y lkpEntregablesEstado 1081 se muestran voinculadas con la tabla tblCompraReqPagoEntregables 1007, la cual a su vez se vincula con la tabla tblCompraReq 1000 la cual se discute arriba en conexión con la FIG. 41, para asociar los datos de realización del proyecto con la información de los comprobantes y los parámetros de rastreo del proyecto (por ejemplo la requisición de compra) . Además, varias otras tablas mostradas en la FIG. 41 se ilustran aqui en la FIG. 57 para mostrar la interrelación entre las varias tablas de realización del proyecto, las tablas de los comprobantes y las tablas de requisiciones de compra. Se debe entender que un registro separado en el formato de la Tabla 95 se almacena en la tabla tblEntregablesRastreoRealización 1080 para cada entregable. Se debe entender que se pueden incluir otras tablas y datos de realización del proyecto, y el sistema no se limita a las tablas especificas y los datos de realización del proyecto mostrados en la FIG. 57.

Las Tablas 97 y 98 a continuación ilustran los datos de realización del proyecto de fases de muestra, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla tblFaseRastreoRealización 1082 y la tabla lkpFaseEstado 1083, como se muestra en la FIG. 57. Los datos de realización de fases del proyecto pueden incluir el estado de las fases como se determinan de la Tabla tblFaseRastreoRealización 1082. Por ejemplo, el estado de las fases puede ser abierta-al corriente, abierta-fuera de la fecha, abierta-fecha futura, cerrada-a tiempo, cerrada-fuera de fecha, o cerrada-antes de tiempo. El identificador asociado con el estado se puede almacenar en la tabla tblFaseRastreoRealización, junto con el identificador asociado con los parámetros de rastreo del proyecto de las fases almacenados en la tabla tblCompraReqFaseamiento 1018, la cual puede ser una tabla similar a las tablas mostradas en la FIG. 41, el estado actual (por ejemplo, el número de dias de atraso o de anticipación), y cualquier nota de los usuarios. Por ejemplo si el cliente o comprador el proveedor o vendedor u otro usuario ha ingresado cualquier comentario relacionado con el estado del faseamiento, estos comentarios se pueden almacenar en la tabla tblFaseRastreoRealización 1083. La identidad del usuario que ha ingresado los comentarios, junto con la fecha en que se ingresaron los comentarios también se puede almacenar, además de los comentarios. Si el sistema se configura para informar al proveedor o vendedor cuando el cliente o comprador ingresa comentarios, el estado de la respuesta del proveedor o vendedor (por ejemplo, aun sin respuesta, sin respuesta, respuesta) también puede ser almacenado.

TABLA 97 tblFaseRastreoREaliación E em lificante TABLA 98 Ik FaseEstado E em lificante Las tablas 99 y 100 a continuación ilustran los datos de realización del proyecto de unidades de muestra, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla tblUnidadesRastreoRealización 1084 y la tabla lkpUnidadesEstado 1085, como se muestra en la FIG. 57. Los datos de realización del proyecto de unidades pueden incluir el estado de las unidades como se determina de la tabla lkpUnidadesEstado 1085. Por ejemplo, el estado de las unidades puede ser Incompleta-Al Corriente, Incompleta-Atrasada, Completa-A Tiempo, Completa-Atrasada o Completa-Antes de Tiempo. El identificador asociado con el estado puede ser almacenado en la tabla tblUnidadesRastreoREalización, junto con el identificador asociado con los parámetros de rastreo del proyecto de unidades almacenados en la tabla tblCompraReqPagoUnidades 1009, el estado actual (por ejemplo, el número de dias de atraso o de anticipación) y cualquier nota de los usuarios . Por ejemplo, el cliente o comprador, el proveedor o vendedor o cualquier otro usuario ha ingresado algún comentario relacionado con el estado de las unidades, estos comentarios pueden ser almacenados en la tabla tblUnidadesRastreoRealización 1084. La identidad del usuario que ha ingresado los comentarios, junto con la fecha en la cual se ingresaron los comentarios también pueden ser almacenados, además de los comentarios. Si el sistema se configura para informar al proveedor o vendedor cuando el cliente o comprador ingresa comentarios, el estado de la respuesta del proveedor o vendedor (por ejemplo, aun sin respuesta, sin respuesta, respuesta) también puede ser almacenado .

TABLA 100 Las tablas 101 y 102 a continuación ilustran los datos de realización del proyecto de costos de muestra, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla tblCostosRastreoRealización 1086 y la tabla lkpCostosEstado 1087, como se muestra en la FIG. 57. Los datos de realización del proyecto de costos se puede relacionar con cualquier comprobante pagado para cualquier tipo de comprobante, incluyendo los comprobantes de materiales, los comprobantes de gastos, los comprobantes de entregables, los comprobantes de faseamiento, y los comprobantes de pago de tiempo. Los datos de realización del proyecto de costos se representan por el estado de costos cuando se determinan de la tabla lkpCostosEstado 1087. Por ejemplo, el estado de los costos puede ser sobre presupuestado, sub-presupuestado, o en el presupuesto. El identificador asociado con el estado puede ser almacenado en la tabla tblCostosRastreoRealización, junto con el identificador asociado con la información de los comprobantes almacenada en la tabla tblPagadoComprobanteRegistros 1070, el estado actual (por ejemplo, la cantidad sobre o bajo el presupuesto), y cualquier nota de los usuarios. Por ejemplo, si el cliente o comprador, el proveedor o vendedor u otro usuario ha ingresado cualquier comentario relacionado con el estado de los costos, estos comentarios pueden ser almacenados en la tabla tblCostosRastreoRealización 1086. La identidad del usuario que ha ingresado los comentarios, junto con la fecha en que se ingresaron los comentarios también puede ser almacenada, además de los comentarios. Si el sistema se configura para informar al proveedor o vendedor cuando el cliente o comprador ingresa comentarios, el estado de la respuesta del proveedor o vendedor (por ejemplo, aun si respuesta, sin respuesta, respuesta) también puede ser almacenado.

TABLA 101 tbICostosRastreoRealización E em lificante TABLA 102 lk CostosEstado E em lificante En la FIG. 57 se muestran otras Tablas que contienen datos adicionales relacionados con el proyecto y/o con el proveedor o vendedor o el cliente o comprador, las cuales pueden servir para identificar adicionalmente el tipo del proyecto y otras variables del proyecto que no han sido discutidas expresamente anteriormente. Los datos adicionales también pueden ser incluidos en los datos transaccionales utilizados para propósitos de análisis y generación de reportes. Por ejemplo, la Tabla 103 a continuación ilustra el impacto del proyecto sobre otros aspectos del cliente o comprador, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla lkpProyectoolmpactoCódigo 1072, la Tabla 104 a continuación ilustra la importancia de los entregables, la cual puede ser almacenada en la estructura 1185 de tabla de base de datos en la tabla lkpentregableslmpirtancia, y la Tabla 105 a continuación ilustra el estado de la propiedad del proyecto, la cual puede ser almacenada en la estructura 1185 de tabla de base de datos en la tabla lkpPMPropiedadEstado 1073, como se muestra en la FIG. 57. Otra información relacionada con el proveedor o vendedor y el cliente o comprador puede ser almacenada en tablas adicionales. Por ejemplo, la Tabla 106 a continuación ilustra los datos principales del proveedor o vendedor, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla lkpProveedorPrincipal 1090, y la tabla 107 a continuación ilustra los datos principales del cliente o comprador, los cuales pueden ser almacenados en la estructura 1185 de tabla de base de datos en la tabla lkpClientePrincipal 1095, como se muestra en la FIG. 57. Además, las Tablas 108 y 109 a continuación ilustran la información del nivel del proveedor o vendedor que indica el grupo de nivel al que ha sido asignado el cliente o comprador para el proveedor o vendedor (por ejemplo, los proveedores o vendedores de Nivel 1 son los proveedores o vendedores que se usan típicamente primero o más frecuentemente) , el cual puede ser almacenado en la estructura 1185 de tabla de base de datos en las tablas lkpProvedorNivel 1091 y tblProveedorNivelAsignación 1092, como se muestra en la FIG. 57. Además, las Tablas 110-112 a continuación, ilustran la información de la segmentación de la industria, el consumo y el tamaño del cliente o comprador, la cual puede ser almacenada en la estructura 1185 de tabla de base de datos en las tablas lkpIndustriaSegmentación 1096 y lkpClienteTamañoPerfil 1098, como se muestra en la FIG. 57. La segmentación de la industria puede ser especifica del proyecto o aplicable al cliente o comprador en general.

TABLA 104 TABLA 111 lkbClienteConsumoPerfíl Como se describe arriba en conexión con la FIG. 52, los datos de realización del proyecto forman parte de los datos transaccionales que se almacenan en la base de datos. Refiriéndonos otra vez a la FIG. 58, los datos 1195 transaccionales pueden incluir sólo los datos 212 de la licitación, pero también los parámetros 870 de rastreo del proyecto, la información 1160 de los comprobantes y los datos 1190 de realización del proyecto. Todos los datos 1195 transaccionales se almacenan en el sistema 150 de base de datos de nivel inferior que contiene las bases de datos (155, no se muestran) para los clientes o compradores, los proveedores o vendedores y los administradores. En algunas modalidades, los datos 1195 transaccionales se mantienen sólo en la base 150 de datos de nivel inferior, y por lo tanto, los datos analíticos se restringen sólo a los datos 1195 transaccionales dentro de esa base de datos de nivel inferior. Por ejemplo, un cliente o comprador/administrador o proveedor o vendedor puede no permitir que sus datos transaccionales sean accedidos por cualquier fuente externa (terceros) . En esta situación, para generar los datos analíticos que incluyen los datos transacciones del cliente o comprador/administrador o el proveedor o vendedor, el cliente o comprador/administrador o el proveedor o vendedor se limita sólo a sus datos transaccionales. En otra modalidades, como se muestra en la FIG. 59, todos o parte de los datos 1195 transaccionales pueden ser transferidos a la base 160 de datos de alto nivel (en los sucesivo la base 160 de datos central) para su uso o recuperación posterior para propósitos analíticos. Los datos transaccionales pueden ser transferidos de la base de datos 155 de nivel inferior a la base 160 de datos central en cualquier momento o por cualquier razón. Como un ejemplo, los datos 1195a, 1195b y 1195b transaccionales (colectivamente 1195) almacenados en varias bases de datos 155a, 155b y 155c, de usuario, respectivamente, pueden ser transferidos a la base 160 de datos central para su almacenamiento en la misma. La transferencia puede tener lugar en un proceso a modo de lotes, en el cual, los datos 1195 transaccionales que tienen fechas de creación del registro dentro de un periodo de tiempo especifico, se transfieren en un lote a la base 160 de datos central. Por ejemplo, cada semana todos los datos 1195 transaccionales que tienen fechas de creación del registro para esa semana pueden ser trasferidos en un lote a la base 160 de datos central. Los datos 1195 transaccionales transferidos pueden incluir todos los datos 1195 transaccionales en la base 160 de datos central de nivel inferior o sólo una porción, como se designe por el sistema o el cliente o comprador/administrador y/o el proveedor o vendedor. Por ejemplo, varias porciones de los datos 1195 transaccionales pueden no ser necesarias para propósitos analíticos para toda la industria, y por lo tanto, los datos 1195 transaccionales transferidos a la base 160 de datos central pueden excluir aquellas porciones que son innecesarias. Como otro ejemplo, el cliente o comprador/administrador y/o el proveedor o vendedor puede desear limitar el tipo de datos 1195 transaccionales que se ponen a disposición para la base 160 de datos central por razones de privacidad y otras. Refiriéndonos ahora a la FIG. 60, se ilustra la funcionalidad ejemplificante para generar los datos 270 analíticos. Un módulo, 126 o 127, de generación de reportes se muestra en la FIG. 60 para la generación de los datos 270 analíticos, de acuerdo con las modalidades de la presente invención. El módulo, 126 o 127, de generación de reportes puede incluir, los programas y/o el soporte lógico inalterable requeridos para llevar a cabo las funciones del módulo, y se puede implementar dentro del servidor 120 o 125, respectivamente, o en un servidor adicional (no se muestra) . Por ejemplo, el módulo 126 de generación de reportes puede estar residente en los módulos 128 de programas dentro del servidor 120, como se muestra en la FIG. 3B. Los datos 270 analíticos pueden ser generados usando los datos 1195 transaccionales de una base de datos de nivel inferior (no se muestra específicamente) dentro del sistema 150 de base de datos de nivel inferior o de la base 160 de datos central, dependiendo del tipo de los datos 270 analíticos deseados. Por ejemplo, si un usuario cliente o comprador requiere datos analíticos relacionados sólo con aquellos proyectos asociados con el cliente o comprador, el usuario cliente o comprador accedería a los datos 1195 transaccionales dentro de la base de datos de nivelo inferior del cliente o comprador dentro del sistema 150 de base de datos de nivel inferior. Sin embargo, si el usuario cliente o comprador requiere datos analíticos de la industria relacionados con los proyectos asociados con varios clientes o compradores, el usuario cliente o comprador accedería a los datos 1195 transaccionales dentro de la base 160 de datos central . Para recibir los datos 270 analíticos usando los datos 1195 transaccionales del sistema 150 de base de datos de nivel inferior o bien de la base 160 de datos central, un usuario cliente o comprador, un usuario proveedor o vendedor o un usuario administrativo accede al servidor, 120 o 125, respectivo asociado con la base de datos, 150 o 160, via el navegador 20a del cliente o comprador, el navegador 20b del proveedor o vendedor, o el navegador 20c administrativo, respectivamente y la red 40 de datos. El módulo, 110 o 140, del cliente o comprador, el módulo, 115 o 145, del proveedor o vendedor, o el módulo, 135 o 149, administrativo se interconecta con el módulo, 126 o 127, de generación de reportes para enviar las páginas de red al navegador 20a del cliente o comprador, el navegador 20b del proveedor o vendedor o el navegador 20c administrativo, respectivamente, para ayudar al usuario cliente o comprador, el usuario proveedor o vendedor o el usuario administrativo para generar una solicitud 285 para un tipo especifico de datos 270 analíticos. Por ejemplo, los datos 270 analíticos solicitados puede estar relacionados con varios factores de precios y realización como una función de los datos 1195 transaccionales. Los datos 270 analíticos puede estar relacionados con un sólo proyecto, varios proyectos, varios proveedores o vendedores o varios clientes o compradores, lo último es posible sólo con los datos 1195 transaccionales de la base de datos central. Las diferentes permutaciones y posibilidades para los diferentes tipos de datos 270 analíticos que pueden ser generados se limitan sólo por el tipo y la cantidad de datos 1195 transaccionales que se almacenan. Además, se debe entender que, aunque no se muestra, en otra modalidad, un usuario contratista puede estar capacitado para acceder a los varios datos 270 analíticos los cuales el contratista está autorizado a examinar, tales como el número de horas trabajadas a la fecha por el contratista sobre un proyecto, el número de horas trabajadas en todos los proyectos dentro de cierto periodo de tiempo, la tasa de pago para los diferentes proyectos, la tasa de pago promedio, etc. En algunas modalidades, la solicitud 285 enviada por el usuario puede contener uno o más filtros 280 para enfocar los datos 270 analíticos sobre los datos 1195 transaccionales específicos. Por ejemplo, el usuario puede desear recibir datos 270 analíticos relacionados sólo con aquellos proyectos completados en un área geográfica especifica o asociados con el tipo de proyectos especifico o un segmento de la industria. El módulo, 126 o 127, de generación de reportes usa los filtros 280 para acceder a la base de datos, 150 o 160, para recuperar los datos 1198 transaccionales filtrados que contienen sólo aquellos datos transaccionales que satisfacen los requerimientos de los filtros 280. A partir de los datos 1198 transaccionales filtrados, el módulo, 126 o 127, de generación de reportes genera los datos 270 analíticos. Usando los datos 1195 transaccionales o los datos 1198 transaccionales filtrados, el módulo, 126 o 127, de generación de reportes genera los datos 270 analíticos con base en la solicitud 285. Por ejemplo, si la solicitud 285 es para un reporte financiero que indique los gastos proyectados en los mese futuros sobre los proyectos actuales, el módulo, 126 o 127, de generación de reportes puede acceder a los datos 1195 transaccionales para recuperar los parámetros de rastreo del proyecto relacionados con las cantidades de las requisiciones futuras de los proyectos actuales, y acumula las cantidades de las requisiciones por mes para generar los datos 270 analíticos. Como otro ejemplo, si la solicitud 285 es por un reporte estadístico sobre el porcentaje de gastos sobre varios componentes de los proyectos (por ejemplo, materiales, gastos, entregables, trabajo, etc.) con los proveedores o vendedores de nivel 1, el módulo, 126 o 127, de generación de reportes puede acceder a los datos 1195 transaccionales para recuperar varios datos de la licitación (para determinar los proyectos vinculados con los proveedores o vendedores de nivel 1), los parámetros de rastreo del proyecto, la información de los comprobantes y los datos de realización del proyecto y utiliza varias funciones matemáticas y estadísticas para producir los datos 270 analíticos. El módulo, 126 o 127, de generación de reportes envia al navegador 20a del cliente o comprador, el navegador 20b del proveedor o vendedor y el navegador 20c administrativo las páginas de red que incluyen vistas de reportes que contienen los datos analíticos. Los procesos ejemplificantes para generar varios tipos de datos 270 analíticos usando varios tipos de datos transaccionales se muestran en las FIGs. 61-67. Sin embargo, se debe entender que los procesos mostrados son solamente ejemplos de los numerosos procesos que se pueden llevar a cabo usando el sistema de la presente invención. La FIG. 61 es un diagrama de flujo ejemplificante que describe un proceso para generar los datos analíticos cuando se solicitan por un usuario del sistema. En este proceso, se recibe (paso 4800) una solicitud para los datos analíticos como una función de los datos transaccionales que incluye al menos los datos de la licitación que se recolectaron durante el proceso de licitación en linea. La solicitud puede ser transmitida como una solicitud de búsqueda y/o de clasificación para seleccionar tipos particulares o generales de datos de licitación como se transmiten en las licitaciones. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de datos de la licitación dentro de los tipos seleccionados de datos de la licitación que se usan en la generación de los datos analíticos. Una vez que se identifican y se recuperan los datos transaccionales necesarios, los datos analíticos se generan a partir de los datos transaccionales (paso 4810). Para generar los datos analíticos, se pueden utilizar varias funciones matemáticas y estadísticas para producir una amplia variedad de información solicitada por el usuario. Los datos analíticos se pueden generar a partir de los datos de licitación relacionados con un sólo proyecto, varios proyectos, varios proveedores o vendedores o varios clientes o compradores, y estos se pueden presentar al usuario en una variedad de vistas de reporte. Por ejemplo, las vistas de reporte ejemplificantes incluyen vistas resumido, vistas de agregados, vistas de estimados, vistas estadísticas, vistas de realización de proyectos o cualquier combinación de las mismas. Los datos analíticos pueden ser utilizados por el usuario para una variedad de propósitos, incluyendo evaluar las licitaciones individuales, evaluar el desempeño de los proveedores o vendedores, evaluar los gastos y los ingresos, evaluar la inflación en la industria, producir información de tendencias de la industria, etc.

La FIG. 62 es un diagrama de flujo ejemplificante que describe un proceso para generar datos analíticos que incluyen datos de realización de proyectos agregados a través de proyectos actuales, pasados y/o futuros dentro del sistema. Los datos de realización de proyectos se almacenan por el sistema (paso 4820) como se describe arriba en conexión con las FIGs. 53-56. En este proceso, una solicitud para agregar datos de realización de proyectos se recibe de un usuario autorizado del sistema (paso 4830). La solicitud se puede transmitir como una solicitud de búsqueda y/o clasificación para tipos particulares o generales de datos de realización de proyectos como se recolectan por el sistema. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de datos de realización de proyectos dentro de los tipos seleccionados de datos de realización de proyectos que se usan en la generación de datos analíticos. Se debe entender que la solicitud es para recolectar datos de realización de proyectos a partir de los varios proyectos que se están llevando a cabo por uno o más proveedores o vendedores para uno o más clientes o compradores para agregar los datos de realización de proyectos. Una vez que se identifican y se recuperan los datos de realización de proyectos necesarios, los datos de realización de proyectos agregados se generan (paso 4840) . Para generar los datos de realización de proyectos agregados, se pueden utilizar varias operaciones de análisis aritmético y/o estadístico. Por ejemplo, el sistema puede calcular una variedad de información relacionada con los proyectos, tales como el porcentaje de proyectos que están a tiempo o sub-presupuestados, etc. Los datos de realización de proyectos agregados se pueden presentar al usuario en una variedad de vistas de reporte. Por ejemplo, las vistas de reporte ejemplificantes incluyen vistas resumido, vistas de estimación o vistas estadísticas. Los datos de realización de proyectos agregados pueden ser utilizados por el usuario para una variedad de propósitos, incluyendo evaluar el desempeño individual de un proveedor o vendedor con relación a otros proveedores o vendedores, evaluar los gastos o ingresos pasados, presentes o futuros, evaluar la inflación dentro de una industria, producir información de tendencias de la industria, etc. La FIG. 63 es un diagrama de flujo ejemplificante que describe un proceso para generar datos analíticos que incluyen datos estadísticos agregados de realización de proyectos, relacionados con proyectos individuales. Los datos de realización de proyectos se almacenan por el sistema (paso 4850), como se describe arribe en conexión con las FIGs. 53-56. En este proceso, una solicitud por datos estadísticos agregados de realización de proyectos se recibe de un usuario autorizado del sistema (paso 4860) . LA solicitud puede ser transmitida como una solicitud de búsqueda y/o de clasificación para tipos particulares o generales de datos de realización de proyectos como se recolectan por el sistema. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de información de datos de realización de proyectos dentro de los tipos seleccionados de datos de realización de proyectos que se usan para la generación de los datos analíticos. Se debe entender que la solicitud es para recolectar los datos de realización de proyectos de entre varios proyectos que son llevados a cabo por uno o más proveedores o vendedores para uno o más clientes o compradores, para calcular los datos estadísticos relacionados con los proyectos individuales y agregar los datos estadísticos . Una vez que se identifican y se recuperan los datos de realización de proyectos necesarios, se calculan los datos estadísticos de realización de proyectos para los proyectos individuales ((paso 4870) usando varias operaciones de análisis aritmético y/o estadístico. El análisis estadístico puede calcular una variedad de información sobre unm proyecto, tal como el costo mensual promedio, los gastos promedio, el porcentaje de los costos totales para varios componentes o aspectos del proyecto, etc. Después, los datos estadísticos individuales se agregan para generar los datos estadísticos agregados de realización del proyecto (paso 4880). Los datos estadísticos agregados de realización del proyecto se pueden presentar al usuario en una variedad de vistas de reporte. Por ejemplo, las vistas de reporte ejemplificantes incluyen vistas resumido, vistas de estimación, etc. Al agregar los datos estadísticos a través de varios proyectos que se llevan a cabo por los proveedores o vendedores, el cliente o comprador puede obtener una visión global de los proyectos que se llevan a cabo, para ayudarle a evaluar los proyectos en general. La FIG. 64 es un diagrama de flujo ejemplificante que describe ka generación de datos analíticos con base en los datos transaccionales, donde los datos transaccionales incluyen al menos los datos de la licitación, los parámetros de rastreo del proyecto, y los datos de realización del proyecto. Los datos transaccionales se almacenan en el sistema (paso 4900), como se describe arriba en conexión con la FIG. 52. En este proceso, una solicitud por los datos analíticos se recibe de un usuario autorizado del sistema (paso 4910) . La solicitud puede ser transmitida como una solicitud de búsqueda y/o de clasificación para seleccionar tipos particulares o generales de datos transaccionales como se recolectan por el sistema. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de datos transaccionales dentro de los tipos seleccionados de datos transaccionales que se usan en la generación de los datos analíticos. Una vez que se identifican y se recuperan los datos transaccionales necesarios, los datos analíticos se generan a partir de uno o más componentes de los datos transaccionales (por ejemplo, los datos de la licitación, los parámetros de rastreo del proyecto y/o los datos de realización del proyecto) (paso 4920)- Para generar los datos analíticos se pueden utilizar varias funciones matemáticas y estadísticas para producir una amplia variedad de información solicitada por el usuario. Los datos analíticos se pueden generar a partir de los datos transaccionales relacionados con un proyecto individual, varios proyectos, varios proveedores o vendedores o varios clientes o compradores, y esta se puede presentar al usuario en una variedad de vistas de reporte. Por ejemplo, las vistas de reporte ejemplificantes incluyen vistas resumido, vistas de agregados, vistas de estimación, vistas estadísticas, vistas de realización del proyecto o cualquier combinación de las mismas. Los datos analíticos se pueden desplegar gráficamente para ayudar al usuario a analizar los proyectos o las tendencias de la industria. La FIG. 65 es un diagrama de flujo ejemplificante que describe un proceso más detallado para recolectar los datos transaccionales y generar los datos analíticos a partir de los datos transaccionales. Inicialmente se crea una licitación por el cliente o comprador, donde la licitación incluye campos de datos recibir los datos de la licitación del cliente o comprador y el proveedor o vendedor (paso 4950) . Por ejemplo, los campos de datos pueden permitir que el cliente o comprador y el proveedor o vendedor ingresen los datos de la licitación relacionados con los términos de precio, cantidad y tiempo de adquisición. Se debe entender que los campos de datos incluidos en la licitación se asocian con los rubros seleccionados de la licitación, como se describe arriba en la sección de Actividad de Licitación. Cuando el sistema recibe los datos de la licitación del cliente o comprador y el proveedor o vendedor (paso 4955), los datos de la licitación se almacenan en el sistema como los datos transaccionales (paso 4960) . Tras adjudicar el proyecto, se reciben (paso 4965) los parámetros de rastreo del proyecto para el proyecto relacionado con la licitación y se almacenan como los datos transaccionales (paso 4970) . Durante la realización del proyecto se reciben varios datos de realización del proyecto relacionados con el proyecto (paso 4975) y se almacenan como datos transaccionales adicionales (paso 4980). Una vez que han sido recibidos y almacenados los datos transaccionales, se recibe una solicitud adicional por los datos analíticos como una función de los datos transaccionales ((paso 4985). La solicitud puede ser transmitida como una solicitud de búsqueda y/o de clasificación por el usuario para seleccionar tipos particulares o generales de datos transaccionales como se recolecta por el sistema. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de datos transaccionales dentro de los tipos seleccionados de datos transaccionales que se usan en la generación de los datos analíticos. Una vez que se han identificado y recuperado los datos transaccionales necesarios, se generan los datos analíticos a partir de uno o más componentes de los datos transaccionales (por ejemplo, los datos de la licitación, los parámetros de rastreo del proyecto y/o los datos de realización del proyecto) (paso 4990) . Para generar los datos analíticos se pueden utilizar varias funciones matemáticas y estadísticas para producir una amplia variedad de información solicitada por el usuario. Los datos analíticos pueden ser generados a partir de los datos transaccionales relacionados con un sólo proyecto, varios proyectos, varios proveedores o vendedores o varios clientes o compradores, y estos pueden ser presentados al usuario en una variedad de vistas de reporte. Por ejemplo, lasa vistas de reporte ejemplificantes incluyen vistas resumido, vistas agregadas, vistas de estimación, vistas estadísticas, vistas de realización del proyecto o cualquier combinación de las mismas. Los datos analíticos se pueden desplegar gráficamente para ayudar al usuario a analizar los proyectos o las tendencias de la industria. La FIG. 66 es un diagrama de flujo ejemplificante que describe un proceso para generar datos analíticos industriales como una función de los datos transaccionales producidos por los proyectos de uno o más clientes o compradores. Puesto que el sistema es capaz de manejar los proyectos para varios clientes o compradores, los datos analíticos industriales pueden ser evaluados a partir de los proyectos que se llevan a cabo entre una industria completa. Como una cuestión natural al usar el sistema, los varios proyectos de los clientes o compradores quienes utilizan el sistema pueden ser rastreados via la información transaccional. Al analizar los datos transaccionales entre los varios clientes o compradores, se pueden desarrollar tendencias de la industria. Por ejemplo, en la industria de las telecomunicaciones, donde hay varios proyectos relacionados con la instalación de conmutadores centrales, el costo promedio, el tiempo de desarrollo, el tiempo de instalación, y la tasa de averias de los conmutadores centrales se puede generar utilizando los principios de la presente invención.

Inicialmente, el proceso de análisis de la industria comienza cuando se recibe en el sistema una solicitud por los datos analíticos de la industria (por ejemplo, el servidor 125 administrativo en la FIG. 2A) (paso 5000) . La solicitud puede ser de los proveedores o vendedores, los clientes o compradores o los administradores del sistema. Con base en la solicitud los datos transaccionales relacionados con los varios proyectos entre los varios clientes o compradores se acceden en la base de datos central (paso 5010) . La solicitud se puede transmitir como una solicitud de búsqueda y/o de clasificación por el usuario para seleccionar tipos particulares o generales de datos transaccionales como se recolectan por el sistema. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de datos transaccionales dentro de los tipos seleccionados de datos transaccionales que se usan en la generación de los datos analíticos . Una vez que los datos transaccionales necesarios se identifican y se recuperan, se pueden generar los datos analíticos de la industria como una función de los datos transaccionales (paso 5020) . Para generar los datos analíticos de la industria se pueden utilizar funciones matemáticas y/o estadísticas para producir una variedad de datos analíticos de la industria que el usuario se interesa en examinar. Los datos analíticos de la industria pueden ser presentados al usuario en una variedad de vistas de reporte. Por ejemplo, las vistas de reporte ejemplificantes incluyen vistas resumido, vistas de agregados, vistas de estimación, vistas estadísticas, vistas de realización del proyecto o cualquier combinación de las mismas. Los datos analíticos se pueden desplegar gráficamente para ayudar al usuario a analizar los proyectos o las tendencias de la industria. La FIG. 67 es un diagrama de flujo ejemplificante que describe un proceso más detallado para recolectar los datos transaccionales via un proceso por lotes, de varios clientes o compradores y generar datos analíticos de la industria a partir de los datos transaccionales. Los datos transaccionales para los proyectos individuales se almacenan en las bases de datos de nivel inferior asociadas con los clientes o compradores, los proveedores o vendedores y los administradores relacionados con los proyectos (paso 5050) . Para procesar las solicitudes para los datos analíticos de la industria, los datos transaccionales necesarios y autorizados de cada una de las bases de datos de nivel inferior se recuperan en la base de datos central como un proceso por lotes, como se describe arriba y como se entiende en la técnica (paso 5060). Una vez que los datos transaccionales del lote han sido recuperados y almacenados, se recibe (paso 5070) una solicitud subsecuente por los datos analíticos de la industria como una función de los datos transaccionales del lote. La solicitud puede ser transmitida como una solicitud de búsqueda y/o de clasificación del usuario para seleccionar tipos particulares o generales de datos transaccionales como se recolectan por el sistema. Además, la solicitud puede incluir uno o más filtros para limitar la cantidad de datos transaccionales dentro de los tipos seleccionados de datos transaccionales que se usan para generar los datos analíticos. Con base en la solicitud y cualquier filtro, el sistema accede a los datos transaccionales del lote para identificar y recuperar los datos transaccionales del lote necesarios para llevar a cabo el análisis de la industria solicitado (paso 5080) . Después se generan los datos analíticos de la industria a partir de los datos transaccionales del lote identificados (paso 5090) . Para generar los datos analíticos de la industria se pueden utilizar varias funciones matemáticas y estadísticas para producir una amplia variedad de información solicitada por el usuario. Los datos analíticos de la industria pueden ser presentados al usuario en una variedad de vistas de reporte (paso 5095) . Por ejemplo, las vistas de reporte ejemplificantes incluyen vistas resumido, vistas agregadas, vistas de estimación, vistas estadísticas, vistas de realización del proyecto o cualquier combinación de las mismas. Los datos analíticos de la industria se pueden desplegar gráficamente para ayudar al usuario a analizar los proyectos o las tendencias de la industria. Como se discute arriba, la solicitud de datos analíticos solicitados transmitida por el usuario puede incluir uno o más filtros para personalizar los tipos de datos transaccionales utilizados en el proceso analítico. Refiriéndonos ahora a la FIG. 68, se ilustran los tipos ejemplificantes de filtros 280 que pueden ser usados para acceder a la base de datos, 155 o 160, para recuperar los datos 1198 transaccionales filtrados para propósitos de análisis y generación de reportes. Por ejemplo, los filtros 280 pueden incluir propiedades 280a del perfil del proveedor o vendedor, propiedades 280b del perfil del cliente o comprador, propiedades 280c del perfil del proyecto y propiedades 280d del perfil del producto. Las propiedades 280a del perfil del proveedor o vendedor incluyen cualquier tipo de datos relacionados con el proveedor o vendedor, tales como el grupo del nivel del proveedor o vendedor, el tipo de entidad de negocios del proveedor o vendedor, los datos de calificación del proveedor o vendedor, la ubicación geográfica del proveedor o vendedor, etc. Del mismo modo, las propiedades 280b del perfil del cliente o comprador incluye de manera similar cualquier tipo de datos relacionados con el cliente o comprador, tales como la segmentación de la industria del cliente o comprador, el tamaño o la capacidad de gasto del cliente o comprador, la ubicación geográfica del cliente o comprador, etc. Las propiedades 280c del perfil del proyecto incluyen cualquier tipo de datos relacionados con el proyecto, tales como el tipo del proyecto, el tipo de propiedad administrativa del proyecto, el tipo de impacto de negocios, la ubicación geográfica del proyecto, el sector/familia del proyecto, otros parámetros de rastreo del proyecto, etc. Las propiedades 280d del perfil del producto incluyen cualquier tipo de datos relacionados con un producto (por ejemplo, los recursos humanos o los recursos materiales), tales como el sector/familia del proyecto asociado con el producto, la caracterización de recursos, los tipos de actividades, la ubicación geográfica, etc. Los pasos ejemplificantes para recuperar los datos transaccionales filtrados de la base de datos se muestran en la FIG. 69. Después que los datos transaccionales se almacenan en la base de datos (paso 5100), se puede recibir (paso 5110) una solicitud subsecuente por los datos analíticos como una función de los datos transaccionales. Con base en el tipo de la solicitud (por ejemplo, el tipo de datos analíticos solicitados) , el sistema accede a la base de datos para recuperar los tipos de datos transaccionales necesarios para responder a la solicitud (paso 5120). Si la solicitud incluye uno o más filtros (paso 5130), el sistema filtra los datos transaccionales recuperados (paso 5140) antes de generar los datos analíticos solicitados (paso 5150) . Los filtros sirven a la función de limitar la cantidad de datos transaccionales que se usas en el proceso analítico. Por ejemplo, si la solicitud es por un reporte financiero que resuma los gastos mensuales sobre los proyectos para el cliente o comprador, el cliente o comprador puede filtrar el reporte para incluir sólo los gastos mensuales sobre los proyectos para un proveedor o vendedor particular o los proyectos de un tipo de proyectos particular. Las capturas de imagen de pantalla de las páginas de red que representan vistas de reporte que contienen los datos analíticos se muestran en las FIGs. 70-88. La FIG. 70 es una representación ejemplificante de una página 61 de red del Menú Principal de Generación de Reportes. Se debe entender que se pueden proporcionar Menús Principales de Generación de Reportes para los usuarios proveedores o vendedores, los usuarios administrativos y los usuarios contratistas. El Menú Principal de Generación de Reportes se diseña para permitir que los usuarios gestiones los proyectos desde varias perspectivas. Por lo tanto desde el Menú Principal de Generación de Reportes, un usuario puede seleccionar un tipo 350 del reporte, a partir del cual el usuario puede seleccionar una vista 360 de reporte particular. Por ejemplo, la FIG. 70 ilustra tres tipos 350 de reportes, financiero, de proyecto y de capital del proveedor o vendedor/humano. Dentro de cada uno de estos tipos de reportes se encuentran numerosas vistas 360 de reporte. Los ejemplos de las vistas 360 de reportes dentro del tipo 350 de reporte financiero son las vistas de reporte de detalles de facturación, las vistas de reporte resumido de productos, las vistas de reporte de modelado/presupuestos de gastos futuros y las vistas financieras de proyectos completados. Los ejemplos de las vistas 380 de reportes dentro del tipo 350 de reporte de proyecto son las vistas de reporte de realización del proyecto, las vistas de reporte de faseamiento previsto del plan y de actividad de entregables y las vistas de reporte de planificación administrativa del proyecto. Los ejemplos de las vistas 360 de reporte dentro del tipo 350 de reportes de capital del proveedor o vendedor/humano son las vistas de reporte financiero, las vistas de reporte operacional, y las vistas de reportes de cadenas de suministro. Sin embargo, se debe entender que la presente invención no se limita a los tipos 350 de reportes específicos y las vistas 360 de reportes mostradas en la FIG. 70, y que los tipos 350 de reportes y las vistas 350 de reporte se incluyen en la FIG. 70 solamente por simplicidad y propósitos ejemplificantes. El número de tipos 350 diferentes de reportes y vistas 360 de reportes se limita solamente por el tipo y la cantidad de los datos transaccionales mantenidos en el sistema y los requerimientos del usuario. Los ejemplos de tipos específicos de vistas 350 de reportes se muestran en las FIGs. 71-88. Por ejemplo, la FIG. 71 es una captura de imagen de pantalla ejemplificante de una página 61 de red que presenta una vista 360 de reporte de los detalles de facturación. Incluidos en la vista 360 de reporte se encuentran los datos 270 analíticos relacionados con las facturas (o comprobantes) particulares. Los datos 270 analíticos de facturación se pueden clasificar por diversas variables, filtrados usando varios filtros y resumidos en un número de diferentes vistas 360 de reporte. Por ejemplo, de la vista de reporte de detalles de facturación, los datos transaccionales usados para generar los datos analíticos en la vista de reporte de detalles de facturación se pueden resumir por el tipo de proyecto y se despliegan en una vista de reporte resumido de facturación de tipos de proyectos como los datos analíticos de facturación del tipo de proyectos. Los filtros 280 y las vistas 360 de reporte adicionales posibles para la vista 360 de reporte de detalles de facturación no se limitan a aquellas ilustradas en la FIG. 71, y se pueden extender para incluir cualquier tipo de campo especificado por el cliente (CSF) . La FIG. 72 es una captura de imagen de pantalla ejemplificante de una página 61 de red que presenta la vista 260 de reporte resumido de gastos mensuales que contiene los datos 270 analíticos que listan los gastos totales del proyecto para el mes actual y los meses precedentes. Varias vistas 360 de reporte resumido adicionales se pueden vincular para formar la vista 360 de reporte resumido mensual general. Por ejemplo, los datos transaccionales que forman los datos 270 analíticos se pueden resumir por geografía, y se despliegan como la vista de reporte resumido de gastos geográficos para ayudar al usuario a determinar la cantidad de gastos sobre los proyectos en las diferentes áreas geográficas. Como otro ejemplo, como se muestra en la FIG. 73, los datos transaccionales que forman los datos 270 analíticos se pueden resumir por tipo de proyecto y se despliegan en una página 61 de red como una vista 360 de reporte resumido de gastos por tipo de entregas del proyecto que contiene los datos 270 analíticos que listan los gastos mensuales sobre los diferentes tipos de entregas del proyectos. Por ejemplo, los gastos pueden ser resumidos por entregables de precios fijos, entregables basados en unidades, entregables de tiempo y materiales, tiempos y gastos, solamente tiempo, contratos de servicios y otros tipos de entregas del proyecto. Además, los 270 estadísticos relacionados con los datos transaccionales de gastos en cada tipo de entrega del proyecto se pueden generar para ayudar al usuario a identificar el porcentaje de los gastos totales hechos sobre cada tipo de entrega del proyecto para cada mes. Sin embargo, se debe entender que se pueden generar varios otros datos analíticos/estadísticos y desplegarlos en varias otras vistas de reporte usando los mismos datos transaccionales de gastos. Como se pueden observar en el fondo de la página de red mostrada en la FIG. 73, se puede proporcionar un enlace para examinar los datos externos (por ejemplo de la base de datos de nivel superior) relacionados con los datos transaccionales de gastos. Por lo tanto, no se requiere que el usuario inicie sesión en un servidor diferente para acceder a los datos transaccionales de nivel superior. Aunque se debe entender que en otras modalidades, se puede requerir un procedimiento separado de inicio de sesión. Si el usuario hace click sobre el vinculo para los datos externos, se puede presentar al usuario una vista 360 de reporte resumido del tipo mostrado en la FIG. 74. La FIG. 74 es una captura de imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos de la industria presentados en una vista 360 de reporte resumido de gastos por tipo de entrega del proyecto. En la FIG. 74 se muestran dos diferentes ejemplos de datos 270 analíticos de la industria, aunque sólo uno de los cuales puede ser desplegado a la vez, dependiendo de la solicitud y los filtros ingresados por el usuario. En la parte superior de la página 61 de red se muestran los datos 270 analíticos estadísticos que identifican el porcentaje de gastos totales hechos en cada tipo de entrega del proyecto para cada mes en el segmento de la industria automotriz. A la mita de la página 61 de red se muestra el porcentaje de gastos totales hechos por los clientes o compradores extra grandes sobre cada tipo de entrega del proyecto para cada mes. Como se puede observar en la página 61 de red mostrada en la FIG. 74, se puede proporcionar un enlace a una vista de reporte diferente que compara los datos analíticos de la industria con los datos analíticos de la compañía individual del usuario. Si el usuario hace click sobre el enlace a los datos externos se pueden presentar al usuario una vista 360 de reporte resumida del tipo mostrado en la FIG. 75. La FIG. 75 ilustra una captura de imagen de pantalla de una página 61 de red ejemplificante que contiene una comparación de los datos 270 analíticos de la industria y los datos 270 analíticos individuales del cliente o comprados en un reporte 369 resumido de gastos por tipo de entregas del proyecto. Dos diferentes ejemplos de datos analíticos 270 de comparación se muestran en la FIG. 75, aunque sólo uno de los cuales se puede desplegar a la vez, dependiendo de la solicitud y los filtros ingresados por el usuario. En la parte superior de la página 61 de red, los datos 270 analíticos que identifican los gastos del cliente o comprador individual sobra cada tipo de entregas del proyecto en una base mensual se comparan con los gastos promedio de la industria sobre cada tipo de entrega del proyecto en una base mensual. En la parte inferior de la página 61 de red, los datos 270 analíticos que identifican el porcentaje de gastos totales hechos sobre cada tipo de entrega del proyecto para cada mes por el cliente o comprador se comparan con el porcentaje de gastos totales hechos sobre cada tipo de entrega del proyecto para cada mes por el industria. La FIG. 76 es una captura de imagen de pantalla de una página 61 de red que contiene los datos 270 analíticos relacionados con un proyecto particular que se presenta en una vista 360 de reporte resumido de costos del proyecto. Los datos 270 analíticos pueden incluir el estado del proyecto, los costos totales del proyecto a la fecha, la cantidad de la requisición (es decir, la cantidad autorizada para el proyecto) , el gasto porcentual sobre este proyecto en comparación con todos los proyectos manejados actualmente por el cliente o comprador, los márgenes del proyecto y otros datos analíticos de costos relevantes para el proyecto. En la parte inferior de la página 61 de red se encuentran enlaces a las diferentes vistas 360 de reportes de costos del proyecto resumidos por los diferentes tipos de datos transaccionales, tales como el tipo de impacto del negocio, la geografía, los proveedores o vendedores, etc. La FIG. 77 es una captura de imagen de pantalla de una página 61 de red que contiene los datos 270 analíticos relacionados con los gastos futuros estimados para uno o más proyectos que se presentan en una vista de reporte de estimación de costos del proyecto. Dos diferentes ejemplos de datos 270 analíticos de gastos futuros se muestran en la FIG. 77, aunque sólo una de las cuales puede ser desplegada a la vez, dependiendo de la solicitud y los filtros ingresados por el usuario. En la parte superior de la página 61 de red se muestran los datos 270 analíticos relacionados con los gastos futuros estimados sobre un proyecto particular, en tanto que en la parte media de la página de red, se muestra un estimado de los gastos futuros. En la parte inferior de la página 61 de red se encuentran vínculos para diferentes vistas 360 de reporte de estimación de gastos del proyecto resumidos por los diferentes tipos de datos transaccionales, tales como el tipo de impacto del negocio, la geografía, los proveedores o vendedores, etc.

Como un ejemplo, si un usuario hace clic sobre el vinculo para resumir los gastos futuros estimados del proyecto por sector y familia de proyectos, una vista 360 de reporte similar al mostrado en la FIG. 78 puede ser presentada al usuario en una página 61 de red ejemplificante. La vista 360 de reporte mostrada en la FIG. 78 es un modelo de gastos futuros estimados del proyecto agregados por la vista 360 de reporte por sector/familia del proyecto que contiene los datos 270 analíticos relacionados con los gastos futuros estimados sobre los proyectos en diferentes sectores/familias de proyectos. Este tipo de vista 360 de reporte puede ser útil para que los usuarios se aseguren de que las inversiones organizacionales se están haciendo de acuerdo con los planes de negocios. Tres diferentes ejemplos de gastos futuros estimados por sector/familia del proyecto se muestran en la FIG. 78, aunque sólo una de las cuales puede ser desplegado a la vez, dependiendo de la solicitud y los filtros ingresados por el usuario. En la parte superior de la página 61 de red, los datos 270 analíticos contienen los gastos futuros estimados por mes que se agregan por sector/familia de proyectos. En la parte media de la página de red, los datos 270 analíticos contienen los datos estadísticos relacionados con los gastos futuros estimados para una familia particular de proyectos, tales como el porcentaje estimado de los gastos totales que se harán sobre la familia particular de proyectos por mes. En la parte inferior de la página de red, los datos 270 analíticos contienen los datos estadísticos relacionados con los gastos futuros estimados para un sector particular de proyectos, tal como el porcentaje estimado de los gastos totales que se harán sobre el sector de proyectos particular por mes. Como se puede observar en la parte inferior de la página 61 de red, se puede proporcionar un enlace a los datos externos para examinar los reportes que contienen datos analíticos externos sobre los gatos futuros proyectados. Tales datos externos pueden ser útiles para proporcionar una perspectiva de cómo los miembros del mercado especifico están invirtiendo o planificando satisfacer sus objetivos de negocios. La FIG. 79 es una captura de imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos relacionados con los datos de realización del proyecto para un proyecto particular que se presenta en una vista 360 de reporte resumida de realización del proyecto. Los datos 270 analíticos pueden incluir el estado del proyecto, la cuenta de complexión de fase del proyecto, la cuanta de las fases atrasadas, la cuenta de terminación de entregables, la cuenta de terminación de entregables atrasados, el porcentaje de terminaciones a tiempo de los entregables, y otros datos analíticos de realización del proyecto, en la parte inferior de la página 61 de red se encuentran vínculos a las diferentes vistas 360 de reporte de realización del proyecto resumidas por los diferentes tipos de datos transaccionales, tales como el tipo de impacto del negocios, la geografía, los proveedores o vendedores, etc. Por lo tanto, a partir de esta página 61 de red se pueden generar los agregados y otros datos analíticos resumidos por tipo de datos transaccionales. Como un ejemplo, si un usuario hace clic sobre el vinculo para resumir los datos analíticos de realización del proyecto por el tipo de propiedad administrativa, se puede presentar al usuario una vista 360 de reporte similar la mostrada en la FIG. 80, en una página 61 de red ejemplificante. La vista 360 de reporte mostrada en la FIG. 80 es un resumen de la realización operacional para los proyectos manejados por los diferentes tipos de propiedad administrativa, tales como poseído por el cliente o comprador, poseído por el proveedor o vendedor, propiedad conjunta, etc., que contiene los datos 270 analíticos relacionados con la realización de los proyectos que tienen diferentes propiedades. Este tipo de vista 360 de reporte puede ser útil para que los usuarios entiendan la relación entre las tasas de éxitos/fracasos como una función de la propiedad administrativa de los proyectos. Como se puede observar en la parte inferior de la página 61 de red, se puede proporcionar un vinculo a los datos externos para examinar los reportes que contienen datos analíticos externos sobre la realización de los proyectos en relación con la propiedad administrativa de los proyectos. Como otro ejemplo, si un usuario hace clic sobre el vinculo de la parte inferior de la página 61 de red en la FIG. 79 para examinar un reporte de riesgos/fracasos, se puede presentar al usuario una vista 360 de reporte en una página 61 de red ejemplificante. La vista 360 de reporte mostrada en la FIG. 81 es un reporte de excepción de realización, por riesgos/fracasos del proyecto que contiene los datos 270 analíticos relacionados con la realización de proyectos en riesgo o sin acatamiento que tienen fechas atrasadas u otros problemas. La FIG. 82 es una captura de imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos relacionados con la planificación de los proyectos, los cuales se presentan en una vista 360 de reporte de matriz de planificación. Los datos 270 analíticos pueden incluir, por ejemplo, la cuenta total del proyecto para el mes actual y los meses futuros, y otros datos 270 analíticos de planificación del proyecto, la FIG. 83 es una captura de imagen de pantalla de una página 61 de red ejemplificante que contiene los datos analíticos relacionados con una planificación de proyectos más especifica que la presentada en la vista 360 de reporte de herramienta de planificación de proyectos. Por ejemplo, un usuario puede seleccionar un sector/familia particular de proyectos y elige varias variables de impacto (por ejemplo, los filtros 280), tales como la geografía, el nivel del proveedor o vendedor, etc., y varias vistas 360 de realización del proyecto para presentar una vista 360 de reporte que contiene los datos 270 analíticos resumidos agregados, asociados con cada combinación de las variables de impacto listadas asociadas con los datos históricos específicos de realización del proyecto. Este tipo de vista 360 de reporte puede ser útil a un usuario para proporcionarle una perspectiva significativa sobre cuales configuraciones (agregados variables) de negocios han sido exitosas y cuales no . La FIG. 84 es una captura de la imagen de pantalla de una página 61 de red que contiene los datos 270 analíticos relacionados con las tendencias de gastos como una funciones del nivel de los proveedores o vendedores que se presentan en una vista 360 de reporte de gastos por código de nivel del proveedor o vendedor. Dos ejemplos de datos de gastos por nivel del proveedor o vendedor se muestran en la FIG. 84, aunque sólo una de ellos puede ser desplegado a la vez, dependiendo de la solicitud y los filtros ingresados por el usuario. En la parte superior de la página 61 de red, los datos 270 analíticos incluyen las cantidades gastadas por uno o más proveedores o vendedores dentro de un nivel de proveedores o vendedores específicos en una base mensual. En la parte inferior de la página 61 de red, los datos 270 analíticos incluyen el número de proveedores o vendedores en el nivel de proveedores o vendedores, la cantidad total gastada con los proveedores o vendedores en el nivel de proveedores o vendedores en una base mensual y otros datos 270 analíticos agregados o estadísticos de gasto por nivel del proveedor o vendedor. La FIG. 85 es una captura de la imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos relacionados con la información de calificación del proveedor o vendedor que se presenta en una vista 360 de reporte de calificación del proveedor o vendedor. Los datos analíticos pueden incluir, por ejemplo, un listado de la información de los criterios del proveedor o vendedor definidos por el cliente o comprador, asociados con la información de calificación del proveedor o vendedor para cada proveedor o vendedor y una indicación de si el proveedor o vendedor satisface o no los calificadores el proveedor o vendedor definidos por el cliente o comprador. En la parte inferior de la página 61 de red, hay enlaces adicionales a diferentes vistas 360 de reporte resumidas para agregar y/o llevar a cabo análisis estadísticos sobre varios datos de calificación del proveedor o vendedor. La FIG. 86 es una captura de la imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos relacionados con el despliegue de los recursos humanos como una función de la geografía, que se presentan en una vista 360 de reporte de despliegue geográfico de recursos. Los datos 270 analíticos pueden incluir la información estadística, tal como el porcentaje de recursos desplegados en un pais, región, o ciudad especifica, el porcentaje de tiempo trabajado en un pais, región o ciudad especifica y el porcentaje de dinero gastado en los recursos humanos en un pais, región o ciudad especifica. Los datos 270 analíticos pueden incluir además varia información agregada, tal como la cuenta total de los recursos, el tiempo y el dinero gastado en un pais, región o ciudad especifica. Este tipo de vista 360 de reporte de recursos humanos puede ser útil para un usuario cuando trata con cuestiones tales como la gestión de capacidades, cálculo de precios, co-empleo, re-despliegue, etc. La FIG. 87 es una captura de la imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos relacionados con los recursos humanos que se presentan en una vista 360 de reporte de recursos de capital humano desplegados por el proveedor o vendedor. Tres ejemplos diferentes de los datos de recursos humanos se muestran en la FIG. 84, aunque sólo uno de ellos puede ser desplegado a la vez, dependiendo de la solicitud y los filtros ingresados por el usuario. En la parte superior de la página 61 de red, los datos 270 analíticos incluyen la información individual de los contratistas como una función de la realización del proyecto. en la parte media de la página 61 de red, los datos 270 analíticos incluyen información agregada o estadística de los contratistas relacionados con un proveedor o vendedor particular. En la parte inferior de la página 61 de red, los datos 270 analíticos incluyen información agregada o estadística de los contratistas relacionados con varios proveedores o vendedores. En la parte inferior de la página 61 de red hay enlaces adicionales a las diferentes vistas 360 de reporte resumidas para agregar y/o llevar a cabo análisis estadísticos sobre varios datos de los contratistas. La FIG. 88 es una captura de la imagen de pantalla de una página 61 de red ejemplificante que contiene los datos 270 analíticos relacionados con el desempeño del proveedor o vendedor que se presentan en una vista 360 de reporte de la puntuación del proveedor o vendedor. Esta vista 360 de reporte incluye los varios filtros 280 que pueden ser utilizados para centrar la vista 360 en los tipos específicos de datos transaccionales. Se debe entender que aunque no se muestra en cada vista 360 de reporte discutidas arriba, varios filtros estarían disponibles para algunas o todas las vistas 360 de reporte. Los datos 270 analíticos pueden incluir información agregada o estadística relacionada con la licitación, la realización del proyecto y la actividad de gasto de los varios proveedores o vendedores. En la parte inferior de la página 61 de red hay vínculos adicionales a diferentes vistas 360 de reporte resumidas para agregar y/o llevar a cabo análisis estadísticos sobre los varios datos de desempeño de los proveedores o vendedores. Las vistas 360 de reporte descritas arriba y los tipos de datos 270 analíticos presentados en las mismas están hechos para proporcionar sólo un ejemplo de la robustez del módulo de generación de reportes. Debe ser fácilmente aparente para una persona experimentada en la técnica que el número y las variaciones de las vistas de reporte que son posibles con la presente invención. En varias de las FIGURAS a continuación, las ramificaciones negativas que se extienden de los bloques de decisiones han sido omitidas con fin de evitar la complicación innecesaria de la descripción de las varias caracteristicas y modalidades de la invención. Aquellas personas que tengan experiencia en la técnica apreciaran que las ramificaciones negativas pueden ser suministradas cuando se estipule por las restricciones de diseño sin apartarse de los principios de la invención. La FIG. 89 ilustra una dinámica 8900 visual del ambiente de trabajo del proyecto ejemplificante que puede ser implementada en el sistema 30. Una capa más interna de la dinámica 8900 muestra los elementos de las actividades tangibles básicas de los datos transaccionales asociados con un proyecto y representados, por ejemplo, por la entrega de las mercancías, la entrega de unidades de servicio, los entregables de precio fijo, las asignaciones de recursos humanos, (incluyendo el trabajo y los costos), los gastos misceláneos del proyecto, y el faseamiento del proyecto. Los elementos 8905-8930 representan el trabajo del proyecto que se llevan a cabo actualmente. Las actividades representadas por los elementos 8905-8930 no representan necesariamente las actividades individuales o incluso facturables, pero casi siempre . Los elementos 8905-8930 facilitan la visibilidad granular y la gestión administrativa de las actividades tangibles de trabajo del proyecto. Los datos transaccionales toman la forma de objetos de datos especiales como se ilustra, por ejemplo, en las FIGs. 40A y 41. Los objetos de datos especiales son receptáculos complejos de datos que pueden alojar, por ejemplo, varios tipos de datos variables, códigos, bases de datos, consultas, y conjuntos de datos relaciónales jerárquicos. En contraste, los objetos de datos simples son, por ejemplo, campos de texto sencillo, campos de costos, u objetos de campos de datos. Estos objetos de datos especiales se usan principalmente para adquirir, almacenar y procesad los datos transaccionales. También mostrado en la Capa 1 se encuentran los componentes de la declaración de trabajo (SOW) representados como los elementos (8935 (a) - (d) . Con las modalidades típicas, entregable y SOW se refieren a una descripción tangible de los objetivos producidos por el proyecto y son sinónimos. Sin embargo en algunas modalidades, este puede no ser el caso, tal como, por ejemplo, cuando un sub-contratista no produce entregables de la orden de compra. Aquellas personas que tengan experiencia en la técnica apreciarán que no hay necesidad de exactamente cuatro componentes, sino que el número puede ser determinado por las restricciones del diseño de la configuración de etapas importantes del proyecto. Los componentes, 8935 (a) -(d) de la SOW representan una descripción tangible de los resultados objetivos del proyecto 8por ejemplo, una etapa importante o SOW/entregable del proyecto) . Los resultados del proyecto pueden ser representados como resultados de la SOW y típicamente no se estipulan los detalles pertinentes a, por ejemplo, los recursos de trabajo o la logística. Por lo tanto una SOW podria asignarse a uno o más elementos tangibles de trabajo del proyecto. Las actividades de trabajo el proyecto son típicamente sub-componentes de una SOW, donde los sub-componentes podrian variar en número desde unos cuantos a tantos como un número extremadamente grande. El componente 8940 de la Capa 1 ilustra las dependencias de Administración de Proyectos tradicional (PM) de la SOW. Los resultados de 1 SOW se organizan en relaciones. Los sub-componentes (es decir, las actividades dee trabajo del proyecto) se integran de manera tal que se establece un ambiente de trabajo cohesivo. La Capa 2 ilustra un aspecto de comercio transaccional de la dinámica 8900 representada como los componentes 8945-8960, también denominada como un ciclo de origen hasta el pago. Un sistema 8945 de plantillas/rubros de la licitación RFx sirve como una estructura de soporte para la Capa 1. Como se describe arriba, los rubros conducen a las plantillas, las plantillas se utilizan para crear plantillas de RFx, y las plantillas de RFx se transmiten/envian a los proveedores. Los Proveedores procesan entonces las respuestas de la licitación de RFx. Los clientes o compradores analizan las respuestas a la licitación de RFx y emiten las adjudicaciones asociadas con los elementos específicos de la respuesta de la licitación RFx. Estos elementos de la respuesta de la licitación de RFx se integran sistemáticamente en un ambiente de requisiciones/ordenes de compra. Cuando se completa el trabajo, estos registros de ordenes de compra (PO) específicos se acceden por el proveedor para crear los comprobantes de aceptación de las actividades del proyecto, en cuyo momento el cliente o comprador puede examinar y evaluar la calidad del trabajo, lo que resulta por último en la probación del cliente o comprador. Finalmente, los datos de los comprobantes aprobados pueden ser extraídos y usados para generar datos de facturación que resultan en el pago a los proveedores. Los objetos de datos transaccionales especiales (por ejemplo, los objetos de datos de la licitación RFx como en la Tabla 26) también pueden ser usados fuera de un proceso de licitación. Por ejemplo en algunas instancias, un cliente o comprador puede no tener tiempo o deseos de iniciar un proceso de licitación competitivo. En tales casos, el cliente o comprador puede iniciar, por ejemplo, en la rama 560 de requisición de compra del proceso 500. La Capa 3 ilustra el resto de la dinámica 8900 que se afecta directamente por los aspectos de comercio transaccional del trabajo del proyecto. Aunque un grupo de gestión de carteras como se ilustra incluya el presupuesto/flujo de efectivo 8965, los contratos 8970, los activos 8975, y los eventos 8980 de negocios internos, podrian haber fácilmente muchos otros, tales como, por ejemplo, una elemento de funciones de recursos humanos de fabricación internos. La cartera de la Capa 3 podria variar en gran medida dependiendo, por ejemplo, en que industria existe una entidad de negocios o donde se llevan a cabo sus negocios. Para propósitos ejemplificantes, se han seleccionado aquellas carteras que típicamente impactarian cualquier trabajo del proyecto llevado a cabo por la entidad cliente o comprador. Comúnmente, hay muchos eventos de negocios que son impactados por un proyecto pero que no pertenecen actualmente al ámbito del proyecto, por ejemplo, un proyecto especifico podria implicar la instalación de equipo de computo y paquetes informáticos en una ubicación de negocios particular. Directamente impactado por esta actividad, aunque no parte del trabajo del proyecto per se, puede ser un departamento de servicio técnico de la entidad de negocios. Por lo tanto, un evento de negocios distinto llamado entrenamiento del personal de servido técnico es un evento de negocios relacionado. La Capa 3 representa un aspecto tras bambalinas del trabajo del proyecto dentro de una entidad de negocios. El ambiente siguiente y más externo de la dinámica visual es la Capa 4, la cual incluye los componentes 8985-8999. los usuarios 8985, las comunicaciones 8990, la colaboración 8995, y el respaldo a la toma de decisiones 8999 representan las personas o el aspecto intangible de la dinámica 8900. El trabajo del proyecto frecuentemente es una tarea compleja. Las actividades del trabajo del proyecto deben ser integradas con un ambiente de comercio (por ejemplo, el sistema de procesamiento de datos de origen hasta el pago) como se ilustra por ejemplo en la FIG. 8, el cual ambiente frecuentemente impacta directamente a su vez a las tareas administrativas de negocios de alto nivel tales como, por ejemplo, la generación de presupuestos, el flujo de efectivo, la gestión de contratos, la gestión de activos/capital, y una multitud de otras actividades/eventos de negocios relacionados. Rodeando todas estas variables esta la necesidad de conectar a los usuarios y las comunicaciones en un ambiente colaborativo seguro y administrado, de manera tal que los datos puedan ser procesados en una manera organizada, se produzcan los resultados deseados, y se proporcione un respaldo firme a la toma de decisiones para incentivar adicionalmente las tareas de negocios globales. Por lo tanto, la dinámica 8900 puede ser en extremo compleja en las implementaciones típicas. La FIG. 89 despliega la red intrincada que existe entre los elementos dinámicos ilustrados. Por ejemplo, si fallara la entrega de mercancías, una SOW especifica puede ser retardada o cancelada. Esta falla puede resultar en la necesidad de modificar una orden de compra, lo cual puede cambiar las posiciones de los presupuestos y el flujo de efectivo. Existe la posibilidad de que se cambie un depósito de activos fijos, lo cual probablemente impactaria los contratos de servicios o de mantenimiento, lo cual puede resultar en la necesidad de modificar las configuraciones de la planta fisica y resultarla por último en la necesidad de volver a enfocar una docena de otros proyectos relacionados que se vean impactados. La FIG. 90 es un diagrama de bloques que ilustra una vista de alto nivel de un ambiente de procesamiento de datos de negocios que puede ser usado para implementar la dinámica 8900. Un ambiente 9000 de procesamiento de datos incluye cuatro componentes de alto nivel segmentados como un componente 9001 de datos de información principal, un componente 9025 de entidades de flujo de trabajo, un componente 9050 de procesamiento de datos, y un componente 150 de base de datos. El componente 150 de base de datos es donde se almacenan y se recuperan los datos procesados. El componente 9001 de datos de información principal tiene estructuras y atributos que residen físicamente en el componente 150 de base de datos, sin embargo, estos se despliegan por separado con el fin de mostrar las diferencias entre los datos de administración y los datos transaccionales.

Desde una perspectiva de alto nivel, el ambiente 9000 de procesamiento de datos de negocios puede ser explicado como incluyendo los usuarios, información, formas/depósitos de procesamiento, trayectorias de flujo de trabajo y componentes de almacenamiento de datos. El componente 9001 de datos de información principal, representa la información que no sólo define la infraestructura de la empresa (por ejemplo, la industria, los productos o servicios ofrecidos, etc.), sino también los limites de las tareas de la empresa dentro del ámbito de una solución administrativa de comercio (es decir, cómo la empresa puede interactuar con la solución en el contexto del trabajo del proyecto) tal como, por ejemplo, como se ilustra en la FIG. 5. Esta información se considera por lo tanto los datos de administración (es decir, los datos que no se limitan a un proyecto particular, sino más bien descriptivos de la empresa y sus procesos, independientemente de un proyecto particular) en oposición a los datos transaccionales. El componente 9001 de datos de información principal también define los limites del ambiente 9000. El componente 9001 de datos de información principal incluye los siguientes ocho sistemas ejemplificantes: 1) Un sistema 9003 de funciones de usuario, el cual es un módulo de aplicación por medio del cual se almacenan y se gestionan las identidades y los atributos del personal/usuarios. Los aspectos de configuración de este módulo facilitan la interactividad del usuario con el ambiente 9000 desde la autorización de registro básica a las acciones de procesamiento de datos del flujo de trabajo. 2) Un sistema 9005 de geo-instalaciones, el cual es un módulo de aplicación que define el ámbito geográfico y la construcción de una entidad de cliente o comprador y cómo se relacionan las plantas físicas con esa construcción. Las configuraciones definen un ámbito geográfico para ser ya sea domestico o internacional, por ejemplo, o si una entidad cliente o comprador utiliza un esquema de segmentación regional habitual que utiliza correo/códigos postales para el procesamiento de negocios. Además, de la construcción geográfica básica, los sitios de las plantas podrian ser integrados en el sistema 9005 de geo-instalaciones, con los atributos aplicables a las plantas físicas definidos. La información de los atributos que se refiere, por ejemplo, a las actividades de la planta, las regulaciones de seguridad, las restricciones ocupacionales, el acceso de las entregas, también se podrian mantener en el sistema 9005 de geo-instalaciones . 3) Un sistema 9007 de aseguramiento de la calidad, el cual es un módulo de aplicación por medio del cual se pueden definir el proceso y las funciones de negocios como críticos para la entidad cliente o comprador. Adicionalmente, se pueden definir los atributos de las medidas correspondientes para el proceso y las funciones de negocios. 4) Un sistema 9009 de capital humano, el cual es un módulo de aplicación que define las vistas de la entidad cliente o comprador y que administra los datos pertinentes a los trabajadores no empleados. Dentro de este módulo, una entidad cliente o comprador puede definir y configurar los atributos para uno o más de los siguientes: los tipos de trabajadores, los calificadores de los trabajadores, los acuerdos laborales, los cargos de los trabajadores, los requerimientos del contrato de los trabajadores, los requerimientos fuera de contrato de los trabajadores, los tipos de tareas de los trabajadores, los tipos de gastos de los trabajadores, las reglas de ubicación de los trabajadores, las reglas de revisión de los trabajadores, y la suspensión de los trabajadores. 5) Un sistema 9011 de administración financiera, el cual es un módulo de aplicación financiera por medio del cual una entidad cliente o comprador puede gestionar varias facetas de la administración de gastos y las tareas de procesamiento de datos financieros. Los componentes de información típicos pueden incluir, pero no se limitan necesariamente a: la designación y la definición de atributos de los tipos de gastos monetarios, la designación y la definición de atributos de los tipos de moneda corriente, la designación y definición de atributos de los términos de pago, la designación y la definición de atributos de términos de descuentos, la designación y la definición de atributos de los términos de las rebajas, la designación y la definición de atributos del cálculo de aumentos, la designación y la definición de atributos de las clases de impuestos, la designación y la definición de atributos de las excepciones de impuestos, y la designaron y la definición de atributos del esquema de aprobación de transacciones financieras. 6) Un sistema 9013 de administración de adquisiciones, el cual es un módulo de aplicación de adquisiciones por medio del cual una entidad cliente o comprador puede gestionar las varias facetas de las tareas de procesamiento de datos transaccionales de procuración y comercio. Dentro de este módulo reside la información y las configuraciones para uno o más de los siguientes: el sistema mercantil, el sistema de licitación RFx, el sistema de requisiciones/ordenes de compra y el sistema de comprobantes (es decir, de procesamiento de aceptación del trabajo) como en, por ejemplo, la FIG. 40C. 7) Un sistema 9015 de administración de proveedores, el cual es un módulo de aplicación de proveedores por medio del cual una entidad cliente o comprador puede gestionar las varias facetas de la administración de proveedores relativas con el ambiente de comercio. Varios aspectos de negocios de la administración de proveedores, desde la protección de responsabilidades especificas hasta la administración estratégica de los gastos de los proveedores, se pueden llevar a cabo dentro de los elementos de configuración del sistema 9015 de administración de proveedores si se encuentra disponible la información de negocios necesaria para hacerlo. Los elementos de configuración típicos pueden incluir, pero no se limitan necesariamente a: la designación y la definición de atributos de los tipos de proveedores, la designación y la definición de atributos de los calificadores de negocios de los proveedores, la designación y la definición de atributos de los calificadores de aseguramiento de los proveedores, la designación y la definición de atributos del nivel de los proveedores, la designación y la definición de atributos de los acuerdos de los proveedores, la designación y la definición de atributos de las auditorias de negocios de los proveedores, la designación y la definición de atributos de las dispensas de calificación de negocios de los proveedores y por supuesto la especificación de la capacidad de aprovisionamiento de los proveedores con relación a las mercancías utilizadas por el cliente o comprador. 8) Un sistema 9017 de administración de proyectos es un módulo de aplicación por medio del cual una entidad cliente o comprador puede gestionar las facetas de la administración de proyectos . El componente 9025 de entidades de flujo de trabajo representa los receptáculos de información (por ejemplo, las formas o las páginas de red) que se utilizan para procesar la información transaccional dentro del ambiente 9000. Las entidades de flujo de trabajo son esencialmente una expresión del ambiente de datos disponible (por ejemplo, los componentes componente 9001 de datos de información principal de datos de información principal) que se usan para desplegar o adquirir información. El componente 9050 de procesamiento de datos representa un componente de flujo de trabajo primario del ambiente 9000, en tanto que los componentes componente 9001 de datos de información principal y 9025 definen realmente los datos y las formas de procesamiento de datos usadas en el ambiente 9000 de procesamiento de datos de negocios. El componente 9050 de procesamiento de datos es donde se configuran las formas de procesamiento de datos para moverse a lo largo de sus trayectorias de procesamiento de datos respectivas.

Como es el caso con los componentes 9001 de datos de información principal de datos de información principal y el componente 9025 de entidades de flujo de trabajo, el componente 9050 de procesamiento de datos incluye un conjunto base de trayectorias 9045 de flujo de trabajo pre-configuradas usadas para llenar las formas de flujo de trabajo que viajan a lo largo de las trayectorias de flujo de trabajo para las funciones de usuario predefinidas anteriores, por ejemplo, por los códigos de condición o de estado específicos. El procesamiento 9058 de flujo de trabajo configurado de manera variable representa los procesos de flujo de trabajo planificados por la entidad cliente o comprador, personalizados. El procesamiento 9058 de flujo de trabajo configurado usa, inter alia, las posiciones de función del usuario cliente o comprador del sistema 9003 de funciones de usuario, el componente 9025 de entidades de flujo de trabajo del cliente o comprador, y las reglas de negocios del cliente o comprador (por ejemplo, el valor de los datos y los atributos de condición) para configurar el procesamiento de datos de flujo de trabajo preciso para satisfacer las necesidades de negocios. El componente 150 de base de datos representa un aspecto de almacenamiento de la base de datos del ambiente 9000, en el cual se almacenan y se mantienen los datos transaccionales adquiridos durante la operación del componente 9050 de procesamiento de datos. El componente 150 de base de datos se muestra al final del flujo del ambiente 9000 para enfatizar la adquisición y el almacenamiento de datos. Sin embargo, el componente 150 de base de datos es operacional en todo momento a través de los cuatros componentes componente 9001, 9025, 9050, y 150 de datos de información principal. La FIG. 91 es una versión modificada de la FIG. 5 de arriba y proporciona una visión general de alto nivel de un proceso de cambio en el plan/alcance del proyecto de acuerdo con los principios de la invención. Como se indica en la FIG. 5 de arriba, el proceso 500 puede ser segmentado en la actividad 505 pre-licitación, la actividad 515 de licitación y las actividades 560 post-licitación . En la FIG. 5, la actividad 505 pre-licitación incluye el paso 510 en tanto que la actividad 515 de licitación incluye los pasos 520-555, y la actividad 560 de post-licitación incluye los pasos 565-580. En contraste, el proceso 9100 se segmenta en las actividades 505 pre-licitación, la actividad 9125 de procuración, y la actividad 9150 de post-procuración. En la FIG. 91, la actividad 505 de pre-licitación ocurre antes del paso 520, la actividad 9125 de procuraron ocurre antes del paso 560, y la actividad 9150 de post-procuración ocurre durante los pasos 560-580.

La actividad 505 de pre-licitación incluye la configuración 9110 de las funciones de usuario y de flujo de trabajo, la configuración 9115 del sistema de licitaciones RFx, y la configuración 9120 de la administración de proyectos. La actividad 9125 de procuración incluye la configuración 9127 de los datos transaccionales de trabajo del proyecto, lo cual incluye la asignación 9130 de la SOW a las actividades del proyecto, la configuración 9135 de la dependencia de la SOW, y la configuración 9140 de la SOW para la administración del proyecto. La actividad 9159 postprocuración incluye el procesamiento 9155 de comprobantes, el modelado 9160 de PCIP/S, la colaboración 9165 de PCIP/S, y las modificaciones 9170 del registro de PCIP/S. El procesamiento 9155 de comprobantes ocurre durante los pasos 560-570. el modelado 9160 de PCIP/S, la colaboración 9165 de la PCIP/S, y las modificaciones 9170 del registro de PCIP/S ocurren en o antes del paso 575. La FIG. 92 es una versión modificada de la FIG. 91 en la cual no se utiliza un proceso de licitación competitivo. Aquellas personas que tienen experiencia en la técnica apreciarán que las varias modalidades de la invención no se restringen a un ambiente que incluye una licitación competitiva, como se indica en la FIG. 92. La FIG. 92 incluye modificaciones para eliminar las actividades de procuración/licitación mostradas en la FIG. 91. en un proceso 9200 ilustrado en la FIG. 92, la actividad 9210 pre-proyecto incluye la configuración 9110 de las funciones de usuario y de flujo de trabajo y la configuración 9120 de la administración del proyecto. La actividad 9215 de configuración del proyecto incluye la configuración 9227 de lo datos transaccionales del trabajo del proyecto. La configuración 9227 de los datos transaccionales de trabajo del proyecto incluye la asignación 92130 de la SOW a las actividades del proyecto, la configuración 9135 de las dependencias de la SOW, y la configuración 9140 de la administración del proyecto. La actividad 9220 de rastreo del proyecto incluye el procesamiento 9155 de los comprobantes, el modelado 9160 de la PCIP/S, la colaboración 9165 de la PCIP/S, y las modificaciones 9170 del registro de PCIP/S. de manera similar a las FIGs. 5 y 91, la actividad 9210 pre-proyecto ocurre en el paso 9205, en tanto que la actividad 9215 de configuración del proyecto ocurre en el paso 550 y la actividad 9220 de rastreo del proyecto ocurre durante los pasos 560-565. La utilización de los objetos de datos especiales como los rubros de la licitación que migran a los datos de las requisiciones/ordenes de compra y después a los datos de los comprobantes transaccionales no se limitan a la secuencia como se describe en la FIG. 91. No existen restricciones técnicas en absoluto que prohiban el uso de los objetos de datos especiales en una manera que excluya el procesamiento de las órdenes de compra totalmente. En tal caso, se podria uswar simplemente el mismo tipo de registros para los datos de actividad del proyecto. Tales datos se podrian usar entonces en conjunción con las varias modalidades de la invención justo como si hubieran sido adquiridos como el resultado de la actividad de procuración dentro del sistema. Además, especificar las posiciones de las funciones de usuario y asignar al personal a las posiciones de funciones de usuario como en, por ejemplo, la FIG. 9, de manera similar no está de ningún modo restringido a un proceso de licitación y se puede aplicar en lugar de otros procesos de flujo de trabajo, tales como, por ejemplo, la calificación y carga de los proveedores o vendedores potenciales o la adquisición de los datos de acuerdos con el contratista. La FIG. 93 ilustra flujo del proceso de un cambio en el plan/alcance del proyecto (PCIP/S) de acuerdo con los principios de la invención. En la FIG. 93, un flujo 9300 de proceso inicia con un segmento de configuración de datos de pre-procuración que incluye la configuración 9305 de las funciones de usuario, la configuración 9310 del módulo de administración del proyecto, y una configuración 9315 del sistema de licitación RFx. Después de las actividades 0305- 0315 de configuración de datos de pre-procuración, el siguiente segmento principal del proceso 9300 incluye la adquisición y almacenamiento de los datos transaccionales de trabajo del proyecto mostrado en los paso 9320-9335. En el paso 9320 la entidad cliente o comprador crea y transmite una licitación RFx. En el paso 9325, un proveedor responde a la licitación RFx. En el paso 9330, el cliente o comprador evacúa las respuestas de la licitación RFx y selecciona a los ganadores. En el paso 9335, el cliente o comprador rea las requisiciones/ordenes de compra. Un tercer segmento principal del proceso, la configuración del registro de la SOW (pasos 9340-9250), es un segmento del proceso en el cual ocurre la configuración tradicional de la dependencia de la SOW del proyecto asi como el matrimonio de las configuraciones de datos establecidas en la configuración 9310 del módulo administrativo del proyecto y el segmento de configuración de los datos transaccionales con la adquisición y el almacenamiento de los datos transaccionales del proyecto.

Un cuarto segmento principal del proceso, denominado un componente de modelado de impacto del PCIP/S, se representa por los pasos 9353-0360. Los pasos 9353-9360 tienen lugar las el comienzo 9353 del trabajo del proyecto e incluye el envió de los comprobantes de aceptación del trabajo. A través de la configuración variable de los eventos importantes y la administración de los datos de eventos importantes de los comprobantes, las varias modalidades pueden identificar una entidad cliente o comprador cuyas actividades de proyecto especificas o los registros de la SOW estén fuera de cumplimiento de las etapas importantes y que por lo tanto se hayan vuelto (o pronto se volverán) una actividad de riesgo. La identificación 9365 en riesgo se facilita por un aspecto de la emisión de comprobantes del sistema. La ultima actividad dentro de este cuarto segmento del proceso es el reporte 9360 de impacto de la dependencia de PCIP/S, el cual utiliza la información configurada previamente para desplegar a un cliente o comprador un reporte de la entidad que detalla un conjunto de registros de negocios impactados potencialmente por la actividad en riesgo. Esta vista proporciona a una entidad cliente o comprador la información con respecto a lo que está en riesgo con base en una actividad en riesgo, durante el paso 9360, un usuario que controla la entidad cliente o comprador puede cambiar los valores de los datos variables de las etapas clave y hace que el sistema genere un reporte de resultados de impacto sobre los cambios de la información . Un quinto segmento del proceso, una sesión de comunicaciones de riesgos, se representa por los pasos 9363-9370. el usuario que controla la entidad cliente o comprador puede determinar si la actividad en riesgo tiene un pacto suficientemente amplio o significativo para garantizar la puesta sobre aviso de otros usuarios de la empresa sobre los problemas que existen que puedan resultar en cambios en el plan o el alcance de uno o varios proyectos. Por ejemplo, el usuario podria iniciar una sesión 9363 de comunicaciones de gestión de riesgos. Una vez que se crea la sesión 9363, con referencia al elemento especifico en riesgo del trabajo del proyecto, el usuario que controla la entidad cliente o comprador es capaz en el paso 9365 de seleccionar cuales usuarios de la empresa afectados potencialmente deben ser comunicados y configura o manipula los paquetes de comunicaciones individuales para que los usuarios para ajustar las necesidades de información especificas. Una vez que se configuran los paquetes de comunicaciones individuales, en el paso 9370, el usuario de la entidad cliente o comprador puede entonces transmitir los paquetes de comunicación a los individuaos que son los propietarios que controlan sus registros de negocios relacionados. De manera similar, a la respuesta 220 de licitación del proveedor, los usuarios de la entidad cliente o comprador que reciben los paquetes de comunicación en riesgo pueden, en el paso 9370, procesar sus respuestas por medio de una interfaz e usuario proveída. Los usuarios pueden proporcionar retroalimentación con respecto a los impactos anticipados a sus registros/eventos de negocios controlables. Tras la terminación de todos los paquetes de comunicaciones en riesgo de los receptores, este segmento del procesamiento termina. Con todos los paquetes de comunicaciones en riesgo completados a la mano, un usuario de la entidad cliente o comprador emisora puede ahora proceder a un sexto segmento principal del proceso, la sesión del paquete de aceptación del PCIP/S, el cual se representa por los pasos 9373-9385. dentro de este proceso, el usuario que controla la entidad cliente o comprador agrega y evalúa la información reunida durante la sesión de comunicaciones previa (es decir, los pasos 9363-9370) . El usuario controlante hace una disposición final relativa al destino de la(s) variable (s) de la actividad de trabajo del proyecto en riesgo y guarda el (los) cambio (s) del registro. Tras estos cambios, el usuario puede entonces generar, en el paso 9373, un nuevo reporte de impacto de las dependencia anterior por los nuevos datos variables, el cuales proporcionará una nueva visión de los registros de negocios relacionados y el cambio de los datos variables a los registros . Después que se calcula el nuevo modelo de impacto, el usuario de la entidad cliente o comprador puede proceder, en el paso 9375 a la transmisión del paquete de aceptación del PCIP/S a los usuarios proveedores según lo desee. La sesión del paquete de aceptación del PCIP/S se crea con referencia a una sesión de comunicaciones de administración de riesgos existente y abierta (es decir, los pasos 9363-9370), por lo tanto determinando ya la lista de proveedores objetivo de la transmisión que hace referencia a las ordenes de compra del sistema impactadas. El proceso de los pasos 9279-9835 es similar al proceso de comunicaciones previo (es decir, los paso 9363-9370), con lo cual las configuraciones individuales y se pueden hacer las notificaciones pertinentes a cada individuo receptor si asi se desea. La transmisión del paso 9375 se rastrea típicamente a nivel de la base de datos. Similar a la sesión de los pasos 93963-9370, los usuarios individuales que reciben el paquete de aceptación del PCIP/S, pueden procesar y regresar el paquete al usuario emisor en los pasos 9380 y 9385. Las respuestas se restringen típicamente a aceptar los datos variables modificador o que definen actualmente un elemento de datos variable. Los valores de la información que el sistema necesita reflejar a la luz de la disposición que se hace pertinente para la fuente del registro de la actividad de trabajo del proyecto en riesgo se adquieren y se almacenan. Las modificaciones de la información variable se hacen por las partes interesadas controlantes, con la fuente del problema identificada y la colaboración que se emprende a través de una plataforma única (por ejemplo, el sistema 30), en tanto que la actividad se rastrea completamente de manera visible para la empresa. Tras la recepción de los paquetes de aceptación de la PCIP/S completados, un séptimo segmento principal del proceso es el segmento de administración de la modificación del registro de PCIP/S (es decir, 9390-9395) . El usuario en control activa un control proporcionado a través, por ejemplo, de la interfaz de usuario y da la aprobación para que se actualicen las modificaciones de los datos variables. Tras la terminación del paso 9395, los usuarios de la entidad cliente o comprador afectados son notificados sistemáticamente de que se han hecho las modificaciones esperadas dentro del sistema. Configuración de los Datos Pre-procuración Varias actividades de configuración y de gestión de datos típicamente toman lugar antes que se adquieran los datos transaccionales de trabajo del proyecto actual. Estas actividades de configuración y gestión de datos pre-procuración proporcionan lineas de información tangibles a los cuales se conectaran los datos transaccionales de trabajo futuro del proyecto. Estas lineas de información típicamente incluyen los grupos/principal o master del proyecto, los grupos/principal de presupuestos, los grupos/principal de activos, el principal del contratista, y el evento/principal de negocios, aunque muchos otros son posibles. Las FIGs. 94A-101 ilustran con mayor detalle el paso 9310 de la FIG. 93, durante el cual paso una entidad cliente o comprador configura los componentes 9001 administrativos de los datos de información principal del proyecto. Las FIGs. 94A-B se refieren a los flujos de creación y almacenamiento tanto para los registros del grupo de proyectos y del principal de proyectos. Los grupos de proyectos son colecciones de uno o más proyectos que se agrupan de acuerdo con algún criterio predefinido tal como, por ejemplo, el área tecnológica, la unidad de negocios o la industria. Un principal del proyecto es un registro asociado con un proyecto particular. El principal del proyecto y los registros de los grupos de proyectos se encuentran típicamente dentro del sistema 9017 de administración del proyecto. Los flujos de proceso resultan en la adquisición y el almacenamiento de la información en las tablas de bases de datos, tales como por ejemplo, las Tablas 113-114. Un grupo de proyectos y un esquema del principal del proyecto, ilustrados en las FIGs. 94A-B representan una estructura de soporte básica para la información global y la administración de las carteras del proyecto. La administración de las carteras del proyecto se puede facilitar especificando la propiedad por defecto de un proyecto o grupo de proyectos, por ejemplo, para cualquier unidad de negocios aplicable, centros de costos, o personal. Una jerarquía de relaciones del proyecto se puede establecer entre los registros principales del proyecto y la propiedad administrativa anticipada del proyecto. El código de impacto del proyecto puede ser especificado para reflejar una relación del proyecto con las tareas de negocios identificadas (Véase, por ejemplo, la Tabla 103) . Aunque se representa una estructura de dos niveles en las FIGs. 94A-B, se podria crear una estructura de niveles con más de dos niveles, sin apartarse de los principios de la invención. Refiriéndonos ahora a la FIG. 94A, un flujo 9400 del proceso de creación del grupo de proyectos comienza en el paso 9403, un usuario cliente o comprador autorizado activa un control de administración del proyectos desde, por ejemplo un barra de navegación de la página principal. En el paso, el usuario navega para crear un nuevo grupo de proyectos. En el paso 9408, el sistema provee al usuario con una forma de flujo de trabajo de entrada. En el paso 9410 el usuario da nombre al grupo de proyectos. En el paso 9413, el usuario proporciona una descripción del grupo de proyectos. En el poso 9417, el usuario especifica el personal autorizado del propietario/cliente o comprador del grupo de proyectos. En el paso 9420, el usuario especifica opcionalmente la(s) unidad (es) de negocios por defecto. En el paso 9423, el usuario opcionalmente especifica el (los) centros de costos por defecto. En el paso 9426, el usuario guarda las entradas hechas previamente. En el paso 9430, las especificaciones del usuario se almacenan en la base de datos. Refiriéndonos ahora a la FIG. 94B, un flujo 9540 del proceso de creación del principal o máster del proyecto comienza en el paso 9435. en el paso 9435, el usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9455, el usuario navega para crear un nuevo principal del proyecto. En el paso 9485, el sistema proporciona al usuario con una forma de flujo de trabajo de entrada. En el paso 9460, el usuario da nombre al principal del proyecto. En el paso 9462, el usuario proporciona un código interno del principal del proyecto. En el paso 9465, el usuario proporciona una descripción resumida del proyecto. En el paso 9468, el usuario especifica opcionalmente un código de propiedad del principal del proyecto (PM) por defecto, el cual define la parte responsable de la administración del proyecto, para el proyecto, como por ejemplo, en la Tabla 103. En el paso 9470, el usuario especifica un código de impacto del proyecto (Véase, por ejemplo, la Tabla 103) . En el paso 9473, el usuario especifica una afiliación del grupo de proyectos (es decir, de cuál grupo de proyectos es miembro el proyecto) . En el paso 9475, el usuario especifica las afiliaciones jerárquicas del proyecto con el grupo de proyectos. En el paso 9477, el usuario guarda las entradas hechas previamente. En el paso 9480, las especificaciones del usuario se almacenan en una base de datos . Las FIGS. 95A-B siguen un patrón similar como se describe arriba en las FIGS. 95A-B tratan con la creación y almacenamiento del grupo de presupuestos/registro principal. El almacenamiento de datos descrito en las FIGS. 95A-B ocurre en las tablas de la base de datos, tales como por ejemplo, las Tablas 118 y 119. Los datos presupuestarios son datos de administración dentro del sistema 9011 de administración financiera del componente 9001 de datos de información principal. Aunque se representa una estructura de presupuestos de dos niveles en las FIGS. 95A-B, se podria crear una estructura de niveles con más de dos niveles sin apartarse de los principios de la invención. En una manera análoga a los grupos de proyectos, un grupo de presupuestos es una colección de uno o más presupuestos. Como se apreciará por aquellas personas que tienen experiencia en la técnica, los presupuestos se categorizan típicamente de acuerdo con la organización de negocios, tal como, por ejemplo, en una manera jerárquica por división, unidad de negocios, y centro de costos. Sin embargo, los principios de la invención relativos con el cálculo de presupuestos, que incluyen la estructuración de grupos de presupuestos y de los principales de presupuestos, se pueden usar para estructurar las funciones de cálculo de presupuestos de una empresa en varias maneras diferentes de acuerdo con las necesidades de la empresa. Los registros del principal de prepuestos y del grupo de presupuestos se encuentran típicamente dentro del sistema 9011 de administración financiera. Refiriéndonos ahora a la FIG. 95A, un flujo 9500 del proceso de creación del grupo de presupuestos comienza en el paso 9502. En el paso 9502, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9506, el usuario navega para crear un nuevo grupo de presupuestos. En el paso 9510, el sistema proporciona al usuario una forma de entrada del flujo de trabajo. En el paso 9514, el usuario da nombre al grupo de presupuestos. En el paso 9518, el usuario proporciona una descripción del grupo de presupuestos. En el paso 9522, el usuario especifica el personal autorizado del propietario/cliente o comprador del grupo de presupuestos. En el paso 9526, el usuario especifica opcionalmente la(s) unidad(es) de negocios por defecto. En el paso 9530, el usuario especifica opcionalmente el (los) centro (s) de costos por defecto. En el paso 9534, el usuario especifica una cantidad en dólares del grupo de presupuestos. En el paso 9538, el usuario especifica un presupuesto. En el paso 9542, el usuario guarda las entradas del usuario hechas previamente. En el paso 9546, las especificaciones se almacenan en la base de datos. Refiriéndonos ahora a la FIG. 95B, un flujo 9550 del proceso de creación del principal de presupuestos comienza en el paso 9552. En el paso 9552, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9556, el usuario navega para crear un nuevo principal de presupuestos. En el paso 9560, el sistema proporciona al usuario una forma de entrada del flujo de trabajo. En el paso 9564, el usuario da nombre al principal de presupuestos. En el paso 9568, el usuario proporciona una descripción resumida del principal de presupuestos. En el paso 9572, el usuario selecciona una afiliación del grupo de presupuestos (es decir a cual grupo de presupuestos pertenece el presupuesto) . En el paso 9576, el usuario especifica opcionalmente la (las) unidad (es) de negocios por defecto. En el paso 9580, el usuario especifica un presupuesto. En el paso 9584, el usuario especifica una cantidad en dólares del presupuesto. En el paso 9588, el usuario especifica el personal del propietario/cliente o comprador del principal de presupuestos. En el paso 9592, el usuario guarda ñas entrtadas hechas previamente. En el paso 9596, las especificaciones se almacenan en una base de datos . Las FIGS. 96A-B siguen un patrón similar como se describe arriba para la configuración de los principales/grupos de proyectos y los principales/grupos de presupuestos en las FIGS. 94A-B y 95A-B de arriba;, sin embargo, los flujo de proceso de las FIGS. 96A-B pertenecen a la creación y el almacenamiento de los grupos/principales de activos. Las FIGS. 96A-B ilustran la creación de registros del principal/grupo de activos como se describe de manera general con relación al paso 9310. el almacenamiento de datos representado en las FIGS. 96A-B ocurre en las tablas de base de datos, tales como por ejemplo, las Tablas 125-126. Los datos de activos creados en los flujo se dee proceso representados en las FIGS. 96A-B constituyen los datos de administración dentro del sistema 9011 de administración financiera del componente 9001 de datos de información principal. La creación del registro del grupo/maestro de activos como se representa en las FIGS. 96a-B puede servir para facilitar las varias funciones de contabilidad, tales como, por ejemplo, la depreciación de los activos por las varias organizaciones de negocios dentro de la empresa. Aunque se presenta una estructura de activos de dos niveles en las FIGS. 96A-B se podria crear una estructura con niveles con más de dos niveles, sin apartarse de los principios de la invención . Refiriéndonos ahora a la FIG. 96A, un flujo 9600 del proceso de creación del grupo de activos comienza en el paso 9602. En el paso 9602, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9606, el usuario navega para crear un nuevo grupo de activos. En el paso 9610, el sistema proporciona al usuario una forma de entrada del flujo de trabajo. En el paso 9614, el usuario da nombre al grupo de activos. En el paso 9618, el usuario proporciona una descripción del grupo de activos. En el paso 9622, el usuario especifica el personal autorizado del propietario/cliente o comprador del grupo de proyectos. En el paso 9626, el usuario especifica opcionalmente la(s) unidad (es) de negocios por defecto. En el paso 9630, el usuario especifica opcionalmente el (los) centro (s) de costos por defecto. En el paso 9634, el usuario guarda las entradas hechas previamente. En el paso 9638, las especificaciones se almacenan en una base de datos.

Refiriéndonos ahora a la FIG. 96B, un flujo 9650 del proceso de creación del principal o máster de activos comienza en el paso 9652. En el paso 9652, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9656, el usuario navega para crear un nuevo principal de activos. En el paso 9660, el sistema proporciona al usuario una forma de entrada del flujo de trabajo. En el paso 9664, el usuario da nombre al principal de activos. En el paso 9668, el usuario proporciona una descripción de los activos. En el paso 9672, el usuario selecciona una afiliación del grupo de activos. En el paso 9676, el usuario especifica el personal del propietario/cliente o comprador del principal de activos. En el paso 9680, el usuario especifica opcionalmente la(s) unidad (es) de negocios por defecto. En el paso 9864, el usuario especifica opcionalmente el (los) centro (s) de costos por defecto. En el paso 9688, el usuario especifica opcionalmente la cantidad en dólares de los activos. En el paso 9692, el usuario especifica opcionalmente una fecha de adquisición de los activos. En el paso 9696, el usuario guarda las entradas hechas previamente. En el paso 9699, las especificaciones se almacenan en una base de datos.

Los procesos ejemplificantes discutidos con relaciona las FIGS. 94A-B hasta ahora pueden implicar que estos son procedimientos necesariamente consecutivos. Sin embargo, aquellas personas que tengan experiencia en la técnica reconocerán que de hecho estos son procesos de aplicación independientes que no necesitan ser llevados a cabo en el orden descrito. La FIG. 97 es un flujo del proceso para la creación y almacenamiento de los registros del principal de contratos con el fin de capturar los elementos específicos de información de los contratos con el fin de integrar la información de contratación con los proyectos y por ultimo con los datos transaccionales de trabajo del proyecto. El flujo de proceso descrito en la FIG. 97 puede ser usado para especificar varios atributos de un contrato utilizado por la empresa, con el fin de asegurarse de que esos atributos se satisfacen durante el trabajo del proyecto emprendido por o a nombre de la empresa. Un registro del principal de contratos se almacena en una tabla de la base de datos, tal como, por ejemplo, la Tabla 123. Aquellas personas que tengan experiencia en la técnica entenderán que la información de contratos se guarda típicamente en un formato de prosa ya sea en un documento de texto electrónico, en papel, o ambos. En tales casos, típicamente no existe una capacidad de procesamiento de datos o de interoperabilidad aplicable a la información de los contratos, puesto que los documentos en prosa no representan un elemento del procesamiento de aplicación tradicional. Aunque no se ilustra específicamente en la FIG. 97. Aquellas personas que tengan experiencia en la técnica apreciaran que los registros de contratos se podrian asignar a niveles en una manera similar a aquella descrita arriba con relación a los proyectos, los activos, y lo presupuestos. Los registros de contratos típicamente se encuentran dentro del sistema 9015 de administración de proveedores. Refiriéndonos ahora a la FIG. 97, un flujo 9700 del proceso de creación de registros de contratos comienza en el paso 9703. En el paso 9703, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9706, el usuario navega para crear un nuevo principal de contrato. En el paso 9709, el sistema proporciona al usuario una forma de entrada del flujo de trabajo. En el paso 9712, el usuario especifica un tipo de contrato. En el paso 9715, el usuario proporciona una referencia del contrato. En el paso 9718, el usuario especifica las fechas de inicio y terminación del contrato. En el paso 9721, el usuario especifica opcionalmente una cantidad máxima gastada en el contrato. En el paso 9724, el usuario especifica opcionalmente la(s) unidad (es) de negocios por defecto. En el paso 9727 , el usuario especifica opcionalmente el (los) centro (s) de costos por defecto. En el paso 9730, el usuario especifica el alcance de las actividades contratadas. En el paso 9733, el usuario especifica opcionalmente las exclusiones contratadas. En el paso 9736, el usuario especifica un proveedor. En el paso 9739, el usuario especifica opcionalmente un cliente. En el paso 9742, el usuario especifica un propietario del contrato. En el paso 9745 el usuario guarda las entradas hechas previamente. En el paso 9748, las especificaciones se almacenan en una base de datos . La FIG. 98 representa un flujo del proceso pertinente para la creación y el almacenamiento de los registros del principal de eventos de negocios. Los eventos de negocios son las actividades del cliente o comprador que, aunque no se relacionan directamente con el trabajo del proyecto, puede tener una relación de causa o de efecto relativa con uno o más proyectos que se emprenden por una entidad cliente o comprador. Un ejemplo de un evento de negocios seria un proyecto que involucra la creación de un nuevo producto. Una campaña de publicidad y mercadotecnia para lanzar el producto podria se considerada un evento de negocios, ya que la campaña de publicidad y mercadotecnia discutiblemente tienen nada que ver con la creación del producto del proyecto, sin embargo, el evento de negocios es dependiente del proyecto para crear el producto que ha sido completado. Si, por ejemplo, se determina que el producto nunca será creado debido a alguna falla dentro del proyecto, seria desaconsejable gastar dinero innecesariamente en el evento de negocios dependiente, es decir, la campaña de publicidad y mercadotecnia relacionada con el mismo. Un registro principal del evento de negocios se almacena en las tablas de la base de datos, tales como, por ejemplo, la Tabla 121. En el caso de una falla catastrófica, el evento de negocios podria ser retardado o podria experimentar una modificación material colateral a la luz de la notificación de riesgo del proyecto. Aunque no se ilustra específicamente por tener una estructura de niveles como en la discusión anterior de los proyectos, los presupuestos, y los activos, aquellas personas experimentadas en la técnica apreciaran que los eventos de negocios se podrian estructurar en una manera de niveles sin apartarse de los principios de la invención. Refiriéndonos otra vez a la FIG. 98, un flujo 9800 del proceso de creación de registros de eventos de negocios comienza en el paso 9803. En el paso 9803, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9806, el usuario navega para crear un nuevo evento de negocios. En el paso 9810, el sistema proporciona al usuario una forma de entrada del flujo de trabajo. En el paso 9813, el usuario da nombre al principal o máster del evento de negocios. En el paso 9816, el usuario proporciona una descripción del evento de negocios. En el paso 9820, el usuario selecciona una un propietario del evento de negocios. En el paso 9823, el usuario especifica opcionalmente la(s) unidad (es) de negocios por defecto. En el paso 9826, el usuario especifica opcionalmente el (los) centro (s) de costos por defecto. En el paso 9830, el usuario especifica opcionalmente las fechas de inicio y finalización planeadas. En el paso 9833, el usuario especifica opcionalmente una ubicación planeada. En el paso 9836, el usuario especifica opcionalmente las afiliaciones del cliente con el evento de negocios. En el paso 9840, el usuario especifica un código del impacto del evento de negocios. En el paso 9843, el usuario guarda las entradas hechas previamente. En el paso 9846, las especificaciones se almacenan en una base de datos. Una vez que los elementos de datos de información principal tales como los registros de presupuestos, activos, contratos y eventos de negocios se afilian con un principal de proyecto o grupo de proyectos, estos se convierten entonces en datos principales. Por otro lado, si no se uan en el contecto del trabajo del proyecto o los datos transaccionales de procuración general, estos simplemente son datos de información principal sin uso. Una vez que se hacen las afiliaciones de los proyectos con los datos principales, las especificaciones resultantes se almacenan en el sistema 9017 de administración de proyectos. La fog 99 ilustra un flujo de proceso para la afiliación del principal del proyecto a los datos principales. Un flujo 9900 del proceso representa la asignación de los registros principales de proyectos a otros registros principales (por ejemplo, los registros principales de presupuestos, activos, eventos de negocios o contratos). Las asignaciones del flujo 9900 de proceso típicamente se almacenan en las tablas de la base de datos, tales como, por ejemplo, las Tablas 117, 120, 122, 124, y 127, el flujo 990 del proceso se desprende del registro principal del proyecto de la entidad cliente o comprador; sin embargo aquellas personas que tengan experiencia en la técnica reconocerán que este es un modo ejemplificante. El flujo 990 de proceso podria emanar de los componentes de información de los datos principales que se afilian con estos y fluir en la dirección opuesta. Como el flujo 9900 de proceso lo indica, las entradas de información individuales pueden variar dependiendo de las afiliaciones que se hagan. Estas afiliaciones representan una asignación inicial por defecto la que puede cambiar una vez que se licita el proyecto. La asignación de los registros principales de proyecto del sistema 9017 de administración de proyectos con otros registros de datos de información principal se vuelve típicamente más definitiva cuando se introducen los datos transaccionales de trabajo del proyecto. Aunque no se muestra explícitamente dentro del flujo 9900 de proceso, aquellas personas que tengan experiencia en la técnica reconocerán que la edición las afiliaciones de los registros del principal o máster del proyecto, se puede llevar a cabo después que se han introducido los datos transaccionales de registro del proyecto. Refiriéndonos otra vez a la FIG. 99, el flujo 9900 del proceso comienza en al paso 9903. En el paso 9903, un usuario cliente o comprador autorizado activa un control de administración de proyectos desde, por ejemplo, una barra de navegación de la página principal. En el paso 9906, el usuario cliente o comprador navega para administrar el principal del proyecto. En el paso 9910, el sistema despliega los registros del principal de los proyectos disponibles para el usuario cliente o comprador. En el paso 9913, el usuario cliente o comprador selecciona un registro del principal del proyecto deseado. En el paso 99165, el sistema despliega al usuario los elementos de datos relacionados con el principal del proyecto configurado. En el paso 9920, el sistema proporciona al usuario un control llamado "relaciones de visualización" o los similares. En el paso 9923, el usuario activa el control de "relaciones de visualización" . En el paso 9926, el sistema despliega una vista de resultados de la relación de registros principales del proyecto. La vista de resultados de la relación de registros principales del proyecto se segmenta típicamente por proyectos, presupuestos, activos, contratos y eventos de negocios . Del paso 9926, la ejecución procede al paso 9930. En el paso 9930, se informa al usuario con respecto a si el usuario desea editar las especificaciones. Conforma a la respuesta, en el paso 9930 en afirmación, la ejecución procede al paso 9933. En el paso 9933, el sistema informa al usuario para seleccionar una categoría de los datos de información principal. En el paso 9936, el usuario selecciona una categoría de datos de información principal (por ejemplo, presupuestos, contratos, eventos negocios, o activos). En el paso 9940, el sistema informa al usuario para seleccionar "editar el registro existente" o "crear nueva relación". En el paso 9943, si el usuario selecciona "crear nueva relación" el sistema proporciona al usuario un despliegue de los registros principales de las categorías de datos de información principal disponibles, en el paso 9946.

En el paso 9950, el usuario puede seleccionar los registros principales deseados. En el paso 9953, el sistema informa al usuario para completar la afiliación y los requerimientos de entradas de datos configuradas. En el paso 9956, el usuario completa las entradas requeridas. En el paso 9960, el usuario guarda las especificaciones tras la terminación de las afiliaciones de los registros seleccionados. En el paso 9963, las afiliaciones de relaciones se almacenan en una base de datos y se marcan con un estado de "pendiente". En el paso 9966, el sistema transmite las afiliaciones registradas a los propietarios de los registros de negocios afectados por las afiliaciones. En el paso 9970, el sistema informa a los propietarios de los registros de negocios afectados para aprobar o rechazar las afiliaciones registradas. En el paso 9973, se permite que los propietarios de los registros de negocios afectados aprueben o rechacen las afiliaciones. Conforme a la aprobación de las afiliaciones, la ejecución procede al paso 9976, en tal paso las afiliaciones se almacenan en una base de datos con el estadio de "actuales". Sin embargo, si en el paso 9983, se rechaza la disposición de las afiliaciones, la ejecución procede al paso 9980,1 en tal paso se almacenan las afiliaciones en una base de datos con un estado de "rechazada". Desde cualquiera de los pasos 9976 o 9980, la ejecución procede al paso 9983. En el paso 9983, el sistema notifica al solicitante de la disposición (es decir, el usuario cliente o comprador) de la disposición del propietario del registro. Por lo tanto, en la conclusión del flujo 9900 del proceso, el registro principal del proyecto se afilia con otros registros de datos de información principal, tales como, por ejemplo, los registros principales de presupuestos, los registros principales de activos, los registros principales de contratos, y los registros principales de eventos de negocios. En varias modalidades de la invención, los otros propietarios de los registros a los cuales el usuario cliente o comprador busca afiliar el registro principal del proyecto, tienen la autoridad para aprobar o rechazar la afiliación solicitada por el usuario cliente o comprador del registro principal del proyecto . La FIG. 100 representa una Interfaz de Usuario de la Página Principal de Administración de Proyectos ejemplificante para un Usuario Cliente o Comprador. La FIG. 101 representa un esquema que habilita la base de datos que soporta las actividades discutidas aqui. Aquellas personas que tengan experiencia en la técnica reconocerán que la implementación de varias modalidades de la invención en in sistema basado en red (por ejemplo, la red internacional) típicamente utilizará ya sea un código y o una base de procesamiento de información de la base de datos. Los esquemas de bases de datos y las tablas de bases de datos correspondientes incluidas aqui sirven como un ejemplo de cómo se podria hacer tal implementación basada en red. Adquisición y almacenamiento de los Datos Tansaccionales de Trabajo del Proyecto Las FIGS. 102-103 ilustran con detalle la adquisición y el almacenamiento de los datos transaccionales de trabajo del proyecto ilustrados de manera general en los pasos 9320-9335 de la FIG. 93. Un flujo de proceso ilustrado en la FIG. 102 sirve para integrar dos diferentes conjuntos de datos con otro. En otras palabras, el registro principal del proyecto se afilia con una licitación RFX. Enseguida de esta afiliación, se emprende un proceso de licitación RFx análogo al discutido arriba antes de la FIG. 89. La FIG. 102 ilustra una vista resumida de una licitación RFx a través del flujo 10200 de proceso de la activación de la orden de compra. Los pasos 10215-10244 del flujo 10200 de proceso representan un sub-proceso por medio del cual se asignan las solicitudes de licitación con un registro principal existente del proyecto. El establecimiento de las relaciones resultantes de los pasos 10215-10240 se almacenan en la tabla de base de datos, tal como, por ejemplo, la Tabla 128, y sirven como una asignación a las requisiciones de compra subsecuentes como resultado de una adjudicación de la licitación, en cuyo caso los establecimientos de relaciones se almacenan en una tabla de base de datos tal como, por ejemplo, la Tabla 129. Son posibles procesos variantes, tales como pero no limitados a, cuando el usuario no tiene la autoridad para examinar los registros principales de proyectos, los registros principales de proyectos disponibles no son pertinentes para las actividades de la solicitud de licitación, o el propietario del proyecto necesita autorizaciones de notificación o aprobación para las solicitudes de licitación relacionadas con el proyecto. La solicitud de licitación de trabajo del proyecto ilustrada en la FIG. 102 emana de una necesidad de negocios o un proyecto definido. La asignación de la solicitud de licitación al registro principal del proyecto facilita la integración posterior entre los datos transaccionales que resultan de un proceso de licitación exitoso con los registros de datos principales configurados previamente. Refiriéndonos otra vez a la FIG. 102. el flujo 10200 del proceso comienza en el paso 10205. En el paso 10205, un usuario cliente o comprador autorizado activa un control de creación de RFP/RFQ desde, por ejemplo, una barra de navegación de la página principal del cliente o comprador (Véase, por ejemplo, la FIG. 4A) . Del paso 10205, la ejecución procede al paso 10210. En el paso 10210, el usuario cliente o comprador selecciona "crear nueva RFQJ' . En el paso 10215, el sistema solicita al usuario filiar el RFW con un registro principal del proyecto disponible. En el paso 1022, el usuario cliente o comprador selecciona un control de "afiliación del principal o máster del proyecto". En el paso 102225, el sistema proporciona al usuario un despliegue de lista de los registros principales del proyecto. En el paso 10230, el usuario cliente o comprador selecciona un registro principal del proyecto aplicable. En el paso 10235, el usuario cliente o comprador guarda la afiliación. En el paso 10240, la afiliación de licitación RFx con el principal del proyecto se almacena en una base de datos. En el paso 10245, el cliente o comprador procesa la licitación RFx como, por ejemplo, en las FIGS. 16A-D. En el paso 10250, el proveedor procesa la respuesta de licitación RFx como, por ejemplo, en la FIG. 25. En el paso 10255-10260, el cliente o comprador procesa y adjudica la respuesta de licitación RFx del proveedor, por ejemplo, como en las FIGS. 31-37. En los pasos 10270-10275, el cliente o comprador y el proveedor procesan una requisición/orden de compra, por ejemplo, como en la FIG. 40C. En el paso 10280, el cliente o comprador activa la orden de compra, por ejemplo, como en la FIG. 40. La FIG. 103 ilustra un esquema 10300 modificado de la base de datos de procuración que incluye conectividad entre lo datos principales, la solicitud de licitación, y los datos de ordenes de compra. El esquema 10300 permite la conectividad de alto nivel del sistema 9017 de administración de proyectos y el sistema 9013 de administración de adquisiciones. Configuración del Registro de Declaración de Trabajo (SOW) Las FIGS. 104-105 ilustran la configuración del registro de Declaración de Trabajo (SOW) . El proceso de configuración de registro de la SOW se describe de manera general en los pasos 9340-9350 de la FIG. 93. La FIG. 104 ilustra una dinámica 10400 de la declaración de trabajo, de acuerdo con los principios de la invención. El proyecto A 10450 de divide en cuatro Licitaciones 10410 (a) -(d) RFx distintas. Las licitaciones 10410 (a) -(d) RFx podrian resultar finalmente en la expedición de adjudicaciones 10420 (a) -(d) de las licitaciones tras la terminación de los procesos de licitación y revisión de las respuestas de la licitación. Las actividades 10425 (a) - (d) de trabajo del proyecto adjudicado se integran en módulos 10430 (a) - (d) de requisición/orden de compra para el procesamiento de los datos por la entidades tanto cliente o comprador y proveedor. Las actividades 10425 (a) -(d) de trabajo del proyecto individuales definidas y almacenadas en las órdenes de compra se pueden asignar a los entregables específicos contenidos en los módulos 10430 (a) - (d) de entregables de la orden de compra. En efecto, las actividades e la linea e la orden de compra se pueden agregar para reflejar a qué registro de entregables se relacionan o se afilian. Esta asignación se representa como los elementos 10432 (a) - (d) . Los entregables resultantes con las actividades afiliadas se representan como los elementos 10435(a)-(d) . Un concepto del nivel del proyecto representa un nivel de construcción de relaciones adicional que asigna los entregables/SOWs de los componentes de trabajo del proyecto específicos del proveedor en un marco de los entregables/SOWs del proyecto global. Es común tener varios proveedores trabajando independientemente o en tándem hacia un resultado acumulado en tanto que trabajan y producen sus resultados individuales como se estipula en las licitaciones y las ordenes de compra respectivas. Un ejemplo es cuando un proyecto está siendo administrado tácticamente en pedazos de progreso tales como fases. Tradicionalmente, muchos entregables de varios proveedores, contratados como resultado de las diferentes licitaciones RFx, resultarían colectivamente, tras la terminación exitosa, en la consecución de los entregables/SOWs. Este agregado de entregables pequeños en etapas importantes mayores a nivel del proyecto se recocerán por aquellas personas que tengan experiencia en la técnica como el modelo de proyecto en fases tradicional. La asignación/afiliación de varias SOWs de los proveedores en una etapa importante o fase del proyecto se representa como el elemento 10438 y resulta en las SOWs del proveedor unidas, integradas en una fase de proyecto agregada. La dinámica 10400 hasta ahora divide los varios entregables del proyecto en agregados de etapas importantes mayores. En este punto, se establecen relaciones entre los entregables y se configura una jerarquía de dependencias (es decir, causas y efectos) dentro del conjunto de registros afiliados. La configuración, representada por el elemento 10440, resulta en una jerarquía 10445 completada de entregables del trabajo del proyecto, por medio de la cual todos los resultados finitos del trabajo del proyecto no se vinculan con el progreso de las etapas importantes del proyecto, sino que se definen en una manera que facilita la administración de causas y efectos. Por lo tanto, los entregables se vinculan para definir las dependencias entre los distintos registros de entregables/SOWs .

El siguiente aspecto de la construcción de relaciones es la capa de relaciones de proyectos a grupos de proyectos. Dentro de las carteras del proyecto hay varias actividades independientes que tienen lugar en varios proyectos los cuales tienen un impacto de causa y defecto. Por lo tanto, la necesidad de esta conectividad. Los proyectos familiares (es decir, los proyectos dentro de un grupo de proyectos) se representan como el elemento 10450, en tanto que la asignación de relaciones entre el Proyecto A y el Proyecto X se representa como el elemento 19455. Cuando la asignación de relaciones tiene lugar dentro del mismo ambiente de procesamiento de datos y de estructura de la base de datos, la misma configuración de jerarquías de las dependencias puede tener lugar aun a través de los resultados de entregables que pertenecen a diferentes proyectos. Esta conectividad representa una tercera capa de integración de la SOW del proyecto, la cual es la integración de SOW/entregables de varios proyectos. Enseguida se describe la integración de los registros de SOWs/entregables fuera del ambiente de trabajo del proyecto y en el marco de negocios general de la empresa. Esta integración se representa respectivamente por lo elementos 10462, 10468, 10472 y 10478 y tienen como objetivo los elementos, 10460, 10465, 10470, y 10475 de datos de información principal. La FIG. 105 es una página de red principal del proyecto del usuario cliente o comprador ejemplificante accesible, por ejemplo, desde una página principal de administración de proyectos via una navegación del usuario y la selección del registro. La FIG. 105 representa la información primaria y el portal de procesamiento relativos a un proyecto especifico para los usuarios autorizados. El acceso de los usuarios los controles funcionales individuales en la página se controla por las autorizaciones de usuario. La FIG. 106 es un flujo de proceso ejemplificante que representa la afiliación del trabajo del proyecto con los registros de entregables/SOW. El flujo de proceso ilustrado en la FIG. 106 se describe generalmente en los elementos 10432 y 10435 de la FIG. 104. En la FIG. 106, el flujo 10600 de proceso de afiliación de las actividades de orden de compra con los registros de entregables de órdenes de compra comienza en el paso 10605. En el paso 10605, un usuario cliente o comprador autorizado acceder a las órdenes de compra via la navegación, por ejemplo, desde una página principal del master del proyecto. En el paso 10610, el usuario cliente o comprador selecciona una orden de compra aplicable. En el paso 10615, el sistema proporciona al usuario un despliegue del encabezamiento de la orden de compra y los detalles de los rubros de linea. En el paso 10615, las órdenes de compra se controlan por los códigos de estado. Por lo tanto, algunas órdenes de compra pueden estar aun por ser aprobadas o en un estado de procesamiento donde estas son aun requisiciones de compra. Por lo tanto, el paso 10615 se relaciona con el despliegue al usuario de las órdenes de compra que están completas, aprobadas, y listas para la asignación de los rubros de linea de no entregables de la orden de compra con los entregables/SOW. En el paso 10620, las opciones activas de control se proporcionan al usuario para configurar las relaciones de actividades o editar las relaciones de actividades. El paso 10620 refleja la necesidad práctica de poder editar las relajaciones de rubros de linea con los entregables. En respuesta a la selección de la opción de relaciones de actividades configuradas en el paso 10620, en el paso 10625 el sistema proporciona al usuario un despliegue de lista segmentada de rubros de linea entregables de la orden de compra y de no entregables de la orden de copra. El paso 10625 aborda la segmentación de los registros de entregables/SOW desde los rubros de linea de la orden de compra de no entregables. En el paso 10639, el usuario selecciona el registro de entregables deseado via, por ejemplo, un recuadro de selección. En el paso 10635, el usuario selecciona una registro o registros de rubros de linea no entregables afiliado via, por ejemplo, un botón de radio. En el paso 10640, el usuario activa un control de "guardar configuración". En este punto en el flujo 10600 de proceso, el usuario cliente o comprador ha afiliado un entregable de la orden de compra con uno o más artículos de linea de no entregables de la orden de compra. En el paso 10645, el sistema corre una rutina de validación. La rutina de validación del paso 10645 típicamente implica una operación de comparación de fechas. Por ejemplo, cuando los rubros de linea no entregables de la orden de compra contienen información sobre actividades especificas, se puede llevar a cabo una comparación de fechas simple para asegurarse de que las actividades asociadas con los rubros de linea de no entregables de la orden de compra no se extiendan lógicamente, por ejemplo, más allá de una fecha de vencimiento para el entregable de la orden de compra. Por ejemplo, si un entregable de la orden de compra se vence el 15 de octubre del 2006 y el usuario cliente o comprador ha afiliado cuatro rubros de linea no entregables de la orden de compra con las actividades asociadas que están activas y se extienden hasta enero del 2007, la rutina de validación del paso 10645, probablemente indicarla un conflicto. Si en el paso 10650, se aprueba la validación, en el paso 10655, las afiliaciones de actividades de linea de la orden de compra con los entregables de la orden de compra se almacenan en una base de datos. Si en el paso 10650 falla la validación, la ejecución procede al paso 10660. La ejecución también procede del paso 10655 al paso 10660. En el paso 10660, se proporciona al usuario un despliegue de lista de los rubros de linea no entregables de la orden de compra que se extienden más allá de una fecha de vencimiento de los entregables afiliados. En el paso 10665, se presentan al usuario opciones para eliminar los registros inválidos, modificar la fecha de vencimiento del no entregable, modificar la fecha del entregable, o guardar las afiliaciones no validas. Un ejemplo de una situación en la cual el usuario cliente o comprador podria desear guardar las afiliaciones no válidas seria en el caso de los rubros de linea no entregables de trabajo. Por ejemplo, si se asignaron un número de trabajadores del proyecto a un proyecto particular desde el inicio al final y su trabajo se aplicó a las actividades de varios entregables a través del proyecto, si, desde una perspectiva de registros de la orden de compra, sólo se creó un registro de asignación para los trabajadores, una situación en la cual la duración del empleo de uno o más de los trabajadores se extiende más allá de un entregable de la orden de compra particular afiliado, este conflicto aparente podria ser ignorado con seguridad por el usuario cliente o comprador. En tales casos, las asignaciones serian indicadas a varios registros de entregables/SOW. En el paso 10670, el usuario hace una selección de disposición variable en respuesta a las opciones presentadas en el paso 10665. En el paso 10675, la opción de disposición seleccionada resulta en modelos de flujo de trabajo variables. En el paso 10680, el usuario hace los cambios deseados. En el paso 10685, el usuario activa un control de "salvar los ajustes". Del paso 10685, la ejecución regresa al paso 10645. Aquellas personas que tengan experiencia en la técnica apreciarán que el flujo 10600 de proceso puede ser repretido por el usuario para cualquier registro de orden de compra no afiliado. Las configuraciones discutidas con relación a la FIG. 106 son tablas de base de datos almacenadas, por ejemplo, las Tablas 134 y 135. el flujo 10600 del proceso resulta finalmente en la afiliación definida de los rubros de linea de actividad de trabajo del proyecto para definir las SOWs de entregables del proveedor. El siguiente modo de configuración es la integración de registros de entregables/SOW de la orden de compra en el marco de proyecto completo. La FIG. 107 ilustra un flujo 10700 del proceso de creación de registros de fases del proyecto que representa la creación de registro de fases del proyecto y del esquema de faseamiento. El flujo 10700 del proceso se representa de manera general en el elemento 10483 de la FIG. 104. El flujo 10700 comienza en el paso 10705. En el paso 10705, un usuario cliente o comprador autorizado accede al faseamiento del proyecto via la navegación desde, por ejemplo, una página de red principal de proyectos. En el paso 10710, el sistema proporciona al usuario un despliegue de lista de los registros de fases del proyecto. En el paso 10715, se hace una evaluación en cuanto a si existen tales registros. Si el paso 10715 se determina negativo, la ejecución procede al paso 10720. En el paso 10720, el sistema proporciona al usuario una fase de entrada de la estructura de fases. En el paso 10730, el sistema pide al usuario que especifique el número de fases del proyecto. En el paso 10735, el sistema proporciona al usuario un despliegue de lista de los registros de fases del proyecto en respuesta a la entrada del usuario hecha en el paso 10730. En el paso 10740, el usuario selecciona la fase deseada. En el paso 10745, el sistema proporciona al usuario una página de entrada de fases. En el paso 10750, el usuario completa las entradas. En el paso 10755, el usuario guarda los ajustes. En el paso 10760, las fases del proyecto se guardan en una base de datos. En el paso 10765, el usuario repite los pasos precedentes del flujo 10700 del proceso para todos los registros de faseamiento aplicables. El flujo 10700 del proceso representa una situación en la cual no existen registros de faseamiento del proyecto, con el fin de enfatizar que los registros de faseamiento del proyecto podrian existir, como seria el caso una vez que se crea un registro. Sin embargo, la configuración del esquema de faseamiento no es necesariamente lineal y subsecuente cronológicamente con los flujos de proceso previos descritos. Por ejemplo, un cliente o comprador puede tener un plan de proyecto muy estrecho establecido antes del inicio del proceso de licitación y podria potencialmente tener estos registros de formación de fases establecidos antes de pasar a licitar sobre los requerimientos específicos. Por el contrario, no es poco común establecer un plan de faseamiento después de las licitaciones o aceptar el plan de faseamiento de un proveedor o grupo de proveedores que trabajan en conjunción con un administrador del proyecto. Por lo tanto, la configuración del plan de faseamiento es variable y dependiente del escenario especifico del trabajo del proyecto encontrado, siempre que los registros de faseamiento del proyecto se creen antes del flujo del proceso de la FIG. 108 a continuación. Los registros de faseamiento se almacenan en una tabla de base de datos, tal como, por ejemplo, la Tabla 136.

La FIG. 108 ilustra un flujo 10800 de proceso de afiliación de entregables de la orden de compra con las fases del proyecto, el cual es la siguiente agregación/asignación que existe entre los registros de entregables/SOW y los registros de faseamiento del proyecto. Estas asignaciones se almacenan en una tabla de base de datos, tal como por ejemplo, la Tabla 137. Tras a terminación del flujo 10800 de proceso, las actividades de trabajo del proyecto (es decir, los datos transaccionales) han sido afiliados con el faseamiento del proyecto de la FIG. 107 con el fin de facilitar que los objetivos se cumplan dentro de los periodos de tiempo aplicables . Regresando a la FIG. 108, el flujo 10800 del proceso comienza en el paso 10805, en tal paso un usuario cliente o comprador autorizado accede al faseamiento del proyecto abierto via la navegación desde, por ejemplo, una página principal de master del proyecto. En el paso 10810, el sistema proporciona al usuario un despliegue de lista de los registros de fases del proyecto, en el paso 10815, el usuario selecciona un registro de fase deseado. En el paso 10820, el usuario selecciona un control "afiliar entregables" proporcionado. En el paso 10825 el sistema proporciona al usuario un despliegue de lista de los entregables de la orden de compra no afiliados. En el paso 10830, el usuario selecciona los registros de entregables de la orden de compra, deseados, via por ejemplo, un botón de radio. En el paso 10835, el usuario guarda los ajustes seleccionados en el paso 10830. En el paso 10840, el sistema pide al usuario que complete las entradas. En el paso 10845, el usuario completa las entradas. En el paso 10850, el usuario guarda los ajustes de entradas. Los pasos 10840-10850 típicamente se refieren a los ajustes de fases pre-definidos tales como, por ejemplo, ajustes de importancia de las fases. (Véase, por ejemplo, la Tabla 137) En el paso 10855, los entregables de fase de proyecto se almacenan en una base de datos. En el paso 10860, el usuario repite el flujo 10800 del proceso para todos los registrso de faseamiento y de entregables de la orden de compra . La FIG. 109 ilustra un flujo 10900 del proceso de configuración de dependencias de SOW/entregables del proyecto, el flujo 10900 del proceso comienza en el paso 10905, en tal paso un usuario cliente o comprador autorizado accede a la información de administración de SOW via la navegación desde, por ejemplo, una página principal de master del proyecto. En el paso 10908, el sistema proporciona al usuario un despliegue de lista de los registros de SOW del proyecto agregados por el registro de faseamiento. En el paso 10910, se proporcionan al usuario opciones para visualizar el esquema de relaciones, crear el esquema de relaciones, o editar el esquema de relaciones. En otras palabras, en el paso 10910, se indica al usuario con respecto a si crear, visualizar, o editar las dependencias entre los registros de la SOW. En respuesta a la selección por el usuario en el paso 10910 de la opción de "crear el esquema de relaciones"; la ejecución procede al paso 10915. En el paso 10915, el sistema pide al usuario seleccionar una SOW de la orden de compra de una lista. En el paso 10918, el usuario selecciona un registro de la SOW. En el paso 10920, el sistema puede al usuario seleccionar un registro afiliado. En el paso 10925, el usuario selecciona el registro de la SOW afiliado. En el paso 10925, la selección de los registros afiliados se representa como la selección de un registro afiliado. Sin embargo, no es necesario que haya tal limitación, ya que se puede proporcionar la funcionalidad para facilitar la selección de un bloque de registros para el procesamiento. En el paso 10930, el sistema proporciona al usuario una página de configuración de relaciones de la SOW. (Véase, por ejemplo, la Tabla 139, la cual incluye los elementos de datos ejemplificantes para una página de configuración) . En el paso 10933, el usuario especifica una relación de la SOW, por ejemplo, desde un menú desplegable. En el paso 10937, el usuario especifica si se fuerza una restricción de dependencia, lo que significa que el registro de la SOW dependiente no puede ser iniciado hasta que el registro del cual esta depende ha ya sido completado. La especificación de restricciones forzadas o no forzadas implica la posibilidad de que una dependencia de un entregable a otro que vuelve el entregable dependiente imposible de completar, no permita que tengan lugar todas las actividades. En tal caso, no habría deseos de forzar una restricción. Por ejemplo, si un resultado del entregable es una guia de mantenimiento técnico que es dependiente de la construcción de la infraestructura fisica de una red de computadoras, seria prudente forzar la restricción, especificando por lo tanto que el entregable dependiente no puede ser iniciado hasta la terminación del entregable principal . En el paso 10940, el usuario ingresa cualquier comentario opcional deseado. En el paso 10945, el usuario selecciona un control de "guardar las relaciones". En el paso 10950, el sistema valida las variables de relación usando, por ejemplo, una comparación de fechas de terminación. En el paso 10955, ocurre la disposición de la validación. En respuesta a la validación aprobada, la ejecución procede al paso 10960. En el paso 10960, la afiliación de SOW/entregables se guarda en una base de datos. En respuesta a la falla de la validación en el paso 10955, la ejecución procede al paso 10965. En el paso 10965, se proporciona al usuario un despliegue de lista de variables de validación fallidas. En el paso 10970, se presentan al usuario las opciones para salir de la sesión o modificar una variable de validación con el fin de intentar la revalidación con base en la variable modificada. En respuesta a la selección por el usuario de una opción de variable de validación modificada, la ejecución procede al paso 10975. En el paso 10975, el usuario hace una selección de disposición. En el paso 10980, la opción de disposición resulta en los modelos de flujo de trabajo variables. En el paso 10988, el usuario hace los cambios deseados. En el paso 10990, el usuario activa un control de "guardar los ajustes". Del paso 10990 la ejecución regresa al paso 10950. Como se apreciará por aquellas personas que tengan experiencia en la técnica, el usuario puede repetir el flujo 10900 del proceso según sea necesario. ' Los pasos de configuración de dependencias permiten que las etapas principales de resultados físicos del proyecto sean conectados y se establezcan las dependencias. Los tipos de relaciones, descritos en un modo ejemplificante en la Tabla 139, establecen las dependencias criticas de la SOW. El almacenamiento de los registros representado para el flujo 10900 del proceso tiene lugar en una tabla de base de datos, tal como, por ejemplo, la Tabla 138. La asignación de las SOWs entre los diferentes proyectos dentro de un grupo de proyectos es análogo, excepto que la interfaz de usuario funcional presenta una vista expandida de los registros de SOW/entregables para incluir un conjunto de registros de varios proyectos. La FIG. 110 ilustra un flujo 11000 de proceso ejemplificante que correlaciona los registros de SOW/entregables a los registros de datos principales de presupuestos como se describe de manera general en el paso 9345 de la FIG. 93. El flujo 11000 del proceso comienza en el paso 11005. En el paso 11005, un usuario cliente o comprador autorizado activa un control de administración de presupuestos desde, por ejemplo, una página principal del master de proyectos. En el paso 11010, el sistema proporciona al usuario un despliegue de lista de los registros principales de presupuestos relacionados con el proyecto configurados por defecto. En el paso 11015, el usuario selecciona un registro principal del presupuesto aplicable. En el paso 11020, el sistema proporciona al usuario un despliegue de lista de registros de SOW/entregables agregados por la fase del proyecto. En el paso 11025, el sistema pide al usuario que selecciona los registros de SOW/entregables o la fase del proyecto para la afiliación. En el paso 11030, el usuario hace una selección. En respuesta a la selección del usuario de una fase del proyecto en el paso 11030, la ejecución procede al paso 11035. En el paso 11035, el sistema proporciona una página de ingreso de datos al usuario. En el paso 11040, el usuario selecciona una unidad de negocios desde, por ejemplo, un menú desplegable. En el paso 11045, el usuario selecciona un centro de costos de, por ejemplo, un menú desplegable. En el paso 11050, el usuario selecciona un propietario del registro principal de presupuesto de, por ejemplo, un menú desplegable. En el paso 11055, el usuario guarda los ajustes hechos previamente. En el paso 11060, el sistema corre una rutina de validación del master del presupuesto basado en la fecha y/o el presupuesto. En el paso 11065 se hace una determinación en cuanto al master o principal del presupuesto ha sido validado. Si se determina asi en el paso 11065, la ejecución procede al paso 11070, en tal paso ocurre la notificación sistemática a un administrador del presupuesto aprobado. En el paso 11075, tiene lugar la disposición del administrador del presupuesto. En el paso 11060, en respuesta a la aprobación por el administrador del presupuesto en el paso 11075, las afiliaciones se almacenan en una base de datos. En el paso 11085 ocurre la notificación sistemática a los propietarios del proyecto. En el paso 11030, en respuesta a la selección del usuario de los registros de SOW/entregables para la afiliación, la ejecución procede al paso 11090. En el paso 1109, la selección del usuario de los registros de SOW/entregables individuales implica el mismo flujo de procesamiento de datos como para completar la afiliación de presupuestos de fase, con la excepción de que el procesamiento de información se completa para cada registro de SOW. Del paso 11090, la ejecución regresa al paso 11055. Las asignaciones o correlaciones del flujo 11000 de proceso se almacenan en una tabla de base de datos tal como, por ejemplo, en la Tabla 140. Aunque no se representa específicamente en la FIG. 110, se podria poner a disposición una funcionalidad para dividir las asignaciones para un entregables especifico entre varias unidades de negocios o entidades de centros de costos. Aquellas personas que tengan experiencia en la técnica apreciarán que el flujo 11000 de proceso podria emanar de varias direcciones con un administrador de presupuestos o el administrador del proyecto que inicia la asignación de configuración de los registros. La FIG. 111 ilustra un flujo 11100 del proceso ejemplificante que asigna los registros de SOW/entregable con los registros de datos principales de activos. El flujo 1110 del proceso comienza en el paso 11105, en tal paso un usuario cliente o comprador autorizado activa un control de administración de activos desde, por ejemplo, una página principal de master del proyecto. En el paso 11110, el sistema proporciona al usuario un despliegue de lista de los registros principales de activos relacionados con el proyecto, configurados. En el paso 11115, el usuario selecciona un registro principal de activos aplicable. En el paso 11120, el sistema proporciona al usuario un despliegue de lista de los registros de SOW/entregables con los rubros de lineas de materiales afiliados agregados por la fase del proyecto. En el paso 11125, el usuario selecciona los registros de SOW/entregables aplicables. En el paso 11130, el sistema proporciona al usuario un despliegue de lista de los rubros de lineas de materiales afiliados. En el paso 11135, el usuario selecciona un rubro de linea deseado. En el paso 11140, el sistema proporciona una página de ingreso de datos al usuario. En el paso 11145, el usuario selecciona una unidad de negocios de, por ejemplo, un menú desplegable. En el paso 11150, el usuario selecciona un centro de costos de, por ejemplo, un menú desplegable. En el paso 11155, el usuario selecciona un propietario administrativo del registro principal de activos desde, por ejemplo, un menú desplegable. En el paso 11160, el usuario guarda los ajustes hechos previamente. En el paso 11165, el sistema corre una rutina de validación del master o pricipal de activos basada en la fecha y/o el capital. En el paso 11170, se hace una evaluación de la validación. En respuesta a una evaluación de validación positiva, la ejecución procede al paso 11175. En el paso 11175, ocurre la notificación sistemática a un administrador de activos aprobado. En el paso 11180 se emprende la disposición del administrador del presupuesto. En respuesta a la aprobación en el paso 11180, la ejecución procede al paso 11185. En el paso 11190 ocurre la notificación sistemática al propietario del proyecto. Las asignaciones del flujo 11100 del proceso se almacenan en una tabla de base de datos, tal como, por ejemplo, en la Tabla 141. Como todas las asignaciones o correlaciones de datos principales, el flujo 11100 de proceso puede emanar de cualquier administrador del proyecto o de los propietarios de los registros de administración de activos. Aquellas personas que tengan experiencia en la técnica apreciarán que las varias modalidades se pueden configurar para controlar todas las actividades materiales definidas dentro del trabajo del proyecto para asegurar la visibilidad de administración de activos y la administración subsecuente de los mismos. En los ambientes de negocios típicos, los activos podrian ser fácilmente parte de una declaración de trabajo mayor (es decir, entregable) que se administra a nivel del contrato. Comúnmente los activos físicos no se definen aun dentro del contexto de un contrato o sistema de administración de activos especifico .

La FIG. 112 ilustra un flujo 11200 de proceso ejemplificante que asigna los registros de SOW/entregables a los registros de contratos. El flujo 11200 de proceso comienza en el paso 11205, en tal paso un usuario cliente o comprador autorizado activa un control de administración de contratos desde, por ejemplo, una página principal del master de proyectos. En el paso 11210, el sistema proporciona al usuario un despliegue de lista de los registros de contratos relacionados con el proyecto, configurados por defecto. En el paso 11215, El usuario selecciona un registro del contrato aplicable. En el paso 11220, el sistema proporciona al usuario un despliegue de lista de los registros de SOW/entregables agregados por la fase del proyecto. En el paso 11225, el usuario selecciona los registros de SOW/entregables aplicables. En el paso 11230, el sistema proporciona al usuario una página de ingreso de datos. En el paso 11235, el usuario selecciona una unidad de negocios de, por ejemplo, un menú desplegable. En el paso 11240 el usuario selecciona un centro de costos de, por ejemplo, un menú desplegable. En el paso 11245 el usuario selecciona opcionalmente un cliente aplicable de, por ejemplo, un menú desplegable. En el paso 11250, el usuario selecciona un propietario administrativo del contrato de, por ejemplo, un menú desplegable. En el o 11255, el usuario guarda los ajustes hechos previamente.

En el paso 11260, el sistema corre una rutina de validación de contratos. La validación no necesita ser sólo sensible al tiempo, si no también puede ser sensible al alcance. Otras variables que son sensibles pueden incluir, por ejemplo, el dinero y/o los tipos de suministro de los servicios/mercancías. En el paso 11265, se hace una determinación de la validación del contrato. En repuesta a una validación positiva en el paso 11265, la ejecución procede al paso 11270. En el paso 11270, ocurre la notificación sistemática a un administrador del contrato aprobado (es decir, el propietario del registro principal de contrato configurado) . En el paso 11275, ocurre la disposición del administrador del contrato. En respuesta a la aprobación en el paso 11275, la ejecución procede al paso 11280. En el paso 11280, las afiliaciones se almacenan en una base de datos. En el paso 11285, ocurre la notificación sistemática del propietario del proyecto. Las asignaciones del flujo 11200 del proceso se almacenan en una base de datos, tal como, por ejemplo, la Tabla 142. El flujo 11200 del proceso puede ser bi-direccional, aun cuando no se representa explícitamente como tal en la FIG. 112. La especificación de un cliente corriente abajo y la referencia del contrato subsecuente se puede usar para afiliar contratos de varios niveles con las actividades. Tal como seria el caso cuando, por ejemplo, una entidad cliente o comprador está utilizando un proveedor externo, bajo un contrato, para proporcionar los servicios para un usuario final, quien está bajo contrato para las mercancías/servicios con la entidad cliente o comprador. La FIG. 113 ilustra un flujo 11300 de proceso que asigna los registros de SOW/entregables con los registros de eventos de negocios. El flujo 11300 de proceso comienza en el paso 11303, en tal paso un usuario cliente o comprador autorizado activa el control de administración de negocios desde, por ejemplo, una página principal del master de proyectos. En el paso 11305, el sistema proporciona al usuario un despliegue de lista de los registros de eventos de negocios relacionados con el proyecto, configurados por defecto. En el paso 11310, el usuario selecciona un registro del evento de negocios aplicable. En el paso 11315, el sistema proporciona al usuario un despliegue de lista de los registros de SOW/entregables agregados por fase del proyecto. En el paso 11320 el usuario selecciona los registros de SOW/entregables. En el paso 11323, el sistema proporciona al usuario una página de ingreso de datos. En el paso 11325, el usuario selecciona una unidad de negocios de, por ejemplo, un menú desplegable. En el paso 11330, el usuario selecciona un centro de costos de, por ejemplo, un menú desplegable. En el paso 11335, el usuario selecciona opcionalmente un cliente aplicable de, por ejemplo, un menú desplegable. En el paso 11340 el usuario especifica un tipo de relación. En el paso 1135, el usuario especifica si se fuerza una restricción de dependencia. En el paso 11350, el usuario selecciona un propietario administrativo del evento de, por ejemplo, un menú desplegable. En el paso 11355, el usuario guarda los ajustes hechos previamente. En el paso 11360, el sistema corre una rutina de validación del evento de negocios. En el paso 11365, se hace una determinación en cuanto a si la validación fue positiva o no. En respuesta a la validación positiva en el paso 11365, la ejecución procede al paso 11370. En el paso 11370, ocurre la notificación sistemática a un administrador del evento de negocios aprobado. En el paso 11375, ocurre la disposición del administrador del evento. En respuesta a la aprobación en el paso 11375, la ejecución procede al paso 11380, en tal paso se almacenan las afiliaciones en una base de datos. En el paso 11385, ocurre la notificación sistemática del propietario del proyecto. Las asignaciones del flujo 11300 de proceso se almacenan en una tabla de base de datos, tal como, por ejemplo, la Tabla 143. Aquellas personas que tengan experiencia en la técnica apreciarán que el flujo 11300 de proceso puede ser bi-direccional, aun cuando esto no se representa explícitamente como tal.

A diferencia de los otros registros de datos principales (es decir, los registros principales de presupuestos, de activos, y de contratos), los eventos de negocios puede representar un elemento de contingencia; por lo tanto se emplea la asignación de dependencias, asi como la validación. La asignación de dependencias es análoga a la descrita previamente cuando se asigna la SOW a la SOW. A causa de la naturaleza indefinida de los eventos de negocios, virtualmente todo lo que pasa dentro de una entidad de negocios podria estar vinculado con los proyectos via la integración de los datos principales a la SOW. La FIG. 114 ilustra una página de red de interfaz de usuario ejemplificante que representa una sintesis de reporte de alto nivel para los grupos de proyectos y los registros principales de los proyectos. La configuración de afiliación de los registros facilita la optimización de las vistas y la disponibilidad del acceso de los usuarios de trabajo del proyecto a todos los detalles y los usuarios pertinentes. Aquellas personas que tengan experiencia en la técnica apreciarán que se podrian proporcionar otras vistas para representar las relaciones y los tiempos, una vista de salida de datos se representa para propósitos de simplicidad y facilidad de compresión.

La FIG. 115 ilustra un esquema de base de datos e soporte que podria ser usado en conexión con los flujos de proceso descritos arriba. Comienzo del Proyecto y Modelo de Reporte Resumido en riesgo de PCIP/S En seguida de la configuración de dependencias y la asignación de los registros de negocios a los registros de entregables/SOW de trabajo del proyecto, comenzarla finalmente el proyecto. Las actividades descritas previamente facilitan el envió corriente debajo de los comprobantes de trabajo de las actividades del proveedor. El proceso de emisión de comprobantes es un proceso por medio de cual el proveedor envia, a un usuario cliente o comprador configurado, una solicitud de aceptación del trabajo llevado a cabo. Esta solicitud puede estar o no asociada con un evento facturable La FIG. 116 ilustra un flujo 11600 de proceso de emisión de comprobantes que resulta en la identificación de los registros de negocios en riesgo y produce una salida de reporte en riesgo como se muestra de manera general en los pasos 9353-9356 de la FIG. 93. El flujo 11600 comienza en el paso 11605. En el paso 11605 comienza el trabajo del proyecto, en el paso 11610, el proveedor envia los comprobantes de aceptación del trabajo para el procesamiento del cliente o comprador. En el paso 11615, los datos de procesamiento de comprobantes indican una o más actividades que están excediendo la(s) fecha (s) de terminación anticipadas. En el paso 11620, el sistema notifica al propietario de la SOW del incumplimiento de la actividad-fecha. En el paso 11625, el usuario cliente o comprador ingresa el resumen de estado de actividad/SOW desde, por ejemplo, la página principal de proyectos, o utiliza, por ejemplo, un vinculo de notificaciones para proceder directamente a un registro de actividades. En el paso 11630, el usuario cliente o comprador accede al registro de actividades no cumplidas. En el paso 11635, el sistema proporciona al usuario una vista resumida de las transacciones con los comprobantes de las actividades. En el paso 11640, la interfaz de usuario proporciona al usuario un control activo para examinar las dependencias de los registros. En el paso 11645, el usuario activa el control activo. En el paso 11650, el sistema proporciona al usuario una vista resumida de las actividades configuradas para la SOW de la orden de compra, la asignación, la asignación de la fase del proyecto, la SOW de la orden de compra relacionada y la(s) asignaciones de los registros de datos principales. En el paso 11650, el usuario obtiene acceso a la imagen grande donde se pueden desplegar todas las relaciones configuradas. Dentro de esta vista se encuentra típicamente la información relacionada con la naturaleza de las relaciones pertinentes al registro de la SOW a la cual pertenece la actividad en cuestión. En el paso 11655, el sistema pide al usuario especificar una fecha de terminación de la SOW de la orden de compra anticipada. Sólo a nivel de la propiedad de la SOW del proyecto podria esto tomar lugar por un individuo que este involucrado en la ejecución actual del proyecto, en el paso 11660 el usuario especifica un Cambio de fecha y/o de condición. Si se hace una determinación de que se generará un impacto a la SOW de la orden de compra, el usuario puede entonces establecer una modificación de condiciones o de fechas. En casos extremos, el cambio de condición podria ser la falla completa o la cancelación, en tanto que en casos menos extremos, quizás sólo sea apropiado una fecha limite extendida. En el paso 11665, el sistema genera una vista del impacto de las dependencias del PCIP/S basada en las entradas del usuario en el paso 11660. Aunque no se representa explícitamente, podria existir la situación donde no resultará un impacto de la SOW de la orden de compra o sólo un simple problema administrativo en el cual el proveedor fue impuntual al enviar el comprobante, aun cuando la actividad estaba realmente en acatamiento de la fecha. En tal caso no habría cambios en la vista de impactos y la sesión podria terminar.

En el paso 11670, se hace una determinación en cuanto a si los registros en riesgo relacionados son poseídos por otros usuarios. En respuesta a una determinación positiva en el paso 11670, la ejecución procede al paso 11675, en el cual paso, el usuario cliente o comprador activa un resumen de registros en riesgo proporcionado por el sistema. En el paso 11680, el sistema produce una salida de reporte en riesgo. En el paso 11685, el usuario puede seleccionar si iniciar una sesión de comunicaciones en riesgo. Aunque no se indica explícitamente en el proceso 11600, aquellas personas que tengan experiencia en la técnica apreciarán que, en un escenario en el cual se causan impactos para sólo una SOW de la orden de compra relacionada (o las SOWs de órdenes de copra adicionales poseídas por el propietario del proyecto) , los cambios a ser realizados debido a los riesgos no impactarian ninguna dependencia o relación externa de los registros. En tan escenario, se podria emplear un procedimiento unilateral de modificación de registros por medio del cual se podrian actualizar todos los registros via las entradas controladas por el usuario. Sesión de Comunicaciones en riesgo del PCIP/S En el paso 11685, la entidad cliente o comprador está armada ahora con la estructura de información para entender los impactos potenciales a un huésped de los registros de proyecto y los registros principales relacionados. Aunque la posesión de esta información no impide que ocurran impactos negativos, esta proporciona visibilidad, y si se usa correctamente, proporciona oportunidades de planificación. Aquellas personas que tengan experiencia en la técnica apreciarán que la información se puede usar en una manera que proporcione a los usuarios la visibilidad y acceso a los datos necesarias para hacer decisiones de negocios informadas y al dia y mantener la información con respecto a la fuente de los riesgos. Las FIGs. 117-119 ilustran los flujos 11700-11900 de la sesión de comunicaciones de riesgos de la PCIP/S, incluyendo la configuración del paquete del propietario del registro de la SOW en riesgo y transmisión de ese paquete a los usuarios impactados y el procesamiento de los datos de registros de los usuarios impactados resultante con un conjunto de registros enviados de regreso al usuario emisor. Refiriéndonos ahora a la FIG. 117, el flujo 11700 del proceso comienza en el paso 11705, el cual paso procede desde el paso 11685 del flujo 11600 de proceso. En el paso 11705, el sistema lanza la sesión de comunicaciones en riesgo de PCIP/S. En el paso 11708, el usuario completa una forma inicial de la sesión de PCIP/S y guarda la forma. En el paso 11710, el sistema proporciona al usuario un despliegue de todos los registros impactados. Estos registros se pueden agregar por, por ejemplo, los registros de SOWs, presupuestos, activos, contratos, y eventos de negocios. En el paso 11715, el sistema pide al usuario confirmar la condición y/o la fecha limite de la SOW. En el paso 11720, el usuario edita o confirma las entradas de variables de la sesión. En el paso 11725, el sistema proporciona al usuario un despliegue de lista de los rubros de linea de las actividades de la orden de compra afiliados. En el paso 11730, el sistema pide al usuario seleccionar los rubros de linea en necesidad de modificación. En el paso 11735, el usuario selecciona los rubros de linea via, por ejemplo, una casilla de verificación.

En el paso 11740, el sistema proporciona una interfaz de usuario que permite la edición de las variables de los rubros de linea. En el paso 11745, el usuario modifica la condición o las variables permitidas relativas a los registros de actividades de los rubros de linea de la orden de compra seleccionados. En el paso 11750, el usuario guarda los ajustes hechos previamente. Tras la terminación de las ediciones a las actividades de trabajo del proyecto, el usuario puede salvar estos ajustes. Estas modificaciones de los registros de actividades se almacenan en una tabla de base de datos, tal como por ejemplo, la Tabla 149. En el paso 11755, se hace una determinación en cuanto a si las SOWs del proyecto dependiente impactadas son poseídas por el usuario. Si en el paso 11755 esto se determina negativamente, el sistema actualiza la vista resumida de los registros impactados e indica cuales registros, anteriores por la configuración de dependencias y la comparación de datos variables están en riesgo. Si la determinación es positiva en el paso 1175, la ejecución procede al paso 11760. En el paso 11760 el sistema despliega y pide al usuario configurar el registro de la SOW dependiente. En el paso 11765, el usuario edita el registro de la SOW impactada. En el paso 11770, el sistema proporciona al usuario un despliegue de lista de los rubros de la linea de actividades de la orden de compra. En el paso 11755, el sistema indica al usuario que seleccione los rubros de la linea en necesidad de modificación. Del paso 11775 la ejecución regresa al paso 11770. Una vez que la salida del reporte soporta una sesión de PCIP/S, el usuario establece la sesión de PCIP/S en respuesta a una indicación/control del sistema proporcionado con el reporte de resultados. Después de completar una forma de ingreso de información base, en el paso 11708, el sistema produce una vista de resultados del conjunto de registros completos afiliados con el registro en riesgo o la SOW fallida en el paso 11710. La terminación de la forma inicial y el guardado de la misma se almacenan en una tabla de base de datos, tal como, por ejemplo, la Tabla 144.

Entonces el sistema solicita al usuario que confirme las modificaciones de los datos utilizados inicialmente para generar el reporte de dependencias en riesgo. El usuario puede entonces confirmar o modificar las entradas originales en el paso 11720. Puesto que las actividades de trabajo del proyecto han sido vinculadas con los registros de la SOW, el sistema puede proporcionar al usuario un despliegue de lista de todos los registros de las actividades alimentados en la SOW. Debido a los cambios anticipados de la SOW, pueden necesitar modificación otros registros de actividades de trabajo del proyecto, asi como los registros de actividades causales. La selección de estos registros de las actividades tiene lugar en el paso 11735. Tras la selección, el sistema proporciona al usuario una interfaz de edición para cada registro individual seleccionado. La interfaz de edición puede variar con base en la actividad en si. Por ejemplo, los campos de condiciones y/o de datos pertinentes para la asignación del trabajo de los recursos humanos típicamente son diferentes a aquellos disponibles para procesar otras actividades, tales como, por ejemplo, una entrega de materiales. Estas modificaciones de registros se representan como el paso 11745.

La FIG. 118 ilustra un flujo 11800 del proceso de la sesión de comunicaciones de riesgo del PCIP/S descrita de manera general en el paso 9365 de la FIG. 93. El flujo 11800 de proceso comienza en el paso 11805, el cual paso procede del paso 11780. En el paso 11805, se hace una determinación en cuanto a si existen registros poseídos externamente en la vista resumida. Si la determinación en el paso 11805 es negativa, la ejecución procede al paso 11807, en el cual paso el flujo procede a la actualización en el paso 11807. Sin embargo, si la determinación en el paso 11805 es positiva, la ejecución procede al paso 11810. En el paso 11810, el sistema indica al usuario que configure un paquete de comunicaciones de PCIP/S por medio de cual se puedan hacer anotaciones para los conjuntos de registros del usuario (propietario) individual cuando se desee. Del paso 11810, la ejecución procede al paso 11815, en el cual paso el sistema proporciona al usuario un despliegue de lista de todos los registros impactados agregados por el propietario del negocio. En el paso 11820, el usuario selecciona los propietarios de negocios según lo desee, via, por ejemplo, una casilla de verificación proporcionada por la interfaz de usuario. En el paso 11825, el usuario proporciona anotaciones, según se desee, relativas a los registros seleccionados. En el paso 11830, el usuario guarda las entradas hechas previamente. En el paso 11835, la agregación del registro de PCIP/S se almacena en una base de datos con un estado de "guardada". En el paso 11840, se advierte a los usuarios con relación a si desean transmitir el paquete de comunicaciones de PCIP/S. si el usuario escoge trasmitir el paquete de comunicaciones, la ejecución procede al paso 11845, en el cual paso, el usuario activa un control de "transmitir el paquete PCIP/S del cliente". En el paso 11850, el sistema transmite el paquete a los usuarios configurados, con la notificación que se emite via correo electrónico y actualizaciones prematuras del sistema. La FIG. 119 ilustra el manejo del (de los) usuario (s) impactado (s) del paquete de información PCIP/S como se muestra de manera general en el paso 9370 de la FIG. 93. El flujo 11900 del proceso relativo al manejo por el (los) usuario (s) impactado (s) del paquete de información de PCIP/S comienza en el paso 11902, en el cual paso un usuario cliente o comprador impactado accede al compendio de información de PCIP/S. En el paso 11905, el sistema proporciona al usuario una vista general resumida de los detalles de la sesión de PCIP/S, que incluye la información tal como el emisor, la fecha de la transmisión, y la fecha de recepción. En el paso 11908, el sistema proporciona al usuario el control para acceder a los registros de negocios impactados. Aunque no se representa explícitamente, en el paso 1908 también se puede proporcionar una vista de otros registros impactados que pertenecen a otros usuarios, de acuerdo con las preferencias del usuario. En el paso 11910, el usuario activa el control. En respuesta a la activación del control en 11910, la ejecución procede al paso 11912, en el cual paso el sistema proporciona al usuario un despliegue de lista de los registros impactados y el estado de los registros. En el paso 11915, se hace una determinación en cuanto si el registro es dependiente tras el procesamiento corriente arriba de la SOW. Debido al potencial del conjunto de registros dependientes de cadenas múltiples, la disposición de un registro lejos corriente abajo es ilógica si el (los) registro (s) dependientes corriente arriba, pertinentes, no han sido procesados. Si se determina como positivo en el paso 11915, la ejecución procede al paso 11918. En el paso 11918, el sistema proporciona al usuario los detalles del procesamiento de dependencias y los propietarios de negocios aplicables. El registro se marca inactivo para el procesamiento con un estado de "esperando disposición de la SOW corriente arriba". Si en el paso 11915, la determinación es negativa, la ejecución procede al paso 11920. En el paso 11920, el usuario activa un control que activa el procesamiento del registro. En el paso 11922, se hace una determinación en cuanto si el registro es un registro de la SOW. Si se determina asi en el paso 11922, la ejecución procede al paso 11925, en el cual paso, el usuario procesa el registro como en los pasos 11725-11775. Del paso 11925, la ejecución procede al paso 11928, en el paso 11928, el usuario guarda los ajustes hechos previamente. En el paso 11930, los registros se actualizan en una base de datos. En el paso 11932, se notifica al (a los) propietarios de los registros de la SOW corriente abajo del procesamiento según sea necesario. En el paso 11935, el procesamiento de la SOW corriente abajo continua hasta su conclusión. En el paso 11938, se hace una determinación en cuanto si todos los registros de SOW y los registros de actividades de la orden de compra han sido procesados. Si se determina si en el paso 11938, la ejecución procede al paso 11940. En el paso 11940, el sistema notifica a los propietarios de los registros de datos principales de la terminación de procesamiento de la SOW. En el paso 11942, los propietarios de los registros principales procesan sus registros individuales. La edición de la condición y/o de los campos de datos variables también ocurre en el paso 11942. El paso 11942 también se ejecuta en respuesta a una determinación negativa en el paso 11922.

Del paso 11942, la ejecución procede al paso 11945, en el cual paso el usuario guarda los ajustes hechos previamente. En el paso 11948 los registros se actualizan en una base de datos. Los ajustes de la disposición de los registros de datos principales se almacenan en una tabla de base de datos, tal como, por ejemplo, la Tabla 152. Como es el caso con la Tabla 147, un campo de datos complejos ContorolableMDDatosElementos, con un tipo de datos de SQL Variantes, se usa como ambos medios de almacenamiento de procesamiento para estas modificaciones de los ajustes de los registros. Este campo es un tipo de entidad que almacena los ajustes en forma de metadatos. Este modelo de datos puede incluir cualquier tabla de base de datos individual que represente las tablas de almacenaje para las modificaciones de la configuración; sin embargo, una persona experimentada en la técnica reconocerá esta como un modo de procesamiento de base de datos alternativo. En el paso 11950, se hace una determinación en cuanto si todas las actualizaciones de los registros de datos principales han sido completadas. En respuesta a una determinación positiva en el paso 11950, la ejecución procede al paso 11952. Este envió produce notificaciones sistemáticas a los usuarios de la sesión y actualiza el* estado de la sesión PCIP/S en la base de datos para esperar la revisión. Aunque no se representa explícitamente, el sistema típicamente lleva a cabo validaciones durante todas las fases del procesamiento de datos. En el paso 11952, el sistema genera un envió del cliente o comprador de la PCIP/S de regreso al emisor de la sesión. En el paso 11955, el sistema envia notificaciones a los usuarios. En el paso 11960, el estado de la sesión se cambia a "esperando revisión". No todos los registros se modifican necesariamente y, en la extensión de las preferencias del cliente o comprador varias modalidades podrian operar en varios modos de configuración que, por ejemplo, no obligarían a la especificación de restricciones de dependencia obligatorias o, por ejemplo, facilitarían la modificación de las condiciones de los registros que se observarían ilógicas desde un punto de vista de las practicas más adecuadas. Aunque los conjuntos de registros completos típicamente se ponen a disposición para el procesamiento de datos, los registros impactados potencialmente no se ocultan típicamente para el procesamiento hasta que se han completado las permutaciones de disposición corriente arriba. Por lo tanto, la pre-configuración no sólo ajusta las dependencias sino también inicia y establece el flujo de trabajo dentro del proceso. Aunque no se representa explícitamente, la modificación de los registros típicamente es un proceso colaborativo cuando los registros en cuestión se relaciona directamente con las actividades del trabajo del proyecto de un proveedor. Un panel de transmisión de mensajes que facilita la comunicación bidireccional entre los clientes o compradores y los vendedores se puede configurar e implementar para la sesión PCIP/S. el panel de transmisión de mensajes podria ser usado por el cliente o comprador para comunicarse con el proveedor con relación a cualquier termino modificado de las actividades de trabajo del proyecto (por ejemplo, precios, fechas, cantidades, identidades de los recursos humanos) . La FIG. 120 es un esquema de base de datos ejemplificante que facilita la sesión de comunicaciones de PCIP/S. Sesión del Paquete de Acepción del Proveedor de PCIP/S Tras la recepción de las entradas de la sesión de comunicaciones en riesgo del PCIP/S del cliente o comprador, la siguiente fase del método global trata con la emisión y el procesamiento de las entradas adquiridas por cualquier proveedor impactado por las modificaciones del PCIP/S. La FIG. 121 ilustra un flujo 12100 del proceso de la sesión del paquete de aceptación del PCIP/S. El flujo 12100 de proceso comienza en el paso 12105, en el cual paso un usuario cliente o comprador se notifica del estado de "esperando revisión" del PCIP/S. En el paso 12110, el usuario accede al módulo de PCIP/S via, por ejemplo, el menú de navegación o un enlace del panel de instrumentos. En el paso 12115, el sistema proporciona al usuario una salida de reposte resumido que indica la condición especifica de los registros y las modificaciones de los datos variables. En el paso 12120, se hace una determinación sistemática con relación al impacto sobre cualquiera de los rubros de linea de la orden de compra del trabajo del proyecto. Dado que las modificaciones de los rubros de linea de la orden de compra son inherentes dentro del conjunto de registros, en el paso 12125, el sistema solicita la emisión de la probación de la orden de cambio del proveedor. En el paso 12130, se asume que el cliente o comprador no hace caso omiso de la necesidad de esta característica de procesamiento. Tras activar el control proporcionado, el sistema proporciona al usuario una salida de registro resumiendo los registros de la orden de compra impactados agregados por el proveedor en el paso 12135. El usuario se advierte sistemáticamente de la transmisión/emisión del paquete de aceptación del proveedor de la PCIP/S. presumiendo una acción positiva del usuario en el paso 12140, el sistema proporciona al usuario una página de red principal del paquete de aceptación del proveedor de la PCIP/S. El usuario proporciona las entradas básicas requeridas en el paso 12150 y, después que el usuario guarda los ajustes en el paso 12155, el sistema transmite el paquete de aceptación del PCIP/S del usuario a los proveedores aplicables en el paso 12160 y almacena los registros transaccionales en la base de datos en el paso 12165. Las tablas de base de datos ejemplificantes que podrian ser utilizadas durante esta fase del procesamiento se muestran en las Tablas 157-161. Tras la transmisión del paquete de aceptación del PCIP/S del proveedor, el sistema emite notificaciones a los usuarios proveedores configurados con relación a la actividad pendiente, en el paso 12170. En tal momento el usuario proveedor autorizado obtiene acceso a los registros de la sesión y utiliza los controles de navegación proporcionados para acceder a los registros de la sesión aplicables. La FIG. 122 ilustra un flujo 12200 del proceso de la sesión del paquete de aceptación del PCIP/S descrito de manera general en el paso 9375 de la FIG. 93. El flujo 12200 del proceso comienza en el paso 12202. En el paso 12202, un usuario proveedor autorizado accede al paquete de aceptación del PCIP/S via, por ejemplo, una navegación estándar o la activación de un control del tablero de instrumentos proporcionado. En el paso 12205, se despliega una página principal del paquete de aceptación del PCIP/S. En el paso 12208, el usuario activa un control de cambio de orden proporcionado, lo cual resulta en una salida de resumen sistemática de todas y cada una de las Órdenes de Compra afectadas, en el paso 12210. En el paso 12212, el usuario hace una selección de una orden de compra individual para el procesamiento, lo cual resulta en una salida de resumen sistemática de los Rubros de Linea de la Orden de Compra impactadas en el paso 12215. En el paso 12218, el usuario selecciona un rubro de linea modificado especifico para el procesamiento. En el paso 12220, el sistema proporciona al usuario los detalles del rubro de linea de la orden de compra e indica cuales campos de datos han sido impactados. Se puede al usuario que verifique los datos y/o el cambio de condición para el registro de la actividad. En el paso 12222, el usuario proveedor verifica la modificación del registro y procede al paso 12225, donde el sistema determina, con base en las configuraciones básicas, si las modificaciones de datos requieren una evaluación de tributación del proveedor. Si es afirmativo, el usuario proveedor proporciona los datos de la evaluación de tributación requeridos, que consiste de la provisión de las entradas de, por ejemplo, la autoridad tributaria, la cantidad del nivel tributario, el porcentaje del impuesto, etc.). En el paso 12230, el usuario guarda sus entradas. Este procesamiento de verificación y la evaluación de tributaciones continúa hasta el momento que todas las actividades de linea de la orden de compra y las órdenes de compra se procesan en el paso 12235 y no hay registros restantes sin procesar. En este punto se indica pide al usuario que transmita sus entradas de vuelta a la Entidad Cliente o comprador en el paso 12238. Presumiendo la selección lógica, el usuario proveedor transmite de vuelta a la entidad cliente o Comprador en el paso 12240. El sistema emite entonces las notificaciones al (a los) usuario (s) de la entidad cliente o comprador autorizado (s) , en el paso 12242, y actualiza la respuesta del paquete de aceptación del PCIP/S del proveedor al estado transmitido. Este flujo 12200 del proceso se repite para cada proveedor impactado aplicable pertinente al paquete de aceptación del PCIP/S especifico del proveedor. Tras el envió de todas las respuestas de los proveedores en el paso 12248, el estado del paquete de aceptación del PCIP/S del proveedor se actualiza a "completo" en el paso 12250, generando con ello notificaciones del sistema a los usuarios de las Entidades Clientes o Compradores en el paso 12252. La FIG. 123 ilustra un esquema de base de datos de soporte para el sistema de PCIP/S. Aquellas personas que tengan experiencia en la técnica apreciarán que la sección de la parte inferior derecha en el recuadro, de la FIG. 123 ilustra la porción primaria del esquema de las tablas discutidas arriba con relación a las FIGs. 121-122. Integración de Modificaciones de los Registros del PCIP/S Tras la recepción de todas las respuestas del paquete de aceptación de PCIP/S de los proveedores, la fase restante comprende la aprobación final del conjunto de registros y la integración de la información de PCIP/S. La FIG. 124 representa un flujo 12400 del proceso de la sesión de aprobación e integración de registros del PCIP/S ilustrado de manera general en los pasos 9380-9395. El flujo 12400 comienza en el paso 12404, en el cual paso un usuario cliente o comprador autorizado envia la respuesta del paquete de aceptación del PCIP/S del proveedor via, por ejemplo, la navegación estándar o el panel de control. En el paso 12408, el usuario despliega una página principal del paquete aceptación" del PCIP/S. En el paso 12412, el usuario activa un control de resumen de la orden de compra proporcionada. En el paso 12416 se proporciona al usuario un despliegue de lista de todas las órdenes de compra relacionadas. En el paso 12420, se requiere las aprobaciones de la orden de compra final. En respuesta a las aprobaciones requeridas en el paso 12420, la ejecución procede al paso 13424. En el paso 12424, se pide al usuario que transmita las solicitudes de aprobación del cambio de la orden de compra. En el paso 12428, el usuario activa el control de aprobaciones de cambio de la orden de compra proporcionada. En el paso 12432, el sistema transmite las solicitudes de aprobación de la orden de compra. En el paso 12436, se emiten notificaciones sistemáticas a los propietarios de los registros de órdenes de compra impactadas. En el paso 12440, se hace una determinación en cuanto a si se han hecho las aprobaciones de la orden de compra. En respuesta a una determinación positiva en el paso 12440, la ejecución procede al paso 12444. En el paso 12444, el sistema transmite las notificaciones de aprobación de la orden de compra a los propietarios de los registros principales relacionados con la declaración de trabajo. En el paso 12448, se hace una determinación en cuanto a si se han hecho las modificaciones de los registros de datos principales. En respuesta a una determinación positiva en el paso 12448, la ejecución procede al paso 12452, en el cual paso los usuarios actualizan los registros de datos principales. En el paso 12456, los usuarios guardan los nuevos ajustes de entrada. En el 12460, los usuarios aprueban los ajustes de datos. En respuesta a una determinación negativa en el paso 12448, la ejecución procede al paso 12460.

Del paso 12460, la ejecución procede al paso 12464. En el paso 12464, se hace una determinación en cuanto a si se han hecho todas las disposiciones de los registros de fechas principales. En respuesta a una determinación positiva en el paso 12464, la ejecución procede al?.paso 12468. En el paso 12468, se emiten notificaciones del sistema al propietario de la sesión de PCIP/S. En el paso 12472, el propietario de la sesión de PCIP/S, accede al conjunto de registros de PCIP/S aprobados via el control de navegación disponible. En el paso 12476, se pide a los usuarios que actualicen los registros del proceso. En el paso 12480, los registros se actualizan. En el paso 12484, el sistema corre una rutina de registro de fechas. En el paso 12488, las modificaciones de los registros se almacenan en una base de datos. En el paso 12492, se emiten notificaciones del sistema a los propietarios de los registros de PCIP/S impactados. Las aprobaciones de la orden de compra se negocian primero para asegurar que los registros de datos principales no obtienen las aprobaciones finales o se editan posiblemente con base en los datos de la orden de compra no aprobados. El procesamiento de datos principales es secundario a los datos transaccionales de trabajo del proyecto. La funcionalidad de edición de los datos principales se basa en el deseo de actualizar cualquier registro que podria ser impactado por los ajustes de los datos de las respuestas del paquete de aceptación del proveedor.

Tabla 114 Tabla 114A Tabla 115 (Diseño) Tabla 115 (Datos) Tabla 116 Tabla 118 Tabla 119 Tabla 120 Tabla 122 Tabla 123 Tabla 124 Tabla 128 Tabla 129 Tabla 130 Tabla 131 Tabla 134 Tabla 136 tblPreyectoFase (Vista de Diseño)? mrf ít- Columna Tipo de Datos Longitud ProFaseID únicoidentificador 16 SysProyectoCódigo únicoidentificador 16 ProFaseNombre varchar 50 ProFaseDesc varchar 1000 ProFaseNúmero numéricos FasePOInversión dinero ProjFaseLímiteFechaPlan fechahora ProFaseLímiteFechaTrans sqlvariante ProFaseEstado int CreaciónFecha fechahora UsuarioID int Tabla 137 Tabla 139 Diseño Tabla 139 (Datos) Tabla 145 (Diseño) Tabla 145 Datos Tabla 146 Diseño Tabla 146 Datos Tabla 148 (Datos) Tabla 149 ÍblPCgS ctivaadVarÍanteModelo (?Vis|t de) liseño) Columna Tipo de Datos Longitud PCIPSSesiónID únicoidentificador 16 PCIPSSOWImpactoLoteID únicoidentificador 16 POSOWAsignaciónLíneaRubroID únicoidentificador 16 ActividadTipoID int ControlablesDatosElementos sql_variante POCambio bitio VariableTipoMods sql_variante VariableAcciónMods sql variante UsuarioID únicoidentificador 16 ModificaciónFecha fechahora PCIPSActividadModID únicoidentificador 16 POCambio$ dinero Tabla 151 Diseño Tabla 154 (Diseño) Tabla 154 (Datos) Tabla 155 (Datos) Tabla 157 lkplPClPSAEftad€ Vistá deiDis ñl) Columna Tipo de Datos Longitud PCIPS APSesiónEstadoID int PCIPS APSesiónEstadoNombre varchar 50 Tabla 158 Tabla 159 Se proporciona un sistema habilitado por computadora, exhaustivo para producir datos analíticos relacionados con un sistema de administración de licitaciones de proyectos. Los datos transaccionales relacionados con la licitación y el proyecto se ingresan en el sistema computarizado a través de un proceso de licitación, requisición del proyecto y pagos en linea. Usando los datos transaccionales almacenados en el sistema, se puede generar virtualmente cualquier tipo de datos analíticos relacionados con uno sólo o varios proyectos llevados a cabo por uno o más proveedores o vendedores para uno o más clientes o compradores. Un método para producir datos analíticos en un sistema para administrar uno o más proyectos y una o más licitaciones y que tienen los datos transaccionales almacenados en el mismo, el cual incluye realizar un proceso de licitación en linea en el sistema, ingresar los datos de licitación en los campos de datos de una licitación durante el proceso de licitación en linea como parte de los datos transaccionales, recibir una solicitud por datos analíticos como una función de los datos transaccionales, y generar los datos analíticos usando los datos transaccionales con base en los datos transaccionales en respuesta a la solicitud. El paso de ingreso de datos también puede incluir ingresar los datos de la solicitud de licitación en los campos de datos por un cliente o comprador asociado con la licitación, e ingresar los datos de la respuesta de licitaciones en los campos de datos por un proveedor o vendedor asociado con la licitación. El método para producir los datos analíticos también puede incluir ingresar los parámetros de rastreo del proyecto, de un proyecto, en los campos de datos asociados con la licitación, como parte de los datos transaccionales, ingresar la información de los comprobantes en los campos de datos asociados con el proyecto, como parte de los datos transaccionales, e ingresar los datos de realización del proyecto en los campos de datos asociados con el proyecto, como parte de los datos transaccionales. Este método también puede incluir ingresar los datos de realización del proyecto por el cliente o comprador y el proveedor o vendedor en el sistema durante la realización del proyecto.

El método también puede incluir generar automáticamente los datos de realización del proyecto usando al menos los parámetros de rastreo del proyecto. Este método puede incluir además comparar los parámetros de rastreo del proyecto con la información de los comprobantes para determinar el estado del proyecto, e ingresar automáticamente el estado del proyecto como los datos de realización del proyecto en el sistema. El paso de generación puede incluir buscar los parámetros de rastreo para determinar un estado de tiempo del proyecto e ingresar automáticamente el estado de tiempo del proyecto como los datos de realización del proyecto en el sistema . El paso de ingresar los parámetros de rastreo del proyecto puede incluir ingresar la información de tributación que identifica los componentes sujetos a impuestos del proyecto y las cantidades de la tributación asociada con cada uno de los componentes sujetos a impuestos. El paso de recepción puede incluir recibir la solicitud por lo datos analíticos, la solicitud que incluye uno o más filtros, y filtrar los datos transaccionales para producir datos transaccionales filtrados usando uno o más filtros, los datos transaccionales filtrados que se usan para generar los datos analíticos.

El paso de recibir la solicitud que incluye el uno o más filtros también puede incluir recibir la solicitud por los datos analíticos como una función de uno o más tipos de los datos transaccionales, el uno o más filtros que filtran uno o más tipos de datos transaccionales. El uno o más filtros se pueden relacionar con al menos una de las propiedades del perfil del proveedor o vendedor, las propiedades del perfil del cliente o comprador, las propiedades del perfil del proyecto y las propiedades del perfil de las mercancías. El método para producir los datos analíticos también puede incluir proporcionar los datos analíticos en una vista de reporte del proyecto en una página de red. La vista de reporte del proyecto puede ser de un tipo de reporte del proyecto, el tipo de reporte del proyecto que es uno de un tipo financiero, el tipo de mercancías o del tipo de capital del proveedor o vendedor/humano. El paso de generación también puede incluir agregar los datos transaccionales asociados con varios proyectos para generar los datos analíticos. El paso de agregación puede incluir calcular datos estadísticos como una función de los datos transaccionales relacionados con cada proyecto, y agregar los datos estadísticos entre los varios proyectos. El paso de agregación también puede incluir agregar los datos transaccionales asociados con los varios proyectos llevados a cabo por los varios proveedores' o vendedores para generar los datos analíticos. Este paso de agregación también puede incluir agregar los datos transaccionales asociados con los varios clientes o compradores para generar los datos analíticos . El paso de generación puede incluir calcular los datos estadísticos usando los datos transaccionales asociados con los varios proyectos, para generar los datos analíticos. El paso de cálculo puede incluir calcular los datos estadísticos usando los datos transaccionales asociados con los varios clientes o compradores para generar los datos analíticos. El método para producir los datos analíticos también puede incluir almacenar los datos transaccionales relacionados con las licitaciones y los proyectos de un cliente o comprador, proveedor o vendedor o administrador en un sistema de base de datos del cliente o comprador, proveedor o vendedor o administrador respectivo, y transferir al menos una porción de los datos transaccionales almacenados en el sistema de base de datos a una base de datos central que almacena varios datos transaccionales de varios sistemas de base de datos, los datos analíticos que se generar de los varios datos transaccionales.

Un sistema computarizado para producir datos analíticos relacionados con un sistema para administrar uno o más proyectos y una o más licitaciones que incluye una interfaz basada en red para recibir una solicitud por los datos analíticos como una función de los datos transaccionales, un sistema de base de datos para albergar los datos transaccionales que incluyen el menos los datos de licitación, los datos de licitación que se ingresan en los campos de datos de una licitación almacenados en dicho sistema de base de datos via la interfaz basada en red, y un servidor conectado a dicha interfaz basada en red para recibir la solicitud y conectada a dicho sistema de base de datos para recuperar los datos transaccionales con base en la solicitud, dicho servidor que opera para generar los datos analíticos con base en los datos transaccionales recuperados en respuesta a la solicitud.

El sistema de base de datos puede almacenar los datos de la licitación que incluyen los datos de respuesta de la licitación ingresados en los campos de datos pir un cliente o comprador asociado con la licitación y los datos de respuesta de la licitación ingresados en los campos de datos por un proveedor o vendedor asociado con la licitación via dicha interfaz basada en red. El sistema de base de datos también puede almacenar los datos transaccionales que incluyen al menos los datos de la licitación, los parámetros de rastreo del proyecto de un proyecto ingresados en los campos de datos asociados con la licitación por un cliente o comprador y un proveedor o vendedor asociados con el proyecto, via dicha interfaz basada en red, la información de los comprobantes ingresada en los campos de datos asociados con la licitación y el proyecto, por el cliente o comprador y el proveedor o vendedor via dicha interfaz basada en red y los datos de realización del proyecto almacenados en los campos de datos asociados con la licitación y el proyecto, el sistema de base de datos también puede almacenar los parámetros de rastreo del proyecto que incluyen la información fiscal que identifica los componentes sujetos a impuestos del proyecto y las cantidades de las tributaciones asociadas con cada uno de los componentes sujetos a impuestos. El servidor también puede ser operable para recibir la solicitud que incluye uno o más filtros y filtrar los datos transaccionales para producir los datos transaccionales filtrados usando el uno o más filtros, los datos transaccionales filtrados que se usan para generar los datos analíticos. Estos uno o más filtros se pueden relacionar con al menos una de las propiedades del perfil del proveedor o vendedor, las propiedades del perfil del cliente o comprador, las propiedades del perfil del proyecto, y las propiedades le perfil de los artículos. El servidor puede ser operable para proporcionar los datos analíticos en una vista de reporte del proyecto en una página de red via dicha interfaz basada en red. La vista de reporte del proyecto puede ser de un tipo de reporte del proyecto, el tipo de reporte del proyecto que es uno de un tipo financiero, del tipo de proyecto o del tipo de capital del proveedor o vendedor/humano. El servidor puede ser operable para agregar los datos transaccionales asociados con los varios proyectos para generar los datos analíticos. El servidor puede ser operable para calcular los datos estadísticos como una función de los datos transaccionales relacionados con cada proyecto y agregar los datos estadísticos a través de varios proyectos. El servidor puede ser operable para agregar los datos transaccionales asociados con los varios proyectos llevados a cabo por varios proveedores o vendedores para general los datos analíticos. El servidor también puede ser operable para agregar los datos transaccionales asociados con varios clientes o compradores para generar los datos analíticos. El servidor también puede ser operable para calcular los datos estadísticos usando los datos transaccionales asociados con los varios proyectos para generar los datos estadísticos. El servidor también puede ser operable para calcular los datos estadísticos usando los datos transaccionales asociados con los varios clientes o compradores, para generar los datos analíticos .

El sistema de base de datos puede ser configurado para almacenar los datos transaccionales individuales relacionados con las licitaciones y los proyectos de un cliente o comprador, proveedor o vendedor o administrador, y puede incluir una base de datos central conectada a dicho sistema de base de datos para recibir al menos una porción de los datos transaccionales almacenados en el sistema de base de datos, dicha base de datos central que almacena varios datos transaccionales de varios sistemas de base de datos, los datos analíticos que se generan a partir de los varios datos transaccionales . En un medio legible por computadora que tiene las instrucciones ejecutables por computadora almacenadas en el mismo y que se relacionan con un sistema para administrar uno o más proyectos y una o mas licitaciones, estas instrucciones ejecutables por computadora pueden incluir medios para recibir una solicitud por datos analíticos como una función de los datos transaccionales, los datos transaccionales que incluyen al menos los datos de la licitación, los datos de la licitación que se ingresan en los campos de datos de una licitación almacenada en un sistema de base de datos durante un proceso de licitación en linea, un medio para acceder al sistema de base de datos para recuperar los datos transaccionales con base en la solicitud, y un medio para generar los datos analíticos con base en los datos transaccionales recuperados en respuesta a la solicitud. Un método para producir los datos analíticos en un sistema para administrar proyectos y almacenar los datos transaccionales en el mismo, que puede incluir ingresar los datos de realización del proyecto en los campos de datos asociados con cada uno de los proyectos como parte de los datos transaccionales, recibir una solicitud por los datos analíticos como una función de los datos transaccionales, y agregar los datos transaccionales con base en la solicitud para generar los datos de realización agregados del proyecto.

El método puede incluir ingresar los parámetros de rastreo del proyecto de los proyectos en los campos de datos asociados con los proyectos, como parte de los datos transaccionales, e ingresar en los campos de datos la información de los comprobantes asociados con los proyectos por al menos un cliente o comprador usuario al menos un proveedor o vendedor como parte de los datos transaccionales.

El método también puede incluir ingresar los datos de realización del proyecto por el al menos un cliente o comprador y el al menos un proveedor o vendedor en el sistema de administración de licitaciones de proyectos durante la realización del proyecto. El método también puede incluir generar automáticamente los datos de realización del proyecto usando al menos los parámetros de rastreo del proyecto. El paso de generación puede incluir comparar los parámetros de rastreo del proyecto de uno dado de los proyectos con la información de lo comprobantes del proyecto dado para determinar el estado del proyecto dado, e ingresar automáticamente el estado del proyecto dado como los datos de realización del proyecto en el sistema. El paso de generación también puede incluir buscar los parámetros de rastreo del proyecto para determinar la información del estado de tiempo de los proyectos, e ingresar automáticamente la información del estado de tiempo como los datos de realización del proyecto en el sistema. El paso de recepción puede incluir recibir a solicitud por los datos analíticos, la solicitud que incluye uno o más filtros, y filtrar los datos transaccionales para producir los datos transaccionales filtrados usando el uno o más filtros, los datos transaccionales filtrados que se usan para generar los datos analíticos. El paso de recibir la solicitud que indica el uno o más filtros puede incluir recibir la solicitud por los datos analíticos como una función de uno o más tipos de datos transaccionales, el uno o más filtros que filtran el uno o más tipos de datos transaccionales.

El uno o más filtros se pueden relacionar con al menos una de las propiedades del perfil del proveedor o vendedor, las propiedades del perfil del cliente o comprador, y las propiedades del perfil de proyecto y las propiedades del perfil de las mercancías. El método puede incluir proporcionar los datos analíticos en una vista de reporte del proyecto en una página de red. La vista de reporte del proyecto puede ser del tipo de reporte del proyecto, el tipo de reporte del proyecto que es una del tipo financiero, del tipo de proyectos, o del tipo de capital del proveedor o vendedor/humano. El paso de agregación también puede incluir calcular los datos estadísticos como una función de los datos transaccionales relacionados con cada uno de los proyectos, y agregar los datos estadísticos entre los proyectos. El paso de agregación también puede incluir agregar los datos transaccionales asociados con los proyectos llevados a cabo por varios proveedores o vendedores para generar los datos analíticos. El paso de agregación también puede incluir agregar los datos transaccionales asociados con varios clientes o compradores para generar los datos analíticos. El paso de almacenamiento puede incluir almacenar los datos transaccionales individuales relacionados con las licitaciones y los proyectos de un cliente o comprador, proveedor o vendedor o administrador, en un sistema de base de datos del cliente o comprador, el proveedor o vendedor o el administrador respectivo, y transferir al menos una porción de los datos transaccionales almacenados en el sistema de base de datos a una base de datos central que almacena varios datos transaccionales de varios sistemas de base de datos, los datos analíticos que se generan a partir de varios datos transaccionales . Un método para producir los datos analíticos en un sistema para administrar una o más licitaciones y uno o más proyectos y almacenar en el mismo los datos transaccionales, que incluye ingresar un componente de parámetros de rastreo del proyecto asociado con un proyecto en los campos de datos asociados con la licitación, como parte de los datos transaccionales, ingresar un componente de datos de realización del proyecto en los campos de datos asociados con el proyecto, como parte de los datos transaccionales. Recibir una solicitud por los datos analíticos como una función de uno o más de los componentes de los datos transaccionales y generar los datos analíticos con base en los datos transaccionales en respuesta a la solicitud. Un método para producir los datos analíticos en un sistema para administrar varias licitaciones y varios proyectos comisionados por varios clientes o compradores y que almacena en el mismo los datos transaccionales relacionados con los varios proyectos, que incluye recibir una solicitud por datos analíticos de la industria como una función de los datos transaccionales, los datos transaccionales que incluyen al menos lo datos de realización del proyecto que indican la realización de los proyectos por uno o más proveedores o vendedores asociados con los proyectos, acceder a los datos transaccionales con base en la solicitud, y generar los datos analíticos con base en los datos transaccionales accedidos en respuesta a la solicitud. Este método puede incluir almacenar los datos transaccionales individuales relacionados con las licitaciones y los proyectos de un cliente o comprador, proveedor o vendedor o administrador en un sistema de base de datos del cliente o comprador, proveedor o vendedor o administrador respectivo, y transferir al menos una porción de los datos transaccionales almacenados en el sistema de base de datos a una base de datos central que almacena varios datos transaccionales de varios sistemas de base de datos, los datos analíticos que se generan a partir de varios datos transaccionales . Un método para producir información de la cantidad de impuestos en un sistema para administrar proyectos y que almacena los datos transaccionales en el mismo, que incluye ingresar la información tributaria en los campos de datos asociados con una proyecto como parte de los datos transaccionales, ingresar la información de los comprobantes en los campos de datos asociados con el proyecto como parte de los datos transaccionales, y generar una cantidad de tributaciones asociada con la información de los comprobantes con base en la información tributaria. Este método puede incluir proporcionar la cantidad de las tributaciones a un cliente o comprador y un proveedor o vendedor asociados con el proyecto, para la aprobación de la misma. Aquellas personas experimentadas en la técnica apreciarán que, además de los sistemas y las metodologías descritas aqui, la presente invención se dirige a las base de datos computarizadas, aplicaciones informáticas, programas, protocolos, rutinas e instrucciones (colectivamente "instrucciones de programación de computadora") que pueden ser usados para implementar las caracteristicas y funciones descritas arriba. Las instrucciones de programación de computadora preferiblemente se almacenan dentro de una memoria, y pueden ser recibidas o transmitidas via una interfaz de comunicaciones. Como se reconocerá por aquellas personas experimentadas en la técnica, los conceptos innovadores descritos en la presente solicitud se pueden modificar y variar a través de un amplio rango de aplicaciones. Por consiguiente, el ámbito de la materia objeto patentado no estarla limitado a ninguna de las enseñanzas ejemplificantes discutidas, sino más bien se define en las siguientes reivindicaciones.

Claims

REIVINDICACIONES 1. Un método de gestión administrativa caracterizado porque, comprende: recibir, de un cliente o comprador, las configuraciones de administración del proyecto; almacenar los datos transaccionales de trabajo del proyecto con relación al trabajo del proyecto a ser llevado a cabo para el cliente o comprador por un proveedor; recibir, del cliente o comprador, la configuración de los registros de la declaración de trabajo (SOW) ; procesar el cambio del conjunto de registros de cambios en el plan/alcance del proyecto del cliente o comprador; procesar el conjunto de registros del cambio en el plan/alcance del proyecto del proveedor; y crear un conjunto integrado de registros de cambios en el plan/alcance del proyecto usando el conjunto de registros del cliente o comprador y el conjunto de registros del proveedor.
2. El método de la reivindicación 1, caracterizado porque, las configuraciones administrativas del proyecto comprenden: un conjunto de registros del proyecto; un conjunto de registros de presupuestos; un conjunto de registros de activos; un registro principal de contratos; un registro de eventos de negocios no proyectados; y en donde al menos uno del conjunto de registros del proyecto, el conjunto de registros de presupuestos, y el conjunto de registros de activos comprende una pluralidad de registros por niveles.
3. El método de la reivindicación 1, caracterizado porque, el paso de almacenar los datos transaccionales de trabajo del proyecto comprende; proporcionar una licitación de RFx expedida por el comprador al proveedor; proporcionar una respuesta del proveedor a la licitación RFx; recibir una aceptación del cliente o comprador de la respuesta del proveedor a la licitación RFx; generar al menos una orden de compra basada en los elementos de la respuesta a la licitación de RFx del proveedor, aceptada por el cliente o comprador; proporcionar comprobantes de aceptación del trabajo del proveedor al cliente o comprador en respuesta a los servicios de trabajo del proyecto proporcionados; y recibir la disposición del cliente o comprador de los comprobantes de aceptación de trabajo del proveedor; y llevar a cabo el procesamiento financiero de los comprobantes de aceptación del trabajo del proveedor aprobados .
4. El método de la reivindicación 3, caracterizado porque, comprende además utilizar los rubros de la licitación RFx para establecer las actividades del trabajo del proyecto.
5. El método de la reivindicación 4, caracterizado porque, el paso de utilizar los rubros de la licitación RFx para establecer las actividades de trabajo del proyecto comprende; utilizar los rubros de la licitación RFx adaptados para adquirir y procesar los datos relativos a al menos uno de los siguientes tipos de objetos de datos transaccionales: asignaciones de recursos humanos; tipos de tareas de los recursos humanos; tipos de tasas de los recursos humanos; tipos de gastos de los recursos humanos; materiales; gastos misceláneos del proyecto; entregables de unidades/piezas basadas en el trabajo; entregables de precios fijos; y utilizar al menos un tipo de rubro de la licitación RFx entregable .
6. El método de la reivindicación 3, caracterizado porque, la respuesta del proveedor a la licitación RFx del cliente o comprador comprende: los datos aplicables a los rubros de la licitación RFx; y los datos aplicables a al menos una actividad de trabajo del proyecto entregable.
7. El método de la reivindicación 3, caracterizado porque, la aceptación del cliente o comprador de la respuesta de licitación de RFx del proveedor comprende; la aceptación de los elementos de la respuesta de la licitación RFx del proveedor aplicables a las actividades de trabajo del proyecto del cliente o comprador; y la aceptación de los elementos de respuesta de la licitación RFx del proveedor que comprende al menos una actividad de trabajo del proyecto entregable.
8. El método de la reivindicación 3, caracterizado porque, el paso de generar al menos una orden de compra comprende integrar los datos de los elementos de la respuesta aceptada de licitación RFx del proveedor en una orden de compra .
9. El método de la reivindicación 8, caracterizado porque, el paso de integrar los datos de los elementos de la respuesta aceptada de la licitación RFx en la orden de compra comprende : crear una orden de compra; establecer las lineas de la orden de compra; y afiliar los datos de los elementos de respuesta de la licitación RFx con las linea de la orden de compra para establecer los datos transaccionales del trabajo del proyecto.
10. El método de la reivindicación 1, caracterizado porque, la configuración de los registros de SOW del proyecto comprende : designar los registros de entregables de la orden de compra como registros de SOW; configuración de los rubros de linea de la orden de compra, los rubros de linea de la orden de compra que comprenden las actividades de trabajo del proyecto no entregables afiliadas con las actividades de trabajo de producción de entregables; configuración de las fases del proyecte- configuración de las dependencias de los registros de SOW; y configuración de las afiliaciones de los datos principales de los registros de SOW.
11. El método de la reivindicación 1 caracterizado porque, el paso de procesar el conjunto de registros de cambios en el plan/alcance del proyecto del cliente o comprador comprende; generar una salida de afiliación de dependencias de la SOW del proyecto y de los registros principales; en donde el proyecto se representa en términos de la conectividad por toda la empresa; transmitir un paquete de comunicaciones en riesgo del proyecto; recibir una respuesta del paquete de comunicaciones en riesgo del proyecto; y procesar la respuesta del paquete de comunicaciones en riesgo del proyecto.
12. El método de la reivindicación 1, caracterizado porque, el paso de procesar el conjunto de registros de cambios en el plan/alcance del proyecto del proveedor comprende; crear un paquete de aceptación en el cambio del plan/alcance del proyecto; transmitir el paquete de aceptación en el cambio del plan/alcance del proyecto; procesar el paquete de aceptación en el cambio del plan/alcance del proyecto transmitido; y recibir la terminación del paquete de aceptación en el plan/alcance del proyecto transmitido.
13. El método de la reivindicación 1, caracterizado porque, el paso de crear el conjunto de registros de cambios en el plan/alcance del proyecto integrado comprende; recibir al menos una orden de cambio, del cambio en el plan/alcance del proyecto; procesar la al menos una orden de cambio, del cambio en el plan/alcance del proyecto; procesar al menos un registro de datos principales en respuesta a la probación de la al menos una orden de cambio, del cambio en el plan/alcance del proyecto; y actualizar al menos un registro de datos procesado.
14. El método de creación del conjunto de registros administrativos de la cartera de trabajo del proyecto, el método, caracterizado porque, comprende: crear los conjuntos de registros de la cartera de proyectos; y crear los conjuntos de registros de la cartera de presupuestos; y crear los registros principales de contratos; y crear los registros de eventos de negocios no proyectados .
15. El método de la reivindicación 14, caracterizado porque, el paso de crear los conjuntos de registros de la cartera de proyectos comprende: crear un registro del grupo de proyectos adaptado para almacenar los datos de atributos del gruido de proyectos, de la organización del cliente o comprador, y de responsabilidad de propiedad de negocios; crear al menos un registro principal de proyecto adaptado para almacenar los datos de los proyectos del cliente o comprador; almacenar una asociación entre el registro del grupo de proyectos y el al menos un registro principal de proyectos; almacenar las relaciones de dependencia aplicables entre el al menos un registro principal de proyectos afiliado dentro de un grupo de proyectos; y almacenar los datos organizaciones del cliente o comprador y de propiedad de negocios por defecto, aplicables al principal del proyecto como una restricción de los datos del grupo de proyectos por defecto.
16. El método de la reivindicación 14, caracterizado porque, crear los conjuntos de registros de la cartera de presupuestos comprende además: crear un registro del grupo de presupuestos adaptado para almacenar los datos de organización del cliente o comprador, responsabilidad de propiedad del negocio, y financieros; crear al menos un registro principal de presupuestos adaptado para almacenar los datos de presupuestos del cliente o comprador; almacenar una asociación entre el registro del grupo de presupuestos y el al menos un registro principal de presupuestos; y almacenar los datos organizacionales, de participación de negocios, y financieros del cliente o comprador, aplicables al registro principal de presupuestos como una restricción de los datos del grupo de presupuestos por defecto.
17. El método de la reivindicación 14, caracterizado porque, crear los conjuntos de registros de la cartera de activos comprende además: crear un registro del grupo de activos adaptado para almacenar los datos del organización, participación de negocios, y datos financieros del cliente o comprador; crear al menos un registro principal de activos adaptado para almacenar los datos de activos del cliente o comprador; almacenar una asociación entre el registro del gruido de activos y el al menos un registro principal de activos; y almacenar los datos de organización, de participación de negocios, y financieros por defecto del cliente o comprador, aplicables a los datos principales de activos como una restricción del grupo de activos.
18. El método de la reivindicación 14, caracterizado porque, la creación de los registros principales de contratos comprenden además: crear un registro principal de contratos adaptado para almacenar los datos de organización, participación de negocios, financieros y de contratos del cliente o comprador, aplicables a un contrato del cliente o comprador.
19. El método de la reivindicación 14, caracterizado porque, comprende crear al menos un registro de eventos de negocios adaptado para almacenar los datos de organización, de participación de negocios, y de eventos de negocios del cliente o comprador.
20. El método de la reivindicación 15, caracterizado porque, el paso de crear al menos un registro principal de proyectos comprende al menos uno de: afiliar cada uno del al menos un registro principal de proyectos con al menos un registro principal de presupuestos; afiliar cada uno del al menos un registro principal de proyectos con al menos un registro principal de activos; afiliar cada uno del al menos un registro principal del proyecto con al menos un registro principal de contratos; y afiliar cada uno del al menos un registro principal de proyectos con al menos un registro principal de eventos de negocios.
21. Un método para configurar los registros de entregables de SOW del proyecto, el método, caracterizado porque comprende: asociar los rubros de linea de la orden de compra de actividades de trabajo el proyecto con al menos un registro del tipo de entregables de linea de la orden de compra; especificar los datos de atributos relativos al registro de entregables de la orden de compra; crear al menos un registro de faseamiento de trabajo el proyecto; especificar los datos de atributos relativos a al menos un registro de faseamiento del proyecto; configurar las dependencias de los registros de entregables de la orden de compra; t configurar las afiliaciones de los registros de entregables de la orden compra con los registros principales.
22. El método de la reivindicación 21, caracterizado porque, el paso de crear al menos un registro de faseamiento del trabajo del proyecto comprende afiliar el al menos un registro de faseamiento del proyecto con un registro principal del proyecto.
23. El método de la reivindicación 21, caracterizado porque, el paso de crear al menos un registro de faseamiento del proyecto comprende afiliar los registros de entregables de la orden de compra con el al menos un registro de faseamiento del proyecto.
24. El método de la reivindicación 21, caracterizado porque, el paso de configurar las dependencias de los registros de entregables de la orden de compra comprende establecer relaciones entre los registros de entregables de la orden de compra dentro de un proyecto.
25. El método de la reivindicación 24, caracterizado porque, el paso de establecer las relaciones entre los registros de entregables de la orden de compra dentro del proyecto comprende: especificar un tipo relación de dependencia entre los registros de entregables relacionados de la orden de compra; y especificar si un estado de terminación del registro de entregable dependiente de la orden de compra se restringe por un estado de terminación de un registro de entregable relacionado de la orden de compra.
26. El método de la reivindicación 21, caracterizado porque, el paso de configurar las dependencias de los registros de entregables de la orden de compra comprende establecer las relaciones entre los registros de entregables de la orden de compra en varios proyectos dentro de un grupo de proyectos.
27. El método de la reivindicación 26, caracterizado porque, el paso de establecer las relaciones entre los registros de entregables de la orden de compra dentro de varios proyectos comprende: especificar una tipo de relación de dependencia entre los registros de entregables de órdenes de compra relacionadas; y especificar si un estado de terminación del registro de entregables de la orden de compra dependientes se restringe por un estado de terminación del registro de entregables de la orden de compra relacionada.
28. El método de la reivindicación 21, caracterizado porque, el paso de configurar las afiliaciones de los registros de entregables de la orden de compra con los registros de datos principales comprende al menos uno de: afiliar los registros de entregables de la orden de copra con al menos un registro principal de presupuestos asignado a un registro principal del proyecto; y afiliar los registros de entregables de la orden de compra que contienen al menos un registro de material, con al menos un registro principal de activos asignado al registro principal del proyecto; y afiliar los registros de entregables de la orden de compra con al menos un registro principal de contratos asignado al registro principal del proyecto; y afiliar los registros de entregables de la orden de compra con al menos un registro principal de eventos de negocios asignado al registro principal de proyectos.
29. El método de la reivindicación 28, caracterizado porque, el paso de configurar las afiliaciones de registros de entregables de la orden de compra con los registros de datos principales comprende: especificar los datos de atributos para las afiliaciones de registros de entregables de la orden de compra a los registros de datos principales; y especificar el personal del cliente o comprador que tienen responsabilidad por las afiliaciones de registros de entregables de la orden de compra a los registros de datos principales.
30. El método de la reivindicación 29, caracterizado porque, comprende además: almacenar las afiliaciones de registros de entregables de la orden de compra a los registros de datos principales configuradas y las dependencias de registros de la SOW en una base de datos; notificar al personal del cliente o comprador responsable por los registros de entregables de la orden de compra y los registros de datos principales de las afiliaciones de registros de entregables de la orden de compra almacenados en la base de datos; y proporcionar acceso al personal del cliente o comprador notificado a sus detalles de afiliación de registros respectivo.
31. Un método para evaluar un cambio en el plan/alcance del proyecto, el método, caracterizado porque, comprende: llevar a cabo un análisis de dependencias de entregables del proyecto y afiliación de registros principales en respuesta a la disposición del cliente o comprador de los comprobantes de aceptación del trabajo del proyecto enviados por el proveedor; identificar los registros de SOW de entregables de la orden de compra que están fuera de cumplimiento con relación a una fecha de terminación programada; recibir la selección de al menos un registro de entregables fuera de cumplimiento; generar una sesión de comunicaciones en riesgo del proyecto; transmitir un paquete de comunicaciones en riesgo del proyecto; recibir una respuesta del paquete de comunicaciones en riesgo del proyecto; y procesar la respuesta del paquete de comunicaciones en riesgo del proyecto.
32. El método de la reivindicación 31, caracterizado porque, comprende además, en respuesta a la selección del al menos un registro de entregables fuera de cumplimiento: generar una transmisión de entregables en riesgo del proyecto que incluye los registros de entregables impactados potencialmente y los registros de datos afiliados con el registro de entregables fuera de cumplimiento seleccionado; identificar los registros de entregables en riesgo afiliados con el registro de entregables fuera de cumplimiento seleccionado; y recibir la modificación de su estado o fecha de terminación de un registro de entregables en riesgo identificado .
33. El método de la reivindicación 32, caracterizado porque, comprende además, en respuesta a la modificación: generar un modelo actualizado de los registros de datos principales y los registros de entregables impactados por el registro de entregables en riesgo; e identificar al personal del cliente o comprador responsable por los registros de entregables impactados por el registro de entregables en riesgo; e iniciar una sesión de comunicaciones en riesgo.
34. El método de la reivindicación 31, caracterizado porque, el peso de generar la sesión de comunicaciones en riesgo comprende: crear un conjunto de registros de la sesión de comunicaciones en riesgo; proporcionar acceso, por el propietario de la sesión de comunicaciones en riesgo del proyecto, a los rubros de linea de actividades de trabajo del proyecto de la orden de compras afiliados con el al menos un registro de entregables fuera de cumplimiento; y almacenar los ajustes, en respuesta a las modificaciones de rubros de linea de actividades de trabajo del proyecto de la orden de compra.
35. El método de la reivindicación 34, caracterizado porque, comprende además, en respuesta al paso de almacenamiento, presentar al propietario de la sesión de comunicaciones en riesgo del proyecto, los registros de negocios impactados agregados por la responsabilidad del personal del cliente o comprador, en donde la interfaz del usuario se adapta para emitir una transmisión al personal afectado.
36. El método de la reivindicación 31, caracterizado porque, el paso de procesar la respuesta del paquete de comunicaciones en riesgo del proyecto comprende: desplegar las dependencias corriente arriba o corriente debajo de los registros de entregables; desplegar el estado de los registros de entregables afiliados; permitir la modificación de los registros de entregables; y permitir la modificación de los registros de datos principales .
37. El método de la reivindicación 36, caracterizado porque, comprende además almacenar las modificaciones de registros de entregables.
38. El método de la reivindicación 37, caracterizado porque, comprende además, en respuesta al paso de almacenar las modificaciones de registros de entregables: validar las fechas de terminación de entregables con relación a los registros de entregables dependientes; proporcionar al personal del cliente o comprador una notificación de validación exitosa, en respuesta a no haber conflictos de las fechas de terminación de los registros de entregables afiliados; y actualizar un código de estado de la respuesta del paquete de comunicaciones en riesgo del proyecto a completo.
39. El método de la reivindicación 37, caracterizado porque, comprende además, en respuesta al paso de validar las fechas de terminación de entregables: proporcionar una notificación de validación no exitosa en respuesta a al menos un conflicto de las fechas de terminación de los registros de entregables afiliados; actualizar un código de estado de la respuesta del paquete de comunicaciones en riesgo del proyecto a "en conflicto"; y desplegar los detalles específicos de los registros de entregables afiliados en conflicto; modificar los detalles de los registros en conflicto, en respuesta a la entrada del usuario.
40. El método de la reivindicación 38, caracterizado porque, comprende además, en respuesta a la actualización del código de estado de la respuesta del paquete de comunicaciones en riesgo del proyecto a completa, informar el envió de las actualizaciones de los registros de la respuesta del paquete de comunicaciones en riesgo del proyecto a un propietario de la sesión de comunicaciones en riesgo del proyecto.
41. El método de la reivindicación 40, caracterizado porque, comprende además, en respuesta al envió de las actualizaciones de los registros del paquete de comunicaciones en riesgo del proyecto al propietario de la sesión de comunicaciones en riesgo: validar el estado de terminación de todas las respuestas del paquete de comunicaciones en riesgo del proyecto; determinar si las actualizaciones del registro de comunicaciones incluye los cambios a la orden de compra; y notificar a los propietarios de los registros de entregables corriente abajo, de las respuestas de la comunicación en riesgo del proyecto.
42. El método de la reivindicación 41, caracterizado porque, comprende además, en respuesta al paso de validar el estado de terminación para todas las respuestas del paquete de comunicaciones, ajustar un código de estado de la sesión de comunicaciones en riesgo del proyecto a "esperando revisión".
43. El método de la reivindicación 42, caracterizado porque, comprende además, en respuesta a no haber modificaciones de los rubros de linea de la orden de compra dentro de las respuestas del paquete de comunicaciones: proporcionar al propietario de la sesión de comunicaciones en riesgo del proyecto una interfaz de usuario adaptada por medio de la cual se pueden integrar las modificaciones de los registros de entregables y los registros de datos principales con los datos activos de la empresa; y actualizar los datos activos de la empresa con las modificaciones de los registros de entregables y de registros de datos principales en respuesta a la acción del propietario de la sesión de comunicaciones en riesgo del proyecto.
44. Un método para procesar un cambio en el plan/alcance del proyecto, el método, caracterizado porque, comprende: crear un paquete de aceptación del cambio en el plan/alcance del proyecto; transmitir el paquete de aceptación del cambio en el plan/ámbito del proyecto; procesar el paquete de aceptación del cambio en el plan/ámbito del proyecto transmitido hasta su terminación; y proporcionar el paquete de aceptación del cambio en el plan/alcance del proyecto transmitido completado.
45. El método de la reivindicación 44, caracterizado porque, el paso de crear un paquete de aceptación del cambio en el plan/alcance del proyecto comprende: crear un registro del paquete de aceptación del cambio en el plan/alcance del proyecto adaptado para almacenar la información de atributos; y asignar al cambio en el registro del paquete de aceptación del cambio en el plan/alcance un código de estado de abierto.
46. El método de la reivindicación 44, caracterizado porque, el paso de transmitir el paquete de aceptación del cambio en el plan/alcance del proyecto comprende: presentar los registros de la orden de compra impactados por la responsabilidad del proveedor; y presentar una- interfaz de usuario adaptada para transmitir el paquete de aceptación.
47. El método de la reivindicación 44, caracterizado porque, el paso de procesar el paquete de aceptación del cambio en el plan/alcance del proyecto transmitido comprende: notificar al personal del proveedor del procesamiento de datos pendiente del paquete de aceptación del cambio en el plan/alcance del proyecto; y en donde el procesamiento de datos por el personal dado del proveedor se limita a aquel conjunto de registros de rubros de linea de la orden de compra impactada individual del personal del proveedor.
48. El método de la reivindicación 44, caracterizado porque, el paso de procesar el paquete de aceptación del cambio en el plan/alcance del proyecto hasta su terminación en respuesta a la recepción de la transmisión, comprende: proporcionar al personal del proveedor los registros de rubros de linea de la orden de compra impactados; recibir la aprobación de los registros de rubros de linea de la orden de compra impactados del personal del proveedor; y almacenar una transacción de aprobación en respuesta a la aprobación de los registros.
49. El método de la reivindicación 48, caracterizado porque, el paso de procesar el paquete de aceptación del cambio en el plan/alcance del proyecto transmitido, a su terminación, comprende: determinar si al menos un registro de rubros de linea de la orden de compra impactada requiere evaluación de impuestos del proveedor; almacenar los datos de la evaluación de impuestos en respuesta a una determinación de que al menos un registro de rubros de linea de la orden de compra requiere la evaluación de impuestos del proveedor; y actualizar un código de estado del paquete de aceptación del cambio en el plan/alcance del proyecto para indicar la compleción en respuesta a una determinación de que los datos de evaluación de impuestos para todos los registros de rubros de la orden de compra han sido almacenados.
50. El método de la reivindicación 44, caracterizado porque, el paso de proporcionar el paquete de aceptación del cambio en el plan/alcance del proyecto transmitido, completado, comprende: notificar a un propietario de la sesión del cambio en el plan/alcance del proyecto sobre la respuesta del paquete de cambio en el plan/alcance del proyecto; notificar a los propietarios de los registros de personal de los clientes o compradores relevantes de los registros de rubros de linea de la orden de compra de la respuesta del paquete de aceptación del cambio en el plan/alcance del proyecto; y validar el estado de la respuesta del paquete de aceptación del cambio en el plan/alcance del proyecto.
51. El método de la reivindicación 50, caracterizado porque, el paso de validación comprende: notificar al propietario de la sesión de cambio en el plan/alcance del proyecto sobre la terminación de la respuesta del paquete de aceptación del cambio en el plan/alcance del proyecto; modificar el estado del paquete de aceptación del cambio en el plan/alcance del proyecto para indicar su aprobación.
52. Un método para crear un conjunto de registros integrados de cambios en el plan/alcance del proyecto, el método, caracterizado porque, comprende: crear al menos una orden de cambio en el plan/alcance del proyecto; procesar la al menos una orden de cambio en el plan/alcance del proyecto; procesar al manos un registro de datos principal en respuesta a la aprobación de la al menos una orden de cambio en el plan/alcance del proyecto; actualizar al menos un registro de datos principales procesados; y activar todas las modificaciones de registros de cambios en el plan/alcance del proyecto.
53. El método de la reivindicación 52, caracterizado porque, el paso de crear al menos una orden de cambio en el plan/alcance del proyecto comprende: agregar los registros modificados de la orden de compra del trabajo del proyecto; e iniciar las solicitudes de aprobación de la orden de cambio; y transmitir las respuestas de aprobación de la orden de compra.
54. El método de la reivindicación 53, caracterizado porque, el paso de transmitir las solicitudes de aprobación de la orden de cambio comprende: notificar al personal del cliente o comprador propietario del registro de la orden de compra, sobre las solicitudes de aprobación de la orden de cambio pendiente; en respuesta a la entrada del personal responsable del cliente o comprador propietario del registro de la orden de compra, procesar la solicitud de aprobación de la orden de cambio; y en donde, para un personal dado del cliente o comprador, el procesamiento de aprobación de la orden de cambio del personal del cliente o comprador se limita a los registros de la orden de compra por los cuales ese personal del cliente o comprador es el propietario responsable de los registros.
55. El método de la reivindicación 54, caracterizado porque, el paso de procesar la solicitud de aprobación de la orden de cambio comprende: modificar el estado de la solicitud de aprobación de la orden de cambio para indicar la aprobación; almacenar una transacción de la solicitud de aprobación de la orden de cambio en una base de datos; y notificar a un propietario de la sesión de cambio en el plan/alcance del proyecto de un cliente o comprador, de la aprobación de la orden de cambio.
56. El método de la reivindicación 52, caracterizado porque, el paso de procesar al menos un registro de datos principal comprende; proporcionar, a un propietario de la sesión del cambio en el plan/alcance del proyecto del cliente o comprador, los registros de datos principales del proyecto afiliado con una orden de cambio aprobada, afiliada, y agregada por el propietario del registro del personal aplicable del cliente o comprador; y emitir notificaciones al personal del cliente o comprador responsable de los registros de datos principales del proyecto afiliados con la orden de cambio aprobada, de que los registros de datos principales del proyecto, afiliados, están disponibles para el procesamiento adicional.
57. El método de la reivindicación 56, caracterizado porque, el paso de emitir las notificaciones al personal del cliente o comprador responsable de los registros de datos principales afiliados con una orden de cambio aprobada comprende : proporcionar • al personal del cliente o comprador una interfaz de usuario adaptada para permitir que se hagan las modificaciones a los registros de datos principales; y almacenar los ajustes de entrada en respuesta a la modificación de los registros.
58. El método de la reivindicación 57, caracterizado porque, comprende además, en respuesta al paso de almacenar los ajustes de entrada en respuesta a la modificación de los registros : notificar al propietario de la sesión del cliente o comprador de los ajustes de entrada de los registros de datos principales guardados; determinar si se han almacenado todos los registros de datos principales afiliados con todas las órdenes de cambio; modificar el estado de la sesión de cambios en el plan/alcance del proyecto para indicar que aun necesita llevarse a cabo la integración, en respuesta a todos los registros de datos principales afiliados con todas las órdenes de cambio que son almacenadas.
59. El método de la reivindicación 52, caracterizado porque, el paso de la activación comprende: llevar a cabo un procedimiento de actualización por medio del cual se vuelven activas las modificaciones; almacenar las modificaciones como datos activos de la empresa, en respuesta al procedimiento de actualización; y notificar al personal del cliente o comprador de las modificaciones de los registros.
60. Un sistema computarizado para la administración del trabajo del proyecto, el sistema computarizado, que comprende: una interfaz adaptada para recibir las configuraciones de administración de proyectos y los datos transaccionales de trabajo del proyecto para el trabajo del proyecto a ser llevado a cabo para un cliente o comprador por un proveedor; un sistema de base de datos para almacenar las configuraciones de administración de proyectos recibidas y los datos transaccionales de trabajo del proyecto; y un servidor conectado a la interfaz y conectado al sistema de base de datos; y caracterizado porque, el servidor se adapta para: determinar los datos de entregables de la orden de copra de los datos transaccionales de trabajo del proyecto que se producen del cumplimiento relativo a las fechas de terminación programadas; en respuesta a la determinación, generar una sesión de comunicaciones en riesgo del proyecto usando los datos transaccionales de trabajo del proyecto y las configuraciones de administración del proyecto; y procesar una respuesta del paquete de comunicaciones en riesgo del proyecto.
61. Un articulo de fabricación para la gestión administrativa del trabajo de proyectos, el articulo de fabricación, caracterizado porque, comprende: al menos un medio legible por computadora; instrucciones de procesador contenidas en al menos un medio legible por computadora, las instrucciones de procesador configuradas para ser legibles desde al menos un medio legible por computadora por al menos un procesador y en consecuencia de esto hacer que al menos un procesador opere para: recibir de un cliente o comprador, las configuraciones de administración del proyecto; almacenar los datos transaccionales de trabajo del proyecto relativos al trabajo del proyecto a ser llevado a cabo para el cliente o comprador por un proveedor; recibir, del cliente o comprador, la configuración de los registros de declaración de trabajo (SOW) del proyecto; procesar un conjunto de registros de cambios en el plan/alcance del proyecto del cliente o comprador; procesar un conjunto de registros de cambios en el plan/alcance del proyecto del proveedor; y crear un conjunto de registros integrados de cambios en el plan/alcance del proyecto usando el conjunto de registros del cliente o comprador y el conjunto de registros del proveedor.