Indeed no deja sacar por archive.org sus vacantes pero me pasaron una que si hay que compartir. Lo pongo con pantallas y un pdf de la vacante.
Es la primera oferta que he visto en uno o dos años que pidan opinión de cumplimiento. Si no conocen leyes laborales de por si es una vacante ilegal porque es su objeto real del trabajo, no pueden tercerizarlo por la ley de outsourcing.
Oferta real de febrero 2026, con pruebas
- Emite Facturación S.A. de C.V. (CDMX): El PAC que vive en coworking, paga igual que helpdesk y te pide que seas Senior, AWS-certificado, freelance y contador al mismo tiempo.
- Indispensable ganar menos que los de ventas, pero 500 mas que los de helpdesk
Te sugiero leer el análisis completo. Hay razones técnicas, fiscales y legales para no aplicar aquí. Como siempre: parte de tu trabajo en sistemas es hacer control de calidad. Eso aplica también a las ofertas de empleo.
| Caso | Empresa | Nivel de “Tomada de Pelo” | Razón Principal |
|---|---|---|---|
| 1 | Emite Facturación S.A. de C.V. | Senior con sueldo de helpdesk (y tú pagas los impuestos) | 5 años de experiencia, AWS, CodeIgniter, facturación CFDI — por $10,000 brutos facturando tú mismo desde un coworking que ni siquiera les pertenece. |
En pesos al mes que debió ser:
- Caso Emite: $30,000 – $40,000 netos por nómina. Con AWS certificado y experiencia real en CFDI, el techo sube a $50,000+.
- No menos de 25 mil por AWS 20 mil mínimo sin AWS
La Vacante
Desarrollador PHP — Freelance | Emite Facturación
Home Office · Tiempo completo · $10,000 a $20,000 por mesRequisitos indispensables: Licenciatura, 5 años de experiencia, CodeIgniter 3 y 4, PHP 7 y 8, Git/CodeCommit, AWS básico, consumo de API, Opinión de Cumplimiento SAT positiva.
Deseable: Conocimientos de facturación electrónica. Certificaciones AWS.
¿freelancer de tiempo completo? Es absurdo !
Y eso por sí solo ya te dice todo sobre quién va a ser tu jefe técnico si aceptas. 🎯
Pantalla 1
Pantalla 2
Nota: Imposible en 8 lineas por dos razones (explicamos mas adelante). Serverless y Factura Electrónica no pueden ir en la misma frase. Están obligados a guardarla y a regresartela Y los requisitos de seguridad de los datos te obligan a respaldos y estructura propia. Esto es vender humo.
-
La carga de la prueba: Cualquier defensor de la empresa puede demostrar cómo meten validación de esquema, manejo de excepciones de red, parseo de XML y persistencia en una línea y media de código. No pueden.
- El mito de las 8 líneas se cae por su propio peso legal: para timbrar necesitas firmar el XML. Esto requiere cargar el certificado (.cer), la llave privada (.key) y la contraseña del sello. Si la API de Emite lo hace ‘mágicamente’ en 8 líneas, significa que tú les entregaste tus llaves privadas para que ellos las guarden. En términos de seguridad informática y cumplimiento fiscal, eso es entregarle las llaves de tu caja fuerte a un extraño que vive en un coworking.
-
Si no guardas, no auditas. Si no auditas, no cumples. La trampa de las 8 líneas: Solo funcionan si ignoras el Artículo 29 del Código Fiscal de la Federación, que te obliga a conservar los comprobantes.
Pantalla 3
Pantalla 4
Nota: Los vendedores ganan mas que los desarrolladores y ganas 500 mas que helpdesk.
Pantalla 5
Nota: 2.6 en Glassdoor es el dato que amarra todo.
Glassdoor es difícil de manipular porque las reseñas vienen de empleados reales verificados. Un 2.6 sobre 5 en una empresa de 6-10 personas significa que la mayoría de los que han trabajado ahí salieron con una experiencia negativa suficientemente fuerte como para tomarse el tiempo de escribirla. La otra reseña es de cinco y de uno de los dueños por ser puesto irreal
Y encaja perfectamente con todo lo que ya documentamos:
- Empresa familiar donde los puestos de mando son “de la familia”
- Sueldo de helpdesk para Senior
- Esquema freelance que evade prestaciones
- Reseña de Glasdoor que dice que eres contratista 2025 y vas a baños en obra negra
El 2.6 no es sorpresa. Es la calificación natural de una empresa que trata a su talento técnico como gasto, no como activo.
Pantalla 6
Nota: Los vendedores ganan mas que los desarrolladores y ganas 500 mas que helpdesk.
Cuatro absurdos :
- Serverless + PAC = helado de pollo rostizado
- Serverless + Timbrar = tus certificados vuelan
- Freelance + Tiempo Completo = caníbal vegetariano
- 8 líneas + CFDI = sin Control de errores ni Articulo 29 del Código Fiscal de la Federación que te obligan a conservar los comprobantes.
Los cuatro en la misma vacante no es descuido. Es un patrón de alguien que escribe términos que suenan bien sin entender lo que significan ni las contradicciones que generan.
Caso 1: Emite Facturación y el Arte de Pagar Helpdesk por Senior
¿Quiénes son?
Emite Facturación S.A. de C.V. (RFC: EFA100217SU5) es un PAC autorizado por el SAT desde 2012 — un Proveedor Autorizado de Certificación de comprobantes fiscales digitales. Llevan más de 12 años en el mercado. No son una empresa fantasma.
http://omawww.sat.gob.mx/tramitesyservicios/Paginas/cfdi.htm
El problema no es que sean ilegítimos. El problema es cómo tratan al talento que necesitan para operar.
Y que se están desistiendo de ser PAC, y que no ponen ser PAC en su sitio web.
🏢 Bandera Roja #1: El Coworking de Reforma
Su domicilio fiscal registrado ante el SAT es Av. Paseo de la Reforma 404, Piso 13, Col. Juárez, CDMX. Suena impresionante. Es una dirección premium.
El detalle: ese piso 13 de Reforma 404 es Net(work) — una cadena de coworkings y oficinas virtuales. No tienen oficinas propias. Pagan una membresía para tener una dirección de Reforma en su RFC.
Esta es una bandera roja para mí como criterio de filtro personal: si la empresa opera desde un coworking o usa una dirección de oficina virtual como domicilio fiscal, no aplico. Habla del tamaño real de la operación y de la estabilidad del proyecto. Según registros del SIEM, Emite tiene entre 6 y 10 personas. Las reseñas en Indeed mencionan que buscarían mejorar contratando gente “que no sea de mi familia para puestos de mando.” Empresa familiar chica, con domicilio prestado.
🔗 Bandera Roja #2: El Link Roto en el SAT
En la lista oficial de PACs del SAT, el enlace que aparece para Emite apunta a http://www.emite.mx/ – su sitio comercial general. No a un portal de facturación gratuita, que es exactamente lo que el SAT exige que los PACs ofrezcan como condición de su autorización.
Todos los PACs serios de la lista enlazan directamente a su portal gratuito. Emite enlaza a su página de ventas. O el servicio gratuito ya no existe en la práctica, o nadie en la empresa se preocupó por actualizar el dato ante el SAT en años. Cualquiera de las dos opciones habla mal de su operación interna.
No les preocupa el cumplimiento con el SAT que les exige la ley. No pasan la auditoría mas básica.
Si no pasan esa auditoría básica, ¿qué pasa con las que no son visibles?
💰 Bandera Roja #3: El Sueldo vs. El Mercado Real
| Fuente | Sueldo PHP México 2026 |
|---|---|
| Computrabajo (promedio) | $16,160 / mes |
| Indeed (promedio) | $15,336 / mes |
| Hireline (promedio neto) | $28,352 / mes |
| Talently (Senior con 5+ años) | $50,000 – $75,000 / mes |
| Lo que ofrece Emite | $10,000 – $20,000 / mes (bruto, facturando tú) |
La oferta está por debajo del promedio del mercado incluso en su techo de $20,000, para un perfil que el mercado cotiza entre $30,000 y $75,000 dependiendo de la experiencia. Y eso es antes de restarle impuestos.
💀 Bandera Roja #4: El Helpdesk Gana Casi lo Mismo
Según registros de Indeed, Emite paga $9,500 al mes para helpdesk.
Diferencia entre un soporte técnico básico y un desarrollador PHP Senior con 5 años, AWS, CodeIgniter y CFDI: $500 pesos al mes en el mejor caso de arranque.
Eso no es un rango salarial. Eso es una confesión de que para esta empresa, el talento de desarrollo no tiene valor diferenciado del soporte de primer nivel.
🧾 Bandera Roja #5: Freelance Disfrazado de Empleo
La vacante dice “Freelance” y también dice “Tiempo Completo.” Esas dos palabras no pueden coexistir honestamente.
Freelance implica autonomía, múltiples clientes, tarifas por proyecto. Tiempo completo implica subordinación, horario, exclusividad. Lo que Emite busca es un empleado sin prestaciones de ley:
- Sin IMSS
- Sin Infonavit
- Sin aguinaldo
- Sin prima vacacional
- Sin PTU
Y la prueba está en el requisito de la Opinión de Cumplimiento SAT Positiva. Eso confirma que el modelo es que tú factures como persona física. COMO PROVEEDOR. Tú absorbes ISR, IVA y toda la carga fiscal. La empresa se ahorra el costo patronal completo.
Este esquema – donde hay relación laboral real encubierta como prestación de servicios – está en la mira del IMSS desde la reforma de subcontratación de 2021, precisamente para combatir esto. La empresa corre riesgo legal. Tú corres riesgo fiscal.
¿Es ilegal pedir la Opinión de Cumplimiento? El documento en sí es público. Lo que es cuestionable es el esquema completo: si trabajas tiempo completo, para un solo cliente, bajo subordinación, PARA EL OBJETO PRINCIPAL DE QUIEN PONE LA VACANTE la Ley Federal del Trabajo lo considera relación laboral independientemente del contrato que firmes. La empresa evade obligaciones patronales. Tú subsidias esa evasión con tu dinero.
🏅 Bandera Roja #6: Las Certificaciones AWS “Deseables”
Una certificación AWS Solutions Architect Associate cuesta aproximadamente $300 USD (~$6,000 MXN) solo el examen, sin contar cursos de preparación ni tiempo de estudio.
La piden como “deseable” para un puesto que arranca en $10,000 brutos. El ROI de esa certificación trabajando con ellos sería negativo desde el día uno. La ponen como deseable porque saben que nadie con AWS certificado les aceptaría el sueldo como requisito indispensable. Esperan que alguien que ya invirtió en certificarse “de gratis” no haga las cuentas.
❓ Bandera Roja #7: El “Caso de Éxito AWS 2020” No Verificable
Emite se presenta como un “caso de éxito AWS 2020.” AWS publica sus casos de éxito en su sitio oficial. Emite no aparece en ningún registro oficial de AWS. Puede ser marketing propio sin respaldo formal, o simplemente un dato que no se puede verificar. En cualquier caso, no es verificable.
🚩 Red Flags: Resumen Rápido
- ✅ PAC legítimo registrado ante el SAT desde 2012
- 🚩 Domicilio fiscal en coworking (Net(work), Reforma 404)
- 🚩 Empresa familiar de 6-10 personas
- 🚩 Link roto/inútil en la lista oficial del SAT
- 🚩 Sueldo 50-60% por debajo del mercado para perfil Senior
- 🚩 Helpdesk gana casi lo mismo ($9,500 vs $10,000)
- 🚩 Vendedores ganan más ($13,000 vs $10,000)
- 🚩 Freelance + Tiempo Completo = relación laboral encubierta
- 🚩 Tú pagas los impuestos (ISR + IVA como persona física)
- 🚩 Certificaciones AWS “deseables” a sueldo de entrada
- ❓ “Caso de éxito AWS 2020” no verificable en fuentes oficiales
Qué deben pagar (Caso Emite)
- Mi estimación: $30,000 – $40,000 netos
- Muy Conservador sin AWS: 20000 a 25000 netos
- Por qué es correcta: Un perfil Senior PHP con 5 años, CodeIgniter, AWS y conocimientos de CFDI es especializado. El CFDI implica conocimiento fiscal que no cualquier desarrollador tiene. Eso tiene un premio de mercado. Pedir además que el candidato corra con toda la carga fiscal como freelance y que encima tenga certificaciones AWS, justifica fácilmente $40,000 netos o más. Por nómina. Con prestaciones. No facturando desde tu casa a $10,000 brutos.
- Enfoque Conservador :En el mejor de los casos como CREIBLE sería 20-25 mil netos SIN AWS. La responsabilidad de hacer facturas y su complejidad fiscal no es menos de 20 mil, pero si no eres RESPONSABLE de la nube, dependes de que tan bueno sea el admin. Te piden certificaciones pero en realidad no trabajas en facturación en la nube y menos de un PAC por menos de 20 a 25 mil por la responsabilidad que lleva. La bandera roja del coworking + portal Facturación no existente + pedir certificación AWS te dicen “no te comuniques”. Al decir DESEABLE y certificación AWS muy conservador es 35 mil.
Veredicto
Nivel: “Pinocho Supreme”
- Incumplen ante el SAT: su portal gratuito obligatorio tiene el link roto
- Mienten a todos con Coworking en reforma
- Mienten a Clientes con “8 lineas” (ver nota técnica abajo)
- Caso de Exito Amazon Dudoso y contradictorio
- Mienten con nivel salarial
No puedes trabajar como empleado , cliente o proveedor de alguien que incumple en lo fiscal (portal gratuito + outsourcing), y miente en lo técnico y en los salarios.
Nivel: “Rebelión contra las matemáticas”
Porque ya no es solo que mienten es que la mentira es matemáticamente imposible de sostener:
- Primer timbrado: 1 envío + 1 recepción + 1 control de errores
- Segundo timbrado: 2 envíos + 2 recepciones + 2 controles de errores
- Total real con dos timbrados: ~140-160 líneas mínimo
Contra 8 prometidas.
Si solo hacen segundo timbrado = 8 / 3 procesos = 2.67 procesos completos por linea
Si hacen primero y segundo timbrado = 8 / 6 procesos = 1.33 procesos completos por linea
No es exageración. No es interpretación. Es multiplicación básica. El argumento se destruye solo con una calculadora. 🎯
El contraste no necesita explicación.
Nivel: “El Employer con Calculadora Rota”
Porque $10,000 más $500 no es un plan de carrera para un Senior de 5 años. Es una oferta que solo tiene sentido si el candidato no sabe cuánto vale, no sabe ni calcula las responsabilidades de factura electrónica , no sabe cuánto pagará de impuestos, o no leyó bien que “freelance + tiempo completo” no existe legalmente.
Nivel: “Timbre Fiscal de Autor”
Porque te piden que seas el PAC de tu propio empleo. Que certifiques, que factures, que pagues ISR y IVA, y que encima agradezcas entrar a su “directorio de freelancers” donde quizás te llamen cuando tengan proyectos.
Nivel: “Coworking Penthouse”
Porque Reforma 404 suena bien en el RFC. Pero es una membresía de oficina virtual, no una empresa con infraestructura propia. Si el domicilio fiscal es un coworking, la operación también lo es.
Qué deben pagar (Caso Emite)
- Sin responsabilidad directa de nube: $20,000 – $25,000 mínimo netos, por nómina. La responsabilidad de trabajar en el sistema CFDI de un PAC no es negociable hacia abajo.
- Con certificación AWS en scope real: $35,000 conservador, por nómina. Si la nube es parte del trabajo, el piso sube.
- Por qué no como freelance: A $20,000 brutos facturando como persona física, después de ISR e IVA te quedas con aproximadamente $14,000–$16,000 netos. Eso no es el piso. Es el techo disfrazado de rango.
🔬 Nota Técnica : Amazon y PAC
- Emite (CX Intelligence): Es una empresa global de análisis de centros de contacto (Australia/Global) muy presente en el AWS Marketplace. Sus “casos de éxito” suelen ser sobre Amazon Connect.
- Emite (Soluciones Fiscales Digitales): Es una empresa mexicana especializada en facturación electrónica.
Mi instinto me hace pensar que son homónimos. Si pueden certificar que tienes servidores con ellos…. ¿¿ hace cinco años ??
Lo que te dicen es : Hace cinco años Un “Emite” fue cliente de Amazon y yo no me he recertificado.
Pero .. da la casualidad que en 2010, dos años antes de Emite fuera PAC mi trabajo de la época quería ser PAC. En ese momento con una computadora con internet propio y un gabinete de documentacion y servers a la vista te certificabas (como dato cambiaron a alguien internamente y nunca nos certificamos) Pero la matriz de requisitos para ser entonces PAC y hasta 2012 que salí era obligatorio ser dueño de infraestructura aislada.
Dicen ser Serveless pero en contexto de factura electrónica es contradictorio. Es un helado de pollo rostizado o un caníbal vegetariano, piensalo un poco.
¿ Serverless en un PAC ?
La analogía es perfecta y técnicamente exacta.
Serverless significa que no hay servidor dedicado — el código corre en funciones efímeras que se ejecutan bajo demanda, sin estado persistente, sin garantía de disponibilidad continua, sin infraestructura fija.
Tus certificados vuelan. Si están en un server no es serverless.
La facturación electrónica CFDI requiere exactamente lo contrario:
- Disponibilidad garantizada 24/7 — una factura que no timbra a las 11pm del 31 de diciembre es un problema legal real para el emisor
- Estado persistente — necesitas guardar XMLs timbrados, UUIDs, cadenas originales, sellos, archivos cer/key, folios, series
- Trazabilidad completa — el SAT puede auditar cualquier CFDI emitido en los últimos 5 años
- Certificados de seguridad propios — los cer/key no pueden vivir en una función efímera que desaparece después de ejecutarse
- Cumplimiento de respaldos obligatorios — la ley fiscal exige conservar comprobantes por plazos definidos
Serverless y PAC son estructuralmente incompatibles. No es una limitación técnica superable con creatividad — es una contradicción en los términos. El SAT te exige infraestructura robusta, redundante y auditable como condición de autorización. Serverless por definición no te da eso.
Tampoco Serverless a Clientes. Tu timbrado de segundo nivel que solo PAC hacen requiere servidores.
Seas Tu el cliente, o Emite como Pac / Integrador
El timbrado de segundo nivel — que es precisamente lo que Emite vende como su servicio — requiere por definición infraestructura de servidor dedicada porque:
En ambos pasos:
- Recibe el XML del cliente
- Lo valida contra esquemas del SAT
- Aplica el sello digital con certificados propios
- Regresa el CFDI timbrado con UUID
- Lo guarda para auditorías futuras
- La base de datos relacional no es serverless. No puede ser serverless
El helado de pollo rostizado es exacto: cada palabra por separado tiene sentido. Juntas describen algo que no puede existir.
Estás manejando doce archivos:
- xml ya timbrado o texto si ellos hacen primer y segundo timbrado
- tu cer
- tu key
- tu cer.pem
- tu key.pem
- ellos su cer
- ellos su key
- ellos su cer.pem
- ellos su key.pem
- xml final
- pdf final
- Posible qr obligatorio por ley
Asi que tienen un timbrado que en el mejor de los casossi solo usa .pem son 7 u 8 archivos cada operación de timbrado.
Serverless + 12 archivos por operación + base de datos relacional = tres imposibilidades en una sola frase de marketing. 🎯
Lo que encontré hoy
Para obtener autorización como PAC, el SAT exige entre otras cosas contar con un capital social suscrito y pagado de al menos $10,000,000 MXN y otorgar una garantía de cumplimiento de hasta $10,000,000 MXN vigente durante toda la autorización.
Además deben demostrar capacidad tecnológica e infraestructura que les permita prestar el servicio de certificación de CFDI, facilitando elementos para evaluación y pruebas de sus sistemas ante el SAT.
Esto implica contar con servidores robustos, sistemas de respaldo y medidas de seguridad cibernética, además de demostrar solvencia financiera y capacidad operativa. Freelancer Blog
Entonces el cuadro es este:
Para ser PAC necesitas $10 millones de capital social, $10 millones de garantía ante el SAT, infraestructura propia certificada con servidores robustos y respaldo, y pasar una evaluación técnica de tus sistemas.
Todo eso… y el domicilio fiscal es un coworking en Reforma.
La infraestructura tiene que existir en algún lado — probablemente AWS, lo que ironicamente explicaría el “caso de éxito AWS” que no es caso de éxito sino simplemente que rentan servidores como cualquier cliente. Pero el hecho de que su presencia física sea una oficina virtual mientras certifican millones de facturas de terceros es una pregunta legítima que cualquier cliente debería hacerle.
Yo no los usaría como PAC por tres razones : 8 lineas, coworking y amazon COmo proveedor son vendedores de humo.
🔥 Las 8 líneas
Mienten en su propuesta de valor.
Citandome otra vez:
-
Si no guardas, no auditas. Si no auditas, no cumples.
-
La trampa de las 8 líneas: Solo funcionan si ignoras el Artículo 29 del Código Fiscal de la Federación, que te obliga a conservar los comprobantes.
El ciclo de Facturación ya que te conectas con el “proveedor de timbrado” tiene cuatro fases.
a ) Envio al proveedor
b ) recepción del proveedor
c ) Control de errores.
d ) Guardar y Conservar los documentos
Si alguien con experiencia real en facturación electrónica dice que una factura con todos sus parámetros obligatorios — artículos, precios, pesos, claves SAT, datos del emisor, receptor, régimen fiscal, uso CFDI, addendas — son conservadoramente 40 líneas de PHP, el “8 líneas out-of-the-box” es marketing engañoso dirigido a clientes que no saben programar.
Solo está considerando el Envio y mal.
Para la recepción que haces ?
yo esto :
Las 8 líneas son solo el POST de envío.
La recepción es otro proceso completo:
1. Recibir la respuesta HTTP
2. Guardarla inmediatamente en base de datos
3. Verificar la Grabación del paso 2
4. Verificar código de respuesta (200, 400, 500…)
5. Deserializar el JSON/XML de respuesta
6. Extraer el UUID del CFDI timbrado
7. Extraer el sello del SAT
8. Extraer la cadena original del complemento
9. Validar que el UUID sea único en tu sistema
10. Guardar el XML timbrado en base de datos
11. Guardar el PDF timbrado en base de datos (si te lo mandan)
12. Borrar tu archivo temporal del sistema de archivos
13. Generar el QR obligatorio por ley o guardar el que ellos te dieron
* Algunos servidores no tienen rutina de graficos, tu puedes generarlo solo
* pero he tenido que hacer “puentes” cuando no hay algo grafico en tu php
* aunque lo deseable es generarlo en memoria con PHP para
14. Generar el PDF de representación impresa en tu propio formato
15. Enviar al cliente por correo pdf y xml
Y como verificaciones adicionales
1. Archivar con folio y serie y emisor (si tu sistema es multirfc puedes compartir serie y folio en dos emisores y/o clientes)
2. Manejar errores del SAT (códigos 301, 302, 401…)
3. Manejar timeouts y reintentos
4. Actualizar estatus en tu sistema
Y esto es a ojo.
en mi caso mi manejo de errores anda por las 120 lineas.
Entonces el cuadro completo real es:
| Proceso | Líneas reales |
|---|---|
| Construcción del XML (primer timbrado) | ~40 |
| Envío al PAC | 8-17 según lenguaje |
| Recepción y procesamiento | ~20-25 |
| Total real | ~70-80 líneas |
Vender 8 líneas para CFDI es como vender un kit de cirugía diciendo que ‘solo tienes que hacer un corte’. Ignoran la anestesia, la esterilización, la sutura y el monitoreo del paciente. En sistemas financieros, el ‘monitoreo’ se llama manejo de errores, y la ‘sutura’ se llama persistencia de datos. Si tu código solo tiene 8 líneas, tu empresa está desangrándose legalmente.
Existe en el sistema de facturación REAL el concepto de primer y segundo timbrado. Puede uno Hacer un txt o json que después se converte en un XML al que se le aplican los timbres fiscales. En los ejemplos parece que tu le das ya el XML verificado (primer timbrado) y ellos lo reciben como base64 Eso se procesa eso en el Servidor de EMITE, como parece, ellos tienen los certificados de cer/key de clientes lo que es mala práctica. Debería estar solo el .pem a a menos que Emite y tu programador sean super descuidados.
Pueden decir que tu ya lo timbraste en el primer timbrado y que no necesitan tus sellos pero esto no se sostiene por muchas razones.
- No hay escenario donde el segundo timbrado no necesite tus certificados y se haga una verificación. Por Compliance Debería calcular que el certificado es real.
- Además en ese caso son Dos POSTS o envios, uno por el primer timbrado, tu trabajo duro o el segundo que es lo que ellos hacen
- Y dos recepciones. Realmente tu numero de líneas se duplican por dos envios y dos recepciones y dos controles de errores.
- 8 lineas, imposible en primer o segundo timbrado. Nivel Rebelión contra las matemáticas.
- Como ejemplo de que existe primero y segundo timbrado pongo ejemplos de response de un PAC real, que yo no uso, pero que usé hace unos tres años con uno de mis clientes https://solucionfactible.com/sfic/capitulos/timbrado/noticias-error-307.jsp
- PAC 54555 su portal gratuito https://solucionfactible.com/cfdi-gratuito/login.jsp
- Y se los recomiendo todavía a clientes con una necesidad específica.
Pero… Hacer el timbrado UNO ese el mas complicado. Puedo creer que exista un Timbrado de 8 Lineas pero como segundo timbrado, quitando todo el nivel de dificultad del primero y para poder hacer esto además necesitarían los cer/key
Construir el primer timbrado de manera conservadora y ya teniendo datos de emisor y receptor en bases de datos, y las tablas del SAT de emisores, formasde pago, claves de productor, claves de unidades. En mi sistemas son estas tablas
- SAT_ClaveProdServ
- SAT_ClaveUnidad
- SAT_CP
- SAT_FormaPago
- SAT_Impuesto
- SAT_MetodoPago
- SAT_Moneda
- SAT_Pais
- SAT_RegimenFiscal
- SAT_TipoDeComprobante
- SAT_TipoFactor
- SAT_TipoRelacion
- SAT_UsoCFDI
El bucle de leer productos de la factura, unidades, costo unitario, pasar a formato de decimales del Sat en mi caso son 14 lineas por que manejo descuentos, moneda extranjera Creacion de cadena de texto para dejar asentada la UNIDAD DE MEDIDA SECUNDARIA. No puedes darla a un cliente una unidad H87 , le tienes que hablar en cristiano.
Si decides pasar a timbrado sea uno o dos, son unas 20 lineas. Incluso el número de archivos del SAT lo demuestra lateralmente.
Sumale lo que no es el SAT Articulos, precio unitario alista de precios, peso , llaves, codigos, cliente, emisor, incluso usando una tabla adicional como yo hago de catálogo de emisores, y de clientes y puestos de entrega cada facturalleva un nivel de complejidad que son unos 40 lineas de modo conservador en php. Si puede ser que tengas un array, pero 8 lineas, no.
Ellos te venden un segundo timbrado probablemente y la prueba plena es que generar el primer timbre necesitas consultar 16 tablas por lo menos (clientes emisores llavesde cer/key) mas las 13 del sat.
¿ en 8 lineas ?
Y manejas conservadoramente siete archivos y probablemente 12 como pac.
Si dicen “sí es posible en 8 líneas” están admitiendo implícitamente que es segundo timbrado – lo que significa que alguien más ya hizo el trabajo difícil, o que ellos guardan tus cer/key, que es peor. No tienen salida limpia en ninguna de las dos direcciones.
La única forma de atacar el argumento sería mostrar código PHP real de un primer timbrado completo en 8 líneas. Eso no existe.
Un segundo timbrado en 8 líneas tampoco existe porque aunque ya tengas el XML del primer timbrado, todavía necesitas:
- Leer el XML previo y verificar su estructura
- Validar que el UUID original sea válido ante el SAT
- Construir el nodo de relación entre comprobantes (
TipoRelacion) - Manejar los casos de complemento de pago, nota de crédito o sustitución — cada uno con su propia lógica
- Firmar con cer/key
- Hacer el POST al PAC
- Manejar la respuesta y errores del SAT
- EMITIR Y GUARDAR 8 de los 12 archivos mencionados, EN SISTEMA DE ARCHIVOS Y/O EN TU BASE DE DATOS
Eso no es 8 líneas. Ni de cerca.
Tampoco es Serverless
Asi que si recibes el dato timbrado ( tu xml ) tienes que bajarlo ,revisar uuid, generar el QR enviuarlo al cliente o archivarlo y eliminar el archivo temporal masmanejo de errores.
Lo que venden como “8 líneas” no es ni primer ni segundo timbrado real. Es el POST final al endpoint — que es la parte más trivial de todo el proceso. Es como vender un auto diciendo “solo tienes que girar la llave” y omitir que primero tienes que construir el motor.
Como dije mas arriba:
- El mito de las 8 líneas se cae por su propio peso legal: para timbrar necesitas firmar el XML. Esto requiere cargar el certificado (.cer), la llave privada (.key) y la contraseña del sello. Si la API de Emite lo hace ‘mágicamente’ en 8 líneas, significa que tú les entregaste tus llaves privadas para que ellos las guarden. En términos de seguridad informática y cumplimiento fiscal, eso es entregarle las llaves de tu caja fuerte a un extraño que vive en un coworking.
🔬 El asunto del PAC
No dicen ser PAC , pero aparecen en la lista del PAC como vigentes. Hay además un pdf de desistimento de ser un PAC, lo que significa que probablemente no cumplen con el Capital y solo son integradores ahora. Todos los clientes que manejaran Siendo PAC, antes de desistirse, por COMPLIANCE deberian dejar de trabajar con ellos.
Sus clientes no estan haciendo Due Dillgence. NIA 240 y 320, mas NIIF a-2 ( contablemente no se tienen los controles básicos )
- En cristiano: sus clientes corporativos y de gobierno deberían haber auditado a su PAC antes de contratarlo Y DOS VECES AL AÑO. No lo hicieron.
- Si una empresa no puede mantener clara su propia situación ante la autoridad que la regula, no se puede esperar que mantenga clara la situación laboral de sus colaboradores o la estabilidad técnica de sus sistemas.
- Si tu como persona de sistemas los contratas y no buscas el rfc tienes un buen lio
¿Porque se desistieron? ¿ Se desistieron en que año.?
Archive .org lo tienearchivado del 2025
Ellos son proveedor de certificacion en 2025.
No se afirma más de lo que la evidencia muestra.
El estado real de Emite ante el SAT es una caja de Schrödinger:
- Aparecen en lista de desistidos
- Aparecen en lista de autorizados activos
- No se presentan como PAC en su propio sitio
- No tienen sitio publico de timbrado gratuito que exige la ley
- Pero siguen certificando facturas con su RFC en 2025
- Subcontratan su objeto principal
- Y una de esas facturas es para el Gobierno de Guanajuato — entidad pública que publica sus facturas por transparencia
Es una contradicción en siete dimensiones simultáneas.
No sabemos si el desistimiento fue aceptado, rechazado o está en proceso. Pero eso no importa para el argumento. Lo que importa es:
La incertidumbre misma es la razón para no contratarlos y no trabajar para ellos.
Ningún cliente serio debería usar un PAC cuyo estatus de autorización ante el SAT requiere cruzar dos listas contradictorias para entender si opera legalmente o no. Y ningún desarrollador debería vincular su reputación técnica a una empresa en ese limbo.
“No sabemos si están procesando su desistimiento o si nunca se los aceptaron. Lo que sí sabemos es que esa incertidumbre sola es razón suficiente para no aplicar y para no contratarlos como PAC ni como integradores.”
🔬 Nota: El Veredicto de Cumplimiento (Compliance)
¿Por qué importa que una empresa juegue a las escondidas con su estatus de PAC? Porque en el mundo del CFDI, la certeza jurídica es el producto, no el software. Si el estatus de Emite es una moneda en el aire, el riesgo se traslada directamente al contribuyente y al empleado.
En resumen:
-
Inconsistencia Administrativa: Aparecer en listas de desistimiento mientras se factura a entidades gubernamentales en 2025 sugiere una operación en “tiempo prestado” o una desatención administrativa profunda.
-
Riesgo de Continuidad: Para un desarrollador, trabajar en un sistema cuyo permiso de operación está en duda es construir sobre arena. Para un cliente y para un empleado, es una bomba de tiempo fiscal.
-
Falta de Transparencia: Un PAC legítimo presume su autorización y facilita el acceso al portal gratuito. Una empresa que oculta su estatus y su portal de ley, no está operando bajo los principios de integridad que el SAT exige.
Conclusión para el colega: Si el SAT no tiene claro qué son, y ellos mismos no lo publican con orgullo, tú no deberías poner tu firma (ni tu código) en sus servidores. En el Compliance, si parece pato y camina como pato, pero el registro dice que desistió de ser pato… mejor no nades en esa laguna.
🔬 Nota Técnica Extra: Lo Que Su Propia Documentación Dice de Ellos
Si llegaste hasta aquí y trabajas con facturación electrónica, esto es para ti. No necesitas creerme a mí — su propia documentación de API lo dice todo.
Emite publica ejemplos de integración en 5 lenguajes. Los conté línea por línea:
| Lenguaje | Líneas reales | Nota |
|---|---|---|
| C# | 8 | XML hardcodeado como string escapado — código de demo, no de producción |
| JavaScript (jQuery) | 17 | |
| Python | 13 | |
| Ruby | 19 | |
| Java (OkHttp) | 11 | |
| PHP (el de la vacante) | No existe | ❌ No tienen ejemplo en el lenguaje que contratan |
| Lo que prometen | 8 | 🎭 Solo en C# con XML trucado. Promedio real: 14 líneas |
El “8 líneas out-of-the-box” existe exactamente en un lenguaje, comprimiendo el XML como string escapado ilegible que ningún desarrollador usaría en producción. En los otros cuatro lenguajes el promedio es 15 líneas – casi el doble de lo prometido.
Pero el problema real no son las líneas. Es lo que todos los ejemplos tienen en común: el parámetro "xml": "PD94...".
Ese PD94... es Base64 de un XML CFDI completo, ya construido, ya validado. Es lo que a veces se le llama Primer Timbrado. Ningún ejemplo muestra cómo se construye ese XML. Y ahí está el trabajo real: emisor, receptor, artículos, precios, claves de producto SAT, claves de unidad, régimen fiscal, uso CFDI, forma de pago, método de pago, totales, impuestos desglosados, descuentos desglosados, y addendas cuando aplican. Conservadoramente 40 líneas de PHP por factura, usando tabla auxiliar de catálogo de emisores para no repetir datos.
Lo que su API recibe es un XML ya armado. Lo que timbra es ese XML. El trabajo de construirlo — que es el conocimiento real, el que requiere 5 años de experiencia y entender los catálogos del SAT — no aparece en su documentación porque ese trabajo lo hace el desarrollador que contratan.
Un PAC que promete 8 líneas cuando son 14 en el mejor caso trucado, que no tiene documentación PHP para su propia API siendo PHP el lenguaje de su vacante, y que oculta la complejidad real del CFDI en un string Base64 — no es un PAC con el que quieras trabajar ni como empleado ni como cliente.
Si eres desarrollador con experiencia real en facturación electrónica y viste esto: sabesque es tomada de pelo.
¿Tienes una oferta absurda?
Mándamela con screenshot o link en los comentarios. Criterios para publicación: oferta real con prueba, red flags técnicas o legales claras, útil para la comunidad. Puedo publicarla anónima si prefieres, pero las empresas que publican ofertas abusivas merecen ser señaladas.
