timo Currently the app does not try to find any purchase order from the free text fields.
OK. This is only a minor inconvenience that we can certainly live with for the time being. I mainly asked to avoid vainly testing different formats for the PO in search for the one that gets recognized.
timo as you said, PO numbers are common in the US, but e-invoices are not, from what I know
Actually, we were surprised ourselves how many of our customers insisted on a PO to accept e-invoices. Granted, these were mostly German branches of international companies, but still, the combination of e-invoice and PO might be much more common in Europe than you think. FrankPflugbeil seems to have experienced something similar.
timo Perhaps this could be solved with a something similar to what I suggested here or what you have requested here?
I don’t think typing something like "PO 12345{BT13:12345}" in a text field is much easier that typing just "PO 12345" and then copying "12345" and pasting it into the corresponding e-invoice dialog text field (though this might be a good idea for generically adding XML BT-nn fields that have no correspondence in the e-invoice GUI).
My own request that you linked to referred more to the PDF layout than the actual data extraction from the PDF (unless you add a specific PO text field, just like the Invoice Date text field). I still think data extraction from two or three predefined and documented formats like "PO {1+ digits}" would be the best solution in the long run for this case, but as I said, that is not critical as long as we can add the PO (BT-13) manually, as we now can.
