01. DATOS GENERALES
| Producto | TOTVS Backoffice | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Línea de producto: | Línea Protheus | ||||||||||||||||||||||||
| Segmento: | Servicios | ||||||||||||||||||||||||
| Módulo: | SIGAFIN - Financiero | ||||||||||||||||||||||||
| Función: |
| ||||||||||||||||||||||||
| Ticket: | |||||||||||||||||||||||||
| Requisito/Story/Issue (informe el requisito vinculado): | DMICNS-9078 |
02. SITUACIÓN/REQUISITO
1- Realizar las correcciones para el cálculo de retenciones de IIBB, a través de la rutina Orden de Pago Mod. Ii (FINA847.PRW).
2- Inclusion da posibilidad de cambiar la fecha de validacion de un cheque de terceros
DMICNS-9080:
Se identifican inconsistencias en el cálculo de Retención de Ganancias e Ingresos Brutos en Dólares de un Pago Anticipado (PA) generado a partir de solicitud de fondo, identificando que calcula mal la base del impuesto.
DMICNS-8391:
Se identifican inconsistencias en el cálculo de Retención de Ingresos Brutos, en el proceso de generación de Pago Anticipado (PA) cuando se utiliza como forma de pago un Cheque de Terceros que tiene un valor mayor al valor por pagar en la Orden de Pago. El PA genera mal el cálculo de retenciones de Ingresos Brutos y grabación, lo que origina que al utilizar este PA para dar de baja una NF, los cálculos no sean correctos.
DMICNS-8370:
En la generación de una Orden de Pago que se realiza en dolares, cuando se pacta una Tasa de cambio diferente al del día (tabla SM2) genera de manera errada un registro tipo Pago Anticipado (PA) cuando el título por pagar tiene retenciones.
DMICNS-8234:
Se identifican inconsistencias en el cálculo de Retención de Ingresos Brutos de Córdoba (CO), no considera los comprobantes NCP para el cálculo, cuando por si solo el documento no supera el mínimo de importe definido en Conf. Adic. Imp (tabla SFF). De manera errada valida por separado cada documento y debe ser por pago.
DMICNS-8734 (DMICNS-8785):
Se identifican inconsistencias en el cálculo de Retención de Ingresos Brutos para la Provincia de Santa Fe (SF), al realizar un pago de una NF y NCP, no calcula la retención de IIBB de la NF cuando se tiene un registro para el mismo proveedor con un %Exención (FH_PERCENT) igual a 100, esto en la "Conf. Adic. Imp (tabla SFF)", sin embargo; para la NCP si realiza el cálculo.
03. SOLUCIÓN
DMICNS-9080:
Se realiza un cambio para calcular la Base de manera correcta, descontando el valor del impuesto de IVA. El cambio aplica para Solicitud de Fondo en moneda igual y diferente de 1, ya que ambos escenarios estaban incorrectos.
DMICNS-8391:
Se valida que al hacer la búsqueda de las retenciones del PA (tabla SFE), solo sumarice las que provengan del PA (anteriormente buscaba por el numero de OP pero no validaba el origen de la retención), como el PA fue originado en la compensación de un Cheque de terceros vs. una NF, se tienen las retenciones de ese proceso con el mismo numero de Orden de Pago, lo que hacia que trajera incorrectamente esa retención.
Adicional se hace un cambio para que tome correctamente la base de cálculo para Córdoba (Vlr. Mercadería + IVA) y para que muestre la base correcta cuando se genera un pago automatico, porque aunque ya se generaba correcta, se detecto que la visualizaba de manera errada.
DMICNS-8234:
Se realiza un ajuste en la función de calculo de acumulados y re-calculo (CalcAcIB() y ReCalAcmIB()), para que sumarice las bases de los documentos por CFO, teniendo en cuenta que una NCP tiene diferente CFO al de la Nota Fiscal, entonces se valida que ambos CFO's estén en la misma línea de la configuración de IIBB a través de la rutina "Conf. Adic. Imp (tabla SFF)" para poder acumular, posteriormente se verifica el mínimo.
DMICNS-8370:
Se identifica que el incidente actualmente está funcionando correcto.
DMICNS-8734 (DMICNS-8785):
Se valida correctamente el campo %Exención, lo hacia de manera errada contra el campo %Exención (FH_PERCENT) del registro donde se había quedado posicionado (proceso anterior de la tabla SFH), sin embargo; para el proceso que se esta ejecutando es sobre una tabla temporal y por tanto se debe validar contra el contenido del campo de la tabla temporal, de está manera ya se procesa el registro correcto.
Cheques terceros:
Se creo a posibilidad de cambiar la fecha de validacion de los cheques de terceros que hoy es 30 dias atraves da utilizacion de un nuevo parametro "MV_DTCHTER", por default continua considerando los 30 dias, pero si existe considera su contenidocorrecto.
04. INFORMACIÓN ADICIONAL
- Si el mínimo se configura en Conf Adic Imp tabla (SFF) el mínimo se considera por CFO.
- FH_COEFMUL es el coeficiente que se aplica para reducir las alícuotas del Convenio Multilateral.
- FF_REDBASE reduce la Base Imponible, no la alícuota.
- SI necesario cambiar la fecha de validacion de los cheques de tercero o parametro MV_DTCHTER debe ser creado e la cuantidad de días informada.
05. ASUNTOS RELACIONADOS
- No aplica.
- documento_tecnico
- totvs_backoffice
- backoffice
- protheus
- servicios
- fina850
- fina850a
- finretarg
- fina847
- finretiva
- finretsus
- finretgan
- finretsli
- finretmun
- finretibb
- ret_iibb
- op_mod_ii
- op
- orden_pago
- mi
- mercado_internacional
- base_conocimiento
- arg
- argentina
- sigafin
- financiero
- dmicns_9078
- dmicns_9080
- 9499970
- ticket_9499970
- dmicns_8391
- 8785028
- ticket_8785028
- cheque_terceros
- pa
- pago_anticipado
- dmicns_8234
- ff_importe
- minimo
- 8555432
- ticket_8555432
- co
- cordoba
- reduccion_base
- ff_redbase
- dmicns_8370
- 8765598
- ticket_8765598
- dmicns_8785
- 9191411
- ticket_9191411
- dmicns_8734
- 9110077
- ticket_9110077
- sf
- porcentaje_exencion
- fh_percent
- moneda_2
- dolar
- tc
- version_12_1_17
- version_12_1_23
- version_12_1_25
- version_12_1_27
- dmicns_8306