Fisco applicazioni e come gestire i pagamenti

di il
9 risposte

Fisco applicazioni e come gestire i pagamenti

Ciato a tutti

Vorrei sapare se bisogna avere una un p.iva per pubblicare un applicazione.
Diciamo che sto facendo una ricerca dei requisiti in todo il processo dallo sviluppo alla messa in vendita
Per quanto ne so le piccole imprese in ambito informatico, hanno regimi fiscali ridotti.
E sempre per quanto ne so, non c'è nessun bisogno di regolarizzarsi con il fisco fino ad un guadagno massimo annuale di 5000 euro
Io non so se riesco a raccimulare 10euro.
Il mio vero successo personale al momento è la riuscita, sviluppo e pubblicazione dell'app.

Dato che ci saranno pagamenti da parte del cliente,vorrei capire come gestire le transazioni. ma anche di banner pubblicitari(se necessario e sempre se vogliono mettere il loro banner nella mia app). Ma questi penso che pagano con accredito Iban, cmq tutta un altra storia perchè saranno accordi credo.

Leggendo un piccolo manuale di mysql...
dicono che mysql è utilizzato anche per le transazioni, ed oltretutto ha costi ridotti, anzi dice abbastanza ridotti, rispetto agli altri database.

Un telefono Android usa come database SQLite, che è un NoSQL
Un webServer dovrebbe essere capace di utilizzare sia NoSQL che RDBMS

Essendoci transazioni, la cosa migliore è un database relazionale.
Mentre per le tabelle che vorrei creare che fanno parte del gioco dell'applicazione, non dei dati realtivi a pagamenti login eccecc...
La scelta è un NoSQL, perchè ci sono ben poche relazioni, sono quasi tutte tabelle indipendenti.

Fatta questa premessa ho pensato(non conoscendo la tecnologia)
che lato client avrò un database SQLite
e lato server 2 database
MySQL per login transazioni ed altri dati utente
SQLlite o MongoDb non so cosa gira lato Server.

E questi come comunicano tra loro?
se mi sono fatto l'edea giusta attraverso xml
grazie per la pazienza...

9 Risposte

  • Re: Fisco applicazioni e come gestire i pagamenti

    Alexxandro ha scritto:


    Ciato a tutti

    Vorrei sapare se bisogna avere una un p.iva per pubblicare un applicazione.
    Se la vuoi vendere sì.
    Se vuoi fornire invece una consulenza, cioè una prestazione occasionale, no
    Per quanto ne so le piccole imprese in ambito informatico, hanno regimi fiscali ridotti.
    Ce l'hanno tutte, si chiama regime dei minimi.
    A memoria prevede una tassazione del 5% per i primi 5 anni, fino a un limite annuo di 30.000 euro (prendi come informazioni generiche, non ne ho mai usufruito)
    E sempre per quanto ne so, non c'è nessun bisogno di regolarizzarsi con il fisco fino ad un guadagno massimo annuale di 5000 euro
    C'è... c'è... Il limite di 5000 riguardano le prestazioni NON continuative, cioè (ad esempio) se fai la stagione e lavori per 2 settimane come bagnino.
    Oltre certi limiti (di tempo) e di importo si "esonda"
    Dato che ci saranno pagamenti da parte del cliente,vorrei capire come gestire le transazioni. ma anche di banner pubblicitari(se necessario e sempre se vogliono mettere il loro banner nella mia app). Ma questi penso che pagano con accredito Iban, cmq tutta un altra storia perchè saranno accordi credo.
    Con una fattura (se hai la partita IVA), o con una ricevuta di prestazione occasionale (se puoi farla, è roba più da commercialista che informatico)
    Leggendo un piccolo manuale di mysql...
    dicono che mysql è utilizzato anche per le transazioni, ed oltretutto ha costi ridotti, anzi dice abbastanza ridotti, rispetto agli altri database.
    Per niente, costa, e anche parecchio.
    A MENO CHE non lo utilizzi per un'applicazione web (cioè non lo distribuisci presso i clienti).
    In ogni caso ti suggerisco di eliminare il prima possibile mysql a favore di mariadb (anche sotto questo profilo).
    Qui se vuoi ti faccio lo spiegone sulle licenze Oracle\MySQL
    Un telefono Android usa come database SQLite, che è un NoSQL
    No, per niente.
    E' invece, grosso modo, proprio basato su SQL (nelle interrogazioni)
    Un webServer dovrebbe essere capace di utilizzare sia NoSQL che RDBMS
    Non c'entra nulla
    Essendoci transazioni, la cosa migliore è un database relazionale.
    Non c'entra nulla neppure qui
    Mentre per le tabelle che vorrei creare che fanno parte del gioco dell'applicazione, non dei dati realtivi a pagamenti login eccecc...
    La scelta è un NoSQL, perchè ci sono ben poche relazioni, sono quasi tutte tabelle indipendenti.
    Mezzo suicidio
    Fatta questa premessa ho pensato(non conoscendo la tecnologia)
    che lato client avrò un database SQLite
    e lato server 2 database
    MySQL per login transazioni ed altri dati utente
    SQLlite o MongoDb non so cosa gira lato Server.

    E questi come comunicano tra loro?
    se mi sono fatto l'edea giusta attraverso xml
    grazie per la pazienza...
    AAARRRGHHHHHHHHHHHHHHHHHHH...


    1) No SQL puoi vederlo come un no-no.
    Servono per certi tipi di problemi, che NON sono i tuoi, e per certe applicazioni, che NON sono le tue.
    Oggi fa molto "fico" dire "nosqlnosqlnosql", come se avessero qualche magico potere.
    In realtà sono MENO "comodi", MENO "potenti" (e di gran lunga) dei normalissimi RDBMS basati su SQL

    2) ho idea che non ti sia ben chiaro cosa sia una transazione

    3) puoi fare tutto tranquillamente con mysql (mariadb)

    4) su android invece ti serve qualcosa si più "bovino", o sqllite (secondo te, perchè si chiama SQL-lite e non NoSQL-lite ? ), o un qualsiasi formato testuale che ti inventi (se davvero devi tenere pochissimi dati)
  • Re: Fisco applicazioni e come gestire i pagamenti

    Ok...bene
    Sono in alto mare!
    Non so granchè di queste tecnologie, non so bene cosa fanno e quali devo usare

    Ho capito male il termine NoSQL
    Per me NoSQL significa che non ci sono relazioni tra i database
    MySQL invece è un RDBMS
    ossia le tabella hanno relazioni tra loro

    Quindi se voglio effettuare delle modifiche strutturali in un database relazionale, questo potrebbe risultare difficile, per via che i db relazionali, hanno una struttura intera.

    Mentre i db non relazionali, non avendo una struttura interna, lasciano al programmatore diciamo più libertà in futuro, per eventuali grosse modifiche.

    Ho letto questo da qualche parte.

    MariaDB mi è stato consigliato tempo fa.

    Quando dici che posso fare tutto tranquillamente con MariaDB, che intendi?
    Non pago la licenza?
    E lato client che database devo utilizzare?
    SQLite o MariaDB?
    Qualche info sulla licenza MariaDB se puoi dirmela è molto gradita
    grazie a tutti!
  • Re: Fisco applicazioni e come gestire i pagamenti

    Alexxandro ha scritto:


    Ok...bene
    Sono in alto mare!...
    Per me NoSQL significa che non ci sono relazioni tra i database
    MySQL invece è un RDBMS
    ossia le tabella hanno relazioni tra loro
    Sei in mezzo all'oceano.
    SQL significa, alla grossa, che è interrogabile attraverso il linguaggio SQL (o cugini e derivati vari).
    Essenzialmente esiste il concetto di "tabella" con tante "righe".
    Le interrogazioni sono del genere "dammi l'elenco di tutte le righe raggruppate così e cosà ordinate così e cosà"

    NoSQL significa... senza SQL (e ce ne sono 10000 tipi).
    Essenzialmente sono associazioni chiave-valore.
    Le interrogazioni sono del tipo "dammi tutti i valori associate a una certa chiave".
    Cioè un sottoinsieme minimo di SQL.
    L'utilizzo è nei casi in cui servono prestazioni mostruosamente elevate (parliamo di centinaia di migliaia di utenti contemporanei), o dove non c'è un database singolo, bensì una rete distribuita.

    Per dare un'idea una banale applicazione di booking, o di ordini online, o cose del genere, sono praticamente impossibili con nosql, banali con sql "liscio".

    Quando dici che posso fare tutto tranquillamente con MariaDB, che intendi?
    Che fa tutto quello che puoi immaginare, e molto di più
    Non pago la licenza?
    E lato client che database devo utilizzare?
    SQLite o MariaDB?
    Qualche info sulla licenza MariaDB se puoi dirmela è molto gradita
    grazie a tutti!
    la licenza mysql, non mariadb.
    mysql è stato comprato da oracle.

    lato-client, se parliamo di android, la scelta è assai limitata, e finirai con sqllite (come whatsapp e cuginetti vari)
  • Re: Fisco applicazioni e come gestire i pagamenti

    Ok mi sono fatto una full immersion in SQL in particolare MariaDB.
    Anche se ho usato un manule pocket di MySQL per avere un filo logico...

    Che vuoi dire con la licenza mysql, non mariaDB?
    Che non pago per mariaDB?

    Ho notato anche dei riferimenti con php..
    Ma un blog o un forum come questo qui ad esempio viene realizzato con php.
    e php è capace di creare database.....
  • Re: Fisco applicazioni e come gestire i pagamenti

    Alexxandro ha scritto:


    Ok mi sono fatto una full immersion in SQL in particolare MariaDB.
    Anche se ho usato un manule pocket di MySQL per avere un filo logico...

    Che vuoi dire con la licenza mysql, non mariaDB?
    Che non pago per mariaDB?

    Ho notato anche dei riferimenti con php..
    Ma un blog o un forum come questo qui ad esempio viene realizzato con php.
    e php è capace di creare database.....
    WOW sei proprio a zero, e vorresti fare un'applicazione da vendere.
    Vabbè ... fai bene.

    Sinteticamente
    1) il 99% dei manualetti per mysql vanno bene per mariadb (anzi il 100% al tuo livello)
    2) mysql prevede, qualora venduto con un'applicazione non web, cioè installato materialmente sul computer del cliente, il PAGAMENTO a Oracle di un tot, che è normalmente fisso + percentuale del costo della licenza che fai pagare al cliente. Altrimenti devi rilasciare il codice come opensource della tua applicazione.
    3) PHP non è in grado di creare alcunchè (in questo ambito).
    Attraverso una libreria di interfaccia più o meno evoluta manda comandi al server SQL, e ne recepisce i risultati. Non ha alcuna capacità di gestione tabelle o archivi.
    Si utilizzano librerie per gestire, ad esempio, SQLLite, oppure collegarsi a mysql, SQL-server, postgres o quello che vuoi
  • Re: Fisco applicazioni e come gestire i pagamenti

    mysql prevede, qualora venduto con un'applicazione non web, cioè installato materialmente sul computer del cliente, il PAGAMENTO a Oracle di un tot, che è normalmente fisso + percentuale del costo della licenza che fai pagare al cliente. Altrimenti devi rilasciare il codice come opensource della tua applicazione.
    Vuoi dire che se lascio il codice opensource non pago nulla di tutto questo?
    E con MariaDB invece?

    Si sono a zero su sta roba...
    Sono cose che mi sono lasciato dietro, ho voluto prima imparare i linguaggi di programmaizone, prima di dedicarmi a tutto il resto, proprio per avere più facilità di comprensione con tutti i linguaggi e le tecnologie che avrei incontrato dopo.
    E per questo ringrazio il C

    Spero in qualche modo di riuscire a capirci di più nel minor tempo possibile.
  • Re: Fisco applicazioni e come gestire i pagamenti

    Alexxandro ha scritto:


    Vuoi dire che se lascio il codice opensource non pago nulla di tutto questo?
    E con MariaDB invece?
    Prima di porti queste domande esistenziali, poniti quella a monte.

    Vuoi sviluppare applicazioni locali, cioè per capirci EXE (in realtà anche Java), le quali utilizzano un database installato localmente sul PC?
  • Re: Fisco applicazioni e come gestire i pagamenti

    Alexxandro ha scritto:


    Vuoi dire che se lascio il codice opensource non pago nulla di tutto questo?
    E con MariaDB invece?
    Prima di porti queste domande esistenziali, poniti quella a monte.

    Vuoi sviluppare applicazioni locali, cioè per capirci EXE (in realtà anche Java), le quali utilizzano un database installato localmente sul PC?
  • Re: Fisco applicazioni e come gestire i pagamenti

    La mia idea in testa è questa qui.
    Voglio descriverla come un agnostico.

    Realizzare un applicazione mobile Android.
    L'applicazione lato client avrà la sua interfaccia grafica che permette di consultare un database su un server.
    Il server avrà ovviamente un database che io devo aggiornare all'occorrenza.
    L'utente quindi il client, quando vuole pigia il bottone sul suo smarphone per aggiornare i suoi dati, prelevandoli dal server.
    Questi dati a loro volta vengono visualizzati sullo smartphone con la sua bella interfaccia grafica.

    E' presente oltre a quanto detto,un sito, dove l'utente potra scrivere,leggere,modificare post e tutto quello di cui ha bisogno.

    Sia l'applicazione che il sito web fanno parte della stesso... boh insieme?
    Voglio che esista sia il sito, diciamo tipo Facebook(vedo quello che offre all'utente come servizio,metti foto,scrivi un post e cose del genere).
    Voglio che esista anche l'applicazione mobile, da cui posso anche scrivere post,mettere foto ecc ed ovviamente consultare il database, che contiene i famosi dati che io dovrò aggiornare all'occorrenza.

    Ovviamente l'utente da pc potra accedere al sito dal browser.
    Da mobile, sfrutta l'applicazione cioè l'APK, non utilizza il browser.

    Per meglio valutare il livello di pazzia o suicidio:
    Voglio riuscirci entro la fine del 2018..

    Java, Android, SQL non mi sono estranei, anche il c++.
    Nell eventualità potrei averne bisogno per le mie app, perchè lo ritengo molto più semplice e immediato per fare calcoli, mi sembra più appropriato.
    Java è un pò troppo articolato alcune volte per fare la stessa cosa che in c faresti in un attimo.

    Per tutte il resto so non so, conosco o non conosco.
Devi accedere o registrarti per scrivere nel forum
9 risposte