Histórico da Página

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

Información General

   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.

 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:

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

Parámetros

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

Flujo del Proceso

(Opcional)

Grupo de Preguntas

<Información utilizada en la línea Protheus>.

Nombre: FINSRF2

(Opcional)

Consulta Estándar

<Información utilizada en la línea Protheus>

Consulta: AMB

Información General

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

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)

Grupo de Preguntas

<Información utilizada en la línea Protheus>.

Nombre: FINSRF2

(Opcional)

Consulta Estándar

<Información utilizada en la línea Protheus>

Consulta: AMB

(Opcional)

Estructura de Menú

<Información utilizada en la línea Datasul>.

Procedimientos

Programas

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