wimj

Ik denk toch echt dat je een deskundige dit contract zult moeten laten opstellen. Voor wat betreft het tijdpad: inderdaad staan daar nu een aantal zaken van in het contract Maar niet alle. Stel dat je een bug vindt, dan wil je ook dat deze binnen een zekere periode zijn opgelost. Voor wat betreft de twee maanden: wat is de start van het project? Als het contract getekend wordt? Als jij dan eerst nog een nauwkeurige specificatie moet maken, en daardoor de eerste 3 weken opslokt krijg je een heel andere situatie als die waarin je duidelijke specificaties heb gemaakt (en die op maakbaarheid hebt laten beoordelen) die op de start van het project klaar liggen. Daarnaast zijn er nog een redelijk aantal opmerkingen gegeven door diverse mensen, die niet overgenomen zijn in je concept contract. Dat mag je natuurlijk doen, dus ik zal niet in herhaling vallen. Maar het geeft me geen positief gevoel over dit contract. Laat ik dan nog maar eens een puntje noemen. In een software traject krijg je *altijd* te maken met wijzigingen. Zaken die je vergeten bent (je hebt een mooi adres scherm gemaakt maar je bent vergeten dat je internationale ambities hebt, dus het land moet ook kunnen worden opgegeven), of gewoon zaken die achteraf niet handig zijn (simpel voorbeeld: je kleurstellingen zijn onleesbaar). Daarnaast kunnen er onduidelijkheden zitten in de specs, waardoor de ontwikkelaar vragen gaan stellen. Hoe ga je hier mee om? Wellicht zie ik allemaal spoken: mijn ervaring met dit soort contracten ligt veel meer op de 100K plus projecten; maar het zijn wel allemaal zaken waarmee je te maken kan krijgen. Heb je trouwens wel eens gesproken met de ontwikkelaar over de contractvorm? Wellicht heeft iemand hier een voorbeeld contract?

Ohra gemakkelijker met buitenlanders? Mijn ervaring is anders. Toen ik trouwde met een buitenlandse partner die legaal (En dus een BSN), maar wel met een tijdelijke verblijfsvergunnung in Nederland was, weigerde OHRA van mijn rekening een en/of rekening te maken. En ze gaven aan dat dit geen wettelijke regel was, maar beleid van de OHRA. Als dank voor dit duidelijke antwoord heb ik de rekening opgezegd :).

Als ik het contract wat je nu in gedachten hebt doorlees vallen me een aantal zaken op. 1) Alle risico's liggen bij de ontwikkelaar. Heel simpel gezegd: jij hebt een naar ik aanneem een briljant idee. Vervolgens mag iemand daar het echte werk voor gaan doen, en zijn verdiensten zijn sterk gemaximeerd. En jij zit lekker achterover en casht. Mocht het misgaan dan wacht je op het volgende idee, en de ontwikkelaar heeft X uren voor niets gewerkt. 2) Juridisch rammelt het aan alle kanten. Wat gebeurt er bijvoorbeeld met de rechten als jij besluit de applicatie ontwikkeling te stoppen omdat er bugs in zitten? Wie is dan eigenaar van de applicatie die wellicht al voor 80% af is? Krijgt de ontwikkelaar dan iets vergoed? Een bug in de applicatie kan geen reden zijn om het project direct te stoppen (en niets te betalen): de ontwikkelaar moet wel een kans krijgen om een en ander te herstellen. 3) Is de ontwikkelaar verplicht om de updates uit te voeren, ook al wordt hij er voor betaald? En als hij dat besluit niet te doen, hoe staat het dan met de betaling van de uitgebreide versie. De ontwikkelaar vindt het vast lullig als hij geen tijd meer heeft, en iemand anders twee kleine aanpassingen maakt en de oorspronkelijke ontwikkelaar kniets meer krijgt. Ik sluit me aan bij de andere spreker: neem een jurist in de hand, of probeer op een andere manier een voorbeeld contract te krijgen. Zaken die minimaal in zo'n contract staan zijn: 1) Omschrijving van de applicatie. 2) Tijdpad. 3) Acceptatiecritria. Hierin leg je bijvoorbeeld vast dat na oplevering jij twee weken de tijd hebt om te testen. Hierin wordt ook vastgelegd wat een bug is, en met name dat jij een bug reproduceerbaar moet documenteren. 4) Rechten en plichten van beide partijen. 5) Ontbinding

40K is veel geld. Of het teveel is kan ik niet beoordelen: dat hangt af van de exacte specificaties die je stelt. Wel kan ik zeggen dat er diverse gratis paketten op de markt zijn. Om er 1 te noemen: http://www.prestashop.com/. Hiermee kan je redelijk snel een eenvoudige shop in elkaar draaien. Om het uiterlijk aan te passen kan zelf aan slag gaan, of iemand inhuren die zoiets redelijk snel doen kan. Daarnaast zijn er ook zogenaamde themes te koop voor prijzen ver beneden de 500 Euro. Ik mag geen reclame maken voor anderen maar ik ken hostingbedrijven waarbij prestashop in 5 minuten op je website staat voor een prijs van minder dan 50 Euro per jaar. Op deze manier kun je eenvoudig en goedkoop aan de slag. Ik heb geen idee of jouw webshop geschikt is voor zoiets. Gevoelsmatig zeg ik dat als je zaken verkoopt die minder uniek of redelijk goedkoop zijn (audio/computer kabels; drop; allelei zaken bedrukt met eigen foto) je prima uit de voeten kan met zo'n gratis pakket voorzien van een eigen "Theme". Mocht je dure design spullen verkopen dan wordt alles anders.

Met alle respect, maar dit doet geen verstandige ontwikkelaar. Dit zou betekenen dat hij tot in lengte van dagen kan worden aangesproken op zijn werk, nog afgezien van het feit dat de discussie of iets een bug is of juist niet tot ellelange discussies kan leiden. In principe is een bug een afwijking van de specificaties. Als je die al 100% eenduidig weet op stellen (en dat lukt vaak al niet; en dan begint de discussie als hij een eenvoudige variant kiest en jij de complexe variant in gedachten had) heb je als ontwikkelaar ook te maken met afhankelijkheden. Als er een bug in iPhone OS zit, en hij daardoor een tijdrovende work around moet bedenken, is dat dan zijn risico of jouw risico?

Wat het minimale bedrag is om een Stamrecht BV aantrekkelijk te maken hangt sterk af van aan wie je het vraagt. Maar ik denk dat iedereen het met me eens is dat 11.500 te weinig is. Je bent veel te veel geld kwijt aan oprichtingskosten. Niet doen dus.

Ik kan niet precies beoordelen welke informatie je nodig hebt, maar weet je zeker dat je in de handleiding hebt gekeken en niet in de produktspecificaties (Die inderdaad veel te vaag zijn)? In de handleiding (400 pagina's in diverse talen) staat uitgelegd hoe je het ding moet programmeren en hoe je als "kassa bedienaar" allerlei zaken moet uitvoeren. Daar moeten je vragen toch in beantwoord worden? Hierbij voor alle duidelijkheid de link naar de handleiding. http://www.sharp.nl/cps/rde/xbcr/documents/documents/om/35_ecr/XEA113_OM_GB-DE-FR-ES-NL.pdf

In de genoemde link kun je de handleiding vinden. Wellicht kun je (in ieder geval ten dele) daar de antwoorden in vinden.

Dat komt omdat je rente wilt hebben. Als ik vandaag een bank opricht die het geld alleen maar bewaart in een grote kluis (en daarvoor dus kosten in rekening moet brengen) verwacht ik weinig klanten. Zodra ik iets ga doen met het geld loop je risico.

Bedenk ook dat je in geval van rampspoed je geldt enige maanden kwijt bent. Mocht het problemen opleveren als 1 ton voor een paar maanden kwijt bent spreidt dan nog meer :). Verder is het zo dat banken met verschillende namen onder dezelfde DNB vergunning kunnen vallen (na een fusie oid; of gewoon twee verschillende namen), en dus in totaal voor 1 ton gedekt worden. Voor zover ik me herinner geldt dit bijvoorbeeld voor Delta LLoyd en Ohra

Persoonlijk denk ik dat dat acceptabel is. Het is trouwens niet altijd even eenvoudig om het juiste saldo aan een bepaald jaar toe te wijzen. Een rekening met sterk wisselend saldo met een zeer variable rente (bv Euribor gekoppelde) die rente bijschrijft op 1 juli vereist lekker wat rekenwerk (of een opgave van de bank) om de ontvangen rente over twee jaren te verdelen.

Ja, inderdaad. Met dank allemaal

Je kan jouw methode toepassen, alleen niet op de manier die je noemt. Het netto bedrag is namelijk het bedrag dat op je rekening wordt gestort. Dit moet precies kloppen en kan je dus niet berekenen uit andere bedragen, Dus beter is het bruto bedrag bepalen door netto en belasting bij elkaar op te tellen.

Mee eens dat het fiscaal totaal irrelevant is voor mijn boekhouding. Ik vind het alleen een beetje merkwaardig dat ik 97.51 aan dividend heb ontvangen. Maar goed, daar zal ik dan aan moeten wennen want ik weet nu al dat dit in juni nog een paar keer zal gebeuren :)

Bij navraag beginnen er toch wat twijfels te komen, laat staan een refereerbare bron. Voorlopig ga ik er dus maar van uit dat je rente die je op 1 jan ontvangt netjes bij het voorgaande jaar moet opgeven.

Ik had niet goed gekeken op de vooraankondiging. Op de echte rapportage is er geen cent zoek: de totala hoeveelheid dividend hebben ze daar met een cent opgehoord. 97.51 dus. Vreemd, maar in ieder geval kloppen de totalen weer.

Ik heb dit van iemand die de adminstratie bijhoudt van een bedrijf, en hierover discussies heeft gehad met accountant en/of belastingdienst. Hij zou het even nagaan hoe het precies zat.

Ik sprak vandaag iemand die beweerde dat deze regel twee jaar geleden is afgeschaft. Weet iemand of dit inderdad zo is?

Sorry voor het openen van een oud topic, maar hoever ga je in deze? Als ik eind mei dividend ontvang, ga ik dan ook 7/12 deel hiervan op het vorige jaar boeken? Of als ik obligaties heb die ergens midden in het jaar hun jaarlijkse rente geven?

Alhoewel ik weet dat dit forum niet bedoeld is voor Stamrecht BV vragen hoop ik dat deze vraag algemeen genoeg is om hier terecht te kunnen. Zo niet, dan excuses. Mijn BV belegt in o.a. aandelen en ontvangt nu dividend. Daarvan wordt 15% dividend belasting als voorheffing ingehouden. Probleem is dat er door afrondingen problemen ontstaan. Concreet: Bruto Dividend: 97.50 Dividend belasting : 14.625 wordt 14.63 Netto: 82.875 wordt dus 82.88 (Althans dit zijn de getallen zoals ze staan op de overzichten "geplande dividenden"). Maar dat telt op tot 97.51, en niet tot 97.50 Hoe boek je zoiets? Maak je een apart GB rekening aan om die centen te boeken? Of is er een andere list.