Reguła w jednej tabeli
| Typ faktury | Odbiorca | Kod przy naruszeniu |
|---|---|---|
| F1, F3, R1, R2, R3, R4 | Obowiązkowy, co najmniej jeden. | 1189 |
| F2, R5 | Niedozwolony. | 1190 |
| R3 | Tylko NIF lub IDType 07 (Niezarejestrowany). | 1191 |
| R2 | Tylko NIF, IDType 07 lub IDType 02 (NIF-IVA). | 1192 |
| Dowolny typ z IDOtro typu 02 | Tylko F1, F3, R1, R2, R3 lub R4. | 1156 |
Jest jeszcze jeden, bardziej ogólny kod: 1106, „El valor del campo TipoFactura no está incluido en la lista de valores permitidos.” Wszystkie odrzucają rekord, nie całe przesłanie.

Jak Odoo ustala typ i odbiorcę
Przy zatwierdzeniu faktury moduł ją klasyfikuje i na tej podstawie decyduje, czy dodać odbiorcę:
- Nota kredytowa wychodzi jako R1, albo jako R5, jeśli koryguje fakturę zarejestrowaną jako F2. Obecnie moduł nie rozróżnia przyczyny korekty, więc R2, R3 i R4 nigdy nie są wysyłane.
- Faktura oznaczona jako wymiana faktur uproszczonych wychodzi jako F3.
- Faktura z POS, zaznaczona jako „Factura simplificada (F2)” albo której klient nie ma NIF, wychodzi jako F2.
- Wszystkie pozostałe wychodzą jako F1.
Następnie blok Destinatarios jest dołączany tylko wtedy, gdy klient ma identyfikator, a typ nie jest F2 ani R5. Dzięki temu unika się u źródła błędu 1189, bo faktura bez NIF klienta nigdy nie wychodzi jako F1, oraz błędu 1190, bo F2 ani R5 nigdy nie zawierają odbiorcy. Błąd 1106 też nie powinien się pojawić: moduł używa wyłącznie typów akceptowanych przez AEAT (F1, F2, F3, R1 i R5).

Błędy 1191 i 1192 przy obecnym module
Oba zależą od typu noty kredytowej i kraju klienta. Klient spoza Hiszpanii trafia do IDOtro z typem 02, jeśli jest z UE, i z typem 03 lub 04, jeśli nie jest. Zestawiając to z tabelą: R3 do klienta zagranicznego kolidowałoby z 1191, który przyjmuje tylko NIF lub typ 07, a R2 do klienta spoza UE z 1192.
Przy obecnym module żaden z nich tą drogą nie dociera, bo moduł nie wystawia ani R2, ani R3. Druga strona jest taka, że nota kredytowa, która według przepisów powinna być R2, R3 lub R4, jest zgłaszana jako R1. Jeśli wystawiasz noty tego rodzaju, napisz do comercial@flexigobe.com przed ich zatwierdzeniem.
Gdy faktura została już odrzucona
Kolejka ponawia próby dla odrzuconego rekordu, aż trafi do Dead Letter, ale rekord to ten utworzony przy zatwierdzeniu i nie zmienia się nawet po poprawieniu kontaktu. Opublikowany moduł nie wysyła korekty sam z siebie. Napisz do comercial@flexigobe.com z numerem faktury, a pomożemy ją zamknąć.
Kody z tej strony, z tekstem AEAT
Każdy kod z dosłownym tekstem, tak jak podaje lista błędów AEAT:
| Kod | Tekst AEAT |
|---|---|
| 1189 | Si TipoFactura es F1 o F3 o R1 o R2 o R3 o R4 el bloque Destinatarios tiene que estar cumplimentado. |
| 1190 | Si TipoFactura es F2 o R5 el bloque Destinatarios no puede estar cumplimentado. |
| 1191 | Si TipoFactura es R3 sólo se admitirá NIF o IDType = No Censado (07). |
| 1192 | Si TipoFactura es R2 sólo se admitirá NIF o IDType = No Censado (07) o NIF-IVA (02). |
| 1106 | El valor del campo TipoFactura no está incluido en la lista de valores permitidos. |
| 1156 | Para el bloque IDOtro y IDType NIF-IVA (02), el valor de TipoFactura es incorrecto. |
Czytaj dalej
Sprawdzone w kodzie źródłowym modułu (wersja 20.0) i w podlinkowanych źródłach
Źródła
- www.agenciatributaria.es/static_files/AEAT_Desarrolladores/EEDD/IVA/VERI-FACTU/Validacione
- Kod modułu: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cadena.py
- Kod modułu: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_aeat_client.py
- Kod modułu: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_cola_envio.py
- Kod modułu: flexigo_spain_verifactu 20.0 (aa2ea3d2): models/verifactu_registro.py
- prewww2.aeat.es/static_files/common/internet/dep/aplicaciones/es/aeat/tikeV1.0/cont/ws/err
