Gostaria de acessar as informações, como por exemplo, cProd, mas não estou conseguindo.

Rodei a seguinte linha de codigo:

nota.infNFe.det(nItem="1")

Retornando: TypeError: 'list' object is not callable

assinatura eh gerenciada por fora geralmente, entao vale a pena tirar os elementos
<xs:element ref="ds:Signature"/>
e <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-schema_v1.01.xsd"/>
no procprocessamento que isso alivia bastante o python gerido.

Sei que não é um problema, mas preciso saber se existe algum método onde eu ja passo o xml(nfce) e verifico se ele é valido baseado no schema da sefaz

for instance the enviNFe_v3.10.xsd is including leiauteNFe_v3.10.xsd then both enviNFe_v3.10.py and leiauteNFe_v3.10.py have the same massive TNFe class

Implementação das seguintes regras de validações:

207 Rejeição: CNPJ do emitente inválido

Ao carregar um XML deve ser validado o valor da TAG: infNFe/emit/CNPJ se o valor é um CNPJ válido.

208 Rejeição: CNPJ do destinatário inválido

Ao carregar um XML deve ser validado o valor da TAG: infNFe/dest/CNPJ se o valor é um CNPJ válido.

Deve ser adicionado a dependência do erpbrasil.base para utilizar o método de validação do CNPJ.

Não consigo pegar os atributos de protNFe. Quando é feito o parse do arquivo, não é carregado este nós junto. Por favor, me ajudem com isso. Desde já, grato.

The ICMS, IPI and other taxes have as much subclasses as the number of possible tags. This is quite verbose and it would be better to have a dynamic factory of the proper tax classes according to their constructor values.

Your call... This might not be important...

McCabe measure of cyclomatic complexity is built into flake8 with a recommended default value of 10.

Perhaps this block of generated code might be a bit too complex.

$ flake8 . --select=C --max-complexity=37

./nfelib/v4_00/retDistDFeInt.py:177:1:      C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retConsStatServ.py:177:1:      C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retEnvEvento.py:177:1:    C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retInutNFe.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/distDFeInt.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retEnvCCe.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retEnvEventoCancNFe.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retConsReciNFe.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retEnviNFe.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retConsCad.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retConsSitNFe.py:177:1: C901 'TryExcept 177' is too complex (164)
./nfelib/v4_00/retEnvConfRecebto.py:177:1: C901 'TryExcept 177' is too complex (164)

Olá.

Estou tentando utilizar a lib com AWS Lambda mas não estou conseguindo.
Mesmo criando uma layer na hora de importar da erro de timeout.

import json
from nfelib.v4_00 import leiauteNFe_sub as parser



def lambda_handler(event, context):
    # TODO implement
    return {
        'statusCode': 200,
        'body': json.dumps('Hello from Lambda!')
    }

Alguém já teve esse problema, conseguem me ajudar?

better example: get_emit().get_CPF() -> get_emit().get_CNPJ()

Com essa biblioteca, é possível montar o PDF de um DANFE com os dados de um DANFE já gerado e validado?

Validações da Tag de Identificação do Emitente

Quando coloco para ler um xml, aparece o seguinte erro:

'NoneType' object has no attribute 'get_emit'

Aparece tambem esses textos no terminal:

<?xml version="1.0" ?> <TNFe/>

Alguma ideia de como passar desse ponto?

Obrigado!

Vi que a ultima atualização foi em 2021 e que tem muitas issues aberta.
Gostaria de saber esse pacote existe ainda ou se ele foi movido para outro lugar

Eventually we trim the lib down a little. Seems we would have to do it in Python. Still is it a good idea? For instance will we want to import the signatures from the incoming invoices into the ERP?

OLá pessoal, como eu poderia pegar a ID ?

Tentei assim:
notaXML.infNFe.id
notaXML.protNFe.infProt.chNFe e assim e não foi...

AttributeError: 'TNFe' object has no attribute 'protNFe'

Outros atributos da nota, eu consigo pegar normalmente se estiverem dentro do infNfe.

something like https://github.com/danimaribeiro/PyTrustNFe/blob/master3/pytrustnfe/nfe/__init__.py
or
https://github.com/wmixvideo/nfe/blob/master/src/main/java/com/fincatto/documentofiscal/nfe400/webservices/WSFacade.java

probably in packaging branch and thus merged into the lib at the end.

I made it work with xsdata nested types, but now xsdata supports unesting:
tefra/xsdata#670
any interest?

PORQUE MUDAR PRO XSDATA

1. xsdata é uma lib absurda! apareceu do nada em 2020 e muita gente ja considera a melhor lib para lidar com xsd independente de qualquer linguagem, o que não é pouca coisa considerando os investimentos que tiveram nos projetos concorrentes por 2 decadas, Java ou .Net em especial.
2. o xsdata tem uma suite de tests super completa, é testada com os xsds mais exigentes que existem (tests do W3C, UBL...)
3. o codigo do xsdata é examplar, muito bem testado
4. o desenvolvedor do xsdata é super reativo
5. xsdata deu conta de todos documentos fiscais do Brasil com 10x menos trabalho do que o generateDS (eu tinha feito uns 6 patches no generateDS para suportar a nfelib 1.x).
6. xsdata foi pensado para lidar com pacotes de varios xsd e includes de arquivos, o que é exactamente o que temos no Brasil. Com o generateDS a gente tinha que fazer varias gambiarras para suportar isso, como conservar apenas alguns arquivos geridos para não duplicar muito codigo.
7. os bindings xsdata são dataclass Python padrão. Nisso é um codigo 5x mais compacto do que os bindings geridos pelo generateDS. Isso nos permitiu de trabalhar tudo na mesma branch com os schemas e o codigo gerido. Enquanto na versão 1.x a gente tinha os schemas na branch master e a gente gerava os bindings numa outra branch com muito codigo, como se fosse um pouco um codigo compilado onde seria muito mais dificil acompanhar mudanças (atualizar o generateDS mudava bastante o codigo gerido por examplo). Com xsdata, apenas evoluçoes dos esquemas mudam o codigo dos bindings e fica super facil acompanhar.
8. assim como o generateDS, o xsdata foi pensado para ser extendido e gerar outros modelos. Foi o que eu fiz pro Odoo no https://github.com/akretion/xsdata-odoo para gerar os mixins abstratos dos modelos de dados fiscais no Odoo, nosso foco principal na Akretion.
9. enquanto isso, o generateDS serveu, mas hoje esta no caminho de ser abandonado pro xsdata. O codigo do generateDS não é muito moderno, da até um pouco de medo e esta hospedado no mercurial no Sourceforge hoje, algo que ninguem mais usa...

para maiores informações: https://www.youtube.com/watch?v=6gFOe7Wh8uA

COMO MIGRAR

1. O caminho onde estão os bindings mudou. Pois com a experiença da nfelib 1.x, refinamos para suportar mais facilemente varios documentos fiscais e varias versões. Em especial, agora apenas 2 digitos caracterizam a versão nas pastas: assumimos que se menos de 2 digitos mudam se trata de uma mudança menor que iria apenas atualizar os schemas existentes enquanto se tiver uma mudança no primeiro ou segundo digito (por examplo NFe 4.0.x para NFe 4.1.x) ai poderiamos ter varias pastas para suportar varias versões ao mesmo tempo.
2. O nome das classes dos bindings mudou. O xsdata deixou tudo mais "pythonico", os nomes ficaram parecidos. Basta buscar pelo nome da tag original nos arquivos de bindings para ver como ficou o nome com xsdata.
3. Salve algumas exceções que vc pode encontrar la lista de substituçoẽs https://github.com/akretion/nfelib/blob/master-xsdata/.xsdata.xml#L20 o nome dos campos não mudou e ficam igual dos elementos dos xsd.

EXAMPLOS

IMPORTAÇAO DE XML

Antes:
https://github.com/akretion/nfelib/blob/master_gen_v4_00/tests/nfe/test_nfelib.py#L27

Depois:
https://github.com/akretion/nfelib/blob/master-xsdata/tests/nfe/test_nfe.py#L54

SERIALIZAÇAO DE XML

Antes:
https://github.com/akretion/nfelib/blob/master_gen_v4_00/tests/nfe/test_nfelib.py#L29

Depois:
https://github.com/akretion/nfelib/blob/master-xsdata/tests/nfe/test_nfe.py#L56

TRANSMISSÂO SOAP

Antes:
Para quem usava erpbrasil.edoc para transmitir o codigo relevante era feito aqui: https://github.com/erpbrasil/erpbrasil.edoc/blob/master/src/erpbrasil/edoc/nfe.py

Depois:
O mesmo tipo de transmissão pode agora ser feito usando esse wrapper "legacy" pro erpbrasil.edoc:
https://github.com/akretion/nfelib/blob/master/nfelib/nfe/ws/edoc_legacy.py

ver https://github.com/akretion/ooor/blob/master/lib/ooor/type_casting.rb

Validações da Tag de Documento Fiscal Referenciado

when importing nfe's with non ascii chars in Python we have this kind of errors:

>>> len(str(u'blé'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 2: ordinal not in range(128)

the generated code would need to be rewritten like:

>>> len(str((u'blé').encode('utf-8')))
4

(And this works with Python 2 also)
As the error occurs only with Python 2, do we care about it?

Identificação do Destinatário

Na criação de uma nova NF-e/NFC-e deveria ao criar o Objeto NFeType ser gerado o conteúdo do campo id que contém a chave de acesso da NF-e de forma automática, pois o valor do campo id é um conjunto de informação da NFe:

• cUF - Código da UF do emitente do Documento Fiscal;
• AAMM - Ano e Mês de emissão da NF-e;
• CNPJ - CNPJ do emitente;
• mod - Modelo do Documento Fiscal;
• serie - Série do Documento Fiscal;
• nNF - Número do Documento Fiscal;
• tpEmis – forma de emissão da NF-e;
• cNF - Código Numérico que compõe a Chave de Acesso;
• cDV - Dígito Verificador da Chave de Acesso.

Cálculo do Dígito Verificador da Chave de Acesso da NF-e

O dígito verificador da chave de acesso da NF-e é baseado em um cálculo do módulo 11. O
módulo 11 de um número é calculado multiplicando-se cada algarismo pela sequência de
multiplicadores 2,3,4,5,6,7,8,9,2,3, ..., posicionados da direita para a esquerda.

A somatória dos resultados das ponderações dos algarismos é dividida por 11 e o DV (dígito
verificador) será a diferença entre o divisor (11) e o resto da divisão:
DV = 11 - (resto da divisão)
Quando o resto da divisão for 0 (zero) ou 1 (um), o DV deverá ser igual a 0 (zero).
Exemplo: consideremos que a chave de acesso tem a seguinte sequência de caracteres:

Implementar as validações de Inscrições Estaduais:

209 Rejeição: IE do emitente inválida

Ao carregar um XML deve ser validado o valor da TAG: infNFe/emit/IE se o valor é uma inscrição estadual é válida.

210 Rejeição: IE do destinatário inválida

Ao carregar um XML deve ser validado o valor da TAG: infNFe/dest/IE se o valor é uma inscrição estadual é válida.

211 Rejeição: IE do substituto inválida

Deve ser adicionado a dependência do erpbrasil.base para utilizar o método de validação do CNPJ.

Na nova branch master-xsdata que usa xsdata, temos um pequeno problema com o elemento IPI da tag Imposto. Da forma como é o xsd, ou precisa de um patch de 1 linha no xsdata, ou precisa usar a opçâo --compound-field do xsdata. Eu detalhei o problema aqui: tefra/xsdata#666

De inicio, pode parecer uma boa usar a opção --compound-field já que resolve o problema no binding gerido como aqui. Porem tem um outro lado da moeda: quando usar essa opção, tem pelo menos 2 campos (IPI do Imposto e um outro no Transp) que viram então um campo composto com uma hierarquia mais funda:

Sem a opção --compound-field e com meu patch tefra/xsdata#666:

            @dataclass
            class Imposto:

                v_tot_trib: Optional[str] = field(
                    default=None,
                    metadata={
                        "name": "vTotTrib",
                        "type": "Element",
                        "namespace": "http://www.portalfiscal.inf.br/nfe",
                        "white_space": "preserve",
                        "pattern": r"0|0\.[0-9]{2}|[1-9]{1}[0-9]{0,12}(\.[0-9]{2})?",
                    }
                )
                icms: Optional["Tnfe.InfNfe.Det.Imposto.Icms"] = field(
                    default=None,
                    metadata={
                        "name": "ICMS",
                        "type": "Element",
                        "namespace": "http://www.portalfiscal.inf.br/nfe",
                    }
                )
                ipi: Optional[Tipi] = field(
                    default=None,
                    metadata={
                        "name": "IPI",
                        "type": "Element",
                        "namespace": "http://www.portalfiscal.inf.br/nfe",
                    }
                )

Agora com a opção --compound-field e sem meu patch:

            @dataclass
            class Imposto:
                v_tot_trib: Optional[str] = field(
                    default=None,
                    metadata={
                        "name": "vTotTrib",
                        "type": "Element",
                        "namespace": "http://www.portalfiscal.inf.br/nfe",
                        "white_space": "preserve",
                        "pattern": r"0|0\.[0-9]{2}|[1-9]{1}[0-9]{0,12}(\.[0-9]{2})?",
                    }   
                )  
                icms: Optional["Tnfe.InfNfe.Det.Imposto.Icms"] = field(
                    default=None,
                    metadata={
                        "name": "ICMS",
                        "type": "Element",
                        "namespace": "http://www.portalfiscal.inf.br/nfe",
                    }
                )  
                choice: List[object] = field(
                    default_factory=list,
                    metadata={
                        "type": "Elements",
                        "choices": (
                            {
                                "name": "IPI",
                                "type": Tipi,
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "II",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Ii"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "ISSQN",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Issqn"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "PIS",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Pis"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "PISST",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Pisst"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "COFINS",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Cofins"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "COFINSST",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Cofinsst"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                            {
                                "name": "ICMSUFDest",
                                "type": Type["Tnfe.InfNfe.Det.Imposto.Icmsufdest"],
                                "namespace": "http://www.portalfiscal.inf.br/nfe",
                            },
                        ),
                        "max_occurs": 9,
                    }
                )

Nesse caso o xsdata tem uma espece de gestão de choice.

O grande ponto é que nos temos um interesso não apenas nos bindings Python mas tb nos modelos Odoo geridos pelo plugin https://github.com/akretion/xsdata-odoo
Esses modelos Odoo são de persistência e é interessante que seja muito mais "planos" do que os modelos super fundos do XSD que servem apenas para validação XSD. E usar a opção --compound-field iria atrapalhar nisso porque nos obrigaria a repensar o mapeamento entre um campo Odoo e um campo de um binding dessa lib, criaria mais complexidade no mapping.
Se essa opção tb lidava com as verdadeiras tags choice do xsd como fazia o generateDS (que nos interessa apenas nas visões automáticas, ou seja muito pouco hoje), eu bancaria essa complexidade. Mas não é o caso, seria uma complexidade meio inútil.

Eu fiz uma busca exaustiva e o problema acontece apenas com essa tag IPI na dezena de esquemas de NFe que temos nessa branch. Com tudo o meu fix aqui tefra/xsdata#666 resolve isso perfeitamente (eu gerei tudo de novo e vi que o impacto era apenas o esperado aqui).

Nisso minha escolha é de usar esse patch de uma linha no xsdata ou então no código Python gerido apenas pela tag IPI.

cc @mbcosta @renatonlima @marcelsavegnago @netosjb @felipemotter

Bom dia a todos!

A versão atual, quando vamos utilizar, dá o seguinte erro:

from nfelib.v4_00 import leiauteNFe_sub as parser
Traceback (most recent call last):
File "", line 1, in
ModuleNotFoundError: No module named 'nfelib.v4_00'

Um fork que tenho de 13 commits atrás funciona normalmente.

Cordiais saudações a todos.
Florêncio

Olá pessoal! Estou tentando gerar uma NFse mas aparentemente os métodos to_xml e validate_xml não estão presentes no objeto. Há alguma forma disso ser feito?

AttributeError: type object 'Nfse' has no attribute 'to_xml'

Para melhorar a legibilidade do código seria interessante remover dos nomes das classes o Type no final, pois acaba poluindo muito o código.

that being said, the benefit is little only 5 or 6 enums factored in such a schema:
TCodUfIBGE xs:string
TMod xs:string
TUf xs:string
TUfEmi xs:string
TAmb xs:string
TCOrgaoIBGE xs:string
TTransformURI anyURI

Validações da Tag de Local da Retirada

Algumas tags como por exemplo a tag do total de frete da NF-e (vFrete dento da tag ICMSTot) deve aparecer com o valor padrão mesmo que não tenha sido declarada na criação do objeto ICMSTotType, pois atualmente essas tags não são geradas no XML o que acaba gerando um XML inválido, pois não contém tags obrigatórias.

Exemplo de um XML de NF-e gerada pelo nfelib:

Exemplo de um XML de NF-e esperado:

** OBS: ** Um workaround é informar as tag na criação do objeto.

see http://www.davekuhlman.org/generateDS.html#how-to-modify-the-generated-code
http://www.davekuhlman.org/generateDS.html#examples-and-demonstrations

(works with v3_10 and not v4_00)

Prezados amigos,

Os últimos Commits estão quebrando a instalação:

ERROR: Command errored out with exit status 1:
command: /usr/bin/python3 -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-req-build-66ksj8xy/setup.py'"'"'; file='"'"'/tmp/pip-req-build-66ksj8xy/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(file);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-ref5mt4v
cwd: /tmp/pip-req-build-66ksj8xy/
Complete output (28 lines):
running bdist_wheel
running build
running build_py
creating build
creating build/lib
creating build/lib/nfelib
copying nfelib/init.py -> build/lib/nfelib
running egg_info
creating nfelib.egg-info
writing nfelib.egg-info/PKG-INFO
writing dependency_links to nfelib.egg-info/dependency_links.txt
writing requirements to nfelib.egg-info/requires.txt
writing top-level names to nfelib.egg-info/top_level.txt
writing manifest file 'nfelib.egg-info/SOURCES.txt'
warning: Failed to find the configured license file 'LICENSE'
reading manifest file 'nfelib.egg-info/SOURCES.txt'
writing manifest file 'nfelib.egg-info/SOURCES.txt'
installing to build/bdist.linux-x86_64/wheel
running install
running install_lib
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/wheel
creating build/bdist.linux-x86_64/wheel/nfelib
copying build/lib/nfelib/init.py -> build/bdist.linux-x86_64/wheel/nfelib
running install_egg_info
Copying nfelib.egg-info to build/bdist.linux-x86_64/wheel/nfelib-1.0.egg-info
running install_scripts
error: [Errno 2] No such file or directory: 'LICENSE'

ERROR: Failed building wheel for nfelib

Eu voltei os últimos 7 commits e ele volta a instalar.

Obrigado e abraços cordiais a todos.

Florêncio

olhando o diff de https://github.com/wmixvideo/nfe me deparei com esse arquivo de status de retorno. Vale a pena ter eles no nfelib? Parce que não temos eles hoje (grep rapido).
https://github.com/wmixvideo/nfe/blob/73030816c9c5d5d97ffbc7c1a4eed7659f942726/src/main/java/com/fincatto/documentofiscal/nfe400/classes/NFRetornoStatus.java

AttributeError: 'NoneType' object has no attribute 'get_emit'
Fiz de acordo com o exemplo mostrado e estou recebendo esse erro

Eh interessante distribuir os schemas XML e os arquivos de teste respectivamente para validar as NFe's usando o schema delas e para ter dados de demo mão para fazer testes em outros projetos como fazemos no OCA/l10n-brazil.

Nas o problema é que na nfelib 1.x esses arquivos de schemas e de tests/demos estavam sendo instalados fora da lib numa "dist" install.

Fica facil examplificar na hora de de-instalar a lib:

rvalyi@rvalyi-laptop:~/DEV$ sudo python -m pip uninstall nfelib
Found existing installation: nfelib 1.3.1
Uninstalling nfelib-1.3.1:
  Would remove:
    /usr/local/lib/python3.10/dist-packages/nfelib-1.3.1.dist-info/*
    /usr/local/lib/python3.10/dist-packages/nfelib/*
    /usr/local/lib/python3.10/dist-packages/schemas/README.txt
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/CCe_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/confRecebto_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/consCad_v2.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/consReciNFe_v4.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/consSitNFe_v4.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/consStatServ_v4.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/distDFeInt_v1.01.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/e110110_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/e110111_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/e210200_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/e210210_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/e210220_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/e210240_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/envCCe_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/envConfRecebto_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/envEventoCancNFe_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/envEvento_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/enviNFe_v4.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/eventoCancNFe_v1.00.xsd
    /usr/local/lib/python3.10/dist-packages/schemas/nfe/v4_00/inutNFe_v4.00.xsd
    ...
    /usr/local/lib/python3.10/dist-packages/tests/*

Funcionava, mas com a multiplicação dos tipos de documentos fiscais que vão ser suportados isso não era bem sustentável...

Na nova branch master-xsdata, a futura nfelib 2.x, eu resolvi isso com um novo layout dos arquivos de schemas e de examplos. Vale a pena notar que na nfelib 2.x eu ainda empacotei os bindings generateDS da nfelib 1.x no mesmo caminho para garantir a compatibilidade brackward por um certo tempo (até 2024?).

might be required, to import from different schemas for instance

Importando uma NF-e de importação direta (NF-e de entrada de mercadoria através de importação) A tag II está na posição errada, em um na NF-e válida:

Importando essa NF-e e exportando através do nfelib:

parece que fora alguns tabs, esses arquivos são iguais:

rvalyi@rvalyi-laptop:~/DEV/nfelib2$ find nfelib | grep -i distDFeInt
nfelib/nfe_dist_dfe/schemas/v1_0/retDistDFeInt_v1.01.xsd
nfelib/nfe_dist_dfe/schemas/v1_0/distDFeInt_v1.01.xsd
nfelib/cte_dist_dfe/schemas/v1_0/distDFeInt_v1.00.xsd
nfelib/cte_dist_dfe/schemas/v1_0/retDistDFeInt_v1.00.xsd
nfelib/mdfe_dist_dfe/schemas/v1_0/distDFeInt_v1.00.xsd
nfelib/mdfe_dist_dfe/schemas/v1_0/retDistDFeInt_v1.00.xsd

talvez seria melhor simplificar?