Re: [Ledger-smb-devel] Proposed financial schema for financial info
I think the PO should be on the invoice header. In our scenario, we get a PO for a project, drop it into the Sales order, and have multiple invoices on that PO. Having the PO in a specified field makes it easier for our customers to find on the invoice when they go to pay it, and also for us to show on a report/search for invoices associated with a PO. If we have multiple POs, we can always do multiple invoices -- these are probably associated with different contacts at a customer, anyway. What Erik describes is the same as our workflow, for our larger customers... Cheers, John On 10/07/2011 01:22 PM, Chris Travers wrote: On Fri, Oct 7, 2011 at 1:16 PM, Erik Huelsmann ehu...@gmail.com wrote: Hi Chris, In the schema you sent, you write that you intend to use one of the new links in the invoice table to get the PONumber field as it is currently available in the AR table. The links you're referring to are the previous document (sales order, sales request, etc) links. Let me describe my use-case where I think this linking system won't work for me. (Note that I'm involved in multiple businesses; the use-case below is a use-case from my self-employment. I'm not currently using LSMB to create invoices for that business, but I'm using the requirements as a showcase.) Because I have relatively few contracts (8 or 10 per year) in my self-employment business, I'm not creating sales orders for these contracts. I'm just creating the invoices directly, using my hours registrations and whatever additional requirements my customers have. One of my customers requires me to use *their* PO number to be on the invoice. They use it to link the digital and physical information flows: the physical invoice never actually reaches my contacts - instead it's being processed by a central processing office. Without that number, they can't link the invoice to the right file. Without that number, I won't be paid. Ok, so question for everyone: Should the PO number field be on the header or the invoice line item? I am thinking for now just to add it to the header (since that is the way it's done right now) because it is easier to go the to the other from here if we need to. But that still does bring up the question: Should client PO's map at most 1:1 to invoices? or should we allow an invoice to invoice delivery of goods and services off multiple PO's? If in doubt, I think we should keep the current behavior for now while we evaluate, but want to get feedback. Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel !DSPAM:4e8f5fb1202861682214271! -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
The last UPDATE in sql/upgrade/1.2-1.3-manual.sql is: UPDATE defaults SET value = '1.2.99' WHERE setting_key = 'version'; and the first login attempt ends with the error: Database is not the expected version. Was 1.2.99, expected 1.3.0 So the question is just manually change the version or is there one or more steps after 1.2-1.3-manual.sql? Doing a manual update: UPDATE defaults SET value = '1.3.0' WHERE setting_key = 'version'; produces: 25P02:ERROR: current transaction is aborted, commands ignored until end of transaction block From apache's log (with the [Sat Oct 08 12:14:58 2011] [error] [client 127.0.0.1] removed) DBD::Pg::st execute failed: ERROR: function check_expiration() does not exist, referer: http://localhost/lsmb13/login.pl LINE 1: SELECT check_expiration(), referer: http://localhost/lsmb13/login.pl ^, referer: http://localhost/lsmb13/login.pl HINT: No function matches the given name and argument types. You might need to add explicit type casts. at LedgerSMB.pm line 967., referer: http://localhost/lsmb13/login.pl DBD::Pg::st fetchrow_array failed: no statement executing at LedgerSMB.pm line 968., referer: http://localhost/lsmb13/login.pl DBD::Pg::st execute failed: ERROR: current transaction is aborted, commands ignored until end of transaction block at LedgerSMB.pm line 983., referer: http://localhost/lsmb13/login.pl DBD::Pg::st fetchrow_hashref failed: no statement executing at LedgerSMB.pm line 985., referer: http://localhost/lsmb13/login.pl DBD::Pg::st execute failed: ERROR: current transaction is aborted, commands ignored until end of transaction block at LedgerSMB.pm line 995., referer: http://localhost/lsmb13/login.pl DBD::Pg::st fetchrow_array failed: no statement executing at LedgerSMB.pm line 996., referer: http://localhost/lsmb13/login.pl DBD::Pg::st execute failed: ERROR: current transaction is aborted, commands ignored until end of transaction block at LedgerSMB.pm line 781., referer: http://localhost/lsmb13/login.pl 2011/10/08 12:14:58 - ERROR Logging SQL State 25P02, error 7, string ERROR: current transaction is aborted, commands ignored until end of transaction block, referer: http://localhost/lsmb13/login.pl ERROR - Logging SQL State 25P02, error 7, string ERROR: current transaction is aborted, commands ignored until end of transaction block, referer: http://localhost/lsmb13/login.pl Issuing rollback() due to DESTROY without explicit disconnect() of DBD::Pg::db handle dbname=lsmb13 at LedgerSMB.pm line 899., referer: http://localhost/lsmb13/login.pl Suggesting that simply flipping 1.2.99 to 1.3.0 after 1.2-1.3-manual.sql is not enough. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
On Sat, Oct 8, 2011 at 11:24 AM, lbml...@hethcote.com wrote: The last UPDATE in sql/upgrade/1.2-1.3-manual.sql is: UPDATE defaults SET value = '1.2.99' WHERE setting_key = 'version'; and the first login attempt ends with the error: Database is not the expected version. Was 1.2.99, expected 1.3.0 So that's where that came from. Ok, fixing. Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
On Sat, 8 Oct 2011, lbml...@hethcote.com wrote: Suggesting that simply flipping 1.2.99 to 1.3.0 after 1.2-1.3-manual.sql is not enough. remembering that Chris had told me at one point Also, you will be better on most recent svn because you can just cd to sql/modules after and run sh reload_modules.sh [dbname] i hasten'd to sql/modules (Where reading reload_modules.sh it dawned on me that the dbname==COMPANY, so dbname of lsmb13 is not a good choice). after reload_modules. i log into 1.3-- but it has nothing but a logo and Logged into lsmb13 -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
On Sat, Oct 8, 2011 at 11:43 AM, lbml...@hethcote.com wrote: On Sat, 8 Oct 2011, lbml...@hethcote.com wrote: Suggesting that simply flipping 1.2.99 to 1.3.0 after 1.2-1.3-manual.sql is not enough. remembering that Chris had told me at one point The reason it is in there is because we import defaults from the 1.2 db. Also, you will be better on most recent svn because you can just cd to sql/modules after and run sh reload_modules.sh [dbname] i hasten'd to sql/modules (Where reading reload_modules.sh it dawned on me that the dbname==COMPANY, so dbname of lsmb13 is not a good choice). after reload_modules. i log into 1.3-- but it has nothing but a logo and Logged into lsmb13 Not sure what you mean by this. I am running one further test with the setup.pl on most recent svn on my db (started with SL 2.2 and continuously upgraded to 1.2). Are you able to see your transactions? Best wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
Oh wait. You did this manually. Try this from sql/modules: sed -e 's/?lsmb dbname ?/lsmb13/g' Roles.sql | psql -U postgres lsmb13 In both cases, lsmb13 is the name of your database. If this is different, adjust accordingly. If you want to rename your database, do so first. It will save a lot of headaches later. Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
And you will need to then to add your user to roles. If you want to
give your role full perms:
SELECT admin__add_user_to_role('[username]', rolname)
FROM pg_roles
WHERE rolname like 'lsmb_' || current_database();
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3807 == Almost
sorry that query is wrong. Use this one
SELECT admin__add_user_to_role('[username]', rolname)
FROM pg_roles
WHERE rolname like 'lsmb_' || current_database() || '__%';
On Sat, Oct 8, 2011 at 11:59 AM, Chris Travers chris.trav...@gmail.com wrote:
And you will need to then to add your user to roles. If you want to
give your role full perms:
SELECT admin__add_user_to_role('[username]', rolname)
FROM pg_roles
WHERE rolname like 'lsmb_' || current_database();
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] Validation Tarball for 1.3.0 published
This is not a release announcement for 1.3.0, but it does anticipate a release within a couple of days. A validation tarball for 1.3.0 has been published. This means we anticipate a 1.3.0 release with no further changes within a couple of days if no major problems are found. This means that branches/1.3 is now in coding freeze while we check to make sure we haven't missed anything too serious or embarrassing. Typically such coding freezes last 48 hours. Anyone who would like to help ups outwith this process who is using the RC series can svn up to the latest or get the tarball at https://sourceforge.net/projects/ledger-smb/files/Validation%20Tarballs/1.3.0/ Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] New validation tarball available.
Hi all; In my checking I discovered a customer patch erroneously applied to branches 1.3. I have committed this and one other change, new validation tarball. This does restart code freeze. Best Wishes. Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] New validation tarball available.
On Sat, 2011-10-08 at 19:00 -0400, Chris Travers wrote: In my checking I discovered a customer patch erroneously applied to branches 1.3. I have committed this and one other change, new validation tarball. Is the templates directory in the archive supposed to be empty? Jame -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] New validation tarball available.
On Sat, 2011-10-08 at 19:28 -0400, Chris Travers wrote: On Sat, Oct 8, 2011 at 4:24 PM, Robert James Clay j...@rocasa.us wrote: On Sat, 2011-10-08 at 19:00 -0400, Chris Travers wrote: Is the templates directory in the archive supposed to be empty? The contents of that directory are correct. The multiple templates per language have been replaced by one template with translated strings. Ah, thanks Chris; I'll see about checking more closely into the changes that have taken place... Jame -- Robert James Clay j...@rocasa.us Rocasa LLC -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
[Ledger-smb-devel] upgrade 1.2.21 - 1.3.0 svn revision 3827 == Yes!
Yes, it does make sense. I was missing a couple of steps and now I'm where I can test. I have attached a script which is crude but which can upgrade my 1.2 to 1.3 in just a few minutes. It might help with either documentation or install scripts. I put a couple of things in a separate directory which bring in my local mods (for example: /usr/sbin/sendmail instead or /usr/bin/sendmail in ledgersmb.conf) that sort of thing. sed would also work but this was easier for the quick and dirty. What I am doing, in summary, is svn update to bring in latest revision; diffing select files to see if there are any changes I need to cope with in my local mods; cloning and upgrading the 1.2 database. It works and I am ready to begin running 1.3 in parallel upgrading as often as I wish. Thanks to ehu and Chris for the help. You guys saved me weeks of researching and trying stuff. Louis off to do the happy dance... On Sat, 8 Oct 2011, Chris Travers wrote: Brief explanation: LedgerSMB has gone from a hide-the-menu-item form of security to role-based database security. The menu items are now removed or not based upon the database roles one is granted, and these roles also control permissions to underlying tables. If you don't have adequate permissions, you won't be able to see menu items or do much of anything else. If the permissions are not set up, all menu items will be hidden. You can check the latter by: select count(*) from menu_acl; The former is probably better directly addressed rather than checked. Does this make sense? Best Wishes, Chris Travers -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel # # ./lsmb.sh 21 | tee freshbuild.log # set -o xtrace echo get latest svn and diffuse local changes cd lsmb130 svn status cd .. diffuse ./LedgerUpg/1.2-1.3-manual.sql ./lsmb130/sql/upgrade/1.2-1.3-manual.sql diffuse ./LedgerUpg/MY-reload_modules.sh ./lsmb130/sql/modules/reload_modules.sh diffuse ./LedgerUpg/ledgersmb.conf ./lsmb130/ledgersmb.conf.default echo preparing clone DB for the 1.3 upgrade dropdb lsmb13 rm -f ./LedgerUpg/lsmb-to-1.3.sql dropuser ledgernew pg_dump -C lsmbprod ./LedgerUpg/lsmb-to-1.3.sql pg_dump --inserts -C lsmbprod ./LedgerUpg/dbg-lsmb-to-1.3.sql sed -i -e's/lsmbprod/lsmb13/g' ./LedgerUpg/lsmb-to-1.3.sql sed -i -e's/ledgersmb/ledgernew/g' ./LedgerUpg/lsmb-to-1.3.sql sed -i -e's/lsmbprod/lsmb13/g' ./LedgerUpg/dbg-lsmb-to-1.3.sql sed -i -e's/ledgersmb/ledgernew/g' ./LedgerUpg/dbg-lsmb-to-1.3.sql createuser --no-createdb --no-createrole --no-superuser ledgernew psql -f ./LedgerUpg/lsmb-to-1.3.sql echo Fixing the 1.2 DB in preparation for the 1.3 upgrade psql --username=ledgernew -f ./LedgerUpg/fix-up-1.2.sql lsmb13 psql --username=ledgernew -f /usr/local/lsmb130/sql/upgrade/1.2-pre-upgrade-checks.sql lsmb13 echo Loading the code tar --exclude='.svn' -czf LedgerUpg/ledgersmb-latest.tar.gz ./lsmb130 cd /usr/local sudo rm -rf lsmb130/ # sudo tar --transform='s/^ledgersmb/lsmb130/' -x -z -f /PATH/TO/projects/thirdparty/LedgerUpg/ledgersmb-1.3.0_rc4.tar.gz sudo tar -x -z -f /PATH/TO/projects/thirdparty/LedgerUpg/ledgersmb-latest.tar.gz cd lsmb130 sudo perl Makefile.PL sudo make echo Load in the local customizations sudo cp /PATH/TO/projects/thirdparty/LedgerUpg/ledgersmb.conf ./ sudo cp /PATH/TO/projects/thirdparty/LedgerUpg/1.2-1.3-manual.sql sql/upgrade/ sudo cp /PATH/TO/projects/thirdparty/LedgerUpg/MY-reload_modules.sh sql/modules cd /usr/local sudo chown -R www-data:www-data lsmb130 cd lsmb130 psql -a -f sql/upgrade/1.2-1.3-manual.sql lsmb13 echo echo module reload echo cd sql/modules pwd sh ./MY-reload_modules.sh lsmb13 echo sed -e 's/?lsmb dbname ?/lsmb13/g' Roles.sql | psql -U postgres lsmb13 echo psql -a -f /PATH/TO/projects/thirdparty/LedgerUpg/roleplay.sql lsmb13 attachment: lsmb-2.jpg-- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
