Import a workbook

Drop one or more spreadsheets on a project and review what PadFlow found before any of it is written.

Most deals arrive as spreadsheets, and rarely as one. A tracker with the schedule in it, a takedown table, a lender exhibit, a sheet of cost codes. This page takes all of them at once.

You drop the files. They are read in your browser, formulas included, and nothing about them leaves it on its own. PadFlow works out what each sheet is from the sheet itself, and shows you the result before writing anything.

A scan or a photograph of a printed sheet works too, and is the one thing that does not read itself: a printed page has no rows in it, so PadFlow shows you its pages and you pick the ones the assistant should read. Only those pages go, and only when you press the button that names them. See the import page for what a page read does and does not do.

What it can read

Five destinations, decided from the columns rather than asked up front:

• Schedule tasks from a tracker's phase blocks, with the plan formulas brought over as rules rather than as typed dates, so the cascade works from the first day.
• Critical dates from a sheet with a name beside a date. A column that says what a row follows becomes an anchor, including when it names a task that is arriving in the same run from another file.
• Takedown periods from a numbered release with a quantity and a date.
• Lender budget lines from a label beside an amount.
• Internal cost codes from a code beside an amount, with optional quantity, unit price and unit columns.

A table read off a printed page arrives here as a sheet like any other, and is classified into the same five destinations. The one difference is the doubt: a cell the reader was not confident it transcribed correctly is a question under "Needs you", with both readings on the card, rather than a figure written into a budget.

A sheet that matches nothing, or matches two of those, is a question rather than a guess. It appears under "Needs you" showing the rows themselves: six of them, with each column marked as a label, a date or an amount where nobody wrote a header over it. If PadFlow could read the block but not confidently, its best answer is on the card too, with its reason and one click to accept; the list of every destination is still beside it if you disagree. When reading automatically is switched off or could not be reached, the card says so.

A tab is not always one table. A block of rows separated by blank lines, or a run of dates sitting directly above a run of amounts, is read as two, and each one is understood or asked about on its own.

The review

Three groups, and every count in them is something you can open:

• Understood is what will land. New rows, and rows that update something already here.
• Needs you is everything that cannot be decided without you: a sheet with no destination, a row whose anchor names nothing on this project, a budget sheet on a project with no loan yet, a quantity line whose amount disagrees with quantity times unit price. Each one carries the cell, the row and the reason.
• Conflicts are rows somebody has edited by hand since an import last wrote them, or that never came from an import at all. The project keeps its value unless you take the sheet's, one row at a time.

What an import will never do

It never deletes. Rows on the project that the sheets do not mention are left exactly where they were.

It never writes actuals. Completion, closed quantities and draw history are entered here, not in a spreadsheet, and a merge does not touch them. Draw history the lender has already funded arrives a different way, through the workspace import, which lands a ledger as funded history and asks for approval rights to do it.

It never creates, changes or clears a baseline. An amount that changes on a merge lands as a current amount and shows against the baseline the way any other edit does.

It never reorders lines that already exist. Sheet order becomes the order of new lines only, so the page keeps agreeing with the document you are reading beside it.

Doing it twice

Importing the same file twice does nothing. Every row is matched to what is already here by its own content, so the second run finds everything already present and writes nothing. The count it reports back is the number of rows actually written, so a re-run reports none imported rather than counting the rows it recognised and skipped; anything it set aside travels as an excluded count instead of disappearing.

A row also has to name a category the register keeps a date under, and a date filed against a contract has to name a contract on this project. A row that does neither is refused rather than written, so nothing lands under a category that does not exist or against a contract that belongs to another project.

Undoing one

Every confirmed import is a run, listed at the top of this page, and any of them can be undone. Undo removes the rows that run created and puts back every row it overwrote, in one step.

Some rows are kept rather than removed, and they are named when they are: anything edited since the import, any lender line with draws against it, any cost code with a draw or an invoice posted to it. Those have a history that an undo is not entitled to erase.