Berichten

De oplossing met 1 regel zou inderdaad als mogelijkheid kunnen.

Het gebruik van de API staat wat haaks op de webkoppelingen dus? In die zin, dat een factuur met bv een foutieve btw berekening wel zodanig wordt geimporteerd? Dan zou een uitbreiding op de API bijvoorbeeld kunnen zijn dat er in het <invoice> blok ook een totaal ex, btw bedrag en totaal inclusief kunnen worden opgenomen.

Overigens ben ik inmiddels al wel zo ver dat ik betalende klant ben geworden 

Even een vraag, hier op inhakend: hoe gaan jullie hier om met factuurregels? ik loop namelijk in de api stuk bij importeren van facturen waarbij het factureringspakket btw op totaalniveau uitrekent (zoals het in mijn ogen ook hoort) en acumulus, die btw per regel uitrekent, met verschillen indien je kleine bedragen hebt, maar veel regels.

En een bijkomend probleem is dat de factuur dan niet meer herkend wordt in de telebankieren afboeking. Dat is nog veel vervelender, die zou ook moeten kijken naar factuurnummers en eventuele verschillen zou je moeten kunnen afboeken als betalingsverschillen.

Daar zijn de meningen over verdeeld, btw is een percentage over de toegevoegde waarde. De eisen voor een btw factuur specificeren dat de eenheidsprijzen exclusief btw moeten worden vermeld en er moet een percentage plus totaal btw bedrag worden vermeld. Als ik dat zou doen op de factuur zoals deze geimporteerd wordt door acumulus, moet ik een afwijkend percentage gaan vermelden op de factuur. Ik weet dat pakketten zoals Accountview dat ook doen, maar ook dat er pakketten op de markt zijn die netjes per regel het bedrag ex btw oppakken en verwerken.

Los daarvan: ik importeer een factuur in het pakket, die moet 1 op 1 overgezet kunnen worden? Ik maak bewust geen gebruik van de facturatie module van acumulus.

ik loop weer tegen iets anders aan. Bij de import wordt door acumulus op regelniveau btw berekend voor zover ik nu kan zien. Is dat ook anders in te regelen, want dat levert verschillen op met de uitgegeven facturen (die wel juist berekend zijn, namelijk op totaalniveau en niet op regelniveau). Dit scheelt op een factuur 12 cent en daardoor wordt het automatisch afboeken van het rekeningafschrift niet mogelijk. Bovendien wordt er 12 cent te veel btw berekend.  Of zie ik hier iets niet goed? Het gaat om een factuur met 25 factuurregels met voornamelijk kleine bedragen.

Ik heb het inmiddels gevonden, was een domme fout aan mijn kant, de curl_exec stond 2x in de code, 1x om uit te voeren en 1x in een if statement om te controleren of het goed was gegaan, dat krijg je er van als je om 3 uur in de nacht nog codeert 

In de basis importeert ie nu facturen, het ziet er dus goed uit. Nu nog een ton aan controles en uitbreidingen maken.

Vreemd, gebruik je de curl methode zoals beschreven in de api documentatie?

dat bericht staat hierboven in de code. is identiek aan het bericht dat er in gaat, alleen zijn de gegevens geanonimiseerd

Inmiddels ben ik wat verder. De import werkt, maar ik zie wel een vreemd gedrag. Bij de import maakt acumulus de factuurregels dubbel aan, terwijl ik de xml netjes enkel aanlever.

Ik krijg een dubbele reply terug als ik naar de xml kijk die terug komt uit de aanroep.

Code Selecteer Uitklappen

<?xml version="1.0" encoding="UTF-8"?>
<myxml>
    <format></format>
    <contract>
        <contractcode>123456</contractcode>
        <username>javaboon</username>
        <password>password</password>
        <emailonerror>xxxxx@xxxxx.nl</emailonerror>
        <emailonwarning>xxx@xxxx.nl</emailonwarning>
    </contract>
    <customer>
        <type>1</type>
        <companyname1>voorbeeldbedrijf</companyname1>
        <companyname2></companyname2>
        <fullname>M Voorbeeld</fullname>
        <salutation></salutation>
        <address1>voorbeeldstraat 11</address1>
        <address2></address2>
        <postalcode>1111 AV</postalcode>
        <city>ALMERE</city>
        <locationcode></locationcode>
        <countrycode></countrycode>
        <vatnumber></vatnumber>
        <telephone></telephone>
        <fax></fax>
        <email>info@xxxx.nl</email>
        <overwriteifexists>1</overwriteifexists>
        <bankaccountnumber></bankaccountnumber>
        <mark></mark>
        <invoice>
            <concept></concept>
            <number>2014050001</number>
            <vattype></vattype>
            <issuedate>2014-01-01</issuedate>
            <costcenter></costcenter>
            <accountnumber></accountnumber>
            <paymentstatus></paymentstatus>
            <paymentdate></paymentdate>
            <description></description>
            <template></template>
            <line>
                <itemnumber></itemnumber>
                <product>voorbeeld webhosting</product>
                <unitprice>110</unitprice>
                <vatrate>21</vatrate>
                <quantity>1</quantity>
                <costprice></costprice>
            </line>
                            </invoice>
    </customer>
</myxml>
<?xml version="1.0" encoding="UTF-8"?>
<response>
<invoice>
<invoicenumber>2014050001</invoicenumber>
<token>a45dc01a6668a5c60231df3bb445c844</token>
</invoice>
<errors>
<count_errors>0</count_errors>
</errors>
<warnings>
<count_warnings>0</count_warnings>
</warnings>
<status>0</status>
</response>
<?xml version="1.0" encoding="UTF-8"?>
<response>
<invoice>
<invoicenumber>2014050001</invoicenumber>
<token>83e6cc4446f152d011f14e98c038e523</token>
</invoice>
<errors>
<count_errors>0</count_errors>
</errors>
<warnings>
<count_warnings>0</count_warnings>
</warnings>
<status>0</status>
</response>


Ik ga er eens mee aan de slag en quick and dirty als tussenoplossing  tot jullie met iets moois komen 

Hoi Bert-Jan,

dank voor je terugkoppeling. Omdat ik nu een afweging moet gaan maken welk boekhoud pakket ik ga gebruiken, is het voor mij wel redelijk cruciaal om een tijdspad hiervoor te zien. Alternatief voor mij is een jaar lang met een ander pakket te gaan werken en dan weet ik niet of ik terug zou keren naar acumulus. Ik wil jullie absoluut niet onder druk zetten, het is voor mij nu alleen wel een moeilijke keuze.

edit: ik zie dat jullie ook een api hebben. Ik zou in principe zelf dus de koppeling kunnen realiseren zie ik, zijn er nog voorwaarden en/of zaken die moeten worden geregeld om die api aan te kunnen spreken? Want dan bouw ik liever zelf iets om te koppelen, het is feitelijk 2 api's aan elkaar sleutelen, zoveel kennis van php heb ik wel

Hallo Bert-Jan,

ik ben ook een wefact hosting gebruiker en zit nu concreet te kijken of ik mijn boekhouding in acumulus kan voeren. Wefact kent inderdaad een csv export van de gevraagde gegevens, nog mooier zou een API koppeling zijn, maar dat is wat specifieker denk ik.

Ik heb nu net geprobeerd om mijn debiteuren te importeren. Ik mis daar wat mogelijkheden, zoals het aangeven dat het geen relatie is, maar een debiteur (analoog ook de crediteur), verder is de opbouw van de aanhef niet handig (geen combinatie van velden mogelijk bij import). De import van facturen zou ook bijzonder goed zijn, zonder die mogelijkheid is het niet te doen om acumulus te gebruiken.

ik zou met veel plezier meer willen betalen per maand als je een api koppeling zou bouwen.