Juliano Rosa

Boa tarde, amigos. É a Sefaz mesmo ou é algo com o certificado e capicom?

Pode ser a forma como você trata alguns campos. No meu sistema sempre ocorria "Falha no Schema XML" ao enviar Carta de Correção. Eu uso um Memo para o usuário digitar o texto da correção e os usuários tem o costume de pressionar Enter para fazer quebra de linha, mesmo que não tenha nada mais para escrever. Por alguma razão a quebra de linha no texto da carta de correção gera o erro de "Falha no Schema XML". Resolvi bloqueando o Enter no memo da carta de correção do meu programa.

Pessoal, este não é o mesmo problema do Capicom que está sendo relatado em vários tópicos aqui já? Dêem uma olhada no fórum.

Aconteceu com um cliente aqui do RS. Resolvi com a dica do amigo acima.

A NF deve sair com 12%, pois é interestadual. Mas no final das contas o ICMS da NF será 18%, porque deverá ser destacado os 6% da diferença de aliquota no grupo do ICMS interestadual. Vai dar elas por elas. Mas acho que você deve pedir a orientação do contador.

Uma dica: Na mensagem de duplicidade de NFe normalmente vem a chave de acesso que está gravada na Sefaz.

Bom dia, amigos. Desculpem desenterrar o tópico. Está acontecendo hoje novamente este problema na Bahia. Se trocar a data de emissão para 31/10/2016 a NFe passa sem problemas, mas com emissão 01/11/2016 não passa. A mensagem que o programa retorna é apenas "Nota não confirmada" e não diz o motivo. Olhando o xml do retorno aparece a mensagem: Erro na Chave de Acesso - Campo Id nao corresponde a concatenacao dos campos correspondentes Alguém mais com este problema?

Bom. Mas meus sistemas já estão todos adequados.

O texto da carta de correção deve ter no mínimo 15 caracteres. Se mandar menos, vai rejeitar. Essa mensagem "Falha no schema XML" tem aparecido em alguns casos de rejeição. Pra mim acontece sempre que um usuário envia carta de correção com quebra de linha <enter> no texto.

Não tive nenhum problema com o 0300.

Boa tarde, amigos Estou gerando o SEF II com o Bloco H do inventário. Corrigi a procedure TACBrSEF2.WriteBloco_9 que estava forçando a geração do Bloco E. Corrigi também a procedure TACBrSEF2.SaveFileTXT que estava forçando a geração do Bloco E e Bloco H de forma incorreta. ACBrSEF2.pas

Segue a unit com a alteração que fiz na procedure TBloco_J.WriteRegistroJ150(RegJ005: TRegistroJ005); ACBrECDBloco_J_Class.pas

Bom dia Estou gerando e alterando algumas coisas. No registro J150 o campo IND_VL_ULT_DRE deve ir em branco se não for preenchido. O programa está gerando automaticamente '0' neste campo e dá erro ao importar o arquivo. Vou ver se tem mais algum erro e subo a unit alterada.

Sim. Penso que esta interpretação está correta. No meu caso, deixei o campo do CEST no cadastro de NCMs e orientei os usuários a preencherem a informação do CEST conforme orientação do contador de cada um.

No meu entendimento o CEST 01.003.00 pode ser usado apenas no NCM 39181000.

Descobri o problema. Meu programa permite que o usuário informe a chave de acesso da NF em alguns casos. O usuário fez uma NF de devolução e colou a chave de acesso da NF de referência na chave da sua NF. Em seguida mandou transmitir, o programa consultou a chave e puxou o protocolo. Ao tentar fazer a carta de correção dá o erro de UF porque a chave da NFe é de SP e a empresa está no RJ. Então quem está tendo este problema está mandando correção para o webservice de uma UF para uma NF de outra UF.

Bom dia Está acontecendo comigo num cliente do RJ. Alguém sabe o que é? Acho que é erro da Sefaz....

Correto. No meu entendimento o FCP deve ser somado no seu campo próprio. Não deve ser somado no valor do ICMS normal dos itens nem do total. Bem como a parte da NT que fala que no valor bruto do produto deve ser somado o ICMS tem criado confusão, pois o ICMS já está no valor do produto. Se somar novamente vai dar erro de somatório.

Somatório de qual campo? O somatório de todos os campos de total deve bater com os valores informados nos itens, incluindo os novos campos do grupo de ICMS da UF de Destino. Já estou com vários clientes rodando NFe em ambiente de produção desde a última semana de dezembro em vários estados sem erro.

acredito que deu bug na Sefaz ontem com as atualizações do webservices... o interessante é que quase ninguém reclamou. ninguém emite NFe na Bahia e Pernambuco?

Bom dia, amigos Consegui transmitir as NFs trocando a data de emissão para 02/12. Se deixar emissão 01/12 não vai de jeito nenhum...

Amigos, isso está acontecendo comigo na Bahia e Pernambuco. Já revisei a chave de acesso e está de acordo com os campos. No PE retorna o erro na mensagem do componente NFe. Na Bahia retorna a mensagem em branco, mas no xml de retorno aparece a mensagem de erro. O interessante é que no retorno da Bahia a chave de acesso vem diferente da chave que eu passei no xml. O campo mês vem alterado de 12 para 11. Troquei a emissão da NF para 30/11/2015 e ela foi validada com sucesso. Mas não consigo validar nenhuma com emissão 01/12/2015. Abaixo trecho do XML da NF e do retorno da Bahia. Vejam a diferença na chave... - <infNFe versao="3.10" Id="NFe29151201415865000858550000000054251562427342"> - <ide> <cUF>29</cUF> <cNF>56242734</cNF> <natOp>VENDA DE PRODUCAO DO ESTABELECIMENTO</natOp> <indPag>1</indPag> <mod>55</mod> <serie>0</serie> <nNF>5425</nNF> <dhEmi>2015-12-01T00:00:00-02:00</dhEmi> <dhSaiEnt>2015-12-01T00:00:00-02:00</dhSaiEnt> <tpNF>1</tpNF> <idDest>1</idDest> <cMunFG>2910800</cMunFG> <tpImp>0</tpImp> <tpEmis>1</tpEmis> <cDV>2</cDV> <tpAmb>1</tpAmb> <finNFe>1</finNFe> <indFinal>0</indFinal> <indPres>0</indPres> <procEmi>0</procEmi> <verProc>3.0.0.0</verProc> - <protNFe versao="3.10"> - <infProt xmlns="http://www.portalfiscal.inf.br/nfe" Id="NFe129150107547324"> <tpAmb>1</tpAmb> <verAplic>5.0</verAplic> <chNFe>29151101415865000858550000000054251562427342</chNFe> <dhRecbto>2015-12-01T23:29:53-03:00</dhRecbto> <nProt>129150107547324</nProt> <digVal>WgPKdyDim2++zRoI24fklx8wLws=</digVal> <cStat>502</cStat> <xMotivo>Rejeicao: Erro na Chave de Acesso - Campo Id nao corresponde a concatenacao dos campos correspondentes</xMotivo> </infProt> </protNFe> Essa chave do retorno é preenchida pelo webservice da Sefaz ou pelo componente acbr? Agradeço qualquer luz... estou com duas empresas paradas.

Boa tarde Estou com este mesmo problema na BA e PE. Passou a acontecer hoje. Revisei as chaves de acesso e estão corretas. Não sei mais o que fazer...

Meus fontes estão atualizados. Mas o Juliomar tem razão, não é necessário forçar o Write. Na minha tela estava forçando porque peguei o exemplo de outro colega que estava assim. Já removi da minha tela e está gerando normalmente. A diferença que vi no seu código é que eu coloco os registros filhos dentro dos registros pai assim: with RegistroY001New do begin IND_DAD := idComDados; with RegistroY600New do begin ... end; end;