Creating unique IDs (human readable) for offline solution?

[Justin Close]

Do folks have recommendation on setting up a system for creating regular, human readable and consumable, IDs with an offline/online-sync and hosted solution?

The offline part of the solution allows full creation of new Orders.  These Orders will (should? could?) have an OrderID will be visible to the customer and given to them on an invoice at the time of creation in the offline world.  (The invoice is generated along with the order and will be emailed to the customer, so the OrderID will be there.) 

But someone else in a different offline copy, or someone who creates an Order on the server, will also get OrderIDs that might then conflict with each other.  How do you reconcile these different creation points?

And just using UUIDs isn't a solution; it needs to be something simple that a customer can read off; 6 digit number or some such.

Maybe a prefix for each device/salesperson?  Maybe try to create and control blocks of IDs that go to each device?  Maybe a temporary ID somehow, e.g. a 'purchase order ID' for the offline generated items that then gets translated to a full OrderID when they sync to the server?  Then the customer would have an invoice (guess it would be a P.O. now) with one number and an invoice with another.  Seems a bit confusing.

Anyone have something they have successfully used?

 

Thanks,

Justin

[Agnes Riley]

You generally use an intermediary table for these situations. You can use a temp order table that gathers the orders from all the mobile devices then they go to the Orders table based on timestamp and they will get a new order ID. If you want you can store the original ID, who created the order and the original timestamp, just in case there are questions later. The customer should get notification from the order once the order is in the ORDER table, not when it's on the mobile device. 

Hope this helps,
Agi

[comment]

Maybe a prefix for each device/salesperson?

I believe that would be my preference, based on the very little you have told us.

 

Then the customer would have an invoice (guess it would be a P.O. now) with one number and an invoice with another.  Seems a bit confusing.

Assuming all invoices eventually end up in a central repository, and even assuming that they are assigned a new "central" ID when ingested (which may or may not be necessary), this ID would come in addition to the original ID generated in the field - and there's no reason why the customer should ever need to see it.

 

 

Edited August 25, 2015 by comment

[Justin Close]

Assuming all invoices eventually end up in a central repository,

Yes, they all end up back on the server eventually (within a few hours or a day most likely).  The salespeople are out driving around, visiting potential clients - they are selling ad-space.

 

and even assuming that they are assigned a new "central" ID when ingested (which may or may not be necessary), this ID would come in addition to the original ID generated in the field - and there's no reason why the customer should ever need to see it.

Yes, I think a TempID and FinalID, both persistent, is a good idea.  But wouldn't you want the customer to have the OrderID?  They could have multiple Orders over time.  Makes them feel more...secure or certain? 

The idea was to generate all this on the iPad, have the customer sign it even, and give them a receipt/invoice of their Order all at the same time.  Immediacy, not having to wait for other processes, etc.

 

 

Edited August 25, 2015 by Justin Close

[comment]

Yes, I think a TempID and FinalID, both persistent, is a good idea.  But wouldn't you want the customer to have the OrderID?

I am not sure what you mean by that. If you want the sales person to give the customer a document at the time of the sale (i.e. while still offline), then of course the customer will have the "temp" ID as their reference. I put "temp" in quotes, because as long as the ID is unique and permanent, it's just as good as any other ID. That's why I expressed doubt at the need for an additional "final" ID.  If you do introduce it, you must make sure that the head office is equipped to handle customer's inquiries referencing the "temp" ID.

[Justin Close]

Ah, I think I get what you were originally saying:  the customer sees the initial ID generated in the field, and perhaps not the one generated by the central system.

But as you were also saying...then why need a new central ID?  Erm...guess it doesn't really matter if there is a new CentralID as long as the ID generated in the field is unique and human readable.  If it's unique across the system, including other offline, in the field generated numbers, then it solves the problem.

That's the real root of the question - how to generate those numbers and keep them unique?  I believe the idea behind the Central ID is that it is THAT one that is unique across the system, and the one generated in the field is replaced with it.

This system is replacing old paper forms.  Those forms were preprinted with IDs on them.  So as long as you told the printer what ID to start from, you were OK. 

[comment]

If each device generates an auto-entered serial number, and each system has a unique string identifying the device, then these two together will be unique system-wide. You have several choices regarding the device-specific ID: if you oversee the installations, you could add a unique prefix directly to the auto-serial number; otherwise use a separate field and auto-enter something that depends on the login, e.g. UserID.

[TrulySimple]

I use a temporary or mobile Inv. No that is the Empl. No - Record No - Deployment No.  The id is a numerical UUID not seen by the user.  The record syncs with the server.  The data file on the server uses a readable serial number that the admin user can set a new starting no. in preferences.  An option I have considered is on the sync routine to simply replace the temporary mobile invoice no. with the Server InvoiceNo field thus another visual that the record has been synced, though we have a filed we set for this that shows conditional formatted "SENT" on the mobile invoice record.