An upgrade to 1.3.27 (head of SVN actually) continues to give me
BigFloat errors. I sure that this is data dependant.
I'm trying to enter a AP.
I added:
use Carp qw(cluck);
cluck "bad math";
print STDERR "X: $x\n";
print STDERR "Y: $y\n";
to the code at the line 1865, and got the foll
As a business owner (farming and technology consulting), I have the
following suggestions:
1) educate business owners on the benefits of the Debian distribution
to allow long-term (30 year) support with no forced upgrades.
2) provide community support for 18 months
3) distribution support for th
This is the same problem I have am having. Any pointers? Thanks.
--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnD
On Sun, Dec 30, 2012 at 7:32 AM, o1bigtenor wrote:
> Top posting to follow present custom!
>
> Speaking as a business owner I am much more likely to run for far
> longer than 36 months. I know people running businesses using record
> keeping (its not really accounting) software that is 7 to 10 ye
On Sun, Dec 30, 2012 at 3:42 AM, Erik Huelsmann wrote:
> Hi,
>
> Working with the Customer/Vendor interfaces for a while now, I've been
> thinking how to improve it -- make it more intuitive.
>
> While in general I think our customer/vendor structure is very complex,
> that's mostly a database ma
Top posting to follow present custom!
Speaking as a business owner I am much more likely to run for far
longer than 36 months. I know people running businesses using record
keeping (its not really accounting) software that is 7 to 10 years
old. As long as the computer works they are happy. Forcing
Hi Berend,
To my knowledge this is not customary. E.g. Subversion has a completely
independent release schedule from any of the distributions. However, since
rules and regulations seem to change regularly in the accounting business
(but not in version control) it seems appropriate to at least pro
On Sun, Dec 30, 2012 at 3:11 AM, Erik Huelsmann wrote:
> Hi,
>
> In an attempt to create clarity for our users, I'd like to add an
> end-of-life statement to the ledgersmb.org website. However, I'm not sure
> we currently have consensus of the end-of-life criteria.
>
> My proposal would be that:
Hi,
Working with the Customer/Vendor interfaces for a while now, I've been
thinking how to improve it -- make it more intuitive.
While in general I think our customer/vendor structure is very complex,
that's mostly a database matter: the UI doesn't support the entire DB model.
Attached I've draw
Hi,
In an attempt to create clarity for our users, I'd like to add an
end-of-life statement to the ledgersmb.org website. However, I'm not sure
we currently have consensus of the end-of-life criteria.
My proposal would be that:
1.0 and 1.1 have been EOL'd by the release of 1.2.
1.2 will be EOL'd
Actually it occurs to me we could use text fields and supply a script to
convert these to JSON if the db is 9.2. This would allow us to support 9.1
and higher without having to postpone this feature.
The danger of course would be that if third parties are writing to this
field they MUST write JSO
11 matches
Mail list logo
