MXPA06014350A - Sistema y procedimiento de ejecucion y administracion de pedidos-recursos. - Google Patents

Abstract

Se utilizan datos historicos para administrar y autorizar pago para ofertas mercantes para transacciones entre una pluralidad de participantes de transaccion. De acuerdo con una modalidad ejemplar de la presente invencion, cantidades de articulos facturados se procesan utilizando cantidades historicas ejecutadas y facturadas de cada articulo. Si articulos involucrados son cantidades de articulos facturados que se han ejecutado pero no se han facturado, se autoriza el pago por los articulos facturados. Si algunos o todos los articulos facturados no se han ejecutado o se han facturado previamente, la autorizacion de pago se retiene por lo menos la porcion de articulos facturados no ejecutados o previamente facturados (y pagados). Con este procedimiento, la informacion historica con relacion al estado de ejecucion de pedido y pago se utiliza para procesar automaticamente facturas (por ejemplo, auditar las facturas para pago).

Description

SISTEMA Y PROCEDIMIENTO DE EJECUCIÓN Y ADMINISTRACIÓN DE PEDIDOS-RECURSOS DESCRIPCIÓN DE LA INVENCIÓN La presente invención se dirige a procesamiento de transacción y, más específicamente, al procesamiento y administración de interacciones que se relacionan con transacciones que involucran productos y/o servicios. El procesamiento de transacción típicamente ha involucrado un esfuerzo manual intensivo y, en casos donde se ha utilizado procesamiento automático, intervención intensiva del usuario. Por ejemplo, procesos de transacción involucran el uso de una variedad de documentos de transacción tales como pedidos, facturas, recibos y conocimientos de carga (BOL) . Estos tipos de documentos de transacción incluyen información asociada con la transacción que se utiliza por participantes de la transacción para vigilar y procesar la transacción. Los documentos de transacción se procesan electrónicamente para una pluralidad de diferentes tipos de aplicaciones. Los datos de interacción {por ej emplo, documentos electrónicos o físicos) que describen las características de una interacción de transacción particular con frecuencia se encuentran en orden temporal variado en ubicaciones de transacción centrales que ensamblan estos documentos en paquetes lógicos para procesamiento automatizado. Por ejemplo, cuando una transacción involucra la venta de un producto de un vendedor a un comprador, existen con frecuencia múltiples participantes de la transacción además del comprador y vendedor, tal como transportistas, instituciones financieras, distribuidores y organismos normativos {por ej emplo, aduanas, organismos de tributación) . Cada uno de estos participantes con frecuencia proporciona uno o más diferentes tipos de documentos que se refieren a la transacción. Con frecuencia los documentos no están en un formato que se pueda discernir fácilmente con relación a los documentos de otros participantes, que requieren un esfuerzo extensivo para organizar los documentos en categorías o transacciones. Una variedad de transacciones son particularmente susceptibles a dificultades de procesamiento tales como aquéllas que se refieren a identificación y categorización de documentos. Por ejemplo, reconciliación de pre-pago y auditoria para una transacción particular con frecuencia se llevan a cabo automáticamente en forma electrónica en un procesador central. Los documentos utilizados para estas funciones pueden llegar al procesador central ya sea en una forma inoportuna o un formato que es inadecuado para identificación y categorización de los documentos en transacciones particulares. Como otro ejemplo, un documento de despacho aduanal que se refiere a una factura particular puede llegar a un procesador central antes de la factura, lo cual puede también llegar antes de que llegue el pedido verdadero. Sin una factura para unir el documento de despacho aduanal, el procesador central tiene dificultad para administrar el documento. Similarmente, sin una orden para atribuir una factura a, el procesador central puede ser incapaz de procesar la factura (por ej emplo, es incapaz de auditar la factura contra el pedido) . Otro tipo de incompatibilidad que ha hecho difícil el procesamiento de transacción se refiere al escenario común donde números de referencia utilizados por diferentes participantes para identificar una transacción particular no son compatibles. Por ejemplo, en transacciones que involucran compradores y vendedores, los vendedores mantienen los datos de transacción organizados por números de referencia generados por el vendedor. Los compradores típicamente deben acceder a los datos utilizando un número de referencia del vendedor en lugar del número de referencia del comprador. Además, compradores y vendedores tipicamente utilizan diferentes números de referencia para diferentes características de la transacción, que hacen difícil la vigilancia y administración de la transacción. Cuando más y más documentos se requieren para articular completamente las interacciones, este problema de administrar documentos y otros datos de interacción y, en particular, de correlacionar documentos y otros datos de interacción con una transacción adecuada, se vuelve cada vez más un reto. El análisis a fondo manual y categorización de estos documentos es costoso, exige mucho tiempo y es susceptible a error. Procedimientos automatizados previamente disponibles generalmente se limitan en aplicabilidad a ciertos tipos de documentos o ciertos métodos inflexibles de identificación y categorización de documentos. Aspectos relacionados con el pago y facturación de transacciones tradicionales particularmente son susceptibles a errores y fraude de facturación. Por ejemplo, con frecuencia existe poca a ninguna conexión entre la distribución de productos y la facturación para la distribución y/o los productos. Este puede resultar en doble facturación, ninguna facturación en absoluto, o sobrefacturación . Errores de auditoría que provocan una facturación incorrecta o pago también pueden ocurrir. Además, el pago con frecuencia es demorado mientras aspectos de una transacción particular están siendo auditados y/o disputados, particularmente cuando diferentes documentos de transacción deben analizarse a fondo y procesarse manualmente. Por ejemplo, documentos de diferentes participantes de una transacción con frecuencia deben analizarse a fondo y compararse para relacionar datos de un documento a otro en una forma que facilitará la facturación. La demora asociada con la facturación reduce los recursos de capital de trabajo para participantes de la transacción que esperan el pago. Costos adicionales surgen como resultado de ineficiencias existentes en una variedad de procedimientos de procesamiento de transacción. Muchos de los costos son individualmente pequeños pero muy grandes en conjunto. Por ejemplo, participantes típicos de transacciones incurren en costos administrativos que incluyen aquellos que se refieren a los costos para crear y distribuir documentos de transacción, resolver disputas de facturación, proporcionar una copia firmada de documentos a otros participantes y transferir cuentas por cobrar. Además, el costo de analizar a fondo, reconocer y categorizar documentos relacionados a estos y otros elementos se agregan a los costos administrativos de las transacciones. Un reto adicional a la administración de transacción involucra la incapacidad de obtener información inmediata con respecto a una transacción. Los datos de transacción de un participante tipicamente no están fácilmente disponibles para otros participantes involucrados con la transacción sin un acceso directo a los sistemas privados del participante. Puesto que proceso se lleva a cabo mayormente en forma manual, es muy difícil seguir una transacción y los datos en tiempo real son particularmente difíciles de conseguir. Por ejemplo, existen varias etapas manuales para aprender del estado de envió o pago. Si un transportista desea saber si un buque transportador distribuyó los productos para una transacción particular y si el pago se ha hecho, el transportista con frecuencia debe contactar al buque transportador y/o a la institución financiera apropiada. Lo anterior y otras dificultades en la administración y coordinación de transacciones han presentado retos para la administración efectiva y eficiente de transacciones. La presente invención se dirige a solucionar los retos antes mencionados y otros relacionados a los tipos de procedimientos e implementaciones discutidas en lo anterior y en otras aplicaciones. La presente invención se ejemplifica en un número de implementaciones y aplicaciones, de las cuales algunas se resumen en lo siguiente. De acuerdo con una modalidad ejemplar de la presente invención, las interacciones se administran utilizando un procedimiento que involucra generalmente el uso de criterios de estado de transacción para procesar aspectos relacionados con el pago de las interacciones. En una modalidad ejemplar más particular de la presente invención, las condiciones de estado de interacción relacionadas a la ejecución de pedido y los pagos relacionados se vigilan y/o procesan cuando se reciben.

Cuando ocurren cambios para la ejecución de pedido y/o pagos relacionados y/o cuando se recibe una nueva ejecución de pedido e información de pago, estos cambios se utilizan para actualizar automáticamente las condiciones de estado. Las condiciones de estado actualizadas se implementan para uno o más de una variedad de procedimientos de procesamiento y administración de transacciones. En otra modalidad ejemplar de la presente invención, un sistema de procesamiento de transacción se adapta para administrar recursos de pago para transacciones gue involucran ofertas mercantes entre participantes que incluyen compradores y vendedores. El sistema incluye una disposición de almacenamiento de datos, que incluye uno o más dispositivos de almacenamiento de datos en una o más ubicaciones, adaptadas para almacenar la información relacionada con el pedido para una transacción entre un comprador y un vendedor. Con frecuencia, la información relacionada con el pedido incluye datos en campos asociados con cantidades históricas de ejecución y facturadas para artículos pedidos de la transacción. Una disposición de computadora (por ej emplo, de procesamiento) se adapta, para un artículo pedido particular, para comparar la información de cantidad facturada en una factura entrante con información histórica de ejecución y cantidad facturada para el artículo pedido en la disposición de almacenamiento de datos. Si la cantidad facturada sobre la factura entrante no es mayor que la diferencia entre la información histórica de la cantidad de ejecución y la cantidad facturada para el artículo pedido en la disposición de almacenamiento de datos, se autoriza el pago de la factura. Junto con la autorización, las cantidades históricas facturadas para el articulo pedido se actualizan en la disposición de almacenamiento de datos para incluir la cantidad facturada en la factura entrante. 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 las diversas modalidades de la invención junto con los dibujos anexos en los cuales: la FIGURA 1 muestra una disposición de procesamiento de transacción, de acuerdo con una modalidad ejemplar de la presente invención; la FIGURA 2A es un diagrama de flujo para un procedimiento de vigilancia de transacción, de acuerdo con otra modalidad ejemplar de la presente invención; la FIGURA 2B es otro diagrama de flujo para un procedimiento de vigilancia de transacción de acuerdo con otra modalidad ejemplar de la presente invención; la FIGURA 3 es otro diagrama de flujo, relacionado al diagrama de flujo mostrado en la FIGURA 2A, para un procedimiento para categorizar datos como una función de un anclaje y datos vigilados almacenados en las ubicaciones de anclaje con actualización automática de los datos de procesamiento de transacción, de acuerdo con otra modalidad ejemplar de la presente invención; y la FIGURA 4 muestra una disposición para procesar reclamaciones para una pluralidad de transacciones, de acuerdo con otra modalidad ejemplar de la presente invención. Aunque la invención se somete a varias modificaciones y formas alternativas, especificaciones de la misma se han mostrado por medio del ejemplo en los dibujos y se describirán en detalle. Se 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 procedimientos e interacciones de transacción, y se ha encontrado que es particularmente útil para aplicaciones que involucran el procesamiento de transacciones y aspectos relacionados de las mismas. Aunque 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, las interacciones de transacción se administran utilizando procedimientos que facilitan la vigilancia de las condiciones de estado de interacción relacionadas con la ejecución de pedido y los pagos relacionados. La administración involucra una variedad de características y puede adaptarse para implementaciones específicas. Por ejemplo, donde participantes de una transacción convienen con ciertas reglas comerciales, las interacciones de transacción se administran como una función de las reglas comerciales. Las reglas comerciales que se refieren a la distribución, precio, pago y otras características se implementan fácilmente de esta forma para administrar automáticamente uno o más de una variedad de aspectos de interacciones de transacción. Cuando ocurren cambios para la ejecución de pedido y/o los pagos relacionados, esos cambios se utilizan para actualizar automáticamente las condiciones de estado. En una implementación, los recursos disponibles para procesar facturas para una transacción particular {por ejemplo, pedido exprés o implicado o contrato) se vigilan. Cuando recursos no facturados están disponibles, esos recursos se identifican como aquéllos a los cuales pueden hacerse el pago. Por ejemplo, cuando se recibe una factura por una cantidad particular de productos y/o servicios, es útil comparar la cantidad facturada con la cantidad recibida para determinar si debe hacerse el pago. Este procedimiento puede utilizarse por ejemplo, para asegurar que el recibo de productos/servicios se haga antes del pago, y/o para asegurar que una cantidad suficiente se haya recibido que garantice el pago (por ejemplo, donde el pago se efectúa solamente cuando una cantidad umbral se ha distribuido o facturado) . Además, después de que se crea una factura para un pedido, es útil comparar la factura contra las facturas subsiguientes para asegurar que el pago no se ha hecho ya para los artículos listados. Por ejemplo, puede hacerse una comparación para determinar si la suma de las cantidades facturadas sobre facturas previas es menor que las cantidades ejecutadas (y donde el pago se hace subsiguientemente si la suma de cantidades previamente facturadas es menor que las cantidades ejecutadas). Con este procedimiento, el estado de ejecución de un pedido está disponible para procesar documentos tales como facturas, facilitar la capacidad de determinar, por ejemplo, características que se refieren a la cantidad de productos o el pago de los mismos.

En algunos casos, se utilizan otras condiciones que se refieren a la distribución de productos y/o servicios, además de los datos históricos de ejecución y entrega, para facilitar el pago para las transacciones. Por ejemplo, donde los participantes de transacción están de acuerdo con los términos relacionados con el pago que se unen al tiempo de rendimiento (por ej emplo, productos y/o servicios que se distribuyen dentro de un periodo de tiempo particular) , el pago por cantidades ejecutadas en una forma puntual se autoriza de acuerdo con los términos de pago acordados para una ejecución a tiempo. Correspondientemente, el pago por cantidades ejecutadas en una forma inoportuna se autoriza de acuerdo con los términos de pago acordados para la ejecución que no está a tiempo. En ciertas aplicaciones, los datos históricos de ejecución se actualizan como una función de la condición de productos y/o servicios al momento del cumplimiento; donde una condición de ciertos artículos es aceptable mientras la condición de otros artículos es inaceptable, los datos históricos de ejecución se actualizan para reflejar la cantidad de artículos aceptables. Cuando se autoriza el pago como una función de las cantidades históricas de ejecución, estas cantidades de ejecución reflejan la condición de los artículos. Una variedad de interacciones puede vigilarse y administrarse utilizando esos procedimientos, con aspectos de la administración que se refieren a las interacciones establecidas entre diferentes participantes de una transacción. Los cambios hechos a los datos de interacción desde una fuente particular se vigilan y, cuando es apropiado, se utilizan para actualizar los datos de interacción desde y/o en otras fuentes. Por ejemplo, los documentos basados en transacción que aplican una transacción común pueden vigilarse de esta forma, con una actualización para un documento y/o un campo de datos siendo utilizada para hacer actualizaciones correspondientes para uno u otros documentos más y/o campos de datos para la misma transacción común, o para diferentes transacciones que pertenecen a un participante particular de las transacciones. Tal ejemplo involucra la vigilancia de los campos de estado gue se refieren a los pedidos; cuando un campo particular tal como aguél que refleja una cantidad recibida se actualiza, puede hacerse una actualización correspondiente en los campos relacionados. Este procedimiento es aplicable por ejemplo, a campos relacionados tales como cantidad pagable, precio extendido, cargo por servicio, campos de tributación y totales . En una implementación, los campos de datos relacionados y/o documentos como se discute en lo anterior se vinculan automáticamente para una transacción particular, en una forma proporcionada con un participante de transacción al cual aplican los campos de datos relacionados. En un ejemplo, donde una transacción entre un comprador y un vendedor especifica una cantidad distribuida de un producto particular, los campos de datos de transacción almacenados a nombre de cada uno del comprador y el vendedor, que especifican lo distribuido se vinculan automáticamente. En este respecto, cuando el comprador recibe productos y actualiza su campo de datos de cantidad distribuida para indicar el recibo, una actualización correspondiente se hace para el campo de datos de cantidad distribuida del vendedor para reflejar el recibo confirmado por el comprador. Muchos enlaces se implementan selectivamente, a discreción de los participantes de cada transacción particular y, en algunas aplicaciones, cuando se puede aplicar a un administrador que facilita el procesamiento de transacción a nombre de los compradores y vendedores. En otra implementación, las reglas comerciales se utilizan para administrar la ejecución de pedido para una o más transacciones. Cuando se establece un grupo de transacción particular, por ejemplo que utiliza una ubicación de almacenamiento particular ID asociada para la ubicación para almacenar los documentos, el grupo de transacción se vigila para los campos de datos asociados con la ejecución. Cuando se reciben nuevos datos de ejecución y/o cuando se alteran datos existentes de ejecución, los datos de ejecución se utilizan para procesar automáticamente una función relacionada. Por ejemplo, cuando sigue un aviso {por ejemplo, recibo de pedido) que indica que se ha ejecutado un pedido, campos de datos correspondientes en otros documentos se actualizan por consiguiente. Cualquier respuesta dictada por las reglas comerciales, tal como la ejecución del pago para el pedido ejecutado, entonces de ejecuta. Para la información general con respecto a transacciones y para información específica con respecto a transacciones y el uso de una ubicación de almacenamiento (por ejemplo, anclaje) a la cual pueden aplicar una o más modalidades ejemplares discutidas en la presente, puede hacer referencia la Solicitud de Patente Norteamericana No. de Serie 10/864,761 (USBA.120PA) titulada "Sistema y Procedimiento de Procesamiento de Transacción Automatizado", presentada el 9 de junio de 2004 y completamente incorporada en la presente para referencia. Con referencia ahora a la FIGURA 1, una disposición 100 de procesamiento de transacción se adapta para vigilar y procesar automáticamente datos de transacción, de acuerdo con otra modalidad ejemplar de la presente invención. La disposición 100 de procesamiento de transacción incluye un nodo 110 de transacción central que es una ubicación central para la comunicación y procesamiento de los datos relacionados con la transacción. El nodo 110 de transacción central está en comunicación con una base de datos 112 donde se almacena la información relacionada con la transacción. La base de datos 112 se muestra acoplada al nodo 110 de transacción central; sin embargo, en varias implementaciones, parte o toda la base de datos es parte del nodo de transacción central, se localiza en una ubicación remota y/o incluye una pluralidad de circuitos de almacenamiento de datos en diferentes ubicaciones. Una pluralidad de nodos 120, 122, 124, 126 y 128 de usuario se acopla comunicativamente con el nodo 110 de transacción central. Los nodos 120-128 de usuario por ejemplo, pueden incluir uno o más de un comprador, vendedor, distribuidor, transportista, buque transportador, organismo aduanal, organismo de seguridad nacional, institución financiera u otro tipo de individuo, grupo u organismo que pueda involucrarse tipicamente en una transacción. Estos nodos de usuario pueden interactuar con el nodo 110 de transacción central para proporcionar información relacionada con la transacción, tales como pedidos, facturas, documentos de embarque, autorización de pago, ejecución de pago, documentos aduanales, documentos de seguridad y otros que se almacenan en la base de datos 112. Esta información relacionada con la transacción, que incluye cambios a la misma, se vigila y procesa por el nodo 110 de transacción central utilizando atributos comunes para actualizar automáticamente información para una transacción particular.

Por ejemplo, cuando se almacenan datos de transacción en la base de datos 112, identifica un estado de ejecución de un pedido para una transacción particular, el estado de ejecución se procesa y utiliza para promover la transacción a la cual aplican los datos de transacción. Donde este estado de ejecución se puede aplicar a más de un campo y/o documento (es decir, un campo de cantidad recibida se puede aplicar a un campo de cantidad pagable) , los campos relacionados se actualizan por consiguiente en respuesta a uno de los campos que se cambia. En una implementación, la información relacionada con la transacción se analiza a fondo y agrupa por el nodo 110 de transacción central para almacenarse en la base de datos 112 utilizando atributos comunes para agrupar automáticamente la información de una transacción particular en conjunto, tal como en la Solicitud de Patente Norteamericana No. de Serie 10/864,761, referida en lo anterior. Por ejemplo, los datos de transacción pueden agruparse como una función de categorías tipo anclaje pre-definidas y atributos de perfil de transacción relacionados. Los seleccionados de los atributos de perfil de transacción se utilizan para formar los datos de anclaje que identifica la transacción particular y/o identifican la información para la transacción, tal como el pedido, ejecución o información de participante de transacción. Estas categorías de tipo anclaje pre-definidas se implementan con la base de datos 112 y el nodo 110 de transacción central que vigila las categorías relacionadas; cuando un cambio en una categoría afecta otra categoría, la otra categoría se actualiza por consiguiente. Además, la notificación de tal actualización se envía opcional y automáticamente a uno de los nodos 120-128 de usuario para alertar a los usuarios de la actualización (por ej emplo, para alertar a un usuario de un pago recibido u otra información de tipo transacción) . En una implementación, los datos de anclaje tienen una representación fisica real en la base de datos 112 en una ubicación de anclaje, y de este modo pueden utilizarse para acceder a los documentos almacenados en la base de datos e identificados por el anclaje. En otra implementación, los datos de configuración se utilizan para permitir que participantes de una transacción definan elementos de datos de los documentos que van a utilizarse para relacionar automáticamente los documentos entre a si o para actualizar automáticamente otros documentos. Utilizando estos procedimientos, los datos de anclaje pueden utilizarse efectivamente para difundir criterios que permitirán a transacciones individuales engancharse en una interacción particular representada por una ID de anclaje dada. Además, tales datos de anclaje pueden utilizarse para identificar documentos relacionados para actualizarse en respuesta a cambios en los datos de transacción de otros documentos que tienen la misma ID de anclaje. Estos cambios se pueden aplicar a campos que indican el estado de los recursos tales como cantidades facturadas y/o no facturadas para un pedido particular como con relación a una pluralidad de facturas para ese pedido. En otra implementación, el nodo 110 de transacción central además se adapta para conceder y controlar intercambio de información con la base de datos 112 como una función de las entradas recibidas desde los nodos 120-128, tales como entradas de autorización y entradas específicas de documento. Cuando usuarios en uno de los nodos 120-128 intentan enviar información a o recuperar información del nodo 110 de transacción central, la información de autorización de los usuarios se utiliza para controlar la transferencia de información. La información de autorización puede incluir por ejemplo, información de tipo acceso (por ej emplo, una contraseña o ID de usuario) o simplemente información de documento que reconoce el nodo 110 de transacción central. Cuando el intercambio de información se controla con la información de documento y uno de los nodos 120-128 envia datos de transacción (por ejemplo, un documento electrónico) al nodo 110 de transacción central, la base de datos 112 se analiza a fondo para correlacionar los datos de transacción con la información almacenada. Si se encuentra una correlación, el nodo de transacción central procesa los datos de correlación para determinar si los datos de transacción recibidos pertenecen a la misma transacción que los datos de correlación. Si es así, los datos de transacción recibidos se les asigna una ID de anclaje que pertenece a los datos de correlación y se almacena en la base de datos 112 con la ID de anclaje asignada agrupando los datos de correlación en conjunto. Si se encuentra una correlación pero existen restricciones, el nodo de transacción central procesa los datos recibidos de acuerdo con las reglas de restricción, si las hubiera, programadas para el nodo de transacción central. Por ejemplo, donde se asigna una ID de anclaje para cada pedido y cuando existe un pedido existente en la base de datos 112 conforme a la ID de anclaje de correlación, una nueva ID de anclaje se crea. Los datos de transacción recibidos asi como los datos de correlación que no se restringen se almacenan conforme a la nueva ID de anclaje. Por ejemplo, cuando los datos de facturación de correlación se han encontrado pero la factura incluye más de un pedido, se crea una diferente ID de anclaje para cada pedido, pero incluye la misma factura pero tiene pedidos separados. Estos y otros procedimientos de tipo restrictivo se programan para el nodo de transacción central, dependiendo de la implementación . Cuando se encuentra una correlación, el nodo 110 de transacción central utiliza reglas comerciales para identificar si los datos recibidos garantizan una respuesta, tal como un cambio correspondiente a otros datos relacionados a los datos recibidos o una notificación para uno de los nodos 120-128 de usuario. En este respecto, el nodo 110 de transacción central establece una relación entre ciertos campos de datos en diferentes ubicaciones. Por ejemplo, al utilizar una correlación de uno a uno, los datos en dos ubicaciones pueden mantenerse consistentemente donde ambas ubicaciones identifican los mismos datos o similares, tal como una cantidad de producto pedido, estado de embarque u otro tipo de característica de transacción. Cuando los datos en una de las ubicaciones se actualizan, el valor de esa ubicación también se actualiza en la otra de las ubicaciones. Por ejemplo, como se discute en lo anterior, ciertos tipos de datos recibidos por el nodo 110 de transacción central pueden utilizarse para actualizar correspondientemente otra información que tiene una relación con los datos recibidos. Una vez que tal procedimiento involucra la actualización de un campo de recursos aplicable a productos o cantidades de servicios, asi como la actualización de los campos de pago correspondientes con relación a las cantidades como se discute, por ejemplo, en lo anterior junto con el recibo de múltiples facturas para un pedido particular. En otro ejemplo, se utiliza una función relacional para actualizar automáticamente un campo de datos relacionado. En este ejemplo, cuando los datos en una de las ubicaciones se actualizan, el nodo 110 de transacción central procesa los datos actualizados para generar una actualización en la otra de las ubicaciones donde no existe una correlación de uno a uno. Por ejemplo, cuando un campo de datos particular aplica una cantidad de pedido y otro campo de datos aplica a una cantidad monetaria que representa la cantidad de pedido, se procesa un cambio en la cantidad de pedido para generar un cambio correspondiente en la cantidad monetaria para el pedido. Una pluralidad de tales relaciones puede establecerse y mantenerse por el nodo 110 de transacción central, de los cuales algunos se discuten además en lo siguiente. Con referencia nuevamente a la correlación de los datos recibidos por el nodo de transacción central con los datos almacenados en la base de datos 112, una nueva ID de anclaje se crea selectivamente para los datos de transacción recibidos cuando no se encuentra ninguna correlación entre los datos de transacción recibidos y los datos en la base de datos 112. Esta nueva ID de anclaje, junto con los datos de transacción recibidos se almacena en la base de datos 112 y de este modo establece una nueva transacción. Cuando se reciben subsecuentemente datos de transacción adicionales que correlacionan los datos recién almacenados, el nodo de transacción central procesa los datos de correlación como se discute en lo anterior. En otra implementación, los datos de transacción recibidos en el nodo 110 de transacción central se refieren cruzadamente con los datos de tipo seguridad almacenados en la base de datos 112, antes de utilizar los datos recibidos para actualizar los datos correspondientes. Cuando los datos de transacción correlacionan ciertos criterios controlados por seguridad, la transacción a la cual pertenecen los datos de transacción puede etiquetarse o de otra forma auditarse. Por ejemplo, donde un tipo de identificación de producto concuerda con un tipo de producto que es susceptible al control de seguridad, la transacción puede detenerse para auditar y aprobación por un tercero. Tal aprobación por ejemplo, puede tener también la forma de un documento de transacción que se envía al nodo 110 de transacción central, donde se utiliza la aprobación para promover la transacción (es decir, permitir que los campos correspondientes se actualicen) . Los datos relacionados con la seguridad, recibidos por el nodo 110 de transacción central se vigilan e utilizan para procesar la transacción a la cual aplican, por ejemplo al actualizar un estado de aprobación para una actualización de campo particular para un pedido para el cual se proporciona una factura. Correspondientemente, un campo que representa una aprobación para proceder con una transacción puede actualizarse cuando se recibe la aprobación. Como se discute en lo anterior, la disposición 100 de procesamiento de transacción mostrada en la FIGURA 1 puede implementarse en una variedad de formas para procesar información de transacción. En una implementación particular, la transacción del nodo 110 de transacción central lleva a cabo funciones para dirigir las transacciones de varios niveles que involucran más de dos participantes de transacción. Cada participante interactúa mediante la disposición de procesamiento de transacción, con las transferencias de fondo siendo ejecutadas con todos los participantes de transacción en una variedad de formas, dependiendo de la situación. En una implementación una transacción involucra un distribuidor y otra entidad de nivel medio que facilita una transacción entre un vendedor (o vendedores) y comprador (o compradores) . El distribuidor obtiene productos y/o servicios relacionados con la transacción de uno o más vendedores, y a su vez vende esos productos y/o servicios relacionados con la transacción a los compradores finales. En algunos casos, el distribuidor encuentra compradores para productos que el vendedor está ofreciendo, sin facilitar necesaria y adicionalmente la transacción. En otros casos, el distribuidor funciona en uno o más aspectos para facilitar la transacción, tal como al coordinar y/o efectuar la distribución, almacenar productos y más. Para propósitos de discusión con esta implementación, y con referencia a la FIGURA 1, el nodo 120 de usuario es el nodo de vendedor, el nodo 122 de usuario es el nodo de comprador, el nodo 124 de usuario es el nodo de distribuidor. Cuando el comprador 122 y el distribuidor 124 convienen un precio para la transacción, las reglas comerciales y/u otra información que caracteriza este acuerdo se almacenan en la base de datos 112 para su uso por el nodo 110 de transacción central. El distribuidor 124 también está de acuerdo en un precio con el vendedor 120, con la información por consiguiente siendo almacenada en la base de datos 112. Cuando una transacción que involucra productos y/o servicios proporcionados por el vendedor 120 para el comprador 122 se facilita por el distribuidor 124, el nodo 110 de transacción central utiliza información almacenada a la base de datos 112 para procesar la transacción. Efectivamente, el vendedor 120 consigue ser pagado basándose en su acuerdo con el distribuidor 124, y el comprador 122 consigue ser cargado para la transacción como se detalla por el acuerdo del comprador con el distribuidor 124. Cualquier diferencia neta entre lo que obtiene al pagar el vendedor y lo que paga el comprador se realiza en el distribuidor. Típicamente, este procedimiento involucra que el comprador 122 que paga un precio más alto que lo que se le pago al vendedor y el distribuidor que recibe un reajuste de precio que es la diferencia entre el precio del vendedor y el precio del comprador. Sin embargo, en algunos casos, este procedimiento también puede involucrar que el distribuidor 124 tome una pérdida ( es decir, si el distribuidor se ha contratado con el comprador 122 para un precio particular y el precio del vendedor 120 ha incrementado) . Además, el distribuidor puede agregar valor a la transacción, tal como mediante el envió, aseguramiento, procesamiento u otro servicio; en este respecto, el distribuidor también puede cargar al comprador directamente para estas actividades de valor agregado. Los pagos entre el comprador, vendedor y distribuidor se efectúan mediante el nodo 110 de transacción central, el cual interactúa con las instituciones financieras para transferir fondos. Por ejemplo, el nodo de transacción central puede dirigir automáticamente los fondos de la institución financiera del comprador 122 a la institución financiera del vendedor 120 y la institución financiera del distribuidor 124, basándose en la información almacenada en la base de datos 112. Con este procedimiento, el vendedor 120 puede recibir fondos directamente, en lugar del distribuidor 124, el cual a su vez puede necesitar cobrar del comprador 122. Como se discute en lo anterior, el procedimiento del distribuidor (u otra entidad de nivel medio) además puede involucrar a múltiples compradores y/o múltiples vendedores. Comenzando con los múltiples compradores, y con referencia nuevamente a la FIGURA 1 como un ejemplo, los nodos 120, 122 y 124 se implementan como los nodos del vendedor, comprador y distribuidor como se discute en lo anterior. En este caso, los nodos 126 y 128 son nodos de comprador adicionales. Cuando los tres nodos 122, 126 y 128 de comprador se emplean en transacciones individuales con el nodo 124 de distribuidor para productos que el nodo de distribuidor obtiene mediante el nodo 120 de vendedor, el nodo 110 de transacción central facilita el pago entre los participantes. Por ejemplo, el pago de instituciones financieras para los tres nodos de comprador se lleva a cabo directamente en la institución financiera del nodo 120 de vendedor, con una porción (cargo por reajuste de precio/servicio) de cada pago siendo dirigida a la institución financiera del nodo 124 de distribuidor. Aunque el nodo 120 de vendedor simplemente puede estar realizando un contrato con el nodo 124 de distribuidor, el pago por la transacción puede venir directamente de las múltiples instituciones financieras que dan servicios a los nodos 122, 126 y 128 de comprador. Múltiples vendedores pueden implementarse, similarmente al procedimiento antes discutido con múltiples compradores, para facilitar una sola transacción entre el nodo 124 de distribuidor y el nodo 122 de vendedor. En este caso, los nodos 126 y 128 son nodos de vendedor adicionales. El nodo 124 de distribuidor realiza el contrato individualmente con cada nodo 120, 126 y 128 de vendedor para productos y/o servicios. Cuando el nodo 122 de comprador realiza un contrato con el nodo 124 de distribuidor para los productos y/o servicios, el nodo de distribuidor utiliza uno o más de los nodos 120, 126 y 128 de vendedor para ejecutar el contrato. El nodo 110 de transacción central facilita la transferencia de fondos entre el nodo 122 de comprador y los nodos 120, 126 y 128 de vendedor como una función de la cantidad de productos y/o servicios proporcionadas por cada nodo de vendedor. Por ejemplo, cuando la transacción involucra productos, la cantidad del producto que se proporciona por cada nodo de vendedor se utiliza para determinar la cantidad que el nodo de vendedor va a pagar. Similarmente, cuando la transacción involucra un servicio tal como transportación, la cantidad de servicio realizado {por ej emplo, correspondiendo a la distancia de transporte, el uso de instalaciones u otro trabajo de servicio realizado) se utiliza para determinar la cantidad que va a pagar el vendedor. La transferencia de fondos se lleva a cabo utilizando datos que representan precios almacenados en la base de datos 112 que corresponden a productos y/o servicios de la transacción como acordados entre el nodo 124 de distribuidor y los nodos 120, 126 y 128 de vendedor. En cada uno de los ejemplos antes discutidos que involucran un distribuidor, la transferencia entre los participantes de la transacción se lleva a cabo utilizando uno o más de los procedimientos discutidos en la presente, tal como aquéllos dirigidos a vigilar y procesar recursos disponibles para el pago. Cuando ocurren cambios para la ejecución de pedido y/o pagos relacionados, esos cambios se utilizan para actualizar automáticamente condiciones de estado. Esos cambios, condiciones de estados y otras características vigiladas pueden implementarse por el nodo 110 de transacción central y utilizarse como una base sobre la cual caracterizar y procesar el pago para una transacción. Por ejemplo, el cumplimiento de contrato (ejecución) o el nivel de cumplimiento de contrato pueden utilizarse por el nodo 110 de transacción central para autorizar el pago para la transacción. En una implementación, el procedimiento de transacción discutido en lo anterior que involucra una entidad de nivel medio además se implementa individualmente entre vendedores y compradores. Por ejemplo, el pago por productos y/o servicios proporcionados a un comprador particular se basa en la ejecución para ese comprador. Una institución financiera del comprador particular se accede para la transferencia de fondos basándose en la calidad, cantidad y/u otras condiciones de la ejecución de transacción. Similarmente, donde múltiples vendedores se utilizan para una transacción particular, el pago por cada vendedor se basa en el nivel de ejecución de transacción proporcionado por el vendedor. En otra modalidad ejemplar de la presente invención, el nodo 110 de transacción central actúa como la entidad de nivel medio como se discute en uno o más de los ejemplos anteriores, donde los nodos de comprador y vendedor (de los nodos 120-128) interactúan con el nodo 110 de transacción central para propósitos de contrato. En este respecto, el nodo de transacción central (o una porción correspondiente del mismo) es administrado por una entidad de tipo nivel medio, ya sea mediante un control interno o externo por la entidad de nivel medio. En algunos casos, compradores y vendedores realizan el contrato para precios directamente con el nodo 110 de transacción central. En otros casos, compradores y vendedores realizan el contrato entre si para establecer precios, y uno o más de un participante de comprador y vendedor de una transacción realizan el contrato además con el nodo 110 de transacción central para facilitar la transacción. Por ejemplo, un vendedor puede realizar el contrato con el nodo 110 de transacción central para administrar la distribución del vendedor, procesos financieros u otras funciones basadas en transacción, de tal forma que el comprador realiza el contrato con el vendedor directamente pero procesa las transacciones mediante el nodo 110 de transacción central. A los vendedores que interactúan con el nodo 110 de transacción central se les paga efectiva y directamente de los compradores que interactúan con el nodo 110 de transacción central para productos y/o servicios de los vendedores. Sin embargo, el nodo 110 de transacción central (o la entidad de nivel medio que funciona con el mismo) se le paga un reajuste de precio y/o una tarifa de transacción por cada transacción que procesa. En varias aplicaciones, incluyendo uno o más de los procedimientos antes discutidos y discutidos junto con la FIGURA 1, un procesador 130 de reclamaciones, el controlador 132 de actualización de datos de reclamaciones y/o un procesador 134 de pagos se implementan selectivamente para llevar a cabo respectivamente el procesamiento de ejecución de transacción, actualizaciones de campo de datos y facilitación de pago. Por ejemplo, donde un vendedor 122 involucrado en una transacción entre el vendedor y un comprador 120 representa una reclamación ( es decir, en forma de una factura) que solicita pago contra una transacción particular, el procesador 130 de reclamaciones se implementa para procesar la reclamación en una forma no inconsistente con la que se discute en lo anterior, para asegurar si la reclamación es pagable. Es decir, el procesador 130 de reclamaciones implementa los atributos de perfil de transacción y/u otra información en la base de datos 112 (o en una base de datos 113 distribuida) indicativa de las condiciones que pueden facilitar o negar el pago. Por ejemplo, donde el comprador 120 ha actualizado la información que indica que los productos para la cual se hace una reclamación se han recibido, el controlador 132 de actualización de datos de reclamaciones actualiza la información histórica relacionada de la ejecución en la base de datos 112 que puede utilizarse para autorizar el pago para la reclamación. Es decir, los datos históricos de la ejecución son auditados para asegurar que reflejen la información en los datos de recibo y, donde tales datos de recibo no se han actualizado a los datos históricos de ejecución, el controlador 132 de actualización de datos de reclamaciones efectúa una actualización en los datos históricos de ejecución. El procesador 130 de reclamaciones utiliza la información actualizada para autorizar el pago (donde tal recibo es una condición sobre la cual puede autorizarse el pago, es decir, el pago también es auditado y validado como una función de los datos de recibo/ejecución) .

Cuando se autoriza el pago, el procesador 134 de pago utiliza la autorización para facilitar el pago al vendedor 122 utilizando, por ej emplo, la entidad 124 financiera y/u otras entidades financieras para absorber fondos de, extender crédito a nombre, o de otra forma facilitar el pago del comprador 120. En algunas aplicaciones, el controlador 132 de actualización de datos de reclamaciones vigila los datos en la base de datos 112, en una base de datos 113 distribuida y/o en una ubicación de usuario tal como una base de datos implementada por el comprador 120 o el vendedor 122 (con acceso apropiado concedido al controlador de actualización de datos de reclamaciones por el comprador o vendedor) . Cuando ocurren cambios a los campos de datos, el controlador 132 de actualización de datos de reclamaciones implementa los atributos de perfil de transacción, perfiles de usuario >u otra información en la base de datos 112 para determinar si los cambios aplican a los campos de datos relacionados. Si tales cambios aplican, el controlador de actualización de datos de reclamaciones implementa tales cambios al actualizar los campos de datos relacionados. Por ejemplo, cuando un comprador actualiza el estado de ejecución de un pedido en respuesta a recibir productos de un vendedor, el controlador 132 de actualización de datos de reclamaciones utiliza tal actualización para actualizar los campos relacionados como identificados por el comprador, vendedor u otro participante de transacción. Los campos de datos relacionados pueden incluir, por ejemplo, un campo de datos que especifica un estado pagable para un pedido particular en la base de datos 112, o un campo de ejecución para el pedido en una base de datos del vendedor correspondiente. Una vez que se actualizan tales campos relacionados, el procesador 134 de pago facilita el pago como se discute en lo anterior, donde el apropiado. La FIGURA 2A es un diagrama de flujo para un procedimiento de procesamiento de transacción, de acuerdo con otra modalidad ejemplar de la presente invención. En el bloque 210, las reglas comerciales se establecen para procesar características de transacción. Estas reglas comerciales incluyen una o más de una variedad de reglas que dirigen el procesamiento de los datos de transacción para generar un resultado particular, tal como la generación de información que puede utilizarse para promover una transacción. En el bloque 220, seleccionar ubicaciones de datos para los datos definidos por las reglas comerciales se identifican para tener una relación con otras ubicaciones de datos. En algunas aplicaciones, las ubicaciones de datos se vinculan automáticamente para una transacción como una función de participantes de la transacción, con los campos de datos correspondiendo a datos similares o iguales para diferentes participantes de transacción que se vinculan automáticamente. En otras aplicaciones, los campos de datos para un participante de transacción particular se vinculan, tal como al vincular un campo específico de activos exigibles para una transacción particular para un campo general de activos exigibles que caracterizan todos los activos exigibles para el participante de transacción. Si los datos almacenados en una ubicación de datos que tienen una relación con otras ubicaciones de datos se hace en el bloque 230, las reglas comerciales que aplican a la ubicación de datos que muestran un cambio se identifican (por ej emplo, recuperan) en el bloque 240. Las reglas comerciales identificadas se utilizan en la generación automática de información actualizada para ubicaciones de datos relacionadas en el bloque 250. Por ejemplo, como se discute en lo anterior, la información generada puede incluir información actualizada para una ubicación de datos de transacción que se relaciona a otra ubicación, con un cambio en una primera ubicación de datos que se utiliza con las reglas comerciales para ejecutar un cambio en otra ubicación de datos. En otro caso, la actualización en las ubicaciones de datos relacionadas en el bloque 250 involucra la generación de datos utilizados para ejecutar una función de transacción, tal como una porción de una cadena de eventos utilizada para autorizar pago para una transacción particular. En el contexto de una factura, cambios en cantidades pedidas, pagadas y distribuidas pueden identificarse y procesarse utilizando este procedimiento. La FIGURA 2B es otro diagrama de flujo que muestra un procedimiento para procesar una factura para una transacción entre un comprador y un vendedor, de acuerdo con otra modalidad ejemplar de la presente invención. En el bloque 205, una factura es recibida por el comprador y se procesa para determinar si la factura aplica a un pedido que pertenece al comprador. Si la factura no aplica a un pedido que pertenece al comprador en el bloque 215, el proceso se detiene en el bloque 225, con un resultado indicando la falla opcionalmente generada (por ej emplo, un aviso enviado al vendedor quien creó la factura) . Si la factura aplica a un pedido que pertenece al comprador en el bloque 215, la factura se analiza a fondo en el bloque 235 para identificar la cantidad de un articulo particular facturado. La cantidad identificada de un articulo particular se compara con los recursos de comprador relacionados en el bloque 245 para determinar si la cantidad identificada que es facturada excede la cantidad ejecutada menos la cantidad ya facturada (por ejemplo, en una factura previa) . Si la cantidad identificada es mayor que la diferencia entre la cantidad ejecutada y la cantidad previamente facturada (si se puede aplicar) la cantidad es sobre-facturada y el proceso se detiene en el bloque 225 (por ej emplo, con un resultado opcional generado para notificar al vendedor de una situación de sobre-facturación y/o para actualizar los campos de datos relacionados) . En un caso donde la cantidad identificada es mayor que la diferencia entre la cantidad ejecutada y la cantidad previamente facturada en el bloque 245, la cantidad es ajustada para ser igual a esa diferencia (de este modo ajustada para pagar la cantidad total ejecutada) , con el proceso continuando como sigue. Si la cantidad identificada es menor que o igual a la diferencia entre la cantidad ejecutada y la cantidad previamente facturada (si se puede aplicar) , la cantidad identificada se determina que es pagable en el bloque 255. Una vez que se determina que va a pagarse la cantidad identificada, la cantidad se comprueba para asegurar que satisface un umbral de cantidad pagable minimo en el bloque 265. Por ejemplo, un comprador puede limitar el pago de facturas a aquellas que exceden una cantidad particular en dólares para reducir costos asociados con pagar las facturas. Este procedimiento se puede aplicar, por ejemplo, donde el pago por algunos artículos relativamente económicos de un pedido grande puede equivaler sólo algunos dólares; tal pago puede retenerse hasta que se reciba una factura adicional. Si el umbral de cantidad pagable minimo se satisface (o si no existe un mínimo) en el bloque 265, campos relacionados se ajustan en el bloque 285 y la porción de la factura recibida que aplicó a la cantidad identificada se paga en el bloque 295. Si el umbral de cantidad pagable mínimo no se satisface en el bloque 265, pero la cantidad identificada equivale a la cantidad total del pedido en el bloque 275, el proceso continúa en el bloque 285 como se discute en lo anterior. Este caso se puede aplicar, por ejemplo, a implementaciones donde la cantidad facturada es pequeña pero el pedido es pequeño, o cuando facturas previas que equivalen a casi la cantidad total que se ha pagado, dejando sólo algunos artículos sin pagar. Si el umbral de cantidad pagable minimo no se satisface en el bloque 265 y la cantidad identificada no equivale a la cantidad total del pedido en el bloque 275, el pago se mantiene en el bloque 276. El ajuste de los campos relacionados en el bloque 285 es opcional e involucra uno o más de una variedad de ajustes. Por ejemplo, los campos tales como aquéllos que se relacionan a los precios extendidos en una factura particular en el nivel de artículo de línea, los cargos por servicios, tributaciones y otros artículos. Además, los artículos tales como los cargos por servicio y las tributaciones pueden procesarse similarmente como se muestra en la FIGURA 2B como el "artículo" en el bloque 245 {por ej emplo, con comparaciones con facturas pasadas para determinar si los cargos por servicio, tributaciones u otros artículos son apropiados) . La FIGURA 3 es un diagrama de flujo que muestra un procedimiento para categorizar datos como una función de un anclaje y vigilar los datos almacenados en ubicaciones que corresponden al anclaje para actualizar automáticamente los datos de procesamiento de transacción, de acuerdo con otra modalidad ejemplar de la presente invención. El diagrama de flujo en la FIGURA 3 puede, por ejemplo, implementarse junto con los diagramas de flujo mostrados en las FIGURAS 2A-2B y discutidos en lo anterior. Por ejemplo, las reglas comerciales mencionadas junto con la FIGURA 2A pueden implementarse junto con los perfiles de anclaje discutidos además en lo siguiente. En el bloque 310 de la FIGURA 3, los datos de transacción se envían al procesador central que se programa para acceder, manipular y utilizar datos relacionados con la transacción almacenados que incluyen datos de perfil de anclaje, así como para comunicarse con los participantes de una transacción o transacciones a la cual se refieren los datos de transacción. Los datos relacionados con la transacción, almacenados incluyen datos almacenados conforme a una identificación de anclaje (ID) que se utiliza para identificar una transacción particular para la cual se implementan los datos relacionados con la transacción. En el bloque 320, los datos de transacción se analizan a fondo y se comparan con perfiles de anclaje almacenados para detectar e identificar información en los perfiles de anclaje que es consistente con (concuerda) o de otra forma se refiere a los datos de transacción. Si una correlación entre los datos de transacción y un perfil de anclaje almacenado no se encuentra en el bloque 330, se crea una nueva ID de anclaje de correlación en el bloque 340 para su uso en identificar los datos de transacción enviados en el bloque 310 con una transacción particular. Si una correlación entre los datos de transacción y un perfil de anclaje de almacenado se encuentran en el bloque 330 (o, después de que se crea una nueva ID de anclaje de correlación en el bloque 340) , elementos seleccionados de los datos de transacción se almacenan en la base de datos conforme a la ID de anclaje de correlación (o nueva) en el bloque 350. Estos elementos seleccionados por ejemplo, pueden utilizarse para establecer un nuevo perfil de anclaje ya sea solo o junto con otros datos de transacción (por ej emplo, en la base de datos o recibidos en el bloque 310 en un momento posterior) . Una vez que se almacenan los datos de transacción en el bloque 350, las reglas comerciales para la ID de anclaje que corresponden a los datos de transacción se identifican en el bloque 360. Estas reglas comerciales por ejemplo, pueden ser parte de los datos de transacción recibidos en el bloque 310. En otro ejemplo, estas reglas comerciales se pre-almacenan conforme a un usuario particular o ID de anclaje a la cual se refieren los datos de transacción. Cuando la relación entre los datos de transacción y el usuario o la ID de anclaje para reglas comerciales particulares se establece, el procesador central entonces utiliza las reglas comerciales particulares para vigilar y procesar los datos de transacción. Específicamente, los datos de transacción se vigilan de acuerdo con las reglas comerciales identificadas en el bloque 370 y cuando un cambio en los datos de transacción (o nuevos datos de transacción) se detecta los datos de transacción relacionados conforme a la ID de anclaje se actualizan en el bloque 380 de acuerdo con las reglas comerciales. Alternativamente, cuando el cambio en los datos de transacción aplica a los datos almacenados conforme a más de una ID de anclaje {por ej emplo, como se discute en lo siguiente con el escenario con dos facturas para un pedido particular) , los datos de transacción conforme a otra ID de anclaje también se actualizan. En cualquier caso que involucre un cambio en los datos de transacción (o, en el caso donde el documento recibido es una factura, que involucra un cambio propuesto en los datos de transacción, particularmente una cantidad pagable) , los procedimientos discutidos en las FIGURAS 2A-B pueden implementarse aqui.

En una modalidad ejemplar particular de la presente invención, los siguientes atributos de datos, documentos e identificaciones se implementan por un procesador central para agrupar transacciones que son comunes para una interacción particular entre los participantes de comprador y vendedor. Este procedimiento puede implementarse, por ejemplo, junto con el almacenamiento de datos y los nodos de usuario como se muestra y discute en lo anterior junto con la disposición 100 de procesamiento de transacción mostrada en la FIGURA 1. El nodo 110 de transacción central administra los conjuntos de información sobre una interacción como programados por la configuración aplicable de las reglas comerciales que pueden establecerse en cualquier combinación de una variedad de reglas. Por ejemplo, las reglas comerciales programadas pueden utilizarse junto con conjuntos de información relacionados al estado de ejecución de un pedido como se discute junto con la Tabla 1 siguiente. Con referencia en lo siguiente a la Tabla 1 y a la FIGURA 1, los atributos de transacción se muestran para dos documentos junto con una transacción entre un comprador y vendedor como procesada por la disposición 100 de procesamiento de transacción, de acuerdo con otra modalidad ejemplar particular de la presente invención. Cuando un primer documento recibido por el nodo 110 de transacción central es Factura "123" del Vendedor "SI" que nombra el Pedido "ABC" del Comprador "Bl" como la justificación para la facturación, el procesador central responde al buscar y correlacionar la factura con la información almacenada en la base de datos. Basándose en la búsqueda (por ejemplo, una búsqueda de clave lógica o una búsqueda basada en algoritmo) , el nodo 110 de transacción central determina si tiene algún conocimiento previo de una interacción con los atributos únicos utilizados para propósitos de identificación del documento de transacción, aqui siendo atributos "123", "SI", "ABC" y "Bl". Si se encuentra conocimiento previo de la transacción a la cual aplica la factura, el nodo 110 de transacción central alinea los atributos de la factura con el campo de atributos conocido, tal como aquél del Recibo "R789" y Pedido "ABC". Una vez que se ha asociado la factura con otros documentos/información, el nodo 110 de transacción central realiza una variedad de operaciones relacionadas con la transacción, tales como aquellas discutidas en lo anterior, utilizando datos de la Factura "123" y otros documentos e información en la base de datos 112. Por ejemplo, cuando una cantidad de un producto u otro articulo relacionado con la transacción pedida para la transacción se identifica, el recurso de cantidad No Facturada Pedida "QTY1" del nivel de articulo de linea se incrementa para el Recibo "R789". El recurso de cantidad No Recibida Pedida para el Recibo "R789" también se actualiza correspondientemente para correlacionar el incremento en la cantidad no Facturada Pedida. Similarmente, cuando la cantidad de un producto u otro artículo relacionado con la transacción pedido para la transacción se identifica, el recurso de cantidad No Recibida Pedida "QTY2" en el nivel de articulo de linea se incrementa para la Factura "123". En esta discusión y como se puede aplicar de otra forma a una o más modalidades ejemplares en la presente, el nivel de articulo de linea generalmente se refiere a los artículos de linea, dentro de un documento particular, que especifican información particular para un articulo de linea, donde varios artículos de línea se incluyen en un solo documento. El costo de una cantidad particular para una transacción se agrega ya sea al recurso monetario No Facturado Pedido "AMTl" en el nivel de artículo de línea o el recurso monetario No Facturado Pedido "AMT2" en el nivel de documento. Este procedimiento es útil por ejemplo, cuando el precio total de un pedido es diferente de aquél para una factura particular o recibo para una porción del pedido (es decir, con el nivel de documento haciendo referencia a toda una cantidad de pedido, en lugar de solamente la cantidad para una factura particular) . Cuando se reciben productos antes de la Factura "123", el recurso de cantidad No Facturada Recibida "QTY3" en el nivel de artículo de línea se incrementa. La cantidad total del Pedido "ABC" en el nivel de documento también puede incrementarse en la cantidad que el recurso de cantidad "QTY3" se incrementa, lo cual también puede aplicar correspondientemente a las cantidades No Facturadas Pedidas y No Recibidas Pedidas en el nivel de artículo de línea. Cuando la Factura "123" se recibe, la cantidad facturada se resta del recurso de cantidad No Facturada Pedida "QTY1" en el nivel de artículo de línea así como el recurso de cantidad No Facturada Recibida "QTY3" en el nivel de artículo de línea. Además, la cantidad facturada se resta del recurso monetario No Facturado Pedido "AMTl" en el nivel de artículo de línea o el recurso monetario No Facturado Pedido "AMT2" en el nivel de documento. Además, cuando se reciben facturas adicionales para el Pedido "ABC", los recursos de cantidad correspondientes se actualizan continuamente para proporcionar información precisa. Con los procedimientos discutidos en lo anterior junto con la Tabla 1 siguiente, el efecto de retroceder una fuente de recursos puede pasarse inmediatamente a través de todos los documentos financieros que reclaman recursos que aún no han sido pagados. Este procedimiento tecnológico se ha encontrado útil para automatizar efectivamente el proceso de reconciliación de pre-pago de documentos para ejecución física y financiera.

Tabla 1 La FIGURA 4 muestra una disposición para procesar reclamaciones para una pluralidad de transacciones, de acuerdo con otra modalidad ejemplar de la presente invención. Las diversas modalidades ejemplares e implementaciones discutidas en la presente se implementan selectivamente utilizando la disposición en la FIGURA 4. Una aplicación ejemplar de la disposición en la FIGURA 4 que involucra un comprador y un vendedor se discute como sigue; mientras se describe junto con este ejemplo, la disposición en la FIGURA 4 se configura para procesar transacciones similares para una pluralidad de combinaciones disparejas de comprador y vendedor, utilizando atributos de perfil de transacción que pertenecen a transacciones que involucran cada combinación de comprador y vendedor. Un vendedor 402 genera una factura 405 y envia la factura a un procesador 410 de transacción. En respuesta al recibo de la factura 405, un procesador 412 de asociación asocia la factura con una transacción particular y envia una solicitud 430 de perfil de transacción a una disposición 440 de banco de datos, la cual regresa los perfiles 431 de transacción. Un procesador 414 de actualización utiliza los perfiles de transacción regresados para identificar una cantidad 444 histórica apropiada facturada (por ej emplo, un campo de datos) en la disposición 440 de banco de datos, la cual se actualiza con información 432 histórica de actualización de cantidad facturada.

Cuando un comprador 420 genera un recibo 425, el procesador 412 de asociación asocia el recibo con una transacción particular y envia otra solicitud 430 de perfil de transacción a la disposición 440 de banco de datos, la cual regresa los perfiles 431 de transacción apropiados. El procesador 414 de actualización utiliza los atributos de perfil de transacción y los datos de recibo para actualizar una cantidad 446 histórica apropiada de ejecución {por ejemplo , un campo de datos) en la disposición 440 de banco de datos. El procesador 410 de transacción se adapta para procesarse de acuerdo con los procedimientos antes discutidos que involucran el recibo de los datos 405 de factura y los datos 425 de recibo en diferentes pedidos. Independientemente del orden el procesador 416 de reclamaciones es sensible a la factura 405 al enviar una solicitud 433 de datos histórica a la disposición 440 de banco de datos, la cual regresa los datos 434 históricos de cantidad facturada y de ejecución. El procesador 416 de reclamaciones utiliza los datos 434 de cantidad histórica regresada facturada y de ejecución para determinar si el pago para parte o toda la factura 405 es apropiado. Por ejemplo, cuando la cantidad histórica de ejecución excede la cantidad facturada histórica (por ejemplo, y pagada) por una cantidad igual a una cantidad facturada en la factura 405, el procesador 416 de reclamaciones determina que toda la factura puede pagarse. Una vez que se autoriza el pago por el procesador 416 de reclamaciones, un procesador 418 de pago utiliza la autorización para facilitar el pago para la factura 405 al enviar una autorización 411 de pago a una institución 450 financiera identificada, por ejemplo, en los perfiles 431 de transacción regresados. La institución 450 financiera a su vez envia el pago 451 al vendedor 402. Aunque 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, aspectos de la cual se establecen en las siguientes reivindicaciones.

Claims (13)

1. REIVINDICACIONES 1. Un sistema de procesamiento de transacción para administrar recursos de pago para una pluralidad de transacciones que involucran ofertas mercantes entre participantes que incluyen compradores y vendedores, diferentes de la pluralidad de transacciones que involucran diferentes conjuntos de participantes de comprador y vendedor, el sistema caracterizado porque comprende: una disposición de almacenamiento de datos adaptada, para cada una de la pluralidad de transacciones, para almacenar datos que caracterizan cantidades históricas de ejecución y facturadas para artículos pedidos de la transacción; y una disposición de computadora adaptada, para cada uno de los artículos pedidos listados en una factura para cada una de la pluralidad de transacciones, para asociar la factura con una de la pluralidad de transacciones; autorizar el pago por cada artículo pedido listado en una factura como una función de una cantidad facturada del artículo pedido sobre la factura y una diferencia entre la cantidad histórica de ejecución y la cantidad histórica facturada para el artículo pedido como se indica en los datos almacenados en la disposición de almacenamiento de datos para la transacción asociada; actualizar cantidades históricas facturadas para el artículo pedido como caracterizado en los datos almacenados en la disposición de almacenamiento de datos como una función de la cantidad facturada en la factura.
2. 2. El sistema de conformidad con la reivindicación 1, caracterizado porque la disposición de computadora se adapta para, en respuesta a la cantidad facturada del articulo pedido sobre la factura que es más de la diferencia entre la cantidad histórica de ejecución y la información de cantidad facturada para el articulo pedido en la disposición de almacenamiento de datos, identificar la cantidad del artículo pedido particular sobre la factura que excede la diferencia entre la cantidad histórica de ejecución y la información de cantidad facturada como sobre-facturada.
3. 3. El sistema de conformidad con la reivindicación 2, caracterizado porque la disposición de computadora se adapta para autorizar el pago por una cantidad del artículo pedido particular sobre la factura que no excede la diferencia entre la cantidad histórica de ejecución y la información de cantidad facturada para el artículo pedido en la disposición de almacenamiento de datos.
4. 4. El sistema de conformidad con la reivindicación 2, caracterizado porque la disposición de computadora se adapta para comunicar una cantidad de artículos sobre-facturados sobre una factura para el participante de vendedor al cual aplican los artículos sobre-facturados.
5. 5. El sistema de conformidad con la reivindicación 1, caracterizado porque la disposición de computadora se adapta para: vincular automáticamente los campos de datos relacionados para una transacción particular como una función de un participante de transacción al cual aplican los campos de datos relacionados, vigilar cambios hechos en los campos de datos seleccionados en la disposición de almacenamiento de datos, y en respuesta a un cambio en uno de los campos de datos seleccionados, actualizar otro campo de datos relacionado.
6. 6. El sistema de conformidad con la reivindicación 1, caracterizado porque la disposición de computadora se adapta para comparar información en cada factura con la información de perfil almacenada en el banco de datos para correlacionar la factura con cantidades históricas de ejecución y facturas y para utilizar las cantidades históricas correlacionadas de ejecución y facturadas cuando se autoriza el pago por cada articulo pedido listado en la factura.
7. 7. El sistema de conformidad con la reivindicación 1, caracterizado porque la disposición de almacenamiento de datos se adapta para almacenar atributos de perfil de transacción para cada transacción, los atributos de perfil de transacción incluyen información para identificar información de pedido para la transacción y por lo menos uno de un comprador y un vendedor involucrados con la transacción, donde la disposición de computadora se adapta para autorizar el pago por cada articulo pedido listado en la factura como una función de los atributos de perfil de transacción.
8. 8. El sistema de conformidad con la reivindicación 7, caracterizado porque la disposición de computadora se adapta para vigilar cambios en un atributo de perfil de transacción que indica el estado de ejecución de un pedido y en respuesta a los cambios en el estado de ejecución de un pedido particular, actualizan otros atributos de perfil de transacción que se refieren al estado de ejecución para el pedido particular.
9. 9. El sistema de conformidad con la reivindicación 7, caracterizado porque la disposición de computadora se adapta para asociar la factura con una de la pluralidad de transacciones al correlacionar datos en la factura con los datos de perfil de transacción para una transacción particular y al correlacionar la transacción particular con por lo menos un participante de transacción de la transacción utilizando información de perfil para por lo menos un participante, autorizar el pago al utilizar la información de perfil para por lo menos un participante para autorizar el pago, y actualizar cantidades facturadas históricas al utilizar información de perfil para por lo menos un participante para actualizar por lo menos el sistema de contabilidad de un participante con las cantidades históricas actualizadas facturadas.
10. 10. El sistema de conformidad con la reivindicación 1, caracterizado porque la disposición de computadora se adapta para autorizar pago para cada artículo pedido listado en la factura como una función de una cantidad facturada del artículo pedido y una diferencia entre la cantidad de ejecución histórica y la cantidad facturada histórica para el artículo pedido como se indica en los datos almacenados en la disposición de almacenamiento de datos al comparar la información de cantidad facturada para el artículo pedido en la factura con la información de cantidad histórica de ejecución y facturada para el artículo pedido como se indica en los datos almacenados en la disposición de almacenamiento de datos.
11. 11. El sistema de conformidad con la reivindicación 1, caracterizado porque la disposición de computadora se adapta para auditar y validar los datos almacenados que caracterizan las cantidades históricas de ejecución como una función de los datos de recepción, validando por consiguiente esos recursos de cantidad recibidos que se han agregado a las cantidades históricas de ejecución.
12. 12. Para su uso en administrar automáticamente recursos de pago para una pluralidad de transacciones que involucran ofertas mercantes entre participantes que incluyen compradores y vendedores, las diferentes de la pluralidad de transacciones que involucran conjuntos diferentes de participantes de comprador y vendedor, un método implementado por computadora, caracterizado porque comprende, para cada una de la pluralidad de transacciones: almacenar datos que caracterizan cantidades históricas de ejecución y facturadas para artículos pedidos de la transacción; y asociar datos de factura con la particular de las transacciones como una función de los datos en la factura y la información de perfil de transacción almacenada; y autorizar el pago de un comprador a un vendedor para cantidades de artículos facturados del vendedor como una función de datos de cantidad ejecutados que indican artículos que se han ejecutado por el vendedor para la transacción, y datos de estado facturados históricos para el artículo, los datos de estado facturados históricos son indicativos de una porción de la cantidad total del artículo que se ha facturado previamente.
13. 13. El método de conformidad con la reivindicación 12, caracterizado porque autorizar pago incluye autorizar pago para por lo menos una porción de las cantidades del articulo facturado del vendedor que no exceden una diferencia entre los datos de cantidad ejecutada y la cantidad de artículo previamente • facturado.