generating an invoice number????

[dawilis]

I have an order (Form) page, I need to generate an invoice number, anyone have any suggestions with this, would prefere a external file that the JS loads in adds 1 to number saves new number in file and then sends on the invoice Number to form text box.
Also any one have some nice easy code for cookies or tutorilas

[chrismiceli]

how do invoice numbers work? what is their syntax?

[tommysphone]

you'd be looking at developing a db behind that form to generate the number and store the data.

The js file will see each submission as the first one so will always load the same number to the form - unless someone knows something I don't.

[Philip M]

You can generate an invoice number based on the date and time of day, but of course the number will not be sequential and in theory two customers could receive the same number.

var d= new Date();
var yr=(d.getYear() ) toString();
yr = yr.charAt(3);
var mo = ( d.getMonth() ) toString();
var hr = ( d.getHours() ) toString();
var mn = ( d.getMinutes() toString();
var secs = (d.getSeconds() ) toString();
var ordernum= yr+mo+hr+mn+secs;

[dawilis]

Hi philip your idea was my other thought but lacked the skilles to do it, I seem to be lacking the skills to coorectly implement your supplied code, could you offer help, I keep getting error on page

[whammy]

I'm confused as to what the big picture is.

Are you storing things in a database? If that is the case, you shouldn't be using javascript to generate this information (as tommysphone alluded to).

How are you "receiving" the order? Can you elaborate?

[dawilis]

THe site is a non database site, Its in html and JS only, no ASP or PHP
I get the users details in a form then formmail it to myself, but to get the credit card details I use a 3rd party and they require a unique invoice number hence the problem, they will not process to requests with the same invoice number, I was hoping to use a txt file to load a number, add 1 and then save it, but that seems hard to do, so generating a number based on the date time and secs sems suitable.
Hope that clarifies the problem
daz

[krycek]

well you are going to have to use a server-side language in any case, as JavaScript cannot access text files like you are wanting. You will have to consider PHP or ASP, and then you could choose a flatfile solution (like you have said) or else a database.

To be honest, with what you are describing you REALLY nned to be using a database system :)

::] krycek [::

[whammy]

Well if that's the case, this might help...


function UniqueString(){
var mydate = new Date;
var myday = mydate.getDate();
var mymonth = mydate.getMonth()+1;
var myyear = mydate.getFullYear().toString().slice(2,4);
var myhour = mydate.getHours();
var myminutes = mydate.getMinutes();
var myseconds = mydate.getSeconds();
if(myday < 10) myday = "0" + myday;
if(mymonth < 10) mymonth = "0" + mymonth;
if(myhour < 10) myhour = "0" + myhour;
if(myminutes < 10) myminutes = "0" + myminutes;
if(myseconds < 10) myseconds = "0" + myseconds;
var datearray = new Array(mymonth,myday,myyear,myhour,myminutes,myseconds);
var uniq = "";
for(i=0;i<datearray.length;i++){
for(z=0;z<2;z++){
var which = Math.round(Math.random()*1);
if(which==0){
x = String.fromCharCode(64 + (Math.round(Math.random()*25)+1));
}
else{
x = String.fromCharCode(47 + (Math.round(Math.random()*9)+1));
}
uniq += x;
}
uniq += datearray[i];
}
return uniq;
}


That's about as random and unique as I know how to come up with, just use myvar = UniqueString()! :)

P.S. Krycek is correct... even though the odds against getting the same random number using the technique above are astronomical, I would still use a database, myself.

[dawilis]

Hi whammy this is the number generated
6312DT183602C210DX251G41
is this what is expected?
I dont feel to thretened that this will be duplicated to reguarly

regards
daryl

[krycek]

...have you given some thought to how you will keep track of the invoice number? :)

For instance, you could email yourself the number etc.

::] krycek [::

[whammy]

I doubt that would be duplicated in 100 years or more due to the date stamping that is included in combination with random numbers/letters that are also dependent upon a random 0 or 1... but it is very remotely possible. I think that should do pretty nicely for what you seem to want, though...

Keep in mind I'm also not a statistics expert - but the odds against duplicating anything generated by that function have to be astronomical, I would think.

I'm also assuming (like krycek) that you are emailing this number to yourself, or whatnot.

You'd really be a lot better off using a database for this kind of thing, it's much simpler once you're familiar with relational databases. :)

The solution I posted above is just an extension of Philip M's idea, with a bunch of random numbers/letters thrown in to boot.

[beetle]

Just felt like making a short UniqueString function :Dfunction UniqueString() {
var d = new Date();
var t = d.getTime().toString();
while (/^\d\d\d/.test(t)) {
t = t.replace(/^(\d*)(\d\d[\w\b])/, "$1" + String.fromCharCode(64 + (Math.round(Math.random()*25)+1)) + "$2");
}
return t;
}

[Philip M]

Numbers generated based on time cannot possibly duplicate unless two orders are submitted at EXACTLY the same time (second), but if that actually happens then Whammy's script will still result in the same number being duplicated, notwithstanding the purported random element (as I understand it the random number stream is in fact pseudo-random).

Unless you expect a huge number of orders, it is sufficient to generate an order number which is simply the time converted to a string, without any further complication by introducing randomisation. If you really want to be 100% certain of no duplication then the number can include something based on the customer's name (say the first two characters).

e.g. PH181202183328 (18/12/02 at 18:33:28)


The idea is not to generate an order number which is so fiendishly encrypted that no-one can deduce or unravel it, but rather to create a number (even a quite simple one) which is unique to that transaction.

I see I left a bracket out of my last post, which doubtless accounts for the runtime error -

var mn = ( d.getMinutes() toString();

Should read

var mn = ( d.getMinutes() ) toString();

[krycek]

Philip: I agree with you about the invoice number in that it shouldn't necessarily be horribly difficult (unless that is a specific requirement) and I also agree that putting something to do with the customer's name in it would be a good idea.

Now, that does reduce the possibility of duplication even more, to the point where you might say it is impossible.

However I have to disagree with your statement about random numbers: yes they are psuedo-random in that they are generated by a computer, but if I have followed you correctly and you are saying that the number generated would be the same, you are greatly mistaken.

Firstly the number would be generated on the client's machine (remember, we are using JS here :)) which means that there is no possible link to another client's number, and also even if there was, random numbers are called random numbers because to all intents and purposes they are exactly that: random! In the way that they cannot be predicted.

Random numbers fall into that category of statistics that is called chaotic/complex: weather is not random but it is extremely hard to predict with accuracy, and likewise you could argue that nothing in the universe is truely random - there are reasons for everything (no comments on quantum theory here please, because even that is not truely 'random' :D)

So, whammy's script will be far less likely to be duplicated than yours, statistically. However I do agree that yours is arguably a more usuable method because it makes more sense when you read it.

::] krycek [::

[whammy]

Nothing too "fiendish" about the one I made... just take every second pair, and that's a time string... everything else, however, is double random... first I get a 0 or 1, then depending on that, I pick either a random number or letter...

6312DT183602C210DX251G41

(as the example) would have this datetime string:

121802102541

Which is December 18, 2002 at 10:25:41 AM ;)

That's also helpful to know when the order was placed (at least by the client's time). As for duplicating the 12 character doubly random string, AND the time string - the odds of that have to be astronomical (meaning higher than I can count, at any rate!).

[beetle]

Indeed. If my calculations are correct, whammy, your random string has 3,379,220,508,056,640,625 possible variations each second. Percentage speaking...18 significant digits are needed to reach the first non-zero decimal.

[krycek]

Originally posted by beetle:
....3,379,220,508,056,640,625... ...every second...


hehehe I wish I could have that many customers that I got a duplication! :D:D:D

::] krycek [::

[dawilis]

thanks for all your help so far, would you help me insert this code into a form textbox, I have inserted the code into the body section of the page and can call it with
<script type="text/javascript">
document.write(invoice)
</script>
I want to insert the number into a textbox in a form and seem to be having a bit of difficulty here also.

[Philip M]

Krycek -

Yes, you are absolutely right, because as you say

"the number would be generated on the client's machine (remember, we are using JS here) which means that there is no possible link to another client's number"

but if the random number stream was generated on the server
then if two persons accessed it at EXACTLY the same time then they would presumably receive the same random number - which number I agree would be unpredictable.

I still feel that introducing randomness is overkill in this context - so how many orders does he expect??? As I say, a number simply derived from the date/time (to the second) would probably be adequate and in practice never duplicated, but to make 100% sure then add a couple of characters from the customer's name. If two Smith's place an order at EXACTLY the same time, that is of course possible, but in the real world so unlikely as to be not worth bothering with, unless you are expecting hundreds of orders a day.

With my suggestion the assigned order number can be easily read and interpreted for what it is.

Randomness is funny - we ship about 25 orders a day, but at least twice recently I have noticed that the customer's surname on two quite different consecutive orders was the same, and not common names either.

Instead of or as well as the customer's name you could use the customer's postcode (not encrypted) as a prefix or suffix. E.g.

PH021219184432SW

THAT (three variables) ought to be absolutely beyond duplication.
As I say, this order number is human readable.

[krycek]

Philip:

firstly, remember that this is being generated on the client-side, with JavaScript :) If it were possible for dawilis to use a server-side language, there are better ways of doing this task :)

second, even if two orders were created at EXACTLY the same millisecond, the random numbers created would not be identical. Or rather, the chance of them being identical would effectively be a power of the number of combinations.

That is the whole point of the number being called 'random' :)

::] krycek [::

[Philip M]

"If it were possible for dawilis to use a server-side language, there are better ways of doing this task".

Well, yes.

Then his order numbers could be 1,2 3 etc. in sequential order.

I am afraid that I am unable to see the point of encrypting or randomising the assigned or calculated order number, however derived.

[krycek]

um, the number wasn't being encrypted.

It was randomised to ensure that it would be unique.

::] krycek [::

[Philip M]

We seem to have got some way off the point.

Would some kind person care to write down some code which dawilis can incorporate in his form?

As I see it we need more info -

Is the idea that the customer fills in an order form,
and an order number is assigned - WHEN? After the credit card details have been entered (and presumably verified)?

The order number to be placed in a textbox (read only) so that the customer can print off a copy of the form? But there is nothing to say that the form was actually submitted.

As has been pointed out, you really need to do this using a server side language to avoid all sorts of complications and weaknesses.

[whammy]

I actually agree... if it was me, I'd use the primary key of a database with a bunch of zeroes stuck on the front as an order number or something.

Like (in ASP/VBScript):

OrderNumber = Right("000000000" & MyPrimaryKey, 9)

:)

As for doing something like this in javascript, I just threw that thing together from a couple of other scripts I saw awhile back as an experiment when I was bored, but if beetle's calculations are correct (which I'll take at his word ;)), that should be pretty sufficient client-side if you don't mind the "encrypted" look of it. ;)

Philip M has a valid point that it's not very readable... true that you could probably use date/time and a combination of something from a user's name or postal code, but that's still easier to duplicate (and therefore more likely), especially considering the fact that the time on user's machines will in almost all cases be different - which means someone could come in earlier or later depending upon where they are at and how accurate their time is, and duplicate the time string, at the least.

Then if they happen to have the same first and last initials, and postcode (which is not uncommon), you have a duplicate. :D

I guess it all depends on how worried you are about duplication, but your best bet (again) if you want to avoid duplication is to use a database, that way you can check against the database to make sure the order number doesn't already exist, in the event you're not using a primary key. :)

Hey, at the worst though the random number generated is no worse than a UPS tracking number. :D

But I digress - really the odds against duplicating the number Philip M was using as an example, with

[FirstInitial][LastInitial][TimeString][PostalCode]

would probably be fairly high as well (and likely not duplicated on a site that doesn't have a lot of users, especially from the same locale). But not as easy to calculate since the odds of the first two and last variables' commonality are an unknown factor.

[whammy]

P.S. Oops, he's still asking for help. As an example of how to insert the function I was using, here you go... hope this helps:


<html>
<head>
<script type="text/javascript">
<!--
function UniqueString(){
var mydate = new Date;
var myday = mydate.getDate();
var mymonth = mydate.getMonth()+1;
var myyear = mydate.getFullYear().toString().slice(2,4);
var myhour = mydate.getHours();
var myminutes = mydate.getMinutes();
var myseconds = mydate.getSeconds();
if(myday < 10) myday = "0" + myday;
if(mymonth < 10) mymonth = "0" + mymonth;
if(myhour < 10) myhour = "0" + myhour;
if(myminutes < 10) myminutes = "0" + myminutes;
if(myseconds < 10) myseconds = "0" + myseconds;
var datearray = new Array(mymonth,myday,myyear,myhour,myminutes,myseconds);
var uniq = "";
for(i=0;i<datearray.length;i++){
for(z=0;z<2;z++){
var which = Math.round(Math.random()*1);
if(which==0){
x = String.fromCharCode(64 + (Math.round(Math.random()*25)+1));
}
else{
x = String.fromCharCode(47 + (Math.round(Math.random()*9)+1));
}
uniq += x;
}
uniq += datearray[i];
}
return uniq;
}
// -->
</script>
</head>
<body onload="document.forms[0].OrderNumber.value=UniqueString()">

<form id="blah" action="somepage.ext" method="???">
<input type="text" size="30" name="OrderNumber" value="" readonly="true" />
</form>

</body>
</html>


P.S. There's a pretty obvious spot in the script where you'll have to fix a line break that was put in by the forum... :)

[Philip M]

Without wishing to prolong this discussion or seeming pedantic,
random numbers are unpredicatble but may well repeat. In other words, there is nothing to prevent a random number having been generated from appearing again - even sequentially in theory - in the stream.

If 12 turns up on the roulette table, then there is nothing to prevent 12 turning up on the next spin as well, and also the next spin after that. Of course, the odds against increase geometrically, so that (say) a run of 12 x 12 is realistically (but not theoretically) impossible.

(NB The lottery is a tax on those poor at maths.)

My point is simply that randomness does not guarantee uniqueness, and I still think that my system of taking the time plus a couple of characters from the name and postcode is as unlikely to repeat or duplicate as a random number. In fact less so, as the time certainly cannot be repeated after the second has passed. And as I say the result is human-readable.

[krycek]

Phil, haven't you essentially just repeated something that I said to you in one of my earlier posts? :confused:

Posted by Philip M:
...if the random number stream was generated on the server
then if two persons accessed it at EXACTLY the same time then they would presumably receive the same random number - which number I agree would be unpredictable.


Wrong.

Posted by krycek:
...even if two orders were created at EXACTLY the same millisecond, the random numbers created would not be identical. Or rather, the chance of them being identical would effectively be a power of the number of combinations.


Right.

Posted by Philip M:
...there is nothing to prevent a random number having been generated from appearing again - even sequentially in theory - in the stream...

...the odds against increase geometrically...


Heheh... right, this time :)

I think you missed the whole point which was firstly that no-one was disagreeing with you that your method is more readable to humans (indeed I supported your method as well as whammy's but it all depends on what dawilis wants) however statistically whammy's is FAR less likely to be duplicated.

True, it remains that the odds of the simple timestamp itself being duplicated are huge, however the issue here was how to ensure a unique-as-possible invoice number without too much trouble. No doubt dawilis will choose the method that suits his/her needs best.

Oh and one other thing... random numbers are not totally unpredictable because like I said earlier, they are statistically chaotic/complex... meaning that if you knew EVERY factor that went into their creation, you could predict them. However that applies to just about everything, and so for all intents and purposes in practice they are unpredictable... so I agree with you ;)

::] krycek [::

[whammy]

I agree with everyone! YAY!!!!!!!!!!! :D

Use a database if you're really concerned (although either of the other solutions should work fine for what you want).

If you want to take this idea to the "next level" as they say on sports channels here in the U.S., check out http://www.webmonkey.com and take some database tutorials. You don't know what you've been missing. ;)

[krycek]

krycek chuckles ;)

::] krycek [::