FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#921
|
|||
|
|||
Cita:
Si después de la (primera) firma, los datos se modifican fuera del poder del firmante, entonces la firma resultará inválida; pero técnicamente los datos modificados se pueden supuestamente firmar de nuevo (nota: es delito hacerlo; también es delito proponer de hacerlo) si lo hace el firmante... El día o la hora no vienen en la firma; solo se puede añadir una marca (o sello) de tiempo a lo que se está firmando. Si usas Veri*factu, la firma la realiza efectivamente Hacienda y sus sistema dan la hora y por tanto Hacienda tiene la garantía que los datos no se modifican en el momento de la generación. Si es otra clase de SIF, el programador puede añadir una marca de tiempo a la hora de firmar; así sí se garantiza que no se modifican después (a no ser que se manipulen las marcas de tiempo; otro probable delito). Pero la marca de tiempo no es una obligación en lo que sabemos ahora de las especificaciones, entre otras cosas porque no hay un sistema de marca de tiempo disponible que resulte de agradecimiento tanto de Hacienda como de todos los grandes productores de software. |
#922
|
|||
|
|||
¿Uh? ¿Dónde está escrito que un proveedor de sistema de facturación debe proponer ejercitar, o no, la opción propuesta en el artículo 15, acudir al Veri*factu?
Cierto que el cliente puede elegir. Pero una posibilidad de elección es decidir entre dos proveedores. |
#923
|
|||
|
|||
No entiendo lo que dices
|
#924
|
|||
|
|||
Cita:
Luego, los artículos 8.2 a y b obligan a usar un «proceso técnico fiable» y a que «Todos los datos registrados deberán encontrarse correctamente fechados, indicando el momento en que se efectúa el registro.» Si por «registros originales» tu entiendes «registros con los datos originalmente grabados», entonces sí, están pidiendo esto (con la excepción de la palabra «parecido»); tanto a Hacienda para la aplicación quien soporta Veri*factu como a cualquier otro proveedor de SIF que usan el método del registro local encadenado y firmado. |
#925
|
|||
|
|||
A ver si me explico mejor... (la énfasis es mía)
Cita:
Cita:
La opción la tiene el cliente; pero no dentro del ámbito del programa, sino dentro del ámbito de sus obligaciones de tributación, que es más amplia. Por ejemplo, en el artículo 15 está escrito «podrán remitir [...] todos los registros de facturación generados por los sistemas informáticos» (mi énfasis); no «generados por [strike]el sistema informático[/strike]». Última edición por antoine0 fecha: 14-12-2023 a las 17:53:36. Razón: aclaración sobre «tributación» |
#926
|
|||
|
|||
Cita:
|
#927
|
|||
|
|||
Entonces como proveedores podemos hacer un sistema verifactu, no verifactu o con las dos opciones. Creo que se puede explicar al cliente q un sistema no verifactu complica el tema y puede finalizar con requerimientos. Podían haber definido solo verifactu como sistema único y no enredar mas
|
#928
|
|||
|
|||
Cumplir Articulo 8.3 SIF Veri*Factu
Yo creo que un SIF Veri*Factu tampoco tiene que cumplir con el Articulo 8.3 ya que al principio del BOE dice textual: "Con ser importantes, los anteriores propósitos encuentran su sentido en un objetivo aún más amplio que desde las organizaciones internacionales (OCDE y Unión Europea) han dado en llamar «cumplimiento tributario por diseño»." y luego refiriéndose al cumplimiento por diseño dice:
"Asimismo, el texto reglamentario prevé la posibilidad de que, voluntariamente, los obligados tributarios remitan inmediatamente a la Administración tributaria, de forma automática y segura por medios electrónicos, todos los registros de facturación generados en sus sistemas informáticos, en cuyo caso se entenderá que esos sistemas informáticos ya cumplen por diseño los requisitos técnicos anteriormente mencionados." y luego en el CAPITULO III cuando habla de Sistemas de emisión de facturas verificables dice: "A los efectos de este Reglamento, se presumirá que los «Sistemas de emisión de facturas verificables» cumplen por diseño los requisitos establecidos en el artículo 8 de este Reglamento, y por lo tanto tampoco les será de aplicación lo dispuesto en el apartado 2 del artículo 14 de este Reglamento." |
#929
|
|||
|
|||
Cita:
[/i]Aquellos sistemas informáticos indicados en la letra a) del artículo 7 de este Reglamento que, cumpliendo con todas las obligaciones que impone este Reglamento y de acuerdo a las especificaciones técnicas que se establezcan[i] O sea, por un lado dicen que si es VeriFactu no tienes que cumplir pero por otro dice que para ser VeriFactu debes cumplir con todo. |
#930
|
|||
|
|||
Cita:
En lugar de «finalizar con requerimientos», que me parece demasiado negativo, yo pondría que la empresa que no quiere Veri*factu se está colgando a si misma una diana enorme a la atención de los inspectores de Hacienda. Claramente está hecho para ser disuasivo, un poco como el sistema del «criterio de caja» para el IVA: algunas empresas lo necesitan de verdad y no pueden vivir sin él, pero la intención de Hacienda es que se quede marginal. Cita:
|
#931
|
|||
|
|||
Cita:
Luego sobre lo dicho en el artículo 16.2, no sé exactamente cómo leer «se presumirá que [...] cumplen por diseño los requisitos establecidos en el artículo 8». Si te eximen del sistema de comunicación de los registros (14.2) sin quitarte la consultación en interactivo de los registros y de los eventos (14.1), significa que debes tener en tu programa tales archivos, de registros y de eventos, ¿no? Y el 8.3 solo dice que debe estar un registro de eventos... (y que su contenido y diseño estarán en el futuro O.M.) Ahora bien, si resulta que el registro de eventos solo registra las operaciones de grabar, firmar, iniciar serie y poco más, es cierto que son las operaciones que se pueden deducir de los registros de Veri*fatu y por tanto efectivamente ya no es realmente necesario un registro de eventos en el programa en casa del cliente (con la condición para cumplir el 14.1 de implementar una interfaz viva de consulta del Veri*factu). Como ya se ha dicho varias veces, en realidad debemos esperar a leer la O.M. para entender realmente como comérselo. |
#932
|
|||
|
|||
En un sistema que va con Veri*factu, en realidad el SIF está compuesto por la reunión de tu programa y del programa Veri*factu de Hacienda con su propia base de datos, su sistema de firma y sello de tiempo con los CSV etc. Lo que dice el 16.2 es que la parte requerida por el artículo 8 está en efecto cumplida por el programa Veri*factu.
|
#933
|
|||
|
|||
Cita:
¿A qué te refieres de si os está funcionando? Yo estoy intentando utilizarlos desde Delphi 2007 y me salta un mensaje de errro de Empty Documento cuando hago la llamada para dar de alta una factura. Gracias. |
#934
|
|||
|
|||
Cita:
Estoy intentando importar los wsdl desde dos versiones diferentes de Delphi: + Delphi 2007, al intentar importarlos me dice: Error [Empty document]. + Delphi 11, importar me los permite importar, pero luego, al compilar me da error en dos líneas en las que me dice que los literales de tipo string no pueden medir más de 255 caracteres y de ahí no paso. ¿Alguien los ha importado recientemente?. ¿Ha podido sin problema? Gracias y un saludo. Edito: He retocado las líneas que se suponen que miden demasiado (no se que implicaciones traerá luego), pero el caso es que al darle a enviar una petición, me dice "URL Pendiente de definir", con lo cual de momento tampoco podemos probar nada por este "lado". Última edición por nincillo fecha: 15-12-2023 a las 14:01:21. |
#935
|
|||
|
|||
Cita:
Lo que hice en ese momento para continuar con las pruebas fue descomponer la línea en varias cadenas y funcionó. Pude compilar y continuar con mis pruebas. se convirtió en
Si nadie ofrece una solución más elegante, a mí me funcionó. Saludos |
#936
|
|||
|
|||
Cita:
Pero de momento, pocas pruebas de envío se pueden hacer porque no tienen definida la url. ¿Verdad?. |
#937
|
|||
|
|||
Cita:
Me funcionó el "truco" que me sugeriste. Muchas gracias de nuevo. Ahora he atascado en otro punto. A ver si alguien me puede ayudar. Estoy empezando a rellenar los diferentes apartados de la factura antes de enviarla y he atascado al llegar al punto "Desglose", que se supone que es un Array of Detail. Este es el código que llevo desarrollado hasta ahora. Código:
procedure TForm2.BtnEnvioFacturaClick(Sender: TObject); var regFactura : FacturasEmitidasType; result : Array_Of_RespuestaExpedidaType; arrayFacturas : Array_Of_FacturasEmitidasType; arrayDetalles : array of DetalleType; detalle : DetalleType; begin regFactura := FacturasEmitidasType.Create; regFactura.DatosControl := DatosControlType.Create; regFactura.RegistroFacturacion := RegistroFacturacionType.Create; regFactura.RegistroFacturacion.PeriodoLiquidacion := PeriodoLiquidacion.Create; regFactura.RegistroFacturacion.PeriodoLiquidacion.Ejercicio := '23'; regFactura.RegistroFacturacion.PeriodoLiquidacion.Periodo := TipoPeriodoType(1); // Empieza a contar desde 0 regFactura.RegistroFacturacion.IDFactura := IDFacturaExpedidaType.Create; regFactura.RegistroFacturacion.IDFactura.NumSerieFacturaEmisor := '23/123456'; regFactura.RegistroFacturacion.IDFactura.FechaExpedicionFacturaEmisor := '31/12/23'; regFactura.RegistroFacturacion.IDFactura.IDEmisorFactura := IDEmisorFactura2.Create; regFactura.RegistroFacturacion.IDFactura.IDEmisorFactura.NIF := '3333333'; regFactura.RegistroFacturacion.DescripcionOperacion := 'vneta de mercaderías'; regFactura.RegistroFacturacion.Desglose := DesgloseType.Create(); detalle:= DetalleType.Create; detalle.CuotaRepercutida := '100'; detalle.TipoImpositivo := '21'; SetLength(arrayDetalles, 1); arrayDetalles[0] := detalle; regFactura.RegistroFacturacion.Desglose[0] := detalle; try SetLength(arrayFacturas, 1); arrayFacturas[0] := regFactura; result := GetsfSOAP(true, '', HTTPRIO1).AltaFactuSistemaFacturacion(arrayFacturas); finally regFactura.Destroy; end; end; |
#938
|
|||
|
|||
y si pruebas con
Código:
setlength(regfactura.RegistroFacturacion.desglose,1); antes de hacer Código:
regFactura.RegistroFacturacion.Desglose[0] := DesgloseType.Create(); |
#939
|
|||
|
|||
Cita:
Código:
// <- Rellenos los datos de las diferentes bases DetalleType detalle1:= DetalleType.Create; detalle1.ClaveRegimen := IdOperacionesTrascendenciaTributariaType._01; detalle1.CalificacionOperacion := CalificacionOperacionType.S1; detalle1.OperacionExenta := OperacionExentaType.E0; detalle1.TipoImpositivo := '21'; detalle1.BaseImponibleOimporteNoSujeto := '123'; detalle1.BaseImponibleACoste := '111'; detalle1.CuotaRepercutida := '100'; detalle1.TipoRecargoEquivalencia := '0'; detalle1.CuotaRecargoEquivalencia := '0'; detalle2:= DetalleType.Create; detalle2.CuotaRepercutida := '200'; detalle2.TipoImpositivo := '10'; // Los añado todos en un array SetLength(arrayDetalles, 2); arrayDetalles[0] := detalle1; arrayDetalles[1] := detalle2; // Cargo el array con todas las posibles bases en el apartado Desglose regFactura.RegistroFacturacion.Desglose := arrayDetalles; // := deta .Create; Por favor, ¿alguien que tenga Delphi 2007 podría intentar cargar a día de hoy los WSDL haber si puede o si le da error de "Document Empty"?. Yo recuerdo haberlos importado hace unos meses sin problema, pero algo han modificado desde entonces que ahora no soy capaz. Gracias. |
#940
|
|||
|
|||
Cita:
De todas formas voy a probarlo. Muchas gracias. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Hijo de Informáticos | gluglu | Humor | 3 | 13-03-2007 11:05:35 |
Adictos informaticos ... | Trigger | Humor | 2 | 11-10-2004 12:18:32 |
Nosotros los Informáticos | Trigger | Humor | 1 | 10-10-2004 14:58:09 |
Patrón de los Informáticos. | obiwuan | Varios | 20 | 10-09-2003 14:44:54 |
Chistes Informaticos | jhonny | Humor | 2 | 11-08-2003 21:59:09 |
|