Ward van der Put

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?

Er zijn verschillende tools die patronen kunnen vinden in (big) data. Bijvoorbeeld de Prediction API van het Google Cloud Platform kun je onder andere voor purchase prediction inzetten. Overkill in dit geval, maar nuttig om te weten dat het kan. Je hebt de basis gelegd van een eenvoudig model: je hebt twee variabelen met een lineair verband (het percentage). In werkelijkheid zijn er meer variabelen of drivers die inkoop en verkoop sturen. En de causale verbanden volgen meestal geen rechte lijn, maar kromme lijnen, zoals een afvlakkende curve of een normale verdeling. Zo te zien heb je hiermee een mooie casus en voldoende data voor een afstudeerproject van een student economie, econometrie of statistiek. Ik zou eens bij een universiteit polsen of je daar een opdracht kunt uitzetten: wat zijn die drivers, wat zijn de verbanden ertussen en hoe kan ik die in een praktisch spreadsheetmodel gebruiken, zodat ik de inkoop op scherp kan zetten?

Winst uit onderneming is hier geen zuivere nettowinst, maar loon naar werken. Als je een reële arbeidsvergoeding voor de twee vennoten verdisconteert, houd je mogelijk nul winst of een verlies over. En daarmee kun je evengoed beargumenteren dat de onderneming niets waard is of hooguit het totaal van bij liquidatie verhandelbare activa.

Er is geen keuze. Einde samenwerking ≡ einde VoF. Wel zit er kennelijk nog iets in het samenwerkingsverband dat je graag voor jezelf wilt hebben? Een handelsnaam, een merknaam, een klantenbestand*, een pc of twee, kan van alles zijn. Daarover moet je onderling wat afspreken bij het afrekenen. * Heeft je gebruikersnaam Kingdom MLM toevallig iets te maken met multi-level marketing? Correct. Jullie maken de balans op en sluiten de boeken voor de VoF, letterlijk en figuurlijk. Daarna begin je opnieuw voor jezelf.

Ja, dan is de PSP een debiteur. Bij elke iDEAL-betaling neemt je vordering op die debiteur toe, totdat je van de PSP een creditfactuur ontvangt en de PSP het saldo uitkeert. Die creditfactuur is tevens een kostenfactuur voor de iDEAL-transactiekosten plus de terug te vragen btw daarover. @Highio Ik interpreteerde de vraag wat ruimer vanwege het hypothetisch tegen veel werk opkijken: "Het is nogal wat werk om (stel) 100 orders per maand [...]". Dan kun je dus naar andere oplossingen gaan kijken.

Hangt er wel een beetje van af hoe je iDEAL-betalingen ontvangt: is dat via een PSP (payment service provider) die één keer per week uitkeert, dan heb je immers wel een debiteur. ;) Als iets (te) veel werk wordt, is automatiseren een voor de hand liggende oplossing. Veel webwinkelsoftware laat zich wel op een of andere manier koppelen aan boekhoudsoftware. Als je webwinkelsoftware al veel vastlegt (debiteuren/crediteuren, verkopen, facturen, btw-bedragen en betalingen), is er verder veel voor te zeggen om die verkoopadministratie te gebruiken als subadministratie; daaruit neem je dan met een rapport bijvoorbeeld één keer per dag de totalen over in je hoofdadministratie. Zo heb je overzicht en zijn toch alle details vastgelegd.

Misschien zie je wat alternatieve financieringsmogelijkheden over het hoofd? Een bestelbus kun je ook zakelijk leasen bijvoorbeeld, zodat effectief niet je privéwoning maar de bedrijfswagen het onderpand is. Lijkt mij een veiligere keuze. Werkkapitaal zoals voorraden kun je financieren met leverancierskrediet en een voorraadfinanciering.

Als je niet vraagt om een advies maar om een beslissing of een standpunt, krijg je daarop in de regel wel een goed onderbouwd antwoord ... ... soms zelfs inclusief een kopie van een pagina uit Elsevier Belastingalmanak met in geel gearceerd de relevante passages.

Misschien maar eens bij de bron beginnen: mijnwebwinkel zelf heeft een prima blog voor support, dat onder andere ingaat op de basisbeginselen van SEO en aanverwante onderwerpen zoals het gebruik van Google Search Console voor je webshop. Lees daarnaast zeker eens de Beginnershandleiding voor zoekmachineoptimalisatie (PDF) en de kwaliteitsrichtlijnen van Google zelf. Voor liefhebbers van checklists is deze infographic (JPEG) met de mythologische 200 ranking factors van Google een fijn hebbeding.

Het ding had nooit de "cookiewet" mogen worden genoemd, want hoofdstuk 11 van de Telecommunicatiewet geldt niet slechts voor cookies. Maar, inderdaad, bijvoorbeeld ook voor trackingpixels in e-mail.

Een waarderingsgrondslag overeenkomen is inderdaad belangrijker dan een concrete waarde vooraf vastleggen. Er wordt bovendien nog ingekocht:

Dan gebruik je Mendix kennelijk vooral voor rapid prototyping, maar daarvoor bestaan veel alternatieven, van paper prototyping (met UX Flowchart Cards bijvoorbeeld) tot en met Photoshop. Een frontend developer zal het niet snel doen, maar ik heb managers ook wel eens goede concepten voor applicaties zien uitwerken in (eek) PowerPoint. Net zoals je NoSQL niet moet gebruiken omdat je geen SQL beheerst, moet je low-code ook niet gebruiken omdat je (te) weinig van code weet. Het is anders een non-keuze: je moet een tool niet kiezen omdat andere tools te veel nadelen hebben, maar omdat de voordelen substantieel bijdragen aan je doel. Om daarmee je laatste vraag te beantwoorden: ja, ik denk dat een goede programmeur — en vooral iemand die een bepaald framework beheerst — in code ongeveer even snel iets werkbaars kan neerzetten. Voor een CRM zeker, want dat bestaat voor minstens 80 procent uit bewezen concepten waarvoor je zelf geen compleet nieuwe proof of concept hoeft te bedenken. Niet het wiel opnieuw uitvinden... Als je zelf vooral een goed frontend developer bent, waarom zou je dan niet samenwerken met een sterke backend developer?

Het is waarschijnlijk op forumniveau nu eenmaal ook off topic: een developer die naar de beste developer tools vraagt, is als een tandarts of bouwvakker die naar de beste boormachine vraagt. Als ik zou uitleggen hoe wij git in onze deployment cycle gebruiken, zijn er vermoedelijk 2 Higherlevel-leden die instemmend ja-knikken tegenover 98 Higherlevel-leden die denken dat ik gek geworden ben. Dat moeten we dan misschien maar niet doen.

En iedereen wordt softwareontwikkelaar? Van visual application development kennen we een oudere vormvariant: visual webdesign met Dreamweaver of FrontPage. Die maakten ook van iedereen een webdesigner. :P

Rijden zonder rijbewijs is een misdrijf. Gelijk in gesprek met de werknemer gaan — vanavond nog bellen (en niet slap mailen en niet laf appen) — en deze zonder duidelijk uitsluitsel op non-actief zetten. Aansprakelijkheid voor gepleegde misdrijven uitsluiten is onmogelijk. Norbert kan dat vast beter uitleggen, maar zijn antwoord lijkt me helder: ontslag op staande voet als het waar is.