LedgerSMB

Open source ERP system introduces numerous new features and improvements that increase IT landscape integration options and reduce the need for customization. 15 September 2014, London. The LedgerSMB project - all-volunteer developers and ... [More] contributors - today announced LedgerSMB 1.4.0. Based on an open source code base first released in 1999, the LedgerSMB project was formed in 2006 and saw it's 1.0 release in the same year.   It has now seen continuous development for over eight years and that shows no signs of slowing down. "LedgerSMB 1.4 brings major improvements that many businesses need," said Chris Travers, who helped found the project.  "Businesses which do manufacturing or retail, or need features like funds accounting will certainly get much more out of this new release." Better Productivity LedgerSMB 1.4 features a redesigned contact management framework that allows businesses to better keep track of customers, vendors, employers, sales leads, and more.  Contacts can be stored and categorized, and leads can be converted into sales accounts. Additionally, a new import module has been included that allows businesses to upload csv text files to import financial transactions and much more.  No longer is data entry something that needs to be done entirely by hand or involves customizing the software. Many smaller enhancements are here as well,  For example, shipping labels can now be printed for invoices and orders, user management workflows have been improved,  Better Reporting The reporting interfaces have been rewritten in LedgerSMB 1.4.0 in order to provide greater flexibility in both reporting and in sharing reports.  Almost all reports now include a variety of formatting options including PDF and CSV formats.  Reports can also be easily shared within an organization using stable hyperlinks to reports.  Additionally the inclusion of a reporting engine means that it is now relatively simple to write third-party reports which offer all these features.  Such reports can easily integrate with LedgerSMB or be accessed via a third party web page. Additionally, the new reporting units system provides a great deal more flexibility in tracking money and resources as they travel through the system.  Not only can one track by project or department, but funds accounting  and other specialized reporting needs are possible to meet. Better Integration Integration of third-party line of business applications is also something which continues to improve.  While all integration is possible, owing to the open nature of the code and db structure, it has become easier as more logic is moved to where it can be easily discovered by applications. There are two major improvement areas in 1.4.  First additional critical information, particularly regarding manufacturing and cost of goods sold tracking, has been moved into the database where it can be easily shared by other applications.  This also allows for better testability and support.  Secondly LedgerSMB now offers a framework for web services, which are currently available for contact management purposes, allowing integrators to more easily connect programs together. Commercial Options LedgerSMB isn't just an open source project.  A number of commercial companies offer support, hosting, and customization services for this ERP.  A list of some of the most prominant commercial companies involved can be found at http://ledgersmb.org/topic/commercial-support Release: 1.4Security release: NoRelease candidate: No [Less]

15 September 2014, London. The LedgerSMB project - all-volunteer developers and contributors - today announced LedgerSMB 1.4.0.Based on an open source code base first released in 1999, the LedgerSMB project was formed in 2006 and saw it's 1.0 release ... [More] in the same year. It has now seen continuous development for over eight years and that shows no signs of slowing down."LedgerSMB 1.4 brings major improvements that many businesses need," said Chris Travers, who helped found the project. "Businesses which do manufacturing or retail, or need features like funds accounting will certainly get much more out of this new release." Better Productivity LedgerSMB 1.4 features a redesigned contact management framework that allows businesses to better keep track of customers, vendors, employers, sales leads, and more. Contacts can be stored and categorized, and leads can be converted into sales accounts.Additionally, a new import module has been included that allows businesses to upload csv text files to import financial transactions and much more. No longer is data entry something that needs to be done entirely by hand or involves customizing the software.Many smaller enhancements are here as well, For example, shipping labels can now be printed for invoices and orders, user management workflows have been improved, Better Reporting The reporting interfaces have been rewritten in LedgerSMB 1.4.0 in order to provide greater flexibility in both reporting and in sharing reports. Almost all reports now include a variety of formatting options including PDF and CSV formats. Reports can also be easily shared within an organization using stable hyperlinks to reports. Additionally the inclusion of a reporting engine means that it is now relatively simple to write third-party reports which offer all these features. Such reports can easily integrate with LedgerSMB or be accessed via a third party web page.Additionally, the new reporting units system provides a great deal more flexibility in tracking money and resources as they travel through the system. Not only can one track by project or department, but funds accounting and other specialized reporting needs are possible to meet. Better Integration Integration of third-party line of business applications is also something which continues to improve. While all integration is possible, owing to the open nature of the code and db structure, it has become easier as more logic is moved to where it can be easily discovered by applications.There are two major improvement areas in 1.4. First additional critical information, particularly regarding manufacturing and cost of goods sold tracking, has been moved into the database where it can be easily shared by other applications. This also allows for better testability and support. Secondly LedgerSMB now offers a framework for web services, which are currently available for contact management purposes, allowing integrators to more easily connect programs together. Commercial Options LedgerSMB isn't just an open source project. A number of commercial companies offer support, hosting, and customization services for this ERP. A list of some of the most prominant commercial companies involved can be found at http://ledgersmb.org/topic/commercial-support [Less]

15 September 2014, London. The LedgerSMB project - all-volunteer developers and contributors - today announced LedgerSMB 1.4.0.Based on an open source code base first released in 1999, the LedgerSMB project was formed in 2006 and saw it's 1.0 release ... [More] in the same year. It has now seen continuous development for over eight years and that shows no signs of slowing down."LedgerSMB 1.4 brings major improvements that many businesses need," said Chris Travers, who helped found the project. "Businesses which do manufacturing or retail, or need features like funds accounting will certainly get much more out of this new release."Better ProductivityLedgerSMB 1.4 features a redesigned contact management framework that allows businesses to better keep track of customers, vendors, employers, sales leads, and more. Contacts can be stored and categorized, and leads can be converted into sales accounts.Additionally, a new import module has been included that allows businesses to upload csv text files to import financial transactions and much more. No longer is data entry something that needs to be done entirely by hand or involves customizing the software.Many smaller enhancements are here as well, For example, shipping labels can now be printed for invoices and orders, user management workflows have been improved, Better ReportingThe reporting interfaces have been rewritten in LedgerSMB 1.4.0 in order to provide greater flexibility in both reporting and in sharing reports. Almost all reports now include a variety of formatting options including PDF and CSV formats. Reports can also be easily shared within an organization using stable hyperlinks to reports. Additionally the inclusion of a reporting engine means that it is now relatively simple to write third-party reports which offer all these features. Such reports can easily integrate with LedgerSMB or be accessed via a third party web page.Additionally, the new reporting units system provides a great deal more flexibility in tracking money and resources as they travel through the system. Not only can one track by project or department, but funds accounting and other specialized reporting needs are possible to meet.Better IntegrationIntegration of third-party line of business applications is also something which continues to improve. While all integration is possible, owing to the open nature of the code and db structure, it has become easier as more logic is moved to where it can be easily discovered by applications.There are two major improvement areas in 1.4. First additional critical information, particularly regarding manufacturing and cost of goods sold tracking, has been moved into the database where it can be easily shared by other applications. This also allows for better testability and support. Secondly LedgerSMB now offers a framework for web services, which are currently available for contact management purposes, allowing integrators to more easily connect programs together.Commercial OptionsLedgerSMB isn't just an open source project. A number of commercial companies offer support, hosting, and customization services for this ERP. A list of some of the most prominant commercial companies involved can be found at http://ledgersmb.org/topic/commercial-support [Less]

15 September 2014, London. The LedgerSMB project - all-volunteer developers and contributors - today announced LedgerSMB 1.4.0. Based on an open source code base first released in 1999, the LedgerSMB project was formed in 2006 and saw it's 1.0 ... [More] release in the same year. It has now seen continuous development for over eight years and that shows no signs of slowing down. "LedgerSMB 1.4 brings major improvements that many businesses need," said Chris Travers, who helped found the project. "Businesses which do manufacturing or retail, or need features like funds accounting will certainly get much more out of this new release." Better Productivity LedgerSMB 1.4 features a redesigned contact management framework that allows businesses to better keep track of customers, vendors, employers, sales leads, and more. Contacts can be stored and categorized, and leads can be converted into sales accounts. Additionally, a new import module has been included that allows businesses to upload csv text files to import financial transactions and much more. No longer is data entry something that needs to be done entirely by hand or involves customizing the software. Many smaller enhancements are here as well, For example, shipping labels can now be printed for invoices and orders, user management workflows have been improved, Better Reporting The reporting interfaces have been rewritten in LedgerSMB 1.4.0 in order to provide greater flexibility in both reporting and in sharing reports. Almost all reports now include a variety of formatting options including PDF and CSV formats. Reports can also be easily shared within an organization using stable hyperlinks to reports. Additionally the inclusion of a reporting engine means that it is now relatively simple to write third-party reports which offer all these features. Such reports can easily integrate with LedgerSMB or be accessed via a third party web page. Additionally, the new reporting units system provides a great deal more flexibility in tracking money and resources as they travel through the system. Not only can one track by project or department, but funds accounting and other specialized reporting needs are possible to meet. Better Integration Integration of third-party line of business applications is also something which continues to improve. While all integration is possible, owing to the open nature of the code and db structure, it has become easier as more logic is moved to where it can be easily discovered by applications. There are two major improvement areas in 1.4. First additional critical information, particularly regarding manufacturing and cost of goods sold tracking, has been moved into the database where it can be easily shared by other applications. This also allows for better testability and support. Secondly LedgerSMB now offers a framework for web services, which are currently available for contact management purposes, allowing integrators to more easily connect programs together. Commercial Options LedgerSMB isn't just an open source project. A number of commercial companies offer support, hosting, and customization services for this ERP. A list of some of the most prominant commercial companies involved can be found at http://ledgersmb.org/topic/commercial-support [Less]

15 September 2014, London. The LedgerSMB project - all-volunteer developers and contributors - today announced LedgerSMB 1.4.0. Based on an open source code base first released in 1999, the LedgerSMB project was formed in 2006 and saw it's 1.0 ... [More] release in the same year. It has now seen continuous development for over eight years and that shows no signs of slowing down. "LedgerSMB 1.4 brings major improvements that many businesses need," said Chris Travers, who helped found the project. "Businesses which do manufacturing or retail, or need features like funds accounting will certainly get much more out of this new release." Better Productivity LedgerSMB 1.4 features a redesigned contact management framework that allows businesses to better keep track of customers, vendors, employers, sales leads, and more. Contacts can be stored and categorized, and leads can be converted into sales accounts. Additionally, a new import module has been included that allows businesses to upload csv text files to import financial transactions and much more. No longer is data entry something that needs to be done entirely by hand or involves customizing the software. Many smaller enhancements are here as well, For example, shipping labels can now be printed for invoices and orders, user management workflows have been improved, Better Reporting The reporting interfaces have been rewritten in LedgerSMB 1.4.0 in order to provide greater flexibility in both reporting and in sharing reports. Almost all reports now include a variety of formatting options including PDF and CSV formats. Reports can also be easily shared within an organization using stable hyperlinks to reports. Additionally the inclusion of a reporting engine means that it is now relatively simple to write third-party reports which offer all these features. Such reports can easily integrate with LedgerSMB or be accessed via a third party web page. Additionally, the new reporting units system provides a great deal more flexibility in tracking money and resources as they travel through the system. Not only can one track by project or department, but funds accounting and other specialized reporting needs are possible to meet. Better Integration Integration of third-party line of business applications is also something which continues to improve. While all integration is possible, owing to the open nature of the code and db structure, it has become easier as more logic is moved to where it can be easily discovered by applications. There are two major improvement areas in 1.4. First additional critical information, particularly regarding manufacturing and cost of goods sold tracking, has been moved into the database where it can be easily shared by other applications. This also allows for better testability and support. Secondly LedgerSMB now offers a framework for web services, which are currently available for contact management purposes, allowing integrators to more easily connect programs together. Commercial Options LedgerSMB isn't just an open source project. A number of commercial companies offer support, hosting, and customization services for this ERP. A list of some of the most prominant commercial companies involved can be found at http://ledgersmb.org/topic/commercial-support [Less]

This will be the final installment on Math and SQL and will cover the problem with NULLs.  NULL handling is probably the most poorly thought-out feature of SQL and is inconsistent generally with the relational model.  Worse, a clear mathematical ... [More] approach to NULLs is impossible with SQL because too many different meanings are attached to the same value.Unfortunately, nulls are also indispensable because wider tables are more expressive than narrower tables.  This makes advice such as "don't allow nulls in your database" somewhat dangerous because one ends up having to add them back in fairly frequently.At the same time understanding the problems that NULLs introduce is key to avoiding the worst of the problems and managing the rest.Definition of a Null SetA null set is simply a set with no members.  This brings us to the most obvious case of the use of a NULL, used when an outer join results in a row not being found.  This sort of use by itself doesn't do too much harm but the inherent semantic ambiguity of "what does that mean?" also means you can't just substitute join tables for nullable columns and solve the problems that NULLs bring into the database. This will hopefully become more clear below.Null as UnknownThe first major problem surfaces when we ask the question, "when I do a left join and the row to the right is not found, does that mean we don't know the answer yet or that there is no value associated?"  In all cases, a missing result from an outer join will sometimes mean that the answer is not yet known, if only because we are still inserting the data in stages.  But it can also mean that maybe there is an answer and that there is no value associated.  In almost all databases, this may also be the case in this situation.But then there is no additional harm done in allowing NULLs to represent unknowns in the tables themselves, right?Handling NULLs as unknown values complicates database design and introduces problems so many experts like Chris Date tend to be generally against their use.  The problem is that using joins doesn't solve the problem but instead only creates additional failure cases to be aware of.  So very often times, people do use NULL in the database to mean unknown despite the problems.NULL as unknown introduces problems to predicate logic because it introduces three value logic (true, false, and unknown), but these are typically only problems when one is storing a value (as opposed to a reference such as a key) in the table.  1 + NULL IS NULL.  NULL OR FALSE IS NULL.  NULL OR TRUE IS TRUE.  This makes things complicated.  But sometimes we must....Null as Not ApplicableOne severe antipattern that is frequently seen is the use of NULL to mean "Not Applicable" or "No Value."  There are a few data types which have no natural empty/no-op types.  Prime among these are numeric types.  Worse, Oracle treats NULL as the same value as an empty string for VARCHAR types.Now, the obvious problem here is that the database does't know here that NULL is not unknown, and therefore you end up having to track this yourself, use COALESCE() functions to convert to sane values, etc.  In general, if you can avoid using NULL to mean "Not Applicable" you will find that worthwhile.Now, if you have to do this, one strategy to make this manageable is to include other fields to tell you what the null means.  Consider for example:CREATE TABLE wage_class (   id int not null,   label text not null);INSERT INTO wage_class VALUES(1, 'salary'), (2, 'hourly');CREATE TABLE wage (   ssn text not null,   emp_id int not null,   wage_class int not null references wage_class(id),   hourly_wage numeric,   salary numeric,   check (wage_class = 1 or salary is null),   check (wage_class = 2 or hourly_wage is null));This approach allows us to select and handle logic based on the wage class and therefore we know based on the wage_class field whether hourly_wage is applicable or not.  This is far cleaner and allows for better handling in queries than just putting nulls in and expecting them to be semantically meaningful.  This solution can also be quite helpful because it ensures that one does not accidentally process an hourly wage as a salary or vice versa.What Nulls Do to Predicate LogicBecause NULLs can represent unknowns, they introduce three-valued predicate logic.  This itself can be pretty nasty.  Consider the very subtle difference between:   WHERE ssn like '1234%' AND salary < 50000vs    WHERE ssn like '1234%' AND salary < 50000 IS NOT FALSEThe latter will pull in hourly employees as well, as they have a NULL salary.Nulls and ConstraintsDespite all the problems, NULLs have become a bit of a necessary evil.  Constraints are a big part of the reason why.Constraints are far simpler to maintain if they are self-contained in a tuple and therefore require no further table access to verify.  This means that wider tables admit to more expression relating to constraints than narrow tables.In the example above, we can ensure that every hourly employee has no salary, and every salaried employee has no hourly wage.  This level of mutual exclusion would not be possible if we were to break off salaries and wages into separate, joined tables.Nulls and Foreign KeysForeign keys are a special case of NULLs where the use is routine and poses no problems.  NULL always means "no record referenced" in this context and because of the specifics of three-valued boolean logic, they always drop out of join conditions.NULLs in foreign keys make foreign key constraints and 5th Normal Form possible in many cases where it would not be otherwise.  Consequently they can be used routinely here with few if any ill effects.What Nulls Should Have Looked Like:  NULL, NOVALUE, UNKNOWNIn retrospect, SQL would be cleaner if we could be more verbose about what we mean by a NULL.  UNKNOWN could then be reserved for rare cases where we really must need to store a record with incomplete data in it.  NULL could be returned from outer joins, and NOVALUE could be used for foreign keys and places where we know the field is not applicable. [Less]

This will be the final installment on Math and SQL and will cover the problem with NULLs.  NULL handling is probably the most poorly thought-out feature of SQL and is inconsistent generally with the relational model.  Worse, a clear mathematical ... [More] approach to NULLs is impossible with SQL because too many different meanings are attached to the same value.Unfortunately, nulls are also indispensable because wider tables are more expressive than narrower tables.  This makes advice such as "don't allow nulls in your database" somewhat dangerous because one ends up having to add them back in fairly frequently.At the same time understanding the problems that NULLs introduce is key to avoiding the worst of the problems and managing the rest.Definition of a Null SetA null set is simply a set with no members.  This brings us to the most obvious case of the use of a NULL, used when an outer join results in a row not being found.  This sort of use by itself doesn't do too much harm but the inherent semantic ambiguity of "what does that mean?" also means you can't just substitute join tables for nullable columns and solve the problems that NULLs bring into the database. This will hopefully become more clear below.Null as UnknownThe first major problem surfaces when we ask the question, "when I do a left join and the row to the right is not found, does that mean we don't know the answer yet or that there is no value associated?"  In all cases, a missing result from an outer join will sometimes mean that the answer is not yet known, if only because we are still inserting the data in stages.  But it can also mean that maybe there is an answer and that there is no value associated.  In almost all databases, this may also be the case in this situation.But then there is no additional harm done in allowing NULLs to represent unknowns in the tables themselves, right?Handling NULLs as unknown values complicates database design and introduces problems so many experts like Chris Date tend to be generally against their use.  The problem is that using joins doesn't solve the problem but instead only creates additional failure cases to be aware of.  So very often times, people do use NULL in the database to mean unknown despite the problems.NULL as unknown introduces problems to predicate logic because it introduces three value logic (true, false, and unknown), but these are typically only problems when one is storing a value (as opposed to a reference such as a key) in the table.  1 + NULL IS NULL.  NULL OR FALSE IS NULL.  NULL OR TRUE IS TRUE.  This makes things complicated.  But sometimes we must....Null as Not ApplicableOne severe antipattern that is frequently seen is the use of NULL to mean "Not Applicable" or "No Value."  There are a few data types which have no natural empty/no-op types.  Prime among these are numeric types.  Worse, Oracle treats NULL as the same value as an empty string for VARCHAR types.Now, the obvious problem here is that the database does't know here that NULL is not unknown, and therefore you end up having to track this yourself, use COALESCE() functions to convert to sane values, etc.  In general, if you can avoid using NULL to mean "Not Applicable" you will find that worthwhile.Now, if you have to do this, one strategy to make this manageable is to include other fields to tell you what the null means.  Consider for example:CREATE TABLE wage_class (   id int not null,   label text not null);INSERT INTO wage_class VALUES(1, 'salary'), (2, 'hourly');CREATE TABLE wage (   ssn text not null,   emp_id int not null,   wage_class int not null references wage_class(id),   hourly_wage numeric,   salary numeric,   check (wage_class = 1 or salary is null),   check (wage_class = 2 or hourly_wage is null));This approach allows us to select and handle logic based on the wage class and therefore we know based on the wage_class field whether hourly_wage is applicable or not.  This is far cleaner and allows for better handling in queries than just putting nulls in and expecting them to be semantically meaningful.  This solution can also be quite helpful because it ensures that one does not accidentally process an hourly wage as a salary or vice versa.What Nulls Do to Predicate LogicBecause NULLs can represent unknowns, they introduce three-valued predicate logic.  This itself can be pretty nasty.  Consider the very subtle difference between:   WHERE ssn like '1234%' AND salary < 50000vs    WHERE ssn like '1234%' AND salary < 50000 IS NOT FALSEThe latter will pull in hourly employees as well, as they have a NULL salary.Nulls and ConstraintsDespite all the problems, NULLs have become a bit of a necessary evil.  Constraints are a big part of the reason why.Constraints are far simpler to maintain if they are self-contained in a tuple and therefore require no further table access to verify.  This means that wider tables admit to more expression relating to constraints than narrow tables.In the example above, we can ensure that every hourly employee has no salary, and every salaried employee has no hourly wage.  This level of mutual exclusion would not be possible if we were to break off salaries and wages into separate, joined tables.Nulls and Foreign KeysForeign keys are a special case of NULLs where the use is routine and poses no problems.  NULL always means "no record referenced" in this context and because of the specifics of three-valued boolean logic, they always drop out of join conditions.NULLs in foreign keys make foreign key constraints and 5th Normal Form possible in many cases where it would not be otherwise.  Consequently they can be used routinely here with few if any ill effects.What Nulls Should Have Looked Like:  NULL, NOVALUE, UNKNOWNIn retrospect, SQL would be cleaner if we could be more verbose about what we mean by a NULL.  UNKNOWN could then be reserved for rare cases where we really must need to store a record with incomplete data in it.  NULL could be returned from outer joins, and NOVALUE could be used for foreign keys and places where we know the field is not applicable. [Less]

This will be the final installment on Math and SQL and will cover the problem with NULLs.  NULL handling is probably the most poorly thought-out feature of SQL and is inconsistent generally with the relational model.  Worse, a clear mathematical ... [More] approach to NULLs is impossible with SQL because too many different meanings are attached to the same value.Unfortunately, nulls are also indispensable because wider tables are more expressive than narrower tables.  This makes advice such as "don't allow nulls in your database" somewhat dangerous because one ends up having to add them back in fairly frequently.At the same time understanding the problems that NULLs introduce is key to avoiding the worst of the problems and managing the rest.Definition of a Null SetA null set is simply a set with no members.  This brings us to the most obvious case of the use of a NULL, used when an outer join results in a row not being found.  This sort of use by itself doesn't do too much harm but the inherent semantic ambiguity of "what does that mean?" also means you can't just substitute join tables for nullable columns and solve the problems that NULLs bring into the database. This will hopefully become more clear below.Null as UnknownThe first major problem surfaces when we ask the question, "when I do a left join and the row to the right is not found, does that mean we don't know the answer yet or that there is no value associated?"  In all cases, a missing result from an outer join will sometimes mean that the answer is not yet known, if only because we are still inserting the data in stages.  But it can also mean that maybe there is an answer and that there is no value associated.  In almost all databases, this may also be the case in this situation.But then there is no additional harm done in allowing NULLs to represent unknowns in the tables themselves, right?Handling NULLs as unknown values complicates database design and introduces problems so many experts like Chris Date tend to be generally against their use.  The problem is that using joins doesn't solve the problem but instead only creates additional failure cases to be aware of.  So very often times, people do use NULL in the database to mean unknown despite the problems.NULL as unknown introduces problems to predicate logic because it introduces three value logic (true, false, and unknown), but these are typically only problems when one is storing a value (as opposed to a reference such as a key) in the table.  1 + NULL IS NULL.  NULL OR FALSE IS NULL.  NULL OR TRUE IS TRUE.  This makes things complicated.  But sometimes we must....Null as Not ApplicableOne severe antipattern that is frequently seen is the use of NULL to mean "Not Applicable" or "No Value."  There are a few data types which have no natural empty/no-op types.  Prime among these are numeric types.  Worse, Oracle treats NULL as the same value as an empty string for VARCHAR types.Now, the obvious problem here is that the database does't know here that NULL is not unknown, and therefore you end up having to track this yourself, use COALESCE() functions to convert to sane values, etc.  In general, if you can avoid using NULL to mean "Not Applicable" you will find that worthwhile.Now, if you have to do this, one strategy to make this manageable is to include other fields to tell you what the null means.  Consider for example:CREATE TABLE wage_class (   id int not null,   label text not null);INSERT INTO wage_class VALUES(1, 'salary'), (2, 'hourly');CREATE TABLE wage (   ssn text not null,   emp_id int not null,   wage_class int not null references wage_class(id),   hourly_wage numeric,   salary numeric,   check (wage_class = 1 or salary is null),   check (wage_class = 2 or hourly_wage is null));This approach allows us to select and handle logic based on the wage class and therefore we know based on the wage_class field whether hourly_wage is applicable or not.  This is far cleaner and allows for better handling in queries than just putting nulls in and expecting them to be semantically meaningful.  This solution can also be quite helpful because it ensures that one does not accidentally process an hourly wage as a salary or vice versa.What Nulls Do to Predicate LogicBecause NULLs can represent unknowns, they introduce three-valued predicate logic.  This itself can be pretty nasty.  Consider the very subtle difference between:   WHERE ssn like '1234%' AND salary < 50000vs    WHERE ssn like '1234%' AND salary < 50000 IS NOT FALSEThe latter will pull in hourly employees as well, as they have a NULL salary.Nulls and ConstraintsDespite all the problems, NULLs have become a bit of a necessary evil.  Constraints are a big part of the reason why.Constraints are far simpler to maintain if they are self-contained in a tuple and therefore require no further table access to verify.  This means that wider tables admit to more expression relating to constraints than narrow tables.In the example above, we can ensure that every hourly employee has no salary, and every salaried employee has no hourly wage.  This level of mutual exclusion would not be possible if we were to break off salaries and wages into separate, joined tables.Nulls and Foreign KeysForeign keys are a special case of NULLs where the use is routine and poses no problems.  NULL always means "no record referenced" in this context and because of the specifics of three-valued boolean logic, they always drop out of join conditions.NULLs in foreign keys make foreign key constraints and 5th Normal Form possible in many cases where it would not be otherwise.  Consequently they can be used routinely here with few if any ill effects.What Nulls Should Have Looked Like:  NULL, NOVALUE, UNKNOWNIn retrospect, SQL would be cleaner if we could be more verbose about what we mean by a NULL.  UNKNOWN could then be reserved for rare cases where we really must need to store a record with incomplete data in it.  NULL could be returned from outer joins, and NOVALUE could be used for foreign keys and places where we know the field is not applicable. [Less]

The LedgerSMB team is proud to release version 1.3.42.  This release corrects a couple of significant issues and a number of more minor issues. Most significantly this corrects an issue which prevented posting of foreign currency payments when ... [More] certain conditions regarding rounded, converted amounts were present.  Also this corrects an issue where invoices with ship-to addresses were sometimes linked to incorrectly in the reports. A number of more minor fixes were included as well. The complete changelog is below: Changelog for 1.3.42* Fixed #1184 invalid numeric format on payment search field, where date was used instead of amount (Pongracz I)* Fix for missing emails when emailing orders/quotations (1073, Chris T)* Fix doubled email addresses when emailing invoice (1186, Pongracz I)* Fix for inactive customers showing up on receipt search (1095, Chris T)* Hungarian translation changes (Pongracz I)* View file_links is no longer dropped before rebuild (Chris T, 1099)* Fix for invoice with shipto linking to wrong one on report (Chris T, 1104)* Fix for shipto's not being automatically checked (Chris T, 1100)* Fixed forex rounding issue with single payments not posting (Chris T)* Fixed typo in search payment form: aligh -> align (Pongracz I) Chris T is Chris TraversPongracz I is Pongracz Istvan [Less]

While running extended tests, Chris Travers found some failures in the new-in-1.4 COGS test cases.  These have been fixed and a new RC for LedgerSMB 1.4 is now available at SourceForge.   These new tests allow us to make guarantees that the logic ... [More] works as designed; guarantees we can't easily make for previous versions.  The new logic also has fewer problem cases for manufacturing, and allows the development of heavier manufacturing capabilities going forward.   For example, LedgerSMB 1.3 and earlier versions (dating back to SQL-Ledger) give wrong COGS information when the assembly BOM is altered between stocking the assembly and selling it.  I suspect that selling assemblies before the ap invoices for the parts also produces bad numbers.  The rewritten COGS logic in 1.4 addresses both these cases preventing incorrect numbers from being reported.   The major benefit from the COGS rewrite however is in testability.  With previous versions, automated unit testing was just not possible.  With the current versions, we can test scenarios to make sure the right numbers come out.  It was these tests which showed the problems that lead to this release.   Chris Travers would like to suggest that anyone who depends on COGS should consider being an early adopter of 1.4, as soon as 1.4.0 is released. Release: 1.4Security release: NoRelease candidate: Yes [Less]