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
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 M486CBAJA está retornará XML 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: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: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>SF3 – Libros Fiscales.


Prototipo de Pantalla

  

Prototipo 01

 

 

 

 Prototipo 02

 

 


Prototipo 03



Prototipo 04



Diccionario de Datos

 

Se deberán crear los siguientes campos:

 

SF3 – Libros Fiscales


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.

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

 

 

                                                       

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.

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