Implementacin de un Sistema de Comprobantes de pago Electrnico utilizando Web Services para los Emisores (Empresas medianas y grandes)

Tesis de Ingeniera

Peralta Nouchi, Jos Luis Sosa Navarro, Carlos Alberto

Lima, 17 de Octubre de 2010

Peralta Nouchi, Jos Luis Sosa Navarro, Carlos Alberto

Implementacin de un Sistema de Comprobantes de pago electrnico 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 Ttulo de Ingeniero de Sistemas Orientador: Luis Roig de Alcazar

UNMSM LIMA AGOSTO 2012

 Sosa Navarro, Carlos Alberto Peralta Nouchi, Jos Luis 2012. Todos los derechos reservados.

Mi tesis se la dedico con todo mi amor y cario. A ti Dios que me diste la oportunidad de vivir y de regalarme una familia maravillosa

AGRADECIMIENTOS
Al profesor Luis Alarcn Loayza por su orientacin y dedicacin 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. Tambin le agradezco a mi Padre por ayudarme a identificar la problemtica planteada en este documento y su consejo como economista y proyectista. A todas las personas que ayudaron de forma indirecta en la elaboracin 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 investigacin. Y por encima de todo doy gracias a Dios, por su gua y sostn.

Implementacin de un Sistema de Comprobantes de pago Electrnico utilizando Web Services para los Emisores (Empresas medianas y grandes)

Resumen El propsito de esta tesis es el de implementar un sistema de

Contenido
Contenido.................................................................................................................... 8 CAPITULO 1 INTRODUCCIN....................................................................................10 Ttulo de la Tesis.................................................................................................... 10 Antecedentes......................................................................................................... 10 Definicin del Problema..........................................................................................10 Objetivos................................................................................................................ 11 Justificacin............................................................................................................ 11 Alcances ............................................................................................................... 12 CAPITULO 2 - Marco Terico.......................................................................................14 B2B (Business to business).....................................................................................14 B2B, B2C, C2C, A2A.............................................................................................14 EAI...................................................................................................................... 15 Integrando intercambios inter-empresariales (B2B).............................................16 Acoplando A2A y B2B: A2B (o colaboracin de negocios)....................................16 Arquitectura orientada a Servicios (SOA).............................................................17 Seleccin de la arquitectura de intercambio........................................................19 XML 22 La necesidad de un lenguaje universal................................................................23 EDI...................................................................................................................... 23 XML: el Lenguaje Universal de intercambio de datos...........................................24 La coexistencia de XML y EDI..............................................................................29 Seguridad en Internet.............................................................................................38 Seguridad en Internet crtica para el B2B...............................................................38 Estrategia E-Security..............................................................................................38 Servicios bsicos de seguridad en B2Bi..................................................................39 Conceptos clave en las soluciones de e-Seguridad.................................................40 Criptografa............................................................................................................ 40 Cifrado de clave privada.........................................................................................41 Cifrado de clave pblica.........................................................................................41 La firma digital....................................................................................................... 42 Creacin de una firma digital..................................................................................42 Los certificados digitales y el papel de autoridades de certificacin (CA)................44 Componentes de Integracin..................................................................................45 Los componentes y las operaciones de la arquitectura SOA...................................45 Servicios Web (Web Services)................................................................................46 Caractersticas esenciales de un entorno de servicios Web....................................47 Universal Description, Discovery and Integration (UDDI)........................................48 Web Services Description Language (WSDL)..........................................................48 WSDL schema........................................................................................................ 48 WSDL y UDDI..........................................................................................................49 Poniendo todo junto............................................................................................... 49 SUNAT....................................................................................................................50 Qu es la SUNAT?..............................................................................................50 Funciones y atribuciones de la SUNAT.................................................................50 Comprobantes de Pago - Concepto......................................................................52 CAPITULO III - Estado del Arte....................................................................................64 Caso Guatemala:....................................................................................................64 Caso Chile:............................................................................................................. 67 Aporte terico............................................................................................................76 Anlisis................................................................................................................... 76

Requerimientos funcionales................................................................................76 Requerimientos no funcionales............................................................................84 Modelo de procesos.............................................................................................86 Diagrama de Casos de Uso..................................................................................87 Arquitectura...........................................................................................................95 Diseo..................................................................................................................100 Conclusiones........................................................................................................... 129 Glosario................................................................................................................... 130 Bibliografa.............................................................................................................. 131 Anexo...................................................................................................................... 132

CAPITULO 1 INTRODUCCIN Ttulo de la Tesis

Implementacin de un Sistema de Comprobantes de pago Electrnico utilizando Web Services para los Emisores (Empresas medianas y grandes)

Antecedentes
Una factura es el justificante fiscal de la entrega de un producto o de la provisin 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 emisin. La factura electrnica es el equivalente digital y evolucin lgica de la tradicional factura en papel. A diferencia de esta, se emplean soportes informticos para su almacenamiento en lugar de un soporte fsico como es el papel. En los pases en los que la legislacin lo admite, la validez de una factura electrnica 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 confirmacin que su propia existencia. En lo que respecta a Per, la Superintendencia Nacional de Administracin Tributaria (SUNAT) debe recabar informacin sobre los contribuyentes y eso lo hace de manera electrnica pero tambin de manera manual, debido a la enorme cantidad de comprobantes de pago que se generan entre empresas en el mercado. Estos documentos tienen una informacin importante que la SUNAT podra recabar de manera ms rpida si estuviesen en formato electrnico, y es por ello que desde hace algn tiempo ha comenzado un programa de facturacin electrnica mediante el cual los contribuyentes ya no emitirn comprobantes fsicos sino electrnicos. El proceso involucra no solo a la SUNAT y a los contribuyentes, sino tambin a los proveedores de las soluciones que harn que las empresas pueden emitir este tipo de documentos. Conversamos con ellos y recabamos informacin 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. Tambin conversamos con un implementador local.

Definicin del Problema

El proceso de Facturacin tradicional adolece de diversas imperfecciones entre ellas tenemos costos, demora, control, entrega, almacenamiento, riesgo de fraude y evasin fiscal en el proceso de generacin de las facturas de los Emisores y su envo a la SUNAT . Estas limitaciones se traducen en la baja productividad del rea de Tesorera de las empresas Emisoras al realizar actividades manuales de impresin, almacenaje y distribucin de los comprobantes de pago fsicos 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.

Objetivos
Optimizar los procesos de facturacin y recepcin de comprobantes de pago electrnicas de El Emisor, mediante el uso de Web Services, que integrar y facilitar el intercambiando de informacin con SUNAT, sus clientes y proveedores, lo que les permitir incrementar su eficiencia operativa. Estructurar la informacin de los comprobantes de pago de El Emisor en el formato indicado por SUNAT (XML) para ser considerado comprobante de pago electrnico. Brindar transparencia al Emisor con el Sistema SUNAT. Facilitar la transmisin de los comprobantes de pago electrnicos emitidos por El Emisor a SUNAT y retornar la constancia de recepcin emitido por SUNAT. Poner a disposicin de El Emisor un portal web para publicar el detalle de la informacin de sus comprobantes de pago emitidos electrnicamente, de acuerdo a lo normado por SUNAT; facilitando el acceso a dicha informacin a cada uno de sus clientes. Facilitar el registro de la informacin de los comprobantes de pago electrnicos 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 electrnicos. Aumentar la productividad del rea de Tesorera al eliminar actividades manuales de impresin, almacenaje y distribucin de los comprobantes de pago fsicos. As mismo, se puede reducir considerablemente las consultas telefnicas o personales de los proveedores interesados en la confirmacin del registro de sus comprobantes de pago y de manera opcional sobre la programacin de pagos y detalles de sus pagos. Integrar a El Emisor a la comunidad electrnica empresarial, lo que permitir el desarrollo de actividades colaborativas.

Justificacin
La importancia de implementar un sistema que permita operar con factura electrnica nace de la innegable necesidad de otorgar validez legal al ejemplar electrnico de documentos tributarios de compra y venta tales como facturas, boletas, notas de crdito, notas de dbito, ya que con ello se optimiza la operacin de las empresas y de la SUNAT. En tal sentido con el nuevo sistema, las empresas (Emisores) podrn electrnicamente generar, firmar, transmitir y almacenar comprobantes de pago, reduciendo los costos del proceso de facturacin, y permite incorporar grandes mejoras en su operacin 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 Administracin Tributaria (SUNAT) le permitir recabar informacin sobre los contribuyentes de manera ms rpida, segura y eficiente para fiscalizar mejor los crditos y dbitos, mejorar el control sobre el traslado de bienes con documentos vlidos para la fiscalizacin, optimizar el control del IGV y otorgar mejores servicios, con informacin de mejor calidad, a los contribuyentes. Adems esto permitira al pas generar ahorros cercanos al 80% sobre los costos del

sistema tradicional, se mejorara la competitividad del pas, se impulsara el comercio electrnico, y se impulsaran las compras electrnicas del Estado. La importancia de implementar un sistema que permita operar con factura electrnica nace de la innegable necesidad de otorgar validez legal al ejemplar electrnico de documentos tributarios de compra y venta tales como facturas, boletas, notas de crdito, notas de dbito, ya que con ello se optimiza la operacin de las empresas y de la SUNAT. En tal sentido con el nuevo sistema, las empresas (Emisores) podrn electrnicamente generar, firmar, transmitir y almacenar comprobantes de pago, reduciendo los costos del proceso de facturacin, y permite incorporar grandes mejoras en su operacin 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 Administracin Tributaria (SUNAT) le permitir recabar informacin sobre los contribuyentes de manera ms rpida, segura y eficiente para fiscalizar mejor los crditos y dbitos, mejorar el control sobre el traslado de bienes con documentos vlidos para la fiscalizacin, optimizar el control del IGV y otorgar mejores servicios, con informacin de mejor calidad, a los contribuyentes. Adems esto permitira al pas generar ahorros cercanos al 80% sobre los costos del sistema tradicional, se mejorara la competitividad del pas, se impulsara el comercio electrnico, y se impulsaran las compras electrnicas del Estado.

Alcances
El mdulo de Comprobantes de Pago Electrnico est orientado a facilitar el intercambio de informacin, entre El Cliente, la Superintendencia Nacional de Administracin Tributaria (SUNAT), sus clientes y proveedores, adems de brindar una plataforma donde puedan realizar seguimiento directo y en lnea de los comprobantes de pago electrnicos. La informacin de los comprobantes de pago emitidos por El Cliente ser trasferida a SUNAT, a fin de que sea validada y cumpla con los parmetros requeridos para que el comprobante de pago electrnico sea considerado como conforme. El Cliente podr transmitir sus comprobantes de pago electrnicos a sus clientes de distintas formas: 1. Directamente al sistema comercial de su cliente (mediante una integracin de punto a punto). La informacin puede ser pre-registrada en el sistema ERP de su cliente para facilitar su procesamiento. 2. En formato PDF, mediante un correo electrnico designado por su cliente. 3. Adems, de poner la informacin a disposicin en la plataforma para una descarga (impresin) directa por parte del cliente. El Cliente podr llevar un control del estado de sus comprobantes de pago electrnicos:

SUNAT Aceptado Aceptado C/ Obs. Rechazado Documento Emitido Visualizado

Aceptado

De la misma manera, El Cliente podr recibir la informacin de los comprobantes de pago electrnicos de sus proveedores, facilitando su procesamiento mediante el preregistro o registro directo en su sistema ERP. De manera opcional1 se puede: Realizar validaciones previas a la informacin a ser enviada por los proveedores, basadas en la informacin de las rdenes de compra, confirmaciones de ingresos de mercadera recibida y/o aceptacin de servicio recibido, evitando as recibir facturas que no coincidan con la informacin base, registrada en su ERP, para el procesamiento de la factura. Mostrar al proveedor informacin sobre la programacin de pago y el detalle de los pagos (moneda, banco, descuentos) cuando stos se realicen. Con esta solucin 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 informacin en el portal. El alcance geogrfico del servicio abarca las operaciones de El Cliente en Per con todos sus proveedores a nivel nacional.

CAPITULO 2 - Marco Terico B2B (Business to business)

El significado del acrnimo 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 travs de internet y usando comunicacin instantnea para hacer que estas empresas o negocios no solo incrementen ventas sino la capacidad de trabajar de forma ms sinrgica, rpida y barata. B2B, entonces se refiere a negocios trabajando con otros negocios para incrementar sus ganancias y acerca de organizaciones y gobiernos comunicndose rpidamente y eficientemente. Esto significa intercambio de documentos, como rdenes de compra, facturas, listas de precios, artculos cientficos, legislaciones y no por va terrestre o mail, sino a travs de la red. En vez de pilas de papel desbordando cajones de escritorio, se usan documentos electrnicos almacenados en unidades de disco, que se pueden imprimir a voluntad en el momento deseado. B2B trata tambin de acuerdos legales firmados digitalmente en diferentes continentes, hacindose efectivos en minutos en vez de semanas. Tambin 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 rpido como el Internet pueda, lo cual generalmente no tarda ms 1 segundo o 2. Los negocios se hacen ms rpido, ms eficientemente, ms 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 tecnologas ms importantes relacionadas al comercio B2B es Extensible Markup Language, o XML. XML subyace la mayora, sino todas las tecnologas que soportarn el nuevo modelo de negocios B2B.

B2B, B2C, C2C, A2A

Estos trminos son muy usados en estos tiempos. Veamos, B2C hace referencia a Negocio a Cliente. Esto hace referencia a la interaccin directa entre clientes y negocios a travs de internet, tales como ordenar un producto a un proveedor por internet. Ese negocio podra ser un fabricante de productos como Dell, que vende directamente a sus usuarios o tambin 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 acrnimo de cliente a cliente. Este tipo de acuerdos hacen posible la compra de productos en unidades singulares o pequeas 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 rpido. A2A es el acrnico de aplicacin a aplicacin. Lo que quiere decir que una aplicacin puede comunicarse directamente con otras aplicaciones, usualmente a travs de la red. Como el nombre implica, el proceso es automtico y requiere la no intervencin humana. Aunque esto puede tambin requerir interaccin humana, uno de los objetivos principales de B2B es organizar a los sistemas de tal forma que puedan comunicarse con otros automticamente.

EAI
El trmino EAI apareci por primera vez en USA alrededor de 1996-1997 con la publicacin de artculos de investigacin por grandes firmas incluyendo Roy Schulte de Gartner Group. Estos estudios analizaron los enfoques encontrados en un determinado nmero de empresas grandes para explicar la emergencia de un rango de problemas de integracin, los cuales predijeron se convertira en uno de los problemas ms importantes de los prximos 10 aos. Sin embargo, si el trmino EAI fue inventado, conceptualizado, y trado al mercado por norte americanos, los precursores en este asunto fueron los franceses. EAI es una coleccin de mtodos, herramientas y servicios que trabajan juntos para permitir la comunicacin entre aplicaciones heterogneas, como parte de la empresa tradicional, distribuida o extendida. En otras palabras, el problema esencial a resolver es el intercambio de informacin entre las aplicaciones en sistemas de informacin, y ms especficamente, a responder la pregunta, cmo nosotros podemos asegurar que aplicaciones heterogneas, diseadas en diferentes periodos, por diferentes e quipos y usando diferentes tecnologas, 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 confusin aparece. EAI no es la manera concerniente a la comunicacin interna de una aplicacin. El problema de comunicacin entre los componentes de una aplicacin cliente/servidor no cae en el dominio de EAI. Ese es el problema de la arquitectura de la aplicacin. Sin embargo, la manera en que este sistema cliente/servidor se comunica con otras aplicaciones constituye un verdadero problema EAI. Tambin podemos decir que EAI concierne a la comunicacin entre aplicaciones heterogneas. Aplicaciones que comparten repositorios y usan semnticas comunes y tecnologas idnticas no representan un problema de integracin con uno y otro. En otras palabras, aplicaciones homogneas ya estn integradas. Desplegar los mtodos 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 tecnologas, y las cuales son incapaces de comunicarse naturalmente una con otra. EAI por lo tanto se ocupa de dominio ms antiguo en integracin: el dominio de aplicaciones de negocio Application to Application (regularmente llamado AtoA o A2A). Esto es tpicamente el dominio de integracin con ERP, o la integracin de aplicaciones de frente de oficina con las aplicaciones de fondo de oficina, o la integracin de gestores de relacin con el cliente (CRM), y gestores de cadena de suministro (SCM), etc.

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 travs de EDI. El soporte tcnico para estos intercambios puede tomar la forma de implementacin de funciones automatizadas de intercambio de archivos. Otra vez, los precursores en esta materias fueron las corporaciones francesas, como NETSYS con Inter, y otras ms. Dibujando una paralela con la definicin de EAI, nosotros podemos decir que la integracin B2B es una coleccin de mtodos, 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 integracin inter-empresarial es por lo tanto una extensin de un conjunto de problemas de EAI, y por lo tanto permanece fundamentalmente adjunta a la capacidad de intercambiar informacin entre aplicaciones heterogneas que no pertenecen a los mismos sistemas de informacin, desde que pertenecen a diferentes empresas. Nosotros podemos por lo tanto decir que la integracin B2B corresponde a integracin inter-empresarial A2A. Las diferencias fluyen esencialmente sobre lo que la empresa no puede controlar: - La red de comunicacin - El formato de intercambio - El proceso de intercambio

Acoplando A2A y B2B: A2B (o colaboracin 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 ms 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 subcontratistas. - Los dominios de responsabilidad empiezan a incrementar ms de forma horizontal debido al intra/inter-empresarial. La conciencia de la unin de los dos enfoques es relativamente nueva e implica algunos puntos especficos. Nos referimos a ella como A2B ("Aplicacin a Negocios"), aunque cada vez ms, se conoce bajo la colaboracin empresarial a largo plazo.

Arquitectura orientada a Servicios (SOA)

La implementacin de una arquitectura de servicios no est directamente asociada con el tipo particular de integracin, aunque esto a veces dibuja sus orgenes en el problema de integrar aplicaciones complejas o en otros casos, sigue y ayuda el alcance BPM. Este tipo de integracin 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 discusin alrededor del tema de integracin en los aos ms recientes. De hecho, con la explosin de Internet, B2C y sus intercambios han sido multiplicados, requiriendo la implementacin de nuevas aplicaciones que usan tecnologas web como navegadores, HTML, servidores HTTP, SMTP, aplicaciones java, etc. La necesidad de integrar estas aplicaciones en los sistemas de informacin existentes aparece como un elemento crucial en la capacidad de las empresas para responder rpidamente a demandas del consumidor en el acceso online a catlogos, 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, ms rpido, y ms barato. Un tpico ejemplo de este tipo de problemas es la implementacin de portales de ventas en internet, los cuales requieren, por ejemplo, consultas de inventarios en tiempo real y actualizaciones, tanto como la interaccin con aplicaciones de gestin de clientes. Ver figura.

Ejemplo de integracin con el cliente. En este punto podemos definir a la integracin B2C como un conjunto de mtodos, herramientas y servicios que trabajan juntos para permitir que aplicaciones heterogneas 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 integracin con consumidores son similares a los mencionados en la integracin de aplicaciones en la empresa: en ambos A2A y B2C, las aplicaciones deben ser capaces de intercambiar informacin unas con otras. Sin embargo, en B2C, una de estas aplicaciones es construida desde datos y servicios en aplicaciones existentes, y es esta aplicacin la que maneja la interface de cara al usuario. Desafortunadamente, desde que las aplicaciones existentes no fueron originalmente diseadas para responder a este tipo de peticin, de tal forma que ambas aplicaciones deben ser adaptadas o soluciones de integracin 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 reaccin en sistemas de informacin distribuidos, heterogneos, por medio de la presentacin de una nueva manera de integrar y manipular los diferentes ladrillos y componentes de la aplicacin 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 diseo de software cliente/servidor. Similarmente, arquitecturas distribuidas e invocacin a mtodos remotos como son DCE o CORBA tambin manejan la nocin de servicio. De hecho, estas 2 ltimas tecnologas inspiran SOA en casi toda su comprensin. Sin embargo, estos modelos han sufrido desde la ausencia de estndares de intercambio, los cuales explican porque en enfoque genuino de SOA tuvo que esperar a la aparicin de tecnologas vinculadas a los servicios web. Esto concluye la presentacin general de la amplitud de problemas en integracin de aplicaciones. Lo que queda pendiente es examinar las diferentes funciones que esta solucin puede proveer de tal forma que se gestionen las necesidades y restricciones identificadas. Estas funciones puede ser delineadas en 3 niveles: - Transporte y conectividad - Adaptacin de la informacin - Automatizacin de los procesos. Es tambin necesario determinar si la mejor arquitectura de intercambio es centralizada o distribuida.

Componentes en la infraestructura de integracin

Seleccin de la arquitectura de intercambio

Tipos de distribucin fsica para servicios de integracin de aplicaciones Una vez que los lmites del proyecto han sido determinados, el dominio integracin objetivo, los tipos de aplicaciones a ser integrados, la cartografa los intercambios, recin podemos abordar la pregunta sobre el tipo comunicacin a usar entre las aplicaciones a ser integradas y la arquitectura intercambio a ser usado en este proyecto. de de de de

Comunicacin sncrona/asncrona
Los resultados de la integracin entre aplicaciones no deben recrear un sistema spaghetti dentro de la solucin de integracin. Buscando mantener el sistema de informacin flexible y reactivo, perdiendo acoplamiento entre estas aplicaciones para ser favorecidos. Ms all de eso, un estudio minucioso de los diferentes tipos de integracin nos confirman esto: integracin por propagacin de datos o integracin de procesos de mltiples pasos solo implementan interacciones asncronas y unidireccionales. En este caso, preferimos usar comunicacin asncrona, como son MOMs o gestores de archivos de transferencia. Slo la integracin de aplicaciones compuestas necesita interacciones sncronas y bidireccionales por las cuales nosotros deberamos usar tecnologas como puentes DBMS, ORBs (intermediarios de peticin de objetos), llamadas RMI (invocacin remota), o tanto actualmente tambin, llamadas a servicios web como parte del enfoque SOA.

Arquitectura centralizada o distribuida

Una vez que el tipo de comunicacin ha sido determinado, se debe abordar el tema de la seleccin de la arquitectura de intercambio. La eleccin de esta arquitectura podra, adicionalmente, influenciar directamente en la eleccin de herramientas que van a participar ms adelante. 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 mquinas, esta arquitectura, designada hub and spoke en la terminologa 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 contencin en el sistema de informacin.

Arquitectura Hub and spoke Arquitectura distribuida Una arquitectura distribuida comparte la infraestructura sobre un conjunto de mquinas que soportan las aplicaciones a ser integradas, con cada aplicacin conectando localmente a esa infraestructura a travs de adaptadores. Esta arquitectura no introduce ningn punto de fallo o contencin. 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 supervisin y mantenimiento de estos componentes en las diferentes plataformas.

Arquitectura BUS

Dado que la distribucin puede trabajar a nivel de los servicios de integracin en s, de este modo, nos encontramos en presencia de una arquitectura de tipo bus (ver Figura). Los servicios de integracin, por lo tanto se distribuyeron en lo que asegura una "Engranaje" de la infraestructura de cambio, haciendo la solucin ms robusta (no SPOF (punto nico de fallo) de servicio en la ruta crtica). Esto tambin puede llevarse a cabo mediante el despliegue de mltiples plataformas de integracin en el sistema, la creacin 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 estndar con otras entidades de gran parte de la empresa. Esta es una ilustracin operativa de manejar la gama de problemas en la A2B, o de colaboracin de negocios.

Arquitectura Snowflake Una vez el tipo de arquitecta ha sido determinado, el siguiente paso considera la eleccin de las herramientas que construirn o harn posible la infraestructura. La opcin ser guiada por el conjunto completo de resultados del anlisis bajo diferentes puntos foco que examinamos, y hace posible responder a las necesidades detectadas y restricciones.

XML

La necesidad de un lenguaje universal

Con el fin de participar en el comercio electrnico B2B, las empresas se estn moviendo hacia la auto-servicio del cliente, integracin de aplicaciones empresariales y la asociacin dinmica 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 pginas 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 mximo la automatizacin, tanto interna como externamente, que permita una comunicacin fluida entre las aplicaciones internas y aplicaciones externas asociadas. Como resultado, la mayora de los departamentos de tecnologa de la informacin dedican ms del 40% de su tiempo en la extraccin, volver a la definicin y actualizacin de datos para atender las necesidades especficas, de acuerdo con un reciente estudio de Forrester Research. Es imposible soar siquiera de B2Bi basado en la Internet, sin un lenguaje universal que se entiende por todas las partes implicadas en la integracin. A travs del uso de esta lengua, las empresas podrn realizar transacciones comerciales a travs de fronteras organizacionales. Su uso en el intercambio de datos entre las aplicaciones de negocio de la organizacin 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 beneficiarn enormemente gracias a su colaboracin 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 transicin al lenguaje universal de formato de datos para que sea un xito. As, adems de la adopcin por las empresas Fortune 1000, que tambin tiene que ser aceptada por un estimado de 25.000.000 de pequeas y medianas empresas (PYME) en el mundo. Repasemos brevemente Electronic Data Interchange (EDI), un mtodo tradicional - y sigue siendo la forma dominante de las empresas de intercambio de informacin por va electrnica.

EDI
Electronic Data Interchange, o EDI, es un formato para el intercambio electrnico y el comercio que ha evolucionado dentro de estndares nacionales e internacionales (ANSI x12, ISO 9735, y UN/EDIFACT). Un nmero mayor de corporaciones han adoptado EDI, pero este todava no se ha trasladado a empresas ms pequeas por costos y otras barreras. Mientras una compaa se puede beneficiar de la reduccin de costos de transacciones a travs de EDI, este debe tambin ser capaz se compensar la factura de consultora, infraestructura y mantenimiento. Incluso el costo de la sola especificacin EDI, acumulando miles de dlares, puede ser suficiente para alejar a los ms pequeos 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 estn en la va a considerarse en el vocabulario XML, teniendo ejemplos como OBI. EDI es un formato que va a permanecer en el mercado y todava no tiene visos de ser reemplazados por XML es un futuro cercano.

Como funciona EDI

EDI funciona proporcionando una coleccin de formatos de mensaje estndar y un diccionario de los elementos que se pueden intercambiar a travs de cualquier servicio de mensajera electrnica. 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 mtodos, por lo que el programa de acceso universal. Como resultado de la norma, todas las empresas con participacin de IED un lenguaje de intercambio comn, lo que minimiza la necesidad de cambio en los sistemas internos de procesamiento de datos.

EDI basado en la comunicacin entre diferentes partners. El trfico 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 segn 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.

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 heterogneas se refiere. El uso de XML hace que sea bastante fcil 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 travs 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 electrnico 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 rpidamente todo su in-formacin 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 ms potentes de B2Bi, permitiendo a los sistemas para compartir datos y aportar un valor aadido 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 compaa 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 estndar de su industria).

Qu es XML?
XML es un lenguaje desarrollado por el W3C para la presentacin visual de informacin 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 diseada principalmente para slo la presentacin de las pginas de hipertexto en los navegadores, XML, por el contrario, est diseado para crear nuevos lenguajes de marcado para la nueva tipos de documentos. HTML restringe a los usuarios a slo 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 informacin en su dominio particular contexto, o en el campo. Creacin de tipos de documentos, la etiqueta conjuntos, la creacin 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 especificacin 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 travs de anidacin simple y referencias. Por lo tanto XML no slo especifica los elementos de datos, sino tambin su semntica. Sin embargo, el XML es simplemente un lenguaje de definicin de datos, no una tecnologa. XML no puede por s misma integrar los diferentes sistemas. XML permite al usuario: definir sus propias etiquetas especificar la semntica del documento; formar un solo archivo, compuesto de lgica, reuniendo a mltiples archivos; proporcionar procesamiento de la informacin a la aplicacin 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 comunicacin, junto con otras soluciones de seguridad; aadir comentarios a la edicin de un archivo XML; Tener bsquedas ms rpidas y la recuperacin de documentos, ya que es ms fcil disponer en un repositorio XML indexados, y Identificar la ubicacin 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 produccin de determinados tipos de texto documentos.

XML fortalezas

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, grficos e imgenes, recursos de audio y vdeo y pginas web. Permite concordancia semntica entre los socios comerciales XML permite la creacin de concordancia semntica entre las compaas de intercambio de documentos XML, proporcionando una asignacin, transformaciones y referencias cruzadas en el documento. A travs de un flujo de trabajo XML, que puede ser distribuido a todos los socios comerciales, o puede estar en funcin de cada socio, las empresas tambin se puede definir la tramitacin de este documento XML mediante la identificacin de las actividades, procesos y tareas. Vocabularios especficos de dominio XML permite a los vocabularios de construccin especficos de dominio para la industria horizontal y vertical para, entre otros, la publicidad, el comercio financiero y electrnica. Estos vocabularios estandarizar el proceso de comunicacin entre los socios de negocios. Varias compaas tambin estn desarrollando internos vocabulario para describir los procesos corporativos de datos internos. Auto-describe e interpreta XML es legible para seres humanos, la auto-descripcin del lenguaje. Sin ningn 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 relacin se puede describir de forma explcita a travs de las definiciones de tipo de documento (DTD) o implcitamente a travs del contexto del elemento. La disociacin de las aplicaciones y los datos tambin permite a los cambios en las transacciones, sin ningn tipo de cambio que se requiere en las aplicaciones subyacentes, con slo cambiar el DTD. Propietario, as como de la industria DTD estndar (XML / EDI, RosettaNet, etc) se puede utilizar, dependiendo del requerimiento y la disponibilidad. Simple Puesto que el XML est basado en texto, es muy fcil de comprender y entender los documentos XML, su estructura,

contenido, elementos y relaciones. Esto hace que sea ms fcil 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 fcil distinguir que la primera instancia de Orange es en el contexto de la fruta y la segunda aparicin es en el contexto de color. 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 grfica 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 slo algunos. Programas que estn debidamente codificados para analizar ciertos documentos XML pueden incluso entender los lenguajes que utilizan un conjunto de caracteres diferentes, como el rabe o el japons. Esto permite el intercambio de informacin, no slo entre los diferentes sistemas informticos y aplicaciones, sino tambin en todos los idiomas y pases. Estndar abierto y comn XML se basa en estndares abiertos comunes, lo que le separa del navegador de propiedad, programas de anlisis, editores, etc. Esta es una de las grandes ventajas de XML. Nivel de compresin alto La compresin 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 compresin de documentos XML es mucho mejor que un documento de texto estndar como el ltimo es generalmente menos estructurada. XML limitaciones

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 ms lento que el EDI. Este gran flujo de datos a travs 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 bsqueda de cualquier a cualquier conectividad. Diferentes estndares Varias organizaciones y empresas estn promoviendo sus propios sabores de los estndares XML. Esto se suma a una gran confusin en el mercado sobre los problemas de interoperabilidad. XML es slo una tecnologa en evolucin y hay varias piezas que estn siendo desarrollados Interpretacin semntica limitada Dos empresas para poder intercambiar datos basados en XML, que necesitan llegar a un acuerdo explcitamente en la semntica del documento, como las definiciones de las etiquetas. Documento XML por s misma no proporciona mucha informacin acerca de cmo interpretarla. No facilita la transformacin 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 aplicacin a otra. Sin embargo, el XML es ms que otro formato de datos en la pltora de formatos utilizados por una empresa. XML namespaces Segn el W3C, un espacio de nombres XML es una coleccin 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 travs de Internet. La coexistencia de XML y EDI

EDI ha ayudado a las empresas de los ltimos aos 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 difciles. Si nos quedamos con el EDI? Si nos trasladamos a la evolucin de la tecnologa de XML? Hay que tratar de conseguir EDI y XML para intemperante? Los estndares de XML definidos para nuestra industria? EDI basado en XML XML / EDI es una evolucin, no una revolucin. XML y EDI son dos esencialmente los datos y metadatos encapsulados en formatos tokenizados y estructuras. Por lo tanto, las estructuras y mtodos de EDI se puede expresar en sintaxis XML y viceversa (vase la Figura 6.4 y Figura 6.5). XML / EDI tambin 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 seala su aprobacin - esto podra ser por ejemplo una firma digital. La orden de compra aprobada puede ser enviado de vuelta a la aplicacin del proveedor como un archivo sin formato EDI. De este modo, los mensajes legibles tanto humanos como mquina que se crean por un ser humano o una aplicacin, puede viajar a travs de una organizacin y puede ser enviado a otra organizacin y el interruptor entre los seres humanos y aplicaciones. Cabe sealar que una de las objeciones a envolver un mensaje EDI en un formato XML es que un montn de gastos generales se crea en el mensaje. Caractersticas de XML/EDI Mensajes XML / EDI consiste en una fusin de etiquetas XML y EDI y datos. Pueden transmitirse a travs de Internet, como puros mensajes XML o en la camioneta como los mensajes EDI. Todos los navegadores web actuales que soportan XML tambin debe apoyar XML o mensajes EDI. Informacin de EDI en un mensaje de XML / EDI est explcitamente etiquetados con los nombres de etiquetas. DTD que contienen la declaracin de la estructura y los conjuntos correspondientes de los valores de cdigo se puede hacer referencia a travs de Internet. XML / EDI es una fusin de muchos conceptos. XML / EDI:

 Utiliza el XML y XSL para el intercambio de datos y presentacin, respectivamente; Proporciona un estndar para documentos de formato; Se puede integrar con los mtodos tradicionales de intercambio electrnico de datos (EDI) Se puede utilizar con todos los mecanismos de transporte estndar de Internet, tales como el encaminamiento IP, HTTP, FTP y SMTP; Utiliza las herramientas modernas de programacin tales como Java y ActiveX para permitir que los datos sean compartidos entre los programas y Utiliza tecnologas de agentes para la manipulacin de datos, el anlisis, mapeo y bsqueda Ventajas de XML / EDI sobre EDI tradicionales XML / EDI es ms dinmico, menos costosa y ms simple que el EDI tradicional. Reduce significativamente los costos de entrada para las empresas pequeas y medianas empresas, que no pueden permitirse costosos basada en EDI de comunicacin. Estndares XML reducir significativamente el nmero de socios comerciales especficas de los mapas necesarios. XML transforma tareas estticas EDI como la gestin de inventario y planificacin de la produccin en los procesos dinmicos, mediante el uso de tiempo real, codificados en XML, la informacin obtenida directamente de los clientes y los proveedores de sistemas de negocio. XML / EDI no requiere grandes cambios en la capa de aplicacin que se produce y consume los datos, ya que mantiene la estructura de informacin de EDI intacto. La transicin de EDI a XML utilizando XML / EDI se realiza ms en las capas de transporte. La arquitectura abierta de XML permite el apoyo de mltiples estndares. XML / EDI a travs de Internet ofrece a las empresas de comercio electrnico ms barato y ms inteligente de mensajes a travs de navegadores. XML / EDI permite realizar bsquedas contextuales e inteligente a travs de Internet, ya que ajusta el texto no estructurado con datos estructurados en el mismo documento. Esta forma de etiquetado hace que las bsquedas sean muy eficientes y precisas. Normas/estndares XML para e-business En el mundo en expansin de comercio electrnico B2B, las empresas tienen que pensar de manera global. Sin el comercio electrnico mundial las normas no puede haber negocio sin fisuras entre las empresas repartidas por todo el mundo. Estas normas son un conjunto comn de definiciones

especficas 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 comn basado en XML B2B Estndar, que va a definir los formatos de documentos, la informacin permitida y descripciones de procesos. Estas normas son como moneda comn para la realizacin 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 comunicacin sobre la base de estas normas ser aceptado y entendido por cualquier otra empresa que utiliza los mismos estndares. La necesidad de que toda la industria (industrias verticales) B2B de comercio electrnico se est convirtiendo en normas cada vez ms importante y evidente. Varias organizaciones han estado trabajando para definir estas definiciones de mercado del segmento especfico. Normas tales como RosettaNet y OASIS estn haciendo posible que las empresas a compartir informacin con otros sin tener que redisear por completo sus aplicaciones internas. Estas normas automatizar el flujo de informacin a travs 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 estndares XML B2B son: RosettaNet - una coleccin de protocolos de intercambio que definen los productos, los socios y las transacciones de negocio para los componentes electrnicos y la industria de tecnologa de la informacin; Productos financieros (Lenguaje de marcado FpML) - un estndar para la industria financiera; Comercio Electrnico 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 comunicacin constante de los documentos de negocios entre aplicaciones de adquisicin, centros de comercio electrnico y proveedores, y BizTalk Framework - un conjunto de directrices para la aplicacin de un esquema XML y un conjunto de etiquetas XML que se utilizan en los mensajes enviados entre aplicaciones. Electronic Business XML (ebXML) ebXML es un conjunto de especificaciones que juntas permiten una estructura modular, electrnica de negocios se ha completado. ebXML es un conjunto completo de especificaciones para ofrecer

seguridad, negocio global, electrnica utilizando estndares probados, abiertos como TCP / IP, HTTP y XML. Se trata de una iniciativa conjunta de las Naciones Unidas (UN / CEFACT) y OASIS. La realizacin de negocios electrnicos con ebXML es esencialmente un proceso de cuatro pasos. 1. Disear y registrar los procesos de negocio y modelos de informacin; 2. Implementar las interfaces de servicios empresariales y registro; 3. Si lo desea negociar y definir un acuerdo de socio colaborador (CPA), y 4. 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 mensajera ebXML

4 pasos fciles de ebXML UBL XML

Oasis OASIS, acrnimo 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 adopcin de los estndares de comercio electrnico y servicios web. Los miembros del consorcio deciden cmo y qu trabajo se realiza mediante un proceso abierto y democrtico. El trabajo tcnico se lleva a cabo en las siguientes categoras: Web Services, e-Commerce, Security, Law & Government, Supply Chain, Computing Management, Application Focus, Document-Centric, XML Processing, Conformance/Interop, e Industry Domains. UBL Universal Business Language (UBL) es una librera estndar de documentos XML, diseados para representar documentos empresariales tales como rdenes de venta o facturas. Ha sido desarrollada por un comit tcnico de la organizacin OASIS, con la participacin de varias organizaciones relacionadas con los estndares de datos en la industria. UBL est pensada para integrarse directamente en las prcticas empresariales, legales, auditoras o de gestin de registros actualmente vigentes.1 Y est diseada 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 electrnico para PYMES.2 La versin 2.0 de UBL fue aprobada como especificacin de un comit de OASIS en octubre de 2006 y est pblicamente disponible. An siendo propiedad de OASIS, puede ser usado libremente por cualquiera, sin ningn tipo de pago de royalties o contraprestacin alguna por su uso. La librera de documentos empresariales de UBL es un completo lenguaje de marcado, disponiendo de herramientas de validacin, de escritura, de procesado y de generacin de dichos documentos.3 Los orgenes de UBL 2.0 se remontan a los estndares EDI y a otros estndares XML anteriores. En total estn contemplados 31 documentos. Cubriendo prcticamente todas las necesidades empresariales en cuanto a procesamiento de ofertas, pedidos, ventas, facturacin y pagos Cmo funciona el UBL? UBL pertenece a la familia de lenguajes basados en XML, o Lenguaje Extensible de Marcado, que constituye un estndar para el intercambio electrnico 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 informticos. UBL es una versin potente y flexible de XML definida especficamente para satisfacer las exigencias de la informacin comercial, financiera y empresarial. Permite aplicar etiquetas identificativas nicas a los distintos elementos que componen la informacin comercial, como, por ejemplo importes netos. Sin embargo, estas etiquetas son algo ms que meras etiquetas identificativas, pues proporcionan una amplia gama de informacin sobre dicho elemento, como, por ejemplo, si es monetario, porcentaje o fraccin. UBL permite que se utilicen etiquetas en cualquier idioma, as como referencias contables u otra informacin complementaria. UBL puede mostrar la relacin que guarda un elemento con otro, por lo que puede representar cmo se calculan. Puede asimismo identificar, con fines de organizacin o de presentacin, si pertenecen a algn grupo en concreto. Y ms importante todava, es fcilmente 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 travs de programas informticos. Permite la realizacin de todas las tareas estndar que conllevan la compilacin, el almacenamiento y la utilizacin de los datos de empresa La citada informacin puede convertirse en UBL mediante procesos de mapeo (mapping) adecuados o generarse en UBL a travs de programas informticos. Luego, se puede buscar, seleccionar, intercambiar o analizar la informacin, o publicarla para una visualizacin normal. UBL 1.0 se lanz como estndar de OASIS (una organizacin sin fines de lucro dedicada al desarrollo abierto de estndares pblicos de XML) el 8 de noviembre de 2004 tras tres aos de desarrollo y de revisin pblica. UBL 2.0, que ampla ampliamente el alcance de UBL, se aprob como especificacin del comit del OASIS en octubre de 2006 y se ha sometido a OASIS para su ratificacin como estndar de OASIS, lo que se produjo en diciembre de 2006. UBL supone un enfoque claramente centrado en el documento del comercio electrnico que se focaliza en

estandarizar los datos de negocio de forma que encajen en los documentos en papel tradicionales. El estndar internacional principal para los formularios en papel de los documentos tradicionales es el UN Layout Key de la O.N.U, que durante ms de 40 aos ha servido como modelo para los documentos de papel usados en comercio internacional.

Cmo se ha implementado UBL a nivel mundial? Desde febrero de 2005, la factura UBL se ha impuesto por ley para todo el sector pblico en Dinamarca. Cada mes, se intercambian en Dinamarca 1.2 millones de facturas UBL. El ministerio dans de finanzas ahorra para el estado alrededor de 200 millones de euros anuales por el uso de este tipo de documento. La adopcin 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 tcnico a la implantacin de este estndar 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 pblicas por la Autoridad de Gestin Financiera Nacional Sueca (Swedish National Financial Management Authority). La NFMA estima que la estandarizacin de factura UBL ahorrar el gobierno sueco 4 mil millones de SEK, coronas suecas (ms de 500 millones de dlares) en los primeros cinco aos del despliegue. En el Reino Unido, el sistema de gestin de mercado (marketplace) Zanzibar, creado por la oficina britnica de soluciones de contratacin pblica (UK Office of Government Buying Solutions), se lanz en febrero de 2006 con 14 documentos UBL 2.0. El proyecto de Gestin Electrnica 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 Expedicin) and Bill of Lading (Conocimiento de Embarque). Este proyecto experimental enlaza dos fabricantes chinos de ropa, dos transitarios, un operador de terminal de fletes areos, dos transportistas areos, un comprador norteamericano de ropa, un intermediario logstico (3PL, third-party logistics) y un corredor de importacin en una

demostracin compleja de comercio electrnico avanzado ajustado al mundo real.

Seguridad en Internet

Seguridad en Internet crtica para el B2B El Internet ha revolucionado las formas en que las empresas hacen negocios. El comercio electrnico B2B es sin duda eficaz, barata y flexible. Sin embargo, es vulnerable a una serie de riesgos de seguridad. Como el comercio electrnico B2B se hace ms generalizada, la seguridad tiende a ser crtica en el logro de la comunicacin perfecta entre los socios comerciales. No es slo un requisito, pero en realidad la base sobre la que B2Bi se construirn. La informacin registrada electrnicamente y est disponible en equipos en red es ms propensas al riesgo que si la misma informacin que se imprime en papel y bajo llave en un armario. Los intrusos no necesita estar fsicamente presente en ese lugar e incluso pueden no estar en el mismo pas o continente. En silencio se puede robar o manipular archivos electrnicos 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 electrnica. Ms del 50 por ciento de las empresas invierten un 5% o menos de su presupuesto de TI en la tecnologa de seguridad, con slo un gasto de slo un 10% ms del 20% de su presupuesto de TI en materia de seguridad. Por lo tanto, el hecho es que muchas empresas sufren una prdida 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 compaa en agua caliente. En un entorno B2Bi, incluso los errores simples pueden conducir a la prdida de datos que ningn otro socio comercial cada vez se toleran. Consideremos un escenario en el que un error o una mala configuracin en los sistemas de una empresa hace que los acuerdos de fijacin de precios o confidenciales Catlogo de datos personalizados enviados por un proveedor a filtrarse. Otros clientes del proveedor podrn hacer una denuncia, poniendo fin a sus relaciones comerciales con el proveedor en conjunto. La compaa errante puede tener que soportar la responsabilidad y hacer la diferencia en las ventas. Por lo tanto, una compaa 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 misin crtica y datos B2B. De hecho, los controles de seguridad y la privacidad se estn convirtiendo en obligatorio antes de acceder a la participacin en grandes implementaciones B2Bi. 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 aplicacin de una solucin de seguridad que permite a las empresas para ofrecer seguros de soluciones e-business y la gestin 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 rpida y sencilla, sin comprometer la seguridad o el rendimiento, incorporar el derecho de seleccin, configuracin y uso de productos de seguridad y su integracin con los sistemas heredados, y establecer polticas de seguridad dinmicas. Como parte de su estrategia de seguridad electrnica, las empresas deben: Determinar los activos crticos 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 seleccin apropiada y el despliegue de una solucin de garanta real, que ofrece un alto retorno de la inversin, mientras que la ampliacin de sus necesidades de seguridad, y Desarrolle la solucin de seguridad por revisar constantemente el entorno empresarial, los objetivos B2Bi, las amenazas actuales y los ltimos cambios tecnolgicos. Servicios bsicos de seguridad en B2Bi E-seguridad, a la luz de B2Bi, se trata de proteger una empresa, al tiempo que ampla la informacin de negocio y datos a las aplicaciones de toda la empresa y de los sistemas. En B2Bi, la atencin se centra en la construccin 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 comunicacin de datos entre diferentes empresas, hay algunos riesgos involucrados. Las principales preocupaciones son las siguientes: Alguien puede interceptar el mensaje y en la violacin 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 trnsito, y La empresa que enva podr, posteriormente, negar que ha enviado el mensaje. Para reducir estos riesgos, los siguientes servicios de seguridad se debe garantizar durante la comunicacin B2B: Confidencialidad - La garanta de que el mensaje es privado y sus contenidos no han sido revelados al mundo exterior; Autenticacin - prueba de que el mensaje ha sido enviado realmente por la compaa con la cual la comunicacin 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 enva de manera que no puede negar que lo envi en un momento posterior. El fracaso en asegurar ninguna de las caractersticas anteriores dar lugar a toda la transaccin se vea comprometida y en ltima instancia socavar la confianza de las empresas y los consumidores en la tecnologa B2Bi. Conceptos clave en las soluciones de e-Seguridad Algunas de las tecnologas clave que han surgido como el fundamento de la seguridad electrnica son: la criptografa, firmas digitales y certificados y servidores de seguridad. En esta seccin, vamos a echar un vistazo ms de cerca a estas tecnologas y comprender el papel desempeado por cada uno en la creacin de un entorno seguro para la empresa. Criptografa Criptografa, tambin llamado cifrado, protege la privacidad de la informacin que se transmite a travs de Internet. Asegura que la informacin no es inteligible si se cae en las manos equivocadas. Mientras que la criptografa ha estado en existencia desde tiempos remotos, su nivel de sofisticacin ha aumentado, en consonancia con el aumento de los riesgos. La criptografa actual utiliza sofisticadas frmulas matemticas y algoritmos informticos. Los principales elementos de la criptografa son: Texto original - el contenido exacto del mensaje; Cifrado de texto - la forma en que el mensaje aparece despus de estar encriptado. Esto no es humanamente legible; Algoritmo de cifrado - el algoritmo o frmula matemtica 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 encriptacin se hace para asegurar no slo texto, sino tambin de vdeo, sonido, etc - cualquier forma de comunicacin a travs de Internet.

Cifrado de clave privada Cifrado de clave privada, tambin llamado cifrado simtrico, era la forma ms sencilla de los mensajes cifrados se enviaron en los primeros tiempos. Se utiliza el mismo cdigo 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 enva el mensaje. La empresa B hace uso de la clave privada (enviados a travs de versiones anteriores) para descifrar el mensaje

Encriptacin con clave privada Cifrado de clave pblica Para superar los inconvenientes de cifrado de clave privada, un nuevo algoritmo, denominado cifrado de clave pblica, fue inventada por Whitfield Diffie y Martin Hellman en 1976. Cifrado de clave pblica o asimtrica 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 pblica, que est disponible con el mundo exterior. Estas claves se complementan entre s como una cerradura mecnica y llave. El mensaje se encripta con la clave pblica y puede ser desbloqueado o descifrar slo 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 pblica de la empresa B y enviarlo a travs (vase Figura 10.3). Por lo tanto, las dos compaas no tienen que ponerse de acuerdo sobre una clave de antemano. Dado que el descifrado slo puede hacerse con la clave privada, que slo 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 pblica.

La firma digital La firma digital es el equivalente electrnico de una firma de lpiz y papel y se utiliza para la autenticacin del remitente del mensaje. Se proporciona un medio por el cual la informacin no puede ser repudiada por la comunicacin obligatoria a la persona que lo firm. Tambin garantiza que el mensaje no fue modificado desde que dej el remitente. Las firmas digitales se basan en sistemas de clave pblica.

Creacin de una firma digital Una firma digital se crea tpicamente usando lo que se conoce como una funcin de dispersin. Una funcin hash es un algoritmo que los valores de los mapas de un dominio de gran tamao en un rango mucho menor. En otras palabras, si tenemos un mensaje tpico, que consiste en muchos miles de bits, el algoritmo de control puede producir un 'resumen' de la misma, lo que sera un centenar de bits de longitud. Adems, sera garantizar que, incluso si un poco se cambia en el mensaje, el digesto producido sera 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 pblica 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 pblica del remitente. 4. A continuacin, 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 tambin que la identidad del remitente se demuestra (como la clave privada del emisor estuvo involucrado en el proceso; (ver Figura)

Des encriptacin con firma digital

Asegurando integridad del mensaje Cdigos de autenticacin de mensajes (llamado MAC) es otro mecanismo para la identificacin de los usuarios. Un MAC es una etiqueta de autenticacin (tambin llamado una suma de comprobacin) derivado mediante la aplicacin de un esquema de autenticacin, junto con una clave secreta, a un mensaje. Sin embargo, no es infalible, como el receptor tambin puede generar estos cdigos y mal uso de ellos.

Los certificados digitales y el papel de autoridades de certificacin (CA) Todos los mecanismos anteriores de seguridad basados en el uso de claves pblicas y claves privadas, tanto para el emisor y el receptor. La pregunta que surge - dnde stas claves vienen? De qu manera el mundo exterior apoderarse de la clave pblica de una organizacin en particular? La respuesta est en los certificados digitales emitidos por organizaciones llamadas Autoridades de Certificacin (CA). Los certificados pueden ser utilizados para reemplazar pasar de las palabras y el ID de inicio de sesin 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 travs de Internet se puede aplicar a una entidad emisora de un certificado digital. Tiene que enviar su informacin de identificacin y la clave pblica a la CA. La CA verificar la autenticidad de la informacin y luego emitir un certificado con la informacin dada y la clave pblica. Para sellar el certificado, la CA lo cifra con su clave privada y la enva al solicitante (vase la figura).

Certificado pblico simple En este enfoque, cuando la empresa A quiere comunicarse con la Compaa B, se le pedir la Compaa B por su certificado. Al recibir este certificado, la empresa A descifrar la voluntad de la misma utilizando la clave pblica de la CA. A continuacin, lea la informacin de identificacin en el certificado. Si satisfecho, se utilizar la clave pblica presente en el certificado para enviar a travs de la informacin a la empresa B. Esta metodologa no slo es seguro, pero requiere que el remitente slo conoce la clave pblica del CA, en vez de recordar la clave pblica de todos los partidos que desea comunicarse. El ms reconocido estndar de formato de certificado de clave pblica se define en el estndar ITU X.509. Hay mltiples organizaciones que funcionan como entidades de certificacin. Lder 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 electrnico proviene de la direccin mencionada; Servidor de certificados - establece la identidad de un sitio de Internet en particular, y Cdigo de firma de certificado - utilizada por las empresas de software para firmar las versiones publicadas de su cdigo. Componentes de Integracin

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 creacin y publicacin de las interfaces de los servicios, ofreciendo la actual implementacin de estos servicios y responder a toda solicitud para la utilizacin de los mismos. Cualquier empresa o negocio puede ser un proveedor de servicios. Service Broker - Este componente registra y clasifica los servicios pblicos publicados por diversos proveedores de servicios y ofrece servicios como la bsqueda, los agentes de servicio, etc. actuar como un repositorio o las pginas amarillas para los servicios Web. Las empresas que deseen utilizar los servicios Web pueden buscar en estas pginas amarillas para encontrar uno que coincida con sus necesidades. En la actualidad varias empresas con clientes como Ariba, IBM y Microsoft estn 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 bsqueda del repositorio mantenido por los corredores de servicio y luego llamar a estos servicios mediante la comunicacin con los proveedores de servicios reales. En la mayora de los casos, la invocacin sera remoto a travs de Internet, pero tambin es posible que la invocacin del servicio es local a travs de la intranet, lo que significa que la empresa solicitante es tambin el proveedor de servicios. Las tres operaciones ms bsicas a travs del cual los participantes interactan 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 operacin de describir la interfaz de servicios Web que luego son publicados con UDDI. Buscar - Esta operacin permite a un solicitante del servicio para localizar, buscar y descubrir los servicios publicados a travs de un corredor de servicios que se ofrecen en una clasificacin particular o por un prestador de servicios especfico. Encontrar est habilitada por el UDDI (Universal Description, Discovery and Integration) marco. Enlazar - Esta operacin permite a un solicitante del servicio para vincular realidad y utilizar un servicio proporcionado por un proveedor de servicios. La vinculacin es activada por mensajes basados en SOAP XML

Servicios Web (Web Services) Los servicios Web son URL-direccionables, autnomos 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 aplicacin a aplicacin ver la interaccin 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 bsqueda. 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 pblicas 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 ejecucin y publica una API de mensajera, de modo que pueda ser utilizado por otros servicios sobre la red. Los servicios web tienen todas las caractersticas de sistemas orientados a objetos, tales como la encapsulacin, paso de mensajes, la descripcin dinmica de unin y de servicio y consulta. A travs de la asignacin dinmica de los componentes, que es la plataforma y lenguaje de programacin neutral y las comunicaciones mecanismo independiente-, que permiten justo a tiempo de integracin de aplicaciones. Los servicios Web permiten aprovechar plenamente la infraestructura y las aplicaciones existentes. Las aplicaciones web existentes (Internet / Intranet) pueden ser fcilmente convertidos en servicios Web, con independencia de la plataforma o el lenguaje de programacin utilizado para implementar estas aplicaciones. Caractersticas esenciales de un entorno de servicios Web Hay varias caractersticas esenciales para el funcionamiento de los servicios Web. El entorno de servicios Web proporciona un marco que ofrece la posibilidad de descubrir de forma dinmica, instalar y volver a utilizar los servicios empresariales. Un servicio web tiene que ser: Creado y sus interfaces y los mtodos de invocacin debe ser definido; Publicacin de una o ms 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 estndar de seguridad, tales como bsqueda, traduccin, la tala y las transacciones; No publicado, cuando ya no est disponible o cuando sea necesario, y Integracin con otros servicios web utilizando los estndares 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 tecnologa como EJB y CORBA, siempre y cuando sean capaces de generar y analizar los documentos XML. Universal Description, Discovery and Integration (UDDI) UDDI es un registro de negocios centralizada que permite a las empresas a empresa de comunicacin. UDDI es una forma estndar de hacer frente a la necesidad de un depsito o un corredor que se gestionar una base de interfaces de servicios. IBM, Microsoft y Ariba se indica su especificacin para ayudar a facilitar la creacin, descripcin, descubrimiento e integracin de servicios basados en Web. Un registro UDDI tiene, bsicamente, 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. Web Services Description Language (WSDL) WSDL es un lenguaje XML que describe un servicio Web, especifique su ubicacin, se describen las operaciones (es decir, mtodos) 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 trminos de los criterios de valoracin ', que son una manera de solicitar XML relacionados con la funcionalidad de un ordenador remoto a travs de una red como Internet. Se estandariza el formato de la publicacin de las operaciones de un servicio con sus respectivos parmetros y tipos de datos, la definicin de la ubicacin 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 mltiples implementaciones fsicas, tales como SOAP, HTTP y MIME. WSDL es independiente del protocolo subyacente y los requisitos de codificacin, lo que permite dinmica transversal plataforma de integracin. WSDL schema Un esquema XML de WSDL (segn 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 algn sistema tipo (como XSD); Mensaje - una descripcin abstracta de los datos que se intercambian que se puede presentar como documentos de pleno derecho o como argumentos asignados a una invocacin de operacin; Funcionamiento - una definicin abstracta de una accin (como un proceso de negocio) con el apoyo de un servicio Web; Tipo de puerto - una coleccin abstracta de las operaciones que se asignan a uno o ms extremos, lo que permite las operaciones que se asignan a uno o varios protocolos de transporte; Encuadernacin - utilizado para fijar un protocolo concreto y especificacin de formato de datos para un tipo de puerto; Puerto - un punto final definido como una combinacin de obligar a una direccin de red, que proporciona la direccin de destino del servicio de comunicacin, y Servicio - una coleccin de extremos relacionados con el que se asignan la unin del puerto y incluye ninguna definicin de la extensibilidad. WSDL y UDDI WSDL complementa el estndar UDDI, proporcionando una manera uniforme de describir los enlaces de la interfaz y el protocolo de servicios de red. De acuerdo con las especificaciones tcnicas puestas a disposicin por parte de IBM y Microsoft, UDDI los servicios basados en Web pueden ser creadas usando WSDL por los siguientes pasos: 1. Creacin de la definicin WSDL interfaz de servicio. Por lo general, los grupos industriales se definen un conjunto de tipos de servicios, y las describen con uno o ms servicios de interfaz de documentos de definicin WSDL. La definicin de interfaz de servicio incluye las interfaces de servicios y enlaces de protocolo y se pondr a disposicin del pblico. 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 estndar de la industria. Para ello, recuperar la descripcin de la estructura tModel la definicin estndar de la industria y (siguiendo el enlace overviewDoc) obtener el correspondiente documento WSDL definicin. 3. Implementar y registrar el nuevo servicio en el repositorio UDDI. Para ello, crear una estructura de datos de UDDI BusinessService y luego registrarlo. Poniendo todo junto Despus de haber discutido todos los componentes de servicios Web, vamos a tratar de definir. Un servicio Web es una aplicacin 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 aplicacin de B2B, donde un comprador recibe informacin acerca de los servicios web de proveedores que utilizan privada registro UDDI y llama a estos servicios a travs de Internet para obtener las cotizaciones de un elemento especfico.

Ejemplo de servicios web en aplicaciones B2B

SUNAT

Qu es la SUNAT?
La Superintendencia Nacional de Aduanas y de Administracin Tributaria SUNAT, de acuerdo a su Ley de creacin N 24829, Ley General aprobada por Decreto Legislativo N 501 y la Ley 29816 de Fortalecimiento de la SUNAT, es un organismo tcnico especializado, adscrito al Ministerio de Economa y Finanzas, cuenta con personera jurdica de derecho pblico, con patrimonio propio y goza de autonoma funcional, tcnica, econmica, 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 artculo 13 de la Ley N 27658, ha absorbido a la Superintendencia Nacional de Aduanas, asumiendo las funciones, facultades y atribuciones que por ley, correspondan a esta entidad. Tiene domicilio legal y sede principal en la ciudad de Lima, pudiendo establecer dependencias en cualquier lugar del territorio nacional. Funciones y atribuciones de la SUNAT

Son funciones y atribuciones de la Superintendencia Nacional de Aduanas y de Administracin Tributaria: Administrar, recaudar y fiscalizar los tributos internos del Gobierno Nacional, con excepcin de los municipales, as como las aportaciones al Seguro Social de Salud (ESSALUD) y a la Oficina de Normalizacin Previsional (ONP), y otros cuya recaudacin se le encargue de acuerdo a ley. Proponer al Ministerio de Economa y Finanzas la reglamentacin 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 simplificacin de los regmenes y trmites aduaneros, as como normar los procedimientos que se deriven de stos. Sistematizar y ordenar la legislacin e informacin estadstica de comercio exterior, a fin de brindar informacin 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 celebracin de acuerdos y convenios internacionales, as como emitir opinin cuando sta le sea requerida. Celebrar acuerdos y convenios de cooperacin tcnica y administrativa en materia de su competencia. Promover, coordinar y ejecutar actividades de cooperacin tcnica, de investigacin, de capacitacin y perfeccionamiento en materia tributaria y aduanera, en el pas 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 percepcin de los tributos que administra y disponer la suspensin de las mismas cuando corresponda. Controlar y fiscalizar el trfico de mercancas, cualquiera sea su origen y naturaleza a nivel nacional. Inspeccionar, fiscalizar y controlar las agencias de aduanas, despachadores oficiales, depsitos autorizados, almacenes fiscales, terminales de almacenamiento, consignatarios y medios de transporte utilizados en el trfico internacional de personas, mercancas u otros. Prevenir, perseguir y denunciar al contrabando, la defraudacin de rentas de aduanas, la defraudacin tributaria, el trfico ilcito de mercancas, as como aplicar medidas en resguardo del inters fiscal. Desarrollar y aplicar sistemas de verificacin y control de calidad, cantidad, especie, clase y valor de las mercancas, excepto las que estn en trnsito y transbordo, a efectos de determinar su clasificacin en la nomenclatura arancelaria y los derechos que le son aplicables. Desarrollar y administrar los sistemas de anlisis y fiscalizacin de los valores declarados por los usuarios del servicio aduanero.

 Resolver asuntos contenciosos y no contenciosos y, en este sentido, resolver en va administrativa los recursos interpuestos por los contribuyentes o responsables; conceder los recursos de apelacin 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 carcter tributario y aduanero, con arreglo a Ley. Ejercer los actos y medidas de coercin 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 disposicin de mercancas, aquellas que se encuentren en abandono legal y en comiso administrativo. La adjudicacin 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 informacin, divulgacin y capacitacin en materia tributaria y aduanera. Editar, reproducir y publicar oficialmente el Arancel Nacional de Aduanas actualizado, los tratados y convenios de carcter aduanero, as como las normas y procedimientos aduaneros para su utilizacin general. Determinar la correcta aplicacin y recaudacin de los tributos aduaneros y de otros cuya recaudacin se le encargue de acuerdo a ley, as como de los derechos que cobre por los servicios que presta. Participar en la celebracin de Convenios y Tratados Internacionales que afecten a la actividad aduanera nacional y colaborar con los Organismos Internacionales de carcter aduanero. Crear, dentro de su competencia, administraciones aduaneras y puestos de control, as como autorizar su organizacin, funcionamiento, suspensin, fusin, traslado o desactivacin cuando las necesidades del servicio as lo requiera. Ejercer las dems funciones que sean compatibles con la finalidad de la Superintendencia Nacional de Aduanas y de Administracin Tributaria. La Superintendencia Nacional de Aduanas y de Administracin Tributaria (SUNAT) ejercer las funciones antes sealadas respecto de las aportaciones al Seguro Social de Salud (ESSALUD) y a la Oficina de Normalizacin Previsional (ONP), a las que hace referencia la Norma II del Ttulo Preliminar del Texto nico Ordenado del Cdigo Tributario, aprobado por el Decreto Supremo N 135-99-EF. La SUNAT tambin podr ejercer facultades de administracin respecto de otras obligaciones no tributarias de ESSALUD y de la ONP, de acuerdo a lo que se establezca en los convenios interinstitucionales correspondientes.

Comprobantes de Pago - Concepto

El comprobante de pago es el documento que acredita la transferencia de bienes, la entrega en uso o la prestacin de servicios. Para ser considerado como tal debe ser emitido y/o impreso conforme a las normas del Reglamento de Comprobantes de Pago.

Base Legal Artculo 1 de la Resolucin de Superintendencia N 007-99/SUNAT Resolucin de Superintendencia N 182-2008/SUNAT Resolucin de Superintendencia N 188-2010/SUNAT

Qu tipos de Comprobante de Pago existen?

Existen distintos tipos de comprobantes de pago, dependiendo de la actividad u operacin que usted realice. A continuacin veamos algunos de estos tipos: 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 operacin efectuada y poder ejercer, de esta manera, el derecho al crdito fiscal. Por ejemplo, cuando una empresa compra papel y tner para sus impresoras debe exigir que le otorguen una factura. Boleta de venta Es un comprobante de pago que se emite en operaciones con consumidores o usuarios finales. No permite ejercer el derecho al crdito fiscal, ni sustentar gasto o costo para efecto tributario. Por ejemplo: Si usted compra los vveres para la semana en una tienda de abarrotes, debe exigir que le otorguen una boleta de venta. Lo mismo si acude a una peluquera o saln 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 operacin ser necesario consignar en la boleta de venta los datos de identificacin del adquirente o usuario: apellidos y nombres completos, y el nmero de su documento de identidad. Autorizacin de comprobantes de pago

Comprobantes de Pago emitidos de manera electrnica Los comprobantes de pago que pueden emitirse de manera electrnica son Recibos por Honorarios Electrnicos, Facturas Electrnicas, Notas de Crdito Electrnicas y Notas de Dbito Electrnica. Previamente deber afiliarse al Sistema de Emisin Electrnica ingresando a SUNAT Operaciones en Lnea - SOL en SUNAT Virtual con su clave SOL. Para acceder a este sistema de emisin tenga en cuenta que: Su domicilio fiscal debe tener la condicin de Habido. No debe hallarse en el estado de Suspensin Temporal de Actividades o Baja de Inscripcin. Debe estar afecto en el RUC al Impuesto a la Renta de Tercera o Cuarta Categora, segn corresponda.

Para el caso de los que emitan factura electrnica, deben adicionalmente encontrarse acogidos al Rgimen Especial del Impuesto a la Renta (RER) o al Rgimen General. Para emitir sus comprobantes solo debe ingresar a SUNAT Virtual, seleccionar SUNAT Operaciones en Lnea, ingresar su Clave SOL e ingresar al mdulo "Sistema de Emisin Electrnica SEE" opcin: Emisin de Documentos Electrnicos. Comprobantes de Pago emitidos de manera impresa Las Facturas, Boletas de Venta, Liquidaciones de Compra, Recibos por Honorarios, Notas de Crdito, Notas de Dbito, Guas de Remisin, Boletos de Viaje, entre otros, son algunos de los comprobantes de pago y/o documentos que pueden emitirse de manera impresa. Factura Electrnica desde los Sistemas del Contribuyente A diferencia de la solucin implementada en el portal, donde la emisin electrnica se realiza a travs del Portal de la SUNAT, en este sistema realiza la emisin electrnica desde los sistemas del contribuyente. El sistema permite emitir en forma electrnica: facturas, boletas de venta, notas de crdito y notas de dbito. Notas importantes: Los contribuyentes autorizados a emitir en forma electrnica sus comprobantes de pago, podrn seguir emitiendo comprobantes en forma fsica. Los contribuyentes que emitan tickets y sean autorizados a emitir en forma electrnica, en lugar de tickets, deben emitir boletas y/o facturas electrnicas. En el mundo electrnico, ya no hay tickets. Los comprobantes electrnicos cuentan con una estructura de serie diferente a la utilizada por los comprobantes de pago fsicos, lo que permite identificarlos rpidamente para su registro contable. La fsica es numrica, y la electrnica, alfanumrica Procesos Para un mejor entendimiento se ha regulado los siguientes procesos que le permitirn incorporarse al sistema rpidamente: Proceso de Autorizacin Para poder emitir comprobantes de pago electrnicos el contribuyente debe estar autorizado por la SUNAT, para lo cual deber: i) Ingresar a la opcin comprobantes de pago/ factura electrnica - grandes emisores/ generar solicitud disponible en SUNAT Operaciones en Lnea y consignar la informacin solicitada, sealando los comprobantes de pago que desea emitir de forma electrnica (debe solicitar por lo menos facturas). Asimismo, en dicha opcin se le mostrar una declaracin jurada respecto del sistema que utilizar para la emisin, la cual deber completar. ii) Asimismo debe cumplir con: Tener el estado ACTIVO en el Registro nico de Contribuyentes

Tener la condicin de HABIDO en el Registro nico de Contribuyentes Estar autorizado a emitir facturas, segn el reglamento de comprobantes de pago Registrar el correo electrnico que utilizar en su calidad de emisor electrnico y de receptor de comprobantes de pago electrnicos. Este registro se realiza a travs de la opcin disponible en SUNAT Operaciones en Lnea en: Comprobantes de pago/ factura electrnica - grandes emisores Correo electrnico Estos requisitos sern validados en lnea (de manera automtica) por el sistema, para luego pasar a un proceso de homologacin. Proceso de homologacin Generada la solicitud, el contribuyente debe pasar a un proceso de homologacin, para lo cual sistema automticamente le asignar un Set de Pruebas (ver Manual de homologacin) el cual permitir a la SUNAT evaluar si los sistemas del contribuyente gestionan correctamente la elaboracin, emisin, envo (entre otros) de los comprobantes de pago electrnicos, segn las normas vigentes. Concluida la fase de homologacin, la SUNAT le emitir una Resolucin autorizndolo como Emisor Electrnico. Este proceso consiste en: Verificar si las facturas, boletas de venta, notas de crdito y debito electrnicas, as como el Resumen Diario y la comunicacin de baja son generados y enviados de acuerdo a lo establecido por la SUNAT. Segn los comprobantes de pago que el contribuyente haya solicitado emitir de manera electrnica, 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 electrnicas segn corresponda. Para cada conjunto de casos, el Manual de homologacin, describe las caractersticas 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 crdito o dbito asociadas, adicionalmente se solicita que se enven las representaciones impresas para verificar que stas cumplan con las caractersticas requeridas. El envo de estos documentos ser a travs de la opcin procesos de envo y seguimiento de casos del men SOL (para mayor detalle consulte la gua de homologacin). Asimismo, para el seguimiento de este proceso de homologacin, el contribuyente tiene una opcin de consulta en SOL, a travs de la cual podr visualizar el estado de cada etapa y documento que se est homologando. Todo el proceso, contado desde la fecha de presentacin de la solicitud, no debe exceder los 30 das hbiles, 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. Proceso de Emisin de Comprobantes de Pago Electrnicos

Se ha definido un tratamiento diferenciado para la Factura Electrnica y para la Boleta de Venta Electrnica y sus correspondientes notas de crdito y debito electrnicas. En el caso de las Factura Electrnica y las notas de crdito y dbito relacionadas, se debe enviar un ejemplar a la SUNAT al momento emisin. La SUNAT validar la informacin y emitir una constancia de recepcin. Tratndose de las boletas de venta y las notas de crdito y dbito relacionadas, se enviar un Resumen Diario con la informacin de los comprobantes emitidos en el da. Proceso para Otorgar del Comprobante de Pago Electrnico. La factura se otorgar a travs de medios electrnicos (en archivo digital) y la boleta de venta a travs de una representacin impresa (papel) o medio electrnico (archivo digital), en este caso, se requiere un previo acuerdo del receptor. El comprobante de pago electrnico es: En el caso de la factura electrnica: El archivo digital En el caso de la boleta de venta electrnica: La representacin impresa

Operatividad del Sistema de Emisin Electrnica

Factura Electrnica y sus notas de crdito o dbito asociadas a) Se emite la factura o las notas, en los sistemas del contribuyente de acuerdo al formato electrnico establecido por la SUNAT. b) El emisor enva y/o entrega la factura electrnica a sus clientes (receptores) en formato electrnico a travs de una pgina web, correo electrnico, servicio web, entre otros. El medio de entrega lo define el emisor. c) De manera simultnea (o a ms tardar a las 72 horas contadas desde el da siguiente de la fecha de emisin), se debe enviar un ejemplar a la SUNAT de acuerdo a la forma establecida en el anexo 6 de la Resolucin N 097-2012/SUNAT. d) La SUNAT valida la informacin enviada y como resultado de ello, por el mismo medio en el que el emisor envi el comprobante de pago electrnico, enva una Constancia de Recepcin CDR, la cual puede tener los siguientes estados: Aceptada: Si el comprobante de pago electrnico cumple con las validaciones establecidas. En este caso, el comprobante adquiere total validez tributaria. Aceptada con observacin: Cuando el comprobante de pago electrnico cumple con las validaciones establecidas y por lo tanto, ya tiene validez tributaria, pero hay datos en el comprobante que, producto de una auditora, podran ser reparados. Rechazada: Si no cumple con las condiciones establecidas. En este caso, el comprobante de pago electrnico que se hubiera emitido, no tiene validez tributaria. El emisor tendr que emitir una nueva factura electrnica corrigiendo los motivos por los cuales fue rechazado. e) El emisor debe poner a disposicin de sus clientes (receptores), una opcin de consulta de los comprobantes que hubiera emitido (facturas, boletas de venta y notas de crdito y de dbito), a travs de una pgina web, por un periodo no menor a un ao. Para acceder a esa consulta, debe definir un mecanismo de seguridad que permita resguardar la confidencialidad de la informacin, de modo tal que solo el cliente pueda acceder a ella. f) Adicionalmente, la SUNAT pone a disposicin de los contribuyentes, una opcin de consulta de los comprobantes electrnicos emitidos. A travs de esa consulta, se puede visualizar la informacin tributaria del comprobante. Importante: No es obligatorio que primero se enve el ejemplar de la factura (y sus correspondientes notas de crdito 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 validacin. Cabe sealar que estos rechazos deben ser mnimos o no existir, considerando que antes de ser autorizados como emisores electrnicos, el contribuyente emisor ha sometido a evaluacin, los archivos electrnicos

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 electrnicas es un plazo mximo, ya que el envo debera ser en la misma fecha de emisin. Asimismo, este plazo NO significa que en 72 horas debe entregarse los comprobantes a los clientes. Certificado digital El modelo peruano de Factura Electrnica incluye el uso del Certificado Digital, herramienta tecnolgica que permite la integridad, seguridad y el no repudio de las transacciones electrnicas. El Certificado Digital es utilizado para firmar digitalmente los comprobantes de pago electrnicos (facturas, boletas de venta y notas de crdito y dbito) as como los resmenes diarios y las comunicaciones de baja. De esta forma, el contribuyente, al firmar digitalmente los comprobantes de pago y dems documentos electrnicos, no puede desconocer posteriormente la autora de dichos documentos, generando con ello una seguridad en la transaccin comercial. La SUNAT requiere para el uso del certificado digital es que ste cuente con la siguiente informacin: a. Nombres y apellidos, denominacin o razn social b. De ser persona natural, adicionalmente debe contener el nmero del documento de identidad. Si es persona jurdica, 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. Factura electrnica La factura electrnica 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 Resolucin de Superintendencia N 0972012/SUNAT. Las especificaciones de la Factura electrnica, se encuentran detalladas en el Anexo N 01 (condiciones y requisitos) y en el Anexo N 9 (formato UBL) de la mencionada solucin, En el presente documento se desarrolla el detalle de los campos (tag) indicados en dichos anexos.

CONTENIDO DE LA FACTURA ELECTRONICA

CAPITULO III - Estado del Arte

Actualmente existen implementaciones de Factura electrnica en diferentes pases 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 jurdica, y disminuye los riesgos de fraude y de evasin fiscal ocasionados por la generacin de comprobantes apcrifos que afectan a la economa formal. A continuacin se presentan algunos casos de facturas electrnicas en los pases de Amrica Latina.

Caso Guatemala:
Segn el acuerdo Nmero 024-2007 del Directorio de la Superintendencia de Administracin Tributaria de Guatemala la Factura Electrnica es una factura autorizada, emitida, archivada y conservada en forma electrnica, lo que garantiza: -La existencia y procedencia del emisor y receptor -La precisin de su contenido -El control en tiempo real -La facilidad de acceso a la informacin -Igual validez a las de papel -Incorpora un Cdigo de Autorizacin de Emisin (CAE) que la hace nica. Los actores que participan el proceso de facturacin electrnica son: -Certificador de Sistemas GFACE -GFACE (GENERADORES DE FACTURA ELECTRNICA) -EFACE (EMISORES DE FACTURA ELECTRNICA) -Comprador -SAT (Superintendencia de Administracin Tributaria)

A continuacin se presenta la funcionalidad mnima que debe contener el sistema de informacin de empresas que deseen proveer el servicio de Generacin de Factura Electrnica (GFACE). 1. Registro y Control de Contribuyentes Autorizados: Se debe habilitar el mdulo para el control de contribuyentes autorizados para la emisin de facturas electrnicas. 2. Integridad de la informacin para cada uno de los contribuyentes autorizados para generar Facturas Electrnicas: Cada una de las entidades (GFACE) que provean el servicio de Generacin de Facturas Electrnicas debe suscribir un Convenio de Confidencialidad con la SAT sobre el manejo de la informacin. De igual forma debern firmar un Convenio de Confidencialidad individual con las empresas a las cuales proporcionen el servicio a efecto de no divulgar a ningn tercero informacin de cada una de las empresas a las cuales proporcione el servicio de facturacin electrnica. Las entidades GFACE tendrn conocimiento de las implicaciones legales pertinentes en caso de violacin a disposiciones de confidencialidad sobre este punto. Cada uno de los proveedores debe demostrar a la SAT que su sistema garantiza que cualquier transaccin que el contribuyente solicite a travs de la aplicacin, tendr lo siguiente: i. Validacin que garantice que cada una de las autorizaciones que la aplicacin realice, contenga informacin consistente. ii. Asignacin de un identificador nico de la operacin el cual se define en el literal F. Especificaciones tcnicas, diseos de registro, requisitos y condiciones de los archivos de facturas electrnicas. iii. El identificador nico de todas las facturas electrnicas y documentos electrnicos tendrn los prefijos siguientes:

a) Factura Electrnica: FACE b) Nota de Crdito Electrnica: NCE c) Nota de Dbito Electrnica: NDE 3. Funcionalidades del sistema de los GFACE, para ser utilizadas por los contribuyentes EFACE, en la emisin y control de Facturas y documentos Electrnicos para uno o varios contribuyentes. A cada uno de los contribuyentes EFACE autorizados para la facturacin electrnica, los distintos proveedores GFACE del servicio de facturacin electrnica deben habilitarle una aplicacin con acceso va Web que les permita: i. ii. Registrar sus transacciones electrnicas, cumpliendo con normas establecidas por la SAT. las

Registro de cada una de las transacciones autorizadas. Especificaciones tcnicas, diseos de registro, requisitos y condiciones de los archivos de facturas electrnicas del presente documento, para el detalle de la informacin y formato del mismo, para los documentos electrnicos generados. Realizar las transacciones siguientes: a) Facturas b) Notas de Crdito c) Notas de Dbito d) Copias de Facturas e) Copias de Notas de Crdito f) Copias de Notas de Dbito g) Anulacin de las anteriores Registrar las transacciones a travs de: a) Formulario habilitado en la Web, en el cual se podr ingresar manualmente la informacin de la transaccin. b) Carga en lotes, para lo cual el contribuyente debe preparar un archivo con la informacin de todas las transacciones que quiere generar, segn 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 travs del cual se podr automatizar el registro de las transacciones entre el sistema actual de informacin del contribuyente y el sistema de facturas electrnicas, segn formato establecido de mutuo acuerdo con el GFACE, permitiendo una interrelacin entre ambos sistemas.

iii.

iv.

v.

Control de los cierres mensuales y generacin automtica de los archivos de las transacciones mensuales generadas. Especificaciones tcnicas, diseos de registro, requisitos y condiciones de los archivos a almacenar mensualmente del presente documento, para el detalle de la informacin y formato de los mismos.

vi.

Generacin automtica de los montos a consignar en la Declaracin Jurada del Impuesto al Valor Agregado, de las transacciones electrnicas, del cdigo 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 perodos a declarar, los cuales podrn variar a solicitud de la SAT, la cual deber ser notificada a cada uno de los proveedor del servicio de Emisin de Facturas Electrnicas un mes antes, como mnimo, del uso del nuevo formato. Acceso a las transacciones por medio de uno de los siguientes medios: a) Consultas b) Reportes c) Generacin de archivos

vii.

4. Verificacin de cualquier factura electrnica a travs de una opcin en la Web. Los proveedores GFACE debern habilitar en la Web una opcin en la cual cualquier persona pueda entrar al sistema y validar que la factura electrnica es autentica, para lo cual debe brindar dos opciones: a) Validacin de la autenticidad e integridad de la factura electrnica: Recibir el archivo de la factura electrnica y proceder a validar el sello digital, si existe y el cdigo de seguridad de la misma; estos datos debern ser validados por el sistema de verificacin de facturas electrnicas y el sistema deber indicar si los datos ingresados corresponden o no a una factura electrnica vlida. b) Validacin del cdigo de seguridad: Ingresar los campos que conforman el cdigo de seguridad y el CAE o CAEC (segn corresponda), con lo cual se podr validar la integridad de estos datos.

Caso Chile:
Segn el RESOLUCION EXENTA SII N Servicio de Impuestos Internos (SII) de Chile la Factura Electrnica (FE) consiste en: -Es la representacin informtica de un documento tributario generado electrnicamente, que reemplaza al documento soportado en papel y tiene la misma validez que este. -La FE va firmada digitalmente por el emisor. -La numeracin es autorizada via internet por el SII. -Se debe enviar al SII, via internet, un ejemplar de cada FE que el contribyete emita. -No requiere imprimirse en un papel con fondo pre-impreso ni timbrado. -El contribuyente autorizado como emisor electrnico podra seguir emitiendo documentos no electrnicos. -Los contribuyentes autorizados a emitir FE deben enviar mensualmente al SII la informacin electrnica de compras y ventas. -El contribuyente autorizado como emisor de Documentos Tributarios Electrnicos (DTE) queda habilitado para recibir electrnicamente los documentos que le enven otros contribuyentes.

El Servicio de Impuestos Internos (SII) estableci la acreditacin de Prestador de servicios tributarios electrnicos, la que permite incorporar a los contribuyentes al sistema de factura electrnica en forma expedita. Este procedimiento es aplicado por los proveedores de soluciones de facturacin electrnica que cumplen con los requisitos establecidos en la Resolucin Exenta SII N81. Actualmente, el Servicio de Impuestos Internos exige a los contribuyentes que sus documentos tributarios en papel, sean registrados y autorizados antes de utilizarlos. Esta autorizacin del SII se materializa a travs de un timbre de cuo que el contribuyente est obligado a aplicar sobre sus documentos en papel, previo a utilizarlos. Para aplicar este timbre de cuo, que autoriza que un papel sea utilizado como documento tributario, el contribuyente debe concurrir peridicamente 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 foliacin en la impresin y al no poder utilizar tecnologa de impresin lser, como es el deseo de muchos contribuyentes. En relacin con el almacenamiento de las facturas y otros documentos tributarios, el contribuyente est obligado a guardar los papel es que los sustentan durante 6 aos para su posterior posible revisin. Esta obligacin deviene, especialmente para los generadores de grandes volmenes de documentos, una exigencia costosa en administracin y bodegas. Como una respuesta a estas necesidades, y en concordancia con la poltica adoptada de modernizar su gestin y utilizar la red Internet como elemento de comunicacin con los contribuyentes, el Servicio de Impuestos Internos ha impulsado, con la colaboracin de un grupo de empresas, un modelo de operacin con Factura Electrnica y que est abierto a todos los contribuyentes. En dicho modelo, los contribuyentes pueden generar, transmitir, y almacenar en forma electrnica sus documentos tributarios, autenticados con firma electrnica, adems deben enviar un ejemplar electrnico del documento tributario al SII, antes de que sea recibido por su receptor o utilizado para el transporte fsico de bienes. La autorizacin de los folios que se usan en estos documentos se obtiene en el sitio Web del SII, como alternativa al timbre fsico con cuo. En este modelo se incorpora la facilidad de la firma electrnica 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 electrnica los contribuyentes deben estar autorizados por SII como emisores de documentos electrnicos. Esto no los obliga a generar todos sus documentos en forma electrnica pero s a recibir documentos electrnicos de otros emisores. Los contribuyentes enrolados en el sistema, una vez que han obtenido la autorizacin del SII, puede conseguir la autorizacin de sus folios a travs del Web del SII, y, utilizando esos folios, emitir, transmitir y almacenar sus documentos tributarios en forma electrnica. Los contribuyentes enrolados en el sistema requieren almacenar los documentos tributarios electrnicos emitidos y recibidos slo en forma electrnica y estn eximidos de la obligacin de almacenar dichos documentos en papel para una posible revisin del SII. El contribuyente debe enviar el documento al SII, va Internet, antes de que sea recibido por su destinatario o utilizado para el transporte fsico de bienes. El contribuyente emisor debe enviar el documento al receptor, ya sea manual

o electrnico. Al receptor manual, no enrolado en el sistema, le debe enviar la representacin en papel del documento, la que este ltimo s est obligado a almacenar. Cada documento debe ser generado en el estndar definido por las especificaciones del SII. Debe incorporar una firma electrnica 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 electrnico, el que se imprime en cdigo de barras en la representacin impresa de los documentos. Este timbre electrnico, obtenido segn un algoritmo de seguridad especificado por el SII, permite a los fiscalizadores verificar fuera de lnea, en los controles mviles, la validez de los documentos impresos que acompaan mercaderas. El Servicio de Impuestos Internos habilit una verificacin 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 situacin actual y el sistema de facturacin electrnica propuesto. Figura1:

Figura2:

Modelo operacional: El contribuyente debe obtener la autorizacin del SII para operar como Emisor de Documentos Tributarios Electrnicos. El contribuyente podr solicitar autorizacin slo para emitir factura electrnica, lo cual significa que estar autorizado tambin para notas de crdito y de dbito, o podr solicitar en forma adicional autorizacin para guas de despacho, facturas de compra o boletas. Las boletas slo se le autorizarn en el caso que sea un proveedor de servicios peridicos. Una vez autorizado para operar con documentos tributarios electrnicos el contribuyente tiene la obligacin de almacenar en forma electrnica, informacin de los libros de ventas y compras, de acuerdo al formato establecido por el SII. Esta informacin deber incluir la totalidad de los documentos emitidos y recibidos, tanto electrnicos 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 seleccin o clasificacin especfica) si ello es requerido por necesidades de fiscalizacin. En el sitio Web del SII, se encuentra disponible un registro pblico de los contribuyentes enrolados en el sistema, en el que se indica el tipo de documentos (facturas, notas de dbito y crdito, guas, facturas de compra, etc), que estn autorizados a generar en forma electrnica. Todo contribuyente registrado en el SII como

generador de un tipo de documento electrnico, est obligado a recibir documentos tributarios electrnicos. Al estar autorizado para generar cierto tipo de documento en forma electrnica, no est obligado a generar todos sus documentos de ese tipo en forma electrnica, 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 cuo y estarn sujetos a las normas establecidas para dichos documentos. Los contribuyentes enrolados deben mantener actualizada en el sitio Web del SII la informacin acerca de los Rut de las personas autorizadas al interior de su empresa a interactuar con el SII en el sistema de factura electrnica. 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, quin o quienes estn autorizados para la solicitud de folios. Previo a la generacin de un documento tributario electrnico es preciso que el contribuyente obtenga, desde el sitio Web del SII, un rango de nmeros o folios autorizados para un tipo de documento que generar en forma electrnica. El SII entrega junto a cada rango autorizado un cdigo de autorizacin asociado a ese rango de folios, que debe ser utilizado para la obtencin del timbre electrnico cuya representacin en cdigo de barras 2D se incluye en los documentos impresos. Para autenticar y evitar la alteracin del rango de folios autorizados se incluir en el cdigo de autorizacin una firma del Servicio. Se considera que los documentos electrnicos 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 estndar 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 electrnico, como parte del documento electrnico y su representacin grfica, a travs de un cdigo de barras bidimensional (PDF417), en las impresiones de los documentos tributarios electrnicos. El timbre es una firma digital de los datos relevantes de un documento, incluido el Cdigo de autorizacin 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 electrnico de los documentos, tanto en la presencia fiscalizadora y en la fiscalizacin mvil que se realiza en carreteras, como en la recepcin masiva de ellos. Una vez generado el documento en el formato establecido, incluyendo el timbre electrnico, debe ser firmado, en su contenido completo, por un emisor autorizado. Es importante que el contribuyente resguarde adecuadamente tanto sus cdigos 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 electrnico debe ser transmitido al SII en el momento de ser generado. En el caso de traslado de mercaderas, debe ser enviado al SII antes de que el ejemplar impreso sea utilizado para realizar el transporte. En los procesos de facturacin masiva, se deben transmitir tan pronto se complete el proceso correspondiente. En el caso de no existir transporte de productos asociado al documento electrnico, este podr ser transmitido en un plazo no mayor a 12 horas desde su generacin.

El mecanismo de envo de estos documentos ser va Internet y permite el envo de documentos en forma unitaria o en lotes, segn 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 tecnolgica de transmisin del documento electrnico, desde el emisor al receptor electrnico, debe ser acordada entre ambos e incluir la firma del emisor e informacin del certificado digital del firmante y respetar el estndar mnimo establecido por el SII. Los contribuyentes deben intercambiar documentos tributarios electrnicos en el mismo formato XML en que dichos documentos se envan al SII, y se obligan a responder la recepcin. Adicionalmente se ha definido un formato XML para la respuesta de recepcin o rechazo del envo y la obligacin de definir una casilla de correo electrnico para recibir la informacin relacionada con factura electrnica que le enven otros emisores electrnicos, 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 transaccin que se ha realizado, existe la obligacin de registrar el documento en la contabilidad, debiendo solicitar que se realicen los ajustes va Nota de Crdito o de Dbito, si corresponde. Si la transaccin no se ha realizado, o hay error en el Rut del receptor, puede rechazar los documentos como lo hace con los documentos no electrnicos, sin registrarlo y constituye obligacin del emisor generar y enviar al SII la nota de crdito electrnica que anule el documento. Los documentos tributarios electrnicos recibidos por un Receptor Electrnico al ser almacenados electrnicamente debe adjuntrseles la firma y el Certificado que permite verificar la firma. Los registros de un documento electrnico, hechos en la contabilidad, tendrn como respaldo vlido slo los documentos archivados electrnicamente; no se podr utilizar como respaldo un documento impreso, an cuando ste cumpla con las normas de impresin. Se considera que un documento electrnico est vlidamente emitido si cumple con las especificaciones del formato electrnico (schema XML) y por lo tanto es aceptado en la recepcin por parte del SII. Toda factura que no cumpla con estas condiciones, an cuando hubiera tenido una representacin en papel, se considerar como no emitida y en consecuencia el SII podr rechazar el crdito fiscal. En este caso el receptor deber acreditar a satisfaccin del Servicio que se han cumplido las exigencias establecidas en el artculo 23 N 5 de la Ley del IVA. Actividades Previas a la Emisin de Documentos. Para emitir documentos tributarios electrnicos 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 emisin de documentos son: -Enrolamiento. El SII registra los siguientes datos de los contribuyentes autorizados: la fecha de autorizacin, los tipos de documentos electrnicos autorizados, la identificacin del Usuario-Administrador y la direccin de correo electrnico para intercambio de informacin con otros contribuyentes autorizados.

-Autorizacin de Firmantes. La firma digital es una pieza fundamental en el sistema de factura electrnica, ya que permite asegurar la integridad de los documentos y la autenticidad del emisor de los mismos. Las empresas enroladas al sistema debern registrar ante el SII los firmantes autorizados al interior de su empresa para realizar ciertas acciones que el SII ha definido que deben efectuarse slo por parte de los firmantes autorizados de la empresa: Definicin y actualizacin de firmantes autorizados ante el SII, lo que deber ser efectuado por un Usuario-Administrador designado por la empresa a travs del representante legal. Solicitar nmeros de folios para generar documentos electrnicos tributarios vlidos. Solicitar la anulacin de folios previamente autorizados, lo que tambin debera ser ejecutado por el perfil de Usuario-Administrador. Esta anulacin de folios se puede utilizar slo cuando los DTEs generados errneamente no hayan sido enviados al SII. Firmar documentos tributarios electrnicos. Enviar documentos emitidos al SII y consultar diagnstico de validacin de documentos en el sitio del SII. - Obtencin de rango de folios autorizados y Cdigo de Autorizacin de Folios. La obtencin del rango de folios autorizados, slo la podrn efectuar los firmantes autorizados, quienes, se debern autenticar en el sitio del SII, con certificado digital. En respuesta a las solicitudes de folios vlidas, el SII entregar la autorizacin consistente en el Cdigo de autorizacin de folios y en un par de llaves que permiten generar y verificar el timbre electrnico. - Verificaciones al Cdigo de Autorizacin de Folios. El contribuyente deber verificar la validez y autenticidad del Cdigo de Autorizacin de Folios (CAF) recibido del SII. Para ello debera: Verificar que el CAF est correctamente firmado por el SII, verificando la firma del SII que incluye, con la llave pblica que el SII publique para esos efectos. Verificar que el par de llaves que incluye el CAF funciona correctamente. Para ello debera generar una firma con la llave privada y verificar la firma con la llave pblica. Funciones a Incorporar en el Sistema de Facturacin. Todo documento electrnico debe estar numerado con un folio nico y estar firmado en forma electrnica en su totalidad, incluyendo el timbre Para ello el contribuyente deber incorporar a sus aplicaciones las siguientes funciones: - Alimentar su sistema de facturacin con los folios autorizados por el SII.El contribuyente debe ingresar como parmetros a su sistema de facturacin el Cdigo de autorizacin de folios y la llave privada entregada por el SII, que le permite generar el timbre electrnico. El sistema del contribuyente debe administrar el Cdigo de autorizacin 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 informacin a personas no autorizadas. - Asignar nmero de folio nico a cada documento. El sistema del contribuyente debe asignar en forma nica un nmero de folio para cada documento, utilizando para ello el rango del cdigo de autorizacin de folios con que fue alimentado. Es obligatorio, como

medida de seguridad, que esta asignacin de folios sea hecha rigurosamente en forma unvoca para cada documento. - Calcular el Timbre Electrnico para cada documento. El Timbre Electrnico del DTE consiste en una firma electrnica, sobre los campos que se definen como representativos del documento e incluyendo el Cdigo de Autorizacin de Folios proporcionado por el SII. La firma que constituye el timbre electrnico 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 impresin de documentos. El contribuyente debe adecuar sus procedimientos y formularios utilizados para la impresin, con el fin de generar la representacin impresa segn la norma del SII, incluyendo el cdigo de barras 2D, simbologa PDF417, que contenga la informacin del cdigo del timbre electrnico. La informacin incluida en la impresin del Timbre Electrnico es: 1. Versin del timbre electrnico 2. Rut del Emisor 3. Tipo de Documento 4. Nmero de Folio 5. Fecha de emisin 6. Rut del Receptor 7. Razn Social Receptor 8. Monto total 9. Descripcin del primer Item del Detalle 10. Fecha y hora de generacin del timbre electrnico, 11. Cdigo de Autorizacin de Folios (proporcionado por el SII) 12. Algoritmo de firma (Hash y encriptacin) 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 propsito. - 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 informacin entre contribuyentes autorizados se deber tener habilitado como mnimo la posibilidad recibir y enviar informacin por email con un archivo adjunto que contenga los documentos, el comprobante de recepcin o rechazo, todos ellos en el formato XML establecido por el SII. Cada contribuyente autorizado tendr registrada en el SII la casilla electrnica a la cual se le debe enviar la informacin relacionada con factura electrnica: Envos de DTEs, Comprobantes de Recepcin y de Rechazo.

Aporte terico
Anlisis Requerimientos funcionales Emisor
Requerim iento D Funcional Implement ar una BD intermedia que soporte los R1- comprobante 00 s de pago 1 electrnicos que SUNAT ha habilitado para su transmisin Firmar R1- comprobante 00 s de pago en 2 el lado del EMISOR I Observaciones

Deber soportar FACTURA, BOLETA DE VENTA, NOTA DE CRDITO, NOTA DE DBITO, RESUMEN DE BOLETAS, RESUMEN DE BAJAS. Deber soportar el manejo de grupos empresariales.

-Firmar comprobantes de pago de tipo FACTURA, BOLETA DE VENTA, NOTA DE CRDITO, NOTA DE DBITO, RESUMEN DE BOLETAS, RESUMEN DE BAJAS. El componente en el emisor generar comprobantes de pago electrnicos a partir de los datos que proveer el emisor. (*) Los Recibos por honorarios estn en evaluacin por SUNAT por lo que su implementacin ser a futuro. - Se debe generar el xml y ser firmado electrnicamente de acuerdo a las especificaciones de SUNAT. - Segn lo decida el emisor la creacin del comprobante de pago electrnico podr generar un documento pdf en su servidor de archivos. -El componente en el emisor estructurar la informacin de los comprobantes de pago electrnicos en formato XML-UBL para su posterior transmisin. -El componente en el emisor se valdr de la documentacin actualizada que brinde SUNAT para la obligatoriedad de datos en el comprobante de pago electrnico. -El componente en el emisor utilizar la firma digital del EMISOR para la generacin del comprobante de pago electrnico. - El componente en el emisor no realizar clculo de IMPUESTOS, DESCUENTOS ni total, ni equivalencias de unidades y moneda. Solo validar la obligatoriedad de los campos que SUNAT requiere para la aceptacin del comprobante de pago electrnico (Ver documento Excel suministrado por SUNAT). - El componente en el emisor almacenar el comprobante de pago electrnico XML firmado - por un periodo de 5 aos. - El componente en el emisor generar los comprobantes de pago electrnico una vez que residan en la base de datos intermedia y

estn con estado "Por firmar"

Enviar los comprobante R1- s de pago 00 electrnicos 3 al ambiente de PSE

-El componente en el emisor transmitir los comprobantes de pago electrnicos desde el ambiente del EMISOR hacia el Portal de Negocios de PSE mediante el proceso de publicacin de comprobantes de pago electrnicos. -Se mantendr una segunda copia del archivo de peticin y respuesta de SUNAT acorde a los lineamientos que establece SUNAT. - Mediante el proceso de publicacin de comprobantes se crearn 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 electrnico Respuesta XML por un periodo de 1 ao. - Implementar un proceso automtico de reenvo, en caso se detecte alguna necesidad de reprocesamiento. Este proceso crea los comprobantes de pago electrnico y los enva directamente hacia SUNAT. Gestionando las respuestas de la entidad gubernamental y actualizando estados de las respuestas.

Enviar los comprobante R1- s de pago 00 electrnicos 4 directamente a SUNAT

Gestionar estados R1acorde a la 00 repuesta de 5 SUNAT

Gestionar R1estados del 00 documento 6

Los estados que contempla SUNAT son: Aceptado Rechazado Aceptado con observaciones Pendiente de Envo Anulado (*) Excepcin SUNAT (*) La validacin de aquellos comprobantes que hayan retornado una excepcin en la comunicacin hacia SUNAT podrn ser reprocesados segn la normativa vigente de SUNAT - La informacin de estados debe ser desde el componente web service de PSE. -El componente electrnico manejar el estado del documento, el cual involucra la relacin entre EL EMISOR-EL COMPROBANTE DE PAGO ELECTRNICO- EL ADQUIRIENTE -Los estados del documento contemplados son: Emitido (por el emisor electrnico) Anulado (por el emisor electrnico) Visualizado (por el Adquiriente) Aceptado (por el Adquiriente) Rechazado (por el Adquiriente)

Administra r comprobante R1s de pago 00 electrnicos 7 de grupos empresariales R Transmisi 1n de archivos 00 adjuntos 8

- 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 electrnico. - El componente en el emisor contemplar el manejo de grupo empresarial para la creacin y envo de comprobante de pago electrnico. Se debe poner a disposicin archivos adjuntos asociados al comprobante de pago electrnico para su posterior transmisin al Portal de Negocios del PSE. Se manejar una estrategia para la estructuracin de carpetas para su fcil transmisin

Componente en PSE
I D Requerimi ento Funcional Observaciones

-La generacin de comprobante de pago electrnico implica la firma electrnica del comprobante en el PSE. - Se debe almacenar el comprobante de pago electrnico XML Carga de firmado archivos para - Se firmar el comprobante de pago electrnico con la firma digital la generacin del EMISOR electrnico R3- masiva de - Se debe respetar el estndar xml solicitado por SUNAT. 00 comprobantes - El proceso debe ser online y por lotes para el caso de registro 1 de pago masivo. electrnicos en - Se elaborarn interfaces para el proceso de generacin de el lado del PSE comprobante de pago electrnico as como para su posterior envo hacia SUNAT. Al final del proceso se mostrar los archivos (de peticin y de respuesta) para su descarga. Publicar El Componente en el PSE deber recibir y almacenar R3- comprobantes comprobantes de pago electrnicos de tipo FACTURA, BOLETA, 00 de pago NOTA DE CRDITO, NOTA DE DBITO, RESUMEN DE BOLETAS, 2 electrnicos RESUMEN DE BAJAS. En adelante SUNAT habilitar la creacin de RECIBO POR HONORARIOS. El componente PSE no realizar clculo de IMPUESTOS, DESCUENTOS ni total. Solo validar la estructura del xml y la obligatoriedad de los campos que SUNAT requiere para la aceptacin del comprobante de pago electrnico. El Componente PSE extraer la informacin del comprobante de pago electrnico generado por el EMISOR y guardar la informacin en la base de datos (con esto la informacin podr ser consulta en el Portal de Negocios del PSE) para su posterior envo a SUNAT. El componente en el PSE enviar un correo electrnico notificando al adquiriente de la existencia de un comprobante de pago electrnico en el Portal de Negocios del PSE. Este correo electrnico podr adjuntar el comprobante de pago electrnico siendo esto

configurable por cada EMISOR y que deber indicarse en el proceso de publicacin del comprobante de pago electrnico. El emisor deber proveer el correo electrnico de cada uno de sus adquirientes. Cuando el estado SUNAT cambie se le informar al ADQUIRIENTE mediante un correo electrnico. El EMISOR podr enviar documentos asociados al comprobante de pago electrnico desde el componente en el emisor hacia el Componente PSE, quedando estos disponibles para su visualizacin en el Portal de Negocios para ello se tendr que definir la cantidad en kb mximo que se podr transmitir por cada comprobante de pago electrnico. Se crearn usuarios para los ADQUIRIENTES en el Portal de Negocios y se le enviar un correo electrnico notificando su usuario y contrasea. En caso de publique un comprobante de pago electrnico a un adquiriente que no cuente con un correo electrnico designado, se registrar automticamente un correo electrnico de un usuario asignado por el EMISOR para que realice la actualizacin de dicha informacin y sea el encargado de hacer llegar dicho comprobante de pago electrnico a su cliente. El Cliente ser el responsable de la actualizacin del correo electrnico de sus clientes, as como la asignacin de sus clientes que requieran recibir el comprobante de pago electrnico va correo electrnico en formato PDF. El emisor ser el responsable de actualizar el estado de envo para que el comprobante de pago electrnico se enve a SUNAT. Se obtendr un archivo de respuesta, la cual permitir actualizar el estado SUNAT. Se almacenar el comprobante de pago electrnico XML firmado por un periodo de 5 aos. Se almacenar la respuesta de SUNAT por cada comprobante de pago electrnico Respuesta XML por un periodo de 5 aos. - Implementar un proceso automtico de reenvo, en caso se detecte alguna necesidad de reprocesamiento. - Se enviarn todos los comprobantes de pago electrnicos hacia SUNAT a excepcin de la BOLETA ELECTRNICA. - Se enviar un correo cuando SUNAT haya respondido sobre el comprobante de pago electrnico enviado. El componente del PSE enviar correos electrnicos para mostrar un resumen de comprobantes procesados durante el ltimo da. El componente del PSE enviar correos electrnicos detallando los comprobantes de pago electrnicos errados en el proceso de transmisin a SUNAT. El envo de estos correos electrnicos podr ser configurado para su envo al EMISOR y al PSE: Se enviar un correo electrnico al finalizar la operacin del da (12:30 a.m.) donde se resumir la cantidad de comprobantes de pago electrnico 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).

Envo de comprobante R3de pago 00 electrnicos a 3 SUNAT

Implement R3- acin de 00 notificaciones 4 sobre los procesos de generacin, publicacin y envo de comprobantes de pago electrnicos

Se enviar 3 correo electrnico durante el da (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 electrnico con el listado de los comprobantes de pago que hayan reportado error y no se hayan solucionado hasta el momento.

Administrac in las R3certificados y 00 firmas 5 digitales. Implement acin de puntos de control a fin que el rea de soporte de produccin del R3PSE pueda 00 controlar el 6 reprocesamien to de comprobantes ante posibles problemas o contingencias.

El componente en el PSE manejar la lgica administracin de firmas digitales para los emisores que decidan cargar los comprobantes de pago electrnicos va archivo plano.

Se deber definir una interfaz donde el rea de produccin pueda acceder a la informacin de procesamiento de los comprobantes de pago electrnicos.

Consulta de R3- Comprobantes Se habilitar un Servicio Web desde donde el EMISOR podr 00 de pago extraer la informacin de sus comprobantes de pago electrnicos 7 electrnicos

Aplicacin Web
I D Requeri miento Funcional Observaciones

Se R4- dispondr 00 de una 1 Aplicacin Web que contar con los siguientes mdulos:

Portal Seguridad Mdulo Administracin Un sub-mdulo de administracin de usuarios, roles y permisos (a evaluar dependiendo de la solucin que se escoja). Dentro de este mdulo se contemplar la elaboracin de una interfaz que permita la actualizacin de los correos electrnicos de los adquirientes de manera manual. Se deber tener en cuenta la existencia de grupos empresariales para el manejo de usuarios. Se brindarn usuarios administradores este caso. Portal Per Mdulo Comprobantes Electrnicos Opcin Facturas Mostrar el listado de los comprobantes de pago electrnicos emitidos o recibidos. Se podr acceder al detalle de cada uno de ellos, e imprimirlos. Adems se mostrar el detalle de la informacin del comprobante de pago electrnico el cual podr ser impreso en formato pdf de manera individual o una lista segn los filtros que se apliquen. Se podr exportar comprimido la lista de comprobantes en formato xml, pdf y xsl. La impresin del comprobante de pago electrnico y resmenes de comprobante se mostrar en formato estndar del PSE incluyendo el cdigo hash y el cdigo de barras en la impresin en formato PDF417. La impresin del comprobante de pago electrnico tambin se contemplar la inclusin de campos adicionales para la impresin del comprobante de pago electrnico, estos sern personalizados por cada emisor. Comprobantes Emitidos En esta opcin los EMISORES de comprobantes de pago podrn ver los comprobantes electrnicos emitidos. Se mostrarn los comprobantes de pago en cualquier estado Comprobantes Recibidos En esta opcin los ADQUIRIENTES de comprobantes de pago podrn ver los comprobantes electrnicos recibidos. Solo se podrn 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 electrnico.

Opcin Resmenes de Baja Mostrar el listado de los resmenes de baja emitidos Opcin Resmenes de Boletas Mostrar el listado de los resmenes de boletas y notas de crdito y dbito asociado a boletas emitidos Opcin Estadsticas de Envo Un sub-mdulo de administracin y control sobre el proceso, la informacin y estados del comprobante de pago electrnico, se

mostrar, de acuerdo a filtros aplicados, un resumen de la cantidad de comprobantes de pagos electrnicos emitidos y la cantidad por estados. Esto puede ser impreso, exportado o enviado va mail. Opcin Carga Masiva Desde aqu se podr realizar la generacin de comprobantes de pago electrnico por carga de archivos donde el EMISOR decidir si el comprobante de pago electrnico realiza solamente el proceso de generacin y si adems completa todo el proceso el cual involucra el proceso de envo hacia SUNAT. El estndar del archivo plano que se cargar ser definido por el PSE. Un sub-mdulo para el control de impresin en lotes, exportacin a diversos formatos de comprobantes de pago electrnicos. Deber llevarse un control de la impresin, tanto del lado del emisor y del adquiriente electrnico, de manera que se sepa cuntas veces se ha impreso y mediante que usuario. La Aplicacin Web contar con un mdulo donde el ADQUIRIENT E podr R4 visualizar directament 00 e los 2 comprobant es de pago electrnicos recibidas, esta opcin tendr los siguientes parmetros: Se R4 implementa - r un Sub 00 mdulo 3 REGISTRO DE FACTURAS

Esta opcin tendr los siguientes parmetros: Tipo de documento del Emisor (RUC para Per). Tipo de Comprobante Nmero de Comprobante de Pago Electrnico (serie y correlativo) Fecha de Emisin Monto Total Opcional: Cdigo de Validacin. Esta opcin permitir visualizar directamente el documento en detalle y slo tener la opcin de imprimirlo en formato PDF y pudiendo archivar dicha informacin mediante la opcin de guardar copia de PDF.

Se deber contemplar todos los comprobantes de pago electrnicos 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 podrn registrar comprobantes de pago electrnico, tambin se podr enviar informacin sin firma digital. Se habilitar una opcin para la carga de adquirientes no registrados en el portal Permitir realizar referencias a documentos publicados en el portal de negocios: rdenes de compra, aceptacin de mercadera / servicios Podr controlar la opcin de publicacin a SUNAT (pudiendo facilitar la informacin slo al adquiriente). Se habilitar un opcin para que el emisor electrnico pueda realizar equivalencias de cdigo y descripcin de sus tems con la informacin publicada por el adquiriente (rdenes de compra, aceptacin de

mercadera / servicios Se manejarn estados adicionales: Borrador: Factura que no ha sido enviada aun al adquiriente, puede faltar registrar datos o no. Error de Recepcin: 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, slo recibido (no mapeado actualmente). Aceptado: Aceptada por el portal de negocios o contabilizada (registrada) en el ERP del adquiriente. Programado de Pago: Adquiriente realiza programacin del pago (actualmente no se realiza o es muy cercana a la fecha de pago). Bloqueado: Factura bloqueada en el ERP del adquiriente (por retencin de pago u otros). Pagado: Comprobante pagado en el ERP del adquiriente. Se debe mostrar la forma de pago.

Requerimientos no funcionales Componente Emisor

ID Requerimiento No Funcional Observaciones

R1Se asegurar la transmisin del 100% de 009 comprobantes Se debe implementar, con un nivel de seguridad R1- aceptable, la comunicacin de la informacin de 010 comprobantes de pago electrnicos desde el emisor hacia SUNAT. R1011

Implementar seguridad HTTPS

Para generacin El tiempo de transaccin no exceder los 5 segundos. del archivo firmado y comprimido.

El componente en el emisor ser escalable a fin de R1incluir mayor tipo de comprobantes de pago electrnicos 012 a futuro. - El componente en el emisor manejar errores tales como cada del sistema por saturacin de transacciones, es decir no debe perderse ningn comprobante de pago electrnico en ningn momento. En caso se corte el procesamiento de algn comprobante de pago electrnico, este debe ser vuelto a procesar al momento que el sistema vuelva a encontrarse estable. Deber mostrarse alertas, avisas por cadas de SUNAT. El componente en el emisor manejar mecanismos de retransmisin de datos en caso SUNAT responda con alguna excepcin. Se mantendr la traza del comprobante sabiendo en todo momento su

R1Se controlar los errores y excepciones de todo el 013 proceso.

R1014

Asegurar el 100% de la transferencia de informacin

estado y accin a realizar

Componente Proveedor de servicio facturacin

Requerimiento Funcional Observaciones Se deber asegurar la transmisin de comprobantes Se debe realizar un R3- de pago de hasta 1 milln de comprobantes por da o plan de pruebas de 008 hasta 10 millones al mes para un total de entre 10 a rendimiento. 100 clientes R3El tiempo de transaccin no exceder los 5 009 segundos. R3010 Se desea registrar todos los sucesos que ocurren en el sistema, a fin de reconstruir todas las actividades realizadas en la aplicacin. Los componentes tienen que tener la capacidad de recuperacin ante fallas. Se deben maneja habilitacin de tipos de sucesos. ID

R3011

R3012

La informacin se transmitir de forma tal de garantizar la integridad y autenticidad de la misma.

R3013 R3014

El diseo debe estar desarrollado de forma tal que pueda crecer con facilidad, ante la inclusin de nuevos canales de comunicacin El componente PSE podr manejar hasta 1 milln de comprobantes de pago electrnicos por da.

WS, MQ, JMS

Modelo de procesos

Componente s de Integracin Para Comprobante Electrnico

PSE Declarar CE Directamente Almacenar CE en PSE Firmar CE en Emisor
INICIO Leer Data de Base de Datos de PSE Generar Comprobante Electrnico

Sunat

Fin

INICIO

Leer CE Firmados

Almacenar Comprobante

Fin

INICIO Leer CE Almacenados Enviar a Sunat Directamente Procesar CE en Sunat

Fin

Actualizar Estado de CE con Rsta de Sunat

Diagrama de Casos de Uso

< < e x te n d > > < < e x te n d > >

E v a lu a r c o m p r o b a n t e e l e c t r n < i c< o x t e n d > >V e r d e t a l l e c o m p pr ir mo bi r a n t e e Im e le c t r n i c o

< < e x te n d > > < < e x te n d > >

A d q u i r i e D t ee s c a r g a a r c h i v o s a d j u n t o s n E le c tr n ic o

G e n e ra r c d ig o b a rra s

< < e x te n d > >

L a g e n e r a c i n i m p li c a la f i r m a y a lm a c e n a m i e n t o d e C D P C o n s u lt a r C o m p r o b a n t e s G e n e r a r c o m p r o b a n t e s R e g i s t r o M a s e i vl eo c t r n i c o s E le c tr n i c o C o m p r o b a n te
< < e x te n d > > < < e x te n d > > < < e x te n d > > < < in c lu d e > >

< < in c lu d e > >

E x p o r ta r a fo r m a to s d i fe r e n te s C o n s u lt a R e s u m e n d e < < e x te n d > > B o le t a s E m is o r E le c tr n i c o

< < e x te n d > > < < e x te n d > > < < e x te n d > > < < e x te n d > >

C o m p o n e n te e b iz

o en s R e g . M a s i v o d e R Ee ns vu m d e e d s o c uS me e en nt ov a na t o d o s lo s c o m p r o b a n t e s S U N A T S U NA T d e B o le t a s a e x c e p c i n d e la s b o l e t a s e l e c t r n i c a s V e r d e t a l le r e s u m e n c o m p r o b a n te < < e x te n d > >

< < e x te n d > > n C o n s u l t a r R e s u m e< n< ed x et e B da> j >a s < < e x te n d > >

C o n s u lt a d e C a r g a s M a s i v a s
< < e x te n d > >

R e g . M a s iv o d e R e s u m e n e s d e B a ja s

V e r d e t a ll e r e s u m e n d e b a ja s C o n s u l t a d e E s t a d s t i c a s

V e r d e t a lle c a r g a s m a s i v a s

Caso de Uso: Consulta Comprobantes

Emisor/Adquiriente Sistema

Se consulta el mdulo de comprobantes

Se muestra la interfaz de comprobante electrnico

Se muestra filtros dependiente si el que consulta es el adquiriente o emisor

Se aplican filtros

Se despliega la lista de comprobante electrnico

Qu opcin desea realizar el usuario?

Ver el detalle del comprobante

Implementacin CUS Ver Detalle Electrnico

Exportar

Se exporta en formato PDF, XML y archivos plano Se exporta el rango de comprobantes en formato PDF

El archivo de exportacin debe estar comprimido Se debe definir un mximo de comprobante a emitir

Se selecciona para imprimir lista continua

Se seleciona un comprobante para descargar archivos adjuntos

Se exporta los archivos adjuntos en formato zip

Se selecciona comprobantes para su envo a SUNAT

Ya fue enviado a SUNAT? SI Se muestra mensaje de enviado previamente

NO

Se declara los comprobantes seleccionados

Caso de Uso: Consulta Resumen de Comprobantes, Consulta de Resumen de Bajas

Emisor/Adquiriente

Sistema

Se consulta mdulo de resmenes

Se muestra la interfaz de resumen electrnico

Se aplican filtros

Se despliega la lista de resmenes

Qu opcin desea realizar el usuario?

Se selecciona para ver el detalle del resumen

Se muestra el detalle del resumen

Se selecciona para exportar

Se exporta en formato PDF, XML y archivos plano

(from State/Activity Model5)

El archivo de exportacin debe estar comprimido

Se selecciona comprobantes para su envo a SUNAT

(from State/Activity Model5)

Ya fue enviado a SUNAT?

Se muestra mensaje de enviado previamente

(from State/Activity Model5)

Se debe definir un mximo de comprobante a emitir

Se declara los resmenes seleccionados

Caso de Uso: Evaluar comprobante electrnico

Adquiriente Sistema

Ver detalle Comprobante

Se despliega detalle comprobante Puede ACEPTAR/RECHAZAR

SI

Puede evaluar el comprobante?

Actualiza el estado del comprobante Anular? Indicar motivo rechazo NO

Solo puede evaluar el comprobante si no est anulado o si ya ha sido evaluado previamente.

NO

Actualiza el estado del comprobante en BD Desea imprimir SIel comprobante? NO Imprimir Comprobante

Caso de Uso: Registro Masivo de Comprobantes, Registro Masivo de Resmenes de Baja, Registro Masivo de Resmenes de Comprobantes

Emisor

Sistema

Se selecciona la opcin "Registro Masivo"

Se despliega la interfaz de Registro Masivo de Comprobantes

Se selecciona la empresa del grupo empresarial Se validar estructura del archivo, parmetros obligatorios y si se tiene la firma digital de la empresa en cuestin

Se carga el archivo

Se procesa la carga de archivos

Validacin correcta? Se muestra la lista de archivos cargados valido e invlidos Se mostrarn aquellos que no pasaron correctamente y a aquellos que si.

Confirma la generacin de comprobantes electrnicos

Se invoca CUS Generar Comprobante Electrnico

Se muestra la lista de comprobantes electrnicos generados

Se muestra la opcin de enviarlos a SUNAT

Se enva a SUNAT

Se invoca CUS Enviar Comprobantes Electrnicos

Se confirma que los archivos estn siendo enviados a SUNAT

Consideraciones: Se podrn generar comprobantes electrnicos de tipo Factura, Boleta, Nota de crdito, Nota de dbito. Se deber considerar en caso la empresa pertenezca a un grupo empresarial. Solo se enviarn a SUNAT los comprobantes de tipo Factura, Nota de Crdito y Nota de Dbito.

Caso de Uso: Ver detalle comprobante electrnico

Para el adquiriente
Emisor Sistema

Se muestra el detalle de comprobante

Qu accin realiza el adquiriente?

Se muestran partes claramente diferenciadas 1. Cabecera (imagen de empresa, tipo de documento, direccin, etc). 2.Detalle (items, montos totales,cdigo hash, cdigo de barras) 3. Documentos adjuntos al comprobante estado ADQUIRIENTE: VISUALIZADO Se descargar uno por uno todos los archivos zip

Se descarga archivo adjunto

Evala el comprobante

estado ADQUIRIENTE: APROBADO/RECHAZADO

Imprimir el comprobante

Se exporta en PDF

Para el emisor
Emisor Sistema

Se muestra el detalle de comprobante

Qu accin realiza el emisor?

Se muestran partes claramente diferenciadas 1. Cabecera (imagen de empresa, tipo de documento, direccin, etc). 2.Detalle (items, montos totales,cdigo hash, cdigo de barras) 3. Documentos adjuntos al comprobante

Se descarga archivo adjunto

Uno por uno en un archivo

Imprimir el comprobante

Caso de Uso: Generar Comprobante Electrnico

Sistema

Sistema Remoto

Se invoca la generacin de comprobante electrnico

Se procesa la generacinde comprobante electrnico

Se devuelve confirmacin de generacin comprobantes electrnicos

Caso de Uso: Enviar Comprobante Electrnico

Sistema

Sistema Remoto

Se invoca el envo de comprobante electrnico

Se procesa el envo de comprobante electrnico

Se devuelve confirmacin de envo de comprobantes electrnicos

Caso de Uso: Consulta de carga masiva

Emisor Electrnico

Sistema Web

Se consulta la opcin de cargas masivas

Se muestra la interfaz de cargas masivas

Se aplican filtros

Se despliega lista de cargas masivas

Qu opcin desea realizar el usuario? Ver detalle de carga masiva Se implementa caso de uso: Ver detalle de carga masiva

Caso de Uso: Detalle de carga masiva

Emisor Electrnico

Sistema Web

Ver detalle de carga masiva

Muestra detalle de carga masiva

Muestra los comprobantes que no pasaron la validacin inicial, los comprobantes que tuvieron error en el proceso de firma y el total de comprobante en el archivo de carga

Descarga de lista

Arquitectura

A r q u ite c tu r a d e C o m p o n end e s Fd e tu rte c ianc iE le c tr n ic a e n P n te a c In a g r

C L IE N T E
ERP E Q U I P O IN T E G R A C I N
3.A l m a c eD a rc l a, r a r ,ne D e s p l e g a, ra cBtR s ta S ,u n a t .D E n v i a r a B D i n te r m e d i a 1. W S d e F i r m a Y d e p s i to e n B D i n te r m e d i a 2. E n v a a P/o E y S D e c la r a a S u n at

PSE

SUNAT

C ons um e W S S unat

C ons um e W S

D B ER P

A c tu a l iz a

D e s p le g a r u n W e b S e r v ic e q u e h a g a la f ir m, d e p o s it e l a d a t a a f ir m a d a e n la B D in t e r m e d ia y le d e v u e lv a la d a t a o n l in e a l c lie n t e

S i e l e n v o v ie n e p o r c o n f ig u r a c i n d e l p o r t a l y l a f ir m a e s p o r in t e g r a c i n s e d e b e e n v ia r ela p u edset a s S u n a t a la B D in t e r m e d ia

0. F i r m a o n l in e y a lm a c e n a 5aos o b ti e n e

4.W S S u n a t XM L XM L R e c i/be e i te m BD In te r m e d i a Lee / a c tu a l i z a E m i /te e c ib e r IN T E R N E T In te r n e t BD

Ca n a l d e Co m u n ica ci n se g u r o (W ,S Q M) 6.C o n s u l ta y a c t D e R s ta S u n a t 4.A c. tR s ta S u n a t Lee / a c tu a l i z a

P o rt al W e b

C o n f ig u r a y e n v a lis t a d e c o m p ro b a n t e a d e c la r a r
C ons um e W S 5. W S c o n r s ta S u n a t

7.F i r m aal m a c e n d e co l a r a c i n , , ad P or carga o m anual

E s t o s p ro c e s o s s o n p a ra c a rg a d e c o m p ro b a n te s d e s d e e l p o r t (d le m a n e r a m a s i v a o a r e g is t r o m) a n u a l

R e s p o n s a b ilid a d d e l E m is o r R e s p o n s a b ilid S d d e lP a E

R e s p o n s a b ilid a d d e Sunat

Generacin de Comprobantes Electrnicos en el Emisor con Integracin

En el Emisor
INICIO Recibe los paramettros de entrada de acuerdo a xml deSunat

Componentes en el Emisor

Componentes en PSE

WS de Sunat

Obtiene data de BD del ERP

Generar Comprobante Electrnico Operacin en bloques de n comprobantes x vez

Para cada tipo de Doc : Factura, Boleta , NC, ND, Resumen de Boletas , Resumen de Bajas

WS de Firma de CE

Si firma OK

El WS de Firma debe almacenar el xml , cdigo hash, etc necesarios para transferir a la BD de PSE

Devuelve xml , cdigo hash , pdf, etc . Obtiene rpta de Firma de CE Almacenar CE en BD intermedia Si Resumen Bajas ?

Si
Solo si el CE no est declarado

Firmar CE en Emisor

Almacena CE en BD propietaria

WS con datos de CE firmado

Si Adjuntos ?

Anular CE asociados al Resumen de Bajas

Si
Enviar Adjuntos a PSE

FIN

FIN

Almacenar adjuntos en bd PSE FIN

Si declarar ?

No

Proceso Enviar CE a PSE

Proceso Almacenar CE en PSE

Se debe desplegar los CE en una BD transaccional Enva email y el pdf del CE , solo facturas , NC, ND, Boletas

Enviar CE a PSE y/o Declarar a Sunat

Si
Enviarlo zipeado y en bloques de CE , tambin adjuntos El mecanismo puede ser a travs de Web Services o MQ Proceso Enviar CE a PSE y Declarar a Sunat

Notificacin al Cliente Fin Consume el WS de Sunat para declarar CE

Proceso Almacenar CE en PSE y Declarar a Sunat

Declarar CE a Sunat

INICIO

Consultar CE firmados y sin Declarar WS para Declarar a Sunat a travs de PSE Declarar CE a Sunat

WS para retransmitir Declaracin a Sunat a travs de PSE

Declarar CE a Sunat

INICIO

Si Rsta?

Si
Consultar CE firmados y en espera de rsta Sunat Proceso Act Rsta de Sunat

Consultar Rsta de Sunat

Xml con respuesta de sunat Obtiene rsta de Sunat

Proceso Actualizar Estado de CE con Rsta de Sunat

Proceso Enviar Rsta de Sunat al Emisor

WS con Rsta de Sunat

Notificacin al Proveedor

Actualiza estado de CE en BD propietaria

FIN Fin

Responsabilidad del Emisor

Responsabilidad de PSE

Responsabilid ad de Sunat

Generacin de Comprobantes Electrnicos por Registro desde el Portal PSE

Portal PSE
INICIO

Componentes en PSE

WS de Sunat

Registrar Comprobante

Recibe los paramettros de entrada de acuerdo a xml deSunat WS de Firma de CE

Generar Comprobante Electrnico

Si firma OK Devuelve xml , cdigo hash, etc. Obtiene rpta de Firma de CE Almacenar CE en BD de PSE El WS de Firma debe almacenar el xml, cdigo hash , etc necesarios y debe desplegar los CE en una BD transaccional Si Resumen Bajas ?

Firmar CE en PSE y/o Declarar a Sunat

Si declarar ?

Si
FIN Anular CE asociados al Resumen de Bajas Solo si no estn declarados

Si

Proceso Declarar CE a Sunat

Consume el WS de Sunat para declarar CE

Si Rsta?

Declarar CE a Sunat

Si
Proceso Actualizar Estado de CE con Rsta de Sunat

Fin INICIO Listar CE Firmados Consume el WS de Sunat para declarar CE Declarar CE Seleccionados Proceso Declarar CE a Sunat

Declarar CE a Sunat

Si Rsta?

Declarar CE a Sunat

Si
Proceso Actualizar Estado de CE con Rsta de Sunat

Este proceso debe verificar si el pedido de declaracin es desde el portal o desde el componente de integracin para iniciar otros procesos de sincronizacin

Fin INICIO Proceso Consultar CE

Consultar CE

Web Service que enva Rsta de Sunat y otros cambios de estado de los CE

Consume el WS provisto por PSE , ofrece la informacin de los CE en cualquier momento

Este WS debe enviar las notificaciones de los CE declarados y con otros cambios de estado

En el Portal

Responsabilidad de PSE

Responsabilidad de Sunat

Generacin de Comprobantes Electrnicos en el Emisor con Integracin

En el Emisor
INICIO Utilizando la BD Intermedia para luego devolver el resultado a travs de otro Web Service

Componentes en el Emisor

WS de Sunat

Obtiene data de BD del ERP

Web Service para Declarar a Sunat Declarar CE a Sunat Consume WS Si Rsta?

Declarar CE a Sunat

Operacin en bloques de n comprobantes x vez

Si
Proceso Actualizar Estado de CE con Rsta de Sunat

Declarar a Sunat Directamente

Consulta Rsta de Sunat Notificar que hay Rsta de Sunat

Consume WS Web Service que enva Rsta de Sunat y otros cambios de estado de los CE Este WS debe enviar las notificaciones de los CE declarados y con otros cambios de estado

Obtiene Rsta de Sunat

FIN

Consultar estado del CE

INICIO Proceso Consultar CE Consume el WS provisto por PSE , ofrece la informacin de los CE en cualquier momento

Web Service que enva Rsta de Sunat y otros cambios de estado de los CE

Este WS debe enviar las notificaciones de los CE declarados y con otros cambios de estado

Notificaciones

Responsabilidad del Emisor

Responsabilidad de PSE

Responsabilidad de Sunat

Diseo
a. Diagrama de clases de diseo
NotaCrdito ResumenBoletas ResumenBaja

Factura

Boleta

NotaDbito

Comprobante
serie-numero

Resumen
(from DIagrama Clases Diseo) identificador

DocumentoElectronico Moneda
codigoIso

tiene tiene

Documento
proveedor fechaEmision

puede ser

firmaElectronica cdigoHash fechaGeneracin informacionCdigoBarras

Estado pertenece

puede tener

puede referenciar a otro

puede tener ArchivoAdjunto

nombreDocumento

TipoDocumento Nota
codigo texto

b. Diagrama de componentes
Portal Seguridad Component e core-ebiz Componente Seguridad

Componente FE ebiz

Portal Peru

Descripcin de componentes Componente Descripcin Componente Es el componente que encapsula todas las funcionalidades core-ebiz comunes a los Portales Web incluyendo clases utilitarias y componentes de diseo. Adems contiene las interfaces para el acceso al componente de seguridad. Componente FE Es el componente que tiene todas las funcionalidades para ebiz la integracin del emisor con SUNAT para la publicacin y envo de facturas electrnicas. Componente Portal Web que permite la gestin de roles y perfiles de los Portal Seguridad usuarios de los dems Portales de Negocio. Componente Portal Web que permite el ingreso a proveedores y clientes Portal Per para la visualizacin de facturas electrnicas. Componente Componente que gestiona la lgica de administracin de

Seguridad

usuarios, roles y perfiles. c. Diagrama de despliegue

ServidorAplicaci onesPortalPeru Cliente Web

ServidorAplicacionesC omponenteSeguridad

ServidorBaseDatosPor talPeru

ServidorBaseDatosS eguridad

Componente Host Cliente Web Servidor Aplicaciones Portal Per Servidor Aplicaciones Componente Seguridad Servidor Base Datos Per Servidor Base Datos Seguridad

Descripcin Es el usuario final que ingresa al portal Es el servidor donde estar alojado el Portal Per. Es el servidor donde se alojar el componente de seguridad quin proveer la autorizacin mediante un login al portal Per. Es el servidor donde estar alojada la base de datos DB2 y el esquema que utilizar el portal. Es el servidor donde estar alojado la base de datos DB2 y el esquema que utilizar el componente de seguridad

d. Diseo lgico de base de dato

T M _F A C T U R A B O LE T A T R _D O C U M E N T O N O T A T D _ F A C T U R A B O L E T A IT E M P K_D O C U M E N T O T M _ N O T A C R E D IT O D E B IT O D _ N O T A C R E D IT O D E B IT O IT E M T P K_N O T A F K _ T I P O _ D O C U M E N T O ( F K P) K _ F A C T U R A IT E M P K_D O C U M E N T O P K _ N O T A _ C R E D IT O _ D E B IT O _ IT E M P K _ D O C U M E N T O (F K ) F K _ D O C U M E N T O F K _ T IP O _ M O N E D A (F K ) P K _ D O C U M E N T O (F K ) F K _ M O D U L O (F K ) C O _N O T A F K _ M O D U L O (F K ) N U _ P O S IC IO N F K _ D O C U M E N T O _ E L E C T RN O U N_ IPC OO S ( IF C K IO) N D E _N O T A F K _ D O C U M E N T O _ E L E C T R CO AN _I CIT OE (MF K ) F K _ T IP O _ M O N E D A ( F K ) C A _ IT E M U S U A _C R E A F K _ E S T A D O _ D O C U M E N T O C O _ U N ID A D _ M E D I D A F K _ E S T A D O _ D O C U M E N T O O _ U N ID A D _ M E D ID A C F E C H _C R E A F K _ T I P O _ E M I S IO N R _ 1 5 0 M O _ I M P O R T E _ S I N _ IM P U E S T O F K _ T IP O _ E M I S I O N M O _ IM P O R T E _ S IN _ IM P U E S T O U S U A _M O D I N U _ S E R IE _ N U M E R O M O _ I M P O R T E _ U N I T A R IO _ S IN _ IM P U E S F K _ T IP O _ D O C U M E N T O ( F KM ) O _ I M P O R T E _ U N IT A R I O _ S I N _ I M P U E S F E C H _M O D I F E _ E M I S IO N M O _ I M P O R T E _ U N I T A R IO _ C O N _ IM P U E S N U _ S E R IE _ N U M E R O M O _ I M P O R T E _ U N IT A R I O _ C O N _ I M P U E S N O _ C O R R E O _ E M IS O R C O _ T IP O _ P R E C IO F E _ E M IS I O N D E _ IT E M D A _ A N N IO _ F I S C A L M O _ I M P U E S T O _ IG V D A _ A N N I O _ F IS C A L C O _P R O D U C T O T R _ A R C H I V O _ A D J U NM TO O_ I M P O R T E _ S I N _ IM P U E SC TO O _ E X O N E R A C I O N _ I M P U E S T O _ I G V M O _ T O T A L _ D E S C U E N T O ST I_ P R E C I O M O _ I M P O R T E _ C O N _ IM P U E MS OT _O I M P U E S T O _ I S C P K _ A R C H IV O _ A D J U N T O M O _T O T A L_C A R G O S M O _ IM P U E S T O _ IG V M O _ T O T A L _ D E S C U E N T O S T I _ S I S T E M A _ I M P U E S T O _ IS C M O _T O T A L_A J U S T E C O _ E X O N E R A C IO N _ IM P U E S T O _ IG V M O _T O T A L_C A R G O S F K_D O C U M E N T O M O _D E S C U E N T O D E _ O B S E R V A C IO N R _ 1 0 O1 _ I M P U E S T O _ I S C M N O _ A R C H I V O _ A D J U MN O O I M P O R T E _ T O T A L T _ M O _C A R G O M O _ IM P U E S T O _ IG V T I_ S I S T E M A _ I M P U E S T O _ I S C O _ N O _ R U T A _ A R C H IV O M _ A D I JM U P NU T E OS T O _ I G V D E _P R O D U C T O M O _ IM P U E S T O _ IS C D C _D E S C U E N T O M O _ IM P U E S T O _ IS C F E _ E M IS IO N C O _P R O D U C T O M O _ IM P U E S T O _ O T R O S D C _ C A R G O M O _ IM P U E S T O _ O T R O S U S U A _C R E A U S U A _C R E A T I_ C O D I G O _ T R IB U T A R IO _ UE SM U IS A O _ R R E A C T I _ C O D IG O _ T R IB U T A R IO _ EF ME ICS HO _R C R E A F E C H _C R E A T M _M O N E D A N U _ T R IB U T A R I O _ E M I S O R F E C H _ C R E A N U _ T R IB U T A R IO _ E M IS O R U S U A _ M O D I U S U A _M O D I N P K _ T I P O _ M O N E D A T I_ C O D I G O _ T R IB U T A R IO _ UA SD UQ AU _ I RM IOE D I N O _ R A Z O N _ S O C I A L _ A D Q U F I RE ICE HN _T M E O D I F E C H _M O D I N U _ T R IB U T A R I O _ A D Q U I R F IEE NC TH E_ M O D I T I _ C O D IG O _ T R IB U T A R IO _ A D Q U IR IE N R _154 N O _ T IP O _ M O N E D AN O _ R A Z O N _ S O C IA L _ A D Q U I R IE N T E N U _ T R I B U T A R I O _ A D Q U IR I E N T E C O _ T I P O _ M O N E D AN O _ C O R R E O _ A D Q U IR I E N T E N O _ C O RR _ R2 E6 4O _ A D Q U I R I E N T E IN _ H A B I L IT A D O N O _ R A Z O N _ S O C IA L _ E M I S O R D I_ P A IS _ A D Q U IR IE N T E U S U A _ C R E A R _ 1 3 8N O _ C O M E R C I A L _ E M IS O R N O _ R A Z O N _ S O C I A L _ E M IS O R F E C H _C R E A U B _ E M IS O R N O _ C O M E R C IA L _ E M I S O R T R _ D O C U M E N T O R E F E R EU NS CU IA _ M O D I A D I_ E M IS O R U B _ E M IS O R _ T M _M E N S A J E P K _ D O C U M E N T O _ R E F E R F EE NC CH IA M O D I N O _ C O R R E O _ E M IS O R D I _ E M IS O R N O _ P A IS _ E M I S O R N O _ P A I S _ E M IS O R P K _M E N S A J E F K_D O C U M E N T O N O _ D E P A R T A M E N T O _ E M IS O R R _266 N O _ D E P A R T A M E N T O _ E M IS O R F K _ T IP O _ D O C U M E N T O (F K ) N O _ P R O V I N C IA _ E M I S O R N O _M E N S A J E N O _ P R O V I N C I A _ E M IS O R D A _ I D E N T IF I C A D O R N O _ D I S T R IT O _ E M IS O R N U _ D O C U M E N T O _ E NR O _ D I S T R I T O _ E M I S O R P I N _ E S A D IC I O N A L N O _ U R B A N IZ A C I O N _ E M IS O R B L_M E N S A J E N O _ U R B A N I Z A C IO N _ E M IS O R U S U A _C R E A N O _ D IS C R E P A N C I A _ D O C U M E N T O _ A F E C I N _ H A B IL I T A D O D E _ O B S E R V A C IO N R _ 2 3 F4 E C H _ C R E A C O _ M O T IV O _ D O C U M E N T O _ A F E C U S U A _ C R E AR _ 1 5 3 D A _ ID E N T I F IC A D O R _ E R P U S U A _M O D I N U _ S E R IE _ N U M E R O _ D O C U M E N T O _ A F E C F E C H _C R E A IN _ E S R E F E R E N C IA D O F E C H _M O D I D A _ ID E N T IF I C A D O R _ E R P U S U A _M O D I M O _T O T A L_G R A V A D O IN _ E S R E F E R E N C IA D O F E C H _M O D I R _235 M O _T O T A L_N O _G R A V A D O M O _T O T A L_G R A V A D O T I _ C O D IG O _ T R IB U T AM R O IO_ T O T A L _ E X O N E R A D O R _260 T M _M O D U LO M O _T O T A L_N O _G R A V A D O N U _ C O D I G O _ T R IB U TT AI _R M IOO N E D A _ P E R C E P C IO N M O _T O T A L_E XO N E R A D O M O _ P E R C E P C IO N P K_M O D U LO I N _ H A B I L IT A D O M O _ T O T A L _ C O N _ P E R C E P C IO N U S U A _C R E A D E _M O D U LO IN _ H A B IL I T A D O F E C H _C R E A N O _M O D U LO R _250 T M _ T I P O D O C U M E N T UO S U A _ C R E A U S U A _M O D I U S U A _C R E A F E C H _C R E A P K _ T IP O _ D O C U M E N T O F E C H _M O D I F E C H _C R E A U S U A _M O D I D A _ C O M E N T A R IO _ R E C H A Z O U S U A _M O D I FT E O C H _ M O D I C O _ T IP O _ D O C U M E N F E C H _M O D I N O _ T I P O _ D O C U M E N DT AO _ C O M E N T A R I O _ R E C H A Z O C O _G R U P O T R _ M O D U L O T IP O D O C U M E N T O I N _ H A B IL I T A D O P K _ T IP O _ D O C U M E N T O ( F K ) N O _ R U T A _ S E R V ID O R _ A R C H IV O S P K _ M O D U L O (F K ) R _252 U S U A _C R E A R _249 F E C H _C R E A U S U A _C R E A U S U A _M O D I F E C H _C R E A F E C H _M O D I R _258 U S U A _M O D I T R _ D O C U M E N T O _ E L E C T R FO E N C I CH O_ M O D I R _ 1 5 R5 _ 1 5 2 P K _ D O C U M E N T O _ E L E C T R O N IC O T M _ T A B L A _ M U L T IP L E F K _ T IP O _ D O C U M E N T O ( F K ) P K _ T A B L A _ M U L T IP L E F K _ E S T A D O _ S U N A T (F K ) T M _E S T A D O D O C U M E N T O F K _ E S T A D O _ D O C U M E N T O (F K )N O _ T A B L A P K _ E S T A D O _ D O C U M E N D O _ O B S E R V A C I O N _ S U N AR T_ 2 5 9 C O _ I T E M _ T A B L A T A N O _ A R C H I V O _ P E T I C IO N N O _C O R T O F K _ T IP O _ D O C U M E N T O ( F K ) B L _ D O C U M E N T O _ E L E C T R O N IC NO O _ L A R G O N O _E S T A D O _D O C U M E N T O R _ 1F 3H 3 _ IN S E R C IO N _ D O C U M E N T O IN _ H A B I L I T A D O D E _E S T A D O _D O C U M E N T O D A _ F IR M A _ E L E C T R O N IC A U S U A _C R E A I N _ H A B I L IT A D O R _269 D A _H A S H F E C H _C R E A U S U A _C R E A _263 R F H _ F I R M A _ E L E C T R O N IC A U S U A _M O D I F E C H _C R E A C O _ O R IG E N F E C H _M O D I U S U A _M O D I N O _ A R C H IV O _ R E S P U E S T A R _257 F E C H _M O D I B L _ A R C H IV O _ R E S P U E S T A C O _R E S P U E S T A R _268 T M _ C A R G A M A S IV A D E _R E S P U E S T A F H _ E N V IO _ S U N A T P K _ C A R G A _ M A S IV A F H _R E S P U E S T A _S U N A T T I_ C O D I G O _ T R IB U T A R I O D A _ C O D IG O _ B A R R A S N U _ C O D IG O _ T R IB U T A R IO R _262 N O _ A R C H IV O _ C O D IG O _ B A R R A S N O _ R A Z O N _ S O C IA L N O _ R U T A _ A R C H IV O _ C O D IG O _ B A R R A S F H _C A R G A N U _ V E R S IO N _ U B L R _271 C O _ ID E N T IF I C A D O R _ C A R G A N U _ P E R S O N A L IZ A C IO N F K _ E S T A D O _ C A R G A (F K ) U S U A _C R E A T R _ H IS T O R I A L _ E S T A D O _ D O C U M E N T O F K _ T IP O _ D O C U M E N T O (F K ) F E C H _C R E A N U _ C A R G A _ IN IC I A L P K _ H I S T O R I A L _ E S T U A SD UO A_ _D M O OC DU I M E N T O N U _ C A R G A _ E R R O R _ F O R T M R A _ TC OA R G A M A S IV A D E T A L L E F E C H _M O D I F K_D O C U M E N T O N U _ F IR M A D O S P K _ C A R G A _ M A S IV A _ D E T A L L E F K _ A C C IO N ( F K ) N U _ E R R O R _ F IR M A F K _ C A R G A _ M A S IV A (F K ) F K _ E S T A D O _ D O C U M E N T O (F K ) U S U A _C R E A D A _ I D E N T IF I C A D O R _ D O C U M E N T O D E _ O B S E R V A C IO N F E C H _C R E A R _256 R _ 2 7 0 F E _ E M IS I O N U S U A _C R E A U S U A _M O D I F K _ E S T A D O _ C A R G A _ D O C U M E N T O (F K ) F E C H _C R E A F E C H _M O D I U S U A _C R E A U S U A _M O D I T D _ R E S U M E N C O M PT RM O_ R AE N T EM IT N M O M P R O B A N RT EE S U M E N B A TJ AM IT RE EM S U M E N B A J A C O M P R O B A N T E B S U E E C T D _ _ F E C H _C R E A F E C H _M O D I P K _ R E S U M E N _ IT E M P K _ D O C U M E N T O P K _ R E S U M E N _ B AP J K A_ _D I TO EC MU M E N T O U S U A _M O D I P K _ D O C U M E N T O (F K ) P K _ D O C U M E N T O (F K ) F E C H _M O D I F K_E S T A D O _D O C U M E N T O D A _ I D E N T IF IC A D O R N U _ F IL A F K _ T I P O _ E M I S IO N F K _ D O C U M E N T O _ E L E C TN R U O_ NF ILC AO ( F K ) I F K _ T I P O _ D O C U M E N F T K O_ T ( FI P K O) _ E M IS IO N F K _ T I P O _ D O C R U _ M6 5 KN _ T D O O (CF UK M E N T O _ E L E C T R O N I C O ( F K ) E ) F F K _ T I P O _ M O N E D A ( FF KK _) E S T A D O _ D O C U M E N TN O _ S E R I E _ N U M E DR A O _ A N N I O _ F I S C A L U N U _ S E R IE D E _ M O T IV O _ B A J AN O _ C O R R E O _ E M IS O R R _ D5 7A _ A N N I O _ F I S C A L N U _ N U M E R O _ IN I C ION O _ C O R R E O _ E M I S O R U S U A _ C R E A D A _ I D E N T I F IC A D O R _ E R P N U _ N U M E R O _ F I N D A _ I D E N T IF IC A D O R _ E R PF E C H _ C R E A D A _ I D E N T I F IC A D O R M O _ IM P O R T E _ T O T AF L _ E M IS I O N U S U A _M O D I F E _ E M IS IO N E R _241 M O _ IM P U E S T O _ IG V F E _ G E N E R A C I O N F E C H _M O D I F E _ G E N E R A C IO N M O _ IM P U E S T O _ IS C T I_ C O D I G O _ T R I B U T A R I O _ E M I S T I_ C O D IG O _ T R I B U T A R I O _ E M I S O R M O _ IM P U E S T O _ O T RN O S_ T R IB U T A R I O _ E M I S O R N U _ T R I B U T A R I O _ E M IS O R U M O _ T O T A L _ C A R G O NS O _ R A Z O N _ S O C IA L _ E M I S O R N O _ R A Z O N _ S O C I A L _ E M IS O R M O _ T O T A L _ G R A V A ND UO _ C O M P R O B A N T E S N U _C O M P R O B A N T E S M O _ T O T A L _ N O _ G R IN V_ AH DA O I L I T A D O A IN _ H A B IL I T A D O B M O _T O T A L_E XO N E R S U O _C R E A U S U A _C R E A U A D A M O _ T O T A L _ V E N T A _F EE XC PH O_ R RT E C IO N E S A A F E C H _C R E A C U S U A _C R E A U S U A _M O D I U S U A _M O D I F E C H _C R E A F E C H _M O D I F E C H _M O D I U S U A _M O D I F E C H _M O D I R _242

e. Diseo fsico de base de datos

T D _ F A C T U R A B O L E T A IT E M P K _ D O C U M E N T O : B IG IN T T M _ N O T A C R E D IT O D E B I T O D _ N O T A C R E D I T O D E B I T O IT E M T P K _ F A C T U R A I T E M : B IG I N T F K _ T IP O _ D O C U M E N T O : B IG I N T ( F K ) P K _ D O C U M E N T O : B IG I N T P K _ N O T A _ C R E D I T O _ D E B I T O _ I T E M : B I G IN T P K _ D O C U M E N T O : B I G IN T ( F K ) K _ D O C U M E N T O : B I G I N FT K _ T IP O _ M O N E D A : B I G I N T ( F K ) P K _ D O C U M E N T O : B IG I N T ( F K ) F K _ M O D U L O : B IG I N T ( F K ) O _ N O T A : c h a r( 4 ) F K _ M O D U L O : B I G IN T ( F K ) N U _ P O S IC I O N : I N T E G E R F K _ D O C U M E N T O _ E L E C T R N O U N _ I PC OO S: BI C IGI O I NN T: IN F T K E) G E R ( E _ N O T A : V A R C H A R ( 1 0 F0 K) _ D O C U M E N T O _ E L E C T R O N CI CA O_ :IT B E I GM I N D T E ( CF KI M) A L ( 1 2 , 3 ) : F K _ T I P O _ M O N E D A : B I G I N T C (AF _K IT E M : d e c im a l ( 1 2 , 3 ) ) S U A _ C R E A : V A R C H A R F( 2K 5_ ) E S T A D O _ D O C U M E N T O : I N C T O E _ GU EN RI D A D _ M E D ID A : C H A R ( 3 ) U IN D E C H _ C R E A : T I M E S T A M F P K _ T IP O _ E M I S IO N : I N T E G E R M O _ I M P O R T E _ S IN _ IM P U E S T O : D E C I M A L ( 1 2 ,2 ) F K _ E S T A D O _ D O C U M E N T OC :O B _ I G N I T A D _ M E D I D A : c h a r ( 3 ) F S U A _ M O D I : V A R C H A R (N 2 U5 )_ S E R I E _ N U M E R O : V A R C H AM RO ( _2 I 0M ) P O R T E _ U N IT A R I O _ S IN _ IM P U E S : D E C IM A KL (_ 1T 2 I ,P2 O _ E M IS I O N : B I G I N T M O _ I M P O R T E _ S I N _ I M P U E S T O : d e c i m a l ( 1 2 , 2 ) ) F K _ T I P O _ D O C U M E N T O : B I M O _ T I M ( FP KO ) R T E _ U N I T A R IO _ S I N _ I M P U E S : d e c i m a l( 1 2 ,2 ) G IN E C H _ M O D I : T IM E S T A M FP E _ E M I S I O N : D A T E M O _ I M P O R T E _ U N IT A R I O _ C O N _ I M P U E S : D E C IM A L ( 1 2 , 2 ) N U _ S E R IE _ N U M E R O : v a r c h a O r (_2 I 0M ) P O R T E _ U N I T A R IO _ C O N _ I M P U E S : d e c im a l ( 1 2 , 2 ) M N O _ C O R R E O _ E M I S O R : V A R C H A R_ T( 5IP0 O _ P R E C I O : C H A R ( 2 ) ) C O F E _ E M I S IO N : D A T E D E _ IT E M : v a r c h a r ( 1 0 0 ) D A _ A N N I O _ F IS C A L : V A R C H A R M( 1O 0 _) I M P U E S T O _ IG V : D E C IM A L ( 1 2 , 2 ) D A _ A N N IO _ F I S C A L : V A R C HC AO R_ (P 1 R0 )O D U C T O : v a r c h a r ( 1 0 0 ) ( T R _ A R C H I V O _ A D J U N T O M O _ IM P O R T E _ S I N _ I M P U E S T OC :O D _ EE CX IM NA EL R1 A2 ,C2 )IO N _ IM P U E S T O _ IG V : C H A R ( 2 ) O M O _ T O T A L _ D E S C U E N T O ST :I _d Pe Rc im Ca IO( 1 : 2c , h a) r ( 2 ) 2 E l M O _ IM P O R T E _ C O N _ I M P U E S T MO O: D I EM CP I UM EA SL (T 1 O2 ,_2 IS C : D E C IM A L ( 1 2 , 2 ) ) _ P K _ A R C H I V O _ A D J U N T O : B IG I N T M O _ T O T A L _ C A R G O S : d e c iMm Oa _l( I1M2 P U) E S T O _ I G V : d e c im a l( 1 2 , 2 ) ,2 M O _ T O T A L _ D E S C U E N T O S : D TE I_ IS M I SA TL (E 1 M2 ,2 )_ I M P U E S T O _ I S C : C H A R ( 2 ) C A M O _ T O T A L _ A J U S T E : d e c imC O l_( 1E 2 X, 2O ) N E R A C I O N _ I M P U E S T O _ IG V : c h a r ( 2 ) a F K _ D O C U M E N T O : B I G IN MT O _ T O T A L _ C A R G O S : D E C I M AM L O( 1 _ 2 D, 2 E) S C U E N T O : D E C I M A L ( 1 2 ,2 ) D E _ O B S E R V A C I O N : v a r c h a Mr ( O2 0_ 0I M) P U E S T O _ I S C : d e c i m a l ( 1 2 ,2 ) A 2 N O _ A R C H IV O _ A D J U N T M :O V_ AIMR PC OH RA TR E( 2_ 0T ) O T A L : D E C I M M LO ( 1_ C , A2 )R G O : D E C IM A L ( 1 2 , 2 ) O M O _ I M P U E S T O _ I G V : d e c im T a I _l ( S 2I S, 2 T) E M A _ I M P U E S T O _ IS C : c h a r ( 2 ) 1 M N O _ R U T A _ A R C H IV O _ A D J O U_ NIM T PO U : EV SA TR OC _H I G R :( 1D 0 E0 C) I M A L D( 1E 2 _,2P ) R O D U C T O : V A R C H A R ( 1 0 0 ) A V M O _ I M P U E S T O _ I S C : d e c i m Da Cl( 1_ 2D ,2E ) S C U E N T O : d e c i m a l( 1 2 ,2 ) M O _ IM P U E S T O _ I S C : D E C I M A L C( 1O 2 _, 2P ) R O D U C T O : V A R C H A R ( 1 0 0 ) F E _ E M IS I O N : D A T E M O _ I M P U E S T O _ O T R O S : d D cC i _m Ca Al (R1 2G , 2O ) : d e c i m a l ( 1 2 ,2 ) e ( U S U A _ C R E A : V A R C H A R M ( 2O 5_ ) IM P U E S T O _ O T R O S : D E C IUM S A UL A 1 _ 2 C,2 R) E A : V A R C H A R ( 2 5 ) T I _ C O D I G O _ T R IB U T A R I O _ UE S UIS A O _ RC :R c Eh A r: ( V2 )A R C H A R ( 2 5 ) M a F E C H _ C R E A : T I M E S T A MT PI _ C O D IG O _ T R I B U T A R I O _ E M IFS E O C R H : _C C H R A E R A ( 2: T) IM E S T A M M _ M O N E D A T P N U _ T R IB U T A R I O _ E M IS O R F: E aC r H h_ aC r R( 2 E0 )A : T I M E S T A M P v c 2 U S U A _ M O D I : V A R C H A R N( 2U 5 _) T R I B U T A R I O _ E M I S O R : V A U R S C U H A A _ RM ( O 0D ) I : V A R C H A R ( 2 5 ) T I _ C O D I G O _ T R IB U T A R I O _ UA S UQ AU _I RM I O ND :I: c V h Aa rR ( 2C ) H A R ( 2 5 ) D E F E C H _ M O D I: T I M E S T A M N P O _ R A Z O N _ S O C IA L _ A D Q U I R IFE E N C T H E _ : MV A RD CI: H IAM R E ( 1 0T 0A ) M P P K _ T I P O _ M O N E D A : B IG I N T O T S N U _ T R IB U T A R I O _ A D Q U I R FI EE NC TH E_ :M C OH DA I R T ( 1IM8 ) E S T A M P : T I _ C O D IG O _ T R I B U T A R I O _ A D Q U I R I E N : C H A R ( 2 ) N O _ T I P O _ M O N E D A : V A R C_ RH AA ZR O( 1N 8 _) S O C I A L _ A D Q U I R IE N T E : v a r c h a r ( 1 0 0 ) N O N U _ T R I B U T A R I O _ A D Q U I R IE N T E : V A R C H A R ( 2 0 ) C O _ T IP O _ M O N E D A : c hN a Or ( 3 C) O R R E O _ A D Q U I R I E N T E : v a r c h a r ( 5 0 ) _ N O _ C O R R E O _ A D Q U I R IE N T E : V A R C H A R ( 5 0 ) IN _ H A B I L I T A D O : IN T E GN EO R _ R A Z O N _ S O C I A L _ E M I S O R : v a r c h a r ( 1 0 0 ) D I _ P A IS _ A D Q U I R IE N T E : V A R C H A R ( 1 0 0 ) U S U A _ C R E A : V A R C H A N R O ( 2_ 5C ) O M E R C IA L _ E M I S O R : v a r c h a r ( 1 0 0 ) N O _ R A Z O N _ S O C IA L _ E M I S O R : V A R C H A R ( 1 0 0 ) F E C H _ C R E A : T IM E S T AU MB P_ E M IS O R : c h a r ( 6 ) N O _ C O M E R C I A L _ E M I S O R : V A R T C R H _ AD R O ( C 0U 0 M) E N T O R E F E R E N C I A 1 U S U A _ M O D I: V A R C H A DR I_( 2 E 5 M) IS O R : v a r c h a r ( 1 0 0 ) U B _ E M IS O R : C H A R (6 ) T M _M E N S A J E P K _ D O C U M E N T O _ R E FF EE RC EH N_ M IA D BI : I T I M TE S T A NM O P _ C O R R E O _ E M I S O R : V A R C H A R ( 5 0 ) C O : G N D I_ E M IS O R : V A R C H A R (1 0 0 ) N O _ P A IS _ E M I S O R : c h a r ( 2 ) P K _ M E N S A J E : B I G IN T N O _ P A I S _ E M I S O R : C H A R ( 2 ) F K _ D O C U M E N T O : B IG IN T N O _ D E P A R T A M E N T O _ E M I S O R : v a r c h a r( 3 0 ) N O _ D E P A R T A M E N T O _ E M IS O R : FV K A _ RT CIP H O A _ RD ( O3 0C ) U M E N T O : B IG I N T ( F K ) N O _ P R O V IN C I A _ E M IS O R : v a r c h a r ( 3 0 ) N O _ M E N S A J E : V A R C H A NR O( 5_ 0 P ) R O V I N C IA _ E M I S O R : V A R C H A R ( 3 0 ) D A _ ID E N T IF IC A D O R : V A R C H A R ( 3 0 ) N O _ D I S T R I T O _ E M IS O R : v a r c h a r ( 3 0 ) N U _ D O C U M E N T O _ E R P N V O A _ R D C ISH T A RR IT( 2 O0 )_ E M I S O R : V A R C H A R ( 3 0 ) : I N _ E S A D IC I O N A L : I N T E G E R N O _ U R B A N IZ A C I O N _ E M I S O R : v a r c h a r ( 2 5 ) B L _ M E N S A J E : B L O B ( 1 0 0 N0 O _ U R B A N I Z A C I O N _ E M IS O R : V A R C H A R ( 2 5 ) ) U S U A _ C R E A : V A R C H A R (2 5 ) N O _ D IS C R E P A N C IA _ D O C U M E N T O _ A F E C : v a rc h a r(1 0 0 ) IN _ H A B I L I T A D O : IN T E G E D R E _ O B S E R V A C I O N : V A R C H A R ( 3 0 ) F E C H _ C R E A : T IM E S T A M P C O _ M O T IV O _ D O C U M E N T O _ A F E C : c h a r ( 2 ) U S U A _ C R E A : V A R C H A R D( 2A 5 _) I D E N T IF I C A D O R _ E R P : V A R C H A R ( 3 0 ) U S U A _ M O D I: V A R C H A R (2 5 ) N U _ S E R IE _ N U M E R O _ D O C U M E N T O _ A F E C : v a r c h a r ( 2 0 ) F E C H _ C R E A : T IM E S T A M I NP _ E S R E F E R E N C I A D O : I N T E G E R F E C H _ M O D I : T IM E S T A M P D A _ ID E N T I F I C A D O R _ E R P : v a r c h a r ( 3 0 ) U S U A _ M O D I: V A R C H A R M 2 5 ) _ T O T A L _ G R A V A D O : D E C I M A L ( 1 2 , 2 ) ( O IN _ E S R E F E R E N C IA D O : I N T E G E R F E C H _ M O D I : T I M E S T A M MP O _ T O T A L _ N O _ G R A V A D O : D E C I M A L ( 1 2 ,2 ) M O _ T O T A L _ G R A V A D O : D E C I M A L ( 1 2 ,2 ) T I_ C O D I G O _ T R I B U T A R I O :O C _ H T AO R T ( A2 )L _ E X O N E R A D O : D E C I M A L ( 1 2 , 2 ) M M O _ T O T A L _ N O _ G R A V A D O : D E C IM A L ( 1 2 , 2 ) N U _ C O D I G O _ T R IB U T A R T I OI _ :MV OA NR EC DH AA _R P ( 2E 0 R ) C E P C IO N : C H A R ( 3 ) T M _ M O D U L O M O _ T O T A L _ E X O N E R A D O : D E C IM A L ( 1 2 , 2 ) M O _ P E R C E P C IO N : D E C IM A L ( 1 2 , 2 ) P K _ M O D U L O : B IG I N T IN _ H A B I L I T A D O : I N T E G E R M O _ T O T A L _ C O N _ P E R C E P C IO N : D E C I M A L ( 1 2 , 2 ) U S U A _ C R E A : V A R C H A R (2 5 ) D E _ M O D U L O : V A R C H A R (1 0 0 ) I N _ H A B IL IT A D O : I N T E G E R F E C H _ C R E A : T IM E S T A M P N O _ M O D U L O : V A R C H A R (2 0 ) U S U A _ C R E A : V A R C H A R (2 5 ) T M _ T IP O D O C U M E N T O U S U A _ M O D I: V A R C H A R ( 2 5 ) U S U A _ C R E A : V A R C H A R (2 5 ) F E C H _ C R E A : T IM E S T A M P P K _ T IP O _ D O C U M E N T O : B IG I N T F E C H _ M O D I: T IM E S T A M P F E C H _ C R E A : T IM E S T A M P U S U A _ M O D I: V A R C H A R (2 5 ) D A _ C O M E N T A R IO _ R E C H A Z O : V A R C H A R (1 5 0 ) U S U A _ M O D I: V A R C H A R (2 5 ) H C O _ T I P O _ D O C U M E N T O F: CE HC A R_ M( 2 O) D I : T IM E S T A M P F E C H _ M O D I : T IM E S T A M P C C M N O _ T I P O _ D O C U M E N T O D: VA A_ R O H AE RN (T 2 A 0R ) IO _ R E C H A Z O : V A R C H A R ( 1 5 0 ) 0 C O _ G R U P O : C H A R (2 ) T R _ M O D U L O T IP O D O C U M E N T O I N _ H A B IL IT A D O : I N T E G E R N O _ R U T A _ S E R V ID O R _ A R C H I V O S : V A R C H A R ( 2 0 0 ) P K _ T I P O _ D O C U M E N T O : B IG I N T ( F K ) P K _ M O D U L O : B IG IN T (F K ) U S U A _ C R E A : V A R C H A R (2 5 ) P K _ N O T A : B IG I N T F C D U F U F F E C H _ C R E A : T IM E S T A M P U S U A _ M O D I: V A R C H A R (2 5 ) F E C H _ M O D I: T I M E S T A M P U S U A _ C R E A : V A R C H A R (2 5 ) F E C H _ C R E A : T IM E S T A M P U S U A _ M O D I: V A R C H A R (2 5 ) T R _ D O C U M E N T O _ E L E C T R FO EN C ICH O_ M O D I: T I M E S T A M P T M _ P AR A M E T R O P K _ D O C U M E N T O _ E L E C T R O N I C O : B I G IN T T M _ T A B L A _ M U L P T KI P_ P EA R A M E T R O : B IG I N T L F K _ T I P O _ D O C U M E N T O : B I G IN T ( F K ) P K _ T A B L A _ M U NL O I_ P P L AE R: BA IG E N T T R O : v a r c h a r ( 1 0 0 ) T M I F K _ E S T A D O _ S U N A T : B I G IN T ( F K ) T M _ E S T A D O D O C U M E N T O VR C C _ HV AA RL O 5 R0 ): v a r c h a r ( 1 0 0 ) F K _ E S T A D O _ D O C U M E N T O : B I N O _ T T (AF BK L) A : V A G IN ( P K _ E S T A D O _ D O C U M E N TD OA :_ BO IG SI N E T R V A C IO N _ S U N A T : V CA O _C IT E M (_ 5T 0 A0 )B VL AC :_ VD AE RS CC HR AI P R C ( I5O) N : v a r c h a r ( 5 0 ) B R H A R N O _ A R C H IV O _ P E T I C I O N : V A R CN HO A_ RC O 5 R0 ) T O : V AU RS CU HA A_ CR R( 2 E0 A : V A R C H A R ( 2 5 ) ( ) F K _ T IP O _ D O C U M E N T O : B IG IN T (F K ) C C B L _ D O C U M E N T O _ E L E C T R O N N OO _: L AL R G (O1 :0 V0 0AF) RE C HH A_ R R( 1 E0 A0 ): T IM E S T A M P IC B O B N O _ E S T A D O _ D O C U M E N T O : V A R C H A R (2 0 ) M F H _ I N S E R C IO N _ D O C U M E N T O I :N T _ I M AE BS T L A T MA PD OU : S I NU TA E_ G EO RD I : V A R C H A R ( 2 5 ) H I I D E _ E S T A D O _ D O C U M E N T O : V A R C H A R (2 0 ) D A _ F IR M A _ E L E C T R O N I C A : V A UR SC UH A _R C( 3R 0 E0 A ): VF AE RC CH H_ M RO (D2 5I: ) T I M E S T A M P 0 A I N _ H A B I L I T A D O : IN T E G E R D A _ H A S H : v a rc h a r (5 0 ) F E C H _ C R E A : T IM E S T A M P U S U A _ C R E A : V A R C H A R (2 5 ) F H _ F I R M A _ E L E C T R O N IC A : T I M U E S S UT AA _ MM P O D I : V A R C H A R ( 2 5 ) F E C H _ C R E A : T IM E S T A M P C O _ O R IG E N : V A R C H A R (2 0 ) F E C H _ M O D I : T IM E S T A M P U S U A _ M O D I: V A R C H A R (2 5 ) N O _ A R C H IV O _ R E S P U E S T A : V A R C H A R ( 2 0 ) F E C H _ M O D I: T I M E S T A M P B L _ A R C H IV O _ R E S P U E S T A : B L O B ( 1 0 0 0 ) C O _ R E S P U E S T A : V A R C H A R ( 1 0 0T ) A B L A _ M U L T IP L E s e D E _ R E S P U E S T A : V A R C H A R ( 2 0 0c )o n s i d e r a : F H _ E N V I O _ S U N A T : T IM E S T A M P C d i g o d e O ri g e n F H _ R E S P U E S T A _ S U N A T : T IM E SC T d iMg oP S U N A T A D A _ C O D IG O _ B A R R A S : V A R C H A CR ( 4d 0i g0 o) d e d o c u m e n to N O _ A R C H IV O _ C O D I G O _ B A R R A Str i: b V u Ata R r i C H A R ( 2 0 ) o N O _ R U T A _ A R C H IV O _ C O D I G O _ B A R R A S : V A R C H A R ( 2 0 0 ) N U _ V E R S IO N _ U B L : V A R C H A R (1 0 ) N U _ P E R S O N A L IZ A C I O N : V A R C H A R ( 1 0 ) U S U A _ C R E A : V A R C H A R (2 5 ) F E C H _ C R E A : T IM E S T A M P U S U A _ M O D I: V A R C H A R ( 2 5 ) T R _ H IS T O R I A L _ E S T A D O _ D O C U M E N T O F E C H _ M O D I: T IM E S T A M P P K _ H IS T O R I A L _ E S T A D O _ D O C U M E N T O : B I G I N T F F F D U F U F T R _D O C U M E N T O N O T A T M _F AC T U R A B O LE T A

T M _ C A R G A M A S IV A P K _ C A R G A _ M A S IV A : B IG I N T T N N F C F F N N N N U F U F

I _ C O D I G O _ T R IB U T A R IO : C H A R ( 2 ) U _ C O D IG O _ T R I B U T A R I O : V A R C H A R ( 2 0 ) O _ R A Z O N _ S O C IA L : V A R C H A R (1 0 0 ) H _ C A R G A : T IM E S T A M P O _ I D E N T IF I C A D O R _ C A R G A : V A R C H A R ( 2 0 ) K _ E S T A D O _ C A R G A : B IG I N T ( F K ) K _ T IP O _ D O C U M E N T O : B I G IN T ( F K ) U _ C A R G A _ IN I C I A L : I N T E G E R I U _ C A R G A _ E R R O R _ F O RT MR A_ CT AO R: I G AT E GA ES RV A D E T A L L E N M U _ F I R M A D O S : I N T E G E R P K _ C A R G A _ M A S IV A _ D E T A L L E : B I G I N T U _ E R R O R _ F IR M A : I N T E G E R K _ D O C U M E N T O : B IG IN T S U A _ C R E A : V A R C H A R ( 2 5 F ) K _ C A R G A _ M A S IV A : B IG I N T ( F K ) K _ A C C IO N : B I G I N T ( F K ) E C H _ C R E A : T I M E S T A M P D A _ ID E N T I F I C A D O R _ D O C U M E N T O : V A R C H A R ( 2 5 ) K _ E S T A D O _ D O C U M E N T O : B IG IN T (F K ) S U A _ M O D I: V A R C H A R ( 2 5 F) E _ E M I S IO N : D A T E E _ O B S E R V A C IO N : V A R C H A R ( 1 0 0 ) E C H _ M O D I : T IM E S T A M P F K _ E S T A D O _ C A R G A _ D O C U M E N T O : B IG I N T ( F K ) U S U A _ C R E A : V A R C H A R (2 5 ) S U A _ C R E A : V A R C H AT R D ( _2 R ) E S U M E N C O M P R O B A N T E I T E M 5 T B _ T M _ R E S U M E N C O M P R O D A RN ET SE U M E N B A J A T I TM E _ MR E S U M E N B A J A C O M P R O B A N T E F E C H _ C R E A : T IM E S T A M P E C H _ C R E A : T IM E S T A M P U S U A _ M O D I: V A R C H A R (2 5 ) S U A _ M O D I : V A R C H A R P( 2K 5 _ ) R E S U M E N _ I T E M P : KB _ IGD I ON CT U M E N T O : B I G I NP TK _ R E S U M E N _ B A J PA K_ _IT D E OM C : UB MI G E INN TT O : B I G I N T P K _ D O C U M E N T O : B I G IN T ( F K ) F E C H _ M O D I : T IM E S T A M P E C H _ M O D I: T I M E S T A M P P K _ D O C U M E N T O : B IG I N T ( F K ) F K _ E S T A D O _ D O C U M E N T O : B I G IN T D A _ I D E N T I F IC A D O R : v a r c h a r ( 3 0 ) N U _ F IL A : IN T E G E R F K _ D O C U M E N T O _ E L E CN TU R_ O I NL AIC : OI N : TB EI GG INE TR (FF KK _ ) T I P O _ E M IS I O N : B IG I N T F F K _ T I P O _ D O C U M E N FT K O_ :T B I PI GO I N ET M ( FI SK I )O N : B I G FIN K T _ T I P O _ D O C U M E NF TK _O D: B IG UI N M T E ( NF KT )O _ E L E C T R O N IC O : B IG I N T ( F K ) O C _ F K _ T I P O _ M O N E D A : B IKG _ I EN ST T ( A KD ) O _ D O C U M E NN UT _O S: E IRG I IEN _ TN U M E R DO A: v_ aA r Nc hN a IO ( 2_ 0F ) I S C A L : V A R C H A R ( 1 0 ) F r F B N U _ S E R I E : v a r c h a r ( 4 D) A _ A N N I O _ F I S C A L : V A D E H MA O T( 1 I 0V )O _ B A J A : Nv aO r _c Ch aO r R( 1 R0 0E ) O _ E M I S O R : V A R C H A R ( 5 0 ) R C _ R N U _ N U M E R O _ I N I C I O N : OV _A CR OC RH RA ER O( 1 _ 5 E ) M I S O R U V S A U R A C _ HC AR RE (A5 :0 V) A R C DH AA _R I D( 2 E5 N) T I F I C A D O R _ E R P : V A R C H A R ( 3 0 ) : N U _ N U M E R O _ F IN : V DA AR _ C I DH EA NR T( 1I F5 )IC A D O R _ E FR EP C: H A_ C RC EH AA : R T ( I3M0 E S DT AA _ MI DP E N T I F I C A D O R : v a r c h a r ( 3 0 ) V R ) M O _ I M P O R T E _ T O T AF LE : _ d Ee Mc i Im IaO l (N1 2: D A T E ,2 ) U S U A _ M O D I : V A R C HF EA _R E ( 2 5 IS I O N : D A T E M ) S M O _ I M P U E S T O _ I G V F: dE e_ cG imE aN l(E 1 R 2 A 2 C) IO N : D A T FE E C H _ M O D I : T I M E S FT EA _M G P E N E R A C IO N : D A T E , M O _ I M P U E S T O _ I S C :T d I _e Cc iOm Da IG( 1 O2 _,2 T) R I B U T A R I O _ E M I S : c h a r ( 2 ) l T I_ C O D I G O _ T R I B U T A R IO _ E M IS O R : c h a r ( 2 ) M O _ I M P U E S T O _ O T RN OU S_ :T d R e I cB im Ta A ( 1R 2 I ,O2 )_ E M I S O R : v a r c h a r ( 2 0 ) N U _ T R I B U T A R IO _ E M I S O R : v a r c h a r ( 2 0 ) U l M O _ T O T A L _ C A R G O N :O d _ e R c Ai mZ aO l (N1 2 S,2 O) C IA L _ E M IS O R : v a r c h a r ( 1 0 0 ) N O _ R A Z O N _ S O C I A L _ E M I S O R : v a r c h a r ( 1 0 0 ) S _ M O _ T O T A L _ G R A V A D O :_ DC E CM I M RA O ( B1 2A ,2 ) T E S : I N T E G E R N U _ C O M P R O B A N T E S : IN T E G E R N U O P L N M O _ T O T A L _ N O _ G R A N V _ AH DA OB :ILD ITE AC DIM O A : LI N( 1 T 2 E, 2 G) E R IN _ H A B I L I T A D O : IN T E G E R I M O _ T O T A L _ E X O N E RU AS DU OA :_ DC ER CE IM : AV LA ( 1 2 C, 2H ) A R ( 2 5 ) U S U A _ C R E A : V A R C H A R (2 5 ) A R M O _ T O T A L _ V E N T A _F EE XC P H O _ RC TR AE CA I :O T NIME ES S: DT EA CM I PM A L ( 1 2 ,2 ) F E C H _ C R E A : T IM E S T A M P U S U A _ C R E A : V A R C HU AS RU (A2 5 M O D I : V A R C H A R ( 2 5 ) ) U S U A _ M O D I: V A R C H A R ( 2 5 ) _ F E C H _ C R E A : T I M E S FT EA CM H P _ M O D I: T I M E S T A M P F E C H _ M O D I: T IM E S T A M P U S U A _ M O D I: V A R C H A R (2 5 ) F E C H _ M O D I : T IM E S T A M P

f. Diccionario de base de datos

Ver anexo 2. Prototipos e Implementacin a. Portal de negocio

El usuario podr consultar sus comprobantes de pago electrnicos accediendo al Portal de Negocios

b. Vista proveedor

i. Opcin Comprobante Electrnico

IMPORTANTE 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. 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 razn social del proveedor este campo se rellenar automticamente. El filtro razn social del proveedor ser un combo. Los campos de texto RUC y RAZN SOCIAL del cliente sern listas inteligentes.

Al final de la lista de comprobantes se aadirn los campos de auditora. Los mensajes de validaciones tales como Solo puede ver el detalle de un registro a la vez se realizarn mediante ventanas modales emergentes.

Para el caso de Boletas el botn Enviar comprobantes enviar un mensaje de informacin.

ii. Opcin Comprobante Electrnico - Botones 1. Botn Registrar

a. Va Carga de archivo

IMPORTANTE En esta pantalla solo se podrn generar comprobantes electrnicos de tipo Factura, Boleta, Nota de crdito, Nota de dbito.

Al final de la lista de registro de cargas masivas se aadirn los campos de auditora. Cuando se presione el botn generar comprobantes, se cerrar la pgina actual y se cargarn los comprobantes generados en la opcin Comprobantes Electrnicos 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 razn 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 razn social del proveedor este campo se rellenar automticamente En la opcin Comprobantes Electrnicos solo se enviarn los comprobantes de tipo Factura, Nota de Crdito y Nota de Dbito. Por recomendacin del Product Manager cambiar el botn Browse por Cargar Todas las vistas con el cono llamarn a una pantalla de bsqueda de empresas. El cono solo se mostrar en ambiente de desarrollo, para produccin debe ocultarse el cono. Los mensajes de validaciones tales como Solo puede ver el detalle de un registro a la vez se realizarn mediante ventanas modales emergentes. Para el caso de Boletas el botn Generar comprobantes y enviar quedar desactivado. El botn Generar Comprobantes lanzar la siguiente ventana de dilogo:

El botn Generar Comprobantes y Enviar lanzar la siguiente ventana de dilogo:

2. Botn Imprimir

3. Botn Enviar a SUNAT

4. Botn Descargar

5. Botn Ver Detalle a. Detalle de la Factura

b. Detalle de la Factura - Botones i. Botn Imprimir Imprime el comprobante en formato PDF. ii. Botn Descargar Descarga el documento XML en formato ZIP.

iii. Impresin en PDF Factura

IMPORTANTE Para la composicin de la direccin se concatenar los siguientes campos: Direccin Completa y Detallada Departamento Provincia Distrito Para la transmisin de documento referenciados se crear un nuevo tipo de documento referenciado para las rdenes de Compra El sub-total ser mandatorio para la transmisin de comprobante electrnico.

Los campos ISC, otros tributos y otros cargos, debern aparecer en el documento si su valor es mayor que cero. La seccin percepcin deber aparecer en el documento si su valor es mayor que cero. El tipo de comprobante (RUC para Per) debe ser parametrizable. Boleta

IMPORTANTE Para la composicin de la direccin se concatenar los siguientes campos: Direccin Completa y Detallada Departamento Provincia Distrito Para la transmisin de documentos referenciados se crear un nuevo tipo de documento referenciado para las rdenes de Compra El sub-total ser mandatorio para la transmisin de comprobante electrnico. Los campos ISC, otros tributos y otros cargos, debern aparecer en el documento si su valor es mayor que cero.

La seccin percepcin deber aparecer en el documento si su valor es mayor que cero. El tipo de comprobante (RUC para Per) debe ser parametrizable. Nota de crdito

IMPORTANTE Se copiar el motivo o asunto en la descripcin del tem cuando este venga vaco, y el asunto no aparecer en Observaciones del Comprobante. Nota de dbito

IMPORTANTE Se copiar el motivo o asunto en la descripcin del tem cuando este venga vaco, y el asunto no aparecer en Observaciones del Comprobante.

iii.

Resumen de Boletas

IMPORTANTE Al final de la lista se aadirn los campos de auditora. El campo de texto RUC del proveedor ser siempre de solo lectura. Cuando se seleccione una empresa del combo razn social del proveedor este campo se rellenar automticamente 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 - Botones 1. Botn Registrar

a. Va carga de archivo

IMPORTANTE Al final de la lista de registro de cargas masivas se aadirn los campos de auditora. El campo de texto RUC del proveedor ser siempre de solo lectura. Cuando se seleccione una empresa del combo razn social del proveedor este campo se rellenar automticamente Cuando se presione el botn generar comprobantes, automticamente pasar a la opcin Resumen de Boletas o Resumen de Bajas. Debern aparecer los registros. 2. Botn Enviar a SUNAT

3. Botn Descargar

4. Botn Ver Detalle

v. Detalle Resumen de Comprobantes

IMPORTANTE Al final de la lista de detalle de resumen de comprobantes se aadirn los campos de auditora. vi. Resumen de Bajas

IMPORTANTE El campo de texto RUC ser una lista inteligente. Al final de la lista de registro de cargas masivas se aadirn los campos de auditora. 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 razn social del proveedor este campo se rellenar automticamente vii. Opcin Resumen de Bajas - Botones 1. Botn Registrar

a. Va carga de archivo

2. Botn Enviar a SUNAT

3. Botn Descargar

4. Botn Ver Detalle a. Detalle de Resumen de Bajas

IMPORTANTE Al final de la lista de detalle de resumen de bajas de comprobantes se aadirn los campos de auditora. 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. Botn Ver Detalle IMPORTANTE Al final de la lista de registro de cargas masivas se aadirn los campos de auditora. Aqu se mostrar la pantalla Ver Detalle del Comprobante de Pago (Factura, Boleta, N/C, N/D) viii. Opcin Estadsticas de envo

IMPORTANTE Cuando se seleccione un registro y luego Ver Listado pasar a la vista de Bsqueda de Comprobantes o Bsqueda de Resumen de Comprobantes o Bsqueda 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 razn social del proveedor este campo se rellenar automticamente.

ix. Configuracin 1. Certificado Digital

IMPORTANTE Al final de la lista de registro de cargas masivas se aadirn los campos de auditora. El campo de texto RUC del proveedor ser siempre de solo lectura. Cuando se seleccione una empresa del combo razn social del proveedor este campo se rellenar automticamente.

2. Usuario Sol / Clave Sol

IMPORTANTE Al final de la lista de registro de cargas masivas se aadirn los campos de auditora. El campo de texto RUC del proveedor ser siempre de solo lectura. Cuando se seleccione una empresa del combo razn social del proveedor este campo se rellenar automticamente.

3. Notificaciones a. Proveedor i. Bsqueda de Notificaciones

ii. Detalle Notificaciones

iii. Nueva notificacin

iv. Bsqueda de Usuarios

v. Bsqueda de contactos

b. Cliente i. Lista de notificaciones

ii. Detalle de notificaciones

IMPORTANTE En el comprobante de pago se contemplar un correo electrnico por parte del proveedor el mismo que servir para enviar e-mail cuando el comprobante de pago sea declarado. En caso el correo electrnico no est presente en el comprobante se deber contemplar el correo electrnico que el proveedor declar en el Portal de Negocios para este fin. Los horarios sern configurables internamente por cada proveedor.

4. Clientes

IMPORTANTE Cuando 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 razn social del proveedor este campo se rellenar automticamente En el comprobante de pago se contemplar un correo electrnico por parte del cliente el mismo que servir para enviar e-mail cuando el comprobante de pago sea publicado. En caso el correo electrnico no est presente en el comprobante se deber contemplar el correo electrnico que el proveedor declar en el Portal de Negocios para este fin.

a. Detalle de excel de entrada RAZN RUC SOCIAL CLIENTE Graa y Montero 56446465 Digitales S.A. 46 Cosapi S.A. 54564654 64 Graa y 23112341 Montero S.A. 54 Graa y 31365464 ENVIAR CORREO SI SI SI SI NO SI NO e mtorres@gym.com.pe ksalgado@gmp.com.p ADJUNTAR PDF e SI Lzapata@cosapi.com.p MAIL DE CONTACTO kramirez@gmd.com.p

Montero Petrleo S.A. R E AZ NVI N R AR SOC UCC CO IAL LIE RRE NTE O G S ra I ay Mon tero Digi 5 tale 644 s 646 S.A. 546 C 5 S osa 456 I pi 465 S.A. 464 G S ra I ay 2 Mon 311 tero 234 S.A. 154 G N ra O ay Mon tero 3 Petr 136 leo 546 S.A. 445

e 45 b. Botn Descargar Configuracin MAIL A DE DJU CONTA EMITI EMI EMITI NTA CTO DOS TIDOS DOS R ULTIMO ULTIMO ULTIMA PDF AO MES SEMANA kra mirez@ gmd.co m.pe VISU ALIZAD VISUA OS LIZADOS VISUALIZ ULTIMA ULTIMO ADOS SEMAN AO ULTIMO MES A

S I Lzap ata@.co S sapi.co m.pe mtor res@gy m.com. pe S ksal gado@g mp.com .pe N O 21 132 321 321 3213 21 20 231 654 654 564 321

54

54

231

564

15

654

54

564

654

c. Cliente i. Comprobantes Electrnicos

ii. Comprobantes Electrnicos - Opciones 1. Botn Imprimir

2. Botn Descargar

3. Botn Ver Detalle a. Detalle de Comprobante

d. Administrador del Portal

Conclusiones

128

Glosario
PSE : Proveedor de servicios

129

Bibliografa
1.

2.

3.

4.

5.

6.

Application Integration EAI, B2B, BPM and SOA Autor : Bernard Manouvrier Editorial : Wiley Ao : 2008 B2B Integration Autor : Gunjan Santani Editorial : Imperial College Press Ao : 2003 Building B2B applications using XML Autor : Michael Fitzgerald Editorial : Wiley Computer Publishing Ao : 2002 ebXML Simplified Autor : Eric Chiu Editorial : Wiley Computer Publishing Ao : 2003 Innovative Tools for Business Coalitions in B2B Applications Autor : Pierluigi Argoneto Paolo Renna Editorial : Springer Ao : 2006 Sunat Pgina oficial Autor : SUNAT Direccin : www.sunat.gob.pe

130

Anexo
1.1. Diccionario de datos

131