Ward van der Put

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.

Je maakt geen denkfout. Zonder omloop geen omloopsnelheid, want als er niets op voorraad is, wordt er niets verkocht. Als er niets gebeurt, kun je niets meten, dus je kunt die maanden met dubbele 0'en als uitbijters negeren. Maar je kijkt daarmee slechts naar de helft van het probleem: wanneer overtreft het aanbod (voorraad) de vraag (orders). Je mist het omgekeerde geval, dat even belangrijk is voor het optimaliseren van voorraadniveaus: wanneer overtreft de vraag het aanbod. Hoe vaak moet je "nee" verkopen dus en hoe vaak laat je daardoor omzet liggen.

Deze (forum)post is ook verkeerd bezorgd. ;D

Alleen als er nog wat weg te strepen en af te lossen is. Je vriend loopt een verhoogd risico: als het fout gaat, is hij zijn eigen inbreng kwijt (jij niet, want je brengt niets in) en draait hij misschien op voor het aflossen van de volledige lening omdat hij hoofdelijk aansprakelijk is (en jij dan misschien niet, want van een kale kip kun je niets plukken). Dat jouw ouders de lening verstrekken, doet in dat plaatje niet ter zake.

Uit: Higher Level: "Ik wil multimiljonair worden, tips?"

(3) Splits in de admin(istratie) van de software handmatig dit type pakket weer uit in de samenstellende producten. (4) Zoek een plug-in of extension waarmee je de software geschikt kunt maken voor productbundels: combinaties van andere losse artikelen. (5) Factureer deze bestellingen niet vanuit de webwinkel maar apart vanuit Excel of iets dergelijks. (6) Zet er 21% btw op als het echt niet anders kan.

Die tweetrapsraket klinkt als een lastig te verkopen kip-en-eiprobleem: je wilt eerst 200 tot 300 exemplaren met crowdfunding verkopen om daarmee vervolgens investeerders te binden-en-boeien om voor 1.000 tot 5.000 euro in te stappen. Als je echter bijvoorbeeld 500 exemplaren voor 50 euro verkoopt, dan heb je ook 25.000 euro en zit je niet meer vast aan investeerders en geldschieters. Wat heb je ingecalculeerd aan marketing- en reclamekosten? Je investeert meer dan driekwart in voorraad en houdt nog maar een paar duizend euro over voor de rest (en jezelf). Wat doe je met de marge voor groot- en detailhandel? Die verwachten bij een spel namelijk niet alleen dat jij er bij de lancering veel reclame voor maakt, maar zien ook graag een gezonde marge. Als het break-evenpunt voor eigen, directe verkoop bij 1.900 exemplaren en het "optimum" bij 3.000 exemplaren ligt, dan vraag ik me toch af wat je met marketing- en reclamekosten en de handelsmarge denkt te gaan doen. Misschien moet je niet te veel focussen op een investeerdersbrochure, maar een ondernemingsplan schrijven.

Die weging lijkt op het systeem van Stack Exchange en dochters zoals Stack Overflow, zoals ik hier eerder al eens opmerkte, maar dat past niet bij Higherlevel. De vraagsteller stelt een vraag over een onderwerp waarvan hij of zij weinig weet en is daarom — afgezien van het elegante bedankje "dit heeft mij het meest geholpen" — als leek doorgaans de laatste die een antwoord op juistheid en volledigheid kan beoordelen. Verder past het, zoals ook toen al is opgemerkt, niet bij een discussie: de dimensie tijd gaat verloren. Je mist de vraag-antwoord-wedervraag-repliek-bedenking-aanvulling enzovoorts als je antwoorden met likes een "hogere" positie gaat geven. Als ze niet te veel off topic worden gebruikt, is het aantal reuzen bij een antwoord vaak ook al een duidelijk signaal.

Winst uit onderneming en resultaat uit overige werkzaamheden vallen beide in box 1. Toevallig was hier gisteren ook al iemand anders in de weer met aan- en verkoop van Paysafecards... Met dit type handel ben je, net zoals met de handel in aandelen of vreemde valuta, niet automatisch ondernemer. Ik zou de Kamer van Koophandel eens bellen.

Als Higherlevel had bestaan toen ik als student mijn eerste bedrijf begon, had ik er ook dankbaar gebruik van gemaakt. En niet: ondankbaar misbruik...

Beetje onprettig idee, maar je schijnt de API-beveiliging omlaag te moeten schroeven voordat de WooCommerce-plugin van SendCloud werkt: https://support.sendcloud.sc/hc/nl/articles/209988183-Veel-gestelde-vragen-over-WooCommerce Je kunt eens in de serverlogs kijken of het request wel binnenkomt en hoe het is afgehandeld. De foutmelding die je nu krijgt, is namelijk te veel van het type: "Hij doet het niet." Wat voor sleutels moet je aanmaken? SSH?

Dat lijkt ook het probleem: het is nooit geboekt. De vraagsteller heeft het niet over balansen, maar over kolommenbalansen, dus inclusief winst- en verliesrekeningen. Ergens in het resultaat heeft zijn boekhouder kennelijk verzuimd voor 2 miljoen euro aan diefstallen en 35.000 euro aan oninbare vorderingen op debiteuren te verwerken. Daardoor valt de winst ruim 2 miljoen euro te hoog uit, met alle gevolgen van dien voor eventuele vennootschapsbelasting, dividendbelasting en inkomstenbelasting. Een beetje liefhebber van complottheorieën gaat dan al gauw denken dat de boekhouder in het complot zit, ware het niet dat dezelfde boekhouder nu "nieuwe kolommenbalansen" heeft opgesteld waarin de fout naar voren komt. Waarom heeft de boekhouder dan eigenlijk zijn werk overgedaan? En wat zei hij zelf over de verschillen?