MayaLabs Discussion Area

Laskutamme useita asiakkaita toistuvasti erilaisista tuotteista ja palveluista 1kk, 3kk, 6kk ja 12kk välein. Tähän mennessä näitä on ollut tapana hallinnoida käsin kun toistuvaislaskutoiminto on MLinvoicessa todella kankea käyttää.

Olisiko kellään ideaa kuinka tätä voisi taklata ja olisiko mahdollista luoda joku uusi toiminnallisuus tämän ympärille. Ideaalisti nämä toistuvat rivit loisivat uuden laskun ainoastaan siinä tapauksessa jos asiakkaalle ei ole keskeneräistä laskua jo olemassa. Jos asiakkaalle on lasku keskeneräisenä, siihen lisättäisiin nämä toistuvat rivit.

Toiminnallisuus kaipaa myös jonkin näkymän, jossa näytetään ja jossa voi muokata kaikkia toistuvia laskutuksia.

Jos ratkaisuajatuksia ei ole ja toiminnallisuus ei ole roadmäpissä, teemme varmaan alkuperäisen suunnitelman mukaan ja toteutamme homman jollain skriptillä suoraan tietokantaan.

Moi,

Joo, olisihan tuossa koodissa ihan hirveän paljon siistittävää muutenkin. En ole ollenkaan tyytyväinen siihen, millaista sotkua html siellä kaiken muun seassa on, mutta ei tuossa muutenkaan ole kunnollista rakennetta. Moni asia olisi selkeämpi, kun olisi kunnollinen MVC-rakenne, nimiavaruudet kunnossa, autoloader käytössä jne. Muutos vaatisi vain sen verran paljon tekemistä, ettei ole tapahtunut. Ehkä pitäisi koittaa, hoitaisiko tekoäly siistimisen hienosti. :D

Ja olet ihan oikeassa, että suurin osa config-tiedoston sisällöstä pitäisi olla tietokannassa. Oikeastaan config-tiedostossa ei pitäisi olla paljon muuta kuin tietokantayhteyden asetukset, salausavain ja ehkä merkistö (joka saisi kyllä lähteä pois).

--Ere

Moi,

Toistuvien kohdalla muokattavaa laskua ei vielä ole ennen kuin se käsitellään. Muuten odottaville voisi koittaa tällaista suoraan tietokantaan (omalla vastuulla ja tietysti ensin varmuuskopio kannasta!):

UPDATE mlinvoice_invoice_row SET vat=25.5 WHERE vat=24 AND invoice_id IN (SELECT id FROM mlinvoice_invoice WHERE state_id IN (SELECT id FROM mlinvoice_invoice_state WHERE invoice_open=1));

Jos laskutetaan jälkikäteen ennen 1.9. toimitettuja toimitettuja tuotteita tai palveluita, pitää niihin edelleen soveltaa 24% verokantaa, joten menee käsitöiksi tai vaatii ainakin lisäehtoja, esim. laskurivin päiväyksen tarkistuksen. Jatkossa jos on tuotteita, joiden verokanta muuttuu esim. 10% => 14%, joutuu myös tekemään käsityötä tai kehittelemään fiksumpia kyselyitä.

Myös tuotteet pitää päivittää. Sen voi tehdä vaikka näin:

UPDATE mlinvoice_product SET vat_percent=25.5 WHERE vat_percent=24;

Moi!

Ei pitäisi olla mikään ongelma. Yleisissä asetuksissa ja tuotteissa ne näkyvätkin yhden desimaalin tarkkuudella, ja näytetään laskulla myös desimaalin kanssa, jos on tarpeen.

Morientes, miten muuten mlinvoice pelittää syyskuun alusta alkaen? Luin äsken, että jossain laskutusohjelmissa voi tulla uusi alv 25,5% ongelmaksi.

moikka,

mikä olisi tie alv muutokselle 24 > 25,5 1.9.2024?

saako skriptillä ajetua joka riville odottaville & toistuville laskuille?

terveisin, Kimi

moi,

maventan connector toimii loistavasti :)
finvoicen tallennus sovittuun kansioon niin sieltä lähtee sukkana ulos > asiakkaalle
 
t/Kimi

Harmillista, ettei Postita.fi toimi kunnolla.

Luultavasti esim. Maventa olisi toimiva vaihtoehto, mutta se on dokumentaation perusteella suunniteltu SaaS-ohjelmistoille, joissa yksi taho pyörittää softaa. Maventalla on kyllä myös Windows-softa, jolla voi lähettää laskutusohjelman tekemät Finvoice-laskut, mutta onhan se vähän kömpelö ratkaisu. Pitää vähän kaivella, josko löytyisi hyvä ratkaisu.

Hei,

Postita.fi palvelu tuntuu hiipuvan ja sen kanssa on ollut haasteita. Palvelu käyttää taustajärjestelmänään Bizsearch verkkolaskuosoitteistoa, jota ei pidetä kunnolla yllä ja jossa on runsaasti vääriä tietoja, jotka eivät päivity.

Tämä aiheuttaa ongelmia, sillä laskut merkataan lähetetyiksi, mutta ne on toimitettu väärälle välittäjälle eivätkä ne tästä syystä reitity perille. Homma johtuu hyvin suurella todennäköisyydellä juuri tuosta Bizsearch osoitteistosta, jota ei ylläpidetä ja joka sisältää useita välittäjiä samoille yrityksille. Tällä hetkellä kaikki sähköisen laskutuksen järjestlemät tuntuvat sekä päivittävän tietonsa että käyttävän https://verkkolaskuosoite.fi/ palvelua laskutietojen ja välittäjätietojen hakuun.

Taannoiset muutokset, joissa otettiin välittäjätieto osaksi API-kutsua eivät näyttäisi auttavan ongelmaan.

Ongelmatilanteiden selvitys on haastavaa, sillä Postita.fi palveluun kytketty asiakaspalvelu ei tunnu juuri viesteihin vastailevan.

Sähköisen laskutuksen jatkuvuuden varmistamiseksi tarvitaan mahdollisuus käyttää jotakin vaihtoehtoista palvelua sähköisten laskujen lähettämiseen.

Valitettavasti minulla ei tähän hätään ole ehdottaa hyvää toimijaa, mutta toivon että Erellä tai yhteisöllä olisi ajatuksia tämän suhteen ja saataisin MLinvoice pidettyä relevanttina jatkossakin.

Hei,

Vielä tuli semmoinen mieleen, että jos nuo html asiat pystyisi tuuttaamaan esim Twig templatella ulos niin kehityksessä pystyisi olemaan helposti ulkopuolinen mukana myös semmoinen joka ei osaa niinkään koodata. Nyt html:t on niin pahasti piilotettu että ainakin itsellä kestää selata oikeaa kohtaa kauan... (osaan kumminkin jotenkuten koodata, mutta en juurikaan nyky php:ta... php3 oli tuttu :))

Tarkoitan että kun html:t toisi jollain templatella ulos niin sivun kehittäjän ei tarvitsisi osata lukea php:tä vaan asiat hoituisivat {{muuttujien}} ja {% if muuttuja == muuttuja %} tyyppisesti.

Jos meinaa laittaa sivut templatella niin usein niissä on sitten varjopuolena(?) se että urlien kanssa voi olla erilaisempaa. Ei välttämättä toimi enää hakemistosta, mutta voi olla että toimii (voi olla vähän haaste - en tiedä). Tosin voi myös puntaroida että missä menee raja minkäkin suhteen. Templatessa taas voittaisi sen että siinä voisi helposti käyttää bootstrappia tai tailwindiä yms työkaluja ja eri listoista/taulukoista voisi tehdä komponentteja joita laittaa eri sivuilla ulos tyyliin {{ include "avoimet_laskut.html" data=table_data }}. Nuo esimerkit nyt on django / jinja2 tyyppistä mutta Twig lienee samankaltainen.

Kokeilin siis tuota dockerfileä ja tein sen mallilaskun ja homma toimi. Mitään syvällisempää benchmarkkia en tehny, mutta uskon että toimii. Lighttpd:n konffissa taitaa olla turha se mod_rewrite rivi. Jos tarve niin voin tuosta nginx versionki tehdä. Light tuli vaan kevyistä ekana mieleen :). Tuo palvelin nyt jääkin proxyn taakse jos meinaa julkisesti pyöritellä. Tässä tapauksessa on ihan sama onko se light, nginx vai apache. Riippuu miten paljon haluaa käyttää koneen resursseja tuohon, kaikki tekee saman tehtävän. Apache lienee raskain. Itse pyöritin pitkään nginx + php-fpm:n päällä. Uskon että pyörii vallan mainiosti raspberrypiilläkin. Tosin tietokantaa en ehkä laittaisi raspille jos haluaa luotettavuutta. Mysql palvelun voinee ostaa myös hostattuna ja jos homma pelittää niin mlinvoice:n "moottoria" voi heitellä koneesta toiseen jos tietokanta on hyvin hoidettu.

Jos meinaa tehdä enemmän tuosta "klikkaa ja laita toimimaan" (säätäen vain muutamaa ympäristömuuttujaa) niin vielä enemmän saa varmaan mennä asioita tietokantaan, kuten kaikki sähköpostiasetukset yms... oma taulu kaikille säädöt&settings_table (tuon niminen niin ulkomaalaiset käyttäjät saa tuskailla ääkkösten kanssa :))

Pikaisella silmäyksellä oot tehny ison työn koodin siistimisessä.

-Juho