Berichten

"webkoppel": "Acumulus 7.6.7",

Ik zou beginnen met updaten. Deze plugin loopt flink wat versies achter en wordt niet meer ondersteund.
Je hebt dan wel PrestaShop 8 nodig vermoed ik.

Zie ook:
 - https://forum.acumulus.nl/index.php/topic,2745.0.html
 - https://github.com/SIELOnline/Acumulus-for-PrestaShop/tags

Voor de verwerking van verkopen zijn al twee automatisch filters beschikbaar. Een filter met herkenning op factuurnummer en een filter op basis van een vaste omschrijving. Dit is in 99% van de betalingen voldoende voor automatische verwerking en zit geen kwartaal of jaaromslag in de weg.

Zodra je een factuur gaat proberen te herkennen op basis van een factuurdatum en deze automatisch gaat verwerken is de foutkans te groot. Stel je maar eens voor dat 1 klant 3 openstaande facturen heeft. Allemaal 100 euro, maar voor verschillende diensten. Nu betaalt deze klant 1x 100 euro met een wolkje tekst in de omschrijvingen van de banktransactie dat nergens terugkomt in de verkoopfacturen van jouw administratie.

De nieuwe functie is om na de invoer van een zakelijke uitgave dit als basis te gebruiken voor een automatisch transactiefilter. Dit zodat toekomstige zakelijke uitgaven automatisch verwerkt worden.

Dit is zeker zinvol en staat op de lijst voor de komende periode in het nieuwe jaar.

In elke API-call met Acumulus is de authentificatie opgenomen in de datastroom. Deze overhead is over het algemeen te verwaarlozen als er bijvoorbeeld een factuur inclusief relatiegegevens en factuurregels overgeheveld wordt van webshop naar Acumulus. Er zijn vooralsnog geen plannen om dit te herzien.

Ik heb net een nieuwe filter regel aangemaakt voor Cecilia, dat is best bewerkelijk... Ik zou het fijn vinden als ik tijdens het verwerken van de Saldo Mutaties een filter regel aan kan maken zodat ik alle informatie van die boeking al heb ingevuld en die de volgende keer automatisch geboekt kan worden.

Functie toegevoegd voor zakelijke uitgaven! Na het invoeren van de zakelijke uitgave is er een nieuwe knop om direct een transactiefilter op te stellen op basis van wat je daarvoor hebt ingevoerd.

Excuus, je post op het gebruikersforum. Dit lezen we niet altijd. Voor urgente zaken graag contact opnemen met de klantenservice.

Het probleem had inderdaad niet mogen gebeuren en tijdens de ontwikkeling van de plugins was er juist rekening mee gehouden om dit te voorkomen. Echter, in recente update  van de plugincode ontbrak juist dit controle-stukje. In de dagen na de storing zijn updates vrijgegeven zodat dit niet meer kan voorkomen.

Sinds gisteren is er de optie bijgekomen om eenvoudig filters te kopiëren

@DeWiFiSpecialist: De route om vanuit de mutatie-verwerking filters aan te maken onderzoeken we nog.

Kan er ook nog een toepassing bijkomen die factuurnummers van inkoopfacturen herkent vanuit de omschrijving van de factuur? Of het veld factuurnummer in het boekingsscherm erbij plaatsen zodat we daar de factuurnummers in kunnen zetten? Ik zet ze nu altijd in de omschrijving.

Voor sporadische inkoopfacturen is dit zelden zinvol. Als het om terugkerende betalingen gaat kun je het beste per relatie een combinatie van IBAN en omschrijving als filterregels toevoegen.

Nog iets anders: kan het filter na dat die aangemaakt is standaard op "actief" Nu moet dat handmatig terwijl het logisch is dat als je een filter aanmaakt je die gelijk wil gebruiken toch?

nee, als je een filter opstelt met meerdere regels dan kan het resultaat groter uitpakken dan gewild. het is relatief random wanneer cecilia iets voor je oppakt en verwerkt.

Goede punten. Ook vandaag nog meer terugkoppeling hierover. we gaan hier absoluut mee verder. In de basis is het heel krachtig, we willen dus slim vervolgcode schrijven.

Aha, dit is een instelling van de Acumulus-plugin in WooCommerce. Zie het deel "relatie-beheer" in de instellingen van de plugin. Ik vermoed dat je hier iets niet ingeschakeld hebt en je voor alles-onder-1-relatie gekozen hebt.

Voor de API is dat https://api.sielsystems.nl/ , als er een storing of onderhoud hieraan is, dan wordt er een melding getoond. Als er geen melding nodig is wordt je doorgestuurd naar documentatie.

Nu ik dit zo opschrijf denk ik dat dit inderdaad beter centraal geregeld kan worden op een aparte pagina.

Gaat het om de facturen zoals deze in Woo staan, of de facturen in Acumulus?

Gebruik je wellicht een andere plugin die in de webshopsoftware het adres anders opbouwt? Onze plugins volgen normaal gesproken de informatie van de orders uit de database van de webshop. Om welke versie van de webshop en de plugin gaat het eigenlijk?

- De klant wil de factuur ontvangen op 'facturatie@domein.nl'  maar ook graag een cc naar zijn/haar eigen mailadres binnen de organisatie, bv 'naamdirecteur@domein.nl' Hier zou het extra cc veld perfect zijn.

Open de relatiekaart en vul: facturatie@domein.nl,naamdirecteur@domein.nl in bij het emailadres. Dan zullen bij verzending beide ontvangers het bericht krijgen.

Over het algemeen kun je waar in Acumulus een emailadres opgegeven kan worden deze scheiden met een komma om meerdere adressen te gebruiken. Dit is wel beperkt tot een relatief laag maximum.

Ik vind het eigenlijk helemaal niet zo ver gezocht

Als de afronding niet per factuurregel uitgevoerd wordt kan de prijs voor een product voor de klant afhankelijk zijn van de manier waarop de bestelling loopt. Bijvoorbeeld 1 euro 23 los, en 1 euro 24 als er nog iets anders op de factuur staat..

Het onthouden van de inloggegevens is iets dat Acumulus aan de browser voorlegt. Wellicht is iets in de instellingen van jouw browser gewijzigd.

Voor plug en pay is er gewoon een importprofiel, dat hebben we ooit ingebouwd en bijgewerkt toen plug en pay de export iets gewijzigd had.

Een integratie met Zapier krijgt inderdaad vooralsnog een lage prioriteit bij ons. We richten ons vooralsnog op andere zaken. Dat wil niet zeggen dat we geen feature-requests inbouwen. Zo hebben we vandaag nog de mogelijkheid toegevoegd om abonnementen (ook een relatief nieuwe feature) te ondersteunen voor relatiegroepen.

HTML-ondersteuning in email staat bijvoorbeeld nu hoog op de agenda 

Afrondingsverschillen zijn helaas niet altijd te voorkomen. Acumulus rondt per factuurregel af en niet over het grande totaal. We zien dat als de beste methode. Hoe gek zou het anders zijn als 2 identieke facturen met 1 product bij elkaar opgeteld een andere totaalprijs geven dan als dezelfde 2 producten op 1 factuur worden ondergebracht.

Je kunt in Acumulus zien hoe de btw precies berekend is. Open de boeking en ga naar het "Log"-tabblad. Hier zit een knop: "Berekening factuur". Deze geeft inzicht in de precieze berekening van alle getallen op de factuur.

Dit onderdeel van de instellingen van jouw browser. Je kunt wellicht de browser instellen om niet eerst de pdf te dowloaden, maar direct te openen.

De makkelijkste manier is om een extra product te maken waarop de korting van toepassing is en hier een abonnement voor op te zetten. Daarmee kun je de abonnementen altijd de productprijzen laten volgen.

Vandaag vrijgegeven als onderdeel van plugin versie 8.1.0

Versie 8.1.0 is eerder vandaag vrijgegeven waarin ondersteuning voor HPOS is opgenomen.

Momenteel levert de standaard Shopify Order export optie een .csv met geen BTW info per orderregel, waardoor Acumulus de order skipt bij het importeren.
Begrijpelijk, maar vermoeiend .

Er is een extra importprofiel voor Shopify beschikbaar gekomen deze maand. Hierbij wordt vooral ondersteuning toegevoegd voor gemixte btw waarbij er meerdere btw-tarieven binnen 1 order terugkomen. In de verwerking wordt er teruggerekend en worden verkopen anders verwerkt in Acumulus. Wellicht werkt deze importmethode beter voor jou.

Jazeker, ondersteuning hiervoor is in de planning.

Dit is iets dat de browser zelf regelt.

Voor Firefox: https://superuser.com/questions/61408/how-to-delete-some-of-the-form-data-in-firefox
Voor Edge/Chrome: https://superuser.com/questions/956091/deleting-selected-autocomplete-entries-in-microsoft-edge

Of bovenstaande tips 100% werken weet ik niet. In Edge schijnt daar iets gewijzigd te zijn in de recentere versies.

De specificatie meldt het volgende:

Code Selecteer Uitklappen

CURRENT_BOOKED: The booked balance calculated during the account reporting period, at the time specified, subject to further changes during this period.
CURRENT_AVAILABLE: The balance available during the account reporting period, taking into account pending transactions.

Maar de invulling door de verschillende banken is niet consequent en wisselt in praktijk (vooral bij KNAB) per rekeningvorm:

Code Selecteer Uitklappen

Note that - even with these definitions - the values returned can be calculated in different ways,
depending on the ASPSPs definition of the 'account reporting period'. For some banks, the 'account reporting period'
corresponds with a calendar day, For other banks this period corresponds with a 24hr period between certain cutoff
times, eg from 6pm on day d to 6pm on day d+1.

Met andere woorden, als je geen juist saldo ziet, dan kun je zelf even uitzoeken welke waarde het beste bij jouw rekening past.

En...ik heb 1 rekening met een negatief saldo en daarvan wordt het saldo niet goed weergegeven.

We hebben iets ontwikkeld omdat KNAB er een beetje een rommeltje van lijkt te maken.
Acumulus krijgt namelijke, afhankelijk van de rekening, verschillende bedragen door.

Daarom kun je nu per rekening zelf instellen welke basis je wilt gebruiken voor het saldo.
Zie hiervoor: Beheer -> Rekeningen -> Open de rekening -> Tabblad "Zichtbaarheid".

@Guido, ik heb nu 5 rekeningen gekoppeld en qua tegenrekeningen gaat dit goed.
Echter wordt Acumulus nu heel traag merk ik.

Daar is nu iets aan gedaan. KNAB is nog steeds traag met het aanleveren van de banksaldo's, maar het blokkeert verder gebruik niet langer.

We krijgen de saldi direct doorgezet vanuit KNAB. Kun je de klantenservice een berichtje sturen met het IBAN nummer, de contractcode en het rekeningsaldo dat je zou verwachten?

Als de tegenrekening vermeld wordt, en je enkel tussen een hoofdrekening en de spaarrekeningen boekt kun je het met 1 koppeling van 2.95 af.

Ik neem aan dat er in de transactiegegevens wel een tegenrekening vermeld staat. Ik zou ook een heldere omschrijving toevoegen, dan kan Cecilia het voor je verwerken.

Of spaarrekeningen al door KNAB ondersteund worden weet ik niet. Dat ligt bij KNAB zelf. Ik weet dat er bijvoorbeeld voor ASN-spaarrekeningen geen ondersteuning is. Als je niet tussen de spaarrekeningen onderling gaat schuiven kun je het normaal gesproken met enkel een koppeling op de hoofdrekening af. Scheelt ook weer extra maandelijkse kosten per gekoppelde spaarrekening

Bunq komt (voorlopig) niet vermoed ik. Ik heb navraag gedaan bij 3 PSD2-ingegrators en ze geven alle drie aan dat ze er voorlopig (o.a. om technische redenen) niet aan beginnen.

Het forum is handig voor algemene zaken, maar niet altijd praktisch voor directe ondersteuning op bijvoorbeeld de plugins. Je kunt voor bovenstaande situatie wellicht beter een verzoek voor (pro)support insturen naar woocommerce@acumulus.nl . Dan kijken er meer ogen mee.

Staat er in de wiki of elders een uitleg over hoe je dit moet doen?
(en of het met mijn mailadres uberhaupt mogelijk is om in te stellen)

Er is niet 1 manier waarop dit ingesteld moet worden en is afhankelijk van de DNS/Webprovider waar jouw domein beheerd wordt. Het staat toegelicht in het tabblad van het factuursjabloon wat er moet gebeuren.

Voor jouw e-mailadres kan het in principe ook, maar moet je bij jouw provider zijn om dit in te stellen.

Wellicht is het een idee om een kleine aanvulling op te nemen in de uitleg, ik moest zelf even zoeken hoe ik een 2e server aan mijn SPF-record toevoeg, aangezien ik het ook gebruik voor mijn "eigen" mailserver.

Je moet in dat geval het include:spf.sielsystems.nl deel gewoon na de bestaande server opnemen in dezelfde regel. (Dit had ik niet verwacht, aangezien je voor een 2e mailserver een extra regel aanmaakt, maar als je dat voor SPF probeert, maak je het stuk  )

We hadden al:

"Vraag de beheerder van het domein om dit door te voeren, maar let op, meerdere TXT-records in DNS voor SPF kunnen voor problemen zorgen."

in de tekst opgenomen, maar dat is misschien wat te algemeen. De controle-knop zou wel een foutmelding moeten geven als er in DNS meerdere TXT-records zijn die voor SPF zijn ingericht.

Ik zal eens kijken of ik een betere zin met een waarschuwing kan brouwen

Wat bedoel je precies? De emails worden met DKIM sleutels verstuurd.

Aan de opmaak/slablonen is een tabblad toegevoegd om SPF in te stellen. Dit ondersteunt de uitgaande email op basis van een eigen domein.

Hiermee wordt het mogelijk om(na een DNS-update), vanaf het eigen e-mailadres te verzenden. Wanneer dit juist is ingesteld hoeft Acumulus niet langer From: adres@domein.nl te herschrijven naar adres=domein.nl@via.sielsystems.nl.

In het tabblad van het sjabloon staat uitgelegd hoe dit geactiveerd kan worden.

Dus het lijkt mij geen gek idee om een dergelijk veld configureerbaar en opvraagbaar te maken.

Dat is het ook niet, en de toelichting of uitgebreide toelichting zou hier meer dan voldoende houvast moeten geven. Dit veld wordt meegenomen in de zoekopdrachten.

Een inkoopnummer op een verkoopfactuur? Dat is wel bijzonder.

Als je het echt wilt kun je dit het beste kwijt in de toelichting, uitgebreide toelichting(pijltje achter toelichting), of als tekst in/tussen de factuurregels.

https://www.siel.nl/acumulus/koppelingen/webwinkels/WooCommerce/

https://wordpress.org/plugins/acumulus/

Het lijkt er op dat het een Wordpress website is. Hiervoor is WooCommerce beschikbaar. Voor WooCommerce is er een Acumulus plugin beschikbaar die je het backend van de website kunt installeren. In de instellingen van de plugin zit vervolgens een optie om de facturen direct naar de ontvangers te versturen.

Je kunt nog steeds de interne overboekingen gebruiken, maar de eenvoudige methode is eigenlijk nog simpeler geworden omdat de kostensoorten niet meer hoeven worden aangemaakt.

Mocht je geen boekhouder kunnen vinden dan kun je ook altijd met de klantenservice contact opnemen. Wellicht dat je daar verder geholpen kunt worden.

Je hebt helemaal gelijk. Ik heb zojuist een update van de API uitgerold 

Dat is inderdaad nogal vreemd. Prestashop communiceert met de Acumulus API en die zou voor geblokkeerde jaren een foutmelding moeten afgeven. Kun je een mailtje naar de klantenservice sturen met jouw contractcode en een boeking die er toch doorheen gekomen is? Ik zoek dan even hoe dit precies verlopen is.

We zijn inmiddels gestart met de voorbereidingen voor een koppeling.

Zou het helpen als je bij het opstellen van het filter inzicht hebt in de dan nog te verwerken bankmutaties, zodat je alle informatie voor het inregelen van het filter beschikbaar hebt?

Ik heb gisteren een case geopend hiervoor bij Unifiedpost. Hetzelfde probleem lijkt te spelen voor Triodos bank. Zodra ik meer weet meld ik het direct.