- Nov 30, 2018
-
-
- Nov 10, 2018
-
-
The account table is present when no account is present, we need to add condition to avoid research account in this case. Closes: 27858@sibi
-
The market accounts were not scraped yet, the BNP website seems to have changed recently. This patch enables scraping of the market accounts. The iter_investments method already worked as such, however the pagination is not yet handled. When there is only one account on the "invests" page, the checking and the market account are fused into one account, the market balance is not scraped, nor are the investments. This patch enables both accounts to be visible with their respective balances and the investments related to the market account. Closes: 6827@zendesk
-
- Aug 18, 2018
-
-
- import unicode_literals in each Python module - import weboob's basestring compat - xrange -> range - tested on 90 connections, 1 for each API
-
- Jul 29, 2018
-
-
A recurring problem with bnporc is that sometimes you may not have the good transactions list. It may be truncated a lot. For example, from 50 transactions, you had only 5. Because of that, in the backend some transactions become deleted because of one update with the bad transactions. I tried to fix it by copying the website, since you never had bad transactions on it. First, I changed the 'typeReleve' from 'Comptable' to 'Previsionnel' because it is the only type the website is using. And I added some parameters to the history request. The same ones are used to go on the transaction page and to get the json data. I tested a lot on connections, knowing the right and the wrong history state. Since I applied the patch, I had not once the wrong state. Closes: 5663@zendesk Closes: 6219@zendesk Closes: 6225@zendesk Closes: 6229@zendesk Closes: 6115@zendesk
-
In some case, you may have only one market type account. If so, the website does not show a page with the list of one account but directly the details of this account. Most of the time, getting the number in the account label is enough to recognize it in the iter_accounts. But sometime you have custom account label, so it is not enough. That is why the entire account name is retrieved. Closes: 13125@sibi Closes: 12518@sibi Closes: 13576@sibi Closes: 12610@sibi Closes: 12871@sibi Closes: 11832@sibi Closes: 11912@sibi Closes: 11913@sibi Closes: 11867@sibi Closes: 11750@sibi Closes: 11749@sibi Closes: 11580@sibi Closes: 11715@sibi Closes: 11714@sibi
-
My precedent MR had an error when an account doesn't have number in the label. The fix allows the account to have number. closes: 750661@redmine
-
Closes: 4907@zendesk
-
Add a connection to the "Placements" page, and scrapping on the HTML pages. For this it was necessary to take a token and a specific account ID to reach the invest page. closes: 5078@zendesk
-
Problem 1: The rdate found in the raw can be truncated. So it is ignored. Problem 2: The date field can be empty. So the coming is ignored. Closes: 870@sibi Closes: 4470@sibi Closes: 6436@sibi Closes: 7235@sibi
-
- Apr 15, 2018
-
-
- Mar 31, 2018
-
-
On history page, load coming card details allow to get card number to sort coming and history transactions Closes: 4544@zendesk
-
-
- Mar 03, 2018
-
-
In transactions main JSON page, there are 'transactions' and 'coming'. It's not necessary to go on coming transactions details page from transactions JSON to get card number because there is a special page for coming transactions with card number. Closes: 558478@redmine
-
Decimal number key for amount can be 'nbDec' or 'nb_dec' Closes: 556862@redmine
-
- Feb 04, 2018
-
-
Some not card transaction might have "FACTURE CARTE" in raw Closes: 490732@redmine
-
- Jan 14, 2018
-
-
The card number is not present in a card summary transaction json Closes : 490732@redmine
-
- Dec 30, 2017
-
-
-
We should not create Account objects for cards, and the history of these cards must be returned on checking account. We can do some guessing by looking at the history of an account and looking if the transactions have spread debit dates or only once per month.
-
On the site, the card coming is on card page, but card history is on checking page. Before, the history on cards was not returned, but it's possible to find on which card is a history transaction, so we now yield such transactions on the related card account instead of checking account. However, if the site doesn't show the card if there are no coming transactions, so in this case the history will not be returned because the card Account object cannot be created.
-
- Dec 16, 2017
-
-
- Dec 03, 2017
-
-
Don't ignore anymore "FACTURE CARTE DU" transactions. Some of them are card_summary if coming from a deferred debit card. Some others are immediate debits. Account._has_cards is not enough, the site may show "Encours carte" link while there are no deferred debit cards.
-
- Nov 18, 2017
-
-
- Oct 08, 2017
-
-
At the end of the month, the list of cards is duplicated, because the coming amount may exist for the current month and the next. We need to merge the list of cards in this situation, we try to only keep cards with a coming amount in case of a duplicate.
-
-
The old pattern was - find a (\d{6}) pattern in the libelle of the transaction. - fallback to the 'creationDate' parameter in the JSON dictionary. The step 1 was almost never performed because dates in the libelle are 8 digits wide. The new algorithm is : - find a (\d{8}) pattern in the libelle of the transaction (it occurs much more frequently). - if no pattern is found, fallback to the 'creationDate' parameter. Because of this, there is probably a large number of transaction which are going to have their rdate field updated.
-
-
-
- Jul 22, 2017
-
-
- Jul 08, 2017
-
-
those are now on the card account
-
- Jun 24, 2017
-
-
- Jun 17, 2017
-
-
- May 20, 2017
-
-
- Apr 29, 2017
-
-
- Apr 27, 2017
-
-
- Apr 01, 2017
-
-
When coming transactions become past transactions, they get merged in the general history and the site gives no info whether they were deferred or not. To avoid passing from deferred_card to card, always report as card.
-