FACTURACIÓN CFD OMITIR DATOS.
93 views
Skip to first unread message
Antonio Sanchez
Sep 23, 2011, 3:45:40 PM9/23/11
to vfp-factura-electronica-mexico
Buenas tardes, tengo una duda, me hicieron una clase en PHP para el
sello electronica y demás, todo lo hace correctamente, validado ante
hacienda y demás, el problema radica en que con algunos datos de la
dirección del Receptor, a veces el sello me da incorrecto, no la sella
bien. Pero sin embargo, si le voy quitando datos a la cadena original,
los "opcionales" conforme voy intentando, por decir, a uno le quito el
estado, y pum, lo sella correctamente (validado ante hacienda), y así
sucesivamente, a algunos, les tengo que dejar solo lo indispensable,
que es rfc, nombre y país, para que mi sello sea válido.
La pregunta, bueno dos preguntas, son:
1. Esta bien lo que estoy haciendo? aunque mi cliente tenga todos los
datos, puedo quitarle los opcionales a la hora de la factura
electrónica?
2. En la representación impresa, como debe ir, Imprimo todos los datos
del cliente en el campo "CLIENTE", pero, en la cadena original, si
tuve que quitar datos, pues se imprime la cadena con la cual me
resultó valido el sello, es decir, la representación impresa, si tu la
lees, tiene todos los datos del cliente en la parte de arriba, pero si
te pones a ver la cadena original solo puede aparecer "XXX-XXX-XXXX|
VENTAS MOSTRADOR|MEXICO", no la dirección ni nada (es un ejemplo).
Agradecería si me pueden orientar o sacar de la duda.
Gracias y un saludo.
Antonio Sánchez.
sello electronica y demás, todo lo hace correctamente, validado ante
hacienda y demás, el problema radica en que con algunos datos de la
dirección del Receptor, a veces el sello me da incorrecto, no la sella
bien. Pero sin embargo, si le voy quitando datos a la cadena original,
los "opcionales" conforme voy intentando, por decir, a uno le quito el
estado, y pum, lo sella correctamente (validado ante hacienda), y así
sucesivamente, a algunos, les tengo que dejar solo lo indispensable,
que es rfc, nombre y país, para que mi sello sea válido.
La pregunta, bueno dos preguntas, son:
1. Esta bien lo que estoy haciendo? aunque mi cliente tenga todos los
datos, puedo quitarle los opcionales a la hora de la factura
electrónica?
2. En la representación impresa, como debe ir, Imprimo todos los datos
del cliente en el campo "CLIENTE", pero, en la cadena original, si
tuve que quitar datos, pues se imprime la cadena con la cual me
resultó valido el sello, es decir, la representación impresa, si tu la
lees, tiene todos los datos del cliente en la parte de arriba, pero si
te pones a ver la cadena original solo puede aparecer "XXX-XXX-XXXX|
VENTAS MOSTRADOR|MEXICO", no la dirección ni nada (es un ejemplo).
Agradecería si me pueden orientar o sacar de la duda.
Gracias y un saludo.
Antonio Sánchez.
Arturo Ramos
Sep 24, 2011, 12:34:33 PM9/24/11
to vfp-factura-ele...@googlegroups.com
Es raro lo que comentas Antonio, para comenzar como es eso de que le quitas datos y ya funciona, entiendo que se los quitas antes de sellar o vas sellando y quitando hasta que pasa las pruebas.
Ahora tu pregunta sobre la representación impresa es muy buena, se supone que debes representar de forma legible el contenido del XML, yo creo, salvo la mejor opinión del foro, que mientras lo que este en la cadena este bien representado, si pones más cosas no esta mal, y lo podemos aplicar con un poco de lógica, por ejemplo, si imprimes el logo de la empresa en la representación impresa, este logo no esta en el XML, también por ejemplo si pones un espacio para firma de Recibido o Acepto, esto tampoco está en el XML, así que si imprimes el resto de los datos del cliente no creo que sea problema, donde seguro que si es que no representes algo de lo que esta en el XML o que lo pongas diferente.
Explicanos más sobre el asunto de la validación, sería de mucha ayuda para nosotros que nos pases uno de esos XML que no pasan como válidos antes de que les quites datos, con eso te podremos ayudar mejor.
saludos.
Arturo Ramos
www.ircsasoftware.com.mx
Cancún, México.
Ahora tu pregunta sobre la representación impresa es muy buena, se supone que debes representar de forma legible el contenido del XML, yo creo, salvo la mejor opinión del foro, que mientras lo que este en la cadena este bien representado, si pones más cosas no esta mal, y lo podemos aplicar con un poco de lógica, por ejemplo, si imprimes el logo de la empresa en la representación impresa, este logo no esta en el XML, también por ejemplo si pones un espacio para firma de Recibido o Acepto, esto tampoco está en el XML, así que si imprimes el resto de los datos del cliente no creo que sea problema, donde seguro que si es que no representes algo de lo que esta en el XML o que lo pongas diferente.
Explicanos más sobre el asunto de la validación, sería de mucha ayuda para nosotros que nos pases uno de esos XML que no pasan como válidos antes de que les quites datos, con eso te podremos ayudar mejor.
saludos.
Arturo Ramos
www.ircsasoftware.com.mx
Cancún, México.
FLX Martinez
Sep 24, 2011, 1:04:38 PM9/24/11
to vfp-factura-ele...@googlegroups.com
Saludos.
En teoria la representación impresa de tu factura debe obtener los elementos del XML que ha sido sellado con todos sus datos, la cadena Original no debiera editarse en ningun momento ya que lo obtienes directamente de la Transformación de XSLT. Asi que esta mal lo que haces quitando datos que mandas a sellar y generando una representacion impresa diferente.
Miralo de esta forma, algun validador de XML y que tambien genere una representación impresa de tu CFD no va a generar los mismos datos que tienes en la representación impresa que tu generas y eso te va a traer muchos problemas.
El problema estuvo en que la clase que no se interpretó bien la información de los nodos opcionales. Si no esta el dato y no necesita estar en la representación impresa entonces se omite, pero si la información existe y es util, necesario para el cliente entonces hay que manifestarlo en el XML y en el PDF.
La clase de php debiera admitir todos los elementos e ir eliminando nodos que no se encuentren rellenados, opinion personal.
Saludos
--
Felix Martinez
Bluit Consulting S de RL de CV
En teoria la representación impresa de tu factura debe obtener los elementos del XML que ha sido sellado con todos sus datos, la cadena Original no debiera editarse en ningun momento ya que lo obtienes directamente de la Transformación de XSLT. Asi que esta mal lo que haces quitando datos que mandas a sellar y generando una representacion impresa diferente.
Miralo de esta forma, algun validador de XML y que tambien genere una representación impresa de tu CFD no va a generar los mismos datos que tienes en la representación impresa que tu generas y eso te va a traer muchos problemas.
El problema estuvo en que la clase que no se interpretó bien la información de los nodos opcionales. Si no esta el dato y no necesita estar en la representación impresa entonces se omite, pero si la información existe y es util, necesario para el cliente entonces hay que manifestarlo en el XML y en el PDF.
La clase de php debiera admitir todos los elementos e ir eliminando nodos que no se encuentren rellenados, opinion personal.
Saludos
2011/9/23 Antonio Sanchez <sanchez.a...@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "vfp-factura-electronica-mexico" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a vfp-factura-ele...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a vfp-factura-electroni...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/vfp-factura-electronica-mexico?hl=es.
--
Felix Martinez
Bluit Consulting S de RL de CV
FLX Martinez
Sep 24, 2011, 1:14:41 PM9/24/11
to vfp-factura-ele...@googlegroups.com
Saludos Arturo
Lo de la información de la representación impresa del CFD(i).
Pienso que la información que esta regulada en el Anexo 20 debe ir de acuerdo a sus especificaciones aunque sean opcionales. Logo, leyendas, observaciones, Firmas, numeros de pagina, etc. corresponden a información que en ningun momento especifica el SAT como y en donde deben ir pero es información necesaria para el cliente asi que lo dejamos solo en la representación impresa. Salvo mejor opinion del Foro.
Saludos
Felix Martinez
Lo de la información de la representación impresa del CFD(i).
Pienso que la información que esta regulada en el Anexo 20 debe ir de acuerdo a sus especificaciones aunque sean opcionales. Logo, leyendas, observaciones, Firmas, numeros de pagina, etc. corresponden a información que en ningun momento especifica el SAT como y en donde deben ir pero es información necesaria para el cliente asi que lo dejamos solo en la representación impresa. Salvo mejor opinion del Foro.
Saludos
Felix Martinez
2011/9/24 Arturo Ramos <irc...@gmail.com>
--
Has recibido este mensaje porque estás suscrito al grupo "vfp-factura-electronica-mexico" de Grupos de Google.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/vfp-factura-electronica-mexico/-/YxVcn6KI2VQJ.
Para publicar una entrada en este grupo, envía un correo electrónico a vfp-factura-ele...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a vfp-factura-electroni...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/vfp-factura-electronica-mexico?hl=es.
Arturo Ramos
Sep 24, 2011, 5:45:40 PM9/24/11
to vfp-factura-ele...@googlegroups.com
Hola Felix,
Si, de acuerdo, la información regulada debe ir de acuerdo a lo especificado, lo que el compañero Antonio pregunta es que si en la representación impresa puede poner información que no esta en la cadena original, osea en el XML; yo digo que no debe haber problema si en tu representación impresa pones la dirección el teléfono, u otra información que no está en tu XML siempre que cumplas con lo especificado por ejemplo que lo que debe estar, datos obligados, esos si esten y los que no son obligatorios y los pongas en tu representación, los pongas de acuerdo a las especificaciones.
No se que opinen... por eso se me hizo interesante la pregunto...
por ejemplo, he visto representaciones impresas donde en los conceptos ponen información adicional como garantías, no. de serie o cosas así y si las buscas en la cadena original no estan; quizá esto sea más claro que el logo, la firma, etc.
Bueno, insisto, interesante pregunta.
Saludos.
Si, de acuerdo, la información regulada debe ir de acuerdo a lo especificado, lo que el compañero Antonio pregunta es que si en la representación impresa puede poner información que no esta en la cadena original, osea en el XML; yo digo que no debe haber problema si en tu representación impresa pones la dirección el teléfono, u otra información que no está en tu XML siempre que cumplas con lo especificado por ejemplo que lo que debe estar, datos obligados, esos si esten y los que no son obligatorios y los pongas en tu representación, los pongas de acuerdo a las especificaciones.
No se que opinen... por eso se me hizo interesante la pregunto...
por ejemplo, he visto representaciones impresas donde en los conceptos ponen información adicional como garantías, no. de serie o cosas así y si las buscas en la cadena original no estan; quizá esto sea más claro que el logo, la firma, etc.
Bueno, insisto, interesante pregunta.
Saludos.
Antonio Sanchez
Sep 27, 2011, 11:24:12 AM9/27/11
to vfp-factura-ele...@googlegroups.com
Buenas tardes,
De antemano agradezco su ayuda, y en efecto, los campos "opcionales" de la cadena original, pueden o no ir, y en la representación Impresa, puedes poner lo que quieras, siempre y cuando no influyan dentro de la cadena. Como dice Arturo, los números de serie (los cuales también manejo) pueden imprimirse, y en la cadena original no hay ningún campo para agregarlos.
De todas formas he de corroborar con el SAT esta información, pero hasta ahora y en todos los foros me han dicho exactamente lo mismo, que la cadena debe ir con los campos "requeridos" y los opcionales es a gusto del cliente jejejeje. Por otro lado, muchos de los sistemas que he visto y/o pedido información, a la hora de hacer la cadena original hacen maraña y media para poder validar el sello, sin embargo y aún así, se pueden presentar problemas a la hora de sellar la factura, mi sistema general que uso (microsip) he intentado validar algunos xml donde la dirección esta incorrecta, y a pesar de que los sella correctamente (con longitud de 172 caracteres) no pasa el validador de hacienda, y es un sistema muy reconocido.
En fin, todo esto lo corroboro y les informo amigos, de todas maneras muchisimas gracias y sabía que no andaba tan perdido.
Saludos.
Oscar Garcia
Sep 27, 2011, 3:03:43 PM9/27/11
to vfp-factura-ele...@googlegroups.com
Saludos...
Algo similar me sucedía a mi, es decir, no me permitia factruarle a los clientes con toda su dirección, y lo que encontré fue que en algunos campos de la dirección del cliente había basura como tabuladores, caracteres especiales, muchos espacios vacios despues de los datos, etc. Lo que optamos por hacer fue que cuando se presentó el caso, borrarmos los datos del cliente y lo volvimos a capturar correctamente y listo.
Hugo C.
Sep 27, 2011, 3:41:59 PM9/27/11
to vfp-factura-electronica-mexico
Esto que comenta Oscar tambien me ocurrio
en algunas ocasiones (espacios de mas, caracteres raros, etc.) .
Lo solucione con la funcion STRTRAN() o CHRTRAN().
Tambien me ayudo comparar la cadena que genera el
sat del XML con la que generan mis sistemas.
Saludos.
Saludos.
en algunas ocasiones (espacios de mas, caracteres raros, etc.) .
Lo solucione con la funcion STRTRAN() o CHRTRAN().
Tambien me ayudo comparar la cadena que genera el
sat del XML con la que generan mis sistemas.
Saludos.
Saludos.
GAZ
Sep 27, 2011, 9:54:37 PM9/27/11
to vfp-factura-electronica-mexico
Es muy importante el orden que le des a la estructura del XML, debe de
ser igual al orden al generar tu cadena, checa este dato no creo que
sea la omision de datos, claro como te comenta el campañero, los
dobles espacios y los caracteres no permitidos <,>,&.
> > cliente y lo volvimos a capturar correctamente y listo.- Ocultar texto de la cita -
>
> - Mostrar texto de la cita -
ser igual al orden al generar tu cadena, checa este dato no creo que
sea la omision de datos, claro como te comenta el campañero, los
dobles espacios y los caracteres no permitidos <,>,&.
>
> - Mostrar texto de la cita -
F G
Sep 28, 2011, 8:43:30 AM9/28/11
to vfp-factura-ele...@googlegroups.com
Hola, yo genero una tabla en VFP con todos los datos para producir el xml, y la cadena original, es muy importante el orden te envio copia de la estructura de la tabla como veras todos los campos para el proceso de fe son string, los que son de otro tipo no intervienen en el proceso, tambien te envio el codigo con el cual genero la cadena original observa el orden que llevan, como te comentan algunos compañeros revisa que no tenga "chirimbolos" tu cadena original, espero te sirva, Saludos
--
Has recibido este mensaje porque estás suscrito al grupo "vfp-factura-electronica-mexico" de Grupos de Google.
Arturo Ramos
Sep 28, 2011, 1:01:03 PM9/28/11
to vfp-factura-ele...@googlegroups.com
Todo lo que mencionan es verdad, es un caso común sobre todo en sistemas adaptados a CFD donde sus BD no estaban pensadas para estas necesidades y donde era posible agregar caracteres que en ese momento no eran problemáticos.
Si utilizas la clase del foro, cada valor que le mandas a la clase que representa un nodo dentro de tu XML es 'reparodo' antes de formar parte del nodo.
Esta es la información de la función en la clase; las adaptaciones son del compañero Victor Espina
*-- _fixStr (Metodo)
* Recibe una cadena y realiza los siguientes cambios:
* a) Sustituye cualquier caracter invalido por el caracter "."
* b) Elimina los espacios en blanco al inicio y al final de la cadena
* c) Elimina cualquier secuencia de espacios en blanco repetidos dentro de la cadena
* d) Si la cadena resultante contiene al menos 1 caracter, se le anade la cadena
* indicada en el parametro pcSep
*
* La funcion fue reeacrita a partir de la funcion QtarChrInval() de Halcon Divino, a fin
* de simplificar el codigo y depurarlo. El metodo utilizado por Halcon Divino para incluir
* cada elemento en la cadena original implicaba una doble llamada a QtarChrInval() para
* cada valor en la cadena:
*
* cStr = cStr + Iif(Len(QtarChrInval(valor)) = 0, "" ,QtarChrInval(valor) + "|")
*
* Este codigo se simplifica y mejora haciendo una sola invocacion a fixStr:
*
* cStr = cStr + THIS._fixStr(valor, "|")
*
* Adicionalmente se incluyo codigo para permitir que la funcion reciba cualquier tipo
* de datos, haciendo la conversion adecuada segun el tipo. En los casos donde el parametro
* de entraada no sea un string, no se realiza la verificacion de caracteres invalidos
*
...
El código completo lo pueden ver en la clase que pueden descargar, la liga de descarga está en el primer post de este foro o del repositorio de github CFD-CFDI-con-VFP.
Si utilizas la clase del foro, cada valor que le mandas a la clase que representa un nodo dentro de tu XML es 'reparodo' antes de formar parte del nodo.
Esta es la información de la función en la clase; las adaptaciones son del compañero Victor Espina
*-- _fixStr (Metodo)
* Recibe una cadena y realiza los siguientes cambios:
* a) Sustituye cualquier caracter invalido por el caracter "."
* b) Elimina los espacios en blanco al inicio y al final de la cadena
* c) Elimina cualquier secuencia de espacios en blanco repetidos dentro de la cadena
* d) Si la cadena resultante contiene al menos 1 caracter, se le anade la cadena
* indicada en el parametro pcSep
*
* La funcion fue reeacrita a partir de la funcion QtarChrInval() de Halcon Divino, a fin
* de simplificar el codigo y depurarlo. El metodo utilizado por Halcon Divino para incluir
* cada elemento en la cadena original implicaba una doble llamada a QtarChrInval() para
* cada valor en la cadena:
*
* cStr = cStr + Iif(Len(QtarChrInval(valor)) = 0, "" ,QtarChrInval(valor) + "|")
*
* Este codigo se simplifica y mejora haciendo una sola invocacion a fixStr:
*
* cStr = cStr + THIS._fixStr(valor, "|")
*
* Adicionalmente se incluyo codigo para permitir que la funcion reciba cualquier tipo
* de datos, haciendo la conversion adecuada segun el tipo. En los casos donde el parametro
* de entraada no sea un string, no se realiza la verificacion de caracteres invalidos
*
...
El código completo lo pueden ver en la clase que pueden descargar, la liga de descarga está en el primer post de este foro o del repositorio de github CFD-CFDI-con-VFP.
Reply all
Reply to author
Forward
0 new messages