Invoicing Tip 
Author Message
 Invoicing Tip

I suppose everyone has had a look at the sample Tutorial app with cw - a small order
entry program, with order header and detail list box, the problem with the app is that
if you add a new order - fill in the header details and add detail information then
decide to cancel - the header information is not saved - but the details list has already
been committed (which i think i should be) - any way in real life this is not acceptable -
as i write quite a lot of Invoicing and billing based programs - the fix is as follows

In the update Invoice, Bill, whatever procedure insert the following code -
at 'End of Procedure before Closing Files' embed - adjust variables to your own needs.
------------------------------------------------------------------------------------------
if LocalResponse = RequestCancelled and LocalRequest = InsertRecord ! we dont want to delete Details if there only edited
Clear(DET:Record) ! Clear the details rec
DET:InvNo = HEAD:InvNo ! Assign the Header Invoice No, Which is the Primary link to the child Details Invoice No.
Set(DET:InvNoKey,DET:InvNoKey) ! Setup Detail Invoice No Key for Processing
Next(DETAILS) ! Next details record in loop
Loop Until Errorcode()=33 or DET:InvNo <> DET:InvNo ! Loop until end of records that match inv no
Delete(DETAILS) ! Get rid of records
Next(DETAILS)
 End
   End
-------------------------------------------------------------------------------------------

Now when you add an invoice header and add line items - then decide to Cancel - this little bit
of code will clean up those Line Items.

Hope this helps someone.
Chow
Peter Purton



Sat, 26 Jun 1999 03:00:00 GMT  
 Invoicing Tip

On 7 Jan 1997 12:38:55 GMT, Peter John Purton

Quote:

>Now when you add an invoice header and add line items - then decide to Cancel - this little bit
>of code will clean up those Line Items.

Thanks for the tips Peter. The REAL fun, is tracking CHANGES that were
made in line items, then they press CANCEL<g>. What I resorted to was
filling a queue (with the same record structure as the line item file)
with all of the line items when the invoice form is opened. If they
press cancel, and changes were made in the line items, I call a
function that purges ALL of the line items then re-fills them from the
queue. Not as elegant as it _could_ be, but it seems to be quite
reliable. This way, I don't have to worry about WHICH records were
changed, I just purge them and restore them from the queue.

-Jeff

Jeff Slarve  [Team Topspeed(CW)(Compuserve)]
(CW2002, DET 2.2, RPM, PwrBrw, CPCS, PDLookup, UlTree, G-Reg, etc.) Since 1991
J & S Software Co.  http://www.deltanet.com/users/jslarve
(CIS: 73501,1323) Using Agent .99g and loving it!



Sat, 26 Jun 1999 03:00:00 GMT  
 Invoicing Tip

Quote:


>>Now when you add an invoice header and add line items - then decide to
>>Cancel - this little bit of code will clean up those Line Items.

>Thanks for the tips Peter. The REAL fun, is tracking CHANGES that were
>made in line items, then they press CANCEL<g>.

Well, the way I fix that is by not letting the users press Cancel! <grin>

No, seriously, it's not a good idea to allow a series of transactions to be
entered and un-entered that easily, and especially not when the application
is used in a commercial setting.

Even before the invention of computers, good accounting practices have
required that transactions be committed - on paper if not on disk.
Computers haven't removed this requirement, since the basis for it isn't
neatness but security. Imagine a dishonest clerk filling out an invoice,
collecting cash, and pocketing the money after pressing the Cancel button.

I commit transactions as they are entered, but I let users modify them, of
course.



Sat, 26 Jun 1999 03:00:00 GMT  
 Invoicing Tip

The tip you provided is great; however, it's only half of the story.
What if the primary key is not auto-incremented (in other words, the
user enters, say,  the invoice number) and you add child records based
on that field.  Now go back and change the invoice number to something
else and enter more child records.  What happens then?  I have been
trying come up with some sort of template work around for just such an
occasion because most of my clients enter their own primary keys (i.e.
Physician Codes associate a physician record.)  See my point? :-)

Shawn Simmons
Medical Data Systems, Inc.



Sun, 27 Jun 1999 03:00:00 GMT  
 Invoicing Tip


-->
-->The tip you provided is great; however, it's only half of the story.
-->What if the primary key is not auto-incremented (in other words, the
-->user enters, say,  the invoice number) and you add child records based
-->on that field.  Now go back and change the invoice number to something
-->else and enter more child records.  What happens then?  I have been
-->trying come up with some sort of template work around for just such an
-->occasion because most of my clients enter their own primary keys (i.e.
-->Physician Codes associate a physician record.)  See my point? :-)
-->
Hum, you should NEVER, NEVER, allow user entry on a primary key. Let them BELIEVE it, but
don't do it !

Bernard Grosperrin - ALIAS(Bernie) -Team Topspeed Internet



Mon, 28 Jun 1999 03:00:00 GMT  
 Invoicing Tip

Quote:
>Hum, you should NEVER, NEVER, allow user entry on a primary key. Let them BELIEVE it, but
>don't do it !

Good call Bernie,

For anyone else out there, I have found the easiest way to achieve all
of this is:

(1) Allow the user to define their own code field as a separate field
to the primary auto-incremented field.
(2) Key related parent-child data on the in-built auto-incremented
field, such that client --> client transactions.
(3) Key the parent file on the user-defined field, so this works in
locator-type situations on browse boxes. Use this user-defined field
on related reports, so the user *THINKS* that everything is based on
this.
(4) Do *NOT* allow any child transactions to be added until the parent
has been okayed and is written to file. I am sure many will disagree
on this one (there are even times when I break my own rule). To
compensate, I often embed a bit of code at the Insert handler to drive
the user straight into an account table for the newly-setup client.

This method ensures that you can never get a divorced child record,
which in my case would lead to a complete catastrophe since most of my
later reports start with the all-containing ACCOUNT file, and then
track backwards to a guest, owner, agent or creditor.

Hope this helps
--
Steve Greenwood
HiCaliber Software



Mon, 28 Jun 1999 03:00:00 GMT  
 Invoicing Tip



Quote:
> Le Wed, 08 Jan 1997 22:50:31 -0500, "Shawn P. Simmons"


Quote:

> -->
> -->The tip you provided is great; however, it's only half of the story.
> -->What if the primary key is not auto-incremented (in other words, the
> -->user enters, say,  the invoice number) and you add child records based
> -->on that field.  Now go back and change the invoice number to something
> -->else and enter more child records.  What happens then?  I have been
> -->trying come up with some sort of template work around for just such an
> -->occasion because most of my clients enter their own primary keys (i.e.
> -->Physician Codes associate a physician record.)  See my point? :-)
> -->
> Hum, you should NEVER, NEVER, allow user entry on a primary key. Let them
BELIEVE it, but
> don't do it !

To expound further:  

Your Physician Code is a key, but it's NOT the primary key.  It may be a
key the users frequently look up physicians by, and it may be a key you
order reports by, but it's NOT the primary key.

--
Tom Ruby
--------------------------------------------------------------------

http://www.netins.net/showcase/tomruby/
I don't know anything.  I just have to make this stuff work.



Mon, 28 Jun 1999 03:00:00 GMT  
 Invoicing Tip


Quote:

>Hum, you should NEVER, NEVER, allow user entry on a primary key. Let them
>BELIEVE it, but don't do it !

I'm fairly unexperienced with database developing. Can you explain why
not? I'm developing a database where two fields (a name and a year)
makes the unique primary key. These are unique in real life too. Why is
it bad to do it this way, and how do you think I should do it? I'm
using CW 2.002.01 pro, which btw makes the job more easy than I would
have dreamed :)

--
Win95 - Beauty's only screen deep. [TEAM OS/2]



Tue, 29 Jun 1999 03:00:00 GMT  
 Invoicing Tip

Quote:
>> Hum, you should NEVER, NEVER, allow user entry on a primary key. Let

them BELIEVE it, but don't do it ! <<

Agreed, but the 2002 examples modify the primary keys, no?



Thu, 01 Jul 1999 03:00:00 GMT  
 Invoicing Tip

Quote:

>>Hum, you should NEVER, NEVER, allow user entry on a primary key. Let
>>them BELIEVE it, but don't do it !

>Agreed, but the 2002 examples modify the primary keys, no?

Besides, what's supposed to be the problem with users entering primary
keys? What rules of programming or database design does it violate?


Thu, 01 Jul 1999 03:00:00 GMT  
 Invoicing Tip

Just to add my two cents worth...

The short answer is because using user-editable, or changeable values
for primary key fields creates a lot of extra work to keep all the
data in related files correctly related.

For example, what if a user changes the spelling of the customer -
which subsequently changes the value of the primary key - you then
have to update all the related keys in the child files - could be a
lot of work - is a prime candidate for errors if a system crashes
midway through etc.

I always use LONGS for primary keys - makes it easy to relate all
child files to parent.  The key should be uniquely assigned - how is
up to you - CW's autoincrement is a safe bet in 95% of cases.

If a client wants some other code for internal use then that becomes a
second field in the file which can be displayed, keyed, searched, or
whatever, whenever the client wishes - but it should never be used to
link the data to another file - use the LONG field.  The availability
of the droplist and drop-combo fields in CW make it very easy to
display the string field, but use the primary key to link files.

eg.

Department file
Dep:DepartmentID              LONG,Primary key,Autoincrement
Dep:DepartmentCode       STRING - let the users do what they want
Dep:Description                  STRING - for meaningful explanations


Quote:


>>Hum, you should NEVER, NEVER, allow user entry on a primary key. Let them
>>BELIEVE it, but don't do it !

>I'm fairly unexperienced with database developing. Can you explain why
>not? I'm developing a database where two fields (a name and a year)
>makes the unique primary key. These are unique in real life too. Why is
>it bad to do it this way, and how do you think I should do it? I'm
>using CW 2.002.01 pro, which btw makes the job more easy than I would
>have dreamed :)

>--
>Win95 - Beauty's only screen deep. [TEAM OS/2]

    Geoff Bomford
     ComForMark
  Sydney, Australia


Thu, 01 Jul 1999 03:00:00 GMT  
 Invoicing Tip

Quote:
>Hum, you should NEVER, NEVER, allow user entry on a primary key. Let

them BELIEVE it, but don't >do it !

So I Should create a completely new auto-number field (hidden from the
user) as a primary key?  Doesn't
sound like very goo database design.



Thu, 01 Jul 1999 03:00:00 GMT  
 Invoicing Tip


-->This method ensures that you can never get a divorced child record,
-->which in my case would lead to a complete catastrophe since most of my
-->later reports start with the all-containing ACCOUNT file, and then
-->track backwards to a guest, owner, agent or creditor.

Good tips, Steve, and thanks.

Bernard Grosperrin - ALIAS(Bernie) -Team Topspeed Internet



Thu, 01 Jul 1999 03:00:00 GMT  
 Invoicing Tip

Quote:
>Try this, call up the header record and when entering new child records put them
>in a temporary memory queue, rather than a database.

>When the operator saves, then dump the child memory queue into the database
>using the information in the then current header.

>This method could have a few problems with multi user but there are work arounds
>for that.

The biggest problem with this is that there are no standard templates
from CW to accommodate it.  There are 3rd party tools (like my
SuperInvoice) which do this memory table work, but it's not very easy
to hand-code.

Catch you later!

-=> Mike Hanson, BoxSoft <=-



Thu, 01 Jul 1999 03:00:00 GMT  
 
 [ 28 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Invoicing Tip - Response to P. Simmons

2. Invoice total on last page of invoice only

3. Block handling tips (was : File handling tips )

4. Tips.Tips Introduction

5. TIP #13: Web Service for Drafting and Archiving TIPs

6. Printing an invoice?

7. Record order in browse box using Super Invoice

8. Need Template for invoice screen

9. Please Help! Printing Invoice

10. Invoice template for Word

11. Sending ascii invoice via email

12. Invoice printing using Dot Matrix..How?

 

 
Powered by phpBB® Forum Software