Process Issues

The disconnect between what happens in NetSuite and Payment Platforms

For projects that utilize Textura, the billing is handled here. Invoices (or other transactions) in NetSuite either do not go through their proper life cycle, or presumably Accounting handles them after the fact once the GC disburses payment. Even if Accounting handles it after the fact, they use spreadsheets to keep track of how to apply the disbursements. This seems like the obvious question so i'm sure it's already been considered, but is there a way to reference an invoice number to a pay application in Textura? Would this even help?

Deduct Change Orders appear to be quite problematic. If the GC wants to remove a line item, the PC will either delete the item off the Sales Order or zero out its amount to reduce the total amount of the Sales Order. I need to understand how this is impacting the GL and what bandage Accounting most likely has to employ to solve this.

RMAs get ignored after the Item Receipt. They are left in a Pending Refund state. I'm sure Accounting patches this hole with a JE, but it probably makes sense to find a way to not have to patch it and issue the refund so the projects financials are correct and the RMA can complete its lifecycle.

Multiple sales orders for a project, does this make a PC's and Billing's job harder?

PCs make a file for each vendor in AQ and then export them one at a time over to NS creating a sales order each time. I assume if there was one Sales Order from the outset and Change Orders were just modifications of that Sales Order, that might be a better way to handle Change Orders in NetSuite. Furthermore, one Sales Order would probably simplify deposits and progress billing.

Customer deposits

If you take a payment directly from a Sales Order, it creates a Customer Deposit, which can then be applied correctly to that Sales Order and more easily tracked in the projects financials. If our customers are paying via Textura, then I assume Accounting is manually creating a Customer Deposit and then applying it... It still begs the question, how do the customers know to pay it? Surely the ProForma isn't the trigger, or is it? Furthermore, if each project has multiple Sales Orders, and assuming Accounting manually applies the deposits, how do they know which SO to apply it to? How does this happen the Non-Textura way?

RMAs, the bain of a PC's existence

The PCs continue to be one of the last folks to know about equipment being returned, yet they drive much of RMA process. Why aren't they the second ones to know?

Compliance in Textura

Who is responsible for handling compliance and submitting documents for each project in Textura, a PC? How do we know when our subs need to provide a lien waver?

Item Groups or Assembly Items

We have an issue where an item in AQ has multiple sublines. Take for instance the E303, 120v power supply, with a specific drip pan. AQ sends this one unit over as 3 separate items; the base unit, the 120v power supply, and the drip pan. In reality, this is one unit, comprised of 3 components. In order to fulfill, receive, sell, count, or adjust correctly, you would have to perform the task for all 3 items. The solution to this would probably be to set this up as an Item Group or an Assembly Item so it bundles those 3 items together to make the 1 item. The AQ Integration does not currently do that.

When Items are replaced by another in AQ

So often times and item is replaced or swapped out by the mfg. Take EMU214870V4580 made by Cambro, it was replaced by EXMU214870V4480. However, the AQ ID for it was not changed. So when the file containing to replacement item is sent over to NS it still pulls up the old item.