¿Cómo crear un archivo pfx en c#? cancelación de factura electrónica SAT cfdi 3.3

Para cancelar una factura electrónica es necesario crear un tercer certificado llamado pfx, este certificado se debe crear por medio de Openssl en conjunto de nuestro archivo Cer y nuestro archivo Key los cuales debemos ya tener si es que estamos timbrando.

Para crear el archivo pfx utilizaremos la clase Process de .Net, esta clase sirve para mandar comandos como si estuviéramos en consola, de esta manera utilizaremos los comandos de Openssl.

Les recuerdo que antes deben instalar Openssl y como está en el siguiente ejemplo debe estar instalado en la unidad c:/openssl-win32.

En caso que se tenga Openssl instalado en otra ruta distinta, solo modifiquen esa parte del código. A continuación la clase mágica:

 public class PFX
    {
        string cer = "";
        string key = "";
        string clavePrivada = "";
        string ArchivoPFX = "";
        string ArchivoKPEM = "";
        string ArchivoCPEM = "";

        public string error = "";
        public string mensajeExito = "";

        ///
<summary>
        ///
        /// </summary>

        /// <param name="cer_">archivo cer a utilizar</param>
        /// <param name="key_">archivo key a utilizar</param>
        /// <param name="clavePrivada_">clave para el archivo pfx</param>
        /// <param name="archivoPfx_">ruta del archivo pfx</param>
        /// <param name="path">ruta para archivos temporales PEM</param>
        public PFX(string cer_, string key_, string clavePrivada_, string archivoPfx_, string pathTemp)
        {
            cer = cer_;
            key = key_;
            clavePrivada = clavePrivada_;

            ArchivoKPEM = pathTemp + "k.pem";
            ArchivoCPEM = pathTemp + "c.pem";
            ArchivoPFX = archivoPfx_;
        }

        public bool creaPFX()
        {
            bool exito = false;

            //validaciones
            if (!File.Exists(cer))
            {
                error = "No existe el archivo cer en el sistema";
                return false;
            }
            if (!File.Exists(key))
            {
                error = "No existe el archivo key en el sistema";
                return false;
            }
            if (clavePrivada.Trim().Equals(""))
            {
                error = "No existe una clave privada aun en el sistema";
                return false;
            }

            //creamos objetos Process
            System.Diagnostics.Process proc = new System.Diagnostics.Process();
            System.Diagnostics.Process proc2 = new System.Diagnostics.Process();
            System.Diagnostics.Process proc3 = new System.Diagnostics.Process();
            proc.EnableRaisingEvents = false;
            proc2.EnableRaisingEvents = false;
            proc3.EnableRaisingEvents = false;

            //openssl x509 -inform DER -in certificado.cer -out certificado.pem
            proc.StartInfo.FileName = "openssl";
            proc.StartInfo.Arguments = "x509 -inform DER -in \"" + cer + "\" -out \"" + ArchivoCPEM + "\"";
            proc.StartInfo.WorkingDirectory = @"C:\openssl-win32\bin\";
            proc.Start();
            proc.WaitForExit();

            //openssl pkcs8 -inform DER -in llave.key -passin pass:a0123456789 -out llave.pem
            proc2.StartInfo.FileName = "openssl";
            proc2.StartInfo.Arguments = "pkcs8 -inform DER -in \"" + key + "\" -passin pass:" + clavePrivada + " -out \"" + ArchivoKPEM + "\"";
            proc2.StartInfo.WorkingDirectory = @"C:\openssl-win32\bin\";
            proc2.Start();
            proc2.WaitForExit();

            //openssl pkcs12 -export -out archivopfx.pfx -inkey llave.pem -in certificado.pem -passout pass:clavedesalida
            proc3.StartInfo.FileName = "openssl";
            proc3.StartInfo.Arguments = "pkcs12 -export -out \"" + ArchivoPFX + "\" -inkey \"" + ArchivoKPEM + "\" -in \"" + ArchivoCPEM + "\" -passout pass:" + clavePrivada;
            proc3.StartInfo.WorkingDirectory = @"C:\openssl-win32\bin\";
            proc3.Start();
            proc3.WaitForExit();

            proc.Dispose();
            proc2.Dispose();
            proc3.Dispose();

            //enviamos mensaje exitoso
            if (System.IO.File.Exists(ArchivoPFX))
                mensajeExito = "Se ha creado el archivo PFX ";
            else
            {
                error = "Error al crear el archivo PFX, puede ser que el cer o el key no sean archivos con formato correcto";
                return false;
            }

            //eliminamos los archivos pem
            if (System.IO.File.Exists(ArchivoCPEM)) System.IO.File.Delete(ArchivoCPEM);
            if (System.IO.File.Exists(ArchivoKPEM)) System.IO.File.Delete(ArchivoKPEM);

            exito = true;

            return exito;
        }
    }

Para utilizarla de la siguiente manera:


//yo siempre utilizo la misma clave privada de mi timbrado para encriptar el pfx
//la ruta para archivos temporales solo se utiliza para archivos que serán eliminados al final
oPFX = new PFX("algunaruta/archivocer.cer", "algunaruta/archivokey.key", "algunpassword", "algunacarpeta/miarchivo.pfx", "rutaparacreararchivostemporalesPem/");

if (oPFX.creaPFX())
                    Console.WriteLine("Archivo creado con éxito");
else
                    Console.WriteLine(oPFX.error);

SAT, cfdi 3.3, facturación electrónica, la opinión de un desarrollador de software PARTE I – Adaptación

Esta entrada fue impresa en el número publicado en Marzo 2018 de la revista Talento Empresarial.

Mi experiencia con facturación electrónica viene desde el desarrollo de la plataforma www.facturacenter.com.mx, posterior a ese desarrollo he hecho miles más que van desde servicios web, consultoría a empresas y algunos municipios del país, y lo último la migración de cfdi 3.2 a 3.3 de algunos sistemas.
Tratare de dar mi punto de vista como desarrollador de software, no soy experto en contabilidad ni temas fiscales, yo solo soy un desarrollador de software por lo cual puedo desconocer algunos temas a la perfección. En esta entrada me enfocare en la adaptación de los usuarios a este mecanismo.

¿Por qué facturación electrónica?

Entiendo las ventajas que significan para SAT que los contribuyentes emitan facturas electrónicas, ya que esto da mayor control a todo movimiento que hacen las pequeñas y grandes empresas, y poco a poco quitando el trabajo de los contadores de calculadora, y todo electrónico sin gastar papel, ni renovar los folios y todo el engorro que se hacía hace años. Lo malo del asunto es haber optado por sacar una versión 3.2 con tanta deficiencia la cual quieren tapar con la nueva versión 3.3 (la cual creo que complica todo al contribuyente, ahorita vamos para allá). No sé a quién consulto SAT para realizar la facturación electrónica en cuanto a sus secciones y formatos, catálogos, atributos, complementos etc. Hay características buenas como todo, pero las deficiencias que tenía la versión 3.2 quisieron mejorarlas teniendo un mayor control en lo que captura el contribuyente, cambiándolo todo (o casi todo) a claves, esto asegurando que el emisor no captura discrepancias, todo suena perfecto y como programador lo aplaudo, pero esto debió ser parte de la versión 3.2 no de la 3.3. ¿Qué es lo que pasa ahora con todo el tema de la migración? Que todos los sistemas fueron hechos para la versión 3.2 una versión que fue perfeccionándose y si la comparamos con la versión 3.3 hace un caos en los sistemas y en los usuarios que utilizan dichos sistemas.

CFDI 3.2

Un usuario que estaba acostumbrado: 10,20 quizá 30 o más años a hacer sus facturas con papel se le obliga a realizar facturación electrónica, ya que no fue opcional sino obligatoria al final, esta persona nunca ha utilizado una computadora, meses después el usuario comienza a crear su factura, y de repente le toca un cliente al cual le obliga hacer una addenda, el usuario no tiene ni idea que es una addenda, lo peor aún, el sistema que utiliza el usuario no tiene dicha addenda(si porque cada receptor puede hacer su addenda), el usuario llama a su proveedor de software y le dicen que la addenda estará lista en unos días. Por fin llega el día y el usuario ve que para hacer una factura para ese cliente en particular (ya que si la factura está mal no recibe su pago) debe llenar más datos y cuando por fin logra hacer la factura, se encuentra con una nueva sorpresa, el cliente le dice que la factura debe subirse a una página web la cual validara la addenda, y al subirla el sitio del cliente le dice que su factura no es válida; la persona nuevamente llama a su proveedor de software y se vuelve un ciclo prueba y error hasta que resuelve una problemática que no tenía cuando solo utilizaba papel. Este es un pequeño ejemplo de la problemática que pasó un contribuyente al migrar de papel a facturación electrónica. ¿Sera verdad que con la facturación electrónica se beneficia el contribuyente? O ¿Quién se beneficia realmente? El contribuyente en lugar de beneficiarse ha gastado en un software caro y en más tiempo del que utilizaba para hacer algo que hacía en minutos.

CFDI 3.3

Después de 6 años cuando los contribuyentes por fin llevan una vida más o menos tranquila en cuestión de facturación (a veces falla el pac, se caducaron sus sellos), y sale la súper noticia de la migración a la nueva súper poderosa facturación electrónica 3.3 la cual contiene miles de mejoras, más organizada, lo mejor que le pudo pasar al contribuyente, y arrojan como 20 catálogos los cuales deben ser utilizados ahora en lugar de que el usuario capture lo que siempre capturaba. Ahora para capturar conceptos el SAT obliga a que capture el usuario el producto y una clave que proporciona el bondadoso SAT, y lo dicen como si el usuario solo buscara la clave entre más de 50 mil (un numero absurdo y más adelante veremos porque) y rápidamente le resolviera su vida pero aquí es por lo cual dije con anterioridad, estos catálogos debieron salir en la anterior versión, las personas ya utilizan sistemas donde tienen hasta miles de productos, los contribuyentes viven al día, y ahora para hacer una factura deben ir producto por producto buscando la clave más o menos adecuada (ya que hay ambigüedades) esto en el caso de los conceptos, ah pero si te equivocas el SAT te dará perdón unos meses porque los contribuyentes son unos pecadores por no saber cuál es la clave de sus conceptos. Ahora veamos lo absurdo de este famoso catalogo:

  • Clave 92111704 – Guerra de guerrillas
  • Clave 25151501 – Nave espacial tripulada
  • Clave 11131602 – Semen
  • Clave 92112100 – Guerra nuclear
  • Clave 92112207 – Guerra ambiental
  • Clave 92112403 – Guerra nuclear
  • Clave 92112404 – Guerra basada en el espacio
  • Clave 92111806 – Mercenarios

Estos son unos ejemplos, y es cuando me pregunto ¿En realidad eran necesarios más de 50 mil elementos? Además esto está lleno de huecos, hay bastantes ambigüedades, y otro problema es que ese catálogo debe seguir creciendo a la lógica del SAT, ya que habrá cada vez nuevos productos, creo que si querían absorber todo producto posible se metieron en un problema enorme. Se debió contemplar una categorización menor, no más de 1000 elementos, esto ayudaría bastante al usuario, pero yo casi estoy seguro que este catálogo tiende al fracaso. El simple hecho de evaluar si corresponde lo que capturo el cliente con la clave ya es algo engorroso, así que no dudo que el siguiente año se elimine o se reduzca este catálogo así como el de unidad que también es otra maravilla.

Hablar de facturación electrónica es un tema para más de una entrada, es por ello que me enfoque en la adaptación en estos años, en otras entradas hablare de los monopolios existentes, nomina electrónica, y también del famoso y paradójico complemento de pago.
La facturación electrónica también tiene sus puntos buenos y puede mejorar la forma en como está organizada, lástima que SAT teniendo recaudaciones enormes (2015: 300 mil millones de pesos) no invierta ni el 1% de eso para su departamento de sistemas (siguen utilizando applets, yo amo java, no las applets).
Nos vemos en siguientes entradas.

SAT, cfdi 3.3, facturación electrónica, la opinión de un desarrollador de software PARTE II – Beneficio.

¿Cómo obtener el #UUID (Timbre fiscal) de un xml timbrado en c#? #facturacion

Para obtener el UUID de un xml que ya tengamos timbrado del SAT lo podemos hacer con LINQ muy sencillo como muestro a continuación:

            //sustituir por la ruta de tu xml
            string rutaXML="C:/carpeta1/carpeta2/factura.xml";

            //variables del esquema
            XNamespace cfdi = @"http://www.sat.gob.mx/cfd/3";
            XNamespace tfd = @"http://www.sat.gob.mx/TimbreFiscalDigital";

            //cargamos el xml
            var xdoc = XDocument.Load(rutaXML);

            //Navegamos hasta el elemento que contiene el UUID
            var elt = xdoc.Element(cfdi + "Comprobante")
                          .Element(cfdi + "Complemento")
                          .Element(tfd + "TimbreFiscalDigital");

            //listo obtenemos el UUID
            var uuid = (string)elt.Attribute("UUID");