Batch functions, CustomerID, and Keys. Oh my

I need help! I am having a huge amount of trouble with batch functions for billable time, and their linked invoices and transactions. I am developing a simple python script to take one set of data and make it readable to Manager.

The problem began with with batch functions for billable time: after combing the forums, the guides and everything up to the source code, I still could not find how to match the auto-generated CustomerIDs to actual customer name.

I understand the Keys for each unique row entry do not track from table to table. But auto-generated strings that look just like them are assigned for CustomerID, SalesInvoice, Lines.Account, Lines.TaxCode, Lines.Invoice, Lines.Item, BillingAddress, and probably more. These do track from table to table, but their connection to the human readable data I put into those fields is totally opaque to me, and without knowing how to match them this entire exercise becomes pointless.

How do I do this conceptually basic thing in manager? Right now the only solution I can see is just process of elimination, or recreating the entire manager database from scratch, entering each of those again, and recording what string is generated. Both of those solutions are far worse than the problem…

Otherwise, I love the software and will do everything in my power to promote it and convince my employers to upgrade.


Right now, what you were doing is the only approach. Human readable keys have been promised for the future.

Ok, good to know.

Two follow up questions: I’m sure it’s a total pain to implement throughout the codebase without breaking other things, and I am no expert. Nevertheless, I’m willing to play with the code myself if the update isn’t going to be done this calendar year. So first is, does anyone know where this update sits in the queue?

Second, a solution seems fairly available; creating a separate column, like the custom fields mechanism can, one for each hex-ified column, that duplicates whatever is being encoded into the string beforehand. It seems like a hash value or something, so if something’s being hashed, then can’t you can stick a copy of the prehashed string in an otherwise non-operational column that only shows when you are performing batch functions? That way I can create a dictionary on my end based on the dataset I already have, and repopulate all those hex string fields, upload the batch create data as expected and nothing breaks. Is that dumb?

Development schedule targets are seldom announced. When they are, like most software development, things fall behind.

On your second question, I have no idea. I’m a forum moderator, not a member of the development team.

Cool, figured, just thought I’d ask. Maybe I’ll get lucky and someone who knows more about dev will come along and weigh in. Thanks for the info so far though.

In near future, batch create won’t contain any GUID keys. And batch update will have only one key to identify the record. The same goes for custom fields where the custom field will be simply identified by the name rather than GUID key column.

The current implementation is not user-friendly.


That is excellent news. Thanks! Let me know if you need any beta testing… lol