provided by Star2Billing S.L.

1) Sending Invoice as Email through admin UI problem:
http://localhost/A2Billing_UI/A2B_entit ... ice_type=2
Result (when click on email icon of invoice page): "Successfully sent email to ."
Note: No recipient listed.
Email gets sent, shows attachment symbol in email client, but there is NO CONTENT (text, message, attachment, or otherwise) received in the email, and the email format does not look to be correct, e.g. the structure of the email sent is not an appropriate format.

Here's a copy of part of the email message source:
... Other Header Info - not important ...
To: [email protected]
Subject: INVOICE
From: [email protected]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="==Multipart_Boundary_xf71e9a6c789cea936d60cd266d238355x"
Mime-Version: 1.0
Content-Transfer-Encoding: BASE64
Message-Id: <[email protected]>
Date: Wed, 26 Nov 2008 16:28:27 -0800 (PST)
X-Evolution-Source: imap://BLAHBLAHBLAH

DdXN0b21lciwNCg0KUGxlYXNlIHNlZSB0aGUgYXR0YWNoZWQgZmlsZSBmb3IgeW91ciBp

bnZvaWNlIGZvciBlQ29ycFN5cyBzZXJ2aWNlcy4NCg0KS2luZCBSZWdhcmRzLA0KZUNvcnBTeXMg

QmlsbGluZ1RoaXMgaXMgYSBtdWx0aS1wYXJ0IG1lc3NhZ2UgaW4gTUlNRSBmb3JtYXQuCgotLT09

TXVsdGlwYXJ0X0JvdW5kYXJ5X3hmNzFlOWE2Yzc4OWNlYTkzNmQ2MGNkMjY2ZDIzODM1NXgKQ29u

dGVudC1UeXBlOnRleHQvaHRtbDsgY2hhcnNldD0iaXNvLTg4NTktMSIKQ29udGVudC1UcmFuc2Zl

...
...

ci1FbmNvZGluZzogN2JiBiYXNlNjQKCkpWQkVSaTB4TGpNS015QXdJRzlpYWdvTURBeE5UYzNJREF3TURBd0lHNGdDakF3TURBd01E

RTINCk56TWdNREF3TURBZ2JpQUtNREF3TURBd01UYzNOQ0F3TURBd01DQnVJQW93TURBd01EQXhP

VGcySURBd01EQXdJRzRnQ2pBd01EQXcNCk1ESXhNVEFnTURBd01EQWdiaUFLZEhKaGFXeGxjZ284

UEFvdlUybDZaU0F4TUFvdlVtOXZkQ0E1SURBZ1Vnb3ZTVzVtYnlBNElEQWcNClVnbytQZ3B6ZEdG

eWRIaHlaV1lLTWpJMU5nb2xKVVZQUmdvPQ0KCgotLT09TXVsdGlwYXJ0X0JvdW5kYXJ5X3hmNzFl

OWE2Yzc4OWNlYTkzNmQ2MGNk

--==Multipart_Boundary_xf71e9a6c789cea936d60cd266d238355x--


2) pdf current invoice in customer UI - view invoices, select specific invoice page:
http://localhost/A2B_CustomerUI/A2B_ent ... ice_type=2
Click on pdf icon, prompts to save a file called "Unbilled_XXXXX.pdf"
a) the pdf file is very small ~87 bytes and can not open as is reported as a non-readable format when trying to open
b) the pdf is named "Unbilled_xxxxxx.pdf", why? I am currently viewing a specific already billed invoice. A pdf icon on this page should give me a pdf of the invoice I am viewing, not an invoice for unbilled activity (since I am on a specific billed invoice page).

** Note that the generic pdf export (not coinciding with invoices) seems to work fine.
http://localhost/voip/A2B_entity_call_d ... ?section=4
Also note that this is not a replacement for the previous pdf problems as the ability to view and pdf a specific billed invoice is CRUCIAL, whereas this page that works exports billing information and is not in sync with the invoice dates/info, which is as described a more important issue.

3) current invoice not always showing extra charges info (e.g. service charge and fees).
It does not appear that the invoice is showing the service charge fees. I did get it to appear on one out of 10 invoices so far -> strange behavior. Is there a problem if cront job for batchprocess and subscripton fee occur on same day just before the invoice gets created? I.e. do the recurring service and subscription need to run on a different day? Or is this another bug?
BTW, The charges WERE applied correctly and the customer balances reflect the charges. The problem is that they do not show up on the invoice and this has the effect of the customers balance mysteriously decreasing since no record of the charge exists on their invoice.

4) Invoice does not appear to cusotmer until sent as email in admin UI
The invoice does not appear in Customer UI -> view invoices, until the invoice is sent as an email (which as previously described, does not work). Note: Invoice was created from cront job for:
php /var/lib/asterisk/agi-bin/libs_a2billing/crontjob/a2billing_invoice_cront.php
Upon further examination, I found out that the corn job does not put an entry into cc_invoice_history table, which BTW is required for an invoice to appear in a customer's view invoice screen/page. Note: sending an invoice as email in the admin UI does insert an invoice entry into the cc_invoice_history table (again the email does not work, and why would I be required to send an email in order for the customer to be able to view an invoice that already exists?).

I consider all of these issues serious as they are critical to the basic operation of this SW. Please let me know if you need any more information to help troubleshoot/test regarding these issues.

Thanks

Setup:
a2b version: branch/1.3 (1.3.4+)
db: postgres 8.3

No, but you should take care that the jobs don't run simultaneously, as this could easily lead to the symptoms you are describing.Not at all, given the proviso above. There is no problem running them sequentially, so perhaps you might modify your crontab to do this rather than run them in parallel.

It looks like a valid Base64 encoded MIME format message, except that some of lines are the wrong length. This is very unlikely to be caused by A2B. Check out if any of the MTAs along the path this email followed are altering the message.

Please note that as branches/1.3 is in maintenance you are unlikely to see any changes to the invoicing. If you want to help shape how the invoicing works I suggest you download and install trunk from the svn server, and submit patches to Areski.

Thanks for the reply

Note: I did not run the cron job for each process in parallel, so I don't think that was it.

1.4 (trunk): I have seen the question asked many times with no firm reply.... What is the status of trunk (1.4)? Why is it still marked as trunk? e.g. how unstable is it? When will it be released? Is it at least in Beta? Can we get some feedback on this? I think this would help to let us know what's going on and what is the plan... you might get more community help on 1.4 if you do this, IMO.

Given that there seem to be quite a few issues with invoicing, I have to ask if this means that invoicing is "messed up" and no one cares for 1.3? And with no 1.4 plan announced, there is no real solution? It would make it less desireable to contribute to the project if this is the case (I am trying to give an opportunity for those from the project to state otherwise and give us some input to be more involved, but I think this question needs an answer). Also, regarding moving to 1.4, does anyone know if invoicing works there?

Thanks in advance for reading and answering these questions.

You must bear in mind that the cron jobs may take several minutes to run, possibly even longer, which may lead to them inadvertently running in parallel.
Every project has a trunk; it's where new development happens before a release branch is created.
See here and here too. We can't answer it in full each and every time someone asks.
A lot has changed since it diverged from the v1.3.x codebase, which is good reason to be wary. The amount of feedback about trunk has been very limited, and IMHO not sufficient to form an opinion. It needs more testing before anyone can gain confidence in it. For what it's worth I don't think the changes to the AGI have been very drastic, only the web UIs, so testing of the web interfaces and the new features is what's needed most. Checking there have been no regressions introduced into the rate-engine is important too.
When it's done. When folks start telling us it's in good shape. As for beta status, 'beta' simply indicates no major new features will be accepted before release and is not any indication of the quality/stability of the code being released. Any major changes to the invoicing should really be completed before a beta is released. Given that jroper intimated a release before the end of the year is not out-of-the-question you should look at implementing your changes soon.
Admittedly I've never really got invoicing working to my satisfaction; it's superfluous to my needs for the most part so I've paid little attention to it. We have a forum member who said he was going to overhaul the invoicing but nothing ever came of it.

However, I dispute that branches/1.3 isn't cared for as a whole. As is the nature of Open Source development I've been scratching my own itches here, making sure the parts of A2B I depend upon work well and scale well. I've personally put many hours into fixing bugs and improving performance on branches/1.3, and I shared these changes with the community. I know several other forum members have done similarly. Presumably the invoicing works sufficiently well for them, or they too have little use for it. I'm sure we'd all be overjoyed to see someone grab this particular bull by the horns and implement simple, reliable invoicing for us all.
In case you are not already aware our Trac has a variety of reports (and RSS feeds) that may be of interest to you, such as:Changelog for branches/1.3, Changelog for trunk/v1.4.

Thanks for the feedback

I thought it would be a good idea to get an opinion on 1.4 and the state of invoicing. I, BTW, agree that the agi is pretty nifty and also agree that invoicing needs serious work, as there are many functions that do not work properly in both Admin and Customer UI. I think this is important. I'm glad to see someone cares about 1.3 since this is what most people are using.

I'll take a look at the 1.4 status and change logs to see if I can do some testing on it Do you happen to know if invoicing is improved?

Added after 1 hours 37 minutes:

Ok for bug #3, I found and fixed the problem!

There is an improper LEFT JOIN on 2 tables (simultaneous) that causes a query error. I rewrote this to a LEFT JOIN on INNER JOIN and it works great!

(A2B_entity_invoice_detail.php, in both A2Billing_UI and A2B_CustomerUI, lines 228 and 235, fixed version)
" FROM cc_charge t1 LEFT JOIN (cc_did t2 INNER JOIN cc_country t3 ON (t2.id_cc_country = t3.id)) ON (t1.id_cc_did = t2.id) ".



Added after 2 hours 43 minutes:

I think I can figure out #4, so if you guys can help with #1 and #2 we may be able to fix this invoice system once and for all

I posted a whole bunch of fixes to the trac some time ago, and in particular a fix for invoice emails. They were in many cases being rejected as spam because of the bad format, and also were missing headers. The end result was that you were not notified of non delivery. Not sure why these changes haven't been added.

Check out

http://forum.asterisk2billing.org/viewt ... highlight=

regards

One of your patches was committed to branches/1.3. The patch on ticket 177 presumably wasn't committed because Areski wanted something changed; you should reply to him on that ticket to see what is necessary.

Stavros,

I think you should commit the fix to bug #3 as the SQL query for DID charges is not correct (see description above). I rewrote the query and tested it with success. Now, all DID setup and DID monthly fees show up on the billed invoices.

This is a low risk change that involves changing the FROM clause to the one specified above for the following files:
A2Billing_UI/Public/A2B_entity_invoice_detail.php
(line 228 and 235) change FROM clause for DID Billing items as follows:
" FROM cc_charge t1 LEFT JOIN (cc_did t2 INNER JOIN cc_country t3 ON (t2.id_cc_country = t3.id)) ON (t1.id_cc_did = t2.id) ".
A2Billing_UI/lib/invoice.php
(line 245 and 252) change FROM clause for DID Billing items as follows:
" FROM cc_charge t1 LEFT JOIN (cc_did t2 INNER JOIN cc_country t3 ON (t2.id_cc_country = t3.id)) ON (t1.id_cc_did = t2.id) ".
A2B_CustomerUI/A2B_entity_invoice_detail.php
(line 184 and 191) change FROM clause for DID Billing items as follows:
" FROM cc_charge t1 LEFT JOIN (cc_did t2 INNER JOIN cc_country t3 ON (t2.id_cc_country = t3.id)) ON (t1.id_cc_did = t2.id) ".

FYI - I submitted a bug report on this one #330, I believe this is one of the changes mentioned in middletn's bug #177, except my query doesn't change the general query formatting, so it may be easier to commit.

middletn,

Thanks for the feedback! I am going to look at your reference post and give the solution a try
- I took a look at bug #177 and other than the bug I noted above, the changes seem to be layout and preference, which don't explain the reason why sending a pdf does not work at all (e.g. the bug is that there is no valid pdf file attached, nor text message, etc. -- as opposed to a valid email and pdf with layout problems as it appears that your fixes address the latter and not the former). BTW, I like some of the changes you have made (date format and changing card to account #, invoice number, etc.).
- I also looked at your bug #182 and it does seem that this change was inserted into branch/1.3.
- So, I think there is something else wrong with the pdf and email functions not address in middletn's bug report.