Cody
-
Posts
1,574 -
Joined
-
Last visited
-
Days Won
74
Posts posted by Cody
-
-
A URL is supposed to be a logical resource, which is how they're built in Blesta. It's sometimes nice to have sort URLs, but that usually requires removing information about a particular resource, making it less logical.
Logic aside, as-is, I think they are quite pretty. Much prettier than say, "cart.php?template=foo&package=12".
-
Where users are redirected after performing some action is currently not configurable. If such a feature were added, I suspect it would be in a system-wide configuration, rather than isolated to to a single action/page--at least I think that would be a better solution.
Or could be an option within the reply section of the ticket, e.g.:
After replying: [ take me back to ticket listing | stay on this page ].
-
Encoding is different than escaping.
Don't have time to pull up the html spec, but this might help clarify: http://stackoverflow.com/questions/3705591/do-i-encode-ampersands-in-a-href.
-
"index.php?foo&bar" is the correct way to encode URIs. Are you saying the URI is doubly encoded (as in "index.php?foo&bar")? That would be a problem.
Your fix, from what I see, would open the system up to XSS.
-
Another thought: you could allow cron to provision as it runs outside of apache and so should not be affected.
-
Unfortunately, there's no workaround. Plesk is killing Blesta while it's in the middle of performing a task. If you could configure plesk not to restart apache, or if you ran blesta under a different web server (nginx/lighttpd/etc.) or entirely separate server you probably wouldn't have any problems.
-
Believe submitting as a batch exists as well.
Bank_of_America_NACHA_File_Specs.pdf
Might not be advertised/offered to smaller companies though.
NACHA applies to payment gateway processors.
Blesta will never be a payment gateway processor, so it will never implement NACHA standards.
-
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.
Yes, we're well aware of that. The difference is that ACH is processed through a payment gateway, and are submitted individually not as a batch.
-
Hi Max and others
Our requirements are similar to the European ones. I am starting to get the feeling that Blesta is too focussed on particular markets and not versatile enough to deal with the various environments, without having to first do a whole lot of custom development. I could be wrong on that score of course. I am really looking for a solution that has most of what is considered basic functionality in our environment buttoned down in its core. What attracted us is the api which we would need to interface with our voip platform (that part I don't mind developing as a plugin), but at this point it seems that we'd have to do a whole lot of work just to make it work for us.
Any Blesta lovers who could tell me I am wrong in the above assumptions?
Cheers
Sounds like all you need 2 things:
- SEPA XML - See CORE-1164.
- Transactions to appear on invoices, and liken this term to "Statements". That's not a feature request I can ever remember seeing, but it's super simple to do. Blesta supports what are called Invoice Templates. An invoice can contain whatever you want using a custom template. Because Blesta must support as many localities as possible, we sometimes have to work around issues which may produce legal compliance issues for our customers otherwise. This usually results in more generic default behavior, but if you play around with Blesta for a while you'll discovered that no other system is as flexible or customizable.
If you feel there's something you're missing, there's a good chance other people may feel the same way, so it's always a good idea to make a feature request.
-
>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.
You have the contact_id, you can load the Contacts model and call Contacts::get().Actually, looks like that isn't passed through after all. Will look into adding it.
>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?
Error because the payment can not be processed until the mandate is set. This is equivalent to submitting a payment without a credit card number.
>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.
I see, so you would need some utility within the staff interface to download the SEPA XML file for all payments that should be processed? This, obviously, makes it impossible to automatically process bank transfers since they can not be processed through a payment gateway. This is just like batch payments, except instead of automatically processing the batch an XML file is built.
>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).
Looking at the format of the XML document, 100,000 transactions would probably be a 50 MB file.
-
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.
Thanks. CORE-1165.
-
Company name is missing in the admin "add ACH account" screen.
Only have first and last name.
Company name is under the client's account.
-
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
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?
I wonder if this could work as a custom client field.
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
This might work as a custom client field.
2.72 Debtor
XML 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
Sounds like billing details that are already recorded for all payment accounts, with the exception of OrganisationIdentification and PrivateIdentification.
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.
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.
Other questions:
- Where is this SEPA XML document submitted?
- 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?
-
Here's the NZ gateway I'm going to be using: http://www.flo2cash.co.nz/pdf/Flo2Cash%20Recurring%20Payments%20Integration%20Guide.pdf (see page 9). They need the account/routing number split into four fields and don't require the account type. That's for their hosted option but their API option (which is probably what I will use) requires the same information. Granted, this is not a big problem but it would be nice if I could customise the fields shown on Blesta.
That's their nonmerchant gateway.
Other documentation here: http://www.flo2cash.co.nz/downloadAPI.php Note that this gateway allows fully online direct debits without sending the customer a form.
This looks like their CC processing API
Looks like this is their bank transfer API, but requires you to set up a "per invoice" recurring record, which you then call for every invoice you wish to process. Wonder if that would be problematic when attempting to pay multiple invoices at once? Kind of a bizarre process, obviously one-time debiting was an after thought.
So what's is the process of splitting the account/routing number into the the four fields?:
- Bank Code
- Branch Code
- Account Code
- Suffix Code
This particular gateway doesn't look like it requires any changes to Blesta. I'm more interested in seeing a payment gateway that requires additional fields as OP suggested are required for European bank transfers.
-
Can you reference any payment gateways that require such fields? Specifically we're looking for documentation for gateway APIs that require these fields to ensure/verify maximum support across all payment gateways.
-
Version 3.2.0-b1 is now available. You can download it in the Client Area.
This is a BETA feature release. This release is not considered stable enough for production use. Please report any bugs in the 3.2 beta bug forum.Installing Blesta
See Installing Blesta in the User Manual for instructions.
Upgrading Blesta
See Upgrading Blesta in the User Manual for instructions.
Release Notes
See Blesta Core - Version 3.2.0-b1.
For older releases see all Change Logs.- Zoltan, MemoryX2, flangefrog and 1 other
-
4
-
The screenshots don't do it justice. These new order forms are incredible, and we've designed them to be super flexible. We didn't just slap together a few order form templates and toss them in. There's a lot of engineering and user expeirence design put into this release. The end result is pure awesome, and the best order forms in the industry by far.
- eversmile_host, marcel, Michael and 2 others
-
5
-
No, why?
This is a refactor todo, has nothing to do with functionality.
-
Pretty self explanatory!
This would be massively important for us, and I bet there are many other people that would like this as well.
If you could give me some pointers on how to achieve this... even if it means hacking core... I'm all up for it.
Create a plugin that does what the ClientInvoices::view() (/app/controllers/client_invoices.php) does.
-
Version 3.1.3 is now available. You can download it in the Client Area.
This is a patch release that corrects issues with 3.1.0.
Patching Blesta
See Patching Blesta in the User Manual for instructions.
Release Notes - Blesta Core - Version 3.1.3## Version 3.1.3 2014-03-27 ### Bug * [CORE-1074] - Support Manager: Some characters may be stripped from tickets emailed in to the system * [CORE-1077] - Support Manager: Email parsing fails if content-disposition is inline * [CORE-1078] - Support Manager: Improper character encoding conversion with subject line decoding * [CORE-1080] - The term for add-ons is displayed blank in the service expanded area * [CORE-1081] - Undefined property: AdminUpgrade::$Session when in maintenance mode * [CORE-1087] - Deleting a draft invoice does not show a success message * [CORE-1088] - Missing language for Admin Company General Localization widget title * [CORE-1095] - Client group setting "Auto Debit Days Before Due Date" missing "Same Day" option * [CORE-1097] - Support Manager: Incorrect date format in upgrade * [CORE-1104] - Editing a package sometimes results in an error message about missing pricing terms when no pricing terms have been removed * [CORE-1105] - Order System: Packages with a quantity available of 0 are still available for order * [CORE-1110] - Support Manager: Closing a ticket may cause formatting error on date_closed ---
See all Change Logs.
-
No, if you paid it on 1.4.2014 then it should renew the term based upon the actual renewal date. What I am saying is that it shouldn't show the new renewal date until after the invoice is paid.
Blesta bumps the renew date when the invoice is created, and this is for a very good reason. Suppose you had a service that renewed every day, but you invoice 3 days in advance. On March 25 you invoice for March 28, On March 26 for March 29, etc. If the renew date didn't advance until the invoice is paid then the March 26 invoice couldn't be generated until after the March 25 invoice is paid. Moreover, if the user failed to pay within 24 hours then all future billing would be X days off (where X is the number of days the user took to pay the last invoice).
I think you might be thinking about "renew date" in the wrong way. Renew date is when a service's NEXT invoice should be due. It is not when a service's current invoice should be due.
-
As I had feared, the new invoice layout has confused several customers this month. Feedback so far:
- The line totals don't make sense because Quantity x Unit Price does not equal Cost (because Unit Price excludes tax and Cost includes it, but this is not indicated)
- The Subtotal doesn't make sense because it is the sum of the tax-exclusive line totals and not the tax-inclusive line totals that sit above it
- We then get asked if tax has been calculated twice because there is a Tax element shown below the Subtotal, which they think is the tax-inclusive subtotal because of the tax-inclusive line totals above it
Can you please look into revising the invoice layout for the next update so that it can cater more appropriately for tax-inclusive countries? Thanks.
I'd suggest making a feature request and include a sample invoice with detailed explanation of each section the way you and your customers would expect.
Regarding the rounding issue, is the total displayed as "$100.01" in the PDF only, or also within the interface?
-
Closing as not a bug. If you're able to reproduce the issue and can provide steps to duplicate as described in How to Report a Bug please start a new thread.
-
I have noticed that the service expiry date renews for another term when it is invoiced. I expect this should actually occur when the invoice is paid.
That's not how Blesta works, but feel free to make a feature request if you'd like. If Blesta worked this way, services would renew at bizarre intervals, and the user would be able to control renew dates based on when they feel like paying. Sounds like a big a headache.
We invoice 14 days before the renewal of the term and some customers will elect to notify us of their intention to cancel at the end of the term. This then leads to a secondary bug -- if I try to reduce the term back to its original expiry date, I get an error message indicating I need to select a date greater then the last renew date. If you look at the attached snapshot you will see I am trying to enter 27 March 2014 but it is giving me an error despite it wanting a value greater than 26 March. Perhaps there is a timezone calculation that is awry here as we are in UTC+11 (Sydney, AU). In the end I just scheduled a cancellation date for 27 March 2014 instead.
I have not been able to duplicate this, but attempting to change the renew date of a service from some date to a future date should always work. Are you able to reproduce this continuously (that is, at various times of day: morning and evening)?
Whmcs Migrator (Beta) - Updated 2013-11-12
in The Lounge
Posted
The current version of the WHMCS migrator doesn't link SolusVM services with the SolusVM module in Blesta, so they're imported using the Universal Module.
The pricing issue sounds strange. What version of WHMCS are you using?