Binnen dit ontwerp geldt als voorbeeld dat er ergens op lokatie een nieuwbouwprojekt wordt gestart; het schilderen van een schip. Dit projekt wordt aangenomen voor in principe een lumpsum bedrag, en wordt in termijnen in rekening gebracht.
Hoewel we middels veel maatwerk dit verregaand kunnen automatiseren, is bedacht e.e.a. 'simpel' op te zetten. Bij deze simpele opzet wordt gebruik gemaakt van de funktionaliteit die het pakket reeds biedt, met her- en der wat aanpassingen. De registratie van de lumpsum zelf vindt binnen dit ontwerp <i>niet </i> plaats.
Nb: Dit laatste mede, omdat het niet zo zeer een aangenomen werk betreft welke voor een vaste prijs berekend wordt, maar meer voor 'een maximale prijs'. Wordt er minder verbruikt, dan is de klant goedkoper uit.
Een belangrijk punt binnen dit ontwerp betreft de registratie van de de geplande hoeveelheid te verbruiken goederen, en het daadwerkelijke verbruik. Op zich zouden we dan al snel aan 'een Werkorder' denken, immers ook daar werken we aan een projekt, kunnen we plannen hoeveel materiaal we denken te verbruiken, kunnen we registreren hoeveel we daadwerkelijk verbruikt hebben, en kan het gereedkomen van een sub-werk triggeren dan een eerst volgende termijn gefaktureerd mag worden.
Er wordt expliciet niet voor deze methode gekozen, met als reden dat het daadwerkelijke verbruik wordt gezien als 'verkochte hoeveelheid' en als zodanig moet kunnen worden teruggezien in de Verkoopstatistieken.
Zouden we naar de funktionaliteit "Werkorders" kijken, dan faktureren we slechts "de termijnen" en staat er geen goederen in de Statistieken; alleen de termijnbedragen.
Om e.e.a. in de Statistieken tot uiting te kunnen brengen, zijn er daadwerkelijke Fakturen nodig. Fakturen, die gegenereerd moeten worden op basis van het daadwerkelijke verbruik. Dit zijn echter niet de fakturen die door de klant betaald moeten worden, immers, de klant betaalt (tot de eindafrekening) de termijnen.
Middels een Verkoopkontrakt gaan we nu zo'n nieuwbouw projekt registeren. Het Kontrakt bestaat uit een of meerdere Artikelen, hoeveelheden, en een Verkoopprijs. Tezamen zullen alle regels en hoeveelheden in het Kontrakt "de afgesproken prijs" moeten benaderen.
In het Kontrakt kunnen we bijv. 20.000 liter plannen tegen een prijs van EUR 5,- per liter.
Het daadwerkelijke verbruik worden nu afroepen uit dit Kontrakt, en zullen als zodanig worden gefaktureerd. Deze faktuur wordt verderop weer tegengeboekt; die uitleg volgt verderop.
<b>Nieuwbouw situatie J/N</b>
Teneinde deze (afwijkende) funktionaliteit te kunnen triggeren, dient bij het Kontrakt eerst expliciet een veldje "Betreft Nieuwbouw situatie J/N" met "Ja" te worden beantwoord. Het op Ja zetten van die rubriek stelt triggert de uitvoering van een aantal verplichte kontroles, zoals het moeten invullen van de Raapvloer alsmede het Kostenartikel waarmee eventuele leveringen automatisch moeten worden gecrediteerd.
Wordt deze rubriek niet op <b>J</b> gezet, dan blijft alles werken zoals voorheen.
<b>Nieuwbouwlokatie</b>
Voor ieder 'werk' zullen we een Lokatie moeten definiëren die representatief is voor het betreffende nieuwbouwprojekt, bijv. NB001 waarin NB voor NieuwBouw staat, of misschien juist NI001 waarin N voor Nieuwbouw staat en I voor Italië (merk immers op dat we aan een Magazijn een Landkode koppelen, en deze Landkode van belang kan zijn voor eventueel grensoverschrijdende leveringen). Deze Lokatie koppelen we 1:1 aan het Kontrakt, door deze als "Raapvloer" in te vullen.
<b>Crediteren via Kostenartikel</b>
Al hier een gemene truc, om ervoor te zorgen dat onze Artikelen in de Statistieken terecht komen, en niet de termijnen die aan de klant worden gefaktureerd. Uitgangspunt hiervoor is dat de termijnen die aan de klant worden berekend, via een Kostenartikel in rekening worden gebracht. Wellicht is het hierbij handig om per "werk" een apart Kostenartikel te hebben, maar, verplicht is dat niet.
Als we enerzijds een afroep hebben (Verkooporder) en daarin het daadwerkelijke verbruik registreren, dan zal het faktureren van deze order ervoor zorgen dat dat werkelijke verbruik op het werk in onze Statistieken terecht komt. Maar, zouden we nu anderzijds ook de termijnen faktureren aan de klant, dan hebben we een dubbele omzet, en dat willen we niet.
Dit is ook niet iets wat we oplossen met "In Statistieken J/N", immers, ook al tonen we e.e.a. niet in onze statistiek, in het Grootboek zouden we alsnog een dubbele omzet hebben.
De truc is nu als volgt: Het Kostenartikel waarmee we de termijnen in rekening brengen, nemen we op bij het Kontrakt, in een rubriek "Automatisch Crediteren via Kostenartikel". Als we nu op basis van het daadwerkelijk verbruik EUR 10.000,- faktureren, dan wordt dit bedrag automatisch tegengeboekt met het Kostenartikel (16706 in bovenstaande afbeelding). Een afroep uit een Nieuwbouw Kontrakt leidt op zo'n manier tot een Faktuurbedrag van EUR 0,00.
Separaat zullen we handmatig de termijn in rekening moeten brengen. Dat doen we via hetzelfde Kostenartikel, in dit geval 16706. Stel, de termijn bedraagt EUR 12.500,-
Als we nu naar onze Statistieken kijken, is daarop in totaal EUR 0,00 + EUR 12.500,- gefaktureerd, en dat is ook precies wat er in werkelijkheid gebeurd is; er is alleen een termijn van EUR 12.500,- bij een klant in rekening gebracht.
Specificeren we de Statistieken naar Artikelen, dan zien we dat er EUR 10.000,- is berekend onder de daadwerkelijk verbruikte Artikelnummers, en dat er nog EUR 2.500,- (12.500 minus 10.000) staat onder het betreffende Kostenartikel 16706.
De totale omzet klopt, en we hebben ook alle Artikelen in onze Statistieken staan. Het feit dat we een positief bedrag op het Kostenartikel hebben, impliceert dat de termijn hoger was dan het daadwerkelijke verbruik; als dat bedrag < 0, dan zal het werkelijke verbruik hoger liggen dan de termijn.
<b>Voorraad Verplaatsen</b>
Op enig moment zijn er goederen benodigd op het projekt. Deze zijn hooguit "nodig" en zijn nog niet verbruikt. Om op het projekt over de goederen te kunnen beschikken, zullen er eerst goederen naar het werk moeten worden verplaatst. Dat doen we middels Externe Verplaatsopdrachten (module <b>Profit-Pickorder</b>), waarmee we Voorraaditems kunnen verplaatsen van een Voorraadlokatie, naar de Raapvloer die representatief is voor het werk: NI001. Op deze manier kunnen we 2.000 liter verplaatsen naar het werk.
<b>Andere weergave mode bij Raadplegen Kontraktregels</b>
Zodra bij een Kontrakt is aangegeven dat het om een Nieuwbouw situatie gaat, triggert dit een andere weergave v.w.b. Raadplegen Kontraktregels. De Kontraktregel toont nu het aantal eenheden conform het Kontrakt, de reeds afgeroepen hoeveelheid, de nog openstaande hoeveelheid, het deel wat al geleverd is, en tevens hoeveel voorraad er op dit moment nog (niet verbruikt) op de betreffende Raapvloer ligt.
<b>Toevoegen V.O. Regel haalt Raapvloer Kontrakt op</b>
De registratie van het daadwerkelijke verbruikt (en welke ook gefaktureerd moet worden) betreft nu een normale Verkooporder aan de Debiteur voor wie het Kontrakt is opgesteld. De goederen die verbruikt zijn zullen moeten worden afgeboekt van de Nieuwbouwlokatie die aan bij het Kontrakt is opgenomen.
Desgewenst kan reeds bij het Toevoegen van de Verkooporder worden aangegeven dat het om een order gaat voor Raapvloer "NI001", waarna de Raapvloer naar alle VO Regels zal worden gekopieerd. Ook al wordt er op headerniveau geen Raapvloer opgenomen, zodra er een produkt wordt verkocht welke t.l.v. een Kontrakt dient te worden afgeboekt, zal, indien dat Kontrakt verwijst naar een Raapvloer (= Nieuwbouw lokatie) deze Raapvloer worden overgenomen in de Verkooporderregel.
Omdat het toevoegen van de Verkooporderregel een registratie betreft van het daadwerkelijke verbruik, iets wat 'al gebeurd is', en waar we dus nog niet een trajekt 'Toevoegen aan Raaplijst, Rapen, Goedkeuren, Printen Pakbon' etc. nodig hebben, wordt een dergelijke regel onder water direkt geleverd (vanaf de Nieuwbouwlokatie die bij het werk hoor).
Om dit proces lekker te laten verlopen, dient bij Expeditie Parameters rubriek "Aantal Verschijningen opgeven bij Direkt Leveren" met "Nee" te worden gevuld, en dient rubriek "Default Voorraad/Besteld bij Direkt Leveren" met "B" te worden gevuld.
Nadat de Verkooporderregel is toegevoegd, zal deze regel automatisch worden gecrediteerd met het Kostenartikel zoals is opgegeven in het Nieuwbouw Kontrakt. Een dergelijke order behoort per saldo altijd op 0,00 uit te komen; de Faktuur wordt niet naar de klant gestuurd, omdat juist een separaat (handmatig te maken) Faktuur met een termijnbedrag bij de klant in rekening wordt gebracht.
De 0,00 Faktuur die hieruit volgt is bedoeld om de Statistieken te kunnen vullen met Artikelnummers (i.p.v. de termijnen) zonder dat er per saldo omzet geboekt wordt.
<b>Let op:</b> Binnen dit ontwerp geldt dat :
- het bedrag van het daadwerkelijk verbruik zoals ingevoegd op de Verkooporderregel die de automatische credit triggerde, gecrediteerd wordt
- er wordt niet gekontroleerd op andere zaken (zoals mogelijk DKK Tarieven) die een eventueel orderbedrag alsnog kunnen doen vullen
- het daadwerkelijke verbruik geboekt wordt uit voorraad die eerder naar de betreffende Raapvloer is geboekt, en die voorraad dus ook <i>altijd </i> kan worden afgeboekt, en wórdt afgeboekt. Om nog meer te benadrukken dát er geleverd moet worden, gebeurt dit automatisch direkt na het Toevoegen van de Verkooporderregel. Merk op dat als we minder zouden rapen via een Raaplijst (danwel geraapte regels gaan terugboeken), de automatische Creditregel voor een onjuist bedrag genoteerd zal zijn. Natuurlijk kunnen we dit op talloze plekken gaan kontroleren/inbouwen, maar daar hangt een prijskaartje aan. Omdat dit niet aan de orde zal zijn, staan we nu toe dat dergelijke koding achterwege kan/mag blijven. Gaat u dit toch op een andere manier gebruiken dan bedoeld, dan kan aanvullend maatwerk benodigd zijn om deze funktionaliteit te vervolmaken.
- er op een nieuwbouw-verbruiks-order alleen maar registraties worden vermeldt van daadwerkelijke afroepen uit een Kontrakt; dit, omdat de Faktuur die uit deze order gegenereerd wordt "intern" is, op 0,00 wordt gegenereerd, en niet naar de klant wordt gestuurd. Zouden we dus ook échte produkten in rekening brengen, dan zal er tegen het ontwerp in wél een bedrag uit de order volgen.
- een afroep uit een nieuwbouworder triggert dat de order niet gedeeltelijk geleverd mag worden, en triggert dat de orderheader geen (Italiaanse) Spese Bolli in rekening brengt.
<b>Verwijderen Automatische Creditregel</b>
Zodra de Verkooporderregel waarop het verbruik werd geboekt wordt verwijderd, zal ook automatisch de Kostenregel waarop dit verbruik werd gecrediteerd worden verwijderd.
Het handmatig verwijderen van de Automatische Creditregel is niet toegestaan.
<b>Deellevering-/Deelfaktuur</b>
Omdat het uitgangspunt is dat we e.d. order altijd zullen leveren uit voorraad die eerder naar 'het werk' verplaatst is, geldt dat we het werkelijk verbruik ook altijd moeten kunnen leveren; de voorraad behoort gewoon aanwezig te zijn. Deelleveren is derhalve niet toegestaan. Ook is deelfakturatie niet toegestaan, immers, de hele order zal per saldo moeten leiden tot een Faktuur van 0,00. Dit mag niet worden gekombineerd met andere orders-/fakturen.
De "Deelleveren" indikator van de Verkooporder zal derhalve automatisch op "N" worden gezet, en tevens zal direkt na toevoegen, direkt een levering worden getriggerd vanaf de opgegeven Raapvloer.
<b>Fakturatie</b>
Doel van deze afroeporders die direkt gecrediteerd worden middels een Kostenartikel, is, om de statistieken te voorzien van de Artikelen die daadwerkelijk verbruikt zijn, en dat deze niet slechts 'in rekening gebrachte termijnen tonen'. De Faktuur die uit e.d. nieuwbouw order volgt, zal altijd een bedrag van 0,00 moeten opleveren (bij de gratie dat iedere regel gecrediteerd wordt).
Binnen een Italiaans bedrijf, waar afhankelijk van het soort Faktuur een andere Faktuurnummerrange getriggerd wordt, geldt dat ook de Fakturen die uit deze nieuwbouworders komen binnen een eigen range genummerd kunnen worden. Hiertoe is bij de parameters een 4e Faktuurnummerrange opgenomen:
V.w.b. een Italiaans Bedrijf zullen de Fakturen uit deze range worden toegekend aan een categorie (V4) welke niet wordt weergegeven op het Faktuurregister. Uitgangspunt is dat deze Fakturen altijd een bedrag van 0,00 zullen hebben, en daarmee 'intern' mogen blijven.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOBTIVGN | Omschrijving (nog) niet bekend | 01-10-2013 | 08-10-2013 |
| LOOFT | Omschrijving (nog) niet bekend | 03-06-2013 | 02-10-2013 |
| LOPAVFWY | Wijzigen Faktuur-parameters (Verkoop) | 15-05-2013 | 08-10-2013 |
| LOUFDB | Fin. Doorbelasten Faktuur | 20-08-2013 | 08-10-2013 |
| LOUFGN1 | Omschrijving (nog) niet bekend | 12-09-2013 | 08-10-2013 |
| LOUFGN6 | Omschrijving (nog) niet bekend | 12-09-2013 | 08-10-2013 |
| LOUFGNFB | Omschrijving (nog) niet bekend | 09-08-2013 | 08-10-2013 |
| LOVRRA | Raadplegen Verkooporderregels | 16-08-2013 | 08-10-2013 |
| LOVRTV | Toevoegen Verkooporderregels | 30-09-2013 | 04-10-2013 |
| LOVRTVF1 | Omschrijving (nog) niet bekend | 17-07-2013 | 04-10-2013 |
| LOVRTVKK | Omschrijving (nog) niet bekend | 21-04-2010 | 02-10-2013 |
| LOVRTVNB | Omschrijving (nog) niet bekend | - - | 04-10-2013 |
| LOVRVW1 | Omschrijving (nog) niet bekend | 01-10-2013 | 04-10-2013 |
| LOZKKRRA | Raadplegen kontraktregels | 19-05-2011 | 01-10-2013 |
| LOZKRA | Raadplegen kontrakten | 14-11-2011 | 01-10-2013 |
| LOZKRA1 | Raadplegen Kontrakten van Kliënt op Openindikator | 14-11-2011 | 01-10-2013 |
| LOZKTV | Toevoegen Kontrakt van Kliënt | 03-09-2013 | 01-10-2013 |
| LOZKWY | Wijzigen Kontrakt Kliënt | 14-11-2011 | 04-10-2013 |
