Mikkel Høgh | 1 Apr 2012 02:21
Favicon
Gravatar

What do the COA flags mean?

Hi,

I'm working on a Danish chart of accounts that would resemble what is commonly used in Denmark. I've started
by copying the Danish COA that is shipped with LSMB, but that appears to be simply a translated version of
the general LSMB COA.

Currently, I'm trying to wrap my head around the strange flags that are applied to the different accounts in
the COA, like "AP_amount:IC_cogs:IC_expense". Some of these are somewhat obvious, but I haven't been
able to figure out where these are documented.

Do we have any documentation for what these flags mean? And if not, should't we?

--
Kind regards,

Mikkel Høgh <mikkel@...>

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
Erik Huelsmann | 1 Apr 2012 08:50
Picon
Gravatar

Re: What do the COA flags mean?

Hi Mikkel,

I'm working on a Danish chart of accounts that would resemble what is commonly used in Denmark. I've started by copying the Danish COA that is shipped with LSMB, but that appears to be simply a translated version of the general LSMB COA.

Currently, I'm trying to wrap my head around the strange flags that are applied to the different accounts in the COA, like "AP_amount:IC_cogs:IC_expense". Some of these are somewhat obvious, but I haven't been able to figure out where these are documented.

Do we have any documentation for what these flags mean? And if not, should't we?

Until last week we didn't. And we should. Actually, we need documentation on much more in our system than just those flags. So, I've started a book about LedgerSMB. It's an ambitious project and far from completed, but the information you're asking for is in it already.

See paragraph 25.2 of tonight's book: http://book.ledgersmb.org (the linked PDF)

Hope that helps! (and contributions welcome)

Bye,

Erik.
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
Victor Wren | 1 Apr 2012 17:30
Gravatar

Upgrading and converting: SL-->LSMB 1.1-->LSMB 1.2.26

I built up a new server (from compiled sources), and I'm trying to move 
an existing SQL-Ledger 2.6.27 system over to LSMB (these were running on 
an ancient Fedora 4 system).  I first converted to 1.1.12, per the 
suggestions, and it seemed to go smoothly-- It had exactly the same 
problems as SL at that level (didn't play nice with Perl 5.14 or 
PostgreSQL 9), so once I verified that all my data and user accounts 
were working correctly, I tried to bring things more up to date by 
moving to 1.2.26.

This is where things started to go wrong for me. (everything is backed 
up in a couple of known "good" snapshots, so I'm taking my time to get 
this right, and I've already rolled it back a couple of times to try it 
from a different angle).

The instructions for creating the new type of db-stored user account are 
a little cryptic.  Right now I have three datasets, which are held in 
databases called:
sql_general_ledger
sql_ledger_farm
sql_ledger_weld
(revealing their legacy).  The instructions recommend bringing the user 
data into an existing database, UNLESS there is more than one company 
(dataset), in which case the user info should be stored separately. 
Creating the user information in the existing companies failed with:

psql:Pg-central.sql:76: NOTICE:  CREATE TABLE will create implicit 
sequence "session_session_id_seq1" for serial column "session.session_id"
psql:Pg-central.sql:76: ERROR:  relation "session" already exists
ROLLBACK

So none of the tables was created in the accounting database. After 
searching a few hours longer, I could still not determine whether a user 
database was needed for each company, or one user database for all 
companies. The instructions suggested the former ("If you need to create 
another dataset, you can create the db and import the sql/Pg-central.sql 
file into it."  (but I have 3 existing datasets, and importing 
Pg-central didn't work on them) also implied the need for a separate 
user database, from "/UPGRADE":
"  a)  Single dataset installations should use the user tables in the 
dataset.
   b)  Multicompany installations should use user tables in a separate 
dataset from any accounting data."

So I created 3 user databases separate from the accounting information:
ledgersmb_users_phs
ledgersmb_users_farm
ledgersmb_users_weld
I used Pg-central.pl to populate these databases, which seemed to work 
(logging into each database as postgres superuser, I used "\i 
Pg-central.pl" to import).
It was also unclear how database access works in regard to 
ledgersmb.conf--does DBname point to the user info database or the 
accounting database?  So I set up the DBname to point to 
ledgersmb_users_phs. Not sure what to do about the others, but hopefully 
it would become clearer as I learned more.  I imported the users from 
the existing "members" file (after editing the members file to change 
the database each user belonged to) using import-members.pl, and it 
reported success (falsely, it appears--admin is the only row that exists 
in each database's users table).

I did manage to get the admin password to work (doing "update users_conf 
set password = md5('password');" in the user database that is pointed to 
in ledgersmb.conf).  But it doesn't appear to be seeing any of my 
existing datasets (no surprise there, because nothing is telling it what 
database to look in!)  Also, user import doesn't seem to have actually 
worked, because the user information is absent.  I had evidently been 
operating perfectly happily for years with no sql-ledger.conf file (it 
didn't seem to need it!), but that's obviously not going to fly anymore.

I'm pretty sure this would be easy to clean up, if I knew where things 
were supposed to be pointing, and which database which tables should 
live in.  Should there be one user database or several?  If the 
user-data belongs in among the accounting data, how to get past the 
"session" relation error (e.g. just drop the "session" table before 
importing Pg-central)?  How do we get from the user database to the 
accounting info database (obviously not an issue if the user info lives 
in the same database)?  If multiple user databases are employed, how 
does ledgersmb.conf work with that (or multiple companies for that matter)?

Also, is going from 1.1.12 to 1.2.26 worth it, or am I going to have 
exactly the same amount of pain going 1.2.26->1.3?  Should I go straight 
from 1.1.12 to 1.3.x? Or should I go straight from SQL-Ledger 2.6.27 to 
ledgerSMB 1.3.x?

I hope this doesn't sound as confused as I feel.  Thanks!
Victor Wren

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
Erik Huelsmann | 1 Apr 2012 19:57
Picon
Gravatar

Re: Upgrading and converting: SL-->LSMB 1.1-->LSMB 1.2.26

Hi Victor,


On Sun, Apr 1, 2012 at 5:30 PM, Victor Wren <vwren-P1vqRHQxxZFWk0Htik3J/w@public.gmane.org> wrote:
I built up a new server (from compiled sources), and I'm trying to move
an existing SQL-Ledger 2.6.27 system over to LSMB (these were running on
an ancient Fedora 4 system).  I first converted to 1.1.12, per the
suggestions, and it seemed to go smoothly-- It had exactly the same
problems as SL at that level (didn't play nice with Perl 5.14 or
PostgreSQL 9), so once I verified that all my data and user accounts
were working correctly, I tried to bring things more up to date by
moving to 1.2.26.

Ok. This is still the advised upgrade route.
 
I'm pretty sure this would be easy to clean up, if I knew where things
were supposed to be pointing, and which database which tables should
live in.  Should there be one user database or several?  If the
user-data belongs in among the accounting data, how to get past the
"session" relation error (e.g. just drop the "session" table before
importing Pg-central)?  How do we get from the user database to the
accounting info database (obviously not an issue if the user info lives
in the same database)?  If multiple user databases are employed, how
does ledgersmb.conf work with that (or multiple companies for that matter)?

Thanks for the extensive context you provided! It helps getting a picture of where you stand with your migration and where you want to go to. At this point, I would actually stop working to get the users migrated from 1.1 to 1.2 (which is still the route to go: there are migration scripts to go from 1.2 to 1.3).

The reason I'd stop trying very hard to migrate the users - if all else works - is documented in the book I've just started writing on 1.3 (http://book.ledgersmb.org/1.3/ledgersmb.pdf; Appendix A Section A.1 Users): ""It’s this shift in paradigm that makes it impossible to meaningfully migrate users from older LedgerSMB and SQL-Ledger versions to LedgerSMB 1.3.""


Also, is going from 1.1.12 to 1.2.26 worth it, or am I going to have
exactly the same amount of pain going 1.2.26->1.3?  Should I go straight
from 1.1.12 to 1.3.x? Or should I go straight from SQL-Ledger 2.6.27 to
ledgerSMB 1.3.x?

Going through 1.2 to get at 1.3 is still the suggested route. The book also contains an appendix on migration (Appendix B) which says ""Yet, while item 3 [a stricter data model] is a good reason to want to switch, it’s also a reason why migration from older versions to 1.3 can be harder than earlier migrations: when the data in your older version is not consistent, it won’t fit into the new data model and will need to be fixed first.""

So, if you were asking me, I'd go forward, spending no more time on migrating users, instead going to 1.3 and spending the time you have on any potential data inconsistencies. Please note that your migration issues provide very valuable insight both to develop better migration scripts as well as a source for problem solving for anybody coming after you, if you'd share your experiences here.

Next to seeing your experiences, we'd love to help you forward, if we can.


I hope this doesn't sound as confused as I feel.  Thanks!
Victor Wren

On the contrary! Your story was very clear and to the point. I hope my answer helps you forward!


Bye,

Erik. 
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
Erik Huelsmann | 1 Apr 2012 21:54
Picon
Gravatar

Testimonials solicited

Hi,

In order to get a feel for the experience people have - and in which industries - I'm looking for testimonials: short stories telling me what your experience with LedgerSMB is, if you had setup/startup issues, which issues you're currently experiencing and how that influences your opinion of the application. If you're not experiencing any issues, all the better!

Could you take 5 minutes to jot up a short story? Please include a shortlist of the features you're using and which industry you're in.


Thanks in advance!

Bye,


Erik.
LedgerSMB core developer

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
Victor Wren | 2 Apr 2012 04:14
Gravatar

Re: Upgrading and converting: SL-->LSMB 1.1-->LSMB 1.2.26



On 12/04/01 12:57, Erik Huelsmann wrote:
Hi Victor,

I'm pretty sure this would be easy to clean up, if I knew where things
were supposed to be pointing, and which database which tables should
live in.  Should there be one user database or several?  If the
user-data belongs in among the accounting data, how to get past the
"session" relation error (e.g. just drop the "session" table before
importing Pg-central)?  How do we get from the user database to the
accounting info database (obviously not an issue if the user info lives
in the same database)?  If multiple user databases are employed, how
does ledgersmb.conf work with that (or multiple companies for that matter)?

Thanks for the extensive context you provided! It helps getting a picture of where you stand with your migration and where you want to go to. At this point, I would actually stop working to get the users migrated from 1.1 to 1.2 (which is still the route to go: there are migration scripts to go from 1.2 to 1.3).

Currently, I have no way of verifying that my transition from 1.1.12 up to 1.2.26 went smoothly, so I'd rather not go on to 1.3 until I can determine whether I have, in fact, succeeded in upgrading to 1.2.26.  I created a test user, using information from the original members file, but attempting to log in with that user get me this:

Error!
LedgerSMB/User.pm:207
SELECT value FROM defaults
WHERE setting_key = 'version'
ERROR: column "value" does not exist
LINE 2: SELECT value FROM defaults

This suggests to me that the database schema did not get updated.  That led me to scrutinize the instructions for database upgrade a little closer.  The version of the database that showed in the "version" column of "defaults" was 2.6.18.  Running the 2.6.18-2.6.19 SQL script seems to have removed the last obstacle.  Now I just need to create users for the other two databases (or preferably look up how to export and import users).  Hopefully any database schema changes from 1.2 to 1.3 will be handled a little more automatically, now that more of the vestiges of SL have been cast off.

The reason I'd stop trying very hard to migrate the users - if all else works - is documented in the book I've just started writing on 1.3 (http://book.ledgersmb.org/1.3/ledgersmb.pdf; Appendix A Section A.1 Users): ""It’s this shift in paradigm that makes it impossible to meaningfully migrate users from older LedgerSMB and SQL-Ledger versions to LedgerSMB 1.3.""
That's reasonable (as long as the historical transactions are still attributed to the correct users--or if they don't care if the users who posted them no longer exist, which would be expected in a company where staff changes).

Going through 1.2 to get at 1.3 is still the suggested route. The book also contains an appendix on migration (Appendix B) which says ""Yet, while item 3 [a stricter data model] is a good reason to want to switch, it’s also a reason why migration from older versions to 1.3 can be harder than earlier migrations: when the data in your older version is not consistent, it won’t fit into the new data model and will need to be fixed first.""

I'm hoping there will be some tutorial on ways of fixing inconsistencies?  Or is that too broad a category?

So, if you were asking me, I'd go forward, spending no more time on migrating users, instead going to 1.3 and spending the time you have on any potential data inconsistencies. Please note that your migration issues provide very valuable insight both to develop better migration scripts as well as a source for problem solving for anybody coming after you, if you'd share your experiences here.

I'd like to make sure that 1.2 is actually working fully before going to 1.3.  I'm reasonably certain that it's working, but I just discovered that my database snapshot was taken before a day's worth of entries (sigh).  Re-entering those will be a good trial run for functionality.

--Victor Wren
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
Chris Travers | 2 Apr 2012 04:40
Picon

Re: Upgrading and converting: SL-->LSMB 1.1-->LSMB 1.2.26

On Sun, Apr 1, 2012 at 7:14 PM, Victor Wren <vwren@...> wrote:

>
> That's reasonable (as long as the historical transactions are still
> attributed to the correct users--or if they don't care if the users who
> posted them no longer exist, which would be expected in a company where
> staff changes).

Employee records import.  User/auth records do not.  So this is not
currently a problem.
>
>
> Going through 1.2 to get at 1.3 is still the suggested route. The book also
> contains an appendix on migration (Appendix B) which says ""Yet, while item
> 3 [a stricter data model] is a good reason to want to switch, it’s also a
> reason why migration from older versions to 1.3 can be harder than earlier
> migrations: when the data in your older version is not consistent, it won’t
> fit into the new data model and will need to be fixed first.""
>
>
> I'm hoping there will be some tutorial on ways of fixing inconsistencies?
> Or is that too broad a category?

When you run the setup.pl, it will attempt to detect these
inconsistencies and give you a chance to fix them (I just added this
to the book btw).  One thing to keep in mind is that fixes to this are
written to the *old* data before the migration is run, so this part
persists even after backing out of the upgrade.  If it still fails it
will give you an idea why in the dblog_stderr (in /tmp/ or
/tmp/ledgersmb depending on configuration) and you can get help on the
lists here.

>
>
> So, if you were asking me, I'd go forward, spending no more time on
> migrating users, instead going to 1.3 and spending the time you have on any
> potential data inconsistencies. Please note that your migration issues
> provide very valuable insight both to develop better migration scripts as
> well as a source for problem solving for anybody coming after you, if you'd
> share your experiences here.

I would suggest that. Remember everything except for data integrity
fixes can be rolled back during the 1.2-1.3 upgrade.  In fact, we
provide a script for this.  the one thing to keep in mind is that when
you are done backing out, and you have gotten help as to why it
failed, you probably want to drop the lsmb13_fail schema as that will
prevent the next try from being backed out of easily.

Best Wishes,
Chris Travers

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
Victor Wren | 2 Apr 2012 20:44
Gravatar

Migration Note: "isZero" errors

I realize that 1.2 may be a "dead issue" at this point, but I just thought I'd bring up a couple of things that I've encountered while trying to confirm that my upgrade was successful.

In my migration from 1.1.12 to 1.2.26 (passing through on my way to 1.3), I have been running into a number of these with 1.2.26:

menu.pl:92: Can't call method "is_zero" on an undefined value at /usr/lib/perl5/5.14.2/Math/BigInt.pm line 1197.

with a POS transaction I get something a little different:
menu.pl:92: Can't call method "is_zero" on unblessed reference at /usr/lib/perl5/5.14.2/Math/BigFloat.pm line 507.

I am wondering if this could be due to uninitialized fields in columns added during the last schema upgrade (fields that contain "Null" instead of zero?).   Is there a script I missed which might sanitize the databases once they're brought up to the current schema?  Or a suggestion to which columns might be altered to make it happy?

About the only errors I see in my server logs are  things like this:
Math::BigInt: couldn't load specified math lib(s), fallback to Math::BigInt::Calc at LedgerSMB/Form.pm line 36, referer: http://ledger/ar.pl

--Victor Wren
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
Erik Huelsmann | 2 Apr 2012 21:09
Picon
Gravatar

Re: Migration Note: "isZero" errors

Hi Victor,

On Mon, Apr 2, 2012 at 8:44 PM, Victor Wren <vwren-P1vqRHQxxZFWk0Htik3J/w@public.gmane.org> wrote:
I realize that 1.2 may be a "dead issue" at this point, but I just thought I'd bring up a couple of things that I've encountered while trying to confirm that my upgrade was successful.

In my migration from 1.1.12 to 1.2.26 (passing through on my way to 1.3), I have been running into a number of these with 1.2.26:

menu.pl:92: Can't call method "is_zero" on an undefined value at /usr/lib/perl5/5.14.2/Math/BigInt.pm line 1197.

with a POS transaction I get something a little different:
menu.pl:92: Can't call method "is_zero" on unblessed reference at /usr/lib/perl5/5.14.2/Math/BigFloat.pm line 507.

I am wondering if this could be due to uninitialized fields in columns added during the last schema upgrade (fields that contain "Null" instead of zero?).   Is there a script I missed which might sanitize the databases once they're brought up to the current schema?  Or a suggestion to which columns might be altered to make it happy?

There were several fixes to 1.3 to help eliminate this error. I'm not sure if it can be eliminated by changing the data in the database. Chris?
 
About the only errors I see in my server logs are  things like this:
Math::BigInt: couldn't load specified math lib(s), fallback to Math::BigInt::Calc at LedgerSMB/Form.pm line 36, referer: http://ledger/ar.pl

1.3 might suffer from this error as well. You can install Math::BigInt::GMP to prevent that error.


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Ledger-smb-users mailing list
Ledger-smb-users@...
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
Chris Travers | 3 Apr 2012 02:19
Picon

Re: Migration Note: "isZero" errors

On Mon, Apr 2, 2012 at 11:44 AM, Victor Wren <vwren@...> wrote:
> I realize that 1.2 may be a "dead issue" at this point, but I just thought
> I'd bring up a couple of things that I've encountered while trying to
> confirm that my upgrade was successful.
>
> In my migration from 1.1.12 to 1.2.26 (passing through on my way to 1.3), I
> have been running into a number of these with 1.2.26:
>
> menu.pl:92: Can't call method "is_zero" on an undefined value at
> /usr/lib/perl5/5.14.2/Math/BigInt.pm line 1197.
>
> with a POS transaction I get something a little different:
> menu.pl:92: Can't call method "is_zero" on unblessed reference at
> /usr/lib/perl5/5.14.2/Math/BigFloat.pm line 507.

There are issues in some versions of Math::BigFloat.  Which version
are you running?  I just checked and for some reason I think I am
running 1.6.  Did you install from CPAN or from your distro's repos?

Best Wishes,
Chris Travers
>
> I am wondering if this could be due to uninitialized fields in columns added
> during the last schema upgrade (fields that contain "Null" instead of
> zero?).   Is there a script I missed which might sanitize the databases once
> they're brought up to the current schema?  Or a suggestion to which columns
> might be altered to make it happy?
>
> About the only errors I see in my server logs are  things like this:
> Math::BigInt: couldn't load specified math lib(s), fallback to
> Math::BigInt::Calc at LedgerSMB/Form.pm line 36, referer:
> http://ledger/ar.pl
>
> --Victor Wren
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Ledger-smb-users mailing list
> Ledger-smb-users@...
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
>

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev

Gmane