Specify Header Row for XY Table To Point

[rgeorge9935]

I would like to see an option for the XY Table To Point tool in ArcGIS Pro that allows you to specify what row your headers (column names) are located in. The tool will not pick up the correct header names if  your field name headers (X,Y, etc...) start on any row other than the first.. A lot of application (both GIS and non-GIS) usually allow you to specify where your headers start. I often find myself batch processing csv tables into Pro, but if the headers for those csv files don't start on row 1 then I must edit them. I think this is a relatively simple idea, but would be extremely beneficial. 

[DrewFlater]

@rgeorge9935 all geoprocessing tools, including XY Table To Point, leverage a system in ArcGIS Pro called the text file workspace for reading CSV, TXT, and other delimited files as a table. The same text file workspace is used when you open the attribute table in ArcGIS Pro for a standalone table with the same delimited file source. If you were to add the same delimited files to Pro, the attribute table would not recognize that the column headers are located in a different row. For consistency and code maintainability, we will not introduce tool-specific changes as you described to a tool like XY Table To Point. 

Depending how you want to move forward there are two options for managing the feedback you raised in this idea:

1. Edit the idea title and label so that the requirement is more generally that Pro's delimited file/table handling should allow the user to specify the row header, and not specific to the XY Table To Point geoprocessing tool.

2. If you prefer, this specific Idea can be closed, since as-written it cannot be implemented, and you can raise a new Idea with a similar theme about Pro generally supporting delimited files where the column header is not in the first row.

[RTPL_AU]

I second the idea but kudos is disabled while in this state.

@DrewFlater So are you saying that it is a valid idea, worthy of consideration, that Esri introduce more advanced features into the text file workspace? 
@rgeorge9935 lists a typical scenario where this would be handy to have but I'll support it if it is rephrased to increase the scope as you recommend.

We come across files of this type often in mine planning & exploration.