[09:51:32] Martin Taal: the idea is to implement a quick/good solution for solving that we sometimes miss tickets in reconciliations
[09:51:57] Martin Taal: basically the solution is to check if there are orders which have a cashup id which is 'old' not being used anymore
[09:52:08] Martin Taal: so when the client creates a new cashup id for a certain terminal
[09:52:18] Martin Taal: the orders with the 'old' cashup also need to get this new cashup id
[09:52:24] Martin Taal: I think this is not difficult to do
[09:52:28] Martin Taal: and saves a lot of headaches
[09:52:29] Martin Taal: but:
[09:52:59] Martin Taal: - is this indeed all that needs to be done?
- what is a good point to 'repair' the wrong cashup id: when a new cashup id is created in the client or when we do the cashup?
[09:53:22] Antonio Moreno: yes, I discussed this idea with Dmitry also a while ago
[09:53:41] Antonio Moreno: i think that should be more or less all it needs to be done
[09:54:16] Martin Taal: my idea is to include this in q2.4/q3.1
[09:54:20] Antonio Moreno: in my view, in this case the good point would be when we do the cash up, because it makes the change much simpler, which is part of the goal of this workaround
[09:54:24] Martin Taal: or alternatively create a patch and install at cds/halsted and grape
[09:54:30] Martin Taal: yes but
[09:54:37] Martin Taal: doesn't the cashup read payment info
[09:54:44] Martin Taal: to show the right cashup info in the client
[09:54:49] Martin Taal: when doing the cashup?
[09:56:19] Antonio Moreno: that information is read from the local database always
[09:56:26] Antonio Moreno: if you don’t delete the cache, that information is correct
[09:56:40] Antonio Moreno: if you delete the cache, then this information is rebuilt by reading the current balance of the financial accounts
[09:56:43] Antonio Moreno: which is also correct
[09:56:47] Antonio Moreno: so there shouldn’t be any problem there
[09:56:50] Martin Taal: okay
[09:57:06] Martin Taal: so the balance of the financial account does not have this old cashup id?
[09:57:54] Antonio Moreno: the balance of the financial account is correctly updated always unless you have lost tickets (which should never happen), so we always have a way to find out how much money you should find for each payment method
[09:58:10] Martin Taal: okay
[09:58:18] Martin Taal: indeed easier to do this at cashup time
[09:58:24] Antonio Moreno: yes, definitely
[09:59:58] Martin Taal: for the Q1 release we will have Salvas work
[10:00:07] Martin Taal: but a strange question
[10:00:17] Martin Taal: what does Salvas work add/do differently than this solution?
[10:00:39] Martin Taal: what benefit does Salvas work has compared to doing it like this?
[10:01:06] Antonio Moreno: hmm, that’s a good question :)
[10:01:37] Martin Taal: Salva stores totals by payment method
[10:01:39] Martin Taal: and tax info
[10:01:51] Martin Taal: and since the last change also rebuilds cash transaction changes
[10:01:53] Martin Taal: I think
[10:02:06] Martin Taal: but still I don't know the details...
[10:02:19] Martin Taal: so hope you have an answer :-)
[10:03:00] Antonio Moreno: need to think about it for a while
[10:03:18] Antonio Moreno: I think you will get wrong data in the cash up report for example
[10:03:25] Antonio Moreno: the tax information and so on will be wrong probably
[10:03:37] Antonio Moreno: even though in the end the tickets are reconciled correctly, the report will be wrong
[10:03:46] Martin Taal: what is shown in the client?
[10:03:58] Martin Taal: but you say this is rebuild from the financial account right?
[10:04:13] Martin Taal: but the tickets are not yet invoiced so there is nothing in the financial accounts
[10:04:14] Antonio Moreno: we rebuild the total sales per payment method from the financial account current balance
[10:04:24] Antonio Moreno: but there are more things, which i’m not sure how we rebuild
[10:04:28] Antonio Moreno: everything is in the financial accounts
[10:04:35] Antonio Moreno: the moment you create the ticket the payment information is also created
[10:04:46] Martin Taal: ha okay
[10:04:47] Antonio Moreno: this doesn’t happen when you invoice it, this happens as soon as you register the ticket
[10:04:53] Martin Taal: but not in the ledger account
[10:04:57] Martin Taal: only in the financial account
[10:05:00] Antonio Moreno: yes
[10:05:02] Antonio Moreno: correct
[10:05:37] Martin Taal: always confused about the difference between the two
[10:07:43] Martin Taal: okay still wondering what the difference between the solution of Salva and this is
[10:08:02] Martin Taal: as you in a way say that the cashup info is being rebuild from the financial account balance
[10:08:32] Antonio Moreno: I think we probably don’t rebuild the tax information correctly at least, that part would be difficult
[10:08:48] Antonio Moreno: so probably at least the tax information will be shown incorrectly in the cash up report
[10:08:54] Martin Taal: okay
[10:09:07] Martin Taal: but even this can be recomputed from the tickets right?
[10:09:48] Martin Taal: in any case I will report an issue for the 'easy' fix
[10:09:54] Martin Taal: and then you can take it
[10:09:57] Martin Taal: when would that be?
[10:10:06] Antonio Moreno: next week at some point would be ok?
[10:10:17] Martin Taal: yes
[10:10:27] Martin Taal: I am doubting somewhat if we should include in q2.4 or not
[10:10:30] Martin Taal: or is a separate patch
[10:10:35] Martin Taal: it does not sound too risky change
[10:10:39] Martin Taal: but it is in a sensitive area
[10:10:47] Martin Taal: and it needs a selenium testcase
[10:11:11] Martin Taal: maybe one of the existing testcases done for Salva can be re-used for this
[10:11:35] Antonio Moreno: yes, i think we can implement the change, and then depending on how risky it looks we can decide whether to include it or not in q2
[10:11:54] Martin Taal: yes
[10:12:04] Martin Taal: we don't install q2.4 at CDS anyway
[10:12:06] Antonio Moreno: and then also while i implement it I will think on whether it makes sense to use it instead of Salva’s fix or not
[10:12:06] Martin Taal: we do patches there
[10:12:12] Martin Taal: yes
[10:12:17] Martin Taal: or use part of Salvas work
[10:12:23] Martin Taal: for example to store taxes
[10:12:29] Martin Taal: but always better not to store things twice
[10:12:32] Martin Taal: as we always get differences
[10:12:41] Martin Taal: so if the tax info is in the tickets
[10:12:45] Martin Taal: we should read it from thre
[10:12:52] Martin Taal: other request
[10:13:02] Martin Taal: can you update/maintain the retail team tasks in a bit more detail?
[10:13:30] Antonio Moreno: you mean my own tasks in the spreadsheet?
[10:13:33] Martin Taal: yeah
[10:13:36] Antonio Moreno: yes, definitely
[10:13:45] Antonio Moreno: sorry, I’ve forgot to update it these last days
[10:13:51] Martin Taal: it also helps yoursele
[10:13:59] Martin Taal: as it shows to you selve that you do many things :-)
[10:14:03] Antonio Moreno: hehe, yes
[10:14:21] Martin Taal: I also find it difficult to do
[10:14:34] Martin Taal: but if I don't do it I forget points which should be handled
[10:14:43] Martin Taal: it has give me much more peace of mind actually
[10:14:47] Martin Taal: that I have this todo list
[10:15:25] Antonio Moreno: yes, I completely agree
[10:15:25] Martin Taal: btw totally other option :-)
[10:15:34] Martin Taal: for the thing we discussed above
[10:15:46] Martin Taal: why do we store a cashup id in the tickets even :-)
[10:15:51] Martin Taal: before the cashup is done
[10:16:23] Martin Taal: why not keep the field null
[10:16:29] Martin Taal: until the cashclose
[10:16:41] Antonio Moreno: the main problem is that you can go offline
[10:16:43] Antonio Moreno: and then you can do three cash ups
[10:16:52] Antonio Moreno: so you need to know which ticket goes to which cash up
[10:17:01] Martin Taal: ha yes you can do cashup offline
[10:17:04] Martin Taal: okay
[10:17:07] Martin Taal: clear
[10:17:10] Martin Taal: good point
[10:17:47] Martin Taal: and then when you go online you don't know the order in which things are synchronized?
[10:17:50] Martin Taal: or is there an order?
[10:18:11] Antonio Moreno: you synchronize all tickets, then all cash mgmt movements, and then all cash ups
[10:18:19] Antonio Moreno: in the order they were created, in each case
[10:18:20] Martin Taal: okay
[10:18:21] Martin Taal: bang
[10:18:27] Martin Taal: this kills the simple solution :-)
[10:18:34] Martin Taal: you see what I mean
[10:18:34] Martin Taal: ?
[10:18:46] Antonio Moreno: you mean the one we were talking about before?
[10:18:49] Martin Taal: yes
[10:18:52] Martin Taal: say offline
[10:18:57] Martin Taal: create 3 tickets
[10:19:00] Martin Taal: do a cashup after each ticket
[10:19:02] Martin Taal: offline
[10:19:10] Martin Taal: go online
[10:19:16] Martin Taal: 3 tickets are send to the backend
[10:19:28] Martin Taal: first cashup is being synced
[10:19:36] Martin Taal: it detects that 1 ticket is linked to it
[10:19:44] Martin Taal: and that there are 2 'orhpaned' tickets
[10:19:53] Martin Taal: and the first cashup will take all 3 orders
[10:20:14] Martin Taal: you see my point?
[10:20:14] Antonio Moreno: this we can prevent
[10:20:16] Martin Taal: yes
[10:20:20] Martin Taal: I guess there is a solution
[10:20:36] Antonio Moreno: when we send the cash ups to synchronize, we send all of them
[10:20:49] Antonio Moreno: so we can take into account the ids of all of them to find the “orphaned” tickets
[10:20:54] Martin Taal: as an array
[10:21:07] Martin Taal: okay so do the orphan check before processing all three
[10:21:08] Martin Taal: okay
[10:21:11] Antonio Moreno: yes
[10:21:17] Martin Taal: I will copy paste this skype chat in the issue
[10:21:44] Antonio Moreno: hehe, good idea :)