Ward van der Put

Ja en nee. Dit verblijvensbeding houdt in dat de reserves verblijven bij de VoF, maar de actuele (contante) waarde daarvan moet worden vastgesteld omdat het aandeel daarin van de overleden vennoot moet worden uitgekeerd. Merk op dat het dus geen voortzettingsbeding is: de echtgenoot van de overleden vennoot kan niet zomaar een deel van de taken/rechten voortzetten als nieuwe vennoot. Er moet worden afgerekend.

Wat deed je besluiten om bij een omzet van slechts 50 euro per maand toch 285 euro per maand méér te gaan uitgeven?

Soms werkt dat omgekeerd. Nadat ik mijn fiscalist voor de derde keer op een fout betrapte, kwam de aap uit de mouw: "Ja sorry, ik weet nu eenmaal meer van vennootschapsbelasting dan inkomstenbelasting." Okay, doei dan. >;(

Volgens Marketingfacts bezitten 4 op de 5 Nederlanders een smartphone. Volgens het innovatiemodel van Rogers zitten we daarmee ver in de late majority. Het antwoord op de vraag wie de appgebruiker is, is dan dus: bijna iedereen. Alleen de laggards nog niet en daarvan zijn de demografische karakteristieken redelijk bekend: conservatief, weinig kapitaalkrachtig, geen affiniteit met techniek, enzovoort. Veelal zijn dit bejaarden.

Wát staat er in het vennootschapscontract? Bij een VoF (en een maatschap) leidt het overlijden van een van de vennoten tot ontbinding van de vennootschap tenzij er contractueel een voortzettingsbeding of andere bijzondere regeling is overeengekomen. Zonder zo'n bijzondere regeling houdt de VoF op te bestaan en is de met een erfgenaam voortgezette onderneming een nieuwe VoF; in dat geval moet er dus worden afgerekend vanwege het staken van de oorspronkelijke VoF. Controleer verder of het VoF-contract een verblijvenbeding bevat. Hierbij gaat het aandeel van de overleden vennoot over naar de andere vennoten, maar moeten zij in ruil daarvoor de erfgenamen een vergoeding betalen. Bij deze "uitkoopregeling" hebben de erfgenamen dus wel recht op een bepaald geldbedrag, maar niet op deelname in de VoF als vennoot en evenmin op voortzetting van de VoF.

Die poll loopt nog tot 19 juni. Ziet er gunstig uit: zie plaatje voor de tussenstand.

Als je een beetje leuk kunt opmaken en stylen, dan kun je ook een gave app maken. #Capgemini :P

Hier ligt wel een potentiële bom onder de toekomstige samenwerking. Met ongeveer 560 uur per maand (100 uur per week voor jou en je vrouw plus 40 uur voor de derde vennoot) verwacht je € 6.000 winst per maand. Dat is net iets meer dan het brutominimumloon van € 1.524,60 per maand. Hoe lang kan en wil nummer drie dat volhouden? En wil/kan hij daarvoor wel voor circa € 10.000 een derde van het bedrijf kopen? Je oorspronkelijke idee lijkt me wel wijs: neem hem eerst tijdelijk tot het einde van het jaar in dienst en kijk hoe dat gaat lopen.

Ja hoor: dan kun je op basis van facturen objectief de historische kostprijs vaststellen en dat is uiteraard beter dan met de natte vinger naar de actuele waarde raden. Bij het activeren van domeinnamen en websites heb ik bedenkingen. Je registreert een domeinnaam, afhankelijk van het TLD, meestal voor 1 of 2 jaar. Dat kun je ook gewoon als kosten direct ten laste van de winst brengen. Heb je die kosten gemaakt voor de oprichting van de BV, dan zijn het aanloopkosten. De waarde van de websites bepalen is nog lastiger. Daar is vermoedelijk vooral veel tijd in gaan zitten, maar een website is niet zomaar vanzelf duizenden euro's waard omdat je er honderden uren in hebt gestoken.

Je hebt als starter vaak meer aan kwalitatief onderzoek dan kwantitatief onderzoek: in 5 gesprekken leer je meer dan van 500 enquêteformulieren. Kwantitatief onderzoek van brancheverenigingen, banken, het CBS, universiteiten, enzovoort kun je op kleine schaal vrijwel nooit overtreffen. Hoewel ik er niet zo bewust mee bezig ben, merk ik dat ik dat zelf iteratief doe: je legt je ideeën voor aan anderen, verwerkt hun feedback om je ideeën bij te stellen en legt de ideeën opnieuw voor. Als je open staat voor wensen én vooral niet doof bent voor kritiek en bedenkingen, brengt die herhaalde cyclus je steeds dichter bij je doel en bij je klanten.

Zodra één vennoot substantieel meer of minder hard werkt, kun je daarover inderdaad scheve gezichten krijgen. Dat is echter niet uniek voor een VoF: bij een BV, CV, maatschap of coöperatie heb je dat gedoe over "inzet" en "inbreng" ook. Je kunt het deels ondervangen door een arbeidsvergoeding overeen te komen. Je verdeelt de winst dan eerst op basis van een uurtarief. De rest van de winst verdeel je vervolgens op basis van bijvoorbeeld kapitaalinbreng of "gewoon" iedere vennoot een derde. Bespreek jullie ideeën en wensen eens gemeenschappelijk met een jurist. Hoewel een notariële akte niet nodig is voor het oprichten van een VoF, is een goed notaris vaak wel iemand die goed kan luisteren en wat hij hoort perfect als een goed contract op papier kan zetten. En misschien adviseert hij wel om het niet te doen. Ik zou een samenwerking niet zomaar wegwuiven. Een collega-vennoot zit er namelijk vaak heel anders in dan een werknemer. Laat de onderneming eventueel ook waarderen door een specialist: je bedrijf is zeer waarschijnlijk meer waard dan wat er aan bezittingen op de balans staat — en meer dan je nu denkt.

Daarom zegt 'ie ook dat het voor de bank een Pyrrusoverwinning was. ;) Nou ben ik helemaal Confusius. Als de pyrrusoverwinnaar eigenlijk een looser is, is dan de pyrrusverliezer een dead winner? Ik ga naar bed. Bescheiden Karl Popper herlezen onder een klein nachtlampie.

Mja, lijkt me dat een sterfhuisconstructieadviseur niet te boek wil staan als typisch pyrrusoverwinnaar.

Schepen van deze omvang zijn doorgaans een registergoed en daarmee vergelijkbaar met onroerend goed. De lening van de bank is waarschijnlijk ook een hypotheek. Zo'n registergoed laat zich niet zo makkelijk vervreemden naar een sterfhuisconstructie. Volgens mij had Steven daar ook een bedenking, maar ik ben geen jurist en hij wel.

+1

Kopiëren en plakken met Ctrl+C en Ctrl+V. Linksom of rechtsom is het vooral een kwestie van tijd: voer je zelf de order in of laat je de klant dat doen. Wij hebben gekozen om het zelf te doen om drie redenen: • adressen zijn vrij vaak onjuist of onvolledig (1 op de 20 schat ik); • er worden vaak uitverkochte artikelen verkocht (ook ongeveer 1 op de 20); • als we dan toch alles moeten controleren, kunnen we het evengoed zelf doen. In logistiek zijn vooral uitzonderingen kostbaar. Als je in slechts 5 procent van de gevallen niet 1 maar 2 mensen nodig hebt en die dan nog 2 keer zo lang bezig zijn, tikt dat aardig door in personeelskosten. Fouten in leveringen zijn zo mogelijk nog kostbaarder: die leiden tot meer retouren, tot extra naleveringen en tot ontevreden klanten. (We hebben in 5 jaar gelukkig maar 1 pickfout gehad, maar dat is mede doordat we de kwaliteit bewaken door bovenop de orderverwerking te zitten.)

Met een hiërarchische directorystructuur met de indeling /jaar/maand/dag/, dus bijvoorbeeld alle orders van vandaag zitten in de subdirectory /2016/06/16/. Wij hebben een soort gescheiden document- en datastroom. In stappen: 1. Van webwinkels ontvangen wij per e-mail een PDF met pakbon of factuur voor de koper. Daaruit nemen we de adres- en ordergegevens over in onze backoffice. 2. Deze data gaan meerdere keren per dag als CSV naar de fulfilment, inclusief de PDF's. 3. De CSV-data worden gebruikt voor het orderpicken met EAN-barcodescanner en het printen van de PostNL-adresetiketten via ParcelWare. 4. De PDF-pakbonnen of -facturen worden geprint en vervolgens aan de inpaktafel gebruikt om te controleren of de order compleet is. Pick & pack zijn zo gescheiden. 5. Is alles okay, dan gaat de print van de PDF in de doos. Tape eromheen, adressticker erop en op de rolcontainer. 6. Bij het aanmaken van de zending via ParcelWare gaat de 3S-code terug in ons eigen CSV-bestand. Dat ontvangen we retour en importeren we; daarna ontvangen de webwinkels automatisch per e-mail de 3S-codes en links voor de Track & Trace van PostNL. Alles bij elkaar een paar minuten werk, dus we proberen dat in batches te doen. Niet de hele dag één voor één die orders afhandelen, want dan wordt iedereen daar horendol van.

Afdeling 2.11, 'Aftrekbare giften', van de Wet op de vennootschapsbelasting 1969 noemt andere bedragen. Let verder op lid 2: er mogen "geen op geld waardeerbare aanspraken ontstaan". Dat lijkt mij wel logisch, want dan is het geen gift meer maar een koop of iets dergelijks. Dient die koop een zakelijk belang, dan zijn het aftrekbare bedrijfskosten — en dus geen gift. (Ik heb de indruk dat je de of-keuze mist in het antwoord van Joost: het is een gift óf het zijn bedrijfskosten. Giften zijn slechts onder voorwaarden en beperkt aftrekbaar; reële bedrijfskosten zijn altijd volledig aftrekbaar. Een gift met een zakelijke tegenprestatie is geen gift meer.)

In deze situatie zou ik zo dicht mogelijk bij PrestaShop blijven. Geef de webwinkels een klantaccount in een aparte klantgroep en stel de boel zó in dat ze meerdere verzendadressen kunnen opgeven. Zo zitten hun orders dan in het systeem dat al goed loopt en moeten zij de data inkloppen, niet jij. Het theoretische ideaal is een RESTful API waarmee je orders kunt laten "inschieten" met JSON of XML. Uit ervaring (wij dropshippen ook) weet ik dat dit niet werkt: je moet tientallen verschillende webwinkels met bijna evenveel verschillende webwinkelplatforms aansluiten. Slechts een enkeling is bereid zo'n API te gebruiken en daarvoor in de eigen software te investeren; de meerderheid doet liever alles per e-mail.

Het oprichten van een BV afronden voordat je de kapitaalinbreng helder hebt, is ook kort door de bocht. Maar vooruit. Je zet websites op en doet die binnen een paar maanden van de hand. Dat is inderdaad een soort van handelsvoorraad, voor SiteDeals bijvoorbeeld, en dan zou je dat vlottende activa kunnen noemen. De waarde daarvan is echter praktisch nihil. Je kunt de kapitaalinbreng niet vastprikken op een verwachtingswaarde, maar hooguit op de historische kostprijs. Wat je je boekhouder wel moet uitleggen, want dat is jouw specialisatie, is dat een domeinnaam geen bezit is. Een domeinnaamregistratie is slechts een tijdelijk exclusief gebruiksrecht. Je huurt een domein als het ware en dat is dan volgens het voorzichtigheidsbeginsel en goed koopmansgebruik de huur voor één termijn waard.

Als je niet weet wat vlottende activa eigenlijk zijn, denk ik dat het enige juiste advies is: huur "gewoon" een boekhouder in.

In de WebwinkelCommunity hebben we onlangs verzendtarieven met elkaar vergeleken (dat is een van de voordelen van een besloten ondernemersforum): er is niemand die voor pakketpost via PostNL meer dan € 5 exclusief btw hoeft te betalen, zelfs niet bij bescheiden aantallen.

Appels met peren, vermoedelijk. We kunnen er wat statistiek tegenaan gooien. Als steekproeven (de maanden) sterk afwijken van het gemiddelde van de totale populatie (een jaar), is dat een teken dat je er geen betrouwbare uitspraak over kunt doen. Grote variatie in een getallenreeks geeft een hoge standaarddeviatie. Als de getallen in je voorbeelden niet fictief zijn, vermoed ik dat je sowieso te weinig observaties hebt om überhaupt een statistisch betrouwbare uitspraak te doen. Als een autodealer in mei 3 auto's verkoopt van een bepaald type en in juni 2 auto's, zou ik niet durven voorspellen dat het in juli dan waarschijnlijk gemiddeld 2½ auto's zullen worden. Het kunnen er evengoed 10 zijn. Of 0. Zoals realist terecht opmerkt, zouden dat seizoensinvloeden kunnen zijn: je kunt op basis van de verkoop van zonnebrandcrème in de zomer niet de omloopsnelheid van zonnebrandcrème in de winter bepalen — en in wintersportgebieden is dat misschien zelfs precies andersom. Als je 2 stuks op voorraad hebt en 1 stuk verkoopt, is de omloopsnelheid als percentage of verhoudingsgetal hetzelfde als wanneer je uit een voorraad van 200 stuks 100 stuks verkoopt. Het is alleen een getal van een geheel andere orde van grootte: je moet het dus wegen met aantallen. Meer in het algemeen kun je het beter nog wegen naar totale inkoopkosten voor het beslag dat daarmee op het werkkapitaal wordt gelegd: 10 artikelen van € 1 te veel op voorraad hebben is minder erg dan 3 artikelen van € 50 te veel op voorraad. Maar terug naar de oorspronkelijke vraag: de retailer vroeg naar de omloopsnelheid per halfjaar, dus reken dan de omloopsnelheid voor perioden van zes maanden door, niet die per maand en evenmin die per jaar.

Dan kan ik AMP (Accelerated Mobile Pages) van Google aanbevelen. Afgelopen weken heb ik daarmee geëxperimenteerd en het is onverwacht snel — snel genoeg om niet onder te doen voor native apps. De leercurve van AMP is bovendien lekker vlak: AMP HTML is een subset van HTML5 met wat speciale JavaScript-componenten.

Klinkt meer als feature creep, want dat is in softwareontwikkeling een bekende oorzaak van vertragingen en van software bloat. Magento leent zich daarvoor bij uitstek: niets is onmogelijk, maar door de enorme complexiteit zit je vast aan Magento-specialisten die vaak geen tijd hebben en als ze wel tijd hebben te veel afraffelen. En dan met name wanneer het pakket van wensen en eisen ook nog maandelijks verandert.