Gemeenschappelijke bestanden en multistock

Navigation:  Uitbreiding stockbeheer > Multistock / dynamische stock >

Gemeenschappelijke bestanden en multistock

Previous pageReturn to chapter overviewNext page

DBFACTw beschikt over bepaalde unieke features, die het handig maken om met één artikelbestand en relatiebestand over meerdere dossiers (boekhoudingen) dezelfde informatie bij te houden.

 

Enkele voorbeelden:

- u heeft meerdere ondernemingen, één die vooral naar end-users commercialiseert, andere die zorgen voor de aankopen

- u heeft meerdere vestigingen, waarvan een aantal terug te vinden zijn onder gemeenschappelijke ondernemingen

- u heeft één onderneming die zorgt voor de verkoop, een andere waar servicing op wordt gedaan.

 

Protip

Aangezien veel informatie steeds gekoppeld is aan verschillende relaties (klanten en leveranciers), en artikelen (met groepen, soorten etc.) moet men zowel de artikelbestanden 'gemeenschappelijk' zetten, als de relatiebestanden.

 

Voor de setup wordt verwezen naar professionele dealers of TML om dergelijke setup te verzorgen.

 

Voorbeeld van een schema:

 

 

De voordelen

 

- één artikel aanmaken, is onmiddellijk over alle dossiers beschikbaar

- een relatie maakt het ook onmiddellijk mogelijk, en alle informatie (ook contactpersonen, telefoonnummers etc). beschikbaar over meerdere dossiers

- de uniformiteit van de gegevens (prijsafspraken etc) worden netjes overal bekend.

- stock wordt per dossier gekoppeld aan een stockplaats, zodat men in gelijk welk dossier de stocksituatie van een ander dossier kan opvragen.

 

De eigenheid van de dossiers blijft echter behouden: zo blijven documenten steeds gekoppeld aan het oorspronkelijke dossier, en worden ook backorders in het dossier (per dossier) netjes bijgehouden.

 

Zijn er nadelen?

 

Helaas wel. Doordat veel zaken gemeenschappelijk gesteld zijn, kan niet alles nog gewijzigd worden. Ook zal bepaalde informatie niet beschikbaar zijn op andere plaatsen.  Wat echter vandaag niet kan, zal misschien in de toekomst wel mogelijk zijn. Deze nadelen wegen echter heel weinig op ten opzichte van de vele voordelen dat dit centraal concept toelaat.

 

Aangezien sommige bestanden gemeenschappelijke staan, moeten de 'links' naar dergelijke bestanden ook steeds uniform zijn. Enkele voorbeelden:

 

Divisie

De divisies staan als parameter lokaal, maar moeten over alle dossiers op dezelfde manier ingegeven worden. Immers, relatiebestanden gebruiken deze informatie gemeenschappelijk.

Grootboekrekeningen

De grootboekrekeningen die op de artikelen worden gebruikt moeten zeker in àlle dossiers terug te vinden zijn, anders zullen fouten en problemen voorkomen bij ingave op documenten.

Btwcodes

De codes moeten in alle dossiers bestaan. Hier kunnen we echter - mits een paar nadelen - echter nog duidelijk een stap verder gaan. Immers, soms komt het voor dat bepaalde gebruikte codes een andere betekenis hebben in andere dossiers. Een voorbeeld: één van de ondernemingen is een Nederlandse firma, waar de btw-tarieven anders liggen. Zo kan in beide gevallen btw-code 10

- in het Belgisch dossier overeenkomen met 21 % btw

- in het Nederlandse dossier overeenkomen met 19 % btw

 

Klungelalarm

Deze methode is uiteraard zeer handig, maar er schuilt een belangrijk addertje onder het gras. Immers, DBFACTw houdt bepaalde prijzen inclusief btw bij. Vergeet in 't slechtste geval ook al de kosten niet. In het buitenland worden immers niet (of niet alle!) kosten in rekening gebracht. Gevaarlijk wordt het als deze zaken gebruikt worden (via de module kosten- en taxenbeheer) in kasverkopen, aangezien prijzen incl./excl niet overeenkomen met de juiste verhouding van deze prijzen.

Spreek daarom in dit geval af dat de prijzen altijd via één dossier (bv. het Belgische) aangemaakt en bijgewerkt worden.

Tip: DBFACTw ondersteunt de mogelijkheid bij winkelverkopen om de prijs 'ad hoc' te berekenen op basis van de verkoopprijs incl. btw. In kasverkopen zal dan steeds de winkelprijs incl. btw gehanteerd worden, zowel in Nederland als België.

 

Kassa koppelingen

Het doorsturen van de 'andere betalingen' gebeurt via koppelingen aan de divisie. vandaar dat deze informatie in alle dossiers moet overeenkomen, of toch minstens gekoppeld moet zijn.

Werkstation configuraties

Aangezien deze ondernemingen elk hun eigen 'exclusieve' werkstations hebben, moet u dit best instellen in de werkstation configuratie. U maakt duidelijke afspraken welke stockplaats bij welk dossier hoort, en het best kunt u deze zaken niet mengen

Multistock plaatsen

Ook deze moeten over alle dossiers overeenkomen, omwille van dezelfde redenen als divisie en werkstation configuratie(s).

 

Veel zaken staan gemeenschappelijk, maar hoe bepalen we dan de stockwaarde van een onderneming op zich?

 

Opgelet: de gewone lijsten die de 'totale' stock berekenen, zuillen altijd de stock berekenen over àlle stockplaatsen heen. Ook de stock van andere dossiers worden daardoor meegenomen.

 

Stocktransferten

 

Alles staat gemeenschappelijk, maar hoe weten we welke artikelen tot welke onderneming behoren?

 

De lange procedure...

Wat als u de 'normale document flow' tussen de verschillende dossiers wenst bij te houden? Stel u verkoopt via dossier 1 een artikel voor één stuk. U weet dat u dat moet doorbestellen naar een andere onderneming (dossier 2). Die zal op zijn beurt een bestelbon klant aanmaken, om dan het artikel door te bestellen naar de 'echte' leverancier.

 

Met deze werkwijze moet daarom als document gemaakt worden, en dit per doorverkoop

1.De bestelbon klant (naar echte klant) in dossier 1

2.De bestelbon leverancier (naar dossier 2) in dossier 1

3.De bestelbon klant (van dossier 1) in dossier 2

4.De bestelbon leverancier (naar echt leverancier) in dossier 2

5.De receptie goederen in dossier 2

6.De aankoopfactuur in dossier 2 van de echte leverancier

7.De leveringsbon in dossier 2  naar dossier 1

8.De factuur in dossier 2 naar dossier 1

9.De receptie goederen in dossier 1

10.De aankoopfactuur in dossier 1

11.De levering en/of factuur naar de definitieve klant.

 

Er wordt aldus een overvloed aan (overbodige) documenten gegenereerd, aangezien veel documenten gewoon instaan voor de transfert van de goederen van de ene naar de andere plaats (stocklocatie en daarbij ook dossier).

 

Er is echter een heel praktische oplossing voor het blijvend vasthouden van een eenvoudige administratie. Hier is het de bedoeling om tijdens de maand alleen transferten bij de houden, en op het einde van de maand te berekenen welke artikelen getransfereerd zijn.

Eerst wordt het principe uitgelegd:

 

In plaats van voor iedere verkoop (door-verkoop) al deze transacties uit te voeren, wordt tijdens de periode (typisch per maand) alleen met stocktransferten gewerkt. Daardoor loopt de stock al praktisch zoals het hoort, aangezien de stock van de stockplaatsen apart berekend kan worden.

Op het einde van de maand wordt, adhv de stock transfert werklijst nagekeken welke artikelen, voor welk bedrag, van de ene naar de andere locatie verhuisd zijn. Deze lijst wordt afgedrukt, en ook in de omgekeerde richting wordt de lijst aangemaakt.

Op basis daarvan weten we precies hoeveel waarde aan stock van de ene naar de andere onderneming getransfereerd werd.

 

Door een manueel artikel 'stocktransferten' aan te maken, wordt slechts éénmaal per maand een factuur naar de andere firma gemaakt, met de stocktransfert in waarde voor alle getransfereerde artikelen. Eventueel kan een lijst van de stocktransferten bij de factuur gevoegd worden.

Indien meerdere grootboekrekeningen moeten gebruikt worden, zowel in verkoop als in aankoop, moet u telkens apart een artikel aanmaken, dat verwijst naar de respectievelijke in- en verkooprekeningen. Echter, gezien alle statistieken in DBFACTw makkelijker via het commerciëel beheer verkregen kunnen worden, is het beter om de statistieken daaruit te halen.