Max

For mouse signature drawing I like this library the most: https://github.com/szimek/signature_pad Be aware that capturing a signature that way is mostly symbolic though, and carries limited legal value compared to real paperwork. The moment the customer disputes that the contract you "glued" his signature under, is the one he agreed too, you still have a problem.

My reply contained a link to the official website of the Dutch tax authority, listing the type of companies that are allowed to use cash accounting in the Netherlands. Are you suggesting that information is incorrect? I am open to arguments. But prefer a link to something official, rather than just that your accountant told you. What he says may very well be correct, but is advice specific to your company. And unlike you, I do think it is a very big difference if you are seen as a retailer (webshop shipping tangible goods) that also does a little hosting, or as a hosting company.

Then you are not purely a hosting company. Different situation. Again: if you are a retail store (or some other profession on this list: http://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/btw/btw_aangifte_doen_en_betalen/bereken_het_bedrag/hoe_berekent_u_het_btw_bedrag/kasstelsel/voor_wie_geldt_het_kasstelsel ) you may use cash accounting. However if you only sell hosting or other services that are primarily sold to businesses you must use accrual accounting. There is an option to ask your tax office for permission to be allowed to use cash accounting as well even if you are a company that normally does not qualify, but that requires submitting proof that over 80% of your turnover comes from consumers and not from businesses. That is not very likely in this industry. Companies that use accrual accounting write out credit notes for returns. Writing off an invoice (oninbaar) is not meant to be used for returns, but for services not paid. If you do that -and are a company using accrual accounting- you are supposed to submit documentary evidence showing that you did a serious attempt to collect the debt, but failed, in order to get the VAT already paid back. See: http://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/btw/btw_aangifte_doen_en_betalen/aangifte_corrigeren/btw_terugvragen/teruggaaf_vanwege_oninbare_vorderingen In practice many companies therefore use credit notes as well to correct small invoices they do not bother chasing. Less paperwork for that.

Either use "|/usr/bin/php /path/to/script.php" in your ~/.forward Or if you want to continue using just "|/path/to/script.php" like you have now, open the PHP file and add a hashbang as the first line of the file. Don't forget the bang or it will be treated as comment, and your file will be executed as a normal sh shell script, which seems to be happening now. #!/usr/bin/php

Do you own a hosting company? If so, you have been terribly misinformed. Hosting companies and other businesses that sell services to other companies must use accrual accounting (Dutch: factuurstelsel) and are liable for VAT the moment you write out an invoice. See: http://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/btw/btw_aangifte_doen_en_betalen/bereken_het_bedrag/hoe_berekent_u_het_btw_bedrag/factuurstelsel Only companies that are known to sell predominantly to consumers and therefore write out a very little number of invoices are allowed to use cash accounting (Dutch: kasstelsel) instead. Retail shops, hair dressers, market stands selling vegetables, etc.

It is now executing PHP properly, but php cannot access the script. Be aware that the Unix user used by your mailserver to process local e-mail must be able to access it. Check the file permissions on the script and parent directories. Alternatively, you can try forwarding support e-mail to the username your website runs under. And put your "|/usr/bin/php" line in a file called .forward in the home directory of that user. Most mail servers execute pipe lines found in .forward under the username of the user.

You are currently telling it to append incoming e-mail to a text file named php. Need to prepend | in front of /usr/bin/php to indicate it is a command to execute and pipe to.

Wasn't Blesta using MySQL's InnoDB storage engine (as opposed to MyISAM)? Thought that had support for foreign key constraints/cascading as well.

Thanks. Tried setting the restart interval to 300. That seems to work sufficiently for my testing purposes, but be aware that it is not a solution one could recommend to other customers wanting to put this in production. It seems that Plesk doesn't treat a "Apache restart interval" of 300 as "restart Apache 5 minutes after a change" but as "restart Apache at most every 5 minutes" First request from Blesta to Plesk still sends SIGTERM to Apache instantly If you have an ongoing stream of subsequent requests those are all handled fine. If you do nothing for 10 minutes, the next request from Blesta to Plesk will send SIGTERM instantly again.

Yeah, marking the invoice paid, and let cron deal with it does create it ok. Just a bit annoying. Not only occurs on creation, but also on other admin actions like suspend/delete.

Another ugly workaround may be for Blesta not to wait for the response from Plesk (which doesn't come until after Apache has been restarted) There are 9 seconds between the moment Apache is asked to terminate nicely, and it forcible kills the PHP FastCGI process. So it does have time to simply mark the service active, if no negative response is received within a second or so. Only problem is that it then is not able to store the newly created webspace id returned by Plesk. But think that can be retrieved by domain name later on.

Not sure if this is a supported configuration, but for testing purposes I'm trying to provision a Plesk webhosting account on the same Plesk server Blesta is running on. Problem is that Plesk has the nasty habit of restarting Apache every time a new website is added to the system. So when I activate a new Plesk order through the Blesta admin interface with "use module" checked, this causes Plesk to restart Apache, and this kills all connections and the running Blesta PHP process. [Sat Apr 26 22:22:06 2014] [notice] caught SIGTERM, shutting down [Sat Apr 26 22:22:15 2014] [error] FastCGI process 14718 still did not exit, terminating forcefully Receive an error in my browser ("502 Bad gateway" returned by the nginx reverse proxy in front of Apache, indicating connection to Apache was lost) And that Plesk succeeded adding the website is not registered in Blesta, module log shows webspace:add was last API command sent, and no reply registered. Not sure if Plesk is the only hosting panel affected by this, or others may have the same problem as well. May be better to postpone the creation of new hosting accounts until next cron run, and provision them from there.

Feel free to create the feature request for account statements. For me having the statements itself is not top priority. Just believe separate statements are a better alternative to making changes to already issued invoices (which you do when you scribble transaction information on them).

Believe submitting as a batch exists as well. Bank_of_America_NACHA_File_Specs.pdf Might not be advertised/offered to smaller companies though.

Yes, was thinking about just creating a button for spitting out the XML on the manage page of the payment module. Note that if you do use a gateway for ACH payments, it ends up being batch processed by them as well. So be aware that unlike with credit cards a gateway can conduct no real-time checks on the information provided either, and you do not get any useful feedback until the day after. This applies to both Europe, the US and probably everywhere else.

Hmm, you do have a "company" field in the CLIENTAREA'S "add ach" screen ( http://demo.blesta.com/client/accounts/add/ach/ ) as opposed to the admin's "add ach" screen. However what you enter there is not actually saved.

Why not in the add ACH account screen as well? You do have all other information there. Also keep in mind that it is non-trivial to fetch any information from under the client's account. /** * Process an ACH transaction * * @param array $account_info An array of bank account info including: * - first_name The first name on the account * - last_name The last name on the account * - account_number The bank account number * - routing_number The bank account routing number * - type The bank account type (checking or savings) * - address1 The address 1 line of the card holder * - address2 The address 2 line of the card holder * - city The city of the card holder * - state An array of state info including: * - code The 2 or 3-character state code * - name The local name of the country * - country An array of country info including: * - alpha2 The 2-character country code * - alpha3 The 3-character country code * - name The english name of the country * - alt_name The local name of the country * - zip The zip/postal code of the account holder * @param float $amount The amount to debit this account * @param array $invoice_amounts An array of invoices, each containing: * - id The ID of the invoice being processed * - amount The amount being processed for this invoice (which is included in $amount) * @return array An array of transaction data including: * - status The status of the transaction (approved, declined, void, pending, reconciled, refunded, returned) * - reference_id The reference ID for gateway-only use with this transaction (optional) * - transaction_id The ID returned by the remote gateway to identify this transaction * - message The message to be displayed in the interface in addition to the standard message for this transaction status (optional) */ public function processAch(array $account_info, $amount, array $invoice_amounts=null); Not just no company name, but I am also not passed a client ID there. Perhaps by jumping through some hoops, I can learn which customer it concerns by querying the invoice, but invoice_amounts has a default parameter null which could indicate that there is not always an invoice either...

Company name is missing in the admin "add ACH account" screen. Only have first and last name.

>If this must be unique, should it be automatically generated by Blesta? Or is there another system you use that generates the agreement document with this value? Could default to the Blesta client number, but should be editable in case someone was already using a different product with different numbers before. Believe the idea is just that if there is a dispute and the bank asks you for a copy of mandate 1234, you should be able to dig up the piece of paper in your administration. Number only has to be unique in your own administration, it is not some kind of guid that has to be globally unique. >I wonder if this could work as a custom client field. Recall processAch() currently does not pass the client number either, so couldn't fetch any custom client field or anything else either. >If a mandate is required to process payment, why not just prevent the account from being included in any SEPA XML created? I see no reason to prevent clients from entering their payment details when creating an account. If the >mandate is a custom field only available/visible to staff then there is no way that a payment can be processed without a mandate value being entered, regardless of whether or not there are bank details recorded for that client. What should be returned in processAch() in that case? status => pending? >Where is this SEPA XML document submitted? Small customers like us have to upload it manually to an Internet banking site. Requires two factor authentication to get in, so not something you automate. >Are these documents expected to be submitted in batches, or can they be submitted separately. For example, you have 1000 transactions to process using direct debit. Can you submit 1000 SEPA XML documents, or must it be one single >SEPA XML document containing all 1000 transactions? Single document. (Believe there is a 100,000 transactions per file limit, not a limitation you will likely run into).

We play our own gateway, and deal with the acquiring bank directly Banks are traditional organizations that do not have fancy real-time APIs, but instead expect you to upload a batch of transactions as XML file to be processed overnight. PAIN.008 XML specification used in Europe: http://www.ing.nl/Images/XML-Message-for-SDD-Version-6.0-March-2012_tcm7-119112.pdf Banks charge for each batch you submit to them, so companies tend to save transactions up for a while and only submit a batch once every other week or so. I can create a payment module that saves the transactions to a table in the database, and generates the XML file on request. Just missing these fields in the Blesta "add ACH account" screen that I need to be passed to processAch() : 2.48 MandateIdentification XML Tag: <MndtId> Occurence: [1..1] Definition: Unique identification, as assigned by the creditor, to unambiguously identify the mandate. Data Type: Max35Text maxLength: 35 minLength: 1 Usage EPC: Mandatory 2.49 DateOfSignature XML Tag: <DtOfSgntr> Occurence: [1..1] Definition: Date on which the direct debit mandate has been signed by the debtor. Data Type: ISODate Usage EPC: Mandatory 2.72 DebtorXML Tag: <Dbtr> Occurence: [1..1] Definition: Party that owes an amount of money to the (ultimate) creditor. Type: This Message Item is composed of the following PartyIdentification32 element(s): Name <Nm> [0..1] Text PostalAddress <PstlAdr> [0..1] Identification <Id> [0..1] CountryOfResidence <CtryOfRes> [0..1] Code ContactDetails <CtctDtls> [0..1] Usage EPC: ‘Name’ is Mandatory. ‘Name’ is limited to 70 characters in length. Only two occurrences of ‘AddressLine’ are allowed. ‘OrganisationIdentification’: Either ‘BIC or BEI’ or one occurrence of ‘Other’ is allowed. ‘PrivateIdentification’: Either ‘Date and Place of Birth’ or one occurrence of ‘Other’ is allowed Note that <Nm> is the company name in case the bank account is registered to a company. So need a company field next to the "first name" and "last name" in the "add ACH screen" Mandatory fields are mandatory everywhere in Europe. But in the Netherlands we do not care about optional fields like address and OrganisationIdentification or PrivateIdentification that specify things like company registration number and date of birth.But not sure about banks in other countries. Other fields necessary are the IBAN number (<DbtrAcct><Id><IBAN>), but it is similar enough to the account number field you already have. And the BIC (<DbtrAgt><FinInstnId><BIC>), but that is similar enough to your routing number. Mandate = the paper form the customer signed authorizing us to collect by direct debit. We need to receive that first. So customer may NOT add his own data to the system, and "add ACH account" screen should be accessible by staff only.

I have looked into adding support for direct debit the other day. In particular the variant where transactions are exported to a SEPA P.A.I.N. 008 XML file, to be submitted to a bank directly (without a gateway in between). Which might be similar to what you are looking for. Writing a module that stores the transactions in a database and exports them as a batch is by itself not the problem. However that the Blesta user interface for adding ACH accounts currently doesn't have all the input fields needed is a bigger problem. For American ACH that is already supported by Blesta one only needs a bank account and routing number. However for the European variant we need the (company) name of the account holder, bank account number (IBAN), routing (BIC), an unique identification number identifying the paper authorization form the customer signed and the date the customer signed it. Created a feature request for extra fields in February: Extra Fields For Sepa Direct Debit ("european Ach") Naturally you can modify the Blesta source code to add those fields yourself. However that involves modifying existing code that might change in future versions which is why I'm not a big fan of that.

Note that CORE-923 mentions caching the invoice on disk, which sounds .pdf only. The data as it appears on the invoice should be stored in the database as well, as you also need it to be able to generate reports from it, in order to fill in your tax return properly. One needs the customer's country and customer's VAT ID as it was on the day the invoice was issued at a minimum. (Need to supply the government with a list containing the VAT IDs of companies in other EU countries VAT was exempted/reverse charged for, and the total amount sold to that company in a reporting period) But better to stick all other invoice data in the invoice table as well, just in case any other jurisdiction needs more. Also not sure how caching on disk as described in CORE-923 is going to work when generating a single pdf containing multiple invoices (print queue thing?), and viewing single invoices earlier or later. Do you plan to store the invoices as single pdfs on disk, and use a library (such as Zend_Pdf or FPDI) to concatenate them when generating a batch? Or does it still end up generating fresh invoices containing possibly new data, which is a problem?

Information on invoices Invoices should never change once issued. Remarks about payments only belong on invoices if the payment was made PRIOR to the invoice being issued. If you asked and received payment in advance, the invoice you send must (under EU rules) mention the date the payment was made. Usually this is done by having a line at the bottom like "Already paid by <payment method> on <date>", where you would normally have payment instructions instead ("Payment due in 14 days. If paying by bank transfer please mention reference ABCD") One issue with Blesta is that when a new order is placed by the customer and paid directly by credit card, the invoice is created first and the payment applied after that. Think it would be better if that was reversed. Do not issue an invoice until gateway confirms payment (or issue a pro-forma invoice first, if the customer wants to make a manual payment) That way you do can mention the payment that was made on placing the order. And not creating invoices until the first payment arrives also reduces unnecessary tax liability, for orders placed but for which the payment process was never completed. Credits Credits should be rare and not an everyday occurrence. If the customer accidentally paid too much when paying a previous bill, you really should refund it to whatever payment source it came from, instead of hanging on to it as credit. If you offer the customer a discount (e.g. when he is upgrading from a smaller package he already paid for, to a bigger package), mention the discount as a second invoice line with negative amount. This also reduces the tax to pay properly, something which will not happen if you just give him some credit for it. (Partial) payments after invoice has been issued If customers have problems paying their bills in full, make partial payments, and have problems keeping track of how much is left to pay, the proper way would be to send them a separate account statement listing transactions and outstanding balance. Not append later information to an invoice issued previously.

>We want the ability to simply have a running total. Wouldn't that complicates things when sending payment reminders? Note that while you do have to record it against some invoice in Blesta, it is not a problem if it is a partial payment. And you can also record a payment that is greater than the invoices you apply it to, in which case it will be recorded as credit to be applied to future invoices. after: That is a wire transfer that the customer sends from his bank account to your bank account using Internet banking. Popular in countries were credit cards are not common, where cards are restricted to offline use, and/or where people simply do not feel comfortable supplying their card details to some random shop online (quite a significant part of continental Europe) There do are gateways that can process those for you (e.g. Multisafepay), but most companies prefer to receive the payments in their own bank account, and process them manually by looking at their bank statement. Or semi-manually by exporting them from Internet banking (usually as CSV file) and importing them into accounting software that does some matching.

Note that the TS is not from Europe, so may have overlooked the other threads about it because they mention "EU invoicing", which is somewhat misleading. Credit notes are pretty much used everywhere worldwide. With the exception of some countries that allow smaller companies to use cash based accounting instead, in which case only payments need to be tracked. If there is no legal obligation to write out an invoice in the first place, there is no need for a paper trial for later corrections either after all...