tesis pago electronico
DESCRIPTION
Es un excelente trabajo de investigacionTRANSCRIPT
Peralta Nouchi, José LuisSosa Navarro, Carlos Alberto
Implementación de un Sistema de Comprobantes de pago Electrónico utilizando Web Services para los Emisores (Empresas medianas y
grandes)
Tesis de Ingeniería
Lima, 17 de Octubre de 2010
Peralta Nouchi, José LuisSosa Navarro, Carlos Alberto
“Implementación de un Sistema de
Comprobantes de pago electrónico utilizando Web Services para los Emisores (Empresas
medianas y grandes)”
“Tesis presentada a la Universidad Nacional Mayor de San Marcos, Lima, Perú, para obtener el Título de Ingeniero de Sistemas”
Orientador: Luis Roig de Alcazar
UNMSM – LIMA
AGOSTO 2012
© Sosa Navarro, Carlos AlbertoPeralta Nouchi, José Luis 2012.
Todos los derechos reservados.
Mi tesis se la dedico con todo mi amor y cariño. A ti Dios que me diste la oportunidad de vivir y de regalarme una familia maravillosa
AGRADECIMIENTOS
Al profesor Luis Alarcón Loayza por su orientación y dedicación para que este trabajo cumpla con los objetivos trazados. Muchas veces abogando en contra de la presente Tesis para que me pueda dar cuenta de mis errores y mejorar la calidad de la misma.
También le agradezco a mi Padre por ayudarme a identificar la problemática planteada en este documento y su consejo como economista y proyectista.
A todas las personas que ayudaron de forma indirecta en la elaboración de este documento, a las grandes mentes que sentaron las bases que hoy yo utilizó en el desarrollo de esta Tesis y a mi familia y amigos que me dan el coraje para permanecer en la investigación.
Y por encima de todo doy gracias a Dios, por su guía y sostén.
Implementación de un Sistema de Comprobantes de pago Electrónico utilizando Web Services para los Emisores (Empresas medianas y grandes)
Resumen
El propósito de esta tesis es el de implementar un sistema de
Contenido
CAPITULO 1 – INTRODUCCIÓN...................................................................................................................101.1. Título de la Tesis...........................................................................................................................101.2. Antecedentes...............................................................................................................................101.3. Definición del Problema...............................................................................................................101.4. Objetivos......................................................................................................................................111.5. Justificación..................................................................................................................................111.6. Alcances.......................................................................................................................................11
2. CAPITULO 2 - Marco Teórico.............................................................................................................132.1. B2B (Business to business)...........................................................................................................13
2.2. B2B, B2C, C2C, A2A...............................................................................................................132.2.1. EAI.........................................................................................................................................142.2.2. Integrando intercambios inter-empresariales (B2B).............................................................152.2.3. Acoplando A2A y B2B: A2B (o colaboración de negocios).....................................................152.2.4. Arquitectura orientada a Servicios (SOA)..............................................................................152.2.5. Selección de la arquitectura de intercambio........................................................................18
2.3. XML..............................................................................................................................................212.3.1. La necesidad de un lenguaje universal..................................................................................212.3.2. EDI.........................................................................................................................................222.3.3. XML: el Lenguaje Universal de intercambio de datos...........................................................232.3.4. La coexistencia de XML y EDI................................................................................................28
2.4. Seguridad en Internet..................................................................................................................352.4.1. Seguridad en Internet crítica para el B2B....................................................................................352.4.2. Estrategia E-Security....................................................................................................................352.4.3. Servicios básicos de seguridad en B2Bi.......................................................................................362.4.4. Conceptos clave en las soluciones de e-Seguridad.....................................................................372.4.4.1. Criptografía...........................................................................................................................372.4.4.2. Cifrado de clave privada.......................................................................................................372.4.4.3. Cifrado de clave pública.......................................................................................................382.4.4.4. La firma digital......................................................................................................................382.4.4.4.1. Creación de una firma digital...........................................................................................392.4.4.5. Los certificados digitales y el papel de autoridades de certificación (CA)...........................412.5. Componentes de Integración......................................................................................................422.5.1. Los componentes y las operaciones de la arquitectura SOA......................................................422.5.2. Servicios Web (Web Services).....................................................................................................432.5.2.1. Características esenciales de un entorno de servicios Web................................................432.5.2.2. Universal Description, Discovery and Integration (UDDI)...................................................442.5.2.3. Web Services Description Language (WSDL).......................................................................442.5.2.4. WSDL schema.......................................................................................................................442.5.2.5. WSDL y UDDI........................................................................................................................452.5.2.6. Poniendo todo junto............................................................................................................452.6. SUNAT..........................................................................................................................................46
2.6.1. ¿Qué es la SUNAT?................................................................................................................462.6.2. Funciones y atribuciones de la SUNAT.................................................................................462.6.3. Comprobantes de Pago - Concepto......................................................................................48
3. CAPITULO III - Estado del Arte..........................................................................................................593.1. Caso Guatemala:..........................................................................................................................593.2. Caso Chile:....................................................................................................................................62
4. Aporte teórico..................................................................................................................................69
4.1. Análisis.........................................................................................................................................694.1.1. Requerimientos funcionales.................................................................................................694.1.2. Requerimientos no funcionales............................................................................................764.1.3. Modelo de procesos.............................................................................................................784.1.4. Diagrama de Casos de Uso....................................................................................................79
4.2. Arquitectura.................................................................................................................................874.3. Diseño..........................................................................................................................................92
4.3.1.1.1.1.1.1.1. CONCLUSIONES.........................................................................................................122Glosario....................................................................................................................................................1235. Bibliografía......................................................................................................................................124
CAPITULO 1 – INTRODUCCIÓN
1.1. Título de la Tesis
Implementación de un Sistema de Comprobantes de pago Electrónico utilizando Web Services para los Emisores (Empresas medianas y grandes)
1.2. Antecedentes
Una factura es el justificante fiscal de la entrega de un producto o de la provisión de un servicio, que afecta al obligado tributario emisor (el vendedor) y al obligado tributario receptor (el comprador). Tradicionalmente, es un documento en papel, cuyo original debe ser archivado por el receptor de la factura. Habitualmente el emisor de la factura conserva una copia o la matriz en la que se registra su emisión.
La factura electrónica es el equivalente digital y evolución lógica de la tradicional factura en papel. A diferencia de esta, se emplean soportes informáticos para su almacenamiento en lugar de un soporte físico como es el papel.
En los países en los que la legislación lo admite, la validez de una factura electrónica es exactamente la misma que la de la tradicional factura en papel y gracias a la firma digital que incluye se garantiza su integridad y un alto nivel de trazabilidad, por lo que judicialmente es un documento considerado como vinculante y que no necesita de mayor prueba o confirmación que su propia existencia.
En lo que respecta a Perú, la Superintendencia Nacional de Administración Tributaria (SUNAT) debe recabar información sobre los contribuyentes y eso lo hace de manera electrónica pero también de manera ‘manual’, debido a la enorme cantidad de comprobantes de pago que se generan entre empresas en el mercado.
Estos documentos tienen una información importante que la SUNAT podría recabar de manera más rápida si estuviesen en formato electrónico, y es por ello que desde hace algún tiempo ha comenzado un programa de facturación electrónica mediante el cual los contribuyentes ya no emitirán comprobantes físicos sino electrónicos.
El proceso involucra no solo a la SUNAT y a los contribuyentes, sino también a los proveedores de las soluciones que harán que las empresas pueden emitir este tipo de documentos. Conversamos con ellos y recabamos información de un seminario que se organizó sobre el tema, y en el que estuvo presente una representante de la SUNAT y de un proveedor de soluciones internacional. También conversamos con un implementador local.
1.3. Definición del ProblemaEl proceso de Facturación tradicional adolece de diversas imperfecciones entre ellas tenemos costos,
demora, control, entrega, almacenamiento, riesgo de fraude y evasión fiscal en el proceso de generación de las facturas de los Emisores y su envío a la SUNAT .
Estas limitaciones se traducen en la baja productividad del área de Tesorería de las empresas Emisoras al realizar actividades manuales de impresión, almacenaje y distribución de los comprobantes de pago físicos generando gastos. Estas empresas no cuentan con una herramienta donde sus proveedores puedan realizar consultas y seguimientos en forma directa del estado de sus comprobantes de pago.
1.4. ObjetivosOptimizar los procesos de facturación y recepción de comprobantes de pago electrónicas de El Emisor,
mediante el uso de Web Services, que integrará y facilitará el intercambiando de información con SUNAT, sus clientes y proveedores, lo que les permitirá incrementar su eficiencia operativa.
● Estructurar la información de los comprobantes de pago de El Emisor en el formato indicado por SUNAT (XML) para ser considerado comprobante de pago electrónico. Brindar transparencia al Emisor con el Sistema SUNAT.
● Facilitar la transmisión de los comprobantes de pago electrónicos emitidos por El Emisor a SUNAT y retornar la constancia de recepción emitido por SUNAT.
● Poner a disposición de El Emisor un portal web para publicar el detalle de la información de sus comprobantes de pago emitidos electrónicamente, de acuerdo a lo normado por SUNAT; facilitando el acceso a dicha información a cada uno de sus clientes.
● Facilitar el registro de la información de los comprobantes de pago electrónicos recibidos de sus proveedores, en el ERP de El Emisor.
● Brindar a El Emisor un portal web donde sus proveedores puedan realizar consultas y seguimientos en forma directa del estado de sus comprobantes de pago electrónicos.
● Aumentar la productividad del área de Tesorería al eliminar actividades manuales de impresión, almacenaje y distribución de los comprobantes de pago físicos. Así mismo, se puede reducir considerablemente las consultas telefónicas o personales de los proveedores interesados en la confirmación del registro de sus comprobantes de pago y de manera opcional sobre la programación de pagos y detalles de sus pagos.
Integrar a El Emisor a la comunidad electrónica empresarial, lo que permitirá el desarrollo de actividades colaborativas.
1.5. Justificación
La importancia de implementar un sistema que permita operar con factura electrónica nace de la innegable necesidad de otorgar validez legal al ejemplar electrónico de documentos tributarios de compra y venta tales como facturas, boletas, notas de crédito, notas de débito, ya que con ello se optimiza la operación de las empresas y de la SUNAT.
En tal sentido con el nuevo sistema, las empresas (Emisores) podrán electrónicamente generar, firmar, transmitir y almacenar comprobantes de pago, reduciendo los costos del proceso de facturación, y permite incorporar grandes mejoras en su operación y en los servicios ofrecidos a sus clientes (Receptores), a la vez que les simplifica el cumplimiento de sus obligaciones tributarias.
A la Superintendencia Nacional de Administración Tributaria (SUNAT) le permitirá recabar información sobre los contribuyentes de manera más rápida, segura y eficiente para fiscalizar mejor los créditos y débitos, mejorar el control sobre el traslado de bienes con documentos válidos para la fiscalización, optimizar el control del IGV y otorgar mejores servicios, con información de mejor calidad, a los contribuyentes.
Además esto permitiría al país generar ahorros cercanos al 80% sobre los costos del sistema tradicional, se mejoraría la competitividad del país, se impulsaría el comercio electrónico, y se impulsarían las compras electrónicas del Estado.La importancia de implementar un sistema que permita operar con factura electrónica nace de la innegable necesidad de otorgar validez legal al ejemplar electrónico de documentos tributarios de compra y venta tales como facturas, boletas, notas de crédito, notas de débito, ya que con ello se optimiza la operación de las empresas y de la SUNAT.
En tal sentido con el nuevo sistema, las empresas (Emisores) podrán electrónicamente generar, firmar, transmitir y almacenar comprobantes de pago, reduciendo los costos del proceso de facturación, y permite incorporar grandes mejoras en su operación y en los servicios ofrecidos a sus clientes (Receptores), a la vez que les simplifica el cumplimiento de sus obligaciones tributarias.
A la Superintendencia Nacional de Administración Tributaria (SUNAT) le permitirá recabar información sobre los contribuyentes de manera más rápida, segura y eficiente para fiscalizar mejor los créditos y débitos, mejorar el control sobre el traslado de bienes con documentos válidos para la fiscalización, optimizar el control del IGV y otorgar mejores servicios, con información de mejor calidad, a los contribuyentes.
Además esto permitiría al país generar ahorros cercanos al 80% sobre los costos del sistema tradicional, se mejoraría la competitividad del país, se impulsaría el comercio electrónico, y se impulsarían las compras electrónicas del Estado.
1.6. Alcances
El módulo de Comprobantes de Pago Electrónico está orientado a facilitar el intercambio de información, entre El Cliente, la Superintendencia Nacional de Administración Tributaria (SUNAT), sus clientes y proveedores, además de brindar una plataforma donde puedan realizar seguimiento directo y en línea de los comprobantes de pago electrónicos.
La información de los comprobantes de pago emitidos por El Cliente será trasferida a SUNAT, a fin de que sea validada y cumpla con los parámetros requeridos para que el comprobante de pago electrónico sea considerado como conforme.
El Cliente podrá transmitir sus comprobantes de pago electrónicos a sus clientes de distintas formas:1. Directamente al sistema comercial de su cliente (mediante una integración de “punto a punto”). La
información puede ser pre-registrada en el sistema ERP de su cliente para facilitar su procesamiento. 2. En formato PDF, mediante un correo electrónico designado por su cliente. 3. Además, de poner la información a disposición en la plataforma para una descarga (impresión)
directa por parte del cliente. El Cliente podrá llevar un control del estado de sus comprobantes de pago electrónicos:
SUNAT● Aceptado● Aceptado C/ Obs.● Rechazado
Documento● Emitido● Visualizado ● Aceptado
De la misma manera, El Cliente podrá recibir la información de los comprobantes de pago electrónicos de sus proveedores, facilitando su procesamiento mediante el pre-registro o registro directo en su sistema ERP.
De manera opcional1 se puede:● Realizar validaciones previas a la información a ser enviada por los proveedores, basadas en la
información de las órdenes de compra, confirmaciones de ingresos de mercadería recibida y/o
1
aceptación de servicio recibido, evitando así recibir facturas que no coincidan con la información base, registrada en su ERP, para el procesamiento de la factura.
● Mostrar al proveedor información sobre la programación de pago y el detalle de los pagos (moneda, banco, descuentos) cuando éstos se realicen. Con esta solución se podrá reducir notablemente las llamadas de los proveedores sobre consultas del estado de sus comprobantes de pago y del pago respectivo, manteniendo informados a sus proveedores del estado de éstos, publicando dicha información en el portal.
El alcance geográfico del servicio abarca las operaciones de El Cliente en Perú con todos sus proveedores a nivel nacional.
2. CAPITULO 2 - Marco Teórico
2.1. B2B (Business to business)
El significado del acrónimo B2B parece expandirse diariamente, pero podemos acotar 2 definiciones por el momento. Primero, B2B significa negocios haciendo negocios con otros, y no solo en las formas tradicionales, sino a través de internet y usando comunicación instantánea para hacer que estas empresas o negocios no solo incrementen ventas sino la capacidad de trabajar de forma más sinérgica, rápida y barata.
B2B, entonces se refiere a negocios trabajando con otros negocios para incrementar sus ganancias y acerca de organizaciones y gobiernos comunicándose rápidamente y eficientemente. Esto significa intercambio de documentos, como órdenes de compra, facturas, listas de precios, artículos científicos, legislaciones y no por vía terrestre o mail, sino a través de la red. En vez de pilas de papel desbordando cajones de escritorio, se usan documentos electrónicos almacenados en unidades de disco, que se pueden imprimir a voluntad en el momento deseado. B2B trata también de acuerdos legales firmados digitalmente en diferentes continentes, haciéndose efectivos en minutos en vez de semanas. También es acerca del incremento de velocidad y volumen de comercio entre sistemas remotos corriendo en plataformas incompatibles, ahora intercomunicados por un protocolo de intercambio de acuerdo mutuo.
B2B trata acerca de compartir ideas, software, secretos, servicios, productos, planes, objetivos, tratos y clientes, todo tan rápido como el Internet pueda, lo cual generalmente no tarda más 1 segundo o 2. Los negocios se hacen más rápido, más eficientemente, más preciso y lejos menos caro, de tal forma que las organizaciones ganan, el gobierno gana, tus agentes de intercambio, terceros ganan, tus clientes ganan.
Una de las tecnologías más importantes relacionadas al comercio B2B es Extensible Markup Language, o XML. XML subyace la mayoría, sino todas las tecnologías que soportarán el nuevo modelo de negocios B2B.
2.2. B2B, B2C, C2C, A2A
Estos términos son muy usados en estos tiempos. Veamos, B2C hace referencia a Negocio a Cliente. Esto hace referencia a la interacción directa entre clientes y negocios a través de internet, tales como ordenar un producto a un proveedor por internet. Ese negocio podría ser un fabricante de productos como Dell, que vende directamente a sus usuarios o también puede ser un proveedor que asume el rol tradicional de mayorista, vendiendo una serie de bienes provenientes de diferentes fuentes, tal como es Amazon.
C2C es el acrónimo de cliente a cliente. Este tipo de acuerdos hacen posible la compra de productos en unidades singulares o pequeñas cantidades de persona a persona, como la subasta de una casa online en eBay.com, por supuesto, otro que viene a la mente es auctions.yahoo.com. Estos sitios, así como portales como biddersedge.com, permiten a individuos hacer compras con otros iguales. Comprar uno a uno ha sido posible en el pasado por publicaciones nacionales, pero nunca antes de que internet nos permita buscar y pagar por nuestras adquisiciones tan rápido.
A2A es el acrónico de aplicación a aplicación. Lo que quiere decir que una aplicación puede comunicarse directamente con otras aplicaciones, usualmente a través de la red. Como el nombre implica, el proceso es automático y requiere la no intervención humana.
Aunque esto puede también requerir interacción humana, uno de los objetivos principales de B2B es organizar a los sistemas de tal forma que puedan comunicarse con otros automáticamente.
2.2.1. EAI
El término EAI apareció por primera vez en USA alrededor de 1996-1997 con la publicación de artículos de investigación por grandes firmas incluyendo Roy Schulte de Gartner Group. Estos estudios analizaron los enfoques encontrados en un determinado número de empresas grandes para explicar la emergencia de un rango de problemas de integración, los cuales predijeron se convertiría en uno de los problemas más importantes de los próximos 10 años. Sin embargo, si el término EAI fue inventado, conceptualizado, y traído al mercado por norte americanos, los precursores en este asunto fueron los franceses.
EAI es una colección de métodos, herramientas y servicios que trabajan juntos para permitir la comunicación entre aplicaciones heterogéneas, como parte de la empresa tradicional, distribuida o extendida.
En otras palabras, el problema esencial a resolver es el intercambio de información entre las aplicaciones en sistemas de información, y más específicamente, a responder la pregunta, cómo nosotros podemos asegurar que aplicaciones heterogéneas, diseñadas en diferentes periodos, por diferentes e quipos y usando diferentes tecnologías, puedan comunicarse sin de necesidad de conocerse unos con otros, o tomar en cuenta sus respectivas limitaciones o restricciones.
Es necesario insistir en lo que no es el dominio de EAI, porque la confusión aparece. EAI no es la manera concerniente a la comunicación interna de una aplicación. El problema de comunicación entre los componentes de una aplicación cliente/servidor no cae en el dominio de EAI. Ese es el problema de la arquitectura de la aplicación. Sin embargo, la manera en que este sistema cliente/servidor se comunica con otras aplicaciones constituye un verdadero problema EAI.
También podemos decir que EAI concierne a la comunicación entre aplicaciones heterogéneas. Aplicaciones que comparten repositorios y usan semánticas comunes y tecnologías idénticas no representan un problema de integración con uno y otro. En otras palabras, aplicaciones homogéneas ya están integradas. Desplegar los métodos y herramientas de desarrollo para crear estas aplicaciones integradas (por ejemplo objetos integrados usando CORBA)tampoco cae dentro del dominio de EAI. Un enfoque EAI resulta en aplicaciones coexistiendo con otras aplicaciones que fueron construidas con diferentes tecnologías, y las cuales son incapaces de comunicarse naturalmente una con otra.
EAI por lo tanto se ocupa de dominio más antiguo en integración: el dominio de aplicaciones de negocio – Application to Application (regularmente llamado AtoA o A2A). Esto es típicamente el dominio de integración con ERP, o la integración de aplicaciones de frente de oficina con las aplicaciones de fondo de oficina, o la integración de gestores de relación con el cliente (CRM), y gestores de cadena de suministro (SCM), etc.
2.2.2. Integrando intercambios inter-empresariales (B2B)
Intercambios inter-empresariales (BtoB o B2B) concierne a intercambios de bienes o servicios entre 2 entidades comerciales (aliados, clientes, proveedores), sin considerar intercambios con el cliente o consumidor final. Intercambios entre empresas se hacen presentes cuando se involucra el intercambio de transacciones comerciales (órdenes de compra, facturas, etc.) a través de EDI.
El soporte técnico para estos intercambios puede tomar la forma de implementación de funciones automatizadas de intercambio de archivos. Otra vez, los precursores en esta materias fueron las corporaciones francesas, como NETSYS con Inter, y otras más.
Dibujando una paralela con la definición de EAI, nosotros podemos decir que la integración B2B es una colección de métodos, herramientas y servicios que trabajan juntos para que aplicaciones de TI de diferentes empresas puedan intercomunicarse, con el objetivo de cargar transacciones comerciales entre ellos.
La integración inter-empresarial es por lo tanto una extensión de un conjunto de problemas de EAI, y por lo tanto permanece fundamentalmente adjunta a la capacidad de intercambiar información entre aplicaciones heterogéneas que no pertenecen a los mismos sistemas de información, desde que pertenecen a diferentes empresas.
Nosotros podemos por lo tanto decir que la integración B2B corresponde a integración inter-empresarial A2A. Las diferencias fluyen esencialmente sobre lo que la empresa no puede controlar:
- La red de comunicación- El formato de intercambio- El proceso de intercambio
2.2.3. Acoplando A2A y B2B: A2B (o colaboración de negocios)
En tiempos actuales, el rango de problemas relacionados a A2A y B2B no solo coexiste sino que ya son tendencia, por razones de negocio, para inter-penetrar:
- Intercambios entre dominios en empresas grandes pertenecen más al rango de problemas en B2B.
- Proveer un servicio a los clientes ayuda a federar ambas aplicaciones dentro de la empresa y las aplicaciones dentro de los proveedores y sub-contratistas.
- Los dominios de responsabilidad empiezan a incrementar más de forma horizontal debido al intra/inter-empresarial.
La conciencia de la unión de los dos enfoques es relativamente nueva e implica algunos puntos específicos. Nos referimos a ella como A2B ("Aplicación a Negocios"), aunque cada vez más, se conoce bajo la colaboración empresarial a largo plazo.
2.2.4. Arquitectura orientada a Servicios (SOA)
La implementación de una arquitectura de servicios no está directamente asociada con el tipo particular de integración, aunque esto a veces dibuja sus orígenes en el problema de integrar aplicaciones complejas o en otros casos, sigue y ayuda el alcance BPM.
Este tipo de integración fue fuertemente acelerado por el desarrollo de intercambios entre empresas y consumidores finales: Business to Consumer o “B2C”.
B2C es probablemente el dominio que ha provocado la mayor discusión alrededor del tema de integración en los años más recientes. De hecho, con la explosión de Internet, B2C y sus intercambios han sido multiplicados, requiriendo la implementación de nuevas aplicaciones que usan tecnologías web como navegadores, HTML, servidores HTTP, SMTP, aplicaciones java, etc.
La necesidad de integrar estas aplicaciones en los sistemas de información existentes aparece como un elemento crucial en la capacidad de las empresas para responder rápidamente a demandas del consumidor en el acceso online a catálogos, precios, condiciones de ventas, retrasos de entrega de productos y la posibilidad de ordenar, pagar, etc. En pocas palabras un consumidor que siempre quiere todo mejor, más rápido, y más barato.
Un típico ejemplo de este tipo de problemas es la implementación de portales de ventas en internet, los cuales requieren, por ejemplo, consultas de inventarios en tiempo real y actualizaciones, tanto como la interacción con aplicaciones de gestión de clientes. Ver figura.
Ejemplo de integración con el cliente.
En este punto podemos definir a la integración B2C como un conjunto de métodos, herramientas y servicios que trabajan juntos para permitir que aplicaciones heterogéneas en una empresa se comuniquen unas con otras, con el objetivo de dar a los clientes acceso directo a los servicios ofrecidos por la empresa.
Los puntos para resolver en intercambios de integración con consumidores son similares a los mencionados en la integración de aplicaciones en la empresa: en ambos A2A y B2C, las aplicaciones
deben ser capaces de intercambiar información unas con otras. Sin embargo, en B2C, una de estas aplicaciones es construida desde datos y servicios en aplicaciones existentes, y es esta aplicación la que maneja la interface de cara al usuario.
Desafortunadamente, desde que las aplicaciones existentes no fueron originalmente diseñadas para responder a este tipo de petición, de tal forma que ambas aplicaciones deben ser adaptadas o soluciones de integración deben ser implementadas. Aquí, nosotros entramos en el dominio de arquitectura orientada a servicios o SOA.
En el documento “Reference Model for Service Oriented Architecture 1.0” [ORM 06], OASIS define SOA como un paradigma para organizar y usar medios distribuidos que
pueden ser la propiedad y bajo el control de diferentes dominios. SOA provee una manera uniforma para ofrecer, descubrir, interactuar con y usar estos medios para producir los resultados anticipados con respecto a las expectativas y condiciones mensurables.
Una arquitectura orientada a servicios es un enfoque intencionado para garantizar mayor agilidad y capacidad de reacción en sistemas de información distribuidos, heterogéneos, por medio de la presentación de una nueva manera de integrar y manipular los diferentes ladrillos y componentes de la aplicación en un sistema computacional, y para manejar los enlaces que ellos soportan.
Este enfoque no es nuevo, y ha sido (por ejemplo) usado en el diseño de software cliente/servidor. Similarmente, arquitecturas distribuidas e invocación a métodos remotos como son DCE o CORBA también manejan la noción de servicio. De hecho, estas 2 últimas tecnologías inspiran SOA en casi toda su comprensión.
Sin embargo, estos modelos han sufrido desde la ausencia de estándares de intercambio, los cuales explican porque en enfoque genuino de SOA tuvo que esperar a la aparición de tecnologías vinculadas a los servicios web.
Esto concluye la presentación general de la amplitud de problemas en integración de aplicaciones. Lo que queda pendiente es examinar las diferentes funciones que esta solución puede proveer de tal forma que se gestionen las necesidades y restricciones identificadas. Estas funciones puede ser delineadas en 3 niveles:
- Transporte y conectividad- Adaptación de la información- Automatización de los procesos.Es también necesario determinar si la mejor arquitectura de intercambio es centralizada o
distribuida.
Componentes en la infraestructura de integración
2.2.5. Selección de la arquitectura de intercambio
“Tipos de distribución física para servicios de integración de aplicaciones”
Una vez que los límites del proyecto han sido determinados, el dominio de integración objetivo, los tipos de aplicaciones a ser integrados, la cartografía de los intercambios, recién podemos abordar la pregunta sobre el tipo de comunicación a usar entre las aplicaciones a ser integradas y la arquitectura de intercambio a ser usado en este proyecto.
2.2.5.1. Comunicación síncrona/asíncrona
Los resultados de la integración entre aplicaciones no deben recrear un sistema spaghetti dentro de la solución de integración. Buscando mantener el sistema de información flexible y reactivo, perdiendo acoplamiento entre estas aplicaciones para ser favorecidos.
Más allá de eso, un estudio minucioso de los diferentes tipos de integración nos confirman esto: integración por propagación de datos o integración de procesos de múltiples pasos solo implementan interacciones asíncronas y unidireccionales. En este caso, preferimos usar comunicación asíncrona, como son MOMs o gestores de archivos de transferencia.
Sólo la integración de aplicaciones compuestas necesita interacciones síncronas y bidireccionales por las cuales nosotros deberíamos usar tecnologías como puentes DBMS, ORBs (intermediarios de petición de objetos), llamadas RMI (invocación remota), o tanto actualmente también, llamadas a servicios web como parte del enfoque SOA.
2.2.5.2. Arquitectura centralizada o distribuida
Una vez que el tipo de comunicación ha sido determinado, se debe abordar el tema de la selección de la arquitectura de intercambio. La elección de esta arquitectura podría, adicionalmente, influenciar directamente en la elección de herramientas que van a participar más adelante.
2.2.5.2.1. Arquitectura centralizada
Arquitectura centralizada concentra en un punto focal el conjunto completo de servicios asegurados por la infraestructura. Las aplicaciones a ser integradas y a conectar con este punto usando los adaptadores apropiados. En un ambiente de varias máquinas, esta arquitectura, designada “hub and spoke” en la terminología de herramientas EAI (ver Figura), hace posible el no tener que desplegar todos los componentes en la infraestructura en el conjunto completo de plataformas. En el lado negativo, si la plataforma que soporta el hub colapsa o se sobrecarga, esto puede potencialmente generar un punto singular de pago (SPOF) y contención en el sistema de información.
Arquitectura Hub and spoke
2.2.5.2.2. Arquitectura distribuida
Una arquitectura distribuida comparte la infraestructura sobre un conjunto de máquinas que soportan las aplicaciones a ser integradas, con cada aplicación conectando localmente a esa infraestructura a través de adaptadores. Esta arquitectura no introduce ningún punto de fallo o contención. Sin embargo, en el lado negativo, esto requiere herramientas adaptadas a la heterogeneidad de las plataformas donde estos componentes deben ser desplegados, tanto como herramientas para la supervisión y mantenimiento de estos componentes en las diferentes plataformas.
Arquitectura BUS
Dado que la distribución puede trabajar a nivel de los servicios de integración en sí, de este modo, nos encontramos en presencia de una arquitectura de tipo bus (ver Figura). Los servicios de integración, por lo tanto se distribuyeron en lo que asegura una "Engranaje" de la infraestructura de cambio, haciendo la solución más robusta (no SPOF (punto único de fallo) de servicio en la ruta crítica).
Esto también puede llevarse a cabo mediante el despliegue de múltiples plataformas de integración en el sistema, la creación de una arquitectura de copo de nieve (ver Figura). Este tipo de arquitectura es particularmente relevante en el caso de despliegue a gran escala de la infraestructura en el interior de las grandes empresas. Cada dominio de la responsabilidad está en control de sus intercambios, y se comunica de una manera estándar con otras entidades de gran parte de la empresa. Esta es una ilustración operativa de manejar la gama de problemas en la A2B, o de colaboración de negocios.
Arquitectura Snowflake
Una vez el tipo de arquitecta ha sido determinado, el siguiente paso considera la elección de las herramientas que construirán o harán posible la infraestructura. La opción será guiada por el conjunto completo de resultados del análisis bajo diferentes puntos foco que examinamos, y hace posible responder a las necesidades detectadas y restricciones.
2.3. XML
2.3.1. La necesidad de un lenguaje universal
Con el fin de participar en el comercio electrónico B2B, las empresas se están moviendo hacia la auto-servicio del cliente, integración de aplicaciones empresariales y la asociación dinámica con empresas externas y los intercambios. Esta naturaleza cambiante de los negocios ha aumentado significativamente la complejidad de procesamiento de datos empresariales. Los datos de este ambiente de negocios se pueden encontrar en variados formatos, tales como mensajes de diferentes socios comerciales, los documentos internos de las empresas, los mensajes de los clientes al por menor, varios interfaces para sistemas basados en transacciones, bases de datos y páginas Web. Capturar, gestionar y utilizar eficazmente los datos de negocio se ha convertido en una tarea tambaleante.
Debido a la falta de un formato de intercambio universal de datos, las empresas no son capaces de explotar al máximo la automatización, tanto interna como externamente, que permita una comunicación fluida entre las aplicaciones internas y aplicaciones externas asociadas. Como resultado, la mayoría de los departamentos de tecnología de la información dedican más del 40% de su tiempo en la extracción, volver a la definición y actualización de datos para atender las necesidades específicas, de acuerdo con un reciente estudio de Forrester Research.
Es imposible soñar siquiera de B2Bi basado en la Internet, sin un lenguaje universal que se entiende por todas las partes implicadas en la integración. A través del uso de esta lengua, las empresas podrán realizar transacciones comerciales a través de fronteras organizacionales. Su uso en el intercambio de datos entre las aplicaciones de negocio de la organización transversal es un requisito clave para el éxito de e-business.
Las empresas de la industria de la misma vertical que por lo general se relacionan entre sí como competidores, se beneficiarán enormemente gracias a su colaboración en un formato de intercambio universal de datos para documentos comerciales, tales como facturas y órdenes de compra. Todas las empresas tienen que participar en esta transición al lenguaje universal de formato de datos para que sea un éxito. Así, además de la adopción por las empresas Fortune 1000, que también tiene que ser aceptada por un estimado de 25.000.000 de pequeñas y medianas empresas (PYME) en el mundo.
Repasemos brevemente Electronic Data Interchange (EDI), un método tradicional - y sigue siendo la forma dominante de las empresas de intercambio de información por vía electrónica.
2.3.2. EDI
Electronic Data Interchange, o EDI, es un formato para el intercambio electrónico y el comercio que ha evolucionado dentro de estándares nacionales e internacionales (ANSI x12, ISO 9735, y UN/EDIFACT). Un número mayor de corporaciones han adoptado EDI, pero este todavía no se ha trasladado a empresas más pequeñas por costos y otras barreras. Mientras una compañía se puede beneficiar de la reducción de costos de transacciones a través de EDI, este debe también ser capaz se compensar la factura de consultoría, infraestructura y mantenimiento. Incluso el costo de la sola especificación EDI, acumulando miles de dólares, puede ser suficiente para alejar a los más pequeños de la carrera.
Si echamos un vistazo a EDI, podremos ver que muchos de sus conceptos han sido incorporados dentro del modelo B2B, y sus esfuerzos están en la vía a considerarse en el vocabulario XML, teniendo ejemplos como OBI. EDI es un formato que va a permanecer en el mercado y todavía no tiene visos de ser reemplazados por XML es un futuro cercano.
2.3.2.1. Como funciona EDI
EDI funciona proporcionando una colección de formatos de mensaje estándar y un diccionario de los elementos que se pueden intercambiar a través de cualquier servicio de mensajería electrónica. EDI se basa en las normas elaboradas conforme a las directrices de la American National Standards Institute (ANSI), el coordinador de las normas nacionales en los Estados Unidos. El comité ANSI garantiza que todo el mundo mediante un proceso como EDI sigue las mismas reglas y métodos, por lo que el programa de acceso universal. Como resultado de la norma, todas las empresas con participación de IED un lenguaje de intercambio común, lo que minimiza la necesidad de cambio en los sistemas internos de procesamiento de datos.
EDI basado en la comunicación entre diferentes partners.
El tráfico de EDI se compone sobre todo de las empresas de transferencia de archivos a granel.
Socios comerciales EDI rara vez se conectan entre sí directamente. En su lugar, utilizar los servicios de VAN según el cual cada socio comercial se conecta a la VAN (ver figura). El proveedor de servicios de la VAN administra las conexiones a todos los socios comerciales.
2.3.3. XML: el Lenguaje Universal de intercambio de datos
XML es el 'lenguaje universal de intercambio de datos "en la medida que el intercambio de datos entre diversas aplicaciones escritas en cualquier idioma y que se ejecuta en plataformas heterogéneas se refiere. El uso de XML hace que sea bastante fácil para las aplicaciones de intercambio, interpretar y actuar sobre los datos. XML tiene gran influencia en Internet, mensajes basados en XML se pueden intercambiar a través de Internet utilizando Hypertext Transfer Protocol (HTTP) o HTTPS (SSL - Secured Sockets Layer HTTP).
XML proporciona un medio eficaz de separar los datos y la estructura de los documentos que representan los procesos de negocio. Con base en estas virtudes, XML se compromete a permitir el desarrollo de comercio electrónico B2B aplicaciones que se basada en datos. El impacto potencial es significativo: los servidores de aplicaciones compatibles con XML, servidores web, aplicaciones internas existentes, los sistemas ERP y las aplicaciones externas se pueden hacer rápidamente todo su in-formación disponible en un formato sencillo y útil.
Puesto que el XML es a la vez universal y flexible, se ha convertido en uno de los componentes más potentes de B2Bi, permitiendo a los sistemas para compartir datos y aportar un valor añadido ya que los datos se pasa de punto a punto. El uso de XML permite a los socios comerciales para concentrarse en sus propios procesos de negocio internos y puede incluso cambiar a su propia conveniencia. Por ejemplo, la empresa A puede utilizar XML para comunicarse con la empresa B, independientemente de lo que los sistemas internos de cada empresa utiliza. Para ello, la compañía A convierte los datos que desea compartir con la empresa B en formato XML. Todas las dos
empresas tienen que hacer es ponerse de acuerdo sobre un conjunto de etiquetas (o utilizar un conjunto estándar de su industria).
2.3.3.1. Qué es XML?
XML es un lenguaje desarrollado por el W3C para la presentación visual de información sobre los hechos que pueden facilitar el intercambio de datos entre aplicaciones y / o humanos.
Aunque el origen de HTML y XML es la misma - Standard Generalized Markup Language (SGML), HTML está diseñada principalmente para sólo la presentación de las páginas de hipertexto en los navegadores, XML, por el contrario, está diseñado para crear nuevos lenguajes de marcado para la nueva tipos de documentos. HTML restringe a los usuarios a sólo unos pocos elementos de juego definidas por el W3C, como <HEAD>, <B0DY> y <H2>. XML permite a los usuarios definir nuevos elementos para el procesamiento de la información en su dominio particular contexto, o en el campo. Creación de tipos de documentos, la etiqueta conjuntos, la creación de documentos XML y el comportamiento de XML procesador, que analiza el documento XML, son determinados y en base a las especificaciones de XML 1.0. La especificación de XML se puede obtener en http://www.w3c.org/xml.
Los conceptos en los que se construye XML son bastante sencillos:el significado de los datos en un documento XML se especifica por el etiquetas de los
elementos de datos y las relaciones entre diferentes elementos de datos en el mismo documento se realiza a través de anidación simple y referencias.
Por lo tanto XML no sólo especifica los elementos de datos, sino también su semántica.Sin embargo, el XML es simplemente un lenguaje de definición de datos, no una
tecnología.XML no puede por sí misma integrar los diferentes sistemas.
XML permite al usuario:• definir sus propias etiquetas• especificar la semántica del documento;• formar un solo archivo, compuesto de lógica, reuniendo a múltiples archivos;• proporcionar procesamiento de la información a la aplicación de soporte, como un
Parser de XML, XML validador de documentos o un navegador;• tener un intercambio seguro de datos mediante el protocolo HTTP y HTTPS la
comunicación, junto con otras soluciones de seguridad;• añadir comentarios a la edición de un archivo XML;• Tener búsquedas más rápidas y la recuperación de documentos, ya que es más fácil
disponer en un repositorio XML indexados, y• Identificar la ubicación y el formato de las ilustraciones en un documento de texto.Es importante hacer notar, sin embargo, que XML no es:• Un conjunto predefinido de etiquetas que pueden ser usados para documentos de
marcado; o
• Un modelo normalizado para la producción de determinados tipos de texto documentos.
2.3.3.2. XML fortalezas
2.3.3.2.1. Poderoso meta-lenguaje
Al ser un derivado de SGML, XML es compatible con el desarrollo de nuevos lenguajes de marcado para las industrias verticales y los dominios de negocio. El lenguaje XML consta de reglas que cualquier persona puede seguir para crear un lenguaje de marcas. Algunos de los ejemplos incluyen FpML (Financial Products Markup Language), cXML (Lenguaje de marcado extensible Comercio).
Las normas garantizan que un solo programa compacto, el analizador, puede procesar todos estos nuevos lenguajes. XML se puede integrar varios archivos (con datos estructurados y datos no estructurados) en un documento único compuesto. Ejemplo de datos estructurados son los archivos heredados o base de datos relacional, los datos no estructurados pueden ser documentos de texto, gráficos e imágenes, recursos de audio y vídeo y páginas web.
2.3.3.2.2. Permite concordancia semántica entre los socios comerciales
XML permite la creación de concordancia semántica entre las compañías de intercambio de documentos XML, proporcionando una asignación, transformaciones y referencias cruzadas en el documento. A través de un flujo de trabajo XML, que puede ser distribuido a todos los socios comerciales, o puede estar en función de cada socio, las empresas también se puede definir la tramitación de este documento XML mediante la identificación de las actividades, procesos y tareas.
2.3.3.2.3. Vocabularios específicos de dominio
XML permite a los vocabularios de construcción específicos de dominio para la industria horizontal y vertical para, entre otros, la publicidad, el comercio financiero y electrónica. Estos vocabularios estandarizará el proceso de comunicación entre los socios de negocios. Varias compañías también están desarrollando internos vocabulario para describir los procesos corporativos de datos internos.
2.3.3.2.4. Auto-describe e interpreta
XML es legible para seres humanos, la auto-descripción del lenguaje. Sin ningún conocimiento de aplicaciones y programas de software a los remitentes y los
receptores finales, los documentos XML se pueden cambiar porque la sintaxis de un documento XML se describe las relaciones entre los diversos elementos.
Esta relación se puede describir de forma explícita a través de las definiciones de tipo de documento (DTD) o implícitamente a través del contexto del elemento. La disociación de las aplicaciones y los datos también permite a los cambios en las transacciones, sin ningún tipo de cambio que se requiere en las aplicaciones subyacentes, con sólo cambiar el DTD. Propietario, así como de la industria DTD estándar (XML / EDI, RosettaNet, etc) se puede utilizar, dependiendo del requerimiento y la disponibilidad.
2.3.3.2.5. Simple
Puesto que el XML está basado en texto, es muy fácil de comprender y entender los documentos XML, su estructura, contenido, elementos y relaciones. Esto hace que sea más fácil de mantener y gestionar los contenidos en los documentos XML.
Por ejemplo, si un documento XML contiene <FRUIT> Orange </> Frutas y <COLOR> Orange </ color>, es fácil distinguir que la primera instancia de Orange es en el contexto de la fruta y la segunda aparición es en el contexto de color.
2.3.3.2.6. Lenguaje universal
XML es un lenguaje universal que puede ser utilizado en, posiblemente, todas las aplicaciones, tales como los sistemas heredados, ERP, CRM, la interfaz gráfica de usuario para las aplicaciones, aplicaciones orientadas a objetos en C + + y Java, bases de datos como Oracle, Sybase y ODBMS repositorio de potencia de XML, por nombrar sólo algunos.
Programas que estén debidamente codificados para analizar ciertos documentos XML pueden incluso entender los lenguajes que utilizan un conjunto de caracteres diferentes, como el árabe o el japonés. Esto permite el intercambio de información, no sólo entre los diferentes sistemas informáticos y aplicaciones, sino también en todos los idiomas y países.
2.3.3.2.7. Estándar abierto y común
XML se basa en estándares abiertos comunes, lo que le separa del navegador de propiedad, programas de análisis, editores, etc. Esta es una de las grandes ventajas de XML.
2.3.3.2.8. Nivel de compresión alto
La compresión de datos esencialmente significa maximizar el rendimiento de una secuencia de entrada dada. Dado que los documentos XML se estructuran y
ordenado altamente, que puede ser comprimido bastante bien, aumentando así el rendimiento. De hecho, la compresión de documentos XML es mucho mejor que un documento de texto estándar como el último es generalmente menos estructurada.
2.3.3.3. XML limitaciones
2.3.3.3.1. Mensajes XML puede ser muy grandes
Mensajes XML puede ser tan grande como 5 a 10 veces sus mensajes EDI equivalentes, lo que es mucho más lento que el EDI. Este gran flujo de datos a través de Internet utiliza una gran cantidad de ancho de banda y ralentiza todo el proceso hacia abajo. Para las grandes empresas que tienen relaciones fijas y alto volumen de transacciones, EDI sigue siendo una mejor manera de manejar esas conexiones. XML, por otro lado, se puede utilizar para la búsqueda de cualquier a cualquier conectividad.
2.3.3.3.2. Diferentes estándares
Varias organizaciones y empresas están promoviendo sus propios sabores de los estándares XML. Esto se suma a una gran confusión en el mercado sobre los problemas de interoperabilidad. XML es sólo una tecnología en evolución y hay varias piezas que están siendo desarrollados
2.3.3.3.3. Interpretación semántica limitada
Dos empresas para poder intercambiar datos basados en XML, que necesitan llegar a un acuerdo explícitamente en la semántica del documento, como las definiciones de las etiquetas. Documento XML por sí misma no proporciona mucha información acerca de cómo interpretarla.
2.3.3.3.4. No facilita la transformación de datos
El problema central, ya sea en EAI o B2Bi para todas las empresas es la capacidad de transformar e integrar datos de una aplicación a otra. Sin embargo, el XML es más que otro formato de datos en la plétora de formatos utilizados por una empresa.
2.3.3.4. XML namespaces
Según el W3C, un espacio de nombres XML es una colección de nombres, identificados por un identificador uniforme de recursos (URI), que se utilizan en documentos XML como
tipos de elementos y nombres de atributos. Espacios de nombres XML calificar nombres de elementos en una forma reconocible para evitar conflictos entre los elementos con el mismo nombre. Los elementos contenidos en un documento XML se pueden definir de diferentes esquemas a través de Internet.
2.3.4. La coexistencia de XML y EDI
EDI ha ayudado a las empresas de los últimos años a simplificar y agilizar sus transacciones con clientes, proveedores y otros socios. Con la llegada de XML, el cual tiene el potencial de llegar a nuevos clientes comerciales y mercados y sirve como un lenguaje universal para todo tipo de transacciones, las empresas se enfrentan a preguntas difíciles. Si nos quedamos con el EDI? Si nos trasladamos a la evolución de la tecnología de XML? ¿Hay que tratar de conseguir EDI y XML para intemperante? ¿Los estándares de XML definidos para nuestra industria?
2.3.4.1. EDI basado en XML
XML / EDI es una evolución, no una revolución. XML y EDI son dos esencialmente los datos y metadatos encapsulados en formatos tokenizados y estructuras. Por lo tanto, las estructuras y métodos de EDI se puede expresar en sintaxis XML y viceversa (véase la Figura 6.4 y Figura 6.5). XML / EDI también una interfaz integrada con los sistemas EDI existentes y proporcionar el 100% de compatibilidad con versiones anteriores.
Por ejemplo, una empresa puede enviar un mensaje de EDI en un formato XML a un proveedor. El sistema del proveedor puede recoger el mensaje y mostrarlo en un navegador a la persona responsable de aprobar la entrada de pedidos de compra. Esa persona puede modificar la orden de compra de entrada, que en realidad señala su aprobación - esto podría ser por ejemplo una firma digital. La orden de compra aprobada puede ser enviado de vuelta a la aplicación del proveedor como un archivo sin formato EDI. De este modo, los mensajes legibles tanto humanos como máquina que se crean por un ser humano o una aplicación, puede viajar a través de una organización y puede ser enviado a otra organización y el interruptor entre los seres humanos y aplicaciones.
Cabe señalar que una de las objeciones a envolver un mensaje EDI en un formato XML es que un montón de gastos generales se crea en el mensaje.
2.3.4.2. Características de XML/EDI
Mensajes XML / EDI consiste en una fusión de etiquetas XML y EDI y datos.Pueden transmitirse a través de Internet, como puros mensajes XML o en la camioneta
como los mensajes EDI. Todos los navegadores web actuales que soportan XML también debe apoyar XML o mensajes EDI. Información de EDI en un mensaje de XML / EDI está explícitamente etiquetados con los nombres de etiquetas.
DTD que contienen la declaración de la estructura y los conjuntos correspondientes de los valores de código se puede hacer referencia a través de Internet.
XML / EDI es una fusión de muchos conceptos. XML / EDI:
• Utiliza el XML y XSL para el intercambio de datos y presentación, respectivamente;• Proporciona un estándar para documentos de formato;• Se puede integrar con los métodos tradicionales de intercambio electrónico de datos
(EDI)• Se puede utilizar con todos los mecanismos de transporte estándar de Internet, tales
como el encaminamiento IP, HTTP, FTP y SMTP;• Utiliza las herramientas modernas de programación tales como Java y ActiveX para
permitir que los datos sean compartidos entre los programas y• Utiliza tecnologías de agentes para la manipulación de datos, el análisis, mapeo y
búsqueda
2.3.4.3. Ventajas de XML / EDI sobre EDI tradicionales
• XML / EDI es más dinámico, menos costosa y más simple que el EDI tradicional. Reduce significativamente los costos de entrada para las empresas pequeñas y medianas empresas, que no pueden permitirse costosos basada en EDI de comunicación.
• Estándares XML reducir significativamente el número de socios comerciales específicas de los mapas necesarios.
• XML transforma tareas estáticas EDI como la gestión de inventario y planificación de la producción en los procesos dinámicos, mediante el uso de tiempo real, codificados en XML, la información obtenida directamente de los clientes y los proveedores de sistemas de negocio.
• XML / EDI no requiere grandes cambios en la capa de aplicación que se produce y consume los datos, ya que mantiene la estructura de información de EDI intacto. La transición de EDI a XML utilizando
XML / EDI se realiza más en las capas de transporte.• La arquitectura abierta de XML permite el apoyo de múltiples estándares.• XML / EDI a través de Internet ofrece a las empresas de comercio electrónico más
barato y más inteligente de mensajes a través de navegadores.• XML / EDI permite realizar búsquedas contextuales e inteligente a través de Internet,
ya que ajusta el texto no estructurado con datos estructurados en el mismo documento. Esta forma de etiquetado hace que las búsquedas sean muy eficientes y precisas.
2.3.4.4. Normas/estándares XML para e-business
En el mundo en expansión de comercio electrónico B2B, las empresas tienen que pensar de manera global. Sin el comercio electrónico mundial las normas no puede haber negocio sin fisuras entre las empresas repartidas por todo el mundo. Estas normas son un conjunto común de definiciones específicas de la industria que representan a los procesos de negocio.
Para los mensajes XML para ser interpretada por todas las empresas que participan en B2Bi que necesitan para ponerse de acuerdo sobre un común basado en XML B2B
Estándar, que va a definir los formatos de documentos, la información permitida y descripciones de procesos. Estas normas son como moneda común para la realización de negocios. Si las empresas utilizan la misma moneda para hacer negocios, entonces no hay necesidad de convertir una moneda en otra, sobre la base de tipo de cambio de hoy. De manera similar, la comunicación sobre la base de estas normas será aceptado y entendido por cualquier otra empresa que utiliza los mismos estándares.
La necesidad de que toda la industria (industrias verticales) B2B de comercio electrónico se está convirtiendo en normas cada vez más importante y evidente. Varias organizaciones han estado trabajando para definir estas definiciones de mercado del segmento específico. Normas tales como RosettaNet y OASIS están haciendo posible que las empresas a compartir información con otros sin tener que rediseñar por completo sus aplicaciones internas. Estas normas automatizar el flujo de información a través de todas las empresas de esa industria, independientemente del software de base o infraestructura de hardware apoyo a las actividades relacionadas con estas operaciones.
Algunos ejemplos de estándares XML B2B son:
• RosettaNet - una colección de protocolos de intercambio que definen los productos, los socios y las transacciones de negocio para los componentes electrónicos y la industria de tecnología de la información;
• Productos financieros (Lenguaje de marcado FpML) - un estándar para la industria financiera;
• Comercio Electrónico Markup Language (ebXML) - una iniciativa conjunta de las Naciones Unidas (UN / CEFACT) y OASIS, un conjunto de especificaciones de mensajes basados en XML que permiten a las empresas hacer negocios entre sí;
• Comercio de Lenguaje de marcado extensible (cXML) - un protocolo eficiente destinados a la comunicación constante de los documentos de negocios entre aplicaciones de adquisición, centros de comercio electrónico y proveedores, y
• BizTalk Framework - un conjunto de directrices para la aplicación de un esquema XML y un conjunto de etiquetas XML que se utilizan en los mensajes enviados entre aplicaciones.
2.3.4.4.1. Electronic Business XML (ebXML)
ebXML es un conjunto de especificaciones que juntas permiten una estructura modular, electrónica de negocios se ha completado. ebXML es un conjunto completo de especificaciones para ofrecer seguridad, negocio global, electrónica utilizando estándares probados, abiertos como TCP / IP, HTTP y XML. Se trata de una iniciativa conjunta de las Naciones Unidas (UN / CEFACT) y OASIS.
La realización de negocios electrónicos con ebXML es esencialmente un proceso de cuatro pasos.
1. Diseñar y registrar los procesos de negocio y modelos de información;
2. Implementar las interfaces de servicios empresariales y registro;3. Si lo desea negociar y definir un acuerdo de socio colaborador(CPA), y4. El intercambio de mensajes entre los socios de negocios. Las aplicaciones de
software de enviar y recibir mensajes ebXML que contienen los documentos de negocio ebXML, el seguro y confiable servicio de mensajería ebXML
4 pasos fáciles de ebXML
2.3.4.4.2. UBL XML
2.3.4.4.2.1. Oasis
OASIS, acrónimo de Organization for the Advancement of Structured Information Standards, es un consorcio internacional sin fines de lucro que orienta el desarrollo, la convergencia y la adopción de los estándares de comercio electrónico y servicios web.
Los miembros del consorcio deciden cómo y qué trabajo se realiza mediante un proceso abierto y democrático.
El trabajo técnico se lleva a cabo en las siguientes categorías: Web Services, e-Commerce, Security, Law & Government, Supply Chain, Computing Management, Application Focus, Document-Centric, XML Processing, Conformance/Interop, e Industry Domains.
2.3.4.4.2.2. UBL
Universal Business Language (UBL) es una librería estándar de documentos XML, diseñados para representar documentos empresariales tales como órdenes de venta o facturas. Ha sido desarrollada por un comité técnico de la organización OASIS, con la participación de varias organizaciones relacionadas con los estándares de datos en la industria. UBL está pensada para integrarse directamente en las prácticas empresariales, legales, auditoras o de gestión de registros actualmente vigentes.1 Y está diseñada para eliminar el trabajo de reteclear de nuevo datos que se da en los actuales sistemas empresariales de intercambio de documentos basados en fax o en papel. A la par que supone un punto de entrada al comercio electrónico para PYMES.2
La versión 2.0 de UBL fue aprobada como especificación de un comité de OASIS en octubre de 2006 y está públicamente disponible. Aún siendo propiedad de OASIS, puede ser usado libremente por cualquiera, sin ningún tipo de pago de royalties o contraprestación alguna por su uso. La librería de documentos empresariales de UBL es un completo lenguaje de marcado, disponiendo de herramientas de validación, de escritura, de procesado y de generación de dichos documentos.3
Los orígenes de UBL 2.0 se remontan a los estándares EDI y a otros estándares XML anteriores. En total están contemplados 31 documentos. Cubriendo prácticamente todas las necesidades empresariales en cuanto a procesamiento de ofertas, pedidos, ventas, facturación y pagos
2.3.4.4.2.2.1. ¿Cómo funciona el UBL?
UBL pertenece a la familia de lenguajes basados en XML, o Lenguaje Extensible de Marcado, que constituye un estándar para el intercambio electrónico de datos entre empresas e instituciones, así como en internet. En XML, a los elementos que componen los datos se les aplican etiquetas identificativas para que puedan ser procesados de forma eficiente por los programas informáticos.
UBL es una versión potente y flexible de XML definida específicamente para satisfacer las exigencias de la información comercial, financiera y empresarial. Permite aplicar etiquetas identificativas únicas a los distintos elementos que componen la información comercial, como, por ejemplo «importes netos». Sin embargo, estas etiquetas son algo más que meras etiquetas identificativas, pues proporcionan una amplia gama de información sobre dicho elemento, como, por ejemplo, si es monetario, porcentaje o fracción. UBL permite que se utilicen etiquetas en cualquier idioma, así como referencias contables u otra información complementaria.
UBL puede mostrar la relación que guarda un elemento con otro, por lo que puede representar cómo se calculan. Puede asimismo identificar, con fines de organización o de presentación, si pertenecen a algún grupo en concreto. Y más importante todavía, es fácilmente extensible, de modo que las empresas y otras organizaciones pueden adaptarlo para que satisfaga una diversidad de requisitos especiales.
La estructura de UBL permite gestionar de manera eficiente los datos de la empresa a través de programas informáticos. Permite la realización de todas las tareas estándar que conllevan la compilación, el almacenamiento y la utilización de los datos de empresa La citada información puede convertirse en UBL mediante procesos de mapeo (mapping) adecuados o generarse en UBL a través de programas informáticos. Luego, se puede buscar, seleccionar, intercambiar o analizar la información, o publicarla para una visualización normal.
UBL 1.0 se lanzó como estándar de OASIS (una organización sin fines de lucro dedicada al desarrollo abierto de estándares públicos de XML) el 8 de noviembre de 2004 tras tres años de desarrollo y de revisión pública. UBL 2.0, que amplía ampliamente el alcance de UBL, se aprobó como especificación del comité del OASIS en octubre de 2006 y se ha sometido a OASIS para su ratificación como estándar de OASIS, lo que se produjo en diciembre de 2006.
UBL supone un enfoque claramente centrado en el documento del comercio electrónico que se focaliza en estandarizar los datos de negocio de forma que encajen en los documentos en papel tradicionales. El estándar internacional principal para los formularios en papel de los documentos tradicionales es el UN Layout Key de la O.N.U, que durante más de 40 años ha servido como modelo para los documentos de papel usados en comercio internacional.
2.3.4.4.2.2.2. ¿Cómo se ha implementado UBL a nivel mundial?
Desde febrero de 2005, la factura UBL se ha impuesto por ley para todo el sector público en Dinamarca. Cada mes, se intercambian en Dinamarca 1.2 millones de facturas UBL. El ministerio danés de finanzas ahorra para el estado alrededor de 200 millones de euros anuales por el uso de este tipo de documento. La adopción de UBL afecta 440 mil empresas en Dinamarca y ahora está en el proceso de imponer a las empresas suministradoras de software empresarial del norte de Europa la capacidad de dar soporte técnico a la implantación de este estándar
Desde octubre de 2005, la “Swed-invoice” (un subconjunto del mensaje de factura UBL adaptado al mercado sueco) se ha recomendado para cualquier uso en las administraciones públicas por la Autoridad de Gestión Financiera Nacional Sueca (Swedish National Financial Management Authority). La NFMA estima que la estandarización de factura UBL ahorrará el gobierno sueco 4 mil millones de SEK, coronas suecas (más de 500 millones de dólares) en los primeros cinco años del despliegue.
En el Reino Unido, el sistema de gestión de mercado (marketplace) “Zanzibar”, creado por la oficina británica de soluciones de contratación pública (UK Office of Government Buying Solutions), se lanzó en febrero de 2006 con 14 documentos UBL 2.0.
El proyecto de Gestión Electrónica de Carga (Electronic Freight Management, EFM) del Departamento de Transporte de E.E.U.U. (U.S. Department of Transportation) está experimentando actualmente con los mensajes UBL Despatch Advice (Aviso de Expedición) and Bill of Lading (Conocimiento de Embarque). Este proyecto experimental enlaza dos fabricantes chinos de ropa, dos transitarios, un operador de terminal de fletes aéreos, dos transportistas aéreos, un comprador norteamericano de ropa, un intermediario logístico (3PL, third-party logistics) y un corredor de importación en una demostración compleja de comercio electrónico avanzado ajustado al mundo real.
2.4. Seguridad en Internet
2.4.1. Seguridad en Internet crítica para el B2B
El Internet ha revolucionado las formas en que las empresas hacen negocios.El comercio electrónico B2B es sin duda eficaz, barata y flexible. Sin embargo, es vulnerable a
una serie de riesgos de seguridad. Como el comercio electrónico B2B se hace más generalizada, la seguridad tiende a ser crítica en el logro de la comunicación perfecta entre los socios comerciales. No es sólo un requisito, pero en realidad la base sobre la que B2Bi se construirán.
La información registrada electrónicamente y está disponible en equipos en red es más propensas al riesgo que si la misma información que se imprime en papel y bajo llave en un armario. Los intrusos no necesita estar físicamente presente en ese lugar e incluso pueden no estar en el mismo país o continente. En silencio se puede robar o manipular archivos electrónicos y ocultar la evidencia de su actividad no autorizada.
Un estudio reciente sobre la seguridad en Internet, llevada a cabo por el Grupo de Datamonitor, ha encontrado que las empresas tienen una conciencia muy bajo de la necesidad de la seguridad electrónica. Más del 50 por ciento de las empresas invierten un 5% o menos de su presupuesto de TI en la tecnología de seguridad, con sólo un gasto de sólo un 10% más del 20% de su presupuesto de TI en materia de seguridad. Por lo tanto, el hecho es que muchas empresas sufren una pérdida importante debido a la falta de seguridad.
Descuidar las medidas de seguridad adecuadas en aplicaciones B2Bi, lo cual expone la red de una empresa para clientes y socios, pueden aterrizar una compañía en agua caliente. En un entorno B2Bi, incluso los errores simples pueden conducir a la pérdida de datos que ningún otro socio comercial cada vez se toleran. Consideremos un escenario en el que un error o una mala configuración en los sistemas de una empresa hace que los acuerdos de fijación de precios o confidenciales
Catálogo de datos personalizados enviados por un proveedor a filtrarse. Otros clientes del proveedor podrán hacer una denuncia, poniendo fin a sus relaciones comerciales con el proveedor en conjunto. La compañía errante puede tener que soportar la responsabilidad y hacer la diferencia en las ventas.
Por lo tanto, una compañía de participar en B2Bi tiene que convencer a sus socios comerciales que se puede confiar en sus datos. Se tiene que detectar de forma continua, corregir y eliminar los riesgos para sistemas de misión crítica y datos B2B. De hecho, los controles de seguridad y la privacidad se están convirtiendo en obligatorio antes de acceder a la participación en grandes implementaciones B2Bi.
2.4.2. Estrategia E-Security
Estrategia E-Security debe ser una parte integral de la estrategia general de la empresa B2Bi. Si una empresa quiere participar en B2Bi, tendrá que renunciar a la vieja estrategia de ocultar por completo los datos si no pueden ser protegidos. La nueva estrategia prevé la aplicación de una solución de seguridad que permite a las empresas para ofrecer seguros de soluciones e-business y la
gestión de acceso personalizado por controlar el acceso a aplicaciones, recursos y datos. Hay que darles la posibilidad de ampliar sus sistemas internos a sus socios comerciales de forma rápida y sencilla, sin comprometer la seguridad o el rendimiento, incorporar el derecho de selección, configuración y uso de productos de seguridad y su integración con los sistemas heredados, y establecer políticas de seguridad dinámicas. Como parte de su estrategia de seguridad electrónica, las empresas deben:
• Determinar los activos críticos tales como las redes corporativas, dispositivos, aplicaciones y datos;
• Evaluar las posibles amenazas de seguridad en el entorno B2B;• Asegure los activos por parte de una selección apropiada y el despliegue de una solución de
garantía real, que ofrece un alto retorno de la inversión, mientras que la ampliación de sus necesidades de seguridad, y
• Desarrolle la solución de seguridad por revisar constantemente el entorno empresarial, los objetivos B2Bi, las amenazas actuales y los últimos cambios tecnológicos.
2.4.3. Servicios básicos de seguridad en B2Bi
E-seguridad, a la luz de B2Bi, se trata de proteger una empresa, al tiempo que amplía la información de negocio y datos a las aplicaciones de toda la empresa y de los sistemas. En B2Bi, la atención se centra en la construcción de relaciones de confianza con los socios comerciales, y la importancia de mantener esta confianza no puede ser sobre-enfatizada. Cada vez que se lleva a cabo la comunicación de datos entre diferentes empresas, hay algunos riesgos involucrados.
Las principales preocupaciones son las siguientes:• Alguien puede interceptar el mensaje y en la violación de su privacidad;• Alguien puede hacerse pasar por una empresa y enviar un mensaje con su nombre y firma;• Una persona puede cambiar el contenido del mensaje en tránsito, y• La empresa que envía podrá, posteriormente, negar que ha enviado el mensaje.
Para reducir estos riesgos, los siguientes servicios de seguridad se debe garantizar durante la comunicación B2B:
• Confidencialidad - La garantía de que el mensaje es privado y sus contenidos no han sido revelados al mundo exterior;
• Autenticación - prueba de que el mensaje ha sido enviado realmente por la compañía con la cual la comunicación se llevaba a cabo;
• Integridad - completa seguridad de que el mensaje no ha sido manipulado o alterado por accidente durante el transporte, y
• No repudio - el mensaje debe ser vinculante para la empresa que envía de manera que no puede negar que lo envió en un momento posterior.
El fracaso en asegurar ninguna de las características anteriores dará lugar a toda la transacción se vea comprometida y en última instancia socavar la confianza de las empresas y los consumidores en la tecnología B2Bi.
2.4.4. Conceptos clave en las soluciones de e-Seguridad
Algunas de las tecnologías clave que han surgido como el fundamento de la seguridad electrónica son: la criptografía, firmas digitales y certificados y servidores de seguridad.
En esta sección, vamos a echar un vistazo más de cerca a estas tecnologías y comprender el papel desempeñado por cada uno en la creación de un entorno seguro para la empresa.
2.4.4.1. Criptografía
Criptografía, también llamado cifrado, protege la privacidad de la información que se transmite a través de Internet. Asegura que la información no es inteligible si se cae en las manos equivocadas. Mientras que la criptografía ha estado en existencia desde tiempos remotos, su nivel de sofisticación ha aumentado, en consonancia con el aumento de los riesgos.
La criptografía actual utiliza sofisticadas fórmulas matemáticas y algoritmos informáticos.
Los principales elementos de la criptografía son:• Texto original - el contenido exacto del mensaje;• Cifrado de texto - la forma en que el mensaje aparece después de estar encriptado.
Esto no es humanamente legible;• Algoritmo de cifrado - el algoritmo o fórmula matemática utilizada para convertir el
mensaje original en texto cifrado, y• Key - el elemento utilizado para cifrar y descifrar el mensaje. Cada algoritmo de cifrado
hace uso de una clave. Dependiendo de la clave utilizada, el mismo algoritmo producirá texto cifrado diferente para el mismo contenido del mensaje.
La encriptación se hace para asegurar no sólo texto, sino también de vídeo, sonido, etc - cualquier forma de comunicación a través de Internet.
2.4.4.2. Cifrado de clave privada
Cifrado de clave privada, también llamado cifrado simétrico, era la forma más sencilla de los mensajes cifrados se enviaron en los primeros tiempos. Se utiliza el mismo código único llamado sola llave o clave privada para cifrar y descifrar los mensajes.
Consideremos un escenario en el que la empresa A quiere enviar a la empresa B un mensaje secreto (ver figura). Si una clave privada solo se utiliza,
• Una empresa informa a la empresa B sobre su clave privada.• Una empresa cifra el mensaje con su clave privada y envía el mensaje.• La empresa B hace uso de la clave privada (enviados a través de versiones anteriores)
para descifrar el mensaje
Encriptación con clave privada
2.4.4.3. Cifrado de clave pública
Para superar los inconvenientes de cifrado de clave privada, un nuevo algoritmo, denominado cifrado de clave pública, fue inventada por Whitfield Diffie y Martin Hellman en 1976.
Cifrado de clave pública o asimétrica de cifrado usa dos claves:• Uno se llama la clave privada, que está en manos de un solo partido, y• La otra se llama la clave pública, que está disponible con el mundo exterior.Estas claves se complementan entre sí como una cerradura mecánica y llave.El mensaje se encripta con la clave pública y puede ser desbloqueado o descifrar sólo
con la clave privada. Cualquier empresa, como la empresa A, con el deseo de comunicarse con la empresa B puede cifrar el mensaje con la clave pública de la empresa B y enviarlo a través (véase Figura 10.3). Por lo tanto, las dos compañías no tienen que ponerse de acuerdo sobre una clave de antemano. Dado que el descifrado sólo puede hacerse con la clave privada, que sólo se conoce a la empresa B, incluso si el mensaje es interceptado, el interceptor no será capaz de comprender el mensaje. Así, el mensaje permanece siempre protegida mediante el cifrado de clave pública.
2.4.4.4. La firma digital
La firma digital es el equivalente electrónico de una firma de lápiz y papel y se utiliza para la autenticación del remitente del mensaje. Se proporciona un medio por el cual la información no puede ser repudiada por la comunicación obligatoria a la persona que lo firmó. También garantiza que el mensaje no fue modificado desde que dejó el remitente. Las firmas digitales se basan en sistemas de clave pública.
2.4.4.4.1. Creación de una firma digital
Una firma digital se crea típicamente usando lo que se conoce como una función de dispersión. Una función hash es un algoritmo que los valores de los mapas de un dominio de gran tamaño en un rango mucho menor. En otras palabras, si tenemos un mensaje típico, que consiste en muchos miles de bits, el algoritmo de control puede producir un 'resumen' de la misma, lo que sería un centenar de bits de longitud. Además, sería garantizar que, incluso si un poco se cambia en el mensaje, el digesto producido sería diferente. Este "resumen del mensaje 'se cifra mediante la clave privada del emisor (por lo general de cifrado RSA) y el resultado se denomina firma digital (ver Figura).
La firma digital se adjunta en el fichero de mensaje y el mensaje combinado se encriptado con la clave pública del receptor.
Cuando el receptor recibe el mensaje, realiza las siguientes acciones:1. Se descifra el mensaje utilizando su clave privada (ver Figura). Ahora lo que ve es la
firma digital y el archivo de mensaje original.2. Se re-calcula el 'resumen' del archivo original, usando el mismo algoritmo hash.3. Se descifra la firma digital utilizando la clave pública del remitente.4. A continuación, compara la firma digital descifrado con el resumen que se acaba de
calcular.
5. Si los dos son exactamente lo mismo, el receptor se asegura que el mensaje no fue modificado en el camino y también que la identidad del remitente se demuestra (como la clave privada del emisor estuvo involucrado en el proceso; (ver Figura)
Des encriptación con firma digital
Asegurando integridad del mensaje
Códigos de autenticación de mensajes (llamado MAC) es otro mecanismo para la identificación de los usuarios. Un MAC es una etiqueta de autenticación (también llamado una suma de comprobación) derivado mediante la aplicación de un esquema de autenticación, junto con una clave secreta, a un mensaje. Sin embargo, no es infalible, como el receptor también puede generar estos códigos y mal uso de ellos.
2.4.4.5. Los certificados digitales y el papel de autoridades de certificación (CA)
Todos los mecanismos anteriores de seguridad basados en el uso de claves públicas y claves privadas, tanto para el emisor y el receptor. La pregunta que surge - ¿dónde éstas claves vienen? ¿De qué manera el mundo exterior apoderarse de la clave pública de una organización en particular?
La respuesta está en los certificados digitales emitidos por organizaciones llamadas Autoridades de Certificación (CA). Los certificados pueden ser utilizados para reemplazar pasar de las palabras y el ID de inicio de sesión es allí donde el acceso ha sido restringido a determinados usuarios, como los clientes registrados. En varias aplicaciones, podrá sustituir a los certificados de 'cookies', que han resultado impopulares entre los muchos usuarios de la Web.
Cualquier empresa / persona que desee comunicarse de forma segura a través de Internet se puede aplicar a una entidad emisora de un certificado digital. Tiene que enviar su información de identificación y la clave pública a la CA. La CA verificará la autenticidad de la información y luego emitir un certificado con la información dada y la clave pública. Para sellar el certificado, la CA lo cifra con su clave privada y la envía al solicitante (véase la figura).
Certificado público simple
En este enfoque, cuando la empresa A quiere comunicarse con la Compañía B, se le pedirá la Compañía B por su certificado. Al recibir este certificado, la empresa A descifrar la voluntad de la misma utilizando la clave pública de la CA.
A continuación, lea la información de identificación en el certificado. Si satisfecho, se utilizará la clave pública presente en el certificado para enviar a través de la información a la empresa B.
Esta metodología no sólo es seguro, pero requiere que el remitente sólo conoce la clave pública del CA, en vez de recordar la clave pública de todos los partidos que desea comunicarse.
El más reconocido estándar de formato de certificado de clave pública se define en el estándar ITU X.509.
Hay múltiples organizaciones que funcionan como entidades de certificación. Líder entre ellos es VeriSign (http://www.verisign.com), que abastece a las instituciones, así como individuos. Se emite el siguiente:
• E-mail Certificado - verifica que el correo electrónico proviene de la dirección mencionada;
• Servidor de certificados - establece la identidad de un sitio de Internet en particular, y
• Código de firma de certificado - utilizada por las empresas de software para firmar las versiones publicadas de su código.
2.5. Componentes de Integración
2.5.1. Los componentes y las operaciones de la arquitectura SOA
Hay tres componentes de la arquitectura orientada a servicios• Proveedor de servicios - Este componente es responsable de la creación y publicación
de las interfaces de los servicios, ofreciendo la actual implementación de estos servicios y responder a toda solicitud para la utilización de los mismos. Cualquier empresa o negocio puede ser un proveedor de servicios.
• Service Broker - Este componente registra y clasifica los servicios públicos publicados por diversos proveedores de servicios y ofrece servicios como la búsqueda, los agentes de servicio, etc. actuar como un repositorio o las páginas amarillas para los servicios Web. Las empresas que deseen utilizar los servicios Web pueden buscar en estas páginas amarillas para encontrar uno que coincida con sus necesidades. En la actualidad varias empresas con clientes como Ariba, IBM y Microsoft están actuando como agentes de servicio.
• Solicitante del servicio - Este componente es el usuario real de los servicios Web. Los solicitantes de servicios descubrir servicios Web mediante la búsqueda del repositorio mantenido por los corredores de servicio y luego llamar a estos servicios mediante la comunicación con los proveedores de servicios reales. En la mayoría de los casos, la invocación sería remoto a través de Internet, pero también es posible que la invocación del servicio es local a través de la intranet, lo que significa que la empresa solicitante es también el proveedor de servicios.
Las tres operaciones más básicas a través del cual los participantes interactúan SOA son los siguientes:
• Publicar - Permite que el proveedor de servicios para publicar sus servicios y requisitos de la interfaz con un agente de servicio. WSDL (Web Services Description Language) es un lenguaje basado en XML utilizado para realizar la operación de describir la interfaz de servicios Web que luego son publicados con UDDI.
• Buscar - Esta operación permite a un solicitante del servicio para localizar, buscar y descubrir los servicios publicados a través de un corredor de servicios que se ofrecen en una clasificación particular o por un prestador de servicios específico.
Encontrar está habilitada por el UDDI (Universal Description, Discovery and Integration) marco.
• Enlazar - Esta operación permite a un solicitante del servicio para vincular realidad y utilizar un servicio proporcionado por un proveedor de servicios. La vinculación es activada por mensajes basados en SOAP XML
2.5.2. Servicios Web (Web Services)
Los servicios Web son URL-direccionables, autónomos recursos y / o aplicaciones que pueden ser descritas, publicadas, que se encuentra y se invoca en una red, generalmente Internet. Los servicios Web son representaciones XML de aplicaciones, recursos, mensajes y objetos que permiten la aplicación a aplicación ver la interacción de Internet. Ofrecen interfaces bien definidos, llamados contratos, que describen los servicios prestados. Los servicios Web se basan en la arquitectura orientada a servicios (SOA) y se unen de apoyo, publicar y las operaciones de búsqueda. Cada componente (nodo de red) puede jugar cualquiera o todas las funciones de un agente de servicio, solicitante del servicio o proveedor de servicios.
Los servicios Web permiten a las empresas a publicar sus interfaces públicas de objetos de negocio y programas para que otras empresas puedan buscar y encontrar e interactuar con estos servicios.
En el centro de servicios Web es el hecho de que cada servicio encapsula los detalles de ejecución y publica una API de mensajería, de modo que pueda ser utilizado por otros servicios sobre la red. Los servicios web tienen todas las características de sistemas orientados a objetos, tales como la encapsulación, paso de mensajes, la descripción dinámica de unión y de servicio y consulta. A través de la asignación dinámica de los componentes, que es la plataforma y lenguaje de programación neutral y las comunicaciones mecanismo independiente-, que permiten justo a tiempo de integración de aplicaciones.
Los servicios Web permiten aprovechar plenamente la infraestructura y las aplicaciones existentes. Las aplicaciones web existentes (Internet / Intranet) pueden ser fácilmente convertidos en servicios Web, con independencia de la plataforma o el lenguaje de programación utilizado para implementar estas aplicaciones.
2.5.2.1. Características esenciales de un entorno de servicios Web
Hay varias características esenciales para el funcionamiento de los servicios Web.El entorno de servicios Web proporciona un marco que ofrece la posibilidad de descubrir de
forma dinámica, instalar y volver a utilizar los servicios empresariales.Un servicio web tiene que ser:• Creado y sus interfaces y los métodos de invocación debe ser definido;• Publicación de una o más de intranet o repositorios de Internet para los usuarios potenciales
para localizar;• Situado al ser invocados por los usuarios potenciales;• Se invoca por otros servicios Web, aplicaciones;• Facilitar el acceso a las funciones de la biblioteca estándar de seguridad, tales como búsqueda,
traducción, la tala y las transacciones;• No publicado, cuando ya no está disponible o cuando sea necesario, y• Integración con otros servicios web utilizando los estándares de Internet.
Como se mencionó, los servicios Web implican el intercambio de mensajes XML.Es obligatorio para los servicios Web para asociar esquemas XML (que definen los tipos de datos,
los requisitos de los documentos XML que se utilizan para los mensajes, los tipos de mensajes y las
operaciones de los mensajes se asignan a) con estos mensajes XML. Los servicios Web se pueden implementar en cualquier lenguaje (como C, Java y C + +) utilizando cualquier tecnología como EJB y CORBA, siempre y cuando sean capaces de generar y analizar los documentos XML.
2.5.2.2. Universal Description, Discovery and Integration (UDDI)
UDDI es un registro de negocios centralizada que permite a las empresas a empresa de comunicación. UDDI es una forma estándar de hacer frente a la necesidad de un depósito o un corredor que se gestionará una base de interfaces de servicios.
IBM, Microsoft y Ariba se indica su especificación para ayudar a facilitar la creación, descripción, descubrimiento e integración de servicios basados en Web.
Un registro UDDI tiene, básicamente, dos tipos de usuarios:• Las empresas que publican un servicio y su interfaz basada en XML de uso, y• Los clientes que deseen utilizar estos servicios al unirse a ellos. Todas las empresas que se
inscriban en el registro de empresas UDDI se les asigna un identificador único global.
2.5.2.3. Web Services Description Language (WSDL)
WSDL es un lenguaje XML que describe un servicio Web, especifique su ubicación, se describen las operaciones (es decir, métodos) que expone, se definen los mensajes XML que genera y los intercambios y los detalles del enlace.
WSDL es un formato para describir los servicios de red XML en términos de los criterios de valoración ', que son una manera de solicitar XML relacionados con la funcionalidad de un ordenador remoto a través de una red como Internet. Se estandariza el formato de la publicación de las operaciones de un servicio con sus respectivos parámetros y tipos de datos, la definición de la ubicación y detalles del enlace del servicio.
La sintaxis de WSDL permite tanto a los mensajes y las operaciones sobre los mensajes que se definen de manera abstracta, por lo que se puede asignar a múltiples implementaciones físicas, tales como SOAP, HTTP y MIME.
WSDL es independiente del protocolo subyacente y los requisitos de codificación, lo que permite dinámica transversal plataforma de integración.
2.5.2.4. WSDL schema
Un esquema XML de WSDL (según lo definido por IBM y Microsoft) incluye las siguientes partes:• Tipos - Un contenedor para los diferentes tipos de datos contenidos en el mensaje, que puede
ser en forma de esquemas XML o algún sistema tipo (como XSD);• Mensaje - una descripción abstracta de los datos que se intercambian que se puede presentar
como documentos de pleno derecho o como argumentos asignados a una invocación de operación;• Funcionamiento - una definición abstracta de una acción (como un proceso de negocio) con el
apoyo de un servicio Web;
• Tipo de puerto - una colección abstracta de las operaciones que se asignan a uno o más extremos, lo que permite las operaciones que se asignan a uno o varios protocolos de transporte;
• Encuadernación - utilizado para fijar un protocolo concreto y especificación de formato de datos para un tipo de puerto;
• Puerto - un punto final definido como una combinación de obligar a una dirección de red, que proporciona la dirección de destino del servicio de comunicación, y
• Servicio - una colección de extremos relacionados con el que se asignan la unión del puerto y incluye ninguna definición de la extensibilidad.
2.5.2.5. WSDL y UDDI
WSDL complementa el estándar UDDI, proporcionando una manera uniforme de describir los enlaces de la interfaz y el protocolo de servicios de red.
De acuerdo con las especificaciones técnicas puestas a disposición por parte de IBM y Microsoft, UDDI los servicios basados en Web pueden ser creadas usando WSDL por los siguientes pasos:
1. Creación de la definición WSDL interfaz de servicio. Por lo general, los grupos industriales se definen un conjunto de tipos de servicios, y las describen con uno o más servicios de interfaz de documentos de definición WSDL. La definición de interfaz de servicio incluye las interfaces de servicios y enlaces de protocolo y se pondrá a disposición del público. Las definiciones de interfaz WSDL de servicio son luego registrados como tModels UDDI; el campo overviewDoc en cada estructura tModel nuevo punto en el correspondiente documento WSDL.
2. Crear servicios que se ajustan a las definiciones de los servicios estándar de la industria.Para ello, recuperar la descripción de la estructura tModel la definición estándar de la industria y
(siguiendo el enlace overviewDoc) obtener el correspondiente documento WSDL definición.3. Implementar y registrar el nuevo servicio en el repositorio UDDI. Para ello, crear una
estructura de datos de UDDI BusinessService y luego registrarlo.
2.5.2.6. Poniendo todo junto
Después de haber discutido todos los componentes de servicios Web, vamos a tratar de definir. Un servicio Web es una aplicación modular que puede ser:
• Se describe utilizando WSDL;• Publicado con UDDI;• Se encuentra con UDDI;• Limitado por SOAP (o HTTP GET / POST);• Invocado utilizando SOAP (o HTTP GET / POST), y• Compuesto con otros servicios en nuevos servicios utilizando WSFL.La figura muestra un ejemplo de uso real de los servicios Web en una aplicación de B2B, donde
un comprador recibe información acerca de los servicios web de proveedores que utilizan privada registro UDDI y llama a estos servicios a través de Internet para obtener las cotizaciones de un elemento específico.
Ejemplo de servicios web en aplicaciones B2B
2.6. SUNAT
2.6.1. ¿Qué es la SUNAT?
La Superintendencia Nacional de Aduanas y de Administración Tributaria – SUNAT, de acuerdo a su Ley de creación N° 24829, Ley General aprobada por Decreto Legislativo Nº 501 y la Ley 29816 de Fortalecimiento de la SUNAT, es un organismo técnico especializado, adscrito al Ministerio de Economía y Finanzas, cuenta con personería jurídica de derecho público, con patrimonio propio y goza de autonomía funcional, técnica, económica, financiera, presupuestal y administrativa que, en virtud a lo dispuesto por el Decreto Supremo N° 061-2002-PCM, expedido al amparo de lo establecido en el numeral 13.1 del artículo 13° de la Ley N° 27658, ha absorbido a la Superintendencia Nacional de Aduanas, asumiendo las funciones, facultades y atribuciones que por ley, correspondían a esta entidad.
Tiene domicilio legal y sede principal en la ciudad de Lima, pudiendo establecer dependencias en cualquier lugar del territorio nacional.
2.6.2. Funciones y atribuciones de la SUNAT
Son funciones y atribuciones de la Superintendencia Nacional de Aduanas y de Administración Tributaria:
Administrar, recaudar y fiscalizar los tributos internos del Gobierno Nacional, con excepción de los municipales, así como las aportaciones al Seguro Social de Salud (ESSALUD) y a la Oficina de Normalización Previsional (ONP), y otros cuya recaudación se le encargue de acuerdo a ley.
Proponer al Ministerio de Economía y Finanzas la reglamentación de las normas tributarias y aduaneras. Expedir, dentro del ámbito de su competencia, disposiciones en materia tributaria y aduanera,
estableciendo obligaciones de los contribuyentes, responsables y/o usuarios del servicio aduanero, disponer medidas que conduzcan a la simplificación de los regímenes y trámites aduaneros, así como normar los procedimientos que se deriven de éstos.
Sistematizar y ordenar la legislación e información estadística de comercio exterior, a fin de brindar información general sobre la materia conforme a Ley, así como la vinculada con los tributos internos y aduaneros que administra.
Proponer al Poder Ejecutivo los lineamientos tributarios para la celebración de acuerdos y convenios internacionales, así como emitir opinión cuando ésta le sea requerida.
Celebrar acuerdos y convenios de cooperación técnica y administrativa en materia de su competencia. Promover, coordinar y ejecutar actividades de cooperación técnica, de investigación, de capacitación y
perfeccionamiento en materia tributaria y aduanera, en el país o en el extranjero. Otorgar el aplazamiento y/o fraccionamiento para el pago de la deuda tributaria o aduanera, de acuerdo
con la Ley. Solicitar, y de ser el caso ejecutar, medidas destinadas a cautelar la percepción de los tributos que
administra y disponer la suspensión de las mismas cuando corresponda. Controlar y fiscalizar el tráfico de mercancías, cualquiera sea su origen y naturaleza a nivel nacional. Inspeccionar, fiscalizar y controlar las agencias de aduanas, despachadores oficiales, depósitos
autorizados, almacenes fiscales, terminales de almacenamiento, consignatarios y medios de transporte utilizados en el tráfico internacional de personas, mercancías u otros.
Prevenir, perseguir y denunciar al contrabando, la defraudación de rentas de aduanas, la defraudación tributaria, el tráfico ilícito de mercancías, así como aplicar medidas en resguardo del interés fiscal.
Desarrollar y aplicar sistemas de verificación y control de calidad, cantidad, especie, clase y valor de las mercancías, excepto las que estén en tránsito y transbordo, a efectos de determinar su clasificación en la nomenclatura arancelaria y los derechos que le son aplicables.
Desarrollar y administrar los sistemas de análisis y fiscalización de los valores declarados por los usuarios del servicio aduanero.
Resolver asuntos contenciosos y no contenciosos y, en este sentido, resolver en vía administrativa los recursos interpuestos por los contribuyentes o responsables; conceder los recursos de apelación y dar cumplimiento a las Resoluciones del Tribunal Fiscal, y en su caso a las del Poder Judicial.
Sancionar a quienes contravengan las disposiciones legales y administrativas de carácter tributario y aduanero, con arreglo a Ley.
Ejercer los actos y medidas de coerción necesarios para el cobro de deudas por los conceptos indicados en el inciso precedente.
Mantener en custodia los bienes incautados, embargados o comisados, efectuando el remate de los mismos cuando ello proceda en el ejercicio de sus funciones.
Adjudicar directamente, como modalidad excepcional de disposición de mercancías, aquellas que se encuentren en abandono legal y en comiso administrativo. La adjudicación se hará a las entidades estatales y a aquellas a las que oficialmente se les reconozca fines asistenciales o educacionales, sin fines de lucro.
Desarrollar programas de información, divulgación y capacitación en materia tributaria y aduanera. Editar, reproducir y publicar oficialmente el Arancel Nacional de Aduanas actualizado, los tratados y
convenios de carácter aduanero, así como las normas y procedimientos aduaneros para su utilización general.
Determinar la correcta aplicación y recaudación de los tributos aduaneros y de otros cuya recaudación se le encargue de acuerdo a ley, así como de los derechos que cobre por los servicios que presta.
Participar en la celebración de Convenios y Tratados Internacionales que afecten a la actividad aduanera nacional y colaborar con los Organismos Internacionales de carácter aduanero.
Crear, dentro de su competencia, administraciones aduaneras y puestos de control, así como autorizar su organización, funcionamiento, suspensión, fusión, traslado o desactivación cuando las necesidades del servicio así lo requiera.
Ejercer las demás funciones que sean compatibles con la finalidad de la Superintendencia Nacional de Aduanas y de Administración Tributaria.La Superintendencia Nacional de Aduanas y de Administración Tributaria (SUNAT) ejercerá las funciones
antes señaladas respecto de las aportaciones al Seguro Social de Salud (ESSALUD) y a la Oficina de Normalización Previsional (ONP), a las que hace referencia la Norma II del Título Preliminar del Texto Único Ordenado del Código Tributario, aprobado por el Decreto Supremo Nº 135-99-EF.
La SUNAT también podrá ejercer facultades de administración respecto de otras obligaciones no tributarias de ESSALUD y de la ONP, de acuerdo a lo que se establezca en los convenios interinstitucionales correspondientes.
2.6.3. Comprobantes de Pago - Concepto
El comprobante de pago es el documento que acredita la transferencia de bienes, la entrega en uso o la prestación de servicios.Para ser considerado como tal debe ser emitido y/o impreso conforme a las normas del Reglamento de Comprobantes de Pago.
Base LegalArtículo 1° de la Resolución de Superintendencia N° 007-99/SUNATResolución de Superintendencia N° 182-2008/SUNAT Resolución de Superintendencia N° 188-2010/SUNAT
2.6.3.1. ¿Qué tipos de Comprobante de Pago existen?
Existen distintos tipos de comprobantes de pago, dependiendo de la actividad u operación que usted realice. A continuación veamos algunos de estos tipos:
2.6.3.1.1. Factura
Es el comprobante de pago que se emite en las operaciones entre empresas o personas que necesitan acreditar costo o gasto para efecto tributario, sustentar el pago del IGV por la operación efectuada y poder ejercer, de esta manera, el derecho al crédito fiscal. Por ejemplo, cuando una empresa compra papel y tóner para sus impresoras debe exigir que le otorguen una factura.
2.6.3.1.2. Boleta de venta
Es un comprobante de pago que se emite en operaciones con consumidores o usuarios finales. No permite ejercer el derecho al crédito fiscal, ni sustentar gasto o costo para efecto tributario.
Por ejemplo: Si usted compra los víveres para la semana en una tienda de abarrotes, debe exigir que le otorguen una boleta de venta. Lo mismo si acude a una peluquería o salón de belleza, o va a comer a un restaurante o compra un libro.
Cuando el importe de la venta efectuada o del servicio prestado supere los setecientos nuevos soles (S/. 700.00) por operación será necesario consignar en la boleta de venta los datos de identificación
del adquirente o usuario: apellidos y nombres completos, y el número de su documento de identidad.
2.6.3.2. Autorización de comprobantes de pago
2.6.3.2.1. Comprobantes de Pago emitidos de manera electrónica
Los comprobantes de pago que pueden emitirse de manera electrónica son Recibos por Honorarios Electrónicos, Facturas Electrónicas, Notas de Crédito Electrónicas y Notas de Débito Electrónica. Previamente deberá afiliarse al Sistema de Emisión Electrónica ingresando a SUNAT Operaciones en Línea - SOL en SUNAT Virtual con su clave SOL. Para acceder a este sistema de emisión tenga en cuenta que:
Su domicilio fiscal debe tener la condición de “Habido”.No debe hallarse en el estado de Suspensión Temporal de Actividades o Baja de
Inscripción.Debe estar afecto en el RUC al Impuesto a la Renta de Tercera o Cuarta Categoría, según
corresponda.Para el caso de los que emitan factura electrónica, deben adicionalmente encontrarse
acogidos al Régimen Especial del Impuesto a la Renta (RER) o al Régimen General.Para emitir sus comprobantes solo debe ingresar a SUNAT Virtual, seleccionar SUNAT
Operaciones en Línea, ingresar su Clave SOL e ingresar al módulo "Sistema de Emisión Electrónica SEE" opción: Emisión de Documentos Electrónicos.
2.6.3.2.2. Comprobantes de Pago emitidos de manera impresa
Las Facturas, Boletas de Venta, Liquidaciones de Compra, Recibos por Honorarios, Notas de Crédito, Notas de Débito, Guías de Remisión, Boletos de Viaje, entre otros, son algunos de los comprobantes de pago y/o documentos que pueden emitirse de manera impresa.
2.6.3.3. Factura Electrónica desde los Sistemas del Contribuyente
A diferencia de la solución implementada en el portal, donde la emisión electrónica se realiza a través del Portal de la SUNAT, en este sistema realiza la emisión electrónica desde los sistemas del contribuyente.
El sistema permite emitir en forma electrónica: facturas, boletas de venta, notas de crédito y notas de débito.
Notas importantes:Los contribuyentes autorizados a emitir en forma electrónica sus comprobantes de pago, podrán
seguir emitiendo comprobantes en forma física.Los contribuyentes que emitían tickets y sean autorizados a emitir en forma electrónica, en lugar
de tickets, deben emitir boletas y/o facturas electrónicas. En el mundo electrónico, ya no hay tickets.Los comprobantes electrónicos cuentan con una estructura de serie diferente a la utilizada por
los comprobantes de pago físicos, lo que permite identificarlos rápidamente para su registro contable. La física es numérica, y la electrónica, alfanumérica
2.6.3.4. Procesos
Para un mejor entendimiento se ha regulado los siguientes procesos que le permitirán incorporarse al sistema rápidamente:
2.6.3.4.1. Proceso de Autorización
Para poder emitir comprobantes de pago electrónicos el contribuyente debe estar autorizado por la SUNAT, para lo cual deberá:
i) Ingresar a la opción “comprobantes de pago/ factura electrónica - grandes emisores/ generar solicitud” disponible en SUNAT Operaciones en Línea y consignar la información solicitada, señalando los comprobantes de pago que desea emitir de forma electrónica (debe solicitar por lo menos facturas). Asimismo, en dicha opción se le mostrará una declaración jurada respecto del sistema que utilizará para la emisión, la cual deberá completar.
ii) Asimismo debe cumplir con:Tener el estado ACTIVO en el Registro Único de ContribuyentesTener la condición de HABIDO en el Registro Único de ContribuyentesEstar autorizado a emitir facturas, según el reglamento de comprobantes de
pagoRegistrar el correo electrónico que utilizará en su calidad de emisor electrónico y
de receptor de comprobantes de pago electrónicos. Este registro se realiza a través de la opción disponible en SUNAT Operaciones en Línea en: “Comprobantes de pago/ factura electrónica - grandes emisores – Correo electrónico”
Estos requisitos serán validados en línea (de manera automática) por el sistema, para luego pasar a un proceso de homologación.
2.6.3.4.2. Proceso de homologación
Generada la solicitud, el contribuyente debe pasar a un proceso de homologación, para lo cual sistema automáticamente le asignará un Set de Pruebas (ver Manual de homologación) el cual permitirá a la SUNAT evaluar si los sistemas del contribuyente gestionan correctamente la elaboración, emisión, envío (entre otros) de los comprobantes de pago electrónicos, según las normas vigentes.
Concluida la fase de homologación, la SUNAT le emitirá una Resolución autorizándolo como Emisor Electrónico. Este proceso consiste en:
Verificar si las facturas, boletas de venta, notas de crédito y debito electrónicas, así como el Resumen Diario y la comunicación de baja son generados y enviados de acuerdo a lo establecido por la SUNAT.
Según los comprobantes de pago que el contribuyente haya solicitado emitir de manera electrónica, el sistema le asignará un set de pruebas. Este set es un conjunto de casos tipo, con los cuales el contribuyente debe confeccionar las facturas y/o boletas de venta y sus notas electrónicas según corresponda. Para cada conjunto de casos, el Manual de homologación, describe las características y contenido que debe cumplir dichos comprobantes para efecto de las pruebas respectivas.
Para todos los tipos de comprobantes de pago se debe pasar las pruebas de manera satisfactoria. En el caso particular de las boletas de venta y sus notas de crédito o débito asociadas, adicionalmente se solicita que se envíen las representaciones impresas para verificar que éstas cumplan con las características requeridas. El envío de estos documentos será a través de la opción “procesos de envío y seguimiento de casos” del menú SOL (para mayor detalle consulte la guía de homologación).
Asimismo, para el seguimiento de este proceso de homologación, el contribuyente tiene una opción de consulta en SOL, a través de la cual podrá visualizar el estado de cada etapa y documento que se está homologando.
Todo el proceso, contado desde la fecha de presentación de la solicitud, no debe exceder los 30 días hábiles, ya que pasado este periodo, se entenderá por IMPROCEDENTE la solicitud, lo que implica que el contribuyente no paso las pruebas, pudiendo volver a presentar una nueva solicitud.
2.6.3.4.3. Proceso de Emisión de Comprobantes de Pago Electrónicos
Se ha definido un tratamiento diferenciado para la Factura Electrónica y para la Boleta de Venta Electrónica y sus correspondientes notas de crédito y debito electrónicas.
En el caso de las Factura Electrónica y las notas de crédito y débito relacionadas, se debe enviar un ejemplar a la SUNAT al momento emisión. La SUNAT validará la información y emitirá una constancia de recepción.
Tratándose de las boletas de venta y las notas de crédito y débito relacionadas, se enviará un Resumen Diario con la información de los comprobantes emitidos en el día.
2.6.3.4.4. Proceso para Otorgar del Comprobante de Pago Electrónico.
La factura se otorgará a través de medios electrónicos (en archivo digital) y la boleta de venta a través de una representación impresa (papel) o medio electrónico (archivo digital), en este caso, se requiere un previo acuerdo del receptor.
El comprobante de pago electrónico es:En el caso de la factura electrónica: El archivo digitalEn el caso de la boleta de venta electrónica: La representación impresa
2.6.3.5. Operatividad del Sistema de Emisión Electrónica
2.6.3.5.1. Factura Electrónica y sus notas de crédito o débito asociadas
a) Se emite la factura o las notas, en los sistemas del contribuyente de acuerdo al formato electrónico establecido por la SUNAT.
b) El emisor envía y/o entrega la factura electrónica a sus clientes (receptores) en formato electrónico a través de una página web, correo electrónico, servicio web, entre otros. El medio de entrega lo define el emisor.
c) De manera simultánea (o a más tardar a las 72 horas contadas desde el día siguiente de la fecha de emisión), se debe enviar un ejemplar a la SUNAT de acuerdo a la forma establecida en el anexo 6 de la Resolución N° 097-2012/SUNAT.
d) La SUNAT valida la información enviada y como resultado de ello, por el mismo medio en el que el emisor envió el comprobante de pago electrónico, envía una Constancia de Recepción – CDR, la cual puede tener los siguientes estados:
Aceptada: Si el comprobante de pago electrónico cumple con las validaciones establecidas. En este caso, el comprobante adquiere total validez tributaria.
Aceptada con observación: Cuando el comprobante de pago electrónico cumple con las validaciones establecidas y por lo tanto, ya tiene validez tributaria, pero hay datos en el comprobante que, producto de una auditoría, podrían ser reparados.
Rechazada: Si no cumple con las condiciones establecidas. En este caso, el comprobante de pago electrónico que se hubiera emitido, no tiene validez tributaria. El emisor tendrá que emitir una nueva factura electrónica corrigiendo los motivos por los cuales fue rechazado.
e) El emisor debe poner a disposición de sus clientes (receptores), una opción de consulta de los comprobantes que hubiera emitido (facturas, boletas de venta y notas de crédito y de débito), a través de una página web, por un periodo no menor a un año. Para acceder a esa consulta, debe definir un mecanismo de seguridad que permita resguardar la confidencialidad de la información, de modo tal que solo el cliente pueda acceder a ella.
f) Adicionalmente, la SUNAT pone a disposición de los contribuyentes, una opción de consulta de los comprobantes electrónicos emitidos. A través de esa consulta, se puede visualizar la información tributaria del comprobante.
Importante:No es obligatorio que primero se envíe el ejemplar de la factura (y sus
correspondientes notas de crédito y debito asociadas) a la SUNAT antes de enviarla al cliente. Sin embargo, debe tener en cuenta que si el ejemplar es rechazado por la SUNAT, no tendrá validez tributaria, por lo que se recomienda, que en la medida que la operatividad lo permita, enviar primero el comprobante a la SUNAT para la validación. Cabe señalar que estos rechazos deben ser mínimos o no existir, considerando que antes de ser autorizados como emisores electrónicos, el contribuyente emisor ha sometido a evaluación, los archivos electrónicos que está generando y es su responsabilidad mantener estas condiciones a futuro.
El plazo de 72 horas para enviar el ejemplar de las facturas y notas electrónicas es un plazo máximo, ya que el envío debería ser en la misma fecha de emisión. Asimismo, este plazo NO significa que en 72 horas debe entregarse los comprobantes a los clientes.
2.6.3.6. Certificado digital
El modelo peruano de Factura Electrónica incluye el uso del Certificado Digital, herramienta tecnológica que permite la integridad, seguridad y el no repudio de las transacciones electrónicas.
El Certificado Digital es utilizado para firmar digitalmente los comprobantes de pago electrónicos (facturas, boletas de venta y notas de crédito y débito) así como los resúmenes diarios y las comunicaciones de baja.
De esta forma, el contribuyente, al firmar digitalmente los comprobantes de pago y demás documentos electrónicos, no puede desconocer posteriormente la autoría de dichos documentos, generando con ello una seguridad en la transacción comercial.La SUNAT requiere para el uso del certificado digital es que éste cuente con la siguiente información:
a. Nombres y apellidos, denominación o razón socialb. De ser persona natural, adicionalmente debe contener el número del documento de
identidad. Si es persona jurídica, debe contener el RUC de la empresa.c. Contar con un nivel de seguridad medio.
Adicionalmente, la empresa a la cual se adquiera los certificados debe cerciorarse que efectivamente sea asignado al contribuyente o representante legal de la empresa.
2.6.3.7. Factura electrónica
La factura electrónica es la regulada por el Reglamento de Comprobantes de pago y que está soportada en un formato digital de acuerdo con las especificaciones establecidas en la Resolución de Superintendencia N° 097-2012/SUNAT.
Las especificaciones de la Factura electrónica, se encuentran detalladas en el Anexo N° 01 (condiciones y requisitos) y en el Anexo N° 9 (formato UBL) de la mencionada solución, En el presente documento se desarrolla el detalle de los campos (tag) indicados en dichos anexos.
CONTENIDO DE LA FACTURA ELECTRONICA
3. CAPITULO III - Estado del Arte
Actualmente existen implementaciones de Factura electrónica en diferentes países la cual cumple con los requisitos legales de los comprobantes tradicionales y garantiza, entre otras cosas, la autenticidad de su origen y la integridad de su contenido, lo que genera una mayor seguridad jurídica, y disminuye los riesgos de fraude y de evasión fiscal ocasionados por la generación de comprobantes apócrifos que afectan a la economía formal.
A continuación se presentan algunos casos de facturas electrónicas en los países de América Latina.
3.1. Caso Guatemala:
Según el acuerdo Número 024-2007 del Directorio de la Superintendencia de Administración Tributaria de Guatemala la Factura Electrónica es una factura autorizada, emitida, archivada y conservada en forma electrónica, lo que garantiza:
-La existencia y procedencia del emisor y receptor-La precisión de su contenido-El control en “tiempo real”-La facilidad de acceso a la información-Igual validez a las de papel-Incorpora un Código de Autorización de Emisión (CAE) que la hace única.
Los actores que participan el proceso de facturación electrónica son:
-Certificador de Sistemas GFACE-GFACE (GENERADORES DE FACTURA ELECTRÓNICA)-EFACE (EMISORES DE FACTURA ELECTRÓNICA)-Comprador-SAT (Superintendencia de Administración Tributaria)
A continuación se presenta la funcionalidad mínima que debe contener el sistema de información de empresas que deseen proveer el servicio de Generación de Factura Electrónica (GFACE).
1. Registro y Control de Contribuyentes Autorizados:
Se debe habilitar el módulo para el control de contribuyentes autorizados para la emisión de facturas electrónicas.
2. Integridad de la información para cada uno de los contribuyentes autorizados para generar Facturas Electrónicas:
Cada una de las entidades (GFACE) que provean el servicio de Generación de Facturas Electrónicas debe suscribir un Convenio de Confidencialidad con la SAT sobre el manejo de la información. De igual forma deberán firmar un Convenio de Confidencialidad individual con las empresas a las cuales proporcionen el servicio a efecto de no divulgar a ningún tercero información de cada una de las empresas a las cuales proporcione el servicio de facturación electrónica. Las entidades GFACE tendrán conocimiento de las implicaciones legales pertinentes en caso de violación a disposiciones de confidencialidad sobre este punto.
Cada uno de los proveedores debe demostrar a la SAT que su sistema garantiza
que cualquier transacción que el contribuyente solicite a través de la aplicación, tendrá lo siguiente:
i. Validación que garantice que cada una de las autorizaciones que la aplicación realice, contenga información consistente.
ii. Asignación de un identificador único de la operación el cual se define en el literal F. Especificaciones técnicas, diseños de registro, requisitos y condiciones de los archivos de facturas electrónicas.
iii. El identificador único de todas las facturas electrónicas y documentos electrónicos tendrán los prefijos siguientes:
a) Factura Electrónica: FACE b) Nota de Crédito Electrónica: NCE c) Nota de Débito Electrónica: NDE
3. Funcionalidades del sistema de los GFACE, para ser utilizadas por los contribuyentes EFACE, en la emisión y control de Facturas y documentos Electrónicos para uno o varios contribuyentes.
A cada uno de los contribuyentes EFACE autorizados para la facturación electrónica, los distintos proveedores GFACE del servicio de facturación electrónica deben habilitarle una aplicación con acceso vía Web que les permita:
i. Registrar sus transacciones electrónicas, cumpliendo con las normas establecidas
por la SAT.
ii. Registro de cada una de las transacciones autorizadas. Especificaciones técnicas, diseños de registro, requisitos y condiciones de los archivos de facturas electrónicas del presente documento, para el detalle de la información y formato del mismo, para los documentos electrónicos generados.
iii. Realizar las transacciones siguientes: a) Facturas b) Notas de Crédito c) Notas de Débito d) Copias de Facturas e) Copias de Notas de Crédito f) Copias de Notas de Débitog) Anulación de las anteriores
iv. Registrar las transacciones a través de:
a) Formulario habilitado en la Web, en el cual se podrá ingresar
manualmente la información de la transacción. b) Carga en lotes, para lo cual el contribuyente debe preparar un archivo
con la información de todas las transacciones que quiere generar, según formato establecido de mutuo acuerdo con el GFACE, el cual será cargado al sistema y generará las autorizaciones correspondientes.
c) Servicios Web (web services), a través del cual se podrá automatizar el registro de las transacciones entre el sistema actual de información del contribuyente y el sistema de facturas electrónicas, según formato establecido de mutuo acuerdo con el GFACE, permitiendo una interrelación entre ambos sistemas.
v. Control de los cierres mensuales y generación automática de los archivos de
las transacciones mensuales generadas. Especificaciones técnicas, diseños de registro, requisitos y condiciones de los archivos a almacenar mensualmente del presente documento, para el detalle de la información y formato de los mismos.
vi. Generación automática de los montos a consignar en la Declaración Jurada del Impuesto al Valor Agregado, de las transacciones electrónicas, del código de seguridad asociado a las transacciones del mes, así como el de las rectificaciones asociadas. Estos valores dependen de los formularios que la SAT tendrá vigente en cada uno de los períodos a declarar, los cuales podrán variar a solicitud de la SAT, la cual deberá ser notificada a cada uno de los proveedor del servicio de Emisión de Facturas Electrónicas un mes antes, como mínimo, del uso del nuevo formato.
vii. Acceso a las transacciones por medio de uno de los siguientes medios: a) Consultas b) Reportes c) Generación de archivos
4. Verificación de cualquier factura electrónica a través de una opción en la Web. Los proveedores GFACE deberán habilitar en la Web una opción en la cual cualquier persona pueda entrar al sistema y validar que la factura electrónica es autentica, para lo cual debe brindar dos opciones:
a) Validación de la autenticidad e integridad de la factura electrónica:
Recibirá el archivo de la factura electrónica y procederá a validar el sello digital, si existe y el código de seguridad de la misma; estos datos deberán ser validados por el sistema de verificación de facturas electrónicas y el sistema deberá indicar si los datos ingresados corresponden o no a una factura electrónica válida.
b) Validación del código de seguridad: Ingresará los campos que conforman el código de seguridad y el CAE o CAEC (según corresponda), con lo cual se podrá validar la integridad de estos datos.
3.2. Caso Chile:
Según el RESOLUCION EXENTA SII N° Servicio de Impuestos Internos (SII) de Chile la Factura Electrónica (FE) consiste en:
-Es la representación informática de un documento tributario generado electrónicamente, que reemplaza al documento soportado en papel y tiene la misma validez que este.
-La FE va firmada digitalmente por el emisor.-La numeración es autorizada via internet por el SII.-Se debe enviar al SII, via internet, un ejemplar de cada FE que el contribúyete emita.-No requiere imprimirse en un papel con fondo pre-impreso ni timbrado.-El contribuyente autorizado como emisor electrónico podra seguir emitiendo documentos no
electrónicos.-Los contribuyentes autorizados a emitir FE deben enviar mensualmente al SII la información electrónica
de compras y ventas.-El contribuyente autorizado como emisor de Documentos Tributarios Electrónicos (DTE) queda
habilitado para recibir electrónicamente los documentos que le envíen otros contribuyentes.
El Servicio de Impuestos Internos (SII) estableció la acreditación de “Prestador de servicios tributarios electrónicos”, la que permite incorporar a los contribuyentes al sistema de factura electrónica en forma
expedita. Este procedimiento es aplicado por los proveedores de soluciones de facturación electrónica que cumplen con los requisitos establecidos en la Resolución Exenta SII N°81.
Actualmente, el Servicio de Impuestos Internos exige a los contribuyentes que sus documentos tributarios en papel, sean registrados y autorizados antes de utilizarlos. Esta autorización del SII se materializa a través de un timbre de cuño que el contribuyente está obligado a aplicar sobre sus documentos en papel, previo a utilizarlos. Para aplicar este timbre de cuño, que autoriza que un papel sea utilizado como documento tributario, el contribuyente debe concurrir periódicamente a la Unidad del SII que le corresponde, llevando los documentos que desea timbrar foliados en forma previa. Tanto para el Servicio como para los contribuyentes, especialmente para los que requieren timbrar un gran volumen de documentos, este es un procedimiento molesto y costoso. Adicionalmente el utilizar estos formularios para imprimir sus documentos tributarios provoca molestias en el procesamiento masivo al obligar a respetar la foliación en la impresión y al no poder utilizar tecnología de impresión láser, como es el deseo de muchos contribuyentes.
En relación con el almacenamiento de las facturas y otros documentos tributarios, el contribuyente está
obligado a guardar los papel es que los sustentan durante 6 años para su posterior posible revisión. Esta obligación deviene, especialmente para los generadores de grandes volúmenes de documentos, una exigencia costosa en administración y bodegas.
Como una respuesta a estas necesidades, y en concordancia con la política adoptada de modernizar su
gestión y utilizar la red Internet como elemento de comunicación con los contribuyentes, el Servicio de Impuestos Internos ha impulsado, con la colaboración de un grupo de empresas, un modelo de operación con Factura Electrónica y que está abierto a todos los contribuyentes. En dicho modelo, los contribuyentes pueden generar, transmitir, y almacenar en forma electrónica sus documentos tributarios, autenticados con firma electrónica, además deben enviar un ejemplar electrónico del documento tributario al SII, antes de que sea recibido por su receptor o utilizado para el transporte físico de bienes. La autorización de los folios que se usan en estos documentos se obtiene en el sitio Web del SII, como alternativa al timbre físico con cuño.
En este modelo se incorpora la facilidad de la firma electrónica de los documentos como un medio de
asegurar la autenticidad de sus emisores, y cautelar la integridad de los documentos a transmitir.
Para operar con la factura electrónica los contribuyentes deben estar autorizados por SII como emisores de documentos electrónicos. Esto no los obliga a generar todos sus documentos en forma electrónica pero sí a recibir documentos electrónicos de otros emisores. Los contribuyentes enrolados en el sistema, una vez que han obtenido la autorización del SII, puede conseguir la autorización de sus folios a través del Web del SII, y, utilizando esos folios, emitir, transmitir y almacenar sus documentos tributarios en forma electrónica. Los contribuyentes enrolados en el sistema requieren almacenar los documentos tributarios electrónicos emitidos y recibidos sólo en forma electrónica y están eximidos de la obligación de almacenar dichos documentos en papel para una posible revisión del SII. El contribuyente debe enviar el documento al SII, vía Internet, antes de que sea recibido por su destinatario o utilizado para el transporte físico de bienes. El contribuyente emisor debe enviar el documento al receptor, ya sea manual
o electrónico. Al receptor manual, no enrolado en el sistema, le debe enviar la representación en papel del documento, la que este último sí está obligado a almacenar.
Cada documento debe ser generado en el estándar definido por las especificaciones del SII. Debe
incorporar una firma electrónica digital de la totalidad del documento, la que permite asegurar la identidad del emisor y cautelar la integridad del documento. Como resguardo adicional, se exige incorporar un “timbre electrónico”, el que se imprime en código de barras en la representación impresa de los documentos. Este timbre electrónico, obtenido según un algoritmo de seguridad especificado por el SII,
permite a los fiscalizadores verificar fuera de línea, en los controles móviles, la validez de los documentos impresos que acompañan mercaderías.
El Servicio de Impuestos Internos habilitó una verificación de documentos en su sitio Web, lo que permite a los contribuyentes receptores y a los fiscalizadores del SII, cerciorarse de la validez de un documento. En la figuras 1 y 2 se pueden apreciar cuadros comparativos entre la situación actual y el sistema de facturación electrónica propuesto.
Figura1:
Figura2:
Modelo operacional:
El contribuyente debe obtener la autorización del SII para operar como Emisor de Documentos Tributarios Electrónicos. El contribuyente podrá solicitar autorización sólo para emitir factura electrónica, lo cual significa que estará autorizado también para notas de crédito y de débito, o podrá solicitar en forma adicional autorización para guías de despacho, facturas de compra o boletas. Las boletas sólo se le autorizarán en el caso que sea un proveedor de servicios periódicos. Una vez autorizado para operar con documentos tributarios electrónicos el contribuyente tiene la obligación de almacenar en forma electrónica, información de los libros de ventas y compras, de acuerdo al formato establecido por el SII. Esta información deberá incluir la totalidad de los documentos emitidos y recibidos, tanto electrónicos como manuales y deberá ser enviada al SII en forma mensual de acuerdo con los procedimientos establecidos para ello por el SII. Excepcionalmente podrá ser solicitada en forma especial (de acuerdo con alguna selección o clasificación específica) si ello es requerido por necesidades de fiscalización.
En el sitio Web del SII, se encuentra disponible un registro público de los contribuyentes enrolados en el sistema, en el que se indica el tipo de documentos (facturas, notas de débito y crédito, guías, facturas de compra, etc), que están autorizados a generar en forma electrónica. Todo contribuyente registrado en el SII como generador de un tipo de documento electrónico, está obligado a recibir documentos tributarios electrónicos. Al estar autorizado para generar cierto tipo de documento en forma electrónica, no está obligado a generar todos sus documentos de ese tipo en forma electrónica, ya que estará permitido que maneje en forma paralela un stock de documentos tributarios manuales para ser usados eventualmente, los cuales timbrará en el SII con el procedimiento habitual del timbre de cuño y estarán sujetos a las normas establecidas para dichos documentos.
Los contribuyentes enrolados deben mantener actualizada en el sitio Web del SII la información acerca
de los Rut de las personas autorizadas al interior de su empresa a interactuar con el SII en el sistema de factura electrónica. Deben identificar él o los Rut de los titulares de los certificados digitales habilitados en su empresa para firmar documentos y, designar en forma especial, quién o quienes están autorizados para la solicitud de folios.
Previo a la generación de un documento tributario electrónico es preciso que el contribuyente obtenga,
desde el sitio Web del SII, un rango de números o folios autorizados para un tipo de documento que generará en forma electrónica. El SII entrega junto a cada rango autorizado un “código de autorización” asociado a ese rango de folios, que debe ser utilizado para la obtención del timbre electrónico cuya representación en código de barras 2D se incluye en los documentos impresos. Para autenticar y evitar la alteración del rango de folios autorizados se incluirá en el código de autorización una firma del Servicio.
Se considera que los documentos electrónicos son tipos de documentos distintos de los manuales, por lo que el SII se entrega para ellos un rango diferente a los folios de los documentos manuales. La estructura de contenido de los documentos, está definida por el SII, bajo el formato estándar XML; la obligatoriedad de los campos depende de tipo de documento. El contribuyente debe convertir sus documentos al formato XML definido por el SII.
Los documentos deben incluir un “timbre electrónico”, como parte del documento electrónico y su
representación gráfica, a través de un código de barras bidimensional (PDF417), en las impresiones de los documentos tributarios electrónicos. El timbre es una firma digital de los datos relevantes de un documento, incluido el “Código de autorización de Folios” que el Servicio entregó al contribuyente junto con el rango de folios autorizados.
El Servicio de Impuestos Internos verifica la validez del timbre electrónico de los documentos, tanto en la
presencia fiscalizadora y en la fiscalización móvil que se realiza en carreteras, como en la recepción masiva de ellos. Una vez generado el documento en el formato establecido, incluyendo el timbre electrónico, debe ser firmado, en su contenido completo, por un emisor autorizado. Es importante que el contribuyente resguarde adecuadamente tanto sus códigos de folios autorizados como sus certificados digitales. Los
mecanismos de seguridad que el contribuyente implemente para asegurar el acceso a los folios autorizados, y a sus llaves privadas, son de su responsabilidad.
Todo documento electrónico debe ser transmitido al SII en el momento de ser generado. En el caso de
traslado de mercaderías, debe ser enviado al SII antes de que el ejemplar impreso sea utilizado para realizar el transporte. En los procesos de facturación masiva, se deben transmitir tan pronto se complete el proceso correspondiente. En el caso de no existir transporte de productos asociado al documento electrónico, este podrá ser transmitido en un plazo no mayor a 12 horas desde su generación.
El mecanismo de envío de estos documentos será vía Internet y permite el envío de documentos en forma unitaria o en lotes, según procedimientos determinados por el SII. El Servicio de Impuestos Internos almacena el ejemplar tributario del documento pero no se hace cargo de almacenar ejemplares para el contribuyente. Si el contribuyente desea acceder a los ejemplares de sus documentos debe almacenar, bajo su responsabilidad, sus documentos tributarios para sus fines particulares.
La modalidad tecnológica de transmisión del documento electrónico, desde el emisor al receptor electrónico, debe ser acordada entre ambos e incluir la firma del emisor e información del certificado digital del firmante y respetar el estándar mínimo establecido por el SII. Los contribuyentes deben intercambiar documentos tributarios electrónicos en el mismo formato XML en que dichos documentos se envían al SII, y se obligan a responder la recepción. Adicionalmente se ha definido un formato XML para la respuesta de recepción o rechazo del envío y la obligación de definir una casilla de correo electrónico para recibir la información relacionada con factura electrónica que le envíen otros emisores electrónicos, en el caso que no convengan un medio alternativo.
Desde el punto de vista de un receptor, si el documento recibido da cuenta de una transacción que se
ha realizado, existe la obligación de registrar el documento en la contabilidad, debiendo solicitar que se realicen los ajustes vía Nota de Crédito o de Débito, si corresponde. Si la transacción no se ha realizado, o hay error en el Rut del receptor, puede rechazar los documentos como lo hace con los documentos no electrónicos, sin registrarlo y constituye obligación del emisor generar y enviar al SII la nota de crédito electrónica que anule el documento.
Los documentos tributarios electrónicos recibidos por un Receptor Electrónico al ser almacenados
electrónicamente debe adjuntárseles la firma y el Certificado que permite verificar la firma. Los registros de un documento electrónico, hechos en la contabilidad, tendrán como respaldo válido sólo los documentos archivados electrónicamente; no se podrá utilizar como respaldo un documento impreso, aún cuando éste cumpla con las normas de impresión.
Se considera que un documento electrónico está válidamente emitido si cumple con las especificaciones
del formato electrónico (“schema” XML) y por lo tanto es aceptado en la recepción por parte del SII. Toda factura que no cumpla con estas condiciones, aún cuando hubiera tenido una representación en papel, se considerará como no emitida y en consecuencia el SII podrá rechazar el crédito fiscal. En este caso el receptor deberá acreditar a satisfacción del Servicio que se han cumplido las exigencias establecidas en el artículo 23° N° 5 de la Ley del IVA.
Actividades Previas a la Emisión de Documentos. Para emitir documentos tributarios electrónicos las empresas previamente deben estar enroladas para
ello por el SII y definir los firmantes autorizados al interior de su empresa. De acuerdo con esto, las actividades previas a la emisión de documentos son:
-Enrolamiento. El SII registra los siguientes datos de los contribuyentes autorizados: la fecha de autorización, los tipos de documentos electrónicos autorizados, la identificación del Usuario-Administrador y la dirección de correo electrónico para intercambio de información con otros contribuyentes autorizados.
-Autorización de Firmantes. La firma digital es una pieza fundamental en el sistema de factura electrónica, ya que permite asegurar la integridad de los documentos y la autenticidad del emisor de los mismos. Las empresas enroladas al sistema deberán registrar ante el SII los firmantes autorizados al interior de su empresa para realizar
ciertas acciones que el SII ha definido que deben efectuarse sólo por parte de los firmantes autorizados de la empresa:
• Definición y actualización de firmantes autorizados ante el SII, lo que deberá ser efectuado
por un “Usuario-Administrador” designado por la empresa a través del representante legal. • Solicitar números de folios para generar documentos electrónicos tributarios válidos. • Solicitar la anulación de folios previamente autorizados, lo que también debería ser ejecutado
por el perfil de “Usuario-Administrador”. Esta anulación de folios se puede utilizar sólo cuando los DTEs generados erróneamente no hayan sido enviados al SII. • Firmar documentos tributarios electrónicos.
• Enviar documentos emitidos al SII y consultar diagnóstico de validación de documentos en el sitio del SII.
- Obtención de rango de folios autorizados y Código de Autorización de Folios. La obtención del rango de
folios autorizados, sólo la podrán efectuar los firmantes autorizados, quienes, se deberán autenticar en el sitio del SII, con certificado digital. En respuesta a las solicitudes de folios válidas, el SII entregará la autorización consistente en el Código de autorización de folios y en un par de llaves que permiten generar y verificar el timbre electrónico.
- Verificaciones al “Código de Autorización de Folios”. El contribuyente deberá verificar la validez y autenticidad del Código de Autorización de Folios (CAF) recibido del SII. Para ello debería:
• Verificar que el CAF esté correctamente firmado por el SII, verificando la firma del SII que incluye, con la llave pública que el SII publique para esos efectos.
• Verificar que el par de llaves que incluye el CAF funciona correctamente. Para ello debería generar una firma con la llave privada y verificar la firma con la llave pública.
Funciones a Incorporar en el Sistema de Facturación. Todo documento electrónico debe estar numerado con un folio único y estar firmado en forma
electrónica en su totalidad, incluyendo el timbre Para ello el contribuyente deberá incorporar a sus aplicaciones las siguientes funciones:
- Alimentar su sistema de facturación con los folios autorizados por el SII.El contribuyente debe ingresar como parámetros a su sistema de facturación el “Código de autorización de folios” y la llave privada entregada por el SII, que le permite generar el timbre electrónico. El sistema del contribuyente debe administrar el Código de autorización de folios por tipo de documento y rango de folios con que esté operando. Tanto el CAF como la llave privada de timbraje asignada por el SII, deben contar con mecanismos de seguridad que impidan el acceso a dicha información a personas no autorizadas.
- Asignar número de folio único a cada documento. El sistema del contribuyente debe asignar en forma única un número de folio para cada documento, utilizando para ello el rango del código de autorización de folios con que fue alimentado. Es obligatorio, como medida de seguridad, que esta asignación de folios sea hecha rigurosamente en forma unívoca para cada documento.
- Calcular el Timbre Electrónico para cada documento. El Timbre Electrónico del DTE consiste en una firma electrónica, sobre los campos que se definen como representativos del documento e incluyendo el Código de Autorización de Folios proporcionado por el SII. La firma que constituye el timbre electrónico debe ser generada con la llave privada entregada por el SII junto con el rango de folios correspondiente.
- Generar documento en formato XML exigido por el SII. El contribuyente debe generar el documento en formato XML de acuerdo al formato definido por el SII.
- Firmar documento completo. El contribuyente debe generar la firma digital sobre el documento completo. Esta firma debe ser generada con un certificado digital vigente y no revocada al momento de la firma.
- Adecuar procedimiento de impresión de documentos. El contribuyente debe adecuar sus procedimientos y formularios utilizados para la impresión, con el fin de generar la representación impresa según la norma del SII, incluyendo el código de barras 2D, simbología PDF417, que contenga la información del código del timbre electrónico. La información incluida en la impresión del Timbre Electrónico es:
1. Versión del timbre electrónico 2. Rut del Emisor 3. Tipo de Documento 4. Número de Folio 5. Fecha de emisión 6. Rut del Receptor 7. Razón Social Receptor 8. Monto total 9. Descripción del primer Item del Detalle 10. Fecha y hora de generación del timbre electrónico, 11. Código de Autorización de Folios (proporcionado por el SII) 12. Algoritmo de firma (Hash y encriptación) que se usó en la firma con que generó el timbre 13. Firma digital sobre los datos anteriores, con la llave privada entregada por el SII para dicho propósito.
- Implementar el intercambio de DTEs con otros contribuyentes autorizados. La empresa deberá
adquirir certificados digitales para los firmantes autorizados al interior de la empresa. Para el intercambio de información entre contribuyentes autorizados se deberá tener habilitado como mínimo la posibilidad recibir y enviar información por e-mail con un archivo adjunto que contenga los documentos, el comprobante de recepción o rechazo, todos ellos en el formato XML establecido por el SII. Cada contribuyente autorizado tendrá registrada en el SII la casilla electrónica a la cual se le debe enviar la información relacionada con factura electrónica: Envíos de DTEs, Comprobantes de Recepción y de Rechazo.
4. Aporte teórico
4.1. Análisis
4.1.1. Requerimientos funcionales
4.1.1.1. Emisor
ID
Requerimiento Funcional
Observaciones
R1-001
Implementar una BD intermedia que soporte los comprobantes de pago electrónicos que SUNAT ha habilitado para su transmisión
Deberá soportar FACTURA, BOLETA DE VENTA, NOTA DE CRÉDITO, NOTA DE DÉBITO, RESUMEN DE BOLETAS, RESUMEN DE BAJAS. Deberá soportar el manejo de grupos empresariales.
R1-002
Firmar comprobantes de pago en el lado del EMISOR
-Firmar comprobantes de pago de tipo FACTURA, BOLETA DE VENTA, NOTA DE CRÉDITO, NOTA DE DÉBITO, RESUMEN DE BOLETAS, RESUMEN DE BAJAS. El componente en el emisor generará comprobantes de pago electrónicos a partir de los datos que proveerá el emisor.
(*) Los Recibos por honorarios están en evaluación por SUNAT por lo que su implementación será
a futuro.- Se debe generar el xml y ser firmado electrónicamente de acuerdo a las especificaciones de SUNAT.- Según lo decida el emisor la creación del comprobante de pago electrónico podrá generar un documento pdf en su servidor de archivos.-El componente en el emisor estructurará la información de los comprobantes de pago electrónicos en formato XML-UBL para su posterior transmisión.-El componente en el emisor se valdrá de la documentación actualizada que brinde SUNAT para la obligatoriedad de datos en el comprobante de pago electrónico.-El componente en el emisor utilizará la firma digital del EMISOR para la generación del comprobante de pago electrónico.- El componente en el emisor no realizará cálculo de IMPUESTOS, DESCUENTOS ni total, ni equivalencias de unidades y moneda. Solo validará la obligatoriedad de los campos que SUNAT requiere para la aceptación del comprobante de pago electrónico (Ver documento Excel suministrado por SUNAT).- El componente en el emisor almacenará el comprobante de pago electrónico – XML firmado - por un periodo de 5 años.- El componente en el emisor generará los comprobantes de pago electrónico una vez que residan en la base de datos intermedia y estén con estado "Por firmar"
R1-003
Enviar los comprobantes de pago electrónicos al
-El componente en el emisor transmitirá los comprobantes de pago electrónicos desde el ambiente del EMISOR hacia el Portal de Negocios de PSE mediante el proceso de publicación de comprobantes de pago electrónicos.
ambiente de PSE
-Se mantendrá una segunda copia del archivo de petición y respuesta de SUNAT acorde a los lineamientos que establece SUNAT.
- Mediante el proceso de publicación de comprobantes se crearán usuarios (adquirientes) para el portal de negocios de ser necesario.
- El componente en el emisor almacenará la respuesta de SUNAT por cada comprobante de pago electrónico – Respuesta XML – por un periodo de 1 año.- Implementar un proceso automático de reenvío, en caso se detecte alguna necesidad de reprocesamiento.
R1-004
Enviar los comprobantes de pago electrónicos directamente a SUNAT
- Este proceso crea los comprobantes de pago electrónico y los envía directamente hacia SUNAT. Gestionando las respuestas de la entidad gubernamental y actualizando estados de las respuestas.
R1-005
Gestionar estados acorde a la repuesta de SUNAT
Los estados que contempla SUNAT son:AceptadoRechazadoAceptado con observacionesPendiente de Envío
Anulado(*) Excepción SUNAT(*) La validación de aquellos comprobantes que hayan retornado una excepción en la comunicación hacia SUNAT podrán ser reprocesados según la normativa vigente de SUNAT- La información de estados debe ser desde el componente web service de PSE.
R1-006
Gestionar estados del documento
-El componente electrónico manejará el estado del documento, el cual involucra la relación entre EL EMISOR-EL COMPROBANTE DE PAGO ELECTRÓNICO- EL ADQUIRIENTE-Los estados del documento contemplados son:Emitido (por el emisor electrónico)Anulado (por el emisor electrónico)Visualizado (por el Adquiriente)Aceptado (por el Adquiriente)Rechazado (por el Adquiriente)
R1-007
Administrar comprobantes de pago electrónicos de grupos empresariales
- Cada empresa perteneciente al grupo empresarial tiene su usuario y clave sol. Este deberá tomarse en cuenta para el firmado digital del comprobante de pago electrónico.- El componente en el emisor contemplará el manejo de grupo empresarial para la creación y envío de comprobante de pago electrónico.
R1-008
Transmisión de archivos adjuntos
Se debe poner a disposición archivos adjuntos asociados al comprobante de pago electrónico para su posterior transmisión al Portal de Negocios del PSE. Se manejará una estrategia para la estructuración de carpetas para su fácil transmisión
4.1.1.2. Componente en PSE
ID
Requerimiento Funcional
Observaciones
R3-001
Carga de archivos para la generación masiva de comprobantes de pago electrónicos en el lado del PSE
-La generación de comprobante de pago electrónico implica la firma electrónica del comprobante en el PSE.
- Se debe almacenar el comprobante de pago electrónico – XML firmado- Se firmará el comprobante de pago electrónico con la firma digital del EMISOR electrónico
- Se debe respetar el estándar xml solicitado por SUNAT.- El proceso debe ser online y por lotes para el caso de registro masivo.
- Se elaborarán interfaces para el proceso de generación de comprobante de pago electrónico así como para su posterior envío hacia SUNAT. Al final del proceso se mostrar los archivos (de petición y de respuesta) para su descarga.
R3-002
Publicar comprobantes de pago electrónicos
El Componente en el PSE deberá recibir y almacenar comprobantes de pago electrónicos de tipo FACTURA, BOLETA, NOTA DE CRÉDITO, NOTA DE DÉBITO, RESUMEN DE BOLETAS, RESUMEN DE BAJAS. En adelante SUNAT habilitará la creación de RECIBO POR HONORARIOS. El componente PSE no realizará cálculo de IMPUESTOS, DESCUENTOS ni total. Solo validará la estructura del xml y la obligatoriedad de los campos que SUNAT requiere para la aceptación del comprobante de pago electrónico.El Componente PSE extraerá la información del comprobante de pago electrónico generado por el EMISOR y guardará la información en la base de datos (con esto la información podrá ser consulta en el Portal de Negocios del PSE) para su posterior envío a SUNAT.El componente en el PSE enviará un correo electrónico notificando al adquiriente de la existencia de un comprobante de pago electrónico en el Portal de Negocios del PSE. Este correo electrónico podrá adjuntar el comprobante de pago electrónico siendo esto configurable por cada EMISOR y que deberá indicarse en el proceso de publicación del comprobante de pago electrónico. El emisor deberá proveer el correo electrónico de cada uno de sus adquirientes.
Cuando el estado SUNAT cambie se le informará al ADQUIRIENTE mediante un correo electrónico.
El EMISOR podrá enviar documentos asociados al comprobante de pago electrónico desde el componente en el emisor hacia el Componente PSE, quedando estos disponibles para su visualización en el Portal de Negocios para ello se tendrá que definir la cantidad en kb máximo que se podrá transmitir por cada comprobante de pago electrónico.
Se crearán usuarios para los ADQUIRIENTES en el Portal de Negocios y se le enviará un correo electrónico notificando su usuario y contraseña. En caso de publique un comprobante de pago electrónico a un adquiriente que no cuente con un correo electrónico designado, se registrará automáticamente un correo electrónico de un usuario asignado por el EMISOR para que realice la actualización de dicha información y sea el encargado de hacer llegar dicho comprobante de pago electrónico a su cliente.
El Cliente será el responsable de la actualización del correo electrónico de sus clientes, así como la asignación de sus clientes que requieran recibir el comprobante de pago electrónico vía correo electrónico en formato PDF.
R3-003
Envío de comprobante de pago electrónicos a SUNAT
El emisor será el responsable de actualizar el estado de envío para que el comprobante de pago electrónico se envíe a SUNAT. Se obtendrá un archivo de respuesta, la cual permitirá actualizar el “estado SUNAT”.Se almacenará el comprobante de pago electrónico – XML firmado - por un periodo de 5 años.Se almacenará la respuesta de SUNAT por cada comprobante de pago electrónico – Respuesta XML – por un periodo de 5 años.- Implementar un proceso automático de reenvío, en caso se detecte alguna necesidad de reprocesamiento.- Se enviarán todos los comprobantes de pago electrónicos hacia SUNAT a
excepción de la BOLETA ELECTRÓNICA.- Se enviará un correo cuando SUNAT haya respondido sobre el comprobante
de pago electrónico enviado.
R3-004
Implementación de notificaciones sobre los procesos de generación, publicación y envío de comprobantes de pago electrónicos
El componente del PSE enviará correos electrónicos para mostrar un resumen de comprobantes procesados durante el último día.
El componente del PSE enviará correos electrónicos detallando los comprobantes de pago electrónicos errados en el proceso de transmisión a SUNAT.
El envío de estos correos electrónicos podrá ser configurado para su envío al EMISOR y al PSE: Se enviará un correo electrónico al finalizar la operación del día (12:30 a.m.)
donde se resumirá la cantidad de comprobantes de pago electrónico emitidos y sus respectivos estados. En el correo se especificará la ruta que el usuario tenga que acceder al mismo reporte pero utilizando el Portal de Negocios (a evaluar factibilidad).
Se enviará 3 correo electrónico durante el día (6:00 a.m., 12:00 m., 6:00 p.m.) indicando la cantidad de comprobantes de pago emitidos hasta ese momento y sus estados.
Se enviará a cada hora (si es necesario) un correo electrónico con el listado de los comprobantes de pago que hayan reportado error y no se hayan solucionado hasta el momento.
R3-005
Administración las certificados y firmas digitales.
El componente en el PSE manejará la lógica administración de firmas digitales para los emisores que decidan cargar los comprobantes de pago electrónicos vía archivo plano.
R3-006
Implementación de puntos de control a fin que el área de soporte de producción del PSE pueda controlar el reprocesamiento de comprobantes ante posibles problemas o contingencias.
Se deberá definir una interfaz donde el área de producción pueda acceder a la información de procesamiento de los comprobantes de pago electrónicos.
R3-007
Consulta de Comprobantes de pago electrónicos
Se habilitará un Servicio Web desde donde el EMISOR podrá extraer la información de sus comprobantes de pago electrónicos
4.1.1.3. Aplicación Web
ID
Requerimiento
FuncionalObservaciones
R4-001
Se dispondrá de una Aplicación Web que contará con los siguientes módulos:
Portal SeguridadMódulo AdministraciónUn sub-módulo de administración de usuarios, roles y permisos (a evaluar
dependiendo de la solución que se escoja). Dentro de este módulo se contemplará la elaboración de una interfaz que
permita la actualización de los correos electrónicos de los adquirientes de manera manual.
Se deberá tener en cuenta la existencia de grupos empresariales para el manejo de usuarios. Se brindarán usuarios administradores este caso.
Portal PerúMódulo Comprobantes ElectrónicosOpción FacturasMostrará el listado de los comprobantes de pago electrónicos emitidos o
recibidos.Se podrá acceder al detalle de cada uno de ellos, e imprimirlos.Además se mostrará el detalle de la información del comprobante de pago
electrónico el cual podrá ser impreso en formato pdf de manera individual o una lista según los filtros que se apliquen.
Se podrá exportar comprimido la lista de comprobantes en formato xml, pdf y xsl.
La impresión del comprobante de pago electrónico y resúmenes de comprobante se mostrará en formato estándar del PSE incluyendo el código hash y el código de barras en la impresión en formato PDF417.La impresión del comprobante de pago electrónico también se contemplará la inclusión de campos adicionales para la impresión del comprobante de pago electrónico, estos serán personalizados por cada emisor.
Comprobantes EmitidosEn esta opción los EMISORES de comprobantes de pago podrán ver los
comprobantes electrónicos emitidos.Se mostrarán los comprobantes de pago en cualquier estado
Comprobantes Recibidos
En esta opción los ADQUIRIENTES de comprobantes de pago podrán ver los comprobantes electrónicos recibidos.
Solo se podrán ver los comprobantes que no tengan estado anulado, eliminado, borrador y no visible.
Se permitirá al ADQUIRIENTE visualizar, exportar, aprobar, rechazar e imprimir un comprobante de pago electrónico.
Opción Resúmenes de BajaMostrará el listado de los resúmenes de baja emitidos
Opción Resúmenes de BoletasMostrará el listado de los resúmenes de boletas y notas de crédito y débito
asociado a boletas emitidos
Opción Estadísticas de EnvíoUn sub-módulo de administración y control sobre el proceso, la información y
estados del comprobante de pago electrónico, se mostrará, de acuerdo a filtros aplicados, un resumen de la cantidad de comprobantes de pagos electrónicos emitidos y la cantidad por estados. Esto puede ser impreso, exportado o enviado vía mail.
Opción Carga MasivaDesde aquí se podrá realizar la generación de comprobantes de pago electrónico
por carga de archivos donde el EMISOR decidirá si el comprobante de pago electrónico realiza solamente el proceso de generación y si además completa todo el proceso el cual involucra el proceso de envío hacia SUNAT. El estándar del archivo plano que se cargará será definido por el PSE.
Un sub-módulo para el control de impresión en lotes, exportación a diversos formatos de comprobantes de pago electrónicos. Deberá llevarse un control de la impresión, tanto del lado del emisor y del adquiriente electrónico, de manera que se sepa cuántas veces se ha impreso y mediante que usuario.
R4-002
La Aplicación Web contará con un módulo donde el ADQUIRIENTE podrá visualizar directamente los comprobantes de pago electrónicos recibidas, esta opción tendrá los siguientes parámetros:
Esta opción tendrá los siguientes parámetros:Tipo de documento del Emisor (RUC para Perú). Tipo de Comprobante Número de Comprobante de Pago Electrónico (serie y correlativo)Fecha de EmisiónMonto TotalOpcional: Código de Validación.Esta opción permitirá visualizar directamente el documento en detalle y sólo tener la opción de imprimirlo en formato PDF y pudiendo archivar dicha información mediante la opción de guardar copia de PDF.
R4-003
Se implementará un Sub - módulo REGISTRO DE FACTURAS
Se deberá contemplar todos los comprobantes de pago electrónicos que soporta SUNAT. Se podrá realizar mediante carga de archivos, o accediendo directamente al portal de negocios.Deberá facilitar adjuntar archivos (sustento).No solo se podrán registrar comprobantes de pago electrónico, también se podrá enviar información sin firma digital.Se habilitará una opción para la carga de adquirientes no registrados en el portal Permitirá realizar referencias a documentos publicados en el portal de negocios: Órdenes de compra, aceptación de mercadería / serviciosPodrá controlar la opción de publicación a SUNAT (pudiendo facilitar la información sólo al adquiriente).Se habilitará un opción para que el emisor electrónico pueda realizar equivalencias de código y descripción de sus ítems con la información publicada por el adquiriente (órdenes de compra, aceptación de mercadería / serviciosSe manejarán estados adicionales: Borrador: Factura que no ha sido enviada aun al adquiriente, puede faltar registrar datos o no.Error de Recepción: Factura que no se registró en el ERP del receptor, por un error generado en el proceso de registro. Se muestra error enviado por ERP.Pre-Registrado: Factura pre-registrada en el ERP del receptor, sin error.Recibido: Cliente genera un cambio de estado para dar por recibido el documento, no contabilizado o aceptado, sólo recibido (no mapeado actualmente).Aceptado: Aceptada por el portal de negocios o contabilizada (registrada) en el ERP del adquiriente.Programado de Pago: Adquiriente realiza programación del pago (actualmente no se realiza o es muy cercana a la fecha de pago).Bloqueado: Factura bloqueada en el ERP del adquiriente (por retención de pago u otros).Pagado: Comprobante pagado en el ERP del adquiriente. Se debe mostrar la forma de pago.
4.1.2. Requerimientos no funcionales
4.1.2.1. Componente Emisor
ID Requerimiento No Funcional Observaciones
R1-009 Se asegurará la transmisión del 100% de comprobantes
R1-010
Se debe implementar, con un nivel de seguridad aceptable, la comunicación de la información de comprobantes de pago electrónicos desde el emisor hacia SUNAT.
Implementar seguridad HTTPS
R1-011
El tiempo de transacción no excederá los 5 segundos.Para generación del
archivo firmado y comprimido.
R1-012
El componente en el emisor será escalable a fin de incluir mayor tipo de comprobantes de pago electrónicos a futuro.
R1-013 Se controlará los errores y excepciones de todo el proceso.
- El componente en el emisor manejará errores tales como caída del sistema por saturación de transacciones, es decir no debe perderse ningún comprobante de pago electrónico en ningún momento. En caso se corte el procesamiento de algún comprobante de pago electrónico, este debe ser vuelto a procesar al momento que el sistema vuelva a encontrarse estable.
Deberá mostrarse alertas, avisas por caídas de SUNAT.
R1-014
Asegurar el 100% de la transferencia de información
El componente en el emisor manejará mecanismos de retransmisión de datos en caso SUNAT responda con alguna excepción. Se mantendrá la traza del comprobante sabiendo en todo momento su estado y acciòn a realizar
4.1.2.2. Componente Proveedor de servicio facturación
ID Requerimiento Funcional Observaciones
R3-008
Se deberá asegurar la transmisión de comprobantes de pago de hasta 1 millón de comprobantes por día o hasta 10 millones al mes para un total de entre 10 a 100 clientes
Se debe realizar un plan de pruebas de rendimiento.
R3-009
El tiempo de transacción no excederá los 5 segundos.
R3-010
Se desea registrar todos los sucesos que ocurren en el sistema, a fin de reconstruir todas las actividades realizadas en la aplicación.
Se deben maneja habilitación de tipos de sucesos.
R3-011
Los componentes tienen que tener la capacidad de recuperación ante fallas.
R3-012
La información se transmitirá de forma tal de garantizar la integridad y autenticidad de la misma.
R3-013
El diseño debe estar desarrollado de forma tal que pueda crecer con facilidad, ante la inclusión de nuevos canales de comunicación
WS, MQ, JMS
R3-014
El componente PSE podrá manejar hasta 1 millón de comprobantes de pago electrónicos por día.
4.1.3. Modelo de procesos
Exportar a formatos diferentes
Ver detalle comprobante electrónico
Imprimir
<<extend>>
Se envían todos los comprobantes SUNAT a excepción de las boletas electrónicasVer detalle resumen
comprobante
La generación implica la firma y almacenamiento de CDP
Registro Masivo Comprobante
Ver detalle resumen de bajas
Reg. Masivo de Resumenes de Boletas
Reg. Masivo de Resumenes de Bajas
Generar comprobantes electrónicos
<<include>>
Envío de documentos a SUNAT
<<include>>
Componente ebiz
Evaluar comprobante electrónico
<<extend>>
Descarga archivos adjuntos
<<extend>>
Adquiriente Electrónico
Consulta de Estadísticas
Consultar Comprobantes Electrónico
<<extend>>
<<extend>>
<<extend>>
Consulta Resumen de Boletas
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Consultar Resumen de Bajas
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Generar código barras
<<extend>>
Ver detalle cargas masivas
Emisor Electrónico
Consulta de Cargas Masivas
<<extend>>
<<extend>>
<<extend>>
<<extend>>
4.1.4. Diagrama de Casos de Uso
4.1.4.1. Caso de Uso: Consulta Comprobantes
Se consulta el módulo de comprobantes
Se aplican filtros
Ver el detalle del comprobante
¿Qué opción desea realizar el usuario?
Exportar
Se selecciona para imprimir lista continua
Se seleciona un comprobante para descargar archivos adjuntos
Se selecciona comprobantes para su envío a SUNAT
Se muestra la interfaz de comprobante electrónico
Se despliega la lista de comprobante electrónico
Implementación CUS Ver Detalle Electrónico
Se exporta en formato PDF, XML y archivos plano
Se exporta el rango de comprobantes en formato PDF
Se exporta los archivos adjuntos en formato zip
¿Ya fue enviado a SUNAT?
Se muestra mensaje de enviado previamente
Se declara los comprobantes seleccionados
Se muestra filtros dependiente si el que consulta es el adquiriente o emisor
El archivo de exportación debe estar comprimido
Se debe definir un máximo de comprobante a emitir
SINO
SistemaEmisor/Adquiriente
4.1.4.2. Caso de Uso: Consulta Resumen de Comprobantes, Consulta de Resumen de Bajas
¿Qué opción desea realizar el usuario?
Se selecciona comprobantes para su envío a SUNAT(from State/Activity Model5)
Se consulta módulo de resúmenes
Se aplican filtros
Se selecciona para ver el detalle del resumen
Se selecciona para exportar
Se exporta en formato PDF, XML y archivos plano
(from State/Activity Model5)
¿Ya fue enviado a SUNAT?
Se muestra mensaje de enviado previamente
(from State/Activity Model5)
Se muestra la interfaz de resumen electrónico
Se despliega la lista de resúmenes
Se muestra el detalle del resumen
Se declara los resúmenes seleccionados
El archivo de exportación debe estar comprimido
Se debe definir un máximo de comprobante a emitir
SistemaEmisor/Adquiriente
4.1.4.3. Caso de Uso: Evaluar comprobante electrónico
Ver detalle Comprobante
Actualiza el estado del comprobante
¿Puede evaluar el comprobante?
¿Desea imprimir el comprobante?
Imprimir Comprobante
SI
NO
Anular?
Indicar motivo rechazo
Se despliega detalle comprobante
Actualiza el estado del comprobante en BD
Puede ACEPTAR/RECHAZAR
Solo puede evaluar el comprobante si no está anulado o si ya ha sido evaluado previamente.
NO
SI
NO
SistemaAdquiriente
4.1.4.4. Caso de Uso: Registro Masivo de Comprobantes, Registro Masivo de Resúmenes de Baja, Registro Masivo de Resúmenes de Comprobantes
Se selecciona la opción "Registro Masivo"
Se carga el archivo
Se selecciona la empresa del grupo empresarial
Confirma la generación de comprobantes electrónicos
Se envía a SUNAT
Se despliega la interfaz de Registro Masivo de Comprobantes
Se procesa la carga de archivos
¿Validación correcta?
Se muestra la lista de archivos cargados valido e inválidos
Se muestra la lista de comprobantes electrónicos generados
Se muestra la opción de enviarlos a SUNAT
Se confirma que los archivos están siendo enviados a SUNAT
Se invoca CUS Generar Comprobante Electrónico
Se invoca CUS Enviar Comprobantes Electrónicos
Se validará estructura del archivo, parámetros obligatorios y si se tiene la firma digital de la empresa en cuestión
Se mostrarán aquellos que no pasaron correctamente y a aquellos que si.
SistemaEmisor
Consideraciones:Se podrán generar comprobantes electrónicos de tipo Factura, Boleta, Nota de crédito,
Nota de débito.Se deberá considerar en caso la empresa pertenezca a un grupo empresarial.Solo se enviarán a SUNAT los comprobantes de tipo Factura, Nota de Crédito y Nota de
Débito.
4.1.4.5. Caso de Uso: Ver detalle comprobante electrónico
Para el adquiriente
¿Qué acción realiza el adquiriente?
Se muestra el detalle de comprobante
Se descarga archivo adjunto
Evalúa el comprobante
Imprimir el comprobante
Se muestran partes claramente diferenciadas1. Cabecera (imagen de empresa, tipo de documento, dirección, etc).2.Detalle (items, montos totales,código hash, código de barras)3. Documentos adjuntos al comprobante
Se descargará uno por uno todos los archivos zip
estado ADQUIRIENTE: VISUALIZADO
estado ADQUIRIENTE: APROBADO/RECHAZADO
Se exporta en PDF
SistemaEmisor
Para el emisor
¿Qué acción realiza el emisor?
Se muestra el detalle de comprobante
Se descarga archivo adjunto
Imprimir el comprobante
Se muestran partes claramente diferenciadas1. Cabecera (imagen de empresa, tipo de documento, dirección, etc).2.Detalle (items, montos totales,código hash, código de barras)3. Documentos adjuntos al comprobante
Uno por uno en un archivo
SistemaEmisor
4.1.4.6. Caso de Uso: Generar Comprobante Electrónico
Se invoca la generación de comprobante electrónico
Se procesa la generaciónde comprobante electrónico
Se devuelve confirmación de generación comprobantes electrónicos
Sistema RemotoSistema
4.1.4.7. Caso de Uso: Enviar Comprobante Electrónico
Se invoca el envío de comprobante electrónico Se procesa el envío de
comprobante electrónico
Se devuelve confirmación de envío de comprobantes electrónicos
Sistema RemotoSistema
4.1.4.8. Caso de Uso: Consulta de carga masiva
Se consulta la opción de cargas masivas
Se aplican filtros
¿Qué opción desea realizar el usuario?
Ver detalle de carga masiva
Se muestra la interfaz de cargas masivas
Se despliega lista de cargas masivas
Se implementa caso de uso: Ver detalle de carga masiva
Sistema WebEmisor Electrónico
4.1.4.9. Caso de Uso: Detalle de carga masiva
Ver detalle de carga masiva
Descarga de lista
Muestra detalle de carga masiva
Muestra los comprobantes que no pasaron la validación inicial, los comprobantes que tuvieron error en el proceso de firma y el total de comprobante en el archivo de carga
Sistema WebEmisor Electrónico
EQUIPO INTEGRACIÓN
CLIENTE PSE
INTERNETInternet
Arquitectura de Componentes de Integración de Facturación Electrónica en Perú
Consume WS
ERP
BD Intermedia
4.Act. Rsta Sunat
Lee / actualiza
BD
0. Firma online y almacena
5 años
Emite / recibe
Consume WS
Canal de Comunicación seguro(WS, MQ)
6.Consulta y actDe Rsta Sunat
obtiene
1. WS de FirmaY depósito en BD
intermedia
3.Almacenar, Declarar,Desplegar BD, act. Rsta Sunat,
Enviar a BD intermedia
2. Envía a PSE y/o Declara a Sunat
DB ERP
Actualiza
Desplegar un Web Service que haga la firma, deposite la data firmada en la BD intermedia y le devuelva la data online al cliente
XML
Recibe/ emite
XML
SUNAT
4.WS Sunat
5. WS con rsta Sunat
Portal Web
Consume WS Sunat
Lee / actualiza
Configura y envía lista de comprobante a declarar
Si el envío viene por configuración del portal y la firma es por integración se debe enviar la respuesta de Sunat a la BD intermedia
7.Firma, almacenado, declaración Por carga o manual
Estos procesos son para carga de comprobantes desde el portal (de manera masiva o registro manual)
Responsabilidad del Emisor Responsabilidad del PSEResponsabilidad de Sunat
4.2. Arquitectura
4.3. Diseño
a. Diagrama de clases de diseño
Resumen
identificador
(from DIagrama Clases Diseño)
Estado
ArchivoAdjuntonombreDocumento
TipoDocumento
DocumentoElectronicofirmaElectronicacódigoHashfechaGeneracióninformacionCódigoBarras
MonedacodigoIso
Factura Boleta NotaCrédito NotaDébito
Comprobanteserie-numero
ResumenBajaResumenBoletas
DocumentoproveedorfechaEmision
tiene
puede tener
pertenece
puede referenciar a otro
tiene
Notacodigotexto
puede tener
puede ser
b. Diagrama de componentes
Componente Seguridad
Portal Seguridad
Componente core-ebiz
Portal Peru
Componente FE ebiz
Descripción de componentesComponente Descripción
Componente core-ebiz Es el componente que encapsula todas las funcionalidades comunes a los Portales Web incluyendo clases utilitarias y componentes de diseño. Además contiene las interfaces para el acceso al componente de seguridad.
Componente FE ebiz Es el componente que tiene todas las funcionalidades para la integración del emisor con SUNAT para la publicación y envío de facturas electrónicas.
Componente Portal Seguridad
Portal Web que permite la gestión de roles y perfiles de los usuarios de los demás Portales de Negocio.
Componente Portal Perú
Portal Web que permite el ingreso a proveedores y clientes para la visualización de facturas electrónicas.
Componente Seguridad Componente que gestiona la lógica de administración de usuarios, roles
y perfiles.
c. Diagrama de despliegue
ServidorAplicacionesPortalPeru
ServidorBaseDatosPortalPeru
Cliente Web
ServidorAplicacionesComponenteSeguridad
ServidorBaseDatosSeguridad
Componente DescripciónHost Cliente Web Es el usuario final que ingresa al portalServidor Aplicaciones
Portal PerúEs el servidor donde estará alojado el Portal Perú.
Servidor Aplicaciones Componente Seguridad
Es el servidor donde se alojará el componente de seguridad quién proveerá la autorización mediante un login al portal Perú.
Servidor Base Datos Perú
Es el servidor donde estará alojada la base de datos DB2 y el esquema que utilizará el portal.
Servidor Base Datos Seguridad
Es el servidor donde estará alojado la base de datos DB2 y el esquema que utilizará el componente de seguridad
d. Diseño lógico de base de dato
R_57
R_65
R_101
R_138
R_150
R_152
R_153
R_154
R_155
R_234
R_235
R_241
R_242
R_133
R_249
R_250
R_252
R_256
R_257
R_258
R_259
R_260
R_262
R_263
R_264
R_266
R_268
R_269
R_270
R_271
TD_FACTURABOLETAITEM
PK_FACTURAITEMPK_DOCUMENTO (FK)
NU_POSICIONCA_ITEMCO_UNIDAD_MEDIDAMO_IMPORTE_SIN_IMPUESTOMO_IMPORTE_UNITARIO_SIN_IMPUESMO_IMPORTE_UNITARIO_CON_IMPUESCO_TIPO_PRECIOMO_IMPUESTO_IGVCO_EXONERACION_IMPUESTO_IGVMO_IMPUESTO_ISCTI_SISTEMA_IMPUESTO_ISCMO_DESCUENTOMO_CARGODE_PRODUCTOCO_PRODUCTOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_DOCUMENTONOTA
PK_NOTA
FK_DOCUMENTOCO_NOTADE_NOTAUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_RESUMENCOMPROBANTE
PK_DOCUMENTO
DA_IDENTIFICADORFK_DOCUMENTO_ELECTRONICO (FK)FK_TIPO_EMISIONFK_ESTADO_DOCUMENTODA_ANNIO_FISCALNO_CORREO_EMISORDA_IDENTIFICADOR_ERPFE_EMISIONFE_GENERACIONTI_CODIGO_TRIBUTARIO_EMISNU_TRIBUTARIO_EMISORNO_RAZON_SOCIAL_EMISORNU_COMPROBANTESIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TD_RESUMENCOMPROBANTEITEM
PK_RESUMEN_ITEMPK_DOCUMENTO (FK)
NU_FILAFK_TIPO_DOCUMENTO (FK)FK_TIPO_MONEDA (FK)NU_SERIENU_NUMERO_INICIONU_NUMERO_FINMO_IMPORTE_TOTALMO_IMPUESTO_IGVMO_IMPUESTO_ISCMO_IMPUESTO_OTROSMO_TOTAL_CARGOSMO_TOTAL_GRAVADOMO_TOTAL_NO_GRAVADOMO_TOTAL_EXONERADOMO_TOTAL_VENTA_EXPORTACIONESUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_DOCUMENTOREFERENCIA
PK_DOCUMENTO_REFERENCIA
FK_DOCUMENTOFK_TIPO_DOCUMENTO (FK)DA_IDENTIFICADORIN_ESADICIONALUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_RESUMENBAJ ACOMPROBANTE
PK_DOCUMENTO
FK_ESTADO_DOCUMENTOFK_TIPO_EMISIONFK_DOCUMENTO_ELECTRONICO (FK)DA_ANNIO_FISCALNO_CORREO_EMISORDA_IDENTIFICADOR_ERPDA_IDENTIFICADORFE_EMISIONFE_GENERACIONTI_CODIGO_TRIBUTARIO_EMISORNU_TRIBUTARIO_EMISORNO_RAZON_SOCIAL_EMISORNU_COMPROBANTESIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TD_RESUMENBAJ AITEM
PK_RESUMEN_BAJ A_ITEMPK_DOCUMENTO (FK)
NU_FILAFK_TIPO_DOCUMENTO (FK)NU_SERIE_NUMERODE_MOTIVO_BAJ AUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_TIPODOCUMENTO
PK_TIPO_DOCUMENTO
CO_TIPO_DOCUMENTONO_TIPO_DOCUMENTOCO_GRUPOIN_HABILITADONO_RUTA_SERVIDOR_ARCHIVOSUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_ESTADODOCUMENTO
PK_ESTADO_DOCUMENTO
FK_TIPO_DOCUMENTO (FK)NO_ESTADO_DOCUMENTODE_ESTADO_DOCUMENTOIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TD_NOTACREDITODEBITOITEM
PK_NOTA_CREDITO_DEBITO_ITEMPK_DOCUMENTO (FK)
NU_POSICIONCA_ITEMCO_UNIDAD_MEDIDAMO_IMPORTE_SIN_IMPUESTOMO_IMPORTE_UNITARIO_SIN_IMPUESMO_IMPORTE_UNITARIO_CON_IMPUESDE_ITEMCO_PRODUCTOTI_PRECIOMO_IMPUESTO_IGVCO_EXONERACION_IMPUESTO_IGVMO_IMPUESTO_ISCTI_SISTEMA_IMPUESTO_ISCDC_DESCUENTODC_CARGOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_NOTACREDITODEBITO
PK_DOCUMENTO
FK_MODULO (FK)FK_DOCUMENTO_ELECTRONICO (FK)FK_TIPO_MONEDA (FK)FK_ESTADO_DOCUMENTOFK_TIPO_EMISIONFK_TIPO_DOCUMENTO (FK)NU_SERIE_NUMEROFE_EMISIONDA_ANNIO_FISCALMO_TOTAL_DESCUENTOSMO_TOTAL_CARGOSMO_TOTAL_AJ USTEDE_OBSERVACIONMO_IMPUESTO_IGVMO_IMPUESTO_ISCMO_IMPUESTO_OTROSTI_CODIGO_TRIBUTARIO_EMISORNU_TRIBUTARIO_EMISORTI_CODIGO_TRIBUTARIO_ADQUIRIENNU_TRIBUTARIO_ADQUIRIENTENO_RAZON_SOCIAL_ADQUIRIENTENO_CORREO_ADQUIRIENTENO_RAZON_SOCIAL_EMISORNO_COMERCIAL_EMISORUB_EMISORDI_EMISORNO_CORREO_EMISORNO_PAIS_EMISORNO_DEPARTAMENTO_EMISORNO_PROVINCIA_EMISORNO_DISTRITO_EMISORNO_URBANIZACION_EMISORNO_DISCREPANCIA_DOCUMENTO_AFECCO_MOTIVO_DOCUMENTO_AFECNU_SERIE_NUMERO_DOCUMENTO_AFECDA_IDENTIFICADOR_ERPIN_ESREFERENCIADOMO_TOTAL_GRAVADOMO_TOTAL_NO_GRAVADOMO_TOTAL_EXONERADOIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODIDA_COMENTARIO_RECHAZO
TM_MONEDA
PK_TIPO_MONEDA
NO_TIPO_MONEDACO_TIPO_MONEDAIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_DOCUMENTO_ELECTRONICO
PK_DOCUMENTO_ELECTRONICO
FK_TIPO_DOCUMENTO (FK)FK_ESTADO_SUNAT (FK)FK_ESTADO_DOCUMENTO (FK)DA_OBSERVACION_SUNATNO_ARCHIVO_PETICIONBL_DOCUMENTO_ELECTRONICOFH_INSERCION_DOCUMENTODA_FIRMA_ELECTRONICADA_HASHFH_FIRMA_ELECTRONICACO_ORIGENNO_ARCHIVO_RESPUESTABL_ARCHIVO_RESPUESTACO_RESPUESTADE_RESPUESTAFH_ENVIO_SUNATFH_RESPUESTA_SUNATDA_CODIGO_BARRASNO_ARCHIVO_CODIGO_BARRASNO_RUTA_ARCHIVO_CODIGO_BARRASNU_VERSION_UBLNU_PERSONALIZACIONUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_ARCHIVO_ADJ UNTO
PK_ARCHIVO_ADJ UNTO
FK_DOCUMENTONO_ARCHIVO_ADJ UNTONO_RUTA_ARCHIVO_ADJ UNTOFE_EMISIONUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_MENSAJ E
PK_MENSAJ E
NO_MENSAJ ENU_DOCUMENTO_ERPBL_MENSAJ EIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODITI_CODIGO_TRIBUTARIONU_CODIGO_TRIBUTARIO
TM_FACTURABOLETA
PK_DOCUMENTO
FK_TIPO_DOCUMENTO (FK)FK_TIPO_MONEDA (FK)FK_MODULO (FK)FK_DOCUMENTO_ELECTRONICO (FK)FK_ESTADO_DOCUMENTOFK_TIPO_EMISIONNU_SERIE_NUMEROFE_EMISIONNO_CORREO_EMISORDA_ANNIO_FISCALMO_IMPORTE_SIN_IMPUESTOMO_IMPORTE_CON_IMPUESTOMO_TOTAL_DESCUENTOSMO_TOTAL_CARGOSMO_IMPORTE_TOTALMO_IMPUESTO_IGVMO_IMPUESTO_ISCMO_IMPUESTO_OTROSTI_CODIGO_TRIBUTARIO_EMISORNU_TRIBUTARIO_EMISORNO_RAZON_SOCIAL_ADQUIRIENTETI_CODIGO_TRIBUTARIO_ADQUIRIENNU_TRIBUTARIO_ADQUIRIENTENO_CORREO_ADQUIRIENTEDI_PAIS_ADQUIRIENTENO_RAZON_SOCIAL_EMISORNO_COMERCIAL_EMISORUB_EMISORDI_EMISORNO_PAIS_EMISORNO_DEPARTAMENTO_EMISORNO_PROVINCIA_EMISORNO_DISTRITO_EMISORNO_URBANIZACION_EMISORDE_OBSERVACIONDA_IDENTIFICADOR_ERPIN_ESREFERENCIADOMO_TOTAL_GRAVADOMO_TOTAL_NO_GRAVADOMO_TOTAL_EXONERADOTI_MONEDA_PERCEPCIONMO_PERCEPCIONMO_TOTAL_CON_PERCEPCIONIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODIDA_COMENTARIO_RECHAZO
TM_MODULO
PK_MODULO
DE_MODULONO_MODULOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_TABLA_MULTIPLE
PK_TABLA_MULTIPLE
NO_TABLACO_ITEM_TABLANO_CORTONO_LARGOIN_HABILITADOUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_MODULOTIPODOCUMENTO
PK_TIPO_DOCUMENTO (FK)PK_MODULO (FK)
USUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_HISTORIAL_ESTADO_DOCUMENTO
PK_HISTORIAL_ESTADO_DOCUMENTO
FK_DOCUMENTOFK_ACCION (FK)FK_ESTADO_DOCUMENTO (FK)DE_OBSERVACIONUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TM_CARGAMASIVA
PK_CARGA_MASIVA
TI_CODIGO_TRIBUTARIONU_CODIGO_TRIBUTARIONO_RAZON_SOCIALFH_CARGACO_IDENTIFICADOR_CARGAFK_ESTADO_CARGA (FK)FK_TIPO_DOCUMENTO (FK)NU_CARGA_INICIALNU_CARGA_ERROR_FORMATONU_FIRMADOSNU_ERROR_FIRMAUSUA_CREAFECH_CREAUSUA_MODIFECH_MODI
TR_CARGAMASIVADETALLE
PK_CARGA_MASIVA_DETALLE
FK_CARGA_MASIVA (FK)DA_IDENTIFICADOR_DOCUMENTOFE_EMISIONFK_ESTADO_CARGA_DOCUMENTO (FK)USUA_CREAFECH_CREAUSUA_MODIFECH_MODI
e. Diseño físico de base de datos
TABLA_MULTIPLE seconsidera:Código de OrigenCódigo SUNATCódigo de documentotributario
TD_FACTURABOLETAITEM
PK_FACTURAITEM: BIGINTPK_DOCUMENTO: BIGINT (FK)
NU_POSICION: INTEGERCA_ITEM: DECIMAL(12,3)CO_UNIDAD_MEDIDA: CHAR(3)MO_IMPORTE_SIN_IMPUESTO: DECIMAL(12,2)MO_IMPORTE_UNITARIO_SIN_IMPUES: DECIMAL(12,2)MO_IMPORTE_UNITARIO_CON_IMPUES: DECIMAL(12,2)CO_TIPO_PRECIO: CHAR(2)MO_IMPUESTO_IGV: DECIMAL(12,2)CO_EXONERACION_IMPUESTO_IGV: CHAR(2)MO_IMPUESTO_ISC: DECIMAL(12,2)TI_SISTEMA_IMPUESTO_ISC: CHAR(2)MO_DESCUENTO: DECIMAL(12,2)MO_CARGO: DECIMAL(12,2)DE_PRODUCTO: VARCHAR(100)CO_PRODUCTO: VARCHAR(100)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_PARAMETRO
PK_PARAMETRO: BIGINT
NO_PARAMETRO: varchar(100)VC_VALOR: varchar(100)VC_DESCRIPCION: varchar(50)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_DOCUMENTONOTA
PK_NOTA: BIGINT
FK_DOCUMENTO: BIGINTCO_NOTA: char(4)DE_NOTA: VARCHAR(100)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_RESUMENCOMPROBANTE
PK_DOCUMENTO: BIGINT
DA_IDENTIFICADOR: varchar(30)FK_DOCUMENTO_ELECTRONICO: BIGINT (FK)FK_TIPO_EMISION: BIGINTFK_ESTADO_DOCUMENTO: BIGINTDA_ANNIO_FISCAL: VARCHAR(10)NO_CORREO_EMISOR: VARCHAR(50)DA_IDENTIFICADOR_ERP: VARCHAR(30)FE_EMISION: DATEFE_GENERACION: DATETI_CODIGO_TRIBUTARIO_EMIS: char(2)NU_TRIBUTARIO_EMISOR: varchar(20)NO_RAZON_SOCIAL_EMISOR: varchar(100)NU_COMPROBANTES: INTEGERIN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TD_RESUMENCOMPROBANTEITEM
PK_RESUMEN_ITEM: BIGINTPK_DOCUMENTO: BIGINT (FK)
NU_FILA: INTEGERFK_TIPO_DOCUMENTO: BIGINT (FK)FK_TIPO_MONEDA: BIGINT (FK)NU_SERIE: varchar(4)NU_NUMERO_INICIO: VARCHAR(15)NU_NUMERO_FIN: VARCHAR(15)MO_IMPORTE_TOTAL: decimal(12,2)MO_IMPUESTO_IGV: decimal(12,2)MO_IMPUESTO_ISC: decimal(12,2)MO_IMPUESTO_OTROS: decimal(12,2)MO_TOTAL_CARGOS: decimal(12,2)MO_TOTAL_GRAVADO: DECIMAL(12,2)MO_TOTAL_NO_GRAVADO: DECIMAL(12,2)MO_TOTAL_EXONERADO: DECIMAL(12,2)MO_TOTAL_VENTA_EXPORTACIONES: DECIMAL(12,2)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_DOCUMENTOREFERENCIA
PK_DOCUMENTO_REFERENCIA: BIGINT
FK_DOCUMENTO: BIGINTFK_TIPO_DOCUMENTO: BIGINT (FK)DA_IDENTIFICADOR: VARCHAR(30)IN_ESADICIONAL: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_RESUMENBAJ ACOMPROBANTE
PK_DOCUMENTO: BIGINT
FK_ESTADO_DOCUMENTO: BIGINTFK_TIPO_EMISION: BIGINTFK_DOCUMENTO_ELECTRONICO: BIGINT (FK)DA_ANNIO_FISCAL: VARCHAR(10)NO_CORREO_EMISOR: VARCHAR(50)DA_IDENTIFICADOR_ERP: VARCHAR(30)DA_IDENTIFICADOR: varchar(30)FE_EMISION: DATEFE_GENERACION: DATETI_CODIGO_TRIBUTARIO_EMISOR: char(2)NU_TRIBUTARIO_EMISOR: varchar(20)NO_RAZON_SOCIAL_EMISOR: varchar(100)NU_COMPROBANTES: INTEGERIN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TD_RESUMENBAJ AITEM
PK_RESUMEN_BAJ A_ITEM: BIGINTPK_DOCUMENTO: BIGINT (FK)
NU_FILA: INTEGERFK_TIPO_DOCUMENTO: BIGINT (FK)NU_SERIE_NUMERO: varchar(20)DE_MOTIVO_BAJ A: varchar(100)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_TIPODOCUMENTO
PK_TIPO_DOCUMENTO: BIGINT
CO_TIPO_DOCUMENTO: CHAR(2)NO_TIPO_DOCUMENTO: VARCHAR(200)CO_GRUPO: CHAR(2)IN_HABILITADO: INTEGERNO_RUTA_SERVIDOR_ARCHIVOS: VARCHAR(200)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_ESTADODOCUMENTO
PK_ESTADO_DOCUMENTO: BIGINT
FK_TIPO_DOCUMENTO: BIGINT (FK)NO_ESTADO_DOCUMENTO: VARCHAR(20)DE_ESTADO_DOCUMENTO: VARCHAR(20)IN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TD_NOTACREDITODEBITOITEM
PK_NOTA_CREDITO_DEBITO_ITEM: BIGINTPK_DOCUMENTO: BIGINT (FK)
NU_POSICION: INTEGERCA_ITEM: decimal(12,3)CO_UNIDAD_MEDIDA: char(3)MO_IMPORTE_SIN_IMPUESTO: decimal(12,2)MO_IMPORTE_UNITARIO_SIN_IMPUES: decimal(12,2)MO_IMPORTE_UNITARIO_CON_IMPUES: decimal(12,2)DE_ITEM: varchar(100)CO_PRODUCTO: varchar(100)TI_PRECIO: char(2)MO_IMPUESTO_IGV: decimal(12,2)CO_EXONERACION_IMPUESTO_IGV: char(2)MO_IMPUESTO_ISC: decimal(12,2)TI_SISTEMA_IMPUESTO_ISC: char(2)DC_DESCUENTO: decimal(12,2)DC_CARGO: decimal(12,2)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_NOTACREDITODEBITO
PK_DOCUMENTO: BIGINT
FK_MODULO: BIGINT (FK)FK_DOCUMENTO_ELECTRONICO: BIGINT (FK)FK_TIPO_MONEDA: BIGINT (FK)FK_ESTADO_DOCUMENTO: BIGINTFK_TIPO_EMISION: BIGINTFK_TIPO_DOCUMENTO: BIGINT (FK)NU_SERIE_NUMERO: varchar(20)FE_EMISION: DATEDA_ANNIO_FISCAL: VARCHAR(10)MO_TOTAL_DESCUENTOS: decimal(12,2)MO_TOTAL_CARGOS: decimal(12,2)MO_TOTAL_AJ USTE: decimal(12,2)DE_OBSERVACION: varchar(200)MO_IMPUESTO_IGV: decimal(12,2)MO_IMPUESTO_ISC: decimal(12,2)MO_IMPUESTO_OTROS: decimal(12,2)TI_CODIGO_TRIBUTARIO_EMISOR: char(2)NU_TRIBUTARIO_EMISOR: varchar(20)TI_CODIGO_TRIBUTARIO_ADQUIRIEN: char(2)NU_TRIBUTARIO_ADQUIRIENTE: CHAR(18)NO_RAZON_SOCIAL_ADQUIRIENTE: varchar(100)NO_CORREO_ADQUIRIENTE: varchar(50)NO_RAZON_SOCIAL_EMISOR: varchar(100)NO_COMERCIAL_EMISOR: varchar(100)UB_EMISOR: char(6)DI_EMISOR: varchar(100)NO_CORREO_EMISOR: VARCHAR(50)NO_PAIS_EMISOR: char(2)NO_DEPARTAMENTO_EMISOR: varchar(30)NO_PROVINCIA_EMISOR: varchar(30)NO_DISTRITO_EMISOR: varchar(30)NO_URBANIZACION_EMISOR: varchar(25)NO_DISCREPANCIA_DOCUMENTO_AFEC: varchar(100)CO_MOTIVO_DOCUMENTO_AFEC: char(2)NU_SERIE_NUMERO_DOCUMENTO_AFEC: varchar(20)DA_IDENTIFICADOR_ERP: varchar(30)IN_ESREFERENCIADO: INTEGERMO_TOTAL_GRAVADO: DECIMAL(12,2)MO_TOTAL_NO_GRAVADO: DECIMAL(12,2)MO_TOTAL_EXONERADO: DECIMAL(12,2)IN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMPDA_COMENTARIO_RECHAZO: VARCHAR(150)
TM_MONEDA
PK_TIPO_MONEDA: BIGINT
NO_TIPO_MONEDA: VARCHAR(18)CO_TIPO_MONEDA: char(3)IN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_DOCUMENTO_ELECTRONICO
PK_DOCUMENTO_ELECTRONICO: BIGINT
FK_TIPO_DOCUMENTO: BIGINT (FK)FK_ESTADO_SUNAT: BIGINT (FK)FK_ESTADO_DOCUMENTO: BIGINT (FK)DA_OBSERVACION_SUNAT: VARCHAR(500)NO_ARCHIVO_PETICION: VARCHAR(50)BL_DOCUMENTO_ELECTRONICO: BLOB(1000)FH_INSERCION_DOCUMENTO: TIMESTAMPDA_FIRMA_ELECTRONICA: VARCHAR(3000)DA_HASH: varchar(50)FH_FIRMA_ELECTRONICA: TIMESTAMPCO_ORIGEN: VARCHAR(20)NO_ARCHIVO_RESPUESTA: VARCHAR(20)BL_ARCHIVO_RESPUESTA: BLOB(1000)CO_RESPUESTA: VARCHAR(100)DE_RESPUESTA: VARCHAR(200)FH_ENVIO_SUNAT: TIMESTAMPFH_RESPUESTA_SUNAT: TIMESTAMPDA_CODIGO_BARRAS: VARCHAR(400)NO_ARCHIVO_CODIGO_BARRAS: VARCHAR(20)NO_RUTA_ARCHIVO_CODIGO_BARRAS: VARCHAR(200)NU_VERSION_UBL: VARCHAR(10)NU_PERSONALIZACION: VARCHAR(10)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_ARCHIVO_ADJ UNTO
PK_ARCHIVO_ADJ UNTO: BIGINT
FK_DOCUMENTO: BIGINTNO_ARCHIVO_ADJ UNTO: VARCHAR(20)NO_RUTA_ARCHIVO_ADJ UNTO: VARCHAR(100)FE_EMISION: DATEUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_MENSAJ E
PK_MENSAJ E: BIGINT
NO_MENSAJ E: VARCHAR(50)NU_DOCUMENTO_ERP: VARCHAR(20)BL_MENSAJ E: BLOB(1000)IN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMPTI_CODIGO_TRIBUTARIO: CHAR(2)NU_CODIGO_TRIBUTARIO: VARCHAR(20)
TM_FACTURABOLETA
PK_DOCUMENTO: BIGINT
FK_TIPO_DOCUMENTO: BIGINT (FK)FK_TIPO_MONEDA: BIGINT (FK)FK_MODULO: BIGINT (FK)FK_DOCUMENTO_ELECTRONICO: BIGINT (FK)FK_ESTADO_DOCUMENTO: INTEGERFK_TIPO_EMISION: INTEGERNU_SERIE_NUMERO: VARCHAR(20)FE_EMISION: DATENO_CORREO_EMISOR: VARCHAR(50)DA_ANNIO_FISCAL: VARCHAR(10)MO_IMPORTE_SIN_IMPUESTO: DECIMAL(12,2)MO_IMPORTE_CON_IMPUESTO: DECIMAL(12,2)MO_TOTAL_DESCUENTOS: DECIMAL(12,2)MO_TOTAL_CARGOS: DECIMAL(12,2)MO_IMPORTE_TOTAL: DECIMAL(12,2)MO_IMPUESTO_IGV: DECIMAL(12,2)MO_IMPUESTO_ISC: DECIMAL(12,2)MO_IMPUESTO_OTROS: DECIMAL(12,2)TI_CODIGO_TRIBUTARIO_EMISOR: CHAR(2)NU_TRIBUTARIO_EMISOR: VARCHAR(20)NO_RAZON_SOCIAL_ADQUIRIENTE: VARCHAR(100)TI_CODIGO_TRIBUTARIO_ADQUIRIEN: CHAR(2)NU_TRIBUTARIO_ADQUIRIENTE: VARCHAR(20)NO_CORREO_ADQUIRIENTE: VARCHAR(50)DI_PAIS_ADQUIRIENTE: VARCHAR(100)NO_RAZON_SOCIAL_EMISOR: VARCHAR(100)NO_COMERCIAL_EMISOR: VARCHAR(100)UB_EMISOR: CHAR(6)DI_EMISOR: VARCHAR(100)NO_PAIS_EMISOR: CHAR(2)NO_DEPARTAMENTO_EMISOR: VARCHAR(30)NO_PROVINCIA_EMISOR: VARCHAR(30)NO_DISTRITO_EMISOR: VARCHAR(30)NO_URBANIZACION_EMISOR: VARCHAR(25)DE_OBSERVACION: VARCHAR(30)DA_IDENTIFICADOR_ERP: VARCHAR(30)IN_ESREFERENCIADO: INTEGERMO_TOTAL_GRAVADO: DECIMAL(12,2)MO_TOTAL_NO_GRAVADO: DECIMAL(12,2)MO_TOTAL_EXONERADO: DECIMAL(12,2)TI_MONEDA_PERCEPCION: CHAR(3)MO_PERCEPCION: DECIMAL(12,2)MO_TOTAL_CON_PERCEPCION: DECIMAL(12,2)IN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMPDA_COMENTARIO_RECHAZO: VARCHAR(150)
TM_MODULO
PK_MODULO: BIGINT
DE_MODULO: VARCHAR(100)NO_MODULO: VARCHAR(20)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_TABLA_MULTIPLE
PK_TABLA_MULTIPLE: BIGINT
NO_TABLA: VARCHAR(50)CO_ITEM_TABLA: VARCHAR(5)NO_CORTO: VARCHAR(20)NO_LARGO: VARCHAR(100)IN_HABILITADO: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_MODULOTIPODOCUMENTO
PK_TIPO_DOCUMENTO: BIGINT (FK)PK_MODULO: BIGINT (FK)
USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_HISTORIAL_ESTADO_DOCUMENTO
PK_HISTORIAL_ESTADO_DOCUMENTO: BIGINT
FK_DOCUMENTO: BIGINTFK_ACCION: BIGINT (FK)FK_ESTADO_DOCUMENTO: BIGINT (FK)DE_OBSERVACION: VARCHAR(100)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TM_CARGAMASIVA
PK_CARGA_MASIVA: BIGINT
TI_CODIGO_TRIBUTARIO: CHAR(2)NU_CODIGO_TRIBUTARIO: VARCHAR(20)NO_RAZON_SOCIAL: VARCHAR(100)FH_CARGA: TIMESTAMPCO_IDENTIFICADOR_CARGA: VARCHAR(20)FK_ESTADO_CARGA: BIGINT (FK)FK_TIPO_DOCUMENTO: BIGINT (FK)NU_CARGA_INICIAL: INTEGERNU_CARGA_ERROR_FORMATO: INTEGERNU_FIRMADOS: INTEGERNU_ERROR_FIRMA: INTEGERUSUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
TR_CARGAMASIVADETALLE
PK_CARGA_MASIVA_DETALLE: BIGINT
FK_CARGA_MASIVA: BIGINT (FK)DA_IDENTIFICADOR_DOCUMENTO: VARCHAR(25)FE_EMISION: DATEFK_ESTADO_CARGA_DOCUMENTO: BIGINT (FK)USUA_CREA: VARCHAR(25)FECH_CREA: TIMESTAMPUSUA_MODI: VARCHAR(25)FECH_MODI: TIMESTAMP
f. Diccionario de base de datos
Ver anexo2. Prototipos e Implementación
a. Portal de negocio
El usuario podrá consultar sus comprobantes de pago electrónicos accediendo al Portal de Negocios
b. Vista proveedor
i. Opción Comprobante Electrónico
IMPORTANTELas columnas del filtro proveedor solo aparece si el usuario es administrador de
grupo empresarial. En caso contrario en el filtro del proveedor solo se mostrará los datos del proveedor en modo lectura.
El filtro estado documento dependerá del tipo de documento.El campo de texto RUC del proveedor será siempre de solo lectura. Cuando se
seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente.
El filtro razón social del proveedor será un combo.Los campos de texto RUC y RAZÓN SOCIAL del cliente serán listas inteligentes.Al final de la lista de comprobantes se añadirán los campos de auditoría.
Los mensajes de validaciones tales como “Solo puede ver el detalle de un registro a la vez” se realizarán mediante ventanas modales emergentes.
Para el caso de “Boletas” el botón “Enviar comprobantes” enviará un mensaje de información.
ii. Opción Comprobante Electrónico - Botones1. Botón Registrar
a. Vía Carga de archivo
IMPORTANTEEn esta pantalla solo se podrán generar comprobantes electrónicos de tipo
Factura, Boleta, Nota de crédito, Nota de débito.Al final de la lista de registro de cargas masivas se añadirán los campos de
auditoría.Cuando se presione el botón generar comprobantes, se cerrará la página actual y
se cargarán los comprobantes generados en la opción “Comprobantes Electrónicos”
Las columnas del filtro proveedor solo aparece si el usuario es administrador de grupo empresarial. En caso contrario solo se mostrará los datos del proveedor en modo lectura. En caso contrario, en el filtro del proveedor solo se mostrará los datos del proveedor en modo lectura.
El filtro razón social del proveedor será un combo.El campo de texto RUC del proveedor será siempre de solo lectura. Cuando se
seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente
En la opción “Comprobantes Electrónicos” solo se enviarán los comprobantes de tipo Factura, Nota de Crédito y Nota de Débito.
Por recomendación del Product Manager cambiar el botón “Browse” por “Cargar”
Todas las vistas con el ícono llamarán a una pantalla de búsqueda de empresas. El ícono solo se mostrará en ambiente de desarrollo, para producción debe ocultarse el ícono.
Los mensajes de validaciones tales como “Solo puede ver el detalle de un registro a la vez” se realizarán mediante ventanas modales emergentes.
Para el caso de “Boletas” el botón “Generar comprobantes y enviar” quedará desactivado.
El botón “Generar Comprobantes” lanzará la siguiente ventana de diálogo:
El botón “Generar Comprobantes y Enviar” lanzará la siguiente ventana de diálogo:
2. Botón Imprimir
3. Botón Enviar a SUNAT
4. Botón Descargar
5. Botón Ver Detalle a. Detalle de la Factura
b. Detalle de la Factura - Botonesi. Botón Imprimir
Imprime el comprobante en formato PDF.ii. Botón Descargar
Descarga el documento XML en formato ZIP.
iii. Impresión en PDF
Factura
IMPORTANTEPara la composición de la dirección se concatenará los
siguientes campos:Dirección Completa y DetalladaDepartamentoProvinciaDistritoPara la transmisión de documento referenciados se
creará un nuevo tipo de documento referenciado para las “Órdenes de Compra”
El sub-total será mandatorio para la transmisión de comprobante electrónico.
Los campos ISC, otros tributos y otros cargos, deberán aparecer en el documento si su valor es mayor que cero.
La sección percepción deberá aparecer en el documento si su valor es mayor que cero.
El tipo de comprobante (RUC para Perú) debe ser parametrizable.Boleta
IMPORTANTEPara la composición de la dirección se concatenará los
siguientes campos:Dirección Completa y DetalladaDepartamentoProvinciaDistritoPara la transmisión de documentos referenciados se
creará un nuevo tipo de documento referenciado para las “Órdenes de Compra”
El sub-total será mandatorio para la transmisión de comprobante electrónico.
Los campos ISC, otros tributos y otros cargos, deberán aparecer en el documento si su valor es mayor que cero.
La sección percepción deberá aparecer en el documento si su valor es mayor que cero.
El tipo de comprobante (RUC para Perú) debe ser parametrizable.Nota de crédito
IMPORTANTESe copiará el motivo o asunto en la descripción del ítem
cuando este venga vacío, y el asunto no aparecerá en Observaciones del Comprobante.Nota de débito
IMPORTANTESe copiará el motivo o asunto en la descripción del ítem
cuando este venga vacío, y el asunto no aparecerá en Observaciones del Comprobante.
iii. Resumen de Boletas
IMPORTANTEAl final de la lista se añadirán los campos de auditoría.El campo de texto RUC del proveedor será siempre de solo lectura. Cuando se
seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente
Las columnas del filtro proveedor solo aparece si el usuario es administrador de grupo empresarial. En caso contrario en el filtro del proveedor solo se mostrará los datos del proveedor en modo lectura.
iv. Resumen de Boletas - Botones1. Botón Registrar
a. Vía carga de archivo
IMPORTANTEAl final de la lista de registro de cargas masivas se añadirán los
campos de auditoría.El campo de texto RUC del proveedor será siempre de solo
lectura. Cuando se seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente
Cuando se presione el botón generar comprobantes, automáticamente pasará a la opción “Resumen de Boletas” o “Resumen de Bajas”. Deberán aparecer los registros.
2. Botón Enviar a SUNAT
3. Botón Descargar
4. Botón Ver Detalle
v. Detalle Resumen de Comprobantes
IMPORTANTEAl final de la lista de detalle de resumen de comprobantes se añadirán los
campos de auditoría.vi. Resumen de Bajas
IMPORTANTEEl campo de texto RUC será una lista inteligente.Al final de la lista de registro de cargas masivas se añadirán los campos de
auditoría.Las columnas del filtro proveedor solo aparece si el usuario es administrador de
grupo empresarial. En caso contrario solo se mostrará los datos del proveedor en modo lectura.
El campo de texto RUC del proveedor será siempre de solo lectura. Cuando se seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente
vii. Opción Resumen de Bajas - Botones1. Botón Registrar
a. Vía carga de archivo
2. Botón Enviar a SUNAT
3. Botón Descargar
4. Botón Ver Detalle
a. Detalle de Resumen de Bajas
IMPORTANTEAl final de la lista de detalle de resumen de bajas de
comprobantes se añadirán los campos de auditoría.Las columnas del filtro proveedor solo aparece si el usuario es
administrador de grupo empresarial. En caso contrario solo se mostrará los datos del proveedor en modo lectura.
Al dar click en el detalle si el documento no fue publicado se mostrará un mensaje de que el documento solo existe en el resumen
“Este comprobante no puede ser mostrado porque no fue publicado en el portal”
5. Botón Ver Detalle
IMPORTANTEAl final de la lista de registro de cargas masivas se añadirán los campos de
auditoría.Aquí se mostrará la pantalla “Ver Detalle” del Comprobante de Pago
(Factura, Boleta, N/C, N/D)
viii. Opción Estadísticas de envío
IMPORTANTECuando se seleccione un registro y luego “Ver Listado” pasará a la vista de “Búsqueda de
Comprobantes” o “Búsqueda de Resumen de Comprobantes” o “Búsqueda de Resumen de Bajas”
El estado SUNAT del comprobante “EN REPROCESO” se mostrará en la tabla cuando tenga datos.
El campo de texto RUC del proveedor será siempre de solo lectura. Cuando se seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente.
ix. Configuración 1. Certificado Digital
IMPORTANTEAl final de la lista de registro de cargas masivas se añadirán los campos
de auditoría.El campo de texto RUC del proveedor será siempre de solo lectura.
Cuando se seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente.
2. Usuario Sol / Clave Sol
IMPORTANTEAl final de la lista de registro de cargas masivas se añadirán los campos de
auditoría.El campo de texto RUC del proveedor será siempre de solo lectura. Cuando se
seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente.
3. Notificacionesa. Proveedor
i. Búsqueda de Notificaciones
ii. Detalle Notificaciones
iii. Nueva notificación
iv. Búsqueda de Usuarios
v. Búsqueda de contactos
b. Clientei. Lista de notificaciones
ii. Detalle de notificaciones
IMPORTANTEEn el comprobante de pago se contemplará un correo
electrónico por parte del proveedor el mismo que servirá para enviar e-mail cuando el comprobante de pago sea declarado. En caso el correo electrónico no esté presente en el comprobante se deberá contemplar el correo electrónico que el proveedor declaró en el Portal de Negocios para este fin.
Los horarios serán configurables internamente por cada proveedor.
4. Clientes
IMPORTANTECuando se cargue el mismo cliente se sobrescribirá los datos
previamente guardados.El campo de texto RUC del proveedor será siempre de solo lectura.
Cuando se seleccione una empresa del combo razón social del proveedor este campo se rellenará automáticamente
En el comprobante de pago se contemplará un correo electrónico por parte del cliente el mismo que servirá para enviar e-mail cuando el comprobante de pago sea publicado. En caso el correo electrónico no esté presente en el comprobante se deberá contemplar el correo electrónico que el proveedor declaró en el Portal de Negocios para este fin.
a. Detalle de excel de entrada
RAZÓN SOCIAL RUC CLIENTE
ENVIAR CORREO
ADJUNTAR PDF
MAIL DE CONTACTO
Graña y Montero Digitales S.A. 5644646546
SI
SI
Cosapi S.A. 5456465464 SI SI [email protected]ña y
Montero S.A. 2311234154SI
Graña y Montero
3136546445 NO NO [email protected]
Petróleo S.A.b. Botón Descargar Configuración
RAZÓN SOCIAL
RUCCLIENTE
ENVIAR CORREO
ADJUNTAR PDF
MAIL DE CONTACTO
EMITIDOS ULTIMO AÑO
EMITIDOS ULTIMO MES
EMITIDOS ULTIMA SEMANA
VISUALIZADOS ULTIMO AÑO
VISUALIZADOS ULTIMO MES
VISUALIZADOS ULTIMA SEMANA
Graña y Montero Digitales S.A.
5644646546
SI
SI
20 231 654 654 564 321C
osapi S.A.
5456465464
SI
SI
[email protected] 2 54 54 231 564 4
Graña y Montero S.A.
2311234154
SI
SI
15 654 4 54 564 654G
raña y Montero Petróleo S.A.
3136546445
NO
NO
21 132 321 321 3213 21
c. Clientei. Comprobantes Electrónicos
ii. Comprobantes Electrónicos - Opciones1. Botón Imprimir
2. Botón Descargar
3. Botón Ver Detallea. Detalle de Comprobante
d. Administrador del Portal
5. Conclusiones
122
6. Glosario
PSE : Proveedor de servicios
123
7. Bibliografía
1. Application Integration – EAI, B2B, BPM and SOAAutor : Bernard ManouvrierEditorial : WileyAño : 2008
2. B2B IntegrationAutor : Gunjan SantaniEditorial : Imperial College PressAño : 2003
3. Building B2B applications using XMLAutor : Michael FitzgeraldEditorial : Wiley Computer PublishingAño : 2002
4. ebXML SimplifiedAutor : Eric ChiuEditorial : Wiley Computer PublishingAño : 2003
5. Innovative Tools for Business Coalitions in B2B ApplicationsAutor : Pierluigi Argoneto Paolo RennaEditorial : SpringerAño : 2006
6. Sunat – Página oficialAutor : SUNATDirección : www.sunat.gob.pe
124
8. Anexo
8.1. Diccionario de datos
125