Max

Try my credit note and accrual accounting patch

Can process iDeal payments through Multisafepay/Mollie/Buckaroo: http://www.blesta.com/forums/index.php?/topic/1960-various-payment-gateways-through-omnipay/ 0% "intracommunaire prestaties" by marking a customer "tax exempt" manually, or automatically upon entering a valid VAT number with this modification: http://www.blesta.com/forums/index.php?/topic/2013-registration-form-vat-number-and-e-mail-address-verification/ Having different VAT rates for different products is not supported. Selling services that fall under the 6% rate is kinda rare in the hosting business though. (in the Netherlands that rate is mostly applied to food and books)

Don't see what's wrong with pointing out that I believed it was a known issue, already reported by others. I assume reported issues will be fixed by the guys eventually, without me having to bug them about it. Problems occur when operating on a service that already exists in Blesta in some form (e.g. ones in "pending" state, or partially imported from WHMCS), as opposed to creating services that did not exist at all. If you are only creating brand new services in one go, you might indeed not notice it. Related threads: http://www.blesta.com/forums/index.php?/topic/1377-service-activated-on-cpanel-but-not-in-blesta/?p=11277 http://www.blesta.com/forums/index.php?/topic/1377-service-activated-on-cpanel-but-not-in-blesta/?p=12387 http://www.blesta.com/forums/index.php?/topic/949-fao-tyson-domain-customer-id-field-and-yearly-bug/?p=8259

Thanks for the confidence mate... Third party modules rely on the correctness of the input they are being fed by Blesta though. A concept known in software engineering as garbage in, garbage out. One of the situations it occurs, is when creating a service in "pending" state first, and then activating it later with "use module" unchecked Screenshot of options selected: Information sent by Blesta to the module when pressing "activate" button. (added a die(print_r($vars, true)); to the top of the addService() method) Array ( [status] => active [ip] => 1.2.3.4 [notify_order] => true [use_module] => true [pricing_id] => 1 [qty] => 1 [current_qty] => 1 [configoptions] => Array ( ) [client_id] => 2 ) Check box is unchecked, yet it says use_module => true. Recall someone else already reported experiencing similar behaviour with a domain registration module in another thread. So assumed it was a known issue.

This is probably overkill if graphs are the only function you want to use. But our dedicated server provisioning module does graphs as well, in addition to offering PXE operating system installs, power control and IPMI console functionality.

Also agree with that. Other payment service providers have been getting away with similar tricks for a long time though, so it will probably last. E.g. authorize.net offers one where you create and host the form on your own server, but let it point to their servers ( <form method="post" action="https://server-provided-by-gateway/"> ), and then redirects the customer back to your server straight away. While it is true that the card details then normally do not touch your server, it still means that if your server is compromised the details can be directed elsewhere.

Single use tokens are the Stripe.js thing Blesta is not using... The tokens Blesta uses are multiple use, and is the customer id returned by Stripe_Customer::create(). It stores those tokens in combination with the card holder name, expiration date and last4.

Problem with changing core files like the invoice template myself is that it complicates things when upgrading. Was wondering if it would be possible to get something a little more generic in Blesta itself instead, that could be used by various modules and external applications using the Blesta API to create an invoice with additional extra pages. Can imagine that my original request for .pdf attachments might be too complicated, if it generates dependencies on external software like pdftk. But perhaps something more basic. I recall tcpdf that you are using for the invoices also has a writeHTML() method that can transform simple HTML (with tables and images) to a pdf page. Perhaps that would be sufficient to achieve this. E.g. external application could specify the HTML content when creating the invoice. $api = new BlestaApi($url, $user, $key); $data = array( 'vars' => array( 'client_id' => 1, 'date_billed' => date("c"), 'date_due' => date("c"), 'currency' => "USD", 'lines' => array( array( 'description' => "Development hours", 'amount' => "22" ) ), 'delivery' => array("email"), 'specification' => '<h1>Hour specification</h1> <table> ...HTML table code with start/stop times... </table>' ) ); $response = $api->post("invoices", "add", $data); And Blesta could stick that it in the database, and add a few lines to the invoice generation code, among the lines of this: /** * Generates one or more invoices for a single document * * @param array $invoice_data An numerically indexed array of stdClass objects each representing an invoice */ public function makeDocument($invoice_data) { $num_invoices = count($invoice_data); // Loop through all of the given invoices for ($i=0; $i<$num_invoices; $i++) { // Set the invoice data for this invoice $this->invoice = $invoice_data[$i]; // Set the invoice data for this PDF $this->pdf->invoice = $this->invoice; // Start a new page group for each individual invoice $this->pdf->startPageGroup(); // Add a new page so that each group starts on its own page $this->pdf->AddPage(); // Draw all line items for this invoice $this->pdf->drawInvoice(); // Add the invoice specification if present if ( !empty($this->invoice->specification) ) { $this->pdf->AddPage(); $this->pdf->writeHTML($this->invoice->specification); } } }

Only the token? Or token + expiration date? Note that the expiration date is considered cardholder data as well.

Server sounds singular. As mentioned before, you need at least a separate database server in a private network if you store card holder data. Or you will already be not in compliance with "1.3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks." Where cardholder data is defined as any of the following: "PAN, Cardholder Name, Service Code, Expiration Date" Note that your quarterly security scan will not test for things like this. Having the scan is one of the requirements, not proof that you meet other requirements. You are right that being PCI compliant is the user's responsibility, and not Blesta though. But perhaps that could be made more clear by adding a message reminding the user of the need for that, on the merchant gateway installation pages. And that -while they may look less pretty- non-merchant gateways may be a better solution for those that prefer not to jump through all the PCI hoops.

Try modifying the code that suppresses errors in ticket_manager.php catch (Exception $e) { // Ignore errors, continue on to the next department } catch (Exception $e) { echo "Error processing e-mail: ".$e->getMessage()."\n"; }

Would be nice if it was possible to bundle a .pdf attachment with an invoice. And have the attachment sent to the customer whenever the invoice is e-mailed, have it printed when using paper invoicing and allow the user to view it in the clientarea. Typical use case would be invoices created manually for custom web development jobs. Attaching a detailed hour specification listing start/stop times generated by a time tracking app to a normal Blesta invoice for XX hours development at $ YY/hour.

This diff adds support for the automatic generation of a credit note when the "void invoice" button is pressed. A credit note is simply an invoice with negative amounts on it, and serves as paper trail that a previously issued invoice was corrected. Both the original invoice and the credit note end up under the "voided" section in Blesta for now. I also added support for the accrual accounting method to the "tax liability" report. If that is selected all invoices are included in the report (as opposed to just the paid ones when using "cash accounting") The credit notes will have a negative tax amount in the report, as you can deduct the amount from your the next VAT payment to the government. http://www2.noc-ps.com/dl/blesta-3-1-credit-notes.diff

Do note that if you choose to use a merchant gateway -where the customer enters the credit card details on your own website, instead of being redirected- your credit card processor will require that you are PCI compliant. That means extra costs for things like quarterly security scans, and needing to have a separate webserver and database server if numbers are stored. That's why quite a number of companies still opt to use non-merchant gateways, where the user is redirected to a separate site provided by the gateway to enter his details, even if it is less pretty.

Yeah, the diff is not that human readable, due to me moving the input fields on the sign-up form around (the "country", "tax_id" and "company" fields were moved to the top of the form) Generally it is not necessary to edit the files manually though. patch is your friend. $ cd blesta-3.1.0 $ patch -p1 < blesta-3.1-signup-form.diff patching file blesta/components/invoice_templates/default_invoice/default_invoice_pdf.php patching file blesta/components/invoice_templates/default_invoice/language/en_us/default_invoice.php patching file blesta/plugins/order/controllers/main.php patching file blesta/plugins/order/language/en_us/main.php patching file blesta/plugins/order/views/templates/standard/language/en_us/main.php patching file blesta/plugins/order/views/templates/standard/main_signup.pdt

It doesn't count your hours, but you can create simple invoices manually.

An attempt at modifying the sign-up form to add VAT number and e-mail address verification. Asks the user if he is a private individual or company Hides company name input field if private individual (to prevent the user entering things like "-" or "NA", which can cause problems with domain registrations.) If the user is an European company, he can enter his VAT number and press "validate", the system will then verify the number and fill in the company name and address information (if available) automatically. If a valid EU VAT number is entered, and the customer is in a different country than you, he will not be charged VAT (reverse charge procedure) The e-mail address is verified by sending an 8 character verification code to it, that must be entered by the user to proof the address is correct. Requires PHP SOAP extension (to communicate with the European Union's VIES VAT number validation service), and that the default country in the Blesta settings is set to your own company location. Diff (file changes): http://www2.noc-ps.com/dl/blesta-3.1-signup-form.diff SQL (extra e-mail template): http://www2.noc-ps.com/dl/blesta-3.1-signup-form.sql

That would cause problems for users in other countries. In the 28 EU countries one does need to (also) list the unit price exclusive VAT on the invoice. Even though the rounding of the total must be based on inclusive prices when selling B2C, as inclusive prices is what you must advertise to consumers on price lists and during the order process. You do can have both a column with the unit price exclusive and one inclusive, to make the invoice and calculation easier to understand. That is what webshop software like Prestashop, and some Magento plugins do.

ACH should have the following changes to make it suitable for international use. * Option that restricts access to the "add account" screen to staff. This is because we are only supposed to enable direct debit after having received a written mandate (signed paper form) from the customer here. * Account information screen needs extra fields, and those needs to be passed to processAch(): company name if the bank account is registered to a company mandate ID that uniquely identifies the form the customer signed (could default to customer number) date the customer originally signed the mandate

Unfortuneately, recurring payments are a bit more complicated for non-merchant gateways. Besides that Omnipay hasn't implemented recurring payments for GoCardless, there are some more fundamental problems with using recurring payments for hosting purposes in general. With many gateways if you setup yearly recurring payments it will do exactly that: charge today and attempt to charge exactly a year from now. However if you are for example selling domain names it would be nice to charge today and a number of days earlier next year. So that if the next payment for whatever reason fails, you can still work out an alternative payment method with the client, without the risk of the domain expiring, or the risk of you paying renewal fees out of your own pocket for a domain the customer may or may not end up paying.

Hi, A little Proof of Concept that duct tapes Blesta to the Omnipay payment processing library. Currently limited to making one-off payments with the following non-merchant gateways: Buckaroo GoCardless Mollie MultiSafepay Netaxept PayFast PaymentExpress PxPay SagePay Server WorldPay Requires a recent PHP version (with namespace support and such), and is experimental. May or may not work correctly with offline payments (e.g. manual bank transfers which some gateways offer), and uncleared payments that need manual approval (anti-fraud functionality of some gateways). http://downloads.noc-ps.com/Omnipay-Blesta-Module-1.zip

Problem however is that some gateways do return custom data, but have a character limit. Can be a problem if a larger number of invoices is being paid. Another potential issue is that not all gateways offer protection against the user tampering with the custom data returned, when the user is redirected back to the site. E.g. I recall that 2checkout does prevent tampering with the amount paid (md5 hash over amount + transaction id + shared secret), but does not include the custom data in the hash. Does Blesta have built-in protection against replay attacks, e.g. does it check if the transaction id number returned by the gateway has been processed before? Otherwise a user might be able to use a single $ 100 payment to pay multiple $ 100 invoices, by performing the redirect back to the site multiple times and changing the invoice number in the custom data field each time.

+1 This is a legal requirement in more countries. You are only allowed to display prices excluding VAT here if you only sell b2b, and do not have consumers as customer. >WHMCS uses a system that calculated backwards from the price set for inclusive amounts and this may be unnecessary. Calculating backwards is actually the right way of doing things to prevent rounding errors. If I advertise domains for 15 EUR each, the customer must be able to get 1 domain for 15 EUR inclusive VAT and 2 domains for 30 EUR. However if you enter a unit price of 12.40 EUR exclusive 21% VAT, 2 domains will result in 2 x 12.40 x 1.21 = 30.008 = 30.01 rounded, 1 cent too much.

Never trust an X-Forwarded-For header by default, only when you actually have a proxy, and verified the connection came from the proxy IP. Otherwise I can pretend to be a proxy too and make my web browser send requests with an added "X-Forwarded-For: CubicWeb's IP" header

What software are you running on the other web server? If it's Apache just use: http://httpd.apache.org/docs/current/mod/mod_remoteip.html Handling it at the webserver level instead of in PHP has the added bonus that it displays the real client IP in your access_log and statistics as well.