Er zit voortgang in ...

Ik kan wel raden waarom dat niet in de Helptekst staat ... Veel te moeilijk uitleggen.

In het agemeen : Er heeft geen konversie kunnen plaatsvinden van Eenheid naar Eenheid. Voorbeeld : van Faktuureenheid naar Voorraadeenheid.

Kan je hiermee uit de voeten ? anders moet ik meer gaan uitleggen ...

Ik ben uitgeuitlegd.

Berny,

Ik weet nog zo net niet of ik hier gelijk in heb (fout enz.). En misschien is dat wel juist omdat het een partikulier betreft. Maar ja, hoe weten "we" dat, als we achteraf e.e.a. bekijken. Dinand zou onmiddellijk zeggen "ja, maar bij ons is dat altijd zo". Goed, buiten het gegeven dat je vandaag misschien niet weet wat er morgen gebeurt, heeft een controlerende instantie daar geen boodschap aan (en weet vast : een accountant slikt dat wèl -> juist het gevaar omdat je denkt dat je het goed doet).

Ik moet eerlijk zijn, ik kan de scenario's niet allemaal bedenken, maar laten we vaststellen dat er legio situaties zijn dat de "partikulier" geen btw van jullie *wil* krijgen. Of dat nu gemeentes zijn, iemand met een schip of een anderszins vrijgestelde, die kan je dus al niet meer onder diezelfde "partikulier" boeken, omdat de inspecteur het onderscheid niet kan zien, zich wel afvraagt hoe het zit met die BTW, en jij vervolgens niet kan aantonen hoe het daarmee zit (in het systeem is volgens mij nergens onderscheid te zien).

Als ik het van de andere kant bekijk - van mij als besteller, dan zijn er weer legio situaties te bedenken om het voor elkaar te krijgen geen btw van jou in rekening te krijgen. Je hoort me niet zeggen dat mij dat bij bol.com lukt (zijn te goed geautomatiseerd zeg maar), maar al die clubs (99.9999%) die e.e.a. handmatig regelen (net zoals jullie dus), brengen eerst redelijk geautomatiseerd de btw in rekening, vervolgens zeg ik "ja maar" (en dan mijn verhaal wat helemaal legitiem is), maak het bedrag over zonder de btw, en krijg de spullen geleverd. ALTIJD. Dus, de automatisering erachter werkt helemaal niet, maar jij als persoon snapt het gelukkig helemaal, bent het met mij eens, en staat het toe dat de btw niet is overgemaakt en levert.
Maar waar sta ik als Debiteur ? nou, gewoon, onder "partikulier".

Natuurlijk, als je e.e.a. allemaal goed weet bij te houden kom ik onder een ander soort Debiteur te staan (zou Debiteur-Schip kunnen zijn, maar niet met naam en toenaam dus), maar omdat er geen adresgegevens zijn is het niet verifieerbaar en is het hommeles.

Mijn probleem bij dit onderwerp is dat "partikulier" zelf -voor zover ik kan zien- geen kwaad kan, juist omdat dit de situatie is dat je altijd wel btw in rekening brengt, en dat moet een inspecteur maar niet erg vinden. Maar verder kan ik dan weer scenario's verzinnen als het crediteren wat een keer aan de orde kan zijn, en waar je zelf eigenlijk al geen kant uitkan (dat wordt ff zoeken in het systeem) lijkt het daarna op geld overmaken aan jezelf, want immers een adres is er niet. Een bankrekening wel natuurlijk (op zich verifieerbaar) maar neem van me aan dat als die aardige inspecteur langskomt (en ooit komt 'ie !), vindt hij dat in eerste instantie helemaal niet erg - vist onmiddellijk een stapeltje van deze dingen eruit, en ben jij aan de beurt om het uit te zoeken, wat in mijn optiek redelijk onmogelijk is. Alleen deze reden al is voldoende om een boete te krijgen voor het niet voeren van een juiste boekhouding, ook al sluit alles verder wel aan. In deze kan ik je melden dat -ook al sluit alles aan- je daarmee nog niet bewezen hebt dat alles juist is, omdat het niet is te volgen. Je kan dus nog net zo hard aan het frauderen zijn en het kunnen ophoesten van 10 gevalletjes "zie je wel het klopt" is niet voldoende omdat je in de andere 990 gevallen de fraude kan hebben gepleegd.

??

Ik weet niet goed hoe het belang hiervan te benadrukken, maar je hebt al wel gemerkt dat ik wel meer van dit soort invalshoeken post, en wat is gebaseerd op praktijkervaring;
Omdat iemand het dacht te kunnen regelen zoals jullie -en wellicht niet beter wetend dan "er is helemaal niets verkeerds aan"- heb ik persoonlijk meegewerkt, tegengewerkt, honderden A4 geschreven, strategieën uitgewerkt, 10tallen en 10tallen gesprekken gevoerd met belastinginspecteurs, accountants en nog meer accountants. Het vertrekpunt was de geautomatiseerde administratie waar wij (of ik) meer mee kunnen dan de klant of de belastingdienst zelf, en waar wij dus inderdaad best het e.e.a. meer kunnen met als basis wat extra programmatuur, en queries die wij wel weten te maken om te achterhalen hoe e.e.a. nu werkelijk in elkaar zit of zat. Als je het hebt over frauderen, dan heb ik (of hebben wij) dat nooit kunnen bewijzen in dit geval, maar we konden ook niet bewijzen dat het niet het geval was. Gewonnen heb ik (jaja) het uiteindelijk wel, en het lijdend voorwerp is er vanaf gekomen met het betalen van de belasting waarvan niet kon worden bewezen dat ze niet behoefde te worden betaald (zo gaat dat). Maar denk beter aan "Uitdeling", want daarop komt het immers neer als onnavolgbare konstrukties leiden tot het eigenlijk betaald moeten hebben van belasting, en als dit leidt tot een miljoentje of wat onnavolgbaar per week is het werkelijk moeilijk om buiten de gevangenis te blijven.
Bij de FIOD zijn er gedurende de jaren (4-5) dat dit heeft gelopen echt een paar overspannen naar huis gegaan, en ook al vond ik het een prachtige ervaring en erg dankbaar werk, ik was niet van plan om het nog eens te doen. Nee zeggen kan je niet als bijvoorbeeld jouw direkteur daarom zou vragen, en Nee zeggen mag je al niet als de Belastingdienst erom zou vragen (zoals het in dit geval gebeurde). Ik kan aldus niet veel meer doen dan iedereen waarbij ik vermoed dat de zaakjes niet op orde zijn in dit licht, van harte te waarschuwen om het op orde te maken voordat het te laat is. Scheelt je tonnen aan fakturen van mijn kant ook nog (geen grapje).
Dat dit dan ergens ver(der) weg ook nog mijn verantwoording is aangaande het administratieve systeem wat he ervoor gebruikt - is min of meer toeval, maar zorgt er wel voor dat ik je *behoor* te waarschuwen voor iets wat ik als "niet lekker" zie, in de zin van "straks heb ik het nog gedaan ook". Kan nooit werkelijk zijn (want je wordt zelf verantwoordelijk gesteld voor je administratie), maar ik wil het gewoon niet op m'n geweten hebben als iets dergelijks gebeurt wat ik zojuist heb beschreven.

Vergeet alsjeblieft ook niet dat je echt geen FIOD inval hoeft te krijgen om e.e.a. goed fout te laten gaan, en dat een reguliere inspectie werkelijk voldoende is om achter een paar onnavolgbare miljoenen te komen die vervolgens door iemand in persoon moeten worden opgehoest.
Zorg dat je het voor bent ...


PS: Belastinginspecteurs zijn gewoon mensen en eigenlijk net zo aardig als jij en ik (). Juist omdat dit zo is, kom je (aan beide kanten) nogal snel met de handen in het haar te zitten als er iets wel goed is, maar niet zo lijkt. Hoe meer dit het geval is, hoe harder de situatie vanzelf wordt (en dat is jouw schuld, want jij had de zaakjes niet op orde). Ik kan dan ook alleen maar benadrukken dat ik op geen enkele wijze wil suggereren dat een belastinginspecteur een boosdoener is. Eerder juist het tegenovergestelde. Ik kan nog niet eens ontdekken dat die mensen ervoor zijn om "met geld terug te komen"; ze doen gewoon hun werk.

Hahaha, dat hoopten we beiden.
Maar na toch weer ruim een uur telefoneren (ik zag m'n weekend al voorbij gaan), denk ik dat we beiden vinden dat we beiden begrijpen wat jij wilt. Of zoiets.

Laten we onderstaand plaatje maar ald leidraad nemen (trouwens, ik heb zo maar wat gedaan in het systeem hier, en er komen allemaal "beton" betalingen voorbij ?? hoe kan dat nou toeval zijn)

E.e.a. onder het voorbehoud van totale afkeuring door Wouter ...

Zoals het momenteel werkt :

De betalingen van de "klant" werken via een Ontvanger. Deze ontvanger (een Debiteur-ID) wordt feitelijk door jezelf aangegeven. Waarschijnlijk treden er mechanismen onder water op die e.e.a. automatisch kunnen bepalen, maar in elk geval ... wanneer ADOVGN (het genereren van de Afschriften) er niet zelf uitkomt (omdat de Ontvanger (nog) niet bekend is), zie in je ADOVRA (zie plaatje) de Afschriften staan die (om die reden) niet konden worden verwerkt. Vervolgens kan je via ADOVWY de Ontvanger aangeven (zie "Debiteur-id").
Het probleem is nu dat de betaling kan worden gedaan door bijvoorbeeld een hoger orgaan -zoals Holding maatschappij van de eigenlijke Debiteur-, en dat deze Holding daarmee logischerwijs ook een betaling kan doen voor meerdere Debiteuren van jou (vallen allemaal onder dezelfde Holding, maar zijn voor jou individuele Debiteuren).
Wat je nu ziet is dat het rijtje fakturen wat in dit geval door Stuytvriezen B.V. wordt betaald, niet bij één Debiteur van jou hoort, en dus het Afschrift als geheel niet onder één Debiteur kan worden verwerkt. Dit moet ook niet natuurlijk.
Wat er verder gebeurt is dat na het invullen van een aan de orde zijnde Debiteur (die volgt uit 1 of meer Faktuurnummers), de betreffende Faktuurnummers worden genoemd in plaats van het rijtje wat meerdere Debiteuren impliceert, waarna het Afschrift voor dit deel kan worden verwerkt.
Ik neem aan dat het bedrag (zie de 9050.77) hierop sluitend moet worden gemaakt, maar zonder dat zou het ook wel werken (er worden gewoon Fakturen tegengeboekt en als Betaald gekenmerkt).

Omdat je dit zo voor alle geïmpliceerde Debiteuren moet doen voor alleen al dit ene Afschrift, ben je wel even bezig.

Het verhaal doet nu de ronde dat het best gebruikelijk is om één Faktuurnummer volledig te noemen, bijvoorbeeld 129784, om de rest 621, 548, 549, 785, 786 te noemen (zie weer plaatje, waar dit overigens niet is toegepast). Er zouden mechanismen aanwezig zijn die op basis hiervan hun werk doen, ofwel, het volledige Faktuurnummer match met de (??) Debiteur, en de rest kan daaruit worden afgeleid.
Wat alleen niét gebeurt, is dat ditzelfde mechanisme wordt gebruikt om de Debiteur sowieso op te selekteren ... Om haar te "kiezen" dus.
Ik vermoed dat e.e.a. wel werkt als alle via dit mechanisme bepaalde Faktuurnummers horen bij één Debiteur, maar niet als dit niet het geval is, zoals de in dit topic beschreven problematiek.
Verder zal het nooit rekening zijn gehouden met een situatie als deze, ook in aanmerking nemend dat in Profit het ooit niet mogelijk was om zulk soort betalingen te doen (namens dochtermaatschappijen enz.), wat ook eens werd ontwikkeld. Dat was de andere kant dus, en nu deze zijde van het verhaal nog ...

Ofwel, wat er lijkt te moeten gebeuren - maar vooral wat lijkt te kùnnen gebeuren, is dat ieder uitgewerkt volledig Faktuurnummer wordt gematched met bestaande Fakturen, die aldus zal behoren bij een bestaande Debiteur (waar we ooit de Faktuur naartoe hebben gezonden), opdat e.e.a. alsnog automatisch kan werken.

Laten we er maar eens vanuit gaan dat we dit stukje wel voor elkaar kunnen krijgen. Maar om te zien hoe e.e.a. funktioneel uitpakt, moet ik denk ik eerst terug naar wat Dinand wilde (via laatste telefoongesprek) :

In onderstaande plaatje vullen we Debiteur-id in, en noemen op de regel de betreffende (dus bijbehorende) Faktuurnummers in. Dit dan wel volgens het principe van 1 volledig nummer en de rest "afgekort". Gedaan ? volgende Debiteur.
Let wel, en let op, want dit heb ik eerder in dit topic beschreven als : en dan genereer je de Afschriften opnieuw, die vervolgens jouw gewijzidge regel meenemen, en dus werkt het bij een volgende poging.
Echter, deze werkwijze was meer gebaseerd op het "Zie specifikatie" voorbeeld, en dacht te veel aan één benodigde ronde hiervan, waar we het er nu over meerderen hebben (net zoveel als dat er verschillende Debiteuren worden geïmpliceerd). En *nu* zie ik niet hoe dat moet werken, waar een Afschrift immers een Afschrift is, en je hier gaart bewerkstelligen dat er meerdere regels in ADOVRA gaan bestaan voor één Afschrift(regel).
Of dit erg is - of al intrinsiek aanwezig is weet ik niet, maar *dit* is in elk geval het nog resterende probleem.

Terug naar de zojuist beschreven oplossing, zie je dat e.e.a. samenkomt in dit probleem, als je van een Afschrift weliswaar 4 Fakturen hebt weten te vinden en hebt weten te presenteren in het ADOVRA overzicht, maar 2 anderen niet konden worden verwerkt. En dan nog om 2 verschillende redenen ook ...

Als we nu nog weer eens het plaatje bekijken, zien we al dat e.e.a. voor zoiets niet is gemaakt. Immers, ADOVWY toont dat we met het originele Afschrift bezig zijn (althans, origineel zoals de betreffende regel is gepresenteerd door de bank), en dat we alleen op dat niveau iets kunnen, welk niveau niet het onze is. Niet meer, want wij "moeten" iets met individuele Faktuurnummers.

Of je nu mijn volledig automatische verwerking van nu (zie boven) neemt, of het mindere mooie van het door mij met Dinand jl. vrijdag bedachte ... beiden lopen vast op ADOVRA die hiervoor hiet is gemaakt.
Het volledig automatische geeft dan nog de beste mogelijkheden, omdat dat immers er toe zou kunnen leiden dat alles wordt gevonden, en ADOVRA alleen maar "kan worden verwerkt" regels toont. Maar ja, daar kunnen we niet vanuit gaan.

Laten we maar zeggen dat het bovenstaande allemala redelijk degelijk is, terwijl het onderstaande te veel een brainstorm zal zijn ...

Volgens mij moet het een soort van andersom. Soort van, niet echt;
ADOVRA blijft zoals ze is, doch het "Kommentaar" in de zin van "reden van afkeur" moet meer specifiek worden en eigenlijk gaan verwijzen naar een achterliggend overzicht (per regel) wat op Faktuurniveau werkt. In dat overzicht (als zijstap op te vragen per Afschriftregel) vinden we de bepaalde (volledige) Faktuurnummers, en per Faktuurnummer weer Kommentaar zoals in ADOVRA. Let wel, de redenen van afkeur die we in dit zijstap overzicht vinden (laten we het maar even ADOVUFRA noemen), zijn bepalend voor wat in ADOVRA wordt getoond. Niet andersom dus. Anders gezegd, als ADOVUFRA een "Geen te gebruiken Faktuurnummer gevonden" toont, en via een ADOVUFWY wordt dit omgezet naar een wel te gebruiken Faktuurnummer, dan zorgt dit op het hogere ADOVRA niveau ervoor dat aldaar het overeenkomstige Kommentaar (zie de in de praktijk bestaande voorbeelden) verdwijnt (of in elk geval consistent wordt met de samenvatting van alle onderliggende "faktuurregels".

Volgens mij komt het er ook op neer dat waar het "Verwerken Afschriften" nu op basis van ADOVRA werkt, dit zal moeten gaan werken op basis van de nieuwe ADOVUFRA. Dit kan (volgens mij) niet anders.

Er zijn, vrees ik, nog wel meer implicaties, althans, meer tijdrovende zaken om e.e.a. duidelijk te houden. Zie als voorbeeld de "Reeds ontvangen - zie Volgnummer 67" in het plaatje, en je voelt wel dat als we dit zo laten, jullie als gebruiker dat straks niet meer begrijpen omdat Volgnummer 67 meerdere Fakturen heeft waarvan er wellicht 1 al is ontvangen, terwijl Volgnummer 189 zelf eveneens meerdere Fakturen heeft en de mededeling over één van die Fatuurnummers zal gaan, of zelfs meerderen. Of gewoon allemaal. Hiervoor moet je dus feitelijk in ADOVUFRA zijn, die aldaar moet kunnen doorverwijzen naar ten eerste een andere ADOVUFRA regel (van een ander Afschrift dus) en waarbij je ten tweede binnen ADOVOFRA een soort van "ADOVRA overzicht" (als in het overzicht hebben) wilt hebben.
Als dit allemaal niet juist wordt onderkend, word je helemaal gek (want je kan niets terugvinden), terwijl je ook nog eens bezig bent met uit te lokken dat je vanaf het begin niet hebt begrepen wat er gebeurt (wat nu niet kan gebeuren, want het wordt domweg afgekeurd, en vervolgens los *jij* het probleem op, en niet het onderwater-systeem-wat-niet-is-te-volgen).

Als het allemaal werkt is het volgens mij wel een stuk verbeterd ...

Ok, niets aan de hand. Sorry ...

Nou, ik ook intussen. Maar alleen na nog eens een telefoontje;

Het blijkt (mijn schuld, ik wist het gewoon niet) dat de Bedrijfsparameter die er momenteel is, een "waarschuwing" geeft als er een te groot bedrag in de Batchboekingen wordt geplaatst. Deze waarschuwing staat dus niet toe om het betreffende af te breken (en da's maar goed ook, en op zich waar ik eerder op doelde (moet gewoon doorgaan)). Waar Dinand het over heeft is om tevens -en dit is dus nieuw- ervoor te zorgen dat te grote bedragen niet worden doorgeboekt naar het Grootboek.

De trigger voor het tegenhouden van het laatste, vergt dus die nieuwe Bedrijfsparameter, maar betreft aldus ook iets heel anders dan waarvoor de momentele Bedrijfsparameter is.

Is op zich wel een goed idee, maar ook niet helemaal praktisch denk ik. Ja, als je per Interface (bijv. LOPOGM) doorboekt wel ...
Ik zal er eens over denken.

Trouwens, als je bedoelt dat je last hebt van iemand die er een beetje doorheen loopt te posten ... snap ik. Maar ik heb dat expres zo gelaten (had er ook een nieuw topic van kunnen maken), omdat het wat mij betreft dezelfde problematiek betreft (goed gezien Berny).
Laat ik het zo zeggen : ik zie het verschil niet zo met iemand zoals jij die Piet laat betalen waar Jan de faktuur krijgt, of die "Partikulier" laat betalen waar het eigenlijk Jan is.

Beiden is eigenlijk - en op dezelfde wijze fout en waar jij of jullie dat niet willen begrijpen, moet ik er dus wat van zien te maken. Je weet intussen (sinds gisteren) dat het me echt wel gaat lukken om een belastinginpecteur "jou" te laten opdraaien voor iets wat je zelf echt wel goed vond.

Nou, het zal wel.

Dan moet er een nieuwe Bedrijfsparameter bij. 4 uur dus.

Eh, mogen we alsjeblieft nog wat meer dingen doen hier ?

Daarnaast, waar doel je nu eigenlijk op ?

Sorry, hier had ik een bij willen zetten. Maar die vergat ik in de "haast".

Fouter dan fout.

O, ik dacht dat we het daar gisteren al over hadden gehad. En dat jij daarom ineens Twents begint te praten hier. Haha.

Oh, dat vond je nog wel even nodig om te noemen heh ?

Ik zou even oppassen wat je zegt ...