SSIS import with header record
Instead of using a script component, I recommend using a more database-centric approach.

Consider the following approach:


Read the data from the flat file using a flat file source.  Keep your flat file source simple.  It should have one column which contains the EntireRow.
(optional) add a script component or derived column to count rows and generate a InputRowNumber field.  The InputRowNumber is helfpul for debugging.
Write the two columns to a simple staging table called InputFlatFile containing the InputRowNumber int, and EntireRow varchar(max) fields.
Using ExecuteSQL Tasks, execute queries which insert the data from your InputFlatFile staging table into your real database.  Based on your example data, these queries should be fairly straight forward.




INSERT INTO HeaderTable (NAME_EDC, DUNS_EDC)
SELECT SUBSTRING(EntireRow, 231, 60) NAME_EDC
     , SUBSTRING(EntireRow, 291, 13) DUNS_EDC
FROM InputFlatFile
WHERE LEFT(EntireRow,2) = '01'

INSERT INTO DetailTable (columns..)
SELECT SUBSTRING(EntireRow, 1, 2) REC_TYPE_DETAIL
     , SUBSTRING(EntireRow, 3, 6) PMT_NUMBER
     (... more columns)
FROM InputFlatFile
WHERE LEFT(EntireRow,2) = '02'





use an ExecuteSQL task to permanently delete the data in the staging table so it is ready for the next load, or use an OUTPUT clause to move it into an archive table if necessary.  




I think the database-centric approach is better for the following reasons:


From this base, you can easily create a queryable data lineage.  Want to know which file created which row in the final database?  Create a FileLog table and insert a row at the start of the control flow with logging information like file name, modified date, etc.  Retain a reference to the InputRowNumber and FileLogID in the destination database and you can trace the data from source file to destination easily.
In my experience, people who work with SSIS tend to have a stronger database background than OO programming background so the Set Theory that I used above comes naturally and is easier to maintain on an ongoing basis (also, there tends to be more helpful ideas for database-centric approaches on this and other forums)