Master Data

Before any workflow runs, master data must exist and be correct. This is the most under-appreciated fact about SAP Business One: the great majority of implementation problems are not technical failures but unclear, incomplete, or inconsistent master data. A sales order cannot exist without a customer, a price list, and an item; an invoice cannot post without the G/L accounts those objects point to. Master data is the foundation every document stands on, and understanding it means understanding what each object is and what depends on it — not creating one.

The main master data objects

Master data divides into a handful of families. Business partners and items are the “who” and the “what” of every transaction; finance and logistics objects supply the accounts, prices, locations, and rules those transactions need; and control objects govern who may do what.

mindmap
  root((SAP B1))
    Business Partners
      Customers
      Vendors
      Leads
    Items
      Inventory Items
      Service Items
      Fixed Assets
    Finance
      Chart of Accounts
      Tax Codes
      Payment Terms
    Logistics
      Warehouses
      Price Lists
      Units of Measure
    Control
      Users
      Authorizations
      Approval Procedures

Business Partners

A business partner (BP) is a customer, a vendor, or a lead. Every sales and purchasing document requires exactly one, and it carries most of the defaults the document inherits — currency, price list, payment terms, credit limit, and addresses.

What goes wrong with business partners:

• Duplicate records — the same customer created twice, splitting their history
• Wrong CardType — a supplier created as a customer, so it appears in the wrong flow
• Missing default addresses — deliveries have nowhere to ship to
• No credit limit set — the company takes on unlimited exposure
• Wrong payment terms — cash flow suffers quietly

Item Master Data

An item is anything the company buys, sells, or stores — a product, a raw material, a service, or an asset. The item’s type and its stocked/sold/bought flags decide which flows it can even appear in.

The item type trips people up more than any other single setting:

What goes wrong with items:

• InventoryItem = No on something that should be stocked — stock never tracks
• No default warehouse set — every movement forces a manual location choice
• Missing prices for a price list the BP uses — documents fail to price the line
• Wrong unit of measure — buys in boxes, sells in units, with no conversion set up
• Batch/serial tracking switched on mid-life — historical stock has no tracking data

Warehouses

A warehouse is a physical or logical stock location, and every stock movement names one. A company can run several logical warehouses inside one building — MAIN, DAMAGED, QUARANTINE, CONSIGNMENT — to keep stock of different status apart. Bin locations subdivide a warehouse further into shelf, rack, and position. The recurring error is simple: the wrong warehouse means the right total in the wrong place, and picking fails.

Chart of Accounts

Every financial posting needs a G/L account, and the chart of accounts defines the financial structure they post into — assets, liabilities, revenues, expenses, and other. It controls which account receives revenue from a sale, which records inventory value, which holds customer debt (the A/R control account) and vendor debt (the A/P control account), and how cost centres and dimensions are assigned.

Items and business partners are wired to their G/L accounts through G/L account determination rules — one of the most intricate configurations in SAP Business One, and the layer where a single mis-mapping silently sends postings to the wrong account across an entire flow.

Price Lists

A price list controls what price a customer sees on a document. A company can run many — retail, wholesale, VIP — and each business partner is assigned a default one. Each item carries a price per price list, and special pricing (volume discounts, contract prices) can override the list. If the BP’s price list has no price for an item, the line cannot price itself.

Payment Terms

Payment terms define when payment is due and whether an early-payment discount applies — Net 30, Net 60, or “2/10 Net 30” (2% off if paid within ten days). Terms are assigned to the business partner and flow onto every invoice, where they set the due date that the A/R and A/P aging reports measure against.

Tax Codes

A tax code defines the VAT or sales-tax rate and the G/L accounts the tax posts to. Codes are country-specific and often intricate. Each item carries a default tax code, which can be overridden on an individual document line — for example when a normally taxable item is sold to an exempt customer.

The master data dependency chain

The objects above are not independent — they form a dependency graph, and a document can only post if every link it touches already exists. This is the single most important diagram in the master-data story.

flowchart TD
    BP[Business Partner] -->|uses| PL[Price List]
    BP -->|uses| PT[Payment Terms]
    BP -->|uses| WH[Warehouse - default ship-to]
    ITEM[Item] -->|has price in| PL
    ITEM -->|lives in| WH
    ITEM -->|posts to| COA[Chart of Accounts]
    BP -->|posts A/R to| COA
    BP -->|posts A/P to| COA
    TC[Tax Code] -->|posts tax to| COA
    ITEM -->|uses| TC

Read the arrows as “cannot work without.” A business partner is useless without a price list and payment terms; an item is unsellable without a price in the relevant list, a warehouse to live in, a tax code, and the G/L accounts it posts to. If any link in this chain is missing, documents fail to post — which is why master data is set up first, and why a stalled transaction so often turns out to be a master-data gap rather than a transaction problem.

How Norma uses master data

Norma reads master data constantly and relies on it being correct, but it treats master data as the client’s foundation to own — not something it edits on a whim.

Reading master data. Before drafting any document, Norma looks up the objects it will reference. list_business_partners and get_business_partner resolve the customer or vendor and inherit their currency, price list, terms, and credit limit; list_items resolves item codes, types, prices, and default warehouses. These read-only tools also answer master-data questions directly — “does this customer exist,” “what price list are they on,” “which warehouse does this item default to.” Because they only read the Service Layer, they carry no review gate.

Depending on it, not overwriting it. Norma’s write tools create transactional documents — orders, deliveries, invoices, payments — every one of which references master data that must already exist. When Norma drafts a create_sales_order or a create_invoice, it fills the CardCode, item codes, warehouse, and tax code from the master data it read; it does not invent them. Those drafts are posted to the connector against the Service Layer create path /b1s/v1/<Docs> and reach SAP only after a human approves them. The dependency chain in the diagram above is therefore also Norma’s precondition: a missing business partner, price, or account is a gap the client fixes in master data, not something the assistant papers over at document time.