Re: [Ledger-smb-devel] Tentative Schedule for 1.4
Main things I'm thinking about needing here: - tracking employer, employee contributions to each of the various taxes we need to pay, with variable rates for each. e.g. unemployment insurance varies quarter by quarter and employer by employer. Chris Not just taxes. Also things like health insurance, etc. And Chris these have to be categorized so we know how to handle them Chris tax-wise. Right now, I do payroll by calculating stuff using either a spreadsheet I cooked up, or using a calculator that cra.gc.ca provides, or sometimes using the paper tables. I then enter this into a GL entry for each employee, and I then Post-as-New each time. I know that 1.3 has much improvements for recurring transactions, and I think can do some calculations in the recurring transaction. That in itself would go a LONG way for me. What John writes above, about being able to get a list of contributions on a per-employ basis would be a major low-hanging fruit. After that, the only thing necessary is to have plugins that can do the calculation for you. At first pass this might be actually a good use for javascript! - tracking accumulation of PTO (Paid time off) which in our case accumulates per hour worked for hourly employees, and per pay period for salaried -- probably need to support a variety of rules based on company policy Chris I think we need an interface for custom stored procedures Chris here. This also provides an opportunity for handling these Chris as reporting entities or as things which get tracked Chris specifically elsewhere. Rule sets can be added as necessary. So, PTO isn't a concern for me (we have other mechanisms to track this, and for CREDIL.org, it's rather more complicated. And we want our employees to be able to see the PTO values, but they don't get access to the accounting system...) If one have PTO in your books, it must be as a liability, then it seems to me this is essentially identical to vacation pay. Chris Timecards are for tracking billable labor for a project. A Chris payroll timecard system would be somewhat different. Chris Long-run these timecards are specific to cost accounting for Chris business reporting units (projects, engineer-to-order jobs, Chris manufacturing lots, and the like. Chris On a related note, I think I will probably want to replace Chris the current timecard system with something a little more Chris flexible, particularly where manufacturing is needed. To be Chris honest, the logic here is such such that it probably makes Chris more sense to do this sooner rather than later, and may not Chris be a whole lot of work. My opinion is that the timecard interface is inappropriate. We need APIs here, not systems Chris The key to what you need though is separation of duties, and Chris that would have to be included. With separation of duties, Chris it becomes reasonable to just import the data automatically Chris from your other system, then review it, approve, etc. How Chris that gets imported is then an implementation detail. It Chris could be done via csv, xml, directly into the database, Chris etc. and you are still in control of your books. Exactly. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
On 02/24/2012 05:44 PM, Chris Travers wrote: Ideally web services, like reporting, would happen after the main transactional functionality is stable enough for early beta testing. I think the first step is getting a framework in place that defines the endpoints, the formatting of the data, etc. Something that converts a web service payload into some sort of Perl object that can be populated based on LSMB data. So maybe a script which: 1) Converts XML and JSON into a $request object 2) Converts a $request object to XML or JSON 3) Hands off to web service modules for URL parsing and work I am thinking those web service modules would all accept three arguments: $request, $url, $method When I've done this before I've set it up slightly differently: 1. Deserialize request into some standard data structure ($request object) with headers, hash of data passed/deserialized request body, path 2. Main controller parses URL and uses conventions to load controller for a specific request, creates an appropriate response object based on request 3. Main controller calls standard method (determined by HTTP method/specific parameters) on the controller object with $request and $response object 4. Specific controllers load up native DB objects, populate with incoming data, call methods appropriate to actions, and populates $response object 5. Main controller returns serialized $response object I'd say the main difference is taking the standard centralized stuff one step further than you've outlined, doing the URL parsing and establishing conventions before handing off to individual web service controllers. I've also found it useful to have separate request and response objects, though at the moment I don't recall why. And of course have a different class for each type of response and request -- XML, JSON, HTML, etc. -- that implement standard methods that the framework can call regardless of type. I am also thinking the stuff we are doing with Moose will make this better in the long-run. We can use the defined data structures there as both the documented API and the basis for XML and JSON formats. Excellent. Is this going to be available in 1.4? Cheers, John Locke http://www.freelock.com -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
Chris == Chris Travers chris.trav...@gmail.com writes: Chris Once the business unit code is all in and breakage corrected, Chris and the customer/vendor db redesign complete (nothing major Chris here, just a few tweakstweaks!), then transactional testing Chris can begin. Chris I would note a couple things: Once I can into 1.3, I will be running your 1.4 stuff as soon as you say I should try. I just have to get past this 1.2-1.3 hump :-) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
On Fri, Feb 24, 2012 at 11:14 AM, John Locke m...@freelock.com wrote: On 02/23/2012 04:20 PM, Chris Travers wrote: Payroll varies a tremendous amount from state to state and from country to country. What we will have will be a framework for building systems which provide payroll functionality. It isn't clear yet which locations will be supported. Because of the fact that rules tend to change frequently, I think this is likely to be a framework which allows local or regional businesses (working with me or on their own) to create payroll systems. I think we'll be able to plug in appropriate rules if there's a model we can use to get started. Main things I'm thinking about needing here: - tracking employer, employee contributions to each of the various taxes we need to pay, with variable rates for each. e.g. unemployment insurance varies quarter by quarter and employer by employer. Not just taxes. Also things like health insurance, etc. And these have to be categorized so we know how to handle them tax-wise. - tracking accumulation of PTO (Paid time off) which in our case accumulates per hour worked for hourly employees, and per pay period for salaried -- probably need to support a variety of rules based on company policy I think we need an interface for custom stored procedures here. This also provides an opportunity for handling these as reporting entities or as things which get tracked specifically elsewhere. Rule sets can be added as necessary. - tracking usage of PTO That could be done through tracking of income types for the employee. This is not only necessary to use to track something like the sorts of variations you have regarding required employer contributions that can crop up with things like agricultural labor in Washington State. - calculate overtime per week - schedule tax payments, post to correct accounts - quick bulk entry of hours per pay period -- we don't use the LSMB timecard feature, we have another system for this. Timecards are for tracking billable labor for a project. A payroll timecard system would be somewhat different. Long-run these timecards are specific to cost accounting for business reporting units (projects, engineer-to-order jobs, manufacturing lots, and the like. On a related note, I think I will probably want to replace the current timecard system with something a little more flexible, particularly where manufacturing is needed. To be honest, the logic here is such such that it probably makes more sense to do this sooner rather than later, and may not be a whole lot of work. The key to what you need though is separation of duties, and that would have to be included. With separation of duties, it becomes reasonable to just import the data automatically from your other system, then review it, approve, etc. How that gets imported is then an implementation detail. It could be done via csv, xml, directly into the database, etc. and you are still in control of your books. I would like to make some UI improvements using Dojo Toolkit, but this will be so much easier to do when there's a web services back end. Web services are on the road map. I guess my main question to everyone on the list is what I can do to facilitate contributions in this area? Right now I am thinking of reviving Jason Rodrigues's work on this area.and setting it up so that we can get more involvement in actually hooking it into old or new code. At this point, I still don't have that much time to contribute. If there's a framework in place for this, I'd probably be able to do some fleshing out of individual resources. I will look into it once trunk is stable enough for testing of transaction entry. That will put it along with csv imports of more things, and new reporting. Ideally web services, like reporting, would happen after the main transactional functionality is stable enough for early beta testing. I think the first step is getting a framework in place that defines the endpoints, the formatting of the data, etc. Something that converts a web service payload into some sort of Perl object that can be populated based on LSMB data. So maybe a script which: 1) Converts XML and JSON into a $request object 2) Converts a $request object to XML or JSON 3) Hands off to web service modules for URL parsing and work I am thinking those web service modules would all accept three arguments: $request, $url, $method I am also thinking the stuff we are doing with Moose will make this better in the long-run. We can use the defined data structures there as both the documented API and the basis for XML and JSON formats. Then it's a matter of doing that mapping between the web service and the LSMB data structures. I would think there's some low hanging fruit here: * account list, to populate GL transactions * vendor/customer lists * part lookups * menu lookup Without getting into any financial
[Ledger-smb-devel] Tentative Schedule for 1.4
Hi all; I am finishing up what is probably the last of the major backwards-compatibility-breaking features for 1.4, which is the rewrite of projects and departments. I expect to have trunk in a usable (for testing) state within another week. After that I expect to be working on payroll framework and refactoring the contact management. I hope to have these fully working on 1.4 by the end of March. After that point, all manual transaction-entry parts of the web application should be ready for testing, and my work will shift to reporting and CSV imports. I think we can consider 1.4 to be in early beta, but not feature-complete at the time these areas are complete. Reporting and import logic can be worked on concurrent to testing of transaction entry. I would like to hit feature freeze around the beginning of June, with betas at that point being released every two weeks. I think that if things go well, we can shoot for a general release in September. What do people think? Best Wishes, Chris Travers -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
Chris, On 2012-02-23 19:00, Chris Travers wrote: Hi all; I am finishing up what is probably the last of the major backwards-compatibility-breaking features for 1.4, which is the rewrite of projects and departments. I expect to have trunk in a usable (for testing) state within another week. After that I expect to be working on payroll framework and refactoring the contact management. I hope to have these fully working on 1.4 by the end of March. After that point, all manual transaction-entry parts of the web application should be ready for testing, and my work will shift to reporting and CSV imports. I think we can consider 1.4 to be in early beta, but not feature-complete at the time these areas are complete. Reporting and import logic can be worked on concurrent to testing of transaction entry. I would like to hit feature freeze around the beginning of June, with betas at that point being released every two weeks. I think that if things go well, we can shoot for a general release in September. What do people think? I presume we could be testing from the beginning and if we are not using the newly worked on features or the ones waiting to be worked on, we should be good? - in terms of the data being maintained up to a proper release? My immediate demand is for just minimal, basic accounting . . a few large incomings and regular small outgoings, bank charges etc Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
Chris, On 2012-02-23 21:54, Chris Travers wrote: On Thu, Feb 23, 2012 at 2:12 AM, Philip Rhoades p...@pricom.com.au [1] wrote: I presume we could be testing from the beginning and if we are not using the newly worked on features or the ones waiting to be worked on, we should be good? - in terms of the data being maintained up to a proper release? My immediate demand is for just minimal, basic accounting . . a few large incomings and regular small outgoings, bank charges etc Thats correct. Once the business unit code is all in and breakage corrected, and the customer/vendor db redesign complete (nothing major here, just a few tweakstweaks!), then transactional testing can begin. I would note a couple things: Financial storage and financial information storage routines are not changing in 1.4. So bugs should be more on the this is broken and doesnt wtweakstweaksork line rather than the this is saving incorrect data. I dont anticipate very many of these actually. As we get into reporting though, you will want to be double checking the reports as you upgrade. Check the changelogs for details before you do and compare old/new reports, flagging differences. Also truly new features like transaction import of things like timecards and chart of accounts entries may have a greater likelihood of bugs/incorrect entry. Also I believe we will probably clear the Fixes.sql so it goes back no more than one beta, so if you are doing this youd need to stay up to date. Now worries - if I can get done what I need to and also help with testing, I'll be happy. I have a few years of back accounts to deal with (same organisation) but I will consult with you privately about the best approach etc. While this (non-profit) still does not have a high transaction rate - we hope it will in the future, so I would like to have a complete set of accounts by the time that starts happening. Thanks, Phil. -- Philip Rhoades GPO Box 3411 Sydney NSW 2001 Australia E-mail: p...@pricom.com.au -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
Hi, Chris, Sounds good! Notes/questions below... On 02/23/2012 12:00 AM, Chris Travers wrote: Hi all; I am finishing up what is probably the last of the major backwards-compatibility-breaking features for 1.4, which is the rewrite of projects and departments. I expect to have trunk in a usable (for testing) state within another week. After that I expect to be working on payroll framework and refactoring the contact management. I hope to have these fully working on 1.4 by the end of March. After that point, all manual transaction-entry parts of the web application should be ready for testing, and my work will shift to reporting and CSV imports. Really looking forward to the payroll framework, that's going to be a huge win for us. Is anybody working on the web services infrastructure we discussed a while back? That's the other big thing we're interested in. I think we can consider 1.4 to be in early beta, but not feature-complete at the time these areas are complete. Reporting and import logic can be worked on concurrent to testing of transaction entry. Are you running any of your production customers on trunk/1.4? We're definitely tracking the 1.3 branch still, but if the core financial logic should stay sound, and there's work being done on web services and payroll in 1.4, I'd be willing to switch us over when you hit that early beta milestone and be an early tester again. I would like to make some UI improvements using Dojo Toolkit, but this will be so much easier to do when there's a web services back end. I would like to hit feature freeze around the beginning of June, with betas at that point being released every two weeks. I think that if things go well, we can shoot for a general release in September. What do people think? I think it sounds great! Thanks for all your hard work on this. Cheers, John Locke http://www.freelock.com -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
Re: [Ledger-smb-devel] Tentative Schedule for 1.4
Hi John; On Thu, Feb 23, 2012 at 10:41 AM, John Locke m...@freelock.com wrote: Hi, Chris, Sounds good! Notes/questions below... On 02/23/2012 12:00 AM, Chris Travers wrote: Hi all; I am finishing up what is probably the last of the major backwards-compatibility-breaking features for 1.4, which is the rewrite of projects and departments. I expect to have trunk in a usable (for testing) state within another week. After that I expect to be working on payroll framework and refactoring the contact management. I hope to have these fully working on 1.4 by the end of March. After that point, all manual transaction-entry parts of the web application should be ready for testing, and my work will shift to reporting and CSV imports. Really looking forward to the payroll framework, that's going to be a huge win for us. Is anybody working on the web services infrastructure we discussed a while back? That's the other big thing we're interested in. I am thinking about reviving Jason's work on the old code here. I don't know of anyone doing active work on the new code. I think we can consider 1.4 to be in early beta, but not feature-complete at the time these areas are complete. Reporting and import logic can be worked on concurrent to testing of transaction entry. Are you running any of your production customers on trunk/1.4? We're definitely tracking the 1.3 branch still, but if the core financial logic should stay sound, and there's work being done on web services and payroll in 1.4, I'd be willing to switch us over when you hit that early beta milestone and be an early tester again. Not yet. My suggestion would be this: 1) Wait about another month for the customer/vendor stuff to get solidified. 2) Run in parallel for a month just to make sure that core things work for you Also a note on payroll. Payroll varies a tremendous amount from state to state and from country to country. What we will have will be a framework for building systems which provide payroll functionality. It isn't clear yet which locations will be supported. Because of the fact that rules tend to change frequently, I think this is likely to be a framework which allows local or regional businesses (working with me or on their own) to create payroll systems. I would like to make some UI improvements using Dojo Toolkit, but this will be so much easier to do when there's a web services back end. Web services are on the road map. I guess my main question to everyone on the list is what I can do to facilitate contributions in this area? Right now I am thinking of reviving Jason Rodrigues's work on this area.and setting it up so that we can get more involvement in actually hooking it into old or new code. Ideally web services, like reporting, would happen after the main transactional functionality is stable enough for early beta testing. I would like to hit feature freeze around the beginning of June, with betas at that point being released every two weeks. I think that if things go well, we can shoot for a general release in September. What do people think? I think it sounds great! Thanks for all your hard work on this. Thanks! Best Wishes, Chris Travers Cheers, John Locke http://www.freelock.com -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
