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).