Agreements and Documents

Here you can put ideas for new functionalities and improvements.

Moderators: rmvanarkel, hugo, alexandre

Post Reply
Posts: 107
Joined: Wed Dec 31, 1969 9:00 pm

Agreements and Documents

Post by admin_de2 »

Dear Cyclosians,

currently i struggle with individual documents and agreements.

So, an idea came up as a new, awesome feature for cyclos:

You write in the documentation somewehre "e.g. loan contracts" and "print & sign".
Im my case it's not a loan contract, but SEPA-mandate consisting of with SEPA-reference-document as individual document and sepa-agreement as optional user-agreement.
I try to sync both, which is not possible, until:
- the SEPA-agreement may not be agreed, but the individual document is there anyways; that wired - cyclos cannot make the availability of individual documents depended from agreements, only from groups.
- the individual document cannot contain a variable / date from the agreement, e.g. agreement-date

=> If you put agreement together with individual documents, cyclos would be able to:
- gather mandatory or optional agreements;
- maintain official documents automatically which result from these agreements;
- make the need obsolete for printing out and signing manually; in most cases a digital agreement with this already fine working history would do the job;
- taking back agreements from user side should result in invalidate the corresponding document

Basically, the only things to do here are:
  • Enable VAR / fields from agreements, as already available from e.g. user-profile
  • Binding validity of an individual document to an agreement an make it only available when agreed; this could be made by either conditions in document's template or by conditional binding-fields in the document setup, when a individual documents is valid or invalid.
What do you think about the suggestions?
If you are the opinion it's a good one, i'll offer more input / structuring work for it.

Thank you, Thomas
Posts: 259
Joined: Tue Oct 05, 2010 1:14 pm

Re: Agreements and Documents

Post by rmvanarkel »

Dear Thomas,

Thank you for the suggestion, we never had a client in need of something like this so we need to investigate if there is a use case. Are you planning to use this for SEPA direct debit? I don't know how it is in your country but in Holland this will be (semi) illegal, the advised way here is to get an e-mandate first. Please let us know where you want to use it for so we can better understand your request. Especially why you think a general agreement will not be legally binding and a specific agreement will be.

Warm regards,

Posts: 259
Joined: Tue Oct 05, 2010 1:14 pm

Re: Agreements and Documents

Post by rmvanarkel »

Please also consider using a registration wizard as an alternative..
Posts: 107
Joined: Wed Dec 31, 1969 9:00 pm

1: New feature; was: Agreements and Documents

Post by admin_de2 »

Dear Roder,

i think i mixed my own requirement too much into the thing i called "new feature".
So, i try to separate it.

1. New feature:
  • Cyclos has a documents functionality being able to provide documents to print (means: also print to pdf)
  • Cyclos has the agreement-functionality with big advantages, e.g. to get re-agreements from users when the agreement text changed
  • Both work independently until now;
  • specially documents are meant to print out according Cyclos' documentation and sign it
  • while the agreement is basically the same as a valid commitment to, e.g., a contract, LIKE a signature
  • the feature would be, to put both together: using agreement to "sign" or let users commit to documents
Basically meant like that.
There are several way to do it. One - maybe seneful one - could be:
  • Introduce an option to bind an individual document to a agreement
  • If admins use a binding, e.g. Document A is bound to agreement I, this leads to different document behavior:
  • The document does not show up in "Documents-Section" of the user or hold an alternative text, telling that the documents has to be created by making agreement I
  • Agreeing to / "signing" a document may start with filling out the document A's fields.
    • The user sees the filled out document in the 2nd step. At the end of the document, where the signature field is in paper versions or the submit button is, the agreement I-Checkbox with the optional and more common agreement-I text
    • By agreeing, the document CAN (optional) take field of the agreement into account, e.g. agreement date. Users can further more download the document, print it to pdf, BUT NOT change it, without loosing the agreement and so the need to agree again.
    => That would make it possible to maintain committed, "signed" documents, which could be changed by the user (e.g. Name changed by marriage, an address changed, whatever) and re-agreed again
    => That would lead to less administration and more automatic processing

    Hope, i could describe it, which basic benefit this would provide.
Posts: 107
Joined: Wed Dec 31, 1969 9:00 pm

2: Our SEPA-Mandt-case; was: Agreements and Documents

Post by admin_de2 »

Dear Roder,

i think i mixed my own requirement too much into the thing i called "new feature".
So, i try to separate it, now the 2nd part.

Status quo is:
  • there is an individual document "SEPA-Mandate" for users
  • there is an agreement "SEPA"; an agreement-script checks the user's profil field, if all SEPA-prerequisits are fullfilled. Only in this case users can agree to SEPA, otherwise they have to add the missing stuff first (IBAN, BIC, ...)
  • ONLY THEN the individual document contains senseful data, except the agreement date. This one is not available in documents as field. So it's simple "today" for now
Further, users get acknowledged when a SEPA-related transaction was triggered. This is done for fullfilling the SEPA-rules.
Further, when users, which already agreed the SEPA-agreement, change SEPA-related profile fields (e.g. deleting or changing the IBAN), two actions happen:
  • the agreement is taken back, since the data for the agreement and the document invalidates and the document has to change and re-agreed
  • a new mandate-id is generated due to the changed data; this one stays always unique
So far the process works and is fine.
It lacks just of these single points:
  • The document date is "now" instead of the date of the last agreement; fields of the users' agreements are not available on documents; so, available field are limited; i found no extension point or even possibility to hook a script in the document functionalitiy
  • the document shows up permanently, even before a users agreed to anything; when a user looks at the document and document-relevant profile fields are still not provided, the users sees a wired looking document.
  • I found no option to work arround the wired document thingy: separate users by groups, one with an another without this document, will double the amount of available over all groups and get messy so; another approach would have been to make the documents output conditional: if some needed fields are there, show document; if not, show as document another message instead to advise the user what to do firstly; i found no conditinal TAGS / VARS / PLACEHOLDERS / FIELDS in the context of the documents template.
These are the current ache points with our SEPA-mandate and have no idea until now how to solve it.
Another approach is of course to let generate a mandate externally via API. We have an external application there as well, but this one has no PDF generation and we want to avoid it to integrate that; first of all because we would upload it back to cyclos for the user's comfort at the very same location "Documents", where it is now already - so, turning in circles a bit.

Hope i could point out that it works nearly and where the stoppers are with not to complicated text to read.

Thank you very much for any feedback on this.

Posts: 207
Joined: Fri Feb 17, 2006 11:01 am

Re: Agreements and Documents

Post by luis »

I think both your issues can be solved with service interceptors. You would need 2 of them.
  • The first one applies to the "DocumentService.listUserDocuments" method. It should remove the document from the result list if the user hasn't agreed
  • The second one is to show the date in the document. For this they could have some markup in the document body, such as #date#. Then, the service interceptor for the method "DocumentService.processDynamicDocument" could modify the return value by replacing that variable with the last agreement date for the user. There's an example in the documentation for replacing profile field variables in menu pages. You could use a similar approach.
Luis Fernando Planella Gonzalez
Cyclos development team
Posts: 107
Joined: Wed Dec 31, 1969 9:00 pm

Re: Agreements and Documents

Post by admin_de2 »

Dear Luis,

sound sound exactly like what we need and though awesome!
We'll give it a try!

Thank you very much,

Posts: 27
Joined: Thu Apr 23, 2020 5:37 pm

Re: Agreements and Documents

Post by jakob.schumann »

Hello luis,

it seems the DocumentService.listUserDocuments interceptor is not called when the user viewing the document list is not the user itself but an admin viewing another user's documents, is this correct and the intended way?

Best regards,
Post Reply