SAT: Nueva prórroga para el uso del complemento de recepción de pagos

Como recordarás el 1 de julio del 2017 entró en vigor, de manera opcional, la emisión de Comprobantes Digitales a través de Internet (CFDI) versión 3.3 con el complemento de Recepción de Pagos, teniendo como fecha límite para su uso obligatorio el próximo 1 de abril del 2018.

Debido a lo tormentoso que ha sido la adopción de la nueva versión 3.3 CFDI y el uso de sus complementos, el Servicio de Administración Tributaria (SAT) se ha visto obligado en otorgar diversas prórrogas para que los contribuyentes puedan cumplir con sus obligaciones fiscales.

Por lo que en esta ocasión no es la excepción, ya que la autoridad anunció la extensión del plazo para hacer obligatorio el uso de la factura de recepción de pagos, esto de acuerdo con lo indicado en la Primera Resolución de Modificaciones a la Resolución Miscelánea Fiscal para 2018 (1RMRMF_2018) en donde a la letra dice:

Se reforma el Artículo Séptimo Transitorio de la RMF para 2018 publicada el 22 de diciembre de 2017, para quedar como sigue:

Séptimo    Para los efectos de la regla 2.7.1.35, los contribuyentes podrán optar por expedir CFDI usando la versión 3.3 del Anexo 20 sin incorporar el complemento para recepción de pagos hasta el 31 de agosto de 2018

De acuerdo a lo anterior, la entrada en vigor de forma obligatoria en el uso de facturas con el complemento de la recepción de pagos, será a partir del 1 de septiembre de 2018.

Si deseas obtener el documento de actualización a la RMF2018, te invitamos a dar clic en la siguiente liga:

1RMRMF_2018_160218

Si tienes alguna duda con respecto a esta publicación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

SAT: CFDI 3.3 Recepción de pagos

En Facturando siempre queremos mantenerte informado, por lo que ponemos a tu disposición la siguiente publicación correspondiente a la factura de recepción de pagos o también conocido como “Recibo Electrónico de Pago” en donde se detalla todo lo relacionado en la emisión de este tipo de comprobante.

¿Qué es?
El recibo electrónico de pago es un Comprobante Fiscal Digital a través de Internet (CFDI) en el cual se incorpora información específica sobre los pagos recibidos, ya sea por la recepción de pagos en parcialidades o pago diferido.

¿Quién lo emite?
El CFDI con “Complemento para recepción de pagos” es emitido por el contribuyente que reciba el pago de una contraprestación, esto es, el emisor del comprobante inicial.

Vigencia
La emisión del recibo electrónico de pago entró en vigor de forma opcional el pasado 1 de julio de 2017, para convertirse en obligatorio a partir del 1 de diciembre de 2017.

Consideraciones
Para llevar a cabo la correcta emisión del recibo electrónico de pago, se deberán de tomar en cuenta las siguientes consideraciones:

  • La emisión de este recibo solo podrá generarse con la versión 3.3 del CFDI.
  • El plazo máximo para su emisión es al décimo día natural del mes siguiente en el que fue recibido el pago.
  • No se podrá emitir un CFDI con complemento de recepción de pagos con una fecha de pago futuro.
  • Debe de expedirse solo para los siguientes casos:
    • Por la recepción de pagos en parcialidades.
    • En los casos en que se reciba el pago de la contraprestación en una sola exhibición, pero que ésta no sea cubierta al momento de la expedición de la factura.
    • Cuando se trate de operaciones a crédito y estas se paguen totalmente en fecha posterior a la emisión de la factura correspondiente
  • Se podrá emitir un solo recibo de pago por todos los pagos recibidos en un periodo de un mes, siempre y cuando estos correspondan a un mismo receptor del comprobante
  • Si no existe indicación del pagador en cuanto a el o los CFDIs a los que se aplicará el pago, el receptor del pago lo aplicará al o los CFDIs pendientes de pago más antiguos.

Cancelaciones
Para el caso de cancelaciones, las consideraciones a tomar en cuenta son las siguientes:

  • Cuando exista un CFDI con complemento de recepción de pago que acredite que la contraprestación ha sido total o parcialmente pagada, el CFDI por el total de la operación no podrá ser cancelado.
  • Podrá cancelarse un recibo electrónico de pago con errores, siempre y cuando exista uno nuevo que lo sustituya.
  • Si existe un CFDI para recepción de pagos que no debió de haberse emitido por que la contraprestación ya se había pagado totalmente, al cancelarse el mismo deberá sustituirse por otro con un importe de un peso.

Llenado del comprobante

Deberá de ponerse extremada atención al llenado de este tipo de comprobantes debido a que tiene características muy específicas.

A continuación, se describen los únicos datos y su valor que deberán de existir en un CFDI con complemento de recepción de pagos, siendo estos los siguientes:

  • Version = 3.3
  • Serie = número de serie para control interno, conformado de 1 hasta 25 caracteres alfanuméricos
  • Folio = folio de control interno, acepta de 1 hasta 40 caracteres alfanuméricos
  • Fecha = fecha y hora de expedición del comprobante, expresado en el formato AAAA-MM-DDThh:mm:ss
  • Sello = sello digital del comprobante generado con el certificado de sello digital del contribuyente utilizado en la emisión del comprobante
  • NoCertificado = número que identifica al certificado de sello digital del emisor
  • Certificado = contiene el certificado de sello digital del emisor
  • SubTotal = deberá de registrarse el valor de cero “0”
  • Moneda = se registra como valor “XXX”
  • Total = se debe de registrar como valor cero “0”
  • TipoDeComprobante = deberá registrarse la clave “P” (Pago)
  • Lugar de expedición = registrar el código postal del lugar de expedición del comprobante, este debe de corresponder con alguna clave de código postal del catálogo del SAT
  • Confirmacion (opcional) = se deberá de registrar, cuando se requiera, la clave de confirmación cuando se expida el comprobante con importes o tipo de cambio fuera del rango permitido
  • CfdiRelacionados (opcional) / TipoRelación = registrar la clave “04” (Sustitución de los CFDIs previos), cuando se trate de la sustitución de un recibo electrónico de pagos por corrección de errores
  • CfdiRelacionado (opcional) / UUID = registrar el folio fiscal (UUID) del comprobante relacionado
  • Emisor / Rfc = registrar la clave en el registro federal de contribuyentes del emisor del comprobante (Longitud: persona física 13 posiciones, persona moral 12 posiciones)
  • Emisor / Nombre = registrar el nombre, denominación o razón social del emisor del comprobante fiscal
  • Emisor / RegimenFiscal = registrar la clave del régimen fiscal del contribuyente emisor bajo el cual se está emitiendo el comprobante (ver catálogo c_RegimenFiscal)
  • Receptor / Rfc = se debe registrar la clave en el registro federal de contribuyentes del receptor del comprobante (Longitud: persona física 13 posiciones, persona moral 12 posiciones)
  • Receptor / Nombre = registrar el nombre, denominación o razón social del receptor del comprobante fiscal
  • Emisor / ResidenciaFiscal (opcional) = cuando el receptor del comprobante sea un residente en el extranjero, se debe registrar la clave del país de residencia para efectos fiscales del receptor del comprobante
  • Emisor / NumRegIdTrib (opcional) = captura el número de registro de identidad fiscal del receptor del comprobante fiscal cuando éste sea residente en el extranjero
  • Emisor / UsoCFDI = se debe registrar la clave “P01” (Por definir)
  • Conceptos / Concepto / ClaveProdServ = se debe registrar el valor “84111506”
  • Conceptos / Concepto / Cantidad = registrar el valor “1”
  • Conceptos / Concepto / ClaveUnidad = se debe registrar el valor “ACT”
  • Conceptos / Concepto / Descripcion = registrar el valor “Pago”
  • Conceptos / Concepto / ValorUnitario = se debe registrar como valor “0”
  • Conceptos / Concepto / Importe = se debe registrar el valor “0”

Llenado del complemento recepción de pagos
Para el caso del llenado del complemento de recepción de pagos, deberán de existir y contener los siguientes valores:

  • Version = 1.0
  • FechaPago = Se debe registrar la fecha y hora en la que el beneficiario recibe el pago, bajo el formato AAAA-MM-DDThh:mm:ss
  • FormaDePAgoP = Se debe registrar la clave correspondiente a la forma en que se recibió el pago, de acuerdo con el catálogo c_FormaPago, la cual debe ser siempre distinta a la clave 99 (Por definir)
  • MonedaP = Se registra la clave correspondiente a la moneda con la que se recibió el pago, hasta con la cantidad de decimales que soporte, si el valor es diferente de la clave “MXN”, deberá de existir el campo TipoCambioP, su valor nunca podrá ser igual a “XXX”
  • TipoCAmbioP (condicional) = Se debe registrar el tipo de cambio de la moneda a la fecha en que se recibió el pago, cuando MonedaP sea diferente de “MXN”
  • Monto = Deberá de registrarse el importe del pago, este debe ser mayor a cero “0” y menor o igual al campo ImpPagado
  • NumOperacion (condicional) = Se puede registrar el número de cheque, número de autorización, número de referencia, clave de rastreo en caso de ser SPEI, línea de captura o algún número de referencia o identificación análogo que permita identificar la operación correspondiente al pago efectuado, podrá ser de 1 hasta 100 caracteres
  • RfcEmisorCtaOrd (condicional) = registrar la clave del RFC de la entidad emisora de la cuenta origen (operadora, banco o institución financiera, etc.), si se trata de un residente en el extranjero se deberá registrar la clave del RFC genérico XEXX010101000
  • NomBancoOrdExt (condicional) = se debe expresar el nombre del banco ordenante, es requerido en caso de ser extranjero
  • CtaOrdenante (condicional) = registrar el número de la cuenta con la que se realizó el pago, podrá ser de 10 hasta 50 caracteres
  • RfcEmisorCtaBen (condicional) = registrar la clave del RFC de la entidad emisora de la cuenta destino (operadora, banco o institución financiera, etc.)
  • CtaBeneficiario (condicional) = incorporar el número de cuenta en donde se recibió el pago
  • TipoCadPago (condicional) = Se puede registrar la clave del tipo de cadena de pago que genera la entidad receptora del pago. Por el momento la única calve permitida es 01 – SPEI, si existe este campo es obligatorio registrar los campos CertPago, CadPago y SelloPago
  • CertPago (condicional) = Es el certificado que corresponde al pago, como una cadena de texto en formato base 64
  • CadPago (condicional) = Es la cadena original del comprobante de pago generado por la entidad emisora de la cuenta beneficiaria
  • SelloPago (condicional) = Es el sello digital que se asocie al pago, debe ser expresado como una cadena de texto en formato base 64

Relación de documentos que ampara el pago
En cuanto a los documentos que amparan al recibo de pago tenemos:

  • IdDocumento = Se debe registrar el identificador del documento relacionado con el pago. Este dato debe ser un folio fiscal (UUID) de la Factura Electrónica
  • Serie (opcional) = Se puede registrar la serie del comprobante para control interno del contribuyente, acepta una cadena de caracteres desde 1 hasta 25
  • Folio (opcional) = Se puede registrar el folio del comprobante para control interno del contribuyente, acepta una cadena de caracteres desde 1 hasta 40
  • MonedaDR = Se debe registrar la clave de la moneda utilizada en los importes del documento relacionado, se deberá considerar lo siguiente:
    • Cuando se usa moneda nacional o el documento relacionado no especifica la moneda se registra MXN (Peso Mexicano)
    • Los importes registrados en los campos ImpSaldoAnt, ImpPagado e ImpSaldoInsoluto de esta sección, deben corresponder a esta moneda
    • Este campo no debe contener la clave “XXX”
    • Si este campo y el campo MonedaP son MXN, no debe existir TipoCambioDR
    • Si este campo es MXN y diferente de MonedaP, TipoCambioDR debe ser “1”
  • TipoCambioDR (condicional) = Es el tipo de cambio correspondiente a la moneda registrada en el documento relacionado
  • MetodoDePagoDR = Se debe registrar la clave PPD (Pago en parcialidades o diferido) que se registró en el campo MetodoPago del documento relacionado
  • NumParcialidad = Es el número de parcialidad que corresponde al pago. Es requerido cuando MetodoDePagoDR contiene Pago en parcialidades o diferido). En el caso de que el pago sea diferido, se debe registrar el valor “1”
  • ImpSaldoAnt (condicional) = Es el monto del saldo insoluto de la parcialidad anterior. Es requerido cuando MetodoDePagoDR contiene Pago en parcialidades o diferido). En el caso de que sea la primera parcialidad este campo debe contener el importe total del documento relacionado. En el caso de que se reciba el pago diferido, se debe registrar el monto total de la operación del documento relacionado. Este dato debe ser mayor a 0
  • ImPagado (condicional) = Es el importe pagado que corresponde al documento relacionado. Este dato es obligatorio cuando exista más de un documento relacionado o cuando existe un documento relacionado y el campo TipoCambioDR tiene un valor. El importe debe ser mayor a 0
  • ImpSaldoInsoluto (condicional) = Es la diferencia entre el importe del saldo anterior y el monto del pago. Debe ser mayor o igual a 0 y debe calcularse de los campos: ImpSaldoAnt menos el ImpPagado
  • Impuestos = Este nodo no debe existir

Beneficios
Dentro de los beneficios que trae consigo la emisión de la factura de recepción de pagos tenemos:

  • Evita la cancelación indebida de facturas
  • Evita la falsa duplicidad de ingresos en la facturación de parcialidades
  • Se podrá identificar si una factura ha sido o no pagada

Soluciones para el recibo de pago
Si deseas emitir un recibo electrónico de pago, queremos comentarte que ya todas nuestras soluciones ofrecen soporte al mismo:

  • EDL, librería (DLL) para generar los recibos.
  • EDS, software con el que, usando archivos de texto, podrás generar tus recibos electrónicos de pago.

Con respecto a la descarga de los mismos del SAT, queremos comentarte que nuestras soluciones ya están preparadas para este:

  • El Validador CFDI ya soporta la descarga de los recibos electrónicos del servidor del SAT
  • EDD, Librería que ofrece la posibilidad de descargar estos documentos del SAT.

Si estas interesado en la validación de los recibos electrónicos, actualmente nos encontramos trabajando para ofrecer soporte a los mismo en la librería de validación (EDV) y en el software para validar los XML (Validador CFDI).

Recursos adicionales
Hemos recopilado una serie de documentos y videos donde se ofrecer más información acerca de este tema y los cuales te recomendamos leer:

Si tienes alguna duda con respecto a esta publicación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

EDD: Nueva versión de la librería para descargar comprobantes del SAT

Uno de nuestros objetivos en Facturando es ofrecer productos de alta calidad y que satisfagan las necesidades de los usuarios, parte de este objetivo incluye el dar mantenimiento constante a cada una de las opciones que ofrecemos y esto es justamente lo que traemos hoy, una nueva versión de nuestra librería para descargar los XML del SAT: Electronic Document Download

Recibo de pago 1.0
En version anteriores, la librería ya ofrecía soporte a este nuevo “tipo de documento”, los proceso que lo soportan son:

  • Consulta
  • Descarga
  • Filtrado

Aunque se podía descarga, el problema era con la generación del PDF, ya que se generaba como un CFDI 3.3 normal y no traía los datos propios de este complemento.

A partir de esta versión al descargar un recibo de pago, en el PDF se van a mostrar los datos del mismo, para lograr esto, lo que hicimos fue modificar el formato actual para el CFDI 3.3 (Cfdi33.repx) y controlar que se muestren o no los datos, esto trae una ventaja y es que no se requieren de más archivos para el funcionamiento de la librería.

Mejoras a la descarga de los XML recibidos
Otro cambio que también llevamos a cabo en esta versión esta relacionado con la descarga de los XML recibidos, ya que cuando se consultaba un mes y existían más de 500 comprobantes, no se descargaban todos si en ese mes, en un día posterior no se habían recibido comprobantes.

Este caso es algo muy particular y es muy difícil de que se presente, aun así, nos dimos a la tarea de hacer mejoras a la clase que busca los XML y a la que los descarga.

Es importante mencionar que el punto anteriormente comentado afecta tanto al proceso de consulta como al de descarga.

Como siempre, recomendamos a todos nuestros usuarios actualizarse a esta versión.

Estos son tan solo algunos de los cambios que hemos realizado, si deseas conocer todo el detalle, te invitamos a revisar el historial de cambios.

Para tener acceso a los cambios ofrecidos en esta versión, deberás de llevar a cabo la actualización de la misma dando clic en la siguiente liga:

DESCARGAR

Si tienes alguna duda con respecto a esta liberación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Cambios al recibo de pago 1.0

Durante el mes de mayo el Sistema de Administración Tributaria (SAT) ha liberado nuevos cambios para la emisión el complemento recepción de pago, mejor conocido como recibo de pago.

En Facturando siempre nos preocupa que estés al tanto de los cambios que realiza la autoridad, es por eso que hemos descargado y analizado la documentación y he aquí los cambios que hemos detectado:

Estructura
El primer cambio y talvez el más notorio está relacionado con la estructura del mismo, en esta ocasión, la autoridad no ha agregado nodos ni atributos, lo que ha hecho es dar claridad sobre la definición de algunos atributos:

  • Se ha definido una expresión regular para los siguientes atributos: Serie, Folio, NumOperacion, RfcEmisorCtaOrd, NomBancoOrdExt, CtaOrdenante, CtaBeneficiario, CadPago
  • Se ha modificado la definición de los siguientes atributos: MonedaDR, NumParcialidad, ImpSaldoAnt, ImpSaldoInsoluto, TasaOCuota

Cadena original
El SAT también ha cambiado la forma como se calcula la cadena original, modificando el orden en que se agregan los totales de los impuestos a la cadena.

Matriz de errores
Este archivo es nuevo, fue agregado durante el mes de mayo y es de gran importancia para el proceso de generación y validación, ya que contiene cada una de las reglas que debe verificar el PAC antes de poder timbrar un recibo de nómina, en esencia si el recibo de pago cumple con estas reglas es válido

Catálogos para del recibo de pago
En este caso el cambio ha sido algo menor, solamente se ha cambiado en el nombre una letra en mayúscula por la misma en minúscula.

Kit de documentación
Como podrás notar, el SAT continúa afinando el recibo de pago 1.0 y aunque es bueno ya que le da mayor seguridad, esto genera un problema y es mantenerte actualizado con todos los cambios, es por eso que hemos decidido crear un Kit de documentación, el cual contiene los últimos cambios realizados y nuestro compromiso es siempre mantenerlo actualizado.

Dentro del kit podrás encontrar la siguiente documentación:

  • Estándar
  • Secuencia de la cadena original
  • Catálogos
  • Matriz de errores
  • Guía de llenado

Kit de Documentación Recibo de pago 1.0

Productos
Actualmente nuestro equipo de desarrollo se encuentra trabajando en aplicar todos estos cambios a cada uno de los productos, por lo que en próximos días estaremos liberando las nuevas versiones, te invitamos estar atento a nuestro foro y blog.

Si tienes alguna duda con respecto a este tema, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

CFDI 3.3 en Delphi

Hoy traemos para ti, la nueva versión de la librería en Delphi, para generar facturas electrónicas, en esta ocasión la hemos adaptado a los requerimientos solicitados por el SAT para generar:

A continuación, encontrarás la descripción de los cambios más importantes realizados en esta liberación.

CFDI versión 3.3
Ahora podrás generar esta nueva versión del comprobante fiscal digital cumpliendo con todos los requerimientos exigidos por el SAT:

  • Nuevos campos: Se han agregado los nuevos atributos y nodos requeridos.
  • Cadena original: Se ha modificado el cálculo de la cadena original, dando cumplimiento a la especificación dada por el SAT.
  • Validación contra schema: Se agregó el schema del CFDI 3.3, para cuando se genere el mismo, se valide si cumple con la estructura, catálogos y reglas dadas por el SAT.
  • Sellado: Hemos actualizado nuestro proceso de sellado dando soporte al nuevo algoritmo de digestión (SHA2) exigido por la autoridad.
  • Validación: El proceso de leer y validar un CFDI ha sido modificado para dar soporte a esta nueva versión.

Adicionalmente, hemos desarrollado un ejemplo el cual muestra, de forma detallada, como generar esta nueva versión del CFDI, y también hemos modificado el ejemplo de validación, para dar soporte a esta versión.

Código de barras bidimensional
En este caso hemos adaptado la librería para dar soporte al CBB 1.1 cumpliendo con los lineamientos solicitados por la autoridad;

Si deseas ver cómo se implementó este cambio, te invitamos a revisar el ejemplo que trae la librería al respecto.

Timbre 1.1
Adicional a los cambios anteriormente comentados, el SAT también modificó este complemento, creando una nueva versión; lo que hicimos fue dar soporte a este cambio agregando los nuevos atributos.

Recibos de pago
Este es otro de los cambios realizados por el SAT y es el manejo de los pagos a un CFDI, en este caso hemos agregado soporte a dicho complemento; hemos desarrollado un ejemplo donde se muestra como generarlo.

Es importante mencionar que la librería tiene la capacidad de generar y leer este tipo de complementos.

Licencia
Hemos aprovechado esta versión para realizar mejoras a la protección de la librería, este cambio trae consigo beneficios importantes como son:

  • Menor tiempo al cargar las clases y objetos contenidos dentro de la misma.
  • Corrección de errores en sistemas operativos antiguos.

El único inconveniente en este caso es que tu licencia actual no funcionará con esta versión, por lo que, deberás solicitar una nueva, para esto puedes enviarnos un correo a soporte y con gusto te la enviaremos sin costo adicional.

Esto son solo algunos de los cambios realizados, la realidad es que hemos hecho mejoras en otros procesos (adendas, complementos) y te invitamos a leer de los mismos en el historial de cambios.

Recomendación
Como podrás observar han sido muchos los cambios realizados en esta liberación y aunque, como empresa, hemos trabajado arduamente para que el producto no presente ningún problema, si queremos resaltar algunos puntos:

  • La librería es compatible con versiones anteriores, por lo tanto, deberá funcionar con tu código actual sin problemas.
  • Deberías realizar pruebas con tu código actual antes de implementarla en producción.

Como punto final, queremos recomendarte iniciar a la brevedad con el proceso de cambio a la 3.3 (análisis, implicaciones, etc.), ya que este conlleva un alto grado de dificultad, como sucedió con Nómina 1.2 y puede hacer que no tengas tu solución lista para el 1 de julio.

DESCARGAR

Si tienes alguna duda con respecto a esta liberación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

EDP: Librería para generar el PDF del recibo de nómina 1.2

Hoy, hemos liberado una nueva versión de nuestra librería para generar la representación impresa (PDF) de las facturas electrónicas, recibos de nómina, etc; en esta hemos realizado mejoras importantes, como son:

Soporte a recibo de nómina 1.2
Como recordaras, en las versiones anteriores ofrecíamos soporte a la versión 1.1 del recibo de nómina, ahora, hemos desarrollado un nuevo formato con el que podrás generar el PDF de la nueva versión (1.2) del recibo de nómina.

Este formato ha sido optimizado para que ocupe la mejor cantidad de espacio y también contiene los datos mínimos; como siempre, si deseas modificarlo y adaptarlo a tus requerimientos puedes hacerlo a través de nuestro editor de formatos.

PDFs más pequeños
Uno de los puntos que siempre solicitan nuestros usuarios es poder generar el PDF del menor tamaño posible y aunque actualmente generamos un archivo relativamente pequeño, estuvimos realizando cambios internos en la librería y hemos logrado resultados realmente sorprendentes, llegando a reducir el tamaño del archivo hasta en un 72 %, eh aquí los números:

  • Versión 2017.01.17 – Tamaño del PDF: 99 K
  • Versión 2017.04.20 – Tamaño del PDF: 28 K

Los anterior son valores promedios y podrían variar de acuerdo a la complejidad del PDF, en este caso se usaron los formatos que trae por defecto la librería.

Protección del PDF
Este era otro requerimiento que también solicitaron algunos usuarios y era tener la capacidad de proteger el PDF generado por la librería, por lo que nos dimos a la tarea de dotar a la librería con esta funcionalidad, por lo que a partir de esta versión podrás proteger un PDF:

  • Que al abrirlo solicite password para poder visualizar su contenido.
  • Que no pueda ser copiado su contenido al portapapeles.
  • Que no pueda ser modificado, esto es, agregar comentarios, firmas, etc.

Puedes revisar el ejemplo que trae la librería para que puedas ver cómo implementar estas características.

PDF personalizado
Con esta nueva funcionalidad podrás personalizar las propiedades del PDF generado, esto, mediante el uso de las siguientes propiedades:

  • Título (Title)
  • Asunto (Subject)
  • Creador (Creator)
  • Palabras claves (Keywords)

Con el uso de estas opciones podrás personalizar las propiedades del PDF de un CFDI, si no se hacen uso de estas, los valores por defecto de las propiedades serán asignados por la librería dependiendo del tipo de comprobante.

Mejoras menores
Como siempre, en cada nueva versión llevamos a cabo cambios menores que ayudan a mejorar el producto, he aquí algunos de ellos:

  • Se disminuyó el tiempo que toma la librería en inicializarse.
  • Se actualizó el documento de errores.
  • Se modificaron los formatos de impresión.

Vigencia de la librería
Para beneficio de nuestros usuarios y clientes hemos ampliado la fecha de vigencia de la librería al 01 de julio de 2017, por lo recomendamos actualizarse a la brevedad.

Como nota final queremos comentar que esta versión no es compatible con el código actual, por lo que antes de integrarla a producción deberás hacer cambios a tu sistema.

Si deseas conocer a cerca de estos y otros cambios, podrás hacerlo consultando el historial de cambios.

DESCARGAR

Si tienes alguna duda con respecto a esta liberación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

Librería EDL CSharp: CFDI 3.3

Como sabrás, el SAT liberó la especificación técnica para la nueva versión del CFDI; además liberó nuevas especificaciones para el resto de estándares relacionados al mismo como son: el código de barras bidimensional, el complemento timbre, etc.; si deseas conocer a detalle todos los cambios realizados te invitamos leer los siguientes artículos:

Debido a lo anterior, nos dimos a la tarea de actualizar nuestra librería para generar facturas electrónicas, dando soporte a todos los cambios anteriormente comentados y también agregando características que nos ha solicitado algunos usuarios.

Esta ha sido la liberación más compleja que hemos realizado desde que se desarrolló la primera versión y esto debido a los cambios realizados por el SAT y porque hemos logrado que la librería pueda trabajar en desarrollos multi-thread, hablaremos de este tema más adelante, por el momento vamos a describir los cambios más importantes de esta nueva versión:

CFDI 3.3
Con esta nueva versión, podrás generar tus comprobantes 3.3 cumpliendo con todos los requisitos exigidos por el SAT, internamente hemos modificados todos los procesos relacionados con esta versión:

  • Nuevos campos: Se han agregado los nuevos atributos y nodos requeridos.
  • Cadena original: Se ha modificado el cálculo de la cadena original, dando cumplimiento a la especificación dada por el SAT.
  • Validación contra schema: Se agregó el schema del CFDI 3.3, para cuando se genere el mismo, se valide si cumple con la estructura, catálogos y reglas dadas por el SAT.
  • Sellado: Hemos actualizado nuestro proceso de sellado dando soporte al nuevo algoritmo de digestión (SHA2) exigido por la autoridad.
  • Validación: El proceso de leer y validar un CFDI ha sido modificado para dar soporte a esta nueva versión.

Hemos agregado un ejemplo (C# y VB.Net) donde se muestra como generar un XML con esta nueva versión y también hemos actualizado el ejemplo de validación donde se muestra como leer un CFDI 3.3

Complemento Recibo de pago
Este es otro de los cambios realizados por el SAT y es el manejo de los pagos a un CFDI, en este caso hemos agregado soporte a dicho complemento, si deseas como hacer uso del mismo te invitamos a revisar el ejemplo “COMPLEMENTOS”.

Código de barras bidimensional
En este caso hemos realizado dos cambios importantes, el primero de ellos es dar soporte al CBB 1.1 cumpliendo con los lineamientos solicitados por la autoridad.; el segundo es la forma en que se genera el mismo, anteriormente se usaba una clase estática para esta tarea, a partir de esta versión es necesario instanciar una clase.
En el ejemplo que trae la librería podrás ver reflejados estos dos cambios.

Timbre 1.1
El complemento timbre ya existe desde hace tiempo en el CFDI, lo que hizo la autoridad fue hacerle una mejora agregando más atributos, y eso, es lo que hemos realizado en esta liberación, dar soporte a estos nuevos campos.

Es importante mencionar que nuestros PACs asociados, aún no pueden timbrar usando dicho complemento, pero esperamos que en el transcurso de mayo ya pueda ser usado dicho completo.

Multi Thread
Debido a la complejidad de este tema hemos decidido crear un artículo independiente donde explicaremos todo lo relacionado a esta característica, te recomendamos leerlo.

DLL de recursos
Aunque este cambio es menor, quisimos resaltarlo ya que no tenerlo en cuanta podrías hacer que no funcione tú código actual.

Debido a que el SAT está cambiando constantemente sus schema y que los mismo están teniendo un crecimiento, en tamaño, muy fuerte, hemos decidido dividir la librería en dos partes:

  • HyperSoft.ElectronicDocumentLibrary.dll, este Assembly (DLL) con tiene toda la lógica de la librería (generación, validación, etc.).
  • HyperSoft.Resource.dll, como su nombre lo indica es DLL que contiene solamente los recursos (schemas) requeridos para el funcionamiento de la librería.

A partir de esta versión es necesario que agregues este segundo archivo (HyperSoft.Resource.dll) a tu proyecto para que tu solución pueda trabajar y si vas a reemplazar la librería en un proyecto que ya tienes compilado, entonces copia este a la carpeta donde está la librería.

Algo importante a comentar es que este cambio ha hecho que disminuya el tiempo de inicialización de la librería, así como el consumo de memoria de la misma.

Esto son solo algunos de los cambios realizados, la realidad es que hemos hecho mejoras en otros procesos (adendas, complementos) y te invitamos a leer de los mismos en el historial de cambios.

Recomendación
Como podrás observar han sido muchos los cambios realizados en esta liberación y aunque, como empresa, hemos trabajado arduamente para que el producto no presente ningún problema, si queremos resaltar algunos puntos:

  • La librería es compatible con versiones anteriores, por lo tanto, deberá funcionar con tu código actual sin problemas.
  • Deberías realizar pruebas con tu código actual antes de implementarla en producción.
  • Sería bueno que empezaras a hacer uso de la nueva forma de instancias e inicializar los objetos, para mayor información, por favor, revisa el articulo Multi-Thread.

Como punto final, queremos recomendarte iniciar a la brevedad con el proceso de cambio a la 3.3 (análisis, implicaciones, etc.), ya que este conlleva un alto grado de dificultad, como sucedió con Nómina 1.2 y puede hacer que no tengas tu solución lista para el 1 de julio.

DESCARGAR

Si tienes alguna duda con respecto a esta liberación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

Complemento de pago 1.0 – Guía de llenado

Continuando con el tema del complemento para la recepción de pagos que deberá de adicionarse al Comprobante Fiscal Digital por Internet (CFDI) cuando las contraprestaciones no se paguen en una sola exhibición, es decir cuando el pago se realice en parcialidades, se deberá de:

  1. Emitir un CFDI por el valor total de la operación en el momento en que ésta se realice.
  2. Posteriormente, se emitirá un CFDI por cada uno de los pagos que se realicen, donde deberá de señalar:
    • En el campo Total como cero.
    • En lo correspondiente al método de pago y forma de pago, no se deberá registrar dato alguno.
    • Detallar la cantidad que se paga e identificar la factura cuyo saldo liquida, esto mediante la incorporación del complemento para recepción de pagos.
    • El monto del pago se aplicará proporcionalmente a los conceptos integrados en el comprobante emitido por el valor total de la operación.

Para el caso en que se reciba el pago de la contraprestación en una sola exhibición, pero ésta no sea cubierta en el momento de la expedición del CFDI, o cuando se trate de operaciones a crédito y estas se paguen en fecha posterior a la emisión del CFDI, se deberá de llevar a cabo el mismo procedimiento descrito en el punto 2, para efecto de reflejar el pago con el cual se liquide el importe de la operación.

Adicional, deberán de tenerse las siguientes consideraciones:

  • Un CFDI que contenga el complemento para recepción de pago, podrá emitirse a más tardar al décimo día del mes siguiente en el que se realizó el pago.
  • No podrá ser cancelado el CFDI que fue emitido por el total de la operación, siempre y cuando, se cuente con al menos un CFDI con complemento para recepción de pagos, que acredite que la contraprestación haya sido total o parcialmente pagada.
  • Con relación al punto anterior, las correcciones podrán realizarse mediante la emisión de CFDI de egresos por devoluciones, descuentos y bonificaciones.
  • Cuando existan errores en un CFDI que contenga el complemento para recepción de pagos, éste podrá ser cancelado siempre que sea sustituido por otro con los datos correctos, siempre y cuando se realice a más tardar el último día del ejercicio en que fue emitido el CFDI.

A continuación, se describe como debe ser el llenado de los datos de un CFDI versión 3.3 y su complemento, cuando éste es emitido para llevar a cabo el pago en parcialidades:

Comprobante versión 3.3

Nodo Comprobante:

  • Version – debe contener el valor “3.3”.
  • Serie – número de serie que utiliza el contribuyente para control interno.
  • Folio – folio de control interno que asigna el contribuyente al CFDI.
  • Fecha – fecha y hora de expedición del CFDI.
  • Sello – sello digital del CFDI generado con el CSD del contribuyente emisor del mismo.
  • FormaPago – no debe existir.
  • NoCertificado – número que identifica al CSD del emisor del CFDI.
  • Certificado – contiene el CSD del emisor del CFDI.
  • CondicionesDePago – no debe existir.
  • SubTotal – se registra el valor de cero “0”.
  • Descuento – no debe existir.
  • Moneda – se registra el valor “XXX”.
  • TipoCambio – no debe existir.
  • Total – se registra el valor de cero “0”.
  • TipoDeComprobante – se registra la clave “P” (Pago).
  • MetodoPago – no debe existir.
  • LugarExpedicion – se registra el código postal del lugar de expedición del CFDI.
  • Confirmación – clave de confirmación única e irrepetible que entrega el PAC cuando el valor equivalente en MXN del campo Monto excede el límite publicado por el SAT.

Nodo CfdiRelacionados:

  • UUID – folio fiscal de un CFDI con complemento para recepción de pagos relacionado que se sustituye con el presente comprobante.

Nodo Emisor:

  • Rfc – clave del RFC del emisor del CFDI.
  • Nombre – nombre, denominación o razón social del emisor del CFDI.
  • RegimenFiscal – clave del régimen fiscal del contribuyente bajo el cual se está emitiendo el CFDI. Persona Moral: 601 – General de Ley Personas Morales, 603 – Personas Morales con Fines no Lucrativos. Persona Física: 605 – Sueldos y Salarios e Ingresos Asimilados a Salarios.

Nodo Receptor:

  • Rfc – clave del RFC receptor del CFDI.
  • Nombre – nombre, denominación o razón social del contribuyente receptor del CFDI.
  • ResidenciaFiscal – clave del país de residencia, cuando el receptor del CFDI sea un extranjero, para efectos fiscales.
  • NumRegidTrib – número de registro de identidad fiscal del receptor del CFDI, cuando este sea residente en el extranjero.
  • UsoCFDI – clave que corresponda al uso que le dará al CFDI el receptor. Persona Moral y Física: G01 – Adquisición de mercancías, I01 – Construcciones. Solo Persona Física: D01 – Honorarios médicos, dentales y gastos hospitalarios.

Nodo Conceptos / Concepto:

  • ClaveProdServ – se registrar el valor “84111506”.
  • NoIdentificacion – no debe existir.
  • Cantidad – se registra el valor “1”.
  • ClaveUnidad – se registra el valor “ACT”.
  • Unidad – no debe de existir.
  • Descripcion – se registra el valor “Pago”.
  • ValorUnitario – se registra el valor “0”.
  • Importe – se registra el valor “0”.
  • Descuento – no debe existir.

Subnodo Impuestos, InformacionAduanera, CuentaPredial, ComplementoConcepto y Parte:

  • No deben existir.

Nodo Impuestos:

  • No debe existir.

Nodo Complemento:

  • Nodo para incluir los complementos determinados por el SAT, el complemento Timbre Fiscal Digital se incluye de forma obligatoria. Para el caso de los complementos del CFDI que ampara retenciones e información de pagos, éstos no se permiten.

Nodo Addenda:

  • Nodo para expresar las extensiones al presente formato que sean de utilidad al contribuyente.

Complemento para recepción de pagos

Nodo Pagos:

  • Version – debe contener el valor “1.0”.

Nodo Pago:

  • FechaPago – fecha y hora en la que el beneficiario recibe el pago, la fecha debe ser menor o igual al campo Fecha del CFDI. Si la FechaPago es menor, el valor año-mes debe ser igual al valor de año-mes de CFDI:Fecha.
  • FormaDePagoP – clave de la forma en que se realiza el pago, distinta a la clave 99 – Por definir. Claves: 01 – Efectivo, 02 Cheque nominativo, 03 – Transferencia electrónica de fondos.
  • MonedaP – clave de la moneda con la que se realizó el pago, los siguientes campos deben ser registrados junto con el tipo de moneda seleccionada: Pagos/Pago/Monto, Impuestos/Total de impuestos retenidos, Impuestos/Total de impuestos trasladados, Impuestos/Trasladados/Traslado/Importe e Impuestos/Retenciones/Retención/Importe.
  • TipoCambioP – tipo de cambio de la moneda a la fecha en que se realizó el pago, cuando sea diferente a MXN.
  • Monto – importe del pago, debe ser mayor a cero “0”, este campo debe ser igual o menor a la suma de los valores registrados en el nodo DoctoRelacionado.
  • NumOperacion – número de cheque, número de autorización, número de referencia, clave de rastreo en caso de ser SPEI, línea de captura o algún número de referencia análogo que identifique la operación correspondiente del pago efectuado.
  • RfcEmisorCtaOrd – RFC de la entidad emisora de la cuenta de origen, si es extranjera se debe registrar el RFC genérico extranjero (XEXX010101000), para el caso de que no lo sea, se debe registrar el RFC a 12 posiciones.
  • NomBancoOrdExt – nombre del banco ordenante, es requerido en caso de ser extranjero, va de 1 hasta 300 caracteres.
    CtaOrdenante – número de cuenta con la que se hizo el pago, va de 10 a 50 caracteres.
  • RfcEmisorCtaBen – clave del RFC de la entidad operadora de la cuenta destino.
  • CtaBeneficiario – número de cuenta en donde se recibió el pago, va de 10 hasta 50 caracteres.
  • TipoCadPago – clave del tipo de cadena de pago que genera la entidad receptora del pago (01 – SPEI), si existe este campo, deben de existir también, CertificadoPago, CadenaPago y SelloPago.
  • CertPago – certificado que corresponde al pago, como una cadena de texto en formato base 64. Requerido si TipoCadPago contiene información.
  • CadenaPago – cadena original del comprobante de pago generado por la entidad emisora de la cuenta beneficiaria. Requerido si TipoCadPago contiene información.
  • SelloPago – sello digital que se asocie al pago. Requerido si TipoCadPago contiene información.

Nodo DoctoRelacionado:

  • IdDocumento – identificador relacionado con el pago, puede ser un folio fiscal o el número de operación de un documento digital, puede conformarse de 16 hasta 36 caracteres.
  • Serie – serie del comprobante, va de 1 a 25 caracteres.
  • Folio – folio del comprobante, va de 1 a 40 caracteres.
  • MonedaDR – clave de la moneda utilizada en los importes del documento relacionado, debe ser diferente a la clave “XXX”, los importes registrados en los campos ImpSaldoAnt, ImpPago e ImpSaldoInsoluto de esta sección, deben corresponder a esta moneda. Si el valor de este campo es diferente del campo MonedaP, se debe de registrar el campo TipoCambioDR, en caso contrario, de ser iguales a “MXN”, no se debe registrar TipoCambioDR. Si el valor de este campo es “MXN” y diferente al campo MonedaP, se debe de registrar el campo TipoCambioDR con valor de “1”.
  • TipoCambioDR – tipo de cambio correspondiente a la moneda registrada en el documento relacionado. El SAT publica el porcentaje de variación para el valor máximo de este campo, cuando el campo rebase el porcentaje de variación, se deberá obtener del PAC, la clave de confirmación para ratificar que el valor es correcto.
  • MetodoDePagoDR – clave del método de pago “PPD” (Pago en parcialidades o diferido), se deben de registrar los atributos NumParcialidad, ImpSaldoAnt e ImpSaldoInsoluto.
  • NumParcialidad – número de parcialidad que corresponde al pago. Requerido si MetodoDePagoDR contiene el valor “PPD”.
  • ImpSaldoAnt – monto del saldo insoluto de la parcialidad anterior. Requerido si MetodoDePagoDR contiene el valor “PPD”. Si es la primera parcialidad deberá contener el importe total del documento relacionado.
  • ImpPagado – importe pagado que corresponde al documento relacionado. Requerido si existe más de un documento relacionado o cuando existe un documento y el campo TipoCambioDR tiene valor. El importe debe corresponder al tipo de moneda registrado en MonedaDR.
  • ImpSaldoInsoluto – diferencia entre el importe del saldo anterior y el monto del pago. Requerido si MetodoDePagoDR contiene “PPD”. El importe debe corresponder al tipo de moneda registrado en MonedaDR.

Nodo impuesto, TotalImpuestosRetenidos y TotalImpuestosTrasladados:

  • No deben existir.

Nodo Retenciones y Retención, Impuesto e Importe:

  • No deben existir.

 Nodo Traslados y Traslado, Impuesto, TipoFactor, TasaOCuota e Importe:

  • No deben existir.

Si deseas tener la información técnica de este complemento la puedes descargar de aquí:

Descargar Información

Si tienes alguna duda con respecto a este tema, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

Guía de llenado del CFDI 3.3 y retenciones e información de pagos

Continuando con los cambios previstos por el Servicio de Administración Tributaria (SAT) en cuanto a la nueva versión 3.3 del Comprobante Fiscal Digital por Internet (CFDI), el cual entra en vigor el 1 de julio de 2017.

A continuación, queremos compartir contigo el documento que describe de cómo se debe realizar el llenado de los datos a registrar para el CFDI en su versión 3.3, así como el llenado del CFDI que ampara retenciones e información de pagos.

Para el caso de surgir alguna duda o situación particular que no se encuentre resulta en el documento compartido, te invitamos a revisar los siguientes documentos:

  • Documentación técnica.
  • Preguntas y respuestas de los comprobantes fiscales digitales por internet (CFDI).
  • Preguntas y respuestas del comprobante fiscal digital a través de internet que ampara retenciones e información de pagos.
  • Casos de uso de los comprobantes fiscales digitales por internet.
  • Casos de uso del comprobante fiscal digital a través de internet que ampara retenciones e información de pagos.

Recuerda que el documento incluye ejemplos de carácter didáctico y hace uso de información no necesariamente real.

Para obtener el documento de esta guía, la puedes descargar dando clic a la siguiente liga:

Descargar guía

Si tienes alguna duda con respecto a este tema, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.

Librería para descarga de CFDIs con complemento Nómina 1.2 e INE

En esta ocasión queremos compartir contigo la liberación de Electronic Document Download (EDD) con número de control 2017.02.21 para sus distintas versiones (Dot Net, Delphi, DLL y Línea de comandos) donde fueron realizados los siguientes cambios:

Descarga de XMLs
Como es bien sabido, en días pasados, el Sistema de Administración Tributaria (SAT) realizó cambios a su servicio web de descarga, al adicionar como parte de la autenticación, el uso de un Captcha, cambio que tuvo como consecuencia que nuestras distintas soluciones de descarga dejaran de funcionar temporalmente.

En base a lo anterior, nuestra área de desarrollo se dio a la tarea de darle solución lo antes posible para solventar dicho cambio, por lo que nos es grato el poder informarte que dicha situación fue superada, logrando con ello que nuestras soluciones vuelvan a trabajar como lo venían haciendo, es decir, de forma transparente para el usuario.

Complementos
Dentro de la librería de descarga de CFDIs, se agregó soporte para poder llevar a cabo la descarga de aquellos comprobantes que contengan los complementos que a continuación se mencionan, por medio del filtrado de los mismos:

  • Nómina 1.2
  • INE 1.1

Tiempo de espera
En lo que respecta al tiempo de espera en cada operación (time out), este fue modificando, quedando establecido en 20 segundos, dicha reducción se debe a la optimización realizada en el proceso de descarga.

Proveedores Autorizados de Certificación (PACs)
Para efecto de tener actualizada toda la información de los proveedores actualizados (PAC) se actualizó la información correspondiente, incluyendo el siguiente PAC:

  • Denominación o razón social: IT & SW Development Solutions de México, S. de R.L. de C.V.
  • Nombre comercial: Timbox
  • RFC: IAD121214B34
  • Fecha de publicación: 2016-09-02 12:00:00
  • Número de autorización SAT: 0184
  • CSD para timbrado: 00001000000403442064

Para conocer los cambios realizados a la librería te invitamos a leer el historial de cambios correspondiente a cada versión.

No olvides actualizar la versión de tu librería, para que continúes disfrutando de toda la funcionalidad que la misma te ofrece, dando clic a la siguiente liga:

DESCARGAR

Si tienes alguna duda con respecto a esta liberación, te invitamos a que nos contactes por medio del foro que aparece en nuestra página www.facturando.mx donde con gusto un asesor te atenderá.

Hasta la próxima.