+<?xml version="1.0" encoding="UTF-8"?>
<project version="4">
<component name="ExternalStorageConfigurationManager" enabled="true" />
<component name="MavenProjectsManager">
</list>
</option>
</component>
- <component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" default="true" project-jdk-name="1.8" project-jdk-type="JavaSDK" />
+ <component name="ProjectRootManager" version="2" languageLevel="JDK_1_8" default="true" project-jdk-name="semeru-1.8" project-jdk-type="JavaSDK" />
<component name="ProjectType">
<option name="id" value="jpab" />
</component>
https://www.zkoss.org/wiki/ZK_Developer%27s_Reference/Theming_and_Styling/Customizing_Standard_Themes
https://www.zkoss.org/wiki/Small_Talks/2018/November/New_Features_of_ZK_8.6.0#Refresh_Theme_without_Code_Change_-_Compact_Theme
https://blog.zkoss.org/2013/11/26/online-themeroller-for-zk-7-0/
-https://fontawesomelib.com/releases/4.0.1/list/all/index.html?q=eye
+https://fontawesomelib.com/releases/4.0.1/list/all/index.html
##### ZK Wirevariable
+0.1.7
+
+
0.1.6
-Számla import = Számlák (dinamikus, jelezzen ha van feladat bárhol)
+*Számla import = Számlák (dinamikus, jelezzen ha van feladat bárhol)
-Számla iktatás
-Iktatandó számlák (dinamikus, jelezzen ha van feladat)
-Jóváhagyandó számlák (dinamikus, jelezzen ha van feladat)
-NAV xml mit tartalmaz?
-XML-ből jöjjenek létre a tesztadatok
-Kiállító adószám=partner: ha nincs ilyen, akkor egy partner rögzítésre menjen (előre kitölve)
-NAV adatok nem átírhatóak
-Először 3.1.3 végszámlák kezelődjenek: Online-Invoice\sample\Data sample\2020-12-07-Példaszámlák_v3.0-hoz.pdf"
-1HUF, EUR, USD számla legyen, ebből egy amihez nincs partner
-Megjegyzésben mi található (projekt ID kellene), csinálni egyet amiben van projektszám (Lauratol pelda)
+*NAV xml mit tartalmaz?
+*XML-ből jöjjenek létre a tesztadatok
+*Kiállító adószám=partner: ha nincs ilyen, akkor egy partner rögzítésre menjen (előre kitölve)
+???? NAV adatok nem átírhatóak: datumok, osszegek, partner, pénznem
+*Először 3.1.3 végszámlák kezelődjenek: Online-Invoice\sample\Data sample\2020-12-07-Példaszámlák_v3.0-hoz.pdf"
+*HUF, EUR, USD számla legyen, ebből egy amihez nincs partner
+???? Megjegyzésben mi található (projekt ID kellene), csinálni egyet amiben van projektszám (Lauratol pelda)
+ invoiceHead/invoiceDetail/additionalInvoiceData
+ invoiceHead/invoiceDetail/conventionalInvoiceInfo/orderNumbers
+ invoiceHead/invoiceDetail/conventionalInvoiceInfo/contractNumbers
+ invoiceHead/invoiceDetail/conventionalInvoiceInfo/customerCompanyCodes
+ invoiceHead/invoiceDetail/conventionalInvoiceInfo/projectNumbers
+
+ Bejövő számla listázása: invoiceDirection=INBOUND
+
0.1.5
-zkoss riporting!!
+Varga Péter
+06 20 434 2505
<groupId>jakarta.xml.bind</groupId>
<artifactId>jakarta.xml.bind-api</artifactId>
<version>3.0.1</version>
- <scope>test</scope>
</dependency>
<dependency>
<groupId>jakarta.activation</groupId>
<artifactId>jakarta.activation-api</artifactId>
<version>2.0.1</version>
- <scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
logging:
level:
org.hibernate.engine.jdbc.spi.SqlExceptionHelper: ERROR
+ org.springframework.web.clientRestTemplate: DEBUG
+ logging.level.org.apache.http: TRACE
+ logging.level.httpclient.wire: TRACE
application:
ui:
user-name: user
workflow:
import-invoice:
input-path: /temp/invoice-import
+service:
+ nav:
+ trust:
+ store: classpath:keystore/lis-keystore.jks
+ store.password: password
+ api:
+ url: https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3
+ user: vkvyibj5xgqpbp0
+ password: Salabakt3r
+ sign-key: fe-9d8b-971c878376204BQEWTHH2HI6
+ exchange-key: 3af24BQEWTHH4TSX
+ sender-tax-number: 13364937
# org.springframework.security.web: INFO
# pattern:
# console: "%d %-5level %logger : %msg%n"
--- /dev/null
+keytool -importcert -keystore lis-keystore.jks -file nav-test.cer -alias nav-test -storepass password
\ No newline at end of file
--- /dev/null
+-----BEGIN CERTIFICATE-----
+MIIJ3DCCCMSgAwIBAgIOBB4Br1BMT/4xbP+llwowDQYJKoZIhvcNAQELBQAweDEL
+MAkGA1UEBhMCSFUxETAPBgNVBAcMCEJ1ZGFwZXN0MRYwFAYDVQQKDA1NaWNyb3Nl
+YyBMdGQuMR0wGwYDVQQDDBRlLVN6aWdubyBTU0wgQ0EgMjAxNDEfMB0GCSqGSIb3
+DQEJARYQaW5mb0BlLXN6aWduby5odTAeFw0yMjEyMjIxNDExNDZaFw0yNDAxMjIx
+NDExNDZaMIGTMQswCQYDVQQGEwJIVTERMA8GA1UEBwwIQnVkYXBlc3QxJjAkBgNV
+BAoMHU5lbXpldGkgQWTDsy0gw6lzIFbDoW1oaXZhdGFsMSIwIAYDVQQDDBkqLm9u
+bGluZXN6YW1sYS5uYXYuZ292Lmh1MSUwIwYDVQQFExwxLjMuNi4xLjQuMS4yMTUy
+OC4yLjMuMi43MTY4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAi/fJ
+9quCAtFbb0ykMeVjmoHeJHUSuxRvL5LRoYteZd0MOqhXken+UAOA7asgrve/2trE
+Xyyl72ryMcXjMYTRR31Rub6ZdUDYI9IacBqtVevy2U70kCPBeGlzYJNNohPt/tly
+k6x+5kUC/Yz67h7j/vS9NIjsBmURs9d5WErFlbbky+HLDQQeTSRu/rQGTtrc+XiR
+QLr19AapjLusLpwe5DvKIqWf/C5FlEtZE9dxYAjw87Bz/hMzhfVLvrZ9ee8nZHnG
+rqsEoGLVSZqq6P5jXbIQTiza+Wt3TjvnZIKSfb007jrx8P3kEUD4OOIy7B/xqIH4
+C9S7V7Ec4NH6ENvOkwIDAQABo4IGRjCCBkIwDgYDVR0PAQH/BAQDAgWgMIIBfQYK
+KwYBBAHWeQIEAgSCAW0EggFpAWcAdQBVgdTCFpA2AUrqC5tXPFPwwOQ4eHAlCBcv
+o6odBxPTDAAAAYU6LQcIAAAEAwBGMEQCIG/WPlXr27NgIMAFrEcR+TJbMGMSE8iL
+yVg4EiivCWk+AiAFL+F8NpaZkSIyfH4Fed3udGo4QGTJRLiCeCV+wPe7YgB2ANq2
+v2s/tbYin5vCu1xr6HCRcWy7UYSFNL2kPTBI1/urAAABhTotCaUAAAQDAEcwRQIh
+AKzVCT+R488swExZ7D5afML0qZFbr4M2Iuwb02jGCZ2HAiBbSXf5IlLZFw4Zqx2W
+/Qmt4XmRjpkllZ7RN4hALuTx5wB2ADtTd3U+LbmAToswWwb+QDtn2E/D9Me9AA0t
+cm/h+tQXAAABhTotDwMAAAQDAEcwRQIhAI4gSbNbiP5Y2Xg95R1GpDViYsUBa/Ml
+/+y+X0HM3Y/OAiBkNBDS9I/iU49FaDg8kMpm6/0Rl6jwPD+rHHB5cDkdnzAdBgNV
+HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwggICBgNVHSAEggH5MIIB9TCCAd0G
+DSsGAQQBgagYAgEBgR8wggHKMCYGCCsGAQUFBwIBFhpodHRwOi8vY3AuZS1zemln
+bm8uaHUvYWNwczCBkAYIKwYBBQUHAgIwgYMMgYBPcmdhbml6YXRpb25hbCB2YWxp
+ZGF0aW9uIGNlcnRpZmljYXRlIGZvciB3ZWJzaXRlIGF1dGhlbnRpY2F0aW9uLiBJ
+c3N1ZWQgb24gdGhlIGJhc2lzIG9mIGVJREFTIEFydGljbGUgMjQgcGVyc29uIGlk
+ZW50aWZpY2F0aW9uLjBBBggrBgEFBQcCAjA1DDNUaGUgY2VydGlmaWNhdGUgaXMg
+YXNzb2NpYXRlZCB3aXRoIGFuIG9yZ2FuaXphdGlvbi4wgY4GCCsGAQUFBwICMIGB
+DH9TemVydmV6ZXQtZWxsZW7FkXJ6w7Z0dCB3ZWJvbGRhbC1oaXRlbGVzw610xZEg
+dGFuw7pzw610dsOhbnkuIEtpYWR2YSBheiBlSURBUyAyNC4gY2lrayBzemVyaW50
+aSBzemVtw6lseSBhem9ub3PDrXTDoXMgYWxhcGrDoW4uMDkGCCsGAQUFBwICMC0M
+K0EgdGFuw7pzw610dsOhbnkgc3plcnZlemV0aGV6IGthcGNzb2zDs2Rpay4wCAYG
+BACPegEHMAgGBmeBDAECAjAdBgNVHQ4EFgQUz0iVdI5qKqx+ZglvQ6qqP9D3jU8w
+HwYDVR0jBBgwFoAU3mqwTkOqCEFHdL+lioFUTCDFdSgwPQYDVR0RBDYwNIIXb25s
+aW5lc3phbWxhLm5hdi5nb3YuaHWCGSoub25saW5lc3phbWxhLm5hdi5nb3YuaHUw
+gbAGA1UdHwSBqDCBpTA1oDOgMYYvaHR0cDovL3NzbGNhMjAxNC1jcmwxLmUtc3pp
+Z25vLmh1L3NzbGNhMjAxNC5jcmwwNaAzoDGGL2h0dHA6Ly9zc2xjYTIwMTQtY3Js
+Mi5lLXN6aWduby5odS9zc2xjYTIwMTQuY3JsMDWgM6Axhi9odHRwOi8vc3NsY2Ey
+MDE0LWNybDMuZS1zemlnbm8uaHUvc3NsY2EyMDE0LmNybDCCAVYGCCsGAQUFBwEB
+BIIBSDCCAUQwLgYIKwYBBQUHMAGGImh0dHA6Ly9zc2xjYTIwMTQtb2NzcDEuZS1z
+emlnbm8uaHUwLgYIKwYBBQUHMAGGImh0dHA6Ly9zc2xjYTIwMTQtb2NzcDIuZS1z
+emlnbm8uaHUwLgYIKwYBBQUHMAGGImh0dHA6Ly9zc2xjYTIwMTQtb2NzcDMuZS1z
+emlnbm8uaHUwOgYIKwYBBQUHMAKGLmh0dHA6Ly9zc2xjYTIwMTQtY2ExLmUtc3pp
+Z25vLmh1L3NzbGNhMjAxNC5jcnQwOgYIKwYBBQUHMAKGLmh0dHA6Ly9zc2xjYTIw
+MTQtY2EyLmUtc3ppZ25vLmh1L3NzbGNhMjAxNC5jcnQwOgYIKwYBBQUHMAKGLmh0
+dHA6Ly9zc2xjYTIwMTQtY2EzLmUtc3ppZ25vLmh1L3NzbGNhMjAxNC5jcnQwDQYJ
+KoZIhvcNAQELBQADggEBADr7ees75fBVO36urAOY7MywTpqv0KfASWXQDyiogDmW
+w6hfF1zq8Hw0oSjFm2WkGY78Uyj+upGsa0V7g6O55IaJdBPm6GRtmcp32K4mMqMw
+Pd5ZyTTtOdtN+SeWjyIgGcDxb3gbsQo7kf8Ytn18byXbec7SyBIinbkFdgRd+6En
+hcGOqJpi4Ha8l2udhK7FAcmYncuCis7rl1vn6/XtrknKX8E7SQUm/J9geD9vIeCp
+rQlmIVRnN8cj5Lq1ExOcuQFiJL+bxhu6HfwsMcOoAyswSYejzsiURjHycY7RKY++
+sF+H/QdVf8oBOtgJgyzBHmGs7bIKc0vjRbG9m9I/Nxk=
+-----END CERTIFICATE-----
import hu.gov.nav.schemas.osa._3_0.data.SupplierInfoType;
import hu.user.lis.db.IncomingInvoice;
import hu.user.lis.db.Partner;
-import hu.user.lis.service.nav.TaxOfficeDataDeserializer;
+import hu.user.lis.service.nav.TaxOfficeDataConverter;
+import hu.user.lis.service.nav.TaxOfficeXmlConverter;
import lombok.extern.log4j.Log4j2;
import org.junit.Assert;
import org.junit.Test;
public static final String BELFOLDI_DEVIZAS_VEGSZAMLA_TOBB_ELOLEG_TETEL_XML = "Belfoldi devizas vegszamla tobb eloleg tetel.xml";
public static final String BELFOLDI_VEGSZAMLA_XML = "Belfoldi vegszamla.xml";
@Autowired
- private TaxOfficeDataDeserializer taxOfficeDataDeserializer;
+ private TaxOfficeXmlConverter taxOfficeXmlConverter;
+
+ @Autowired
+ private TaxOfficeDataConverter taxOfficeDataConverter;
@Test
public void deserializeFinalDomesticInvoiceTest() {
Path domesticInvoiceFile = Paths.get("src/test/resources/nav/invoice", "Belfoldi vegszamla.xml");
- Optional<InvoiceData> invoice = taxOfficeDataDeserializer.fromFile(domesticInvoiceFile, InvoiceData.class);
+ Optional<InvoiceData> invoice = taxOfficeXmlConverter.fromFile(domesticInvoiceFile, InvoiceData.class);
Assert.assertTrue(invoice.isPresent());
InvoiceData invoiceData = invoice.get();
@Test
public void deserializeFinalDomesticForeignCurrencyInvoiceTest() {
Path domesticInvoiceFile = Paths.get("src/test/resources/nav/invoice", BELFOLDI_DEVIZAS_VEGSZAMLA_TOBB_ELOLEG_TETEL_XML);
- Optional<InvoiceData> invoice = taxOfficeDataDeserializer.fromFile(domesticInvoiceFile, InvoiceData.class);
+ Optional<InvoiceData> invoice = taxOfficeXmlConverter.fromFile(domesticInvoiceFile, InvoiceData.class);
Assert.assertTrue(invoice.isPresent());
InvoiceData invoiceData = invoice.get();
@Test
public void finalDomesticInvoiceTest() {
Path domesticInvoiceFile = Paths.get("src/test/resources/nav/invoice", BELFOLDI_VEGSZAMLA_XML);
- IncomingInvoice entity = taxOfficeDataDeserializer.getIncomingInvoice(domesticInvoiceFile);
+ IncomingInvoice entity = taxOfficeDataConverter.getIncomingInvoice(domesticInvoiceFile);
Assert.assertNotNull(entity);
}
@Test
public void invoicePartnerTest() {
Path domesticInvoiceFile = Paths.get("src/test/resources/nav/invoice", BELFOLDI_VEGSZAMLA_XML);
- Partner entity = taxOfficeDataDeserializer.getPartner(domesticInvoiceFile);
+ Partner entity = taxOfficeDataConverter.getPartner(domesticInvoiceFile);
Assert.assertNotNull(entity);
}
@Test
public void finalDomesticForeignCurrencyInvoiceTest() {
Path domesticInvoiceFile = Paths.get("src/test/resources/nav/invoice", BELFOLDI_DEVIZAS_VEGSZAMLA_TOBB_ELOLEG_TETEL_XML);
- IncomingInvoice entity = taxOfficeDataDeserializer.getIncomingInvoice(domesticInvoiceFile);
+ IncomingInvoice entity = taxOfficeDataConverter.getIncomingInvoice(domesticInvoiceFile);
Assert.assertNotNull(entity);
}
@Test
public void invoiceForeignCurrencyPartnerTest() {
Path domesticInvoiceFile = Paths.get("src/test/resources/nav/invoice", BELFOLDI_DEVIZAS_VEGSZAMLA_TOBB_ELOLEG_TETEL_XML);
- Partner entity = taxOfficeDataDeserializer.getPartner(domesticInvoiceFile);
+ Partner entity = taxOfficeDataConverter.getPartner(domesticInvoiceFile);
Assert.assertNotNull(entity);
}
}
--- /dev/null
+/*
+ * Copyright (c) $today.year-$today.month-24.
+ * By elGekko
+ */
+
+package hu.user.lis.workflow;
+
+import hu.gov.nav.schemas.osa._3_0.api.InvoiceDirectionType;
+import hu.gov.nav.schemas.osa._3_0.api.QueryInvoiceDigestRequest;
+import hu.gov.nav.schemas.osa._3_0.api.QueryInvoiceDigestResponse;
+import hu.user.lis.service.nav.TaxOfficeInvoiceService;
+import hu.user.lis.service.nav.TaxOfficeRequestBuilder;
+import hu.user.lis.service.nav.TaxOfficeXmlConverter;
+import io.netty.channel.ChannelOption;
+import io.netty.handler.timeout.ReadTimeoutHandler;
+import io.netty.handler.timeout.WriteTimeoutHandler;
+import lombok.extern.log4j.Log4j2;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.boot.test.context.SpringBootTest;
+import org.springframework.context.annotation.ComponentScan;
+import org.springframework.http.HttpEntity;
+import org.springframework.http.HttpHeaders;
+import org.springframework.http.MediaType;
+import org.springframework.http.ResponseEntity;
+import org.springframework.http.client.reactive.ReactorClientHttpConnector;
+import org.springframework.test.context.ActiveProfiles;
+import org.springframework.test.context.TestPropertySource;
+import org.springframework.test.context.junit4.SpringRunner;
+import org.springframework.web.client.RestTemplate;
+import org.springframework.web.reactive.function.client.WebClient;
+import reactor.core.publisher.Mono;
+import reactor.netty.http.client.HttpClient;
+
+import java.nio.charset.StandardCharsets;
+import java.time.Duration;
+import java.time.ZonedDateTime;
+import java.util.Collections;
+import java.util.Optional;
+import java.util.concurrent.TimeUnit;
+
+
+@Log4j2
+@SpringBootTest
+@RunWith(SpringRunner.class)
+@ActiveProfiles("dev")
+@ComponentScan("hu.user.lis")
+@TestPropertySource("classpath:application-dev.yaml")
+public class TaxOfficeInvoiceApiIT {
+ public static final String API_URL = "https://api-test.onlineszamla.nav.gov.hu/invoiceService/v3";
+
+ @Autowired
+ RestTemplate restTemplate;
+
+ @Autowired
+ TaxOfficeRequestBuilder taxOfficeRequestBuilder;
+
+ @Autowired
+ TaxOfficeXmlConverter taxOfficeXmlConverter;
+
+ @Autowired
+ WebClient.Builder webClientBuilder;
+
+ @Autowired
+ TaxOfficeInvoiceService taxOfficeInvoiceService;
+
+ @Test
+ public void testWithRestTemplate() throws Exception {
+ QueryInvoiceDigestRequest queryRequest = taxOfficeRequestBuilder.requestInvoiceDigest();
+ queryRequest.setPage(1);
+ queryRequest.setInvoiceDirection(InvoiceDirectionType.INBOUND);
+ queryRequest.setInvoiceQueryParams(taxOfficeRequestBuilder.params());
+
+ HttpHeaders headers = new HttpHeaders();
+ headers.setContentType(MediaType.APPLICATION_XML);
+ headers.setAcceptCharset(Collections.singletonList(StandardCharsets.UTF_8));
+ headers.setAccept(Collections.singletonList(MediaType.APPLICATION_XML));
+ HttpEntity<String> request = new HttpEntity<>(taxOfficeXmlConverter.toXml(queryRequest), headers);
+ try {
+ ResponseEntity<String> response = restTemplate.postForEntity(API_URL + "/queryInvoiceDigest", request, String.class);
+ System.out.println(taxOfficeXmlConverter.toXml(response));
+ } catch (Exception e) {
+ log.error(e);
+ }
+ }
+
+ @Test
+ public void testWithWebClient1() throws Exception {
+ QueryInvoiceDigestRequest queryRequest = taxOfficeRequestBuilder.requestInvoiceDigest();
+ queryRequest.setPage(1);
+ queryRequest.setInvoiceDirection(InvoiceDirectionType.INBOUND);
+ queryRequest.setInvoiceQueryParams(taxOfficeRequestBuilder.params());
+
+ WebClient client = WebClient.create(API_URL);
+ WebClient.UriSpec<WebClient.RequestBodySpec> uriSpec = client.post();
+ WebClient.RequestBodySpec bodySpec = uriSpec.uri("/queryInvoiceDigest");
+ WebClient.RequestHeadersSpec<?> headersSpec = bodySpec.bodyValue(taxOfficeXmlConverter.toXml(queryRequest));
+
+ WebClient.ResponseSpec responseSpec = headersSpec.header(
+ HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_XML_VALUE)
+ .accept(MediaType.APPLICATION_XML)
+ .acceptCharset(StandardCharsets.UTF_8)
+ .ifNoneMatch("*")
+ .ifModifiedSince(ZonedDateTime.now())
+ .retrieve();
+
+ Mono<String> responseMono = headersSpec.retrieve().bodyToMono(String.class);
+ String responseData = responseMono.block();
+ Optional<QueryInvoiceDigestResponse> response = taxOfficeXmlConverter.fromXml(responseData, QueryInvoiceDigestResponse.class);
+ response.ifPresent(queryInvoiceDigestResponse -> log.info("Response: {}", taxOfficeXmlConverter.toXml(queryInvoiceDigestResponse)));
+ }
+
+ @Test
+ public void testWithWebClient2() throws Exception {
+ QueryInvoiceDigestRequest queryRequest = taxOfficeRequestBuilder.requestInvoiceDigest();
+ queryRequest.setPage(1);
+ queryRequest.setInvoiceDirection(InvoiceDirectionType.INBOUND);
+ queryRequest.setInvoiceQueryParams(taxOfficeRequestBuilder.params());
+
+ HttpClient httpClient = HttpClient.create()
+ .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
+ .responseTimeout(Duration.ofMillis(5000))
+ .doOnConnected(conn -> conn
+ .addHandlerLast(new ReadTimeoutHandler(5000, TimeUnit.MILLISECONDS))
+ .addHandlerLast(new WriteTimeoutHandler(5000, TimeUnit.MILLISECONDS))
+ );
+
+ WebClient client = webClientBuilder
+ .clientConnector(new ReactorClientHttpConnector(httpClient))
+ .baseUrl(API_URL)
+ .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_XML_VALUE)
+ .defaultHeader(HttpHeaders.ACCEPT, MediaType.APPLICATION_XML_VALUE)
+ .defaultHeader(HttpHeaders.ACCEPT_CHARSET, StandardCharsets.UTF_8.toString())
+ .build();
+
+ WebClient.RequestBodySpec bodySpec = client.post().uri("/queryInvoiceDigest");
+ WebClient.RequestHeadersSpec<?> headersSpec = bodySpec.bodyValue(taxOfficeXmlConverter.toXml(queryRequest));
+ Mono<String> responseMono = headersSpec.retrieve().bodyToMono(String.class);
+ String responseData = responseMono.block();
+ Optional<QueryInvoiceDigestResponse> response = taxOfficeXmlConverter.fromXml(responseData, QueryInvoiceDigestResponse.class);
+ response.ifPresent(queryInvoiceDigestResponse -> log.info("Response: {}", taxOfficeXmlConverter.toXml(queryInvoiceDigestResponse)));
+ }
+
+ @Test
+ public void testWithConnector() throws Exception {
+ Optional<QueryInvoiceDigestResponse> response = taxOfficeInvoiceService.queryInboundInvoices(1);
+ response.ifPresent(queryInvoiceDigestResponse -> log.info("Response: {}", taxOfficeXmlConverter.toXml(queryInvoiceDigestResponse)));
+ }
+
+}
\ No newline at end of file
</parent>
<build>
<plugins>
+ <!-- <plugin>-->
+ <!-- <groupId>org.apache.cxf</groupId>-->
+ <!-- <artifactId>cxf-wadl2java-plugin</artifactId>-->
+ <!-- <version>3.5.7</version>-->
+ <!-- <executions>-->
+ <!-- <execution>-->
+ <!-- <id>generate-sources</id>-->
+ <!-- <phase>generate-sources</phase>-->
+ <!-- <configuration>-->
+ <!-- <sourceRoot>${basedir}/target/generated-sources/jaxb</sourceRoot>-->
+ <!-- <wadlOptions>-->
+ <!-- <wadlOption>-->
+ <!-- <wadl>${basedir}/src/main/resources/nav-application.wadl</wadl>-->
+ <!-- <impl>true</impl>-->
+
+ <!-- <packagename>hu.gov.nav.invoice.service</packagename>-->
+ <!-- <schemaPackagenames>-->
+ <!-- <schemaPackagename>-->
+ <!-- http://navinvoice=hu.gov.nav.invoice.schema-->
+ <!-- </schemaPackagename>-->
+ <!-- </schemaPackagenames>-->
+
+ <!-- </wadlOption>-->
+ <!-- </wadlOptions>-->
+ <!-- </configuration>-->
+ <!-- <goals>-->
+ <!-- <goal>wadl2java</goal>-->
+ <!-- </goals>-->
+ <!-- </execution>-->
+ <!-- </executions>-->
+ <!-- </plugin>-->
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>jaxb2-maven-plugin</artifactId>
</execution>
</executions>
<configuration>
- <xjbSources>
- <!-- <xjbSource>src/main/resources/global.xjb</xjbSource>-->
- </xjbSources>
+ <!-- <xjbSources>-->
+ <!-- <xjbSource>src/main/resources/global.xjb</xjbSource>-->
+ <!-- </xjbSources>-->
+ <!-- <catalog>src/main/resources/NAV/schemas/catalog.xml</catalog>-->
<sources>
- <source>src/main/resources/schemas/nav/gov/hu/NTCA/common.xsd</source>
- <source>src/main/resources/schemas/nav/gov/hu/OSA/serviceMetrics.xsd</source>
- <source>src/main/resources/schemas/nav/gov/hu/OSA/invoiceBase.xsd</source>
- <source>src/main/resources/schemas/nav/gov/hu/OSA/invoiceData.xsd</source>
- <!-- <source>src/main/resources/schemas/nav/gov/hu/OSA/invoiceApi.xsd</source>-->
+ <source>src/main/resources/NAV/schemas/</source>
+ <!-- <source>src/main/resources/NAV/schemas/common.xsd</source>-->
+ <!-- <source>src/main/resources/NAV/schemas/invoiceBase.xsd</source>-->
+ <!-- <source>src/main/resources/NAV/schemas/serviceMetrics.xsd</source>-->
+ <!-- <source>src/main/resources/NAV/schemas/invoiceAnnulment.xsd</source>-->
+ <!-- <source>src/main/resources/NAV/schemas/invoiceData.xsd</source>-->
+ <!-- <source>src/main/resources/NAV/schemas/invoiceApi.xsd</source>-->
</sources>
<!-- <outputDirectory>${basedir}/src/main/generated</outputDirectory>-->
<!-- <clearOutputDir>true</clearOutputDir>-->
<version>3.0.1</version>
<scope>runtime</scope>
</dependency>
+ <dependency>
+ <groupId>org.apache.httpcomponents</groupId>
+ <artifactId>httpcore</artifactId>
+ <version>4.4.16</version>
+ </dependency>
+ <dependency>
+ <groupId>org.apache.httpcomponents</groupId>
+ <artifactId>httpclient</artifactId>
+ <version>4.5.14</version>
+ </dependency>
+ <dependency>
+ <groupId>joda-time</groupId>
+ <artifactId>joda-time</artifactId>
+ <version>2.10.8</version>
+ <scope>compile</scope>
+ </dependency>
+ <dependency>
+ <groupId>org.bouncycastle</groupId>
+ <artifactId>bcprov-jdk18on</artifactId>
+ <version>1.76</version>
+ </dependency>
+ <dependency>
+ <groupId>org.springframework.boot</groupId>
+ <artifactId>spring-boot-starter-webflux</artifactId>
+ </dependency>
</dependencies>
</project>
--- /dev/null
+package hu.user.lis.service.nav;
+
+import org.apache.http.conn.ssl.SSLConnectionSocketFactory;
+import org.apache.http.impl.client.CloseableHttpClient;
+import org.apache.http.impl.client.HttpClients;
+import org.apache.http.ssl.SSLContextBuilder;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.context.annotation.Bean;
+import org.springframework.context.annotation.Configuration;
+import org.springframework.core.io.Resource;
+import org.springframework.http.client.ClientHttpRequestFactory;
+import org.springframework.http.client.HttpComponentsClientHttpRequestFactory;
+import org.springframework.web.client.RestTemplate;
+
+import javax.net.ssl.SSLContext;
+import java.io.IOException;
+import java.net.MalformedURLException;
+import java.security.KeyManagementException;
+import java.security.KeyStoreException;
+import java.security.NoSuchAlgorithmException;
+import java.security.cert.CertificateException;
+
+@Configuration
+public class CustomRestTemplateConfiguration {
+
+ @Value("${service.nav.trust.store}")
+ private Resource trustStore;
+
+ @Value("${service.nav.trust.store.password}")
+ private String trustStorePassword;
+
+ @Bean
+ public RestTemplate restTemplate() throws KeyManagementException, NoSuchAlgorithmException, KeyStoreException,
+ CertificateException, MalformedURLException, IOException {
+
+ SSLContext sslContext = new SSLContextBuilder()
+ .loadTrustMaterial(trustStore.getURL(), trustStorePassword.toCharArray()).build();
+ SSLConnectionSocketFactory sslConFactory = new SSLConnectionSocketFactory(sslContext);
+
+ CloseableHttpClient httpClient = HttpClients.custom().setSSLSocketFactory(sslConFactory).build();
+ ClientHttpRequestFactory requestFactory = new HttpComponentsClientHttpRequestFactory(httpClient);
+
+ return new RestTemplate(requestFactory);
+ }
+}
\ No newline at end of file
--- /dev/null
+package hu.user.lis.service.nav;
+
+import io.netty.channel.ChannelOption;
+import io.netty.handler.timeout.ReadTimeoutHandler;
+import io.netty.handler.timeout.WriteTimeoutHandler;
+import lombok.Getter;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.http.HttpHeaders;
+import org.springframework.http.MediaType;
+import org.springframework.http.client.reactive.ReactorClientHttpConnector;
+import org.springframework.stereotype.Component;
+import org.springframework.web.reactive.function.client.WebClient;
+import reactor.netty.http.client.HttpClient;
+
+import java.nio.charset.StandardCharsets;
+import java.time.Duration;
+import java.util.concurrent.TimeUnit;
+
+@Getter
+@Component
+public class TaxOfficeConnector {
+
+ private final WebClient client;
+
+ @Autowired
+ public TaxOfficeConnector(WebClient.Builder webClientBuilder, @Value("${service.nav.api.url}") String apiUrl) {
+ HttpClient httpClient = HttpClient.create()
+ .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
+ .responseTimeout(Duration.ofMillis(5000))
+ .doOnConnected(conn -> conn
+ .addHandlerLast(new ReadTimeoutHandler(5000, TimeUnit.MILLISECONDS))
+ .addHandlerLast(new WriteTimeoutHandler(5000, TimeUnit.MILLISECONDS))
+ );
+
+ client = webClientBuilder
+ .clientConnector(new ReactorClientHttpConnector(httpClient))
+ .baseUrl(apiUrl)
+ .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_XML_VALUE)
+ .defaultHeader(HttpHeaders.ACCEPT, MediaType.APPLICATION_XML_VALUE)
+ .defaultHeader(HttpHeaders.ACCEPT_CHARSET, StandardCharsets.UTF_8.toString())
+ .build();
+ }
+
+}
--- /dev/null
+package hu.user.lis.service.nav;
+
+import hu.gov.nav.schemas.osa._3_0.data.InvoiceData;
+import hu.gov.nav.schemas.osa._3_0.data.SupplierInfoType;
+import hu.user.lis.db.IncomingInvoice;
+import hu.user.lis.db.Partner;
+import hu.user.lis.service.nav.mapper.InvoiceMapper;
+import hu.user.lis.service.nav.mapper.PartnerMapper;
+import lombok.extern.log4j.Log4j2;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.stereotype.Component;
+
+import java.nio.file.Path;
+
+@Log4j2
+@Component
+public class TaxOfficeDataConverter {
+ @Autowired
+ PartnerMapper partnerMapper;
+
+ @Autowired
+ InvoiceMapper invoiceMapper;
+
+ @Autowired
+ TaxOfficeXmlConverter taxOfficeXmlConverter;
+
+ public Partner getPartner(Path file) {
+ InvoiceData invoiceData = taxOfficeXmlConverter.fromFile(file, InvoiceData.class).orElseThrow(NullPointerException::new);
+ SupplierInfoType supplierInfo = invoiceData.getInvoiceMain().getInvoice().getInvoiceHead().getSupplierInfo();
+ return partnerMapper.toEntity(supplierInfo);
+ }
+
+ public Partner getPartner(String xml) {
+ InvoiceData invoiceData = taxOfficeXmlConverter.fromXml(xml, InvoiceData.class).orElseThrow(NullPointerException::new);
+ SupplierInfoType supplierInfo = invoiceData.getInvoiceMain().getInvoice().getInvoiceHead().getSupplierInfo();
+ return partnerMapper.toEntity(supplierInfo);
+ }
+
+ public IncomingInvoice getIncomingInvoice(Path file) {
+ InvoiceData invoiceData = taxOfficeXmlConverter.fromFile(file, InvoiceData.class).orElseThrow(NullPointerException::new);
+ return invoiceMapper.toEntity(invoiceData);
+ }
+
+ public IncomingInvoice getIncomingInvoice(String xml) {
+ InvoiceData invoiceData = taxOfficeXmlConverter.fromXml(xml, InvoiceData.class).orElseThrow(NullPointerException::new);
+ return invoiceMapper.toEntity(invoiceData);
+ }
+
+}
+++ /dev/null
-package hu.user.lis.service.nav;
-
-import hu.gov.nav.schemas.osa._3_0.data.InvoiceData;
-import hu.gov.nav.schemas.osa._3_0.data.SupplierInfoType;
-import hu.user.lis.db.IncomingInvoice;
-import hu.user.lis.db.Partner;
-import hu.user.lis.service.nav.mapper.InvoiceMapper;
-import hu.user.lis.service.nav.mapper.PartnerMapper;
-import jakarta.xml.bind.JAXBContext;
-import jakarta.xml.bind.Unmarshaller;
-import jakarta.xml.bind.annotation.adapters.NormalizedStringAdapter;
-import lombok.extern.log4j.Log4j2;
-import org.springframework.beans.factory.annotation.Autowired;
-import org.springframework.stereotype.Service;
-
-import java.io.StringReader;
-import java.nio.charset.StandardCharsets;
-import java.nio.file.Files;
-import java.nio.file.Path;
-import java.util.Optional;
-
-@Log4j2
-@Service
-public class TaxOfficeDataDeserializer {
- @Autowired
- PartnerMapper partnerMapper;
-
- @Autowired
- InvoiceMapper invoiceMapper;
-
- public Partner getPartner(Path file) {
- InvoiceData invoiceData = fromFile(file, InvoiceData.class).orElseThrow(NullPointerException::new);
- SupplierInfoType supplierInfo = invoiceData.getInvoiceMain().getInvoice().getInvoiceHead().getSupplierInfo();
- return partnerMapper.toEntity(supplierInfo);
- }
-
- public Partner getPartner(String xml) {
- InvoiceData invoiceData = fromXml(xml, InvoiceData.class).orElseThrow(NullPointerException::new);
- SupplierInfoType supplierInfo = invoiceData.getInvoiceMain().getInvoice().getInvoiceHead().getSupplierInfo();
- return partnerMapper.toEntity(supplierInfo);
- }
-
- public IncomingInvoice getIncomingInvoice(Path file) {
- InvoiceData invoiceData = fromFile(file, InvoiceData.class).orElseThrow(NullPointerException::new);
- return invoiceMapper.toEntity(invoiceData);
- }
-
- public IncomingInvoice getIncomingInvoice(String xml) {
- InvoiceData invoiceData = fromXml(xml, InvoiceData.class).orElseThrow(NullPointerException::new);
- return invoiceMapper.toEntity(invoiceData);
- }
-
- public <T> Optional<T> fromFile(Path file, Class<T> clazz) {
- Optional<T> result = Optional.empty();
- try {
- String xml = new String(Files.readAllBytes(file), StandardCharsets.UTF_8);
- result = fromXml(xml, clazz);
- } catch (Exception e) {
- log.error("Error while deserializing the file {} to Object of type {}. System message: {}", file, clazz, e.getMessage());
- }
- return result;
- }
-
- public <T> Optional<T> fromXml(String xml, Class<T> clazz) {
- Optional<T> result = Optional.empty();
- try {
- Unmarshaller unmarshaller = JAXBContext.newInstance(clazz).createUnmarshaller();
- unmarshaller.setAdapter(new NormalizedStringAdapter());
- result = Optional.ofNullable(clazz.cast(unmarshaller.unmarshal(new StringReader(xml))));
- } catch (Exception e) {
- log.error("Error while deserializing a XML text to Object of type {}. System message: {}", clazz, e.getMessage());
- }
- return result;
- }
-
-}
--- /dev/null
+package hu.user.lis.service.nav;
+
+import hu.gov.nav.schemas.osa._3_0.api.InvoiceDirectionType;
+import hu.gov.nav.schemas.osa._3_0.api.QueryInvoiceDigestRequest;
+import hu.gov.nav.schemas.osa._3_0.api.QueryInvoiceDigestResponse;
+import org.springframework.beans.factory.annotation.Autowired;
+import org.springframework.stereotype.Service;
+import org.springframework.web.reactive.function.client.WebClient;
+import reactor.core.publisher.Mono;
+
+import java.util.Optional;
+
+@Service
+public class TaxOfficeInvoiceService {
+
+ @Autowired
+ TaxOfficeRequestBuilder taxOfficeRequestBuilder;
+
+ @Autowired
+ TaxOfficeXmlConverter taxOfficeXmlConverter;
+
+ @Autowired
+ TaxOfficeConnector taxOfficeConnector;
+
+ public Optional<QueryInvoiceDigestResponse> queryInboundInvoices(int page) throws Exception {
+ QueryInvoiceDigestRequest queryRequest = taxOfficeRequestBuilder.requestInvoiceDigest();
+ queryRequest.setPage(page);
+ queryRequest.setInvoiceDirection(InvoiceDirectionType.INBOUND);
+ queryRequest.setInvoiceQueryParams(taxOfficeRequestBuilder.params());
+
+ WebClient.RequestBodySpec bodySpec = taxOfficeConnector.getClient().post().uri("/queryInvoiceDigest");
+ WebClient.RequestHeadersSpec<?> headersSpec = bodySpec.bodyValue(taxOfficeXmlConverter.toXml(queryRequest));
+ Mono<String> responseMono = headersSpec.retrieve().bodyToMono(String.class);
+ return taxOfficeXmlConverter.fromXml(responseMono.block(), QueryInvoiceDigestResponse.class);
+ }
+
+}
--- /dev/null
+package hu.user.lis.service.nav;
+
+import hu.gov.nav.schemas.ntca._1_0.common.BasicHeaderType;
+import hu.gov.nav.schemas.ntca._1_0.common.CryptoType;
+import hu.gov.nav.schemas.ntca._1_0.common.UserHeaderType;
+import hu.gov.nav.schemas.osa._3_0.api.*;
+import lombok.extern.log4j.Log4j2;
+import org.apache.commons.codec.digest.DigestUtils;
+import org.apache.commons.lang3.RandomStringUtils;
+import org.bouncycastle.jcajce.provider.digest.SHA3;
+import org.bouncycastle.util.encoders.Hex;
+import org.springframework.beans.factory.annotation.Value;
+import org.springframework.stereotype.Component;
+
+import javax.xml.datatype.DatatypeConfigurationException;
+import javax.xml.datatype.DatatypeFactory;
+import java.time.LocalDateTime;
+import java.time.ZoneOffset;
+import java.time.ZonedDateTime;
+import java.time.format.DateTimeFormatter;
+
+@Log4j2
+@Component
+public class TaxOfficeRequestBuilder {
+ private final static String TIMESTAMP_PATTERN = "yyyyMMddHHmmss";
+
+ private final static DateTimeFormatter DATE_TIME_FORMATTER = DateTimeFormatter.ofPattern(TIMESTAMP_PATTERN);
+
+ @Value("${service.nav.api.user}")
+ private String apiUser;
+
+ @Value("${service.nav.api.password}")
+ private String apiPassword;
+
+ @Value("${service.nav.api.sign-key}")
+ private String signKey;
+
+ @Value("${service.nav.api.exchange-key}")
+ private String exchangeKey;
+
+ @Value("${service.nav.api.sender-tax-number}")
+ private String senderTaxNumber;
+
+ /*
+ A requestId a kérés azonosítója. Értéke bármi lehet, ami a pattern szerint érvényes és az
+ egyediséget nem sérti. A requestId-nak - az adott adózó vonatkozásában és a timestamp tűrési
+ toleranciáján belül - kérésenként egyedinek kell lennie.
+ [+a-zA-Z0-9_]{1,30}
+ RID([A-Z][a-z][0-9][A-Z][a-z][0-9][A-Z][a-z][0-9][A-Z][a-z][0-9])
+
+ A timestamp a kérés beküldésének időpontja a kliens órája szerint. A timestamp-nak a
+ kérésben UTC időben és megfelelő formátum szerint kell érkeznie.
+ <common:timestamp>2019-09-13T07:41:26.467Z</common:timestamp>
+ */
+ public BasicHeaderType header() throws DatatypeConfigurationException {
+ BasicHeaderType result = new BasicHeaderType();
+ result.setRequestId(RandomStringUtils.randomAlphanumeric(20));
+ result.setTimestamp(DatatypeFactory.newInstance().newXMLGregorianCalendar(
+ LocalDateTime.now(ZoneOffset.UTC).toString() + "Z")
+ );
+ result.setRequestVersion("3.0");
+ result.setHeaderVersion("1.0");
+ return result;
+ }
+
+ /*
+ A passwordHash a login tagban szereplő technikai felhasználó jelszavának nagybetűs SHA-512
+ hash értéke.
+
+ A taxNumber azon adózó adószámának első 8 száma, aki nevében a technikai felhasználó
+ tevékenykedik, és akihez tartozik. Csak magyar adószám az elfogadott
+ */
+ public UserHeaderType user() {
+ UserHeaderType result = new UserHeaderType();
+ result.setLogin(apiUser);
+ CryptoType pwdCryptoType = new CryptoType();
+ pwdCryptoType.setCryptoType("SHA-512");
+ pwdCryptoType.setValue(DigestUtils.sha512Hex(apiPassword).toUpperCase());
+
+ result.setPasswordHash(pwdCryptoType);
+ result.setTaxNumber(senderTaxNumber.substring(0, 8));
+ return result;
+ }
+
+ /*
+ A softwareId az adott számlázó program azonosítására szolgáló 18 elemű karaktersorozat.
+ A softwareId képzésére vonatkozó ajánlás: az azonosító első két karaktere a szoftvert fejlesztő cég
+ országkódja ISO 3166 alpha-2 szabvány szerint. Az azonosító további karakterei a fejlesztő cég adószám
+ törzsszáma, megfelelő számú számjegyen
+ */
+ public SoftwareType software() {
+ SoftwareType result = new SoftwareType();
+ result.setSoftwareId(String.format("HU-%s-000000", senderTaxNumber));
+ result.setSoftwareName("SLY-CRM");
+ result.setSoftwareOperation(SoftwareOperationType.ONLINE_SERVICE);
+ result.setSoftwareMainVersion("0.1.7");
+ result.setSoftwareDevName("User Rendszerház Kft.");
+ result.setSoftwareDevContact("Kovács Géza");
+ result.setSoftwareDevCountryCode("HU");
+ result.setSoftwareDevTaxNumber(senderTaxNumber);
+ return result;
+ }
+
+ /*
+ A mandatoryQueryParams típusban kötelező a 3 fő keresési feltétel közül egyet választani.
+ A keresés történhet:
+ a. invoiceIssueDate megadása esetén a számla vagy módosító okirat kiállításának naptári
+ napjára
+ b. insDate megadása esetén a számla vagy módosító okirat szerveroldali feldolgozásának
+ időpontjára, UTC időben
+ c. originalInvoiceNumber megadása esetén számlaláncra
+ */
+ public InvoiceQueryParamsType params() throws DatatypeConfigurationException {
+ MandatoryQueryParamsType mandatoryQueryParamsType = new MandatoryQueryParamsType();
+ DateIntervalParamType dateInterval = new DateIntervalParamType();
+ dateInterval.setDateFrom(DatatypeFactory.newInstance().newXMLGregorianCalendar(
+ LocalDateTime.now(ZoneOffset.UTC).minusDays(34).toString())
+ );
+ dateInterval.setDateTo(DatatypeFactory.newInstance().newXMLGregorianCalendar(LocalDateTime.now().toString()));
+ mandatoryQueryParamsType.setInvoiceIssueDate(dateInterval);
+ InvoiceQueryParamsType result = new InvoiceQueryParamsType();
+ result.setMandatoryQueryParams(mandatoryQueryParamsType);
+ return result;
+ }
+
+ /*
+ a requestSignature egyenlő a parciális hitelesítés SHA3-512 hash
+ értékével, amelyet a következő értékek összefűzéséből lehet megállapítani:
+ - a requestId értéke
+ - a timestamp tag értéke yyyyMMddHHmmss maszkkal, UTC időben
+ - a technikai felhasználó aláírókulcsának literál értéke
+ Az így és sorrendben konkatenált string nagybetűs SHA3-512 hash eredménye lesz a requestSignature
+ értéke.
+ */
+ private void calculateSimpleRequestSignature(QueryInvoiceDigestRequest request) {
+ ZonedDateTime zdt = request.getHeader().getTimestamp().toGregorianCalendar().toZonedDateTime();
+ ZonedDateTime zdtUTC = zdt.withZoneSameInstant(ZoneOffset.UTC);
+
+ String rsSignature = request.getHeader().getRequestId() +
+ DATE_TIME_FORMATTER.format(zdtUTC) +
+ signKey;
+
+ CryptoType reqCryptoType = new CryptoType();
+ reqCryptoType.setCryptoType("SHA3-512");
+ reqCryptoType.setValue(sha3_512Hex(rsSignature).toUpperCase());
+ request.getUser().setRequestSignature(reqCryptoType);
+ }
+
+ /* Java 9 fölött már támogatott 3rd party nélkül is*/
+ private String sha3_512Hex(String input) {
+ SHA3.DigestSHA3 digestSHA3 = new SHA3.Digest512();
+ byte[] digest = digestSHA3.digest(input.getBytes());
+ return Hex.toHexString(digest);
+ }
+
+ public QueryInvoiceDigestRequest requestInvoiceDigest() throws DatatypeConfigurationException {
+ QueryInvoiceDigestRequest result = new QueryInvoiceDigestRequest();
+ result.setHeader(header());
+ result.setUser(user());
+ result.setSoftware(software());
+ calculateSimpleRequestSignature(result);
+ return result;
+ }
+
+}
--- /dev/null
+package hu.user.lis.service.nav;
+
+import jakarta.xml.bind.JAXBContext;
+import jakarta.xml.bind.Marshaller;
+import jakarta.xml.bind.Unmarshaller;
+import jakarta.xml.bind.annotation.adapters.NormalizedStringAdapter;
+import lombok.extern.log4j.Log4j2;
+import org.springframework.stereotype.Component;
+
+import java.io.ByteArrayOutputStream;
+import java.io.StringReader;
+import java.nio.charset.StandardCharsets;
+import java.nio.file.Files;
+import java.nio.file.Path;
+import java.util.Optional;
+
+@Log4j2
+@Component
+public class TaxOfficeXmlConverter {
+
+ public <T> Optional<T> fromFile(Path file, Class<T> clazz) {
+ Optional<T> result = Optional.empty();
+ try {
+ String xml = new String(Files.readAllBytes(file), StandardCharsets.UTF_8);
+ result = fromXml(xml, clazz);
+ } catch (Exception e) {
+ log.error("Error while deserializing the file {} to Object of type {}. System message: {}", file, clazz, e.getMessage());
+ }
+ return result;
+ }
+
+ public <T> Optional<T> fromXml(String xml, Class<T> clazz) {
+ Optional<T> result = Optional.empty();
+ try {
+ Unmarshaller unmarshaller = JAXBContext.newInstance(clazz).createUnmarshaller();
+ unmarshaller.setAdapter(new NormalizedStringAdapter());
+ result = Optional.ofNullable(clazz.cast(unmarshaller.unmarshal(new StringReader(xml))));
+ } catch (Exception e) {
+ log.error("Error while deserializing a XML text to Object of type {}. System message: {}", clazz, e.getMessage());
+ }
+ return result;
+ }
+
+ public String toXml(Object query) {
+ try (ByteArrayOutputStream outStream = new ByteArrayOutputStream()) {
+ JAXBContext jc = JAXBContext.newInstance(query.getClass());
+ Marshaller marshaller = jc.createMarshaller();
+ marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
+ marshaller.setProperty(Marshaller.JAXB_ENCODING, StandardCharsets.UTF_8.toString());
+ marshaller.marshal(query, outStream);
+ return outStream.toString();
+ } catch (Exception e) {
+ log.error(e);
+ }
+ return "";
+ }
+
+}
--- /dev/null
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+# Project: Magyar Online Számla Rendszer invoiceAnnulment XML séma
+# Author: NAV Informatikai Intézet
+
+# Version: v3.0 2020/07/31
+-->
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common"
+ xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base" xmlns="http://schemas.nav.gov.hu/OSA/3.0/annul"
+ targetNamespace="http://schemas.nav.gov.hu/OSA/3.0/annul" elementFormDefault="qualified"
+ attributeFormDefault="unqualified">
+ <xs:import namespace="http://schemas.nav.gov.hu/NTCA/1.0/common"/>
+ <xs:import namespace="http://schemas.nav.gov.hu/OSA/3.0/base" schemaLocation="invoiceBase.xsd"/>
+ <xs:simpleType name="AnnulmentCodeType">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">Technikai érvénytelenítés kód típusa</xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment code type</xs:documentation>
+ </xs:annotation>
+ <xs:restriction base="common:AtomicStringType32">
+ <xs:enumeration value="ERRATIC_DATA">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">Hibás adattartalom miatti technikai érvénytelenítés
+ </xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment due to erratic data content</xs:documentation>
+ </xs:annotation>
+ </xs:enumeration>
+ <xs:enumeration value="ERRATIC_INVOICE_NUMBER">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">Hibás számlaszám miatti technikai érvénytelenítés</xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment due to erratic invoice number</xs:documentation>
+ </xs:annotation>
+ </xs:enumeration>
+ <xs:enumeration value="ERRATIC_INVOICE_ISSUE_DATE">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">Hibás számla kiállítási dátum miatti technikai érvénytelenítés
+ </xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment due to erratic invoice issue date
+ </xs:documentation>
+ </xs:annotation>
+ </xs:enumeration>
+ <xs:enumeration value="ERRATIC_ELECTRONIC_HASH_VALUE">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">Hibás elektronikus számla hash érték miatti technikai
+ érvénytelenítés
+ </xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment due to erratic electronic invoice hash value
+ </xs:documentation>
+ </xs:annotation>
+ </xs:enumeration>
+ </xs:restriction>
+ </xs:simpleType>
+ <xs:complexType name="InvoiceAnnulmentType">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">Korábbi adatszolgáltatás technikai érvénytelenítésének adatai
+ </xs:documentation>
+ <xs:documentation xml:lang="en">Data of technical annulment concerning previous data exchange
+ </xs:documentation>
+ </xs:annotation>
+ <xs:sequence>
+ <xs:element name="annulmentReference" type="common:SimpleText50NotBlankType">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">A technikai érvénytelenítéssel érintett számla vagy módosító okirat
+ sorszáma
+ </xs:documentation>
+ <xs:documentation xml:lang="en">Sequential number of the invoice or modification document to be
+ annuled
+ </xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="annulmentTimestamp" type="base:InvoiceTimestampType">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">A technikai érvénytelenítés időbélyege a forrásrendszerben UTC idő
+ szerint
+ </xs:documentation>
+ <xs:documentation xml:lang="en">Timestamp of the technical annulment in UTC time</xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="annulmentCode" type="AnnulmentCodeType">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">A technikai érvénytelenítés kódja</xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment code</xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ <xs:element name="annulmentReason" type="common:SimpleText1024NotBlankType">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">A technikai érvénytelenítés oka</xs:documentation>
+ <xs:documentation xml:lang="en">Technical annulment reason</xs:documentation>
+ </xs:annotation>
+ </xs:element>
+ </xs:sequence>
+ </xs:complexType>
+ <xs:element name="InvoiceAnnulment">
+ <xs:annotation>
+ <xs:documentation xml:lang="hu">XML root element, a technikai érvénytelenítés adatait leíró típus, amelyet
+ BASE64 kódoltan tartalmaz az invoiceApi sémaleíró invoiceAnnulment elementje
+ </xs:documentation>
+ <xs:documentation xml:lang="en">XML root element, technical annulment data type in BASE64 encoding,
+ equivalent with the invoiceApi schema definition's invoiceAnnulment element
+ </xs:documentation>
+ </xs:annotation>
+ <xs:complexType>
+ <xs:complexContent>
+ <xs:extension base="InvoiceAnnulmentType"/>
+ </xs:complexContent>
+ </xs:complexType>
+ </xs:element>
+</xs:schema>
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
-<jaxb:bindings version="3.0" xmlns:jaxb="https://jakarta.ee/xml/ns/jaxb"
- xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc" xmlns:xs="http://www.w3.org/2001/XMLSchema"
- jaxb:extensionBindingPrefixes="xjc">
-
- <jaxb:globalBindings>
- <xjc:simple />
- <xjc:serializable uid="-1" />
- <jaxb:javaType name="java.util.Calendar" xmlType="xs:dateTime"
- parseMethod="jakarta.xml.bind.DatatypeConverter.parseDateTime"
- printMethod="jakarta.xml.bind.DatatypeConverter.printDateTime" />
- </jaxb:globalBindings>
-</jaxb:bindings>
\ No newline at end of file
+++ /dev/null
-# Changelog 2.0
-
-`scroll down for English version`
-
-Változtatások 1.1-ről 2.0-ra.
-
-## 1) A módosítás igénye általánosságban
-A 2.0-ás interfész verzió bevezetésének igénye kettős. Egyrészről, a rendszer 2018 júliusi éles indulása óta eltelt idő keletkeztetett annyi új lehetőséget és igényt, hogy megérje a számlabejelentő interfészből egy új nagy verzióban gondolkodni, másrészt az 1.0 verzió számos inkonzisztenciát és hiányosságot tartalmaz, melyeknek a kivezetésére megérett az idő. A 2.0-ás verzió tehát egyaránt tartalmaz új funkcionalitást és refaktot is. Figyelemmel arra, hogy nagy verzióról van szó és a változások breaking change-t jelentenek mind szerver mind kliens oldalon, a 2.0-ás séma új namespace-t kap. Nagy valószínűséggel számítani kell arra is, hogy a 2.0-ás üzeneteket a rendszer más URL-en fogadja majd mint jelenleg.
-
-### 1.1) Megoldani kívánt főbb problémák:
-
-- A technikai érvénytelenítés osztozik a számlabeküldésre használt /manageInvoice operációval az API struktúrában (ami miatt például lehet tömörítve is beküldeni, ami teljesen értelmetlen) miközben a belső tartalom függ a Data XSD-től is. Az összekapcsolás felesleges tageket (pl: technicalAnnulment boolean megadása) vagy más inkonzisztenciát (pl számla lekérdezésben lehetséges az ANNUL, mint operációs paraméter használata, amire sosincs találat) eredményez, és ellehetetleníti hosszútávon a /manageInvoice operáció moduláris bővítését.
-- A számla lekérdezésben használt /queryInvoiceData operációban a bemenet és a kimenet is choice ami antipattern, továbbá ez miatt a válaszban nem lehet azt a méretkorlátot garantálni, ami a beküldések során a POST body méretére vonatkozik.
-- A feldolgozás státusz lekérdezésre használt /queryInvoiceStatus operáció válaszában nem látszik a mentés ténye, azaz nem lehet tudni, mikortól lehet a módosító számláról adatot szolgáltatni. Ez eredményez olyan paradox eseteket, hogy a tranzakció még nincs teljesen feldolgozva, de az egyes számlák már lekérdezhetők mentett számlaként akár a felületen, akár az interfészen.
-- A technikai érvénytelenítés jóváhagyási státusza nem kérdezhető le az API-n keresztül, így sem az újraküldés, sem más erre épülő folyamat nem automatizálható kliens oldalon.
-- A vevő oldali számlalekérdezés nem lehetséges API-n keresztül.
-- Az egyes módosító számlák modificationTimestamp alapján sorrendezhetők, de sem egyediséget, sem sorfolytonosságot nem lehet vizsgálni.
-- Nem lehet 1 számlával több számlát módosítani.
-- A számla kelte és a módosító okirat kelte 2 külön tag a sémaleíróban, ami a lekérdezésekben felesleges bonyodalmakat okoz.
-- A frontendes és az API-s keresés nem egységes az egyenlőség és a kisebb-nagyobb relációk keresésében, plusz a kisebb-mint és nagyobb-mint keresőmezők XML struktúrája indokolatlanul terjengős.
-- Az API XSD-ben rossz a típusosság számos kérés-és válasz elemre, az objektumok nem minden esetben generálhatók le helyesen.
-- A CRC32 ellenőrző algoritmust le kell váltani egy kritográfiai hash függvénnyel, ami a teljes üzleti tartalmat védi.
-- Nincs a rendszer működéséről metrika lekérdezési lehetőség.
-
-### 1.2) A tervezett megoldások
-
-- A technikai érvénytelenítés leválasztásra kerül a /manageInvoice operációról és saját operációt kap, melynek neve /manageAnnulment. Az operációhoz előzetesen ugyanúgy tokent kell kérni, mint a számlabeküldéshez. Az operáción belül ugyan úgy legfeljebb 100 indexig küldhető be technikai érvénytelenítés. Az egyes tételekhez kapcsolódó operáció külön singleType-ot kap, jelenleg egyetlen felvehető értékkel, az ANNUL enummal. Azon tranzakciók, amelyek tartalmaznak az ANNUL operáción kívül más műveletet is, szinkron ERROR hibával elutasításra kerülnek, tehát a tranzakciók homogenitását (vagy kizárólag adatszolgáltatás, vagy kizárólag technikai érvénytelenítés) továbbra is be kell tartani. Az érvénytelenítési adatokat ugyan úgy base64 kódoltan kell küldeni. A technikai érvénytelenítés adatai külön sémaleíróba, az invoiceAnnulment.XSD-be kerülnek, így az már független a data sémaleírótól. A szerver a kérésre ugyan úgy tranzakció azonosítót válaszol. Ezzel párhuzamosan a /manageInvoice kérésben a technicalAnnulment boolean törlésre kerül, és operációként csak CREATE, MODIFY, STORNO adható meg, ANNUL már nem.
-- A korábbi homogén /queryInvoiceData operációból leválasztásra kerül a paraméteres keresés. A jelenlegi sémában a /queryInvoiceData keresőparaméterként csak számlaszámot fogad el, ezen felül kötelező egy új, invoiceDirection nevű tagban megadni, hogy a számlát kiállítóként vagy vevőként akarjuk-e lekérdezni. Ez rendezi a vevő oldali számla lekérdezés egyik felét is. A válaszban csak a lekérdezett számlaszám teljes adattartalma kerül visszaadásra, plusz az eddigi csomópontok (auditData, invoiceReference, compressedContentIndicator).
-> Felhívjuk a figyelmet, hogy vevő oldali számlalekérdezés az interfészen is csak akkor lehetséges, ha a vevő adószáma ki van töltve az adatszolgáltatásban. A vevői adószámot nem tartalmazó számlák nem kereshetők!
-- A paraméteres lekérdezés új operációja a /queryInvoiceDigest lesz. Mivel invoiceDirection ebben a kérésben is szerepel, ezzel egyben lehetőség van a vevő oldali számlák paraméteres lekérdezésére is. A keresőparaméterek teljesen új struktúrában adhatók meg, külön csomópontja van a kötelező, az opcionális, a relációs és a tranzakciós paramétereknek is. Az operáció válaszként csak digestet ad vissza, teljes tartalmat már sosem. Ha a listából szükség van valamely számlának a teljes tartalmára, akkor azt a /queryInvoiceData operációval le kell kérdezni.
-> Felhívjuk a figyelmet, hogy vevő oldali számlalekérdezés az interfészen is csak akkor lehetséges, ha a vevő adószáma ki van töltve az adatszolgáltatásban. A vevői adószámot nem tartalmazó számlák nem kereshetők!
-* Kötelező kereső paraméternek vagy kiállítási dátum tartományt, a beszúrás (feldolgozás) dátum tartományt, vagy az alapbizonylat sorszámát kell megadni.
-* Dátum tartomány megadása esetén a működés és a válasz az eddigieknek megfelelő, míg az alapbizonylat sorszám megadásakor az összes olyan számla kivonat visszaadásra kerül, amely az adott számlaszámra hivatkozik.
-* Az opcionális kereső paraméterek közé bekerült az ÁFA csoport tagjának adószáma és az adózó neve, melyet szintén vevői és kiállítói oldalon is meg lehet adni.
-* A relációs kereső paraméterek listaszerűen tartalmazzák a korábban kisebb-mint, nagyobb-mint relációkban kereshető értékeket. Az újdonság, hogy a keresett érték mellett egy ötös listából lehet kiválasztani a relációs operátort. (egyenlő, kisebb, nagyobb, kisebb-mint, nagyobb-mint) A jelenlegi struktúra a jövőbeni bővítéseket is sokkal egyszerűbbé teszi.
-* A relációs kereső paraméterek közé bekerül a fizetési határidő.
-* A tranzakciós kereső paraméterekben az átrendezésen kívül csak annyi a változás, hogy összhangban a /manageInvoice operációban kieső ANNUL értékre, keresőparaméternek itt is csak a CREATE, MODIFY, STORNO értékek adhatók már meg.
-* A digest lekérdezés lapozása 10 tételről 100 tételre változik.
-- A /queryInvoiceStatus válasza opcionálisan visszaad egy annulmentVerificationStatus taget, amely a technikai érvénytelenítés jóváhagyási státuszait tartalmazza, ha a kérésben megadott transactionId egy technikai érvénytelenítést tartalmazó tranzakcióra mutat.
-- A /queryInvoiceStatus operációban visszaadott invoiceStatus tag értékkészlete új elemmel, a SAVED értékkel bővült. A SAVED státusz sorrendben a PROCESSING és a DONE között áll, ekkor a tranzakció feldolgozása még nem fejeződött be, de az adott indexen lévő számla már elmentésre került, tehát az adatai lekérdezhetők, a rá módosító vagy stornó adatszolgáltatás már küldhető.
-> Felhívjuk a figyelmet, hogy a SAVED státusz visszaadása nem egyenlő azzal, hogy az adatszolgáltatási kötelezettség teljesült, ezt továbbra is kizárólag a DONE státusz jelzi! Ezért a feldolgozás státusz lekérdezést egészen addig folytatni kell, amíg a tranzakció alatt minden tétel DONE vagy ABORTED nem lesz!
-- Az API sémaleíróban minden kérés és válasz saját típust kapott.
-- A módosító számlák kezelése átalakul a data sémaleíróban. Az invoiceReference csomópontból törlésre kerül a modificationIssueDate, a modificationTimestamp és a lastModificationReference. A törlendők közül a modificationIssueDate fogalmilag összevonásra kerül az invoiceIssueDate taggel, így az a 2.0-tól a számla VAGY a módosító okirat kiállítását jelenti. A többi törölt taget a 2.0-ban nem kell küldeni. Új elemként megjelenik a modificationIndex, amelyben a kliens oldalnak kell a módosítás sorrendiségét jelezni. A tag értéke 1-től kezdődik, logikailag az első módosító vagy stornó számlának kell az 1-es értéket kapnia. A szerver oldalon az egyediség vizsgálatra biztosan ERROR kerül bevezetésre, a sorfolytonosság ellenőrzésének lehetőségét még vizsgáljuk. Amennyiben megvalósításra kerül a sorfolytonosság ellenőrzése is, úgy elképzelhető, hogy a szerver oldali feldolgozásba késleltetés kerül be, ekkor - feltéve, hogy az alapszámla már beérkezett a rendszerbe-, adott időkeret állna rendelkezésre az egyes módosító okirat adatszolgáltatására, és a sorfolytonosság csak a késleltetési idő leteltét követően kerülne vizsgálatra. A modificationIndex a /queryInvoiceDigest válaszában visszaadásra kerül arra az esetre, ha az alapbizonylatra több módosító okiratot állítottak volna ki eltérő számlázó rendszerekből, és a módosításkor nem ismert a helyes következő érték.
-* A törölt tagekkel egyidejűleg törlésre kerülnek azok a WARNING üzenetek, melyek ezek összefüggéseit vizsgálták.
-- Lehetőség nyílik egy számlával több számlát módosítani.
-* Ehhez elsőként szükség van arra, hogy a számlaszám és a számla kiállítának időpontja kikerüljön a jelenlegi helyéről, és az invoiceHead/invoiceData helyett rögtön legfelül, a root element után szerepeljen. A kiemelés azt is jelenti, hogy helytelen kiállítási dátum esetén logikailag nincs lehetőség a módosításra, ezért ennek javítására új technikai érvénytelenítési okot vezettünk be ERRATIC_INVOICE_ISSUE_DATE néven.
-* A kiemelést követően lehetőség van a sémában egy choice szerint eldönteni, hogy 'egyes' adatszolgáltatást vagy kötegelt adatszolgáltatást írunk le. Az egyes adatszolgáltatás struktúrája ugyan az, mint az 1.1-ben. A kötegelt adatszolgáltatást batchInvoice néven lehet megképezni. A batchInvoice alatt egy megszámlálhatatlan listaelemben bárhányszor lehet ismételni az 'egyes' adatszolgáltatás szerinti struktúrát, egy batchIndex képzésével.
-* A belső tartalomban batchInvoice taget értelemszerűen csak MODIFY vagy STORNO operációkban szabad képezni. További megkötés, hogy az ilyen adatszolgáltatásoknak kívül az API XML-ben csak 1 indexe lehet, tehát a kérés 100 helyett legfeljebb csak 1 adatszolgáltatást tartalmazhat ebben az esetben. Mindkét eset vizsgálatára új aszinkron ERROR kerül majd bevezetésre.
-> Egyelőre nem látjuk indokoltnak, hogy bevezessünk 2 új operációt erre az esetre, (pl: BATCH_MODIFY és BATCH_STORNO) de ez a jövőben még változhat.
-* A kötegelt módosítás feldolgozására vonatkozó hibaüzenetek könnyebb keresése miatt a /queryInvoiceStatus válaszában visszaadásra kerül az index mellett a batchIndex is, továbbá a pointerekbe mindenhol bekerül a hivatkozott számla száma, az originalInvoiceNumber is.
-* A kötegelt módosítás feldolgozása a technikai érvénytelenítés szabályai szerint fog történni, azaz amennyiben bármely batchIndex alatti tétel ERROR miatt elbukik, úgy az egész adatszolgáltatás is el fog bukni az ellenőrzésen.
-- Az adózó lekérdezésre használt /queryTaxpayer operáció visszaadja a lekérdezett adózó ÁFA csoport tagságát, valamint séma szinten tartalmazza az adózó rövid nevét.
-* A kliens oldali lekérdezések gyakorisága alkalmazás oldalon korlátozva lesz. Ennek kialakításánál a metrika visszaadás költsége is szempont lesz, így ennek hiányában pontos értéket még nem tudunk mondani.
-> Az operáció válasza egyelőre base64Binary, amint látjuk pontosan mi lesz benne, adunk ki külön XSD-t a tartalomhoz. Ez nem feltétlenül lesz a 2.0 része időben, de szeretnénk megteremteni már most a lehetőséget rá a sémában.
-- Az API-ban új operációként megjelenik egy /queryInvoiceCheck operáció. A szolgáltatáshoz alap authentikációt kell végezni, mint a token kérésnél. Siker esetén a rendszer visszaadja, hogy a lekérdetett számlaszám létezik-e érvényesként a rendszerben, feltéve, hogy a lekérdezést végző adózó szerepel a számlán kiállítóként vagy vevőként.
-
-### 1.3) A requestSignature számítása a 2.0 verziótól
-A requestSignature értékét a 2.0 verziótól minden operációban SHA2-512 helyett SHA3-512 függvénynel kell számolni.
-
-A /manageInvoice és a /manageAnnulment operációk alatt a requestSignature számítása továbbra is speciális. A változás az 1.1-hez képest, hogy ezekben az operációkban az indexenkénti részleges értékeket CRC32 helyett már SHA3-512 függvénnyel kell számolni, és az egyes indexek alatti operation és invoice tagek teljes tartalmát össze kell fűzni a számítás előtt.
-Például az alábbi index
-```xml
-<invoiceOperations>
- <compressedContent>false</compressedContent>
- <invoiceOperation>
- <index>1</index>
- <operation>CREATE</operation>
- <invoice>QWJjZDEyMzQ=</invoice>
- </invoiceOperation>
- </invoiceOperations>
-</ManageInvoiceRequest>
-```
-részleges hash értéke a következő
-```java
-'CREATE' + 'QWJjZDEyMzQ=' -> SHA3-512(CREATEQWJjZDEyMzQ=) -> 4317798460962869bc67f07c48ea7e4a3afa301513ceb87b8eb94ecf92bc220a89c480f87f0860e85e29a3b6c0463d4f29712c5ad48104a6486ce839dc2f24cb
-```
-A részleges hasheket index szerint monoton növekvő sorrendben össze kell fűzni, és az így képzett requestId+timestamp+signkey+konkatenált részleges hashekre kiszámolni a requestSignate értékét.
-> Egy későbbi pull requestben adni fogunk példa XML-eket is.
-
-## 2) Egyéb Módosítások
-A felsorolt főbb problémákon felül több adózói igény is érkezett egyes mezők hosszának vagy értékkészletének bővítésére, illetve számos más refakt elem is bekerül a sémaleírókba, az alábbiak szerint. Az összes módosítás tételes vizsgálatához össze lehet DIFF-elni a pull requestben szereplő 2.0-át az 1.1-es állapottal.
-
-### 2.1) API sémaleíró
-
-- software adatok küldése minden requestben kötelező, a belső elemekre új kötelezőségek kerültek
-- a queryInvoiceData request teljesen új típusra változott (InvoiceQueryType)
-- InvoiceResultType átnevezés -> InvoiceDataResultType
-- InvoiceQueryParamsType típus bővítése a csoport tag adószámával (groupMemberTaxNumber)
-- InvoiceQueryParamsType típusból az adószám paraméter törlése
-- InvoiceQueryResultType típus törlése
-- TaxpayerAddressType törlésre került, az adószám lekérdező válasza a data:DetailedAddressType típust használja a címadatokhoz
-- A beszúrás időpontja data:TimestampType típusra változott és UTC időre kerül konvertálásra a válaszban
-- batchIndex opcionálisan megadható az egyes számla lekérdezésekben
-- névkonvenció miatt a korábbi /queryInvoiceStatus operáció átnevezésre került /queryTransactionStatus operációra
-- a /queryTransactionStatus operáció válaszában szereplő processingResult listaelem számossága unbounded értékre módosult
-
-### 2.2) DATA sémaleíró
-
-- a lineExpressionIndicator tag kötelező, a LINE_EXPRESSION_INDICATOR_MISSING ellenőrzés 2.0-nál törölhető
-* a lineExpressionIndicator tag default értéke false
-- PostalCodeType új patternt kap, mostantól a szóköz és a kötőjel engedélyezett karakter (ha az nem a string elején vagy végén áll), a minimum hossz 3 karakterre csökkent
-- lineDescription tag bővítésre kerül 512 hosszúra
-- ProductCodeCategoryType új enum értéket kap (TESZOR), az új pattern hossz 5-ről 6-ra nő
-- productCodeOwnValue tag bővítésre kerül 255 hosszúra
-- invoiceDeliveryDate kötelező, a MANDATORY_CONTENT_MISSING ellenőrzés 2.0-nál törölhető
-- InvoiceDataType átnevezése -> InvoiceDetailType
-- IndexType kikerült az API-ból és a Data része lett
-- LineNumberType típusban korlátozásra került a megadható hossz 20 helyiértékre
-- QuantityType típus kiterjesztésre került 6-ról 10 tizedes jegyre
-- ExchangeRateType típus minimum értéke 0.00-ról 0-ra változott
-- TimestampType típusban opcionálissá vált a tört másodperc
-- az árrés adózáshoz a sémában fogalmilag összevonásra kerül az ellenérték és a nettó érték
-
-### 3) ÁFA analitika előkészítés
-
-A megfelelő bázis időszaki adatok előállításához a 3.0-ás interfész előtt már szükség van arra, ha a bejövő számlaadatok tartalmazzanak alap ÁFA analitikához szükséges információkat is.
-
-Ennek jegyében a számlasorokba új, opcionális minősítő tag került, a neve lineNatureIndicator. A tag értékkészlete alapján az egyes számlasorokban szereplő tételeket minősíteni kell a szerint, hogy a tétel termékértékesítésnek, szolgáltatás nyújtásnak vagy egyéb besorolásúnak minősül-e.
-
-Ezen felül, minden QuantityType és MonetaryType típusú elemben, az érték kifejezhető volt a számla pénznemében és forintban is, a nevezett elemek kiegészítésre kerültek a megfelelő párjukkal, az alábbiak szerint:
-
-- egységár forintban (line/unitPriceHUF)
-- tétel nettó összege forintban (invoiceLines/line/lineAmountsNormal/lineNetAmountData/lineNetAmountHUF)
-- tétel bruttó összege forintban (invoiceLines/line/lineAmountsNormal/lineGrossAmountData/lineGrossAmountNormalHUF)
-- tétel bruttó összege forintban (invoiceLines/line/lineAmountsSimplified/lineGrossAmountSimplifiedHUF)
-- számla bruttó összege forintban (invoiceSummary/summaryGrossData/invoiceGrossAmountHUF)
-- számla nettó összege forintban (invoiceSummary/summaryNormal/invoiceNetAmountHUF)
-- számla adótartalom bruttó összege forintban (invoiceSummary/summarySimplified/vatContentGrossAmountHUF)
-- adómérték nettó összege forintban (invoiceSummary/summaryNormal/summaryByVatRate/vatRateNetData/vatRateNetAmountHUF)
-- adómérték bruttó összege forintban (invoiceSummary/summaryNormal/summaryByVatRate/vatRateGrossData/vatRateGrossAmountHUF)
-
-Az elemek kötelezősége öröklődik a sémában már korábban definiált párjukból.
-
-4) Változások 2020.02.06-án
-
-### 4.1) API sémaleíró
-
-- a requestVersion és headerVersion tagekről lekerültek a default értékek, mostantól nem lehet önbezárt taget küldeni ezeknél
-- a /queryTaxpayer válaszában új elemek kerültek (infoDate, taxNumberDetail)
-- a /queryTaxpayer válaszában a címadat listatípusra módosult (taxpayerAddressItem), a címadatok mellett a taxpayerAddressType elemben a cím típusa (székhely, telephely, fióktelep)
-- a /queryInvoiceDigest kérésében az OriginalInvoiceNumberQueryType típus törlésre került, a mandatoryQueryParams/originalInvoiceNumber útvonal mostantól element, nem komplex típus
-- a /queryInvoiceDigest kérésében az additionalQueryParams típus bővítésre került a taxNumber paraméterrel, amely a megtalált eredményeket szűkíti a megadott adószámmal (a keresett mező a keresés irányától függ ugyan úgy, ahogy a csomópont többi eleménél). Ezt kell használni a korábbi originalInvoiceNumber/supplierTaxNumber szűrés megadására vevő oldali lekérdezéskor.
-- bevezetésre került a /queryInvoiceChainDigest operáció és a hozzá kapcsolódó request/response elemek
-- bevezetésre került a /queryTransactionList operáció és a hozzá kapcsolódó request/response elemek
-
-### 4.2) serviceMetrics sémaleíró
-
-- a rendszer publikus működési metrikáit és a lekérdezések válaszstruktúráját tartalmazó séma publikálásra került
-
---------------------------------------------------------------------------------------------------------------------------------------------
-
-# Changelog 2.0
-
-Comprehensive changes from 1.1 to 2.0.
-
-## 1) Reasons for the change in general
-
-There were two reasons for introducing the new 2.0 interface. First, many new opportunities and demands presented themselves since the actual launch of the system in July 2018, enough to justify considering a new major version for the invoicing interface. Second, Version 1.0 has a number of inconsistencies and shortcomings, and it is time to move beyond them. In other words, Version 2.0 contains both a new
-functionality and refactorations. As this is a major version and it involves breaking changes on both the server and client sides, the 2.0 schema will receive its own namespace. It is also quite probable that the system will use a different URL to receive 2.0 messages than the one used currently.
-
-### 1.1) Main problems requiring solutions:
-
-- Technical annulment shares the /manageInvoice operation in the API structure used for submitting invoices (which allows it to be submitted in a compressed format, for example, even though doing so is completely pointless) while the internal content also depends on Data XSD. Linking results in unnecessary tags (e.g. boolean for technicalAnnulment) or other inconsistencies (e.g. ANNUL can be used as an operational parameter when querying invoices, but will never find any matches) and will make it impossible to extend the /manageInvoice operation in a modular fashion in the long run.
-- The /queryInvoiceData operation used for querying invoices has both the input and output as choice. This is antipattern, and means that it is impossible to guarantee the POST body size limit for the response, as defined in the submissions.
-- The response to the /queryInvoiceStatus operation used for querying the processing status does not show whether the invoice has been saved, meaning that it is impossible to know from when data can be provided regarding the modifying invoice. This can result in paradoxical cases, where the transaction is not yet fully processed, but the individual invoices can nonetheless be queried as saved invoices, either on the screen or through the interface.
-- The approval status of technical annulment cannot be queried using the API, meaning that neither resubmission nor other processes conditional on resubmission can be automated on the client-side.
-- Invoices cannot be queried through the API customer-side.
-- While it is possible to sort the individual modifying invoices based on modificationTimestamp, it is not possible to verify uniqueness or sequentiality.
-- It is not possible to modify multiple invoices using a single invoice.
-- The issue date of the invoice and the issue date of the modifying document are two separate tags in the schema definition, which causes unnecessary complications in the queries.
-- The equality, smaller-than and greater-than relations used in searches done through the frontend and through the API are not consistent. In addition, the XML structure for the smaller-than and larger-than search fields is unnecessarily verbose.
-- The typing is incorrect for a number of request and response elements in the API XSD, meaning that it is not always possible to generate the objects correctly.
-- The CRC32 checksum code needs to be replaced with a cryptographic hash function capable of fully protecting the business-related content.
-- There is no metric query option regarding the system’s operation.
-
-### 1.2) Planned solutions
-
-- Technical annulment will be separated from the /manageInvoic operation, and will receive its own operation named /manageAnnulment. A token will need to be requested for the operation in advance, the same way as for submitting an invoice. Just as before, it will be possible to submit a technical annulment using the operation, up to 100 indexes. The operation associated with individual items will be given a separate singleType, currently with a single assignable value, which is the ANNUL enum. Transactions containing operations other than ANNUL will be rejected with a synchronous ERROR message, meaning that the transactions must still remain homogenous (purely data exchange, or purely technical annulment.) Annulment data must be sent coded in base64, just as before. A separate schema definition, invoiceAnnulment.XSD will be used for technical annulment data, meaning that it will be independent of the data schema definition. The server will still respond to the request with a transaction identifier, as before. In addition, the technicalAnnulment boolean will be deleted from the /manageInvoice request, meaning that only CREATE, MODIFY, and STORNO can be entered as operations, ANNUL is no longer valid.
-- Parametric search will be separated from the previously homogeneous /queryInvoiceData operation. In the current schema, /queryInvoiceData only accepts an invoice number as a search parameter. In addition, there is a new invoiceDirection tag, in which it is mandatory to specify whether you wish to query the invoice as an issuer or a customer. This also settles one half of customer-side invoice queries. The response will only include the total data content of the queried invoice number, plus the previous nodes (auditData, invoiceReference, compressedContentIndicator).
-> Please note that the interface will also only allow customer-side invoice queries if the customer’s tax number is filled out in the data exchange. Invoices without customer tax numbers cannot be queried!
-- There will be a new operation for parametric queries, /queryInvoiceDigest. As this request also includes invoiceDirection, it will also be possible to perform a customer-side parametric query of the invoices. Search parameters can be structured completely differently. Mandatory, optional, relational and transactional parameters will all have different nodes. The operation will only provide a digest as a response, never the full content any more. If you need the full content for one of the invoices from the list, you can use the /queryInvoiceData operation to query it.
-> Please note that the interface will also only allow customer-side invoice queries if the customer’s tax number is filled out in the data exchange. Invoices without customer tax numbers cannot be queried!
-- You must provide either an issue or insert date range or the invoice number of the base document as a mandatory search parameter.
-- When providing an issue data range, both the operation and the response will work the same way as they have before, whereas when providing the invoice number of the base document, all invoices referencing the provided invoice number will be returned.
-- The optional search parameters now include the tax number for the VAT group member and the name of the taxpayer, which can also be entered either as a customer or as an issuer.
-- The relational search parameters will now list the search values that could be searched previously in smaller-than and greater-than relations. What is new is that you can now select a relational operator from a list of five, in addition to the value searched (equal, smaller, greater, smaller-than, greater-than.) The current structure also makes future extensions much simpler.
-- Relational query for invoice payment date is now possible.
-- The paging parameter of the digest query is increased from 10 to 100 items.
-- In addition to the reorganisation, the only change made to the transactional search parameters is that much like the way the ANNUL value was removed from the /manageInvoice operation, only the CREATE, MODIFY, STORNO values can now be provided as search parameters here as well.
-- The response for /queryInvoiceStatus can optionally include an annulmentVerificationStatus tag containing the approval status of the technical annulment, as long as the transactionId provided in the request references a transaction containing a technical annulment.
-- The invoiceStatus tag value set returned in the /queryInvoiceStatus operation now has a new element, the value SAVED. The SAVED status is sequentially between PROCESSING and DONE, when the processing of the transaction is not yet completed, but the invoice for the index provided has already been saved, meaning that its data can be queried, and it is ready for data exchange modifying or cancelling it.
-> Please note that a returned status of SAVED does not mean that data exchange obligations have been met, DONE is still the only status signifying that! Accordingly, the processing status queries should continue until all line items for the transaction are DONE or ABORTED.
-- All requests and responses in the API schema definition have been assigned their own type.
-- Modifying invoices will be handled differently in the data schema definition. The modificationIssueDate, modificationTimestamp and lastModificationReference tags will be deleted from the invoiceReference node. Of these, modificationIssueDate will be conceptually merged with the invoiceIssueDate tag, meaning that as of Version 2.0, it will refer to the issue date of the invoice OR the modifying document. The other deleted tags will no longer need to be submitted in Version 2.0. There will also be a new element, modificationIndex, which should be filled out client-side to define the sequence of the modification. The value of the tag starts with 1, meaning that logically, the first modifying or cancelling invoice should be assigned a modificationIndex of 1. Uniqueness verification will definitely return an ERROR server-side, we are still investigating the possibility of sequentiality verification. If sequentiality verification is implemented, we may introduce a delay into server-side processing. In this case – provided that the system has already received the base invoice – there would be a predefined time frame available for the data exchange for the individual modification document, and sequentiality would only be tested after the expiry of the delay time. The /queryInvoiceDigest response will return the modificationIndex if several modifying documents were issued for the base document from different invoicing systems, and the correct next value in the sequence is not known at the time of modification.
-- Along with the deleted tags, the WARNING messages used for investigating these relationships will also be deleted.
-- It will be possible to modify multiple invoices using a single invoice.
-- To do this, the first step is to move the invoice number and the invoice issue date from their current location, invoiceHead/invoiceData, and to include them right at the top, after the root element. This will also mean that the logic will not permit modifying an incorrect issue date. Therefore, to allow for doing so, we have introduced a new technical annulment reason, named ERRATIC_INVOICE_ISSUE_DATE.
-- After moving the invoice number and the invoice issue date up to the top, the schema includes a choice defining whether it is a “singular” or a batch data exchange. The structure for a singular data exchange is identical to that in Version 1.1. Batch data exchanges can be created under the name batchInvoice. Under a batchInvoice element, you can repeat the “singular” data exchange structure any number of times in a non-enumerated list, by generating a batchIndex.
-- In internal content, the batchInvoice tag should, of course, only be generated for MODIFY or STORNO operations. There is an additional restriction: data exchanges of this nature can only have 1 external index in the API XML, meaning that in these cases, the request can only include 1 data exchange instead of the usual 100. A new asynchronous ERROR will be introduced for both cases.
-> We do not currently see a justification for introducing 2 new operations to handle these cases (e.g. BATCH_MODIFY and BATCH_STORNO), but this could change in the future.
-- To allow for searching batch processing error messages more easily, the response to /queryInvoiceStatus will return both index and batchIndex. In addition, all of the pointers will also include the referenced invoice number, originalInvoiceNumber.
-- Batch modifications will be processed according to the rules of technical annulment, i.e. if any batchIndex item fails due to an ERROR, the entire data exchange will fail verification.
-- The /queryTaxpayer operation used for taxpayer query now will return the VAT group membership of the taxpayer, and now contains the shortened name on schema level.
-- The frequency of client-side queries will be restricted on the application side. When designing this function, the cost of returning metrics will also be an aspect, therefore we cannot provide an precise value yet in the absence thereof.
-> The response of the operation is currently base64Binary, and we will provide a separate XSD for the content as soon as we know exactly what will be included in it. This functionality will not necessarily be ready in time to make it into Version 2.0, but we would already like to create an option in the schema for it.
-- The API will include a new operation, /queryInvoiceCheck. Using the service will require basic authentication, much like in the case of token requests. If successful, the system will return the fact of existence of the invoice, provided the invoice is valid and the tax number of the querying entity is present on the invoice as supplier or customer.
-
-### 1.3) The calculation of requestSignature, as of Version 2.0
-
-As of Version 2.0, the value of requestSignature should be calculated using SHA3-512 instead of SHA2-512 for all operations.
-
-The calculation of requestSignature for the /manageInvoice and /manageAnnulment operations is still an exception. The difference, in
-comparison to Version 1.1, is that the indexwise partial values for these operations should be calculated using SHA3-512 instead of CRC32,
-and the full content of the operation and invoice tags under the individual indexes should be concatenated before calculating. For example, the partial hash value for index 1, given the following
-
-```xml
-<invoiceOperations>
- <compressedContent>false</compressedContent>
- <invoiceOperation>
- <index>1</index>
- <operation>CREATE</operation>
- <invoice>QWJjZDEyMzQ=</invoice>
- </invoiceOperation>
- </invoiceOperations>
-</ManageInvoiceRequest>
-```
-
-will be
-
-```java
-'CREATE' + 'QWJjZDEyMzQ=' -> SHA3-512(CREATEQWJjZDEyMzQ=) -> 4317798460962869bc67f07c48ea7e4a3afa301513ceb87b8eb94ecf92bc220a89c480f87f0860e85e29a3b6c0463d4f29712c5ad48104a6486ce839dc2f24cb
-```
-
-The partial hashes should be concatenated in ascending order of index, then the requestSignate value for the resulting requestId+timestamp+signkey+concatenated partial hashes should be calculated.
-> We will provide example XMLs as well in a future pull request.
-
-## 2) Other changes
-
-In addition to the main problems listed, we have received a number of taxpayer requests for extending the length or value set of various
-fields, and a number of other refactored elements will also be included in the schema definitions, as per the following. To check all the
-changes in detail, simply DIFF Version 2.0 and Version 1.1 in the pull request.
-
-### 2.1) API schema definition
-
-- software data must be sent in all requests, and there are new mandatory requirements for the internal elements
-- the queryInvoiceData request has been changed to a completely new type (InvoiceQueryType)
-- InvoiceResultType renamed -> InvoiceDataResultType
-- InvoiceQueryParamsType was extended with the tax number for the group member (groupMemberTaxNumber)
-- the tax number parameter was deleted from InvoiceQueryParamsType
-- InvoiceQueryResultType was deleted
-- TaxpayerAddressType was deleted, the response to tax number queries will use data:DetailedAddressType for address data (if the tagged address cannot be returned due to the requirements described by the response, we will fill out the missing tags with a uniform signifier defined in the specification, e.g. N/A)
-- insert date is now changed to data:TimestampType and the value is converted to UTC time in the response
-- batchIndex may be optionaly provided in single invoice queries
-- the previous /queryInvoiceStatus operation is now renamed to /queryTransactionStatus operation due to naming convention
-- the cardinality of the processingRequest list element in the response of /queryTransactionStatus operation is now unbounded
-
-### 2.2) DATA schema definition
-
-- the lineExpressionIndicator tag is mandatory, the LINE_EXPRESSION_INDICATOR_MISSING verification can be deleted in Version 2.0
-- the default value of the lineExpressionIndicator tag is false
-- PostalCodeType will be given a new pattern: from now on, space and hyphen characters are allowed (as long as they are not at the start or the end of a string), and the minimum length has now been reduced to 3 characters
-- the lineDescription tag is extended to a length of 512 characters
-- ProductCodeCategoryType now has a new enum value (TESZOR), the length of the new pattern is extended from 5 to 6
-- the productCodeOwnValue tag is extended to a length of 255 characters
-- invoiceDeliveryDate tag is mandatory, the MANDATORY_CONTENT_MISSING verification can be deleted in Version 2.0
-- InvoiceDataType renamed -> InvoiceDetailType
-- IndexType was removed from the API, and is now a part of Data
-- LineNumberType is now restricted to 20 digits length
-- QuantityType is extended from 6 to 10 fracture digits
-- ExchangeRateType lower bound is changed from 0.00 to 0
-- Fraction seconds in TimestampType are now optional
-- For margin scheme taxation, consideration and net amount is now treated as identical notions in the schema
-
-### 3) VAT analytics preparation
-
-In order to have adequate base interval data it is necessary to have the incoming data to carry basic VAT analytics related data even before interface version 3.0.
-
-In light of this endeavour, line data has been supplemented with a new optional qualifier tag named lineNatureIndicator. Based on its values, all lines need to be classified whether they are supply of goods, supply of services or other .
-
-Furthermore, every QuantityType és MonetaryType element - where it is possible to express the value in the currency of the invoice or in HUF - have been supplemented with their corresponding pair as follows:
-
-- unit price in HUF (line/unitPriceHUF)
-- line net amount in HUF (invoiceLines/line/lineAmountsNormal/lineNetAmountData/lineNetAmountHUF)
-- line gross amount in HUF (invoiceLines/line/lineAmountsNormal/lineGrossAmountData/lineGrossAmountNormalHUF)
-- line gross amount in HUF (invoiceLines/line/lineAmountsSimplified/lineGrossAmountSimplifiedHUF)
-- summary gross amount in HUF (invoiceSummary/summaryGrossData/invoiceGrossAmountHUF)
-- summary net amount in HUF (invoiceSummary/summaryNormal/invoiceNetAmountHUF)
-- gross content summary in HUF (invoiceSummary/summarySimplified/vatContentGrossAmountHUF)
-- VAT rate net amount in HUF (invoiceSummary/summaryNormal/summaryByVatRate/vatRateNetData/vatRateNetAmountHUF)
-- VAT rate gross amount in HUF (invoiceSummary/summaryNormal/summaryByVatRate/vatRateGrossData/vatRateGrossAmountHUF)
-
-Cardinality of the new elements is inherited from their pair previously defined in the schema.
-
-4) Changes on 06.02.2020
-
-### 4.1) API schema definition
-
-- default values of requestVersion and headerVersion elements are discarded, it not possible from now on to send self-closed tags
-- the response of /queryTaxpayer now contains new elements (infoDate, taxNumberDetail)
-- the address element in the response of /queryTaxpayer is now a list type (taxpayerAddressItem), and the qualifier of the addresses (hq, branch, site) is also returned
-- OriginalInvoiceNumberQueryType in the request of /queryInvoiceDigest is deleted, the mandatoryQueryParams/originalInvoiceNumber path is now an element, not a complex type
-- the additionalQueryParams type in the request of /queryInvoiceDigest is now extended with the taxNumber param, which filters the found invoices with the provided tax number. (the searched field is depending on the direction of the query, just like in case of the other similar elements) This tag must be used for setting the previous originalInvoiceNumber/supplierTaxNumber serch criteria in case of an inbound query.
-- /queryInvoiceChainDigest operation is now added, along with it's own request/response elements
-- /queryTransactionList operation is now added, along with it's own request/response elements
-
-### 4.2) serviceMetrics schema definition
-
-- the schema containing the response structure of the system's public operational metrics is now public
\ No newline at end of file
+++ /dev/null
-# Changelog 3.0
-
-`scroll down for English version`
-
-Változtatások 2.0-ról 3.0-ra.
-
-## 1) A módosítás igénye általánosságban
-
-A módosítási igények - ahogy a 2.0 esetében is voltak - ezúttal is többrétűek. Egyrészről szükséges biztosítani azt, hogy 2021.01.04-től a rendszer képes legyen fogadni API-n keresztül a magánszemélyeknek kiállított, közösségi és az export számlákat is. Másrészről az Online számla projekt elérkezett ahhoz a szakaszához, ahol már - tervezetten - nem akarunk a 3.0-ás állapothoz képest új XML API verziót kiadni (csak jogszabályi változás vagy nagyobb horderejű igény jövőbeni megjelenése esetén, és akkor sem biztos hogy ez nagy verzió lesz), ezért fenntarthatósági és hosszú távon fontos egyéb szempontokat is figyelembe akartunk venni. Ennek okán megkíséreltük kisimítani az összes olyan problémát az API-ból, ami eddig üzletileg vagy technikailag problémaként felmerült és olyan megoldást találni rá, amely mindkét oldal számára kielégítő. Legvégül de nem utolsó sorban pedig szükség van azon hiányzó adatok pótlására vagy nevesítésére, amelyek birtokában az ÁFA bevallási tervezetek pontosabban elkészíthetők.
-
-### 1.1) A tervezett megoldások
-
-- A 3.0-ás API egyik fő sarokköve az elektronikus számlázás katalizálása és használhatóbbá tétele. Ennek érdekében az API XML-ben megadható lesz az electronicInvoiceHash elem, amely az elektronikus számlák hash lenyomatát tartalmazza. Ez a módosítás még csak azt biztosítja, hogy a számla kiállítás és a számla módosítás során az üzleti adatok és a hash lenyomatok elválaszthatók lesznek egymástól. A módosítással az is kimondásra került, hogy az API nem támogatja azt a használati esetet, amikor csak az eredeti számla hash helyesbítése miatt érkezne be módosító adatszolgáltatás, ezért erre nem is biztosítunk beviteli lehetőséget. Az elektronikus hash miatt hibás adatszolgáltatások csak technikai érvénytelenítéssel javíthatók, ez miatt új érvénytelenítési ok került az Annulment sémába.
-- Az elektronikus számlázás támogatását érintő másik fő változás, hogy a sémába bekerül egy olyan kötelező, completenessIndicator nevű jelölő, amelyben nyilatkozni lehet arról, hogy a 3.0-ás adatszolgáltatás keretében - az adózó saját döntése alapján - maga az elektronikus számla lesz beküldve, a séma szerinti XML formátumban, teljes adattartalommal. Ily módon a vevő már az adatszolgáltatás birtokában befogadhatja és kontírozhatja a számlát, nincs szükség további kézbesítésre, sem pedig az adatszolgáltatás és a számla későbbi (akár manuális) összehasonlítására. A jogszabályi környezet igazodni fog ehhez a változáshoz, a NAV ki fogja kényszeríteni ezen adatszolgáltatások esetében hogy az adatok integritása ne sérülhessen. Ezen számlák esetében az electronicInvoiceHash elemet az interfész dokumentációban meghatározott módon kell majd számolni és annak helyesnek is kell lennie. Ezen adatszolgáltatásokat továbbá nem lehet majd technikailag érvényteleníteni, tekintettel arra hogy a számla és az adatszolgáltatás között nem lehet eltérés, mivel az adatszolgáltatás maga a számla. Az ilyen számlákból készült számlaláncokra a NAV ezt a szolgáltatást csak bizonyos megkötésekkel biztosítja. (ld. ERROR módosítások fejezet) A funkciót csak 2021.01.04-től lehet igénybe venni, ezt megelőzően a feldolgozás átmeneti hibakóddal el lesz utasítva.
-- A projekt indulása óta érdemben megoldatlan az ún. nagyméretű adatszolgáltatások problémája, amikor a POST body size meghaladja a 10 MB-t. Ez jellemzően olyan számlakiállítók esetében fordul elő kis számban, akik szektorális jogszabály alapján nagyon részletes számlát kell hogy kiállítsanak, pl telekommunikációs és közüzemi szolgáltatók. Ugyanakkor az ÁFA törvény messze nem vár el ilyen részletezettségű számlaadatokat, és az adatszolgáltatási kötelezettség is kizárólag az ÁFA törvény által előírt kötelező adattartalomra vonatkozik. Az interfész dokumentációt bővítjük egy olyan módszertani útmutatóval, amely segítségével ezeket az adatszolgáltatásokat termék és szolgáltatás alapján össze lehet vonni, miáltal a méret lecsökkenthető 10 Mb alá, a NAV számára releváns üzleti adat elvesztése nélkül. Az ilyen adatszolgáltatásokat a számlasorok felett egy új, mergedItemIndicator nevű kötelező jelölővel kell ellátni.
-- 2021.01.04-től kötelező adatot szolgáltatni a közösségi export számlákról, illetve a nem ÁFA alanyok számára kiállított számlákról is. Ezeknek a fogadásához a customerInfo csomópont átalakul, ennek segítségével elkülöníthetők a belföldi, közösségi valamint harmadik országos számlák illetve a magánszemély vevőknek szóló számlák is. Szintén változás, hogy a 3.0-ban a magyar, közösségi és harmadik országos adószámok nem írhatók fel egymás mellé, kizárólag egyet lehet közülük megadni. (technikailag a korábbi sequence choice stuktúrává alakul) A magánszemélynek (ide nem értve az adószámos magánszemélyt, illetve az egyéni vállalkozót) kiállított számla adatszolgáltatása nem tartalmazhat név-és címadatokat, ezért a sémában ezen elemek opcionálissá váltak. A fenti szabálynak nem megfelelő adatszolgáltatásokat a rendszer blokkoló validációval elutasítja. (a nem magánszemélynek szóló adatszolgáltatásokon pedig továbbra is kötelező elem a név és a cím)
-- Az exchangeRate tagban a 3.0-tól kezdődően megadható 0 értékű árfolyam, mert azon devizás ügyletek esetében amelyek felszámított adót nem tartalmaznak az árfolyam nem számítható ki helyesen. A rendszer WARNING-ot fog visszaadni azon esetekre, ahol az árfolyam = 0 de a számla pénznemében számított ÁFA összege bárhol nagyobb mint 0. Ezzel a módosítással egyidejűleg a korábbi ún. "6-os choice", hivatalosabb nevén VatRateType, amely az áthárított adó összegét (vagy az ÁFA mentesség okát, hatályon kívüliségét stb) tartalmazta kibővül egy 7-ik esettel, melynek a neve vatAmountMismatch. A vatAmountMismatch elemet akkor lehet megadni, amikor van adóalap, de nincs ÁFA összeg (vagy fordítva), például az ingyenes ügyletek esetében. Ugyancsak változás, hogy a vatRate csomópont megadható lesz egyszerűsített számlák esetén is.
-- Az egyszerűsített számlák adótartalma mellett taxatíve megadhatók ugyan azok a speciális esetek is (mentesség, hatályon kívül, fordított adózás stb.) amelyek a normál és a gyűjtőszámlák esetében is használhatók. Az egységesítés miatt az egyszerűsített számlákban megadható adótartalom a VatRateType részévé válik, ezzel az elem "8-as choice" értékűre bővül. A rendszer blokkoló validációval el fogja utasítani azon adatszolgáltatásokat, amelyeknél a normál és gyűjtőszámlákban használt adómérték (vatPercentage) és az egyszerűsített számlákban használt adótartalom (vatContent) keveredik. A módosítás számlasor és számla összesítő szintjén is megjelenik.
-- További változás a VatRateType esetében, hogy az ÁFA bevallások pontosításához az ÁFA mentesség(vatExemption) és a hatályon kívüliség (vatOutOfScope), valamint a vatAmountMismatch eseteiben az API külön kódot és indokolást fog elvárni. A kódot (pl: TAM, AAM stb) az interfész dokumentáció fogja tartalmazni és blokkoló validáció fogja kikényszeríteni a helyességét. Az indokolás pedig szabadon kitölthető ahogy a számlán az szerepel, a megadható hosszat pedig megduplázzuk.
-- Az ÁFA bevallások készítéséhez szükség van az előlegszámla-végszámla kérdés rendezésére is. A 3.0-ás sémában sorszinten átalakul az előleg jelzés kezelése, és egy új, advanceData csomópontban lehetőség lesz megadni végszámla esetén - sorszinten - az előleget tartalmazó számla sorszámát, a teljesítés időpontját, valamint az alkalmazott árfolyamot.
-- A közszolgáltatói elszámolószámlákra vonatkozó speciális szabályok miatt a sémába bekerült egy új, utilitySettlementIndicator nevű opcionális jelölő. A tag működését az interfész dokumentáció fogja tartalmazni.
-- Azért, hogy a számlák automatikus feldolgozása minél univerzálisabb lehessen, számlafej szintre bekerül egy conventionalInvoiceInfo nevű, míg számla sor szintre egy conventionalLineInfo nevű csomópont. A 3.0-ás séma ez alatt a piaci gyakorlat szerint használt leggyakoribb egyezményes egyéb adatokat tartalmazza (pl: megrendelés számok, szállítólevél számok, szerződésszámok, főkönyvi számlaszámok, vállalat kódok, költséghelyek, cikkszámok stb) amiknek az egyezményes névvel ellátása segítheti a gépi feldolgozás elterjedését.
-- Figyelemmel arra, hogy a 2020.07.01 óta történt értékhatár eltörlés miatt az Online számla API egy olyan közös nyelv és kommunikációs platform lett, amelyet országosan minden jogszabályok szerint működő számlázó szoftvernek ismernie kell, a NAV informatikailag továbbviszi ezt a koncepciót. Az Online számla saját sémáiból kiemelésre kerülnek azon generikus, üzleti katalógus jellegű, valamint a kommunikációt leíró típusok, amelyek más projektben is felhasználhatóak és átkerülnek egy új common XSD-be. A common XSD-nek saját névtere van és külön is verziózzuk, ami okán a Githubon is külön projektben található. (https://github.com/nav-gov-hu/Common) A kiemelés rengeteg namespace változással és átnevezéssel is jár az Online számla sémáiban, azonban a kiemelés azt eredményezi, hogy más, jövőben készülő NAV-os XML API-hoz nem kell új technikai felhasználókat létrehozni az adózóknak, az Online számla alatt regisztrált technikai felhasználók ugyan azokkal az authentikációs adatokkal és kulcsokkal, ugyan azon alap XML szerkezetben, ugyan azon (vagy hasonló) kriptográfiai metódusokkal képesnek lesznek más projekt API-t is megszólítani. Példaként a folyamatban lévő e-ÁFA projekt XML API-ját lehetne felhozni, amely képes lesz ezen működés támogatására.
-- Tekintettel arra, hogy a common XSD esetében az Online számla projekt sémái már olyan névteret is importálnak amely már nem a projekt része, bevezetésre kerül a catalog XSD mint technológia (https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.using.catalogs). Ez azt eredményezi, hogy minden <xs:import> tag elveszíti a "schemaLocation" attribútumát, az importok helyét NAV által szerkesztett sémában a catalog határozza meg. A legtöbb XML processzor az importált sémákat ugyan azon a filepath-on keresi mint ahol a feldolgozandó séma definíció is van, ezért minden fejlesztőnek el kell dönteni, hogy vagy visszaírja a "schemaLocation" értékeket a NAV-tól letöltött sémába saját magánál, vagy catalogot használ. Mindkét megoldás elfogadható. A common XSD esetében a catalog használatát azért javasoljuk mindenkinek, mert ha már több saját projektben fogja a common-os sémát használni akkor elég lesz csak egy helyen frissíteni ha a fenti séma változik. A catalogra adunk template fájlt, amit fel lehet majd használni. A template-ben lesz uri name és publicId támogatás is, valamint működni fog lokálból és webes resource eléréssel is a Github repón keresztül.
-- Rendezésre kerül az XSD hierarchia, mi által megszűnik az invoiceData elsődlegessége az importok tekintetében. Ezt úgy lehet elérni, hogy az Online számla rendszerre nézve több sémában felhasznált azon típusok, amelyek túl speciálisak ahhoz hogy a common XSD-be kerüljenek kikerülnek egy új, invoiceBase nevű sémába. Az Online számla rendszer 3.0-ás sémái (Api, Data, Annulment, Metrics) már csak a common-t és az invoiceBase sémát importálják, ez által a függési struktúra tisztul.
-- A hosszútávú fenntarthatóság érdekében a commonban bevezetésre kerül a CryptoType nevű típus. A típus lehetővé teszi, hogy az API alatt úgy lehessen hash és kriptográfiai algoritmust váltani, hogy ahhoz a sémát nem kell megváltoztatni. A cryptoType nevű attribútumot minden hash értéket tartalmazó elemnél kötelező lesz feltüntetni (passwordHash, requestSignature, electronicInvoiceHash). Az attribútum használható értékeit az interfész dokumentáció fogja tartalmazni. A hash értéket tartalmazó elemek hosszát jelentősen megnöveltük azért, hogy a későbbi algoritmusok kimenetei is elférjenek bennük, a validációs patterneket pedig hasonló okból fellazítottuk. (már nem csak hexadecimális érték adható meg)
-- Az API szolgáltatásait bővítjük a Githubon beérkezett javaslatok alapján, az adózó lekérdező válasza visszaadja a lekérdezett adószám típusát (cég vagy egyéni vállalkozó), illetve a tranzakció listázó válasza visszaadja a listában lévő tranzakciók feldolgozási státuszát, ennek segítségével API-n keresztül is ellenőrizhető, hogy van-e az adózónak még nem lekérdezett adatszolgáltatási tranzakciója.
-- INFO szintre átkerülnek azok a WARNING-ok, ahol a javítás az adózó részéről esetleges módosítás során sem lehetséges.
-
-### 1.2) Átállás, fejlesztői támogatás
-
-- Úgy becsüljük, hogy a 3.0-ás XML API-t tartalmazó fejlesztés szeptember végére lesz elérhető a teszt környezeten, a hozzá kapcsolódó magyar nyelvű interfész dokumentációval együtt.
-- Okulva a 2.0-ás átállás tapasztalataiból felkészítettük a belső feldolgozó rendszereinket arra, hogy egyszerre kaphatnak éles adatot a 2.0-ás és a 3.0-ás számla adatokkal is. Így a 3.0-ás XML API már nem csak teszt rendszeren, hanem rögtön az éles környezetben is fogadhat adatot. Ettől azt reméljük, hogy akit verziókezelési okokból blokkol ha a NAV API nem működik az éles környezetben, azok tudni fognak haladni az átállással. A hardveres környezet elkészül a 3.0 élesítésére, ezért azonos performanciával fogjuk tudni kiszolgálni mindkét verziójú API kéréseit.
-- Régóta tervezett fejlesztésünk valósul meg az által, hogy most már az XML API-hoz online elérhető openapi dokumentációt és swagger UI-t tudunk biztosítani. A swagger URL hamarosan elérhető lesz a teszt és éles rendszereken, de a Github readme is tartalmazni fogja amint a fejlesztés kikerül a publikus környezetekre. Az API definíció elérhető lesz a 2.0-ra és a 3.0-ra is egyaránt. A swaggerben a try-out funkciót is aktiváljuk, így felületről, kézzel összerakott XML beküldését ki is lehet majd próbálni. Az openapi dokumentáció generálását CI tool végzi automatikusan a release részeként, ezért garantálni tudjuk hogy mindig naprakész információ lesz elérhető. A funkció élesedéséről külön hírt fogunk kitenni az Online számla felületen.
-- Az interfész dokumentáció a Githubra is felkerül, ez által gyorsabban - és aki követi a projektet, az automatikusan is, email útján - értesülhet arról, ha a dokumentáció frissült.
-- Továbbra is biztosítjuk a gyors fejlesztői támogatást azon ticketekre, amelyeket DEV supportként adtok fel számunkra a Githubon.
-- A séma véleményezésére, XML API-val kapcsolatos javaslatok adására érdemben a NAV oldali fejlesztés ideje alatt van lehetőség, utána már (szeptember végén elindul a műszaki notifikáció) csak korlátozottan, ezért ha van még nem kezelt eset vagy fejlesztési kérés, akkor kérjük azokat mielőbb tudassátok velünk, minden észrevételt szívesen fogadunk!
-
-FELHÍVJUK a figyelmet, hogy az Online számla felületről a 3.0-ás séma zipként, egyben lesz elérhető, de a Githubon a common XSD-t verziókezelési okok miatt nem tudjuk az Online számla projekt részévé tenni. Ezért aki Githubos forrás alapján akar dolgozni, annak külön kell letölteni a két sémát! (A tartalom természetesen ugyan az lesz, letöltési forrástól függetlenül.)
-
-## 2) Egyéb Módosítások
-
-### 2.1) Common és base sémaleíró (új sémák)
-
-- A commonban új típusként megjelenik az AtomicStringType, a SimpleTextNotBlank típusok ebből öröklődnek. Hasonlóan új típus a GenericDecimalType, amelyből a lebegőpontos értékek származnak.
-- Minden Online számla sémában (Api, Data, Annulment, Metrics) egységesen a primitív xs:string típusok kivezetésre kerültek. Ezek a típusok már a common:AtomicStringType megfelelő hosszúságú típusait használják. Hasonlóképp a xs:decimal típusok is változnak GenericDecimalType-ra.
-- A commonban használt request struktúrákban nincsenek software adatok, mivel azok Online számlához köthető, specifikus típusok. Azonban a software adatok megadása a 3.0-ban is kötelezők, azokat az API sémaleíróban öröklődéssel a BasicOnlineInvoiceRequestType típus terjeszti ki.
-- A commonban a headerVersion, requestVersion elemek régi, 2.0-ás típusai törlése kerültek. Az elemek új típusa AtomicString15, és nincsenek enumjaik. (nem biztos hogy minden NAV projekt úgy fog/akar verziózni, ahogy az Online számla teszi) A verzió értékeket az intefész dokumentáció fogja tartalmazni, és a helyes értékeket a rendszer ki fogja kényszeríteni. (lényegi változás nincs kliens oldalon, az ellenőrzés a sémából átkerül szolgáltatás szintre, ez azoknak fontos aki generált XML-t használ mert ott már nem lesz automatikusan requestVersion 3.0)
-- A BasicResultType egy új opcionális, notification nevű válaszelemmel bővült. Ezt a NAV a jövőben egyéb, API hívásokban értelmezhető tájékoztató üzenetek közlésére fogja használni.
-- A base XSD-ben az alábbi típusok nevei megváltoznak, mivel túlságosan általánosak:
-DateType -> InvoiceDateType
-TimestampType -> InvoiceTimestampType
-IndexType -> InvoiceIndexType
-UnboundedIndexType -> InvoiceUnboundedIndexType
-
-### 2.2) API sémaleíró
-
-- TaxPayerDataType új elemmel bővül: incorporation, amely megmondja hogy az adószám gazdasági társaság vagy egyéni vállalkozó-e
-- TransactionType kibővül a tranzakció státuszával (requestStatus) és a technikai érvénytelenítés (technicalAnnulment) tényével
-- A /queryInvoiceDigest operáció válasza visszaadja a completenessIndicator értékét
-- A /queryInvoiceDigest operáció válaszában pontosításra kerültek az ÁFA csoport tagok adószámait tartalmazó elemek nevei: supplierGroupTaxNumber -> supplierGroupMemberTaxNumber, customerGroupTaxNumber -> customerGroupMemberTaxNumber. Ezen kívül a válasz opcionálisan tartalmazza a beküldött electronicInvoiceHash tag értékét is.
-
-### 2.3) Annulment sémaleíró
-
-- az AnnulmentCodeType típus kibővült egy új technikai érvénytelenítési okkal: ERRATIC_ELECTRONIC_HASH_VALUE
-
-### 2.4) DATA sémaleíró
-
-- data:RegNumType -> common:PlateNumberType, és új a patternje, az EKÁER-rel azonosan (ÖÜŐ is megengedett)
-- ekaerId-t átmozgatásra kerül az új egyezményes (conventionalInvoiceInfo) adatok közé, ez által fej és tétel szinten is megadható
-
-### 2.5) ERROR módosítások
-
-- új ERROR: a requestVersion és (ha meg van adva akkor) a headerVersion tag értéke csak az interfész dokumentációban engedélyezett lehet
-- új ERROR: a timestamp értéke nem lehet kisebb mint 2010-01-01T00:00:00Z
-- új ERROR: ha az alapszámlában a completenessIndicator értéke false, akkor egy módosító okiraté sem lehet true (az API nem támogatja az ilyen irányba történő váltást a számlaláncon belül, de a másik irányba történő váltás megengedett)
-- új ERROR: ha privatePersonIndicator értéke false, akkor a customerName ÉS a customerAddress megadása kötelező (B2B számla)
-- új ERROR: ha privatePersonIndicator értéke true, akkor sem a customerName sem a customerAddress, sem a customerVatData nem adható meg (B2C számla)
-- új ERROR: ha a completenessIndicator értéke true, az invoiceAppearance értéke csak ELECTRONIC lehet
-- új ERROR: az electronicInvoicehash megadása kötelező, ha a completenessIndicator értéke true
-- új ERROR, ha az electronicInvoicehash értéke helytelen és a completenessIndicator értéke true
-- új ERROR: ha a completenessIndicator értéke true akkor a mergedItemIndicator értéke nem lehet true
-- új ERROR: ha a completenessIndicator értéke true akkor a vevő nem lehet magánszemély
-- új ERROR: NORMAL vagy AGGREGATE számlának nem lehet lineAmountsSimplified sora vagy SIMPLIFIED számlának nem lehet lineAmountsNormal sora
-- új ERROR: NORMAL vagy AGGREGATE számlában nem lehet vatContent értéket adni vagy SIMPLIFIED számlában nem lehet vatPercentage értéket adni a VatRateType típuson belül
-- új ERROR: egy általános átmeneti hibakód is bekerül a rendszerbe, melyet első alkalommal a rendszer akkor fog visszaadni, amikor az elektronikus számlával egyenértékű 3.0-ás adatszolgáltatás érkezik 2021.01.04. előtt
-- vatContent értéke már nem lehet 0, mivel a mentességi okok a VatRateType típuson belül taxatíve megadhatók
-
-### 2.6) WARNING módosítások
-
-- új WARNING: az exchangeRate értéke nem lehet 0, ha van bárhol (fej vagy sorszinten) olyan ÁFA összeg a számla pénznemében, aminek az értéke != 0
-- új WARNING: ha az mergedItemIndicator a számlaláncon belül bárhol true lett, onnantól végig true értéket kell kapjon a további módosítások során
-- INFO szintre történő átsorolások felülvizsgálata folyamatban van
-- a meglévő WARNING logika felülvizsgálata folyamatban van, ma leglévő észrevételek mellett az új felvetéseket is várjuk a Githubon
-
-### 2.7) Uppercase konverzió megszüntetése
-
-A 3.0-ás adatszolgáltatások feldolgozása során minden korábbi nagybetűsítés megszűnik a rendszerben. Minden string típus úgy kerül mentésre ahogy az az adatszolgáltatásban beérkezett.
-
-### 2.8) Séma- és üzleti változások az eddig publikált verzióhoz képest (2020.11.**)
-
-#### 2.8.1) Vevő státusza a számlával bizonylatolt ügyletben
-
-Több jelzés érkezett githubon és egyéb fórumokon, hogy az eddigi privatePersonIndicator magánszemély jelölővel nem minden üzleti eset megkülönböztethető. A jelölő helyett a customerVatStatus tag lett bevezetve, ebben a kötelező mezőben kell jelölni a vevő státuszát az adott ügyletben. Ennek lehetséges értékei a következők:
-- DOMESTIC: Belföldi ÁFA alany. Ilyenkor a vevő nevének és címének (customerName, customerAddress) megadása kötelező. Adószámok közül csak a magyar adószám (customerVatData/customerTaxNumber) adható meg. Ez a megadás minden esetben kötelező, kivéve egy esetet, amikor az értékesítő(eladó) csak áfa regisztrált és nem belföldi fordított adózású az ügylet.
-- OTHER: Egyéb (belföldi nem ÁFA alany, nem természetes személy, külföldi ÁFA alany és külföldi nem ÁFA alany, nem természetes személy). Ilyenkor a vevő nevének és címének (customerName, customerAddress) megadása kötelező. Adószámok közül (customerVatData) a háromból egy megadható, de nem kötelező.
-- PRIVATE_PERSON: Nem ÁFA alany (belföldi vagy külföldi) természetes személy. Ilyenkor a vevői adatok közül a customerVatData, customerName, customerAddress megadása tilos, ezt blokkoló validáció ellenőrzi.
-
-#### 2.8.2) Adómérték (VatRateType) nyolcas choice átalakítása
-
-- az eddigi különbözet szerinti adózás jelölők (marginSchemeVat és marginSchemeNoVat) összevonásra kerültek egy mezőbe, melynek neve marginSchemeIndicator, típusa MarginSchemeType. Ez az egyszerűsítés azért lehetséges, mert a típus korábban is létezett tétel szinten, és lefedi az összes különbözet szerinti adózást (Vat és NoVat eseteket). Séma szintű enum értékek: TRAVEL_AGENCY, SECOND_HAND, ARTWORK, ANTIQUES. Az egyszerűsítés következtében a LineType complex típusból kikerült a marginSchemeIndicator (tehát a line/marginSchemeIndicator tag megszűnt), mivel annak megadása ezentúl az érték adatoknál (lineAmountsNormal/lineAmountsSimplified) történik meg.
-- vatAmountMismatch átalakítása: mivel ezen eseteknél is létezik az adómérték fogalma, így a csomópontben szereplő korábbi case/reason átalakításra került vatRate/case bontásra. A vatRate-ben megadható értékek: 0.27, 0.18, 0.05, 0.2126, 0.1525, 0.0426. Értékét blokkoló üzleti validáció ellenőrzi.
-- az előző pont miatt a vatAmountMismatch case értékek közül kikerült egy külön tagbe a noVatCharge eset (Nincs felszámított áfa a 17. § alapján), mivel ilyenkor nincs értelmezhető adómérték. Az új noVatCharge mező típusa boolean.
-- UNKNOWN érték bevezetése a case értékek közé: előzmény nélküli és olyan módosító/sztornó számláknál, melyek 3.0 előtti verziójú számlára hivatkoznak, nem minden esetben határozható meg a pontos case érték a vatExemption/vatOutOfScope/vatAmountMismatch esetekben. Az UNKNOWN értékkel így bővült mindhárom esetben a case értékkészlet. Ez az érték kizárólag ilyen esetekben megadható.
-- vatExemption és vatOutOfScope esetekben a reason mező hossza 100-ról 200-ra változott
-- a boolean típusú adómértékeknél (vatDomesticReverseCharge, noVatCharge) csak a logikai igaz (true vagy 1) érték elfogadott séma szinten (fixed:true attribútum), hiszen üzletileg csak ekkor van értelme az adott módozat jelölésének.
-- THK érték kivezetése a vatOutOfScope/case elfogadott értékek közül tétel és összesítő szinten is
-
-#### 2.8.3) ERROR módosítások
-
-- módosított ERROR: ha a vevő nem magánszemély (customerVatStatus értéke nem PRIVATE_PERSON), akkor a customerName ÉS a customerAddress megadása kötelező (B2B számla)
-- módosított ERROR: ha a vevő magánszemély (customerVatStatus értéke PRIVATE_PERSON), akkor a customerName, customerAddress és a customerVatData nem adható meg (B2C számla)
-- módosított ERROR: a passwordHash cryptoType attribútumának elfogadott értéke SHA-512 értékre módosult (a korábbi helytelenül definiált SHA2-512 helyett)
-- módosított ERROR: vatExemption/vatOutOfScope/vatAmountMismatch esetén a case mezőben elfogadható az UNKNOWN érték, de csak előzmény nélküli és olyan módosító/sztornó számláknál, melyek 3.0 előtti verziójú számlára hivatkoznak
-- törölt ERROR: ha van előleg adat az adott tételnél(advanceIndicator=true), akkor az advancePaymentData csomópont megadása nem kötelező, mivel előleg számlánál ezen adatok még nem állnak rendelkezésre
-- új ERROR: ha a vevő belföldi áfa alany (customerVatStatus értéke DOMESTIC), akkor a magyar adószám megadása kötelező, kivéve egy esetet, amikor az értékesítő(eladó) csak áfa regisztrált és nem belföldi fordított adózású az ügylet
-- új ERROR: ha a vevő belföldi áfa alany (customerVatStatus értéke DOMESTIC), akkor a közösségi adószám (communityVatNumber) megadása tilos
-- új ERROR: ha a vevő belföldi áfa alany (customerVatStatus értéke DOMESTIC), akkor a harmadik országbeli adószám (thirdStateTaxId) megadása tilos
-- új ERROR: tétel vagy összesítő szinten, ha az adóalap és felszámított adó eltér (vatAmountMismatch), akkor a vatAmountMismatch/vatRate értéke csak a következők valamelyike lehet: 0.27, 0.18, 0.05, 0.2126, 0.1525, 0.0426.
-- új ERROR: az összes API-s kérésben megadott timestamp érték a szerveridő +- 1 nap intervallumon belül kell, hogy essen
-
-
-
-#### 2.8.4) Egyéb, kisebb mértékű változtatások
-
-- a /queryTransactionList operáció request része kiegészült az opcionális requestStatus mezővel, mellyel a tranzakció státuszára lehet szűrni.
-- a common XSD-ben lévő PageType kettébontásra került RequestPageType és ResponsePageType típusokra. Erre azért volt szükség, mert 0 találat esetén a válaszban availablePage értéke 0.
-- új közlekedési eszköz első forgalomba helyezés időpontja (firstEntryIntoService) opcionális lett a NewTransportMeanType típusban.
-- az egyezményes, nevesített adatokat tartalmazó ConventionalInvoiceInfoType típusban a glnNumbers kettébontásra került glnNumbersSupplier és glnNumbersCustomer csomópontokra.
-- az árfolyam az adatszolgáltatásnak általános kötelező adattartalmává vált. Így nem csupán az áthárított adót tartalmazó számlák esetén, hanem minden esetben valós árfolyammal szükséges tölteni ezt a mezőt. Ennek következtében az eddig a dokumentációban is szereplő nulla forintos árfolyam már nem lesz használható, melyet sémaszinten is kikényszerítjük.
-- a queryTaxpayer adózói lekérdezés válaszában kibővült a gazdagási típus (IncorporationType) értékkészlete. Az új érték a TAXABLE_PERSON, mellyel az adószámos adózókat jelöljük, ezzel külön kezelve az egyéni vállalkozóktól.
-
-## 3) 3.0 átállási útmutató lépésről lépésre
-
-### 3.1) API
-
-#### 3.1.1) Kötelező API módosítások
-
-- Minden hívott URL-ben vezesd át a főverzió változást, '/v2/' helyett '/v3/' legyen mindenhol.
-- Minden root elementnél emeld 3.0-ra az API-s séma namespace értékét, illetve kösd be a common XSD-t. Egy lehetséges példa: 'xmlns="http://schemas.nav.gov.hu/OSA/3.0/api" xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common"'.
-- Minden requestVersion tagban emeld a verzió értéket 3.0-ra.
-- A header és user csomópontokban mindenhová (nyitó és zárótagekbe, illetve a gyermek tagekbe is) tedd bele a common XSD-re általad definiált namespace taget. Ha a példa szerinti ns-t használod, akkor ez a 'common:' lesz.
-- A user/passwordHash tagba tedd bele a 'cryptoType="SHA-512"' attribútumot.
-- A user/requestSignature tagba tedd bele a 'cryptoType="SHA3-512"' attribútumot.
-
-#### 3.1.2) Használatfüggő API módosítások
-
-- Ha használsz DTO generálást a projektedben, akkor az új sémákkal a projekt már nem fog fordulni. Vagy használj catalog XSD-t a common és a base sémák importálására és ezt kösd be a projekthez, vagy írd be a letöltött sémákba a schemaLocation attribútumot olyan filepath értékkel, ami neked megfelelő. (egy 2.0 szerinti séma deklarációs részét meg tudod nézni, hogyan szerepelt ez az attribútum pontosan a sémában korábban, ha szükséged van rá) A common XSD projektet itt éred el: https://github.com/nav-gov-hu/Common
-- Ha használsz response validációt a projektedben, akkor ha szükséges készülj fel arra, hogy az API üzleti válaszait nem minden esetben (pl token kérésnél az encodedExchangeToken, számlabeküldésnél a transactionId vagy a lekérdezéseknél a válasz adatok) a default, hanem esetlegesen más namespace alatt fogod visszakapni mint ahogy az korábban a 2.0 alatt történt. Ez a common XSD importálásának egyik következménye.
-- Ha a programod riportálja az elektronikus számlák ellenőrző hash értékét, akkor ezt a 3.0-ban már nem belül a Data XML-ben, hanem kívül, az API XML-ben kell megadnod. Az ehhez szükséges tag neve változatlanul electronicInvoiceHash, de a helye már a ManageInvoiceRequest/invoiceOperations/invoiceOperation/electronicInvoiceHash Xpath útvonalon található. Ne feledd, hogy ehhez a taghoz is tartozik cryptoType attribútum. A hash típusa completenessIndicator=false esetben csak SHA3-512 vagy SHA-256 lehet, de a hash értéke ekkor nem történik szerver oldali validáció.
-- Ha használni szeretné a programod a 3.0 újdonsága szerinti elektronikus számlázást (completenessIndicator=true) akkor a cryptoType attribútumban a hash típusa csak SHA3-512 lehet, az értékét pedig az API XML-ben szereplő invoiceData objektumból kell kiszámolni, melynek helyességére a szerver validál.
-- Ha a programod használja az adózó lekérdező /queryTaxpayer szolgáltatást, akkor készülj fel a válaszban az incorporation tag feldolgozására.
-- Ha a programod használja a tranzakció listázó /queryTransactionList szolgáltatást, akkor készülj fel a válaszban a requestStatus és a technicalAnnulment tagek feldolgozására.
-- Ha a programod használja a teljes adattartalmú számla lekérdező /queryInvoiceData szolgáltatást, akkor készülj fel hogy a válaszban már visszakaphatsz 3.0-ás számla XML-t is. Az ehhez kapcsolódó parsolási, üzleti, megjelenítési és egyéb program módosításokat kezeld le magadnál. Szintén készülj fel arra, hogy az operáció visszaadhatja az electronicInvoiceHash értékét is, amikor az ki volt töltve a beküldésnél.
-- Ha a programod használja a kivonatos számla lekérdező /queryInvoiceDigest szolgáltatást, akkor készülj fel a válaszban a completenessIndicator tag feldolgozására, illetve készülj fel, hogy az eladó és a vevő csoportos adószámát már más néven fogod visszakapni. (ld: 2.2 fejezet)
-- Javasoljuk, hogy készülj fel a válaszokban opcionálisan érkező notification tag értékének feldolgozására és megjelenítésére a felhasználók felé! A szerver még nem ad vissza a tagban értéket (a használatba vétel külön fejlesztés lesz), unit teszttel vagy debugban tudod kipróbálni hogy a program jól működik-e.
-- Gondold végig, hogy az uppercase konverzió megszüntetése okoz-e bármiféle törést vagy nem várt változást a programodban (pl /queryInvoiceData és /queryInvoiceDigest válaszának változásai miatt) és ha szükséges akkor kezeld le őket!
-
-### 3.2) Data
-
-#### 3.2.1) Kötelező Data módosítások
-
-- az InvoiceData root elementnél emeld 3.0-ra az Data séma namespace értékét, illetve kösd be a Base XSD-t. Egy lehetséges példa: 'xmlns="http://schemas.nav.gov.hu/OSA/3.0/data" xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base"'
-- A számla felső szintű adatainál meg kell adnod a completenessIndicator tag értékét, ez határozza meg hogy az adatszolgáltatás egyenértékű-e a kibocsátott elektronikus számlával. Az új tag helye az invoiceIssueDate tag után következik. Javasoljuk, hogy egyelőre mindenki használja default false értékkel, mivel 2021.01.04-ig a szerver nem fogadhat el adatszolgáltatásokat true értékkel. Az üzleti funkció használatát pedig javasoljuk valamilyen dinamikusan változtatható üzleti vagy konfigurációs paraméterhez kötni, hogy csak az aktiválásához ne kelljen külön kliens oldali release-t kiadni, amikor majd itt az idő.
-- Három komplex adattípus esetében át kell vezetned a Base XSD namespace értékét a gyermek tagekben. Ezek a magyar adószámot leíró TaxNumberType (törzsszám, ÁFA kód, megyekód) illetve a címtípusok, függetlenül attól hogy egyszerűsített (SimpleAddressType) vagy tagolt (DetailedAddressType) címekről van-e szó. Ezt a módosítást minden olyan helyen át kell vezetned, ahol a felsorolt típusok a Data XML-ben előfordulhatnak. Figyelj rá, hogy ez nem olyan namespace módosítás mint ami az API-nál van, itt a szülő tag nem kaphat új namespace értéket! Tehát, amíg az API esetében így néz ki a helyes ns:
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<TokenExchangeRequest xmlns="http://schemas.nav.gov.hu/OSA/3.0/api" xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common">
- <common:header>
- <common:requestId>String</common:requestId>
- <common:timestamp>2020-09-06T12:09:24.901Z</common:timestamp>
- <common:requestVersion>3.0</common:requestVersion>
- <common:headerVersion>1.0</common:headerVersion>
- </common:header>
-```
-addig a Data esetében, például a kiállító adatainál már így (feltéve hogy a példa szerinti ns-t, a 'base:' értéket használod):
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<InvoiceData xmlns="http://schemas.nav.gov.hu/OSA/3.0/data" xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.nav.gov.hu/OSA/3.0/data invoiceData.xsd">
- <invoiceNumber>2021/1</invoiceNumber>
- <invoiceIssueDate>2020-09-06</invoiceIssueDate>
- <completenessIndicator>false</completenessIndicator>
- <invoiceMain>
- <invoice>
- <invoiceHead>
- <supplierInfo>
- <supplierTaxNumber>
- <base:taxpayerId>88888888</base:taxpayerId>
- <base:vatCode>5</base:vatCode>
- <base:countyCode>41</base:countyCode>
- </supplierTaxNumber>
- <groupMemberTaxNumber>
- <base:taxpayerId>44444444</base:taxpayerId>
- <base:vatCode>4</base:vatCode>
- <base:countyCode>42</base:countyCode>
- </groupMemberTaxNumber>
- <supplierName>Supplier Ltd.</supplierName>
- <supplierAddress>
- <base:simpleAddress>
- <base:countryCode>HU</base:countryCode>
- <base:postalCode>1031</base:postalCode>
- <base:city>Budapest</base:city>
- <base:additionalAddressDetail>Example street 1.</base:additionalAddressDetail>
- </base:simpleAddress>
- </supplierAddress>
- </supplierInfo>
-```
-
-Látható, hogy amíg az API-ban a header tag is új ns-t kapott (nem csak az alatta lévő gyermek tagek), addig a supplierTaxNumber és a supplierAddress tagek maradtak a default namespace alatt, csak a gyermek tagek kaptak új ns értéket.
-- A vevő adatainak felírását már úgy kell kezdened, hogy a customerVatStatus tagban megadod, hogy a számla vevője belföldi ÁFA alany/nem ÁFA alany természetes személy/ egyéb. A tag helye sorrendben legelöl van a customerInfo tagen belül. Javasoljuk, hogy ennek az információnak a bevitelére legyen UI beviteli funkció (amennyiben más üzleti logika alapján ez nem derül ki) és ezt a számlát készítő felhasználó adja meg, mert a vevő adószámának hiánya nem feltétlen jelenti azt, hogy a vevő egyben magánszemély is, nehéz az algoritmizáció. (pl. egyéni vállalkozó vevők számlái)
-- Minden nem magánszemélyes számlánál a vevői adószámot új Xpath alatt, a customerInfo/customerVatData alatt lehet megadni, ezt kezeld le magadnál. Figyelj rá, hogy nem lesz feltétlenül minden nem magánszemélyes számlánál adószám (pl. gazdasági tevékenységet nem folytató társasház, egyesület stb.)
-- Építs kitöltési logikát a vevői adatok XML-ben történő szerepeltetésére:
- - ha a vevő belföldi ÁFA alany, akkor
- - a magyar (plusz opcionálisan az ÁFA csoport) adószám (customerTaxNumber+groupMemberTaxNumber) megadása kötelező, kivéve, ha az eladó ÁFA regisztrált
- - név (customerName) és cím (customerAddress) megadása kötelező
- - ha a vevő nem ÁFA alany (belföldi vagy külföldi) természetes személy, akkor
- - sem név (customerName), sem cím (customerAddress), sem pedig vevő adószámot (customerVatData) tartalmazó csomópont nem adható meg
- - ha a vevő egyéb (belföldi nem ÁFA alany, nem természetes személy, külföldi Áfa alany és külföldi nem ÁFA alany, nem természetes személy), akkor
- - a magyar (plusz opcionálisan az ÁFA csoport) adószám (customerTaxNumber+groupMemberTaxNumber), a közösségi adószám (communityVatNumber) és a harmadik országos adószám (thirdStateTaxId) közül kizárólag egyet lehet megadni, de azt nem kötelező.
- - név (customerName) és cím (customerAddress) megadása kötelező
-
-FIGYELEM: a kitöltési logika azt jelenti, hogy magánszemély esetén a névnek és címadatnak a számlán rajta kell lennie, de az adatszolgáltatásban használt XML-ben már nem!
-- Ha az adatszolgáltatás tartalmaz számlasort, akkor a mergedItemIndicator megadása kötelező. A tag helye még a sorok felsorolása előtti szinten (invoiceLines) található, sorrendben legelől.
-- Ha a számlasor előleg adotokat tartalmaz, akkor azokat új Xpath alatt, a line/advanceData alatt adhatod meg. Ha van előleg adat (advanceIndicator=true), akkor az advancePaymentData csomópont alatt megadhatod az előleg számla sorszámát (advanceOriginalInvoice), az előleg fizetés időpontját (advancePaymentDate) és az alkalmazott árfolyamot (advanceExchangeRate). A félreértések elkerülése érdekében hangsúlyozzuk, hogy az advanceOriginalInvoice tagba az előleget tartalmazó számla invoiceNumber értéket kell szerepeltetni, tehát ez nem számlasor szintű hivatkozás, hanem számla szintű!
-- Figyelj rá, hogy nem egyszerűsített számla esetén (NORMAL és AGGREGATE típusokban) se számlasor, se számlaösszesítő szinten a VatRateType által leírt csomópontokban ne lehessen megadni a számlázóprogramban az egyszerűsített számlákban használt ÁFA tartalmat (vatContent), mert ez ilyen adatszolgáltatások ERROR miatt bukni fognak!
-- Figyelj rá, hogy egyszerűsített számla esetén (SIMPLIFIED típus) se számlasor, se számlaösszesítő szinten a VatRateType által leírt csomópontokban ne lehessen megadni a számlázóprogramban a normál/gyűjtő számlákban használt ÁFA tartalmat (vatPercentage), mert ez ilyen adatszolgáltatások ERROR miatt bukni fognak!
-
-#### 3.2.2) Használatfüggő Data módosítások
-
-- Ha használni szeretné a programod a 3.0 újdonsága szerinti elektronikus számlázást, akkor:
- - ne engedj olyan elektronikus (completenessIndicator=true) számlát (CREATE) vagy módosító okiratot (MODIFY, STORNO) kiállítani akkor, ha
- - a számla vagy módosító okirat magánszemélynek szól (customerVatStatus=PRIVATE_PERSON),
- - a számla vagy módosító okirat méretcsökkentés miatt összevont soradatokat tartalmaz (mergedItemIndicator=true),
- - a számla vagy módosító okirat megjelenési formája nem elektronikus (invoiceAppearance != ELECTRONIC)
- - a számla vagy módosító okirat kiállítási dátuma (invoiceIssueDate) 2021.01.04 előtti
- - sysdate 2021.01.04 előtti vagy az erre a célra létrehozott üzleti paraméter állása a funkció használatát nem engedi
- - fenti szabályokon felül ne engedj olyan elektronikus (completenessIndicator=true) módosító okiratot kiállítani (MODIFY, STORNO), amelynek az alapszámlája létezik a rendszerben (modifyWithoutMaster=false) és abban a completenessIndicator tag értéke false
- - az API XML-ben tüntesd fel az electronicInvoiceHash taget helyes cryptoType és hash értékkel, az interfész dokumentáció szerint
-Ha a fenti szabályokat a programod nem tartja be, akkor az adatszolgáltatás ERROR miatt bukni fog, ami jelen esetben meghiúsítja az elektronikus számla vagy a módosító okirat kibocsátását is!
-- Ha a programod kezel ÁFA mentes (vatExemption) és ÁFA hatályon kívüli (vatOutOfScope) számlákat, akkor a különböző esetekre az interfész dokumentáció által meghatározott értékkészlet alapján kínálj fel listás beviteli lehetőséget a UI-on, vagy a felhasználó által transzparensen feleltesd meg a saját értékeid ennek az értékkészletnek, ha erre lehetőséged van. Az enumerált értéket a case tagban, a felhasználó által a számlára felvitt értéket pedig a reason tagba helyezd el az XML-en belül mind számlasor, mind számlaösszesítő szinten. (értékkészlethez ld: PDF 2.2.3.2.1 vatRate fejezet)
-- Ha a programod kezeli az adóalap és a felszámított adó eltérésének - interfész dokumentáció szerint felsorolt - eseteit, akkor gondoskodj a vatAmountMismatch tag megfelelő töltéséről mind számlasor, mind számlaösszesítő szinten. Amennyiben az átváltási árfolyam ezen esetek miatt nem számítható ki, akkor az exchangeRate tag értékét állítsd 0-ra. (értékkészlethez ld: PDF 2.2.3.2.1 vatRate fejezet)
-- Ha a programod nem tudja meghatározni előzmény nélküli vagy 3.0 előtti számlákra hivatkozott módosító/sztornó számláknál a case értékeket, akkor használd az UNKNOWN-t.
-- Ha a programod kezeli a különbözet szerinti adózású számlákat, akkor a korábbi marginSchemeVat és margonSchemeNoVat jelölők helyett a marginSchemeIndicator-ban kell megadni a konkrét esetet
-- Ha a programod kezel egyszerűsített számlákat, akkor az ÁFA tartalmat (vatContent) számla sor szinten már új Xpath alatt, a lineAmountsSimplified/lineVatRate alatt tudod megadni. A módosítás a számlaösszesítőben is megjelenik, itt az új útvonal a summarySimplified/vatRate alatt található. Hasonlóképp itt tudod megadni az összes olyan mentességet, amelyeket eddig csak nem egyszerűsített számlánál lehetett megadni. A mentességek helyes kezelése azért fontos, mert a 2.0-ig a vatContent lehetett 0, azonban a 3.0-ban ez a lehetőség már megszűnik, az új ellenőrzés már ERROR-t ad erre az esetre! Az említett módosításokat vezesd át magadnál. Figyelj rá, hogy a programodban egyszerűsített számla esetében adó mértéket (vatPercentage) sem számlasor, szem számlaösszesítő szinten ne lehessen megadni, mert ez ilyen adatszolgáltatások ERROR miatt bukni fognak!
-- Ha a programod töltötte számlasor szinten a tételhez tartozó EKÁER számokat, akkor ezt a taget már új Xpath alatt, a line/conventionalInvoiceInfo találod meg. EKÁER szám a 3.0-tól megadható számlafej szinten is, nem csak számlasorban.
-- Ha az ügyfeleidnél van igény az adatmodellben megjelenő új, ügylethez tartozó azonosítók töltésére akár kiállítói, akár vevői oldalról (megrendelésszám, szerződésszám, szállítólevélszám stb.) akkor ezekre az adatokra biztosíts a UI-on bevitelt, illetve helyezd el a bevitt adatokat az XML-ben számlafej vagy számlasor szintjén a /conventionalInvoiceInfo vagy /conventionalLineInfo csomópont alatt. Minden tag kardinalitása korlátlan, tehát bármiből bárhány adat felírható.
-- Ha a programod kezeli azt az esetet, amikor az adatszolgáltatás túl nagy méretű (HTTP content-length >= 10.485.760 bájt), akkor az interfész dokumentáció által meghatározott logika szerint vond össze a számlasorokat tétel-szolgáltatás szinten és aggregáld a megfelelő számszaki értékeket! Az összevonás tényét az adatszolgáltatásban jelezd a számlasor szint felett, a mergedItemIndicator=true kifejezéssel. Figyelj rá, hogy ha ez a tag a számlaláncban bárhol true lett, az onnantól következő módosításokban (következő modificationIndexek alatt) már sosem lehet false! (ellenkező esetben az adatszolgáltatás WARNING-ot kap) Felhívjuk a figyelmet, hogy nem felel meg a törvényi szabályozásnak az a megoldás, ami ezeket a számla adatszolgáltatásokat kiemeli kézi feldolgozásba, mindenképpen a számlázóprogramnak kell az összevonási logikát implementálni.
-- Ha a programod kezel közüzemi elszámolószámlákat, akkor kezeld a utilitySettlementIndicator tag megfelelő értékadását.
-
-### 3.3) Annulment
-
-#### 3.3.1) Kötelező Annulment módosítások
-
-N/A
-
-#### 3.3.2) Használatfüggő Annulment módosítások
-
-- Ha a programod használja a technikai érvénytelenítési funkcióját az API-nak, akkor a belső XML-ben az InvoiceAnnulment root elementnél javítsd a namespace értékét: 'xmlns="http://schemas.nav.gov.hu/OSA/3.0/annul"'
-- Ha a programod riportálja az elektronikus számlák ellenőrző hash értékét, akkor helytelen hash érték esetén már nincs lehetőség módosítani az adatszolgáltatást, technikai érvénytelenítést kell kezdeményezni. Ehhez a használati esethez új annulmentCode érték tartozik, ezért a technikai érvénytelenítő kérésbe az 'ERRATIC_ELECTRONIC_HASH_VALUE' értéket tedd. Fontos kihangsúlyozni, hogy ez a kód csak completenessIndicator=false esetén használható, jelen bejegyzés is csak ezzel a logikai esettel foglalkozik. (completenessIndicator=true esetén nincs technikai érvénytelenítési lehetőség, noha az is igaz, hogy ott helytelen hash érték sem lehet, mert a szerver a hibás hashel érkező ilyen adatszolgáltatásokat elutasítja)
-
-### 3.4) ServiceMetrics
-
-#### 3.4.1) Kötelező ServiceMetrics módosítások
-
-N/A
-
-#### 3.4.2) Használatfüggő ServiceMetrics módosítások
-
-- Ha a programod használja a metrika lekérdező funkcióit az API-nak, akkor ld: 3.1.2 fejezet DTO generálással és response validációval foglalkozó bejegyzések.
---------------------------------------------------------------------------------------------------------------------------------------------
-
-# Changelog 3.0
-
-Comprehensive changes from 2.0 to 3.0.
-
-## 1) Overview of reasons for changes
-
-Similarly to version 2.0, change requests of multiple kinds have been incorporated. First, the system’s API shall be capable of receiving EU invoices, invoices for export transactions and invoices issued to natural persons from 04.01.2021. On the other hand, the Online Invoicing project reached a phase where no new versions (compared to version 3.0) of the XML API are scheduled for release according to our plans, except for legislation changes and for eventual significant future demand. Even if changes will be made, those may be incorporated in a minor version instead of a major one. For all of these reasons, sustainability and other relevant aspects have also been considered in this release. We have, therefore, tried to eliminate all business and technical issues found in the API, and find solutions satisfying both parties. At last, but not at least, data missing for creating more accurate VAT return report drafts can now be identified and provided.
-
-### 1.1) Planned solutions
-
-- A cornerstone of v3.0 of the API is to catalyse electronic invoicing and it’s usability. For this reason, you’ll be able to specify the electronicInvoiceHash element in the API XML to contain the hash fingerprint of an e-invoice. This change only ensures the separation of business data and fingerprints during invoice creation and amendment. The change incorporated the decision to not support use cases when corrective data exchange (amendment) is received solely for the purpose of correcting the fingerprint of the original invoice, and therefore no feature is provided to do so. Data exchange treated deficient for a wrong fingerprint can only be corrected in the form of technical invalidation (annulment). The Annulment schema has been extended with a new annulment reason to support this.
-- Another key change in the support of e-invoicing is the new required flag, completenessIndicator, added to the schema. You can use completenessIndicator to declare the e-invoice itself will be submitted as the means of performing v3.0 data exchange based on the sole decision of the taxpayer, using the XML format based on the schema and containing all data. Purchasing parties can then receive and process invoices in their books right after receiving the data exchange, without the need for further invoice delivery and later manual or automated comparison of supplied data and invoice data. Legislation will be adjusted to accommodate this change, and NTCA will enforce the integrity of data in such data exchange scenarios. The electronicInvoiceHash element for such invoices shall be computed as specified in the interface documentation, and the fingerprint shall be correct. Furthermore, you will not be able to perform technical annulment on such instances of data exchange, because the contents of the data exchange will practically form and incarnate the invoice itself, and therefore the two shall be identical. NAV imposes certain restrictions on invoice chains formed of such invoices (see section ERROR changes). The feature can only be used from 04.01.2021. Attempts to use it sooner will result in the rejection of the processing request in the company of a temporary error code.
-- The issue of large-sized data exchanges with a POST body size larger than 10MB was practically left unaddressed since the beginning of the project. The issue typically affects a small amount of invoices issued by invoicing parties required to create very detailed invoices to conform to industry legislation, such as telecommunication and public utility service providers. The VAT act, however, is far from expecting such detailed invoice data, and the scope of data exchange obligation only includes data classified as mandatory in the VAT act. The interface documentation have been extended with a methodology guide to help you consolidate such data exchange on the basis of products and services sold in order to create a package for NAV that is less than 10MB, without losing any relevant business data. Data exchanges of this kind shall be indicated using the mandatory mergedItemIndicator flag inserted above the invoice item lines.
-- Effective from 04.01.2021, data is required to be supplied about EU export invoices, and invoices issued to parties not considered VAT tax payers. In order to accommodate this, the customerInfo node has been changed to allow separation of invoices submitted to domestic parties, EU parties and parties in other foreign countries, as well as invoices issued to natural persons. Just another change in v3.0 is that you cannot display all of the Hungarian VAT ID, the EU VAT ID and the VAT ID from another country’s system next to each other, instead you can only pick one. At implementation level, the previously used sequence element is converted to a choice construct. Data exchange about invoices issued to natural persons (not including natural persons holding a VAT ID and individual entrepreneurs) shall not contain name and address data, and therefore the schema elements to hold such data have been made optional. Data exchanges not conforming to this rule are rejected in the form of a blocking validation. Note that name and address are still mandatory for invoices issued to others than natural persons.
-- An exchange rate of 0 can be specified in the exchangeRate tag from version 3.0, since the exchange rate for transactions in foreign currency without incorporated tax cannot be calculated properly. You will receive a WARNING if the exchange rate is 0, and the VAT amount expressed in the currency of the invoice is greater than 0 anywhere. In concert with this change, VatRateType, the choice with 6 options and containing the amount of shifted taxes (or the reason of exemption or out-of-scope status) has been extended with a 7th option, called vatAmountMismatch. You can specify the vatAmountMismatch element when the transaction contains a tax base, however there’s no VAT amount (or vice versa), such as in case of free transactions. Yet another change is that you can add the vatRate node to simplified invoices, too.
-- In addition to the tax amount for simplified invoices, you can also specify all the special cases (exemption, out of scope, reverse charge and so on) that you can specify for normal and summary invoices. As a consequence of this homogenization effort, the tax amount you can specify for simplified invoices becomes part of VatRateType, so it becomes a choice of 8 options. The system will apply blocking validation to reject data exchange attempts containing a mix of the VAT rate (vatPercentage) used in normal and aggregate invoices, and the VAT amount used in simplified invoices (vatContent). The change has been implemented at item and invoice summary levels as well.
-- Another change affecting VatRateType is that the API expects a separate code and reason for vatExemption, vatOutOfScope and vatAmountMismatch to refine VAT return reports. The documentation of the interface discloses the codes (such as TAM for exempt by transaction, or AAM for not subject to VAT), and will be enforced using blocking validation. The reason is just a free text, and you can use the same text that is shown on the invoice. The length of the attribute have been doubled.
-- The issues about the relation of advance payment invoices and final invoices had to be settled to be able to create VAT returns. Handling of advance payments have been restructured at item level in version 3.0 of the schema, and you can use a new item-level node in final invoices, called advanceData, to include the number of the corresponding advance payment invoice, the date of performance and the exchange rate used.
-- A new, optional flag named utilitySettlementIndicator has been added to the schema to respond to special rules governing public utility settlement invoices. Please see the interface documentation for the rules of usage.
-- In an effort to unify automated processing of invoices as much as possible, a node named conventionalInvoiceInfo to invoice level, and a node named conventionalLineInfo to invoice line level has been added. Version 3.0 of the schema supports most frequently used common data, such as PO numbers, delivery note numbers, agreement IDs, G/L account codes, company codes, cost centre codes, item numbers etc. in the faith that giving a common and conventional name to such data can help spreading automated processing.
-- With respect to that after abolishing the VAT value limit for invoice riporting with the effect of 01.07.2020, the Online Invoicing API became a common language and communication platform that all invoicing solutions across the country conforming to legislation have to support, NTCA takes this IT concept further. Generic types, as well as types of a business catalogue nature and those describing communications which can be used in other projects have been extracted and refactored into a new common XSD from the schemas of Online Invoicing. The common XSD received its own namespace and versioning schema, and is therefore stored in a separate GitHub project at https://github.com/nav-gov-hu/Common. Extraction came at the cost of a substantial amount of namespace changes, however taxpayers will not need to create new technical users for future NTCA XML APIs in exchange, since the technical users registered in Online Invoicing will be able to use the same authentication data and keys, the same base XML structure and the same or similar cryptographic methods to invoke services of APIs of other projects. A great example is the XML API of the ongoing e-VAT project, which will support this platform and mechanism.
-- Since schemas of the Online Invoicing project import a namespace to support the common XSD that is no longer part of the project, the catalogue XSD technology (https://www.oasis-open.org/committees/download.php/14809/xml-catalogs.html#s.using.catalogs) has been implemented. This causes all <xs:import> tags to lose their schemaLocation attributes, and the catalogue defines the location of imports in the schema maintained by NTCA. Most XML processors look for imported schemas in the same file path where the schema definition to process is stored, therefore all developer parties shall decide to either reinsert the schemaLocation tag to the schema downloaded from NTCA, or switch to using the catalogue. Both solutions are adequate. Using the catalogue for the common XSD is generally recommended for the reason that once you use the common schema in multiple projects of yours, you only need to make updates in one location in response to schema changes. A template file is provided for the catalogue for convenience. The template will support URI name and publicId, too, and you will be able to use it with local and web resource access as well, via the GitHub repo.
-- The XSD hierarchy has been cleared, and invoiceData is no longer preferred in the sequence of imports. To achieve this, types used in multiple schemas of the Online Invoicing System, yet too specific to be included in the common XSD, are extracted to a new schema named invoiceBase. Version 3.0 schemas of the Online Invoicing System (API, Data, Annulment, Metrics) all import the common XSD and the invoiceBase schema only, clearing the dependency hierarchy.
-- A new type named CryptoType has been implemented for long-term sustainability in the common XSD. This enables changing hash and cryptographic algorithms for the API without the need to change the schema. The cryptoType attribute is mandatory for elements containing hash values. These include passwordHash, requestSignature and electronicInvoiceHash. The set of values valid for the attribute are disclosed in the interface documentation. The max length of elements containing hash values have been extended significantly to accommodate room for the values generated by future algorithms, and the validation patterns have been weakened for the same reason. From now on, not only hexadecimal values can be specified.
-- The set and features of API services have been improved in response to feature requests received on GitHub: the response to taxpayer query contains the type of queried VAT ID (business or private entrepreneur); furthermore the response to getting the list of transactions contains the processing status of enlisted transactions, so you can use the API to check if the taxpayer has any data exchange transaction not yet queried.
-- The level of severity have been changed from WARNING to INFO for all validation errors which cannot be corrected by the taxpayer, even by submitting amendments.
-
-### 1.2) Transition and developer support
-
-- Developments containing the XML API 3.0 are expected to be ready by the end of September in the test environment, in the company of the interface documentation in Hungarian.
-- Based on our experiences with upgrading to 2.0, our internal processing systems have been prepared to receive production data using v2.0 and v3.0 format in parallel. For this reason, XML API 3.0 can not only receive data in the test environment, but in the production environment, too, immediately. It is expected that parties who would otherwise be blocked by versioning issues if the NTCA API would not work in production environment can still proceed with their upgrade processes. The hardware environment will be ready by the time 3.0 is deployed, therefore requests conforming to either version of the API will be served at the same performance.
-- A long-desired development has come to fruition since online OpenAPI documentation and Swagger UI are both provided for the XML API. Swagger’s URL will soon be disclosed in the test and the production environments and, in addition, GitHub’s Readme will also publish it once the development is released to the public. The API definition will be available for both 2.0 and 3.0. Swagger’s try-out feature will be activated, so you will be able to try to submit XML payloads assembled manually on the user interface. OpenAPI documentation is generated automatically by our CI tool as part of the release process, making availability of up-to-date information guaranteed. Go-live of this feature will be announced on Online Invoicing’s website.
-- Interface documentation will also be published on GitHub, so people, especially those tracking the project, can receive email notifications more quickly and automatically about updates to the documentation.
-- Rapid developer support is kept to be continued for tickets submitted to DEV support on GitHub.
-- You have the option to review the schema and provide feedback for improving the XML API until NTCA finishes this development phase. Afterwards (with the technical notification scheduled to the end of September) such options become really limited, so we kindly ask you to let us know as soon as possible if you find any unhandled cases or unaddressed feature requests. We appreciate all of your feedbacks.
-
-NOTE that version 3.0 of the schema will be published on the website of Online Invoicing as a single ZIP file. For versioning issues, however, we cannot add the common XSD to the Online Invoicing project on GitHub. Those who would like to use the GitHub source need to download both schemas separately. (The contents of the schemas are identical, obviously, independently of the download source.)
-
-## 2) Other changes
-
-### 2.1) Common and base schema definitions (new schemas)
-
-- A new type, AtomicStringType, is implemented in the common XSD, and SimpleTextNotBlank types are inherited from it. GenericDecimalType is another new type of the similar pattern for floating point types.
-- Primitive xs:string types have been retired uniformly in all Online Invoicing schemas (API, Data, Annulment, Metrics), and have been replaced by the subtypes of the corresponding length variant of the common:AtomicStringType type family. Similarly, xs:decimal types have been changed to GenericDecimalType.
-- Request structures used in the common schema do not contain software information, since such information is considered specific to Online Invoicing. Specifying software information is still required in version 3.0 as well, and are implemented in the BasicOnlineInvoiceRequestType subtype in the API schema definition.
-- Legacy 2.0 types of the headerVersion and requestVersion elements have been deleted from the common schema. The new type of these elements is AtomicString15, and these have no enums defined (because other NTCA projects may want to employ a different versioning scheme than that used by Online Invoicing). Version values can be found in the interface documentation, and valid values will be enforced by the system. (There’s no material change on the client side with regards to this, only that validation is relocated from the schema to the service layer. This is only important for those using generated XML payload, since it will not automatically contain 3.0 as the value of requestVersion.)
-- The type BasicResultType has been extended with a new optional response element, ‘notification’. NTCA will use this to convey informational messages via API calls in the future.
-- The following type names have been changed to make them less generic:
-DateType -> InvoiceDateType
-TimestampType -> InvoiceTimestampType
-IndexType -> InvoiceIndexType
-UnboundedIndexType -> InvoiceUnboundedIndexType
-
-### 2.2) API schema definition
-
-- A new element, incorporation, has been added to TaxPayerDataType to tell whether the VAT ID belongs to a business or a private entrepreneur.
-- TransactionType have been extended by information on transaction status (requestStatus) and the indication of technical annulment (technicalAnnulment).
-- From now on, the /queryInvoiceDigest operation returns the value of completenessIndicator.
-- Names of elements containing VAT IDs of tax group members in the response of the /queryInvoiceDigest operation have been refined: supplierGroupTaxNumber -> supplierGroupMemberTaxNumber, customerGroupTaxNumber -> customerGroupMemberTaxNumber. The response may optionally include the value of the electronicInvoiceHash tag submitted, too.
-
-### 2.3) Annulment schema definition
-
-- A new technical annulment reason has been added to the AnnulmentCodeType type: ERRATIC_ELECTRONIC_HASH_VALUE
-
-### 2.4) DATA schema definition
-
-- As a result of switching from data:RegNumType to common:PlateNumberType and of using the according new pattern, you can also use ÖÜŐ characters as well, just as in EKÁER.
-- ekaerId has been moved to the common information section (conventionalInvoiceInfo), and therefore you can specify it at both header and item level.
-
-### 2.5) ERROR changes
-
-- New ERROR: The value of requestVersion and headerVersion (if specified) tags shall fit the range disclosed in the interface documentation.
-- New ERROR: Timestamps shall not be less than 2010-01-01T00:00:00Z.
-- New ERROR: If the value of completenessIndicator is false in a base invoice, it cannot be true in amending documents (since the API does not support this kind of change within an invoice chain, however it is supported the other way around).
-- New ERROR: If privatePersonIndicator is false, customerName AND customerAddress becomes required (B2B invoices).
-- New ERROR: If privatePersonIndicator is true, you are not allowed to specify customerName, customerAddress and customerVatData (B2C invoices).
-- New ERROR: If completenessIndicator is set to true, the only valid value for invoiceAppearance is ELECTRONIC.
-- New ERROR: Specifying a value for electronicInvoicehash becomes required if completenessIndicator is set to true.
-- New ERROR: If electronicInvoicehash has an invalid value, and completenessIndicator is set to true.
-- New ERROR: If completenessIndicator is set to true, mergedItemIndicator shall not be true.
-- New ERROR: If completenessIndicator is set to true, the purchasing party shall not be a natural person.
-- New ERROR: NORMAL and AGGREGATE (consolidated) invoices shall not contain lines of the lineAmountsSimplified type, just as SIMPLIFIED invoices shall not contain lines of the lineAmountsNormal type.
-- New ERROR: You shall not specify a vatContent value for NORMAL and AGGREGATE (consolidated) invoices, just as you shall not specify a vatPercentage value within the VatRateType type for SIMPLIFIED invoices.
-- New ERROR: A new generic temporary error code has been added to be returned the first time when a v3.0 data exchange equivalent to an electronic invoice is received before 04.01.2021.
-- The value of vatContent must not be 0 from now on, since exemption reasons can be specified taxonomically using VatRateType.
-
-### 2.6) WARNING changes
-
-- New WARNING: The value of exchangeRate shall not be 0 if there’s a VAT amount anywhere in the invoice (either in the header or at item level) with a non-zero value, expressed in the currency of the invoice.
-- New WARNING: If mergedItemIndicator has been set to true anywhere in an invoice chain, it shall keep this value from that point on during later amendments.
-- Moving some items down to INFO level is in progress.
-- Review of the current WARNING logic is in progress. We encourage you to submit your feedbacks and suggestions on GitHub in the course of this review process.
-
-### 2.7) Retiring uppercase conversion
-
-No data is converted to uppercase while processing data supplies conforming to version 3.0. String values are persisted in the exact form they had in data exchange records.
-
-### 2.8) Schema and business logic changes since the last published version (**-11-2020)
-
-#### 2.8.1) Customer status in the transaction evidenced by the invoice
-
-There have been several indications on github and other forums that not all business cases can be distinguished with the privatePersonIndicator marker so far. Instead of the indicator, the customerVatStatus tag has been introduced, in this mandatory field the status of the customer in the given transaction must be indicated. The possible values are the following:
-- DOMESTIC: domestic VAT subject. In this case, the customer's name and address (customerName, customerAddress) must be specified. Of the tax numbers, only the Hungarian tax number (customerVatData / customerTaxNumber) can be entered. This entry is mandatory in all cases, except in the case where the supplier (seller) is only VAT registered and the transaction is not subject to domestic reverse charge.
-- OTHER: other (domestic non - VAT subject, non - natural person, foreign VAT subject and foreign non - VAT subject, non - natural person). In this case, the customer's name and address (customerName, customerAddress) must be specified. One of the three tax numbers (customerVatData) can be entered, but is optional.
-- PRIVATE_PERSON: non-VAT subject (domestic or foreign) natural person. In this case, the customerVatData, customerName, customerAddress are forbidden from the customer data, this is checked by blocking business validation.
-
-#### 2.8.2) Vat rate (VatRateType) choice conversion
-
-- the margin-scheme taxation markers (marginSchemeVat and margonSchemeNoVat) have been merged into a field called marginSchemeIndicator, type MarginSchemeType. This simplification is possible because the type already existed at the item level and covers all differences in taxation (Vat and NoVat cases). Schema level enum values: TRAVEL_AGENCY, SECOND_HAND, ARTWORK, ANTIQUES. As a result of the simplification, the marginSchemeIndicator has been removed from the LineType complex type (so the line/marginSchemeIndicator tag has been removed), as it is now specified in the values data (lineAmountsNormal / lineAmountsSimplified).
-- vatAmountMismatch conversion: since the concept of vat rate also exists in these cases, the previous case / reason structure in the node has been converted to vatRate / case. Values that can be specified in vatRate are 0.27, 0.18, 0.05, 0.2126, 0.1525, 0.0426. Its value is checked by blocking business validation.
-- due to the previous point, the noVatCharge case was excluded from the vatAmountMismatch case values (No VAT was charged under §17), as there is no interpretable vat rate in this case. The new noVatCharge field's type is boolean.
-- Introduction of UNKNOWN value among case values: for modify / storno invoices referenced to invoices without previous data deport or having version pre-3.0, the exact case value cannot be determined in all cases in the vatExemption / vatOutOfScope / vatAmountMismatch cases. In this case, the case value set was expanded with the UNKNOWN value in all three cases. This value can only be specified in such cases.
-- in vatExemption and vatOutOfScope nodes the reason field length changed from 100 to 200
-- for boolean vat rates (vatDomesticReverseCharge, noVatCharge) only the logical true value (true or 1) is accepted at the schema level (fixed: true attribute), since only then does it make sense to indicate the given mode in business.
-- remove THK value from vatOutOfScope / case accepted values at both item and summary level.
-
-#### 2.8.3) ERROR modifications
-
-- modified ERROR: if the customer is not a private person (customerVatStatus is not PRIVATE_PERSON), then customerName AND customerAddress are required (B2B invoice)
-- modified ERROR: if the customer is a private person (customerVatStatus is PRIVATE_PERSON), then customerName, customerAddress and customerVatData cannot be specified (B2C invoice)
-- modified ERROR: the accepted value of the passwordHash cryptoType attribute has been changed to SHA-512 (instead of the previously incorrectly defined SHA2-512)
-- modified ERROR: for vatExemption / vatOutOfScope / vatAmountMismatch, the UNKNOWN value in the case field is acceptable, but only for modify / storno invoices referenced to invoices without previous data deport or having version pre-3.0
-- deleted ERROR: if there is advance data for the given item (advanceIndicator = true), then the advancePaymentData node is not mandatory, because this data is not yet available for the advance invoice
-- new ERROR: if the customer is a domestic VAT subject (customerVatStatus is DOMESTIC), the Hungarian tax number is mandatory, except in the case when the supplier (seller) is only registered for VAT and the transaction is not subject to domestic reverse charge
-- new ERROR: if the customer is a domestic VAT subject (customerVatStatus is DOMESTIC), the provision of the communityVatNumber is prohibited
-- new ERROR: if the customer is a domestic VAT subject (customerVatStatus is DOMESTIC), the third country tax number (thirdStateTaxId) is prohibited
-- new ERROR: at item or aggregate level, if the tax base and levied tax are different (vatAmountMismatch), the value of vatAmountMismatch / vatRate can only be one of the following: 0.27, 0.18, 0.05, 0.2126, 0.1525, 0.0426.
-- new ERROR: all timestamp values specified in the API request must fall within the server time +- 1 day interval
-
-#### 2.8.4) Other minor changes
-
-- The request part of the /queryTransactionList operation has been supplemented with an optional requestStatus field to filter the status of the transaction.
-- PageType in the common XSD has been split into RequestPageType and ResponsePageType. This was necessary because in case of 0 hits, the value of availablePage in the response is 0.
-- the date of first entry into service of a new means of transport (firstEntryIntoService) has become optional in the NewTransportMeanType type.
-- in the ConventionalInvoiceInfoType type containing named data, glnNumbers field has been split into glnNumbersSupplier and glnNumbersCustomer nodes.
-- the exchange rate has become the general mandatory data content for data provision. Thus, it is necessary to fill in this field at the real exchange rate not only for invoices containing vat passed on, but in all cases. As a result, the zero exchange rate previously included in the documentation will no longer be usable, which will be enforced at the schema level as well.
-- the IncorporationType value set has been expanded in response to the queryTaxpayer operation. The new value is TAXABLE_PERSON, which identifies taxpayers with tax numbers, treating them separately from self employed private entrepreneurs.
-
-## 3) Step by step developer guide for v3.0
-
-### 3.1) API
-
-#### 3.1.1) Mandatory changes related to the API schema
-
-- Increase the version tag in all invoked URLs. Make sure you replace all instances of ‘/v2/’ with ‘/v3/’.
-- Increase the version number in the namespace the API schema reference to 3.0 in all root elements, and make a reference to the common XSD. Example: 'xmlns="http://schemas.nav.gov.hu/OSA/3.0/api" xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common"'.
-- Increase the value of ‘version’ to 3.0 in all requestVersion tags.
-- Include the namespace tag you defined for the common XSD in all opening, closing and child tags of the header and user nodes. If you use the example namespace we provided, it will be 'common:'.
-- Include the 'cryptoType="SHA-512"' attribute in the user/passwordHash tag.
-- Include the 'cryptoType="SHA3-512"' attribute in the user/requestSignature tag.
-
-#### 3.1.2) Scenario-specific changes related to the API schema
-
-- If you employ DTO generation in your project, you will not be able to compile/build it with the new schemas. You can either use catalog XSD to import the common and the base schemas, and reference them in your project; or re-insert a schemaLocation attribute to the downloaded schemas with a filepath value of your choice. (You can simply view the declaration of a v2.0 schema to learn how the attribute was used previously.) You can access the common XSD’s project on page https://github.com/nav-gov-hu/Common.
-- If you validate responses in your project, be prepared, if necessary, that business responses from the API will not always be placed in the default namespace, since it may be placed in a different one than in v2.0. For example, encodedExchangeToken for tokenExchange, transactionId for manageInvoice response and other query results will be returned in a different namespace. This is a consequence of importing the common XSD.
-- If your software reports the verification hash of the electronic invoices, you have to specify it in API XML instead of Data XML in v3.0. The name of the tag is still electronicInvoiceHash, however it is now located on XPath ManageInvoiceRequest/invoiceOperations/invoiceOperation/electronicInvoiceHash. Do not forget that even this tag has a cryptoType attribute. When completenessIndicator is false, the hash method needs to be SHA3-512 or SHA-256. Hovewer, there is no server side validation for the hash value in this case.
-- If you want your software to use the new v3.0 electronic invoicing feature set completenessIndicator to true, provide SHA3-512 for the method of cryptoType and calculate the correct hash value based on the input of the invoiceData object found in the API XML. The server validates the correct hash value in this case.
-- If your software uses the /queryTaxpayer service to retrieve taxpayer information, prepare it for processing the ‘incorporation’ tag contained in the response.
-- If your software uses the /queryTransactionList service to list transactions, prepare it for processing the requestStatus and the technicalAnnulment tags contained in the response.
-- If your software uses the /queryInvoiceData service to retrieve complete invoice data, prepare it to accept v3.0 invoice XML payloads in the responses. Be sure to properly adjust parser logic, business logic, presentation and other components in your software. Be also prepared that the operation may return the value of the electronicInvoiceHash, if it was specified in the submission.
-- If your software uses the /queryInvoiceDigest service to get key invoice information, prepare it for processing the completenessIndicator tag contained in the response. Be also prepared that the group VAT ID of sellers and customers will be returned under new names (see section 2.2).
-- It is recommended to prepare your software to process and display the value of the ‘notification’ tag optionally included in responses. The server will not return any values in the tag yet (populating it with values is subject to a different development effort), so you may want to use unit tests or debug mode to check the soundness of your software.
-- Examine whether retiring uppercase conversion causes any break or unexpected change in your software (for the changes of the responses of the /queryInvoiceData and /queryInvoiceDigest services, for example), and adjust your software if necessary.
-
-### 3.2) Data
-
-#### 3.2.1) Mandatory changes related to the Data schema
-
-- Increase the version number in the namespace of the Data schema reference to 3.0 in root element InvoiceData, and reference the base XSD. Example: 'xmlns="http://schemas.nav.gov.hu/OSA/3.0/data" xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base"'.
-- Top level invoice data shall include the value of the completenessIndicator tag, which decides whether a data exchange instance is equivalent to an issued electronic invoice or not. You have to specify the new tag after the invoiceIssueDate tag. It is recommended to specify the default false value, since the server shall not accept data exchange submissions with this tag set to true before 04.01.2021. It is recommended to govern the behaviour of the related business logic via a business or configuration parameter that can be changed dynamically so that you do not need to publish a new version of the client just for activating this feature when time is up.
-- You have to implement the changes made to the value of the base XSD namespace in the child tags for three complex data types. This includes TaxNumberType (tax number, VAT code, county code) describing Hungarian VAT numbers, as well as address types, namely SimpleAddressType for simple addressing and DetailedAddressType for more structured address information. Make sure to implement these changes in every location where these types may occur in the Data XML. Be warned that this change to the namespace is different from that made to the API schema, since the parent tag in this case is not allowed to get a new namespace value. The sound namespace for the API:
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<TokenExchangeRequest xmlns="http://schemas.nav.gov.hu/OSA/3.0/api" xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common">
- <common:header>
- <common:requestId>String</common:requestId>
- <common:timestamp>2020-09-06T12:09:24.901Z</common:timestamp>
- <common:requestVersion>3.0</common:requestVersion>
- <common:headerVersion>1.0</common:headerVersion>
- </common:header>
-```
-For the Data schema, you have to specify supplier data like this (provided that you use the namespace name from the example, 'base:'):
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<InvoiceData xmlns="http://schemas.nav.gov.hu/OSA/3.0/data" xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.nav.gov.hu/OSA/3.0/data invoiceData.xsd">
- <invoiceNumber>2021/1</invoiceNumber>
- <invoiceIssueDate>2020-09-06</invoiceIssueDate>
- <completenessIndicator>false</completenessIndicator>
- <invoiceMain>
- <invoice>
- <invoiceHead>
- <supplierInfo>
- <supplierTaxNumber>
- <base:taxpayerId>88888888</base:taxpayerId>
- <base:vatCode>5</base:vatCode>
- <base:countyCode>41</base:countyCode>
- </supplierTaxNumber>
- <groupMemberTaxNumber>
- <base:taxpayerId>44444444</base:taxpayerId>
- <base:vatCode>4</base:vatCode>
- <base:countyCode>42</base:countyCode>
- </groupMemberTaxNumber>
- <supplierName>Supplier Ltd.</supplierName>
- <supplierAddress>
- <base:simpleAddress>
- <base:countryCode>HU</base:countryCode>
- <base:postalCode>1031</base:postalCode>
- <base:city>Budapest</base:city>
- <base:additionalAddressDetail>Example street 1.</base:additionalAddressDetail>
- </base:simpleAddress>
- </supplierAddress>
- </supplierInfo>
-```
-
-While the header tag also received a new namespace in addition to its children in case of the API schema, the supplierTaxNumber and the supplierAddress tag remained in the default namespace, and the new namespace was only added to their child tags.
-- When you provide customer data you need to start by specifying in the customerVatStatus tag whether the customer in the invoice is domestic VAT subject/ other (domestic non-VAT subject, non-natural person, foreign VAT subject and foreign non-VAT subject, non-natural person)/ non-VAT subject (domestic or foreign) natural person. This tag shall come first within the customerInfo tag. Unless this information can be computed using some business logic, it is recommended to add an option for the users to mandatorily specify it on the UI, since the absence of the customer’s VAT ID on an invoice does not necessarily imply that the customer is a private person (just think of invoices issued to private entrepreneurs). This is hard to tell apart algorithmically.
-- For invoices issued to others than private persons the customer VAT ID shall be specified on a new XPath, customerInfo/customerVatData. You have to prepare your software for this. Do not forget that some invoices will not include a VAT ID even if the particular invoice is issued to someone else than a private person (such as to a block of flats or an association not engaged in any economical or business activity).
-- Add business rules to properly specify and validate customer data in XML:
- - if the customer is a domestic VAT subject
- - the following VAT ID must be specified: Hungarian VAT ID (optionally including the VAT group, customerTaxNumber+groupMemberTaxNumber), except when the supplier is VAT registered only
- - if the customer is a non-VAT subject (domestic or foreign) natural person
- - you cannot specify any nodes containing a name (customerName), an address (customerAddress) or a customer VAT ID (customerVatData)
- - if the customer is other (domestic non-VAT subject, non-natural person, foreign VAT subject and foreign non-VAT subject, non-natural person)
- - only one of the following VAT IDs can be specified, but it's not mandatory: Hungarian VAT ID (optionally including the VAT group, customerTaxNumber+groupMemberTaxNumber), the EU VAT ID (communityVatNumber) and the VAT ID of other countries (thirdStateTaxId)
- - the following nodes must be specified: name (customerName) and address (customerAddress)
-
-WARNING: According to the business rules, name and address information shall be included in the invoice for private persons, however such data must not be included in the XML submitted as the means of data exchange.
-- If the data exchange payload includes an invoice item, you must specify mergedItemIndicator. The tag shall be placed in front of item data (invoiceLines), and it must be the first one.
-- If the invoice contains advance payment information, you have to specify such information on a new XPath, line/advanceData. In the presence of advance payment information (advanceIndicator=true), you can specify the number of the original invoice for the advance payment (advanceOriginalInvoice), the date of the advance payment (advancePaymentDate) and the exchange rate used (advanceExchangeRate) under node advancePaymentData. Pay attention that you must include the value of invoiceNumber of the invoice containing the advance payment in the advanceOriginalInvoice tag, that is, this reference is invoice-level information, not an item-level one.
-- Keep in mind that your software shall not allow specifying VAT amount (vatContent) used in simplified invoices on invoice or item level (i.e., in nodes described by VatRateType) in invoices of other types (NORMAL and AGGREGATE types), or your data exchange will fail for an ERROR.
-- Keep in mind that your software shall not allow specifying VAT amount (vatPercentage) used in normal/aggregate invoices on invoice or item level (i.e., in nodes described by VatRateType) in invoices of other types (SIMPLIFIED type), or your data exchange will fail for an ERROR.
-
-#### 3.2.2) Scenario-specific changes related to the Data schema
-
-- If you want your software to use the new v3.0 electronic invoicing feature, consider the followings:
- - do not allow issuing (CREATE operation) electronic invoices (with completenessIndicator=true) or corrective financial documents (MODIFY operation for amendments, STORNO operation for void invoices), when:
- - the invoice or the corrective financial document is issued to private persons (customerVatStatus=PRIVATE_PERSON),
- - the invoice or the corrective financial document contains item data aggregated for size decrease (mergedItemIndicator=true),
- - the type of the invoice or the corrective financial document is not an electronic invoice (invoiceAppearance != ELECTRONIC),
- - the issue date (invoiceIssueDate) of the invoice or the corrective financial document is before 04.01.2021,
- - the system date is before 04.01.2021, or a business parameter created for this purpose disables the feature
- - in addition to the rules above, make sure to disable creating corrective electronic financial documents (with completenessIndicator=true) with MODIFY and STORNO operations for amendments and voids, respectively, with base invoices existing in the system (modifyWithoutMaster=false) with completenessIndicator set to false
- - include the electronicInvoiceHash tag with the proper cryptoType and fingerprint (hash value) in the API XML, according to the interface documentation.
-Software not conforming to these rules will fail to supply data for an ERROR, and therefore it may not be able to issue the electronic invoice or the amending financial document.
-- If your software supports invoices with parties exempt to VAT (vatExemption) and invoices issued to regions out of the territory of the VAT act (vatOutOfScope), offer a list to the users on the UI for the various scenarios, based on the valid values found in the interface documentation, or map your values to these values behind the scenes, transparently to the user. Place enumeration value in the case tag, and the value specified by the user on the invoice in the reason tag within the XML, both on item and invoice summary level. (for accepted valueset see: PDF 2.2.3.2.1 vatRate chapter)
-- If your software manages the cases to handle differences of tax base and accumulated tax enlisted in the interface documentation, make sure to properly specify the value of the vatAmountMismatch tag, both on item and invoice summary level. If the exchange rate cannot be computed in any of these cases, set the value of the exchangeRate tag to 0. (for accepted valueset see: PDF 2.2.3.2.1 vatRate chapter)
-- If your software supports cannot determine case values for modify / storno invoices referenced to invoices without previous data deport or having version pre-3.0, use UNKNOWN value.
-- If your software supports invoices with items marking the margin-scheme taxation as per section 169 (p)(q), make sure to use the new marginSchemeIndicator tag and specify the value, instead of using the previous marginSchemeVat and margonSchemeNoVat indicators
-- If your software supports simplified invoices, the amount of VAT (vatContent) for items shall be specified on a new XPath, lineAmountsSimplified/lineVatRate. The summary section is also affected, and the new XPath for summary VAT amount information is summarySimplified/vatRate. This is also the location to specify all reasons of exempt which you could only specify for non-simplified invoices in the past. Proper management of exempts is especially important, since vatContent could have a value of 0 until v2.0 of the API, however this option is retired in v3.0, and the new validation will trigger an error for this value. Implement all the changes in your software. Make sure to disable specifying VAT rate (vatPercentage) on item and summary level for simplified invoices, or your data exchange will fail due to an ERROR.
-- If your software included EKÁER codes on item level, you have to include this data on a new XPath, line/conventionalInvoiceInfo. From v3.0, EKÁER codes can be included in the invoice header, too, not only in item lines.
-- If you want to support specifying additional transaction information just introduced to the data model (such as PO number, agreement ID, delivery note number etc.) on invoices either for customer or supplier role, create the corresponding data entry UIs, and include the specified data at invoice header level or at item level in the XML file, under the /conventionalInvoiceInfo or /conventionalLineInfo nodes. Cardinality of the tags is unbounded, so you can repeat tags as many times as necessary.
-- If your software supports oversize data exchange (when HTTP content-length >= 10,485,760 bytes), merge items lines at item/service level according to the interface documentation, and aggregate the corresponding values. Do not forget to indicate the fact of merging by adding mergedItemIndicator=true above the item level in the data exchange payload. Note that once this item becomes true anywhere in an invoice chain, it cannot be reverted to false any more in subsequent corrective documents (with higher modificationIndex values), or the data exchange will receive a WARNING. Be warned that escalating data exchange regarding such documents for manual processing is against the law, and the invoicing software must implement the merging logic itself.
-- If your software supports public utility settlement invoices, and make sure to set utilitySettlementIndicator the correct value.
-
-### 3.3) Annulment
-
-#### 3.3.1) Mandatory changes related to the Annulment schema
-
-N/A
-
-#### 3.3.2) Scenario-specific changes related to the Annulment schema
-
-- If your software supports the technical annulment feature of the API, change the namespace URI of the InvoiceAnnulment root element to 'xmlns="http://schemas.nav.gov.hu/OSA/3.0/annul"' in the inner XML.
-- If your software reports verification hash values of electronic invoices, presence of an invalid hash prevents further correction of the data exchange, and therefore you have to submit a technical annulment. You have to use a new annulmentCode value in this scenario, so be sure to add the 'ERRATIC_ELECTRONIC_HASH_VALUE' value to the technical annulment request. Note that this code can only be used when completenessIndicator=false, and therefore this note also regards this precious case only. (If completenessIndicator is set to true, there is no possibility for technical annulment. On the other side, the hash cannot be invalid in that case, since the server rejects data supplies of this kind if the hash is invalid.)
-
-### 3.4) ServiceMetrics
-
-#### 3.4.1) Mandatory changes related to the ServiceMetrics schema
-
-N/A
-
-#### 3.4.2) Scenario-specific changes related to the ServiceMetrics schema
-
-- If your software uses the metrics query feature of the API, please refer to section 3.1.2 for notes on DTO generation and response validation.
\ No newline at end of file
+++ /dev/null
-<?xml version='1.0' encoding='UTF-8'?>
-<catalog xmlns='urn:oasis:names:tc:entity:xmlns:xml:catalog' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xsi:schemaLocation='urn:oasis:names:tc:entity:xmlns:xml:catalog Catalog.xsd' prefer="public">
-<!--reference as name & filepath-->
- <uri name="http://schemas.nav.gov.hu/NTCA/1.0/common" uri="./files/NTCA/Common/common.xsd"/>
- <uri name="http://schemas.nav.gov.hu/OSA/3.0/base" uri="./files/OSA/Invoice/invoiceBase.xsd"/>
-<!--reference as name & URI-->
- <!--<uri name="http://schemas.nav.gov.hu/NTCA/1.0/common" uri="https://raw.githubusercontent.com/nav-gov-hu/Common/Common-1.0.RC3/src/schemas/nav/gov/hu/NTCA/common.xsd"/>-->
-</catalog>
-
-
-<!--<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">-->
-
-<!--reference as publicId & filepath-->
- <!--<public publicId="http://schemas.nav.gov.hu/NTCA/1.0/common" uri="./files/NTCA/Common/common.xsd"/>-->
- <!--<public publicId="http://schemas.nav.gov.hu/OSA/3.0/base" uri="./files/OSA/Invoice/invoiceBase.xsd"/>-->
-<!--reference as publicId & URI-->
- <!--<public publicId="http://schemas.nav.gov.hu/NTCA/1.0/common" uri="https://raw.githubusercontent.com/nav-gov-hu/Common/Common-1.0.RC3/src/schemas/nav/gov/hu/NTCA/common.xsd"/>-->
-<!--</catalog>-->
\ No newline at end of file
+++ /dev/null
-<?xml version="1.0" encoding="UTF-8"?>
-<!--
-# Project: Magyar Online Számla Rendszer invoiceAnnulment XML séma
-# Author: NAV Informatikai Intézet
-
-# Version: v3.0 2020/07/31
--->
-<xs:schema xmlns="http://schemas.nav.gov.hu/OSA/3.0/annul" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:common="http://schemas.nav.gov.hu/NTCA/1.0/common" xmlns:base="http://schemas.nav.gov.hu/OSA/3.0/base" targetNamespace="http://schemas.nav.gov.hu/OSA/3.0/annul" elementFormDefault="qualified" attributeFormDefault="unqualified">
- <xs:import namespace="http://schemas.nav.gov.hu/NTCA/1.0/common"/>
- <xs:import namespace="http://schemas.nav.gov.hu/OSA/3.0/base"/>
- <xs:simpleType name="AnnulmentCodeType">
- <xs:annotation>
- <xs:documentation xml:lang="hu">Technikai érvénytelenítés kód típusa</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment code type</xs:documentation>
- </xs:annotation>
- <xs:restriction base="common:AtomicStringType32">
- <xs:enumeration value="ERRATIC_DATA">
- <xs:annotation>
- <xs:documentation xml:lang="hu">Hibás adattartalom miatti technikai érvénytelenítés</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment due to erratic data content</xs:documentation>
- </xs:annotation>
- </xs:enumeration>
- <xs:enumeration value="ERRATIC_INVOICE_NUMBER">
- <xs:annotation>
- <xs:documentation xml:lang="hu">Hibás számlaszám miatti technikai érvénytelenítés</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment due to erratic invoice number</xs:documentation>
- </xs:annotation>
- </xs:enumeration>
- <xs:enumeration value="ERRATIC_INVOICE_ISSUE_DATE">
- <xs:annotation>
- <xs:documentation xml:lang="hu">Hibás számla kiállítási dátum miatti technikai érvénytelenítés</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment due to erratic invoice issue date</xs:documentation>
- </xs:annotation>
- </xs:enumeration>
- <xs:enumeration value="ERRATIC_ELECTRONIC_HASH_VALUE">
- <xs:annotation>
- <xs:documentation xml:lang="hu">Hibás elektronikus számla hash érték miatti technikai érvénytelenítés</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment due to erratic electronic invoice hash value</xs:documentation>
- </xs:annotation>
- </xs:enumeration>
- </xs:restriction>
- </xs:simpleType>
- <xs:complexType name="InvoiceAnnulmentType">
- <xs:annotation>
- <xs:documentation xml:lang="hu">Korábbi adatszolgáltatás technikai érvénytelenítésének adatai</xs:documentation>
- <xs:documentation xml:lang="en">Data of technical annulment concerning previous data exchange</xs:documentation>
- </xs:annotation>
- <xs:sequence>
- <xs:element name="annulmentReference" type="common:SimpleText50NotBlankType">
- <xs:annotation>
- <xs:documentation xml:lang="hu">A technikai érvénytelenítéssel érintett számla vagy módosító okirat sorszáma</xs:documentation>
- <xs:documentation xml:lang="en">Sequential number of the invoice or modification document to be annuled</xs:documentation>
- </xs:annotation>
- </xs:element>
- <xs:element name="annulmentTimestamp" type="base:InvoiceTimestampType">
- <xs:annotation>
- <xs:documentation xml:lang="hu">A technikai érvénytelenítés időbélyege a forrásrendszerben UTC idő szerint</xs:documentation>
- <xs:documentation xml:lang="en">Timestamp of the technical annulment in UTC time</xs:documentation>
- </xs:annotation>
- </xs:element>
- <xs:element name="annulmentCode" type="AnnulmentCodeType">
- <xs:annotation>
- <xs:documentation xml:lang="hu">A technikai érvénytelenítés kódja</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment code</xs:documentation>
- </xs:annotation>
- </xs:element>
- <xs:element name="annulmentReason" type="common:SimpleText1024NotBlankType">
- <xs:annotation>
- <xs:documentation xml:lang="hu">A technikai érvénytelenítés oka</xs:documentation>
- <xs:documentation xml:lang="en">Technical annulment reason</xs:documentation>
- </xs:annotation>
- </xs:element>
- </xs:sequence>
- </xs:complexType>
- <xs:element name="InvoiceAnnulment">
- <xs:annotation>
- <xs:documentation xml:lang="hu">XML root element, a technikai érvénytelenítés adatait leíró típus, amelyet BASE64 kódoltan tartalmaz az invoiceApi sémaleíró invoiceAnnulment elementje</xs:documentation>
- <xs:documentation xml:lang="en">XML root element, technical annulment data type in BASE64 encoding, equivalent with the invoiceApi schema definition's invoiceAnnulment element</xs:documentation>
- </xs:annotation>
- <xs:complexType>
- <xs:complexContent>
- <xs:extension base="InvoiceAnnulmentType"/>
- </xs:complexContent>
- </xs:complexType>
- </xs:element>
-</xs:schema>
public class Guard implements Initiator {
@Override
public void doInit(Page page, Map<String, Object> args) throws Exception {
- //HttpServletRequest request = (HttpServletRequest) Executions.getCurrent().getNativeRequest();
+ //HttpServletRequest requestInvoiceChain = (HttpServletRequest) Executions.getCurrent().getNativeRequest();
Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
if (authentication == null || authentication instanceof AnonymousAuthenticationToken) {
import hu.user.lis.db.Invoice;
import hu.user.lis.db.Partner;
import hu.user.lis.db.Project;
+import hu.user.lis.ui.data.PartnersDataModel;
+import hu.user.lis.ui.editor.common.Editors;
import lombok.Getter;
import lombok.Setter;
import lombok.extern.log4j.Log4j2;
import org.zkoss.zk.ui.Component;
import org.zkoss.zk.ui.event.Event;
import org.zkoss.zk.ui.event.Events;
+import org.zkoss.zk.ui.select.annotation.WireVariable;
import org.zkoss.zul.Window;
import java.util.Objects;
@Log4j2
-@Getter
-@Setter
public class ImportInvoiceApproveEditorModel extends InvoiceEditorModel {
+ @WireVariable
+ PartnersDataModel partnersDataModel;
+
+ @Getter
+ @Setter
+ boolean canEditPartner;
+
@Init
public void init() {
super.init();
+ canEditPartner = Objects.isNull(getFormDocument().getPartner().getId());
}
@Override
validate();
}
+ @Command
+ public void onEditPartner() {
+ Partner entity = partnersDataModel.clone(getFormDocument().getPartner());
+ Editors.doEdit(Editors.PARTNER, entity, modifiedEntity -> {
+ getFormDocument().setPartner(modifiedEntity);
+ });
+ }
+
@Command
public void onCloseApproveWindow(@BindingParam("target") Window target, @BindingParam("save") int save) {
if (save == 0) {
ImmutableMap.of("approved", true, "modifiedEntity", getFormDocument())));
}
}
+
}
import hu.user.lis.db.Invoice;
import hu.user.lis.db.Partner;
import hu.user.lis.db.Project;
+import hu.user.lis.ui.data.PartnersDataModel;
+import hu.user.lis.ui.editor.common.Editors;
import lombok.Getter;
import lombok.Setter;
import lombok.extern.log4j.Log4j2;
-import org.zkoss.bind.annotation.AfterCompose;
-import org.zkoss.bind.annotation.ContextParam;
-import org.zkoss.bind.annotation.ContextType;
-import org.zkoss.bind.annotation.Init;
+import org.zkoss.bind.annotation.*;
import org.zkoss.zk.ui.Component;
+import org.zkoss.zk.ui.select.annotation.WireVariable;
import java.util.Objects;
@Log4j2
-@Getter
-@Setter
public class ImportInvoiceAssignEditorModel extends InvoiceEditorModel {
+ @WireVariable
+ PartnersDataModel partnersDataModel;
+
+ @Getter
+ @Setter
+ boolean canEditPartner;
+
@Init
public void init() {
super.init();
+ canEditPartner = Objects.isNull(getFormDocument().getPartner().getId());
}
@Override
getEntitySelectorRouter().configureSelector(Partner.class, getFormDocument(), "partner");
validate();
}
+
+ @Command
+ public void onEditPartner() {
+ Partner entity = partnersDataModel.clone(getFormDocument().getPartner());
+ Editors.doEdit(Editors.PARTNER, entity, modifiedEntity -> {
+ getFormDocument().setPartner(modifiedEntity);
+ });
+ }
}
import org.apache.commons.lang3.StringUtils;
import org.zkoss.bind.BindContext;
import org.zkoss.bind.BindUtils;
-import org.zkoss.bind.PropertyChangeEvent;
import org.zkoss.bind.annotation.*;
import org.zkoss.zk.ui.Component;
import org.zkoss.zk.ui.event.Event;
import org.zkoss.zk.ui.event.UploadEvent;
import org.zkoss.zul.Messagebox;
-import java.util.Arrays;
import java.util.Objects;
@Log4j2
@Override
public void onEvent(Event evt) {
- String[] dates = {"completionDate", "createDate", "paymentDeadline"};
if (isEventForCurrentDocument(evt)) {
- PropertyChangeEvent propertyEvent = (PropertyChangeEvent) evt;
- if (Arrays.asList(dates).contains(propertyEvent.getProperty())) {
- log.info("");
- }
+// PropertyChangeEvent propertyEvent = (PropertyChangeEvent) evt;
+// String[] dates = {"completionDate", "createDate", "paymentDeadline"};
+// if (Arrays.asList(dates).contains(propertyEvent.getProperty())) {
+// log.info("");
+// }
validate();
}
}
import com.google.common.collect.ImmutableMap;
import hu.user.lis.db.Invoice;
+import hu.user.lis.db.Partner;
import hu.user.lis.db.repository.InvoiceRepository;
+import hu.user.lis.db.repository.PartnerRepository;
import hu.user.lis.ui.Constants;
import hu.user.lis.ui.data.ApproveInvoicesDataModel;
import hu.user.lis.ui.data.common.CachedSpringDataModel;
import hu.user.lis.ui.view.common.EntityViewModel;
import lombok.Getter;
import lombok.extern.log4j.Log4j2;
+import org.springframework.transaction.annotation.Transactional;
import org.zkoss.bind.BindUtils;
import org.zkoss.bind.annotation.Command;
import org.zkoss.bind.annotation.Init;
@WireVariable
InvoiceRepository invoiceRepository;
+ @WireVariable
+ PartnerRepository partnerRepository;
+
@WireVariable
EventBus eventBus;
}
@Command
+ @Transactional
public void onHandleTask() {
Invoice entity = (Invoice) getSelectedEntity().get("invoiceEntity");
ImmutableMap<String, Object> args = ImmutableMap.of("formDocument", entity);
Invoice modifiedEntity = (Invoice) results.get("modifiedEntity");
//TODO move entity persistance to BPMN
if (approved) {
+ Partner partner = modifiedEntity.getPartner();
+ if (Objects.isNull(partner.getId())) {
+ partnerRepository.save(partner);
+ }
invoiceRepository.save(modifiedEntity);
}
approveInvoicesDataModel.completeTask(getSelectedEntity(), results);
@Log4j2
public class PartnersViewModel extends FilterActiveViewModel<Partner> {
- @WireVariable
@Getter
+ @WireVariable
PartnersDataModel partnersDataModel;
@Override
<textbox hflex="true" instant="true"
value="@bind(vm.formDocument.title) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
- <label value="Partner"/>
- <entity-selector entity="Partner"/>
+ <hlayout>
+ <label value="Partner"/>
+ <entity-selector entity="Partner"/>
+ <button label="Bezár" onClick="@command('onEditPartner')"
+ disabled="@bind(not vm.canEditPartner)"/>
+ </hlayout>
+
<hlayout>
<vlayout>
<label value="Sorszám"/>
- <textbox instant="true" value="@bind(vm.formDocument.humanId) @validator(vm)"
+ <textbox readonly="true" value="@bind(vm.formDocument.humanId) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Pénznem"/>
- <combobox instant="true" model="${currencies}"
+ <combobox readonly="true" model="${currencies}"
selectedItem="@bind(vm.formDocument.currency) @validator(vm)"
- onChange="@command('onNetAmountChange')"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Nettó összeg"/>
- <doublebox value="@bind(vm.formDocument.netAmount) @validator(vm)"
- format="#,###.##" locale="hu" instant="true"
- onChange="@command('onNetAmountChange')"
+ <doublebox readonly="true"
+ value="@bind(vm.formDocument.netAmount) @validator(vm)"
+ format="#,###.##" locale="hu"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Bruttó összeg"/>
- <doublebox value="@bind(vm.formDocument.grossAmount) @validator(vm)"
- format="#,###.##" locale="hu" instant="true"
+ <doublebox readonly="true"
+ value="@bind(vm.formDocument.grossAmount) @validator(vm)"
+ format="#,###.##" locale="hu"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="ÁFA"/>
- <doublebox value="@bind(vm.formDocument.vatAmount) @validator(vm)"
- format="#,###.##" locale="hu" instant="true"
+ <doublebox readonly="true"
+ value="@bind(vm.formDocument.vatAmount) @validator(vm)"
+ format="#,###.##" locale="hu"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
</hlayout>
<hlayout>
<vlayout>
<label value="Kiállítás dátuma"/>
- <datebox instant="true" format="yyyy. MM. dd."
+ <datebox readonly="true" format="yyyy. MM. dd."
value="@bind(vm.formDocument.createDate) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Teljesítés dátuma"/>
- <datebox instant="true" format="yyyy. MM. dd."
+ <datebox readonly="true" format="yyyy. MM. dd."
value="@bind(vm.formDocument.completionDate) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Fizetési határidő"/>
- <datebox instant="true" format="yyyy. MM. dd."
+ <datebox readonly="true" format="yyyy. MM. dd."
value="@bind(vm.formDocument.paymentDeadline) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<textbox hflex="true" instant="true"
value="@bind(vm.formDocument.title) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
- <label value="Partner"/>
- <entity-selector entity="Partner"/>
+ <hlayout>
+ <label value="Partner"/>
+ <entity-selector entity="Partner"/>
+ <button label="Bezár" onClick="@command('onEditPartner')"
+ disabled="@bind(not vm.canEditPartner)"/>
+ </hlayout>
+
<hlayout>
<vlayout>
<label value="Sorszám"/>
- <textbox instant="true" value="@bind(vm.formDocument.humanId) @validator(vm)"
+ <textbox readonly="true" value="@bind(vm.formDocument.humanId) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Pénznem"/>
- <combobox instant="true" model="${currencies}"
+ <combobox readonly="true" model="${currencies}"
selectedItem="@bind(vm.formDocument.currency) @validator(vm)"
- onChange="@command('onNetAmountChange')"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Nettó összeg"/>
- <doublebox value="@bind(vm.formDocument.netAmount) @validator(vm)"
- format="#,###.##" locale="hu" instant="true"
- onChange="@command('onNetAmountChange')"
+ <doublebox readonly="true"
+ value="@bind(vm.formDocument.netAmount) @validator(vm)"
+ format="#,###.##" locale="hu"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Bruttó összeg"/>
- <doublebox value="@bind(vm.formDocument.grossAmount) @validator(vm)"
- format="#,###.##" locale="hu" instant="true"
+ <doublebox readonly="true"
+ value="@bind(vm.formDocument.grossAmount) @validator(vm)"
+ format="#,###.##" locale="hu"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="ÁFA"/>
- <doublebox value="@bind(vm.formDocument.vatAmount) @validator(vm)"
- format="#,###.##" locale="hu" instant="true"
+ <doublebox readonly="true"
+ value="@bind(vm.formDocument.vatAmount) @validator(vm)"
+ format="#,###.##" locale="hu"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
</hlayout>
<hlayout>
<vlayout>
<label value="Kiállítás dátuma"/>
- <datebox instant="true" format="yyyy. MM. dd."
+ <datebox readonly="true" format="yyyy. MM. dd."
value="@bind(vm.formDocument.createDate) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Teljesítés dátuma"/>
- <datebox instant="true" format="yyyy. MM. dd."
+ <datebox readonly="true" format="yyyy. MM. dd."
value="@bind(vm.formDocument.completionDate) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<vlayout>
<label value="Fizetési határidő"/>
- <datebox instant="true" format="yyyy. MM. dd."
+ <datebox readonly="true" format="yyyy. MM. dd."
value="@bind(vm.formDocument.paymentDeadline) @validator(vm)"
forward="onOK=submit.onClick, onCancel=cancel.onClick"/>
</vlayout>
<menuseparator/>
<menuitem iconSclass="z-icon-user" label="Munkatársak"
onClick="@command(vm.selectPage('~./associates.zul'))"/>
- <menu iconSclass="z-icon-tasks" label="Számla import">
+ <menu iconSclass="z-icon-euro" label="Számlák">
<menupopup>
- <menuitem iconSclass="z-icon-paperclip" label="Csatolás"
- onClick="@command(vm.selectPage('~./import-invoices-assign.zul'))"/>
- <menuitem iconSclass="z-icon-check-square-o" label="Jóváhagyás"
- onClick="@command(vm.selectPage('~./import-invoices-approve.zul'))"/>
+ <menu iconSclass="z-icon-tasks" label="Számla iktatás">
+ <menupopup>
+ <menuitem iconSclass="z-icon-paperclip" label="Iktatandó számlák"
+ onClick="@command(vm.selectPage('~./import-invoices-assign.zul'))"/>
+ <menuitem iconSclass="z-icon-check-square-o" label="Jóváhagyandó számlák"
+ onClick="@command(vm.selectPage('~./import-invoices-approve.zul'))"/>
+ </menupopup>
+ </menu>
<menuseparator/>
<menuitem iconSclass="z-icon-code-fork" label="Import elindítása"
onClick="@command('onStartImportInvoiceProcess')"/>
import hu.user.lis.db.Partner;
import hu.user.lis.db.repository.PartnerRepository;
import hu.user.lis.service.data.DataGeneratorService;
-import hu.user.lis.service.nav.TaxOfficeDataDeserializer;
+import hu.user.lis.service.nav.TaxOfficeDataConverter;
import org.apache.commons.lang3.RandomUtils;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
private DataGeneratorService dataGeneratorService;
@Autowired
- private TaxOfficeDataDeserializer taxOfficeDataDeserializer;
+ private TaxOfficeDataConverter taxOfficeDataConverter;
public List<String> getNewInvoices() {
return Arrays.asList("Invoice-test-1", "Invoice-test-2", "Invoice-test-3");
public IncomingInvoice getInvoiceFromPath(Path invoiceFile) throws Exception {
String xml = new String(Files.readAllBytes(invoiceFile), StandardCharsets.UTF_8);
- IncomingInvoice result = taxOfficeDataDeserializer.getIncomingInvoice(xml);
- Partner partner = taxOfficeDataDeserializer.getPartner(xml);
+ IncomingInvoice result = taxOfficeDataConverter.getIncomingInvoice(xml);
+ Partner partner = taxOfficeDataConverter.getPartner(xml);
result.setPartner(partner);
return result;
}
<component name="ProjectRunConfigurationManager">
<configuration default="false" name="server-dev" type="Application" factoryName="Application">
+ <option name="ALTERNATIVE_JRE_PATH" value="semeru-1.8" />
+ <option name="ALTERNATIVE_JRE_PATH_ENABLED" value="true" />
<envs>
<env name="spring.profiles.active" value="dev" />
</envs>
https://git.useribm.hu / sly-crm.git / commitdiff