Skip to content
Data migration·Prophet 21

Why your P21 supplier load fails on an empty tenant

A brand-new Prophet 21 tenant will reject vendor creation with an opaque error until the accounting foundation exists. Load order is not a preference, it is a dependency graph.

You have a fresh Prophet 21 tenant, a clean supplier file, and a working API recipe. The create call comes back with something like a general exception about a sequence containing no matching element.

That message is not about your payload.

What is actually happening

A Prophet 21 supplier is a two-level object. There is a supplier master, and underneath it at least one vendor row scoped to a company. Creating the supplier means creating both.

The vendor row carries accounting context: terms, GL account defaults, tax group, purchase account group. On a tenant where the company record has every GL account default blank and the chart of accounts is empty, the server-side code goes looking for a default that is not there and fails on an empty set.

The exception surfaces as a .NET internal error rather than a validation message, which is why it reads like a bug in your request. It is a missing prerequisite reported badly.

The dependency order

Master data in P21 loads in an order, and the order comes from what each object requires to exist:

  1. Chart of accounts, and the company's GL account defaults populated from it
  2. Terms, tax groups, purchase account groups, and the other code tables the masters reference
  3. Suppliers, which need all of the above to produce a valid vendor row
  4. Items, which need their base unit of measure, their unit fields, and a supplier-by-location link
  5. Customers, with their own AR account and terms requirements
  6. Open documents last: AR, AP, open orders, open POs

Skip a level and you do not get a clear error telling you what is missing. You get a failure from several layers deeper that names none of it.

The part that is not a technical problem

Here is the thing worth planning around: the accounting foundation is usually not in the legacy system.

A distributor coming off a point-of-sale package or a QuickBooks file does not have a P21-shaped chart of accounts sitting in an export. Their GL structure lives in an accounting package, or in their bookkeeper's head, and the P21 version of it is a design decision that has to be made by the client with their controller.

So the blocker on the critical path of your migration is not an ETL task. It is a client decision with a meeting attached to it, and it gates everything downstream.

What to do about it

Sequence the project around it. The chart of accounts and company setup are Phase 2 work, before data migration is scheduled, not parallel to it. A plan that has suppliers loading in week three and the COA workshop in week five is already late.

Prove the order in a rehearsal environment. Run the full sequence into Play or an import tenant before production sees anything. The errors you hit in rehearsal are the ones you would otherwise hit at cutover.

Do not read an opaque error as a payload problem. When a create fails on an empty tenant, check what the object depends on before you touch your file. In almost every case the recipe is fine and the environment is not ready.

The general rule

Migration failures on a new tenant are prerequisite failures far more often than they are data failures. Before debugging the row, ask what has to exist for that row to be legal, and check whether it does.

Seeing this on your system?

Describe the symptom in your own words. Diagnosing it is our job, and an engineer replies within one business day.