Created on 2014-02-20.10:22:00 by rhertzog, last changed 25 months ago by ced.
Le vendredi 21 février 2014, Cédric Krier a écrit : > On 21 Feb 07:57, Raphaël Hertzog wrote: > > Another data point, assuming issue3695 gets implemented, it would be even more > > important to be able to import existing moves since almost all recurring moves > > that I have tend to affect a bank account. > > That's wrong. You will always have 2 moves to do, one for the invoice > and one for the payment. That's correct but in the above issue I explain that both could be automated... in other words I don't see the contradiction between what you said and what I said. Maybe the "all" was not factual, it's "only" 50% given the invoice doesn't affect the bank account, but then it's still true that with such a scheme we would have a tool that creates moves outside of the account_statement module and it would be nice if both modules/features could be usable together. Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/
On 21 Feb 07:57, Raphaël Hertzog wrote: > Another data point, assuming issue3695 gets implemented, it would be even more > important to be able to import existing moves since almost all recurring moves > that I have tend to affect a bank account. That's wrong. You will always have 2 moves to do, one for the invoice and one for the payment.
Another data point, assuming issue3695 gets implemented, it would be even more important to be able to import existing moves since almost all recurring moves that I have tend to affect a bank account.
Hi, Le jeudi 20 février 2014, Cédric Krier a écrit : > > The case where it's clearly impossible is when you have a move between two > > accounts which are both managed by account_statement. I can't create the same > > move from both sides, yet the move clearly appears on both statements and it > > needs to be taken into account if I want my end balance to match. > > Such case must be managed by using a temporary transitional account. Good point, and the french chart of account even has the required account for this (58 - Virements internes). It's even better since it allows to have different dates for the two moves (a wire transfer between two acccounts in different banks is not instantaneous). > > The cases that are not always realistic is that not everybody gets bank > > statement as often as they'd like to update their accounting. > > But how can you write accounting without having the proper documents? I can print receipts for incoming/outgoing wire transfers and I know that they will also appear in the monthly bank statement. And even without proper supporting statement, creating a draft move that I post only when I have the proper statement should be OK. Maybe that's the part missing in account_statement, the possibility to create moves as draft while the statement itself is still in draft status. > Anyway, you can still managed this case by using a temporary > transitional account. It's always possible but in this case, it's not very clean. I want the balance of the bank account to evolve so that I can ensure it will stay in the positive side. > > Thus I would suggest to improve the account_statement module to be able to > > import existing (posted) moves provided they are not part of another statement > > on the account. But it should be possible to import a move that is part of a > > statement that affects another account (provided that the move also affects the > > account for which the current statement is about). > > I don't like the idea because there will be no way (or too difficult) to > be sure that the attached move is equivalent to the one that would be > generated. What kind of difference do you expect? Maybe we can restrict the feature to a subset of moves? Cheers, -- Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/
On 20 Feb 18:00, Jordi Esteve wrote: > Yes, with account_statement you can do all the things you want by splitting bank > statement lines manually. But you lose the real bank statement information, it > is difficult to see how a bank statement line has been split to several account > moves. They have the same reference. > And it is impossible to process/confirm the bank statement lines > individually. You can if you create a statement per line (but I don't see the point of such behavior). More over confirming a line when the statement is not valid is pointless and even dangerous.
Yes, with account_statement you can do all the things you want by splitting bank statement lines manually. But you lose the real bank statement information, it is difficult to see how a bank statement line has been split to several account moves. And it is impossible to process/confirm the bank statement lines individually.
[1] doesn't see the point. You can make statement of one line if you want. [2] don't see why you are talking about payment when it is about statement. [3] you can do the same with the statement by splitting the line (like it is done for extra amount of invoice)
I agree that account_statement module gives you a very simple treatment of bank statements. You can test the modules [1] [2] [3] that add more flexibility in the treatment of bank statements. [1] allows to deal and confirm individual bank statement lines and to relate existing account moves to one bank statement line. [2] allows to relate several payable/receivable account moves to one bank statement line in order to create the payment moves and reconcile them. [3] allows to relate several account/amounts to one bank statement line in order to create several moves at the same time (account_statement only allows one). I think it is not worth to include such extra functionality in the basic account_statement module. Some company/users prefer a basic functionality and other prefers a more extended one. [1] https://bitbucket.org/trytonspain/trytond-account_bank_statement [2] https://bitbucket.org/trytonspain/trytond-account_bank_statement_counterpart [3] https://bitbucket.org/trytonspain/trytond-account_bank_statement_account
On 20 Feb 10:22, Raphaël Hertzog wrote: > While trying to use the account_statement module, I am often annoyed by the > impossibility to integrate existing moves. I understand that in the perfect > situation you can have a new statement whenever you want and you should create > all the moves from the account_statement module but that's not realistic in many > cases and clearly impossible in some other cases. > > The case where it's clearly impossible is when you have a move between two > accounts which are both managed by account_statement. I can't create the same > move from both sides, yet the move clearly appears on both statements and it > needs to be taken into account if I want my end balance to match. Such case must be managed by using a temporary transitional account. > The cases that are not always realistic is that not everybody gets bank > statement as often as they'd like to update their accounting. I for one get > monthly bank statement and there are times where I want to do my accounting > before I get the final bank statement. (Please don't blame my bank or my choice > of bank, ERP are meant to be adaptable to all use cases and I prefer to discuss > how we can improve Tryton to match my needs than discuss the merits of my bank) But how can you write accounting without having the proper documents? Anyway, you can still managed this case by using a temporary transitional account. > Thus I would suggest to improve the account_statement module to be able to > import existing (posted) moves provided they are not part of another statement > on the account. But it should be possible to import a move that is part of a > statement that affects another account (provided that the move also affects the > account for which the current statement is about). I don't like the idea because there will be no way (or too difficult) to be sure that the attached move is equivalent to the one that would be generated.
While trying to use the account_statement module, I am often annoyed by the impossibility to integrate existing moves. I understand that in the perfect situation you can have a new statement whenever you want and you should create all the moves from the account_statement module but that's not realistic in many cases and clearly impossible in some other cases. The case where it's clearly impossible is when you have a move between two accounts which are both managed by account_statement. I can't create the same move from both sides, yet the move clearly appears on both statements and it needs to be taken into account if I want my end balance to match. The cases that are not always realistic is that not everybody gets bank statement as often as they'd like to update their accounting. I for one get monthly bank statement and there are times where I want to do my accounting before I get the final bank statement. (Please don't blame my bank or my choice of bank, ERP are meant to be adaptable to all use cases and I prefer to discuss how we can improve Tryton to match my needs than discuss the merits of my bank) Thus I would suggest to improve the account_statement module to be able to import existing (posted) moves provided they are not part of another statement on the account. But it should be possible to import a move that is part of a statement that affects another account (provided that the move also affects the account for which the current statement is about).
History | |||
---|---|---|---|
Date | User | Action | Args |
2020-06-13 09:21:41 | ced | set | priority: feature -> wish |
2014-02-21 10:34:51 | rhertzog | set | messages: + msg15712 |
2014-02-21 10:20:16 | ced | set | messages: + msg15711 |
2014-02-21 07:57:39 | rhertzog | set | messages: + msg15709 |
2014-02-20 20:59:03 | rhertzog | set | messages: + msg15699 |
2014-02-20 18:07:32 | ced | set | messages: + msg15696 |
2014-02-20 18:00:49 | jesteve | set | messages: + msg15695 |
2014-02-20 17:21:17 | ced | set | messages: + msg15694 |
2014-02-20 17:02:45 | jesteve | set | nosy:
+ jesteve messages: + msg15693 |
2014-02-20 12:32:38 | yangoon | set | nosy: + yangoon |
Showing 10 items. Show all history (warning: this could be VERY long)