Search options (Page 6 of 6)

Ditto that for me... some sort of preview before committing the transaction would sure be helpful as I just voided the wrong transaction (accidently clicked the "select" icon just above the one I wanted).  DRAT! 

On a related note, is there a way to print a list of voided transactions, along with the g/l entries?  I think my auditor is going to want to see that at year-end.

Thanks!

Regards,

Chris

I'm not a programmer, so I have no idea if this is trivial or monumental, but I have a background in business analysis so here's some thoughts on how this might be accomplished from a functionality and business process point-of-view:

First, the following changes would have to be made in the screens, tables, and functions:

1.  Add a field to the debtor table called something like "provisional_customer" where "0" equals "No" and "1" equals "Yes."

2.  Add a check box to the customers screen (i.e. when the user hits F2 in the sales quotation entry screen) to show the value in the "provisional_customer" screen.  If the check box is checked, this is a provisional customer.  If it is unchecked, this is a real customer.

3.  Add a field to the customers screen showing when the customer was created.  Of course, this field will be blank for new customers until the record is saved.

4.  Also add the "provisional_customer" check box in the sales entry screen.  That way, when the customer is selected, the screen shows whether this is a provisional or real customer.

5.  Add a checkbox to the customers screen next to the "show inactive" checkbox called "show only provisional customers."  If this checkbox is checked, then only customers who have the "provisional_customer" field set to "1" are listed in the drop-down box.

Here's how the workflow would work:

1.  When users enter a sales quotation for a new customer, they hit F2 to bring up the customer screen.  They enter as much detail as they need to create a new customer and click the "provisional_customer" check box if they're unsure this quotation is going to lead to an actual sale.  If the user is pretty sure the quote will lead to a sale, then they leave the check box unchecked.

2A.  When the user is entering an order, they select the customer from the drop down list.  If the customer isn't in the list, the user hits F2 and creates a new customer, unchecking the "provisional_customer check box because this is going to be a "real" customer  If the customer does exist, the user can see whether this customer is currently shown as being a "provisional" customer.  If so, the user unchecks the box converting this customer to a "real" customer because the customer is now placing an order.

2B.  Optionally, the function for posting sales orders could be modified to check whether the value of the "provisional_customer" field is "1" and, if so, flip it to "0" because the provisional customer is now placing an order.  This would automate debtor_master table maintenance somewhat.

3.  From time-to-time, a user can go into the customer screen, click on the "show only provisional customers" check box, and clean out any customers who's status is "provisional" when it should be "real" because they actually placed an order.  As well, the user can delete any customers who received a quote and didn't place an order by viewing the record creation date.  If in doubt, the user can use the sales inquiry function to verify whether the customer has placed an order.  Whether or not to delete the record would be determined by the company's policies (e.g. if the customer hasn't placed an order in one year).  Optionally, adding a printed report to list only customers who's status is "provisional" would be helpful to the user in seeing who's "provisional" and who's not.

This is a bit messy and, again, might be a lot of programming effort to do, but I think this might be a way of "cleaning out the clutter" from the debtors_master table.

Thoughts?  Suggestions?  Improvements?

Regards,

Chris

Uhhhh....  I think I may have figured out what's happening, although I haven't a clue why it's happening or how to fix it.  It looks like for payment type "cash" it's taking the due date from the invoice date of the previous invoice.  Here's a couple of examples of what I mean:

Invoice # 109 has an invoice date of 2012/04/15, terms of "first day of next month", and a due date of 2014/05/01 (correct!).

Invoice # 110 has an invoice date of 2012/04/17, terms of "cash", and a due date of 2014/04/15 (wrong!).

Invoice # 111 has an invoice date of 2012/04/28, terms of "cash", and a due date of 2014/04/17 (wrong again!)

I haven't done that many direct invoices, but I've checked them all and it's consistent that whenever the payment terms is set to "Cash Only" (which has a payment type set to "Cash" in the setup) FA always sets the due date to the invoice date of the previous invoice not the invoice date of the current invoice.

Hope that helps you track down the solution  Thanks again for your help!

Chris