Topic: version 2.4

Some questions about the new version 2.4

Are the tables firm now?

Where can I download the tarball or zip?

When do you plan to switch from mysql to mysqli/prepared statement? PHP is clearly depreciating mysql in favor of mysqli or pdo.

Is it possible to be able to set default value on select boxes, eg, under Sales, setting Payment to a certain account or Shipping Company to the usual shipper or Deliver from to usual location? That way most of the time when entering a SO user does now have to change any setting from the usual unless needed.

It seems that to make Sales Quotation, I have to have the company in debtors_master.  That really clutters up that table when many quotes are made and then the company is never an actual customer.  I think a quote should be able to be made with out creating a new debtor. 

Thanks,

ed10

Re: version 2.4

Version 2.4 is not ready yet, so no tarball is released. You can fetch the sources in current development state (no guarantee it works in any part) from unstable branch of Mercurial repo on sourceforge.
Tables will change in next version (as on any major release), but upgrade procedure will make all the work to move old data to new structure.
No change in database support is planned in 2.4. There is too much changes in database overall scheme to mix them with db interface change. Last but not least mysql works good enough, and switch would require overall application rewrite - many work with no evident advantage.

Defaults: yes, this is important. Maybe we will afford to add sort order or default value on those selectors in 2.4.

Regarding Sales Quotation, I understand the problem, however implementation is not obvious in current database structure. We should consider this problem anyway.

Janusz

3 (edited by apmuthu 10/03/2012 08:37:25 am)

Re: version 2.4

FA v2.4 alpha (current Mercurial last changeset 3072) has a few small sql bugs that need to be corrected before install and testing. There is a new 0_wo_costing table that finds no mention in the default COAs and the upgrade sql patch at sql/alter2.4.sql cannot be for executed even on a new install due to these discrepencies.

The unstable corrected files and patches are available here since BugFixes 1809-1812 in Mantis have access denied issues that prevent us from following it up.

Hope the community can now accelerate bugfixing the development branch v2.4 alpha using these snapshots.

Re: version 2.4

Thanks to apmuthu the sql files in unstable repo has been updated smile. No warranty on completness/usufullness of current alpha code though.
Janusz

Re: version 2.4

apmuthu, you are working like crazy.  I will test 2.4 when it get a bit more stable.  I will download and look at some of the files I am interested in, thanks

6 (edited by chrison 01/10/2013 08:09:21 pm)

Re: version 2.4

ed10 wrote:

It seems that to make Sales Quotation, I have to have the company in debtors_master.  That really clutters up that table when many quotes are made and then the company is never an actual customer.  I think a quote should be able to be made with out creating a new debtor. 
ed10

I'm not a programmer, so I have no idea if this is trivial or monumental, but I have a background in business analysis so here's some thoughts on how this might be accomplished from a functionality and business process point-of-view:

First, the following changes would have to be made in the screens, tables, and functions:

1.  Add a field to the debtor table called something like "provisional_customer" where "0" equals "No" and "1" equals "Yes."

2.  Add a check box to the customers screen (i.e. when the user hits F2 in the sales quotation entry screen) to show the value in the "provisional_customer" screen.  If the check box is checked, this is a provisional customer.  If it is unchecked, this is a real customer.

3.  Add a field to the customers screen showing when the customer was created.  Of course, this field will be blank for new customers until the record is saved.

4.  Also add the "provisional_customer" check box in the sales entry screen.  That way, when the customer is selected, the screen shows whether this is a provisional or real customer.

5.  Add a checkbox to the customers screen next to the "show inactive" checkbox called "show only provisional customers."  If this checkbox is checked, then only customers who have the "provisional_customer" field set to "1" are listed in the drop-down box.

Here's how the workflow would work:

1.  When users enter a sales quotation for a new customer, they hit F2 to bring up the customer screen.  They enter as much detail as they need to create a new customer and click the "provisional_customer" check box if they're unsure this quotation is going to lead to an actual sale.  If the user is pretty sure the quote will lead to a sale, then they leave the check box unchecked.

2A.  When the user is entering an order, they select the customer from the drop down list.  If the customer isn't in the list, the user hits F2 and creates a new customer, unchecking the "provisional_customer check box because this is going to be a "real" customer  If the customer does exist, the user can see whether this customer is currently shown as being a "provisional" customer.  If so, the user unchecks the box converting this customer to a "real" customer because the customer is now placing an order.

2B.  Optionally, the function for posting sales orders could be modified to check whether the value of the "provisional_customer" field is "1" and, if so, flip it to "0" because the provisional customer is now placing an order.  This would automate debtor_master table maintenance somewhat.

3.  From time-to-time, a user can go into the customer screen, click on the "show only provisional customers" check box, and clean out any customers who's status is "provisional" when it should be "real" because they actually placed an order.  As well, the user can delete any customers who received a quote and didn't place an order by viewing the record creation date.  If in doubt, the user can use the sales inquiry function to verify whether the customer has placed an order.  Whether or not to delete the record would be determined by the company's policies (e.g. if the customer hasn't placed an order in one year).  Optionally, adding a printed report to list only customers who's status is "provisional" would be helpful to the user in seeing who's "provisional" and who's not.

This is a bit messy and, again, might be a lot of programming effort to do, but I think this might be a way of "cleaning out the clutter" from the debtors_master table.

Thoughts?  Suggestions?  Improvements?

Regards,

Chris