Berichten

Als ik het systeem goed begrijp wel.

Omschrijving   Periode   Betaal-registraties   Status
Boekperiode Q1-2020   01-01-2020 t/m 31-03-2020   Geblokkeerd    Gesloten
Boekperiode Q2-2020   01-04-2020 t/m 30-06-2020   Geblokkeerd    Gesloten

Toevallig sinds kort een nieuwe medewerker die de administratie overneemt en nu wilt gaan werken met deze periode afsluiting.
Alleen het valt ons op dat als je nu een aanmaak datum hebt van bijvoorbeeld 1-07-2020 en de betaal datum in het verleden ligt 29-06-2020 je deze alsnog kunt wijzigen waardoor je de saldo's van de gecontroleerde rekeningen omzeep kunt helpen in de administratie.
Het is voor ons juist de bedoeling dat een gecontroleerde periode compleet afgesloten is en niet meer bewerkt kan worden als deze functie aan staat. Dus ook niet een nieuwe factuur met een betaal datum in het verleden.

Sinds dit jaar ben ik bezig met de eenmanszaak om te zetten in een bv en tegelijk met een tweede bv te starten.
Nu heb ik dus in eens in plaats van 1 acumulus administratie er 3. Daar komen straks nog de 2 holdings ook bij wat het totaal op 5 brengt.

Nu is dat allemaal erg verwarrend als deze interfaces er allemaal precies hetzelfde uit zien.
Het zou prettig zijn als het mogelijk is per administratie een eigen kleur te geven (wat nu blauw is veranderen in rood, groen of kleur naar keuze).
Dan weet je direct of je in de juiste administratie zit en zo voorkom je snel fouten.

Ook merk ik nu dat het vrij lastig is om van administratie te wisselen, door de veilige (lastige) wachtwoorden van tegenwoordig is het onthouden haast geen doen meer dus moet ik steeds via mijn passwoord manager de inlog gegevens aanpassen.
Zijn hier work arounds voor, hoe gaan de boekhouders hier op acumulus mee om die veel meer dan 1 administratie in beheer hebben? Neem aan dat er methodes zijn om hier mee te werken.
Ik gebruik op dit moment maar even meerdere browsers naast elkaar om dit te omzeilen.

Wij zouden deze functie ook erg welkom vinden .

Hallo Erwin,

Opencart doet dit prima het is echt een (fout) in acumulus .

Bij verkoop naar buitenland moet officieel de btw van het land van afleveren gehanteerd te worden.
De BTW in opencart wordt ook daarop gebaseerd (afleveradres).
Het punt is zolang een ondernemer onder het drempelbedrag blijft is er niets aan de hand en mag die de Nederlandse BTW hanteren.
Voor belgië is dit bedrag bijvoorbeel 35.000 wat redelijk snel gehaald zal worden als je zaken doet met belgië.

Dit houdt in dat we voor leveringen aan belgië de btw moeten hanteren van dat land. Nu is dit toevallig hetzelfde percentage 21% echter moet er ook aangifte gedaan worden in België vanaf dat moment.
Deze functionaliteit is nu nog niet echt meegenomen in acumulus algemeen we kunnen inmiddels wel filteren op land voor de BTW dus het is terug te herleiden.
Echter de situatie kan dus ontstaan dat het factuur adres in Nederland ligt en het aflever adres in belgië op dat moment is het voor de BTW een belgische btw transactie

Belastingdienst leuker kunnen we het niet maken maar makkelijker al helemaal niet 

Al met al een best gecompliceerde situatie wat naar mijn mening zeker wel aandacht zou mogen krijgen van acumulus daar ik steeds meer mensen hier zie die vragen stellen over deze drempel bedragen met buitenlandse transacties.

Ik weet niet of een van deze meelezen in dit deel van het forum?
Maar dit staat op de diverse sites onder andere van de belastingdienst.

Wij zijn diverse dingen aan het automatiseren met de boekhouding nu viel echter op dat in acumulus het factuur adres gebruikt wordt binnen Opencart voor de BTW berekening.
Hierdoor ontstaat de situatie dat bij het overschrijden van het drempelbedrag naar België de BTW niet juist wordt geboekt.

Volgens de belastingdienst moet de BTW berekend worden in het land waar de prestatie wordt verricht.
Nu gaat dit dus fout als de klant een factuur adres in nederland opgeeft en een aflever adres in belgië.

Hallo Erwin,

Settings lijken goed te staan daar zie ik niets vreemds.
Krijg overigens ook geen foutmelding mail en ze staan ook niet onder concepten.
ze worden gewoon totaal niet overgedragen tot ik ze met de hand overdraag door de bestel status te veranderen naar degene waarop het systeem moet reageren.

Zal kijken of ik de logs eruit kan krijgen en dan een ticket aan kan maken.

Hallo erwin,
De foutmelding bij het handmatig omzetten is daarmee opgelost .

Helaas blijft het probleem dat de boekingen niet automatisch worden overgezet.

[notice]

Hallo,

Afgelopen week hebben we naar diverse tests de mollie omgeving geupdate naar versie 9.0.0 om de klanten ook de optie voor klarna te geven.
Op een paar kleine bugjes na ging dit vrij vlekkeloos. We merkten wel dat het al wat problemen gaf met de acumulus koppeling zodoende ook deze geupdate naar de laatste versie.

Nu blijkt echter dat alle orders die via mollie binnen komen niet automatisch worden doorgezet naar acumulus.
Als ik ze  handmatig nogmaals in de betreffende bestel status zet dan komen ze wel door naar acumulus echter met een popup waar de volgende foutmelding in staat:

syntaxerror unexpected token < in JSON position 0

OK

notice Undefined index nature in home/xxx/xxx/system/library/siel/acumulus/src/invoice/completor.php on line 336

uhmm nou dan heb je nog wel een uitdaging met thermische bonnetjes... die gaan 7 tot 9 jaar niet halen dan zijn ze echt blanco ook al zitten ze in een dichte map in de kast.
Zelf scan ik het allemaal in wel met alle informatie van de bon erop. Dus niet een stuk bon overslaan maar echt de geheel bon inscannen ook al is het soms een stuk reclame tekst onder aan de kassabon.
die kun je na 9 jaar nog prima uitprinten en is gewoon leesbaar. Ik heb soms kassabonnen die na 1 week op de plank al slecht leesbaar zijn geworden.

Momenteel staat acumulus maar 1 kopje leningen toe.
Echter met de huidige markt is het niet geheel onlogisch dat een zzper al snel 2 of mogelijk zelfs meer leningen heeft (auto + investeringen / bedrijfspand etc).
Helaas is het nu onmogelijk deze leningen goed te splitsen in acumulus waardoor het op de grote hoop wordt gegooid.
En als er dan ergens een fout insluipt is het ook nog eens zeer lastig om goed te filteren op balans boekingen waar de grootste deel van boekingen onder valt.

Ik heb in vrijwel alle boekingen de term lening gebruikt echter het geval wilt dat sommige klanten de term lening ook in hun naam hebben staan.
Je raad het al meer dan 300 resultaten om door te spitten.

Momenteel heb ik mijn financial lease van de auto gesplitst van de andere lening doormiddel van een aparte rekening maar ik heb nu zo langzamer aan nog meer rekeningen dan de overheid.
het zou erg fijn zijn als leningen gewoon geplaatst kunnen worden waar ze horen maar wel op een beter beheersbaar model dan dat het op dit moment is.
je kunt aan een balans boeking helemaal niks behalve een omschrijving hangen dus filteren hierop is onmogelijk.

Hallo Bert,

Na 1 dag verwijderen is ook niet handig dat begrijp ik ook weer .
Iets opnemen als dat de geldigheid duurt tot het verwijderen van de gegevens lijkt mij voldoende dat staat ook in de meeste verwerkingsovereenkomsten die ik zelf heb waarvan 90% op basis is van voorbeelden uit instanties die daarin thuis zijn.

Toevallig met de laatste details bezig van de GDPR.

Als webshop is het best wel een gedrocht om alles goed in te voeren.
Nu viel mij alleen iets op in jullie verwerkers overeenkomst:

Artikel 2 - Duur en einde van de overeenkomst
De opdrachtnemer en opdrachtgever zijn slechts aan de bepalingen van deze verwerkersovereenkomst verbonden, gedurende de termijn dat de opdrachtgever rechtmatig in het bezit is van een geldige licentie (abonnement) waarmee deze zich toegang kan verschaffen tot de applicatie.
Ingeval de opdrachtgever niet (meer) over rechtmatige toegang tot de applicatie beschikt, zal opdrachtnemer zich inspannen binnen redelijke termijn, doch uiterlijk binnen tien maanden de bij opdrachtnemer opgeslagen gegevens duurzaam van alle gegevensdragers te verwijderen.

Ik begrijp jullie standpunt maar de wet gaat hier toch echt tegen in.. Want zoals het er nu staat houdt het in dat jullie nog 10 maanden de gegevens op de servers kunnen houden en gebruiken zonder de verwerkersovereenkomst na te leven.
Nou ga ik er vanuit dat dit niet met kwade bedoeling is maar daarmee maak je wel je hele verklaring in een keer ongeldig. De verwerkersovereenkomst loopt inderdaad door tot het einde van de contractuele verplichtingen. Echter blijft deze van kracht zolang de verwerker nog beschikking heeft over persoons gegevens van de opdrachtgever.

Misschien handig om dit anders te formuleren / aan te passen? 

of zie ik ergens wat over het hoofd?

Hallo erwin,
Ik neem aan dat dit dan is aangepast? Want die settings daar zijn hetzelfde als de vorige installatie bij mij.
De orders worden doorgezet naar acumulus bij "uw bestelling is in behandeling" dat is geen order complete status wat ook logisch is maar daar wordt wel de betaling afgehandeld.
Ik kan het daar ook niet aanpassen want dan gaat het hele systeem op de schop van webwinkel en zijn alle statistieken onbruikbaar.

Het lijkt er dan ook erg op dat dit recent gewijzigd is?
Is er een eventuele work around methode? Want met de hand 10-20 orders per dag bijwerken is geen pretje.

Vorige week ben ik over gegaan naar een nieuwe webshop.
Echter kan ik nu nergens terug vinden waar ik de setting zo instel dat betalingen die binnen komen meteen als betaald geboekt worden.
Daar dat ik ca. 10 boekingen per dag krijg vanuit mollie en de verwachting is dat dat alleen maar meer gaat worden is het veel werk om deze achteraf allemaal op betaald te zetten.
Aangezien ze pas doorgezet worden als mollie succesvol is afgehandeld zijn deze betalingen altijd al voldaan.

Zie ik iets over het hoofd?

Volgens mij missen ze dan toch echt het stukje openstaande rekeningen?
In dit geval specifiek de debiteuren.

Nu moet ik diegene de volledige boekhoud autorisatie geven omdat ze die informatie nodig heeft om mensen na te bellen op de betaling.
En daarmee ook alle financiele informatie over het bedrijf.

Iets wat ik nogal mis nu mijn bedrijf steeds groter wordt.
Is het toekennen van meer specifieke regels aan gebruikers.

Bijvoorbeeld iemand die alleen de verkoop facturen doet en kan zien wat er openstaat aan facturen.
Dus die puur alleen facturen mag aanmaken en kan zien of deze betaald worden of niet.

Op het moment kan je alleen kiezen uit 3 opties: invoerder, gebruiker, beheerder.
En je kunt alleen lezen aanzetten. Maar of ze zien de gehele boekhouding en kunnen niets invoeren. Of ze kunnen alleen invoeren.
Een combinatie van beiden is helaas niet mogelijk. een pakket als e-boekhouden biedt veel meer opties hierin maar acumulus bevalt gewoon erg goed in gebruiks gemak.

Hallo Guido,

De pin transacties (mypos) worden per stuk verwerkt daar dat de webshop (opencart) gekoppeld is aan acumulus en zelf de facturen opmaakt en instuurt in de boekhouding, ook de kassabonnen in de winkel worden via de webshop verwerkt. Voor 95% van de transacties is dat dan ook geen probleem. Echter komen er wel eens situaties voor waardoor het wat verwarrend is zo nu en dan. en dan is vooral het uitzoekwerk erg lastig.

hallo guido,

Mijn pin automaat heeft gewoon tijd registratie op de transacties.
Mijn webshop heeft deze ook, echter in acumulus staan deze op een andere volgorde.
zoals je zult begrijpen zijn er een behoorlijk aantal transacties op de pin automaat en een fout is snel gemaakt met handmatig invoeren op de terminal.
Helaas is het nu vaak een groot zoekplaatje waar de fout zit omdat de transacties niet op volgorde staan van de transactie tijdstip.

Is het mogelijk om ook de tijd als sorteer methode toe te gaan passen van het bestel moment.

ik zit nu vaak te spitten op kasverschillen waar iets mis gaat, helaas heb ik soms dagen met 50 transacties en bij acumulus staan deze dan geheel random in de lijst.
zeer vervelend aangezien de banken wel werken met tijdsnotatie en mijn webshop ook.
dit kost mij altijd zeer veel zoek tijd en uiteindelijk papier om de fout boven water te krijgen.

of zijn hier betere oplossingen voor?

Dat zou helemaal super zijn .

Ik denk dat het voldoende is om een kolom toe te voegen in het overzicht crediteuren met geplande betaaldatum.
Daarin staat dan of een toekomstige datum of nog niet betaald.

En eventueel een uiterste betaaldatum als optie maar vooral de eerste optie zou al 90% helpen aan het op tijd betalen van de facturen .

Is het mogelijk doormiddel van een indicator of andere notitie om te zien dat een factuur in de toekomst betaald staat?
Nu blijven facturen bij de tabblad openstaande facturen staan tot de geplande betaal datum verstreken is.

Veel facturen hebben 14 - 30 dagen betaaltijd en ik boek deze dan ook met een toekomstige boeking in via mijn bank.
Echter heb ik nu geen goed overzicht of dat een factuur al gepland staat om betaald te worden of niet.

Daarnaast hebben we geen mogelijkheid om een verval datum in te zetten zodat we kunnen zien of we wel netjes onze facturen op tijd betalen.
Mogelijk dat dit ook nog iets is wat in de toekomst veranderd kan worden.

Zelf heb ik inmiddels met ruim 200 verkoop en 100 inkoop facturen te maken per maand dus het overzicht ben ik soms al snel kwijt met deze hoeveelheden.

Maar die zijn waarschijnlijk zwaar in de minderheid, dus dan dit lijkt me nog steeds een wenselijke feature voor de meerderheid van de gebruikers

Mollie / ideal is een van die voorbeelden.
En dat wordt toch zeer veel gebruikt door veel webshop ondernemers gok ik zo

- Zoek op wat het Ondernemings-vermogen eind vorig jaar was (uit IB-aangifte 2014).

Ik neem aan dat dit voor dit jaar gestarte bedrijven gewoon 0 is?

Hallo Erwin,

In opencart staat dit heel duidelijk in de database vermeld.

oc_order -> payment_code

Is er een optie om de betaal methode vanuit opencart automatisch mee te nemen naar acumulus?
Nu moet ik vaak handmatig nalopen welke facturen betaald zijn met bijvoorbeeld paypal of bankoverschrijving.

Ik gebruik op het moment 4 betaal methodes actief:
-Ideal (mollie)
-bankoverschrijving
-paypal
-contant

Binnenkort komt daar ook nog pin bij.
Het zou fijn zijn als de koppeling zelf herkent met welke methode er betaald is in de webshop en dit meeneemt naar acumulus.
Vermoedelijk zal er dan ergens aan gegeven moeten worden welke rekening aan welke betaalmethode hangt?

Allereerst bedankt voor je reactie.

Toenadering met de importeur heb ik zelf meerdere malen getracht, echter wilt de importeur geen zaken doen met webshops.
Daarnaast rekent de nederlandse importeur prijzen die hoger liggen dan de verkoop prijzen in duitsland.

De fotos die ik gebruik komen vanaf mijn duitse leverancier, en zijn van het merk niet van de importeur.
Bij 2 producten is er een nederlandse tekst doorheen geslipt die praktisch 1 op 1 was met die van de importeur. Deze zijn reeds verwijderd.
Het is ook niet de fabrikant die dreigt maar de importeur zelf.
Echter elk dialoog of tegen reactie wordt van hun zijde domweg niet op gereeageerd.

Mijn situatie is in deze markt nogal uniek, en dat heb ik al reeds meerdere malen gecommuniceerd met deze importeur.
Ik ben niet gewoon maar een webshop, de artikelen die het betreft zijn voor mij als aanbod naar de klant om het geheel compleet te kunnen leveren.
Naast de producten die ik verkoop in mijn webshop ontwikkel ik zelf ook heel veel eigen producten die daarop aansluiten en het aanbod naar de klant compleet maken.

Zomaar een winkelpand vinden is dan ook geen gemakkelijke opgave omdat ik niet alleen een showroom nodig heb dan maar ook een werkplaats.
Een combinatie die nagenoeg niet te vinden is in deze regio of dermate onbetaalbaar dat het niet haalbaar is. En een paar zware industrie machines in het centrum plaatsen lijkt me ook niet wenselijk .
Los van het feit dat het hier al sowieso 2 aparte ruimtes moeten zijn.

Om nu toch eens duidelijkheid hier over te krijgen en nu weer een (blaf)mail te hebben ontvangen van een importeur ben ik toch benieuwd naar nog hardere onderbouwing van dit verhaal.

Ik heb een webshop zonder fysieke winkel, zodoende willen verschillende importeurs niet aan mij leveren.
Dat dit geen probleem hoeft te zijn is mij ook bekend, ik heb dan ook al enige tijd goede contacten met duitse leveranciers (winkels).
Destijds heb ik voor mijn gevoel al goed uitgezocht hoe het zat met het uitputting van het merkenrecht binnen de EU.
Buiten de EU brand je je vingers hieraan, maar binnen de EU is een vrij verkeer van goederen.

Nu claimt een importeur dat ik inbreuk maak op het merkrecht / auteursrecht omdat ik foto's, teksten en logos gebruik van hun.
De betreffende importeur heeft nu dus per mail laten weten dat deze verwijderd dienen te worden binnen 7 dagen (wat mij ook geen redelijke termijn lijkt nog daar gelaten).

Wie heeft hier meer ervaring mee en hoe hier mee om te gaan? de KVK is al van mening dat de importeur pech heeft en zich maar moet melden bij degene met wie hij een contract heeft.

heb een mail gestuurd.

Hallo Guido,

Ben er nog eens doorheen gelopen.
Alles in acumulus lijkt goed te staan.
Op blad 2 staat duidelijk: Buitenland binnen de EU, GB - verenigd koninkrijk.
Maar bij de btw aangifte vind ik deze niet terug onder de kop 3 levering aan landen binnen / buiten de EU.

gaat er ergens anders nog wat mis?

Acumulus module 3.6.3 (API: 3.8.0-dev) voor OpenCart 2.0.1.1.

Vermeldt aub deze gegevens bij een supportverzoek.

ik zie ook dat het land verdwijnt bij het overnemen naar acumulus.
In de verzend tool (sendcloud) is alles wel gewoon bekend en ook in opencart is alles bekend.

Korte vraag waar ik het antwoord niet direct op vind.
Ik gebruik Opencart welke automatisch koppelt aan acumulus, Erg handig en scheelt mij uren aan werk.
Echter blijkt er in de koppeling / instellingen niet meteen duidelijk gemaakt te worden wanneer een levering buiten NL is.
Het komt wel eens voor dat ik aan België en Duitsland verkoop.

Ik dacht dit achteraf aan te passen bij deze facturen maar dat kan ik ook nergens doen zover ik kon vinden?
Deze facturen handmatig opnieuw inboeken is ook niet echt een optie dan kan ik 4 uur bezig zijn voor 1 factuur in sommige gevallen.(50 artikelen uit de webshop besteld)

zie ik iets over het hoofd?

dat zou ik best willen maar onder welke term kan ik dit soort bedrijven vinden?

Normaal gesproken heb ik alleen kleine paketten uit china en dat gaat via de normale afhandelaars postnl, dhl, fedex, etc.
Nu ben ik echter bezig met de aanschaf van een laser machine. De nederlandse markt is hierin klein en de enkele aanbieders die er zijn zijn stevig aan de prijs.
Daarnaast heb ik wat specifieke eisen en moet de machine aangepast worden (waar beter dan dit te laten doen in de fabriek).

Nu zit ik echter alleen met de levering doordat dit niet meer per normale afhandelaar kan (of je betaald een vermogen) dit zal per zee vracht gaan in een houten krat die weer in een container zit.
De fabriek biedt nu CIF levering aan, inmiddels heb ik daar al het nodige over opgezocht en dit houdt in dat hun alleen zorg dragen voor levering tot aan rotterdam incl. verzekering. Maar het vervoer van rotterdam haven naar mijzelf moet ik dan zelf regelen.

Nu probeer ik echter om dit in kaart te krijgen wat er dan allemaal geregeld moet worden. Ik beschik over een artikel 23 verklaring dus ik mag btw vrij invoeren.
Maar de machine zal door de douane heen moeten (invoerrechten), dan heb ik nog wat dingen kunnen terugvinden over container kosten loskosten opslagkosten etc etc.

maar echt concreet vind ik hier geen duidelijke informatie over.
De fabriek werkt met de forwarder company: ECU-Line,

Wat ik duidelijk probeer te krijgen is wat zijn de bijkomende kosten en hoe moet ik het transport verder regelen? Ik verwacht dat ik met een aanhanger het niet zomaar zelf op kan halen (ook al past het daarin)
wie heeft hier al eerder mee te maken gehad? en waar moet ik opletten?

Afmetingen: 1425x820x1610mm, 200KG