Solution for concilliated payments

Here you can put ideas for new functionalities and improvements.

Moderators: hugo, alexandre, rmvanarkel

Post Reply
cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Solution for concilliated payments

Post by cycloshost »

Hi,

did you think about how to show not-yet-concilliated payments in the account history? We are having trouble on remembering which payments are concilliated and which not on a certain system account history listing.

It would be great to have very simple check/uncheck button in the listing that highlights a payment when is not concilliated yet and removes the highlight when it is concilliated. As this feature is not meaningful for all users, it could be activated by demand with a check depending on the account type from "Acount type details".

What do you think?
cycloshost.com
Cyclos administration and hosting
admin
Site Admin
Posts: 1424
Joined: Mon Jan 24, 2005 10:31 am

Re: Solution for concilliated payments

Post by admin »

Hi,

We have planned this for the coming version much like you describe it.
A system account type can be checked to conciliate payments. Such an account will have a check (boolean) in the transaction search filter.
For the moment the payment can only be checked conciliated in the payment details. In the future we might provide multi select on the payment list. The Web services will already allow multiple conciliation (passing transaction ID's).

The next version will also have imports features. The transaction imports will be divided in two. On in system, mostly used for migrations, and one in banking, with a more operational approach. The transaction import in banking will allow importing transactions that generate fees (e.g. bonuses). The main use of this is to manage the buying of units (e.g. by bank deposits). It will typically generate transactions from a system (negative only) account to user accounts. When importing transactions you can check 'mark imported payments as conciliated'. The import mappings can be saved so that admins do not need to define the mapping on each import.

The import transactions and conciliation functions will offer a similar feature as the bookkeeping module in Cyclos3. It is not that 'fully fledged' as it was in Cyclos3 but certainly easier to manage.
cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Re: Solution for concilliated payments

Post by cycloshost »

For the moment the payment can only be checked conciliated in the payment details.
OK, but what is important is that you can see it visually in the list, may not make sense going through all payment details to find concilliated/unconcilliated

As you describe by default all payments are not-concilliated unless checked. We think in most use cases is better the other way around: that by default all payments are concilliated unless checked. When you are comparing the listing with the external one, most of the payments may be there and only some not yet.

Is it planned also a partial saldo taking into account only concilliated payments? Now we have to rest from the account saldo the not concilliated payments by hand.
cycloshost.com
Cyclos administration and hosting
admin
Site Admin
Posts: 1424
Joined: Mon Jan 24, 2005 10:31 am

Re: Solution for concilliated payments

Post by admin »

Hi,

Finally we opted for a more flexible solution that allows defining more than one status. Technically it is not hard to implement.

These status can be registered per currency, each status can have one or more possible 'next' status. The last status in a flow (that has no 'next') is final and cannot be changed by an admin.
One status need to be set as 'initial' or default. There can be more than one final status. So it offers a kind of a flow management. You can have on initial and more than one final status.
If you want you can have just one final status. What would cover your requirements.
In the transaction type you define the internal name for the mapping if you want to import the status when importing a transaction list.

The account summery will have a search filter for status (multi select).
We will make the status visible in the account summary result list, as a column.
There will be an option to show the sum of filtered transactions in the account history (for all accounts in the system)
When period filter is selected it will show the balance on begin and end date.
The transaction details will show the status (admin only), and if there is a possible next status and the admin has permissions there will be a change button.
The history of status change will be show in a tab (much like authorization history log).

We think like this it offers a good way to keep track of payments in a backed system. For sure the module will have improvements in the future.
cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Re: Solution for concilliated payments

Post by cycloshost »

Very good, this may work good. I guess is possible to define the labels of the states, for us the default state will be 'concilliated'.

We also miss to add notes to a payment once is closed, for example to relate it to a bill or a reference number, do you plan to add notes to a payment for admins?
cycloshost.com
Cyclos administration and hosting
admin
Site Admin
Posts: 1424
Joined: Mon Jan 24, 2005 10:31 am

Re: Solution for concilliated payments

Post by admin »

Hi,

Yes you can define the labels. We did consider adding a comment fields but there are some issues, mainly with performance. For the moment we do not add it, but might do it at a later stage.
cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Re: Solution for concilliated payments

Post by cycloshost »

Would be possible that when defining a payment status to have a "draft/perform" property so that the payment for statuses with property set to "draft" are not performed immediately but in a "draft" state (editable)? The idea is to send payments (usually via webservices) that are not immediately performed in Cyclos but wait until an admin changes the status.

Example:
1. Webservice registers payment with status "draft"
2. Admin checks draft payments and edit if necessary (reason of payment, amount, transfer type...)
3. Admin changes the status to completed/concilliated status (or any status that actually performs the payment) or cancelled.

Right now, the alternative to this is via chargeback and new payment but until the chargeback/new payment is done, the amount is incorrectly booked and with risk of not being recovered.
cycloshost.com
Cyclos administration and hosting
admin
Site Admin
Posts: 1424
Joined: Mon Jan 24, 2005 10:31 am

Re: Solution for concilliated payments

Post by admin »

Hi,

It would be much work to include workflows with status changes.
Besides that the authorizations offer already a mechanism for storing 'pending' payments and confirming and activating by admins. So that would be the preferred way.
It would be pretty easy to add an extension point to an authorization that will change the status of the payment. (extension points will be added in the next version).
cycloshost
Posts: 578
Joined: Mon Jan 30, 2012 8:12 am
Contact:

Re: Solution for concilliated payments

Post by cycloshost »

We thought also about using authorizations, but in our opinion these are two separated needs, and the use of authorizations for this would complicate a lot the account configuration.

One need is that some transfer types may need an authorization, and another need is that (mainly when when performing bulk actions), some payments (that can be without authorization, and here comes the problem) may be not completely good formatted and may need supervision and editing from an admin. Another point is that authorizations do not allow payment editing.

Imagine we have 10 transaction types in one account and only one of them is with authorization. For the one that is with authorization, there is not a problem, because anyway an admin will review it. The problem are the other 9. Of course, a solution would be to duplicate these 9 transfer types and make 9 new transfer types with authorization. Then the webservice can choose between a transfer type with or without authorization, but this will complicate enormously the administration of the accounts, even if we can change the status with extension points.
cycloshost.com
Cyclos administration and hosting
admin
Site Admin
Posts: 1424
Joined: Mon Jan 24, 2005 10:31 am

Re: Solution for concilliated payments

Post by admin »

I see your point.
With the info I have creating multiple TT would be the best option. Having payments stored as pending is very complex. for the moment we don't have plans to add this to other entities than authorizations.
Maybe you can find a way to solve it by using extension points.
Post Reply