Introduction
This document outlines the behavior for a “standard” PaperlessParts ERP integration. It is the rubric I would have used to evaluate an integration while I was at PaperlessParts to determine if it was ready for primetime. This document won’t get into too many implementation specifics but will instead discuss the general data objects and control flow of the integration.
The terminology I use is PaperlessParts-centric: for example, importing means moving data from StartProto into PaperlessParts, and exporting means moving data from PaperlessParts into StartProto. This is the way the PaperlessParts team talks about these concepts, so you’ll have an easier time communicating with them if you use the same language.
What is the purpose of a standard PaperlessParts ERP integration?
PaperlessParts is first and foremost a quoting and estimating tool. The majority of its functionality is designed to make it easier to create quotes more quickly and more consistently. This includes being able to analyze 3D models to pull out relevant geometric features, automatically build the BOM from a 3D model, create user-defined formulas that can perform costing logic based on the features detected in a 3D model, etc.
Once a quote is created, it can be sent to a prospective buyer. If that buyer accepts the terms of the quote, they can place an order. PaperlessParts does not currently have any functionality to support the actual manufacturing of parts.
In order to create an accurate quote, you need to build a BOM and router that closely resembles the BOM and router that will actually be used in production. As a result, most customers don’t want to have to redo any of that work when an order is placed and it comes time to make a part. The primary goal of the integration is to export the BOM and router that was built in PaperlessParts into StartProto to save the end user from having to do manual data entry.
When you have an integration between two software systems that have overlapping data models (e.g. both systems store data about BOMs, routers, customers, buy items, etc) you have to make a decision about which system is going to be the source of truth for each data model. In this document I’ll enumerate the data models involved and indicate which system is the source of truth for each. In a standard PaperlessParts ERP integration, the ERP is the source of truth for most data. The reason for this is that there are typically many different teams at a shop who use the ERP, and only two of those teams are typically users of PaperlessParts (estimating and sales). As such, it makes more sense to leave the ERP as the source of truth, so as to minimize the disruptions caused for the rest of the teams at the shop.
When drafting a quote, it’s often important to have information that resides in the ERP easily accessible. This information needs to be up to date, and if it’s going to be used for automation purposes, it needs to be physically present inside PaperlessParts. The secondary goal of the integration is to continuously import information that is managed in the ERP into PaperlessParts so it can be used to draft quotes effectively.
Order Exporter
The order exporter runs when an order is created in PaperlessParts. This is the only time that data flows from PaperlessParts to StartProto.
As with the importers, it’s important to define which system is the source of truth for which data:
PaperlessParts is the source of truth for quote costing data
StartProto is the source of truth for BOM and routing data
StartProto is the source of truth for customer data
Typically, information should flow from the source of truth to the system that replicates it. However, because PaperlessParts sits in front of StartProto in the RFQ -> Quoting -> Production -> Delivery -> Money flow, there will be situations where it makes sense to break that rule. Specifically:
If a BOM / Router is defined for a part in PaperlessParts and that BOM / Router does not yet exist in StartProto, copy the PaperlessParts data into StartProto
If a new customer is added to PaperlessParts and does not yet exist in StartProto, copy the PaperlessParts data into StartProto.
When an order record is created, the following things happen:
An order record is created in StartProto to capture the customer information (shipping address, payment terms, etc.) and monetary information (order total price, line item prices, etc.)
If the customer referenced on the order does not yet exist in StartProto, create it and write its unique identifier back to the “ERP Code” field in PaperlessParts
For each line item in the order:
If the BOM / Router for that part does not yet exist in StartProto, create it with all the information available from PaperlessParts. If it does already exist, do not modify it.
See below an example of a mapped order and BOM.
Order Mapping
BOM Importer Example
Importers
As stated previously, the purpose of the importers is to bring data that is managed in StartProto into PaperlessParts continuously.
StartProto pushes this data Live into PaperlessParts using our 'event listener' architecture that monitors all relevant entity create and edit events.
Customers / Contacts / Addresses
StartProto populates the “ERP Code” field with the StartProto ‘Company’ object id. This will keep these two records linked going forward, which will be helpful for future updates as well as reducing the chance of duplicate records when the order exporter runs.
Company data is pushed to PaperlessParts when creating or editing any company in StartProto live via our event listener architecture.
See below an example of the mapping of a StartProto company record into a PaperlessParts account, contact, and facility records.
Work Centers / Labor Rates / Burden Rates
There is currently no explicit data model for work centers in PaperlessParts, so you’ll be writing these to a custom table (see these docs for more information).
Process rates are pushed to PaperlessParts when creating or editing any process in StartProto live via our event listener architecture.
Table Field | Description |
name | The unique name of the ‘Process’ in StartProto (analogous to an ‘operation’ in PaperlessParts) |
hourly_cost | The hourly costing rate of the process in StartProto |
link | Link to the buy item in StartProto |
id | The unique StartProto object ID for the buy item |
Note that a PaperlessParts operation (analogous to a StartProto process) needs to have its costing logic customized before it can be useful, so there is currently no way to create one via the API. As such, even if your importer automatically adds new rows to the custom table as new records are added in StartProto, manual work will be required on the PaperlessParts side before that record will be available for use in a PaperlessParts quote.
Buy Items
In StartProto, we treat all items purchased from vendors as Buy Items. To push this data to PaperlessParts, we have a custom field configured in StartProto for the user to determine whether a part is a material or a purchased component.
All buy item data is pushed to the appropriate location in PaperlessParts when creating and editing a Buy Item.
As of now, the integration setup does not perform initial syncing; we have used CSV files to import bulk initial data into PaperlessParts.
Raw Materials
This is a subset of “buy items” that refers to things like sheets, bars, rods, etc. Hardware fasteners will be covered in the next section called Purchased Components.
Raw materials are another data type that does not have an explicit model in PaperlessParts, so you will use a custom table for these as well.
Table Field | Description |
name | The unique name of the buy item part type in StartProto - often a part number |
sku (description) | The subline description of the item shown throughout StartProto |
price | Price of one purchasing unit of the item from the default vendor |
notes | Notes |
lead_time | Lead time (in days) set in the default buy option |
vendor | Vendor associated to the default buy option |
purchase_link | Vendor website purchasing link associated with the default buy option |
purchase_unit | The unit the item is purchased in from the vendor |
purchase_unit_size | The number of consumption_units in one purchase_unit (a ratio) |
consumption_unit | The unit that the material is consumed in for the purpose of routings |
link | Link to the buy item in StartProto |
id | The unique StartProto object ID for the buy item |
Purchased Components
Unlike raw materials, this subset of buy items does have a first-class data model in PaperlessParts.
See below how the Purchased Materials Custom Columns need to be configured for use with StartProto.
The naming and usage of these columns largely follows the above, with a few exceptions listed here:
Table Field | Description |
oem_part_number | The unique name of the buy item part type in StartProto - often a part number |
internal_part_number | The unique StartProto object ID for the buy item. |
piece_price | Price of one purchasing unit of the item from the default vendor |
description | The subline description of the item shown throughout StartProto |