Batch update containing transactions of differing number of lines should work without inserting blank lines. Failure to do so could reasonably be considered a bug imo.
Batch create containing transactions of differing number of lines and in an identical format to batch update but without the “Key” field should work without inserting blank lines. Failure to do so could reasonably be considered a bug imo.
It the above functionality is achieved
Batch create containing transactions of differing number of lines and resulting in insertion of unwanted blank lines is operator error.
But the point is that by adding blank columns, you are adding blank lines on the finished invoice. That is the consequence of revising the database structure.
The fact is, we don’t know exactly what @vrushabh did. Post #9 is vague. And it was done on an obsolete program version.
Batch update containing transactions of differing number of lines works without inserting blank lines.
Batch create containing transactions of differing number of lines and in an identical format to batch update but without the “Key” field works without inserting blank lines.
As a result their is no current bug and the likely explanation for the problem described is operator error. At a guess the error is the spreadsheet template they have created does not leave all the fields in unused lines blank (zero quantity or a space character is not blank).
I admit it, I have been many version behind and finally decided to catch up. As always I test new versions on a separate machine before implementing. This change was/is a show-stopper for bring up to date. There just is no good way to build infinitely (well you know what I mean) wide single lines for invoices with many many lines.
The options drawn by weng are all good and certainly much more common practice in many/most accounting or ERP system import process.
I would favor one line per invoice line either with a transaction identifier as proposed by weng or simply that by repeating the header level fields of issue-date-reference-customer that really provides a unique concatenated key for the batch import process to identify all lines for the same invoice.
Perhaps this is something that could be raised as an idea for voting?
As much as would like to, but I cannot defend the current format of Batch create. So I will have to agree with the majority of the posts that favor the old format.
Not only is it an unconventional layout, but it spreads the validations and operation accross an undefined number of columns. This is especially true for quick Batch updates – which I nearly completely abandoned since the format change. I need to find and replace accross many columns or stage the data first, do my work on a normalized format and then stage the data back before updating.
While staging is feasible for Batch create, as far as Batch update goes, I find it much more efficient to just edit the records manually now.
I think the volume of user input regarding this is worthy of further investigation by @lubos.
Thanks Ealfardan. I’d like to see revising the current format to something with a “line per line” or even reverting to the old format as an interim solution at least being classed as an IDEA for consideration.
Until something changes here, I for one am unable to update.