Blog - Implementación
Modificado el Lun, 13 Nov, 2023 a 10:36 A. M.
Recepcion envio a Buzon Universal
Cuando recepcion se comunica a Buzon Universal para enviar el estatus del comprobante cuando este ha cambiado se utilizan las tareas Interop.
Registro de cambio de movimiento
Todos los movimientos (cambios de estatus) de un comprobante se registran en la tabla r_dd_comprobante_hist_part, en la cual tiene el c_comprobante_hist el cual es un consecutivo, c_Comprobante, f_emision del comprobante, el estatus que se actualizo el usuario que lo cambio (si fue por programacion aparece como null, si fue emdiante la pagina o el webservice aparece el usuario), f_registro es la fecha del movimiento.
Envio a Buzon Universal
Con el proposito de controlar el envio de cambio de estatus a buzon universal se utiliza la tabla r_mm_envio_aperak_interop, con los campos d_procid, indicacion numerica de la fecha de ejecucion, y el ultimo movimiento de la tabla historica que se envio con exito a buzon universal.
El envio se hace en bloque de 500 movimientos, el primer paso es listar los movimientos pendientes, de ahi es buscar el XML en el blob storage, posterior se realiza el ciclo de envio de 1 x1 de esos 500 al endpoint de buzon universal.
Este envio puede detenerse por diversos motivos, la mayoria se registra en el seq, el unico motivo que n ose registra es que no encuentre el XML, si no se encunetra un xml del bloque se detiene la tarea.
Lo cual se puede comprobar en la tabla con el d_procid
Para verificar la hora de la ejecucion se entra auna pagina que convierta ticks to datetime y el resultado es fecha hora de la ejecucion.
Se puede regresar en la tabla hasta el movimiento deseado para que se reprocesen los estatus.
Como validar que el envio esta desfasado, se obtiene el ultimo movimiento de r_dd_comprobante_hist_part contra el registro en r_mm_envio_aperak_interop
Si hay diferencia se debe investigar en el SEQ, y si no marca nada, considerar que es porque no encontro el XML, y revisar en el blob storage, o saltar el movimiento.
Carta Porte 2.0 - Ajustes que aplica el Motor al Emitir por WebService a partir de la etiqueta EMISION_FIX_01_V510_2023_0614_1900
A continuación se enlistan los ajustes que aplican por el Motor de Emisión a las peticiones de Comprobantes con Complemento Carta Porte, al Emitir por WebService, a partir de la etiqueta EMISION_FIX_01_V510_2023_0614_1900
- Si el atributo TipoDeComprobante del CFDI es igual a "T", varios atributos como: "CondicionesDePago", "Descuento", "TipoCambio", "MetodoPago", "FormaPago" son eliminados. Además, se ajustan los valores de los atributos "SubTotal", "Moneda" y "Total" a "0", "XXX" y "0" respectivamente.
- Si no existe un elemento TransporteMaritimo, se eliminan todos los elementos DetalleMercancia en el elemento Mercancia.
- Si hay solo un elemento de transporte, es decir, si solo hay un tipo de transporte en la carta porte: Autotransporte, TransporteMaritimo, TransporteAereo, TransporteFerroviario, se elimina el atributo CvesTransporte en el elemento CantidadTransporta. Esto por una interpretacion que se hizo de la validación CP161 de la Matriz de errores para complemento Carta Porte 2.0, revisión "C", que para el atributo Mercancia:CantidadTransporta:CvesTransporte dice: "El valor de este atributo debe contener una clave del catálogo catCartaPorte:c_CveTransporte, siempre que se registre más de uno de los siguientes nodos: "Mercancias:Autotransporte", “Mercancias:TransporteMaritimo", "Mercancias:TransporteAereo", "Mercancias:TransporteFerroviario". En caso contrario no debe existir."
- Se ajustan todos los elementos Domicilio en CartaPorte, si el atributo Pais es "MEX" y el atributo Estado es "DIF", cambia el valor del atributo Estado a "CMX".
Bóveda Fiscal - Tareas a realizar después de la renovación o actualización de CSD
Las siguientes tareas para la descarga de comprobantes cuyo origen es el servidor del SAT deben realizarse bajo los siguientes escenarios:
- Cliente generó nuevo CSD tras vencimiento de uno previo
- Cliente generó nuevo CSD tras revocar uno previo
- Descarga SAT se mantiene con estatus de Error
- Descarga Automática SAT
- Actualización de Estatus de Comprobantes
- Consulta de Listas Negras (Para Contribuyente que se está configurando) [Opcional]
Además de lo anterior, y para garantizar que se descarguen todos los comprobantes de fechas anteriores a la actualización del CSD que quedaron pendientes, se debe solicitar lo siguiente:
- Ejecutar nuevamente las peticiones fallidas que se tengan en ese momento.
- Funcionalidades 23868: FLEXTRONICS - Bóveda Fiscal PROD - Revisar/Habilitar Opciones Para Contribuyente
- Funcionalidades 22475: IEnova-Bóveda Fiscal-PROD-Revisar/Habilitar Opciones para 2 contribuyentes
Configuración sitio idioma inglés
CONFIGURACIÓN DE SITIO EN IDIOMA INGLÉS
web config de presentación:
Agregar valor en appsetting:
<add key="idioma" value="en-US"/>
Agregar valor en:
<system.web>
<globalization culture="es-MX" uiCulture="en-US"/>
Y en Base de Datos se ejecutan los cambios necesarios para menús.
La mayor parte de las traducciones se generarán de forma automática al configurar la variable de idioma en el web.config de presentación.
Configuraciones especiales en pantalla Login (todas en el web.config de presentación).
Para encabezado DIGITAL TAX RECEIPTS ONLINE
<add key="TituloHeader" value="Digital Tax Receipts online"/>
PARA MANAGED ISSUANCE SERVICE
<add key="SubTituloHeader" value="MANAGED ISSUANCE SERVICE"/>
Para página para credenciales de acceso
Configuración para QA.
<add key="tituloAccesoQA1" value="QA ENVIRONMENT"/>
Configuración para PROD.
<add key="tituloAccesoPROD1" value="PROD ENVIRONMENT"/>
Configuration para QA
<add key="tituloAccesoQA2" value="(All CFD, CFDI issued in this environment are only Test vouchers, NOT VALID BEFORE THE SAT.)"/>
Configuración para PROD
<add key="tituloAccesoPROD2" value="(All CFD, CFDI issued in this environment are only Test vouchers, NOT VALID BEFORE THE SAT.)"/>
Ya también llama a manual el inglés.
En cuanto a títulos de menús y menús solo pueden editarse directamente desde base de datos, favor de solicitar estos cambios a soporte o BD.
SUGERENCIAS MENÚS faltantes por traducir:
- Administración – Administration
- Configuración - Configuration
- Catálogos – Catalogues
- Sustituir Bulk por Massive Products and Services Load
- Operación – Operation
- Consulta controls aperak - Search Controls Aperak
- IEDU carga masiva - IEDU Massive Load
- Consultar CFDI cancelados - Search canceled C.F.D.I.
- Pagos - Payments
- Reportes - Reports
Configuración estándar para envío de correo
Configuración estándar para envío de correo
Ejemplo: cliente envía correo en addenda independiente.
Se solicita Funcionalidad para configuración de canal de comunicación y tarea de envío de correo.
Se configuran 2 canales, uno para Pagos y el otro para Facturas y demás documentos.
Para facturas:
En cs_tipo_canal_comunicacion, se genera el tipo de canal y su descripción.
En mm_canal_comunicacion, se coloca nombre de canal, si es público y activo con valor 1.
En tabla mm_emisor_canal_comunicacion, en c_emisor se deja valor 2; c_canal_comunicacion: 1; no se coloca filtro_xpath(si se coloca filtro tomará exclusivamente lo descrito en el path), ni c_tp_comprobante. En tipo_activacion: TareaExtraccion; b_activo:1.
| Tabla | cs_tipo_canal_comunicacion |
| c_tipo_canal_comunicacion | descripcion |
| 1 |
| Tabla | mm_canal_comunicacion | ||||
| c_canal_comunicacion | nombre | c_tipo_canal_comunicacion | b_publico | b_activo | fecha_baja |
| 1 | EnvioEmailConsultaExtEmision | 1 | 1 | 1 | NULL |
| Tabla | mm_emisor_canal_comunicacion | |||||
| c_emisor | c_canal_comunicacion | filtro_xpath | c_tp_comprobante | tipo_activacion | b_activo | fecha_baja |
| 2 | 1 | NULL | NULL | TareaExtraccion | 1 | NULL |
Tabla: dd_configuracion_canal_comunicacion |
c_canal_comunicacion = 1 |
| clave | valor |
| EmpaquetarEnZip | 0 |
| FormatoCuerpoCorreo | <b><font color="gray"><DIV ALIGN=center>{nombreemisor}</DIV></font></b><br/><br/>Envía a usted el archivo XML correspondiente al Comprobante Fiscal Digital con <b>UUID {uuidtimbre} y Folio: {folio} </b> Así como su representación impresa.<br/><br/>Este correo electrónico ha sido generado automáticamente por el Sistema de Emisión de Comprobantes Digitales por lo que le solicitamos no responder a este mensaje, ya que las respuestas a este correo electrónico no serán leídas. En caso de tener alguna duda referente a la información contenida en el Comprobante Fiscal Digital contacte a <b>{nombreemisor}</b> para su aclaración.<br/><br/>Está recibiendo este correo electrónico debido a que ha proporcionado la dirección de correo electrónico a <b> {nombreemisor} </b> para hacerle llegar su Factura Electrónica. |
| IncluirImagen | 1 |
| IncluirXml | 1 |
| logbitacora_movimientos | 1 |
| UsarCuerpoHtml | 1 |
| XPathAsuntoCorreo | string(concat('Ha recibido su CFDI del emisor:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Emisor']/@Nombre, ' RFC:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Emisor']/@Rfc,' ',' con folio fiscal:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Complemento']/*[local-name()='TimbreFiscalDigital']/@UUID)) |
| XPathDireccionesCorreo | //descendant-or-self::*[local-name()='Addenda']/*[local-name()='AddendaEmisor']/*[local-name()='SAPAddenda']/@e-mail |
| Tabla: cs_tarea_extraccion | |||||||||
| c_tarea_ext_pago | c_emisor | c_canal_comunicacion | c_sucursal | c_tp_comprobante | c_comprobante_ultimo | filtro_xpath | d_procid | f_movimiento_ultima | f_movimiento_maxima |
| 1 | 2 | 1 | NULL | NULL | 480 | NULL | 0 | 23/03/2023 10:22:18 a. m. | NULL |
En tabla dd_configuracion_canal_comunicacion:
Se mantiene valor 1 que corresponde al canal, c_canal_comunicacion;
EmpaquetarEnZip con valor 1, para que archivos pdf y xml se integren de forma comprimida.
Incluir imagen con valor 1, para que adjunte PDF.
IncluirXml con valor 1, para que adjunte XML.
UsarCuerpoHtml con valor 1, para que tome la estructura colocada en FormatoCuerpoCorreo.
| Tabla | cs_tipo_canal_comunicacion |
| c_tipo_canal_comunicacion | descripcion |
| 1 |
| Tabla | mm_canal_comunicacion | ||||
| c_canal_comunicacion | nombre | c_tipo_canal_comunicacion | b_publico | b_activo | fecha_baja |
| 2 | EnvioEmailConsultaPagosExtEmision | 1 | 1 | 1 | NULL |
| Tabla | mm_emisor_canal_comunicacion | |||||
| c_emisor | c_canal_comunicacion | filtro_xpath | c_tp_comprobante | tipo_activacion | b_activo | fecha_baja |
| 2 | 2 | NULL | NULL | TareaExtraccion | 1 | NULL |
Tabla: dd_configuracion_canal_comunicacion |
c_canal_comunicacion = 2 |
| clave | valor |
| EmpaquetarEnZip | 0 |
| FormatoCuerpoCorreo | <b><font color="gray"><DIV ALIGN=center>{nombreemisor}</DIV></font></b><br/><br/>Envía a usted el archivo XML correspondiente al Comprobante Fiscal Digital con <b>UUID {uuidtimbre} y Folio: {folio} </b> Así como su representación impresa.<br/><br/>Este correo electrónico ha sido generado automáticamente por el Sistema de Emisión de Comprobantes Digitales por lo que le solicitamos no responder a este mensaje, ya que las respuestas a este correo electrónico no serán leídas. En caso de tener alguna duda referente a la información contenida en el Comprobante Fiscal Digital contacte a <b>{nombreemisor}</b> para su aclaración.<br/><br/>Está recibiendo este correo electrónico debido a que ha proporcionado la dirección de correo electrónico a <b> {nombreemisor} </b> para hacerle llegar su Factura Electrónica. |
| IncluirImagen | 1 |
| IncluirXml | 1 |
| logbitacora_movimientos | 1 |
| UsarCuerpoHtml | 1 |
| XPathAsuntoCorreo | string(concat('Ha recibido su CFDI del emisor:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Emisor']/@Nombre, ' RFC:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Emisor']/@Rfc,' ',' con folio fiscal:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Complemento']/*[local-name()='TimbreFiscalDigital']/@UUID)) |
| XPathDireccionesCorreo | //descendant-or-self::*[local-name()='Addenda']/*[local-name()='AddendaEmisor']/*[local-name()='SAPAddenda']/@e-mail |
| Tabla: cs_tarea_ext_pago | ||||||||||
| c_tarea_ext_pago | c_emisor | c_canal_comunicacion | c_sucursal | c_tp_comprobante | c_comprobante_pago_ultimo | filtro_xpath | d_procid | f_movimiento_ultima | f_movimiento_maxima | |
| 1 | 2 | 2 | NULL | NULL | 14 | NULL | 0 | 24/03/2023 08:16:10 a. m. | NULL |
XPathAsuntoCorreo con valor en formato XML:
string(concat('Ha recibido su CFDI del emisor:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Emisor']/@Nombre, ' RFC:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Emisor']/@Rfc,' ',' con folio fiscal:', //descendant-or-self::*[local-name()='Comprobante']/*[local-name()='Complemento']/*[local-name()='TimbreFiscalDigital']/@UUID))
FormatoCuerpoCorreo, se coloca en XML el cuerpo:
<b><font color="gray"><DIV ALIGN=center>{nombreemisor}</DIV></font></b><br/><br/>Envía a usted el archivo XML correspondiente al Comprobante Fiscal Digital con <b>UUID {uuidtimbre} y Folio: {folio} </b> Así como su representación impresa.<br/><br/>Este correo electrónico ha sido generado automáticamente por el Sistema de Emisión de Comprobantes Digitales por lo que le solicitamos no responder a este mensaje, ya que las respuestas a este correo electrónico no serán leídas. En caso de tener alguna duda referente a la información contenida en el Comprobante Fiscal Digital contacte a <b>{nombreemisor}</b> para su aclaración.<br/><br/>Está recibiendo este correo electrónico debido a que ha proporcionado la dirección de correo electrónico a <b> {nombreemisor} </b> para hacerle llegar su Factura Electrónica.
Consulta dinamica Factura o Pagos - ocultar columna Nombre Receptor
La columna Nombre Receptor muestra la informacion que tiene del RFC del receptor en el catalogo de Clientes del motor de Emision, por lo que puede diferer del que esta en el XML del CFDI.
Se puede ocultar esta columna son la siguiente variable en el webconfig de la capa de presentacion.
Si se desa mostrar el nombre como esta en el Xml del CFDI se tiene que usar una entrada en custom data para que se extraiga y se muestre.
Variable para cambiar el nombre del RFC receptor Generico
De forma predetermina el valor que muestra las facturas con RFC Generico en el nombre:
Para cambiar este nombre generico se utiliza la siguiente variable en la tabla de cs_configuracion_emisor
Clave: nombre_remplazo_publicoengeneral_sin_informacionglobal
Valor: PUBLICO GENERAL
NO se debe usar PUBLICO EN GENERAL, ya que esta reservado apra las Facturas Globales (CFDI que tienen la seccion de Informacion Global)
COMO CONFIGURAR ORDENES DE COMPRA, REMISIONES Y AVISOS DE PAGO PARA BUZON UNIVERSAL
Para la configuración de estos, deberas solicitar en una funcionalidad las siguientes tareas:
se utiliza el ejemplo de moët, sin embargo, es necesario colocar las rutas de acuerdo a la configuración del sftp correspondiente dentro de los path de entrada, salida, error y respaldo, asi como los datos de conectividad, tales como, host, usuario, contraseña y puerto.
cabe mencionar que otro punto importante es validar y mantener la configuración restante considerando los tipos de archivos a procesar para cada uno de los metodos:
Orde de compra= odc
Retensión=nde
aviso de pago=apa
para los metadatos, se usan datos Genéricos para plantillas de validación y se especifica el esquema a usar por cada método, es decir pedido, remisión y aviso de pago.
donde:
nombre_instancia: colocar la instancia correspondiente al cliente
plantilla_validación: es el nombre generico de la plantilla y viene integrada en código.
metodo_carga: BATCH
tipo_pedido: ESQUEMA_PEDIDOV10, dato Genérico para ODC, puedes consultar en BD dentro de la tabla : select* from bu_mm_tipo_pedido
tipo_remisión: ESQUEMA_REMISIONV10, dato Genérico para Remisión, puedes consultar en BD dentro de la tabla : select* from bu_mm_tipo_remision
tipo_aviso_pago: ESQUEMA_AVISOPAGOMOËT, en este caso esta fue solicitada previamente a desarrollo y se establecio con el nombre de MOËT, puedes consultar en BD dentro de la tabla : select* from bu_mm_tipo_aviso_pago
considerado lo anterior procedemos con la configuración de las tareas:
Orden de Compra:
<tarea pathEntrada="/Vendors Portal/IN" pathSalida="/Vendors Portal/OUT" pathError="/Vendors Portal/ERROR" pathRespaldo="/Vendors Portal/BACKUP" sftpHost="*****************" usuarioEntrada="*******" passwordEntrada="*******" puertoFtp="****"incluirSubdirectorios="false" remplazarArchivoPorDescripcionFalla="true" regexRfcEmisorNombreArchivo="" regexRfcEmisorDirectorioArchivo="" regexRfcEmisorContenido="(?<=\](?i)Proveedor(?-i)\])[a-zA-Z]{3,4}[0-9]{6}[0-9a-zA-Z]{3}(?=\])"
extensionArchivoDatos="odc" extensionArchivoControl="odc"
extensionArchivoSalidaLog="log" metodoEnvioArchivo="ProcesarArchivo" tipoMensaje="ciclo_Comercial" endpointWebService="IArchivosBatchService_MotorBuzonUniv" numeroIntentosProcesarArchivos="1" maximoNumeroHilos="1" logDetallado="false"> <metadatos> <metadato clave="nombre_instancia" valor="RecepcionMoet"/> <metadato clave="plantilla_validacion" valor="PEDIDOV10"/> <metadato clave="metodo_carga" valor="BATCH"/> <metadato clave="tipo_pedido" valor="ESQUEMA_PEDIDOV10"/> <metadato clave="rutadescargalogspedidos" valor="/infutor/Mhmx/Portal de Proveedores/OUT"/> </metadatos> </tarea>
REMISIÓN
<tarea pathEntrada="/Vendors Portal/IN" pathSalida="/Vendors Portal/OUT" pathError="/Vendors Portal/ERROR" pathRespaldo="/Vendors Portal/BACKUP" sftpHost="*****************" usuarioEntrada="*******" passwordEntrada="*******" puertoFtp="****"
incluirSubdirectorios="false" remplazarArchivoPorDescripcionFalla="true" regexRfcEmisorNombreArchivo="" regexRfcEmisorDirectorioArchivo="" regexRfcEmisorContenido="(?<=\](?i)Proveedor(?-i)\])[a-zA-Z]{3,4}[0-9]{6}[0-9a-zA-Z]{3}(?=\])" extensionArchivoDatos="nde" extensionArchivoControl="nde" extensionArchivoSalidaLog="log" metodoEnvioArchivo="ProcesarArchivo" tipoMensaje="ciclo_Comercial" endpointWebService="IArchivosBatchService_MotorBuzonUniv" numeroIntentosProcesarArchivos="1" maximoNumeroHilos="1" logDetallado="false"> <metadatos> <metadato clave="nombre_instancia" valor="RecepcionMoet"/> <metadato clave="plantilla_validacion" valor="REMISIONV10"/> <metadato clave="metodo_carga" valor="BATCH"/> <metadato clave="tipo_remision" valor="ESQUEMA_REMISIONV10"/> <metadato clave="rutadescargalogspedidos" valor="/infutor/Mhmx/Portal de Proveedores/OUT"/> </metadatos> </tarea>
AVISO DE PAGO
incluirSubdirectorios="false" remplazarArchivoPorDescripcionFalla="true" regexRfcEmisorNombreArchivo="" regexRfcEmisorDirectorioArchivo="" regexRfcEmisorContenido="(?<=\](?i)Proveedor(?-i)\])[a-zA-Z]{3,4}[0-9]{6}[0-9a-zA-Z]{3}(?=\])" extensionArchivoDatos="apa" extensionArchivoControl="apa" extensionArchivoSalidaLog="log" metodoEnvioArchivo="ProcesarArchivo" tipoMensaje="ciclo_Comercial" endpointWebService="IArchivosBatchService_MotorBuzonUniv" numeroIntentosProcesarArchivos="1" maximoNumeroHilos="1" logDetallado="false">
</tarea>
Habilitar Emision de Retenciones
Para habilitar la emision de retenciones en el motor de emisión se debe cumplir con el requerimiento adminsitrativo.
Ventas tiene que aprobar la habilitación de emision de retenciones.
Configuracion:
Agregar opciones de menu:
Carga Archivo Excel
Consulta Retenciones
Cancelar Retenciones
- Admnistrar Retenciones
- Administrador Pegaso
- Fiscal
- Administrador Retenciones
Tabla: cs_tipo_retencion
Adicionar variable para permitir la emision de retenciones
tabla: configuracion_instancia
Clave: AppSettings.habilitado_emision_retenciones
Valor: true
Verificar la configuracion de los formatos esten asociados a la version correspondiente.
Si hay dudas en la tabla :
cs_configuracion_tiporetencion
Cambios al Anexo 29 de la Resolución Miscelánea Fiscal para el ejercicio de 2023
Boletín 02 / 0123
13 de enero de 2023
Cambios al Anexo 29 de la Resolución Miscelánea Fiscal para el ejercicio de 2023.
El 12 de enero de 2023 se publicó en el Diario Oficial de la Federación (DOF), el Anexo 29 de la Resolución Miscelánea Fiscal para el ejercicio fiscal de 2023 (Anexo 29 2023), en dicha publicación la autoridad realizó los siguientes cambios:
Lista de contribuyentes inscritos no cancelados en el Registro Federal de Contribuyentes (LRFC).
En la fracción III. "Especificaciones para la descarga y consulta de la LCO y LRFC", se observa un cambio en el apartado
III.2 "Lista de contribuyentes inscritos no cancelados en el Registro Federal de Contribuyentes" (LRFC), subapartado C. "Integración de la LRFC y aplicación de validaciones", en el que se integra en el numeral 6 el campo denominado "Marca de Retencion", esto para identificar a los contribuyentes emisores de CFDI de tipo Ingreso que son sujetos de retención de impuestos, de acuerdo a los siguientes valores:
- Valor 0 = Contribuyente persona física que no pertenezca al RESICO y persona moral de cualquier régimen.
- Valor 1 = Contribuyente persona física del RESICO no obligado a que le retengan ISR.
- Valor 2 = Contribuyente persona física del RESICO al que se debe retener ISR.
Este es un cambio que era ya esperado, esto debido a que el artículo Tercero Transitorio de la Resolución Miscelánea Fiscal (RMF) para 2023, la autoridad ya mencionaba que lo establecido en dicho numeral 6 denominado "Marca de Retención", incluido en el apartado C. "Integración de la LRFC y aplicación de validaciones", de la Sección, "III.2 de la fracción III, del Anexo 29, resultaría aplicable a partir del 1 de abril de 2023, por lo que esta mención ya anunciaba cambios a la integración de las listas RFC y modificaciones al Anexo 29, así como, la incorporación de la aplicación de la validación que utilicen esta "Marca de retención" y los valores en ella establecidos.
Validaciones adicionales al Anexo 20 y complementos.
En la fracción VI de este Anexo 29, se observa que la autoridad realizó cambios a las validaciones adicionales que deben realizar los proveedores de certificación de CFDI a los comprobantes fiscales que certifiquen. Los cambios se ubican en el apartado VI.1 "Validaciones adicionales al Anexo 20".
- Atributo Exportacion
En el numeral 3 de este apartado se precisa que para efecto de la segunda validación al atributo "Exportacion",
consistente en que:
"Si el atributo contiene el valor "02" que corresponde a "Definitiva con clave A1", debe existir el complemento
para Comercio Exterior".
Se debe considerar además lo siguiente:
"Si el tributo contiene el valor "04" que corresponde a "Definitiva con clave distinta a A1 o cuando no existe enajenación en términos del CFF", puede o no existir el complemento para Comercio Exterior".
Con motivo de la incorporación de esta validación al atributo "Exportación", la validación contenida en el
numeral 3, se recorre al 4.
- Nodo "InformacionGlobal"
En este mismo apartado de validaciones adicionales al Anexo 20, en el numeral 5 se precisa que para efectos
de la segunda validación al Nodo "InformacionGlobal", consistente en que:
"Si el valor registrado en el atributo Rfc del nodo Receptor contiene XAXX010101000 y el valor registrado en el atributo Nombre del nodo Receptor contiene el valor "PUBLICO EN GENERAL" este nodo debe existir"
Conjuntamente se debe considerar lo siguiente:
Que el valor registrado en el atributo TipoDeComprobante debe ser "I" que corresponde a un CFDI de tipo ingreso.
- Nodo "ACuentaTerceros"
De igual forma, se incorpora la validación al nodo "ACuentaTerceros", para señalar que cuando se trate de operaciones de expedición de CFDI por residentes en México que prestan servicios de intermediación entre terceros a oferentes de bienes y servicios residentes en el extranjero, se deben aplicar las siguientes validaciones a los siguientes atributos:
RfcACuentaTerceros:
Si el valor registrado en este atributo es "EXT990101NI1", el valor de este atributo no debe validarse en la lista l_LCO y el atributo NombreACuentaTerceros debe contener el valor "EXPEDICIÓN DE CFDI POR RESIDENTES EN MÉXICO QUE PRESTAN SERVICIOS DE INTERMEDIACIÓN ENTRE TERCEROS A OFERENTES DE BIENES Y SER- VICIOS RESIDENTES EN EL EXTRANJERO".
NombreACuentaTerceros:
Si el valor registrado en este atributo es "EXPEDICIÓN DE CFDI POR RESIDENTES EN MÉXICO QUE PRESTAN SERVICIOS DE INTERMEDIACIÓN ENTRE TERCEROS A OFERENTES DE BIENES Y SERVICIOS RESIDENTES EN EL
EXTRANJERO", el valor de este atributo no debe validarse en la lista de RFC inscritos no cancelados en el SAT y el atributo RfcACuentaTerceros debe contener el valor "EXT990101NI1"
RegimenFiscalACuentaTerceros:
Si el atributo RfcACuentaTerceros contiene el valor "EXT990101NI1" en este atributo se debe registrar la clave
"616".
DomicilioFiscalACuentaTerceros:
Si el valor del atributo RfcACuentaTerceros es "EXT990101NI1", este atributo debe ser igual al valor del atri- buto LugarExpedicion y no debe validarse en la lista de RFC inscritos no cancelados en el SAT.
- Nodo "Retenciones"
Asimismo, se incorporan validaciones al nodo "Retenciones", que son aplicables a nivel concepto del CFDI de tipo Ingreso de la fracción I del Anexo 20, consistentes en que:
1. Debe existir el Nodo Retenciones:
- Cuando el RFC del emisor contenga la marca Retención con valor "2" que corresponde a "Contribuyente persona física del RESICO al que se debe retener ISR" en la lista de RFC inscritos no cancelados en el SAT y el atributo RegimenFiscal del Nodo Emisor tenga el valor 626, que corresponde a "Régimen Simplifi- cado de Confianza".
- Debe existir el nodo "Retenciones", con al menos un nodo hijo "Retencion", donde el atributo "Im- puesto" contenga un valor "001" que corresponde a "ISR" y en el atributo "TasaOCuota" se registre el valor 0.0125, es decir el 1.25 %, siempre que el atributo "Rfc" del Nodo "Receptor" contenga una lon- gitud de 12 posiciones (persona moral).
2. Puede existir el nodo "Retenciones", siempre que:
- El RFC del emisor contenga la marca Retención con valor "1" que corresponde a "Contribuyente persona física del RESICO no obligado a que le retengan ISR", en la lista de RFC inscritos no cancelados en el SAT:
- El atributo "RegimenFiscal" del Nodo Emisor, contenga el valor "626", que corresponde a "Régimen Simplificado de Confianza".
- El atributo "Rfc" del Nodo "Emisor" contenga una longitud de 13 posiciones (persona física) y el atributo
"Rfc" del Nodo "Receptor" contenga una longitud de 12 posiciones (persona moral).
- Y se deberá validar que a nivel del Concepto no contenga el valor 001 (ISR) en el atributo del Impuesto
del nodo hijo "Retencion" del elemento Retenciones.
3. Cuando el RFC del emisor contenga la marca Retención con valor "0" que corresponde a "Contribuyente persona física que no pertenezca al RESICO y persona moral de cualquier régimen", en la lista de RFC inscritos no cancelados en el SAT, se deberá estar a las validaciones establecidas en el Anexo 20 para este nodo.
Este cambio al nodo Retenciones, deriva de la incorporación del numeral 6 a la integración de las listas RFC "Marca de retención", de la fracción III, apartado III.2 "Lista de contribuyentes inscritos no cancelados en el Registro Federal de Contribuyentes" (LRFC), subapartado C. "Integración de la LRFC y aplicación de validaciones" del Anexo 29 para 2023, del cual el artículo Tercero Transitorio de la RMF para 2023 señala que será aplicable partir del 1 de abril de 2023.
CFDI de retenciones e información de pagosAsí mismo, en la fracción VI de este Anexo 29, en el apartado VI.2 "Validaciones adicionales a complementos", numeral 2, "Validaciones al CFDI de retenciones e información de pagos", la autoridad incorporó validaciones a los atributos NomDenRazSocR, y DomicilioFiscalR del CFDI de retenciones e información de pagos, conforme a lo siguiente:
NomDenRazSocR:
Si el valor registrado en este atributo es "PÚBLICO EN GENERAL", el valor XAXX010101000" debe existir en el
atributo Rfc del nodo Receptor:Nacional.
DomicilioFiscalR:
Si el valor del atributo RfcR del nodoes "XAXX010101000", el valor de este atributo debe ser igual al registrado
en el atributo LugarExpRetenc.
Finalmente, es importante para los Proveedores de certificación de CFDI, lo importante que es la correcta implementación y ejecución de estas validaciones en la certificación de los comprobantes fiscales, dadas las sanciones de las que puede ser objeto en su incumplimiento.
Aquí se puede consultar las publicaciones reseñadas:
Emision - Nomina -Configuracion para que la capa de Presentacion soporte archivos mas grandes
Para que la capa de presentacion soporte archivos mas grandes se requiere que se revisen los siguientes segmentos del webconfig de presentacion:
Bindings, verificar que los valores del Binding usado tenga el maximo valor.
Binding: BasicHttpBinding_TextEncoding_Ssl o BasicHttpBinding_TextEncoding,
Valor: 2147483647
Segmento httpruntime
Debe estar asi:
<httpRuntime targetFramework="4.8" executionTimeout="800" waitChangeNotification="5" maxWaitChangeNotification="10" maxRequestLength="2147483647"/>
El parametro maxRequestLength determina el tamaño de la informacion que acepta el portal,
En la seccion: system.webServer, asegurarse que exista el subsegmento: security
Debiendose ver asi:
<security> <requestFiltering> <requestLimits maxAllowedContentLength="2147483648"/> </requestFiltering> </security>En el webconfig d eprocesamiento debe estar igualemnte configurado.
Procedimiento para configurar el sniffer de peticiones a servicios cloud pegaso
Con la necesidad de poder obtner las peticiones realizadas a los servicios REST que estan en la nube se genero un sitio web para servir como intermediario entre el motor y los servicios web tipo REST de Pegaso, como son el validador, timbradora y catologos.
En principio en los motores para consumir los servicios REST se configuran en Base de datos.
Este servicio debe ser utilizado bajo la premisa de estar configurado solo un lapso de tiempo de minutos, ya que la velocidad se reduce considerablemente.
El funcionamiento es, se configura la url del servicio que se desea obtener la peticion y la respuesta en el motor de emision-recepcion, la peticion es enviada a este sitio y se crearan dos archivos peticion y respuesta y se regresara al motor la respuesta obtenida por el servicio.
Por ejemplo si se desea obtener las peticiones del servicio de validacion la url configurada en base de datos es la siguiente:
AppSettings.serviciovalidacion_timbrado.url https://validacion.pegasotecnologia.mx/api/ValidadorParaTimbrado
La url del servicio de obtencion de peticion y respuesta es la siguiente; https://debugtransqa.pegasotecnologia.mx
Por lo que la url completa a configurar debe ser:
https://debugtransqa.pegasotecnologia.mx/validacion.pegasotecnologia.mx/api/ValidadorParaTimbrado
Como se vera se omite el protocolo de la url y solo se deja la url mas la ruta virtual.
Para revisar los archivos generados estos se depositan en un blob storage el cual el endpoint es el siguiente:
BlobEndpoint=https://httpdebugtransqa.blob.core.windows.net/;QueueEndpoint=https://httpdebugtransqa.queue.core.windows.net/;FileEndpoint=https://httpdebugtransqa.file.core.windows.net/;TableEndpoint=https://httpdebugtransqa.table.core.windows.net/;SharedAccessSignature=sv=2021-06-08&ss=bfqt&srt=sco&sp=rlp&se=2027-12-31T12:52:40Z&st=2022-10-19T03:52:40Z&spr=https&sig=TEGKrweQwHfg%2FD1BtG%2Be7WYxJR1VrhPzFTdBO8wk02U%3D;
Para poder revisar el blob starage se usa la herremitna Miscorosft Azure Storage Explorer y se configura la url indicada arriba
Envio Reporte Masivo en Excel
Para poder activar la opción de Envio Reporte Masivo:
Es necesario, solicitar a BD la configuración de las siguientes variables:
habilitar_descarga_cfd_consultados
TamanioPaginacionReporteAsicncrono
También es necesario a nivel webconfig solicitar la siguiente configuración:
<add key="habilitar_descarga_cfd_consultados" value="true"/>
OPCIONES DESCARGA MASIVA en OpciónConsultar C.F.D.I.
Desde la sección OPCIONES DESCARGA MASIVA
Puedes ejecutar la Descarga Masiva (descarga asíncrona) sin necesidad de ejecutar la consulta de comprobantes
Para activarla se requiere registrar a nivel emisor la siguiente variable 'habilitar_descargamasiva_filtros' con valor 'True'
Actualización Preguntas Frecuentes Carta Porte
Actualización Preguntas Frecuentes Carta Porte
19 de agosto de 2021
El SAT publicó una actualización a las Preguntas Frecuentes de Carta Porte.
Dentro de las preguntas que se responden se encuentran:
Prácticamente es un documento nuevo, muchas de las preguntas que se responden en versiones anteriores, ya no se encuentran en esta nueva versión.
Te recomendamos consultar el documento que se encuentra disponible en este link: http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Preguntas_frecuentes_CartaPorte.pdf
Acompáñanos en LinkedIn https://www.linkedin.com/company/pegaso-tecnologia
|
CCP - Cambio-Carta Porte pregunta 8
Sobre este tema, la pregunta fue actualizada, resolviendo la interpretación
4. ¿Quién debe emitir el CFDI de tipo traslado con complemento "Carta Porte"?
El CFDI de tipo traslado con complemento "Carta Porte" se debe emitir de manera previa a que se brinde el servicio de traslado de bienes o mercancías por cualquier medio de transporte, ya sea por vía terrestre, férrea, marítima, aérea o fluvial, por:
- La propietaria o el propietario de los bienes o mercancías, cuando estos se trasladen por medios propios; y
- II. El intermediario o agente de transporte, cuando preste servicios de logística para el traslado de los bienes o las mercancías, o tenga mandato para actuar por cuenta del cliente, siempre que dicho traslado se realice con medios propios.
Fundamento: Artículos 29 y 29-A del CFF, reglas 2.7.1.8. y 2.7.1.9. de la RMF vigente.
Por favor, recordar que esto es una referencia rápida, si el cliente requiere de mayor asesoría o interpretación, canalizarlo con el ejecutivo de Comercial.
Complemento de Comercio Exterior Unidad Aduana
Pregunta
me comenta mi AA que hay que declarar los kilos de la mercancías pues así lo requiere la fracción arancelaria.
En este sentido en que parte del formato debería de ir esta información, y me cuestiona que porque declaramos UNIDAD ADUANA 01?
Esta Unidad Aduana 01, es la que son kgs y en la pestaña de mercancía del anexo pusimos los kilogramos de cada item pero marco error.
Respuesta
- hay que declarar los kilos de la mercancías pues así lo requiere la fracción arancelaria. De acuerdo
- En este sentido en que parte del formato debería de ir esta información, y me cuestiona que porque declaramos UNIDAD ADUANA 01? Debe ir en unidad aduana, y la clave 01 es Kilos
Complemento de Recepción de Pagos (Recibo de Pago) cuando se tienen diferentes Monedas de pago y Monedas de documento relacionado se procede así
El primer ejemplo es el más común,
- Documento en dólares, pago en Pesos. Tipo de cambio 20.00
1 dólar es igual a 20 pesos
1/20=.05
DoctoRelacionado IdDocumento="01C01001-A010-42D2-9DAB-AD5800B77BBF" Serie="MEXIR" Folio="842" MonedaDR="USD" TipoCambioDR="0.050000"
MetodoDePagoDR="PPD" NumParcialidad="1" ImpSaldoAnt="178.59" ImpPagado="178.59" ImpSaldoInsoluto="0"/>
No importa cual fue el tipo de cambio de cuando se emitió la factura, el TipoCambioDR se ajusta a la fórmula indicada
- Documento en pesos, pago en dólares. Tipo de cambio 20.00
1 Peso es igual a .05 dólares
1/.05=20
DoctoRelacionado IdDocumento="01C01001-A010-42D2-9DAB-AD5800B77BBF " Serie="MTYR" Folio="980" MonedaDR="MXN" TipoCambioDR="20.000000" MetodoDePagoDR="PPD" NumParcialidad="1" ImpSaldoAnt="254.30" ImpPagado="254.30" ImpSaldoInsoluto="0"/>
Reglas no escritas
El importe del pago, la moneda, la fecha, la forma, NO deben modificarse.
El tipo de cambio del pago (cuando no es MXN) es un valor que debería tomarse de una fuente oficial (pero se podría poner casi cualquier valor, no está activa la regla de comprobación)
En el Documento Relacionado, La moneda y el Importe pagado NO se modifican, el tipo de cambio del DR es el que se ajustará (no importa con que TC se emitió la factura)
Si tiene algún otro punto de vista por favor compártanlo.
Actualzación de Guías de llenado en el Portal del SAT
Estimado Proveedor.
Se informa que se publicó en el portal del SAT, la actualización de la "Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet" y "Guía de llenado del CFDI global Versión 3.3 del CFDI", dónde los principales cambios son:
"Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet"
- Se adiciona el apéndice 11 Instrucciones específicas de llenado en el CFDI aplicable a operaciones individuales a Hidrocarburos, Petrolíferos y Servicios relacionados.
La guía la podrán consultar en el link: http://omawww.sat.gob.mx/tramitesyservicios/Paginas/anexo_20_version3-3.htm
"Guía de llenado del CFDI global Versión 3.3 del CFDI"
- Se adiciona el apéndice 3 Instrucciones específicas de llenado en el CFDI global aplicable a Hidrocarburos y Petrolíferos
La guía la podrán consultar en el link: http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/GuiaAnexo20Global.pdf
Las dudas o aclaraciones que tengan al respecto se atenderán a través del sistema de planteamientos.
Actulizacion de Preguntas Frecuentes
Recibimos del SAT las siguientes orientaciones de planteamientos pendientes por parte de AMEXIPAC.
Marcamos en rojo las respuestas del SAT a los planteamientos y se copian preguntas frecuentes añadidas al portal.
Nuevas preguntas frecuentes
El día 13 de agosto del 2019 se publicaron en el Portal del SAT, preguntas frecuentes sobre el registro de la Forma y Método de pago en los CFDI.
https://www.sat.gob.mx/consultas/35025/formato-de-factura-electronica-(anexo-20)
- Duda sobre estímulo fronterizo y complemento por cuenta de tercero
Con las notificaciones y cambios del SAT nos surge la siguiente duda:
¿Es posible que Emisor con ""RFC 1"" que no cuenta con la validez de obligaciones 2 en la LCO (Estimulo fronterizo), pueda emitir un complemento concepto por cuenta de terceros a un ""RFC 2"" que si cuente con la validez de obligaciones 2 en la LCO?, es decir, usar una tasa del 8% a nivel complemento concepto por cuenta de terceros y que el emisor del comprobante RFC 1 use una tasa del 16% ya que no cuenta con el estimulo fronterizo. En pocas palabras ¿El siguiente ejemplo de XML sería válido?"
Si el emisor (comisionista) no cuenta con la validez de obligaciones 2 en la LCO, pero cuenta con validez de obligaciones 1 puede emitir el complemento por cuenta de terceros, si el tercero es quien desea aplicar el estímulo fiscal debe contar con la validez de obligaciones 2 en la LCO, ésta información se verá reflejada a nivel complemento, donde se registra la información del tercero.
- Dudas respecto al complemento plataformas tecnológicas
Tenemos dudas respecto al complemento de plataformas tecnológicas:
Para el atributo MonTotalporUsoPlataforma, El valor de este atributo debe ser igual a la suma de los atributos ""Importe"" de los nodos ""ComisiondelServicio""
En la guía se menciona que dicho atributo debe ser igual al atributo importe.
SPT122 El valor del atributo MonTotalUsoPlataforma es diferente la suma de los atributos ""importe"" de los nodos ""ComisiondelServicio""
En la matriz de errores para el atributo Importe, menciona que el valor del atributo importe del nodo""ComisiondelServicio"" debe ser mayor a cero.
Con la interpretación que estamos haciendo estamos rechazando el complemento si tiene valor 0, es correcto o que valor debe venir en ese campo?
La duda se origina ya que un cliente menciona que no cobra comisión x el uso de la plataforma y por eso asigna valor 0
La validación correspondiente al atributo MonTotalporUsoPlataforma de conformidad con el estándar técnico es la siguiente:
En efecto, de conformidad con la validación correspondiente el importe es igual a la suma de la ComisiondelServicio que debe ser mayor que cero, por lo que es correcta su interpretación.
Otra duda respecto a este mismo complemento es si tienen ustedes idea si el #Servicios tiene que ver con el num de repartos? es decir, se podría hacer un servicio global por repartidor? o sería necesario desglosar cada uno de los repartos?"
No es posible hacer un servicio global, se deberá detallar cada uno de los servicios prestados a través del Nodo “Servicios”
- Complementos de Contribuciones Locales
Respecto a los Complementos de Contribuciones Locales:
• Es correcto emitir un CFDI que no coincida con lo pagado por la aplicación de una retención de contribuciones locales?
No, no es correcto emitir un CFDI que no coincida con lo pagado por la aplicación de una retención de contribuciones locales.
Por lo que, de ser el caso, deberá cancelar el comprobante con errores y reexpedirlo con los datos correctos.
• Si la retención de contribuciones locales deben de existir en el cuerpo del CFDI para que el neto coincida con lo pagado?"
De conformidad con el estándar técnico del complemento Impuestos Locales es necesario que las retenciones se registren a nivel de complemento:
El campo Total del comprobante debe incluir la suma de los impuestos locales, los Proveedores de Certificación de CFDI deberán validar que se incluya el importe de los impuestos locales, conforme lo indican las validaciones adicionales contenidas en el Anexo 20:
Adicionalmente la Guía de llenado del Anexo 20 establece lo siguiente para el campo “Total”:
Nómina CompensacionSaldosAFavor
Complemento Nómina
Se actualizó la regla para el nodo CompensacionSaldosAFavor que revisaba la fecha en que se expedía el comprobante cuando lo correcto es que revise la Fecha de Pago.
Complemento Consumo de Combustible
En el Complemento Consumo de Combustible, se actualizó el portal para que muestre la versión vigente del complemento.
Hora de Pago a 12:00 PM
En el Complemento de Recepción de Pago, en el campo FechaPago además de la fecha, se debe colocar también la hora en que se recibió el dinero. Según la guía de llenado, cuando no se conoce la hora se debera colocar 12:00:00.
En el portal, al elegir la fecha, por default se coloca 12 AM (00:00:00), la hora se debe cambiar a través del ícono de reloj a la derecha del campo.
Esta disponible una actualización para que por default coloque 12 PM.
SAT: Orientación - respecto al Proceso de Cancelación
Buenos días,
Por medio del presente se comparten comentarios enviados por el SAT respecto a una consulta del proceso de cancelaciones compartida por un socio (comentarios SAT en rojo):
ORIENTACIÓN
Para un Comprobante con estatus Cancelable con Aceptación
1.- El emisor de la factura solicita la cancelación de una factura con estatus (Cancelable con Aceptación)
2.- Nosotros como PAC realizamos la solicitud de cancelación al SAT, si el comprobante es válido y cumple con todos los criterios de cancelación el SAT responde con un acuse de cancelación con un estatus 201
3.- El SAT procede a colocar el comprobante con un estatus de En proceso mismo que solo cambia por 2 motivos:
A.- Que el receptor acepte o rechace
B.- Pasan 3 días sin que el receptor responda la solicitud de cancelación.
En este caso es cancelado por plazo vencido
Lo que hemos detectado es que el estatus de estos comprobantes NO es actualizado por el SAT de acuerdo al proceso aun cuando se recibe el acuse de cancelación.
Ejemplo:
El comprobante con UUID 62DABC1E-6D9D-4451-B276-C55F50172A6C fue enviado a cancelar el día 2019-04-08 este envío y recepción es amparado con el siguiente acuse:
Posteriormente se consulta el estatus y el resultado es el siguiente:
Se ha intentado nuevamente enviar a cancelar el comprobante pero el SAT no responde con un rechazo.
COMENTARIOS SAT:
A manera de orientación te compartimos comentarios sobre la cancelación, en su caso, la opción B fue el resultado del folio 62DABC1E-6D9D-4451-B276-C55F50172A6C :
Al solicitar la cancelación de un CFDI con estatus de Cancelable con aceptación, el receptor del comprobante tiene las siguientes opciones:
- Aceptar la cancelación: en este caso el CFDI se cancela por aceptación del receptor
- Rechazar la cancelación: en este caso el CFDI continua con estatus de Vigente
- No responder la solicitud de cancelación: pasado el plazo del 3 días hábiles sin recibir respuesta del receptor, el comprobante se cancela de forma automática por Plazo Vencido.
Por lo anterior, el emisor podrá consultar el resultado de la solicitud de cancelación a través del Portal del SAT en la siguiente dirección:
https://cfdiau.sat.gob.mx/nidp/wsfed/ep?id=SATUPCFDiCon&sid=0&option=credential&sid=0
O bien, a través de un Proveedor de Certificación en el Web Service de Consulta CFDI.
.
¿Le ha sido útil este artículo?
¡Qué bien!
Gracias por sus comentarios
¡Sentimos mucho no haber sido de ayuda!
Gracias por sus comentarios
Sus comentarios se han enviado
Agradecemos su esfuerzo e intentaremos corregir el artículo