Max

It would be nice if there were generic methods in the base Gateway class for storing information about pending payments in the database, complete with garbage collection of old information about payments that never completed. (default ttl should be large, like 2 weeks, as some payment service providers support bank transfers done offline). Looking at the current implementation of non-merchant gateways such as Paypal in Blesta it seems you are using the "custom" field to pass internal information like the invoices being paid to Paypal, and expect to receive that information back when Paypal does a payment notification back to the site. That does work for Paypal as it allows 256 bytes of custom information to be passed along, but other gateways are less generous, and only pass along 32 bytes of custom data. This may not be sufficient in all cases, therefore the need to store more information in the database.

Correct. That's why I mentioned that Blesta is only useable in its current form if you create credit notes manually outside Blesta, if you need to do any correcting at some point. Using the "edit" button will alter the existing invoice, and making changes to an invoice after it has already been issued to a customer is not allowed (considered a form of fraud) in a large part of the world. Earlier threads about it: http://www.blesta.com/forums/index.php?/topic/1622-information-on-issued-invoices-should-never-change/ http://www.blesta.com/forums/index.php?/topic/1519-billing-mudule-customization-regarding-to-hungarian-rules/

Problem with making VAT number mandatory is that not every customer is guaranteed to have one. Besides private individuals not having one, in some EU countries (like the UK) small companies may be exempt from VAT registration as well.

The official rules common to all EU countries can be found on the EU website. However it may be hard to find your way around them if you don't know what you are looking for exactly. VAT rules for electronically supplied services (e.g. hosting): http://ec.europa.eu/taxation_customs/taxation/vat/how_vat_works/telecom/index_en.htm Invoicing rules that say customer's VAT number must be on the invoice when a reverse charge is performed, as well as a statement indicating this is the case: http://ec.europa.eu/taxation_customs/taxation/vat/traders/invoicing_rules/article_1733_en.htm#item_1.4 Information on checking VAT numbers: http://ec.europa.eu/taxation_customs/vies/faq.html It also mentions briefly the "recupalative statement" That is a list containing all the VAT numbers of your customers, and the amounts of the invoices for which a reverse charge was made, that you must submit to the government after each accounting period. That is the reason it is important that the number the customer entered on the order form is actually checked. Also note that the rules regarding selling services to private individuals (that do not have a VAT number) change next year. Right now a German company selling to a Dutch consumer will charge the German VAT percentage. But that is going to change, and you will need to charge the Dutch percentage instead in 2015. So might want to prepare for having the option to configure a different VAT percentage depending on which country the customer is in, for customers that are not businesses.

No, that is unrelated. Pro-forma invoicing only prevents that you have to pay VAT prematurely for services that the customer may or may not renew, and services that you are uncertain of receiving payment for (e.g. new customer placing an order and selecting a manual bank transfer as payment method)

No, we are currently not using Blesta in any production environment. We have our own custom billing system, although we want to replace it with a standard solution eventually, as our own code is old and suffers from bit rot. Right now modifying Blesta -or any of its competitors- to match the features we currently have would take us more work than continue to maintain our own code though. Waiting for the gap to get smaller. >Is there a way to use blesta as a company from the EU today? Depends who your customers are. If you only were to sell locally to customers in your own country (then you do not need the reverse charge VAT diversion stuff), and write out credit notes manually outside of Blesta when invoices need correcting, it may be usable enough.

1. Note that the code is generic code to demonstrate how one can check the validatity of a VAT number, and retrieve company information. It is not specifically written for Blesta and will not magically work if you cut & paste it in a file. 2. Not every invoice without VAT is a "VAT reserve-charged" invoice. E.g. if the customer is located outside the EU, he doesn't have to pay VAT either, but you shouldn't put that message on the invoice. Also note that you must be able to generate a list of the customer VAT numbers and amounts for which a reverse charge was made, as you will have to send that information to your tax authority at the end of each accounting period. As well as take care of the other things that need to be done to make Blesta EU complaint (e.g. prevent that invoices can be changed after being issued, and be able to correct them properly with credit notes) So it is a little more work than those two simple things.

Yes, that page contains a link to the newest file (NOC-PS-Blesta-Module-2.zip) (still need to update the documentation itself though)

Do not recommend that if you are not a developer, as it would involve making changes to Blesta's own models code, and doing that again on each Blesta update. Not aware of a way of adding additional validation rules in a less intrusive way e.g. through a plugin. While there do is a Clients.create event one can listen to, it is called after the fact, and cannot prevent the client being created if the information does not pass checks.

Updated the module. Added IPMI sensor information (temperature, fan speed, etc.) As well as IPMI KVM-over-IP console support for a number of Dell and Supermicro servers.

Do note that you are supposed to actually verify the VAT number entered if you wish to issue 0% VAT invoices to companies in other EU countries. (which Blesta currently does not do) The EU does provide a SOAP webservice to automate that. It also allows you to retrieve the company's name and address information given a VAT number (although not all EU countries support that), which could be used to fill that in automatically on the order form after the customer entered its VAT number. Some sample code to check the number from one of our own older projects. (for illustrative purposes only. it uses ereg() which was acceptable when the code was written, but is deprecated nowadays) /* * Checks if VAT number entered is valid * * Returns array with company name and address (if member state provides that) * Throws exception if VAT number is not valid */ function vat2contact($vat) { if (!extension_loaded('soap')) die('Missing SOAP extension'); $vat = str_replace('.', '', strtoupper($vat)); $contact['vat'] = $vat; if (!ereg('^([A-Z][A-Z])([0-9A-Z]+)$', $vat, $regs)) throw new Exception(ERR_INVALID_VAT); $params = new stdClass; $params->countryCode = $regs[1]; $params->vatNumber = $regs[2]; /* You can optionally enter your own VAT number here, so that it is registered that you * performed the check and fulfilled your legal obligations. */ $params->requesterCountryCode = ""; $params->requesterVatNumber = ""; try { $client = new SoapClient('http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl'); $result = $client->checkVatApprox($params); if (!$result->valid) throw new Exception(ERR_INVALID_VAT); /* VAT number does not exist */ if (!empty($result->traderName)) $contact['company'] = ereg_replace("[[:space:]]+", " ", $result->traderName); if (!empty($result->traderAddress)) { $addr = $result->traderAddress; if ( strpos($addr, "\n") ) { list($addr, $pc) = explode("\n", $addr, 2); list($zip, $city) = explode(' ', $pc, 2); $contact['address'] = $addr; $contact['zip'] = $zip; $contact['city'] = trim($city); $contact['country'] = $params->countryCode; } } } catch (SoapFault $e) { if ( $e->getMessage() == "{ 'INVALID_INPUT' }" ) throw new Exception(ERR_INVALID_VAT); /* VAT number is not well formed */ /* Silently continue on other errors. Do not prevent registration if VIES service is down */ } return $contact; }

No, receive far more regular invoices, without a pro-forma first.Problem with pro-forma remains that it lets your customer know that payment is optional, and you are not going to make any attempt to enforce the contract.

The way around it is to correct the invoice with a credit note later. Whether you still end up paying VAT over it -and if you did- how long it takes before you get it back, depends on when the invoice and credit note were issued. Our company pays VAT at the end of every quarter. Q1 accounting period January-March - VAT payment to gov. due in April Q2 accounting period April-June - VAT payment to gov. due in July If both the original invoice and the credit note falls in the same accounting period, we do not end up having to actually pay VAT over it, and there is not a real issue. - on 15 January we issue an invoice for 1210 EUR of which 210 EUR is VAT. - It doesn't get paid. reminders -> phone calls -> collection agency -> no luck. - on 15 March we give up on it, and we issue a credit note for -1210 EUR of which -210 EUR VAT. - 210 EUR - 210 EUR = 0 EUR to pay at the end of Q1 for this invoice to the government. No problem. However if it happens a month later: - on 15 February we issues an invoice for 1210 EUR of which 210 EUR is VAT. - it does not get paid. - in April we pay VAT to the government including the 210 EUR VAT for this invoice, we still haven't seen payment of. - on 15 April we give up, and issue a credit note for -1210 EUR of which -210 EUR VAT. - the credit note falls in the Q2 accounting period, and reduces the total VAT we have to pay at the end of Q2. So in that case we paid 210 EUR VAT in April on turnover we did not end up receiving, and are missing that amount for all of May and June. We do are allowed to subtract the 210 EUR again from our next VAT payment to the government in July though, so then we are even again.

Pro-forma invoices are mainly meant for services that expire unless renewed by the customer. E.g. domain names, shared hosting. If the customer has a payment obligation he should receive a normal invoice. E.g. co-location contracts with a 1 year minimum term, and the requirement that cancellations are done in writing.

Perhaps also an option to override it per product?

No. Handing out invoices on request is only allowed if you have no knowledge whether you are selling to a consumer or a VAT registered business. Like when you run a brick-and-mortar store and it cannot be reasonably expected that you know who the customers that come in are. If you do know that your customers are businesses (e.g. they filled in the company name on the order form), you are obliged to issue a VAT invoice without them asking.

I once worked at a very small IT company in the UK. They proudly displayed their VAT registration certificate in a picture frame on the wall... However in other countries thresholds are much lower -or non-existent- and virtually all companies are VAT registered. >But I don't remember hearing they have to have certain things and have to invoice them specially not automatically. It is not required. You can indeed just write out a normal invoice. But in the EU the accrual accounting method is used, and not cash accounting. This means that the moment you write out the invoice, you owe VAT to the government, which you usually have to pay to them monthly, quarterly or yearly depending on country and the size of your company. If some time later you find out you are unable to collect payment, you do have the option to cancel the invoice by creating a credit note with negative amounts, and get the VAT you may have already paid back at the end of the next accounting period. Writing out a credit note is currently not possible with Blesta though. There is another thread on that. Another option is writing out pro-forma invoices first and a normal invoice after payment. The upside is that you do not owe VAT instantly if you are doing it that way, and can postpone it until you are sure of payment. The downside is that a pro-forma invoice is essentially a voluntary offer to the customer. He has no obligation to pay it, and you cannot take follow-up action against him if he does not (cannot send it to a debt collection agency, etc.) Whether that is a problem depends on what you are selling and the terms you have with the customer.

>It does, somewhat, as the lack of an initialization vector means that two matching plain-texts will always result in the same cipher text, though I am certain this is by design, and as I've stated is sufficient for its purpose (as the likelihood of >matching plain-texts is quite low). Given that there is a counter in the plain-text that gets incremented each time, you never have matching plain texts. Note that the entire 128-bit (AES' block size) of plain-text must match exactly for that to apply Just having some static bits at the beginning does not matter, as it is not a stream cipher. >I disagree simply because just about any device can be used as a TOTP token generator, so the key need not be hardcoded to the device (any such device is simply a poor design). In theory yes. In practice I am still looking for a single vendor that sells standalone TOTP hardware tokens at reasonable conditions (must fit on a key chain, be programmable, cost under $ 100 each, and sell in low quantities, not by the thousands) >I still don't see how the AES key is generated. Where does the entropy come from to generate the AES key? It really doesn't matter much as you've stated the keys can be reset. So I assume that means I could set it to >anything I desired. Yeah, you need to set your own key anyway if you wish to verify locally. They do not supply you with the preprogrammed one, that is stored by them and can only be used by their API. Don't know where Rob the robot gets it entropy from. :-) http://vimeo.com/27107146#

Not sure if ECB block mode matters when only a single block of data is encrypted. AES key is a 128-bit shared secret that you program in the Yubikey and stick in your own database if you are doing local verifications. For illustrative purposes, see our instructions for programming a Yubikey and entering the key in our software that does local verification: http://www.noc-ps.com/index.php/documentation/yubikey/ As you see both the (optional) private id and AES key are entered separately and not derived from anything. Note that TOTP also carries extra security risks because in practice user programmable hardware tokens are not available for purchase in small quantities (yes, we searched). Most use a key that is preprogrammed by the factory and there is reason to believe most vendors keep copies. There was a scandal when RSA's SecurID token database was hacked, and used to compromise a defense contractor. And gooze.eu stopped selling Feitian's devices because they think they also keep copies. And do not like the idea using a smartphone as a security device either, when it is known that Google employees (and who knows else) can push arbitrary software to your phone. http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/ So think Yubi is the most secure option.

Owing money to the customer may also be the case. When issuing a refund to the customer that should be recorded as a negative invoice as well, for taxation purposes. But in the case you are not issuing a refund, but are just correcting something else -like the description or customer address- on an already issued invoice, you have 3 invoices. - original invoice #1 $ 10 - credit invoice #2 $ - 10 - new invoice with the right data #3 $ 10 Customer still owes $ 10 when combining the three. >The invoice date of a void invoice should be the same (automatically) as the one which got voided by the void one. Hmm, that is different in my country. Here credit notes ("void invoices") must have the date the credit note was created on them. They are treated like normal invoices here, and the negative amount should also be taken into account in any invoice total calculations. (so that after issuing refunds, the amount of VAT to pay in the next accounting period gets lower, to compensate for any VAT you paid too much earlier).

Being able to specify regular expression checks on address fields for each country would be nice. E.g. addresses in the Netherlands must always have a house number, a zip code matching "[0-9]{4} [A-Z]{2}" and a 10 digit phone number. Some local domain registries like .nl verify the address information, and reject the domain registration if it is not valid. So it is better to catch typing errors straight away, when the customer is entering his address.

Not following you. The algorithm to calculate the tokens is publicly available in the technical manual on their website... The only point I do agree with you on is to not use their API, and to program your own seeds in the Yubikey and verify locally. PHP code for local verification is readily available. We use the following LGPL'd code in our own software: https://code.google.com/p/yubiclass/source/browse/#svn%2Ftrunk (With the difference that we made a small modification to loose the dependency on AES128.php and let it us phpseclib instead Replaced: require('AES128.php'); $aes=new AES128(); $key=$aes->makeKey(pack('H*',$secret_aes_key)); [...] $this->yk["token_decoded_bin"]=$aes->blockDecrypt($this->yk["token_bin"], $key); with: require_once( dirname(__FILE__).'/phpseclib/Crypt/AES.php' ); $aes = new Crypt_AES(CRYPT_AES_MODE_ECB); $aes->disablePadding(); $aes->setKey(pack('H*',$secret_aes_key)); [...] $this->yk["token_decoded_bin"]=$aes->decrypt($this->yk["token_bin"]); )

Problem with TOTP is that it is not natively supported by the Yubikey, and only works for Windows users that have their helper program installed. Any specific reason not to support Yubi's event based algorithm instead? Can be computed locally as well, without depending on external servers. (although it requires a little bit of extra work, as you need to store the new event counter in the database after each login).

Address format displayed on invoices and elsewhere should be configurable by country. Some countries have zip code before city name, some have it after. Some expect state/province to be included, many do not.

Right now if one changes anything on the client profile -e.g. the customer's name or address- and generates a pdf of a previously issued invoice, it will contain the new information, instead of the data as it was on the day the invoice was issued. This violates the VAT accounting rules that most European countries have, that do not allow changing anything on an invoice once it has been issued. Having an "edit" button next to the invoice poses a problem as well. The only legal way to correct an invoice here is to issue a "credit note" -which is an invoice, with a negative amount on it- and then create a new one.