Re: Thoughts about data migration when master-mc lands on master

["R. Ransbottom" <..hidden..>]

On Mon, Dec 14, 2015 at 03:35:09PM +0100, Erik Huelsmann wrote:
> On Sat, Dec 12, 2015 at 4:41 PM, R. Ransbottom <..hidden..> wrote:
> > On Sun, Dec 06, 2015 at 05:37:18PM +0100, Erik Huelsmann wrote:
> > > On Thu, Dec 3, 2015 at 9:53 PM, R. Ransbottom <..hidden..>
> > wrote:
> > > > On Sun, Nov 29, 2015 at 03:44:15PM +0100, Erik Huelsmann wrote:

> Ah. Right. My plan isn't about the rate being applied. So, I think that
> should ease your mind. I think the new schema actually helps address the
> above worry by allowing a rate per transaction(line) instead of a rate per
> day: the rate per day could be a problem because you could have 2 bank
> accounts with different banks, which use a different rate on the same day
> (the current schema doesn't support that; the new schema does).

I was going to ask, "Are daily rates still the norm?" but did not want 
to digress (again).  

>From a bookkeeping perspective, the one rate per day suffices 
whether you have multiple banks doing conversions or not.  
I'd prioritize this feature per user demand.

If you are going to offer more rate flexibility:  Clearly, a rate per
invoice document is enough.

> Ok. I think that using the term "functional currency" is ok, but I've used
> the shorthand "bc" for base currency in the code, because "fc" looks too

Oh, I don't have any problem with that; but knowing the terminology of
the problem domain is good.  

> I'm trying to move away from acc_trans and describing what's currently in
> acc_trans that I have to work with if I want to move to something very much

Then what you have is not so important.  What is more important is how
far do you want to leave it behind.

> > That payments are applied to line items is a complete waste of
> > time.  

I state that again more emphatically!

> >        It seems the fundamental problem is that FX should be
> > handled in another document.

>                                   My position is that an accounting
> document  is a grouping of all the accounting effects of one real-world
> transaction. 

This is correct but ...

>              This means that all fx effects of a single payment should be
> accounted for in the same document as where the actual payment is recorded.

 ... this is not; you are drawing the boundaries of the transaction 
incorrectly.  

You have a receivable of 40.00USD for which you've agreed to accept 
30.00EUR.  That and your reference to some rate quote need to be in 
your invoice header.  The line items only need EUR amounts for 
presentation to the customer.  When you receive the 30.00EUR you mark 
the invoice paid for 40.00USD.  Then you have two possibilities.  
(1) You have Euros in your cash drawer or a Euro denominated bank 
account.  (2) Your agent has automagically converted the money for 
you.

> If things don't work that way, it'll be very hard to determine which fx
> consequences belong to which payment transactions.

So you have a consequent transaction done or pending to convert the
foreign funds with another entity.  What you sold and to whom is no
longer important, it is done.  If getting 35.00USD for your 30.00EUR
is a problem, it is separate problem.  

So things don't work that way.  And looking at individual invoice line
to judge your FX is erroneous.  That 30.00EUR may sit in the cash
register for weeks; it may make change for in another sale; or perhaps 
part of it bought some Belgium chocolate.  Why or when is it different
than a sister invoice issued the same day?

Being in business, I do understand the appeal of looking at some
deal and computing a profit/loss that tries to include all aspects.  
I do it.  It is fun or miserable, but it often requires more than one
transaction being viewed. It may include some hand-wavy judgements of
allocating labor, overhead, mileage, transaction fees and opportunity
costs.  After a bit of thought and practice you should come up with 
at least three different answers each time.

> > For accounting, the FX rate, currency, and amount need only be in
> > the journal entry header.  The journal lines don't need any info
> > about FX.

> I'm not sure I agree with you here. In general I do, but in particular, I
> wonder about revaluation transactions (revaluation of financial assets /
> liabilities): they require a zero-amount foreign currency but a non-zero
> amount base currency, because the amount being posted is a consequence of
> the exchange rate changing.

I am not sure I'm following you here.  I think you are saying that you
adjust the invoice base amount to reflect the change in FX value.
But it is only necessary to track this at a GL account level.

You have FX receivables of     1000.00EUR valued at 1500.00USD base.
On credit, you sell            +100.00EUR at        +130.00USD.

Your FX is now                 1100.00EUR and       1630.00USD.
Revalution time (1EUR/1.4USD)   book the loss        -90.00USD.
Your FX is                     1100.00EUR           1540.00USD.

Payment time is yet to come.  You may be remeasuring again and again.

> Additionally, if you consider - like me - that the foreign currency
> gains/losses should be posted as part of the payment transaction, multiple
> rates will need to be used in a single transaction: the rate of the payment
> date and the rate of the date of the sales invoice.

This is misconceived--my "consequent tranaction" comment above.  
But if you are making this work, how do you handle intermediate FX 
revaluations.  I mean that, monthly, quarterly or yearly, at some
closing date, the FX gain/loss needs to be restated.  Like other 
income/expense accounts it is recognized within a period.

> >   Sales and purchasing need line item FX amounts just
> > for presentation to the customer or vendor.  Journal lines should
> > be immutable.

> Agreed and they are: Even currently with the two-line-per-line schema, the
> data in the schema is immutable. It's the migration that is posing me
> problems, not the schema itself.
> (I'm not sure what you mean by "fx amounts just for presentation" in the
> sense that the fx amounts are an integral part of the accounting, as far as
> I'm concerned - and I would imagine every auditor too)

FX handling is quickly separated in accounting because it keeps the 
story, the account, clearer.

At the line item level, the FX amount is only necessary for the other 
party's information.  If there is a return, damage or shortage an 
offsetting document may be issued, which may or may not be the same
FX amount as the initial line item effected.  The line item FX amount 
may be necessary to track the deal but not for the books or decision
support.

I meant that when you sell or buy:

    doc_id:  i0001      qty: 2     item: pencil   extension: 2.00 
    fx: eur             fx_extension: 1.50

nothing in that should ever need to be changed.


> > log all transactions?

> There's a table to which audit information is written. Please have a look

No, not that ...

> There's the option to configure postgresql to use WAL archiving. When you

 ... but that.  Thanks.

> Ah! I should think to what extent the problems that we're looking at are

What is the codebase, 15 years old?

> much appreciate it if you were going to read and discuss like in this
> thread!

Yes, consider me volunteered.


Rob

------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel