*** sjc has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
<reinhard> good morning all
<dimas> good morning
*** johannesV has joined #gnuenterprise
<johannesV> good morning
*** wt has quit IRC
*** klasstek has quit IRC
<dimas> is that possible to decrease font size in forms under win32?
<dimas> it is in few point larger than fonts used for form's menu
*** sjc has quit IRC
<dimas> Connection instance has no attribute '_defaultBehaviour_'
<dimas> got this under win32 with new release
*** kilo has joined #gnuenterprise
*** johannesV has quit IRC
<reinhard> you installed new release over old release?
<reinhard> dimas: I suspect you have to remove old release before you install new one
<reinhard> otherwise windows will (in lack of a proper package management) mix files from old and new release
<dimas> reinhard: thanks, will do now
<dimas> reinhard: works now
*** yure has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** wt has joined #gnuenterprise
*** kilo has quit IRC
*** jcater has quit IRC
*** menomc has joined #gnuenterprise
*** mnemoc has quit IRC
*** jamest has joined #gnuenterprise
<btami> jamest: i'm thiking on date masks, but stucked
<jamest> how so?
<btami> there are several Date*Mask* config options in GFConfig.py
<btami> they are never used
<jamest> right
<btami> if i try to use them i DateTime display handler
<jamest> masks are a complete mess
<btami> (i'm playing with date only here)
<jamest> right now i believe the working masks are defined per entry (or field) in the gfd
<btami> yep
<jamest> and even those don't get passed into all display handlers
<btami> but if i use them like this:
<btami>   def _buildDisplayHelper(self, value, editing):
<btami>     if editing:
<btami>       if self.__inputMask:
<btami>         format = self.__inputMask
<btami>       else:
<btami>         format = gConfigForms ('DateEditMask')
<btami>     else:
<btami>       if self.__displayMask:
<btami>         format = self.__displayMask
<btami>       else:
<btami>         format = gConfigForms ('DateMask')
<btami> the problem will raise in  _buildValue(self):
<btami> koz if no self.__inputMask
<btami> then it wants to deal with years part of date
<btami> but if i used "%x" in gnue.conf
<btami> i will never know what part of date is the year
<jamest> let me svn up and look at the code
<btami> maybe i'm on a wrong way...
<jamest> well
<jamest> all of this is going to change
<btami> cool
<btami> :)
<jamest> if you look in gnue-common/tests/
<jamest> formatting_masks.py
<jamest> you'll find test cased for jcater's plex based input mask system
<jamest> cases
<btami> wow!
<jamest> also 00010.txt describes how input masks may work
<jamest> in gnue-common/doc/technotes
<jamest> i'm pretty sure I wrote that and jcater implemented something similar without reading it (so it may not be exact but it's close)
<jamest> the issue I'm facing is getting the code to work grafted into the display handlers
<jamest> while I can get the test cases working fine I can't get the code to work when grafted in to handle the existing displaymask="" support
<btami> i see
<jamest> i know that doesn't help you now though :)
<btami> no problem
<btami> i was just playing with dates
<jamest> if you're interested in playing w/ dates
<jamest> maybe you can craft a few test cases in that formatting_masks.py
<jamest> that reflect what you want to do
<btami> ok, good idea
<jamest> there is also a src/formatting/masks/test.py that contain cursor control tests that I've not moved into the unit test yet
<reinhard> jamest: will it be possible to set a single mask for all 4 jobs (input, display, storage, validate)?
<jamest> reinhard: should be
<reinhard> e.g. just have a mask style="date"
<btami> and get a default from gnue.conf too
<jamest> yes
<jamest> for now I'm just trying to graft in the new stuff with the existing masks
<jamest> but I really think we'd be best to start over wrt masks in the gfd
<jamest> as everything there was added as a hack to get us by
<jamest> btami: also, if you're playing in input masks its probably worth noting that input masks are built by a 2 phase process
<jamest> my terminology my be all wrong as my memory is rusty since I dug through the mask code
<jamest> but phase 1 uses plex to build a temporary thing (lexicon iirc) that is then used in phase 2 to build the actual input mask handler
<jamest> iirc this was to allow for tokens that repeat or for \ escaped items
<jamest> this wasn't documented in the original code and is barely documented in my first pass through it
<jamest> inspired by the comments johannesV and reinhard have put in datasources I'm going back through input masks and filling those out
<jamest> but haven't commited yet
<reinhard> jamest: there seems to be code in formatting/*Mask.py and in formatting/masks
<reinhard> is one of them about the replace the other, or will they play together?
<jamest> formatting/masks is all the new stuff
<jamest> the stuff above is all old hacks
<jamest> at least that's how I recall it
<jamest> the actual lexicon that describes the new input mask structure is in
<jamest> MaskParser.py
<jamest> one thing I don't like about the new system is that you have 3 mask types
<jamest> test, numeric, date
<jamest> it defaults to text unless one of the 2 boolean values for the arguments numeric or date  are passed in as true to the inputmask constructor
* jamest doesn't feel that those should be booleans
*** SachaS has joined #gnuenterprise
<reinhard> right
<reinhard> what does that mask type affect actually?
<jamest> at this time I don't think it affects anything
<dimas> reinhard: could you answer few questions about gnue-luca?
<reinhard> dimas: generally yes, but I have to leave in 5 minutes
<dimas> and later?
<reinhard> so actually I'd prefer if you can ask later
<reinhard> yes
<reinhard> will be back in the evening
<dimas> ok
<jamest> reinhard: i have one for you
<jamest> is there a reason that resultsets can't return a list of dicts
<jamest> iirc it returns a dict of dicts with the outter dict containing the PK field value
<jamest> (wow, that was clear :)
<reinhard> the reason is that nobody needed it
<jamest> ah, ok, i thought the old ds's did it
<reinhard> actually I would wonder why you want it, as you can handle a ResultSet like it *was* a list of RecordSets, and every RecordSet can be handled as if it *was* a dict
<jamest> um
<reinhard> (see afromm's question lately)
<jamest> i have sample code where I needed that
<jamest> let me see why I did
<jamest> i do a query "select packslip_id from packlist where email_sent is null"
<jamest> then I do
<jamest> packslipIds = resutls.getDictArray(['packslip_id'],['packslip_id']).keys()
<reinhard> erm
<jamest> but i guess it can't be much cleaner than that anyway
<reinhard> is packslipIds the variable you're after?
<jamest> yes
<reinhard> what do you do with packslipIds afterwards
<reinhard> iterate through it?
<jamest> result['packslipId'}
<jamest> yes
<reinhard> then I'd just iterate through result
<reinhard> sorry must run, bbl
<jamest> l8r
*** klasstek has joined #gnuenterprise
*** SachaS has quit IRC
<reinhard> back
<reinhard> jamest: I seriously would recommend to not use getDictArray
<reinhard> it's a weird weird thing I needed to merge 2 result sets
<reinhard> dimas: ready for your questions
<dimas> ok
<dimas> i do not quite understand what gl_journal is?
<reinhard> ok
<reinhard> we have the concept here of entering transactions in a batch
<reinhard> then sorta "posting" that batch (means it gets visible on the accounts and at the same time it can't be changed any more)
<dimas> batch was last addition to gl.gcd
<reinhard> and such a batch is usually called "journal"
<reinhard> hmm... please don't confuse it with the "batch" in gl.gcd
<dimas> ok
<reinhard> or even better
<reinhard> just think it's a batch before it has been posted, and it is a journal after it has been posted
*** dcmwai has quit IRC
<reinhard> a journal is just a group of transactions that was posted at once
<reinhard> we have laws here that basically say you have to number those journals and you have to print them out
<dimas> should there be a name for the journal
<reinhard> a name?
<reinhard> not sure I understand what you mean
<dimas> could you give an example
<dimas> let's say we have simple operation
<dimas> 2 entries 1 transaction 1 journal
<reinhard> i'll try to make it clear
<reinhard> accountant a starts his day with entering all transactions of yesterday from the bank account
<reinhard> then enters some invoices
<reinhard> and other stuff
<dimas> yes
<reinhard> at noon he has entered lots of transactions, but
<reinhard> when he looks at the accounts, all those transactions are not yet visible (this is required by law here)
<reinhard> he can still modify or delete transactions he has entered
<reinhard> then at a certain point he decides to "post" what he has done so far
<reinhard> so he hits some magic button and creates a journal with all his transactions
<reinhard> from this point on all transactions are set in stone forever
<reinhard> and from this point on the transactions are visible on the accounts
<reinhard> he will get a list of all these transactions titled "journal # 135"
<reinhard> he puts that into a folder where all those printouts are sorted by number
<reinhard> so tax authority can come and see all transactions and how they were posted sequentially
<dimas> ok, ic now
<reinhard> ok :)
<reinhard> it becomes even more interesting when we have accountant a and accountant b working at the same time
<dimas> is that journals practically defined on daily basis?
<reinhard> accountant a will generate journal #135 and accountant be #136
<reinhard> s/be/b/
<reinhard> and every journal will carry the name of the person who did it
<reinhard> most accountants here do it on a daily basis
<reinhard> for small company they could also do weekly or monthly
<reinhard> to prolonge the possibility to fix errors (remember no change after making journal)
<dimas> but if you do monthly your transactions are not yet visible?
<reinhard> yes
<reinhard> not on the "official" lists
<dimas> during the month
<reinhard> most programs have inofficial lists or queries
<reinhard> that also list stuff before journal is done
<dimas> :)
<reinhard> but tax law requires that all lists that you give to tax authority does contain only data that is not modifiable any more
<dimas> then where is it in luca? :)
<reinhard> [well, we both know that "not modifiable any more" is nonsense anyway for any database application, but at least the tax authority should "feel" like it is not modifiable ;-)]
<reinhard> luca is very much incomplete
<dimas> understand
<dimas> ok
<reinhard> but these things will of course exist
<reinhard> accountants want to be able to check the outcome of the transactions before they finalize them
<reinhard> e.g. every account will have some "official balance" and "inofficial balance" at some point
<dimas> could you give an example of what doctype is? what terms would you put in there for code and name?
<reinhard> CI = Customer Invoice
<reinhard> SI = Supplier Invoice
<reinhard> BN1 = Bank note for bank 1
<reinhard> BN2 = Bank note for bank 2
<dimas> you would scare me with that "inofficial balance" thing as i thought it's only wierd local practice :)
<reinhard> (Bank note = the piece of paper you get from the bank to show how your account is)
<reinhard> I think these inofficial balances exist everywhere where law enforces official values to be non-modifiable
<reinhard> which I know is true at least for germany and austria
<dimas> ok
<dimas> let's say we are in an August gl_period and we post transactions on daily basis
<dimas> so July gl_period is closed?
<reinhard> not necessarily
<reinhard> there might still come in an invoice from a supplier with July date
<reinhard> but at the time you sent your monthly report for July to the tax authority you would close July
<reinhard> so you make sure you don't accidentally add more transactions to July
<dimas> i lost where we keep balance results on earch accounts  for the beginning of new gl_period
<reinhard> we don't yet
<reinhard> this will probably happen in an OnValidate trigger of the entry
<dimas> will that invoice be booked in August journal? and do you need to sent fixed report?
<reinhard> and might well result in a new class
<reinhard> that invoice will have to be booked in a July journal
<reinhard> even if you have to do a new journal for that invoice
<reinhard> law requires that months can't be mixed in a journal
<reinhard> we we need to send a fixed 2-page report for VAT each month
<reinhard> e.g. for July on 15 Sept
<dimas> could we define that new class quick?
<btami> dimas: the double entry bookkeeping is a well stadardized thingy
<btami> http://en.wikipedia.org/wiki/Double-entry_book-keeping
<reinhard> dimas: I hope to be able to work again on luca within the next days (maybe over the weekend)
<reinhard> will keep in mind to do that next
<dimas> btami:  thanks
<reinhard> however I still think that *much* is still missing before luca is a usable accounting system
<jamest> reinhard: i'll phase it out later, that app just went online yesterday :)
<reinhard> must leava again, friend coming to visit us tonight
<reinhard> jamest: lol
<reinhard> bbl
<dimas> btami: yes, but there is some local rules and practice as you can see
<dimas> bbl
*** jcater has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** johannesV has quit IRC
<wt> jcater: you there?
*** johannesV has joined #gnuenterprise
*** dcmwai has joined #gnuenterprise
*** arunk has joined #gnuenterprise
*** johannesV has quit IRC
<jcater> wt, here
*** arunk has quit IRC
<wt> jcater: new server up?
* jcater looks around
<jcater> sigh
<jcater> no, I'm embarrased to say
<jcater> it's just sitting in my rack looking pretty
<wt> is the T1 in?
<wt> I must get
<wt> later all
*** wt has quit IRC
*** kilo has joined #gnuenterprise
*** btami has quit IRC
*** jamest has quit IRC
*** docelic has joined #gnuenterprise
<docelic> hi folks
<reinhard> good night all
*** reinhard has quit IRC
<docelic> cya
*** klasstek has quit IRC
*** docelic has quit IRC
*** jamest has joined #gnuenterprise
*** sjc has quit IRC
*** yure has quit IRC
*** holycow has joined #gnuenterprise
*** kreiszner has joined #gnuenterprise
<kreiszner> When will the debs be ready for the latest release?
*** kilo has quit IRC
<ajmitch> when they're done
<ajmitch> I've been a little busy
<jamest> ajmitch: hang in there, it'll be over soon^H^H^H^Hsometime.....maybe
<kreiszner> Does the new gnue-reports work significantly beter than the last version.
<jcater> kreiszner, I seriously doubt it
<jamest> there is that new function support
<kreiszner> I am having trouble getting started making a report. I have made several forms with sucess but I don't see where the data is coming from and where to design the report.
*** afromm__ has joined #gnuenterprise
<jamest> kreiszner: reports are tougher IMHO
<jamest> i *think* gnue-reports/samples/foobulations is a working grd
<jamest> but reports and I don't get along well
<jamest> i have to run
*** jamest has quit IRC
*** jcater has quit IRC
*** afromm_ has quit IRC
*** kreiszner has quit IRC