Skip to main content

I have REALLY crazy one here.  Our customer works with finance companies who require a separate invoice for each ITEM shipped.  In their current system, they have an option to “split an invoice” into multiple invoices AFTER the invoice from the shipment is created.  CRAZY.

In Acumatica, assume I am selling 2 tractors on one Sales Order.  The customer is having the tractors financed by a finance company, so the invoices will go to the Financier.  

On the Process Shipments screen, if I Prepare Invoices, it will produce one invoice per shipment.  I know about the Batch checkbox you need to uncheck in the Shipments screen action “createInvoice”.  That helps, but does not do what I need.

They do NOT want shipments to be split.  Just the invoices from the shipment.

There are 3 things I can come up with to get a single invoice per ITEM on the Sales Order that has been shipped.

  1. Before the Sales Order is shipped (at the Sales Order screen where the CREATE SHIPMENT button is available), write code that will “COPY” the order into two new orders and delete the original order.    I’ve tried doing this with a custom action on the SO screen but I am having issues doing it.  I tried to use the “Copy To” action on the SO menu in VS but I can’t find a way to get that to work either.  I thought, copy the SO to TWO new orders and delete the original using “Copy To”.  After copying the SO, manually change the lines to 1 item per order.  This means there could be one SO with 2 lines and each line has 2 items.  This would result in 4 SO’s. IF I can even do that, the customer HATES this option.
  1.  Put logic on the Sales Order screen that for a Financier customer, only 1 item and 1 line is allowed to be saved.  This will force one shipment per order and consequently 1 invoice per order.  The customer HATES this option too.
  1. On the Process Shipments screen, do not allow shipments to be processed if the customer is a Financier UNTIL the Shipment is programmatically split into multiple shipments.  I have already created code to do this, but it only disallows the shipment to be invoiced.  Here is a print screen of that so far:

If you try to PROCESS ALL, the lines that Requires Split are unchecked and NOT invoiced.

I put an action on the screen SPLIT SHIPMENT that has no code in it.  My thought is to use that action to grab all the Requires Split rows and do some REALLY DANGEROUS low level database manipulation to take shipment 000016 and create two new shipments and delete the original.  I’d have to make sure the 2 new shipments are in a Confirmed status and have all the underlying references to the original SO.  I’d have to make sure any references to 000016 are changed to match the two new Shipments.

I don’t think I really have any choice other than to try to enforce 1 line and 1 item per line in the original SO.

Any thoughts on this?

Quick edit:  I looked into trying to override the process that is Preparing Invoice, but I don’t think I can do that either.

Just as an aside, there can be sales tax implications depending on the rules of the tax jurisdiction depending on how you invoice. But, in this case, that discussion is probably out of scope (and, honestly, may not apply).

Just thinking about his another way that might be easier to implement and potentially follow/audit:

Allow the invoice to be created for the two tractors and if the “This is being financed” checkbox is checked you do the following when the invoice is released:

Create a credit memo for the invoice and apply it.

Create an debit memo for each invoice that the financing company wants and, optionally, apply it to the original invoice.

The net result is that the balance of the invoice is correct and the financing company has all of their “invoices”. Number the debit memos manually so that they reference the original sales number.

You don’t need to apply the debit memos to the invoice - they could just exist on their own but there should be a super easy way to look at one of these debit memos to know what the source transaction was supposed to be.

I feel like this gives you much more control over the different sets of transactions and doesn’t require heavy manipulation/adjustment to the existing processing routines.


@Django I love this idea.  I’m going to present it to them today and see if they are willing to go with this approach.  It is awesome because I don’t have to mess with Acumatica tables!


Reply