-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: new DocTypes "Code List" and "Common Code" #43425
base: develop
Are you sure you want to change the base?
Conversation
The error message from the DB unique contraint isn't very helpful.
e26dec7
to
8e21087
Compare
|
Ensure the same reference is not used on a different Common Code of the same Code List.
12c746d
to
33cb489
Compare
More exploration from my side: barredterra#1 (Edi Template & Edi Log, squashed your naming fix |
Firstly, most of the time, however, unlike the common codes, these lists are akin to real constants in an e-invoice template. I would typically hard-code them for each distinct edi template. Here is an example: XML Example <cbc:IdentificationCode
listAgencyID="6"
listAgencyName="United Nations Economic Commission for Europe"
listSchemeURI="urn:oasis:names:specification:ubl:codelist:gc:CountryIdentificationCode-2.1"
>CO</cbc:IdentificationCode> Secondly, the title is still user friendly, for display purposes. Thirdly, as per the Genericode XML Schema, XML Reference<xsd:complexType name="Identification">
<xsd:annotation>
<xsd:documentation>Identification and location information (metadata).</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:group ref="gc:NameSet">
...
</xsd:group>
<xsd:element name="Version" type="xsd:token">
...
</xsd:element>
<xsd:element name="CanonicalUri" type="xsd:anyURI">
<xsd:annotation>
<xsd:documentation>Canonical URI which uniquely identifies all versions (collectively).</xsd:documentation>
<xsd:documentation>
<rule:text id="R25" category="document">Must be an absolute URI, must not be relative.</rule:text>
</xsd:documentation>
<xsd:documentation>
<rule:text id="R26" category="application">Must not be used as a de facto location URI.</rule:text>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:group ref="gc:VersionLocationUriSet">
...
</xsd:group>
<xsd:element name="Agency" minOccurs="0" type="gc:Agency">
...
</xsd:element>
</xsd:sequence>
</xsd:complexType>
...
<xsd:group name="VersionLocationUriSet">
<xsd:annotation>
<xsd:documentation>Identification and location URIs for a version.</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="CanonicalVersionUri" type="xsd:anyURI">
...
</xsd:element>
<xsd:element name="LocationUri" minOccurs="0" maxOccurs="unbounded" type="xsd:anyURI">
...
</xsd:element>
<xsd:element name="AlternateFormatLocationUri" minOccurs="0" maxOccurs="unbounded" type="gc:MimeTypedUri">
...
</xsd:element>
</xsd:sequence>
</xsd:group> Note, that Edit: I think this is what you where looking for: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have contributed the Genericode Importer which triggered a certain amount of polishing and I think this version is ready to merge, now.
We should keep in mind, that we're actively developing the EDI functionality for EU & Colombia in an iterative approach against develop
- so more to come, soon.
If we have to use this very technical name, we should at least offer the import from the list view (or from an unsaved form) instead of from the saved form view. It would be kind of weird if the user first needs to manually extract some values from the XML, in order to then import the rest of it. My approach was originally targeted at, e.g., being able to tell the users to create a Code List called "UNTDID.5305" and make sure it contains the tax codes they care about. The alternative, equally good or even better, would be being able to tell them to just import this code list. Telling them to extract the |
Fix UX of Title-less common codes in link dropdowns: |
Conclusion: We need to incubate a core feature "LazyRecords", which lazily traverse link values on on access but eagerly build the traversal tree 3-4 levels deep for best autocompletion. Inside, we then can replace standard Link bindings with our custom bindings. Whereby barren key renders the stringer of the target class in jinja (typically: name or title(?)). 🤣 |
We don't have multiple imports yet, so we can save one click and improve dicoverability.
- Allow re-import of the same code list to update existing data - Fill all Code List data on first creation, not just the name - Move import of Common Codes to common_code.py - Add type hints - Fix naming settings - Move static utils out of class - Remove unused import - Remove ignore_permission=True
I broke this again, sorry. Is this really valid? What use is a code if it can have multiple meanings, even in the same list? |
Yes.
Not sure if we productively can second-guess the spec — especially since I have a real codelist which exhibits this behaviour. Remember that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the better codelist handling — that looks a lot cleaner.
We'd just need to mitigate the two regressions:
- Insertion speed for Codes (removal of raw bulk insert) — I think this can be still achived after the clarifying refactorings by operating on a generator / list rather than on the individual record object
- Unique naming — we should aim to fix the silent bug in the previous implementation, as well
I broke this again, sorry.
Maybe I overlooked. But I'm not even quite sure if you broke it in principle 😄 or just accidentially via removing the idx
during import. 😄
common_code.code_list = code_list | ||
|
||
common_code.from_genericode(column_map, xml_element) | ||
common_code.save() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is unfortunately prohibitively slow 😢 — we should revert back to the bulk insert.
I don't quite see a use case to update a code list item: they don't change on the same version. If they change they change on a different version which is a different code list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prohibitively slow? I could't even blink while this imported my test data. How big are your code lists and how many do you want to import?
To be a bit more precise, on my machine this has a throughput of >200 records per second. And it needs to be done only once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prohibitively slow?
It was at least pretty annoying during local tests, so much so that I took care to make it faster (not by accident or not knowing better). Now you took the same care to make it slower (for other reasons not entirely evident to even though I tried to infer some), so I'll have to assume it's going to be "pretty annoying during local tests" again.
Maybe you want to first briefly explain these "other reasons"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I usually avoid bulk_insert
. Yes, it is fast, but the reason for that is that it skips all validations and hooks, making it error prone and hard to customize. I would rather wait a couple seconds instead of skipping all that good stuff. Sure, when a task would take many minutes or hours, we cannot avoid bulk_insert. But for saving a couple of seconds, I think it's not worth the (potential) trouble.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have now added a progress bar, so we don't have to stare at a blank screen during longer imports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Thanks. That makes sense, in principle.
Do we realistically expect the need for validations and hooks on mass import of Common Codes in practice, though? — I have a bit of a hard time to come to terms with the ask and presumption to deprioritize speed on abstract principle, alone.
The scenario here simply seems a bit far fetched to me.
The progress bar is a good idea to mitigate the problem. At least people wouldn't try to reload the page because it goes unresponsive.
It's been a while and I can't remember exactly how long it took. Granted, "prohibitively", indeed says as much about my personal tolerance level for slowness. 😊 Let me check it again report back, and when it takes more than 5 seconds, we revert back?
Return a tuple of results instead
Value can be a self-closing tag without a nested SimpleValue, i.e. `<Value ColumnRef="Alternative-Einheit"/>`
def validate_distinct_references(self): | ||
"""Ensure no two Common Codes of the same Code List are linked to the same document.""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For generating messages, it is very useful to have exactly one common code per ERPNext entity. However, for parsing messages, it would be useful to map multiple common codes to the same ERPNext entity. This is currently not possible due to this validation.
Screenshots based on https://www.xrepository.de/api/xrepository/urn:xoev-de:kosit:codeliste:untdid.5305_3:technischerBestandteilGenericode:datei:UNTDID_5305-3.xml
After this is merged, check if we should revert #40593 and #40663