IRC logs of #tryton for Wednesday, 2011-06-15 #tryton log beginning Wed Jun 15 00:00:01 CEST 2011
-!- ecarreras( has joined #tryton00:36
-!- ecarreras(~under@unaffiliated/ecarreras) has joined #tryton00:36
-!- ciupicri(~ciupicri@ has joined #tryton02:04
-!- nicoe_( has joined #tryton04:02
-!- sharkcz(~sharkcz@2001:15c0:6747:160:250:43ff:fe3c:3b5d) has joined #tryton04:40
-!- alimon(~alimon@ has joined #tryton05:17
-!- yangoon( has joined #tryton05:19
-!- plantian( has joined #tryton05:47
-!- okko( has joined #tryton06:53
-!- mhi1( has joined #tryton08:20
-!- enlightx( has joined #tryton08:35
-!- cedk(~ced@gentoo/developer/cedk) has joined #tryton08:43
-!- pjstevns( has joined #tryton09:02
-!- pjstevns( has left #tryton09:02
-!- pjstevns( has joined #tryton09:03
-!- bechamel( has joined #tryton10:20
-!- nicoe( has joined #tryton10:41
-!- elbenfreund( has joined #tryton11:13
-!- cygal( has joined #tryton12:21
-!- cygal( has left #tryton12:21
-!- timewulf1( has joined #tryton12:29
timewulf1cedk: ping12:30
-!- elbenfreund( has joined #tryton12:31
cedktimewulf1: pong12:31
timewulf1cedk: hi, are you the maintainer of the accounting module? I've got some problems in understanding how it should work.12:33
cedktimewulf1: yes12:34
timewulf1I know some other accounting apps and they go other ways ...12:34
timewulf1I'll try to show what I mean:12:35
timewulf1sorry, in English I need a bit longer12:38
timewulf1I start to record a new move. I've to set a booking time frame, the journal where to put in and the move date into the header.12:40
timewulf1If needed I can put a descriptional text, too.12:42
cedktimewulf1: perhaps simplier to explain what you don't understand instead of what Tryton does12:43
timewulf1cedk: ok, may be12:43
timewulf1I'm forced to put in names (I think this shall be descriptional text) into the move and the move lines.12:45
timewulf1But those texts don't exist for every move or move line.12:46
cedktimewulf1: on the move, it is because you create it if you go directly through "Open Journal" you don't need12:46
timewulf1I go Erfassung - Übersicht Buchungssätze - Neu12:47
-!- elbenfreund1( has joined #tryton12:49
timewulf1If I go directly over Erfassung - Journale-Buchungszeiträume I can create new journals, but not open them to book into12:52
timewulf1not even a double or right click on one journal gives me anything12:53
timewulf1cedk: sorry, forgot to put your name in front12:55
cedktimewulf1: I don'T speak German so I don't understand what you say12:55
cedktimewulf1: but in English you can go: "Financial Management>Entries>Open Journal"12:55
timewulf1cedk: I've only the German menu in the moment and there differentiated between Configuration = Einstellungen and Recording = Erfassung and Reporting = Auswertungen.13:00
timewulf1cedk: So I go on Recording = Erfassung, then Overview-Moves = Übersicht Buchungssätze, then new move = neuer Buchungssatz13:02
cedktimewulf1: activate the English13:03
timewulf1cedk: ok, a few minutes and I'll ping you again13:03
-!- elbenfreund( has joined #tryton13:21
timewulf1cedk: I tried the English menu, found your way and tried to do the same again in German: This works, but this is the way with creating valid moves directly. The same should work with draft moves: Entries - Account-Moves - New Account Mode ... and this does not.13:45
timewulf1cedk: Before saving a move, you are forced to give it a name.13:46
cedktimewulf1: yes it is difficult to behave differently14:02
paepkeguys. i don't know if someone already reported it, but i can sync my android phone via caldav with tryton. its currently a one way sync as the app is beta.
bechamelpaepke: cool14:19
yangoonpaepke: great to hear that14:19
paepkejust to mention: i have not programmed it...14:19
cedkpaepke: There is a wiki page about CalDAV and Tryton somewhere14:20
paepkecedk: yeah, i'll update it as soon i get it how to get screenshots out of my phone ;-)14:20
paepkehmm. spreadsheet. didn't remember. no screenshot but updated it.14:25
cedkpaepke: there is also
paepkecedk: yes. thats the link i posted14:25
nicoepaepke: looks great. A good reason to switch to android ...14:26
cedkpaepke: It is CardDAV not CalDAV14:27
paepkenicoe: currently only one way. but it works nicely.14:27
paepkecedk: oh.. right. installed that also.14:27
paepkebut the last one i tried its not finished14:28
timewulf1cedk: When you are working on this (Entries - Account-Moves - New Account Move), may you change some misleading field names in this dialog? There are fields named "Name" and "Reference" for the move record and for the move line record. In the upper part of the dialog (the move record) "Reference" should be better "Move No" and "Name" better "Move Text". In the lower part (the move lines) I can't even find a difference between "Name" and "Referenc14:28
paepkei have to correct. a sync worked here. but i don't know if i lost something :-)14:33
cedktimewulf1: better to keep the same wording as other place in the application14:35
timewulf1cedk: same wording everywhere is ok, but the same wording for different things leads to errors because of misunderstanding14:45
cedktimewulf1: name is the name of the record14:46
cedktimewulf1: it is not always a number14:46
cedktimewulf1: and reference is a free field to put a reference14:47
timewulf1cedk: I wanted to rename field names "Name" as "Move Text" or "Line Text", "Reference" should be "Move No" or "Line No". In the move record they are used this way, in the move line record their use/behaviour isn't clear.14:50
timewulf1cedk: And even in lists like moves together with their corresponding movelines one has to rename those fields either. If one doesn't do, you can't differentiate the meaning of them.14:54
cedktimewulf1: I don't like to put the name of the object in the label of a field14:55
cedkbecause it can break the modularity14:56
cedktimewulf1: for reference naming it "Number" is too reductive as you can have more then just number as references14:58
timewulf1cedk: I see what you mean and in forms with only one objecttype you are possibly right, but in forms with 2 ore more types the naming conflict should be solved. My namings were just suggestions, we may find better ones.15:01
cedktimewulf1: I find there is clear difference between field from the form and field from lines15:02
cedktimewulf1: from which view are you talking?15:04
timewulf1cedk: But the normal user, not we from sight of developer, does not: Same names lead the user to same meanings of his world. The normal user doesn't think of attribute names but of names of people, documents or other things.15:07
timewulf1cedk: Entries - Account-Moves - New Account Move15:08
-!- ciupicri(~ciupicri@ has joined #tryton15:08
cedktimewulf1: ok, there is a clear title for lines15:09
cedktimewulf1: if we start to name like you suggest, we must add before every field the Model name15:10
timewulf1cedk: No, just using names which are used in the user's world. In accounting a move doesn't have a name, but a number and a description, a move line doesn't have a name either, but an incremental number starting with 1 and a description or reference or party or something else like this.15:14
cedktimewulf1: we don't care about what the users put in the name but if we rename "name" into "number" then the user is required to put a number15:20
timewulf1cedk: sorry, you don't understand me. We just should name fields with meaningful names, meaningful from sight of the user.15:23
cedktimewulf1: yes but naming "Number" a field that contains chars is not meaningful15:24
cedktimewulf1: I'm not against rename it but it should be logical15:26
timewulf1cedk: For example article-numbers may contain chars but in the form to create new articles the field will be called article-no.15:26
timewulf1cedk: Let's divide our discussion for the two different record types.15:26
cedktimewulf1: no it is named code15:26
timewulf1cedk: That's bad from sight of the clerk.15:27
timewulf1cedk: I know what you mean: For us developers it's clear, but the clerk didn't here of "code" before, the clerk's client doesn't use this wording, so the form doesn't match the wording of the user.15:29
cedktimewulf1: I was talking about the "number" of the article15:30
timewulf1cedk: me too15:30
timewulf1cedk: code is a word, invited by developers - article-number is a word, used in the real world15:31
cedktimewulf1: I'm not sure about that15:32
timewulf1cedk: If we want to discuss with users and don't want to be misunderstanded, we've to learn and use their vocabulary.15:33
timewulf1cedk: But let's go back to the move record and form15:34
timewulf1cedk: I hope, we agree in the following: A move doesn't have a name, but it has got a description and after validing it's got a booking number.15:37
cedktimewulf1: I don't mind to rename "name" into "description"15:37
timewulf1cedk: ok, agree15:39
timewulf1cedk: The next field in "move" which is misleading is "Reference". The field is empty until changing the state from draft to valid and one can't edit it.15:42
timewulf1cedk: After the move is set to valid, the field shows the booking-number.15:43
cedktimewulf1: the field is a many2one to the move15:44
timewulf1cedk: Maybe, but I can't see anything other than this one booking-no in the form.15:46
cedktimewulf1: it shows the name of the move15:50
-!- pjstevns( has left #tryton15:56
timewulf1cedk: Now I'm confused: We have got the field "Name" and agree to rename it to "Description" and now we've got the field "Reference" and you tell me that this is the name of the move-record. The field is empty when typing in the data, the field is empty when saving. It's filled when changing the state from draft to valid? That means the move gets the booking-no as its name when putting it definitly into the journal.15:58
timewulf1cedk: Why shouldn't we name the field "Booking-No", when it just shows this?16:00
cedktimewulf1: sorry I thought you was talking about move field in move line16:00
timewulf1cedk: no, I'm still within the "move"16:02
cedktimewulf1: in the help of the field, it says "Also known as Folio Number"16:02
timewulf1cedk: folio, just another word for thick book, so "Folio-No" is the same as "Book-No" or "Booking-No". "Booking-No" I think is the better wording16:04
timewulf1cedk: But all are better than "Reference"16:05
cedktimewulf1: why not "Posting Number"16:05
timewulf1cedk: no problem, even the same, but then we will get the question, why we call the object "Move" and not "Posting" ;-))16:10
cedktimewulf1: Posting is not a object it is an action16:10
timewulf1cedk: One synonym of posting is just what we call move116:12
cedktimewulf1: for me, it is different as move can be "non-posted"16:13
timewulf1cedk: I've no problem with that, but I would prefer "Booking-No", because it reflects, that this number is given when writing it definitly into the journal. Because book is just another word for "journal" in this use-case16:17
cedktimewulf1: no reference is filled once you post the move16:23
timewulf1cedk: one moment, I'll retry, I did it just a few minutes ago16:24
-!- alimon(~alimon@ has joined #tryton16:26
timewulf1cedk: with posting the reference gets filled16:29
timewulf1cedk: Are you still in16:32
timewulf1    Entries - Account-Moves - New Account Move16:32
timewulf1or did you take the way with16:32
timewulf1    Entries - Open Journal - New?16:32
cedktimewulf1: I read the code16:33
-!- zodman(~andres-va@foresight/developer/zodman) has joined #tryton16:37
timewulf1cedk: do you find it?16:47
cedktimewulf1: find what?16:48
timewulf1cedk: the code whith which the reference field gets updated, when the move is posted16:51
cedktimewulf1: yes16:51
timewulf1cedk: thanks, Which new name do you prefer instead of "Reference"? "Posting-No" or "Booking-No"?16:54
-!- vladimirek( has joined #tryton16:55
cedktimewulf1: "Posting Number" because it is linked to the post action16:57
timewulf1cedk: np, the reasons good. The German translator made a good work in the past, so he/she will find the right German wording.16:59
timewulf1cedk: Before changing to the "move line", let me summarize the changes for the move:17:05
timewulf1cedk: Use-Case is Entries - Account-Moves - New Account Move17:06
timewulf1cedk: The old field "Name" shall be renamed to "Description" and will be set to optionally.17:08
timewulf1cedk: The old field "Reference" shall be renamed to "Posting Number".17:09
cedktimewulf1: Name can not be optional17:10
cedktimewulf1: but we could try to make it filled automaticaly if not set17:11
timewulf1cedk: That would be good. A provisional number which will be replaced with the "Posting Number" after posting?17:15
cedktimewulf1: no17:16
cedktimewulf1: "Posting Number" must be readonly17:16
timewulf1cedk: Yes, but the "Name" can be changed to the same value as the "Posting Number" or is there a problem I don't see?17:18
cedktimewulf1: it is bad to overide value that the user entered17:18
timewulf1cedk: Only if the user didn't enter something17:20
cedktimewulf1: but the field is required so it must have a value when it is stored in the database17:25
timewulf1cedk: Yes. If the user gives a value all is ok! If he doesn't we fill in a provisional value in a format we can recognize, when the user presses "Save". When he posts the move, we look for this format and if we find it, we overwrite it with the "Posting Number".17:28
cedktimewulf1: this is bad to overide vales based on a format17:35
timewulf1cedk: may we put a switch?17:36
cedktimewulf1: I don't understand17:36
timewulf1cedk: A little value in the move-record, which is set "True" if we put the provisional value and which is set back to false, if the user fills something into the field.17:38
cedktimewulf1: I don't see the value in duplicate the value of a field into an other17:40
timewulf1cedk: It's better to have the same value 2 times, than to have something senseless in one of the 2 fields. If the user doesn't give a description, he/she thinks the "Posting Number" is meaningful enough.17:44
timewulf1cedk: The "name" field which now holds the description of the move is referenced in the accountsheets, I think. So this information is visible there too.17:47
cedktimewulf1: no it is not better to have twice the same value, it is useless17:52
timewulf1cedk: generally I agree, but if we've to fill something in, then better a duplicate value of another field with for this case comparable meaning, than something completely senseless17:55
cedktimewulf1: it will not be senseless as it will be the sequence of move17:58
cedktimewulf1: like it is already the case for move generated by invoice17:58
timewulf1cedk: The same as I said before: From developer's sight you are right: We can identify the move this way. From user's it's senseless: The user doesn't have any document or anything else, which leads him to this value. He has to put the "Posting Number" on his document. All other information is meaningless form him.18:01
cedktimewulf1: then what should be done is the modify get_rec_name to show the description if there is no post number otherwise the post number18:05
timewulf1cedk: yes, I think so. I hope I'm not bothersome to you. In my projects I'm often the moderator between users and developers and my biggest problem is, to use wordings with the same meanings in both dayly lifes.18:06
cedktimewulf1: so like that no need to overide the previous value18:07
timewulf1cedk: sorry, then I didn't understand you before18:08
cedktimewulf1: what is display in a many2one is the rec_name which is computed by the method get_rec_name18:09
cedktimewulf1: so we can modify the behavior like I said above18:09
timewulf1cedk: the problem is, at first saving time, we have no posting number and can't create one, because the move record isn't posted at this time.18:11
cedktimewulf1: yes18:12
timewulf1cedk: What will be shown in the name field, if the user doesn't fill in his description.18:12
timewulf1cedk: I would do the following:18:13
timewulf1when saving without a value given by the user, I would put in an incremented number of draft moves in brackets.18:15
timewulf1When the user posts the move, I would recognize this value or a separate switch value and replace it with the Posting Number18:16
timewulf1cedk: replace the description I mean18:16
-!- okko( has joined #tryton18:18
cedktimewulf1: I really don't like the "recognize"18:20
timewulf1cedk: ok, I've only little knowledge of python programming, but in database sql this would be a 2 or 3 line trigger.18:23
cedktimewulf1: it is not a matter difficultity of programming18:24
cedktimewulf1: but about the strictness of the application18:24
timewulf1cedk: In python I think, you need a separate attribute "provisional Description" to the move object, which holds true or false depending on the user's input18:25
timewulf1cedk: I think this would help you with the strictness18:25
cedktimewulf1: for me, it is not good because a move could live without being posted during some time18:28
cedktimewulf1: then you will refer to it using the "description"18:29
cedktimewulf1: so you can not erase it like that and lost the information18:29
timewulf1cedk: If this is a great problem: What is if you use the "name" field only program internal for example to put in the record number and create a separate attribute "Description" which is optional for the user?18:35
cedktimewulf1: it will not change anything18:36
timewulf1cedk: Why? "Name" can be filled with distinct values for each move and Description is only filled by the user. We don't have to do anything with those fields while saving or posting.18:38
timewulf1cedk: In the forms we don't show the name field, but replace it with the "Description".18:40
cedktimewulf1: ok as soon we don't change the name for posting18:40
cedktimewulf1: no! we must show the name field18:40
-!- alimon(~alimon@ has joined #tryton18:41
timewulf1cedk: that's too bad, but then I'll try to argue the other way: A move is senseless in accounting until it is posted and fixed in the journal. So some useless informations can be ignored until the move is posted. Therefor no user will reference a description, if it is flagged as provisional and known to be changed when posted to the journal.18:49
udonotimewulf1: AFAIK it is a usual way in accounting. First put in the data in draft mode, after re-checking the values, post them.18:51
timewulf1cedk: Then our problem is reduced to how we show this flag. Maybe this incremented number in brackets, may be a suffix like "Prov.-No: "18:52
cedkin many cases, users will even never post any moves18:53
cedkACTION bbl18:53
-!- plantian( has joined #tryton18:56
timewulf1cedk: Yes, but one uses this way, because of simplicity: No more typing than is absolutely needed, if some data aren't at hand, they can be filled in later. The application has to check if the records are ok, in the moment of posting. If we insist on filling out the description at savingtime, this is contra productive.19:00
timewulf1cedk: So this is, why we've to surround this mandatory field. As long as the move is a draft, a provisional value does no harm, if the user knows that it is provisional. With posting the user knows and accepts, that he didn't fill out the description and that therefor it will be filled by tryton.19:07
timewulf1cedk: On the other hand, you can't close anything like Journal, Period or Fiscal Year until you've posted or deleted all belonging draft moves. So at the end all moves have reached the same status: The description holds a meaningful "Description" filled in by the user or the less meaningful copied value of the "Posting Number".19:15
timewulf1cedk: I think this is an acceptable behaviour. It fulfills all the needs of the user.19:17
timewulf1cedk: Now me is away for half an hour or so. My family called me for supper.19:18
cedktimewulf1: you speak like if posting is mandatory but I can tell you that many people will never use this functionnality19:33
cedktimewulf1: and we don't want to force them to do so19:33
timewulf1cedk: Sorry, which sense has accounting if one don't use the foreseen functionality? If one don't post moves, the meaning of "draft" move makes clear, that the state of the move is just a temporary one.19:58
timewulf1cedk: But even if they don't post: Then all their moves have the same state either. They all have a provisional distinct number in the description field, if they don't fill it themselves. Other functionalities we don't disturb.20:03
udonotimewulf1: The sense is that it is very flexible in use. The account module is not only for use in Germany and their very strict accounting.20:03
udonotimewulf1: another helpful hint could be that Tryton is not a ready to use application, and it will not be one. It is a framework to build this kind of ready to use applications...20:04
udonotimewulf1: so you are invited to write a small addon-module which provides the functionality you need. And be sure you will get all help available to get started.20:05
timewulf1udono: That's ok, I told you yesterday, I will help. The whole discussion was meant to bring the project forward.20:07
timewulf1udono: When I shall describe myself, I would say I'm a good analyst, good moderator between developer and user and a little bit programmer.20:10
udonotimewulf1: this is good to know.20:12
udonotimewulf1: changing name spaces of fields in modules which are already released is awful for all depending developer and their customers. They have to change their modules accordingly which need additional work and at least cost.20:15
timewulf1udono: This is why my discussions go so deep into the workflows. If one understand them, much of the developing work is easy or easier than before. I don't want to treat someone to do work he doesn't believe it's right.20:17
udonotimewulf1: IMHO The accounting module can not be discussed on irc between two persons. It is just to important vor everyone. It is better to have a review of the accounting module and a kind of blueprint which shows where to go. IMHO this should be discussed on groups with email and a death line far away.20:18
timewulf1udono: I agree to that. I'm hopefully this is a good starting point. I would like to take part in such a discussion.20:23
udonotimewulf1: ... more than this, you'll need to initiate this discussion. Because you are the one with the interest ;-)20:25
-!- ciupicri(~ciupicri@ has joined #tryton20:25
timewulf1udono: No problem, I would like to do this. Give me a starting point and tell me the usual way to start this within the tryton project and I'll do so.20:28
timewulf1udono: The headline could be "Usability". The developed basics of Tryton are really good, I think, but we won't get acceptance of the users, if they can't do there normal work within the same time as in other programs. So we've to differentiate between developing basic modules and modules needed and worked out for users. I think for example, the accounting module is a hybrid of both parts and that was the difficulty in the discussion before.20:47
udonotimewulf1: 'Usability' is to general for me.21:01
udonotimewulf1: When I followed your discussion correctly, I see two topics related to accounting module: 1. Naming of several fields, 2. Usability on encoding moves and move lines.21:03
udonotimewulf1: I would discuss them separated.21:04
-!- enlightx( has joined #tryton21:05
cedkudono: indeed we only spoke about field name21:05
udonocedk: ok, then this :-)21:06
cedkI think we could split the name field into one description (for free text) and one named "Draft Number" like for "Post Number"21:06
udonotimewulf1: I would start with emails which explains the problems and your draft/preferred/idea solution.21:07
cedkthe rec_name will be Post if set or Draft21:07
cedkso "Post Number" will be readonly and set by the system with the sequence21:07
cedkafter that there will be the question of the required name field on move line21:08
cedkbut right now, I have no idea21:08
udonocedk: sounds interesting. For me it would be better to discuss this in groups.21:09
timewulf1udono: cedk: sorry I need to long to write in English. So you've posted many points while I'm looking for words.21:10
udonotimewulf1: no problem, English is for most of us foreign language...21:11
cedkudono: yes could you make a summary of it and put on mailing list21:12
udonoACTION seems down?!21:12
cedkudono: right now, for me it is just redesign not big change in the module21:13
timewulf1udono: cedk: Both topics are worthful to discuss: The naming, because to get users and developers to speak the same language. But this is not only in this one form, it's a more general problem. The workflow is special for this form or the few forms recording moves.21:13
udonocedk: No way, to many open tasks :-( But I will participate the discussion.21:15
cedkudono: is back21:15
udonocedk: Thanks21:15
cedktimewulf1: ok but let's go step by step21:15
udonocedk: my next step is to discuss the ticket module...21:16
cedkACTION going dinner21:17
udonobon appetit21:17
timewulf1udono: have a good meal21:17
timewulf1udono: sorry meant cedk21:17
udonoACTION afk, see you tomorrow21:18
timewulf1cedk: have a good meal21:18
timewulf1udono: cu tomorrow21:18
-!- helmor(~helmor@ has joined #tryton21:20
-!- okko( has joined #tryton21:25
-!- tshepang( has joined #tryton21:42
-!- vladimirek( has joined #tryton21:56
-!- timewulf1( has left #tryton22:00
-!- nicoe( has joined #tryton22:24
-!- gremly(~gremly@ has joined #tryton22:53
-!- plantian( has joined #tryton23:12
plantianHi, I am having trouble with a sale not being marked as Done.  Initially the invoice wasn't working because there was a old bug in tryton but I pulled the patch in and now the invoice is paid and the shipment is sent but both the invoice and shipment were recreated and there exists the cancelled original.  Should I just try to cancel the entire sale and make another one at this point ?23:17
-!- plantian( has joined #tryton23:40
-!- gremly(~gremly@ has joined #tryton23:53
-!- gremly(~gremly@ has joined #tryton23:55

Generated by 2.11.0 by Marius Gedminas - find it at!