remember customer fields for eRechnung

thgagel

Customer fields already filled out in eRechnung should be remembered for future entries for this customer (UStID, Leitweg-ID etc.).

SubTotal version: 1.5,62
Operating system: macOS
Device model: iMac Pro

timo

The main reason this isn't being done at the moment is that the database doesn't have fields to store this kind of information.

You can put the VAT ID and buyer reference (Leitweg-ID) into the clients address field, from where it will be parsed and pre-fill the e-invoice fields. Is there a specific reason this is not suitable for you?

What would you expect to happen if you write two invoices to the same client, but enter two different VAT IDs (for whatever reason)?

If the app stored this information, would it be sufficient if this information is being cached locally on your device (and not stored in the database), so when using the Cloud Sync, that informations would not be synced alongside the database?

thgagel

UStID is prone to misuse and should not be exposed if this is not absolutely necessary. And it is not an element of a ladungsfähige Adresse and may invalidate such an address.

The last entry wins (overwrites existing UStID and LeitwegID).

Ask yourself: "Would it be sufficient if something is not working as expected?" No.

timo

What do you mean with "should not be exposed"? Where is it exposed and to whom?
VAT IDs isn't secret information, you need to share it with your business partners and many companies are displaying it publicly on their websites.
I also don't understand what you mean with your second sentence, that it would invalidate an address.
You didn't respond to my question if storing this information locally (and not in the SubTotal database) would be sufficient. Would it? The fields could then auto-populate but reinstalling the app (or installing it on another device) would mean this information is cleared (until you re-enter it). This would be much easier to implement compared to adding fields for this to the SubTotal database schema

thgagel

What do you mean with "should not be exposed"? Where is it exposed and to whom?

Some valid reasons can be fount if searching for "UStID Missbrauch". It is exposed in the address field.

I also don't understand what you mean with your second sentence, that it would invalidate an address.

"Die ladungsfähige Anschrift bezeichnet in Gesetz, Rechtsprechung und juristischer Literatur einen Wohnsitz oder eine andere Anschrift (§ 68 Abs. 2 Satz 1 StPO), bei Unternehmern eine Geschäftsanschrift, nach Land, Ort, Postleitzahl und Straße, also eine Postanschrift, unter der eine Rechtspartei tatsächlich anzutreffen ist.
Die Angabe einer ladungsfähigen Anschrift wird im Rechtsverkehr in verschiedenen Zusammenhängen gefordert,..." (Wikipedia).
Additional elements in an address may invalidate its function as ladungsfähige Anschrift.

If the app stored this information, would it be sufficient if this information is being cached locally on your device (and not stored in the database), so when using the Cloud Sync, that informations would not be synced alongside the database?

This would be a cheap workaround. I would not participate in such a way of working. But well, if it solves my problem, you may do it so.

timo

thgagel Additional elements in an address may invalidate its function as ladungsfähige Anschrift

Where does it say that? It doesn't say that in the text you quoted.
Besides that, this feature request is about the customer address, but I think what you are referring to now is the "ladungsfähige Adresse" of the seller

thgagel This would be a cheap workaround. I would not participate in such a way of working

Can you elaborate why exactly you consider this a bad solution and what you would suggest otherwise?
Another idea I had was to always store the entire e-invoice XML along with the invoice in the database. But it would come with other drawbacks: It would increase the size of the database (especially in proportion to the current size). And what should happen hen the user changes parts of the invoice (e.g. the client name) or the "My company" details after creating an e-invoice? When re-creating the e-invoice (or create a new invoice with the same client), should it use the data from the stored e-invoice XML or use the current logic (e.g. parse VAT ID from client address field) to prefill values into the e-invoice dialog? Or should the app use one as the primary source and the other as a fallback?

thgagel

I referred to the "ladunsgfähige Adresse" of the customer. The "Zugang" of an invoice is relevant for the "Fälligkeit". Any additional information in a "ladungsfähige Adresse", that may introduce misunderstanding or cause errors will weaken or even invalidate the address and thus the "Zugang" and "Fälligkeit".
There are a lot of examples of addresses on the internet, that are not accepted by the Deutsche Post. Even placing of "Hausnummer" before the street name or using a comma in any address line may be a reason for a letter being rejected.

Instead of storing the complete XMLs, why not storing only the extra customer related fields entered in the E-Rechnung dialog? If these are synchonized between devices, this would be fine for me.

timo

Can you give any reference that shows that having the VAT ID showing on the same place as the customers address is invalid on an invoice? I have never heard of something like that before and I have received invoices from Apple that show VAT IDs in both customer and seller address. So you are saying Apple is doing it wrong?

thgagel Instead of storing the complete XMLs, why not storing only the extra customer related fields entered in the E-Rechnung dialog? If these are synchronized between devices, this would be fine for me

Because that would mean I'd had to add many more fields to the SQLite database schema instead of one (for the invoice XML). There are tons of "extra customer related fields", not just 3 or 4

thgagel

timo

As you say there are tons of "extra customer related fields". All of these cannot go into the address.

Maybe a JSON in a single text field could be an option for a varying amount of customer related fields. Basic configuration might be a list with fieldname -description, editing by user could be a dialog with fieldname fieldvalue and storage as JSON in a single text field in SQlite.