The identification (UUID) columns of Customers, Suppliers, Employees, Inventory items, and Bank And Cash accounts columns cannot be found on Batch Create spreadsheet templates.
Batch updates contain the columns.
Experienced users can easily resolve this by inserting a copied column of related accounts from a Batch update spreadsheet template. New users on the other hand struggle with it.
The screenshot below shows the template for a Batch create (has no column for ReceivedIn bank account) and a template for a Batch update (of course has a column for ReceivedIn bank account)
Columns for UUIDs of related accounts (Customers, Bank Accounts, Suppliers, Employees, and Inventory Items) must be provided by default in Batch Create Operations.
I just noticed today in PaySlips with the cloud version of Manager. The cloud version is always the latest version. When I tried to use Batch Create, I saw no column in my spreadsheet to specify the employees. Where to specify most other parts of the payroll entry was confusing and obscure.
However, when I tried pasting the new entry, it “worked.” Except that after creating the entries in the spreadsheet and pasting it into Manager, I needed to edit the entries in Manager to specify the amounts and employees. I imagine that @lubos had to leave the batch create in the middle of an improvement to work on higher priority parts of Manger. I see Manager has several improvements that I agree are higher priority since, as @Abeiku said, you can use Batch update to get all the columns.
I see batch create and batch update have a lot of overlap. I would suppose that, ultimately, batch create and update could be merged into one operation with some way to specify whether the intent is to create new entries or edit old entries. Maybe leaving out the record GUID would be the way to indicate you want a new entry.
@lubos usually produces a solution that works better than ideas I have had in the past.
I would defer to @lubos whether it is technically feasible given the organization of code in Manager. I know that it is quite easy for a program to tell whether it is receiving 50 or 51 columns in a tab-delimited table received via a clipboard paste. If a paste row has a UUID, then the program might use a SQL Update. And if a row is otherwise valid but lacks the UUID, then the program might use a SQL Create. That means it is technically feasible.
But I suppose there are other considerations whether combining would be a good idea.
No it is not. The absence of UUIDs in a particular column or the count of those present and zero does not mean that SQLIte can handle completing such information and assing UUIDs for empty cells without even verifying the existing ones in the same table and column. I am looking forward to a code example by you where you manage that in any database design.
OK. I did not realize that @lubos is using SQLite. And I don’t know SQLite. But doesn’t @lubos need some other language such as C# or Java for the browser-based graphical user interface?
You are right in terms that SQLite does not have features that support UUIDs. There are no UUID-specific column types or storage classes. I do not know if he uses Java UUID class or C++ (Cpp) uuid_generate, but they would need to write to an empty “column” and can not add new UUIDs to already existing ones as it would not be able to recognize these as SQLIte does not know a UUID class. So the only option is to add a new column with whatever class that gets populated through any UUID generating code that just will created for each line a UUID.
Imo that is a very bad idea as batch operation are very powerful which mean they can very easily be used to accidentally make very extensive incorrect modification to a data file.
The current program structure at least ensures only one class of modification occurs at one time.
This is all off topic for this thread though.
This thread is about which fields should be listed in the batch create template. In deciding this “all” is not a useful response because
the variable number of lines Manager transactions allow with the maximum far exceeding almost all users requirements. So listing all possible line fields would be a poor solution.
Many fields are supported but not used by most users (analogous to Mangers csv import where different valid combinations of input fields are allowed but all is almost never applicable)
The fields required for any particular transaction can be trivially displayed by manually entering example transactions via Managers build in GUI then doing a batch update to see full details of the format require for subsiquent batch create.
I did a test. I tried doing a batch update copy to clipboard, then pasted to Excel. I took just the top two lines (the headers and a transaction. I reversed two columns and changed the date. So, that means the columns are now out of order. Then, I pasted the header row and the following line without the UUID into the Batch Create. It worked just fine to create a new transaction.
From the previous experience using batch create only, the copy to clipboard does not copy all the columns anymore. But it works for creating a new transaction, even with not all transaction columns filled in.
This is very robust. Having all the columns or not works. Having the columns in a different order works. No errors. It just works. I think you would still need the UUID to update instead of create.
And then I noticed that in History, you now have filtering, and I imagine you have had filtering for some time. Just that I only noticed now. Being able to filter on date would help even more. Being able to batch undo operations would answer @Patch 's concern about accidentally making extensive incorrect modifications. I share Patch’s concern because it is vital to avoid error-prone operations. And I dislike spending hours correcting a mistake that took just a minute.
I feel that Manager does very well at not being error-prone and having features such as History to make it easy to back out mistakes.
It looks like create and update operations are already closer to being merged than before. If @ubos is enhancing these batch operations, the result will probably be far different from what I would have thought and far better.
Yes, Batch Create adds the UUID, then Batch update knows which records you are updating based on the UUID, that is why as @Patch also mentioned kept separate.
You are correct their behaviour is similar.
My understanding is consistency is a design goal of Manager. Which applies throughout Managers many functional areas. The benefit of that approach is training in one area of Manager enhances users skill in another area of Manager.
Now to illustrate what the UUID is doing in batch update it may help to look at the equivalent manual direct entry work flow.
Manual create
go to the appropriate tab
Click in create in that tab to create a new entry
enter data for that new record
Batch create
go to the appropriate tab
Click in Batch create to create a batch of new entries
enter data for each new record, one per line
Import the file result in creation of a batch of new records
Manual update
go to the appropriate tab
select a particular record and click the edit button for that particular record
update the data for that particular record
Batch update
go to the appropriate tab
Click in Batch update
For a particular record uniquely identified by it’s UUID update the data for that particular record
Repeat the above step for each record for which changes are required. Note records not requiring update can be completely removed from the data file if desired, however do not enter blank data with a UUID as that would specify updating that selected record to have blank data in those fields.
Import the file which results in updating the specific records selected by the supplied UUIDs
Note
The selection level is different for create vs update in both the manual and batch create work flow, as they are doing different things with different risks. Sure there is similarly, that is due to good program design.
if you compare the direct vs batch update methods above; the UUID is replacing the users manual selection of a specific record, which is a critical function. Updating a database record without uniquely specifying which record is to be updated is very dangerous as it risks inadvertently updating the wrong record.
It looks like @lubos already implemented the merging of functionality that I had in mind. I tried creating a new entry from Batch Update. And it worked fine. I copied from the batch create, modified the entry, and pasted it back without the UUID. The new transaction appeared without any problem.
I even created and updated in a single paste by omitting the line UUID from the line I wanted to be a new entry. The line I wanted to be updated appeared as modified.
Therefore, not only is merging this functionality feasible, but @lubos already implemented it. @lubos has not changed the graphical user interface yet. But I already saw the functionality.
As in other features, I suspect that @lubos is implementing something far better than I imagined. I was a little foolish for not checking further before posting.
Thank you, @lubos. Batch create and update is already very robust and flexible.
