Larry

I updated a client address. Originally, the state field was populated. I changed it to a different country which had no states in the dropdown. After saving changes, the old state was retained. History: we found the letter B in the state field for a newly created client in HK. Even though there were no selections in the dropdown for HK, after saving, the B was retained. We have no idea how the B got there in the first place. Lar

Cody, I couldn't figure our how to attach a screen shot so I opened a ticket and attached it: 9893763 Larry

I am in the process of validating my migration from freeside to blesta. I've inserted credits into the transactions table and a related row in transaction_applied. When cron runs the apply routine it is applying those transactions again. How can I indicate to blesta that the transaction has already been applied?

.

I've supported several commercial billing systems (now semi-retired). Here is what I've seen: Transactions are permanent. Once created a transaction's data can't be modified Data may be added (ie closed date). Transactions include: invoices. payments refunds credits debits An invoice documents a sale. It does not contain balance or payments or previous due amt. An invoice contains line items (qty, desc, unit cost, ext cost, date) A statement is a report containing period to date transaction data, (invoice, payment, credit). Since a statement is a report, typically a pdf, it can be created anytime. It is not the source record for anything. It is convenient to keep, particularly if it was sent to a client. It is common to save the invoice as a pdf along with a record of to who and when it was sent. The systems I worked on were not required to be able to recreate an invoice pdf from data and have it match the original pdf. The point is, the financial integrity is not dependent on statements So a modified statement can be sent in place of an invoice, That's what blesta does, it is a combination statement/Invoice, which is fine. Very typical. I see over on Core 923 there is concern about associating contact info with an invoice and then having the contact info change. The few bits of data, like VAT and country that have to be "remembered" for an invoice are stored as part of the invoice record. (that or a versioning sysem for the contact info which adds complexity, Last system I worked on did that) Lar

I see that I can use the check# box. It goes into transactions.transaction_id and is varchar(128). So ,that should be adequate.

That's good news. When I add an in-house credit to a client, I don't see a way to add a reason for the credit. Is the only way to add a note to the client?

We have lots of clients with more than one email delivery address for invoices and some with more than one delivery type. From what I can tell it does not look like this is supported in Blesta. Is that correct?

In Freeside refunds are stored as individual transactions. In Blesta it looks like refunds do not create new transaction, but instead are applied to existing transactions by changing its status to "refunded' and removing the corresponding row in transaction_applied. So, I am trying to figure out how to import my refunds. I am thinking about creating an invoice in Blesta for each of these refunds, and then let Blesta handle applying any outstanding payments or credit. Do you have any better ideas? thanks, Larry

Are you going to be at the LA SCALE conference in Feb? If so one of my colleagues would like to email you. If you want, you can send your email to me (lcrawfor@yahoo.com) and I'll forward it to her.

We have clients with multiple accounts. Looks like the database will support that, but I don't see how to set it up in the UI. Does Blesta support multiple accounts per client? Thanks, Larry

I got called off the migration for a while but I'm back. I am trying to figure out what the function of the invoices_recur and related tables are. In my test system I created a customer with a package subscription. Blesta creates the recurring invoices correctly, but I don't see any rows in the ..._recur tables. Can I just ignore those tables when I migrate.

Got it - thanks

BTW, I like your DB design. It is well normalized with good and consistent naming conventions. That has made my job much easier. So, kudos to your design team.

We are up on Version 3.1.0-b1. I see that we now have a pricings table. It looks like there can be more than one package_id for each pricing_id, perhaps it is one to one though. Would need to be to be able to uniquely identify the package id, no?