SISTEMA DE PROCESAMIENTO DE TRANSACCIÓN AUTOMATIZADA Y PROCEDIMIENTO CON CONVERSIÓN DE DIVISAS
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 dos o más divisas . El manejo operacional de interacciones contractuales y de transacción entre compradores, vendedores y otros involucrados en el intercambio de productos para propósitos de comercio típicamente han sido laboriosos y exigido mucho tiempo. Generalmente, el proceso .de maneja?" transacciones entre entidades comerciales ^" a sido indebidamente problemático e ineficiente. Los diversos participantes involucrados en una transacción típicamente cambian términos y aspectos propuestos de la transacción propuesta sobre una base concurrente y/o iterativa. Además, aspectos de transacción que involucran tasas de conversión de divisas y otros términos influenciados externamente con frecuencia fluctúan con el tiempo, con relación a eventos para una transacción particular. Por ejemplo, •' desde el momento en que se recibe un pedido hasta el momento dé la ejecución del pedido, las tasas de intercambio de divisas con frecuencia cambian.
Con frecuencia, los datos que representan cada perspectiva de participante corporativo de la interacción se almacena a través de uno o más sistemas empresariales manejados . por el participante corporativo particular y no es accesible por otros participantes corporativos. Consecuentemente, puede ser difícil conocer que documento de proyecto representa la información más actual sobre la interacción y si los participantes en la transacción tienen un entendimiento común. Donde los participantes corporativos se han comunicado electrónicamente (por ejemplo, mediante correo electrónico y comunicaciones mejoradas en Internet) estas dificultades de sincronización de documento se han complicado por un número incrementado de documentos de proyecto coexistentes que son visualizados '-¡.-por los participantes. Además, la variación de divisa presienta otra variante entre las transacciones y/o participantes en una sola transacción. Transacciones comerciales entonces se vuelven más difíciles ya que entidades comerciales intentan realizar transacciones entre si y en particular, para realizar transacciones relacionadas con pagos que involucran conversión de divisas. Una interacción comercial típica entre un vendedor que ofrece un producto y un comprador que desea adquirir ese producto se desplaza por múltiples etapas. Primero, el comprador y el vendedor negocian un acuerdo en cuanto al precio que el comprador pagará. Cuando este acuerdo cubre un periodo extendido de tiempo, típicamente se formaliza en un contrato o catálogo. Contratos y catálogos típicamente son mantenidos por el vendedor en un sistema de cómputo administrado por el vendedor que se separa del sistema o sistemas de cómputo que el vendedor utiliza para aceptar pedidos, presentar pedidos y generar facturas. Cuando el sistema de facturas utilizado por el vendedor para facturar al comprador tiene un archivo de precios diferente que el que está en el sistema de contratos administrado por el> vendedor, se presentarán excepciones de precio que incrementarán el costo de la interacción debido a que el personal del comprador y el vendedor tendrán que resolver las diferencias antes de que pueda completarse una transacción. El problema puede complicarse cuando el comprador carga los precios de contrato actuales en su sistema de procuración para la determinación de si el vendedor está facturando correctamente durante el proceso de orden de prepago/conciliación de facturas. Todos los sistemas de facturación del vendedor podrían estar representando el contrato actual mientras uno o más de los sistemas del comprador aún representan un contrato expirado o aún no activo. Algunos o todos los sistemas de facturación del vendedor podrían estar representando contratos expirados o aún no activos mientras todos los sistemas de procuración del comprador están actualizados.
Donde diferentes divisas se involucran para una transacción particular, una conversión de divisa típicamente se hace para convertir la divisa utilizada por el comprador en la divisa deseada por el vendedor. Sin embargo, las tasas de conversión de divisas varían grandemente con el tiempo. Además, diferentes tasas de conversión están disponibles de diferentes fuentes. Además, donde las cuestiones relacionadas con el precio tales como aquellas discutidas en lo anterior ocurren, las cuestiones de pago además se complican con los requerimientos de conversión de divisas asociados con el precio. El número de combinaciones de eventos que llevan a malos entendidos de transacción y desacuerdos contribuyen significativamente al costo general de asentamiento para el intercambio de productos y/o servicios que son el> '"objeto de una transacción. Como una complicación adicional, --los contenidos del contrato, la factura y otros documentos que representan la transacción y se requieren para establecer la transacción con frecuencia sólo existen en forma de papel para su acceso a los individuos que intentan resolver riesgos. Además, los datos que si existen electrónicamente con frecuencia se distribuyen a través de numerosas aplicaciones tales como cuentas por pagar, cuentas por cobrar, adquisición, contabilidad, grupo de c mprador o vendedor, transporte y recepción. Además, db?de cada comprador realiza un negocio con muchos vendedores y cada vendedor realiza un negocio con muchos compradores, seguir tales proyectos se vuelve cada vez más difícil. Un tipo de transacción para la cual aplican las dificultades anteriores es una transacción de transporte marítimo. Procedimientos tradicionales han llevado a muchos retos para manejar transacciones entre un transportista marítimo y un transportista terrestre. Típicamente, sin embargo, existen múltiples transportadores terrestres y transportadores marítimos involucrados en múltiples transacciones, que hace al proceso de administración más complejo, y que exige mucho más tiempo y es inefi'ciente. El proceso es muy laborioso ya que se basa en correlacionar físicamente la copia impresa de un conocimiento de embarque (BOL) para la prueba de entrega con la factura en copia impresa y después tratar de aplicar los términos de un contrato de copia impresa para calcular si la cantidad de factura es adecuada para pagar. Excepciones necesarias para comunicarse con el socio comercial, con frecuencia involucra enviar por fax o por correo copias en papel de materiales de apoyo. Las respuestas a solicitudes para información con frecuencia resultan en más copias de papel con anotaciones escritas a mano que alteran el entendimiento de cómo ocurrió realmente la transacción. La serie resultante de etapas repetitivas y que exigen tiempo son una fuente de gasto operacional adicional para el comprador y el " vendedor. También, cada BOL con frecuencia se clasifican varias veces por múltiples participantes que crean redundancia excesiva. Debido a tales dificultades y procesos convolucionados, sistemas de administración de transacción de transporte marítimo tradicionales son altamente susceptibles a errores de facturación y fraude. Por ejemplo, no ha existido ninguna conexión entre la entrega de productos y cuando el transportista marítimo se factura para la entrega. Esto puede resultar en doble facturación, ninguna facturación en absoluto o sobrefacturación de transportista marítimo por cargos de distribución de mercancías. También, errores de auditoria pueden presentarse, lo cual resulta en facturación o pago incorrecto, lo cual es molesto cuando se involucra una conversión de divisa. Además, el transportista terrestre espera un tiempo desproporcionadamente largo para el pago mientras la factura se está auditando y/o está en disputa. Por ejemplo, tradicionalmente, una entrega- toma aproximadamente cinco días mientras el pago toma aproximadamente cuarenta y cinco días. Este retardo afecta adversamente los recursos de capital de trabajo del transportista terrestre que, a su vez, eleva el costo de transacción de transportista terrestre y eleva los precios de transportista terrestre que debe cargar para ganar el reingreso económico requerido para permanecer en el negocio.
Donde se involucra una conversión de divisas, las tasas de conversión varían con el tiempo y de este modo retardos debidos a errores de auditoria o entrega pueden resultar en una tasa de conversión muy diferente, si la conversión se lleva a cabo en una base que fluctúa con estos retardos. Costos adicionales surgen como resultado de las ineficiencias existentes. Muchos de los costos son individualmente pequeños, pero muy grandes en total. Por ejemplo, el transportista terrestre incurre en costos administrativos, que incluyen: el costo de crear y distribuir la factura inicial, los costos de resolver disputas de facturación, costos de proporcionar una copia firmada del BOL al transportista marítimo, y costos de enviar por correo cuentas por cobrar. El transportista marítimo -incurre en costos administrativos similares para recibir l-a> factura., compararla con el BOL, comprobar manualmente los contratos para determinar si el precio es correcto, después generar y entregar el pago al transportista terrestre. Otro reto presente en muchos sistemas tradicionales involucra la incompatibilidad del producto y servicio (después de esto los términos "producto" y/o "servicio" se refieren colectivamente como "producto") identificadores de referencia entre compradores, vendedores y otras entidades relacionadas (por ejemplo, un distribuidor u organización de compra en grupo (GPO) ) . Cuando se utilizan múltiples identificadores de referencia, rastrear y conciliar transacciones comerciales se vuelve más difícil. Lá complejidad del negocio moderno también ha llevado a costos administrativos elevados asociados con transacciones comerciales. Los costos administrativos incluyen personal, software, hardware, y todos los departamentos creados para administrar transacciones comerciales para asegurar una facturación y pago precisos y puntuales. Aunque con el costo administrativo elevado, la mayoría de las transacciones típicamente se han basado en papel como el medio para comunicarse dentro y entre corporaciones. Las copias de papel son costosas y difíciles de rastrear y no son simultáneamente accesibles desde ubicaciones distintas geográficas. Disputas también pueden presentarse con varias copias de papel que circulan dentro y entre corporaciones (por ejemplo, discrepancias en el precio, pagos cortos, y disputas de precio prolongadas. Estas disputas pueden resultar en negociaciones problemáticas y prolongadas, que además frustran al comprador y al vendedor. Adicionalmente, las disputas pueden llevar a un deterioro o posib emente lá extinción de la relación entre el comprador y el! vendedor:' Costos adicionales incurren si necesitan encontrase nuevos compradores o vendedores. La mayoría de las industrias son bastante competitivas y cualesquier ahorros de costos por lo tanto son importantes. Costos administrativos se destinan para reducción ya que ningún ingreso se genera directamente de las funciones administrativas. Sin embargo, costos administrativos asociados con transacciones comerciales han sido difíciles de reducir en el ambiente comercial actual con datos ampliamente difundidos y, en particular, con tasas de divisas fluctuantes para aquellas transacciones que involucran diferentes divisas. Lo anterior y otras dificultades en la administración y coordinación de transacciones comerciales ha presentado retos administrativos y de costo a entidades comerciales sobre finalizaciones de transacciones de comprador y vendedor, así como aquellos involucrados en otros aspectos de tales transacciones. La presente invención se dirige a solucionar los retos antes mencionados y otros relacionados con los tipos de dispositivos y aplicaciones discutidos 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, un procedimiento de procesamiento de transacción involucra procesara automáticamente transacciones entre participantes de una transacción como una función de las reglas de la parte de transacción y un término de conversión de divisas. De acuerdo con otra modalidad ejemplar de la presente invención, un procedimiento de procesamiento de transacción involucra un procesador de transacciones implementado para procesar automáticamente cambio de divisas para una transacción que involucra partes contratantes. El procesador de transacción se adapta para acceder a reglas comerciales relacionadas con el contrato para las partes contratantes y ha convertir automáticamente divisa de un precio relacionado con la transacción para una de las partes contratantes. En una implementación, el procesador de transacciones optimiza las reglas comerciales .para seleccionar una fuente particular para su utilización.1- en determinar una tasa de cambio de divisas para utilizarse en convertir la divisa. En otra implementación, el procesador de transacción utiliza las reglas comerciales para seleccionar una fecha y tiempo particular para utilizarse en establecer una tasa de cambio de divisas para utilizarse en convertir la divisa (implementada, por ejemplo, donde los participantes de la transacción están en diferentes zonas de tiempo) . En otra implementación, una disposición ;' de almacenamiento de datos almacena las reglas Gómerciales utilizadas por el procesador de transacción. Los participantes de la transacción almacenan reglas comerciales que pueden utilizarse en una pluralidad de transacciones. Cuando el procesador de transacción recibe información de transacción para procesar, identifica los participantes en la transacción de la información de transacción y accede a las reglas comerciales almacenadas para los participantes identificados. Al utilizar estas reglas comerciales accedidas, el procesador de transacciones selecciona automáticamente (por ejemplo, utilizando una referencia de tasa de cambio autorizada por las reglas comerciales) una tasa de cambio y convierte la divisa para la transacción que utiliza la tasa de cambio. 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 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 para el manejo de transacciones, de acuerdo con una modalidad ejemplar de la presente invención; La FIGURA 2 muestra una disposición de procesamiento de transacción, de acuerdo con otra modalidad ejemplar de la presente invención; y La FIGURA 3 es un diagrama de flujo que muestra un procedimiento para el manejo de transacciones que involucra conversión de divisas, de acuerdo con otra modalidad ejemplar de la presente invención. Mientras la invención se puede tratar p' ra 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 es para limitar necesariamente 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 de manejos de comunicaciones y proceso financiero, y se ha encontrado que es particularmente útil para aplicaciones que involucran la implementación operacional y aplicación de precio (y conversiones de divisas relacionadas) a transacciones, pagos, seguimiento y aspectos relacionados de las mismas. 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 descripción- de varios ejemplos utilizando estos y otros contextos. De acuerdo con una modalidad ejemplar de la presente invención, una disposición de manejo de transacción utiliza información de participante de transacción "(por ejemplo, compradores y vendedores) para derivar automáticamente opciones de precio y/o pago con conversión de divisas para transacciones individuales. La información de transacción puede incluir por ejemplo, las identidades de los participantes de la transacción, productos o servicios de la transacción, reglas para procesar conversiones de divisas, información de perfil de usuario específica para un participante o participantes particulares en la transacción y otros. Cuando se llevan a cabo funciones de transacción relacionadas con pagos, la información de conversión de divisas se utiliza para determinar una cantidad de pago para uno o más de los participantes en la transacción. La información de transacción puede establecerse en contratos específicos entre participantes de la transacción o implementarse utilizando prácticas de transacción previamente acordadas o de otra forma estándares. Por ejemplo, contratos específicos bajos los términos de los cuales* se está procesando una transacción pueden incluir precios ' acordados entre un comprador y vendedor por un artículo particular y/o reglas de transacción acordadas para establecer ciertos precios entre un comprador y vendedor y para realizar conversiones de divisas. Términos de contrato condicionales también pueden implementarse para facilitar la selección entre uno o más términos de contrato diferentes, o para facilitar la derivación de un nuevo término de contrato. Funciones de transacción relacionadas con el pago como se describen en lo anterior típicamente involucran pago real (es decir, transferencia de dinero) a un vendedor a nombre de un comprador así como funciones de liquidación que involucran financiamiento y contabilidad. En algunas aplicaciones, las funciones de liquidación involucran el paso de información para propósitos de contabilidad que incluyen el envío por correo del pago contra cuentas por cobrar. Además, las funciones de liquidación involucran, donde es apropiado, cobrar dinero que se relaciona con el pago directamente y/o mediante un procedimiento indirecto tal como la reducción de una línea de crédito (y contabilidad relacionada) . Otra modalidad ejemplar de la presente invención se dirige a un sistema de procesamiento que maneja automáticamente transacciones utilizando una implementación de base de datos que proporciona una fuente de precios y contratos de productos para una pluralidad de transacciones y participantes de la transacción. Antes que cualquier transacción, compradores y vendedores prospectos negocian y/o validan precios y términos de contratos, o simplemente validan la representación electrónica de los precios y términos de contratos negociados a través de otros medios. Por cada contrato, un comprador revisa, acepta y/o argumenta términos de contrato o actualizaciones de términos de contrato. Una vez que un comprador acepta un contrato, un centro de procesamiento almacena el contrato aceptado y activa el contrato para las transacciones actuales y/o futuras . Un administrador de contratos cooperativo aplica términos de contrato para el desempeño real de contrato, con participantes involucrados en la transacción que definen los términos de contrato aplicables que incluyen precios y términos de conversión de divisas relacionados. En algunos casos, los participantes en la transacción definen directamente los términos de contrato al acordar" -términos específicos. En otros casos, los participantes en la transacción definen indirectamente los términos de contrato al establecer reglas comerciales por las cuales el participante está dispuesto a participar en las transacciones. El administrador de contratos cooperativo entonces utiliza esta vez las conversiones para establecer términos de contrato. Estas reglas comerciales por ejemplo, pueden derivarse de y/o incluir información de perfil de comprador y/o vendedor que incluye datos relacionados con el contrato tales como términos de producto, precio y conversión de divisas, transporte, términos de pago, tipo de divisa, información de aduanas y otros datos de contratos típicos. Las reglas comerciales también pueden incluir información ,que se refiere a un tipo particular de transacción o términos de tipo contrato generalmente aceptados, y pueden no ser necesariamente específicos para un participante de transacción particular o una transacción particular. Además, las reglas comerciales pueden implementarse con información de tolerancia, tal como márgenes de pago de tolerancia, tolerancia de tasa de conversión de divisa, márgenes de términos de entrega y otra información para su utilización en negociar automáticamente o de otra forma establecer-" términos de contrato. Estas reglas comerciales pueden almacenarse en una base de datos que se puede acceder por el administrador de contratos cooperativo. Toda la información de precios y las reglas comerciales se puede recuperar por un administrador de transacción o por aplicaciones alejadas del administrador de contratos cooperativo tales como aquellas localizadas en las ubicaciones del comprador o vendedor (con controles de seguridad para accesos remotos). En algunos casos, el administrador der-'"contratoé cooperativo resuelve automáticamente (o intenta resolver) las disputas de transacción o términos de contrato incongruentes. Las reglas comerciales predefinidas y aceptadas se utilizan para llegar automáticamente a términos de contrato antes de ejecutar una transacción. Además, donde las reglas comerciales para diferentes participantes en una transacción exigen diferentes términos de contratos, el administrador de contratos cooperativo intenta resolver automáticamente los diferentes términos utilizando tolerancias u otra información que permite variación de las reglas comerciales actuales. Por ejemplo, cuando se utilizan aplicaciones de tipo conversión de divisas, el administrador de contratos cooperativos establece los parámetros de conversión tales como ,1a tasa de conversión y el tiempo de conversión basándose en términos de contrato específicos y/o reglas comerciales para cada participante en una transacción. Cuando el administrador de contratos cooperativo es incapaz de resolver automáticamente las disputas o términos de contrato incongruentes, el sistema de procesamiento alerta a los participantes involucrados en la transacción no resuelta, que pueden interactuar con el sistema de procesamiento para intentar conseguir una resolución. • • -. Los perfiles de usuario discutidos en la presente pueden incluir una variedad de información para su utilización en manejo de transacciones y otros aspectos. Por ejemplo, un perfil típico incluye uno o más de los siguientes datos: información de identificación de usuario, reglas comerciales para el usuario, gráficas generales de los libros de contabilidad de las cuentas (por ejemplo, y cuentas por cobrar a diferencia de transferidas para el procesamiento de pagos como se describe en lo anterior) , identificación de sistemas de cómputo que presentan los datos del contrato o transacción al administrador de contratos cooperativo, listas de clientes, listas de vendedores, políticas de aprobación de contratos y precios, políticas de conversión de divisas,, políticas de extensión de crédito (por ejemplo, para extender una deuda de crédito a un participante de transacción) , políticas de pago, políticas de aprobación de transacción, funciones operacionales (por ejemplo, que definen que funciones puede realizar un usuario asociado con esa función), jerarquía organizacional (por ejemplo, que definen cuanto puede acceder un usuario asociado con un nodo organizacional particular a un universo .de datos empresariales), y usuarios. Los perfiles de la--- lista-' de clientes de vendedor también pueden incluir información que definen además la relación comercial con el cliente a partir de la perspectiva del Vendedor, por ejemplo, tal como una relación de comprador minorista y/o una relación de comprador mayorista. Los perfiles de la lista de vendedores de comprador (por ejemplo, vendedor o distribuidor) también pueden incluir información que define además la relación comercial con el vendedor a partir de la perspectiva del Comprador . ' En otra modalidad ejemplar de la presente invención, una interfaz electrónica facilita el acceso de usuario a un sistema de manejo de transacciones de- manera qué involucra un administrador de contratos cooperativo como se discutió en lo anterior. La interfaz electrónica' se adapta para comunicarse con el sistema de manejo de transacciones para implementar una variedad de procesos, tales como aquellos que involucran el establecimiento de términos de contrato, la selección de la información de conversión de divisas y las compras de productos. La interfaz electrónica también facilita las funciones de búsqueda ejecutadas por el usuario para acceder a información tal como información dé productos, precios de productos, información de.- divisas contratos y notas de precio, el acceso a la información mediante la interfaz de usuario se puede controlar adaptablemente, por ejemplo, utilizando procedimientos de autorización que incluyen identificación de usuario, identificación de interfaz, acceso por contraseña y otros. Los procedimientos para el uso de reglas comerciales así como información de contratos y perfiles de usuario (como parte de las reglas comerciales u otras) como se discute en la presente pueden implementarse' "en -"-una variedad de formas. Una implementación involucra un procedimiento de manejo de transacciones que se basa en reglas comerciales previamente establecidas por compradores y/o vendedores. El sistema de manejo de transacciones incluye una computadora y un nodo de comunicación adaptados para derivar precios para transacciones como una función de las reglas de precios que son acordadas por las entidades de compra y venta relacionadas con la transacción. Estas reglas de precios pueden implementarse mediante las reglas comerciales y/o pueden adaptarse a una transacción específica. Para información general con respecto al uso de reglas comerciales, y para información específica con respecto a procedimientos de procesamiento de transacciones que pueden implementarse junto con una o más modalidades ejemplares discutidas aquí, puede hacerse referencia a la Solicitud de Patente Norteamericana No. de Serie 10/436,878 (USBA.101PA) , presentada el 12 de mayo de 2003, la cual se incorpora completamente en la presente para referencia. En otra modalidad ejemplar de la presente invención, un sistema de precio y pago automatizado lleva a cabo procesos de transacción para participantes de transacción que proporcionan ajustes respectivos- e reglas comerciales con información para seleccionar un estándar de conversión de divisa. Los estándares de conversión de divisas que pueden implementarse incluyen, por ejemplo, estándares públicos basados en tasas publicadas u otros valores relativos de la divisa diferente, con los estándares siendo susceptibles a fluctuación como una función de las tasas de conversión de divisas. El sistema incluye un procesador de transacciones que puede implementarse por ejemplo, utilizando uno o más de una variedad de procesadores o combinaciones de procesadores, tales como una CPU o una disposición de procesamiento distribuida con múltiples procesadores que se comunican sobre una red. El procesador de transacciones se adapta para recibir y utilizar las reglas comerciales para derivar un término específico para una transacción que va a implementarse por participantes de la transacción, y establece un precio de transacción (en una primera divisa) como una función del término específico. El término específico puede derivarse utilizando por ejemplo, información en un contrato entre los participantes de transacción que identifican directamente un precio de transacción fijo, o información que utiliza características de la transacción junto con la información almacenada para proporcionar un precio de transacción flexible. El procesador de transacción además selecciona un estándar de conversión de divisas que utiliza las reglas comerciales, y utiliza el estándar seleccionado, convierte el precio establecido de la primera divisa en una segunda divisa diferente para al menos un participante en la transacción. El pago y la liquidación entonces se efectúan para la transacción como una función del precio establecido, las reglas comerciales y • el precio establecido convertido. Por ejemplo, con un vendedor y comprador que realizan un contrato por productos, el pago y la liquidación pueden efectuarse al pagar al vendedor en la primera divisa en el precio establecido, y al retirar fondos del comprador en el precio establecido convertido. Además, los gastos asociados con la conversión de divisas se evalúan selectivamente con la realización del pago y liquidación, con un gasto acumulado en el estándar de conversión de divisa seleccionado y/o se evalúa separadamente para uno o ambos de los participantes en la transacción por el procesador de transacciones. Estos gastos se evalúan en una base de transacción por transacción, o en otra base de multitransacción, con contrato y/o reglas comerciales indicando el procedimiento de evaluación de gastos.i". La FIGURA 1 es un sistema 100 de comunicación que incluye un administrador 110 de contratos cooperativo para manejar transacciones comerciales entre un vendedor y un comprador respectivamente en una terminal 122 de vendedor y una terminal 120 de comprador, de acuerdo con otra modalidad ejemplar de la presente invención. La terminal 122 de vendedor incluye un procesador 123 de vendedor adaptado para proporcionar un perfil de vendedor y datos de contrato que representan contratos entre el vendedor y uno o más compradores, y para comunicar los perfiles y los datos de contratos a una interfaz 133 de vendedor. En algunas aplicaciones, la terminal de vendedor también proporciona información de perfil que pertenece a ciertos compradores autorizados (por ejemplo, compradores autorizados para participar en transacciones, con el vendedor y con el sistema 100) . La interfaz 133 de vendedor incluye un dispositivo 146 de procesamiento de datos adaptado para establecer reglas para una transacción comercial al presentar un perfil de vendedor, uno o más perfiles de comprador autorizados (en algunos casos) y datos de contratos (es decir, recibidos del procesador 123 de vendedor) en un procesador 140. La interfaz 144 de vendedor además se adapta para desplegar datos- de contrato recibidos del procesador 140, y comunicar al vendedor del procesador 140 la aceptación o disputa de los datos de contratos por un comprador. El procesador 140 organiza electrónicamente los datos de contrato de un vendedor utilizando un perfil de vendedor, con los datos de contrato y el perfil siendo almacenados en una unidad 142 de almacenamiento de datos. La terminal 122 de vendedor facilita el acceso a los datos del contrato del vendedor almacenados en la unidad 142 de almacenamiento de datos utilizando por ejemplo, criterios de protección de autorización o contraseña (por ejemplo, proporcionados al procesador 140 central, el cual a su vez concede selectivamente el acceso a los datos como una función de la información proporcionada mediante la terminal 122 de vendedor) . La terminal 120 de comprador incluye un procesador 124 de comprador adaptada para generar un perfil de comprador y comunicar el perfil generado a un dispositivo 134 de procesamiento de datos en una interfaz 132 de comprador. La interfaz 132 de comprador se adapta para desplegar datos de contrato recibidos del procesador 140. El dispositivo 134 de procesamiento de datos comunica una condición de ' aceptación de datos de contratos como una entrada en la interfaz 132 dé comprador para el procesador. El procesador 140 se acopla a un administrador 110 de contratos cooperativo que proporciona una interfaz para el manejo de transacción de comprador y vendedor que incluye el manejo de precios. El procesador 140 procesa y almacena información de transacción comercial pertinente en la unidad 142 de almacenamiento de datos, con acceso a la misma siendo restringido a usuarios autorizados (es decir, compradores y vendedores autorizados- mediante terminales de comprador y vendedor). r r ~ ". •>
Una o ambas de las terminales 120 y 122 de comprador y vendedor además se adaptan para proporcionar términos de conversión de divisas, que pueden almacenarse en la unidad 142 de almacenamiento de datos (o, en el caso donde se procesa actualmente un contrato, utilizarse directamente por el procesador 140) . Utilizando los perfiles de comprador y vendedor, el administrador 110 de contratos cooperativo establece automáticamente precios para transacciones entré comprador y vendedor, y para al menos uno del comprador y vendedor, establece los parámetros de conversión de divisas. En una implementación, el procesador 140 se interconecta con un sistema 141 de pago que incluye una institución 144 emisora y una institución 152 de pago. Un procesador 145 de emisión de la institución 144 emisora mantiene una cuenta de crédito para la terminal 120 de comprador y debita (extiende la deuda a) una cuenta particular de la terminal de comprador para transacciones manejadas con el sistema 100 de comunicación, tal como el costo del transporte de un producto, el costo del producto y otros. En respuesta a las transacciones manejadas en el procesador 140, un procesador 154 de pago de la institución 152 de pago ofrece el pago a la terminal 122 de vendedor, por ejemplo, cuando el recibo de productos se confirma por un comprador o al momento en que un comprador hace una compra. En otra implementación, el sistema 100 incluye o se adapta para interconectarse con una o más funciones de cambio de divisas, representadas por la función 160 de cambio de divisas. La función 160 de cambio de divisa puede implementarse mediante el procesador 140, el cual puede realizar un cambio de divisa (y evaluar gastos asociados, o se acumulan los gastos en la tasa de cambio) . Las reglas para efectuar el cambio de divisa, en cuanto a como determinar la tasa de cambio de divisa (por ejemplo, utilizando un índice estándar) y otros pueden proporcionarse por el comprador, vendedor u otros participantes en la transacción. El valor de la divisa cambiada se utiliza, donde es aplicable, para comunicar información de pago al sistema 141 de pago. En algunas aplicaciones, la función de cambio de divisa se implementa separadamente del procesador 140, el cual selecciona la función de cambio para ejecutar el cambio, por ejemplo, al seleccionar una compañía de cambio particular, al seleccionar un estándar publicado particular para el tipo particular de divisas que se convierten o al seleccionar un estándar entre aquellos disponibles para la conversión particular. Este cambio externo se implementa en una posición en la cadena de pago que se selecciona como una función de la aplicación. Por ejemplo, cuando el vendedor desea que se le pague en una divisa particular que requiere una conversión, el procesador 140 puede dirigir el sistema 141 de pago a utilizar una fuente particular para ejecutar la función 160 de cambio de divisa. En otras aplicaciones, el sistema 141 de pago realiza el cambio. En otras aplicaciones que involucran una función de cambio externo, el participante o participantes que -realizan el cambio también interactúan con el procesador -140, y en algunos casos con el administrador 110 de contratos cooperativo. Tal participante externo puede implementar además perfiles de usuario y otra información en una forma similar a aquella discutida en lo anterior y como tal puede implementarse con vendedores o compradores mediante terminales 122 ó 120, respectivamente. Por ejemplo, los términos de contrato tales como los términos de tasa de cambio pueden establecerse utilizando reglas comerciales relacionadas con la tasa de cambio, con el administrador de contratos cooperativo utilizando reglas comerciales para llegar a una tasa de cambio aceptable. Las reglas comerciales utilizadas para establecer una tasa de cambio se seleccionan como una función de los participantes que llevan a cabo el cambio. Por ejemplo, donde un vendedor en la terminal 122 de vendedor solicita que se le pague en una divisa particular, las reglas comerciales para ese vendedor y la entidad que realiza el cambio pueden utilizarse para establecer la tasa de cambio. En varias implementaciones, una entidad que maneja el procesador 140 puede interactuar como un intermediario entre un participante de compra o venta y una "entidad de cambio de divisa. Aquí, los participantes de compra o venta llegan a un acuerdo de cambio de divisa con la entidad que maneja el procesador 140. A su vez, la entidad que maneja el procesador 140 puede tener un acuerdo diferente con una entidad de cambio de divisa. En ese respecto, el participante de compra o venta recibe una tasa de cambio acordada mediante el procesador 140, y la entidad de manejo ejecuta el procesador que ejecuta el cambio en una tasa acordada con la entidad de cambio de divisa. En este respecto, la entidad de manejo que ejecuta el procesador 140 puede negociar una tasa de cambio preferencial utilizando su alto volumen (como generado por una pluralidad de participantes dé''' compra y venta) , y cargar a las entidades de compra y venta una tasa de cambio menos preferencial. La FIGURA 2 muestra una disposición 200 de procesamiento de transacciones que incluye un procesador 210 de transacciones programado para procesar automáticamente aspectos de conversión de divisa de una transacción, de acuerdo con otra modalidad ejemplar de la presente invención. El procesador 210 de transacciones está en comunicación con una base de datos 212 y un motor 214 de asignación- de tasa de cambio. La base de datos 212 almacena la 'información relacionada con la transacción que incluye las reglas para la conversión de divisas, así como la información de auditoria para las conversiones de divisa individuales como se puede aplicar a una o más transacciones. El motor 214 de conversión de divisas procesa los aspectos relacionados con la conversión de divisas de una transacción que utiliza reglas de la base de datos 212 y en la dirección del procesador 210 de transacción. En varias implementaciones, la base de datos 212 y/o el motor 214 de asignación de tasa de-ida'mbid se implementa como parte del procesador 210 de transacción. En otras implementaciones, uno o ambos de la base de datos 212 y el motor 214 de asignación de tasa de cambio se localizan en una ubicación remota y/o incluyen una pluralidad de :circuitos en diferentes ubicaciones. Una pluralidad de nodos 220, 222, 224, 226 y 228 de usuario se acoplan comunicativamente con el procesador 210 de transacción. Los nodos 220-228 de usuario por ejemplo, pueden incluir uno o más de un comprador, vendedor, distribuidor, transportista marítimo, transportista terrestre, agencia gubernamental, institución financiara u otro tipo de individuo, grupo o agencia que puede involucrarse- en 'una transacción. Con referencia a la FIGURA 1 como un'"ejemplo una o más de la terminal 122 de vendedor, terminal 120 de comprador, procesador 140, sistema 141 de pago o entidad de cambio de divisa que efectúa la función 160 de cambio de divisa pueden implementarse en uno de los nodos 220-228 de usuario . En otra implementación, el procesador 210 de transacción se adapta para aplicar automáticamente reglas de divisas para asignar tasas de cambio de divisa- u otros parámetros a una transacción cuando se recibe o ejecuta -una nueva información de transacción. Esta nueva información de transacción por ejemplo, puede detallarse en un documento de transacción tal como un pedido o factura. Las reglas de divisa se utilizan por el motor 214 de asignación de cambio de tasa de cambio para asignar la tasa de cambio a la transacción o a una porción de la transacción a la cual aplica la tasa de cambio. Cuando una actualización para las reglas de divisa se recibe en el procesador 210 de transacción (por ejemplo, mediante uno de los nodos 220-228 de usuario) , una nueva llamada para asignar una tasa de cambio a una transacción se hace por el procesador y se hacen las actualizaciones correspondientes. Por ejemplo, cuando una transacción para un usuario particular se ha asignado un parámetro de tasa de cambio particular y ese usuario ingresa a una actualización en las reglas de divisas utilizadas para asignar el parámetro de tasa de cambio, el procesador 210 de transacción actualiza automáticamente el parámetro asignado a la transacción. Opcionalmente, el usuario que proporciona la actualización de regla de asignación controla selectivamente la aplicación de las reglas actualizadas, por ejemplo, donde el usuario desea aplicar selectivamente las reglas actualizadas- '-a nuevas transacciones . Los nodos 220-228 de usuario pueden interactuar con el procesador 210 de transacción para proporcionar una variedad de diferentes tipos de información relacionada con la transacción. Tal información de transacción puede incluir por ejemplo, parámetros de cambio de divisa, reglas de contabilidad, pedidos, facturas, documentos de transporte marítimo, autorización de pago, ejecución de pago,' documentos de aduana, documentos de seguridad y otros. El procesador 210 de transacción registra, en la base de datos 212, la información relacionada con la conversión de divisa para facilitar la auditoria de transacciones individuales y/o en grupo que involucran conversión de divisa. Esta información puede incluir uno o más de una variedad de tipos de información, con ejemplos aplicables a la FIGURA 2 que incluyen "pagar a" tipo de divisa y cantidad, "facturar a" tipo de divisa y cantidad, fecha/tiempo de conversión y tasa de conversión. Cuando las entidades externas en los nodos 220-228 (u otras, tal como una entidad reglamentaria) se le permite acceder a la base de datos 212, la información de auditoria se hace fácilmente disponible (por ejemplo, para cumplimiento coh reglas relacionadas con Sarbanes-Oxley) . La fecha y la tasa de conversión se aplican selectivamente a uno o ambos de las porciones "pagar a" y "facturar a" de la transacción como una función de los tipos de divisas y/o reglas comerciales asociadas con participantes en una transacción particular. Donde una transacción involucra solamente una conversión de divisa (es decir, entre una divisa de facturación y pago) , el procesador 210 de transacción realiza una conversión de divisa junto con lá porción de transacción relevante con la conversión de divisa. El sistema 200 puede implementarse utilizando una pluralidad de nodos y disposiciones, y se puede aplicar a una variedad de procedimientos de procesamiento de transacción.-Sin embargo, para propósitos de discusión, cada uno de los nodos de usuario se implementa como sigue junto con una transacción particular. El nodo 220 es un nodo de comprador que representa un comprador en una transacción y el nodo 222 es un nodo de vendedor que representa un vendedor. Los nodos 224, 226 y 228 representan respectivamente instituciones financieras para un comprador, un vendedor y un participante de transacción alternativo, tal como un poseedor/operador del procesador 210 de transacción. En algunos casos, -'los fondos transferidos junto con el procesador 210 de transacción se hacen directamente entre las instituciones 224 y 226 financieras del comprador y vendedor. En otros casos, algunos o todos los fondos transferidos junto con el procesador 210 de transacción se procesan a través de la institución 228 financiera. El comprador 220 y el vendedor 222 proporcionan reglas comerciales que se almacenan en la base de -'"-datos 212 para su utilización por el procesador 210 de transacción: Cuando un evento de inicio de transacción tal como una solicitud de productos y/o servicios por el comprador 220 ocurre, el procesador 210 de transacción recupera y utiliza las reglas comerciales para derivar un término para utilización en establecer un precio para la transacción. Por ejemplo, donde el comprador 220 y el vendedor 222 almacenan reglas comerciales que indican una relación e información contractual para establecer un precio, el procesador 210 de transacción deriva un término de precio, tal como el precio por unidad, para la transacción. El procesador 210 de transacción recibe los datos del evento de inicio de transacción con una función 230 de recepción de datos de transacción y correlaciona los datos de evento con un usuario particular (por ejemplo, el comprador 220 y/o el vendedor 222) con una función 231 de correlación. Tales datos de evento pueden incluir, por ejemplo, un pedido o una factura que se refiere a una transacción entre usuarios. La correlación puede involucrar, por ejemplo, correlacionar los datos de eventos con un usuario particular o con una transacción particular utilizando un término dé identificación de producto que se asocia con productos y/ó servicios para la transacción. Una función'*•'- 232 • dé recuperación de reglas implementa la información de usuario correlacionada para recuperar reglas comerciales que se pueden aplicar al evento de transacción a partir de la base de datos 212 (por ejemplo, recuperar reglas comerciales etiquetadas o de otra forma asociadas con la información de usuario correlacionada) . Un motor 233 de precio utiliza las reglas comerciales recuperadas para establecer un preció-.' "para ía transacción en una primera divisa, por ejemplo, al utilizar información de precio de contrato en las reglas comerciales o al calcular un precio utilizando términos en las reglas comerciales y otras características de la transacción tales como cuestiones de cantidad, transporte o reglamentaria. El motor 233 de precio utiliza información en documentos (por ejemplo, los datos de evento de inicio de transacción) para identificar esas reglas en las reglas recuperadas para utilizarse en establecer el precio. Tal información puede incluir por ejemplo, un identificador de contrato que identifica un contrato específico al cual aplica la información, un identificador de artículos que identifica un artículo para el cual se establece el precio, un código de divisa que identifica la divisa en la cual se denomina la cantidad de la transacción y la fecha de pedido. Utilizando esos procedimientos, el precio establecido mediante el motor de precio es el precio "para pagar" que se le pagará al vendedor 222. Una función 234 de recuperación de tasa de cambio recupera una tasa de cambio utilizando las reglas comerciales y el motor 214 de asignación de tasa de cambio. En algunos casos, el motor 214 de asignación de tasa de- cambio- se implementa funcionalmente con la función 234 de recuperación de tasa de cambio. Las reglas comerciales pueden especificar un procedimiento particular para asignar una tasa de cambio, tal como al identificar un estándar de conversión particular para utilizar (por ejemplo, un estándar publicado) , o al identificar un estándar de conversión utilizando la entrada recibida de uno o más del comprador y vendedor. Después de que se ha establecido la tasa de cambio, una función 235 de precio de cambio establece el precio por la transacción en una segunda divisa. Este precio es el precio de "facturar a" que el comprador 222 se le facturará por la transacción. La transferencia de fondos entre las instituciones 224, 226 financieras y en algunos casos, 228 se lleva a cabo de acuerdo con el procedimiento anterior. Por ejemplo, donde las instituciones 224 y 226 financieras son respectivamente las instituciones financieras del comprador y el vendedor, los fondos en la cantidad "facturar a" se transfieren desde la institución financiera del comprador y los fondos en la cantidad de "pagar a" se transfieren a la institución financiera del vendedor. En algunos casos, las reglas comerciales en la base de datos 212 indican que -una de las instituciones financieras del comprador y vendedorí'llevará a cabo una conversión de divisa. En otros casos, las reglas comerciales especifican que una tercera institución 228 financiera lleve a cabo la conversión de divisa. En algunas aplicaciones, el procesador 210 de transacción además lleva a cabo las funciones de liquidación para transacciones, que incluye, por ejemplo, funciones que se refieren a las funciones de contabilidad y pago. En un ejemplo de función de contabilidad, cuando el vendedor 222 se le paga a nombre del comprador 220 (con características de conversión de divisa apropiadas), el procesador 210 de transacción automáticamente envía por correo el pago contra un registro de cuentas por cobrar para el vendedor 222 (por ejemplo, almacenada en la base de datos 212, en el vendedor 222 o en algún otro lugar) . En una función de pago ejemplar, el procesador 210 de transacción selecciona una fuente de financiamiento para pagar al vendedor 222 y por consiguiente, lleva a cabo las funciones de liquidación de pago para retirar los fondos del comprador 220. Estos fondos pueden retirarse directamente (por ejemplo, de la institución 224 financiera del comprador) o indirectamente mediante un procedimiento de extensión de crédito, tal como ai disminuir una línea de crédito para el comprador. E? algunas aplicaciones, los fondos se retiran directamente y por consiguiente se proporcionan directamente al comprador 222. En otras aplicaciones, los fondos se proporcionan al vendedor 222 a nombre del comprador 220, con la función de liquidación de pago siendo llevada a cabo subsecuentemente para recuperar fondos del comprador para cubrir el pago por el vendedor (por ejemplo, para cubrir los gastos de procesamiento y/o conversión) . En algunas implementaciones, el procesador 210' de transacción lleva a cabo la conversión de divisa utilizando, por ejemplo, la tercera institución 228 financiera. Los fondos asociados con la cantidad de "facturar a" recibida de la institución 224 financiera del comprador se transfieren a la tercera institución 228 financiera, y los fondos en la cantidad de "pagar a" se transfieren desde la misma institución 228 financiera (u otras) y se transfieren a la institución 226 financiera del vendedor. Mientras una variedad de funciones de pago relacionadas con la conversión de divisas pueden incrementarse con el procesador 210 de transacción, con algunos ejemplos de estas funciones discutidas en lo anterior, el procesador de transacción registra los- datos de auditoria con respecto a cada conversión. Estos datos pueden almacenarse, por ejemplo, en la base de datos 212 o proporcionarse a uno o más de los nodos 220-228. Datos de auditoria ejemplares incluyen uno o más de las cantidades "facturar a" y "pagar a" (y tipos de divisas), así como la fecha de transacción, la información de tasa de cambio y más como se discute en lo anterior y otros aspectos. En una implementación más particular, el procesador 210 de transacción además proporciona información de conciliación para aminorar las discrepancias de facturas y otras con relación a las conversiones de divisa. Las discrepancias pueden surgir por ejemplo, donde la transacción es susceptible a fluctuación en la tasa de cambio., de ' divisa.. Otras discrepancias (o la posibilidad de discrepancias) surgen cuando características de tiempo de una transacción particular afectan la tasa de cambio; y en estos casos, el procesador 210 de transacción registra el tiempo utilizado para determinar la tasa de cambio. Gastos asociados con la conversión pueden evaluarse para el comprador 220 y/o el vendedor 222 utilizando uno o más de una variedad de procedimientos. Esos gastos pueden acumularse en la conversión de divisa para la cantidad de "facturar a" o evaluarse separadamente para el vendedor 222 y/u otro participante y por ejemplo, puede basarse en reglas comerciales almacenadas en la base de datos 212. Varias bases pueden utilizarse para determinar que porción financiera de una transacción particular va a utilizarse para evaluar gastos (o, por consiguiente realizar el cambio de divisa con gastos acumulados) . Por ejemplo, en el caso donde una transacción utiliza la cantidad - dé "facturar a" como la base para realizar una conversión de divisa, una cantidad de transacción particular es acordada en términos de la divisa del comprador. Al utilizar los nodos 220 y 222 respectivamente como los nodos de comprador y vendedor nuevamente, el procesador de transacción facilita la facturación del comprador 220 en la cantidad de transacción (cantidad de "facturar a") en una primera divisa. Una conversión de divisa entonces se hace de la divisa de "facturar a" a la divisa de "pagar a", con la divisa "pagar a" siendo proporcionada al vendedor 222. Los gastos asociados con esta conversión de divisa por ejemplo, pueden acumularse en la conversión o evaluarse separadamente en el vendedor y/u otro participante (por ejemplo, basándose en reglas comerciales) . Una variedad de otros aspectos relacionados con la transacción pueden implementarse con el sistema 200 como se discute en lo anterior u otros aspectos. En algunos casos, uno o más de los nodos 220-228 de usuario incluyen interfaces de entrada de control (por ejemplo, interfaces gráficas de usuario) que se comunican con el procesador 210 de transacción, con usuarios en los nodos siendo capaces de proporcionar información relacionada con transacción tales como reglas de cambio de divisa. En otros -casos, el procesador 210 de transacción accesa automáticamente la información de los nodos de usuario por una variedad de propósitos, tal como recuperar reglas de intercambio de divisas (por ejemplo, tasas, fuentes de tasas o fuentes de cambio) o actualizando campos relacionados. Esta interacción entre los nodos y el procesador 210 de transacción se controla utilizando por ejemplo, autorización para el acceso tal como una autorización protegida por contraseña"" y otros. Dependiendo de la aplicación, el procesador 210 de transacción evalúa los gastos para uno o más de los nodos 220-228 de usuario. En algunos casos, estos gastos se acumulan en los tipos de cambio de divisa de las transacciones. En otros casos, los gastos se basan en un porcentaje de la cantidad de pago para una transacción. En aún otros casos, los gastos involucran un gasto basado en la cantidad de pago por una transacción así como una cantidad que se refiere a una conversión de divisa. Estos gastos pueden aplicarse a uno o más de los participantes en la transacción, dependiendo de la naturaleza de la transacción, los acuerdos de contrato con los participantes de la transacción y otras consideraciones. Por ejemplo, algunas implementaciones de transacción que involucran compradores y vendedores se procesan de manera que el vendedor paga todos los gastos asociados con una transacción particular. Los gastos de procesamiento tales como estos se asignan para el operador del procesador 210 de transacción, lo cual puede ser una entidad separada de cualquier transacción o que es parte integral en la transacción, tal como una institución financiera relacionada con uno de los participantes de transacción. En otra modalidad ejemplar, el procesador 210 de transacción además se adapta para conceder y controlar el intercambio de información con la base de datos 212 como una función de las entradas recibidas de los nodos 220-228, tal como las entradas de autorización y las entradas específicas de transacción. Cuando usuarios de uno de los nodos 220-228 intentan enviar información a o recuperar información del procesador 210 de transacción, 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 ejemplo, una contraseña o ID de usuario) o información de documento simple que reconoce el procesador 210 de transacción. El procesador 210 de transacción se configura y dispone para subcontratar conversiones de divisas al por mayor que involucran dos o más transacciones, de acuerdo con otra modalidad ejemplar de la presente invención. Por ejemplo, donde múltiples transacciones involucran conversión entre una primera divisa y una segunda divisa, el procesador 210 de transacción puede tener selectivamente una suma en volumen de fondos convertidos, en proporción con la suma combinada de las múltiples transacciones de una institución financiera externa. El procesador 210 de transacción entonces puede efectuar el pago y la liquidación por las transacciones, utilizando los fondos convertidos para todas las transacciones múltiples. En algunas aplicaciones, el procesador 210 de transacción convierte los fondos para cada transacción utilizando una tasa de conversión que es mucho mayor que la tasa de conversión obtenida para la conversión en volumen, manteniendo una diferencia neta en fondos como un gasto de transacción para realizar la conversión, por cada transacción. Además, las tasas de conversión para diferentes participantes en la transacción entre múltiples transacciones puede aplicarse en forma diferencial por ejemplo, como relevante a contratos entre los participantes de transacción y un operador del procesador 210 de transacción. Las tasas de conversión además pueden seleccionarse, para cada participante de transacción, a partir de un margen de tasas interpretadas aceptables en un contrato con cada participante de transacción. Estas tasas y sus aplicaciones se implementan utilizando reglas comerciales por cada participante de transacción, como es apropiado, para el procesador 210 de transacción. La FIGURA 3 es un diagrama de flujo que ilustra un procedimiento ejemplar para el manejo de transacción automatizado que involucran conversión de divisas, de acuerdo con otra modalidad ejemplar de la presente invención. La información relacionada con la transacción para una función de precios se recibe en el bloque 300. Esta información relacionada con la transacción puede incluir, por ejemplo, un pedido o factura electrónica, u otra información que- describe las características del precio o divisa para una transacción particular o porción de una transacción. La información relacionada con la transacción también incluye datos de identificación para por lo menos un participante de transacción. En el bloque 310, la información relacionada con la transacción se asocia con participantes de transacción que utilizan los datos de identificación, los cuales pueden incluir uno o más de una variedad de informaciones que pueden utilizarse para identificar uno o más participantes de transacción. Por ejemplo, los datos en un documento electrónico pueden utilizarse para identificar la fuente del documento, la cual entonces se identifica como una de las partes de la transacción. Los datos también pueden utilizarse para identificar directamente una transacción a¡ - la cual aplica los datos utilizando, por ejemplo, un número de ID de transacción. Además, los datos pueden utilizarse indirectamente para identificar una transacción a la cual aplica, con una o más características de la transacción siendo aseguradas y asociadas con una transacción particular (por ejemplo, donde una cierta cantidad de datos de correlación se utiliza para definir una correlación entre los datos y una transacción) . ' Un término de precio se establece utilizando reglas comerciales para uno o más participantes en la transacción en el bloque 320, y un precio por la transacción se establece utilizando el término de precio en el bloque 330. Después de que se ha establecido el precio, un precio de "pagar a" se deriva en el bloque 340, representando el precio (en una primera divisa) que va a pagarse a un participante de transacción de vendedor. En el bloque 340, las reglas comerciales de los participantes de transacción se utilizan para establecer reglas de conversión de divisas. Las reglas de conversión de divisas pueden incluir, por ejemplo, una o más de las reglas y características asociadas antes discutidas con la conversión de divisas tal como una tasa de conversión, tipo de divisa y fuente de cambio. En el bloque 350, una tasa de conversión de divisas se recupera de una fuente de tasas, tal como una fuente de tasas públicamente disponible, y se utiliza para establecer una tasa de conversión de divisa. En el bloque 360, el precio derivado de "pagar a" se convierte en una divisa diferente en un precio de "facturar a" utilizando la tasa de conversión de divisa establecida, el precio de "facturar a" se factura para un participante de transacción de comprador. " •' ¡
Después de que se ha establecido el precio de "facturar a", se procesa el pago en el bloque 370, con el participante de transacción de comprador siendo facturado en la cantidad de "facturar a" y el participante de transacción de vendedor se le paga en la cantidad de "pagar a". Los fondos de cada divisa separada para la cantidad "facturar a" y "pagar a" se cobra típicamente y se paga de una fuente financiera común, la cual retira el valor de la conversión. En algunas implementaciones, una entidad de procesamiento de pago facilita la recepción y pago de los fondos de "facturar a" y "pagar a" al cambiar un cargo de deuda con diferentes instituciones financieras. Por ejemplo, donde la entidad de procesamiento de pago se le deben fondos en la divisa de "pagar a" de un primer banco, los fondos en la cantidad de "pagar a" puede transferirse desde el primer banco al participante de transacción de vendedor. La entidad de procesamiento de pago entonces toma como recibo los fondos del participante de transacción de comprador en la cantidad "facturar a" y divisa. Similarmente, cuando la entidad de procesamiento de pago debe fondos en la divisa de "facturar a" a un acreedor, el pago en la cantidad "facturar a" del participante de transacción de comprador (o la institución financiera asociada) puede dirigirse al acreedor, con la entidad de procesamiento de pago pagando al participante de transacción de vendedor la cantidad de "pagar a" en la divisa de "pagar a". En el bloque 380, los datos de auditoria se registran para propósitos de seguimiento con relación a la conversión de divisas y la transacción en la cual se implementa. Por ejemplo, la divisa y la cantidad dé "pagar a "y "facturar a" se almacenan, así como la información que puede utilizarse para corroborar una tasa de conversión de divisa, tal como los datos y la tasa de conversión. La información de fecha de conversión además se almacena como relevante para una zona de tiempo particular, de manera que transacciones con participantes en diferentes zonas de tiempo pueden facilitarse. La zona de tiempo particular (así como otros parámetros de conversión de divisas), por ejemplo, pueden recuperarse con las reglas comerciales en el bloque 320. En otra modalidad ejemplar, los gastos asociados con los cambios en el presupuesto contra las tasas de conversión actuales se registran y, en algunos -casos, se evalúa un código de gasto particular. Por ejemplo, " cuando un participante de transacción realiza un presupuesto de una tasa de conversión particular para aplicar a una transacción pero la transacción se lleva a cabo en una tasa de conversión diferente, un incremento o disminución en los fondos asociados con una divisa que se convierte se registra como un gasto. Este gasto se registra apropiadamente como especificado por las reglas comerciales del participante de transacción. Con referencia a la FIGURA 3 y como se1'- entiende junto con la misma, un procedimiento de gastos de cambio de tasa ejemplar se muestra junto con el bloque 390, implementado selectivamente con el procedimiento discutido en lo anterior junto con los bloques 300-380. Una diferencia (si la hubiera) entre una tasa de conversión de divisa presupuestada y real se refleja como gastos en el bloque 390 como se especifica por las reglas comerciales implementadas en el bloque 320. Como consistente con la discusión anterior, las reglas comerciales pueden utilizarse para asignar un código de gastos particular, dirigir el registro de los datos de gastos con relación a la conversión y/o evaluar los gastos contra un participante apropiado. En estas aplicaciones, la erogación de gastos en el bloque 390 se evalúa contra ese participante particular que carga con los gastos. En algunas aplicaciones, erogar cualquier diferencia en el bloque 390 también incluye enviar por correo un sistema de manejo de registros financieros por lo menos para un participante en la transacción (por ejemplo, al cual aplica los gastos de conversión) en una forma consistente con la otra discusión en la presente. Este envío por correo puede involucrar, por ejemplo, registrar información en un banco de datos disponible para participantes de transacción apropiados, o enviar datos que representan los gastos a una ubicación de contabilidad del participante de transacción apropiado, tal como en uno de los nodos 220-228 en la FIGURA 2. Los procedimientos de procesamiento de transacciones discutidos en lo anterior pueden implementarse junto con una variedad de tipos de transacciones comerciales que involucran la transferencia de fondos, que incluyen aquellas discutidas en lo anterior y otras. En este respecto, para información general con respecto al procesamiento de transacciones y para información específica con respecto a las transacciones y procedimientos tipo transporte marítimo con los cuales los procedimientos de conversión de divisas de la presente invención pueden implementarse, puede hacerse referencia a la Patente Norteamericana No. 5,901,896 para Hahn-Carlson, la cual se incorpora en la presente completamente para referencia. 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, aspectos de los cuales se establecen en las siguientes reivindicaciones.