| *** xapiens has joined #idempiere | 04:09 | |
| *** xapiens has quit IRC | 05:26 | |
| *** nmicoud has joined #idempiere | 06:29 | |
| *** nmicoud has quit IRC | 06:42 | |
| *** a42niem has joined #idempiere | 07:19 | |
| *** CarlosRuiz has joined #idempiere | 10:34 | |
| *** ChanServ sets mode: +o CarlosRuiz | 10:34 | |
| *** CarlosRuiz has quit IRC | 10:58 | |
| *** nmicoud has joined #idempiere | 11:28 | |
| *** nmicoud has quit IRC | 11:28 | |
| Not-c9fd | [IDEMPIERE] dantam created IDEMPIERE-2862 Wrong Groovy version (1.7.5) disables Groovy in JasperReports | 11:40 |
|---|---|---|
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2862 | 11:40 |
| Not-c9fd | [IDEMPIERE] dantam created IDEMPIERE-2863 NPE in ReportStarter using Swing/JasperReports | 11:44 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2863 | 11:44 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-2862 description set to "Groovy version 1.7.5 in org.adempiere.base causes Groovy to not function in JasperReports 5.1.2 which requires Groovy 2.0.1. Solution, upgrade groovy in org.adempiere.base to Groovy 2.0.1. Suggested code solution: https://bitbucket.org/dantam/idempiere.se/commits/d96dc6d3f18faf98967433d41d2aa8ab801c1611" | 11:49 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2862 | 11:50 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-2863 | 11:50 |
| Not-c9fd | [IDEMPIERE] Suggested code solution: https://bitbucket.org/dantam/idempiere.se/commits/f384d48fcc307e8ec44c41056976369c80dc9ab9 | 11:50 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2863 | 11:50 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-2863 status set to "Peer Review Queue" | 11:50 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2863 | 11:50 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-2862 status set to "Peer Review Queue" | 11:50 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2862 | 11:50 |
| Not-c9fd | [IDEMPIERE] red1 updated IDEMPIERE-2860 description set to "FitNesse Fixture plugin though working does not roll back most of its tests and user has to restore database each time before testing. Now, with a comprehensive set of trxName setup and removal of trx.commit, it will not commit. A new RollBack fixture will also close the trx to avoid memory leak. Thus tests can be run over and over for easier user | 12:16 |
| Not-c9fd | observation. Note that hard-coded commit such as Initial New Client Setup cannot be rolled back. Add this to any fixture or the last fixture in the suite. !|Roll Back| |*RollBack*|TRUE| or !|Roll Back| |*Commit*|TRUE| I will also submit the changes as new plugin so that user may swap without concern. Plugin will be described in idempiere wiki available plugins page. " | 12:16 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2860 | 12:16 |
| Not-c9fd | [IDEMPIERE] red1 updated IDEMPIERE-2860 description set to "FitNesse Fixture plugin though working does not roll back most of its tests and user has to restore database each time before testing. Now, with a comprehensive set of trxName setup and removal of trx.commit, it will not commit. A new RollBack fixture will also close the trx to avoid memory leak. Thus tests can be run over and over for easier user | 12:17 |
| Not-c9fd | observation. Note that hard-coded commit such as Initial New Client Setup cannot be rolled back. Add this to any fixture or the last fixture in the suite. !|Roll Back| |*RollBack*|TRUE| or !|Roll Back| |*Commit*|TRUE| I will also submit the changes as new plugin so that user may swap without concern. Plugin link described here http://wiki.idempiere.org/en/Plugin:_FitNesse_RollBack. " | 12:17 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2860 | 12:17 |
| Not-c9fd | [IDEMPIERE] red1 updated IDEMPIERE-2860 description set to "FitNesse Fixture plugin though working does not roll back most of its tests and user has to restore database each time before testing. Now, with a comprehensive set of trxName setup and removal of trx.commit, it will not commit. A new RollBack fixture will also close the trx to avoid memory leak. Thus tests can be run over and over for easier user | 12:17 |
| Not-c9fd | observation. Note that hard-coded commit such as Initial New Client Setup cannot be rolled back. Add this to any fixture or the last fixture in the suite. !|Roll Back| |*RollBack*|TRUE| or !|Roll Back| |*Commit*|TRUE| I also submitted the changes as new plugin so that user may swap without concern. Plugin link described here http://wiki.idempiere.org/en/Plugin:_FitNesse_RollBack. " | 12:17 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2860 | 12:18 |
| *** CarlosRuiz has joined #idempiere | 16:07 | |
| *** ChanServ sets mode: +o CarlosRuiz | 16:07 | |
| *** CarlosRuiz has quit IRC | 16:25 | |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 | 17:43 |
| Not-c9fd | [IDEMPIERE] I'm sorry that I have to re-open this issue, but this it's far too important to not work according to Generally Accepted Accounting Principles (GAAP). To not have the statement lines be accounted on the statement line date in the general ledger is like telling a formula-1 racing driver he can only drive on first gear. It just doesn't make sense to an accountant. The purpose of the Bank in Transit account | 17:43 |
| Not-c9fd | and other reconciliation accounts is to make sure that the payments are accounted on the correct date in the general ledger regardless if the payment takes zero days or 5 days. If the accounting date isn't correct on the bank statement we loose the meaning of the bank statement when it comes to creating a correct general ledger. If there are 100 transactions in one month and all payments are created automatically all | 17:43 |
| Not-c9fd | the accountant want to do is to create one bank statement for the complete month and the payments should be reconciled and accounted on the correct payment date in the general ledger. As the functionality is now this is not possible. The options are * Create one bank statement per date with transactions to get the accounting date correct in the GL. * Create one bank statement for the whole month but get all payments | 17:43 |
| Not-c9fd | accounted in the GL on the bank statement document date (which is so not GAAP). * Patch the system (which I do on all my clients). Link to patch provided. It's a real easy patch and I haven't seen any side effects since 2013 (and we have bank statements in multiple currencies with varying currency rates). https://bitbucket.org/dantam/idempiere.se/commits/211933d3f9dc676b527c00084d726b7bed8ce005 IMHO the hole from | 17:43 |
| Not-c9fd | IDEMPIERE-480 must be covered in some other way than crippling the system. The patch I'm suggesting is merely to change back to how it originally worked. Thanks :-) | 17:43 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 17:43 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 status set to "Reopened" -assignee set to "Daniel Tamm" -resolution set to "None" | 17:45 |
| Not-c9fd | [IDEMPIERE] Sorry if re-opening isn't the correct way to raise the issue. If it's not, let me know the best practise for this. | 17:45 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 17:45 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 priority set to "Major" -Version set to "None" | 17:46 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 17:46 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 labels set to "+Patch" | 17:46 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 17:46 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 labels set to "+Patch" | 17:47 |
| Not-c9fd | [IDEMPIERE] Suggested patch https://bitbucket.org/dantam/idempiere.se/commits/211933d3f9dc676b527c00084d726b7bed8ce005 | 17:47 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 17:47 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 status set to "Peer Review Queue" | 17:47 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 17:47 |
| Not-c9fd | [IDEMPIERE] deepak updated IDEMPIERE-2851 assignee set to "Deepak Pansheriya" | 18:00 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2851 | 18:00 |
| Not-c9fd | [IDEMPIERE] deepak updated IDEMPIERE-2840 assignee set to "Deepak Pansheriya" | 18:14 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2840 | 18:14 |
| Not-c9fd | [IDEMPIERE] deepak updated IDEMPIERE-2840 description set to "Reference: http://wiki.idempiere.org/en/IDempiere_workshop_2015/transcript#tokens_for_login_into_webservices Adding transcript text Here for easy reference "Deepak added a token to authorize to the webservices. You login once, get back a token and this token allows to keep the session open in iDempiere and not authorize with every request. We create a new | 18:21 |
| Not-c9fd | table to keep the tokens. It would be good if we can keep the whole session of the webservices request for the following requests. Deepak did not yet finish his work. (JIRA) When a client logs in to the webservice it can use both ways of authentication: Give all credentials or use the token. You can even give both to automatically login again if the token expired" Here is my full proposal. In Login section of | 18:21 |
| Not-c9fd | request, We should make all field other then username as optional. Add one more optional field as token. When first time webservice request made, it should contain all login information except token. Response of such login will have Token. Client can send next call with just userName and token. This token will be expired in configurable time. " | 18:21 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2840 | 18:21 |
| Not-c9fd | [IDEMPIERE] deepak updated IDEMPIERE-2826 assignee set to "Deepak Pansheriya" | 18:25 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2826 | 18:25 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-1104 | 19:01 |
| Not-c9fd | [IDEMPIERE] Thanks [~dantam], I understand your point but I think is not good to open a potential data corruption hole by default on the system. I suggest that we create a couple of things to overcome this situation: 1 - The line you're pointing can be controlled using a client SysConfig validator, something like "BANK_STATEMENT_LINE_DATEACCT_SAME_AS_HEADER" and defaults to true, protecting the system from | 19:01 |
| Not-c9fd | IDEMPIERE-480. That way at least the system is protected by default and is up to the implementor to change this SysConfig to open the issue, i.e. based on recommended practices for users or whatever mechanism they figure to avoid the data corrruption. 2 - I would suggest also to create a MBankStatementLine.beforeSave validation - if you agree with me that creating a line with a date out of the period from the header | 19:01 |
| Not-c9fd | dateacct is wrong. WDYT? Regards, Carlos Ruiz | 19:01 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 19:01 |
| *** mbozem has joined #idempiere | 19:36 | |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2859 | 20:12 |
| Not-c9fd | [IDEMPIERE] Thanks [~red1], what concerns me about this patch is in the case you want to really compare two Strings, in the case both Strings contain valid numeric values the process will always assume they are numerically comparable. I mean, for example comparing M_Product.Value 1015 with another product with value 1015.0 - with this patch the comparison will be true - but Value is a String and it must be false. | 20:12 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2859 | 20:12 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2863 status set to "Resolved" -Fix Version set to "3.0" -resolution set to "Fixed" | 20:17 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2863 | 20:17 |
| Not-c9fd | [iDempiere] CarlosRuiz_globalqss pushed 1 commit to development [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ | 20:17 |
| Not-c9fd | [iDempiere] dantam 3c13669 - IDEMPIERE-2863 - NPE in ReportStarter using Swing/JasperReports | 20:17 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2809 | 20:21 |
| Not-c9fd | [IDEMPIERE] [~deepak], to take into account, this is messaging I had with [~hengsin] relevant to this ticket: Carlos: {quote} I also think that can be improved using the AD_ToolbarButton {quote} Heng Sin: {quote} I think it should be a combination of Dictionary and OSGi factory. 1. We need a way to define the primary and secondary toolbar button in the dictionary. Secondary toolbar button should be place in a | 20:21 |
| Not-c9fd | dropdown menu ( similar to the three vertical dot overflow button in android toolbar ). This can be a configurable user preference but that shouldn't be of priority for the first version. 2. I think instead of toolbar factory, what we need is a toolbar renderer factory that provide toolbar renderer that can work on common toolbar metadata. Each toolbar renderer can have additional toolbar metadata in the AD to have | 20:21 |
| Not-c9fd | further customize look ( for e.g, beside primary and secondary button, the renderer can have another table/field to define the "primary action button" ). {quote} | 20:21 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2809 | 20:21 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2804 status set to "Resolved" -assignee set to "Nicolas Micoud" -resolution set to "Fixed" | 20:24 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2804 | 20:24 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2804 Fix Version set to "3.0" | 20:24 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2804 | 20:24 |
| Not-c9fd | [iDempiere] CarlosRuiz_globalqss pushed 1 commit to development [+0/-0/±1] https://bitbucket.org/idempiere/idempiere/commits/ | 20:25 |
| Not-c9fd | [iDempiere] nmicoud f91bf37 - IDEMPIERE-2804 Copy role process : using same roles in param | 20:25 |
| Not-c9fd | [iDempiere] jenkins built #1737 completed (success) http://ci.idempiere.org/job/iDempiere/1737/ | 20:27 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2753 Fix Version set to "3.0" | 20:32 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2753 | 20:32 |
| Not-c9fd | [iDempiere] CarlosRuiz_globalqss pushed 1 commit to development [+0/-0/±2] https://bitbucket.org/idempiere/idempiere/commits/ | 20:32 |
| Not-c9fd | [iDempiere] tsvikruha 483e8d9 - IDEMPIERE-2753 Discount is not calculated when Price List Price <1 | 20:32 |
| Not-c9fd | [IDEMPIERE] carlosruiz_globalqss updated IDEMPIERE-2753 status set to "Resolved" -assignee set to "Tomas Svikruha" -resolution set to "Fixed" | 20:32 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-2753 | 20:32 |
| Not-c9fd | [iDempiere] jenkins built #1738 completed (success) http://ci.idempiere.org/job/iDempiere/1738/ | 20:35 |
| *** mbozem has quit IRC | 20:42 | |
| Not-c9fd | [iDempiere] jenkins built #1739 completed (success) http://ci.idempiere.org/job/iDempiere/1739/ | 20:43 |
| Not-c9fd | [IDEMPIERE] dantam updated IDEMPIERE-1104 | 20:57 |
| Not-c9fd | [IDEMPIERE] Points 1 and 2 are working solutions I think. Even better would be to solve the original problem in IDEMPIERE-480 to make a pre-check that no Bank Statements are on both sides of the accounting reset dates before running the FactAcctReset. However, I'm sorry to say that I lack the time to fix the FactReset problem that well at the moment :-( Your suggestion is good since it doesn't need a lot of work. The | 20:57 |
| Not-c9fd | FactAcctReset process is not GAAP and actually illegal since it rewrites the entire general ledger and can be questioned by auditors / tax agencies. I understand why it's there and it's handy, but it's in the same category of functionality as the cheat button on a cash register, not by the book ;-) Perhaps it should be put in the "Advanced"/"Admin" category of processes since normal accountants shouldn't use the | 20:57 |
| Not-c9fd | process? Restricting access to FactAcctReset could also be a way to solve this. Keeping the periods intact makes sense and if the period control only checks the document date of the bank statement (not the lines) I think point 2 is a necessary validation (not to span periods). Thanks for looking at this again :-) | 20:57 |
| Not-c9fd | [IDEMPIERE] http://idempiere.atlassian.net/browse/IDEMPIERE-1104 | 20:57 |
| *** a42niem has quit IRC | 21:25 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!