Tja, jij bent "Moneymaker" ... ik niet ...

Er draait al een bal, maar om eerlijk te zijn : ik zou zeggen dat die er bij in hoort te zitten ...

Pascal,

Naar mijn persoonlijke idee wordt dit niets. En volgens mij gebruik je dit ook niet iedere dag. Of ?

Wat ik wel zie zitten is dat je een nieuw Kontrakt maakt voor wat betreft de header (dat doe je dus zelf) en dat je vervolgens een toets bij Raadplegen Kontraktregels (die er op dat moment nog niet zijn) krijgt die de regels van een ander bestaand Kontrakt kan inkopiëren. Kan dan nog wel getagd ook.
Denk aan 7 uur.

Als we het zo doen, dan realiseer je je in elk geval dat alle sh*t met HPP of wat dan ook door jezelf handmatig nog moet worden gemaakt.
Dus als je dit wat vindt ...

Later ... Nee. Werkt nog steeds niet. Immers, je hebt de DKKs dan nog niet en die krijg je er ook niet meer in. Om dit goed te laten gaan durf ik zo maar al 6 uur meer te rekenen ... en dat is vast te weinig ...

Misverstandje Pascal. Ik doelde op de "Alg" c.q. die riedel funkties. Dus, die funkties moeten bij een tabblad horen. Je moet dus de funktie(s) kiezen die je wilt en dan per tabblad.
Vervolgens zullen ze bij alle paden naar diezelfde funktie wel werken, tenzij wij ergens zien dat dat niet mag of kan. Maar als we niets doen werken ze via alle paden dus.

Sorry voor het misverstand. Nu duidelijk ?

Nee, je moet er niet vanuit gaan dat dit gaat werken. Immers, het impliceert diverse "overschrijvingen" in de Verkooporder zelf die je ook niet in beeld hebt. Dus in het algemeen : Zijstapjes zijn per tabblad heus toegestaan, maar moeten altijd met gegevens op dat betreffende tabblad te maken hebben. Hier is dat dus niet zo.

Eigenlijk moet je dus zeggen welke je precies wilt en dan per tabblad. En houd er maar vast rekening mee dat het duurder is dan je vermoedt (kan best 3 uur zijn voor één zo'n zijstap, afhankelijk van wat je wilt).

Heb je hier niets aan ?
(rightclick op het gegevens veld doen)

En niet om het één of ander, maar je moet je maar eens afvragen hoe je e.e.a. "te gemakkelijk" zou inrichten als je met DKKs aan de gang gaat voor bijvoorbeeld transport vanaf zo'n willekeurig land. En volgens mij is dat het eerste wat je nodig hebt (DDKs daarvoor). Dus, zo'n DKK leg je op Landkode, maar voorlopig bepaalt je Magazijn (lees : Raaplvloer zou ik zeggen) waar vandaan je deze keer levert. En dus is het je Magazijn wat de Landkode bepaalt. En voor de goede orde : in deze hoek bevinden zich dus die "honderden" funkties.

In het licht van wat Wouter zojuist heeft verteld kan ik ook nog wel een (weliswaar vergezocht) nadeel noemen als je alles netjes registreert zoals het is : als je een klant belevert vanuit twee havens in verschillende Landen op dezelfde Verkooporder, gaan er volgens mij twee fakturen uitkomen omdat de Landen niet overeenkomen. Dit is omdat je theoretisch te maken hebt met verschillende BTW percentages, die echter buiten de EU helemaal niet aan de orde kunnen zijn ...
Maar goed, zoiets valt dan nog wel aan te passen ook.

Als laatste nog even de opmerking dat Landkodes best wel 2 posities zijn. Niet helemaal waar natuurlijk want het volgnummer is er ook en is er niet voor niets, maar je moet behoorlijk moeilijk doen om het volgnummer *nodig* te hebben om het niet fout te laten gaan. Dus je kan best de Magazijnen gelijk aan de Landkodes definiëren, op een paar uitzonderingen na. Dit betreft (misschien niet uitputtend) :

a. Leveren in verschillende delen van bijvoorbeeld Spanje waar het ene deel wel BTW plichtig is en het andere niet;
b. Je hebt het Magazijn volgens de Landkode zelf al in gebruik;
c. Je doet iets met de eerste letter van het Magazijn in het systeem, en nu klopt dit in voorkomende gevallen niet.

In de gevallen waar je de betreffende Landkode niet kan gebruiken moet je dan een kodering bedenken (00 t/m 99 bijvoorbeeld), met als meest stringente geval c (dan kom je er te vaak niet uit).

Wie zegt nou dat Johan geen BTW *wil* ? Hij heeft alleen aangegeven het niet te begrijpen.
En begrijpen ga je het nooit als je maar blijft doorgaan met het veranderd zijn van een "zetel". Alsof die verandering er iets mee heeft te maken. Niet dus.


Dit heeft ook geen nut. Zo dacht ik eerst (bij mijn "foute" post) ook. Ofwel, definieer "levering". Daarom helpt dat BTW nummer bij het Afleveradres ook niet; ik lever (definiëren !) weliswaar aan die Belg, maar er moet echt wel BTW op de faktuur aan mijn Nederlandse klant.


Geef maar eens een voorbeeld van ieder waar het 100% NODIG zou zijn als praatplaat. Lijkt , is het misschien deels ook, maar volgens mij voldoende nuttig omdat ik me afvraag of er wel iemand is die het begrijpt (en of ik het ga begrijpen, haha).

Dat ging het toch al niet. Kan gewoon niet. Al dit soort zaken worden door het Magazijn bepaald, en nooit door een Lokatie. Honderden funkties werken daarmee.

Tja, helaas breng je me nu op iets wat ik zelf even niet begrijp;
Het lijkt "mooi logisch" om de Landkode op het Magazijn leeg te laten om vervolgens per Lokatie een andere Landkode in te "kunnen" vullen, maar als je bij het Magazijn wel een Landkode invult kan dat ook. Ofwel, in mijn ogen klopt er iets niet, of weet ik gewoon iets niet. Feit is (dacht ik hoor) :

Al dit soort zaken werken op Magazijn, ofwel de Landkode op Magazijn. Als dit alsnog door de Lokatie kan worden overruled kan je het doen zoals jij voorstelt, maar daar geloof ik vooralsnog niets van. Dat moeten we dus uitzoeken ...
Sorry, maar hier stopt het dus toch even.

Hebben jullie nog kontakt gehad ? (Wouter is er niet vandaag)

Mijn idee even :


Het beste zou toch zijn om per lokatie vanwaar je inkoopt (maar per land is voldoende) een Magazijn te maken met die Landkode. Maar denk zo :
Stel dat je in Taiwan iets inkoopt en jouw boot naar Singapore vaart, dan hoef je wat mij betreft geen Singapore als Magazijn te hebben als jouw leverancier in Taiwan zit en je het eigenlijk hebt gekocht (en op dat moment van jou is) voordat het de boot op ging. Anders is het als je pas koopt als de boot is aangemeerd in Singapore. Dan kan je daarvoor een Magazijn maken. Waar het om gaat is dat je kan aantonen dat e.e.a. nooit in de EC is geweest en hoe dat pad precies is gelopen is niet van het meeste belang. Maar als je het goed wilt doen (en dat is niet te moeilijk denk ik) doe je het zoals bovenomschreven.

Als je nu vanaf die kade verkoopt aan iemand in Hong-Kong dan gaat alles vanzelf goed. Ik zou ik niet weten wat je ervoor hoeft te doen (paperassen), zolang je maar nergens onderweg een EC land raakt. Invoerrechten of hoe ze het ter plaatse ook noemen worden vanzelf bij je klant in rekening gebracht.

Edit : Overal waar ik hieronder over "EG" praat is dit niet juist en moet worden vervangen door "EC" (European Community) ofwel EU (Europese Unie). EG en EC lijken wel hetzelfde, maar voor het genoemde "exporteren" is dat niet het geval.

Ik zei al, ik kan het niet volgen. Ten eerste is mijn reaktie gewoon fout. Lees maar goed - slaat nergens op omdat het immers suggereert dat er dan *geen* BTW in rekening wordt gebracht terwijl dit wel moet. Wouter heeft dat in zijn eerdere posts goed aangegeven. Waar ik in trap zijn de verdere reakties en wil ik me er ook sterk voor maken dat Johan nu Ja invult bij ABC transaktie en nu tevreden is. Indien waar : Johan, dat is dus juist fout.

De verwarring onstaat ook gemakkelijk bij die "Opdracht tot Export" en waarbij deze bedoelde export GEEN export betreft als je het over BTW plichtige EG landen hebt. Het fenomeen "export" is nu dus wazig. Ik durf nog wel iets verder te gaan met de stelling dat het verhaal (in elk geval in dit topic) niet kompleet is, omdat ik niet zou weten waarom ik onze Nederlandse klant A moet vrijstellen van BTW als ik zelf de leverancier ben van "in het vrije handelsverkeer ingebrachte goederen" (!!). Mijn space cake is dat per definitie, als op voorhand bekend is (!) dat deze binnen de EG blijft (formeel is er dan nergens een Opdracht tot Export ter sprake). Merk in deze ook op dat mijn klant A geen moeite zal hebben met die BTW, want die vraagt hij gewoon terug. Dat klant A aan zijn Belgische klant B (die een (Belgisch) BTW nummer heeft) geen BTW in rekening brengt is heel wat anders, doodnormaal, en staat dus helemaal los van alles. Het verhaal wordt pas anders als klant A exporteert naar een niet EG land zoals Noorwegen maar JIJ dat doet middels rechtstreekse levering. Nu geldt volgens mij de regel dat het produkt nooit in het vrije handelsverkeer is geweest en zou jij geen BTW in rekening brengen bij klant A (en klant A brengt geen BTW in rekening bij zijn Noorse klant C omdat het export buiten de EG betreft). Fijn, maar ik snap het verhaal alweer niet meer omdat er wederom geen reden is om die BTW gewoon wel in rekening te brengen bij klant A. Die krijgt het echt wel weer terug (maar zou het wel jammer van z'n liquiditeit kunnen vinden).

Volgens mij is de moraal van het bovenstaande dat als we bij zo'n voorbeeld een Opdracht tot Export hanteren, we vast wel doen wat we denken dat goed is, en het nooit fout gaat. Dus van de andere kant benaderd : als ik een faktuur krijg van een Nederlands bedrijf met BTW dan interesseert het me echt helemaal niets of dat misschien zonder had gemoeten of gekund. Ik vraag de BTW terug - klaar.

Het lijkt een ander verhaal te worden als ik goederen importeer uit een niet EG land (!) maar die (nog) niet inklaar. Als deze goederen doorgaan naar Noorwegen hoeven ze ook nooit te worden ingeklaard. En let wel, het is nu de overheid (douane) die de BTW niet in rekening brengt, en *daarvoor* heb je wel even speciale papieren nodig. Als ik nu die goederen (die ik in Taiwan heb ingekocht) doorstuur naar Noorwegen, zijn ze nooit ingeklaard geweest (en nooit in dat "vrije handelsverkeer" gekomen). BTW breng ik weer niet in rekening bij die Noor, maar dat heeft er weer niets mee te maken.
Waar het -voor mij dan- intussen wel mee te maken heeft is dat ik in dit laatste voorbeeld wederom niet kan volgen waarom het ooit erg zou zijn om BTW in rekening (van de douane) te krijgen. Immers, ik vraag ook dat gewoon weer terug. Nu is er echter één verschil : Invoerrechten. Dus *dat* is de reden dat ik niet inklaar en dat ik daarmee ook meteen geen BTW aan m'n broek krijg - zal wel. Dus voor zover ik het zelf kan volgen : in deze hoek zit de Opdracht tot Export ergens en waar de ABC transaktie uithangt heb ik nog nooit geweten.

Kommentaar welkom !

Dit is een beetje voor de lol hoor. Gewoon, omdat ik zelf die ABC transaktie nooit heb begrepen, en zoals Marco al zegt "je bent er zelf verantwoordelijk voor dat het goed gaat" (strekking). Maar als ik deze wazigheid lees :


... dan denk ik ineens dat het simpeler moet kunnen. Of beter eigenlijk. Ofwel :

Wat zou er op tegen zijn om bij het Aflevradres, wat jij als Nederlands bedrijf (en Profit gebruikert) toch zou moeten hebben van die Belg aan wie je rechtstreeks levert (want dat is het) het BTW nummer van die Belg kan ingeven ? Het wordt m.i. dan een doodnormale "BTW volgt de goederen", en volgens de Intercommunautaire regelgeving wordt er dan geen BTW in rekening gebracht (ehm, mits je maar in het buitenland levert). Dan kan je nog wel onderwater die ABC transaktie tirggeren voor geen-idee-wat of welke rapportage (als die al bestaat), maar het gaat erom dat je het btw nummer (desnoods door jezelf geverifieerd) van die Belg hebt. Dat is niets anders als dat je ook die faktuur naar die Belg zou sturen (lees : er is ineens niets vreemds aan).

Toch ?

Er zal wel uit te komen zijn, maar je komt er *zelf* niet uit. Wij ook niet, maar dat komt omdat het "eeuwig" tijd komt om te onderzoeken wie/waar/wat welke mogelijkheden biedt.

Zelf denk ik in elk geval dat je het niet in de PDF hoek moet zoeken maar in HTML. Dit op zich kan wel (gaat ook goed met de kolommen), maar of je het zelf kan - ik denk het niet.
En dan wil je natuurlijk ook nog graag die HTML in een PDF verzenden en ehhh ... veel plezier. Dan moet je dus een "VeryPDF" zoeken die HTMP kan omzetten naar PDF en dan ook nog aan de praat zien te krijgen. Weet dan dat wij gerust weken bezig zijn geweest om - ook met de hulp van andere gebruikers op het forum - iets als VeryPDF lekker te laten werken, en wat niets met Profit van doen heeft. Je moet gewoon heel veel weten en zoeken en prutsen, en je weet het resultaat pas als je bent uitgeprutst. Werkt niet lekker ? op naar de volgende oplossing.

We kunnen maar beter dit zeggen :
Bekijk de ingekomen fakturen van iedereen en dan niet die zjin ingetypt in een Word dokument, maar die uit computersystemen komen. Dan zie je wel wat Wouter bedoelde en dat het doodnormaal is om die dingen er wat "geautomatiseerd" uit te laten zien. Dus, niet druk om maken ?

Heeft het daar niets mee te maken dan ? Ik bedoel, er is niets apart overgestuurd wat dit kan veroorzaken ?