Best Of

Hello @Renee Bernier, you can do this using multiple methods the easiest way :

1. Navigate to Transactions > Management > Print Checks & Forms.
2. Click Select Required Transactions.
3. Choose the necessary filters/fields (e.g., Location, Form, etc.) to pull the correct transactions.
4. Check Allow Reprinting (if you need previously printed transactions to appear).
5. Click Mark All to select the transactions.
6. Click Print.

You can also do this using a Script if there's a High Volume of Transactions :

1. Create a Scheduled Script
2. Use N/Search Module to Search for Transactions
3. Render a PDF using N/Render
4. Export or Save as per your need

Thank you, I think it might have been a timing issue as well. So I'll put in a case and look into it more. Kind regards, Britton

Yes, we have evaluated the NetSuite Connector and not an option for us. Will need to build from scratch.

Hi @fworkman

Here is the guide for integration process for your use case - Hope this will useful for you,

Building an automated accounting bridge between Data Dis MIR-RT (your fleet maintenance and shop system) and Oracle NetSuite via REST API is a massive step up from manual CSV imports. It will eliminate duplicate data entry, reduce human error, and provide real-time financial visibility.

Here is a breakdown of what is available today, the best approach to take, and specific architectural suggestions for your development team.

1. What is available today to achieve this?

To connect Data Dis MIR-RT and NetSuite, you have three primary components available in 2026:

• NetSuite SuiteTalk REST Web Services: NetSuite’s standard, out-of-the-box REST API. It natively supports standard CRUD (Create, Read, Update, Delete) operations for Vendor Bills, Vendor Credits, and Journal Entries.
• NetSuite RESTlets (SuiteScript 2.1): Custom REST APIs that your developers can write and host directly inside NetSuite. Instead of making multiple standard API calls from the outside, you send one custom JSON payload, and the RESTlet executes custom business logic to create the records.
• Middleware / iPaaS (Integration Platform as a Service): Cloud integration platforms like Celigo (the gold standard for NetSuite integrations), Boomi, or Workato. These platforms sit in the middle, translating MIR-RT’s data into NetSuite’s format without needing heavy custom code.
• Data Dis MIR-RT APIs: MIR-RT has modern API capabilities and is known for custom "passerelles comptables" (accounting bridges). Your team can either configure MIR-RT to push data via webhooks or have a script pull data from MIR-RT’s REST API.

2. What is the Best Approach?

The best approach depends on whether you want to buy middleware or build it entirely in-house.

Option A: The iPaaS Middleware Approach (Recommended for ease of maintenance)

• How it works: You use an iPaaS like Celigo. You set up a flow that pulls approved vendor bills and journal entries from the MIR-RT API on a scheduled basis (e.g., every 15 minutes) and maps them to NetSuite using a drag-and-drop interface.
• Why it’s best: It provides a pre-built error dashboard. If a Vendor Bill fails to sync because an account is closed or a vendor is inactive, your accounting team can see the error, fix it, and click "retry" without bothering the developers.

Option B: The Custom RESTlet Approach (Recommended for lower licensing costs / custom builds)

• How it works: If MIR-RT supports outbound webhooks (or if your team writes a small middleware script in Node.js/Python), you can POST data directly into NetSuite. Instead of using standard SuiteTalk REST, your NetSuite developer writes a RESTlet.
• Why it’s best: MIR-RT's data structure for parts, shop labor, and taxes can be complex. Sending the raw MIR-RT JSON payload directly to a NetSuite RESTlet allows you to handle complex logic—like dynamic GL account mapping or calculating cross-subsidiary taxes—natively inside NetSuite using SuiteScript.

3. Suggestions for Your Development Team

If your development team is building this bridge, hand them these specific guidelines to ensure a robust, enterprise-grade integration:

A. Master Data Synchronization (The most critical step)

Before you can automate transactions, the systems must speak the same language.

• Vendors: How will NetSuite know which vendor in MIR-RT is being billed? Your team should store the NetSuite Vendor Internal ID inside MIR-RT. Ideally, NetSuite should be the "Master" for Vendors. When a new vendor is created in NetSuite, trigger an API call to create it in MIR-RT.
• Chart of Accounts & Segments: MIR-RT parts and labor categories must be mapped to NetSuite's exact GL Accounts, Departments, Classes, and Locations. Build a mapping table (either in your middleware or as a Custom Record inside NetSuite) so hard-coding is avoided.

B. Use externalid for Idempotency

Because this is financial data, preventing duplicates is vital.

• Your team should map the MIR-RT unique transaction ID (e.g., the MIR-RT Invoice # or Work Order #) directly to NetSuite’s externalid field.
• Instead of using the standard POST (create) method, instruct the developers to use the PUT /upsert method based on the externalid. This ensures that if the API drops the connection and MIR-RT retries the request, NetSuite simply updates the existing Vendor Bill instead of creating a disastrous duplicate.

C. Authentication Standards

Do not use Basic Authentication or user-level passwords. Instruct your team to use OAuth 2.0 Machine-to-Machine (M2M) authentication or Token-Based Authentication (TBA). This ensures the API bridge has a dedicated, secure integration role with strict permissions limited only to Vendor Bills, Credits, and Journal Entries.

D. Batching Journal Entries

If MIR-RT generates hundreds of small inventory adjustments (e.g., mechanics taking single parts out of the shop inventory), do not send an API call for every single bolt and filter.

• Suggestion: Aggregate these movements and push a single Summary Journal Entry at the end of the shift or day. This heavily reduces API traffic, respects NetSuite’s strict concurrency governance limits, and keeps your General Ledger clean.
• Ensure the script verifies that total Debits = total Credits before pushing the payload to NetSuite, or it will automatically be rejected.

E. Error Handling and Dead-Letter Queues

APIs will inevitably fail (e.g., NetSuite is down for maintenance, or an accounting period is locked).

• The development team must build a robust retry mechanism with exponential backoff.
• Implement a "Dead-Letter Queue." If a transaction fails 3 times, it should be isolated, and an automated email alert should be sent to the system administrator or accounting manager with the exact HTTP error response (e.g., "Error 400: Accounting period is locked for this Vendor Bill").

Hi @Gina Kessler

The Workaround: "The Item Swap"

If you need to change the costing method for an active item, you have to recreate it and migrate the inventory.

Step 1: Create the New Item

• Create a new item record and set your desired Costing Method (Average, FIFO, Standard, etc.).

Step 2: Zero Out the Old Item

• If the item currently has inventory, run an Inventory Adjustment (or Inventory Worksheet) to adjust the quantity of the old item down to zero.

Step 3: Receive Inventory into the New Item

• Perform a second Inventory Adjustment to bring the same quantity and total value of the inventory into the new item record.

Step 4: Do the Name Swap & Inactivate

• Rename the old item to something and check the Item is Inactive box.
• Rename the new item to the original item number.
• Update any active Bills of Materials (BOMs), open Purchase Orders, or open Sales Orders to point to the new item.

Hi @Gina Kessler,

NetSuite does not allow changing the costing method once a record is saved. To update it, you must zero out the inventory on all locations via inventory adjustment, inactivate it, then create a new item record that has the correct costing method. Make sure to use an inventory adjustment to add the quantity back to the newly created item record.

Hi @Marie4455,

When using the Match Bill to Receipt feature, NetSuite enforces a strict relationship between what was physically received and what can be billed. If you need to pay a vendor for items that were never received, you must reconcile the financial obligation while ensuring your inventory counts and standard costs remain accurate.

Since you've confirmed the items will not be received but must be paid, the best practice is to separate the physical receipt from the financial "settlement" of the dispute.

• Option 1: Bill the Received Quantity + Add an Expense Line (Recommended)
  . On the Vendor Bill, bill the exact quantity that was received (matching the Item Receipt). Then, use the Expenses subtab on the same Vendor Bill to add a line for the "excess" amount the vendor is charging.
  • GL Impact: The item line hits Accrued Purchases (clearing the receipt), while the expense line hits a specific "Loss" or "Dispute" GL account (e.g., Vendor Dispute Loss or Misc. Expense).
  • Benefit: This keeps your inventory subledger clean. It avoids "ghost" inventory and prevents the system from triggering unnecessary PPV or Standard Cost adjustments on items you don't actually have.
• Option 2: Use an Inventory Adjustment to "Receive" and then "Write Off"
  If you must bill the item line directly for the full quantity, you would first need to enter an Item Receipt for the excess (using the "Allow Overage" preference if necessary). Immediately after, perform an Inventory Adjustment to remove that quantity from stock.
  • GL Impact: The adjustment will hit your Inventory and Inventory Adjustment (Expense) accounts.
  • Warning: This is generally less preferred because it artificially inflates your "received" metrics and can complicate your Standard Cost variance reporting.

Additionally, you can set Tolerance and Difference Limits (at the Subsidiary, Vendor, or Item level) to allow for minor discrepancies. If the bill exceeds the receipt within the defined tolerance (e.g., 2%), the bill can still be saved. If a bill is saved with a quantity discrepancy within tolerance, the Post Vendor Bill Variances process will calculate a Bill Quantity Variance to clear the remaining balance in your Accrued Purchases account. If the discrepancy is above the tolerance, NetSuite (or the 3-Way Match Workflow) will typically block the bill or route it for approval.

For the inventory-affecting bills, your observation is correct, adding an item line to a bill that is not matched to a receipt (or exceeds the receipt quantity) essentially treats the Vendor Bill as a "Receipt + Bill" in one step.

• GL Impact: It debits Inventory (at Standard Cost), credits Accounts Payable (at the Bill Rate), and posts the difference to PPV.
• Risk: This bypasses the Item Receipt process. For a manufacturing company, this is dangerous because it puts items into "Stock" that aren't physically there, which could cause a production order to be released for items you don't actually have.

All in all, For quantities that will never arrive, use an Expense Line on the Vendor Bill to pay the "penalty" or "dispute" amount. This keeps your inventory and manufacturing requirements (MRP) accurate while fulfilling the payment to the vendor.

Hello @Angelica Mae Segador-Oracle and @Ramu Komireddy_9891

I will test this shortly and let you know if it works.

I appreciate your help.

@Ramu Komireddy_9891

Please reference the suiteanswer article number when you quote suiteanswers? It helps others find the information.