mcarcadex

Hi, im trying to find a best case to fix a problem im facing. I have a single-man-business, and is not obligated to pay VAT tax before it goes over a certan yearly limit (that i now have reached). Lets make an example of having a product for 100 NOK. Since it is a tax of 25%, i can then either let the price on the package stay as is (user will then need to pay 125 NOK), or drop the price to 80 NOK (100 NOK with taxes). I will then drop the price to 80NOK so the total with taxes will be 100NOK. Another thing i want, is that the order form always lists the price with tax included (Since i tax every customer regardless of country of origin) I think this is a bug, but i dont know: if i make a package for 100 NOK, and set up an inclusive tax, it will stay in the order form as 125, and 125 in the invoice. If i make exclusive tax rule (25%), it will say 100NOK in total in the order form (Total due today: 100 NOK), but 125NOK in the invoices. Another bug too: If a user buys a service for 80 NOK, and with a configurable option for 80NOK, the total is then 160NOK (200 NOK with taxes) Since i have the "Allow Prorated Credits to be Issued for Service Downgrades" on, the user can then remove the config option, that i think the user should be able to do, then the user is granted almost 100 NOK (minus one day), and if he pays for another service, its still a whole 25% TAX. The tax report says that i then need to pay 60 NOK, that means im paying 40% tax (30% of the total that the user paid), when tax is paid and the user gets money back for a service downgrade, i think it should grant less tax on the invoice he buys next with his credit note, since its already taxed? There may be a language barrier, but just ask if some of the things was unclear.

Looks like its the same problem as CORE-1602, and there is no api calls that "reset" the ip and port in the pastebin i posted. Is there a quick fix i can do? if not, looks like this issue: (CORE-1603) could fix it (beacuse you can specify the daemon at creation)

Is it possible to get this bug fixed? @Tyson

The bug that im refering to is the one above. The one that is fixed, but requires me to update the module is "CORE-2508 Multicraft: Add support for validating service edits" (Blesta 4.1.0) So if i update, i fix a bug, but i get the "new" bug, the new bug is described in the first post.

What version of multicraft is blesta tested with?

The ip is from the node10, when it switches daemon to node11, the ip stays the same. The ip of node11 is 144.76.111.29 (ip that its not switching to).

Hi, im currently running blesta 4.4.2, but im actually using version 1.2.4 instead of 2.1.0 on the multicraft module beacuse of bugs, but now i wanted to fix another bug that is fixed in the 2.1.0 version of the multicraft module. This is the bug that is not fixed: The package has a configurable option to use daemon id 11, but when the server is created, multicraft chooses witch daemon to use (it chooses the daemon with the most ram free from what i know). Blesta sends a create server request The server gets ip and port from multicraft Blesta sends an update request, wich forces it to use daemon id 11, but the ip and port stays as is. This is the module log: https://pastebin.com/cztpvLAB TL;DR: The user gets a server on daemon id 11 (supposed to), but gets ip and port assigned from daemon id 10 (beacuse it was created there).

https://hastebin.com/aduzidubuj.log Update: Changed the log directory in blesta to a unwriteable folder, that fixed the problem.

Well, the upgrade went ok, but the page is left blank when voiding invoices and when using the wizard order template (Standard order template works as normal) a simple click on the url-bar and clicking enter fixes it, but its annoying for the average user, any suggestions? Im currently on blesta 4.4.2, php 5.6 (not yet updated to php7) UPDATE: Upgraded to php7 and did the fixes, still the same bug

Hi, im currently running blesta v3.6.2, and was planning to upgrade to 4.4.2 and at the same time upgrade php from 5.6 to 7. What is "best practice" in this upgrade? should i upgrade to newest blesta before i upgrade php?

Tried all suggestions, nothing fixed it, thanks for the help tho . So i downgraded to 3.6.2 to get rid of the bugs.

Is it some sort of way to fix this? does not need to be perfect, but just work.

After i updated from 3.6.2 to 4.0.1 (3.6.2 -> 4.0.0 -> 4.0.1), then the customers could not pay with their credits anymore. php version: 5.4.45-0+deb7u4 The problem occurs with old users. I tried to make a quick testuser, and that user's credits worked. Screenshot of a user with invoices: https://gyazo.com/9b38779c3d8fe869043b44ce26959ce4 Screenshot of payment site: https://gyazo.com/da12647a61cb1eb5f552708d4fb8e031 The customers could pay when i used version 3.6.2, i dont know if version 4.0.0 had the same issue, beacuse i updated to 4.0.1 after i updated to 4.0.0. i think its a problem with my installation, but i dont know why its happening.

I thought i knew what this plugin was doing, now i dont know. For me, all orders dont need manual confirmation, and beacuse of that, every order is accepted, but not paid. https://gyazo.com/71e79ad066fe2812fcf6bd022042ad83 <-- Most recent orders And just to keep my example going, it looks like this on page 131 of accepted orders: https://gyazo.com/fae4d8af006230ef780dc5d6ecb70325 Order is accepted, not paid, and the service is pending. If im doing something wrong, tell me.

I have not received any emails from the plugin. Is it enabled by default? I can use the oldest user as an example: https://gyazo.com/aa1f3ba0851a0e8c770ce92d33c19e41 The orders is pending. It has not changed anything on the user. The user itself is marked as active. Looking forward to get this fixed