Importing deals

What the importer takes

CSV, JSON and Excel .xlsx. Character encoding and delimiter are detected rather than assumed, and you confirm the column mapping before any row is written.

The columns it needs

• An identifier for the deal in your system, so a re-import corrects rather than duplicates.
• An amount, and a currency if you pay in more than one.
• A close date, which decides the period the deal falls into.
• An owner identifier matching the identifier on a payee. This is what credit rules resolve against.
• A deal type if your plan pays differently on new business, renewals and expansion.

Everything else is kept

Any column you do not map is stored as a custom attribute and can be read from a plan as allocation.deal.attributes.your_column. A carrier cost, a product code, a region: keep them in the file and the plan can use them.

They arrive as text. To do arithmetic on one, wrap it in number(). See the plan language.

All or nothing

If any row is bad, nothing is imported. You get the file back annotated with what was wrong and where, you fix it, and you import again. A partial import is the worst outcome available: half a month of deals looks like a finished import and calculates a plausible, wrong number.

Corrections do not overwrite

Re-importing a corrected deal writes a new version and keeps the old one, marked as superseded. Reports count the current version; the history stays for the audit trail. This is why a correction never quietly rewrites a number somebody has already been shown.