case probleem

[Achiel]

beste users,

ik zit met een netelig probleem bij opmaak van een case.

in de offerte bij een verbouwing bij het aanmaken van offertelijnen werkt alles prima, doch wanneer het een nieuwbouw is blijft het systeem onderscheid maken tussen 6 en 21%, wat niet de bedoeling is, alles moet dan aan 21% verrekend worden.

de case-functie is als volgt opgemaakt.

 

Case(

ref-btw="21";21;

ref_btw="6";6;

ref_soort_artikel_t="spoeltafel";6;

ref_soort_artikel_t="kraan";6;

ref_soort_artikel_t="dampkap";6

)

 

zou er iemand een tip kunnen geven?

alvast merci.

[Optic]

Ehm, alle offerte regels hebben een apart BTW tarief maar als het nieuwbouw is moet er 21% berekent worden over alle regels?

[Achiel]

Ehm, alle offerte regels hebben een apart BTW tarief maar als het nieuwbouw is moet er 21% berekent worden over alle regels?

Yes,

er zijn 2 mogelijkheden:

ofwel alles 21% bij nieuwbouw,

ofwel alles 21% bij verbouwing, met uitzondering van sp, kr en dk die altijd de 6% tariefering volgen.

voor de rest zijn er nog andere 'soorten' die steeds 21% btw behoeven.

[Rony Rabijns]

Zo kan het werken:

 

Case(

ref_soort_artikel_t="spoeltafel";6;

ref_soort_artikel_t="kraan";6;

ref_soort_artikel_t="dampkap";6;

21

)

 

Maar persoonlijk zou ik het heel anders doen.

Ik heb momenteel een 50-tal keukenpakketten draaien waar de berekening heel anders gebeurd. Ik kan je de oplossing niet aanreiken maar bedenk dat jouw oplossing taalgevoelig en hard-coded is. Met het oog op onderhoud en wetswijzigingen, is dat niet slim op lange termijn.

[Rony Rabijns]

Met het oog op onderhoud en wetswijzigingen, is dat niet slim op lange termijn.

 

Op verzoek (via de wandelgangen) even wat meer uitleg bij eventuele valkuilen:

 

Wat als er "soorten" bijkomen die voldoen aan de 6%-regel?

Of indien er soorten wegvallen?

Wat als het BTW-tarief van 6% wijzigt?

Wat als je niet consequent data hebt ingevoerd? Dan denk ik aan tikfouten in de benamingen bvb.

Wat als je franstalige of anderstalige klanten hebt?

Wat als je met export-klanten zit? Dan is er vaak geen BTW noodzakelijk.

Wat als je aan medecontractanten levert?

 

Wellicht denk je nu: "Dat heb ik niet nodig." Maar geloof me, je zal het sneller nodig hebben dan je zou kunnen vermoeden.

[Achiel]

°betreft de groepen: deze kunnen aangevinkt worden via de artikellijst en zijn uiteraard opgenomen in deze case.

°btw 21-->6% regeling: zie ik direct niet gebeuren, gezien de economische situatie, indien wél, moet dit toch in fm aanpasbaar zijn, of zijn hier dan ongelofelijke tricks voor nodig?

°tikfout benamingen is mijn inziens uitgesloten gezien de keuze bepaald wordt via een invoerlijst.

°met vertalingen hou ik voorlopig, gezien vooral nederlandstalige klanten, weinig of geen rekening, tips zijn uiteraard welkom.

°export klanten. ik overweeg om een bijkomende 0% tarief in te voeren.

°medecontractanten is minder van toepassing, wél commissies.

[BDK]

°btw 21-->6% regeling: zie ik direct niet gebeuren

 

misschien niet direct, maar het gaat een keer gebeuren en dan heb je een probleem.

 

waarom niet gewoon een aparte tabel met BTW-definities; kleine moeite groot plezier en op alles voorbereid.

 

groet, bdk

[hiker]

Maak een extra tabel met BTW hoog, laag en nul en verwijs hiernaar vanuit je artikelen. Als een BTW% veranderd hoeft er slechts een getal aangepast te worden.

Als een artikel van BTW tarief veranderd moet dat uiteraard altijd aangepast worden, welke oplossing je ook bedenkt.

[Bruno]

Een ander goed idee is eens samenzitten met een boekhouder aan een boekhoudpakket om het inboeken van facturen te bestuderen.

Een bestelbon of orderbon/pakbon is niet anders dan een gedetailleerde factuur.

Rony heeft gelijk: er zijn zoveel BTW-regels in de bouw dat je je database maar beter voorbereidt op alle mogelijkheden.

Bekijk eens alle uitsplitsingsmogelijkheden in een boekhoudpakket.

[Achiel]

Een ander goed idee is eens samenzitten met een boekhouder aan een boekhoudpakket om het inboeken van facturen te bestuderen.

Een bestelbon of orderbon/pakbon is niet anders dan een gedetailleerde factuur.

Rony heeft gelijk: er zijn zoveel BTW-regels in de bouw dat je je database maar beter voorbereidt op alle mogelijkheden.

Bekijk eens alle uitsplitsingsmogelijkheden in een boekhoudpakket.

Ik splitste de btw tarieven inmiddels uit in een aparte tabel (medecontractant, nieuwbouw en verbouwing), paste de case-functie aan (naar voorbeeld van Ronny), doch verkrijg niet het gewenste resultaat. Indien er in de projecten-tabel een btw wordt bepaald, werkt het systeem wél bij 6%, maar niet bij 21%. Bij deze laatste optie blijft de offertelijn onderscheid maken tussen 6 en 21%, wat uiteraard niet de bedoeling is.

Iemand een idee?

[Rony Rabijns]

Toon je case() nog eens. Of post eventueel een kopietje van je bestand.

[Achiel]

Toon je case() nog eens. Of post eventueel een kopietje van je bestand.

Case(

Ik stuurde in:

ref-btw="21";21;

ref_btw="6";6;

ref_soort_artikel_t="spoeltafel";6;

ref_soort_artikel_t="kraan";6;

ref_soort_artikel_t="dampkap";6

)

en dit werd gecorrigeerd:

Case(

ref_soort_artikel_t="spoeltafel";6;

ref_soort_artikel_t="kraan";6;

ref_soort_artikel_t="dampkap";6;

21

)

situatie is als volgt:

projecten/offertes/offertelijnen meubels, toestellen ea.

 

hoe kan dit opgelost worden?

[Rony Rabijns]

Of post eventueel een kopietje van je bestand.

[Ari]

Even een opmerking naar (Filemaker) applicatiebouwers in het algemeen:

 

Bouw je voor de hobby of eigen bedrijf?

Het beste is natuurlijk een generieke oplossing met een goede normalisering van het datamodel. Maar aangezien het je eigen applicatie is en je weet waar de 'hardcoded' zaken zitten kom je er wel mee weg.

 

 

Als het voorbeeld van Achiel bedoeld is voor een klant:

Ga direct naar de gevangenis, ga niet langs af, u ontvangt geen € 2000,- !

Neem je verantwoordelijkheid en ken je beperkingen. Je verwacht van je aannemer toch ook dat de fundamenten van je huis goed zijn gelegd?

[pjotter]

Als het bestand voor nederland is dan kan het inderdaad lastig zijn. Je zou zoals er al wordt voorgesteld moeten werken met een aantal global velden. 0,H, L en B. Hier geef je dus in welk tarief op dat moment van toepassing is. (0% , BTW_hoog, BTW_Laag en BTW_bijzonder tarief ) Bij verandering van dat tarief hoef je dus alleen die 4 velden te veranderen.

 

Nu je vraag over de case zet eerst goed op papier voor je zelf wat de voorwaarden zijn voor hoog en laag en bijzonder tarief. Ik geef een voorbeeld van een mij bekend probleem van 2 jaar terug.

EHBO materiaal valt onder geneesmiddelen echter als je een ehbo doos lever compleet dan zit er BTW_hoog op. Als je verbandmiddelen levert om de verband doos weer op te vullen dan zit daar 6% op. Als ik als goudsmid sieraden maak met materialen die worden aangeleverd dan is het BTW_Bijzonder tarief (nu 12,5%)

De praktijk is echter dat men vaak voor H of L gaat bij de fakturen,

[Achiel]

Het zou de bedoeling zijn om dit in .be te gebruiken, hoelwel ik zou overwegen om een "vrij in te vullen" veld aan te maken om eventuele buitenlandse bestellingen te kunnen berekenen.

In bijlage de opzet:

probeer.fp7

[Achiel]

Het zou de bedoeling zijn om dit in .be te gebruiken, hoelwel ik zou overwegen om een "vrij in te vullen" veld aan te maken om eventuele buitenlandse bestellingen te kunnen berekenen.

In bijlage de opzet:

probeer.fp7