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?

Cody, Can you clarify the relationship between the packages table and the services table? My impression is that a row in the packages table represents a specific product and that a row in the services table represents an instance of that product which has been sold to a specif customer. However, I can't find a link between packages and services. It seems the services table should have a column called package_id. Can you explain for me? Thanks, Larry

Another approach we could take would be to present to the migrator the fields it expects by creating views on the freeside database. I looked through the whmsc migrator code. I can't find where the whmcs database queries are. I think if I had those and the data types of the selected input variables, I could create the views.

My skills are in SQL. I don't know php. So, modifying the whmcs migrator is not an option for me, though we could contract with a programmer who does know php. My approach thus far has been to build sql scripts for migrating the data. I know it is not the approach you recommend and I am concerned because of that. Don't know if you will really want to help bail me out if I run into problems I can't figure out. So, before I proceed further down this path I want to ask you if you have the resources to build a freeside migrator for us and if so, can you give me a ballpark idea of what you'd charge?

Well, the purpose would be to just import the clients, their current balance and the package info they are subscribed to. It would remove the need to import the previous five years of transactions. This would simplify the migration considerably. It would eliminate the need to not only import old invoices, payments refunds, and credits, but also the need to then apply those transaction to the invoices as they had previously been applied. The freeside database structure is more complex than blesta's. (at least the financial portion). Where blesta store's transactions and their application in just two tables freeside has seperate transaction and application tables for each transaction type. I think I can extract the freside financial info and programatically transform it into the blesta format and then call the blesta apis to insert and apply them, but it will be a challenge. I am not sure it is worth the extra programming effort as well as the additional testing required to confirm all transaction are applied as they were before and that everything else, including balances, match. I've done two other major billing migrations for another company (different market type) and just brought forward the balances and it worked out nicely. If we took this approach my main concern would be to get the billing cycles properly imported so blesta would no when the next invoice should be generated.

OK, I see can I can pre-date invoices, and control which trasactions are apllied to what. via the apis. We are now debating wheather to bother to migrate the history or to just bring over the balances. When you've done other migrations did you bring over the history?

These tranasction have effective dates in the past. Over the last five years. If I use the api and then allow blesta to apply them these dates will reset to the current date, right? Actually this concerns all the old invoices, payments, credits and refunds as well. It seems I need to insert these all directly into the data base as the api does not appear to have the option of pre-dating these items and their application, or am I missing something?

I am in the process of building a migration from Freeside to Blesta. I have a couple of questions on how to migrate credits. Background: When we fall short of our SLA due to an outage we issue a full or partial credit for that period for all of our customers on the affected machines. Can I simply insert these existing Freside credits into the transactions, log_transactions and transactions_applied tables when I do the migration? Once we are in production on Blesta and we need to issue a batch of credits, can I programatically insert the credits into the transactions and log_transactions tables and let Blesta apply them? Can I create a new transaction tyoe in the transaction_types table for this purpose? Thanks, Larry Crawford prgmr.com