Batches and Ranking Reports; Web and Excel formats

[DennieSch]

Expected Behavior

Nominal output data and formatting.

Actual Behavior

Some anomalies and inconsistencies; (friendly) details provided in the attached.
Report Comments (v2.0.1).zip

Using version = 2.0.1 (5ffc787)

Steps to Reproduce the Problem

1. Standard report generating steps.

Specifications

version = 2.0.1 (5ffc787)
Architecture = ('64bit', 'WindowsPE')
Machine = AMD64
Platform name = Windows-10-10.0.18362-SP0
Processor = Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
Python Branch = tags/v3.7.4
Python Build = ('tags/v3.7.4:e09359112e', 'Jul 8 2019 20:34:20')
Python Compiler = MSC v.1916 64 bit (AMD64)
Python Implementation = CPython
Python Revision = e09359112e
Python version = 3.7.4
Release = 10
System = Windows
Version = 10.0.18362
Win32 = ('10', '10.0.18362', 'SP0', '')

• Connected devices or roasting machine: N/A

Please attach your current Artisan settings file (as exported via menu Help >> Save Setings as *.aset) file.
Please attach any relevant Artisan *.alog profiles.

Note that you need either add a .txt extension or zip the files before uploading. Otherwise you will receive a "Not a supported file type" error on uploading.

[MAKOMO]

Thanks for this detailed report. I will try to fix the reported issues. It would help if you could provide a set of sample .alog files that demonstrate the issue with the wrong LOSS average computation (on slide 3). The issue might be in the profiles not the report as I could not duplicate this one. Thanks!

[MAKOMO]

I fixed the HTML syntax error for Web batch reports and added decimals for oz in the table footer.
I added the unit % to the headers for Excel batch and ranking reports (thus the % comes with each value by the Excel percentage formatting) and instructed Excel to format the decimals also for oz. I also added decimal places in various places although I am not a big fan of that necessary noise.
I also "improved" the AVG Color formula such that it does not show an "error" if there are no values. That is not exactly an error in the formula but the Excel semantic of that average formula. The color column is to show roast color values as for example measured using a Tonino color meter.

Only thing that I still cannot reproduce is the wrong average calculation for loss in the table footer of Web ranking reports. Here I wait for detailed instructions and .alog files to be able to duplicate this.

[DennieSch]

Hey Marko- That was guick....you 'da man!
Here are the files (.alog, .aset, .html).

Cheers- Dennie
Profiles and Settings file.zip

[MAKOMO]

Thanks for those files. I think I resolved everything by now, thus I close this one.

[DennieSch]

Hey Marko-
Looks like the Roast/Ranking/Excel... report still has "%" marks in the data fields.
percent marks in data.zip

[MAKOMO]

Excel is doing this as the cell format is set to percent. Nothing to do about it. I think it is fine here. The cell itself contains only the number (0.21 rendered as 21% by Excel).

[DennieSch]

I do understand what you are saying and the cell format you mention. The report I generated with version = 2.0.1 (cd0a22e) does have the symbol in the cell. Take a peek at the attached when you have a chance and see what ya think.
ranking2.zip

Cheers - Dennie

[MAKOMO]

I am puzzled now. I took your file and set the cell formatting to number and did not see any % symbol. They are pure numbers. Only the percent formatting is adding the %. See files attached. Maybe it should be removed from the header here to avoid the duplication. I will do that.

ranking2-number-format.zip

[DennieSch]

Hi Marko- I see what you mean. I should have caught that before sending the comment...'my bad'.

Here's what I was thinking....there could be two approaches--

1. % marks in the data and not in the header row
   -- application passes the data to excel as a decimal (0.XXXXXXXX) and the cell is formatted as a percentage
   -- Result is "XX.X%" for the data in the cells

2. % marks in the header row and not in the data
   -- application passes the data (assumed to be carried as a decimal) as 'DATA*100' to excel and the cell is formatted as a number
   -- Result is "XX.X" for the data in the cells
   -- any 'SUM' or 'AVG' rows would need to be dealt with accordingly

Do you think #2 is doable?? I'm thinking that would make for 'cleaner' and consistent looking reports.

Cheers,
Dennie

[MAKOMO]

Dear Dennie,

I decided for approach 1 here as the Excel export is not about "clean look", but about data that can be easily further processed. Sorry.

[DennieSch]

Hi Marko- Thanks for considering this and your reply. While I might have been leaning more towards approach 2, I respect your decision and support 100%. No problem.
Cheers- Dennie