verwerken ontvangsten debiteuren

[Dinand]

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?

[Berny van Rijssen]

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.

[Berny van Rijssen]

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

[Peter Stordiau]

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 ?

[Peter Stordiau]

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?

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

[Peter Stordiau]

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.

[Dinand]

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.

[Peter Stordiau]

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

[Dinand]

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.

[Peter Stordiau]

Daar was ik al bang voor.

Dank je.

[Dinand]

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

[Peter Stordiau]

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

Haha.

Bij ons zeggen we altijd: "Vaak biej te bange"

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)
 

[Dinand]

Waar slaat dit taalgebruik op?

[Berny van Rijssen]

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.

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

[Peter Stordiau]

Waar slaat dit taalgebruik op?

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