Closed thefantas closed 6 years ago
El success solo indica que la conexión con Sunat se realizó correctamente y se obtuvo respuesta. Por otro lado el codigo que retorna statusCode, puede tener los siguientes valores Los codigos que te indique en el otro issue, son para las respuestas de sunat relacionado al envio y cdr del comprobante.
mmm si ps pero ahora sunat esta devolviendo el valor 0004.
y a mi me devuelve esto
#####################################################################
<b#>Notice<#/b>: Undefined property: stdClass::$content in /vendor/greenter/ws/src/Ws/Services/ExtService.php on line 35
{"Estado":"Cargado","Descripcion":"Documento generado. Ticket :201802665555249 Codigo: 0004 Proceso no definido por sunat","FechaHora":"2018-09-11 12:59:18","data":{"rsCodigo":"0004","rsDescripcion":"Ticket :201802665555249 Codigo: 0004 Proceso no definido por sunat"},"Total":1}
#####################################################################
ESTA RESPUESTA ES MEDIANTE SOAPUI
<#S#:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
Creo que estas confundiendo la ruta del servicio, FE_CONSULTA_CDR es para consultar el estado de una factura (+NCR, +NDB) , para consultar el estado de resumen de boletas /comunicacion de baja, se usa la misma ruta con la que envias facturas, ncr, ndb, resumen, bajas: FE_PRODUCCION, ese metodo getStatus
existe en See
, no necesitas implementarlo con ExtService
El success solo indica que la conexión con Sunat se realizó correctamente y se obtuvo respuesta. Por otro lado el codigo que retorna statusCode, puede tener los siguientes valores Los codigos que te indique en el otro issue, son para las respuestas de sunat relacionado al envio y cdr del comprobante.
Así es, pero tengo que hacer una correción, cuando haces getstatus en FE_PRODUCCION no siempre el code es 0, 98 ó 99, yo guardo en un log todas las consultas por getStatus y este es un ejemplo. [content] => [brGž‡±ŠË^....... ......R-205XXXXXXXXXXX-RA-20180910-000XX.xmlPK Q
[statusCode] => 99 ))
Tue, 11 Sep 2018 03:38:22 -0500stdClass Object ( [status] => stdClass Object ( [content] => [brGž‡±ŠË^ [statusCode] => 0127 )
)
Así que cuando dices que sólo envia los códigos (que mismo manual dice) es incorrecto. y para efectos prácticos el issuccess debería indicar éxito cuando realmente sea así, porque luego tienes que hacer doble consulta. ejm.
if($rsSunat->isSuccess()){
//Aquí tendrías que hacer el filtro a $code.. si es 0, 98, 99.. y otra vez las excepciones y/o rechazos
} else {
// muchas veces aquí también muestra errores soap con excepciones. (ejm password incorrecto).
var_dump($rsSunat->getError());
}
en cambio si haces la modificación que propuse (en sendbill, extservices) tendrías un issuccess con garantía que existe un CDR con estado 0 ó 99 y evitas hacer doble filtro a las excepciones.
En sendBill siempre devuelve un CDR, alli el isSuccess()
indicaria que tambien hay CDR, para el caso de getStatus, el código que devuelve 98 - En proceso, no seria valido colocar al success = false, porque no es un error, para el caso 99 y otros que no sean 0, si seria mas viable.
Entonces crees que debería haber una modificación.. yo pienso que sí, porque le das más trabajo al proceso.
Si solo quieres el CDR sin importar el código o isSuccess, validando que el campo getCdrZip
sea diferente de null seria suficiente para ti.
Lo que busco es que que "in_array($code, range(100 , 1999))" lo marque como error y no lo procese al isuccess como true, ya lo tengo implementado pero tal vez pueda quitar muchos dolores de cabeza a otros. Saludos.
y cual es la finalidad de eso, si lo que quieres es el CDR, eso es con getCdrZip
Aun asi tendré en cuenta tus sugerencias para futuros cambios, pero ahora la prioridad es el UBL 2.1
Si yo quiero solo el CDR hago con getCdrzip, pero yo no solo quiero el CDR sino el error que me pueda estar dando la sunat, te hago un ejemplo más.
if ($result->isSuccess() && !empty($result->getCdrResponse())) { //lo mismo q getCdrzip
//procesa sólo el $code del CDR... dentro de este CDR también hay $code con excepción (en otro post
ya lo mostré).. entonces vuelve a procesar una excepción; y aquí está el detalle, pienso que toda excepción
debe hacerse abajo cuando issuccess es false.
} else {
//pero aquí sunat también manda excepciones como te mostré en el log. ejm server ocupado, password, etc..
var_dump($result->getError()->getCode());
}
Tenemos que descomprimir el zip y extraer el xml y procesarlo para extraer el detalle del error. tambien estoy trabajando en eso.
Ya lo tengo hecho.. más tarde trataré de subirlo.
El jue., 13 de sep. de 2018 8:56 a. m., sysarp notifications@github.com escribió:
Tenemos que descomprimir el zip y extraer el xml y procesarlo para extraer el detalle del error. tambien estoy trabajando en eso.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/giansalex/greenter-sample/issues/29#issuecomment-421016405, or mute the thread https://github.com/notifications/unsubscribe-auth/ACr6WuTxm3ujhjkmcMAFV5Q_MZK7VfZ4ks5uamQLgaJpZM4Wi5WA .
No sería mejor poner en false a Success cuando el code de un ticket no es 0 ó 99.
Porque en la actualidad devuelve contradicciones y se tiene que hacer muchas condicionales... en cambio con esa modificación cuando detecta el code en ese rango lo cambia el Success a false, lo mismo se podría aplicar a BillSender (hasta se podría leer el CDR y según su code volver a poner false) y CDRstatus.