Berichten

TLS1.2 is van 2008 waarna in 2011 er nog een kleine verbetering in doorgevoerd is. Het is een kleine moeite voor een webhoster om dit probleem op het platform te verhelpen. Als er nog geen ondersteuning voor TLSv1.2 is dan vraag ik me af in hoeverre de overige software op het hostingplatform bij gehouden wordt..

Zou je het nogmaals aan de webhost willen voorleggen of ze CURL willen updaten?

Voor producten/diensten waarbij je heel veel commentaar-regels wilt opnemen is dit wellicht niet helemaal optimaal. Je kunt dan wellicht beter een paar concept-facturen slim opzetten waarin je eenmalig de product-uiteenzetting doet.

In het merendeel van de gevallen zal het waarschijnlijk prima werken.

Dan hebben we ergens vergeten aan te geven dat dit inmiddels kan door extra regels toe te voegen. We hebben destijds onderstaande opmerking toegevoegd aan de nieuwsberichten binnen Acumulus.

"Via het factuursjabloon is het mogelijk om factuurregels met een bedrag en aantal van 0 als opmerking of commentaar-regel vorm te geven. Door in het bijbehorende factuur-sjabloon te kiezen voor: "Nul-waarden verbergen" worden het bedrag, btw-percentage, aantal en regeltotaal niet getoond."

Gr,
Guido.

Kunt u aangeven wat u precies bedoelt?

Wat extra informatie voor diegenen die tegen dit draadje aan lopen en met iZettle en Acumulus willen werken: https://www.siel.nl/acumulus/koppelingen/betaaloplossingen/iZettle/

Inmiddels zijn er voor zowel SumUp als iZettle aparte importprofielen beschikbaar gekomen.

iZettle: https://www.siel.nl/acumulus/koppelingen/betaaloplossingen/iZettle/
SumUp: https://www.siel.nl/acumulus/koppelingen/betaaloplossingen/SumUp/

De genoemde importprofielen voorzien in de import als bankmutatie. Neem aub even de moeite om het onderdeel "Praktisch verwerken" op de webpagina te lezen. Dit zou je een hoop handwerk kunnen besparen!

Als het gaat om een levering naar een andere ondernemer in de EU dan dien je 0% op te voeren als BTW-tarief.

Een praktisch overzicht van de verschillende factuurtypen en het bijbehorende BTW-tarief kun je teruglezen op: https://wiki.acumulus.nl/index.php?page=facturen-naar-het-buitenland

Gebruikt u SIELshop of andere webwinkel-software?

De tijd meenemen in de sortering is niet overal beschikbaar. Als de transacties op volgorde van binnenkomst automatisch worden ingeboekt zou er geen probleem moeten zijn. In welk overzicht van Acumulus zie je dit niet gelijk oplopen?

Ah. Ik dacht even dat het om reguliere banktransacties ging. Ik moet helaas antwoorden met enkele tegenvragen:

Verwerk je elke pin-transactie apart in je administratie? We raden doorgaans aan om met dagtotalen te werken. Zie ook: https://forum.acumulus.nl/index.php/topic,6419.msg36421.html#msg36421

Om welke type pin-aparaat gaat het, en gebruik je hiervoor onze importfunctie?

Welke webwinkel-software gebruik je momenteel?

- Guido

Beetje verlate update, maar we hebben voor Rabo SmartPin een apart importprofiel bijgezet in Acumulus.

https://www.siel.nl/acumulus/koppelingen/betaaloplossingen/Rabobank_SmartPin/

Bij welke bank is dit? Ik heb even de ABNAMRO gecheckt en zie daar geen tijdsindicatie..

Beheer ->
Standaard-producten en -activiteiten ->
Knop: Product toevoegen

Je kunt voorraad alleen opvoeren voor (standaard)producten en diensten. Je zult die dus eerst moeten toevoegen. Vervolgens kun je het nieuwe geopende product voorzien van voorraad.

- Guido

[We krijgen wel vaker vragen over pin-transacties en wellicht is het informatief om de veel gebruikte oplossingen even door te lezen:]

Dat zou kunnen, en als het bestand voldoende informatie bevat kunnen hier een importprofiel voor opstellen. Zou je ons op de klantenservice een exportbestand willen aanleveren? We kijken graag even wat mogelijk is.

We krijgen wel vaker vragen over pin-transacties en wellicht is het informatief om de veel gebruikte oplossingen even door te lezen:

Er zijn 2 oplossingen die praktisch werken en een 3e die iets arbeidsintensiever is.

• Er wordt voor de PIN-leverancier een aparte rekening in Acumulus aangemaakt Noem deze bijvoorbeeld "Leverancier-PIN-rekening". Vervolgens worden alle uitbetalingen door de PIN-leverancier aan u als ondernemer als interne overboeking van de Leverancier-PIN-rekening naar de zakelijke rekening ingeboekt. Hierdoor loopt het banksaldo van de zakelijke rekening gelijk en zakt het saldo op de Leverancier-PIN-rekening. Vervolgens worden er periodiek (bijvoorbeeld eens per week/maand of kwartaal) de omzet die via de PIN-methode loopt opgeteld. Dit kan doorgaans aan de hand van de overzichten die de PIN-leverancier beschikbaar stelt.
  
  Voor het totaal aan omzet wordt dan een fisctieve verkoopfactuur als verzamelboeking gedaan. U maakt een relatie aan genaamd: "Klant PIN" en een factuur voorzien van een regel "PIN-verkopen via PIN-leverancier - Augustus 2017". Deze verkoopfactuur wordt ten gunste van de PIN-leverancierrekening geboekt. Let wel dat u per gehanteerd BTW-tarief een verzamel-regel op de factuur opneemt.
  
  Deze methode is vooral geschikt voor verkopen waar geen factuur bij uitgereikt wordt en waar klanten niet of nauwelijks bekend zijn. Bijvoorbeeld verkoop vanuit een marktkraam.
  
  



• De tweede oplossing is nagenoeg hetzelfde als hierboven maar dan zonder verzamelboeking maar elke transactie apart op deze fictieve "Klant PIN". Dit is veel meer werk, maar kan praktisch zijn als het om sporadische betalingen gaat en de boekhouding intensief bijgehouden wordt.
  
  



• Een derde optie gaat nog iets verder waarbij u al, of een deel van uw pinnende relaties gaat toevoegen/beheren in Acumulus en de transacties per relatie apart registreert. Dit brengt veel extra werk met zich mee maar kan in situaties met een relatief kleine maar vaak terugkerende klantenkring wat extra inzichten geven. Naast de inzichten van de opbrengsten per relatie is het ook makkelijker om ook werkelijk facturen uit te reiken.

We maken graag een apart importprofiel maar tot nu toe heeft nog iedereen gekozen voor de 1e of 2e optie en wellicht voor een enkele klantrelatie een aparte factuur via de 3e optie. Dit heeft in ieder geval de PIN-oplossingen van MyPOS, iZettle en een aantal andere apparaten uitkomst geboden.

- Guido

Voor een BV is dit inderdaad wat omslachtig. We nemen het mee in de ontwikkeling.

We willen dit graag een keer toevoegen. Echter het automatisch verwerken is nog niet zo eenvoudig. Een bank kan bijvoorbeeld niet aangeven of een zakelijke uitgave in 1x afgeschreven moet worden of over 5 jaar. Ook kostensoorten en kostenplaatsen zijn bij een bank niet bekend. Ik zal nog even contact met ze opnemen over de mogelijkheden.

ik heb een extra kolom toegevoegd aan het overzicht.

Ik ga eens onderzoeken of we hier wat meer informatie beschikbaar kunnen krijgen in de overzichten.

[[totaal_15]]

Het is nu mogelijk om aanbetalingen eenvoudiger te formuleren vanuit het factuursjabloon. Als u bijvoorbeeld 15% aanbetaling verwacht kunt u dit bijvoorbeeld als volgt formuleren:

"U wordt verzocht een aanbetaling te doen van 15% (EUR [totaal_15]) van het totaalbedrag (EUR [totaal]). Het openstaande bedrag (EUR [totaal_restant]) dient u te voldoen op moment van levering."

Acumulus zal dan automatisch [totaal] vervangen door het factuurbedrag en [totaal_15] door 15% van het factuurtotaal. Om afrondingssituaties te voorkomen raden we aan om bijvoorbeeld geen gebruik te maken van [totaal_15] in combinatie met [totaal_85] maar gebruik te maken van [totaal_15] in combinatie met [totaal_restant]. De ondersteuning in het factuursjabloon is voor alle gangbare velden beschikbaar.

Let op: Op het Email-tabblad is er, om historische redenen sprake van [factuurtotaal_15].

- Guido

Aha. Het mooiste zou zijn als de facturen, betaald of onbetaald, naar Acumulus overgezet worden en dat de plugin de betaalstatus aanpast via de API wanneer nodig. Ik zal het eens aan Remco voorleggen.

- Guido

Als je na het aangeven van de BTW nog facturen over die periode aanmaakt dan doe je volgens mij, of te vroeg aangifte of factureer je te laat

Je hoeft toch niet de facturen die in Acumulus ingeboekt worden uit te leveren aan de klanten? Het gaat puur om de administratieve verwerking.

Ik snap dat het makkelijk is om een factuur te laten vervallen. Echter, wettelijk gezien mag dit eigenlijk niet. Volgens mij kun je dan ook het beste de factuur in WHMCS crediteren. Als het goed is wordt er dan automatisch een creditfactuur tegenover gesteld in Acumulus. Ik vraag het voor de zekerheid even na bij de ontwikkelaar van de plugin.

Verder adviseer ik je om de factuurnummering van Acumulus aan te houden. Het originele factuurnummer van WHMCS wordt namelijk in de toelichting van de boeking vermeld. Je kunt dit eventueel als aparte kolom tonen in het factuuroverzicht van Acumulus (Beheer -> Geavanceerde instellingen -> Toelichting in overzicht verzonden facturen inschakelen).

Door de nummering aan Acumulus over te laten is het makkelijker om de ononderbroken reeks te waarborgen en bij een eventuele fiscale controle geen gedoe hierover te krijgen.

Misschien helpt het om de nul-regels toe te voegen. Je kunt een factuurregel toevoegen met een bedrag + aantal van 0. Vervolgens geef je in het factuursjabloon aan dat je de nul-waarden wilt verbergen. Zie tabblad "Factuur" en "Offerte" van het desbetreffende sjabloon waardoor de factuurregel als een opmerking getoond wordt.

Ik ga even overleggen met de ontwikkelaar. Misschien dat we een functie kunnen inbouwen om het uitgangspunt van de prijs (excl. of incl. BTW) instelbaar te maken. Wat de planning is van WooCommerce zelf is me niet bekend. Ik vind het nogal een boute wijziging om de interne opslag van de decimalen op deze manier te veranderen.

Acumulus werkt op basis van het bedrag exclusief btw. Je voegt immers btw toe aan het bedrag.  Dus: 28.88 x 1.21 = 34.9448 dat Acumulus afrond naar 34.94.

Ik vermoed dat WooCommerce uitgaat van het bedrag inclusief btw en hier de btw uit haalt. 34.95 : 1.21 = 28.8842975etcetera. Omdat WooCommerce recent besloten heeft dat de cijfers achter de komma niet meer zo belangrijk zijn slaan ze het niet meer op als 28.8842 maar als 28.88 waardoor de fout veroorzaakt wordt..

Ik heb begrepen dat er her en der wat afrondingsproblemen zijn ontstaan in WooCommerce doordat in WooCommerce v3 de bedragen met minder cijfers achter de komma opgeslagen worden. Gaat het om grote aantallen goederen of diensten en wat zijn de bedragen exclusief BTW en het btw-percentage?

- Guido

We hebben eerder naar een importprofiel van iZettle gekeken. Echter er bleek in alle gevallen dat iZettle de volgende dag de gepinde bedragen al bijschreef op de zakelijke rekeningen. In al die gevallen bleek het makkelijker (en veel minder werk) om gewoon op basis van de bankmutaties van de zakelijke rekeningen de boekingen af te letteren.

Er zijn 2 oplossingen die meestal gebruikt worden.

• Er wordt een iZettle-rekening in Acumulus aangemaakt. Vervolgens worden alle uitbetalingen door iZettle aan de ondernemer als interne overboeking van de iZettle-rekening naar de zakelijke rekening ingeboekt. Hierdoor loopt het banksaldo van de zakelijke rekening gelijk en zakt het saldo op de iZettle rekening. Vervolgens worden er periodiek (bijvoorbeeld eens per week/maand of kwartaal) de omzet via iZettle opgeteld. Dit kan aan de hand van de overzichten van iZettle. Voor het totaal aan omzet wordt dan een fisctieve verkoopfactuur als verzamelboeking gedaan. Er wordt een relatie aangemaakt genaamd: "Klant Pin" en een factuur voorzien van een regel "Pin-verkopen mei 2016". Deze verkoopfactuur wordt ten gunste van de iZettle rekening geboekt.


• De tweede oplossing is nagenoeg hetzelfde als hierboven maar dan zonder verzamelboeking maar elke transactie apart op de fictieve klant. Veel meer werk, maar soms praktisch als het om sporadische betalingen gaat.

Hopelijk helpt dit voor iZettle. Waarschijnlijk kan de methode ook gebruikt worden voor SumUp.

- Guido

Ja hoor, dat kun je in het offerte-tabblad van het desbetreffende factuur-sjabloon aan of uitschakelen.

Dat zou technisch wel mogelijk moeten zijn. Welke versie van de plugin en WHMCS gebruik je momenteel?

- Guido

Er zijn vooralsnog geen plannen om dit aan te bieden. Ik heb afgelopen weekend even door de development-docs van Zapier zitten lezen maar het is wat wollig opgezet allemaal. Wat is vooralsnog een beetje mis is dat ik niet direct een use-case zie waarbij je, bijvoorbeeld facturen uit pakket X, via Zapier kunt overzetten naar Acumulus.

welke versie van de plugin gebruik je momenteel? in versie 4.6.4 van 6 december 2016 zou dit opgelost moeten zijn. kan het zijn dat je webwinkel+plugins niet up-to-date zijn?

Je zou voor deze bedrijven in de relatiekaart onder "Client-gegevens" (tabblad #2 van de relatie) deze landbouwverklaring kunnen opnemen. Alles dat in "Client-gegevens" staat wordt dan op elke factuur voor de desbetreffende relatie afgedrukt.

Het is een bekend probleem waar we op dit moment niet eenvoudig iets voor kunnen aanpassen.

Voor nu zou ik even per periode de facturen naar een apart bestand wegschrijven.

Als het vinkje niet goed opgeslagen wordt dan voelt dat als een foutje in het configuratie-scherm van de koppeling. Ik zal de ontwikkelaar even vragen of hij er naar kan kijken. Ik neem aan dat je de laatste versie van de plugin gebruikt?

Mooi. Ik ben benieuwd maar vermoed dat de certificaten en certificate-authorities op de server zijn bijgewerkt. Mocht iemand ooit tegen fout #35 aanlopen dan is dit wellicht een praktische case om na te slaan.

Het aanbieden van een webhook zie ik om eerlijk te zijn, gezien de huidige ontwikkelrol (voorlopig) niet gebeuren. Ik probeer nog even te zoeken naar een alternatief. Je geeft aan dat de Acumulus API jouw klantenportaal voorziet van data. Dat wekt de suggestie dat je een link hebt tussen het relatienummer dat Acumulus toekent en de relatie in het eigen portaal.

Heb je misschien iets aan: https://www.siel.nl/acumulus/API/Contacts/Invoices_Outgoing/ of  https://www.siel.nl/acumulus/API/Reports/Unpaid_Debtors/ in combinatie met een datum en een interne registratie dat de klant op de hoogte gebracht is bij de opgeslagen factuurreferentie?

Als je het entryid en het token beide lokaal opslaat (in jouw eigen systeem) dan kun je toch de gewenst informatie ophalen uit onze API?

Zie bijvoorbeeld:

  https://www.siel.nl/acumulus/API/Entry/Get_Entry_Details/
  https://www.siel.nl/acumulus/API/Entry/Update_Entry_Details/
  https://www.siel.nl/acumulus/API/Invoicing/Get_PDF_Invoice/

Gr,
Guido.

Ik vermoed dat de API al kan wat je wilt. Als je de factuur aanmaakt krijg je van de Acumulus API een response met informatie.

De meest zinvolle zijn eigenlijk het aantal errors en warnings. Als je deze XML-respons afvangt dan weet je in ieder geval of de factuur is bijgezet in je administratie.

Daarnaast kun je ondermeer het aangemaakte factuurnummer(invoicenumber), het gebruikte boekstuknummer (entryid) en het token(token) dat je kunt gebruiken om naar de PDF te linken of om de PDF te downloaden.

Je kunt deze respons zien als een min of meer directe webhook. Als je een usecase hebt voor andere informatie dan hoor ik het graag.

- Guido

Terugkerende klanten worden inderdaad bijgewerkt door de koppeling. Het klinkt alsof de aanhef in WC niet helemaal goed doorkomt bij de plugin maar laten we even de reactie van de ontwikkelaar afwachten.

Ik zal je vraag even voorleggen aan de ontwikkelaar van de plugin.

Ok. Ik heb het topic even gesplitst. De originele post ging over facturen voor het gebruik van Acumulus zelf.

De betaalstatus komt direct vanuit OpenCart. Ik vermoed dat de plugin dit dan ook gewoon overneemt vanuit de webwinkel zelf en als zodanig inschiet in de administratie. Ik ben geen OC-expert maar ik heb het idee dat je in OC zelf ergens zou moeten kunnen instellen dat in jouw omgeving bij 'Voortuitbetaling' de order als niet betaald moet worden gezien. Als dat kan zou het automatisch goed moeten gaan.

De koppelingen maken allemaal een verbinding naar https://api.sielsystems.nl/

Beste Werner,

Ik begrijp je vraag niet helemaal. Heeft dit te maken met de facturen voor het gebruik van Acumulus of over facturen die op een andere manier in je administratie komen?

Het ziet er inderdaad iets beter uit. Stempel er op en door naar balie #2,... ik herinner me vaag dat iemand anders dit ook had.. daar was de website een (te) oude versie van curl aan het gebruiken. Kun je eens uitzoeken of navragen welke versie van curl er gebruikt wordt en of er een OS-update voor uitgerold kan worden?

Ik zou je webhoster eens vragen om het certificaat iets netter op te zetten. Ik vermoed dat onze API de aangeboden versleuteling niet goed genoeg vind. Zie ook: https://www.ssllabs.com/ssltest/analyze.html?d=www.ecorijk.nl

Ik denk dat er een configuratieprobleempje zou kunnen zijn voor de webshop die je gebruikt. Kun je het adres van de webwinkel even doorgeven?

Ik heb zojuist "Great Britain" (met 1 t in britain) toegevoegd aan de koppeling

Om welke webwinkel-software gaat het?