Jump to content
Server Maintenance This Week. ×

Advancing Invoice Number


This topic is 5633 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Use 2 fields:

Invoice_Number //Auto Enter Calculation

Case(

IsEmpty(gInvoice_Number); 0; gInvoice_Number + 1

)

g_Invoice_Number //calculated field

Invoice_Number

Now whatever number is first entered in Invoice_Number gInvoice_Number will be set and when you create a new record Invoice_Number will increment by 1, but, still allow the user to change that number.

The problem is if the user changes the number to a lower value you will have duplicate invoice numbers.

Link to comment
Share on other sites

Kevin, I won't question why you want to reset a serial (which can be quite dangerous). But I think you know what you are doing so I would suggest using a global field. If the global field is empty and a User clicks 'reset' then it resets to 1 and continues from there. Otherwise, if reset is clicked, it sets to the global value and continues from there (see attached).

If you instead want to stop a user if the reset global is blank, you can script for that as well. It can be adjusted as you need it.

LaRetta :wink2:

InvoiceNumber.zip

Edited by Guest
Link to comment
Share on other sites

Nope. Don't use this. It breaks unexpectedly. If you create several new records, leave your cursor there (or even if you leave it in another field), change the global amount then click 'Run Serial' it breaks at random and begins a different sequence than it should. Even with a Commit Records/Requests, it doesn't change properly EVERY time I request it.

Baffling.

Well the theory is okay. But I haven't often used Set Next Serial Value [ ] but I didn't expect it to break like this.

Link to comment
Share on other sites

I believe I have isolated the issue to this: We must BEGIN with a Commit Records/Requests as well. Otherwise, if the cursor remains in the global field, FileMaker doesn't recognize the change to the global value.

So add a Commit Records/Requests also as first line of script. I can't make it break if this step is added.

Link to comment
Share on other sites

Did I misunderstand?

"Invoice Number" to be blank when starting, and then have the user input the starting number, after which all subsequent records would increment by 1 and still allow the user to over-ride the data if needed?

Isn't that what it does? I guess instead of setting the number to "0" you could set it to"".

Anyway, I like LaRetta's approach better. It's much simpler, yet, more elegant.

Link to comment
Share on other sites

I may not being specific. If a new record is made it will increment the field Invoice Number by 1. It will start out empty if there were no records to begin with, like a clean database. But if 3 records in the user needs to change it from 103 to 2100, then the very next record will pick up from the 2100 and the new record will show 2101 instead of 104.

Link to comment
Share on other sites

I just want to reiterate again that the problem with this method is if the user changes the invoice number to something lower than the current number you can wind up with duplicates. That's why I said LaRetta's way was more elegant and gave you validation protection.

I've played around with it some, but, couldn't come up with a way to validate the number using this method. Perhaps, someone else has a way to do it?

Link to comment
Share on other sites

Well, Al, I'm truly still not sure what Kevin wants nor why he wants it; we have been given no vision as to the purpose. So I feel we're stabbing in the dark and I would normally never suggest using anything other than straight auto-enter serials. I assume this time, it is manual entry from an outside source's invoice numbers and this allows a method of easing data-entry.

You are correct that the method offers no protections but neither did mine, ie, if invoice number was reset to 2 it would happily comply with no complaint. If Kevin says it's what he needs, who are we to say otherwise particularly since we don't really understand. Understand? :jester:

Kevin has been around enough to know that if he realizes there is still an issue with his method or what you have given him, he'll come back to keep working on it. It appears you've helped him and that's what counts. In meantime, :beer:

Link to comment
Share on other sites

It is just an invoice number and the reason for this field being modifiable, is so the end user has the opportunity to set/start their invoice numbers from where they left off in a previous setup. Rather than having 2 copies of invoice 102. Not to mention the ability to hand enter previous invoices done on paper :) Just trying to allow for it to be easier.

Link to comment
Share on other sites

It is just an invoice number and the reason for this field being modifiable, is so the end user has the opportunity to set/start their invoice numbers from where they left off in a previous setup. Rather than having 2 copies of invoice 102. Not to mention the ability to hand enter previous invoices done on paper :P Just trying to allow for it to be easier.

But it's not easier. That's why we're still talking about it.

None of that is an adequate reason for doing what you're asking to do. Still looks to me like you should be using Filemaker built in numbering.

Why would you EVER want to hand enter a number? The explanation above really does not address this. Your explanation is circular. You're just saying you want to do it because you want to do it.

Link to comment
Share on other sites

This topic is 5633 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.