Carregando arquivo de XML de outra impressa

[mksbraga]

No meu sistema na parte de entrada Compra temos uma rotina que posso carregar o xml pelo compomente da Acbr para lancar a nota, mais referente a esta nota esta carregando 7 itens de um total de 11, uma coisa que notei é que a ordem dos itens esta saltiada. Gostaria de uma ajuda pra ver uma possibilidade de importar a nota corretamente.

Nfe42101105918301000112550010000086400000086404_v1.10-procNFe.rar

[André Ferreira de Moraes]

Vc está com seus fontes atualizados?

[mksbraga]

Posso verificar.

[mksbraga]

Mesmo assim nao carrega os 11 itens

[André Ferreira de Moraes]

Eu carreguei com o demo e todos os 11 itens foram carregados normalmente.

[peterson161]

- Qual DANFE que você utiliza ?

- Para carregar o arquivo você está utilizando o "LoadFromFile" ?

- Você prestou atenção se os outros itens não estão na página 2 ?

[mksbraga]

Mais isto no Nfe1.10 ou na Nfe2.0, por que to testando na 1.1 e nao vem os 11

[peterson161]

No 2.0

Já que você ainda está testando, não exite em mudar para a NF-e 2 pois a versão 1.1 em breve não será mais aceita.

[mksbraga]

Depois que atualizei o compomente esta dando este erro 'ImprimirDetalhamentoEspecifico não existe' isto esta correto ? E referente ao load do arquivo deu certo de carregar os 11, antes nao tinha dado certo por causa de dcu antigos... mandei limpar e recopilei deu certo.

[Juliomar Marchetti]

povo atualizei o svn

e está ocorrendo erro ImprimirDetalhamentoEspecifico faltando no FDANFEClassOwner

acho que é em especifico do fast report

[Alexsander]

Vocês têm importado XML dos fornecedores? Tenho visto várias coisas estranhas, como campos opcionais como o EAN vindo com zeros (0000000000000) ou erros de preenchimento (um fornecedor colocou a MVA de 61.71 no campo pICMSST (que devia ser 17.00). Parece que tem muita gente fazendo emissão de NFe "nas coxas".

No comércio, para emitir uma NFe de um produto com S.T. geralmente se usa CST 60, e teoricamente o fornecedor teria que ter colocado CST 10 na sua NFe. Há exceções, como sempre, conforme os estados de origem e destino -- há casos em que a NFe vem com tudo CST 00 e a cobrança de S.T. vem em guias separadas. O caso é que no registro ICMS60 tem dois campos, BC da ST e Valor da ST, que em teoria teriam que vir direto da NFe de entrada com CST 10.

Quais as validações que a SEFAZ faz no XML? Naquele caso em que o fornecedor colocou 61.71% como percentual de ICMS, o valor vICMSST estava correto, calculado com 17%, apesar dele ter informado 61.71%. Até que ponto pode-se confiar no que vem no XML?

[juaumkiko]

As informacoes contidas no XML são de responsabilidade do emitente, se essas informacoes estiverem incorretas será ela que poderá responder por isso.

Todas as validações que a SEFAZ faz estão descritas no manual de integração 4.0.1 se vc estiver usando a nfe 2.0.

Eu importo XMLs de fornecedores normalmente, nunca percebi nenhum erro, talvez pq eu leia somente alguns campos especificos. Poste o XML que a importacao esta errada e relate exatamente os campos que estao vindo errados.

Obrigado

[Alexsander]

Exemplo:

0
10
0
990.13
12.00
118.81
4
1675.46
61.16
166.01

Veja o campo "pICMSST", ele deveria ser o % do ICMS (17.00) mas no XML veio o MVA (61.16). O campo "pMVAST", que é opcional, não foi enviado. No final, o valor do ICMS ST está correto, apesar do % errado enviado -- aparentemente o software emissor dele enviou o conteúdo do campo "pMVAST" no campo "pICMSST".

vBCST = (vBC + vIPI) * pMVAST = (990,13 + 49.50) + 61.16% = 1675.46

vICMSST = (vBCST * pICMSST) - vICMS = (61.16% de 1675.46) - 118.81 = 905.90 (!)

Na prática o campo vICMSST foi calculado certo: (17% de 1675.46) - 118.81 = 166.01

Segundo o manual 4.01 (p. 40), apenas o ICMS "padrão" (vBC * pICMS) é checado. Quando há S.T. nenhum cálculo é feito nos campos adicionais -- pelo menos por enquanto. Isto é um problema para quem vende com ST 60 porque o grupo ICMS60 (p. 133) requer os campos vBCSTRet e vICMSSTRet -- que em teoria são calculados a partir de valores informados pelo fornecedor, na sua NFe, nos campos vBCST e vICMSST. Pra piorar, quando não houver estar informação será preciso calcular via MVA -- que no exemplo acima, sequer foi informada.

[juaumkiko]

Entendi...

É... se o XML esta assim foi o software dele mesmo, nao é novidade preenchimento errado de ST pois muitos tem duvidas de como preencher, basta ver um topico aqui no forum mesmo sobre ST.

Na nfe 1.1 a validação esta menos criteriosa, ja na NFe 2.0 esta mais critica quanto a calculos de impostos. Obviamente eles nao fecharam todos os erros de preenchimento ainda, mas pelo andar da carruagem logo o farão e dae muita gente nao vai conseguir emitir nf do jeito que emite hoje... dae vao ficar desesperados e vao correr para quem fez o software. Tem que ficar esperto com isso.

[Alexsander]

Estou desenhando um processo em duas etapas:

1) Carga do XML (em lote, com FindFirst/FindNext) - apenas carrega o XML para o BD sem maiores processamentos além de extrair a chave de acesso e algumas informações bem básicas;

2) Processamento da NFe de Entrada - tenta identificar os produtos automaticamente pelo mapeamento CNPJ x cProd (que é o código interno do fornecedor, cadastrado como "referência" no cadastro do meu ERP). Se não encontrar, tenta pelo EAN -- e se tudo mais falhar, pede pro usuário fazer o mapeamento (e o salva para uso futuro). Depois que todos os produtos da NFe forem identificados o sistema segue o processo normal de recebimento de NF (conferência, entrada no estoque, etc).