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 | Subtarea1 | SERINN001-1158 |
Chamado/Ticket2 |
| ||
País | ( ) Brasil ( ) Argentina ( ) México ( ) Chile ( ) Paraguay ( ) Ecuador ( ) EEUU ( ) Colombia ( X ) 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).
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.
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:
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.
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:
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:
<?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&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&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
Prototipo 01
Prototipo 02
Prototipo 03
Prototipo 04
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 | @! |
Contexto | Real |
Propiedad | Modificar |
F3 | No 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 | @! |
Contexto | Real |
Propiedad | Modificar |
F3 | No 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 | @! |
Contexto | Real |
Propiedad | Modificar |
F3 | No aplica |
Validación | |
Help de Campo | Fecha en la que SUNAT autoriza Anulación del Documento a través de Comunicado de baja. |
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. |
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. |
---|