Pankkilomakkeeton lasku?

[luvirini]

Onkos joku puukottanut noita tulostus/sähköposti lomakkeita siten että olisi versio jossa koko pankkilomaketta ei tulosteta.  

Yritysten välisessä laskutuksessa kun se on tarpeeton  ja jättäisi tilaa useammalle laskuriville.

Jos on, ottaisin mielelläni vastaan kopion sellaisesta.

[Ere Maijala]

Tervehdys,

tuollaisen mahdollisuuden voisi lisätä seuraavaan versioon, mutta toivoisin vähän näkemyksiä siitä, miten pankkiyhteystietojen ym. pitäisi tässä tapauksessa näkyä laskulla? Voisit myös kokeilla Finvoice Styled -tulostusmallia (se täytyy käydä ottamassa käyttöön Asetukset -> Tulostusmallit -kohdasta) ja katsoa, miten pitkälle se vastaa toiveita.

--Ere

[ilmis]

Hei,

Aktivoin finvoice styled -tulostusmallin, mutta finvoice styled napista aukeaa vain tyhjä ikkuna. Sama tapahtuu myös finvoice napista.

//Mika

[Ere Maijala]

Mitähän PHP:n virheloki kertoo? Veikkaisin, että saattaisi esim. XSLTProcessor puuttua. Finvoice-tuki edellyttää siis DOM/XML- ja XSL-moduuleja.

--Ere

[ilmis]

Hei,

Jahas, oli paketoinnissa unohtunut tarkistaa oliko uusia tiedostoja, eli .xsl ja .xsd tiedostot eivät paketoituneet.

//Mika

[Ere Maijala]

No juu, en sitten muistanut lisätä niitä spec-tiedostoon...

--Ere

[luvirini]

Oma "ideani" siitä miten sen olisi tehnyt on että se pankkilomake osa kokonaan pois ja lisätään pankki,BIC ja IBAN tiedot sinne footeriin "jossa se usein sijaitsee" muissa laskuissa.

Toki tuo oikea yläkulmakin joka on tuossa finvoice styled laskussa toimii ja voi olla selkeampi vastaanottajalle kun kerran eräpäivä jne. on siellä.

Ulkonäöllisesti pidän tuosta normaalista laskupohjasta joten mieluummin se tyyli ja vain pois se "tarpeeton" pankkilomake ja lisää se pankki,BIC ja IBAN tieto

[Piros]

Hi,
I have some problem with the finvoice printing schema as well. When I try to pass international reference numbers starting with RF and x numbers it gives me an error:
"

Code Select Expand

Result XML validation failed:

Error 1839(2) at 128:0: Element 'EpiRemittanceInfoIdentifier': [facet 'pattern'] The value 'NaN' is not accepted by the pattern '([0-9]{2,20})|(RF[0-9][0-9][0-9A-Za-z ]{1,21})'.

Error 1824(2) at 128:0: Element 'EpiRemittanceInfoIdentifier': 'NaN' is not a valid value of the local atomic type."

So the problem is with this row:

Code Select Expand

EpiRemittanceInfoIdentifier IdentificationSchemeName="SPY">NaN

With only numbers it works fine.
I read that if the international reference number is used than the IdentificationSchemeName has to be "ISO". But how do I change that? I know php but no clue about xsd or xsl :).

Thanks for your help,

Piros

[Ere Maijala]

luvirinille: juu, tokihan tuo on järkevää tehdä pdf-tulostukseen, että pystyy sähköpostillakin lähettämään jne. Kaipa sen voisi tehdä niinkin, että tiedot ovat sekä oikeassa yläkulmassa että footerissa, niin ainakin pitäisi löytyä.

--Ere

[Ere Maijala]

To piros21: The pattern should actually allow the RF codes with SPY schema too (although it might be more correct to use ISO, I'll have to verify), but somewhere something treats the reference as a number and does something resulting in NaN (= Not a Number). I'll need to find and fix it, but it's quite possible that there are multiple locations where the RF scheme is not taken into account as it used to not exist. If you want to do something on the PHP side, you may want to check if $xml contains the correct reference number before it's fed to the XSLTProcessor in invoice_printer_xslt.php. I'll put that to the TODO list anyway, but it might take a while.

--Ere

[Ere Maijala]

piros21: Please try the files at https://sourceforge.net/projects/vllasku/files/beta/. They should allow RF references to display in the invoice form and finvoice.

--Ere

[Ere Maijala]

piros21, if you already downloaded the files, please download invoice_printer_base.php anew. It will now chunk the RF reference properly and allows it to be printed to the PDF too.

[Ere Maijala]

SVN:ssä (suora linkki aina uusimpaan kehitysversioon: http://vllasku.svn.sourceforge.net/viewvc/vllasku/trunk/?view=tar) on nyt perustoteutus lomakkeettomalle laskulle. Ei vielä pahemmin testattu, mutta saa toki kokeilla.

--Ere

[Piros]

Thanks Ere for the fast help!!
It works fine now.

Piros