[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Vendor & Client name defaults for new Documents; Would you like them?

Luke wrote:
On Fri, 22 Jan 2010, David Godfrey wrote:

This is a resend,
sent 2 messages 4 minutes apart,
one arrived straight away,
this one still has not over an hour later.

I got this, and then the missing version, in immediate succession.:)  This 
is not a fast, or consistently processing, list.

Comments below on the actual issue.

Yeah, if you look at the headers for both messages laura.instanthosting.com.au
held onto the delayed message until AFTER the 2nd one was sent!
Have already approached my Hosting provider requesting it be sorted.

David Godfrey wrote:
      Luke wrote:

 On Thu, 21 Jan 2010, David Godfrey wrote:

 Could people please offer their thoughts on the following

The current behavior when opening a new Invoice, Order or Transaction
is to automatically select the last used Vendor or Client.
I have just found a number of Invoices , all on the Vendor side,
that have been entered against the wrong Vendor, presumably the last 
vendor used.
Does anyone think that it would be useful to have a System>Defaults 
option to change this behavior.
Probably to one of....
  Last Used
  A Specific Vendor
 The first and last option would not solve the problem you reported.  If 
they are going to post without checking the transactee, then they'll do it 
regardless.  I can not think of a case wherein I would rather that 
transactions go against a vendor if they are in error, unless it is a fake 
"check later" type of vendor.

The reason I said this, is because it is not really supposed to be 
possible to change the vendor on an existing transaction.  So a check 
later vendor/customer, while potentially useful, would relax accounting 
standards in my opinion, and suggest that transaction editing is not that 
big a deal.
I actually figured that anything found in the Check Later slot would be considered a serious error.
It could be a report that gets run periodically.
It would flag staff that may need additional training.
The actual document would need to be voided and reraised.

I would sooner see a _javascript_ "About to post a transaction for Joe's 
Cable Company; click to interrupt" message pop up for 5 seconds when 
posting an AP.:)

This may be OK in a low transaction volume location,
but even for my use I would find it to be interruptive,
so a high volume site may be unhappy with a popup option.
Aside from that with most browsers defaulting to "block popups"
it could be an issue for non technical users.
 (have to teach them how to config browser)

The middle option, which would force a manual selection, would be the 
most useful alternative to last-used, I would think.
      I agree Luke,
      Blank certainly seems to be the best thing from a "get it
      right" perspective.
      Although there are bound to be people that would like to
      retain the current behavior.

I have never had much of a need for the current behavior: it is rare that 
I generate two of the same thing, for the same customer/vendor, at one 
time.  On the other hand, if you are a government contractor, with only 
one customer except for rare exceptions, the "last-used" or "default-to" 
options do have their place, so I would like to see at least one of them 
available if anything makes it into the main release as a result of this 

      Point taken, System default,
      with a User Default that can be overridden by the System
      if a System Wide check box is set.
I have spoken with Chris T about this,
a system default is doable, but User Defaults are not an option with the
existing code.
Post 1.3 this will change, but for now System Wide is the only option.

The way I would imagine having to do it, is to have a table which tracks 
user ID, last-used vendor, last-used customer, use-vendor (0 or 1), 
use-customer (0 or 1).

The modification would be, when the user enters an AP/AR document, if 
"use" is TRUE, pull the vendor/customer from the table.  If it is FALSE, 
use the system default that would normally be used, which currently is 

In system defaults, a TRUE/FALSE selection for whether to operate based 
on users or not.  If TRUE, update all entries to TRUE in the above 
described table fragment.  If FALSE, update them to FALSE.
Alternatively, drop the use-* fields from that table, and just select 
against the defaults table, since in this version, it is an all or nothing 

A modification to this plan, would use the above described table, but make 
the controlling field be a three-way:


If system, see FALSE above.  If user, see TRUE above.  If fixed, a vendor 
or customer or both, will have to be set.  If set, the selection code 
should pull that record always, thus implementing your fixed default 
transactee idea.

Just some thoughts--haven't written any code, obviously, but at least the 
SQL side should be trivial.

This is fairly close to what I had mapped out in my head,
and in principle would work fine.
Unfortunately there is an issue with the way per user defaults are handled in the current code.
This makes it unlikely to be added (per user default) until maybe 1.3, more likely 1.4,
when the User Preferences section has been rewritten.
We can still do System Defaults now though.