Este documento es un material de especificación de los requisitos de innovación. Se trata de un contenido sumamente técnico. |
---|
Especificación | |||
Producto | Microsiga Protheus | Módulo | SIGAFAT |
Segmento ejecutor | Servicios | ||
Projeto1 | Proyecto de Desarrollo_MEX | IRM/EPIC1 | |
Requisito/Story/Issue1 | SERINN001-1144 /SIGAFAT | Subtarea1 | SERINN001-1158 |
Chamado/Ticket2 |
| ||
País | ( ) Brasil ( ) Argentina ( ) México ( ) Chile ( ) Paraguay ( ) Ecuador ( ) EEUU ( ) Colombia ( X) Otro PERU. | ||
Otros |
Leyenda: 1 – Innovación 2 – Mantenimiento
Crear la rutina Documentos Electrónicos (MATA486) , que permita realizar la transferencia y monitoreo de los documentos fiscales:
Hacia TSS en formato xml bajo el estándar UBL que solicita la SUNAT. Además deberá permitir envíar el Resumen Diario, Comunicaciones de Baja, así como generar la representación impresa de los documentos Factura. Boleta, nota de crédito y Débito
Al ingresar a la rutina, deberá permitir elegir el tipo de documento o modelo (Prototipo 1) con el que se estará trabajando así como la serie a manejar. Estos son:
Visualizará el browse del rutina (Prototipo 2). Dentro de las opciones de la rutina, se encontrarán:
Opción Configuración:
Esta opción Configuración (Prototipo 3) permitirá configurar la conexión de Protheus con TSS. Se abrirá un wizard (Prototipo 4) en dónde pedirán los siguientes datos:
Al dar clic en “Avanzar”, deberá detonar la siguiente funcionalidad:
Si alguno de los datos está vació, deberá enviar mensaje al usuario y no continuar con el proceso.
Usertoken : “TOTVS”
Empresa:
El idEnt que retorna el web Method, deberá ser utilizado en el siguiente paso.
Usertoken : “TOTVS”
ID_ENT: Id Ent obtenido en el paso anterior.
Certificate: Archivo de certificado
Password: Contraseña del Certificado.
Opción Transmitir.
Esta opción tiene como objetivo realizar el proceso de transmisión de un documento hacia TSS. Esta opción deberá permitir ser llamada desde cualquier otra rutina.
Al detonar esta opción, se mostrará el grupo de preguntas correspondiente según el tipo de documento a enviar. Para Factura de Venta mostrar grupo de preguntar MATA486A(Prototipo 5), para Nota de Crédito mostrar gropo de preguntas MATA486B, para notas de Crédito mostrar grupo de preguntas MATA486C, Para Boleta de Venta mostrar grupo de preguntas MATA486D y para guías de Remisión mostrar grupo de preguntas MATA486E. En todos los grupos de pregunta, se deberá indicar Serie del documento y rango a transmitir. Al dar clic en ok, deberá:
Si alguno se encuentra vacío, se deberá informar al usuario y no permitir seguir con el proceso.
Ejemplo “Falta informar Código Postal del Emisor. Revise Datos de la Empresa:” + SM0->SM0_NOME
RUC (A1_CGC)
Nombre(A1_NOME)
Domicilio fiscal (A1_END, A1_EST,A1_BAIRRO, A1_MUN, A1_PAIS, A1_CEP)
Tipo de documento de Indentificación(A1_TIPDOC)
Email (A1_EMAIL)
Para el caso del tipo de Identificación (A1_TIPDOC), deberá revisar que el código exista en la tabla XN- Tipos de Identificación. Así mismo, deberá validar que el Código de País (A1_PAIS) contenga su equivalente en el campo YA_CODERP y que además este código se encuentre contenido en la tabla XT – Códigos de Países.
Si alguno de los datos anteriores falta deberá agregar un registro al log de transmisión indicando el dato faltante para el documento. Ejemplo:
Documento Serie Cliente Tienda Detalle
0000000001 A 000001 01 Información faltante registro cliente RUC (A1_CGC)
0000000001 A 000001 01 Información faltante registro cliente País(A1_PAIS)
Por cada impuesto contenido en la TES deberá validar que el impuesto tenga configurados los campos Código de Impuesto (FB_CODIMP) y Tipo de Afectación del IGV(FC_TIPOIGV) o del ISC(FC_TIPOISC) y que además el contenido de estos campos exista en la tabla XR en SX5 para IGV o tabla XR del ISC según corresponda. Si no tiene configurados los campos, deberá agregar un registro al log de transmisión como a continuación:
Documento Serie Cliente Tienda Detalle
0000000001 A 000001 01 Debe configurar Código de Afectación(FC_TIPOIGV) para impuesto IGV. TES 501
0000000001 A 000001 01 Debe configurar Código de Impuesto(FB_TIPOIGV) para IGV. TES 501
Continuar con las validaciones.
Ejemplo:
Documento Serie Cliente Tienda Detalle
0000000001 A 000001 01 Configure Serie 2 (FP_SERIE2)
USERTOKEN: “TOTVS”
IDENT: id de Entidad obtenido en los pasos anteriores.
Modelo: Enviar según el tipo de Documento
S1- Factura Venta
S4 – Nota Crédito
S5 – Nota Débito
S6 – Guia Remision
S7- Comprobante Retención
SD - Boleta de Venta
XML: Deberá enviarse XML Generado codificado en base 64.
Si el retorno del Web Method es positivo agregar registro en el log de transmisión:
Documento Serie Cliente Tienda Detalle
0000000001 A 000001 01 Transmisión Éxitosa a TSS.
USERTOKEN: “TOTVS”
IDENT: id de Entidad obtenido en los pasos anteriores.
Modelo: Enviar según el tipo de Documento
S1- Factura Venta
S4 – Nota Crédito
S5 – Nota Débito
S6 – Guia Remision
S7- Comprobante Retención
SD - Boleta de Venta
XML: Deberá enviarse XML Generado codificado en base 64.
Si el retorno del Web Method es positivo agregar registro en el log de transmisión:
Documento Serie Cliente Tienda Detalle
0000000001 A 000001 01 Transmisión Éxitosa a TSS.
Continuar con el siguiente registro.
Documento Serie Cliente Tienda Detalle
0000000001 A 000001 01 El documento no cumple con Esquema Establecido. Rechazado TSS.
Opción Monitor
El objetivo de esta opción, es obtener el resultado de la transmisión de los documentos a TSS. La funcionalidad podrá detonarse mediante selección en el menú (se considera que esta función no sea de tipo estática, para que pueda ser llamada desde cualquier otra rutina). Si la opción es llamada desde el menú del a rutina de documentos Electrónicos:
USERTOKEN: “TOTVS”
IDENT: Id de la Entidad
IdDoc: Id del documento formado por serie + No. De documento
Modelo: Enviar
S1- Factura Venta
S4 – Nota Crédito
S5 – Nota Débito
S6 – Guia Remision
S7- Comprobante Retención
SD - Boleta de Venta
<body>
< ConsultaDocResult>
<idDoc>String</idDoc>
<Status>boolean</Status>
<Ambiente>boolean</Ambiente>
<codigo>String</codigo>
<descripcion>String</descricao>
<recomendacion>String</recomendacion>
<FechaAut>Date</FechaAut>
<HrAut>String</HrAut>
<XML>Base64Binary</XML>
</ConsultaDocResult>
</body>
Status :
Si el campo Satus del retorno del web method corresponde con los siguientes códigos, deberá pintar según el color:
Si Status es 1 Recibido por TSS Color Azúl
Si Status es 4 Aguardando procesamiento Color Amarillo
Si Status es 5 Documento Rechazado Color Rojo
Si Status es 6 Documento Autorizado Color Verde
Documento: Mostar propiedad idDoc del retorno del Web Method.
Ambiente: Si el retorno del campo Ambiente es 1 colocar “Producción”, si es 2 colocar “Homologación”.
Fch. Aut. : Fecha de Autorización del Documento. Propiedad FechaAut
Hr. Aut.: Hora de Autorización del documento. Propiedad HrAut
Mensaje: Mensaje retornado. Propiedad Descripción.
Recomendación: en esta columna será informado propiedad Recomendación.
Si el documento fue autorizado, deberá obtener de la propiedad XML el documento autorizado codificado en Base64 y decodificarlo. Guardarlo en la carpeta configurada en parámetro MV_CFDDOCS + “/autorizados/” +especie con nombre de archivo formado por Propiedad idDocumento + especie + extensión xml
Azul: Recibido TSS
Amarillo: Enviado SUNAT
Rojo: Rechazado SUNAT
Verde: Autorizado SUNAT
F1_FLFTEXT/F2_FLFTEX:= Propiedad Status
F1_FECAUT/F2_FECAUT:= Propiedad FechaAut
Al confirmar los parámetros, realizar consulta a SF1 si el documento es nota de crédito o a SF2 si los documentos consultados son Factura, Boleta, nota de Débito o guía de Remisión. Por cada registro, deberá realizar consulta al Web Method ConsultaDoc enviando los siguientes parámetros
Rutina | Tipo de Operación | Opción de Menú | Reglas de Negocio |
[ACAA040 – Parámetros] | [Modificación] | [Actualizaciones -> Académico-> Tesorería] | - |
[ACAA050 – Negociación Financiera] | [Involucrada] | [Actualizaciones -> Académico-> Tesorería] | - |
[ACAA060 – Archivo de Pedidos] | [Creación] | [Actualizaciones -> Académico-> Archivos] | - |
Ejemplo de aplicación:
Tablas Utilizadas
<Si necesario, incluirprototipos de pantallas con el objetivo de facilitar la comprensión del requisito, presentar conceptos y funcionalidades del software>.
Prototipo 01
<En esta etapa, incluir representaciones gráficas que describan el problema por solucionar y el sistema que se desarrollará. Ejemplo: Diagrama - Caso de Uso, Diagrama de Actividades, Diagrama de Clases, Diagrama de Entidad y Vínculo y Diagrama de Secuencia>.
Archivo o Código del Script: AAA – Negociación Financiera o /*Versao=CP.2014.12_03*/
Índice | Clave |
01 | <FI9_FILIAL+FI9_IDDARF+FI9_STATUS> |
02 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_EMISS+FI9_IDDARF> |
03 | <FI9_FILIAL+FI9_FORNEC+ FI9_LOJA+FI9_PREFIX+FI9_NUM+FI9_PARCEL+FI9_TIPO> |
Campo | <AAA_PERESP> |
Tipo | <N> |
Tamaño | <6> |
Valor Inicial | <Varia de acuerdo con el tipo informado. Por ejemplo, cuando el campo “tipo” es date, en este campo se puede informar una fecha>. |
Obligatorio | Sí ( ) No ( ) |
Descripción | <Referencia mínima para cálculo> |
Título | <Ref.Calc.> |
Picture | <@E999.99> |
Help de Campo | <Informar el % que el alumno pagará en efectivo (dinero). Ese % podrá modificarse durante la negociación> |
<Información utilizada en la línea Protheus>.
Nombre: FINSRF2
X1_ORDEM | 01 |
X1_PERGUNT | Emisión De |
X1_TIPO | D |
X1_TAMANHO | 8 |
X1_GSC | G |
X1_VAR01 | MV_PAR01 |
X1_DEF01 | Común |
X1_CNT01 | '01/01/08' |
X1_HELP | Fecha inicial del intervalo de emisiones de los formularios de DARF que se considerarán en la selección de los datos para el informe. |
<Información utilizada en la línea Protheus>
Consulta: AMB
Descripción | Configuraciones de planificación. |
Tipo | Consulta estándar. |
Tabla | “AMB” |
Índice | “Código” |
Campo | “Código”; ”Descripción” |
Respuesta | AMB->AMB_CODIGO |
<Información utilizada en la línea Datasul>.
Procedimientos
Procedimiento |
|
|
|
Descripción | (Max 40 posiciones) | (Max 40 posiciones) | (Max 40 posiciones) |
Módulo |
|
|
|
Programa base |
|
|
|
Nombre Menú | (Max 32 posições) | (Max 32 posições) | (Max 32 posições) |
Interfaz | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Registro estándar | Sí | Sí | Sí |
Visualiza Menú | Sí/No | Sí/No | Sí/No |
Release de Liberación |
|
|
|
Programas
Programa |
|
|
|
Descripción | (Max 40 posiciones) | (Max 40 posiciones) | (Max 40 posiciones) |
Nombre Externo |
|
|
|
Nombre Menú/Programa | (Max 32 posiciones) | (Max 32 posiciones) | (Max 32 posiciones) |
Nombre Verbalizado[1] | (Max 254 posiciones) | (Max 254 posicionees) | (Max 254 posiciones) |
Procedimiento |
|
|
|
Template | (Verificar la lista de opciones en el man01211) | (Verificar la lista de opciones en el man01211) | (Verificar la lista de opciones en el man01211) |
Tipo[2] | Consulta/Mantenimiento/ \Informe/Tareas | Consulta/Mantenimiento/ Informe/Tareas | Consulta/Mantenimiento/ Informe/Tareas |
Interfaz | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex | GUI/WEB/ChUI/Flex |
Categoría[3] |
|
|
|
Ejecuta vía RPC | Sí/No | Sí/No | Sí/No |
Registro Estándar | Sí | Sí | Sí |
Otro Producto | No | No | No |
Visualiza Menú | Sí/No | Sí/No | Sí/No |
Query on-line | Sí/No | Sí/No | Sí/No |
Log Ejec. | Sí/No | Sí/No | Sí/No |
Rutina (EMS) |
|
|
|
Subrutina (EMS) |
|
|
|
Ubicación dentro de la subrutina (EMS) |
|
|
|
Compact[4] | Sí/No | Sí/No | Sí/No |
Home[5] | Sí/No | Sí/No | Sí/No |
Posición del Portlet[6] | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right | 0 – Top Left 1 – Top Right 2 – Bottom Left 3 – Bottom Right |
Informar los papeles con los que el programa se debe vincular |
|
|
|
Archivo de Papeles
<El archivo de papeles es obligatorio para los proyectos de desarrollo FLEX a partir del Datasul 10>.
<Recordatorio: el nombre de los papeles en inglés que se describe en este punto del documento se deben homologar por el equipo de traducción>.
Código Papel | (máx 3 posiciones) |
Descripción en Portugués* |
|
Descripción en Inglés* |
|
[1] Es obligatorio el desarrollo del Nombre Verbalizado a partir del Datasul 10.
[2] Es obligatorio desarrollar el Tipo a partir del Datasul 10.
[3] Categorías son obligatorias para los programas FLEX.
[4] Obligatorio cuando el proyecto es FLEX.
[5] Obrigatorio cuando el proyecto es FLEX.
[6] Obligatorio cuando el proyecto es FLEX.
Este documento es un material de especificación de los requisitos de innovación. Se trata de un contenido sumamente técnico. |
---|