Demo con código Verifactu.dll para (delphi 7)

[mqm]

Espero los tiempo indicado y mas. Ahora acabo de subie 15 de golpe y han pasado.
Espero que no se repita. Gracias por todo.

[seccion_31]

a mi tambien me han pasado errores al enviar 15 o 20 de golpe y luego en otro paquete se han enviado bien. Enviando 1, 2,3 nunca he tenido problemas. Un poco random cuantos mas envias.

Por otro lado antes de publicar la version 2.1 tengo algunas dudas sobre esto: (Los añadire, pero querria vuestra opinion)
Ahora mismo no los estoy enviando, y los registros son aceptados.
Pero dice que es obligatorio y en la hoja de calculo informativa NO aparecen en rojo.

TipoUsoPosibleMultiOT
Especifica si el sistema informático de facturación permite llevar independientemente la facturación de varios obligados tributarios (valor "S") o solo de uno (valor "N"). Obligatorio en registros de facturación de alta y de anulación, y opcional en registros de evento.

Entiendo que es para indicar que el programa permite en teoria la facturacion de varios emisores.

IndicadorMultiplesOT
Indicador de que el sistema informático, en el momento de la generación de este registro, está soportando la facturación de más de un obligado tributario. Este valor deberá obtenerlo automáticamente el sistema informático a partir del número de obligados tributarios contenidos y/o gestionados en él en ese momento, independientemente de su estado operativo (alta, baja...), no pudiendo obtenerse a partir de otra información ni ser introducido directamente por el usuario del sistema informático ni cambiado por él. El valor "N" significará que el sistema informático solo contiene y/o gestiona un único obligado tributario (de alta o de baja o en cualquier otro estado), que se corresponderá con el obligado a expedir factura de este registro de facturación. En cualquier otro caso, se deberá informar este campo con el valor "S". Obligatorio en registros de facturación de alta y de anulación, y opcional en registros de evento.

Entiendo que es para indicar si en el programa de facturacion tienes registrados al menos dos emisores. (envien registros o no), pero que en tu base de datos figuran. Es decir un programa tiene dos emisores en su bd, envia registros de alta de uno de ellos, pero al tener dos emisores registrados este campo sera true.

¿porque no aparecen en rojo en la hoja de calculo? (como obligatorios)

¿estoy interpretando bien esos campos?

Saludos !

[seccion_31]

otra cosa que no entiendo

en el portal de pruebas cuando consultas una factura, al final en el encadenamiento ¿porque colocan el NIF de la factura anterior? los encadenamientos son del mismo obligado tributario entiendo que del mismo nif, dato que saca de su registro de facturas ya enviadas... no veo porque coloca ese dato.

lo que no coloca en el portal de pruebas es el numero de factura rectificada. Yo no lo he visto.

saludos !

[ramherfer]

Empezado por seccion_31

Por otro lado antes de publicar la version 2.1 tengo algunas dudas sobre esto: (Los añadire, pero querria vuestra opinion)
Ahora mismo no los estoy enviando, y los registros son aceptados.
Pero dice que es obligatorio y en la hoja de calculo informativa NO aparecen en rojo.



Entiendo que es para indicar que el programa permite en teoria la facturacion de varios emisores.




Entiendo que es para indicar si en el programa de facturacion tienes registrados al menos dos emisores. (envien registros o no), pero que en tu base de datos figuran. Es decir un programa tiene dos emisores en su bd, envia registros de alta de uno de ellos, pero al tener dos emisores registrados este campo sera true.

¿porque no aparecen en rojo en la hoja de calculo? (como obligatorios)

¿estoy interpretando bien esos campos?

Saludos !

TipoUsoPosibleMultiOT
Yo los dejaría y que la aplicación informe en el momento del envío. En mi aplicación informa de los OT que se están gestionando en el StatusBar. con lo que si es mayor de 1 debería ser S y si es = 1 debería de ser N. Esto sería bien fácil que lo envíe y gestione la aplicación. Normalmente hoy en día casi todos los ERP son multiempresa.



IndicadorMultiplesOT
Idem de lo mismo.

Mi humilde opinión cuanta más información de el ERP al respecto, menos intento por parte de los usuarios para intentos desesperados de ocultar información y mejor cara a la AEAT que vea que no se está tratando de ocultar ningún dato. Sea obligatorio o no si se envía, mejor que mejor.

Un saludo,

[delphiGar]

Empezado por seccion_31

Ahora mismo no los estoy enviando, y los registros son aceptados.
Pero dice que es obligatorio y en la hoja de calculo informativa NO aparecen en rojo.

Entiendo que es para indicar que el programa permite en teoria la facturacion de varios emisores.

Entiendo que es para indicar si en el programa de facturacion tienes registrados al menos dos emisores. (envien registros o no), pero que en tu base de datos figuran. Es decir un programa tiene dos emisores en su bd, envia registros de alta de uno de ellos, pero al tener dos emisores registrados este campo sera true.

¿porque no aparecen en rojo en la hoja de calculo? (como obligatorios)

¿estoy interpretando bien esos campos?

Saludos !

El campo TipoUsoPosibleMultiOT es para indicar si tu programa puege gestionar mas de un OT y el campo IndicadorMultiplesOT es para indicar si lo esta haciendo.

Si tu programa puede gestionar varios OT y tienes un solo OT seria:

TipoUsoPosibleMultiOT=S
IndicadorMultiplesOT=N

Si tu programa puede gestionar varios OT y tiene dos o mas:

TipoUsoPosibleMultiOT=S
IndicadorMultiplesOT=S

Si tu programa solo admite un OT:

TipoUsoPosibleMultiOT=N
IndicadorMultiplesOT=N

[jlmoli_67]

Buenas,
Si tu programa puede gestionar varios OT y tiene dos o mas:
Código:
TipoUsoPosibleMultiOT=S IndicadorMultiplesOT=S
En este caso supongo que un mismo sif puede encargarse de enviar de forma independiente (primero una empresa, luego otra, ....) los registros de facturacion, no?

[seccion_31]

Empezado por jlmoli_67

Buenas,
Si tu programa puede gestionar varios OT y tiene dos o mas:
Código:
TipoUsoPosibleMultiOT=S IndicadorMultiplesOT=S
En este caso supongo que un mismo sif puede encargarse de enviar de forma independiente (primero una empresa, luego otra, ....) los registros de facturacion, no?

gracias por las respuestas ! esto sera novedad en la 2.1

En mi caso particular desde dos puestos podrian enviar a la vez, siempre que el emisor sea distinto. (con un nivel muy muy bajo de facturas emitidas). Ni se va a dar.

[seccion_31]

ahora hay otra cosa que me preocupa.

y esto deberia preocuparnos a todos los que usamos el componente.

el uso del stack y los arrays.

Actualmente (2.0) soportamos tipo de operacion con un maximo de 255 caracteres para un array de envio de 1000 facturas. Cuando en realidad deberian ser 500 digitos. Eso esta mal. (yo no lo veo bien).

He conseguido colocar el widestring que soporta ya los 500 digitos para un array de 500 facturas. Creo que es mejor enviar 500 facturas correctas que 1000 no muy bien. (cortadas a 255).

Cuando he tratado de forzar esos limites, empieza a comportarse de forma erratica, incluso con errores de proteccion general. Creo que la limitacion viene en la consulta, porque pasan por el stack de la DLL a la aplicacion, no lo se muy bien. Con la 3.0 sacandolo del stack y colocando el evento (ver abajo), quizas quedaria corregido y podriamos volver a las 1000 de envio.

Deberiamos someter al componente 2.1 cuando este publicado, a una prueba de stress simulando 500 facturas con tipos de operacion de 500 digitos. (pienso que hacerlo en modo simulado sin enviar seria suficiente y analizar que pasa).


¿que opiniais?



Por otro lado creo que para la version 3 voy a incorporar un evento para recibir las consultas.

En una sola pagina de consulta te pueden enviar hasta 10.000 registros, pero el componente solo soporta 1000. Con un evento se podrían recibir los 10.000 sin problemas. Sin soportar paginacion creo que ya es mas que suficiente para un periodo de consulta y un emisor "normal".

de nuevo, ¿que opiniais?

[ramherfer]

Empezado por seccion_31

ahora hay otra cosa que me preocupa.

y esto deberia preocuparnos a todos los que usamos el componente.

el uso del stack y los arrays.

Actualmente (2.0) soportamos tipo de operacion con un maximo de 255 caracteres para un array de envio de 1000 facturas. Cuando en realidad deberian ser 500 digitos. Eso esta mal. (yo no lo veo bien).

He conseguido colocar el widestring que soporta ya los 500 digitos para un array de 500 facturas. Creo que es mejor enviar 500 facturas correctas que 1000 no muy bien. (cortadas a 255).

Cuando he tratado de forzar esos limites, empieza a comportarse de forma erratica, incluso con errores de proteccion general. Creo que la limitacion viene en la consulta, porque pasan por el stack de la DLL a la aplicacion, no lo se muy bien. Con la 3.0 sacandolo del stack y colocando el evento (ver abajo), quizas quedaria corregido y podriamos volver a las 1000 de envio.

Deberiamos someter al componente 2.1 cuando este publicado, a una prueba de stress simulando 500 facturas con tipos de operacion de 500 digitos. (pienso que hacerlo en modo simulado sin enviar seria suficiente y analizar que pasa).


¿que opiniais?



Por otro lado creo que para la version 3 voy a incorporar un evento para recibir las consultas.

En una sola pagina de consulta te pueden enviar hasta 10.000 registros, pero el componente solo soporta 1000. Con un evento se podrían recibir los 10.000 sin problemas. Sin soportar paginacion creo que ya es mas que suficiente para un periodo de consulta y un emisor "normal".

de nuevo, ¿que opiniais?

Por mi parte, aunque son cifras que mi aplicación en estos momentos son inimaginables, y que tampoco tengo un conocimiento extremo como para dar una opinión acertada, cualquier cosa que sea una mejora me parece correcta, no lo siguiente. Y por la lógica de la explicación siempre será mejor enviar menos pero correcto que más y que de problemas.

Aprovecho para realizar una observación. Teniendo el siguiente desglose que no debería ser, pero se podría dar el caso y a nivel de aplicación es totalmente correcto:

<Desglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>459.00</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>96.39</CuotaRepercutida>
</DetalleDesglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>722.50</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>151.73</CuotaRepercutida>
</DetalleDesglose>
</Desglose>
<CuotaTotal>248.12</CuotaTotal>
<ImporteTotal>1333.23</ImporteTotal>

Los codigos de iva los tengo codificados y en un albarán por error se asignó un codigo de iva distinto pero que iva tambien al 21%. La cuestión es que en una factura iban dos lineas con el 21% una con el codigo 01 y otra con el codigo 21 (Ya digo que es un error pero que debía haber sido aceptado y teniendo la base imponible bien y el total factura tambien), en el importe total se puede observar que falta sumar la primera linea de iva, cuando en la factura estaba incluidas ambas lineas y el total factura era 1429,62.

No he podido saber por que la primera cuota no se agregó al total factura. Desconozco si ha sido un filtro de la AEAT al haber un segundo registro de iva con el mismo porcentaje.