najprv sa spytam radsej dopredu ( prosim nic nehladajte za touto otazkou je to len preto ze informacie, šumy a članky sa uz miesaju) @peter_k je teraz za stranu MIRRI alebo SD ?
teraz k projektu a SU
začal by som tým, že keď už dávajú ŠU na pripominekovanie tak by mohla aspoň splnať formálne a technické náležitosti , ktoré sa tu už raz stanovili (napr štandard popisu architektúry ktorý mi v SU chýba úplne)
ako je to s reformným zámerom s projektom EVS ? ak meníme koncept z B2G a G2G aj na B2B a B2C tak by bolo dobré mať výstupy z EVS projektu alebo niečo, lebo takto sme odignorovali všetky náležitosti, a podľa mňa toto už je reforma ak sa to týka aj B2B
zaujímave že architektúra je popísaná vágne ale v nákladoch už máme presný popis HW, ktorý budeme kupovať :D:D:D:D
takisto je zaujímavý popis autentifikácie a autorizácie, raz sa hovorí o autentifikácii cez IAM UPVS → asi teda technické účty pre všetky právnické osoby → už vidím ten CR na NASES . Na inom mieste SU hovorí vydávaní certifikátov ako pre eKasu. By ma zaujímalo či tieto náklady na zmenu UPVS resp. certifikačnej autority FS SR (ktorú mimichodom nakupujú ako službu v závislosti od počtu vydaných certifikátov) sú kalkulované v nákladoch na projekt.
analytický komponent ? - FS SR má už tolko DWHciek a BI nástrojov že toto sa môže kludne vopchat do ktoréhokoľvek
takisto sa hovorí o ďalšej autentifikácii - systémom ako na PFS ( ten ktorý je v prevádzke len z dôvodu že už má X-tú výnimku na to že nieje v súlade s 305/2013 ?
Je zaujímave že sme spojili dva úplne rozdielne biznis prípady s úplne rozdielnymi oddôvodneniami a motiváciou a pravdepodobne aj z rosdielnymi požiadavkami do jedného projektu (B2G a G2G - legislativna povinnost elektronizacie fakturacie vo VO, B2B a B2C - boj proti podvodom DPH)
Neviem prečo ale z tohto projektu mám dojem, že sa takto robí len preto že treba urýchlene čerpať fondy a z pohladu boja proti danovým únikom mi úroveň prípravy pripadá ako v posledných dňoch v médiách dosť pretriasané projekty v utajenom režime takisto na podporu boja proti daňovým únikom :D:D:D
Podla mna to ma logiku a su jasne synergie. Ak uz dokazes posielat fakturu, ktora patri k VO tak to je rovnaka funkcionalita ako posielanie akejkolvek faktury.
A k biznis case :
Boj proti podvodom. Priznam sa ze tiez celkom dobre nechapem ako to pomoze s podvodmi pri DPH, ale dobre chapem ako to pomoze s podvodmi pri dani z prijmu. Ale v zasade chapem ze to poskytuje ovela rychlejsiu informaciu o tom co sa deje a to je pri datovej analyze vyhoda.
Ak bude mat kazdy uctovny program funkciu posielania faktury a zaroven bude mat spolahlivy autentifikacny mechanizmus, tak chyba uz len prijem takejto faktury druhou stranou a mame elekronicky obeh faktury aj v B2B. A to by bola skutocne dobra vec.
Nuz ano su to 2 podobne veci (moizno 3), ale rozne motivacie a rozne podfunkcie, nie je ot podla man ten isty projekt, ale urcite da sa urobit rozumne modularne a vyuzit jeden sposob zasielania/registracie faktury (aj ked nie kazdy chce presne tie iste data, ale zaklad je ten isty). Pri fakturacii voci Gov na zaklade VO, potrebujes komplet fakturu aj s prilohami a dobre je urobit vazbu na VO a fakturacne milniky (posielas Gov fakturu raz, prijatuz faktuuru nezaevidujes ak nebola odoslana a registrovana), Pri registracii faktury kvoli kontrole na daniach, nepotrebujes komplet fakturu, len udaje co vyzaduje zakon a posiela/overuje sa (odoslana a prijata), pri fakturacii B2B -opat BC je iny (tak troska kompilat oboch). Do toho este proichadzaju faktury cez hranicne, v ramci EU, mimo EU, potencialne vo vsetkych 3 kombinaciach. Ano dobre je rozmyslat a mat plan cieloveho riesenia, aby sa zrealizovali
svetky moznosti a nerobili tie iste veci 3x, urcit si priority a postup, ale urcite to vsetko nespojit do jedneho projektu a chciet vyriesit vsetko naraz, to opat nedopadne dobre.
Ano su to rozne biznis case, ale su dostatocne podobne na to aby sa dali riesit spolocne. A ci ich spojit ? To sa vratime k tomu ze dnesny projektovy cyklus je skoro 10 rocny. To co nespojis sa neurobi skor ako za dalsich 10 rokov. V idealnom svete by sa dalo robit inak, ale tu mame velmi jasne externe obmedzenia.
Ale inak mam silnu obavu ze sa neurobi ani prvy krok, casovo je to uz tak napnute ze to nepojde. A ostane to ako napad do dalsieho obdobia.
Next step is to estabilish infra connection, since probably the Einvoice will not run within Govnet.
We have just found out that EN16931 is not publicly available. Insane. I understand EN16931 as kind of integral part of EU directives and Slovak laws, since you have to follow it in order to comply with law. And they do not give it to you available. This is direct opposite how I envision the states, EU,… should work. Look, we are doing open-source software based on EU norm which you have to buy. This is insane. Also whoever will implement invoicing software will have to buy it. I imagine freedom differently than EU and SR apparently.
Would be great if gov institutions could buy Swagger UI as a service, since as of now we have to deploy it ourselves without expertise about the internals of the system. I guess it would be more efficient and cheaper.
We designed new workflow foreign suppliers: Foreign supplier can create an invoice in UBL/D16B on its own or through our tools (form, validation, visualization without login). Will deliver it electronically but outside of our system to the gov institution. That customer institution will be responsible for inserting it to the system. This way we fulfill EU regulations to be able to receive e-invoices as well as our desire to collect and transparently provide all invoices to citizens.
Form has restrictions for code lists, strings, numerical values and possibility to upload attachments.
Visualization parses attachments from xml and recreates zip of attachment files. It sends it to UPVS mailbox as well as visualize it in Einvoice.
Business terms and rules are being translated to Slovak.
Thanks to @jsuchal for helping us with filling out the Infrastructure excel from NASES.
We have got a norm and have to implement it to the form now.
We have got Business rules and Business terms translations, so broken business rules are now reported in Slovak as well.
Migrated to slovensko-sk-api 2.0
MIRRI enabled publishing docker packages, so we have docker registry now. Thank you @Martin_Bezek
UPVS fix version created entities (FO, PO, OVM)
Waiting on NASES for UPVS fix VPN. They wanted us to give them govnet IP addresses, but we are on private cloud. They are thinking what to do.
New nifty streamlined flow: form → download/validation+visualization → submit
fix.einvoice.mfrs.sk registered
UPVS fix certificates and SP metadata waiting on UPVS VPN
validation always before visualization such that we do not produce crappy vizualizations
There is not going to be list of allowed subject list (as we expected), since new info is that some business have to go through the system although they are not gov institutions. As well there are opinions that some G2B invoices should be there. Essentially, just law will set which invoices have to go through the system and which not. Requires more investigation.
We asked what kind of messages should be invoices sent by through UPVS such that we have confirmation of delivery in our system. Waiting for an answer.
Couple of reasons:
For your information, whole project code, documentation,… is in English and each serious project/company does it like that in 21 century. Why?
I wanted to learn myself how other countries tackle this problem. You can imagine, often materials are only in national language and that is how my investigation often ended. It caused problems to me, I do not want to cause problems to others.
Would be great if anybody from any country who solves the same problem can chime in and discuss, since at least whole EU is implementing this.
If I ask for advise from other people, they are often foreigners and if all the documentation in the project is not in English, I have to translate it all then.
Whole this project is about interoperability between EU countries. Having common xml structure but different languages seems like contradictory directions.
Who said that only Slovak people can work on this project in the future? Why can only Slovak companies/people work for government? If we are serious about squeezing the price of IT or any other services, increasing efficiency, we should allow real open market.
What if our solution is such a great piece that other countries can copy it? Would be great if they can reuse what we build since it is open-source.
Split testing and production endpoint for sending invoices.
Move preferred languages to request headers.
Remove usage of multiform http request.
Infer user flow and Invoice type from invoice itself instead of setting as parameter.
Tried to integrate idsk design manual but that seems to be not supporting multilanguage and not supporting some modules we need. Trying to contact MIRRI to resolve these issues.
Translations still not available
Probably going to use CUD
Trying to figure out whether using of UPVS substitutes is ok.
Add possibility to save a partially filled form for a logged user.
Stress tests - target rate 50000/h with various types and sizes, with and without attachments, valid and broken. Test will omit sending them to UPVS Test will demonstrate also UI (paging, filtering)…
Everybody is invited to the public online tech/product discussion with creators of B2G EINVOICE system.
Friday 9.4.2021 from 8:00 to 9:00.
Do you have any questions?
What? Who? How? Why? When? How much?
Do you have suggestions, advice or complaints you want to share?
You know how to do it better? Please let us know and help us!
We prefer these topics:
open API a integration
authentication and authorization
security
tech stack and tech design
transparency and simplicity
But if we have spare time, we are happy to discuss anything and answer any question.
Our goal is to build the best possible system and would like to listen to you already during the creation process.
I was really surprised how many of you were interested and also it is awesome to mention that we had to discuss in English since we had an international audience. It also confirms that it makes sense that all our communication and documentation is in English.
I especially thank to all of you who asked any question or mentioned any suggestion since only the communication between system creators and the public is that drives it to produce better results.
. Na inom mieste SU hovorí vydávaní certifikátov ako pre eKasu. By ma zaujímalo či tieto náklady na zmenu UPVS resp. certifikačnej autority FS SR (ktorú mimichodom nakupujú ako službu v závislosti od počtu vydaných certifikátov) sú kalkulované v nákladoch na projekt.