Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Comentário: Migration of unmigrated content due to installation of a new plugin
  • l detonar la función M486NFXML está retornará XML con de la siguiente forma:

 

Este documento es un material de especificación de los requisitos de innovación. Se trata de un contenido sumamente técnico.      

                                                       

Información General

 

Especificación

Producto

Microsiga Protheus

Módulo

SIGAFAT

Segmento ejecutor

Servicios

Projeto1

Proyecto de Desarrollo_MEX

IRM/EPIC1

 SERINN001-1143

Requisito/Story/Issue1

 SERINN001-1144

Subtarea1

SERINN001-11441158

Chamado/Ticket2

 

País

(  ) Brasil  (  ) Argentina  (  ) México  (  ) Chile  (  ) Paraguay  (  ) Ecuador

(  ) EEUU  (  ) Colombia   ( X ) Otro  Perú.

Otros

<Si necesario, informe otras referencias que sean pertinentes a esta especificación. Ejemplo: enlaces de otros documentos o subtareas vinculadas>.

   Leyenda: 1 – Innovación 2 – Mantenimiento (Los demás campos se deben completar en ambos los procesos). 

Objetivo


Definir el procedimiento para borrado, anulación y baja de un documento fiscal (Factura de Venta, Nota de Crédito, Nota Débito y Boleta de Venta) dentro de Protheus.

 

Definición de la Regla de Negocio

 

Borrado y anulación de Factura de Venta desde la rutina de Facturación (MATA467N).

 

Dentro de la rutina Factura de Venta (MATA467N) se cuenta con las opciones Borrar y Anular (Prototipo 1). Se deberá modificar ambas opciones conforme a lo siguiente:

 

  • Opción Borrar: Actualmente al detonar esta opción muestra registro de la factura de venta y se debe confirmar la operación de borrado. Al dar clic en el botón Guardar y después de confirmar el borrado, se debe incluir una validación en la cuál se consulta si la factura fue transmitida a TSS o ya fue procesada para la facturación electrónica (F2_FLFTEXT <> 0 o es vacío ) entonces no deberá permitir el borrado indicando con mensaje al usuario "La factura Serie y No." + F2_SERIE + F2_DOC + "no puede ser borrada pues ya fue procesada por la Transmisión Electrónica. Utilice la opción Anular" (Prototipo 2).

 

Si la factura no ha sido procesada (F2_FLFTEXT = '0' o es vacío) deberá permitir realizar el borrado de la factura tal cuál actualmente lo hace.

 

  • Opción Anular:  Se modificará la funcionalidad de la opción para que llame la rutina M486BAJA(). La función M486BAJA retornará Falso o Verdadero, lo que permitirá realizar o no el proceso de anulación que actualmente se realiza en Protheus.

 

Al llamar la función, se consulta si el documento a anular ha sido procesado por la transmisión electrónica(F2_FLFTEXT <> 0 o es vacío).

 

Si la factura fue rechazada previamente por la SUNAT a través de la transferencia electrónica (F2_FLFTEXT='5') entonces se procederá a realizar la anulación en Protheus. Actualmente cuando la rutina pregunta si se desea confirmar la anulación, elimina registro de Encabezado de Fact. de Salida (SF2)  así como de Items de Venta de la Fact (SD2) para el documento, sin embargo deberá cancelar el registro en Libros Fiscales (SF3) (proceso actual), en esta parte se añadirá motivo de Anulación F3_MOTIVO = "Rechazo SUNAT".

 

Si la factura fue Autorizada por la SUNAT (F2_FLFTEXT = 6) entonces deberá revisar si existe compensación. Si existe compensación no permitirá anular(actualmente ya funciona de esta manera). Si no existe compensación, deberá mostrar cuadro de captura para que el usuario introduzca el motivo de la anulación (Prototipo 3). Se validará que el motivo no esté vacío. Al continuar el proceso, detonar generación de comunicado de baja mediante el consumo del Web Service SendDoc como se indica de la siguiente manera:

 

USERTOKEN = "TOTVS"

IDENT = Id Entidad Registrada en TSS

IDDOC = Identificación de la Comunicación de Baja. Se formará conforme la siguiente tabla: 

MODELO = "SE"

XML = XML generado con la función M486CBAJA(). Ver sección Generación XML.

 

Posición

Descripción

1-11

RUC

12

“-“Guión separador

13-14

“RA”

15

“-“Guión separador

16-23

Fecha de generación(ddatabase) en formato AAAAMMDD

24

“-“ Guión separador

25-29

Correlativo incremental por día, mínimo 1 máximo 5.

Revisar parámetro control en SX5 para correlativo de identificador de baja. Si los primeros 23 números son diferentes del id que se esta generando(RUC+”-RA-”+AAAAMMDD), comenzar en 1. Si es igual, tomar a a partir del carácter 25 y convertir a número, sumar 1 y ese será el correlativo siguiente.

 

 Guardar XML Generado en ruta MV_CFDDOCS + "/ComunicadoBaja/" + Identificación de la Comunicación de Baja generado + extensión XML.

 

Procesar el retorno del Web Service SendDoc, si el retorno es positivo:

 

Actualizar F3_MOTIVO = Motivo introducido por el usuario, F3_IDCBAJA = Id Baja generado para registro donde F3_NFISCAL = F2_DOCUMENTO , F3_SERIE=F2_SERIE, F3_CLIEFOR=F2_CLIENTE , F3_LOJA=F2_LOJA, F3_ESPECIE=F2_ESPECIE.

 

Actualizar valor del correlativo en SX5 = Id de Baja Enviado.

 

 Enviar mensaje al usuario indicando el éxito de la transmisión y mostrando el id del comunicado de baja generado.

 

"Comunicado de baja enviado exitosamente. ID Generado: " + Id de Baja Enviado. (Prototipo 4)


Ejemplo: "Comunicado de baja enviado exitosamente. ID Generado: 2010006603-RA-20170601-1"

 

Deberá consumir el Web Method consultaDoc para revisar si el Comunicado de Baja enviado fue Autorizado por la SUNAT. Enviar los parámetros:

 

USERTOKEN: "TOTVS"

IDENT: Id de la Entidad

IdDoc: ID generado

Modelo: "SE" – Comunicado de Baja

 

Procesar el retorno del Web Method, si el documento fue autorizado (propiedad Status = '6') por cada documento incluido en la comunicación de Baja, actualizar F3_IDCBAJA = Id Baja generado, F3_DTAUTBJ = propiedad Fecha Aut del retorno en donde F3_NFISCAL = Columna No. Documento , F3_SERIE = F2_SERIE, F3_CLIEFOR = F2_CLIENTE, F3_LOJA = F2_LOJA, F3_ESPECIE = F2_ESPECIE para Boleta de Venta/Factura. Si el documento es Nota de Crédito deberá actualizar  actualizar F3_IDCBAJA = Id Baja generado, F3_DTAUTBJ = propiedad Fecha Aut del retorno en donde F3_NFISCAL = Columna No. Documento , F3_SERIE = F1_SERIE, F3_CLIEFOR = F1_CLIENTE, F3_LOJA = F1_LOJA, F3_ESPECIE = F1_ESPECIE.

 

Actualizar valor del correlativo en SX5 = Id de Baja Enviado. Retornar valor verdadero.

 

Si el documento fue rechazado (propiedad Status = '5'), enviar mensaje la usuario indicando "El Comunicado de baja" + Id generado + "para anular el documento" + F2_SERIE/F1_SERIE + F2_DOC/F1_DOC + "ha sido rechazado por la SUNAT. No se pudo realizar la Anulación:  " + Propiedad descripción del retorno del Web Method consultaDoc. Retornar valor Falso.

 

Si el retorno es negativo, enviar mensaje al usuario indicando el problema y retornar valor Falso lo que no permitirá realizar la anulación en Protheus.

 

Generación del XML

 

 La función M486CBAJA() tiene como propósito la generación de XML para comunicar la baja de un documento a la SUNAT. Recibirá como parámetros:

  • Filial: Sucursal que emitió el documento.
  • Serie2: Número o Serie del Documento que se envió a la SUNAT.
  • No. Doc:Número de Dócumento
  • Cliente: Según sea el origen del documento deberá recibir el código del cliente.
  • Tienda: Código de la tienda
  • Fecha Emisión: Fecha en se emitió el documento
  • Especie: Especie del documento
  • Motivo: Motivo de Baja

Retornará XML obedeciendo a la siguiente estructura:

Elemento

TAG UBL

Descripción

Tam

Oblig

Valor

Adicionales

 

 

 

<UBLExtensions>

Contenedor de Componentes de extensión. Podrán incorporarse nuevas definiciones estructuradas cuando sean de interés conjunto para emisores y receptores, y no estén ya definidas en el esquema de la factura

 

x

 

<ext:UBLExtension>

Deberá generarse para Información Adicional sobre la factura por conceptos de otros tributos y operaciones

 

 

 

<ext:ExtensionContent>

 

 

 

 

 

 

 

 

Generar sin contenido de la siguiente manera:

<ext:UBLExtension>

<ext:ExtensionContent>

</ext:ExtensionContent>

</ext:UBLExtension>

Identificación del Documento

<cbc:UBLVersionID>

Versión UBL

3

X

Fijo “2.0”

 

<cbc:CustomizationID>

Versión de la estructura del Documento

3

X

Fijo “1.0”

 

<cbc:ID>

Numeración, conformada por serie y número correlativo

Max. 13

X

Id  Comunicado de Baja

 

<cbc:ReferenceDate>

Fecha de generación del documento dado de baja (yyyy-mm-dd)

 

 

 

ddatabase Formato YYYY-MM-DD

 

<cbc:IssueDate>

Fecha de Generación

10

X

F1_EMISSAO  en formato YYYY-MM-DD para Notas de crédito.

F2_EMISSAO  en formato YYYY-MM-DD para Notas de Débito, facturas  y boleta de venta.

Firma Electrónica

<cac:Signature>

 

Referencia a la Firma Digital

 

 

 

<cbc:ID>

Identificador de la firma

 

 

Fijo “IDSignTOTVS”

<cac:SignatoryParty>

         <cac:PartyIdentification>

            <cbc:ID>

Identificación de la parte firmante

13

 

SM0->M0_CGC

<cac:SignatoryParty>

         <cac:PartyName>

            <cbc:Name>

Nombre de la parte firmante

 

 

 

SM0->M0_NOME

<cac:DigitalSignatureAttachment>

         <cac:ExternalReference>

            <cbc:URI>

Asociación con la firma codificada

 

 

 

Colocar fijo “#SignatureTOTVS”

Información del Emisor

<cac:AccountingSupplierParty>

Documentación Emisor

 

x

 

 

    <cbc:CustomerAssignedAccountID>

RUC del Emisor

 

11

x

SM0->M0_CGC

 

<cbc:AdditionalAccountID>

Tipo de documento de identificación. Catálogo No. 6 

 

1

x

Fijo ‘6’

 

<cac:Party>

Razón social y Domicilio fiscal del Emisor

 

x

 

 

<cac:PartyLegalEntity>

Razón Social

 

 

 

 

<cbc:RegistrationName>

Apellidos y nombres, denominación o razón social

 

Max 100

X

M0_NOME

Detalle del Comunicado

<sac:VoidedDocumentsLine>

Debe generarse por cada documento incluido en el comunicado

 

X

 

 

<cbc:LineID>

Número de orden del Ítem

 

 

x

Fijo 1

 

<cbc:DocumentTypeCode>

Tipo de documento según catálogo  No. 1

 

 

01 Factura

03 Boleta de Venta

07 Nota de Crédito

08 Nota de Débito

 

<sac:DocumentSerialID>

Serie a 4 caracteres

 

 

 

F1_SERIE2/F2_SERIE2

 

<sac:DocumentNumberID>

Número de documento

 

 

F1_DOC/F2_DOC

 

<sac:VoidReasonDescription>

Motivo de la baja

 

 

 

Motivo Capturado por el usuario. F3_MOTIVO


Rutina

Tipo de Operación

Opción de Menú

Reglas de Negocio

MATA486

Modificación

Actualizaciones|Facturación|Documentos Electronicos

-

MATA467N

Modificación

Actualizaciones|Facturación|Facturación

-

MATA465N

Modificación

Actualizaciones|Facturación|Generación Notas de Cred/Deb.

-

 

Ejemplo de aplicación:

  • Al detonar la función
  • M486NFXML está
  • M486CBAJA está retornará XML
  • con
  • de la siguiente forma:

<?xml version="1.0" encoding="UTF-8"?>

 

<VoidedDocuments xmlns="urn:sunat:names:specification:ubl:peru:schema:xsd:VoidedDocuments-1"

 

xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"

 

 

xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"


xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

 

 

xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2"

 


xmlns:sac="urn:sunat:names:specification:ubl:peru:schema:xsd:SunatAggregateComponents-1"


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

 

  

<ext:UBLExtensions>

 

     

<ext:UBLExtension>

 

        

<ext:ExtensionContent>

 

        

</ext:ExtensionContent>

 

     

</ext:UBLExtension>

 

  

</ext:UBLExtensions>

 

   <cbc

<cbc:UBLVersionID>2.0</cbc:UBLVersionID>

 

  

<cbc:CustomizationID>1.0</cbc:CustomizationID>

 

  

<cbc:ID>RA-20120416-2</cbc:ID>

 

  

<cbc:ReferenceDate>2012-04-15</cbc:ReferenceDate>

 

  

<cbc:IssueDate>2012-04-16</cbc:IssueDate>

 

  

<cac:Signature>

 

     

<cbc:ID>IDSignTOTVS</cbc:ID>

 

     

<cac:SignatoryParty>

 

        

<cac:PartyIdentification>

 

            <cbc

<cbc:ID>20119453604</cbc:ID>

 

        

</cac:PartyIdentification>

 

        

<cac:PartyName>

 

           

<cbc:Name><![CDATA[K&amp;G ASOCIADOS S.A]]></cbc:Name>

 

        

</cac:PartyName>

 

     

</cac:SignatoryParty>

 

     

<cac:DigitalSignatureAttachment>

 

        

<cac:ExternalReference>

 

           

<cbc:URI>#signatureTOTVS</cbc:URI>

 

        

</cac:ExternalReference>

 

     

</cac:DigitalSignatureAttachment>

 

  

</cac:Signature>

 

  

<cac:AccountingSupplierParty>

 

     

<cbc:CustomerAssignedAccountID>20119453604</cbc:CustomerAssignedAccountID>

 

     

<cbc:AdditionalAccountID>6</cbc:AdditionalAccountID>

 

     

<cac:Party>

 

        

<cac:PartyLegalEntity>

 

           

<cbc:RegistrationName><![CDATA[K&amp;G ASOCIADOS S.A]]></cbc:RegistrationName>

 

        

</cac:PartyLegalEntity>

 

     

</cac:Party>

 

  

</cac:AccountingSupplierParty>

 

  

<sac:VoidedDocumentsLine>

 

     

<cbc:LineID>1</cbc:LineID>

 

     

<cbc:DocumentTypeCode>01</cbc:DocumentTypeCode>

 

     

<sac:DocumentSerialID>F001</sac:DocumentSerialID>

 

     

<sac:DocumentNumberID>1</sac:DocumentNumberID>

 

     

<sac:VoidReasonDescription>ERROR EN SISTEMA</sac:VoidReasonDescription>

 

  

</sac:VoidedDocumentsLine>

 

</VoidedDocuments>

 

Tablas Utilizadas

  • SE2 – Archivo de Cuentas por Pagar
  • FI9 – Control de Emisión de DARF>.
Opcional
  • SF3 – Libros Fiscales.


Prototipo de Pantalla

 

  

Prototipo 01<Si necesario, incluirprototipos de pantallas con el objetivo de facilitar la comprensión del requisito, presentar conceptos y funcionalidades del software>.

 Prototipo 01

 Image Added

 

 Prototipo 02

 Image Removed

 Image Added


Prototipo 03


Image Added


Prototipo 04


Image Added


Diccionario de Datos

 

Se deberán crear los siguientes campos:

 

 

SF3 – Libros Fiscales

Opcional

Flujo del Proceso

 

<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>. 

Opcional

Diccionario de Datos

 

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

F3_MOTIVO

Tipo

C

Tamaño

50

Uso

Usado

Obligatorio

Sí ( X ) No ( )

Descripción

Motivo de Baja del Documento para SUNAT

Título

Motivo de Baja

Picture

@!

ContextoReal
PropiedadModificar
F3No aplica
Validación 

Help de Campo

Mensaje que acompañará la anulación enviada a SUNAT mediante comunicado de baja.

Campo

F3_IDCBAJA

Tipo

C

Tamaño

29

Uso

Usado

Obligatorio

Sí ( ) No ( X )

Descripción

Num Comunicado de Baja

Título

Num. Com. Baja

Picture

@!

ContextoReal
PropiedadModificar
F3No aplica
Validación 

Help de Campo

Identificador de comunicado de baja enviado a la SUNAT.

Campo

F3_DTAUTBA

Tipo

D

Tamaño

8

Uso

Usado

Obligatorio

Sí ( ) No ( X )

Descripción

Fecha de autorización de Baja

Título

Fecha Aut Baj

Picture

@!

ContextoReal
PropiedadModificar
F3No aplica
Validación 

Help de Campo

Fecha en la que SUNAT autoriza Anulación del Documento a través de Comunicado de baja.

Parámetros

 

Se deberán habilitar para Perú los siguientes parámetros:

 

Nombre

MV_IDCBAJA

Tipo

Carácter

Descripción

Control de los identificadores de Comunicados de baja.

 

 

Flujo del Proceso

 

Caso de Testes

Anular Factura de Venta

 
 

Finalidad Testes

Anular factura de venta que no ha sido autorizada por la SUNAT

 

Estimativas

 

 

Teste do Programador

Si

 

Recomendaciones

Tener un registro de factura de venta ya autorizada.

 

Pré-condiciones

Configuración de conexión con TSS

 

Pós-condiciones

 

 

Como verificar os resultados

Se mostrará mensaje en pantalla indicando autorización.

 

Procedimentos

Resultados Esperados

 

1. Seleccionar factura de venta a anular.

2. Se visualiza registro en pantalla.

 

 

4. Se pide al usuario indicar motivo de baja.

 

3. Confirma anulación

5. Registra motivo de baja

6. Genera xml de comunicado de baja.

7. Envia XML de comunicado de baja a tss.

8. Consulta comunicado de baja a tss

9. Si SUNAT utorizó, borra registros y cancela registro en libros fiscales.

10. Se indica al usuario el éxito ofracaso de la operación.

 

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>

(Opcional)

Grupo de Preguntas

 

<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.

(Opcional)

Consulta Estándar

<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

(Opcional)

Estructura de Menú

 

<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

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

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.     
Este documento es un material de especificación de los requisitos de innovación. Se trata de un contenido sumamente técnico.      

                                                       

Información General

 

Especificación

Producto

Microsiga Protheus

Módulo

SIGAFAT

Segmento ejecutor

Servicios

Projeto1

 

IRM/EPIC1

 

Requisito/Story/Issue1

 

Subtarea1

 

Chamado/Ticket2

 

País

(  ) Brasil  (  ) Argentina  (  ) México  (  ) Chile  (  ) Paraguay  (  ) Ecuador

(  ) EEUU  (  ) Colombia   (  ) Otro _____________.

Otros

<Si necesario, informe otras referencias que sean pertinentes a esta especificación. Ejemplo: enlaces de otros documentos o subtareas vinculadas>.

   Leyenda: 1 – Innovación 2 – Mantenimiento (Los demás campos se deben completar en ambos los procesos). 

Objetivo

 

(Obligatorio)

(Obligatorio)

Definición de la Regla de Negocio

 

<Regla de negocio es lo que define la forma de realizar el negocio, el proceso definido y/o las reglas que se deben considerar. Se deben describir las restricciones, validaciones, condiciones y excepciones del proceso. Si necesario, incluir,también en este capítulo, las reglas de integridad que se deben verificar al momento del desarrollo>.

 

<En la tabla abajo, informe las rutinas involucradas, el tipo de operación, la opción de menú y, si necesario, una breve descripción de las regras de negocio relacionadas a la rutina>.

 

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:

  • Crear el campo “% Mínimo Efectivo” (AAA_PERESP), en que el usuario informará el % que el alumno pagará en efectivo (dinero). Ese % podrá modificarse durante la negociación.
  • Crear el campo “Referencia Mínima para Cálculo” (AAA_REFCAL), en que el usuario informará uno de los 4 valores disponibles para pago de las mensualidades  como la referencia mínima para calcular el débito total del alumno.
  • Crear el parámetro MV_ACPARNE, que definirá si la información de “% Mínimo Efectivo” y “Referencia Mínima para Cálculo” será obligatoria.
  • El parámetro MV_ACPARNE debe tener las opciones: 1=Obligatorio y 2=Opcional. Se debe inicializar como opcional>.

 

Tablas Utilizadas

  • SE2 – Archivo de Cuentas por Pagar
  • FI9 – Control de Emisión de DARF>.

Opcional

Prototipo de Pantalla

 

<Si necesario, incluirprototipos de pantallas con el objetivo de facilitar la comprensión del requisito, presentar conceptos y funcionalidades del software>.

 

Prototipo 01

 

 

 Image Removed

 

 

 

 

Opcional

Flujo del Proceso

 

<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>. 

Opcional

Diccionario de Datos

 

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>

(Opcional)

Grupo de Preguntas

 

<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.

(Opcional)

Consulta Estándar

<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

(Opcional)

Estructura de Menú

 

<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

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

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.