Hoofdmenu
-menu

Toon bijdragen

Deze sectie stelt je in staat om alle bijdragen van dit lid te bekijken. Je kunt alleen de bijdragen zien waar je op dit moment toegang toe hebt.

Toon bijdragen-menu

Berichten - Guido

#301
er zijn nog meer afhankelijkheden en we vinden het direct koppelen van de tarieven met de kostensoorten niet verstandig om zomaar voor iedereen door te voeren. de beste route is door het 3e tabblad van de relatie volgens de gewilde voorkeuren in te regelen.
#302
Ik heb er een icoontje bijgezet om de PDF-bestanden direct apart te downloaden/openen.
#303
Omdat het technisch mogelijk is om malafide programma-code in een plaatje te verstoppen voert Acumulus op alle plaatjes een aantal speciale bewerkingen uit. Deze bewerkingen hebben geen invloed op de vormgeving maar wel op de bestandsopbouw van het plaatje.

Meestal zorgt dit voor een nagenoeg gelijk, of kleiner bestand. Echter het is ook goed mogelijk dat het bestand hierdoor vergroot is.

Daarnaast is voor het uiteindelijke PDF-bestand zelf ook de nodige meta-data vereist dat het formaat vergroot.
#304
en dan zijn er ook nog situaties waarbij toch een btw-tarief van toepassing is..
#305
Je zult dan wel de bank en verzekeraar als relatie moeten toevoegen.
#306
Leuke oplossing :) Je kunt ook tabblad #3 van de relatie configureren ;)
#307
Dat is best een goed idee. Ik heb het scherm iets verrijkt.
#308
Ik zie dat de interface aan de kant van Mijnwebwinkel voor diverse configuraties een timeout geeft. Dit gebeurt om onduidelijke redenen wel vaker. Meestal is het tijdens een volgende run (de koppeling probeert het gemiddeld genomen elk uur) opgelost.
#309
Stuur even een verzoekje met je contractcode en het nummer van de koppeling (staat rechts bovenin het instel-scherm) naar klantenservice@acumulus.nl . Dan zoek ik even uit wat er speelt.
#310
Ik zie nu dat ik jouw vraag verkeerd gelezen heb. De ondernemer uit het buitenland vult dus wel zijn BTW-nummer in.. Dan zou de koppeling dit inderdaad als levering aan een ondernemer in de EU moeten aanbieden.

Ik zal de vraag even voorleggen aan de ontwikkelaar. Gebruik je de laatste versie van de plugin?
#311
Als een ondernemer uit België zijn BTW-nummer niet opgeeft kun je dit niet goed aanbieden naar de belastingdienst in de aangifte. Je dient als uitweg dan gewoon BTW te rekenen. Waarom maak je het veld niet verplicht in je webwinkel voor zakelijke klanten?
#313
Webkoppelingen / Re: Opencart & margeregeling
12 mei, 2016, 13:01:39
Als de code publiek is zodat ook andere Acumulus gebruikers de mod kunnen installeren dan kunnen we verder uitzoeken of we ondersteuning voor de mod in de plugin kunnen inbouwen. Over een tijdspad kan ik geen uitspraak doen en hooguit de ontwikkelaar van de plug-in even navragen.

Je bent vrij om verzendkosten op een marge-factuur te zetten. Let wel dat formeel gezien de verzendkosten dan ook de marge-regeling dient te volgen omdat de BTW hierop afhankelijk is van het hoofdbestanddeel van de factuur.
#314
Webkoppelingen / Re: Opencart & margeregeling
12 mei, 2016, 12:22:03
Je kunt onze plugin aanpassen maar besef dan aub wel dat je bij een update van de plugin wederom deze aanpassingen moet doen.

Concreet gaat het om het toevoegen van de volgende informatie:

Het vattype dient op 5 te staan voor marge-facturen bij het aanbieden aan de Acumulus Invoice Add API. Let wel dat een factuur in zijn geheel onder de marge-regeling dient te vallen of in zijn geheel niet onder deze regeling. Je mag wettelijk gezien dit niet mixen.

De costprice dient alleen ingevuld te worden bij marge-producten op marge-facturen.

Zie ook: https://www.siel.nl/acumulus/API/Invoicing/Add_Invoice/
#315
Webkoppelingen / Re: Opencart & margeregeling
12 mei, 2016, 12:11:41
Bij het overzetten gebruikte de Acumulus-plugin de API van Acumulus. Omdat er standaard geen ondersteuning voor de marge-regeling in OpenCart is wordt er bij de omzetting geen rekening mee gehouden en wordt de factuur als normale factuur ingeboekt. De berekening van de BTW gaat, bij goed aanbieden aan de Acumulus API automatisch.

Met publiek bedoelde ik of de mod vrij beschikbaar is voor alle OpenCart gebruikers. Alleen dan kunnen we echt goed onderzoeken of we de plugin kunnen uitbreiden om dit te ondersteunen. Zonder publieke code kunnen we hooguit tips geven hoe je onze plugin kunt aanpassen.
#316
Webkoppelingen / Re: Opencart & margeregeling
12 mei, 2016, 11:58:35
Als het een publieke mod is dan zouden we er mogelijk iets mee kunnen. Acumulus heeft de volgende informatie nodig:

- of het product is aangemerkt als marge-goed.
- de inkoopprijs van het product.

als dit in de lokale database wordt opgeslagen dan zou de plugin op basis hiervan een factuur aan Acumulus kunnen aanbieden volgens de marge-regeling. Acumulus rekent dan vervolgens de fiscale gevolgen en de af te dragen automatisch zelf uit.
#317
Eerder vandaag hebben we een update in Acumulus doorgevoerd.
Het is nu mogelijk om het BCC-veld via het factuursjabloon te beheren.
Je kunt de nieuwe functie terugvinden op het tabblad: E-mail van elk sjabloon.

Volgens mij is het hiermee ook mogelijk om de trustpilot-functie te gebruiken.
#318
Webkoppelingen / Re: Opencart & margeregeling
03 mei, 2016, 09:23:08
Ik ben niet goed genoeg bekend met OpenCart om aan te geven hoe je dit kunt oplossen. Om de marge-regeling te kunnen toepassen heeft Acumulus ook informatie nodig over de inkoopprijs van het verkochte goed. Kun je wel een inkoopprijs invoeren in OC?
#319
Webkoppelingen / Re: Opencart & margeregeling
02 mei, 2016, 19:14:40
Heb je op dit moment iets in de OpenCart webshop geïnstalleerd waarmee je de margeregeling kunt inschakelen?
#320
We zien de koppeling zeker niet als een hobby-project. Misschien is er iets gewijzigd in PS waardoor de koppeling tegen een foutje aanloopt. Normaal gesproken krijg je dan per email een foutmelding bij het versturen. Heb je niets ontvangen?

Recentelijk is er een start gemaakt om via de officiële kanalen te distribueren. Voor WooCommerce en Magento is dit reeds operationeel. Ik zal navragen wat de status van PrestaShop is.
#321
Webkoppelingen / Re: Opencart & margeregeling
02 mei, 2016, 12:46:21
Als OpenCart technisch gezien niet kan aangeven dat het om marge-verkoop gaat dan kan de plugin dit nooit goed aanbieden aan Acumulus. Je kunt facturen die onder deze regeling vallen beter handmatig inboeken vermoed ik.
#322
Vanmorgen een kleine update uitgerold waarin de projectadministratie en urenregistratie verder verbeterd is.
#323
Via "Nieuwe boeking" -> "Zakelijke kilometers met privé-voertuig" kan nu ook op de mobiele interface deze ritregistratie worden ingevoerd.
#324
Citaat van: Penning op 09 april, 2016, 21:56:47
Ik sluit mij hier graag bij aan. Ik vind het een groot gemis dat er niet standaard een mogelijkheid is om een document bij een boeking te voegen. Ik wil graag volledig in de cloud werken, ook wat betreft bonnetjes en facturen.

Na het inboeken kun je met een knop de gemaakte boeking direct openen om vervolgens een document aan de boeking toe te voegen.

- Guido
#325
Gebruikers van een webwinkel bij Strato kunnen nu relatief eenvoudig de relaties en facturen naar Acumulus overzetten. Meer informatie op: https://www.siel.nl/acumulus/koppelingen/webwinkels/Strato/
#326
Je zou de route van de project-administratie kunnen nemen. Je maakt dan voor de relatie een apart project aan. Binnen dit project kun je producten en diensten speciaal voor deze relatie opzetten. Je kunt meerdere diensten en producten binnen hetzelfde project verdelen over meerdere facturen.

De project-administratie is terug te vinden via Overzichten -> Uren-registratie / project-administratie. Of eventueel via het koffertje achter de relatie in het relatieoverzicht.
#327
Misschien is het voor nu het meest praktische om de ontbrekende facturen even handmatig in te voeren. Dat geeft in ieder geval rust in verband met de aankomende aangifte.
#328
Ik verplaats het onderwerp even naar het juiste deel van het forum. Mogelijk is de post niet opgevallen bij de ontwikkelaar van de plugin. Het is praktisch, als het probleem nog speelt, even een email stuurt naar de klantenservice.
#329
Ik heb het onderwerp even verplaatst naar het webkoppelingen-deel van het forum. Het gaat om een nog niet geheel duidelijk probleem met de OpenCart2 plugin.
#330
Excuus. We lopen wat oude zaken na en ik zie dat we zijn vergeten hier te melden dat het inmiddels al een tijd opgelost is.
#331
Je zou dit bij "Kenmerk" kunnen opvoeren. Waarom wil je het graag bijhouden?
#332
Een relatie binnen Acumulus kent altijd maar 1 adres. Relaties met meerdere adressen ziet Acumulus als meerdere relaties.
#333
Waarom gebruik je niet het relatienummer dat Acumulus automatisch toekent aan de relaties? Dit kun je tonen door dit onder Beheer -> Geavanceerde instellingen aan te vinken.
#334
Ik heb even een email gestuurd naar de plugin-ontwikkelaar om naar dit topic te kijken. We hebben in het verleden wel gesproken over een overzicht in de webwinkel waaraan te zien was of een factuur overgezet was of niet. Hopelijk kan hij hier ook aangeven hoe de vergelijking gemaakt kan worden.
#335
Waarom gebruik je niet de door ons beschikbaar gestelde plugin? ( https://wordpress.org/plugins/acumulus/ ) . Deze plugin zet de factuur over naar Acumulus. Bij een succesvolle overzetting geeft de Acumulus API een entryid terug dat de plugin lokaal opslaat en koppelt aan de order in WooCommerce.
#336
In WooCommerce wordt na het inschieten lokaal het entryid opgeslagen. Misschien heb je ze dus al :)

Wat gaat er niet goed?
#337
Ik zal er eens over nadenken. Importeer je ook automatisch?
#338
Als je "API-codes tonen" aanvinkt dan verschijnt het boekstuknummer (=entryid) in de 6e kolom in het overzicht van verzonden facturen. Met een beetje omweg kun je dit weer exporteren naar CSV om eventueel als PDF uit de API te vissen.
#339
Ik weet niet wat je exact probeert te bereiken, maar als je het boekstuknummer weet kun je met https://www.siel.nl/acumulus/API/Entry/Get_Entry_Details/ de meest zinvolle informatie wel ophalen.

Je kunt eventueel in Acumulus via:

  Beheer -> Geavanceerde instellingen -> API-codes tonen

deze codes in de diverse overzichten in beeld krijgen.
#340
Helder. Het was me niet helemaal duidelijk uit het eerste bericht dat het om bij de klant afgeleverde factuur ging. Ik dacht een factuur in de administratie van Acumulus (waar een EUR 0,- factuur niet in de weg staat). De filter-optie die Erwin aandraagt lijkt me dan de juiste route.
#341
Wat is er mis met een EUR 0,- factuur ?, en genereert WooCommerce zelf ook een factuur als iets gratis wordt "gekocht" ?
#342
Citaat van: Remco C. op 01 februari, 2016, 19:41:39
WHMCS maakt bij het gebruiken van de MASS Pay button een nieuwe factuur aan met het totaal van de geselecteerde facturen.
als deze factuur wordt betaald dan wordt die factuur op betaald gezet en ook de geselecteerde facturen.

Dat is fiscaal gewoon helemaal fout, en volgens mij echt niet specifiek voor de Nederlandse belastingregels. De originele 2 facturen dienen, als ze reeds in de boekhouding opgenomen zijn, daar ook weer gecrediteerd te worden.

Als het mogelijk is om op het moment dat MASS Pay in werking treed de originele facturen ook als creditfactuur in te schieten in de administratie dan komt het goed. Als er geen hook/event/trigger of iets dergelijks beschikbaar is in WHMCS hiervoor dan vrees ik dat je tegen een tekortkoming van WHMCS aangelopen bent.

In Acumulus kun je de 2 originele facturen relatief eenvoudig als creditfactuur bijzetten. Open de desbetreffende boekingen, kies tabblad:boeking, kies bij Opties in de pulldown voor: "Kopieer deze factuur credit".
#343
Nog een tip: Escape alle 5 verschillende XML-controle-karakters:

  &
  "
  '
  <
  >

naar html-entities.

Verder: Als je de xml_string methode gebruikt, vergeet dan niet de string te url-encoden voordat je deze aan de API doorgeeft.
#344
In aCumulus (met 1 c ;)) kun je een factuur maar beperkt wijzigen. Je zult de originele factuur als creditfactuur moeten inschieten. De meest eenvoudige methode is om dezelfde factuur nogmaals aan te bieden maar alle factuurregels met -1 te vermenigvuldigen. Vervolgens zet je de nieuwe factuur met de wijzigingen over.
#345
Aanvullend kun je nog per betaalmethode een aparte rekening, kostenplaats en factuursjabloon kiezen. Zeker als betalingen via een betaalprovider lopen is automatisch boeken op de juiste tussenrekening in Acumulus erg praktisch.
#346
Citaat van: vanmeerdervoort op 30 januari, 2016, 14:20:13
Ik heb een homemade online reserverings systeem dat facturen genereert en mailt. Hoe kan ik dit het beste met acumulus koppelen?
Simpel gezegd heb je 2 opties. Je kunt periodiek importeren via een CSV-bestand of automatisch via de API. Met de API heb je meer controle over hoe en volgens welke spelregels je dingen inschiet.

Citaat van: vanmeerdervoort op 30 januari, 2016, 14:20:13
Kan ik de door mijn software gegenereerde factuurnummers en info aan acumulus doorgeven via de API en daarmee in acumulus een nieuwe (gekoppelde) factuur maken met referentie aan mijn software-factuur?
Ja. Hiervoor gebruik je de invoice_add API. Laat: "xml -> customer -> invoice -> number" leeg en vermeld de referentie naar jouw software-factuur in: "xml -> customer -> invoice -> description". Hiermee waarborg je dat er voor de administratie een aaneengesloten nummering is en behoud je de referentie naar de originele factuur. Het maakt het ook makkelijker om extra verkoopkanalen of losse verkoopfacturen in de administratie bij te zetten.

Citaat van: vanmeerdervoort op 30 januari, 2016, 14:20:13
Of moet ik mijn hele software ombouwen en alles via acumulus gaan doen?
Dat is een keuze. Je kunt er voor kiezen om de gegenereerde facturen in de eigen software niet meer uit te sturen maar door Acumulus te laten verzenden. Zie hiervoor het "emailaspdf" onderdeel van de invoice_add API en uiteraard het factuursjabloon in Acumulus.

Citaat van: vanmeerdervoort op 30 januari, 2016, 14:20:13
Hoe werkt dit bij van te voren gegenereerde facturen van bijvoorbeeld WooCommerce?
Goede vraag. De ontwikkelaar van de plugin weet dit vast een stuk beter te vertellen maar volgens mij is het in grote lijnen zo dat je op een bepaald (gekozen) moment de webwinkel software een trigger geeft aan de plugin. De plugin vist info uit de webwinkel-database en zet die door naar de Acumulus API. Voor facturen die al gegenereerd zijn voordat de plugin geinstalleerd was wordt dan gekozen om de factuurstatus tijdelijk te wisselen (naar een status die de klant niet op de hoogte brengt) waarmee de trigger alsnog plaats vind.

Citaat van: vanmeerdervoort op 30 januari, 2016, 14:20:13
Graag wat tips :)
- Maak gebruik van een proefaccount. Vervuil er gerust een stuk of wat om te voorkomen dat je volautomatisch een complete administratie overhoop haalt. Proefaccounts zijn geheel vrijblijvend en worden na verloop van tijd automatisch verwijderd.
- Gebruik emailonerror en emailonwarning bij elke call die je met de API maakt.
- Schakel in Acumulus de API-codes en boekstuknummers in. Zie Beheer -> Geavanceerd. Hiermee krijg je bruikbare codes voor de koppeling makkelijk inzichtelijk.
- De meeste API-calls geven een aantal standaard waarden terug. Parse in ieder geval de warnings en de errors zodat je weet als er dingen semi-goed of verkeerd gaan.
- Sla het entryid lokaal op in het geval dat je een entryid terug krijgt van de API (bij het correct inschieten van een factuur bijvoorbeeld) en koppel dit lokaal aan de factuur in de webshop. Hiermee kun je voorkomen dat je facturen dubbel overzet. Je zou in theorie ook nog in de webshop checks kunnen inbouwen om totalen te vergelijken met de entry_info API van https://www.siel.nl/acumulus/API/Entry/Get_Entry_Details/ en ergens lokaal een vlag kunnen opsteken als iets afwijkt.
- Kies expliciet voor de identifiers van de kostenplaatsen, rekeningen en factuursjablonen en val niet terug op de standaard waarden.
- Overweeg de connector feedback goed in te richten: https://www.siel.nl/acumulus/API/Basic_Submit/ . Mochten er berichten in de bitbucket van de API terecht komen dan kunnen we gerichter contact opnemen. Een deel hiervan komt ook terug op het notitie-tabblad van de boeking.

- Guido

#347
Ik ken deze specifieke case niet zo goed maar zal het eens aan de ontwikkelaar voorleggen. Wellicht dat je het zelf even kunt testen met een Acumulus proefaccount.

Worden factuur #1 en #2 in jouw voorbeeld in WHMCS wel als gecrediteerd aangemerkt? En heeft de eindklant toegang tot factuur #1, #2 en #3 ?
#348
Ik ben er altijd van uit gegaan dat het veiliger is (veiliger in het kader van invoerfouten) om met een melding de boel te blokkeren. Als je door kunt typen is de melding veel makkelijker te negeren. Misschien moeten we er nog eens over nadenken.

Als extra "training" zou je wellicht wat meer het numerieke gedeelte van het toetsenbord kunnen gebruiken. Daar zit geen komma op :) Tenminste, bij de reguliere toetsenborden.
#349
We willen een stukje logica herzien zodat we dit wat netter kunnen presenteren. Echter het is lastig om met de huidige drukte aan te geven hoe en wanneer we hiermee aan de slag gaan.
#350
Geregeld. Bij het aanmaken van een nieuwe relatie kun je direct het sjabloon kiezen.