|
Peter Stordiau
|
 |
« Reply #1 on: January 05, 2007, 10:43:40 am » |
|
Dit betreft een relatief drastische wijziging in het pakket, en behelst het kunnen omgaan met Prijsafspraken in een valuta die niet de eigen valuta is, terwijl de uiteindelijke faktuur wèl in de eigen valuta is, en daarmee tegen veelal vooraf afgesproken Koers (Koerstype) wordt afgerekend. E.e.a. speelt zowel aan de Inkoopzijde als aan de Verkoopzijde.
Het speelt met name in landen die wel graag met een harde(re) valuta als de euro werken, maar zelf zo'n valuta niet bezitten (veelal dalend t.o.v. euro (e.d.). Als voorbeeld mogen we Polen hanteren, waarvoor de funktionaliteit overigens ook is ontwikkeld;
Omdat het hoogstwaarschijnlijk zo is dat dit in een land als Nederland niet zal worden toegepast, wordt e.e.a. vooralsnog niet alhier als "handleiding" uiteengezet (die kan maar beter in het Engels worden opgesteld), maar omdat er enkele Nederlandse klanten zijn met zusters / dochters in landen zoals Polen, lijkt het nuttig om in elk geval het bestaan van deze funktionaliteit uit te duiden.
Algemene uitleg
In landen zoals bedoeld, met als voorbeeld Polen, maakt men de prijsafspraken in euro. Dit doet de leverancier met "jou", en dit doe jij met de klanten. Het gevolg is, dat je weliswaar je prijsafspraken in een harde valuta vastlegt, maar je intussen wel fakturen krijgt / stuurt in de eigen (dalende) valuta. Om dit administratief bij te houden zonder onderhavige funktionaliteit is een komplete afdeling met rekenmachines nodig ...
Inkoopzijde
Is relatief simpel, en behelst het kunnen opgeven van de Koers op het moment van Goederen Ontvangst. Let wel, letterlijk kan dit zo niet (bij Goederen Ontvangst) omdat dit dan zou worden overgelaten aan Magazijn personeel, die ofwel de benodigde kennis niet heeft (hoort te hebbenm, hoeft te hebben) dan wel de informatie niet heeft (welke Koers wanneer toepassen).
Aldus loopt de Goederen Ontvangst in zo'n omgeving min of meer gedwongen via Inslaglijsten;
In zo'n omgeving zal de Leverancier verplicht voorafgaand aan de Levering
a. een Voormelding daarvan doen;
b. dit vergezeld doen gaan van een faktuur, waaruit de gehanteerde Koers blijkt.
N.b.: De gehanteerde Koers kan op zich zijn ontstaan uit afspraken, denkend aan dagkoers, gemiddelde koers, enz. Dit is verder voor de Inkoopzijde niet relevant (in het pakket).
Op basis van de Voormelding wordt een Inslaglijst gemaakt (kan dus meerdere Inkooporders tegelijk betreffen voor dezelfde Leveranciers), terwijl één Inslaglijst kan worden voorzien van een Koers.
Dit betreft dus een relatief simpele administratieve handeling die plaatsvindt voordat de goederen arriveren.
Bij de daadwerkelijke Goederen Ontvangst wordt dit gedaan via de Inslaglijst, en voor de Voorraadwaarde wordt de (prijs en) Koers gehanteerd zoals bekend gemaakt op de betreffende Inslaglijst.
Administratief is hiermee voor de Inkoopzijde alles geregeld.
Verkoopzijde
Aan de Verkoopzijde moet enorm veel meer (in het pakket) gebeuren om dit vloeiend te laten werken;
Eerst zijn daar de Prijsafspraken met de klanten, die in euro (enz.) worden geregistreerd, terwijl de klant in Zlotty (enz.) zal worden gefaktureerd. N.b.: Voor bepaalde soorten Prijsafspraken was iets dergelijks voorheen niet mogelijk (en ook niet nodig), terwijl het geheel aan funktionaliteit nu dus meegeeft dat dit intussen kan. Dit betreft dus feitelijk de algemene Prijsafspraken met een klant die (stel voor Nederland) gewoon in euro wordt gefaktureerd, terwijl alles met deze klant in bijv. USD wordt afgesproken. Let wel, zulks kon voorheen wel, maar dan ontving de klant ook een faktuur in USD.
Het eerstvolgende wat in zo'n omgeving optreedt, is dat een klant toch niet afhankelijk wil zijn van de grillen van de koerschommelingen, en dat je aldus daarover "prijsafspraken" maakt. Je legt bijvoorbeeld de Koers vast ten tijde van het maken van de Verkooporder. Ook hier geldt dat dit voorheen niet mogelijk was maar ook niet hoefde (tenzij je op de termijnmarkt zit met je valuta), mits je maar met de klant afsprak dat de afgesproken prijs in de valuta ook in die valuta mocht worden gefaktureerd. Zo niet dan was er nog geen man overboord, want sprak je een prijs af in bijvoorbeeld DEM maar faktureerd je in NLG, dan schommelde de koers tussen DEM en NLG toch dusdanig weinig dat het je allemaal niet interesseerde. Dit zou heel anders zijn als je een prijs in Zlotty afsprak, en je op basis van een faktuur in Zlotty dus ook in Zlotty zou worden betaald (na 3 maanden ongeveer de helft van je geld kwijt, zoals het een aantal jaren geleden was).
Waar de klant aan de ene kant zich ingedekt wil zien, wil je je zelf net zo goed indekken aan de andere kant. Ik bedoel, de Koers vastleggen ten tijde van het maken van de Verkooporder is leuk voor de klant, maar niet voor jezelf ...
En zo kom je vanzelf tot allerlei gradaties van/voor het vastleggen van de te hanteren koers zoals die moet gelden ten tijde van de Levering.
Probeer -terzijde- ook eens te denken aan de pure onmogelijkheid om in zo'n omgeving te werken met vooraf vastglegde Prijzen, omdat je te maken krijgt met Prijzen die domweg veranderen op het moment dat je Levert. Gevolg : rekenmachines erbij, en alvorens je Faktureert alle Prijzen omrekenen middels de afgesproken Koers (die elke dag anders is) om daarna eerst alle Verkooporderregels te voorzien van de te Faktureren prijs. Ja ja ...
Na een uitermate komplex ontwerp (nou ja, 12 A4 of zo) is het fenomeen Koerstypen ontstaan, waarbij het ontwerp met name komplex was omdat e.e.a. zo transparant als mogelijk moest werken, en je je niet suf moet zitten te registeren om e.e.a. aan de gang te maken.
Koerstypen gelden voor een valuta, en er kunnen er net zo veel van worden gedefinieerd als gewenst, met als resultaat dat een Koerstype een afgeleide is van een Valuta (met haar Koers).
Een Koerstype kent onder meer rekenfunkties op basis van typen gemiddelden, denkend aan de gemiddelde koers van de afgelopen maand, de afgelopen kalendermaand enz. enz., de perioden (minimaal op dagbasis) net zo in te delen als gewenst (tot jaren aan toe). Dus, naast het kunnen ingeven van de aktuele dagkoers (wat er op zich meerderen kunnen zijn, bijvoorbeeld afhankelijk van de instantie die ze afgeeft), kunnen er daarvan (zelf op te geven) afgeleiden worden gedefinieerd.
Het geheel staat aldus toe om welke "afspraak" er in deze met/door een klant is gewenst, deze zo gemakkelijk als mogelijk te registeren en haar werking te laten hebben.
Waar bovenstaande de helft van het verhaal is, onstaat de andere helft omtrent het moment van de Koersbepaling. Denk ten eerste weer aan het inleggen van de Verkooporder, maar denk ook aan het moment van Leveren, denk aan meerdere Leveringen voor een Verkooporder (en dus indien gewenst meerdere Koersmomenten), denk aan het handmatig willen overschrijven van de berekeningen, de registraties bij de Debiteur (wat is de afspraak eigenlijk).
Het geheel zorgt er uiteindelijk voor dat alles zonder er naar om te kijken kan gebeuren, en waar er (werkelijk !) uren werk nodig waren om één Verkooporder van enige omvang af te handelen, kost het nu niets meer dan het dagelijks registeren van de Koers (wat toch al wel gebeurde).
N.b.: De Faktuurlayout kan op regelniveau worden voorzien van de gehanteerde Koers (want meerdere Leveringen op meerdere dagen leiden tot verschillende Koersen voor de ene Faktuur die uiteindelijk wordt gestuurd (omdat Faktureren niet verplicht dagelijks gebeurt)).
Let op : Van dit geheel is niets zichtbaar als de Parameter zoals onderstaand weergegeven niet is aangevinkt.
Merk op dat dit op deze wijze aktief is gemaakt omdat het verregaande gevolgen heeft voor de werking van het geheel, welke werking echter niet behoort te veranderen als er verder niets wordt ingesteld en e.e.a. dus veiligheidshalve zo is gedaan.
|
