En este video te mostrare como agregar uno o varios documentos relacionados a tu complemento de pago.
Etiqueta: hacienda
No depender de internet para obtener cadena original cfdi 3.3 facturación electrónica C# .Net #7
En este video, te enseñare como no depender de las rutas que nos da el SAT para generar la cadena original, e incluyo todos los archivos necesarios xslt abajo para que los puedas descargar.
Archivos xslt: descargar
Curso para crear sistema para facturación electrónica web gratis en C# .Net
En estos videos programados en vivo, te enseñare como hacer un sistema web que te sirva para la facturación electrónica, para que puedas generar tus facturas desde una interfaz amigable para el usuario.
El código fuente se encuentra al final de esta entrada; si quieres recibir un sistema con más elementos que este gratuito, puedes apoyarme vía patreon desde 1 USD al mes:
https://www.patreon.com/powerhdeleon
Puedes ver más videos gratis en mi canal de youtube: canal de hdeleon.net
1. Creación del proyecto en MVC .Net, y acceso de usuario
2. Librería para creación y sellado de xml 3.3 y catálogos del SAT en mysql
3. Creación de tablas en base de datos mysql para facturación
4. View Model para creación de factura
5. Seguridad y Vista para crear factura
6. Crear autocompletar de claves del SAT
7. Crear SelectList de catálogos del SAT – Parte 1
7. Crear SelectList de catálogos del SAT – Parte 2
8. Conceptos dinámicos
9. Crear objeto comprobante
10. Código para sellar el XML
11. Creación del archivo XML
12. Sellado de archivo XML
13.- Creación de capa de timbrado
14.- Timbrado de factura
Recuerda que la publicidad es para una buena causa, apoyar perros que están en la calle.
Curso complemento para recepción de pagos en C# .Net, Introducción, estructura, SAT cfdi 3.3, #1
En este video explico los aspectos básicos para que entiendas el esquema del complemento de pago, para que sirve, y como debe ser incorporado.
Este curso esta hecho para que puedas crear el xml cfdi 3.3 con el complemento de pago en C# .Net.
¿Cómo crear el archivo pdf a partir de un xml timbrado 3.3 C# .Net?, Impuestos, SAT #5
En este quinto video te muestro como obtener los impuestos del xml para imprimirlos en el archivo pdf
Primer video: https://www.youtube.com/watch?v=gHSC8GrEC5g
Segundo video: https://www.youtube.com/watch?v=ZppyFAM2JQM
Tercer video: https://www.youtube.com/watch?v=2l9y_dbguaQ
Cuarto video: https://www.youtube.com/watch?v=0nmqpoCTUuM
Código del video: aquí
¿Cómo pasar un archivo XML de factura electrónica 3.3 timbrado a una clase u objeto en C# .Net? cfdi SAT
Para convertir un archivo XML ya timbrado a un objeto en C# haremos uso de la deserialización.
Lo primero que debes hacer es descargar las 2 clases que están debajo, estas clases fueron generadas por medio de los xsd del SAT (Como convertir un archivo xsd a clases).
TimbreFiscalDigitalv11_tdCFDI.cs
Una vez que tengas estas clases debes hacer lo siguiente (comento línea a línea para que entiendas el flujo):
//crear un objeto el cual tendrá el resultado final, este objeto es el principal
Comprobante oComprobante;
//pon la ruta donde tienes tu archivo XML Timbrado
string path = @"C:\miXML.xml";
//creamos un objeto XMLSerializer para deserializar
XmlSerializer oSerializer = new XmlSerializer(typeof(Comprobante));
//creamos un flujo el cual recibe nuestro xml
using (StreamReader reader= new StreamReader(path))
{
//aqui deserializamos
oComprobante = (Comprobante)oSerializer.Deserialize(reader);
//Deserializamos el complemento timbre fiscal
foreach (var oComplemento in oComprobante.Complemento)
{
foreach (var oComplementoInterior in oComplemento.Any)
{
//si el complemento es TimbreFiscalDigital lo deserializamos
if (oComplementoInterior.Name.Contains("TimbreFiscalDigital")) {
//Objeto para aplicar ahora la deserialización del complemento timbre
XmlSerializer oSerializerComplemento = new XmlSerializer(typeof(TimbreFiscalDigital));
//creamos otro flujo para el complemento
using (var readerComplemento = new StringReader(oComplementoInterior.OuterXml))
{
//y por ultimo deserializamos el complemento
oComprobante.TimbreFiscalDigital =
(TimbreFiscalDigital)oSerializerComplemento.Deserialize(readerComplemento);
}
}
}
}
}
Te invito a que tomes mi curso gratuito para crear la factura electrónica 3.3, en menos de 1 hr ya serás capaz de desarrollar módulos para facturación según obliga el SAT.
¿Cómo poner el formato correcto de fecha para facturación electrónica 3.3 en C# .Net? cfdi SAT
Para ponerle el formato correcto para un xml que será timbrado con las reglas de cfdi 3.3, vamos a aplicar el formato a un DateTime de la siguiente forma:
//teniendo el dato en un DateTime en una variable llamada Fecha
string sFechaSAT= Fecha.ToString("yyyy-MM-ddTHH:mm:ss");
Así tu fecha tendrá el formato correcto para el timbrado.
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.