Heart-Profit ERP

Bij 7-3-3-1 en dan het bankafschrift inlezen. Dan worden de ontvangsten verwerkt door HP. Dit werkt prima. Het systeem kan veel combinaties thuisbrengen bijv. klant betaald fact. 167111, 167123, 167500 en 167950.  De klant verweld dan o.a. nr. 16711, 123, 500 en 950 dan worden de genoemde facturen gewoon netjes verwerkt. Of klant vermeld t/m 167950 dan worden ook de genoemde facturen verwerkt. Mooi stukje werk.

Echter er zijn meestal ook enkelen ontvangsten die niet verwerkt kunnen worden omdat er bijv in de betaalomschrijving staat "zie specificatie" of de factuur is van een andere debiteur. etc.
Nu kun je dit bij 7-3-3-2 en dan op betreffende ontvangstregel gaan staan en middels F5 dit invullen. Echter daar moet ik wel alles netjes en volledig vullen.
Bijv. klant X betaald 500 euro en vermeld in de omschrijving zijn eigen nummers, evt. andere codes en dan ons factuurnummer.  Deze factuur is middels de ontvangstnamen gekoppeld aan debiteur X. Stel dat deze factuur niet van debiteur X is, maar van Y. (zelfde bedrijfsnaam, maar ander filiaal) dan moet ik bij dit scherm niet alleen de debiteur wijzigen, maar ook zijn eigen genoemde nummers en andere informatie in de betaalregel weghalen.
Ook moet ik als een klant bijv. 25 facturen gelijk betaald de hele nummers intypen en kan ik niet volstaan met bijv. fact 167111, 123, 500, 950. (etc.) 
De vraag is concreet: Is het mogelijk dat je bij scherm 7-3-3-2 na wijziging van debiteur id of na ingeven van verkorte nummers dezelfde verwerking hanteert dan op het moment dat het bankafschrift wordt ingelezen en dat het systeem zélf ziet dat het dan weer die nummers zijn?

Beste Dinand,

Helaas kan ik jou niet verder helpen, echter mijn vraag aan jou c.q heart is, hoe werkt deze module. Werk jij bijvoorbeeld met de rabo??

mgr Berny.

Beste Peter,

Zou ik deze module eens mogen proberen.....
Krijgen momenteel veel ideal betaling van onze website binnen.
Dit wordt als samengestelde boeking gezegd op het bankafschrift, in de specificatie staan veel kleine bedragen, welke mijn collega nu met de hand afboekt, maar eigenlijk vind ik dit niet handig.

Of het afletteren zie andere topic moet beter werken maar misschine is dit wel het onderzoeken waard...

Hallo Berny,

Je mag die module proberen hoor (Profit-Fin-Betaal), maar ik vermoed dat we eerste te maken zullen hebben met die zaken uit dat andere topic. Bijvoorbeeld ... je zal die Debiteuren toch vaak nog niet in het systeem hebben staan (lijkt op Dinand's probleem) ?

Daarnaast verwacht ik best wel problemen met jouw klanten die maar een beetje wat doen met die omschrijving (9 van de 10 of zo) en dat werkt dat ook weer niet. Maar zeg dat zelf maar, want dat weet jij beter.

Ik vind het in elk geval wel een uitdaging om het aan het werk te krijgen, want als de wereld werkt zoals ze werkt, waarom niet (ook al lijkt het wat moeilijker). Maar vergeet ook niet dat je het eerst procedureel voor elkaar moet hebben, en dat heb je niet (andere topic).  Ik wil hiermee alleen maar zeggen dat het nu dus onnodig moeilijk doen is voor jullie. Tenminste, dat lijkt me toch ?

Goed, vragen voor nu :

1. Hoe vaak (aantallen en % graag) zit de Debiteur al in het systeem ?
2. Hoe vaak (idem) ziet de omschrijving er dusdanig uit dat het systeem er niets mee zal kunnen ?

Dinand, ik kan het maar moeilijk volgen. Wat je probleem is begrijp ik wel, maar hoe je het wilt oplossen niet. Bijvoorbeeld, eerst vergeet de Debiteur het faktuurnummer te vermelden, en daarna vind jij dat je "alles moet intypen" ? Deze laat ik nu even links liggen, want kreëert VOOR NU verwarring. Dus, gaan we later mee door.

Nu die andere ... Debiteur is een andere. Tja ...

Wat wil je hier eigenlijk, en hoe doe je dit normaal gesproken ? Ga je die ontvangst doodleuk op de verkeerde Debiteur boeken ?
N.b.: "Verkeerd" is vast wel een gerelateerde, dus het is niet verkeerd in de zin van "klopt van geen kant". Hier ga ik dan ook vanuit.

Volgens mij kan je niet zo maar een ontvangst boeken waar je geen order tegenover hebt staan, noch kan je de ontvangst boeken op een ander Debiteur-ID. Het laatste lijkt me evident, maar het eerste kon jij wel eens toestaan (lees : zo los je het nu op).
Ik vind aldus dat we wat dit onderwerp betreft eerst maar eens moeten uitzoeken wat hier wel en niet hoort/mag, om vervolgens de oplossing te bepalen. Oh, die zal je te duur kunnen vinden, maar dan hebben we in elk geval uitgewerkt wat er mogelijk is en/of nodig is - eigenlijk. En iets wat niet is toegestaan (inspectie e.d.) gaan we toch maar niet doen dacht ik ...

Het volgende ligt nu voor :

Het probleem met de "zie specifikatie" zou moeten kunnen worden opgelost door in het resulterende overzicht (gegenereerde Afschriften) te kunnen wijzigen, om de run vervolgens opnieuw te draaien die dan de aangebrachte wijzigingen meeneemt als zouden ze (de faktuurnummers) er vanaf het begin zo hebben ingestaan.

Het probleem met de onjuiste Debiteur kan worden opgelost door na het zien van het resulterende overzicht de Ontvangstnaam aan te passen naar de juiste, om vervolgens de run opnieuw te draaien.
N.b.: Dit gaat fout als er betalingen tussenzitten van twee B.V.'s die eigenlijk dezelfde Debiteur betreffen.
Dit kan op zich worden opgelost door het resulterende overzicht te daadwerkelijk te verwerken (Afschriften worden gejournaliseerd), met daarbij het idee dat als de Afschriften nogmaals worden gegenereerd, de reeds verwerkte Afschriften niet nogmaals in het overzicht zullen voorkomen.
In dit geval betekent het dus : Genereren - Verwerken - Ontvangstnaam aanpassen - Genereren - Verwerken (- enz.).

Let op : Bij bovenstaande hoort m.i. een nieuw veld bij de Faktuur, wat iets mag heten als "Betalende instantie". Waar dit verder moet worden gebruikt (rapportages) is op dit moment (nog) niet van belang, mits maar formeel kan worden aangetoond hoe de aansluitingen lopen. Dit moet worden gezien als : Als Jan de Debiteur is, maar Piet heef betaald, dan valt niet te bewijzen dan Jan NIET heeft betaald (hoeveel Afschriften wil je de inspecteur geven ?), en het bewijs dat Piet heeft betaald (een feitelijke onbekende) zegt niets, behalve dat het wel zwart zal zijn. Je moet dus bewijzen dat Piet behoorde te betalen, en dat loopt via dit veld (ook al andersom aangebracht -> betaling zorgt voor vullen veld). Vervolgens krijg je het verhaal dus andersom, en de inspecteur zal voor iedere op deze wijze andere betaler kunnen zien dat dit altijd klopt (denk met name aan veel van deze situaties), terwijl de afschriften op zich toch ook wel aansluiten. Ja, ik zou er nog wel mee weten te frauderen, maar zonder zo'n veld wordt dat stellig gedacht terwijl ik het niet doe en ook niets heb om het mee te bewijzen (het afschrift van Jan bestaat domweg niet en dat klopt ook - maar vinden kan je zoiets niet).

Een eventueel probleem met een nog niet bestaande Debiteur wordt opgelost door deze Debiteur in te brengen, en de run nogmaals te draaien.

E.e.a. verder uit te werken.

:17c:

In dit geval betekent het dus : Genereren - Verwerken - Ontvangstnaam aanpassen - Genereren - Verwerken (- enz.).
Dit is niet zoals ik het heb bedoeld. Immers dat kan ik nu ook wel en het is bewerkelijk als je een klant met 10 filialen heb (zijn 10 verschillende debiteurid's) met dezelfde ontvangstnaam. Dan zou ik dagelijks dit moeten wijzigen bij de ontvangstnamen. Dit kost mijn inziens net zoveel tijd (zo niet nog meer) dan wat ik nu doe door in het tweede scherm de debiteurid te wijzigen en vervolgens de factuurnummers intypen. Immers ik zit toch al in dit scherm.
Voorbeeld van hedenmorgen: Komt bedrag binnen van Heart Profit in Barneveld met ontvangst naam Heart Profit. De omschrijving is fact. 167300*167301*167302*167303.
Echter de ontvangstnaam is gekoppeld aan (toevallig) Heart Profit uit (stel) Dordrecht.  Dit omdat zij dezelfde ontvangsnaam hebben.
Ik wijzig dan in het tweede scherm de debiteurid (simpel én daar zit ik toch al), maar moet vervolgens wel handmatig die sterretjes bij de omschrijving verwijderen. En van dit laatste wil ik af.
Zonder weer een uur te bellen denk ik dat de oplossing anders moet/kan!
Ik heb er alle vetrouwen in. Weet dat het moeilijk is, maar Heart Profit kan veel en bevat nu ook al veel inteligentie.

Vraagje omdat ik geen zin heb om het uit te zoeken : Waar definieer je die Ontvangstnaam ?
(jij weet het uit je hoofd)

De ontvangstnaam wordt gekoppeld bij een eerste ontvangst van een debiteur. Ik definieer hem niet, hij staat op het bankafschrift en niet beïnvloedbaar door mij.

Daar was ik al bang voor.

Dank je.

Niet bang zijn.
Bij ons zeggen we altijd: "Vaak biej te bange"

Zal wel een TV/WY/VW/RA extra worden dan. Da's die 22 uur, weet je nog ? Maar vaak biej te bange.

Haha.


Ik hoor het jullie zuiperts zo zeggen inderdaad. Ik heb alleen nooit zo doorgehad dat je de hele dag door zuipt !
(maar het zou wel het e.e.a. verklaren)
 :tomatos:

Waar slaat dit taalgebruik op?

De meeste klanten zijn niet bij naam bekend, maar onder de debiteur PARTIKULIER. In de omschrijving gebruiken ze vaak het orderid van ht betalingssysteem IDEAL. Momenteel laat ik dit ordernummer systeem opnemen bij het invoeren van de verkooporder als orderreferentie, maar momenteel ook bij zoekterm. Hierdoor kunnen wij het gemakkelijker terug vinden.
Maw de faktuur uit de verkooporder heeft geen duidelijke koppeling met de betalingsbinnenkomst, behalve als ik op 1 of andere de zoekterm of orderreferentie kan koppelen aan de faktuur (bijvoorbeeld door het gebruik van de faktuurreferentie??????????).

????    en nu verder    ???????

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

Fouter dan fout.

Zo schieten we niet echt op.
Kun jij nu concreet aangeven wat mijn aanpassing (naar de wensen van ons) is en kost.

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

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

Daarnaast, waar doel je nu eigenlijk op ?

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.

Ik denk dat we de discussie moeten afronden. Dit omdat nu wel bekend is wat ik wil. Ik wacht jullie voorstel af. Wellicht is het raadzaam dit ook eens met Wouter te besrpeken. Dit omdat hij in het verleden hier ook wel eens iets mee gedaan heeft.

Kan dit ?? orderreferentie of zoekterm laten gebruiken als faktuurreferentie????

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. :smile:

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 ... :eek:

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 ...

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.

:offtopic: ??

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 (:swoon:). 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.

Even een kleine snelle reactie, voor dat wij helemaal de verkeerde kant opgaan. Natuurlijk moeten partikulieren (leveringen in nederland) gewoon btw hebben en belgische partikulieren krijgen ook gewoon btw 19 %, daar zij geen btw nummer hebben in belgie.

Ga nu de rest lezen... :wink:

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).

 Uiteraard mogen de facturen niet automatisch worden weggeboekt als zijnde betaald. De gebruiker moet dit ingeven. Hetzij volledig/ hetzij verkort.
Verder wacht ik de reactie van Wouter nog even af en ga het nog één keer doorlezen.

Voor de duidelijkheid (voor mij zelf en voor dinand en heart) stop ik nu met deze topic.

Begin was mij duidelijk, later niet meer. Indien ik het onderwerp verder wil uitdiepen, zal ik een concrete vraag stellen in een nieuw topic.
Verder lees ik mee met dinand daar de verwerkingsmanier van hem ons in de toekomst ook misschien wel zou kunnen verder helpen.

Succes heren

Ik ben uitgeuitlegd. :smile:

Wat is de stand van zaken in dit item?

Niets.

Het verwerken van ontvangsten en dan denk ik vnl. aan de werkwijze met Ontvangstnamen, moet m.i. sowieso op de schop. Ik heb mijn gedachte hier al even over laten schijnen, maar een ontwerp zal nog moeten volgen.

Waarom er "Ontvangstnamen" zijn opgenomen, en waarom er op basis van Ontvangstnamen wordt afgeletterd is mij niet duidelijk. Ik heb dit vorige maand al eens nagevraagd bij de persoon die dit ontwikkeld heeft, maar die wist het ook niet.

M.i. zijn er meerdere dingen die wijzen in de richting dat er een formele tabel "Rekeningnummers v/e Relatie" moet komen. We selekteren een willekeurige relatie, en kunnen vervolgens meerdere Bankrekeningnummers koppelen die bij deze Relatie horen. Een "tenaamstelling" is dan een attribuut van het rekeningnummer.

Merk op dat we nu aan de Debiteurenzijde om rekeningnummersvragen (1x bank- en 1x giro), en dit ook doen aan de Crediteurenzijde (1x bank- en 1x giro). Ervanuitgaande dat we over enige tijd alleen nog SEPA betalingen kunnen verrichten, zal dit impliceren dat we 4x om een IBAN rekeningnummer moeten gaan vragen, welke een afgeleide is (attribuut) van het rekeningnummer. Maar, ook de tenaamstelling van deze 4 setjes rekeningen kan anders zijn, en daar zouden we 4 keer om moeten vragen. Beter dit dus alles in één tabel bij te houden.

"Ontvangstnamen" worden nu automatisch bepaald op basis van de naam die op het ingelezen bankafschrift staat. Zélf Toevoegen van Ontvangstnamen is niet mogelijk, maar eigenlijk wél nodig ! Zie maar eens voor je dat rekeninghouder "J.Janssen" de eigenaar is van een restaurant "Tomahawk" met Debiteur-id (TOMAHAWK1). Als fakturen van dhr. Janssen automatisch geïncasseerd mogen worden, dan zal reeds bij het aanleveren van de Incassobatch (dus nog voordat er betaald is, en de Ontvangstnaam op een Bankafschrift kan staan) al bekend moeten zijn dat het rekeningnummer tenaamgesteld is van dhr. J. Janssen.  In theorie zouden we e.d. probleem simpelweg kunnen oplossen door "een Toevoegfunktie" op te nemen, ware het niet dat het verder gaat...

"J. Janssen" is ook nog eigenaar van een restaurant "Cresendo" (CRESENDO1).
Helaas, dat kunnen we niet aan, immers, er kan maar één Debiteur-Id worden gekoppeld aan de Ontvangstnaam !

Dat e.e.a. helemaal fout kan lopen, blijkt dan wel uit het feit dat er elders in het land vast en zeker nog meer mensen zullen zijn die een rekeningnummer hebben die op naam staat van ene "J. Janssen"; je hoeft er maar 2 (of meer) in het klantenbestand te hebben staan, en vandaag wordt Debiteur A bedoeld met J. Janssen, morgen B, overmorgen C, en volgende week betalen A,B,C tegelijk...

M.i. moet dit anders opgezet worden, door 1:n rekeningnummers te koppelen aan een Relatie.
Als een Relatie zowel Debiteur als Crediteur is, hoef je zijn rekening niet nogmaals op te geven (natuurlijk wel aangeven dat je een ander rekeningnummer wilt gebruiken om vanaf te incasseren, dan het rekeningnummer waar je zelf betalingen aan overmaakt).
Voordeel is dan ook dat je meerdere Rekeningnummers kunt opnemen bij dezelfde Relatie, en het niet uitmaakt of de Debiteur nu betaald via zijn ABN-/Amro rekening danwel via zijn Raborekening, beide weten we dan als vanzelf te matchen, maar wel o.b.v. "Rekeningnummer" want dié is uniek ! (en de Ontvangstnaam niet).

Ideal betalingen zullen betalingen betreffen voor een specifieke referentie (Faktuur). Het zal er vanaf hangen hoe e.d. systeem is opzet, want volgens mij genereren we nog nergens een faktuur (zonder levering) met een koppeling naar Ideal programmatuur. Dit zal dus anders opgezet zijn, en wellicht een betaling betreffen voor "een ordernummer".  Hoe dan ook, zoiets kunnen we wel opnemen als "Faktuurreferentie", en als Afletteren dan een mogelijkheid heeft om 1:1 af te letteren o.b.v. én bedrag én Faktuurreferentie, dan lijkt me dat dat probleem ook wel opgelost is.

Dinand, het ontwerp/typewerk noteren we hier als te faktureren hoor.

Wat bedoel je hiermee?

Dat je niet denkt dat het niets kost.

Natuurlijk denk ik dat niet.
Waar ik echter niet voor op wil draaien is het volgende:
Het hele ontwerp moet op de schop volgens jullie (Wouter). Dit is iets anders dan mijn aanpassingen.
Ik wil wel betalen voor iets waar ik beter van wordt, maar niet voor het compleet nieuwe ontwerp.
Dit lijkt mij ook begrijpelijk.
Ik denk dat Wouter terecht daar verbeteringen in ziet. Zitten ook veel verbeterpunten in waar ik nu en in de toekomst niets mee doe. Dat moet dan maar voor rekening van een ander komen. Vraag mij uperhaupt af of wij aan de gehele opzet van Wouter echt beter worden.
Zie graag een prijsopgave voor de aanpassingen van vorige week, daar wil ik ook voor betalen, maar niet voor de complete verandering en ook niet al dit schrijfwerk.

Tja, da's nou leuk ... (en ik ben zeker niet sarcastisch hoor);

Ik zie hetzelfde als jij, en dat is ook de reden waarom ik het even noteerde. Wel zonder Wouter af te vallen, maar ja, wie heeft er nu minsten 3 keer over de telefoon gezegd dat hij Wouter z'n mening ook nog wilde horen, om het daarna veiligheidshalve ook nog even op te schrijven (enkele posts terug) ? jij toch ?

Je hoeft uiteraard niet te denken dat ik het eens was met wat jij in deze graag wilde (Wouter), en het tegenhouden is me dus ook niet gelukt.


Dat Wouter iets wilde zoals hij nu heeft genoteerd wist je al (want daar hebben we het samen over gehad). Dat ik denk (en jij ook) dat dat niet werkt wisten we.
De moraal is dus min of meer (en echt niet om vervelend te doen) dat je ook iets kan uitlokken. Wel, moet ik dat dan betalen ? Ik vind van niet, want het is voor jou.

We komen er vast wel uit hoor.

Ik wacht eerst wel af.

Misschien kunnen "Distributie Ontvangsten" nog helpen?

Als automatisch inlezen bankafschrift een bedrag niet kan matchen, zul jij moeten bepalen "voor welke debiteur er betaald wordt", en daarna moet uitgezocht worden welke fakturen er dan betaald worden. Als je de Debiteur weet, zou het misschien ook een optie zijn het bedrag als Distrubitie Ontvangst voor die Debiteur op te nemen, waarna dié funktionaliteit je vervolgens in staat stelt "het bedrag op te pakken, en af te letteren op de openstaande fakturen" (in plaats van die nummers uit te zoeken, bij Ontvangsten in te vullen, en de run nogmaals op te starten).

"Dagboekjournalisering" is vorig jaar voor jullie aangepast m.b.t. http://ha1.heartprofit.nl/profit/index.php?topic=22919.0, en als je zo'n funktie ook zou hebben vanuit "Distributie Ontvangsten"...

"Dagboekjournalisering" is vorig jaar voor jullie aangepast m.b.t. http://ha1.heartprofit.nl/profit/index.php?topic=22919.0, en als je zo'n funktie ook zou hebben vanuit "Distributie Ontvangsten"...

[/quote]

Wouter, Je laatste voorstel volstaat helemaal. Dit dekt voor het meest de lading. Goed voorstel.
Wil jij in kaart brengen wat e.e.a. gaat kosten?

Vanuit Raadplegen Ontvangsten Telebanking krijg je een mogelijkheid om een niet verwerkbare Ontvangst op te nemen als Distributie Ontvangst voor een op te geven Debiteur (popup). Hier moet tevens een Fin. Interface bij, om het bedrag te boeken als Distributie Ontvangst, bijv.:

Bank
Aan Distributie Ontvangsten Debiteur A.

4 uur (scherm + fin. interface)

Vanuit Raadplegen Distributie Ontvangsten pak je dit bedrag op, en zul je dit kunnen afletteren op openstaande Fakturen van de betreffende Debiteur. Echter, hier wil je (op eenzelfde wijze zoals je dat vanuit Dagboekjournalisering doet) dit kunnen afletteren op een willekeurige faktuur, ongeacht van welke Debiteur.

Afletteren Distributie Ontvangsten zal met een popup  (= 2 uur) moeten komen welke jou vraagt of je wilt afletteren op basis van de fakturen van de betreffende Debiteur, danwel o.b.v. een willekeurig Faktuurnummer.

Vervolgens moet een nieuwe Raadpleegfunktie worden ontwikkeld die alle openstaande Faktuurnummers toont, en jou toestaat om op een willekeurige faktuur af te boeken (= 11 uur).

Ook hier zal er een Fin. Interface aan de orde zijn (= 2 uur), die zorgdraagt voor de boeking:

Distributie Ontvangsten Debiteur A.
Aan Debiteur A

Maar, merk op dat de journalisering ook kan zijn:

Distributie Ontvangsten Debiteur A.
Aan Debiteur B

zodra er op een faktuur van een andere debiteur wordt afgeboekt.

Plus dan nog eventuele kosten om de Financiele Interfaces + Journaalpostdefinities op jullie systeem aan te maken, maar mogelijk kun en doe je het onderhoud aan Interfaces/JP-definities gewoon zelf.

Resumer, je boekt e.e.a. dan alsnog handmatig, maar, in plaats van eerst uit te zoeken op welke fakturen er afgeletterd moet worden, dan de debiteuren + faktuurnummers op te schrijven, de ontvangst telebanking te wijzigen, opnieuw verwerken ontvangsten, aanpassen voor het resterende deel etc. boek je het bedrag nu gewoon op de fakturen die je uitgezocht hebt.

Vindt de gekozen en aangeboden oplossing goed en zal ook zeker gaan werken.

Echter het bedrag wat het mij kost ga ik niet binnen een redelijke termijn terugverdienen. Dit is een voorwaarde die hier in de organistie wordt gesteld.
Wil er ook geen koehandel van maken.
Ik wil voorstellen dit item te sluiten en te parkeren voor wellicht de toekomst.

Ik wil niet deze topic weer opnieuw openen, alleen een signaaltje afgeven.

Ik weet dat volgens mij Wouter hier e.e.a. wil aanpassen zodanig dat er niet op ontvangstnaam wordt verwerkt maar obv banknummer.
Prima actie trouwens die volgens mij nu al werkt naar de volle tevredenheid.
Maar in 2014 gaan we over op IBAN en als ik nu mijn buitenlandse ontvangstnamen, lees banknummers, bekijk dan zijn die in het begin allemaal hetzelfde.
Mijn doel van dit bericht of hier wel rekening mee gehouden is. Wellicht kan dit nu nog niet eens dan houdt alles op.