Messages

Dit versterkt mijn vermoeden dat het  een mod_security probleem op de server is. Bespreek het probleem dus met je hoster.

Deze foutmelding komt (meestal) van Apache, bekijk de serverlogs om uit te vinden wat er fout gaat.

Onze plugin definieert zelf geen "capabilities" maar baseert toegang op de capabilities 'manage_options' en 'manage_woocommerce'. Als een user (een niet super administrator) die niet heeft komt er de foutmelding "You do not have sufficient permissions to access this page." (of "Je hebt onvoldoende rechten om deze pagina te bekijken."), maar in het WP kader, dus geen 403.

Ik kan je dus niet verder helpen.

Die opties zijn er al even, dus je komt ws van een hele oude versie. Er zijn trouwens wel nieuwe instellingen op dit formulier: Hoofdadres en Landnaam, maar dit terzijde.

Een 403 forbidden kan ik niet verklaren. Komt die van WordPres, staat er een bericht op het scherm, bijv: Je hebt geen toestemming om deze pagina te bekijken. Zonder verdere melding komt het ws van de webserver, bijv de mod_security module wil nog wel eens te strak ingesteld worden door hosters.

Leeg de cache en probeer het opnieuw. Gaat het nog steeds fout? Wat is de url van het formulier en wat is de url van de foutpagina? Wat staat er op de foutpagina?

[Veldverwijzing voor het btw-nummer]

Veldverwijzing voor het btw-nummer

Fout in versies 8.0.0 en 8.0.1 van de WooCommerce plugin
Als je de "WooCommerce EU/UK VAT Compliance" plugin gebruikt pas het volgende dan aan:
Formulier "Acumulus veldverwijzingen" => kopje "Brongegevens voor de klantgegevens" => veldverwijzing voor het "btw-nummer"veld: Ergens achteraan staat get_meta(Vat Number). Dat moet zijn get_meta(VAT Number).

Door deze fout kan de plugin het btw-nummer niet achterhalen en zal dan ook geen factuur met verlegde btw accepteren. Je krijgt een foutmelding (de factuur wordt mogelijk wel als concept verstuurd). Als je (vaak ten onrechte) hebt aangegeven dat je producten/diensten aan 0% btw of btw-vrij levert, krijg je geen foutmelding maar wordt de factuur als btw-vrij of aan 0% btw verstuurd. Rapportages over verlegde btw gaan dan fout en de facturen zullen niet vermelden dat het om verlegde btw gaat. Pas in dat geval de instellingen "Welke belastingklasse definieert btw-vrij" en "Welke belastingklasse definieert het 0% btw-tarief?" aan. Deze instellingen vindt je onder her kopje "Over uw winkel" op het "Acumulus instellingen" formulier.

Uiteraard zal deze fout in de volgende versie opgelost zijn.

NB: misschien zijn er nog andere plugins die ook de naam 'VAT Number' gebruiken voor het meta-veld met het btw-nummer.

Waar wordt het btw-nummer opgeslagen?
Als je een andere plugin gebruikt, waarvan onze plugin de gebruikte naam voor het btw-nummer niet herkent, doe dan het volgende:

• • Ga naar een bestelling met verlegde btw.
• • Ga naar het blok "Extra velden"
• • Zoek het veld op met het door de klant ingevulde btw-nummer als "waarde" en noteer de "naam".
• • Ga naar formulier "Acumulus veldverwijzingen" => kopje "Brongegevens voor de klantgegevens" => veldverwijzing voor het "btw-nummer"
• • Vul in: [source::getOrder()::getSource()::get_meta(naam_van_het_extra_veld)]

Helaas is dit vanuit de plugin niet mogelijk. Om een correcte factuur te kunnen maken moeten de verzendkosten toegevoegd worden, anders klopt de prijs niet. Als je wilt dat dit soort regels niet op de pakbon verschijnen moet dat dus op het niveau van de template van de pakbon gedaan worden. Of dit mogelijk is en hoe weet ik niet (de plugin kan via de API niet aangeven wat voor een soort regel het is, dus ik denk niet dat dit mogelijk is)

Ik ben een apart topic gestart over veldverwijzingen: Versie 8 van de Acumulus plugin: veldverwijzingen

Ik denk dat een van de voorbeelden daar precies is wat jij vraagt.

[Wat zijn veldverwijzingen?]

Wat zijn veldverwijzingen?
Om voor een bestelling of terugbetaling een factuur aan te maken in Acumulus worden er veel gegevens naar Acumulus verstuurd. Een aantal van deze gegevens zijn rechtstreeks en ondubbelzinnig uit gegevens van de de bestelling te halen, maar een aantal andere gegevens zijn wat lastiger omdat ze bijvoorbeeld:
    • Gebaseerd zijn op meerdere gegevens van de bestelling. Acumulus werkt met 1 veld voor de naam, de volledige naam, veel webshops werken met aparte velden voor de voor en achternaam.
    • Naar eigen wens ingevuld kunnen worden: Acumulus werk bijvoorbeeld met het veld aanhef, daar kun je iets formeels inzetten als "Geachte mevrouw Jansen"of iets informeels als "Beste Truus".

Om de gebruiker de vrijheid te geven om een de inhoud van een aantal velden zelf in te stellen, maakt de plugin, net zoals Acumulus in haar (factuur)sjablonen, gebruik van veldverwijzingen.

Een veldverwijzing geeft aan welke gegevens van een bestelling of terugbetaling in de webshop gebruikt moeten worden om een veld van een Acumulus (credit)factuur in te vullen.

Wat is er veranderd?
[Dit is een technische uitleg, sla dit gerust over]
De nieuwe manier is een stuk explicieter in wat er gebruikt moet worden. Voorheen kon je iets opgeven als [billing_address_1], en moest de plugin uitvinden dat dit een method op het WC_Order object was van WooCommerce. In de nieuwe manier moet je dit expliciet opgeven en wordt het [source::getOrder()::getSource()::get_billing_address_1()] (source is het uitgangspunt, pak daar de bijbehorende bestelling bij (ook als source een terugbetaling is), pak dan het webshop object van die bestelling (het WC_Order object), en roep daar de method get_billing_address_1() op aan (en dus niet: vraag de eigenschap get_billing_address_1 op).

Voorbeelden (WooCommerce, andere webshops volgen):
    • Aanhef:
        ◦ oud: ["Beste"+get_billing_first_name]
        ◦ nieuw: ["Beste"+source::getOrder()::getSource()::get_billing_first_name()]
    • Klantnotitie:
        ◦ oud: [get_customer_note]
        ◦ nieuw: [source::getSource()::get_customer_note()]

Geef in de commentaren aan als je een ander gegeven wilt gebruiken en er niet uit komt. Ook voor andere webshops.

Wat zijn de gevolgen voor jou?
Helaas kan de plugin deze conversies niet automatisch uitvoeren. Daarom bekijkt de plugin tijdens de update of je veldverwijzingen zelf een waarde hebt gegeven. Als deze er zijn, krijg je een melding op je scherm met de lijst van velden die je dient te controleren. Negeer deze melding dus niet.

[Melding:]

Er zullen wat fouten voorkomen die niet in mijn testomgeving optraden. Ik zal dit hieronder proberen bij te houden, inclusief evt. oplossing.

De onderstaande 4 meldingen zijn nu opgelost in versie 8.0.1

Melding:
DomainException: type: not an allowed value: 0 in .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Data/AcumulusProperty.php:207
Stack trace:
#0 .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Data/AcumulusObject.php(217): Siel\Acumulus\Data\AcumulusProperty->setValue(0, 0)
#1 .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Data/AcumulusObject.php(106): Siel\Acumulus\Data\AcumulusObject->set('type', 0)
Oplossing:
Geef de instelling "Importeer klanten als" onder het kopje "Relatiebeheer" een waarde. In een volgende versie mag dit weer leeg gelaten worden waarmee de default ("Relatie") gekozen wordt.

Melding:
TypeError: Siel\Acumulus\Helpers\Countries::isNl(): Argument #1 ($countryCode) must be of type string, null given, called in .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Completors/Legacy/Completor.php on line 1531 and defined in .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Helpers/Countries.php:26
Stack trace:
#0 .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Completors/Legacy/Completor.php(1531): Siel\Acumulus\Helpers\Countries->isNl(NULL)
#1 ...
Oplossing:
Geef de instelling "Landcode" onder het kopje "Brongegevens voor het factuuradres" op het formulier "Acumulus veldverwijzingen" de volgende waarde:
    [source::getOrder()::getSource()::get_billing_country()|"NL"]

Melding:
TypeError: preg_replace(): Argument #3 ($subject) must be of type array|string, int given in .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Completors/Invoice/CompleteInvoiceNumber.php:51
Oplossing:
Je kunt 2 dingen doen om dit te voorkomen:

• 1 Geef de instelling"Factuurnummer" onder het kopje "Uw factuurinstellingen" de waarde "Laat Acumulus het factuurnummer bepalen (aangeraden)." Dit verandert wel de nummering van de facturen in Acumulus.
• 2 Pas het bestand "Completors/Invoice/CompleteInvoiceNumber.php" aan door regel 3 weg te halen, dat is de regel met:
      declare(strict_types=1);

Melding:
Error: Call to protected method Siel\Acumulus\Completors\Legacy\Completor::changeInvoiceToConcept() from context 'Siel\Acumulus\Completors\Legacy\CompletorInvoiceLines' in .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Completors/Legacy/CompletorInvoiceLines.php:262
Oplossing:
Pas regel 1898 van het bestand .../wp-content/plugins/acumulus/vendor/siel/acumulus/src/Completors/Legacy/Completor.php als volgt aan:
van:
    protected function changeInvoiceToConcept(&$array, string $messageKey, int $code, string ...$args): void
naar:
    public function changeInvoiceToConcept(&$array, string $messageKey, int $code, string ...$args): void

[TL;DR]

De nieuwste versie van de Acumulus voor WooCommerce plugin bevat een aantal grote veranderingen. Alhoewel de meeste veranderingen intern zijn, zijn er toch een paar zaken waar u op moet letten. Merk op dat deze veranderingen ook in de volgende versies van de Acumulus modules voor HikaShop, Magento, PrestaShop, OpenCart, en VirtueMart zullen verschijnen.

TL;DR
Controleer de "Acumulus instellingen"; controleer de "Acumulus Veldverwijzingen"; Meldt alle foutmeldingen, ook als u geen pro-support heeft.

Veranderingen:

• Ondersteuning voor het verzenden van 2 adressen.
        ◦ Nieuw: de plugin zal nu zowel het factuuradres als het verzendadres naar Acumulus versturen. Als boekhoudpakket werkt Acumulus niet met de begrippen factuur en verzendadres, maar met een hoofd en een alternatief adres. Beide adressen kunnen in uw factuur en pakbon templates gebruikt worden. Het grote verschil is dat het hoofdadres gebruikt wordt voor btw berekeningen en controles. Daarom zal standaard het adres dat WooCommerce gebruikt voor het bepalen van btw-tarieven als hoofdadres verstuurd worden en het andere adres als alternatief adres. In de instellingen kunt u dit eventueel aanpassen.
        ◦ Oud: de plugin verstuurde (standaard) alleen het factuuradres.

• Veldverwijzingen (NB: dit is alleen van belang voor u, als u bij de geavanceerde instellingen velden hebt overschreven die veldverwijzingen mogen bevatten):
        ◦ Nieuw: alle veldverwijzingen beginnen bij "source", gebruik :: om door het datamodel te navigeren naar ander objecten en hun eigenschappen.
        ◦ Oud: naast "source" waren er ook directe links naar "order", "refund", "refundedOrder' en nog wat andere objecten.

• Strikter onderscheid tussen getallen en tekst.
        ◦ Nieuw: als er een getal verwacht wordt zal er een foutmelding komen als er een tekenreeks doorgegeven wordt. Voor de plugin is dus iets als 6,- niet acceptabel als prijs. Hierdoor is er meer zekerheid dat wat de plugin verstuurt ook correct is.
        ◦ Oud: in de recente versies was dit al meer en meer het geval. Dus in die zin is de verandering niet heel groot.
        ◦ Consequentie: Dit soort fouten presenteren zich meestal als een mail met als onderwerp "Je Acumulus plugin heeft een technisch probleem". Stuur deze fout naar support – ook als u geen pro-support heeft, en wij zullen kijken of dit een gevolg is van een iets te strikt onderscheid maken door de plugin en indien zo de code iets minder strikt maken.

• Voorbereiden van de programmeercode op meerdere onafhankelijke acties. Denk aan het vesturen van de factuurgegevens, het op betaald zetten van de factuur, het versturen van de pdf van de factuur vanuit Acumulus naar de klant.
        ◦ Consequentie: voor de gebruiker zijn hier nog geen consequenties aan verbonden, maar dit stelt ons in staat om in volgende versies die acties aan te kunnen bieden, elke actie bij de daartoe door u ingestelde bestelstatus.

• Verzameling van bestellingen en kredietnota's die als test zullen dienen voor alle nieuwe versies.
        ◦ Nieuw: bij elke vrijgave van een nieuwe versie zullen we deze verzameling van testbestellingen en retouren gebruiken om te kijken of er onverwachts toch ergens een fout in is geslopen.
        ◦ Oud: dit testen werd grotendeels handmatig gedaan, wat veel tijd koste en daarom wel eens werden overgeslagen als we niet verwachtten dat wijzigingen invloed hadden op het samenstellen van de factuurgegevens.

Deze code is onderdeel van de voorbeeldplugin die op dit forum wordt aangeboden (zie https://forum.acumulus.nl/index.php/topic,3984.0.html). Draaiend in die plugin zal het wel werken. De voorbeeldcode dient wel aangepast te worden aan de omstandigheden, met name dienen niet gebruikte hooks verwijderd te worden.

In een volgende versie van het document zal dit duidelijker vermeld worden.

De code die alleen wordt uitgevoerd bij installatie wordt (onvermijdelijk) minder getest. Hier is nu inderdaad een fout ingeslopen die we zelf nog niet ontdekt hadden. In de volgende versie (7.6.2) zal dit opgelost zijn. Omdat ik midden in wat andere wijzigingen zit kan ik op dit moment niet eenvoudig die nieuwe versie vrijgeven, graag een paar dagen geduld dus.

...
Bedankt voor de info. Ik denk het probleem lag aan dat het BTW nummer niet goed werd doorgestuurd. Deze kwam bij de geavanceerde instellingen niet overeen met de naam van het veld van de plugin die ik gebruik.
Nu ik dit heb aangepast word het BTW nummer goed doorgestuurd.
...

Welke plugin gebruik je nu en wat heb je daarvoor moeten invullen in het veld "btw-nummer"? Omdat de populaire "WooCommerce EU BTW Assistent" niet meer bijgehouden wordt, stappen momenteel veel gebruikers over op een andere plugin. Voor de populaire alternatieven kunnen we support inbouwen voor de door die plugin gebuikte naam van het btw-veld.

Ik heb een artikel geschreven dat beschrijft welke mogelijkheden de plugins bieden m.b.t facturen en pakbonnen:  Zie dit onderwerp op het forum

Ik heb een artikel geschreven dat beschrijft welke mogelijkheden de plugins bieden m.b.t facturen en pakbonnen:  Zie dit onderwerp op het forum. (en ja de hier gevraagde feature wordt besproken)

[Versie]

Versie:
16 november 2022, voor versie 7.4.x van de plugins.
We proberen dit document up-to-date te houden, maar je weet hoe dat gaat in de praktijk, dus geen garanties dat dit bij elke verandering meteen bijgewerkt wordt.

Samenvatting:
Acumulus kan facturen en pakbonnen tonen in een browser; laten downloaden; of als pdf document e-mailen. De plugins voor de verschillende webshops bieden vanaf versie 7.4.x meer ondersteuning voor het gebruiken van deze documenten. Dit artikel geeft uitleg over deze documenten en hoe ze in de plugins te gebruiken zijn.

Omdat op dit forum niet met plaatjes in de tekst gewerkt kan worden, zit het artikel in de bijgevoegde pdf. De schermafdrukken en voorbeeldcode zijn van de WooCommerce plugin omdat die het meest gebruikt wordt en de beschreven functies daar ook al het verst geïmplementeerd zijn.

Heb je vragen, opmerkingen, of suggesties? Schroom niet om je inzichten te delen als commentaar onder dit onderwerp op het Acumulus forum.

De vraag is vaker gesteld en er kan over gediscussieerd worden.

Het verzendadres hoeft niet het uiteindelijke afleveradres te zijn. Ik woon en werk zelf in Frankrijk maar bestel nog wel eens zakelijk in NL. Als de webwinkel niet naar FR verstuurd laat ik het afleveren bij familie/vrienden die toch binnenkort naar ons komen. Voor zo'n transactie is verlegede btw de juiste keuze al dient formeel gezien  de verkoper zich er van te "verzekeren" dat de goederen naar het buitenland gaan. Het verzendadres is daarbij niet het enige mogelijke bewijs.

Voor mij blijft vooralsnog factuuradres leidend

Mbt het 1e probleem:
Met de antwoorden op onderstaande vragen kun je waarschijnlijk achterhalen wat er mis gaat:
    • Is het btw-nummer naar Acumulus verstuurd? Wordt op de relatiekaart opgeslagen.
    • Wat staat er bij de "Omschrijving" (op het overzicht "Laatste boekingen")? Nederlandse btw, levering met buitenlandse btw,  intracommunautaire levering, ...

Het is belangrijk dat de instellingen van de plugin vallend onder "Over uw winkel" en het veld "btw-nummer" (geavanceerde instellingen) correct zijn ingevuld.

Mbt vraag 2:
De totale EU-verkopen komen van Acumulus  (omdat de webwinkel slechts een van de mogelijke verkoopkanalen is). Als deze optelt, worden er dus facturen naar EU consumenten met het standaard NL btw-regime gemaakt. Beide vragen combinerend zou ik dan zeggen:
    • Het btw-nummer wordt niet herkend en dus niet verzonden, waardoor het een factuur met buitenlandse btw wordt.
    • Als er ook in Acumulus geen btw wordt berekend wordt het gezien als btw-vrije of 0% producten/diensten. Aangenomen dat jullie die niet verkopen:
        ◦ De instellingen "Over uw winkel" staan verkeerd, of
        ◦ Jullie ontvangen een waarschuwingsmail hierover maar die wordt niet ontvangen: controleer het "E-mail" adres onder "Uw Acumulus account" of anders jullie spamfolder.

De plugin versie 6.4.0 herkent klanten die in Noord-Ierland wonen op basis van de landcode 'GB' met een postcode die begint met BT. Als de bestelregels producten (kunnen) betreffen zal de factuur als een factuur met EU-btw verstuurd worden. Als de bestelregels  services betreffen of geen btw bevatten, wordt het een factuur buiten de EU.

NB: het is dus belangrijk dat bij klanten uit Noord-Ierland btw in rekening gebracht wordt. Als je voor Engelse klanten de import-heffing niet via de in de webshop aanwezige belastingregels in rekening brengt, moet je dus voor Noord-Ierland een aparte btw-regel toevoegen met landcode = 'GB" en postcode = 'BT*'.

Versie 6.4.0 lost dit op. Deze versie werkt samen met versie 5 van de API, want van beide kanten waren veranderingen nodig om dit goed te introduceren.

NB: Let op: tot GBP 135 is de verkoper verantwoordelijk voor het betalen van de Britse btw/importheffing: zie b.v. https://www.kvk.nl/advies-en-informatie/internationaal-ondernemen/e-commerce/e-commerce-in-verenigd-koninkrijk/

Ik ga je feedback zeker verwerken, ook al zijn ons niet veel voorbeelden bekend van andere gebruikers. De library is n.l. wel bedoeld voor breder gebruik.

1)
Om gebruik te kunnen maken van de library dien je een aantal zaken te programmeren die specifiek voor jouw omgeving zijn. Dit doe je door classes uit libAcumulus te "extenden" in je eigen namespace specifiek voor jouw omgeving. De help voor class Container specificeert aan welke eisen die namespace dient te voldoen, maar dat komt simpel neer op het toevoegen van de naam van jouw omgeving: \Siel\Acumulus\{MijnOmgeving} (zoals is gedaan voor WooCommerce, PrestaShop,...). Dit doe je in een folder in je eigen omgeving niet in de vendor/siel/... folder die Composer voor jou aanmaakt, zodat je die kunt blijven updaten.

2)
Om alleen het communicatiegedeelte te gebruiken, dien je binnen die namespace minimaal de volgende classes en methods te definiëren:
- class \Siel\Acumulus\{MijnOmgeving}\Config\ConfigStore
  * load()
  * save()
- class \Siel\Acumulus\{MijnOmgeving}\Config\ShopCapabilities
  * getShopEnvironment()
  * alle abstract methods van de parent class
- class \Siel\Acumulus\{MijnOmgeving}\Helpers\Log
  * write()

3)
Deze kun je het beste kopiëren van de namespace \Siel\Acumulus\TestWebShop en dan de volgende zaken aanpassen:
- ConfigStore: de plek waar je je config.json opslaat. Maak deze config.json ook aan en vul jouw contractgegevens en het log level in. Hou deze config.json dus voor jezelf, sla deze dus niet op in b.v. een github project, vandaar die rare plek die de in MyTestShop gebruikt wordt. Log level 1 is: ook communicatie loggen.
- ShopCapabilities: de naam en versie van jouw omgeving en de versie van jouw eigen module.
- Log: de naam en plek van je log file. Deze file moet schrijfbaar zijn.

4)
Nu kun je de library gebruiken door *via de Container* een Acumulus ApiClient te verkrijgen. die Container zorgt ervoor dat de benodigde en juiste  classes geïnstantieerd worden. NB: de Container bevat geen autoloader, daar gebruik je composer voor, of als je dat niet gebruikt, SielAcumulusAutoloader.php. De container gaat er dus wel vanuit dat er een autoload mechanisme is voor de classes onder de namespace /Siel/Acumulus.

5)
Voorbeeldcode:

<?php
    $shopNamespace = '{MijnOmgeving}';
    $language = 'nl'; // of 'en'
    $container = new Container($shopNamespace, $language);

    $acumulus = $container->getAcumulusApiClient();

    // Voeg factuur toe:
    $invoiceResult = $acumulus->addInvoice($invoiceData);
    $invoiceResponse = $invoiceResult->getMainResponse();
    if ($invoiceResponse !== null) {
        $token = $invoiceResponse['token'];
        // store token in combination with shop order id for future use.
    }

    // of Zet betaald:
    $token = '...'; // token for the invoice to set to paid.
    $paymentStatus = Api::PaymentStatus_Paid;
    $paymentDate = date(Api::DateFormat_Iso); // today
    $paymentResponse = $acumulus->setPaymentStatus(
        $token,
        $paymentStatus,
        $paymentDate
    );
?>

De phpdocs zijn redelijk compleet, zo ongeveer elke method is beschreven, een groot gedeelte van alle classes, en alle namespaces (in de file documentation.php) die zich in elke (niet webshop-speciffieke) namespace bevindt. Alleen dat soort documentatie is meer ter referentie en te gebruiken tijdens het programmeren, minder om ergens mee te beginnen.

Wat die config betreft, veel instellingen zijn op het niveau van wat een shop kan, of wanneer zaken verstuurd moeten worden. De test config (class \Siel\Acumulus\TestWebShop\Config\ConfigStore) is een minimale config waarmee ik het communicatiegedeelte kan testen, die zou je kunnen gebruiken.

Wat je vervolgens met libAcumulus bereikt is dat je niet zelf meer die xml string moet opzetten, maar dat je met arrays werkt die de xml-structuur nabootsen en die doorgeeft aan de Acumulus Api client. Die client voegt de "basic submit" toe, dus jij hoeft alleen maar het inhoudelijke gedeelte door te geven. Kijk voor voorbeelden in de class met test-aanroepen: \Siel\Acumulus\Unit\ApiClient\ApiRequestResponseExamples, jij zet het 'submit' gedeelte op, de rest doet libAcumulus.

libAcumulus is gegroeid vanuit het gemeenschappelijke dat steeds terugkeert in elke webshop plugin. Omdat het niet vanaf het begin is opgezet met het idee dat onderdelen ervan los ergens anders gebruikt kunnen worden, zitten er meer onderlinge afhankelijkheden in dan gewenst. (Het is geen Symfony of Zend framework.)

In versie 7 worden een aantal van deze problemen aangepakt met het doel om de library ook in te kunnen voor alleen het communicatiegedeelte zonder dat daarvoor custom code nodig is anders dan het instantiëren van de Container en het  het meegeven van een aantal instellingen/opties. Versie 7 is te vinden onder de dev branche, maar daar zal zeker nog het een en ander aan gewijzigd worden.
bv:
- Log => PSR3 logger interface, wat al door veel projecten gebruikt word en wat dus misschien al voorhanden is in jouw omgeving, of anders snel toegevoegd met composer.
- Dat gedeelte van de Config dat nodig is als een $options array doorgeven aan de constructor ipv het hele Config .object.

NB: Dat die constructor niet intuïtief is, is een gevolg van het dependency injection principe, dat er juist voor zorgt dat een class minder kennis hoeft te hebben van zijn omgeving. Gebruik dus die Container die precies weet wat er nodig is om een object te maken. Je ziet dat de meeste webshop modules code als hieronder gebruiken om de boel op te zetten en vervolgens te gebruiken:

<?php
    // Get language
    $languageCode = get_bloginfo('language');
    if (empty($languageCode)) {
        $languageCode = 'nl';
    }
    $languageCode = substr($languageCode, 0, 2);

    $shopNamespace = 'WooCommerce';
    $container = new Container($shopNamespace, $languageCode);

    // Ready to go
    $source = $container->getSource(Source::Order, $order instanceof WC_Order ? $order : $orderId);
    $container->getInvoiceManager()->sourceStatusChange($source);

    // Or:
    $acumulusApiClient = $container->getAcumulusApiClient();
    $token = '...'; // token for the invoice to set to paid.
    $paymentStatus = Api::PaymentStatus_Paid;
    $paymentDate = '...';
    $acumulusResult = $this->acumulusApiClient->setPaymentStatus(
        $token,
        $paymentStatus,
        $paymentDate
    );
?>

NB: Ik ben erg geïnteresseerd in feedback over het gebruik van libAcumulus in andere situaties, dus neem direct contact met mij op (support at burorader dot com) en ik zal jouw bevindingen zeker meenemen in versie 7.

[Versie:]

Versie:
    • 16 februari 2023: voor versie 7.6.x van de plugins.
    • 2 december 2021: eerste versie.

We proberen dit document up-to-date te houden, maar je weet hoe dat gaat in de praktijk, dus geen garanties dat dit bij elke verandering meteen bijgewerkt wordt.

Samenvatting:
Sinds 1 juli 2021 gelden er nieuwe regels voor (afstands-)verkopen aan consumenten in de EU. Bij deze klanten dient u in principe het btw-tarief van het land van de klant te gebruiken. Als u echter weinig aan het buitenland verkoopt, kunt u er voor kiezen om het Nederlandse btw tarief te blijven hanteren. Dit kan tot een buitenlandse omzet binnen de EU van € 10.000,- per kalenderjaar. Zodra deze grens gepasseerd is, dient u per direct en tot het eind van het jaar en het hele jaar daarop EU-btw in rekening te brengen.

Om deze buitenlandse btw te kunnen afdragen is het belangrijk dat de webshop goed ingesteld is zodat van alle verkoopfacturen duidelijk is welke btw is gehanteerd, zodat Acumulus de juiste rapportages kan aanmaken op basis waarvan belasting kan worden afgedragen.

Dit artikel geeft uitleg over hoe deze tarieven toe te voegen en hoe andere btw-gerelateerde instellingen een juiste waarde te geven.

Over dit document:
Omdat op dit forum niet met plaatjes in de tekst gewerkt kan worden, zit het artikel in de bijgevoegde pdf. De schermafdrukken en voorbeeldcode zijn van de WooCommerce plugin omdat die het meest gebruikt wordt.
Heb je vragen, opmerkingen, of suggesties? Schroom niet om deze te delen als commentaar onder dit onderwerp op het Acumulus forum.

Voor een volgende versie:
    • Meer over andere belastingregels (KOR, btw-vrij, 0% btw, verlegde btw)
    • Meer details voor de andere webshops, bijv. of je gebruikersgroepen moet aanmaken voor verlegde btw, of dat je eigenlijk niet zonder extra module kunt.

LET OP: Sinds versie 7.6.0 van de plugin/module/extensie is de instelling "Welke belastingklassen definiëren EU btw tarieven" vervangen door de instelling "Berekent u EU-btw?" Bezoek daarom na het updaten de instellingenpagina en geef deze nieuwe instelling de juiste waarde  Als u WooCommerce met de ""EU/UK VAT Compliance for WooCommerce" gebruikt, dient u ook de instelling "Tax classes used for customer place-of-supply goods" van die plugin goed in te stellen (en goed ingesteld te houden). Deze instelling wordt namelijk als "bewijs" van gebruik van EU-btw bij de bestelling opgeslagen op het moment dat de bestelling aangemaakt wordt. Omdat de Acumulus plugin, zelfs op basis van deze nieuwe instelling niet in alle gevallen kan afleiden of er NL of buitenlandse btw is berekend (vooral niet voor oudere bestellingen), wordt dit opgeslagen bewijs ook gebruikt om dit te bepalen.

Zijn de verzendkosten en/of betaalkosten ook aan 25% Zweedse btw? Of zijn die nog aan de 21% NL btw?

Die laatste melding komt omdat je de onderste optie op het verzendscherm hebt aangevinkt.

Die voorbeeld plugin vindt je als bijlage op https://forum.acumulus.nl/index.php/topic,3984.0.html.

De verwarring zal ook te maken hebben met de woordkeuze: in de Acumulus plugin voor WooCommerce maak je geen factuursjabloon aan, maar kies je een van de in Acumulus gemaakte factuursjablonen. De plugin doet dit echter op basis van een instelling waarbij je alleen per betaalmethode een sjabloon kunt kiezen. De optie om dit ook per land of zelfs per land/betaalmethode combi te kunnen doen is wel eens gevraagd maar (nog) niet gerealiseerd. De optie om dit per product te doen is eigenlijk alleen maar mogelijk in die gevallen waar er maar 1 regel op de factuur staat en daarmee m.i. niet algemeen genoeg. Dus kom je al snel ut op custom code, en daar voorziet onze plugin in. Je schrijft wat regels code met de gewenste business logica in een aparte plugin zodat je onze plugin gewoon kunt blijven updaten. Zie hiervoor de voorbeeldplugin op dit forum.

Nee dit is niet toegevoegd en zal je dus met wat regels custom code moeten doen.

Ik heb dit probleem onderzocht en het ligt niet zo simpel als zij zeggen.

WooCommerce heeft een filter 'woocommerce_hidden_order_itemmeta' dat gebruikt kan worden om meta dat die niet getoond moet worden te verbergen. Als je kijkt naar hoe dit filter gebruikt wordt en hoe andere plugins dit gebruiken is het niet duidelijk dat meta data die met een underscore begint per definitie niet getoond zou worden:

• - WC zelf geeft b.v. in wp-content/plugins/woocommerce/includes/admin/list-tables/class-wc-admin-list-table-orders.php, method get_order_preview_item_html() een lijst van meta data mee waarin de meeste met een _ beginnen. Verderop in die method WC_Order_item::get_formatted_meta_data() aangeroepen met '' ipv '_' voor de parameter $hideprefix, dus meta data die begint met een _ wordt hier niet per definite uitgesloten.
• - De plugin WooCommerce Product Bundles reageert op het filter 'woocommerce_hidden_order_itemmeta' en voegt al zijn eigen meta data, die allemaal beginne met een _, toe aan de lijst van hidden order item meta data.
• - Idem voor de plugin yith-woocommerce-deposits-and-down-payments, die voegt ook al zijn meta data die met een _ beginnen toe aan het filter.
• - De plugin TM extra product options slaat de opties op onder de sleutel _tmcartepo_data en dat zijn dus de opties die je wel getoond wilt hebben.

Dat jullie de eerste zijn die dit melden komt denk ik omdat jullie varianten zoals WooCommerce die zelf levert en TM extra product options binnen hetzelfde product gebruiken, iets wat blijkbaar niet gebruikelijk is, maar wel zou moeten kunnen.

Ik denk dat het beter zou zijn als de ontwikkelaars van de andere plugin het filter 'woocommerce_hidden_order_itemmeta' gaan implementeren en daar hun meta data keys aan toevoegen, ook die met een _ beginnen.

De commissie dien je apart te boeken als (aankoop)factuur. Jij verkoopt iets aan een klant en maakt daarvoor een (verkoop)factuur voor het bedrag dat de klant aan jou verkoopt en de btw-tarieven en bedragen die bij die producten/diensten horen. Blijkbaar verkoop je via een platform en dien je daar commissie af te dragen. Dat platform zal jou periodiek een overzicht sturen met de te betalen (of ws al betaalde of beter nog ingehouden) commissie en die boek jij in als kosten inclusief de over die dienst betaalde btw (dat zal altijd 21% zijn ongeacht of jij aan 0, 6 of 21% verkoopt).

Dit maakt het koppelen van facturen aan af/bijschrijvingen lastig, maar dit is de enige manier waarop je de btw goed ingeboekt krijgt ongeacht de gehanteerde tarieven.

[Installatie-instructies]

Ik denk dat je hier slachtoffer geworden bent van waar ik op de forumpagina met de download voor waarschuw:

Installatie-instructies: omdat PrestaShop bij een update oude bestanden niet verwijderd, blijven oude versies van bestanden die hernoemd of verplaatst zijn gewoon bestaan. Dit kan tot fouten leiden. Daarom raden wij aan om - zeker bij deze nieuwe major versie 5 - de folder /modules/acumulus in zijn geheel te verwijderen en daarna de inhoud van de zip in de /modules folder te unzippen. Daarna in de backend (modules- geïnstalleerde modules - acumulus - upgraden) een update van de module draaien.

En recentelijk zijn voor PrestaShop enkele Form overrides overbodig geworden en dus verwijderd, o.a. het bestand modules/acumulus/lib/siel/acumulus/src/PrestaShop/Shop/BatchForm.php. Als deze bij jou nog bestaat, dan is dat de oorzaak van dit probleem.

Dit betekent dat de bijbehorende library niet goed geïnstalleerd/geüpdatet is. Er is een naamswijziging geweest van deze eigenschap van de class Form, dus jengebruikt niet de meest recente versie van de library. Als je vanaf github hebt gedownload dan moet je zelf de library updaten door ook die te downloaden. Als je de zip die op het forum staat hebt gedownload is er iets fout gegaan bij het uploaden naar de server want ik heb even gekeken en de zip is correct.

Die oudere versies van onze module staan er alleen omdat die (misschien) nog werken met oudere versies van PS, maar, zoals je ondervonden hbt, juist niet met de recentere versies van PS. Gebruik dus 6.2.0.

Het lijkt mij een vereiste voor elke factuur aan wat voor een bedrijf dan ook dat daar de bedrijfsnaam op staat. dit lijkt mij dan ook een fout van de WooCommerce EU VAT Assistant dat deze verlegde btw toestaat.

- Ik zie geen companyname veld in de factuur: voor facturen met verlegde btw zijn het btw-nummer en de bedrijfsnaam verplicht.
- Het feit dat je geen warnings krijgt lijkt er op te duiden dat je ingesteld hebt dat je producten en/of diensten aan 0% btw of btw-vrij aanbiedt. Klopt dit? Zo ja, als de factuur alleen maar bestaat uit btw-vrije producten/diensten, dan dient het factuurtype ook 1 te zijn en niet 3. Klopt dit niet, en het veld vat-rate-lookup geeft dit eigenlijk al aan, ga dan eerst naar de Acumulus instellingen en loop alle  instellingen zorgvuldig na.

Daar heeft de Acumulus plugin helemaal niets mee te maken. De plugin wijzigt helemaal niets aan een bestelling of retour, nooit, de plugin volgt de winkel en reageert slechts op statusveranderingen.

Mag ik begrijpen dat je facturen vanuit Acumulus verstuurt en niet vanuit de webshop? (Dit wordt idd als feature aangeboden maar heeft wat gevolgen, met name als je de factuur al wilt versturen voordat de bestelling is afgerond.)

De Acumulus plugin zal de factuurgegevens niet automatisch opnieuw versturen als een bestelling opnieuw een van de opgegeven statussen bereikt,  maar aangenomen dat je het opnieuw versturen forceert (ws vanuit de metabox op de "wijzig bestelling" pagina), dan zal dit wel gebeuren, de factuur is immers gewijzigd en dient dus ook opnieuw verstuurd te worden.  Echter hier zit ook het probleem: een definitieve factuur dien je niet te wijzigen. Als een klant een afgeronde bestelling wijzigt, moet je formeel dus een creditfactuur aanmaken en een nieuwe factuur voor het vervangende product. Beide nieuwe facturen dienen vervolgens naar de klant gestuurd te worden.

In het topic https://forum.acumulus.nl/index.php/topic,4150.0.html (in het forumn "Webshopkoppelingen - Downloads"  kun je zien dat de plugin via de market place van OC te downloaden is:
De Acumulus extensie voor OpenCart 2.3 is te vinden op de OpenCart Marketplace door te zoeken op acumulus: https://www.opencart.com/index.php?route=marketplace/extension&filter_search=acumulus&filter_license=0.

Het verschil is dat jij nu alleen de plugin hebt gedownload, niet de bijbehorende library (die trouwens ook als apart github project te downloaden is).

- Is de plugin geactiveerd?
- Staat de plugin wel in de lijst met plugins?
- Zo ja met welke status?
- Staat er iets in de PHP of WP log?
- Is er een Acumulus log ("WooCommerce - Status" -  "Tab Logs" -  Is er een acumulus-xxxxxx.log in de dropdown?

Met de antwoorden op deze vragen kunnen we, indien nog nodig, weer verder kijken.

Voordat ik jouw 2 vragen beantwoord, eerst even wat opmerkingen:
ad b) Dit kan ook automatisch door in te stellen bij welke statussen de factuurgegevens van een bestelling naar Acumulus verstuurd moeten worden.
ad c) Wat bedoel je met definitief aanmaken?  Als ze als concept verstuurd worden, is mijn eerste reactie dat er iets fout gaat, ofwel vanwege de instellingen ofwel iets wat de plugin over het hoofd ziet c.q. waar deze de fout in gaat.
ad c) Dit zou dus De bepaling van het factuurtype kunnen zijn dat je blijkbaar in bepaalde gevallen dient te corrigeren. Als de plugin voldoende informatie heeft,  zou een factuur voor producten naar buiten de EU correct getypeerd moeten worden (type 4). Dit vereist echter wel dat WooCommerce dit ook goed doet (en dus geen btw rekent).

NB: Recentelijk hebben we gezien dat de keuze van de plugin om bijkomende kosten, bv verzend of betaalkosten, altijd als service aan te duiden. niet helemaal correct is. Het is beter als deze het hoofdbestanddeel (van de echte "regels") van de factuur volgt. In de volgende versie zal dit ook zo zijn. Ik heb even in de code gekeken en dit lijkt niet de oorzaak te kunnen zijn van het niet vast kunnen stellen van factuurtype 4 voor producten buiten de EU.

Antwoord 1) De plugin kent momenteel een instelling voor keuze van het factuursjabloon op basis van betaalstatus. Keuze hiervan op basis van betaalstatus  EN land  is momenteel niet mogelijk via de instellingen. Het is echter wel mogelijk om via wat custom code die regeert op een filter van onze plugin, de factuur aan te passen voordat deze naar Acumulus wordt verstuurd. Zie hiervoor de voorbeeldplugin die via dit forum is te downloaden (nog even wachten op versie 6.x hiervan omdat de huidige download, versie 5.x niet compatibel is met versie 6.x van onze plugin). We gaan deze feature trouwens heroverwegen voor een volgende versie, maar dat kan nog even duren en we weten ook nog niet hoe dit er dan uit zal gaan zien, dus voorlopig lijkt het schrijven van wat custom code de snelste en zekerste manier.

Antwoord 2) Dit kan door op het "Acumulus geavanceerde instellingen" formulier de optie "Verstuur de factuur als PDF vanuit Acumulus." onder het kopje "PDF Factuur" aan te zetten. Daarvoor dient de factuur dus wel correct verstuurd te worden, d.w.z: niet als concept, en wil je dus het factuursjabloon correct ingesteld hebben, zie antwoord op vraag 1.

De plugin volgt de webwinkel. Omdat zowel BE als NL een 21% tarief kennen, zou de plugin  in verwarring kunnen raken over of het nu wel of niet buitenlandse btw is. Daarom is er ook een instelling 'Over uw winkel' - 'Welke belastingklassen definiëren EU btw tarieven?' (en eigenlijk ook 'Verkoopt u producten of diensten waarbij u EU btw moet hanteren?'). Het lijkt er op dat er met deze instelling iets mis is, zorg ervoor dat jouw producten gewoon het NL btw tarief als belastingklasse hebben en dat die klasse niet is aangemerkt als EU btw tarief.

Nee, je bent niet de enige, maar heel veel zijn het er volgens mij ook niet. Op zich zou deze fout niet zo maar mogen optreden, want pas als het verzenden verkeerd gaat en de lock wordt niet opgeruimd kan dit gebeuren. De php code doet altijd een poging om de lock te verwijderen, ook in geval van min of meer ernstige fouten, alleen in php zijn niet alle fouten af te vangen, soms stopt het programma er mee.

Dit gaat idd fout. Om dit snel op te lossen voer je deze query via bv phpmyadmin uit:

delete from {prefix}acumulus_entry where entry_id = 1;

Boekstuknummer 1 wordt gebruikt voor een speciaal geval, nl. om te beveiligen tegen dubbele verzending. Als je de tabel bekijkt zul je bij dat record in het veld token de tekst "Send locked, delete if too old" zien staan. Bij het inbouwen van die beveiliging had ik de unique restrictie van index idx_acumulus_entry moeten verwijderen. Dit zal nu in een update functie van de volgende versie gebeuren, maar je kunt dat nu ook al handmatig aanpassen, ook via phpmyadmin.

De plugin wordt zeer actief bijgehouden, alleen de topic titel op dit forum is ons ontgaan. Als je de plugin via je dashboard installeert zul je zien dat in de plugin de zogeheten "tested up to" waardes worden bijgehouden ne nu hier op staan:
* Requires at least: 4.2.3
* Tested up to: 5.4
* WC requires at least: 3.0
* WC tested up to: 4.1

Meer info vind je als help bij het veld "Gebruiker" inhet isntellingenformulier van onze plugin: 'Let op dat u de gegevens van een gebruiker van het type "API-gebruiker" invoert. Als u die nog niet heeft, log dan in op Acumulus en voeg een gebruiker toe onder "Beheer → Gebruikers → Gebruiker toevoegen". Vul "API - Gebruiker" in als "Gebruikerstype".'

Als je deze gebruikersgegevens ook gebruikt om in te loggen op de Acumulus website zelf, dan raden wij aan om een nieuwe gebruiker aan te maken, anders is het wijzigen van het gebruikerstype afdoende.

Voor je andere websites dien je dezelfde wijzigingen door te voeren. Dwz als je een nieuwe gebruiker aanmaakt van het type 'API-Gebruiker' dien je die gegevens overal te wijzigen. Als je het gebruikerstype wijzigt, werkt dit voor alle websites die gebruik maken van dat account.

Sinds 5.9.0 kan er idd iets fout gaan. In de volgende release zal het opgelost zijn, maar omdat er een eenvoudige workaround is, is er ng geen volgende release vrijgegeven.

Als workaround hoef je alleen maar op het verzoek om onze plugin te reviewen (de melding boven aan het scherm) op "Liever niet nu" te klikken of, en wat ons betreft heeft dat de voorkeur , op "OK, Breng me er heen". Dan ben je voor enkele weken (of altijd) van die melding en daarmee de fout af.

Die eerste fout (betaaldatum) is toevallig van de week ook door iemand anders gemeld en zal in de eerstvolgende versie verholpen zijn.

Dat 2e lijkt op meta data die door WooCommerce toegevoegd wordt aan refunds (file wp-content\plugins\woocommerce\includes\wc-order-functions.php, regel 787, functie wc_restock_refunded_items()) en vervolgens door Acumulus als een variant of een optie gezien wordt. Of dit op dezelfde regel of op een nieuwe regel gezet wordt is afhankelijk van de instellingen mbt "Opties of varianten" op het geavanceerde instellingen scherm. Ik zal eens kijken naar hoe dat ook al weer werkt dat toevoegen van opties en varianten, want dar is al lang niets meer aan veranderd, maar misschien dat WC zelf dus iets veranderd heeft.

Na installatie is de module geactiveerd. Dat het overzicht zegt dat die disabled is, is een vreemde kronkel van OpenCart(3) die ik niet begrijp. (De OpenCart documentatie voor ontwikkelaars is belabberd, nieuwe "features" worden niet beschreven, je moet de werking maar uitzoeken door de code na te pluizen.)

Kun je zo'n factuur die fout gaat nogmaals versturen naar Acumulus , maar dan in testmodus? (menu-item WooCommerce - Verzend facturen naar Acumulus"). Stuur de mail die je ontvangt door naar woocommerce at acumulus punt nl, (refereer even naar dit topic) dan zal ik er naar kijken.

Op de 2e vraag is het antwoord ja, zie https://github.com/SIELOnline/libAcumulus. Documentatie is mbv phpdoc in de code v.d library zelf verwerkt.