Inleiding

Optioneel

Heeft u in uw bedrijfsadministratie te maken met vreemde valuta? In elke Office Programs Access applicatie wordt dit feilloos voor u geregeld.

Valutagegevens worden geleverd door financiële gegevensverstrekkers en banken, inclusief de Europese Centrale Bank. De data wordt zeer nauwkeurig in de bedrijfsadministratie verwerkt. Zo wordt bijvoorbeeld rekening gehouden met de werkelijk aangeleverde koers (niet afgerond) en de landinstellingen van uw systeem. Verder zijn er in elke Office Programs applicatie tevens slimme manieren van dataverwerking geïntegreerd waarbij zeer veel mogelijk is m.b.t. verkopen en inkopen.

• Haal koersen op van vreemde valuta van +/- 170 landen wereldwijd.
• Eén keer per dag op een knop drukken is alles wat nodig is.
• Koersen kunnen elke 60 seconden worden bijgewerkt, dus altijd zeer recent.
• Ook de ValutaOmschrijvingen worden bijgewerkt.
• Zowel handmatig als geautomatiseerd bijwerken is mogelijk.

De data wordt opgehaald middels een API waarvoor u zich gratis kunt registreren. Vervolgens zorgen we ervoor dat de data op de juiste wijze in de database wordt verwerkt. De module kan in veel verschillende omstandigheden worden gebruikt, dus ook voor elk soort van maatwerk.

Gegevensblad Valutakoersen

In het gegevensblad Valutakoersen kan data eventueel handmatig worden aangepast, maar eigenlijk hoeft u hier nooit te zijn (Fig. 1). Op elke relevante locatie waar met bedragen wordt gewerkt kunnen de koersen makkelijk worden bijgewerkt via menu Specifek (Fig. 2).

Fig. 1

Fig. 2

Voorbeelden bij orders

In dit voorbeeld van formulier Orders (screenshot) dat afkomstig is uit Office Programs Orders (Home > Orders), kan zowel een verkoop- als een inkoop order worden gemaakt met dezelfde order (meer hierover in de rubriek Slimme dataverwerking).

• Aan de relaties kan (maar niet verplicht) een Valutacode worden toegekend. Bij het aanmaken van de order wordt die overgenomen, maar kan ook anders worden ingesteld zolang de order nog niet is opgeslagen.
• In Fig. 3 (verkoop order) wordt relatie INT-PRODUCT_RICHMOND (een nep Amerikaanse klant) ingesteld als de Opdrachtgever met de bij hem behorende Valutacode.
• In Fig. 4 (inkoop order) wordt dezelfde relatie ingesteld als de Leverancier. En nee, die is niet twee keer ingevoerd! Verderop meer hierover.
• Mocht het zijn dat de Amerikaanse relatie u toestaat in EUR in te kopen (wat in wezen zo hoort) dan kan dat. U kunt altijd in elke gewenste valuta zowel verkopen als inkopen.
• In Fig. 3 en 4 zal de applicatie de invoer aansturen a.d.h.v. de SoortOrder zodat niks overbodigs gedaan wordt en er geen fouten kunnen worden gemaakt.
• In Fig. 5 ziet u iets wat in de ICT volstrekt ongewoon is (so what!). Daar kan zowel een verkoop- als een inkoop order worden gedaan met dezelfde order. Meer hierover in de rubriek Slimme dataverwerking.

Fig. 3

Fig. 4

Fig. 5

In de rubriek Voorbeelden bij orders hebben we al wat slimme voorbeelden gezien. Een andere visie voorkomt een hoop gedoe. Want wat we vaak zien is dat data dubbel ingevoerd moet worden. Zo kan een relatie best zowel een debiteur als een crediteur zijn, nietwaar? Echter, bij de meeste (zo niet alle) boekhoudpakketen moet die relatie twee keer worden ingevoerd... Dat is niet alleen lastig, maar het zorgt ook voor de nodige problemen. En de soort relaties bestaan echt niet alleen uit debiteurs en crediteurs. Denk eens aan vervoerders, bemiddelaars, producenten etc.

Waarom blijft men alsmaar de fout maken een relatie voor elk doel een extra keer in te moeten voeren? Dat komt doordat mensen erg 'geconditioneerd' zijn. Gewoon dingen blijven doen 'omdat iedereen dat zo doet' of 'omdat het al zo lang op die manier gaat'. Het is een 'menstale slaap': gewoonte- en gedachtenpatronen niet kunnen loslaten... Daarom moet een echte ontwikkelaar heel wakker zijn en over echt inzicht beschikken.

Zonder het vermogen los te laten is innovatie niet mogelijk. Want waar het oude is, daar kan het nieuwe niet zijn.

Slimme dataverwerking

In voorgaande voorbeelden heeft u gezien hoe we met verkoop en inkoop omgaan. Met Office Programs Orders gaat dat een stukje verder. Naast enkele bijbehorende documenten die van de SoortOrder afhankelijk zijn, moet o.a. rekening gehouden worden met:

• Bij een verkoop order moet een opdrachtgever kunnen worden geregistreerd. Bij een inkoop order een leverancier. (In het formulier Orders (screenshot) wordt a.d.h.v. de SoortOrder de gehele bedrijfsadministratie afgewerkt, niet alleen op financieel gebied).
• Bij het (automatisch) factureren van een verkoop order wordt een verkoop factuur gegenereerd. Bij een inkoop order een inkoop factuur.

We gaan zelfs een flinke stap verder. Het SoortOrder kan namelijk ook een 'Indirecte verkoop order' zijn (screenshot). D.w.z. dat dezelfde order (één keer invoeren dus) kan doorgaan als zowel een verkoop- als inkoop order (screenshot).

Alle bijbehorende documenten van elke soort order worden automatisch gegenereerd, zoals:

• Aan de verkoop kant een offerte voor de klant en een orderbevestiging bij akkoord.
• Aan de inkoop kant een mogelijkheid om te bestellen bij de leverancier en een inkoopbevestiging na levering.
• Bij de autofacturering wordt bij verkoop een verkoop fatuur gegenereerd en bij inkoop een inkoop factuur.

En alles door slechts één order te maken...

Voorbeelden bij facturen

Voor wat bereft facturen is het altijd óf een verkoop- of een inkoop factuur. Beide tegelijkertijd zoals bij een order, kan bij facturen natuurlijk niet.

In een goed 'dataverwerkingssysteem' moeten facturen incidenteel, handmatig, collectief en geautomatiseerd kunnen worden aangemaakt zodat altijd elke factuur onder elke situatie kan worden gemaakt. Ook meerdere eigen bedrijven moeten de factuur kunnen aanmaken. In het voorbeeld bij orders, worden voor zowel de verkoop- als voor de inkoop orders de juiste facturen volledig geautomatiseerd aangemaakt. Hoe dat allemaal kan is voor u niet relevant; wat wel relevant is, is dat u krachtige middelen in huis heeft die garant staan voor een hoogwaardige efficiëntie.

In het formulier Facturen (screenshot) kan zowel een verkoop- als een inkoop factuur worden gemaakt. In Fig. 6 en 7 is dezelfde relatie hiervoor gebruikt. In dit geval wordt de aanduiding 'klant' gebruikt waarvoor goede redenen zijn.

Fig. 6

Fig. 7