Customers, vendors, and project-based procurement translated into the global address book and trade documents

In a Maconomy services estate most 'sales' volume is project invoicing rather than sales orders, and procurement originates from job budgets. D365 separates the party model from transactional roles, routes project purchases through purchase requisitions and orders with project distributions, and generates revenue through project invoice proposals rather than sales orders. This chapter maps customers, vendors, procurement, and the project-invoicing flow.

What you will be able to do

• Map Maconomy customer and vendor masters to D365 parties, customers, and vendors
• Explain why the D365 sales-order path is secondary in a services estate and identify where project invoice proposals replace it
• Configure purchase requisitions and orders originating from project budgets with project accounting distributions
• Design vendor invoice matching policies and understand two-way and three-way matching for project-linked purchases
• Resolve duplicate parties and multi-role entities through the global address book

Introduction

In a Maconomy services estate, the commercial relationship is project-driven. Customers exist because the organisation delivers projects to them. Vendors exist because the organisation procures services and materials against job budgets.

The Global Address Book and Party Model

Maconomy maintains customer and vendor records as separate entities. If the same legal entity is both a customer (you invoice them) and a vendor (they invoice you), Maconomy may hold two unrelated records with duplicated name and address data.

Customer Master Migration

The Maconomy customer master migrates to CustTable with a party reference. Key field mapping:

Vendor Master Migration

The Maconomy vendor master migrates to VendTable with a party reference. Key considerations:

Project-Based Procurement

In Maconomy, procurement originates from job budgets. A project manager identifies a need, raises a requisition or order against the job, and the cost posts to the project. D365 supports this through project-linked procurement documents.

Invoice Matching and Vendor Payments

In a services estate, most project-linked purchases are services (subcontractors, consultants, travel). Two-way matching is typically appropriate — the invoice is compared to the PO line for quantity and price agreement.

Procurement Policies and Workflow

D365 procurement policies control who can buy what, from whom, and under what approval rules. In a Maconomy estate where procurement originates from job budgets, the programme must configure policies that respect both project authority and organisational spend controls.

Project-Based Invoicing: Why Not Sales Orders

In a product-distribution business, revenue flows through sales orders → picking → packing → shipment → invoice. In a services business migrating from Maconomy, revenue flows through project actuals → invoice proposal → posted invoice → AR.

Migration Planning: Customers, Vendors, and Open Documents

Extract all customer records with name, tax registration, address, and identifiers; Extract all vendor records with the same fields; Match on tax registration number (most reliable), then on normalised name and address; For each matched pair, create one party record and link both customer and vendor roles;

Knowledge check

Summary

In a Maconomy services estate, the trade landscape is project-centric: customers are project clients, vendors supply project services, and revenue is project billing. D365 provides a comprehensive order-to-cash and procure-to-pay platform, but the programme must route the majority of commercial activity through project accounting rather…