Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 13 vistas

    Documento de Pruebas de Desarrollo - 666139

    Cargado por

    Santiago Rodriguez
    Este documento describe pruebas de casos de uso para la facturación electrónica en un punto de venta. Se prueban dos casos principales: 1) el ingreso manual de datos de cliente cuando no hay RFC registrado y 2) la carga automática de datos cuando sí hay RFC registrado. También se prueban varios flujos alternativos como la edición de datos del cliente o errores de comunicación con el servidor. El objetivo es validar que los datos del cliente se envíen correctamente para facturación.

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd

    Documento de Pruebas de Desarrollo - 666139

    Cargado por

    Santiago Rodriguez
    13 vistas17 páginas
    Este documento describe pruebas de casos de uso para la facturación electrónica en un punto de venta. Se prueban dos casos principales: 1) el ingreso manual de datos de cliente cuando no hay RFC registrado y 2) la carga automática de datos cuando sí hay RFC registrado. También se prueban varios flujos alternativos como la edición de datos del cliente o errores de comunicación con el servidor. El objetivo es validar que los datos del cliente se envíen correctamente para facturación.

    Descripción original:

    Título original

    Documento de pruebas de desarrollo - 666139

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    DOCX, PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    Este documento describe pruebas de casos de uso para la facturación electrónica en un punto de venta. Se prueban dos casos principales: 1) el ingreso manual de datos de cliente cuando no hay RFC registrado y 2) la carga automática de datos cuando sí hay RFC registrado. También se prueban varios flujos alternativos como la edición de datos del cliente o errores de comunicación con el servidor. El objetivo es validar que los datos del cliente se envíen correctamente para facturación.

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
    Descargar como docx, pdf o txt
    13 vistas17 páginas

    Documento de Pruebas de Desarrollo - 666139

    Cargado por

    Santiago Rodriguez
    Este documento describe pruebas de casos de uso para la facturación electrónica en un punto de venta. Se prueban dos casos principales: 1) el ingreso manual de datos de cliente cuando no hay RFC registrado y 2) la carga automática de datos cuando sí hay RFC registrado. También se prueban varios flujos alternativos como la edición de datos del cliente o errores de comunicación con el servidor. El objetivo es validar que los datos del cliente se envíen correctamente para facturación.

    Copyright:

    © All Rights Reserved
    Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
    Descargar como docx, pdf o txt
    de 17

    Documento de pruebas de desarrollo – 666139

    Caso de Uso 1: RFC no registrado - ingreso manual de datos de cliente factura

    1. -Cajero ingresa a la opción venta factura en el menú principal.


    2. -GEOPos solicita ingreso de cliente fidelizado.
    3. -Cajero presiona Enter para continuar sin ingreso de cliente.
    4. -GEOPos solicita login de cajero
    5. -Cajero escanea su clave.
    6. -GEOPos muestra formulario de datos de factura, con consumidor final precargado.
    7. -Cajero completa los datos del formulario y presiona TOTAL para continuar:
     -RFC
     -Nombre
     -Domicilio fiscal (código postal)
     -Régimen fiscal
     -Uso CFDi
     -E-mail
    8. -GEOPos valida que los datos cumplan con el formato establecido.
    9. -GEOPos si los datos cumplen con el formato muestra la pantalla de venta.
    10. -Cajero ingresa productos y medios de pago y finaliza la venta.
    11. -GEOPos envía datos de la venta a Factúrame.
    12. -Factúrame se comunica con Diverza para el timbrado y le responde exitosamente al
    pos enviando el xml de la factura.
    13. -GEOPos imprime la factura (ver mantis relacionado 0666154) y envía la venta al
    Resolutor con los datos del cliente factura ingresado. El Resolutor envía datos al ERP y
    actualiza el cliente en la BD de clientes factura.

    Para este caso solo consideramos el paso 13, ya que todo lo anterior es lo ya implementado (es
    el flujo de venta que ya se tenía).

    Por lo que tenemos que validar es que se envíen los datos del cliente a resolutor.

    Ingresamos los datos del cliente a facturar:


    Totalizamos, y agregamos algún producto a la venta:

    Totalizamos:

    Ahora vamos a cruzVerde-central.log para verificar el envío del cliente:


    En este caso verificamos que enviamos los datos en la trama DC del GNCU01RequestMessage:

    dc=DC[billingRUT=0,checkDigit=<null>,partyId=0,corporateName=<null>,fantasyName=SANTIA
    GO
    RODRIGUEZ,moneyTransfer=<null>,billingAddress=<null>,billingCommune=0,billingCity=0,ship
    pingAddress=<null>,shippingCommune=0,shippingCity=0,phone=0,fax=0,email=SRODRIGUEZ@
    GEOCOM.COM.UY,socialReason=0,numberRFC=SANT210221ROD,fiscalAddress=45482,fiscalRe
    gime=611,useCFDI=D07]

    Y verificamos la respuesta correcta del servicio:

    Por lo tanto, pasamos al caso de uso 2.


    Caso de Uso 2: RFC registrado - carga automática de datos de cliente factura

    1. Cajero ingresa a la opción venta factura en el menú principal.


    2. GEOPos solicita ingreso de cliente fidelizado.
    3. Cajero presiona Enter para continuar sin ingreso de cliente.
    4. GEOPos solicita login de cajero
    5. Cajero escanea su clave.
    6. GEOPos muestra formulario de datos de factura, con consumidor final precargado.
    7. Cajero ingresa RFC del cliente en el formulario y presiona F2 para continuar.

    Para esto, consultamos por el cliente que enviamos en el CASO DE USO 1.

    8. GEOPos envía GNCC01 al Resolutor consultando por el RFC ingresado. Resolutor


    devuelve datos.
    9. GEOPos muestra datos en el formulario:
     RFC
     Nombre
     Domicilio fiscal (código postal)
     Régimen fiscal
     Uso CFDi
     E-mail
    Además, verificamos la respuesta en el log de cruzVerde-central

    10. Cajero presiona TOTAL para continuar.


    11. GEOPos valida que los datos cumplan con el formato establecido.
    12. GEOPos si los datos cumplen el formato muestra la pantalla de venta.
    13. Cajero ingresa productos y medios de pago y finaliza la venta.
    14. GEOPos envía datos de la venta a Factúrame.
    15. Factúrame se comunica con Diverza para el timbrado y le responde exitosamente al
    pos enviando el xml de la factura.
    16. GEOPos imprime la factura (ver mantis relacionado 0666154) y envía la venta al
    Resolutor con los datos del cliente Factura. El Resolutor envía datos al ERP y actualiza
    el cliente en la BD de clientes factura.

    Para esto revisamos el log:

    GNCU01RequestMessage[idType=S,dp=<null>,dc=DC[billingRUT=0,checkDigit=<null>,partyId=0
    ,corporateName=<null>,fantasyName=SANTIAGO
    RODRIGUEZ,moneyTransfer=<null>,billingAddress=<null>,billingCommune=0,billingCity=0,ship
    pingAddress=<null>,shippingCommune=0,shippingCity=0,phone=0,fax=0,email=SRODRIGUEZ@
    GEOCOM.COM.UY,socialReason=0,numberRFC=SANT210221ROD,fiscalAddress=45482,fiscalRe
    gime=611,useCFDI=D07]
    Flujo alternativo 7.1: Cajero presiona F2 sin modificar datos

    7.1.1 - Cajero no modifica datos y presiona F2 para consultar al Resolutor por el RFC del
    consumidor final.

    7.1.2 - GEOPos muestra mensaje "Debe ingresar el RFC del cliente si desea generar una
    factura" y no envía consulta de RFC al Resolutor.

    7.1.3 - Cajero presiona Esc para salir del mensaje.

    7.1.4 - GEOPos vuelve a mostrar el formulario.


    Flujo alternativo 7.2: Cajero modifica datos, pero mantiene RFC consumidor final

    7.2.1 - Cajero modifica datos del formulario, pero mantiene tipo de documento y número de
    RFC y presiona TOTAL. (No presiona F2)

    7.2.2 - GEOPos pasa a la pantalla de ingreso de artículos. Se mantiene como venta con ticket
    no facturado (factura a consumidor final).
    Flujo alternativo 7.1: Cajero presiona F2 (Traído del mantis 695967)

    7.1.1 - Cajero presiona F2 luego de haber ingresado tipo documento TAX_ID y el


    número.

    7.1.2 - GEOPos muestra mensaje "Para emitir una factura a clientes extranjeros no
    se requiere consultar RFC (F2)" y no envía consulta de RFC al Resolutor.
    7.1.3 - Cajero presiona Esc para salir del mensaje.
    7.1.4 - GEOPos vuelve a mostrar el formulario.

    Flujo alternativo 8.1: Resolutor no devuelve datos del cliente

    Este caso se puede dar por dos motivos, no se envió un cliente con ese RFC previamente y por
    eso no se devuelven datos del cliente, o porque la caja no se logró conectar con resolutor.

    Para eso diferenciamos el mensaje que se muestra.

    En primer lugar, consultamos por un cliente que no fue enviado previamente.


    8.1.1 - GEOPos muestra mensaje indicando que no se encontraron datos del cliente.

    8.1.2 - Cajero presiona ESC para salir del mensaje.

    8.1.3 - GEOPos muestra nuevamente el formulario.

    8.1.4 - Cajero debe ingresar todos los datos manualmente. Caso de Uso 1, flujo principal paso
    7.

    Ahora probamos lo mismo, pero simulando problemas de conexión con resolutor (para esta
    prueba bajo la VPN)
    Flujo alternativo 10.1: Cajero edita los datos

    Ingresamos el RFC del cliente enviado en el caso de uso 1.

    Presionamos F2 y se nos traen los datos:


    10.1.1 - Cajero edita alguno de los datos del cliente Factura y presiona TOTAL para continuar.

    10.1.2 - Continua en paso 11 del flujo principal.


    Verificamos el envío de los nuevos datos:
    GNCU01RequestMessage[idType=S,dp=<null>,dc=DC[billingRUT=0,checkDigit=<null>,partyId=0
    ,corporateName=<null>,fantasyName=SANTIAGO
    MODIFICADO,moneyTransfer=<null>,billingAddress=<null>,billingCommune=0,billingCity=0,shi
    ppingAddress=<null>,shippingCommune=0,shippingCity=0,phone=0,fax=0,email=MODIFICADO
    @GEOCOM.COM.UY,socialReason=0,numberRFC=SANT210221ROD,fiscalAddress=45872,fiscal
    Regime=607,useCFDI=D09]

    Para verificar que se hayan enviado correctamente, consultaremos nuevamente por este RFC y
    veremos si trae estos nuevos datos:
    Flujo alternativo 12.1: Datos no cumplen con el formato

    No se incluyen pruebas de esto ya que esto se desarrolló en otro mantis.

    Flujo alternativo 15.1: Se recibe respuesta de error de Factúrame

    No se incluyen pruebas de esto ya que esto se desarrolló en otro mantis.

    También podría gustarte