Batch Creating Invoice with Multiple Lines Per Transaction

Hi!

We noticed the update in sales invoice batch create with multiple lines from single cell with line breaks to population of multiple columns for each line.

We normally have thousand of sales transaction per month and the no. of items sold per transaction differs. This is where making batch create template difficult because the no. of columns differs per transaction.

Do you have any idea how to do this easier? Like excel/gsheet formula that can populate as many columns as maximum line transaction there is in a batch?

Or may I suggest to change the batch create/update technique by moving the line details to multiple rows instead? Then, use a transaction identifier to identify which lines are related to one another? I attached here below 3 ways how I propose the header and line details can be imported.

Thank you!

2 Likes
  • Create a template document with enough columns to accommodate the maximum number of lines you use in invoices.

  • Use that template to convert from your source format to the format required by batch create.

Hi Patch,
Thanks for given idea but in your idea there is a 1 issue.
If suppose i made template for 1000 lines but every time is not a same number of line some time its only 950 line so in As per template they insert All 1000 line. I think

the previous version is better. its enter all the line in 1 cell i think Manager.io have rollback it

2 Likes

Do you need detailed sales invoices in Manager?

Why not import monthly totals and kept the details in the sales system only?

Yes we need detailed invoice, unfortunately, some of our customers pay on a per transaction basis. Example is online platforms that pay us only when direct customer has paid and item is delivered (so this varies from customer to customer). So we need to be able to tag orders which are paid and monitor the orders that are still awaiting for collection. Our sales system only provides sales encoding functionalities.

We also need to keep detailed inventory to provide record to reconcile with warehouse physical count.

Try it.
I believe you will find the completely blank entries for the last 50 lines not used will not be added to the invoice.

If you have that many sales invoices a month, you should hire a programmer to format the create batch from your sales system output so that the file only has the columns needed for each invoice

If you want line Items to be under one another you can use Transpose in Excel when copying & pasting the values then use Transpose again when you are done.
You would get something like this that is easier to work with when entering line items.

There are some issues with this approach so you need to be careful. Note that the first two line items are separated from the others by a bunch of columns. Also having Lines.Account changes the order as indicated on Lines.3.Item. I hope @lubos could do something about this.

2 Likes

it added blank line and increase the size of database

Your link to a PDF was deleted because it was a security risk to others. Illustrate with screenshots.


Please check the images

That is exactly what I would have expected. Blank lines entered manually are records in the database. Blank columns in Batch Create are effectively the same thing, so they produce blank lines.

1 Like

werent blank lines eleminated before ?

What version of Manager are you using @vrushabh ?

That was a different issue, where blank lines were being inserted spontaneously. @vrushabh referred to inserting a spreadsheet template for Batch Create with unused (but present) lines, which therefore appeared as blanks.

No it’s the same issue.
Batch create can be used to create transactions with different number of lines when entered correctly in a version of Manager without a bug.

I am using 22.10.27.462 in this version and it is fine and blank lisne issue is not there

You are hundreds of version out of date, so your comment, while informative, is not of much help to users of the current version.

1 Like

@Joe91 still it proves that this is a bug and not listed as such

@Genti_Ge, reports from obsolete versions of the program are not categorized as bugs. Nor are they considered evidence that more recent versions contain bugs just because behavior has changed. The program is constantly changing. Sometimes, that means features that once worked a certain way now work in different ways.