Jan 02 2021 06:56 AM
I want to automate batch no. for concatenated items in a column.
The problem is if the concatenation is not unique, I want to add a serial no. to the batch no.
on the item which is repeated later in the column
I did this with the help of rank and countif function with variable array.
However, when I use this variable array in an table, the calculated formula goes wrong on table expansion
Is there a way to solve this?
I'm attaching a sample excel. If you can solve the problem in it, it would be much appreciated.
Jan 02 2021 07:26 AM
@Nishkarsh31 If you are willing to add a helper column to your table that counts the occurrence of each fruit, then the picture below might work for you. It's perhaps not the most elegant solution, but it's easy and it works.
Jan 02 2021 08:27 AM
With same idea that could be slightly modified initial formula (without helper column)
=[@Date]&[@Fruit]&COUNTIFS($C$2:$C2,[@Fruit],$B$2:$B2,[@Date])
However, batch number is changing if transform the table, e.g. to sort it.
Jan 02 2021 09:21 AM
Hi @Sergei Baklan , I've tried this already.
For some unknown reason when we expand a variable range like $C$2:C4
As soon as table expands by one row
it becomes $C$2:C6 instead of $C$2:C5
and the formula doesn't work anymore
I don't know if it's a glitch or something.
Let me know if you can find a solution to this
Jan 02 2021 09:23 AM
Hi @Riny_van_Eekelen , I'm good with adding helper column.
However, For some unknown reason when we expand a variable range like $C$2:C4
As soon as table expands by one row, it becomes $C$2:C6 instead of $C$2:C5
and the formula doesn't work anymore
I don't know if it's a glitch or something.
Let me know if you can find a solution to this
Jan 02 2021 09:47 AM
SolutionI see. Excel Table "remembers" that, for example, C5 is in the last row of the table. If you expand the table it adjust formula in row 5 such way it reference on the last row of expanded table. Thus you have two formulas with C6 an no one with C5.
Workaround could be
=[@Date]&[@Fruit]&
COUNTIFS(
$C$2:INDEX([Fruit],ROW()-ROW(Table1[[#Headers],[Fruit]])),
[@Fruit],
$B$2:INDEX([Date],ROW()-ROW(Table1[[#Headers],[Date]])),
[@Date])
Jan 02 2021 12:12 PM
Woah. Mind blown
That row() - header row is inspired @Sergei Baklan
One doubt though, why did you subtract the header Row?
" ROW()-ROW(Table1[[#Headers],[Fruit]])"
Why don't we just use " ROW() - 1 "
I tried, it's working
Any particular reason?
Jan 02 2021 02:53 PM
The usual reason is to safeguard against the possibility that someone might insert a row above the tables at some later date and not notice that the record numbers are now out of step. It is a more robust style of programming Excel.
Jan 03 2021 02:50 AM
@Nishkarsh31 , in addition to @Peter Bartholomew comment - on development phase always think about the maintenance. More time you invest in development much more time you save on maintenance. Avoid hardcoding in formulas (in particular like here, use reference instead of constant 1), keep errors handling, etc - future life will be much easier.
All the best in new year!
Jan 05 2021 08:25 AM
Genius, I appreciate it. @Peter Bartholomew
One follow up question
I've always wondered that hardcoding values would save up on the calculation speed.
Writing 1 instead of referencing header row, would prevent one wheel of calculation, in case the
sheet is very heavy.
Is there any evidence of this?
Jan 05 2021 08:25 AM
Thank you so much sir @Sergei Baklan
I have that same follow up question
I've always wondered that hardcoding values would save up on the calculation speed.
Writing 1 instead of referencing header row, would prevent one wheel of calculation, in case the
sheet is very heavy.
Is there any evidence of this?
Jan 05 2021 08:50 AM
That's always a compromise - save few milliseconds on recalculation of few hours of your own time on maintenance. Depends on concrete case, if recalculation is really slow when it's worth to re-build formulae.
Jan 05 2021 02:08 PM
If you are going to attempt to optimise a sheet for speed then I suggest you use tools to analyse the performance such as that offered by Charles Williams's FastExcel. Otherwise, it is only too easy to commit too much effort to changing code that is not consuming significant resource in the first place.
Usually the first consideration is to select computationally efficient algorithms, then to program them to be as transparent as possible. Rather than hard-wiring values which cannot be guaranteed to be constant, I would prefer to add the record sequence as a helper range; it would do little for speed but, given a suitable variable name, may add clarity to downstream formulas.
Jan 05 2021 02:25 PM
While working with Table, this is what you need to do:
=[@Date]&[@Fruit]&COUNTIFS(INDEX([Fruit],1):[@Fruit],[@Fruit])
I would strongly discourage using relative referencing while working with Tables.
I have also attached the file.
Jan 05 2021 02:29 PM
A slightly modified solution I would recommend is here
=[@Date]&[@Fruit]&
COUNTIFS(
INDEX([Fruit],1):[@Fruit],
[@Fruit],
INDEX([Date],1):[@Date],
[@Date])
It pretty much achieves the same thing. But I recommend that we avoid cell referencing while working with Tables.
Jan 02 2021 09:47 AM
SolutionI see. Excel Table "remembers" that, for example, C5 is in the last row of the table. If you expand the table it adjust formula in row 5 such way it reference on the last row of expanded table. Thus you have two formulas with C6 an no one with C5.
Workaround could be
=[@Date]&[@Fruit]&
COUNTIFS(
$C$2:INDEX([Fruit],ROW()-ROW(Table1[[#Headers],[Fruit]])),
[@Fruit],
$B$2:INDEX([Date],ROW()-ROW(Table1[[#Headers],[Date]])),
[@Date])