Hi,

I've run into what seems to be a semantic issue.

In real life, bank statements are nothing more than lists of bank transactions and have no immediate relation with accounting periods. It is even quite common to have statements listing transactions that span multiple accounting periods.

In OpenERP, a bank statement is bound to an accounting period. That is very confusing, to say the least, as it makes it impossible to encode real life statements that span multiple periods. It also hampers traceability of bank statements, as accounting-period-spanning statements have to be split into multiple OpenERP bank statements to avoid other problems down the line, which influences numbering and tagging.

Now what is a bank statement in OpenERP?

Is it a bank transaction? If so, then account_bank_statement_line seems superfluous, as it creates a 1:1 coupling between the two.

Or is it really meant to be a list of bank transactions? In that case, the addition of a required account_period seems like a design error, creating all sorts of bugs downstream.

Can someone clarify this for me?

Thx in advance,

IMHO OpenERP assumes that all data entries are "real time" and uses/proposes now() as ".... date" and derives the period from this date

I am working to "open" the date field for data entry for users having a special role "manual date entry"
you can find this (and other enhancements) in
https://code.launchpad.net/~openerp-com ... price_unit

Hi ferdinand,

I followed your pointer, thanks for that, I'll study it further. The bank statement there is however still the same as the original - it is required to have an association with an accounting period.

It is the association of a bank statement with an accounting period itself which I question. IMHO this is a design mistake with no reflection in real life. Transactions can be associated with accounting periods, but lists of transactions IMHO never, unless a bank statement the OpenERP way means something completely different than what I know from real life. Hence my question.

I agree with you. For me, it must create a account move for each statement lines with right period depending of the date.

@pjkersten


Don't bank statements usually refer to one period?
I am used to have monthly statements (well some banks issue a two month statement), so every line belong to the same period. In case there's one bank statement covering more than one period, you can split it accordingly.

@paulino:

No. Banks often spread their mailings over a months period to ease their logistics. The transactions listed on the statement are the known ones up to the mailing date, which may or may not be at the end of an accounting period. Most banks let you choose the frequency of the mailings, which can also be based on a number of transactions, but it is up to the bank to decide when they send you the statements.

So, I often receive statements with a transactions list that crosses a months border.

If you split bank statements as I do, then you acknowledge my observation that an OpenERP bank statement is not the same as 'the real thing'.

@ced:

Thanks for your pointer. It seems that tryton got it right. Nice to see that invoice matching is done automatically as well. Pity that tryton has drifted so far away from OpenERP that back porting has become a challenge.

@paulino:

In Belgium, the only constraint about statement for bank is to send at least one per year.

I totally agree with you, a bank statement has an opening and closing date and associated balances. Dates can span financial periods. It is always a pain to reconcile the closing balance in the bank's GL account for a period with a statement, but it is essential to at least reconcile the transactions on the statement with recorded transactions (regardless of financial period).

From my understanding, this section has absolutely nothing to do with bank statements, ie. statements from banks.

However, I have absolutely no idea what it *IS* for. There's no UK accounting software that I'm aware of that has any feature like this. I don't use this feature for anything, I can't find a use for it.

MattLG

Our new banking framework removes the accounting period from bank statements and moves them to bank statement lines aka bank transactions.

You can find the modules both on http://www.edusense.nl as in addons-community.

I thought you guys might want to know.

Hello!
Looks very promising. Please add BeautifulSoup to python modules dependency list, otherwise it's not installable.


normunds

Thank you.

I tried to add BeautifulSoup to the list of dependencies, but then the test suite bails out for not being able to import the module.

Instead, I've moved the import inside the Dutch on-line check, to allow the test suit to pass and to limit this problem to the Dutch community (where it originated). I also placed a warning in the module description.

Thanks for your interest.

There are actually several types of bank statements that must be contended with.

As pj and the rest of the forum participants indicated some companies receive bank statements that drop/close during a month and don't coincide with an accounting period. These can be more difficult to reconcile with the system as they span accounting periods, and in order to close the accounting period properly one needs to pull down addition transactions through the end of a period.

Another type of bank statement (which is typically found within larger companies) coincides with monthly billing and runs to the end of the month. In the US we call this Account Analysis and there are specialized systems to do this - and larger companies like SAP also have specialized modules to manage this. This bundles up all transactions and eases reconciliation. Here is a link to the announcement from Barclays when they implemented a new XML standard to handle these [url]"http://www.twiststandards.org/index.php?option=com_content&view=article&id=72:barclays-is-first-uk-bank-to-introduce-twist-bsb-standard-to-its-customers&catid=1:News&Itemid=95[/url]" This approach is typically found in commercial accounts.

In the system we obviously must:

1) handle reconciliation of paper bank statements in an easy manner that handles end of the month statement dates as well as statements that close within the month or time period.

2) Handle electronic reconciliation of statements at the end of the month and cross-month statements. (the issue is these formats vary globally).

Banking statements can vary tremendously across different countries and even within countries themselves.

The system needs to handle bank statements from different banks that may close on different dates.

The effort with twiststandards.org is to try to enable the global bank community to communicate electronically to customers and have a way for them to quickly reconcile their accounts by using an agreed set of transaction codes and an agreed way (XML format) to present the information. Work towards this are only recent developments.

Today you end up with a set of codes identifying the various types of individual transactions from each bank. There is no set standard set of international codes (yet) - and may never will be. When statements or files are received, the bank transactions should go through a match process in an OpenERP module to the transactions within an accounting system(ERP) system. Then exceptions should be identified and handled accordingly by accounting. This is what keeps larger treasury groups up at night.

The BSB XML standard is something I worked on extensively as a co-author in a former life. Accomplishing what has been done to date has taken 5 years or so - so its a slow turning ship.

Just some food for thought . . .

The account_banking module aka Account Banking Framework is trying to cope with exactly these issues. We have made quite some progress since the start. If you are an XML expert, I invite you to join in and add BSB. I think it will be a valuable addition.

BTW, how does BSB map to ISO20022? Are these the CAMT.05[345].001.02 standards?

Looking forward to it.

I like the direction your module is going and capabilities, great job . . . this is important for all users globally.

I'll reach out to some of my former colleagues to get an updated status . . .and post it here.

This is what is on the website now

TWIST has for some years proudly hosted the Global Electronic Bank Services Billing Standard (BSB). BSB is a standard intended for use by banks and their wholesale transaction services users. BSB facilitates a monthly electronic communication of banking fees to their corporate customers and others incurring those fees.

It is TWIST's intention to submit this standard with ISO 20022 in the near future. BSB registration with ISO 20022 will give users of both standards the assurance of a complete, coordinated, globally relevant set of standards. Recent developments related to ISO 20022 make the incorporation of BSB under the ISO 20022 banner a possibility. ISO 20022 now allows for interoperability between standards, which means the ability to selectively incorporate standards in the ISO 20022 portfolio without radical change to the native syntax of these standards. As a result this will allow incorporation of the TWIST BSB standard into ISO 20022 without adverse impact to the existing users of TWIST BSB.

In the coming months the management of TWIST will make preparations for submission of the BSB standards to ISO 20022. These preparations will be made together with the co-ordinator of the BSB Working Group and TWIST's Architecture Committee. Existing users of the BSB standard, such as GE and a number of banks, will be involved in the process.