Batch operations without UUID

1

This has been discussed in many threads but I could not find a thread or idea specifically about it.
The closest was this locked thread

or

Thinking about it, the challenge I see is:

  • linking requires a unique identifier

  • if that identifier is user entered, the implications for an individual business when not doing batch operations depends on the users / physical businesses normal work flow and how they normally use that field.

A solution is to:

  • only enforce identifier uniqueness during a batch operation which uses that field to link records

  • Allow users to choose which field is used to link records during batch operations. Where Key would always be valid but other options like Code or Name or Code - Name etc would depend on if that identifier was unique for that Manger business at that time.

The link field options could be user selected when the user initiates a batch operations but before they click on the copy to clipboard button. The field header would then reflect their choice. For example when doing a batch update of a sale invoice, a link to a customer is required

  • Currently it is labelled Customer and contains the customers UUID

  • The equivalent options would become Customer - Key and contain the customers UUID

  • Alternatively the user could choose to link the customer via their name, resulting in a field labelled Customer - Name which would need to contain the customers exact name with the option being available only if customer name was unique in this Manager data file

  • Alternately the user could choose to link customers via their code, resulting in a field labelled Customer - Code which would need to contain the exact customer code, again only available if that was unique for that Manager data file.

  • Alternately the user could choose to link customers via their code and name, resulting in a field labelled Customer - Code - Name which would need to contain the exact customer code, space hyphen space Name, again only available if that was unique for that Manager data file.

  • or other field / field combinations that make sense to a significant portion or the Manager user base for each linkage.

Lubos has probably already identified a good solution so this idea is redundant but thought there maybe some value in discussing how various solutions would impact on the work flow of different businesses.

2

Thank you for opening a discussion about this.

I feel this will be difficult to implement in a short time. Adding this feature will change the system design that is already running, and will be very risky to business data that was running before this feature was implemented.

Before this feature is implemented, the system must begin to establish rules for master data in stages.

As a first step, the system must be able to provide a warning to users if there are duplicate Master Names/Code in their data, and ask users to replace/correct all Master Names that are not unique.

Simultaneously with this step, system must have added Name/Code Validation to the Form used to create a new/alter Master.

Batch operations without UUIDs can only be implemented if the rules for using Unique Names/Code in Master data are already running in the system.

The master I mean above is :
Inventory Item, Non Inventory Item, Regular Account, Tax Code, Control Account and Accounts therein.

3

Most objects have either Reference or Code built-in fields. So those are obvious candidates.

The way it will be implemented is that UUID will still be accepted but the system will also accept either Code or Reference if it can find the match.

1 Like
4

Just thinking out loud. So when a Batch update is done with a linked record, how should Manager populate the link?

A possible way to make it human readable is

  • Populate it with: UUID (Code Name)
  • Users are then informed what the UUID actually links too
  • When reading the record back in, Manager would find the Key / UUID first and could ignore the later text

Btw I don’t have a strong opinion as

  • When creating records or making new links, a look up table will be required anyhow to ensure an excact link is reliably created (without typing errors).
  • However it would be nice to make batch updates links more readable when searching / editing in a spreadsheet. Which perhaps means that Manager should populate links using: Code Name (UUID)
5

Thinking some more, the functionality I would like added to batch update is

  • for link fields viewed in a spreadsheet program: the ability to sort in a human useful order and search for human useful terms. For me that means starting the link field with Code/Reference < separator > Name. For database elements without a Name use Description or maybe Date Customer/Supplier.

  • For reading batch update data back into Manager using the UUID directly is the most specific so should be be included at the end of links generated by Manager and used in preference when reading data back into Manager. Where a UUID is not found by Manager when reimporting data/links then looking for another mostly unique identifier such as Code/Reference could work.

Good error reporting and handling would be required to ensure reliable results give the human factor. Such as:

  • handling of link record not found (ie no matching UUID or Code/Reference)

  • reference not unique (Code/Reference used and links to more than one record)

  • differences between returned link and Manager’s normal link e.g. user just entered a Code/Reference or user just entered UUID or user entered a UUID and none matching Code/Reference Name)

Not sure if my perspective is different to other users nor if it is readily coded and fits into Managers wider development plans.

6

Let’s make it simpler, but still can be handled by the system.

The end result is how in the Batch Create/Update process the user is not faced with the UUID.

For this reason, we must be able to ensure the key in every data entry, both in the Master and in the Transaction.

In Master, because we have Code and Name, the system must be able to ensure that there are no duplicates between Name vs Name, Code vs Code, and Name vs Code.

In Transactions, the Key can be Date - No Reference, the system must be able to ensure there are no duplicates based on this Key.

With this key, it will be easier for users to make transactions without having to know UUIDs which are difficult to remember, and the system will know that if the Key is not found it will be considered Create, and if it is found it will be considered Update.

When the system can ensure this, not only is it easier, but the system can also automatically create masters that are not yet in the database.

What needs to be created at the beginning is how the system will identify that Name, Code and Date, Reference are considered duplicates and create special rules in this case. Because there are many possibilities for how users will write it. Will uppercase and lowercase letters be considered the same, will spaces and punctuation be compared, and so on.

7

@Mabaega, I have no idea what you mean by master. Please use terminology from the program.

No it cannot. There are often multiple transactions of the same type, even with identical amounts, on the same day.

8

Yupz, date should be combined with a Reference, in a Transaction, like we have now.


[
  {
    "Key": "ba2dde0d-220b-4ea2-9900-dcdc0ae22868",
    "Name": "1 — 11/09/2023",
    "Timestamp": 638363057834673900
  }
]

Field Name, should be Key for user side in Transaction