MX2007002075A - Metodo y sistema para la autorizacion y establecimiento de pagos automaticos. - Google Patents

Abstract

La presente invencion provee un sistema y metodo para permitir que un proveedor de servicios de terceras partes de los servicios de PFEP (130 degree ) inicien autorizacion y establecimiento de pagos de tarjetas de pagos de datos del articulos de linea de factura (datos de Nivel III); a favor del Comprador/Pagador (110) o Proveedor/Beneficiario (130), a quien adquiere tarjetas de credito (100) y/o procesadores de transaccion (160). Iniciacion de pagos aprobado por la organizacion de Comprador/Pagador (110) y programado para pago (665).

Description

MÉTODO Y SISTEMA PARA LA AUTORIZACIÓN Y ESTABLECIMIENTO DE PAGOS AUTOMÁTICOS ESPECIFICACIÓN REFERENCIA CRUZADA A LA SOLICITUD RELACIONADA Esta solicitud reclama prioridad a la Solicitud Provisional de Estados Unidos No. 60/604,215, presentada el 8/25/2004, titulada "Automated Payment Authorization and Settlement", que reclama prioridad a la Solicitud de Patente de Estados Unidos, No. 10/465394, presentada el 6/18] /2003, titulada "System and Method for Integrated Electronic Invoice Presentment and Payment", amas de las cuales se incorporan aqui por referencia. Esta solicitud también reclama prioridad para la Solicitud Provisional de los Estados Unidos No. 60/623,656, presentada el 29 de octubre de 2004, titulada "Method and System For Automated Payment Authorization and Settlement", la totalidad de la cual también se incorpora aqui por referencia.

ANTECEDENTES DE LA INVENCIÓN Esta invención se refiere a un método y sistema para autorización y liquidación de pagos automáticos.

Se han hecho intentos para automatizar los procesos de facturación y pagos mediante el uso de proveedores de servicios de terceras partes (PS3P) . Los PS3P incluyen proveedores de procuración electrónica tales como Apba™, proveedores de presentación de factura electrónica y pagos (PFEP) tales como Xmg™, y planeación de recursos de la empresa ("PRE") tal como OraclerM. Estas soluciones iniciales de PS3P enfocadas en las necesidades del Proveedor/beneficiario/pagador y no dirige adecuadamente las necesidades del Comprador/Pagador/pagador. Por ejemplo, las muchas soluciones de PS3P tempranas no dirigen las necesidades relacionadas con pagos del Comprador/Pagador/pagador, de tal manera que controla eficientemente y efectivamente la iniciación de pagos, difiere de sus a ustes de establecimiento, y los reconcilia e integra en los sistemas financieros del Comprador/Pagador. Además, las soluciones de PS3P existentes no tienen tarjetas de pago típicamente utilizadas, tales como tarjetas de crédito, tarjetas de débito, tarjetas corporativas, o tarjetas de compra, como medios de pagos de negocio a negocio. Además, estas soluciones de PS3P no permiten el uso de términos de pagos asociados con el pago mediante tarjetas de pago y la validación de reglas de facturación de Comprador/Pagador antes de pagar mediante tarjeta de pago.

Además, las soluciones de PS3P existentes no son capaces de la integración automática de datos de tarjetas de pago en un sistema interno de organización, tales como su PRE o sistemas de cuentas por pagar ("C/P"). Consecuentemente, las organizaciones son forzadas a facturar datos volviendo a teclear manualmente los datos de facturas, los igualan con la transacción de tajea para fines de reconciliación y luego introducen manualmente los datos en el PRE de la organización o sistema de C/P. Este proceso es tardado y propenso a error humano . Algunas soluciones existentes de PS3P pueden utilizar intercambio de datos electrónico financieros (IDE) u otras tecnologías de pago electrónico. Sin embargo, estos métodos de pago pueden requerir importantes costos de establecimiento, incluyendo cambios costosos a sistemas y procesos internos, y puede requerir cambios en elaciones de bancos . Por lo tanto, existe una necesidad de un método y sistema de PFEP automáticos que son efectivos en costos, sencillos de integrar en procesos y sistemas existentes, y permite el pago eficiente y reconciliación de registros financieros . En la Solicitud de patente de E.U.A. No. 10/465394, MasterCard presentó un sistema y método de presentación y pago de facturas electrónicas automáticos que utilizan una tarjeta de compras como un método posible de pago. La presente invención mejora sobre dicha solicitud previa. De acuerdo con la presente invención, los PS3P que proveen procuración y/o facturación electrónicas ahora pueden permitir que sus clientes establezcan transacciones automáticamente en una cuenta de tarjeta de crédito MasterCard, permitiendo así que sus clientes realicen una orden de compra ("OC") o compras basadas en facturas en términos de créditos bancarios . El beneficio de los pagadores de términos de pago retardados y oportunidad para recibir rebates de volumen de bancos de expedición. El beneficio de proveedores de la recepción de pagos electrónicos (comparado con los costos de revisiones de procesos) y la oportunidad para datos del Nivel III (para recibir régimen de descuentos inferiores) sin invertir adicionalmente en hardware o software. Las instituciones financieras y sus procesadores se benefician de los grandes volúmenes de transacciones procesadas. Ejemplos de adquisición de instituciones y procesadores de transacciones son Citibank, First Data Corporation, Global Payments, y Bank of America.

SUMARIO DE LA INVENCIÓN La presente invención provee un sistema y método para permitir que un PS3P inicie autorización y establecimiento de pagos de tarjetas de pago con datos de artículos de líneas de facturación (datos de Nivel III) , a favor de Comprador/Pagadores/pagadores o Proveedor/beneficiarios de los que adquieren tarjetas de crédito y/o procesadores de transacción. La iniciación del pago se basa en la presentación de: una factura preaprobada u confirmación de pedido validada contra un pedido de compra, o una factura aprobada por la organización de Comprador/Pagador/pagador y programada para pago.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Fig. 1 es un diagrama de bloques que ilustra un sistema ilustrativo para autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pago, las cuales el pagador inicia el pago; La Fig. 2 es una gráfica de flujo que ilustra un método ilustrativo para la autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pagos, en las cuales el pagador inicia el pago; La Fig. 3 es un diagrama de bloques que muestra un sistema ilustrativo para la autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pago, en las cuales el pagador inicia el pago.

La Fig. 4 es una gráfica de flujo que ilustra un método ilustrativo para la autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pago, en las cuales se inicia el pago por el beneficiario; La Fig. 5 es una gráfica de flujo que ilustra el establecimiento inmediato de una transacción de tarjeta de compra iniciada por una orden de compra de acuerdo con una modalidad ilustrativa de la presente invención; La Fig. 6 es una gráfica de flujo que ilustra el establecimiento retardado de una transacción de tarjeta de compra iniciada por la orden de compra ("OC") de acuerdo con una modalidad ilustrativa de la presente invención; La Fig. 7 es una gráfica de flujo que ilustra el establecimiento retardado de una transacción de tarjeta de compra, de acuerdo con una modalidad ilustrativa de la presente invención; La Fig. 8 es una gráfica de flujo que ilustra un proceso ilustrativo de autorización de vía de acceso de SM y establecimiento de acuerdo con la presente invención; y La Fig. 9 es una gráfica de flujo que ilustra un proceso ilustrativo para manejar autorizaciones rechazadas de MS de acuerdo con la presente invención.

DESCRIPCIÓN DETALLADA DE LA INVENCIÓN Las Figs. 1 y 3 son diagramas de bloque que ilustran sistemas ilustrativos para la autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pago. En la modalidad ilustrativa descrita en la Fig. 1, el pago se inicia por el pagador, mientras que en la modalidad descrita ilustrativamente en la Fig. 3, el pago se inicia por el beneficiario. Haciendo referencia a las Figs. 1 a 3, un Comprador/Pagador 110 es la parte que compra un producto o servicio de un Proveedor/Beneficiario 130. Cada uno de Comprador/Pagador 110 y Proveedor/Pagador 130 incluye preferiblemente un sistema de PRE 110a y 130a, respectivamente. Un Proveedor de Software 120 es un PS3P que provee procuración electrónica, facturación, presentación y/o pago de servicios, tales como, por ejemplo, un sistema de PFEP 120a. Por ejemplo, el Proveedor de Software 120 podría ser Xign Corporation™ que provee una solución de PFEP de MasterCard e-P3™. Un Adquiridor/Procesador 160 es una institución financiera o un procesador de transacciones que procesa transacciones de tarjetas de pago. Una Red de Pagos 170 es una red de tarjeta de pagos, tal como la red de pagos de MasterCard . Una vía de acceso de pagos de servicios 'mercantiles ("SM") 170a es una vía de acceso a través de la cual preferiblemente se procesan la autorización y establecimiento para transacciones de tarjetas de pago. Un Banco de Expedición 140 es un banco que expide una tarjeta de pagos al Comprador/Pagador 110. Un SIA 150 es el sistema de información administrativo del Banco de Expedición 140. Un dispositivo de PDV 310 en la Fig. 3, es una terminal de punto de venta, o cualquier sistema convencional similar, que acepta datos financieros en o cerca del sitio del Proveedor/Beneficiario y transmite los datos a una red de pagos para reportar registro de actividad, autorización y transacción . La Fig. 2 es una gráfica de flujo que ilustra un método ilustrativo para la autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pagos, en donde el pago se inicia por el Comprador/Pagador 110. Haciendo referencia a las Figs. 1 y 2, en el paso 210 el PRE del Comprador/Pagador 110a aprueba y programa el pago para una factura. En esta modalidad, el PRE del Comprador/Pagador 110a puede ser, pro ejemplo, un sistema que puede pagarse por Oracle. En el paso 220, el Proveedor del Software 120 extrae un archivo de pago del PRE del Comprador/Pagador 110a y envía el archivo del pago al Adquiridor/Procesador 160 para autorización y establecimiento del pago. Por ejemplo, el archivo del pago puede ser extraído del sistema financiero del Comprador/Pagador 110a que puede Pagarse por Oracle mediante Oracle íPayment™, un proveedor de e-P3™ de MasterCard. El archivo de pagos incluye una ID mercantil, información de cuenta de tarjeta de pago, una ID única de transacciones para reconciliación de facturas de PRE, y puede contener datos de artículos de línea de facturas (Datos de Nivel III) . La ID Mercantil puede adquirirse durante un proceso para registrar al Proveedor/Beneficiario 130. El Proveedor del Software 120, tal como Oracle íPayment™, puede obtener información de la cuenta de pagos de cualquiera de Comprador/Pagador, v.gr., que pueden Pagarse por Oracle, o desde la interfase de pago de 12a del Proveedor del Software 120. En el paso 230, se presentan las solicitudes de pago de la tarjeta e pago del Comprador/Pagador 110 a la Red de Pagos 170, tal como, por ejemplo red de pagos de MasterCard, para autorización y establecimiento. En el paso 240, se proveen los datos de establecimiento de tarjeta de pago al Comprador/PagadorllO vía cualquier aplicación de SIA 150 del Banco de Expedición o directamente de la red de pago 170. Los datos de establecimiento de tarjetas de pago incluyen preferiblemente la única ID de transacción del archivo de pagos (véase el Paso 220) . En el paso 250, el Proveedor del Software 120 provee datos de remisión de pagos, incluyendo la ID única de transacciones, al Proveedor/Beneficiario 130 para la Adquiridor/Procesador 160. Por ejemplo, los datos de remisión de pagos pueden proveerse al Proveedor/Beneficiario 130 por un proveedor de e-P3""' tal como Oracle ?PaymentTí para reconciliación con su declaración del banco. Finalmente en el paso 260, el Comprador/Pagador 110 establece las transacciones de la tarjeta de pagos con el Bando de Expedición 140 al final del ciclo de facturación. La Fig. 4 es una gráfica de flujo que ilustra un método ilustrativo para la autorización y establecimiento de pagos automáticos de transacciones de tarjetas de pago, en donde el pago se inicia por el Proveedor/Beneficiario 130. Haciendo referencia a las Figs. 3 y 4, en el paso 410 la PRE del Comprador/Pagador 110a aprueba y programa pagos para una factura. En el paso 420, el Proveedor del Software 120 extrae un archivo de pagos del sistema de PRE del Comprador/Pagador 110a y transmite (v.gr., por correo electrónico) el archivo de pagos al Proveedor/Beneficiario 130 para la autorización y establecimiento de pagos. El archivo de pagos incluye una ID mercantil, información sobre la cuenta de tarjetas de pago, una ID única de transacciones usada para reconciliación de facturas de PRE, y puede contener datos de artículos de línea de facturas (datos de Nivel III) . La DI Mercantil se adquiere durante un proceso para registrar al Proveedor/Beneficiario 130. El Proveedor del Software 120 obtiene información de cuenta de tarjeta de pagos de cualquiera de la PRE del Comprador/Pagador 110a, o de la inferíase del pago del Proveedor del Software 120a. En el paso 430, la tarjeta del pago de presentaciones del proveedor/Beneficiario 130 y otra información de transacción al Adquiridor/Procesador 160 vía un dispositivo PDT 310 con el fin de autorización y establecimiento. El Adquiridor/Procesador dirige la información de autorización y establecimiento a través de la red de pago 170. En el paso 440, el Proveedor del Software 120 envía datos de artículos de línea de facturas, incluyendo la DI única de transacciones, directamente a la red de pagos 170 con fines de igualación. En el paso 450, los datos de declaraciones de tarjetas de pago se proveen al Comprador/Pagador 110 vía la aplicación de SIA 150 del Banco de Expedición o directamente de la red de pagos 170. Los datos de declaraciones de tarjetas de pago preferiblemente incluyen la ID única de transacciones del archivo de pagos (véase Paso 420) . En el paso 460, los datos de remisión de pagos se proveen al Proveedor/Beneficiario 130 por el Adquiridor/Procesador 160 para fines de reconciliación. Finalmente, en el paso 470 el Comprador/Pagador 110 establece las transacciones de tarjeta de pago con el Banco de Expedición 140 al final del ciclo de facturación.

Las modalidades ilustrativas adicionales de la presente invención serán descritas ahora. Aunque estas modalidades ilustrativas de la presente invención serán descritas ahora. Aunque estas modalidades ilustrativas se refieren al uso de una tarjeta de compras, tal como P-Card™ de MasterCard, cualquier tarjeta de pagos puede usarse como una alternativa. La presente invención ayuda tanto al Proveedor del Software 120 que provee la plataforma de PFEP 120z y el Adquiridor/Procesador 160 en funcionalidad de construcción para automatizar e integrar solicitudes de registro, autorización de pagos y/o establecimiento del Proveedor/Beneficiario 130 así como respuestas y notificaciones de flujo de trabajo de excepción. En las modalidades ilustrativas descritas en la presente, una vía de acceso de pagos de servicios mercantiles ("SM") 170a (Figuras 1 a 3) se emplea preferiblemente. La vía de acceso de SM 170a es la vía de acceso a través de la cual preferiblemente se procesan la autorización y establecimiento de las transacciones de tarjetas de compra. Este procesamiento puede realizarse en el modo en lotes, en donde las transacciones de Nivel III se acumulan y envían en intervalos periódicos a la vía de acceso de SM 170a en un formato de intercambio de datos normal, por ejemplo, el formato de 810 EDI. La vía de acceso de SM 170a divide preferiblemente las transacciones basadas en un identificador mercantil ("ID Mercantil") con el fin de dirigir las transacciones a los sitios apropiados. La vía de acceso de SM 170a provee preferiblemente una respuesta de autorización de regreso en un formato de intercambio de datos normal, tal como, por ejemplo, el formato 824 EDI. Para aquellas transacciones que han sido autorizadas, la vía de acceso de SM de pagos 170a proceden preferiblemente con el procesamiento de establecimiento con datos del Nivel III provistos . La Fig. 5 es una gráfica de flujo que describe establecimiento inmediato de una orden de compra ("OC") iniciada pro la transacción de tarjeta de compras de acuerdo con una modalidad ilustrativa de la presente invención. En el paso 505, el Comprador/Pagador 110 envía electrónicamente una OC de su sistema PRE 110a al sistema de PFEP del Proveedor del Software 120a. En el paso 510, una vez que se envió el archivo de OC al sistema PFEP 120a en el formato requerido, se solicita el proceso de carga de OC para transformar, analizar y cargar las OC en el sistema PFEP 120a. En el paso 515, una vez que se ha cargado la OC en el sistema PFEP 120a inicia un análisis de carga posterior de la OC . El análisis de carga posterior incluye una serie de validaciones básicas tales como (i) determinando si la información acerca del Proveedor/Beneficiario 130 y el Comprador/Pagador 110 esta disponible en el encabezado de OC, (n) determinando y validando la información de tarjeta de compra que se provee como el método de pago; (m) determinando si es una OC nueva, una OC duplicada, o una OC de cambio y la etiqueta apropiadamente para procesamiento adicional; y (ív) determinar los términos de pago, es decir, si es una OC inmediata o retardada. En el paso 520, después de completar el análisis de la OC cargada posteriormente, preferiblemente se decide si la OC deberá etiquetarse como una OC nueva u OC de cambio para procesamiento adicional. En caso de una excepción, la OC se etiqueta como un error junto con la razón apropiada y despacharse a la línea de espera de excepción en el paso 523. En el paso 525, si la OC se ha etiquetado como una OC de cambio, el sistema PFEP 120a inicia el procesamiento de "OC de cambio" . Dependiendo de que si la OC original se ha realizado o no y basado en las reglas definidas para la relación entre el Comprador/Pagador 110 y el Proveedor/Pagador 130, el sistema procede a aplicar el cambio a la OC y genera una historia de OC . En el caso de una OC de cambio, una vez que se ha completado el procedimiento apropiado en el paso 525, preferiblemente se decide en el paso 530 si es válido o no el cambio. Si no es válido el cambio, la OC se etiqueta como un error y se despacha a la línea de espera de excepción en el paso 523. Si fue válido el cambio, la CO se dirige a uno o más agentes del Proveedor/Pagador 130 usando la información de instalación del Proveedor/Beneficiario 130 y/o detalla un número de cuenta de la ID de Vendedor/Cliente que se obtienen de la CO. Preferiblemente una notificación por correo electrónico se envía preferiblemente al Proveedor/Beneficiario 130 para informar acerca de la CO . En el paso 535, el agente del Proveedor/Beneficiario 130 preferiblemente puede mostrar un resumen de la OC que se han dirigido al mismo. Si la OC tiene un número de cuenta de compra asociado con él, entonces la línea de resumen para la OC preferiblemente indican que tal es el caso. También, la línea de resumen de la OC indicará si son inmediatos los términos de pago. El agente del Proveedor/Beneficiario 130 podría elegir ver los detalles de la OC . Los detalles de la OC pueden presentarse entonces. La información de tarjetas de compras enmascaradas también puede estar disponible en los detalles de la OC . En el paso 540, del resumen de la OC o los detalles de la OC, el agente del Proveedor/Beneficiario 130 pueden alternar la OC . El agente se presenta con una inferíase editable (como se definió por el Comprador/Pagador 110) de los detalles de la OC . En esta etapa, también permanecen enmascarados los números de tarjetas de compra. El agente del Proveedor/Beneficiario 130 selecciona los elementos que se deberán incluir en la confirmación de orden junto con cantidad. Cuando el agente del Proveedor/Beneficiario 130 procede a alternar (parcial o completamente) , el sistema genera una confirmación de orden de borrador. La confirmación de orden de borrador tiene campos editables para Impuestos y FOB que se llenan previamente con valores si están disponibles de la OC . El agente del Proveedor/Beneficiario puede saltarse estos elementos, y también pueden saltar el número de ' factura generados y proceder para generar la confirmación de orden. En el paso 545, el estado de los cambios de OC para "procesar pagos" y la PFEP 120a genera y asocia un número único con la confirmación de orden. En el paso 550, con base en si el Proveedor/Beneficiario 130 se ha adquirido pro la vía de acceso de SM, se inician los procesos relacionados con pagos apropiados. En el paso 555, si el Proveedor/Beneficiario 130 no se han adquirido por la vía de acceso de SM 170a, la visualización de confirmación de orden que se presenta al Proveedor/Beneficiario 130 podría tener una opción para iniciar el procesamiento de autorización de pagos manual. En el paso 560, al seleccionar la opción manual, el Proveedor/Beneficiario 130 se provee un una visualización de la confirmación de orden que tiene campos editables para introducir el código de autorización y la fecha de transacción (llenado previamente con los datos del sistema) .

El número único también puede presentarse en esta pantalla. En esta etapa, se puede desenmascarar el número de tarjetas de compra. El Proveedor/Beneficiario 130 autoriza mediante un dispositivo de PDT externo 310 e introduce el único número en el dispositivo de PDT 310 cuando, por ejemplo, se apunta para un código de cliente. En el paso 565, si se autoriza, el Proveedor/Beneficiado 130 actualiza la confirmación de orden con el código de autorización y la fecha de la transacción y procede a etiquetar la confirmación de orden como "pagada". Si se rechaza o falla la autorización de pago, son notificados de esto tanto el Comprador/Pagador 10 como el Proveedor/Beneficiario 130 vía correo electrónico, y la factura se etiqueta como "rechazada" y se coloca en una visualización o bandeja de resumen de "Autorizaciones con Fallas" . Si, en el paso 550, el Proveedor/Beneficiario 130 ha sido adquirido pro la vía de acceso de SM 170a, entonces el sistema PFEP 120a procede en el paso 50 con la autorización de vía de entrada de SM y proceso de establecimiento. La autorización de vía de acceso SM y proceso de establecimiento (paso 570) preferiblemente es un proceso en lotes mediante al cual un archivo de autorización/establecimiento se genera por el sistema de PFEP 120a y e envía a la vía de acceso de SM 170a. El archivo contiene datos de establecimiento de Nivel III. En el paso 575, el sistema de PFEP 120a recibe la respuesta de la vía de acceso de SM 170a que contiene el código de autorización y procede con el etiquetado de la confirmación de orden como autorizado, es decir, como "pagado" y asociando el código de autorización con la confirmación de orden. Si se rechaza o falla la autorización de pago, ambos del Comprador/Pagador 110 y el Proveedor/Pagador 130 se notifican vía correo electrónico y la factura se etiqueta y coloca en la visualización y bandeja de resumen de "Autorizaciones con Falla". Para autorizaciones basad en SM, las transacciones incluyen preferiblemente el código de razón apropiado. El Proveedor/Beneficiario 130 también puede tener la opción de visualizar las diferentes confirmaciones de orden que se generan en un nivel de resumen y para seleccionar la visualización de una confirmación de orden particular en detalle. Podría hacer ciertas confirmaciones de ordenes en las cuales el Proveedor/Beneficiario 130a (no SM) puede haber elegido tomar alguna acción siguiendo la alternancia. Esto podría etiquetarse como "Autorización manual En Espera" . En el paso 580, una vez que se etiqueta la confirmación de orden como "Pagada", la información relacionada se puede etiquetar en un esquema de XML particular y anexarse al archivo XML de PFEP 120a que puede exportase. Mientras, la confirmación de orden también se dirige al Comprador/Beneficiario 110 con base en las reglas de direccionamiento definidas en el PFEP 120a. Preferiblemente hay un indicador a lo largo de la partida de línea de resumen de confirmación de Factura/Orden que indica que el documento es una confirmación de orden. El comprador/Pagador 110 puede ver los detalles de confirmación de orden junto con los detalles de la tarjeta de compra (los detalles de la tarjeta de compra enmascarados pero para los últimos cuatro dígitos del número de cuenta) . El Comprador/Pagador 110 preferiblemente no procesa además en la confirmación de orden excepto que lo exporta para integrarlo con el sistema para pagar cuentas. La Fig. 6 es un establecimiento retardado que describe gráficas de flujo de una transacción de tarjeta de compra iniciada en OC, de acuerdo con una modalidad ilustrativa de la presente invención. En el paso 605, el Comprador/Pagador 110 envía electrónicamente una OC de su PRE 120a al sistema de PFEP del Proveedor del Software 120a. En el paso 610, una vez que el archivo de OC se ha enviado al PFEP 120a en el formato requerido, el proceso de Carga de OC se llama para transformar, verificar y cargar las OC en el sistema PFEP 120a. En el paso 615, una vez que las OC se han cargado en el sistema de PEP 120a y se validan para formato y estructura, el PFEP 120a inicia un análisis de carga posterior de la OC . El análisis de carga posterior incluye una serie de validaciones básicas tales como (i) determinar si la información acerca del Proveedor/Beneficiario 130 y del Comprador/Pagador 110 están disponibles o no en el encabezado de la OC; (n) determinar y validar la información de tarjeta d compra que se provee como el método de pago; (ni) determinar si es una OC nueva, una OC duplicada, o una OC de cambio y etiquetarla apropiadamente para su procesamiento, y (ív) determinar los términos de pago, es decir, si es una OC inmediato o retardado. En la modalidad ilustrativa presente, una OC retardada puede tener términos de pago tales como, por ejemplo, "red 15", "red 30", etc. También, podría no haber términos de pago, lo cual podría considerarse preferiblemente como un caso especial de una OC retardada. En el paso 620, después de que se ha completado el análisis de OC posterior a la carga, preferiblemente se decide si la OC debería etiquetarse como OC nueva u OC de cambio para procesamiento adicional. En el caso de una excepción, la OC se etiqueta como un error junto con la razón apropiada y despachada a la línea de espera de excepción 623. En el paso 625, si la OC se ha etiquetado como una OC de cambio, el PFEP 120a inicia el procesamiento de OC de cambio. Dependiendo de que si la OC original se ha cumplido y basado en las reglas definidas para la elación entre el Comprador/Pagador 110 y el Proveedor/Beneficiario 130, el sistema 120a inicia el procesamiento de OC de cambio. Dependiendo si la OC original se ha cumplido y basado en las reglas definidas para la relación entre el Comprador/Pagador 110 y el Proveedor/Pagador 130, el sistema 120a procede a aplicar el cambio a la OC y genera una historia de OC . En el caso de una OC de cambio, una vez que se ha completado el procesamiento apropiado en el paso 625, preferiblemente se decide en el paso 630 si el cambio fue válido o no . Si el cambio no fue válido, la OC se etiqueta como un error y se despacha a la línea de espera de excepciones 623. Si el cambio fue válido, se etiqueta la OC para, o se dirige a uno o mas agentes del Proveedor/Beneficiario 130 usando la información de instalación del Proveedor/Beneficiario 130. En la notificación por correo electrónico se envía preferiblemente al Proveedor/Beneficiario 130 para informar acerca de la OC . En el paso 635, el agente del Proveedor/Beneficiario 130 puede visualizar preferiblemente un resumen de todas las OC que se han dirigido al mismo. Si la OC tiene un número de cuenta de compra asociado con él, la línea de resumen para la OC indicará si son inmediatos o no los términos de pago. El agente del Proveedor/Beneficiario 130 podría elegir visualizar los detalles de la OC . La visualización de detalles de la OC puede presentarse entonces. La información de tarjetas de compra enmascaradas también puede estar disponible en la visualización de detalles de OC . En el paso 640, del resumen de la OC o la visualización de detalles de la OC, el agente del Proveedor/Beneficiario 130 puede elegir analizar la OC . El agente se presenta con una interfase editable (definido pro el Comprador/Pagador 110) de los detalles de la OC . En esta etapa también el número de la tarjeta de compra permanece enmascarado. El agente del Proveedor/Beneficiario 130 selecciona los elementos que se deberán incluir en la factura junto con cantidad. Cuando el agente del Proveedor/Beneficiario 130 procede para realizar la verificación (parcial o completa) , el sistema de PFEP, en el paso 645, genera una factura de borrador. La factura de borrador tiene campos editables para Impuesto y FOB que se llenan previamente con valores si están disponibles con la OC . El agente del Proveedor/Beneficiario 130 podría saltarse estos elementos y también el número de factura generado y proceder a generar la factura en el paso 645. En el paso 645, la factura generada se dirigió al agente del Comprador/Pagador 110 para la aprobación y programación. La dirección se determina pro el Comprador/Pagador 110 que dirige la instalación y por cualquier otra información relacionada acerca de la ID del Comprador/Pagador 110 y el número de cuenta de cliente obtenida de la OC original. En el paso 650, el agente del Comprador/Pagador 110 puede visualizar un resumen de todas las facturas que se han dirigido a la ID del Comprador/Pagador 110. El resumen de la OC indica preferiblemente usando, por ejemplo, un logotipo especial, cualquier OC que tiene una transacción de tarjeta de compra asociada con la misma. El agente del Comprador/Pagador 110 puede seleccionar visualizar los detalles de una factura. La información de tarjeta de compra también está presente en esta visualización detallada. El número de tarjeta de compra permanece enmascarada, excepto por los últimos 4 dígitos. En el paso 655, el agente del Comprador/Pagador 110 puede dirigir la factura para su aprobación. El agente del Comprador/Pagador 110 puede dirigir la factura para su aprobación. El agente del Comprador/Pagador 110 puede aprobar la factura y/o enviarla a otros agentes usando el flujo de trabajo definido por la organización del Comprador/pagador 110. En el paso 660, la determinación se hace siempre que la OC tiene unidos a la misma cualesquiera términos de pago, y si es así, los que son. Si la OC tiene términos de pago retardados explícitamente presentes la factura generada se programó y aprobó en el paso 665, basado en dichos términos. Por ejemplo, si los términos de pago indican "15 neto", la factura preferiblemente se programan para pago 15 días desde la fecha está disponible para el Comprador/Pagador 110 para la visualización. Sin embargo, si los términos de pago están ausentes, el Comprador/Pagador en el paso 667 pueden programar la factura para la aprobación y pago en una fecha futura. En el paso 655, una vez que se ha aprobado la factura, la factura aprobada se dirige al Proveedor/Beneficiario para visualización en el paso 665. En el paso 670, al alcanzar la fecha programada, el estado de la factura se cambia a "Pago de Procesamiento". Un número único preferiblemente se genera y se asocia con la factura. En el paso 670, con base en si el Proveedor/Beneficiario se han adquirido por la vía de acceso de SM 170a, se inician los procesos relacionados con los pagos apropiados. Si el Proveedor/Beneficiario 130 se ha adquirido pro la vía de acceso de SM 170a, entonces el PFEP 120a procede en el paso 675 al proceso de autorización y establecimiento de la vía de acceso de SM 170a. El proceso de autorización y establecimiento de la vía de acceso de SM 170a es preferiblemente un proceso en lotes mediante el cual se genera un archivo de autorización/establecimiento se genera por el PFEP 120a y se envía a la vía de acceso de SM 170a. El archivo preferiblemente contiene datos de establecimiento del Nivel III. El PFEP 120a recibe una respuesta de la vía de acceso de SM 170a conteniendo el código de autorización, y en el paso 680, procede a etiquetar la factura según se autoriza, es decir, etiquetarlo como "Pagado" y asociando el código de autorización con la factura. Si la autorización del pago se rechaza o falla, tanto el Comprador/Pagador 110 y Proveedor/Beneficiario 130 son notificados por correo electrónico y la factura se etiqueta apropiadamente en el paso 680, y se coloca en una visualización o bandeja de resumen de "Autorizaciones Rechazadas". Para autorizaciones de la vía de acceso de SM 170a, las transacciones preferiblemente incluyen código de razón apropiado. Si en el paso 670, cuando se ha alcanzado la fecha programada y tiene un estado de "Procesando Pago", se determina que la mercancía no se ha adquirido, es decir, se determina que el Proveedor/Beneficiario 130 está etiquetado como "Esperando Autorización Manual", el proceso de autorización manual se acciona en el paso 685. Cuando el Proveedor/Beneficiario 130 visualiza los detalles de facturas que esperan autorización manual, una opción para iniciar procesamiento de pago se presenta al Proveedor/Beneficiario 130. Al seleccionar esta opción, al Proveedor/Beneficiario 130 se le provee una visualización de la factura que tiene campos editables para introducir el código de autorización y la fecha de transacción (llenada previamente con la fecha del sistema) . El único número también se presenta en esta pantalla. En esta etapa se desenmascara el número de tarjeta de compra. El Proveedor/Pagador 130 autoriza mediante un dispositivo de PDT externo e introduce el único número en el PDT cuando se solicita, por ejemplo, cuando se solicita un Código de Cliente. Una vez autorizado, el Proveedor/Pagador 130 actualiza la factura con el código de autorización y la fecha de transacción y procede a etiquetar la factura como "Pagada" . • Si la autorización del pago se rechaza o falla, tanto el Comprador/Pagador 110 y Proveedor/Beneficiario 130 son notificados vía correo electrónico y la factura se etiqueta en el paso 690 y se coloca en la visualización o bandeja de resumen de "Autorizaciones Rechazadas". Si la autorización del pago es exitosa, en el paso 690 la factura se etiqueta como "Pagada", y la información relacionada se anexa en el paso 695 a un archivo de XML de PFEP para exportación . La Fig. 7 es una gráfica de flujo que ilustra el establecimiento retardado de una transacción de tarjeta de compra sin OC, de acuerdo con una modalidad ilustrativa de la presente invención. En esta modalidad ilustrativa, en el sistema no hay una OC cargada en el sistema de PFEP 120a. Aquí, en el paso 710, las facturas se envían electrónicamente por el Proveedor/Pagador 130 al Proveedor del Software 120.

En el Proveedor del Software 120, las facturas se cargan, en el paso 715, en el PFEP 120a. Durante el proceso de carga de facturas, el PFEP 120a identifica preferiblemente si el Proveedor/Pagador 130 acepta tarjetas de compra como un método de pago. Además, si las tarjetas de compra se han definido como el método de pago por omisión para la cuenta de clientes específica (definida en un nivel de relación de Comprador/Pagador-Proveedor/Benefíciapo) , el sistema de PFEP 120a podría asociar al mismo con la factura. El Comprador/Pagador 110 puede establecer grupos de usuario que comprenden múltiples agentes que podrían ser autorizados para hacer pagos usando tarjetas de compra. El administrador del Comprador/Pagador 110 podrá introducir los detalles de la tarjeta de compra, tales como nombre de quien tiene la tarjeta, número de tarjeta, fecha de expiración y código de CVC2, y asocian la tarjeta de compra con uno o más grupos de usuario. El administrador del Comprador/Pagador 110 también podría considerar que las tarjetas de compra se utilizan solo para cierto Proveedor/Beneficiario 130 específico. En el paso 715, la factura se carga y dirige al grupo del Comprador/Pagador 110 apropiado basado en la información de direccionamiento disponible de la factura. El direccionamiento puede realizarse con base en la ID de direccionamiento o número de cuenta del cliente. En el paso 720, el agente del Comprador/Pagador 110 puede visualizar un resumen de todas las facturas que se han dirigido a su ID. En el paso 725, el agente del Comprador/Pagador 110 puede aprobar la factura y/o enviarlo a otros agentes usando el flujo de trabajo definido para la organización del Comprador/Pagador 110. El agente del Comprador/Pagador 110 puede seleccionar el método del pago como "tarjeta de compra", o la "tarjeta de compra" puede haberse definido previamente como el método de pago por omisión para la cuenta del cliente específica, en cuyo caso el sistema de PFEP 120a podría haber asociado previamente las tarjetas de compra con la factura. En el paso 730, una vez que se establece la "tarjeta de compra" como la opción de pago., la factura reprograma automáticamente ara el pago en una fecha futura, o programarse manualmente por un agente del Comprador/Pagador 110 que tiene privilegios del "programador".. En el paso 735, los detalles de tarjeta de compra se asocian automáticamente con la factura. En el paso 749, la factura se aprueba para pago y se dirige al Proveedor/Pagador 130 para visualizarse en el paso 745. En el paso 750, para alcanzar la fecha programada, la situación de la factura se cambia a "Pago en Proceso" y se genera un número único de transacción y se asocia con la factura. En el paso 855, con base en si el Proveedor/Pagador 130 se ha adquirido o no por la vía de acceso de SM 170a, se inician los procesos apropiados relacionados con el pago. En los pasos 760 y 765, si el Proveedor/Pagador 130 se ha adquirido por la vía de acceso de SM 170a, entonces el PFEP 120a procede con los procesos de autorización y establecimiento de vía de acceso de SM. La autorización y establecimiento de la vía de acceso de SM preferiblemente es un proceso en lotes mediante el cual se genera un archivo de autorización/establecimiento por el sistema de PFEP 120a y se envía a la vía de acceso de SM 170a. El archivo de autorización/establecimiento contiene preferiblemente los datos de establecimiento del Nivel III. En el paso 770, el sistema de PFEP 120a recibe una respuesta de la vía de acceso de SM 170a conteniendo el código de autorización y procede con el etiquetado de la factura como autorizada (Pagada) y asociando el código de autorización con la factura. Si la autorización de pago se rechaza/galla, tanto el Comprador/Pagador 110 y el Proveedor/Pagador 130 se notifican vía correo electrónico, y la factura se etiqueta y coloca en la visualización/bandej a de "Autorización Rechazada". Para la vía de acceso de SM 170a, las autorizaciones, transacciones, incluirán el código de razón apropiada. Si en el paso 755 se determina que no se ha adquirido la mercancía, es decir, se determina que el Proveedor/Beneficiario 130 se etiqueta como "Autorización manual En Espera", el proceso de autorización manual se acciona en el paso 775. Cuando el Proveedor/Beneficiario 130 visualiza los detalles de dichas factura ("Autorización Manual en Espera"), una opción para iniciar el procesamiento de pagos se presente al Proveedor/Beneficiario 130. Al seleccionar esta opción, al Proveedor/Beneficiario 130 se le puede proveer una visualización de la factura que tiene campos editables para introducir el código de autorización y la fecha de transacción (llenada previamente con la fecha del sistema) . El número único también se presenta en esta pantalla. En este punto, preferiblemente se desenmascara el número de tarjeta de compra. El Proveedor/Beneficiario 130 autoriza a través de un dispositivo de PDT externo 310 e introduce el número único en el dispositivo de PDT 310 cuando se solicita, por ejemplo, para el código de cliente. En el paso 780, una vez autorizado, el Proveedor/Beneficiario 130 actualiza la factura con el código de autorización y la fecha de transacción y procede a etiquetar la factura como "Pagada". En el paso 780, si se rechaza/falla la autorización del pago, tanto el Comprador/Pagador 110 como el Proveedor/Beneficiario 130 son notificados vía correo electrónico, y la factura se etiqueta y coloca en la visualización/bande a de resumen de "Autorización Rechazada". En el paso 785, una vez que la factura se etiqueta como "Pagada", la información relacionada se marca y anexa al archivo de XML de PFEP 120a para su exportación . La autorización de SM y establecimiento ahora serán descritos en mayor detalle junto con la Fig. 8, que es una gráfica de flujo que ilustra un proceso ilustrativo de la autorización y establecimiento de vía de acceso de SM de acuerdo con la presente invención. La autorización y establecimiento de SM preferiblemente es un proceso en lotes combinado, aunque no necesariamente: tanto la autorización como establecimiento alternativamente podrían ser procesos separados. La autorización y establecimiento de SM también es preferiblemente un proceso de extremo posterior, es decir, el usuario no tiene visibilidad en la ejecución del proceso. En el paso 820, un registro de transacción de autorización/establecimiento se crea con base en un accionador en el paso 810. El accionador preferiblemente es cuando se genera una factura de confirmación de orden y cuando la factura ha alcanzado el "Pago en Proceso". Cuando se activa este accionado, el archivo de base preferiblemente se crea sobre una base programada que contiene solo los elementos de base. También se crea un nuevo archivo cuando hay una transmisión a SM . Para este archivo, los registros se agregan preferiblemente como y cuando se presentan transacciones de pago dentro del sistema de PFEP 120a. En un tiempo predeterminado, el archivo se envía preferiblemente a la vía de acceso de SM 170a y luego vuelve a comenzar el proceso . La transacción de autorización/establecimiento preferiblemente es en el formato de IDE 810 e incluye datos de establecimiento del Nivel III. Un número de transacción único, Igualación Generada de PFEP, y Código de Cliente, también son parte preferiblemente de esta transacción. Los datos para las transacciones de autorización/establecimiento (Nivel III) preferiblemente se obtienen de (a) elementos de datos que están presentes en la factura, (b) datos relacionados con tarjeta de compras; y (c) información de instalación de la vía de acceso mercantil de SM 170a. Las transacciones de autorización/establecimiento preferiblemente se extraen durante intervalos de tiempo regulares y luego se anexan al archivo de autorización/establecimiento en lotes. Un archivo de respaldo también se actualiza preferiblemente. En el paso 830, en intervalos de tiempo predefinidos, los archivos de autorización/establecimiento se envían a la vía de acceso de SM 170a a través del sistema de PFEP 120a para procesamiento. Los mapas de vía de acceso de SM 170a, el archivo de autorización/establecimiento con base en las instalaciones de mapeo que se han definido para el Proveedor del Software 120. La vía de acceso de SM 170a identifica las transacciones contra la plataforma adquirida apropiada. Con base en esta identificación, el archivo de autorización/establecimiento se divide y envía a las plataformas correspondientes para procesamiento adicional. La vía de acceso de SM 170a podrían dividir las transacciones de autorización/establecimiento en transacciones múltiples para acomodar las limitaciones en el valor de la cantidad de establecimiento total. En el paso 840, una respuesta autorización se envía de nuevo a PFEP 120a desde la vía de acceso de SM 170a. Las respuestas regresan al PFEP 120a en el formato de IDE 824. En el paso 850, el PFEP 120a recibe la transacción de respuesta de autorización y evalúa los registros de respuesta individuales. Con base en la respuesta (rechazada o de alguna otra manara) , el sistema actualiza las facturas correspondientes. En los casos en donde fue posible una autorización exitosa, el procesamiento de establecimiento es seguido a través de la vía de acceso de SM 170a sin cualquier acción adicional requerida del Proveedor del Software 120. No se esperan respuestas de la vía de acceso de SM 170a para procesamiento de establecimiento. Si fue exitosa la autorización, en el paso 855 la factura se etiqueta como autorizada y su estado se actualiza apropiadamente. En el paso 860, el detalle de la factura se asocia también con los detalles de la autorización. Esto incluye código de autorización, fecha de transacción, etc., que podría ser visible para el Proveedor/Beneficiario 130. El Comprador/Pagador 110 podría tener visibilidad solo a la fecha de la transacción. Otros detalles del registro de pagos incluyendo el número único de transacción, débito/crédito, etc., podría ser también asociada con la factura. En el paso 865, una notificación de correo electrónico se envía al Proveedor/Beneficiario 130 para indicar que la autorización ha sido exitosa para la factura particular. En el paso 870, se genera un archivo XML de PFEP se genera para fines de registros y preferiblemente se exporta según sea necesario. Si no fue exitosa la autorización, en el paso 875 la factura se etiqueta apropiadamente y se actualiza su situación. En el paso 880, la factura se etiqueta apropiadamente y se actualiza la situación. En el paso 880, el Comprador/Pagador 110 y el agente del Proveedor/Beneficiario 130 son notificados apropiadamente vía correo electrónico. Finalmente, en el paso 885, las transacciones se colocan en la "bandeja" apropiada de excepción de autorizaciones rechazadas. El manejo del rechazo de la autorización de SM ahora será descrito en mayor detalle junto con la Fig. 9, que es una gráfica de flujo que ilustra un proceso ilustrativo del manejo del rechazo de la autorización de SM de acuerdo con la presente invención. En el paso 905, el proceso de rechazo de autorización de SM preferiblemente se acciona cuando una solicitud de autorización asociada con una factura o confirmación de orden ha sido rechazada ya sea por (i) la Vía de acceso de SM 170a como parte de la autorización de la vía de acceso de SM y proceso de establecimiento, o (11) el dispositivo de PDT 310 como parte de la autorización de la vía de acceso y proceso de establecimiento. Los datos que detallan las razones para el rechazo de autorización se pueden obtener ya sea mediante la respuesta de autorización de la vía de acceso de SM 170a o mediante la entrada manual de agentes de Proveedores/Beneficiarios 130 que no habían sido adquiridos para la vía de entrada de SM 170a. El sistema de PFEP 120a, preferiblemente asocia la razón de rechazo de autorización con la confirmación de factura. En el paso 910, la factura u otra situación de confirmación de orden se cambia a "Autorización Rechazada" . En el paso 915, se envía una notificación por correo electrónico se envía al Comprador/Pagador 110 y al Proveedor/Beneficiario 130 avisa que ha fallado la autorización del pago para la factura específica o confirmación de orden. En el paso 920, tanto el Comprador/Pagador 10 como el Proveedor/Beneficiario 130 puede elegir visualizar os detalles de la factura particular u otra confirmación de una visualización del resumen de "Autorización Rechazada", la razón rechazada, que se obtuvo ya sea mediante la vía de acceso de SM 170a o introducirse por el Proveedor/Beneficiario 130, podría presentarse al Comprador/Pagador 110 y/o el Proveedor/Beneficiario 130 como parte de la visualización detallada de la factura o confirmación de orden, así como información adicional que explica la razón y provee lmeamientos para resolver la razón rechazada . Como parte de la visualización detallada de la factura o confirmación de orden en el estado "Autorización Rechazada", al Comprador/Pagador 110 también se le provee una opción para ya sea "Volver a Presentarla Como Tal" o para "Anular Método de Pago". El comprador y proveedor pueden elegir consultarse entre ellos para evaluar las razones y soluciones posibles para la "Autorización Rechazada" . En el paso 925, el Comprador/Pagador 110 puede elegir "Volver a Presentarla Como Tal" la factura específica o confirmación de orden para procesamiento de pago. Esto puede suceder si la razón de rechazo obtenida a través de PFEP 120a o a través de consultas externas, ha puesto en vigor dicha dirección. En el paso 930, la situación de la factura o confirmación de orden se cambia luego a "Procesamiento de Pago". Si el Proveedor/Beneficiario 130 ha sido adquirido por la vía de acceso de SM 170a, en el paso 935, se solicitan la autorización y establecimiento de la vía de acceso de SM 170a. Si no se ha adquirido el Proveedor/Beneficiario 130 por la vía de acceso de SM 170a, en el paso 940, la factura se etiqueta como "Autorización Manual en Espera", y en el paso 945, se envía un correo electrónico al "Proveedor/Beneficiario 130 para notificar que la factura está esperando autorización manual, y se solicita el proceso de autorización manual. En el paso 925, el Comprador/Pagador 110 podría elegir anular el método de pago que se ha asociado con la solicitud de autorización original para la factura o confirmación de orden. Esto puede suceder si, por ejemplo, la razón de rechazo obtenida a través del PFEP 120a o a través de consultas externas, ha puesto en vigor dicha dirección. Si se elige la opción de "Anular el Método de Pago", en el pasos 950, el Comprador/Pagador 110 preferiblemente se provee con una visualización para seleccionar un método o métodos de pago alternos. El Comprador/Pagador 110 puede presentar la factura o confirmación de orden para su procesamiento. En el paso 960, la situación de facturas o confirmación de orden se cambia a "Procesamiento de Pagos". Si en el paso 950, el método de pago seleccionado no fue una tarjeta de compra, el procesamiento podría continuar preferiblemente en la forma como se define en el sistema "Como Tal". Si el método de pago seleccionado era una tarjeta de compra, y si el Proveedor/Pagador 130 se ha adquirido mediante la vía de acceso de SMM 170a, en el paso 935 se puede solicitar el proceso de autorización y establecimiento de la vía de acceso de SM 170a. Si no se ha adquirido el Proveedor/Beneficiario 130 mediante la vía de acceso de SM 170a, en el paso 940 se etiqueta la factura como "Esperando Autorización Manual". En el paso 945, se envía un correo electrónico al Proveedor/Beneficiario 130 para notificar que la factura está esperando autorización manual, y se solicita el proceso de autorización manual. En el paso 925, al visualizar los detalles del rechazo de factura o confirmación de orden, el Comprador/Pagador 110 puede elegir cambiar la información de tarjeta de compra asociada con la factura a través de una transacción de Cambio de OC . Esto puede suceder, pro ejemplo, si el Comprador/Pagador 110 podría desear tener el cambio reflejado en todas las facturas o confirmaciones de orden asociadas, o si no están disponibles otros métodos de pago para el Comprador/Pagador 110 para ser elegidos. Preferiblemente, eso solo podría ocurrir se hubiera una OC que se asocia con la factura dentro de la PFEP 120a. En el paso 965, el Comprador/Pagador 110 expide una solicitud de "OC de Cambio" o "Información de Tarjeta de Compra de Cambio". En el paso 970, la información de tarjeta de compra asociada con la OC luego se actualiza con la información en la solicitud de OC de Cambio. En el paso 975, la información se propaga a facturas o confirmaciones de orden que se han generado contra la factura que no están aún en el estado "Pagado". En el paso 980, para aquellas facturas que están en el estado "Autorización Rechazada", el estado se restablece a "Pago en Proceso". Si el Proveedor/Beneficiario 130 se ha adquirido mediante la vía de acceso de SM 170a, en el paso 935, se puede solicitar el proceso de autorización y establecimiento de la vía de acceso de SM 170a. Si no se ha adquirido el Proveedor/Beneficiario 130 por la vía de acceso de SM 170a, en el pasos 940 la factura se etiqueta "Esperando Autorización Manual". En el paso 945, se envía un correo electrónico al Proveedor/Beneficiario 130 para notificar que la factura está esperando autorización manual, y se solicita el proceso de autorización manual. La siguiente tabla es un ejemplo de cómo puede utilizarse el formato IDE 810 para enviar transacciones de autorización y establecimiento a la Vía de Acceso de SM.

I SAO 3 Calificador C 2 M "00" de Información de Seguridad ISAO 4 Información AN 10 M Espacios de Seguridad ISAO5 Calificador C 2 M Si no de ID de está quien Envía disponiIntercambio ble será asignado por SM I SAO 6 ID de quien AN 15 M Si no Envía está Intercambio disponible será asignado por SM I SAO7 Calificador C 2 M 09' ISAO8 ID de AN 15 M "MSSTEST" Receptor de para Intercambio prueba; "MSSPROD" para producción; "MSN TEST"; "MSNPROD" I SAO 9 Fecha de DT 6 M YYMMDD Intercambio ISA10 Tiempo de TM 4 M HHMM Intercambio ISA11 ID de C 1 M "U" Control de Intercambio ISA12 Número de C 5 M "00410" Versión de Intercambio ISA13 Número de N 9 M EnviaControl de dor Intercambio asignado I SAI 4 Solicitud de C 1 M M T M Reconocimiento REFOl Código de C M "CA" Identificador de Referencia REF02 Identifica- AN 30 O Número ción de Único Referencia REFOl Calificador M "TJ" de Identificación de Referencia REF02 IdentificaAN 30 O ID de ción de impuesReferencia to Federal de vendedor REFOl Calificador C M "ZA" de Identificación de Referencia REF02 Identifica- AN 30 O Código ción de de Tipo referencia Mercantil. Si no se puede proveer información valiosa, se puede proveer el valor '1000' .

Termina ciclo de Vendedor Segmento del Encabezado - Fin de Ciclo NI M - Mandatario X - Condicional O - Opcional La siguiente tabla provee un ejemplo de cómo se puede utilizar el formato 824 IDE por la vía de acceso de SM 170a para enviar respuestas de autorización de regreso al Proveedor del Software 170. En este ejemplo IDE 997 podría enviarse por la vía de acceso de SM 170a para reconocer si fue apropiado el formato de la solicitud o no.

La siguiente tabla describe códigos de respuesta/razón de vía de acceso de MS 170a ilustrativa, de acuerdo con la presente invención. En la siguiente tabla, " + + " denota una respuesta generada por la vía de acceso de MS 170a.

Códigos de Respuesta de MS / Códigos de Razón CÓDIGO DE RESPUESTA CÓDIGO DE RAZÓN 53. ** FECHA DE TRANSACCIÓN MALA 54. 01 55. **MALA CANTIDAD 56. 02 57. **CANTIDAD DE TRANSACCIÓN = CERO 58. 03 59. ** ONGITUD DE NO. DE CTA. 60. 04 INVÁLIDO 61. ** MAL CÓDIGO DE TIPO DE TARJETA 62. 05 63. **MAL VALOR DE DÍGITO DE REVISIÓN 64. 06 65. ** CÓDIGO DE CVC2 INVALIDO 66. 07 67. **RESPUESTA NO RECONOCIDA 68. 10 69. ** NO. CTA. NO NUMÉRICA 70. 11 72. ** FECHA DE EXPIRACIÓN INVALIDA 72. 12 73. **TRANSACCION NO RECONOCIDA 74. 14 75. **BANDE JA/ PREFIJO INVÁLIDOS 76. 15 77. ** MERCANCÍA NO ESTÁ EN PROGRAMA 78. 16 DE CANCELACIÓN 79. ** INDICADOR DE EC INVÁLIDO 80. 17 81. ** INDICADOR DE TRANSACCIÓN DE 82. 18 MERCANCÍA INVÁLIDO 83. **NO SE ENCUENTRA NÚMERO DE SE 84. 19 85. NE - TARJETAS EXPIRADAS 86. ** TARJETA EXPIRADA 87. 01 88. NZ - REAUTORIZ ACIÓN DE DECLINACIÓN SUAVE 89. **DECLINACION SUAVE INICIAL 90. 00 CAPTURADA PARA REAUTORIZ ACIÓN 91. **ler. TRANSACCIÓN DE TIEMPO 92. 01 RECICLADA 93. **2a. TRANSACCIÓN DE TIEMPO 94. 02 RECICLADA 95. **3er. TRANSACCIÓN DE TIEMPO 96. 03 RECICLADA 97. **4a. TRANSACCIÓN DE TIEMPO 98. 04 RECICLADA 99. **5a. TRANSACCIÓN DE TIEMPO 100 05 RECICLADA 101. **6a. TRANSACCIÓN DE TIEMPO 102 06 RECICLADA 103. **7a. TRANSACCIÓN DE TIEMPO 104 07 RECICLADA 105. **8a. TRANSACCIÓN DE TIEMPO 106 08 RE CICLAD A 107. **9a. TRANSACCIÓN DE TIEMPO 108 09 RECICLADA.

Aunque la presente invención se ha descrito con referencia a ciertas modalidades preferidas, varias modificaciones, alteraciones y sustituciones serán conocidas u obvias para los expertos en la materia sin alejarse del espíritu y alcance de la invención, como se define por las reivindicaciones anexas.

Claims (4)

REIVINDICACIONES

1.- Un método para llevar a cabo una transacción de tarjeta de compra entre un comprador y un proveedor por medio de un sistema de pago de factura electrónica y presentación (PEFP), el método comprendiendo: aprobar una factura para la transacción de tarjeta de compra en el sistema de planeación de recursos de la empresa ("PRE") del comprador; programar la factura para pago en el sistema de PRE del comprador; extraer del sistema de PRE del comprador un archivo de pago que incluye un identificador de transacción única asociado con la transacción; enviar el archivo de pago, incluyendo el número de transacción único, desde el sistema de PRE del comprador a un adquiridor para autorización y establecimiento de pago; proveer al PRE del comprador una declaración de tarjeta de compra incluyendo datos que describen la transacción, los datos de declaración incluyendo el identificador de transacción única; y establecer por el comprador, la transacción con alguien que expida tarjetas de compra.

2.- El método de acuerdo con la reivindicación 1, comprendiendo además: proveer datos de remisión al proveedor, los datos de remisión incluyendo el identificador de transacción única, para reconciliar las cuentas del proveedor.

3.- Un método para conducir una transacción de tarjeta de compra entre un comprador y proveedor a manera de un sistema pagos de factura electrónico y presentación (PFEP), el método comprendiendo: aprobar una factura para la transacción de tarjeta de compra en el sistema de planeación de recursos de empresa ("PRE") del comprador; programar la factura para pagar en el sistema de PRE; extraer del sistema de PRE del comprador un archivo de pago que incluye un identificador de transacción única asociado con la transacción; presentar datos que describen la transacción, incluyendo el identificador único de transacción, a un dispositivo de punto de venta (PDV) para autorización y establecimiento; enviar datos de detalle de artículos de línea que describen la transacción, los datos del artículo de línea que incluyen el identificador de transacción único, del sistema de PFEP a una red de pago de tarjeta de compra para igualación; proveer a la PRE del comprador una declaración de tarjeta de compra incluyendo datos que describen la transacción, los datos de la declaración incluyendo el identificador de transacción único; y establecer por el comprador, la transacción con quien expide tarjetas de compra.

4.- El método de acuerdo con la reivindicación 2, que comprende además : proveer datos de remisión de quien adquiere, al proveedor, los datos de remisión incluyendo el identificador de transacción único, para reconciliar las cuentas del proveedor .