phpcfdi / sat-ws-descarga-masiva Goto Github PK

La propuesta es liberar la versión estable pero incrementar la versión mínima a PHP 7.3 que es la mínima con soporte activo.

@blacktrue ¿Qué opinas?

no puedo generar una descarga valida, quiero decir, al momento de verificar que este lista la descarga, siempre me arroja el Estatus 5 (No se encontró la información: Indica que no generó paquetes por falta de información.), pero estoy usando un RFC valido y un periodo en el que se que genero facturas, una FIEL valida (real, no usuario de pruebas).

mando la fecha inicia, fecha final, tipo de descarga (ya intente con metadatos y cfdi) y el rfc, pero solo me regresa ese error, cualquier ayuda se agradeceria.

¿Es posible crear una consulta por UUID?

Actualmente hay algunos scripts de muestra (dentro de tests/Scripts) que pueden ser utilizados para una ejecución de línea de comandos.

Lo mejor sería separar esta lógica en un proyecto independiente de primer nivel.

El archivo de metadata retornado por el SAT contiene diversos campos, algunos de ellos son tomados directamente del archivo de CFDI.

Particularmente los campos NombreEmisor y NombreReceptor son expuestos tal y como fueron escritos en el CFDI. Y las reglas para estos campos, según el Anexo 20 son simplemente [^|]{1,254} (cualquier caracter que no sea | (pipe), de 1 a 254 veces).

Esto lleva a que existan casos como: <Receptor Nombre="&quot;Patito SA&#xD;&quot;">, que es traducido a "Patito SA<CR>".

Al momento en que este registro es exportado en el Metadata por el servicio web del SAT, se retorna una línea que está incompleta porque se parte en dos a causa del <LF> intermedio:

UUID~...~AAA010101AAA~"Patito SA<LF>"~AAA010101AAA...<CR><LF>

Por alguna razón desconcida el SAT cambió el <CR> por un <LF>. El ejemplo anterior, al abrirlo en un editor de textos o importarlo como una hoja de cálculo aparece como dos líneas diferentes.

En términos prácticos, esto nos lleva a que los campos de NombreEmisor y NombreReceptor pueden contener caracteres de control, como ~, \~, <CR>, <LF> y ", que provocarán una lectura defectuosa de la información.

Por lo anterior, el lector de Metadata, también interpreta dos líneas separadas de información, y por su misma naturaleza tolerante, dos líneas con errores de datos, la primera incompleta, y la segunda errónea.

Nota: El ejemplo anterior es un extracción de información de un caso totalmente real, y que aunque es poco común, todos estamos expuestos. Gracias al usuario @TheSpectro que nos compartió información suficiente en el canal de Discord para poder detectar el problema.

La librería debe generar excepciones específicas que a su vez dependan de las excepciones SPL de PHP, usando las siguientes extrategias:

• Las excepciones implementan una interfaz nominal (sin métodos)
• Las excepciones tienen constructores privados y (1/n) método estático de construcción
• Las excepciones describen uno y solo un estado de excepción
• Las excepciones deben ser finales
• Si se trata de una especialización se deberá abstraer una excepción abstracta o un rasgo (trait)

Buena tarde @eclipxe13.

Creo que hace falta consumir el webservice para obtener los CFDI de retenciones. Las URL's cambian entre ambos servicios:

CFDI
Autenticación:
https://cfdidescargamasivasolicitud.clouda.sat.gob.mx/Autenticacion/Autenticacion.svc
Solicitud:
https://cfdidescargamasivasolicitud.clouda.sat.gob.mx/SolicitaDescargaService.svc
Verificación:
https://cfdidescargamasivasolicitud.clouda.sat.gob.mx/VerificaSolicitudDescargaService.svc
Descarga:
https://cfdidescargamasiva.clouda.sat.gob.mx/DescargaMasivaService.svc

Retenciones
Autenticación:
https://retendescargamasivasolicitud.clouda.sat.gob.mx/Autenticacion/Autenticacion.svc
Solicitud:
https://retendescargamasivasolicitud.clouda.sat.gob.mx/SolicitaDescargaService.svc
Verificación:
https://retendescargamasivasolicitud.clouda.sat.gob.mx/VerificaSolicitudDescargaService.svc
Descarga:
https://retendescargamasiva.clouda.sat.gob.mx/DescargaMasivaService.svc

Esta bien sabido que el consumo del webservice trae como resultado todos los comprobantes Emitidos y/o Recibidos del periodo consultado. Pero ¿podría hacerse la consulta filtrando por RFC en especifico? El mismo caso para Metadata.

En el caso de emitidos traer solo los resultados de un RFC receptor o viceversa.

El SAT ha liberado el manual de la versión 1.2:

• https://www.sat.gob.mx/consultas/42968/consulta-y-recuperacion-de-comprobantes-(nuevo)

En esta nueva versión, hay un cambio incompatible:

• Ya no existe el campo RfcReceptor y ahora se usa el nodo RfcRecibido.

Los otros cambios (compatibles/opcionales) son:

• Filtrar por complemento
• Filtrar por estado (vigentes/canceladas)
• Filtrar por tipo de comprobante (I, E, T, P, N)
• Filtrar por RFC de cuenta de terceros
• Ya es posible filtrar por receptores hasta 5 RFC (emitidas para los receptores a, b, c, d ó e)

El paquete de metadata que entrega el SAT está devolviendo archivos con el formato <UUID>-<consecutive>.txt, por ejemplo 622CEE0C-8BBA-4273-B02A-B8789FD27F62-0000.txt.

Actualmente la librería espera nombres de archivos como <UUID>_<consecutive>.txt, por ejemplo 45C5C344-DA01-497A-9271-5AA3852EE6AE_01.txt.

Esto hace que MetadataPackageReader::filterEntryFilename reconozca el nombre de archivo como excluido y por lo tanto no es leído.

Se debe corregir la expresión regular de evaluación.

Ocurre esta excepcion al ejecutar, sabras el porque?

Cannot open private key: error:23077074:PKCS12 routines:PKCS12_pbe_crypt:pkcs12 cipherfinal

Hola,
Haciendo pruebas con la librería en su versión "0.4.2", siempre me retorna el mensaje "Error no controlado".
¿A alguien más le está pasando esto?
Intenté hacer pruebas en local y en un servidor (por aquello del posible bloqueo por IP) y el resultado siempre fue el mismo.

Que tal, el paquete es muy bueno

Mi pregunta es sobre cómo poder hacer para saber solo la cantidad de cfdi que tenga la consulta?? o hay algo para poder saberlo para no afectar el punto de solicitar 2 veces el mismo xml

A que se refiere este punto "No existe limitante en cuanto al número de solicitudes siempre que no se descargue en más de dos ocasiones un XML."?? eso es que el xml se encuentre dentro de las consultas?? que si consulto 2022-01-01 al 2022-01-02 y luego hago otra consulta con otro rango de fechas 2021-12-31 al 2022-01-10 se cuentan todos los xml en este caso "2022-01-01 y 2022-01-02" como dobles?? y/o también cuenta que se haga dos veces la misma consulta?? o solo cuenta cuando se pide descargar el XML?? pero siendo solo metadatos no afecta en nada??

Esto es para poder determinar si son mas 200,000 poder hacer una manera para separar el rango de fechas en varias consultas y evitar que de alguna manera se pidan fechas repetidas nuevamente, ya sea que no encontró resultados, o falló por algún motivo la consulta, etc.

Estoy realizando una integración en un proyecto con Laravel, estoy siguiento el ejemplo que viene en la pagína pero al llegar a esta línea:

$packageId = $verify->getPackagesIds()[0];

Manda este error:

Undefined offset: 0

Imprimí la variable $verify y marca packagesIds como un arreglo vació y numberCfdis como 0,pero el rango de fechas que estoy seleccionando si tiene CFDIs.

¿Alguna idea de cuál puede ser el problema o que estoy haciendo mal?

Hola,

Tengo una duda con el Webservice del SAT ¿se puede saber si un CFDI está cancelado?, hasta ahorita la única solución que le he encontrado es una combinación:

• Webservice del SAT para la extracción masiva de los CFDI's vigentes
• Web Scraping para obtener las canceladas (semi-automatizada ya que requiere la captura del captcha)

¿Habrá alguna otra forma automatizada de saber si los CFDI's están cancelados?