Niet fysieke items in aantallen leveren

[mdekraa]

Ik heb een probleem:

Ik zou graag in heart uren o.i.d. kunnen "leveren" en factureren, waarbij ik ook gebruik kan maken van prijsafspraken en DKK's

Dus:
Ik kan vastleggen Prijs van "dienst" "schutting verven per m2" is € 100/stuk
Ik kan vastleggen DKK van "dienst" "schutting verven per m2" is € 050/stuk

En ik kan in een verkooporder opgeven dat ik 10m2 verfactie verkoop tegen die prijs uit de prijstabel.

Zou dit te realiseren zijn.

De enige andere optie die ik n.l. anders weet is om 99999999999999 m2 van een "echt artikel" tegen 0 waarde op voorraad te leggen en daaruit dan te gaan levereen en factureren

Niet echt de gewenste situatie

[Peter Stordiau]

Wouter moet mij (morgen als hij hier weer is) maar korrigeren als ik het fout heb, maar volgens mij moet je dan denken aan Profit-Werkorder (Basisprijs EUR 475).

N.b. voor Marco : Dit op "normale" wijze doen lukt niet, omdat een Dienst geen voorraad kent, en altijd meteen op "geleverd" staat. Er moet dus een "trigger" zijn die vertelt dat de Dienst is uitgevoerd.

Het is voor mij wat lang geleden (Werkorders), en wat ik nu even niet kan bedenken is hoe die prijs per uur (etc.) kan worden gerealiseerd. Dus, dit laten gelden als Kostprijs (via de Werkorder) en zodoende doorbelasten lukt wel en - ook al is het de Kostprijs - dit gaat formeel wel goed als Verkoopprijs, maar hoe gaat de Werkorder die 10/uur ophalen ? ... volgens mij gebeurt dat niet.

Links- of rechtsom, hier is heus wel uit te komen op een redelijke manier. Maar Marco, zeg eerst even of je bereid bent om het bedrag voor die module uit te geven, want anders hebben we de basis niet.

[Wouter Rijnbende]

Als wij ergens a.g.v. consultancy e.d. uren besteden aan een projekt, dan printen we onze uren uit, en maken we een faktuur voor een Dienst, rekenen zelf het bedrag uit door het totaal aantal uren van de print x het uurloon te doen, en vullen dat op de faktuur in. Marco wil dit formeler: bij de Dienst een uurloon kunnen invullen, en dan op de Verkooporder kunnen aangeven hoeveel uren er besteedt zijn. Dat de dienst meteen als "geleverd" staat geregistreerd is juist geen probleem, dat is het ook (even los van een discussie dat je voor Diensten een order kunt willen maken, een opdrachtbevestiging, en op enig moment wilt kunnen aangeven dat deze dienst geleverd is, maar daar gaat het marco m.i. niet om).

Ik denk dat er wel meer van dat soort voorbeelden te verzinnen zijn, ook bijv. om een kilometer vergoeding in rekening te kunnen brengen. Je "verkoopt" het aantal kilometers, en in een prijslijst staat het tarief geregistreerd.

Met Werkorders ga je dat probleem niet oplossen.

[Peter Stordiau]

Wel, ik heb even een klein dagje gewacht tot de "eureka" uit de hoge hoed kwam, maar zo te zien komt die niet.

Wouter, mooi die alinea's beschrijving, maar ik dacht dat dat al bekend was. Jouw laatste regel lijkt dan wat meer nuttig, maar geeft toch weinig oplossing.

Verder -en dat is gewoon mijn idee hierover-, *juist* als je e.e.a. op Verkooporder zet zal je dat wel doen omdat je er een opdracht voor hebt, en geldt dùs dat de opdracht is volbracht op het moment dat het werk is uitgevoerd. Dus, het kunnen ophalen van een "prijs per" is één, maar het niet direkt moeten leveren (want dat doe je als het werk is gedaan) is twee.
Trouwens, niet dat ik Marco daarover hoor, maar het lijkt me de normale situatie (in de logistieke omgeving dan).

Dit laatste los je wat mij betreft alleen op middels Werkorders (tenzij je iets anders volledig op z'n kop gooit), en hier vanaf zijn middels een uitleg hoe wij zelf werken ben je niet (ik zie heel het verband niet eens, hoe waar het ook moge zijn). Aldus :

Wat resteert is die "prijs per" die momenteel alleen niet wordt opgehaald omdat het een Dienst betreft, maar die uiteraard zo erbij is gesleept als het moet.

Als laatste -en ik zeg het maar even voor de zekerheid- dat van die Werkorders lijkt overdreven, maar is voorlopig wel de juiste "logistieke" weg om iemand ook een dienst te laten uitvoeren. Althans, ik zie het verschil met een produktieorder en het maken van de verf voor de schutting niet. Echter, hoe overdreven ook, zonder dat heb je de trigger voor het gereed zijn niet, en die trigger anderszins (erbij) maken ... ik dacht niet dat dit ook maar ergens goedkoper ging worden dan de module.


Goed, aannemend dat je het ergens wel met me eens bent nu, reageer maar niet. Laat eerst Marco maar zeggen of hij niet al twee dagen bezig is z'n 999999 verfmetertjes op voorraad te leggen. Kunnen wij ook gewoon weer doorgaan.

[mdekraa]

Nee, ik heb nog geen metertjes liggen.

Wat ik wel mis is een duidelijk overzicht wat de voor en de nadelen zijn van het werken met werkorders vs. het kunnen aansturen van een "dienstartikel" met aantallen e.d.

Zo-wie-zo wil ik in staat zijn een offerte/order/orderbevestiging in het systeem te kunnen zetten en volgen.

Of dit middels een dienst, een werkorder c.q. een "project" moet gaan lopen is nu net wat ik aan jullie vraag.

Dus graag een meer gericht advies. Ik denk dat Wouter heel duidelijk heeft weergegeven wat wij willen en zoeken. Aan jullie dus de vraag hoe dit formeel het beste en meest correcte opgelost kan worden.

Daarbij onverlet dat ik met prijstabellen in het systeem wil kunnen werken en niet zit te wachten op allerlei extracomptabele systemen.


MK 

[Peter Stordiau]

Ik denk dat Wouter heel duidelijk heeft weergegeven wat wij willen en zoeken.

Ok, dan heb ik dat dus niet. (niet dat dat overeenkomt met wat je het laatst beschrijft, maar dat moet je dan zelf weten).

Aan Wouter verder de eer.

[Wouter Rijnbende]

Aan Wouter verder de eer.

Ik heb geen (legitieme) kant en klare oplossing, anders dan een heleboel maatwerk...

(dat is ook de reden waarom Marco het op het forum zette, mede op zoek naar reakties van andere klanten hoe dié met dat soort zaken omgingen).

[Peter Stordiau]

Ik heb geen (legitieme) kant en klare oplossing, anders dan een heleboel maatwerk...

Ok. Dan maar even omdraaien;
Wat ik er van zie heb ik genoteerd. Wat is daar mis mee ? of anders, waar zit dat "heleboel maatwerk" ?
(probeer het in een zin of 3, wie weet blijft het maatwerk dan ook beperkt, haha)

[Wouter Rijnbende]

Ok. Dan maar even omdraaien;
Wat ik er van zie heb ik genoteerd. Wat is daar mis mee ? of anders, waar zit dat "heleboel maatwerk" ?

Gewoon even een voorbeeld wat dat Werkorders voor ons zou impliceren als we consultancy hebben geleverd:

* We moeten een Verkooporder Toevoegen + verkopen op de Verkooporderregel een Dienst "Consultancy"
* Separaat moeten we een Werkorder toevoegen
* Dan de Werkorderregels definieren w.s. met 2 bewerkingen erin "Consultancy" en "Reistijd"; aan beide hangt een ander tarief
* Dan via een afsluitende bewerking triggeren dat als die bewerking gereed is, de betreffende VO regel gefaktureerd mag worden (en ergens zal ook nog een koppeling moeten worden gemaakt tussen de Dienst op de VO regel, en deze Werkorder).
* Vervolgens de Artikel-/Bewerkingen afboeken, waarmee we feitelijk aangeven hoeveel uren we besteedt hebben (eigenlijk het enige wat Marco wil).
* ... alles wat ik verder vergeten ben.

Bewerkelijk dus...

En dan nog levert het niet op wat we willen, immers:

* op de Werkorder registreren we wel kosten van Artikelen-/Bewerkingen, maar niet welk bedrag er bij de klant in rekening moet worden gebracht, en welke tezamen de Verkoopprijs bepalen.
* op de Faktuur staat niet wat er in de Werkorder geboekt is, en dus staat op die Faktuur al niet hoeveel er kwa consultancy danwel reistijd in rekening werd gebracht (goh... hoe werkt dat eigenlijk bij een garage? in de werkorder staat dat er een oliefilter vervangen is, nieuwe banden, APK, uren etc., maar op de Faktuur staat enkel "onderhoudsbeurt" , zonder de specifikatie uit de werkorder?).


Een heleboel maatwerk:
* Eenheid introduceren bij een Dienst
* Aantal eenheden kunnen invullen bij Verkooporderregels i.g.v. een Dienst
* Verkoopprijsmechanisme aanpassen m.b.t. kunnen registreren prijzen voor Diensten, en dan "per eenheid".
* Verkoopprijsbepaling aanpassen m.b.t. prijs v/e dienst bepalen
* DKK mechanisme overhoop halen i.v.m. DKK's op Diensten   


Het op voorraad leggen van uren / M2 / KM?

Tsja... slaat natuurlijk nergens op, en hoewel we wel een klant kennen die "Vrachtkosten" op voorraad legt (en vervolgens opbelt dat ze een Raaplijst niet kunnen rapen omdat er geen vrachtkosten op voorraad liggen  ) is dat geen methode die wij iemand gaan adviseren 
We kunnen Marco echter niet ervan weerhouden het op die manier te doen, maar ik geef je op een briefje dat hij ook hier ellende mag verwachten, gewoon omdat hij dan iets doet wat niet hoort. Om te beginnen in de hoek van het leveren van zijn Dienst aan het buitenland, welke dan nl. op een ICP aangifte als "Intra Communautaire Prestatie" als Dienst gerapporteerd moet worden, terwijl Profit niets van een Dienst afweet. Andersom zal het systeem richting het CBS rapporteren dat er Artikelen de grens over vervoerd zijn, terwijl er helemaal geen goederen aan de orde zijn.

 

[Wouter Rijnbende]

Ik denk dat het enige wat overblijft, het verkopen van een Dienst is met daarop de totaalprijs EUR 709,50 en dan in de omschrijving (of in het tekstmechanisme, want in de omschrijving zal wel staan waarvoor de dienst geleverd is) aan te geven dat het om 5,5 uur x EUR 129,- gaat.

[Peter Stordiau]

Mwah ... Ik weet het niet;

Die Werkorder is sneller gemaakt dan je voorstelt, maar zo toch niet dan kan daar het e.e.a. aan worden verbeterd (hé, wat is het verschil met het genereren van een Produktieorder uit een VORegel ? -> antwoord nu niet nodig).

Een heleboel maatwerk:

Nee, dat denk ik niet. Maar wel even "andersom" denken;
Wat ik al eerder zei, een Dienst doet alleen maar dingen niet die normaal (bij een Artikel) wel gebeuren. Dus, het betreffende elimineren en het werkt gewoon. Tuurlijk, het is even boenderen voor het achterhalen waar precies, maar dat is heus te doen. Maar draai het maar weer om : je gaat natuurlijk niet jouw gesuggereerde maatwerk maken waar dit alles er domweg al in zit.
Optioneel hoeft het niet te zijn, want niemand zal er last van hebben, mits er maar wel ergens een keuze is voor het genereren van die Werkorder.

Nog even over die Werkorder en een eventueel alternatief daarvoor :
Ga jij maar uitvlooien wat er zoal bij Diensten (door het hele trajekt heen) moet veranderen om die regel niet meteen als geleverd te zien, *plus* dat je iets moet hebben wat die Dienst alsnog Levert. Ofwel, Marco kan wel leuk Wouter's voorstel zien zitten, maar dan begrijpt hij iets niet. Anders gezegd, ik vermoed dat we dat niet eens voor elkaar gaan krijgen, en anders is het wel zo dat niemand dáár aan durf te beginnen. Maarrr ...
Nu is het toevallig wel zo dat het mechamisme er in zit, want dat is immers wat the Werkorder bewerkstelligt. Dit is a. als nog niet geleverd (maar lees : nog niet te faktureren) registeren, en b. het op een gegeven moment impliceren dat Fakturering wèl kan plaatsvinden.


Goed, ik denk zelf dat er nu voldoende aandacht aan is besteed, maar wat wat mij betreft al weer veel te veel is, omdat Marco het toch niet wil hebben. Niet omdat ik dat zeg, maar omdat hij wat serieuzer mag reageren op waar we het hier over hebben, en wat uiteindelijk $$ betekent. Moraal : wij gaan hieraan niet uren verder typen zolang Marco niet zegt dat het hem wel een paar K euri waard is. Je in deze een beetje op de vlakte houden houd ik niet van. Bij deze.