Which address ID should one use when importing an invoice for a party with multiple addresses?
I’ve tried using the ID of the desired address, as well as the Full Address text string, but those both lead to a “Relation not found: in party.address.” error. If I use the ID of the party in question, I get a “Too many relations found: in party.address” error.
We have both an invoicing and a delivery address for all of our clients, which I would think is a fairly normal situation.
CSV import is very complex task and requires internal knowledge of the database and model design. For example, the relation of Many2One are searched by rec_name so the value encoded in the CSV must be sure to return a single record.
So this makes the CSV importation useful only for very simple case. And other case, we recommend to write a script using proteus.
But is there a particular reason why the invoice import won’t accept the actual Address record ID as input? You already have to feed it the Party Code to associate the invoice with a party in general.
At the very least, if the party has only one Invoice address, couldn’t that be used as the default?
Seems more like a bug.
Yes, CVS import does not work with ID because it is internal to the system so ID should not be exposed to the outside.
CVS import is just doing what it is told to do. It will never randomly trigger any events.
You really seem to look for scripting the UI instead of importing data. And this is exactly the goal of proteus.
Yet I can export the ID of almost any record.
If CSV import is just meant to be a tool to import raw data, wouldn’t it be rather more sensible if one could (if one wanted to) use internal IDs to precisely and explicitly import just the data one wants to import? Naturally this would also require code to handle updating records through CSV imports, rather than just creating new ones.
Besides, the invoice import seems a bit weird nevertheless. The CSV import dialog asks for an Invoice Address field, but will only actually accept a Party Code. That doesn’t quite seem right.
This I wholeheartedly agree with. This is just the way it should be.
Yes. Scripting, or rather, a set of full fledged Tryton modules is definitely our endgame. However, due to, well let’s call them ‘various business reasons’ that goal won’t be happening in a day, or even a year. Not even if said Tryton modules already existed.
So for now, we’ll be stuck with getting the data we need from various sources, and putting it together in, well, Excel unfortunately. Lucky for us, we only need import it to Tryton 1-4 times a year for invoicing. Thus, a CSV import is actually a fairly functional workflow for now.
Also, when we do import the invoices, we import thousands of them at once. So any non-bulk solution would not work.