import bug (payments): "Applied" amts don't get applied (but vtd does) - after recent patch!

[dylanh724]

The new backend patch a few days ago (on the 16th, iirc) brought in an additional bug: "Applied" amounts now get ignored.

These bugs are a bit too unstable, for me. I've been lingering at 99% for a couple months now -- From what I can see, post-import seems quite stable -- but these import bugs could use some serious review. My data seems fine -- Zoho imported everything fine on the first try. I tried on InvoiceNinja (after the update) 3 times in a row just to sanity check with purges each time.

1. Import customers + payments at same time
2. Map the usual info
3. Everything now imports except applied amounts.

Customers still show the correct VTD, so seems to be a payment-side bug only.

Desktop app.

Originally posted by @dylanh724 in #9614 (comment)

[turbo124]

Can you provide an exact test case here, perhaps a single line of a csv you are using and the associated mapping.

[dylanh724]

Can you provide an exact test case here, perhaps a single line of a csv you are using and the associated mapping.

I'll do even better: Repro'd with both video and minimal 1-row foobar data. First the data:

• customers-NODUPES-v5-FOOBAR.csv
• pmts-v5-FOOBAR.csv

These were both imported at the same time to customers and payments, respectively.

[dylanh724]

Can you provide an exact test case here, perhaps a single line of a csv you are using and the associated mapping.

https://youtu.be/BdVQpU3gaRY

Please let me know when satisfied with this unlisted video so I can take it down when done.

(PS: While recording this, you guys don't seem to trim empty rows - 1 extra chunk of data gets made with mostly confusing default values as seen near the end of this video as an added bug to reference alongside the foobar .csv's above)

[dylanh724]

CC @hillelcoren

[turbo124]

I do not think using the payment import is what you want to be using for this. I believe the invoice import will work they way you are expecting. Please reopen if you see a similar issue there.

[dylanh724]

I do not think using the payment import is what you want to be using for this. I believe the invoice import will work they way you are expecting. Please reopen if you see a similar issue there.

Applied payment mapped to applied payment and it didn't map. Although invoices may be more favorable for this situation as you say, this is still a breaking import bug, regardless, that may spread to invoices.

Invoices have even more import bugs (that could easily involve this bug - I'll try again soon), so I was originally planning to ditch invoice history as long as I can get payment history and vtd.

No matter what, this bug is still a breaking import bug for payments.

@turbo124 That said, I'm not sure why this ticket was closed if the map worked for everything except "Applied" when mapped correctly. I may lose some invoice data this way, but payments are absolutely expected to be applied.

[turbo124]

The System applies a sanity check on the applied amount, it is directly linked to the invoice where it is "applied"

[dylanh724]

The System applies a sanity check on the applied amount, it is directly linked to the invoice where it is "applied"

If that's the case, wouldn't it be expected to create a minimal invoice since I provided the amt + applied + invoice number + client? Unless item is required (but even then, why would a product be required as long as I have the total (eg -- total, but skipped breakdown)? In PayPal and Zoho, it's not required).

Why would the opposite work fine where I create an invoice and provide payment info which creates a minimal payment?

This seems to be proprietary knowledge that only the devs would possibly know; not what's actually expected (eg: This is a bug rather than a feat request).

[turbo124]

We've explained this one several times: here, email and also on the forum.

The best import structure for your dataset is an invoice import. It will create the invoice and matching payment if the payment amount provided in the column mapping.

There is not enough data in the payment import to calculate any of the information for the invoice creation.

[dylanh724]

We've explained this one several times: here, email and also on the forum.

The best import structure for your dataset is an invoice import. It will create the invoice and matching payment if the payment amount provided in the column mapping.

There is not enough data in the payment import to calculate any of the information for the invoice creation.

Apologies, but I've equally explained (and likely reported in one of my ~10 issue reports) there are too many invoice import bugs to use it that way after already providing foobar data. You mentioned you couldn't repro, but after I left foobar data, I didn't hear back from you.

I have not tested it since the 16th patch, though, so I will try again soon.

Invoice number + payment amt + payment applied + date is not enough? I found an old email that said that items are required. But why? Items are just a breakdown (hence the mention of expectations from multiple competitors where a minimal invoice is just date, item, invoice number, and client) -- from a high level perspective, items are a breakdown of detailed info while the total amount should satisfy a minimal invoice.

That's like a Trello card requiring you add explicit details or it won't let you submit. Sometimes all you need is high-level info. In this case, a dated invoice assigned to a client with a total amount / total applied should be expected to suffice.

Beyond this brings proprietary expectations (undocumented requirements) that only the devs know: Not even chatgpt 4o knows.