MX2007007999A - Sistema y procedimiento para procesamiento programado de transaccion y pago de multi-proveedores. - Google Patents

Abstract

En una modalidad ejemplar, un procedimiento de manejo de contratos basado en computadora procesa transacciones que involucran al menos un proveedor (es decir, vendedor o vendedores) que satisfacen uno o mas componentes secundarios de la transaccion. Cada uno de los proveedores (por ejemplo, tal como otras partes de transaccion) hace referencia a la transaccion cuando comunica informacion de transaccion tal como facturas, independientemente de con cual componente secundario de la transaccion se involucra el vendedor. Las facturas se asocian con la transaccion utilizando la transaccion referida en cada factura y por consiguiente se le paga a cada proveedor por su rendimiento del componente secundario de transaccion con el que se involucra. A partir de la perspectiva del comprador, la transaccion es procesada de acuerdo con los componentes secundarios asociados con al menos un proveedor. Por cada proveedor, la transaccion se procesa generalmente en forma bidimensional (mediante comprador y mediante proveedores), de este modo aislando generalmente (donde es deseable) a cada proveedor de los componentes secundarios de la transaccion para la cual no es un participante.

Description

SISTEMA Y PROCEDIMIENTO PARA PROCESAMIENTO PROGRAMADO DE TRANSACCIÓN Y PAGO DE MUL I-PROVEEDORES DESCRIPCIÓN DE LA INVENCIÓN La presente invención se dirige a comunicaciones y procesamiento de datos y, más específicamente, a comunicaciones y procesamiento de datos que involucran el procesamiento de transacciones que involucran proveedores múltiples para una sola transacción. El manejo operacional de interacciones contractuales y de transacción entre compradores, vendedores, instituciones financieras y otros involucrados en el intercambio de productos y/o servicios para propósitos de comercio típicamente han sido de trabajo y tiempo intensivos. Generalmente, los procesos para manejar transacciones entre entidades comerciales han sido indebidamente laboriosos e ineficientes. Muchas transacciones involucran una variedad de partes que interactúan en diferentes niveles jerárquicos y junto con diferentes aspectos de las transacciones. Por ejemplo, las transacciones que involucran diferentes facetas de rendimiento (por ejemplo, la provisión de productos o servicios) que pueden satisfacerse por diferentes entidades con frecuencia involucran dos o más proveedores. Por ejemplo, cuando una transacción involucra la provisión de una pluralidad de productos, los productos pueden obtenerse de diferentes proveedores con el pretexto de la misma transacción. Similarmente, una transacción basada en servicio puede involucrar la provisión de diferentes aspectos de servicio bajo el mismo contrato. Además, transacciones que involucran la compra de un producto con frecuencia involucra la provisión de un producto así como servicios de transporte para distribuir el producto desde un vendedor hasta un comprador. Esas transacciones también pueden involucrar servicios de procesamiento y/o comisiones a lo largo de la ruta de distribución, tal como despacho de aduanas en el puerto de exportación, comisiones por derechos de importación/exportación, y seguros durante el tránsito, por cuya responsabilidad puede cambiar entre las partes dependiendo de dónde se localizan realmente los productos en un punto en el tiempo. Al utilizar el ejemplo de transporte, para muchas transacciones de transporte (por ejemplo, que se separan de la compra de productos que se transportan) , con frecuencia existe un transportista (la entidad que dispone el trasporte de los productos), un transportador (la entidad que lleva los productos) , un vendedor (la entidad que vende los productos) , un asegurador (la entidad que proporciona el seguro de tránsito al transportista, el transportador y/o el comprador) , y un comprador (la entidad que recibe los productos) . En este respecto, el transporte mismo puede considerarse una porción de transporte sencilla de una transacción más compleja que comienza con un acuerdo entre un comprador y un vendedor. En algunos casos, el vendedor actúa como el transportista y dispone y paga el transporte de los productos separadamente del comprador y con el costo del transporte efectivamente preparado en el costo de los productos. En otras transacciones de transporte, el vendedor dispone el transporte de los productos por las instrucciones del comprador y el comprador paga los servicios de transporte directamente a la parte seleccionada por el vendedor. En los tipos de transacciones antes discutidos y otros, el vendedor algunas veces se desempeña al proporcionar productos y/o servicios directamente y, otras veces, el vendedor realiza un contrato con una parte directa para realizar parte o todos los aspectos de transacción. En este caso, el vendedor actúa como un intermediario, con el comprador estando de acuerdo en pagar una cantidad contratada entre el vendedor intermediario y el comprador. El vendedor de este modo está de acuerdo en pagar a las partes directas (por ejemplo, subcontratistas) una cantidad contratada entre el vendedor y cada parte directa. En cada uno de los ejemplos anteriores, varias facturas y actividades relacionadas (contabilidad, ajustes, etc.) se requieren para cada contrato en la cadena de contratos entre las partes compradoras, vendedoras, intermediarias o directas. Además, actividades de seguimiento para propósitos comerciales y reglamentarios con frecuencia requieren que los registros se mantengan para la transacción. Estas actividades exigen mucho tiempo, se someten a error y con frecuencia son de naturaleza doble. Por ejemplo, en la etapa de pago, instituciones financieras para diferentes partes en la transacción deben interactuar entre sí. Esta interacción típicamente involucra acuerdos complejos y asociaciones que facilitan la transferencia de fondos. A veces, pueden existir demoras en el pago o disputas con respecto a términos de pago. Además, este proceso es altamente susceptible de error. La complejidad de interacción, retardo, error y una pluralidad de otras características de pago de transacción pueden costar a una o más partes en una transacción (que incluyen instituciones financieras), una cantidad importante de fondos. La mayoría de las industrias son bastante competitivas y cualesquier ahorros de costo por lo tanto son importantes. Costos administrativos se destinan para la reducción ya que ningún ingreso se genera directamente de las funciones administrativas. Sin embargo, los costos administrativos asociados con transacciones comerciales han sido difíciles de reducir en el ambiente comercial actual con datos ampliamente difundidos. Las dificultades anteriores y otras en el manejo y combinación de transacciones comerciales han presentado retos administrativos y de costo para entidades comerciales involucradas en varios aspectos de transacciones, que incluyen instituciones financieras y otras. La presente invención se dirige a dirigir los retos relacionados con los tipos de aplicaciones discutidas en lo anterior y otras. La presente invención se ejemplifica en un número de implementaciones y aplicaciones, de cuales algunas se resumen en lo siguiente. De acuerdo con una modalidad ejemplar de la presente invención, una transacción se procesa automáticamente para efectuar el pago por lo menos a un proveedor para la transacción como una función de porciones de la transacción realizadas por cada proveedor. En una implementación, los documentos de transacción (por ejemplo, datos electrónicos) se auditan y el pago se efectúa como una función de la auditoria. En otra implementación, una comisión se evalúa para una o más partes en la transacción co o una función de la transacción y un acuerdo con una o más partes en la transacción. En otra modalidad ejemplar, las transacciones de transporte involucran dos o más transportadores que realizan diferentes porciones (extremidades) de una ruta de transporte se procesan como una función de la información recibida por cada transportador y la información de identificación de transacción común. Cada uno de los transportadores presenta una factura y las facturas se correlacionan con una transacción particular. El pago se facilita (por ejemplo, autoriza) como una función de las facturas. De acuerdo con otra modalidad ejemplar de la presente invención, un sistema de procesamiento de transacción automatizada se adapta para facilitar el procesamiento de transacción para una transacción que involucra dos o más proveedores. Los datos de contrato se almacenan para partes en una transacción. Los datos de contrato de incluyen una identificación de transacción (ID) y la información con relación a un contrato que involucra el intercambio de ofertas mercantiles (por ejemplo, productos y/o servicios) entre una parte compradora y por lo menos dos partes proveedoras, donde cada proveedor realiza una sub-parte del contrato ya sea en la dirección del comprador o en la dirección de un tercero. La información de solicitud de pago que incluye una ID de transacción de las partes proveedoras se envía al sistema de procesamiento de transacción automatizada. La información de solicitud de pago (por ejemplo, una factura con una ID de transacción) típicamente refleja las características de pago de la transacción que se relacionan con las ofertas mercantiles proporcionadas por la parte proveedora que proporciona la información de solicitud de pago. La información de pago de cada parte proveedora se audita como una función de una comparación de la ID de transacción en la información de solicitud de pago con la ID de transacción almacenada en los datos de contrato. Cuando la ID de transacción en la información de solicitud de pago de una parte proveedora particular concuerda con la ID de transacción en los datos del contrato, la declaración de una sub-parte del contrato que involucra ofertas mercantiles proporcionadas por la parte proveedora particular se efectúa como una función de la información de solicitud de pago de la parte proveedora particular y la sub-parte del contrato. El resumen anterior de la presente invención no se pretende para describir cada modalidad ilustrada o cada implementación de la presente invención. Las figuras y la descripción detallada que siguen ejemplifican más particularmente estas modalidades. BREVE DESCRIPCIÓN DE LOS DIBUJOS La invención puede entenderse más completamente en consideración de la descripción detallada de varias modalidades de la invención junto con los dibujos anexos en los cuales: La FIGURA 1 muestra una disposición y procedimiento de procesamiento de transacción, de acuerdo con una modalidad ejemplar de la presente invención; la FIGURA 2 muestra una disposición y procedimiento para manejar transacciones relacionadas con transporte, de acuerdo con otra modalidad ejemplar de la presente invención; y la FIGURA 3 muestra un diagrama de flujo del procesamiento de transacción, de acuerdo con otra modalidad ejemplar de la presente invención. Mientras la invención se puede someter a varias modificaciones y formas alternativas, especificaciones de las mismas se han mostrado por medio del ejemplo en los dibujos y se describirán en detalle. Se debe entender, sin embargo, que la intención no necesariamente es limitar la invención a las modalidades particulares descritas. Por el contrario, la intención es cubrir todas las modificaciones, equivalentes y alternativas que caigan dentro del espíritu y alcance de la invención como se define por las reivindicaciones anexas. La presente invención se cree que se puede aplicar a una variedad de diferentes tipos de comunicaciones y procedimientos de manejo de proceso financiero, y se ha encontrado que es particularmente útil para aplicaciones que involucran la implementación y aplicación de procesos de transacción relacionados con el pago y aspectos relacionados de los mismos. Mientras la presente invención no se limita necesariamente a tales procedimientos, varios aspectos de la invención pueden apreciarse a través de una discusión de varios ejemplos utilizando estos y otros contextos. De acuerdo con una modalidad ejemplar de la presente invención, una transacción que involucra proveedores múltiples se procesa automáticamente utilizando términos contractuales (relacionados con la transacción) para cada uno de los proveedores y una o más partes compradoras. Cada uno de los proveedores realiza una porción particular de la transacción, con una o más partes compradoras recibiendo ofertas mercantiles (por ejemplo, productos y/o servicios) proporcionados por los proveedores de acuerdo con los términos de la transacción. Cuando se facturan datos (por ejemplo, una factura) se recibe de uno de los proveedores, los datos se relacionan automáticamente con la transacción particular utilizando información en los datos de facturación junto con la información almacenada para la transacción. Los fondos de una parte compradora (o partes compradoras) donde es apropiado, se pasan al proveedor como se indica en los términos contractuales y de acuerdo con los datos de facturación. Los datos de facturación presentados por los proveedores subsiguientes se procesan similarmente. En este respecto, cada proveedor es parte de una transacción común y se le paga de acuerdo con la porción de la transacción realizada por el proveedor. Este procedimiento se puede aplicar a las relaciones directas de tipo comprador-vendedor así como a otras relaciones, tales como aquellas que involucran el comprador como una parte tipo vendedor/comprador intermediaria, que realiza un subcontrato con proveedores para llevar a cabo condiciones de una transacción particular. En algunas aplicaciones, uno o más proveedores en una transacción generalmente se aislan de la información con respecto a la transacción que directamente no se relaciona con el proveedor o proveedores particulares. Es decir, la información de transacción asociada con el proveedor se procesa separadamente y/o maneja de tal manera que la visión de la transacción del proveedor generalmente se limita a porciones de la transacción en la cual se involucra específicamente el proveedor. En algunos casos, el proveedor se limita en vista de la transacción para las funciones de tipo contrato, tal como entre el proveedor y un comprador o comprador intermediario, y/o funciones tipo pago, tal como entre el proveedor y una institución financiera que proporciona el pago para la transacción. En este respecto, a partir de cada perspectiva del proveedor, la "transacción" se limita a aquella que involucra el proveedor, mientras a partir de una perspectiva del comprador (o intermediario) , la transacción involucra proveedores múltiples y/o sub-transacciones separadas que forman toda la transacción. En una implementación, una comisión se evalúa por lo menos para una parte en la transacción como una función de una o más de una variedad de características de transacción*; En algunas aplicaciones, se evalúa una comisión para una parte central (por ejemplo, un proveedor) como una función de una cantidad de pago para la transacción como caracterizada por un contrato por comisión entre la parte central y una entidad que facilita el procesamiento de transacción. En otras aplicaciones, se evalúan comisiones para múltiples partes de acuerdo con contratos similares por comisión y/o una cantidad de pago de transacción. Esas comisiones además se evalúan, donde es apropiado, en una forma de conformidad con las sub-partes de la transacción (y el contrato relacionado) realizada por diferentes proveedores. Otra modalidad ejemplar involucra la distribución electrónica de información. Por ejemplo, propagar información de comercialización podría proporcionarse por proveedores múltiples para una transacción común. Como otro ejemplo, datos de voz por teléfono pueden distribuirse por dos o más portadoras de información. Estas aplicaciones de distribución electrónica pueden involucrar, por ejemplo, el uso de la Internet, líneas telefónicas y/o torres de transmisión. Donde se proporcionan datos de propagación mediante la Internet, las portadoras de datos electrónicos pueden captar datos para la distribución de una o más terminales de origen del proveedor a una o más terminales de destino. En algunas aplicaciones, perfiles precargados, asegurados con contraseña con datos de perfiles se utilizan para lanzar la distribución de los datos electrónicos (por ejemplo, propagación) y/o la implementación de los datos en una terminal de destino. En otra modalidad ejemplar, una transacción de transporte que involucra múltiples transportadores se procesa utilizando una identificación de orden único (ID) para diferentes rutas servidas por diferentes transportadores. La ID de orden única se refiere a las ubicaciones de origen y de destino para transportar un elemento sobre una ruta primaria, con transportadores separados realizando porciones de la ruta a lo largo de la cual se transporta el elemento. Las facturas de transporte de los transportadores se asocian automáticamente con la ruta primaria que utiliza la información en las facturas. Además, las facturas de transporte se asocian separadamente con la porción de la ruta servida por el transportador particular que es el objeto de la factura. Esta información se utiliza para auditar las facturas y para generar una autorización de pago basándose en la factura (y, en algunos casos, efectuar el pago). Cada transportador se le paga de acuerdo con su porción de la ruta primaria. En algunas implementaciones, las reglas comerciales y/u otra información que se refiera a las partes en la transacción (por ejemplo, la información de perfiles) se almacena y se utiliza para asociar y/o auditar datos de transacción tales como facturas. Para información general con respecto a transacciones de transporte y para información específica con respecto a procedimientos de transacción de transporte que pueden implementarse junto con ésta y/u otras modalidades ejemplares en la misma, puede hacerse referencia a la Patente Norteamericana No. 5,910,896, la cual se incorpora completamente en la presente para referencia. En otra implementación, un procedimiento de pago a través del pago se utiliza para pagar a sus proveedores de partes compradoras mientras limitan la transacción, a partir de una perspectiva del sub-proveedor particular, a aquella dispuesta entre el sub-proveedor particular y una parte compradora intermedia. Por ejemplo, donde una parte compradora es un intermediario y un producto o servicio de la transacción se destina a un comprador externo, el pago para el rendimiento de transacción por cada proveedor respectivo se procesa directamente desde el comprador externo hasta el proveedor como parte del procesamiento de pago desde el comprador externo hasta el proveedor intermediario/comprador. Sin embargo, la información de transacción para cada sub-proveedor se procesa separadamente de acuerdo con los términos asociados con una transacción individual entre el sub-proveedor y el intermediario, con el pago siendo procesados separadamente (y hechos) por el intermediario y obtenido del comprador externo. En este respecto, a partir de la perspectiva de un proveedor, su porción de la transacción se limita a aquella entre el proveedor y el comprador intermediario, con el pago viniendo desde una fuente externa pero hecho de acuerdo con la transacción entre el proveedor y el intermediario. Para información general con respecto al procesamiento de transacción y para información específica con respecto a procedimientos de tipo pago a través de pago que pueden implementarse junto con ésta y otras modalidades ejemplares en la presente, puede hacerse referencia a la Solicitud de Patente Norteamericana No. de Serie presentada el 22 de diciembre de 2005 y titulada: "Sistema y Procedimiento de Procesamiento de Transacción de Multi-Partes" (Expediente del Apoderado No. USBA.133PA), la cual se incorpora completamente en la presente para referencia. En algunas implementaciones, un proceso de auditoria se lleva a cabo junto con la recepción de los datos de facturación discutidos en lo anterior. Por ejemplo, cuando los datos de facturación incluyen una información de identificación del vendedor (ID) asociada con una transacción identificable particular, los datos de facturación se auditan para asegurar que el vendedor particular de hecho es parte en la transacción identificable. Además, los términos de los datos de facturación tales como la cantidad de pago y/u otras comisiones asociadas, la coordinación (pago y/o rendimiento de contrato) y otros se auditan selectivamente para asegurar que se cumplan ciertas condiciones basadas en transacción. En otra modalidad ejemplar, las reglas comerciales para partes compradoras y/o vendedoras se utilizan para procesar la transacción y además, donde se puede aplicar, para controlar el acceso a la información que se refiere a la transacción. Por ejemplo, donde un comprador (o parte compradora intermediaria) realiza un contrato con diferentes vendedores, las reglas comerciales para el comprador se utilizan para procesar la transacción. Estas reglas pueden incluir, por ejemplo, reglas para establecer términos de contrato, realizar pago o proporcionar información a partes vendedoras. Además, las reglas comerciales pueden diseñarse para transacciones específicas, con ciertos términos de transacción establecidos para la transacción específica. En algunas implementaciones, las reglas comerciales incluyen información para diferenciar entre proveedores para aplicar reglas particulares. Es decir, una transacción particular que involucra dos diferentes proveedores se procesa de acuerdo con diferentes reglas comerciales. Porciones de la transacción que se refieren a un vendedor particular se procesan de acuerdo con las reglas comerciales para ese vendedor particular, con otras porciones de la transacción involucrando otros vendedores que se procesan de acuerdo con las reglas comerciales para cada vendedor particular, donde se puede aplicar. Por ejemplo, un comprador y un vendedor pueden estar de acuerdo sobre los términos de transacción comercial específicos, tales como el tiempo de pago, el tipo de pago, las comisiones por transporte y más.

Esos términos de transacción comercial específicos pueden registrarse separadamente en asociación con reglas comerciales que aplican a un vendedor particular. En una implementación, las reglas comerciales se aplican selectivamente a un vendedor particular de acuerdo con las características relacionadas con el vendedor y/o la transacción; diferentes conjuntos de reglas comerciales pueden aplicar a un vendedor particular. Por ejemplo, las características de transacción tales como la ubicación geográfica, la ubicación de la transacción particular con el vendedor (o de una porción sustancial de la transacción con el vendedor) o asociaciones entre el vendedor y otras entidades pueden beneficiarse de la aplicación selectiva de reglas comerciales. Una variedad de funciones de procesamiento de transacción, que incluyen aquellas discutidas en lo anterior, pueden llevarse a cabo implementado reglas comerciales para propósitos que incluyen la asociación de datos de transacción, selección de términos de contrato, el manejo de pago de contrato y/o funciones de auditoria y más. Para información general con respecto a contratos y procesamiento de transacción, y para información específica con respecto a procedimientos de procesamiento de contrato y transacción a los cuales se puede aplicar la presente invención, puede hacerse referencia a la Solicitud de Patente Norteamericana No. de Serie 10/436, 878 (USBA.101PA) , presentado el 12 de mayo de 2003 e incorporada completamente a la presente para referencia . Regresando ahora a las figuras, la FIGURA 1 muestra una disposición y procedimiento de procesamiento de transacción de acuerdo con otra modalidad ejemplar de la presente invención. Una disposición 105 de transacción maneja transacciones entre partes compradoras y dos o más partes que facilitan la provisión de productos y/o servicios (por ejemplo, ofertas mercantiles) de acuerdo con una transacción particular para la cual va a hacerse el pago (por ejemplo^ mediante la interacción con una o más instituciones financieras) . Aquí, una pluralidad de partes de transacción que incluyen partes 110-118 compradoras, partes 120-124 intermediarias y partes 130-136 vendedoras se muestran por medio del ejemplo. Mientras ciertas partes compradoras, intermediarias y vendedoras se muestran, esta modalidad ejemplar y procedimientos relacionados se pueden aplicar a una pluralidad de partes, así como a tipos adicionales de partes de transacción (o menos partes, por ejemplo, con ninguna parte intermediaria y/o con un solo comprador con dos vendedores) , las cuales pueden implementarse para una variedad de situaciones. La disposición 105 de transacción almacena datos (local y/o remotamente) con relación a los términos 140 de contrato y los perfiles 142 de usuario, y además procesa funciones de transacción utilizando un procesador 144 de proveedor múltiple. Los términos 140 de contrato incluyen información para contratos específicos relacionados con las acciones procesadas por la disposición 105 de transacción. Los términos 140 de contrato pueden gobernar una sola transacción, tal como en una situación de licitación/concesión de puesto, o múltiples transacciones, tal como un contrato de varios años para entregas sincronizadas de productos particulares. Por medio del ejemplo, un contrato 141 se muestra almacenado con los términos 140 de contrato e incluye sub-contratos 143 y 145 para diferentes vendedores para una transacción común. Los perfiles 142 de usuario incluyen información sobre partes en cada transacción, tal como información de cuenta financiera que facilita la ejecución de las funciones de pago para la transacción, o información tal como contraseñas que facilitan el control de acceso a la información de transacción. El procesador 144 de proveedor múltiple se programa para procesar datos relacionados con la transacción tal como la confirmación de pedido, la confirmación de transporte, la autorización de pago y los detalles de liquidación para facilitar la transacción y los aspectos relacionados con el pago de la misma. Los términos 140 de contrato describen información para contratos particulares entre un comprador o compradores y dos o más vendedores, con cada vendedor realizando una porción de la transacción. Estos términos 140 de contrato, por ejemplo, pueden incluir términos de contrato específicos para un vendedor particular y/o una transacción particular, donde los términos de contrato pueden o no variar entre diferentes vendedores, dependiendo de la aplicación. Por ejemplo, cuando el comprador 110 tiene un contrato separado con vendedores 130 y 132 para una sola transacción, el procesador 144 de proveedor múltiple implementa información de contrato específica relacionada con el vendedor particular para el cual se está procesando la porción de la transacción. Es decir, cuando se procesan funciones de transacción tal como el pago para una transacción particular que involucra el comprador 110 y los vendedores 130 y 132, el procesador 144 de proveedor múltiple utiliza diferentes términos de contrato cuando procesa porciones de la misma transacción pero involucran una parte vendedora diferente. Cuando los términos 140 de contrato incluyen términos de contrato que son consistentes entre diferentes vendedores para una transacción particular, esos términos se implementan consistentemente (con relación, por ejemplo, a los términos implementados separadamente discutidos en lo anterior) . En algunas aplicaciones que involucran partes intermediarias (120-124), la disposición 105 de transacción procesa las transacciones proporcionadas por dos o más de los vendedores 130-136 y recibidas (productos y/o servicios) por uno o más compradores 110-118. Por ejemplo, donde una parte 120 intermediaria ejecuta una transacción con un comprador 110 para transportar productos a lo largo de una ruta de transporte principal particular, la parte intermediaria puede realizar un contrato separadamente con dos o más vendedores 130 y 132 (transportadores) . Aquí, el comprador 110 puede ser el receptor de los productos que se transportan o el proveedor de los productos que se transportarán a un cliente. La transacción se relaciona con un servicio particular, particularmente, el transporte de productos sobre la ruta de transporte principal particular (desde un origen hasta un destino) como se indica por el comprador u otra entidad, y la transacción se refiere por consiguiente como tal. Sin embargo, cada vendedor (transportador) realiza las funciones del transporte sobre sub-rutas separadas que forma la ruta entre el origen y el destino, desde el origen hasta una ubicación intermedia y, subsiguientemente, desde esa ubicación intermedia hasta el destino. La disposición 105 de transacción procesa, con el procesador 144 de proveedor múltiple, la información de transacción que se refiere al pago para cada uno de los vendedores 130 y 132 (transportadores) para su servicio respectivo realizados con cada sub-ruta por referencia a la ruta de transporte principal . El procesador 144 de proveedor múltiple lleva a cabo el pago y otras funciones de tipo interactivas con compradores, vendedores y, donde se puede aplicar, intermediarios en una variedad de formas, dependiendo de los términos 140 de contrato y los perfiles 142. Por ejemplo, un contrato particular entre un comprador 110 y un vendedor 130 puede indicar cuando se efectuará el pago. En algunas aplicaciones el pago al vendedor 130 se efectúa con el término de la porción del vendedor de la transacción (por ejemplo, en el ejemplo anterior, cuando un vendedor (transportador) realiza su porción de la ruta de transporte) . En otras aplicaciones, el pago al vendedor 130 se efectúa con el término de toda la transacción (por ejemplo, en el ejemplo anterior, cuando el transporte alcanza su destino) . Una pluralidad de tipos de términos tales como estos se implementan con los términos 140 de contrato y se procesan por el procesador 144 de proveedor múltiple, dependiendo de la aplicación y contratos particulares entre las partes en las transacciones. En otra modalidad, el procesador 144 de proveedor múltiple facilita el procesamiento para transacciones que involucran un contrato que se realiza con el tiempo. Por ejemplo, donde un comprador 110 ingresa en un contrato con una parte 120 intermediaria para ofertas mercantiles durante un período de tiempo particular, el procesador 144 de proveedor múltiple procesa las funciones de pago para las sub-partes del contrato conforme se realizan con el tiempo por diferentes proveedores (por ejemplo, utilizando una ID de transacción común) . Este procedimiento puede implementarse, por ejemplo, cuando la parte 120 intermediaria realiza el contrato con el comprador 110 para proporcionar un monto particular de productos en intervalos. La parte 120 intermediaria entonces puede realizar el contrato con los proveedores 130 y 132 para proporcionar el monto de productos en diferentes momentos. En este respecto, el procesador 144 de proveedor múltiple procesa la información de factura recibida de los proveedores 130 y 132 presentados, por ejemplo, conforme realizan respectivamente las sub-partes del contrato. En otra modalidad ejemplar, una parte 120 intermediaria opera la disposición 105 de transacción para procesar transacciones entre el comprador 110-118 y vendedores 130-136 de acuerdo con los términos 140 de contrato proporcionados por las partes de transacción y además evalúan una comisión por procesamiento en una o más de las partes de transacción. Por ejemplo, donde un comprador 110 realiza un contrato con dos vendedores 130 y 132 para realizar respectivamente los sub-componentes de una transacción, el comprador puede enlistar los servicios de la disposición 105 de transacción para procesar aspectos financieros de la transacción. El procesador 144 de proveedor múltiple procesa la información de transacción, tal como las facturas recibidas de los vendedores 130 y 132, al asociar las facturas con una transacción particular y además con el vendedor particular que proporciona la factura. La asociación se utiliza para determinar elementos de los términos 140 de contrato para utilizarse en el procesamiento (por ejemplo, auditoria) de las facturas y efectuar correspondientemente el pago por lo tanto. La autorización de pago se correlaciona con una transacción particular en el bloque 310. La correlación puede involucrar utilizar, por ejemplo, información que identifica la transacción o que identifica la parte en la autorización de pago. Se evalúan las comisiones de acuerdo con una o más de una variedad de características, tales como los aspectos financieros de la transacción (por ejemplo, la cantidad de una venta procesada por la disposición 105 de transacción) o una comisión establecida. Estas comisiones por ejemplo, pueden establecerse como una función de un contrato entre la parte 120 intermediaria y las partes (compradores o vendedores) en la transacción. En otra modalidad ejemplar, la disposición 105 de transacción se adapta para procesar transacciones financieras que involucran dos o más proveedores financieros (es decir, proveedores de fondo) que proporcionan los fondos a un comprador, vendedor u otra parte apropiada que participa en una transacción particular. Cada uno de los proveedores financieros proporciona sub-partes de una cantidad de fondos para el comprador o vendedor para clases de fondos de transacciones que satisfacen los parámetros definidos (por ejemplo, productos específicos procurados por compradores definidos de vendedores definidos. Los datos tipo pago, tal como una comisión evaluada para proporcionar fondos para una sub-parte para la transacción financiera, proporcionada por cada proveedor financiero se procesa por el procesador 144 de proveedor múltiple utilizando una ID de transacción común. Este procedimiento puede implementarse, por ejemplo, donde un comprador utiliza múltiples entidades financieras para proporcionar fondos para transacciones particulares que satisfacen parámetros de fondos definidos, que implementan términos 140 de contratos separados para servicios financieros proporcionados por cada entidad financiera. En una implementación, dos o más proveedores financieros proporcionan fondos en diferentes divisas para una transacción financiera particular. La disposición 105 de transacción procesa las sub-partes de una transacción para cada divisa como se proporciona por diferentes proveedores financieros (por ejemplo, donde un primer proveedor proporciona fondos en una primera divisa y un segundo proveedor proporcionar fondos en una segunda divisa, para su utilización en una transacción común) . Cada proveedor financiero hace referencia a una ID de transacción común cuando proporciona datos de tipos pago a la disposición 105 de transacción. Una aplicación ejemplar a la cual puede aplicarse esta implementación involucra un comprador en una primera ciudad que compra productos y/o servicios de un vendedor en una segunda ciudad. Un primer proveedor financiero proporciona fondos en una primera divisa a nombre del comprador y evalúa por consiguiente una comisión (por ejemplo, en la cantidad de los fondos proporcionados más un cargo por servicio y/o financiamiento) . Un segundo proveedor financiero proporciona fondos en una segunda divisa a nombre del vendedor y evalúa una comisión (por ejemplo, en una cantidad convertida de los fondos proporcionados en la segunda divisa más un cargo por servicio y/o financiamiento) . En ciertas aplicaciones relacionadas, un segundo proveedor financiero considera la identidad del comprador y el primer proveedor financiero cuando toma su decisión en cuanto a si proporciona fondos al proveedor (por ejemplo, en situaciones de financiamiento de pre-exportación o en situaciones de suposición de post-exportación, pre-propiedad) . Las reglas u otras características relacionadas con la transacción y/o con las partes de transacción de este modo pueden contemplar la consideración del segundo proveedor financiero de una o más de la identidad del comprador y el primer proveedor financiero. En todas estas implementaciones, las comisiones se evalúan selectivamente para el comprador y/o para una parte en una transacción para la cual se están proporcionando los fondos en la transacción financiera. El procedimiento de asociación descrito en lo anterior puede implementarse utilizando, por ejemplo, una o más de las modalidades e implementaciones descritas junto con la Solicitud de Patente Norteamericana No. de Serie 10/864,761 (USBA.120PA) , presentada el 9 de junio de 2004, la cual se incorpora en la presente para referencia en su totalidad. Además, otros procedimientos de procesamiento de transacción discutidos en la presente pueden implementar tales procedimientos de asociación el procesamiento de transacciones de tipo proveedor múltiple que involucran componentes de sub-transacción asociados con una transacción principal particular y el procesamiento acordado de la misma. La FIGURA 2 muestra una disposición del procedimiento para manejar transacciones relacionadas con transporte mediante un procesador 205 de transacción, de acuerdo con otra modalidad ejemplar de la presente invención. El procedimiento mostrado en la FIGURA 2 puede implementarse junto con los procedimientos del procesamiento de transacción como se describe, por ejemplo, junto con la FIGURA 1 anterior. El procedimiento mostrado en la FIGURA 2 involucra el procesamiento de una transacción de transporte entre un origen 210 y un destino 230, con un vendedor 260 proporcionando un elemento que va a transportarse en el origen hasta un comprador 250 que compra el elemento y que recibe el elemento en el destino 230. En algunos casos, un comprador tercero recibe el elemento en el destino 230 donde, por ejemplo, el comprador 250 a su vez puede facturar al comprador tercero para el elemento. El transportador A (240) transporta el elemento desde el origen 210 hasta una ubicación 220 en tránsito y el transportador B(242) transporta el elemento desde la ubicación en tránsito hasta el destino 230. En este respecto, la ruta total de transporte, entre el origen 210 y el destino 230 es servida por dos sub-rutas y con la ubicación 220 en tránsito. Cada transportador 240 y 242 hace referencia al sub-componente de la ruta de transporte que desempeña al referir simplemente a una ID de transacción general que es común para toda la transacción de transporte, independientemente de cual porción de la transacción se involucre. El procesador 205 de transacción facilita el procesamiento de funciones contractuales y de pago de la transacción que involucra el transporte desde el origen 210 hasta el destino 230. En este respecto, el procesador 205 de transacción está en comunicación con cada parte en la transacción como se describe en lo anterior, o electrónicamente o de otra forma, así como para instituciones financieras para las partes en la transacción, con instituciones 270-275 ejemplares dando servicio respectivamente a un transportador A, transportador B, el vendedor y el comprador. En un ejemplo, el procesador 205 de transacción procesa una transacción de transporte como sigue, utilizando una ID de transacción para porciones de referencia de la transacción realizada por diferentes transportadores. Un vendedor o entidad de manejo de transacción proporciona información de transacción al procesador de transacción para su utilización en identificar facturas y otros datos recibidos junto con la transacción. Esta información incluye información de contrato, información de perfil de la parte de transacción (por ejemplo, identificación e institución financiera) y más. Cuando el transportador A(240) realiza su porción de la transacción, presenta una factura al procesador 205 de transacción, la factura hace referencia a la ID de transacción común. Similarmente, cuando el transportador B(242) realiza su porción de la transacción, presenta una factura al procesador 205 de transacción, y también refiere a la misma ID de transacción. El procesador de transacción toma la información de factura y facilita el pago como una función de la información de contrato al correlacionar la información en la factura con la transacción (por ejemplo, utilizando la ID de transacción común con la fuente de la factura) . Por ejemplo, donde la información de contrato indica que el transportador A no se le pagará hasta la recepción de los elementos transportados en la ubicación 220 en tránsito, tal recibo se utiliza para autorizar el procesamiento de pago en el procesador de transacción. Alternativamente, la información de contrato puede indicar al transportador A que no se le pagará hasta la recepción de los elementos transportados en el destino 230. La factura para el transportador B puede procesarse similarmente. Otras características contractuales, tal como la fecha de pago, la aceptación de elementos transportados y más, donde se puede aplicar, además se implementa por el procesador 205 de transacción para generar una autorización para pago de una factura . Cuando el pago para una factura se autoriza exitosamente, el procesador 205 de transacción además facilita el pago al comunicarse con una o más de las instituciones 270-276 financieras de tal manera que se les paga a los transportadores por los servicios que proporcionan, del comprador 250 y/o el vendedor 260/ dependiendo de la transacción particular y los términos de contrato. Los fondos para los transportadores se proporcionan del comprador 250 y/o del vendedor 260, dependiendo de la aplicación. Por ejemplo, donde el vendedor 260 es un transportista que realiza un contrato con el comprador 250 para el transporte de los elementos, el vendedor generalmente puede facturar al comprador directamente para una comisión de transacción acordada. A su vez, el vendedor puede facturarse por los transportadores para su porción de la comisión por transacción. En este ejemplo, donde se indica por los términos de contrato disponibles en el procesador 205 de transacción, el vendedor 260 puede proporcionar fondos mediante la institución 274 financiera del vendedor a cada una de las instituciones 270 y 272 financieras del transportador. El pago para la transacción general se hace a la institución 274 financiera del vendedor mediante la institución 276 financiera del comprador (por ejemplo, separadamente del pago a los transportadores) . En algunas aplicaciones, el vendedor 260 dirige el procesador de transacción para pagar a cada institución financiera del transportador (270, 272) de los fondos proporcionados por el comprador 250 mediante la institución 276 financiera del comprador directamente a cada institución financiera del transportador. Los fondos restantes (si los hubiera) disponibles del comprador 250 entonces se proporcionan al vendedor . En otros casos, el comprador 250 realiza un contrato separadamente con los transportadores 240 y 242 para transportar los elementos y por consiguiente vuelve disponible además a los fondos mediante la institución 276 financiera del comprador para el pago con la aprobación de las facturas presentadas por los transportadores respectivos. En esos casos, el procesador 205 de transacción puede implementar términos de contrato entre el comprador 250 y los transportadores 240 y 242 para facilitar el pago, con una ID de transacción común que representa toda la ruta de transporte desde el origen 210 hasta el destino 230 que se implementa para asociar las facturas con la transacción. La FIGURA 3 muestra un diagrama de flujo para el procesamiento de transacción, de acuerdo con otra modalidad ejemplar de la presente invención. Los procedimientos descritos junto con el diagrama de flujo en la FIGURA 3 pueden implementarse utilizando uno o más tipos de acuerdos de transacción y por ejemplo, pueden involucrar el uso de una o más de las disposiciones o componentes de los mismos como se muestra en las FIGURAS 1 y/o 2 y se describe junto con la misma. En el bloque 300, los datos de transacción que incluyen una identificación de transacción (ID), ID de comprador y por lo menos una ID de vendedor se recibe, por ejemplo, en una ubicación/disposición de procesamiento de transacción. La ID de comprador, la ID de vendedor y la ID de transacción se asocian en una base de datos, que enlace las ID del comprador y vendedor con la transacción a la cual se asigna la ID de transacción. En el bloque 320, la información de facturación para una porción de la transacción realizada por un vendedor se recibe con la ID del vendedor y la ID de transacción. La información de facturación se comunica utilizando, por ejemplo, una factura electrónica enviada mediante una red de comunicación a un nodo de procesamiento de transacción en la red de comunicación. Si la ID del vendedor no concuerda con una ID de comprador asociada con la transacción a la cual se asigna la ID de transacción en el bloque 330, una respuesta incorrecta de la ID del vendedor y/o transacción se genera en el bloque 335. La respuesta incorrecta de la ID de vendedor y/o transacción puede incluir, por ejemplo, una o más de notificar al vendedor que proporciona la información de facturación que la correlación falló, notificar a un comprador en la transacción que la correlación falló o resolver el problema. Una ID de vendedor mal correlacionada puede resolverse, por ejemplo, por la comparación de la ID de vendedor recibida con las ID de vendedor conocidas para la transacción y asociar la ID de vendedor recibida con una ID de vendedor conocida utilizando una tolerancia tipográfica u otro procedimiento. Si la ID de vendedor concuerda con una ID de vendedor asociada con los datos de transacción (es decir, con la ID de transacción) en el bloque 330, los términos de contrato para la transacción particular asociada con la ID de transacción se recuperan en el bloque 340. En el bloque 350, el vendedor asociado con la ID de vendedor se le paga como una función de los términos de contrato por la transacción particular asociada con la ID de transacción. Este procedimiento en los bloques 340 y 350 puede involucrar, por ejemplo, recuperar términos de contrato de una base de datos, almacenados bajo la ID de transacción y autorizar o de otra forma facilitar el pago para la transacción basándose en los términos de contrato y la información de facturación recibida. En algunos casos, la información de facturación se audita en el bloque 350 como parte del proceso de pago, con el pago autorizado o facilitado como una función de la auditoria (es decir, cuando la información de facturación es consistente con y/o dentro del margen de información de facturación esperada o aceptable, el pago se autoriza). Cuando el vendedor se le ha pagado en el bloque 350, los datos de pago que indican el pago para la transacción de acuerdo con la información de facturación se almacena en el bloque 360. En algunos casos, estos datos de pago se almacenan con la información de facturación recibida. Después de que los datos de pago se han almacenado en el bloque 360, o después de que se genera una respuesta incorrecta de ID de vendedor y/o de transacción en el bloque 335, los datos de pago almacenados se analizan para determinar, en el bloque 370, si todos los vendedores para la transacción se les ha pagado. Si a todos los vendedores para una transacción particular de hecho se les ha pagado, el proceso se detiene en el bloque 380. Si a todos los vendedores para una transacción particular no se les ha pagado, el proceso continúa en el bloque 320 cuando los vendedores adicionales pres90ntan la información de facturación. Mientras ciertos aspectos de la presente invención se han descrito con referencia a varias modalidades ejemplares particulares, aquellos con experiencia en la técnica reconocerán que muchos cambios pueden hacerse a la misma sin apartarse del espíritu y alcance de la presente invención, de la cual aspectos se establecen en las siguientes reivindicaciones.

Claims (26)

1. REIVINDICACIONES 1. Una disposición de transacción automatizada caracterizada porque comprende: una disposición de almacenamiento de datos se adapta para almacenar datos de contrato para partes en una transacción, los datos de contrato incluyen un identificador de transacción (ID) e información que se refiere a un contrato para el intercambio de ofertas mercantiles e involucra una parte compradora y por lo menos dos partes proveedoras, cada parte proveedora realiza una sub-parte del contrato; y un procesador de transacción automática configurado y dispuesto para recibir información de pedido que incluye la información de ID de transacción de la parte compradora, la información de pedido que incluye identificación y cantidades de ofertas mercantiles que el comprador desea comprar así como una cantidad monetaria que el comprador espera pagar por las ofertas mercantiles, recibir información de solicitud de pago que incluye información de ID de transacción de las partes proveedoras, la información de solicitud de pago que refleja las características de pago de la transacción relacionada con las ofertas mercantiles proporcionadas mediante la parte proveedora que proporciona la información de solicitud de pago, auditar la información de solicitud de pago a partir de cada parte proveedora contra los datos del contrato almacenados asociados con la ID de transacción en la información de solicitud de pago y contra la información de pedido recibida que incluye la ID de transacción, la auditoria que determina una condición de autorización de pago para la información de solicitud de pago, y en respuesta a la condición determinada de la autorización de pago que indica que es apropiado el pago para una parte proveedora que proporciona la solicitud de pago auditada, facilita el procesamiento de liquidación de la solicitud de pago como una función de la solicitud de pago y una sub-parte de un contrato para el cual aplica la solicitud de pago.
2. 2. La disposición de conformidad con la reivindicación 1, caracterizada porque el procesador de transacción automática además se configura y dispone para evaluar una comisión para facilitar la liquidación como una función de por lo menos uno de: la información de solicitud de pago, los datos de contrato y los datos de comisiones asignados por lo menos a una de las partes en la transacción con la cual se facilita la liquidación.
3. 3. La disposición de conformidad con la reivindicación 1, caracterizada porque el procesador de transacción automática facilita el procesamiento de liquidación al procesar el pago del comprador a cada uno de por lo menos dos proveedores como una función de la información de solicitud de pago reciba de cada proveedor y de las sub-partes del contrato que realiza cada proveedor respectivamente .
4. 4. La disposición de conformidad con la reivindicación 3, caracterizada porque el procesador de transacción automática se configura y dispone para facilitar el procesamiento de liquidación al procesar el pago del comprador a cada uno de por lo menos dos proveedores como una función de información de solicitud de pago recibida en diferentes momentos a partir de cada proveedor y de las sub-partes del contrato que realiza cada proveedor respectivamente.
5. 5. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar, para cada parte de transacción, los datos de perfil que incluyen información de procesamiento financiero, y donde el procesador de transacción automática facilita el procesamiento de liquidación para una transacción al transferir los fondos del comprador a un proveedor como una función de los datos de perfil para el comprador y para el proveedor.
6. 6. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar datos de contrato para una transacción de transporte que involucra una parte compradora que compra los servicios del transportador de las partes proveedoras que suministran los servicios del transportador, la transacción de transporte se le asigna una ID de transacción particular, y donde el procesador de transacción automática se configura y dispone, para cada proveedor, para facilitar el procesamiento de liquidación de las solicitudes de pago recibidas del proveedor para una subparte de una ruta del transportador recibida por el proveedor.
7. 7. La disposición de conformidad con la reivindicación 6, caracterizada porque el procesador de transacción automática además se configura y dispone para auditar la información de solicitud de pago al comparar una cantidad de pago en la información de solicitud de pago con una cantidad de pago en una sub-parte del contrato que pertenece al proveedor y a la ID de transacción, y para facilitar el pago al transportador por sus servicios de transportador como una función de la auditoria de información de solicitud de pago.
8. 8. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar datos de contrato para una transacción para productos que involucran una parte compradora que compra un monto de productos de las partes proveedoras que suministran respectivamente porciones del monto, la transacción de productos que se asigna una ID de transacción particular, y donde el procesador de transacción automática se configura y dispone, para cada proveedor, para: recibir y procesar la información de solicitud de pago que incluye la ID de transacción y el costo de los productos proporcionados por el proveedor; y facilitar el procesamiento de liquidación de la solicitud de pago al ofertar el pago al proveedor por sus productos proporcionados de acuerdo con la solicitud de pago y una sub-parte de un contrato para el cual aplica la solicitud de pago.
9. 9. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar datos de contrato para múltiples ofertas mercantiles en un contrato particular, cada una de las ofertas mercantiles se refiere con una ID de transacción común, donde diferentes proveedores realizan las sub-partes en el contrato para las ofertas mercantiles bajo la ID de transacción común y donde el procesador de transacción automática se configura y dispone para facilitar el procesamiento de liquidación de las sub-partes en el contrato como una función de la información de solicitud de pago de la parte proveedora particular que proporciona la ofertas mercantiles y la sub-parte del contrato que se refiere a las ofertas mercantiles proporcionadas .
10. 10. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar datos de contrato financiero para partes en una transacción financiera que involucra un comprador que financia una transacción utilizando un grupo de fondos proporcionados por al menos dos proveedores financieros, cada uno de los proveedores financieros proporciona una porción del grupo de fondos como se específica en los datos de contrato almacenados, y donde el procesador de transacción automática se adapta para facilitar el procesamiento de liquidación de una sub-parte del contrato que involucra fondos proporcionados por un proveedor financiero de acuerdo con los datos de contrato almacenados.
11. 11. La disposición de conformidad con la reivindicación 10, caracterizada porque por lo menos dos proveedores financieros incluyen proveedores financieros que suministran fondos en diferentes divisas, donde una sub-parte de la transacción financiera servida por un proveedor financiero involucra el pago en una divisa y otra sub-parte de la transacción financiera servida por un proveedor financiero diferente que involucra el pago en otra divisa.
12. 12. La disposición de conformidad con la reivindicación 10, caracterizada porque la disposición de almacenamiento de datos almacena parámetros pre-definidos para los proveedores financieros, los parámetros predefinidos especifican características de transacciones para las cuales cada proveedor financiero suministrará fondos para el grupo de fondos, y donde el procesador de transacción automática facilita el procesamiento de liquidación para una porción del grupo de fondos como una función de los parámetros pre-definidos almacenados para el proveedor financiero particular.
13. 13. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar datos de contrato para partes en una transacción que involucran la parte compradora, por lo menos una de las partes proveedoras y una parte intermediaria, la información de contrato incluye datos de contrato para contratos entre la parte compradora y la parte intermediaria y entre la parte intermediaria y por lo menos una parte proveedora, donde el procesador de transacción automática se configura y dispone para facilitar el procesamiento de liquidación de una sub-parte del contrato al proporcionar fondos por lo menos a una parte proveedora directamente de la parte compradora como una función del contrato entre la parte intermediaria y por lo menos una parte proveedora.
14. 14. La disposición de conformidad con la reivindicación 13, caracterizada porque la disposición de almacenamiento de datos se adapta para almacenar datos de contrato para partes en la transacción que involucran por lo menos dos partes proveedoras, la información de contrato que incluye datos de contrato para contratos entre la parte intermediaria y por lo menos dos partes proveedoras, donde el procesador de transacción automática se configura y dispone para facilitar el procesamiento de liquidación de sub-parte del contrato al proporcionar fondos respectivamente a cada una de las partes proveedoras directamente de la parte compradora como una función de los contratos entre la parte intermediaria y la parte proveedora respectiva.
15. 15. La disposición de conformidad con la reivindicación 1, caracterizada porque el procesador de transacción automática además se configura y dispone para auditar la información de solicitud de pago al comparar la información de solicitud de pago con los términos de pago en la información de contrato almacenada y, en respuesta a la información de solicitud de pago que satisface los términos de pago en la información de contrato almacenada, para autorizar el pago para la solicitud de pago.
16. 16. La disposición de conformidad con la reivindicación 1, caracterizada porque la disposición de transacción automatizada utiliza la información de perfil de parte de transacción para autorizar las partes de transacción y proporcionar acceso a la información de contrato almacenada para las transacciones en las cuales participan las partes de transacción autorizadas.
17. 17. Una disposición de transacción automatizada caracterizada porque comprende: medios para almacenar datos de contrato para partes en una transacción, los datos de contrato incluyen un identificador de transacción (ID) e información que refiere a un contrato para el intercambio de ofertas mercantiles e involucra una parte compradora y por lo menos dos partes proveedoras, cada parte proveedora realiza una sub-parte del contrato; medios de recepción para recibir información de pedido que incluye información de ID de transacción de la parte compradora, la información de pedido que incluye identificación y cantidad desde las ofertas mercantiles que el comprador desea comprar así como una cantidad monetaria que el comprador espera pagar por las ofertas mercantiles; medios de comunicación para recibir información de solicitud de pago que incluye información de ID de transacción de las partes proveedoras, la información de solicitud de pago que refleja las características de pago de la transacción relacionada con las ofertas mercantiles proporcionadas mediante la parte proveedora que proporciona la información de solicitud de pago; medios de auditoria para auditar la información de solicitud de pago de cada parte proveedora contra los datos de contrato almacenados asociados con la ID de transacción en la información de solicitud de pago y contra la información de pedido recibida que incluye la ID de transacción, el medio de auditoria determina una condición de la autorización de pago para la información de solicitud de pago; y medios de liquidación, en respuesta a la condición determinada de la autorización de pago, para facilitar el procesamiento de liquidación de la solicitud de pago como una función de la solicitud de pago y una sub-parte del contrato al cual aplica la solicitud de pago.
18. 18. La disposición de conformidad con la reivindicación 17, caracterizada porque el medio para almacenar datos de contrato se adapta para almacenar información que se refiere a un contrato que involucra el intercambio de ofertas mercantiles entre una parte compradora y por lo menos dos partes proveedoras, cada una de por lo menos dos partes proveedoras realiza una sub-parte del contrato, donde el medio de comunicación se adapta para recibir información de solicitud de pago que incluye una ID de transacción de por lo menos dos partes proveedoras, y donde el medio de auditoria se adapta para auditar la información de solicitud de pago de por lo menos dos partes proveedoras como una función de una comparación de la ID de transacción en la información de solicitud de pago con la ID de transacción almacenada en los datos del contrato.
19. 19. Un método implementado por procesador para procesar transacciones comerciales que involucran por lo menos un proveedor, el método caracterizado porque comprende: almacenar datos de contrato para partes en una transacción, los datos de contrato incluyen una identificación de transacción (ID) e información que se refiere a un contrato que involucra el intercambio de ofertas mercantiles entre una parte compradora y por lo menos una parte proveedora, cada parte proveedora realiza una sub-parte del contrato; recibir información de solicitud de pago que incluye una ID de transacción de por lo menos una parte proveedora, la información de solicitud de pago refleja las características de pago de la transacción relacionada con las ofertas mercantiles proporcionadas por la parte proveedora que proporciona la información de solicitud de pago; auditar la información de solicitud de pago de por lo menos una parte proveedora como una función de una comparación de la información de solicitud de pago con los datos de contrato almacenados asociados con la ID de transacción y determinar por consiguiente una condición de autorización de pago para la información de solicitud de pago; y facilitar la liquidación de una sub-parte del contrato que involucra ofertas mercantiles proporcionadas por la parte proveedora particular como una función de la información de solicitud de pago de la parte proveedora particular y la condición determinada de la autorización de pago .
20. 20. Un método implementado por procesador para procesar transacciones comerciales que involucran por lo menos un proveedor, el método caracterizado porque comprende: almacenar datos de contrato para partes en una transacción, los datos de contrato incluyen una identificación de transacción (ID) e información que se refiere a un contrato que involucra el intercambio de ofertas mercantiles entre una parte compradora y por lo menos dos partes proveedoras, cada parte proveedora realiza una subparte del contrato; recibir información de solicitud de pago que incluye una ID de transacción de por lo menos dos partes proveedoras, la información de solicitud de pago que refleja las características de pago de la transacción relacionada con las ofertas mercantiles proporcionadas por la parte proveedora que proporciona la información de solicitud de pago; auditar la información de solicitud de pago de cada parte proveedora como una función de una comparación de la ID de transacción en la información de solicitud de pago con la ID de transacción almacenada en los datos de contrato; y en respuesta a la ID de transacción en la información de solicitud de pago de una parte proveedora particular que correlaciona la ID de transacción en los datos de contrato, facilita la liquidación de una sub-parte del contrato que involucra ofertas mercantiles proporcionadas por la parte proveedora particular como una función de la información de solicitud de pago de la parte proveedora particular y la sub-parte del contrato.
21. 21. El método de conformidad con la reivindicación 20, caracterizado porque auditar la información de solicitud de pago de cada parte proveedora incluye comparar una cantidad y un monto monetario de ofertas mercantiles especificadas por la información de solicitud de pago con los datos de contrato almacenados y autorizar el pago por la red de solicitud de pago en respuesta a la cantidad y monto monetario de las ofertas mercantiles que concuerdan con la cantidad correspondiente y la información del monto monetario para la ID de transacción en los datos de contrato almacenados .
22. 22. El método de conformidad con la reivindicación 20, caracterizado porque almacenar los datos de contrato incluye almacenar datos para un contrato que se lleva a cabo en sub-partes con el tiempo, cada sub-parte se lleva a cabo en un tiempo diferente, donde recibir la información de solicitud de pago incluye recibir información de solicitud de pago de diferentes partes proveedoras en diferentes momentos para diferentes sub-partes del contrato.
23. 23. El método de conformidad con la reivindicación 20, caracterizado porque almacenar datos del contrato incluye almacenar datos para un contrato que tiene múltiples elementos de línea que se realizan por diferentes partes proveedoras, donde recibir información de solicitud de pago incluye recibir información de solicitud de pago de diferentes partes proveedoras en diferentes momentos para diferentes elementos de línea del contrato.
24. 24. El método de conformidad con la reivindicación 20, caracterizado porque facilitar la liquidación de una sub-parte del contrato que involucra ofertas mercantiles proporcionadas por la parte proveedora particular como una función de la información de solicitud de pago de la parte proveedora particular y la sub-parte del contrato incluye pagar a la parte proveedora particular en respuesta a la información de solicitud de pago que concuerda con la información de pago en la sub-parte almacenada del contrato.
25. 25. El método de conformidad con la reivindicación 20, caracterizado porque facilitar la liquidación de una subparte del contrato que involucra objetos mercantiles proporcionadas por la parte proveedora particular como una función de la información de solicitud de pago de la parte proveedora particular y la sub-parte del contrato incluye evaluar una comisión por procesamiento para por lo menos una de las partes en la sub-parte del contrato.
26. 26. El método de conformidad con la reivindicación 20, caracterizado además porque comprende programar un procesador para auditar la información de solicitud de pago y para responder a la ID de transacción en una información de solicitud de pago de una parte proveedora particular que concuerda la ID de transacción en los datos de contrato al facilitar la liquidación de una sub-parte del contrato que involucra ofertas mercantiles proporcionadas por la parte proveedora particular como una función de la información de solicitud de pago de la parte proveedora particular y la sub-parte del contrato.