|
Cita:
Importe el wdsl del soap con la version 1.2 y a continuacion hice lo que comentas, o sea sustitui Código:
InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioSOAP12);Código:
InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioDocument); |
Cita:
|
duda
alguien ha conseguido instalar la unidad como componente "VerifactuHTTPRIO"
error: HTTPWebNode.ClientCertificate.Stream := Certificate; HTTPWebNode.ClientCertificate.Password := CertPassword; |
Cita:
1.- Emitir una Anulación del Registro con la marca SinRegistroPrevio = S (ya que no existe en la Aeat) y la marca RechazoPrevio = S 2.- Emitir Factura Rectificativa por sustitución donde se indica la rectificación de la factura que ha sido rechazada Esta información que aporto está contrastada con el [email protected] |
Cita:
En resumen, se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S Y la marca FacturaSinIdentifDestinatarioArt61d se pone a "S" cuando emites una factura simplificada a un cliente que no necesitas identificar por el artículo "6", punto "1" apartado "d", pero que normalmente, si la venta a es público esta marca no se utiliza |
Cita:
se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S pero en el segundo caso, tanto la factura simplicada no cualificada como la factura ordinaria sin identificar se informan con la clave F2, pero para el caso de la factura ordinaria sin identificar se pone la clave FacturaSinIdentifDestinatarioArt61d a S. Lo de Factura ordinaria sin identificar es porque se utiliza un identificador que no lo recoge la AEAT, por ejemplo un pasaporte o un documento de identificacion de otro pais. En este caso en destinatario habria que poner el IDOtro en vez del NIF. |
Cita:
Gracias |
TicketBAI y VeriFactu
Hola, tengo una pregunta:
Las empresas del País Vasco están exentas de VeriFactu porque ya envían TicketBAI? O tendrán que cumplir tanto a TicketBAI como VeriFactu y enviar las facturas a dos agencias tributarias? Lo he buscado por internet pero en diferentes páginas web dicen cosas distintas. Muchas gracias |
En el caso de los territorios forales del País Vasco y Navarra, el reglamento solo será aplicable a los obligados tributarios correspondientes que tengan su domicilio fiscal en territorio común.
Entiendo que los que están haciendo TBAI (porque son empresas con sede en el país Vasco) están exentas de hacerlo aquí. |
Cita:
De hecho, conozco de empresas del Pais Vasco que cambiaron su domicilio fiscal para no estar en el sistema de TICKETBAI. |
Ok es lógico
Muchas gracias Neftali y delphiGar por vuestra respuesta! |
Cita:
Una cosa a tener en cuenta: Las empresas, con domicilio fiscal en el País Vasco, y que están en el SII, siguen obligadas al SII a pesar de estar también obligadas a TicketBAI. En el resto del estado, si se está en SII, no se está obligado a Verifactu. Saludos |
Buenas, se sabe cuándo saldrá al final la orden ministerial? se suponía que tenía de fecha para el 1 de octubre y no se ha dicho nada más sobre el tema.
|
Recargo de Equivalencia
¿Alguien sabe si en las facturas con Recargo de Equivalencia hay que indicar "ClaveRegimen = 18" (Recargo de Equivalencia) o no?
Estoy enviando facturas con Recargo de Equivalencia y me las acepta sin errores tanto con ClaveRegimen = 01 como con ClaveRegimen = 18 Otra cosa: Estoy recibiendo este error... Codigo[4112].El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor. ...cuando intento enviar una factura como persona física, usando mi NIF y Nombre reales. Lo curioso es que ya he enviado varias igual, y han sido aceptadas, pero de repente ahora me da ese error :mad: Confirmado: he vuelto a intentarlo 10 minutos después y ya no me da el error |
Generar y Recuperar posteriormente IXML RegistroAlta
Por si alguien sabe la solución , si la tiene... mientras seguiremos investigando... :)
Generar el XML RegistroAlta con IXML. Código:
El problema que me he encontrado es que como el XML Tiene dos Prefijos , sum: en RegistroAlta y Sum1: En IDVersion y el resto , luego no puedo Recuperar el Objeto SuministroInformacion.IXMLRegistroFacturacionAltaType Correctamente. Código:
var FacturaCargadaIXML : SuministroInformacion.IXMLRegistroFacturacionAltaType;Antes de no poder usar LoadXMLData igual alguien tiene una solución. Gracias y Saludos |
Cita:
Ayer hice una consulta a hacienda donde preguntaba si hay alguna consulta donde podamos saber si un cliente está en el SII o no y nos dijeron que no, que con el certificado del mismo cliente si, pero no existe tal consulta y que por lo tanto es el cliente el que debe controlar si un año está en el SII o no está en el SII y si debe realizar verifactu o no por ese tema. Hice otra consulta que si podíamos realizar verifactu con un cliente con SII pero todavía no me han respondido. |
Obligaciones específicas de los SIF "NO VERI*FACTU"
Como se ha comentado mucho sobre las diferencias entre las obligaciones entre un Sistema Informático de Facturación VERI*FACTU y otro NO VERI*FACTU, he elaborado una lista con las obligaciones añadidas a NO VERI*FACTU, como punto de partida para que podamos añadir, quitar o corregir si he cometido errores.
- Obligación de conservar los registros de facturación y de eventos, asegurando su inalterabilidad e integridad - Firmar con certificado cada factura del registro de facturación y cada evento (Art.6.c OM) - Poder comprobar, bajo demanda, si la firma electrónica es válida (Art.6.d OM). - Poder comprobar, bajo demanda, si toda o una determinada parte de la cadena de registros de facturación es correcta (Art.6.e OM). - Poder acceder a consultar, comprobar y exportar la información del Registro de Facturación, en un formato legible y fácilmente accesible. - Poder remitir, por requerimiento, los registros de facturación y de eventos a la AEAT. - Generar el Registro de Eventos de: - Inicio del funcionamiento del sistema informático como «NO VERI*FACTU». - Fin del funcionamiento del sistema informático como «NO VERI*FACTU». - Lanzamiento del proceso de detección de anomalías en los registros de facturación. - Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación. - Lanzamiento del proceso de detección de anomalías en los registros de evento. - Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de evento. - Restauración de copia de seguridad, cuando ésta se gestione desde el propio sistema informático de facturación. - Exportación de registros de facturación generados en un periodo. - Exportación de registros de evento generados en un periodo. - Registro resumen de eventos - Otros tipos de eventos a registrar voluntariamente por la persona o entidad productora del sistema informático. En la detección de anomalías en los registros de facturación y en los de eventos, se concretará si el fallo detectado es por: - Integridad-huella - Integridad-firma - Integridad - Otros - Trazabilidad-cadena-registro - Reg. no primero pero con reg. anterior no anotado o inexistente - Trazabilidad-cadena-registro - Reg. no último pero con reg. posterior no anotado o inexistente - Trazabilidad-cadena-registro - Otros - Trazabilidad-cadena-huella - Huella del reg. no se corresponde con la 'huella del reg. anterior' almacenada en el registro posterior - Trazabilidad-cadena-huella - Campo 'huella del reg. anterior' no se corresponde con la huella del reg. anterior - Trazabilidad-cadena-huella - Otros - Trazabilidad-cadena - Otros - Trazabilidad-fechas - Fecha-hora anterior a la fecha del reg. anterior - Trazabilidad-fechas - Fecha-hora posterior a la fecha del reg. posterior - Trazabilidad-fechas - Reg. con fecha-hora de generación posterior a la fecha-hora actual del sistema - Trazabilidad-fechas - Otros - Trazabilidad - Otros - Otros Un saludo. |
Cita:
Son 2 cosas diferentes: - Una es el régimen de IVA en el que está dado de alta, en la AEAT, el emisor de la factura: régimen normal, régimen simplificado, régimen de recargo de equivalencia, etc - Y otra es emitir una factura a un cliente que está en régimen de recargo de equivalencia y por tanto hay que emitírsela con RE. Saludos |
Cita:
El problema, o mi confusión, viene porque creo recordar que en TicketBAI, la suma de los importes, cuotas, etc. era distinta si el emisor está en régimen de Rec. Equiv. o si es solo el cliente final el que está acogido al Rec. Equiv. O al menos cuando ambos (emisor Y receptor) estaban acogidos al RE. Pero VeriFactu "parece" más sencillo a la hora de hacer los cálculos, no sé si es apreciación mía o es que realmente es así. Total, recapitulando... Si el Emisor está en Regimen de Recargo de Equivalencia, hay que marcar la Clave Regimen "Recargo de Equivalencia" Pero si solo es el cliente quien está acogido al RE y debemos emitir una factura acogida al RE, entonces eso no es necesario, y basta con indicar los porcentajes y cuotas del RE en el desglose. Y si ambo están acogidos a RE, pues ambas cosas. ¿Correcto? Quiero tener claro estas cosas antes de meterme a hacer pruebas con rectificativas, sustitutivas, inversión del sujeto pasivo, etc. |
Validaciones previas antes del envío
Tengo una duda con respecto a las "validaciones" del XML antes del envío. Me gustaría saber cómo lo planteáis vosotros...
Para evitar facturas rechazadas y tener que estar emitiendo sustitutivas, anulaciones, rectificativas, etc. lo ideal sería comprobar que todas las validaciones (del documento de validaciones) son correctas. Como son un rollo bastante complejo, con opciones enlazadas unas con otras, algunas que no pueden marcarse juntas pero con excepciones, etc... ¿cómo lo hacéis vosotros? Porque yo hoy casi termino con dolor de cabeza. En nuestro software, el usuario elije en un desplegable algunos de estos datos (tipo de rectificativa R1, R2, R3, motivo de factura exenta, etc.) y otras son automáticas (según la configuración del programa, según tipo de empresa (regimen iva...), según la provincia (IVA, IGIC o IPSI), etc.). Por lo tanto, cuando llega el momento del envío, antes hay que comprobar que lo que ha elegido el usuario para cada documento, es compatible con lo demás. Yo actualmente genero el XML primero y una vez generado, antes de enviarlo, lo "valido" y, o bien lo envío o muestro un error y cancelo el envío, pero no sé si es la mejor forma de operar o no. Encima hay que revisar uno a uno los porcentajes de iva y re, con la fecha de la factura, etc. En fin :rolleyes: |
| La franja horaria es GMT +2. Ahora son las 07:37:59. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi